Hi all,
Over the past few days, I took some time to start merging G:F:N updates in G:F. Thanks a lot to the people who worked on G:F:N, it was a good way to stay updated with the latest versions.
The merge went fine overall. I took the opportunity to look at the packages closely, and fixed various other things (wrong BuildRequires, eg), sent various patches upstream (I was bad enough to not tag them in the spec files, though :/), dropped various old unneeded patches, etc.
There are only a few packages left. Here's a summary of why I left those packages:
=============== avahi: it's probably okay, but I'd love to have Stanislav double-check
devhelp: depends on webkit. I'm not sure the webkit we have right now is of good quality (it's quite old). So do we want this?
empathy: was looking at the updated empathy-lockdown.patch patch, and wondering if it had been sent upstream... Not really a blocker ;-)
evolution evolution-data-server evolution-exchange: too big for "osc rdiff", so I got lazy and ignored them for now
gdm: I think it needs a manual merge (broken patch) Didn't look closer.
gnome-power-manager: requires devicekit-power
gstreamer-0_10-plugins-bad: legal status of the new plugins unclear
libgda libgnomedb: I think it needs a manual merge (broken patch). Also I don't know if we can safely update to libgda 4 now?
libsoup: it drops a patch but the upstream bug is still open with no clear resolution
nautilus: I think it needs a manual merge (broken patch) Didn't look closer.
gnome-packagekit PackageKit: would be good to have Scott look at this
system-config-printer: I want to take a closer look at the newer version to see if it's okay to update
tomboy: don't remember -- probably just a minor tweak I wanted to do :-) ===============
I'll continue at some point this week, but people should feel free to finish the work ;-)
Vincent
Le lundi 26 janvier 2009, à 15:26 +0100, Vincent Untz a écrit :
I'll continue at some point this week, but people should feel free to finish the work ;-)
I forgot to mention -- a few packages fail to build. For some, it's only because it's an old version (gnome-utils, eg). For others, it's only a directory ownership issue (most probably on /usr/share/gnome/help that is owned by libgnome).
For this second issue, I was wondering what to do. I'm not really happy with having all packages owning the same directory, but it's bad to require libgnome too.
So maybe we should create a filesystem-gnome package that contain some common directories? There are quite some directories that could be there:
/usr/share/gnome /usr/share/gnome/help /usr/share/gnome/autostart /usr/share/omf /usr/share/gtk-doc /usr/share/icons/HighContrastLargePrint
I'm sure there are others...
Any opinion on this? And also, how would we have this package automatically installed? I wouldn't want to have all packages require it :/
Vincent
On Mon, 2009-01-26 at 15:48 +0100, Vincent Untz wrote:
Le lundi 26 janvier 2009, à 15:26 +0100, Vincent Untz a écrit :
I'll continue at some point this week, but people should feel free to finish the work ;-)
I forgot to mention -- a few packages fail to build. For some, it's only because it's an old version (gnome-utils, eg). For others, it's only a directory ownership issue (most probably on /usr/share/gnome/help that is owned by libgnome).
For this second issue, I was wondering what to do. I'm not really happy with having all packages owning the same directory, but it's bad to require libgnome too.
I must ask why it'd be bad? It would be a "BuildRequires" and not "Requires" and so unless a .so of the dependent package actually requires a .so provided by libgnome, it wouldn't be automatically pulled in by RPM either.
If libgnome is to be deprecated, then we need to create those directories in some other base GNOME package and ensure that libgnome has it in its list of BuildRequires.
So maybe we should create a filesystem-gnome package that contain some common directories? There are quite some directories that could be there:
/usr/share/gnome /usr/share/gnome/help /usr/share/gnome/autostart /usr/share/omf /usr/share/gtk-doc /usr/share/icons/HighContrastLargePrint
dunno about others, but
/usr/share/gtk-doc /usr/share/gtk-doc/html
are certainly meant to be owned by gtk-doc :-) Of the build failures I saw and other packages I just happened to observe, I added gtk-doc to BuildRequires and removed re-ownership of those directories.
-Suman
Le lundi 26 janvier 2009, à 21:22 +0530, Suman Manjunath a écrit :
On Mon, 2009-01-26 at 15:48 +0100, Vincent Untz wrote:
Le lundi 26 janvier 2009, à 15:26 +0100, Vincent Untz a écrit :
I'll continue at some point this week, but people should feel free to finish the work ;-)
I forgot to mention -- a few packages fail to build. For some, it's only because it's an old version (gnome-utils, eg). For others, it's only a directory ownership issue (most probably on /usr/share/gnome/help that is owned by libgnome).
For this second issue, I was wondering what to do. I'm not really happy with having all packages owning the same directory, but it's bad to require libgnome too.
I must ask why it'd be bad? It would be a "BuildRequires" and not "Requires" and so unless a .so of the dependent package actually requires a .so provided by libgnome, it wouldn't be automatically pulled in by RPM either.
Hrm, you also need the Requires, else the packages will fail to install. Or am I missing something? Also, removing the libgnome BuildRequires makes things build faster (because they don't have to wait for libgnome).
[...]
dunno about others, but
/usr/share/gtk-doc /usr/share/gtk-doc/html
are certainly meant to be owned by gtk-doc :-)
But you don't need gtk-doc installed to see the help in devhelp :-) So should it really be owned by gtk-doc?
Vincent
Hrm, you also need the Requires, else the packages will fail to install. Or am I missing something?
I'm pretty sure that a package that owns files/directories within a directory that doesn't exist will create that directory and it will simply be unowned by any installed package.
Also, removing the libgnome BuildRequires makes things build faster (because they don't have to wait for libgnome).
*That* is a good point, any metrics on the speed-up?
Le lundi 26 janvier 2009, à 16:50 +0000, James Ogley a écrit :
Hrm, you also need the Requires, else the packages will fail to install. Or am I missing something?
I'm pretty sure that a package that owns files/directories within a directory that doesn't exist will create that directory and it will simply be unowned by any installed package.
So, not clean if you remove the package. But not a huge deal either. I guess I prefer to have all packages own the directory ;-)
Also, removing the libgnome BuildRequires makes things build faster (because they don't have to wait for libgnome).
*That* is a good point, any metrics on the speed-up?
No metrics. But I wouldn't say it's 20% faster -- probably closer to 5%, (but it's actually hard to know since I don't have a close control on the build service ;-)). It just enables us to build more packages in parellel earlier.
Vincent
On Mon, 2009-01-26 at 15:48 +0100, Vincent Untz wrote:
Le lundi 26 janvier 2009, à 15:26 +0100, Vincent Untz a écrit :
I'll continue at some point this week, but people should feel free to finish the work ;-)
I forgot to mention -- a few packages fail to build. For some, it's only because it's an old version (gnome-utils, eg). For others, it's only a directory ownership issue (most probably on /usr/share/gnome/help that is owned by libgnome).
For this second issue, I was wondering what to do. I'm not really happy with having all packages owning the same directory, but it's bad to require libgnome too.
So maybe we should create a filesystem-gnome package that contain some common directories? There are quite some directories that could be there:
/usr/share/gnome /usr/share/gnome/help /usr/share/gnome/autostart /usr/share/omf /usr/share/gtk-doc /usr/share/icons/HighContrastLargePrint
I'm sure there are others...
Any opinion on this? And also, how would we have this package automatically installed? I wouldn't want to have all packages require it :/
Wouldn't it be enough to have gtk2 or glib2 depend on this new package (filesystem-gnome?). Or do we have any packages in need of those directories that also wouldn't need gtk2/glib2?
Cheers, Magnus
Le mardi 27 janvier 2009, à 06:07 +1100, Magnus Boman a écrit :
Any opinion on this? And also, how would we have this package automatically installed? I wouldn't want to have all packages require it :/
Wouldn't it be enough to have gtk2 or glib2 depend on this new package (filesystem-gnome?). Or do we have any packages in need of those directories that also wouldn't need gtk2/glib2?
Hrm. Example: gnome-doc-utils doesn't depend on either of those, and uses /usr/share/gnome/help
Vincent
On Mon, 2009-01-26 at 15:26 +0100, Vincent Untz wrote:
Hi all,
Over the past few days, I took some time to start merging G:F:N updates in G:F. Thanks a lot to the people who worked on G:F:N, it was a good way to stay updated with the latest versions.
Awesome. We should probably do a debrief about what worked and what didn't work once all packages have been merged so that we can do this better and faster next time.
The merge went fine overall. I took the opportunity to look at the packages closely, and fixed various other things (wrong BuildRequires, eg), sent various patches upstream (I was bad enough to not tag them in the spec files, though :/), dropped various old unneeded patches, etc.
There are only a few packages left. Here's a summary of why I left those packages:
=============== avahi: it's probably okay, but I'd love to have Stanislav double-check
devhelp: depends on webkit. I'm not sure the webkit we have right now is of good quality (it's quite old). So do we want this?
If there's a newer version of webkit, any reasons we can't update? Isn't upstream moving towards webkit for devhelp? What are the side effects of using it?
empathy: was looking at the updated empathy-lockdown.patch patch, and wondering if it had been sent upstream... Not really a blocker ;-)
evolution evolution-data-server evolution-exchange: too big for "osc rdiff", so I got lazy and ignored them for now
Good news; https://bugzilla.novell.com/show_bug.cgi?id=461729 (In short, check out osc from svn and it can rdiff without including tarballs)
gdm: I think it needs a manual merge (broken patch) Didn't look closer.
I have not had time to look at this but do we know what/how patches are broken for this and other packages? They all built nicely in G:F:N the last time I checked.
gnome-power-manager: requires devicekit-power
DeviceKit is in Factory. Hopefully we'll get DK-power in soon as well but upstream says that 2.24.x will be maintained for distros that don't have -power.
gstreamer-0_10-plugins-bad: legal status of the new plugins unclear
Who can/should sort this out?
libgda libgnomedb: I think it needs a manual merge (broken patch). Also I don't know if we can safely update to libgda 4 now?
Bad news is that Anjuta requires libgda4.
libsoup: it drops a patch but the upstream bug is still open with no clear resolution
I'll look at this one.
nautilus: I think it needs a manual merge (broken patch) Didn't look closer.
Same question as for gdm
gnome-packagekit PackageKit: would be good to have Scott look at this
system-config-printer: I want to take a closer look at the newer version to see if it's okay to update
I never got to split out the different python packages out of it either so needs to be done.
Cheers, Magnus
Le mardi 27 janvier 2009, à 06:02 +1100, Magnus Boman a écrit :
On Mon, 2009-01-26 at 15:26 +0100, Vincent Untz wrote:
devhelp: depends on webkit. I'm not sure the webkit we have right now is of good quality (it's quite old). So do we want this?
If there's a newer version of webkit, any reasons we can't update?
Not yet, afaik :/
Isn't upstream moving towards webkit for devhelp? What are the side effects of using it?
Upstream won't use webkit for 2.26 because it's not accessible. Maybe not a big deal for devhelp, though. Someone should just try the package and see how it works. If it works fine, then maybe it's okay to go ahead...
gdm: I think it needs a manual merge (broken patch) Didn't look closer.
I have not had time to look at this but do we know what/how patches are broken for this and other packages? They all built nicely in G:F:N the last time I checked.
There was a patch submitted to G:F that got accepted (same for nautilus). Wasn't a big deal.
I did the merge.
gstreamer-0_10-plugins-bad: legal status of the new plugins unclear
Who can/should sort this out?
Stanislav will probably know.
system-config-printer: I want to take a closer look at the newer version to see if it's okay to update
I did this merge too.
I never got to split out the different python packages out of it either so needs to be done.
Yep, something to do for 11.2.
Vincent
Le mardi 27 janvier 2009, à 06:02 +1100, Magnus Boman a écrit :
On Mon, 2009-01-26 at 15:26 +0100, Vincent Untz wrote:
libgda libgnomedb: I think it needs a manual merge (broken patch). Also I don't know if we can safely update to libgda 4 now?
Bad news is that Anjuta requires libgda4.
FWIW, we have a few packages not building because they still need libgda3. Maybe we should just create a libgda3 package? They are parallel installable.
libsoup: it drops a patch but the upstream bug is still open with no clear resolution
I'll look at this one.
I need libsoup to fix the gvfs build, so I investigated. The patch requires a gnutls patch that was dropped in the past. So, it's fine, I guess. I'll merge it.
Vincent
Hey, here's a small update.
The remaining packages are:
avahi dbus-1-glib devhelp gnome-packagekit gnome-power-manager gstreamer-0_10-plugins-bad libsoup PackageKit
I might do devhelp in a few minutes if I can test the package and it's okay for daily use.
Note that dbus-1-glib shouldn't have been submitted to G:F:N, but to home:thoenig:Factory since we don't use G:F:N anymore for now (we do stuff directly in G:F).
Also, I've disabled the builds on G:F:N to help the build service a bit. It wasn't really good to have it build stuff twice (in G:F and in G:F:N).
A few things are broken in G:F, but we're fixing them.
Vincent
On Thu, 2009-01-29 at 01:41 +0100, Vincent Untz wrote:
Hey, here's a small update.
The remaining packages are:
avahi dbus-1-glib devhelp gnome-packagekit gnome-power-manager gstreamer-0_10-plugins-bad libsoup PackageKit
Avahi has lot's of patches shouldn't we submit upstream ? Also g-p-m 2.25.x needs devicekit-disks are we make devicekit or stick with g-p-m 2.24 ?
Packagekit misses an important feature that is "canceling" is it possible to add on our zypper backend ?
A few things are broken in G:F, but we're fixing them.
Yes the status is "under developement" but i hope for 2.25.90 to have an usuable desktop.
Luis
On Thu, 2009-01-29 at 01:20 +0000, Luis Medinas wrote:
On Thu, 2009-01-29 at 01:41 +0100, Vincent Untz wrote:
Hey, here's a small update.
The remaining packages are:
avahi dbus-1-glib devhelp gnome-packagekit gnome-power-manager gstreamer-0_10-plugins-bad libsoup PackageKit
Avahi has lot's of patches shouldn't we submit upstream ? Also g-p-m 2.25.x needs devicekit-disks are we make devicekit or stick with g-p-m 2.24 ?
For now, we need to stick with g-p-m 2.24.x. We do have DK in the distro, but not DK-power yet.
Cheers, Magnus
Le jeudi 29 janvier 2009, à 01:20 +0000, Luis Medinas a écrit :
On Thu, 2009-01-29 at 01:41 +0100, Vincent Untz wrote: Avahi has lot's of patches shouldn't we submit upstream ?
I didn't look at the patches. Out of the 12 patches, 6 are removed with the new packages, though.
Also g-p-m 2.25.x needs devicekit-disks are we make devicekit or stick with g-p-m 2.24 ?
See Magnus' reply.
Packagekit misses an important feature that is "canceling" is it possible to add on our zypper backend ?
Hrm, isn't this orthognoal to updating things in G:F? ;-) I'd say file a bug about it.
Vincent
Final update: everything is now merged, except gstreamer-0_10-plugins-bad which is still waiting for someone who can do the review (difficult because of the legal stuff).
gnome-power-manager was not technically merged, but there were changes in G:F so the package there was broken, and we're still waiting for DeviceKit-power. We figured out it wouldn't be hard to just redo the update when we'll have DeviceKit-power.
Now next stop: the packaging day!
Vincent
Vincent,
On Mon, 2009-02-02 at 04:02 +0100, Vincent Untz wrote:
Final update: everything is now merged, except gstreamer-0_10-plugins-bad which is still waiting for someone who can do the review (difficult because of the legal stuff).
Awesome stuff! Thanks for spending all that time merging.
gnome-power-manager was not technically merged, but there were changes in G:F so the package there was broken, and we're still waiting for DeviceKit-power. We figured out it wouldn't be hard to just redo the update when we'll have DeviceKit-power.
Now next stop: the packaging day!
And also, I'd like to have a discussion about what was good/bad with using G:F:N while Factory was frozen. After all, the merge did take a bit longer than I think anyone expected (I do know that you did a whole lot more than only merging but if there's something we can improve next time around, we should talk about it)
Vincent
Cheers, Magnus
Le lundi 02 février 2009, à 14:50 +1100, Magnus Boman a écrit :
And also, I'd like to have a discussion about what was good/bad with using G:F:N while Factory was frozen. After all, the merge did take a bit longer than I think anyone expected (I do know that you did a whole lot more than only merging but if there's something we can improve next time around, we should talk about it)
Sure. So, what went wrong, on the review side:
+ not enough reviewers: - Novell people were too busy - no outsider yet. This can only improve, because we now have people contributing to packaging, and so they will gain experience.
+ reviewer stupid enough to fix various other things during the review (I upstreamed/removed patches, cleaned up various things, etc.) => this is actually the thing that took most of the time
+ non-necessary changes in the spec files that make the review harder. Changes like %configure -> %{configure} add to the noise (and I disagree with this change, but that's another topic ;-)). I don't think we should take G:F:N as an opportunity to clean up the packaging since this makes the review task harder. This should instead be done in G:F, when we don't update 100 packages at a time.
+ patches that were removed from spec file, but not from the build service. Well, not just patches. Files in general.
+ incomplete .changes. It's important to know when a patch is updated/add/removed, and why. It's also important to know why this thing in the packaging was changed. A good .changes entry is a good way to make the review much faster. (FWIW, I'm in no way doing perfect .changes entry either, but I'm trying to force myself to document everything and avoid vague statements like "Clean up everything" -- something I used to do a lot ;-))
+ fwiw, having the upstream changes in .changes helps here. Eg, I can quickly see if upstream had a new feature that requires some new dependency or new flag this way. So, painful for the packager, helpful for the reviewer.
+ should have had reviews at the beginning: the common mistakes that were done in many packages (don't ask me what now ;-)) could have been avoided if highlighted after the first submissions
On the packaging side:
+ new packages in Factory that broke stuff. There were two main things that usually broke: - Release tag. Not sure we can do anything there, since the Version tag is one line above, so we'll have a conflict. - .changes files. A potential solution here is to use another file for the .changes entry. Like gnome-panel.changes.next. Don't know. The build service could be more helpful there...
+ anything else?
Those are the obvious things.
-
James Ogley -
Luis Medinas -
Magnus Boman -
Suman Manjunath -
Vincent Untz