Re: bits from the release team

[Andreas Barth]

* Sven Luther ([EMAIL PROTECTED]) [060103 23:02]:
> On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote:
> > the other hand side, the difference is only one week - and if nothing is
> > broken by that, we can freeze the kernel at N-110 also.
 
> i think comparing the kernel with the toolchain is overkill, if nothing else a
> last minute change in the toolchain will need a kernel recompile anyway maybe.
> I do confess that i read June 30 at first, and this seemed much less
> acceptable to me.

well, the kernel is definitly about the same level as the toolchain and
standard/base - changes can have very easily impact on the installer,
and it is not an option to remove the package if it is broken.


> > > > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > > > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > > > freeze, d-i RC]
> > > > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> > > 
> > > We will have a kernel which is outdated by two versions at release time 
> > > with
> > > this plan, since there are about 1 kernel upstream release every 2 month.
> > 
> > Well, if we want to release with a newer kernel, we need to make sure
> > d-i doesn't stumble over it. Experience tells us that there are enough
> 
> What experience ?

I was speaking about the installer. And usually there are lots of
last-minute changes that need to go in - not only new languages, but
lots of other small minor, but still important bug fixes.


> > Also, the kernel will be outdated sooner or later anyways - so, if after
> > one year the kernel is 12 or 14 months old is not too much a difference.
> 
> Hehe, me runs sid kernels installed almost as is on all my sarge systems
> indeed, just with rebuild yaird and mininmally backported udev.

Well, but then an older kernel doesn't hurt you? :P


> Indeed, but you have only the sarge experience to go by, and taking the sarge
> experience on this is hardly fair to the huge amount the kernel team has
> devoted to streamline the process.

Of course, we have seen that the kernel build process is way more mature
now. Nobody doubts that.


> Also, i don't really believe joeyh and fjp
> are really the relevant maintainers with regard to the debian kernel and its
> application, since they lack the vision of how things could go better, or more
> thruthfully, probably lack the time and motivation to think really about the
> issue, and why should they, it is the kernel team jobs :)

Well, they are definitly the relevant people for the installer. And,
frankly speaking, at least I have good experience with both of them.


> d-i is only a part of the problem anyway, and i believe the less problematic.
> out-of-tree modules and third-party patches are a worse mess.

Hm, which out-of-tree modules do you consider to be release critical,
i.e. we cannot release without them?


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


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

hi, ive a new mail address

[Capitalistpig Asset Management]

Thanks for your comments.

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 10:34:43PM -0800, Steve Langasek wrote:
> On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) 
> wrote:
> > 1. http://lkml.org/lkml/2005/12/3/55
> 
> > Perhaps the idea of maintain a kernel with other distros is not bad,
> > if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire,
> > Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really
> > don't know if it is possible to mix RH, Debian, SuSE, Slackware and
> > other distros to maintain the same kernel, but certainly should be possible
> > to get all Debian (and Debian based/derivative) playing together. :-)
> 
> The biggest obstacle to this is that different distributions have different
> and contradictory requirements for what ships in the kernel.  For Debian,
> the obvious requirement is that everything we ship in main meets the DFSG;
> this is a requirement that is not shared by Ubuntu, for instance, which
> means any collaboration on kernels between those two distros has to allow
> for different bits being stripped out at the time of source package
> generation.
> 
> It would certainly be nice to see improvements in kernel collaboration, and
> I believe it is possible, we just have to be honest with ourselves about the
> difficulties involved.

Also, notice that cooperation with the ubuntu kernels was more marked when
Fabionne was the ubuntu kernel maintainer, but now that he has passed the
relay, i feel that it is less. We have proposed to them to use a common
infrastrcuture with enabled/disabled patches for both, but the reply was
mostly of the kind, yeah we would like to cooperate, and no actions followed.
I believe it has also an influence on the place where the source package is
ohold (alioth svn repo over whatever strange stuff ubuntu uses), and they said
we should use their system. 

So, altough patches can occasionally be exchanged, i doubt that cooperation
will go further for control-and-politics reason, and i believe it is maybe
best so for both involved. There can be cooperation without sharing all the
infrastructure and packaging. Other less high-profile daughter-distros are
probably simply reusing the debian kernel, and this is probably the best way
of doing this.

Friendly,

Sven Luther


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

Re: bits from the release team

[Steve Langasek]

On Wed, Jan 04, 2006 at 12:23:31AM -0200, Felipe Augusto van de Wiel (faw) 
wrote:
> 1. http://lkml.org/lkml/2005/12/3/55

>   Perhaps the idea of maintain a kernel with other distros is not bad,
> if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire,
> Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really
> don't know if it is possible to mix RH, Debian, SuSE, Slackware and
> other distros to maintain the same kernel, but certainly should be possible
> to get all Debian (and Debian based/derivative) playing together. :-)

The biggest obstacle to this is that different distributions have different
and contradictory requirements for what ships in the kernel.  For Debian,
the obvious requirement is that everything we ship in main meets the DFSG;
this is a requirement that is not shared by Ubuntu, for instance, which
means any collaboration on kernels between those two distros has to allow
for different bits being stripped out at the time of source package
generation.

It would certainly be nice to see improvements in kernel collaboration, and
I believe it is possible, we just have to be honest with ourselves about the
difficulties involved.

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


signature.asc
Description: Digital signature

Re: bits from the release team

[Steve Langasek]

On Tue, Jan 03, 2006 at 11:27:25PM +0100, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote:
> > (forgot to CC d-kernel on this)

> > On Tuesday 03 January 2006 22:02, Sven Luther wrote:
> > > We will have a kernel which is outdated by two versions at release time
> > > with this plan, since there are about 1 kernel upstream release every 2
> > > month.

> > 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
> > starting to get implemented).

> > I remember we did consider using 2.6.10 instead of 2.6.8 and decided not 
> > to mainly because it was not really that much better than 2.6.8.
> > As I remember it, this was a joint decision by the kernel team, release 
> > managers and the d-i developers. Not something that the kernel team were 
> > really pushing and was blocked by some assholes from the d-i team who did 
> > not want to cooperate.

> Well, i remember joeyh vetoing it because it would take at least a month to
> get the change done, and i believe we didn't really push for it because the
> infrastructure was a mess back then. This has changed.

> The one point that put me up, is that we should have gotten that security
> update in, but this was also vetoed for the same month-long delay in the
> kernel/d-i upgrade process. The kernel team has reduced that delay to less
> than 24hours now for the release arches,

You have been harranguing the ftp team to approve new upstream kernels
through the NEW queue before they've even been uploaded -- for an amazing
false optimization that burns good will with your fellow developers.  Even
if udebs *were* being built from the same linux-2.6 source package, this
doesn't address the real reason why it's important to freeze the kernel
early:  *the kernel is a core component of everyone's system and detecting
regressions takes a long time*.  Anything that requires a reboot cycle or an
installation test in order for users to detect bugs is going to need a
longer testing period than other packages; the only way to ensure this
happens is by freezing it early, i.e., around the same time as the toolchain
packages for which we have the same problem of figuring out whether a new
version is better or worse.

The underlying assumption in your plea for a shorter kernel freeze is "newer
is better".  But people who accept this assumption unconditionally don't
*run* Debian stable; so neither should we base our freeze timeline on an
unconditional acceptance of it.  Newer isn't necessarily better, but it is
necessarily *different*, which is the enemy of stability.

There is still room for targetted fixes to the kernel after the freeze date;
backports of new drivers, or backports of specific bugfixes, are certainly
fair game.  Taking a new version of whatever upstream happens to have
released would not be.

> My believe is that this kind of thing should be as much automated as possible,
> to let the few ressource we have be used where best it should, a little work
> at the start which will pay off forever after, this is what computers and
> programming is for, to make the task of the users and programmers easier, i
> think we all agree with that, or we would still be using boot-floppies :)

I'm all in favor of streamlining the integration of new kernel versions into
the installer, but I don't believe that the majority of the work involved
falls into the "automatable" category.

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


signature.asc
Description: Digital signature

Re: How to Increase Contributions from Volunteers

[Manoj Srivastava]

On Tue, 3 Jan 2006 12:50:22 +0100, Andreas Schuldei <[EMAIL PROTECTED]> said: 

> * Thomas Hood <[EMAIL PROTECTED]> [2006-01-03 12:24:29]:
>> They are right: most probably they will find it easier to make
>> contributions to other projects.

> we need to promote the easy entry points to contributing to debian
> more prominently and should hide the "how to become a DD" in
> comparison.

What on earth for?

> we should leave that option for the ones that want to contribute
> above average.

We are trying to build the best distribution of linux on the
 planet, not the so-so ditribution created by the most number of
 people.  Why do you think that an excellent direbution can come by
 with contribution of people who are, in your own words, below
 average? 

manoj
-- 
A man without a woman is like a statue without pigeons.
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]

Remove from call- wave

[Corkylinda54]

Please remove me from call-wave. Thanks, corkylinda54  (  Louis E. Grantham )

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> I think the single-user system is the last one that alternatives handling
> should optimize for, since the *one* person who's going to know to type
> "nvi" instead of "vi", and the one person who can fix the alternatives if he
> doesn't like them, is the admin...

which also means he most likely wants to have the manually installed packet
to grab the alternative link.

Gruss
Bernd


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

Re: bits from the release team

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/2006 10:13 PM, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote:
> 
>>[EMAIL PROTECTED] (Marco d'Itri) writes:
>>
>>>On Jan 04, Adam Heath <[EMAIL PROTECTED]> wrote:
>>>
Not to mention that 2.6.15 requires a newer udev.  Who knows what other 
newer
things newer kernels might require.
>>>
>>>OTOH, old kernel are buggy and out of date wrt modern hardware, and we
>>>lack the manpower to backport for years fixes and new features RHEL-style.
>>>Do you have a better solution?
>>
>>Why don't we use RHEL's kernel, or collaborate with them to maintain a
>>stable kernel tree, or something?
> 
> Why doesn't debian really collaborate with ubuntu on the kernels, which would
> be more natural. Debian use mostly the mainline upstream kernels, which is
> where everything goes back in anyway, so ...

Just my two cents... :)


Sometime ago, Adrian Bunk [1]raise the question about a kernel stable
tree in LKML, after a lot of discussion (and AFAIK no good resolution), a lot
of ideas travel on the list (also in the midle of flamewar), ideas like "try
to not break the entire userland" and "let the distro take care of having a
stable kernel".

1. http://lkml.org/lkml/2005/12/3/55


Perhaps the idea of maintain a kernel with other distros is not bad,
if Ubuntu shows up as a candidate, I would like to add Progeny, Linspire,
Xandros, "DCC Alliance Fan Club" and also other Debian Derivatives. I really
don't know if it is possible to mix RH, Debian, SuSE, Slackware and
other distros to maintain the same kernel, but certainly should be possible
to get all Debian (and Debian based/derivative) playing together. :-)

If you give it a quick look (and a quick try), we will have more
users testing the same kernel, which means more feedback, we will have
more developers working to get it stable and working to get it secure.
Probably even upstream get benefits from this model and sounds like a very
good way to work together, even to try to integrate outside patches and
backporting things. =)

Kind regards,

- --
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org

iD8DBQFDuzGiCjAO0JDlykYRAsYxAKCYl+WPqiEWapKTK3Yee//o6Dn58wCfXPh5
JOZOVATPQIMWPgMnHzDuKrg=
=qcxC
-END PGP SIGNATURE-


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

Re: Maintaining a debian package

[Kevin Mark]

On Tue, Jan 03, 2006 at 10:59:12PM +0100, Andi Drebes wrote:
> Hi there!
> I'm currently developing an application for library management (real books,
> CDs, etc). I'd like to distribute it over the internet, because I think it
> could be useful to other users. As I'm using debian and like it pretty
> much, I'd like to add it to the list of packages that debian oficially
> provides. The first problem is, that I don't know how to create
> debian-packages. I even have a lot of problems when creating a distribution
> with automake and autoconf. Well, I'm going to learn it (at least, I hope
> so :)). I'd like to know more about the process of how packages are added
> to the official debian package list.
> 
> Thanks in advance,
> Andi Drebes
> 
> P.S.: Sorry for my bad english - it's not my native language...
Hi Andi,
you may notice that  Debian has many programs to catalog thing. Some for
cd/dvd's, some for books, etc. When you make an ITP you will need to
make an argument as to why this packages should be added. Debian
developers will want to know what differentiates your package from other
similar ones in Debian already. This is not to say that you will be
unable to add your package to debian, but on rare occasions it has been
decided that some packages would not benefit being added. An ITP also
know as an "intent to package" is a request that is sent to the Debian
BTS (bug tracking system) to announce a request to add a package to
Debian. Your next step should be to get familar with Debian by visiting
the debian mentor  website and join the debian-mentors mailing list.
There you will be helped to develop your package so that it can be made
into a '.deb' aka debian package. Once you do this, you will need
someone to sponsor your package. This will allow someone who is a debian
developer to look at your work and if ok, will upload it into Debian.
You IIRC can request a sponsor here.
Cheers,
Kev
ps. If you want some beta tester for your work, you should include a URL
so that folks like me can try your work, assuming you feel it is in a
shape to be tested.
-- 
counter.li.org #238656 -- goto counter.li.org and be counted!
  `$' $' 
   $  $  _
 ,d$$$g$  ,d$$$b. $,d$$$b`$' g$b $,d$$b
,$P'  `$ ,$P' `Y$ $$'  `$ $  "'   `$ $$' `$
$$ $ $$g$ $ $ $ ,$P""  $ $$
`$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$
 `Y$$P'$. `YP $$$P"' ,$. `Y$$P'$ $.  ,$.


signature.asc
Description: Digital signature

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Langasek]

On Tue, Jan 03, 2006 at 08:58:49AM -0600, Steve Greenland wrote:
> On 03-Jan-06, 00:46 (CST), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> > On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> > > If you agree with the change, do Stefano and I need to do anything
> > > other than swap vi alternative priorities and swap important<->optional
> > > priorities?

> > Why swap the vi alternative priorities?

> Because if vim is the default, and someone deliberately installs nvi,
> the presumption is that they prefer nvi, and thus it should grab the vi
> link.

I think that's a pretty bad presumption; to me, it indicates that *someone*
on the system prefers nvi and has requested its installation, but this
doesn't mean it's the preference of either the system administrator or of
the majority of the users.

> Such behaviour is pretty much standard alternative handling: the default
> install is the lowest priority, and the optional variants have higher
> priorities.

> For a single user system, this makes sense. For a multi-user system,
> where the admin might want all of (vim, nvi, vile, whatever) as options
> for the user, it's easy to pick whichever one you want for the default.

OTOH, the admin may not understand the alternatives system, or recognize its
relevance at the time of installing the package (worst case, some other
package pulls it in automatically), which makes for an inconsistent user
experience.

I think the single-user system is the last one that alternatives handling
should optimize for, since the *one* person who's going to know to type
"nvi" instead of "vi", and the one person who can fix the alternatives if he
doesn't like them, is the admin...

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


signature.asc
Description: Digital signature

Re: bits from the release team

[Gabor Gombas]

On Wed, Jan 04, 2006 at 01:10:49AM +0100, Sven Luther wrote:

> But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev
> and it works.

AFAIK it should work with the default ruleset. It breaks only with
certain custom rules due to a bug in the libsysfs version used by udev.

So, if you did not create any udev rules yourself you should be fine.
With old udev and new kernel my rules that map my USB disks to persistent
names under /dev were definitely broken.

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: dependencies on makedev

[Stephen Gran]

This one time, at band camp, Josselin Mouette said:
> Le jeudi 29 décembre 2005 à 21:25 -0600, Adam Heath a écrit :
> > > You edit or add to the udev rules.  These are usually used to set
> > > policy for whole categories of devices, but you can of course fine
> > > tune it, or replace all the standard rules with your own.  The default
> > > gives you all the standard names, as with a static /dev.  (I
> > > personally switched it to the devfs-style rules.)
> > 
> > That's the wrong answer.
> > 
> > What ever happened to standard unix tools?  chmod/mkdir/chown/mv?
> 
> Can you give us a way to change permissions of a device that can be
> plugged or unplugged?

Of course.  With a static /dev/, the node is always there to be operated
on whether or not there is hardware associated with the device node.
You can chmod it whether there is a device plugged in or not.

udev largely solves the problem of 'my /dev tree is ugly with all those
extra things in it'.  Until it also solves all of the problems it brings
with it, and provides an upgrade path better than 'upgrade the kernel
first', I have to remain unconvinced.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
> 
> > On Jan 04, Adam Heath <[EMAIL PROTECTED]> wrote:
> >
> >> Not to mention that 2.6.15 requires a newer udev.  Who knows what other 
> >> newer
> >> things newer kernels might require.
> > OTOH, old kernel are buggy and out of date wrt modern hardware, and we
> > lack the manpower to backport for years fixes and new features RHEL-style.
> > Do you have a better solution?
> 
> Why don't we use RHEL's kernel, or collaborate with them to maintain a
> stable kernel tree, or something?

Why doesn't debian really collaborate with ubuntu on the kernels, which would
be more natural. Debian use mostly the mainline upstream kernels, which is
where everything goes back in anyway, so ...

Friendly,

Sven Luther


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

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 05:28:15PM -0600, Adam Heath wrote:
> Not to mention that 2.6.15 requires a newer udev.  Who knows what other newer
> things newer kernels might require.

Notice that Linus recently expressed on LKML that udev and other userland
breakage on kernel upgrade is not to acceptable, so this would be a bug to be
fixed.

But yes, udev is the problematic case, altough i run 2.6.14 with sarge udev
and it works.

Friendly,

Sven Luther


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

Re: bits from the release team

[Brian Nelson]

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

> On Jan 04, Adam Heath <[EMAIL PROTECTED]> wrote:
>
>> Not to mention that 2.6.15 requires a newer udev.  Who knows what other newer
>> things newer kernels might require.
> OTOH, old kernel are buggy and out of date wrt modern hardware, and we
> lack the manpower to backport for years fixes and new features RHEL-style.
> Do you have a better solution?

Why don't we use RHEL's kernel, or collaborate with them to maintain a
stable kernel tree, or something?

-- 
Captain Logic is not steering this tugboat.


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

Re: bits from the release team

[Frans Pop]

On Wednesday 04 January 2006 00:17, Adeodato Simó wrote:
>   Given that backports.org seems to successfully track kernels on sid
>   already (as per Steinar's comment), and given that I've heard Frans
>   Pop mention the possibility of a sarge d-i update using 2.6.12,

Hmm. That needs a bit of context.
The only way in which the d-i team has so far considered an update of d-i 
for Sarge is if a newer kernel version is officially supported for Sarge.

For us this would be easiest if the new version would be included in a 
point release, but I personally doubt such a proposal would ever pass the 
Stable release manager.

We could also look into this if a new kernel were made part of volatile, 
although that would mean d-i would have to be extended in some places to 
be able to support that.

Still, first requirement is selection of a kernel that will be supported. 
Downside of anything more recent than 2.6.12 is that a lot of structural 
changes in d-i would need to be backported to deal with the removal of 
devfs and to support the new initrd generators.


pgp2ItpXdtkUs.pgp
Description: PGP signature

Re: bits from the release team

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 4 Jan 2006 00:24:04 +0100
Sven Luther <[EMAIL PROTECTED]> wrote:

> > (Without the "current method sucks" comments please; saying "I
> > think the current situation could be improved by..." is much more
> > likely to get positive reactions.)
> 
> This is not my past experience though, and the current method sucks,
> this is a fact, i as powerpc porter of d-i have to live with, so why
> should i not be allowed to express my opinion about this ? 

Because your ignorance of being rude will hurt the conversation - even
if your arguments are sane.


Go ahead and claim that I have no right to say so due to my having a
record of being rude myself. Such reaction would only prove my point
here.


 - Jonas

P.S.

Please do *not* cc me as I am subscribed to d-kernel!

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDuwm8n7DbMsAkQLgRAklqAJ9Tz82+Gw7DjDid2F2cncgsjh2kswCfcZYn
J8jSPC7UpM3ut3Oo/5BXkK4=
=seHD
-END PGP SIGNATURE-

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Christian Marillat]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit :
>> Something troubles me. You make unofficial packages while waiting for 
>> official
>> packages. Aren't you DD ? Wouldn't uploading these unofficial packages
>> in unstable make them official ?
>
> I don't think we need more packages maintained by Christian Marillat.

Moron are still here in 2006. Happy new year...

christian


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

Re: bits from the release team

[Marco d'Itri]

On Jan 04, Adam Heath <[EMAIL PROTECTED]> wrote:

> Not to mention that 2.6.15 requires a newer udev.  Who knows what other newer
> things newer kernels might require.
OTOH, old kernel are buggy and out of date wrt modern hardware, and we
lack the manpower to backport for years fixes and new features RHEL-style.
Do you have a better solution?
(Other than telling people "just use Ubuntu", which is what I do.)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Christian Marillat]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit :
>> Something troubles me. You make unofficial packages while waiting for 
>> official
>> packages. Aren't you DD ? Wouldn't uploading these unofficial packages
>> in unstable make them official ?
>
> I don't think we need more packages maintained by Christian Marillat.

Same apply for you...

Christian


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

Re: bits from the release team

[Marco d'Itri]

On Jan 03, Julien BLACHE <[EMAIL PROTECTED]> wrote:

> I wonder how that's going to happen wrt udev and a couple of other
> things that, as of today, depend on a precise version of the kernel.
udev only depends on a "recent enough" version of the kernel (probably
2.6.15 by the time etch will be frozen) and the upstream maintainers
promised that (modulo bugs) versions >= 072 will be forward-compatible
with new kernel releases.

Anyway, I agree that we should aim to release something better than a
six months old kernel (which sarge showed is often too old).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: bits from the release team

[Adam Heath]

On Tue, 3 Jan 2006, Margarita Manterola wrote:

> On 1/3/06, Sven Luther <[EMAIL PROTECTED]> wrote:
>
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
> > [...]
> > We will have a kernel which is outdated by two versions at release time with
> > this plan, since there are about 1 kernel upstream release every 2 month.
> >
> > So, we will be asking the question about the upgradability of the kernel 
> > later
> > during this release process, and i believe that it is not something which
> > should be ignored. Already you are considering upgrading the sarge kernel
> > which has some trouble booting on a rather non-negligible quantity of
> > hardware, so having a two version outdated kernel at release time is not 
> > nice.
>
> I really don't think that having a four months out-dated kernel is
> that bad.  What is really important is to have stable kernels.  Past
> experience with the modified 2.6 release policy has shown that some
> 2.6 kernels are pretty stable and some others are quite crappy.

Not to mention that 2.6.15 requires a newer udev.  Who knows what other newer
things newer kernels might require.


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

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 06:04:39PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > Indeed. The d-i team usually says "no" outright to any kind of proposal of
> > this kind, so it is up to the kernel team to come up with an implementation
> > which convinces them :) The release team deserves to be informed about the
> > possibility though.
> 
> Cite message-ids or irc logs please.

Such hiding in the sand, ...  well i don't keep irc logs, and you can go
searching for those past email posts as well as i can.
> 
> > Indeed, but you have only the sarge experience to go by, and taking the 
> > sarge
> > experience on this is hardly fair to the huge amount the kernel team has
> > devoted to streamline the process. Also, i don't really believe joeyh and 
> > fjp
> > are really the relevant maintainers with regard to the debian kernel and its
> > application, since they lack the vision of how things could go better, or 
> > more
> > thruthfully, probably lack the time and motivation to think really about the
> > issue, and why should they, it is the kernel team jobs :)
> 
> Understanding how the above paragraph could be perceived as insulting is
> left as an exersise for the reader.

Yeah, and i have mails from you which where degrees of magnitude more
insulting than those, and i have still not forgiven you about the way you
hurt me in april. So tone done your arrogance a bit, please.

Friendly,

Sven Luther


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

Re: bits from the release team

[Sven Luther]

On Wed, Jan 04, 2006 at 12:13:37AM +0100, Frans Pop wrote:
> On Tuesday 03 January 2006 23:52, Sven Luther wrote:
> > The current proposal is about simply using the same .udeb organisation
> > and move it inside the linux-2.6 common package, which is something
> > that works out just fine for ubuntu even, but which the current
> > linux-2.6 common package infrastructure could also handle.
> 
> So, when can we expect a coherent, full proposal (with overview of 
> benefits, possible pitfalls, things that need to be worked out further, 
> and so on) on this in a dedicated mail on a new thread to the relevant 
> mailing lists, so we can actually comment on it instead of only seeing a 
> rough outline mentioned every so often as part of a flame?

The linux-2.6 package will propose a solution which will produce the *EXACT
SAME* set of .udebs as with the current kernel-wedge solution, and will be
more easy to maintain in a more automated way, and integrated with the rest of
the linux-2.6 kernel, so porters only need to do the work once in a single
integrated way.

> (Without the "current method sucks" comments please; saying "I think the 
> current situation could be improved by..." is much more likely to get 
> positive reactions.)

This is not my past experience though, and the current method sucks, this is a
fact, i as powerpc porter of d-i have to live with, so why should i not be
allowed to express my opinion about this ? 

> > The only 
> > reason i saw against this was a mail from joeyh mentioning ease of
> > moving modules around inside .udebs, and that this would be easier
> > under the d-i umbrella than if it is inside the kernel, and naturally
> > the old sarge-time brokeness in the archive infrastructure, which is
> > presumably fixed by now, or should be fixed for etch.
> 
> You forget the argument that when kernel udebs are maintained within d-i, 
> we will be much more likely to spot changes in them as a possible cause 
> of breakage when installation-reports come in.

well, if the only thing you are afraid about is documentation, we shall
provide you with this information in a way most suitable. All this can and and
will be easily automated and presented upon you on a platter, which is not the
case with the current kernel-wedge situation, where the i386 .udebs and
kernel-wedge are updated and the rest of the ports left out in the cold
without any kind of info about possible breakage already fixed on i386, thanks
you very much, so two weights two measures, right ? 

Friendly,

Sven Luther


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

Re: bits from the release team

[Adeodato Simó]

* Steinar H. Gunderson [Tue, 03 Jan 2006 23:34:26 +0100]:

> On Tue, Jan 03, 2006 at 10:45:16PM +0100, Frans Pop wrote:
> > 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
> > starting to get implemented).

> The real question (IMHO) is probably whether it would be possible to get
> newer kernels into volatile. I'd guess "probably not", given that stuff like
> udev tends to break every other release, but it's a tempting thought -- the
> sarge machine here seems to run miles better with a 2.6.14 backport (yay for
> backports.org) than it ever did with 2.6.8 (which seems to have a really
> really unstable USB layer).

  There was a bit discussion about this on d-volatile last week
  (starting at [1]). I think a fair summary of the discussion is:

- from the volatile side of things, Andreas Barth expressed that it
  was probably best to pick one >= 2.6.12 version, stick to it as
  the "newer kernel for sarge until etch releases", and manage to
  get security support for it.

- from the kernel side of things, Sven Luther raised his concerns
  about the uninteresting scenario that for the kernel team would be
  to maintain yet _another_ kernel tree, and proposed to track in
  volatile the kernels from etch, instead of creating a separate
  tree for stable-newer-kernel.

[1] http://lists.debian.org/debian-volatile/2005/12/msg00025.html

  Given that backports.org seems to successfully track kernels on sid
  already (as per Steinar's comment), and given that I've heard Frans
  Pop mention the possibility of a sarge d-i update using 2.6.12,
  perhaps volatile could be the place for security updates for the
  kernel of such d-i update (if one happens, and if they canl't be place
  if the official archive, that is).

  Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Javier Álvarez - ¡Ay, Maricruz!


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

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 06:09:18PM -0500, Joey Hess wrote:
> Sven Luther wrote:
> > And have you added stable-security into the equation ? Your choices of back 
> > in
> > april are in part responsible for the abysmal situation in stable-security
> > with regard to kernels during these past months.
> 
> Pedantically speaking, fjp made no d-i release decisions last April.

Nope, you did, and the "Your" above was meant to be the d-i team.

I also remember you accusing of single-handledly delaying the sarge release by
a week, which was not welcome after i invested almost a week fighthing with
k-p to get the 2.4 ppc kernels in a decent shape for sarge, especially as i
didn't really believe into 2.4 powerpc kernels at that time. Would i have told
you at the start of that week what i would have tried to do, can you honestly
you would have let me do it ? 

But anyway, let's agree to disagree or whatever, and stop hurting each other,
there will be a proposal made in the 2.6.16 timeframe, and we can then speak
again about this.

Friendly,

Sven Luther


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

Re: bits from the release team

[Frans Pop]

On Tuesday 03 January 2006 23:52, Sven Luther wrote:
> The current proposal is about simply using the same .udeb organisation
> and move it inside the linux-2.6 common package, which is something
> that works out just fine for ubuntu even, but which the current
> linux-2.6 common package infrastructure could also handle.

So, when can we expect a coherent, full proposal (with overview of 
benefits, possible pitfalls, things that need to be worked out further, 
and so on) on this in a dedicated mail on a new thread to the relevant 
mailing lists, so we can actually comment on it instead of only seeing a 
rough outline mentioned every so often as part of a flame?

(Without the "current method sucks" comments please; saying "I think the 
current situation could be improved by..." is much more likely to get 
positive reactions.)

> The only 
> reason i saw against this was a mail from joeyh mentioning ease of
> moving modules around inside .udebs, and that this would be easier
> under the d-i umbrella than if it is inside the kernel, and naturally
> the old sarge-time brokeness in the archive infrastructure, which is
> presumably fixed by now, or should be fixed for etch.

You forget the argument that when kernel udebs are maintained within d-i, 
we will be much more likely to spot changes in them as a possible cause 
of breakage when installation-reports come in.


pgpRRzbMYjt34.pgp
Description: PGP signature

Re: bits from the release team

[Joey Hess]

Sven Luther wrote:
> And have you added stable-security into the equation ? Your choices of back in
> april are in part responsible for the abysmal situation in stable-security
> with regard to kernels during these past months.

Pedantically speaking, fjp made no d-i release decisions last April.

If you would like to blame this pendant, you'll need to be a bit more
specific.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: bits from the release team

[Joey Hess]

Sven Luther wrote:
> Indeed. The d-i team usually says "no" outright to any kind of proposal of
> this kind, so it is up to the kernel team to come up with an implementation
> which convinces them :) The release team deserves to be informed about the
> possibility though.

Cite message-ids or irc logs please.

> Indeed, but you have only the sarge experience to go by, and taking the sarge
> experience on this is hardly fair to the huge amount the kernel team has
> devoted to streamline the process. Also, i don't really believe joeyh and fjp
> are really the relevant maintainers with regard to the debian kernel and its
> application, since they lack the vision of how things could go better, or more
> thruthfully, probably lack the time and motivation to think really about the
> issue, and why should they, it is the kernel team jobs :)

Understanding how the above paragraph could be perceived as insulting is
left as an exersise for the reader.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 11:33:44PM +0100, Frans Pop wrote:
> On Tuesday 03 January 2006 23:01, Sven Luther wrote:
> > Indeed. The d-i team usually says "no" outright to any kind of proposal
> > of this kind, so it is up to the kernel team to come up with an
> > implementation which convinces them :)
> 
> Bullshit.
> We (d-i team, mainly Joey) gave very good reasons why we thought the 
> proposal was not good and would result in more problems than it solved.

You did indeed give good reasons why having the one .udeb per module plan i
follhardly proposed would not work.

The current proposal is about simply using the same .udeb organisation and
move it inside the linux-2.6 common package, which is something that works out
just fine for ubuntu even, but which the current linux-2.6 common package
infrastructure could also handle. The only reason i saw against this was a
mail from joeyh mentioning ease of moving modules around inside .udebs, and
that this would be easier under the d-i umbrella than if it is inside the
kernel, and naturally the old sarge-time brokeness in the archive
infrastructure, which is presumably fixed by now, or should be fixed for etch.

I believe that this is indeed an argument, but which is outweighted by the
benefit especially on the port situation, i believe, and the reason i come
back with this times after time :)

> That you choose to structurally ignore the opinions, comments and 
> objections by others who are a lot more knowledgeable about the _other_ 
> area in Debian impacted by the proposal is typical.

Yeah, i am an idiot and you know best, especially when you fail to clearly
understand what i propose and chose to reject it on the basis of what you
think i propose, this is probably due in part to some lacking in my
communication skills, but i guess you also don't make things easy.

> Your half-baked proposals may look good from a kernel maintenance 
> viewpoint, but in our opinion they have a negative impact on the d-i side 
> of the equation.

And have you added stable-security into the equation ? Your choices of back in
april are in part responsible for the abysmal situation in stable-security
with regard to kernels during these past months. Don't look only to save a few
hours of work during the moment, in order to lose huge amounts of times (and
irremediable lose of face even) later on.

> Rejecting a badly thought out proposal is _not_ the same as saying no 
> outright.

Yeah, but you have kept saying to me : it is a stupid idea, don't even think
about it, and then you speak about badly thought out proposal ? 

> I'm not going to repeat the arguments here. They can be found in the 
> archives.

Indeed, apart from the fact that they are the arguments against the wrong
proposal :)

> Your attitude does nothing to motivate me to work on this.

Yep, but i don't ask you to work on this, while you ask me to not work on it
and keep the status quo, which is broken.

Friendly,

Sven Luther



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

Re: bits from the release team

[Steinar H. Gunderson]

On Tue, Jan 03, 2006 at 10:45:16PM +0100, Frans Pop wrote:
> 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
> starting to get implemented).

The real question (IMHO) is probably whether it would be possible to get
newer kernels into volatile. I'd guess "probably not", given that stuff like
udev tends to break every other release, but it's a tempting thought -- the
sarge machine here seems to run miles better with a 2.6.14 backport (yay for
backports.org) than it ever did with 2.6.8 (which seems to have a really
really unstable USB layer).

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


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

Re: bits from the release team

[Frans Pop]

On Tuesday 03 January 2006 23:01, Sven Luther wrote:
> Indeed. The d-i team usually says "no" outright to any kind of proposal
> of this kind, so it is up to the kernel team to come up with an
> implementation which convinces them :)

Bullshit.
We (d-i team, mainly Joey) gave very good reasons why we thought the 
proposal was not good and would result in more problems than it solved.
That you choose to structurally ignore the opinions, comments and 
objections by others who are a lot more knowledgeable about the _other_ 
area in Debian impacted by the proposal is typical.
Your half-baked proposals may look good from a kernel maintenance 
viewpoint, but in our opinion they have a negative impact on the d-i side 
of the equation.

Rejecting a badly thought out proposal is _not_ the same as saying no 
outright.

I'm not going to repeat the arguments here. They can be found in the 
archives.

Your attitude does nothing to motivate me to work on this.


pgp6Ql7CIlWlU.pgp
Description: PGP signature

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 06:26:02PM -0300, Margarita Manterola wrote:
> On 1/3/06, Sven Luther <[EMAIL PROTECTED]> wrote:
> 
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
> > [...]
> > We will have a kernel which is outdated by two versions at release time with
> > this plan, since there are about 1 kernel upstream release every 2 month.
> >
> > So, we will be asking the question about the upgradability of the kernel 
> > later
> > during this release process, and i believe that it is not something which
> > should be ignored. Already you are considering upgrading the sarge kernel
> > which has some trouble booting on a rather non-negligible quantity of
> > hardware, so having a two version outdated kernel at release time is not 
> > nice.
> 
> I really don't think that having a four months out-dated kernel is
> that bad.  What is really important is to have stable kernels.  Past
> experience with the modified 2.6 release policy has shown that some
> 2.6 kernels are pretty stable and some others are quite crappy.

Indeed, but that would be something the kernel team is best placed to decide,
and if a given unstable kernel is crappy, we won't allow it in testing, its
that simple.

> So, I'd say it's better to give some time to be sure that the kernel
> that is shipping with Debian's stable distribution is really a stable
> kernel, and not a crappy one.  I don't think you can tell the
> difference before this version of the kernel reaches a big number of
> people, and therefore, it does need time (frozen, in testing).

Indeed, unstable is such a place, but is 4 month too much of a time to find
out, and would a month or two be enough, i do believe this.

> However, if while preparing the release, the frozen kernel would show
> up as being a crappy one, the release managers might allow for a new
> kernel to enter testing.  But this is only a hypothetical case, and I
> expect it would be carefully evaluated before it actually happened.

The crappy kernel would never enter testing in the first place, as testing has
always been done on unstable. See 2.6.14 is out for over 2 month now, and it
didn't reach testing, and never will now that 2.6.15 is out, because the
devfs/initrd-tool situation, and this was the right thing to do.

Friendly,

Sven Luther


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

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 11:01:03PM +0100, Frans Pop wrote:
> (forgot to CC d-kernel on this)
> 
> On Tuesday 03 January 2006 22:02, Sven Luther wrote:
> > We will have a kernel which is outdated by two versions at release time
> > with this plan, since there are about 1 kernel upstream release every 2
> > month.
> 
> 2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
> starting to get implemented).
> 
> I remember we did consider using 2.6.10 instead of 2.6.8 and decided not 
> to mainly because it was not really that much better than 2.6.8.
> As I remember it, this was a joint decision by the kernel team, release 
> managers and the d-i developers. Not something that the kernel team were 
> really pushing and was blocked by some assholes from the d-i team who did 
> not want to cooperate.

Well, i remember joeyh vetoing it because it would take at least a month to
get the change done, and i believe we didn't really push for it because the
infrastructure was a mess back then. This has changed.

The one point that put me up, is that we should have gotten that security
update in, but this was also vetoed for the same month-long delay in the
kernel/d-i upgrade process. The kernel team has reduced that delay to less
than 24hours now for the release arches, but there is still work to be done on
the d-i side of it, and more specifically with the module .udebs, which could
be uploaded quickly, but rely on the porters doing very unfriendly drudge
work.

My believe is that this kind of thing should be as much automated as possible,
to let the few ressource we have be used where best it should, a little work
at the start which will pay off forever after, this is what computers and
programming is for, to make the task of the users and programmers easier, i
think we all agree with that, or we would still be using boot-floppies :)

> The first kernel after 2.6.8 that was a real improvement was 2.6.12 and 
> that was released definitely too late for Sarge.

Agreed, the issue is the common infrastrucure, and the cost the previous
situation has, and the repercusion of this cost on stable-security.

> > Already it should be possible, provided the d-i guys get their act
> > together, to have a new d-i .udeb sets within 48 hours or less of a new
> > upstream kernel release, altough the image build may take longer, and
> > we hope to get the external modules and patches streamlined by then.
> 
> This is an extremely bad way to get friendly cooperation and discussion 
> about changing anything.

:) Well, we could have released 2.6.15 with .udeb modules included, which
would have been less friendly even.

> Producing new udebs for all architectures for d-i can be done quite fast, 

It could, joeyh even told me it could be easily automated, and Kamion
mentioned me he is already doing part of what is needed for that automation
(namely building module .udebs without installing the kernel images), but upto
now it is still a pain, and takes over a week or two to get done, this was the
case for both 2.6.12, and 2.6.14, and why is that ? Because the porters are
slackers is not really the right reply to this.

> as evidenced by the recent uploads for 2.6.14, provided the porters 
> taking care of the udebs for their architecture . I expect little 
> problems or delay for 2.6.15.

Indeed, and this is the crux of the problem, you put all the responsability on
the porters, while there is really no porter work needed at all. it is only
the nature of the non-unified package that the mainstream arch gets build
quickly, and the non-mainstream arches get bit-rotten until there is an
urgency and the porters get kicked. This is the process problem we are facing,
and i think we can solve in a way satisfactory to the d-i team.

My plan is to come up with something for the 2.6.16 timeframe, which you can
then review, and if it works out well, be used shortly afterward. Etch should
release with 2.6.18 i believe, with the current timeframe, so we have two
versions afterward to sort things out.

> As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for 
> i386.

And exactly this is the bug, and not the feature, it did happen quite fast for
i386, but nobody cared about the other arches, like before the i386 kernel
came out quite fast, but other arches came out with a more or less longer
delay. Compare with same day upload on 9 of the 12 main debian arches ? 

> Yes, we did wait a while before updating to 2.6.14, but that was 
> mainly because d-i itself first had to prepare its userland for the 
> removal of devfs.

The 2.6.12 to 2.6.14 upgrade was indeed very very painful because of the devfs
removal and thus initrd-tools replacement, i am well placed to know about
that.

> So please, get off your hobbyhorse and stop pissing people off with 
> unfounded statements.

He, so, there is no problem, and the situation is perfect, and you prefer to
hide and shoot the messenger :)

Friendly,

Sven Luther



-- 
To UNS

Maintaining a debian package

[Andi Drebes]

Hi there!
I'm currently developing an application for library management (real books,
CDs, etc). I'd like to distribute it over the internet, because I think it
could be useful to other users. As I'm using debian and like it pretty
much, I'd like to add it to the list of packages that debian oficially
provides. The first problem is, that I don't know how to create
debian-packages. I even have a lot of problems when creating a distribution
with automake and autoconf. Well, I'm going to learn it (at least, I hope
so :)). I'd like to know more about the process of how packages are added
to the official debian package list.

Thanks in advance,
Andi Drebes

P.S.: Sorry for my bad english - it's not my native language...


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

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 10:32:12PM +0100, Maximilian Attems wrote:
> On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote:
> > On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
> > 
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
> 
> the kernel is an essential piece of our release,
> makes sense to have it in tune with everchanging userspace interfaces
> (alsa, udev to name a few).

Indeed, that is why it is part of base, but putting it in comparison with the
toolchain (glibc, gcc, etc) is overkill. 

> > > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> > > e.g. cdbs)
> > > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > > freeze, d-i RC]
> > > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> > 
> > We will have a kernel which is outdated by two versions at release time with
> > this plan, since there are about 1 kernel upstream release every 2 month.
> 
> we had the chance for sarge, but we weren't ready.

Due in big part to the messed up kernel situation we inherited from in sarge,
remember i proposed delaying sarge to get the unified kernel infrastructure :)

> for etch we will work for our best to be ready.

indeed.

> please don't rush out such mails without consensual position.

like bow and smile and wait forever ? This is not i believe the debian way of
handling things, and i am certainly not the only one taking this kind of
approach, and much more involved and whatever DDs than me have done it like
that, so ...

Friendly,

Sven Luther


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

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 10:31:38PM +0100, Andreas Barth wrote:
> Hi,
> 
> thanks for your mail. I just want to point out that we published the
> timeline already back in October, but of course, that shouldn't refrain
> us from changing it if this is necessary. :)

Yeah, i was already chidded (?) that my mail was too inflamatory, this was not
the intention, altough i wrote it such to get some reaction upto a point :)

> [re-arranged the quote]
> * Sven Luther ([EMAIL PROTECTED]) [060103 22:03]:
> > On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
> > > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> > > e.g. cdbs)
> > 
> > Why do you put the kernel together with the essential toolchain freeze, it
> > should be together with the rest of base, i believe.
> 
> Hm, I'm quite sure we had some good reason for this; however, I cannot
> really remember why we put the kernel to the essential tool chain. On

:)

> the other hand side, the difference is only one week - and if nothing is
> broken by that, we can freeze the kernel at N-110 also.

i think comparing the kernel with the toolchain is overkill, if nothing else a
last minute change in the toolchain will need a kernel recompile anyway maybe.
I do confess that i read June 30 at first, and this seemed much less
acceptable to me.

> > > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > > freeze, d-i RC]
> > > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> > 
> > We will have a kernel which is outdated by two versions at release time with
> > this plan, since there are about 1 kernel upstream release every 2 month.
> 
> Well, if we want to release with a newer kernel, we need to make sure
> d-i doesn't stumble over it. Experience tells us that there are enough

What experience ? There is no way of common measure between todays situation
and what happened in the pre-sarge timeframe, and we (i, but some of the
kernel team at least agreed with that) fully expect to get things working out
nicely well before the release date, so that there would be a much reduced
impact from the kernel upload on the d-i build schedule. Remember i proposed
the common infrastructure already in marsh/april last year, but was voted done
for the sarge release on it (with some no-kind words even).

The main issue will be one of testing the kernel and d-i built with it, but
there should be no technical hurdles which would cause month-long delays.

> last-minutes changes to the installer that we cannot avoid to better not
> change the kernel; if the installer team (i.e. Joey Hess or Frans Pop)
> tell us otherwise, we can of course adjust our plannings.  However,
> there will be a minimum periode where we just need to freeze everything
> to get enough testing to the proposed release.

Indeed. The d-i team usually says "no" outright to any kind of proposal of
this kind, so it is up to the kernel team to come up with an implementation
which convinces them :) The release team deserves to be informed about the
possibility though.

> Also, the kernel will be outdated sooner or later anyways - so, if after
> one year the kernel is 12 or 14 months old is not too much a difference.

Hehe, me runs sid kernels installed almost as is on all my sarge systems
indeed, just with rebuild yaird and mininmally backported udev. But still, it
is an image issue, and i believe the kernel team would be more happy if the
"obsolet the day it comes out" stigma debian has had in the past doesn't touch
us. Also, you will pay in maintenance cost for those few month difference
during all the etch livetime, guess who will be ending doing this work ? 

> > So, we will be asking the question about the upgradability of the kernel 
> > later
> > during this release process, and i believe that it is not something which
> > should be ignored.
> 
> Well, we as release team first believe what is told us by the relevant
> maintainers. Our current status is that kernel upgrades late in the
> release process (especially after the d-i RC) are rather painfull.

Indeed, but you have only the sarge experience to go by, and taking the sarge
experience on this is hardly fair to the huge amount the kernel team has
devoted to streamline the process. Also, i don't really believe joeyh and fjp
are really the relevant maintainers with regard to the debian kernel and its
application, since they lack the vision of how things could go better, or more
thruthfully, probably lack the time and motivation to think really about the
issue, and why should they, it is the kernel team jobs :)

d-i is only a part of the problem anyway, and i believe the less problematic.
out-of-tree modules and third-party patches are a worse mess.

Friendly,

Sven Luther


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED

Re: bits from the release team

[Julien BLACHE]

Sven Luther <[EMAIL PROTECTED]> wrote:

(sorry for the previous empty posting)

> Already it should be possible, provided the d-i guys get their act together,
> to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel
> release, altough the image build may take longer, and we hope to get the
> external modules and patches streamlined by then.

I wonder how that's going to happen wrt udev and a couple of other
things that, as of today, depend on a precise version of the kernel.

It might not be that easy to upgrade the kernel during the freeze,
unfortunately.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: bits from the release team

[Julien BLACHE]

Sven Luther <[EMAIL PROTECTED]> wrote:

> On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
>> N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
>
> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.
>
>> N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
>> e.g. cdbs)
>> N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
>> N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
>> freeze, d-i RC]
>> N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
>
> We will have a kernel which is outdated by two versions at release time with
> this plan, since there are about 1 kernel upstream release every 2 month.
>
> So, we will be asking the question about the upgradability of the kernel later
> during this release process, and i believe that it is not something which
> should be ignored. Already you are considering upgrading the sarge kernel
> which has some trouble booting on a rather non-negligible quantity of
> hardware, so having a two version outdated kernel at release time is not nice.
>
> Already it should be possible, provided the d-i guys get their act together,
> to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel
> release, altough the image build may take longer, and we hope to get the
> external modules and patches streamlined by then.
>
> Friendly,
>
> Sven Luther

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: bits from the release team

[Maximilian Attems]

On Tue, Jan 03, 2006 at 10:02:05PM +0100, Sven Luther wrote:
> On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
> 
> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.

the kernel is an essential piece of our release,
makes sense to have it in tune with everchanging userspace interfaces
(alsa, udev to name a few).
 
> > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> > e.g. cdbs)
> > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > freeze, d-i RC]
> > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> 
> We will have a kernel which is outdated by two versions at release time with
> this plan, since there are about 1 kernel upstream release every 2 month.

we had the chance for sarge, but we weren't ready.
for etch we will work for our best to be ready.

please don't rush out such mails without consensual position.

-- 
maks


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

Re: bits from the release team

[Frans Pop]

On Tuesday 03 January 2006 22:02, Sven Luther wrote:
> We will have a kernel which is outdated by two versions at release time
> with this plan, since there are about 1 kernel upstream release every 2
> month.

2.6.8 is not an optimal kernel, but largely due to timing (i.e. SATA just 
starting to get implemented).

I remember we did consider using 2.6.10 instead of 2.6.8 and decided not 
to mainly because it was not really that much better than 2.6.8.
As I remember it, this was a joint decision by the kernel team, release 
managers and the d-i developers. Not something that the kernel team were 
really pushing and was blocked by some assholes from the d-i team who did 
not want to cooperate.

The first kernel after 2.6.8 that was a real improvement was 2.6.12 and 
that was released definitely too late for Sarge.

> Already it should be possible, provided the d-i guys get their act
> together, to have a new d-i .udeb sets within 48 hours or less of a new
> upstream kernel release, altough the image build may take longer, and
> we hope to get the external modules and patches streamlined by then.

This is an extremely bad way to get friendly cooperation and discussion 
about changing anything.
Producing new udebs for all architectures for d-i can be done quite fast, 
as evidenced by the recent uploads for 2.6.14, provided the porters 
taking care of the udebs for their architecture . I expect little 
problems or delay for 2.6.15.

As I remember it, the update from 2.6.8 to 2.6.12 was done quite fast for 
i386. Yes, we did wait a while before updating to 2.6.14, but that was 
mainly because d-i itself first had to prepare its userland for the 
removal of devfs.

So please, get off your hobbyhorse and stop pissing people off with 
unfounded statements.


pgpQBmyWehbrh.pgp
Description: PGP signature

Re: bits from the release team

[Andreas Barth]

Hi,

thanks for your mail. I just want to point out that we published the
timeline already back in October, but of course, that shouldn't refrain
us from changing it if this is necessary. :)


[re-arranged the quote]
* Sven Luther ([EMAIL PROTECTED]) [060103 22:03]:
> On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> > N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels
> > N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> > e.g. cdbs)
> 
> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.

Hm, I'm quite sure we had some good reason for this; however, I cannot
really remember why we put the kernel to the essential tool chain. On
the other hand side, the difference is only one week - and if nothing is
broken by that, we can freeze the kernel at N-110 also.


> > N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> > N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> > freeze, d-i RC]
> > N  = Mon  4 Dec 06: release [1.5 months for the general freeze]
> 
> We will have a kernel which is outdated by two versions at release time with
> this plan, since there are about 1 kernel upstream release every 2 month.

Well, if we want to release with a newer kernel, we need to make sure
d-i doesn't stumble over it. Experience tells us that there are enough
last-minutes changes to the installer that we cannot avoid to better not
change the kernel; if the installer team (i.e. Joey Hess or Frans Pop)
tell us otherwise, we can of course adjust our plannings.  However,
there will be a minimum periode where we just need to freeze everything
to get enough testing to the proposed release.

Also, the kernel will be outdated sooner or later anyways - so, if after
one year the kernel is 12 or 14 months old is not too much a difference.


> So, we will be asking the question about the upgradability of the kernel later
> during this release process, and i believe that it is not something which
> should be ignored.

Well, we as release team first believe what is told us by the relevant
maintainers. Our current status is that kernel upgrades late in the
release process (especially after the d-i RC) are rather painfull.


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


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

Re: bits from the release team

[Margarita Manterola]

On 1/3/06, Sven Luther <[EMAIL PROTECTED]> wrote:

> Why do you put the kernel together with the essential toolchain freeze, it
> should be together with the rest of base, i believe.
> [...]
> We will have a kernel which is outdated by two versions at release time with
> this plan, since there are about 1 kernel upstream release every 2 month.
>
> So, we will be asking the question about the upgradability of the kernel later
> during this release process, and i believe that it is not something which
> should be ignored. Already you are considering upgrading the sarge kernel
> which has some trouble booting on a rather non-negligible quantity of
> hardware, so having a two version outdated kernel at release time is not nice.

I really don't think that having a four months out-dated kernel is
that bad.  What is really important is to have stable kernels.  Past
experience with the modified 2.6 release policy has shown that some
2.6 kernels are pretty stable and some others are quite crappy.

So, I'd say it's better to give some time to be sure that the kernel
that is shipping with Debian's stable distribution is really a stable
kernel, and not a crappy one.  I don't think you can tell the
difference before this version of the kernel reaches a big number of
people, and therefore, it does need time (frozen, in testing).

However, if while preparing the release, the frozen kernel would show
up as being a crappy one, the release managers might allow for a new
kernel to enter testing.  But this is only a hypothetical case, and I
expect it would be carefully evaluated before it actually happened.


--
Besos,
Marga

Re: bits from the release team

[Sven Luther]

On Tue, Jan 03, 2006 at 09:24:19PM +0100, Andreas Barth wrote:
> N-117  = Mon 30 Jul 06: freeze essential toolchain, kernels

Why do you put the kernel together with the essential toolchain freeze, it
should be together with the rest of base, i believe.

> N-110  = Mon  7 Aug 06: freeze base, non-essential toolchain (including
> e.g. cdbs)
> N-105  = Mon 14 Aug 06: d-i RC [directly after base freeze]
> N-45   = Wed 18 Oct 06: general freeze [about 2 months after base
> freeze, d-i RC]
> N  = Mon  4 Dec 06: release [1.5 months for the general freeze]

We will have a kernel which is outdated by two versions at release time with
this plan, since there are about 1 kernel upstream release every 2 month.

So, we will be asking the question about the upgradability of the kernel later
during this release process, and i believe that it is not something which
should be ignored. Already you are considering upgrading the sarge kernel
which has some trouble booting on a rather non-negligible quantity of
hardware, so having a two version outdated kernel at release time is not nice.

Already it should be possible, provided the d-i guys get their act together,
to have a new d-i .udeb sets within 48 hours or less of a new upstream kernel
release, altough the image build may take longer, and we hope to get the
external modules and patches streamlined by then.

Friendly,

Sven Luther


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

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Lars Wirzenius]

ti, 2006-01-03 kello 21:06 +0100, Josselin Mouette kirjoitti:
> Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit :
> > Something troubles me. You make unofficial packages while waiting for 
> > official
> > packages. Aren't you DD ? Wouldn't uploading these unofficial packages
> > in unstable make them official ?
> 
> I don't think we need more packages maintained by Christian Marillat.

We could do with fewer character assassinations, too.

-- 
Pity the sysadmin


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

RFA: simulavr: Atmel AVR simulator

[Shaun Jackman]

Package: wnpp
Severity: normal

I no longer use this package myself. It would be better off with a maintainer who does use it.

Cheers,
Shaun

simulavr: Atmel AVR simulator
 simulavr simulates the Atmel AVR family of micro-controllers,
 emulates a gdb remote target, and displays register and memory
 information in real time.

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Josselin Mouette]

Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit :
> Something troubles me. You make unofficial packages while waiting for official
> packages. Aren't you DD ? Wouldn't uploading these unofficial packages
> in unstable make them official ?

I don't think we need more packages maintained by Christian Marillat.

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


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

Bug#345828: ITP: libclass-meta-perl -- Class automation, introspection, and data validation

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libclass-meta-perl
  Version : 0.52
  Upstream Author : David Wheeler <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/~dwheeler/Class-Meta-0.52/
* License : Perl: Artistic/GPL
  Description : Class automation, introspection, and data validation

 Class::Meta provides an interface for automating the creation of Perl classes
 with attribute data type validation. It differs from other such modules in
 that it includes an introspection API that can be used as a unified interface
 for all Class::Meta-generated classes. In this sense, it is an implementation
 of the "Facade" design pattern.
 

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


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

Re: dependencies on makedev

[Josselin Mouette]

Le jeudi 29 décembre 2005 à 21:25 -0600, Adam Heath a écrit :
> > You edit or add to the udev rules.  These are usually used to set
> > policy for whole categories of devices, but you can of course fine
> > tune it, or replace all the standard rules with your own.  The default
> > gives you all the standard names, as with a static /dev.  (I
> > personally switched it to the devfs-style rules.)
> 
> That's the wrong answer.
> 
> What ever happened to standard unix tools?  chmod/mkdir/chown/mv?

Can you give us a way to change permissions of a device that can be
plugged or unplugged?
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


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

Re: something strange with rsh/ssh + bash/tcsh is happening. Please advise

[Henning Makholm]

Scripsit Yaroslav Halchenko <[EMAIL PROTECTED]>

>-c string If the -c option is present, then commands are read
>  from string.  If there are arguments after the
>  string, they are assigned to the positional
>  parameters, starting with $0.

> so - sldkjf (if I read English correctly) should be assigned to $0
> (yikes again). Lets try:

>> cat zzz.sh 
> #!/bin/bash
> echo "#0=$0 #1=$1"

> *> /bin/bash -c /home/yoh/zzz.sh  sldkjf sdf sdf
> #0=/home/yoh/zzz.sh #1=

> so what the hell is right in this situation

Bash behaves as the manual page says. The string is
'/home/yoh/zzz.sh', and every $1 in that string did indeed get
expanded to sdf, after which the command reads '/home/yoh/zzz.sh'.

On the other hand:

$ bash -c 'echo 0=$0 1=$1' sldkjf sdf sdf
0=sldkjf 1=sdf
$ bash -c 'source zzz.sh'   sldkjf sdf sdf
#0=sldkjf #1=sdf
$ 

The argument to the -c option is being interpreted as _a shell script_
itself.

-- 
Henning Makholm  "It will be useful even at this
  early stage to review briefly the main
  features of the universe as they are known today."


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

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Linas Zvirblis]

Debian people are well aware of Ubuntu and their way of doing things. No 
need to point it out.


As for your problem, please post to debian-user or other more apropriate 
mailing list and describe it as precisely as you can. Debian-devel is 
for internal development of Debian.



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

Re: not getting CCs from the bugs I reported

[Henning Makholm]

Scripsit Josselin Mouette <[EMAIL PROTECTED]>
> Le mercredi 28 décembre 2005 à 23:49 -0600, Adam Heath a écrit :

>> You'll only get mails if the sender sends to ###-submitter.
>> Mail sent to just ### is not forwarded, and only stored.

>> This is not a bug in the software, but in the person sending the mail.

> I consider this a bug in the software. It's awkward not to receive some
> communications on a bug you submitted.

I think the theory is that a non-technical user who reports a bug
might not be interested in reading a lot of mail where scary geeks
throw incomprehensible jargon at each other while they figure out
how to fix the problem.

On the other hand, I do not think that most of the bugs in our BTS are
reported by non-technical users. 

-- 
Henning Makholm "This imposes the restriction on any
  procedure statement that the kind and type
 of each actual parameter be compatible with the
   kind and type of the corresponding formal parameter."


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

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Radosław Warowny]

Thanks for your answer, and information you provided.
At the begining I have to make a correction. My happiness last for a
day or two, after that  the problems with gnome, web-browsers, totem
came back (maybe after reboot ? I don't know yet..). I found some more
verbose error message from totem saying something about dbus and
network connection error. I experience similiar problems with pure
testing (fresh install, withoud mixing packages) and mixed
testing+unstable and experimental gnome. I didn't try pure unstable
release yet.

The "unstable" debian distribution name I think could be wrongly
interpreted. "..the first stage of public testing.." sounds a little
better, maybe it could be a good system for me ? Nobody want's to have
something unstable installed.
"Ubuntu" sounds good - there is no negative meaning, it could convince
people to use it although it contains almost the same software as
debian unstable, as you said.
But in fact, isn't it true that ubuntu success (1st place according to
distrowatch.com) is also success of debian ? But does debian
development proft from that ? Maybe it could do something similiar as
ubuntu - release system for desktop users with quite up-to-date
software allowing wider testing or take something back from testing
ubuntu results ?
These are just some ideas, I don't say these are recipes for success.
I think debian should notice ubuntu success and could infer to improve
it's development.
It could make conditions to get more pepole use it and like it (and
maybe even love it).

Best regards
Radek

Re: not getting CCs from the bugs I reported

[James Vega]

On Tue, Jan 03, 2006 at 09:30:44AM -0600, Graham Wilson wrote:
> On Tue, Jan 03, 2006 at 12:58:25PM +0100, Josselin Mouette wrote:
> > Le mercredi 28 d?cembre 2005 ? 23:49 -0600, Adam Heath a ?crit :
> > > You'll only get mails if the sender sends to ###-submitter.  Mail sent to 
> > > just
> > > ### is not forwarded, and only stored.
> > > 
> > > This is not a bug in the software, but in the person sending the mail.
> > 
> > I consider this a bug in the software. It's awkward not to receive some
> > communications on a bug you submitted.
> 
> I sometimes consider it useful. For instance, when someone has submitted
> a patch to the bug, and I am discussing the patch with this individual,
> and not the original submitter of the bug report.

AIUI, that's where <[EMAIL PROTECTED]> comes in handy.  You
could send the email to the bug via that alias and then CC the person
you're discussing the patch with.

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


pgpkbE3C7W7hx.pgp
Description: PGP signature

Re: not getting CCs from the bugs I reported

[Don Armstrong]

On Thu, 29 Dec 2005, Thijs Kinkhorst wrote:

> On Wed, 2005-12-28 at 23:49 -0600, Adam Heath wrote:
> > You'll only get mails if the sender sends to ###-submitter.  Mail sent to 
> > just
> > ### is not forwarded, and only stored.
> > 
> > This is not a bug in the software, but in the person sending the mail.
> 
> I'd consider this a bug in the software, the principle of least surprise
> would suggest that one gets copied on updates to bugs one submits. I've
> seen this on every BTS I've encountered and it makes sense to do so. Of
> course it should be easy to unsubscribe.

See #37078 et al.


Don Armstrong

-- 
In all matters of government, the correct answer is usually: "Do
nothing"
 -- Robert Heinlein _Time Enough For Love_ p428

http://www.donarmstrong.com  http://rzlab.ucr.edu


signature.asc
Description: Digital signature

Re: not getting CCs from the bugs I reported

[Graham Wilson]

On Tue, Jan 03, 2006 at 12:58:25PM +0100, Josselin Mouette wrote:
> Le mercredi 28 d?cembre 2005 ? 23:49 -0600, Adam Heath a ?crit :
> > You'll only get mails if the sender sends to ###-submitter.  Mail sent to 
> > just
> > ### is not forwarded, and only stored.
> > 
> > This is not a bug in the software, but in the person sending the mail.
> 
> I consider this a bug in the software. It's awkward not to receive some
> communications on a bug you submitted.

I sometimes consider it useful. For instance, when someone has submitted
a patch to the bug, and I am discussing the patch with this individual,
and not the original submitter of the bug report.

-- 
gram


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

Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?

[Benjamin Mesing]

Hello,

> > > However due to the QT library transition my package
> > > which I fixed in unstable at once has not entered testing yet...
> 
> packagesearch |  2.0.4 |   testing | source, alpha, ...
> packagesearch |  2.0.4 |  unstable | source, alpha, ...
You are right, the QT library transition is compeleted now.

> I can't see any mention of xterm in packagesearch's changelog, nor any bugs
> filed about the problem, either.
Look at changelog.gz, probably I should have copied it to
changelog.Debian.gz too. Bugs were not filed against this problem. And
to be honest it might _not_ have occured in testing. I've never checked
when xterm changed in its behaviour, and if this xterm version made the
transition before the new version of packagesearch. Also note that it
was only one feature of packagesearch which broke (after all
packagesearch does only recommend xterm and works without it). But my
point was that such (unforseeable) things might break things in testing.

But I have taken the point of the replies. Second hand experience is
nothing I will base my judgement on (and make it public) any more.

So please disregard my statement against "testing"

Best regards Ben

-- 
Please do not send any email to [EMAIL PROTECTED] -- all email not
originating from the mailing list will be deleted. Use the reply to
address instead.


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

Re: Experiment: poll on "switching to vim-tiny for standard vi?"

[Steve Greenland]

On 03-Jan-06, 00:46 (CST), Steve Langasek <[EMAIL PROTECTED]> wrote: 
> On Mon, Jan 02, 2006 at 11:47:05AM -0600, Steve Greenland wrote:
> > If you agree with the change, do Stefano and I need to do anything
> > other than swap vi alternative priorities and swap important<->optional
> > priorities?
> 
> Why swap the vi alternative priorities?

Because if vim is the default, and someone deliberately installs nvi,
the presumption is that they prefer nvi, and thus it should grab the vi
link.

Such behaviour is pretty much standard alternative handling: the default
install is the lowest priority, and the optional variants have higher
priorities.

For a single user system, this makes sense. For a multi-user system,
where the admin might want all of (vim, nvi, vile, whatever) as options
for the user, it's easy to pick whichever one you want for the default.

SteveG

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: How to Increase Contributions from Volunteers

[Zak B. Elep]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Andreas!

On 1/3/06, Andreas Schuldei <[EMAIL PROTECTED]> wrote:
> * Thomas Hood <[EMAIL PROTECTED]> [2006-01-03 12:24:29]:
> > They are right: most probably they will find it easier to make
> > contributions to other projects.
>
> we need to promote the easy entry points to contributing to
> debian more prominently and should hide the "how to become a DD"
> in comparison. we should leave that option for the ones that want
> to contribute above average.

Hm, perhaps something like Corey Burger's HelpingUbuntu wikipage?[1] I
for one would like to see a HelpingDebian page where we could outline
these various points of entry...

... then again, I just noticed DebianContributerProject.[2] Not that I'm
a killjoy, but that ought to be Contributor, not Contributer[3] ;)

[1]  https://wiki.ubuntu.com/HelpingUbuntu
[2]  http://wiki.debian.org/DebianContributerProject
[3]  http://www.dict.org/bin/Dict?Form=Dict2&Database=gcide&Query=Contribute

- --
Zak B. Elep  ||  http://zakame.spunge.org
[EMAIL PROTECTED]  ||  [EMAIL PROTECTED]
1486 7957 454D E529 E4F1  F75E 5787 B1FD FA53 851D

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

iD8DBQFDuo3XV4ex/fpThR0RAuTiAKCHKyeg2VcI7N2l4XRc6OulLEvJ7wCeJyS3
nQChCGkW8u3Xj0b7a025CME=
=osFm
-END PGP SIGNATURE-

Re: Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources

[Robert Millan]

On Tue, Jan 03, 2006 at 12:42:22PM +0100, Josselin Mouette wrote:
> Le jeudi 22 d?cembre 2005 ? 16:51 +0100, Robert Millan a ?crit :
> >  This package contains the FreeBSD 6.x counterparts of some standard build
> >  utilities (make, yacc, lex ..)
> >  .
> >  They have some specific modifications needed to be able to build FreeBSD 
> > 6.x
> >  sources.
> 
> Maybe it's a dumb question, but isn't there a way to patch these tools
> and/or the freebsd sources so that we can build them with the standard
> tools in Debian?

Yes but:

  - In big packages (like kFreeBSD), it's a huge work.
  - Upstream is extremely unlikely to accept patches for that.

-- 
Robert Millan


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

Re: How to Increase Contributions from Volunteers

[Thomas Hood]

Andreas Schuldei wrote:
> we need to promote the easy entry points to contributing to debian more 
> prominently
> and should hide the "how to become a DD" in comparison. we should leave that 
> option
> for the ones that want to contribute above average.


If there is any truth to what Joseph Michael Smidt originally said:

> 1.)All people psychologically want to feel important and that they are an 
> official
> part of an organization.  I feel there should be an official title for all
> contributers so they feel like they are part of the community, not just a 
> pion until
> they get official developer status.

then it might help to reword several pages at debian.org so that they are more
inclusive.  Rename "Developers' Corner" to "Contributors' Corner".  Under "The 
People"
write "This is a comprehensive listing of all the Debian _maintainers_ 
accompanied
with a list of packages they maintain", instead of "...developers..." (which 
would
also be more accurate since non-DD maintainers are already listed).  And so on.
Reword with the principle in mind that there are many contributors to Debian 
who are
not Debian Developers®.
-- 
Thomas Hood

Re: How to Increase Contributions from Volunteers

[Henrique de Moraes Holschuh]

On Tue, 03 Jan 2006, Andrew Vaughan wrote:
> Whats needed is a genuine team of 2-5 suitable new maintainer 'peers' 

[...]

You just described how Alioth-based team maintainership works when it
involves people who aren't DDs, which it often does AFAIK.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: udev event completion order

[Gabor Gombas]

On Mon, Jan 02, 2006 at 08:19:30PM +0100, Adrian von Bidder wrote:

> 'just plug' is the watchword. New device model just needs a reboot - in 
> some circumstances device numbering is random without hardware changes and 
> without software changes.

So it exposes a bug more frequently than before. So why not fix the
bug instead of trying to paper over it forever? As a user, a disk
changing its name if I plug it to a different SATA connector that
happens to be connected to a different chip on the MB is _exactly_ the
same problem as the name change on a single reboot.

Any solution must work equally well for the "plugged in at a different
location" case or it is useless.

Gabor

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

Bug#345769: ITP: locomo -- Logitech Mouse Control for USB mice

[Thibaut VARENE]

Package: wnpp
Severity: wishlist
Owner: Thibaut VARENE <[EMAIL PROTECTED]>

* Package name: locomo
  Version : 1.0
  Upstream Authors: Alexios Chouchoulas <[EMAIL PROTECTED]>
Andreas Schneider <[EMAIL PROTECTED]>
Tobias Schleuss <[EMAIL PROTECTED]>
* URL : http://lomoco.linux-gamers.net/
* License : GPL
  Description : Logitech Mouse Control for USB mice

lomoco can configure vendor-specific options on Logitech USB mice (or
dual-personality mice plugged into the USB port). A number of recent
devices are supported. The program is mostly useful in setting the
resolution to 800 cpi or higher on mice that boot at 400 cpi (such as
the MX500, MX510, MX1000 etc.), and disabling SmartScroll or Cruise
Control for those who would rather use the two extra buttons as ordinary
mouse buttons. It can also retrieve battery level from wireless mice.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (90, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-ck7-bz
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: not getting CCs from the bugs I reported

[Josselin Mouette]

Le mercredi 28 décembre 2005 à 23:49 -0600, Adam Heath a écrit :
> You'll only get mails if the sender sends to ###-submitter.  Mail sent to just
> ### is not forwarded, and only stored.
> 
> This is not a bug in the software, but in the person sending the mail.

I consider this a bug in the software. It's awkward not to receive some
communications on a bug you submitted.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: How to Increase Contributions from Volunteers

[Andreas Schuldei]

* Thomas Hood <[EMAIL PROTECTED]> [2006-01-03 12:24:29]:
> They are right: most probably they will find it easier to make contributions 
> to other
> projects.

we need to promote the easy entry points to contributing to
debian more prominently and should hide the "how to become a DD"
in comparison. we should leave that option for the ones that want
to contribute above average.


signature.asc
Description: Digital signature

Re: Bug#344417: ITP: freebsd6-buildutils -- Utilities for building FreeBSD 6.x sources

[Josselin Mouette]

Le jeudi 22 décembre 2005 à 16:51 +0100, Robert Millan a écrit :
>  This package contains the FreeBSD 6.x counterparts of some standard build
>  utilities (make, yacc, lex ..)
>  .
>  They have some specific modifications needed to be able to build FreeBSD 6.x
>  sources.

Maybe it's a dumb question, but isn't there a way to patch these tools
and/or the freebsd sources so that we can build them with the standard
tools in Debian?

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

Re: How to Increase Contributions from Volunteers

[Thomas Hood]

Joseph Michael Smidt wrote:
>   I believe the greatest barrier the Debian Project has in preventing 
> widespread
> contributions from greater numbers of volunteers is a psychological barrier.  
> I have
> personally introduced Debian to several of my friends and always emphasize 
> the idea
> that they too can contribute to the great cause whether by documentation, 
> translation
> or adopting a package, etc...  Universally they are excited, desire to try it 
> out,
> then come back having read what it takes to be a Debian Developer and are
> overwhelmed.  They then begin searching out other open source projects where 
> it seems
> psychologically they will be able to be more of an assistance.


They are right: most probably they will find it easier to make contributions to 
other
projects.

What is missing from your message is the argument why this should be changed.  
Would it
in fact be a good thing if your friends devoted their time to Debian rather 
than to
those other projects?  It is not obvious to me that that would be better.  The 
"great
cause" is the free software movement as a whole.  Within that movement there 
should be
room for different kinds of projects, including exclusive hobby clubs.
-- 
Thomas Hood


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

Re: spohr.debian.org not sending email

[Stig Sandbeck Mathisen]

Ryan Murray <[EMAIL PROTECTED]> writes:

> exim treats 45x errors to be per host, rather than per address.

That depends on when it gets the error.

If exim gets a timeout or an error message after sending RCPT TO, it
is treated as a recipient error, and not a host error.

http://exim.org/exim-html-4.30/doc/html/spec_43.html#SECT43.2

-- 
Stig Sandbeck Mathisen <[EMAIL PROTECTED]>


pgpgQvpKOU9ZV.pgp
Description: PGP signature

Re: [Listmaster] Seeking petsupermarket

[Marco d'Itri]

On Jan 03, Gene Heskett <[EMAIL PROTECTED]> wrote:

> every legit address I can think of at uol.br.com, with zero bounces, 
> so they are either a damned good black hole, or are well aware of the 
> nuisance they are being and just don't give a starving rats ass.
[X] they are well aware and do not care

-- 
ciao,
Marco


signature.asc
Description: Digital signature