** 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
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
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
(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
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
Forwarding to upstream.
-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
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]
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]
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]
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]
Help appreciated.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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.
-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
-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
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
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]
Uploaded.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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]
Uploaded.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
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
: 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
-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
-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
-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
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]
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]
-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
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
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]
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
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]
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
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
-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
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
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
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
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.
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
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]
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
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
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]
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
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
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
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
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
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
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
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
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
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
... 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]
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
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
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
-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
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.
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 =~ /^/) { #
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
---
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
-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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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:
Dreadnotch
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
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
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.
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
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
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
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
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
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
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.
[ -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.
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
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)
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
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
-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
-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
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
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]
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
901 - 1000 of 1614 matches
Mail list logo
