Re: Bits from the release team (freeze time line)
On Fri, Dec 27, 2013 at 09:47:41PM +0100, Niels Thykier wrote: On 2013-12-27 21:08, Antonio Terceiro wrote: Hi, On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote: We are happy to use results from other automated tests (like autopkgtest [DEP8]) in the same way, as soon as someone runs them on the entire archive and gives us a machine-readable list of the results. [DEP8] http://dep.debian.net/deps/dep8/ I am playing with something for this. It's in a very initial stage, so take it with a grain of salt: http://dep8.debian.net/ Please have a look at http://dep8.debian.net/data/packages.json and let me know what other information you would need there. Hi Antonio, Thanks for looking into it. At first glance, the exported json looks good! I am a bit curious on how we will distinguish a has-no-tests from a not-tested-yet case. My idea was not providing any data at all for packages that do not have DEP-8 tests. Does your runner support retesting packages when a dependency is updated? E.g. if a new version of APT is uploaded, will it schedule the tests for python-apt (assuming the latter has DEP-8 tests)[1]? It is by no means a blocker, but I know there has been interest in the feature. That was actually one of my initial assumptions, so the runner was designed around this feature. It will run tests for a package again when there is a new version of the package or of any package in it dependency chain. One concern I have, though: reusing your example, suppose there are new versions of both Python and APT, and python-apt tests break. How would we know which of them is to blame? Will both of them be blocked from migrating to testing? Before we can integrate it, we will probably need some way of fetching it securely (e.g. via https or ssh). no problem, it should be trivial to put https up. -- Antonio Terceiro terce...@debian.org signature.asc Description: Digital signature
Re: Bits from the release team (freeze time line)
On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: However, using words like known-buggy mips* machines is just FUD against the mips*-ports, and plainly inacceptable, so please stop doing that. (For reference, there is no mipsel machine which has hardware bugs affecting daily operations. There are two mips machines which are pre-series and are not as stable as I wish, but as builddadm I was more occupied recently with arm* machines not stable then with mips machines not stable. This all doesn't mean I think nothing should be changed, but please do not FUD against mips* (or any other architecture).) builddadm does not keep the machines running, DSA does. ball is ancient, corelli and gabrielli are unstable under load and lucatelli does need occasional reboots too, IIRC. But mips and mipsel might not actually be the same bucket you'd want to use, that seems to be the key takeaway here. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#733266: pu: package whois/5.1.0
On Dec 28, Adam D. Barratt a...@adam-barratt.org.uk wrote: This change isn't explicitly documented afaics. Have servers stopped supporting the S flag, or was it not actually supported to begin with? I have forgot the exact details of what it meant, but it was not commonly used and it is not supported anymore by servers: echo '-S 10.0.0.1' | nc whois.ripe.net 43 echo '-S 10.0.0.1' | nc whois.apnic.net 43 -- ciao, Marco signature.asc Description: Digital signature
Re: Bits from the release team (freeze time line)
On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: However, using words like known-buggy mips* machines is just FUD against the mips*-ports, and plainly inacceptable, so please stop doing that. (For reference, there is no mipsel machine which has hardware bugs affecting daily operations. There are two mips machines which are pre-series and are not as stable as I wish, but as builddadm I was more occupied recently with arm* machines not stable then with mips machines not stable. This all doesn't mean I think nothing should be changed, but please do not FUD against mips* (or any other architecture).) builddadm does not keep the machines running, DSA does. ball is ancient, I agree that ball, rem and mayer are indeed ancient. That said despite their age, they are about twice faster as armel and armhf build daemons for building for example libreoffice or qt4-x11. Does they cause any problem from the administration point of view? corelli and gabrielli are unstable under load and lucatelli does need occasional reboots too, IIRC. I agree that corelli and gabrielli are unstable, though it's clearly not related with the load. I am not aware of any issue with lucatelli, do you have some more details? Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131228181425.gb15...@hall.aurel32.net
Bug#733411: migrate only packages built on at least two architectures
Package: release.debian.org User: debian-release@lists.debian.org Usertags: britney Hi, as just discussed on IRC, it would be nice if britney would only migrate packages to testing which are available on at least two architectures (so that we know it had been autobuilt at least once). (For the few exceptions which are only relevant for a single architecture, there would need to be a hint like singlearch package, and also an initial cleanup before activating it sounds a good idea.) Reasoning behind is that as of now britney doesn't get aware if brand new packages FTBFS everywhere e.g. because of broken build dependencies, but would happly migrate such a package to testing (which then couldn't been built in a clean chroot), because the package is current on all architectures it was ever built on. Forcing human work to file RC bugs fast enough doesn't seem reliable, especially if we could automatically detect it. Thanks, Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131228193231.gw12...@mails.so.argh.org
Processed: severity of 733411 is wishlist
Processing commands for cont...@bugs.debian.org: severity 733411 wishlist Bug #733411 [release.debian.org] migrate only packages built on at least two architectures Severity set to 'wishlist' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 733411: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733411 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.138825949512573.transcr...@bugs.debian.org
Processed: tagging 733266
Processing commands for cont...@bugs.debian.org: # The BTS appears to have eaten my first attempt to do this... tags 733266 + wheezy confirmed Bug #733266 [release.debian.org] pu: package whois/5.1.0 Added tag(s) wheezy and confirmed. thanks Stopping processing here. Please contact me if you need assistance. -- 733266: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733266 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.138825999115806.transcr...@bugs.debian.org
Re: Bits from the release team (freeze time line)
On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote: On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: However, using words like known-buggy mips* machines is just FUD against the mips*-ports, and plainly inacceptable, so please stop doing that. (For reference, there is no mipsel machine which has hardware bugs affecting daily operations. There are two mips machines which are pre-series and are not as stable as I wish, but as builddadm I was more occupied recently with arm* machines not stable then with mips machines not stable. This all doesn't mean I think nothing should be changed, but please do not FUD against mips* (or any other architecture).) builddadm does not keep the machines running, DSA does. ball is ancient, I agree that ball, rem and mayer are indeed ancient. That said despite their age, they are about twice faster as armel and armhf build daemons for building for example libreoffice or qt4-x11. Does they cause any problem from the administration point of view? The mipsel machines are working reliably but are probably not replacable if one dies. They could use more memory and it'd be helpful if they booted from SATA (so that we can source new disks if/when the current PATA disks die). corelli and gabrielli are unstable under load and lucatelli does need occasional reboots too, IIRC. I agree that corelli and gabrielli are unstable, though it's clearly not related with the load. I am not aware of any issue with lucatelli, do you have some more details? Of the four Movidis mips machines that I received at ubcece, one was dead on arrival, two have proven unreliable and only one is stable. All four were received with notes indicating that their eth0 was faulty, suggesting that they failed QA. The one that is stable is often so overloaded that we can't actually run any of our regular system administration tasks since the entire system is just thrashing (because there are 2 buildd instances running concurrently, and g++ with large parallelism just eats memory) I think that our core point is that we need the porter community (internal and external) to source production-quality buildd hardware with requisite out of band managment (console power, minimum). DSA is happy to organize the purchase of hardware, if we're pointed to an acceptable vendor. That said, if the external hardware community is interested in having Debian ported to their architecture, then we should not need to purchase hardware. Nor should we need to accept buggy pre-production hardware. So, our concern remains: buildd and porter boxen for the mips* and arm* need some attention from the porter community. Let's work together to get some newer, more capable, bug-free hardware lined up. Maybe even under warranty :) Thanks, Luca -- Luca Filipozzi http://www.crowdrise.com/SupportDebian -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131228195121.ga8...@emyr.net
Re: Bits from the release team (freeze time line)
Hi, On Sat Dec 28, 2013 at 19:51:21 +, Luca Filipozzi wrote: On Sat, Dec 28, 2013 at 07:14:25PM +0100, Aurelien Jarno wrote: On Sat, Dec 28, 2013 at 03:28:04PM +0100, Philipp Kern wrote: On Fri, Dec 27, 2013 at 02:19:07PM +0100, Andreas Barth wrote: However, using words like known-buggy mips* machines is just FUD against the mips*-ports, and plainly inacceptable, so please stop doing that. (For reference, there is no mipsel machine which has hardware bugs affecting daily operations. There are two mips machines which are pre-series and are not as stable as I wish, but as builddadm I was more occupied recently with arm* machines not stable then with mips machines not stable. This all doesn't mean I think nothing should be changed, but please do not FUD against mips* (or any other architecture).) builddadm does not keep the machines running, DSA does. ball is ancient, I agree that ball, rem and mayer are indeed ancient. That said despite their age, they are about twice faster as armel and armhf build daemons for building for example libreoffice or qt4-x11. Does they cause any problem from the administration point of view? The mipsel machines are working reliably but are probably not replacable if one dies. They could use more memory and it'd be helpful if they booted from SATA (so that we can source new disks if/when the current PATA disks die). also, ball and rem currently sit in a a 4U case, which occupies (together with wiggum.debconf.org) 1/3 of the full rack we have at man-da. If we could get better boxes (or replace the machines at all), that would be nice. Cheers, Martin -- Martin Zobel-Helas zo...@debian.orgDebian System Administrator Debian GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131228200013.gb3...@ftbfs.de
Bug#733266: pu: package whois/5.1.0
[Re-sending with a gzipped attachment, as the BTS's spam-checking ate
the original]
Control: tags -1 + wheezy confirmed
On Fri, 2013-12-27 at 23:15 +0100, Marco d'Itri wrote:
whois in stable should be updated due to the many changes in the
database.
I think that the smartest choice would be to reupload the latest
release, once it will have transitioned to testing.
All the changes are either documentation and database changes or
trivial fixes contributed by Red Hat.
The complete diff, after removing the translation updates, is 44 KB,
so maybe it is more practical to review the commits in the git
repository available from https://github.com/rfc1036/whois .
44KB's not that much. :-)
I've attached a copy of the translation-filtered diff between 5.0.23 and
5.1.0 for the record, which I'd be happy to have uploaded to stable as
5.1.0~deb7u1 with a suitable changelog stanza. One query:
while ((ch = GETOPT_LONGISH(argc, argv,
- abBcdFg:Gh:Hi:KlLmMp:q:rRs:St:T:v:V:x, longopts, 0)) 0) {
+ abBcdFg:Gh:Hi:KlLmMp:q:rRs:t:T:v:V:x, longopts, 0)) 0) {
[...]
/* flags for RIPE-like servers */
-const char *ripeflags=abBcdFGKlLmMrRSx;
+const char *ripeflags=abBcdFGKlLmMrRx;
This change isn't explicitly documented afaics. Have servers stopped
supporting the S flag, or was it not actually supported to begin with?
Regards,
Adam
whois_5.0.23-5.1.0.diff.gz
Description: GNU Zip compressed data
Bug#733411: migrate only packages built on at least two architectures
Andreas Barth a...@ayous.org (2013-12-28): as just discussed on IRC, it would be nice if britney would only migrate packages to testing which are available on at least two architectures (so that we know it had been autobuilt at least once). No, we wouldn't know that. _multi.changes, etc. Mraw, KiBi. signature.asc Description: Digital signature
Bug#733411: migrate only packages built on at least two architectures
* Cyril Brulebois (k...@debian.org) [131228 21:38]: Andreas Barth a...@ayous.org (2013-12-28): as just discussed on IRC, it would be nice if britney would only migrate packages to testing which are available on at least two architectures (so that we know it had been autobuilt at least once). No, we wouldn't know that. _multi.changes, etc. Well, we at least would have way better changes. Im not speaking about cheating maintainers, but about maintainers making simple errors. This isn't the 100%-approach, but the 95% we can get easily. Anyways, not my decision. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131228213000.gx12...@mails.so.argh.org
