Re: Unable to connect to dbus socket.

[Josselin Mouette]

Le dimanche 19 octobre 2008 à 13:45 +0200, Guido Loupias a écrit :
> This is a slightly modified version of the code that is in libnotify_init() 
> which I put in my own program to redirect the output (error->message) to a 
> logfile because I wasn't sure how to redirect g_message() (which is what the 
> code in libnotify_init() uses to output the error). The logfile looks like 
> this:
> 
> ERROR: Failed to connect to socket /tmp/dbus-fgcckjDDZP: Verbinding is 
> geweigerd
> LOG: LibNotify constructor called (this = 0x9bb1c14)

> The LOG messages come from another line of code. It's the ERROR message that 
> is 
> coming from std::runtime_error(error->message). "Verbinding is geweigerd" is 
> Dutch for "Connection refused". The log file is an accumulation of multiple 
> runs 
> of the program, it's not erased when the program is restarted. So for every 
> ERROR in the log file there is 1 run of the program (one logout and login).

It looks like libdbus tries to use the socket that is related to your
previous session, which is of course wrong since dbus-daemon has exited
and will not accept new connections on it.

You should look at the DBUS_SESSION_BUS_ADDRESS, and see what is setting
it to the previous value. If you are running a panel applet, the
probable cause is that the bonobo-activation-server process from the
previous session is still running and is setting this environment
variable.

Newer versions of b-a-s are based on dbus so this will not happen in
GNOME 2.26. As for the current version, you need to add the following to
your .server file (under the oaf_server with type="exe"):




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


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

Re: Terminal emulators and command line arguments (again!)

[Andrei Popescu]

On Mon,20.Oct.08, 00:51:03, s. keeling wrote:
 
> Just curious, but why 2 & 3?  Why isn't 1 considered the simplest
> solution?  xterm is ca. 300k.  What Seyon users can't afford 300k disk
> space or its RSS?
> 
> vi's installed on every *nix box on the planet.  Why shouldn't xterm
> be on every X install on the planet?  My /usr/bin/vim.basic is 1.3 Mb.
> 
> 1 seems a far more robust solution to me.
 
Because it brings benefits to all users, not just users of seyon. I 
recently went (again) through experimenting with different terminal 
emulators and it was pretty annoying that all my keyboard shortcuts 
(based on x-terminal-emulator!) didn't work because one or the other 
wouldn't support some command-line options.

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Processed: Re: Bug#477498: general: Unmounting network filesystems solution (for me at least)

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 477498 initscripts
Bug#477498: smbfs: Shutdown & Reboot scripts try umount CIFS but CIFSD is 
killed first
Bug reassigned from package `general' to `initscripts'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

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


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

Re: Bug#477498: general: Unmounting network filesystems solution (for me at least)

[Petter Reinholdtsen]

Sound to me like the cifs startup script need to register their pid to
avoid killall killing them at shutdown.  The mechanism is already
provided by initscripts, now the packages needing it just need to use
it.

Which package starts this daemon?  This issue should be reassigned
there.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Bug#477498: general: Unmounting network filesystems solution (for me at least)

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> Sound to me like the cifs startup script need to register their pid
> to avoid killall killing them at shutdown.  The mechanism is already
> provided by initscripts, now the packages needing it just need to
> use it.

Another alternative is to flag the mounted volume in /etc/fstab using
the _netdev flag, to make sure the volume is umounted by umountnfs.sh
and not umountfs.sh during shutdown.

Happy hacking,
-- 
Petter Reinholdtsen


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

Bug#502854: ITP: goby -- WYSIWYG presentation tool for GNU Emacs

[Tatsuya Kinoshita]

Package: wnpp
Severity: wishlist
Owner: Tatsuya Kinoshita <[EMAIL PROTECTED]>

* Package name: goby
  Version : 0.94
  Upstream Author : Kazu Yamamoto
* URL : http://www.mew.org/~kazu/proj/goby/
* License : BSD
  Programming Lang: Emacs Lisp
  Description : WYSIWYG presentation tool for GNU Emacs

 Goby is an Emacs Lisp package to display large fonts and images, which
 can be used as a WYSIWYG presentation tool on GNU Emacs.
 .
 There are two modes, Edit and View, for Goby.  Edit mode is implemented
 as a minor mode while View mode as a major mode.  The created file (*.gby)
 is just a text, so you can easily handle it.
 .
 To display large fonts, install TrueType font packages.  To use images,
 install the netpbm package.  To make screen dumps, install the
 imagemagick package.

Thanks,
--
Tatsuya Kinoshita


pgpTjFNKdJ31S.pgp
Description: PGP signature

Re: Bug#502543: ITP: confget -- Utility to read variables from a configuration file

[Dominique Dumont]

Peter Pentchev <[EMAIL PROTECTED]> writes:

> On Fri, Oct 17, 2008 at 05:48:02PM +0200, Adeodato Sim?? wrote:
>> * Peter Pentchev [Fri, 17 Oct 2008 18:37:21 +0300]:
>> 
>> >   Description : Utility to read variables from a configuration file
>> 
>> Please mention "INI-style" in the short description, eg.:
>> 
>> Description : Utility to read variables from an INI-style 
>> configuration file
>
> Well, I will - for this version - but part of the idea behind confget is
> that it will eventually grow the ability to read config files in other
> formats.  I had my sights set on Java property files, but it turned out
> they were... a bit complicated, what with Unicode, quoting, and such,
> so I left them out of 1.00.

Then, you might want to consider Augeas for this purpose (Debian
package are already available).

Augeas has the ability to read and write INI files (and other files as
well)

See http://augeas.net for details

HTH

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner


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

Re: Bug#500176: This bug is still around and release-critical

[Jörg Sommer]

Hello Pierre,

Pierre Habouzit <[EMAIL PROTECTED]> wrote:
> I believe the problem here is somehow very generic, and that using a
> virtual package like proposed in the bug report (#500176) doesn't scale
> well. Especially for dns daemons. Packaging two of them myself (nsd3
> that is an authoritative server only, and pdnsd that is a caching daemon
> only) I can tell the virtual package solution would be a mess: I _want_
> to be able to use nsd3 _and_ pdnsd on the same machine (I actually do
> since the former binds to the external IPs only and pdnsd to 127.0.0.1)

> Anyways I think there is a more general solution to find and here are a
> path. The fact that Debian starts every single service on first install
> is something that we strive for, but causes some grief for sysadmins
> that don't wish to open an unprotected service before they configured
> it. It also generates the issue we're disussing.

If the idea of update-rc.d disable|reenable[1] gets implemented, it would
be enough to disable a service after first installation. update-rc.d
could do that.

[1] http://lists.debian.org/debian-devel/2008/09/msg00623.html

Bye, Jörg.
-- 
Die NASA brauchte 12 Jahre um einen Kugelschreiber zu entwickeln, der
kopfüber, in der Schwerelosigkeit und unter Wasser schreiben kann.
Die Russen benutzten einfach einen Bleistift …


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Marc 'HE' Brockschmidt wrote:

> Ben Finney <[EMAIL PROTECTED]> writes:

>> I would think at least a meaningful justification in the bug report is
>> required
>
> Well, apply common sense. In all of the bugs I recently tagged, the
> DFSG violation is usually a formal problem, something that other
> distributions and upstream don't consider a problem at all. While

What does "formal" mean here?  And the fact that other
 distributions play fast and loose with shipping non-fre stuff should
 not be an excuse for Debian to start violating the foundation
 documents, so whether or not Ubuintu ships non-free drivers is not
 something that Debian can point to to violate the DFSG.

> fixing these issues is and should be a goal of Debian, it's hardly
> something that can be done in the last few weeks before releasing. The
> drawbacks of delaying the release indefinitely for these bugs are much
> greater than releasing with these minor DFSG violations [1].


> FWIW, this has also been done for past releases (see, for example,
> #211765).

In the past, we passed GR's to allow us to ship with known DFSG
 violations: http://www.debian.org/vote/2004/vote_004

Has the current release team lowered the bar on Debian actually
 trying to follow the social contract? Is releasing on schedule more
 important than the SC?

manoj
-- 
Arithmetic: An obscure art no longer practiced in the world's developed
countries.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> 
> Has the current release team lowered the bar on Debian actually
>  trying to follow the social contract?

Yes, they have.

Furthermore, the FTP team (which is supposed to be in charge of DFSG
enforcement) has decided to look the other way:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823

Btw, I'm looking for supporters for a GR to stop this gross violation of the
SC.  Any DDs who read this, please let me know if you're interested.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Josselin Mouette]

Le lundi 20 octobre 2008 à 16:08 +0200, Robert Millan a écrit :
> > Has the current release team lowered the bar on Debian actually
> >  trying to follow the social contract?
> 
> Yes, they have.

What if, instead of ranting everywhere, you actually contributed code to
fix these bugs?

I don’t recall the release team being reluctant to letting bug fixes
(especially serious ones) migrate to lenny.

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


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 08:48:50AM +0200, Marc 'HE' Brockschmidt wrote:
> While fixing
> these issues is and should be a goal of Debian, it's hardly something
> that can be done in the last few weeks before releasing.

If I may make a suggestion, instead of trying to justify that Debian should
change its goals against the will of the majority of the developers, the
release team could just keep ignoring them all the same, and instead of
referring to the result as "Debian", just find another name to make SC #1
happy.

And if you find yourself in difficulty finding a name, I think "Blobbie" is
a pretty one.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> Le lundi 20 octobre 2008 à 16:08 +0200, Robert Millan a écrit :
> > > Has the current release team lowered the bar on Debian actually
> > >  trying to follow the social contract?
> > 
> > Yes, they have.
> 
> What if, instead of ranting everywhere, you actually contributed code to
> fix these bugs?

I did...

> I don’t recall the release team being reluctant to letting bug fixes
> (especially serious ones) migrate to lenny.

...but you missed the point.  They're not wishlist bugs.  If they were, I
wouldn't care much about them.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Stephen Gran]

This one time, at band camp, Robert Millan said:
> On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> > 
> > Has the current release team lowered the bar on Debian actually
> >  trying to follow the social contract?
> 
> Yes, they have.
> 
> Furthermore, the FTP team (which is supposed to be in charge of DFSG
> enforcement) has decided to look the other way:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823

I'm not sure that an unanswered email means they are condoning it.  It
just means they're not talking to you.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug#477498: general: Unmounting network filesystems solution (for me at least)

[Steve Langasek]

On Mon, Oct 20, 2008 at 09:57:24AM +0200, Petter Reinholdtsen wrote:
> Sound to me like the cifs startup script need to register their pid to
> avoid killall killing them at shutdown.  The mechanism is already
> provided by initscripts, now the packages needing it just need to use
> it.

> Which package starts this daemon?  This issue should be reassigned
> there.

Er, there's no such daemon.

> Another alternative is to flag the mounted volume in /etc/fstab using
> the _netdev flag, to make sure the volume is umounted by umountnfs.sh
> and not umountfs.sh during shutdown.

$ grep cifs /etc/init.d/umountnfs.sh 
  nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs)
$

umountnfs.sh already knows that cifs is a network filesystem.  And having to
add a flag to /etc/fstab would be the wrong solution, /because/ cifs is
always a network filesystem and umountnfs.sh should handle it.

But in some circumstances, it happens that the network interface is taken
down before umountnfs.sh is called.  This is the case when using NM 0.6 to
manage your interface (and possibly with later versions, I haven't checked).
CIFS doesn't like having the network pulled out from under it, leaving these
long timeouts.

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


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Thomas Viehmann]

Hi everyone, <--- will be referred to as "you"

Stephen Gran said:
> This one time, at band camp, Robert Millan said:
> > On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> > >
> > > Has the current release team lowered the bar on Debian actually
> > >  trying to follow the social contract?
> >
> > Yes, they have.
> >
> > Furthermore, the FTP team (which is supposed to be in charge of DFSG
> > enforcement) has decided to look the other way:
> >
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
>
> I'm not sure that an unanswered email means they are condoning it.  It
> just means they're not talking to you.
... with a CC to that bug report.

I queried Robert on IRC and told him that he does not have a realistic
scenario of fixing the bug and that he would need to come up with a
working NMUable patch to in order to even have a viable proposition to
move things forward.[1]

What are the release and ftp team supposed to do here? Sure, I can
type in "dak rm linux-2.6" and see what happens except the www.d.o
pseudopackage receiving a bug about removing me from the
FTP-Assistants list. Disposing of the luggage that is each
supplementaryGid line in LDAP would enable me to move on to happier
projects more easily.[2]

As Robert himself says, these bugs have been known for four years.
They are RC, if you did not prepare an NMU should ask yourself why you
did not and stop pretending that it is the release or ftp team's
responsibility to fix the RC bugs that you are not fixing.
The options from a FTP or release point of view are exactly keep
stuff, drop stuff, replace stuff by better stuff. That better stuff
needs to be available, though, and you are as much to blame for that
as everyone else.

Kind regards

T.

1. And yes, the bug about e100 (#494308) contains an unanswered
   question by Robert. But to me it reads as "Do you want a patch that
   does not work or a longer one that actually works?" which without
   doubt has not been answered because it is a deep philosophical
   question and puzzling everyone who ever looked at that bug to the
   point where they have to cease all activity on RC bugs and relax by
   enjoying a decent flamewar on debian-devel.

2. Every single time I look at the RC bug list, my first thought is
   about my exit strategy before I am even able to start considering
   the bug at hand.
   My pet flamewar would be about quality in Debian and whether the
   DAM needs to designate some people as Developers who do not
   maintain packages, but I can restrain myself enough to wait until
   after the release.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Robert Millan wrote:


> Btw, I'm looking for supporters for a GR to stop this gross violation
> of the SC.  Any DDs who read this, please let me know if you're
> interested.

Actually, I think we need a GR on the lines of
,
|  http://www.debian.org/vote/2006/vote_007
|  General Resolution: Handling source-less firmware in the Linux kernel
`

To get a special dispensation for lenny.

If someone were to propose such a GR, I would second it. If the
 DPL gives us leave to cut down discussion and voting to a week, we
 could get the decision in a couple of weeks.

I do not think that willfully violating the social contract is a
 decision for a few delegates to make -- we, as a project, should
 acknowledge the need for and make a special exception to release Debian
 with known non-free bits in it.

manoj
-- 
If Machiavelli were a programmer, he'd have worked for AT&T.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Josselin Mouette]

Le lundi 20 octobre 2008 à 16:34 +0200, Robert Millan a écrit :
> On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> > What if, instead of ranting everywhere, you actually contributed code to
> > fix these bugs?
> 
> I did...

And you deserve kudos for that. But that doesn’t make this current
thread less of a troll. You cannot ask, so late in the release process,
to introduce several thousand-lines patches in the kernel, even if they
finally exist. And you can’t say you were ignoring the situation until
now. It should have been obvious that, given how they evolved, these
bugs would be ignored for lenny.

> > I don’t recall the release team being reluctant to letting bug fixes
> > (especially serious ones) migrate to lenny.
> 
> ...but you missed the point.  They're not wishlist bugs.  If they were, I
> wouldn't care much about them.

They are serious bugs. And if we waited to have zero serious bugs before
releasing, we’d never release. That’s why lenny-ignore tags are here.

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


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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Josselin Mouette]

Le lundi 20 octobre 2008 à 16:34 +0200, Robert Millan a écrit :
> On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> > What if, instead of ranting everywhere, you actually contributed code to
> > fix these bugs?
> 
> I did...

And you deserve kudos for that. 

But still, it is unrealistic to ask, so late in the release process,
to introduce several thousand-lines patches in the kernel, even if they
finally exist (and AFAIK there are not patches for all these bugs).

You cannot say either that you were ignoring the situation until now. It
should have been obvious that, given how they evolved, these bugs would
be ignored for lenny. It is unfortunate, but people have focused on
fixing other kinds of bugs.

> > I don’t recall the release team being reluctant to letting bug fixes
> > (especially serious ones) migrate to lenny.
> 
> ...but you missed the point.  They're not wishlist bugs.  If they were, I
> wouldn't care much about them.

They are serious bugs. And if we waited to have zero serious bugs before
releasing, we’d never release. That’s why lenny-ignore tags are here.

The release team is not trying to lower standards, but simply to
mitigate between the issues and obtain the best compromise.

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


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 06:15:57PM +0200, Thomas Viehmann wrote:
> 
> What are the release and ftp team supposed to do here? Sure, I can
> type in "dak rm linux-2.6" and see what happens

Move it to non-free.  Then have it go to NEW the next time it's uploaded,
and go through the usual DFSG-ness check (but this time with aid, since
you can check the BTS for known issues).

> They are RC, if you did not prepare an NMU should ask yourself why you
> did not and stop pretending that it is the release or ftp team's
> responsibility to fix the RC bugs that you are not fixing.

The maintainers pretend that the only acceptable fix is one that:

  - Implements userland load (with the firmware blob added to non-free).
  - Has been tested on the affected hardware.

Since I have interest in the Social Contract but not in supporting non-free
stuff, I've only been working on #494010 [1] and packaged the necessary
utility [2] that would assemble the (now free) firmware.

For the rest, if I get a *firm* [3] assertion that I may NMU to fix it, you
can count on it that I would NMU by removing all the blobs and replace the
functions that process them with stubs.  Then again, the maintainers don't
want that.  Not my fault.

So, everyone stop complaining that I don't do the work.  I already do much
more than I am morally obligued to.

[1] with much appreciated help/advice from Ben Hutchings
[2] http://ftp-master.debian.org/new/a56_1.3-1.html btw, would be really nice
if it can be fast-tracked.
[3] that means either sanctioned by the maintainers or by the DPL

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Josselin Mouette]

Damnit, sent mail instead of moving to drafts. Sorry for the double
sending.
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote:
>
> You cannot ask, so late in the release process,

Some of these bugs have been known for *years*.  In one of them, I even got
a reply saying something along the lines of "I was expecting this one".

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Josselin Mouette]

Le lundi 20 octobre 2008 à 19:30 +0200, Robert Millan a écrit :
> On Mon, Oct 20, 2008 at 07:16:12PM +0200, Josselin Mouette wrote:
> >
> > You cannot ask, so late in the release process,
> 
> Some of these bugs have been known for *years*.  In one of them, I even got
> a reply saying something along the lines of "I was expecting this one".

Still, the release team depends on the good will of developers who spend
time fixing RC bugs. And they are not the only ones that have been
sitting for way too long.

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


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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Thomas Bushnell BSG]

On Mon, 2008-10-20 at 16:08 +0200, Robert Millan wrote:
> On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> > 
> > Has the current release team lowered the bar on Debian actually
> >  trying to follow the social contract?
> 
> Yes, they have.
> 
> Furthermore, the FTP team (which is supposed to be in charge of DFSG
> enforcement) has decided to look the other way:
> 
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823

I had understood that we had passed a GR to allow--ONCE--a past release
with these bugs not fixed, with the understanding they would be fixed
the next time.  Have I missed something?

Thomas



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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Thomas Bushnell BSG]

On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
> Actually, I think we need a GR on the lines of
> ,
> |  http://www.debian.org/vote/2006/vote_007
> |  General Resolution: Handling source-less firmware in the Linux kernel
> `
> 
> To get a special dispensation for lenny.

I think this would be insane.  It smacks of the nonsense of the US
Congress extending copyright over and over again, always for a "limited
term", but such that the terms just never actually expire.

I object to a second round of this.  I was ok with it once, as a
compromise, but the understanding I had then was that it was a one-time
thing, to give time to actually *fix* the problem.

The kernel team should *fix the bug* and not just sit on their hands.
We should not release until it's fixed.

But the continued dishonesty of holding out one set of principles and 
guarantees, while granting ourselves exceptions on every release, is not 
tolerable to me.

> I do not think that willfully violating the social contract is a
>  decision for a few delegates to make -- we, as a project, should
>  acknowledge the need for and make a special exception to release Debian
>  with known non-free bits in it.

We did that once.  With the understanding that we wouldn't do it
again--or at least, that was my understanding--it was proffered as a
special case, a one-time thing, because of the urgency of the case.  

Moreover, at the time, there was an amendment proposed to make it "as
long as required" and it got fewer votes than the one-time thing.
Pretty clearly, we *already decided* this issue, and we need no vote.
We need the relevant maintainers to be told "your unwillingness to fix
this means we will not be able to release".

I object very strongly to the feeling that I am being held hostage by
developers who will not fix the bug, and then protest "emergency! we
must release! no delay! we'll do it next time!" and then sit on their
hands again for another go-round.  The solution is to refuse to play
along, and to say, "hey, you had two years; we're just going to wait
until you fix the bug."

Thomas



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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 10:48:57AM -0700, Thomas Bushnell BSG wrote:
> On Mon, 2008-10-20 at 16:08 +0200, Robert Millan wrote:
> > On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote:
> > > 
> > > Has the current release team lowered the bar on Debian actually
> > >  trying to follow the social contract?
> > 
> > Yes, they have.
> > 
> > Furthermore, the FTP team (which is supposed to be in charge of DFSG
> > enforcement) has decided to look the other way:
> > 
> >   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823
> 
> I had understood that we had passed a GR to allow--ONCE--a past release
> with these bugs not fixed, with the understanding they would be fixed
> the next time.  Have I missed something?

Apparently, our control structures are not reliable enough to _enforce_
what we have decided.  It seems we relied primarily on the release team,
which has betrayed the goals of the project, and only count on the FTP
team as a fallback, which so far has done nothing about it.

Looks clear that we need to change something don't it?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Mark Brown]

On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:

> I object to a second round of this.  I was ok with it once, as a
> compromise, but the understanding I had then was that it was a one-time
> thing, to give time to actually *fix* the problem.

Note that there is currently active upstream work to allow us to address
these issues - some of the patches are present in 2.6.27, others are
still in flight.  This is a vast step forward on where we were with etch
if we do decide to go down the route of releasing with exceptions again.

> We need the relevant maintainers to be told "your unwillingness to fix
> this means we will not be able to release".

I don't think that's a particularly constructive approach to take,
especially not in a volunteer project.

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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Marc 'HE' Brockschmidt]

Robert Millan <[EMAIL PROTECTED]> writes:
> It seems we relied primarily on the release team, which has betrayed
> the goals of the project, 

I do not accept to be called names because I firmly believe that
Debian's goal is to distribute the best possible free software to our
users. All of our work has no value unless people are able to use the
software we integrate, test and improve.

I believe what you want to say is "I'm willing to pick up all the work
of the release team" before you start insulting the people who invest a
lot more time into this project than you do.

Marc


pgp6ZaFWFd1yx.pgp
Description: PGP signature

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Thomas Viehmann wrote:


> I queried Robert on IRC and told him that he does not have a realistic
> scenario of fixing the bug and that he would need to come up with a
> working NMUable patch to in order to even have a viable proposition to
> move things forward.[1]
>
> What are the release and ftp team supposed to do here? Sure, I can
> type in "dak rm linux-2.6" and see what happens except the www.d.o
> pseudopackage receiving a bug about removing me from the
> FTP-Assistants list. Disposing of the luggage that is each
> supplementaryGid line in LDAP would enable me to move on to happier
> projects more easily.[2]

Seems like there are patches stripping the kernel of these
 non-free blobs. So, how much would out hardware support be degraded?
 How many people are affected by these non-free drivers?

>
> As Robert himself says, these bugs have been known for four years.
> They are RC, if you did not prepare an NMU should ask yourself why you
> did not and stop pretending that it is the release or ftp team's
> responsibility to fix the RC bugs that you are not fixing.
> The options from a FTP or release point of view are exactly keep
> stuff, drop stuff, replace stuff by better stuff. That better stuff
> needs to be available, though, and you are as much to blame for that
> as everyone else.

So, drop non-free stuff, iff the GR fails.

I'll be willing to help create kernel packages for a fully free
 kernel and upload it, if that is what the ftp-masters want.  Been a
 while since I released official kernel images, but perhaps there is
 chance for a second time. After all, Lance Armstrong might be riding in
 the Tour de France 2009.

manoj
-- 
May all your PUSHes be POPped.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Thomas Bushnell BSG]

On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote:
> On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
> 
> > I object to a second round of this.  I was ok with it once, as a
> > compromise, but the understanding I had then was that it was a one-time
> > thing, to give time to actually *fix* the problem.
> 
> Note that there is currently active upstream work to allow us to address
> these issues - some of the patches are present in 2.6.27, others are
> still in flight.  This is a vast step forward on where we were with etch
> if we do decide to go down the route of releasing with exceptions again.

I think we have no need to go "down that route".  We do not have to
support the hardware at all. That is an option.  The fact that the
kernel maintainers would prefer a fancier thing is not the point.

We can simply not ship support for that hardware *at all*.  That's
perfectly acceptable to me--even as a user of such hardware.

A patch to fix the bug--which is the inclusion of non-free things in
main--can be quickly and easily implemented.  I'm oh-so-sorry if a
fancier fix is not available--but there has been plenty of time.  I'm
not willing to see another release with non-free blobs in the kernel,
especially since it is really quite trivial to remove them.

> > We need the relevant maintainers to be told "your unwillingness to fix
> > this means we will not be able to release".
> 
> I don't think that's a particularly constructive approach to take,
> especially not in a volunteer project.

I think that it is singularly non-constructive to see the maintainers of
packages regard compliance with our foundational documents as wishlist
items, and the release team regard such things as anything other than
show-stoppers.

Thomas



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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Thomas Bushnell BSG]

On Mon, 2008-10-20 at 20:18 +0200, Robert Millan wrote:
> Apparently, our control structures are not reliable enough to _enforce_
> what we have decided.  It seems we relied primarily on the release team,
> which has betrayed the goals of the project, and only count on the FTP
> team as a fallback, which so far has done nothing about it.
> 
> Looks clear that we need to change something don't it?

Yes, we need a rule that we never release with non-free software.

I thought we already had such a rule, but if the release team needs us
to vote on the social contract again, we can do so.

Thomas



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

Re: Bug reports of DFSG violations are tagged ‘len ny-ignore’?

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20-10-2008 16:32, Manoj Srivastava wrote:
> On Mon, Oct 20 2008, Thomas Viehmann wrote:
>> I queried Robert on IRC and told him that he does not have a realistic
>> scenario of fixing the bug and that he would need to come up with a
>> working NMUable patch to in order to even have a viable proposition to
>> move things forward.[1]
>>
>> What are the release and ftp team supposed to do here? Sure, I can
>> type in "dak rm linux-2.6" and see what happens except the www.d.o
>> pseudopackage receiving a bug about removing me from the
>> FTP-Assistants list. Disposing of the luggage that is each
>> supplementaryGid line in LDAP would enable me to move on to happier
>> projects more easily.[2]
> 
> Seems like there are patches stripping the kernel of these
>  non-free blobs. So, how much would out hardware support be degraded?
>  How many people are affected by these non-free drivers?

Just as a reference, #484365 talks about linux-libre which
seems to be an effort from FSFLA to remove non-free blobs from
Linux kernel.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484365


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

iEYEARECAAYFAkj8268ACgkQCjAO0JDlykaAlwCfZwpQ+Rx5Pe4/rloACozBvPnw
iIoAn22gly6EjMsx97BzRWOH0ZIjQwua
=zH0D
-END PGP SIGNATURE-


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 08:46:18PM +0200, Marc 'HE' Brockschmidt wrote:
> Robert Millan <[EMAIL PROTECTED]> writes:
> > It seems we relied primarily on the release team, which has betrayed
> > the goals of the project, 
> 
> I do not accept to be called names because I firmly believe that
> Debian's goal is to distribute the best possible free software to our
> users. All of our work has no value unless people are able to use the
> software we integrate, test and improve.
> 
> I believe what you want to say is "I'm willing to pick up all the work
> of the release team" before you start insulting the people who invest a
> lot more time into this project than you do.

Sorry for my blunt description of the situation.  Sometimes it has to come
this way, but I don't think it's insulting.

If that makes you feel better, I dearly appreciate most of your work (that is,
the part that doesn't involve dismissing DFSG violations as non-RC issues).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Adeodato Simó]

* Manoj Srivastava [Mon, 20 Oct 2008 08:41:16 -0500]:

> Has the current release team lowered the bar on Debian actually
>  trying to follow the social contract? Is releasing on schedule more
>  important than the SC?

When I do my release work, I have certain tools, and decisions about how
to use them. One of these tools is britney, and another is the possibility
of saying that certain bugs will not stop the release from happening.

Every developer has tools, and decisions as well. For example, every
developer can make uploads, and they have the power to decide to upload
a VCS snapshot of a package to unstable.

For me, believe it or not, it's very important not to betray the rest of
developers with the actions I take in my role as a release person. Which
is *not* to say I won't take any actions that makes feel one particular
developer betrayed. But I do try to listen to what people have to say
about how we release, I really do.

In the case at hand, I can clearly see some people feel betrayed, and
they're in the right to be so (though IMHO they're not in their right to
speak for the developers at larege). However, and until proven wrong,
I'm convinced the majority of developers don't feel betrayed by these
"lenny-ignore" tags. I'm open to being proven wrong, though.

(If you must know, I also /personally/ believe that it's the task of
those who feel betrayed to prove the release team wrong, and not the
opposite. In my view, the release takes what is in unstable and tries to
make something coherent of it. If you are outraged with what's in
unstable, take it up with the people responsible for it. We just stamp a
number in certain versions of packages, nothing more. Unstable is also
"Debian", you know.)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Dar Williams - February


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Adeodato Simó]

* Adeodato Simó [Mon, 20 Oct 2008 21:38:00 +0200]:

> (If you must know, I also /personally/ believe that it's the task of
> those who feel betrayed to prove the release team wrong, and not the
> opposite.

(If the release team fail to realize by themselves, I mean, should that
happen.)

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Dar Williams - This Was Pompeii


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Marc 'HE' Brockschmidt wrote:

> I do not accept to be called names because I firmly believe that
> Debian's goal is to distribute the best possible free software to our

I do not think anyone has any problems with us distributing
 *free* software. It is the non-free parts in main people have an issue
 with. 

> users. 

manoj

-- 
The most popular labor-saving device today is still a husband with
money. Joey Adams, "Cindy and I"
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Neil McGovern]

On Mon, Oct 20, 2008 at 09:33:49PM +0200, Robert Millan wrote:
> On Mon, Oct 20, 2008 at 08:46:18PM +0200, Marc 'HE' Brockschmidt wrote:
> > Robert Millan <[EMAIL PROTECTED]> writes:
> > > It seems we relied primarily on the release team, which has betrayed
> > > the goals of the project, 
> > 
> > I do not accept to be called names because I firmly believe that
> > Debian's goal is to distribute the best possible free software to our
> > users. All of our work has no value unless people are able to use the
> > software we integrate, test and improve.
> > 
> > I believe what you want to say is "I'm willing to pick up all the work
> > of the release team" before you start insulting the people who invest a
> > lot more time into this project than you do.
> 
> Sorry for my blunt description of the situation.  Sometimes it has to come
> this way, but I don't think it's insulting.
> 

It is incredibly insulting.

> If that makes you feel better, I dearly appreciate most of your work (that is,
> the part that doesn't involve dismissing DFSG violations as non-RC issues).
> 

Not at all. A justification that involves a 'but' is nullified. If you
really want to help, I'd love to see some drivers that you consider free
that will replace the ones that you don't.

Neil
-- 
* hermanr feels like a hedgehog having sex...


signature.asc
Description: Digital signature

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Neil McGovern]

On Mon, Oct 20, 2008 at 04:31:00PM +0200, Robert Millan wrote:
> On Mon, Oct 20, 2008 at 08:48:50AM +0200, Marc 'HE' Brockschmidt wrote:
> > While fixing
> > these issues is and should be a goal of Debian, it's hardly something
> > that can be done in the last few weeks before releasing.
> 
> If I may make a suggestion, instead of trying to justify that Debian should
> change its goals against the will of the majority of the developers,

Not the majority, try again (hint: 271 < ~500).

> the release team could just keep ignoring them all the same, and
> instead of referring to the result as "Debian", just find another name
> to make SC #1 happy.

Debian vote is -> way. I'll be happy to take a GR vote off you.

> And if you find yourself in difficulty finding a name, I think "Blobbie" is
> a pretty one.
> 

We've got plenty, thanks. If you want to enforce your own name, perhaps
helping with the release may be a path to becoming a RM yourself.

Neil
-- 
 hm, maybe wearing a black t-shirt while dusting my bedroom for the
first time in years wasn't such a good idea


signature.asc
Description: Digital signature

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Robert Millan]

On Mon, Oct 20, 2008 at 12:23:20PM -0700, Thomas Bushnell BSG wrote:
> On Mon, 2008-10-20 at 20:18 +0200, Robert Millan wrote:
> > Apparently, our control structures are not reliable enough to _enforce_
> > what we have decided.  It seems we relied primarily on the release team,
> > which has betrayed the goals of the project, and only count on the FTP
> > team as a fallback, which so far has done nothing about it.
> > 
> > Looks clear that we need to change something don't it?
> 
> Yes, we need a rule that we never release with non-free software.
> 
> I thought we already had such a rule, but if the release team needs us
> to vote on the social contract again, we can do so.

We already have a stronger rule in SC, saying that Debian (including
unreleased versions) is 100% free.

Obviously, there's always going to be a time lapse between the moment in
which a bug is filed and a fix is uploaded.  We used to think the upper limit
to that lapse would be "till next release", but one can't rely on the release
team to enforce that anymore, so why not define an upper limit in GR instead?

I'll be working on this tomorrow and send a draft to -vote.  Please participate
in the discussion if you can.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


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

Re: Unable to connect to dbus socket.

[Guido Loupias]

Josselin Mouette schreef:

If you are running a panel applet, the
probable cause is that the bonobo-activation-server process from the
previous session is still running and is setting this environment
variable.
This appears to have been the culprit. I added the snippet below to the server 
file and it solved the problem.



Newer versions of b-a-s are based on dbus so this will not happen in
GNOME 2.26. As for the current version, you need to add the following to
your .server file (under the oaf_server with type="exe"):





Thanks alot Josselin. :)
By the way, killer sig.

Regards,
Guido


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Adeodato Simó wrote:


> For me, believe it or not, it's very important not to betray the rest of
> developers with the actions I take in my role as a release person. Which
> is *not* to say I won't take any actions that makes feel one particular
> developer betrayed. But I do try to listen to what people have to say
> about how we release, I really do.

But developers are not the only infliences on your decision. You
 have agreed to abide by the social contract, have you not? That, too,
 should dictate how you act within your delegated role. 


> In the case at hand, I can clearly see some people feel betrayed, and
> they're in the right to be so (though IMHO they're not in their right
> to speak for the developers at larege). However, and until proven
> wrong, I'm convinced the majority of developers don't feel betrayed by
> these "lenny-ignore" tags. I'm open to being proven wrong, though.

I have no idea about how betrayal features here: I just believe
 that the decision to ignore these problems in Lenny fall beyond the
 powers given to delegates.

There is nothing to feel betrayed by, all kinds of people make
 all kinds of mistakes, and I do not live in a perpetual feeling of
 victimization or betrayal.

> (If you must know, I also /personally/ believe that it's the task of
> those who feel betrayed to prove the release team wrong, and not the
> opposite. In my view, the release takes what is in unstable and tries to
> make something coherent of it. If you are outraged with what's in
> unstable, take it up with the people responsible for it. We just stamp a
> number in certain versions of packages, nothing more. Unstable is also
> "Debian", you know.)

In other words, if the release team is allowing packages to
 violate the DFSG, one must prove something to the relese team (not sure
 what that is, exactly). Is it in dispute that non-free blobs that
 violate the DFSG actually violate the DFSG?

Or does the release team need someone to quote the contitution
 and the social contrat to them? (I doubt that is the case, since the
 RM"s are mostly quite competent)

Are you saying you want the project to show you that the SC is
 still relevant, by passing yet another GR?

Please pardon my confusion, since you ought to be aware that
 English is not my first (or second) language.

So, could you explain  your view of the issue here, without
 bringing in feeling of betrayal, which I do not comprehend?

manoj
-- 
"Survey says..." Richard Dawson, weenie, on "Family Feud"
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

Hi,

This email is an edited excerpt from Sven Luther, sent via
 private email. I am sending in a version I am happy to defend posting,
 and will try to convey as much of what Sven said as I am comfortable
 forwarding. I have marked where I paraphrased what Sven said.

manoj

> On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
>> On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
>> > Actually, I think we need a GR on the lines of
>> > ,
>> > |  http://www.debian.org/vote/2006/vote_007> > |  General Resolution: 
>> > Handling source-less firmware in the Linux kernel
>> > `

>> > To get a special dispensation for lenny.

>> I think this would be insane.  It smacks of the nonsense of the US
>> Congress extending copyright over and over again, always for a "limited
>> term", but such that the terms just never actually expire.

>> I object to a second round of this.  I was ok with it once, as a
>> compromise, but the understanding I had then was that it was a one-time
>> thing, to give time to actually *fix* the problem.

>> The kernel team should *fix the bug* and not just sit on their hands.
>> We should not release until it's fixed.

>> But the continued dishonesty of holding out one set of principles and
>> guarantees, while granting ourselves exceptions on every release, is
>> not tolerable to me. 


> Well, what do you expect ? When we last have this discussion, the
> actual GR which the kernel team wanted to be something we could use to
> actually work on this issue, and as a statement of fact for hardware
> manufacturers.

 However, the GR that was passed differed significantly from
 that. Because of that, and the fact that the kernel team
 lost members and is stretched thin, it is no wonder that
 nobody did take the torch up and fix the issue until now.

> Sven Luther

-- 
The Czechs announced after Sputnik that they, too, would launch a
satellite. Of course, it would orbit Sputnik, not Earth!
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Ben Finney]

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

> Ben Finney <[EMAIL PROTECTED]> writes:
> > I would think at least a meaningful justification in the bug
> > report is required
> 
> Well, apply common sense.

Common sense, i.e. the policy, social contract, and DFSG that are each
agreed in common by all DDs, would have those bugs prevent packages
violating the DFSG from being released in Debian.

If you have some other justification that overrides this common sense,
*please* make it explicit in the bug report when tagging bugs to be
ignored despite the evident unsuitability of the package for release.

> In all of the bugs I recently tagged, the DFSG violation is usually
> a formal problem, something that other distributions and upstream
> don't consider a problem at all.

That appears to be a no-op: other distributions and upstream have not
in general made an explicit social contract to follow the DFSG, while
the Debian project has done so.

> While fixing these issues is and should be a goal of Debian, it's
> hardly something that can be done in the last few weeks before
> releasing.

Is that release deadline externally imposed, then? Are we bound to
release on a specific date regardless of what bugs, ‘lenny-ignore’
tagged or otherwise, remain in the packages?

Or is it the case, as I'd understood from the guiding documents of the
Debian project, that it's more important to release Debian such that
it meets the project's own promises?

> The drawbacks of delaying the release indefinitely for these bugs
> are much greater than releasing with these minor DFSG violations
> [1].

This is a fallacy of the excluded middle. You omit the option to
remove the parts of the work that violate the DFSG, which is a
long-accepted solution to these types of bugs.

-- 
 \ “Dare to be naïve.” —Richard Buckminster Fuller, personal motto |
  `\   |
_o__)  |
Ben Finney


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Moritz Muehlenhoff]

Robert Millan wrote:
>> > > Has the current release team lowered the bar on Debian actually
>> > >  trying to follow the social contract?
>> > 
>> > Yes, they have.
>> 
>> What if, instead of ranting everywhere, you actually contributed code to
>> fix these bugs?
>
> I did...

You contributed one(!) - untested - patch for e100 and did nothing for the
rest since beginning of August.

These bugs were tagged "help" by the Debian Kernel Team since the same
day you filed them. The same team, which is already heavily overworked
and which already fixed/pruned lots of drivers with the 2.6.23-1 upload.

If it were really important, why didn't you start with this directly after
Etch release? Why didn't you do anything substantially since two and a half
months? 

Where are your patches working on these issues upstream? If it is so
important to you, why didn't you even notice that all this firmware
separation work is already going on upstream led by David Woodhouse?
(The same applies to Nathanael Nerode, who never did a thing to get
all this resolved instead of pestering around)

> ...but you missed the point.  They're not wishlist bugs.  If they were, I
> wouldn't care much about them.

Well, bugs don't get magically fixed.
You didn't do anything substantially about them, so you can hardly complain.

Cheers,
Moritz


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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Adeodato Simó]

* Manoj Srivastava [Mon, 20 Oct 2008 15:14:15 -0500]:

Hi,

> But developers are not the only infliences on your decision. You
>  have agreed to abide by the social contract, have you not? That, too,
>  should dictate how you act within your delegated role. 

[...]

> There is nothing to feel betrayed by, all kinds of people make
>  all kinds of mistakes, and I do not live in a perpetual feeling of
>  victimization or betrayal.

[...]

> In other words, if the release team is allowing packages to
>  violate the DFSG, one must prove something to the relese team (not sure
>  what that is, exactly). Is it in dispute that non-free blobs that
>  violate the DFSG actually violate the DFSG?

> Or does the release team need someone to quote the contitution
>  and the social contrat to them? (I doubt that is the case, since the
>  RM"s are mostly quite competent)

> Are you saying you want the project to show you that the SC is
>  still relevant, by passing yet another GR?

> Please pardon my confusion, since you ought to be aware that
>  English is not my first (or second) language.

> So, could you explain  your view of the issue here, without
>  bringing in feeling of betrayal, which I do not comprehend?

I agreed to abide by the social contract, but I happen to think that
these lenny-ignore tags at hand are acceptable in order to get a release
out, /and/ I also believe that a majority of the developers happens to
think the same (otherwise I wouldn't condone their use; I repeat: if I
thought most DDs would think they are not reasonable, I would not
approve of them even if they'd be reasonable to me).

I may as well be mistaken in this belief, so I'm open to being proved
wrong. To be proven, specifically, that the developers at large don't
want these lenny-ignore tags applied. (That should answer your question
above.)

> I have no idea about how betrayal features here: I just believe
>  that the decision to ignore these problems in Lenny fall beyond the
>  powers given to delegates.

This is a very interesting point, actually. My opinion is that: (a) they
are a tool the release team should have, (b) the release team should not
drift from the project at large in their use, (c) as with every other
decision from a developer, they are always overrideable by a GR.

HTH,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
   Listening to: Dar Williams - This Was Pompeii


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Mark Brown]

On Mon, Oct 20, 2008 at 12:22:25PM -0700, Thomas Bushnell BSG wrote:
> On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote:
> > On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:

> > > We need the relevant maintainers to be told "your unwillingness to fix
> > > this means we will not be able to release".

> > I don't think that's a particularly constructive approach to take,
> > especially not in a volunteer project.

> I think that it is singularly non-constructive to see the maintainers of
> packages regard compliance with our foundational documents as wishlist
> items, and the release team regard such things as anything other than
> show-stoppers.

No, really.  The kernel team are volunteers.  Ordering them to do things
doesn't help at all; one could equally well send the same message to
everyone working on Debian (or, indeed, the wider community) since they
could also step up to the plate and help fix this issue.

If they were actively stopping people working on these issues then that
would be different but I have not seen them doing this.

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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Franklin PIAT]

On Mon, 2008-10-20 at 10:55 -0700, Thomas Bushnell BSG wrote:
> On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote:
> > Actually, I think we need a GR on the lines of
> > ,
> > |  http://www.debian.org/vote/2006/vote_007
> > |  General Resolution: Handling source-less firmware in the Linux kernel
> > `
> > 
> > To get a special dispensation for lenny.
> 
> I think this would be insane.  It smacks of the nonsense of the US
> Congress extending copyright over and over again, always for a "limited
> term", but such that the terms just never actually expire.

According to [1], we are talking about 13 bugs. 
 5 were opened in August
 2 were opened in September
 7 were opened in October

Thanks to those who hunted those bugs (Robert and Ben), and those who
submitted patches (Robert and Ben).

> I object very strongly to the feeling that I am being held hostage by
> developers who will not fix the bug, and then protest "emergency! we
> must release! no delay! we'll do it next time!" and then sit on their
> hands again for another go-round.  The solution is to refuse to play
> along, and to say, "hey, you had two years; we're just going to wait
> until you fix the bug."

None of the "ignore-lenny" bugs have been opened for two years, right ?

How can we expect magazines to reserve their cover-page for us, if they
have no clue about when we release ?

I'm not saying it's fine to violate SC, I'm just the kind of guy who
accept some compromises (temporary compromises here).
May be we should only allow such "ignore-lenny" violation, if N+1 (i.e
2.6.27) has the guilty feature removed in experimental?

BTW, Kudos to the D-I team who did an excellent job handling non-free
firmware in Lenny. A user is prompted for non-free firmware. That's a
very good way to reverse the "not supported" paradigm: As far as a user
is concerned, it is not Linux that doesn't support "my" device, it is
"my" device that require a damned non-free driver.

Franklin

[1] 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3Afirmware;tag=lenny-ignore


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

Re: Bug reports of DFSG violations are tagged ‘len ny-ignore’?

[Felipe Augusto van de Wiel (faw)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20-10-2008 19:09, Adeodato Simó wrote:
> * Manoj Srivastava [Mon, 20 Oct 2008 15:14:15 -0500]:
[...]
>> So, could you explain  your view of the issue here, without
>>  bringing in feeling of betrayal, which I do not comprehend?
> 
> I agreed to abide by the social contract, but I happen to think that
> these lenny-ignore tags at hand are acceptable in order to get a release
> out, /and/ I also believe that a majority of the developers happens to
> think the same (otherwise I wouldn't condone their use; I repeat: if I
> thought most DDs would think they are not reasonable, I would not
> approve of them even if they'd be reasonable to me).
> 
> I may as well be mistaken in this belief, so I'm open to being proved
> wrong. To be proven, specifically, that the developers at large don't
> want these lenny-ignore tags applied. (That should answer your question
> above.)

This sounds like "appeal to popularity", just because
a supposed majority do not care about something being applied
that doesn't instantly make it reasonable.

I do accept that lenny-ignore tags are an important
tool for the Release Team to make another successful release,
but I also think we will need to handle the non-free linux
blobs in some way.

People may had been harsh in expressing their feelings
about the situation, now that the problem got a lot more
attention, my honest question is: what are the alternatives we
have from the Kernel and Release Team point of views? I mean,
do we have other alternatives besides doing something similar
we did for etch?


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

iEYEARECAAYFAkj8/eYACgkQCjAO0JDlykaAKACff3Lkfb9CsMHWDdGNeQCo5T9X
bK8AoNJZp81/YQW5oiUZJ5M407PpVQb1
=fX56
-END PGP SIGNATURE-


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Adeodato Simó wrote:


> I agreed to abide by the social contract, but I happen to think that
> these lenny-ignore tags at hand are acceptable in order to get a release
> out, /and/ I also believe that a majority of the developers happens to
> think the same (otherwise I wouldn't condone their use; I repeat: if I
> thought most DDs would think they are not reasonable, I would not
> approve of them even if they'd be reasonable to me).

I think that we should not just assume that the developers think
 that violating the DFSG is acceptable just to release a new version. I
 think we should have the project explicitly state this, via a GR, like
 we have done for the last two releases.

We should not get so blase about violating the DFSG that we do
 not even ask, and just assume eveyone is  going to just accept DFSG
 violations in a core component because it is facile, and because
 somehow the release when we are ready sentiment is old fashioned.

> This is a very interesting point, actually. My opinion is that: (a) they
> are a tool the release team should have, (b) the release team should not
> drift from the project at large in their use, (c) as with every other
> decision from a developer, they are always overrideable by a GR.

The tools do not make decisions, people do. I also think that
 the foundation documents codify what the core values for the project
 are. If the release team is drifting away from the foundation
 documents, I think they are drifting away from the project at large, by
 definition.

If you want a GR to tell you you should follow the social
 contract, I suppose  we'll have to go through the motions.

If the social contract and the whole freedom thing have become
 passe, and the project members think so, we should then pass a GR
 deleting the SC and the DFSG, and just ship whatever is convenient. I
 am not sure I would still want to be part of the project that does
 that, though.

manoj
-- 
To the systems programmer, users and applications serve only to provide
a test load.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Thomas Bushnell BSG]

On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> No, really.  The kernel team are volunteers.  Ordering them to do things
> doesn't help at all; one could equally well send the same message to
> everyone working on Debian (or, indeed, the wider community) since they
> could also step up to the plate and help fix this issue.

Of course.  These are RC bugs.  I would be happy to upload an NMU that
fixed the RC issue by removing support for the relevant hardware, and
dropping blobs from the source.  I don't think it's a very challenging
task, but I'm happy to do so.  Will that be ok?

> If they were actively stopping people working on these issues then that
> would be different but I have not seen them doing this.

Great, so since there won't be any active attempts to stop, I can just
go ahead with the work, right?

Thomas



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

Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?

[Ben Hutchings]

On Mon, 2008-10-20 at 19:22 +0200, Josselin Mouette wrote:
> Le lundi 20 octobre 2008 à 16:34 +0200, Robert Millan a écrit :
> > On Mon, Oct 20, 2008 at 04:21:24PM +0200, Josselin Mouette wrote:
> > > What if, instead of ranting everywhere, you actually contributed code to
> > > fix these bugs?
> > 
> > I did...
> 
> And you deserve kudos for that. 
> 
> But still, it is unrealistic to ask, so late in the release process,
> to introduce several thousand-lines patches in the kernel, even if they
> finally exist (and AFAIK there are not patches for all these bugs).

These patches exist, and they change less than a thousand lines in
total.  Here's the state of things:

driver bug "source" file(s) licenceaction
-
cassini498631  net/cassini.hGPLv2  remove
dabusb 502663  media/video/dabfirmware.hBSDish move (dabusb)
dsp56k 494010  char/dsp56k.cGPLv2  add source
e100   494308  net/e100.c   BSDish move (e100)
kaweth 502665  net/usb/kawethfw.h   GPLv2  remove
mga502666  char/drm/mga_ucode.h MITmove (matrox)
qla1280502667  scsi/ql1{2160,040,280}_fw.h  GPLv2  remove
r128   494007  char/drm/r128_cce.c  MITmove (ati)
radeon 494009  char/drm/radeon_microcode.h  MITmove (ati)
starfire   501152  net/starfire_firmware.h  unmodified redist  move 
(adaptec)
tehuti 501153  net/tehuti_fw.h  GPLv2  remove
typhoon502669  net/typhoon-firmware.h   unmodified redist  move (3com)
whiteheat  502668  usb/serial/whiteheat_fw.hGPLv2  remove

"Action" is what my changes would do.  If the licence requires source
distribution, remove.  If the licence allows binary-only distribution,
move to firmware-nonfree (the names given are the package names minus
the leading "firmware-".  In the case of dsp56k we can provide the
source.  In fact Robert has been working to provide a package of the
assembler for the source.

The modified linux-2.6 and firmware-nonfree source packages, and the
linux-source-2.6.26 and firmware-* binary packages, can be found in:
http://people.debian.org/~benh/firmware-removal/

Please test them if you can.  I have only been able to test the radeon
changes myself.

Ben.

PS: I've now managed to find firmware for qla1280
,
tehuti
 and
kaweth  under a
4-clause BSD licence, so they are candidates for firmware-nonfree after
all.  The BSD driver for Cassini doesn't have the Saturn firmware patch
and there seems to be no BSD driver for Whiteheat.



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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Ben Finney]

Moritz Muehlenhoff <[EMAIL PROTECTED]> writes:

> Well, bugs don't get magically fixed.
> You didn't do anything substantially about them, so you can hardly
> complain.

These specific bug reports describe instances where the Debian project
breaks its own promises, which is why their severity is ‘serious’. The
complaint is that positive action is being taken (the tagging of bug
reports so that they are to be ignored for a Debian release) to ensure
that breach occurs.

Every recipient of the social contract's promise is entitled to hold
the Debian project to its promises.

-- 
 \“No matter how cynical you become, it's never enough to keep |
  `\up.” —Jane Wagner, via Lily Tomlin |
_o__)  |
Ben Finney


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Ben Hutchings]

On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
> On Mon, Oct 20, 2008 at 12:22:25PM -0700, Thomas Bushnell BSG wrote:
> > On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote:
> > > On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote:
> 
> > > > We need the relevant maintainers to be told "your unwillingness to fix
> > > > this means we will not be able to release".
> 
> > > I don't think that's a particularly constructive approach to take,
> > > especially not in a volunteer project.
> 
> > I think that it is singularly non-constructive to see the maintainers of
> > packages regard compliance with our foundational documents as wishlist
> > items, and the release team regard such things as anything other than
> > show-stoppers.
> 
> No, really.  The kernel team are volunteers.  Ordering them to do things
> doesn't help at all; one could equally well send the same message to
> everyone working on Debian (or, indeed, the wider community) since they
> could also step up to the plate and help fix this issue.
[...]

Actually, I've done the last part of the work to remove firmware (mostly
adapting patches written by others).  The remaining problems are (a) a
very few drivers don't have redistributable firmware (b) most of the
other patches have not been properly tested, at least not with the
Debian kernel.

Ben.



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

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Stefano Zacchiroli]

On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
> When I do my release work, I have certain tools, and decisions about how
> to use them. One of these tools is britney, and another is the possibility
> of saying that certain bugs will not stop the release from happening.

> Unstable is also "Debian", you know.)

I found these arguments actually really convincing. So, to the GR
proposers, beware of how do you propose it, because I would have
really hard time understanding a GR that simply asks for not
*releasing* stuff which we continue *distributing* in some of our
suites (i.e., unstable).  Why should the treatment be different?

... and if it is *not* different, why should be the release managers
be considered responsible for it? They "just" decide (and kudos for
all their hard work, BTW) if something which is already in Debian gets
released or not.

Cheers.

PS Note that I don't want yet to take part in judging the severity of
   the issues, mostly because I'm still offline and I want to read the
   bug logs. But I believe the points I've raised above are valid no
   matter what is written in that bug logs.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right
uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach


signature.asc
Description: Digital signature

Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?

[Stefano Zacchiroli]

On Mon, Oct 20, 2008 at 04:52:40PM -0500, Manoj Srivastava wrote:
> I think that we should not just assume that the developers think
>  that violating the DFSG is acceptable just to release a new version. I

Sure, but we shouldn't assume the contrary either, and it seems to me
that a lot of participants in this thread did precisely that.

> The tools do not make decisions, people do. I also think that
>  the foundation documents codify what the core values for the project
>  are. If the release team is drifting away from the foundation
>  documents, I think they are drifting away from the project at large, by
>  definition.

But why nobody is making these very same arguments to the maintainer
of their packages or to the FTP masters FWIW? According to these
arguments they are drifting as away as the RMs. Either this is
actually so (which I don't believe), or as Dato said the general
feeling about these issues agrees with them RMs.

> If the social contract and the whole freedom thing have become
>  passe, and the project members think so, we should then pass a GR
>  deleting the SC and the DFSG, and just ship whatever is convenient. I
>  am not sure I would still want to be part of the project that does
>  that, though.

Please, don't get epic.

Truth is that this is yet another case where I would like to see more
a poll (still authenticated with devotee) to feel the general feelings
of DDs, more than a GR with a decision which would actually be a
pretest just to understand the general feeling.

Maybe Jeroen which did that in the past can fire up a poll on the fly?
The question would be as simple as: «do you agree with RMs about
tagging lenny-ignore bugs LIST_OF_BUGS_WITH_URLS?».

I'm quite sure the answer would be «yes», but here I'm entering myself
the guesswork terrain which permeates this thread.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è sempre /oo\ All one has to do is hit the right
uno zaino-- A.Bergonzoni \__/ keys at the right time -- J.S.Bach


signature.asc
Description: Digital signature

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Ben Finney]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> On Mon, Oct 20, 2008 at 04:52:40PM -0500, Manoj Srivastava wrote:
> > I think that we should not just assume that the developers
> >  think that violating the DFSG is acceptable just to release a new
> >  version.
> 
> Sure, but we shouldn't assume the contrary either

What, in your view, would allow such an assumption? I'd have thought
an explicit agreement to follow the social contract would be *exactly*
what's required to allow assumption that the agreement will be
followed.

> I'm quite sure the answer would be «yes», but here I'm entering
> myself the guesswork terrain which permeates this thread.

I don't see how claims of “guesswork” can be raised for assuming
that an explicit agreement remains in place unless explicitly
nullified.

-- 
 \“Room service? Send up a larger room.” —Groucho Marx |
  `\   |
_o__)  |
Ben Finney


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Stefano Zacchiroli wrote:

> On Mon, Oct 20, 2008 at 04:52:40PM -0500, Manoj Srivastava wrote:
>> I think that we should not just assume that the developers think
>>  that violating the DFSG is acceptable just to release a new version. I

> Sure, but we shouldn't assume the contrary either, and it seems to me
> that a lot of participants in this thread did precisely that.

I am not sure who you are talking about, but I assure you I have
 not. My point is that we should explicitly ask, especially if it is
 about having us willfully violate the DFSG.

>> The tools do not make decisions, people do. I also think that
>>  the foundation documents codify what the core values for the project
>>  are. If the release team is drifting away from the foundation
>>  documents, I think they are drifting away from the project at large, by
>>  definition.
>
> But why nobody is making these very same arguments to the maintainer
> of their packages or to the FTP masters FWIW?

They have been made to the maintainers, and my understanding is
 the same arguments have been made to the ftp masters.

> According to these arguments they are drifting as away as the
> RMs. Either this is actually so (which I don't believe), or as Dato
> said the general feeling about these issues agrees with them RMs.

This does not logically follow. If the delegates are all vested
 into releasing regularly on schedule, it does not mean that the project
 as a wh9ole either agrees, or disagrees. Which is why we must ask.

> Truth is that this is yet another case where I would like to see more
> a poll (still authenticated with devotee) to feel the general feelings
> of DDs, more than a GR with a decision which would actually be a
> pretest just to understand the general feeling.

A straw poll would not be something which I would consider
 authoritative, or binding, in any fashion, no.

manoj
-- 
Truthful, adj.: Dumb and illiterate. Ambrose Bierce, "The Devil's
Dictionary"
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ‘ lenny-ignore’?

[Manoj Srivastava]

On Mon, Oct 20 2008, Stefano Zacchiroli wrote:

> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>> When I do my release work, I have certain tools, and decisions about how
>> to use them. One of these tools is britney, and another is the possibility
>> of saying that certain bugs will not stop the release from happening.
> 
>> Unstable is also "Debian", you know.)
>
> I found these arguments actually really convincing. So, to the GR
> proposers, beware of how do you propose it, because I would have
> really hard time understanding a GR that simply asks for not
> *releasing* stuff which we continue *distributing* in some of our
> suites (i.e., unstable).  Why should the treatment be different?

It should not. Which is why the patches proposed on -kernel
 should be applied (NMU's are certainly feasible)

> ... and if it is *not* different, why should be the release managers
> be considered responsible for it? They "just" decide (and kudos for
> all their hard work, BTW) if something which is already in Debian gets
> released or not.

I am not sure that violating a foundation document falls under
 the powers of a delegate. I wish it did, being a delegate, but it does
 not. I looked.

manoj
-- 
Amnesia used to be my favorite word, but then I forgot it.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Luk Claes]

Manoj Srivastava wrote:
> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
> 
>> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:

>> ... and if it is *not* different, why should be the release managers
>> be considered responsible for it? They "just" decide (and kudos for
>> all their hard work, BTW) if something which is already in Debian gets
>> released or not.
> 
> I am not sure that violating a foundation document falls under
>  the powers of a delegate. I wish it did, being a delegate, but it does
>  not. I looked.

Stop this nonsense, it's not the release team that is violating a
foundation document. It's Debian as a whole and it's happening now, not
when we release or not. The only thing we did as a release team is to
make clear that we don't want to delay the release if these bugs won't
get fixed. As always we don't object that lenny-ignore bugs would get
fixed before lenny.

Cheers

Luk


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

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Manoj Srivastava]

On Tue, Oct 21 2008, Luk Claes wrote:

> Manoj Srivastava wrote:
>> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
>> 
>>> On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
>
>>> ... and if it is *not* different, why should be the release managers
>>> be considered responsible for it? They "just" decide (and kudos for
>>> all their hard work, BTW) if something which is already in Debian gets
>>> released or not.
>> 
>> I am not sure that violating a foundation document falls under
>>  the powers of a delegate. I wish it did, being a delegate, but it does
>>  not. I looked.
>
> Stop this nonsense, it's not the release team that is violating a
> foundation document. It's Debian as a whole and it's happening now, not
> when we release or not. The only thing we did as a release team is to
> make clear that we don't want to delay the release if these bugs won't
> get fixed. As always we don't object that lenny-ignore bugs would get
> fixed before lenny.

Hmm. I am not so sire it is nonsense. Yes, the release team is
 not alone in this, and, really, all of us are somewhat to blame for not
 helping the kernel team fix the DFSG violations. But I don't think that
 the release team is blameless, either, since they decided to release
 with DFSG violating code.

Now, if we are all so very eager to have these bugs go away, we
 have no objections to an NMU with the patches that have been posted on
 -kernel mailing list, right? (Note: some of these patches have only
 recently been posted, so NMU's based on these patches have only just
 becme possible).

manoj
-- 
BE ALERT (The world needs more lerts...)
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Luk Claes]

Manoj Srivastava wrote:
> On Tue, Oct 21 2008, Luk Claes wrote:
> 
>> Manoj Srivastava wrote:
>>> On Mon, Oct 20 2008, Stefano Zacchiroli wrote:
>>>
 On Mon, Oct 20, 2008 at 09:38:00PM +0200, Adeodato Simó wrote:
 ... and if it is *not* different, why should be the release managers
 be considered responsible for it? They "just" decide (and kudos for
 all their hard work, BTW) if something which is already in Debian gets
 released or not.
>>> I am not sure that violating a foundation document falls under
>>>  the powers of a delegate. I wish it did, being a delegate, but it does
>>>  not. I looked.
>> Stop this nonsense, it's not the release team that is violating a
>> foundation document. It's Debian as a whole and it's happening now, not
>> when we release or not. The only thing we did as a release team is to
>> make clear that we don't want to delay the release if these bugs won't
>> get fixed. As always we don't object that lenny-ignore bugs would get
>> fixed before lenny.
> 
> Hmm. I am not so sire it is nonsense. Yes, the release team is
>  not alone in this, and, really, all of us are somewhat to blame for not
>  helping the kernel team fix the DFSG violations. But I don't think that
>  the release team is blameless, either, since they decided to release
>  with DFSG violating code.

We didn't decide to release yet...

> Now, if we are all so very eager to have these bugs go away, we
>  have no objections to an NMU with the patches that have been posted on
>  -kernel mailing list, right? (Note: some of these patches have only
>  recently been posted, so NMU's based on these patches have only just
>  becme possible).

Not in principle, though I would object an NMU that is not tested properly.

Cheers

Luk


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

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Ben Finney]

Luk Claes <[EMAIL PROTECTED]> writes:

> it's not the release team that is violating a foundation document.
> It's Debian as a whole and it's happening now, not when we release
> or not.

This is an important distinction, thank you.

> The only thing we did as a release team is to make clear that we
> don't want to delay the release if these bugs won't get fixed.

Surely the requirement is not to *ignore* a serious bug, but to
*remove* the offending package unless the bug is resolved?

Yes, I understand we're talking about, in some cases, kernel packages
that have these bugs. What I don't see is why these serious bugs, that
(as you point out) violate the Debian project's foundation documents,
can be ignored for the sake of releasing on a particular date.

-- 
 \ “I doubt, therefore I might be.” —anonymous |
  `\   |
_o__)  |
Ben Finney


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

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Ben Finney]

Luk Claes <[EMAIL PROTECTED]> writes:

> Manoj Srivastava wrote:
> > Hmm. I am not so sire it is nonsense. Yes, the release
> >  team is not alone in this, and, really, all of us are somewhat to
> >  blame for not helping the kernel team fix the DFSG violations.
> >  But I don't think that the release team is blameless, either,
> >  since they decided to release with DFSG violating code.
> 
> We didn't decide to release yet...

That's not the point being made: As I understand Manoj's point, it is
that tagging a bug ‘lenny-ignore’ is an active decision that a
particular bug, even if it represents a DFSG violation, will not be
considered in the decision to release.

To that extent, it *is* making the decision that it is acceptable to
release Debian with DFSG-violating works, in advance of the decision
to actually release.

-- 
 \  “As the evening sky faded from a salmon color to a sort of |
  `\   flint gray, I thought back to the salmon I caught that morning, |
_o__)and how gray he was, and how I named him Flint.” —Jack Handey |
Ben Finney


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

Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?

[Manoj Srivastava]

On Tue, Oct 21 2008, Luk Claes wrote:


> We didn't decide to release yet...

Fair enough.

>> Now, if we are all so very eager to have these bugs go away, we
>>  have no objections to an NMU with the patches that have been posted on
>>  -kernel mailing list, right? (Note: some of these patches have only
>>  recently been posted, so NMU's based on these patches have only just
>>  becme possible).
>
> Not in principle, though I would object an NMU that is not tested
> properly. 

What would you call proper testing? I promise to build the kernel
 images on two architectures I have access to (i386 and amd64), and test
 the images on the limited set of machines I have (3). If the NMU is
 uploaded to people.d.o, perhaps people with access to other hardware
 can test it (though I am no, perhaps, the best candidate to create the
 NMU, since Ben Hutchings has really been doing some heavy lifting with
 the patches).

If an NMU of the kernel package is acceptable, in absence of the
 kernel-team themselves accepting the patches and doing an MU, then
 perhaps the issue has been overblown.

My impression had been that the kernel image packages were
 deemed too important to NMU, especially given their impact on the
 installer.  I'd be happy to be proved wrong.

manoj
-- 
What the large print giveth, the small print taketh away.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bug reports of DFSG violations are tagged ???lenny-ignore????

[Marc Haber]

On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG
<[EMAIL PROTECTED]> wrote:
>On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote:
>> No, really.  The kernel team are volunteers.  Ordering them to do things
>> doesn't help at all; one could equally well send the same message to
>> everyone working on Debian (or, indeed, the wider community) since they
>> could also step up to the plate and help fix this issue.
>
>Of course.  These are RC bugs.  I would be happy to upload an NMU that
>fixed the RC issue by removing support for the relevant hardware, and
>dropping blobs from the source.  I don't think it's a very challenging
>task, but I'm happy to do so.  Will that be ok?

You're not seriously thinking that a release without E100 support does
make any sense and is any good for Debian, right?

Greetings
Marc

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


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