Re: reporting FTBFS bugs
Adeodato Simó wrote: hi, I have some questions regarding FTBFS bugs. Sorry if they seem too naive but I'm always afraid of doing something wrong and I thought I'd better ask here then. 1. if a package fails in any buildd machine, thats a FTBFS bug per se, right? Uuuusually. If it failed because the buildd admin killed it, it's not. 2. who can/should report FTBFS bugs when they occur in a buildd machine? I've mostly seen them reported by the buildd's admin, but cyrus-sasl2-mit failed on arm more than a month ago [1] (but I noticed today) and there has been no bug report. I report them a lot. 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Nope. Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. So I'm mainly asking if it is OK to file the bug myself, and if that should be reported elsewhere. TIA and sorry for the annoyance, [1] http://buildd.debian.org/build.php?arch=armpkg=cyrus-sasl2-mit -- There are none so blind as those who will not see.
Re: reporting FTBFS bugs
Adeodato Sim wrote: hi, I have some questions regarding FTBFS bugs. Sorry if they seem too naive but I'm always afraid of doing something wrong and I thought I'd better ask here then. 1. if a package fails in any buildd machine, thats a FTBFS bug per se, right? Uuuusually. If it failed because the buildd admin killed it, it's not. 2. who can/should report FTBFS bugs when they occur in a buildd machine? I've mostly seen them reported by the buildd's admin, but cyrus-sasl2-mit failed on arm more than a month ago [1] (but I noticed today) and there has been no bug report. I report them a lot. 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Nope. Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. So I'm mainly asking if it is OK to file the bug myself, and if that should be reported elsewhere. TIA and sorry for the annoyance, [1] http://buildd.debian.org/build.php?arch=armpkg=cyrus-sasl2-mit -- There are none so blind as those who will not see.
Re: reporting FTBFS bugs
On 2004-05-27 Adeodato Simó [EMAIL PROTECTED] wrote: [...] 1. if a package fails in any buildd machine, thats a FTBFS bug per se, right? It is not necessarily a bug in the package, if that is what you are asking, some dependency might not be ready, the buildd might be broken (out of diskspace) or toolchain might be installed in a buggy version. 2. who can/should report FTBFS bugs when they occur in a buildd machine? I've mostly seen them reported by the buildd's admin, but cyrus-sasl2-mit failed on arm more than a month ago [1] (but I noticed today) and there has been no bug report. buildd-maintainers regularily check the build-logs, it is natural that they often submit these bug-reports. 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. Not that I am aware of. - You could check the archives of debian-arm. So I'm mainly asking if it is OK to file the bug myself, and if that should be reported elsewhere. Yes, it is ok, and the BTS is imho the correct place. TIA and sorry for the annoyance, no problem, there was no annoyance involved. ;-) [1] http://buildd.debian.org/build.php?arch=armpkg=cyrus-sasl2-mit Hmm. if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../plugins -c -o dlopen.lo `test -f 'dlopen.c' || echo './'`dlopen.c; \ then mv -f .deps/dlopen.Tpo .deps/dlopen.Plo; \ else rm -f .deps/dlopen.Tpo; exit 1; \ fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../plugins -I../include -I/usr/include/kerberos gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../plugins -I../include -I/usr/include/kerberos make[3]: *** [dlopen.lo] Error 1 [long lines simply cut off] Strange. The buildlog simply tells absolutely nothing. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash
Re: reporting FTBFS bugs
* Andreas Metzler [Thu, 27 May 2004 19:29:02 +0200]: On 2004-05-27 Adeodato Simó [EMAIL PROTECTED] wrote: [...] 1. if a package fails in any buildd machine, thats a FTBFS bug per se, right? It is not necessarily a bug in the package, if that is what you are asking, some dependency might not be ready, the buildd might be broken (out of diskspace) or toolchain might be installed in a buggy version. yep, I thought it later. 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. Not that I am aware of. - You could check the archives of debian-arm. I looked there, and nothing. So I'm mainly asking if it is OK to file the bug myself, and if that should be reported elsewhere. Yes, it is ok, and the BTS is imho the correct place. TIA and sorry for the annoyance, no problem, there was no annoyance involved. ;-) ok, thanks! -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The true teacher defends his pupils against his own personal influence. -- Amos Bronson Alcott
Re: reporting FTBFS bugs
On Thu, May 27, 2004 at 07:58:54PM +0200, Adeodato Simó [EMAIL PROTECTED] wrote: 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. Not that I am aware of. - You could check the archives of debian-arm. Well, if I have a bug filed against any of my packages, and I am working on fixing it, then I set the flag 'confirmed', and when it is fixed, but not yet uploaded, I set 'pending'. But that's me, others may not do this way. Cheers, Laszlo
Re: reporting FTBFS bugs
On 2004-05-27 Adeodato Simó [EMAIL PROTECTED] wrote: [...] 1. if a package fails in any buildd machine, thats a FTBFS bug per se, right? It is not necessarily a bug in the package, if that is what you are asking, some dependency might not be ready, the buildd might be broken (out of diskspace) or toolchain might be installed in a buggy version. 2. who can/should report FTBFS bugs when they occur in a buildd machine? I've mostly seen them reported by the buildd's admin, but cyrus-sasl2-mit failed on arm more than a month ago [1] (but I noticed today) and there has been no bug report. buildd-maintainers regularily check the build-logs, it is natural that they often submit these bug-reports. 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. Not that I am aware of. - You could check the archives of debian-arm. So I'm mainly asking if it is OK to file the bug myself, and if that should be reported elsewhere. Yes, it is ok, and the BTS is imho the correct place. TIA and sorry for the annoyance, no problem, there was no annoyance involved. ;-) [1] http://buildd.debian.org/build.php?arch=armpkg=cyrus-sasl2-mit Hmm. if /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../plugins -c -o dlopen.lo `test -f 'dlopen.c' || echo './'`dlopen.c; \ then mv -f .deps/dlopen.Tpo .deps/dlopen.Plo; \ else rm -f .deps/dlopen.Tpo; exit 1; \ fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../plugins -I../include -I/usr/include/kerberos gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../plugins -I../include -I/usr/include/kerberos make[3]: *** [dlopen.lo] Error 1 [long lines simply cut off] Strange. The buildlog simply tells absolutely nothing. cu andreas -- See, I told you they'd listen to Reason, [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in Snow Crash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reporting FTBFS bugs
* Andreas Metzler [Thu, 27 May 2004 19:29:02 +0200]: On 2004-05-27 Adeodato Simó [EMAIL PROTECTED] wrote: [...] 1. if a package fails in any buildd machine, thats a FTBFS bug per se, right? It is not necessarily a bug in the package, if that is what you are asking, some dependency might not be ready, the buildd might be broken (out of diskspace) or toolchain might be installed in a buggy version. yep, I thought it later. 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. Not that I am aware of. - You could check the archives of debian-arm. I looked there, and nothing. So I'm mainly asking if it is OK to file the bug myself, and if that should be reported elsewhere. Yes, it is ok, and the BTS is imho the correct place. TIA and sorry for the annoyance, no problem, there was no annoyance involved. ;-) ok, thanks! -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The true teacher defends his pupils against his own personal influence. -- Amos Bronson Alcott -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reporting FTBFS bugs
On Thu, May 27, 2004 at 07:58:54PM +0200, Adeodato Sim [EMAIL PROTECTED] wrote: 3. is it tracked anywhere (other than the bug report, non-existant in this case) if this is being worked on? Having a month passed, I'd assume that the maintainer isn't aware of this, but I really can't tell. Not that I am aware of. - You could check the archives of debian-arm. Well, if I have a bug filed against any of my packages, and I am working on fixing it, then I set the flag 'confirmed', and when it is fixed, but not yet uploaded, I set 'pending'. But that's me, others may not do this way. Cheers, Laszlo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
