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
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: Releasability of the HPPA port
Carlos, On 08/06/2010 10:48 AM, Carlos O'Donell wrote: I think we do agree that it will be included into stable for the last time. Under which metrics or evaluation process is this decision being made? basically the criteria listed on [0] (which is again not entirely up-to-date, though). I think for hppa it would be mainly architecture availability, keeping the buildds running for yet another stable release until EOL (which would for squeeze probably be now+0,5y+2y+1y=now+3,5y), buildds being redundant hardware-wise, builds not failing for the security in non-obvious manners[1], having some upstream support, etc. More than one porter is also important so that we are not left alone if the only person working on it needs to shift his/her priorities (c.f. bus factor). Kind regards, Philipp Kern [0] http://release.debian.org/squeeze/arch_qualify.html [1] Like requiring multiple give-backs until it finally builds. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5ce47a.1020...@debian.org
Releasability of the HPPA port
Dear HPPA porters, dear HPPA port users, the Release Team is currently wondering if it makes sense to release with HPPA as a regular stable architecture with squeeze. It might be that it is not up to the standards of a regular Debian release. We seem to chase random segmentation faults, causing multiple give-backs to eventually yield a built package. Especially this is also causing concerns from a security building point of view, as autobuilding has to work for this. If it's not entirely up to our standards, would a separate suite, like it has been done in the past for etch-m68k, help having some sort of release that can be updated independently from the main stable release? Such a suite could also be useful to land larger changes than normally allowed for stable and maybe to continue the hppa port from a stable foundation for some time. I think we do agree that it will be included into stable for the last time. Kind regards, Philipp Kern signature.asc Description: Digital signature
Re: Status of the hppa buildds
Hallo Frans, am Fri, Nov 13, 2009 at 08:51:52AM +0100 hast du folgendes geschrieben: dann frazier wrote: Things are back in order. Today I finished getting the new penalosa setup as a buildd, and I've resurrected peri which appeared to be having problems talking to w-b. I've worked around the libstdc++/apt problem on both by downgrading to a working version. paer does not look to be up yet, but does have a huge list of packages assigned to it in state building [1]. The other 2 buildds are only picking relatively recent uploads from the needs build list, which means that the older uploads assigned to paer are still not going anywhere. So, unless paer will be up soon, I think that the packages assigned to it should be reassigned or moved back to the needs build queue. I just gave back a whole bunch of packages. 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: HPPA and Squeeze
On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote: Here is a list of packages that failed to build because of instability on the buildds today: package | buildd | error qgit| penalosa | make: *** [install] Segmentation fault acpica-unix | peri | make: *** [install] Segmentation fault I had those random segfaults in make on paer too, until we switched to the UP kernel, at least from what I saw. Sadly it looks that I forgot the buildd upgrade process on paer some days ago. The buildd will be back building ASAP. 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: Boost build failure on hppa
[ Please Cc me as I'm not subscribed to the list. ] On 2009-05-14, Steve M. Robbins st...@sumost.ca wrote: On Wed, May 13, 2009 at 05:37:36PM +0200, Domenico Andreoli wrote: On 5/12/09, Steve M. Robbins st...@sumost.ca wrote: No other arch failed to copy these files, and the previous build (-5) on hppa [2] exhibited no such trouble. The only difference between -5 and -6 is a debian/control change to a conflicts specification. I blame the build daemon. Can someone have a look? =20 indeed it built successfully on my hppa box. Thanks, Domenico. Could the powers-that-be please reschedule boost1.38 on hppa? Please Cc debian-wb-t...@lists.d.o next time. I just discovered this mail by chance. I rescheduled it yesterday in order to get more build material for a new hppa buildds (paer)[*] and it built successfully. Sadly, in other news, paer suffers from random segfaults, too. This makes building quite unreliable, but at least the machine does not crash like our other buildds (peri and penalosa) do. It would be nice if someone could debug this, as it makes buildd maintainance fairly unpleasant. (In this case the buildd is freely accessible for DDs but still that does not help much because it's random. We saw more segfaults in unstable builds than in stable and oldstable builds. Does that mean that the glibc in unstable could have its hands in the game? If so, the sid chroot on the porter machine could be used for data gathering.) Kind regards, Philipp Kern [*] Which is actually also our porterbox. -- To UNSUBSCRIBE, email to debian-hppa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
