Samuel Henrique: Hello World
This is my very first post, just to make sure everything is working as expected.
Made with Zola and the Abridge theme.
$ sudo apt update
$ sudo apt install flatpak
$ flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
$ which -s gnome-software && sudo apt install gnome-software-plugin-flatpak
$ which -s plasma-discover && sudo apt install plasma-discover-backend-flatpak
xdg-portal-*
packages, that are required for Flatpak
applications to communicate with the desktop environment. Just to be sure, you
can check the output of apt search '^xdg-desktop-portal'
to see what's
available, and compare with the output of dpkg -l grep xdg-desktop-portal
.
As you can see, if you're a GNOME or KDE user, there's a portal backend for
you, and it should be installed. For reference, this is what I have on my GNOME
desktop at the moment:
$ dpkg -l grep xdg-desktop-portal awk ' print $2 '
xdg-desktop-portal
xdg-desktop-portal-gnome
xdg-desktop-portal-gtk
flatpak --system
, the default) or
per-user (aka. flatpak --user
)? Turns out, this questions is answered in the
Flatpak documentation:
Flatpak commands are run system-wide by default. If you are installing applications for day-to-day usage, it is recommended to stick with this default behavior.Armed with this new knowledge, let's install the Firefox app:
$ flatpak install flathub org.mozilla.firefox
$ flatpak run org.mozilla.firefox
~/.mozilla/
-- where the Firefox Debian package stores its data~/.var/app/org.mozilla.firefox/.mozilla/
-- where the Firefox Flatpak
app stores its data# BEWARE! Below I'm erasing data!
$ rm -fr ~/.var/app/org.mozilla.firefox/.mozilla/firefox/
$ cp -a ~/.mozilla/firefox/ ~/.var/app/org.mozilla.firefox/.mozilla/
$ mv ~/.mozilla/firefox ~/.mozilla/firefox.old.$(date --iso-8601=date)
flatpak run org.mozilla.firefox
takes me to my "usual"
everyday Firefox, with all its tabs opened, pinned, bookmarked, etc.
More integration?
After following all the steps above, I must say that I'm 99% happy. So far,
everything works as before, I didn't hit any issue, and I don't even notice
that Firefox is running via Flatpak, it's completely transparent.
So where's the 1% of unhappiness? The Run a Command dialog from GNOME, the
one that shows up via the keyboard shortcut <Alt+F2>
. This is how I start my
GUI applications, and I usually run two Firefox instances in parallel (one for
work, one for personal), using the firefox -p <profile>
command.
Given that I ran apt purge firefox
before (to avoid confusing myself with two
installations of Firefox), now the right (and only) way to start Firefox from a
command-line is to type flatpak run org.mozilla.firefox -p <profile>
. Typing
that every time is way too cumbersome, so I need something quicker.
Seems like the most straightforward is to create a wrapper script:
$ cat /usr/local/bin/firefox
#!/bin/sh
exec flatpak run org.mozilla.firefox "$@"
<Alt+F2>
and type firefox -p <profile>
to start
Firefox with the profile I want, just as before. Neat!
Looking forward: system updates
I usually update my system manually every now and then, via the well-known pair
of commands:
$ sudo apt update
$ sudo apt full-upgrade
flatpak update [OPTION...] [REF...] Updates applications and runtimes. [...] If no REF is given, everything is updated, as well as appstream info for all remotes.Could it be that simple? Apparently yes, the Flatpak equivalent of the two
apt
commands above is just:
$ flatpak update
flatpak update
additionally to apt update
, manually,
everytime I update my system.gnome-software-plugin-flatpak
,
and that I checked Software Updates -> Automatic in the Settings (which I
did).
However, I didn't find any documentation regarding what this setting really
does, so I can't say if it will only download updates, or if it will also
install it. I'd be happy if it automatically installs new version of Flatpak
apps, but at the same time I'd be very unhappy if it automatically upgrades my
Debian system...
So we'll see. Enough for today, hope this blog post was useful!
Multi-Arch: same
file loss. It was found that the proposed
mitigation for ineffective diversions does
not work as expected. Trying to fix it up resulted in more problems, some of
which remain unsolved as of this writing.
Initial work on moving shared libraries in the essential set has been done.
Meanwhile, the wider Debian community worked on fixing all known
Multi-Arch: same
file loss scenarios. This work is now being driven by
Christian Hofstaedler and during the Mini DebConf in Cambridge, Chris Boot,
tienne Mollier, Miguel Landaeta, Samuel Henrique, and Utkarsh Gupta sent
the other half of the necessary patches.
/dev/fd/N
from fuse3
to fuse2
.piuparts
..oct
files.-fdebug-prefix-map
to clang to match GCC, another patch against gcc-5 to backport the removal of -fdebug-prefix-map
from DW_AT_producer
, and finally by proposing the addition of a normalizedebugpath
to the reproducible
feature set of dpkg-buildflags
that would use -fdebug-prefix-map
to replace the current directory with .
using -fdebug-prefix-map
.
Sergey Poznyakoff merged the --clamp-mtime
option so that it will be featured in the next Tar release. This option is likely to be used by dpkg-deb
to implement deterministic mtimes for packaged files.
Packages fixed
The following packages have become reproducible due to changes in their
build dependencies:
augeas,
gmtkbabel,
ktikz,
octave-control,
octave-general,
octave-image,
octave-ltfat,
octave-miscellaneous,
octave-mpi,
octave-nurbs,
octave-octcdf,
octave-sockets,
octave-strings,
openlayers,
python-structlog,
signond.
The following packages became reproducible after getting fixed:
i386
build nodes have been setup by converting 2 of the 4 amd64
nodes to i386
. (h01ger)
Package reviews
92 reviews have been removed, 66 added and 31 updated in the previous week.
New issues: timestamps_generated_by_xbean_spring, timestamps_generated_by_mangosdk_spiprocessor.
Chris Lamb filed 7 FTBFS bugs.
Misc.
On March 20th, Chris Lamb gave a talk at FOSSASIA 2016 in Singapore.
The very same day, but a few timezones apart, h01ger did a presentation at LibrePlanet 2016 in Cambridge, Massachusetts.
Seven GSoC/Outreachy applications were made by potential interns to work on various aspects of the reproducible builds effort. On top of interacting with several applicants, prospective mentors gathered to review the applications.
.oct
files.-fdebug-prefix-map
to clang to match GCC, another patch against gcc-5 to backport the removal of -fdebug-prefix-map
from DW_AT_producer
, and finally by proposing the addition of a normalizedebugpath
to the reproducible
feature set of dpkg-buildflags
that would use -fdebug-prefix-map
to replace the current directory with .
using -fdebug-prefix-map
.
As succesful result of lobbying at LibrePlanet 2016, the --clamp-mtime
option will be featured in the next Tar release. This option is likely to be used by dpkg-deb
to implement deterministic mtimes for packaged files.
i386
build nodes have been setup by converting 2 of the 4 amd64
nodes to i386
. (h01ger)