On 04/05/2010 12:28 PM, Cristian Morales Vega wrote:

2010/4/5 Dave Plater :

...

I don't know if it was intentional but libpng-devel is no longer provided in factory. There is libpng14-compat-devel from the libpng14 package and from the libpng12 package : libpng12-compat-devel and libpng12-devel. I'm not really sure what's going on but I do know that the lack of libpng-devel is causing a major blockage in some major packages ie. libqt4, cairo and cups to name the ones that are blocking packages I'm trying to fix but I think a large portion of packages depend on them. Maybe libpng12-devel should provide libpng-devel but libpng12.so.0 also seems to be missing. Can somebody with a bit more experience in this have a look, when I investigated yesterday I could have sworn that I saw libpng14-compat-devel in at least one of the above packages spec files so maybe the problem's already being worked on.

- "libpng-devel" is provided by libpng14-compat-devel

$ osc cat openSUSE:Factory/libpng14/libpng14.spec | grep -B5 'Provides:[[:space:]]*libpng-devel' %package compat-devel License: Zlib License Group: Development/Libraries/C and C++ Summary: Development Tools for applications which will use the Libpng Requires: libpng%{branch}-devel = %{version} Provides: libpng-devel = %{version}

- It is also provided by libpng12-compat-devel, but

$ osc meta prjconf openSUSE:Factory | grep libpng1[24]-compat-devel Prefer: libpng14-compat-devel

Your problem is that multimedia:apps uses spapshot instead of standard

$ osc meta prj multimedia:apps | fgrep -A3 openSUSE_Factory <repository name="openSUSE_Factory"> <path repository="openSUSE_Factory" project="multimedia:libs"/> <path repository="snapshot" project="openSUSE:Factory"/> <arch>x86_64</arch> <arch>i586</arch>

and libpng14-compat-devel is built for standard but not for snapshot

$ osc ls -b openSUSE:Factory libpng14 ... snapshot/x86_64 snapshot/i586 staging/ppc staging/x86_64 staging/i586 standard/i586 libpng14-1.4.1-1.1.src.rpm libpng14-14-1.4.1-1.1.i586.rpm libpng14-14-debuginfo-1.4.1-1.1.i586.rpm libpng14-compat-devel-1.4.1-1.1.i586.rpm libpng14-compat-devel-32bit-1.4.1-1.1.x86_64.rpm libpng14-debugsource-1.4.1-1.1.i586.rpm libpng14-devel-1.4.1-1.1.i586.rpm libpng14-devel-32bit-1.4.1-1.1.x86_64.rpm standard/x86_64 libpng14-1.4.1-1.1.src.rpm libpng14-14-1.4.1-1.1.x86_64.rpm libpng14-14-debuginfo-1.4.1-1.1.x86_64.rpm libpng14-compat-devel-1.4.1-1.1.x86_64.rpm libpng14-debugsource-1.4.1-1.1.x86_64.rpm libpng14-devel-1.4.1-1.1.x86_64.rpm ...

Probably because before there was only a "libpng" package that has been substituted by "libpng12" and "libpng14", and still there has not been an opportunity for the new packages to be built for snapshot.

No idea about when the next snapshot is planned (snapshots are milestones? if so Apr 09, for Milestone 5), but since projects as multimedia:apps use it could be a good idea to make it soon.

I've maintainer rights for multimedia:apps and libs so I could simply make it build from standard but not wanting to mess anything up could you see any problems arising if I do? Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Mon, 5 Apr 2010, Dave Plater wrote:

On 04/05/2010 12:51 PM, Dave Plater wrote:

...

I've maintainer rights for multimedia:apps and libs so I could simply make it build from standard but not wanting to mess anything up could you see any problems arising if I do? Thanks Dave P

I was brave (or reckless) and made it build from standard,

Note that this will make multimedia:apps rebuild much more often than usually necessary. This is because standard/ always contains the just rebuilt packages from openSUSE:Factory, whereas snapshot/ contains the packages from standard/ copied over when the latter was built through (or at some other point). I.e. snapshot/ changes less frequently than standard/ . That's usually the desired mode, except, as you now noted, some build or runtime dependency chain is changed, which needs some time to propagate into snapshot/ although it's already solved in standard/ . So, to get work done it's indeed okay to temporarily switch to standard/ as base repo, ...

the 49 blocked packages are now building, I'll switch back to snapshot when M5 is released.

... but in the interest of build power (and download bandwidth for users of your repo), please don't forget to switch back to snapshot/ when the problem has solved itself there (by copying over from standard/). Ciao, Michael. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org

Hi, On Tue, 6 Apr 2010, Adrian Schröter wrote:

...

Note that this will make multimedia:apps rebuild much more often than usually necessary. This is because standard/ always contains the just

It can be also the opposite, building against standard can lead to the blocked state, if it is currently building. While building against snapshot/ may trigger on each change in your project (source or binary changes).

Huh? Changes in your project will cause rebuild requests no matter what base repo you build against. Or at least they ought to.

...

So, to get work done it's indeed okay to temporarily switch to standard/ as base repo, ... ... ... but in the interest of build power (and download bandwidth for users of your repo), please don't forget to switch back to snapshot/ when the problem has solved itself there (by copying over from standard/).

That is too simple and depends on the work pattern. You may trigger more builds with snapshot/ depending on it.

How could this happen?

standard/ is still the recommended default target.

Priorisation of the builds needs to be handled from us on the server side in any case.

It's always better to have fewer rebuild trigger requests, no matter how clever the priorisation is, so I don't get what you're trying to say. Building against snapshot/ should never generate more rebuild requests, than building against standard/, except if the copying from standard/ to snapshot/ is buggy. Ciao, Michael.

Hi, On Tue, 6 Apr 2010, Adrian Schröter wrote:

...

...

...

Note that this will make multimedia:apps rebuild much more often than usually necessary. This is because standard/ always contains the just

It can be also the opposite, building against standard can lead to the blocked state, if it is currently building. While building against snapshot/ may trigger on each change in your project (source or binary changes).

Huh? Changes in your project will cause rebuild requests no matter what base repo you build against. Or at least they ought to.

No, when for example glibc in openSUSE:Factory/standard is building, all builds, indedepend of the project are in blocked state.

Yes, and? As soon as that glibc is finished all packages which were in blocked are then going to be rebuilt. Not different from when if the snapshot/ glibc was changed (for project building against snapshot/). Changes or no changes to your project don't even enter the picture. Could you please answer the remaining questions of my mail?

No bug, works as designed and wanted :)

But you fail to answer _what_ was designed and wanted. Probably we're talking past each other: I'm not at all interested in the blocked state, that's something you brought into the picture, but I still don't know why. I'm exclusively talking about the raw number of package rebuilds (and I claim they will be fewer when building against snapshot/ vs. standard/; you seem to disagree with that, and I want to know how my claim can be wrong). Ciao, Michael.

Hi, On Tue, 6 Apr 2010, Adrian Schröter wrote:

...

...

No bug, works as designed and wanted :)

But you fail to answer _what_ was designed and wanted. Probably we're talking past each other: I'm not at all interested in the blocked state, that's something you brought into the picture, but I still don't know why. I'm exclusively talking about the raw number of package rebuilds (and I claim they will be fewer when building against snapshot/ vs. standard/; you seem to disagree with that, and I want to know how my claim can be wrong).

The blocked state prevents us from building only shortly needed packages.

you can avoid building packages (because multiple source changes or other indirect build triggers like binary builds of packages in the build dependencies) via the blocked state.

Um, yes, of course. But if someone does multiple source changes to the same package in a row (i.e. something that's purely under his control), without intermediate builds (i.e. he doesn't test each source change), and he indeed _doesn't want_ those intermediate builds (i.e. he relies on the slowness of standard/ to prevent those multiple builds because the package remains in blocked for a long time because of some indirect dependency) then he is stupid. He simply should not have done multiple source changes if he doesn't want multiple rebuilds. Now if he does changes in the project on multiple packages (A,B,C) which might be BuildReqs for package X, then depending on how quick he is with committing the A/B/C changes X will be rebuilt multiple times. But that is the case no matter if he builds against snapshot/ or standard/ . So far about direct build triggers (source or project changes). As for indirect build triggers: these are changes in the base project. standard/ changes more often than snapshot/ (this is true, isn't it?), hence building against snapshot/ will rebuild your projects packages less often for indirect reasons.

So, when you say you build less often packages in your project in general by selecting "snapshot" over "standard" this is not true. It depends a lot on how the trigger pattern is in your project and in openSUSE:Factory.

The way I see it, there are either triggers caused by the base project, or triggers caused by the project itself, and no other type of triggers (let's ignore manual triggers). The base-project triggers are strictly fewer with snapshot/ , and the project-local triggers are exactly the same. Why do you think different? Ciao, Michael.

Am Dienstag 06 April 2010 schrieb Adrian Schröter:

standard/ is still the recommended default target.

Haem, this is simply not true. snapshot is the default for openSUSE:Factory since quite a long time. And the fact alone that your published packages will very likely matches what's factory on download.opensuse.org makes the right default. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org