: MIT
Programming Lang: C
Description : Alert when your machine is becoming over-saturated
psi-notify is a minimal unprivileged notifier for system-wide resource pressure
using PSI. This can help you to identify misbehaving applications on your
machine before they start to severely impact
Package: wnpp
Severity: wishlist
Owner: James Richardson <j...@mesrichardson.com>
* Package name: elpa-mu4e-alert
Version : 1.0
Upstream Author : Iqbal Ansari <iqbalansar...@yahoo.com>
* URL : https://iqbalansari/mu4e-alert
* License : GPL v3
Prog
Votre compte AccesD de Desjardins a été placer sous surveillance.
Un examen récent de votre compte en ligne AccèsD déterminé que nous avons
besoin de quelques informations supplémentaires de votre part afin de vous
fournir un service sécurisé.
Comment vérifier votre compte en ligne AccèsD de
Description : A small library to manipulate the favicon
Tinycon adds an alert bubble to the favicon containing a small amount of
text. It also supports numeric contents up to 2 digits, automatically
truncating using a metric suffix (k, M, G) when it gets too large to
fit
As you know the world's biggest branding revolution starts January 2012.
What direct implications does it have for your organization? What do your teams
need to know now and what must they be prepared for in advance to face the
tidal wave?
This White Paper provides an in-depth overview and
* Ben Hutchings b...@decadent.org.uk, 2011-04-23, 15:06:
[...]
=== version, strings longer than 30 (unique ones) ===
0.9.15+post20100705+gitb3aa806-2
0.0.0+git20091215.9ec1da8a-2+b2
1.0.0~alpha3~git20090817.r1.349dba6-2
1:2.5.0~alpha4+svn20091009-1+b2
2.1.14+2.6.32.13-201005151340-1
Hi,
On Wed, Apr 27, 2011 at 03:11:14PM -0300, Henrique de Moraes Holschuh wrote:
On Tue, 26 Apr 2011, Uoti Urpala wrote:
...
It is still not a good reason to waste part of a draconian 30 chars of space
with hash information.
I agree.
Anyway, I think 30 should be the absolute upper limit for
Osamu Aoki dijo [Thu, Apr 28, 2011 at 11:55:48PM +0900]:
(...)
1.2.10~YYMMDD for prerelease of version 1.2.10
1.2.10~rcYMMDD for prerelease of version 1.2.10 (alternative format)
this last 2 are mostly used in unstable/testing only. So length is
less of problem.
Remember that
Henrique de Moraes Holschuh hmh at debian.org writes:
I do think you misunderstood my point in the hash issue. My point is not
that a full hash will not collide. The point is that the full hash as seen
in a tree received from the upstream DVCS should not see colisions, because
the collision
On Sat, Apr 23, 2011 at 06:31:38PM +0900, Osamu Aoki wrote:
Hi,
In order to manage package file name length below 90 and to have sane
screen for package management, may I suggest to recommend some limits
(for lintian check etc.):
* package name string should be less than 40 characters.
*
On Tue, Apr 26, 2011 at 07:31:22PM -0400, James Vega wrote:
On Tue, Apr 26, 2011 at 10:28:07PM +0900, Osamu Aoki wrote:
In this sense, most reasonable solution seems to me
0.YYMMDD
This way, when ever upstream decide to release package with sane
versioning (usually bigger than 1.)
On Tue, Apr 26, 2011 at 07:31:22PM -0400, James Vega wrote:
Why assume the first version will be = 1.x? It's not uncommon to use
0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
needing an epoch if/when upstream starts using actual version numbers.
~ sorts after ., so
Jon Dowland j...@debian.org (27/04/2011):
~ sorts after ., so 0~110427 will be considered newer than 0.1.
Therefore, the 0 in 0~YYMMDD is meaningless, and would be no better
than ~YYMMDD (which would still sort after 0.1, and require an
epoch).
$ dpkg --compare-versions 0~110427 '' 0.1 echo
On Wed, Apr 27, 2011 at 04:09:48PM +0100, Jon Dowland wrote:
~ sorts after ., so 0~110427 will be considered newer than 0.1.
Therefore,
the 0 in 0~YYMMDD is meaningless, and would be no better than ~YYMMDD (which
would still sort after 0.1, and require an epoch).
From Policy [1], ~ sort
On Tue, 26 Apr 2011, James Vega wrote:
Why assume the first version will be = 1.x? It's not uncommon to use
0.x. Using 0~YYMMDD seems a safer option to reduce the chance of
needing an epoch if/when upstream starts using actual version numbers.
The 0.DATE thing is from before we had support
On Tue, 26 Apr 2011, Uoti Urpala wrote:
This branch of the thread was NOT about packages that use date ONLY. Maybe
that's what you were confused about above? The version would still need the
last release name too, as in 15.3.2~rc3+svn2005010112.
The two possibilities showed up in the
On Tue, 26 Apr 2011, Uoti Urpala wrote:
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're
On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
On Tue, 26 Apr 2011, Chow Loong Jin wrote:
On 26/04/2011 01:50, Gunnar Wolf wrote:
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at,
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Uoti Urpala wrote:
Using date and time as a version is not current best practice. You'll still
need the upstream version part too to sort correctly relative to released
versions.
I was refering to the full commit
On Tue, Apr 26, 2011 at 10:28:07PM +0900, Osamu Aoki wrote:
In this sense, most reasonable solution seems to me
0.YYMMDD
This way, when ever upstream decide to release package with sane
versioning (usually bigger than 1.) within 8 chars and we can continue
without epoch. But this is
Ben Hutchings dijo [Sun, Apr 24, 2011 at 04:54:46AM +0100]:
If you use git describe, removing hashes is a bad idea.
They are needed to identify the version. Version numbers that are not
unique are worthless.
If versions are not ordered without the inclusion of a commit hash, they
are
On 26/04/2011 01:50, Gunnar Wolf wrote:
[...]
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at, mid-devel-cycle
breakage should be at a minimum. So, instead of basing our packages
off arbitrary commit hashes, why not
On Tue, 26 Apr 2011, Chow Loong Jin wrote:
On 26/04/2011 01:50, Gunnar Wolf wrote:
Anyway - Summing up what I'm saying here, tags have a clear meaning: A
point where upstream wants us to base our efforts at, mid-devel-cycle
breakage should be at a minimum. So, instead of basing our packages
On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
[...]
Then, you use UTC date+time, that's two digits for the
best-practice leading of 0., plus 13 digits for MMDDTHHMM,
which is quite precise enough most of the time. Add two more for
seconds, and it is almost
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the
On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote:
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of
On Mon, Apr 25, 2011 at 10:29:53PM +0100, Ben Hutchings wrote:
On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote:
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote:
If versions are not ordered without the inclusion of a commit hash, they
are not ordered *with* it (except
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're being silly.
All you need is the proper date and time to use as a version (for
ordering), and a proper
Henrique de Moraes Holschuh hmh at debian.org writes:
On Tue, 26 Apr 2011, Adam Borowski wrote:
Telling someone the bug is in a version I pulled from the VCS but didn't
bother noting down which version it was is not very useful.
Now you're being silly.
All you need is the proper date
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered,
This seems like an
[Followup-To: nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern tr...@philkern.de schrieb:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff j...@inutil.org wrote:
Given that wheezy will probably be the last version that's strictly
greater than lenny and squeeze we should switch to Debian version
numbers in the version instead of
* Philipp Kern [2011-04-24 10:23 +]:
(OTOH it needs to be greater than +squeeze then, so +debXY won't do.)
It needs to be greater than +squeeze, smaller than . and must not
contain -.
/usr/bin/ascii prints:
|Dec Hex
| 43 2B +
| 44 2C ,
| 45 2D -
| 46 2E .
,debXY would do, but would require
[ dropping debian-cd@ from CC ]
On 2011-04-24 11:59, Philipp Kern wrote:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff j...@inutil.org wrote:
Given that wheezy will probably be the last version that's strictly
greater than lenny and squeeze
On Sun, 24 Apr 2011, Moritz Mühlenhoff wrote:
[Followup-To: nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern tr...@philkern.de schrieb:
[Followup-To: header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves d...@earth.li wrote:
On Sat, Apr 23, 2011 at
Hi,
In order to manage package file name length below 90 and to have sane
screen for package management, may I suggest to recommend some limits
(for lintian check etc.):
* package name string should be less than 40 characters.
* version name string should be less than 30 characters.
On Sat, 2011-04-23 at 18:31 +0900, Osamu Aoki wrote:
[...]
=== version, strings longer than 30 (unique ones) ===
0.9.15+post20100705+gitb3aa806-2
0.0.0+git20091215.9ec1da8a-2+b2
1.0.0~alpha3~git20090817.r1.349dba6-2
1:2.5.0~alpha4+svn20091009-1+b2
2.1.14+2.6.32.13-201005151340-1
Ben Hutchings b...@decadent.org.uk (23/04/2011):
I would like to see policy forbid the use of commit hashes in
versions. They aren't ordered, and the information about exactly
which commit the snapshot was can be included in the changelog.
I'll be happy to second any wording you could come up
On Sat, 23 Apr 2011, Cyril Brulebois wrote:
Ben Hutchings b...@decadent.org.uk (23/04/2011):
I would like to see policy forbid the use of commit hashes in
versions. They aren't ordered, and the information about exactly
which commit the snapshot was can be included in the changelog.
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered,
This seems like an odd reason to forbid them; should one also
forbid strings such as 'pre', 'rc', 'lenny', 'squeeze' in version
numbers
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the information about exactly which commit the
snapshot was can be included in the changelog.
If you use git describe, removing hashes
On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote:
On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
I would like to see policy forbid the use of commit hashes in versions.
They aren't ordered, and the information about exactly which commit the
snapshot was can be included
Hi,
On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre st...@einval.com wrote:
If we really want to meet the spec, we should be aiming for 64
characters, but that affects 98 packages and I'm not *too* bothered
about it since testing shows no issues thus far. I'm tempted to file:
*
On Sunday 10 April 2011 20:19:42 Toni Mueller wrote:
Hi,
On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre
st...@einval.com
wrote:
If we really want to meet the spec, we should be aiming for 64
characters, but that affects 98 packages and I'm not *too* bothered
about it since testing
Goswin von Brederlow goswin-...@web.de Sun, April 3, 2011 5:17:06 PM
Philipp Kern tr...@philkern.de writes:
On 2011-04-03, Wouter Verhelst wou...@debian.org wrote:
OTOH, do you really want to type
apt-get install package-with-policy-compliant-utterly-long-silly-name?
There's a point when
On Sat, Mar 26, 2011 at 08:56:14AM +0100, Raphael Hertzog wrote:
On Fri, 25 Mar 2011, Steve McIntyre wrote:
On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a
On 2011-04-03, Wouter Verhelst wou...@debian.org wrote:
OTOH, do you really want to type
apt-get install package-with-policy-compliant-utterly-long-silly-name?
There's a point when package name lengths become problematic, and that
isn't just true for ISO images.
That's why $DEITY invented tab
Philipp Kern tr...@philkern.de writes:
On 2011-04-03, Wouter Verhelst wou...@debian.org wrote:
OTOH, do you really want to type
apt-get install package-with-policy-compliant-utterly-long-silly-name?
There's a point when package name lengths become problematic, and that
isn't just true for
On Wed, Mar 30, 2011 at 06:16:12PM +0200, gregor herrmann wrote:
On Wed, 30 Mar 2011 11:56:22 +0100, Steve McIntyre wrote:
Right, that's certainly true for the lib.*-perl packages, and I
wouldn't know how we should rename them in a sane way.
In the worst case that I'm looking at, I'm a little
On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 30 Mar 2011, Steve McIntyre wrote:
I think so. The package with long names tend to follow a naming policy
that sort of imposes the long name... so if we put a too-short limit
then we're asking them to make an
On Thu, 31 Mar 2011, Steve McIntyre wrote:
On Wed, Mar 30, 2011 at 09:54:49AM -0300, Henrique de Moraes Holschuh wrote:
On Wed, 30 Mar 2011, Steve McIntyre wrote:
I think so. The package with long names tend to follow a naming policy
that sort of imposes the long name... so if we put a
Andreas Metzler ametz...@downhill.at.eu.org writes:
In gmane.linux.debian.devel.general Joey Hess jo...@debian.org wrote:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.
If I had to chose
On Sat, Mar 26, 2011 at 08:56:14AM +0100, Raphael Hertzog wrote:
On Fri, 25 Mar 2011, Steve McIntyre wrote:
On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a
On Sat, Mar 26, 2011 at 03:18:12PM +0100, gregor herrmann wrote:
On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote:
We already have arbitrary limits on filename length (~200 bytes or so
on RockRidge), even before this. I'm just proposing to lower them for
a common use case. Do we
On Wed, 30 Mar 2011, Steve McIntyre wrote:
I think so. The package with long names tend to follow a naming policy
that sort of imposes the long name... so if we put a too-short limit
then we're asking them to make an exception in the naming policy.
So what's a reasonable name length limit
On Wed, 30 Mar 2011 11:56:22 +0100, Steve McIntyre wrote:
Right, that's certainly true for the lib.*-perl packages, and I
wouldn't know how we should rename them in a sane way.
In the worst case that I'm looking at, I'm a little surprised by the
names here on two fronts:
Joey Hess jo...@debian.org writes:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.
If I had to chose between that working, and not needing to worry about
filename lengths, I'd choose the
Hi,
some technical facts about name lenght in Debian ISO 9660 images:
Raphael Hertzog wrote:
What happens if you try to put too-long filenames on the CD with Joliet
enabled?
libisofs, which produces the Debian i386 and amd64 images, truncates
oversized Joliet names. Collisions get resolved by
Hi!
Am 28.03.2011 11:23, schrieb Thomas Schmitt:
Test reports from reading such an ISO image by a real Windows machine
would be interesting ... :)
E.g. with a file name of 100 characters:
xorriso -as mkisofs -o test.iso -J -joliet-long -graft-points \
Hi,
Alexander Reichle-Schmehl wrote:
xorriso -as mkisofs -o test.iso -J -joliet-long -graft-points \
/012345678901234567890123456789012345678901234567890123456789012345678901234
5678901234567890123456789=/some/file/on/disk
Didn't worked over here with an uptodate Windows XP. It
Olaf van der Spek wrote:
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV jaq...@debian.org
wrote:
Olaf van der Spek wrote:
That's not our problem, is it?
It is, if we are trying to be as compatible as possible.
Compatible with what? Bugs in other implementations?
What does
In gmane.linux.debian.devel.general Joey Hess jo...@debian.org wrote:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.
If I had to chose between that working, and not needing to worry about
On Mon, 28 Mar 2011, John H. Robinson, IV wrote:
Olaf van der Spek wrote:
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV jaq...@debian.org wrote:
Olaf van der Spek wrote:
That's not our problem, is it?
It is, if we are trying to be as compatible as possible.
Compatible with what?
On Mon, Mar 28, 2011 at 6:43 PM, John H. Robinson, IV jaq...@debian.org wrote:
Compatible with what? Bugs in other implementations?
What does that really gain us?
The ability for the discs to be read on as many systems as possible. I'm
not going to pretend to know what all someone else may
Goswin von Brederlow wrote:
And how would users then get those files? If you have a kernel without
udf filesystem support then apt/aptitude/... would suddenly fail to find
some files. Same if udf isn't the default filesystem for cds.
That's what the Rock Ridge extensions are for.
--
see shy
On Fri, 25 Mar 2011, Steve McIntyre wrote:
On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.
If I had to chose between that working,
On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote:
We already have arbitrary limits on filename length (~200 bytes or so
on RockRidge), even before this. I'm just proposing to lower them for
a common use case. Do we really care about supporting *very* long
names here?
I think so.
On Sat, 2011-03-26 at 15:18 +0100, gregor herrmann wrote:
On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote:
We already have arbitrary limits on filename length (~200 bytes or so
on RockRidge), even before this. I'm just proposing to lower them for
a common use case. Do we
Am Freitag 25 März 2011, 21:59:31 schrieb Rene Engelhard:
Hi,
On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote:
On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote:
Hi,
On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
The longest is:
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV jaq...@debian.org wrote:
That's not our problem, is it?
It is, if we are trying to be as compatible as possible.
Compatible with what? Bugs in other implementations?
What does that really gain us?
--
Olaf
--
To UNSUBSCRIBE, email to
On Sat, 26 Mar 2011 14:32:27 +, Ben Hutchings wrote:
I think so. The package with long names tend to follow a naming policy
that sort of imposes the long name... so if we put a too-short limit
then we're asking them to make an exception in the naming policy.
Right, that's certainly
Hey folks,
I've noticed a problem recently in the archive when building CDs,
aggravated to a certain extent by the newer source formats. Some of
the filenames in the archive are getting *very* long, and this is
causing issues. As a matter of course, we build CDs with RockRidge and
Joliet support
On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
Hey folks,
I've noticed a problem recently in the archive when building CDs,
aggravated to a certain extent by the newer source formats. Some of
the filenames in the archive are getting *very* long, and this is
causing issues. As a
Hi,
On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
Debian LibreOffice Maintainers debian-openoff...@lists.debian.org
openoffice.org
Dead. Any anything there is just transitional packages you need tor
squeeze-wheezy upgrades, so need to stay. Is libreoffice also affected?
On Fri, Mar 25, 2011 at 03:50:32PM +0100, Rene Engelhard wrote:
Hi,
On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
Debian LibreOffice Maintainers debian-openoff...@lists.debian.org
openoffice.org
Dead. Any anything there is just transitional packages you need tor
On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre st...@einval.com wrote:
users. The problem is that Joliet has a limit for filename length (64
characters), and technically we're already past that length. From
genisoimage.1:
64 is quite low. Is there no way to use longer filenames that still
Steve McIntyre wrote:
I've noticed a problem recently in the archive when building CDs,
aggravated to a certain extent by the newer source formats. Some of
the filenames in the archive are getting *very* long, and this is
causing issues. As a matter of course, we build CDs with RockRidge and
Hi,
On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
The longest is:
libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb
at 71.
Good, then any bug against openoffice.org is not needed, as that obviously
will be + wontfix wheezy-ignore, because it simply
On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre st...@einval.com wrote:
64 is quite low. Is there no way to use longer filenames that still
works on all required platforms?
To do that, we'll have to switch to a different filesystem. That's a
possibility (maybe UDF), but there's probably even
On Fri, Mar 25, 2011 at 11:52:35AM -0400, Joey Hess wrote:
Steve McIntyre wrote:
I've noticed a problem recently in the archive when building CDs,
aggravated to a certain extent by the newer source formats. Some of
the filenames in the archive are getting *very* long, and this is
causing
On Fri, Mar 25, 2011 at 04:48:12PM +0100, Olaf van der Spek wrote:
On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre st...@einval.com wrote:
users. The problem is that Joliet has a limit for filename length (64
characters), and technically we're already past that length. From
genisoimage.1:
64
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.
If I had to chose between that working, and not needing to worry about
filename lengths, I'd choose the latter.
Is it possible to provide Joliet
On Fri, Mar 25, 2011 at 05:13:03PM +0100, Olaf van der Spek wrote:
On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre st...@einval.com wrote:
64 is quite low. Is there no way to use longer filenames that still
works on all required platforms?
To do that, we'll have to switch to a different
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre st...@einval.com wrote:
Why's that? Isn't UDF widely supported?
Implementations often widely differ in their limitations - see the
Wikipedia page for more details. The suggested way to make a safe UDF
DVD is often along the lines of use the
On 2011-03-25, Joey Hess jo...@debian.org wrote:
Is it possible to provide Joliet filenames for only a subset of files?
It is, yes. But not something I'd like to do if we can avoid it.
One approach then would be to omit joliet filenames for the few long
packages. This would not even impact
Olaf van der Spek wrote:
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre st...@einval.com wrote:
Why's that? Isn't UDF widely supported?
Implementations often widely differ in their limitations - see the
Wikipedia page for more details. The suggested way to make a safe UDF
DVD is often
On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote:
Hi,
On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
The longest is:
libreoffice-presentation-minimizer_1.0.3+LibO3.3.1-1_kfreebsd-amd64.deb
at 71.
Good, then any bug against openoffice.org is not
Hi,
On Fri, Mar 25, 2011 at 09:48:15PM +0100, Adam Borowski wrote:
On Fri, Mar 25, 2011 at 05:09:54PM +0100, Rene Engelhard wrote:
Hi,
On Fri, Mar 25, 2011 at 03:27:57PM +, Steve McIntyre wrote:
The longest is:
On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote:
Steve McIntyre wrote:
There are uses I've heard about, including (apparently quite common)
using CDs and DVDs to seed a mirror on a Windows server.
If I had to chose between that working, and not needing to worry about
filename lengths,
John H. Robinson, IV wrote:
Olaf van der Spek wrote:
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre st...@einval.com wrote:
Why's that? Isn't UDF widely supported?
Implementations often widely differ in their limitations - see the
Wikipedia page for more details. The suggested way to make
* License : Various
Programming Lang: Various
Description : contributed tools, monitors and alert for mon package
mon-contrib provides many user-contributed tools,
monitors, and alerts for mon package.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBCAAGBQJNV
these profile which kids who is missing, kindly forward to others
for help these kids and presnts
usha
-- Forwarded message --
From: Kids Missing kidsmiss...@gmail.com
Date: Sun, Nov 1, 2009 at 4:47 PM
Subject: [Kids Missing:/] Kids Missing Alert - 01 November 2009
To: kidsmiss
http://i83.imagethrust.com/i/1035857/dhg3.png
From the foregoing account it will be seen that in Newspeak the expression of
unorthodox opinions, above a very low level, was well-nigh impossible.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
http://imagecloset.com/uimages/viu1176820417f.png
Because all Agents defect and all Resisters sell out.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
An email message that you sent was undeliverable
The email header contained the following:
From: debian-devel-french@lists.debian.org
To: [EMAIL PROTECTED]
Subject: Re: Protected Mail System
The email has the following problem:
The email contained the virus:
==
Bapco detected hostile or unwanted content in this message.
If you believe this is in error, please resend the whole message to:
[EMAIL PROTECTED]
Please make sure that you specify the recipient email address(es) in
your message.
Your
The following message sent by this account has violated system policy:
From: debian-devel@lists.debian.org
To: [EMAIL PROTECTED]
Date: Wed, 22 Feb 2006 22:40:09 +0100
Subject: Re: Approved document
The following violations were detected:
--- Scan information follows ---
Virus Name: [EMAIL
Attenzione.
Il messaggio email inviato a questo indirizzo da debian-devel@lists.debian.org,
con oggetto Good day, conteneva un virus e pertanto è stato eliminato.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Attenzione.
Il messaggio email inviato a questo indirizzo da debian-devel@lists.debian.org,
con oggetto Good day, conteneva un virus e pertanto è stato eliminato.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Attachment file : body.scr
Virus name : W32/[EMAIL PROTECTED]
Action taken: Unable to Clean...
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
1 - 100 of 130 matches
Mail list logo
