On 04/14/2011 10:04 PM, Hans-Peter Jansen wrote:
On Thursday 14 April 2011, 18:53:28 Stephan Kleine wrote:
On Wednesday April 13 2011 20:52:09 Hans-Peter Jansen wrote:
On Wednesday 13 April 2011, 19:18:03 Stephan Kleine wrote:
On Tuesday April 12 2011 23:36:45 peer wrote:
On 04/12/2011 10:56 PM, Adrian Schröter wrote:
Am Dienstag, 12. April 2011, 22:38:17 schrieb Peter Linnell:
> On 04/12/2011 10:19 PM, Adrian Schröter wrote: > >> Am Dienstag, 12. April 2011, 21:54:56 schrieb Peter Linnell: >> >>> On 04/02/2011 09:51 PM, peer wrote: >>> >>>> On 04/02/2011 08:20 PM, Stephan Kleine wrote: >>>> >>>>> On Saturday April 2 2011 19:13:48 you wrote: >>>>> >>>>>>> Here is the bug report >>>>>>> >>>>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=62035 >>>>>>> 0 >>>>>>> >>>>>> Well, it is obvious that the debian folks don´t care >>>>>> about anything outside >>>>>> their ivory tower. I meant filing a bug at the cdbs >>>>>> upstream that their build scripts are broken cause >>>>>> being unable to build in parallel _is_ a bug IMHO, so >>>>>> they would perhaps fix this. >>>>>> >>>>> Er, sry, I forgot what cdbs is, seems like you are >>>>> screwed ;P >>>>> >>>>> But more seriously, not doing the builds in parallel is >>>>> just a waste of time >>>>> and resources and debian& buntu builds already take >>>>> much longer than rpm builds (e.g. during package >>>>> install) so disabling parallel builds to please >>>>> some broken packages isn't an option imho. Simply wait >>>>> till a way to disable >>>>> them in the packages meta data is implemented and fix it >>>>> in the meantime by >>>>> adding "-j1" to your make call. >>>>> >>>> You didn't read the reply by the author well. The package >>>> is not broken, it's a choice to have the package like it >>>> is. That's why it's not a accident that it fails on obs >>>> and not on the Debian, Ubuntu and Launchpad build >>>> systems. They doesn't violate the Debian policy and I >>>> think that's a good choice. That's also why the cdbs >>>> author argues that obs is broken, not the package and I >>>> do agree with him here. >>>> >>>> It's fundamentally wrong imo to provide a service for >>>> Debian packages and not accept the Debian way and the >>>> Debian policy. Of course you could discuss the way of >>>> building with the Debian devs and try to convince them >>>> (at least the cdbs author seems to be open for a rational >>>> discussion). But at the end the best thing a service for >>>> Debian packages can do, it to adapt to the Debian way. >>>> Then we as users are assured that we don't need all kinds >>>> of hacks to get our Debian packages build. >>>> >>>> >>>> ~P >>>> >>> I read the Debian policy carefully and nothing there it >>> seems _prohibits_ parallel building. >>> >>> Quote: >>> >>> "parallel=n >>> >> Where is this set exactly ? >> >> We can parse that maybe in build script and limit it to >> "n". Or take the dpkg tools already care of that ? >> > http://www.debian.org/doc/debian-policy/ch-source.html#s-deb > ianr > > ules-opt ions Section 4.9.1 > okay, so it seems that the packages really need to get fixed debian/rules file to avoid the usage of parallel builds too me. (similar as in spec files where the macro must not be used).
Thanks for digging into it. adrian
Enabling parallel building via DEB_BUILD_OPTIONS, parallel=n seems to be the proper way to enable parallel building on Debian. But if this is not set by the package maintainer, obs shouldn't build the package in parallel, because that would violate the Debian policy.
~P
No, make it the other way round. Until explicitly disabled in the packages meta data build the stuff in parallel since .deb builds already waste enough time during package installation and most people probably will never know or care to enable parallel builds for working packages.
And if they choose to punish themself, why not meet their policy, but simply penalize those non parallel builds in the scheduler adequately in order to lower burden of other BS users.
Guess, how fast the self-healing power will change this silly situation.
Again, because that "policy" is screwing over everyone else cause the .deb builds already waste loads of time (e.g. the package installation takes considerable longer than on rpm based distros) so anything that makes .deb builds faster is plain awesome in my book.
Also the majority of the packages should "just work" when build in parallel because - again - the only reason that wouldn't work is because the packages build scripts have a bug in the first place.
So please explain me why everyone else should get punished and time get wasted just cause a handful of people happen to want to build broken packages they refuse to fix?
So simply fix your packages build scripts and send the patch upstream or implement some option to turn of parallel builds in the packages meta data or wait till someone else does it for you but stop punishing everyone cause your stuff is broken and you refuse to fix it.
Stephan, you probably misunderstood me. Given, debian require BS to build their stuff with a single CPU by default, no problem, just penalize these builds in the scheduler by _lowering_ their priority with _factor_ 10 (est. avg. 6 CPUs, e.g. estimated to hog a build node 10 times longer than other projects packages, iow. 10 RPM builds and then one "single CPU" debian build).
Result: bigger debian builds will take ages, but this is exactly, what they _demand_¹. debian packagers, that run off their patience will try to solve this by enabling parallel builds in their packages.
The idea is, that debian packagers stop being jobworths, and start fixing their issues for their own sake and the rest of us doesn't suffer from debian project policy silliness too much.
This is not about punishment, it's about fairness and raising the attraction to fix this with self-healing power.
Hopefully, I expressed myself better this time, Pete
¹) Well, not exactly, but OTOH this scheduler penalization does work pretty well: before Stephan Kulow fixed this, I remember having packages hanging around in scheduled state for several _days_! Enough time for them to think about solutions to the problem.
This doesn't sounds like an constructive and adult way to solve these issues. You harm the end-users because of something they have little influence on. People use obs just to publish packages for their projects. They aren't necessarily Debian developers themselves. The real Debian developers do prefer other services instead of obs, so they won't be impressed or forced to change their policy at all. At the end you only hurt the end-user of obs who likes to publish Ubuntu | Debian packages via obs. If you slow down the build process of Debian packages heavily, the only thing you achieve is that people like me are forced to choose other services like Launchpad. I personally prefer obs, but this discussion doesn't make me feel that obs really cares about the Debian based projects and it makes me wonder why it even provide the option to build for Debian. Best regards, ~P -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org