wanna peruse site (buildd.armlinux.org/~buildd/)

Since the perl upgrade on inkvine, which removed /usr/local/lib/site_perl/ from @INC, this hasn't been working, and I expect the mail has been bouncing. It's now fixed, so the site should be being updated again. c.

quinn-diff

I'm looking into setting up a quinn-diff somewhere on armlinux.org, as that seems to be common practice. If this isn't going to be helpful, stop me. c.

Re: qpopper

On Tue, 6 Feb 2001, Chris Rutter wrote: > I'm doing this now; I've filed a bug. It should be in Incoming now. c.

Re: qpopper

On 6 Feb 2001, James Troup wrote: > > I'm doing this now; I've filed a bug. > > Err, what? Hello? buildd chroot support anyone? Unpacking sendmail (from .../sendmail_8.9.3-21_arm.deb) ... Setting up libpam0g-dev (0.72-13) ... Setting up sendmail (8.9.3-21) ... Stopping mail transport agent: s

Re: qpopper

On Sat, 3 Feb 2001, Philip Blundell wrote: > This isn't amenable to auto-building - it gets tangled up trying to replace > exim with sendmail on the buildd machine. Would somebody please build it > manually? I'm doing this now; I've filed a bug. c.

Re: BUG: gcc broken

On Mon, 5 Feb 2001, Nicholas Clark wrote: > Processor : Intel StrongARM-110 rev 2 (v4l) > BogoMIPS: 1.90 > Hardware: Acorn-RiscPC > Revision: > Serial : For everyone's interest, I think a revision T looks like this: Processor :

Re: ARMLinux on ARM710 / Kinetic

On Sun, 4 Feb 2001, Richard Atterer wrote: > Does ARMLinux run on pre-StrongARM processors now (in my case, an > ARM710 inside my RiscPC)? IIRC, there was some discussion about this a > few months ago and somebody said "there are a few problems now, but it > should work soon". So, does it? There

failing armagetron builds

Builds of armagetron are failing in a strange way, unreported by other architectures (who are possibly using a newer version of sbuild, or just not complaining): [...] dh_installmanpages -parmagetron-server armagetron-server.6 dh_installchangelogs doc/changelog.html Your terminal lacks the

more performance bottleneck stuff

Okay, I'm mystified (at least at this time in the morning). Here's a vmstat trace, running on inkvine: procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 0 0 0 17836 3280 5212 164

peformance bottleneck in wanna-peruse

Though this top report for while the page was being generated seems to suggest that CPU is not a bottleneck: 30288 daemon20 19 256 220 156 R N 83.8 0.3 944:28 distributed-net 8228 apache 0 0 3484 3476 2352 D 7.1 5.4 0:10 apache 8230 apache 3 0 3488 3480 2360 R

wanna-build progress report

The list-all-packages page is now working again (PHP seems to have developed an aversion to things it used to accept over the past month), though sadly it only crawls down at about three times the speed of medusa -- around 2kB/s or so. This is still pretty painful. Possibly an opportunity to inst

Re: wanna-peruse moving and upgrades

I'm off to bed for tonight, but here's a progress report. On Thu, 1 Feb 2001, Chris Rutter wrote: > and thus I've moved that particular component of the ARM buildd stuff > over to inkvine [...] This is now essentially done; for those with access to armlinux.org facilities,

weirdo errors

Anyone got any idea why these errors might have happened? (medusa) /home/buildd/www cp -dR * .htaccess .wanna-peruserc /mnt/inkvine/home/buildd/www cp: overwrite `/mnt/inkvine/home/buildd/www/build.php'? y cp: overwrite `/mnt/inkvine/home/buildd/www/comment.php'? y y y cp: cannot create symbolic

wanna-peruse moving and upgrades

medusa is grossly underpowered to run a bunch of inefficient scripts such as those that comprise the wanna-peruse system (which powers the buildd log viewer, available at ), and thus I've moved that particular component of the ARM buildd stuff over to inkvine (a

Re: glibc 2.2.1

Bdale built it already. Build cancelled. c.

Re: glibc 2.2.1

On Wed, 31 Jan 2001, Philip Blundell wrote: > Dammit, this keeps happening. It needs a woody machine to build, but > medusa should be up to it. I'll start a build shortly, unless someone > else has done so. I've just started one. Assuming there are no mitigating circumstances as to patches or

Re: New NetWinder install process?

On Fri, 19 Jan 2001, Marko Dinic wrote: > .../disks-arm/current/doc/ , but it all seems to be standardized for > Debian and not specific to ARM as the previous doc's were. It just seems > that READ_OR_PARISH.NetWinder (Thanks Jim Studt!) was so much simpler > before. Okay; I think this counts as

Re: BUG??

On Tue, 9 Jan 2001, Chester wrote: > BTW,i can't connect to ftp.armlinux.org,it always time-out. You'll probably need to switch on `passive' mode in your FTP client; alternatively, I think you access the archive at http://www.invkine.fluff.org/archives/armlinux/ c.

Re: XFree86 4.0.2 status

On Mon, 8 Jan 2001, Philip Blundell wrote: > Not much point, actually -- I think I accidentally blew away my edits to > elfloader.c, and Tor has already built the equivalent package anyhow. Okay, cool. It turns out Branden asked Bdale Garbee (gzip maintainer and sometime ARM hacker) to do some

Re: XFree86 4.0.2 status

On Fri, 5 Jan 2001, Philip Blundell wrote: > I've set a build of 4.0.2-1 going on medusa, with a few hacks in elfloader.c > to select Rel rather than Rela relocs for ARM. It's in ~philb/x if you want > to take a look. Probably won't finish until tomorrow sometime. This bombed out in elfloader

Re: XFree86 4.0.2 status

On Fri, 5 Jan 2001, Branden Robinson wrote: > AFAIK the only attempted build has been on ARM, which was complicated by > glibc problems (which may now be resolved). This is nth-hand information, but I think one of the most taxing problems may be the implementation of support for the ARM flavour o

Re: status of arm port

On Sun, 19 Nov 2000, Othmar Pasteka wrote: > i just had to discover that somehow the arm port isn't > maintained. i got the impression that someone set up an buildd > and etc. pp. so, what is the actual status? i am a bit confused > right now. The ARM port is very much maintained in spirit; I cur

2.2r1

If you look at the change log for Debian 2.2r1, you'll notice a great number of new / finally-built / updated ARM packages -- I'd like, before I forget, to express some thanks to Phil for (almost exlusively, I think) this work here -- it certainly wasn't me! c.

Re: ARM build machines

On Fri, 10 Nov 2000, Philip Blundell wrote: > Chris did indeed set up wanna-build and buildd on medusa, though ...Phil has much more of a clue about what's going on and has done a lot more work in the past few months on this issue. c.

Re: ARM build machines

On Fri, 10 Nov 2000, Wookey wrote: > Assuming we are not talking at cross-purposes; I believe Chris only set up > one machine (medusa.armlinux.org) with buildd as he ran out of time and has > now sunk under college work until the end of term. He is aware that various > people offered machines. Ye

Re: mysterious headers

On Tue, 31 Oct 2000, Philip Blundell wrote: > Thanks. Seems the `glide2' version is the operative one, which seems to be > some kind of i386 only thing. Yeah; Glide is the `register-level' interface through which applications can talk directly to a 3DFX card -- probably tied up with some x86 sp

although

I hasten to point out it might not be the kernel sources involved, but a toolchain issue. c.

Re: signal 11s in latest woody

On Sat, 21 Oct 2000, Philip Blundell wrote: > If you can give a concrete example of something that fails, I'll look into it. I will; though a rough precis of what's to come would be something like xdm (oopses); update-menus + apt-get and a few other things die with segmentation faults. Although

dying binaries

Hm, add to that list e2fsck and apt-get. :-( c.

signal 11s in latest woody

I notice quite a lot of stuff seems to be receiving signal 11s (at least, on a RiscPC) in the latest woody stuff (like most of X, update-menus, and a few other utilities). Anyone have any idea why? If things are being auto-built using CVS binutils, this possibly could be why; perhaps it might be

Re: 2.2r1

On Fri, 13 Oct 2000, Anthony Towns wrote: > I believe quinn-diff is now correctly handling proposed-updates, so > if you could please get as much of it autobuild for your respective > architectures as possible, it'd be appreciated. I've signed and uploaded all extant .changes files for stable, bu

Re: buildd

On Fri, 29 Sep 2000, Alexander Schulz wrote: > From: Debian/ARM Buildd #1 <[EMAIL PROTECTED]> > Date: Wed, 27 Sep 2000 11:01:56 -0400 Ahh -- Jim Pick setup the build daemon on rameau months ago, but as far as I know it never uploaded anything -- I guess the wanna-build database must have been ina

archive updates

Just for your interest, the latest versions of the following packages have now been installed in the unstable archive: acct aegis afterstep aime amd angband appindex apt-move ascd asclock asmail asmixer asmodem autoclass autogen barcode bash bbpager bg5cc bg5ps boxes bsd-finger bsdgames-nonfree bs

util-linux from potato doesn't build

Um, does anyone have any idea how util-linux got into potato? fdisk doesn't build on ARM... If there was an NMU, the patch didn't make its way back to the maintainer. :-( c.

Processing of skk_10.59-7_arm.changes (fwd)

Hundreds (thousands?) of packages making their way to an archive near you. c. -- Forwarded message -- Date: Mon, 25 Sep 2000 08:06:35 +0100 (BST) From: Philip Hands <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Processing of skk_10.59-7_arm.changes skk_10.59-7_arm.changes up

Re: buildd

On Sat, 23 Sep 2000, Alexander Schulz wrote: > What should the subject look like? Searching for build didn't show anything > back to April. It depends which bit sent the mail. Some examples are: Subject: wanna-build statistics Sat Sep 23 00:29:49 BST 2000 Subject: wanna-build unstable state

Re: buildd

On Sat, 23 Sep 2000, Alexander Schulz wrote: > At least he told me so. If it was fixed very recently, perhaps it doesn't. He > can only see messages arriving, not that they doesn't arrive :-) If you could bounce me one of the messages I'll see what I can do. Doesn't the Return-Path give any clue

Re: buildd

On Sat, 23 Sep 2000, Alexander Schulz wrote: > Roman told me there is some arm buildd/wannabuild out there that sends > messages to the debian-m68k mailing list. It doesn't seem to be europa, and medusa's turned off at the moment. Is this still happening? c

Re: Again: libz1

On Sat, 23 Sep 2000, Marco Suzzi wrote: > Some packages seems to need libz1 but i can't find it. > I was't able to get info from Mailing List Archive so ... > Where can i find libz1 ? This package is provided by `zlib1g': (willow) ~ dpkg -s zlib1g [...] Provides: libz1 [...] whi

subarch rant

I can see you all love me going on about this. It looks like the example program may have been deemed a Good Thing, and thus its functionality is going to get subsumed into a wider utility. You can all feel proud of being inmates of the architecture where it started. c.

subarch honolulu

Okay, well if no one screams that's going into debianutils. A warning: changing that package in potato is going to be ... difficult, to say the least, more than once -- it's an Essential: package, and therefore everyone's boot disks will have to be rebuilt, and so on. We can get away with it once

arm's failures in testing

The arm contigent of ajt's `testing' distribution is pretty poor: http://auric.debian.org/~ajt/testing_probs.html Is anyone else paying much attention to this? c.

subarch debacle

After hours of tense negotiations with the Cabal it seems that I was in error about how subarchitectures will work. In the ensuing brouhaha, I concoted a mildly less shit scheme, I think though am not certain, for expressing hardware. In this revelatory new scheme, we'd have names like this: acor

subarch saga

I'm negotiating to add a `--print-model' or `--print-subarchitecture' option to dpkg, which I think is probably the right way to do it. c.

Re: fbdev problems

On Wed, 13 Sep 2000, Nicholas Clark wrote: > Is this the reason why you were finding that my patch didn't seem to work? > (sorry, I forgot to say that I wasn't running in "default") I'm totally guessing. This is based on a couple of off-hand thoughts having spent five minutes staring at the sour

fbdev problems

Skimming the source, it would seem another problem is where Xfbdev is told to use the `default' mode and doesn't attempt to reset the virtual height. What it really ought to do is take the mode parameters, unset text, and reset the mode, I suppose; design oversight? Why do no other architectures

Re: XFree86 correct from source?

On Mon, 28 Aug 2000, Nicholas Clark wrote: > fbdev does turn off text acceleration once it goes for the mode for real. > However, I found I needed to patch it to turn of text acceleration when > probing to make modes not get rejected. I'm not sure if it's the > right thing to do. Hm, have you act

Re: kernel-package forces target to `Image'

On Sat, 2 Sep 2000, Tor Slettnes wrote: > Sure.. > I am the cause of that /Image thing, and it had to do with an earlier > version of the NeTTrom not being able to read /vmlinux. I have not > tried this in later versions, and anyway think that your idea about a > switch is cleaner. > > So, if yo

kernel-package forces target to `Image'

I notice that the rules file for `kernel-package' forces the target to `Image' on ARM: ### ARM ifeq ($(strip $(architecture)),arm) GUESS_SUBARCH:='netwinder' ifeq (,$(findstring $(SUBARCH),netwinder)) SUBARCH:=$(GUESS_SUBARCH) endif kimage := Image loaderdep= loader=nettrom l

Re: Sub-architectures in update-modules

On Sat, 2 Sep 2000, Philip Blundell wrote: > I don't have any strong feelings either way. "Footbridge" is obviously more > generic and I guess it's the technically correct choice, but "netwinder" is > more likely to mean something to the majority of people installing Debian. I > imagine there

Re: Sub-architectures in update-modules

On Sat, 2 Sep 2000, Philip Blundell wrote: > I'm pretty sure "netwinder" is good for all three of these. Other than that, > sounds fine. Most of the other platforms aren't suitable for standard Debian > installs anyway, being weirdo embedded-type targets, so I reckon covering > just > the Fo

boot-floppies missing -fPIC?

Building boot-floppies with language choosing turned on, whinges appear about ARM_PC_R24 from iconv.so, which is compiled thus: (medusa) usr/src/boot-floppies/utilities/dbootstrap/langs make iconv.so gcc -shared -o iconv.so iconv.o -lpython1.5 Would I be correct in my ill-informed guess that

Re: Sub-architectures in update-modules

On Tue, 1 Aug 2000, Philip Blundell wrote: > Let's stick with just `acorn' for now and see what happens. I think > Archimedes/A680/A5000 can certainly share one set of modules. RiscPC > obviously needs different ones but confusion should be minimal - call them > `acorn32' if you like. Okay

Re: NetWinder an XFree

On Mon, 28 Aug 2000, Philip Blundell wrote: > 64MB isn't quite enough RAM to run things like GNOME locally though. Uh-oh. My x86 box runs HelixGNOME 1.2, Sawfish, Netscape, xemacs, half-a-dozen gnome-terminals, a few panel monitors and assorted applications, and it's not that bad -- it only has

Re: configure level change on arm to build PIC until glibc-2.2?

On Mon, 28 Aug 2000, Philip Blundell wrote: > Not a lot. If you want to use a shared object purely as a way of dynamically > loading code, and don't actually want to share it, it can be slightly more > efficient to build it non PIC. But the vast majority of cases of non-PIC > code > in share

Re: configure level change on arm to build PIC until glibc-2.2?

On Mon, 28 Aug 2000, Adam C Powell IV wrote: > > Poorer code generated for static executables; useless register loads. > > Results in a performance penalty, larger code size. > > This is why Debian policy requires shared objects to be built with -fPIC, > static > without (section 4.2). If somet

Re: XFree86 correct from source?

On Mon, 28 Aug 2000, Chris Gorman wrote: > It did last time I tried it about a month ago. Yeah, but (I should have qualified myself really) did it run happily and apparently correctly on (at least) Netwinders? c.

XFree86 correct from source?

I recently just built `xfree86-1' (3.3.6-10), and apart from its taking three days and 810MB of disk space, it apparently worked. Does XFree86 really auto-build successfully from package source these days? c.

Re: Bug in arm dynamic linker?

On Wed, 23 Aug 2000, Jim Studt wrote: > I ran into this as well, but too late to fix for potato. Not a problem. I negotiated that we can do what we like to the archive for 2.2r1 (which won't be in that long, mind) with the Release Manager. c.

[buildd@medusa.armlinux.org: wanna-build unstable state changes 2000 Aug 19 08:20:22]

Wayhey. It looks like we have one auto-builder. Now to get those .changes files signed. c. - On Sat, 19 Aug 2000 08:20:25 you wrote: State changes at 2000 Aug 19 08:20:22 for distribution unstable: --take(unstable): sed_3.02-6 changed from Needs-Build to Building by buildd --take(unstabl

ARM slave build daemons wanted

There's now a working wanna-build database setup on medusa.armlinux.org. I now need slave build daemons to build some packages. If you'd like to volunteer, check `wanna-build' out of cvs.debian.org and install the `buildd', preferably in a chroot environment, and send me the following information:

Intent to setup auto-builder

I intend to setup a central wanna-build database for ARM on medusa and at least two slave build daemons. If this is going to break something, please scream and shout now. c.

Sub-architectures in update-modules

The various varieties of ARM architecture hardware most certainly don't have a standard set of mappings from common module aliases `soundcore', etc. onto modules; for this reason, it seems we need a system like m68k, where we'd have /etc/modutils/arch/arm.{netwinder,acorn,...}. There's a bash func

ARM up-to-dateness w.r.t. test-cycle-3

This might be of interest: http://pandora.debian.org/~ajt/uptodateness.html c.

Re: Auto-builders

On Thu, 27 Jul 2000, Philip Blundell wrote: > Sadly, the two aren't related -- even binutils 2.10 has the segfault problem. > > I poked the mozilla build a bit last night and got one green cycle out of it, > but it's lapsed back into redness now. It's possible whatever Frank Smith fixed (`li

Re: xmms optimisation

On Fri, 28 Jul 2000, Jason Gunthorpe wrote: > Fabien told me that splay works at about 10% cpu on a StrongARM, and I > have some propritary routines from ARM LTD that use about 5%. > > The trick is to us only integer math, then ARM runs at a good clip. Yup, indeed. I presume xmms does indeed us

xmms optimisation

Has anyone worked on any optimised ARM routines for MP3 decoding in xmms? I notice it's not fast enough as it stands on a 200MHz StrongARM; this seems pretty bad to me. I think xmms is supposed to use parts of mpg123 as its decoding call, and I recall that someone did some optimised ARM patches fo

Re: where is SSH ?

On Fri, 28 Jul 2000, Jason Gunthorpe wrote: > Well, looks to me like someone de-installed it.. In fact, it looks to me > like one heck of alot of things have been deinstalled... > > Sadly my ssh for arm deb seems to have gone missing :< I've put the ones in use on medusa up for ftp, which seem t

Auto-builders

What auto-builders have we got going at the moment, and what type are they? Also, do they feed off frozen, woody, or both? :-) (He says, noticing binutils 2.10 hasn't made it into woody, and that the Mozilla builds are failing from a linker segfault.) c.