Custom Search
|
Date: December 31, 2006
From: "1月13-14日/上海" <ghb25@xxxxxxx>
|
主办单位： 易腾企业管理咨询有限公司 课程背景 |
Date: December 31, 2006
From: "Sofia Holmes" <vwastewater@xxxxxxxx>
|
Sign up and get $777.00 for free...
Download our casino software and become a winner.
It is your chance to win a lot of money!!!
We have 45+ casino games.
HUGE COMPS and $500,000 PROGRESSIVES are included!!
|
Date: December 30, 2006
From: "Walter" <adam@xxxxxxxxxxx>
 |
Date: December 29, 2006
From: "postmaster" <iys@xxxxxxxxxxxxxxxxxxx>
debian-arm，您好： 请阅附件
采购2007.rtf
Description: Binary data
Date: December 29, 2006
From: "Tyler" <brian_kingstonwfzs@xxxxxxxxxx>
Well well! Nrude CUTEGIRHLS Fsucked Dqoggystyle & Fsacial Gwangbang It seems to be an appropriate way to say hello to OOP lovers :) http://soon.redoloke.com/ Sghaved Lratin HOTALITTLE Uondressing & Fducking Veibrator That low vice, curiosity!
Date: December 28, 2006
From: Frans Pop <elendil@xxxxxxxxx>
Hello porters, I've just announced the schedule [1] for the release of the Installation Guide to be included with the Etch release. That schedule leaves room for bigger updates until Dec 31 and for minor ones until Jan 7. This means that if you have any updates you'd like to get in for your port, there is not much time left. From Jan 1, please consult before directly committing any updates (or send patches). My apologies for not sending out a reminder earlier. Cheers, FJP [1] http://lists.debian.org/debian-boot/2006/12/msg01492.html
pgp5CmyqrMvCM.pgp
Description: PGP signature
Date: December 26, 2006
From: debdev@xxxxxxxxxxxxxx (A Mennucc)
In-reply-to:
<20061224184813.GM9665@xios
>
References:
<20061222080555.GA27217@xxxxxxxxxxxxxx> <458D04E0.5030509@xxxxxxxxxx> <20061223222601.GA9665@xios
> <20061224184813.GM9665@xios
>
hi there somehow, on the eve of 25 Dec, mplayer transitioned into testing this means that someone uploaded the ARM version into the archives.... (I dont know who did that.. if it was not you, then maybe it was Santa :-) thanks anyway for the help ! a. On Sun, Dec 24, 2006 at 06:48:14PM +0000, Wookey wrote: > On 2006-12-23 22:26 +0000, Wookey wrote: > > On 2006-12-23 11:28 +0100, A Mennucc wrote: > > > hi everybody > > I have started a build on hedges and can do a binNMU, but I think it will be > > rejected too as only official builds are currently being accepted. > > OK. It has built. I won't signh and upload it until I get the word. > > Wookey > -- > Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 > work: http://www.aleph1.co.uk/ play: http://wookware.org/ > > > -- > To UNSUBSCRIBE, email to debian-arm-REQUEST@xxxxxxxxxxxxxxxx > with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous, http://www.securityfocus.com/columnists/420
Date: December 26, 2006
From: Andreas Barth <aba@xxxxxxxxxxxxxxx>
In-reply-to:
<20061225111153.GB4889@xxxxxxxxx>
References:
<20061225111153.GB4889@xxxxxxxxx>
* Fabio Tranchitella (kobold@xxxxxxxxx) [061225 12:12]: > please allow a freeze exception for mapserver/4.10.0-4 and postgis/1.1.6-2, > both uploaded six days ago. For mapserver, the only changes are the updated > debconf translations for pt and fr. For postigs, the only change is an updated > README.Debian with some extra documentation for the new users. unblocked both. Cheers, Andi -- http://home.arcor.de/andreas-barth/
Date: December 25, 2006
From: Frans Pop <elendil@xxxxxxxxx>
(BCCed to d-ports)
Hello,
We received a BR that the list of porters for PowerPC on the Organization
webpage [1] was outdated. However, this seems to be true for most ports.
Please reply to debian-www@xxxxxxxxxxxxxxxx with an updated list of active
porters for your port after discussing changes on your port list.
The current list is:
Alpha -- <debian-alpha@xxxxxxxxxxxxxxxx>
member Ivan E. Moore III
member Christopher C. Chimelis
AMD64 -- <debian-amd64@xxxxxxxxxxxxxxxx>
member Frederik Schüler <fs@xxxxxxxxxx>
member Kurt Roeckx <kurt@xxxxxxxxx>
ARM -- <debian-arm@xxxxxxxxxxxxxxxx>
member Philip Blundell
member Othmar Pasteka
i386 -- <debian-devel@xxxxxxxxxxxxxxxx>
member James Troup <james@xxxxxxxxxx>
member Roman Hodek <Roman.Hodek@xxxxxxxxxxxxxxxxxxxxxxxxxx>
member Ryan Murray <rmurray@xxxxxxxxxx>
IA-64 -- <debian-ia64@xxxxxxxxxxxxxxxx>
member Bdale Garbee
member Matthew Wilcox
member Randolph Chung
m68k -- <debian-68k@xxxxxxxxxxxxxxxx>
member Roman Hodek
member Christian T. Steigies
member Michael Schmitz
member Adam Conrad
member Stephen R. Marenka
member Wouter Verhelst
MIPS -- <debian-mips@xxxxxxxxxxxxxxxx>
member Ryan Murray
member Guido Günther
PA-RISC -- <debian-hppa@xxxxxxxxxxxxxxxx>
member Bdale Garbee
member Matthew Wilcox
member Randolph Chung
PowerPC -- <debian-powerpc@xxxxxxxxxxxxxxxx>
member Daniel Jacobowitz
member Martin Schulze
member Hartmut Koptein
S/390 -- <debian-s390@xxxxxxxxxxxxxxxx>
member Gerhard Tonn
SPARC/UltraSPARC -- <debian-sparc@xxxxxxxxxxxxxxxx>
member Ben Collins
member James Troup
SuperH -- <debian-superh@xxxxxxxxxxxxxxxx>
I would suggest at least the following changes:
Alpha: add Steve Langasek
ARM: add Martin Michlmayr
HPPA: add Kyle McMartin
IA-64: add Dann Frazier
MIPS: add Thiemo Seufer
PowerPC: add Sven Luther and Bastian Blank
Sparc: add Jurij Smakov
S/390: add Bastian Blank
Note: you may also wish to review and update the port pages under [2].
Cheers,
FJP
[1] http://www.debian.org/intro/organization
[2] http://www.debian.org/ports/
pgp7b4QgO8kIj.pgp
Description: PGP signature
Date: December 25, 2006
From: "Martin Guy" <martinwguy@xxxxxxxx>
In-reply-to:
<20061223214016.GA1746@xxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx> <20061221141145.GE5810@xxxxxxxxxxxxxxx> <20061223214016.GA1746@xxxxxxxxxxxxxx>
On Thu, Dec 21, 2006 at 03:11:45PM +0100, Wouter Verhelst wrote:
> A prime example is the "tar" testsuite which is very picky about > filesystem behaviour. > - With a real ARM CPU building on local (USB) storage, it passes all tests > - With a real ARM CPU over NFS the testsuite fails one test (cyclic renames) > - From QEMU in a locally-mounted nfsroot it fails a dozen tests. > - Building with QEMU in an NBD volume passes all tests. Clock skew, I guess?
That seems to be most of the answer. NFS timestamps files with the server's clock, while on NBD the entire filesystem structure is client-dependent. Our ARM systems, both real and emulated, are losing between 2 and 3 seconds wallclock time per minute and I had a once-a-minute shell script scrabbling to keep the local clock synchronised with the server. I am hoping that ntpd will do a better job of it. M
Date: December 25, 2006
From: Fabio Tranchitella <kobold@xxxxxxxxx>
Hello,
please allow a freeze exception for mapserver/4.10.0-4 and postgis/1.1.6-2,
both uploaded six days ago. For mapserver, the only changes are the updated
debconf translations for pt and fr. For postigs, the only change is an updated
README.Debian with some extra documentation for the new users.
Both of them miss the arm binaries as they were rejected (I suppose because of
the rogue arm autobuilder), so before the freeze exception they should be
requeued on an official ARM autobuilder.
These are the changelogs:
"""
mapserver (4.10.0-4) unstable; urgency=medium
.
* debian/po/pt.po: updated. (Closes: #401386)
* debian/po/fr.po: added. (Closes: #399395)
"""
"""
postgis (1.1.6-2) unstable; urgency=low
.
* debian/README.Debian: added documentation for the new users on how to use
postgis and how to enable it for new or existent databases.
"""
Thanks in advance,
--
Fabio Tranchitella http://www.kobold.it
Free Software Developer and Consultant http://www.tranchitella.it
_____________________________________________________________________
1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564
signature.asc
Description: Digital signature
Date: December 24, 2006
From: Wookey <wookey@xxxxxxxxxxxx>
In-reply-to:
<20061223222601.GA9665@xios
>
References:
<20061222080555.GA27217@xxxxxxxxxxxxxx> <458D04E0.5030509@xxxxxxxxxx> <20061223222601.GA9665@xios
>
On 2006-12-23 22:26 +0000, Wookey wrote: > On 2006-12-23 11:28 +0100, A Mennucc wrote: > > hi everybody > I have started a build on hedges and can do a binNMU, but I think it will be > rejected too as only official builds are currently being accepted. OK. It has built. I won't signh and upload it until I get the word. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
Date: December 23, 2006
From: Wookey <wookey@xxxxxxxxxxxx>
In-reply-to:
<458D04E0.5030509@xxxxxxxxxx>
References:
<20061222080555.GA27217@xxxxxxxxxxxxxx> <458D04E0.5030509@xxxxxxxxxx>
On 2006-12-23 11:28 +0100, A Mennucc wrote: > hi everybody > > (I am CCing this in d-arm .) > > 'mplayer' 1.0~rc1-10 was correctly built on ARM but the upload from > 'smackdown' was rejected . See > http://buildd.debian.org/pkg.cgi?pkg=mplayer > and the attached message. > > (It seems that this is a recurrent problem: see > http://wiki.debian.org/ArmBuilddWatch ). > > In this case, this is is ~urgent: due to many bugs and discussions, > MPlayer never entered into Etch ; now it is in correct shape to enter; > so the ARM build is the last needed item to have MPlayer into Etch. > > So, > - either someone can requeue this build, > - or some helping soul in d-arm can build and upload it, > - or explain me how to do it (I tried to log in 'agnesi', but it would > not let me do that; I can log in 'leisner', but I see no way to build > mplayer inside it). I have started a build on hedges and can do a binNMU, but I think it will be rejected too as only official builds are currently being accepted. You should mail arm@xxxxxxxxxxxxxxxxx, and ask if this can just be fixed by the buildd maintainers, e.g. by a requeue, or a re-upload or if a binNMU is needed. I can give you a hedges account for you to do your own build (much faster than leisner) if you like. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
Date: December 23, 2006
From: Wookey <wookey@xxxxxxxxxxxx>
In-reply-to:
<20061220185812.GY21698@xxxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <20061220173758.GA22752@xxxxxxxxxxxxxxxxx> <458981B9.9040600@xxxxxxxxxxxxxxx> <20061220185812.GY21698@xxxxxxxxxxxxxxxx>
On 2006-12-20 19:58 +0100, Bill Allombert wrote: > On Wed, Dec 20, 2006 at 12:32:25PM -0600, Bill Gatliff wrote: > > > > Could you try those packages on hedges? (You can get developer access > > from Wookey if you need it). Hedges has 512MB real and 1.5GB swap. And > > unlike leisner, the netwinders, or nslu2s, it's expandable if needed. > > No use, this will simply thrash the box to no end. Try to build openvrml > for example. It failed on europa after 1000 minutes of inactivity: > > <http://buildd.debian.org/fetch.cgi?&pkg=openvrml&ver=0.15.10-8&arch=arm&stamp=1150222284&file=log> This built OK on hedges in about 6 hours. Is a binNMU needed? (meant to get back about this earlier but forgot I had it running). Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
Date: December 23, 2006
From: Daniel Jacobowitz <dan@xxxxxxxxxx>
In-reply-to:
<20061221141145.GE5810@xxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx> <20061221141145.GE5810@xxxxxxxxxxxxxxx>
On Thu, Dec 21, 2006 at 03:11:45PM +0100, Wouter Verhelst wrote: > > A prime example is the "tar" testsuite which is very picky about > > filesystem behaviour. > > - With a real ARM CPU building on local (USB) storage, it passes all tests > > - With a real ARM CPU over NFS the testsuite fails one test (cyclic renames) > > - From QEMU in a locally-mounted nfsroot it fails a dozen tests. > > - Building with QEMU in an NBD volume passes all tests. > > Clock skew, I guess? IIRC it has to do with the order in which files in a directory are returned by readdir. We found that the tar testsuite blew up on some RHEL systems too, and various NFS servers. -- Daniel Jacobowitz CodeSourcery
Date: December 23, 2006
From: A Mennucc <mennucc1@xxxxxxxxxx>
In-reply-to:
<20061222080555.GA27217@xxxxxxxxxxxxxx>
References:
<20061222080555.GA27217@xxxxxxxxxxxxxx>
hi everybody (I am CCing this in d-arm .) 'mplayer' 1.0~rc1-10 was correctly built on ARM but the upload from 'smackdown' was rejected . See http://buildd.debian.org/pkg.cgi?pkg=mplayer and the attached message. (It seems that this is a recurrent problem: see http://wiki.debian.org/ArmBuilddWatch ). In this case, this is is ~urgent: due to many bugs and discussions, MPlayer never entered into Etch ; now it is in correct shape to enter; so the ARM build is the last needed item to have MPlayer into Etch. So, - either someone can requeue this build, - or some helping soul in d-arm can build and upload it, - or explain me how to do it (I tried to log in 'agnesi', but it would not let me do that; I can log in 'leisner', but I see no way to build mplayer inside it). thanks in advance to anyone who would help a. ps: whatever you choose to do, please CC both lists and me to notify A Mennucc ha scritto: > hi everybody > > the ARM version of mplayer_1.0~rc1-10 never entered into the archives, > because of > this error following > > what is the correct thing to do now? > can someone reupload it with a correct signature? > > I dont think this needs a binNMU... the build did not fail, > it is just that the signature failed. > > a. >
--- Begin Message ---Rejected: mplayer_1.0~rc1-10_arm.changes: not signed by authorised uploader === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email.
--- End Message ---
signature.asc
Description: OpenPGP digital signature
Date: December 21, 2006
From: Sam Hocevar <sam@xxxxxxx>
In-reply-to:
<20061221140813.GD5810@xxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <45896FF1.7010801@xxxxxxxxxxxxxxx> <20061220175012.GQ2947@xxxxxxx> <20061221140813.GD5810@xxxxxxxxxxxxxxx>
On Thu, Dec 21, 2006, Wouter Verhelst wrote: > > Pardon me sir, but can that claim that binaries built on so-called > > "real hardware" will unquestionably run (as opposed to, if I understand > > correcly, binaries built on an emulated platform) be backed up by any > > facts, examples, experimentation results or scientific publication? > > Binaries built on real hardware are built on a machine that uses the > binaries built on same real hardware. This is not true. We have different ARM machines that use different CPUs and hardware. Given the versatility of the ARM platform, if the argument "building the binaries on the same machine that uses the binaries" was valid whatsoever, it would in fact be an argument in favour of only using a standardised emulated platform. > I.e., if it works, at least you're sure it doesn't work because the > compiler and the emulator are bug-compatible. But you're sure that it's not because the compiler and the CPU are bug-compatible? Regards, -- Sam.
Date: December 21, 2006
From: Wouter Verhelst <wouter@xxxxxxxxxx>
In-reply-to:
<56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx>
On Wed, Dec 20, 2006 at 07:27:03PM +0000, Martin Guy wrote: > 2006/12/20, Wookey <wookey@xxxxxxxxxxxx>: > >We ought to discuss if there > >is any significant reason not to use qemu 'machines' instead of actual > >hardware for slower arches. > > As Wookey knows, I have been building Debian packages to bootstrap the > armel port of etch under QEMU for a couple of months now, and have had > all sorts of troubles which traced back to doing this on an NFSroot. > Some of this is due to having to use a particularly unreliable NFS > setup, but some problems are repeatable whenever you build in an NFS > volume. > > A prime example is the "tar" testsuite which is very picky about > filesystem behaviour. > - With a real ARM CPU building on local (USB) storage, it passes all tests > - With a real ARM CPU over NFS the testsuite fails one test (cyclic renames) > - From QEMU in a locally-mounted nfsroot it fails a dozen tests. > - Building with QEMU in an NBD volume passes all tests. Clock skew, I guess? (Occasionally, I started to maintain NBD because the RTC driver for m68k macs under Linux is crap. You don't want to know the details) -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Date: December 21, 2006
From: Wouter Verhelst <wouter@xxxxxxxxxx>
In-reply-to:
<20061220175012.GQ2947@xxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <45896FF1.7010801@xxxxxxxxxxxxxxx> <20061220175012.GQ2947@xxxxxxx>
On Wed, Dec 20, 2006 at 06:50:12PM +0100, Sam Hocevar wrote: > On Wed, Dec 20, 2006, Bill Gatliff wrote: > > > For the faster arches, i.e. the ARM9 machines and above, I'm thinking > > that we should stick with real hardware so there's no question that the > > binaries will run properly. > > Pardon me sir, but can that claim that binaries built on so-called > "real hardware" will unquestionably run (as opposed to, if I understand > correcly, binaries built on an emulated platform) be backed up by any > facts, examples, experimentation results or scientific publication? Binaries built on real hardware are built on a machine that uses the binaries built on same real hardware. I.e., if it works, at least you're sure it doesn't work because the compiler and the emulator are bug-compatible. -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Date: December 21, 2006
From: Kevin Mark <kevin.mark@xxxxxxxxxxx>
In-reply-to:
<45897576.6000205@xxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <45897576.6000205@xxxxxxxxxxx>
On Wed, Dec 20, 2006 at 06:40:06PM +0100, Aurelien Jarno wrote: > Wookey a écrit : > > On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: > >> Hi, > >> > >> For those who don't know, I have setup 8 emulated ARM build daemons and > >> started to upload packages. To know why and for more information, see > >> [1]. > > > > Very impressive piece of work aurelien! We ought to discuss if there > > is any significant reason not to use qemu 'machines' instead of actual > > hardware for slower arches. > > > > BTW, I don't think ARM needs emulated build machines. It's just that > it's the fastest ARM machine I found. My two NSLU2 won't have been enough. > > Also it seems the current ARM build machines altogether are fast enough > to build all the packages (except for building big packages like the > kernel). But a faster machine would mean that the Vancouver requirements > are satisfied, and also less machines to handle, so less work for the > ARM build daemon maintainer. Hi *, that brings up an interesting issue wrt the vancouver memorandum: it didn't address software emulation or virtualization. Can qemu and xen be shown to be reliable for buildd purposes? Does the aforementioned document need to be modified for these? cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System | go to counter.li.org and | | `- http://www.debian.org/ | be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org |
signature.asc
Description: Digital signature
Date: December 21, 2006
From: Russ Allbery <rra@xxxxxxxxxx>
In-reply-to:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> (Aurelien Jarno's message of "Wed, 20 Dec 2006 17:39:26 +0100")
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
Aurelien Jarno <aurel32@xxxxxxxxxx> writes: > * Also those package (and they are plenty others), could be tagged > not-for-us. This would spare some build daemon time, and would ease to > see which packages have really failed to build or not. [...] > openafs_1.4.2-4 As the OpenAFS co-maintainer, I can confirm that would be the correct action to take. OpenAFS tries to fail its build fairly quickly with a clear error message, but it really should just be tagged not-for-us on arm (and on mips and mipsel). I tried contacting the Packages-arch-specific maintainers a few times about this a while back without a response. -- Russ Allbery (rra@xxxxxxxxxx) <http://www.eyrie.org/~eagle/>
Date: December 20, 2006
From: Aurelien Jarno <aurel32@xxxxxxxxxx>
In-reply-to:
<1166645058.26586.10.camel@xxxxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <1166645058.26586.10.camel@xxxxxxxxxxxxxxxxx>
Mirco Bauer a écrit : > Hi Aurelien, > > I can give some details about the Mono related packages that failed to > build before but worked for you. I reply inline. > > On Wed, 2006-12-20 at 17:39 +0100, Aurelien Jarno wrote: >> * Packages that now build fine: >> blam_1.8.3-2 (for 40 days) Oops, there is a mistake (copy & paste abuse), this should have been 9 days, as other mono related packages. > blam failed because of a runtime bug (which is specific to the arm port) > in Mono, which can be indentified by throwing random > System.IO.FileNotFoundException, which was fixed in Mono 1.2.2.1 (see > #394418), so a simple rebuild solves this kind of FTBFS on ARM for Mono > based software. Though there are remaining problems still with Mono and > netwinder, which is why the bug isn't closed yet. When you say "netwinder", could you reproduce it on others netwinder machines than the build daemon called that way? FYI this build daemon seems to have some problems (missing files). -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@xxxxxxxxxx | aurelien@xxxxxxxxxxx `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: December 20, 2006
From: Aurelien Jarno <aurel32@xxxxxxxxxx>
In-reply-to:
<56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx>
Martin Guy a écrit : > 2006/12/20, Wookey <wookey@xxxxxxxxxxxx>: >> We ought to discuss if there >> is any significant reason not to use qemu 'machines' instead of actual >> hardware for slower arches. > > As Wookey knows, I have been building Debian packages to bootstrap the > armel port of etch under QEMU for a couple of months now, and have had > all sorts of troubles which traced back to doing this on an NFSroot. > Some of this is due to having to use a particularly unreliable NFS > setup, but some problems are repeatable whenever you build in an NFS > volume. > > A prime example is the "tar" testsuite which is very picky about > filesystem behaviour. > - With a real ARM CPU building on local (USB) storage, it passes all tests > - With a real ARM CPU over NFS the testsuite fails one test (cyclic renames) > - From QEMU in a locally-mounted nfsroot it fails a dozen tests. > - Building with QEMU in an NBD volume passes all tests. > > What do your QEMU buildds use for mass storage? > I am using the emulated SCSI hard-disk, on the versatile platform. See http://www.aurel32.net/info/debian_arm_qemu.php -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@xxxxxxxxxx | aurelien@xxxxxxxxxxx `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: December 20, 2006
From: Mirco Bauer <meebey@xxxxxxx>
In-reply-to:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
Hi Aurelien, I can give some details about the Mono related packages that failed to build before but worked for you. I reply inline. On Wed, 2006-12-20 at 17:39 +0100, Aurelien Jarno wrote: > * Packages that now build fine: > blam_1.8.3-2 (for 40 days) blam failed because of a runtime bug (which is specific to the arm port) in Mono, which can be indentified by throwing random System.IO.FileNotFoundException, which was fixed in Mono 1.2.2.1 (see #394418), so a simple rebuild solves this kind of FTBFS on ARM for Mono based software. Though there are remaining problems still with Mono and netwinder, which is why the bug isn't closed yet. > evolution-sharp_0.11.1-3 (for 9 days) Same thing here as for blam > gcc-h8300-hms_4.1.1-3 (for 7 days) > hdbc-odbc_1.0.1.1 (for 40 days) > hdbc-missingh_1.0.1.1 (for 40 days) > njb-sharp_0.3.0-1 (for 9 days) Same thing as for blam > muine_0.8.5-1.1 (for 9 days) This one seems to fail trying to generate some WDSL stuff, that tries to use the internet, which is not always available on some buildds, but was on your machine seems like. Can't say anything about the other packages. -- Regards, Mirco 'meebey' Bauer PGP-Key: http://keyserver.noreply.org/pks/lookup?op=get&search=0xEEF946C8 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d s-:+ a-- C++ UL++++$ P L++$>+++$ E- W+++$ N o? K- w++>! O---- M- V? PS PE+ Y- PGP++ t 5+ X++ R tv+ b+ DI? D+ G>++ e h! r->++ y? ------END GEEK CODE BLOCK------
signature.asc
Description: This is a digitally signed message part
Date: December 20, 2006
From: Bill Allombert <ballombe@xxxxxxxxxxxxxxxxx>
In-reply-to:
<56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <56d259a00612201127v3f5d4e45r3e1af785dcd965dc@xxxxxxxxxxxxxx>
On Wed, Dec 20, 2006 at 07:27:03PM +0000, Martin Guy wrote: > 2006/12/20, Wookey <wookey@xxxxxxxxxxxx>: > >We ought to discuss if there > >is any significant reason not to use qemu 'machines' instead of actual > >hardware for slower arches. > > As Wookey knows, I have been building Debian packages to bootstrap the > armel port of etch under QEMU for a couple of months now, and have had > all sorts of troubles which traced back to doing this on an NFSroot. > Some of this is due to having to use a particularly unreliable NFS > setup, but some problems are repeatable whenever you build in an NFS > volume. You would get the same problem with NFSroot on a real hardware. > A prime example is the "tar" testsuite which is very picky about > filesystem behaviour. > - With a real ARM CPU building on local (USB) storage, it passes all tests > - With a real ARM CPU over NFS the testsuite fails one test (cyclic renames) > - From QEMU in a locally-mounted nfsroot it fails a dozen tests. > - Building with QEMU in an NBD volume passes all tests. > > What do your QEMU buildds use for mass storage? I use aranym (for m68k) and a 14Gb real hd partition. I tried to use NFS but given up due to the issues you mention and poor performance. Cheers, -- Bill. <ballombe@xxxxxxxxxx> Imagine a large red swirl here.
Date: December 20, 2006
From: "Martin Guy" <martinwguy@xxxxxxxx>
In-reply-to:
<20061220170521.GI9665@xios
>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
>
2006/12/20, Wookey <wookey@xxxxxxxxxxxx>:
We ought to discuss if there is any significant reason not to use qemu 'machines' instead of actual hardware for slower arches.
As Wookey knows, I have been building Debian packages to bootstrap the armel port of etch under QEMU for a couple of months now, and have had all sorts of troubles which traced back to doing this on an NFSroot. Some of this is due to having to use a particularly unreliable NFS setup, but some problems are repeatable whenever you build in an NFS volume. A prime example is the "tar" testsuite which is very picky about filesystem behaviour. - With a real ARM CPU building on local (USB) storage, it passes all tests - With a real ARM CPU over NFS the testsuite fails one test (cyclic renames) - From QEMU in a locally-mounted nfsroot it fails a dozen tests. - Building with QEMU in an NBD volume passes all tests. What do your QEMU buildds use for mass storage? M
Date: December 20, 2006
From: Bill Allombert <Bill.Allombert@xxxxxxxxxxxxxxxxxxx>
In-reply-to:
<458981B9.9040600@xxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <20061220173758.GA22752@xxxxxxxxxxxxxxxxx> <458981B9.9040600@xxxxxxxxxxxxxxx>
On Wed, Dec 20, 2006 at 12:32:25PM -0600, Bill Gatliff wrote: > > Could you try those packages on hedges? (You can get developer access > from Wookey if you need it). Hedges has 512MB real and 1.5GB swap. And > unlike leisner, the netwinders, or nslu2s, it's expandable if needed. No use, this will simply thrash the box to no end. Try to build openvrml for example. It failed on europa after 1000 minutes of inactivity: <http://buildd.debian.org/fetch.cgi?&pkg=openvrml&ver=0.15.10-8&arch=arm&stamp=1150222284&file=log> > But on that point, I've never had any issues with either > distcc+crossgcc--- which I've tested extensively--- or QEMU. But Neither I have (I use distcc+crossgcc on top of aranym quite extensively) so I don't see any reason not to use that if that help the port to be releasable. > forcing the use of real hardware wherever possible means (a) you know > for sure, and (b) you have to keep your real hardware maintained. Those > seem like good things. They are sure good thing but not at the price of the port not being released which is the issue here. Cheers, -- Bill. <ballombe@xxxxxxxxxx> Imagine a large blue swirl here.
Date: December 20, 2006
From: "Gordon Farquharson" <gordonfarquharson@xxxxxxxxx>
In-reply-to:
<41e120000612201048t7c27aed1he8fd838d2232995@xxxxxxxxxxxxxx>
References:
<41e120000612201048t7c27aed1he8fd838d2232995@xxxxxxxxxxxxxx>
On 12/20/06, Bengt Bolinder <bbolinder@xxxxxxxxx> wrote:
Hallo group. When I try to update / upgrade my NSLU2 running debian 2.6.18-3-ixp4xx I get error: Segmentation faulty tree
This is a known problem [1] with 2.6.18-3 and is being actively worked by upstream kernel developers. To work around the problem, delete the cache files (*.bin) in /var/cache/apt, and then rerun apt-get. Gordon [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401980 -- Gordon Farquharson
Date: December 20, 2006
From: Martin Michlmayr <tbm@xxxxxxxxxx>
In-reply-to:
<41e120000612201048t7c27aed1he8fd838d2232995@xxxxxxxxxxxxxx>
References:
<41e120000612201048t7c27aed1he8fd838d2232995@xxxxxxxxxxxxxx>
* Bengt Bolinder <bbolinder@xxxxxxxxx> [2006-12-20 19:48]:
> uname -a showes
> Linux mini 2.6.18-3-ixp4xx #1 Tue Dec 5 16:52:07 UTC 2006 armv5tel GNU/Linux
>
> Do anyone have a solution, please..
That's a known issue. Do
rm /var/cache/apt/*.bin
as a workaround.
--
Martin Michlmayr
http://www.cyrius.com/
Date: December 20, 2006
From: "Bengt Bolinder" <bbolinder@xxxxxxxxx>
Hallo group. When I try to update / upgrade my NSLU2 running debian 2.6.18-3-ixp4xx I get error: Segmentation faulty tree Here is what I do: mini:/# apt-get update Get:1 http://debian.osuosl.org etch Release.gpg [378B] Get:2 http://security.debian.org etch/updates Release.gpg [189B] Hit http://security.debian.org etch/updates Release Ign http://security.debian.org etch/updates/main Packages/DiffIndex Ign http://security.debian.org etch/updates/main Sources/DiffIndex Hit http://security.debian.org etch/updates/main Packages Hit http://security.debian.org etch/updates/main Sources Hit http://debian.osuosl.org etch Release Hit http://debian.osuosl.org etch/main Packages/DiffIndex Hit http://debian.osuosl.org etch/main Sources/DiffIndex Fetched 2B in 10s (0B/s) Reading package lists... Done mini:/# apt-get upgrade Reading package lists... Done Segmentation faulty tree... 50% mini:/# uname -a showes Linux mini 2.6.18-3-ixp4xx #1 Tue Dec 5 16:52:07 UTC 2006 armv5tel GNU/Linux Do anyone have a solution, please.. Thanks in advance. -- Best regards Bengt Bolinder
Date: December 20, 2006
From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
In-reply-to:
<20061220173758.GA22752@xxxxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <20061220173758.GA22752@xxxxxxxxxxxxxxxxx>
Bill:
A very basic reason is that some packages require 1GB of RAM to build in finite time and there are no arm and m68k buildd with that amount of RAM.
Could you try those packages on hedges? (You can get developer access from Wookey if you need it). Hedges has 512MB real and 1.5GB swap. And unlike leisner, the netwinders, or nslu2s, it's expandable if needed.
An alternative is to use distcc+crosscc to a distccd server with 1GB of RAM.
I've done this before (rebuilt X that way, just as a test!), but it has similar concerns to the QEMU approach.
But on that point, I've never had any issues with either distcc+crossgcc--- which I've tested extensively--- or QEMU. But forcing the use of real hardware wherever possible means (a) you know for sure, and (b) you have to keep your real hardware maintained. Those seem like good things.
b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx
Date: December 20, 2006
From: Aurelien Jarno <aurelien@xxxxxxxxxxx>
In-reply-to:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
Aurelien Jarno a écrit : > * Packages that failed to build because the build daemon netwinder is > fucked for weeks wrt to /usr/lib/libtasn1.so.3.0.6 > cpufire-applet_1.2-2 > gnome-session_2.14.3-4 The situation is actually worse than what I expected. This build daemon seems to loose files from its chroot. I don't have access to it, but from the build logs I can say that /sbin/MAKEDEV [1] and /usr/lib/libtasn1.so.3.0.6 [2] are missing. Other files may be missing. Given that a lot of packages are using autoconf to detect available libraries, some packages built by this build daemon may have some disable functionalities. Bye, Aurelien [1] http://buildd.debian.org/build.php?pkg=kdebase&arch=arm&ver=4:3.5.5a.dfsg.1-4 [2] http://buildd.debian.org/fetch.cgi?&pkg=gnome-session&ver=2.14.3-4&arch=arm&stamp=1166563605&file=log -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@xxxxxxxxxx | aurelien@xxxxxxxxxxx `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: December 20, 2006
From: Bill Allombert <ballombe@xxxxxxxxxxxxxxxxx>
In-reply-to:
<20061220170521.GI9665@xios
>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
>
On Wed, Dec 20, 2006 at 05:05:21PM +0000, Wookey wrote: > On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: > > Hi, > > > > For those who don't know, I have setup 8 emulated ARM build daemons and > > started to upload packages. To know why and for more information, see > > [1]. > > Very impressive piece of work aurelien! We ought to discuss if there > is any significant reason not to use qemu 'machines' instead of actual > hardware for slower arches. A very basic reason is that some packages require 1GB of RAM to build in finite time and there are no arm and m68k buildd with that amount of RAM. An alternative is to use distcc+crosscc to a distccd server with 1GB of RAM. Cheers, -- Bill. <ballombe@xxxxxxxxxx> Imagine a large red swirl here.
Date: December 20, 2006
From: Sam Hocevar <sam@xxxxxxx>
In-reply-to:
<45896FF1.7010801@xxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
> <45896FF1.7010801@xxxxxxxxxxxxxxx>
On Wed, Dec 20, 2006, Bill Gatliff wrote: > For the faster arches, i.e. the ARM9 machines and above, I'm thinking > that we should stick with real hardware so there's no question that the > binaries will run properly. Pardon me sir, but can that claim that binaries built on so-called "real hardware" will unquestionably run (as opposed to, if I understand correcly, binaries built on an emulated platform) be backed up by any facts, examples, experimentation results or scientific publication? Kindest regards, -- Sam.
Date: December 20, 2006
From: Aurelien Jarno <aurelien@xxxxxxxxxxx>
In-reply-to:
<20061220170521.GI9665@xios
>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
>
Wookey a écrit : > On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: >> Hi, >> >> For those who don't know, I have setup 8 emulated ARM build daemons and >> started to upload packages. To know why and for more information, see >> [1]. > > Very impressive piece of work aurelien! We ought to discuss if there > is any significant reason not to use qemu 'machines' instead of actual > hardware for slower arches. > BTW, I don't think ARM needs emulated build machines. It's just that it's the fastest ARM machine I found. My two NSLU2 won't have been enough. Also it seems the current ARM build machines altogether are fast enough to build all the packages (except for building big packages like the kernel). But a faster machine would mean that the Vancouver requirements are satisfied, and also less machines to handle, so less work for the ARM build daemon maintainer. What I wanted to demonstrate, is that the percentage of package built by an architecture does depends on the speed of the build machines, but also on how they are administrated. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@xxxxxxxxxx | aurelien@xxxxxxxxxxx `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: December 20, 2006
From: Aurelien Jarno <aurelien@xxxxxxxxxxx>
In-reply-to:
<20061220170521.GI9665@xios
>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
>
Wookey a écrit : > On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: >> Hi, >> >> For those who don't know, I have setup 8 emulated ARM build daemons and >> started to upload packages. To know why and for more information, see >> [1]. > > Very impressive piece of work aurelien! We ought to discuss if there > is any significant reason not to use qemu 'machines' instead of actual > hardware for slower arches. I think we should include Paul Brook in the discussion, as he written a lot of parts of the ARM emulation, and is also active in the Debian ARM port. Anyway I will say that if we can have fast machine (and there are fast ARM machines), it is better than a few not to slow emulated ARM machine. But that machine should be accepted by the DSA. And here is the problem. > How fast is each of your build machines in comparison to existing > buildds? For what I saw they are a bit faster than the Debian build machines. You can expect to have a ARM v5 running at around 350 MHz. And with plenty of RAM (256 MB in my case), so that make a huge difference on some packages. > The offered Hedges machine is more than twice as fast as existing > buildds and really ought to be brought into the network - it has been > offered for about 2 months now. I will mail DSA again to see if anyone > will tell what needs to be done next, by whom, and when. It is very > rude to people making such offers to give no response at all for such > a long time. Fortunately bill seems very tolerant of Debian's foibles, > and we can at least use it as a private developer-access machine in > the meantime. > >> Note that I would have been happy to not start those build daemons, but >> given the way the arm build daemons are administrated, something had to >> be done. > > Perhaps you are right. Let us all try to keep this discussion > constructive. > >> Anyway, I have been able to fix a few packages that were not built >> successfully. For the others, I have extracted from wanna-build a list >> of package that build successfully, but have failed to build for >> various reasons. > > <lots of useful info> > > Can you update the armbuildd wiki page with this? (I expect you are going to > anyway). Yes, I will do that later today. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@xxxxxxxxxx | aurelien@xxxxxxxxxxx `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to debian-arm-REQUEST@xxxxxxxxxxxxxxxx with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
Date: December 20, 2006
From: Bill Gatliff <bgat@xxxxxxxxxxxxxxx>
In-reply-to:
<20061220170521.GI9665@xios
>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx> <20061220170521.GI9665@xios
>
Wookey wrote:
On 2006-12-20 17:39 +0100, Aurelien Jarno wrote:Hi, For those who don't know, I have setup 8 emulated ARM build daemons and started to upload packages. To know why and for more information, see [1].Very impressive piece of work aurelien! We ought to discuss if there is any significant reason not to use qemu 'machines' instead of actual hardware for slower arches.
As long as there's the occasional test on actual hardware, I don't have a problem with it.
For the faster arches, i.e. the ARM9 machines and above, I'm thinking that we should stick with real hardware so there's no question that the binaries will run properly.
How fast is each of your build machines in comparison to existing buildds? The offered Hedges machine is more than twice as fast as existing buildds and really ought to be brought into the network - it has been offered for about 2 months now. I will mail DSA again to see if anyone will tell what needs to be done next, by whom, and when. It is very rude to people making such offers to give no response at all for such a long time. Fortunately bill seems very tolerant of Debian's foibles,
What choice do I have? I'm not a DD, so it isn't like I have any authority to do otherwise. :)
and we can at least use it as a private developer-access machine in the meantime.
Indeed. b.g. -- Bill Gatliff bgat@xxxxxxxxxxxxxxx
Date: December 20, 2006
From: Wookey <wookey@xxxxxxxxxxxx>
In-reply-to:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
References:
<20061220163923.GA28448@xxxxxxxxxxxxxxxxx>
On 2006-12-20 17:39 +0100, Aurelien Jarno wrote: > Hi, > > For those who don't know, I have setup 8 emulated ARM build daemons and > started to upload packages. To know why and for more information, see > [1]. Very impressive piece of work aurelien! We ought to discuss if there is any significant reason not to use qemu 'machines' instead of actual hardware for slower arches. How fast is each of your build machines in comparison to existing buildds? The offered Hedges machine is more than twice as fast as existing buildds and really ought to be brought into the network - it has been offered for about 2 months now. I will mail DSA again to see if anyone will tell what needs to be done next, by whom, and when. It is very rude to people making such offers to give no response at all for such a long time. Fortunately bill seems very tolerant of Debian's foibles, and we can at least use it as a private developer-access machine in the meantime. > Note that I would have been happy to not start those build daemons, but > given the way the arm build daemons are administrated, something had to > be done. Perhaps you are right. Let us all try to keep this discussion constructive. > Anyway, I have been able to fix a few packages that were not built > successfully. For the others, I have extracted from wanna-build a list > of package that build successfully, but have failed to build for > various reasons. <lots of useful info> Can you update the armbuildd wiki page with this? (I expect you are going to anyway). Thanx you for your efforts on the arm port over the last few months - they have been extremely helpful. Can we make aurel32 an arm buildd maintainer? I think he has shown both competence and dedication this year. I'm sure having more than one maintainer would be helpful. Aurel - do you want to commit to this task? Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://wookware.org/
Date: December 20, 2006
From: Aurelien Jarno <aurel32@xxxxxxxxxx>
Hi, For those who don't know, I have setup 8 emulated ARM build daemons and started to upload packages. To know why and for more information, see [1]. These afternoon I saw on #debian-release: 15:52:11 aj | "# unilateral action to run an emulated buildd -- all arm changes sidelined until fixed." 16:18:59 aj | and now aurel32 will presumably fly off the handle 16:22:37 aba | aj: I don't think that is a good idea either if the porters do uploads - i.e. blacklisting is probably better than whitelisting 16:23:14 aba | aj: and please let e.g. people upload to non-free and experimental, e.g. tbm or kmuto 16:28:16 aj | aba: not at this time 16:28:28 aba | aj: at which time then? First I am not very happy to learn that from IRC, I would have prefer to get a mail. However I am very happy to see a reaction on the ARM build daemons side, and this time really fast. Usually, you have to wait that a user detect a problem and warns the build daemon maintainer [2] [3]. And then wait again. Note that I would have been happy to not start those build daemons, but given the way the arm build daemons are administrated, something had to be done. Anyway, I have been able to fix a few packages that were not built successfully. For the others, I have extracted from wanna-build a list of package that build successfully, but have failed to build for various reasons. I would like an explanation from the arm build daemon maintainer why they are still on this state: * Packages that now build fine: blam_1.8.3-2 (for 40 days) evolution-sharp_0.11.1-3 (for 9 days) gcc-h8300-hms_4.1.1-3 (for 7 days) hdbc-odbc_1.0.1.1 (for 40 days) hdbc-missingh_1.0.1.1 (for 40 days) njb-sharp_0.3.0-1 (for 9 days) muine_0.8.5-1.1 (for 9 days) * Packages lost from elara (not uploaded for more than 5 days). Note that it is obvious using [4] to see there is a problem: comple