* Tyler MacDonald [Tue, 18 Jul 2006 11:37:09 -0700]: Hi Tyler, let's see if I can give an useful answer to your questions and concerns.
> Please see: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378375 > I would like to test this bug fix on a s390 box before uploading it. Except > I don't have access to an s390 box. :-/ I asked Bastian if he would be > willing to test this before I get my sponsor to upload, but he hasn't > replied. > What's the Debian way of handling this? I know that if I upload the new > package to unstable, it will at least be no worse than the previous version, > but it also seems like a waste of time to upload it if it just has more > problems under the s390 arch. Should I continue attempting to find an s390 > box, is there something somebody out there can do to help, or should I just > have my new packages uploaded and hope for the best? First, and most important: what makes you think that the failure is s390-specific? The fact that you only got a FTBFS report from the s390 autobuilder just means that (a) it failed there, (b) the buildd admin looked at the log, check that the FTBFS was not already reported, and submitted a bug against your package. But this says nothing about the package building in other architectures, specially because (a) you won't normally get duplicate bugs for the same FTBFS, even if in different arches, and (b) our s390 buildd admin, Bastian Blank, is normally the one that gets to the logs first, or so it seems, because a big part of FTBFS bugs come from him. ;-) Enough for verbosity already. If you check this page: http://buildd.debian.org/build.php?&pkg=mod-bt You'll see that it failed in five more architectures (mips powerpc sparc hppa m68k). In this case in particular, seems like all the big endian ones. :-) So with respect Bastian not replying above, well, I guess porters normally will want to spend their (probably scarce) free time helping with problems _really_ specific to their architecture. * Tyler MacDonald [Tue, 18 Jul 2006 12:14:55 -0700]: > My question was really geared to "any architecture" though... when > it's an arch you don't have access to; > 1) If you "think" you've fixed the problem, should you upload a new > package that "Closes:" the bug? Well, your first initial reaction, wanting to test it in one of the affected architectures, is particularly thoughtful. However, this is not always easy, so there are circumstances when one just directly uploads: e.g. the fix is trivial and one is confident it'll work, or the patch was directly provided by one of the porters. (Of course the above only applies when it is completely impossible to reproduce the problem in one's own architecture.) > 2) How long should you let a FTBFS bug stick around for on account > of lack of testability before you give up and just upload it anyway and hope > for the best? My opinion: not very long, unless it's a very very big package, and provided you have certain assurance that the fix will work (IOW, not just "ok, let's try this and see if it works"). I think this bug is one of those where one can get to the "fairly confident it'll work" stage. (OTOH, your solution seems a bit fragile for a source package that wants to get compiled with -Werror. The two apache2 and php5 files that define WORDS_BIGENDIAN, also share 23 other macro definitions; as it happens, to the same value, which does not trigger an error. But that's up to you, I guess.) > 3) Is there any sort of (organized or disorganized) effort / method > for obtaining builds of your package on architecture X before they're > uploaded to debian? Not really. Either a DD does it in some project machine, or you ask in a porter list. > Is experimental good for this? Not really intended to test if packages build, but if packages work. :-P > 3a) Is experimental good for anything? Eg; if I have a test package > uploaded to "experimental", with a "Closes:" line in the changelog, will it > close the bug? It'll mark it as fixed-in-experimental (or close it with the appropriate version number, in the future). > Will it typically get autobuilt? Supposedly. (http://experimental.ftbfs.de) > Can I upload the exact same > package to unstable later if it turns out that the bug is indeed fixed? With an extra changelog entry, yes. > The dev. reference says "the experimental packages are automatically > removed once you upload the package in unstable with a higher version > number"... which seems to imply that it's not a *true* staging area, > since I can't promote a package that's byte-for-byte the same. Right, not byte for byte, since an extra changelog entry is needed (*). Who said it was an staging area, anyway? It's an extra distribution, just an incomplete one. (*) To advanced readers of the list: do *not* be evil. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Rosa León - ¡Ay, amor! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
