On Wed, 2009-06-17 at 14:27 +0200, Stephan Kulow wrote:

My current plan is to put SUSE_ASNEEDED=0 in all packages failing atm and then leave it to the packagers to take out and fix on their own schedule.

http://www.suse.de/~coolo/asneeded has the logs I greped out - as soon as suse.de syncs again. Be patient in the next minutes :)

Greetings, Stephan

Maybe it's a good idea filling bugs to maintainers so they can be aware of this problem. It's good to know the number of packages failing is very low. Luis (metalgod) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 17/06/09 09:01, Stephan Kulow wrote:

I don't think it's a bug if a package doesn't work out of the box with different linker flags.

Why not ? most of the build failures are bugs, packages use wrong linking order... I think that qualifies as a bug. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wed, Jun 17, 2009 at 03:01:52PM +0200, Stephan Kulow wrote:

...

Maybe it's a good idea filling bugs to maintainers so they can be aware of this problem. I don't think it's a bug if a package doesn't work out of the box with different linker flags.

I think the opposite way. Being involved in Wireshark development I have to go and check all the big distros for changes made, find out why and by whom and then apply what appears to be useful. <rant> It's *really* annoying! Why can't the package maintainers open a bug with Wireshark for every patch that isn't 100% distro specific and let the project maintainers decide what is acceptable and what isn't? While I'm ranting anyway: Each and every patchfile that is part of a source package should contain a description and information on the author(s) - how am I supposed to give credit correctly otherwise when I decide that a patch is useful? Normally figuring out the credits part is more work than finding out whether to apply a patch or not. </rant> Ciao Joerg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thu, Jun 18, 2009 at 06:39:27PM +0200, Cristian Morales Vega wrote:

2009/6/18 Joerg Mayer :

...

On Wed, Jun 17, 2009 at 03:01:52PM +0200, Stephan Kulow wrote:

...

...

Maybe it's a good idea filling bugs to maintainers so they can be aware of this problem. I don't think it's a bug if a package doesn't work out of the box with different linker flags.

I think the opposite way. Being involved in Wireshark development I have to go and check all the big distros for changes made, find out why and by whom and then apply what appears to be useful. <rant> It's *really* annoying! Why can't the package maintainers open a bug with Wireshark for every patch that isn't 100% distro specific and let the project maintainers decide what is acceptable and what isn't?

Seriously? Because I think "now I will have to open an account in its bug tracker and...". When I'm not busy I report upstream, but when I have anything else to do the last thing I want is open yet another account in yet another bug tracker.

OH, now that's an interesting approach: You need to track upstream, so you have to spend quite a bit of time following that stuff, e.g. subscribe to the relevant mailing lists, find out the svn address, but you cannot be bothered to take the one time effort (per project that you maintain) to open an account?

My fault, but... perhaps OpenID will make people report more to upstream.

...

While I'm ranting anyway: Each and every patchfile that is part of a source package should contain a description and information on the author(s) - how am I supposed to give credit correctly otherwise when I decide that a patch is useful? Normally figuring out the credits part is more work than finding out whether to apply a patch or not. </rant>

I don't really mind about getting credit for some minor patches. But I suppose it's important to upstream because of legalities. Anyway, Wireshark 1.2.0 builds with --as-needed because of the new behavior in binutils, but it still has a problem that triggers if you use pre-2.20 binutils. The patch is available at https://build.opensuse.org/package/view_file?file=wireshark-1.2.0-asneeded.patch&package=wireshark&project=openSUSE%3AFactory and I'm the author.

Now you're really funny: In order to access that URL I need to create an account ..... But what I was really complaining about is that there doesn't seem to be any requirement to put the necessary information directly into the patches. Ciao Joerg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/6/19 Joerg Mayer :

On Thu, Jun 18, 2009 at 06:39:27PM +0200, Cristian Morales Vega wrote:

...

2009/6/18 Joerg Mayer :

...

On Wed, Jun 17, 2009 at 03:01:52PM +0200, Stephan Kulow wrote:

...

...

Maybe it's a good idea filling bugs to maintainers so they can be aware of this problem. I don't think it's a bug if a package doesn't work out of the box with different linker flags.

I think the opposite way. Being involved in Wireshark development I have to go and check all the big distros for changes made, find out why and by whom and then apply what appears to be useful. <rant> It's *really* annoying! Why can't the package maintainers open a bug with Wireshark for every patch that isn't 100% distro specific and let the project maintainers decide what is acceptable and what isn't?

Seriously? Because I think "now I will have to open an account in its bug tracker and...". When I'm not busy I report upstream, but when I have anything else to do the last thing I want is open yet another account in yet another bug tracker.

OH, now that's an interesting approach: You need to track upstream, so you have to spend quite a bit of time following that stuff, e.g. subscribe to the relevant mailing lists, find out the svn address, but you cannot be bothered to take the one time effort (per project that you maintain) to open an account?

I don't mantain many packages, I'm more the random patch guy. But as I already said "my fault"... I was giving an explanation, not a justification. Why the mantainer doesn't submits upstream the patches I submit to him? Well, he probably thinks I already did.

...

My fault, but... perhaps OpenID will make people report more to upstream.

...

While I'm ranting anyway: Each and every patchfile that is part of a source package should contain a description and information on the author(s) - how am I supposed to give credit correctly otherwise when I decide that a patch is useful? Normally figuring out the credits part is more work than finding out whether to apply a patch or not. </rant>

I don't really mind about getting credit for some minor patches. But I suppose it's important to upstream because of legalities. Anyway, Wireshark 1.2.0 builds with --as-needed because of the new behavior in binutils, but it still has a problem that triggers if you use pre-2.20 binutils. The patch is available at https://build.opensuse.org/package/view_file?file=wireshark-1.2.0-asneeded.patch&package=wireshark&project=openSUSE%3AFactory and I'm the author.

Now you're really funny: In order to access that URL I need to create an account .....

But what I was really complaining about is that there doesn't seem to be any requirement to put the necessary information directly into the patches.

There is: http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.15._Patch_Tag, but... I think I have NEVER found a name in an openSUSE patch. Few times an explanation. There is also http://en.opensuse.org/GNOME/Patches, that I don't know why it's under GNOME. But in general (perhaps it's better for Gnome packages) isn't very respected. ...someone feels like creating some rpmlint checks? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri, 2009-06-19 at 01:46 +0200, Cristian Morales Vega wrote: [...]

There is also http://en.opensuse.org/GNOME/Patches, that I don't know why it's under GNOME. But in general (perhaps it's better for Gnome packages) isn't very respected.

...someone feels like creating some rpmlint checks?

The GNOME team uses these tags to keep track of what patches etc we have. The result of properly tagging our patches can be seen at http://tmp.vuntz.net/opensuse-packages/patch.py We also do rpmlint checks on our packages, which can be found at http://tmp.vuntz.net/opensuse-packages/rpmlint.py Cheers, Magnus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/6/17 Stephan Kulow :

Am Mittwoch 17 Juni 2009 schrieb Cristian Morales Vega:

...

2009/6/17 Stephan Kulow :

...

So I would like to hear feedback on this. We have an alternative of course: leaving binutils as it is and only set SUSE_ASNEEDED=1 in packages where we expect real benefits. Or we set SUSE_ASNEEDED=0 in all packages creating a build problem and you guys say we test enough to make as-needed useful.

If there are a Iot of build fails I would make a full Factory build with SUSE_ASNEEDED=1 and create an openSUSE:Factory:asneeded project similar to openSUSE:Factory:Gcc44 with a link to the packages that failed (with the build log, not sure if that would require an additional build). If there is real interest I would expect those packages (or the library packages they depend on with the real problem) to be fixed for 11.2 release. If so, set SUSE_ASNEEDED=1 again for all post-11.2 Factory builds and we will have all the 11.3 development time to find and fix the packages that build but with problems... plus any new build fail, but I don't really expect any package build starting to fail because of --as-needed between now and 11.2 release. Meanwhile one could put a ban to SUSE_ASNEEDED=1 for packages that contain libraries (or allow it only with also "--no-allow-shlib-undefined") but allow each packager to set SUSE_ASNEEDED=1 for his packages with only executables if they want to.

I would really like to have the full distro building with --as-needed, call it a personal obsession. I had some free time recently and I have submitted a few patches to fix packages that failed with --as-needed... a few because they were all I knew. Having a list of problematic packages would be really helpful.

My current plan is to put SUSE_ASNEEDED=0 in all packages failing atm and then leave it to the packagers to take out and fix on their own schedule.

Between, where SUSE_ASNEEDED should be setted? Not really sure about what I can put in the package/project metadata in the BS and how should be setted ("export SUSE_ASNEEDED=1"?).

http://www.suse.de/~coolo/asneeded has the logs I greped out - as soon as suse.de syncs again. Be patient in the next minutes :)

MozillaThunderbird buildlog 16,4MiB?? Ok...will be the last one ;-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Robert Kaiser schrieb:

/me giggles.

:-(

Could have sworn our palette of Mozilla apps (MozillaFirefox, MozillaThunderbird, seamonkey) was on that list - and I'm right! :P

I wonder though if we should move to Thunderbird 3.0 Beta and SeaMonkey 2.0 Alpha/Beta builds for Factory though, from all we hear those are not really less stable than the Thunderbird 2 and SeaMonkey 1.1 "stable" versions, but catch up with Firefox 3.5 code-wise (could help with this -as-needed stuff perhaps) and both should release finals before openSUSE 11.2 goes gold.

Wolfgang as OBS package manager for Mozilla builds may have some input into that, I guess.

Yes ;-) Actually I'm waiting impatiently for a Thunderbird 3.0b3 release to put it into Factory. Putting 3.0b2 there would just be too old and a nightly breaks far too many locales to have it in Factory IMHO. Almost the same for SeaMonkey while there is the difference that I didn't care yet to add a locale package anyway so updating to a current nightly would be possible. That's more a decision I'd like to proxy to you Robert as SeaMonkey project lead. If you'd like to see SeaMonkey 2.0a/b earlier than later in Factory I'm fine with it. Just let me know. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wednesday 17 June 2009 22:55:57 Robert Kaiser wrote:

That said, I think that current SeaMonkey 2.0b1pre nightlies are almost as stable as 1.1.x but significantly better not only in functionality but also is compatibility with today's operating systems. I think it's definitely worth to put that code into Factory.

Will we see releases of SeaMonkey and Thunderbird in time for 11.2? In that case, I agree with moving forward, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Thursday 18 June 2009 10:34:08 Wolfgang Rosenauer wrote:

Andreas Jaeger schrieb:

...

On Wednesday 17 June 2009 22:55:57 Robert Kaiser wrote:

...

That said, I think that current SeaMonkey 2.0b1pre nightlies are almost as stable as 1.1.x but significantly better not only in functionality but also is compatibility with today's operating systems. I think it's definitely worth to put that code into Factory.

Will we see releases of SeaMonkey and Thunderbird in time for 11.2? In that case, I agree with moving forward,

According to http://en.opensuse.org/Roadmap/11.2 we are talking about: Sun, Aug 02 openSUSE 11.2 Milestone 5 Release as "Feature and version freeze for the complete distribution".

"Patch level update of leaf-packages" applies for sure for SeaMonkey (I doubt it's on the media) and might as well for Thunderbird - which would make a deadline of 18th of August.

I'm not quite sure if we will have final releases at that point but it could still make sense to ship what is the latest beta then.

So, what is the planned final release? And then let's discuss with Coolo, Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Thursday 18 June 2009 13:32:09 Robert Kaiser wrote:

Andreas Jaeger wrote:

...

On Wednesday 17 June 2009 22:55:57 Robert Kaiser wrote:

...

That said, I think that current SeaMonkey 2.0b1pre nightlies are almost as stable as 1.1.x but significantly better not only in functionality but also is compatibility with today's operating systems. I think it's definitely worth to put that code into Factory.

Will we see releases of SeaMonkey and Thunderbird in time for 11.2? In that case, I agree with moving forward,

Two months ago I would have said "we'll surely make August" for both. With the recent pushing out of things I'm not completely sure. As we very probably will stop maintaining Thunderbird 2.x and SeaMonkey 1.x well before the maintenance period of 11.2 ends, and given the stability that testers of development builds are seeing in current Thunderbird 3.0 and SeaMonkey 2.0 pre-releases I think it would even be better to ship betas of them with 11.2 than so-called "stable" versions of the old series. It's unfortunate that we don't have finals of the new versions right now, then this would be very much easier, that's for sure.

Coolo's call in this case - and I support the proposal to go to the new versions and ship them even as betas if needed (and consider updating them via online update after release). But this is quite an exception! Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Stephan Kulow schrieb:

Am Donnerstag 18 Juni 2009 schrieb Andreas Jaeger:

...

Coolo's call in this case - and I support the proposal to go to the new versions and ship them even as betas if needed (and consider updating them via online update after release). But this is quite an exception!

Exception on what base? Sorry, rules are rules and the 11.2 window really is large enough not to need exceptions for the case of it. And of course development versions have less testers, so there will always be less bugs in the development version than in the released version.

Ok, I don't care too much as the need for having to rely on openSUSE "base" is declining. Anyway could you please point me to the rules you are referring to? So to make that clear one more time we are talking about updating MozillaThunderbird and seamonkey to beta versions in worst case before openSUSE will enter feature freeze. Either we do that and allow beta versions what we did pretty often in the past (especially by introducing alpha quality package management which obviously wasn't named alpha or beta) or the other alternative would be to drop MozillaThunderbird and seamonkey from Factory _now_ as I'm pretty sure that security support will be completely stopped once Thunderbird 3 and seamonkey 2 got released as it's already only limited support since Firefox 2 went out of maintenance upstream. I would choose the former but if that's not possible I would choose the latter (if I were you or your security team). Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Thursday 18 June 2009 14:03:06 Stephan Kulow wrote:

Am Donnerstag 18 Juni 2009 schrieb Andreas Jaeger:

...

Coolo's call in this case - and I support the proposal to go to the new versions and ship them even as betas if needed (and consider updating them via online update after release). But this is quite an exception!

Exception on what base? Sorry, rules are rules and the 11.2 window really is large enough not to need exceptions for the case of it. And of course development versions have less testers, so there will always be less bugs in the development version than in the released version.

I would ship these as betas based on the comments that Robert made regarding stability. We can either freeze in August - or later. Or we freeze in August and update at some time to the final version. Andreas -- Andreas Jaeger, Director Platform / openSUSE, aj@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Wednesday 17 June 2009 07:27:03 am Stephan Kulow wrote:

Am Mittwoch 17 Juni 2009 schrieb Cristian Morales Vega:

...

2009/6/17 Stephan Kulow :

...

So I would like to hear feedback on this. We have an alternative of course: leaving binutils as it is and only set SUSE_ASNEEDED=1 in packages where we expect real benefits. Or we set SUSE_ASNEEDED=0 in all packages creating a build problem and you guys say we test enough to make as-needed useful.

If there are a Iot of build fails I would make a full Factory build with SUSE_ASNEEDED=1 and create an openSUSE:Factory:asneeded project similar to openSUSE:Factory:Gcc44 with a link to the packages that failed (with the build log, not sure if that would require an additional build). If there is real interest I would expect those packages (or the library packages they depend on with the real problem) to be fixed for 11.2 release. If so, set SUSE_ASNEEDED=1 again for all post-11.2 Factory builds and we will have all the 11.3 development time to find and fix the packages that build but with problems... plus any new build fail, but I don't really expect any package build starting to fail because of --as-needed between now and 11.2 release. Meanwhile one could put a ban to SUSE_ASNEEDED=1 for packages that contain libraries (or allow it only with also "--no-allow-shlib-undefined") but allow each packager to set SUSE_ASNEEDED=1 for his packages with only executables if they want to.

I would really like to have the full distro building with --as-needed, call it a personal obsession. I had some free time recently and I have submitted a few patches to fix packages that failed with --as-needed... a few because they were all I knew. Having a list of problematic packages would be really helpful.

My current plan is to put SUSE_ASNEEDED=0 in all packages failing atm and then leave it to the packagers to take out and fix on their own schedule.

http://www.suse.de/~coolo/asneeded has the logs I greped out - as soon as suse.de syncs again. Be patient in the next minutes :)

Greetings, Stephan

Not that I have a lot of input on build intricacies, but I whole heartedly agree with Stephan here. Time needs to be allowed for the development of 11.2 to "Settle" in the short amount of time between now and release so a clean up of the bugs in the packages can take place without introducing new ones with asneeded. Regardless of how much manpower is dedicated to rushing-pushing-tinkering and changing every package to build with asneeded between now and 11.2 release, reality says you will be chasing asneeded bugs all the way up to the release date and then bandaiding packages at the last minute to press DVD's and inevitably then many unintended consequences of the asneeded rush won't show up until after the DVD's are pressed because the state of build process wasn't frozen (asneeded=0/asneeded=1) long enough before release to allow adequate testing to minimize the number of "Oopses" in the final product. If adequate time isn't allowed for simply ironing out the packages with their current build procedure, I think you are just setting yourselves up for failure and being caught short on time to get it all done. Personally, I would like to see 11.2 be a clean release without 1.2G of package updates within the first 30 days of release needed to fix problems that would have been avoided if a smarter and more conservative approach to getting 11.2 DVD ready had been taken. There is only so much that can be done. The decision to freeze/decide upon the build process for packages seems like something that needs to happen yesterday so the cleanup can begin. Just my .02 that applies to any large undertaking whether writing code or changing APU turbine speed sensors on the shuttle. (there are 3 per turbine if you are interested)(Manufactured by Sunstrand) -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Saturday 20 June 2009 04:41:52 am Cristian Morales Vega wrote:

We all agree that "enough time" is needed to test changes... but nobody agrees about how much is "enough time". That's why we have a project manager... to bother him about changes we want even if there is no time and blame him about other changes that got done without time ;-)

IMHO, we should be conservative with this release to avoid experience with few previous. There is no better marketing than good release. -- Regards, Rajko http://news.opensuse.org/category/people-of-opensuse/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Sat, Jun 20, 2009 at 08:45:56PM -0500, Rajko M. wrote:

On Saturday 20 June 2009 04:41:52 am Cristian Morales Vega wrote:

...

We all agree that "enough time" is needed to test changes... but nobody agrees about how much is "enough time". That's why we have a project manager... to bother him about changes we want even if there is no time and blame him about other changes that got done without time ;-)

IMHO, we should be conservative with this release to avoid experience with few previous. There is no better marketing than good release.

With the opening of Factory to the community you might find it not as conservative as you would like, with all new workflows, processes and package acceptance strategies and so on. as-needed fixes will be just a minor hickup compared to that. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org