Re: Shutdown of servers at AQL (mips*el porterbox and buildds)
Dear all, On 2023-11-23 07:11, Aurelien Jarno wrote: > Dear all, > > Our hosting agreement with AQL has ended. As a result we need to unrack > the servers that were hosted there. We are working on relocating them or > setting up new servers elsewhere. > > The list of affected services are: > - eller.d.o (mips*el porterbox) eberlin.d.o has been setup as a mips*el porterbox to replace eller.d.o. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: reinstallation of the riscv64 porterbox
Dear all, On 2023-12-27 22:27, Aurelien Jarno wrote: > Dear all, > > As part of making riscv64 as an official architecture, the riscv64 porterbox > will be reinstalled. For this reason, it will be unavailable for a couple of > days. It will then come back as ricci.debian.org. The reinstallation is now done, the porterbox is now accessible as ricci.debian.org. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Re: ppc64el porterbox replacement: plummer.d.o -> platti.d.o
Hi, On 2022-10-22 13:16, David Bremner wrote: > Aurelien Jarno writes: > > > Dear all, > > > > We lost access to the Power9 machine hosted at Unicamp, which was > > hosting the ppc64el porterbox called plummer.d.o. A new porterbox called > > platti.d.o has been setup as a replacement. > > > > Regards, > > Aurelien > > > It would be nifty if someone (TM) would update where > ppc64el-porterbox.debian.net points to. > Jakub, could you please update it? Thanks Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: mips(64)el porterbox downtime
On 2016-08-24 23:18, Aurelien Jarno wrote: > Dear all, > > The mipsel and mips64el porterbox, etler.d.o, will be shutdown and > decommissioned in about 12h. It will be replaced by a faster Octeon III > based machine, whose name hasn't been chosen yet. It will be installed > in the datacenter on Friday, so expect it to installed and accessible > during the week-end. > > It means that there will be a few days without mips(64)el porterbox. For > generic 32-bit MIPS porting the big endian porterbox, minkus.d.o, might > be used instead. The new porterbox is now available. It is called eller.debian.org. Sorry for the inconvenience. Enjoy! Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Re: does Debian help detect gravitational waves?
On 2016-02-13 19:56, Yaroslav Halchenko wrote: > > On Sun, 14 Feb 2016, Aurelien Jarno wrote: > > > https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html > > > > The Ganglia graph (top right corner of the page) appears to be generated > > > on a Debian host using the official packages (it has ganglia-webfrontend > > > in the URL) > > > > Drill down into the Ganglia reports and we can even see things like > > > kernel package version > > > > http://silkspectre.cgca.uwm.edu/ganglia/?r=hour===os_release=by+name=NEMO=_regex=_graphs=0=m==1=small=4 > > > > os_release: 3.16.0-0.bpo.4-amd64 > > > > Please have a look at the article (BTW released under CC license): > > > https://journals.aps.org/prl/pdf/10.1103/PhysRevLett.116.061102 > > > The article itself has one thousand of authors from 133 different > > institutes member of the LIGO and VIRGO cooperation. It is a result of > > a huge amount of work by thousands of persons in the last 15 years to > > design, build, improve, operate the instrument, but also to work on the > > theory or simulation. > > > For sure Debian has been used somewhere, just like Slackware, MS-DOS, > > HP-UX or any other system have helped at some moment. Just looking at > > one random website from one small subpart of the whole project to > > conclude about the Debian implication in the whole project just doesn't > > make sense. It is just like deducing that pelican helps the Debian > > project because it is used on the Debian blog. > > FWIW that link > https://www.lsc-group.phys.uwm.edu/lscdatagrid/doc/reference-platform.html > at least now has already explicit listing > > Reference Operating Systems > > Scientific Linux 6.1 > Debian 6.0 Squeeze > CentOS 5.3 (to be deprecated) > Debian 5.0, Lenny (to be deprecated) > > So I guess Debian was of some notable help, and I am really glad that our work > at least tiny bit contributed to this event. But that is it. Somewhat > twisting while overall agreeing with the point of Aurelien's reply -- > Debian was probably used somewhere along the way of any recent sizeable > research endeavor simply because it is used in so many scenarios and places. Look at the acknowledgment section, especially the computing resources part: | The authors gratefully acknowledge the support of the NSF, STFC, MPS, | INFN, CNRS and the State of Niedersachsen, Germany, for provision of | computational resources. Therefore one should look at much more than the above website to even get an idea about the Debian place in this project. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Bug#805237: makes gcc-5 FTBFS on s390x: ld segfaults linking libstdc++
control: severity -1 serious On 2015-11-16 00:45, Helmut Grohne wrote: > Hi Matthias, > > On Sun, Nov 15, 2015 at 11:43:49PM +0100, Matthias Klose wrote: > > you really like to exaggerate things. Please could you take a step back? > > The rebootstrap goal doesn't automatically qualify for RC issues. Just take > > it. > > You are right here in that rebootstrap bugs are not automatically RC > bugs. You also notice that very few of the bugs I file are RC bugs as > you received quite a few of them. So when a package (e.g. gcc-5) FTFBS > (without involving cross toolchains at all) on a release architecture > (e.g. s390x) and built earlier, then that's an RC bug, no? > The bug has been triggered on the build daemons: https://buildd.debian.org/status/fetch.php?pkg=gcc-4.8=s390x=4.8.5-2=1447893885 https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9=s390x=4.9.3-6=1447956518 https://buildd.debian.org/status/fetch.php?pkg=gcc-4.9=s390x=4.9.3-7=1447972159 https://buildd.debian.org/status/fetch.php?pkg=gcc-5=s390x=5.2.1-24=1448145029 I am therefore increasing the severity of this bug. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
alpha architecture imported in debian-ports.org
Hi all, The debian-ports.org service has been moved to a new machine last week-end, which allowed to add new architectures. I have therefore imported the alpha architecture (both unstable and experimental) as of 2011-05-07 to debian-ports.org. Unfortunately I have not been able to find signed .changes file for the .deb files listed in [2]. They are present on the debian-ports.org ftp server, but given it's not possible to verify their checksum against a signed .changes file, they are not listed in the Packages file. This can be fixed by either adding the missing .changes file if they can be found later, or by triggering binNMU once the build daemons have been started. To use the new archive, you should first install the debian-ports-archive-keyring package [3], and then you modify your /etc/apt/sources.list as follow, or using a mirror listed on [4]: deb http://ftp.debian-ports.org/debian unstable main deb http://ftp.debian-ports.org/debian unreleased main The source entry should still point to a Debian mirror. The unreleased entry is there for packages that need to be patched with regard to the official Debian sources to be built on alpha. More details are available on [5]. Michael Cree mc...@orcon.net.nz and Bill MacAllister w...@stanford.edu have expressed their interest in maintaining this port in the future, please coordinate with them if you are also interested. Regards, Aurelien [1] http://lists.debian.org/debian-infrastructure-announce/2011/04/msg1.html [2] debian/pool/main/a/apf/apf-client_0.8.4-1_alpha.deb debian/pool/main/a/apf/apf-server_0.8.4-1_alpha.deb debian/pool/main/c/coldfire/coldfire_0.2.2-2.1_alpha.deb debian/pool/main/c/cramfsswap/cramfsswap_1.4.1_alpha.deb debian/pool/main/d/dime/dime_0.20030921-2_alpha.deb debian/pool/main/d/dime/libdime_0.20030921-2_alpha.deb debian/pool/main/d/dircproxy/dircproxy_1.0.5-5.1_alpha.deb debian/pool/main/e/elfsign/elfsign_0.2.2-2_alpha.deb debian/pool/main/f/francine/francine_0.99.8orig-6_alpha.deb debian/pool/main/g/gpx2shp/gpx2shp_0.69-3_alpha.deb debian/pool/main/h/hsetroot/hsetroot_1.0.2-1_alpha.deb debian/pool/main/liba/libapache2-mod-auth-pgsql/libapache2-mod-auth-pgsql_2.0.3-5_alpha.deb debian/pool/main/liba/libapache2-mod-rpaf/libapache2-mod-rpaf_0.5-3_alpha.deb debian/pool/main/libm/libmail-pop3client-perl/libmail-pop3client-perl_2.17-1_alpha.deb debian/pool/main/l/lv/lv_4.51-2_alpha.deb debian/pool/main/m/makejvf/makejvf_1.1a+0-2_alpha.deb debian/pool/main/m/mkcue/mkcue_1-2.1_alpha.deb debian/pool/main/m/mod-mime-xattr/libapache2-mod-mime-xattr_0.4-4_alpha.deb debian/pool/main/m/mp3rename/mp3rename_0.6-9_alpha.deb debian/pool/main/p/palbart/palbart_2.4-5_alpha.deb debian/pool/main/p/perl-byacc/perl-byacc_2.0-6_alpha.deb debian/pool/main/p/photopc/photopc_3.05-6_alpha.deb debian/pool/main/s/starvoyager/starvoyager_0.4.4-5_alpha.deb debian/pool/main/s/statserial/statserial_1.1-22_alpha.deb debian/pool/main/s/stax/stax_1.0-13_alpha.deb debian/pool/main/s/stereograph/stereograph_0.30a-6_alpha.deb debian/pool/main/t/tf/tf_4.0s1-17_alpha.deb debian/pool/main/t/tuxeyes/tuxeyes_0.0.3-8_alpha.deb debian/pool/main/t/tuxpuck/tuxpuck_0.8.2-2.1_alpha.deb debian/pool/main/w/wordplay/wordplay_7.22-17_alpha.deb debian/pool/main/w/wp2x/wp2x_2.5-mhi-9_alpha.deb [3] http://packages.debian.org/debian-ports-archive-keyring [4] http://www.debian-ports.org/mirrors [5] http://www.debian-ports.org/archive -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
hppa architecture imported in debian-ports.org
Hi all, The debian-ports.org service has been moved to a new machine last week-end, which allowed to add new architectures. I have therefore imported the hppa architecture (both unstable and experimental) as of 2011-05-07 to debian-ports.org. Unfortunately I have not been able to find signed .changes file for the .deb files listed in [2]. They are present on the debian-ports.org ftp server, but given it's not possible to verify their checksum against a signed .changes file, they are not listed in the Packages file. This can be fixed by either adding the missing .changes file if they can be found later, or by triggering binNMU once the build daemons have been started. To use the new archive, you should first install the debian-ports-archive-keyring package [3], and then you modify your /etc/apt/sources.list as follow, or using a mirror listed on [4]: deb http://ftp.debian-ports.org/debian unstable main deb http://ftp.debian-ports.org/debian unreleased main The source entry should still point to a Debian mirror. The unreleased entry is there for packages that need to be patched with regard to the official Debian sources to be built on hppa. More details are available on [5]. Despite a few hppa people complaining about the removal of this architecture from the official archive [6], nobody answered my emails [7]. I am still waiting for some people to maintain this port in the future. Regards, Aurelien [1] http://lists.debian.org/debian-infrastructure-announce/2011/04/msg1.html [2] debian/pool/main/a/apf/apf-client_0.8.4-1_hppa.deb debian/pool/main/a/apf/apf-server_0.8.4-1_hppa.deb debian/pool/main/c/coldfire/coldfire_0.2.2-2.1_hppa.deb debian/pool/main/c/cramfsswap/cramfsswap_1.4.1_hppa.deb debian/pool/main/d/dircproxy/dircproxy_1.0.5-5.1_hppa.deb debian/pool/main/e/elfsign/elfsign_0.2.2-2_hppa.deb debian/pool/main/f/francine/francine_0.99.8orig-6_hppa.deb debian/pool/main/g/gpx2shp/gpx2shp_0.69-3_hppa.deb debian/pool/main/h/hsetroot/hsetroot_1.0.2-1_hppa.deb debian/pool/main/liba/libapache2-mod-auth-pgsql/libapache2-mod-auth-pgsql_2.0.3-5_hppa.deb debian/pool/main/libm/libmail-pop3client-perl/libmail-pop3client-perl_2.17-1_hppa.deb debian/pool/main/l/lv/lv_4.51-2_hppa.deb debian/pool/main/m/makejvf/makejvf_1.1a+0-2_hppa.deb debian/pool/main/m/mkcue/mkcue_1-2.1_hppa.deb debian/pool/main/m/mod-mime-xattr/libapache2-mod-mime-xattr_0.4-4_hppa.deb debian/pool/main/m/mountpy/mountpy_0.8.1_hppa.deb debian/pool/main/m/mp3rename/mp3rename_0.6-9_hppa.deb debian/pool/main/p/palbart/palbart_2.4-5_hppa.deb debian/pool/main/p/perl-byacc/perl-byacc_2.0-6_hppa.deb debian/pool/main/p/photopc/photopc_3.05-6_hppa.deb debian/pool/main/s/sanduhr/sanduhr_1.93-4_hppa.deb debian/pool/main/s/statserial/statserial_1.1-22_hppa.deb debian/pool/main/s/stax/stax_1.0-13_hppa.deb debian/pool/main/s/stereograph/stereograph_0.30a-6_hppa.deb debian/pool/main/t/tf/tf_4.0s1-17_hppa.deb debian/pool/main/t/tinyirc/tinyirc_1.1.dfsg.1-1_hppa.deb debian/pool/main/t/tuxpuck/tuxpuck_0.8.2-2.1_hppa.deb debian/pool/main/u/udo/udo_6.4.1-1_hppa.deb debian/pool/main/w/wordplay/wordplay_7.22-17_hppa.deb debian/pool/main/w/wp2x/wp2x_2.5-mhi-9_hppa.deb [3] http://packages.debian.org/debian-ports-archive-keyring [4] http://www.debian-ports.org/mirrors [5] http://www.debian-ports.org/archive [6] http://lists.debian.org/debian-hppa/2011/04/msg2.html http://lists.debian.org/debian-hppa/2011/04/msg7.html [7] http://lists.debian.org/debian-hppa/2011/04/msg00021.html http://lists.debian.org/debian-hppa/2011/04/msg00026.html -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: debian-ports.org migration
On Sat, Apr 30, 2011 at 11:54:56PM +0200, Aurelien Jarno wrote: Hi all, As some of you might already be aware, debian-ports.org is moving to a new machine, which should solve our disk space issues and secure the hosting for the future. This machine is now hosted by Debian and is called leda.debian.net [1]. Thanks to DSA for making that possible. The migration will happen tomorrow, Sunday May 1st, and the various services will be unavailable during a few hours in order to do the final synchronisation between the two machines. DNS will be updated after this, so most people won't notice any change. The migration was finished today around 12:00 UTC, but I waited a bit more for having a full run of all the scripts before announcing everything was fine. The services are now all running, however it happens that the I/O are quite slow on the new machine, archive install taking more than 7 hours instead of less than 1 hour before. Until the problem is understood and fixed, I have changed the crontab to only run 2 archive-install per day instead of 4. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: buildd/porter/maintainer roles again
On Mon, Jul 12, 2010 at 06:05:45PM +, Clint Adams wrote: Shouldn't it be the responsibility of the buildd admin (if, for some reason, the buildd admin is not a porter) to notify an architecture's porters of any porting issues manifesting themselves in a package build? I think you made a point, there is clearly a problem of communication between packages maintainer / buildd maintainer and porters. Packages maintainer are often waiting for porters to fix an issue they are not aware. Even if they have been made aware, the issue can easily be lost if not correctly tracked. We are missing some tools here. The BTS is IMHO the most suitable tool to do that, and it is already used by the security team that way. When a bug is tagged security, the security team receives a copy of every mail sent to this bug. We can imagine doing the same for the porters, in other words adding tags for each architectures (some of them might be grouped like mips and mipsel), and getting the corresponding port mailing list receiving the mail. We can also imagine that every week the porter mailing list receives a list of the opened issue like it is done for example for RC bugs. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713201732.gi18...@hall.aurel32.net
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 02:27:42PM -0700, Don Armstrong wrote: On Tue, 13 Jul 2010, Hector Oron wrote: 2010/7/13, Russ Allbery r...@debian.org: But if those steps fail and it gets to the point where I'm actively asking for help, my customary experience has been to never get any reply. Mail seems to just disappear into a black hole. Sometimes this is true even for a requeue request, although mostly those do get handled, but anything asking for more details seems to rarely get any reply. We are persons, and mail stack grows fast. So, suggested use of BTS should be encouraged. Tagging packages for porters to have a look might be a really good idea. If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] While I agree it should go through the BTS, I am not sure pseudo-packages are the best for that. In most cases fixing a porting issue is not the responsibility of the maintainer nor the porter, but both together. With pseudo-packages it will end-up as bugs reassigned to the pseudo-packages (to the porters), with the maintainers being satisfied of having one bug less to care. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713213632.gj18...@hall.aurel32.net
Re: buildd/porter/maintainer roles again
On Tue, Jul 13, 2010 at 02:50:03PM -0700, Don Armstrong wrote: On Tue, 13 Jul 2010, Aurelien Jarno wrote: On Tue, Jul 13, 2010 at 02:27:42PM -0700, Don Armstrong wrote: If porters would like psuedopackages for their architecture to track requests, that can be arranged. [Y'all just need to ask, point me at some bugs which should be assigned to them, tell me the maintainer address, and provide the blurb that goes on http://www.debian.org/Bugs/pseudo-packages.] While I agree it should go through the BTS, I am not sure pseudo-packages are the best for that. In most cases fixing a porting issue is not the responsibility of the maintainer nor the porter, but both together. With pseudo-packages it will end-up as bugs reassigned to the pseudo-packages (to the porters), with the maintainers being satisfied of having one bug less to care. You can reassign bugs to multiple packages or use affects to indicate that a bug affects multiple packages, so this isn't really a problem. What we really need here is the push method. If the information arrives directly on the porter mailing list it might be taken into account. With the pull method where people have to regularly fetch the information, it never works. While what your offer probably answers to this problem, I would be more happy with something based on tags as it is already for the security bugs. OTOH I don't know about the internals and haven't thought in details about the advantages and drawbacks of each method. I would already be happy with pseudo packages. That said, whatever way porters want to keep track of bugs which maintainers need assistance with is fine by me. It's even fine if different architectures choose different methods. I think on the contrary that we should have the same and easy method on all architectures, so that we can have this method recorded somewhere for package maintainers. If we have different and complex methods (like we already have with a few user tags for some architecture), people never apply them. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100713220653.gk18...@hall.aurel32.net
Re: Debian decides to adopt time-based release freezes
not, the changes are still (IME) published to Debian ASAP when they make sense in a Debian context. Yes, the eglibc package in Debian and Ubuntu are very close, simply because Ubuntu does not do real changes (or bad changes that we don't want to see, like ignoring the testsuite failures without understanding the problem), so there is almost nothing back to contribute... People are often complaining that Ubuntu doesn't give back their patches to Debian, they are wrong as the reason is that often such patches do not really exists. Now perhaps what you mean isn't that you expect Ubuntu to collaborate better, but that you expect Ubuntu /to do more of the work/. That's a different question, and not one that can be solved at the level of individual developers - the Ubuntu developer community is much smaller than the Debian developer community, and if the work output from Ubuntu doesn't meet your expectations, it's not because Ubuntu developers are sitting idle waiting for Debian to do all the work. You are touching the problem here. You've also told me on IRC that Matthias Klose does not have a lot of time to work on the glibc side. That's were the business model of Canonical fails (to be friendly in the Open Source community, to makes money it probably works well). Canonical put a lot of manpower and money on the Gnome project as it is what the end user sees, but forgets that a GNU/Linux distribution is also made, among other things, of a Linux kernel and a libc. It won't work without those essential components. The Free Software is not about taking the work from others, it is also about sharing part of the work. If you look a bit, the contribution of Ubuntu on the (E)GLIBC packaging represents very few, and if you look at the upstream side it's even less. Debian or Gentoo separately contributes a lot more than Ubuntu. If Ubuntu does not want to share part of the work, it's a choice, but then don't be surprise that Debian doesn't want to contribute. I also don't buy the argument upstream being uncooperative as an explanation for the number of contributions. This surely doesn't help, but it does not prevent to submit bugs or patches. Even if the patch is ignore or rejected, other people are looking at the bug tracker and the mailing lists, and will re-use them, exactly like Debian re-use patches like that posted by other distributions. Also you now also have the option to re-submit it to EGLIBC. Sometimes the patches are rewritten and the attributions lost in the meanwhile, but as the lists are public, this does not prevent other persons following them to recognize your work. That said I really appreciate the effort put by Ubuntu on working on multiarch with Debian. This is an example that contribution can work well when both side play the game. Unfortunately that does not seems to be the case on all domains. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Mon, Aug 03, 2009 at 09:15:03PM +0200, Cyril Brulebois wrote: Bernd Zeimetz be...@bzed.de (03/08/2009): Ack ack ack. I even have the impression that the Canonical employees want to ensure that Debian gets important things much much later than Ubuntu. Obviously false, see how (e)glibc maintainers are pushed by Ubuntu people to get the next release ready, ignoring their own bugs? And for the ones they can't ignore, forwarding them directly in the Debian BTS, even if they correspond to a version that has never been uploaded to the Debian archive. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Tue, Aug 04, 2009 at 09:28:18PM +0200, Aurelien Jarno wrote: On Mon, Aug 03, 2009 at 09:15:03PM +0200, Cyril Brulebois wrote: Bernd Zeimetz be...@bzed.de (03/08/2009): Ack ack ack. I even have the impression that the Canonical employees want to ensure that Debian gets important things much much later than Ubuntu. Obviously false, see how (e)glibc maintainers are pushed by Ubuntu people to get the next release ready, ignoring their own bugs? And for the ones they can't ignore, forwarding them directly in the Debian BTS, even if they correspond to a version that has never been uploaded to the Debian archive. And to the upstream BTS, mentioning both Ubuntu and Debian bugs. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Thu, Jul 30, 2009 at 03:24:03PM +0200, Raphael Hertzog wrote: On Thu, 30 Jul 2009, Modestas Vainius wrote: So let's just freeze late in the early/middle spring of 2010 this time and aim for Dec 2011 freeze next time. If you disagree with that, please enlighten me why Debian needs to rush _this time_. If synchronization is so badly wanted for the next Debian release, why not to synchronize with Ubuntu 10.10 (as an experiment)? Luk explained in the RM keynote that they do not want the freeze to conflict with debconf so that developers are free to work on new stuff aimed at unstable in this (usually productive) week. That's probably a good point to avoid that. But given that Squeeze is going to be an exception by the short release cycle anyway, why can't we add another exception that the first freeze is not December, even if it means the other implied exception is that we are in freeze for Debconf *10* (and not for every Debconf)? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
On Wednesday 29 July 2009, Meike Reichle wrote: The Debian project has decided to adopt a new policy of time-based development freezes for future releases, on a two-year cycle. I am fine with that, at least I think we should give a chance to this method. They are some concerns about bad synchronisation with some upstream projects, but I am sure we can find some arrangements. Freezes will from now on happen in the December of every odd year, which means that releases will from now on happen sometime in the first half of every even year. To that effect the next freeze will happen in December 2009, with a release expected in spring 2010. I have a lot more problems with that. If this short release cycle had been announced a few weeks after the release of Lenny, it would have been fine. With such a late announce, a lot of developers and teams have already made their schedule and plans based on a roughly 2 year release for Squeeze, and it is really frustrating to have cut them down. I am also really concerned by the state of the release team. Sid is opened again for 5 months, and the freeze will happen in 5 months, so we are just in the middle. If we look a bit what happens on the release team since the release of Lenny, it has simply been absent. A lot of mails on debian-release about hints or binNMU are ignored, mails about transitions are answered very late. The recent MySQL transition is just an example. Last but not least, the transitions are not really managed and take a lot of time (for example QEMU is blocked out of testing for 2 months due to the bluez transition). That's why I would like to ask a single question to the release team: What are your plans to ensure the development process of Squeeze is not slowed down by migration and transitions issues? Or said otherwise how the release team is going to ensure fast reaction to the requests on the mailing list and short transitions (more one week than two months)? The three new release assistants seems to be a first answer to that, but I really doubt it is enough. Cheers, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Re-thinking Debian membership
On Fri, Oct 24, 2008 at 11:44:03AM +0300, Lars Wirzenius wrote: [snip] Proposal * People should be allowed to join Debian when there is reasonably wide-spread consensus that they agree with the project's goals, are committed to working on those goals, and are trustworthy. The best way to determine this is to have some number of people endorse a candidate. However, there should not be too much opposition to a candidate, either. Concrete proposal: max(Q, 20) endorsements, two existing members together can veto. The veto can be done anonymously via the Debian Account Manager to avoid peer pressure to not veto. The DAM only counts the endorsements and vetos, and does not make judgement calls. All endorsements and vetos must happen within 30 days. * Membership in the project gives both voting and upload rights. * Membership ends 24 months after they're given, or after the latest participation in a vote arranged by the project's Secretary. Members may retire themselves earlier, of course. * Members may be expelled via the normal General Resolution process, with a simple majority. Ftpmasters may temporarily limit upload rights in an emergency. * Membership is controlled via GnuPG keyrings, primarily maintained by the Debian Account Manager. The keyrings shall be maintained in a way that allows any member to change them, and that is fully transparent to the members in general, and that further makes it easy to undo mistakes. * Upload sponsorships and the limited upload rights via the Debian Maintainer status are unaffected by this proposal. I really like your proposal, it is simple and at the same time it is able to solve lot of problems: NM, MIA, DAM SPOF... There is still some minor changes I would like to see (for example I really think that a new member should still agree with DMUP/SC/DFSG), but I consider it a really good basis to start a productive discussion. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net signature.asc Description: Digital signature
Re: Re-thinking Debian membership
Ana Guerrero a écrit : Hi Lars, Thank you a lot for taking the time in drawing this nice proposal. I like it in overall, but with some little changes, that have been already covered in previous emails. Still I am commenting them. On Fri, Oct 24, 2008 at 11:44:03AM +0300, Lars Wirzenius wrote: [...] I think we should go in the opposite direction: massively simplify the whole membership thing. Totally agree on this. [Huge part of the email removed] Proposal * People should be allowed to join Debian when there is reasonably wide-spread consensus that they agree with the project's goals, are committed to working on those goals, and are trustworthy. The best way to determine this is to have some number of people endorse a candidate. However, there should not be too much opposition to a candidate, either. Concrete proposal: max(Q, 20) endorsements, two existing members together can veto. The veto can be done anonymously via the Debian Account Manager to avoid peer pressure to not veto. The DAM only counts the endorsements and vetos, and does not make judgement calls. All endorsements and vetos must happen within 30 days. I think max (Q, 20) is a high number, maybe max (Q, 10) ? And as well, 2 person vetoing seems like a small number, maybe 4 or 5? * Membership in the project gives both voting and upload rights. I think it is important everybody having the same rights, voting and uploading power. Even if some people never will be interested in voting (I do understand people who do not care about the DPL election), or you are an translator who never will make a upload. Still, documentation maintainers might want upload their docs package, translators could do QA uploads adding translations and so on. You do not really need so much skills for maintaning an easy package. For example, a python module is really easy to maintain, and in case of problems, you have the support of the python modules team where you can ask or another member can easily help you since all it is team maintained. I expect this work because I hope when developers endorse somebody for becoming a member of the project, endorses somebody who not is only interested in the project technically and philosophically, besides people who they trust and have some common sense... * Membership ends 24 months after they're given, or after the latest participation in a vote arranged by the project's Secretary. Members may retire themselves earlier, of course. No, please, voting should be voluntary. On one side I understand that you don't want make voting mandatory, but I really like the idea of: - activity = you keep your membership - inactivity = you lose your membership Maybe we could find another way to define activity, like (upload || vote || svn commit || ...), which retrigger some time of memberships. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re-thinking Debian membership
Didier Raboud a écrit :
Aurelien Jarno wrote:
I really like the idea of:
- activity = you keep your membership
- inactivity = you lose your membership
Maybe we could find another way to define activity, like (upload || vote
|| svn commit || ...), which retrigger some time of memberships.
Or a simple challenge-response mail system once a {time-step}...
It is not that invasive, really simple and rather efficient.
My point is that if your only activity in Debian is periodically
answering an automated email, I don't see the point of staying member of
the project.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
NEW queue
Hi, The NEW queue hasn't been processed for two months if we except a few fast-tracked packages, and the number of packages it contains has increased a lot. Some rumors said it is due to the approaching release of Lenny, but on the other hand some packages in NEW are targeted to experimental, which is the suggested way to test changes for Squeeze [1]. It may also be due to the ftp-masters being busy with other things or not feeling like working on that. In that case, I would suggest to appoint a new ftp-master/ftp-master assistant. Could we please have some details about that? Regards, Aurelien [1] http://lists.debian.org/debian-devel-announce/2008/07/msg7.html -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net signature.asc Description: Digital signature
Re: Developer Status
Marc 'HE' Brockschmidt a écrit : Lucas Nussbaum [EMAIL PROTECTED] writes: On 22/10/08 at 22:51 +, Clint Adams wrote: On Thu, Oct 23, 2008 at 12:10:29AM +0200, Joerg Jaspert wrote: This was initially written by me, then discussed within DAM (so take us two for we) and then discussed with DSA, FTPMaster, Keyring-Maint, Secretary, FrontDesk and the DPL. I am disappointed in all of these people. He wrote discussed, this doesn't mean that all of them agreed fully on this proposal^Hdecision. It would be interesting to have the point of view of each of those groups. You all know I'm lazy, so I'll just repeat myself: If I understand correctly, that is the answer you sent to Joerg, right? | (A small TS basically, the most important TS questions for them.) | This seems excessive. The point of DM was to kill off all the | bureaucracy and allow people in when they were able to convince a DD of | their skills. Adding a (small) NM process makes DM completely useless, I | think. [...] | Anyway, I've thought about this some more. At the moment, your proposal | seems to have three goals: |(i) Allow non-developer contributors to become project members. | (ii) Get rid of the horrible hack that DM is and replace it with |something closer to NM. [... stuff that was removed from the proposal and is now irrelevant ...] | (i) IMO needs a change to the constitution, as said before. This should | be a no-brainer, someone needs to prepare the changes, send it to -vote, | then kick the secretary to do the CfV. This should go through without | much discussion (draft title: Constitutional Amendment: Allow | non-developer members). | | (ii) is the messy part. Formally, doing it by declamation from | DAM/ftp-team is iffy, as it gets rid of a process that was endorsed by | the developer body in a GR last year. | The other problem with your proposal is that you make it harder to | contribute as package maintainer. Heck, making that easier was the whole | point of DM, reverting that change and replacing DM by Debian's NM | process five years ago (and that's basically what you are suggesting - | TS has grown excessively, a small subset of today's questions is what | people needed to do 5 years ago). | The fact that the NM committee (and not some random DD) does the package | check before allowing DM uploads should be enough. That's actually | what I had in mind when I proposed something like DM 2 years ago - which | was fine with you back then. How long has it been discussed? I am really surprised that your comments still fully apply to the current proposal (it looks like a policy), so basically your comments havn't been addressed. Really strange for a mail using we to represent numerous teams/persons, including you as a member of the Front Desk. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Developer Status
On Wed, Oct 22, 2008 at 11:33:28PM +0200, Joerg Jaspert wrote: Developer Status Summary of this post Discussions in the past have made it clear that the current definition of Debian Developer (AKA someone who is a member of the Debian project) should be modified and made more flexible. There have been attempts in the past to do something similar, notably Debian Maintainers (DM) [GR-DM], and to some extent debian-community.org [D-C], but these have only addressed parts of the whole issue. We plan to integrate DM more closely into the NM process/system Could you please define We. while keeping the spirit of easing entry into Debian for newcomers. At the same time we add a separate track for less-technical contributors. Is it a start of a discussion? A new policy? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net signature.asc Description: Digital signature
Re: No buildd redundancy for alpha/mips/mipsel
James Andrewartha a écrit : Not a buildd, but [1] notes that there's an alpha porting machine waiting for more than a year to be set up by DSA. I don't know if there's an RT ticket, but there is a bug [2] about this, which was closed this week, although it looks like by accident. This machine has been setup, it is called albeniz.debian.org, that's why the bug has been closed. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Some thoughts on the ARM build daemons
Hi all, The ARM port is getting bad [1], the percentage of packages built staying a bit more than 90% for 2 weeks. Also this is confirmed by a message on #debian-arm this morning: 09:30 doko please could somebody care about the python2.4, python2.5, binutils, gcc-4.1 and gcj-4.1 builds for arm? for gcj-4.1, please see the instructions posted on debian-ports/debian-gcc gcj-4.1 has to be bootstrapped manually (after python is installable again), but all other packages have not been built on ARM. They are blocked by python being uninstallable, but python2.4 is on position 115! in the list of packages to build. The problems mainly comes from the build daemons. Only *3 out of 7* are building packages, and one of the three is also building stable-security from time to time. Here are the states and reasons I have been able to found on the web and on IRC: - grieg: up, building packages - cats: up, building packages - tofee: up, building packages, sometimes stable-security. - smackdown: down, waiting for a 2.6 kernel - elara: down, waiting for bug#421037 - europa: down, waiting for bug#421037 - netwinder: down, waiting for bug#421037, but seems to be unaffected by this bug Note that the bug#421037 may be due to a too old kernel, but the glibc maintainers are lacking information. The situation is lasting for some time now, and I see no sign that it will change soon. If the person in charge of the ARM build daemons is short on time (which I can understand, life is life), why not delegate a person to fix this problem? Also the build power has always been tight on this architecture, so even if they are all restarted today, it would take weeks to get back to a normal state. I think it is time to changes things. Our faster build daemons have a 233MHz CPU with 256MB of RAM, while there are way faster ARM CPU today. Quoting our new DPL's platform: So we still have that money, and I would like to use it at least to fix our broken hardware. What about buying new ARM hardware with that money? Having faster machines would also allow to cope with hardware, software or human failures that always happens from time to time. Replacing one machine with another solve the problem of finding a hosting place for the new machine. Any comments? Bye, Aurelien [1] http://buildd.debian.org/stats/graph-week-big.png [2] http://www.debian.org/vote/2007/platforms/sho -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some thoughts on the ARM build daemons
Wookey a écrit : On 2007-05-08 12:05 +0200, Aurelien Jarno wrote: Hi all, The ARM port is getting bad [1], the percentage of packages built staying a bit more than 90% for 2 weeks. Also this is confirmed by a message on #debian-arm this morning: 09:30 doko please could somebody care about the python2.4, python2.5, binutils, gcc-4.1 and gcj-4.1 builds for arm? for gcj-4.1, please see the instructions posted on debian-ports/debian-gcc gcj-4.1 has to be bootstrapped manually (after python is installable again), but all other packages have not been built on ARM. They are blocked by python being uninstallable, but python2.4 is on position 115! in the list of packages to build. The problems mainly comes from the build daemons. Only *3 out of 7* are building packages, and one of the three is also building stable-security from time to time. Here are the states and reasons I have been able to found on the web and on IRC: - grieg: up, building packages - cats: up, building packages - tofee: up, building packages, sometimes stable-security. - smackdown: down, waiting for a 2.6 kernel - elara: down, waiting for bug#421037 - europa: down, waiting for bug#421037 - netwinder: down, waiting for bug#421037, but seems to be unaffected by this bug Note that the bug#421037 may be due to a too old kernel, but the glibc maintainers are lacking information. I tried to reproduce this on my netwinder but it simply didn't happen here. The situation is lasting for some time now, and I see no sign that it will change soon. If the person in charge of the ARM build daemons is short on time (which I can understand, life is life), why not delegate a person to fix this problem? I would love to see Aurelien added to the arm buildd team - he has shown significant activity and interest in this over the last year, and clearly knows what is going on. Also the build power has always been tight on this architecture, so even if they are all restarted today, it would take weeks to get back to a normal state. I think it is time to changes things. Our faster build daemons have a 233MHz CPU with 256MB of RAM, while there are way faster ARM CPU today. Quoting our new DPL's platform: So we still have that money, and I would like to use it at least to fix our broken hardware. What about buying new ARM hardware with that money? I'm not sure money is the issue - it appears to be DSA set-up time. New hardware has been offered, many months ago, and is there, ready, online, but (so far as I can tell) it has not been brought into use by the people with the power to do it (DSA and arm build-admin). http://lists.debian.org/debian-arm/2006/11/msg8.html I don't know who is waiting for what, at this stage. There was some activity on this in mid-Feb when Elmo and Bill exchanged mail via me, after discovering that elmo's mail to bill was getting eaten somewhere along the way (which obviously doesn't help). They arranged to meet on IRC to get things sorted out. That's why I proposed to replace the current machines by new ones. The local admin can just take the old disk (or copy the system if the disk format is different) and install a kernel for the new subarch. That does not change the IP, the account, the SSH keys, etc., so there is nothing to ask to DSA or whoever. I can also offer a reasonably fast build machine, but there didn't seem much point until Bills was put into use. So, yes - lets get fatrer hardware - it is now available, but until we can work out why we have been unable to bring hedges into use in nearly 6 months, and fix that problem, then money for hardware will not help. Bill, elmo - what happened after emails in feb? What are we waiting for now? Can anyone on this list help? If elmo is too busy (something that happens to everybody and that I understand, life is life), why can't this be done by somebody else? Don't say me elmo is not the only person able to setup a build daemon. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Some thoughts on the ARM build daemons
Aurelien Jarno a écrit : Wookey a écrit : On 2007-05-08 12:05 +0200, Aurelien Jarno wrote: Hi all, The ARM port is getting bad [1], the percentage of packages built staying a bit more than 90% for 2 weeks. Also this is confirmed by a message on #debian-arm this morning: 09:30 doko please could somebody care about the python2.4, python2.5, binutils, gcc-4.1 and gcj-4.1 builds for arm? for gcj-4.1, please see the instructions posted on debian-ports/debian-gcc gcj-4.1 has to be bootstrapped manually (after python is installable again), but all other packages have not been built on ARM. They are blocked by python being uninstallable, but python2.4 is on position 115! in the list of packages to build. The problems mainly comes from the build daemons. Only *3 out of 7* are building packages, and one of the three is also building stable-security from time to time. Here are the states and reasons I have been able to found on the web and on IRC: - grieg: up, building packages - cats: up, building packages - tofee: up, building packages, sometimes stable-security. - smackdown: down, waiting for a 2.6 kernel - elara: down, waiting for bug#421037 - europa: down, waiting for bug#421037 - netwinder: down, waiting for bug#421037, but seems to be unaffected by this bug Note that the bug#421037 may be due to a too old kernel, but the glibc maintainers are lacking information. I tried to reproduce this on my netwinder but it simply didn't happen here. The situation is lasting for some time now, and I see no sign that it will change soon. If the person in charge of the ARM build daemons is short on time (which I can understand, life is life), why not delegate a person to fix this problem? I would love to see Aurelien added to the arm buildd team - he has shown significant activity and interest in this over the last year, and clearly knows what is going on. Also the build power has always been tight on this architecture, so even if they are all restarted today, it would take weeks to get back to a normal state. I think it is time to changes things. Our faster build daemons have a 233MHz CPU with 256MB of RAM, while there are way faster ARM CPU today. Quoting our new DPL's platform: So we still have that money, and I would like to use it at least to fix our broken hardware. What about buying new ARM hardware with that money? I'm not sure money is the issue - it appears to be DSA set-up time. New hardware has been offered, many months ago, and is there, ready, online, but (so far as I can tell) it has not been brought into use by the people with the power to do it (DSA and arm build-admin). http://lists.debian.org/debian-arm/2006/11/msg8.html I don't know who is waiting for what, at this stage. There was some activity on this in mid-Feb when Elmo and Bill exchanged mail via me, after discovering that elmo's mail to bill was getting eaten somewhere along the way (which obviously doesn't help). They arranged to meet on IRC to get things sorted out. That's why I proposed to replace the current machines by new ones. The local admin can just take the old disk (or copy the system if the disk format is different) and install a kernel for the new subarch. That does not change the IP, the account, the SSH keys, etc., so there is nothing to ask to DSA or whoever. I can also offer a reasonably fast build machine, but there didn't seem much point until Bills was put into use. So, yes - lets get fatrer hardware - it is now available, but until we can work out why we have been unable to bring hedges into use in nearly 6 months, and fix that problem, then money for hardware will not help. Bill, elmo - what happened after emails in feb? What are we waiting for now? Can anyone on this list help? If elmo is too busy (something that happens to everybody and that I understand, life is life), why can't this be done by somebody else? Don't say me elmo is not the only person able to setup a build daemon. ^^^ just remove the not :) -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
Pierre Habouzit a écrit : On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: On a personal note, in my experience the most effective way of working with James and Ryan is to trust that they generally know what they're doing and more or less leave them to get on with making things better on their own rather than hassling them for status reports or similar. Well, that leave one obvious question then, are they the best people for the job ? because I'd really prefer people that work 10% less, to communicate what they do in the other 90% of their task, so that everyone knows what's going on, and can plan their own job decently. My point is, many tasks in debian depend on what DSA/DAM/... do and especially when. Event if (for the sake of the argument) I admit that things get eventually done, the unknown time part _is_ generating a _lot_ of frustration. Just leave them to their own devices isn't something you'll see recommended in management books, but when people are doing stuff that they care about for fun, it's worth considering. This is just handwaving: letting them in their dark corner because they work faster like that, is not related to the issue that is debated: no one says james or ryan are lazy, the problem is almost nobody know what and when they are doing it. A downside is that it makes it hard to know how to help, We're far beyond trying to help them, at least for me, I just want to have ETA's and communication because this is how people work together. Their work (or absence of, or delays of, or ...) are impacting the work of every single DD out there, and that sucks. Do you want a Simple example ? For almost 4 or 5 months (if not more) there is no Alpha machine available to developers, one being restricted, The machine is locked since the compromise in July 2006. So that's almost *8 months*. the other in lock down, waiting for a setup I guess (-- did you remark the I guess ? I mean I don't know what's going on, and nobody knows afaict). The problem is, I'm now helping packaging the glibc, and we have a couple of alpha-only bugs. Things really stupid like headers problems, that would almost take a full minute to be fixed. BUt that bug Well the glibc in testing/unstable is not really a problem as it is currently frozen (though it would have been possible to release Etch without those bugs). The problem now concerns glibc 2.5 (or later) which will be the glibc for Lenny. I think the easiest solution is simply to *not* consider alpha as a release architecture for Lenny from the glibc point of view, and ignore bugs (but accept patches). After all this architecture fails one release criterion. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412070: project: alpha developer-available machine is locked down
Package: project Severity: serious The Debian project lacks an alpha developer-available machine for about 8 months. This makes some bugs impossible to fix. The severity is set to serious because alpha is a release architecture for Etch, but without a developer-available machine it is not sure it will be the case for Lenny. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-xen-amd64 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Google Summer of Code
Sune Vuorela a écrit : On 2007-02-16, Anthony Towns aj@azure.humbug.org.au wrote: if so, have a list of suggested projects up, along with recommendation on what students should expect if they get A list of projects I just thought of - I have no clue how much work there are in them - and wether they have really been started already Debian-Live: Have a working debian-installer from debian-live - (one of the good thins ubuntu has done - we want one of those) kfreebsd-livecd kfreebsd: get d-i working livecd. Having d-i working on GNU/kFreeBSD will be a really great thing. I really think we should have that on our list of suggested project. About the livecd, it would be nice to have a GNU/kFreeBSD one, but there are probably more important projects. And we already have ging, though it is outdated. Cheers, Aurelien (with its GNU/kFreeBSD hat on) -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BREAKING NEWS: Debian developers aren't trusted
Anthony Towns a écrit : On Thu, Feb 15, 2007 at 06:34:16PM +1100, Hamish Moffatt wrote: On Thu, Feb 15, 2007 at 01:13:36PM +1000, Anthony Towns wrote: -vote dropped On Wed, Feb 14, 2007 at 03:06:01PM +0100, Martin Zobel-Helas wrote: i think someone running more than one autobuilder for more than _two_ years now (okay, not for the officical archive, but i see that as nonrelevant here) demonstrats very good that he mets your mentioned technical constraints. AIUI, Aurelian doesn't have the capability to run a non-emulated arm buildd. While http://blog.aurel32.net/?p=25 is a good demonstration of some things, I don't think it's the level of buildd we want for our release architectures. Wow, was there a point to your post or was pure insult? What's insulting in that (apart from the misspelling of Aurelien)? From http://blog.aurel32.net/?p=33: Yes I agree that real machines would be better, but I dont have a stack of fast ARM machines at home. First of all I haven't asked to become arm build daemon maintainer. What I asked for a responsive arm buildd maintainer who handle mails sent to [EMAIL PROTECTED] The goal of the emulated arm buildd farm was to be able to handle the requests by myself, in fully automated way (building and uploading package by hand takes a lot of time). I also asked some news about the arm machine offered by Bill Gatliff. This machine is really fast compared to the current build daemons and replace a few of the current one. As described by Steve Langasek on -vote, this can reduce some problems and the load of the build daemon maintainer. so, afaict, he doesn't have the capability to run a non-emulated arm buildd. And hacking together a buildd quickly and easily is impressive and useful for new ports, but it's more important for buildds for release architectures to be well-connected and reliable over a long period. We probably could change that expectation and have buildds be put together by DDs from whatever they have lying around and hosting them at home; I don't think it'd be a good idea, but others mileage may vary. I fully agree that knowing how to install wanna-build + buildd + sbuild don't make you a buildd maintainer. FYI, I am running a wanna-build database for hurd-i386, kfreebsd-i386 and kfreebsd-amd64 on my home server, and running three build daemons, two for kfreebsd-i386 (yes, contrary to some official architectures we have buildd redundancy), and one for kfreebsd-amd64. And that for almost 2 years. I have learned a lot from that, experienced hardware problems, chroot breakages due too buggy maintainer scripts, and even toolchain problems. The kfreebsd-amd64 build daemon has been added very early in the development of this architecture (ie two or three weeks after the toolchain has been ported), and I think I have learned more from that than if it has been an official and fully mature architecture. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Wouter Verhelst a écrit : having one buildd maintainer per arch as opposed to a team will allow one to faster see recurring obscure problems that need fixing). That's the theory. The reality shows the exact contrary, at least for arm: - The chroot of netwinder is broken for weeks. - tofee is loosing packages for weeks. - Some build daemons do not have enough resources to build big packages. Nobody adds those packages to weak_no_auto_build or weak_no_auto_build on those build daemons. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Explications needed...
Steve Langasek a écrit : On Wed, Dec 20, 2006 at 06:17:20PM +0100, Michael Banck wrote: [this discussion is off-topic on -devel, please follow-up on -project] On Wed, Dec 20, 2006 at 05:51:55PM +0100, Luk Claes wrote: How did Aurelien get wanna-build access for his buildd He didn't, it's a rogue autobuilder. Which is the reason it got blacklisted. or did he not ask for it... He did apparently, but did not get a response and decided to act anyway. Did somebody from the release team say that the arm autobuilder is causing trouble to the release, and that buildd maintenance needs to get addressed? No. ARM was in no danger of being dropped from the release due to this, and the only buildd problem I've seen identified in this was a broken libtasn1-3 package in netwinder's chroot -- if this was causing any problems for the release team, I at least wasn't aware of it. All started with this email: http://lists.debian.org/debian-arm/2006/08/msg00151.html ARM was *in danger*, a lot of stuff (java, xulrunner, mono, ...) were not working correctly. People worked hard to fix that, but it was very difficult to get packages depending on fixed stuff to get requeued. Also a lot of arch-specific compile errors were actually due to build daemon problems. I have decided to help the ARM port at that time, and I am building around 20 packages per week on my NSLU2 since this moment (the glibc being frozen, I don't have test build to do). It takes me a lot of time, so I decided to automate the process with build daemons. We will see the evolution of the ARM port without those uploads. I know at least two packages with RC bugs which won't move to testing because one of the ARM build daemon have (recurrent) problems (and it's not netwinder nor elara). And this time I won't be able to build them by hand. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Server restored after Compromise
Steve Kemp wrote: On Thu, Jul 13, 2006 at 08:18:27PM +0200, Bas Zoetekouw wrote: An investigation of developer passwords revealed a number of weak passwords whose accounts have been locked in response. That's not good. Should we maybe implement a stricter password policy? Or maybe only allow pubkey ssh authentication? Definitely a good idea. We already trust users to maintain their GPG key securely, so adding the requirement they do the same with an SSH keypair isn't anything more difficult. Like having both public and private SSH keys on gluck.d.o? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Second Call for Talks: Debian Devroom at FOSDEM 2006
On Mon, Dec 05, 2005 at 11:32:52AM +0100, Wouter Verhelst wrote: Hi, Hi, Three weeks and one day have passed since I sent out my first Call for Talks[1] for the Debian DevRoom at the upcoming FOSDEM 2006[2] in Brussels, Belgium. For those who haven't heard about it, FOSDEM is the Free and Open-Source Developers European Meeting which takes place every year in the buildings of the ULB, the Université Libre de Bruxelles; due to it being organized by the community and for the community, it presents a unique opportunity for people of various FLOSS projects to meet eachother as well as to learn about the latest developments in the FLOSS world. For the third year in a row, Debian is having a DevRoom; we have one room with 76 seats booked for the whole weekend. Since my initial Call for Talks, people have proposed talks for a total of just over 4 hours. That's a good start, but we will need a lot more talks to fill the schedule; therefore, I am asking again for people to come forward and propose talks. The only requirement is that you have a technical talk about a Debian-related subject; this should not be a difficult requirement to meet. Are you still accepting talks, or am I late? I could make a talk about the Debian GNU/kFreeBSD port, something like the one I plan to do at Debconf 6. However, I am not yet sure I would be able to go at FOSDEM, I may have an other thing the same days. I should know that before the end of the week, so if you are interested, please tell me. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: thank you for your support
Hi Branden ! On Mon, Apr 11, 2005 at 03:13:55AM -0500, Branden Robinson wrote: To those who ranked me poorly in this year's election, I hope to gain your confidence. If you'd like to mail me privately (or otherwise) to let me know how I can do that, please do so. To gain my confidence, here is what you could do: - Do everything to make sure that the Vancouver proposal doesn't become real. In the future, I hope it will be still possible to call Debian the Universal OS. - Stop the Project Scud, the cabal is already enough! Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Theo de Raadt On Firmware Activism
Andrew Pollock wrote: On Wed, Nov 03, 2004 at 10:30:10PM +, Martin Michlmayr - Debian Project Leader wrote: http://kerneltrap.org/node/view/4118 Kudos to Theo for OpenBSD getting out and poking the vendors. My concern is that for all their effort, and potential flow on benefits to Linux, it won't be considered good enough for Debian because of the current stance on firmware, and source code to it... Where did we get up to with that anyway, binary blobs are out, end of story? Currently the license of the acx100 firmware doesn't even allow to redistribute the firmware. I hope with this action Texas Instrument would at least give the right to redistribute it, so it could be included in non-free. For user having non-free in their /etc/apt/source.list, that would let them install the driver (which is licensed under GPL and already in Debian, section contrib) in one operation using apt-get. Currently they have to find the firmware on the CD given with the card, which is not very easy. Sometimes it is located in a .cab file, or in a .exe installer. A free firmware is better than a non-free firmware. But a non-free firmware is better than nothing. -- .''`. Aurelien Jarno GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
