Re: Ubuntu discussion at planet.debian.org

[Andres Salomon]

On Sun, 24 Oct 2004 09:28:20 +0200, Matthias Urlichs wrote:

> Hi, Henrique de Moraes Holschuh wrote:
> 
>> Is there really a developer out there that doesn't do even the most
>> rudimentary VC by keeping copies of all the source packages he has
>> uploaded/worked on ?
> 
> What for? You can always get your old versions from snapshots.debian.net.
> 

*smirk*.  I'm reminded of a quote...

"Only wimps use tape backup: _real_ men just upload their important stuff 
on ftp, and let the rest of the world mirror it"
-- Linus

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[Adeodato Simó]

* José Luis Tallón [Mon, 25 Oct 2004 03:53:46 +0200]:

> Wouter Verhelst wrote:

> >For the sake of consistency, I would suggest kde-theme-$FOO. This is
> >what enlightenment, jsboard, opie, and even previous incarnations of KDE
> >itself use (kdeartwork-theme-*).

  note that the * part is not the theme name, but a further explanation
  of the package contents (e.g., icons, decorations). in fact, packages
  from kdeartwork ship several themes in each package, splitted by
  component-type.

  for non-kdeartwork packages (i.e., not from kde.org), one wants to
  split by origin and ship all components together.

> This is NOT a theme...

  agreed. note to Wouter: I strongly prefer kde-$FOO-style instead of
  using the word theme, since kde uses the word "theme" for something
  different than styles (as baghira).

  as you say, theme is already used by other systems and using it would
  be consistent, but it could confuse kde users making them think the
  package contains what it doesn't. plus, the word "style" is also
  meaningful (at least I perceive it as such).

> the source package is *of course* called 
> Baghira... i assumed kwin-$FOO for a kwin complement made sense. If it 
> does not, i can rename it to simply 'baghira' and be done with it... 
> additional suggestions?

  yes, please consider kde-baghira-style, since it's not only kwin
  decorations that you'll be providing in the package, right? see
  rationale in my other message.

  cheers,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
We may not return the affection of those who like us, but we always
respect their good judgement.

Re: Security updates for sarge?

[Andres Salomon]

On Sat, 23 Oct 2004 05:10:26 +0200, Sven Mueller wrote:

> Heck, If I were a DD, I would be glad to help whereever needed. The most 
> pressing bits seem to be (from my POV):
> 1) buildd network (especially because of sarge/security)
> 2) ftpmaster (seems to be overwhelmed in work for months now)
> 3) new-maintainer process (though it seems to have sped up considerably
> during the last year)

Hah..

> 4) security team (though I'm not sure how bad the situation is)
> 
> So, if my help is wanted with one of the first three of those, I will 
> gladly file a NM application immediately.
> 

Afaict, James processes NM apps alphabetically, by last name.  You can
probably get through the first few stages of NM in a few weeks (It took me
a little over a month, between submitting my app, to getting
Front Desk approval). So, if you applied now and hurried, I'm betting
you'd become a DD before me.  :/

Re: gfreeamp playlist inquiry

[Kevin Mark]

On Sun, Oct 24, 2004 at 11:35:19AM +0200, Ulrich Eckhardt wrote:
> On Saturday 23 October 2004 05:42, Kevin Mark wrote:
> > Your ability to
> > ask for features in the software programs that you use is one of the
> > advantages of libre/free software. 
> 
> Errm, can't you do so with any piece of software out there? The advantage of 
> free software is that you can do it yourself (or hire someone), not just the 
> original author.
> 
> I agree that it's more fun with free software though. :)
> 
> Uli
> 
Hi Uli,
when was the last time adobe or M$ listen to a users request?
how does a user add a feature to photoshop?
I said 'asking for a feature' was ONE advantage. another is fixing it
yourself, as you said.
-Kev
-- 

(__)
(oo)
  /--\/
 / |||
*  /\---/\
   ~~   ~~
"Have you mooed today?"...


signature.asc
Description: Digital signature

Re: Drop testing

[Miles Bader]

"Nikita V. Youshchenko" <[EMAIL PROTECTED]> writes:
>> > IMHO it's somewhat silly to "stop the experiment now" and drop
>> > testing. Although there are problems with testing, there *are*
>> > well-known positives of having it.
>>
>> All the known positives are outweighted by the negative issues as
>> described before.
>
> I don't think so.
>
> For me, existance of testing allows running more-or-less up-to-date systems 
> without facing current development problems with packages/subsystems that 
> I'm not involved in.

Yeah, me too.  I run unstable at work (where I have a fast/reliable net
connection), and testing at home (where I don't).  Testing seem to hit a
sweet spot in the reliability/update-frequency continuum for me.

Now, whether testing does or does not help the "make a new stable release"
problem, I don't know -- but it most certainly _is_ useful for normal
users, and er, aren't they the whole (or at least most of the) point?

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Ubuntu discussion at planet.debian.org

[Andrew Pollock]

On Fri, Oct 22, 2004 at 12:25:48PM +0200, Jérôme Marant wrote:
> Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> writes:
> 
> > On 20041022T134825+0200, Jérôme Marant wrote:
> >> Before "testing", the RM used to freeze unstable and people were
> >> working on fixing bugs. There were pretest cycles with bug horizons,
> >> and freezes were shorter.
> >
> > That's not true (unless you are talking about something that was ceased
> > several years before testing became live, certainly before I started
> > following Debian development in 1998).  Before testing the RM used to
> > fork unstable into a "frozen" distribution.  Unstable was still open for
> > development, and heated arguments developed on this very list asking
> > that the process be changed so that unstable would be frozen; this was
> > never done.
> >
> > I don't know what you mean by "pretest cycles with bug horizons".
> >
> 
> You are correct. It seems so old to me that I didn't even recall
> it was a fork. This indeed explains why that process had to
> be improved. It also explains why the current process needs to
> be improved as well.
> 
> Thanks to Ubuntu, we now have a good example of what's proven
> to work.
> 

I think it is premature to declare that Ubuntu's model works any better than
what we're currently doing, in the long run.

regards

Andrew

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!

Re: Security updates for sarge?

[Andrew Pollock]

On Sat, Oct 23, 2004 at 02:43:18PM -0500, Manoj Srivastava wrote:
> On Sat, 23 Oct 2004 05:10:26 +0200, Sven Mueller <[EMAIL PROTECTED]> said: 
> 
> > Ingo Juergensmann [u] wrote on 22/10/2004 18:35:
> >> On Fri, Oct 22, 2004 at 06:13:46PM +0200, Martin Schulze wrote:
> >> 
> >>> Because they have set up and maintain the buildd network.
> >> Yes, nice, well done, thank them for their initial work, but it
> >> seems as if it's up for others now to take over that job, because
> >> they obviously failing continuously doing it now.
> 
> > I must admit I thought something similar: Why the hell are there
> > only two people who know how to do it, when two people doesn't seem
> > to be enough?
> 
>   Are you volunteering to go out and better educate yourself to
>  take on this work?

I would like to volunteer. Please give me some pointers on how I could
better educate myself, as I have an interest in increasing my understanding
of the "back-end" of what makes the distribution tick.

regards

Andrew

-- 
linux.conf.au 2005   -  http://lca2005.linux.org.au/  -  Birthplace of Tux
April 18th to 23rd   -  http://lca2005.linux.org.au/  -   LINUX
Canberra, Australia  -  http://lca2005.linux.org.au/  -Get bitten!


signature.asc
Description: Digital signature

Re: Bug#277658: ITP: smarty -- Template Engine for PHP

[José Luis Tallón]

Raphaël 'SurcouF' Bordet wrote:
Jose Luis Tallon wrote:
Package: wnpp
Severity: wishlist
* Package name: smarty
  Version : 2.6.5
  Upstream Author : Monte Ohrt <[EMAIL PROTECTED]> & Andrei Zmievski 
<[EMAIL PROTECTED]>
* URL : http://smarty.php.net/
* License : LGPL
  Description : Template Engine for PHP

There're already exist a smarty package in debian: 
http://packages.debian.org/unstable/web/smarty

Why this ITP ?
Because i hadn't seen the package thanks for pointing it out.
Less work for me (i needed it for the ITP of bacula-web). Bug already 
closed. Thanks again.

J.L.

Re: Bug#277582: ITP: kwin-baghira -- A MacOSX-like theme for Apple junkies ;)

[José Luis Tallón]

Wouter Verhelst wrote:
On Fri, Oct 22, 2004 at 04:31:52AM +0200, Adeodato Simó wrote:
 

 I would suggest a name like kde-$FOO-style to be used (e.g.,
 kde-baghira-style) for packages that provide a widget style for
 QT/KDE, and include kwin decoration (if they exist) in the same
 package. (*)
   

For the sake of consistency, I would suggest kde-theme-$FOO. This is
what enlightenment, jsboard, opie, and even previous incarnations of KDE
itself use (kdeartwork-theme-*).
 

This is NOT a theme... the source package is *of course* called 
Baghira... i assumed kwin-$FOO for a kwin complement made sense. If it 
does not, i can rename it to simply 'baghira' and be done with it... 
additional suggestions?

By the way, it is already packaged and works pretty well ( i have been 
using my own packages of baghira for the last 3 months)... it has not 
been uploaded already because my sponsor hasn't got the time to do it yet

Re: Accepted osh 1.7-11woody1 (i386 source)

[Mitch Pope]

settle down, gezz. 2 million emails.

On Mon, 2004-10-25 at 09:41, Matt Zimmerman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Format: 1.7
> Date: Thu, 19 Jun 2003 15:47:22 -0400
> Source: osh
> Binary: osh
> Architecture: source i386
> Version: 1.7-11woody1
> Distribution: stable-security
> Urgency: high
> Maintainer: Oohara Yuuma <[EMAIL PROTECTED]>
> Changed-By: Matt Zimmerman <[EMAIL PROTECTED]>
> Description: 
>  osh- Operator's Shell
> Changes: 
>  osh (1.7-11woody1) stable-security; urgency=high
>  .
>* Non-maintainer upload by the Security Team
>* Apply patch from Steve Kemp to fix buffer overflows (#168383)
> Files: 
>  3af7f1c0c6a346d204c379b1a0c76239 565 shells extra osh_1.7-11woody1.dsc
>  0196364c5ea0afab1c1d3163c40cb1a8 150241 shells extra osh_1.7.orig.tar.gz
>  50c1a6f3a14d5a9a87a0903d01e40f82 11456 shells extra osh_1.7-11woody1.diff.gz
>  dc76617c5ba84467187da2ef53b6b5b9 26734 shells extra osh_1.7-11woody1_i386.deb
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.2 (GNU/Linux)
> 
> iD8DBQE+8hYQArxCt0PiXR4RAk6BAKDRzzD0eypM6UT8+44pX4nlnv5OHACgicpC
> tO9b6hTZXa6vytyE/ClnA40=
> =GSev
> -END PGP SIGNATURE-
> 
> 
> Accepted:
> osh_1.7-11woody1.diff.gz
>   to pool/main/o/osh/osh_1.7-11woody1.diff.gz
> osh_1.7-11woody1.dsc
>   to pool/main/o/osh/osh_1.7-11woody1.dsc
> osh_1.7-11woody1_i386.deb
>   to pool/main/o/osh/osh_1.7-11woody1_i386.deb
> 

Re: Transitioning to Mozilla Firefox 1.0PR

[Eric Dorland]

* Johannes Rohr ([EMAIL PROTECTED]) wrote:
> [Cc'ing to debian-devel. Maybe others want to comment on this. Firefox 
> 1.0x is currently kept out of Sid/Sarge because most translations are 
> not yet available. Therefore Sarge is likely to be released with Firefox 
> 0.9.3]
> 
> Hi,
> 
> the latest news from my upstream is, that they are not going to release 
> a locale package for firefox 0.10 at all. They say they are going to 
> release Firefox 10 RC1 instead which is due 18 October.
> 
> Now, I understand that many other locale packagers have similar probs. 
> What does this mean? What is less unfortunate? Releasing Debian with a 
> totally unsupported development release of firefox or dump the 
> not-yet-updated locale packages instead?
> 
> Personally I'd rather have mozilla-firefox-locale-de removed from Sarge 
> in order to get Firefox 1.0 in! The localization can still be installed 
> through firefox' extension manager anyway.

I'm basically in agreement with Johannes here. I think we're better
served getting a latter firefox in than earlier, translations be
damned :) I'm basically going to upload 0.10.1-1.0PR1 to unstable
unless someone come up with compelling reasons not to. If I can't get
it into sarge then I will certainly make a 0.9.3 release to address
it's issues. 

-- 
Eric Dorland <[EMAIL PROTECTED]>
ICQ: #61138586, Jabber: [EMAIL PROTECTED]
1024D/16D970C6 097C 4861 9934 27A0 8E1C  2B0A 61E9 8ECF 16D9 70C6

-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ 
O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ 
G e h! r- y+ 
--END GEEK CODE BLOCK--


signature.asc
Description: Digital signature

Bug#278128: ITP: tomboy -- Tomboy is a desktop note-taking application for Linux and Unix.

[Eric Gaumer]

Package: wnpp
Severity: wishlist


* Package name: tomboy
  Version : 0.2.2
  Upstream Author : beatniksoftware <[EMAIL PROTECTED]>
* URL : http://www.beatniksoftware.com/tomboy/
* License : LGPL
  Description : Tomboy is a desktop note-taking application for Linux and 
Unix. 
  
  Simple and easy to use, but with potential to help you organize the ideas and 
information you deal with every day.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.4.22-ben2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Re: Ubuntu discussion at planet.debian.org

[Marcelo E. Magallon]

On Sun, Oct 24, 2004 at 01:37:21AM -0500, Manoj Srivastava wrote:

 > > Okay, it's a month old, but there hasn't been any since.
 > > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html
 > > "We are also still missing official autobuilders for
 > > testing-proposed-updates on alpha and mips.  All other architectures
 > > appear to be keeping up with t-p-u uploads."
 > 
 >  Missing a buildd on an arch or too is a far cry from t-p-u
 >  being unsupported.

 Testing is by design all-or-nothing.  As long as a single architecture
 hasn't buildd support for t-p-u, the buildd support for t-p-u is as
 good as missing.  You could do builds by hand, but then again, how many
 developers actually do that?  And it "only" takes a mail to the admin
 team ("please install build dependencies for foo in bar").

 Marcelo

Re: Package names don't matter too much

[Marcelo E. Magallon]

On Thu, Oct 07, 2004 at 05:15:30PM +0200, Frank Küster wrote:

 > There's more to a package name than just being a key to tools. It is
 > the name by which one remembers the software, even when he or she
 > doesn't really know it; it is the name one uses when asking a friend
 > (or Dr. Google) about it.

 Do you realize that you just argued in favor of naming this CDDB?  This
 _is_ the name of this, ehem... bundle.

 Go argue with upstream if you don't like their naming convetions.  I
 certainly don't like krap, it sickens me, but I manage to ignore it.

 > > So this nameing discussion is about what package data should be
 > > mangled into the package name, in this case especially what
 > > dependency data. 
 > 
 > You wanted the discussion to be more general - then please
 > acknowledge that it is not only, or even mainly, about dependencies.
 > I have learned that I don't need to activate some GNUstep desktop to
 > use cddb.bundle or terminal.app, so this is no reason to prepend
 > "gnustep-". 

 For me the easiest method for finding some piece of software for GNOME
 is this:

$ grep-available -s Package -F Depends gtk2 -a -F Description mail
Package: rubrica
Package: gnome-pilot-conduits
Package: gnubiff
...

 which _is_ about dependencies.

 What you keep arguing about is something that is better solved at the
 UI level.

 > There are more reasons, among them the wish to have names that can
 > easily be recognized and memorized, and the wish to have a name that,
 > if it isn't unique, at least makes it possible to distinguish the
 > program from others: Not only in a technical sense, but in human
 > language.

 Yes, that's fine and that's what .app and .bundle are for.

 Marcelo

keysigning in vienna-austria

[Filippo Giunchedi]

Hi,
I'm now in Vienna and I'm wondering if there's someone interested
in keysigning (and/or a coffee and/or a beer), please contact me.
kind regards,
filippo

Re: Release-critical Bugreport for May 14, 2004

[Cord Beermann]

Hallo! Du (Colin Watson) hast geschrieben:

>As far as I can tell, the reports are still being mailed as normal.
>Perhaps a listmaster could investigate why they're not reaching the
>debian-devel-announce readership.

a lot of funny spamassassin-hits pushed the report to junk.

I added a temporary(?) fix, and bounced the latest report to the list.

Sorry for the inconvinience,
Cord


signature.asc
Description: Digital signature

Re: Drop testing

[Steve Langasek]

On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:

> One of the first and most known things: it puts a lot of outdated packages on
> the head of our users! Yes, testing sounds like a good compromise for people
> that want to have bleeding edge software without taking the risk, but we saw 
> in
> the past years that testing created more problems that it was really worth.

Excluding RC bugs and complications, the wait time for a package to reach
testing from unstable is 10 days.  The lifetime of a stable release is much
longer than 10 days, during which time all of those packages are "outdated".
Why is this a criticism of testing, but not of stable?

> Debian Testing is not stable and is not mature. It is full of shitty bugs
> (let me define this term as name for ugly bugs that bother the users but do
> not look appear as critical for maintainer, or not important enough to touch
> package in the holy "frozzen" state). Such bugs are a disaster, they make
> our definition of a Stable release absurd. Yes, Debian Stable has become a
> buggy stable release. Just face it.

This is both an unhelpful, subjective assessment of testing, and not
something that would be fixed by dropping testing.  If there are
undocumented bugs in testing that you consider release-critical, the answer
is for you to file the reports to document them.  If the maintainer
disagrees with you about whether it's release-critical, you can appeal the
question to the release team -- or, better yet, prepare a patch on your own
that's good enough that the maintainer will apply it without any further
need for arguing over severities.

If you're not willing to do the above, or if for whatever reason this
doesn't work, eliminating testing isn't going to help you either.  The bugs
would still be there, whether "there" is named "testing" or "unstable".

So no, I won't "just face it".  If you're not happy with the quality of the
software going into sarge, there is a public BTS available for you to use in
addressing these problems.  Given the declining number of RC bugs open
against sarge, however, I would offer that this is something of a minority
view.

> The major goal (making Freeze periods shorter) was not reached. The second
> goal (faster releases) was not reached. 

There's a lack of useful evidence on this question.  Among the other factors
involved which make it difficult to determine what the effect of testing has
been on release cycles, we have:

  - the number of released architectures
  - the number of packages targetted for the release
  - the number of developers involved who must coordinate among themselves
to bring about a release
  - individual developers' life circumstances and resource committment to
Debian
  - individual RC issues that introduce release delays
  - a very small sample size

The last point is particularly relevant, given that most of sarge has not
frozen yet at all.  While the freeze for base has been much longer than we
might have hoped, for most packages it has had zero impact so far; and we
have every reason to believe that a quick freeze of the rest of the system
will be possible once the current blocking issues are sorted out.

> The third goal (better software quality in the development branch) was not
> reached, at most partially (the users did not have to deal with PAM bugs
> this time, hahaha).

Subjective, not to mention insulting to the efforts of all the developers
who have been doing their part to make sarge a top-quality OS.  Or did you
have statistics on the frequency & fix rate of RC bugs in pre-sarge testing
vs. unstable prior to the introduction of testing?

> So how would the removal of Testing help?
> =

>  - frozen would have better software - more up-to-date upstream versions with
>less ugly upstream/packaging bugs

Unsubstantiated assertion.  The software would be more up-to-date at the
beginning of the freeze, but the freeze would almost certainly last longer
since there would be no way to deal with RC-buggy package versions except
for fixing them or dropping them after the freeze has started; so by the end
of the freeze, the software is likely to be *less* up-to-date.

>  - maintainers would actually be forced to fix 

Er, as opposed to what?

> A possible future model for the release cycle and freze method will be so
> called Tristate freeze model. It consists of three states:

>  - PRE-FREEZE, 2-3 Weeks before the freeze day. A frozen directory is created
>on a dedicated machine and release managers can start testing the freeze
>management scripts. Release team and few selected users should have access
>to this resource. This testing environment is not stable and may (or not) 
> be
>purged before the main freeze begins
>  - MAIN FREEZE: takes three weeks, beginning from the freeze day. Unstable
>branch will be moved to "frozen".  Packages uploaded to "frozen" or
>"unstable" are mapped to "frozen-candidates

Re: Drop testing

[Nikita V. Youshchenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> #include 
>
> * Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
> > > #include 
> >
> > IMHO it's somewhat silly to "stop the experiment now" and drop
> > testing. Although there are problems with testing, there *are*
> > well-known positives of having it.
>
> All the known positives are outweighted by the negative issues as
> described before.

I don't think so.

For me, existance of testing allows running more-or-less up-to-date systems 
without facing current development problems with packages/subsystems that 
I'm not involved in.

For a long time, I use mixed (stable/)tesing/sid systems. Most of packages 
are from testing, sid version is used for a package if testing version 
doesn't fit for whatever reason.

This proved to work very well. I think many developers and technical users 
do the same, if they don't they should probably try it, because it really 
works well. 

In fact, existance of testing allows me to be a user and a developer at the 
same time.

You may state that such reason has nothing to do with release process, for 
which testing was originally proposed. Yes, I agree. However, the above 
argument shows why testing *is useful for real life* even in it's current 
state.

As for role of testing in the release process, I believe there is plenty of 
room to improve.
You write, biggest problem with testing is outdated packages. Yes, probably 
you are right. So, some action should be taken to overcome that. I can't 
immidiatly answer what exact actions will help, but it's a good direction 
to think on. Let's try.
So what makes package's path to testing long?
- - RC bugs. Here nothing else could be done other than fixing the bugs. 
Personally I thing that some infrastructure change could be useful here to 
force maintainers fix RC bugs. Probably any RC bug without activity for 
several (say, 5) days should "become more public", some mechanism should 
be used to encourage non-maintainers to work on the issue.
- - Complex dependency chains. Probably some scheme could be used to decrease 
the effect of those. E.g. build mostly against testing, not against sid, 
and use build-deps from sid only if relly required (what exactly "really 
required" means here, should be defined separately).
- - Arch de-sync. Can't some mix of cross-compilation and more work on 
toolchain issues improve situation here? I'm currently involved in 
dpkg-cross, and I see some interesting possibilities here.
- - What else?

> > Unless such analysis is done, almost any discussion of this topic is
> > pointless. Period.
>
> A-Ha. How long does Testing exists? And why did nobody write this paper
> in the meantime? Why do you not try to do so? I describe the facts. Not
> some imaginary proof that will never see the daylight. Period.

I don't know why nobody did such analysis. (Probably someone did? I'd love 
to read it!)
As for myself, I don't feel I understand the problem deep enough. Although 
I follow debian developent for many years, I'm only becoming to be 
involved :).
I tried to write something just now, see above. I may try deeper analysis 
later, however someone with better understanding of details could do that 
better.

> > But such analysis should be done *after* *sarge* *release*. Flaming
> > now will only postpone the release and do nothing more.
>
> As described before, it is too late to stop this discussion.

Just take action on some RC issue before you write next message to this 
flamewar :). If everybody does that way, having such a flamewar will be 
the most effective BSP in Debian's history :).

To be honest with myself, before writing this mail I've looked through the 
list of current RC bugs, found one that was last posted long ago, and 
submitted some information there that is probably enough to resolve the 
issue. That was bug #274873.


> But many maintainers simply do not care much
> about testing, Unstable runs fine for them.

Do you really think that this is the point? Do you have statistics?

My feeling is that many more maintainers don't take care much about their 
packages, and testing/sid issue has nothing with this. We have currently 
at least hundred of thousands of bugs open. Say, half of those are 
wishlists and probably shouldn't count, but the rest 50,000 are issues 
that require action! Many are open for months and years.

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

iD8DBQFBfA3bv3x5OskTLdsRAu/wAJwOkabMCf7xca0sB5RFEaxPCKverQCgvM9i
HWrXyk6RkAFJhhxenNi3pLk=
=R+6W
-END PGP SIGNATURE-

Re: Ubuntu discussion at planet.debian.org

[Steve Langasek]

On Sun, Oct 24, 2004 at 03:48:04AM -0700, Michael K. Edwards wrote:
> On Sat, 23 Oct 2004 01:04:41 +0200, Jérôme Marant <[EMAIL PROTECTED]> wrote:
> > As soon as testing is strictly equal to unstable regarding package
> > versions, testing is roughly ready for release.

> If Jérôme's observation is correct, then I don't need to worry;
> unstable will converge to a consistent state under the watchful eyes
> of the RM (and many others), testing will rise to meet it, and the
> worst that might happen is that some of the packages I've chosen could
> be excluded from sarge because of a quality problem or an ill-timed
> maintainer absence.

It is not correct.  At the time testing freezes for sarge, there are likely
to be many packages in unstable which either have no version in testing, or
have older versions in testing.  The list of such packages is always visible
at .  While
it's a goal of the release team to ensure that *incidental* issues don't
keep package fixes/updates out of testing, there are plenty of package
updates which will come too late for consideration, or will be RC-buggy in
their own right, that won't be part of sarge.

And immediately *after* the freeze point, I think we can safely expect
unstable to begin diverging even further from testing.

> In this light (and for my purposes), the only sensible place to branch
> stable off from unstable is at a point where the major subsystems are
> all going to be reasonably maintainable on the branch.  Perhaps we're
> close to such a point now and just haven't been for a while, for
> reasons largely beyond the Debian project's control.  (Apart from the
> definition of its "major subsystems", that is; note that Ubuntu
> doesn't expect to be able to provide the level of support for KDE that
> they plan for Gnome, and it appears to me that the effect of changes
> in the C++ toolchain on KDE has been a significant factor in delaying
> sarge.  Do tell me if I'm mistaken about that, but please don't flame
> too hard; I'm not casting aspersions on KDE or g++/libstdc++, just
> recording an impression.)

While getting KDE updates into testing has been a significant task in the
past, I'm not aware of any point during the sarge release cycle when KDE has
been a factor delaying the release.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Ubuntu discussion at planet.debian.org

[Steve Langasek]

On Sun, Oct 24, 2004 at 01:37:21AM -0500, Manoj Srivastava wrote:
> >> This is incorrect, t-p-u is indeed supported by buildds -- though
> >> this paragraph seems to be more like a rant than anything else.

> > Okay, it's a month old, but there hasn't been any since.
> > http://lists.debian.org/debian-devel-announce/2004/09/msg5.html
> > "We are also still missing official autobuilders for
> > testing-proposed-updates on alpha and mips.  All other architectures
> > appear to be keeping up with t-p-u uploads."

>   Missing a buildd on an arch or too is a far cry from t-p-u
>  being unsupported.

Unfortunately, nothing in t-p-u can be safely accepted into testing until
it's been built for all relevant architectures.  While having 9 out of 11
architectures building t-p-u is better than still needing all 11 archs to be
set up for it, the practical, visible impact *today* on testing is the same;
it just means that the "tomorrow" when we can use t-p-u for its intended
purpose is likely a little closer.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#278084: ITP: scim-hangul -- Hangul Input Method Engine for SCIM

[Osamu Aoki]

Package: wnpp
Severity: wishlist

* Package name: scim-hangul
  Version : 0.1.2
  Upstream Author : James Su <[EMAIL PROTECTED]>
* URL : http://www.freedesktop.org/
* License : (GPL2)
  Description : Hangul Input Method Engine for SCIM

 SCIM (Smart Common Input Method) is an input method (IM) platform.
 .
 Hangul Input Method Engine enables SCIM to input Hangul (Korean)
 characters from the keyboard using the plugin modules and the data
 files.
 .
 Author: James Su <[EMAIL PROTECTED]>
 .
 For details about SCIM, please see the description of package scim.

Test package together with all other updated version of SCIM at

 deb http://people.debian.org/~osamu/package/ ./
 deb-src http://people.debian.org/~osamu/package/ ./

This is maintained by few people now as a part of SCIM packages.  
Ming Hua <[EMAIL PROTECTED]> is leading but I do some parts too.

Once pkg-scim at alioth accepted, we will move there.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]>  Brussels Belgium, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract

Bug#278086: ITP: scim-m17n -- M17N Input Method Engine for SCIM

[Osamu Aoki]

Package: wnpp
Severity: wishlist


* Package name: scim-m17n
  Version : 0.1.3
  Upstream Author : James Su <[EMAIL PROTECTED]>
* URL : http://www.freedesktop.org/
* License : (GPL2)
  Description : M17N Input Method Engine for SCIM

 .
 M17N (Multilingualization) Input Method Engine enables SCIM to input
 many non-latin characters from the keyboard using libm17n library.
 .
 Author: James Su <[EMAIL PROTECTED]>
 .
 For details about SCIM, please see the description of package scim.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Test package together with all other updated version of SCIM at

 deb http://people.debian.org/~osamu/package/ ./
 deb-src http://people.debian.org/~osamu/package/ ./

This is maintained by few people now as a part of SCIM packages.
Ming Hua <[EMAIL PROTECTED]> is leading but I do some parts too.

Once pkg-scim at alioth accepted, we will move there.

-- 
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]>  Brussels Belgium, GPG-key: A8061F32
 .''`.  Debian Reference: post-installation user's guide for non-developers
 : :' : http://qref.sf.net and http://people.debian.org/~osamu
 `. `'  "Our Priorities are Our Users and Free Software" --- Social Contract

Re: Drop testing

[Andrew M.A. Cater]

On Sun, Oct 24, 2004 at 08:44:47PM +0200, Gergely Nagy wrote:

> 
> Getting people motivated should not be done in a way that makes - I hope
> - many of them unhappy. To get back to your point - blocking uploads to
> unstable will not make more people concentrate on the release. They'll
> surely find something else that "more fun": it's not "release or
> uploads", it's "release or uploads or something else". Those who do not
> give a damn about the release, will not change their mind when unstable
> is frozen.
> 
> Motivating people means getting them interested in the release, making
> the process "more fun" for them. Or at least less of a nuiseance.
> Freezing unstable will add to the annoyance level, instead of taking
> away from it.

> 
> What you propose places even more burden on the release managers, even
> more stuff to deal with. They will not get motivated by this, not at
> all. Ways to make the current system better - THAT would be very
> welcome. Like enhancing the logic of the testing scripts, which decide
> when and how a package migrates from unstable to testing, so migrations
> could get faster and large blocking stuff could be eliminated, that
> would help the release. Placing burden on people who already have more
> than enough to care and worry about won't help at all, methinks.
> 

> So far, the main complaint against testing is that sometimes packages
> get stuck. *Duh*, so fix the problem that made them stuck. That might
> need some social engineereing, as most of the time, stuckage is not
> caused by technical problems. Would you want to push the same larger
> update into a frozen unstable, you'd run into the very same problems
> anyway.
> 

All of the above makes a very great deal of sense.  I've been around
Debian as a lurker since 1.2 and an active user since 1.3.  Testing
has solved lots of problems.  Stable is _always_ too old after about two
months after release - though point releases do help when they are
allowed to be  made.  Unstable is generally just a fraction too dynamic:
I run unstable on my machines at home because I can fix it - and because 
it's not mission-critical here - but I run testing at work because it's 
had the bugs gradually hammered out of it.  I'm _hoping_ that testing will
get released Real Soon Now so that I can reassure the authorities at
work that the software is stable - it's only a name but a world of
difference and it means I can pass control of one machine to the end
users {B-)  Most users in the Linux User Group that I'm part of 
have aaparently also gradually moved to Debian testing - it works for 
them and various of them have adopted it as they have seen others succeed.

As far as _I'm_ concerned, testing is ready to release as Stable now, modulo 
one or two annoying bugs in the Sparc debian-installer.  On i386 installer 
works fine, on Alpha it's OK.  The installer is pretty much hammered to death
for all architectures.  Testing proposed updates is in place.  If we
just chucked the release out of the door tomorrow as Stable, we'd probably be
at least as ready as we were for hamm/potato/woody IMHO. This is not
insuperable. Debian advocacy is taking up quite a lot of my time at
work, to my boss's annoyance, as I point out that the commercial
distributions don't have the software we need and use :)  Dropping
testing altogether seems at first sight to be an easy option and testing
seems to be an easy target - but it benefits us much more than it hurts.

Now, fresh from flamewars, Ubuntu bashing and threats of GR's - how
close are we to release and can we just f* well do it please??

Andy

Re: Drop testing

[Joey Hess]

Eduard Bloch wrote:
> #include 
> * Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:
> 
> > > not look appear as critical for maintainer, or not important enough to 
> > > touch
> > > package in the holy "frozzen" state). Such bugs are a disaster, they make
> > > our definition of a Stable release absurd. Yes, Debian Stable has become a
> > > buggy stable release. Just face it.
> > 
> > AIUI, you propose to freeze unstable and go back to the old method of
> > having updates during the freeze be manually put in at the discretion of
> > the Release Managers. If we did that, how would one of these "ugly bugs"
> > be any more likely to be fixed in frozen unstable than it is in today's
> 
> a) The release time would be shorter

Proposing a change that will tend to making it harder to have most
packages up-to-date, and then justifying it by saying you hope your
scheme will result in a shorter release time does not seem very wise to
me.

> b) It would be up to humans (and not some obscure scripts) to decide
> whether the bugs deseves a fix or not

No, I'm talking about changes made to frozen packages. Currently these
are added to testing based on human discretion, not via scripts, just as
they would be under your proposal.

> > currently frozen in testing, the situation is exactly what it is now;
> > the maintainer and RM have to decide whether putting this fix into
> > testing (or frozen) and possibly introducing new, more important bugs is
> > warrented by the ugliness of the bug. If the package is one of the large
> > majority of packages that are _not_ currently frozen in testing, then it
> 
> "not currently"? 

Currently only base packages are frozen in testing. If you don't know
this, well..

> In my solution, the whole Sid archive would be frozen.
> And there will be no Testing, see subject.

It seems to me that you have misunderstood my question. Or I do not
understand your reply. The reason I refer to testing in my question in
because I am comparing how things work _now_ with how you propose things
work.

Having a hard time making any sense of what you're saying now; if I
cannot understand your proposal, I will have to object to it.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Drop testing

[Gergely Nagy]

> > >  - unstable lockdown in the freeze
> > >  - drop Testing and concentrate on work instead of wasting time on
> > >synching stuff. This eliminates the need for testing-security. See
> > >the last part of the paper for details.
> > 
> > Doing this would result in many users who currently run testing fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution. I, for one, wouldn't run unstable on my
> > parents' box, whereas testing proved to be quite reliable there.
> 
> Ehm... what is wrong with running stable with backports? Why do you not
> install a such combination for your parents, what is wrong with that?
> 
>  - Missing few important pieces of software? Backport them

That takes some effort, especially when the new version in unstable
build-depends something bigger (I remember how hard it was to backport
some debhelper-using stuff without backporting all of perl - I do not
want to backport large pieces of unstable).

I do not have the time and energy to do those backports. Nor do I want
to upgrade half the system, nor is any security support for backports as
far as I know. Not officially, that's certain. (Yes, there isn't one for
testing either, but most of the case I can just grab the new package
from unstable and be done with it, while it's not that easy using
backports).

And even if I could do it theoretically, J Random User who is running
testing (because stable is too old) would not be able to do the
backports himself, whenever he needs something that is not backported
already.

>  - all the packages are out of date? Well, though luck, this is what the
>whole issue is about. We need to release faster. Faster releases are
>only feasible if enough developers are motivated. They are motivated
>if Unstable is blocked and they must care about the release instead
>of working on stuff that makes "more fun".

No, they are NOT motivated if unstable is frozen. Did we get potato out
sooner than sarge? I don't think so (I may be wrong, though, it was
quite some time ago, and I was only lurking on the lists back then).

I do remember though, that I, as a mere mortal user was very upset about
unstable being frozen. I was running it to get the latest and greatest
software to play with, and when that excitement was taken away I felt a
bit cheated. You take away the toy, and whoever played with it, will
find another one, and since he's angry at you, probably not the
replacement toy you offer. (Ie, freeze unstable and I'm sure to go and
ignore Debian until there's a release - not that I do anything for the
release anyway, so it probably wouldn't matter, but still)

Getting people motivated should not be done in a way that makes - I hope
- many of them unhappy. To get back to your point - blocking uploads to
unstable will not make more people concentrate on the release. They'll
surely find something else that "more fun": it's not "release or
uploads", it's "release or uploads or something else". Those who do not
give a damn about the release, will not change their mind when unstable
is frozen.

Motivating people means getting them interested in the release, making
the process "more fun" for them. Or at least less of a nuiseance.
Freezing unstable will add to the annoyance level, instead of taking
away from it.

> > Freezing unstable will get you nothing compared to what we have now.
> 
> What do we have? Release times reaching eternity? Testing, full of
> hidden / obscure bugs that have not been visible in Sid, or that are
> fixed in Sid but the update got stuck somewhere?

So you propose that those hidden / obscure bugs will only surface when
stable comes out, because there was no testing where they could be
observed earlier? How, pray tell, is that better? How was potato's
release any better than today? Except that the arches had to be kept in
sync "manually", without the help of testing.

For updates, that are important enough but got stuck, there is
testing-proposed-updates. Once there are (security or other)
autobuilders for testing, one uploads a package there, it gets approved,
everyone's happy. Little more work on the maintainer's part, but you'd
have to do roughly the same, would unstable get frozen. With the
additional burden on the release managers that they would need to check
EVERY proposed upload. Now they only need to check a smaller amount of
uploads, since unstable - and even some parts of testing - are open
still.

What you propose places even more burden on the release managers, even
more stuff to deal with. They will not get motivated by this, not at
all. Ways to make the current system better - THAT would be very
welcome. Like enhancing the logic of the testing scripts, which decide
when and how a package migrates from unstable to testing, so migrations
could get faster and large blocking stuff could be eliminated, that
would help the releas

Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support

[Matthew Garrett]

Loïc Minier <[EMAIL PROTECTED]> wrote:

> * Package name: ibm-acpi

This has been integrated into the acpi.sf.net patch, so is fairly likely
to end up in the mainstream kernel before too long.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support

[Loïc Minier]

Matthew Garrett <[EMAIL PROTECTED]> - Sun, Oct 24, 2004:

> This has been integrated into the acpi.sf.net patch, so is fairly likely
> to end up in the mainstream kernel before too long.

 Oh never read of that, do you have some pointers?  Are you sure it's
 the same driver?  Thanks!

   Regards,

[ BTW: your email didn't reach debian-devel, but I see it was Cc:ed, is
  this normal? ]
-- 
Loïc Minier <[EMAIL PROTECTED]>

Bug#278075: ITP: libical0 -- An implementation of basic iCal protocols

[Ricardo Mones]

Package: wnpp
Severity: wishlist


* Package name: libical0
  Version : 0.23
  Upstream Author : Eric Busboom <[EMAIL PROTECTED]>
* URL : http://www.softwarestudio.org/libical/
* License : LGPL/MPL (dual)
  Description : An implementation of basic iCal protocols

 Libical is an mplementation of the IETF's iCalendar Calendaring 
 and Scheduling protocols (RFCs 2445, 2446, and 2447). 
 .
 The current version of libical focuses on creating and
 manipulating iCal objects. With it, you can parse text
 representations of iCal components, add and remove 
 sub-components, properties, parameters and values, and 
 print the components back out as strings.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-k7
Locale: LANG=spanish, LC_CTYPE=spanish (charmap=ISO-8859-1) (ignored: LC_ALL 
set to es_ES)

Re: Ubuntu discussion at planet.debian.org

[Anthony Towns]

On Sat, Oct 23, 2004 at 06:48:31AM +0200, J?r?me Marant wrote:
> There are package that never enter testing and nobody notice because
> everyone use unstable (sometimes because of buggy dependencies).

This isn't true: http://www.debian-administration.org/?poll=3

Sure, it's a tiny enough sample that the "32%" probably isn't terribly
reliable; but heck, even one person is enough to refute a claim of
"everyone", and there are 59 people noted there.

Can we at least avoid being quite so negligent with the truth? Like, say,
not making claims about how many people use testing in the first place,
without getting some actual numbers to back them up?

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Anthony Towns]

On Sun, Oct 24, 2004 at 07:32:18AM +0200, Martin Schulze wrote:
> > You _are_ aware that this is approximately how it was done before woody, no?
> With three 1-month test cycles to get frozen into a reasonable and releaseable
> state?

Eh? potato was frozen on the 16th January, 2000; it was released on
the 15th of August. The freeze itself had originally been planned for
sometime late 1999, but was put on hold a couple of times.

version   codename   freeze-daterelease-date development/freeze

 1.1   buzz  ?  1996/06/17
 1.2   rex   ?  1996/12/12  6 months
 1.3   bo?  1997/06/05  6 months
 2.0   hamm   1998/02?  1998/07/23 8 + 6 = 14 months
 2.1   slink 1998/11/03 1999/03/10 4 + 4 =  8 months
 2.2   potato2000/01/16 2000/08/1510 + 7 = 17 months
 3.0   woody 2002/05/01 2002/07/2020 + 3 = 23 months
  ?sarge ? >2004/10/20>27 months

As far as test cycles are concerned, Richard proposed them on 1999/12/28,
with the first one scheduled for 2000/01/22, hoping that two would be
needed. Test cycle one began 2000/05/02 and ended with test cycle two.
Test cycle two began 2000/05/30 and ended 2000/06/24. Test cycle three
began 2000/07/06 and ended with the release, more or less. The start
of the test cycles were delayed due to boot-floppies not being ready,
and consisted of some "bug horizons", and other miscellania. Note that
for the entire period from January to August, _no_ packages were added
or updated in potato without inspection by the release manager; with
new features and non-RC bug fixes generally being immediately rejected.
That's where the feeling that stable is 7 months out of date before it's
even release comes from.

For hamm, slink and potato, we needed to spend around 43% of our time
frozen, working solely on fixing RC bugs. "Three one-month test cycles"
simply isn't an accurate summary of what freezing Debian entails.

YMMV on the woody "freeze" date; I'm choosing the date when britney stopped
running, but it's also worth considering packages that were uploaded but
"blocked" for various reasons, and updates that weren't uploaded because
we were trying to release.

Note that when considering the latter, updates for potato were also
"discouraged" for a month or two before the actual freeze; see [0], eg.
At present, the only packages not automatically propogating to testing
are packages in base. Even things as large as Gnome 2.6 have made it
into testing since May.

I'm tempted to say "What, then, are our choices? Note that `Release every
six months, at absolutely no cost' isn't one of them", but actually it
is: we can just grab whatever the Ubuntu guys put out and stick it in
our archive, at so close to zero cost as to be indistinguishable. That's
not quite a "Debian stable release", however -- it doesn't support as
many packages, or as many architectures; so maybe there is a cost even
then.

But "freeze, sweat blood fixing bugs, release" isn't a magic formula:
it results in spending over 40% of our time sweating blood rather than
doing fun stuff, and it still takes ages to actually do, given the size
of the distribution we have. And the freeze period is usually spent
screwing up unstable completely too, which creates yet more work for
the next time round (because everyone's testing frozen, bugs in unstable
get left to sit there for months, which makes them harder to fix because
whoever was working on them forgets, or moves on).

Note that warty/main is about 1/17th the size of Debian (which probably
underestimates the difference in complexity, if complexity isn't a linear
function of size), and that, conservatively, it has probably a hundred
times the direct funding Debian has -- though Debian might well surpass
Ubuntu if you also count indirect funding, but I've no idea how you'd
manage that.

Of course, the other problem with talk of a Debian freeze is finding
someone willing to manage it -- the last freeze we had was potato,
which managed to fairly thoroughly burn out Richard Braakman, and I
think we're something like four times bigger now than we were then,
just counting packages; another factor of two if you count architectures
(aiming for a factor of three).

Cheers,
aj

[0] http://lists.debian.org/debian-devel-announce/1999/11/msg0.html

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Anthony Towns]

On Sun, Oct 24, 2004 at 03:53:23PM +0400, Nikita V. Youshchenko wrote:
> > #include 
> Yes, there are problems with current scheme. So one should write down the
> facts and do a careful, in-detail, emotion-less analysis of each problem
> and it's reasons. 

Trivial analysis:

* One of Testing's goals was to be 95% releasable at all times.
* It hasn't been.
* Why not?
   (a) RC bugs
   (b) Can't install it
   (c) Security vulnerabilities
* How can these be solved?
   (a) (1) Pro-active removals by release managers,
   (2) More bug fixing in unstable
   (3) Bug fixing specifically for testing
   (b) (1) Developing a maintainable installer
   (c) (1) Doing security updates for testing
   (2) Doing better security updates in unstable, 
and getting them into testing quickly

The release managers have been putting some effort into (a)(1) over the
past year, and there's four of them now instead of just one. How much effort
has the project been putting into the other factors?

> One such analysis is done and made public, most likely a
> solution will be found that is much less radical than killing everything,

Non-radical solutions don't let you write a general resolution, however.

> But such analysis should be done *after* *sarge* *release*. Flaming now will
> only postpone the release and do nothing more.

For comparison, testing was designed during a flamewar a month or two
before hamm's release. Well, extensive discussion is a far more accurate
description than flamewar -- in particular, I don't believe there was any
blame involved, whether on a person, process or tool. I may be mistaken.
Of course, there was pretty much nothing unconventional about our release
process at the time.

> Probably there are non-technical problems with the uncoming release. But
> there are technical problems also, yes? Why not eliminate those? If instead
> of each mail in this thread a single RC bug that affects sarge was fixed,
> probably there could be *zero* such bugs now.

Why not do both? Every time you post a mail to a thread like this, fix an
RC bug. This is the "ObBug:" rule.

ObBug: 275585

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

``[S]exual orgies eliminate social tensions and ought to be encouraged.''
  -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod)


signature.asc
Description: Digital signature

Re: Drop testing

[Eduard Bloch]

#include 
* Wouter Verhelst [Sun, Oct 24 2004, 11:41:33AM]:

> > Very few bug reports from testing users are of any value at all.
> 
> I respectfully disagree here.
> 
> With most of my packages, bugs get filed only when the transition to
> testing has been complete for quite a while already, except when the bug
> is a /really/ severe one (severity grave or critical).

Counter example: you fix a bug in Sid but insufficiently (and you do not
know for sure). Few users continue reporting bugs in the Testing
version. You ask them to test the Sid version. But Sid scares them and
they promise to wait for the update to be in Sid. Then, you will wait
weeks for the acknoledgement and the bug may still be in Testing in this
time. And it will take another two weeks for a real fix to slip into
Testing.

That is not fun. That is overhead which creates confusion.

Regards,
Eduard.
-- 
In the beginning was the word, and the word was content-type: text/plain

Re: Drop testing

[Eduard Bloch]

#include 
* Marco d'Itri [Sat, Oct 23 2004, 10:06:24PM]:
> On Oct 23, Eduard Bloch <[EMAIL PROTECTED]> wrote:
> 
> > ABSTRACT
> You are trying to force developers to work on item x, which they dislike,
> by forcing them to not work on item y, which they like more. You are
> apparently oblivious to the fact that most developers will probably
> spend their time on item w (which is probably not a Debian task), which

At least they won't poison Sid with fresh things that may others life
more difficult. Eg. new library versions.

> they like less than x but still more than y. So this will at least fail,
> and probably hurt debian too.

Maybe. What is the alternative? Continue with the current method and
release Edge... 2009 or so?

Regards,
Eduard.
-- 
Everything is illusion. Constructs of language, light, metaphor; nothing
is real.  -- Babylon 5, Season 4

Re: Drop testing

[Eduard Bloch]

#include 
* Joey Hess [Sat, Oct 23 2004, 08:36:18PM]:

> > not look appear as critical for maintainer, or not important enough to touch
> > package in the holy "frozzen" state). Such bugs are a disaster, they make
> > our definition of a Stable release absurd. Yes, Debian Stable has become a
> > buggy stable release. Just face it.
> 
> AIUI, you propose to freeze unstable and go back to the old method of
> having updates during the freeze be manually put in at the discretion of
> the Release Managers. If we did that, how would one of these "ugly bugs"
> be any more likely to be fixed in frozen unstable than it is in today's

a) The release time would be shorter
b) It would be up to humans (and not some obscure scripts) to decide whether 
the bugs deseves a fix or not

Yes, some manpower would be required for this process. But fellow
maintainers could be involved into process of evulation of the quality
of a proposed upgrade.

> currently frozen in testing, the situation is exactly what it is now;
> the maintainer and RM have to decide whether putting this fix into
> testing (or frozen) and possibly introducing new, more important bugs is
> warrented by the ugliness of the bug. If the package is one of the large
> majority of packages that are _not_ currently frozen in testing, then it

"not currently"? In my solution, the whole Sid archive would be frozen.
And there will be no Testing, see subject.

Regards,
Eduard.
-- 
For any stupid thing chosen at random, you'll find at least 5 people on
the Internet who thinks it's a good idea. -- Steve Langasek in debian-devel

Re: Drop testing

[Eduard Bloch]

#include 
* Steinar H. Gunderson [Sat, Oct 23 2004, 10:36:16PM]:

> >  - unstable lockdown in the freeze
> >  - drop Testing and concentrate on work instead of wasting time on
> >synching stuff. This eliminates the need for testing-security. See
> >the last part of the paper for details.
> 
> You _are_ aware that this is approximately how it was done before woody, no?

Similar to those and more aggressive. Didn't I write this already?

Regards,
Eduard.
-- 
Junggesellen sollten hohe Steuern zahlen. Es ist nicht gerecht, daß
einige Männer glücklicher sein sollen als andere.
-- Oscar Wilde

Re: Drop testing

[Eduard Bloch]

#include 
* Gergely Nagy [Sat, Oct 23 2004, 10:44:58PM]:

> >  - unstable lockdown in the freeze
> >  - drop Testing and concentrate on work instead of wasting time on
> >synching stuff. This eliminates the need for testing-security. See
> >the last part of the paper for details.
> 
> Doing this would result in many users who currently run testing fall
> back to stable + backports or switch to another distro (ubuntu being a
> likely candidate), which in turn, would result in less bugreports and a
> less stable distribution. I, for one, wouldn't run unstable on my
> parents' box, whereas testing proved to be quite reliable there.

Ehm... what is wrong with running stable with backports? Why do you not
install a such combination for your parents, what is wrong with that?

 - Missing few important pieces of software? Backport them
 - all the packages are out of date? Well, though luck, this is what the
   whole issue is about. We need to release faster. Faster releases are
   only feasible if enough developers are motivated. They are motivated
   if Unstable is blocked and they must care about the release instead
   of working on stuff that makes "more fun".

> Freezing unstable will get you nothing compared to what we have now.

What do we have? Release times reaching eternity? Testing, full of
hidden / obscure bugs that have not been visible in Sid, or that are
fixed in Sid but the update got stuck somewhere?

> Those who don't care about a release, will not care that way either,
> just their complaints will get louder and more frequent. Those who are

How should they complain? "We cannot update foo in Sid because it has
been frozen for three weeks now, nya, nya". The answer would be some
analogue to RTFM (HTFR, help the f... release).

> willing to do the work neccessary for the release are already trying to

Re: Drop testing

[Eduard Bloch]

#include 
* Nikita V. Youshchenko [Sun, Oct 24 2004, 03:53:23PM]:
> > #include 
> 
> IMHO it's somewhat silly to "stop the experiment now" and drop testing.
> Although there are problems with testing, there *are* well-known positives
> of having it.

All the known positives are outweighted by the negative issues as
described before.

> Yes, there are problems with current scheme. So one should write down the
> facts and do a careful, in-detail, emotion-less analysis of each problem
> and it's reasons. One such analysis is done and made public, most likely a
> solution will be found that is much less radical than killing everything,
> and still eliminate the problems, or make the problems smaller.
> 
> Unless such analysis is done, almost any discussion of this topic is
> pointless. Period.

A-Ha. How long does Testing exists? And why did nobody write this paper
in the meantime? Why do you not try to do so? I describe the facts. Not
some imaginary proof that will never see the daylight. Period.

> But such analysis should be done *after* *sarge* *release*. Flaming now will
> only postpone the release and do nothing more.

As described before, it is too late to stop this discussion.

> Probably there are non-technical problems with the uncoming release. But

There are, as described before. For example, I cannot see any life sign
of our FTP masters. How comes?

> of each mail in this thread a single RC bug that affects sarge was fixed,
> probably there could be *zero* such bugs now.

If we would fix the bugs in the distribution that is to be released,
there would be *zero* now. But many maintainers simply do not care much
about testing, Unstable runs fine for them. That is why a refered Joel
on Software, RTF paper. Please.

Regards,
Eduard.
-- 
Wie man sein Kind nicht nennen sollte: 
  Flora Soft 

Re: Security updates for sarge?

[Ingo Juergensmann]

On Sun, Oct 24, 2004 at 01:14:25PM +0100, Matthew Garrett wrote:

> > IIRC, you're one of those Ubuntus, right? No more to be said then... 
> I am not an employee of Canonical, and nor have I ever been.

Ok, sorry then for that point. 

-- 
Ciao...  // 
  Ingo \X/

Re: Release-critical Bugreport for May 14, 2004

[Jose Carlos Garcia Sogo]

El dom, 24-10-2004 a las 09:14 +0200, Andreas Tille escribiÃ:
> On Sun, 24 Oct 2004, Petter Reinholdtsen wrote:
> 
> > Did these reports stop, or is there something wrong with my email?
> > The last one I could find in my debian-devel-announce mail folder is
> > from 2004-05-14.
> This is what I wondered every week but was to lazy to ask.  Either something
> is broken or our both email systems are broken.

  AFAIK, no one is receiving that mail. It must have been eaten
somewhere in the MXs or list servers.

  Regards,

-- 
Jose Carlos Garcia Sogo
   [EMAIL PROTECTED]


signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada	digitalmente

Bug#278045: ITP: vdr-plugin-console -- Plugin for vdr that implements a virtual terminal

[Thomas Schmidt]

Package: wnpp
Severity: wishlist

* Package name: vdr-plugin-console
  Version : 0.5.1
  Upstream Author : Jan Rieger <[EMAIL PROTECTED]>
* URL : http://ricomp.de/vdr/
* License : GPL
  Description : Plugin for vdr that implements a virtual terminal

 This plugin for vdr implements a virtual terminal, that can be 
 displayed by vdr's OSD, it allows you to display and control 
 allmost every console application.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: [EMAIL PROTECTED], LC_CTYPE=iso_8859_15 (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])

Re: Ubuntu discussion at planet.debian.org

[Martin Schulze]

Mike Hommey wrote:
> On Sun, Oct 24, 2004 at 07:53:27AM +0200, Martin Schulze wrote:
> > Err...  experimental ABI changes are for experimental.  Confirmed ABI
> > and API changes are for unstable (or whatever you want to call the
> > development branch).  We must not hide those changes from the future
> > stable distribution since it was done and confirmed upstream.
> 
> Are you saying you would go with a (for instance) gcc ABI change right
> now (i.e. while trying to release) in unstable if there was one ?

As somebody said, the world is not binary.  This also has to be decided
on a per-use case.  Hence, I cannot provide a yes/no answer to this general
question.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

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

Re: Drop testing

[Nikita V. Youshchenko]

> #include 

IMHO it's somewhat silly to "stop the experiment now" and drop testing.
Although there are problems with testing, there *are* well-known positives
of having it.

Yes, there are problems with current scheme. So one should write down the
facts and do a careful, in-detail, emotion-less analysis of each problem
and it's reasons. One such analysis is done and made public, most likely a
solution will be found that is much less radical than killing everything,
and still eliminate the problems, or make the problems smaller.

Unless such analysis is done, almost any discussion of this topic is
pointless. Period.

But such analysis should be done *after* *sarge* *release*. Flaming now will
only postpone the release and do nothing more.

Probably there are non-technical problems with the uncoming release. But
there are technical problems also, yes? Why not eliminate those? If instead
of each mail in this thread a single RC bug that affects sarge was fixed,
probably there could be *zero* such bugs now.

Re: Security updates for sarge?

[Matthew Garrett]

Ingo Juergensmann <[EMAIL PROTECTED]> wrote:

> IIRC, you're one of those Ubuntus, right? No more to be said then... 

I am not an employee of Canonical, and nor have I ever been.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Bug#278035: ITP: vdr-plugin-remote -- Plugin for vdr to support the built-in remote control port of DVB-Cards

[Thomas Schmidt]

Package: wnpp
Severity: wishlist

* Package name: vdr-plugin-remote
  Version : 0.3.1
  Upstream Author : Oliver Endriss <[EMAIL PROTECTED]>
* URL : http://endriss.escape.bei.t-online.de/vdr
* License : GPL
  Description : Plugin for vdr to support the built-in remote control port 
of DVB-Cards

 This plugin for vdr supports the built-in remote control 
 port of some DVB-Cards or CI-Modules.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.9
Locale: [EMAIL PROTECTED], LC_CTYPE=iso_8859_15 (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])

RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.

[Oded Shimon]

Hi.

This is no longer an RFS, I posted this RFS here quite a while ago, this is 
now a "plea" for: What should I do?


My program is an MEncoder frontend which depends on MPlayer, if I am not 
mistaken, that means it belongs in contrib. I have completed a Debian 
package, have been looking for a sponsor for quite some time, I have tried 
asking here, in debian-mentors, in several other relevant debian mailing 
lists, and in the IRC channel, and got for it one useful reply, to contact 
Marillat.
Thanks to him, my program is now up at the unofficial archives at 
http://hpisi.nerim.net/ , for which I am very grateful.

My question is, at this point, is there any chance my program will be in the 
official Debian archives (in section contrib)? Is there anything else I 
should try to find a sponsor?...

- ods15

Bug#278027: RFP: ibm-acpi -- Driver for IBM laptops to extend ACPI support

[Loïc Minier]

Package: wnpp
Severity: wishlist

* Package name: ibm-acpi
  Version : 0.7
  Upstream Author : Borislav Deianov <[EMAIL PROTECTED]>
* URL : http://ibm-acpi.sourceforge.net/
* License : GPL
  Description : Driver for IBM laptops extending ACPI support on Linux

This driver extends the ACPI subsystem of IBM Thinkpads running Linux to
support new features that wouldn't otherwise be available.

Re: Ubuntu discussion at planet.debian.org

[Michael K. Edwards]

On Sat, 23 Oct 2004 01:04:41 +0200, Jérôme Marant <[EMAIL PROTECTED]> wrote:
> As soon as testing is strictly equal to unstable regarding package
> versions, testing is roughly ready for release.

I think this observation is acute -- as applied to the _current_
"testing" mechanism.

Personally, I view "testing" as a QA system for the release process,
not a sensible distribution for anyone (developer or end user) to be
running on a "real" system.  My understanding of the mechanism by
which packages propagate into testing is that there's only one
interesting thing about it: the _reason_ why any given package fails
to propagate.  The automated dependency analysis takes some of the
personality conflicts out of the assessment of the release status, and
provides macroscopic milestones (systematic transition to library X,
version upgrade to desktop suite Y) during a certain phase of the
release cycle.

I am in the interesting position of serving as buildmaster for an
"appliance" incorporating a snapshot of a subset of Debian unstable. 
(I may perhaps deserve some flamage for not keeping up communication
with the Debian project while working on this, more or less in
isolation.  Allow me to plead that the pressure of circumstances has
been rather intense, and I am hoping that recent management changes
will result in more follow-through on promises of return contributions
of time and other resources.)

Perhaps I've just been lucky, but I haven't had any technical trouble
at all due to the choice of "unstable".  The only issue I encountered
was an upstream-induced regression in MySQL 4.0.21, which would have
hit me anyway (we bought MySQL's commercial support contract, but I
have no desire to ship any bits that haven't been through the hands of
the Debian packager, who seems to be on top of the situation). 
snapshot.debian.net was a real lifesaver on this one, allowing me to
choose the particular historical version I wanted for the affected
packages.

When sarge releases, I'm going to want to be able to sync the boxes in
the field up to sarge so that they can participate in the "stable"
security maintenance process.  In the best of all possible worlds, I'd
have some guarantee that sarge will contain package versions no lower
than today's unstable, at least for the packages I'm bundling.  But I
don't think it's at all reasonable to expect that kind of a guarantee,
and I'm just going to have to do my own QA on the upgrade/downgrade
process from the snapshot I've chosen to the eventual "golden" sarge.

If Jérôme's observation is correct, then I don't need to worry;
unstable will converge to a consistent state under the watchful eyes
of the RM (and many others), testing will rise to meet it, and the
worst that might happen is that some of the packages I've chosen could
be excluded from sarge because of a quality problem or an ill-timed
maintainer absence.  This would be an inconvenience but hardly grounds
for complaint about Debian's release process.

In this light (and for my purposes), the only sensible place to branch
stable off from unstable is at a point where the major subsystems are
all going to be reasonably maintainable on the branch.  Perhaps we're
close to such a point now and just haven't been for a while, for
reasons largely beyond the Debian project's control.  (Apart from the
definition of its "major subsystems", that is; note that Ubuntu
doesn't expect to be able to provide the level of support for KDE that
they plan for Gnome, and it appears to me that the effect of changes
in the C++ toolchain on KDE has been a significant factor in delaying
sarge.  Do tell me if I'm mistaken about that, but please don't flame
too hard; I'm not casting aspersions on KDE or g++/libstdc++, just
recording an impression.)

To me, the miracle is that a "stable" distribution is possible at all,
given human nature and the scope of the Debian archive.  The old adage
about sausage and the law goes double for software, perhaps because
it's a sort of sausage (a composite product of many, er, committed
contributors) stuffed with law (part logic and part historical
circumstance).  I have to admit that it takes a strong stomach to
watch the sausage being made and then eat it anyway, but it helps to
focus on how much better it is than one's other options in sausages. 
That's still how I feel about Debian, with good reason.

Cheers,
- Michael

Re: Release-critical Bugreport for May 14, 2004

[Steinar H. Gunderson]

On Sun, Oct 24, 2004 at 11:08:32AM +0100, Colin Watson wrote:
> As far as I can tell, the reports are still being mailed as normal.
> Perhaps a listmaster could investigate why they're not reaching the
> debian-devel-announce readership.

Perhaps they hit the maximum message size or something?

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

Re: Release-critical Bugreport for May 14, 2004

[Mike Hommey]

On Sun, Oct 24, 2004 at 12:34:54PM +0200, Wouter Verhelst wrote:
> They are; I received one just last week.
> 
> If they're not reaching you, I suggest you check your d-d-a subscription
> and/or your spam filter.

How did you receive a mail to d-d-a which is not even in the archive ?
http://lists.debian.org/debian-devel-announce/2004/10/index.html
http://lists.debian.org/debian-devel-announce/2004/09/index.html

Mike

Re: Release-critical Bugreport for May 14, 2004

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 12:34:54PM +0200, Wouter Verhelst wrote:
> On Sun, Oct 24, 2004 at 11:08:32AM +0100, Colin Watson wrote:
> > On Sun, Oct 24, 2004 at 01:26:09AM +0200, Petter Reinholdtsen wrote:
> > > [BugScan reporter]
> > > > Bug stamp-out list for May 14 06:01 (CST)
> > > >
> > > > Total number of release-critical bugs: 565
> > > > Number that will disappear after removing packages marked [REMOVE]: 1
> > > > Number that have a patch: 79
> > > > Number that have a fix prepared and waiting to upload: 22
> > > > Number that are being ignored: 14
> > > > Number on packages not in testing: 200
> > > > Number concerning the next release (excluding ignored and 
> > > > not-in-testing): 274
> > > 
> > > Did these reports stop, or is there something wrong with my email?
> > > The last one I could find in my debian-devel-announce mail folder is
> > > from 2004-05-14.
> > > 
> > > Anyone know what happened?
> > 
> > As far as I can tell, the reports are still being mailed as normal.
> > Perhaps a listmaster could investigate why they're not reaching the
> > debian-devel-announce readership.
> 
> They are; I received one just last week.

... except that I didn't; I confused the bug stuff with the WNPP mail.
Please ignore.

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

Re: Release-critical Bugreport for May 14, 2004

[Wouter Verhelst]

On Sun, Oct 24, 2004 at 11:08:32AM +0100, Colin Watson wrote:
> On Sun, Oct 24, 2004 at 01:26:09AM +0200, Petter Reinholdtsen wrote:
> > [BugScan reporter]
> > > Bug stamp-out list for May 14 06:01 (CST)
> > >
> > > Total number of release-critical bugs: 565
> > > Number that will disappear after removing packages marked [REMOVE]: 1
> > > Number that have a patch: 79
> > > Number that have a fix prepared and waiting to upload: 22
> > > Number that are being ignored: 14
> > > Number on packages not in testing: 200
> > > Number concerning the next release (excluding ignored and 
> > > not-in-testing): 274
> > 
> > Did these reports stop, or is there something wrong with my email?
> > The last one I could find in my debian-devel-announce mail folder is
> > from 2004-05-14.
> > 
> > Anyone know what happened?
> 
> As far as I can tell, the reports are still being mailed as normal.
> Perhaps a listmaster could investigate why they're not reaching the
> debian-devel-announce readership.

They are; I received one just last week.

If they're not reaching you, I suggest you check your d-d-a subscription
and/or your spam filter.

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

Re: Release-critical Bugreport for May 14, 2004

[Colin Watson]

On Sun, Oct 24, 2004 at 01:26:09AM +0200, Petter Reinholdtsen wrote:
> [BugScan reporter]
> > Bug stamp-out list for May 14 06:01 (CST)
> >
> > Total number of release-critical bugs: 565
> > Number that will disappear after removing packages marked [REMOVE]: 1
> > Number that have a patch: 79
> > Number that have a fix prepared and waiting to upload: 22
> > Number that are being ignored: 14
> > Number on packages not in testing: 200
> > Number concerning the next release (excluding ignored and not-in-testing): 
> > 274
> 
> Did these reports stop, or is there something wrong with my email?
> The last one I could find in my debian-devel-announce mail folder is
> from 2004-05-14.
> 
> Anyone know what happened?

As far as I can tell, the reports are still being mailed as normal.
Perhaps a listmaster could investigate why they're not reaching the
debian-devel-announce readership.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]

Re: gfreeamp playlist inquiry

[Ulrich Eckhardt]

On Saturday 23 October 2004 05:42, Kevin Mark wrote:
> Your ability to
> ask for features in the software programs that you use is one of the
> advantages of libre/free software. 

Errm, can't you do so with any piece of software out there? The advantage of 
free software is that you can do it yourself (or hire someone), not just the 
original author.

I agree that it's more fun with free software though. :)

Uli

Re: Drop testing

[Wouter Verhelst]

On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote:
> Gergely Nagy <[EMAIL PROTECTED]> writes:
> 
> >> It may sound a bit radical, but core points have been mentioned in the
> >> thread already. I suggest to do it in a more radical way:
> >> 
> >>  - unstable lockdown in the freeze
> >>  - drop Testing and concentrate on work instead of wasting time on
> >>synching stuff. This eliminates the need for testing-security. See
> >>the last part of the paper for details.
> >
> > Doing this would result in many users who currently run testing fall
> > back to stable + backports or switch to another distro (ubuntu being a
> > likely candidate), which in turn, would result in less bugreports and a
> > less stable distribution.
> 
> Very few bug reports from testing users are of any value at all.

I respectfully disagree here.

With most of my packages, bugs get filed only when the transition to
testing has been complete for quite a while already, except when the bug
is a /really/ severe one (severity grave or critical).

When this is true, it doesn't matter whether the user is a testing one
or an unstable one -- both packages simply are of the same version.

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

Re: an idea for next generation APT archive caching

[Brian May]

> "Wouter" == Wouter Verhelst <[EMAIL PROTECTED]> writes:

Wouter> It's not actually version 2 yet, but the current apt-proxy
Wouter> in unstable is supposed to be apt-proxy v2.

This version isn't in testing, hence part of my confusion. The other
part comes from the fact apt-proxy 1.9.18 in unstable is probably v2.

(As for why it is not in testing, see bug #267880 + others).
-- 
Brian May <[EMAIL PROTECTED]>

Re: Ubuntu discussion at planet.debian.org

[Jérôme Marant]

Matthew Palmer <[EMAIL PROTECTED]> writes:

>>  That is a simple branching issue in the version control
>>  system, no?
>
> A huge rush of air fills the list as hundreds of developers fill their
> lungs to collectively say "I don't use version control"...

AFAIK, it has nothing to do with VC.

-- 
Jérôme Marant

http://marant.org

Re: an idea for next generation APT archive caching

[Robert Collins]

On Sat, 2004-10-23 at 12:57 -0500, Manoj Srivastava wrote:
> On Fri, 22 Oct 2004 23:04:32 -0700, Matt Zimmerman <[EMAIL PROTECTED]> said: 
> 
> > On Wed, Oct 20, 2004 at 02:11:44AM +0200, martin f krafft wrote:
> >> Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this
> >> could be interesting, maybe it's just crap. Your call.
> 
> > My position on special-purpose proxy caches for APT is that
> > general-purpose proxy caches (like squid) seem to work fine for me.
> > What advantages do they have for others?
> 
>   Optimization?  With a special purpose proxies I can control
>  how the cache gets updated. For example, I want to keep two versions
>  of packages I use around -- the current, and the previous one, no
>  matter how old. Hard to do with Squid, which does not know these two
>  files ar4e different versi9ons of the same package. 

It can be taught that. A custom cache replacement policy, for one cache
dir, for example.

Rob

-- 
GPG key available at: .


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

Re: Ubuntu discussion at planet.debian.org

[Matthias Urlichs]

Hi, Henrique de Moraes Holschuh wrote:

> Is there really a developer out there that doesn't do even the most
> rudimentary VC by keeping copies of all the source packages he has
> uploaded/worked on ?

What for? You can always get your old versions from snapshots.debian.net.

SCNR,
-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Security updates for sarge?

[Matthias Urlichs]

Hi, Manoj Srivastava wrote:

>   Are you, then, setting up a system for the security team to be
>  able to build packages for testing?  (you did mention you needed no
>  further help from anybody).  Is there a reason you are not indeed
>  putting things in place?

I already have, as far as possible with my own machines. Debian, however,
consists of slightly more architectures than are currently available in my
computer room. I also assume that the security team's source packages are
located somewhere other than http://smurf.noris.de/code/debian/testing/;
furthermore, they probably want the official security stuff to live on a
Debian-administered system.

To clarify: I wouldn't need help actually doing it, but somebody would
have to add me into a few groups / add my ssh pubkey to a few more files,
before I'd be able to *start* doing it *again*, but this time in a way
that's actually of benefit tto Debian, instead of just my personal
playroom.

>> Asking whether people want to leatn how to do the job is thus
>> pointless.

>   No, having people who merely want to come up with rants
> against people who are doing the work is a good thing.

If the people who are currently allowed to do the work were indeed doing
it, I would agree with you. After a month of no visible progress WRT t-s,
however, I'd say that they are not.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]

Re: Release-critical Bugreport for May 14, 2004

[Andreas Tille]

On Sun, 24 Oct 2004, Petter Reinholdtsen wrote:
Did these reports stop, or is there something wrong with my email?
The last one I could find in my debian-devel-announce mail folder is
from 2004-05-14.
This is what I wondered every week but was to lazy to ask.  Either something
is broken or our both email systems are broken.
Kind regards
   Andreas.

Re: Content of CDs / DVDs

[Marc Haber]

On Wed, 20 Oct 2004 23:35:02 +0200, Bartosz Fenski aka fEnIo
<[EMAIL PROTECTED]> wrote:
>Let's be honest... how many of us will download full CD set of sarge?

A lot of clueless newbies will. It's already common with woody. Almost
daily, Usenet groups will receive articles like "now I have downloaded
all 7 woody CDs, and what do I do with them?".

Greetings
Marc

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

Re: Ubuntu discussion at planet.debian.org

[Hamish Moffatt]

On Sat, Oct 23, 2004 at 11:08:17PM -0500, Manoj Srivastava wrote:
> On Sun, 24 Oct 2004 09:46:32 +1000, Matthew Palmer <[EMAIL PROTECTED]> said: 
> > A huge rush of air fills the list as hundreds of developers fill
> > their lungs to collectively say "I don't use version control"...
> 
>   Really? Good good, I would expect developers to adhere to this
>  most basic of recommended software practice.

 I haven't seen much need here. It's usually possible to track
down earlier package versions if I really need through, from Debian, or
snapshot.debian.net, or out of date mirrors (:)).

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Bug#278006: ITP: mod-proxy-html -- Apache2 filter module for HTML links rewriting

[Emmanuel Lacour]

Package: wnpp
Severity: wishlist


* Package name: mod-proxy-html
  Version : 2.4.1
  Upstream Author : Nick Kew <[EMAIL PROTECTED]>
* URL : http://apache.webthing.com/mod_proxy_html/
* License : GPL
  Description : Apache2 filter module for HTML links rewriting

 mod_proxy_html is an output filter to rewrite HTML links in a proxy
 situation, to ensure that links work for users outside the proxy. It
 serves the same purpose as Apache's ProxyPassReverse directive does for
 HTTP headers, and is an essential component of a reverse proxy.


-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-1-686
Locale: LANG=C, LC_CTYPE=fr_FR

Re: Ubuntu discussion at planet.debian.org

[Manoj Srivastava]

On Sun, 24 Oct 2004 14:52:17 +0900, Mike Hommey <[EMAIL PROTECTED]> said: 

> On Sun, Oct 24, 2004 at 12:11:51AM -0500, Manoj Srivastava wrote:
> [...]
>> If unstable is not a distribution, what the hell is the point of
>> having all the paraphernalia of unstable around?  The whole point
>> of uploading to unstable is to have people test packages in
>> unstable.

> If people test unstable, then it's unstable we should release, not
> testing. As somebody said in this thread not enough people are
> trying testing, and that's one of our problems in the release cycle.

World is not binary. As it is, we have people testing both
 unstable and Sarge, giving us two levels at which bugs may be caught
 and fixed. And the only numbers I have seen quoted about usage seem
 to indicate that testing is indeed being run by a whole slew of
 people.

> [...backwards a bit...]
>> In other words, stop all development dead, since experimental is
>> never ever used as a default ditribution by anyone sane.

> Stop all development ? See the situation for gnome 2.8. It is in
> experimental. It is compiled for several architectures, and is maybe
> soon ready to be put in unstable. Do you really call that stopping
> all development ?

Anecdotal evidence is not the singular for data. I am speaking
 about past experience, where yes, by and large, development was
 indeed stopped.  Obviously, there are exceptions to any rule.

>> This is incorrect, t-p-u is indeed supported by buildds -- though
>> this paragraph seems to be more like a rant than anything else.

> Okay, it's a month old, but there hasn't been any since.
> http://lists.debian.org/debian-devel-announce/2004/09/msg5.html
> "We are also still missing official autobuilders for
> testing-proposed-updates on alpha and mips.  All other architectures
> appear to be keeping up with t-p-u uploads."

Missing a buildd on an arch or too is a far cry from t-p-u
 being unsupported.

> Take it as a rant if you want, but I'm just noticing.

Frankly, I am not seeing this as a big pain in the butt. It is
 a deficiency in support for some of the supported architectures, yes.

manoj
-- 
Do you think your mother and I should have lived comfortably so long
together if ever we had been married?
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Reproducible, precompiled .o files: what say policy+gpl?

[Manoj Srivastava]

On Sat, 23 Oct 2004 22:40:31 +0200, Wesley W Terpstra <[EMAIL PROTECTED]> said: 

> On Sat, Oct 23, 2004 at 12:27:25PM -0600, Gunnar Wolf wrote:
>> Wesley W. Terpstra dijo [Mon, Oct 18, 2004 at 09:59:36PM +0200]:
>> > At this point my question is only academic; the pure-gcc in main,
>> > icc-prebuilt in contrib solution seems to solve my concerns just
>> > as well.
>> 
>> I have only one concern with this: What happens if you drop the
>> package and someone else takes it? He will no longer be able to
>> compile it with icc, and the icc-prebuilt users will be left out in
>> the cold. What would you say to that?

> He can upload a version to contrib which depends on the version in
> main and has no contents. Then the icc users are automatically
> converted to gcc.

Why not go the contrib route to start with, and avoid these
 potential surprises?

> Or else, if he is an open-source developer who makes no money from
> his debian work, he can download icc from their site for free.  Just
> universities and paid researchers like me have to pay. Sniff.

Just because I make not money from Debian does not mean I am
 willing to sell out to non-free software.  There _is_ a principle
 involved here, you know.

manoj
-- 
Houston, Tranquillity Base here.  The Eagle has landed. Neil Armstrong
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Ubuntu discussion at planet.debian.org

[Mike Hommey]

On Sun, Oct 24, 2004 at 07:53:27AM +0200, Martin Schulze wrote:
> Err...  experimental ABI changes are for experimental.  Confirmed ABI
> and API changes are for unstable (or whatever you want to call the
> development branch).  We must not hide those changes from the future
> stable distribution since it was done and confirmed upstream.

Are you saying you would go with a (for instance) gcc ABI change right
now (i.e. while trying to release) in unstable if there was one ?

Mike

Re: non-free firmware: driver in main or contrib?

[Mike Hommey]

On Sun, Oct 24, 2004 at 04:20:16AM +0100, Matthew Garrett wrote:
> Argh. Sorry, I shouldn't be allowed to post while drunk. That was meant
> to go to -legal, not -devel.

And i shouldn't have replied without looking at the To: field.

Mike

Re: non-free firmware: driver in main or contrib?

[Mike Hommey]

On Sun, Oct 24, 2004 at 03:41:13AM +0100, Matthew Garrett wrote:
> Is this the case even if the firmware is in a flash chip attached to the
> device? If the total amount of non-free software on a user's system is
> the same regardless, why are we concerned about how it's packaged?

'kay, this has already been debated earlier, but let me rephrase it.
If some driver depend on *loading* a non-free firmware, i.e. being
*totally* useless without, it goes into contrib.
Same applies to any software in debian, right ?

Mike

Re: Ubuntu discussion at planet.debian.org

[Martin Schulze]

Henrique de Moraes Holschuh wrote:
> Is there really a developer out there that doesn't do even the most
> rudimentary VC by keeping copies of all the source packages he has
> uploaded/worked on ?

FWIW: I've heard so...

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

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

Re: Ubuntu discussion at planet.debian.org

[Martin Schulze]

Mike Hommey wrote:
> On Sat, Oct 23, 2004 at 12:14:45PM -0500, Manoj Srivastava wrote:
> > On Sat, 23 Oct 2004 14:23:48 +0900, Mike Hommey <[EMAIL PROTECTED]> said: 
> > 
> > > And why not, instead of freezing unstable, make it build against
> > > testing, when er try to freeze testing ?
> > 
> > Libraries. If you build against a library version that is no
> >  longer in unstable, then you may have issues in testing when a new
> >  library tries to migrate into testing -- cause nowhere would there be
> >  packages built against the new library version.
> 
> I don't see the point. If you build against what is in testing, there's
> no issue when migrating to testing.

Maybe you forgot that in such cases testing becomes what unstable is:
unstable.  You're likely to be unable to install software because
dependencies cannot be fulfilled yet by the architecture you're
running.  You've exactly won what?

> One particular issue would be when libraries change ABI, and new
> packages would need to be built against them, but still, at that
> particular time, the purpose being mainly to freeze testing, these 
> ABI changes should be candidates for experimental.

Err...  experimental ABI changes are for experimental.  Confirmed ABI
and API changes are for unstable (or whatever you want to call the
development branch).  We must not hide those changes from the future
stable distribution since it was done and confirmed upstream.

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

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

Re: Security updates for sarge?

[Ingo Juergensmann]

On Sun, Oct 24, 2004 at 03:29:35AM +0100, Matthew Garrett wrote:

> > But I think you're right... it's not about getting work done, it's about
> > politics and a orwellian "all users are equal, DDs are more equal" nonsense.
> > With every day passing by, it seems even more clearly to me that Debian has
> > lost its basics and has turned into a project that prefer to deal with
> > itself for that reason. And now it's even controlled by a venture
> > capitalist. Great job, well done... :-(
> You appear to be discussing some Debian that doesn't exist. In itself,
> this isn't surprising - you appear to have spent a significant period of
> time discussing a Debian that is only mildly related to the Debian that
> most people appear to perceive. Your postings to debian-devel have
> generally resulted in large quantities of noise and a complete absence
> of useful conclusions. 

Actually, I haven't seen a discussion resulting in any useful conclusion or
result on d-d. 

> You're either a revolutionary arguing on the side of the largely silent
> majority, or you're in a minority. In the first case, I'd suggest that
> you engage in making it clearer that a large set of people agree with
> you. In the latter case, I'd like to request that you stop. Your posts
> are counter-productive - your style of argumentation repels those who
> may have sympathy, and inflames those who already disagree with you.
> Your current activities are accomplishing nothing. There is no advantage
> to be gained in "I told you so" - instead, you merely delay us from
> going anywhere.

Ugh, sorry... I wasn't aware that it's *me* who is preventing the release
from being done. When I would have known that, I never would have worked
hard in the past weeks on the unofficial buildd network to bring down the
backlog for mips (and tried for others). Silly me... 

> Matthew Garrett | [EMAIL PROTECTED]

IIRC, you're one of those Ubuntus, right? No more to be said then... 

-- 
Ciao...  // 
  Ingo \X/

Re: Ubuntu discussion at planet.debian.org

[Mike Hommey]

On Sun, Oct 24, 2004 at 12:11:51AM -0500, Manoj Srivastava wrote:
[...]
>   If unstable is not a distribution, what the hell is the point
>  of having all the paraphernalia of unstable around?  The whole point
>  of uploading to unstable is to have people test packages in
>  unstable. 

If people test unstable, then it's unstable we should release, not
testing. As somebody said in this thread not enough people are trying
testing, and that's one of our problems in the release cycle.

[...backwards a bit...]
>   In other words, stop all development dead, since experimental
>  is never ever used as a default ditribution by anyone sane.

Stop all development ? See the situation for gnome 2.8. It is in
experimental. It is compiled for several architectures, and is maybe
soon ready to be put in unstable. Do you really call that stopping all
development ?

>   This is incorrect, t-p-u is indeed supported by buildds --
>  though this paragraph seems to be more like a rant than anything
>  else.

Okay, it's a month old, but there hasn't been any since.
http://lists.debian.org/debian-devel-announce/2004/09/msg5.html
"We are also still missing official autobuilders for
testing-proposed-updates on alpha and mips.  All other architectures
appear to be keeping up with t-p-u uploads."

And vorlon told me not so long ago that it was still the case, and that
it was the reason why the NMU by Frank Lichtenheld for kxmleditor[1]
through t-p-u still hasn't made it to sarge... and you may know that all
KDE applications updates have to go through t-p-u, since unstable is
"polluted" with KDE 3.3 which won't make it for sarge.

Take it as a rant if you want, but I'm just noticing.

Mike

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265680&msg=35

Re: Security updates for sarge?

[Manoj Srivastava]

On Sun, 24 Oct 2004 00:30:37 +0200, Sven Mueller <[EMAIL PROTECTED]> said: 

> Manoj Srivastava [u] wrote on 23/10/2004 21:43:
>>> I must admit I thought something similar: Why the hell are there
>>> only two people who know how to do it, when two people doesn't
>>> seem to be enough?
>> Are you volunteering to go out and better educate yourself to take
>> on this work?

> You know perfectly well that there _are_ people out there who know
> how to do it.

And don't seem to have the time or the motivation to do it,
 i=or it would have been done.  Until it is done, all people who rant
 at the current situation would be better off learning how to and
 actually doing something, rather than coming out with more hot air.

>  Also: I offered my help if it is wanted (see below),

And that is very good indeed.

> but I see no point in learning what's needed to work as a buildd or
> ftp admin for debian while I know perfectly well that helping hands
> in these areas is regularly declined by those in charge.

Umm, empty promises are often ignored, yes. Setting up a
 tested infrastructure, I think, would not be ignored.

> If my help is indeed wanted: Yes.  Under the current circumstances
> (with no definite acknowledgement that my help will be accepted):

That's not how things work.

> no.

Ah. Thought not.

> Also you are in no way responsive to my main point: Why are there
> only two people doing the job when quite a few more people have
> already offered to help (and are indeed qualified to do the job)?

Cause they got off their butt and did things? (rather than
 talk about how good they would be at helping out, if only people
 formed cheering squads and go Rah! rah! rah!

>> Or is this yet another time wasting rant?

> You mean like your post?

Yup, mine was an anti-rant rant.

>>> Heck, If I were a DD, I would be glad to help whereever
>>> needed. The

>> Ah. Just a spectator, booing and hissing at the people who have
>> stood up to be counted.

> And who decline help every time the subject of their work load comes
> up? 

You ain;t ever gonna get a gilded invitation. That is not how
 free software works.


>>> So, if my help is wanted with one of the first three of those, I
>>> will gladly file a NM application immediately.

>> Please do.

> Fine. Where do you want me to help?

Weherever you can scratch your itch.

> When I know where my help is wanted and accepted, I will gladly file
> the application. Until then I currently see no point in doing so
> (putting more load on the DAM without having actual work for me to
> do).

Don't bother. With that attitude, I don't think you are gonna
 last long in free software. If you continue to look externally for
 gilded invitations and  rah! rah! aquads.

>> We need more workers, and less lawyers.

> Exactly my point. Problem is that the current workers are doing
> everything to keep others from being able to do their work.

If the so called wanna-be workers are so easily dissuaded, I
 am not sure they aree the workers we are looking for. Moving along
 now. 

manoj
-- 
And miles to go before I sleep. Robert Frost
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Drop testing

[Martin Schulze]

Steinar H. Gunderson wrote:
> On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:
> > It may sound a bit radical, but core points have been mentioned in the
> > thread already. I suggest to do it in a more radical way:
> > 
> >  - unstable lockdown in the freeze
> >  - drop Testing and concentrate on work instead of wasting time on
> >synching stuff. This eliminates the need for testing-security. See
> >the last part of the paper for details.
> 
> You _are_ aware that this is approximately how it was done before woody, no?

With three 1-month test cycles to get frozen into a reasonable and releaseable
state?

Regards,

Joey

-- 
MIME - broken solution for a broken design.  -- Ralf Baechle

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

Re: Ubuntu discussion at planet.debian.org

[Manoj Srivastava]

On Sun, 24 Oct 2004 11:27:41 +0900, Mike Hommey <[EMAIL PROTECTED]> said: 

> On Sat, Oct 23, 2004 at 12:14:45PM -0500, Manoj Srivastava wrote:
>> On Sat, 23 Oct 2004 14:23:48 +0900, Mike Hommey <[EMAIL PROTECTED]>
>> said:
>> 
>> > And why not, instead of freezing unstable, make it build against
>> > testing, when er try to freeze testing ?
>> 
>> Libraries. If you build against a library version that is no longer
>> in unstable, then you may have issues in testing when a new library
>> tries to migrate into testing -- cause nowhere would there be
>> packages built against the new library version.

> I don't see the point. If you build against what is in testing,
> there's no issue when migrating to testing.  One particular issue

And you wouldn't ever be able to run unstable, so what's the
 point of having it if people don't test unstable?

> would be when libraries change ABI, and new packages would need to
> be built against them, but still, at that particular time, the
> purpose being mainly to freeze testing, these ABI changes should be
> candidates for experimental.

In other words, stop all development dead, since experimental
 is never ever used as a default ditribution by anyone sane.


>> Not to mention that unstable would become unviable as a
>> distribution -- the run time libs may not be the ones that are
>> needed by the packages in unstable.

> At that particular time, isn't frozen-testing the one that is
> supposed to be a distribution ?

If unstable is not a distribution, what the hell is the point
 of having all the paraphernalia of unstable around?  The whole point
 of uploading to unstable is to have people test packages in
 unstable. 

> On top of the problems mentionned by the other replies, the fact
> that autobuilders have to be set up for t-p-u... can you remind me
> how long sarge has been planned for freeze ? and for how long
> autobuilders are required for alpha and mips for t-p-u ?

This is incorrect, t-p-u is indeed supported by buildds --
 though this paragraph seems to be more like a rant than anything
 else.

manoj
-- 
Psychiatry is the care of the id by the odd.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Security updates for sarge?

[Manoj Srivastava]

On Sat, 23 Oct 2004 22:40:58 +0200, Matthias Urlichs <[EMAIL PROTECTED]> said: 

> Hi, Manoj Srivastava wrote:
>> Again, are you volunteering to go out and learn how to do it?  Or
>> is this yet another time wasting rant?
>> 
>>> Heck, If I were a DD, I would be glad to help whereever
>>> needed. The
>> 
>> Ah. Just a spectator, booing and hissing at the people who have
>> stood up to be counted.

> Manoj, please stop.

I would much rather that the peanut gallery stop, in which
 case I would never have intervened.

> The last time this came up, at least four people offered to help. At
> least one of them (me ;-) considers himself to be qualified and
> experienced enough to do the job without further help from anybody.

Are you, then, setting up a system for the security team to be
 able to build packages for testing?  (you did mention you needed no
 further help from anybody).  Is there a reason you are not indeed
 putting things in place?

> Asking whether people want to leatn how to do the job is thus
> pointless.

No, having people who merely want to come up with rants
 against people who are doing the work is a good thing.  If you don't
 think things are being done well enough, and that you can do better,
 by all means go ahead and scratch your itch.

manoj
-- 
"The part I think I'd like best is crushing people who get in my way."
Calvin
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C