Re: s390 build box?
* 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!
Reply to: