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-bsd-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: 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-bsd-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
Bug#665997: libbsd uses wrong compiler when cross-building
Source: libbsd Version: 0.3.0-2 Tags: Patch User: crossbu...@debian.org Usertags: cross As part of making debian 'bootstrappable' we are making sure that at least the core system is cross-buildable. libbsd uses 'gcc' directly, so cross-compiling fails. The attached patch fixes that. This bug corresponds to ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/libbsd/+bug/963060 Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ diff -ur origs/libbsd-0.3.0/Makefile patched/libbsd-0.3.0/Makefile --- origs/libbsd-0.3.0/Makefile 2011-06-02 17:20:55.0 + +++ patched/libbsd-0.3.0/Makefile 2012-03-27 16:46:52.0 + @@ -119,7 +119,6 @@ LIB_SHARED_OBJS := $(LIB_SRCS:%.c=%.lo) AR = ar -CC = gcc CCLD = $(CC) # Set default values for user variables diff -ur origs/libbsd-0.3.0/debian/rules patched/libbsd-0.3.0/debian/rules --- origs/libbsd-0.3.0/debian/rules 2012-02-25 19:41:15.0 + +++ patched/libbsd-0.3.0/debian/rules 2012-03-27 16:45:48.0 + @@ -4,6 +4,7 @@ #export DH_VERBOSE=1 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) CFLAGS := -Wall $(shell dpkg-buildflags --get CFLAGS) @@ -20,7 +21,7 @@ build-arch: dh_testdir - $(MAKE) CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" + $(MAKE) CPPFLAGS="$(CPPFLAGS)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" CC="$(DEB_HOST_GNU_TYPE)-gcc" build: build-indep build-arch
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/
