[Bug 305793] Re: starting partitioner freezes machine at 50%
** Attachment added: hdparm-and-friends.txt http://launchpadlibrarian.net/20264713/hdparm-and-friends.txt -- starting partitioner freezes machine at 50% https://bugs.launchpad.net/bugs/305793 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 305793] Re: starting partitioner freezes machine at 50%
This machine is directly attached to the internet; assuming the LiceCD supports it I'm happy to enable a remote login if anyone wants to poke around. Or think of this as great excuse to buy an Intel x25-e. (No idea if the x25-m will have the same problem or not) Web search finds one similar incident report. http://ubuntuforums.org/showthread.php?t=220086 -- starting partitioner freezes machine at 50% https://bugs.launchpad.net/bugs/305793 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 305793] Re: starting partitioner freezes machine at 50%
Finally found an installation path that works. Never burnt so many CDs in my life. 8.10 i386 live cd : FREEZE 8.10 amd64 lice cd : FREEZE 8.04 amd64 live cd : FREEZE 8.10 amd64 alternate cd : hangs, but way after paritioning 8.04.1 amd64 alternate cd : SUCCESS -- starting partitioner freezes machine at 50% https://bugs.launchpad.net/bugs/305793 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Wesnoth-dev] About the name of my translation (last answer to Robert)
(you are exactly like Sith against Jedi) Usually, the project leader chooses some objective decision criteria. Either a home brew set of rules, or following something like BCP 47.The criteria is applied, the decision is made, the end. However, I'm also cool with a light saber battle. -Jeff BCP47 http://www.rfc-editor.org/rfc/bcp/bcp47.txt ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] About the name of my translation (brief answers and conclusion)
I think Valencian (RACV) sounds reasonable. First, I don't see a need for Wesnoth language translations to be sanctioned by the United Nations, ISO, or any other authority. Heck, its not uncommon for people to translate computer interfaces to Klingon. http://www.google.com/intl/xx-klingon So to me the question boils down to name collision or user confusion. The Valencian (RACV) proposal seems like a fairly descriptive name, and separable from other competing concepts of Valencian. I know linguistic identity can mix with political identity and ignite a lot of passion, and sometimes these battles spill over to unlikely places. But basically - from Wesnoth's perspective - is there really a problem here? Jeff ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Bug#499599: pylucene: README code example doesn't work
Forwarding to upstream.
Accepted jcc 1.9-8 (source i386)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Sat, 30 Aug 2008 18:31:31 -0700
Source: jcc
Binary: jcc
Architecture: source i386
Version: 1.9-8
Distribution: unstable
Urgency: low
Maintainer: Jeff Breidenbach [EMAIL PROTECTED]
Changed-By: Jeff Breidenbach [EMAIL PROTECTED]
Description:
jcc- code generator producing a Python extension from Java classes
Closes: 497131
Changes:
jcc (1.9-8) unstable; urgency=low
.
* Add ${python:Depends} (closes: 497131)
Checksums-Sha1:
622500604ffa9fb3e0cc0f669c7b1770e271bee4 989 jcc_1.9-8.dsc
3362f8b0423352b56d05c95c54f4ac8ea315da24 4637 jcc_1.9-8.diff.gz
6945703a9cfb35c566ca433c24ab5aaa625ede10 186332 jcc_1.9-8_i386.deb
Checksums-Sha256:
ba9e5d8f6a00377e5fd14256007a0eb45788ac9652dc4858f1c17fe2b897b8aa 989
jcc_1.9-8.dsc
e64d903ac76eb07f7873cc9b3588ee77f7b230504254c45b2bb1997fb29c481e 4637
jcc_1.9-8.diff.gz
64f927a9c1688a5502574b05470eacb5267005742afa0718578229f9d679d440 186332
jcc_1.9-8_i386.deb
Files:
8776a9a491318f43c0065444e91f5a63 989 python extra jcc_1.9-8.dsc
5da38f1c7a7f986300bcb57942724559 4637 python extra jcc_1.9-8.diff.gz
9792a881ce99d34f377fd7817062c1c0 186332 python extra jcc_1.9-8_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIufWXazfo3TSzaFYRAlFqAJ9ggJMMFV5PjyV6rgehx7n5He7N8QCeLeh9
DYU3ZAcMa3mTxOGAFEj7I3M=
=T3aF
-END PGP SIGNATURE-
Accepted:
jcc_1.9-8.diff.gz
to pool/main/j/jcc/jcc_1.9-8.diff.gz
jcc_1.9-8.dsc
to pool/main/j/jcc/jcc_1.9-8.dsc
jcc_1.9-8_i386.deb
to pool/main/j/jcc/jcc_1.9-8_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497131: [jcc] Please add ${python:Depends} to Depends field
Thanks! NMU uploads are fine, or I'll get to this when I can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496332: [pylucene] still FTBFS
Thanks! NMU uploads are fine, or I'll get to this when I can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#497131: [jcc] Please add ${python:Depends} to Depends field
Thanks! NMU uploads are fine, or I'll get to this when I can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496332: [pylucene] still FTBFS
Thanks! NMU uploads are fine, or I'll get to this when I can. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496332: pylucene - FTBFS: error: Python.h: No such file or directory
Help appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494690: ftbfs on arm*, uses '$' in C code
You'll need to use -fdollars-in-identifiers in gcc flags to allow compiling code with $ as identifier. Sounds good to me. Feel free to submit as a non-maintainer upload. Or I'll get around to it eventually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jcc 1.9-7 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 10 Aug 2008 11:29:55 -0700 Source: jcc Binary: jcc Architecture: source amd64 Version: 1.9-7 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: jcc- code generator producing a Python extension from Java classes Changes: jcc (1.9-7) unstable; urgency=low . * Fix important debian/changelog typo Checksums-Sha1: 430718312c87ec710c38947069992e0aa8a9fb93 989 jcc_1.9-7.dsc b50ffc1b5e7e3dbdc918a1e21583373ef0ccaa64 4485 jcc_1.9-7.diff.gz 570c2d0152f421638254b754c5634945c768 167704 jcc_1.9-7_amd64.deb Checksums-Sha256: c761b66a2bd272911c25ae7a859a3dfed30ce87345cf38cc6f37849157e8 989 jcc_1.9-7.dsc d0b250cded3d2ae7810a85017f02d8c6be11b617e8eb82e15f04c2363f6c5991 4485 jcc_1.9-7.diff.gz 59e1c98f182ad81bf90c8dcf1701f353b64c7fcbb92dd767c022a0a1c1a6b4aa 167704 jcc_1.9-7_amd64.deb Files: 4d8a3abc40c57d2f56b703769687930a 989 python extra jcc_1.9-7.dsc fa0fcca70caa05d3150ea1be501a2f91 4485 python extra jcc_1.9-7.diff.gz 797a393f5a0ef8fb954193a9003e3258 167704 python extra jcc_1.9-7_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFInzXEazfo3TSzaFYRAgrDAJ4u2L0tcLL55Yha5koKmwHGXlY2FQCeJTkK R8+ScATWlE+0JfS9u1GO8EY= =eyam -END PGP SIGNATURE- Accepted: jcc_1.9-7.diff.gz to pool/main/j/jcc/jcc_1.9-7.diff.gz jcc_1.9-7.dsc to pool/main/j/jcc/jcc_1.9-7.dsc jcc_1.9-7_amd64.deb to pool/main/j/jcc/jcc_1.9-7_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jcc 1.9-5 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 07 Aug 2008 21:54:09 -0700 Source: jcc Binary: jcc Architecture: source amd64 Version: 1.9-5 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: jcc- code generator producing a Python extension from Java classes Closes: 493992 Changes: jcc (1.9-5) unstable; urgency=low . * fix build on non-AMD64 (closes: 493992) Checksums-Sha1: 9b836b7ddf5ec4e197a33a2a0a5ae45d228bde7e 989 jcc_1.9-5.dsc 4b6f4aa9be86ee57ee17eae006bbf7aec0db9625 4419 jcc_1.9-5.diff.gz d4e191c31096592eca92c2887b292b30e9ad9acb 167630 jcc_1.9-5_amd64.deb Checksums-Sha256: c4ebff764599e3ea072b0a670b6ed94651339f85f494eaa02ee174cf42e869da 989 jcc_1.9-5.dsc 8050b99e7d48994d376a0200327ecc96365ca1b505084edbe21ee16f0a9736f9 4419 jcc_1.9-5.diff.gz 48990fd711e801c4d0d5dcc8807430f1b428e905f12e5f82ac73f82a694545c0 167630 jcc_1.9-5_amd64.deb Files: 06a5f7c250d98d2d7d1721fd850a53f8 989 python extra jcc_1.9-5.dsc 47360b335200fb490ea8a3fca66988c3 4419 python extra jcc_1.9-5.diff.gz 5503064dca6011f8cedf98c579f2f28a 167630 python extra jcc_1.9-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIm9Lqazfo3TSzaFYRAvQZAJ4kbpQjfMIXsG/Sueth1ZUXetJzPgCfXu3K RGHc1iJP3nNTtrMgqvPqEEw= =W36F -END PGP SIGNATURE- Accepted: jcc_1.9-5.diff.gz to pool/main/j/jcc/jcc_1.9-5.diff.gz jcc_1.9-5.dsc to pool/main/j/jcc/jcc_1.9-5.dsc jcc_1.9-5_amd64.deb to pool/main/j/jcc/jcc_1.9-5_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
What library is that? libjvm.so Specifically /usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so As found here: http://packages.debian.org/sid/i386/openjdk-6-jre-headless/filelist I'm surprised you got PyLucene to build; I wonder if it runs (there is a simple test in the PyLucene README.Debian) Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Sounds good to me. Will apply and upload your patch today. Thanks for the hard work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Uploaded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
What library is that? libjvm.so Specifically /usr/lib/jvm/java-6-openjdk/jre/lib/i386/client/libjvm.so As found here: http://packages.debian.org/sid/i386/openjdk-6-jre-headless/filelist I'm surprised you got PyLucene to build; I wonder if it runs (there is a simple test in the PyLucene README.Debian) Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Sounds good to me. Will apply and upload your patch today. Thanks for the hard work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Uploaded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Peter, Thank you very much for the patch. It is almost right. Open JDK 1.6 has this really weird setup where one of the shared libraries is under the server subdirectory on AMD64 and under the client subdirectory under i386. (Not sure what the story is on other architectures). The PyLucene binary has almost exactly the same problem if you are interested in looking at that one too. I'm happy to apply a revised patch and submit. Or I'll make an effort to revise your patch myself if I can find the time. -Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#493992: jcc FTBFS on everything except amd64 due to wrong paths (was jcc_1.9-4(sparc/unstable): FTBFS on sparc, missing dependency)
Peter, Thank you very much for the patch. It is almost right. Open JDK 1.6 has this really weird setup where one of the shared libraries is under the server subdirectory on AMD64 and under the client subdirectory under i386. (Not sure what the story is on other architectures). The PyLucene binary has almost exactly the same problem if you are interested in looking at that one too. I'm happy to apply a revised patch and submit. Or I'll make an effort to revise your patch myself if I can find the time. -Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[pylucene-dev] Fwd: pylucene_2.3.1-1_amd64.changes ACCEPTED
Hip hip hurray! And finally. Both PyLucene and JCC are now part of Debian main. Kudos to everyone directly involved, and a special thank you to Sun for open sourcing of Java. That made life so much easier. These package will automatically propogate all over the place over time, including Debian derived distributions like Ubuntu. Right now, users of Debian unstable (sid) should be able to apt-get install pylucene. http://packages.qa.debian.org/j/jcc.html http://packages.qa.debian.org/p/pylucene.html -- Forwarded message -- From: Debian Installer [EMAIL PROTECTED] Date: Mon, Aug 4, 2008 at 8:10 PM Subject: pylucene_2.3.1-1_amd64.changes ACCEPTED To: Jeff Breidenbach [EMAIL PROTECTED] Accepted: pylucene_2.3.1-1.diff.gz to pool/main/p/pylucene/pylucene_2.3.1-1.diff.gz pylucene_2.3.1-1.dsc to pool/main/p/pylucene/pylucene_2.3.1-1.dsc pylucene_2.3.1-1_amd64.deb to pool/main/p/pylucene/pylucene_2.3.1-1_amd64.deb pylucene_2.3.1.orig.tar.gz to pool/main/p/pylucene/pylucene_2.3.1.orig.tar.gz Override entries for your package: pylucene_2.3.1-1.dsc - extra text pylucene_2.3.1-1_amd64.deb - extra text Announcing to [EMAIL PROTECTED] Closing bugs: 490254 Thank you for your contribution to Debian. ___ pylucene-dev mailing list pylucene-dev@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
Accepted pylucene 2.3.1-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Apr 2008 10:39:49 -0700 Source: pylucene Binary: pylucene Architecture: source amd64 Version: 2.3.1-1 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: pylucene - Python extension for accessing Java Lucene Closes: 490254 Changes: pylucene (2.3.1-1) unstable; urgency=low . * Initial release (closes: 490254) Files: 3219b6c08acfe9e5827e0711a8ae068f 593 text extra pylucene_2.3.1-1.dsc aedbb508cf430ad3f2aab2492c6e42de 7932955 text extra pylucene_2.3.1.orig.tar.gz dc605f5e2b771b75b0e802801c4ba670 2944 text extra pylucene_2.3.1-1.diff.gz 32daa5246a7f64a22fd991341c017cb9 2565956 text extra pylucene_2.3.1-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIhsYqazfo3TSzaFYRAoT/AJ46B+/jpAVgf4bW0cSNA4OxoiFhygCbBK0z CDRcIbsRTn3wBOYpbVTrhZk= =MwDn -END PGP SIGNATURE- Accepted: pylucene_2.3.1-1.diff.gz to pool/main/p/pylucene/pylucene_2.3.1-1.diff.gz pylucene_2.3.1-1.dsc to pool/main/p/pylucene/pylucene_2.3.1-1.dsc pylucene_2.3.1-1_amd64.deb to pool/main/p/pylucene/pylucene_2.3.1-1_amd64.deb pylucene_2.3.1.orig.tar.gz to pool/main/p/pylucene/pylucene_2.3.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jcc 1.9-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 23 Jul 2008 12:33:40 -0700 Source: jcc Binary: jcc Architecture: source amd64 Version: 1.9-4 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: jcc- code generator producing a Python extension from Java classes Changes: jcc (1.9-4) unstable; urgency=low . * fix a dependency bug Checksums-Sha1: 156cce641e09d310fe2f55de2103f95f711b245a 989 jcc_1.9-4.dsc 756850bc5714050938245e39b47250ae95e180d2 3998 jcc_1.9-4.diff.gz 014d36e581b77fa5b4c38f60a97612d3d33e7dce 167574 jcc_1.9-4_amd64.deb Checksums-Sha256: 22640e48ffd5eb8768f3120bf79f8b6c7ffe4c62d8d5b7e5188d144366d65e01 989 jcc_1.9-4.dsc f92f9f287f6e75c9f601911c195373a7306492e3c359b2a0f87e88d11d6f85ec 3998 jcc_1.9-4.diff.gz c6f7372a44a5f989b699cea9cb07a3d428544289854cd1548656b841da31f1db 167574 jcc_1.9-4_amd64.deb Files: 9aea98945e7ccf66d4cab75f23aad20b 989 python extra jcc_1.9-4.dsc 3930e94540311835d53ed341181cbffd 3998 python extra jcc_1.9-4.diff.gz 39f99d6a1559fcb0b30569f6a6b2b74e 167574 python extra jcc_1.9-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIh4h7azfo3TSzaFYRApgyAKCg+84hslU089jz071WMh1Kirrw/wCdHkVh tD4sfko1z6EbhD7xwJkCX2M= =xj5p -END PGP SIGNATURE- Accepted: jcc_1.9-4.diff.gz to pool/main/j/jcc/jcc_1.9-4.diff.gz jcc_1.9-4.dsc to pool/main/j/jcc/jcc_1.9-4.dsc jcc_1.9-4_amd64.deb to pool/main/j/jcc/jcc_1.9-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jcc 1.9-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 22 Jul 2008 21:20:20 -0700 Source: jcc Binary: jcc Architecture: source amd64 Version: 1.9-3 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: jcc- code generator producing a Python extension from Java classes Changes: jcc (1.9-3) unstable; urgency=low . * Move to main using OpenJDK Checksums-Sha1: 99c4042182a2946273c314fc33e7be978485ace5 989 jcc_1.9-3.dsc d8067578a6bc70c04c654b69b2d103fa5b993be6 3968 jcc_1.9-3.diff.gz a0daf658d58cc50b56dcc1234e8432a9ecbbadbe 167554 jcc_1.9-3_amd64.deb Checksums-Sha256: 6bdb41795cc6c46f832206e566da46a190e3dde8cb77ea42887d5d7723cbf20b 989 jcc_1.9-3.dsc 492051c14f2741021f9166e529c5e9414a09aa9391ca1adf6d6cde5136f12680 3968 jcc_1.9-3.diff.gz e37e863b6189858a24e9d06af5276348b7301f2df71ab996aebddd13f512b1a5 167554 jcc_1.9-3_amd64.deb Files: c14598af6ad1737866fc0af452fa4f25 989 python extra jcc_1.9-3.dsc 24c7fafcb41fe95b4087b98529a24eca 3968 python extra jcc_1.9-3.diff.gz d38a59049363a72adff9c39cc43d4d58 167554 python extra jcc_1.9-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIhrgEazfo3TSzaFYRAnSnAKCu9cZibIs5PkhMjQzd5ikzJRStowCfZMxy NxWLrweFvyR1iJz8V5NrN7A= =GCP8 -END PGP SIGNATURE- Accepted: jcc_1.9-3.diff.gz to pool/main/j/jcc/jcc_1.9-3.diff.gz jcc_1.9-3.dsc to pool/main/j/jcc/jcc_1.9-3.dsc jcc_1.9-3_amd64.deb to pool/main/j/jcc/jcc_1.9-3_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488895:
But that said, openjdk entered Debian now (yay!). Good. Lucene2 can be moved to main with a build-depends on OpenJDK. Who's got the energy to do it? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488895:
But that said, openjdk entered Debian now (yay!). Good. Lucene2 can be moved to main with a build-depends on OpenJDK. Who's got the energy to do it? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted leptonlib 1.57-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 16 Jul 2008 10:38:21 -0700 Source: leptonlib Binary: libleptonica leptonica-progs libleptonica-dev Architecture: source i386 Version: 1.57-1 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: leptonica-progs - sample programs for Leptonica image processing library libleptonica - image processing library libleptonica-dev - image processing library Changes: leptonlib (1.57-1) unstable; urgency=low . * New upstream release Files: 730de86f5eb20abbded6b07018c77fea 646 graphics optional leptonlib_1.57-1.dsc 890f3ba2cc0d904306a1a4fc9eae23fb 3945624 graphics optional leptonlib_1.57.orig.tar.gz 6ddc12584d150327895b34b029017b86 6372 graphics optional leptonlib_1.57-1.diff.gz bbcca2034da370702fa0eac5c0b9edc9 866858 libdevel optional libleptonica-dev_1.57-1_i386.deb dfb7be697e3763f765e1e8280cffbb17 437116 libs optional libleptonica_1.57-1_i386.deb efd08d55ffd9b6dbd62701a1040faf4a 97814 graphics optional leptonica-progs_1.57-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFIfjgeazfo3TSzaFYRAg8/AJwPELKR+poksoc2lAc0YHQGVLdUEgCgiIgP 5Gamet72/E6Qe893cDzkL5w= =aZvq -END PGP SIGNATURE- Accepted: leptonica-progs_1.57-1_i386.deb to pool/main/l/leptonlib/leptonica-progs_1.57-1_i386.deb leptonlib_1.57-1.diff.gz to pool/main/l/leptonlib/leptonlib_1.57-1.diff.gz leptonlib_1.57-1.dsc to pool/main/l/leptonlib/leptonlib_1.57-1.dsc leptonlib_1.57.orig.tar.gz to pool/main/l/leptonlib/leptonlib_1.57.orig.tar.gz libleptonica-dev_1.57-1_i386.deb to pool/main/l/leptonlib/libleptonica-dev_1.57-1_i386.deb libleptonica_1.57-1_i386.deb to pool/main/l/leptonlib/libleptonica_1.57-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488895: please move to main
When we went through this for Lucene 1.4.3, the trick was to compile under main, and then make sure the regression tests passed if Sun Java was installed. That way we knew the package was ok to ship and the problems were all in the runtime. But seriously, what's the ETA for Sun Java to enter main? Fedora is already shipping it, right? ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#490254: ITP: pylucene - Python extension for accessing Java Lucene
Package: wnpp Severity: wishlist http://pylucene.osafoundation.org/ Apache 2.0 License -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488895: please move to main
When we went through this for Lucene 1.4.3, the trick was to compile under main, and then make sure the regression tests passed if Sun Java was installed. That way we knew the package was ok to ship and the problems were all in the runtime. But seriously, what's the ETA for Sun Java to enter main? Fedora is already shipping it, right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490254: ITP: pylucene - Python extension for accessing Java Lucene
Package: wnpp Severity: wishlist http://pylucene.osafoundation.org/ Apache 2.0 License -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#488895: please move to main
When we went through this for Lucene 1.4.3, the trick was to compile under main, and then make sure the regression tests passed if Sun Java was installed. That way we knew the package was ok to ship and the problems were all in the runtime. But seriously, what's the ETA for Sun Java to enter main? Fedora is already shipping it, right? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Mailman-Developers] RFC 5064 Archived-At header
Will someone provide some real use case scenarios of how the archived-at URL gets used by a message receipient. If I have the message locally, do I care where it is archived? It's handy if you are writing a blog. For example, Linux Weekly News reports on the Linux Kernel mailing list. They quote particular messages, and provide an archival link. This lets readers examine the (possibly active) thread. http://lwn.net/Articles/286910/ http://lwn.net/Articles/287490/ ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Accepted jcc 1.9-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 27 Apr 2008 21:33:03 -0700 Source: jcc Binary: jcc Architecture: source amd64 Version: 1.9-1 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: jcc- code generator producing a Python extension from Java classes Changes: jcc (1.9-1) unstable; urgency=low . * Initial release Files: 0355e3aefd197843ad22acda32f8d1fb 655 contrib/python extra jcc_1.9-1.dsc 3e1ea01b4ed507632ad521c166a4d70a 56698 contrib/python extra jcc_1.9.orig.tar.gz f11ab0c2ecd7d3121147d7316339812a 3485 contrib/python extra jcc_1.9-1.diff.gz 2339272ba73f975308f5f029559e8bd5 167810 contrib/python extra jcc_1.9-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIQjY9azfo3TSzaFYRAqL/AJ9d116Qp0P/Z19d4DYV2DqjIKA8OQCeKlrV hl7SdQqmVyMwo4k4W31NJf0= =/R2E -END PGP SIGNATURE- Accepted: jcc_1.9-1.diff.gz to pool/contrib/j/jcc/jcc_1.9-1.diff.gz jcc_1.9-1.dsc to pool/contrib/j/jcc/jcc_1.9-1.dsc jcc_1.9-1_amd64.deb to pool/contrib/j/jcc/jcc_1.9-1_amd64.deb jcc_1.9.orig.tar.gz to pool/contrib/j/jcc/jcc_1.9.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
full site search
Ok, that one got away from me. Let's try this again. I've enabled an experimental full site search. It's definitely not ready for prime time; too slow and we aren't going to update the index regularly. And it might go away at any time. But if you want to play around, have fun. We don't really have a good use case for full site search and it takes some work to do it well. So speak up if you think this is worth pursuing. http://www.mail-archive.com/search?l=all -- To unsubscribe, send mail to [EMAIL PROTECTED]
[pylucene-dev] Re: debian / ubuntu jcc package
One thing I noticed is that your package contains _jcc.so for Python 2.4 and Python 2.5. Is that intentionally? No, it came for free from the build infrastructure. That's because the linker can't find libjvm.so (which should be part of Sun's JDK). You can set an rpath in setup.py but at least for Fedora this may not be acceptable [...] Thanks; that was it. I'll try adding an entry in /etc/ld.so.conf.d because Debian disallows the use of rpath. http://wiki.debian.org/RpathIssue ___ pylucene-dev mailing list pylucene-dev@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
[pylucene-dev] Re: debian / ubuntu jcc package
I've placed an Ubuntu PyLucene package online at just now. I'm also in progress submitting a package for inclusion with Debian. But that will almost certainly require some time and back and forth - the last time I did this, the package was rejected for quality reasons. This represents some regrouping and making another effort. PyLucene 2.3.1 :: JCC 1.9 :: Ubuntu 8.04 :: AMD64 :: Python 2.5 :: Sun Java 1.6 http://www.mail-archive.com/pylucene ___ pylucene-dev mailing list pylucene-dev@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
[pylucene-dev] debian / ubuntu jcc package
http://ftp-master.debian.org/new/jcc_1.9-1.html#binary-jcc-contents a) Which of these files should I prune from the package? b) python -m jcc complains about not being able to find libjvm.so; I assume I messed something up in the package to cause that, but am not sure which part. ___ pylucene-dev mailing list pylucene-dev@osafoundation.org http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
[pylucene-dev] jcc setup.py LFLAGS
For packaging purposes, I'm planning to change jcc/setup.py as follows so that
autobuilders have fewer problems. It means there are a couple extra paths for
the linker / dynamic loader to search, but I don't see this as a big deal.
Q1: I notice that rpath i386/AMD64 don't really match; one talks about client,
the other talks about a server subdirectory. Is this a simple oversight?
Q2: Maybe this should be considered for the office version of setup.py
after all ?
Jeff
===
LFLAGS = {
'darwin': ['-framework', 'JavaVM'],
'linux2': ['-L/usr/lib/jvm/java-6-sun/jre/lib/i386',
'-L/usr/lib/jvm/java-6-sun/jre/lib/amd64',
'-ljava',
('-Wl,-rpath=/usr/lib/jvm/java-6-sun/jre/lib/amd64:'
'/usr/lib/jvm/java-6-sun/jre/lib/amd64/server:'
'/usr/lib/jvm/java-6-sun/jre/lib/i386:'
'/usr/lib/jvm/java-6-sun/jre/lib/i386/client')],
'sunos5': ['-L/usr/jdk/instances/jdk1.6.0/jre/lib/i386', '-ljava',
('-R/usr/jdk/instances/jdk1.6.0/jre/lib/i386:'
'/usr/jdk/instances/jre/lib/i386/client')],
'win32': ['/LIBPATH:o:/Java/jdk1.6.0_02/lib', 'jvm.lib']
}
___
pylucene-dev mailing list
pylucene-dev@osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
feedback on jcc package, please
Could I please get some feedback on the package jcc ? This is my first time using cdbs. http://www.jab.org/jcc/ Thanks, Jeff [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[Bug 194207] Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
have become unusable in 2.6.24. Besides the annoying warning, what else goes wrong? (I recently reported duplicate bug #197982) -- arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings https://bugs.launchpad.net/bugs/194207 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 194207] Re: arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings
That's interesting; I only get the warning when I run the cli64 tool to query drive status. Regular use of the SATA controller doesn't trigger any warnings for me, no matter what the load. Probably the difference is in how we are utilizing the Areca card; I'm just using a simple passthrough mode and not actually invoking any of the hardware RAID capabilities of the card. -- arcmsr + archttp64 calls dma_free_coherent() with irqs disabled - dmesg filled with warnings https://bugs.launchpad.net/bugs/194207 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 197982] [NEW] dma warning in hardy kernel
Public bug reported: I see this repeatedly in syslog [ 4074.960149] WARNING: at /build/buildd/linux-2.6.24/arch/x86/kernel/pci-dma_64.c:169 dma_free_coherent() [ 4074.960152] Pid: 19831, comm: cli64 Not tainted 2.6.24-8-server #1 [ 4074.960153] [ 4074.960154] Call Trace: [ 4074.960157] [802144ca] dma_alloc_coherent+0x13a/0x200 [ 4074.960161] [80214283] dma_free_coherent+0xa3/0xb0 [ 4074.960166] [880f8540] :arcmsr:arcmsr_queue_command+0x890/0x9a0 [ 4074.960177] [880c800c] :scsi_mod:scsi_dispatch_cmd+0x17c/0x2e0 [ 4074.960187] [880ced75] :scsi_mod:scsi_request_fn+0x225/0x3d0 [ 4074.960191] [8033bf72] blk_execute_rq_nowait+0x62/0xb0 [ 4074.960200] [880ce644] :scsi_mod:scsi_execute_async+0x1f4/0x3e0 [ 4074.960208] [881d34df] :sg:sg_common_write+0x18f/0x930 [ 4074.960212] [881d3f50] :sg:sg_cmd_done+0x0/0x2c0 [ 4074.960216] [80468070] thread_return+0x3a/0x59a [ 4074.960222] [881d3e4d] :sg:sg_new_write+0x1cd/0x2d0 [ 4074.960227] [881d5c65] :sg:sg_ioctl+0x4c5/0xb60 [ 4074.960230] [80468d59] do_nanosleep+0x69/0x90 [ 4074.960233] [80257538] hrtimer_nanosleep+0x78/0x140 [ 4074.960236] [802bd16d] do_ioctl+0x7d/0xa0 [ 4074.960240] [802bd3b0] vfs_ioctl+0x220/0x2c0 [ 4074.960244] [802bd4e1] sys_ioctl+0x91/0xb0 [ 4074.960247] [8020c37e] system_call+0x7e/0x83 # cat /proc/version Linux version 2.6.24-8-server ([EMAIL PROTECTED]) (gcc version 4.2.3 (Ubuntu 4.2.3-1ubuntu2)) #1 SMP Thu Feb 14 20:42:20 UTC 2008 This is a hardy kernel on gutsy # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=7.10 DISTRIB_CODENAME=gutsy DISTRIB_DESCRIPTION=Ubuntu 7.10 There's an Areca 1230 SATA controller in the system. To trigger the warning, I can run the Areca command line utility cli64 which is some presumably closed source RAID management tool. Or at least it was a binary download. Running it and asking what disks are attached to the controller rsf info triggers the warning. I have no idea if this warning matters in the slightest, but thought it best to report. ** Affects: ubuntu Importance: Undecided Status: New -- dma warning in hardy kernel https://bugs.launchpad.net/bugs/197982 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 198248] [NEW] cfdisk creates invalid (!) partion tables on disk
Public bug reported: Binary package hint: util-linux cfdisk is apparently putting bad info on disk, but poking the kernel correctly and directly when making large partitions. Everything looks fine until the first reboot. I hear this is a known problem with parted, but want to let you know cfdisk is also affected. To reproduce: a) Get a terabyte drive b) Make a giant partition on it + mount (I formatted xfs) c) Everything is happy happy joy joy d) reboot e) partition is gone! udev doesn't make a device, manually running mknod doesn't help. Bad! f) re-run cfdisk (which sees the partition) and write it again. g) everything mounts happy happy ... at least for this boot cycle # cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=7.10 DISTRIB_CODENAME=gutsy DISTRIB_DESCRIPTION=Ubuntu 7.10 Running a hardy kernel # cat /proc/version Linux version 2.6.24-8-server ([EMAIL PROTECTED]) (gcc version 4.2.3 (Ubuntu 4.2.3-1ubuntu2)) #1 SMP Thu Feb 14 20:42:20 UTC 2008 # apt-cache policy util-linux util-linux: Installed: 2.13-8ubuntu1 Candidate: 2.13-8ubuntu1 Version table: *** 2.13-8ubuntu1 0 500 http://us.archive.ubuntu.com gutsy/main Packages 100 /var/lib/dpkg/status Thread is here with more details. http://oss.sgi.com/archives/xfs/2008-03/msg00030.html ** Affects: util-linux (Ubuntu) Importance: Undecided Status: New -- cfdisk creates invalid (!) partion tables on disk https://bugs.launchpad.net/bugs/198248 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: transferring RAID-1 drives via sneakernet
I just finished the transfer and it went great. Thanks for all the advice. I went with the assemble-by-uuid approach in /etc/mdadm.conf which did very well. Especially since drive letters danced around quite a bit between reboots. One of the disks died during transit, and the redundancy part of RAID earned its keep. The only thing I didn't figure out was SATA hotplug. The SATA controller (an Areca 1230 in JBOD mode) happily noticed when a drive was hotplugged into a port. But Linux didn't seem to notice. I was using cfdisk to probe. Is there a particular command needed to convince Linux to look around and see if there are any new SATA devices? Jeff - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
It's not a RAID issue, but make sure you don't have any duplicate volume names. According to Murphy's Law, if there are two / volumes, the wrong one will be chosen upon your next reboot. Thanks for the tip. Since I'm not using volumes or LVM at all, I should be safe from this particular problem. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: transferring RAID-1 drives via sneakernet
Does the new machine have a RAID array already? Yes.. the new machine already has on RAID array. After sneakernet it should have two RAID arrays. Is there a gotcha? - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
transferring RAID-1 drives via sneakernet
I'm planning to take some RAID-1 drives out of an old machine and plop them into a new machine. Hoping that mdadm assemble will magically work. There's no reason it shouldn't work. Right? old [ mdadm v1.9.0 / kernel 2.6.17 / Debian Etch / x86-64 ] new [ mdad v2.6.2 / kernel 2.6.22 / Ubuntu 7.10 server ] - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Any inexpensive hardware recommendations for PCI interface cards?
Does anyone recommend any inexpensive (probably SATA-II) PCI interface cards? See this message and surrounding thread from November 2007 on the linux-ide list. http://www.mail-archive.com/[EMAIL PROTECTED]/msg12726.html - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm break / restore soft mirror
So the obvious follow up question is: for this scenario does it make sense to only resync the difference between the two bitmaps? E.g. Drive A will have a current bitmap, B will have a stale bitmap. Presumably one could get away with just resyncing the difference. Or is this too much of special case to consider? Jeff - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm break / restore soft mirror
On Dec 14, 2007 11:13 AM, Jeff Breidenbach [EMAIL PROTECTED] wrote: So the obvious follow up question is: for this scenario does it make sense to only resync the difference between the two bitmaps? Never mind, I see why this won't work. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm break / restore soft mirror
What you could do is set the number of devices in the array to 3 so they it always appears to be degraded, then rotate your backup drives through the array. The number of dirty bits in the bitmap will steadily grow and so resyncs will take longer. Once it crosses some threshold you set the array back to having 2 devices to that it looks non-degraded and clean the bitmap. Then each device will need a full resync after which you will get away with partial resyncs for a while. I don't undertand why clearing the bitmap causes a rebuild of all devices. I think I have a conceptual misunderstanding. Consider a RAID-1 and three physical disks involved, A,B,C 1) A and B are in the RAID, everything is synced 2) Create a bitmap on the array 3) Fail + remove B 4) Hot add C, wait for C to sync 5) Fail + remove C 6) Hot add B, wait for B to resync 7) Goto step 3 I understand that after a while we might want to clean the bitmap and that would trigger a full resync for drives B and C. I don't understand why it would ever cause a resync for drive A. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mdadm break / restore soft mirror
Proposed solution is to use software raid mirror. Before backup starts, break the soft mirror unmount and backup partition I use this method for backup once a week. One challenge is drives aren't great at steaming data quickly (for the resync) while also doing a lot of random access. Having a little extra redundancy (think 3 or more drives in the RAID-1) can really help. If you can be certain that the device that you break out of the mirror is never altered, then you could add an internal bitmap while the array is split and the rebuild will go much faster. Is this also a viable speedup for the kep rotating backup drives through the array strategy? If so, how much speedup are we talking about? Assume the array changes by 1% before a backup drive gets rotated in again. Jeff - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
unable to remove failed drive
... and all access to array hangs indefinitely, resulting in unkillable zombie
processes. Have to hard reboot the machine. Any thoughts on the matter?
===
# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sde1[6](F) sdg1[1] sdb1[4] sdd1[3] sdc1[2]
488383936 blocks [6/4] [__]
unused devices: none
# mdadm --fail /dev/md1 /dev/sde1
mdadm: set /dev/sde1 faulty in /dev/md1
# mdadm --remove /dev/md1 /dev/sde1
mdadm: hot remove failed for /dev/sde1: Device or resource busy
# mdadm -D /dev/md1
/dev/md1:
Version : 00.90.03
Creation Time : Sun Dec 25 16:12:34 2005
Raid Level : raid1
Array Size : 488383936 (465.76 GiB 500.11 GB)
Device Size : 488383936 (465.76 GiB 500.11 GB)
Raid Devices : 6
Total Devices : 5
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Fri Dec 7 11:37:46 2007
State : active, degraded
Active Devices : 4
Working Devices : 4
Failed Devices : 1
Spare Devices : 0
UUID : f3ee6aa3:2f1d5767:f443dfc0:c23e80af
Events : 0.22331500
Number Major Minor RaidDevice State
0 00- removed
1 8 971 active sync /dev/sdg1
2 8 332 active sync /dev/sdc1
3 8 493 active sync /dev/sdd1
4 8 174 active sync /dev/sdb1
5 00- removed
6 8 650 faulty /dev/sde1
# dmesg
sd 4:0:0:0: SCSI error: return code = 0x802
sde: Current: sense key: Aborted Command
Additional sense: Scsi parity error
end_request: I/O error, dev sde, sector 594882271
raid1: sde1: rescheduling sector 594882208
ata5: command timeout
ata5: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00
ata5: status=0xff { Busy }
sd 4:0:0:0: SCSI error: return code = 0x802
sde: Current: sense key: Aborted Command
Additional sense: Scsi parity error
end_request: I/O error, dev sde, sector 528737607
raid1: sde1: rescheduling sector 528737544
ata5: command timeout
ata5: translated ATA stat/err 0xff/00 to SCSI SK/ASC/ASCQ 0xb/47/00
ata5: status=0xff { Busy }
sd 4:0:0:0: SCSI error: return code = 0x802
sde: Current: sense key: Aborted Command
Additional sense: Scsi parity error
end_request: I/O error, dev sde, sector 814377071
[...]
md: cannot remove active disk sde1 from md1 ...
md: could not bd_claim sde1.
md: error, md_import_device() returned -16
# cat /proc/version
Linux version 2.6.17-2-amd64 (Debian 2.6.17-7) ([EMAIL PROTECTED]) (gcc
version 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)) #1 SMP Thu Aug
24 16:13:57 UTC 2006
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: stable basic 4-port SATA card
Thanks for the excellent rundown. sata_sil24: 3124/3132 chips don't have any outstanding serious problems. IRQ loss on PCI-X was the only recent serious known problem but it's fixed now. I'm still a little confused how to translate this known-good chipset to an actual buyable PCI card. It isn't obvious from basic web searching. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
stable basic 4-port SATA card
I read with interest I. Straford's current trials and tribulations with the Promise SATA300 TX4. Do people have a favorite alternative to this card that plays well with Linux? I've read the chipset compatibility list, but am not sure how to boil that information down to an actual buyable SATA controller. http://www.mail-archive.com/linux-ide@vger.kernel.org/msg12398.html http://linux-ata.org/driver-status.html - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Mailman-Developers] Improving the archives
but if you can trust yourself to generate them, consecutive integers provide minimal, order-preserving, perfect hashing, too! Hmm this sounds pretty sensible to me. Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Accepted jhove 1.1g-5 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 15 Oct 2007 18:23:21 -0700 Source: jhove Binary: jhove Architecture: source all Version: 1.1g-5 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: jhove - JSTOR/Harvard Object Validation Environment Changes: jhove (1.1g-5) unstable; urgency=low . * Switching to non-free Files: f85e69ea059511ffd5db70fdd4d37869 655 non-free/utils optional jhove_1.1g-5.dsc 5a784bc6a9b8db24fa3bffd4db122ae0 1273205 non-free/utils optional jhove_1.1g.orig.tar.gz 9432e2a38126ed0e4f6c17abfa9c6593 4508 non-free/utils optional jhove_1.1g-5.diff.gz 048b46a9e7c1536bc6c3f3fe565ba6c1 1986036 non-free/utils optional jhove_1.1g-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFHFBPRazfo3TSzaFYRAnMUAJ9SSYitmJAnVFhweiQmQLThUdXIQACgozUJ Mk+kWf1s7ommBwU4rYTbbE8= =5rdt -END PGP SIGNATURE- Accepted: jhove_1.1g-5.diff.gz to pool/non-free/j/jhove/jhove_1.1g-5.diff.gz jhove_1.1g-5.dsc to pool/non-free/j/jhove/jhove_1.1g-5.dsc jhove_1.1g-5_all.deb to pool/non-free/j/jhove/jhove_1.1g-5_all.deb jhove_1.1g.orig.tar.gz to pool/non-free/j/jhove/jhove_1.1g.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Slight change in address for my mailing list
Hi Terrence, The domain for the mailing list is lists.metaperl.com, not metaperl.com. Sure, I think we can help you out. Let's move this to the customer service address instead of using gossip. By the way, you've got an X-No-Archive: yes header in your new setup, which is preventing archiving. Please take care of that first. Cheers, Jeff -- To unsubscribe, send mail to [EMAIL PROTECTED]
[bug #20142] strip backslash in rfc822 From: field
Follow-up Comment #5, bug #20142 (project mhonarc):
--- /var/tmp/mhutil.pl 2007-10-09 20:30:36.0 -0700
+++ /usr/share/mhonarc/mhutil.pl2007-10-09 21:32:05.0 -0700
@@ -176,7 +176,8 @@
foreach $tok (@tokens) {
next if $skip;
if ($tok =~ /^/) { # Quoted string
$tok =~ s/^//; $tok =~ s/$//;
+ $tok =~ s/\(.)/$1/g; $tok =~ s/\//g;
return $tok;
}
if ($tok =~ /^(/) { # Comment
___
Reply to this item at:
http://savannah.nongnu.org/bugs/?20142
___
Message sent via/by Savannah
http://savannah.nongnu.org/
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
Re: [bug #20142] strip backslash in rfc822 From: field
Here's an unmangled copy of the patch. I think this works,
but the \ part acts a little weird during testing. (E.g. if I
run -editidx I can fix an index page, but I can't seem to break it
again if I change the code back)
-Jeff
# diff -u /var/tmp/mhutil.pl /usr/share/mhonarc/mhutil.pl
--- /var/tmp/mhutil.pl 2007-10-09 20:30:36.0 -0700
+++ /usr/share/mhonarc/mhutil.pl2007-10-09 22:05:59.0 -0700
@@ -177,6 +177,7 @@
next if $skip;
if ($tok =~ /^/) { # Quoted string
$tok =~ s/^//; $tok =~ s/$//;
+$tok =~ s/\\(.)/$1/g; $tok =~ s/\\\/\/g;
return $tok;
}
if ($tok =~ /^\(/) { # Comment
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
Re: [bug #20142] strip backslash in rfc822 From: field
Ah, now I understand. This is the right patch.
# diff -u /var/tmp/mhutil.pl /usr/share/mhonarc/mhutil.pl
--- /var/tmp/mhutil.pl 2007-10-09 20:30:36.0 -0700
+++ /usr/share/mhonarc/mhutil.pl2007-10-09 22:05:59.0 -0700
@@ -177,6 +177,7 @@
- Hide quoted text -
next if $skip;
if ($tok =~ /^/) { # Quoted string
$tok =~ s/^//; $tok =~ s/$//;
+$tok =~ s/\\(.)/$1/g;
return $tok;
}
if ($tok =~ /^\(/) { # Comment
-
To sign-off this list, send email to [EMAIL PROTECTED] with the
message text UNSUBSCRIBE MHONARC-DEV
Accepted perceptualdiff 1.0.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 28 Sep 2007 14:52:18 -0700 Source: perceptualdiff Binary: perceptualdiff Architecture: source i386 Version: 1.0.1-1 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: perceptualdiff - perceptual image comparison tool Changes: perceptualdiff (1.0.1-1) unstable; urgency=low . * Initial release Files: f1085ac58d721a3693d08bcb67d430e7 637 utils optional perceptualdiff_1.0.1-1.dsc 2f7d90f478036bb2184663e56e8b1d3b 32344 utils optional perceptualdiff_1.0.1.orig.tar.gz 7b1fa4a934a890563e06158bb38a7c88 13146 utils optional perceptualdiff_1.0.1-1.diff.gz 93122cf89a67a4c9521f627b2d304f2e 14598 utils optional perceptualdiff_1.0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFG/aWvazfo3TSzaFYRAlmtAJsHHm2OAmY3/wTSggTFf3iOrtDbGgCgjm36 2riSbXHBVgnOHXmu8MgeKc8= =zUxd -END PGP SIGNATURE- Accepted: perceptualdiff_1.0.1-1.diff.gz to pool/main/p/perceptualdiff/perceptualdiff_1.0.1-1.diff.gz perceptualdiff_1.0.1-1.dsc to pool/main/p/perceptualdiff/perceptualdiff_1.0.1-1.dsc perceptualdiff_1.0.1-1_i386.deb to pool/main/p/perceptualdiff/perceptualdiff_1.0.1-1_i386.deb perceptualdiff_1.0.1.orig.tar.gz to pool/main/p/perceptualdiff/perceptualdiff_1.0.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Mailman-Developers] Improving the archives
Question: what about crossposted messages? Let's say a message gets sent to a list called mailman-developers with a CC to a list called pet-bunnies. Hypothetically, of course. Presumably, the person who got the message from pet-bunnies should probably end up at the pet-bunnies archive, where the message can be viewed in proper context; right before the processed carrots flamewar and after the manifesto on proper hopping technique. To make that work, I think we need some way to - at least optionally - allow one or more of the RFC 2369 headers to influence the archival URL. Reading the wiki, I guess that's where List-Archive comes into play? My other question is about the angle brackets. Barry, why are you inclined to include them in calculations? It's kind of arbitrary, but quoting RFC 2822, end of section 3.6.4: Semantically, the angle bracket characters are not part of the msg-id; the msg-id is what is contained between the two angle bracket characters. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
sleepy, minor request for help
Hi all, I messed up the file permissions when uploading a new package (jhove) to ftp-master, leading to package rejection. And I am too tired right now to go through the gpg-erific file deletion procedure to try again tonight. If there is a DD who has energy and is willing to complete the upload, I'd appreciate it. Otherwise I'll tackle this again some time tomorrow. Pointers below to the signed package and the unhappy file on ftp-master. Jeff === The file with bad read permissions: ftp://ftp-master.debian.org//pub/UploadQueuejhove_1.1g.orig.tar.gz/jhove_1.1g.orig.tar.gz The already signed package: http://www.jab.org/jhove ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Re: Joining pkg-java, and some package review requests
Varun, good to hear from you again. Welcome. --Jeff ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
new feature: hints
Remember the info pages? http://www.mail-archive.com/petbunny%40lsv.uky.edu/info.html If you squint carefully, you can see a new field called hints. So what's a hint? Hints are gentle way to tell the world what a list is about. Let's say you have a mailing list about pet bunnies. Then you add a hint called pet bunnies. This will make it a little easier for pet bunny lovers to find the archive. It will also help target any advertisements for things like carrots instead of linux kernel hacking jobs. And maybe other good uses in the future. Hints are optional, but please try it out if you get a chance. A good hint is one that you could type into a global search engine, and would be happy to see the list archive as a result. So pet bunnies is a good hint, Mr. Snuggles is having a pwarty! is not so good. By the way, you now know my favorite list archive of all time. I currently have the hints set to be world editable (except for a few I've personally set by hand) and we'll see how that works out. If there is a spam problem we'll do something different. Have fun, Jeff -- To unsubscribe, send mail to [EMAIL PROTECTED]
[bug #18113] inconsistant thread slices w/ poor man's windowing
Follow-up Comment #3, bug #18113 (project mhonarc): I ran on a handful of list messages (10 of them) and added them to a mhonarc archive one at a time, with MAXSIZE set to 3. This version preserved the thread slices, while 2.6.16 pretty much clobbered the thread slices. Looks good to me. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?18113 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #20142] strip backslash in rfc822 From: field
Follow-up Comment #4, bug #20142 (project mhonarc): I've placed a sample of raw messages at the following location. It is encrypted to the mhonarc signing key and is representative of production traffic. Maybe the size is a little bit of overkill for this particular problem, but the dataset might be useful for other problem cases as well. Once the dataset is received, yell and I'll delete it. To find relevent messages in this dataset, use the grep command described in one of the other comments. http://www.mail-archive.com/mail-sample.bz2.gpg ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20142 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [Mailman-Developers] Improving the archives
What we really want to know is how many (non-empty) Message-ID collisions are there that *don't* share a Date? This is the number of messages that only-messageid loses, and that the composite identifier method would not lose. I took a look at a larger dataset, 5.85 million messages from several thousand lists. Of the messages that share message-id but not date, most come from a small number of based web services. 875 come from forums.slimdevices.com 378 come from lists.openplans.org 265 come from nabble.com 164 come from egroups.com 135 come from yahoo.com 166 come from elsewhere That's 0.03% if you count all the messages. It is 0.008% if you discard the top three offenders, all of which I have contacted. I didn't try contacting Yahoo/eGroups because in my past experience, talking to a brick wall is easier. I have not analyzed how many of these messages are spam or have duplicate bodies, which further discounts the percentages. Hope this data helps. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
704 messages fall into this category. Of these, 596 come from a single (malfunctioning and duplicate spewing) list server. I have not yet examined the remaining 208 messages, but I'll bet anything many also have duplicate message bodies. Or are spam. So for this data set, we have an upper bound of 0.01% messages in this category, possibly significantly less. Correction. ... remaining 108 ... 0.005% ... ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
What we really want to know is how many (non-empty) Message-ID
collisions are there that *don't* share a Date? This is the number of
messages that only-messageid loses, and that the composite identifier
method would not lose.
It took longer than expected, but I now have numbers from
looking at 2,151,896 messages spread over a few thousand
lists. The appended script was run over a set of MH format
raw messages.
704 messages fall into this category. Of these, 596 come from a
single (malfunctioning and duplicate spewing) list server. I have
not yet examined the remaining 208 messages, but I'll bet anything
many also have duplicate message bodies. Or are spam. So for this
data set, we have an upper bound of 0.01% messages in this
category, possibly significantly less.
Jeff
#!/bin/bash
#
# Look for messages that
#
# Do collide with message-id
# Don't collide with message-id + date
DIR=/home/archive/Mail
C1=0
C2=0
get_ineresting_messages() {
cd $DIR/$1
for j in $(ls -U); do
MSG_ID=$(cat $j | 822field message-id)
MSG_DATE=$(cat $j | 822field date)
if [ $MSG_ID != ]; then
echo $MSG_DATE | $MSG_ID
fi
done |\
sort |\
uniq --separator='|' --skip-fields=1 --all-repeated |\
uniq --uniq
}
for i in $(ls $DIR | grep @); do
DUP=$(get_ineresting_messages $i)
DUP_CNT=$(echo -n $DUP | wc -l)
MSG_CNT=$(cd $DIR/$i ls -U | wc -w)
C1=$(( C1 + MSG_CNT ))
C2=$(( C2 + DUP_CNT ))
if [ $DUP_CNT != 0 ]; then
echo
echo === collisions/messages: $C2/$C1 $i
echo $DUP
else
echo -n . 12
fi
done
-Dale
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/jeff%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
[bug #20142] strip backslash in rfc822 From: field
Follow-up Comment #2, bug #20142 (project mhonarc): This is super useful, and really comes into play for us on $FROMNAME$. Everything else can essentially stay the same. In particular, $SUBJECT$ will quite often have unescaped backslashes, for example, a message talking about Windows software might contain C:Progam Fileswhatever So I admit a hack to fix ( ) on $FROMNAME$ isn't pretty, but it would be super useful and if I had a pointer on where to insert it, I'd be happy to attempt this patch myself. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20142 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #18113] inconsistant thread slices w/ poor man's windowing
Follow-up Comment #1, bug #18113 (project mhonarc): I wonder how hard this is. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?18113 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #19142] Right-to-left paragraphs not aligned to the right
Follow-up Comment #1, bug #19142 (project mhonarc): I'm interested in right-to-left as well, but how would the parser detect that the paragraph is RTL? Is the only way to do this by analyzing the character set or are there other indicators? And if it is by character set, can web browsers be set to do this automatically (or through use of a special CSS file?) http://www.mail-archive.com/[EMAIL PROTECTED]/msg05948.html ___ Reply to this item at: http://savannah.nongnu.org/bugs/?19142 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #17563] mhonarc trashes malformed HTML
Follow-up Comment #1, bug #17563 (project mhonarc): We don't bother with HTML mail any more when there's any choice in the matter, so not so important to us. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17563 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
[bug #18112] SPAMMODE produces broken links
Follow-up Comment #2, bug #18112 (project mhonarc): The work around for this is - for us - is to detect and kill off this type of broken at serving time. So not so critical from my perspective. ___ Reply to this item at: http://savannah.nongnu.org/bugs/?18112 ___ Message sent via/by Savannah http://savannah.nongnu.org/ - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [Wesnoth-dev] Soul shooter - Aptrgangr : please revert it
Dreadnotch ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Mailman-Developers] Improving the archives
If you improve the script or find numbers that lead to different conclusions, now's the time to know! Live and learn! So I just looked at 2 million raw messages from 2007, spread over a few thousand mailing lists (all data is from mail-archive.com). My first question was - when comparing only with messages from the same list - how many times do I see a repeated message-id? The answer was ... drumroll please ... 260 thousand. What the hell? Time for a closer look. In some cases, the archiver was getting two copies of every message. For example, the MLM (mailman) was sending out a message to subscriber A and subscriber B, and both paths eventually lead to the archiver. In another case, the MLM (YahooGroups) spammed 20 copies of the same message to every subscriber, and modified the body of each one. YahooGroups tends create HTML mail and sticks ads, possibly spyware, and who knows what other crap in message footers. There's probably other categories I haven't noticed yet, 260k messages is a lot of checking. So you'd think the archives would be a complete mess. But they aren't and I had no idea anything was remotely amiss under the hood. That's because mhonarc only archives one message per message-id. So those 19 repeats from YahooGroups get thown away. This is actually a pretty robust strategy when you think about it; it keeps lots of annoyances out of archives and everyone who gets smited deserves it; accidental duplicates, malicious duplicates, broken mail transfer agents. Reasonable people can disagree, but I like it. So I'm amending my request. If mailman and pipermail++ want to keep a verbatim record of everything passing through the MLM, fine. But please make it also possible to interoperate with archivers that use the looser mhonarc strategy, e.g. allow the interoperability URL to collide when message-ids collide. Currently Stephen's proposal allows this, Barry's does not. Just to make things really concrete, here's an example from that YahooGroups collision I was describing. The 20 messages spammed to subscribers would all have a interoperability URL something like this (but perhaps not quite so enormously long) embedded in the message, in both headers and possibly a footer. http://www.mail-archive.com/search?l=estika%40yahoogroups.comq=3578.125.161.129.196.1175036508.CBNWebMail%40webmail1.cbn.net.id Clicking on it, the user goes to the archive server. For this particular archiver, an HTTP 302 redirect takes the user to another URL which happens to be more human friendly. But the details of what alternate URLs are available - if any - is really up to the archive server. http://www.mail-archive.com/[EMAIL PROTECTED]/msg01341.html I think that's about it. I do kind of like Stephen's suggestion of allowing the archiver to supply a formuia for interoperability URL; if that's the case I'd say the RFC2369 headers could be fair game for use in the calculation. That allows cross posted messages to easily link to their correct archive - note how I used the contents of List-Post when creating the interoperability URL above. Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
If you are relying on the sender to do the right thing, then why not force them to create proper message-ids? I think Barry's proposal is essentially a numbers game - e.g. he's hoping for significantly better results using Date in the calculation than not using it. http://wiki.list.org/display/DEV/Stable+URLs I'll try to tease out some more useful stats from some large datasets this weekend. (I can't just run the python scripts as is because I don't have python 2.5 in the same place as the data, I don't keep raw message in mbox format, blah blah blah, but we'll figure it out). My hypothesis is Date doesn't really buy much, but that's in part because I have a vested interest in that outcome. We'll see how the data plays out. And I still think RFC2369 headers are needed in the calculation if cross posted messages are to be handled correctly. Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
Notice that of 325146 total messages, 624 of them had no message-id header. Even if you aggregate dup+col, you're still looking at a total duplicate rate of 0.29%. Message ID's are supposed to be unique. This is discussed in in RFC 822: 4.6.1 and RFC 1036: 2.1.5, and probably other places. If that's not the case, the mail transfer agent is broken. I think it's better to go ahead and use the mesage-id, rather than concoct yet another this time we mean it! unique identifier. This is a cost/benefit thing; the cost is some real world collisions, the benefit is a conceptually simpler system. Conceptually simpler things are good especially when implemented all over the place. Which brings me to suggestion #2, which is go ahead and write an RFC on how list servers should embed archival links in messages. This sounds like an internet wide interoperability issue as much as something mailman specific. Why not come up with a scheme usable by all list servers? And also describe a specification third party archival services can comply to. Besides, I've always wanted to help write an RFC. If we go that route, it would be good to get input from a range of people - one person I'd suggest is Earl Hood, author of mhonarc. Thoughts? Jeff While I'm almost tempted to ignore a hit rate that low, if you think of an archive holding 1B messages, you still get a lot of duplicates. OTOH, the rate goes down even lower if you consider the message-id and date headers. (Note, I did not consider messages missing a date header). How likely is it that two messages with the same message-id and date are /not/ duplicates? Heck, at that point, I'd feel justified in simply automatically rejecting the duplicate and chucking it from the archive. I spent a /little/ time looking at the physical messages that ended up as true collisions. Though by no means did I look at them all, they all looked related. For example, with strategy 2 some messages look like they'd been inadvertently sent before they were completed. I need to see if there's any similarities in MUA behind these, but again, I think we might be able to safely assume that collisions on message-id+date can be ignored. That leads me to the following proposal, which is just an elaboration on Stephen's. First, all messages live in the same namespace; they are not divided by target mailing list. Each message has two addresses, one is the Message-ID and one is the base32 of the sha1 hash of the Message-ID + Date. As Stephen proposes, Mailman would add these headers if an incoming message is missing them, and tough luck for the non-list copy. The nice thing is that RFC 2822 requires the Date header and states that Message-ID SHOULD be present. Why the second address? First, it provides as close to a guaranteed unique identifier as we can expect, and second because it produces a nearly human readable format. For example, Stephen's OP would have a second address of mid '[EMAIL PROTECTED]' date 'Wed, 04 Jul 2007 16:49:58 +0900' # XXX perhaps strip off angle brackets h = hashlib.sha1(mid) h.update(date) base64.b32encode(h.digest()) 'RXTJ357KFOTJP3NFJA6KMO65X7VQOHJI' I like base32 instead of base64 because the more limited alphabet should produce less ambiguous strings in certain fonts and I don't think the short b64 strings are short enough to justify the punctuation characters that would result. While RFC 3548 specifies the b32 alphabet as using uppercase characters, I think any service that accepts b32 ids should be case insensitive. A really Postel-y service could even accept '1' for 'I' and '0' for 'O' just to make it more resilient to human communication errors. I'd like to come up with a good name for this second address, which would suggest the name of the X- header we stash this value in. X- B32-Message-ID isn't very sexy. Maybe X-Message-Global-ID, since I think there's a reasonable argument to make that for well-behaved messages, that's exactly what this is. So now, think of the interface to a message store that supports this addressing scheme. Well it's something like: class MessageStore(Interface): def store_message(message): Store the message. :raises ValueError: when the message is missing either the Message-ID header or a Date header. :raises DuplicateMessageError: when a message in the store already has a matching Message-ID and Date. An archive is free to raise this exception for duplicate Message-IDs alone. def get_message_by_global_id(key): Locate and return the message from the store that matches `key`. :param key: The Global ID of the message to locate. This is the base32 encoded SHA1 hash of the message's Message-ID and Date headers. :returns: The message object matching the Global ID, or None if there is no such match.
Re: [Mailman-Developers] Improving the archives
There are three different parties coming to the table. One is the mail transfer agent of the sender, another is the list server, and the third is the archive server. Ideally, all three will be happy campers. So we just specify a header to put it in, and subscribers will be able to use it, per definition of a canonical URL. It is the archive server's job to decide what is the canonical URL for a message. There's a good chance these archival URLs will be served by an HTTP redirect. So let's not use the word canonical. :) What complexity? Mailman just does msg['X-List-Archive-Received-ID'] = Email.msgid() Easy to introduce, harder to deal with. The archival server would now keep track of both the message-id and the x-list-archive-received-id. That's two namespaces that almost do the same thing. It's easier for the archive server to keep track of one name space than two, and - most importantly - conceptually simpler. From the perspective of the assorted list servers, it's easier to do nothing than to do something. So if they can get by with just message-id (which is already implemented) not have to add x-list-archive-received-id, that's a smoother implementation path. If we base on message-id, archival servers will be able to retroactively add support for all their stored messages, even those that are ten years old. And users holding an old message will be able to figure out that URL without doing any computational gymnastics. Put another way, there's the possibility to reduce the archive servers' implementation to search for this mesage-id which is something really useful to have anyway, and therefore likely to get wider support. In addition, Barry was talking about concocting a unique identifier from the Date field and Message-ID. I'm not a big fan of this idea, because the date field comes from the mail user agent and is often wildly corrupt; e;g; coming from 100 years in the future. Very painful if the archive is showing most recent message first. Therefore an archival server is very likely to determine message date from the most recent received header (generally from a trusted mail transfer agent) rather than the date field. From the archive server's perspective, the best thing to do with the date field is throw it away. So for these reasons, I'd rather stick with message-id and risk some real world collisions, instead of introduce another identifier. If the list server receives a message with no message-id, by all means create one on the spot. To me, this feels like the sweet spot in terms of cost benefit. The main thing that bugs me is message-ids are long, which makes them awkward to embed in a URL in the footer of a message. Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
Regardless of whether we *need* to generate our own unique ID, I'm leaning towards the thought that we're going to *want* to generate our own for usability reasons. In a perfect world, i think we'd have a sequence number so I could visit http://example.com/mailman/ archives/listname/204.html and know that 205.html would be the next message to that list, but any short unique id would do if sequence numbers are too much of a pain. I agree there's a lot of usability benefits from short URLs, but perhaps this is the job of the archive server, and not the list server. Mharc (an archive server) is a great example here. Mharc's canonical message format is pretty human friendly. http://ww.mhonarc.org/archive/html/mharc-users/2002-08/msg0.html Unfortunately, there's no trivial way for the list server to know that human friendly URL when the message is sent out. Fortunately, Mharc is also happy handles messages by message-id, which the list server does know about. http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=mharc-users[EMAIL PROTECTED] Had I been the implementer, I'd probably have made mharc do an HTTP 302 redirect from the longer URL to the shorter URL. But that's besides the point. The point is we have an existing, working, happy archival server, and it would be really nice if list servers (such as mailman) were compatible. And by compatible, I mean offering the capability of embedding an archival URL in the footers of messages. -Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
What you gain from my proposal over a pure Message-ID approach
is guaranteed uniqueness given the list copy
Guarantee is a pretty strong word. A malicious person could post two
messages with the same message-id, same date, but different bodies.
Sometimes the channel between the MLM and the archive server will
be SMTP, and spurious messages can be injected. Finally, from the archive
server's perspective, some of the MLMs might make mistakes - just like
from the MLM's perspective, some of MTAs might make mistakes in
setting message-id. So I don't think the proposed SHA1(date, message-id)
scheme buys a hard guarantee of uniqueness. Every component has
to protect themselves, but none can solve the world's problems.
So that moves us to how many collisions are reduced in practice.
I have a question about the numbers Barry mined from the python
lists. Are the collisions really that high? One should not count
messages without a message-id, because the MLM can and should
create one in that case.
One should also not count collisions of messages going to different
lists. Here's why. Let's say message M is cross posted to lists L1 and
L2. Even though it is the same message, there are now two different
contexts. (For example, people visit M at archive L1 should get a
completely different experience if they hit next message and people
visiting M at archive L2.)
So I'd be curious what the collision numbers come to with these two
factors taken into account. The other takeaway is list name really
should be part of the URL to get proper context. The earlier example
from Mharc does this.
and human friendlier urls.
That's a very compelling point.
SHA1 can't be computed inside someone's head or simple cut-n-pasted
together for old messages, but I think the usability benefits of short
URLs (short enough that they can comfortably fit inside message bodies)
outweighs this drawback. By the way, is SHA-1 still in favor? My
impression was it was fading away after the Shandong University team
partially cracked it.
Throw it away or hide [Date]? The former would be a problem,
but not the latter.
Thrown away. My favorite archival service is based on mhonarc,
and raw mail goes into offline cold storage. Of course this can be
changed for the future messages with some pain, but there's no
reasonable way for myself (or any other mhonarc users in the
same predicament) to retrofit against Date based URLs. For the
record, here's what mhonarc embeds in each HTML page it
produces because these were considered the important headers.
In this message sent from Australia, the date shows a timezone
of UTC -0700, because it was pulled from the received header.
!-- MHonArc v2.6.15 --
!--X-Subject: [Gossip] Re: green#45;travel resources {webliographies} --
!--X-From-R13: [nephf Z. Saqvpbgg zraqvpbgNlnubb.pbz --
!--X-Date: Wed, 26 Apr 2006 00:27:27 #45;0700 --
!--X-Message-Id: [EMAIL PROTECTED] --
!--X-Content-Type: text/plain --
!--X-Reference: [EMAIL PROTECTED] --
!--X-Head-End--
So my main request is to double check the numbers, see if using
Date really buys as much as one thinks. I'll keep digesting the
other aspects of the wiki page.
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
change of pace
As you may know, The Mail Archive has been an advertising supported service for several years now. We have recently decided to shift things around a bit. We are completely removing advertising for regulars. This includes list admins, list members and lurkers - anyone that uses The Mail Archive directly. We'll keep and experiment with advertising only on pages viewed by fly by visitors that show up from off-site searches. We think this will improve the experience for all of you, and for all of your mailing list's readers. Note that this means you should be seeing The Mail Archive ad-free automatically now. The idea is to enhance usability for people more deeply involved with lists, with the costs covered by those remaining folks who likely don't care as much. Are people generally happy with the idea? Any comments or questions? Cheers, Jeff -- To unsubscribe, send mail to [EMAIL PROTECTED]
Re: [Mailman-Developers] Improving the archives
Maybe a way to think about this is that the canonical url is based on the message-id, but then there's some way to distill even this down to a tinyurl or simple integer that would be stable in the face of full archive regenerations. I'd suggest the reverse. Keep the canoncical archive URL short and sweet, and then use a URL redirection service to map message-id's to those URLs. It is the archiver's job to make it all work. For example, the canonical archive URL might stay exactly the way it is in pipermail. But the archival link embedded in the message would instead go to a redirection service. http://mail.codeit.com/pipermail/zcommerce/2002-February/000523.html http://mail.codeit.com/[EMAIL PROTECTED] The one other thing I'd ike to revisit is integration with third party archival services. There are two obvious integration points; one is a button in the Mailman list admin user interface that says archive with service X not unlike the setting in Firefox that basically says search with service X. The other integration point is the archival link discussed above. In which case it would be set to something like. http://third-party-service/[EMAIL PROTECTED] Disclosure: I help run a third party archiving service, and this topic was discussed quite a bit previously. [1] Nonetheless it seems like a good time revisit given the current discussion about archive wishlists. [1] http://www.mail-archive.com/mailman-developers@python.org/msg08772.html ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Improving the archives
In which case [the message body link] would be set to something like. http://third-party-service/[EMAIL PROTECTED] Just for fun, I did a trial implementation. It works, but the URLs are too long. For example, the URL below spends 59 characters on the messag-id, and 27 characters on the listname. We're already over my comfort level (of about 72 characters) and haven't even started to count the hostname, and other URL-lengthening overhead. Maybe this was a bad idea after all. http://www.mail-archive.com/search?l=mailman-developers%40python.org[EMAIL PROTECTED] Jeff ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [bug #20252] [gnu.org #336933] RFC2047 header encoding bug
[ -savannah because I am lazy ] Ok, well we do have proof that mhonarc is capable of doing the right thing on the exact same message. I use the TEXTENCODE resource to send everything to UTF-8, which is probably the recommended mhonarc way of doing things these days anyway. http://www.mhonarc.org/MHonArc/doc/resources/textencode.html http://www.mhonarc.org/MHonArc/doc/rcfileexs/utf-8-encode.mrc.html So while one could dive in deep and try to figure out what is going on, another choice is just try TEXTENCODE and see if it all magically works. And if so, tell the bug tracking system. If that doesn't do the trick, I don't know what to say other than works for me. - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Re: [bug #20252] [gnu.org #336933] RFC2047 header encoding bug
I don't have a mhonarc install to test it. Is it possible to install and process a single message right-away without setting up MTA integration, etc? Yes. As a side note #1 I have the names of 564 gnu.org and nongnu.org mailing lists that have been hand checked and determined to be completely overrun by spam. Is there anyone at the FSF I should give these to? Side note #2 is mail-archive.com has kept secondary archives for FSF lists with permission for some time now. If it was helpful, we'd be happy to add FSF branding to those archives and swap primary/secondary roles with the FSF maintained archives. Cheers, Jeff - To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV
Bug#424471:
Rmic has apparently drifted in and out of kaffe/GNU classpath over time. I say we just wait for GPL Sun Java and fix it then. Or punt the Lucene package for Lucene2 if dependencies allow it, and Lucene2 gets into main (again, depending on GPL Sun Java) ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
Bug#424471:
Rmic has apparently drifted in and out of kaffe/GNU classpath over time. I say we just wait for GPL Sun Java and fix it then. Or punt the Lucene package for Lucene2 if dependencies allow it, and Lucene2 gets into main (again, depending on GPL Sun Java) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424471:
Rmic has apparently drifted in and out of kaffe/GNU classpath over time. I say we just wait for GPL Sun Java and fix it then. Or punt the Lucene package for Lucene2 if dependencies allow it, and Lucene2 gets into main (again, depending on GPL Sun Java) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted leptonlib 1.45-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 1 Jun 2007 13:59:43 -0700 Source: leptonlib Binary: libleptonica leptonica-progs libleptonica-dev Architecture: source i386 Version: 1.45-1 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: leptonica-progs - sample programs for Leptonica image processing library libleptonica - image processing library libleptonica-dev - image processing library Changes: leptonlib (1.45-1) unstable; urgency=low . * New upstream release Files: 9daf6949f8ab2f2d92b605f7eac37bfa 646 graphics optional leptonlib_1.45-1.dsc 20e47724dcfd6a3933695e41a78cc9bc 2889746 graphics optional leptonlib_1.45.orig.tar.gz 997d9193d83eed7526c3fa86bbc0bf23 5691 graphics optional leptonlib_1.45-1.diff.gz 6d9adc4bcd619f11ef37732ac18fba0f 516794 libdevel optional libleptonica-dev_1.45-1_i386.deb 75f3f5863b3dc594cb0c6dff66cccf31 333764 libs optional libleptonica_1.45-1_i386.deb 8ef045a294e05a05c6bfc66b0683a708 61248 graphics optional leptonica-progs_1.45-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFGYJN+azfo3TSzaFYRAtaZAKCy3A2Cuq2oevgBdwwA2X8s9r97GwCeJRV2 uLL99GfNAkcxyOB6fuZSwlE= =uSy0 -END PGP SIGNATURE- Accepted: leptonica-progs_1.45-1_i386.deb to pool/main/l/leptonlib/leptonica-progs_1.45-1_i386.deb leptonlib_1.45-1.diff.gz to pool/main/l/leptonlib/leptonlib_1.45-1.diff.gz leptonlib_1.45-1.dsc to pool/main/l/leptonlib/leptonlib_1.45-1.dsc leptonlib_1.45.orig.tar.gz to pool/main/l/leptonlib/leptonlib_1.45.orig.tar.gz libleptonica-dev_1.45-1_i386.deb to pool/main/l/leptonlib/libleptonica-dev_1.45-1_i386.deb libleptonica_1.45-1_i386.deb to pool/main/l/leptonlib/libleptonica_1.45-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted leptonlib 1.45-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 1 Jun 2007 15:56:49 -0700 Source: leptonlib Binary: libleptonica leptonica-progs libleptonica-dev Architecture: source i386 Version: 1.45-2 Distribution: unstable Urgency: low Maintainer: Jeff Breidenbach [EMAIL PROTECTED] Changed-By: Jeff Breidenbach [EMAIL PROTECTED] Description: leptonica-progs - sample programs for Leptonica image processing library libleptonica - image processing library libleptonica-dev - image processing library Changes: leptonlib (1.45-2) unstable; urgency=low . * Add sample images Files: c36470bb9ca5350b032aad5cd629e82d 579 graphics optional leptonlib_1.45-2.dsc ea9d36e1e5db3b15bff26fd1913d2f01 2885649 graphics optional leptonlib_1.45-2.tar.gz 9d0b0686c615c0a62ea4595c0d4e7596 719874 libdevel optional libleptonica-dev_1.45-2_i386.deb 411a5afcbef4c43c7193a80b3b02c3fc 333800 libs optional libleptonica_1.45-2_i386.deb afaf55a750ed0408c9e613b434505d6f 61278 graphics optional leptonica-progs_1.45-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFGYKYSazfo3TSzaFYRAiScAJwKw1hugntJ1RnkZ+D1FRz6J41q0ACeL823 91fdGkN0atCB/myHOK1AX30= =6mTF -END PGP SIGNATURE- Accepted: leptonica-progs_1.45-2_i386.deb to pool/main/l/leptonlib/leptonica-progs_1.45-2_i386.deb leptonlib_1.45-2.dsc to pool/main/l/leptonlib/leptonlib_1.45-2.dsc leptonlib_1.45-2.tar.gz to pool/main/l/leptonlib/leptonlib_1.45-2.tar.gz libleptonica-dev_1.45-2_i386.deb to pool/main/l/leptonlib/libleptonica-dev_1.45-2_i386.deb libleptonica_1.45-2_i386.deb to pool/main/l/leptonlib/libleptonica_1.45-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
armel disk image
On 4/26/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Jeff Breidenbach [EMAIL PROTECTED] [2007-04-10 22:53]: Yes, yes, please put up a nslu2 disk image!! I want to see if I can get a working debian Install. My spare nslu2 accidentally got left in a remote datacenter. So it will be some time before I can actually do this. Maybe someone else will oblige in the meantime. I have done this now: http://www.cyrius.com/debian/nslu2/unpack.html Ok, I made one too, which has a few less steps than Martin's version at the cost of some flexibility. Here's the completely untested recipe. 1 Get an nlsu2 2 Get a fast, reliable 2GB flash drive (I used Corsair Flash Voyager GT) 3 Get a Debian or Ubuntu desktop computer 4 apt-get install dd_rescue upslug2 5 Download armel-2gb.img.gz 6 Download armel-firmware.bin 7 Image the flash drive using your desktop computer a Figure out where the drive is; in this example /dev/sde b Double check you aren't about to toast your hard drive c zcat armel-2gb.img.gz | dd_rescue - /dev/sde 8 Put nslu2 in firmware upload mode 9 upslug2 -i armel-firmware.bin That's it. Combine the flashdrive and the nslu2 and it should boot to DHCP networking. The root password is changeme, and you should probably adjust your timezone (tzconfig) and make a user account. Now I need three things - help. 1) A website to post armel-2gb.img.gz. This is presumably contaminated with the proprietary network driver, so it should be behind one of those stupid click-through license agreements. There's already similar armel stuff at http://www.slug-firmware.net - can someone with a connection there help me? This is a ~150MB file. 2) I don't actually know how to pull off the firmware currently flashed to the nslu2. That means I don't have a copy of armel-firmware.bin mentioned in the instructions. How do I do that? I presumably would dump a copy of this on the same website as the armel-2gb.img.gz. Although if it isn't contaminated by the proprietary ethernet driver, I can easily find a home for it. (Joey: is it contaminated or not?) 3) I should put these instructions on a wiki or something so that users can make notes when or if they run into problems. Can some existing Linux / Debian / NSLU provide a wiki page I can edit? I don't really want to run my own wiki. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: armel disk image
Intel proprietary microcode for the on-chip NPE engines Any chance of Intel opening up the microcode? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: success report, armel on nslu2
Cool! But that's still a fair number of steps. Why not create nslu2.img and write it to the disk with dd? My nslu2 is still stranded in a datacenter cabinet in Fremont, so I can't try it myself and find out why it doesn't work. Jeff On 4/26/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Jeff Breidenbach [EMAIL PROTECTED] [2007-04-10 22:53]: Yes, yes, please put up a nslu2 disk image!! I want to see if I can get a working debian Install. My spare nslu2 accidentally got left in a remote datacenter. So it will be some time before I can actually do this. Maybe someone else will oblige in the meantime. I have done this now: http://www.cyrius.com/debian/nslu2/unpack.html If someone could check my instructions, I'd appreciate it. It's possible I forgot to mention something. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
