Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
On 4/13/2019 12:49 PM, Aurelien Jarno wrote: > The process to inject all packages to debian-ports is to get all the > deb, udeb and buildinfo files from the archives (main and debug) and > associate them with the .changes files that are hosted on coccia. We'll > also need to fetch all the associated GPG keys used to sign the changes > files. Then we can inject that in the debian-ports archive. I'm curious how the GPG bit works given that there is no guarantee that the signature can be validated at any other point in time than ingestion on ftp-master - especially considering the rotation/expiry of subkeys and buildd keys. In this case the files already come from a trusted source and should be ingested as-is, I guess? (Not that I particularly like the fact that it's only a point in time validation.) Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On 2016-06-15 00:37, Dimitri John Ledkov wrote: There is openmainframe project https://www.openmainframeproject.org/ , which I believe offers access to z/VM instances hosted by Marist colledge. At the openmainframeproject EU meetup, it was indicated that SUSE joined with indication that Open Build Service might be able to use resources hosted by Marist. I wonder if it makes sense to reach out, and see if there are resources available to use as porter boxes & build boxes. That way Debian might be able to get such donated resource available on ongoing basis and hopefully with some hw support. Debian already makes use of Marist's resources. The challenge was/is to get redundancy as DSA very sensibly insists on. Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On Mon, Jun 13, 2016 at 07:33:56PM +, Niels Thykier wrote: > Philipp Kern: > > On 2016-06-05 12:01, Niels Thykier wrote: > >> * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, > >>s390x > >>- *No* blockers at this time from RT, DSA nor security. > >>- s390, ppc64el and all arm ports have DSA concerns. > > What is the current DSA concern about s390x? > The concern listed as: "rely on sponsors for hardware (mild concern)" > > As I recall the argument went something along the lines of: > > "Debian cannot replace the hardware; if any of the machines dies, we > need a sponsor to replace it. If all of them dies and we cannot get > sponsored replacements, we cannot support the architecture any longer" > > (My wording) Yeah, but that's unfortunately one of the universal truths of this port. I mean in theory sometimes they turn up on eBay and people try to make them work[1]. It also seems true for other ports where we commonly relied on sponsors to hand us replacements. But maybe it's only ppc64el these days, maybe there are useful builds available for the others (including arm64 and mips) on the market now. Kind regards and thanks Philipp Kern [1] https://www.youtube.com/watch?v=45X4VP8CGtk (Here's What Happens When an 18 Year Old Buys a Mainframe)
Re: [Stretch] Status for architecture qualification
On 2016-06-05 12:01, Niels Thykier wrote: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x - *No* blockers at this time from RT, DSA nor security. - s390, ppc64el and all arm ports have DSA concerns. What is the current DSA concern about s390x? Kind regards and thanks Philipp Kern
Re: binNMUs: please exercise some care
On Fri, Oct 23, 2015 at 02:46:23PM +0200, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > > and testing), so the only way to be certain what binNMU number to use is to > > check manually. In practice what actually happens is that people forget > > about > Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. Unfortunately it is not being run on the same host as dak either. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013 at 02:46:27PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. What is your plan to support partial upgrades? BinNMUs can require new Qt versions to be installed, but Qt can be upgraded independently to the newer version, causing the rdepends to crash. This can potentially be solved by Breaks, but it still breaks assumptions of people using Debian in that such ABI breaks will be communicated through SONAME bumps. And the old lib will not even be coinstallable. (Of course a good time to do such changes are in fact SONAME bumps, but I realize that this won't happen for Qt for quite some time.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Please try rebuilding imagemagick on sparc (2nd try)
On Thu, Nov 22, 2012 at 07:05:26AM +0100, Bastien ROUCARIES wrote: And under other arch we do not found anything. I do not have an access to a porter box (dm), i will ask but i néed more information in order to reproduce http://dsa.debian.org/doc/guest-account/ Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Please try rebuilding imagemagick on sparc (2nd try)
Vincent, am Wed, Nov 21, 2012 at 11:43:06AM +0100 hast du folgendes geschrieben: gb imagemagick_8:6.7.7.10-5 . sparc This FTBS has been hitting imagemagick sporadically without any pattern, and never in a way related to code changes. I suspect it may be a subtle toolchain bug, but as it is not very reproducible, there's no simple way to dig into that. So far, rebuilding has always succeeded, suggesting a small probability to trigger the bug. I'd guess some valgrind might be in order? Anyway done. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: SPARC daily d-i builds
On Sun, Jan 23, 2011 at 10:05:40PM +, Jurij Smakov wrote: Fair enough. However, the machine has 32 CPUs and 32G of RAM, so even while used as a buildd, significant amounts of resources are probably just sitting idle. I see that it only has 72G of disk though (2x72G disks in RAID-1 config), however we could probably solicit donation of the disks needed or even convince DPL to throw some money at it. Hence the questions: 1. Is there any virtualization solution on zee which would allow us to run more than a single buildd on it? 2. If disks are the bottleneck, what are the part numbers for them? I guess that if we would get another two, we could simply make another RAID-1 volume out of that, to not interfere too much with existing setup? 3. Who is the right person to talk to about arranging various reconfigurations like that? It'd make sense to Cc d-admin on this. FWIW, I do recall bad memory issues with zee, it's currently down to 16G of RAM, too. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: SPARC daily d-i builds
Hi, am Wed, Jan 12, 2011 at 01:53:59AM +0100 hast du folgendes geschrieben: Gaudenz Steinlin gaud...@debian.org (11/01/2011): As all my attempts to find someone willing to setup d-i daily builds on a sparc buildd [1] failed. I'm going to give up now and will not bother you again until some steps up to do the necessary work or provide me with buildd access. I added the following note to the d-i daily builds overview page: Due to the lack of porter and buildd admin interest there are currently no daily builds for the SPARC architecture. These builds will be reenable as soon as someone finds the time to do the necessary buildd setup. I would also be willing to do the neccessary setup myself if someone provides me with the necessary access to a sparc buildd. So, again, it's not about lack of interest, it's about lack of time. Also, you could have pinged debian-wb-t...@. I believe aba did most of the d-i autobuilding stuff, so he might have some clue to share. I've added this list to the loop. and I did tell on #d-boot the following on Nov 13 2010: [...] 15:27 trave11er ok, we didn't get any reply from stappers, so sparc dailies still have the old kernels, afaict [...] 15:31 otavio trave11er: buildd people were going to put sparc into it 15:31 otavio trave11er: dunno if it has been done 15:31 otavio adsb: ^? [...] 15:33 phil otavio: were going to is quite untrue. There still isn't a bug report, and I did report the result of my investigation, i.e. there's no space on the only LVMed sparc buildd we have. 15:37 otavio phil: I didn't recall about the space issue 15:37 otavio phil: indeed So meh, whatever. To my knowledge that's still true. We currently don't have the capacities and we admitted that. Furthermore not asking -wb-team might not give you answers, indeed. Sorry if I missed something along the way. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote: maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The point of injection is for discussion. I would prefer having this set in dpkg-buildflags, and then disabled by these ~100 packages. Note that this is probably the same like modifying the N - ~100 packages, as almost no package respects dpkg-buildflags yet. Did you actually do a build test? Kind regards Philipp Kern signature.asc Description: Digital signature
Meeting Minutes for the IRC Release Team Meeting on August 23, 2010
Hi there, those are the minutes of Monday's IRC meeting at #debian-release. 1) What will be the release architectures for squeeze? - sparc will be kept as a release architecture for now. The gcc code generation code which moved to v9/32bit has taken place in Nov 2009. There will be rebuilds of all packages that haven't been rebuilt since. The exact details of this still need to be sketched out. [assignee: pkern] - mips*: #519006 is hurting us badly. GCC upstream was pinged, Loongson and Codesourcery will be contacted about a backport to gcc-4.4 if there's no answer. [assignee: aurel32] - mips: a possible toolchain issue popped up on openjdk-6, which needs investigation [assignee: aurel32] - mipsel: another Loongson machine will be shipped to aba for use as a porter box [assignees: zobel, aba] - hppa: HPPA will be dropped as a release architecture for squeeze. Details on a possible squeeze-hppa release need to be discussed with the hppa porters. [assignee: ?] - kfreebsd-*: We consider a released kfreebsd-* package set as a technology preview, that might not be up to the full Debian standards. We will try to keep it in the same infrastructure set (i.e. as normal architectures) for squeeze, but this can be reviewed later. 2) Which transitions are left for squeeze? What's their current state? - gnustep: RC bug on hppa, fix pending upload. Looks good otherwise. - opencv: one FTBFS on hppa - ace: FTBFS on armel and kfreebsd, not a blocker - php: No transition removing deprecated features. - mono: mail to debian-release@ to be sent [assignee: meebey] - apt: transition can be started in unstable [assignee: mvo] - xapian: ditto [assignee: olly] 3) Release Team meeting 2-3 October in Paris: Who's going? - Negotiations about times, crashing space and travel sponsorship need to be done with zack. [assignee: faw] - mehdi, jcristau, luk, adsb, aba and pkern can probably make it; HE: unsure; faw: relying on the availabilty of overseas travel sponsorship, if not possible following remotely - Maulkin cannot make it. 4) What's the state of the Release Notes? - timeline: 4 weeks to get them ready, 2 weeks of string freeze, 1 week of fixes and final week for translations (i.e. 2 months) [assignee: faw] - upgrade-reports to be prepared and solicited [assignee: vorlon] 5) Any other business? - This item was not called as the time budget was exceeded. A full log is available on [1] (text-only version on [2]). Action and info items are also available as extracted bits on [3]. Kind regards, Philipp Kern on behalf of the Debian Release Team [1] http://meetbot.debian.net/debian-release/2010/debian-release.2010-08-23-20.02.log.html [2] http://meetbot.debian.net/debian-release/2010/debian-release.2010-08-23-20.02.log.txt [3] http://meetbot.debian.net/debian-release/2010/debian-release.2010-08-23-20.02.html signature.asc Description: Digital signature
IRC Release Team Meeting on Mon, Aug 23rd, 20 UTC
Dear fellow developers, the Release Team will hold an IRC meeting at #debian-release on irc.debian.org on Monday, August 23rd, at 20 UTC. The following agenda was proposed for the meeting: 1) What will be the release architectures for squeeze? (hppa, kfreebsd-*, sparc and mips had concerns raised about their releasability.) 2) Which transitions are left for squeeze? What's their current state? 3) Release Team meeting 2-3 October in Paris: Who's going? 4) What's the state of the Release Notes? 5) Any other business? We will try to work with a soft deadline of 1h and a hard one of 1,5h. Later items on the list might be postponed to a later meeting. Kind regards, Philipp Kern on behalf of the Debian Release Team signature.asc Description: Digital signature
Re: IRC Release Team Meeting on Mon, Aug 23rd, 20 UTC
On Tue, Aug 17, 2010 at 11:13:44PM +0200, Josip Rodin wrote: On Tue, Aug 17, 2010 at 09:52:34PM +0200, Philipp Kern wrote: sparc had concerns raised about [its] releasability http://release.debian.org/squeeze/arch_qualify.html indicates the number of porters and upstream support is questionable by being yellow, but other than that there is no real explanation. It would be good if this was clarified, so that we know what you guys actually expect. Well, for upstream support there is: at the bottom of the page. According to doko sparc32 code generation is unmaintained upstream, and he doesn't want to step up to maintain it any longer. Furthermore I found the following thread dated back to 2007: http://lists.debian.org/debian-sparc/2007/07/msg00049.html So far nobody stepped up to provide us with a working sparc64 port. I know that aurel32 did some work on zee.debian.org, but was hurt by bad RAM in that box (AFAIR). What we are currently struggling with are build failures that happen on one class of the builders, while not happening on the other, and IIRC this is happening vice-versa. Hopefully others can fill in the gaps I left here. Kind regards, Philipp Kern signature.asc Description: Digital signature
Re: Sparc release requalification
On Thu, Aug 20, 2009 at 10:45:46AM +0200, Bastian Blank wrote: On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote: On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. No, we don't need to do that. Thats what is multiarch for. It's not intended that multiarch supports switching architectures. Of course it would help to import some 64bit packages selectively from a sparc64 port but most of your binaries would still be 32bit with the only partially supported code generation? Even on a rebuild you would have to pull in the 64bit libs in a way you build against them by default? (Or would that boil down to passing another DEB_*_ARCH so that config.guess targets 64bit and stuffing that into simple packages with arch:sparc?) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Sparc release requalification
Josip, am Tue, Aug 18, 2009 at 11:23:27PM +0200 hast du folgendes geschrieben: (on a somewhat brighter note, Stephen Gran has reported an almost successful install on T2K recently [0]) (Is that the newly donated machine that we had been talking about a while ago?) donated to Debian years ago, only DSA'ed very, very recently. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: [SRM] xorg and xorg-server update for lenny
On Wed, Jun 03, 2009 at 09:49:19PM +0200, Julien Cristau wrote: the workaround put in xorg-server for 5.0.1 didn't fix the problem on sparc with pci drivers, and actually made things worse for some people, so I'd like to revert it in 5.0.2, and try to fix it some other way instead. The xorg-server update would: - remove the patch added in r1 - cherry-pick a patch to fix the idletime xsync timer (see http://packages.qa.debian.org/g/gnome-session/news/20090521T093223Z.html and http://cgit.freedesktop.org/xorg/xserver/commit?id=1f4fb0225b278d1cf4145aebeb0bdd23dc8f62d5) I'm not attaching the patch here, it's in git, branch debian-lenny, for those who care. ACK. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
