: 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
* Package name: elpa-mu4e-alert
Version : 1.0
Upstream Author : Iqbal Ansari
* URL : https://iqbalansari/mu4e-alert
* License : GPL v3
Programming Lang: lisp
Description : Desktop notifications
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.
--
To UNSUBSCRIBE, email to debian-devel-requ
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 can
* Ben Hutchings , 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
1:2.2cvs20100105-true-dfsg-5+b1
0
Henrique de Moraes Holschuh 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 wo
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 w
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 fo
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 thr
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 suppor
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], ~
Jon Dowland (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 "Jon
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 "0~1
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 big
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 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
Henrique de Moraes Holschuh 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 comm
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
On Tue, 26 Apr 2011, Uoti Urpala wrote:
> Henrique de Moraes Holschuh 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 yo
Henrique de Moraes Holschuh 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 da
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 de
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
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
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 th
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 alm
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 pa
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, wh
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
On Sun, 24 Apr 2011, Moritz Mühlenhoff wrote:
> ["Followup-To:" nach gmane.linux.debian.devel.general gesetzt.]
> Philipp Kern schrieb:
> > ["Followup-To:" header set to gmane.linux.debian.devel.general.]
> > On 2011-04-23, Dominic Hargreaves wrote:
> >> On Sat, Apr 23, 2011 at 03:06:39PM +0100,
[ 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 wrote:
> >> Given that wheezy will probably be the last version that's strictly
> >> greater than lenny and squeeze we sho
* 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
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2011-04-24, Moritz Mühlenhoff 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 codenames post-s
["Followup-To:" nach gmane.linux.debian.devel.general gesetzt.]
Philipp Kern schrieb:
> ["Followup-To:" header set to gmane.linux.debian.devel.general.]
> On 2011-04-23, Dominic Hargreaves wrote:
>> On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote:
>>> I would like to see policy forb
["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2011-04-23, Dominic Hargreaves 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 odd rea
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 in
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 ha
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 al
On Sat, 23 Apr 2011, Cyril Brulebois wrote:
> Ben Hutchings (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 t
Ben Hutchings (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 with on that
topi
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
> 1:2.2
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.
(securit
On Sunday 10 April 2011 20:19:42 Toni Mueller wrote:
Hi,
On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre
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 is
Hi,
On Fri, 25.03.2011 at 14:17:06 +, Steve McIntyre 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:
>
> * serious bugs on
Goswin von Brederlow Sun, April 3, 2011 5:17:06 PM
> Philipp Kern writes:
>
>> On 2011-04-03, Wouter Verhelst 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 problemati
Philipp Kern writes:
> On 2011-04-03, Wouter Verhelst 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
On 2011-04-03, Wouter Verhelst 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 completion.
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 DV
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 p
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
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
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:
> libcgi-applica
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 l
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
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
Andreas Metzler writes:
> In gmane.linux.debian.devel.general 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 needi
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 sh
On Mon, Mar 28, 2011 at 6:43 PM, John H. Robinson, IV 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 need to do wi
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 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 impl
In gmane.linux.debian.devel.general 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 leng
Olaf van der Spek wrote:
> On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV
> 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 that r
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 X
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 \
>
> /01234567890123456
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 b
Joey Hess 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 latter.
>
>>
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
On Fri, Mar 25, 2011 at 5:55 PM, John H. Robinson, IV 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 debian-devel-req
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
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.
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 t
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 t
John H. Robinson, IV wrote:
>Olaf van der Spek wrote:
>> On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre 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
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 l
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:
> > >
> > > libreoffice-presentation-minimizer_1.0.3+LibO3.3.
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.
Olaf van der Spek wrote:
> On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre 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
On 2011-03-25, Joey Hess 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 your use case
On Fri, Mar 25, 2011 at 5:27 PM, Steve McIntyre 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 ISO9660 bridge
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 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. Th
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 Joli
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 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
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
>> causi
On Fri, Mar 25, 2011 at 5:08 PM, Steve McIntyre 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 more of a ch
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 sim
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 an
On Fri, Mar 25, 2011 at 3:17 PM, Steve McIntyre 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
works on all requ
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
>>openoffice.org
>
>Dead. Any anything there is just transitional packages you need tor
>squeeze->wheezy upgrades, so need t
Hi,
On Fri, Mar 25, 2011 at 02:17:06PM +, Steve McIntyre wrote:
> Debian LibreOffice Maintainers
>openoffice.org
Dead. Any anything there is just transitional packages you need tor
squeeze->wheezy upgrades, so need to stay. Is libreoffice also affected?
>From your list it appears not...
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. A
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 s
: 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
Date: Sun, Nov 1, 2009 at 4:47 PM
Subject: [Kids Missing:/] Kids Missing Alert - 01 November 2009
To: kidsmiss...@googlegroups.com
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]
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
==
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 email
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 PROT
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]
Your message with subject HELLO sent on 04/07/05, 21:29:15 contained one
or more attachments not allowed by ChevronTexaco and was blocked.
McAfee GroupShieldâ Alert
McAfee GroupShield discovered a problem with the following email. See your
system administrator for further information.
Date/Time sent: 01 Dec 2004 10:45:32
Subject line: Re: Hello
From: debian-devel@lists.debian.org
To: Granneman, Joseph
Action taken: Replaced
1 - 100 of 123 matches
Mail list logo
