Re: buildd chroot creation: who should get notified of failures?
On Thu, Dec 21, 2017 at 10:45:52 +0800, Paul Wise wrote: > Hi folks, > > Occasionally the buildd (and porterboxen) fail to debootstrap updated > chroots. Sometimes these are Internet problems, sometimes local network > problems, sometimes mirror problems, sometimes archive problems. These > mails go to DSA but as far as I can tell, we always ignore them, I > certainly do. I have included below a sample of the error messages > since September so folks can get an idea of the errors. > I think they should keep going to DSA and we should take care of them. Cheers, Julien
Nota Fiscal Eletrônica (NF-e): 05:51:45.
(NF-e): Série: 001 Número: 147852 Emitente: INDÚSTRIA E COMERCIO ALFA LTDA CNPJ: 55.407.761/0001-54 Chave da NF-e: 35171255407761000154550010001398901461-Download https://goo.gl/pwgCe2?debian-qa@lists.debian.org Protocolo: 135170808 Para confirmar a Autorização da SEFAZ referente à NF-e mencionada acima acesse o site: www.nfe.fazenda.gov.br/Download XML e PDF NFe/CTe https://goo.gl/pwgCe2?debian-qa@lists.debian.org Este e-mail foi gerado automaticamente
Re: packages that FTBFS twice in a row ...
On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote: > Does the reproducible build effort currently test for reproducibility of > source packages? no. the creation of Debian source packages is not reproducible at the moment. I don't recall whether we found a fundamental problem with it or if simply we had other fishes to fry. (I guess it's probably that this would require pristine-tar which would be a fundamental change if we'd make this a must) -- cheers, Holger signature.asc Description: PGP signature
Re: packages that FTBFS twice in a row ...
Holger Levsen dixit: >On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote: >> Does the reproducible build effort currently test for reproducibility of >> source packages? > >no. the creation of Debian source packages is not reproducible at the >moment. I don't recall whether we found a fundamental problem with it or Debian source packages are the *source* form of everything in Debian; therefore, they are (per definitionem) “correct”, as they are taken and copied, not (re)created. >(I guess it's probably that this would require pristine-tar which would pristine-tar is not perfect and does not work on all architectures or with all workflows, not even all VCSes. This does not sound desirable. Standard workflow for a “second” upload is to download the previous one, reusing the same origtgz, creating a second Debian source pak‐ kage with it, and then using debdiff to validate the changes, anyway. (I do. Don’t you?) So I don’t think that’s something that needs to be explored. bye, //mirabilos -- 13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs 13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you 16:06⎜ Thank god I found you =) 20:03│«bioe007:#cvs» mira2k: ty 18:36⎜«ThunderChicken:#cvs» mirabilos FTW! 23:03⎜«mithraic:#cvs» aaah. thanks
Re: packages that FTBFS twice in a row ...
On Fri, Dec 22, 2017 at 04:59:35PM +, Thorsten Glaser wrote: > >On Thu, Dec 21, 2017 at 05:14:02AM +0100, Andreas Beckmann wrote: > >> Does the reproducible build effort currently test for reproducibility of > >> source packages? > > > >no. the creation of Debian source packages is not reproducible at the > >moment. I don't recall whether we found a fundamental problem with it or > > Debian source packages are the *source* form of everything in Debian; > therefore, they are (per definitionem) “correct”, as they are taken > and copied, not (re)created. yes. the question was, whether it's possible to do this in a bit by bit reproducible way. as became clear again here, this ain't easy and doesn't get us much anyway, so we didnt pursue it further. -- cheers, Holger signature.asc Description: PGP signature
Re: packages that FTBFS twice in a row ...
On Fri, Dec 22, 2017 at 04:32:50PM +, Holger Levsen wrote: > no. the creation of Debian source packages is not reproducible at the > moment. I don't recall whether we found a fundamental problem with it or > if simply we had other fishes to fry. Actually, Guillem went ahead and did this himself. He also thought it would be hard, but after trying only few changes to dpkg were needed. Look: mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % mkdir ../a ../b mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % dpkg-source -b . dpkg-source: info: using options from diffoscope/debian/source/options: --tar-ignore=.*.sw? --tar-ignore=*/*~ --tar-ignore=,,* --tar-ignore=.[#~]* --tar-ignore=.deps --tar-ignore=.git --tar-ignore=.gitattributes --tar-ignore=.gitignore --tar-ignore=.gitmodules dpkg-source: info: using source format '3.0 (native)' dpkg-source: info: building diffoscope in diffoscope_89.tar.xz dpkg-source: info: building diffoscope in diffoscope_89.dsc mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % dcmd mv ../diffoscope_89.dsc ../a mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % dpkg-source -b . dpkg-source: info: using options from diffoscope/debian/source/options: --tar-ignore=.*.sw? --tar-ignore=*/*~ --tar-ignore=,,* --tar-ignore=.[#~]* --tar-ignore=.deps --tar-ignore=.git --tar-ignore=.gitattributes --tar-ignore=.gitignore --tar-ignore=.gitmodules dpkg-source: info: using source format '3.0 (native)' dpkg-source: info: building diffoscope in diffoscope_89.tar.xz dpkg-source: info: building diffoscope in diffoscope_89.dsc mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % dcmd mv ../diffoscope_89.dsc ../b mattia@warren ..vel/reproducible/diffoscope/diffoscope (git)-[master] % cd .. mattia@warren ~/devel/reproducible/diffoscope % diffoscope a/diffoscope_89.dsc b/diffoscope_89.dsc |##| 100% Time: 0:00:00 mattia@warren ~/devel/reproducible/diffoscope % So, yes, source packages can be built reproducibly! :D -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#885017: DDPO: extract_incoming.pl: unxz: (stdin): File format not recognized
Package: qa.debian.org Severity: normal Tags: newcomer User: qa.debian@packages.debian.org Usertags: ddpo Occasionally we get an error mail from the ddpo.incoming cron job like the one below. As far as I can tell this is caused by line 102 from the extract_incoming.pl file. The code should be changed to separate the download from the decompression, print the download errors, check the file before decompressing and print any issues with the file. This way, the QA team can more easily debug the problem. Right now the problem is not debuggable in any way because of the ambiguous error message. open B, "wget $ca_debian -q -O - https://incoming.debian.org/debian-buildd/dists/buildd-$dist/main/source/Sources.xz | unxz |" or die "wget: $!"; https://anonscm.debian.org/git/qa/qa.git/tree/data/ddpo/extract_incoming.pl#n102 From: Cron Daemon To: cron-er...@qa.debian.org Subject:Cron nice -15 flock -n /srv/qa.debian.org/lock/ddpo.incoming /srv/qa.debian.org/data/cronjobs/ddpo.incoming unxz: (stdin): File format not recognized -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
