Re: mozilla 0.9.7 <-> galeon

[Shaya Potter]

I've updated my unstable galeon package with a pull from the cvs that
compiles against mozilla 0.9.7

http://www.cs.columbia.edu/~spotter/galeon_1.1-1_i386.deb

wget it, dpkg -i it

it seems to work fine for me.  Note that this is a cvs pull from
11am'ish EST on Dec 25th, so it could be unstable.

shaya

On Tue, 2001-12-25 at 12:21, johan boeckx wrote:
> Possible that with the most recent update of mozilla (0.9.7) there are 
> problems with the dependences with galeon. ?
> 
> thx,
> Johan Boeckx
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-- 
[EMAIL PROTECTED],yucs.org}
http://yucs.org/~spotter/

Re: Bug#126434: ITP: super-sed -- An enhanced version of sed

[Adam Heath]

On 26 Dec 2001, Ganesan R wrote:

> 1. The source tarball is still called sed (the latest version is
>sed-3.52.tar.gz). What are my options of dealing with this other than
>asking upstream to change the source tarball?

You can rename the source tarball when uploading to debian.  No problems.

> 2. I compiled with a program prefix of 's', so super sed binary will be
>called ssed to differentiate it from GNU sed. I'll also use alternatives
>to make this the default sed. This takes care of the binary and the man
>page, however the info pages are still called sed.info, sed.info-1 :-(.

You can't use alternatives in this situation, because the real said doesn't
use them.  alternatives can have multiple slaves, not just one, so the info
pages can be linked to the main binary as the same time the manpages are
linked.

What you want is dpkg-divert.  But I vote against diverting /usr/bin/sed.

Re: Bug#126434: ITP: super-sed -- An enhanced version of sed

[Henrique de Moraes Holschuh]

On Wed, 26 Dec 2001, Adam Heath wrote:
> What you want is dpkg-divert.  But I vote against diverting /usr/bin/sed.

I have to agree with Adam, diverting sed might be dangerous.

HOWEVER, nothing forbids you to package it simply as ssed for now, then
run very comprehensive regression tests to make sure it has no incompatibi-
lities with GNU sed.  Maybe, symlink sed to ssed in your system to help with
this testing. 

If ssed is indeed faster, better, and backwards-compatible, as well as
maintained upstream, we might want to use it as our sed for woody+1
(provided you email enough evidence that it would be a good idea, and the
sed maintainer agrees with the exchange).

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

An alarming trend (no it's not flaimbait.)

[ahzz-debate]

First, i'd like to apologise to the developers that witnessed me 
"spazzing"(as one person described it) over the current state of debian and 
it's stability/buggyness.

Ok, as a one-time debian tier-1 mirror server admin, and a 4 year user 
of debian i'd like to make an observation that I recently went off in 
#debian-devel over.

For some time now there has been an increasing trend in people that I 
know who use debian. It is the view that debian is becoming increasingly 
"old"/outdated, and that developers either a: dont' have the time to properly 
maintain packages, or just don't care. Which the case is here I don't know. I'm 
not intimate with a lot of developers. However, this has been the same view 
that has been slowly dawning over me for a while now.

I see an increasing trend of two critical problems in the way debian 
operates. #1 package age. Let me talk about this one first. There has been a 
relatively (year or two) explosion in the package count. As this package count 
has gone up, packages that I have used for years and that used to work well 
have falen into a sad state or disrepair. I'll use CDRToaster as an example 
here.

As debian "caught up" on versions, CDRToaster became increasingly 
buggy. The last modification that I saw to it over a year ago was to let it 
support > 8x CDR drives. I personaly took the time to patch it and send out a 
patch. I never saw it in debian until the upstream included it approximatly 2 
motnhs later. This is too long of a timeframe for a simple patch to take to 
"fix" something. Now this was a feature enhancement and was easy to accept that 
it took a bit to get back into debian.

The latest bug that has irked me to no end is the fact that cdrtoaster 
has not worked with creating data tracks with a graft on the fly for an unknown 
period of time. It's a simple fix really. Just add the option -graft-points to 
the mkisofs command. Well, here is the buglist of cdrtoaster

* #41009: cdrtoaster: cdrtoaster(1) manpage missing
  Package: cdrtoaster; Reported by: Roland Rosenfeld <[EMAIL PROTECTED]>; 2 
years and 173 days old.
* #75204: cdrtoaster uses xterm
  Package: cdrtoaster; Reported by: Normal User <[EMAIL PROTECTED]>; 1 year 
and 68 days old.
* #78892: unnecessary test for writeable CD-R device
  Package: cdrtoaster; Reported by: Fred Gray <[EMAIL PROTECTED]>; 1 year 
and 21 days old.


Note the age of all of these bugs. Over a year old each. Now the reason 
for this aparantly is that CDRToaster hasn't been updated on the homepage since 
Jan 2001 at ver 1.12. Obviously this package is DEAD. 8-P I'm sad to see it go 
as I am on many usefull programs such as this one.

However, that leaves a problem. I've been told by several developers 
that "it's an upstream problem. send them a patch and when they include it we 
will update". Wel, that argument doesn't work in increasingly common cases like 
this. At this point, it is now (IMHO) the debian packagers problem. If they are 
unwilling or unable to fix it, then the package should be marked as "BAD" or 
"dead-upstream" as a warning to the user that they should pick a different 
utility like this one to use.

What I see happening is this. The package count has increased 
proportionatly to the ammount of bugs per package. This is giving debian a bad 
name. This is driving users away. Eventualy if this continues, debian WILL die 
or be a nice distribution only diehard fans of it's ideals will use.

Now a little history for you to understand my view of why this 
prevaling attitude is annoying to say the least, and has me up in arms over it 
so to speak. When I signed on to distribute debian, it was rock solid. Packages 
were only marginaly out of date. People loved it. Users loved it. Debian people 
trash talked redhat daily over it's bugs.(not all debian folk, just the more 
vocal and publicly seen ones). I have slowly stoped recomending it as the 
number of people that tried it because of me has shifted from mostly "nice 
distro. thanks" to "this is buggy, and out of date. thanks a lot. >:( ".



Ok, this has gotten long enough. I'm proposing as a user that you 
(debian et al) find a way to somehow warn the user that this package is dead 
upstream and that bugs aren't likely to get fixed if the maintainer is 
unwilling/able to fix it. I am also proposing that it be required of a 
maintainer that they have at least a rudimentary ability to fix minor bugs like 
this.

It is my opinion that if you are putting your name to somethign that 
you are providing for download, you are implying that you have accepted 
responsibility for the quality of the software. 

If this is not the case, then debian needs to stop labeling itself as a 
"distro" in the users eyes, and clearly label itself as a system of packaging 
volunteers that have NO responsibility for software bugs at all, and ONLY 
res

Re: An alarming trend (no it's not flaimbait.)

[Henrique de Moraes Holschuh]

On Wed, 26 Dec 2001, [EMAIL PROTECTED] wrote:
>   For some time now there has been an increasing trend in people that
>   I know who use debian. It is the view that debian is becoming
>   increasingly "old"/outdated, and that developers either a: dont'
>   have the time to properly maintain packages, or just don't care.

Does this comment apply to unstable, or just to stable?  Stable being
out-of-date is a very different problem than unstable being out-of-date...

>   However, that leaves a problem. I've been told by several developers
>   that "it's an upstream problem. send them a patch and when they
>   include it we will update". Wel, that argument doesn't work in

This is only a valid excuse when upstream is active. I have often said
something like that re. fetchmail (although it is more like: this is
upstream's ground. If upstream agrees to do it, I will follow him. Bug
forwarded).

On the other hand, if a Debian developer is NOT willing to become upstream
for a package that is being badly maintained upstream, he should orphan that
package, and maybe even request its removal from the archive if the package
state is really bad.

>   the debian packagers problem. If they are unwilling or unable to fix
>   it, then the package should be marked as "BAD" or "dead-upstream" as

Some would even say the package should have a bug filled, severity important
(or higher): "WARNING: package not being maintained actively".  Which should
be closed by the maintainer, when he comes back from lala-land, or when it
is handled over to someone else.

Please file such a bug against that CD recoding package. If
the maintainer complains that he is 'actively maintaining' it, tell him to
stop lying to himself and admit he either needs to become upstream and fix
all bugs, or drop the package (and keep the bug open)

>   a warning to the user that they should pick a different utility like
>   this one to use.

This is actually a good idea. One can use the BTS to file bugs (I suggest
bug severity to be either "important", or if the package is too sorry a
state, "grave" -- but do be very sure of what you're doing if you file a
"grave" bug).

However, do expect to be yelled at if you misfile any such bugs, a lot of
maintainers will not like that at all. You have been warned.

>   Ok, this has gotten long enough. I'm proposing as a user that you
>   (debian et al) find a way to somehow warn the user that this package
>   is dead upstream and that bugs aren't likely to get fixed if the
>   maintainer is unwilling/able to fix it. I am also proposing that it

Right now, using the BTS properly you could do suck marking of packages
without any extra tools.  I expect such packages to be dropped at release
time if they are really unmaintained.

>   be required of a maintainer that they have at least a rudimentary
>   ability to fix minor bugs like this.

I believe most maintainers already take that view. Those who don't, really
should know better.

>   It is my opinion that if you are putting your name to somethign that
>   you are providing for download, you are implying that you have
>   accepted responsibility for the quality of the software. 

Indeed.  I would like to point out, however, that this applies to the
package level too.  If someone maintains a package, and uploads it to Debian,
he better be ready to stand behind the quality of his work. Otherwise, he
should either improve that packaging fast, or get lost (and please orphan
his packages properly while at it). 

'Thank you for all the fishes, do come back when you have the proper skill
level and/or amount of spare time to actually maintain your Debian packages'
may be a harsh thing to say; it looks elitist, even.  But it is the best
thing to do from a QA (and therefore, an user's) point of view, IMHO.  Heck,
one does not even need to leave the project, just take an extended vacation
(BUT FOLLOW THE PROPER PROCEDURE FOR DOING SO, thank you), and come back
later, as many have done in the history of the project.

>   system of packaging volunteers that have NO responsibility for

I (along with many others) will fight using deadly weaponry to avoid such an
fate.  We need responsible maintainers in Debian, not packagers that go
their merry way leaving the distro littered with outdated and often broken
crap.

-- 
  "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: An alarming trend (no it's not flaimbait.)

[Pierfrancesco Caci]

:-> "ahzz-debate" == ahzz-debate  <[EMAIL PROTECTED]> writes:

[...]

>   I see an increasing trend of two critical problems in the way
>   debian operates. #1 package age. Let me talk about this one
>   first. There has been a relatively (year or two) explosion in
>   the package count. As this package count has gone up, packages
>   that I have used for years and that used to work well have
>   falen into a sad state or disrepair. I'll use CDRToaster as an
>   example here. 

[...]

>   However, that leaves a problem. I've been told by several
>   developers that "it's an upstream problem. send them a patch
>   and when they include it we will update". Wel, that argument
>   doesn't work in increasingly common cases like this. At this
>   point, it is now (IMHO) the debian packagers problem. If they
>   are unwilling or unable to fix it, then the package should be
>   marked as "BAD" or "dead-upstream" as a warning to the user
>   that they should pick a different utility like this one to
>   use. 

[...]

>   It is my opinion that if you are putting your name to
>   somethign that you are providing for download, you are
>   implying that you have accepted responsibility for the quality
>   of the software.  

>   If this is not the case, then debian needs to stop labeling
>   itself as a "distro" in the users eyes, and clearly label
>   itself as a system of packaging volunteers that have NO
>   responsibility for software bugs at all, and ONLY responsible
>   and track bugs that come from being packaged. 

[...]



>   Ok, enough of this for tonight. I will now let you all discuss
>   this amongst yourselves since I am not a developer. Should the
>   situation arise that a: I have more free time, and b: that
>   debian either accepts responsibility for packages, or
>   alternativly modifies it's public image to one of being a
>   packager only and keeps up with upstream stuff, then at that
>   point i'd be interested in joining the team to make debian
>   better. 
 
[...]

>   I would appreciate a CC: to [EMAIL PROTECTED] for
>   any emails sent back tot he list directly. For I am not on the
>   debian-devel mailing list.:) 


[...]


Nice bait I'll bite, but if you want to read it you'll have to
subscribe... It's not fair to throw the rock and hide the hand 

1) learn how to properly format a mail message (i.e. fold at 75th
   column)

2) learn how to package a deb and adopt whichever package you think
   you're better at maintaining than the original maintainer

3) if the package is dead upstream, fork it and maintain it
   yourself. Most free software licences allow it.


Have a nice (redhat|mandrake|windowsXP) day

Pf


-- 

---
 Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED]  -  
http://gusp.dyndns.org
  Firenze - Italia  | Office for the Complication of Otherwise Simple Affairs 
 Linux penny 2.4.16 #1 Fri Nov 30 22:12:51 CET 2001 i686 unknown

Re: Bug#125904: ITP: fungetty, a fun new getty for Linux framebuffers

[Christian Kurz]

On 25/12/01, Ben Pfaff wrote:
> Ben Armstrong <[EMAIL PROTECTED]> writes:

> > On Thu, Dec 20, 2001 at 02:36:52AM -0800, Ben Pfaff wrote:
> > > If so, then maybe you should have a look at fungetty, a
> > > replacement for the standard Linux getty that can display
> > > full-color graphics above the login prompt.  I hacked this up
> > > over the last week or so, and it seems to work pretty well.  It
> > > can display many kinds of PNG files above the login prompt.
> > > There are some bugs and limitations, but nothing unreasonable.

> > How does this differ from fbgetty?

> fbgetty doesn't actually implement its `image' command for the
> issue file.  At least, AFAICT.  

And why then don't you hack on fbgetty and add the necessary code? You
could then send me a patch which I forward to the upstream author. So
far he hasn't been biting me and I think he would at least take a close
look at your patch and maybe completely or partial incorporate it. 

Upstream had to first fix some terminal issues which showed up and the
broken secure exec functionality to get fbgetty working fine again. The
next release after the current one, which I'm testing right now, will be
0.2.x and the new feature of actually implementing the image command
would be at least in my opinion a nice feature. So Ben, if you are
interested to hack on fbgetty to get the image functionality implemented
for the next release, just mail me privately. 

Christian
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgpQPvnZw6DlB.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.)

[Adam Olsen]

On Wed, Dec 26, 2001 at 09:38:24AM +0100, Pierfrancesco Caci wrote:
> Nice bait I'll bite, but if you want to read it you'll have to
> subscribe... It's not fair to throw the rock and hide the hand 
> 
> 1) learn how to properly format a mail message (i.e. fold at 75th
>column)
> 
> 2) learn how to package a deb and adopt whichever package you think
>you're better at maintaining than the original maintainer
> 
> 3) if the package is dead upstream, fork it and maintain it
>yourself. Most free software licences allow it.

While it is a bit of a bait, I agree with his assessment.  And I
believe his point is that debian needs a better way to handle packages
that aren't properly maintained, rather than just letting them clutter
up the archives.

-- 
Adam Olsen, aka Rhamphoryncus

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

Duly chastined. :) I discovered a few minutes ago (thanks to a friend 
that is d-d) that I can in fact join the debian-devel list. So I am now lurking 
to read and reply. :)

I'll reply in a few minutes to the other email. :)

Brian

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

Heh, I was not aware that a non-developer could subscribe to d-d.

On Wed, Dec 26, 2001 at 08:41:54AM +, David Graham wrote:

> 
> 
> Nice bait I'll bite, but if you want to read it you'll have to
> subscribe... It's not fair to throw the rock and hide the hand 
> 
> 1) learn how to properly format a mail message (i.e. fold at 75th
>column)

Oops. Darnit, how to do this automaticly with vi?

> 
> 2) learn how to package a deb and adopt whichever package you think
>you're better at maintaining than the original maintainer

Read up on packaging, attempted applying diffs from debian , 
sucessfully I might add. But as for creating new packages... I haven't had a 
lot of time to try it. ;-P Mind you this has been in the last 2 years...

> 
> 3) if the package is dead upstream, fork it and maintain it
>yourself. Most free software licences allow it.

Anyone care to donate a time machine to me? I know this sounds routine
and a lot like an escapeism but. I honestly do not have to time to maintain
my own GPLd software, run a company, advocate Linux smartly, make nice with 
the family, maintain a 5,000 sq ft warehouse, maintain my sanity, and have
a life. Adding package maintenance would be just a little more, but i'd like
to regain at least ONE of the seven days of the week for myself before delving
into somethign as complex as properly packaging a program for debian.

I can say this though, if Debian were to address the issues I have
brought up in a realistic manner, I would be willing to toss my personal time
into the project once I have some available, as well as possibly some idle
company employee time once I can afford it.

After all, I am trying to make a company run on 100% GPLd software.
TerraBox's goal is to be a testimony to the power and usability of Open 
Source software in the business arena. To do less than to toss time back into
the company would be hypocritical at best, and downright dishonestly evil
at worst IMHO.
> 
> 
> Have a nice (redhat|mandrake|windowsXP) day
> 
> Pf

Ack! EVIL! It's still Debian Woody for me. :) I'm not giving up just 
yet.


-- 

Brian Wolfe  <[EMAIL PROTECTED]> "Down to earth computing!"
TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.)

[David D. W. Downey]

* Pierfrancesco Caci ([EMAIL PROTECTED]) wrote:
> 
> Nice bait I'll bite, but if you want to read it you'll have to
> subscribe... It's not fair to throw the rock and hide the hand 
> 
> 1) learn how to properly format a mail message (i.e. fold at 75th
>column)

Quit pickin at the measly stuff and pay attention to the content of
his words. Laying the bear trap here only gets you laughs from the
other hunters.

> 
> 2) learn how to package a deb and adopt whichever package you think
>you're better at maintaining than the original maintainer
> 

Pointing out a failure in a system doesn't mean one has the ability
to do what you are asking. It simply means he found a failure. In
this instance, his becoming a maintainer does nothing to solve the
problem he's point at other than for that single package. Pushing
someone off into this section only further proves the point that
debian's starting to potentially fall apart since you completely
prove that you either failed to hear or desired not to hear what
his content.

> 3) if the package is dead upstream, fork it and maintain it
>yourself. Most free software licences allow it.
> 
> 

Please explain how him maintaining it helps the other packages in
trouble as well. Or are you trying to suggest that the package he
spoke of is the only one of it's kind in trouble or that no other
packages in debian suffer from the fate he describes?

> Have a nice (redhat|mandrake|windowsXP) day
> 

Not even worth more than this snicker.



OK, I'm getting in on this one, regardless of opinions. Sorry, but I
have to agree with Brian here. 

OK, my little history to show what grounds I make my stand on.

I've used linux for quite a few years now. I started with SLS Linux
kern ver 1.0.8), was there at slackware's inception, ran Peanut,
Stampede, Red Hat, Mandrake, and of course Debian.

I've worked in the linux industry for Red Hat, Ensim Corp, and a few
others. I've developed LPIC-II certification tests as a core member of LPI. 

"Why are you listing all that crap bub?" Probably what a few of you
are asking. Only to show my experience with different distros,
linux, and where I feel I gain my credence for my vote for Brian's
comments.

Debian is a solid distro to me. It's got heart, strength of
charactor both in it's member software, and it's member users and
developers. It's withstood 99% of the "Let's add every feature we
can lay our hands on cause that'll show we know what we're doing!"
crowd. It's solidly built, loved, and protected over by a loyal
group of users. This is more than I can say for the majority of the
distributions out there. 

yeah I give other distribs a hard time just like everyone else. it's
fun and part of the game. BUT, there are some real things that
happen to real distros when it's members don't speak of what they
see wrong and *developers* __listen__. 

Folks, our user base (non official developers and general users
alike) deserve to be listened to when they say something.

At least Brian took the time to list things out with well thought
out and deliberately worded and experience backed points. Many of
the "complaints" that a distrib gets are from those that aren't
really for the distro, it's just something they use, they want some
help, they find it's not easy without using the docs, and just
start bad mouthing it to cover their own lack of capability.
The real users have something substantial to their words.

Brian does. I've got to admit up front that I've not been a user of
debian as a primary distribution. And for whatever the comments
made, yes, I've been using Red Hat or Slackware as my primary. I do
run multiple distributions at any given time. There are many that do
because it makes it easier to see where users in general are. 

I have been running Debian since Slink. I've left it, come back,
left it, ran it solid for a bit, then left it again, now I'm back.

Why? Simply because of issues with Debian, be it the installer of
old, the lack of certain support, all different reasons. But one
thing is for sure. I've been able to follow quite a bit of the
lifeline of Debian. I too have watched as packages that Debian used
to keep up to date are now getting moldy. I've watched as developers
have gotten the attitude that the user is here to serve their
programming careers or their kudos meter, rather than the developers
realizing that's who they develop for besides themselves. (Face it
you wouldn't be developing for "Debian" as an official developer if
you didn't believe that it's a community thing and community is made
up of more than just the developers.)

Monitoring all the packages that belong in the Debian distribution
is a mighty tough thing. I'm sure even Brian will grant that. The
point of this excersise is the realization that the reason we have
maintainers in the first place is to make sure that stuff like this
*doesn't* happen to debian. If each maintainer is watching his or
her upstream, updates with their source when it's relea

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

On Wed, Dec 26, 2001 at 08:40:52AM +, David Graham wrote:
> 
> On Wed, 26 Dec 2001, [EMAIL PROTECTED] wrote:
> > For some time now there has been an increasing trend in people that
> > I know who use debian. It is the view that debian is becoming
> > increasingly "old"/outdated, and that developers either a: dont'
> > have the time to properly maintain packages, or just don't care.
> 
> Does this comment apply to unstable, or just to stable?  Stable being
> out-of-date is a very different problem than unstable being out-of-date...

I'm speaking of testing,frozen mainly. Way Back Then(tm) I could depend
on unstable to function better than windows. :) Alas this is no more. And 
Stable looks/feels/smells like my gret grandpa. Open Source simply moves too
fast to keep a stable dist up to date. but good lord! I get visions of a mummy!
*GRIN*

> 
> > However, that leaves a problem. I've been told by several developers
> > that "it's an upstream problem. send them a patch and when they
> > include it we will update". Wel, that argument doesn't work in
> 
> This is only a valid excuse when upstream is active. I have often said
> something like that re. fetchmail (although it is more like: this is
> upstream's ground. If upstream agrees to do it, I will follow him. Bug
> forwarded).

*nod* In the case of upstreams, are there any metrics to approximate
how long it takes to get a bug fixed from upstream? Any kind of tools that
would allow you to manage patches so that a fix the user provides, can be 
used at the debian maintainer leve until it appears from upstream? This would
alleviate the issue of slow upstream maintainers I believe...

> 
> On the other hand, if a Debian developer is NOT willing to become upstream
> for a package that is being badly maintained upstream, he should orphan that
> package, and maybe even request its removal from the archive if the package
> state is really bad.

Agreed. Completely. :) Sadly, this is not the case. Debian has a case 
of Scales. ;-P packages dried up and flaking off, like CDRToaster (My current
target to pick on to keep things centered...)

> 
> > the debian packagers problem. If they are unwilling or unable to fix
> > it, then the package should be marked as "BAD" or "dead-upstream" as
> 
> Some would even say the package should have a bug filled, severity important
> (or higher): "WARNING: package not being maintained actively".  Which should
> be closed by the maintainer, when he comes back from lala-land, or when it
> is handled over to someone else.

This sounds like a good idea. I have heard murmurs of packages getting
tossed that have severe and critical bugs before a release. However, Is it 
logical to apply this same measure to packages in testing that sit with a CRIT
or SEVERE bug status of one or more bugs for an extended period of time?

It does no good to toss things out at the end. I believe that curing
the root of the problem before it interferes with the life of the distro is
the proper method of treating the problem. By kicking a package back into
unstable when it has CRIT bugs for more than a few days, debian can keep
testing clean enough to make a MUCH shorter bug-fix-fest and release cycle.
This is mostly due to nailing these critters as they pop up and don't get
resolved before they acumulate and cause a 6-month long frozen period.


> 
> Please file such a bug against that CD recoding package. If
> the maintainer complains that he is 'actively maintaining' it, tell him to
> stop lying to himself and admit he either needs to become upstream and fix
> all bugs, or drop the package (and keep the bug open)

Aye Aye Captain! ;) 9 times out of ten, i'm beaten to the bug report.
heh. So I loose interest in chasing every one due to believing someone else
has probably reported it allready.

This is a flaw in MY method that I shall strive to change.


> 
> > a warning to the user that they should pick a different utility like
> > this one to use.
> 
> This is actually a good idea. One can use the BTS to file bugs (I suggest
> bug severity to be either "important", or if the package is too sorry a
> state, "grave" -- but do be very sure of what you're doing if you file a
> "grave" bug).

See above about filing bugs. Guilty your honour. ;)
> 
> However, do expect to be yelled at if you misfile any such bugs, a lot of
> maintainers will not like that at all. You have been warned.

Heh. I got yelled at for suggesting someone add a 1 liner to the deb 
.diff once or twice. ;-P I fear not overfiend, why shall I fear a Lesser 
Evil? *duck*

> 
> > Ok, this has gotten long enough. I'm proposing as a user that you
> > (debian et al) find a way to somehow warn the user that this package
> > is dead upstream and that bugs aren't likely to get fixed if the
> > maintainer is unwilling/able to fix it. I am also proposing that it
> 
> Right 

Re: An alarming trend (no it's not flaimbait.)

[Brian Wolfe]

On Wed, Dec 26, 2001 at 01:38:53AM -0800, David D. W. Downey wrote:
> * Pierfrancesco Caci ([EMAIL PROTECTED]) wrote:
> > 
> > Nice bait I'll bite, but if you want to read it you'll have to
> > subscribe... It's not fair to throw the rock and hide the hand 
> > 
> > 1) learn how to properly format a mail message (i.e. fold at 75th
> >column)
> 
> Quit pickin at the measly stuff and pay attention to the content of
> his words. Laying the bear trap here only gets you laughs from the
> other hunters.

I deserved a little bit of this. I'm no saint. :) To be fair he did 
separate this out from the meat of his reply. But thanks for the defense. :)
> 
> > 
> > 2) learn how to package a deb and adopt whichever package you think
> >you're better at maintaining than the original maintainer
> > 
> 
> Pointing out a failure in a system doesn't mean one has the ability
> to do what you are asking. It simply means he found a failure. In
> this instance, his becoming a maintainer does nothing to solve the
> problem he's point at other than for that single package. Pushing
> someone off into this section only further proves the point that
> debian's starting to potentially fall apart since you completely
> prove that you either failed to hear or desired not to hear what
> his content.

He agrees with me on several things. Just a bit more cautious about it.
> 
> > 3) if the package is dead upstream, fork it and maintain it
> >yourself. Most free software licences allow it.
> > 
> > 
> 
> Please explain how him maintaining it helps the other packages in
> trouble as well. Or are you trying to suggest that the package he
> spoke of is the only one of it's kind in trouble or that no other
> packages in debian suffer from the fate he describes?

If I had the time, then i'd be taking over the packages that I use that 
are rather flawed. It's a start. 

> 
> > Have a nice (redhat|mandrake|windowsXP) day
> > 
> 
> Not even worth more than this snicker.
> 
> 
> 
> OK, I'm getting in on this one, regardless of opinions. Sorry, but I
> have to agree with Brian here. 
> 
> OK, my little history to show what grounds I make my stand on.
> 
> I've used linux for quite a few years now. I started with SLS Linux
> kern ver 1.0.8), was there at slackware's inception, ran Peanut,
> 



> Cheerfully singing my name to this,
> 
> -- 

That is a great suggestion! I believe I can toss in some of the one 
developer-type person I have doing work for me to trackign down the root of 
some of custier packages. Mind, his time is on a side-deal agreement, so he 
isn't an "emplyee" in the normal sense of the word. But I will see if I can 
get some of his time in trade to add to this. I'll pick out a few of the 
most-used packages that I have and see what the reality is on them. If they 
are maintained by a slacker (no pun on slackware intented or wanted) then 
I'll swat em with a Clue Bat(tm) as sugested here. :)

FWIW, I love debian for several reasons despite it's flaws... here 
they are in no particular order...

#1 (ok, so this IS the biggest. ;) ) It's not a for-proffit corp! Community 
CAN have a potential influence. It's maintainers *usualy* use the packages 
they maintain daily.

#2 it's the only Ture Open Source distro out there that I know of.

#3 It started with a noble goal in mind, and started with an attitude of 
quality. If not, then where the hell did the idea of apt-get and dpkg come 
from!?!

#4 Pick-o-the-week application ability. More than one editor, browser, 
filemanager, graphics tool, library-, etc, etc, etc. Now this DOES 
need to be curtailed in the interest I described in my first post. But 
for the short haul, until the horse has all it's harness back on it.

-- 

Brian Wolfe <[EMAIL PROTECTED]> "Down to earth computing!"
TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C



pgpZR2zoUoYeU.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Christian Kurz]

Damn, I didn't want to post here anymore, but looks like I need to add
some points. :-(

On 26/12/01, Brian Wolfe wrote:
>   Heh, I was not aware that a non-developer could subscribe to d-d.

Looking at http://lists.debian.org and reading the list description
would have told you that before.

> On Wed, Dec 26, 2001 at 08:41:54AM +, David Graham wrote:
> 

> > Nice bait I'll bite, but if you want to read it you'll have to
> > subscribe... It's not fair to throw the rock and hide the hand 

> > 1) learn how to properly format a mail message (i.e. fold at 75th
> >column)

>   Oops. Darnit, how to do this automaticly with vi?

By reading the documentation or hasn't vi some documentation? Look
around for textwidth and wrapmargin.

> > 2) learn how to package a deb and adopt whichever package you think
> >you're better at maintaining than the original maintainer

>   Read up on packaging, attempted applying diffs from debian , 
> sucessfully I might add. But as for creating new packages... I haven't had a 
> lot of time to try it. ;-P Mind you this has been in the last 2 years...

Aehm, if you already successfully applied the diffs to a source package,
then it's not difficult to build a new debian package from that source.
And it's enough if new developers start by taking over old packages that
they daily use and which have been orphaned. 

> > 3) if the package is dead upstream, fork it and maintain it
> >yourself. Most free software licences allow it.

>   Anyone care to donate a time machine to me? I know this sounds routine
> and a lot like an escapeism but. I honestly do not have to time to 
> maintain
> my own GPLd software, run a company, advocate Linux smartly, make nice with 
> the family, maintain a 5,000 sq ft warehouse, maintain my sanity, and have
> a life. Adding package maintenance would be just a little more, but i'd like
> to regain at least ONE of the seven days of the week for myself before delving
> into somethign as complex as properly packaging a program for debian.

Well, taking over the upstream for a software is quite difficult since
you need to know the source well and be a good programmer. But
maintaining a debian package doesn't require that much time and
knowledge. So if you find enough time to send loud complaintments to
this list and then discuss them, it would be better to stop sending
those complaints but instead spend the time by sending in an ITA or ITO
for some debian package and help improving debian.

>   I can say this though, if Debian were to address the issues I have
> brought up in a realistic manner, I would be willing to toss my personal time
> into the project once I have some available, as well as possibly some idle
> company employee time once I can afford it.

Who is Debian? This is a _volunteer_ _based_ _organization_ so everyone
is spending the time on the tasks he's interested it. And even you won't
be able to force anyone to address the issues who posted, until either
he has enough interested and time to take care of some or you pay some
of our developers to take care of this issues. Or maybe you even find it
enough time to take care of them yourself and contribute that way to
Debian.

Christian

P.S.: I'm aware that some parts of this mail maybe seen as a bait for
flames, but that's not the intention. I'm just writing my own opinion
and statements about this and will now switch back to silence and
disappear in an unseens shadow. :-(
-- 
   Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16  63EC A9E6 67FF 26CC 7853


pgp8mdY3hNyKU.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.)

[Christian Kurz]

So, that's hopefully my last post for quite a long time.

On 26/12/01, David D. W. Downey wrote:
> * Pierfrancesco Caci ([EMAIL PROTECTED]) wrote:
> > 1) learn how to properly format a mail message (i.e. fold at 75th
> >column)

> Quit pickin at the measly stuff and pay attention to the content of
> his words. Laying the bear trap here only gets you laughs from the
> other hunters.

Wrong. If you want people to read a mail and follow the content, then
you have to proper format it, so that's it's easy to read it. Did you
ever read some books or newspapers and noticed the format that they are
using? With your argumentation we can remove all those formatting and
prints books and newspapers on a large paper roll and read it.

> > 2) learn how to package a deb and adopt whichever package you think
> >you're better at maintaining than the original maintainer

> Pointing out a failure in a system doesn't mean one has the ability
> to do what you are asking. It simply means he found a failure. In

Not directly. He found a situation that he think it's flawed and which
needs to be changed. But without either having enough people interested
to take care of it, it won't change until he steps forward and starts
working on changing it.

> this instance, his becoming a maintainer does nothing to solve the
> problem he's point at other than for that single package. Pushing

Wrong, he can then help with other packages, make NMU's if the
maintainer gave him permission or track MIA developers done and then
orphan their package and let Debian QA take care of them. 

> someone off into this section only further proves the point that
> debian's starting to potentially fall apart since you completely
> prove that you either failed to hear or desired not to hear what
> his content.

And you seem to ignore that this is _volunteer_ _based_. Debian
Developers will work on those issues that they are interested in and not
the things you want to see them working on. If you want to see
Developers working on some issue, either start paying them for doing the
work, convince enough to work on the issue or start the work on your
own. The BTS will happily accept your mails and debian-qa will be
interested to hear about MIA developers which you tracked down and which
agree to orphan their packages or aren't reachable in any way.

> "Why are you listing all that crap bub?" Probably what a few of you
> are asking. Only to show my experience with different distros,
> linux, and where I feel I gain my credence for my vote for Brian's
> comments.

And then you are not able to use your experience to create solutions to
help debian but to also start lenghty discussions here? Thanks for
showing me that at least a part of our user base seems to have changed
and see Debian as company which they pay for and which they can force
into working on certain issues. 

> Debian is a solid distro to me. It's got heart, strength of
> charactor both in it's member software, and it's member users and
> developers. It's withstood 99% of the "Let's add every feature we
> can lay our hands on cause that'll show we know what we're doing!"
> crowd. It's solidly built, loved, and protected over by a loyal
> group of users. This is more than I can say for the majority of the
> distributions out there. 

So why are you then not contributing something back to the Debian
project if you quite like it that much?

> Folks, our user base (non official developers and general users
> alike) deserve to be listened to when they say something.

Listening is one thing, but doing something is much better and at least
people like you who according to their own description have enough
experience and knowledge, should think about spending some time on
helping and improving debian by working on it instead of starting
lenghty discussions and complaining loud.

> Why? Simply because of issues with Debian, be it the installer of
> old, the lack of certain support, all different reasons. But one

And you aren't able to work on the installer or even just clearly
describe the people working on it which parts need to be improved in
your opinion and why? Lack of certain support? Try to write exact
descriptions what kind of support you are lacking and then talk with the
maintainers who are responsible for it about adding it or helping them
add it. 

> *doesn't* happen to debian. If each maintainer is watching his or
> her upstream, updates with their source when it's released, and if
> the upstream is *not* providing the updates like they should, either

Pardon? You want to give us a exact defintion for "updates like they
should"? There's no way to define that and sometimes upstream authors
also disappear simply because they have a lack of time.

> announce to the BTS that the source is cold, or attempt to

Why should one do that? If the package is still working fine and
contained no bugs, there's in my opinion no need to do this. And if the
package is too buggy, it's easier to contact the 

Re: An alarming trend (no it's not flaimbait.)

[Anthony Towns]

On Wed, Dec 26, 2001 at 06:34:16AM -0200, Henrique de Moraes Holschuh wrote:
> 'Thank you for all the fishes, do come back when you have the proper skill
> level and/or amount of spare time to actually maintain your Debian packages'

That's all very well (personally I find it a bit insulting and
counterproductive), but it doesn't actually do any good if we don't clean
up after them. You can complain all you want about packages that silently
lapse into unmaintained buginess, but the fact is we're not doing much
better with packages that are orphaned. Bas Zoetekouw posted the results
of a script in mid November that'd help clearing up packages that've
been sitting in the archive unmaintained for ridiculously long periods,
but it doesn't seem to be being used.

Cheers,
aj

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

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf


pgpNbsqnO5Jr9.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[David N. Welton]

Brian, I understand your complaints.  It bugs me, too, to find
software not maintained well.  We are volunteers, though, and as you
realize, it takes a lot of time to do this, and so it happens, on
occasion that someone just can't keep up.  I don't think it's really
fair of people to tell you "hey, see if you can do it better", as you
may not have the free time to work on something, let alone jump
through the beaurocratic hoops that Debian places in the way of people
who want to help.  If you don't have the time, you'll probably end up
not maintaining it well either;-)

As was stated elsewhere, the best way you can make a meaningful
contribution is to file bugs that are "higher level" than "normal", in
order to draw attention to broken packages.  Even this will take you
some time to do properly, as you should read through the existing
reports in order to avoid duplicates.  However, it's a very valuable
service.  I know I appreciate finding that someone has already
reported a problem, and by doing so, possibly blocking buggy software
from going into 'testing' or being released.

Thanks for your time, and happy Debian'ing,
-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> As was stated elsewhere, the best way you can make a meaningful
> contribution is to file bugs that are "higher level" than "normal", in
> order to draw attention to broken packages.  

Oh god no. Please no. Inflating bug severeties just makes it harder to
do releases; if there's a problem with normal bugs being ignored (and,
IMO, there is), it needs to be addressed directly, not worked around by
filing everything as important or higher.

Hrm. At least tell me that I'm misreading this, and what you meant to say
was `` "higher quality" than "average" '' or something.

Cheers,
a *twinge* j

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

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Rune Broberg]

On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> 
> Brian, I understand your complaints.  It bugs me, too, to find
> software not maintained well.  We are volunteers, though, and as you
> realize, it takes a lot of time to do this, and so it happens, on
> occasion that someone just can't keep up.  I don't think it's really
> fair of people to tell you "hey, see if you can do it better", as you
> may not have the free time to work on something, let alone jump
> through the beaurocratic hoops that Debian places in the way of people
> who want to help.  If you don't have the time, you'll probably end up
> not maintaining it well either;-)

This, however, doesn't make it OK, that the work isn't done properly - I
for one know, that I do not have the time to be an active maintainer of
any "major" Debian-package - So I don't. I have, however, considered one
of the smaller packages, where I can overcome the burden of helping out.

Work done poorly is - IMHO - worse than work not done - If a package in
the Debian archives isn't maintained, it should be left open for someone
else to grab - as in "work not done". Otherwise Debian will look like a
bunch of developers, who have everything under control - but who are just
plain poor at coding. And I don't think that's the way we want Debian to
look?

First post on debian-devel from me, hope there were no major errors...

-- 
Rune B. Broberg aka. Mihtjel


pgpgZq5POOU0q.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[David N. Welton]

Anthony Towns  writes:

> On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:

> > As was stated elsewhere, the best way you can make a meaningful
> > contribution is to file bugs that are "higher level" than
> > "normal", in order to draw attention to broken packages.

> Oh god no. Please no. Inflating bug severeties just makes it harder
> to do releases; if there's a problem with normal bugs being ignored
> (and, IMO, there is), it needs to be addressed directly, not worked
> around by filing everything as important or higher.

If the software is broken enough that people find it really doesn't
work for its intended purpose, I agree with Henrique's idea that a bug
should be filed that will block the software from getting released.

> Hrm. At least tell me that I'm misreading this, and what you meant
> to say was `` "higher quality" than "average" '' or something.

If it's going to be a bug that blocks the package from getting into
Debian releases, it better be well thought out, and high-quality, and
certainly not something used lightly.

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
 Personal: http://www.efn.org/~davidw/

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 12:26:50PM +0100, David N. Welton wrote:
> Anthony Towns  writes:
> > On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> > > As was stated elsewhere, the best way you can make a meaningful
> > > contribution is to file bugs that are "higher level" than
> > > "normal", in order to draw attention to broken packages.
> > Oh god no. Please no. Inflating bug severeties just makes it harder
> > to do releases; if there's a problem with normal bugs being ignored
> > (and, IMO, there is), it needs to be addressed directly, not worked
> > around by filing everything as important or higher.
> If the software is broken enough that people find it really doesn't
> work for its intended purpose, I agree with Henrique's idea that a bug
> should be filed that will block the software from getting released.

That's not really what's at issue here though; the bug that started this
thread was "support passing -graft-points to mkisofs". That's not a grave,
critical or serious bug, and, TBH, I can't really see it being even a
normal or important bug. It's just a completely legitimate wishlist request
that'd probably be implemented in a couple of weeks if there was someone
actively working on maintaining cdrtoaster.

The problem isn't that the package is buggy and unusable per se, it's
just that it's not being kept up to date with other software in the
distribution.

Cheers,
aj

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

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf


pgppLljRVr5Al.pgp
Description: PGP signature

Re: latest gnome packages not in sid?

[Josip Rodin]

On Mon, Dec 24, 2001 at 01:47:47PM -0500, Matt Zimmerman wrote:
> Creating a bug report has the advantage of sharing the status of the issue
> with other users and developers, but the disadvantage of annoying
> developers who are oversensitive about bug reports.

How about make a blacklist in the bug tracking system for developers who are
oversensitive about bug reports? ;)

-- 
 2. That which causes joy or happiness.

Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[martin f krafft]

Package: wnpp
Version: N/A; reported 2001-12-26
Severity: wishlist

* Package name: spambouncer
  Version : 1.4
  Upstream Author : Catherine A. Hampton <[EMAIL PROTECTED]>
* URL : http://www.spambouncer.org
* License : GPL
  Description : a powerful user-based anti-spam solution

[cc'd to catherine to inform her of my interest to package this for
debian!]
  
The SpamBouncer is a set of procmail recipes, or instructions, which
search the headers and text of your incoming email for indications of
spam. If spam is identified, there is a plethora of actions you can
take, ranging from tagging, deletion, to complaining to upstream, or
simulating mailer-daemon bounces.

It's updated frequently so as to accomodate for spammers' volatility,
and the package would include an easy way to deal with this.

Please inform me if there is anything that speaks against me packaging
this program.

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux fishbowl 2.4.5 #1 Wed Aug 22 01:11:06 CDT 2001 i686
Locale: LANG=en, LC_CTYPE=en_US

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
"... doch warum sollte nicht jeder einzelne
 aus seinem leben ein kunstwerk machen koennen?"
-- michel foucault

Re: An alarming trend (no it's not flaimbait.)

[Mark Brown]

On Wed, Dec 26, 2001 at 01:57:17AM -0600, [EMAIL PROTECTED] wrote:

>   As debian "caught up" on versions, CDRToaster became
>   increasingly buggy. The last modification that I saw to it over
>   a year ago was to let it support > 8x CDR drives. I personaly
>   took the time to patch it and send out a patch. I never saw it
>   in debian until the upstream included it approximatly 2 motnhs
>   later. This is too long of a timeframe for a simple patch to
>   take to "fix" something. Now this was a feature enhancement and
>   was easy to accept that it took a bit to get back into debian.

It seems perfectly reasonable to punt patches that aren't Debian
specific to upstream.  It helps both upstream and the Debian maintainer
if everyone is working off the same version of the package, particularly
when Debian users try to go upstream for support.  Slow release cycles
already create enough hassle with that without starting to modify the
package under upstream.

Where upstream is inactive or unresponsive things are a little
different, of course.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Fidonet support on dial-in

[Russell Coker]

How popular is Fidonet support in Debian?

Of the people who use it, is it most desired to have a Fido program be 
spawned with stdin/stdout/stderr pointing to a serial port or is it more 
desired that the Fido software be accessed by rsh/ssh connection to a Fido 
server machine?

I'm going to add Fido support to Portslave soon.  I am wondering whether I 
should enable the feature in the Debian package, and how exactly I should 
make it work.

Please reply to this message privately as most people on the list won't be 
interested.

-- 
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/   Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page

Re: why does xlibs-pic exist?

[Marcus Brinkmann]

On Tue, Dec 25, 2001 at 07:47:46PM +0100, Eduard Bloch wrote:
> My prophet, we are really glade to hear your non-constructive, needless and
> useless critism. Go away and use RedHat where you allways get working
> solutions, for more plattforms, better code, hotdogs falling from the sky,
> etc. etc.

Robinsonitis seems to be a contagious disease...

Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann  GNUhttp://www.gnu.org[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[Craig Dickson]

martin f krafft wrote:

> The SpamBouncer is a set of procmail recipes, or instructions, which
> search the headers and text of your incoming email for indications of
> spam. If spam is identified, there is a plethora of actions you can
> take, ranging from tagging, deletion, to complaining to upstream, or
> simulating mailer-daemon bounces.
> 
> It's updated frequently so as to accomodate for spammers' volatility,
> and the package would include an easy way to deal with this.
> 
> Please inform me if there is anything that speaks against me packaging
> this program.

Maybe the answer is obvious to experienced package developers, but what
is the "easy way" you plan to handle SpamBouncer's frequent updates?
It's not an issue for unstable as long as you keep up with the changes,
but how is this going to work in a stable release? A badly-outdated copy
of SpamBouncer isn't terribly useful, and is even mildly dangerous if
you have it configured to automatically send complaints.

Craig

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[martin f krafft]

also sprach Craig Dickson <[EMAIL PROTECTED]> [2001.12.26.1724 +0100]:
> Maybe the answer is obvious to experienced package developers, but what
> is the "easy way" you plan to handle SpamBouncer's frequent updates?

i was simply thinking of a cronjob that received ftp updates and
installs them... of course with intelligence around it to handle
errors...

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
"mirrors should reflect a little before throwing back images."
   -- jean cocteau


pgpEdMmb8AifT.pgp
Description: PGP signature

New alpha package of slash-2.2.0 available

[Eric Van Buggenhaut]

Hi,

I'm currently packaging slash-2.2.0 the weblog code that run Slashdot.

Since our current stable version is 2.2, I build the package for
Potato.

I made the files available at

http://debian.org/~ericvb/potato

Since this package depends on a lot of perl libraries that aren't
currently available for potato, I packaged them too. Since their main
purpose is to be used with slash, I haven't given them all whistle and
bells you might expect from official Debian packages. My main goal
was: providing the libraries and installing cleanly, hence the
occasional lack of Description: field for example. If you have time to
spend on this, please send patches.

All these additional libraries are apt-gettable, you need in your
/etc/apt/sources.list, the following line:

deb http://debian.org/~ericvb/slash potato main

And to install slash+deps:

#apt-get install slash


Some remarks about the upstream slash code:

- it was meant to be installed in /usr/local. Although doc says it can
  be installed 'anywhere', it's been quite hard-coded and I spent
  hours tracking down all the paths used. I saw terrific things like :
  /site, /etc/log, /usr/plugins, etc. I corrected what I faced. There
  certainly are still inconsistencies.
- the Makefile isn't nice either. I did my best to get it working but
  probably didn't do it the most elegant way.

AFAIC, the .deb still lacks a decent postinst script that
automates the installation of slash files.


In other words, I leave the package here for the sake of open source
and collaborative work. I'll keep working on it and in the meantime,
all efforts, patches and comments are welcomme so that we get a decent
package as soon as possible.

Cheers,

-- 
Eric VAN BUGGENHAUT "Los niños son esponjas"
(Amaya Rodrigo Sastre)
\_|_/   Andago
   \/   \/  Av. Santa Engracia, 54
a n d a g o  |--E-28010 Madrid - tfno:+34(91)2041100
   /\___/\  http://www.andago.com
/ | \   "Innovando en Internet"
[EMAIL PROTECTED]

Re: An alarming trend (no it's not flaimbait.)

[Colin Watson]

On Wed, Dec 26, 2001 at 01:57:17AM -0600, [EMAIL PROTECTED] wrote:
>   For some time now there has been an increasing trend in people
> that I know who use debian. It is the view that debian is becoming
> increasingly "old"/outdated, and that developers either a: dont' have
> the time to properly maintain packages, or just don't care. Which the
> case is here I don't know. I'm not intimate with a lot of developers.
> However, this has been the same view that has been slowly dawning over
> me for a while now.

I don't necessarily agree that the situation is as bad as you're
painting it elsewhere in your mail, but it's entirely true that many
packages have serious quality problems.

In the relatively short time I've been a Debian developer (less than a
year), I've taken over several packages in the sort of state you
describe and got them into a better state. I've worked on several others
that have ended up in the hands of the QA group, where they may not
receive the most loving care possible (God knows,
http://bugs.debian.org/[EMAIL PROTECTED] has enough crap on it),
but where they're certainly better off than with nobody watching them at
all. (I say this mostly to try to establish that I've been trying to do
things as well as just talking about them.)

The problem is that this is a very labour-intensive process. Taking over
a badly-maintained package means that I have yet another thing to take
care of on a long-term basis, and my to-do list is pretty long as it is.
More importantly, though, if the package wasn't already orphaned then
taking it over or working on it in any other way can turn into a
political nightmare. Offer to help some people by doing a non-maintainer
upload of their package and you'll get your head bitten off. On the
other hand, many maintainers are great about this, and would be happy to
accept help on their less urgent bugs if only anyone dared to offer it!
And of course some people will just not respond either way through lack
of time or whatever. Thus trying to take action yourself to fix
non-release-critical bugs is an unknown quantity in terms of how much
political flamage you're going to have to wade through, and it can end
up being more trouble than it's worth.

The upshot is that release-critical bugs get attention, because there
are lots of them and there's a general consensus that it's OK for other
people to step in and fix them if the maintainer doesn't have the time.
This encourages bug severity inflation because it sometimes seems like
the only reliable way to get anything done (see elsewhere in this
thread), and it unnecessarily sharpens the tone of people who are going
around fixing things ("why haven't you fixed this grave bug yet?!" - I'm
quite sure I'm guilty of this), which in turn gets maintainers' backs up
and makes them understandably less amenable to letting anybody else work
on their bugs, perpetuating the vicious circle. Then sometimes people
make mistakes in NMUs, which has been the source of any number of
flamewars on -devel in the past.

I don't know what the solution to any of this is short of having
everybody develop industrial-strength thick skins. Perhaps a standard
place where everybody could say up-front what their attitude is would be
useful (http://people.debian.org/~cjwatson/nmu.html is mine, FWIW). I
think encouraging people not to be afraid to offer help in whatever form
is a good idea, although I'm sure somebody will disagree with me.

In general we need development and quality assurance not to be at war
with one another.

>   Ok, enough of this for tonight. I will now let you all discuss
> this amongst yourselves since I am not a developer. Should the
> situation arise that a: I have more free time, and b: that debian
> either accepts responsibility for packages, or alternativly modifies
> it's public image to one of being a packager only and keeps up with
> upstream stuff, then at that point i'd be interested in joining the
> team to make debian better.

I'd say that Debian does accept responsibility for packages, even if we
don't always discharge that responsibility. I hope you consider your
second condition fulfilled, as the only way Debian can improve is by the
efforts of its members.

-- 
Colin Watson  [EMAIL PROTECTED]

orphaned packages in DWN?

[Adam Olsen]

In response to the thread about old packages, I have a specific
suggestion.  How about we post a list of orphaned packages in the
weekly news?  That way the community is kept very aware of where they
can help.  And if somebody gets annoyed by seeing the same package
from week to week, well, by that point it should get removed outright.

-- 
Adam Olsen, aka Rhamphoryncus

Re: Installed dtaus 0.5.1-1 (i386 source)

[Martin Schulze]

Wichert Akkerman wrote:
> Previously Martin Schulze wrote:
> > Do I have to use brackets for you?
> 
> Well, jokes aside, a somewhat more clear description would be
> helpful, I couldn't figure out what it really was immediately.

I'm happy to receive an improved description.

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

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

Re: Why isn't apt internationalized?

[Martin Schulze]

Michael Piefel wrote:
> Am 21.12.01 um 16:01:08 schrieb Gregor Hoffleit:
> > This is to say: In some instances, even no translation is better than a
> > bad translation.
>  
> Quite right, but this was just a quick hack. BTW, why should the
> translation be better than the original? ;-)

Quite simple: Because it should at least be not more confusing than
the original...

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

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

Re: why does xlibs-pic exist?

[John H. Robinson, IV]

On Wed, Dec 26, 2001 at 04:08:34PM +0100, Marcus Brinkmann wrote:
> 
> Robinsonitis seems to be a contagious disease...

grr, i'm _always_ nice, and *never* rude.

-john
-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  

Re: orphaned packages in DWN?

[John H. Robinson, IV]

On Wed, Dec 26, 2001 at 04:53:54PM +, Adam Olsen wrote:
> How about we post a list of orphaned packages in the weekly news?

not every week! news is for _new_ stuff, not the same-old from the
previous week.

perhaps a monthly/biweekly post to #debian-devel, or some other
(moderated) list set up just for such automated reports.

keeping the community updated is a nice thing, this is why so very few
of our lists have closed subscriptions. using DWN as a forum for _this_
purpose i believe is bad.

-john

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[Mark Brown]

On Wed, Dec 26, 2001 at 08:24:52AM -0800, Craig Dickson wrote:

> but how is this going to work in a stable release? A badly-outdated copy
> of SpamBouncer isn't terribly useful, and is even mildly dangerous if
> you have it configured to automatically send complaints.

Fortunately, the program has a feature which causes it to disable
automatic complaint generation if it's not been updated recently.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[Mark Brown]

On Wed, Dec 26, 2001 at 05:41:24PM +0100, martin f krafft wrote:
> also sprach Craig Dickson <[EMAIL PROTECTED]> [2001.12.26.1724 +0100]:

> > Maybe the answer is obvious to experienced package developers, but what
> > is the "easy way" you plan to handle SpamBouncer's frequent updates?

> i was simply thinking of a cronjob that received ftp updates and
> installs them... of course with intelligence around it to handle
> errors...

You'd also need a method for handling systems on dialup connections.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: orphaned packages in DWN?

[Adam Olsen]

On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote:
> On Wed, Dec 26, 2001 at 04:53:54PM +, Adam Olsen wrote:
> > How about we post a list of orphaned packages in the weekly news?
> 
> not every week! news is for _new_ stuff, not the same-old from the
> previous week.

If the same packages get posted repeatedly then they need more drastic
measures.  Reposting them just shows that they've yet to get a
maintainer, and still need one.

> perhaps a monthly/biweekly post to #debian-devel, or some other
> (moderated) list set up just for such automated reports.
> 
> keeping the community updated is a nice thing, this is why so very few
> of our lists have closed subscriptions. using DWN as a forum for _this_
> purpose i believe is bad.

Perhaps.  Certainly, DWN isn't just for developers, so it's a bit off
topic there.  However, posting packages that have gone unmaintained
for a long time, and which we're not planning on removing completely,
would get a response if it was actually used by somebody.


-- 
Adam Olsen, aka Rhamphoryncus

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Anthony Towns  writes:

> Oh god no. Please no. Inflating bug severeties just makes it harder to
> do releases; if there's a problem with normal bugs being ignored (and,
> IMO, there is), it needs to be addressed directly, not worked around by
> filing everything as important or higher.

But I think the point here is that the presence of a jillion normal
bugs, unaddressed for years, constitutes a release-critical bug, and
we want some way to filter such packages out of the release.  At
least, that's what I thought the idea was about.

Re: orphaned packages in DWN?

[Sean Neakums]

begin  Adam Olsen quotation:

> On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote:
>> keeping the community updated is a nice thing, this is why so very few
>> of our lists have closed subscriptions. using DWN as a forum for _this_
>> purpose i believe is bad.
> 
> Perhaps.  Certainly, DWN isn't just for developers, so it's a bit off
> topic there.  However, posting packages that have gone unmaintained
> for a long time, and which we're not planning on removing completely,
> would get a response if it was actually used by somebody.

How about listing packages that are orphaned on DWN once, when it
happens, with a pointer to the full list of orphaned packages?
Something like:

  Three packages were orphaned this week: blah, blorp and foop,
  bringing the total to xxx.  Please see
  http://debian.org/wherever/the/list/lives for the full list.

seems suitable for a user-oriented newsletter.

-- 
 /  |  | The spark of a pin
<[EMAIL PROTECTED]> |  (require 'gnu)  | dropping, falling feather-like.
 \  |  | There is too much noise.

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[martin f krafft]

also sprach Mark Brown <[EMAIL PROTECTED]> [2001.12.26.1822 +0100]:
> You'd also need a method for handling systems on dialup connections.

sure. /etc/ppp/ip-up.d in that case...
as in: if dialup, the cron job would simply drop a file in there
every week, which would delete itself after a successful update...

> "You grabbed my hand and we fell into it, like a daydream - or a
> fever."

where's that from?

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
you will be run over by a beer truck.


pgpzh9gpwQdqe.pgp
Description: PGP signature

Re: orphaned packages in DWN?

[Adam Olsen]

On Wed, Dec 26, 2001 at 05:45:08PM +, Sean Neakums wrote:
> begin  Adam Olsen quotation:
> 
> > On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote:
> >> keeping the community updated is a nice thing, this is why so very few
> >> of our lists have closed subscriptions. using DWN as a forum for _this_
> >> purpose i believe is bad.
> > 
> > Perhaps.  Certainly, DWN isn't just for developers, so it's a bit off
> > topic there.  However, posting packages that have gone unmaintained
> > for a long time, and which we're not planning on removing completely,
> > would get a response if it was actually used by somebody.
> 
> How about listing packages that are orphaned on DWN once, when it
> happens, with a pointer to the full list of orphaned packages?
> Something like:
> 
>   Three packages were orphaned this week: blah, blorp and foop,
>   bringing the total to xxx.  Please see
>   http://debian.org/wherever/the/list/lives for the full list.
> 
> seems suitable for a user-oriented newsletter.

I agree.  Although we should perhaps have a second mailing to
debian-devel listing packages that have been unmaintained for a while,
and are getting old enough to remove.

-- 
Adam Olsen, aka Rhamphoryncus

Re: orphaned packages in DWN?

[Martin Schulze]

Sean Neakums wrote:
> begin  Adam Olsen quotation:
> 
> > On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote:
> >> keeping the community updated is a nice thing, this is why so very few
> >> of our lists have closed subscriptions. using DWN as a forum for _this_
> >> purpose i believe is bad.
> > 
> > Perhaps.  Certainly, DWN isn't just for developers, so it's a bit off
> > topic there.  However, posting packages that have gone unmaintained

DWN: Welcome to Debian Weekly News, a newsletter for the Debian developer 
community.
(from .

> > for a long time, and which we're not planning on removing completely,
> > would get a response if it was actually used by somebody.
> 
> How about listing packages that are orphaned on DWN once, when it
> happens, with a pointer to the full list of orphaned packages?
> Something like:
> 
>   Three packages were orphaned this week: blah, blorp and foop,
>   bringing the total to xxx.  Please see
>   http://debian.org/wherever/the/list/lives for the full list.
> 
> seems suitable for a user-oriented newsletter.

You are invited to provide such information on a regular basis
phrased similar to the recently added packages item.

That's not said to stop you.

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

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

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[Robert van der Meulen]

Quoting martin f krafft ([EMAIL PROTECTED]):
> > "You grabbed my hand and we fell into it, like a daydream - or a
> > fever."
> where's that from?
'dead flag blues', by Godspeed you black emperor!

Greets,
Robert
-- 
  Linux Generation
   encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key.
if you remember the 60's, you weren't there.


pgpZjHImJwA72.pgp
Description: PGP signature

Re: Quake 2 sources GPL'd

[Paul Duncan]

* Erich Schubert ([EMAIL PROTECTED]) wrote:
[snipped]
> BTW: The source has some drawbacks right now i fear:
> As far as i could see it does not include the glx driver (which is the
> only way to use all those nvidia graphics cards) but depends on an old
> mesa version and svgalib.

An patch to add SDL-based GL acceleration to the Quake II source (and
tweak the Makefile so it's more Linux-friendly) is available here:

http://icculus.org/~relnev/main.php

I have no idea if it works or how well it works; I just noticed people
talking about it in #nvidia.

> Greetings,
> Erich

-- 
Paul Duncan <[EMAIL PROTECTED]>pabs on #e (OPN IRC)
http://www.pablotron.org/   OpenPGP Key ID: 0x82C29562



pgpU2xjBh0tHz.pgp
Description: PGP signature

translations

[Hanno Terveen]

hi debian team

i would like to contribute my part to the linux/open source comunity and ive
heard that you never get enough of people who translate stuff for you.
well, i speak both german and english and i thought i could be of use for
you`?!
im totally new to linux but im getting into it steadily and im getting
better every day. i understand the open source idea that you take and give
so what i could give you is my language skill.

contact me if you need me as a translator for any of your projects.

bye, and merry christmas

hanno terveen

[OT] Re: why does xlibs-pic exist?

[Paul Duncan]

* Branden Robinson ([EMAIL PROTECTED]) wrote:
[snipped] 
> THIS IS BECAUSE YOU REFUSE TO READ.

Press the little button below tab and above left shift before sending
any more messages. 

;)

> -- 
> G. Branden Robinson|If you wish to strive for peace of
> Debian GNU/Linux   |soul, then believe; if you wish to
> [EMAIL PROTECTED] |be a devotee of truth, then
> http://people.debian.org/~branden/ |inquire. -- Friedrich Nietzsche

-- 
Paul Duncan <[EMAIL PROTECTED]>pabs on #e (OPN IRC)
http://www.pablotron.org/   OpenPGP Key ID: 0x82C29562



pgpyMAmu9fAuj.pgp
Description: PGP signature

Re: orphaned packages in DWN?

[Adam Olsen]

On Wed, Dec 26, 2001 at 07:15:53PM +0100, Martin Schulze wrote:
> Sean Neakums wrote:
> > begin  Adam Olsen quotation:
> > 
> > > On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote:
> > >> keeping the community updated is a nice thing, this is why so very few
> > >> of our lists have closed subscriptions. using DWN as a forum for _this_
> > >> purpose i believe is bad.
> > > 
> > > Perhaps.  Certainly, DWN isn't just for developers, so it's a bit off
> > > topic there.  However, posting packages that have gone unmaintained
> 
> DWN: Welcome to Debian Weekly News, a newsletter for the Debian developer 
> community.
> (from .

Oops :)

> 
> > > for a long time, and which we're not planning on removing completely,
> > > would get a response if it was actually used by somebody.
> > 
> > How about listing packages that are orphaned on DWN once, when it
> > happens, with a pointer to the full list of orphaned packages?
> > Something like:
> > 
> >   Three packages were orphaned this week: blah, blorp and foop,
> >   bringing the total to xxx.  Please see
> >   http://debian.org/wherever/the/list/lives for the full list.
> > 
> > seems suitable for a user-oriented newsletter.
> 
> You are invited to provide such information on a regular basis
> phrased similar to the recently added packages item.
> 
> That's not said to stop you.

A slap in the face in reality, but then, isn't that what this is all
about?  This is an important issue for debian, but there's many other
important issues too, and in the end the ones that get improved are
the ones that get improved.

Anyway, I did some searching and found two interesting posts, although
not the one by Bas Zoetekouw that was mentioned earlier.  The first is
http://www.geocrawler.com/archives/3/216/2001/11/100/7020148/, and
it mentions a script to remove old bugs from wnpp[0]; Not directly
useful.  The second is
http://lists.debian.org/debian-devel/2000/debian-devel-23/msg01353.html,
which says there's a lintian error/warning called
"ancient-standard-version", which I believe can detect when a debian
package is far behind the upstream version.


[0] Actually, the script is to generate wnpp summaries, which would
help in clearing out old bugs.

-- 
Adam Olsen, aka Rhamphoryncus

Re: translations

[Martin Schulze]

Moin!

Hanno Terveen wrote:
> i would like to contribute my part to the linux/open source comunity and ive
> heard that you never get enough of people who translate stuff for you.
> well, i speak both german and english and i thought i could be of use for
> you`?!
> im totally new to linux but im getting into it steadily and im getting
> better every day. i understand the open source idea that you take and give
> so what i could give you is my language skill.
> 
> contact me if you need me as a translator for any of your projects.

http://ddtp.debian.org/
http://www.infodrom.org/projects/manpages-de/
boot floppies, modconf (see )

Regards,

Joey

-- 
GNU GPL: "The source will be with you... always."

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

Re: [OT] Re: why does xlibs-pic exist?

[Branden Robinson]

On Wed, Dec 26, 2001 at 02:02:26PM -0500, Paul Duncan wrote:
> * Branden Robinson ([EMAIL PROTECTED]) wrote:
> [snipped] 
> > THIS IS BECAUSE YOU REFUSE TO READ.
> 
> Press the little button below tab and above left shift before sending
> any more messages. 
> 
> ;)

It might surprise you, but I have "ctrl:nocaps" in my XF86Config-4 file.
:)  I just hold down the left shift key with my pinky and pound away.

-- 
G. Branden Robinson| When I die I want to go peacefully
Debian GNU/Linux   | in my sleep like my ol' Grand
[EMAIL PROTECTED] | Dad...not screaming in terror like
http://people.debian.org/~branden/ | his passengers.


pgpDMOXupiU8Z.pgp
Description: PGP signature

Re: orphaned packages in DWN?

[Jochen Voss]

Hello,

On Wed, Dec 26, 2001 at 07:15:53PM +0100, Martin Schulze wrote:
> Sean Neakums wrote:
> > How about listing packages that are orphaned on DWN once, when it
> > happens, with a pointer to the full list of orphaned packages?
> > Something like:
> > 
> >   Three packages were orphaned this week: blah, blorp and foop,
> >   bringing the total to xxx.  Please see
> >   http://debian.org/wherever/the/list/lives for the full list.
> > 
> > seems suitable for a user-oriented newsletter.
> 
> You are invited to provide such information on a regular basis
> phrased similar to the recently added packages item.
> 
> That's not said to stop you.

Getting the information is really easy:

there are these "Work-needing packages report for ..." posts
to debian-devel-announce, which contain all necessary information.
Seemingly it can even be extracted automatically: if I feed
the message "Work-needing packages report for Dec 21, 2001"
into the following AWK script

#! /usr/bin/awk -f
/^Total number of orphaned packages: / { total=$NF }
/^The following packages are orphaned:$/ { active=1; count=0; }
/^The following packages are up for adoption:$/ { active=0 }
/^\[NEW\] [^ ]* \(/ {
  if (! active) next;
  count = count + 1;
  packages[count] = $2;
}
END {
  if (count == 0) {
print "No packages were orphaned this week,";
printf "leaving %d orphaned packages.  Please see\n", total
  } else {
if (count == 1) {
  printf "One package was orphaned this week: %s,\n", packages[1];
} else if (count == 2) {
  printf "Two packages were orphaned this week: %s and %s,\n",
packages[1], packages[2];
} else {
  printf "%d packages were orphaned this week: %s",
count, packages[1];
  for (i=2; ihttp://www.debian.org/devel/wnpp/ for the full list.\n"
}

I get

Two packages were orphaned this week: kdoc and ssh-nonfree,
bringing the total to 106.  Please see
http://www.debian.org/devel/wnpp/ for the full list.

Maybe this could even be used in conjunction with procmail.

Jochen
-- 
 Omm
  (0)-(0)
http://www.mathematik.uni-kl.de/~wwwstoch/voss/privat.html


pgpDO57MR3i87.pgp
Description: PGP signature

Re: Quake 2 sources GPL'd

[Stephen Zander]

> "Marcus" == Marcus Brinkmann <[EMAIL PROTECTED]> writes:
Marcus> Let's promote when we have something to promote.

Does this count as something to promote?

http://psdoom.sourceforge.net>

-- 
Stephen

"A duck!"

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Bdale Garbee]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> But I think the point here is that the presence of a jillion normal
> bugs, unaddressed for years, constitutes a release-critical bug

While that's an interesting assertion, the real question is what it means to
"address" a bug.  There are packages with many bugs open against them which
are nevertheless very useful, even essential, packages.  Artificially cranking
up the severity isn't going to make them any better... 

Bdale

Re: orphaned packages in DWN?

[Bdale Garbee]

[EMAIL PROTECTED] (Adam Olsen) writes:

> http://lists.debian.org/debian-devel/2000/debian-devel-23/msg01353.html,
> which says there's a lintian error/warning called
> "ancient-standard-version", which I believe can detect when a debian
> package is far behind the upstream version.

Nope, it tells you when the control file claims the package complies with an
ancient version of debian-policy, which is completely unrelated to the package
version.

Bdale

Re: Bug#126317: ITP: robotournament -- Game where players program their robots against each other

[Gustavo Noronha Silva]

On Mon, 24 Dec 2001 00:45:05 +0100
Erich Schubert <[EMAIL PROTECTED]> wrote:

>   Version : x.y.z
>   Upstream Author : Name <[EMAIL PROTECTED]>
> * URL : http://www.some.org/
> * License : (GPL, LGPL, BSD, MIT/X, etc.)
this information is not so clear... this is bad, you need to
inform at least URL and License... 

please do it

[]s!

-- 
Gustavo Noronha Silva - kov 
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+
|  .''`.  | Debian GNU/Linux:  |
| : :'  : + Debian BR...: +
| `. `'`  + Q: "Why did the chicken cross the road?"  +
|   `-| A: "Upstream's decision." -- hmh  |
*-* -+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+-+

Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution

[martin f krafft]

also sprach Robert van der Meulen <[EMAIL PROTECTED]> [2001.12.26.1922 +0100]:
> > > "You grabbed my hand and we fell into it, like a daydream - or a
> > > fever."
> > where's that from?
> 'dead flag blues', by Godspeed you black emperor!

i knew that, you joker :)
just needed a refreshment...

(mark should possibly credit...)

-- 
martin;  (greetings from the heart of the sun.)
  \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
  
f u cn rd ths, u cn gt a nce jb in th prgrmng indstry


pgppYc4gKZS4V.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.)

[Brian Wolfe]

On Wed, Dec 26, 2001 at 01:43:53PM +, Mark Brown wrote:
> On Wed, Dec 26, 2001 at 01:57:17AM -0600, [EMAIL PROTECTED] wrote:
> 
> > As debian "caught up" on versions, CDRToaster became
> > increasingly buggy. The last modification that I saw to it over
> > a year ago was to let it support > 8x CDR drives. I personaly
> > took the time to patch it and send out a patch. I never saw it
> > in debian until the upstream included it approximatly 2 motnhs
> > later. This is too long of a timeframe for a simple patch to
> > take to "fix" something. Now this was a feature enhancement and
> > was easy to accept that it took a bit to get back into debian.
> 
> It seems perfectly reasonable to punt patches that aren't Debian
> specific to upstream.  It helps both upstream and the Debian maintainer
> if everyone is working off the same version of the package, particularly
> when Debian users try to go upstream for support.  Slow release cycles
> already create enough hassle with that without starting to modify the
> package under upstream.
> 
> Where upstream is inactive or unresponsive things are a little
> different, of course.

Yup, this is the situation that I was attempting to describe, when 
upstream seems to be ignoring the package, debian can then take on some of the 
smaller patches that fix functionality that is broken (such as the grafting 
ability. pretty important in making iso images IMHO>) If the maintainer had 
a way of keeping track of small patches via some method(cvs maybe?) then they 
could peel them back off once the offical patch made it's way back to them 
from upstream months (years even? *shudder*) later.

> 
> -- 
> "You grabbed my hand and we fell into it, like a daydream - or a fever."
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> 

-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

It's a normal bug at the minimal. I couldn't get CDRToaster to even do 
a simple burn of a single directory! So I think the bug description would be 
more like "CDRToaster has failed to follow the evolution of mkisofs's command 
line parameters. As a result many fetures that CDRToaster purports to have now 
fail to work at all." As such this is now a critical or at minimal important 
bug.

On Wed, Dec 26, 2001 at 09:56:10PM +1000, Anthony Towns wrote:
> On Wed, Dec 26, 2001 at 12:26:50PM +0100, David N. Welton wrote:
> > Anthony Towns  writes:
> > > On Wed, Dec 26, 2001 at 12:07:57PM +0100, David N. Welton wrote:
> > > > As was stated elsewhere, the best way you can make a meaningful
> > > > contribution is to file bugs that are "higher level" than
> > > > "normal", in order to draw attention to broken packages.
> > > Oh god no. Please no. Inflating bug severeties just makes it harder
> > > to do releases; if there's a problem with normal bugs being ignored
> > > (and, IMO, there is), it needs to be addressed directly, not worked
> > > around by filing everything as important or higher.
> > If the software is broken enough that people find it really doesn't
> > work for its intended purpose, I agree with Henrique's idea that a bug
> > should be filed that will block the software from getting released.
> 
> That's not really what's at issue here though; the bug that started this
> thread was "support passing -graft-points to mkisofs". That's not a grave,
> critical or serious bug, and, TBH, I can't really see it being even a
> normal or important bug. It's just a completely legitimate wishlist request
> that'd probably be implemented in a couple of weeks if there was someone
> actively working on maintaining cdrtoaster.
> 
> The problem isn't that the package is buggy and unusable per se, it's
> just that it's not being kept up to date with other software in the
> distribution.
> 
> Cheers,
> aj
> 
> -- 

As I said before, thats a rather bad bug. One that will continue to 
cause the package to fail more and more in more common usage. Debian updated
it's version of mkisofs, and thus IT broke CDRToaster. As such this is now in
part a debian specific bug that hasn't been addressed in over a year IMHO.

When a distribution (or maintainer) upgrades a package that other
pack ages depend on, it is NOT up to the upstream to make the affected package 
compliant with the now-upgraded sub-package(mkisofs in this case) work togeather
properly. It's the responsibility of the two packagers to fix this "broken by 
upgrade" bug. This is the core of my beef that got me started.

> Anthony Towns <[EMAIL PROTECTED]> 
> I don't speak for anyone save myself. GPG signed mail preferred.
> 
> The daffodils are coming. Are you?
>   linux.conf.au, February 2002, Brisbane, Australia
> --- http://www.linux.org.au/conf



-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C



pgpfzxLyNUUAf.pgp
Description: PGP signature

FAQ: How do I add custom sections to a dexconf-generated XF86Config or XF86Config-4 file?

[Branden Robinson]

I just wrote this for addition to the Debian X FAQ, and thought I would
post it here since I've been getting asked about this lately.  Also,
it's a bit of signal to counter the noise I generated yesterday under
provocation from Jack Howarth.  :)

Needless to say, XF86Config(7), XF86Config-v3(5), and XF86Config-4(5)
are required reading for people who want to customize their XFree86
server configuration.

*) How do I add custom sections to a dexconf-generated XF86Config or
   XF86Config-4 file?

As of xfree86v3 3.3.6-42 and xfree86 4.1.0-10, the dexconf utility only
writes to part of the X server configuration file, instead of claiming
the entire file for itself.

For XFree86 3.x servers, this is mostly useful for adding XInput and
ServerFlags sections, and for replacing the Files and Modules sections
with something more to the user's liking.

For XFree86 4.x, this enables the replacement of the Files and Modules
sections, and the addition of an arbitrary number of supplementary
Device, InputDevice, Monitor, Screen, and ServerLayout sections.
Sections that are never written by dexconf (ServerFlags, VideoAdaptor,
Modes, and Vendor) can also be added, of course.

The most obvious application of this functionality is to support
additional input devices and multi-headed configurations, but another is
the replacement of, for instance, the Device section with something more
customized.  For instance, the driver for your video card may be buggy
and you may wish to add the 'Option "NoAccel"' flag to the Device
section for your video card.  Dexconf and the debconf questions
associated with it do not support the plethora of possible options (many
of them driver-specific), because it is not a very ambitious tool.

The number one fact to remember about the XFree86 4.x server is that the
first ServerLayout section encountered in the XF86Config-4 file is the
one that is used by default.  It is of course possible to add the
"-layout" option to server invocations, either manually or by
configuring xdm or xinit to do so by default (e.g., by editing
/etc/X11/xinit/xserverrc and/or /etc/X11/xdm/Xservers).

To implement the above example, then, I would add three sections to the
configuration file generated by debconf: a Device section with 'Option
"NoAccel", a Screen section to use that Device in conjunction with a
monitor, and a ServerLayout section to bind the Screen to input devices.
If I want my new ServerLayout to be the default, I'll put it at the top
of the XF86Config-4 file, before the debconf area.  The Device and
Screen sections can go either before or after the debconf area, but I'll
put them before just to keep my customizations together.  Also, I'll
remember to give my new sections unique identifiers so that they don't
collide with the identifiers used by debconf.

Example:

  Section "Device"
  Identifier"Custom Device"
  Driver"ati"
  Option"NoAccel"
  EndSection

  Section "Screen"
  Identifier  "Custom Screen"
  Device  "Custom Device"
  Monitor "Generic Monitor"
  DefaultDepth 24
  Subsection "Display"
  Depth   8
  Modes   "[EMAIL PROTECTED]" "[EMAIL PROTECTED]" "1024x768" 
"800x600" "640x480"
  EndSubsection
  Subsection "Display"
  Depth   16
  Modes   "[EMAIL PROTECTED]" "[EMAIL PROTECTED]" "1024x768" 
"800x600" "640x480"
  EndSubsection
  Subsection "Display"
  Depth   24
  Modes   "[EMAIL PROTECTED]" "[EMAIL PROTECTED]" "1024x768" 
"800x600" "640x480"
  EndSubsection
  EndSection

  Section "ServerLayout"
  Identifier"Custom"
  Screen"Custom Screen"
  InputDevice   "Generic Keyboard" "CoreKeyboard"
  InputDevice   "Configured Mouse" "CorePointer"
  EndSection

  ### BEGIN DEBCONF SECTION
[snip]
  ### END DEBCONF SECTION

Of course, my "Generic Monitor", "Generic Keyboard", and "Configured
Mouse" should be defined in the debconf section of the file, but the
identifier in the monitor section may be different, depending on what
dexconf wrote to the file.

-- 
G. Branden Robinson|   The key to being a Southern
Debian GNU/Linux   |   Baptist: It ain't a sin if you
[EMAIL PROTECTED] |   don't get caught.
http://people.debian.org/~branden/ |   -- Anthony Davidson


pgpjpJcS06Qfr.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

Ok, here is something to look at. How many NEW packages are there in 
the last 2 months? How many of them could have been saved for later due to an 
alternate allready existing? How many don't add a whole lot of value to debian?

Instead of many new packages, why not make people pick up the orphaned 
stuff, and find replacements or adopt packages that have been DOA upstream?

NOTE: I haven't looked at this kind of stats before, nor do I know how 
to find this kind of information. dwn used to list at least 10 to 30 NEW 
things per week. and meanwhile the orphan count rose quickly...

-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Nathan E Norman]

On Wed, Dec 26, 2001 at 03:49:11PM -0600, Brian Wolfe wrote:
>   Instead of many new packages, why not make people pick up the orphaned 
> stuff, and find replacements or adopt packages that have been DOA upstream?

In a volunteer organization, you can't _make_ people do anything.  You
can encourage them to do things, or forbid them from doing things, but
you can't say "Hey Hans, you need to do this project, and Bill needs
to do that project".  Corporations work that way, Debian does not.

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpAcJqKV5Yhf.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Brian Wolfe]

No, but you can do, like you said, and deny them a new package unless 
they take up an older one that matches thier area of expertiece.

For example, (still picking on CDRToaster as an example only at this 
time) if I were the maintainer of mkisofs, and I updated it, thus breaking 
CDRTOaster. then a month or two later I wanted to add a new package that 
debian allready has a functional equivilant of, the maintainer coordinator
(does such a person exist?) would look and see that CDRToaster is DOA upstream, 
and it's pakager hasn't marked it as such and either retired it, or replaced 
it with another package, then the mkisofs maintainer would be asked to adopt 
the CDRToaster if they had the capability to do so.

Now, this is just a theoretical situation, so take it with a grain of 
salt and look more at the idea behind the theory. :) Not saying it's THE 
solution, just an idea of how to keep people from leaving cruft all over, and
encouraging maintainers to check up on packages that require/strongly-reccomend
thier package that they updated. (note, this obviously can't be applied to
core packages very realisticly, just for optional/fringe stuff thats poping up)


On Wed, Dec 26, 2001 at 04:22:42PM -0600, Nathan E Norman wrote:
> On Wed, Dec 26, 2001 at 03:49:11PM -0600, Brian Wolfe wrote:
> > Instead of many new packages, why not make people pick up the orphaned 
> > stuff, and find replacements or adopt packages that have been DOA upstream?
> 
> In a volunteer organization, you can't _make_ people do anything.  You
> can encourage them to do things, or forbid them from doing things, but
> you can't say "Hey Hans, you need to do this project, and Bill needs
> to do that project".  Corporations work that way, Debian does not.
> 
> -- 
> Nathan Norman - Staff Engineer | A good plan today is better
> Micromuse Ltd. | than a perfect plan tomorrow.
> mailto:[EMAIL PROTECTED]   |   -- Patton



-- 

TerraBox.comFingerprint: 2849 5090 D4E0 2A6C C648  A750 52F8 8504 67DB 205C



pgpjWBbRXK2gK.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Seems to me that we came up with a solution for this problem a while
ago: the Debian QA team.  Right now it has eight people, and an
overwhelming workload.  I think a QA team is the right thing here;
presumably it can have the discussions about whether particular
packages are so stale they should be removed.

But I suspect that eight people is nowhere near enough people.  Maybe
I could join...  Indeed, maybe the problem would go away if everyone who
has posted a suggestion in this thread joined the QA team and started work.

Maybe we need a way to make being on the QA team a sexy job, just like
maintaining glibc or the kernel or X is.

Re: An alarming trend (no it's not flaimbait.)

[Amaya]

Anthony Towns dijo:
> Bas Zoetekouw posted the results of a script in mid November that'd
> help clearing up packages that've been sitting in the archive
> unmaintained for ridiculously long periods, 

Could anyone ponit me to that script? Google can't help me this time :-)

-- 
 .''`.  "No tengo el coño pa ruidos" -- David Amor, dear friend
: :' :  
`. `' Proudly running Debian GNU/Linux Sid (Kernel 2.4.14)  
  `-www.amayita.com  www.malapecora.com  www.chicasduras.com

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Olsen]

On Wed, Dec 26, 2001 at 03:02:48PM -0800, Thomas Bushnell, BSG wrote:
> 
> Seems to me that we came up with a solution for this problem a while
> ago: the Debian QA team.  Right now it has eight people, and an
> overwhelming workload.  I think a QA team is the right thing here;
> presumably it can have the discussions about whether particular
> packages are so stale they should be removed.

I agree, but I was trying to get more obvious mechanisms for them to
use.

> 
> But I suspect that eight people is nowhere near enough people.  Maybe
> I could join...  Indeed, maybe the problem would go away if everyone who
> has posted a suggestion in this thread joined the QA team and started work.

I'd be more than willing to help, but I'm not a debian developer.
(heh, anybody live in edmonton alberta?)

> 
> Maybe we need a way to make being on the QA team a sexy job, just like
> maintaining glibc or the kernel or X is.

I HOPE that's a joke.  Mentioning the X maintainer (*cough* no names
*cough) in the same sentance as "sexy" is just wrong imnsho.

-- 
Adam Olsen, aka Rhamphoryncus

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Nathan E Norman]

On Wed, Dec 26, 2001 at 04:52:39PM -0600, Brian Wolfe wrote:

[ a bunch of stuff I didn't read, because ... ]

If you're going to participate on the debian mailing lists, consider
doing so with a mailer that understands and honors the
Mail-Followup-To: header (yes, I know it's not an "official" standard,
but it's considered a standard on debian lists).

I don't need copies of list mail unless I ask for them.  I read the
lists.  Please don't Cc: me on list mail.  Etc.

[ rest of rant deleted ]

-- 
Nathan Norman - Staff Engineer | A good plan today is better
Micromuse Ltd. | than a perfect plan tomorrow.
mailto:[EMAIL PROTECTED]   |   -- Patton


pgpqwCUcCF1xZ.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Olsen <[EMAIL PROTECTED]> writes:

> I HOPE that's a joke.  Mentioning the X maintainer (*cough* no names
> *cough) in the same sentance as "sexy" is just wrong imnsho.

I dunno, he looks pretty nice in the pic on his web page. :)

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Olsen <[EMAIL PROTECTED]> writes:

> > But I suspect that eight people is nowhere near enough people.  Maybe
> > I could join...  Indeed, maybe the problem would go away if everyone who
> > has posted a suggestion in this thread joined the QA team and started work.
> 
> I'd be more than willing to help, but I'm not a debian developer.
> (heh, anybody live in edmonton alberta?)

You don't have to be a developer to be a QA person; see qa.debian.org
for details.

And there are currently two developers who live in Edmonton.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Olsen]

On Wed, Dec 26, 2001 at 03:37:15PM -0800, Thomas Bushnell, BSG wrote:
> Adam Olsen <[EMAIL PROTECTED]> writes:
> 
> > > But I suspect that eight people is nowhere near enough people.  Maybe
> > > I could join...  Indeed, maybe the problem would go away if everyone who
> > > has posted a suggestion in this thread joined the QA team and started 
> > > work.
> > 
> > I'd be more than willing to help, but I'm not a debian developer.
> > (heh, anybody live in edmonton alberta?)
> 
> You don't have to be a developer to be a QA person; see qa.debian.org
> for details.
> 
> And there are currently two developers who live in Edmonton.

Oh, err umm... I need more excuses.  Anybody got any suggestions? ;)

-- 
Adam Olsen, aka Rhamphoryncus

apt-move & debootstrap

[Matthijs Melchior]

Hello debian,
   We are using boot-floppies_3.0.18 to newly install debian on the
new computer of my son.  To not have to download through my slow cable
connection, I have used apt-move om my own computer to convert the
very big /var/cache/apt/archive to a local mirror structure.
Now dbootstrap starts with getting /mirrors/debian/dists/sid/Release,
and this file is not there.
I have been searching all apt-* tools, some of the mailing lists and
documentation but nowhere is this file mentioned.  I see the real
archives do have this file as well as Release files in all leaf directories.
Please, can you point me somewhere I can find out how to get these
Release files created.
--
Thanks,
  -o)
Matthijs Melchior   Maarssen  /\\
[EMAIL PROTECTED]  +31 346 570616  Netherlands _\_v
 

Re: orphaned packages in DWN?

[Anthony Towns]

On Wed, Dec 26, 2001 at 07:07:54PM +, Adam Olsen wrote:
> Anyway, I did some searching and found two interesting posts, although
> not the one by Bas Zoetekouw that was mentioned earlier.  

http://lists.debian.org/debian-qa/2001/debian-qa-200111/msg00188.html

Cheers,
aj

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

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf

Re: grsecurity kernel patch ITO

[Jonathan McDowell]

On Wed, Dec 19, 2001 at 08:14:30AM +0100, Russell Coker wrote:
> I have packaged the grsecurity kernel patch, but it hasn't gone into unstable 
> apparently because of the process of freezing for woody release.
> 
> Now the LSM kernel patch that I maintain is getting some of the features of 
> grsecurity (the next version has a port of OpenWall to 2.4.16) and I have 
> less interest in it.
> 
> The main patch package is on http://www.coker.com.au/grsec/
 
FWIW I have now taken over the maintainence of this and you can find my
work at:

http://www.earth.li/~noodles/grsec/

It's been updated for the 2.4.17 kernel.

J.

-- 
/-\ |  CAFFEINE!
|@/  Debian GNU/Linux Developer |
\-  |


pgptBMeEkQtb4.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 09:36:13AM -0800, Thomas Bushnell, BSG wrote:
> Anthony Towns  writes:
> > Oh god no. Please no. Inflating bug severeties just makes it harder to
> > do releases; if there's a problem with normal bugs being ignored (and,
> > IMO, there is), it needs to be addressed directly, not worked around by
> > filing everything as important or higher.
> But I think the point here is that the presence of a jillion normal
> bugs, unaddressed for years, constitutes a release-critical bug, and
> we want some way to filter such packages out of the release.  At
> least, that's what I thought the idea was about.

No, it's not that simple. dpkg is perfectly releasable right now, in spite
of a jillion normal bugs. Heck, now that Wichert and Adam are working on it,
it's even an example of a well maintained package.

There's a place for bugs like "This unmaintained package is not release
quality anymore", but I don't think it's really a good idea for users
in general to be filing them: you need to check the package really
is unmaintained and make sure that no one else is interested in doing
anything about it before you worry about it, at least, which is a job
for developers (ideally the -qa team).

Cheers,
aj

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

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf


pgp83o7K7P354.pgp
Description: PGP signature

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Anthony Towns  writes:

> No, it's not that simple. dpkg is perfectly releasable right now, in spite
> of a jillion normal bugs. Heck, now that Wichert and Adam are working on it,
> it's even an example of a well maintained package.

So, picking one at random, why is bug 9085 still open?  

> There's a place for bugs like "This unmaintained package is not release
> quality anymore", but I don't think it's really a good idea for users
> in general to be filing them: you need to check the package really
> is unmaintained and make sure that no one else is interested in doing
> anything about it before you worry about it, at least, which is a job
> for developers (ideally the -qa team).

I think I do agree about this part.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Wichert Akkerman]

Previously Thomas Bushnell, BSG wrote:
> So, picking one at random, why is bug 9085 still open?  

Because since we started working on it again we've had lots
more pressing things to look into that a bug like #9085?

Wichert.

-- 
  _
 /[EMAIL PROTECTED] This space intentionally left occupied \
| [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0  2805 3CB8 9250 2FA3 BC2D |

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Wichert Akkerman <[EMAIL PROTECTED]> writes:

> Previously Thomas Bushnell, BSG wrote:
> > So, picking one at random, why is bug 9085 still open?  
> 
> Because since we started working on it again we've had lots
> more pressing things to look into that a bug like #9085?

So I picked that bug totally at random; and my intention is not to
poke at the hard-working dpkg maintainers.

Perhaps the metric is not "are there bugs that have gone unattended
for four years", but "are there no bugs that have gotten any attention
for years".  The latter test might well be better.

Still, if there are bugs that have gone unattended for four years,
then *something* is broken, but not necessarily something that the
dpkg maintainers can fix.  Perhaps the hard-working (overworked) QA
team can also have a priority list of very-old bugs.  Or perhaps there
need to be more people working on such packages.  I don't know.

What I see is just a symptom; I have no certain diagnosis.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Anthony Towns]

On Wed, Dec 26, 2001 at 06:39:34PM -0800, Thomas Bushnell, BSG wrote:
> Wichert Akkerman <[EMAIL PROTECTED]> writes:
> > > So, picking one at random, why is bug 9085 still open?  
> > Because since we started working on it again we've had lots
> > more pressing things to look into that a bug like #9085?
> Perhaps the metric is not "are there bugs that have gone unattended
> for four years", but "are there no bugs that have gotten any attention
> for years".  The latter test might well be better.

It's more a matter of triage, IMO: ie, "if the more important bugs
haven't gotten any attention for some time", then you can assume the
package isn't being maintained well.

If there are just lots of less important bugs that aren't getting attention,
then we're either short on manpower, or not using the manpower we have as
well as we might.

Cheers,
aj

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

The daffodils are coming. Are you?
  linux.conf.au, February 2002, Brisbane, Australia
--- http://www.linux.org.au/conf

Re: An alarming trend (no it's not flaimbait.)

[Adam Heath]

On Wed, 26 Dec 2001, Brian Wolfe wrote:

> > Where upstream is inactive or unresponsive things are a little
> > different, of course.
>
>   Yup, this is the situation that I was attempting to describe, when
> upstream seems to be ignoring the package, debian can then take on some of the
> smaller patches that fix functionality that is broken (such as the grafting
> ability. pretty important in making iso images IMHO>) If the maintainer had
> a way of keeping track of small patches via some method(cvs maybe?) then they
> could peel them back off once the offical patch made it's way back to them
> from upstream months (years even? *shudder*) later.

dbs(doogie build system, debian build system)

See autofs, apache, x(contains a pre-alpha version of dbs).

Do NOT see glibc, gcc.  Those use dpatch, which was around before dbs.  Dbs
has a larger following(but well  under 100 packages use it).

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On Wed, 26 Dec 2001, Brian Wolfe wrote:

>   It's a normal bug at the minimal. I couldn't get CDRToaster to even do
> a simple burn of a single directory! So I think the bug description would be
> more like "CDRToaster has failed to follow the evolution of mkisofs's command
> line parameters. As a result many fetures that CDRToaster purports to have now
> fail to work at all." As such this is now a critical or at minimal important
> bug.

The package works for some people(those who have the old version of mkisofs
installed).  This makes the priority of the bug important.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Heath <[EMAIL PROTECTED]> writes:

> On Wed, 26 Dec 2001, Brian Wolfe wrote:
> 
> > It's a normal bug at the minimal. I couldn't get CDRToaster to even do
> > a simple burn of a single directory! So I think the bug description would be
> > more like "CDRToaster has failed to follow the evolution of mkisofs's 
> > command
> > line parameters. As a result many fetures that CDRToaster purports to have 
> > now
> > fail to work at all." As such this is now a critical or at minimal important
> > bug.
> 
> The package works for some people(those who have the old version of mkisofs
> installed).  This makes the priority of the bug important.

Um, if it doesn't work for the version of mkisofs in woody, then it is
a critical bug as far as woody is concerned.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On Thu, 27 Dec 2001, Anthony Towns wrote:

> On Wed, Dec 26, 2001 at 09:36:13AM -0800, Thomas Bushnell, BSG wrote:
> > Anthony Towns  writes:
> > > Oh god no. Please no. Inflating bug severeties just makes it harder to
> > > do releases; if there's a problem with normal bugs being ignored (and,
> > > IMO, there is), it needs to be addressed directly, not worked around by
> > > filing everything as important or higher.
> > But I think the point here is that the presence of a jillion normal
> > bugs, unaddressed for years, constitutes a release-critical bug, and
> > we want some way to filter such packages out of the release.  At
> > least, that's what I thought the idea was about.

> No, it's not that simple. dpkg is perfectly releasable right now, in spite
> of a jillion normal bugs. Heck, now that Wichert and Adam are working on it,
> it's even an example of a well maintained package.

Both Wichert and I go in spurts.  Once about every 4 months or so, it seems.
We usually don't do it at the same time either.

I do tend to read all the dpkg bugs once every 4 months.  I tend to fix bugs
that are similiar each time I do so.  My last go at dpkg I fixed most
outstanding install-info bugs(they should all be marked pending(I love that
tag)).

Of course, there are hints that there is another segfault bug out there, with
the latest version in woody.  It's not repeatable, however.  Also, on this
note, I stand by 1.9.18, as being one of the most safest versions of dpkg,
with regard to buffer overruns, and the like.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Heath <[EMAIL PROTECTED]> writes:

> Of course, there are hints that there is another segfault bug out there, with
> the latest version in woody.  It's not repeatable, however.  Also, on this
> note, I stand by 1.9.18, as being one of the most safest versions of dpkg,
> with regard to buffer overruns, and the like.

That also points out that dpkg is not a good example; some packages
are sufficiently critical that conservatism in bug fixing is
important.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> So, picking one at random, why is bug 9085 still open?

Because that's a cosmetic issue.  There are more important things to work on,
like fixing bugs, and implementing features that we will need down the road.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> Um, if it doesn't work for the version of mkisofs in woody, then it is
> a critical bug as far as woody is concerned.

That may be true.  But someone who has potato installed, and does a partial
upgrade, might not have the new version of mkisofs.

Seriously, if a mkisofs upgrade broke software that used it, the only way to
*guarantee* that partial upgrades don't cause software to break, is for
mkisofs to conflict with the older versions of packages that used it.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Thomas Bushnell, BSG]

Adam Heath <[EMAIL PROTECTED]> writes:

> On 26 Dec 2001, Thomas Bushnell, BSG wrote:
> 
> > So, picking one at random, why is bug 9085 still open?
> 
> Because that's a cosmetic issue.  There are more important things to work on,
> like fixing bugs, and implementing features that we will need down the road.

The reason I didn't think it necessary to say more in the question
above was because it seemed obvious to me that either:

1) A cosmetic issue takes only a few seconds to fix, or
2) It should be a wishlist item.

Now, my point isn't "beat on dpkg" (and indeed, 'twasn't I that
brought it up IIRC).  But my point is that if something has sat there
for over four years, *something* somewhere is not working.  It seems
obvious to me that the dpkg maintainers are doing a fabulous job.  So
the problem isn't in them.

But there still is *some* kind of problem.

Re: An alarming trend (no it's not flaimbait.) (fwd)

[Adam Heath]

On 26 Dec 2001, Thomas Bushnell, BSG wrote:

> Adam Heath <[EMAIL PROTECTED]> writes:
>
> > Of course, there are hints that there is another segfault bug out there, 
> > with
> > the latest version in woody.  It's not repeatable, however.  Also, on this
> > note, I stand by 1.9.18, as being one of the most safest versions of dpkg,
> > with regard to buffer overruns, and the like.
>
> That also points out that dpkg is not a good example; some packages
> are sufficiently critical that conservatism in bug fixing is
> important.

Yes, it does.  See my uploads of 1.9.11 thru 1.9.14.