Re: Porter roll call for Debian Bullseye
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote: > On 12/1/20 5:02 AM, YunQiang Su wrote: > > I am sorry for the later response. > >Hi, > > > > I am an active porter for the following architectures and I intend > > to continue this for the lifetime of the Bullseye release (est. end > > of 2024): > > > > For mipsel and mips64el, I > > - test most packages on this architecture > > - run a Debian testing or unstable system on port that I use regularly > > - fix toolchain issues > > great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in > testing ... >... This problem has now been resolved: https://tracker.debian.org/pkg/gcc-defaults-mipsen https://tracker.debian.org/pkg/gcc-10-cross-mipsen cu Adrian
Re: Porter roll call for Debian Bullseye
Hi, sorry for the late reply and thanks a lot Graham for pinging me directly. I didn't monitor -devel closely lately, but I am an active porter for the following architecture and I intend to continue this for the lifetime of the Bullseye release (est. end of 2024): For ppc64el, I - test most packages on this architecture - run a Debian testing or unstable system that I use regularly - fix ppc64el-related bugs, especially by following https://udd.debian.org/cgi-bin/ftbfs.cgi - test d-i on a daily basis with an homegrown automated iso (sid netboot/testing netinst/bullseye alphas) installer (vm and PowerVM) and moving to OpenQA now. - fix d-i bugs/issues I am a DD, Frédéric Bonnard signature.asc Description: PGP signature
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: Porter roll call for Debian Bullseye
On Sun, Dec 06, 2020 at 01:03:17PM +0100, Matthias Klose wrote: > On 12/1/20 5:02 AM, YunQiang Su wrote: > > I am sorry for the later response. > >Hi, > > > > I am an active porter for the following architectures and I intend > > to continue this for the lifetime of the Bullseye release (est. end > > of 2024): > > > > For mipsel and mips64el, I > > - test most packages on this architecture > > - run a Debian testing or unstable system on port that I use regularly > > - fix toolchain issues > > great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in > testing ... The main blocker for that seems to be a bug that was fixed in gcc-10 10.2.0-20, a new source upload with the gcc-10-source build dependency bumped to (>= 10.2.0-20~) should fix that. binNMU won't work due to binary-all. > > - triage arch-specific bugs > > - fix arch-related bugs > > any help with #972269 ? I looked into it back then, at least for me there was nothing obvious why dbus-python failed and not other packages. A few months earlier one other package had a similar problem, but it seems rare enough that it shouldn't be a high priority for anyone. cu Adrian
Re: Porter roll call for Debian Bullseye
On 12/1/20 5:02 AM, YunQiang Su wrote: > I am sorry for the later response. >Hi, > > I am an active porter for the following architectures and I intend > to continue this for the lifetime of the Bullseye release (est. end > of 2024): > > For mipsel and mips64el, I > - test most packages on this architecture > - run a Debian testing or unstable system on port that I use regularly > - fix toolchain issues great ;-) gcc-cross-mipsen and gcc-10-cross-mipsen have never been in testing ... > - triage arch-specific bugs > - fix arch-related bugs any help with #972269 ?
Re: Porter roll call for Debian Bullseye
I am sorry for the later response. Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Bullseye release (est. end of 2024): For mipsel and mips64el, I - test most packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - provide hardware for automated tests on ci.d.n, jenkins.d.n (etc.) - ... I am a DD YunQiang Su signature.asc Description: This is a digitally signed message part
Re: Porter roll call for Debian Bullseye
On 2020-11-20, Graham Inggs wrote: > A friendly reminder about the porter roll call for bullseye. > > On Mon, 2 Nov 2020 at 22:23, Graham Inggs wrote: >> 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: > > Please note we don't automatically assume that porters for previous > releases will continue to do so. > If you were a porter for a previous release, we'd like you to sign up > again for bullseye. I know I'm a bit late to the party now... I do run both arm64 and armhf on numerous machines, mostly as part of the reproducible builds zoo. We mostly stick to stable for the main OS, but do run unstable and testing in chroots. I also sometimes run testing or individual packages from unstable on various other armhf and arm64 machines I use and make efforts to report and ideally fix bugs when encountered. I maintain u-boot and arm-trusted-firmware, used primarily on armhf and arm64. I do occasional debian-installer work and linux related work for both arm64 and armhf. I can most likely continue doing the above for the forseeable future. Not likely to fix deeply complicated toolchain issues. If all that qualifies for a porter hat, ok, if not, also ok. :) live well, vagrant signature.asc Description: PGP signature
Re: Porter roll call for Debian Bullseye
Hello! On 11/2/20 9:23 PM, Graham Inggs wrote: > 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? > * Please describe recent relevant porter contributions. > * Are you running/using Debian testing or sid on said port(s)? > * Are you testing/patching d-i for the port(s)? > > Please note that no response is required for amd64 because our > toolchain maintainers are happy to support amd64 as-is. Also note > that this waiver no longer applies for i386, where it did in previous > releases. Since there haven't been any replies to this call - at least not on the lists that I am currently on - I would like to make a suggestion to address this porter issue in the long term. In Debian Ports, we have many users that would still like to be able to use stable or testing releases which we can't offer since we don't have a Britney instance ourselves. We are also missing a proper instance of the Debian Archive Kit (DAK) meaning that we don't have the possibility to use cruft, see [1]. If we had both Britney and a proper DAK in Debian Ports, we could make Debian Ports more official by turning Debian's architecture support policy into a tier system similar to many other projects such as NetBSD [2]. The plan would be that ports can be promoted and demoted between tiers at the courtesy of the release team. Current release architectures would be Tier I while ports architectures would be Tier II. Being Tier I means, port must have a dedicated porter team, Tier II means that the Debian Ports team takes care of the maintenance of the port, similar to what the QA team already does for packages. Tier I is guaranteed to be stable with FTBFS bugs and other QA issues being release critical while such bugs on Tier II will only be classified as important or normal. This means that users will still be able to install fresh releases on Tier II targets, we just don't guarantee that it will work. At the same time, the release and security teams don't have to deal with ports where finding porters is more difficult. The only problem that I see with this approach is that DSA will probably not be easily transferring administration rights over Tier I buildds to the Debian Ports team when a port becomes Tier II. Similarly, DSA will probably not agree to take care of Tier II buildds. So the question over server administration could be an actual blocker for such a concept, although it would probably less critical in practice as ports won't be moved between tiers too often. And we would need to get DAK and Brtiney for Debian Ports, first, of course. Any comments? Adrian > [1] https://lists.debian.org/debian-sparc/2017/12/msg00060.html > [2] https://www.netbsd.org/ports -- .''`. 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
Re: Porter roll call for Debian Bullseye
Hi A friendly reminder about the porter roll call for bullseye. On Mon, 2 Nov 2020 at 22:23, Graham Inggs wrote: > 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: Please note we don't automatically assume that porters for previous releases will continue to do so. If you were a porter for a previous release, we'd like you to sign up again for bullseye. Please refer to the architecture requalification page [1] for the current status. Graham, on behalf of the release team [1] https://release.debian.org/bullseye/arch_qualify.html
Porter roll call for Debian Bullseye
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? * Please describe recent relevant porter contributions. * Are you running/using Debian testing or sid on said port(s)? * Are you testing/patching d-i for the port(s)? Please note that no response is required for amd64 because our toolchain maintainers are happy to support amd64 as-is. Also note that this waiver no longer applies for i386, where it did in previous releases. Feel free to use the following template as your reply: """ Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the Bullseye release (est. end of 2024): For , I - test (most|all) packages on this architecture - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - triage d-i bugs - test d-i regularly - fix d-i bugs/issues - maintain buildds - maintain/provide hardware for (or assist with) automated tests on ci.d.n, jenkins.d.n (etc.) - run other automated tests outside the Debian QA services (Please describe these) - ... """ Graham, on behalf of the release team [1] https://release.debian.org/bullseye/arch_qualify.html
