Re: buildd/porter/maintainer roles again
On Wed, Jul 28, 2010 at 04:53:51AM +, Clint Adams wrote: On Tue, Jul 27, 2010 at 11:27:43AM -0400, Wouter Verhelst wrote: - I have no clue who the powerpc porters are, if there are any. I guess we can't rely on the lenny qualification wiki pages. I'm still interested in powerpc, and while it's not my primary interest, I do follow the powerpc list, and would try to investigate any issues brought up on there as time allows, and I'm sure I'm not the only one who could do this. The main thing is making sure we are notified of problems! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: buildd/porter/maintainer roles again
Clint Adams sch...@debian.org writes: On Tue, Jul 27, 2010 at 11:27:43AM -0400, Wouter Verhelst wrote: What would you think if you saw this happening only on a particular architecture? /usr/bin/ld: non-dynamic relocations refer to dynamic symbol fork@@GLIBC_2.0 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status #519006 - I literally have memorized the bug id by now. Marc pgpYmduqGfv07.pgp Description: PGP signature
Re: buildd/porter/maintainer roles again
On Tue, Jul 27, 2010 at 05:01:12PM -0500, Peter Samuelson wrote: [Wouter Verhelst] Please remember that every time a package fails to function correctly on a particular architecture, barring toolchain bugs, this is a bug in that package itself. Barring toolchain bugs is a pretty big caveat. Just as big as barring kernel and libc issues, some other reasons for packages to fail to build or run on particular architectures. There is a perception, which may or may not be grounded in reality, that _most_ FTBFS from the Debian buildds are either toolchain, kernel, or libc issues. It is certainly my perception. It's not my perception, but I guess it depends on how you define architecture-specific bugs. If by architecture-specific, you mean bugs that occur on one set of architectures, but for one reason or another not the set of architectures that includes the architecture on which the developer builds and tests his packages, then you're very, very wrong. If you rather mean bugs that occur on one architecture, and one architecture only--perhaps with the exception of related architectures like mips and mipsel, or i386 and amd64--then there's probably a pretty high amount of toolchain bugs, indeed. But even then, I doubt it would be true that these bugs are usually toolchain related. Toolchain bugs are pretty rare; in the 8 or so years that I've been an m68k porter, there've been only a handfull. There have, however, been several packages that failed to build on just m68k, and most of those were because of bugs in the software that only managed to trip on m68k because of some peculiarities in the hardware. Confusion between pointer and integer in return values, for instance, will cause immediate failures on m68k, yet is not a bug in the m68k toolchain. Similar problems exist on other architectures, and it is my perception that these happen far more often than toolchain bugs And it seems to have been a toolchain issue that started this thread (some mips buildd simply cannot not build Java stuff, as I recall). Yeah, well, java is a bit of a special case, anyway. We've historically not been able to do much with java on most of our architectures; java really isn't very portable, even today. Do you, as a porter and buildd admin, have a rough idea what percentage of FTBFS and arch-specific bugs you see that are ultimately a bug in the package, versus an externality like a bad build chroot, bad kernel, bad system library, or bad toolchain? If we're talking about 90% vs. 10%, for example, that would inform who should really be on the front line triaging this stuff. I don't really keep track of that, I'm afraid. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728183122.gj26...@celtic.nixsys.be
Re: buildd/porter/maintainer roles again
On Wed, Jul 28, 2010 at 04:53:51AM +, Clint Adams wrote: On Tue, Jul 27, 2010 at 11:27:43AM -0400, Wouter Verhelst wrote: - It's only useful to talk to a porter if the bug clearly is a porting issue, rather than a bug in the package. This isn't always easy to make out from the build log. What would you think if you saw this happening only on a particular architecture? /usr/bin/ld: non-dynamic relocations refer to dynamic symbol fork@@GLIBC_2.0 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status Yes, that does look like a toolchain issue. I didn't say it's impossible to make out, just that most bugs aren't as clear as the above. - I have no clue who the powerpc porters are, if there are any. I guess we can't rely on the lenny qualification wiki pages. That page is llld. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728183227.gk26...@celtic.nixsys.be
Re: buildd/porter/maintainer roles again
On Mon, Jul 12, 2010 at 06:05:45PM +, Clint Adams wrote: Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? As a powerpc buildd admin but not a porter, I'd be happy to do so. But: - It's only useful to talk to a porter if the bug clearly is a porting issue, rather than a bug in the package. This isn't always easy to make out from the build log. - I have no clue who the powerpc porters are, if there are any. I can mail to the debian-powerpc mailinglist of course, but that seems to be mostly a powerpc user support list these days. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727152743.gi11...@celtic.nixsys.be
Re: buildd/porter/maintainer roles again
On Tue, 27 Jul 2010, Wouter Verhelst wrote: I can mail to the debian-powerpc mailinglist of course, but that seems to be mostly a powerpc user support list these days. Since coordinating porters and keeping them coordinated seems to be a problem, and pseudopackages with affects and/or reassign as appropriate seem to be the best solution, are there any objections to requiring a porter psuedopackage for each architecture and setting the maintainer of that pseudopackage to the appropriate mechanism to contact porters? I'm imagining that buildd admins would then just file an FTBFS against the package, the maintainer would see it, and say I don't know why this is failing; looks to be arch-specific, reassign or affects the bug to the arch specific porter psuedopackage, and the porters now can track the bug. If there aren't any objections here, I'll run this by the porters that I can track down. Don Armstrong -- What I can't stand is the feeling that my brain is leaving me for someone more interesting. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727154214.gi19...@teltox.donarmstrong.com
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 05:22:12PM +0200, Petter Reinholdtsen wrote: [Clint Adams] Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? You bring up the important topic of expectations on who is responsible for what regarding porting of Debian packages to the architectures in Debian. I believe it is important that the separation of responsibilities between package maintainers, porters and buildd maintainers is described somewhere autorative, to ensure that the entire project have a common understanding on who is responsible for what and hopefully avoid or reduce the number of conflicts between package maintainers, porters and buildd administrators. To ensure the various ports of Debian to not put unreasonable strain on package maintainers, I believe it is important that most of the responsibility of getting a package working on a architecture where the package have never built before is placed on the porters and buildd administrators. I would like for people not to speak in such generic terms. Sometimes a package fails to build or work on an architecture because it does something silly, like addr = (u32)(p32) ... which is code that will never ever function correctly on 64-bit architectures (and before you ask: yes, this is a real-life example). Expecting porters to find and fix such things is not only unrealistic, it isn't even fair. If this responsibility instead is placed on package maintainers, I believe it is a good idea for Debian to drop the lesser used architectures to ensure they do not slow down the rate of improvement in Debian. You should note that packages which have never built before on a particular architecture cannot hold back that architecture, unless they are part of the base system or Build-Essential set. So dropping that architecture for that reason isn't a good idea, IMO. Those caring for an architecture (which I assume is the set of porters and buildd administrators) need to be the ones responsible for providing patches to package maintainers to get the architecture working with a given package. Of course this work need to be done together with the package maintainers, but I believe it is unreasonable to expect maintainers to spend time on trying to get their packages working on architectures they do not care for, and am sure it is the way to get Debian to throw out lesser used architectures. It is fair to expect porters to work on packages when they hold back the port as a whole (such as packages that are part of the toolchain or the base system). It is fair to expect porters to work on packages when asked. E.g., a package fails to build or function, the maintainer can't figure out why, and doesn't have hardware of the architecture in question. Porters should then be willing to download the package, and spend some time in identifying the bug in question. I don't think it's fair to expect porters to work on *all* bugs in *all* packages for their architecture, just because that architecture is lesser used. Please remember that every time a package fails to function correctly on a particular architecture, barring toolchain bugs, this is a bug in that package itself. It may be a bug that just doesn't happen to trigger very often on machines of the architecture that the maintainer used to build and test the package, or it may be a bug of a kind that is only problematic on one subset of architectures (such as failure to properly use the ntoh* functions, or casts of pointers to 32bit variables, or something similar), but that doesn't make it a bug of the architecture; it is still a bug in the package itself. As such, while the architecture's porters should be willing to help out when and where necessary, I think fixing one's bugs should still be one's own responsibility. If, of course, a maintainer can't fix something and the porters can't (or won't) help, then that's a very good reason for that maintainer to ignore the bug. In that light, it's also discouraging to see that even if a porter puts some work in a package Just Because He Can(tm), some maintainers just don't care, because it works on their architecture and this architecture is not used that often anyway (#497262, for example). -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727162249.gj11...@celtic.nixsys.be
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 02:27:42PM -0700, Don Armstrong wrote: On Tue, 13 Jul 2010, Hector Oron wrote: 2010/7/13, Russ Allbery r...@debian.org: But if those steps fail and it gets to the point where I'm actively asking for help, my customary experience has been to never get any reply. Mail seems to just disappear into a black hole. Sometimes this is true even for a requeue request, although mostly those do get handled, but anything asking for more details seems to rarely get any reply. We are persons, and mail stack grows fast. So, suggested use of BTS should be encouraged. Tagging packages for porters to have a look might be a really good idea. If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] I did at some point ask for architecture tags, but was told to use usertags instead. I made a suggestion to that end, but they ended up not getting used all that much, mainly because usertags are not as visible as regular tags and therefore not as helpful. I still think regular tags for architectures are what we should move to, and don't think skipping the requirement for going through usertags first is an unfair request (ports are a fairly important part of Debian, after all) but have given up on that cause; I seemed to be screaming in the void. -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727162643.gk11...@celtic.nixsys.be
Re: buildd/porter/maintainer roles again
On Tue, Jul 27, 2010 at 11:42:14AM -0400, Don Armstrong wrote: I'm imagining that buildd admins would then just file an FTBFS against the package, the maintainer would see it, and say I don't know why this is failing; looks to be arch-specific, reassign or affects the bug to the arch specific porter psuedopackage, and the porters now can track the bug. If there aren't any objections here, I'll run this by the porters that I can track down. Architecture pseudopackages? Yeah, I guess that would work, too; but I think tags are preferable. Most of the things that we have pseudopackages for are things that aren't directly related to packages; i.e., having a bug assigned to both the pseudopackage and some other package is the exception rather than the rule. I feel, however, that in this case the same just isn't true; architecture-specific bugs are always in one particular package. Reassigning to the architecture pseudopackage will cause the bug to disappear from the main package, causing duplicate bugs to be filed. So that would mean they'd almost always need to be assigned to both the pseudopackage and the original package, which I frankly find to be a bit of a hassle. Additionally, tags have the interesting feature that you can limit a query by whether or not something is tagged in a specific way. Give me all packages that affect powerpc or s390, but not any other architecture could be an interesting way to hunt for bugs related to char signedness, which is going to be awkward using pseudopackages. The release team could use architecture tags in similar ways they now use their release-ignore tags: severity serious or higher bugs that have tags for this set of architectures but not for this other set here are not in fact release critical, unless they also have the patch tag set. I think doing such things with architecture pseudopackages is going to be much harder. In short, I believe tags are the best answer here. (oh, and if you're going to add them, I'll buy you a beer. Two, if you also migrate the tags that I've described in http://lists.debian.org/debian-devel-announce/2009/03/msg00015.html) -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727170622.gp11...@celtic.nixsys.be
Re: buildd/porter/maintainer roles again
On Tue, 27 Jul 2010, Wouter Verhelst wrote: So that would mean they'd almost always need to be assigned to both the pseudopackage and the original package, which I frankly find to be a bit of a hassle. That's why affects exists. Additionally, tags have the interesting feature that you can limit a query by whether or not something is tagged in a specific way. Give me all packages that affect powerpc or s390, but not any other architecture could be an interesting way to hunt for bugs related to char signedness, which is going to be awkward using pseudopackages. You can do the same thing using packages; there's no difference in the way that packages are searched that differentiates them from tags. The major difference between tags and pseudopackages is that mail going to a psuedopackage's maintainer works today. Mail regarding bugs containing a specific tag does not currently go anywhere, and this would have to be changed. I can change this (and in fact, generalizing this is on my todo list), but I want to avoid spending time on a solution which won't be used. Pseudopackages also have the advantage that bugs regarding buildds and such which are in the porters domain can also be assigned to a specific psuedopackage so the porters can track it. Don Armstrong -- Only one creature could have duplicated the expressions on their faces, and that would be a pigeon who has heard not only that Lord Nelson has got down off his column but has also been seen buying a 12-bore repeater and a box of cartridges. -- Terry Pratchet _Mort_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727174803.gk19...@teltox.donarmstrong.com
Re: buildd/porter/maintainer roles again
[Wouter Verhelst] Please remember that every time a package fails to function correctly on a particular architecture, barring toolchain bugs, this is a bug in that package itself. Barring toolchain bugs is a pretty big caveat. Just as big as barring kernel and libc issues, some other reasons for packages to fail to build or run on particular architectures. There is a perception, which may or may not be grounded in reality, that _most_ FTBFS from the Debian buildds are either toolchain, kernel, or libc issues. It is certainly my perception. And it seems to have been a toolchain issue that started this thread (some mips buildd simply cannot not build Java stuff, as I recall). Do you, as a porter and buildd admin, have a rough idea what percentage of FTBFS and arch-specific bugs you see that are ultimately a bug in the package, versus an externality like a bad build chroot, bad kernel, bad system library, or bad toolchain? If we're talking about 90% vs. 10%, for example, that would inform who should really be on the front line triaging this stuff. Peter -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100727220112.ga8...@p12n.org
Re: buildd/porter/maintainer roles again
On Tue, Jul 27, 2010 at 11:27:43AM -0400, Wouter Verhelst wrote: - It's only useful to talk to a porter if the bug clearly is a porting issue, rather than a bug in the package. This isn't always easy to make out from the build log. What would you think if you saw this happening only on a particular architecture? /usr/bin/ld: non-dynamic relocations refer to dynamic symbol fork@@GLIBC_2.0 /usr/bin/ld: failed to set dynamic section sizes: Bad value collect2: ld returned 1 exit status - I have no clue who the powerpc porters are, if there are any. I guess we can't rely on the lenny qualification wiki pages. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728045351.ga27...@scru.org
Re: buildd/porter/maintainer roles again
On Wed, Jul 21, 2010 at 12:17:15AM +0200, Bastian Blank wrote: The maintainer have to fix the missing error checks first. I fail to see any arch-specific problems, only a missing library. Okay, so your answer is that the maintainer should review the build log, notice the missing library, and then do what? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100721122528.ga26...@scru.org
Re: buildd/porter/maintainer roles again
On Wed, Jul 14, 2010 at 02:16:59PM +, Clint Adams wrote: I'd like the people in the buildd-admins-are-doing-the-right-thing camp to describe the ideal workflow for solving architecture-specific issues with the ksh[0] package. [0] https://buildd.debian.org/pkg.cgi?pkg=ksh The maintainer have to fix the missing error checks first. I fail to see any arch-specific problems, only a missing library. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, Dagger of the Mind, stardate 2715.1 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100720221715.ga17...@wavehammer.waldi.eu.org
Re: buildd/porter/maintainer roles again
Hi! * Charles Plessy ple...@debian.org [2010-07-14 02:14:12 CEST]: Le Tue, Jul 13, 2010 at 08:44:17PM +0200, Hector Oron a écrit : I would also like to point you to http://blog.aurel32.net/?p=58 I am sure that we could achieve the suggested goal, which is to have a port ready and in a good shape when an architecture turns mainstream, if we were following a strategy similar to what is suggested on the following page of Fedora's wiki: https://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures Isn't that what http://www.debian-ports.org/ is about, being second class architectures? In situations where nobody volunteers to do the work of porting leaf packages for scientific computation on embedded arches where nobody will use them, my conclusion is that it would be harmless for the ports to ignore the package completely. Such architectures are moved off the main pool and to debian-ports, at least that's what was my understanding and what I perceived in the last years. So long, Rhonda -- Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder Mensch auch ein Privatleben haben sollte. -- http://www.karriere.at/artikel/884/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714073347.ga12...@anguilla.debian.or.at
Re: buildd/porter/maintainer roles again
Hi, On Dienstag, 13. Juli 2010, Don Armstrong wrote: If porters would like psuedopackages for their architecture to track requests, that can be arranged. I'd say not only porters would benefit from such pseudopackages, but also maintainers, buildd admins and users. But if, there'd need to be pseudopackages for all arch supported by Debian, else it would only be half useful. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: buildd/porter/maintainer roles again
* Charles Plessy ple...@debian.org [100714 02:15]: In situations where nobody volunteers to do the work of porting leaf packages for scientific computation on embedded arches where nobody will use them, I'd rather think that is an indicator that a package is not suiteable for Debian because of poor quality. Things needing porting to work on all architectures usually include - sources doing '#if' for all known architectures and having no working default pure-C implementation. While that is understandable for some low-level stuff not easily done in C (like the core of some languages), I've seen this more than often enough that some C or C++ project just tries to optimize code and lets the generic implementation bitrot (or had it never working). - undefined behaviour Unaligned access is quite common. That's sad because in my experience it's practically impossible to get it without getting into the undefined part of the C specification. That usually means that just the next compiler could have some optimisation that causes your code to go havoc. Also note that it's not about embedded arches where nobody will use them, but about the architecture you did not care about. I doubt amd64 would have been possible without alpha fixing the ubiquitous 64-bit-unreadiness for years. Arm and mips might appear on laptops soon. And even the ones found in NAS devices have speeds that ten years ago would have been high-end machines. Even the mainstream processors got more picky about alignment. Thanks to vector operations and compiler optimisations using them sometimes you can get problems with undefined behaviour that is otherwise only visible by unaligned access causing SIGBUS. my conclusion is that it would be harmless for the ports to ignore the package completely. We had this discussion already: show me a port that want to ignore packages. If you as package maintainer want to ignore bugs in your package by ignoring architectures showing them, then say it this way. And do not claim a perspective you do not have. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714101017.ga5...@pcpool00.mathematik.uni-freiburg.de
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 08:44:17PM +0200, Hector Oron wrote: Maintainers are the ones that know best their software, they are encouraged to maintain their packages in best manner following a strict policy and following strict verification and validation procedures. In Debian, it is requested to have that software built in all arches (or at least as much as you can get). Porters are there to help out, but you can not put all the amount of work for all the failing software on an architecture to the porters for such architecture. I'd like the people in the buildd-admins-are-doing-the-right-thing camp to describe the ideal workflow for solving architecture-specific issues with the ksh[0] package. [0] https://buildd.debian.org/pkg.cgi?pkg=ksh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714141659.ga6...@scru.org
Re: buildd/porter/maintainer roles again
On Wed, Jul 14, 2010 at 11:07:50PM +0900, Charles Plessy wrote: I am not asking for throwing away people's work or ignoring their motivation, but I feel demotivated that I am asked efforts with nothing in return, since--and this is what makes this mail more or less on-topic in this thread--it is usually not the porter nor the users themselves who insist on putting a high priority for distributing scientific leaf package on their favorite architecture, but a policy that I challenge, enforced through the buildd maintainers by filing RC bugs. From http://release.debian.org/squeeze/rc_policy.txt: 4. Autobuilding [...] Packages must autobuild without failure on all architectures on which they are supported. Packages must be supported on as many architectures as is reasonably possible. Packages are assumed to be supported on all architectures for which they have previously built successfully. Prior builds for unsupported architectures must be removed from the archive (contact -release or ftpmaster if this is the case). If it never build on that arch before, and looks like an arch specific issue, it's not RC. This for instance means that not all FTBFS bugs on kfreebsd-* are RC. I will file bugs as RC even when it didn't build previous when I think it's supported on that arch and needs some very easy fix, like adding proper build-depends. Kurt -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714164629.ga29...@roeckx.be
Re: buildd/porter/maintainer roles again
Bernhard R. Link brl...@debian.org writes: * Charles Plessy ple...@debian.org [100714 02:15]: In situations where nobody volunteers to do the work of porting leaf packages for scientific computation on embedded arches where nobody will use them, I'd rather think that is an indicator that a package is not suiteable for Debian because of poor quality. I tend to agree in general, but it's worth noting that if there are any legitimate cases here (things with low-level, fine-tuned assembly code or the like for specific architectures), Charles is packaging the types of things (high-performance scientific computing applications) that are most likely to have such issues. I suspect, though, that most of the cases he's running into are... - sources doing '#if' for all known architectures and having no working default pure-C implementation. While that is understandable for some low-level stuff not easily done in C (like the core of some languages), I've seen this more than often enough that some C or C++ project just tries to optimize code and lets the generic implementation bitrot (or had it never working). ...this, or at a more basic level, a build system that makes assumptions about all the platforms it could ever possibly be compiled on. It's sad how many scientific applications I've seen that do something functionally equivalent to: #ifndef __i386__ /* Code assuming amd64. */ #endif One of the challenges that is particularly bad with scientific code is that a lot of the authors are not coming from a programming background and are not familiar with the commonly used methods for handling things like this that are prevelant in the open source world. The code usually has some cobbled-together build system that was written by some grad student five years ago out of chewing gum and duct tape, which no one involved in the project is willing to touch or understands. In one sense, then, you're right: it's often badly written code, or at least badly *packaged* code (the core scientific stuff is sometimes quite pretty). On the other hand, that's just the state of maturity of that field at this point, with some stand-out exceptions. If we want to try to make Debian a strong platform for scientific computing, we unfortunately have to figure out how we're going to deal with that type of upstream for many of the packages. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bpaa5792@windlord.stanford.edu
Re: buildd/porter/maintainer roles again
On 2010-07-12, Bernd Zeimetz be...@bzed.de wrote: Or they should work closely with the porters to notify them about build logs which smell like issues porters should look into. I would consider that 'caring for the port'. /Sune -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni3o7ja.rvp.nos...@sshway.ssh.pusling.com
Re: buildd/porter/maintainer roles again
[Clint Adams] Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? You bring up the important topic of expectations on who is responsible for what regarding porting of Debian packages to the architectures in Debian. I believe it is important that the separation of responsibilities between package maintainers, porters and buildd maintainers is described somewhere autorative, to ensure that the entire project have a common understanding on who is responsible for what and hopefully avoid or reduce the number of conflicts between package maintainers, porters and buildd administrators. To ensure the various ports of Debian to not put unreasonable strain on package maintainers, I believe it is important that most of the responsibility of getting a package working on a architecture where the package have never built before is placed on the porters and buildd administrators. If this responsibility instead is placed on package maintainers, I believe it is a good idea for Debian to drop the lesser used architectures to ensure they do not slow down the rate of improvement in Debian. Those caring for an architecture (which I assume is the set of porters and buildd administrators) need to be the ones responsible for providing patches to package maintainers to get the architecture working with a given package. Of course this work need to be done together with the package maintainers, but I believe it is unreasonable to expect maintainers to spend time on trying to get their packages working on architectures they do not care for, and am sure it is the way to get Debian to throw out lesser used architectures. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flk4ozs8yj@login1.uio.no
Re: buildd/porter/maintainer roles again
Dear Petter, 2010/7/13, Petter Reinholdtsen p...@hungry.com: I believe it is a good idea for Debian to drop the lesser used architectures to ensure they do not slow down the rate of improvement in Debian. I am proud of the amount of architectures Debian supports. I also understand its overhead, but I think that having software that runs on any processor makes Debian one of the best choices out there. I would also like to point you to http://blog.aurel32.net/?p=58 Those caring for an architecture (which I assume is the set of porters and buildd administrators) need to be the ones responsible for providing patches to package maintainers to get the architecture working with a given package. Of course this work need to be done together with the package maintainers, but I believe it is unreasonable to expect maintainers to spend time on trying to get their packages working on architectures they do not care for, and am sure it is the way to get Debian to throw out lesser used architectures. Maintainers are the ones that know best their software, they are encouraged to maintain their packages in best manner following a strict policy and following strict verification and validation procedures. In Debian, it is requested to have that software built in all arches (or at least as much as you can get). Porters are there to help out, but you can not put all the amount of work for all the failing software on an architecture to the porters for such architecture. Best regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikawo_x_wj-gr-hzmrvvxr7mynysj8vmfhhj...@mail.gmail.com
Re: buildd/porter/maintainer roles again
On Mon, Jul 12, 2010 at 06:05:45PM +, Clint Adams wrote: Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? I think you made a point, there is clearly a problem of communication between packages maintainer / buildd maintainer and porters. Packages maintainer are often waiting for porters to fix an issue they are not aware. Even if they have been made aware, the issue can easily be lost if not correctly tracked. We are missing some tools here. The BTS is IMHO the most suitable tool to do that, and it is already used by the security team that way. When a bug is tagged security, the security team receives a copy of every mail sent to this bug. We can imagine doing the same for the porters, in other words adding tags for each architectures (some of them might be grouped like mips and mipsel), and getting the corresponding port mailing list receiving the mail. We can also imagine that every week the porter mailing list receives a list of the opened issue like it is done for example for RC bugs. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713201732.gi18...@hall.aurel32.net
Re: buildd/porter/maintainer roles again
Hector Oron hector.o...@gmail.com writes: Maintainers are the ones that know best their software, they are encouraged to maintain their packages in best manner following a strict policy and following strict verification and validation procedures. In Debian, it is requested to have that software built in all arches (or at least as much as you can get). Porters are there to help out, but you can not put all the amount of work for all the failing software on an architecture to the porters for such architecture. I must say, as a package maintainer, I've found the interactions with porting and buildds for more obscure architectures, when I've had to have those interactions, generally frustrating and unhelpful. Now, please note, those interactions have been rare. By and large everything just works, and when it doesn't, the build logs generally contain more than enough information for me to figure out what's going on. When that fails, logging on to a porter system and doing a build there has usually let me get to the bottom of the problem. That part works great. The FTBFS bug reports have also normally been quite good. But if those steps fail and it gets to the point where I'm actively asking for help, my customary experience has been to never get any reply. Mail seems to just disappear into a black hole. Sometimes this is true even for a requeue request, although mostly those do get handled, but anything asking for more details seems to rarely get any reply. So far, I've usually managed to muddle through and figure out the issue on my own, and to be fair, it's usually some bug in my package that only got triggered in very obscure circumstances that made it not entirely reproducible but which wasn't a problem with that specific architecture. But the complete silence in response to requests for assistance is, I must say, rather demotivating. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lj9f9lje@windlord.stanford.edu
Re: buildd/porter/maintainer roles again
On Tue, 13 Jul 2010, Hector Oron wrote: 2010/7/13, Russ Allbery r...@debian.org: But if those steps fail and it gets to the point where I'm actively asking for help, my customary experience has been to never get any reply. Mail seems to just disappear into a black hole. Sometimes this is true even for a requeue request, although mostly those do get handled, but anything asking for more details seems to rarely get any reply. We are persons, and mail stack grows fast. So, suggested use of BTS should be encouraged. Tagging packages for porters to have a look might be a really good idea. If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] Don Armstrong -- Judge if you want. We are all going to die. I intend to deserve it. -- a softer world #421 http://www.asofterworld.com/index.php?id=421 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713212742.gt31...@rzlab.ucr.edu
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 02:27:42PM -0700, Don Armstrong wrote: On Tue, 13 Jul 2010, Hector Oron wrote: 2010/7/13, Russ Allbery r...@debian.org: But if those steps fail and it gets to the point where I'm actively asking for help, my customary experience has been to never get any reply. Mail seems to just disappear into a black hole. Sometimes this is true even for a requeue request, although mostly those do get handled, but anything asking for more details seems to rarely get any reply. We are persons, and mail stack grows fast. So, suggested use of BTS should be encouraged. Tagging packages for porters to have a look might be a really good idea. If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] While I agree it should go through the BTS, I am not sure pseudo-packages are the best for that. In most cases fixing a porting issue is not the responsibility of the maintainer nor the porter, but both together. With pseudo-packages it will end-up as bugs reassigned to the pseudo-packages (to the porters), with the maintainers being satisfied of having one bug less to care. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713213632.gj18...@hall.aurel32.net
Re: buildd/porter/maintainer roles again
On Tue, 13 Jul 2010, Aurelien Jarno wrote: On Tue, Jul 13, 2010 at 02:27:42PM -0700, Don Armstrong wrote: If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] While I agree it should go through the BTS, I am not sure pseudo-packages are the best for that. In most cases fixing a porting issue is not the responsibility of the maintainer nor the porter, but both together. With pseudo-packages it will end-up as bugs reassigned to the pseudo-packages (to the porters), with the maintainers being satisfied of having one bug less to care. You can reassign bugs to multiple packages or use affects to indicate that a bug affects multiple packages, so this isn't really a problem. That said, whatever way porters want to keep track of bugs which maintainers need assistance with is fine by me. It's even fine if different architectures choose different methods. Don Armstrong -- Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713215003.gw31...@rzlab.ucr.edu
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 02:50:03PM -0700, Don Armstrong wrote: On Tue, 13 Jul 2010, Aurelien Jarno wrote: On Tue, Jul 13, 2010 at 02:27:42PM -0700, Don Armstrong wrote: If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] While I agree it should go through the BTS, I am not sure pseudo-packages are the best for that. In most cases fixing a porting issue is not the responsibility of the maintainer nor the porter, but both together. With pseudo-packages it will end-up as bugs reassigned to the pseudo-packages (to the porters), with the maintainers being satisfied of having one bug less to care. You can reassign bugs to multiple packages or use affects to indicate that a bug affects multiple packages, so this isn't really a problem. What we really need here is the push method. If the information arrives directly on the porter mailing list it might be taken into account. With the pull method where people have to regularly fetch the information, it never works. While what your offer probably answers to this problem, I would be more happy with something based on tags as it is already for the security bugs. OTOH I don't know about the internals and haven't thought in details about the advantages and drawbacks of each method. I would already be happy with pseudo packages. That said, whatever way porters want to keep track of bugs which maintainers need assistance with is fine by me. It's even fine if different architectures choose different methods. I think on the contrary that we should have the same and easy method on all architectures, so that we can have this method recorded somewhere for package maintainers. If we have different and complex methods (like we already have with a few user tags for some architecture), people never apply them. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713220653.gk18...@hall.aurel32.net
Re: buildd/porter/maintainer roles again
Hello, 2010/7/14, Aurelien Jarno aurel...@aurel32.net: You can reassign bugs to multiple packages or use affects to indicate that a bug affects multiple packages, so this isn't really a problem. What we really need here is the push method. If the information arrives directly on the porter mailing list it might be taken into account. With the pull method where people have to regularly fetch the information, it never works. While what your offer probably answers to this problem, I would be more happy with something based on tags as it is already for the security bugs. OTOH I don't know about the internals and haven't thought in details about the advantages and drawbacks of each method. I would already be happy with pseudo packages. Just a suggestion, tagging the package, add an also affects a 'pseudo_package' and weekly forwards to porter lists? I like the idea on have a list with the bugs, so whenever wearing porter hat, porters and non porters might have a look to this list of bugs. Best regards, -- Héctor Orón Our Sun unleashes tremendous flares expelling hot gas into the Solar System, which one day will disconnect us. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktilyi_kkczkdmjzd0dqyeyfj-xt7gwca5b6pe...@mail.gmail.com
Re: buildd/porter/maintainer roles again
On Wed, 14 Jul 2010, Aurelien Jarno wrote: What we really need here is the push method. There's nothing stoping porters from pulling the status of bugs which need to be handled by the porters and forwarding them to their mailing list; since the maintainer of the psuedopackage would presumably be set to the porters mailing list, messages to those bugs would arrive there too. While what your offer probably answers to this problem, I would be more happy with something based on tags as it is already for the security bugs. OTOH I don't know about the internals and haven't thought in details about the advantages and drawbacks of each method. I would already be happy with pseudo packages. It's possible to provide another tag specific mailing list, but this requires code changes. It honestly doesn't make a difference to me which is done; psuedopackages would just be slightly faster to roll out and more obvious. I think on the contrary that we should have the same and easy method on all architectures, so that we can have this method recorded somewhere for package maintainers. If we have different and complex methods (like we already have with a few user tags for some architecture), people never apply them. Whatever mechanism is used, porters have to be happy with it, and have to use it. If having porters happy and using it means different mechanisms, that's fine. A single one would be optimal, but only if there's enough agreement behind it. The workflow should look something like this: 1) message goes to porter mailing list: [This bug #nnn looks like a arch-specific bug] 2) porters reassign/tag the bug to indicate that they've seen it, and agree that it is an arch-specific bug Don Armstrong -- I never until now realized that the primary job of any emoticon is to say excuse me, that didn't make any sense. ;-P -- Cory Doctorow http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713235806.gz31...@rzlab.ucr.edu
Re: buildd/porter/maintainer roles again
Le Tue, Jul 13, 2010 at 08:44:17PM +0200, Hector Oron a écrit : 2010/7/13, Petter Reinholdtsen p...@hungry.com: I believe it is a good idea for Debian to drop the lesser used architectures to ensure they do not slow down the rate of improvement in Debian. I am proud of the amount of architectures Debian supports. I also understand its overhead, but I think that having software that runs on any processor makes Debian one of the best choices out there. I would also like to point you to http://blog.aurel32.net/?p=58 Dear all, I am sure that we could achieve the suggested goal, which is to have a port ready and in a good shape when an architecture turns mainstream, if we were following a strategy similar to what is suggested on the following page of Fedora's wiki: https://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures We could rename the concept ‘pioneer architecture’ to make it more proud, and adapt it to our current practice (for instance give more logistic support to the port than what is written in this document). In situations where nobody volunteers to do the work of porting leaf packages for scientific computation on embedded arches where nobody will use them, my conclusion is that it would be harmless for the ports to ignore the package completely. Taken from the pakcage point of view, the question is whether our project wants to have specialised software distributed in Debian itself, or in derivatives that focus on a subset of our architectures. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100714001412.ga24...@merveille.plessy.net
buildd/porter/maintainer roles again
Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712180545.ga28...@scru.org
Re: buildd/porter/maintainer roles again
On 12/07/10 at 18:05 +, Clint Adams wrote: Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? I think it should be. Or the porters should monitor the builds on their architecture to be able to detect FTBFS and act on them, without the maintainer having to manually ping them. If we expect the maintainer to ping the porters, then we lack proper infrastructure to keep track of current queries to porters. For example, I would expect a BTS pseudo-package for each architecture that I could use to ask for porter help, not just debian-$arch@ mailing lists where it's easy to lose track of discussions. Lucas -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712192419.ga19...@xanadu.blop.info
Re: buildd/porter/maintainer roles again
On Mon, Jul 12, 2010 at 10:24:19PM +0300, Lucas Nussbaum wrote: I think it should be. Or the porters should monitor the builds on their architecture to be able to detect FTBFS and act on them, without the maintainer having to manually ping them. If I were a porter, I would not bother doing this if the buildd admin did not care as much as a porter would; such inattention or apathy is very frustrating and makes one want to cease being a porter. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100712192830.ga1...@scru.org
Re: buildd/porter/maintainer roles again
On 2010-07-12, Clint Adams sch...@debian.org wrote: On Mon, Jul 12, 2010 at 10:24:19PM +0300, Lucas Nussbaum wrote: I think it should be. Or the porters should monitor the builds on their architecture to be able to detect FTBFS and act on them, without the maintainer having to manually ping them. If I were a porter, I would not bother doing this if the buildd admin did not care as much as a porter would; such inattention or apathy is very frustrating and makes one want to cease being a porter. I do think that buildd admins that doesn't care for the architechture they are buildd maintaining for should try hard handing over that responsibility to someone who does care for the arch. /Sune -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni3mvvb.rvp.nos...@sshway.ssh.pusling.com
Re: buildd/porter/maintainer roles again
On 07/12/2010 10:49 PM, Sune Vuorela wrote: On 2010-07-12, Clint Adams sch...@debian.org wrote: On Mon, Jul 12, 2010 at 10:24:19PM +0300, Lucas Nussbaum wrote: I think it should be. Or the porters should monitor the builds on their architecture to be able to detect FTBFS and act on them, without the maintainer having to manually ping them. If I were a porter, I would not bother doing this if the buildd admin did not care as much as a porter would; such inattention or apathy is very frustrating and makes one want to cease being a porter. I do think that buildd admins that doesn't care for the architechture they are buildd maintaining for should try hard handing over that responsibility to someone who does care for the arch. Or they should work closely with the porters to notify them about build logs which smell like issues porters should look into. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c3b9b92.7080...@bzed.de
