Re: bits from the release team

[Goswin von Brederlow]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit :
>> * Lionel Elie Mamane:
>> > Why can't we have a master key that signs the yearly keys? After
>> > all, we have a long-term unique X.509 master key, so what's the
>> > difference with OpenPGP?
>>
>> End users are typically not exposed to the X.509 keys, which makes
>> things a lot easier.
>>
>> By the way, if you've got a master key, you need to plan for key
>> rollover, too.  Why not apply that procedure directly to the keys
>> used to sign the release files?  A yearly key change just results in
>> unnecessary administrative overhead for our users, without providing
>> any real benefit to them.  A key compromise still needs manual
>> intervention.
>>
>> At the very least, if we have to keep that yearly key change for
>> political reasons, please schedule it in a way that it doesn't happen
>> in January.
>
> Proposal 1:
>
>   a possible way would be to have two valid keys at any time. like one
>   new key per year (or 6 month like you want) with a validity of 2 years
>   (resp. one year).
>
>   that would obviously mean two signatures per package (but I don't
>   think that's that much work) and would require the user to update
>   their "keyring package" only once every year (or 6 month), which looks
>   like a quite reasonnable trade-off. Even stable updates can use that
>   scheme, since it's released more than once a year.

Except that apt-get fails if any of the signatures are unknown or
expired. So you still need both keys and not just one of them as you
intent.

> Proposal 2:
>
>   the package that holds the public signature key has to contain every
>   single emited key, and be signed with any anterior one. Meaning that
>   the upgrade for any user would be smooth.
>
>   I don't think that having a kludge in dpkg that forces the upgrade of
>   that package ASAP would be hard or dangerous to implement, so that
>   even a non aware user could just "apt-get update" without having read
>   the release notes.
>
>   This is simpler, but less secure than the Proposal 1.

Not applicable to non debian repositories or easily exploitable to
work on any package.

> Proposal ...:
>
>   there is a lot of such ideas IMHO, one just has to think 10 minutes to
>   imagine a couple of ones.
>
>
> IMHO, changing the key every year at any date is not problematic at all, 
> because there is plenty of solution to do smooth replacement of the 
> key.

Do you see any drawbacks with my proposal of having Release.key next
to each Releas.gpg or do you have a better idea that will work for
every apt-getable archive?

MfG
Goswin


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

Re: Getting rid of circular dependencies, stage 4

[Bill Allombert]

On Wed, May 10, 2006 at 05:23:34AM +0200, Michael Koch wrote:
> Hello,
> 
> 
> > antlr
> > gjdoc
> 
> Somehow these seem to be false positives to me because the packages
> depend on a java runtime environment which can but does not have to
> depend on.

The dependency involve the following packages:
antlr gjdoc java-gcj-compat kaffe kaffe-jthreads kaffe-pthreads

and a graph is available at
  http://debian.semistable.com/dot/libjessie-java_unstable.png

(Given the way the list is generated I doubt there are false
positives).

> > eclipse-jdt
> > eclipse-jdt-common
> > kaffe
> > kaffe-jthreads
> > kaffe-pthreads
> > libswt3.1-gtk-java
> > libswt3.1-gtk-jni
> 
> I dont understand these.

eclipse-jdt <--> eclipse-jdt-common
http://debian.semistable.com/dot/eclipse-jdt-common_unstable.png

gjdoc kaffe kaffe-jthreads kaffe-pthreads
http://debian.semistable.com/dot/kaffe-pthreads_stable.png

libswt3.1-gtk-java <--> libswt3.1-gtk-jni
http://debian.semistable.com/dot/libswt3.1-gtk-jni_unstable.png

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: Intent to hijack Bacula

[José Luis Tallón]

Gustavo Franco wrote:
> [snip]
>
> Thanks for this. I'm using backuppc at work and was considering to
> move our backups to bacula after upgrading our current hardware setup.
> Package updates and bug squashing in general was on the roadmap.
:-)
Bacula (specially 1.38.x is much better... hopefully you'll be delighted)
> That would be good if you, Jose and probably others joined a 'bacula'
> group in alioth to keep this in group maintenance. 
I have offered John co-maintenance recently.

I previously declined very 'consistent' offers to adopt/take over
Bacula, and offered co-maintenance instead.
One of the main reasons: i have quite good relations with upstream
(almost made them move main development to Debian -- will try again
soon) and understand our user's problems quite well. Additionally, quite
a lot of users have already contacted me.
> Hopefully i would be able to join with real work in the next month.
> Thoughts?
You would be more than welcome... specially if  you are any good with
Postgres. I know that the current postinst could be better (was
contributed and can't say much)

Some work a much needed dbconfig-common migration would be very
interesting, too (i don't feel i have resources enough to tackle that on
my own)
> Closing, do you think it will be possible to ship in Etch a "backup
> server" task using bacula ? I think that's all up to add more stuff in
> debconf and prepare the task itself. Probably a goal for the first
> 'group upload', if you agree.
I couldn't be happier if that happened. We have a bit less than 3 months
(until Etch freezes) to get all of this in shape. Any other volunteers?


J.L.


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

Re: bits from the release team

[Goswin von Brederlow]

Florian Weimer <[EMAIL PROTECTED]> writes:

> * Goswin von Brederlow:
>
>> Doesn't work if the key is ever compromised and a new one has to be
>> created out of schedule. Or when you spend your x-mas holidays away
>> from your system and couldn't upgrade before new years eve.
>
> Exactly, and this begs the question why we rotate keys at all.

A key might be compromised without our knowledge. With the yearly
rotation a stolen key will only be usefull for a limited time. Without
rotation an atttacker could gain the key and then wait for an
opportune moment to use it.

But that is not relevant to the problem. Experience shows that keys do
get compromised and need changing. So rotation or no rotation the key
change has to be handled anyway. Rotation just adds it at specific
intervals on top of random events.

MfG
Goswin


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

Re: bits from the release team

[Pierre Habouzit]

Le Mer 10 Mai 2006 11:05, Goswin von Brederlow a écrit :
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit :
> >> * Lionel Elie Mamane:
> >> > Why can't we have a master key that signs the yearly keys? After
> >> > all, we have a long-term unique X.509 master key, so what's the
> >> > difference with OpenPGP?
> >>
> >> End users are typically not exposed to the X.509 keys, which makes
> >> things a lot easier.
> >>
> >> By the way, if you've got a master key, you need to plan for key
> >> rollover, too.  Why not apply that procedure directly to the keys
> >> used to sign the release files?  A yearly key change just results
> >> in unnecessary administrative overhead for our users, without
> >> providing any real benefit to them.  A key compromise still needs
> >> manual intervention.
> >>
> >> At the very least, if we have to keep that yearly key change for
> >> political reasons, please schedule it in a way that it doesn't
> >> happen in January.
> >
> > Proposal 1:
> >
> >   a possible way would be to have two valid keys at any time. like
> > one new key per year (or 6 month like you want) with a validity of
> > 2 years (resp. one year).
> >
> >   that would obviously mean two signatures per package (but I don't
> >   think that's that much work) and would require the user to update
> >   their "keyring package" only once every year (or 6 month), which
> > looks like a quite reasonnable trade-off. Even stable updates can
> > use that scheme, since it's released more than once a year.
>
> Except that apt-get fails if any of the signatures are unknown or
> expired. So you still need both keys and not just one of them as you
> intent.

that is obviously "fixe-able"

> > Proposal ...:
> >
> >   there is a lot of such ideas IMHO, one just has to think 10
> > minutes to imagine a couple of ones.
> >
> >
> > IMHO, changing the key every year at any date is not problematic at
> > all, because there is plenty of solution to do smooth replacement
> > of the key.
>
> Do you see any drawbacks with my proposal of having Release.key next
> to each Releas.gpg or do you have a better idea that will work for
> every apt-getable archive?

this is obviously a valid idea, except that you have to have those key 
over https to avoid MiM attacks, with a valid https CA (like in not 
self-signed).
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpvSD3EgOym5.pgp
Description: PGP signature

Re: PDF files and dh_compress

[Adam Borowski]

On Tue, 9 May 2006, Frank Küster wrote:

Martin Wuertele <[EMAIL PROTECTED]> wrote:

How about compressing all generated pdf with eg pdftk instead of gzip?
That would save on space without troubling potential readers.

Most PDF files in Debian are already compressed;  at least those
which are generated on a Debian system, and somehow TeX is involved
are.

[an example of TeX-generated pdf]

So somehow uncompressing-recompressing with pdftk gives a slightly
larger file [...]
To me, this sounds like in general it's not worth to compress compressed
pdf files with gzip; if we'd go for size, we should use bzip2.


An idea:
debhelper:
if (-x '/usr/bin/pdftk'")
{
`pdftk $_ output $tmp uncompress`;
`pdftk $tmp output $recompressed compress`;
compare the sizes of $_ and $recompressed
install the smaller
}
else
{
warn "PDF docs but no pdftk installed\n";
}
lintian:
W: PDF docs but no Build-Depends on pdftk

--
/---\ Shh, be vewy, vewy quiet,
| [EMAIL PROTECTED] | I'm hunting wuntime ewwows!
\---/
Segmentation fault (core dumped)

Re: PDF files and dh_compress

[Florian Weimer]

* Frank Küster:

> Most PDF files in Debian are already compressed;  at least those
> which are generated on a Debian system, and somehow TeX is involved
> are.  

And those which haven't been rebuilt could well be non-free anyway
(because we lack the source code). 8->

exp. lightspeed disappeared

[A Mennucc]

hi

I uploaded an experimental version of 'lightspeed', as you see in
http://packages.qa.debian.org/l/lightspeed/news/20060507T214839Z.html
on Sun 7th of May ; but strangely enough it does not appear, neither in
http://packages.qa.debian.org/l/lightspeed.html
nor in
http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=lightspeed

Actually, in this latter there is the version for kfreebsd-i386 , but not
the version for i386, that I uploaded.

Why?  

(also, who should I write to? if there is a more apt list to post this
message, please tell me)

a.

ps: note that the above is a NMU... I am helping fixing a bug; I 
 uploaded the new version in experimental to make it available
 to the bug reporter and so that I would see if autobuilders do compile it

-- 
Andrea Mennucc
 "Ukn ow,Ifina llyfixe dmysp acebar.ohwh atthef"


signature.asc
Description: Digital signature

Re: APT key maintainence

[Goswin von Brederlow]

Andreas Barth <[EMAIL PROTECTED]> writes:

> * Pierre Habouzit ([EMAIL PROTECTED]) [060506 12:46]:
>> if you take the 2y validity with 1y overlap, to have no problems, 
>> users/images/... just have to be updated once a year (and will have a 
>> life of at least one year, almost two if those are updated as soon as a 
>> new key exists), which sounds reasonnable to me.
>
> Actually, if someone installs etch r0, I expect that he can install etch
> r5 without any hassle (unless ftp-master was hijacked :). This means
> that the key used in r5 needs to be available in etch r0.
>
>
> Cheers,
> Andi

Or can be updated + validated without hassle.

Providing keys in advance will never work. Keys will get lost, keys
will be delayed, keys will get compromised and need replacing or any
other unexpected event will break it.

Instead of that make key updates automatic (downloading Release.key)
with a validation step inbetween that checks the keys signatures and
uses user interaction. We can be reasonably sure that at least some of
the ftp-master team will have a key in the stable R0 keyring package
that will still be valid and used for R5. The more signatures the
archive key gets the more likely that becomes.

MfG
Goswin


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

Re: Getting rid of circular dependencies, stage 4

[Robert Lemmen]

On Wed, May 10, 2006 at 02:57:22AM +0200, Matthias Klose wrote:
> maybe the corresponding g++-X.Y and libstdc++-Z-X.Z-dev packages could
> be solved by merging these packages. Anyway, these binaries are built
> from the same source, so we should ot care-

please note that cycles that cycles of packages that come from the same
source are a problem as well, and are in a way forbidden by policy...

cu  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

multiarch status update

[Matt Taggart and others]

Hi debian-devel,

For a couple years now a few of us have been talking about an idea called 
"multiarch". This is a way to seamlessly allow support for multiple different 
binary targets on the same system, for example running both i386-linux-gnu and 
amd64-linux-gnu binaries on the same system (many other working combinations 
exist as well). I have created a new page in the wiki to track info and status

  http://wiki.debian.org/multiarch

Recently HP and Canonical Ltd. have been looking into possible implementation 
strategies and this has resulted in the following report

  http://multiarch.alioth.debian.org/multiarch-hp-report.pdf

One of the things that came out of that report is that implementing multiarch 
would be much easier if we had a few enhancements in the package manager. This 
prompted Scott James Remnant to start working on a "dpkg 2.0" design document. 
That has been sent to the debian-dpkg list and is available at

  http://lists.debian.org/debian-dpkg/2006/05/msg00022.html

(please direct any followup about dpkg there)

Multiarch will allow Debian to

* better support systems that can run multiple binary targets, like
  i386 on amd64, i386 on ia64.
* better support MMX/SSE/Altivec/etc tuned packages
* allow for seamless large ABI transitions
* allow users to smoothly migrate from one arch to another
* do things like "partial architectures" so that we can add weird
  processor variants without needing to add an entire new port to the
  pool/mirrors
* better assimilate the *BSD kernels and userspaces
* better support non-monopoly archs, since they may be able to run bits
  for other archs
* maybe even to do stuff like use non-native archs (with support for
  other binary targets) to build native bits (m68k emulator on
  superfast amd64?). 
* other cool stuff

We think multiarch can be implemented with minimal disruption to unstable, 
most changes won't effect "single-arch" type systems at all. We'd like to 
start working on implementing it, but before we do we wanted to get feedback, 
concerns, recommendations, volunteers :), etc. This is a big undertaking and 
we're going to need everyone's help to make it happen. Please reply.

Thanks,

--
Tollef Fog Heen <[EMAIL PROTECTED]>
dann frazier <[EMAIL PROTECTED]>
Lamont Jones <[EMAIL PROTECTED]>
Scott James Remnant <[EMAIL PROTECTED]>
Matt Taggart <[EMAIL PROTECTED]>
Matt Zimmerman <[EMAIL PROTECTED]>



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

Re: Getting rid of circular dependencies, stage 4

[Alastair McKinstry]

Bill Allombert wrote:


Hello Debian developers,

Here the lists of packages involved in circular dependencies listed by
maintainers.


Alastair McKinstry <[EMAIL PROTECTED]>
console-common
console-tools


 

Ok, console-common will depend on  ( kbd | console-tools) in the next 
release, and I will
remove dependencies from console-tools. Will upload as soon as the phone 
company

fixes my ASDL ...

Regards
Alastair


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

Re: Getting rid of circular dependencies, stage 4

[allomber]

On Wed, May 10, 2006 at 02:57:22AM +0200, Matthias Klose wrote:
> Bill Allombert writes:
> > Debian GCC Maintainers 
> > g++-3.3
> > g++-3.4
> > g++-4.0
> > g++-4.1
> > gcj
> > gcj-4.0
> > gcj-4.1
> > java-gcj-compat
> > libgcj-dev
> > libgcj6-dev
> > libgcj7-dev
> > libstdc++5-3.3-dev
> > libstdc++6-4.0-dev
> > libstdc++6-4.1-dev
> > libstdc++6-dev
> > 
> > Debian GCC maintainers 
> > g++-2.95
> > libstdc++2.10-dev
> 
> maybe the corresponding g++-X.Y and libstdc++-Z-X.Z-dev packages could
> be solved by merging these packages. Anyway, these binaries are built
> from the same source, so we should ot care-

Being built from the same source has no effect on apt and dpkg handling
of circular dependencies.

> I currently do not understand the java-gcj-compat / gcj-4.X relationship.

java-gcj-compat is involved in a dependency loop with:
   antlr gjdoc kaffe kaffe-jthreads kaffe-pthreads libgnucrypto-java
   libjessie-java

  graph at http://debian.semistable.com/dot/libjessie-java_unstable.png

gcj-4.X circular deps:
gcj-4.0 <--> libgcj6-dev
gcj <--> libgcj-dev
gcj-4.1 <--> libgcj7-dev

> > Debian OpenOffice Team 
> > openoffice.org-common
> > openoffice.org-core
> 
> that's just a splitting into arch/indep packages. you sould not warn
> about it.

apt and dpkg do not handle them any specially, so I don't see why I
should.

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: bacula_1.38.8-0.1_i386.changes is NEW

[José Luis Tallón]

John Goerzen wrote:
> Hello Jose,
>
> Before I reply to your message, I want to be clear that I'm going to be
> blunt here, and say exactly what I think.  This is not intended to be an
> insult or an attack, but the reasons for these concerns.
>   
Ok. I don't like flamewars either. There are plenty on Debian-Devel.
> On Tue, May 09, 2006 at 07:42:17PM +0200, José Luis Tallón wrote:
>   
>> I'd rather have you as a co-maintainer.
>> The unfortunate situation is that i have been in the NM queue for more
>> than two years and a half now. The fact that i depend on my sponsors to
>> get packages uploaded makes me delay them until i can guarantee a
>> minimum level of quality (since i can't fix my mistakes easily).
>> 
>
> That situation sounds unfortunate; however, there are others that are
> able to successfully maintain packages in Debian -- with sponsors --
> that don't have this sort of problem.  Or at least not to the extent
> that you have.
>   
In fact, Stephen himself has offered to sponsor some of my upload, which
i have so far declined -- that's not a personal issue in any way, but
i'd rather save myself the trouble of explaining *once again* all my
technical decisions for a particular package.

Cristoph Haas is listed as uploader for Bacula.
Turbo Fredriksson helped quite a bit.

>> Moreover, i have had several personal issues during the last months,
>> which made me unable to help.
>> 
>
> Unfortunate, but the proper thing to do in this situation is to announce
> the situation and solicit NMUs from people.  As far as I have seen, you
> did not do this.
>   
Hmm... I will keep that in mind for the next time, should it ever happen
(hopefully not)
But I can't see it anywhere in the Policy nor in the Developers' Reference.
> There are several reasons I have made the NMUs I have, and that I intend
> to take over this package.  Some of them are:
>
>  * Release-critical bugs that were open for over a year (303862)
>or a very long time (343762).  Some of these were trivial (10-second)
>fixes.
>   
Well... no upload = no bugfixes
>  * Bacula was removed from testing three months ago due to its
>bugginess.
>   
So what? that's obvious. Buggy package ==> removed from testing.
That is how we ensure our OS's quality.

>  * Repeated promises from you in the BTS to make a new upload "soon",
>reference to beta testers, etc., but no upload was forthcoming.
>Your last upload was almost a year ago.
>   
Yes. I am not proud of that.
>  * Your in-progress 1.38 packages on SourceForge were a good start,
>but did not address many significant issues.
>   
Well.. i did close most of the outstanding bugs, and adapted to a new
generation Bacula.
Transition from 1.36 to 1.38 was not that easy, since it involved a
delicate decision: splitting the sd in several "flavors".
> There are a lot of problems that have persisted for literally years in
> the Bacula packages.  Some of them are:
>
>  * Your postinst scripts would stop (and later restart) database
>servers without first asking permission.  A terrible no-no in
>production environments.
>   
Definitively, not MySQL not SQLite.
As for Postgres... well, i never claimed to be any good with postgres,
and adopted what was submitted. The RFH has been there, as you say, for
years.

BTW, the 0pre1 "Debian version" means something, and was advertised as such.
>  * Your clean target was ineffective and caused a huge diff.gz
>   
For 1.38 ? Yes. Can't clean before you have it built, right?
Those binaries were contributed by one of my users (Adam Thornton), when
the two machines i had available were unable to build Bacula-1.38.7.
I must say that i wasn't home at the time.
>  * Bacula would link against Python 2.2 in some cases even though you
>dep'd on python2.3
>   
Didn't get to it, either. Fortunately, your patches address that
problem, right?
>  * Policy violations in numerous places, including treatment of logfiles
>   
Touché  as for the logfiles.
I would like to know what are the other Policy violations you refer to,
so that i can learn from those.
>  * No rotation of logs
>   
That's a wishlist bug. I think that 'wishlist' comes after 'grave' or
'important'. Do you think otherwise?
>  * Indiscriminate removing of /var/lib/bacula on removal, which would
>completely break the remaining bacula packages on a system
>   
Hmm.. never had that problem, but i understand your point.
Please note that i also use Bacula in production in several machines.
>  * Bashisms in debian/rules.
>   
Ok. Didn't notice those, nor did lintian or linda.
Care to point them so that i can learn?
>  * Poor handling of multiple-variants problem.  Hacking up configure
>scripts instead of just calling configure several times (see
>the reference to vim in the debian developers' guide)
>   
Well I did build Bacula that way almost two years ago, with version
1.32f-4 till 1.32f-6.

I was publicly "reprehended" by Turbo Fredriksson due to the amount of
CPU 

Bug#366684: ITP: pyfits -- Python module for reading, writing, and manipulating FITS files

[Aurelien Jarno]

Package: wnpp
Severity: wishlist
Owner: Aurelien Jarno <[EMAIL PROTECTED]>

* Package name: pyfits (python2.x-pyfits for the binaries)
  Version : 1.0.1-1
  Upstream Author : Science Software Branch of the STScI
* URL : http://www.stsci.edu/resources/software_hardware/pyfits
* License : BSD like
  Programming Lang: Python
  Description : Python module for reading, writing, and manipulating FITS 
files

FITS (Flexible Image Transport System) is a data format most used in
astronomy. PyFITS is a Python module for reading, writing, and manipulating
FITS files. The module uses Python's object-oriented features to provide quick,
easy, and efficient access to FITS files. The use of Python's array syntax
enables immediate access to any FITS extension, header cards, or data items.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-amd64-k8-smp
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8)


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

Re: multiarch status update

[Jonas Meyer]

On Wed, 2006-05-10 at 02:00 -0700, Matt Taggart and others wrote:
> Hi debian-devel,
> 
> For a couple years now a few of us have been talking about an idea called 
> "multiarch". This is a way to seamlessly allow support for multiple different 
> binary targets on the same system, for example running both i386-linux-gnu 
> and 
> amd64-linux-gnu binaries on the same system (many other working combinations 
> exist as well). I have created a new page in the wiki to track info and status

> 
> We think multiarch can be implemented with minimal disruption to unstable, 
> most changes won't effect "single-arch" type systems at all. We'd like to 
> start working on implementing it, but before we do we wanted to get feedback, 
> concerns, recommendations, volunteers :), etc. This is a big undertaking and 
> we're going to need everyone's help to make it happen. Please reply.
> 
I'd prefer to have done it yesterday. I got to know about this because
of the possibility to use scratchbox2 with it in a way that you can
easily cross compile for any target without a seperated build
environment. Also it will ease the use of dpkg-cross a great lot.
 I think a lot of people don't trust in this can actually work and I'd
like to see an actual proof. I definately want to help with this.
Jonas


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

Re: effectiveness of rsync and apt

[A Mennucc]

hi

I had the same idea some time ago

if you ever decide to work on that, I may help

Goswin von Brederlow wrote:

> I actualy have a little hack how one could implement patch debs now to
> test this out:
> 
> 1. Create an archive mirror with rsync batch files (or xdelta or
> whatever) between the last and current version of each package. It
> might be simplest to replace the data.tar.gz in each deb with the
> rsync batch file and leave the rest of the deb as is.
> 
> 2. Create Packages.gz and friends for those patch debs
> 
> 3. Create an apt method "http-patch" to apt that will first check for
> the old version of the package or dpkg-repack it, then forks the http
> method to download the patch deb, applies the patch and returns the
> build deb.
> 
> 4. Add
> 
> deb http-patch://server/path suite dist
> 
> to sources.list _before_ the normal http url.
> 
> 
> One drawback of this hack would be that you get an error from the
> http-patch method when you don't have the previous version available
> before apt-get falls back to the http url.
> 
> MfG
> Goswin
> 
> 


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

Re: PDF files and dh_compress

[Charles Plessy]

On Wed, May 10, 2006 at 07:21:58AM +0200, Florian Weimer wrote :
> * Frank Küster:
> 
> > Most PDF files in Debian are already compressed;  at least those
> > which are generated on a Debian system, and somehow TeX is involved
> > are.  
> 
> And those which haven't been rebuilt could well be non-free anyway
> (because we lack the source code). 8->

Dear all, dear Florian,

I am preparing a package (1) in which I have added the the PDF manual
(2) which in the public domain. It has been created from a MSWord
document. The upstream author is considering rewriting it in LaTeX, but
of course, ther is no guarantee that it will be done shortly.

(1) http://bugs.debian.org/365499
(2) available on the same page as the sources, 
http://probcons.stanford.edu/download.html

Does it mean that I have to remove the pdf documentation, and indicate
to the users how to download it by themselves in the manpage and/or
README.Debian?

Interestingly, one could consider that a PDF file is not a program. As
in addition this one is in the public domain, it has no licence nor
copyright. Does it mean that the DFSG do not apply and that I can
distribute it in the debian package ?

Have a nice day,

-- 
Charles Plessy
Wako, Saitama, Japan


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

Re: Getting rid of circular dependencies, stage 4

[Brendan O'Dea]

On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:
>Here the lists of packages involved in circular dependencies listed by
>maintainers.
>
>   perl
>   perl-modules

These two packages are meant to be installed together, split only for
arch any/all.

I'm a bit puzzled as to why this is a problem, since this particular
dependency exists in sarge and as far as I no caused no upgrade issues.

Note that the dependency expressed is not exactly circular, since the
perl-modules dependency on perl is "looser" than the inverse.  Don't
know if this matters for the problem you're trying to fix.

--bod


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

Re: Getting rid of circular dependencies, stage 4

[Pierre Habouzit]

Le Mer 10 Mai 2006 14:40, Brendan O'Dea a écrit :
> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:
> >Here the lists of packages involved in circular dependencies listed
> > by maintainers.
> >
> > perl
> > perl-modules
>
> These two packages are meant to be installed together, split only for
> arch any/all.
>
> I'm a bit puzzled as to why this is a problem, since this particular
> dependency exists in sarge and as far as I no caused no upgrade
> issues.

cycles are evil, so when you can avoid them, it's better, and here ...

> Note that the dependency expressed is not exactly circular, since the
> perl-modules dependency on perl is "looser" than the inverse.  Don't
> know if this matters for the problem you're trying to fix.

perl-modules should not depends on perl. It's useless to have only 
perl-modules installed, but this create no harm.

moreover people just apt-get install perl, so that won't break anything.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpyUm72ZE6fX.pgp
Description: PGP signature

Re: multiarch status update

[Olaf van der Spek]

On 5/10/06, Matt Taggart and others <[EMAIL PROTECTED]> wrote:

For a couple years now a few of us have been talking about an idea called
"multiarch". This is a way to seamlessly allow support for multiple different
binary targets on the same system, for example running both i386-linux-gnu and
amd64-linux-gnu binaries on the same system (many other working combinations
exist as well). I have created a new page in the wiki to track info and status


Does it also allow completely arbitrary combinations to be installed?


* allow for seamless large ABI transitions
* allow users to smoothly migrate from one arch to another
* do things like "partial architectures" so that we can add weird
 processor variants without needing to add an entire new port to the
 pool/mirrors
* better assimilate the *BSD kernels and userspaces
* better support non-monopoly archs, since they may be able to run bits
 for other archs
* maybe even to do stuff like use non-native archs (with support for
 other binary targets) to build native bits (m68k emulator on
 superfast amd64?).
* other cool stuff


Does it also allow multiple versions of the same package to be
installed at the same time?
For example, multiple minor versions or multiple major versions?

Re: Getting rid of circular dependencies, stage 4

[Henning Glawe]

On Wed, May 10, 2006 at 10:40:32PM +1000, Brendan O'Dea wrote:
> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:
> >Here the lists of packages involved in circular dependencies listed by
> >maintainers.
> >
> > perl
> > perl-modules
> 
> These two packages are meant to be installed together, split only for
> arch any/all.
> 
> I'm a bit puzzled as to why this is a problem, since this particular
> dependency exists in sarge and as far as I no caused no upgrade issues.

what about the issue showing up in conjunction with doc-base? both perl and
perl-modules were installed, but not in matching versions (due to apt being
confused about the circular dep) during the upgrade
from 5.6 to 5.8, which made packages calling install-docs in their
maintainer scripts fail, if I remember correctly...

> Note that the dependency expressed is not exactly circular, since the
> perl-modules dependency on perl is "looser" than the inverse.  Don't
> know if this matters for the problem you're trying to fix.

it is not "looser" if you look at it from the perspective of a sarge->etch
update...

-- 
c u
henning


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 4

[James Vega]

On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote:
> On Tue, 9 May 2006 22:49:36 +0200, Bill Allombert <[EMAIL PROTECTED]> said:
> > Hubert Chan <[EMAIL PROTECTED]>
> >alsaplayer-alsa
> >alsaplayer-common
> >alsaplayer-gtk
> 
> Hmm...  alsaplayer-common Depends: on "alsaplayer-alsa |
> alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface".  Is this
> really a problem?

The problem is that all three packages Depend on each other as seen from
grep-dctrl -sPackage,Depends -FPackage -e 'alsaplayer-(alsa|common|gtk)'

Package: alsaplayer-alsa
Depends: libasound2 (>> 1.0.9), libc6 (>= 2.3.5-1),
 alsaplayer-common (= 0.99.76-7)
 -

Package: alsaplayer-common
Depends: libc6 (>= 2.3.5-1), libflac7, libgcc1 (>= 1:4.0.1),
 libid3tag0 (>= 0.15.1b), libmad0 (>= 0.15.1b),
 libmikmod2 (>= 3.1.10), libogg0 (>= 1.1.2), liboggflac3,
 libsndfile1 (>= 1.0.2-1), libstdc++6 (>= 4.0.1),
 libvorbis0a (>= 1.1.0), libvorbisfile3 (>= 1.1.0),
 zlib1g (>= 1:1.2.1), alsaplayer-alsa | alsaplayer-output,
  ---
 alsaplayer-gtk | alsaplayer-interface
 --

Package: alsaplayer-gtk
Depends: libc6 (>= 2.3.5-1), libgcc1 (>= 1:4.0.1), libglib1.2 (>= 1.2.0),
 libgtk1.2 (>= 1.2.10-4), libstdc++6 (>= 4.0.1),
 libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0),
 libxi6 | xlibs (>> 4.1.0), xlibmesa-gl | libgl1,
 alsaplayer-common (= 0.99.76-7)
 -

There's no real reason that alsaplayer-common needs to Depend on an
alsaplayer-output variant or an alsaplayer-interface variant.  As a
user, if I just want to look at the common files for some reason, I
sholudn't need to install alsaplayer-(output|gtk).  Those would be fine
as Recommends.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: PDF files and dh_compress

[Frank Küster]

Hi,

If you want to discuss this further, please move the discussion to
-legal;  you can ask to get Cc's if you aren't subscribed there.

Charles Plessy <[EMAIL PROTECTED]> wrote:

> On Wed, May 10, 2006 at 07:21:58AM +0200, Florian Weimer wrote :
>> * Frank Küster:
>> 
>> > Most PDF files in Debian are already compressed;  at least those
>> > which are generated on a Debian system, and somehow TeX is involved
>> > are.  
>> 
>> And those which haven't been rebuilt could well be non-free anyway
>> (because we lack the source code). 8->
>
> Dear all, dear Florian,
>
> I am preparing a package (1) in which I have added the the PDF manual
> (2) which in the public domain. It has been created from a MSWord
> document. The upstream author is considering rewriting it in LaTeX, but
> of course, ther is no guarantee that it will be done shortly.

It shouldn't be hard, though (no fancy formatting, tables etc.). By the
way, I'd strongly recommend to *not* write it in LaTeX.  At least the
part about the commandline options looks like it should be kept in some
format that allows to create the man page from it.

> Does it mean that I have to remove the pdf documentation, and indicate
> to the users how to download it by themselves in the manpage and/or
> README.Debian?

No, you have two alternative options: Either get the word document from
the author and check whether it can be handled by OpenOffice.  I'm not
sure whether it's necessary to recreate the PDF from OpenOffice (nor
whether OpenOffice is scriptable), but you should at least check that
the PDF file uses only free fonts.

If you can't get the word document, we can still distribute the PDF file
in non-free.

> Interestingly, one could consider that a PDF file is not a program. 

Which is irrelevant - Debian has resolved by General Resolution that all
material in the distribution has to be free according to the DFSG, not
only programs.

> As in addition this one is in the public domain, it has no licence nor
> copyright. 

This is contradictory or at least unclear.  In many legislations,
there's no such thing as "public domain", so it *needs* a public-domain
like license, e.g.

"You may use, modify and/or distribute this test without restrictions."

> Does it mean that the DFSG do not apply and that I can
> distribute it in the debian package ?

The fact that something has been put in the Public Domain does not mean
that the DFSG would not apply to it - it just means that it is DFSG-free.



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

Re: multiarch status update

[Gabor Gombas]

On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote:

> Does it also allow multiple versions of the same package to be
> installed at the same time?
> For example, multiple minor versions or multiple major versions?

I think that's not going to fly. Just think about the different
arch-dependent packages depending on incompatible versions of an
arch-independent package.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: multiarch status update

[Olaf van der Spek]

On 5/10/06, Gabor Gombas <[EMAIL PROTECTED]> wrote:

On Wed, May 10, 2006 at 02:54:23PM +0200, Olaf van der Spek wrote:

> Does it also allow multiple versions of the same package to be
> installed at the same time?
> For example, multiple minor versions or multiple major versions?

I think that's not going to fly. Just think about the different
arch-dependent packages depending on incompatible versions of an
arch-independent package.


Why would that not fly?
Both versions of the arch-independent package could be installed at
the same time.

Re: Getting rid of circular dependencies, stage 4

[Brendan O'Dea]

On Wed, May 10, 2006 at 02:51:59PM +0200, Pierre Habouzit wrote:
>Le Mer 10 Mai 2006 14:40, Brendan O'Dea a écrit :
>> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:
>> >Here the lists of packages involved in circular dependencies listed
>> > by maintainers.
>> >
>> >perl
>> >perl-modules
>>
>> These two packages are meant to be installed together, split only for
>> arch any/all.
>>
>> I'm a bit puzzled as to why this is a problem, since this particular
>> dependency exists in sarge and as far as I no caused no upgrade
>> issues.
>
>cycles are evil, so when you can avoid them, it's better, and here ...

A specific problem, rather than a vague description of "evil" would
help.

>> Note that the dependency expressed is not exactly circular, since the
>> perl-modules dependency on perl is "looser" than the inverse.  Don't
>> know if this matters for the problem you're trying to fix.
>
>perl-modules should not depends on perl. It's useless to have only 
>perl-modules installed, but this create no harm.
>
>moreover people just apt-get install perl, so that won't break anything.

That would be true if perl depended on perl-modules (= current-ver).

The current dependencies are used to allow a slightly newer version of
perl-modules to be installed:  porters had issues in unstable where perl
was uninstallable due to the package not having built on an
architecture.*

Simply having perl depend on perl-modules (>= current-ver) is more
problematic than the case you describe, since a sarge user may upgrade
just perl-modules 5.8.4-x to 5.8.8-y, retaining the older perl package
and things would go pear-shaped.

--bod

* ISTR some discussion about modifications to the archive suite which
  would keep binary packages from the same source package together on a
  per-arch basis, which would resolve this particular issue.


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

Re: Getting rid of circular dependencies, stage 4

[Josselin Mouette]

Le mercredi 10 mai 2006 à 23:44 +1000, Brendan O'Dea a écrit :
> A specific problem, rather than a vague description of "evil" would
> help.

See for example
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316403;msg=15
among many RC bugs caused by circular dependencies.

-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Getting rid of circular dependencies, stage 4

[Brendan O'Dea]

On Wed, May 10, 2006 at 03:01:21PM +0200, Henning Glawe wrote:
>On Wed, May 10, 2006 at 10:40:32PM +1000, Brendan O'Dea wrote:
>> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:
>> >Here the lists of packages involved in circular dependencies listed by
>> >maintainers.
>> >
>> >perl
>> >perl-modules
>> 
>> These two packages are meant to be installed together, split only for
>> arch any/all.
>> 
>> I'm a bit puzzled as to why this is a problem, since this particular
>> dependency exists in sarge and as far as I no caused no upgrade issues.
>
>what about the issue showing up in conjunction with doc-base? both perl and
>perl-modules were installed, but not in matching versions (due to apt being
>confused about the circular dep) during the upgrade
>from 5.6 to 5.8, which made packages calling install-docs in their
>maintainer scripts fail, if I remember correctly...

Different issue.

The problem there was outside of the scope of dependencies:  since
install-docs gets called conditionally, packages don't declare a
dependency on doc-base, so don't get the dependency on perl and
install-docs may be called before all required packages are configured.

Having install-docs work only with essential packages (perl-base) fixes
that problem (fixed in 0.7.18-0.1).

See http://lists.debian.org/debian-perl/2004/12/msg0.html and
http://bugs.debian.org/278495 for details.

--bod


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

Re: Getting rid of circular dependencies, stage 4

[Pierre Habouzit]

Le Mer 10 Mai 2006 15:44, Brendan O'Dea a écrit :

> The current dependencies are used to allow a slightly newer version
> of perl-modules to be installed:  porters had issues in unstable
> where perl was uninstallable due to the package not having built on
> an architecture.*

Package: perl
Depends: perl-modules (>= ${source:Version})

achieves that IMHO.

>
> Simply having perl depend on perl-modules (>= current-ver) is more
> problematic than the case you describe, since a sarge user may
> upgrade just perl-modules 5.8.4-x to 5.8.8-y, retaining the older
> perl package and things would go pear-shaped.

that is higly unlikely since nothing should depends only from 
perl-modules. (In fact, IMHO nothing should depends from perl-modules 
at all).

so the only way for a user to upgrade perl-modules only is to apt-get 
install perl-modules which looks like an awkward thing to do.

moreover:

Package: perl-modules
Conflicts: perl (<< ${source:Version})

looks like achieving what you want.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp17dlFoMogb.pgp
Description: PGP signature

Re: Getting rid of circular dependencies, stage 4

[Daniel Schepler]

Le Mardi 09 Mai 2006 22:49, Bill Allombert a écrit :
> Debian Qt/KDE Maintainers 
...
>   libkcal2b
>   libkdepim1a

It looks like these two have circular dependencies because libkdepim depends 
on libkcal, while a couple of the standard libkcal plugins (namely 
kcal_kabc.so and kcal_remote.so) depend on libkdepim.  I don't see any easy 
way to disentangle these.
-- 
Daniel Schepler

Re: bacula_1.38.8-0.1_i386.changes is NEW

[John Goerzen]

On Wed, May 10, 2006 at 01:36:47PM +0200, José Luis Tallón wrote:
> Ok. I don't like flamewars either. There are plenty on Debian-Devel.

I should point out that you CC'd your reply to this message I sent you
in private to debian-devel. 

> > Unfortunate, but the proper thing to do in this situation is to announce
> > the situation and solicit NMUs from people.  As far as I have seen, you
> > did not do this.
> >   
> Hmm... I will keep that in mind for the next time, should it ever happen
> (hopefully not)
> But I can't see it anywhere in the Policy nor in the Developers' Reference.

http://www.debian.org/doc/developers-reference/ch-developer-duties.en.html#s-inform-vacation

> > There are several reasons I have made the NMUs I have, and that I intend
> > to take over this package.  Some of them are:
> >
> >  * Release-critical bugs that were open for over a year (303862)
> >or a very long time (343762).  Some of these were trivial (10-second)
> >fixes.
> >   
> Well... no upload = no bugfixes

I find it extremely hard to believe that you couldn't find anyone to
sponsor an upload with RC bugfixes in a YEAR, especially since you
stated that your AM had offered to sponsor uploads for you.  The only
reason I could see that happening is if your packages are in such bad
shape that they don't build or that a sponsor refuses to upload it on
quality grounds.  Both of which could be the case here.

> >  * Bacula was removed from testing three months ago due to its
> >bugginess.
> >   
> So what? that's obvious. Buggy package ==> removed from testing.
> That is how we ensure our OS's quality.

Bacula itself is not buggy.  The Debian packages of it are.

[ snip a lot of stuff about databases ]

You say that you have let the PostgreSQL code languish because you don't
know PostgreSQL.  Maybe.  But you should know enough to know that
stopping and restarting a database server without asking permission is
terrible, and where to find the call to the init script that does that.

You could also install PostgreSQL, read its docs, and test.  It isn't
all that difficult.  Certainly doesn't warrant that bug being there for
years.

There are all sorts of other problems: build-dep'ing on libsqlite3-dev
when you are going to look for Sqlite v2, etc.

> >  * Your clean target was ineffective and caused a huge diff.gz
> >   
> For 1.38 ? Yes. Can't clean before you have it built, right?

Yes, you can, and should be able to.  The debian/rules clean target
should clean the package from any state.  It also didn't do a very good
job of cleaning it from being built.

> >  * Bacula would link against Python 2.2 in some cases even though you
> >dep'd on python2.3
> >   
> Didn't get to it, either. Fortunately, your patches address that
> problem, right?

Correct.

> >  * Policy violations in numerous places, including treatment of logfiles
> >   
> Touché  as for the logfiles.
> I would like to know what are the other Policy violations you refer to,
> so that i can learn from those.

Here are the ones I've *noticed* (some of these are best practices as
opposed to policy violations):

 * Logfiles in wrong directory

 * Postrm deleting files belonging to other packages, and breaking those
   packages in the process

 * Incorrect build-deps on Python and Sqlite

 * Missing build-deps for parts of gnome as well as mtx

 * No rotation for logfiles

 * Ineffective clean target

 * Probably dozens of cruft files in debian/

 * Hacking upstream configure system and hard-coding libraries
   (which may be incorrect on different archs and Debian versions)
   instead of using the suggested vim-like approach (see developer's
   ref)

 * Postinsts attempting to chmod files in other packages that are not
   even depended upon, then failing if those files don't exist

 * Bashisms in debian/rules, leading to FTBFS if /bin/bash is not
   /bin/sh on a given system.

 * Bashisms in maintainer scripts, leading to failure to install
   if /bin/bash is not /bin/sh on user's system

 * Dozens of other lintian errors and warnings -- run it yourself to
   see.

> >  * No rotation of logs
> >   
> That's a wishlist bug. I think that 'wishlist' comes after 'grave' or
> 'important'. Do you think otherwise?

In my book, this is grave, since it can -- and has -- lead to filling up
a disk and thus rendering many other packages useless.

> >  * Indiscriminate removing of /var/lib/bacula on removal, which would
> >completely break the remaining bacula packages on a system
> >   
> Hmm.. never had that problem, but i understand your point.
> Please note that i also use Bacula in production in several machines.

Until you have tried to remove it, you may not have seen it.

> >  * Bashisms in debian/rules.
> >   
> Ok. Didn't notice those, nor did lintian or linda.
> Care to point them so that i can learn?

Please just set /bin/sh to something other than bash or zsh and try it
again.

> >  * Poor handling of multiple-variants problem.  Hacking up configure

Re: Intent to hijack Bacula

[John Goerzen]

On Wed, May 10, 2006 at 12:10:52PM +0200, José Luis Tallón wrote:
> I previously declined very 'consistent' offers to adopt/take over
> Bacula, and offered co-maintenance instead.
> One of the main reasons: i have quite good relations with upstream
> (almost made them move main development to Debian -- will try again
> soon) and understand our user's problems quite well. Additionally, quite
> a lot of users have already contacted me.

There is no reason that your good relations with upstream should be
conditioned upon your listing as Maintainer of Bacula in Debian.
Furthermore, there is no reason to believe that you are the only person
capable of cultivating such.

> Some work a much needed dbconfig-common migration would be very
> interesting, too (i don't feel i have resources enough to tackle that on
> my own)

I plan to do this today.

> I couldn't be happier if that happened. We have a bit less than 3 months
> (until Etch freezes) to get all of this in shape. Any other volunteers?

I have not withdrawn my intent to take over Bacula.  I am volunteering
to do some pretty significant work on it, and have already done so.

-- John

Re: Getting rid of circular dependencies, stage 4

[Bill Allombert]

On Wed, May 10, 2006 at 10:40:32PM +1000, Brendan O'Dea wrote:
> On Tue, May 09, 2006 at 10:49:36PM +0200, Bill Allombert wrote:
> >Here the lists of packages involved in circular dependencies listed by
> >maintainers.
> >
> > perl
> > perl-modules
> 
> These two packages are meant to be installed together, split only for
> arch any/all.
> 
> I'm a bit puzzled as to why this is a problem, since this particular
> dependency exists in sarge and as far as I no caused no upgrade issues.
> 
> Note that the dependency expressed is not exactly circular, since the
> perl-modules dependency on perl is "looser" than the inverse.  Don't
> know if this matters for the problem you're trying to fix.

The issue is that it is undefined whether perl and perl-modules will be
configured first, which is something Depends is supposed to prevent.
This make installations and upgrades less predictable.

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: Getting rid of circular dependencies, stage 4

[Mike Bird]

On Wednesday 10 May 2006 01:24, Bill Allombert wrote:
> gjdoc kaffe kaffe-jthreads kaffe-pthreads
> http://debian.semistable.com/dot/kaffe-pthreads_stable.png

Can someone point me to an explanation for this (Etch)?

gjdoc depends on kaffe.  But kaffe-pthreads provides kaffe.

Why then is it necessary to install kaffe as well as kaffe-pthreads?

Thanks,

--Mike Bird


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

Re: System users and valid shells...

[Manoj Srivastava]

On 8 May 2006, Marc Haber outgrape:

> On Fri, 05 May 2006 11:12:35 +0300, Jari Aalto
> <[EMAIL PROTECTED]>
> wrote:
>> Richard A Nelson <[EMAIL PROTECTED]> writes:
>>> On Wed, 3 May 2006, Colin Watson wrote:
>>> The rest of the system accounts are happily running with
>>> /bin/false
>>
>> There is now /bin/nologin which is more secure
>
> You can surely explain why /bin/nologin is more secure than
> /bin/false. I'm eager to learn.

Since /bin/nologin is used in very specific circumstances, I
 can create far tighter security policy and auditing rules for use
 with /bin/nologin. /bin/false is used legitimately in scripts, so the
 audit trail is diffused, and /dev/null can't be restricted/audited to
 the same extent that either /bin/false or /bin/nologin can.

manoj
-- 
"The only difference between me and a madman is that I'm not mad."
Salvador Dali
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Getting rid of circular dependencies, stage 4

[Pierre Habouzit]

Le Mer 10 Mai 2006 17:01, Mike Bird a écrit :
> On Wednesday 10 May 2006 01:24, Bill Allombert wrote:
> > gjdoc kaffe kaffe-jthreads kaffe-pthreads
> > http://debian.semistable.com/dot/kaffe-pthreads_stable.png
>
> Can someone point me to an explanation for this (Etch)?
>
> gjdoc depends on kaffe.  But kaffe-pthreads provides kaffe.

which makes the look gjdoc <-> kaffee-pthreads because kaffee-?threads 
depends upon gjdoc.

> Why then is it necessary to install kaffe as well as kaffe-pthreads?

why do kaffe-[pj]threads depends upon gjdoc ? isn't a recommends 
enough ?

given its description, it looks like a developpement tool, and I don't 
get why it's needed just for running java apps, I even don't really 
understand why it should even *suggest* it.

IMHO kaffe-dev should depends upon gjdoc, because it makes sense, but 
not kaffee (or it's threaded implementations).
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpDrTylHkTiE.pgp
Description: PGP signature

Re: Getting rid of circular dependencies, stage 4

[Yves-Alexis Perez]

On Tue, 2006-05-09 at 22:49 +0200, Bill Allombert wrote:
>Hello Debian developers,
>
>Here the lists of packages involved in circular dependencies listed by
>maintainers.

[snip]

> Debian Xfce Maintainers <[EMAIL PROTECTED]>
> xfce4-mixer
> xfce4-mixer-alsa
> xfce4-mixer-oss
> 

In this situation, xfce4-mixer depends on xfce4-mixer-(alsa|oss).
xfce4-mixer contains common files, an executable, a panel plugin,
locales... It relies on two backend libs, an oss or an alsa one. 

xfce4-mixer really depends on the backends, it won't work without one of
them. We made the backends depends on xfce4-mixer because it's useless
to have them installed without the mixer. But it's not harmful either,
so I just changed the Depends: to Recommends: (btw people should not
install directly xfce4-mixer-(alsa|oss) but install xfce4-mixer).

It'll be fixed in the next package version.

Regards,
-- 
Yves-Alexis Perez


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

Re: PDF files and dh_compress

[Charles Plessy]

Dear all, dear Frank,

If it was the intention of the general resolution you are reffering to
that any document which has been created by automatic processing of
another document could not be distributed without its "source", it is
rather unfortunate that it refers to the DFSG, which explicitely use
the term "program" in their paragraph 2.

However, I do not want to argue, and your comment about the possibility
that the PDF file might contain non-free fonts also makes sense. I will
not include the PDF in my package.

As for the public domain, I thought I was on solid ground because work
made by public servants in the USA is automatically public domain.
However, I realised that the Standford university where the software has
been released is private (correct me if I am wrong), thus the program
can not be in public domain.

I will document this in the copyright file, and ask the upstream author
if he agrees to rephrase his statement. (However, my limited experience
showed me that when authors chose permissive licences or statement, they
are not generally interested in managing their copyrights as rigourously
as Debian expects it...)

Have a nice day,

-- 
Charles Plessy
Wako, Saitama, Japan


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

Re: Getting rid of circular dependencies, stage 4

[Frank Küster]

Brendan O'Dea <[EMAIL PROTECTED]> wrote:

>>perl-modules should not depends on perl. It's useless to have only 
>>perl-modules installed, but this create no harm.
>>
>>moreover people just apt-get install perl, so that won't break anything.
>
> That would be true if perl depended on perl-modules (= current-ver).

And how is apt supposed to install both if they are not present at all
before the installation?

Well, it isn't, since perl is installed by debootstrap (or whatever the
installer uses), but this exception shouldn't be taken as an excuse to
not fix a bug that's easily fixable.

> Simply having perl depend on perl-modules (>= current-ver) is more
> problematic than the case you describe, since a sarge user may upgrade
> just perl-modules 5.8.4-x to 5.8.8-y, retaining the older perl package
> and things would go pear-shaped.

Upgrading from sarge should be done according to the instructions in the
release notes.  The only things that should be installed separately are
probably aptitude, apt and dpkg, then just dist-upgrade.

To prevent such "problems" in the future, perl 5.8.n could Conflict with
perl-modules ( >= 5.8.(n+1) ), but I'm not sure this doesn't cause other
problems. 

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

Re: Getting rid of circular dependencies, stage 4

[Daniel Schepler]

Le Mercredi 10 Mai 2006 17:09, Pierre Habouzit a écrit :
> why do kaffe-[pj]threads depends upon gjdoc ? isn't a recommends
> enough ?
>
> given its description, it looks like a developpement tool, and I don't
> get why it's needed just for running java apps, I even don't really
> understand why it should even *suggest* it.
>
> IMHO kaffe-dev should depends upon gjdoc, because it makes sense, but
> not kaffee (or it's threaded implementations).

This was already discussed in bug #328648 and #362769, where the kaffe 
maintainers say that kaffe is supposed to be a whole development kit.  I 
don't understand myself why they can't just make kaffe be a metapackage 
depending on everything, and still make it possible to install just the 
runtime if you really want.
-- 
Daniel Schepler

Re: Intent to hijack Bacula

[Wouter Verhelst]

On Wed, May 10, 2006 at 09:26:33AM -0500, John Goerzen wrote:
> On Wed, May 10, 2006 at 12:10:52PM +0200, José Luis Tallón wrote:
> > I couldn't be happier if that happened. We have a bit less than 3 months
> > (until Etch freezes) to get all of this in shape. Any other volunteers?
> 
> I have not withdrawn my intent to take over Bacula.  I am volunteering
> to do some pretty significant work on it, and have already done so.

You should not go ahead and remove José from maintenance over his
objection if he offers you co-maintenance. Your reason for hijacking
bacula seems to have been that José was slacking, not anything personal
or some such. In that case, I can understand that you want to take over
so that the work gets done. But if José says "I'm more than willing to
let you help out, but I still want to work on it", then that should be
respected; this is how it's always done in Debian.

Of course, if I misunderstood something, or you have some compelling
reason to block José from cooperating that you haven't talked about yet,
I'm happy to be enlightened.

-- 
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: Intent to hijack Bacula

[Marco d'Itri]

On May 10, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

> You should not go ahead and remove José from maintenance over his
> objection if he offers you co-maintenance. Your reason for hijacking
> bacula seems to have been that José was slacking, not anything personal
> or some such. In that case, I can understand that you want to take over
> so that the work gets done. But if José says "I'm more than willing to
> let you help out, but I still want to work on it", then that should be
> respected; this is how it's always done in Debian.
Except that he is not a developer and so far has not showed the minimal
competence required to maintain a package, nor attempts to improve his
procedures.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: PDF files and dh_compress

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> As for the public domain, I thought I was on solid ground because work
> made by public servants in the USA is automatically public domain.
> However, I realised that the Standford university where the software has
> been released is private (correct me if I am wrong), thus the program
> can not be in public domain.

Stanford University is indeed a private institution and the copyright of
works for hire for Stanford University vests in the Board of Trustees.
However, Stanford is generally fairly good about using reasonable
licenses, at least after a bit of prompting.

Note that copyright even for public educational institutions is more
complex than that.  The copyright on BSD, for example, is still held by
the board of trustees of the University of California; it isn't public
domain, even though that's a public institution.  In practice, the rules
that say that work done by the government is automatically public domain
are undermined by enough special cases that it's best not to rely on them
without an explicit statement.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Getting rid of circular dependencies, stage 4

[Brendan O'Dea]

On Wed, May 10, 2006 at 04:20:19PM +0200, Pierre Habouzit wrote:
>Le Mer 10 Mai 2006 15:44, Brendan O'Dea a écrit :
>
>> The current dependencies are used to allow a slightly newer version
>> of perl-modules to be installed:  porters had issues in unstable
>> where perl was uninstallable due to the package not having built on
>> an architecture.*
>
>Package: perl
>Depends: perl-modules (>= ${source:Version})
>
>achieves that IMHO.

Yes, that's exactly what is used now.

>> Simply having perl depend on perl-modules (>= current-ver) is more
>> problematic than the case you describe, since a sarge user may
>> upgrade just perl-modules 5.8.4-x to 5.8.8-y, retaining the older
>> perl package and things would go pear-shaped.
>
>that is higly unlikely since nothing should depends only from 
>perl-modules. (In fact, IMHO nothing should depends from perl-modules 
>at all).

Correct.  I'd prefer that nothing did.  See however the output of
'apt-cache rdepends perl-modules'.

Selecting a random entry from that list with a versioned dependency,
'munin':

  Depends: perl (>= 5.6.0-16), perl-modules (>= 5.8.0) | 
libparse-recdescent-perl, [...]

>so the only way for a user to upgrade perl-modules only is to apt-get 
>install perl-modules which looks like an awkward thing to do.

People do.  Particularly those with limited network connectivity. 

Consider a sarge dialup user who wants a newer version of
libcgi-pm-perl, so adds unstable to sources.list and tries

  apt-get install libcgi-pm-perl

sees

  Package libcgi-pm-perl is a virtual package provided by:
perl-modules 5.8.4-8sarge5
  You should explicitly select one to install.

So chooses to run

  apt-get install perl-modules

>moreover:
>
>Package: perl-modules
>Conflicts: perl (<< ${source:Version})
>
>looks like achieving what you want.

Perhaps (although using ${Upstream-Version}-1).

That does seem to work for a dist-upgrade to sid from sarge (after
manually tweaking the depends/conflicts on perl-modules in
/var/lib/apt/lists/*).

A bit gun-shy about adding conflicts to perl since the 5.005 -> 5.6.0
transition, which produced some upgrade disasters like
http://lists.debian.org/debian-perl/2001/02/msg00031.html (apt choosing
to remove the conflicted target and all dependent packages...)

Will consider for the next upload.

--bod


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

Re: PDF files and dh_compress

[Frank Küster]

Please, this time, obey the Followup-to to debian-legal.

Charles Plessy <[EMAIL PROTECTED]> wrote:

> However, I do not want to argue, 

Yes. Please. Please do not argue before you've read the discussions we
already had on this.  I don't expect you to find any relevant new
points. 

> and your comment about the possibility
> that the PDF file might contain non-free fonts also makes sense. I will
> not include the PDF in my package.

Judging from the list of fonts included, it should be possible to
replace them by similar free fonts (Helvetica instead of Arial, a better
choice anyway, URW Courier instead of CourierNew, URW Times instead of
TimesNewRoman. 

> As for the public domain, I thought I was on solid ground because work
> made by public servants in the USA is automatically public domain.
> However, I realised that the Standford university where the software has
> been released is private (correct me if I am wrong), thus the program
> can not be in public domain.

But it can be put into the public domain, or at least a state that's
equivalent in effect.  From a short look at the document and the web
page, though, it looks as if there's no license at all.  

This means that we do not have a permission to redistribute that file
(nobody has) and *must* remove it ASAP.

> I will document this in the copyright file, and ask the upstream author
> if he agrees to rephrase his statement.

The existing statement for the software is perfect, no need to rephrase
anything.  The non-existent statement for the Documentation is the
problem. 

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

Re: Intent to hijack Bacula

[Frank Küster]

[EMAIL PROTECTED] (Marco d'Itri) wrote:

> Except that he is not a developer and so far has not showed the minimal
> competence required to maintain a package, nor attempts to improve his
> procedures.

I also don't see how it matters: If José and John were Co-maintainers,
no other DD would sponsor José's uploads.  In consequence, John would be
the only uploader, and if he doesn't at the moment trust José's
knowlegde or skills, he'll inspect his packages very critical, no matter
whether José is in the Uploaders field or not.  

Similar if the Maintainer: is set to a to-be-created mailing list:  As
soon as there's one DD among the Uploaders, any non-DD is as much a
maintainer of the package as this DD (or the DDs) are willing to rely on
his work.

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

Re: Intent to hijack Bacula

[John Goerzen]

On Wed, May 10, 2006 at 06:12:52PM +0200, Wouter Verhelst wrote:
> > I have not withdrawn my intent to take over Bacula.  I am volunteering
> > to do some pretty significant work on it, and have already done so.
> 
> You should not go ahead and remove José from maintenance over his
> objection if he offers you co-maintenance. Your reason for hijacking
> bacula seems to have been that José was slacking, not anything personal
> or some such. In that case, I can understand that you want to take over

Well, I would say it's more that he has written very poor code -- some
of which has been broken for several years -- and has not made much
effort to fix it.  For at least some of it, he does not believe there is
a problem.  Take a look at the BTS if you want.  My first NMU closed 22
bugs (or will, once it gets out of NEW).

> so that the work gets done. But if José says "I'm more than willing to
> let you help out, but I still want to work on it", then that should be
> respected; this is how it's always done in Debian.

I have made it clear to everyone -- him included -- that I would be
happy to receive patches.  I will, however, be sure to review them
before applying them.

> Of course, if I misunderstood something, or you have some compelling
> reason to block José from cooperating that you haven't talked about yet,
> I'm happy to be enlightened.

The most compelling reason:

http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];arch=source

Please note that the pending upload bugs on that page are ones that are
fixed in my NMU.

There are all sorts of other long-term blatant problems with Bacula that
weren't reported to the BTS.  His AM had already mentioned quite a few
to him back in February.  I don't believe jltallon is yet suited to
maintain a package of this complexity.

-- John

Re: Intent to hijack Bacula

[John Goerzen]

On Wed, May 10, 2006 at 07:03:16PM +0200, Frank Küster wrote:
> I also don't see how it matters: If José and John were Co-maintainers,
> no other DD would sponsor José's uploads.  In consequence, John would be

There is no guarantee of that.  Somebody has been uploading these
packages all along, and whoever it was didn't take a very close look at
them.  Plus, he is in NM and may become a DD in the future.  Though I
believe his AM is not very pleased with the Bacula situation -- his AM
encouraged me to hijack this package, in fact.

> the only uploader, and if he doesn't at the moment trust José's
> knowlegde or skills, he'll inspect his packages very critical, no matter
> whether José is in the Uploaders field or not.  

If Jose were primary maintainer, and I was a co-maintainer (or one of
several), he would still get the final say over whether or not he would
accept my patches, and would still get the final say over making changes
to the package.  I do not have confidence that he would bear that
responsibility well.

Re: bacula_1.38.8-0.1_i386.changes is NEW

[Lionel Elie Mamane]

On Wed, May 10, 2006 at 09:23:03AM -0500, John Goerzen wrote:
> On Wed, May 10, 2006 at 01:36:47PM +0200, José Luis Tallón wrote:
>> Ok. I don't like flamewars either. There are plenty on Debian-Devel.

>>>  * Your clean target was ineffective and caused a huge diff.gz

>> For 1.38 ? Yes. Can't clean before you have it built, right?

> Yes, you can, and should be able to.  The debian/rules clean target
> should clean the package from any state.

While this is true in an abstract sense, this is not true for many,
many packages. I'd expect most of those that use autoconf not to clean
up correctly if configure is interrupted / fails before creating the
Makefile.

-- 
Lionel


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

Re: bits from the release team

[Joey Hess]

Goswin von Brederlow wrote:
> Except that apt-get fails if any of the signatures are unknown or
> expired. So you still need both keys and not just one of them as you
> intent.

No, that used to be apt's behavior, but since January apt and all other
Release-verifying tools (debootstrap, net-retriever) have been satisfied
to know only one key out of multiple signatures.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 4

[Dagfinn Ilmari Mannsåker]

Brendan O'Dea <[EMAIL PROTECTED]> writes:

> On Wed, May 10, 2006 at 04:20:19PM +0200, Pierre Habouzit wrote:
>> (In fact, IMHO nothing should depends from perl-modules at all).
>
> Correct.  I'd prefer that nothing did. 

Is this documented anywhere? If is really is the case that nothing
should depend on perl-modules (but rather on perl itself), the Perl
Policy should mention it in the dependencies section.

> Selecting a random entry from that list with a versioned dependency,
> 'munin':
>
>   Depends: perl (>= 5.6.0-16), perl-modules (>= 5.8.0) | 
> libparse-recdescent-perl, [...]

Speaking as co-maintainer of munin, should we just change that to "perl
(>= 5.8.0) | libparse-recdescent-perl" instead? Won't lintian complain
about a duplicate relation on perl in that case, or has that been fixed?

(We want the packages to be installabe on woody with the minimum amount
of fuss, so we don't want to just depend on perl (>= 5.8.0)).

-- 
ilmari
"A disappointingly low fraction of the human race is,
 at any given time, on fire." - Stig Sandbeck Mathisen


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

Re: Intent to hijack Bacula

[José Luis Tallón]

John Goerzen wrote:
> On Wed, May 10, 2006 at 06:12:52PM +0200, Wouter Verhelst wrote:
>   
>>> I have not withdrawn my intent to take over Bacula.  I am volunteering
>>> to do some pretty significant work on it, and have already done so.
>>>   
>> You should not go ahead and remove José from maintenance over his
>> objection if he offers you co-maintenance. Your reason for hijacking
>> bacula seems to have been that José was slacking, not anything personal
>> or some such. In that case, I can understand that you want to take over
>> 
>
> Well, I would say it's more that he has written very poor code -- some
> of which has been broken for several years 
The package itself is a bit more than two years old.
Most of your concerns are with PostgreSQL-related code, which is much
newer (first introduced w/ Bacula-1.36)
> -- and has not made much effort to fix it.  For at least some of it, he does 
> not believe there is
> a problem.  Take a look at the BTS if you want.  My first NMU closed 22
> bugs (or will, once it gets out of NEW).
>   
>> so that the work gets done. But if José says "I'm more than willing to
>> let you help out, but I still want to work on it", then that should be
>> respected; this is how it's always done in Debian.
>> 
>
> I have made it clear to everyone -- him included -- that I would be
> happy to receive patches.  I will, however, be sure to review them
> before applying them.
>   
That means a change in maintainership without RFA/O nor MIA status.
>> Of course, if I misunderstood something, or you have some compelling
>> reason to block José from cooperating that you haven't talked about yet,
>> I'm happy to be enlightened.
>> 
>
> The most compelling reason:
>
> http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];arch=source
>
> Please note that the pending upload bugs on that page are ones that are
> fixed in my NMU.
>   
Not anymore. I have already added some of my own   o_O
> There are all sorts of other long-term blatant problems with Bacula that
> weren't reported to the BTS. 
Then go ahead and report them yourself. That's what the BTS is for.

... and attaching patches for NMUs once (or even before) they are
uploaded, according to the Policy.
Again, where are they? I had to ask for the diff corresponding to
1.38.8-0.1, but haven't received the patches for the following three
uploads.

Please, will you abide by the Policy before criticizing others'
non-compliance ?
I am still the maintainer, after all...
> His AM had already mentioned quite a few to him back in February.
Yes. The ones relating to static linking I have already solved for a
long time.
The ones related to PgSQL... still didn't have the knowledge nor the
time needed
> I don't believe jltallon is yet suited to maintain a package of this 
> complexity.
>   
Well... at least this means I am not completely incompetent as a
maintainer...
You have just conceded that this package is tremendously complex. Thanks.




I'd rather fix bugs than keep discussing. As I said before, I never
liked flamewars
(and, before you say it, I will:  just watch out for uploads in my name.
This time I have the means )



J.L.


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

Re: Getting rid of circular dependencies, stage 4

[Joey Hess]

Frank Küster wrote:
> Well, it isn't, since perl is installed by debootstrap (or whatever the
> installer uses)

*blank stare*

> Upgrading from sarge should be done according to the instructions in the
> release notes.  The only things that should be installed separately are
> probably aptitude, apt and dpkg, then just dist-upgrade.

No, Debian supports partial upgrades. The instructions in the release
notes wouldn't _work_ if we didn't.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: PDF files and dh_compress

[John Hasler]

Russ Allbery writes:
> In practice, the rules that say that work done by the government is
> automatically public domain...

Work done by US federal government employees on government time is
effectively public domain.  This does _not_ apply to work done by state or
local government employees.  It also does not apply to work done by US
federal government contractors.

> ...are undermined by enough special cases that it's best not to rely on
> them without an explicit statement.

Could you describe these special cases?
-- 
John Hasler


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

lists.debian.org Has been added...

[Shawn Myers]

Hello,

I'm writing to let you know that I have just added your website,
lists.debian.org, to my directory.

You can find your listing here...

http://www.faxwin.com/efax

I also wanted to gauge your interest in networking our websites
together more closely for mutual benefit.

If you would consider linking to http://www.faxwin.com from
your own website, I would be more than happy to increase
your listing to "premium status". This will always ensure that
your listing appears at the top of your category above all other
normal listings, even if new webmasters submit their website to
the same category in the future.

I think you have a fantastic site, and would love to have you as
a strategic link partner.

If you're interested, simply reply to this entire email and let
me know where you've placed the link to http://www.faxwin.com
on your own site, and I will immediately modify your listing to
premium status.

I look forward to hearing from you soon & keep up the great work...

Sincerely,
Shawn Myers
mailto:[EMAIL PROTECTED]


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

Re: PDF files and dh_compress

[Russ Allbery]

John Hasler <[EMAIL PROTECTED]> writes:
> Russ Allbery writes:

>> In practice, the rules that say that work done by the government is
>> automatically public domain...

> Work done by US federal government employees on government time is
> effectively public domain.  This does _not_ apply to work done by state
> or local government employees.  It also does not apply to work done by
> US federal government contractors.

>> ...are undermined by enough special cases that it's best not to rely on
>> them without an explicit statement.

> Could you describe these special cases?

The US federal government contractor one is the one that I'm the most
familiar with, particularly since it has tentacles into a lot of things
that might on the surface appear to be work done by US federal government
employees on government time.  Beyond that, if I had more specifics, I
wouldn't tend as strongly towards suggesting caution.  :)  It's precisely
because the situation in practice seems rather murky that I recommend
being careful.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Intent to hijack Bacula

[Wouter Verhelst]

On Wed, May 10, 2006 at 12:08:57PM -0500, John Goerzen wrote:
> On Wed, May 10, 2006 at 06:12:52PM +0200, Wouter Verhelst wrote:
> > > I have not withdrawn my intent to take over Bacula.  I am volunteering
> > > to do some pretty significant work on it, and have already done so.
> > 
> > You should not go ahead and remove José from maintenance over his
> > objection if he offers you co-maintenance. Your reason for hijacking
> > bacula seems to have been that José was slacking, not anything personal
> > or some such. In that case, I can understand that you want to take over
> 
> Well, I would say it's more that he has written very poor code -- some
> of which has been broken for several years -- and has not made much
> effort to fix it.

Okay. That wasn't very clear from your initial post.

> For at least some of it, he does not believe there is a problem.

In itself, this shouldn't be a reason for hijacking a package (though
I'll admit that it can be a compelling argument).

> Take a look at the BTS if you want.  My first NMU closed 22 bugs (or
> will, once it gets out of NEW).
> 
> > so that the work gets done. But if José says "I'm more than willing to
> > let you help out, but I still want to work on it", then that should be
> > respected; this is how it's always done in Debian.
> 
> I have made it clear to everyone -- him included -- that I would be
> happy to receive patches.  I will, however, be sure to review them
> before applying them.

Sure.

> > Of course, if I misunderstood something, or you have some compelling
> > reason to block José from cooperating that you haven't talked about yet,
> > I'm happy to be enlightened.
> 
> The most compelling reason:
> 
> http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];arch=source
> 
> Please note that the pending upload bugs on that page are ones that are
> fixed in my NMU.

Right.

> There are all sorts of other long-term blatant problems with Bacula that
> weren't reported to the BTS.  His AM had already mentioned quite a few
> to him back in February.  I don't believe jltallon is yet suited to
> maintain a package of this complexity.

Okay; this explains quite a lot. If bacula really is in a sorry shape (I
wouldn't know, I don't use it), then what you're planning to do would
seem to be a good idea.

It's just that I'm quite concerned about the precendent this creates. Up
until now, people have abandoned packages when other people felt the
packages in question where poorly maintained. I remember the case of the
mozilla packages back in pre-woody times, when it was felt that the
maintainer was doing a very poor job at it, too; eventually, though, he
was persuaded to hand over maintenance of mozilla to Takuo KITAME, who
had already been doing some NMU's, if I recall correctly; I'd have
preferred seeing something similar here, if that had been possible. If
not... I'll agree that uncommon problems require uncommon solutions, but
then you have to make clear it's an uncommon problem you're talking
about. Your initial post didn't do that.

That being said, 

The only way you can get experienced developers is by allowing people to
maintain packages and gain experience. While this is usually done
through having people maintain a small package, and having them take on
larger packages as time goes on, there is something to be said for
people who jump in the deep, and learn as time goes on, which is what
José did with the bacula packages. It didn't turn out to work, but then
noone is infallible. However, if José is willing to learn, I do think
it'd be nice if he would remain as co-maintainer. Having a seasoned
developer like yourself in the team to help out and explain where and
why things are good or bad will surely help in the long run. In light of
that, and in light of his past contributions (good and, well, 'not as
good') which he's already done, please consider allowing José a more
active role on the bacula packages than "he can send in patches like
everyone else."

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


signature.asc
Description: Digital signature

Re: Getting rid of circular dependencies, stage 4

[Hubert Chan]

On Wed, 10 May 2006 09:04:14 -0400, James Vega <[EMAIL PROTECTED]> said:

> On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote:
>> Hmm...  alsaplayer-common Depends: on "alsaplayer-alsa |
>> alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface".  Is
>> this really a problem?

My question, which I guess wasn't clear, was whether the circular
dependency is still a problem if one of the dependencies in the cycle is
an or'ed dependency.

[...]

> There's no real reason that alsaplayer-common needs to Depend on an
> alsaplayer-output variant or an alsaplayer-interface variant.  As a
> user, if I just want to look at the common files for some reason, I
> sholudn't need to install alsaplayer-(output|gtk).  Those would be
> fine as Recommends.

alsaplayer-common contains the main alsaplayer binary
(/usr/bin/alsaplayer), which does not function without an
alsaplayer-output and alsaplayer-input plugin.  So yes, it really does
depend on these.  (I would have named alsaplayer-common something
different -- maybe alsaplayer-bin, or just alsaplayer, but that was what
it was called when I inherited it.)

A Recommends: might work, since aptitude will try to install recommended
packages, but I think that Depends: describes the package relationship
much better, and so I don't want to change it unless absolutely
necessary.

-- 
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: Intent to hijack Bacula

[John Goerzen]

On Wed, May 10, 2006 at 07:53:23PM +0200, Wouter Verhelst wrote:
> developer like yourself in the team to help out and explain where and
> why things are good or bad will surely help in the long run. In light of
> that, and in light of his past contributions (good and, well, 'not as
> good') which he's already done, please consider allowing José a more
> active role on the bacula packages than "he can send in patches like
> everyone else."

One thing I should mention, and I guess I should have said this
yesterday...

A couple of people have suggested setting up an Alioth project for
Bacula, and I think that sounds like a good idea.  I plan to do that
within the next few days -- I am still making some significant changes
to the package yet, and it would be difficult for others to follow
development right now.

Jose will be welcome to join that effort.

-- John

Re: Emacs out for lunch?

[Kurt Petersen]

Kurt Petersen wrote:
> I was the happy user of Emacs on Debian unstable. After a normal 
>   apt-get update; apt-get dist-upgrade
> Emacs disappeared and has not been seen later. I'm I the only one to
> miss it?
> 
> Could this be the reason:
> 
> # apt-get install  emacs21-nox
> [...]
> The following packages have unmet dependencies:
>   emacs21-nox: Depends: emacs21-bin-common (= 21.4a-3) but it is not going to 
> be installed
> E: Broken packages

It still does not work... 

Hasn't this package been tested in "testing"? It is about two weeks
now that it stopped working. 

Kurt


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

Re: Getting rid of circular dependencies, stage 4

[James Vega]

On Wed, May 10, 2006 at 01:41:56PM -0400, Hubert Chan wrote:
> On Wed, 10 May 2006 09:04:14 -0400, James Vega <[EMAIL PROTECTED]> said:
> 
> > On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote:
> >> Hmm...  alsaplayer-common Depends: on "alsaplayer-alsa |
> >> alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface".  Is
> >> this really a problem?
> 
> My question, which I guess wasn't clear, was whether the circular
> dependency is still a problem if one of the dependencies in the cycle is
> an or'ed dependency.

As far as I know, yes, they are still a problem.

> [...]
> 
> > There's no real reason that alsaplayer-common needs to Depend on an
> > alsaplayer-output variant or an alsaplayer-interface variant.  As a
> > user, if I just want to look at the common files for some reason, I
> > sholudn't need to install alsaplayer-(output|gtk).  Those would be
> > fine as Recommends.
> 
> alsaplayer-common contains the main alsaplayer binary
> (/usr/bin/alsaplayer), which does not function without an
> alsaplayer-output and alsaplayer-input plugin.  So yes, it really does
> depend on these.  (I would have named alsaplayer-common something
> different -- maybe alsaplayer-bin, or just alsaplayer, but that was what
> it was called when I inherited it.)

Ah, yes, I didn't take a look at the packages as well as I should have.
Taking a look at the package contents, it seems like changing the
alsaplayer-(output|input) variants to Recommending alsaplayer-common
would work fine.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Intent to hijack Bacula

[Olaf van der Spek]

On 5/10/06, Wouter Verhelst <[EMAIL PROTECTED]> wrote:

It's just that I'm quite concerned about the precendent this creates. Up
until now, people have abandoned packages when other people felt the
packages in question where poorly maintained. I remember the case of the


Sometimes they have abondoned it, but not always. Look at net-tools
for an example of an almost similar situation.

Re: Intent to hijack Bacula

[John Goerzen]

On Wed, May 10, 2006 at 07:37:34PM +0200, José Luis Tallón wrote:
> >> You should not go ahead and remove José from maintenance over his
> >> objection if he offers you co-maintenance. Your reason for hijacking
> >> bacula seems to have been that José was slacking, not anything personal
> >> or some such. In that case, I can understand that you want to take over
> >> 
> >
> > Well, I would say it's more that he has written very poor code -- some
> > of which has been broken for several years 
> The package itself is a bit more than two years old.
> Most of your concerns are with PostgreSQL-related code, which is much
> newer (first introduced w/ Bacula-1.36)

According to the changelog, you first released the PostgreSQL support in
August 2004 in 1.34.5-1.

But no, it is not accurate to say most of my concerns relate to
PostgreSQL.

> > There are all sorts of other long-term blatant problems with Bacula that
> > weren't reported to the BTS. 
> Then go ahead and report them yourself. That's what the BTS is for.

I have already uploaded fixes.  Why bother with that?

> ... and attaching patches for NMUs once (or even before) they are
> uploaded, according to the Policy.
> Again, where are they? I had to ask for the diff corresponding to
> 1.38.8-0.1, but haven't received the patches for the following three
> uploads.

I had every reason to believe that there were more bugs that could be
fixed prior to the uploaded packages exiting NEW.  I turned out to be
correct.  I planned all along to open a new bug with the full diff once
I had completed the NMU activities, as suggested by the developer's
reference.  NMU procedures are not mentioned in the Debian Policy.

Posting an individual patch to 22 bugs, some of which had
interdependencies, would have been incredibly annoying for both of us.

You asked me very soon after I made the first upload, and I was happy to
send you the diff with the patches accumulated to date.  You would have
received it before long anyway -- a few hours later.

> > His AM had already mentioned quite a few to him back in February.
> Yes. The ones relating to static linking I have already solved for a
> long time.

No, you have not.  Your last upload to Debian was almost a year ago, and
did not solve that.

As long as you did not upload a fix to Debian, it is not fixed as far as
Debian is concerned.  A fix in some off-Debian source tree somewhere
does nothing to get Bacula in etch, and more importantly, does nothing
to make it work for Debian users.  Your fix also didn't work.

> The ones related to PgSQL... still didn't have the knowledge nor the
> time needed

That is irrelevant.  It is your responsibility.  If you don't have the
capability to maintain the package for these reasons, you should have
orphaned it long ago.

> > I don't believe jltallon is yet suited to maintain a package of this 
> > complexity.
> >   
> Well... at least this means I am not completely incompetent as a
> maintainer...
> You have just conceded that this package is tremendously complex. Thanks.

I made no statement about the package being tremendously complex or not.
I, in fact, don't believe it is.  It's about moderate complexity.
Certainly nothing on the order of X, libc, kernels, TeX, etc.  

I also did not say that you are completely incompetant as a maintainer.

I just said that the complexity of *THIS* package seems to exceed your
*PRESENT* abilities as a maintainer.  (Notice the word "YET" above).

> (and, before you say it, I will:  just watch out for uploads in my name.
> This time I have the means )

I don't know what this is supposed to mean.

Re: multiarch status update

[Matt Taggart]

"Olaf van der Spek" writes...

> Does it also allow completely arbitrary combinations to be installed?

We're not sure of this implementation detail yet. But I think...

By default your system won't be multiarch, but the sysadmin can turn on 
combinations. The config file for doing this will have entries for known 
working combinations, but nothing will prevent you from adding your own 
combination (because maybe you are developing support for that combination).

> Does it also allow multiple versions of the same package to be
> installed at the same time?
> For example, multiple minor versions or multiple major versions?

Read the papers listed in the wiki. The short answer is no, same as it is 
today with single-arch. As explained in the papers, trying to do anything else 
results in a complex dependency nightmare.

-- 
Matt Taggart
[EMAIL PROTECTED]



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

Re: Getting rid of circular dependencies, stage 4

[Hubert Chan]

On Wed, 10 May 2006 14:24:58 -0400, James Vega <[EMAIL PROTECTED]> said:

> On Wed, May 10, 2006 at 01:41:56PM -0400, Hubert Chan wrote:
>> alsaplayer-common contains the main alsaplayer binary
>> (/usr/bin/alsaplayer), which does not function without an
>> alsaplayer-output and alsaplayer-input plugin.  So yes, it really
>> does depend on these.  (I would have named alsaplayer-common
>> something different -- maybe alsaplayer-bin, or just alsaplayer, but
>> that was what it was called when I inherited it.)

> Ah, yes, I didn't take a look at the packages as well as I should
> have.  Taking a look at the package contents, it seems like changing
> the alsaplayer-(output|input) variants to Recommending
> alsaplayer-common would work fine.

Ah, looking at the changlogs, those dependencies were added because of
Bug #185814 -- alsaplayer-common only works with alsaplayer plugins from
the same version.  Ugh.  Yeah, I'll try to figure out how to fix this
properly.

-- 
Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA   (Key available at wwwkeys.pgp.net)
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


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

Re: Intent to hijack Bacula

[José Luis Tallón]

Marco d'Itri wrote:
> On May 10, Wouter Verhelst <[EMAIL PROTECTED]> wrote:
>
>   
>> You should not go ahead and remove José from maintenance over his
>> objection if he offers you co-maintenance. Your reason for hijacking
>> bacula seems to have been that José was slacking, not anything personal
>> or some such. In that case, I can understand that you want to take over
>> so that the work gets done. But if José says "I'm more than willing to
>> let you help out, but I still want to work on it", then that should be
>> respected; this is how it's always done in Debian.
>> 
> Except that he is not a developer and so far has not showed the minimal
> competence required to maintain a package, nor attempts to improve his
> procedures.
>   
Thank you, Marco.

Personal issues are better left outside this discussion.


J.L.



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

Re: exp. lightspeed disappeared

[Steinar H. Gunderson]

On Wed, May 10, 2006 at 09:37:48AM +0200, A Mennucc wrote:
> I uploaded an experimental version of 'lightspeed', as you see in
> http://packages.qa.debian.org/l/lightspeed/news/20060507T214839Z.html
> on Sun 7th of May ; but strangely enough it does not appear, neither in
> http://packages.qa.debian.org/l/lightspeed.html
> nor in
> http://packages.debian.org/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=lightspeed

It appears in madison:

  [EMAIL PROTECTED]:~$ madison lightspeed
  lightspeed |  1.2-2 | oldstable | source, alpha, arm, hppa, i386, 
ia64, m68k, mips, mipsel, powerpc, s390, sparc
  lightspeed |  1.2-5 |stable | source, alpha, arm, hppa, i386, 
ia64, m68k, mips, mipsel, powerpc, s390, sparc
  lightspeed |  1.2-5 |   testing | source, alpha, arm, hppa, i386, 
ia64, m68k, mips, mipsel, powerpc, s390, sparc
  lightspeed |  1.2-5 |  unstable | source, alpha, amd64, arm, hppa, 
hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
  lightspeed | 1.2a-3 |  experimental | source, i386, sparc

It also seems to appear in the two URLs you paste. Perhaps it fixed itself? :-)

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


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

Bug#366747: ITP: mp3val -- A program for MPEG audio stream validation

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi <[EMAIL PROTECTED]>

* Package name: mp3val
  Version : 0.1.4
  Upstream Author : [EMAIL PROTECTED]
* URL : http://mp3val.sourceforge.net/
* License : GPL
  Description : A program for MPEG audio stream validation

 MP3val is  a small, high-speed  tool for MPEG audio  files validation
 and (optionally) fixing problems.
 .
 It was primarily designed for  verification of MPEG 1 Layer III (MP3)
 files, but supports also other MPEG versions and layers.
 .
 It  can be  useful  for finding  corrupted  files (e.g.  incompletely
 downloaded)
 .
  Homepage: http://mp3val.sourceforge.net/

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686-smp
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: Getting rid of circular dependencies, stage 4

[Bill Allombert]

On Wed, May 10, 2006 at 01:41:56PM -0400, Hubert Chan wrote:
> On Wed, 10 May 2006 09:04:14 -0400, James Vega <[EMAIL PROTECTED]> said:
> 
> > On Wed, May 10, 2006 at 12:32:53AM -0400, Hubert Chan wrote:
> >> Hmm...  alsaplayer-common Depends: on "alsaplayer-alsa |
> >> alsaplayer-output" and "alsaplayer-gtk | alsaplayer-interface".  Is
> >> this really a problem?
> 
> My question, which I guess wasn't clear, was whether the circular
> dependency is still a problem if one of the dependencies in the cycle is
> an or'ed dependency.

Yes it is. Consider the following set of packages:
A -> B|C
B -> A
C -> nothing

1) A user can request A and B to be installed. This fulfill the
dependency. requirement. However dpkg cannot configure A before B and B
before A.

2) Such user upgrade to Etch. dpkg must upgrade A and B. It will not
replace B by C to remove the cycle and it still cannot configure A
before B and B before A.

So the problem exist as soon as there exists a choice of the
alternatives that lead to a circular dependency.

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: multiarch status update

[Olaf van der Spek]

On 5/10/06, Matt Taggart <[EMAIL PROTECTED]> wrote:

> Does it also allow multiple versions of the same package to be
> installed at the same time?
> For example, multiple minor versions or multiple major versions?

Read the papers listed in the wiki. The short answer is no, same as it is
today with single-arch. As explained in the papers, trying to do anything else
results in a complex dependency nightmare.


That's a shame, as I think a lot of the infrastructure required for
multiple architectures overlaps with that required for multiple
versions.

Re: PDF files and dh_compress

[Yaroslav Halchenko]

> On 5/9/06, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote:
> >* dh_compress doesn't compress some other files based on extension
> > including .zip files. PDF (to my knowledge) uses zip internally to
> > compress the document. So why PDF should be gzipped if .zip not?
> Probably because .zip is compressed better already than .pdf?
Indeed they are doing better:

itanix:/usr# find /usr  -iname *.zip | while read fname; do 
nfname=${fname//\//_};  gzip -9 -c "$fname" >| "/var/tmp/zips/${nfname}.gz"; 
done
itanix:/usr# du -sh /var/tmp/zips
51M /var/tmp/zips

itanix:/usr# find /usr  -iname *.zip | xargs du -ch
54M total

> >* Although there is  a way to view pdf.gz without explicit decompression
> > (use see or xzpdf) it is inconvenient for being used from firefox for
> > instance (?)
> What about improving transparent decompression somehow?
well... unification via mailcap is nice, but as I mentioned before it
would be trickier to make it work from firefox (it assumes all .gz files
to be gzip archives right of the box), and would require each
application tuning to make it handle pdf.gz, or may be pdf.bz2...

besides that such unification would forbid my own choice... now
for quick viewing I prefer to use xpdf, for some long read I would like
to use acroread... 

Sure we could create some wrapper to make it work like
zview acroread *.pdf.gz

but I am not sure if it is really worth it.

As I have shown, uncompressed PDFs of the whole sid would sacrifice just
150M of space which is miniscular... and on old boxes
(routers/gateways) you wouldn't want to install all -doc packages in any
case (which should contain most of pdf files)

Additional tuning of pdfs with pdftk might help... quick test on a
locally installed box (so just with a subset of pdfs):

83M pdfs.orig  -- original pdf and pdf.gz found on the system
106Mpdfs   -- gunzipped pdf.gz and original pdfs
474Mpdfs.unc   -- uncompressed with pdftk
102Mpdfs.compress  -- compressed back with pdftk
101Mpdfs.best  -- the best between pdfs and pdfs.compress

if we gzip -9 original .pdf 
76M pdfs.gz

So there is sense in invoking pdftk just to compress possibly terrible
(with uncompressed streams) PDF files

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




pgp4a1LhLOkGQ.pgp
Description: PGP signature

gcc 4.1 or not

[Andreas Barth]

Hi,

there were some requests, e.g. by Martin Michlmayr to the release team
whether we could switch gcc to 4.1 or not for etch.  As we're heading to
freeze etch rather soon and also the RC bug count doesn't look too good,
and we want to be on time this time :), we think the switch to gcc 4.1
as default should only be made if not more than 20 packages become RC
buggy by it.  Also, the switch should happen latest 1.5 months prior to
freeze, that is Jun 15th.

The RC bug NMU policy also applies to such bugs, but please be
aware: Do not upload package until you make sure you don't break
anything. Please check also that you're not just disturbing a transition
(e.g. don't NMU packages in sid the day before they go to testing :).

Questions should go to debian-release also (though of course I read d-d
also :).


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


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

Re: multiarch status update

[Martijn van Oosterhout]

On 5/10/06, Olaf van der Spek <[EMAIL PROTECTED]> wrote:

On 5/10/06, Matt Taggart <[EMAIL PROTECTED]> wrote:
> > Does it also allow multiple versions of the same package to be
> > installed at the same time?
> > For example, multiple minor versions or multiple major versions?
>
> Read the papers listed in the wiki. The short answer is no, same as it is
> today with single-arch. As explained in the papers, trying to do anything else
> results in a complex dependency nightmare.

That's a shame, as I think a lot of the infrastructure required for
multiple architectures overlaps with that required for multiple
versions.


You've been able to install multiple versions of the same package for
a long time, just we give each package a new name. Libraries are the
obvious example but you can install multiple versions of postgresql
simultaneously. It's not rocket science, just most people don't
consider it worth the effort.

In any case, I don't think any of this is going to handle multiple
architechtures simultaneously magically. It's more like each arch get
given a namespace and everything is carefully designed to stop the
namespaces conflicting. TANSTAAFL.
--
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

Re: PDF files and dh_compress

[Bill Allombert]

On Tue, May 09, 2006 at 01:15:54PM -0400, Yaroslav Halchenko wrote:
> Dear Developers,
> 
> I've raised this discussion at -mentors first [1] but I think it is worth
> asking on a devel list since no definite decision was reached and I
> could not find similar discussion in the archives.
> 
> I've got annoyed enough by compressed pdf.gz in -doc packages
> that I decided to check if that is required (deb pol, or dev ref?)
> and/org common practice.
> 
> The facts are:
> 
> * the policy states in 12.3 Additional documentation:
> 
>  *Text documentation* should be installed in the directory
>   /usr/share/doc/package, where package is the name of the package, and
>compressed with gzip -9 unless it is small.
>  
>  My take on that is that "text documentation" referred to uncompressed
>  text files which definitely should be compressed. But PDF can be
>  referred as text documentation with the same success as png with text
>  in it.
>  
> * Although there is  a way to view pdf.gz without explicit decompression
>   (use see or xzpdf) it is inconvenient for being used from firefox for
>   instance (?)

Could you point us to a bug report ? firefox being a web browser is likely
to be used to download .pdf.gz files from non-Debian source, so changing
Debian practice will not remove the need for that support.

> * There is no general agreement of either PDF should be gzipped or not.
>   There are 1250 pdf and 1068 pdf.gz file shipped with sid distribution
>   (please see [2] for more details). Possible reasons for present
>   disagreement is due to the lack of clear statement in the policy
>   or in dev reference or best practices. Also I believe neither lintian
>   nor linda warns about present pdf or pdf.gz files

I would not mind letting the maintainer decide whether compressing the
PDF in the package will achieve a significant saving (policy 12.3 says:
... unless it is small), whether the package work with compressed PDF
etc.

> * If we decide to allow pdf being installed uncompressed (which would be
>   my wish) we would occupy additional 153M to current 299M (see [2]) on
>   all of them on a sid system. If we rule opposite -- to keep them all
>   in .gz, then we would free up 50M.

Is that correct ?

Total uncompressed PDF: 299M+153M=452M
Total   compressed PDF: 299M-50M =244M
Compression ratio: (452-244)/452= 46%

A stat I would like to see is the compression ratio for the 
PDF that are shipped compressed compared to the compression ratio for the 
PDF that are shipped uncompressed.


> Now the questions are:
> 
> * Should we enforce the single way (pdf vs pdf.gz), or keep as it is now
>   without any agreement and up to the maintainer?

46% is sufficient for making compression worthwhile in my opinion.
However I prefer to rely on the judgement of the maintainer than to
force one way on the other.

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: Emacs out for lunch?

[Steve Langasek]

On Wed, May 10, 2006 at 08:18:56PM +0200, Kurt Petersen wrote:
> Kurt Petersen wrote:
> > I was the happy user of Emacs on Debian unstable. After a normal 
> >   apt-get update; apt-get dist-upgrade
> > Emacs disappeared and has not been seen later. I'm I the only one to
> > miss it?

> > Could this be the reason:

> > # apt-get install  emacs21-nox
> > [...]
> > The following packages have unmet dependencies:
> >   emacs21-nox: Depends: emacs21-bin-common (= 21.4a-3) but it is not going 
> > to be installed
> > E: Broken packages

> It still does not work... 

> Hasn't this package been tested in "testing"? It is about two weeks
> now that it stopped working. 

This broken package is only in unstable.  If you want testing, configure
your machine to look at testing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: PDF files and dh_compress

[Olaf van der Spek]

On 5/10/06, Yaroslav Halchenko <[EMAIL PROTECTED]> wrote:

> What about improving transparent decompression somehow?
well... unification via mailcap is nice, but as I mentioned before it
would be trickier to make it work from firefox (it assumes all .gz files


Good solutions aren't always trivial. :)


to be gzip archives right of the box), and would require each
application tuning to make it handle pdf.gz, or may be pdf.bz2...


Ideally those applications shouldn't have to know about specific
encoding schemes but should be able to offload decoding to a library.


besides that such unification would forbid my own choice... now


Why would that be?


for quick viewing I prefer to use xpdf, for some long read I would like
to use acroread...

Sure we could create some wrapper to make it work like
zview acroread *.pdf.gz

but I am not sure if it is really worth it.

As I have shown, uncompressed PDFs of the whole sid would sacrifice just
150M of space which is miniscular... and on old boxes


It still sounds like very wasted space.

Bug#366780: ITP: summain -- compute and verify file checksums

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius <[EMAIL PROTECTED]>

* Package name: summain
  Version : 1.0
  Upstream Author : Lars Wirzenius <[EMAIL PROTECTED]>
* URL : http://liw.iki.fi/liw/summain/
* License : GPL
  Programming Lang: Python
  Description : compute and verify file checksums

 A checksum is a number that identifies the contents of a file: if the
 contents change, so does the checksum. If you create a checksum before
 you burn a CD, when you know the files are correct, you can easily
 check the CD at any time: just compute the checksum again and see if
 they have changed.
 .
 summain computes and checks files against such checksums. It supports
 both MD5 and SHA-1 checksums, using formats compatible with the md5sum
 and sha1sum utilities, both for reading and writing. In addition, it
 can read and verify checksums from Debian .dsc, .changes, and Sources
 files.

(This ITP is for a program not quite released yet. I hope to get some
feedback on the description. The release and package upload to NEW will
happen once Debcamp6 Internet access gets more usable, or when I return
home.)

-- 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.15-1-686
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)


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

Re: PDF files and dh_compress

[Yaroslav Halchenko]

> > * Although there is  a way to view pdf.gz without explicit decompression
> >   (use see or xzpdf) it is inconvenient for being used from firefox for
> >   instance (?)

> Could you point us to a bug report ? firefox being a web browser is likely
> to be used to download .pdf.gz files from non-Debian source, so changing
> Debian practice will not remove the need for that support.
I am not sure if there is a bugreport - I didn't check for it -- just
tried to open few pdf.gz before it annoyed me enough to think about
doing smth about it
Indeed it might be worth checking in depth for possibility to make it
work in firefox

> >   or in dev reference or best practices. Also I believe neither lintian
> >   nor linda warns about present pdf or pdf.gz files
> I would not mind letting the maintainer decide whether compressing the
> PDF in the package will achieve a significant saving (policy 12.3 says:
> ... unless it is small), whether the package work with compressed PDF
> etc.
Sure we can leave it up to a subjective decision of the maintainer.

> Is that correct ?
yeap
> Total uncompressed PDF: 299M+153M=452M
> Total   compressed PDF: 299M-50M =244M
> Compression ratio: (452-244)/452= 46%
> A stat I would like to see is the compression ratio for the 
> PDF that are shipped compressed compared to the compression ratio for the 
> PDF that are shipped uncompressed.
by compressed do mean gzipped or compressed internally?


> > Now the questions are:
> > * Should we enforce the single way (pdf vs pdf.gz), or keep as it is now
> >   without any agreement and up to the maintainer?
> 46% is sufficient for making compression worthwhile in my opinion.
on my box for those 83M of pdfs I also have 328M of html files... may be
we should ship tarballs of htmls, or may be ship them within cramfs
images? ;-) It is a bad comparison of cause but I think that the penalty
of uncompressed PDFs is much small comparred to the other factors. On
the other hand it makes their viewing much smoother/easier

Since not many DDs got interested, probably everything would get left at
the current stage ... I just would ship PDFs in my packages uncompressed
so people could easily read documentation whenever they intended to do
so by installing -doc packages
-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]




pgpsOw4gQo5Mf.pgp
Description: PGP signature

Bug#366786: ITP: python-nose -- test discovery and running for Python's unittest

[Gustavo Noronha Silva]

Package: wnpp
Severity: wishlist
Owner: Gustavo Noronha Silva <[EMAIL PROTECTED]>


* Package name: python-nose
  Version : 0.8.7
  Upstream Author : Jason Pellerin
* URL : http://somethingaboutorange.com/mrl/projects/nose/
* License : LGPL
  Programming Lang: Python
  Description : test discovery and running for Python's unittest

nose provides an alternate test discovery and running process for
unittest, one that is intended to mimic the behavior of py.test as
much as is reasonably possible without resorting to too much magic.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-686
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)


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

Re: gcc 4.1 or not

[Martin Wuertele]

* Andreas Barth <[EMAIL PROTECTED]> [2006-05-10 23:11]:

> there were some requests, e.g. by Martin Michlmayr to the release team
> whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> freeze etch rather soon and also the RC bug count doesn't look too good,
> and we want to be on time this time :), we think the switch to gcc 4.1
> as default should only be made if not more than 20 packages become RC
> buggy by it.  Also, the switch should happen latest 1.5 months prior to
> freeze, that is Jun 15th.
 
I'm in favour of gcc 4.1 as it would provide our etch users with a
fairly recent default gcc at the time of the release and avoids the
rumor that debian releases badly outdated stuff as well.

yours Martin
-- 
<[EMAIL PROTECTED]>  Debian GNU/Linux - The Universal Operating System
 i am about to sell the oldest disks in the world :d
 those 5 1/4 inch floppys moses saved the 10 command prompts on?


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

Re: gcc 4.1 or not

[Wouter Verhelst]

On Wed, May 10, 2006 at 11:10:48PM +0200, Andreas Barth wrote:
> Hi,
> 
> there were some requests, e.g. by Martin Michlmayr to the release team
> whether we could switch gcc to 4.1 or not for etch.  As we're heading to
> freeze etch rather soon and also the RC bug count doesn't look too good,
> and we want to be on time this time :), we think the switch to gcc 4.1
> as default should only be made if not more than 20 packages become RC
> buggy by it.  Also, the switch should happen latest 1.5 months prior to
> freeze, that is Jun 15th.

Additional data point: GCC 4.0 on m68k is mostly crap, and probably the
reason why we haven't been able to make it back as a release candidate
architecture yet.

GCC 4.1 fixes a _lot_ of the GCC 4.0 bugs on m68k, and we'd really,
_really_ love to see it become the default, at the very least on our
architecture. So, I guess that means we'll have to help out there,
doesn't it? ;-)

> The RC bug NMU policy also applies to such bugs, but please be
> aware: Do not upload package until you make sure you don't break
> anything. Please check also that you're not just disturbing a transition
> (e.g. don't NMU packages in sid the day before they go to testing :).
> 
> Questions should go to debian-release also (though of course I read d-d
> also :).

One: What's the easiest way to extract the list of gcc-4.1 related bugs
from the BTS?

-- 
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: gcc 4.1 or not

[Jurij Smakov]

On Wed, 10 May 2006, Andreas Barth wrote:


Hi,

there were some requests, e.g. by Martin Michlmayr to the release team
whether we could switch gcc to 4.1 or not for etch.  As we're heading to
freeze etch rather soon and also the RC bug count doesn't look too good,
and we want to be on time this time :), we think the switch to gcc 4.1
as default should only be made if not more than 20 packages become RC
buggy by it.  Also, the switch should happen latest 1.5 months prior to
freeze, that is Jun 15th.

The RC bug NMU policy also applies to such bugs, but please be
aware: Do not upload package until you make sure you don't break
anything. Please check also that you're not just disturbing a transition
(e.g. don't NMU packages in sid the day before they go to testing :).


I didn't hit this problem myself yet, but it has been mentioned on 
sparclinux list that 4.1 currently miscompiles the sparc kernel. It's, of 
course, not such a big deal, if 4.0 will still be present as a 
non-default.


Best regards,

Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/   KeyID: C99E03CC


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