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: Sa
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: Status of d-i kernel transition for 2.6.14
On Wed, Dec 07, 2005 at 09:48:27PM +0100, Frans Pop wrote: > powerpc 2.6.14-2/2.4.27 2.6.12-1/2.4.27 2.6/2.4.27 Fixed, now the config has 2.6.14-2, i had added it in the gtkdi branch, but forgot to commit the sid-di one. 2.4.27 should be used only for apus and nubus, but nubus has no d-i support yet, and apus has 2.6.14-2 kernels now, and will thus be dropping the 2.4.27 apus kernels. Will try to migrate apus to 2.6.14 next week, but there is extensive .config and .udeb modules needed, so any help there is welcome, as i am really too busy to do debian work until january. There are no 2.4.27 generic powerpc kernels in etch/sid anymore, or there should not be. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch/s390 TODO
On Thu, Nov 24, 2005 at 12:54:19PM +0100, Bastian Blank wrote: > On Sat, Nov 19, 2005 at 12:12:51PM +0100, Sven Luther wrote: > > I disabled the dasd patch in parted 1.6.23, because it didn't apply cleanly, > > and there where some changes which made it non-trivial for me to fix it, i > > asked you on irc to look at it, and think i also mailed here, but nothing > > happened since then. Otavio has now taken a more active role than me in > > parted > > maintenance, as has K.G., so it would be best to contact them about this > > maybe. > > I fixed it at least one time and it worked after that. Yes, but then the code it is based on has changed again, and it needs refixing, which is why it is not included. I asked you back then. Now if you have fixed it again since 1.6.23, then it is another matter, can you please try enabling the patch and confirm it builds and works indeed ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: etch/s390 TODO
On Fri, Nov 18, 2005 at 08:52:09PM +0100, Bastian Blank wrote: > s390 support in partman > === > There is some type of s390/dasd support available for parted, it just > completely disables the check for the sector size, as parted hardcodes > this in too many places and dasds don't follow this. Maybe this can be > fixed in a proper way. > > partman needs to be fixed to use a correct block size for the devices > (1024 byte blocks on a 4096 bytes sectors device just don't work). I disabled the dasd patch in parted 1.6.23, because it didn't apply cleanly, and there where some changes which made it non-trivial for me to fix it, i asked you on irc to look at it, and think i also mailed here, but nothing happened since then. Otavio has now taken a more active role than me in parted maintenance, as has K.G., so it would be best to contact them about this maybe. One issue with the DASD patch, is that it was from some guy who now seems MIA or something, as i wrote him too about this, and it is a rather consequent patch, and thus needs official FSF copyright assignement to be merged upstream, which is really what we want to do. Someone with DASD knowledge and hardware is probably best placed to look at it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lablgl failed to build on s390 (for strange reasons).
Hello, ... I have been following up on a failed build log on s390 for lablgl, and something seems strange here. It does say : http://buildd.debian.org/fetch.php?&pkg=lablgl&ver=0.98-4&arch=s390&stamp=1040601659&file=log&as=raw ** Using build dependencies supplied by package: Build-Depends: debhelper (>> 3.0.0), ocaml-3.06-1, tcl8.3, tcl8.3-dev, tk8.3, tk8.3-dev, libncurses5-dev, xlibs, debhelper, xlibmesa-dev|bgl-dev ** Filtered missing central deps that are dependencies of or provide build-deps: xlibs-dev (>> 4.1.0) Checking for already installed source dependencies... debhelper: already installed (in sufficient version 4.1.28 >> 3.0.0) ocaml-3.06-1: already installed but later on : make[1]: Entering directory `/build/buildd/lablgl-0.98' ocamlc -pp camlp4o var2def.ml -o var2def make[1]: ocamlc: Command not found make[1]: *** [var2def] Error 127 make[1]: Leaving directory `/build/buildd/lablgl-0.98' make: *** [build-stamp] Error 2 So apparently ocaml-3.06-1 is not installed. and naturally the build fails. i logged in on raptor to see what is going on, but i am not sure if this is the buildd box, and there was no ocaml installed on the unstable chroot there. Could someone please help me investigate this and see what did happen ? Ocaml 3.06-14 was sucessfully built on s390 : lftp ftp.debian.org:/debian/pool/main/o/ocaml> ls *3.06*s390* -rw-rw-r--1 1176 1176 185044 Dec 17 07:17 ocaml-base_3.06-14_s390.deb -rw-rw-r--1 1176 1176 4496246 Dec 17 07:17 ocaml_3.06-14_s390.deb Apart from the evident need to have lablgl built, i am really curious about what did happen, as ocaml packaging does rely on some creative virtual packages dependencies to keep all working fine, and it may be the cause of this problem (altough it should not). Thanks for your help, and merry christmas everyone. 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
