GNOME has, for some reason or another,
always been the default desktop environment in Debian since the installer is
able to install a full desktop environment by default. Release after release,
Debian has been shipping different versions of GNOME, first based on the
venerable 1.2/1.4 series, then moving to the time-based GNOME 2.x series,
and finally to the newly designed 3.4 series for the last stable release,
Debian 7
wheezy .
During the final stages of wheezy s development, it was pointed out that
the first install CD image would not longer hold all of the required packages
to install a full GNOME desktop environment. There was lots of discussion
surrounding this bug or fact, and there were two major reactions to it. The
Debian GNOME team rebuilt some key packages so they would be compressed using
xz instead of
gzip, saving the few megabytes that
were needed to squeeze everything in the first CD. In parallel, the tasksel
maintainer decided
switching to Xfce as default
desktop was another obvious fix. This change, unannounced and two days before
the freeze, was very contested and spurred the usual massive debian-devel
threads. In the end, and after a few default desktop flip flops, it was agreed
that GNOME would remain as the default for the already frozen wheezy release,
and this issue would be revisited later on during
jessie s
development.
And indeed, some months ago, Xfce was again reinstated as Debian s
default desktop for jessie as announced:
Change default desktop to xfce.
This will be re-evaluated before jessie is frozen. The evaluation will
start around the point of DebConf (August 2014). If at that point gnome
looks like a better choice, it ll go back as the default.
Some criteria for that choice will include:
* Popcon numbers for gnome on jessie. If gnome installations continue to
rise fast enough despite xfce being the default (compared with, say
kde installations), then we ll know that users prefer gnome.
Currently we have no data about how many users would choose gnome when
it s not the default. Part of the reason for switching to xfce now
is to get such data.
* The state of accessability support, particularly for the blind.
* How well the UI works for both new and existing users. Gnome 3
seems to be adding back many gnome 2 features that existing users
expect, as well as making some available via addons. If it feels
comfortable to gnome 2 (and xfce) users, that would go a long way
toward switching back to it as the default. Meanwhile, Gnome 3 is also
breaking new ground in its interface; if the interface seems more
welcoming to new users, or works better on mobile devices, etc, that
would again point toward switching back.
* Whatever size constraints exist for CD or other images at the time.
--
Hello to all the tech journalists out there. This is pretty boring.
Why don t you write a story about monads instead?
Joey Hess in dfca406eb694e0ac00ea04b12fc912237e01c9b5.
Suffice to say that the Debian GNOME team participants have never been
thrilled about how the whole issue is being handled, and we ve been wondering
if we
should be doing anything about it, or just move along and enjoy
the smaller amount of bug reports against GNOME packages that this change would
bring us, if it finally made it through to the final release. During our real
life meet-ups in FOSDEM and the
systemd+GNOME sprint
in Antwerp, most members of the team did feel Debian would not be
delivering a graphical environment with the polish we think our users deserve,
and decided we at least should try to convince the rest of the Debian project
and our users that Debian will be best suited by shipping GNOME 3.12 by
default. Power users, of course, can and know how to get around this default
and install KDE, Xfce, Cinnamon, MATE or whatever other choice they have. For
the average user, though, we think we should be shipping GNOME by default, and
tasksel should revert the above commit again. Some of our reasons are:
- Accessibility: GNOME continues to be the only free desktop
environment that provides full accessibility coverage, right from login screen.
While it s true GNOME 3.0 was lacking in many areas, and GNOME 3.4 (which we
shipped in wheezy) was just barely acceptable thanks to some last minute GDM
fixes, GNOME 3.12 should have ironed out all of the issues and our non-expert
understanding is that a11y support is now on par with what GNOME 2.30 from
squeeze offered.
- Downstream health: The number of active members in the
team taking care of GNOME in Debian is around 5-10 persons, while it is 1-2 in
the case of Xfce. Being the default desktop draws a lot of attention (and bug
reports) that only a bigger team might have the resources to handle.
- Upstream health: While GNOME is still committed to its
time-based release schedule and ships new versions every 6 months, Xfce
upstream is, unfortunately, struggling a bit more to keep up with new plumbing
technology. Only very recently it has regained support to suspend/hibernate via
logind, or support for Bluez 5.x, for example.
- Community: GNOME is one of the biggest free software
projects, and is lucky to have created an ecosystem of developers, documenters,
translators and users that interact regularly in a live social community. Users
and developers gather in hackfests and big, annual conferences like
GUADEC, the
Boston Summit, or
GNOME.Asia. Only KDE has a comparable
community, the rest of the free desktop projects don t have the userbase or
humanpower to sustain communities like this.
- Localization: Localization is more extensive and complete
in GNOME. Xfce has 18 languages above 95% of coverage, and 2 at 100%
(excluding English). GNOME has 28 languages above 95%, 9 of them being
complete (excluding English).
- Documentation: Documentation coverage is extensive in
GNOME, with most of the core applications providing localized, up to date and
complete manuals, available in an accessible format via the Help reader.
- Integration: The level of integration between components
is very high in GNOME. For example, instant messaging, agenda and accessibility
components are an integral part of the desktop. GNOME is closely integrated to
NetworkManager, PulseAudio, udisks and upower so that the user has access to
all the plumbing in a single place. GNOME also integrates easily with online
accounts and services (ownCloud, Google, MS Exchange ).
- Hardware: GNOME 3.12 will be one of the few desktop
environments to support HiDPI displays, now very common on some laptop models.
Lack of support for HiDPI means non-technical users will get an unreadable
desktop by default, and no hints on how to fix that.
- Security: GNOME is more secure. There are no processes
launched with root permissions on the user s session. All everyday operations
(package management, disk partitioning and formatting, date/time
configuration ) are accomplished through PolicyKit wrappers.
- Privacy: One of the latest focuses of GNOME development is
improving privacy,
and work is being done to make it easy to run GNOME applications in isolated
containers, integrate Tor seamlessly in the desktop experience, better disk
encryption support and other features that should make GNOME a more secure
desktop environment for end users.
- Popularity: One of the metrics discussed by the tasksel
change proponents mentioned popcon
numbers. 8 months after the desktop change,
Xfce does not seem to have made a dent on install numbers.
The Debian GNOME team doesn t feel popcon s data is any better than a
random online poll though, as it s an opt-in service which the vast majority
of users don t enable.
- systemd embracing: One of the reasons to switch to Xfce
was that it didn t depend on systemd. But now that systemd is the default, that
shouldn t be a problem. Also given ConsoleKit is deprecated and dead upstream,
KDE and Xfce are switching or are planning to switch to systemd/logind.
- Adaptation: Debian forced a big desktop change with the
wheezy release, switching from the traditional GNOME 2.x to the new GNOME Shell
environment. Switching again would mean more adaptation for uses when they ve
had two years to experience GNOME 3.4. Furthermore, GNOME 3.12 means two years
of improvements and polishing to GNOME 3.4, which should help with some of the
rough edges found in the GNOME release shipped with wheezy.
- Administration: GNOME is easy to administrate. All the
default settings can be defined by administrators, and mandatory settings can
be forced to users, which is required in some companies and administrations;
Xfce cannot do that. The close integration with freedesktop components
(systemd, NM, PulseAudio ) also gives access to specific and useful
administration tools.
In short, we think defaulting to GNOME is the best option for the Debian
release, and in contrast, shipping Xfce as the default desktop could mean
delivering a desktop experience that has some incomplete or rough edges, and
not on par with Debian quality standards for a stable release. We believe
tasksel should again revert the change and be uploaded as soon as possible, in
order to get people testing images with GNOME the sooner the better, with the
freeze only two months away.
We would also like that in the future, changes of
this nature will not be announced in a git commit log, but widely discussed in
debian-project and the other usual development/decision channels, like the
change of init system happened recently. We will, whichever the final decision
is, continue to package GNOME with great care to ensure our users get the best
possible desktop experience Debian can offer.
With the end of the year approaching fast, I thought putting my year in
retrospective via music would be a fun thing to do.
Albums
In 2022, I added 51 new albums to my collection nearly one a week! I listed
them below in the order in which I acquired them.
I purchased most of these albums when I could and borrowed the rest at
libraries. If you want to browse though, I added links to the album covers
pointing either to websites where you can buy them or to Discogs when digital
copies weren't available1.
Browsing through the albums, I can see my tastes really shifted a lot in the
last few years. I used to listen to a lot of Hip-Hop, but the recent trends in
this genre2 really turn me off. In fact, it seems I didn't add a single
Hip-Hop album to my collection this year...
Metal also continues to dominate the list. Many thanks to Angry Metal
Guy for being the best metal reviewing website out there.
The 
A new released of 
What happened about the 
There s a lot of discussion / moaning /arguing at this time, so I thought I d post something about how LAVA got into Debian Jessie, the work involved and the lessons I ve learnt. Hopefully, it will help someone avoid the disappointment of having their package missing the migration into a future stable release. This was going to be a talk at the Minidebconf-uk in Cambridge but I decided to put this out as a permanent blog entry in the hope that it will be a useful reference for the future, not just Jessie.
Context
LAVA relies on a number of dependencies which were at the time all this started NEW to Debian as well as many others already in Debian. I d been running LAVA using packages on my own system for a few months before the packages were ready for use on the main servers (I never actually installed LAVA using the old virtualenv method on my own systems, except in a VM). I did do quite a lot of this on my own but I also had a team supporting the effort and valuing the benefits of moving to a packaged system.
At the time, LAVA was based on Ubuntu (12.04 LTS Precise Pangolin) and a new Ubuntu LTS was close (Trusty Tahr 14.04) but I started work on this in 2013. By the time my packages were ready for general usage, it was winter 2013 and much too close to get anything into Ubuntu in time for Trusty. So I started a local repo using space provided by Linaro. At the same time, I started uploading the dependencies to Debian. json-schema-validator, django-testscenarios and others arrived in April and May 2014. (Trusty was released in April). LAVA arrived in NEW in May, being accepted into unstable at the end of June. LAVA arrived in testing for the first time in July 2014.
Upstream development continued apace and a regular monthly upload, with some hotfixes in between, continued until close to the freeze.
At this point, note that although upstream is a medium sized team, the Debian packaging also has a team but all the uploads were made by me. I planned ahead. I knew that I would be going to Macau for Linaro Connect in February a critical stage in the finalisation of the packages and the migration of existing instances from the old methods. I knew that I would be on vacation from August through to the end of September 2014 including at least two weeks with absolutely no connectivity of any kind.
Right at this time, Django1.7 arrived in experimental with the intent to go into unstable and hence into Jessie. This was a headache for me, I initially sought to delay the migration until after Jessie. However, we discussed it upstream, allocated time within the busy schedule and also sought help from within Debian with the RFH tag. Rapha l Hertzog contributed patches for django1.7 support and we worked on those patches upstream, once I was back from vacation. (The final week of my vacation was a work conference, so we had everyone together at one hacking table.)
Still there was more to do, the django1.7 patches allowed the unit tests to complete but broke other parts of the lava-server package and needed subsequent tweaks and fixes.
Even with all this, the auto-removal from testing for packages affected by RC bugs in their dependencies became very important to monitor (it still is). It would be useful if some packages had less complex dependency chains (I m looking at you, uwsgi) as the auto-removal also covers build-depends. This led to some more headaches with libmatheval. I m not good with functional programming languages, I did have some exposure to Scheme when working on Gnucash upstream but it wasn t pleasant. The thought of fixing a scheme problem in the test suite of libmatheval was daunting. Again though, asking for help, I found people in the upstream team who wanted to refresh their use of scheme and were able to help out. The fix migrated into testing in October.
Just for added complications, lava-server gained a few RC bugs of it s own during that time too fixed upstream but awkward nonetheless.
Achievement unlocked
So that s how a complex package like lava-server gets into stable. With a lot of help. The main problem with top-level packages like this is the sheer weight of the dependency chain. Something seemingly unrelated (like libmatheval) can seriously derail the migrations. The package doesn t use the matheval support provided by uwsgi. The bug in matheval wasn t in the parts of matheval used by uwsgi. It wasn t in a language I am at all comfortable in fixing but it s my name on the changelog of the NMU. That happened because I asked for help. OK, when django1.7 was scheduled to arrive in Debian unstable and I knew that lava was not ready, I reacted out of fear and anxiety. However, I sought help, help was provided and that help was enough to get upstream to a point where the side-effects of the required changes could be fixed.
Maintaining a top-level package in Debian is becoming more like maintaining a core package in Debian and that is a good thing. When your package has a lot of dependencies, those dependencies become part of the maintenance workload of your package. It doesn t matter if those are install time dependencies, build dependencies or reverse dependencies. It doesn t actually matter if the issues in those packages are in languages you would personally wish to be expunged from the archive. It becomes your problem but not yours alone.
Debian has a lot of flames right now and Enrico encouraged us to look at what else is actually happening in Debian besides those arguments. Well, on top of all this with lava, I also did what I could to help the arm64 port along and I m very happy that this has been accepted into Jessie as an official release architecture. That s a much bigger story than LAVA yet LAVA was and remains instrumental in how arm64 gained the support in the kernel and various upstreams which allowed patches to be accepted and fixes to be incorporated into Debian packages.
So a roll call of helpers who may otherwise not have been recognised via changelogs, in no particular order:
If you're a
DebConf12 speaker and produced slides, please upload them to penta,
so that they could be used as future reference.
I have had the pleasure of attending 
I came one day early to participate, as Debian's representative, at the
yearly GNOME Advisory Board meeting, for the first time. It was a positive
experience, which helped me get a grasp of the big picture of what the GNOME
Foundation does. I also had the pleasure of visiting
When I was first approached about this, I thought Collabora was a small
company. But as I looked more into it, I discovered that's not longer the
case, there's many more people than I imagined working there (here!), and
was delighted to see I knew many of them, and many other are well known
members of the major Free Sofware communities. I'll be joining the
sysadmin team to work closely with
Thanks!!!
Work to bring
