Aw: Re: Bits from ARM porters
Hello, That being said: becoming a DD would be ok for me, but would it be ok with the project as well? The scope of my work would be rather limited, I think... We have non-programming DDs http://www.debian.org/News/2010/20101019 http://www.debian.org/vote/2010/vote_002 which is not exactly what we want since those lack the upload privileges, but it would get Ingo the (overdue) member status. Cheers, Steffen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/trinity-5dca2fdc-1cc5-41f4-94a2-815aa54a26c2-1386160598187@3capp-gmx-bs36
Re: Bits from ARM porters
Hi, On Tue, Dec 03, 2013 at 01:18:33PM +0100, Hector Oron wrote: Hello, 2013/12/3 Aurelien Jarno aurel...@aurel32.net: On Tue, Dec 03, 2013 at 12:43:36AM +0100, Hector Oron wrote: 5.2 Setup arm64 debian-ports ⁃ arm64 setup as new bootstrapping port ⁃ manual builds could be uploaded but possible lack of space ⁃ 9 more packages needed for a minimal bootstrap I have been contacted by Wookey earlier this year about adding arm64 port to debian-ports, and everything is now ready. I am still waiting for the buildds email addresses and ssh key though. It is already possible to upload packages, as space is not an issue on debian-ports since we moved to the machine offered by DSA. That said adding a new architecture is a problem (I had to add mips64el on the waiting list recently), as we are lacking CPU and disk I/O. Remember we have about 2/3 of the architectures in the official Debian archive, on a single virtual machine. Wookey, any ETA for providing buildds email addresses and ssh key? Aurelien, currently debian-ports is a libvirt VM all by itself on DL850 hardware, which it is undesired, so debian-ports cannot have more resources on that machine until it moves away (preferably as Debian service if that's desired). Yes, I understand this point. 7 Debian-Ports integration in Debian I find strange that it has been discussed and actions have been taken during an ARM bof, without having been contacted. Anyway let's see the various points: Aurelien, this is chicken-egg problem, I added that point for discussion for the meeting (which was published when announced the discussion agenda, few months away). I was wanting to discuss with you, once there is some material for discussion. Actions have not yet been taken, as it needs to be discussed with you. Let's have a look to the issues more deeply: Ok. debian-ports needs a user mailing list. That could be a good idea. Note however that there is currently a buildd-maintain...@debian-ports.org contacting the buildd maintainers of all architectures there. There are no public forums for debian-ports discussions. Some debian-ports buildd maintainers would benefit from that so share experiences and share common problems. It would also be a common ground to know which ports are being added/removed, etc... Instead of handling that in private. I think we all are in the same thinking that a mailing list would be good. So, for fixing the problem: Which mailing list should be used for debian-ports discussion? I am opened to suggestions that do not involve the debian-ports machine, as the goal is to reduce the things hosted there. While the ARM sprint, Manuel Montecelo suggested to create one in alioth or we can either replace debian-po...@lists.debian.org alias by proper mailing list, as that list currently spams all porters lists, and some people is annoyed with it. Options: a. create new mailing list on alioth b. re-purpose debian-ports@l.d.o c. other I would go to option a, opening a debian-ports group on alioth, and also hosting the git there (which means one less service to move). 7.1 Hand machine over to DSA All that needs to be done to handover machine to DSA: ⁃ Identify services running on d-ports ⁃ Transfer services to DSA machine ⁃ Transfer domain names to DSA As already said earlier, I am fine doing that as long as we do not loose features or contributors. What is clearly missing in the list above, is the manpower to do the transfer and the maintenance once the transfer is done (unless DSA is planning to do the full administration, including wanna-build, archive, ...). No DSA should not do the service administration. I would expect the manpower to do the transfer and maintenance would be done by debian-ports team (which includes you, me and other people behind the curtains if there are some). I am personally can provide some manpower from time to time to do the transfer, but clearly can't be involved that much more. It will mostly depends how many software has to be rewritten to match the new machine or DSA requirements. I remember having spent hours rewriting parts of mini-dak when moving debian-ports to the DSA provided machine to minimize the effects of a very low fork rate due to virtualization, while people where sending mails to complain the archive was slow or broken. I don't want that again. Here is the list of services: - mini-dak for running the archive - FTP server for uploading packages and serving the archive and CD images - web server for serving the archive and CD images - wanna-build - postgresql for wanna-build - web server for wanna-build frontend (pgstatus) - mail server + wbpy to store the build logs - rsync server for serving the archive, currently restricted to mirrors
Re: Bits from ARM porters
Hello, (Adding CC to person that done the comment) 2013/12/3 Lisandro Damián Nicanor Pérez perezme...@gmail.com: Hector Oron wrote: [snip] 5.1 Enable buildd support ─ ⁃ Fast model system (initial bootstrapping only) ⁃ QEMU support (bootstrapping to the point of a buildd image recompile it all again) ⁃ Real hardware accessible to Debian (?) ⁃ Qt issues make it hard with emulators. May build, might not work. Would this be a Qt problem related to the emulator or the the toolkit itself? /me with his Qt maintainer hat on (which might be too big, but oh well...) That was a comment done by Canonical folks, iirc Adam Conrad, talking from their experience on emulated builds. Maybe, they are able to expand on the comment. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAODfWeFJL3hXVf+kwdyM8D_ZyctBjTr76girhGb=sfppcea...@mail.gmail.com
Re: Bits from ARM porters
On 2 December 2013 23:08, Hector Oron hector.o...@gmail.com wrote: 5 arm64 Debian port support ═══ If Debian is unable to find ARM 64-bit hardware before Jessie gets frozen, it likely won't be Jessie supported. What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? Is the shortage realistically be possible to fill with a targeted fundraiser? During Jessie lifecycle, there will be demand for stable ARM64 port. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluju9ilxdx0wdf8zpofrqrqwivnvciouhkraqo8xq+j...@mail.gmail.com
Re: Bits from ARM porters
Dmitrijs Ledkovs x...@debian.org (2013-12-03): On 2 December 2013 23:08, Hector Oron hector.o...@gmail.com wrote: 5 arm64 Debian port support ═══ If Debian is unable to find ARM 64-bit hardware before Jessie gets frozen, it likely won't be Jessie supported. What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? Is the shortage realistically be possible to fill with a targeted fundraiser? During Jessie lifecycle, there will be demand for stable ARM64 port. arm64 hardware availability (or lack thereof) might be the blocker here. Mraw, Ki-not-pretending-that-he-knows-anything-about-hardware-Bi. signature.asc Description: Digital signature
Re: Bits from ARM porters
Hello, 2013/12/3 Aurelien Jarno aurel...@aurel32.net: On Tue, Dec 03, 2013 at 12:43:36AM +0100, Hector Oron wrote: 5.2 Setup arm64 debian-ports ⁃ arm64 setup as new bootstrapping port ⁃ manual builds could be uploaded but possible lack of space ⁃ 9 more packages needed for a minimal bootstrap I have been contacted by Wookey earlier this year about adding arm64 port to debian-ports, and everything is now ready. I am still waiting for the buildds email addresses and ssh key though. It is already possible to upload packages, as space is not an issue on debian-ports since we moved to the machine offered by DSA. That said adding a new architecture is a problem (I had to add mips64el on the waiting list recently), as we are lacking CPU and disk I/O. Remember we have about 2/3 of the architectures in the official Debian archive, on a single virtual machine. Wookey, any ETA for providing buildds email addresses and ssh key? Aurelien, currently debian-ports is a libvirt VM all by itself on DL850 hardware, which it is undesired, so debian-ports cannot have more resources on that machine until it moves away (preferably as Debian service if that's desired). 7 Debian-Ports integration in Debian I find strange that it has been discussed and actions have been taken during an ARM bof, without having been contacted. Anyway let's see the various points: Aurelien, this is chicken-egg problem, I added that point for discussion for the meeting (which was published when announced the discussion agenda, few months away). I was wanting to discuss with you, once there is some material for discussion. Actions have not yet been taken, as it needs to be discussed with you. Let's have a look to the issues more deeply: debian-ports needs a user mailing list. That could be a good idea. Note however that there is currently a buildd-maintain...@debian-ports.org contacting the buildd maintainers of all architectures there. There are no public forums for debian-ports discussions. Some debian-ports buildd maintainers would benefit from that so share experiences and share common problems. It would also be a common ground to know which ports are being added/removed, etc... Instead of handling that in private. I think we all are in the same thinking that a mailing list would be good. So, for fixing the problem: Which mailing list should be used for debian-ports discussion? I am opened to suggestions that do not involve the debian-ports machine, as the goal is to reduce the things hosted there. While the ARM sprint, Manuel Montecelo suggested to create one in alioth or we can either replace debian-po...@lists.debian.org alias by proper mailing list, as that list currently spams all porters lists, and some people is annoyed with it. Options: a. create new mailing list on alioth b. re-purpose debian-ports@l.d.o c. other 7.1 Hand machine over to DSA All that needs to be done to handover machine to DSA: ⁃ Identify services running on d-ports ⁃ Transfer services to DSA machine ⁃ Transfer domain names to DSA As already said earlier, I am fine doing that as long as we do not loose features or contributors. What is clearly missing in the list above, is the manpower to do the transfer and the maintenance once the transfer is done (unless DSA is planning to do the full administration, including wanna-build, archive, ...). No DSA should not do the service administration. I would expect the manpower to do the transfer and maintenance would be done by debian-ports team (which includes you, me and other people behind the curtains if there are some). Here is the list of services: - mini-dak for running the archive - FTP server for uploading packages and serving the archive and CD images - web server for serving the archive and CD images - wanna-build - postgresql for wanna-build - web server for wanna-build frontend (pgstatus) - mail server + wbpy to store the build logs - rsync server for serving the archive, currently restricted to mirrors due to I/O issues - git server and web server for the code and data used on debian-ports - script to create an incoming directory - script for transitions tracking (ben) - POP3S server for buildds behind NAT - DNS server for debian-ports.org - web server for the public website - IPv6: not really a service, but used for buildds without public IPv4 I opened RT#4808, attaching that list, in case, we decide to take action on it. 7.2 Enable unreleased suite handling in archive tools ─ Aparently, keeping separated archive for debian-ports would be good, so we can still have waky-hacks in -ports, while do clean bootstrap in Debian archives. The unreleased suite is a very important feature that should not be lost, unless we allow porters to NMU packages in a short
Re: Bits from ARM porters
KiBi wrote: Dmitrijs Ledkovs x...@debian.org (2013-12-03): What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? arm64 hardware availability (or lack thereof) might be the blocker here. And the MIPS thread âright nowâ shows how much we would not want to rely on prototype/evaluation boards. During Jessie lifecycle, there will be demand for stable ARM64 port. How about not releasing arm64 with jessie, but making a snapshot of unstable/arm64 (from debian-ports possibly) at that point and offering that as âjessie-arm64â, like âetch-m68kâ was done? With less than a year to go, this sounds like a safe route, and will lead to people not needing to rush things. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l7kir1$d18$1...@ger.gmane.org
Re: Bits from ARM porters
I don't really see the point, as it is already the case. Actually most of the uploaders in debian-ports are non-DD, and it is something that should not be lost in the transfer either. If debian-ports is converted to official Debian service, then all the user database is extracted from LDAP, which allows access to DD, but non-DD have a problem (similar with alioth guest accounts). Somehow that needs to be solved. While in the sprint, few DAM members were around and we were able to discuss it a little bit. Apparently, the consensus was to make those people Debian contributors or the such early in the process, if I understood correctly. Iâd love to have a bit more incentive to get people like Ingo, who has been doing m68k buildd work for, I believe, a decade, to become at least a Debian member. On the other hand, while some of these people (porters) will need packaging skills and should attempt to become full uploading DD, some (buildd admins) will need more or less only trust and some limited technical skills (ofc they should be welcome to do more), so we shouldnât put the barrier *too* high. Iâd really like to get everyone whoâs got root on the m68k buildds, or physical access to it¹, to be a member of the project, though⦠bye, //mirabilos â Though this would include âremote handsâ like parents, or data centre personnell, which we cannot justify. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l7kjgl$d18$2...@ger.gmane.org
Re: Bits from ARM porters
Hello, 2013/12/3 Dmitrijs Ledkovs x...@debian.org: On 2 December 2013 23:08, Hector Oron hector.o...@gmail.com wrote: 5 arm64 Debian port support ═══ If Debian is unable to find ARM 64-bit hardware before Jessie gets frozen, it likely won't be Jessie supported. What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? Is the shortage realistically be possible to fill with a targeted fundraiser? During Jessie lifecycle, there will be demand for stable ARM64 port. Seriously, I have no idea. There are no arm64 machines available for sale, besides those phones from the apples, which are unsuitable for our purposes. Debian Project is community funded, in general, people find expending 5-7k$ out of Debian money for full ARM (32-bit) server *not* an option. While Canonical was able to make a deal with AMCC/APM for X-Gene machine (to build Ubuntu's arm64 port), apparently that machine is not going to see the light until half next year, right before Debian freeze. It was suggested to do arm64 cross built or emulated built in debian-ports, so it'd be easier to bootstrap if it becomes official, however it is quite tight in schedule for Jessie release as you can see. Regards, -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caodfwefvuufzbjsi0g5kl43aykf7cj6temniqjf7rlv3sj-...@mail.gmail.com
Re: Bits from ARM porters
On Tue, Dec 03, 2013 at 12:30:16PM +0100, Hector Oron wrote: 2013/12/3 Lisandro Damián Nicanor Pérez perezme...@gmail.com: Hector Oron wrote: [snip] 5.1 Enable buildd support ─ ⁃ Fast model system (initial bootstrapping only) ⁃ QEMU support (bootstrapping to the point of a buildd image recompile it all again) ⁃ Real hardware accessible to Debian (?) ⁃ Qt issues make it hard with emulators. May build, might not work. Would this be a Qt problem related to the emulator or the the toolkit itself? /me with his Qt maintainer hat on (which might be too big, but oh well...) That was a comment done by Canonical folks, iirc Adam Conrad, talking from their experience on emulated builds. Maybe, they are able to expand on the comment. It's not a problem with Qt as such. The problem is that qemu-user tends to get very upset when multithreading is involved, and Qt likes to use threads. We escalated it to the emulator folks in Linaro some time ago, but I'm told that fixing this in qemu is a very substantial project which nobody's currently working on. https://bugs.launchpad.net/qemu/+bug/1084148 The approach used by Launchpad's ARM PPA builders where you install qemu-user-static and emulate foreign-architecture binaries on the fly is a neat trick, and works for a subset of packages. But until qemu-user is made a *lot* more robust, it doesn't stand a chance of being able to build the whole archive; and Qt is low enough down the dependency chain that in practice you run into this sooner than you might expect or want. qemu-system doesn't suffer from this class of problems. On the other hand it's significantly slower, and you may have some amusement getting it to do such things as emulating a machine with sufficient memory and I/O. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203143829.ga20...@riva.ucam.org
Re: Bits from ARM porters
+++ Aurelien Jarno [2013-12-03 01:56 +0100]: Hi, On Tue, Dec 03, 2013 at 12:43:36AM +0100, Hector Oron wrote: 5.2 Setup arm64 debian-ports ⁃ arm64 setup as new bootstrapping port ⁃ manual builds could be uploaded but possible lack of space ⁃ 9 more packages needed for a minimal bootstrap I have been contacted by Wookey earlier this year about adding arm64 port to debian-ports, and everything is now ready. Yes, thanks very much for doing that. (Although I never got an email about it, so only noticed because someone pointed out it was there) I am still waiting for the buildds email addresses and ssh key though. We're still waiting for a machine we can actually use as a buildd. In the meantime I've set up an 80-core amd64 machine to run models on. I'm in the process of setting that up so that it can actually be used as a set of buildds. We'll see how that performs. It's slow, but still good enough to build hundreds packages/week. And would at least validate the architecture in debian infra. I expect this to happen this month. We also (as of today) have part-time access to the early hardware linaro have, so long as we don't get in the way of other development and benchmarking work. Actually Riku has access to that machine - I'm not allowed to log in because of idiotic legal nonsense about NDAs between ARM and the owners of the hardware (riku is employed by linaro, I'm seconded from ARM, so only one of poses an unnacceptable threat to their Imaginary Property). It is already possible to upload packages, as space is not an issue on debian-ports since we moved to the machine offered by DSA. That said adding a new architecture is a problem (I had to add mips64el on the waiting list recently), as we are lacking CPU and disk I/O. Remember we have about 2/3 of the architectures in the official Debian archive, on a single virtual machine. Understood. We hope not to spend too log in ports, but it depends how long before a real buildd is aquired. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203150146.gr1...@stoneboat.aleph1.co.uk
Re: Bits from ARM porters
On Tue, Dec 03, 2013 at 12:30:16PM +0100, Hector Oron wrote: 2013/12/3 Lisandro Damián Nicanor Pérez perezme...@gmail.com: Would this be a Qt problem related to the emulator or the the toolkit itself? That was a comment done by Canonical folks, iirc Adam Conrad, talking from their experience on emulated builds. Maybe, they are able to expand on the comment. It's not a Qt issue, it's a fundamental issue with qemu-user-static and threading, which Qt uses a whole lot of. The issues aren't at all limited to Qt, it just happens that Qt gets run a lot in a lot of builds (a lot more than you'd think...). ... Adam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131203160122.gi7...@0c3.net
Re: Bits from ARM porters
On Tue, Dec 3, 2013 at 11:42:56 +, Dmitrijs Ledkovs wrote: On 2 December 2013 23:08, Hector Oron hector.o...@gmail.com wrote: 5 arm64 Debian port support ═══ If Debian is unable to find ARM 64-bit hardware before Jessie gets frozen, it likely won't be Jessie supported. What is the opportunity cost here? Are there no machine available within budget? If that's the case, what's the current budget that Debian Project can contribute, and what's the shortage to buy ARM 64-bit hardware *today*? I would hope that's 0. If there's available arm64 hw and there are companies interested in a Debian arm64 port then I'd think they can sponsor hw. Cheers, Julien signature.asc Description: Digital signature
Re: Bits from ARM porters
On 12/03/2013 01:40 PM, Thorsten Glaser wrote: I’d really like to get everyone who’s got root on the m68k buildds, or physical access to it¹, to be a member of the project, though… I second that! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/529e194c.8090...@physik.fu-berlin.de
Re: Bits from ARM porters
Am 03.12.2013 um 13:40 schrieb Thorsten Glaser t...@debian.org: I’d love to have a bit more incentive to get people like Ingo, who has been doing m68k buildd work for, I believe, a decade, to become Hmmm, since March 2001, if my archive serves me correctly. at least a Debian member. On the other hand, while some of these people (porters) will need packaging skills and should attempt to become full uploading DD, some (buildd admins) will need more or less only trust and some limited technical skills (ofc they should be welcome to do more), so we shouldn’t put the barrier *too* high. Hmm, hmmm, h... Trying to convince me to become a DD is as old as running Arrakis as second m68k buildd to Kullervo. Over 12 years now. Back then it would have been easy: just say Yes, I want to be a DD, here's my gpg key! Because I didn't want to do any packaging at all, it became impossible at some point until DMs and such were introduced. Somewhen I decided to apply, but wasn't applied an AM for about a whole year, which led me to revoke my application with great disappointment. I’d really like to get everyone who’s got root on the m68k buildds, or physical access to it¹, to be a member of the project, though… Well, this would be the only reason for me that would justify a new application: establishing some degree of trust, well, more official trust relationship than now. But beyond that... well, I don't know if it makes sense to become a DD in a big effort. Actually, I'm not against it, but I have no problem with not being one. If others think it would make sense, then it's perfectly fine for me to re-apply if I won't face the same trouble again. When being a DD I could imagine to work on merging Buildd.Net into Debian infrastructure and improve it, if that would be appreciated... That being said: becoming a DD would be ok for me, but would it be ok with the project as well? The scope of my work would be rather limited, I think... -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Bits from ARM porters
Ingo Jürgensmann dixit: Because I didn't want to do any packaging at all, it became impossible at some point until DMs and such were introduced. Somewhen I decided It’s even better now: we have “non-packaging developers”, e.g. people who work on, say, exclusively the press team. to apply, but wasn't applied an AM for about a whole year, which led me to revoke my application with great disappointment. Oh ☹ That’s sad. I think just before I decided to apply for DD, there were a lot of improvements in that area though (I did manage to pass in an amazing six weeks total), so I hope that’s a thing os the past. That being said: becoming a DD would be ok for me, but would it be ok with the project as well? The scope of my work would be rather limited, I think... Most definitely! (Think diversity statement.) bye, //mirabilos -- 13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good guy. But he's always right! In every fsckin' situation, he's right. Even with his deeply perverted taste in software and borked ambition towards broken OSes - in the end, he's damn right about it :(! […] works in mksh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312032024070.2...@herc.mirbsd.org
Re: Bits from ARM porters
]] Ingo Jürgensmann Trying to convince me to become a DD is as old as running Arrakis as second m68k buildd to Kullervo. Over 12 years now. Back then it would have been easy: just say Yes, I want to be a DD, here's my gpg key! Not really, I became a DD about then and went through the full NM with PP and all. I’d really like to get everyone who’s got root on the m68k buildds, or physical access to it¹, to be a member of the project, though… Well, this would be the only reason for me that would justify a new application: establishing some degree of trust, well, more official trust relationship than now. But beyond that... well, I don't know if it makes sense to become a DD in a big effort. Actually, I'm not against it, but I have no problem with not being one. If others think it would make sense, then it's perfectly fine for me to re-apply if I won't face the same trouble again. With no particular hat on, I'd really like anybody running services for and pushing packages into Debian to have some sort of official hat, whether it's DD or DM or similar. As for merging buildd.net into the rest of the wbadm stuff, I have no opinion. Talking to the existing wbadm people is probably the best way forward. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2y5417i61@rahvafeir.err.no
Re: Bits from ARM porters
Hi, On Tue, Dec 03, 2013 at 12:43:36AM +0100, Hector Oron wrote: 5.2 Setup arm64 debian-ports ⁃ arm64 setup as new bootstrapping port ⁃ manual builds could be uploaded but possible lack of space ⁃ 9 more packages needed for a minimal bootstrap I have been contacted by Wookey earlier this year about adding arm64 port to debian-ports, and everything is now ready. I am still waiting for the buildds email addresses and ssh key though. It is already possible to upload packages, as space is not an issue on debian-ports since we moved to the machine offered by DSA. That said adding a new architecture is a problem (I had to add mips64el on the waiting list recently), as we are lacking CPU and disk I/O. Remember we have about 2/3 of the architectures in the official Debian archive, on a single virtual machine. [...] 7 Debian-Ports integration in Debian I find strange that it has been discussed and actions have been taken during an ARM bof, without having been contacted. Anyway let's see the various points: debian-ports needs a user mailing list. That could be a good idea. Note however that there is currently a buildd-maintain...@debian-ports.org contacting the buildd maintainers of all architectures there. Which mailing list should be used for debian-ports discussion? I am opened to suggestions that do not involve the debian-ports machine, as the goal is to reduce the things hosted there. 7.1 Hand machine over to DSA All that needs to be done to handover machine to DSA: ⁃ Identify services running on d-ports ⁃ Transfer services to DSA machine ⁃ Transfer domain names to DSA As already said earlier, I am fine doing that as long as we do not loose features or contributors. What is clearly missing in the list above, is the manpower to do the transfer and the maintenance once the transfer is done (unless DSA is planning to do the full administration, including wanna-build, archive, ...). Here is the list of services: - mini-dak for running the archive - FTP server for uploading packages and serving the archive and CD images - web server for serving the archive and CD images - wanna-build - postgresql for wanna-build - web server for wanna-build frontend (pgstatus) - mail server + wbpy to store the build logs - rsync server for serving the archive, currently restricted to mirrors due to I/O issues - git server and web server for the code and data used on debian-ports - script to create an incoming directory - script for transitions tracking (ben) - POP3S server for buildds behind NAT - DNS server for debian-ports.org - web server for the public website - IPv6: not really a service, but used for buildds without public IPv4 7.2 Enable unreleased suite handling in archive tools ─ Aparently, keeping separated archive for debian-ports would be good, so we can still have waky-hacks in -ports, while do clean bootstrap in Debian archives. The unreleased suite is a very important feature that should not be lost, unless we allow porters to NMU packages in a short timeframe and even during freeze. Another feature of the archive is to be able to upload packages versions newer than the current one, but older than in the sources. This allow things to progress even if the current package in unstable is broken and the maintainer doesn't cares about ports. People proposed to add theses features to dak, but nobody actually did the job so far. 7.3 Merge wanna-build DB into official one ── ⁃ We want to be able to keep same architecture in both Debian and Debian-ports (Note: Debian-ports packages carry scary hacks, and Debian bootstrap should start from clean start) Note that we are running the same software than in Debian, even if it is sometimes lagging a bit. Thanks to Philip Kern for his work on that. Remember that it means wanna-build should look for unreleased. Also remember it means that non-DD should be able to access wanna-build. If possible the same persons should also have a shell with access to the packages files and wanna-build to be able to handle transitions and schedule NMUs, like the release team is doing. 7.4 Enable non-DD uploaders for d-ports ─── ⁃ Recognise porting work in the NM process independently of whether individual packages are listed as being maintained by that person. Needs some tools or existing tools adapting to ports structure. I don't really see the point, as it is already the case. Actually most of the uploaders in debian-ports are non-DD, and it is something that should not be lost in the transfer either. Regards, Aurelien -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc
Re: Bits from ARM porters
Hector Oron wrote: [snip] 5.1 Enable buildd support ─ ⁃ Fast model system (initial bootstrapping only) ⁃ QEMU support (bootstrapping to the point of a buildd image recompile it all again) ⁃ Real hardware accessible to Debian (?) ⁃ Qt issues make it hard with emulators. May build, might not work. Would this be a Qt problem related to the emulator or the the toolkit itself? /me with his Qt maintainer hat on (which might be too big, but oh well...) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l7jfdd$pt7$1...@ger.gmane.org
Flashable image generation Re: Bits from ARM porters
On Tue, Dec 3, 2013 at 7:43 AM, Hector Oron wrote: 12 Flashable image generation ═ 12.1 Discussion on supporting pre-installed images ── ⁃ Just fix DI to work on the expected platforms. ⁃ Document ways to create images with existing tools. You appear to have not included our discussion from IRC, here is a summary and expansion of the discussion. Flashable images are much nicer than d-i from an ARM mobile devices PoV, hardware vendors/OEMs PoV and also from a cloud PoV. There are some situations like full-disk encryption that can't be done with images but they are still a useful option to have. We already have some flashable images; Debian live Debian cloud. Both of these do things like post-debootstrap removal of files like SSH private keys and thus a bit hacky. They both also reimplement these things instead of using the same removal code. http://www.debian.org/CD/live/ At DebConf13, Raphaël Hertzog suggested there should be a debconf setting for packages to check for so they are generically configured instead of fully-configured for the local system. debootstrap would set that debconf setting while building the chroot and insert an initial-boot configuration step that removes it and runs all the maintainer scripts again. Questions: What should the debconf setting be called? Who is willing to work on this? Has anyone done some comparisons between multiple debootstrap/d-i installs to see what files should be generated on first-boot of image based installs and what debconf prompts need to happen on first-boot? What things are currently changed post-debootstrap for the live and cloud images? Would the live and cloud people be willing to merge their stuff? I hear the live stuff can generate non-live (read-write) images too so it may be best to standardise on that. We probably need a GUI tool to download and install Debian images onto mobile devices using the various flashers. https://wiki.debian.org/Mobile#software-flashers -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GG=PyyfH+FM_LNiajfohkcUFd3Qtko=fnwfmx4dth...@mail.gmail.com
