Re: Debian Archive architecture removals
On 2015-05-06 10:44, Thorsten Glaser wrote: > [ with my m68k buildd maintainer and (ex-?) porter hat ] > > Aurelien Jarno dixit: > > >- debian-ports uses mini-dak instead of dak. It uses less resources and > > brings some features that are useful for new architectures like > > accepting binary uploads when it "improves" the version even if it is > > not the latest one or an "unreleased" suite for packages built from > > modified source (hence architecture specific). On the contrary its > > There’s two more bugs that *really* disturb porters’ work in it: > > • it is possible to do a binary upload of the *same* version of a pak‐ > kage that is currently in the archive, which breaks the package until > the next bigger upload fixes it: mini-dak serves the checksums from > one of the uploads but the .deb files from the other of the uploads > (this can happen in case of human errors, or caused by a w-b hiccup, > when a package was taken by someone (porter or buildd) and is in > Building state, then vanishes from the DB, then comes back) > > • (much worse) library transition old-version keeping is broken: > > suppose there is src:isl (= 0.12.2-2) building libisl10 in the > archive and built on some architecture; then, someone uploads > src:isl (= 0.14-2) which builds libisl13 instead; in dak (on the > main archive), the old libisl10 binary packages are kept in the > Packages.gz file until there is no dependency on it any more; > mini-dak just throws all NBS binary packages away immediately Then that's only one more, because it's exactly what I described in my mail. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
Re: Debian Archive architecture removals
[ with my m68k buildd maintainer and (ex-?) porter hat ] Aurelien Jarno dixit: >- debian-ports uses mini-dak instead of dak. It uses less resources and > brings some features that are useful for new architectures like > accepting binary uploads when it "improves" the version even if it is > not the latest one or an "unreleased" suite for packages built from > modified source (hence architecture specific). On the contrary its There’s two more bugs that *really* disturb porters’ work in it: • it is possible to do a binary upload of the *same* version of a pak‐ kage that is currently in the archive, which breaks the package until the next bigger upload fixes it: mini-dak serves the checksums from one of the uploads but the .deb files from the other of the uploads (this can happen in case of human errors, or caused by a w-b hiccup, when a package was taken by someone (porter or buildd) and is in Building state, then vanishes from the DB, then comes back) • (much worse) library transition old-version keeping is broken: suppose there is src:isl (= 0.12.2-2) building libisl10 in the archive and built on some architecture; then, someone uploads src:isl (= 0.14-2) which builds libisl13 instead; in dak (on the main archive), the old libisl10 binary packages are kept in the Packages.gz file until there is no dependency on it any more; mini-dak just throws all NBS binary packages away immediately Oh, and the performance. On the other hand, things like the existence of unreleased really *do* help, so, a ｂｉｇ thank-you to Aurélien for running d-ports❣ bye, //mirabilos PS: I’d be happy to discuss things (dpo experience) on debconf, if I manage to make some time for that in the days I’m there; can’t say beforehand, unfortunately -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1505061037260.27...@herc.mirbsd.org
Re: Debian Archive architecture removals
[ With my debian-ports admin hat ] On 2015-05-04 11:48, Cyril Brulebois wrote: > Lucas Nussbaum (2015-05-04): > > I'm wondering if we could find a way to accomodate those architectures > > in an official way, while still limiting the impact on ftpmasters and > > other teams. I'm not entirely clear on the status of debian-ports.org, First of all it should be noted that moving an architecture to debian-ports, while decreasing the load on ftpmasters, increases the load on debian-ports, so it doesn't change a lot for the project. In practice it even increases as you need more manpower to maintain an architecture in debian-ports than in the debian archive. That's why we should move an architecture to debian-ports only if it some people (DD or not) are really going to maintain it. If not we already have snapshot.debian.org for that. > > and of what the current downsides of using debian-ports are. Maybe it's > > just about supporting and advertising debian-ports as Debian's official > > way to host second-class architectures. Maybe there's more to it. > > Last I heard about it, it was understaffed and infra was undersized + > needed some changes to make it possible to grow. The situation hasn't really changed. Currently the whole debian-ports runs on a single machine, which is a VM kindly provided by DSA. This means running the archive (mini-dak) with http/ftp/rsync, buildd, cdimage and a few more services on a single machine. The machine is therefore heavily loaded, especially I/O wise and we had to disable rsync access except for a few mirrors working in push mode (so that we can control when they do the sync, ie not during mini-dinstall). On the manpower side we are also clearly understaffed, and only working in emergency mode when something is broken. For example the wanna-build installation is usually lacking months of commits compared to the official one. We tried to start addressing with a "plan" to move services to DSA administrated machine, as it can be seen there: [1]. We started by moving easy things like DNS and website. We then continued by moving the buildd service to a new machine called portman.d.o mimicking as much as possible the layout of the buildd.d.o installation, but we failed to do so in reasonable time. The main issue there is than buildd is a HUGE PAIN to setup as it is actually composed of wanna-build + wbpy + pgstatus + some additional scripts. Add to that some uncommitted code and code running in some $HOME... In addition to that it requires a lot specific setup as root, and thus interaction with DSA. We therefore decided to continue on that at Debconf 15 during a more general sprint [2]. After that we still haven't agreed on how to give access to non-DD people to a DSA administrated machine (see below why I believe it's important). We have some ideas about how to handle the remaining services but no real plan so far. Any help would be appreciated for the move, but also for longterm administration. Of course only serious help, not just unknown persons wanted to be root on debian-ports (yes we get this kind of offer from time to time). > > What > > are the current downsides of moving hurd-i386 and sparc to debian-ports? First of all we roughly have two kind of architectures on debian-ports: new architectures which are there for a short time until they get accepted as an official architecture and previously official architectures coming there to die on the longterm. debian-ports has been designed for the first case, where there is usually a lot of manpower. The second case is a bit more recent and started with the removal of official architectures from Debian. I see the following downsides in using debian-ports for an architecture, but they are likely a lot more: - debian-ports uses mini-dak instead of dak. It uses less resources and brings some features that are useful for new architectures like accepting binary uploads when it "improves" the version even if it is not the latest one or an "unreleased" suite for packages built from modified source (hence architecture specific). On the contrary its biggest issue is that it is source package based, which means if a package is renamed in a transition this causes the old binary package to disappear and the new one to appear. This causes a lot of extra work for transitions. - Build daemons are not "owned" by Debian, but have to be provided, hosted and administrated by individuals. It means the machine usually sits on DSL line behind a NAT, that's the reason why debian-ports also provide POP3 mailboxes (yes wanna-build partly communicates by mail). - The above is also true for porter boxes. - Given the above and due to the lack of manpower, more "broken time" than the official archive. - Transitions are not handled by the release team. - Bug reports concerning these architectures are more often ignored, even if they contain a patch. In addition to that I would like to remind that half of the people
Re: Debian Archive architecture removals
+++ Samuel Thibault [2015-05-05 09:17 +0200]:
> * Getting binNMUs from d-release transitions
>
> This saves porters a lot of tedious work that would otherwise be just
> duplicated. We are not talking about fine-grain binNMUs here, but
> coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps
> which makes it easy for d-release to just throw them at debian-ports
> archs along the master archs and forget about it.
I would just like to second this point, having brought a port through
d-p recently. Keeping up with transition binNMUs is a quite a
significant overhead for a (usually small and overworked) porting
team. As a porter one has a good understanding of arch-specific
issues, but very little understanding of current archive-wide
transitions. And the existing infrastructure doesn't tell you that
things have been rebuilt in the main archive so you should do it too -
you have to poll (or notice when things break/become uninstallable).
It would certainly be an improvement if d-p architectures at least got
notice of such rebuilds (maybe this already could happen, I just
didn't know how?). It would be even better if they automatically
propagated (although this may sometimes break stuff, especially in
early life of a port - some trade-offs there).
> Those two previous items may actually perhaps be fixed together:
> could it make sense to have the debian-ports architectures on
> buildd.debian.org, would it bring human overhead? The databases there
> are already per-architecture, so they don't actually interfere.
That's a intresting possibility, but there are also advantages to the
current separate instance/database, config, authorisation and usage
expectations. Merging would fix this issue but might cause others - I
don't know enough to say.
> Perhaps we need a political decision here?
I think it's mostly a practical one, as I don't see much disagreement
about the objectives here: What is the best way to arrange things to
support 'released, supported, all-equal' ports vs 'best-effort, let
them get out of sync' 2nd-class ports (both on the way up ('upcoming')
and on the way down ('legacy')).
Centralise the things we can to take workload off porters, distribute
things where ports being broken or unloved could hold up the
released ports.
This is the sort of thing where getting the right people in a room is
productive as hardly anybody has a good overview of all the
aspects/issues. Debconf session?
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
--
To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150505140457.gi18...@halon.org.uk
Re: Debian Archive architecture removals
Richard Braun, le Tue 05 May 2015 12:27:10 +, a écrit : > On Tue, May 05, 2015 at 01:36:57PM +0200, Arne Babenhauserheide wrote: > > Given that the package coverage of the Hurd continuously increased and > > that it just released 0.6 of its core components[1] along with releasing > > Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off > > ftp-master. > > It's irrelevant. Yes, my point is that it should not be relevant. Being mirrored is clearly useless. The concern is actually that being on master is currently more than about just that. Samuel -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505130015.gk6...@type.labri.fr
Re: Debian Archive architecture removals
On Tue, May 05, 2015 at 01:36:57PM +0200, Arne Babenhauserheide wrote: > Given that the package coverage of the Hurd continuously increased and > that it just released 0.6 of its core components[1] along with releasing > Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off > ftp-master. It's irrelevant. The Hurd isn't a popular system, few people actually use it, there are probably a lot more Debian mirrors than machines using them with hurd-i386 packages. It's simply not worth it. I'm not a Debian contributor but, as a Hurd contributor, it seems perfectly appropriate that the Hurd gets removed from there. On the other hand, I'm ready to provide resources so that things work nicely from debian-ports. -- Richard Braun -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505122710.ga31...@dalaran.sceen.net
Re: Debian Archive architecture removals
On Tue, May 05, 2015 at 09:17:02AM +0200, Samuel Thibault wrote: > [Speaking for the debian-hurd team] > > Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : > > Maybe it's just about supporting and advertising debian-ports as > > Debian's official way to host second-class architectures. Maybe > > there's more to it. What are the current downsides of moving hurd-i386 > > and sparc to debian-ports? > > That's perhaps the best question to address. Being on master just for > being mirrored is not useful to such kinds of ports of course. In the > current status of the Debian infrastructure, there are however a lot > more consequences, which we can perhaps work on, so as to avoid making > hurd-i386 and sparc essentially disappear, and perhaps at the same time > to revive some debian-ports archs without overhead for ftp-master, > d-release etc.. Also perhaps more easily consider removing more archs > from master. I completely agree. And I also agree that moving to debian-ports makes patches harder to get merged, but if debian-ports becomes something more official, it may get slightly easier. > Perhaps we need a political decision here? -- Richard Braun -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505123552.gb27...@dalaran.sceen.net
Re: Debian Archive architecture removals
Am Montag, 20. April 2015, 00:22:08 schrieb Joerg Jaspert: > hurd-i386 > = > Well before wheezy was released, we talked with the HURD porters, and > they agreed to re-check their archive status just after the wheezy > release[1]. The plan was to move the HURD port off ftp-master if it > wasn't included as a technology preview or full release arch. HURD > wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. Given that the package coverage of the Hurd continuously increased and that it just released 0.6 of its core components[1] along with releasing Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off ftp-master. [1]: http://www.gnu.org/software/hurd/news/2015-04-10-releases.html [2]: http://www.gnu.org/software/hurd/news/2015-04-29-debian_gnu_hurd_2015.html http://thread.gmane.org/gmane.os.hurd.bugs/27177 The Hurd isn’t an old architecture which is slowly fading away but rather slowly but steadily progressing and getting more stable. The qemu live image works right away, including the translator tests which show the unique capabilities of the Hurd. Best wishes, Arne -- Ein Würfel System - einfach saubere Regeln: - http://1w6.org signature.asc Description: This is a digitally signed message part.
Re: Debian Archive architecture removals
On 05/05/15 at 09:17 +0200, Samuel Thibault wrote: > * Appearing on packages' and maintainers' PTS > pages like http://buildd.debian.org/bash and > https://buildd.debian.org/sthiba...@debian.org > > * Being considered as "second-class citizen" Note that our developer dashboards (DDPO, Tracker, DMD) are already widely able to pick and combine data from various sources. So as long as the debian-ports data is reliable and useful, I don't think that it would be a problem to expose it more prominently. For example, it would be fairly trivial to add a "TODO" in https://udd.debian.org/dmd/ or tracker.d.o when there's a package in d-p's unreleased suite _and_ a bug tagged 'hurd' in the BTS. (UDD already knows about all the needed data for that, and I would happily create a json export for tracker to use) - Lucas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505073156.ga6...@xanadu.blop.info
Re: Debian Archive architecture removals
[Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : > Maybe it's just about supporting and advertising debian-ports as > Debian's official way to host second-class architectures. Maybe > there's more to it. What are the current downsides of moving hurd-i386 > and sparc to debian-ports? That's perhaps the best question to address. Being on master just for being mirrored is not useful to such kinds of ports of course. In the current status of the Debian infrastructure, there are however a lot more consequences, which we can perhaps work on, so as to avoid making hurd-i386 and sparc essentially disappear, and perhaps at the same time to revive some debian-ports archs without overhead for ftp-master, d-release etc.. Also perhaps more easily consider removing more archs from master. * Appearing on packages' and maintainers' PTS pages like http://buildd.debian.org/bash and https://buildd.debian.org/sthiba...@debian.org This makes people aware of portability issues; when hurd-i386 moved there some years ago, that did make a change: we saw maintainers caring and fixing their packages, quite often the fixes are quite trivial. It would be useful to see other debian-ports results there for portability checking, notably hppa. There is already a link to buildd.debian-ports.org, but people do not even notice it, let alone think about checking it. * Getting binNMUs from d-release transitions This saves porters a lot of tedious work that would otherwise be just duplicated. We are not talking about fine-grain binNMUs here, but coarse-grain well-known planned binNMUs. Wanna-build supports extra-deps which makes it easy for d-release to just throw them at debian-ports archs along the master archs and forget about it. Those two previous items may actually perhaps be fixed together: could it make sense to have the debian-ports architectures on buildd.debian.org, would it bring human overhead? The databases there are already per-architecture, so they don't actually interfere. * Appearing on http://release.debian.org/transitions/ and https://qa.debian.org/dose/debcheck/unstable_main/index.html We're fine with d-release not looking at the hurd column. But *we* however do look at it, and would be sad to completely lose that. It could be in a completely separate page or column, that would not pose problem. * Being considered as "second-class citizen" Well, this is already rather true for hurd-i386: we do sometimes get answers from maintainers "this is not going to be a release architecture, I will not bother with patches for it" (even about packaging patches). Or the patches linger on the BTS for years (see https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;tag=hurd) Currently we use the "important" severity for hurd-i386, but maintainers can just discard it. Being on debian-ports actually somehow partly helps here, since we can upload patched packages in "unreleased" and continue porting. But on the other hand this makes us less pushy, and patches tend to accumulate. Also, being on debian-ports makes it much more difficult to afford making binNMUs, and thus the patches can really linger in the BTS ad æternam. Perhaps we need a political decision here? Samuel -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505071702.gi3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
Joerg Jaspert, le Mon 04 May 2015 18:11:29 +0200, a écrit : > On 13931 March 1977, Lucas Nussbaum wrote: > > > That pad says: "As a result of current state, d-ports cannot accept more > > ports". If that's still true, it would make sense to postpone dropping > > hurd and sparc until this is fixed... > > Hurd is already on d-p, so hurd actually has double infrastructure use. Not really: we only have a dozen packages on d-p, the rest is not on d-p. > And the last "release" they did came from d-p resources, No, I got the packages from master, and used snapshot.d.o as a way to have a "frozen" image of it. Samuel -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504161609.gk3...@type.bordeaux.inria.fr
Re: Debian Archive architecture removals
On 13931 March 1977, Lucas Nussbaum wrote: > That pad says: "As a result of current state, d-ports cannot accept more > ports". If that's still true, it would make sense to postpone dropping > hurd and sparc until this is fixed... Hurd is already on d-p, so hurd actually has double infrastructure use. And the last "release" they did came from d-p resources, which is another argument not to continue on ftp-master with them. Sparc has sparc64 there, so that would be an addition to it. -- bye, Joerg -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87pp6gs4pa@delenn.ganneff.de
Re: Debian Archive architecture removals
On 04/05/15 at 18:04 +0800, Paul Wise wrote: > On Mon, May 4, 2015 at 5:48 PM, Cyril Brulebois wrote: > > Lucas Nussbaum (2015-05-04): > >> I'm wondering if we could find a way to accomodate those architectures > >> in an official way, while still limiting the impact on ftpmasters and > >> other teams. I'm not entirely clear on the status of debian-ports.org, > >> and of what the current downsides of using debian-ports are. Maybe it's > >> just about supporting and advertising debian-ports as Debian's official > >> way to host second-class architectures. Maybe there's more to it. What > >> are the current downsides of moving hurd-i386 and sparc to debian-ports? > > > > Last I heard about it, it was understaffed and infra was undersized + > > needed some changes to make it possible to grow. > > > > This was some time ago, so I've added admin@ to make sure we get updated > > intel on this topic. > > zumbi was working on moving debian-ports to debian.org infrastructure > and got some of it done (the website for instance). I asked him about > it on IRC and got this response: > > zumbi: this mail looks like it needs a status update re > ports.d.o https://lists.debian.org/20150504062822.ga24...@xanadu.blop.info > pabs: we had this: https://titanpad.com/debian-ports > pabs: I was hoping for debcamp/debconf to be able to finish it up > (however I am still unsure about if I'll be able to attend event) > zumbi: may I copy that into email or can you? > pabs: feel free to copy it > pabs: it needs someone with wanna-build database experience, > some dsa, aurel32 (and maybe some ftp-master) to complete the work That pad says: "As a result of current state, d-ports cannot accept more ports". If that's still true, it would make sense to postpone dropping hurd and sparc until this is fixed... Lucas -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504104741.ga18...@xanadu.blop.info
Re: Debian Archive architecture removals
On Mon, May 4, 2015 at 5:48 PM, Cyril Brulebois wrote: > Lucas Nussbaum (2015-05-04): >> I'm wondering if we could find a way to accomodate those architectures >> in an official way, while still limiting the impact on ftpmasters and >> other teams. I'm not entirely clear on the status of debian-ports.org, >> and of what the current downsides of using debian-ports are. Maybe it's >> just about supporting and advertising debian-ports as Debian's official >> way to host second-class architectures. Maybe there's more to it. What >> are the current downsides of moving hurd-i386 and sparc to debian-ports? > > Last I heard about it, it was understaffed and infra was undersized + > needed some changes to make it possible to grow. > > This was some time ago, so I've added admin@ to make sure we get updated > intel on this topic. zumbi was working on moving debian-ports to debian.org infrastructure and got some of it done (the website for instance). I asked him about it on IRC and got this response: zumbi: this mail looks like it needs a status update re ports.d.o https://lists.debian.org/20150504062822.ga24...@xanadu.blop.info pabs: we had this: https://titanpad.com/debian-ports pabs: I was hoping for debcamp/debconf to be able to finish it up (however I am still unsure about if I'll be able to attend event) zumbi: may I copy that into email or can you? pabs: feel free to copy it pabs: it needs someone with wanna-build database experience, some dsa, aurel32 (and maybe some ftp-master) to complete the work -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6FXYe0te=rE-2B0-8OCgdG=tut_et66mkhu6rgnjwc...@mail.gmail.com
Re: Debian Archive architecture removals
Lucas Nussbaum (2015-05-04): > I'm wondering if we could find a way to accomodate those architectures > in an official way, while still limiting the impact on ftpmasters and > other teams. I'm not entirely clear on the status of debian-ports.org, > and of what the current downsides of using debian-ports are. Maybe it's > just about supporting and advertising debian-ports as Debian's official > way to host second-class architectures. Maybe there's more to it. What > are the current downsides of moving hurd-i386 and sparc to debian-ports? Last I heard about it, it was understaffed and infra was undersized + needed some changes to make it possible to grow. This was some time ago, so I've added admin@ to make sure we get updated intel on this topic. Mraw, KiBi. signature.asc Description: Digital signature
Re: Debian Archive architecture removals
On 20/04/15 at 00:22 +0200, Joerg Jaspert wrote: > Hi, > > As the jessie release approaches, the ftp-team have been reviewing the > status of the architectures in unstable. > > Neither sparc nor hurd-i386 are going to release with jessie and we are > therefore looking at their future in unstable. > > > SPARC > = > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745938 > > Given the current lack of proper kernel support and the lack of upstream > toolchain support, we intend to remove sparc *at the latest*, three > months after the release of jessie. This could be avoided if there is a > team of Debian Developers putting in a serious effort to revive this > port, thus the 3 months timeframe. If this happens, please keep track in > an easy reviewable way, so we can recheck it before actual removal (for > example list of closed bugs, uploads, upstream patch work, ...). > > It is noted that the sparc64 port is likely to be a more suitable basis > for any future SPARC work but that nobody has approached us about > inclusion. > > hurd-i386 > = > Well before wheezy was released, we talked with the HURD porters, and > they agreed to re-check their archive status just after the wheezy > release[1]. The plan was to move the HURD port off ftp-master if it > wasn't included as a technology preview or full release arch. HURD > wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie. > > We'll be removing HURD, as discussed, from the ftp-master archive after > the Jessie release. > > [1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html Hi, I fully understand that those architectures cause an additional load on ftpmasters (and various other teams). But I've always been very proud that Debian was able to accomodate a wide variety of architectures and kernels (even if I've not done much to achieve that). I find it sad that we will soon have to say "oh, and there are also people maintaining an unofficial Hurd port outside Debian". I'm wondering if we could find a way to accomodate those architectures in an official way, while still limiting the impact on ftpmasters and other teams. I'm not entirely clear on the status of debian-ports.org, and of what the current downsides of using debian-ports are. Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? Lucas signature.asc Description: Digital signature
