DSA concerns for jessie architectures
[please consider replacing debian-ports@ldo with the appropriate port specific list when replying.] Comrades! At our recent Essen sprint, DSA went through the release qualification matrix (for wheezy, as there isn't one for jessie, yet) and defined a set of requirements that we consider necessary for us to support a port for the next stable release. We have limited these requirements to whether DSA can support a port well or not, and we wanted to establish these requirements early in the release cycle so that our concerns can be addressed. Our requirements for machines are not new; they are: * reliability - The stable release manager requires that we operate three machines for each port: two buildd machines in different locations and one porter machine. These machines must be reliable (see mips for counterexample). * out of band management - We require the ability to manage the machines independently of their primary network interface: serial console or better, remotely-controllable power. * supportability - We require that the machines be commercialy available (within financial constraints) and that they be supportable through a warranty or post-warranty support or are otherwise easy to replace. * stability - We require that the machine's architecture have an actively-maintained stable kernel in the archive. * environment - We require that packages critical for DSA operations be available: puppet, samhain, syslog-ng, ferm/pf, etc. Historically, we have not been enforcing these requirements strictly and this has caused / continues to cause us significant operational challenges resulting in our inability to render the service levels that should reasonably be expected of us. Therefore, we believe it is important that all debian.org machines meet these requirements. Based on the list of requirements enumerated above, we currentlty are concerned about the following architectures from the perspective of using them as debian.org machines: * armel: no remote management (being worked on); no archive kernel for the machines we use. * armhf: no remote management (being worked on). * hurd: no puppet/ruby broken (for 3 months+); lack of firewall support. * mips: existing machines are either not reliable or too slow to keep up; we suspect that they may not be easily replaceable. * mipsel: the porter machine and some of the buildd machines have an implementation error for one opcode; missing kernel in the archive * sparc: no working nflog (mild concern); no stable kernels in stable (compiling clisp for instance crashes the kernel reliably on smetana). We need to run sparc with oldstable kernels to provide stable machines. That's not an option for long. * s390/x: no stable kernels; not sourceable within our budgets (currently relying on sponsors - this has not been a problem so far). We believe that it is the responsibility of the porter community to either source hardware or provide DSA with proposals regarding the hardware Debian should buy. We encourage the porter community to actively assist DSA with the resolution of the above noted concerns regarding various ports. Thanks, Martin Zobel-Helas Debian System Administration Team -- "It pays to be obvious, especially if you have a reputation for being subtle." Martin Zobel-Helas Debian System Administrator Debian & GNU/Linux Developer Debian Listmaster http://about.me/zobel Debian Webmaster GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B signature.asc Description: Digital signature
Re: sparc qualification for Wheezy
Hi, On Wed May 30, 2012 at 22:29:32 +0200, Bernd Zeimetz wrote: > Hi, > > > > On Wed May 16, 2012 at 13:19:48 +0100, Adam D. Barratt wrote: > >> Hi, > >> > >> With the sound of the ever approaching freeze ringing loudly in our ears, > >> we're (somewhat belatedly) looking at finalising the list of release > >> architectures for the Wheezy release. > >> > >> Comments on / additions and corrections to the content of > >> http://release.debian.org/wheezy/arch_qualify.html would be appreciated, > >> as would any other information you think is relevant to helping us > >> determine sparc's status for the release. > > > > with my DSA hat on: > > > > We no longer have an UltraSparc II porterbox, and we are considering > > decommissioning our single remaining UltraSparc II buildd machine. > > > > Maybe it would be a good idea to officially drop US II support from > > wheezy since we won't have hardware to test issues on. > > Might make sense, but on the other hand the USII machines were usually those > where issues did *not* show up. Especially USIII liked to be a problem child > as > the specs were never released by sun. It got better with USIV again... So some > state like 'not officially supported, but should just work' is probably the > best > for USII. if that means, DSA does not need to operate those machines for the project any more, i am fine with that. Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530203434.gh29...@ftbfs.de
Re: sparc qualification for Wheezy
Hi, On Wed May 16, 2012 at 13:19:48 +0100, Adam D. Barratt wrote: > Hi, > > With the sound of the ever approaching freeze ringing loudly in our ears, > we're (somewhat belatedly) looking at finalising the list of release > architectures for the Wheezy release. > > Comments on / additions and corrections to the content of > http://release.debian.org/wheezy/arch_qualify.html would be appreciated, > as would any other information you think is relevant to helping us > determine sparc's status for the release. with my DSA hat on: We no longer have an UltraSparc II porterbox, and we are considering decommissioning our single remaining UltraSparc II buildd machine. Maybe it would be a good idea to officially drop US II support from wheezy since we won't have hardware to test issues on. Cheers, Martin -- Martin Zobel-Helas | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster GPG key http://go.debian.net/B11B627B | GPG Fingerprint: 6B18 5642 8E41 EC89 3D5D BDBB 53B1 AC6D B11B 627B -- To UNSUBSCRIBE, email to debian-sparc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120530201601.gg29...@ftbfs.de
Re: free(): invalid nextd size?
Hi, On Mon Sep 22, 2008 at 02:41:06 -0500, Steven Robbins wrote: > Hi, > > The Sparc Buildd failed to build ITK [1], aparently because the build > takes too long (see below). Or does the first line indicate something more > nefarious? > > Would the buildd owner please re-try ITK? > > Thanks, > -Steve > > Excerpt from [1]: > > *** glibc detected *** /usr/lib/gcc/sparc-linux-gnu/4.3.1/cc1plus: free(): > invalid next size (fast): 0x0098d7a0 *** > make[3]: *** > [Wrapping/CSwig/Algorithms/CMakeFiles/_ITKAlgorithmsPython.dir/wrap_itkHistogramMatchingImageFilterPython.o] > Terminated > make[2]: *** > [Wrapping/CSwig/Algorithms/CMakeFiles/_ITKAlgorithmsPython.dir/all] Terminated > make[1]: *** [all] Terminated > make: *** [debian/stamp-makefile-build] Terminated > Build killed with signal 15 after 150 minutes of inactivity > > > [1] > http://buildd.debian.org/fetch.cgi?&pkg=insighttoolkit&ver=3.8.0-1&arch=sparc&stamp=1220273077&file=log it could be a problem with the processort (being Ultra III). I will requeue on spontini, which is a Ultra II Greetings Martin -- Martin Zobel-Helas <[EMAIL PROTECTED]> | Debian System Administrator Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#477741: libauthen-dechpwd-perl_2.002-3(sparc/unstable): FTBFS, test failed
Hi, On Thu Apr 24, 2008 at 17:27:39 -0700, Ivan Kohler wrote: > severity 477741 important > tags 477741 help > thanks > > FTBFS appears to be specific to sparc architecture. > > I tried to log onto sperger.debian.org and at least look further into > the problem, but neither debhelper nor libmodule-build-perl are > installed. I'll email debian-admin@ and ask. [sid] sperger:~# apt-get build-dep libauthen-dechpwd-perl Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. -- Martin Zobel-Helas <[EMAIL PROTECTED]> | Debian Release Team Member Debian & GNU/Linux Developer | Debian Listmaster Public key http://zobel.ftbfs.de/5d64f870.asc - KeyID: 5D64 F870 GPG Fingerprint: 5DB3 1301 375A A50F 07E7 302F 493E FB8E 5D64 F870 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC and status report: Kernel upgrades for woody->sarge upgrades
Hi Matthew, On Thursday, 24 Mar 2005, you wrote: > On Thu, Mar 24, 2005 at 02:31:55PM +0100, Frank Lichtenheld wrote: > > As many of you may know on some machines users will need to install > > a current kernel before they will be able to upgrade woody to sarge > > (or better: glibc of woody to glibc of sarge). I've tried to use the > > available information to provide the needed files for these kernel > > upgrades. > > To my knowledge the affected machines/architecures are currently > > hppa64, sparc sun4m (only some of them) and 80386. > > It's all hppa machines, not just hppa64. IIRC we did some upgrade tests on hppa(32) at the BSP in Frankfurt in November last year and had no problems with that, but i might be wrong. Frank, could you please confirm this, as i recall you and Uli did these tests Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi Patrick, On Monday, 14 Mar 2005, you wrote: > I'll make a standard pdf letter folks can print and sign and send if > they'd like. > > They cannot kill the sparc line off, Debian is my favorite distro for > Sparc, we've got to do something about this! that won't work what we need here is some guys who a willing to do active kernel work on debian sparc. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits (Nybbles?) from the Vancouver release team meeting
Hi List, On Sunday, 13 Mar 2005, Steve Langasek wrote: [...] > > Therefore, we're planning on not releasing most of the minor architectures > starting with etch. They will be released with sarge, with all that > implies (including security support until sarge is archived), but they > would no longer be included in testing. [...] > We project that applying these rules for etch will reduce the set of > candidate architectures from 11 to approximately 4 (i386, powerpc, ia64 > and amd64 -- which will be added after sarge's release when mirror space no sparc here. After speaking to Andreas Barth, asking, why sparc might become SCC, he pointed my to the last release update where it says: | It's for this reason that all architectures are | required to be synced to the same kernel version for sarge, but even so, | more per-architecture kernel help is needed, particularly for the sparc | and the arm port. So we seem to have a lack of sparc kernel hackers/developers. I myself are using Debian on sparc very much, but do not have the knowledge with sparc kernels to help here. The only thing i could do here is testing, testing, testing... > - 5 developers who will use or work on the port must send in > signed requests for its addition > > - the port must demonstrate that they have at least 50 users That should be possible somehow. Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
