Re: Best practices for cron jobs?

[Bas Zoetekouw]

Hi Duncan!

You wrote:

> Adding a sleep $[ $RANDOM % 60 ] is probably not a good idea as it will
> hold up all the other cronjobs that should be run.

What about making sure the spamassassin cron.daily job is the last one
to run (by calling it ZZspamassassin or so)?  It might even be worth it
to put the random wait in its own /etc/cron.daily/ZZ_randomwait, so that
other packages could also benefit from the same construction.

Regards,
Bas.
-- 
+--+
| Bas Zoetekouw  | Sweet day, so cool, so calm, so bright, |
|| The bridall of the earth and skie:  |
| [EMAIL PROTECTED]  | The dew shall weep thy fall tonight;|
+|For thou must die.   |
 +-+


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

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Tuesday 12 June 2007 19:57, Joey Hess wrote:
> I had generally assumed that most programmers were reaonsable and used
> powers of 2, but this thread is certianly changing my mind about *that*.

It's not that unreasonable. Humans generally count in base 10 - computers 
count in base 2.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgppaW9Zr6ibG.pgp
Description: PGP signature

Bug#428643: ITP: maven-ant-helper -- package helper scripts for building Maven components with ant

[Paul Cager]

Package: wnpp
Severity: wishlist
Owner: Paul Cager <[EMAIL PROTECTED]>

* Package name: maven-ant-helper
  Version : 1.0
  Upstream Author : Trygve Laugstøl <[EMAIL PROTECTED]>
* URL : http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper
* License : Apache
  Programming Lang: Java
  Description : package helper scripts for building Maven components with 
ant

 An environment that can be used to simplify the creation of Debian
 packages to support the Maven system. A "modello" ant task is
 also provided.
 .
  Homepage: http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper


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

Re: Two proposals for a better Lenny (testing related).

[Andreas Barth]

* Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]:
> On 12/06/07 at 22:23 +0200, Luk Claes wrote:
> > NO!
> > 
> > unstable is meant for packages that should be in the next stable release, 
> > as such only packages that are in the maintainer's opinion ready to migrate 
> > to testing should be uploaded to unstable.
> 
> Then shouldn't we have a more aggressive policy about removals from
> unstable, for packages that have failed to get into testing during the
> past n months ?

We have that policy, just nobody who does the QA-bits needed to make
that happen.


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


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

Re: Two proposals for a better Lenny (testing related).

[Gabor Gombas]

On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:

>  - Smooth passages are not always smooth (who had a working xorg after
> the upgrade for 7, please raise their hands)

AFAIR apart from having to edit a few config files it was quite painless
(I've upgraded when Xorg was still in experimental).

OTOH the current xserver-xorg-video-ati snapshot in experimental is not
suitable for everyday use (the crash in DPMS is a blocker for me) so I'd
be quite annoyed if it was uploaded to unstable; but being able to
easily test new versions to see if the bugs are still there is very
useful.

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: Two proposals for a better Lenny (testing related).

[Gabor Gombas]

On Tue, Jun 12, 2007 at 05:40:29PM -0300, Gustavo Franco wrote:

> I disagree, that's what we've with experimental today mainly due to
> the fact that there's just a few packages there. Consider everybody
> uploading every package for unstable instead.

Experimental can and does contain packages that are _known_ to be broken
and unusable. Uploading these to unstable would mean that no one would
test unstable any more (right now you can _decide_ if you want to risk
installing known-broken packages from experimental; removing
experimental also removes that choice).

And if no one tests unstable because it's just too broken, then bugs
will not be found before packages migrate to testing (the method of
migration, being manual or automatic does not matter here at ALL),
meaning the quality of testing would drop significantly.

I don't see that as an improvement...

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: Best practices for cron jobs?

[Gabor Gombas]

On Wed, Jun 13, 2007 at 12:28:09AM -0400, Duncan Findlay wrote:

> What can I do to satisfy those with and without anacron, and to avoid
> hammering the sa-update servers at a specific time?

Idea:

- Generate a random minute number in the postinst
- Set up an entry in cron.d that runs every hour at the above specified
  minute and calls a helper script that checks if the last invocation of
  sa-update was more than 23 hours ago (using a timestamp file) and if
  so calls sa-update

Gabor

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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Ter, 2007-06-12 às 17:03 -0700, Steve Langasek escreveu:
> On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
> > Ter, 2007-06-12 às 22:05 +0200, Frans Pop escreveu:
> > > Personally I think the current system is fine.
> 
> > just a note, as user:
> 
> > The current system is fine but:
> >  - priority from unstable should less than testing or stable ( as i
> > think - not for sure - happens nowadays). On experimental has less
> > priority.
> >  - There are no guaranties that testing is always working and stable.
> >  - there are no guaranties that testing is secure (please security team,
> > can you clarify this?)
> 
> You won't find a contractual guarantee from Debian about either of these
> things, for *any* of the Debian suites.

look ... i don't want guaranties ... you know what i mean ... want a
place where it says "testing HAS security support, we focus on having it
stable. I don't want  written contract ... i want a desktop user to
discard stable and use testing. For that debian needs do publicly advice
the use of testing in these cases ... and i mean for real.
> 
> There is a testing security team that addresses unembargoed security issues
> in testing.  Fixes for embargoed security issues are generally not prepared
> in advance for testing.  However, more people have access to work on the
> unembargoed security issues anyway (in the general case: anyone can upload
> to t-p-u), so it's not definite that stable is always more secure than
> testing.

So, maybe, have more strict upload rules? Or, on the other way,
maintainers can upload packages directly into testing (from t-p-u?).

> >  - There are no public, announced, snapshots from testing (so people can
> > download and install).
> 
> Other than the d-i betas?

yes ... for example, every 6 months ... all teams can organize to ship a
preview release of debian. Teams will know that day X at Y time  full
set of cd's will be built. so teams will have +/- stable packages in
testing and debian will have an automatic version.
d-i "per se" is not a debian release.

This will give users another view of debian.
For example, debian "lenny preview A" would be announced and people
would install it and test it. Otherwise, no one will use it.
> 
> >  - Testing simply moves too fast and the automatically passage process
> > between unstble and testing *DOES* break testing. For one example,
> > package "foo" requires package "bar<=0.3" but package "bar 0.4"
> > automatically passes to testing.
> 
> Um, no.  That does not happen automatically.  In rare cases it happens
> because the release team has overridden the installability check for a
> package, because maintainers have not coordinated their transitions in
> unstable and as a result something needs to be broken to ever get any of the
> packages updated because you can't get 300 maintainers to get their packages
> in a releasable state *and* leave them alone long enough to transition to
> testing as a group.

So please, don't do those "oh, let them pass" transitions ... they BREAK
stuff ... for real.
> 
> (... and this is why getting rid of experimental is a horrible idea.)

i think we cannot give up of experimental ... it's a place for ...
experimental packages and preview packages (samba 4, for example),
> 
> >  - Smooth passages are not always smooth (who had a working xorg after
> > the upgrade for 7, please raise their hands)
> 
> 
you lucky person.
> 
> :)
> 
> >  - kernel modules simply die, when the kernel is upgraded, but the
> > modules aren't ( people using non-free nvidia modules, raise their
> > hands; people using wifi modules raise their hands)
> 
> That's a problem of the packaging of those kernel modules, then, not a
> problem of testing per se; even if you track stable and therefore the
> problem only affects you once every two years, it's still a problem that
> should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686
> (oh look, this one already exists).

kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
time (they are not free, right?) ... kernel passes to testing ...
automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ...
after a reboot, my xorg server will not run... when it used to.

this is a simple upgrade ... because kernel packages are always NEW, the
kernel will pass because it has no reverse dependency problems in
testing.
And, just a note ... we are talking about testing, not stable.
> 
> > So ... automatically pass to testing ... is bad.
> 
> Invalid premise -> invalid conclusion.

it's not invalid ... it's valid by the reasons above.
> 
> > So ... more package tests are need (such as test reverse depends)
> 
> What do you mean?

i mean that the passage f packages from unstable to testing needs to be
more difficult. 
for example, if a package has, for example, important or serious bugs,
should not pass to testing,even if it has security issues ... because it
will break testing.

> 
> -- 
> Steve Langasek  

Re: Two proposals for a better Lenny (testing related).

[Gabor Gombas]

On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:

> kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
> time (they are not free, right?) ... kernel passes to testing ...
> automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ...
> after a reboot, my xorg server will not run... when it used to.

Then create an empty nvidia-module package that depends on the latest
nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH >> X.Y.Z.
Just because you're using non-free kernel modules does not mean that
everyone else _not_ using those modules should be penalized.

Or alternatively, just reboot with the old kernel just like you'd do
when you found out that any random driver you happen depend on stops
working in the new kernel version.

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: Two proposals for a better Lenny (testing related).

[Steve Langasek]

On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
> > > The current system is fine but:
> > >  - priority from unstable should less than testing or stable ( as i
> > > think - not for sure - happens nowadays). On experimental has less
> > > priority.
> > >  - There are no guaranties that testing is always working and stable.
> > >  - there are no guaranties that testing is secure (please security team,
> > > can you clarify this?)

> > You won't find a contractual guarantee from Debian about either of these
> > things, for *any* of the Debian suites.

> look ... i don't want guaranties ... you know what i mean ... want a
> place where it says "testing HAS security support, we focus on having it
> stable. I don't want  written contract ... i want a desktop user to
> discard stable and use testing. For that debian needs do publicly advice
> the use of testing in these cases ... and i mean for real.

You are never going to get a statement from the Debian project telling users
to use one suite or another (or at least, you shouldn't); the most we should
be doing is giving users a list of pros and cons for each suite and letting
them decide which fits their needs.  I'm all in favor of reducing the number
of decisions users have to make *in the software* :), but on something as
high-level as which distro/suite to use, misestimating a user's needs is the
kind of thing that will sour the user on Debian for a very long time.

> > There is a testing security team that addresses unembargoed security issues
> > in testing.  Fixes for embargoed security issues are generally not prepared
> > in advance for testing.  However, more people have access to work on the
> > unembargoed security issues anyway (in the general case: anyone can upload
> > to t-p-u), so it's not definite that stable is always more secure than
> > testing.

> So, maybe, have more strict upload rules? Or, on the other way,
> maintainers can upload packages directly into testing (from t-p-u?).

More strict upload rules for what?

> > >  - Testing simply moves too fast and the automatically passage process
> > > between unstble and testing *DOES* break testing. For one example,
> > > package "foo" requires package "bar<=0.3" but package "bar 0.4"
> > > automatically passes to testing.

> > Um, no.  That does not happen automatically.  In rare cases it happens
> > because the release team has overridden the installability check for a
> > package, because maintainers have not coordinated their transitions in
> > unstable and as a result something needs to be broken to ever get any of the
> > packages updated because you can't get 300 maintainers to get their packages
> > in a releasable state *and* leave them alone long enough to transition to
> > testing as a group.

> So please, don't do those "oh, let them pass" transitions ... they BREAK
> stuff ... for real.

What?

> > That's a problem of the packaging of those kernel modules, then, not a
> > problem of testing per se; even if you track stable and therefore the
> > problem only affects you once every two years, it's still a problem that
> > should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686
> > (oh look, this one already exists).

> kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
> time (they are not free, right?) ... kernel passes to testing ...

That doesn't happen.

> this is a simple upgrade ... because kernel packages are always NEW, the
> kernel will pass because it has no reverse dependency problems in
> testing.

False.

-- 
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/


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

Re: Reasonable maximum package size ?

[Gunnar Wolf]

Wouter Verhelst dijo [Sun, Jun 10, 2007 at 06:59:49PM +0100]:
> >   Honnestly, no, this is not true anymore nowadays. With a 500Gb sata
> > hard drive, you're able to have a full debian mirror (all archs). Such a
> > disk is around 100??? nowadays.
> 
> ... but it will break down in three months with the typical usage
> pattern of a public Debian mirror.

ftp.mx.debian.org has three desktop-class hard drives, which have
faithfully served for ~1.5 years. We recently had hardware failures,
but more related to the aging machine (a 450MHz Pentium II) than to
the disks - And yes, we are getting a new machine :)

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: Two proposals for a better Lenny (testing related).

[Gustavo Franco]

On 6/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote:

On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
> >* What do you mean by "switch unstable automatic nature to not
> >  automatic"

> In a few words, move the 'NotAutomatic: yes' from experimental to
> unstable and burn experimental.

So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to
unstable?


Today, no? In a new scenario where unstable isn't automatic? Yes.


Shall we try it and see whether all the release team quits in frustration
and disgust, making lenny's release cycle the longest ever?


FUD.

regards,
-- stratus
http://stratusandtheswirl.blogspot.com


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

Re: Using standardized SI prefixes

[Christof Krüger]

On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> shirish writes ("Using standardized SI prefixes"):
> >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> 
> Urgh, these things are ugly and an abomination.  We should avoid them.
> 
> Ian.
> 

I'd really like to hear some real arguments against SI prefixes, besides
being ugly or funny to pronounce or just because "it has always been
like that". Advantages of using SI prefixes has been mentioned in this
thread. Please tell me the disadvantages so there can actually be a
constructive discussion.

Christof Krüger

Re: Two proposals for a better Lenny (testing related).

[Marc 'HE' Brockschmidt]

"Gustavo Franco" <[EMAIL PROTECTED]> writes:
> On 6/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote:
>> On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
* What do you mean by "switch unstable automatic nature to not
  automatic"
>>> In a few words, move the 'NotAutomatic: yes' from experimental to
>>> unstable and burn experimental.
>> So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to
>> unstable?
> Today, no? In a new scenario where unstable isn't automatic? Yes.

That idea is so crappy that you should probably be hit over the head
with a stick. Each shlib-bumping upload of glibc to unstable means that
it needs to transition before all other r-deps can move to
testing. Uploading experimental glibcs that are far from ready to
unstable is the perfect way to get the release team to quit.

Marc
-- 
BOFH #287:
Telecommunications is downshifting.


pgpObT6G2RIwM.pgp
Description: PGP signature

Re: Two proposals for a better Lenny (testing related).

[Lucas Nussbaum]

On 13/06/07 at 11:19 +0200, Andreas Barth wrote:
> * Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]:
> > On 12/06/07 at 22:23 +0200, Luk Claes wrote:
> > > NO!
> > > 
> > > unstable is meant for packages that should be in the next stable release, 
> > > as such only packages that are in the maintainer's opinion ready to 
> > > migrate 
> > > to testing should be uploaded to unstable.
> > 
> > Then shouldn't we have a more aggressive policy about removals from
> > unstable, for packages that have failed to get into testing during the
> > past n months ?
> 
> We have that policy, just nobody who does the QA-bits needed to make
> that happen.

What would be those QA bits ?

It would be easy to get the list of packages that haven't reached
testing in the n months (and have been in debian for more than n months).

I could even work on that during debconf, but then, there's the problem
of knowing who has the authority to remove packages from unstable. Such
tasks don't get you a lot of karma points, so, if removals are not
requested by someone with authority (release team or ftpmaster), this
will probably result in a lot of flames.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Two proposals for a better Lenny (testing related).

[Steve Langasek]

On Wed, Jun 13, 2007 at 08:02:53AM -0300, Gustavo Franco wrote:
> On 6/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote:
> >On Tue, Jun 12, 2007 at 04:40:54PM -0300, Gustavo Franco wrote:
> >> >* What do you mean by "switch unstable automatic nature to not
> >> >  automatic"

> >> In a few words, move the 'NotAutomatic: yes' from experimental to
> >> unstable and burn experimental.

> >So in your opinion, the glibc maintainers should upload glibc 2.6-0exp2 to
> >unstable?

> Today, no? In a new scenario where unstable isn't automatic? Yes.

ITYM "in a scenario where we stop bothering to use britney for modular
transitions into testing because it no longer works, and we replace it
instead with a periodic forklift copy from unstable to testing with all bugs
and all installability problems caused by builds, and while we're at it
let's go back to causing it "frozen", HTH HAND.

> >Shall we try it and see whether all the release team quits in frustration
> >and disgust, making lenny's release cycle the longest ever?

> FUD.

My bad, let me try to eliminate the uncertainty: you're designing in a
vacuum, you haven't bothered to inform yourself how testing works and
therefore have failed to understand the consequences of your proposal in
spite of my efforts to hint you in the right direction, and it's a dumb
idea.

-- 
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/


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

Re: Two proposals for a better Lenny (testing related).

[Marc 'HE' Brockschmidt]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> On 13/06/07 at 11:19 +0200, Andreas Barth wrote:
>> * Lucas Nussbaum ([EMAIL PROTECTED]) [070612 23:17]:
>>> On 12/06/07 at 22:23 +0200, Luk Claes wrote:
 unstable is meant for packages that should be in the next stable release, 
 as such only packages that are in the maintainer's opinion ready to 
 migrate 
 to testing should be uploaded to unstable.
>>> Then shouldn't we have a more aggressive policy about removals from
>>> unstable, for packages that have failed to get into testing during the
>>> past n months ?
>> We have that policy, just nobody who does the QA-bits needed to make
>> that happen.
> What would be those QA bits ?

Automatic checks and reports.

> It would be easy to get the list of packages that haven't reached
> testing in the n months (and have been in debian for more than n months).

Yes. One would just need to do it (and decide some basic rules)...

> I could even work on that during debconf, but then, there's the problem
> of knowing who has the authority to remove packages from unstable. Such
> tasks don't get you a lot of karma points, so, if removals are not
> requested by someone with authority (release team or ftpmaster), this
> will probably result in a lot of flames.

I think that a package that has been in unstable for a whole release
cycle without entering testing should probably live in experimental or
not in Debian at all. I guess that is something most people can agree
on.

Marc
-- 
BOFH #337:
the butane lighter causes the pincushioning


pgpRPbtyZsE2b.pgp
Description: PGP signature

Re: Using standardized SI prefixes

[Caeles]

One more opinion:

If you consider a number more relevant than its nearest power of 2,
then somebody else will consider every digit of that number relevant.
In that case, don't use rounding by SI/IEC prefixes at all.
For an example see Bug #420716.

The first number, where the difference between base 1024 and base
1000 results in a greater inaccuracy than rounding to the next power
of 2, is 2^150 vs 10^45. According to the cited wikipedia article,
SI and IEC prefixes roughly go only half as far. So the difference
between SI and IEC prefixes is immaterial.


Regards,

  Mark Weyer


P.S.: I am not subscribed to the list


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

Re: Two proposals for a better Lenny (testing related).

[Adeodato Simó]

* Gustavo Franco [Mon, 11 Jun 2007 18:20:17 -0300]:

> * Switch unstable (release) for not automatic updates

This seems like the key of your proposal, and this is, in simple words
and AIUI, why it would not bring any improvements:

  - Our main objective is to have as few bugs in testing as possible,
since testing is what becomes stable.

  - Our current way to achieve that is by extensive testing of unstable;
as Joey Hess pointed out, most bug reports come from people using
unstable, and we use those bug reports to keep packages in bad shape
out of testing, and thus out of stable.

  - By swithing unstable to NotAutomatic, you expect to get more users
of testing instead, thus getting more people to test testing, and
find bugs *there*. Which is bad, because bugs are discovered *once
the packages have entered testing*, which is too late.

HTH,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
— As the ship lay in Boston Harbor, a party the colonists dressed as red
  Indians boarded the vessel, behaved very rudely, and threw all the tea
  overboard, making the tea unsuitable for drinking. Even for Americans. 
-- George W. Banks in “Mary Poppins”


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

Re: Using standardized SI prefixes

[Scott James Remnant]

On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:

> On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > shirish writes ("Using standardized SI prefixes"):
> > >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> > 
> > Urgh, these things are ugly and an abomination.  We should avoid them.
>  
> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.
> 
User Confusion.

Most users do not know what a "tebibyte" is, and they do not care.  They
know that "a terabyte" is "about a million million bytes", and that is
sufficient.

Since you're rounding anyway, the loss of accuracy between "about a
million million bytes" and "just over a million million bytes" is not
significant.  Certainly not at the expense at having to teach users
another new unit.

Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
Quoting the same figures with a different unit in the operating system
is pedantry for its own sake.

Users have already learnt that the term "gigabyte" is approximate.

Introducing new units has only added confusion, rather than removed it.

Before the new units, we all knew that 1GB was an approximate figure and
likely to be (for bytes) based on a power of 2.  Now we have figures
quoted in GB and GiB, some of which are power of 10, some of which are
power of 2.  Some figures quoted in GiB are wrong, and should be in GB;
likewise some in GB should be GiB.  And we still have many figures in
both GB and GiB which are neither of the two!

Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
or 1.44MiB.  One could name it the 1.4MB or 1.47MiB floppy and confuse
everyone into thinking it's a different thing, of course.  Or maybe it
should be the 1,440KB floppy, or the 1,475KiB floppy?  Neither of these
help the situation.

Without the binary unit to consider, when we quote a drive as 1TB, we
know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available.  It's actually more likely to have
something strange like 1,024,000,000,000 available.

(And none of this takes into account partitioning and filesystem
overhead!)

I see no problem with this "1TB" quote being approximate.  It's rounded
anyway.  If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change[0].

Scott

[0] Unless you're older than 25.
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


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

Re: Using standardized SI prefixes

[Bjørn Ingmar Berg]

On 13/06/07, Christof Krüger <[EMAIL PROTECTED]> wrote:

I'd really like to hear some real arguments against SI prefixes, besides
being ugly or funny to pronounce or just because "it has always been
like that". Advantages of using SI prefixes has been mentioned in this
thread. Please tell me the disadvantages so there can actually be a
constructive discussion.


So far in this discussion i honestly thought that the arguments
against SI prefixes were too obvious to bother mentioning.

Let me start with a dumb example:
For a child or uninterested commoner that flying critter is simply "a
birdie".  For those in the know exactly the same entity is a "Falco
peregrinus".
Even if simply calling it "birdie" or perhaps "falcon" would be
easier, more "user friendly" more "understandable for everyone" it
simply would not be /correct/.
Therefore it must stay "Falco peregrinus" in all contexts where really
conveying information matters.

Computers deal with numbers in base two.  Humans deal with numbers in
base 10.  When computers and humans interact (on a technical level)
humans must adapt to the computer, because computers can not.
Dealing with chunks of data, addresses, registers, etc. has to be done
in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
marketing humanoid, that will never make those two numbers equal.  And
it must never be allowed to.  Computers, computer designers, computer
technicians and most computer programmers will always deal with the
_real_ base 2 numbers like 1024.

Another example.  Pi is an irrational number starting with 3.14
Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
would be easier to remember and more marketable.  It would also be
totally useless AND completely wrong.  AFAIK some very dumb people
actually managed to decree by law that pi was to equal 3.  They had to
stop doing that.

In the same was as with pi redefining or "standardizing" kilobytes and
megabytes would be totally useless AND completely wrong.  Computers
have always, do, and will continue to deal with their numbers along
the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc...
So, when dealing with computers, must we.

One does not redefine "Falco peregrinus" to "birdie" because "that
would make it more understandable for the commoner".  Ornithologists
need it to stay "Falco peregrinus" in the future.
One does not redefine pi to a value of 3 because "that would make it
more understandable for the commoner".  Mathematicians, architects
(and basically everyone else) need it to stay ~3.1415926535 in the
future.
One does not redefine kilobyte to mean 1000 (base 10) because "that
would make it more understandable for the commoner".  Real computer
people need it to stay 1024 (base 10).

A well-known and very common trait of language is that one given word
can often have more than one specific meaning.  When this is the case
you need a context to be sure.  This is considered normal, and never a
real problem.  This should hold true regarding computers and counting
as well.

Finally a personal and subjective thought.  At times one has to chose
whether to oversimplify facts and information to the point where
"everyone" understands it, (If this happens they DO NOT understand it;
they are given the illusion of understanding) or whether to educate
the public.  I am very convinced the correct solution is always to
educate the public.  The world is not flat.  The earth is not the
center of the universe.  Pi is not 3.  A kilobyte is not 1000; it is
1024 because that is the way computers work.


Regards,
Bjørn Ingmar Berg

--

blog.bergcube.net/

Bug#428676: ITP: snowballz -- fun RTS game featuring snowball fights with penguins

[Miriam Ruiz]

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


* Package name: snowballz
  Version : 0.9.3
  Upstream Author : Joey Marshall <[EMAIL PROTECTED]>
  Upstream Author : Matthew Marshall <[EMAIL PROTECTED]>
* URL : http://joey101.net/snowballz/
* License : GPL
  Programming Lang: Python
  Description : fun RTS game featuring snowball fights with penguins

Take command of your army of penguins as you blaze your path to victory!

March through snow laden forests to conqueror new frontears and grow
your small army. Ambush enemy lines with blasts of freezing snowballs.
But don't neglect your home, invaders are just over the next snow drift!
 
Gather fish for your cold penguins to munch on as they warm up in your
cozy igloo.

It's a snowy world you don't want to miss!


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

Re: Using standardized SI prefixes

[Scott James Remnant]

On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote:

> 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
> less.
> 
No it doesn't.

The meaning of 1 TB depends on the context, and has always done so.

Scott
-- 
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


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

Re: Using standardized SI prefixes

[Alex Queiroz]

Hallo,

On 6/13/07, Scott James Remnant <[EMAIL PROTECTED]> wrote:


The meaning of 1 TB depends on the context, and has always done so.



Wrongly.

--
-alex
http://www.ventonegro.org/


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

Re: Two proposals for a better Lenny (testing related).

[Paul Wise]

On 6/13/07, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:


It would be easy to get the list of packages that haven't reached
testing in the n months (and have been in debian for more than n months).


Such a list exists:
http://bjorn.haxx.se/debian/oldest.html

--
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Using standardized SI prefixes

[Alex Jones]

On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:
> Without the binary unit to consider, when we quote a drive as 1TB, we
> know that it has *at least* 1,000,000,000,000 bytes available.
> Depending on the drive, it may have anywhere between this and
> 1,099,511,627,776 bytes available.  It's actually more likely to have
> something strange like 1,024,000,000,000 available.

10% error is no good for me. You can continue to play the "at least"
card, but what about when it's more important if it is "at most"
something? And seeing as this error only goes up exponentially, at which
prefix do you draw the line and say "no more"?

And no-one uses floppy disks any more. Let's just bury them all and
forget about them. :D

> I see no problem with this "1TB" quote being approximate.  It's rounded
> anyway.  If you really want to know how many bytes are available, you
> can use this great unit called the "byte" which is accurate and not
> subject to change[0].

1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
less. If they want to actually put 1.024 TB on the disk then they can
say 1 TB (approx.) like any other industry (detergent, bacon, etc.).
-- 
Alex Jones
http://alex.weej.com/

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Wednesday 13 June 2007 15:29, Scott James Remnant wrote:
> On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:
> > On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > [...] Please tell me the disadvantages so there can actually be a
> > constructive discussion.
>
> User Confusion.
>
> Most users do not know what a "tebibyte" is, and they do not care.  They
> know that "a terabyte" is "about a million million bytes", and that is
> sufficient.
>
> Since you're rounding anyway, the loss of accuracy between "about a
> million million bytes" and "just over a million million bytes" is not
> significant.  Certainly not at the expense at having to teach users
> another new unit.

This is a hurdle to adoption, a one time cost. It is not an argument against 
IEC prefixes per se. The long-term benefits outweigh the costs, IMO.

> Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
> Quoting the same figures with a different unit in the operating system
> is pedantry for its own sake.
>
> Users have already learnt that the term "gigabyte" is approximate.

No, it's not. It's ambiguous. A given number can be exact or approximate 
regardless of the unit. "1.0 GB" can mean either 1.0·10^9 byte or 1.0·2^30 
byte, but whether the real value is exactly one or the other or something 
near one or the  

> Introducing new units has only added confusion, rather than removed it.

New concepts can always cause initial confusion. Relearning is harder than 
learning something right from the beginning. The same argument has been used 
against metrication in the US. Again, it's a one-time cost.

> Before the new units, we all knew that 1GB was an approximate figure and
> likely to be (for bytes) based on a power of 2.  Now we have figures
> quoted in GB and GiB, some of which are power of 10, some of which are
> power of 2.  Some figures quoted in GiB are wrong, and should be in GB;
> likewise some in GB should be GiB.  And we still have many figures in
> both GB and GiB which are neither of the two!

You're talking a lot about approximation. If I understand you correctly, 
you're saying that any stated quantity of data must either be an exact 
number, e.g. 23 368 986 120 bytes, or an approximation with a single 
significant digit. That is *stupid*. You want to deny people the 
*possibility* of consistence, unambiguity and accuracy (without resorting to 
numbers on the form "3.1·10¹²"), just because you won't think that you'll 
need that possibility most of the time.

There *is* reason to state rounded numbers with two or three digits, in which 
case the difference between MB and MiB or GB and GiB definitely matters, and 
even with a single significant digit, 8 GiB (exactly) is 9 GB when rounded to 
the nearest whole number.

> Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
> or 1.44MiB.  One could name it the 1.4MB or 1.47MiB floppy and confuse
> everyone into thinking it's a different thing, of course.  Or maybe it
> should be the 1,440KB floppy, or the 1,475KiB floppy?  Neither of these
> help the situation.

The 1 440 KiB floppy is dead. Let it rest in pieces. The fact that a marketing 
department screwed up long ago by thinking that 1 440 kB equals 1.44 MB, 
which it would have done, had that really *been* 1 440 kB and not 1 440 KiB, 
is not a case against IEC prefixes. On the contrary, it may well be a prime 
example of a confusion that wouldn't have happened if the IEC prefixes had 
been adopted by then.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpQnKqXRd0XO.pgp
Description: PGP signature

Re: Getting package translations into the mirrors (was Re: APT 0.7 for sid)

[Michael Bramer]

On Sun, Jun 10, 2007 at 07:16:49PM +0200, Martijn van Oosterhout wrote:
> On 6/10/07, Frank Küster <[EMAIL PROTECTED]> wrote:
> >> That's because they're not the latest files. The latest output form
> >> the DDTP project is here:
> >> http://ddtp.debian.net/debian/dists/sid/main/i18n/
> >>
> >> There have been requests to have the FTP site mirror from there or
> >> have some other mechanism to get the data to the main servers. As far
> >> as I know it needs an FTP master to fix. I understand the reason for
> >> it not having been done earlier was lack of support in apt?
> >
> >Have you submitted a bug against ftp.d.o?  I couldn't find one.
> 
> I havn't because I didn't think it was my problem. But I found it here:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=109955
> 
> It's six years old, the URLs have changed but thats it. I came to this
> rather late so I don't know the story. Just google for apt-i18n brings
> up some stuff. There's this:
> 
> http://lists.debian.org/debian-i18n/2006/06/msg00107.html
> http://lists.debian.org/debian-devel-announce/2006/06/msg3.html
> 
> When I last asked about it I was told to wait, so I've done nothing.
> I've CCed grisu, perhaps he knows what's going on...

Thanks for the info.

I close the bug. 

The files are already on the ftp master (see
ftp://ftp.debian.org/debian/dists/unstable/main/i18n/) as translation
files.

Gruss
Grisu
-- 
Michael Bramer  - a Debian Linux Developer  http://www.debsupport.de
PGP: finger [EMAIL PROTECTED]  -- Linux Sysadmin   -- Use Debian Linux
"Ziemlich viele Firmen, die alle kein Linux benutzen, würden nach Abschaltung
 der Linux-Rechner erst mal ins Schwimmen kommen." -- Matthias Peick


pgpTY1wj54j1F.pgp
Description: PGP signature

Re: Two proposals for a better Lenny (testing related).

[Lucas Nussbaum]

On 13/06/07 at 15:19 +0100, Paul Wise wrote:
> On 6/13/07, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
> 
> >It would be easy to get the list of packages that haven't reached
> >testing in the n months (and have been in debian for more than n months).
> 
> Such a list exists:
> http://bjorn.haxx.se/debian/oldest.html
 
Yes, but there's a bug. Let's take eglade as an example. The list says
1341 days.

Actually, it is 1341 days since that package last entered testing. But
it was in testing on 2006-11-20 (it was removed from testing on
2006-11-21). Which is much shorter than 1341 days, and also more
acceptable.

The correct fix for this would probably be to analyze the Sources files
on snapshot.d.n...
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: Two proposals for a better Lenny (testing related).

[Marc 'HE' Brockschmidt]

Lucas Nussbaum <[EMAIL PROTECTED]> writes:
> On 13/06/07 at 15:19 +0100, Paul Wise wrote:
>> On 6/13/07, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
>> >It would be easy to get the list of packages that haven't reached
>> >testing in the n months (and have been in debian for more than n months).
>> Such a list exists:
>> http://bjorn.haxx.se/debian/oldest.html
> Yes, but there's a bug. Let's take eglade as an example. The list says
> 1341 days.
>
> Actually, it is 1341 days since that package last entered testing. But
> it was in testing on 2006-11-20 (it was removed from testing on
> 2006-11-21). Which is much shorter than 1341 days, and also more
> acceptable.

Yeah, but I guess you need to ignore that day anyway, because I seem to
remember that this was a britney problem that marked all packages as
rc-bug-free or something.

Marc
-- 
Fachbegriffe der Informatik - Einfach erklärt
134: Benutzerfreundlichkeit
   Der Benutzer hat zum Admin freundlich zu sein. (Thorsten Fenk)


pgpuPk4XvlAdY.pgp
Description: PGP signature

Re: Using standardized SI prefixes

[shirish]

On Wed, 2007-06-13 at 12:51 +0200, Christof Krüger wrote:

> On Tue, 2007-06-12 at 15:52 +0100, Ian Jackson wrote:
> > shirish writes ("Using standardized SI prefixes"):
> > >   Please look at http://en.wikipedia.org/wiki/Binary_prefix .
> >
> > Urgh, these things are ugly and an abomination.  We should avoid them.
>
> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.
>
User Confusion.

Most users do not know what a "tebibyte" is, and they do not care.  They
know that "a terabyte" is "about a million million bytes", and that is
sufficient.

Since you're rounding anyway, the loss of accuracy between "about a
million million bytes" and "just over a million million bytes" is not
significant.  Certainly not at the expense at having to teach users
another new unit.

Hard drives are bought in gigabytes, memory is bought in gigabytes, etc.
Quoting the same figures with a different unit in the operating system
is pedantry for its own sake.

Users have already learnt that the term "gigabyte" is approximate.


Wrong most users think of "gigabyte" as absolute rather than
approximation. If that was not the case then
http://en.wikipedia.org/wiki/Binary_prefix#Legal_disputes wouldn't
have happened. Most of the users when they burn a CD/DVD use the
approximation "GB" to say a burn a movie DVD. Most of the DVD media is
marketted as 4.78 GB while its 4.38 "GiB" & hence when they download a
movie (legally downloaded or otherwise) or do mixed mode stuff. Also I
don't know many users who go down to byte-size level & see how much
space is remaining. I do get support calls over this quite a bit.
Thinking that users know its an approximate IMHO is an
oversimplification.


Introducing new units has only added confusion, rather than removed it.


The same could be said of relatively newer concepts like free
software, open source, copyright, creative licenses, .PNG, .SVG & all
the newer stuff that the web keeps pouring in. Micro formats anyone.
That doesn't mean we stop learning, it just means we adjust ourselves
to the new reality.


Before the new units, we all knew that 1GB was an approximate figure and
likely to be (for bytes) based on a power of 2.  Now we have figures
quoted in GB and GiB, some of which are power of 10, some of which are
power of 2.  Some figures quoted in GiB are wrong, and should be in GB;
likewise some in GB should be GiB.  And we still have many figures in
both GB and GiB which are neither of the two!

Renaming the 1.44MB floppy helps in neither case; it is neither 1.44MB
or 1.44MiB.  One could name it the 1.4MB or 1.47MiB floppy and confuse
everyone into thinking it's a different thing, of course.  Or maybe it
should be the 1,440KB floppy, or the 1,475KiB floppy?  Neither of these
help the situation.


 Right, although it doesn't completely solve the situation it does
take things to a nearer perfect answer. I do see that it would take
time for us to make that change but its a better change IMO.

> Without the binary unit to consider, when we quote a drive as 1TB, we

know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available.  It's actually more likely to have
something strange like 1,024,000,000,000 available.

(And none of this takes into account partitioning and filesystem
overhead!)

I see no problem with this "1TB" quote being approximate.  It's rounded
anyway.  If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change[0].


   Do you think most common users are ever going to go down to byte size
level to see if things fit or not. It would actually be a good test
for Novell . I believe they do  desktop tests for HIG & see how users
actually do stuff. Not techies but
day-to-day the Johns & Janes.

Scott

[0] Unless you're older than 25.
--
Scott James Remnant
Ubuntu Development Manager
[EMAIL PROTECTED]


Cheers

--
 Shirish Agarwal
 This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17

Re: Using standardized SI prefixes

[Darren Salt]

I demand that Alex Jones may or may not have written...

> And no-one uses floppy disks any more. Let's just bury them all and forget
> about them. :D

I used one yesterday to do a BIOS upgrade. :-)

> 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
> less.

It means 1024^4 bytes, no more and no less. :-þ

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   http://www.youmustbejoking.demon.co.uk/progs.packages.html>

We'll get along fine as soon as you realise that I'm God!

Re: Using standardized SI prefixes

[Magnus Holmgren]

On Wednesday 13 June 2007 15:19, Bjørn Ingmar Berg wrote:
> Let me start with a dumb example:
(OK, dumb example duly deleted)

> Computers deal with numbers in base two.  Humans deal with numbers in
> base 10.  When computers and humans interact (on a technical level)
> humans must adapt to the computer, because computers can not.

I don't agree with that. Compilers generally understand numbers in base 10, 
for example. More about that later.

> Dealing with chunks of data, addresses, registers, etc. has to be done
> in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
> marketing humanoid, that will never make those two numbers equal.  And
> it must never be allowed to.  Computers, computer designers, computer
> technicians and most computer programmers will always deal with the
> _real_ base 2 numbers like 1024.

So? This is why there needs to be a separate set of prefixes for powers of 2. 
As for that falcon, it's just another example of why there needs to be a 
well-defined vocabulary even if the common people don't care about the 
details.

> Another example.  Pi is an irrational number starting with 3.14
> Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
> would be easier to remember and more marketable.  It would also be
> totally useless AND completely wrong.  AFAIK some very dumb people
> actually managed to decree by law that pi was to equal 3.  They had to
> stop doing that.
>
> In the same was as with pi redefining or "standardizing" kilobytes and
> megabytes would be totally useless AND completely wrong.  Computers
> have always, do, and will continue to deal with their numbers along
> the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc...
> So, when dealing with computers, must we.

Again, computers are perfectly capable of presenting numbers in base ten or 
any other base, depending on what is most convenient. Otherwise we might have 
been forced to input numbers in binary and get answers like "Total distance: 
10011.1 km" back (with k meaning 2^10, of course). That SI prefixes have been 
used to express powers of two is more specifically an artifact of memory 
addressing. The sizes of memory banks are normally a power of two. In that 
case it's convenient to say that the memory capacity is 64 MiB when you mean 
that it's 67 108 864 byte. But for data on a wire, or even files on a disk, 
there isn't anything constraining sizes to a power of two (block sizes are a 
number of KiB, but you rarely need to think of that as a user).

> One does not redefine pi to a value of 3 because "that would make it
> more understandable for the commoner".  Mathematicians, architects
> (and basically everyone else) need it to stay ~3.1415926535 in the
> future.
> One does not redefine kilobyte to mean 1000 (base 10) because "that
> would make it more understandable for the commoner".  Real computer
> people need it to stay 1024 (base 10).

It's not about redefining "kilobyte to mean 1000", because, as has been 
pointed out repeatedly, a kilobyte is currently either 1000 byte or 1024 byte 
depending on context. There is no exact definition, just a rather vague 
convention. This is about once and for all ending that mess.

Your analogy with redefining pi as exactly 3 is way off, because pi is a 
natural constant and as such has been defined since the beginning of time. 
Redefining pi would be like trying to alter the shape of the universe or the 
laws of nature. Deciding that SI prefixes shall be SI prefixes even in 
computer context is not like trying to strip 24 bytes off every block of 
1024, or mandating that computers always have to use BCD internally.

> A well-known and very common trait of language is that one given word
> can often have more than one specific meaning.  When this is the case
> you need a context to be sure.  This is considered normal, and never a
> real problem.  This should hold true regarding computers and counting
> as well.

That doesn't make vagueness and ambiguity *desirable*. It is common to have a 
well-defined terminology wherever people need to communicate efficiently 
without misunderstandings. Two examples are the SI units and prefixes.

> Finally a personal and subjective thought.  At times one has to chose
> whether to oversimplify facts and information to the point where
> "everyone" understands it, (If this happens they DO NOT understand it;
> they are given the illusion of understanding) or whether to educate
> the public.  I am very convinced the correct solution is always to
> educate the public.

Good. Let's then teach the public that "borrowing" well-defined SI prefixes 
and giving them a different meaning in some situations was a bad idea, and 
that an adequate solution exists.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgp3oIOldbVpg.pgp
Description: PGP signature

How to package software with binaries in tarball?

[Sergei Golovan]

Hi!

What is a recommended practice of packaging programs, for which
distributed tarball contains binaries (generated from the sources)?

Specifically, newly released erlang distribution includes prebuilt
architecture-independent binary files.

Should we remove them from the original tarball, or is it better to leave them?

Best wishes!
--
Sergei Golovan


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

Re: How to package software with binaries in tarball?

[Andreas Metzler]

Sergei Golovan <[EMAIL PROTECTED]> wrote:
> What is a recommended practice of packaging programs, for which
> distributed tarball contains binaries (generated from the sources)?

> Specifically, newly released erlang distribution includes prebuilt
> architecture-independent binary files.

> Should we remove them from the original tarball, or is it better to leave 
> them?

Unless there is a huge a gain in tarball size I would keep the
pristine source. It is rather nice to be able take debian's tar.gz and
verify with md5sum or a detached gpg sig that upstream's tarball is
identical. OTOH if I needed to repackaged the source tarball anyway
since it contains non DFSG free material I would remove the binaries
too.
cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: How to package software with binaries in tarball?

[Sergei Golovan]

On 6/13/07, Andreas Metzler <[EMAIL PROTECTED]> wrote:

> Should we remove them from the original tarball, or is it better to leave 
them?

Unless there is a huge a gain in tarball size I would keep the


Tarball without binaries is about 11Mb, with binaries is about 37Mb.


pristine source. It is rather nice to be able take debian's tar.gz and
verify with md5sum or a detached gpg sig that upstream's tarball is


The original tarball contains non-free RFCs, so it is recreated anyway.


identical. OTOH if I needed to repackaged the source tarball anyway
since it contains non DFSG free material I would remove the binaries
too.


OK. I see your point. Thanks!
--
Sergei Golovan


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

Re: Using standardized SI prefixes

[Felipe Sateler]

Mike Hommey wrote:

> On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov
> <[EMAIL PROTECTED]> wrote:
>> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
>> 
>> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
>> 
>> =10^12 :)
>> 
>> and Germany, France, former UdSSR, 
> 
> Anywhere where milliard is 10^9, basically...

Which includes England, according to Merriam-Webster [1]. The Spanish Royal
Academy also defines[2] it as 10^12, which would mean every Spanish
speaking country uses that definition too.

[1] http://www.m-w.com/mw/table/number.htm
[2] http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=bill%F3n
-- 

  Felipe Sateler


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

Re: Using standardized SI prefixes

[Christof Krüger]

> Let me start with a dumb example:
> For a child or uninterested commoner that flying critter is simply "a
> birdie".  For those in the know exactly the same entity is a "Falco
> peregrinus".
> Even if simply calling it "birdie" or perhaps "falcon" would be
> easier, more "user friendly" more "understandable for everyone" it
> simply would not be /correct/.
The word birdie is a generalization of quite every critter that can fly.
So it is correct, the critter "Falco peregrinus" is a birdie, too.
Calling this critter "falco peregrinus" is correct, too. The example
just doesn't apply here because KB is not a generalization of KiB and
vice versa.

> 
> Computers deal with numbers in base two.  Humans deal with numbers in
> base 10.  When computers and humans interact (on a technical level)
> humans must adapt to the computer, because computers can not.
> Dealing with chunks of data, addresses, registers, etc. has to be done
> in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
> marketing humanoid, that will never make those two numbers equal.
Right, and this is the reason why having the same name for different
things is not good.

> And it must never be allowed to.  Computers, computer designers, computer
> technicians and most computer programmers will always deal with the
> _real_ base 2 numbers like 1024.
Unfortunately, computer designers, technicians etc. are not living in an
isolated world (well.. maybe some of them).
No one wants to forbid the computer people to use base 2 numbers. They
are just asked to write KiB instead of KB if they mean base 2
quantities, because the rest of the world already uses kilo as 1000.
Changing the rest of the world makes no sense and having distinct names
for distinct thing does no harm.


> Another example.  Pi is an irrational number starting with 3.14
> Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
> would be easier to remember and more marketable.  It would also be
> totally useless AND completely wrong.  AFAIK some very dumb people
> actually managed to decree by law that pi was to equal 3.  They had to
> stop doing that.
Well, another example that does not apply here. Nobody wants to change
something true to something wrong. The status quo is that KB can mean
either 1000 or 1024 bytes depending on the context (or shoe size of the
developer or whatever). So there is an ambiguity here. Introducing SI
prefixes would eliminate ambiguities if applied consistently. Pi is well
defined. There is no ambiguity.

> Computers
> have always, do, and will continue to deal with their numbers along
> the progression of 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc...
> So, when dealing with computers, must we.
Yup, I totally agree. But why do we call it "kilo" then, when we
actually mean 1024? Someone found it handy dozens of years ago and
everybody has adapted it. So back then, someone was redefining your pi
to 3 because it was close enough and now we should leave it this way?
Remember that until computers have been invented (or binary logic), kilo
has always meant 1000.

> A well-known and very common trait of language is that one given word
> can often have more than one specific meaning.  When this is the case
> you need a context to be sure.  This is considered normal, and never a
> real problem.  This should hold true regarding computers and counting
> as well.
This is called a homograph. An example taken from wikipedia:
shift n. (a change)
shift n. (a period at work)
I agree that in "normal life" you can guess the meaning from the context
because it has completely different meanings.
However, I don't agree that this should hold true in computer science.
One possible meaning of KB is "1000 bytes". The other is "1024 bytes".
Now take the sentence: "Hello John. I've got a file here and want to
send it to you. It's 25KB large." Now please extract from the context
which meaning is significant here? The problem is that the both possible
meanings depict exactly the same: a quantity of bytes.

> Finally a personal and subjective thought.  At times one has to chose
> whether to oversimplify facts and information to the point where
> "everyone" understands it, (If this happens they DO NOT understand it;
> they are given the illusion of understanding) or whether to educate
> the public.
I think that you base your argumentation on wrong assumptions. The
purpose of introducing SI prefixes is *not* to make the newbie's life
simpler, at least not as primary goal. Surely, there are situations
where it really doesn't matter (e.g. if you are interested in the order
of magnitude 10% error may be totally acceptable). However, SI prefixes
make life easier for technical stuff where it is important to be exact
without having to "guess" the context, ask every time or consider the
professional background of your communication partner.

Regards,
  Christof Krüger

Re: Using standardized SI prefixes

[Adam D. Barratt]

On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote:
> Mike Hommey wrote:
> 
> > On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov
> > <[EMAIL PROTECTED]> wrote:
> >> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
> >> 
> >> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
> >> 
> >> =10^12 :)
> >> 
> >> and Germany, France, former UdSSR, 
> > 
> > Anywhere where milliard is 10^9, basically...
> 
> Which includes England, according to Merriam-Webster [1]. 
[...]
> [1] http://www.m-w.com/mw/table/number.htm

The American usage has been becoming more common in England (and the
rest of Britain :-) over the past few years, particularly in science and
finance related usage.

I could be wrong, but I suspect most British people have never even
heard of a milliard. It's usually referred to either as a billion or an
"American billion".

Adam


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

Re: Using standardized SI prefixes

[Josselin Mouette]

Le mercredi 13 juin 2007 à 15:06 +0100, Scott James Remnant a écrit :
> On Wed, 2007-06-13 at 15:01 +0100, Alex Jones wrote:
> 
> > 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
> > less.
> > 
> No it doesn't.
> 
> The meaning of 1 TB depends on the context, and has always done so.

The meaning of 1 TB is approximate only for approximate people. I'd
expect more rigor from people working in computer science (if we can
call it a science).

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Best practices for cron jobs?

[sean finney]

On Wednesday 13 June 2007 06:28:09 Duncan Findlay wrote:
> I imagine it would be relatively simple to have the postinst generate
> a random time during the day for a cron script to run, but this
> doesn't work with anacron -- many users would never get updates.

how would this break anacron?

> What can I do to satisfy those with and without anacron, and to avoid
> hammering the sa-update servers at a specific time?

personally, i would do something like this:

  - generate the crontab with a random hour/minute into a temp file
  - register the temp file /etc/cron.d/yourpackage via ucf


sean


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

Re: Best practices for cron jobs?

[Adeodato Simó]

* sean finney [Wed, 13 Jun 2007 20:46:42 +0200]:

> On Wednesday 13 June 2007 06:28:09 Duncan Findlay wrote:
> > I imagine it would be relatively simple to have the postinst generate
> > a random time during the day for a cron script to run, but this
> > doesn't work with anacron -- many users would never get updates.

> how would this break anacron?

Because anacron can't run stuff only present in /etc/cron.d.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
As scarce as truth is, the supply has always been in excess of the demand.
-- Josh Billings


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

Re: Using standardized SI prefixes

[Russ Allbery]

Christof Krüger <[EMAIL PROTECTED]> writes:

> I'd really like to hear some real arguments against SI prefixes, besides
> being ugly or funny to pronounce or just because "it has always been
> like that". Advantages of using SI prefixes has been mentioned in this
> thread. Please tell me the disadvantages so there can actually be a
> constructive discussion.

Trying to change every piece of software in existence is a waste of time
and energy for a problem that isn't that serious.

IMO, that's the *real* objection; most of the arguments are justifications
for that position or are about things that we'd get over if this issue
were addressed (like the silly words -- there are sillier words in English
that just don't sound that way because we're used to them).

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Best practices for cron jobs?

[Jan-Pascal van Best]

Duncan Findlay wrote:
> Adding a sleep $[ $RANDOM % 60 ] is probably not a good idea as it will
> hold up all the other cronjobs that should be run.
>   
How about using a sub shell, so that other cron jobs can continue?
(
sleep $[ $RANDOM % 60 ]
sa-update
) &

(or something like this)

Cheers

Jan-Pascal




signature.asc
Description: OpenPGP digital signature

Re: Using standardized SI prefixes

[Christof Krüger]

On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:
> [...]
> And we still have many figures in both GB and GiB which are neither of
> the two!

okay ... reading on ...

> [...]
> I see no problem with this "1TB" quote being approximate.  It's
> rounded anyway.

So you don't care if it is approximate? Then you should care less if
it's even exact!

However, I find that tebibyte, gibibyte, mebibyte and kibibyte sound
quite familiar to their base-10 friends so that it should be no problem
even for a dumb user to understand its meaning if he already knew what a
gigabyte or megabyte is. This is especially the case with the short
notation (e.g. KiB vs. KB).

The more important case is when a user actually *cares* about the exact
number.
At the moment base 10 and base 2 numbers are often prefixed both with k
for kilo, M for mega etc. This means that there will be confusion if
something is labeled 100GB.
Now consider introducing SI prefixes.
There still will be confusion with "100GB", because apparently not
everyone likes SI prefixes and continues using the "old" prefixes with
base 2 numbers. However, when something is labeled "100GiB", there is no
confusion (remember that we are talking about a user that cares about
the exact number, the dumb user will guess that GiB must be something
similar to GB).
Okay, so we gained some confidence about what is meant. How can we get
rid of the rest of uncertainty? Answer: Use the SI prefixes
consistently! This will take a while of course, but eventually you can
only benefit.

Regards,
  Christof Krüger

Re: Two proposals for a better Lenny (testing related).

[Josselin Mouette]

Le mardi 12 juin 2007 à 17:40 -0300, Gustavo Franco a écrit :
> I disagree, that's what we've with experimental today mainly due to
> the fact that there's just a few packages there. Consider everybody
> uploading every package for unstable instead.

This has already been tried by Fedora and Mandriva, which ship
development versions of their packages in the top-of-the-edge releases.
The result is that developers are more focused on how to deal with utter
breakage of their own installation than on improving software they
maintain.

Please, avoid that. And do never, ever forget that rule before uploading:

UNSTABLE PACKAGES SHOULD BE RELEASE QUALITY

Mistakes happen, but to detect them we need people using unstable, and
people won't use a completely broken distribution. 

People knowingly uploading a package unsuitable for a stable release
should be forced into working as d-i release manager for 3 months.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Using standardized SI prefixes

[Lionel Elie Mamane]

On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote:

> Even in the US all legitimate science and engineering is done in SI
> units.

Suurre... That's why in 1999 the NASA Mars orbiter didn't crash
because one (NASA) team worked in metric units and the other (private
contractor) in imperial units.

-- 
Lionel


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

Re: Best practices for cron jobs?

[Florian Weimer]

* Duncan Findlay:

> I imagine it would be relatively simple to have the postinst generate
> a random time during the day for a cron script to run, but this
> doesn't work with anacron -- many users would never get updates.

debsecan creates a cron entry which is run hourly, at a random minute,
and the invoked script simply does nothing unless a day has passed
since the last activity.

This was the best thing I could come up with.  People keep talking
about ucf in this context, but I don't see how it contributes to a
solution. (Just make sure that the generated cron entry does not
contain any configuration data such as command line arguments.)


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

Re: Using standardized SI prefixes

[Josselin Mouette]

Le mercredi 13 juin 2007 à 15:19 +0200, Bjørn Ingmar Berg a écrit :
> When computers and humans interact (on a technical level)
> humans must adapt to the computer, because computers can not.

Anyone starting with such assumptions should never design any kind of
user interface.

> Dealing with chunks of data, addresses, registers, etc. has to be done
> in base 2.  Even if 1024 is "close enough" to 10^3 for a PHB or
> marketing humanoid, that will never make those two numbers equal.  And
> it must never be allowed to.  Computers, computer designers, computer
> technicians and most computer programmers will always deal with the
> _real_ base 2 numbers like 1024.

Which is why they need appropriate units.

> Another example.  Pi is an irrational number starting with 3.14
> Sure, it would be easier to "standardize" it to 3.00.  Done deal.  It
> would be easier to remember and more marketable.  It would also be
> totally useless AND completely wrong.  AFAIK some very dumb people
> actually managed to decree by law that pi was to equal 3.  They had to
> stop doing that.

This is exactly what you are trying to do: state that 1024 = 1000.

> A well-known and very common trait of language is that one given word
> can often have more than one specific meaning.  When this is the case
> you need a context to be sure.  This is considered normal, and never a
> real problem.  This should hold true regarding computers and counting
> as well.

Yeah, sure. This is why mathematicians always use 3 instead of Pi in
calculations. After all they are similar, and you can infer which one is
actually being used depending on the context.

> I am very convinced the correct solution is always to
> educate the public.  The world is not flat.  The earth is not the
> center of the universe.  Pi is not 3.  A kilobyte is not 1000; it is
> 1024 because that is the way computers work.

I am convinced the correct solution is to educate the group of blindfold
hackers who think 1024 = 1000. It is much easier than educating millions
of users.

Wake up, Neo. There is a world out there. And in this world, "kilo"
means 1000. One thousand. 10³.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 03:45 -0700, Steve Langasek escreveu:
> On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
> 
> > look ... i don't want guaranties ... you know what i mean ... want a
> > place where it says "testing HAS security support, we focus on having it
> > stable. I don't want  written contract ... i want a desktop user to
> > discard stable and use testing. For that debian needs do publicly advice
> > the use of testing in these cases ... and i mean for real.
> 
> You are never going to get a statement from the Debian project telling users
> to use one suite or another (or at least, you shouldn't); the most we should
> be doing is giving users a list of pros and cons for each suite and letting
> them decide which fits their needs.  I'm all in favor of reducing the number
> of decisions users have to make *in the software* :), but on something as
> high-level as which distro/suite to use, misestimating a user's needs is the
> kind of thing that will sour the user on Debian for a very long time.

Yes, but debian *only* publicites the use of stable (that home users or
desktop users tag as "stale"). If you publicity say that testing (or
maybe this should be renamed :( ) is the way for an up-to-date, latest
software distribution , then they will use it.

for now it only states that testing is ... testing, right?
> 
> > > There is a testing security team that addresses unembargoed security 
> > > issues
> > > in testing.  Fixes for embargoed security issues are generally not 
> > > prepared
> > > in advance for testing.  However, more people have access to work on the
> > > unembargoed security issues anyway (in the general case: anyone can upload
> > > to t-p-u), so it's not definite that stable is always more secure than
> > > testing.
> 
> > So, maybe, have more strict upload rules? Or, on the other way,
> > maintainers can upload packages directly into testing (from t-p-u?).
> 
> More strict upload rules for what?

To have security updates in testing, easily and stable ... not to
upgrade a new version into testing that can break stuff, or some mixed
unstable and testing upload.

> 
> > > >  - Testing simply moves too fast and the automatically passage process
> > > > between unstble and testing *DOES* break testing. For one example,
> > > > package "foo" requires package "bar<=0.3" but package "bar 0.4"
> > > > automatically passes to testing.
> 
> > > Um, no.  That does not happen automatically.  In rare cases it happens
> > > because the release team has overridden the installability check for a
> > > package, because maintainers have not coordinated their transitions in
> > > unstable and as a result something needs to be broken to ever get any of 
> > > the
> > > packages updated because you can't get 300 maintainers to get their 
> > > packages
> > > in a releasable state *and* leave them alone long enough to transition to
> > > testing as a group.
> 
> > So please, don't do those "oh, let them pass" transitions ... they BREAK
> > stuff ... for real.
> 
> What?
Some packages are allowed to pass into testing even if other depends on
it, but has issues that will take some time to resolve. This will make
that that package, that is now in testing, will not be installable in
anyway. This happens sometimes.

> 
> > > That's a problem of the packaging of those kernel modules, then, not a
> > > problem of testing per se; even if you track stable and therefore the
> > > problem only affects you once every two years, it's still a problem that
> > > should be addressed -- e.g., with metapackages like nvidia-kernel-2.6-686
> > > (oh look, this one already exists).
> 
> > kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
> > time (they are not free, right?) ... kernel passes to testing ...
> 
> That doesn't happen.

well ... it happened to me before etch was released ... in such a way
that i gave up using them.
> 
> > this is a simple upgrade ... because kernel packages are always NEW, the
> > kernel will pass because it has no reverse dependency problems in
> > testing.
> 
> False.
true.

nvidia-kernel  (meta packge) depends on linux-image-2.6.10.

a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did
not pass because it is too young.

nvidia-kernel is unusable.
Or the user reboots with the new kernel, or edits by hand the
xorg.conf .

I used testing since about 3 months after sarge was released ... it was
quite stable, but some transitions broke my system and it should not
happen.

> -- 
> 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/
> 
> 


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 12:39 +0200, Gabor Gombas escreveu: 
> On Wed, Jun 13, 2007 at 11:28:52AM +0100, Luis Matos wrote:
> 
> > kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
> > time (they are not free, right?) ... kernel passes to testing ...
> > automatically, the nvidia-module-2.6.50 uses 2.6.50 and not *.51, so ...
> > after a reboot, my xorg server will not run... when it used to.
> 
> Then create an empty nvidia-module package that depends on the latest
> nvidia-module-X.Y.Z package and conflicts with linux-image-$ARCH >> X.Y.Z.
> Just because you're using non-free kernel modules does not mean that
> everyone else _not_ using those modules should be penalized.

but why should I??? this goes against the "testing is always *WORKING*"
phrase. TESTING IS NOT ALWAYS WORKING.

you had the example with nvidia modules, what about wifi modules ...
what about ... camera modules (i think they are all in the same source
package now).
They all BREAK in this case. How many of debian developers and
contributors use these modules?

> 
> Or alternatively, just reboot with the old kernel just like you'd do
> when you found out that any random driver you happen depend on stops
> working in the new kernel version.

that is an *extreme* situation ... when there is  BUG in the
software ... not just because some package entered testing and broke
your system.

> 
> Gabor
> 
cheers, 
Luis Matos


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

Re: Bug#428198: ITP: gabedit -- graphical interface to Ab Initio packages

[Daniel Leidert]

Am Sonntag, den 10.06.2007, 08:41 +0200 schrieb Luca Brivio:
> Daniel Leidert wrote:
> > Gabedit is a graphical user interface to computational chemistry
> > packages, like:
> >
> >  - GAMESS-US
> >  - Gaussian
> >  - Molcas
> >  - Molpro
> >  - MPQC
> >  - Q-Chem
> 
> Maybe the fact that MPQC is the only one which is free and already in Debian 
> (so that this package will go in the main section) could be worth some 
> highlighting (e.g. "Gabedit is a graphical user interface to MPQC and to 
> following proprietary/commercial software: [...]",

This could be a choice. But I would probably add this information to the
manpage, not to the package documentation.

> maybe also append "like 
> MPQC" to the short description and make it "Recommends:" the latter). After 
> all, Debian is about software freedom. :-)

I don't think, the fact that mpqc is a DFSG-compliant software, warrants
a recommends. There is no reason to recommend an Ab Initio package, just
because it's free. Different users have different needs :) So they will
choose one or more Ab Initio package based on their needs.

BTW: The package (already/currently) suggests mpqc. This is IMHO enough.

Regards, Daniel


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

Re: Two proposals for a better Lenny (testing related).

[Russ Allbery]

Luis Matos <[EMAIL PROTECTED]> writes:

> but why should I??? this goes against the "testing is always *WORKING*"
> phrase. TESTING IS NOT ALWAYS WORKING.

Having to use module-assistant != not working.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: How to package software with binaries in tarball?

[Steinar H. Gunderson]

On Wed, Jun 13, 2007 at 10:06:20PM +0400, Sergei Golovan wrote:
>> pristine source. It is rather nice to be able take debian's tar.gz and
>> verify with md5sum or a detached gpg sig that upstream's tarball is
> The original tarball contains non-free RFCs, so it is recreated anyway.

On a general note (I haven't checked if this applies to erlang or not):
Please, if you repack, include the exact instructions for repacking in
debian/copyright; ideally down to something you could cut-and-paste into a
shell. Even though the resulting tarball might not be identical, it makes for
much easier NMUing _and_ upstream intactness checking.

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


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

Bug#428750: ITP: drawxtl -- display crystal structures on ordinary computer hardware

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: drawxtl
  Version : 5.3
  Upstream Author : Larry Finger, Martin Kroeker and Brian Toby
* URL : http://home.att.net/~larry.finger/drawxtl/
* License : LGPL/Public Domain/GL2PS LICENSE (see

http://svn.debian.org/wsvn/debichem/wnpp/drawxtl/debian/copyright?op=file&rev=0&sc=0)
  Programming Lang: C, C++
  Description : display crystal structures on ordinary computer hardware

DRAWxtl reads a basic description of the crystal structure, which includes
unit-cell parameters, space group, atomic coordinates, thermal parameters or
a Fourier map, and outputs a geometry object that contains polyhedra, planes,
lone-pair cones, spheres or ellipsoids, bonds, iso-surface Fourier contours
and the unit-cell boundary.

Four forms of graphics are produced:

 (1) an openGL window for immediate viewing
 (2) the Persistence of Vision Ray Tracer (POV-RAY) scene language for
 publication-quality drawings
 (3) the Virtual Reality Modeling Language (VRML) for dissemination
 across the Internet
 (4) a Postscript rendering of the OpenGL window for those that want
 high-quality output but do not have
 POV-RAY installed.


The package is actively maintained by the debichem project members at
alioth.debian.org.

- -- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.20.3 (PREEMPT)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGcF2Xm0bx+wiPa4wRArCqAJwOgmCKIInaz843x48z57NYtPxC3gCfX9Py
3gelB2+7rRfOONLBBu8YqCc=
=WNm9
-END PGP SIGNATURE-


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu:
> Luis Matos <[EMAIL PROTECTED]> writes:
> 
> > but why should I??? this goes against the "testing is always *WORKING*"
> > phrase. TESTING IS NOT ALWAYS WORKING.
> 
> Having to use module-assistant != not working.

having a working system *with* only debian *oficial* packages and then
after an upgrade that system stops working properly, i call it a
regression ...

if ... *if* i had used module-assistant to use nvidia graphics (or
camera modules, or wifi, or what else), i would not mind to do that.
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED])   
> 
> 


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

Re: Using standardized SI prefixes

[Onno Benschop]

As I see it there are two ways of resolving the difference between KiB
and KB.

* Use Rosetta to update the text and fix the output so that it now
  reads KiB. This would be relatively simple to do, but not actually
  helpful longer term.
* Fix the source code that calculates KB by doing a bit shift[0] and
  instead dividing the number of bytes by a power of 10.



[0] I'm assuming that most applications will calculate how many
Kilobytes/Megabytes are used by dividing by a power of two.

-- 
Onno Benschop

Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA)
--
()/)/)()..ASCII for Onno..
|>>?..EBCDIC for Onno..
--- -. -. ---   ..Morse for Onno..

Proudly supported by Skipper Trucks, Highway1, Concept AV, Sony Central, Dalcon
ITmaze   -   ABN: 56 178 057 063   -  ph: 04 1219    -   [EMAIL PROTECTED]


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

Re: Using standardized SI prefixes

[Ivan Jager]

On Wed, 13 Jun 2007, Alex Jones wrote:

On Wed, 2007-06-13 at 14:29 +0100, Scott James Remnant wrote:

Without the binary unit to consider, when we quote a drive as 1TB, we
know that it has *at least* 1,000,000,000,000 bytes available.
Depending on the drive, it may have anywhere between this and
1,099,511,627,776 bytes available.  It's actually more likely to have
something strange like 1,024,000,000,000 available.


10% error is no good for me. You can continue to play the "at least"
card, but what about when it's more important if it is "at most"
something? And seeing as this error only goes up exponentially, at which
prefix do you draw the line and say "no more"?

And no-one uses floppy disks any more. Let's just bury them all and
forget about them. :D


I see no problem with this "1TB" quote being approximate.  It's rounded
anyway.  If you really want to know how many bytes are available, you
can use this great unit called the "byte" which is accurate and not
subject to change[0].


1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more and no
less. If they want to actually put 1.024 TB on the disk then they can
say 1 TB (approx.) like any other industry (detergent, bacon, etc.).


1 TB has only one significant digit. It would be silly to think that it 
was an exact measurement, at least in fields I am familiar with. ;) No one 
I know would think 1km is as precisely measured as 1.0km.


But, just because it is approximate, doesn't mean it isn't also 
ambigouous. :) 1 TB could mean between 5000 and 14999 
bytes, between 549755813888 and 1649267441663  bytes, or even 
between 5000 and 14999.99... bels. :)


So, if you want the exact number of bytes, don't round it off, and if you 
do round it off, don't be surprised if the rounding is ambiguous, because 
the units are not SI units, and the prefixes may or may not be. Just don't 
use prefixes when not rounding.


I wonder, do people feel as storngly about exactly how many tablespoons
1 TT is?

Ivan

Re: Two proposals for a better Lenny (testing related).

[Russ Allbery]

Luis Matos <[EMAIL PROTECTED]> writes:

> having a working system *with* only debian *oficial* packages and then
> after an upgrade that system stops working properly, i call it a
> regression ...

If you're using non-free drivers, the first part of your sentence above
doesn't apply.

Usually, however, those non-free drivers that are built for each kernel
get built before the new kernel migrates to testing, but given that those
builds can't be handled by the general mechanism for building add-on
modules, I don't think the currency of those builds can be guaranteed.

My recommendation is to always use module-assistant for all non-free
drivers that you want to use.  That way, if there is a build in non-free,
you can be pleasantly surprised, but your normal method will always work.

Many non-free drivers (and some free drivers, for that matter) are never
automatically built at the moment, although with the new mechanism for
building modules in main, hopefully that number will drop over time for
the free ones.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Two proposals for a better Lenny (testing related).

[Steinar H. Gunderson]

On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote:
> Many non-free drivers (and some free drivers, for that matter) are never
> automatically built at the moment, although with the new mechanism for
> building modules in main, hopefully that number will drop over time for
> the free ones.

Could you please elaborate on this mechanism, or point to an URL? (If it's
been discussed here and I just missed it, I apologize -- I skip most of
-devel these days :-) )

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


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

Re: Two proposals for a better Lenny (testing related).

[Felipe Sateler]

Luis Matos wrote:

> Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu:
>> Luis Matos <[EMAIL PROTECTED]> writes:
>> 
>> > but why should I??? this goes against the "testing is always *WORKING*"
>> > phrase. TESTING IS NOT ALWAYS WORKING.
>> 
>> Having to use module-assistant != not working.
> 
> having a working system *with* only debian *oficial* packages and then
> after an upgrade that system stops working properly, i call it a
> regression ...

Installing a newer kernel is not an upgrade, in a sense. You are installing
new software alongside the old one. Thus the usual expectations don't hold.

PS: I do agree that it would be nice if there was a way to automatically
bring in the modules you are using for the new version, or at least warn,
but I can't seem to figure out a nice and elegant way of doing that. And
no, more people using testing won't fix this issue either.


-- 

  Felipe Sateler


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

Re: Two proposals for a better Lenny (testing related).

[Russ Allbery]

Steinar H Gunderson <[EMAIL PROTECTED]> writes:
> On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote:

>> Many non-free drivers (and some free drivers, for that matter) are
>> never automatically built at the moment, although with the new
>> mechanism for building modules in main, hopefully that number will drop
>> over time for the free ones.

> Could you please elaborate on this mechanism, or point to an URL? (If
> it's been discussed here and I just missed it, I apologize -- I skip
> most of -devel these days :-) )

http://packages.qa.debian.org/l/linux-modules-contrib-2.6.html

My understanding of the goal is that this package will build-depend on the
source packages of all the free external drivers that can support this
sort of automated build and then only the linux-modules-contrib
maintainers have to deal with the ever-changing exact list of kernel
versions for which modules should be built.

I don't know how far along this is yet.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Two proposals for a better Lenny (testing related).

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:
> Steinar H Gunderson <[EMAIL PROTECTED]> writes:
>> On Wed, Jun 13, 2007 at 03:00:15PM -0700, Russ Allbery wrote:

>>> Many non-free drivers (and some free drivers, for that matter) are
>>> never automatically built at the moment, although with the new
>>> mechanism for building modules in main, hopefully that number will drop
>>> over time for the free ones.

>> Could you please elaborate on this mechanism, or point to an URL? (If
>> it's been discussed here and I just missed it, I apologize -- I skip
>> most of -devel these days :-) )

> http://packages.qa.debian.org/l/linux-modules-contrib-2.6.html

Also, and more interestingly:

http://packages.qa.debian.org/l/linux-modules-extra-2.6.html

contrib is just the ones that go into contrib, of course.  (D'oh.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Using standardized SI prefixes

[Wesley J. Landaker]

On Wednesday 13 June 2007 14:03:51 Lionel Elie Mamane wrote:
> On Tue, Jun 12, 2007 at 05:33:12PM -0600, Wesley J. Landaker wrote:
> > Even in the US all legitimate science and engineering is done in SI
> > units.
>
> Suurre... That's why in 1999 the NASA Mars orbiter didn't crash
> because one (NASA) team worked in metric units and the other (private
> contractor) in imperial units.

I am happy to very brutally assert that the team who didn't use SI was not 
doing legitimate science or engineering. But whether it's from unskilled 
employees or bad management, it's quite unfortunate. =(

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu:
> Luis Matos <[EMAIL PROTECTED]> writes:
> 
> > having a working system *with* only debian *oficial* packages and then
> > after an upgrade that system stops working properly, i call it a
> > regression ...
> 
> If you're using non-free drivers, the first part of your sentence above
> doesn't apply.

I agree ... so what about the linux-modules-contrib-2.6 source package?

> Usually, however, those non-free drivers that are built for each kernel
> get built before the new kernel migrates to testing, but given that those
> builds can't be handled by the general mechanism for building add-on
> modules, I don't think the currency of those builds can be guaranteed.

agreed.
> 
> My recommendation is to always use module-assistant for all non-free
> drivers that you want to use.  That way, if there is a build in non-free,
> you can be pleasantly surprised, but your normal method will always work.

i don't think that this is useful in a debian way. That is equal to tell
the maintainer to stop his work.

> 
> Many non-free drivers (and some free drivers, for that matter) are never
> automatically built at the moment, although with the new mechanism for
> building modules in main, hopefully that number will drop over time for
> the free ones.

i hope so.
i want to tell a couple of things:
 1. My critic goes for the automatic passage of packages that make other
packages (already available in testing) uninstallable or conflictive. In
these 2 sets are packages that have reverse depends and, for example,
the kernel.
 2. You, like other, confirm this situation, but for some reason, you
just don't explicit agree with it.
 3. My main objective is to turn testing an *REAL* alternative for
stable. I've used testing (now i am running stable). It's quite stable,
but some upgrades break stuff. This breakage should not happen and
packages that cause breakage should not pass into testing.
 4. Making testing more visible as a bleeding edge (+/-) *stable*
distribution would be a nice thing and people would appreciate. Making
snapshots (full cd sets called previews, for one example) would make it
visible and useful. Users with testing (commonly home or power users)
can see it's system evolute, while it remains stable, usable and
bleeding edge (stability would be preferred over bleeding edge).
 5. CUT is *THE* option for testing that would permit this.

just my thoughts.

Luis Matos
> 
> -- 
> Russ Allbery ([EMAIL PROTECTED])   
> 
> 


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

Re: Two proposals for a better Lenny (testing related).

[Emanuele Rocca]

* Joey Hess <[EMAIL PROTECTED]>, [2007-06-11 19:56 -0400]:
>  Testing also needs periodic snapshots and guaranteed upgradability to
>  be useable by more users, amoung other points I discuss at
>  http://kitenet.net/~joey/code/debian/cut/

"Snapshots should be made available regularly, so that users who need a
 firm foundation for deployment have one. They'd be numbered, so we could
 call them cut 4, cut 5, etc. Each would be a snapshot of testing at a
 point when it was in especially good shape."

Another option could be calling each snapshot cut -MM, or cut
-MM-DD if we plan to release them more than once per month.

I realize that 'freezing' testing when it is in good shape we adhere to
the "when it's ready" philosophy, but can you think of a rough estimate
about how often it could happen?

ciao,
ema


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu:
> Luis Matos wrote:
> 
> > Qua, 2007-06-13 às 14:16 -0700, Russ Allbery escreveu:
> >> Luis Matos <[EMAIL PROTECTED]> writes:
> >> 
> >> > but why should I??? this goes against the "testing is always *WORKING*"
> >> > phrase. TESTING IS NOT ALWAYS WORKING.
> >> 
> >> Having to use module-assistant != not working.
> > 
> > having a working system *with* only debian *oficial* packages and then
> > after an upgrade that system stops working properly, i call it a
> > regression ...
> 
> Installing a newer kernel is not an upgrade, in a sense. You are installing
> new software alongside the old one. Thus the usual expectations don't hold.

the usual expectation that i have with a new kernel is to improve my
operating system ... that includes no regressions on supporting my
hardware - for example, wifi or graphic card.

> 
> PS: I do agree that it would be nice if there was a way to automatically
> bring in the modules you are using for the new version, or at least warn,
> but I can't seem to figure out a nice and elegant way of doing that. And
> no, more people using testing won't fix this issue either.

what about checking the *-modules-2.6.A packages available and compare
them with the previous version?

if the count of both are equal, then kernel *and* modules can go into
testing. If, for some reason a module is not available or cannot migrate
into testing, kernel would not migrate.
> 
> 
> -- 
> 
>   Felipe Sateler
> 
> 


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qui, 2007-06-14 às 01:04 +0200, Emanuele Rocca escreveu:
> * Joey Hess <[EMAIL PROTECTED]>, [2007-06-11 19:56 -0400]:
> >  Testing also needs periodic snapshots and guaranteed upgradability to
> >  be useable by more users, amoung other points I discuss at
> >  http://kitenet.net/~joey/code/debian/cut/
> 
> "Snapshots should be made available regularly, so that users who need a
>  firm foundation for deployment have one. They'd be numbered, so we could
>  call them cut 4, cut 5, etc. Each would be a snapshot of testing at a
>  point when it was in especially good shape."
> 
> Another option could be calling each snapshot cut -MM, or cut
> -MM-DD if we plan to release them more than once per month.

this makes the snapshots just like the current ones (i think cd sets are
built weekly r monthly, can anyone confirm this?)
> 
> I realize that 'freezing' testing when it is in good shape we adhere to
> the "when it's ready" philosophy, but can you think of a rough estimate
> about how often it could happen?

think about transitions .. let's get etch release cycle example.

i think 2 or 3 snapshots would be good.

(not time ordered)
1. transition to xorg
2. new gnome version
3. new kde version
4. new gcc version

these are quite predictable, and i think the main objective is not FULL
stability, but to have a work base.
So, if we predict that in the next month a big transition will be made,
then, a snapshot will be made with the transition objectives.

When they are accomplished, debian would ship a snapshot.
By scheduling the snapshot, other maintainers can upload their new
packages that will be included in the snapshot.

remind you that if packages only pass to testing *ready for stable*
(more or less) any snapshot would be quite stable and usable (+/- like
an ubuntu release - this was a bad joke).
Having this *release* would make people to use more debian.
Of course the system would be continuously updated.
> 
> ciao,
> ema
> 
> 

best regards,
Luis Matos


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

Re: Two proposals for a better Lenny (testing related).

[Russ Allbery]

Luis Matos <[EMAIL PROTECTED]> writes:
> Qua, 2007-06-13 às 15:00 -0700, Russ Allbery escreveu:

>> My recommendation is to always use module-assistant for all non-free
>> drivers that you want to use.  That way, if there is a build in
>> non-free, you can be pleasantly surprised, but your normal method will
>> always work.

> i don't think that this is useful in a debian way. That is equal to tell
> the maintainer to stop his work.

I think this is a ridiculous exaggeration.  module-assistant is not
difficult to use.  Installing the correct kernel modules for your kernel
is a one-line command.

> i want to tell a couple of things:
>  1. My critic goes for the automatic passage of packages that make other
> packages (already available in testing) uninstallable or conflictive. In
> these 2 sets are packages that have reverse depends and, for example,
> the kernel.
>  2. You, like other, confirm this situation, but for some reason, you
> just don't explicit agree with it.

For non-free, this is inevitable without significant changes to the way
that Debian works that I don't believe will happen.  Debian has provided a
different solution in the form of module-assistant that in my experience
works great.  I recommend that you learn how to use it rather than tilting
at windmills.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: Two proposals for a better Lenny (testing related).

[David Nusinow]

On Wed, Jun 13, 2007 at 11:53:24AM +0200, Gabor Gombas wrote:
> On Wed, Jun 13, 2007 at 12:42:34AM +0100, Luis Matos wrote:
> 
> >  - Smooth passages are not always smooth (who had a working xorg after
> > the upgrade for 7, please raise their hands)
> 
> AFAIR apart from having to edit a few config files it was quite painless
> (I've upgraded when Xorg was still in experimental).
> 
> OTOH the current xserver-xorg-video-ati snapshot in experimental is not
> suitable for everyday use (the crash in DPMS is a blocker for me) so I'd
> be quite annoyed if it was uploaded to unstable; but being able to
> easily test new versions to see if the bugs are still there is very
> useful.

By the time it hit testing it worked pretty well for most people. We broke
a few things, but it was nice for just about everyone. Everyone except
those people using proprietary drivers, but they know they've already dug
their own grave there. If Luis wants to keep whining about it, I suggest he
talk to nvidia.

 - David Nusinow


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

Re: Two proposals for a better Lenny (testing related).

[Russ Allbery]

David Nusinow <[EMAIL PROTECTED]> writes:

> By the time it hit testing it worked pretty well for most people. We
> broke a few things, but it was nice for just about everyone. Everyone
> except those people using proprietary drivers, but they know they've
> already dug their own grave there. If Luis wants to keep whining about
> it, I suggest he talk to nvidia.

I didn't have many problems even with proprietary drivers.  I thought it
went quite smoothly.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 16:18 -0700, Russ Allbery escreveu:
> For non-free, this is inevitable without significant changes to the
> way
> that Debian works that I don't believe will happen.  Debian has
> provided a
> different solution in the form of module-assistant that in my
> experience
> works great.  I recommend that you learn how to use it rather than
> tilting
> at windmills. 

this is not a discussion on how to support non-free drivers ... 
module-assistant is not an answer to the modules-contrib and
modules-extra (at least). (i have used module-assistant and i think is a
great tool)

the problem here (that happened to me with other packages) is that some
packages with reverse dependencies passed into testing making other
packages uninstalable. kernel and modules is just one problem.
my point here is that i think the current structure is ok, but ... the
passage to testing has to be done with more care (care it already has).

i am not whining about the use of nvidia non-free drivers ... i am
whining about have a good CUT and *THAT* requires the paragraph
before.  


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

Re: Two proposals for a better Lenny (testing related).

[Luis Matos]

Qua, 2007-06-13 às 19:20 -0400, David Nusinow escreveu:
> By the time it hit testing it worked pretty well for most people. We
> broke
> a few things, but it was nice for just about everyone. Everyone except
> those people using proprietary drivers, but they know they've already
> dug
> their own grave there. If Luis wants to keep whining about it, I
> suggest he
> talk to nvidia. 

lol ... the passage from xorg 6 to 7 was a big passage ... i had some
uninstalable packges (not nvidia related), i even opened a bug[0], that
i closed some weeks ago when i reviewed the bugs i've submitted.

this is one example about the problem i am trying to get attention to.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370370


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

Re: Using standardized SI prefixes

[Ben Finney]

Ivan Jager <[EMAIL PROTECTED]> writes:

> On Wed, 13 Jun 2007, Alex Jones wrote:
> > 1 TB is not rounded. It means precisely 1 × 10^12 bytes, no more
> > and no less. If they want to actually put 1.024 TB on the disk
> > then they can say 1 TB (approx.) like any other industry
> > (detergent, bacon, etc.).
>
> 1 TB has only one significant digit. It would be silly to think that
> it was an exact measurement, at least in fields I am familiar
> with. ;) No one I know would think 1km is as precisely measured as
> 1.0km.

The difference being that digital specifications for things like
storage capacity and memory are not measured. They are calculated, and
in those contexts they *are* precise.

Rounding can be done after the calculated number is obtained, but it's
not inherent in the process of obtaining the number the way that
measuring "1 km" or "1 tablespoon" is.

Since we *can* give a perfectly precise quantity of bytes and other
digital phenomena, and often do, this is even more reason to use the
precise meaning of the units for those quantities.

-- 
 \  "I moved into an all-electric house. I forgot and left the |
  `\   porch light on all day. When I got home the front door wouldn't |
_o__) open."  -- Steven Wright |
Ben Finney


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

Re: Using standardized SI prefixes

[Ben Finney]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Christof Krüger <[EMAIL PROTECTED]> writes:
>
> > I'd really like to hear some real arguments against SI prefixes,
> > besides being ugly or funny to pronounce or just because "it has
> > always been like that". Advantages of using SI prefixes has been
> > mentioned in this thread. Please tell me the disadvantages so
> > there can actually be a constructive discussion.
>
> Trying to change every piece of software in existence is a waste of
> time and energy for a problem that isn't that serious.

This proposal was never about "trying to change every piece of
software in existence". Just because perfection is unobtainable
doesn't stop us from working to improve the state of what we have.

> IMO, that's the *real* objection; most of the arguments are
> justifications for that position or are about things that we'd get
> over if this issue were addressed (like the silly words -- there are
> sillier words in English that just don't sound that way because
> we're used to them).

Agreed. Most of the arguments against this proposal to follow a useful
standard that improves clarity have been essentially "yuk" or "I'm
alright Jack".

Yes, the names sound silly. So does "byte", but we follow that
convention. A silly name is not an argument against following the
standard. The names are close enough to the wrongly-applied base-10
names that familiarity is fairly easily obtainable, while still being
different enough that they are distinct names.

Yes, most of us who frequently work with computers have become
accustomed to the ambiguity of these terms, in a field where precision
of terminology is highly valued. This is no reason not to work toward
fixing this for the majority of people who have yet to spend any
significant time exposed to these terms.

-- 
 \   "One of the most important things you learn from the internet |
  `\   is that there is no 'them' out there. It's just an awful lot of |
_o__) 'us'."  -- Douglas Adams |
Ben Finney


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

Bug#428774: ITP: pixman -- pixel-manipulation library for X and cairo

[Julien Cristau]

Package: wnpp
Severity: wishlist
Owner: Debian X Strike Force <[EMAIL PROTECTED]>

* Package name: pixman
  Version : 0.9.3
  Upstream Author : Søren Sandmann <[EMAIL PROTECTED]>
* URL : git://anongit.freedesktop.org/git/pixman
* License : MIT/X
  Programming Lang: C
  Description : pixel-manipulation library for X and cairo

 A library for manipulating pixel regions -- a set of Y-X banded
 rectangles, image compositing using the Porter/Duff model
 and implicit mask generation for geometric primitives including
 trapezoids, triangles, and rectangles.


Future releases of the X.Org X server and of cairo will link against
pixman instead of duplicating this code, so packaging this is necessary
before we can consider uploading recent git snapshots of the X server to
experimental.
Preliminary packaging at
http://git.debian.org/?p=pkg-xorg/lib/pixman.git


signature.asc
Description: Digital signature

Re: Best practices for cron jobs?

[Brian May]

> "Duncan" == Duncan Findlay <[EMAIL PROTECTED]> writes:

Duncan> What can I do to satisfy those with and without anacron,
Duncan> and to avoid hammering the sa-update servers at a specific
Duncan> time?

Look at the clamav-freshclam package.

I suspect the maintainers have already encountered similar issues to
yours.

I can't remember the details of how clamav-freshclam works right now
though.
-- 
Brian May <[EMAIL PROTECTED]>


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

Bug#428776: ITP: libpciaccess -- Generic PCI access library for X

[Julien Cristau]

Package: wnpp
Severity: wishlist
Owner: Debian X Strike Force <[EMAIL PROTECTED]>

* Package name: libpciaccess
  Version : 0.8.0
  Upstream Authors: Ian Romanick <[EMAIL PROTECTED]>
Eric Anholt <[EMAIL PROTECTED]>
edward shu <[EMAIL PROTECTED]>
* URL : git://anongit.freedesktop.org/git/xorg/lib/libpciaccess
* License : MIT/X
  Programming Lang: C
  Description : Generic PCI access library for X

 Provides functionality for X to access the PCI bus and devices
 in a platform-independant way.

This is a dependency of the new avivo driver (for r500-based AMD cards),
and will be used by future releases of the X.Org X server.
Preliminary packaging at
http://git.debian.org/?p=pkg-xorg/lib/libpciaccess.git


signature.asc
Description: Digital signature

Re: Two proposals for a better Lenny (testing related).

[Steve Langasek]

On Wed, Jun 13, 2007 at 05:32:01PM +0100, Luis Matos wrote:
> > > > Um, no.  That does not happen automatically.  In rare cases it happens
> > > > because the release team has overridden the installability check for a
> > > > package, because maintainers have not coordinated their transitions in
> > > > unstable and as a result something needs to be broken to ever get any 
> > > > of the
> > > > packages updated because you can't get 300 maintainers to get their 
> > > > packages
> > > > in a releasable state *and* leave them alone long enough to transition 
> > > > to
> > > > testing as a group.

> > > So please, don't do those "oh, let them pass" transitions ... they BREAK
> > > stuff ... for real.

> > What?
> Some packages are allowed to pass into testing even if other depends on
> it, but has issues that will take some time to resolve. This will make
> that that package, that is now in testing, will not be installable in
> anyway. This happens sometimes.

Well, tough.  Take it up with the maintainers who don't coordinate their
uploads to unstable with the maintainers of related packages.  The release
team only breaks packages in testing when we *have* to do so to move the
release forward (meaning, a net reduction in RC problems).

> > > > That's a problem of the packaging of those kernel modules, then, not a
> > > > problem of testing per se; even if you track stable and therefore the
> > > > problem only affects you once every two years, it's still a problem that
> > > > should be addressed -- e.g., with metapackages like 
> > > > nvidia-kernel-2.6-686
> > > > (oh look, this one already exists).

> > > kernel upgrades from 2.6.50 to 2.6.51 ... nvidia packages don't build in
> > > time (they are not free, right?) ... kernel passes to testing ...

> > That doesn't happen.

> well ... it happened to me before etch was released ... in such a way
> that i gave up using them.

No.  The nvidia kernel packages are a particular case where the module
packages were willfully broken in testing by the release team because of
long-outstanding RC bugs in related nvidia packages.

Again, this was a necessary trade-off which reduced the overall number of
release-critical problems in testing.

> > > this is a simple upgrade ... because kernel packages are always NEW, the
> > > kernel will pass because it has no reverse dependency problems in
> > > testing.

> > False.
> true.

> nvidia-kernel  (meta packge) depends on linux-image-2.6.10.

> a new linux-image-2.6.20 passes to testing. The new nvidia-kernel did
> not pass because it is too young.

You either don't know how testing works, or you don't know how the Debian
kernel packages are structured.

-- 
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/


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

Bug#428777: ITP: xserver-xorg-video-avivo -- X.Org X server -- Avivo display driver

[Julien Cristau]

Package: wnpp
Severity: wishlist
Owner: Debian X Strike Force <[EMAIL PROTECTED]>

* Package name: xserver-xorg-video-avivo
  Version : 0.0.1
  Upstream Authors: Daniel Stone <[EMAIL PROTECTED]>
Matthew Garrett <[EMAIL PROTECTED]>
Jerome Glisse <[EMAIL PROTECTED]>
* URL : git://anongit.freedesktop.org/git/avivo/xf86-video-avivo
* License : GPL
  Programming Lang: C
  Description : X.Org X server -- Avivo display driver

 This driver for the X.Org X server (see xserver-xorg for a further
 description) provides support for ATI R500 cards.
 .
 Note that this driver is currently experimental and works in 2D only.


Anybody interested in helping out with the avivo package is welcome to
contact debian-x (I don't think any of the current XSF members have the
hardware).  Preliminary packaging at
http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-avivo.git


signature.asc
Description: Digital signature

Re: Two proposals for a better Lenny (testing related).

[Felipe Sateler]

Luis Matos wrote:

> Qua, 2007-06-13 às 18:09 -0400, Felipe Sateler escreveu:
>> Installing a newer kernel is not an upgrade, in a sense. You are
>> installing new software alongside the old one. Thus the usual
>> expectations don't hold.
> 
> the usual expectation that i have with a new kernel is to improve my
> operating system ... that includes no regressions on supporting my
> hardware - for example, wifi or graphic card.

But it doesn't hold, since you are actually installing a _new_ package, not
upgrading an existing.

> 
>> 
>> PS: I do agree that it would be nice if there was a way to automatically
>> bring in the modules you are using for the new version, or at least warn,
>> but I can't seem to figure out a nice and elegant way of doing that. And
>> no, more people using testing won't fix this issue either.
> 
> what about checking the *-modules-2.6.A packages available and compare
> them with the previous version?

That would live everyone waiting for the every module to be ready, of which
they may not be using some.

> 
> if the count of both are equal, then kernel *and* modules can go into
> testing. If, for some reason a module is not available or cannot migrate
> into testing, kernel would not migrate.

Note that independent of wether modules are in testing or not, upgrading a
kernel *won't* install the modules (out of tree modules, that is). You
still have to install them by hand. That is what I was referring to.


-- 

  Felipe Sateler


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

Re: Re: APT 0.7 for sid

[Philippe Cloutier]

I am definitely a GUI person (aptitude is the last non-GUI program
with a GUI available that I still use), but I still prefer aptitude to
any other. I was under the impression that most others did too, is it
not the recommended Debian way?.

Yes (but that's a reported bug, #418455)


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

Re: Two proposals for a better Lenny (testing related).

[Felipe Sateler]

Felipe Sateler wrote:


> That would live everyone waiting for the every module to be ready, of
 
> which they may not be using some.

That is leave, of course


-- 

  Felipe Sateler


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

Re: Using standardized SI prefixes

[shirish]

Hi all,
   One of the ways to drive usage as somebody mentioned is to
drive upstream & that is a good way. Make sure most of free libraries
incorporate KiB [0] & the mathematical stuff needed (No computer
engineer here, just a user who cares)  so things turn out right while
making sure that the end-user utility GUI's [1]  do show them & as
well as update things on wikipedia to show the new reality [2] :)

[0] http://libburnia-project.org/changeset/877 as well as
http://libburnia-project.org/changeset/876

[1] http://dev.deluge-torrent.org/changeset/527

[2] http://en.wikipedia.org/wiki/Binary_prefix#Adoption

As more & more softwares start using the standards while in
development there would be no more need to try & advocate usage of Si
prefixes. We just need to add critical mass & that's it.
--
 Shirish Agarwal
 This email is licensed under http://creativecommons.org/licenses/by-nc/3.0/

065C 6D79 A68C E7EA 52B3  8D70 950D 53FB 729A 8B17


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

GSASL Maintainer Missing in Action?

[cascardo]

Hello,

libgsasl and libntlm are maintained by Yvan Bassuel and were uploaded by
Anibal Salazar. I am CC'ing them.

Two weeks ago I've sent an email no Yvan, asking if he was still
interested in maintaining those packages. Both have newer upstream
versions. There is a bug with a patch for libgsasl7 that was not
answered by Yvan. It is dated as of last December. libgasl7 and libntlm0
were last uploaded in March 2006 and June 2006, respectively. I've sent
another message to Yvan on Monday.

Does anyone know the whereabouts of Yvan? May I consider him missing in
action?

I am interested in maintaining those packages. How should I proceed? NMU
before taking maintainership and wait another two weeks? Take
maintainership now? Or wait another two weeks and, then, uploading those
new versions? (I will need sponsorship, but that I can arrange.)

Best Regards,
Thadeu Cascardo.


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

Re: How to package software with binaries in tarball?

[Sergei Golovan]

On 6/14/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:

On Wed, Jun 13, 2007 at 10:06:20PM +0400, Sergei Golovan wrote:
>> pristine source. It is rather nice to be able take debian's tar.gz and
>> verify with md5sum or a detached gpg sig that upstream's tarball is
> The original tarball contains non-free RFCs, so it is recreated anyway.

On a general note (I haven't checked if this applies to erlang or not):
Please, if you repack, include the exact instructions for repacking in
debian/copyright; ideally down to something you could cut-and-paste into a
shell. Even though the resulting tarball might not be identical, it makes for
much easier NMUing _and_ upstream intactness checking.


Is get-orig-source target in debian/rules, which fetches and repacks
orig.tar.gz sufficient? I guess it should be.

--
Sergei Golovan


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

Re: Two proposals for a better Lenny (testing related).

[Manoj Srivastava]

On Mon, 11 Jun 2007 18:20:17 -0300, Gustavo Franco <[EMAIL PROTECTED]> said: 

> 1) The 'remove experimental' proposal

> * Warn developers and contributors[0]
> * Remove experimental
> * Switch unstable (release) for not automatic updates

This is one of the worst proposals I have seen.
  Removing experimental means that there is no place to pout in packages
  which are "probably broken, but really interested persons should
  please test".  There would be no way of distinguishing those from "new
  packages, ought to be OK, please test" stuff.

Prevent auto up0dating, means that, along with the above change,
 unstable becomes too annoying to run.

With people no longer running unstable, bugs do not get
 caught. Instead, bugs propogate to testing.

So, effectively, you have removed testing (and relabled unstable
 as testing).

With no real bug triage before testing, we are back to the old
 release dilemma: the distribution we release from has lots of bugg
 packages.  Welcome back to 1/2 year long freezes.

Why one earth would w3e want to regress to the days before
 testing? 

manoj
-- 
Quick, sing me the BUDAPEST NATIONAL ANTHEM!!
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: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Manoj Srivastava]

On Sat, 9 Jun 2007 11:24:08 -0500, Steve Greenland <[EMAIL PROTECTED]> said: 

> On 09-Jun-07, 04:30 (CDT), Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
>> My point is that it is useful to know what major release of Debian a
>> machine is using,

> My point is the only reliable way to determine that is via
> /etc/apt/sources and /etc/apt/preferences, not to mention
> /var/lib/dpkg/status (because packages might be on hold).

You are assuming that the contents of /etc/apt/sources and
 /etc/apt/preferences are fairly static.  That is an asumptio0n that
 does not hold true at least for my laptop, where the sources and
 preferences change a log when I travel (which is fairly often).

Parsing today's sources would lead you to assume I only do
 security up0dates, and would have no bearing on the versions of
 packages on my system (which come from local Sid partial mirror, not in
 my sources.list file today).

manoj
-- 
"Don't get married.  Find a woman you hate and buy her a house." anon
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: Using standardized SI prefixes

[Miles Bader]

Eduard Bloch <[EMAIL PROTECTED]> writes:
> What is not really understandable is why this stupid naming has been
> kept in Windows XP.

Because nobody actually cares except control-freak types, and they're
certainly not who windows is targetting!

-Miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson


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

Re: Using standardized SI prefixes

[Jean-Christophe Dubacq]

On Wed, Jun 13, 2007 at 07:41:27PM +0100, Adam D. Barratt wrote:
> On Wed, 2007-06-13 at 14:08 -0400, Felipe Sateler wrote:
> > Mike Hommey wrote:
> > 
> > > On Tue, Jun 12, 2007 at 09:25:13PM +, Evgeni Golov
> > > <[EMAIL PROTECTED]> wrote:
> > >> On Tue, 12 Jun 2007 15:42:08 -0300 Paulo Marcondes wrote:
> > >> 
> > >> > billion = 10^6 * 10^6 (IIRC, as used in Portugal - no jokes here!)
> > >> 
> > >> =10^12 :)
> > >> 
> > >> and Germany, France, former UdSSR, 
> > > 
> > > Anywhere where milliard is 10^9, basically...
> > 
> > Which includes England, according to Merriam-Webster [1]. 
> [...]
> > [1] http://www.m-w.com/mw/table/number.htm
> 
> The American usage has been becoming more common in England (and the
> rest of Britain :-) over the past few years, particularly in science and
> finance related usage.
> 
> I could be wrong, but I suspect most British people have never even
> heard of a milliard. It's usually referred to either as a billion or an
> "American billion".

http://en.wikipedia.org/wiki/Long_and_short_scales

It all depends on space and time.


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

Re: Two proposals for a better Lenny (testing related).

[Frank Küster]

Marc 'HE' Brockschmidt <[EMAIL PROTECTED]> wrote:

> I think that a package that has been in unstable for a whole release
> cycle without entering testing should probably live in experimental or
> not in Debian at all. I guess that is something most people can agree
> on.

Hm, I was tempted to think "yes, of course", but how about foo-snapshot
or bar-cvs?  Why shouldn't they be in unstable, autobuilt and available
as Build-Depends for baz-bzr?

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

Re: Two proposals for a better Lenny (testing related).

[Raphael Hertzog]

On Wed, 13 Jun 2007, Felipe Sateler wrote:
> PS: I do agree that it would be nice if there was a way to automatically
> bring in the modules you are using for the new version, or at least warn,
> but I can't seem to figure out a nice and elegant way of doing that. And
> no, more people using testing won't fix this issue either.

It's not that complicated if we have the new "Breaks" field. I just
submitted my suggestion on the package linux-latest-2.6.

The idea is to have something like this:

Package: linux-image-2.6-686
Version: 2.6.21+7
Breaks: kqemu-modules-2.6-686 (<< 2.6.21+7), unionfs-modules-2.6-686 (<< 
2.6.21+7), ...

That way, linux-image-2.6-686 is upgraded only if a matching
kqemu-modules-2.6-686 / unionfs-modules-2.6-686 is also available. Of
course if the user has not installed any of those packages, it's a no-op
as it should be.

Some details probably need to be worked out, but it looks like a good way
to do that.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


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