Re: Looking for someone to adopt pdftohtml

[Søren Boll Overgaard]

Hi,

On Sun, Feb 27, 2005 at 10:09:15PM +0100, Frederic Peters wrote:
> 
> > So, if anyone uses or cares about pdftohtml, please step up, otherwise I 
> > will
> > work out an arrangement with the maintainer of the depending package 
> > mentioned
> > above.
> 
> I use pdftohtml in a private project (actually only pdftohtml -xml for
> its XML output) and will adopt pdftohtml if nobody steps up.

Please do, it definitely needs attentions.

Thanks.

-- 
Søren O.   ,''`.
  : :' :
GPG key id: 0x1EB2DE66`. `'
GPG signed mail preferred.  `-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [OT] maildir (was Re: procmail and Large File Support)

[Michelle Konzack]

Am 2005-02-27 18:19:45, schrieb sean finney:
> can't help but chime in here :)

> On Mon, Feb 28, 2005 at 09:22:30AM +1100, Brian May wrote:
> > Not every situation warrants using maildir, it uses a large number of
> > inodes, is slow to scan (yes, mbox isn't very good either),

Mailbox is MUCH slower as Maildir, because it must be scaned entierly,
but with maildir, most you can spead up the searches while scaning
only the Headers.

> > inefficient at storing large number of very small files (due to block
> > size limitations of file system), and more complicated to
> > transfer/move/share.

What is complicate ?
You need only the right programs...

> it does use a large number of inodes, but i've found that even on large
> filesystems with many users, there's not a real risk of starving the fs
> of inodes.  ymmv.  i'm not sure about the transferring/moving/sharing though.
> 
> figuring the average email is about 13-15k, i believe an ext2/ext3
> filesystem created with default options would fill up before running
> out of inodes.

I have striped the Messages by "Received: " Headers and the most
Messages are under 4 kByte now. I have a Mailarchive from around
130 Mailinglists with 5,3 Million Messages and my ext3 Filesystem
has up to 18.000.000 Inodes and a blocksize of 1 kByte.

I had never problems with it. 

Also I have only one Mailfolder per Mailinglist (
has for example more then 190.000 Messges in it.) 

> > Of course, all of these factors depend on the file system used. I am
> > confident somebody could point out a file-system that eliminates many
> > of these disadvantages.
> 
> recent versions of kernel/ext2/ext3 have built-in dirent hashing, which
> cuts heavily on the many-files penalty.  another benefit of maildir
> is that when you modify a single message, you only need to modify the
> individual file, as opposed to the entire mailbox.  in some of the
> sloppier imap servers (*cough* uw-imap *cough* *cough*), this can cause
> huge, grind-your-server-to-a-halt performance hits as deleting, or
> merely reading a new message necessates a huge amount of i/o.

Right. I use courier and it works perfectly with Maildir...
No blocking or high load, even if I open m<  Mailbox

>   sean

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: [OT] maildir

[Michelle Konzack]

Am 2005-02-27 20:42:03, schrieb Ron Johnson:

> Ah.  Maildir distinguishes "new" and "already read" by whether
> an email is in the new/ or cur/ folder.
> 
> Doing a "select all, and mark as read" on a multi-GB mbox file
> sounds painful.

This is, why I never will use mailbox
Fortunatly I have converted all "Eudora lite" mailboxes to Maildir :-)

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: [OT] maildir

[Michelle Konzack]

Am 2005-02-28 04:34:41, schrieb Bernd Eckenfels:

> You mark a message as new by moving it to the "new" directory, and mark it
> as seen with the "cur" directory. Flags are normally added to the file name
> (by mutt for example). However some MUA-Servers need more info, which is
> then stored in extra files (imap is a pathological example for excessiv
> additional state)

You forget, that they are NEW messages which you have not
looked at and they are marked with "O" for Old-Unseen.
These files are moved to /cur.

> Greetings
> Bernd

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: [OT] maildir (was Re: procmail and Large File Support)

[Michelle Konzack]

Am 2005-02-27 20:19:09, schrieb Ron Johnson:

> Sure, for those *20* GB mbox files.

Who has 20 GByte mailboxes ?  -  It is realy braindamaged...

Even on xfs, open a 20 GByte Mailbox will eat up all resources
on the System

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: [OT] maildir (was Re: procmail and Large File Support)

[Ron Johnson]

On Mon, 2005-02-28 at 09:25 +0100, Michelle Konzack wrote:
> Am 2005-02-27 20:19:09, schrieb Ron Johnson:
> 
> > Sure, for those *20* GB mbox files.
> 
> Who has 20 GByte mailboxes ?  -  It is realy braindamaged...

The same person with the 2GB mbox that started this thread, after
s/he neglected it for a few more months.

> Even on xfs, open a 20 GByte Mailbox will eat up all resources
> on the System

Guess you'd better use Maildir, then, huh? ;)

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

LUKE: Is Perl better than Python?
YODA: No... no... no. Quicker, easier, more seductive.
LUKE: But how will I know why Python is better than Perl?
YODA: You will know. When your code you try to read six months
from now.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [OT] maildir (was Re: procmail and Large File Support)

[Michelle Konzack]

Am 2005-02-28 02:43:45, schrieb Ron Johnson:
> On Mon, 2005-02-28 at 09:25 +0100, Michelle Konzack wrote:

> > Who has 20 GByte mailboxes ?  -  It is realy braindamaged...
> 
> The same person with the 2GB mbox that started this thread, after
> s/he neglected it for a few more months.

:-/

Oh yes, the SPAM/Virus folder.
Then try to check it for false-positives...  :-)

> > Even on xfs, open a 20 GByte Mailbox will eat up all resources
> > on the System
> 
> Guess you'd better use Maildir, then, huh? ;)

I have no problems with my huge Maildir :-)

'mutt' open the 187.000 Messages in around 47 seconds local (/home
mounted via nfs v3) and via courier-imap-ssl in around 30 seconds.

I know the avantages of Maildir.

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: Automatic building of (parts of) the archive

[Wouter Verhelst]

On Sat, Feb 26, 2005 at 10:00:32PM +0100, Goswin von Brederlow wrote:
> Its buildd specific. If its queue is empty it contacts wanna-build and
> puts the new packages into the queue. I can't remeber the filename but
> that should be easy to see from the source.

~buildd/build/REDO

Format:

_ 

If there's a file like that when buildd starts, it will call sbuild with
those packages. It is safe to edit the file when sbuild is running, or
to create it if buildd is running and the file isn't there (that's what
buildd-mail does if you send a failed reply with "retry", or a
should-build reply with "ok" as the command)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#297218: ITP: radeontool -- utility to control ATI Radeon backlight functions on laptops

[Bas Zoetekouw]

Hi Luigi!

You wrote:

> You can find (and review) a preliminary package at
>   http://people.debian.org/~luigi/radeontool

Tahnks for packaging this!

Any chance you could make it suid safe and executable bij users in the
video group?

And maybe you could add support for setting the compaq m300/m500
backlight luminosity (although I'm not sure if that is Compaq specific or genral
for radeon), as implemented in the m300bl[1] program?

[1] http://wwwbode.cs.tum.edu/~acher/m300/

-- 
Kind regards,
++
| Bas Zoetekouw  | GPG key: 0644fab7 |
|| Fingerprint: c1f5 f24c d514 3fec 8bf6 |
| [EMAIL PROTECTED], [EMAIL PROTECTED] |  a2b1 2bae e41f 0644 fab7 |
++ 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[A Mennucc]

Sebastien NOEL wrote:
I have some questions about your package:
 

*   Why the "--disable-mencoder" in debian/rules ? 

 

my original thought was :
since  LAME is not in Debian , then 'mencoder' will not be very useful
but then some people pointed out that there are many interesting things 
that can
be done with mencoder that do not need LAME

so my next packaging will have 'mencoder'
*   Why the "--disable-aa" ?
   Ok caca is better than aa but it's not enabled either.
 

I received some e-mail from upstream authors suggesting that AA was a 
nice trick
but it may be removed from my packaging

anyway it seems that '-vo sdl:aa ' will work as well
*   You build libavcodec and libavformat but that seems to me a waste of time.
   FFmpeg is already in main, why not only link mplayer with
   libavcodec.a (libavcodec-dev) and libavformat.a (libavformat-dev) ?
 

choice of  upstream : AFAICR  a monolithic 'mplayer' improves performances

btw: this is what  Linus Torvalds decided with the kernel;
methinks that a smaller kernel with a stable API for loading
other minor services (ham radio, USB gadgets , etc)
would be much better, but thats another (long) story.
And, yes , I know that linux has modules, no, I dont think that they
satisfy the above requisite: currently linux is too big and too complex
for my tastes: it takes ages to download it, configure it and compile it.
It forces distributions to: either offer a complete kernel that will
satisfy all tastes, and that is huge; or have people recompile it
(and this means, understand its myriad of options).

Qestion to all DD:
Without decss, faad, lame & xvid, mplayer insn't really mplayer.
 

answer of 1 DD: on the other hand, without any kind of mplayer, Debian 
is at a loss

and there are wonderful feats that 'mplayer' that do not need  : decss, 
faad, lame & xvid

bye
a.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: self-depending packages

[Frank Küster]

Nicolas Boullis <[EMAIL PROTECTED]> wrote:

> Trying to upgrade a woody system to sarge, I experienced problems 
> upgrading libgtk2.0-0, and discovered that this packages was 
> self-depending. Afetr forcing the upgrade with "dpkg -i --force-depends", 
> everything went smoothly. So I filed a bug against libgtk2.0-0.
> Then I discovered that I could upgrade this package from woody to sarge 
> with no trouble in a clean pbuilder chroot. So the problem might me more 
> complex.
>
> However, from this bug report began a discussion with Loic Minier about 
> self-dependencies and circular dependencies.

What's the bug number?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: self-depending packages

[Antti-Juhani Kaijanaho]

On 20050227T214242+0100, Nicolas Boullis wrote:
> My understanding is that a self-depending package must be configured 
> before it can be configured, which makes it unconfigurable, and hence 
> uninstallable. And I think the same reasoning can be applied to 
> circular dependencies. But Loic disagrees.

Self-dependencies are harmless but ugly.  Circular dependencies are
sometimes (though very seldom) necessary (most of the time the same
effect can be got from a -common package).  Dpkg tries to break the
cycle at the least problemous point, for example configuring a package
with no postinst first.

> Should a bug be filed against those packages?

Minor severity at most, IMHO.

-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Peter Samuelson]

[Goswin von Brederlow]
> Which also avoids that packages will be unavailable on every new
> architecture debian introduces because the maintainer has to adjust
> the Architecture: line.

I suppose it'd be nice to be able to use !foo in the Architecture: line
for cases where something is known not to be supportable on a
particular small subset of arches, through toolchain bugs or whatever.

This smells like something dpkg/dpkg-source would have to support
directly, probably by substituting the list of arches into the field at
dpkg-source -b time.  Even so, I wonder if any external tools would
have a problem with the Architecture: line inside debian/control not
being the same as in the .dsc..


signature.asc
Description: Digital signature

Re: mplayer, the time has come

[Paul Hampson]

On Mon, Feb 28, 2005 at 10:19:37AM +0100, A Mennucc wrote:
> Sebastien NOEL wrote:

> >I have some questions about your package:
> >*   You build libavcodec and libavformat but that seems to me a waste of 
> >time.
> >   FFmpeg is already in main, why not only link mplayer with
> >   libavcodec.a (libavcodec-dev) and libavformat.a (libavformat-dev) ?

> choice of  upstream : AFAICR  a monolithic 'mplayer' improves performances

You've missed the point. If you use the libavcodec-dev and
libavformat-dev packages in Debian, you _get_ a monolithic
mplayer. Those packages only contain the static libraries,
which are linked in at compile time, since the packager has
chosen to not produce dynamic libraries for these two libraries
(for a different reason, I suspect, to do with the fluidity of
the libraries' APIs)

And even if libav{codec,format} had shared libraries in Debian,
the static versions in the -dev could be linked in, and I
understand that's the default way mplayer's configure script
accesses external libav{codec,format}.

If you use the ones in Debian, that's one less thing people
need to recompile to rebuild mplayer, like using external
libflac, libsdl etc, and it's easier to rebuild a local
mplayer with the latest lib{avcodec,format} versions, assuming
the packager of those is tracking CVS closely.

-- 
---
Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)
[EMAIL PROTECTED]

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

This email is licensed to the recipient for non-commercial
use, duplication and distribution.
---


signature.asc
Description: Digital signature

Re: self-depending packages

[Marc Haber]

On Mon, 28 Feb 2005 11:51:13 +0200, Antti-Juhani Kaijanaho
<[EMAIL PROTECTED]> wrote:
>Dpkg tries to break the
>cycle at the least problemous point, for example configuring a package
>with no postinst first.

Does it? The last time I was faced with that issue, the starting point
chosen was random and unpredictable.

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: self-depending packages

[Steinar H. Gunderson]

On Mon, Feb 28, 2005 at 11:58:14AM +0100, Marc Haber wrote:
> Does it? The last time I was faced with that issue, the starting point
> chosen was random and unpredictable.

It does. (I've hacked the code.)

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]µ

[Wouter Verhelst]

On Sun, Feb 27, 2005 at 11:08:14AM -0500, Rudy Godoy wrote:
> On 22/02/2005 at 10:11 Wouter Verhelst wrote...
>  
> > I agree that we should not continue to provide software for outdated
> > hardware platforms just for the sake of it; but as it is, there are
> > still people interested in m68k (some hobbyists, some embedded
> > developers, some who just use their old trusty hardware as their home
> > firewall, etc) and, I'm sure, other currently less-used hardware, so as
> > long as a port doesn't continually stall the release (which none
> > currently does; there are occasionally problems, but that happens in
> > every major undertaking), I see no reason to drop any port.
> 
> Regarding this issue I was thinking about it since I've faced in a
> situation where a package[0] I maintain does have "high" hardware
> requirements, which led me to think if it is really wise to have it
> with "arch: any" since probably in some arches it would not ever be
> installed/used, or even if case it will run really slow or even crash
> and the user will not enjoy the software as was intended by upstream,
[...]
> I don't know much about buildd infrastructure[1], if such thing was
> proposed or commented before (didn't check archives),

It has been brought up before a few times on the m68k mailinglists (and
perhaps others too, but I don't follow those). The answer is pretty
complex. In short: don't remove an architecture from your Architecture:
line unless it
* crashes,
* is something that requires so much CPU time that using it on hardware
  of which a >100Mhz variant does not exist /will/ make the system trash
  and be generally unusable until you hit the reset button,
or
* does not compile

I once wrote the long story in my blog; you can find it at
 (it being a
rant in reply to people shouting 'we should drop foo from Debian/m68k!',
it doesn't entirely fit into this thread, but apart from that, it
explains it).

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Wouter Verhelst]

On Mon, Feb 28, 2005 at 04:42:54AM -0600, Peter Samuelson wrote:
> 
> [Goswin von Brederlow]
> > Which also avoids that packages will be unavailable on every new
> > architecture debian introduces because the maintainer has to adjust
> > the Architecture: line.
> 
> I suppose it'd be nice to be able to use !foo in the Architecture: line
> for cases where something is known not to be supportable on a
> particular small subset of arches, through toolchain bugs or whatever.

Congratulations, you've just found #112325 :-)

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[Sebastien NOEL]

On Mon, 28 Feb 2005 10:19:37 +0100
A Mennucc <[EMAIL PROTECTED]> wrote:
> >*   Why the "--disable-mencoder" in debian/rules ? 
> >
> my original thought was :
> since  LAME is not in Debian , then 'mencoder' will not be very useful
> 
> but then some people pointed out that there are many interesting things 
> that can
> be done with mencoder that do not need LAME
> 
> so my next packaging will have 'mencoder'

ok, thanks you

> >*   Why the "--disable-aa" ?
> >Ok caca is better than aa but it's not enabled either.
> >
> I received some e-mail from upstream authors suggesting that AA was a 
> nice trick
> but it may be removed from my packaging
> 
> anyway it seems that '-vo sdl:aa ' will work as well

ok, but can you take a look at libcaca support please ?

> >*   You build libavcodec and libavformat but that seems to me a waste of 
> >time.
> >FFmpeg is already in main, why not only link mplayer with
> >libavcodec.a (libavcodec-dev) and libavformat.a (libavformat-dev) ?
> >
> >  
> >
> choice of  upstream : AFAICR  a monolithic 'mplayer' improves performances

Paul Hampson was faster than me for this point.
(but finally, i don't know if it is a good idea because ffmpeg was
configured with '--disable-mmx')


> answer of 1 DD: on the other hand, without any kind of mplayer, Debian 
> is at a loss

[agree]
 

Regards,

Sebastien NOEL


pgpt9Cfm3CvAJ.pgp
Description: PGP signature

Re: dehs will stop

[Pascal Hakim]

On Mon, 2005-02-28 at 03:32 +0100, Bluefuture wrote:
> 
> I'm not a debian developer, so i could not post on dda mailing list. I
> had opened many thread over this months on debian-qa debian-devel about
> dehs issues. The only reply are:
> 

If you're not a developer and you want to post on d-d-a, you need to
find a sponsor just like with packages. As long as the message is signed
by someone in the keyring, it should go through.

Cheers,

Pasc


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[Sebastien NOEL]

On Thu, 24 Feb 2005 19:40:35 -0500, you wrote:
> > (according to /usr/share/doc/ffmpeg/patents.txt.gz)
> I hope that isn't a file with descriptions of patents--anyone who
> reads such a thing would risk increased patent liability.  I'd rather
> not look for myself to find out, though.

omfg. it's not possible. you're a fake, you don't really exist ?
I put a pointer to you where you will be able to find more information
and the only reaction is "you are stupid, i'm not going to read this
and i don't want to know more about that"

whow

> That said, are the patents supposedly affecting libfaad2 actively
> being enforced?

Read The Fucking File


> I don't know how many times this can be said: non-us is *not a
> solution* to patents affecting the US, and never has been.

and what now ?

ok non-us is not the solution. but does it mean that there is no
solution at all ?


Sebastien NOEL



signature.asc
Description: Digital signature

Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

[Christoph Berg]

Re: Nelson A. de Oliveira in <[EMAIL PROTECTED]>
> * Package name: wmansied
>   Version : 0.4
>   Upstream Author : Walter Schreppers <[EMAIL PROTECTED]>
> * URL : http://www.win.ua.ac.be/~wschrep/ansied/
> * License : GNU General Public Licence version 2
>   Description : An ANSI/ASCII editor.

Re: Nelson A. de Oliveira in <[EMAIL PROTECTED]>
> * Package name: duhdraw
>   Version : 2.7.7
>   Upstream Author : Walt Stoneburner <[EMAIL PROTECTED]>
> * URL : http://www.cs.helsinki.fi/u/penberg/duhdraw/
> * License : GNU Copyleft
>   Description : A ANSI Editor for Linux similar to TheDraw.

What's the difference between the two? Do we really need both?

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

Re: [OT] maildir

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> That's for a maildir. It won't help you for mbox folders. Which kind
> of was the point, as I understand it.

Well, the comment that a file is immutable applies to maildir but not mbox
(obviously - how would you add new mails?). Thats why I responded, there is
not really a need to modify maildir files, and therefore you need no
locking - which was the reason for the comment in the first place.

Greetings
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[Moritz Muehlenhoff]

A Mennucc wrote:
> and there are wonderful feats that 'mplayer' that do not need  : decss, 
> faad, lame & xvid

Why should Debian's mplayer be unable to support XVID? The MPEG4 codec from
libavcodec will play any XVID just fine and libavcodec is already part of
Debian in xine-lib and ffmpeg.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mplayer, the time has come

[Cedric De Wilde]

On Mon, Feb 28, 2005 at 01:29:03PM +0100, Sebastien NOEL wrote:
> > I don't know how many times this can be said: non-us is *not a
> > solution* to patents affecting the US, and never has been.
> 
> and what now ?
> 
> ok non-us is not the solution. but does it mean that there is no
> solution at all ?
> 

Wait for sarge to become stable and discuss later, juste like xorg,
amd64...


Cédric De Wilde


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: self-depending packages

[Andrew Suffield]

On Mon, Feb 28, 2005 at 12:06:06PM +0100, Steinar H. Gunderson wrote:
> On Mon, Feb 28, 2005 at 11:58:14AM +0100, Marc Haber wrote:
> > Does it? The last time I was faced with that issue, the starting point
> > chosen was random and unpredictable.
> 
> It does. (I've hacked the code.)

Unfortunately apt breaks the code. If you use dpkg directly it'll
work. If you use apt it'll pick a random and unpredictable starting
point.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Bug#297235: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

[Nelson A. de Oliveira]

Hi Christoph,

On Mon, 28 Feb 2005, Christoph Berg wrote:

> > * Package name: wmansied
> >   Version : 0.4
> >   Upstream Author : Walter Schreppers <[EMAIL PROTECTED]>
> > * URL : http://www.win.ua.ac.be/~wschrep/ansied/
> > * License : GNU General Public Licence version 2
> >   Description : An ANSI/ASCII editor.
>
> > * Package name: duhdraw
> >   Version : 2.7.7
> >   Upstream Author : Walt Stoneburner <[EMAIL PROTECTED]>
> > * URL : http://www.cs.helsinki.fi/u/penberg/duhdraw/
> > * License : GNU Copyleft
> >   Description : A ANSI Editor for Linux similar to TheDraw.

> What's the difference between the two? Do we really need both?

I was using duhdraw, and since there was no package of it available, I
have decided to package. Duh Draw is a text mode only editor. It uses
ncurses.

When searching for a graphical ANSI editor, I found wmansied. It uses QT
libraries. Since some people don't like text mode utilities, I thought
that would be good to package it too.

If you think that only one is necessary, let me know, please.

Thank you
Nelson


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#297218: ITP: radeontool -- utility to control ATI Radeon backlight functions on laptops

[Luigi Gangitano]

Il giorno lun, 28-02-2005 alle 10:15 +0100, Bas Zoetekouw ha scritto:
> Any chance you could make it suid safe and executable bij users in the
> video group?

It would be difficult, radeontool need write access to /dev/mem, which
on my 'sid' is 

   crw-r-  1 root kmem 

so only root can change that. I could do a SETUID binary executable only
by root and video group, but I'm not sure we could trust it.

And, btw, you can do it yourself with dpkg-statoverride.

> And maybe you could add support for setting the compaq m300/m500
> backlight luminosity (although I'm not sure if that is Compaq specific or 
> genral
> for radeon), as implemented in the m300bl[1] program?
> 
> [1] http://wwwbode.cs.tum.edu/~acher/m300/

This is not related, since it's an utility that control the backlight
level via the on-board SuperIO chip, while radeontool uses the internal
controls to switch the backlight on and off.

Regards,

-- 
 Luigi Gangitano -- <[EMAIL PROTECTED]> -- <[EMAIL PROTECTED]>
 GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

Re: Any reason why I'm not CCed by bugs of my packages?

[Joel Aelwyn]

On Fri, Feb 25, 2005 at 04:43:06PM -0600, John Hasler wrote:
> Andreas Tille writes:
> > but got no mail notification about #296197 - just have seen it via web
> > interface.  Any idea what went wrong here.  (If I'm not absolutely wrong
> > this is not the first case for this package.)
> 
> I have no idea what causes it but the same thing happens to me a couple of
> times a year.



I just make it a regular habit to scan my packages via the web interface,
if only to remind myself about the wishlist bugs sitting on some of them.
Nothing's perfect.
-- 
Joel Aelwyn <[EMAIL PROTECTED]>   ,''`.
 : :' :
 `. `'
   `-


signature.asc
Description: Digital signature

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Goswin von Brederlow]

Peter Samuelson <[EMAIL PROTECTED]> writes:

> [Goswin von Brederlow]
>> Which also avoids that packages will be unavailable on every new
>> architecture debian introduces because the maintainer has to adjust
>> the Architecture: line.
>
> I suppose it'd be nice to be able to use !foo in the Architecture: line
> for cases where something is known not to be supportable on a
> particular small subset of arches, through toolchain bugs or whatever.

As a sidenote, wanna-build and buildd completly ignore the
architecture line (apart from arch:all) and build packages anyway.

Anything in the control file is purely informative to the buildd admin
at this point.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SoftwareSuspend-devel] 2.1-final for 2.6.8.1

[Erich Schubert]

Hi,
> > SElinux is not supported by debian. the grsecurity situation isn't
> > much different. 
> For SELinux. the kernel has the code; the archive has the user-space
> tools.

Believe me, I'm running SELinux on a couple of sarge boxes. Debian
SELinux support is incomplete. You need a patched init, for example.
rjc has a separate repository for these.
You don't want a libselinux dependency from sysvinit for mainstream in
Debian was the reasoning. So no way to run SElinux with 100% sarge.
And you better take the rules from CVS, too.

> I don't see how this is any different to what I propose with
> swsusp2. I will package it. If you oppose to have this patch in
> stable, please discuss it on debian-devel.

[Added CC: to debian-devel]

Yes. I claim that it doesn't make any sense to have software-suspend2
patches in Debian stable, because of all the driver issues remaining
with 2.6.8.1.
I've been running swsusp2 for a long time now, and I'm sponsoring the
hibernate script debian packages. Believe me, I have considered doing
a patch package.

> > It requires the USB modules to be unloaded before suspend. This
> > implies you must not compile them statically into the kernel.
> > Similar things apply to other drivers.
> 
> I see no problem with this on Debian kernels, which are modular.

The patch will not be included in Debian kernels, but will be used by
the user to build his own kernel. Which will likely be not pure
modular, but maybe just break swsusp.

> As soon as Pavel merges swsusp2 into 2.6 ...

Which will not be in 2.6.8.1

> > But those who build their own kernel will either go for a more
> > recent kernel, or will likely change some options and end up with
> > a non-working suspend due to driver problems. and this will
> > reflect back badly on both debian and swsusp2.
> 
> Debian assumes that those who compile their own kernels know what
> they are doing. I don't see a point in trying to nanny them and
> prevent them from screwing up their systems. There are plenty of
> other ways to do so too.

Heck, just let them get a recent kernel and be much better off!
Put the kernel and the swsusp patch into "volatile".

Gruß,
Erich Schubert
--
erich@(mucl.de|debian.org)  --  GPG Key ID: 4B3A135C(o_
  To understand recursion you first need to understand recursion.   //\
  Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für   V_/_
eine Stunde wie eine Heimat aus. --- Herrmann Hesse

Re: self-depending packages

[Antti-Juhani Kaijanaho]

On 20050228T164806+, Andrew Suffield wrote:
> Unfortunately apt breaks the code. If you use dpkg directly it'll
> work. If you use apt it'll pick a random and unpredictable starting
> point.

Doesn't apt usually unpack all packages first and then configure them in
one run, so that shouldn't matter?

(Of course, essential packages and stuff like that break this but...)

-- 
Antti-Juhani Kaijanaho, Debian developer 

http://kaijanaho.info/antti-juhani/blog/en/debian


signature.asc
Description: Digital signature

Re: Debian "Sarge" Support

[Hans Reiser]

Can you folks at Debian tell me whether we are supported in Sarge?
Thanks,
Hans
Ben Pont wrote:
I am preparing to install Debian "Sarge" on my
computer and am debating whether to partition
Reiser4 or Ext3.
I know Lindows supports Reiser4, Lindows being
Debian based, but do you know if Sarge explicitly
supports your format?  Since Debian is a pain in
the ass to install in the first place, I'd really
like to get things right the first time and not
have to repartition / reinstall if I discover
Reiser4 isn't supported by Debian.
Yes, I have tried getting answers from the Debian
folks directly, but have gotten mixed messages. 
Any info from your side would be greatly
appreciated.  Thanks.

Ben
		
__ 
Do you Yahoo!? 
Take Yahoo! Mail with you! Get it on your mobile phone. 
http://mobile.yahoo.com/maildemo 

 

debi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: self-depending packages

[Loïc Minier]

On Mon, Feb 28, 2005, Frank Küster wrote:
> What's the bug number?

 

-- 
Loïc Minier <[EMAIL PROTECTED]>
"Neutral President: I have no strong feelings one way or the other."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: splitting a source package into 2 source packages

[Cesar Martinez Izquierdo]

El Sábado 26 Febrero 2005 21:47, sean finney escribió:
> istr the same thing, and was thinking that this might be the case.
> since i don't suppose the ftp-master illuminati are going to come out
> of hiding just to answer this question, i guess i'll upload, find out,
> and report back :/
>
>
>  sean

Please, do it (report back). I'm interested in the same question.

  César

Re: Debian "Sarge" Support

[Floris Bruynooghe]

On Mon, Feb 28, 2005 at 01:47:18PM -0800, Hans Reiser wrote:
> Can you folks at Debian tell me whether we are supported in Sarge?
> 
> Thanks,
> 
> Hans

Last time I installed sarge (ages ago, about November last year) I did
make some ReiserFS partitions and they ended up being 3.6 not 4.
Things could have changed of course, but I don't really expect so.

Hope this helps
Floris

> Ben Pont wrote:
> 
> >I am preparing to install Debian "Sarge" on my
> >computer and am debating whether to partition
> >Reiser4 or Ext3.
> >
> >I know Lindows supports Reiser4, Lindows being
> >Debian based, but do you know if Sarge explicitly
> >supports your format?  Since Debian is a pain in
> >the ass to install in the first place, I'd really
> >like to get things right the first time and not
> >have to repartition / reinstall if I discover
> >Reiser4 isn't supported by Debian.
> >
> >Yes, I have tried getting answers from the Debian
> >folks directly, but have gotten mixed messages. 
> >Any info from your side would be greatly
> >appreciated.  Thanks.
> >
> >Ben
> >
> >
> > 
> >__ 
> >Do you Yahoo!? 
> >Take Yahoo! Mail with you! Get it on your mobile phone. 
> >http://mobile.yahoo.com/maildemo 
> >
> >
> > 
> >
> debi
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact 
> [EMAIL PROTECTED]
> 

-- 
Debian GNU/Linux -- The power of freedom
www.debian.org | www.gnu.org | www.kernel.org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debian "Sarge" Support

[Josselin Mouette]

Le lundi 28 fÃvrier 2005 Ã 13:47 -0800, Hans Reiser a Ãcrit :
> Can you folks at Debian tell me whether we are supported in Sarge?

As far as I know, there is no reiser4 support in the Debian stock
kernel.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=

Re: Debian "Sarge" Support

[Andrew M.A. Cater]

As far as I can see - Debian "Sarge" / Debian "testing" / Debian
GNU/Linux 3.1 - now has support both for Reiserfs [?? 3.6.19??] 
and Reiser4 [?? 1.0.3 ??]. There is a kernel patch against version
2.6.8 for Reiser4.

Hope this helps - everyone feel free to correct me if I'm wrong :)

Andy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: self-depending packages

[Andrew Suffield]

On Mon, Feb 28, 2005 at 09:49:41PM +0200, Antti-Juhani Kaijanaho wrote:
> On 20050228T164806+, Andrew Suffield wrote:
> > Unfortunately apt breaks the code. If you use dpkg directly it'll
> > work. If you use apt it'll pick a random and unpredictable starting
> > point.
> 
> Doesn't apt usually unpack all packages first and then configure them in
> one run, so that shouldn't matter?

dpkg does the same thing

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Debian Project Leader Election 2005

[Nico Golde]

Hi,
* Debian Project Secretary <[EMAIL PROTECTED]> [2005-02-28 21:36]:
> The nomination period is at an end, with six candidates
>  standing forth to be counted. We are now in the campaigning period.
>  The candidates are:
> 
>   o Matthew Garrett  [EMAIL PROTECTED]

^^ Is the email address wrong?
There is no entry for http://qa.debian.org/[EMAIL PROTECTED]
Regards Nico
-- 
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | mutt-ng.berlios.de | grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpVN7mx1bRQw.pgp
Description: PGP signature

Re: Debian Project Leader Election 2005

[Joerg Jaspert]

On 10214 March 1977, Nico Golde wrote:

>>   o Matthew Garrett  [EMAIL PROTECTED]
> ^^ Is the email address wrong?
> There is no entry for
> http://qa.debian.org/[EMAIL PROTECTED]

No, as you are free to use whatever email as a maintainer.
Look at db.d.o if you want to look for logins.

-- 
bye Joerg
<_DeadBull_> ohne speicher, tastatur, mouse, pladde, monitor, also nur die
Hardware...


pgpRbHBdnh6Ui.pgp
Description: PGP signature

Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

"Nelson A. de Oliveira" <[EMAIL PROTECTED]> writes:

> WMAnsiEd is an ANSI editor with functions like line drawing, ellipse,
> box, etc., written in Qt. All IBM ANSI and ASCII characters are

"ANSI" is pretty meaningless as a "standard", since ANSI standardised
many different things.  Perhaps you mean it implements ISO-6429
(ECMA-48) SGR control sequences, or maybe something entirely
different?  Either way, it would help if you were much more specific.

(This applies equally to the other ITP.)


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQFCI4z3VcFcaSW/uEgRArPXAJwJbg6I4N13wcQs6z1tlH86YfWcFACfaCDa
MMcd8DXdCXZgoI9b1ZlUCf0=
=I6+Y
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Why are you guys using user space utilities not written by us that seem to not work? Could you change who is the debian maintainer for us?

[Hans Reiser]

I can volunteer [EMAIL PROTECTED], the guy who writes our utilities 
(which work), for the task.

This is the second time that Ed has broken Reiserfs support in Debian, 
and each time it breaks Namesys looks bad, because users have no idea it 
is not us who broke our code.  Thanks to Cliff we now have an idea where 
some mysterious reports of things breaking have their source. 

Who is jltallon?  adv-solutions.net has no information on its web page 
explaining about who they are.

Is Debian intending to code fork ReiserFS?  Are you guys that nuts?
Vitaly, please pursue this matter with Debian.
Hans
--- Begin Message ---
Well, I have some new info this morning.
We attributed the errors to hard drive problems to start with as well, 
but the errors were too consistent and appeared on too many machines 
simultaneously.

Over the weekend we have collected many reports of people being unable 
to install using reiser3, but succeeding with reiser4.  This eliminates 
both bad CD burns and hard drive errors, so I went looking for another 
cause.

Recently we included qtparted which pulls in a Debian package called 
``progsreiserfs'' instead of ``reiserfsprogs.''  We are investigating 
this as the cause of the problems right now.

We are seeing a behavior with the ``progsreiserfs'' tools that one 
install will generate errors, another will succeed but take a long time, 
and a third will succeed in the normal amount of time.  Same machine, 
same hard disk, same CDROM.

I'm including Debian's description of these packages below.
Package: reiserfsprogs
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 1072
Maintainer: Ed Boraas <[EMAIL PROTECTED]>
Architecture: i386
Version: 1:3.6.19-1
Depends: libc6 (>= 2.3.2.ds1-4), libuuid1
Description: User-level tools for ReiserFS filesystems
This package contains utilities to create, check, resize, and debug 
ReiserFS
filesystems.
.
NOTE: Releases of Linux prior to 2.4.1 do not support ReiserFS on their 
own.
Thus, these tools will only be useful with Linux 2.4.1 or later, or if your
kernel has been built with the ReiserFS patch applied. This patch can 
be found
in the appropriate kernel-patch--reiserfs packages.
.
 Homepage: http://www.namesys.com/

zz:~# apt-cache show progsreiserfs
Package: progsreiserfs
Version: 0.3.0.4-4
Architecture: i386
Priority: extra
Section: admin
Maintainer: Jose Luis Tallon <[EMAIL PROTECTED]>
Depends: libc6 (>= 2.3.2.ds1-4), libreiserfs0.3-0 (>= 0.3.0), libuuid1
Conflicts: reiserfsprogs
Provides: reiserfsprogs
Size: 34236
Installed-Size: 156
MD5sum: 57feec6fc2b48d125e755e0a2ab31bb0
Description: Tools for manipulating ReiserFS filesystems
progsreiserfs is a collection of tools for manipulating
ReiserFS filesystems. There are tools to create, check,
resize, tune and copy ReiserFS filesystems.
.
These tools differ from the standard Namesys ReiserFS tools
in that they use libreiserfs to do their work.
Filename: pool/p/progsreiserfs/progsreiserfs_0.3.0.4-4_i386.deb

Hans Reiser wrote:
Clifford Beshers wrote:
We recently rewrote our installer to use a custom program that can 
stream a compressed iso9660 image file and unpack it to disk.  
Previously it used rsync.  Everything seemed to be fine, but when we 
started running it on many machines, we started encountering errors 
like the ones shown below, the output of dmesg.

At first I suspected it might be that the kernel hadn't re-read the 
partition table, but on several installs we did not create or modify 
that table.

Anyone have any guesses as to what is going wrong?
Again, this is reiser3.
hda1: rw=0, want=116654088, limit=50058477
attempt to access beyond end of device
hda1: rw=0, want=116916232, limit=50058477
attempt to access beyond end of device
hda1: rw=0, want=117178376, limit=50058477
ReiserFS: hda1: warning: sh-2029: reiserfs read_bitmaps: bitmap block 
(#6258688) reading failed
ReiserFS: hda1: warning: jmacd-8: reiserfs_fill_super: unable to read 
bitmap

The above look like hardware errors from the disk drive.  There have 
been rsync related emails on this list, but let's start with a working 
disk drive, ok?

It is remotely possible that the above could be a failure to reboot 
after using fsync

NTFS volume version 1.2.
NTFS-fs warning (device hda2): load_system_files(): Volume is dirty.  
Will not be able to remount read-write.  Run chkdsk and mount in 
Windows.
ReiserFS: hda1: found reiserfs format "3.6" with standard journal
ReiserFS: hda1: using ordered data mode
ReiserFS: hda1: journal params: device hda1, size 8192, journal first 
block 18, max trans len 1024, max batch 900, max commit age 30, max 
trans age 30
ReiserFS: hda1: checking transaction log (hda1)
ReiserFS: hda1: Using r5 hash to sort names
ReiserFS: hda1: warning: Created .reiserfs_priv on hda1 - reserved 
for xattr storage.
Adding 1049592k swap on /mnt/install/boot/linux-swap.swp.  
Priority:-1 extents:215
ReiserFS: warning: is_leaf: item location seems wrong (second one): 
*3.6* [7 32 0

Re: Debian Project Leader Election 2005

[Nico Golde]

Hello Joerg,

* Joerg Jaspert <[EMAIL PROTECTED]> [2005-02-28 21:54]:
> On 10214 March 1977, Nico Golde wrote:
> 
> >>   o Matthew Garrett  [EMAIL PROTECTED]
> > ^^ Is the email address wrong?
> > There is no entry for
> > http://qa.debian.org/[EMAIL PROTECTED]
> 
> No, as you are free to use whatever email as a maintainer.
> Look at db.d.o if you want to look for logins.

Ok thanks. I thought that would be his maintainer
email address.
Regards Nico
-- 
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | mutt-ng.berlios.de | grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpUsMnezWAJU.pgp
Description: PGP signature

Re: Why are you guys using user space utilities not written by us that seem to not work? Could you change who is the debian maintainer for us?

[Steve Langasek]

Hans,

On Mon, Feb 28, 2005 at 03:22:17PM -0800, Hans Reiser wrote:
> This is the second time that Ed has broken Reiserfs support in Debian, 
> and each time it breaks Namesys looks bad, because users have no idea it 
> is not us who broke our code.  Thanks to Cliff we now have an idea where 
> some mysterious reports of things breaking have their source. 

I can't see from the message below that this breakage has anything to do
with Ed's work.  The progsreiserfs package has a separate maintainer; it
also has a release-critical bug open on it due to these known (to us)
problems, and will not be included in the upcoming sarge release.  It also
has not been available in the Debian testing suite for some time, nor is it
included with the Debian installer: anyone who pulls packages from Debian
unstable without looking at any of these issues does so at their own risk.

Incidentally, aside from having had its reiserfs resize support pulled
because it depended on the buggy progsreiserfs implementation, qtparted has
itself also been dropped from testing due to an unrelated RC bug.

Thanks,
-- 
Steve Langasek
postmodern programmer

> Date: Mon, 28 Feb 2005 12:12:38 -0800
> From: Clifford Beshers <[EMAIL PROTECTED]>
> To: Hans Reiser <[EMAIL PROTECTED]>
> Cc: reiserfs-list@namesys.com
> Subject: Re: Install errors, reiser3 messages
> X-Lindows-Footer: yes
> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
>   thebsh.namesys.com
> X-Spam-DCC: : 
> X-Spam-Status: No, hits=0.0 required=2.0 tests=none autolearn=no version=2.60
> 
> Well, I have some new info this morning.
> 
> We attributed the errors to hard drive problems to start with as well, 
> but the errors were too consistent and appeared on too many machines 
> simultaneously.
> 
> Over the weekend we have collected many reports of people being unable 
> to install using reiser3, but succeeding with reiser4.  This eliminates 
> both bad CD burns and hard drive errors, so I went looking for another 
> cause.
> 
> Recently we included qtparted which pulls in a Debian package called 
> ``progsreiserfs'' instead of ``reiserfsprogs.''  We are investigating 
> this as the cause of the problems right now.
> 
> We are seeing a behavior with the ``progsreiserfs'' tools that one 
> install will generate errors, another will succeed but take a long time, 
> and a third will succeed in the normal amount of time.  Same machine, 
> same hard disk, same CDROM.
> 
> I'm including Debian's description of these packages below.
> 
> Package: reiserfsprogs
> Status: install ok installed
> Priority: optional
> Section: admin
> Installed-Size: 1072
> Maintainer: Ed Boraas <[EMAIL PROTECTED]>
> Architecture: i386
> Version: 1:3.6.19-1
> Depends: libc6 (>= 2.3.2.ds1-4), libuuid1
> Description: User-level tools for ReiserFS filesystems
> This package contains utilities to create, check, resize, and debug 
> ReiserFS
> filesystems.
> .
> NOTE: Releases of Linux prior to 2.4.1 do not support ReiserFS on their 
> own.
> Thus, these tools will only be useful with Linux 2.4.1 or later, or if your
> kernel has been built with the ReiserFS patch applied. This patch can 
> be found
> in the appropriate kernel-patch--reiserfs packages.
> .
>  Homepage: http://www.namesys.com/
> 
> zz:~# apt-cache show progsreiserfs
> Package: progsreiserfs
> Version: 0.3.0.4-4
> Architecture: i386
> Priority: extra
> Section: admin
> Maintainer: Jose Luis Tallon <[EMAIL PROTECTED]>
> Depends: libc6 (>= 2.3.2.ds1-4), libreiserfs0.3-0 (>= 0.3.0), libuuid1
> Conflicts: reiserfsprogs
> Provides: reiserfsprogs
> Size: 34236
> Installed-Size: 156
> MD5sum: 57feec6fc2b48d125e755e0a2ab31bb0
> Description: Tools for manipulating ReiserFS filesystems
> progsreiserfs is a collection of tools for manipulating
> ReiserFS filesystems. There are tools to create, check,
> resize, tune and copy ReiserFS filesystems.
> .
> These tools differ from the standard Namesys ReiserFS tools
> in that they use libreiserfs to do their work.
> Filename: pool/p/progsreiserfs/progsreiserfs_0.3.0.4-4_i386.deb
> 
> 
> 
> Hans Reiser wrote:
> 
> >Clifford Beshers wrote:
> >
> >>
> >>We recently rewrote our installer to use a custom program that can 
> >>stream a compressed iso9660 image file and unpack it to disk.  
> >>Previously it used rsync.  Everything seemed to be fine, but when we 
> >>started running it on many machines, we started encountering errors 
> >>like the ones shown below, the output of dmesg.
> >>
> >>At first I suspected it might be that the kernel hadn't re-read the 
> >>partition table, but on several installs we did not create or modify 
> >>that table.
> >>
> >>Anyone have any guesses as to what is going wrong?
> >>Again, this is reiser3.
> >>
> >>
> >>hda1: rw=0, want=116654088, limit=50058477
> >>attempt to access beyond end of device
> >>hda1: rw=0, want=116916232, limit=50058477
> >>attempt to access beyond end of device
> >>hda1: rw=0, want=117178376, limit=50058477
> >>ReiserFS: hda1: warning

Re: [OT] maildir (was Re: procmail and Large File Support)

[David Schmitt]

On Monday 28 February 2005 01:51, Ron Johnson wrote:
> On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote:
[snip]
> > figuring the average email is about 13-15k, i believe an ext2/ext3
>
> That seems awfully huge.  In my (Maildir) archive of d-u, the
> average size is 4,959 bytes.  Of course, there are no html mails.
> Though, even in my Evolution list archive, where there are many
> more html-mails, the average size is only 6,097.

I ran statistics on maildirs of the university (of arts) mailserver I 
administer: ~90k per mail.


Regards, David
-- 
- hallo... wie gehts heute?
- *hust* gut *rotz* *keuch*
- gott sei dank kommunizieren wir Ãber ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15

Re: Why are you guys using user space utilities not written by us that seem to not work? Could you change who is the debian maintainer for us?

[Joey Hess]

Hans Reiser wrote:
> I can volunteer [EMAIL PROTECTED], the guy who writes our utilities 
> (which work), for the task.
> 
> This is the second time that Ed has broken Reiserfs support in Debian, 
> and each time it breaks Namesys looks bad, because users have no idea it 
> is not us who broke our code.  Thanks to Cliff we now have an idea where 
> some mysterious reports of things breaking have their source. 
>
> Who is jltallon?  adv-solutions.net has no information on its web page 
> explaining about who they are.
> 
> Is Debian intending to code fork ReiserFS?  Are you guys that nuts?
> 
> Vitaly, please pursue this matter with Debian.

Hi Hans, I think we met in Max's once after a BALUG meeting. Anyway, let
me try to clear up some misconceptions you seem to have:

 - progreiserfs is not the default reiserfs toolset used by Debian. See
   thread starting at 
   .
 - Since progreiserfs is known to cause data loss, it has not even been
   available in Debian testing for a long time, and is unlikely to be
   part of a Debian release. See .
 - progsreiserfs was not developed by Debian, so accusing us of forking
   reiserfs is a fairly strange thing to say. It was written by Yury
   Umanets <[EMAIL PROTECTED]>. See .
 - Ed Boraas has, AFAIK, nothing to do with progsreiserfs. He maintains
   reiserfsprogs, from namesys. See the mail you forwarded to this list.
 - Jose Luis Tallon is a prospective new Debian developer who, with the
   help of Debian developer Roberto Lumbreras, has been (trying to)
   maintain progsreiserfs after the developer who previously added it to
   the Debian distribution in 2002 resigned. See
   .

All of the above information can be obtained publically online; indeed
that's where I obtained it, with only a few minutes searching. Maybe
doing a bit more research before posting messages that are so likely to
result in flames would be a good idea in the future.

> This message contains information which may be confidential and 
> privileged. Unless you are the addressee (or authorized to receive for the 
> addressee), you may not use, copy or disclose to anyone the message or any 
> information contained in the message. If you have received the message in 
> error, please advise the sender and delete the message.  Thank you.

Please do not post mails to the debian mailing lists with signature
blocks that are so obviously unenforceable. All mails posted to Debian
mailing lists, with the exception of debian-private, are made available
publically without exception. Thanks.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: [OT] maildir (was Re: procmail and Large File Support)

[Ron Johnson]

On Mon, 2005-02-28 at 22:55 +0100, David Schmitt wrote:
> On Monday 28 February 2005 01:51, Ron Johnson wrote:
> > On Sun, 2005-02-27 at 18:19 -0500, sean finney wrote:
> [snip]
> > > figuring the average email is about 13-15k, i believe an ext2/ext3
> >
> > That seems awfully huge.  In my (Maildir) archive of d-u, the
> > average size is 4,959 bytes.  Of course, there are no html mails.
> > Though, even in my Evolution list archive, where there are many
> > more html-mails, the average size is only 6,097.
> 
> I ran statistics on maildirs of the university (of arts) mailserver I 
> administer: ~90k per mail.

Art majors passing around scanned pictures of croissants?  ;)

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

When asked to name the chief qualification a politician should
have. "It's the ability to foretell what will happen tomorrow,
next month, and next year --- and to explain afterward why it
didn't happen."
Sir Winston Churchill


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [OT] maildir

[Brian May]

> "Michelle" == Michelle Konzack <[EMAIL PROTECTED]> writes:

>> > inefficient at storing large number of very small files (due
>> to block > size limitations of file system), and more
>> complicated to > transfer/move/share.

Michelle> What is complicate ?  You need only the right
Michelle> programs...

Perhaps I should elaborate on this point.

If I want to allow people to download a mbox folder (consider mailing
list archive), all I do is put in under a HTTP accessible
directory. People only need to download one file, and IIRC, there is a
standard (or defacto standard) MIME type for mbox files. I believe a
browser will automatically start mutt. In fact, I believe this will
work even if the file is gzipped.

Now take Maildirs... Sure, I could tar.gz the entire directory, but
this means the recipient must manually untar it before accessing it.
I don't believe there is a standard MIME type to distinguish these
files either. As far as your browser is concerned, it isn't "Maildir"
format, it is "gzipped tar format".

Also, all mailing list software I have seen so far exclusively uses
mbox files.

Sure, these are implementation issues that could be solved, but
currently mbox wins.
-- 
Brian May <[EMAIL PROTECTED]>


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why are you guys using user space utilities not written by us that seem to not work? Could you change who is the debian maintainer for us?

[José Luis Tallón]

Hans Reiser wrote:
I can volunteer [EMAIL PROTECTED], the guy who writes our utilities 
(which work), for the task.
Sorry, but this is the first thing i hear anything about this :-?
This is the second time that Ed has broken Reiserfs support in Debian, 
and each time it breaks Namesys looks bad, because users have no idea 
it is not us who broke our code.  Thanks to Cliff we now have an idea 
where some mysterious reports of things breaking have their source.
Progsreiserfs are *not* in testing and have Release Critical bugs for a 
reason, and that is to avoid giving the impression that they are stable 
packages. In fact, they are even categorized under "extra" instead of 
"optional", because they are lower priority.

Who is jltallon?  adv-solutions.net has no information on its web page 
explaining about who they are.
Well, José Luis Tallón (that's me). Currently finishing the NM process 
at Debian and maintainer of some packages.
Adv-solutions.net has no web page. It is one of my personal domains, 
with no commercial interests attached.

Is Debian intending to code fork ReiserFS?  Are you guys that nuts?
Vitaly, please pursue this matter with Debian.
Well, i would sincerely appreciate that somebody explained the full 
thing to me.
I have been intending to upgrade "progsreiserfs" for quite some time 
now, but lacked the necessary time. And since they are not in testing, i 
really needed not worry.

From what i read below, there is somebody actually using QtParted for 
their installer. This means i now have some incentive to devote work to 
this... i will try to have it upgraded as soon as possible, but i can't 
guarantee anything. I will try to keep you posted.
Any additional feedback would be appreciated.

Hans

Subject:
Re: Install errors, reiser3 messages
From:
Clifford Beshers <[EMAIL PROTECTED]>
Date:
Mon, 28 Feb 2005 12:12:38 -0800
To:
Hans Reiser <[EMAIL PROTECTED]>
To:
Hans Reiser <[EMAIL PROTECTED]>
CC:
reiserfs-list@namesys.com
Return-Path:
<[EMAIL PROTECTED]>
Delivered-To:
[EMAIL PROTECTED]
Received:
(qmail 14707 invoked by uid 85); 28 Feb 2005 20:12:56 -
Received:
from [EMAIL PROTECTED] by thebsh.namesys.com by uid 82 
with qmail-scanner-1.15 (spamassassin: 2.43-cvs. Clear:SA:0(0.0/2.0 
tests=none autolearn=no version=2.60):. Processed in 8.523853 secs); 
28 Feb 2005 20:12:56 -
Received:
from mail.linspire.com (HELO mail.lindows.com) (130.94.123.204) by 
thebsh.namesys.com with SMTP; 28 Feb 2005 20:12:47 -
Received:
by mail.lindows.com (Postfix, from userid 8) id 17AEC15C6D20; Mon, 28 
Feb 2005 12:14:02 -0800 (PST)
Received:
from linspireinc.com (unknown [207.67.194.2])by mail.lindows.com 
(Postfix) with ESMTPid CC40A15C6CF3; Mon, 28 Feb 2005 12:14:01 -0800 
(PST)
Message-ID:
<[EMAIL PROTECTED]>
User-Agent:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20041006 
Debian/1.6-5.1.0.50.linspire0.38
X-Accept-Language:
en-us, en
MIME-Version:
1.0
References:
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
In-Reply-To:
<[EMAIL PROTECTED]>
Content-Type:
text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:
7bit
X-Lindows-Footer:
yes
X-Spam-Checker-Version:
SpamAssassin 2.60 (1.212-2003-09-23-exp) on thebsh.namesys.com
X-Spam-DCC:
:
X-Spam-Status:
No, hits=0.0 required=2.0 tests=none autolearn=no version=2.60

Well, I have some new info this morning.
We attributed the errors to hard drive problems to start with as well, 
but the errors were too consistent and appeared on too many machines 
simultaneously.

Over the weekend we have collected many reports of people being unable 
to install using reiser3, but succeeding with reiser4.  This 
eliminates both bad CD burns and hard drive errors, so I went looking 
for another cause.

Recently we included qtparted which pulls in a Debian package called 
``progsreiserfs'' instead of ``reiserfsprogs.''  We are investigating 
this as the cause of the problems right now.

We are seeing a behavior with the ``progsreiserfs'' tools that one 
install will generate errors, another will succeed but take a long 
time, and a third will succeed in the normal amount of time.  Same 
machine, same hard disk, same CDROM.

I'm including Debian's description of these packages below.
Package: reiserfsprogs
Status: install ok installed
Priority: optional
Section: admin
Installed-Size: 1072
Maintainer: Ed Boraas <[EMAIL PROTECTED]>
Architecture: i386
Version: 1:3.6.19-1
Depends: libc6 (>= 2.3.2.ds1-4), libuuid1
Description: User-level tools for ReiserFS filesystems
This package contains utilities to create, check, resize, and debug 
ReiserFS
filesystems.
.
NOTE: Releases of Linux prior to 2.4.1 do not support ReiserFS on 
their own.
Thus, these tools will only be useful with Linux 2.4.1 or later, or if 
your
kernel has been built with the ReiserFS patch applied. This patch can 
be found
in the appropriate kernel-patch--reiserfs packages.
.
 Homepage: http://www.namesys.com/

zz:~# 

Re: Debian "Sarge" Support

[Wouter Verhelst]

On Mon, Feb 28, 2005 at 01:47:18PM -0800, Hans Reiser wrote:
> Can you folks at Debian tell me whether we are supported in Sarge?

The stock kernels support Reiser3, but not Reiser4. Reiser4 support
packages are available, however.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Wouter Verhelst]

On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
> Peter Samuelson <[EMAIL PROTECTED]> writes:
> 
> > [Goswin von Brederlow]
> >> Which also avoids that packages will be unavailable on every new
> >> architecture debian introduces because the maintainer has to adjust
> >> the Architecture: line.
> >
> > I suppose it'd be nice to be able to use !foo in the Architecture: line
> > for cases where something is known not to be supportable on a
> > particular small subset of arches, through toolchain bugs or whatever.
> 
> As a sidenote, wanna-build and buildd completly ignore the
> architecture line (apart from arch:all) and build packages anyway.

Well, somewhat :-)

they /attempt/ the build. sbuild will detect that it is not actually a
package for this architecture, and will break it off right when the
source package is extracted.

> Anything in the control file is purely informative to the buildd admin
> at this point.

No, sbuild does check more things.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: splitting a source package into 2 source packages

[Bill Allombert]

On Sat, Feb 26, 2005 at 02:47:51PM -0500, sean finney wrote:
> On Sat, Feb 26, 2005 at 02:18:19PM -0500, Josh Metzler wrote:
> > I seem to recall hearing that NEW processing is based solely on binary 
> > packages, so that the new source package would not need to go through NEW 
> > if it creates a binary package that is already in the archive.
> > 
> > I couldn't find anything about this through google, though, so it may be 
> > best to upload to experimental first and see if your new packages go right 
> > in or not.
> 
> istr the same thing, and was thinking that this might be the case.
> since i don't suppose the ftp-master illuminati are going to come out
> of hiding just to answer this question, i guess i'll upload, find out,
> and report back :/

Given that some people might find offensive to be compared to
illuminati, I don't think this is the best way to engage the ftp-master.
YMMV.  

IIUC, the override file only contains binary packages names, so
renaming/splitting a source package without altering the binaries
packages produced should not need changes to the override file.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [OT] maildir

[sean finney]

On Tue, Mar 01, 2005 at 09:03:06AM +1100, Brian May wrote:
> Also, all mailing list software I have seen so far exclusively uses
> mbox files.
> 
> Sure, these are implementation issues that could be solved, but
> currently mbox wins.

if the use of your stored mail is append-only and read-only, then
mbox is the best way to go, for reasons you mentioned.  it sucks
for just about anything else though.

sean

-- 


signature.asc
Description: Digital signature

Re: splitting a source package into 2 source packages

[sean finney]

On Tue, Mar 01, 2005 at 12:29:09AM +0100, Bill Allombert wrote:
> Given that some people might find offensive to be compared to
> illuminati, I don't think this is the best way to engage the ftp-master.
> YMMV.  

perhaps i should have made it a bit more apparent that my tongue was
slightly in-cheek when i said that.  it was also slightly not in-cheek,
as i do feel that the world of ftp-master is often shrouded in a veil
of secrecy.  however, i by no means meant to offend anyone personally
and if i have i withdraw the comparison.


sean

-- 


signature.asc
Description: Digital signature

Re: Debian Project Leader Election 2005

[Bartosz Fenski aka fEnIo]

On Mon, Feb 28, 2005 at 09:48:49PM +0100, Nico Golde wrote:
> >  The candidates are:
> > 
> >   o Matthew Garrett  [EMAIL PROTECTED]
> 
> ^^ Is the email address wrong?
> There is no entry for http://qa.debian.org/[EMAIL PROTECTED]

But there is such entry in http://db.debian.org/

Noone force you to use [EMAIL PROTECTED] to maintain your packages,
although it's AFAIR recommended.

Matthew uses the following:
http://qa.debian.org/[EMAIL PROTECTED]

regards
fEnIo
-- 
  ,''`.  Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo
 : :' :   32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland
 `. `'   phone:+48602383548 | proud Debian maintainer and user
   `-  http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001


signature.asc
Description: Digital signature

Re: [OT] maildir

[Henning Makholm]

Scripsit Bernd Eckenfels <[EMAIL PROTECTED]>

> Thats why I responded, there is not really a need to modify maildir
> files,

That depends. I sometimes want to archive the text people wrote to me
without wasting disk space (and performance when I search my mail
archive) on attachments that I don't need anymore. Mutt provides a
nice UI for removing attachments, which involves modifying the message
file.

-- 
Henning Makholm "... and that Greek, Thucydides"


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [OT] maildir

[Henning Makholm]

Scripsit Brian May <[EMAIL PROTECTED]>

> Sure, these are implementation issues that could be solved, but
> currently mbox wins.

Who says you have to use either one or the other for everything? I use
maildir for incoming mail but mbox files for most of my old saved
mail. Works nice and seamlessly.

-- 
Henning Makholm   "`Update' isn't a bad word; in the right setting it is
 useful. In the wrong setting, though, it is destructive..."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Why are you guys using user space utilities not written by us that seem to not work? Could you change who is the debian maintainer for us?

[Steve Langasek]

On Mon, Feb 28, 2005 at 11:45:11PM +0100, José Luis Tallón wrote:
> From what i read below, there is somebody actually using QtParted for 
> their installer.

Someone who has a 4-month-old (or older) fork of the parted packages.
(The Debian parted package stopped build-depending on libreiserfs at the
beginning of November).  Not much of a reason to hurry, if you ask me...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

[Joe Wreschnig]

On Mon, 2005-02-28 at 21:28 +, Roger Leigh wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> "Nelson A. de Oliveira" <[EMAIL PROTECTED]> writes:
> 
> > WMAnsiEd is an ANSI editor with functions like line drawing, ellipse,
> > box, etc., written in Qt. All IBM ANSI and ASCII characters are
> 
> "ANSI" is pretty meaningless as a "standard", since ANSI standardised
> many different things.  Perhaps you mean it implements ISO-6429
> (ECMA-48) SGR control sequences, or maybe something entirely
> different?  Either way, it would help if you were much more specific.
> 
> (This applies equally to the other ITP.)

For most of us who grew up on IBM PC systems in the DOS days, "ANSI" was
a character set / graphics style first, and an organization second. I
don't know what the official standards for the character set and
terminal specifications are, but people who are interested are going to
be looking for "ANSI" or "ANSI graphics", not a standards document
number.

(Compare the usage of "ISOs" to refer to CD images regardless of their
status as ISO-9660 filesystems and ISO's other standards.)
-- 
Joe Wreschnig <[EMAIL PROTECTED]>


signature.asc
Description: This is a digitally signed message part

Re: [OT] maildir

[Ron Johnson]

On Tue, 2005-03-01 at 09:03 +1100, Brian May wrote:
> > "Michelle" == Michelle Konzack <[EMAIL PROTECTED]> writes:
> 
> >> > inefficient at storing large number of very small files (due
> >> to block > size limitations of file system), and more
> >> complicated to > transfer/move/share.
> 
> Michelle> What is complicate ?  You need only the right
> Michelle> programs...
> 
> Perhaps I should elaborate on this point.
> 
> If I want to allow people to download a mbox folder (consider mailing
> list archive), all I do is put in under a HTTP accessible
> directory. People only need to download one file, and IIRC, there is a
> standard (or defacto standard) MIME type for mbox files. I believe a
> browser will automatically start mutt. In fact, I believe this will
> work even if the file is gzipped.
> 
> Now take Maildirs... Sure, I could tar.gz the entire directory, but
> this means the recipient must manually untar it before accessing it.
> I don't believe there is a standard MIME type to distinguish these
> files either. As far as your browser is concerned, it isn't "Maildir"
> format, it is "gzipped tar format".

You mean you don't gzip mbox files before putting them "out there"
for public access?

Besides, there's always maildir2mbox, or a wrapper around whatever
library call that any MUA (like Evo & KMail) uses when it moves 
things from a Maildir folder to an mbox "folder".

> Also, all mailing list software I have seen so far exclusively uses
> mbox files.

Sure, since all it does is append.

> Sure, these are implementation issues that could be solved, but
> currently mbox wins.

In certain narrow cases.  Any time, though, that you have the MUA
updating a big mbox at the same time an MTA is writing to it, issues
will occur.

And then there's NFS.  If $USER is mounting $HOME, then mbox files
could get corrupted, but Maildir won't.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"You don't want give people a reason to not invite you to the hot
parties."
Pat Sajak, on being a Republican in Hollywood


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [OT] maildir

[Ron Johnson]

On Mon, 2005-02-28 at 23:46 +, Henning Makholm wrote:
> Scripsit Brian May <[EMAIL PROTECTED]>
> 
> > Sure, these are implementation issues that could be solved, but
> > currently mbox wins.
> 
> Who says you have to use either one or the other for everything? I use
> maildir for incoming mail but mbox files for most of my old saved
> mail. Works nice and seamlessly.

Exactly.

-- 
-
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.

"Whatever may be the moral ambiguities of the so-called demoratic
nations and however serious may be their failure to conform
perfectly to their democratic ideals, it is sheer moral
perversity to equate the inconsistencies of a democratic
civilization with the brutalities which modern tyrannical states
practice."
Reinhold Nieburhr, ca. 1940


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Goswin von Brederlow]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
>> Peter Samuelson <[EMAIL PROTECTED]> writes:
>> 
>> > [Goswin von Brederlow]
>> >> Which also avoids that packages will be unavailable on every new
>> >> architecture debian introduces because the maintainer has to adjust
>> >> the Architecture: line.
>> >
>> > I suppose it'd be nice to be able to use !foo in the Architecture: line
>> > for cases where something is known not to be supportable on a
>> > particular small subset of arches, through toolchain bugs or whatever.
>> 
>> As a sidenote, wanna-build and buildd completly ignore the
>> architecture line (apart from arch:all) and build packages anyway.
>
> Well, somewhat :-)
>
> they /attempt/ the build. sbuild will detect that it is not actually a
> package for this architecture, and will break it off right when the
> source package is extracted.

It does? How does that work for packages with only a minimal control
file that generate a full contol file during build? I see the Arch
check of the dsc file in line 742-484 but that is very unreliable.
Anything I missed?

I believe the dpkg behaviour to set "Architecture: any" for sources
that build arch dependent and independent packages (as opposed to
e.g. Architecture: all i386 powerpc) makes it impossible to reliably
decide if a package should be build for an arch.

>> Anything in the control file is purely informative to the buildd admin
>> at this point.
>
> No, sbuild does check more things.

Ok, slightly exagerated, but a lot of packages would get build by sbuild
wrongfully if it weren't for packages-arch-specific in wanna-build.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#297487: ITP: eleven -- programming language for creating reliable, scalable web applications

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: eleven
  Version : 1.0
  Upstream Author : Joseph Morrison <[EMAIL PROTECTED]>
* URL : http://eleven.sourceforge.net/
* License : GPL
  Description : programming language for creating reliable, scalable web 
applications

Eleven is a programming language for creating reliable, scalable web 
applications.
Applications are expressed in a high-level language with a simple, C-like 
syntax,
from which the Eleven compiler generates complete, ready-to-run implementions 
in PHP
or mod_perl.

Eleven is designed for applications in which rapid development, high 
performance, and
stability are critical - but total control over the look and feel is not (since 
Eleven
generates most of the user interface automatically). Good examples are online 
exams and
surveys, electronic voting, and business workflow applications.

The program is already packaged and is temporarily at 
http://156.35.156.136/inniyah/eleven/

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-2-686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.

[John Hasler]

Joe Wreschnig writes:
> I don't know what the official standards for the character set and
> terminal specifications are...

Whatever IBM said they were.  I believe they are in the IBM PC Technical
Reference Manual: I've got one around here somewhere.
-- 
John Hasler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#297218: ITP: radeontool -- utility to control ATI Radeon backlight functions on laptops

[Joshua Kwan]

Luigi Gangitano wrote:
* Package name: radeontool
 Version : 1.5
 Upstream Author : Frederick Dean <[EMAIL PROTECTED]>
* URL : http://fdd.com/software/radeon/
* License : zlib license
 Description : utility to control ATI Radeon backlight functions on laptops
Aside from the fact that this doesn't support older ATI chipsets, does
this package supersede atitvout?
Package: atitvout
Priority: optional
Section: misc
Installed-Size: 48
Maintainer: Ola Lundqvist <[EMAIL PROTECTED]>
Architecture: i386
Version: 0.4-3
Depends: libc6 (>= 2.3.2.ds1-4)
Filename: pool/main/a/atitvout/atitvout_0.4-3_i386.deb
Size: 19616
MD5sum: 2cdbb42f45d0722522defb2c202a447c
Description: ATI TV Out Support Program
 This utility program may be used for executing several configuration
 commands for the TV Out connector of ATI Rage Mobility P/M graphics
 boards under GNU/Linux on i386. Primarily it is intended to enable TV
 Out support after bootup and for switching the used TV standard from
 NTSC to PAL.
--
Joshua Kwan


signature.asc
Description: OpenPGP digital signature

Re: Any reason why I'm not CCed by bugs of my packages?

[Andreas Tille]

On Mon, 28 Feb 2005, Joel Aelwyn wrote:
I just make it a regular habit to scan my packages via the web interface,
if only to remind myself about the wishlist bugs sitting on some of them.
Sure, that's why I detected the bug just in time, but this personal
habit is no excuse that a function of the BTS might work or might
work not.
Nothing's perfect.
Sure - but arent we here to report and fix bugs - also the bugs
of the BTS?  I do not understand your posting.
Kind regards
  Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Let's remove mips, mipsel, s390 ... [or have strict arch: control? ]

[Wouter Verhelst]

On Tue, Mar 01, 2005 at 01:28:58AM +0100, Goswin von Brederlow wrote:
> Wouter Verhelst <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Feb 28, 2005 at 08:18:56PM +0100, Goswin von Brederlow wrote:
> >> Peter Samuelson <[EMAIL PROTECTED]> writes:
> >> 
> >> > [Goswin von Brederlow]
> >> >> Which also avoids that packages will be unavailable on every new
> >> >> architecture debian introduces because the maintainer has to adjust
> >> >> the Architecture: line.
> >> >
> >> > I suppose it'd be nice to be able to use !foo in the Architecture: line
> >> > for cases where something is known not to be supportable on a
> >> > particular small subset of arches, through toolchain bugs or whatever.
> >> 
> >> As a sidenote, wanna-build and buildd completly ignore the
> >> architecture line (apart from arch:all) and build packages anyway.
> >
> > Well, somewhat :-)
> >
> > they /attempt/ the build. sbuild will detect that it is not actually a
> > package for this architecture, and will break it off right when the
> > source package is extracted.
> 
> It does? How does that work for packages with only a minimal control
> file that generate a full contol file during build?

Such packages need to make sure their initial control file contains
enough information about the architectures a package can be built on
anyway if they want dpkg-buildpackage to run successfully.

> I see the Arch check of the dsc file in line 742-484 but that is very
> unreliable. Anything I missed?

Haven't looked at the source, only know the behaviour when a
foreign architecture's package's build is attempted. Something like

Architecture not in control file: i386 -- skipped

or so.

> >> Anything in the control file is purely informative to the buildd admin
> >> at this point.
> >
> > No, sbuild does check more things.
> 
> Ok, slightly exagerated, but a lot of packages would get build by sbuild
> wrongfully if it weren't for packages-arch-specific in wanna-build.

'some', rather than 'a lot'; but apart from that, correct.

-- 
 EARTH
 smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 WATER
 -- with thanks to fortune


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

pyblosxom up for adoption

[Fredrik Steen]

Anyone using pyblosxom and would like to adopt it?

I'm not using pyblosxom anymore and would like to give it away
to more caring hands.

-- 
 .''`. Fredrik Steen, [EMAIL PROTECTED]
: :' : 2CD6 C838 BE77 795F 5EF1  3E5B DA91 EE7B A58E 164
`. `'  http://www.stone.nu/
  `--  http://www.debian.org/



signature.asc
Description: Digital signature