Re: Results of the porter roll call (Was: Roll call for porters of architectures in sid and testing)
Hi Niels, I don't know upto what point you are familiar with my history and its link to the powerpc port, but it pains me to see that the powerpc port is left with so few porters, and that it may mean the port being dropped. I also have not really followed the mailing lists since a long time, and don't know who is actually managing the powerpc port, but giving the (1) and 0.5 remark, i guess there is not a full porter. So given that, and provided debian may not see a problem again in me becoming active, i may be interested in becoming active again as powerpc maintainer. Not sure what category you can include me in though, and what the formalities would be should i become active (and welcome) in debian again. Also, i am not really sure of the amount of time i will be able to devote to debian, and i will have to take my powerpc hardware out of the storage area i put it in, but i guess it should be enough to do powerpc porting work, provided other folk help me out. That said, i am also interested in the powerpcspe port, as i am (slowly) working on a open-hardware Freescale P1010 based board. Anyway, please let me know if there is anything i can do. Friendly, Sven Luther On Wed, Oct 02, 2013 at 09:45:35AM +0200, Niels Thykier wrote: Hi, The final results are in: Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 hurd-i386 || 5 || 0 || 3 ||8 ia64 || *0* || 0 || 3 ||3 kfreebsd-amd64 || 4 || 0 || 2 ||6 kfreebsd-i386 || 4 || 0 || 2 ||6 mips || 1 || 0 || 1 ||2 mipsel || 1 || 0 || 1 ||2 powerpc[1] || (1) || 0 || 2 || 2.5? s390x || *0* || 0 || 0 || *0* sparc[2] || 1 || 0 || 0 ||1 [1] The (1) and .5 is from a I am not primarily a porter [...]-remark, so I wasn't sure how to count it. [2] By the looks of it, if sparc was replaced by sparc64, we could be looking at 3 in the Other-column rather than 0. NMs/DMs include DMs and people currently in NM process. The Other column may include people who said they would like to become porters (but would need to be introduced to the job) and thus may imply some active recruiting from the current porters. This is at least true for hurd-i386. The current policy says that we require 5 developers (i.e. DDs) for release architectures[AP], so based on that only amd64, i386 and hurd-i386 would pass this requirement. It is quite possible we need to revise that requirement, but most of the architectures would (still) do well to attract a few more (DD) porters. I have attached a file with my notes of who are behind those numbers. If your name is missing or you believe I have miscounted something[CD] for an architecture listed in the table above, please reply to this email *promptly* (CC'ing me explicitly is fine) with your concerns or corrections. At this time, I have *not* updated the arch qualification table yet. I will do that in a couple of days. We will also follow up on this in the next bits from the release team. ~Niels [AP] http://release.debian.org/jessie/arch_policy.html [CD] I may (or may not) have been caffeine-deprived when I did the counting. You are free to make assumptions about whether that has affected my ability to do addic^Htion or parsing your email(s) properly. Summary table: Arch || DDs || NMs/DMs || Other || Total ---++-++-++---++-- armel || 3 || 0 || 1 ||4 armhf || 3 || 1 || 2 ||6 hurd-i386 || 5 || 0 || 3 ||8 ia64 || *0* || 0 || 3 ||3 kfreebsd-amd64 || 4 || 0 || 2 ||6 kfreebsd-i386 || 4 || 0 || 2 ||6 mips || 1 || 0 || 1 ||2 mipsel || 1 || 0 || 1 ||2 powerpc[1] || (1) || 0 || 2 || 2.5? s390x || *0* || 0 || 0 || *0* sparc || 1 || 0 || 0 ||1 [1] Roger Leigh: I am not primarily a porter [...]. armel: Wookey (DD), Gatis Visnevskis (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD) armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD), Justus Winter (!DD), Lennart Sorensen (!DD), Nobuhiro Iwamatsu (DD), Steve McInture (DD) hurd-i386: Samuel Thibault (DD), Barry deFreese (DD), Thomas Schwinge (!DD), Pino Toscano (DD), Svante Signell (!DD), Michael Banck (DD), Guillem Jover (DD), Zhang Cong (!DD) kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD), Steven Chamberlain (!DD), Guillem Jover (DD) kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD
Re: Dropping sparc32 for Lenny (was: Scheduling linux-2.6 2.6.21-[23])
On Fri, May 18, 2007 at 02:39:41PM +0200, Frans Pop wrote: On Friday 18 May 2007 14:05, Bastian Blank wrote: I have to acknowledge the message from Dave[1]. Until there is a new kernel upstream it may be possible to compile it but it is impossible to fix real problems. Yes, I completely agree with that. However, when you casually propose to _deprecate_ (instead of temporarily disable) sparc32 as part of a kernel upload proposal, then I feel the discussion needs to be moved to a wider audience. Frans, Bastian did write : For now I only want to disable it. in the message you quote. This seems in complete opposition to what you claim he did say. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Builds disturbed by the usage of a 64bit kernel.
On Fri, May 18, 2007 at 12:13:34PM +0900, Charles Plessy wrote: Dear all, Starting from the observation that a pre-release debian pacakge of root-system and the current xaralx (non-free) pacakge fail to build from source on G5 powerpc machines but not on G4, I started to get worried that that kind of failures would be more widespread. The core of the problem is that the configure scripts sometimes mistake the build system type to be powerpc64-unknown-linux-gnu instead of powerpc-unknown-linux-gnu. I am wondering similar things happen on sparc running a 32-bit userland with a 64-bits kernel, hence the crosspost. To investigate a bit more, I am rebuilding the maching with a cowbuildd, and in this email, I would like to give preliminary results before the week-end. Interesting, notice that Andreas Jochens has gotten a serie of patches applied to some packages for his pure-64 effort. I wonder if this effort helps in this case, or causes problems. Do you know what exactly is causing this problem ? Or could you list the 140 packages which you already detected to be problematic ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] mass kernel udeb update and preparations for RC1
On Sun, Sep 17, 2006 at 02:28:06PM +0200, Frans Pop wrote: * powerpc: oldworld boot problems with recent kernels Both will be fixed in 2.6.18, and are already in the 2.6.18-rc7 snapshots since today. We don't have 2.6.18 based d-i to confirm this, but i will do a custom build over the week to confirm this. I don't particularly feel like backporting those fixes to 2.6.17, especially as the etch kernel target is 2.6.18, but others may volunteer to do it, or i may do it if i find some time. Friendlly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I Etch Beta2 - Status update (4)
On Tue, Mar 07, 2006 at 01:52:49PM +0100, Frans Pop wrote: I am very happy to announce that the debian-installer images targeted for Beta2 are now in testing (except AMD64) and that daily (etch_d-i) netinst and buisinesscard CD images using them are now available from [1]. These images use the 2.6.15-7 kernel. Can you add to the errata page (or tell me where to add it), the following three issues : - 2.6.15-7 has on powerpc a clock drift issue which is fixed in 2.6.15-8. - sbp2 is broken in 2.6.15-7, but fixed in 2.6.15-8, on powerpc, thus not allowing an install to a firewire disk, or reading back a firewire disk - the tg3 module is not included in the module .udebs, and as thus a network install on machine with those broadcom ethernet controllers (like the Apple Xserve G5) is not possible. loading the tg3.ko module by hand is a known workaround. This should be in addition to the not yet fixed prep issue, which makes d-i fail on all ibm chrp boxes due to yaboot having a problem with partman-prep being broken. On 32bit arches, a workaround is to use nobootloader, and the mkvmlinuz way instead of yaird (configuring mkvmlinuz to produce the compressed vmlinuz-* kernel, and dding it to a prep partition). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#344615: missinglib: ftbfs [sparc] *** [test] Bus error
On Thu, Jan 05, 2006 at 09:57:23AM +0100, Florian Weimer wrote: * Sven Luther: i guess sparc-*-* should be changed by sparc*-*-*, and we can then close this bug. But why does the host triplet not match sparc*-*-*? Because it was buggy ? I believe the developpers had no access to a box presenting itself as sparc64-* or something such. This is fixed in the upstream 3.09.1 release anyway, case closed :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#344615: missinglib: ftbfs [sparc] *** [test] Bus error
On Tue, Jan 03, 2006 at 03:09:07PM +0100, Julien Cristau wrote: forwarded 344615 http://caml.inria.fr/mantis/view.php?id=3944 kthxbye On Mon, Jan 2, 2006 at 12:26:14 +, Jurij Smakov wrote: ldd is a double-word load, so the first argument (the memory location) must be double-word aligned. I bet it's not (what's the value of %i1?) and that's what causes the bus error. %i1 contains 0xa3f74, which is indeed not double-word aligned. The ocaml float allocation function doesn't take care of alignment, so we've reported this problem upstream. As said on irc : configure has # Determine alignment constraints case $host in sparc-*-*|hppa*-*-*) # On Sparc V9 with certain versions of gcc, determination of double # alignment is not reliable (PR#1521), hence force it. # Same goes for hppa. # But there's a knack (PR#2572): # if we're in 64-bit mode (sizeof(long) == 8), # we must not doubleword-align floats... if test $2 = 8; then echo Doubles can be word-aligned. echo #undef ARCH_ALIGN_DOUBLE m.h else echo Doubles must be doubleword-aligned. echo #define ARCH_ALIGN_DOUBLE m.h fi;; *) sh ./runtest dblalign.c case $? in 0) echo Doubles can be word-aligned. echo #undef ARCH_ALIGN_DOUBLE m.h;; 1) echo Doubles must be doubleword-aligned. echo #define ARCH_ALIGN_DOUBLE m.h;; *) echo Something went wrong during alignment determination for doubles. echo I'm going to assume this architecture has alignment constraints over doubles. echo That's a safe bet: Objective Caml will work even if echo this architecture has actually no alignment constraints. echo #define ARCH_ALIGN_DOUBLE m.h;; esac;; esac i guess sparc-*-* should be changed by sparc*-*-*, and we can then close this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
searching access to a sparc sid box ...
Hello, ... I wanted to build the ocaml package for sparc, since it is the only thing stopping ocaml 3.06 (and a load of other packages depending on it) from entering testing. The package was built by the sparc buildd on september 24, but not uploaded, so i guess (from a response from debian-ia64, which had the same problem) that the buildd maintainer did not have time to sign it. So i said, ok, i will upload them myself, i did this for ia64 on merullo, but there was no sparc box running sid available to developpers (well, the pages i found listing debian machines from the developper corner lists 3 sparc boxes, but 2 being broken and the lats one having only woody auric). Is there a sid box available, or alternatively could a sid chroot be made available somewhere, so that people can look at their packages on sparc ? Alternatively, if someone could tell me who the buildd maintainer is and if he will be around shortly to sign the packages, this will make me happy also. Friendly, Sven Luther
Re: searching access to a sparc sid box ...
On Fri, Oct 04, 2002 at 08:03:20AM -0400, Ben Collins wrote: On Fri, Oct 04, 2002 at 08:35:10AM +0200, Sven LUTHER wrote: Hello, ... I wanted to build the ocaml package for sparc, since it is the only thing stopping ocaml 3.06 (and a load of other packages depending on it) from entering testing. The package was built by the sparc buildd on september 24, but not uploaded, so i guess (from a response from debian-ia64, which had the same problem) that the buildd maintainer did not have time to sign it. So i said, ok, i will upload them myself, i did this for ia64 on merullo, but there was no sparc box running sid available to developpers (well, the pages i found listing debian machines from the developper corner lists 3 sparc boxes, but 2 being broken and the lats one having only woody auric). Login to vore.debian.org and read the motd. Ok, thanks, i will. (But then vore was listed as having a dead powersupply on http://db.debian.org/machines.cgi yesterday). Friendly, Sven Luther
Re: searching access to a sparc sid box ...
On Fri, Oct 04, 2002 at 08:12:43AM -0400, Ben Collins wrote: On Fri, Oct 04, 2002 at 02:19:11PM +0200, Sven Luther wrote: On Fri, Oct 04, 2002 at 08:03:20AM -0400, Ben Collins wrote: On Fri, Oct 04, 2002 at 08:35:10AM +0200, Sven LUTHER wrote: Hello, ... I wanted to build the ocaml package for sparc, since it is the only thing stopping ocaml 3.06 (and a load of other packages depending on it) from entering testing. The package was built by the sparc buildd on september 24, but not uploaded, so i guess (from a response from debian-ia64, which had the same problem) that the buildd maintainer did not have time to sign it. So i said, ok, i will upload them myself, i did this for ia64 on merullo, but there was no sparc box running sid available to developpers (well, the pages i found listing debian machines from the developper corner lists 3 sparc boxes, but 2 being broken and the lats one having only woody auric). Login to vore.debian.org and read the motd. Ok, thanks, i will. (But then vore was listed as having a dead powersupply on http://db.debian.org/machines.cgi yesterday). Oh, didn't know that. It's alive as of yesterday. Yes, i did see it in the database today. Thanks. BTW, are you the buildd maintainer ? if yes, you could sign the ocaml sparc built from september 24, so it get uploaded without me having to rebuild the packages ? Friendly, Sven Luther
Re: searching access to a sparc sid box ...
On Fri, Oct 04, 2002 at 08:40:42AM -0400, Ben Collins wrote: Yes, i did see it in the database today. Thanks. BTW, are you the buildd maintainer ? if yes, you could sign the ocaml sparc built from september 24, so it get uploaded without me having to rebuild the packages ? Nope, that would be James ([EMAIL PROTECTED]) or Ryan ([EMAIL PROTECTED]). Ok, no problem, i am building the package by hand right now, and will upload it. Friendly, Sven Luther
Re: searching access to a sparc sid box ...
On Fri, Oct 04, 2002 at 02:18:58PM +0100, James Troup wrote: Sven Luther [EMAIL PROTECTED] writes: On Fri, Oct 04, 2002 at 08:40:42AM -0400, Ben Collins wrote: Yes, i did see it in the database today. Thanks. BTW, are you the buildd maintainer ? if yes, you could sign the ocaml sparc built from september 24, so it get uploaded without me having to rebuild the packages ? Nope, that would be James ([EMAIL PROTECTED]) or Ryan ([EMAIL PROTECTED]). Ok, no problem, i am building the package by hand right now, and will upload it. Err, please don't. All your doing is fighting the buildd for vore's CPU and IO. The machine's only been back 24 hours or so and is still catching up on the backlog, please just be patient and give it a chance. Ok, no problem. i just stopped the build. I was not aware that vore hosted the sparc buildd, but it makes sense, i should have thought of it. Sorry about the inconvenience, i just wanted to create too much problems, i suppose i did it wrong. Friendly, Sven Luther
Re: [PATCH for 0pre1v3] r128 and radeon without vgaHW problem fix
On Sun, Sep 01, 2002 at 04:07:30AM +0900, ISHIKAWA Mutsumi wrote: In [EMAIL PROTECTED] Michel Dänzer [EMAIL PROTECTED] wrote: On Sam, 2002-08-31 at 19:24, ISHIKAWA Mutsumi wrote: I put a patch to build fix on SPARC and new MANIFEST.sparc. http://people.debian.org/~ishikawa/XFree86/4.2.0-0pre1v3/sparc/101_sparc_ati_without_vgahw.diff This is a bad patch IMHO. I have a question: Are RADEON and Rage128 supports need on SPARC currently? Some some SPARC workstation/server uses RADEON and/or Rage128? I know some SPARC workstations (e.g Ultra5) use mach64 graphic chip. So, we need mac64 support. We should not drop ati mac64 drivers. But I don't know RADEON or Rage128 graphic borad for SPARC. If RADEON/Rage128 board for SPARC does exist, we need more hack to support these (but I don't have the board and enough time to do this...). Well, i guess the Ultra5 have pci slots, so you could imagine putting a pci radeon or rage128 board in it, is it not ? I guess even the just released Radeon 9000 PCI boards could be used, but then i don't own a Ultra5 box, and don't know if many people will do this. Friendly, Sven Luther
Re: g77 issues
On Thu, Apr 19, 2001 at 10:50:34AM +0100, Nick Bailey wrote: Ionut Georgescu wrote: PS command line: g77 -g -pg -o programm *.f PPS gcc -v: Reading specs from /usr/lib/gcc-lib/alpha-linux/2.95.3/specs gcc version 2.95.3 20010315 (Debian release) I'm interested... I don't know enough FORTRAN to test this out, but I have been seeing Scilab (which has a lot of FORTRAN inside) doing some strange things recently. If you were to send me a short program to compile and run on this debian PowerPC (Mac G4) I can let you see the results. PPS I made another test. In the big programm I have defined a function fermi2: ... and computed the following expression: aux22= 1.0d0-fermi2(enpct) The output was: on x86: tmp_fermi2( -2.20214243)= 1. aux22= 1.11022302E-16 !! should have been 0. !! This is an engineering department: 1.11022302E-16 == 0 ;-) Can you print out the first expression more accuately? I bet it isn't really 1 (actually 1.000111022302 ;-) Maybe there's no bug: it's just truncation error? Maybe the maths unit on the alpha is better than the one on the ia32 on this test (no suprise there!) Also, note that alpha is a 64bit plateform, and that as thus it could be that it handles some things better than ia32 or ppc. Not sure if this influences floating point values, i guess not. Friendly, Sven Luther
Re: call for ports to begin using 2.4.0 headers for glibc
On Tue, Jan 16, 2001 at 03:26:03PM +0100, Christian T. Steigies wrote: On Mon, Jan 15, 2001 at 11:05:39PM -0500, Ben Collins wrote: Well, the big deal is that to enable LFS on glibc, it must be compiled against 2.4.0 headers. This does not break when running on 2.2.x You mean we have to make binNMUs of glibc? Or will you make a new upload which explicitly requests kernel-headers 2.4.0? arch I build myself). I would like all other archs to follow suit (whoever builds glibc for that particular arch), even if it means using local 2.4.0 source (and not something in the archive) so long as you plan to fill this gap once a 2.4.0/2.4.1 source is available in sid. Right now I only see this in the pools: kernel-image-2.4.0-test11-i386 There isn't an official 2.4.0 source yet in the archive? Besides, we could probably build kernel-images for 2.4 on m68k, but they do not work so well yet (at least on my box the IDE driver is not yet working, rendering the kernel useless for me). Do you want those in the archive? But who cares, I even uploaded xfree4.0 now to make the archive happy... with ppc, i386 and sparc. Any other ports that want me to keep them in sync, feel free to donate h/w. How about using debian funds to pay that hardware? I only have one m68k machine, I am not sure if I want to donate that one to you, I could not work for m68k anymore then. Or maybe get it donated by somebody else, and not necessarily by a developer, after all I am donating quite a lot already. IMHO. I have a spare A1200 with 68030 processor lying around, it has no harddisk though. Would that count toward donating hardware ? Friendly, Svne Luther
