Re: Packages getting marked not-for-us
On Thu, Aug 07, 2008 at 04:06:50PM -0400, Roberto C. S?nchez wrote: On Thu, Aug 07, 2008 at 09:57:49PM +0200, Petter Reinholdtsen wrote: I would rather have maintainers spend time improving their packages instead of wasting it trying to figure out why some architecture fail/refuses to build their package. In some (many?) cases that leads to direct improvement of the package. I have had a package quit building on a particular architecture and it ended revealing itself as a problem with something in the build system All of which would go a lot better if the maintainer were told about whatever issue caused the buildd to be configured not to build the package rather than having to discover that this has happened and infer the reasoning for the decision. Also note that this discussion is about the buildds being configured to not even try compiling a package, not about build failures encountered on the buildds. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
Petter Reinholdtsen [EMAIL PROTECTED] writes: [Matthew Johnson] Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... I agree. Perhaps a new rule should be introduced, that when a porter flag a package as NFU on a given architecture, he should be required to file a removal request for the binaries on that architecture too, and CC the package maintainer to let the maintainer know about the decision. Silently flagging packages as NFU on a given architecture do not seem like a good idea, and expecting the maintainer to ask for removal without letting the maintainer know that the porter refuses to build a given package can only lead to frustration and friction within the project. I assume such removal requests can be scripted, to make it easy for the porter/buildd maintainer to do. Happy hacking, Except that sometimes packages are flagges N-F-U because they break the buildd chroot during build. For example they pull in a package that has a broken maintainer script. Such N-F-Us would be temporary until the faulty package is fixed and should really not cause any removals. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
On Wed, Aug 06, 2008 at 10:42:53AM +0100, Steve McIntyre wrote: Steve Langasek wrote: On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote: Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software that can be compiled on an architecture even if it doesn't seem that useful. I have the X11 libraries on my NSLU2, which lacks any graphical output, but I use it as an X11 server. The argument for not building various packages on s390 is that s390 has *no hardware*, so anything that depends on local hardware to be useful has no purpose on s390. That doesn't apply for hpodder, which is not a hardware interface; but that's a plausible explanation for why the package was put in NFU, if the buildd maintainer thought it was hardware-dependent. It would be nice if buildd admins told people they were doing it, of course, so that maintainers don't have to guess why their packages mysteriously aren't being built... While I agree with the general sentiment, there is really nothing mysterious about checking buildd.debian.org (and calling it that is just finding excuses for maintainers that don't spend the time to check the status of their packages). Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
On Thu, 07 Aug 2008, Goswin von Brederlow wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Matthew Johnson] Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... I agree. Perhaps a new rule should be introduced, that when a porter flag a package as NFU on a given architecture, he should be required to file a removal request for the binaries on that architecture too, and CC the package maintainer to let the maintainer know about the decision. Silently flagging packages as NFU on a given architecture do not seem like a good idea, and expecting the maintainer to ask for removal without letting the maintainer know that the porter refuses to build a given package can only lead to frustration and friction within the project. I assume such removal requests can be scripted, to make it easy for the porter/buildd maintainer to do. Happy hacking, Except that sometimes packages are flagges N-F-U because they break the buildd chroot during build. For example they pull in a package that has a broken maintainer script. Such N-F-Us would be temporary until the faulty package is fixed and should really not cause any removals. Then, they should be special-cased, and the rest (that are not short-term NFUs) should be made DD-friendly by doing what Pere suggested. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Thu, 07 Aug 2008, Goswin von Brederlow wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Matthew Johnson] Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... I agree. Perhaps a new rule should be introduced, that when a porter flag a package as NFU on a given architecture, he should be required to file a removal request for the binaries on that architecture too, and CC the package maintainer to let the maintainer know about the decision. Silently flagging packages as NFU on a given architecture do not seem like a good idea, and expecting the maintainer to ask for removal without letting the maintainer know that the porter refuses to build a given package can only lead to frustration and friction within the project. I assume such removal requests can be scripted, to make it easy for the porter/buildd maintainer to do. Happy hacking, Except that sometimes packages are flagges N-F-U because they break the buildd chroot during build. For example they pull in a package that has a broken maintainer script. Such N-F-Us would be temporary until the faulty package is fixed and should really not cause any removals. Then, they should be special-cased, and the rest (that are not short-term NFUs) should be made DD-friendly by doing what Pere suggested. The actual long term solution is the packages-arch-specific file. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
Henrique de Moraes Holschuh wrote: On Thu, 07 Aug 2008, Goswin von Brederlow wrote: Petter Reinholdtsen [EMAIL PROTECTED] writes: [Matthew Johnson] Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... I agree. Perhaps a new rule should be introduced, that when a porter flag a package as NFU on a given architecture, he should be required to file a removal request for the binaries on that architecture too, and CC the package maintainer to let the maintainer know about the decision. Silently flagging packages as NFU on a given architecture do not seem like a good idea, and expecting the maintainer to ask for removal without letting the maintainer know that the porter refuses to build a given package can only lead to frustration and friction within the project. I assume such removal requests can be scripted, to make it easy for the porter/buildd maintainer to do. Happy hacking, Except that sometimes packages are flagges N-F-U because they break the buildd chroot during build. For example they pull in a package that has a broken maintainer script. Such N-F-Us would be temporary until the faulty package is fixed and should really not cause any removals. Then, they should be special-cased, and the rest (that are not short-term NFUs) should be made DD-friendly by doing what Pere suggested. All NFUs are supposed to be short-term. Though some not as short-term as others... Long term issues should be in Packages-arch-specific. Some NFUs are used for long-term (non-)issues currently, though that's not at all what it's supposed to be used for. It would be better if that just changed... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software that can be compiled on an architecture even if it doesn't seem that useful. I have the X11 libraries on my NSLU2, which lacks any graphical output, but I use it as an X11 server. That being said, I can see the point from the s390 build admins; as a m68k porter, I don't think we need to spend the time compiling fight sims and such for an architecture that has no where close to the processing power to run it, and thus I can see why NFUing useless packages can help save wear and tear on the s390 buildds. Michael On Tue, Aug 5, 2008 at 4:58 PM, Mark Brown [EMAIL PROTECTED] wrote: On Tue, Aug 05, 2008 at 12:21:52PM -0500, John Goerzen wrote: This seems to happen to me most often on the s390 build daemon, and has happened with at least 3 to 5 different packages now. (Current example is hpodder). In fact, I don't think I've ever seen it happen elsewhere. It seems to happen when build-deps don't get satisfied, or where there is some problem installing the build-deps. This is quite common with the s390 buildd - it tends to happen when it appears that the package may not be useful on s390 (eg, due to apparing to require hardware not available on s390), apparently based on the package description. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote: Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software that can be compiled on an architecture even if it doesn't seem that useful. I have the X11 libraries on my NSLU2, which lacks any graphical output, but I use it as an X11 server. The argument for not building various packages on s390 is that s390 has *no hardware*, so anything that depends on local hardware to be useful has no purpose on s390. That doesn't apply for hpodder, which is not a hardware interface; but that's a plausible explanation for why the package was put in NFU, if the buildd maintainer thought it was hardware-dependent. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
Steve Langasek wrote: On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote: Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software that can be compiled on an architecture even if it doesn't seem that useful. I have the X11 libraries on my NSLU2, which lacks any graphical output, but I use it as an X11 server. The argument for not building various packages on s390 is that s390 has *no hardware*, so anything that depends on local hardware to be useful has no purpose on s390. That doesn't apply for hpodder, which is not a hardware interface; but that's a plausible explanation for why the package was put in NFU, if the buildd maintainer thought it was hardware-dependent. It would be nice if buildd admins told people they were doing it, of course, so that maintainers don't have to guess why their packages mysteriously aren't being built... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You can't barbecue lettuce! -- Ellie Crane -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
On Wed Aug 06 10:42, Steve McIntyre wrote: Steve Langasek wrote: On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote: Correct me if I'm wrong, but it seems like a pretty bad idea to NFU software that can be compiled on an architecture even if it doesn't seem that useful. I have the X11 libraries on my NSLU2, which lacks any graphical output, but I use it as an X11 server. The argument for not building various packages on s390 is that s390 has *no hardware*, so anything that depends on local hardware to be useful has no purpose on s390. That doesn't apply for hpodder, which is not a hardware interface; but that's a plausible explanation for why the package was put in NFU, if the buildd maintainer thought it was hardware-dependent. It would be nice if buildd admins told people they were doing it, of course, so that maintainers don't have to guess why their packages mysteriously aren't being built... Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Packages getting marked not-for-us
[Matthew Johnson] Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... I agree. Perhaps a new rule should be introduced, that when a porter flag a package as NFU on a given architecture, he should be required to file a removal request for the binaries on that architecture too, and CC the package maintainer to let the maintainer know about the decision. Silently flagging packages as NFU on a given architecture do not seem like a good idea, and expecting the maintainer to ask for removal without letting the maintainer know that the porter refuses to build a given package can only lead to frustration and friction within the project. I assume such removal requests can be scripted, to make it easy for the porter/buildd maintainer to do. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packages getting marked not-for-us
Hi, I have been having what is a recurring problem: One of the buildds will (apparently) randomly mark one of my packages not-for-us. That despite the fact that the package built on that buildd in the past, and there's no reason to suggest that architecture has been excluded. This then gets in the way of packages migrating to testing, because the buildd had built former versions there. This seems to happen to me most often on the s390 build daemon, and has happened with at least 3 to 5 different packages now. (Current example is hpodder). In fact, I don't think I've ever seen it happen elsewhere. It seems to happen when build-deps don't get satisfied, or where there is some problem installing the build-deps. Back in the Old Days when I ran an Alpha buildd (years ago), things never got automatically marked not-for-us; that happened manually. After asking around on IRC a few weeks ago, there is no longer consensus that's how it happens now. Does anybody know? -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packages getting marked not-for-us
John Goerzen [EMAIL PROTECTED] writes: Back in the Old Days when I ran an Alpha buildd (years ago), things never got automatically marked not-for-us; that happened manually. After asking around on IRC a few weeks ago, there is no longer consensus that's how it happens now. Does anybody know? not-for-us needs to be set manually. Marc -- BOFH #347: The rubber band broke pgp8LFGZXWBlM.pgp Description: PGP signature
Re: Packages getting marked not-for-us
On Tue, Aug 05, 2008 at 12:21:52PM -0500, John Goerzen wrote: This seems to happen to me most often on the s390 build daemon, and has happened with at least 3 to 5 different packages now. (Current example is hpodder). In fact, I don't think I've ever seen it happen elsewhere. It seems to happen when build-deps don't get satisfied, or where there is some problem installing the build-deps. This is quite common with the s390 buildd - it tends to happen when it appears that the package may not be useful on s390 (eg, due to apparing to require hardware not available on s390), apparently based on the package description. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
