Re: NMUs for Python Policy -- please hold them a little

[Frank Küster]

Roland Mas <[EMAIL PROTECTED]> wrote:

> Loïc Minier, 2006-06-23 16:40:06 +0200 :
>
> [...]
>
>>  Probably the biggest reason why I feel this extra time would be
>>  useful is because the new Python Policy and the tools supporting it
>>  saw non-negligible changes in the last days.  All of this only
>>  settled very recently.  This explains why maintainers have been
>>  reluctant in moving packages to the new policy immediately.
>
> And here I was, thinking a policy was a collection of tried and true
> best practices turned into official status after they've been in use
> by most concerned packages for some time.  

I think this is what should be expected most of the time.  However, you
can't always achieve that: In this case, a change was to be made that
required updating application packages, "basic packages" of some area
(like the python* packages here) and helper packages (debhelper) at the
same time.  This could /maybe/ be tested in experimental or some local
testbed.  On the other hand, it also required to cater for different
packaging styles, maintainer flavors etc., and this cannot be tested.

Similarly, when we established the TeX sub-Policy, we also started to
write up what we already had agreed upon.  Some things resulted in basic
TeX and add-on packages being in violation of must-clauses from the
start, just because the conforming basic TeX packages were only in
experimental, and hardly any add-on maintainer new about it.  Of course
it took some time until things settled.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Bug#375462: ITP: kwin-style-serenity -- Plasmoid inspired window decoration for KDE

[Sune Vuorela]

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: kwin-style-serenity
  Version : 0.9
  Upstream Author : Remi Villatel 
* URL : http://www.kde-look.org/content/show.php?content=35954
* License : GPL
  Programming Lang: QT
  Description : Plasmoid inspired window decoration for KDE

 highly configurable window decoration with many different
 icons and good possibility to configure the menu bar as well.
 .
 This package also ships some colorschemes
 .
 This is a window decoration, not a style.

-- System Information:
Debian Release: unstable/experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-k7
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Bug#375461: ITP: kde-style-serenity -- Serenity widget style for kde

[Sune Vuorela]

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela <[EMAIL PROTECTED]>


* Package name: kde-style-serenity
  Version : 0.9
  Upstream Author : Remi Villatel <[EMAIL PROTECTED]>
* URL : http://www.kde-look.org/content/show.php?content=35954
* License : LGPL-2
  Programming Lang: QT
  Description : Serenity widget style for kde

 widget style without too many lines to avoid
 "recursive frames effect"
 serenity is based off lipstik engine


-- System Information:
Debian Release: unstable/experimental
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (200, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-k7
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)


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

Re: Reclaiming automake

[Scott James Remnant]

On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote:

> Scott James Remnant dropped me an email recently, interested in
> improving the automake situation in Ubuntu and Debian[0].
> 
> [0] Their plan, which mirrors mine, is documented here:
> https://wiki.ubuntu.com/AutomakeTransition
> 
If you could have another read through of that spec, now it's
post-draft, and make sure we're still both planning the same thing
that'd be great.  I don't see any reason for Ubuntu to go a different
direction to Debian here.

In particular I had a momentary thought about what packages should
actually depend/build-depend on now -- could you check that.

> Now before I can implement this master plan, I need to fix all the
> packages that still build depend on "automake"[1]. To proceed with
> this I'd like to file wishlist bugs (with patches) against these
> packages one week from today. One week after that, with the Release
> Team's blessing, I'd like to start NMUing as much of these packages as
> I can. Once that is complete, I'd like to make the transition and
> raise the severity of any of bugs that remain.
> 
We should probably work together to cut the time down to make these
patches.

Scott
-- 
Scott James Remnant
[EMAIL PROTECTED]


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

Re: Why does doc packages need to contain gzipped files?

[Frank Küster]

Ron Johnson <[EMAIL PROTECTED]> wrote:

> Adeodato Simó wrote:
>> * Ron Johnson [Sat, 24 Jun 2006 09:34:29 -0500]:
>> 
>>> How does that package get from the Debian mirror to your
>>> computer?
>> 
>>> 2 ways: - network - mailed CD/DVD
>> 
>>> In either case, *size* does matter.
>> 
>> No, this is not about network transfer size, only about disk
>> space, because files inside a .deb file are inside a _gzipped_
>> tar file. (Plus, IIRC, a gzipped tar of uncompressed files
>> usually gives a bigger rate than a compressed tar of gzipped
>> files. So there.)
>
> Point taken.
>
> Wasn't there a discussion a month or so ago regarding whether PDF
> files should be gzipped or not?

There was.  It ended with no conclusion.  Here's my view of the outcome,
from pure recollection without looking anything up:

- gzipping PDF files does save some space; bz2 compression would save
  even more.  Naturally, compressing files that are internally
  uncompressed gives better results.

- among the people that maintain packages with lots of pdf.gz files, no
  one seems really opposed to shipping them uncompressed.  But also
  nobody seemd to be willing to do the first step, especially since
  there is no consensus about not compressing them.


So far for the past;  at the moment I think that it would be a good
compromise to not compress PDF files in dedicated -doc packages, while
keeping them compressed in mixed packages.  This would mean that we
should *not* wait for debhelper to switch, but instead add -X.pdf to
dh_compress in tetex-doc.  But this is just my personal opinion, and not
a very fixed one - it still has to be discussed among the Debian TeX
Task Force

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Why does doc packages need to contain gzipped files?

[Frank Küster]

Osamu Aoki <[EMAIL PROTECTED]> wrote:

> Gzipping PDF provides no real space saving advantage

What do you mean with "no real"?  There is a considerable saving, as
I've shown in the previous thread a couple of weeks ago.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Why does doc packages need to contain gzipped files?

[Frank Küster]

Osamu Aoki <[EMAIL PROTECTED]> wrote:
>> http://lists.debian.org/debian-devel/2006/05/msg01440.html).
[...]
> Now that I know files which was compressible by gzip had good cmpression
> already inside PDF, I am leaning toward publishing PDF without gzipping
> even now.  Thanks.
>
> Just to rehash facts,
>
>   228023 fhs-2.3.pdf.gz
>   510762 fhs-2.3.pdf
>  2883196 fhs-2.3.uncompr.pdf
>   529987 fhs-2.3.recompr.pdf
>
>   798976 reference.en.pdf.gz
>  1239893 reference.en.pdf
>  2759682 reference.uncompress.en.pdf
>  1261303 reference.recompress.en.pdf
>
> pdftk can not be used to further compress existing pdf files in the
> archive internally.  They are well compressed.

This is expected, because they are generated with pdflatex or gs'
PS-to-PDF conversion mechanisms, and those use gzip with -9 internally,
so that's the best you can get with gzip.  It can still be compressed
further because in PDF, only some parts are allowed to be compressed
internally.

As I said in the earlier posting referenced above, *if* we really want
to go for smallest space, we should produce PDF files without internal
compression and use bz2 instead.  Maybe this is an option for
documentation inside udeb's, if there are any PDF files at all.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Why does doc packages need to contain gzipped files?

[Frank Küster]

Martin Wuertele <[EMAIL PROTECTED]> wrote:

> * Eduard Bloch <[EMAIL PROTECTED]> [2006-06-25 12:06]:
>
>> And besides of that, compression does not make sense on most PDFs as
>> pointed out by yuo/me/many others and the remaining PDFs have good
>> chances to recompressed internally.
>  
> And again: I'm here with you, pdf.gz does not make sense. Propably using
> the built-in compression might.

No, this is factually wrong.  PDF files produced on a Debian system with
any of the usual tools already have maximal internal compression,
there's no way to further improve that (except buying Adobe and allowing
internal bz2/7zip/whatever in the PDF standard...).

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Problems with PDF creation (was: Why does doc packages need to contain gzipped files?)

[Frank Küster]

Osamu Aoki <[EMAIL PROTECTED]> wrote:

> Wait, there is less than 70MB of PDF.  Yes, this is true.  Due to
> difficulties of making nice PDF out of XML/SGML without hitting FTBFS,
> many packages does not bother PDF creation.  Most of the doc containing
> PDF are:

Can you please be more specific about "difficulties ... nice ... FTBFS"?
There have been some problems when teTeX 3.0 was uploaded to sid after
sarge's release, but that was a one-time problem (and the central
packages like debiandoc-smgl, linuxdoc etc. were fixed quite fast;
db2latex was harder).  Do you imply that people stopped generating PDF
files last summer/autumn because of these problems?  Or are there other
problems I am not aware of?

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Why does doc packages need to contain gzipped files?

[Steinar H. Gunderson]

On Mon, Jun 26, 2006 at 10:11:57AM +0200, Frank Küster wrote:
> No, this is factually wrong.  PDF files produced on a Debian system with
> any of the usual tools already have maximal internal compression,
> there's no way to further improve that (except buying Adobe and allowing
> internal bz2/7zip/whatever in the PDF standard...).

Decompress the internal deflate streams, and compress the resulting .pdf
file? ;-)

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


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

Re: *-doc package should not gzip PDF file

[Preben Randhol]

Paul Wise <[EMAIL PROTECTED]> wrote on 26/06/2006 (05:08) :
> On Sun, 2006-06-25 at 16:51 -0400, James R. Van Zandt wrote:
> 
> > >   I have no idea how debhelper works. Are there anybody out there that
> > >   can help with getting it to stop gzipping files in -doc?
> > 
> > dh_compress already has a list of file extensions where (re-)compressing
> > doesn't make sense.  I've submitted Bug#375406 with a patch (below) to
> > add .pdf to the list.
> 
> If I read the discussion correctly up to this point, some PDFs are
> fairly compressible and some are not. Perhaps dh_compress could evaluate
> this for each .pdf and only compress those files where the saving is
> significant (say 40%)?

Why this space saving concern for -doc packages? I really don't get it.
If you want to save space gzip all html files and make web browsers work
out-of-the-box with gzipped html files. If a pdf file is huge because of
lack of internal compression then isn't it better to use a tool that
compresses internally than to fix the symptoms?

Anyway I'm asking for user friendliness.

As for the statistics that has been brought up. Are there +3000 pdf
files in the doc-packages of Debian?

Preben


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

Re: *-doc package should not gzip PDF file

[Preben Randhol]

Osamu Aoki <[EMAIL PROTECTED]> wrote on 25/06/2006 (12:17) :
> I think I gave wrong impression to you.

Yes :-)

I thought you meant the usual: OK I'll fix your problem if you provide
the solution :-)

> Most of PDF.GZ are under me and tetex-doc people.  Once we find good
> technical solution, we may do it without policy change.  See internal
> compression discusion too.

I see. Thanks.

Preben


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

Re: Bug#374997: ITP: utf8-migration-tool -- tool to migrate a Debian system to UTF-8

[Martin-Éric Racine]

su, 2006-06-25 kello 21:42 +0200, Denis Barbier kirjoitti:
> (I forgot to Cc: d-d in my first reply)
> 
> On Fri, Jun 23, 2006 at 01:12:23AM +0300, Martin-Éric Racine wrote:
> [...]
> > > > I would gladly welcome co-maintainance with Debian's i10n/i18n team.
> > > 
> > > What are his benefits over convmv?
> > 
> > convmv is good at doing recursive batch conversions from command line.
> > 
> > utf8-migration-tool is good at inspecting and reporting the encoding,
> > and it operates as a user-friendly GUI druid written in PyGTK.
> > 
> > The telling takes longer than the showing, so I invite interested
> > parties to simply try it. The package is arch:all and available in my
> > personal repository (source+binary).
> 
> I would love to, but as you can see from this snapshot, this program
> is not usable with a white on black theme.  Can you please fix it?

That is a leftover from Tollef's original code in wizard.py, where the
UI colors are hard-coded, rather than inherited via the GTK theme.

I can see the lines where this is taking place, but I'm not familiar
enough with GTK coding to know how to fix it.

Help is welcome.

-- 
Martin-Éric Racine
http://q-funk.iki.fi


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

Re: additions to dpkg-architecture and dpkg-cross

[Pjotr Kourzanov]

Volker,

  Great that you've put this up to public. Still, for this to be
accepted, we need to come up with patches for apt that contain an
algorithm that will pick versions of packages matching user's
requirements, known architecture hierarchies (i386->i486->...)
and available sources. Currently, apt is quite dumb in that respect
AFAIK, i.e. it only looks at binary-$DEB_HOST_ARCH while it could
also look binary-all, binary-$DEB_HOST_ARCH, and
binary-$DEB_HOST_SUPERARCH (where $DEB_HOST_SUPERARCH=i386 when
DEB_HOST_ARCH=i686) etc.

  I've used this sort of logic for rootfs generation script I've been
playing around with (I'll be bold enough to post it here just for
example). It takes a Debian architecture name as $1 and then for
each package name that it reads from /dev/stdin it finds a version
from list of source repositories in this order:

1. binary-$DEB_HOST_ARCH (e.g. armv5te)
2. binary-$DEB_HOST_SUPERARCH (e.g. arm)
3. local compiles (e.g. /usr/src/Debian)
4. binary-all.

  It only has one-level hierarchy, but that's just a home-grown sample...

  Also, dpkg-cross's logic of barfing at conversion between non-equal
architecture (names) MUST be changed... It really should also look
at the architecture hierarchy and allow for "down-casting" of
packages to their cross- counterparts since you really don't want
to compile the whole distribution with optimizing/cross compilers
(we are not Gentoo are we?).

  Furthermore, isn't there a dpkg requirement that all packages
installed must have either DEB_HOST_ARCH or "all" as Architecture?

Should we somehow coordinate our efforts to make this into official
apt/dpkg/dpkg-cross?

Pjotr

Volker Grabsch wrote:
> Dear Debian Developers,
> 
> I've been pleased to summarize some ideas for the general public.
> More details and sources can be found at the end of this mail.
> I'm not subscribed to all lists, so please CC any replies to me.
> 
> --
> 
> I propose to add more CPU types to dpkg-architecture. In particular,
> I'd like to see the different i386 architectures there, i.e.
> i586, i686, k6, ...
> 
> The dpkg-cross tool is currently only used for cross compiling
> applications. However, dpkg-cross is a more generic tool. The
> "dpkg-buildpackage" wrapper of dpkg-cross allows you to compile
> a package with different compilers, without the need to change
> your debian/rules. (usually, some compatibility changes are needed
> to make the debian/rules file "cleaner", but that's all)
> 
> For instance, some programs with lots of calculations (e.g. mplayer)
> are compiled with different processor optimizations (e.g. mplayer-i586).
> Such packages are created by very redundant entries in debian/rules.
> Exactly such redundancy is removed by dpkg-cross.
> 
> Also, these optimized versions get names like "mplayer-i586",
> but their architecture is set to "i386". That means, the *real*
> architecture is encoded in the package name instead of the package's
> architecture.
> 
> This is a work around the inability of apt to automatically use
> the best suited binary packages. (e.g. uses on a i686 system the
> mplayer-i586 instead if mplayer-i386, and the kernel-image-i686)
> 
> If one day apt evolves, packages like mplayer-i586 will step in their
> way. The "Package:" field should not contain architectural information.
> The "Architecture:" field serves that purpose.
> 
> Until APT becomes aware of multiple architectures, this won't change
> much. However, there are still lots of interesting cases where
> more architectures are desirable.
> 
> For example, suppose you support a new OS, such as the w32 platform.
> Currently, your only choice is "w32-i386", which means that you must
> use an i486-mingw32msvc Compiler. However, for a w32 system a i486
> compile doesn't make a lot of sense. Since those systems (except very
> old Windows versions) need at least a Pentium, it is reasonable to
> compile such a distribution at least for i586, not i486.
> 
> That means, the "linux" OS dictates that i386 should mean "at least
> i486", while other OSes (e.g. win32) have different needs (e.g. "at
> least i586"). Such dependencies between the OS and CPU type are simply
> unnecessary and disturbing.
> 
> In that example, there should be a "linux-i386" platform (which may
> be abbreviated to i386), while dpkg-architecture should also allow
> a Debian platform like "w32-i586". This proposal is similar to
> the addition of multiple arm CPU variants to dpkg-architecture.
> 
> Of course, if you want to allow, e.g. the -i386 packaes to be installed
> on a -i586 distribution, some bigger parts of dpkg and apt would have
> to be changed. However, that is not my proposal at all. I don't intend
> to create a w32-i586 Debian distribution which must also accept w32-i386
> packages. I want to create an entire w32-i586 distribution.
> (well, currently, I just want to provide cross compiling packages for
> such a platform)
> 
> I al

Re: *-doc package should not gzip PDF file

[George Danchev]

On Monday 26 June 2006 11:46, Preben Randhol wrote:
> Paul Wise <[EMAIL PROTECTED]> wrote on 26/06/2006 (05:08) :
> > On Sun, 2006-06-25 at 16:51 -0400, James R. Van Zandt wrote:
> > > >   I have no idea how debhelper works. Are there anybody out there
> > > > that can help with getting it to stop gzipping files in -doc?
> > >
> > > dh_compress already has a list of file extensions where
> > > (re-)compressing doesn't make sense.  I've submitted Bug#375406 with a
> > > patch (below) to add .pdf to the list.
> >
> > If I read the discussion correctly up to this point, some PDFs are
> > fairly compressible and some are not. Perhaps dh_compress could evaluate
> > this for each .pdf and only compress those files where the saving is
> > significant (say 40%)?
>
> Why this space saving concern for -doc packages? I really don't get it.
> If you want to save space gzip all html files and make web browsers work
> out-of-the-box with gzipped html files. If a pdf file is huge because of
> lack of internal compression then isn't it better to use a tool that
> compresses internally than to fix the symptoms?
>
> Anyway I'm asking for user friendliness.
>
> As for the statistics that has been brought up. Are there +3000 pdf
> files in the doc-packages of Debian?

You can stroke such sort of queries at http://ara.edos-project.org.
For instance, regex'ing on the "Package:" field, like that:

package:/-doc$/ 
Total 832 packages (and 2090 versions).

package:/^doc-/ 
Total 44 packages (and 97 versions).

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: *-doc package should not gzip PDF file

[Frank Küster]

Preben Randhol <[EMAIL PROTECTED]> wrote:

> If a pdf file is huge because of
> lack of internal compression then isn't it better to use a tool that
> compresses internally than to fix the symptoms?

The internal compression allowed in a PDF file is dictated by the PDF
specification.  This open standard is owned by Adobe.  Even if this was
a free standard, or you buy Adobe, you couldn't just have some
discussion and then change it.  It would also require to enhance the
existing tools (most notably Acrobat and Adobe Reader).

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Testing excuses question

[Jiri Palecek]

Hello,

I've seen some mysterious excuses on http://bjorn.haxx.se/debian

For example:

look at the package arch2darcs. There is:

arch2darcs is adding amd64 binaries (no new version) 
arch2darcs is waiting for tla

this looks OK.

But then

Updating tla makes 1 depending packages uninstallable on i386: 
arch2darcs

And more

Dependency analysis (including build-depends; i386 only):

info: arch2darcs depends on tla >= 1.3 (ok, testing has version 1.3.3-3)

So:

- How can be arch2darcs be waiting for tla, if testing already has some version.
  I could understand it is waiting for tla to add amd64 packages too, but it 
blocks
  other arches.

- How can updating tla make arch2darcs on i386, if testing has version 1.3.3-3,
  is trying to update to 1.3.3-3.3 (it seems the maintainer does some 
numerology :-)
  and the dependency is in the form >=1.3?

It seems these packages are blocked by neon (which also block subversion, 
kdevelop
and rpm). There is  also another gem concerning neon:

neon depends on libssl-dev >= 0.9.8a-3 but testing has 0.9.8b-2 (unstable 
has 0.9.8b-2)

It seems that all packages the webpage says are directly dependent on neon
already have a version that is not too young and is RC bug free, so if there 
aren't any
other reasons, they could go in.

BTW what is the exact reason for this situation?

Regards
   Jiri Palecek
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193


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

Re: Testing excuses question

[Ozgur Karatas]

success,
and test set in webalizer? 

http://bjorn.haxx.se/debian/points.html

 ,''`.  Ozgur Karatas
: :' :  [EMAIL PROTECTED]
`. `'   http://www.ozgurkaratas.com
  `-Powered By Debian GNU\Linux

 Jiri Palecek <[EMAIL PROTECTED]> demiş ki: 
> Hello,
> 
> I've seen some mysterious excuses on http://bjorn.haxx.se/debian
> 
> For example:
> 
> look at the package arch2darcs. There is:
> 
> arch2darcs is adding amd64 binaries (no new version) 
> arch2darcs is waiting for tla
> 
> this looks OK.
> 
> But then
> 
> Updating tla makes 1 depending packages uninstallable on i386: 
> arch2darcs
> 
> And more
> 
> Dependency analysis (including build-depends; i386 only):
> 
> info: arch2darcs depends on tla >= 1.3 (ok, testing has version 1.3.3-3)
> 
> So:
> 
> - How can be arch2darcs be waiting for tla, if testing already has some 
> version.
>   I could understand it is waiting for tla to add amd64 packages too, but it 
> blocks
>   other arches.
> 
> - How can updating tla make arch2darcs on i386, if testing has version 
> 1.3.3-3,
>   is trying to update to 1.3.3-3.3 (it seems the maintainer does some 
> numerology :-)
>   and the dependency is in the form >=1.3?
> 
> It seems these packages are blocked by neon (which also block subversion, 
> kdevelop
> and rpm). There is  also another gem concerning neon:
> 
> neon depends on libssl-dev >= 0.9.8a-3 but testing has 0.9.8b-2 (unstable 
> has 0.9.8b-2)
> 
> It seems that all packages the webpage says are directly dependent on neon
> already have a version that is not too young and is RC bug free, so if there 
> aren't any
> other reasons, they could go in.
> 
> BTW what is the exact reason for this situation?
> 
> Regards
>Jiri Palecek

Re: (doc) 31. sarge install and postfix building

[Ozgur Karatas]

hi,
i writing Debian GNU\Linux Install and Building Postfix Mail Server document.

if pdf format  : http://www.iucoders.com/article_detail.jsp?nid=50
in html format: 
http://www.olympos.org/article/articleview/1861/1/10/debian_gnulinux_ile_postfix_posta_sunucusu_kurulumu
 

 ,''`.  Ozgur Karatas
: :' :  [EMAIL PROTECTED]
`. `'   http://www.ozgurkaratas.com
  `-Powered By Debian GNU\Linux

 "Frank Küster" <[EMAIL PROTECTED]> demiş ki: 

Re: (doc) 31. sarge install and postfix building

[Ralf Hildebrandt]

* Ozgur Karatas <[EMAIL PROTECTED]>:

> if pdf format  : http://www.iucoders.com/article_detail.jsp?nid=50
> in html format: 
> http://www.olympos.org/article/articleview/1861/1/10/debian_gnulinux_ile_postfix_posta_sunucusu_kurulumu

Dude, it's Turkish :) That makes it a tad bit hard to read...

-- 
Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]


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

Bug#375496: O: drupal

[Hilko Bengen]

Package: wnpp
Severity: normal

I am orphaning the drupal package. I am no longer using it.

Advice for the DD who wants to take this over: Create separate
versions for major upstream releases: drupal4.5, drupal4.6, drupal4.7.
Don't waste time trying to do automatic database updates -- that
Simply Won't Work. BTDT.

Cheers,
-Hilko


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

Re: Re: Testing excuses question

[Jiri Palecek]

> success,
> and test set in webalizer? 

> http://bjorn.haxx.se/debian/points.html

Sorry, I do not understand. You mean the "breaks xx packages" thingy?

I have already said, that of these 74 packages, 15 are dependent,
and they are more or less prepared to enter testing along with
neon. The rest only depends on those 15, and seem (I have not 
checked all) to be OK if the 15 go in (eg. they don't have to go in).

Regards
Jiri Palecek
__
Mit WEB.DE iNews werden Sie über die Ergebnisse der wichtigsten WM-Begegnungen
per SMS informiert: http://freemail.web.de/features/inews.htm/?mc=021202

Re: Why does doc packages need to contain gzipped files?

[Osamu Aoki]

On Mon, Jun 26, 2006 at 09:59:36AM +0200, Frank Küster wrote:

> There was.  It ended with no conclusion.  Here's my view of the outcome,
> from pure recollection without looking anything up:
> 
> - gzipping PDF files does save some space; bz2 compression would save
>   even more.  Naturally, compressing files that are internally
>   uncompressed gives better results.
> 
> - among the people that maintain packages with lots of pdf.gz files, no
>   one seems really opposed to shipping them uncompressed.  But also
>   nobody seemd to be willing to do the first step, especially since
>   there is no consensus about not compressing them.
> 
> 
> So far for the past;  at the moment I think that it would be a good
> compromise to not compress PDF files in dedicated -doc packages, while
> keeping them compressed in mixed packages.  This would mean that we
> should *not* wait for debhelper to switch, but instead add -X.pdf to
> dh_compress in tetex-doc.  But this is just my personal opinion, and not
> a very fixed one - it still has to be discussed among the Debian TeX
> Task Force

Seconded.


signature.asc
Description: Digital signature

Re: Why does doc packages need to contain gzipped files?

[Osamu Aoki]

On Mon, Jun 26, 2006 at 10:00:57AM +0200, Frank Küster wrote:
> Osamu Aoki <[EMAIL PROTECTED]> wrote:
> 
> > Gzipping PDF provides no real space saving advantage
> 
> What do you mean with "no real"?  There is a considerable saving, as
> I've shown in the previous thread a couple of weeks ago.

Some has 50%, many debiandoc ones were 30%, some were 10% range.  I
posted list in thios thread.  Afterall, I thought 50% over 1/5 is not
really a lot since pdf is shrunk 1/5th with random access capability.

Osamu

Re: Problems with PDF creation (was: Why does doc packages need to contain gzipped files?)

[Osamu Aoki]

On Mon, Jun 26, 2006 at 10:17:20AM +0200, Frank Küster wrote:
> Osamu Aoki <[EMAIL PROTECTED]> wrote:
> 
> > Wait, there is less than 70MB of PDF.  Yes, this is true.  Due to
> > difficulties of making nice PDF out of XML/SGML without hitting FTBFS,
> > many packages does not bother PDF creation.  Most of the doc containing
> > PDF are:
> 
> Can you please be more specific about "difficulties ... nice ... FTBFS"?
> There have been some problems when teTeX 3.0 was uploaded to sid after
> sarge's release, but that was a one-time problem (and the central
> packages like debiandoc-smgl, linuxdoc etc. were fixed quite fast;
> db2latex was harder).  Do you imply that people stopped generating PDF
> files last summer/autumn because of these problems?  

That pretty much it.

> Or are there other
> problems I am not aware of?

doc-debian used to loop 6 times to build PDF. Many Debiandoc packages
did not contain PDF for cjk.  New build script is much more stable.

I know some package build PDF first as upstream.

I fupdown does not come with documentation.

...

Re: Testing excuses question

[Andrew Vaughan]

On Monday 26 June 2006 23:08, Jiri Palecek wrote:
> Sorry, I do not understand. You mean the "breaks xx packages" thingy?
>
> I have already said, that of these 74 packages, 15 are dependent,
> and they are more or less prepared to enter testing along with
> neon. The rest only depends on those 15, and seem (I have not
> checked all) to be OK if the 15 go in (eg. they don't have to go in).

Upgrading neon breaks subversion (and other packages), but subversion is 
waiting for both neon and perl.  Perl FTBFS on hppa and mips.  

HTH
Andrew V.


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

Re: Why does doc packages need to contain gzipped files?

[Thomas Viehmann]

Frank Küster wrote:
> There was.  It ended with no conclusion.  Here's my view of the outcome,
> from pure recollection without looking anything up:
> 
> - gzipping PDF files does save some space; bz2 compression would save
>   even more.  Naturally, compressing files that are internally
>   uncompressed gives better results.
> 
> - among the people that maintain packages with lots of pdf.gz files, no
>   one seems really opposed to shipping them uncompressed.  But also
>   nobody seemd to be willing to do the first step, especially since
>   there is no consensus about not compressing them.

I think that a notable addition (by Olaf v.d.S. IIRC) was that it could
be worthwhile to improve viewers. E.g. kghostview will correctly open
.pdf.gz while gnome-gv will not. Similarly kdvi opens .dvi.gz.
Altough I'm not using KDE in general, my preference for kdvi is
precisely because of that (and reverse search, but that seems to be more
standard nowadays).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Why does doc packages need to contain gzipped files?

[Preben Randhol]

On Mon, 26 Jun 2006 17:21:10 +0200
Thomas Viehmann <[EMAIL PROTECTED]> wrote:

> I think that a notable addition (by Olaf v.d.S. IIRC) was that it
> could be worthwhile to improve viewers. E.g. kghostview will
> correctly open .pdf.gz while gnome-gv will not. Similarly kdvi
> opens .dvi.gz. Altough I'm not using KDE in general, my preference
> for kdvi is precisely because of that (and reverse search, but that
> seems to be more standard nowadays).

You would need to update share-mime-info (or similar packages) too. I
mean so that not only the applications that reads the pdf files work,
but that also rox-filer, nautilus, firefox e.i application that
launches the application for a given mime type knows which program
to call and not file-roller, ark or some other unpacking program.

Best wishes

Preben


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

Re: Why does doc packages need to contain gzipped files?

[Preben Randhol]

On Sun, 25 Jun 2006 12:08:17 +0200
Rolf Kutz <[EMAIL PROTECTED]> wrote:

> Do you think users with small machines shouldn't
> be able to install docs, too? It's just a one line
> script to gunzip all pdfs in /usr/share/doc.

I don't find this a good argument as it is equally a one line script to
bzip2 all pdfs in /usr/share/doc in small computers.


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

Re: Why does doc packages need to contain gzipped files?

[Frank Küster]

Thomas Viehmann <[EMAIL PROTECTED]> wrote:

> Frank Küster wrote:
>> There was.  It ended with no conclusion.  Here's my view of the outcome,
>> from pure recollection without looking anything up:
>> 
>> - gzipping PDF files does save some space; bz2 compression would save
>>   even more.  Naturally, compressing files that are internally
>>   uncompressed gives better results.
>> 
>> - among the people that maintain packages with lots of pdf.gz files, no
>>   one seems really opposed to shipping them uncompressed.  But also
>>   nobody seemd to be willing to do the first step, especially since
>>   there is no consensus about not compressing them.
>
> I think that a notable addition (by Olaf v.d.S. IIRC) was that it could
> be worthwhile to improve viewers. 

Agreed.

> E.g. kghostview will correctly open
> .pdf.gz while gnome-gv will not. Similarly kdvi opens .dvi.gz.
> Altough I'm not using KDE in general, my preference for kdvi is
> precisely because of that (and reverse search, but that seems to be more
> standard nowadays).

I don't know over what you prever kdvi, but xdvi (which is xdvik really,
but the k here has nothing to do with KDE) also opens dvi.gz, and has
done so for long.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: Why does doc packages need to contain gzipped files?

[Sam Hocevar]

On Mon, Jun 26, 2006, Preben Randhol wrote:

> > Do you think users with small machines shouldn't be able to install
> > docs, too? It's just a one line script to gunzip all pdfs in
> > /usr/share/doc.
>
> I don't find this a good argument as it is equally a one line script
> to bzip2 all pdfs in /usr/share/doc in small computers.

   A one-liner that can take hours, whereas gunzipping is quite cheap.

-- 
Sam.


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

Re: Patch cplay to use mplayer with speed-control

[Daniel Michalik]

On 2006-06-23, Kevin B. McCarty <[EMAIL PROTECTED]> wrote:
> If it is optional (that is, if you improve your patch to test for an mplayer
> binary at runtime), you could certainly consider submitting it to the Debian
> maintainer or to upstream. 

I worked on my patch. Now it only extents cplay of the possibility to use
mplayer, but all players of the original version still work. So there is no
_need_ of mplayer, it also works without.

> - It would be more readable if you use unified diff format ("diff -u")
> to show some lines of context.
> - The code where you create the fifo makes it with a predictable
> filename; also, it assumes that if it (or another file of the same name)
> already exists, it may be deleted by the current cplay user.  Hence it
> is susceptible to a very trivial DOS attack.  You ought to fix this
> before submitting the patch.

Thank you, I did like you suggested. The code for the fifo from my first patch
was copied from the control-fifo of the original cplay-1.49. I fixed both in
different ways according to the ideas of the fifo use. I also added equalizer
support and tried fixing 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375060.

I sent my patch to Ulf, the author of cplay and will wait for his reactions.
The cplay-dev mailinglist seems dead, but I will announce it there, too.

Thanks for further comments, see
http://www.argafal.de/cgi-bin/index.pl?page=projcplay for the latest version.

Best regards,
-daniel-
-- 
http://www.blackamp.de

GPG-Key: 0x53BE81EC 
Fingerprint: A854 4C0A FF1A 09DF 5433  0EF8 1CF0 0213 53BE 81EC


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

Re: Why does doc packages need to contain gzipped files?

[Stefano Zacchiroli]

On Mon, Jun 26, 2006 at 05:21:10PM +0200, Thomas Viehmann wrote:
> I think that a notable addition (by Olaf v.d.S. IIRC) was that it could
> be worthwhile to improve viewers.

Seconded.

On the same line, given the habits we are developing nowadays, we should
also improve all command line completion of the affected viewer. We
already have several "viewers" able to open .gz files whose completion
aren't aware of that.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-


signature.asc
Description: Digital signature

Bug#375548: ITP: openvcp -- Linux-VServer Control Panel

[Sebastian Harl]

Package: wnpp
Severity: wishlist
Owner: Sebastian Harl <[EMAIL PROTECTED]>


* Package name: openvcp
  Version : 0.1-beta
  Upstream Author : Gerrit Wyen <[EMAIL PROTECTED]>
* URL : http://openvcp.org/
* License : GPL
  Description : Linux-VServer Control Panel

OpenVCP allows you to manage Linux-VServers (http://linux-vserver.org/) on
several machines using a single webinterface.


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

Bug#365073: ITP: zimpl -- mathematical modeling language for optimization problems

[Joachim Reichel]

* Package name: zimpl
  Version : 2.04
  Upstream Author : Thorsten Koch 
* URL : http://www.zib.de/koch/zimpl/
* License : GPL
  Programming Lang: C
  Description : mathematical modeling language for optimization problems

 Zimpl allows the specification of certain optimization problems - linear
 programs (LPs) and mixed integer programs (MIPs) - in a high-level
 description language. These descriptions can be converted into the
 LP or MPS file formats which are understood by LP and MIP solvers.
 .
 Homepage: http://www.zib.de/koch/zimpl/


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

Re: sending debian-private postings to gmail

[Martin Schulze]

Domenico Andreoli wrote:
> it's nice to have your personal gobal & searchable mailing list
> archive, where you can really find anything you have ever received.

Even though it is nice, it's also problematic to scatter around
private and hence sensitive (at least temporarily sensitive)
information on a system that uses this as content for various
ratings.  I also have some doubts the mails are really deleted
from the disks and archives when you delete them in your interface.

Hence, I have to admit that Ians reasons are valid.

> sorry, i already switched to a safer address, sob..

Thank you.

Regards,

Joey

-- 
Have you ever noticed that "General Public Licence" contains the word "Pub"?

Please always Cc to me when replying to me on the lists.


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

Re: Why does doc packages need to contain gzipped files?

[Preben Randhol]

On Mon, 26 Jun 2006 17:59:39 +0200
Sam Hocevar <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 26, 2006, Preben Randhol wrote:
> 
> > > Do you think users with small machines shouldn't be able to
> > > install docs, too? It's just a one line script to gunzip all pdfs
> > > in /usr/share/doc.
> >
> > I don't find this a good argument as it is equally a one line script
> > to bzip2 all pdfs in /usr/share/doc in small computers.
> 
>A one-liner that can take hours, whereas gunzipping is quite cheap.

Please, how likely is it that a developer has a limited computer with
limited disc space and a lot of -doc packages? Maybe we need a poll
asking if the normal developer has a limited disc space or not? Anyway
if a computer *does* have limited hard disc space then it most likely
have limite CPU (like my old 166 MHz that collects dust in the corner).
This means that it will be a bigger annoyance to have to wait for zxpdf
or whatever to open the pdf every day.

And believe me I know as I also am maintaining a 233MHz...

Nothing is free, but space is close to...

Preben


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

Is OSS only support to be considered a bug?

[Preben Randhol]

With the 2.6 kernel programs using OSS for sound are not working
anymore. Sound that is. One *may* use aoss, but then the user needs to
open a terminal and write:

aoss program-name

because launching from the menu it won't work. So I consider aoss only
as a temporary dirty hack before alsa takes over completely.

My question is if it is legitimately to open bugs against applications
that only support OSS for spund?

Preben


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

new tar behavior and --wildcards

[Bdale Garbee]

The new tar behavior with respect to wildcards is not a change I
introduced just for Debian, it's a new upstream change that appears to
be quite intentional and well documented, as per this text from the tar
info docs:

   The following table summarizes pattern-matching default values:

   MembersDefault settings
   --
   Inclusion  `--no-wildcards --anchored
   --no-wildcards-match-slash'
   Exclusion  `--wildcards --no-anchored
   --wildcards-match-slash'

   -- Footnotes --

   (1) Notice that earlier GNU `tar' versions used globbing for
   inclusion members, which contradicted to UNIX98 specification 
   and was not documented.

Obviously, the problems reported with various Debian utilities are due
to the default now being --no-wildcards for inclusion combined with a
dependency on the footnoted "feature" of previous versions of GNU tar.

Since this seems to have been an intentional behavior change by
upstream to better align with a published standard, I'm uninclined to
fight it, and think our best response is to update our utilities to
include the --wildcards option, with a suitable versioned dependency on
tar.

Bdale


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

Re: Is OSS only support to be considered a bug?

[Marco d'Itri]

On Jun 26, Preben Randhol <[EMAIL PROTECTED]> wrote:

> My question is if it is legitimately to open bugs against applications
> that only support OSS for spund?
Yes.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Is OSS only support to be considered a bug?

[Bastian Blank]

On Mon, Jun 26, 2006 at 09:20:34PM +0200, Preben Randhol wrote:
> With the 2.6 kernel programs using OSS for sound are not working
> anymore. Sound that is.

Incorrect. The kernel includes OSS emulation.

> My question is if it is legitimately to open bugs against applications
> that only support OSS for spund?

It is a wishlist bug.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

Re: Is OSS only support to be considered a bug?

[Wouter Verhelst]

On Mon, Jun 26, 2006 at 09:20:34PM +0200, Preben Randhol wrote:
> With the 2.6 kernel programs using OSS for sound are not working
> anymore. Sound that is. One *may* use aoss, but then the user needs to
> open a terminal and write:
> 
> aoss program-name
> 
> because launching from the menu it won't work. So I consider aoss only
> as a temporary dirty hack before alsa takes over completely.
> 
> My question is if it is legitimately to open bugs against applications
> that only support OSS for spund?

No. There is snd-pcm-oss.ko, which provides working OSS sound, even if
you don't use aoss. Just make sure to load the proper module.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4


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

Re: new tar behavior and --wildcards

[Petr Vandrovec]

[I'm not on Debian-devel, so please CC me]

Bdale Garbee wrote:

The new tar behavior with respect to wildcards is not a change I
introduced just for Debian, it's a new upstream change that appears to
be quite intentional and well documented, as per this text from the tar
info docs:

   The following table summarizes pattern-matching default values:

   MembersDefault settings
   --
   Inclusion  `--no-wildcards --anchored
   --no-wildcards-match-slash'
   Exclusion  `--wildcards --no-anchored
   --wildcards-match-slash'

   -- Footnotes --

   (1) Notice that earlier GNU `tar' versions used globbing for
   inclusion members, which contradicted to UNIX98 specification 
   and was not documented.


Although maybe that it was not documented, it was widely used, and it exists for 
at least 6 years.  So upstream should fix documentation instead of tar behavior. 
 As documentation is not part of Debian, it does not matter for Debian anyway.



Obviously, the problems reported with various Debian utilities are due
to the default now being --no-wildcards for inclusion combined with a
dependency on the footnoted "feature" of previous versions of GNU tar.

Since this seems to have been an intentional behavior change by
upstream to better align with a published standard, I'm uninclined to
fight it, and think our best response is to update our utilities to
include the --wildcards option, with a suitable versioned dependency on
tar.


This decision makes tar completely incompatible.  Programs which worked fine 
with tar for 6 years are suddenly broken, and now you have to have two versions 
- one for 'tar' before this brokeness, which do not pass --wildcards, and one 
for this broken 'tar', which passes --wildcards.  And older version on newer 
'tar' extracts nothing, while new version on older 'tar' fails with an unknown 
option error.


Maybe it could be default for tar's POSIX mode, but I have no idea why GNU mode 
behavior should be changed in any way.

Petr Vandrovec


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

Re: Why does doc packages need to contain gzipped files?

[Steve McIntyre]

Preben Randhol writes:
>On Mon, 26 Jun 2006 17:59:39 +0200
>Sam Hocevar <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Jun 26, 2006, Preben Randhol wrote:
>> 
>> > > Do you think users with small machines shouldn't be able to
>> > > install docs, too? It's just a one line script to gunzip all pdfs
>> > > in /usr/share/doc.
>> >
>> > I don't find this a good argument as it is equally a one line script
>> > to bzip2 all pdfs in /usr/share/doc in small computers.
>> 
>>A one-liner that can take hours, whereas gunzipping is quite cheap.
>
>Please, how likely is it that a developer has a limited computer with
>limited disc space and a lot of -doc packages? Maybe we need a poll
>asking if the normal developer has a limited disc space or not? Anyway
>if a computer *does* have limited hard disc space then it most likely
>have limite CPU (like my old 166 MHz that collects dust in the corner).
>This means that it will be a bigger annoyance to have to wait for zxpdf
>or whatever to open the pdf every day.

Yet I've got several machines with limited disk space where I really
*do* care if things are compressed. After all, disk space is *always*
used up when it's in use and CPU is only used on the odd occasion when
you actually decompress the files in question. The laptop where I'm
typing this right now is my main Debian devel machine these days, as
well as the machine I carry around with music etc. on it. The less I
use up space on the -doc packages I have installed, the more
music/data files I have space for on the disk...

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
"...In the UNIX world, people tend to interpret `non-technical user'
 as meaning someone who's only ever written one device driver." -- Daniel Pead


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

Re: Why does doc packages need to contain gzipped files?

[Preben Randhol]

On Mon, 26 Jun 2006 21:30:45 +0100
Steve McIntyre <[EMAIL PROTECTED]> wrote:

> Yet I've got several machines with limited disk space where I really
> *do* care if things are compressed. After all, disk space is *always*
> used up when it's in use and CPU is only used on the odd occasion when
> you actually decompress the files in question. The laptop where I'm
> typing this right now is my main Debian devel machine these days, as
> well as the machine I carry around with music etc. on it. The less I
> use up space on the -doc packages I have installed, the more
> music/data files I have space for on the disk...

1. On your limited HD machines how many -doc packages have you
installed that you really need since you have a laptop?

2. If you prefer music over documentation, so what? Then I say that you
should bzip2 all your html and pdf files and unpack them when needed.
Then you'll get more mp3's on your computer too...

Please, stay on topic...


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

Re: Is OSS only support to be considered a bug?

[Preben Randhol]

On Mon, 26 Jun 2006 21:35:19 +0200
Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> On Mon, Jun 26, 2006 at 09:20:34PM +0200, Preben Randhol wrote:
> > With the 2.6 kernel programs using OSS for sound are not working
> > anymore. Sound that is. One *may* use aoss, but then the user needs
> > to open a terminal and write:
> > 
> > aoss program-name
> > 
> > because launching from the menu it won't work. So I consider aoss
> > only as a temporary dirty hack before alsa takes over completely.
> > 
> > My question is if it is legitimately to open bugs against
> > applications that only support OSS for spund?
> 
> No. There is snd-pcm-oss.ko, which provides working OSS sound, even if
> you don't use aoss. Just make sure to load the proper module.

Yes, but isn't this considered to be a temporary transitional thing? It
isn't loaded by default by the debian kernel image at least.

Preben


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

Re: new tar behavior and --wildcards

[Joe Smith]

"Petr Vandrovec" wrote in message news:[EMAIL PROTECTED]


Since this seems to have been an intentional behavior change by
upstream to better align with a published standard, I'm uninclined to
fight it, and think our best response is to update our utilities to
include the --wildcards option, with a suitable versioned dependency on
tar.


This decision makes tar completely incompatible.  Programs which worked 
fine with tar for 6 years are suddenly broken, and now you have to have 
two versions - one for 'tar' before this brokeness, which do not 
pass --wildcards, and one for this broken 'tar', which passes --wildcards. 
And older version on newer 'tar' extracts nothing, while new version on 
older 'tar' fails with an unknown option error.


Maybe it could be default for tar's POSIX mode, but I have no idea why GNU 
mode behavior should be changed in any way.

Petr Vandrovec


Indeed. If POSIX compatability is important to the GNU tar maintainer, then 
why has he not updated GNU pax yet?
UNIX03 has no tar, but has pax. So reviving the paxutils package seems more 
imporant than fixing an incompatibility with an outdated

version of the Unix spec.




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

Re: Is OSS only support to be considered a bug?

[Joe Smith]

"Preben Randhol" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

On Mon, 26 Jun 2006 21:35:19 +0200
Wouter Verhelst <[EMAIL PROTECTED]> wrote:


On Mon, Jun 26, 2006 at 09:20:34PM +0200, Preben Randhol wrote:
> With the 2.6 kernel programs using OSS for sound are not working
> anymore. Sound that is. One *may* use aoss, but then the user needs
> to open a terminal and write:
>
> aoss program-name
>
> because launching from the menu it won't work. So I consider aoss
> only as a temporary dirty hack before alsa takes over completely.
>
> My question is if it is legitimately to open bugs against
> applications that only support OSS for spund?

No. There is snd-pcm-oss.ko, which provides working OSS sound, even if
you don't use aoss. Just make sure to load the proper module.


Yes, but isn't this considered to be a temporary transitional thing? It
isn't loaded by default by the debian kernel image at least.



Umm... See these pages:

http://alsa.opensrc.org/aoss
http://alsa.opensrc.org/OSSEmulation

It sounds like both meathods are supported by the alsa devs, but obviously
native Alsa support is prefered, 




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

Re: new tar behavior and --wildcards

[Russ Allbery]

Petr Vandrovec <[EMAIL PROTECTED]> writes:

> This decision makes tar completely incompatible.  Programs which worked
> fine with tar for 6 years are suddenly broken, and now you have to have
> two versions - one for 'tar' before this brokeness, which do not pass
> --wildcards, and one for this broken 'tar', which passes --wildcards.
> And older version on newer 'tar' extracts nothing, while new version on
> older 'tar' fails with an unknown option error.

The --wildcards flag was added in tar 1.13.20 in 2001-06-27, so passing
--wildcards is safe even for oldstable.  Only the default changed.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Why does doc packages need to contain gzipped files?

[Yaroslav Halchenko]

On Mon, 26 Jun 2006, Osamu Aoki wrote:
> >...<
> > So far for the past;  at the moment I think that it would be a good
> > compromise to not compress PDF files in dedicated -doc packages, while
> > keeping them compressed in mixed packages.  This would mean that we
> > should *not* wait for debhelper to switch, but instead add -X.pdf to
> > dh_compress in tetex-doc.  But this is just my personal opinion, and not
> > a very fixed one - it still has to be discussed among the Debian TeX
> > Task Force
> Seconded.
Thirded! ;)

I think that there must be some general rules introduced in dh_compress
such as you suggested: 

1. don't compress within -doc packages. 

2. verification at package build time if there is a considerable
space saving from file compression. That would allow to don't recompress
already compressed files, but on the other hand it might introduce
inhomogeneity -- some files of similar nature would be compressed, the
others not.

N.B.: Just few hours ago I've filed a but against beagle since it ships
an extension in its doc directory as .xpi.gz. Besides the fact that it
can't be used as it is shipped, ie without decompression,
extracted .xpi actually took few bytes less than .xpi.gz.

The main argument from my side: if there is no transparent support to
handle those compressed files (like pdf.gz can't be easily viewed from
firefox as it is shipped now. don't suggest proxied archival tools such
as ark... that is not transparent support), then they better be
shipped uncompressed since otherwise uncompressing them manually would
break their proper CLEANUP and UPGRADE.

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




pgptAxFH2Noil.pgp
Description: PGP signature

Another weird tar issue (100 character filenames)

[Russ Allbery]

I just built new xml-security-c packages to fix the current FTBFS bug, and
lintian returned the following error message:

E: libxml-security-c-doc: deb-created-with-broken-tar file: 
/usr/share/doc/libxml-security-c-doc/c/apiDocs/winutils_2XSECBinHTTPURIInputStream_8hpp-source.html
N:
N:   The binary package was created with a broken version of tar. Some
N:   versions of tar contain a bug, which make the resulting .deb broken.
N:   On unpack, some filenames are going to be corrupted.
N:   
N:   This package was build with such a version of tar, and the mentioned
N:   filename is corrupted. Refer to Debian bug #230910 for more
N:   information, or simply update your tar-version and rebuild.

(along with several other files).  These filenames are indeed exactly 100
characters long, as mentioned in the referenced bug.  The bug, however,
indicates that this may not have really been a bug in tar but rather was a
bug in dpkg with its inability to handle filenames that were exactly 100
characters (apparently one isn't supposed to nul-terminate in that case).

I can't find any reference of this issue in dpkg's changelog, and I can't
find any explicit note in the latest tar changelog or NEWS entry that
indicates there was an intended change, but the patch in that bug appears
to no longer be applied to the Debian tar source.  Is this lintian error
just obsolete and should now be removed?  Or is there something more
complex going on?

dpkg -i installed the resulting *.deb without any difficulty and without
any file name corruption that at least I can see on my Debian testing
system, but I don't know if that proves this bug is gone.

I don't know if this is related, but I've also started seeing the
following messages from tar during package building:

dpkg-deb: building package `libxml-security-c12' in 
`../libxml-security-c12_1.2.1-3_i386.deb'.
tar: -: file name read contains nul character
dpkg-deb: building package `libxml-security-c-dev' in 
`../libxml-security-c-dev_1.2.1-3_i386.deb'.
tar: -: file name read contains nul character

Is there some sort of mismatch happening between what dpkg and related
tools are generating and what tar is now expecting?

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Bug#375603: ITP: zope-pgstorage -- a ZODB backend that persists to a PostgreSQL database

[alex bodnaru]

Package: wnpp
Severity: wishlist
Owner: alex bodnaru <[EMAIL PROTECTED]>


* Package name: zope-pgstorage
  Version : 0.1
  Upstream Author : Shane Hathaway, Zope Corporation, <[EMAIL PROTECTED]>
* URL : http://hathawaymix.org/Software/PGStorage
* License : Zope Public License (ZPL) Version 2.1
  Programming Lang: Python
  Description : a ZODB backend that persists to a PostgreSQL database

 PGStorage is a ZODB backend that persists to a PostgreSQL database. 
 PGStorage stores simple pickles in the database, so it is compatible 
 with most Zope applications and is much simpler than Ape. Undo and 
 packing are supported.
 .
 PGStorage also takes the place of ZEO. Any number of Zope instances 
 can connect to a single PostgreSQL database. Furthermore, the 
 replication options available for PostgreSQL may take the place 
 of ZRS (Zope Replication Services.)

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-skas3-v8.2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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