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: 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
