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
