Cinnamon 2.4

A few weeks ago, I upgrade all cinnamon ebuilds to 2.4 in tree. However I could not get Cinnamon (shell part) to actually work, as in show anything useful on my display. So this is a public service announcement that if you like Cinnamon and want to help with this issue, please visit bug #536374. For some reason, the hacks found in gnome-shell does not seem to work with cinnamon’s shell.

Gnome 3.14

Gnome 3.14 ebuilds started hitting the tree a couple of days ago. Move is now complete and Gnome 3.14 was unmasked a couple of minutes ago. Besides the usual bumps, we worked on adding complete Wayland support. If you are eager to help upstream debug it, feel free to test but before filing any report, don’t forget to check upstream’s list of known limitations (like missing Drag’n’Drop, etc).

Gnome 3.14 also required GStreamer 1.4 that leio has been working on. First ebuilds have been added to allow Gnome unmasking, more to come.

We are also still looking for new recruits for the team as we are really low on active team members. If you feel like helping but are not sure about your skills, worry not, we can help you.

The future of Gnome 2

Following forum [1], IRC and mailing list reading, I wanted to clarify Gnome team position on what will happen now that Gnome 3.8 has moved to stable.

Gnome 2 is going to be removed.

I think it cannot be more clear and there are multiple reasons for that. Let’s write a bit about those so people do not try to invent conspiracy theories:

  • Gnome 2 is not maintained anymore, nothing will make this fact go away.
  • the team is understaffed, many of our talented contributors are too busy with real life or simply quit the (Gentoo) project.
  • Bug reports are still flowing for Gnome 2 but none of us in the team are running it anymore because we do not have the extent of time needed for that.

So, yes, Gnome 3 does not suit everyone’s tastes, but most of us still love it, yes, it depends on systemd and most of us would rather keep our good ol’ openrc that did the work just fine but Gnome 2 is going away and nothing will change that.

What we recommend to people who loved Gnome 2 is to switch to alternatives like XFCE, MATE or Cinnamon because there is no point in living in the past.


Gnome 3.6

We had a marathon with Alexandre (tetromino) in the last 2 weeks to get Gnome 3.6 ebuilds using python-r1 eclasses variants, EAPI=5 and gstreamer-1. And now it is finally in gentoo-x86, unmasked.

You probably read, heard or have seen stuff about EAPI=5 and new python eclasses before but, in short, here is what it will give you:

  • package manager will finally know for real what python version is used by which package and be able to act on it accordingly (no more python-updater when all ebuilds are migrated)
  • EAPI=5 subslots will hopefully put an end to revdep-rebuild usage. I already saw it in action while bumping some of the telepathy packages to discover that empathy was now automatically being rebuilt without further action than emerge -1 telepathy-logger.

No doubt lots of people are going to love this.

Gnome 3.6 probably still has a few rough edges so please, check bugzilla before filing new reports.

gstreamer 1.0

It has been a while since I have last written here but I am not dead and I still somehow manage to contribute to Gentoo.

In the past weeks, I have been working on making Gnome 3.6 ready for inclusion in portage. It rapidly appeared that Gnome 3.6 would have to use both gstreamer 0.10 and gstreamer 1.0 however gstreamer team is badly understaffed and only Alexandre (tetromino) who is not even a gstreamer team member had tried to start bumping ebuilds to gstreamer 1.0.

But then Alexandre got busy and this development stalled a bit. After I finished bumping the overlay to Gnome 3.6.1, I took the challenge to rewrite the gstreamer eclasses to make them easier to use and understand. They were, in my opinion, quite scary with version checks everywhere and I think it is one of the reason that so few people wants to work in gstreamer team 🙂

If you do not follow gentoo-dev, most of the code moved to gst-plugins10.eclass which received some magic touches that basically makes 99% of the version dependant code go away. As an added bonus, the eclasses are now documented and support EAPI 1 to 5. EAPI 0 support got dropped because of missing slot operators which is really annoying right now with gstreamer.

So if you hit some gstreamer compilation problems in the last few days, please forgive me, upgrade road was a bit bumpy but, overall, it was not so bad. And now, I am happy to say that gstreamer 1.0 is in portage which clears the road for gnome 3.6 inclusion.

On a final note, I also continued Alexandre’s work of bumping last 0.10 releases and so we are up-to-date on that front as well.

Happy compiling !

Things you didn’t known about IPv6 link-local address

I regained interest in trying IPv6 at home since my ISP provides the option to switch to IPv6 (also some might say it’s not IPv6 to the end user as it is intended in IPv6 design documents). But before ticking the appropriate box on the router interface, I wanted to give a shot at serverless network configuration.

I’m running ftp, nfs, afp, ntp, http, smtp, imap and some other servers at home and as I have a couple of machines to run that on, I soon needed a dns and a ldap server for good measure. For reasons I won’t detail, I wanted to give a shot at dns-less (bind) network but still keep name resolution with mdns (avahi, yay auto-discovery of services).

Now to get back to IPv6, I’ve seen MacOS X do a couple of things out of the box with link-local addresses and naive as I am at times, I thought GNU/Linux would do the same. I’ve had IPv6 enabled for a long time in my kernels but never managed to ping others machines without starting a dhcp v6 server (radvd). So digging a bit, I soon discovered that basic tools you find on a GNU/Linux system are useless with link-local address. Take ping6 for example, you want to ping a host you have the address of so you type:

$ ping6 fe80::21b:63ff:feab:e6a6
connect: Invalid argument

Meh ??? It’s a valid address, WTF is it telling me. Google to the rescue, you have to specify the network interface you want to use to send the packet. It’s ok ping6 has a -I parameter that allows you to select the one you want, and you also find that there is a weird syntax that allows you to do that inline:

$ ping6 -I eth0 fe80::21b:63ff:feab:e6a6
PING fe80::21b:63ff:feab:e6a6%eth0(fe80::21b:63ff:feab:e6a6) 56 data bytes
64 bytes from fe80::21b:63ff:feab:e6a6: icmp_seq=1 ttl=64 time=0.041 ms
$ ping6 fe80::21b:63ff:feab:e6a6%eth0
PING fe80::21b:63ff:feab:e6a6%eth0(fe80::21b:63ff:feab:e6a6) 56 data bytes
64 bytes from fe80::21b:63ff:feab:e6a6: icmp_seq=1 ttl=64 time=0.041 ms

You’re all happy now that you sent your first ping over IPv6, now since avahi tells the local world about this machine’s address, you want to try using it’s hostname:

$ ping6 -I eth0 shinobu.local
PING shinobu.local(shinobu.local) from fe80::21b:63ff:feab:e6a6 eth0: 56 data bytes
64 bytes from shinobu.local: icmp_seq=1 ttl=64 time=0.377 ms
$ ping6 shinobu.local%eth0
unknown host

Hu ho, what’s going on here. This post is getting way longer than I expected so let’s jump to the conclusion.

I have found no trick to make a program know about the network interface I want to use when using hostnames so if you want to use ssh or wget that don’t have a way to specify the network interface you’re screwed. Ho yes, there is a solution, you can write wrapper scripts that will resolve the address for you and rewrite the command with the address%iface format, but that’s crazy. Os X seems to do this just fine, how come free software can’t ? (this is a rethorical question in case you wonder).

Finally, having a dhcp v6 server providing a global scope address solves these issues but to the cost of having a device to run it on. A device you depend on and that must be online all the time. Say good bye to auto-discovery, etc on your network.

Gnome herd needs fresh blood

Title says it all. As things are today, even though a couple of people popped up on my previous “Looking for a padawan” post none of them got actually involved, gnome herd is failing its mission. Gnome 2.28 is not getting keyworded, no migration documentation is being worked on and no stabilization list is in preparation either. As for gnome 2.30, we are closing in final release and we still don’t have 50% of compliant packages in overlay (probably even less). Since working in gentoo got a lot less fun for me, the situation isn’t going to change much in the foreseeable future.

Irregular update

A few words to say that even though I’ve been busy irl, gnome 2.28.2 is almost completely in tree (about 10 packages left). Also, I finally killed tracker 0.6 from the tree, it was rusty and deserved some rest. Tracker 0.7 has been added and although it’s API/ABI changed, it already is integrated to nautilus 2.28. I still have to get the totem patch for it and we will be back to what was supported with 0.6. I’ve also updated the live ebuild and I’ll make sure it stays in sync with last release.

Looking for a padawan

Title says it all. It’s pretty obvious that gnome team can’t currently keep up with the income of new bugs (especially a lot of unexpected 2.26 bugs) and I keep being split between my gnome duties and maintenance of various other stuff (notably freedesktop that no-one seems to care about these days). So I need one, two or more guys/gals that want to get their hands a bit dirty. If you feel up to it, just come and say hello on #gentoo-desktop, if I’m not around, probably other gnome herd members will be waiting for you :).