Re: Porter roll call for Debian Bullseye
On 2020-11-02 22:23 +0200, Graham Inggs wrote: > Hi > > We are doing a roll call for porters of all release architectures. If > you are an active porter behind one of the release architectures [1] > for the entire lifetime of Debian Bullseye (est. end of 2024), please > respond with a signed email containing the following before Friday, > November 27: > > * Which architectures are you committing to be an active porter for? arm64,armhf,armel > * Please describe recent relevant porter contributions. on-site support for buildds at arm. process day-to-day buildd requests give-backs) investigate missing arm support (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724711) investigate compiler issues and push to arm compiler team if appropriate (e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974058 ) run rebuilds across the arch occaisionally (currently planned for arm64 to test BTI support and armhf to test 64-bit timet release) > * Are you running/using Debian testing or sid on said port(s)? yes. I have three arm64 buildds (I did have an arm64 desktop until we all got sent home - it's now stuck in the office, but I should have an arm64 laptop from next week...) (thunderx, softiron, Ampere emag). and an assortment of armhf and armel devices including my home controller (armel, balloonboard) (odroid, hikey, arndale, cubietruck, qnap). My home server and mythtv backend was armhf until it croaked last month. An emergency x86 box has been stuffed in until I work out what's wrong with it/replace it. > * Are you testing/patching d-i for the port(s)? Yes. Added multiple console support for last release. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: binNMUs: please exercise some care
+++ Emilio Pozuelo Monfort [2015-10-23 11:49 +0200]: > On 23/10/15 11:20, Thorsten Glaser wrote: > > How about, scheduling them all at once, but using the same version > > number across arches when doing it (i.e. the largest)? > > Again, that involves determining what that number is for each package... That is a single-page lookup, though, so only one lookup, not one for each arch e.g: https://buildd.debian.org/status/package.php?p=harfbuzz > Instead of all that manual work for every transition, you could ping > #758616 and try to get this solved at its root. It would clearly be better if we either did sourceful rebuilds or fixed the 'binNMU skew' problem. But we do need to do something reasonably soon otherwise it's not going to be ready for Stretch either. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Re: using build profiles breaks debian-ports
+++ Thorsten Glaser [2015-07-17 09:31 +0200]: > Hi *, > > using build profiles breaks debian-ports architectures, all of them: > > http://buildd.debian-ports.org/status/package.php?p=x264 > > │Dependency installability problem for [33]x264 on alpha, hppa, m68k, sh4, > sparc64 and x32: > │ > │x264 build-depends on missing: > │- empty-dependency-after-parsing > > wdiff shows: > > Version: ⌦2:0.146.2538+git121396c-2⌫ ▶2:0.146.2538+git121396c-3◀ > > Build-Depends: […] libgpac-dev (>= ⌦0.5.0+svn4288~),⌫ ▶0.5.0+svn4288~) > ,◀ […] > > So this means that because someone added the build profiles thing, > wanna-build (or something else in the component stack) on dpo can > no longer calculate B-D installability for those packages, which > sorta defeats the purpose of adding it. We tried hard to find and fix everthing that would care: https://wiki.debian.org/BuildProfileSpec#Document_status I guess there is something different about ports infra, or something that has not been updated. I've pointed Josch at this bug to investigate. dose should be doing those buil-dep calcs and it has understood this for ages. 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/20150717114720.gp17...@halon.org.uk
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: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
+++ Niels Thykier [2013-10-02 09:45 +0200]: > Hi, > > The final results are in: > > Summary table: > Arch || DDs || NMs/DMs || Other || Total > ---++-++-++---++-- > armel || 3 || 0 || 1 ||4 > armhf || 3 || 1 || 2 ||6 > armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve > McIntyre (DD) > armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), > Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McIntyre (DD) I am surprised not to see Riku Voipio and Hector Oron on this list as I know they help manage the buildds and Riku signs uploads. I don't know if they are trying to escape, or just being too slack to send mail :-) > arm64: Wookey (DD), Steve McInture (DD) There are other DDs working on this too (Doko and Riku particularly), but again they are probably trying to avoid getting any more formal responsibilities. :-) Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, 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: http://lists.debian.org/20131002150724.ge32...@stoneboat.aleph1.co.uk
Therion build stuck on sparc?
Therion: http://packages.qa.debian.org/t/therion.html has been waiting for the sparc build for a while now. http://buildd.debian.org/~jeroen/status/architecture.php?a=sparc shows that therion has now been in state 'building' for 28 days (on lebrun) I suspect something is broken there as it shouldn't take more than a couple of hours. Can someone take a look and see what might be wrong? If that's not clear (or the below is easier) then if someone could do: apt-get install dbs docbook-to-man libvtk5-dev in the sid chroot on sperger then I'll do a test-build there. cheers Wookey -- Principal hats: Balloonz - Toby Churchill - Aleph One - Debian http://wookware.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Joliet support for s390 CDs
On Tue 12 Nov, Steve McIntyre wrote: > On Tue, Nov 12, 2002 at 12:43:42PM +0000, Wookey wrote: > >To the CD-team more generally: Looking at the scripts I see that i386 and > >alpha CDs add -J automatically, but not the other arches. Is there a good > >reason why we don't make them with -J anyway for exactly this reason (easy > >to browse on a handy windows box before the install?). I suppose it uses up > >some space on the CD, but presumably not actually very much? I make my ARM > >CDs with -J and no-one has complained... > > There was a hint of problems for m68k a long time ago, ISTR. So I > turned off -J for the m68k CDs a long time ago, in slink IIRC. CC:ed to porters. Can porters tell the CD team whether they would prefer CDs to be made with Joliet long-filenames (as well as the current options) or not. Is this known/thought to cause problems on any architectures these days. If not then I suggest we turn it back on as it's extremely useful to those that need it. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
