One unfortunately still too common practice I find in my fellow developers is to rely too much on overlays to get users involved; my personal preference on this matter is getting people to proxy-maintain packages, and the reason is that this way I can make sure the fixes propagate to all the other users in a timely matter, as well as being able to intercept mistakes before I commit them to the tree.
But there are other reasons why I dislike overlays; for instance, they often clash enough with each other, or mix should-be-working packages with don’t-even-try … which is the case of the current Gnome overlay. I used to use the Gnome overlay so I could test and help reporting bugs before the next release hit ~arch; unfortunately since a while ago now, the overlay contains Gnome3/Gtk+3 packages that really shouldn’t be mixed in on a system that is actually used.
This became obnoxious to me the moment I went to actually try Rygel (so that I could actually get rid of MediaTomb, if it worked and I could add it to the tree — that code is noxious!). The problem is not in the high reliance of Rygel on Vala, that would be good enough, given that we have it in tree; the problem is that the Rygel UI (and after trying it out I can safely say that you don’t want to try without the UI) requires either Gtk+3 (no way!) or Gtk+ 2.21… which is the “devel” branch and is present only on the gnome overlay. Not even masked in tree.
It wouldn’t have been too bad, if it wasn’t that upstream (finally!) split gdk-pixbuf from gtk+ itself, so you should finally be able to use librsvg without X11 on the system (which is why my charts are available only as SVG and cannot be seen by some browsers who have trouble displaying embedded SVG). Unfortunately, this also means that they changed the path gdk-pixbuf uses to load the loaders (no pun intended); and the current ~arch librsvg won’t pick that up. Again, the librsvg in the overlay has automagic-deps trouble, and require both Gtk+2 and Gtk+3 to be present to work. D’oh!
This is nothing new, what is the problem? Well, ostensibly beside the fact that Arun blogs about something we can’t have 😉 — not your fault, I know, not picking on you, don’t worry Arun!
The problem comes when I’ve asked before why the Gnome stuff is not pushed in main tree under p.mask, like most other teams work, especially given that I can make use of the tinderbox to check reverse dependencies before it’s unleashed, rather than have to report them afterwards. Indeed, Gtk+ and other libraries’ updates tend to be quite boring because there is way too much software that define GTK_NO_DEPRECATED and similar, which should only be used during development, and thus fail when stuff they us do get deprecated. Of course even if they didn’t define that, the code would be failing at the following update when they get removed, but that’s beside the point now.
Interestingly enough, though, the effect of (at least some) more recent deprecation seem to be causing the same kind of issue (if, by the mere fact we’re talking about Gtk+, to a lesser severity) of the recent glibc-2.12 release in the form of undefined symbols where GTK_* macros are used.
As you might suspect the tinderbox already stumbled across a few of these packages; while the quick-fix is generally quick (drop the NO_DEPRECATED definition), the complete fix (use the correct non-deprecated API) takes a while, and I can’t blame the maintainers for waiting to hear from upstream on that matter, especially given the way gtk+ is always dropped like a bombshell. Just to be on the safe side, I’ve now added some further tests to ensure that neither the “symbols” requirements caused by gtk+–2.20 nor those caused by glibc-2.12 will be left standing without further notice. If the tinderbox will ever build such a broken package, it’ll be reporting it to me so that I can file the proper bug.
Now, the gtk+–2.21 situation seem to start just as well; gtkhtml fails to build and it’s even part of Gnome itself. I will be begging the Gnome team again, starting from here, for them to add the ebuilds as soon as they are usable in main tree, under p.mask, so that the tinderbox can start churning at them.
But since people seem to think I write too much negatively, I have to say that at least a few developers seem to actually keep in mind there is the tinderbox available; Samuli, Alexis and Jeroen asked for feedback before unmasking (XFCE, Ocaml and libevent-2 respectively), and the problems found have been taken care of much more quickly then even I expected, for the most part. So if you’re a package maintainer and want the reverse dependencies of your package tested before unmasking a version into ~arch, just drop me a mail and I’ll set up a special run. It can take anything between half a day to a week or two depending on the size of the revdep tree and the queued up runs (right now it’s completing a full-system-set rebuild to see if there were more issues with glibc-2.12; turns out I only hit another problem and that was related to GNU make 3.82 instead (another “good” scary bump).
After this post, you can guess the following run is going to target gtk+–2.20. If there are no further runs, after that it’ll resume the daily-build of the tree.
Please keep in mind though: package.mask-ed packages are fine, but the tinderbox will not test any overlay. Get your fixes in the tree proper!
Didn’t you used to test java-overlay? I’m sure you pulled me up for one of my packages not setting source/target once.
No, that is _me_ using the java-overlay 😉
Small nitpick: it isn’t exactly the browsers support for svg. you’ve picked probably the least compatible method of embedding it. img only works in Opera afaict. object is a bit more universal with the annoying webkit transparency glitch. Best is probably embedding an svg tag directly with xhtml and maybe SSI to avoid fuglifying the code on your end at least. If there’s a better way I haven’t seen it yet.
Just Opera, Chrome, Safari, Mobile Safari (iPhone and Android). … I guess it only does not work with Firefox and Internet Explorer.
oops scratch that… I guess it does work in webkit now, I was thinking firefox (rebooting router fixed it… stupid wrt54g).
Personally, I think overlays are brilliant. It *is* an excellent way to get more users involved. But you need good policies. If something would likely break a user’s system, mask it or drop keywords, for example.
They work great for _new_ packages; not to maintain the packages that are _already_ in maintree and that by moving to overlays will be ignored for wayyyy too long time.If it wasn’t for Justin, the sci software would be not working most of the time still; and LISP is at the same point right now.
Dear Flameeyes, concerning overlays is all so true of what you write. These are exactly the reasons I’m against overlays, but too bad, that I don’t have a lot of free time (anymore) to spend on gentoo and I’m just a stupid user.It looks like you and me should start killing off all those frickin overlays.CheersJ
About gnome-overlay: gnome 3 is masked. Additionally overlays helps to get people involved without becoming full gentoo developer. Either as: – Nagging constantly to pull patches from his/her repo. – Having rw access to overlay without becoming full gentoo devloper (due to for example time limitations)I try to work with gnome-overlay and give them bumps from time to time. I cannot imagine to work with gentoo CVS server. Additionally in such way I can have chance of getting some recognition as author of ebuild 😉
Is it masked now? Because I’m quite sure that leio’s answer last time was something along the line “simply don’t use it anymore”. And it does not solve the problem with Gtk+ 2.21, given that _to actually work_ (you do need SVG pixbuf support, or things like Gwibber won’t even start) it needs Gtk+ 3 as well… which seems to me like being part of Gnome 3, not 2.And proxy-maintainership still allows users to submit ebuilds. And if the problem is time, rather than quality, we should solve _taht_, not work it around getting even worse overall quality!
it is masked since 22 Jun 2010. The Gnome 3 is maintained by ABCD but I try to nag him to push my changes from time to time 😉 [it seems that ford_prefect committed recently some fixes].The problem with autodeps etc. is indeed problem and I agree that if portage is primary target for fixes but I oppose that ‘all overlays are evil’.I don’t think I would be so happy to fill a lot of bugs with ebuilds attached to push gnome 3.0. Even if testing (making it built, patching autodetection & build failers, posting bugs upstream etc.) takes a lot of time I’m more willing to work on git (alternativly darcs or other DVCS) then with bugzilla. I know of at least one person who works on overlay without status of developer (he however have write access – it is on different overlay though).I belive that removal of overlay would create the bigger gap between users and developers.Portage is rsync for user CVS for devs. It have many auxalary tools developer needs to learn. I wouldn’t imagine to became Gentoo developer maybe also (altought not primarly) with the chicken and egg problem (I don’t need to learn ools because I’m not Gentoo developer and I won’t become Gentoo Developer without knowing tools).I understend that change of infrastructure cannot be done overnight but using git/darcs/… helps me to just drop into some ebuild management. Creating patches/bumps is easy and all I have tools to do them. With rsync I don’t have them and with CVS I cannot work with local branch (ok. I can use git-cvs or something like that).Additionally such support allows to submit ebuilds when I have time. I’m not formal Gentoo developer, it doesn’t have to be my formal, important project. I can share ebuilds/fix them when I have time. When I first submit several ebuilds I got some valuable feedback (QA) from gnome team. Probably I wouldn’t write so much if there was no overlays.
I just patched gnome-base/librsvg in the overlay to only build against x11-libs/gtk+:3 when USE=gtk3 is set, so that part should be fixed now.
(mutter:5865): St-WARNING **: Failed to load /usr/share/gnome-shell/theme/section-more-open.svg: Unrecognized image file format
Flameeyes,Thanks for the post. Your insight allowed me to “fix” the unstable version of gnome-shell from the gnome overlay so that it doesn’t spew so many errors about:(mutter:5865): St-WARNING **: Failed to load /usr/share/gnome-shell/theme/section-more-open.svg: Unrecognized image file formatand it’s user interface makes more sense now (it was missing many interface “buttons”.P.S. Sorry about the previous post.
As Maciej points out, all the unstable stuff is, or should be, masked in overlay.You’re going to love this, though – the GTK+ dep in configure.ac is a lie. You should be able to run it with a stable version of GTK+.
Once we get the git switch such stuff will be way easier…(since would be just a matter of merging overlay branches back to master portage)
I do not remember having seen any e-mails to gnome@ about overlay usage, or bugs in the overlay to the e-mail or bugzilla from you. So I’m not quite sure what do you expect to achieve with these rants and calls for abolishing overlays in your blog, if you even intend that. A blog is a blog, ramblings of a given person, afterall. I don’t always read it. Things surely most often don’t get converted into trackable task items, etc.We will not enter a discussion about the pros and cons of the things being currently done in GNOME overlay being done in the overlay instead of portage tree in some random blog comments.Please share your concerns about the GNOME team way of working in a discussable medium, such as gnome@ mail alias, an apporpriate mailing list or other such means, so we can discuss and address them with the whole team.Your GNOME team lead,Leio
I’ve been calling to get GTK+, glib, librsvg and rest of the non-gnome packages out of the overlay and in tree for years now.To test Xfce4 (and rest of the tree) early with them, instead of when shit has already hit the roof.Perhaps one day I’ll get motivated enough to get GTK+ and co. transferred from “gnome” herd to “freedesktop” herd and get things properly tested…
How is Rygel coming along? I too would love to ditch mediatomb. Need additional testers for it?