Re: MIPS port backlog, autobuilder machines and some arrogance

[Chris Cheney]

On Fri, Nov 14, 2003 at 02:55:09PM +0100, Wouter Verhelst wrote:
> Op vr 14-11-2003, om 11:34 schreef Ingo Juergensmann:
> [...]
> > As a result and a sort of protest, I´ll stopped my m68k buildd, because I
> > don´t know m68k that much to be of any help for this port anymore. Therefore
> > my m68k isn´t needed anymore as my offered mips machine isn´t needed for the
> > mips port or the Debian project at all.
> 
> Ingo,
> 
> I can understand why you're upset, but please do try not to make one
> port suffer for the actions of the people responsible for another port.
> The help arrakis has provided over the years has always been
> appreciated, and will be for as long as you provide the access; it would
> be a shame if this would be discontinued because of a difference in
> opinion you have with Ryan regarding the way autobuilding for the mips
> architecture should be handled.

So why does Ryan have the authority to reject more buildd's when he
obviously is overburdened to the point he doesn't respond to emails
(see Branden Robinson's post as an example). From an untrained eye the
mips buildd's seem to be building packages more or less fine just that
they were lagged by the human behind them. One example is kdelibs which
wasn't built for nearly a month due to what should have been a Dep-Wait
on a fixed libXrender, which was uploaded the same day mips attempted to
build kdelibs.

Chris


signature.asc
Description: Digital signature

Re: POSIX capabilities patch

[Junichi Uekawa]

>  >And if i enable SETPCAP for init, will init drop that capability? Will it
>  >pass it to all started programs?
> See http://www.linux.it/~md/ssd.tgz .
> No kernel hacks needed.

I see a 404. 


regards,
junichi

Re: MIPS port backlog, autobuilder machines and some arrogance

[Chris Cheney]

Another point is do we really want an arch/port to be maintained by only
one person? IMHO there should be at least two people capable and
actually running the buildds for each arch, possibly more when they are
too busy with other things as appears the case with Ryan.

Chris


signature.asc
Description: Digital signature

Re: Bug#217980: Autobuilders and nut package (#217980)

[Arnaud Quette]

Artur R. Czechowski wrote:
Hello
This bug causes autobuilders stop work. It is possible to fix it ASAP?
http://buildd.debian.org/fetch.php?&pkg=lftp&ver=2.6.8-2&arch=hppa&stamp=1068852612&file=log&as=raw
http://buildd.debian.org/fetch.php?&pkg=rrdcollect&ver=0.2.1-5&arch=mipsel&stamp=1068836320&file=log&as=raw
Cheers
	Artur
 

sorry for the side effect.
I'm currently rebuilding nut with the needed
fix (with your patch, thanks) and some others.
Thanks
Arnaud
--
PS: the upload is scheduled this afternoon (+6h max)

Re: Anyone know anything about 3dwm?

[Jochen Voss]

Hello,

A minor fix for the common blurb of all the descriptions:

On Sat, Nov 15, 2003 at 02:52:13AM +0100, Sam Hocevar wrote:
>  3Dwm is the Three-Dimensional Workspace Manager. It defines a full user
>  environment with support for three-dimensional user interfaces using a 3D
>  widget kit. It also provides some backwards compatiility with all the major
   
   compatibility

I hope this helps,
Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Bug#155583: radiusd-freeradius history and future

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Sam Hartman  <[EMAIL PROTECTED]> wrote:
>I think dpkg-statoverride is not too bad in this case.  I'll talk to
>the nis package maintainer and see if that's acceptable.  If not, nis
>could install some flag file.  The unix_chkpwd could start with root
>privs, chuck for this flag file with a hard coded path and drop to
>shadow if the flag file does not exist.

The NIS package is in limbo right now. I'm the maintainer, but
I haven't had time to maintain it. I did send an ITO to this
list, but it appears noone wants to take it.

Mike.

Re: MIPS port backlog, autobuilder machines and some arrogance

[Ingo Juergensmann]

On Sat, Nov 15, 2003 at 12:54:18AM -0500, Branden Robinson wrote:
> On Fri, Nov 14, 2003 at 11:34:41AM +0100, Ingo Juergensmann wrote:
> > As some of you know the mips port has some problems keeping up.
> Daniel Stone and I have been trying for months to get feedback regarding
> xfree86 > 4.3.0-0pre1v1 on mips, and we are always met with stony
> silence.

Right. He had the chance to say "No, thx, that backlog is just temporarily
and we solved the backlog and having another machine is not needed" in a
polite way for about a week, but nothing happened. 

> > Everything went well with that machine - until we directed the request to
> > debian-admin to get wanna-build access for mips. The request was rejected
> > with the following reasons (to my knowledge):
> > - another machine is in the works
> Which, of course, will never go down, suffer hardware failure, or have
> its hosting site suffer a power outage or fire.

Right. On m68k we have the most buildd machines and guess what: murphy
looked in some weeks and several buildds went away nearly at the same time
giving a backlog of about >220 packages rather quick. 
Therefor we don't say "Oh my god! We don't need so many buildds because more
machines can fail more often!" but more likely "Hey, the number of packages
is constantly growing, the toolchain is very often giving problems and is
getting slower as well (gcc3.3) and there will always be exists problems
that take machines down. So we appreciate to have even more machines and
have a pool of buildd maintainers as well to help each other!"

> > - we don´t need your machine
> And we never will; see above.

On m68k-build there was a little more discussion about the reasons. See the
webarchive for the list. 
Funny thing is, that every responsible people gives another reason for
rejecting our offer, which make me feel that not the machine is the problem
but that those people want to act alone on their own will and decision. 
The reason that were given there was that having multiple buildd maintainer
will make it hard to work together and it's more simple when a single buildd
maintainer manages all of the buildds for one arch.
a) I think that's not true. m68k shows clearly that this can work and even
is a benefit, because I think that m68k is the most responsive and helpful
archs when maintainers direct questions to the (right ;) list. 
b) When it is a problem for a person to work together with others he clearly
should reconsider his involvment in Debian, because the project is a
cooperate effort and not something where helping hands should be excluded
when they want and are able to help. Although I don't think it's violating
the social contract, I don't think that this behaviour is in the sense of
it. 
c) We offered a machine. Maybe it's not the fastest or best equipped right
now but it is usuable. And we didn't insisted of administrating it by our
own, although Wouter wanted to maintain the buildd in order to unburden
Ryan, but when he wanted to take it himself that would be ok as well. 
d) There is a second machine that could be used as buildd, when the new
disks and the memory arrives. All machines would have fixed IP addresses, so
that the machines could even be used as public machines. But the responsible
persons have not asked for either option but simply rejected the idea of
having more machines to help with the backlog without asking for further
information. And that's plain stupid or arrogant. Call it as you want.

> > - you don´t have any knowledge about mips, so the machine wouldn´t be of any
> > help at all.
> It's not like you're an experienced buildd admin, and it's vitally
> important that people who aren't already experts at administrating mips
> buildds not gain that expertise.

It's even more worse! 
I simply cannot be a buildd admin on my own, because I'm not a DD and thus
cannot sign the packages. And to improve the worseness: I understand as much
mips asm as I understand m68k asm: not a single word! 
So, saying I'm not experienced enough on mips also means I cannot run a m68k
buildd, because my knowledge is the same for both archs. ;-)

> > As a result and a sort of protest, I´ll stopped my m68k buildd, because I
> > don´t know m68k that much to be of any help for this port anymore. Therefore
> > my m68k isn´t needed anymore as my offered mips machine isn´t needed for the
> > mips port or the Debian project at all.
> I'm not sure I agree with your decision, but I do think I understand
> your frustration.

Thx.

> Can I ask why it is such a disaster to have an alternate or standby
> buildd for the mips architecture?

IMHO because some people don't want anyone else to play on their playground.

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

Re: RFA: A lot of packages

[Matthias Klose]

> I'm totally swamped in work even though I haven't started learning for
> the next round of exams yet, so I'd like to give away my packages:
> 
>  - python-imaging(*)
> 
>Simon
> 
> (*) Gerhard H=C3=83=E2=82=ACring expressed interest, but I have no definiti=
> ve word.

If Gerhard doesn't take it, I'll take it back.

Matthias

Bug#220890: ITP: eyed3 -- Display and manipulate id3-tags on the command-line

[Alexander Wirt]

Package: wnpp
Severity: wishlist

* Package name: eyed3
  Version : 0.5.1
  Upstream Author : Travis Shirk <[EMAIL PROTECTED]>
* URL : http://www.travisshirk.net/eyeD3/
* License : GPL
  Description : Display and manipulate id3-tags on the command-line

A command-line editor to add/edit/remove id3-tags on mp3 files.
It supports id3 tags version 1.0,1.1,2.3 and 2.4. 
Additionally it display several informations about the file 
(length, bitrate, sample rate ...). 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bart 2.4.21 #2 Thu Jul 24 10:50:08 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Bug#220888: ITP: python-eyed3 -- Python module for id3-tags manipulation

[Alexander Wirt]

Package: wnpp
Severity: wishlist

* Package name: python-eyed3
  Version : 0.5.1
  Upstream Author : Travis Shirk <[EMAIL PROTECTED]>
* URL : http://www.travisshirk.net/eyeD3/
* License : GPL
  Description : Python module for id3-tags manipulation

python-eyed3 is a python module for id3-tags manipulation. 
It supports Version 1.0,1.1,2.3 and 2.4 id3-tags. It also 
allows to retrieve informations like length, bitrate from 
the mp3 file.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bart 2.4.21 #2 Thu Jul 24 10:50:08 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Re: Bug#155583: radiusd-freeradius history and future

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Sam Hartman  <[EMAIL PROTECTED]> wrote:
>>I think dpkg-statoverride is not too bad in this case.  I'll talk to
>>the nis package maintainer and see if that's acceptable.  If not, nis
>>could install some flag file.  The unix_chkpwd could start with root
>>privs, chuck for this flag file with a hard coded path and drop to
>>shadow if the flag file does not exist.
>
>The NIS package is in limbo right now. I'm the maintainer, but
>I haven't had time to maintain it. I did send an ITO to this
>list, but it appears noone wants to take it.

Okay, that is not entirely true. I just uploaded 3.10-1 to
ftp-master, and closed several bugs. Sometimes I just need
some incentive, I guess ..

Mike.

Source only uploads? -- A summary

[Roland Stigge]

Hi,

last month, Wolfgang Borgert wondered [1] if we should decide to enable
source-only uploads. The thread was lead quite emotionally and turned to
be a flame war. Personally, I stopped following it when [DD X] wrote:
"Be very wary of listening to [DD Y]. His comments are frequently
disconnected from reality.". I guess that others did similarly.

But since I'm interested in this topic, I now read over it and try to
summarize the main reasons for or against source only uploads:

Pro:

* Better quality and consistency
* Autobuilders (i386) are inexpensive
* We could have "Architecture: all" autobuilds
* Prevention of trojans in binaries
* Prevention of statically linked-in stuff we don't have the source
  from in the archive
* The current situation keeps DDs from using experimental (which in turn
  is suggested by the RM) because experimental parts disqualify an
  installation as a build environment
* Currently, the developer's development environment potentially exposes
  information about him (name etc. in generated files)
* Currently, autobuilders don't find all FTBFS bugs (especially in 
  "Architecture: i386" and "Architecture: all" packages)
* DD bandwidth could be saved by source only uploads
* A full build log could be available
* Currently, the mostly used architectures (i386 and powerpc) have the
  least quality because the packages built in individual developer's
  environments are more likely to be broken or at least influenced

Con:

* Autobuilders are "artificial" and don't reflect common Debian 
  installations
* Autobuilders are regarded as a single point of failure: breaking into
  them does more harm than breaking into all the developer's machines
* Developer's machines accommodate "real life systems", so they can even
  detect more bugs since they expose the build process to more
  configuration possibilities
* There are not enough autobuilder resources available
* Source only uploads (SOU) would encourage carelessness
* "Architecture: all" packages won't get built with SOU
* Currently, we have a variety of build environments: various DD's
  installations, plus "artificial" buildd environments. This covers more
  of the testing space, i.e. will discover more bugs
* DDs shouldn't upload packages built in their experimental etc.
  extended environments, but instead they should upload pbuilder-built
  versions
* Would require extra amount of work for porters

(I apologize to all of you who find this redundant.)

Please don't reply to this mail publicly by continuing or restarting the
old debate. (But I invite you to just add further _basic_ reasons I
forgot to mention here.)

Instead, I volunteer to host a small, unofficial and non-anonymous
survey to get an impression of the community's opinion. If you are a
Debian Developer, please send me a private mail with

  "Source only uploads: Yes"

or

  "Source only uploads: No"

in the subject. At the beginning of December, I will post the results,
and if there is any doubt, I will disclose the list of names and votes.

Thanks.

bye,
  Roland

[1] http://lists.debian.org/debian-devel/2003/debian-devel-200310/msg01226.html


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

Bug#220898: ITP: scsi-idle -- asdf

[Eduard Bloch]

Package: wnpp
Severity: wishlist

* Package name: scsi-idle
  Version : 2.4.23
  Upstream Author : various
* URL : http://www.lost-habit.com/scsi.html
* License : GPL

I picked it up from the 2.4.19 version, fixed the tools to compile with
gcc-3.2 and plan to package it with the following description:

Package: scsi-idle
Description: turn off SCSI disks when idle
 This package contains small programs to start and stop SCSI disks and a
 daemon that spins down drives when idle. Optional kernel patch which
 spins up SCSI-disks when they are accessed is provided by the
 kernel-patch-scsi-idle package.

Package: kernel-patch-scsi-idle
Description: Kernel patch to spin up SCSI drives on access
 The scsi-idle patch is needed to spin up SCSI drives from idle mode
 when accessed. The programs to spin down the disks are provided by the
 scsi-idle package.
 .
 Supported kernel versions: 2.0.36, 2.2.10, 2.4.18 and above.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux debian 2.4.23-rc1 #2 Sa Nov 15 14:06:45 CET 2003 i686
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8

Re: buildd dpkg was interrupted

[Goswin von Brederlow]

Paul Telford <[EMAIL PROTECTED]> writes:

> One of my packages just failed to build on m68k with the message:
> 
> E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to 
> correct the problem. 

Thats the buildd as already stated in the other mail, but...

> I noticed that a couple of other packages on this arch have also just 
> failed to build with the same message.  Does the buildd require manual 
> attention, or is my package broken?  My package log is: 
> http://buildd.debian.org/build.php?&pkg=digikam&ver=0.5.1-1&arch=m68k

I've build your package and I'm not happy with the build log.

The french documentation seems not to build but the error gets
ignored. (see bugreport) for one thing.

The other thing is the amount of g++ warnings like unused variables,
implicit typenames and even unitialized variables showing up. Also
some "control reaches end of non-void function" warnings.

Please cleanup your source. I will get digikam marked as failed since
I supect the build debs to be faulty.

MfG
Goswin

Re: Bug#217980: Autobuilders and nut package

[Artur R. Czechowski]

On Sat, Nov 15, 2003 at 10:44:02AM +0100, Arnaud Quette wrote:
> PS: the upload is scheduled this afternoon (+6h max)
I see package is uploaded to incoming. Thanks :)
BTW, it probably requires manual intervention from buildd maintainers.

Cheers
Artur
-- 
[...] jestem wredna, żelazna małpa
/Croolik/

Re: On linux kernel packaging issue

[Goswin von Brederlow]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> #include 
> * Glenn McGrath [Sun, Nov 09 2003, 09:53:26AM]:
> 
> > > We're all very interested in *real* evidence here, because there
> > > hasn't been any in the past. If you don't have any evidence, you can
> > > expect people to call bullshit on this.
> > 
> > Gentoo
> 
> What does that mean? Gentoo uses a heavily patched kernel which goes far
> beyound of what we dicuss 
> 
> > # time bzip2 -9k linux-2.6.0-test5.tar
> >  
> > real2m40.974s
> > user2m33.679s
> ...
> > user2m49.316s
> 
> Even then, it's about only 10 percent. Let's compare them with vanilla
> kernel, optimised for P4:
> 
> # time bzip2 -9k out.wav
> 
> real0m42.862s
> user0m41.410s
> sys 0m0.310s
> 
> The same running an unoptimised vanilla kernel:
> 
> real  0m40.990s
> user  0m40.640s
> sys   0m0.350s
> 
> Where is the performance gain you are talking about? Not even two
> percent, haha.

The unoptimized kernel is _clearly_ slower than the optimized one but
that actually makes bzip run _much_ faster.

This clearly prooves _beyond_any_reasonable_doubt_ we should not
optimize the kernel at all to get the best performance.

MfG
Goswin

Re: RFA: A lot of packages

[Andrés Roldán]

I will make an upload today then.

Regards.

Andrés Roldán <[EMAIL PROTECTED]> writes:

> I will take amap if no one disagrees.
>
> Simon Richter <[EMAIL PROTECTED]> writes:
>
>> Hi,
>>
>> I'm totally swamped in work even though I haven't started learning for
>> the next round of exams yet, so I'd like to give away my packages:
>>
>>  - amap
>>  - pingus
>>  - uptimed (sponsor needed for Daniel Gubser, who helped out)
>>  - python-imaging(*)
>>
>>Simon
>>
>> (*) Gerhard Häring expressed interest, but I have no definitive word.
>>
>> -- 
>> GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD  ADC6 18A0 CC8D 5706 A4B4
>
> -- 
> Andres Roldan
>
> Fluidsignal Group <[EMAIL PROTECTED]>
> The Debian Project<[EMAIL PROTECTED]>
> GIGAX <[EMAIL PROTECTED]>
> GPG Key-ID0xB29396EB  
> Home Page http://people.fluidsignal.com/~aroldan

-- 
Andres Roldan

Fluidsignal Group   <[EMAIL PROTECTED]>
The Debian Project  <[EMAIL PROTECTED]>
GIGAX   <[EMAIL PROTECTED]>
GPG Key-ID  0xB29396EB  
Home Page   http://people.fluidsignal.com/~aroldan


pgpgQ08OuXg2p.pgp
Description: PGP signature

Re: On linux kernel packaging issue

[Goswin von Brederlow]

Eduard Bloch <[EMAIL PROTECTED]> writes:

> #include 
> * Tobias Wolter [Sun, Nov 09 2003, 04:52:54PM]:
> > On 2003-11-09T16:19:21+0100 (Sunday), Eduard Bloch wrote:
> > > * Tobias Wolter [Sun, Nov 09 2003, 03:47:15PM]:
> > > >> # time bzip2 -9 < out.wav > /dev/null 
> > > > [...]
> > > >> # time /tmp/bzip2-1.0.2/bzip2 -9 < out.wav > /dev/null 
> > > >> Do you see now that 8 of your 10 percent come directly from the
> > > >> application code and other two maybe from the optimized libc? 
> > > > You did think of caching, did you?
> > > You did think of reading time(1), did you?
> > 
> > $ time bzcat \#debian.de_2003-07-10.log.bz2 > /dev/null; \ 
> >   sleep 10; \
> >   time bzcat \#debian.de_2003-07-10.log.bz2 > /dev/null
> 
> And you wanna say... what?!
> 
> > real0m0.068s
> > user0m0.030s
> ...
> > user0m0.030s
> 
> Comparing with something you quoted away:
> 
> |# time bzip2 -9 < out.wav > /dev/null
> |
> |real0m48.989s
> |user0m41.930s
> ...
> |user0m38.920s
> 
> Hint: the 'real' output was not relevant.
> 
> MfG,
> Eduard.

I think he ment that the reduced sys time might be caused by the wav
file being cached.

MfG
Goswin

Re: Anyone know anything about 3dwm?

[Steve Greenland]

On 14-Nov-03, 19:52 (CST), Sam Hocevar <[EMAIL PROTECTED]> wrote: 
> On Sat, Nov 15, 2003, Andrew Pollock wrote:
> 
> > I'm trying to prepare a QA upload of the 3dwm source package, and close a 
> > few of the trivial bugs assigned to it (mainly binary package descriptions 
> > being shite).
> 
>Yes, they all suck pretty much. Here are my suggestions:

Can I promote the idea that the 3Dwm summary appear *after* the package
specific material? I know that a lot of packages do it the way Sam has
it, but when browsing packages in e.g. aptitude, you often don't have
much space for the long description, and having to scroll every time to
skip past the summary is mildly annoying.

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

Bug#217980: Info received (was Bug#217980: Autobuilders and nut package)

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this problem report.  It has been forwarded to the package maintainer(s)
and to other interested parties to accompany the original report.

Your message has been sent to the package maintainer(s):
 Arnaud Quette <[EMAIL PROTECTED]>

If you wish to continue to submit further information on your problem,
please send it to [EMAIL PROTECTED], as before.

Please do not reply to the address at the top of this message,
unless you wish to report a problem with the Bug-tracking system.

Debian bug tracking system administrator
(administrator, Debian Bugs database)

Re: Digital Alpha 2100 Sable 233MHz

[Goswin von Brederlow]

Greg Folkert <[EMAIL PROTECTED]> writes:

> On Sun, 2003-11-09 at 15:47, Greg Folkert wrote:
> > I have a DEC Alpha 2100 Dual Processor with 256MB Memory and ~60GB of
> > drives space. It currently doesn't have any OS on it (well Tru64 Runtime
> > Only no User licenses)
> > 
> > I have a 1.5MBps SDSL line with a pretty good connectivity, but is
> > shared with the business it would be located at.
> > 
> > I guess, the question comes... would it be usable for Debian
> > building/development of the Alpha port?
> 
> Forgot... Dual 233MHz EV4.

Apart from disk space that a rather small system. On a dual cpu one
would like to run two buildds giving 128Mb ram to each. But c++
programms easily eat up 300-500MB during compile. Even with only one
buildd the system would swap for bigger packages.

Currently what I think would be far more usfull than another buildd
(alpha has an empty build queue anyway atm) would be testing the
debian-installer. From Tru64 I guess you have srm installed so the cds
with aboot should boot and work. If you have the time please do test
d-i.

MfG
Goswin

Re: RFA: A lot of packages

[Steve Kemp]

On Fri, Nov 14, 2003 at 05:03:59PM +0100, Simon Richter wrote:

>  - uptimed (sponsor needed for Daniel Gubser, who helped out)

  I will sponsor Daniel; or failing that I'd take it over
 myself.  Whichever you both prefer.

Steve
--

Re: possible compromise for ITP: linux?

[Goswin von Brederlow]

Santiago Vila <[EMAIL PROTECTED]> writes:

> On Mon, 10 Nov 2003, Eike Sauer wrote:
> 
> > What about letting Robert build and upload (if ftp-masters agree)
> > his package, *if* he puts it in experimental, uses a description
> > that contains a warning about the experimental status of the
> > package in a prominent place, and not calling it "linux", but...
> 
> linux-2.4.22 please, but just the binary-package, it should be ok to call
> "linux" the source package.
> 
> This way we could put an end to the objection that it may not be
> upgraded safely.
> 
> 
> As far as unstable vs experimental is concerned, I think one of the
> goals for this package is to have a common source package for the
> autobuilders. Since the autobuilders do not build experimental, it
> would not make any sense at all to upload it for experimental.

It will _only_ built on i386. Further more even with changes it will
only work on a very few archs so far.

And the package is 27MB too big since it should depend on the vanilla
linux sources instead of including them.

> If Robert is such an incompetent developer as some people say and the
> package does not build on the 11 different architectures, then the
> package will not propagate to testing and the world will be safe from
> the disaster.

A package will enter testing if it builds on all (or more) arch it was
previously build. Someone would have to file a FTBFS bug before it
becomes a candidate.

> OTHO, if he manages to create a package which compiles on every
> architecture and produces an *usable* kernel on every of them, why
> should not be the package allowed to exist in testing?
> 
> And if there is some architecture on which the kernel produced is not
> usable, would this not be a good reason for a "severity: serious" bug,
> which would again save the world from the disaster?

He has a lot of work before him before its useable. Personally I think
the time is better spend on merging the existing images source
together with the old build technique then to start from scratch.

MfG
Goswin

Re: possible compromise for ITP: linux?

[Goswin von Brederlow]

Joe Wreschnig <[EMAIL PROTECTED]> writes:

> On Mon, 2003-11-10 at 19:31, Adam Heath wrote:
> > On Tue, 11 Nov 2003, Santiago Vila wrote:
> > 
> > > If Robert is such an incompetent developer as some people say and the
> > > package does not build on the 11 different architectures, then the
> > > package will not propagate to testing and the world will be safe from
> > > the disaster.
> > 
> > You misunderstand how testing works.
> > 
> > If a *new* package doesn't build on some arch, it won't be held up from
> > testing because of it.
> > 
> > It's only when an *existing* package that *previously* built on some arch, 
> > and
> > now it doesn't, that testing will ignore it.
> 
> Given that we know Linux does in fact compile and run on all those
> architectures (by virtue of the fact we have them in the first place), I

We know vanilla doesn't.

> think it would be fair to insist that Robert's package do the same
> before it propagates to testing. He's stated numerous times that the
> porting is just packaging work and that he's capable of doing it.
> 
> I am not sure of the best technical way to make this happen, though.
> -- 
> Joe Wreschnig <[EMAIL PROTECTED]>

MfG
Goswin

Re: possible compromise for ITP: linux?

[Goswin von Brederlow]

Joey Hess <[EMAIL PROTECTED]> writes:

> Excuse the tautology, but I find it can be useful sometimes to look at
> requirements separate from the implementation, and try to come up with
> an alternate implementation that meets the same requirements. That other
> thread is too long for me to know for sure what all the requirements of
> the proposed linux package are, but I remember two of the main ones:
> 
> 1. apt-get install linux should install the linux kernel
> 2. apt-get source linux should retrieve the source to the linux kernel
> 
> Since the real source to the linux kernel is currently in the
> kernel-source- package, one way to approach requirement #2
> would be to make kernel-source-2.4.22 produce a binary package named
> "linux" on the i386 architecture. On other architectures the same binary
> package would be produced by whatever package contains the real kernel
> source for that architecture. Since apt-get source resolves binary
> packages to source package, it will just work, #2 satisfied.
> 
> On to meeting requirement #1. Now that we have a "linux" binary package.
> it need only depend on the appropriate kernel-image-nnn-yyy package. So
> on i386, the linux package produced by kernel-source-2.4.22 depends on
> kernel-image-2.4.22-1-386. Installation of that package installs the
> linux kernel, and upgrades are handled reasonably as well; old known
> working versions of the kernel remain on the system (if you don't want
> them to, aptitude can help). New versions of the kernel are pulled in
> as the dependencies of the linux package change to
> kernel-image-2.4.23-1-386, kernel-image-2.6.0-1-386, etc.
> 
> Problems of this approach, off the top of my head:
> 
> a. Having a binary package of the same name that is produced by
>different source packages on different architectures may or may not
>drive the archive maintainence scripts nuts. On the other hand,
>it uses no more space in the archive than our kernel sources use
>today.
> b. If kernel-source-2.4.22 produces a "linux" package, then when 2.4.23
>comes out, kernel-source-2.4.22 has to either be removed from the
>archive, or revved to stop providing the linux package before
>kernel-source-2.4.23 can begin to do so.
> c. After you apt-get source linux, you are left with a nice kernel tree,
>but not the .config used to build the kernel (that is in the source
>package for kernel-image-nnn-). Also, the debian/ directory is
>not set up to build a binary kernel, instead it wants to build these
>strange kernel-source "binary" packages. I'm not sure that being
>able to build the kernel is a part of requirement #2; if it is I can
>probably come up with a way around this, but it will require larger
>changes to how our kernel source is packaged.

apt-get build-dep kernel-image-nnn-
apt-get source kernel-image-nnn-

There are also kernel-tree-* package providing the right vanilla
source and patches.

MfG
Goswin

Re: possible compromise for ITP: linux?

[Goswin von Brederlow]

Eike Sauer <[EMAIL PROTECTED]> writes:

> Andrew Suffield schrieb:
> > He doesn't need to, he can be slapped down.
> 
> "Keine Gewalt!" ("No violence!")
> 
> > We don't ignore minor issues just because there are major ones.
> 
> So let's hope Robert can cope with minor issues 
> and only talk about the big ones for now.
> 
> >  - this packages adds nothing, and would occupy a fair chunk of space
> >in the archive. 
> 
> I don't know how short Debian is of space.
> How large would Robert's packages be?
> There already are several packages with complete 
> kernel sources which take as much place as his package 
> would, right?
> So is this really too large to let him test his idea?

Lets look at sid and just sources:

[EMAIL PROTECTED]:/mnt/debian/pool/main% find -type f -name "*kernel*gz" | 
xargs du -h --total | grep total
281Mtotal

[EMAIL PROTECTED]:/mnt/debian/pool/main% find -type f -name "*kernel*gz" | 
xargs du -m | sort -nr | head
40  
./k/kernel-source-2.6.0-test9/kernel-source-2.6.0-test9_2.6.0-test9.orig.tar.gz
35  ./k/kernel-source-2.4.22/kernel-source-2.4.22_2.4.22.orig.tar.gz
34  ./k/kernel-source-2.4.21/kernel-source-2.4.21_2.4.21.orig.tar.gz
33  ./k/kernel-source-2.4.20/kernel-source-2.4.20_2.4.20.orig.tar.gz
32  ./k/kernel-image-2.4.19-hppa/kernel-image-2.4.19-hppa_22.2.tar.gz
31  ./k/kernel-source-2.4.19/kernel-source-2.4.19_2.4.19.orig.tar.gz
27  ./k/kernel-image-2.4.19-ia64/kernel-image-2.4.19-ia64_020821.2.tar.gz
19  ./k/kernel-source-2.2.25/kernel-source-2.2.25_2.2.25.orig.tar.gz
5   ./m/mindi-kernel/mindi-kernel_1.0.orig.tar.gz
5   
./l/linux-kernel-headers/linux-kernel-headers_2.5.999-test7-bk.orig.tar.gz

As you can see (apart from hppa and ia64, what are you guys doing
there?) there is only one kernel source for each version.

All the kernel-image packages build-depend on the one kernel source
package and various kernel patch packages and are only a few K big
each:

-rw-rw-r--1 mrvn mrvn  673 Jun 24 23:47 
kernel-image-2.4.20-amiga_2.4.20-5.dsc
-rw-rw-r--1 mrvn mrvn 4.8K Jun 24 23:47 
kernel-image-2.4.20-amiga_2.4.20-5.tar.gz


There is no reason to duplicate the kernel source even if the images
are to be produced differently.

> >  - this package cannot be safely upgraded (without forcing a reboot).
> > The latter prohibits it from being in a Debian release. 

The same can be said for the current images.

> So it doesn't stop it from entering experimental.
> But I'm not sure if a package is worth a try if
> it cannot possibly make it in a release.
> 
> Ciao,
> Eike

Duplicating the vanilla source in the archive is a very bad
idea. Thats an extra 40 MB for every 2.6 kernel to be.

MfG
Goswin

Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

Hi,

below are some subjective opservations and opinions regarding the
progress towards Debian 3.1 .

Please read it, and make your own opinions on where I'm right and where
I'm wrong, even if you might not agree with my opinions on other issues
or if you don't agree with everything below.

This is not meant as a personal offence against anyone. E.g. I'm taking 
KDE as an example below, but this shouldn't imply anything about the 
quality of KDE or the packaging of KDE.


The reason why I write this mail is that I often can't tell someone who
asks me "Which distribution should I use?" to use Debian since:

- Debian 3.0 doesn't support much of the hardware curently available -
  the old 2.4.18 kernel on the boot floppies doesn't even boot on many
  new computers (some Promise IDE chipsets require a more recent 2.4 
  kernel), and much hardware from nearly all currently abailable 
  graphics cards to scanners is not or not appropriate supported
- testing, unstable or Debian 3.0 with backports aren't suitable for
  production systems

My impression is that many Debian developers don't use a Debian 3.0
(without backports), and that they therefore don't know how outdated it 
is.

Backports are only a workaround, not a solution for this problem. Mixing 
half a dozen backport sources of various quality is in my experience not 
more stable than using unstable.


Today, it's only 17 days until the officially announced "aggressive
goal" for the release of Debian 3.1 [1]. That's a date many users know
about, but I don't see any real progress towards Debian 3.1 during the
last months.

Let me start with some observaions regarding testing:

testing has some advantages:

- it's usually partially consistent in the sense that usually all
  depedencies are fulfilled
- testing detects some problems that might be unnoticed otherwise (e.g. 
  build errors on one architecture)
- testing forces maintainers to care more about their packages if they 
  want to get them into testing

testing has some disadvantages:

- testing doesn't itself ensure a releaseable state (e.g. it contained 
  for some time a mixture of GNOME 1 and GNOME 2)
- often you can't build testing within itself, since the testing
  scripts ignore build dependencies
- testing needs much manual interaction, e.g. it's practically imposible
  for a package like Mozilla, where two dozen packages have to depend on 
  the exact version of Mozilla, to ever enter testing without a massive
  manual interaction


During the last months, the number of RC bugs of packages in unstable 
was constant at 700 bugs including 500 RC bugs in packages that are in
testing [2].

Yes, there's the common argument "Don't talk, fix bugs.". Unfortunately
this doesn't work: Debian is too big. I might e.g. be able to fix 50
easy to fix RC bugs in unstable, but this would be lost in the noise,
and wouldn't result in real progress.

Debian with over 1200 maintainers and over 13000 packages [3] is too big
to work in the relatively unstructured way it is currently. Announcing
0-day NMUs isn't sufficient to get a significant number of bugs fixed,
it's at least required to organize many bug squashing parties and to 
work hard to get many people involved in them [4].


It's often suggested to remove packages (at least from testing) if the
maintainer is inactice.

If a maintainer is MIA, his packages should be orphaned and he should be 
kicked out of Debian as soon as possible.

But for a user, it doesn't matter why a package isn't in Debian stable.
E.g. I've heard questions why gnuchess isn't in Debian 3.0 .

Debian 3.0 contains 7 CDs with binaries and Debian 3.1 might contain 10
or more CDs. How do you explain to a user why there are 10 CDs, but this
popular package is not included, and that package he needs is not
included?

Saying "The maintainer didn't care enough about the package you need."
only sounds like a good reason to switch to RedHat...  :-(

The Debian Social Contract says "Our Priorities are Our Users and Free 
Software" - if your users are a priority, dropping packages from a 
release shouldn't occur when it isn't badly needed.


Let's go back to some observations regarding what's needed to come 
nearer to Debian 3.1:

You can't freeze testing at any time - getting fixes that might be in
the packages in unstable for a long time from unstable into testing to
get testing into a releasable state might take more time than starting
from unstable.

Currently, many new upstream versions flood into unstable every day. 
Trying to get this or that package into testing is a Sysyphos task,
since once this or that problem with moving packages into testing is
solved, the next one pups up. For testing to work good, it's required to
have unstable in a good state. Often new so-versions of libraries enter
unstable, and e.g. KDE 3.2 might soon go into unstable. If testing
should be frozen, it's needed to _freeze unstable_ (IOW: require RM
approval for every upload to unstable). This doesn't need to be

Re: POSIX capabilities patch

[Marco d'Itri]

On Nov 15, Junichi Uekawa <[EMAIL PROTECTED]> wrote:

 >>  >And if i enable SETPCAP for init, will init drop that capability? Will it
 >>  >pass it to all started programs?
 >> See http://www.linux.it/~md/ssd.tgz .
 >> No kernel hacks needed.
 >I see a 404. 
Sorry: http://www.linux.it/~md/software/ssd.tgz .

-- 
ciao, |
Marco | [3070 biLxUf8rrGApc]

Re: MIPS port backlog, autobuilder machines and some arrogance

[Marco d'Itri]

On Nov 15, Chris Cheney <[EMAIL PROTECTED]> wrote:

 >Another point is do we really want an arch/port to be maintained by only
 >one person? IMHO there should be at least two people capable and
 >actually running the buildds for each arch, possibly more when they are
 >too busy with other things as appears the case with Ryan.
I fully agree. If a port has not enough developers to care about it,
then it should not be considered a candidate for releases.

-- 
ciao, |
Marco | [3071 sfP4YzRx/2xIc]


signature.asc
Description: Digital signature

Re: Anyone know anything about 3dwm?

[Bill Allombert]

Andrew wrote:

> I'm trying to prepare a QA upload of the 3dwm source package, and close a 
> few of the trivial bugs assigned to it (mainly binary package descriptions 
> being shite).

I have tried several time to make any use of those packages but
failed. Since they are not maintained anymore, I would suggest 
to remove them instead of keeping packages that look completly
useless to me. They also exhibit some horendous packaging bug.

So does  someone here has any use of them ? And how ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 

Re: Some observations regardig the progress towards Debian 3.1

[Andrew Suffield]

On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> - Debian 3.0 doesn't support much of the hardware curently available -
>   the old 2.4.18 kernel on the boot floppies doesn't even boot on many
>   new computers (some Promise IDE chipsets require a more recent 2.4 
   ^^^
>   kernel), and much hardware from nearly all currently abailable 
^^

This is false. All the promise IDE chipsets are adequetely supported
by 2.4.18, albeit not in anything above ata-33 mode. The only problem
is that autodetection fails for some of the newer ones, and you have
to manually specify the controller ports.

> My impression is that many Debian developers don't use a Debian 3.0
> (without backports), and that they therefore don't know how outdated it 
> is.

I've no idea how you acquired this impression. I'd say quite the
opposite, on all points.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: POSIX capabilities patch

[Miquel van Smoorenburg]

In article <[EMAIL PROTECTED]>,
Marco d'Itri  <[EMAIL PROTECTED]> wrote:
>On Nov 15, Junichi Uekawa <[EMAIL PROTECTED]> wrote:
>
> >>  >And if i enable SETPCAP for init, will init drop that capability? Will it
> >>  >pass it to all started programs?
> >> See http://www.linux.it/~md/ssd.tgz .
> >> No kernel hacks needed.
> >I see a 404. 
>Sorry: http://www.linux.it/~md/software/ssd.tgz .

Should that go into /sbin/init itself, so that you can boot with
initcaps=eip,cap_setpcap+eip on the command line ? Or is it still
too early to put that into init upstream ?

I assume init then has to link against libcap or something.
Would it add a lot of size to the binary ?

Mike.

Re: Some observations regardig the progress towards Debian 3.1

[Goswin von Brederlow]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> Hi,
> 
> below are some subjective opservations and opinions regarding the
> progress towards Debian 3.1 .
> 
> Please read it, and make your own opinions on where I'm right and where
> I'm wrong, even if you might not agree with my opinions on other issues
> or if you don't agree with everything below.
>...
> Another problem for the release is the Debian installer. The vast
> majority of Debian installations is i386. If the new installer isn't
> ready on all architectures it might be an option to ship some
> architectures without installer in 3.1r0, and add the installer for
> these architectures in 3.1r1 or 3.1r2. This way Debian 3.1 might be
> released more early, and even for the affected architectures it's
> better, since additionally to the status quo (installing and using
> Debian 3.0), they can upgrade to Debian 3.1 .
> 
> 
> Thanks for reading this mail.
> 
> Yours
> Adrian

The problems with porting debian-installer to different archs is
minimal. As shown on the D-I debcamp in Oldenburg porting to a new
architecture can be done over a weekend without any prior knowledge of
d-i. Since then several things have also been simplified in respect to
porting and more people are able to help on the issue.

Given a person with the hardware and time I'm certain support can be
added in a single day. The big problem is getting access to the
hardware directly or indirectly through a tester.

And don't tell me use debians machines unless you are able to provide
accounts for sveral non DD d-i developers (which needs sudo for
additional build-depends needed for that arch).


Well, enough ranting. Overall I think the porting to the remaining
archs is the lesser of the problems of d-i.

MfG
Goswin

Re: MIPS port backlog, autobuilder machines and some arrogance

[Goswin von Brederlow]

Marco d'Itri <[EMAIL PROTECTED]> writes:

> On Nov 15, Chris Cheney <[EMAIL PROTECTED]> wrote:
> 
>  >Another point is do we really want an arch/port to be maintained by only
>  >one person? IMHO there should be at least two people capable and
>  >actually running the buildds for each arch, possibly more when they are
>  >too busy with other things as appears the case with Ryan.
> I fully agree. If a port has not enough developers to care about it,
> then it should not be considered a candidate for releases.

There is a difference between available/existing and responcible.

In this case developer who want to help out with hardware and time are
put down by one power hungry (no offence ment, don't even know who you
are, exagerated to make a point) DD who is blocking any help offered.

MfG
Goswin

PS: realy no offence ment, I just wish other archs where as friendly and open 
ad the m68k buildd community

Re: Some observations regardig the progress towards Debian 3.1

[Eduard Bloch]

Moin Adrian!
Adrian Bunk schrieb am Saturday, den 15. November 2003:

> solved, the next one pups up. For testing to work good, it's required to
> have unstable in a good state. Often new so-versions of libraries enter
> unstable, and e.g. KDE 3.2 might soon go into unstable. If testing
> should be frozen, it's needed to _freeze unstable_ (IOW: require RM
> approval for every upload to unstable). This doesn't need to be under a

_ __  __  _  _   _ _  __ 
   / \   |  \/  || || \ | |   | |__   _ __  ___  | |_ | |_____  _ __ 
  / _ \  | |\/| ||  _|  |  \| |   | '_ \ | '__|/ _ \ | __|| '_ \  / _ \| '__|
 / ___ \ | |  | || |___ | |\  | _ | |_) || |  | (_) || |_ | | | ||  __/| |   
/_/   \_\|_|  |_||_||_| \_|( )|_.__/ |_|   \___/  \__||_| |_| \___||_|   
   |/

SCNR,
Eduard.

Bug#220930: ITP: unace -- De-archiver for .ace files

[Robert Millan]

Package: wnpp
Severity: wishlist

* Package name: unace
  Version : 1.2b
  Upstream Author : Marcel Lemke <[EMAIL PROTECTED]>
* URL : None. Google for "unace-1.2b.tar.gz"
* License : Ambigous
  Description : De-archiver for .ace files

I'm referring to the 1.2b release which has been discontinued upstream
but still lies around. Although current upstream releases are clearly
non-free, the license 1.2b release (which comes with source code) is ambigous.
It seems it was the author's intention that 1.2b was freely distributable
and modifiable, but he didn't clarify that in the sources.

I'll ask the author to re-license either 1.2b or a more recent version under
a free software license.

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux aragorn 2.4.22-1 #1 dv nov 14 14:15:06 CET 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]

Bug#220937: ITP: icecream - non-interactive stream download utility

[Christoph Siess]

Package: wnpp
Version: N/A; reported 2003-11-15
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: icecream
  Version : 0.8
  Upstream Author : Gil Megidish <[EMAIL PROTECTED]>
* URL : http://icecream.sourceforge.net/
* License : GPL
  Description :  icecream is a non-interactive stream download
  utility. It connects to icecast and shoutcast servers and redirects
  all fetched content to an
  stdin-capable player or to media files on your disk. With an option
  turned on, it can save the stream into different files, each
  representing
  the played track. It is also possible to tee the input to both disk
  and stdout.

- -- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux mercler 2.4.18 #1 Mon Jun 9 11:44:13 CEST 2003 i686
Locale: LANG=C, [EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE/tnj0nC/GTAhVf98RAsZ6AJ9dD6I3kh45FetgsXU7by39WSi/kACfZ5Ra
/YINFE8C0SsI5R/ET3bmj3g=
=vBdN
-END PGP SIGNATURE-

Re: POSIX capabilities patch

[Henrique de Moraes Holschuh]

On Sat, 15 Nov 2003, Miquel van Smoorenburg wrote:
> In article <[EMAIL PROTECTED]>,
> Marco d'Itri  <[EMAIL PROTECTED]> wrote:
> >On Nov 15, Junichi Uekawa <[EMAIL PROTECTED]> wrote:
> >Sorry: http://www.linux.it/~md/software/ssd.tgz .
> 
> Should that go into /sbin/init itself, so that you can boot with
> initcaps=eip,cap_setpcap+eip on the command line ? Or is it still
> too early to put that into init upstream ?

It is way in time to have it in init :-)

> I assume init then has to link against libcap or something.
> Would it add a lot of size to the binary ?

If you have to link libcap, probably :-(  OTOH, maybe you can have all
used-only-once code in a different page than the commonly used code, so that
it can be swapped out easily...

Anyway, for init, you might do a much simpler "initcaps=0xf00" that does not
need libcap, if size is a problem.

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

Re: Some observations regardig the progress towards Debian 3.1

[Josip Rodin]

On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> Please read it, and make your own opinions on where I'm right and where
> I'm wrong, even if you might not agree with my opinions on other issues
> or if you don't agree with everything below.

Nice of you to vent steam onto the mailing lists and invite people to
spend time reading. Except that we're not reading anything new, hardly
anyone will bother trying to figure out exactly how the litany is helpful,
and the final result will be that nothing will happen.

The really sad thing in the whole story is that I've become[1] so bored with
our fundamental problems that I can't even force myself to restate them in
these threads, and instead skip over the discussion and foresee the
conclusion.

[1] and undoubtedly many others as well

-- 
 2. That which causes joy or happiness.

Bug#220942: ITP: gswitchit -- Xkb state indicator and switcher for GNOME panel

[Marc DequÃnes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist

* Package name: gswitchit
  Version : 2.5.0
  Upstream Author : Sergey V. Udaltsov <[EMAIL PROTECTED]>
* URL or Web page : http://gswitchit.sourceforge.net/
* License : GPL
  Description : Xkb state indicator and switcher for GNOME panel

This will close RFP #163252.

Zygimantas Berucka <[EMAIL PROTECTED]> created an unofficial package and is okay
to let me take over it.

Description taken from the RFP : (as i'm lazy and will rewrite it when 
packaging it :-P )

GSwitchIt is an XKB toolkit for GNOME. Features:

* Support up to 4 keyboard groups
* Customizable images for each group (see this HOWTO)
* Switching using the applet menu or by click.
* Audible bell on group switching (BTW, it can be turned off!).
* Support for "secondary" groups(i.e. groups reachable only from popup menu).
* Customizable group switch shortcut. Currently ~15 fixed combinations are 
supported (besides the ones in X distribution). Also, user can create its own 
key combination.
* Independent group switching per window (optional)
* Any key combination can be used as switchcut.
* Indicators (Caps Lock, Scroll Lock, Num Lock) can be maintained the same 
per-window way as keyboard groups.
* Abitility to track the configuration changes (setxkbmap compability).
* XKB configuration capplet. Allows per-user XKB settings.
* New: Ability to work correctly with the global (set in /etc/X11/XF86Config) 
XKB configuration.
* New: Optional "default" group - assigned to all new window on creation.

Duck
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/tn/0sczZcpAmcIYRAqJjAJ43Dt2mVVqHjs81BYw7oFb3myA8xQCfSYuN
r91s686lWOIOUtipHSHhQnA=
=gKuQ
-END PGP SIGNATURE-

Re: RFA: A lot of packages

[Daniel Gubser]

Am Sam, 2003-11-15 um 16.52 schrieb Andrés Roldán:
> I will make an upload today then.

sorry to be so late but Christian Perrier made an upload for uptimed
today:

http://packages.qa.debian.org/u/uptimed/news/1.html

Daniel

Bug#220944: ITP: libxklavier -- high-level API for X Keyboard Extension (XKB)

[Marc DequÃnes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist

* Package name: libxklavier
  Version : 0.95
  Upstream Author : Sergey V. Udaltsov <[EMAIL PROTECTED]>
* URL or Web page : http://pdx.freedesktop.org/Software/LibXklavier
* License : LGPL
  Description : high-level API for X Keyboard Extension (XKB)

This follows ITP #220942

Preliminary Description taken from the web site :

libxklavier is a library providing high-level API for X Keyboard
Extension known as XKB. This library is indended to support XFree86
and other commercial X servers. It is useful for creating XKB-related
software (layout indicators etc).

The current features are:
 * Reading XKB configuration registry information (for XFree86)
 * Configuring XKB
 * Application-defined callbacks for many XKB-related events
 * Support for per-window switching etc. 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/toScsczZcpAmcIYRAoJRAJ4gaN8VFYt13uVy1Ppmd5Y1816akgCZASH7
aQrXZ27xF0q7NRoTUvgnTak=
=jwNe
-END PGP SIGNATURE-

ttmkfdir and libfreetype6

[Robin]

Recently, while trying to get rid of packages on my system from the "oldlibs"
section, I noticed that mkttfdir still depends on libttf2.

The newer ttmkfdir version (3.0.9) that RedHat 9 uses works with the
Freetype 2 library, and it has seen much more active development lately
than the version we're using in Debian so I think it might be a good idea
to take 3.0.9 and package it for Debian.

However, I don't know what the ttmkfdir maintainer has planned with ttmkfdir
and I don't want to step on his toes by doing an unwanted NMU. I contacted
Miros/law over a week ago but I haven't heard back from him yet. A glance at
all of his packages shows that he hasn't been active for quite a while. Does
anyone know whether he's still actively maintaining them?

A newer ttmkfdir package, using the 3.0.9 sources from RedHat, is available
from
http://people.debian.org/~robin/ttmkfdir/
Basically it's the RedHat 3.0.9 version with two patches applied to let
it compile without errors on gcc-3.3 and to make it build properly. The
patches that are currently applied to ttmkfdir-1.0 no longer apply to
the newer version but it seems that they are no longer needed, anyway.
Also, it uses CDBS for debian/rules because it's good and makes for easier
maintenance ;-)

Incidentally, using ttmkfdir 3.0.9 would close bug #141621 (.ttc support)
as well.

Would it be a good idea if I did an NMU, seeing how Miros/law himself is
not likely to respond himself anytime soon? None of the bugs against
ttmkfdir are release critical, but its dependency on an old (obsolete)
library is an anachronism and will become more of one if the old
ttmkfdir makes it into the new stable distribution.

Any thoughts?
- Robin


signature.asc
Description: Digital signature

New Ideas on the side of kernel-source/image

[Goswin von Brederlow]

Hi,

given the recent flamewar about the new attempt to package the linux
kernel here are some ideas that surfaced during several discussions on
irc. I want to draw a conclusion here for intrested people who missed
it and for future references.


First some basically already existing stuff:

1. there should be a kernel-source-linux/bsd/hurd/whatever-version
package that it the upstreams pure vanilla source.

2. Each architecture and debian in general should have a patches
relative to that and metapackages to provide a kernel tree. Thats
already there for most archs (all but 2 afaik).

3. Additional patches can be packages up the same way the arch
specific and general debian patches are done.

Currently kernel-package handles that quite good already. Thats all
already available and discussion of the above should be kept out of
here (unless relevant to the ideas below).


Now some new ideas (on which comments and suggestions are welcome):

A) Simplify kernel-image packages, less repetitions

I sugested to make kernel-package contain all the scripts and rules to
build a kernel-image package just like cdbs contains all the basic
stuff to build a deb. The kernel-image package would just contain the
config to be used, specify what patches are involved and any rules
that are uncommon or unforseen by kernel-package.

The unpacking, patching, configuring, stampfiles, etc in the current
kernel-image packages is allways the same and can be handled by one
include statement.


B) Less bug propagation from kernel-package to kernel-images

Now make-kpkg adds pre/postinst/rm and similar files to the
kernel-image packages that handle updating the kernel when installing.
Any bug or change in those scripts requires a complete rebuild of the
kernel-images.

Eduard Block suggested removing the update scripts from the
pre/postinst/rm scripts and adding a "update-kernel" tool that handles
installation and removal of kernels. update-kernel can be fixed or
changed without rebuilding all kernel-images. bootloaders could
provide their own update-kernel scripts (or hook into it) that modify
the menus or just rerun the bootloader whenever the kernel changes.

I too think having a central control point for kernel installs and
removals would be a good idea.

[Note: Even grub needs to update its menu.lst for each kernel if the
correct version is to be shown as title]


C) Reduce the traffic and mirror space for kernel updates, split
modules into groups

Splitting the kernel image itself and the modules into seperate debs
would save a lot of space for powerpc (which has 3 kernel flavours
that can share modules).

Further splitting of the modules into groups (ide-modules,
scsi-modules, net-modules, multimedia-modules,...) was suggested.
Debian-installer has code for splitting up modules into udebs and that
could be reused. One big downside I see with this further splitting is
that users would complain about unsuported hardware because they
didn't install the right module debs.

Personally I'm against splitting up modules into several debs but for
splitting kernel image and modules.


D) Updateable custom build kernels

Many people prefer to configure and build their kernels themself,
mostly because they don't need all the stuff the debian kernel
provides. The drawback is that updates of patches (security fixes?)
need to be tracked manually and a new kernel build manually. People
might have to build several kernel images for each source/patch update
or distribute one kernel image to several systems.

What I propose is a 2 step system that will automate (or through
pining onmly manual updates) these steps.

A package (say kernel-linux-setup) provides a setup utility the user
(group kernel or some other restriction) can use to create a kernel
config of his taste. That would include not only the .config file but
also the set of patches to be used and how flexible updates should be
(e.g. allow 2.4.22-1 to 2.4.22-2 updates only or 2.4.22 to 2.4.23
updates?).

The setup utility then creates a kernel-compile-
package that depends on the right kernel-source, kernel-tree, patches,
utilities and contains the config needed. That package can then be
installed (by the utility?) and hooks itself into any updates of the
kernel source, tree or patches so it gets reconfigured every time they
are updated. That solves the problem of tracking source and patch
updates.

The kernel-compile-* package(s) can rebuild the kernel-image every
time they are configured directly, in the background or mark the
rebuild to be done by a cron job. Problems (like new config options)
could be asked directly (for direct build) or reported via email. The
default answere could be accepted or the build could fail.

After compilation we have a kernel-image-*.deb but what to do with it?
When the image is compiled directly dpkg is still running so it can't
be installed with dpkg itself. Installing it directly (not build a
deb) is somehow bad too. When the image is build in the backgro

Re: Changes in t1lib.

[Branden Robinson]

On Fri, Nov 14, 2003 at 09:20:53PM +0100, Andreas Metzler wrote:
> As t1lib-dev (1.3.1) and libt1-dev (5.0.0) are not API compatible I'd
> consider that a pseudo-package useless or even unwelcome.

Good point.

-- 
G. Branden Robinson|The errors of great men are
Debian GNU/Linux   |venerable because they are more
[EMAIL PROTECTED] |fruitful than the truths of little
http://people.debian.org/~branden/ |men. -- Friedrich Nietzsche


signature.asc
Description: Digital signature

Re: Some observations regardig the progress towards Debian 3.1

[Steve Langasek]

On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:

> During the last months, the number of RC bugs of packages in unstable 
> was constant at 700 bugs including 500 RC bugs in packages that are in
> testing [2].

> Yes, there's the common argument "Don't talk, fix bugs.". Unfortunately
> this doesn't work: Debian is too big. I might e.g. be able to fix 50
> easy to fix RC bugs in unstable, but this would be lost in the noise,
> and wouldn't result in real progress.

> Debian with over 1200 maintainers and over 13000 packages [3] is too big
> to work in the relatively unstructured way it is currently. Announcing
> 0-day NMUs isn't sufficient to get a significant number of bugs fixed,
> it's at least required to organize many bug squashing parties and to 
> work hard to get many people involved in them [4].

Are you planning to organize a bug squashing party, then?

> It's often suggested to remove packages (at least from testing) if the
> maintainer is inactice.

> If a maintainer is MIA, his packages should be orphaned and he should be 
> kicked out of Debian as soon as possible.

> But for a user, it doesn't matter why a package isn't in Debian stable.
> E.g. I've heard questions why gnuchess isn't in Debian 3.0 .

Do you feel there are reasons why
 and the various scripts
floating around to provide daily RC reports fail to ensure that packages
people care about are taken care of in spite of the maintainer?  What
methods would you propose to better balance between providing the
software users need and not distributing packages that are
embarrassingly buggy?

(FWIW, I've never heard of packages being removed from testing on the
grounds of maintainer inactivity -- only on the grounds of package
bugginess.)

> For testing to work good, it's required to have unstable in a good
> state. Often new so-versions of libraries enter unstable, and e.g. KDE
> 3.2 might soon go into unstable. If testing should be frozen, it's
> needed to _freeze unstable_ (IOW: require RM approval for every upload
> to unstable). This doesn't need to be under a "no new upstream code"
> policy at the beginning, but at least beta versions, new so-names and
> major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should
> be avoided.

Yes, I've actually been pondering whether it wouldn't make sense to try
to serialize major transitions (such as soname changes), to improve our
chances of keeping testing both releasable and reasonably up-to-date at
all times.  I've also tried to encourage mini-freezes in cases where
groups of packages were almost-but-not-quite ready for testing.

> Another problem for the release is the Debian installer. The vast
> majority of Debian installations is i386. If the new installer isn't
> ready on all architectures it might be an option to ship some
> architectures without installer in 3.1r0, and add the installer for
> these architectures in 3.1r1 or 3.1r2. This way Debian 3.1 might be
> released more early, and even for the affected architectures it's
> better, since additionally to the status quo (installing and using
> Debian 3.0), they can upgrade to Debian 3.1 .

The new installer isn't ready on even i386 yet.

But based on the progress d-i has made over the past two months, it
looks like the installer has a good chance of being ready -- even on all
architectures -- before the rest of the archive is ready to go.  There
have definitely been some mistakes to learn from in the time since the
woody release, in terms of letting experimental changes loose in
unstable; but sarge is definitely not standing still at this point --
even though the RC bug count doesn't seem to be going down, a lot of
necessary work has been done both on the installer and on clearing the
various blockages in testing.  All things considered, we do seem to be
much closer to a release now than we were 3 months ago.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Some observations regardig the progress towards Debian 3.1

[Goswin von Brederlow]

Karsten Merker <[EMAIL PROTECTED]> writes:

> On Sat, Nov 15, 2003 at 07:15:42PM +0100, Goswin von Brederlow wrote:
> 
> > The problems with porting debian-installer to different archs is
> > minimal. As shown on the D-I debcamp in Oldenburg porting to a new
> > architecture can be done over a weekend without any prior knowledge of
> > d-i. Since then several things have also been simplified in respect to
> > porting and more people are able to help on the issue.
> > 
> > Given a person with the hardware and time I'm certain support can be
> > added in a single day. The big problem is getting access to the
> > hardware directly or indirectly through a tester.
> 
> Unfortunately it is not that simple. Work is underway for several
> architectures, but this takes a lot longer than just a single day or
> a weekend. Don't forget that besides platform-specific bugs in d-i
> (like the crash when selecting another language than US-English on
> mipsel) there are also platform-specific bugs which are probably not
> a problem of d-i itself but show up only in d-i (the busybox-ash
> problem on mipsel comes to my mind).

Ok, but those will only show up once a port is underway.

I was talking about getting d-i build and make it create bootable
images. Testing of the many subcomponents (all the udebs) takes a lot
longer and a lot more testers.

> Besides that there are architectures which cannot dynamically load
> a ramdisk through the bootloader but instead must statically
> compile the initrd into the kernel, which needs a kernel rebuild
> for every new cycle, so turnaround times are quite long.

Thats being worked on for ppc for some time now, which seems to be the
worst case needing a complete kernel compile to add the initrd. Other
archs can link a prebuild image and initrd or use the ppc method once
thats setteled.

> Making a "normal" change and testing it takes up to an hour for me;
> if I need to do a full install to test the change (like the current
> work on the bootloader stuff) takes even longer.
> 
> Nonetheless I do not think that there should be an i386-only release
> of d-i. One of Debian's strengths is the multi-platform support,
> and we should try to keep d-i in sync on all platforms.

One aim for my mail was to rouse some people to help for the other
archs.

MfG
Goswin

zebra not in sarge

[Bao C. Ha]

Hello,

I have just noted that zebra is not in sarge.  Is it going to be phased
out?  Besides quagga, are there any other good routing daemons?

Thanks.
Bao
-- 
Best Regards.
Bao C. Ha
Hacom OpenBrick Distributor USA http://www.hacom.net
voice: (714) 530-8817 fax: (714) 530-8818
8D66 6672 7A9B 6879 85CD 42E0 9F6C 7908 ED95 6B38

Example of really nasty DD behavior

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



Filip Van Raemdonck <[EMAIL PROTECTED]> wrote :

> libxklavier & gswitchit packages are uploaded and waiting to be added by
> ftp-master.

This nasty behavior shows that being an officiel Debian developer
does not mean quality.

I was writing an ITP when you posted that and suddendly, saw all my
work preparation turned into ashes.

You did work on your own without any notice.
May i remeber you the use of IPTs and RFPs ?
These are tools to inform people about works to be done and work in
progress in order to avoid duplicate work.
As u did not fill any ITP nor informed anybody on this RFP, u did make
me loose my time preparing for doing this packaging.

Moreover, while you were running to be the first guy to upload a package,
you forgot that working hand in hand with the upstream author is the
best way to produce a work of good quality.
I did contact him, but you didn't.

Another thing, someone had already packaged this program (see web site);
he is not a Debian developer and has not enought time to become one. But
he has done an interresting job and you could have contacted him and ask
him gently if he was interrested in entering the maintainer process
(because he could have made this package to be prepared and then propose
it into Debian). You could have some respect for his work, even if he is
not a DD.
I did contact him, but you didn't.

I'm informing these two persons about the situation, because i'm sure
u do not have a second for such social activities.


Thx for remebering you're not alone in the world...

Duck
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/tq7ssczZcpAmcIYRAnS5AJ4xugTDwfVLBocOlpo2GMYVeNTD3gCcCpnm
1owYx8FBA+E4TaTwjL+Q6Hs=
=HeXx
-END PGP SIGNATURE-

Already done by someone else

[Duck]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Coin,


Somenone already did the job and forgot the BTS usage.
(see #163252 for more details)
So, i'm closing those ITPs.

Duck
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 

iD8DBQE/tq/hsczZcpAmcIYRAqRdAJ9GnwhUh0RLlbZRsOgkpyImn2tKLwCfSDu2
9iocODQQjBiqJZNRuMxWbI4=
=EusX
-END PGP SIGNATURE-

Re: Some observations regardig the progress towards Debian 3.1

[Blars Blarson]

In article <[EMAIL PROTECTED]> 
[EMAIL PROTECTED] writes:
>Given a person with the hardware and time I'm certain support can be
>added in a single day. The big problem is getting access to the
>hardware directly or indirectly through a tester.

Given that I've spend about 20 hours trying to get debian-installer
working on sparc, and havn't yet tried to boot it, I'm sure you are
wrong.  (Three bugs reported and fixed already, one that still needs
to be filed.)

>And don't tell me use debians machines unless you are able to provide
>accounts for sveral non DD d-i developers (which needs sudo for
>additional build-depends needed for that arch).

As far as I can tell, there are three people who have done any attempt
at getting d-i workin on sparc.  None of them is lacking the needed
hardware.  If hardware was all that was needed, I could have not given
away some of what I've given away, or picked up slightly better
machines for not much money.  I may be given a few in the near future.

-- 
Blars Blarson   [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option.  It is a standard feature.

Re: Example of really nasty DD behavior

[Chad Walstrom]

On Sat, Nov 15, 2003 at 11:55:46PM +0100, Duck wrote:
> I was writing an ITP when you posted that and suddendly, saw all my
> work preparation turned into ashes.

Duck, perhaps you should have written the ITP earlier.  Instead of
complaining, why don't you thank your fellow developer and offer to
co-maintain the package.  Perhaps the package could benefit from your
combined efforts.

-- 
Chad Walstrom <[EMAIL PROTECTED]>   http://www.wookimus.net/
   assert(expired(knowledge)); /* core dump */


pgpacm25aDgft.pgp
Description: PGP signature

Re: POSIX capabilities patch

[Marco d'Itri]

On Nov 15, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:

 >>Sorry: http://www.linux.it/~md/software/ssd.tgz .
 >
 >Should that go into /sbin/init itself, so that you can boot with
 >initcaps=eip,cap_setpcap+eip on the command line ? Or is it still
 >too early to put that into init upstream ?
I don't know. It was a quick hack I made because I wanted to play with
capabilities. I suppose that there is a reason if whoever designed this
did not allow normal programs to raise capabilities.

 >I assume init then has to link against libcap or something.
No, it's not needed.

-- 
ciao, |
Marco | [3073 osO.igcE1/dtA]

Re: Some observations regardig the progress towards Debian 3.1

[Colin Watson]

On Sat, Nov 15, 2003 at 03:42:26PM -0600, Steve Langasek wrote:
> On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> > For testing to work good, it's required to have unstable in a good
> > state. Often new so-versions of libraries enter unstable, and e.g. KDE
> > 3.2 might soon go into unstable. If testing should be frozen, it's
> > needed to _freeze unstable_ (IOW: require RM approval for every upload
> > to unstable). This doesn't need to be under a "no new upstream code"
> > policy at the beginning, but at least beta versions, new so-names and
> > major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should
> > be avoided.
> 
> Yes, I've actually been pondering whether it wouldn't make sense to try
> to serialize major transitions (such as soname changes), to improve our
> chances of keeping testing both releasable and reasonably up-to-date at
> all times.  I've also tried to encourage mini-freezes in cases where
> groups of packages were almost-but-not-quite ready for testing.

I feel we've been getting much better at this over the last few months.
The last Python transition, while a bit hair-raising, went fairly
smoothly in the end for something that affected hundreds of packages;
GNOME 2.4 looks like it should go fairly smoothly once glibc/NPTL is out
of the way; and so on.

> But based on the progress d-i has made over the past two months, it
> looks like the installer has a good chance of being ready -- even on all
> architectures -- before the rest of the archive is ready to go.  There
> have definitely been some mistakes to learn from in the time since the
> woody release, in terms of letting experimental changes loose in
> unstable;

The worst of these was sheer accident, and I think its causes have been
addressed now. Use of experimental is increasing, too.

> but sarge is definitely not standing still at this point -- even
> though the RC bug count doesn't seem to be going down,

Frankly, I don't remember the RC bug count *ever* dropping by much prior
to a release; the pattern has been that the bugs are pushed out to
packages we don't care about, which then get removed. While not perfect,
it gets the job done in finite time, it's pragmatic, and in many ways it
reflects reality.

> All things considered, we do seem to be much closer to a release now
> than we were 3 months ago.

Agreed.

Cheers,

-- 
Colin Watson  [EMAIL PROTECTED]

Re: debian-installer beta 1

[Martin Michlmayr]

* Miquel van Smoorenburg <[EMAIL PROTECTED]> [2003-11-10 00:02]:
> >We are pleased to announce the first beta release of
> >debian-installer, the new installation system for sarge.
> 
> We want screenshots!

http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=455&page=1

-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: zebra not in sarge

[Martin Michlmayr]

* Bao C. Ha <[EMAIL PROTECTED]> [2003-11-15 17:34]:
> I have just noted that zebra is not in sarge.  Is it going to be
> phased out?  Besides quagga, are there any other good routing
> daemons?

zebra has been replaced by quagga in sarge.
-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Sat, Nov 15, 2003 at 03:42:26PM -0600, Steve Langasek wrote:
> On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> 
> > During the last months, the number of RC bugs of packages in unstable 
> > was constant at 700 bugs including 500 RC bugs in packages that are in
> > testing [2].
> 
> > Yes, there's the common argument "Don't talk, fix bugs.". Unfortunately
> > this doesn't work: Debian is too big. I might e.g. be able to fix 50
> > easy to fix RC bugs in unstable, but this would be lost in the noise,
> > and wouldn't result in real progress.
> 
> > Debian with over 1200 maintainers and over 13000 packages [3] is too big
> > to work in the relatively unstructured way it is currently. Announcing
> > 0-day NMUs isn't sufficient to get a significant number of bugs fixed,
> > it's at least required to organize many bug squashing parties and to 
> > work hard to get many people involved in them [4].
> 
> Are you planning to organize a bug squashing party, then?

I'm willing to organize bug squashing parties (one is for sure not 
enough), but this has to be part of a release plan that seems doable and 
that is enforced.

The latest published release plan is quite obsolete.

> > It's often suggested to remove packages (at least from testing) if the
> > maintainer is inactice.
> 
> > If a maintainer is MIA, his packages should be orphaned and he should be 
> > kicked out of Debian as soon as possible.
> 
> > But for a user, it doesn't matter why a package isn't in Debian stable.
> > E.g. I've heard questions why gnuchess isn't in Debian 3.0 .
> 
> Do you feel there are reasons why
>  and the various scripts
> floating around to provide daily RC reports fail to ensure that packages
> people care about are taken care of in spite of the maintainer?  What
> methods would you propose to better balance between providing the
> software users need and not distributing packages that are
> embarrassingly buggy?

- frequent bug squashing parties

- faster orphaning of packages of MIA maintainers


> (FWIW, I've never heard of packages being removed from testing on the
> grounds of maintainer inactivity -- only on the grounds of package
> bugginess.)

A MIA maintainer doesn't fix bugs in his packages, and this can lead to 
the removal of a package.

It's perhaps nitpicking whom of us is right in this case.  ;-)

> > For testing to work good, it's required to have unstable in a good
> > state. Often new so-versions of libraries enter unstable, and e.g. KDE
> > 3.2 might soon go into unstable. If testing should be frozen, it's
> > needed to _freeze unstable_ (IOW: require RM approval for every upload
> > to unstable). This doesn't need to be under a "no new upstream code"
> > policy at the beginning, but at least beta versions, new so-names and
> > major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should
> > be avoided.
> 
> Yes, I've actually been pondering whether it wouldn't make sense to try
> to serialize major transitions (such as soname changes), to improve our
> chances of keeping testing both releasable and reasonably up-to-date at
> all times.  I've also tried to encourage mini-freezes in cases where
> groups of packages were almost-but-not-quite ready for testing.
>...

After nearly three years of testing, my impression is that the hopes 
that testing would be always releasable were never fulfilled.

woody was the first release that started from testing, and there was
much more than half a year between the beginning of the freeze and the 
actual release.

Your work of trying to get packages into testing through mini-freezes
is what I called a "Sysyphos task" in my initial mail: As long as the 
flood of new upstream versions into unstable isn't stopped, there are 
always new problems poping up once the current ones are solved.

You need a freeze at one point (unstable or testing) to get a base where 
you can start to fix the remaining problems without new bugs from new 
upstream versions.

The choices are:
- freeze testing and start then to backport all the bug fixes and 
  security fixes from unstable
- freeze unstable and try to get as many packages as possible from
  unstable into testing (exactly the work you are currently doing, but
  based on a more stable basis)
- freeze unstable and use unstable as a basis

All three choices are doable.

I'd say the first one is most work of the three choices, but these are 
only my personal feelings.

> Steve Langasek

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

加入以下网赚 一个月轻松100元

[snow]

debian-devel:您好!

本人从事网赚已半年，这半年几乎所有的公司都做过，比如：钱友、小站、冲浪的DEGOO、。
但是我觉得那些效率都不高，所以自己研究了最好的以下几个网赚公司，都是收到钱

更多赚钱网站 请到http://snow870726.35123.net/ 咨询


如果你对网络赚钱 有所怀疑 那么请用以下 两个公司 Opt-in-pays Linkburst 
都是只要你账户里面有0。01美元 就付款的

☆Opt-in-pays 邮件+点击,无最小付款,付款方式: paypal/支票/egold.
下线提成: 50%-25%-12.5%-6.25%-3.125 
,无穷层级的,信誉很好,收到了N次钱了.每个月自动付款到帐.操作解说：其操作跟LINK2CASH是一样的,唯一的区别是
进入账户 点read e_mails 点击连接 天一封信 
注册链接:http://opt-in-pays.com/join.php?r=187430



☆Linkburst 
1.赚钱方式: 点击
2.$0 付款
3.付款方式: egold
4.下线提成: 20%-10%-5%-2.5% ?限层级下?
重点特色
1.信誉很好,收到了N次钱了.
2.每月15日前自动付款
3.操作：进入你的帐户后,点PAID LINK2,会看见一大排竖立的连接,其中带
有黑点的表示当前的有效连接,大概每15秒只能点其中一个,加钱0.01,
一分钟后如果还有别的带黑点的,再点,再加钱0.01
注意事项: 平时在线就可以登陆入帐户的PAID LINKS区域,每隔一分钟
刷新一次,看有没有新的带黑点的连接出现.要注意的是,如果已经点过的
连接或者不带黑点的是无效的.

注册地址http://linkburst.com/join.php?r=186201


以下为很好的网赚 其中 现金克隆网  突围网 阳普广告网 都是中文的  



☆现金克隆网 
2003年10月6日新设立的中文网赚公司!前500人注册奖励￥2.00，以人民币或者E-gold方式。全中文界面，容易操作。最低支付普通会员
 
￥25。高级会员帐户里有$0.01就可以申请E-gold，$1时可申请StormPay，或者￥15时申请通过国内银行支付。下线政策：5级：15%，10%，5%，3%，2%。
 


注册链接：http://cashcloner.com/paidmail/site/index.php?refid=3852




突围网 http://www.tuwei.com/?mid=snow870726
非常好的中文网赚 操作容易



阳普广告网  全国唯一一家以问答式广告，为企业提供互联网 广告的门户性网站。 
（绝对正规：浙ICP证：030127）总部设立在东南亚最大的小商品城──浙江义乌。 
操作：回答广告的问 题，每天可以得到1元左右，还在增加。直接下线 
20%,间接下线：10%  
是目前国内最好的网站。以前有做过阳普的朋友知道点击广告回答问题很麻烦很浪费时间，不过，我有一个工具，他可以让你在8分钟内回答所有的问题，不过还要视你的网速决定，我一般10分钟内就可以全部点完。
请如实填写，身份证号码一定要正确，因为他是你收钱的唯一凭据，别的信息可
以在登陆以后再改的，但是身份正是不能修改的，我在刚开始的时候，也是不相 
信，于是我填的信息都是假的，后来后来帐号里的钱却拿不出来呀! 后悔死了。
在这里一定要看你的身份号码正是否正确，身份正号码不仅不可以修改，而且每个身份证只能注册1次。但是支持多个账号，不过要多个身份证多个银行账号。我本人就注册了3个号。他支持工商银行和邮政储蓄和建设银行的转帐。

注册链接： http://www.15668.com/ypuser/ypregister_1.asp?superioruser=snow870726





☆allyousubmitters极好公司，注册就送10$, 
每封信和每个点击都不低于5分，发信量大，且稳定，每天都能得到0.4$以上。最小支付50$,支持EG，6层下线，目前罕见的较高支付的好公司.
  


注册链接：http://www.allyousubmitters.com/pages/index.php?refid=snow870726


更多赚钱网站 请到http://snow870726.35123.net/ 咨询



致
礼!
  　　 snow
  　　 [EMAIL PROTECTED]
  　　 2003-11-16

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Sun, Nov 16, 2003 at 12:34:27AM +, Colin Watson wrote:
> On Sat, Nov 15, 2003 at 03:42:26PM -0600, Steve Langasek wrote:
> > On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> > > For testing to work good, it's required to have unstable in a good
> > > state. Often new so-versions of libraries enter unstable, and e.g. KDE
> > > 3.2 might soon go into unstable. If testing should be frozen, it's
> > > needed to _freeze unstable_ (IOW: require RM approval for every upload
> > > to unstable). This doesn't need to be under a "no new upstream code"
> > > policy at the beginning, but at least beta versions, new so-names and
> > > major upstream releases (e.g. avoid KDE 3.2, but 3.1.5 is OK) should
> > > be avoided.
> > 
> > Yes, I've actually been pondering whether it wouldn't make sense to try
> > to serialize major transitions (such as soname changes), to improve our
> > chances of keeping testing both releasable and reasonably up-to-date at
> > all times.  I've also tried to encourage mini-freezes in cases where
> > groups of packages were almost-but-not-quite ready for testing.
> 
> I feel we've been getting much better at this over the last few months.
> The last Python transition, while a bit hair-raising, went fairly
> smoothly in the end for something that affected hundreds of packages;
> GNOME 2.4 looks like it should go fairly smoothly once glibc/NPTL is out
> of the way; and so on.

glibc/NPTL is an example of a nice new feature that breaks other
packages (e.g. it causes mail loss for some people using the cyrus-imapd
package from testing or unstable).

NPTL is _really_ nice, but these are the changes that wouldn't occur 
after the beginning of a freeze.

>...
> > but sarge is definitely not standing still at this point -- even
> > though the RC bug count doesn't seem to be going down,
> 
> Frankly, I don't remember the RC bug count *ever* dropping by much prior
> to a release; the pattern has been that the bugs are pushed out to
> packages we don't care about, which then get removed. While not perfect,
> it gets the job done in finite time, it's pragmatic, and in many ways it
> reflects reality.
>...

Why is this better than starting a freeze and fixing the bugs in bug 
squashing parties?

The problem with your pragmatic approach is that every of your users has 
other packages he cares about. A package you care zero about might be 
the killer application for some users.

This might not be a problem if it happens for one package, but if it 
happens for e.g. 500 packages the sum of people affected by at least one 
of these removals will be quite large.

If someone wants to answer "But noone cared enough to fix this package!" 
now, he forgets that there is a distinction between developers and users 
of Debian.

> Cheers,
> Colin Watson  [EMAIL PROTECTED]

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Sat, Nov 15, 2003 at 08:48:04PM +0100, Josip Rodin wrote:
> On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> > Please read it, and make your own opinions on where I'm right and where
> > I'm wrong, even if you might not agree with my opinions on other issues
> > or if you don't agree with everything below.
> 
> Nice of you to vent steam onto the mailing lists and invite people to
> spend time reading. Except that we're not reading anything new, hardly
> anyone will bother trying to figure out exactly how the litany is helpful,
> and the final result will be that nothing will happen.
> 
> The really sad thing in the whole story is that I've become[1] so bored with
> our fundamental problems that I can't even force myself to restate them in
> these threads, and instead skip over the discussion and foresee the
> conclusion.
> 
> [1] and undoubtedly many others as well

Yes it is a fundamental problem.

But this problem needs either be fixed in any way or Debian should 
officially announce that it's now a hackers-only distribution, since 
it's due to the lack of stable releases not usable for serious systems.


_Why_ do these threads pop up without any solution if it's a 
fundamental problem?


cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: Bug#220888: ITP: python-eyed3 -- Python module for id3-tags manipulation

[Alexander Winston]

On Sat, 2003-11-15 at 07:20, Alexander Wirt wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: python-eyed3
>   Version : 0.5.1
>   Upstream Author : Travis Shirk <[EMAIL PROTECTED]>
> * URL : http://www.travisshirk.net/eyeD3/
> * License : GPL
>   Description : Python module for id3-tags manipulation
> 
> python-eyed3 is a python module for id3-tags manipulation. 
> It supports Version 1.0,1.1,2.3 and 2.4 id3-tags. It also 
> allows to retrieve informations like length, bitrate from 
> the mp3 file.

Once again, I would change the long description to the following:

A Python module for the manipulation of ID3 tags. It supports versions
1.0, 1.1, 2.3, and 2.4 of the ID3 standard. It can also retrieve
information such as length and bit rate from an MP3 file.


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

Re: Bug#220888: ITP: python-eyed3 -- Python module for id3-tags manipulation

[Alexander Winston]

On Sat, 2003-11-15 at 22:01, Alexander Winston wrote:
> On Sat, 2003-11-15 at 07:20, Alexander Wirt wrote:
> > Package: wnpp
> > Severity: wishlist
> > 
> > * Package name: python-eyed3
> >   Version : 0.5.1
> >   Upstream Author : Travis Shirk <[EMAIL PROTECTED]>
> > * URL : http://www.travisshirk.net/eyeD3/
> > * License : GPL
> >   Description : Python module for id3-tags manipulation
> > 
> > python-eyed3 is a python module for id3-tags manipulation. 
> > It supports Version 1.0,1.1,2.3 and 2.4 id3-tags. It also 
> > allows to retrieve informations like length, bitrate from 
> > the mp3 file.
> 
> Once again, I would change the long description to the following:
> 
> A Python module for the manipulation of ID3 tags. It supports versions
> 1.0, 1.1, 2.3, and 2.4 of the ID3 standard. It can also retrieve
> information such as length and bit rate from an MP3 file.

My apologies. The previous message was intended to go to the entry in
the BTS.


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

Re: gimp1.2: gimp package suggest non-free software

[Branden Robinson]

On Thu, Nov 13, 2003 at 10:36:12PM +1100, Zenaan Harkness wrote:
> On Thu, 2003-11-13 at 19:32, Roberto Suarez Soto wrote:
> > Regarding options available to choose and women breasts' size,
> > quantity is always quality ;-)
[...]
> Sometimes I wonder how I'd feel if some spoke of men in such a
> way. This occurs much less often than its opposite.

There's an analogue; see "Diamonds are a Girl's Best Friend".

If one wants to understand stereotypes and sex roles, one has to
understand that women are sex objects, and men are success objects.

For futher reading:

Deborah Blum, _Sex on the Brain: The Biological Differences Between Men
  and Women_
Warren Farrell, _The Myth of Male Power_
Matt Ridley, _The Red Queen: Sex and the Evolution of Human Nature_

Did any one else notice that we are quite desperately off-topic?

-- 
G. Branden Robinson| If God had intended for man to go
Debian GNU/Linux   | about naked, we would have been
[EMAIL PROTECTED] | born that way.
http://people.debian.org/~branden/ |


signature.asc
Description: Digital signature

Re: Some observations regardig the progress towards Debian 3.1

[Anthony Towns]

On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote:
> below are some subjective opservations and opinions regarding the
> progress towards Debian 3.1 .

This is off-topic for -release. Please restrict any replies to -devel or
private mail.

Cheers,
aj

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

Australian DMCA (the Digital Agenda Amendments) Under Review!
-- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda

Re: Some observations regardig the progress towards Debian 3.1

[Steve Langasek]

On Sun, Nov 16, 2003 at 02:35:57AM +0100, Adrian Bunk wrote:

> The problem with your pragmatic approach is that every of your users has 
> other packages he cares about. A package you care zero about might be 
> the killer application for some users.

> This might not be a problem if it happens for one package, but if it 
> happens for e.g. 500 packages the sum of people affected by at least one 
> of these removals will be quite large.

> If someone wants to answer "But noone cared enough to fix this package!" 
> now, he forgets that there is a distinction between developers and users 
> of Debian.

Er, why point out the distinction between developers and users?  Are you
now suggesting that we have an obligation to maintain any packages that
users ask for, even when those packages are not of interest to *any*
developers?

-- 
Steve Langasek
postmodern programmer


pgpkAPj1ZT7lL.pgp
Description: PGP signature

Re: Some observations regardig the progress towards Debian 3.1

[Philip Charles]

On Sun, 16 Nov 2003, Adrian Bunk wrote:

> But this problem needs either be fixed in any way or Debian should
> officially announce that it's now a hackers-only distribution, since
> it's due to the lack of stable releases not usable for serious systems.
>
> _Why_ do these threads pop up without any solution if it's a
> fundamental problem?

I suppose that I am one of the few DDs that has anything to do with the
selling side of GNU/Linux distros and have day to day contact with J.
Average User.  This is probably why the issue does not get addressed.  On
the commercial side I treat Debian as a meta-distribution, raw material
for specialised installation CDs.  Klaus Knopper and Jon Danzig (Libranet)
treat it in much the same way.

I think I have sold only one Official i386 3.0 set, the others have been
my "Enhanced" set with OOo and the like included.  I am in the final
stages of producing a fast, mindless and low intervention CD for computer
dealers.  Neither of these would be possible without Debian.  I would not
even attempt to build such CDs with other distros, let alone building
installation CDs for GNU Hurd.

As a meta-distribution Debian is superb.  However, it would be good if
Debian could also be more aware of J.Average User.

Phil.

--
  Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand
   +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420
 [EMAIL PROTECTED] - preferred.  [EMAIL PROTECTED]
 I sell GNU/Linux & GNU/Hurd CDs.   See http://www.copyleft.co.nz

Re: Anyone know anything about 3dwm?

[Andrew Pollock]

On Sat, Nov 15, 2003 at 10:03:42AM -0600, Steve Greenland wrote:
> On 14-Nov-03, 19:52 (CST), Sam Hocevar <[EMAIL PROTECTED]> wrote: 
> > On Sat, Nov 15, 2003, Andrew Pollock wrote:
> > 
> > > I'm trying to prepare a QA upload of the 3dwm source package, and close a 
> > > few of the trivial bugs assigned to it (mainly binary package 
> > > descriptions 
> > > being shite).
> > 
> >Yes, they all suck pretty much. Here are my suggestions:
> 
> Can I promote the idea that the 3Dwm summary appear *after* the package
> specific material? I know that a lot of packages do it the way Sam has
> it, but when browsing packages in e.g. aptitude, you often don't have
> much space for the long description, and having to scroll every time to
> skip past the summary is mildly annoying.

Thanks Steve and Sam, I have incorporated both your suggestions along 
witha couple of patches in the BTS and am currently building a new rev of 
the packages for a QA upload with new and improved package descriptions.

regards

Andrew

Re: Some observations regardig the progress towards Debian 3.1

[Adrian Bunk]

On Sat, Nov 15, 2003 at 09:51:55PM -0600, Steve Langasek wrote:
> On Sun, Nov 16, 2003 at 02:35:57AM +0100, Adrian Bunk wrote:
> 
> > The problem with your pragmatic approach is that every of your users has 
> > other packages he cares about. A package you care zero about might be 
> > the killer application for some users.
> 
> > This might not be a problem if it happens for one package, but if it 
> > happens for e.g. 500 packages the sum of people affected by at least one 
> > of these removals will be quite large.
> 
> > If someone wants to answer "But noone cared enough to fix this package!" 
> > now, he forgets that there is a distinction between developers and users 
> > of Debian.
> 
> Er, why point out the distinction between developers and users?  Are you
> now suggesting that we have an obligation to maintain any packages that
> users ask for, even when those packages are not of interest to *any*
> developers?


No, that would be the other extreme, and the optimum is in between.


If a package is not in stable only because the maintainer was MIA or he
didn't care enough, and therefore easy to fix RC bugs weren't fixed,
this doesn't harm the maintainer, it harms Debian.

Not every wish of a user for a package has to be fulfilled, and it's 
obviously correct to remove completely broken and/or obsolete packages.


My sentence might have sounded bit extreme, but this is a result of
seeing that some people on debian-release prefer suggesting to remove a
package from testing over notifying the maintainer that it doesn't build
on one architecture...


> Steve Langasek

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Some observations regardig the progress towards Debian 3.1

[David Starner]

> Debian 3.0 contains 7 CDs with binaries and Debian 3.1 might contain 10
> or more CDs. How do you explain to a user why there are 10 CDs, but this
> popular package is not included, and that package he needs is not
> included?
>
> Saying "The maintainer didn't care enough about the package you need."
> only sounds like a good reason to switch to RedHat...  :-(

There are going to be packages that users want that aren't included.
That's life. We are never going to support every program that anyone
might think they need.

If you were a Debian developer, you could fix this by adopting or at least
NMUing important programs that were unmaintained. Is it easier to stand
on the outside and complain then actually work to making it better?

__
Do you want a free e-mail for life ? Get it at http://www.email.ro/

Re: POSIX capabilities patch

[Henrique de Moraes Holschuh]

On Sun, 16 Nov 2003, Marco d'Itri wrote:
> On Nov 15, Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>  >too early to put that into init upstream ?
> I don't know. It was a quick hack I made because I wanted to play with
> capabilities. I suppose that there is a reason if whoever designed this
> did not allow normal programs to raise capabilities.

But normal programs ARE allowed to raise capabilities, as long as they have
this capability to begin with.  As the kernel stands right now (why? I have
no idea), init has to explicitly request capabilities for its children...
otherwise nothing can, since init is the 'parent' of all.

Maybe it is fear that some 'distracted' admin will lock himself outside of
root, but then, since when we accept that as an excuse for blocking
something?

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

pthread development problem

[Jonathan BENSAMOUN]

Hi,
I've got a little problem developping an application with many threads involved.
I know there is definetly something going wrong in my code because basically,
what happens is that as soon as I launch my threads I cannot close any socket,
in any of all the threads (even the one creating them).
I'm not allowed to post the code here but there is nothing really particular
than some sockets that does not close. I tried in UDP, so it's not a TIME_WAIT
problem and none of my thread is listening on the socket while another thread is
trying to close it. The thread closing the socket is the one opening it.
The close returns 0 but the socket remains open in my "netstat" and I cannot
rebind on it (not a setsockopt stuff b/c UDP). I just wanted to know if you guys
already heard about a such problem.

Looking to isolate the problem I found the same behavior while trying to close a
socket opened by another thread, while this thread recvfrom on it.
I join the test code ...

PS: I hope I post on the good ML, debian-devel seems adapted, even if the recent
posts are not really about development problems.

Best regards
J. Bensamoun


test.c
Description: Binary data