Re: Results for General Resolution: Lenny and resolving DFSG violations

[Raphael Hertzog]

On Mon, 29 Dec 2008, Anthony Towns wrote:
> Anyway, given the last proposal I made [0] went nowhere, unless people
> want to come up with their own proposals, or want to second the above as
> a draft proposal to be improved and voted on, I suspect nothing much will
> change, and we'll have this discussion again in a few years when squeeze
> is looking like releasing.

I think it would be worth it to take some time to draft an updated social
contract given the difficulties we've seen in the debate. I like most of
what I've seen in your proposal (except the wording on the point about
publishing any private stuff).

I would suggest you to let vacation time pass, and then try submitting
it again in a new thread (or maybe post-lenny, up to you). Whatever you
choose, I'll try to share my comments/participate in the discussion
anyway.

I'm not sure the whole rewrite is necessary, it might be easier to modify
less and give separate rationale for each change. But honestly I haven't
looked enough into it yet to comment more than that.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: adding pre-depends to libpam-modules for lenny

[Tollef Fog Heen]

]] Steve Langasek 

(Not wearing any particular hat here)

[...]

| Is it ok to make libpam-modules Pre-Depends: debconf (>= 0.5) | debconf-2.0
| for lenny?

Yes, I think this sounds reasonable (and your analysis looks good to me).

[...]

| So is it ok to also make libpam-modules Pre-Depends: ${shlibs:Depends} for
| lenny?  For reference, the current shlibs (on i386) are:
| 
|   libc6 (>= 2.7-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.59)
| 
| Again, these are all already transitively essential, so the main concern is
| whether further restricting the unpack order will cause any dependency
| loops, which I don't believe it will.

Testing or manually verifying that there are no loops is probably wise,
but otherwise this looks fine too.

| If y'all agree to this change, I can knock out the implementation within a
| couple of days and get another RC bug off the list - then I just have to
| accept the beatings from Christian for the implied addition of a new debconf
| template this late in the lenny freeze... :)

Just send him some cheese and red wine and he'll be happy. :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFC: adding pre-depends to libpam-modules for lenny

[Raphael Hertzog]

On Sun, 28 Dec 2008, Steve Langasek wrote:
> Therefore I think it's neither necessary nor appropriate for libpam-modules
> to avoid a pre-dependency on debconf.
> 
> Is it ok to make libpam-modules Pre-Depends: debconf (>= 0.5) | debconf-2.0
> for lenny?

I think so. We already have many predependencies on debconf so this is not
going to change much. 

I wonder however if the fact that you would not restart the service at the
same point in time might have an impact. 

> Also, once that change is made, it might be appropriate to also move the
> current service restart handling from the libpam0g postinst to the
> libpam-modules preinst.  The reason to do this is that libpam0g is not the
> only library used by libpam-modules that could cause symbol skew for a
> running service (the same problem has been reported in Ubuntu with
> versioned symbols from glibc), so although not relevant for etch->lenny
> (because the lenny libpam0g depends on the lenny libc6), in the general
> case it's possible the libpam0g postinst is too early to restart services to
> ensure they're usable afterwards with the new libpam-modules.
> 
> So is it ok to also make libpam-modules Pre-Depends: ${shlibs:Depends} for
> lenny?  For reference, the current shlibs (on i386) are:
> 
>   libc6 (>= 2.7-1), libdb4.6, libpam0g (>= 0.99.7.1), libselinux1 (>= 2.0.59)

Pre-depends has been created for critical part of the system that we can't
afford to leave even temporarily in a broken state, and IMO pam perfectly
fits this if it's required.

And from the analysis done, it looks like so. The simple Depends doesn't
ensure that the required libs are unpacked when the services are restarted
in the preinst and the Pre-Depends fixes that.

> Again, these are all already transitively essential, so the main concern is
> whether further restricting the unpack order will cause any dependency
> loops, which I don't believe it will.

But an etch-lenny upgrade test wouldn't hurt. :)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Peter Tuhársky]

Amaya  wrote / napísal(a):



By creating Debian Women, we are sending out the message that it is
definitely ok to be a female and and a geek, and we aim to create
visibility for those female users, developers, contributors... so that
they can serve as 'role models', or inspiration for other males and
females who might be inteested in getting involved. 


Yes, the time of announcement I felt it that way.


Regarding my personal webpage, it has nothing to do with Debian, so it
is offtopic in this discussion.


Well, it just gives different point of view on the recent "incident". It 
is often good to learn about the people's motives when decisions are made.



When I reflected upon my need for approval, I also found my answer to
the one million dollars question: Why are there so few women in
computing?
For me, the patriachy is an acceptable answer. Find your own, it is an
enlightment trip, and you do not need to aome to my same answer. 


For me, the answer is quite simple. The computing is almost technical 
industry, and therefore it is naturally more suitable for men, who are 
naturally strog in technical thinking and achieving the task milestones. 
Just like there are much more women in people-contact positions, because 
women are naturally better equipped for social contact, empathy, 
caregiving... Althought I think it is time now, that much of technical 
issues are being solved or solved already, and there is need to make the 
computing experienca "more human".


A man would usually be a terrible personal assistant (secretary) or 
kindergarden nurse, because men are weak in paralell-tasking, where 
women are strong.
I found these things to be natural -woman is just naturally better 
equipped for the household and children care, not because "man poses her 
to that pose", but because she really CAN effectively cope with multiple 
tasks at time, e.q. she can cook and guard a child at the same time, 
with ease. Man cannot do that, or only with extreme stress. Give him 
three tasks, he would overburn. Other hand, it is usually harder for a 
woman to keep track for long-term goals, concentrate to single task, 
etc. You can find a paralell in some stone-age image, where man must 
concantrate his conciousness and strength to single task -hunt down an 
animal so to feed his family, although I don't believe in stone-age 
either :-)


Admitting this knowledge, we can use our strong attributes for a great 
benefit, rather than suppressing the difference, that would also 
suppress our potential.


Peter


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Peter Tuhársky]

gregor herrmann  wrote / napísal(a):


Maybe you missed the "old enough" in Lisi's mail.
In Austria for example equal rights between man and woman in a
marriage exist only since 1975.
Cf. http://www.demokratiezentrum.org/media/pdf/info_familienrecht.pdf


Well, I've heard, that formally, a slavery has been cancelled just 1994 
in some states of USA.


There are many things people did and do wrong. Enslaving anyone if bad. 
Irrespectedly of gender. However, the feminism of its current shape, in 
countries where no discrimination is pushed on women, is making the same 
mistake, just in other direction. You know, apartheid has been cancelled 
not so long ago, and what took place then? Reversed apartheid. It is 
well-pictured in the Babylon 5 series, the Narn-Centauri neverending 
conflict. Bad for anyone, both sides just revenging the old sins, ad 
infinitum.


Peter


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Noah Slater]

On Mon, Dec 29, 2008 at 10:39:50AM +0100, Peter Tuhársky wrote:
> For me, the answer is quite simple. The computing is almost technical
> industry, and therefore it is naturally more suitable for men, who are
> naturally strog in technical thinking and achieving the task milestones.
> Just like there are much more women in people-contact positions, because
> women are naturally better equipped for social contact, empathy,
> caregiving... Althought I think it is time now, that much of technical
> issues are being solved or solved already, and there is need to make the
> computing experienca "more human".

This is total horseshit.

It is anecdotal gender profiling that causes women and men to choose certain
paths through life in the first place, and is hence one of the root causes of
the very problem we're trying to solve.

> A man would usually be a terrible personal assistant (secretary) or
> kindergarden nurse, because men are weak in paralell-tasking, where women are
> strong.

[citation needed]

> I found these things to be natural -woman is just naturally better equipped
> for the household and children care, not because "man poses her to that pose",
> but because she really CAN effectively cope with multiple tasks at time,
> e.q. she can cook and guard a child at the same time, with ease.

[citation needed]

> Man cannot do that, or only with extreme stress. Give him three tasks, he
> would overburn.

[citation needed]

> Other hand, it is usually harder for a woman to keep track for long-term
> goals, concentrate to single task, etc.

[citation needed]

> Admitting this knowledge, we can use our strong attributes for a great
> benefit, rather than suppressing the difference, that would also suppress our
> potential.

Don't fool your self, this isn't knowledge. It's anecdotal superstition.

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Noah Slater]

On Mon, Dec 29, 2008 at 10:55:54AM +0100, Peter Tuhársky wrote:
> There are many things people did and do wrong. Enslaving anyone if bad.
> Irrespectedly of gender. However, the feminism of its current shape, in
> countries where no discrimination is pushed on women, is making the same
> mistake, just in other direction. You know, apartheid has been cancelled not
> so long ago, and what took place then? Reversed apartheid. It is well-pictured
> in the Babylon 5 series, the Narn-Centauri neverending conflict. Bad for
> anyone, both sides just revenging the old sins, ad infinitum.

Wait, what?

> It is well-pictured in the Babylon 5 series

Tell me you didn't just cite a fictional universe...

-- 
Noah Slater, http://tumbolia.org/nslater


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Tzafrir Cohen]

On Mon, Dec 29, 2008 at 10:10:51AM +, Noah Slater wrote:
> On Mon, Dec 29, 2008 at 10:39:50AM +0100, Peter Tuhársky wrote:
> > For me, the answer is quite simple. The computing is almost technical
> > industry, and therefore it is naturally more suitable for men, who are
> > naturally strog in technical thinking and achieving the task milestones.
> > Just like there are much more women in people-contact positions, because
> > women are naturally better equipped for social contact, empathy,
> > caregiving... Althought I think it is time now, that much of technical
> > issues are being solved or solved already, and there is need to make the
> > computing experienca "more human".
> 
> It is anecdotal gender profiling that causes women and men to choose certain
> paths through life in the first place, and is hence one of the root causes of
> the very problem we're trying to solve.

Interesting discussion. But as Noah mentioned elsewhere: off-topic on 
this list. Feel free to continue this off-list. Or maybe on debian-women 
(where this thread started and was actually discussed).

-- 
Tzafrir Cohen | tzaf...@jabber.org | VIM is
http://tzafrir.org.il || a Mutt's
tzaf...@cohens.org.il ||  best
ICQ# 16849754 || friend


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Desktop standards, MIME info cache, and Lintian

[Loïc Minier]

On Sun, Dec 28, 2008, Russ Allbery wrote:
> 1. The update-desktop-database program used to be documented in the
>desktop entry spec in version 0.9.5 and was removed in 0.9.6 (the
>current version is 1.0).  Should I draw some conclusion from that?  Is
>this program and cache likely to go away?  Is it still really used?
>(It also seems odd that a cache regenerated from installed files is
>written to /usr/share rather than in /var.)

 (I have no idea why it's not mentionned anymore.)  Yes, the program is
 still used; it's in charge of generating
   /usr/share/applications/mimeinfo.cache (and
 /usr/local/share/applications/mimeinfo.cache); these files may then be
 used by e.g. gio (in GLib) to map MIME types to .desktop files
 (really applications).  This can be used for example to open web
 objects with the correct application according to its MIME type, or via
 shared-mime-info + gio -- which allow mapping of a file's content or
 filename to a MIME type -- to open any file with an application
 handling this MIME type.

> 2. Should Lintian be continuing to recommend that people installing
>*.desktop files call dh_desktop just in case, even if there are no
>MimeType entries in the *.desktop files?  I've been leaning that way in
>the past, but given how long it's been since dh_desktop was added and
>given that it still doesn't do anything else, I wonder if this isn't
>just noise.  I'm currently leaning towards removing the check for
>dh_desktop in favor of only checking for update-desktop-database when
>there are *.desktop files with MimeInfo unless someone tells me that's
>a bad idea.

 I can see how it would be useful to recommend calling dh_desktop as
 soon as you distribute .desktop files just like it would be more useful
 if we could inject any rules in packages via cdbs or the new "dh".
 However, this is really packaging style and using an extensible
 packaging style shouldn't be imposed by a checker tool like lintian;
 I'm not aware of any different dh_desktop usage which would justify
 raising a warning right now.

 Also, would we have to do more things on .desktop files, we would have
 more options to implement them without requiring dh_desktop (triggers
 come to mind).

 So not raising a lintian warning when dh_desktop isn't called on
 .desktop file would be more to my taste.

> 3. Does the Shared MIME-info Database or the update-mime-info program have
>anything to do with this?  I think I've convinced myself that they
>don't, but I'd love confirmation from someone who works more intensely
>in the desktop environment world than I.

 Not directly; they are used along this database.  The desktop file
 database only maps MIME types to .desktop files (applications really),
 and comes along a static list of applications which should be preferred
 for a MIME type (/usr/share/applications/defaults.list and friends).
 The Shared MIME Info database maps filenames and file contents patterns
 to MIME types.  These are often used together, but are distinct.

   Bye,
-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Russell Coker]

On Monday 29 December 2008 21:26, Tzafrir Cohen  wrote:
> > It is anecdotal gender profiling that causes women and men to choose
> > certain paths through life in the first place, and is hence one of the
> > root causes of the very problem we're trying to solve.
>
> Interesting discussion. But as Noah mentioned elsewhere: off-topic on
> this list. Feel free to continue this off-list. Or maybe on debian-women
> (where this thread started and was actually discussed).

http://mjg59.livejournal.com/94420.html

Matthew Garrett made a good point in the above blog post:
# And when you see behaviour that you think discourages others, call people on
# it. Even if nobody's behaviour changes as a result, you're sending a signal
# that not everyone in the community agrees. Sometimes all people want is to
# know that there'll be some people on their side.

While this discussion will have to end eventually it seems obvious to me that 
leaving a message such as the one Peter wrote without any response is not the 
way to do it.

-- 
russ...@coker.com.au
http://etbe.coker.com.au/  My Main Blog
http://doc.coker.com.au/   My Documents Blog


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Procese correos empezando hoy mismo y gane dinero

[Gane Dinero procesando emails]

Estimad@ amig@: 

Desde ahora tiene la posibilidad de poder ganar dinero
trabajando desde su Casa y de manera fácil.
Si usted nos elige deberá procesar correos electrónicos.
Para procesar correos tendrá que seguir unos sencillos pasos que le mostraremos.
Si usted puede procesar 20 correos electrónicos al día, a usted se le pagará 
$260.00 usd,
empezando hoy ($13 usd por cada correo que procese correctamente).
Cuanto se suele hacer es una media entre 5 y 20 correos que se procesan cada 
dia.
Nosotros le diremos cómo, ofreciéndole total información, material y las 
herramientas.

Usted tiene nuestra garantía de ganar dinero. Cada vez que usted
procese nuestros correos electrónicos, ganará dinero. Esto es un
método sencillo, honrado y fácil de hacer para ganar cientos y hasta
algunos miles de dólares cada mes. ¡Imagínese cúanto puede ganar en un año!
Empiece a procesar correos electrónicos Hoy. Copie mi dirección de
correo electrónico (email: universalarm...@gmail.com) y visite:

ð http://www.abundanciaydinero.blogspot.com
 
Sus ganancias pueden ser ilimitadas…

¡¡ Usted puede hacer sobre $150.00 en un tiempo entre 2 y 24 horas !!

Cuanto más tiempo invierta procesando estos correos electrónicos, más
dinero ganará, mientras trabaja desde la comodidad de su casa.

Una oportunidad honrada y efectiva en tiempos de crisis,

Sinceramente,

Su Patrocinador: Rafael Leán
Mail: universalarm...@gmail.com
 
Le deseamos que pase una Feliz Navidad y Próspero Año Nuevo
 
Si usted ha recibido este mensaje por error, por favor acepte nuestras
disculpas. Le pedimos que se tome la molestia de unos segundos y
responda a este e-mail con la siguiente nota. "No Deseo Recibir su
Correspondencia".

Muchas gracias por su tiempo.

"Unidos podremos vencer las limitaciones"
 
Algunas listas de envío email fueron obtenidas a través de www.5sent.info por 
lo que cumplimos las normas antispam

Urgent respond

[Martin Dent]

I have a new email address!You can now email me at: mar_tinden...@ymail.com

Sir/Madam,

I’ve business to discuss with you, please contact me, for more details

Dent

- Martin Dent

Re: mass bug filing for undefined sn?printf use

[Evgeni Golov]

On Sun, 28 Dec 2008 09:53:40 +0100 Adeodato Simó wrote:

> Evgeni Golov 
>desmume (U)

Forwarded upstream, they'll fix that asap.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Adeodato Simó]

* Thomas Bushnell BSG [Sun, 28 Dec 2008 21:55:36 -0800]:

> I wish we could have in the world of GNU/Linux one, just one,
> please--just one--distribution which really took free software as of
> cardinal importance.

I don't like the wording of your sentence, but I'll point out that
gNewSense already exists, and that then, even Stephen Fry (let alone
Richard Stallman) would endorse you.

http://www.gnewsense.org/

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
  Listening to: La Buena Vida - No lo esperaba de mí


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Osamu Aoki]

Hi,

On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote:
> On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote:
> > On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote:
> > > I wonder how many DDs were ashamed to vote the titled "Reaffirm the
> > > social contract" lower than the choices that chose to release.
> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> > Social Contract, which I objected to them, and I still object to now.
> > If there was a GR which chainged the Debian Social contract which
> > relaxed the first clause to only include __software__ running on the
> > Host CPU, I would enthusiastically vote for such a measure.
> 
> So what would such a SC look like?

I am impressed by your well thought proposal.  Thanks!
Here are my comments to it.
 
> We previously had a vote to revert the SC to 1.0, and while it defeated
> reaffirming the current SC, it lost to the option of simply postponing it.
> Maybe with nearly four years of experience since then, that's changed
> though.

I hope people have learned from this :-)

> Using the word "software" as the basis for the divide might be too much:
> we've already done a lot of work restricting main to DFSG-free docs, and
> I think it makes sense to keep that. Having main be a functioning bunch
> of free stuff with a minimal and decreasing amount of random non-free
> stuff we still need to support it works well, it seems to me.

Yes.

> Back in the day, I tried writing a version of the SC that felt both
> inspiring and within the bounds of what we could actually meet. It looked
> like:
...
>4. We will be open about our activities
> 
>   We will conduct our affairs in public and allow anyone to follow our
>   discussions. Where public disclosure is not immediately feasible
>   we will make any private discussions publically available at the
>   earliest opportunity.
...
> 
> It doesn't try to say how these goals are met, leaving that up to the DPL,
> ftpmaster, debian-policy, individual maintainers and future resolutions
> by the project. I think that makes sense by and large, but having the
> project state that explicitly might be necessary to avoid continuing
> ambiguity and arguments. 
...
> It drops the "100% free" phrasing we've had in the past, because
> fundamentally what we have isn't 100% free. It might be three-nines
> edging onto four-nines, but we don't even have an accurate measurement.
> Calling main as it stands today an "integrated system of free software"
> seems the best compromise between staying focussed on freedom, not
> claiming to be completely free until we are, and not devolving into
> impenetrable jargon that I could come up with.

You mean like many contracts which use best effort clause ... For
example, "we will use and promote FREE softwares to the extent possible."
 
> It redoes the "we will not hide problems" phrasing in a way that,
> I think, reflects the intent better than the current wording, which
> seems to support just about everything but the BTS to be done in
> secret. Unfortunately that's some way off current practice wrt conducting
> project activities on restricted machines, private IRC channels, unlogged
> IRC channels, in personal emails, and on private lists.

But the way you wrote in 4 as "we will make any private discussions
publically available at the earliest opportunity." is problematic since
it is 100% disclosure pledge. I suggest something along "we will make
any private discussions publically available at the earliest opportunity
to the extent appropriate for this objective."  I am using "this
objective" as "to allow anyone to follow our discussions".   I hope
someone can rephrase this better. 

...

> One other thing the above does is, unlike the current SC, is use the word
> "Debian" to refer solely to the project -- so it doesn't suffer from the
> confusion that when the current SC says "Debian will remain 100% free" you
> don't have to mentally substitute in "The main component of ... releases"
> in order to reconcile it with the later mentions of non-free stuff.

Yes, I like this.
 
> Since it's worded as a pledge, it might make sense that if it (or
> something like it) is ever adopted, that existing developers membership
> being dependent on them agreeing to the pledge. That didn't happen with
> the previous SC change, but it seems strange to claim to have a social
> contract when a significant number of members don't actually support
> it 100%.

I am not sure about the last part.  If you said "when a significant
number of members don't actually abide by it 100%.", I can agree.  As
much as we are discussing SC change now, we should allow us to discuss
changing it as long as we abide by the current SC during its valid term.
I mean people with view to have stricter FREE requirement should not be
forced to leave project via this "pledge process". 

To me, none of us made action which does not abide to the valid current
SC.  

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Florian Weimer]

* Theodore Tso:

> I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> Social Contract, which I objected to them, and I still object to now.
> If there was a GR which chainged the Debian Social contract which
> relaxed the first clause to only include __software__ running on the
> Host CPU, I would enthusiastically vote for such a measure.

I think it's not that simple anymore.

For instance, while I have no particular opinion on firmware, I object
to packages in main which, when run on a web browser, execute
proprietary Javascript blobs (either by shipping them in the package,
or by linking them in some way).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Mike Hommey]

On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer  
wrote:
> * Theodore Tso:
> 
> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> > Social Contract, which I objected to them, and I still object to now.
> > If there was a GR which chainged the Debian Social contract which
> > relaxed the first clause to only include __software__ running on the
> > Host CPU, I would enthusiastically vote for such a measure.
> 
> I think it's not that simple anymore.
> 
> For instance, while I have no particular opinion on firmware, I object
> to packages in main which, when run on a web browser, execute
> proprietary Javascript blobs (either by shipping them in the package,
> or by linking them in some way).

Following the same logic, you should be opposing to packages such as the
kernel, that allows to run proprietary ELF blobs. This is ridiculous.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510122: ITP: icicles -- an emacs library that enhances minibuffer/input completion

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: icicles
  Version : 22.0+2008-12-27
  Upstream Author : Drew Adams 
* URL : http://www.emacswiki.org/emacs/Icicles
* License : GPL
  Programming Lang: Lisp
  Description : an emacs library that enhances minibuffer completion, that 
is, input completion.

Icicles lets you do the following:
* cycle through completion candidates that match your current
  input
* use a pattern to match completion candidates, including:
  o regexp matching (including substring)
  o fuzzy matching
  o prefix matching (as in vanilla Emacs)
  o command abbreviation matching
* use multiple regexps to match candidates, chaining these filters
  together like piped 'grep' commands
* see all possible complete inputs (pertinent commands, variables,
  and so on) that match your partial or regexp input: the list is
  updated dynamically (incrementally) if you change your input
* see all previous inputs that match your partial or regexp input,
  and selectively reuse them
* match input against completion candidates that do not match a
  given regexp; that is, complement the set of matches and use the
  result for subsequent matching
* use multiple regexps to search (and replace) text across
  multiple buffers, files, or regions
* search areas of text that have a certain text property, such as
  a face
* browse Imenu or tags entries that match your partial or regexp
  input
* create and use multiple-choice menus; that is, menus where you
  can choose multiple entries any number of times
* create and use multi-commands ? commands that you can use to
  perform an action on any number of candidate inputs any number
  of times
* perform set operations (intersection, union,?) on the fly, using
  sets of completion candidates or other strings
* persistently save and later reuse sets of completion candidates
  (e.g. project file names)
* complete input piecewise, against multiple completion
  candidates, in parallel
* complete key sequences, and navigate the key-binding hierarchy
  (this includes the menu bar menu hierarchy) (see also LaCarte)
* sort completion candidates on the fly, in multiple,
  context-dependent ways

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (501, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Florian Weimer]

* Mike Hommey:

> On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer  
> wrote:
>> * Theodore Tso:
>> 
>> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
>> > Social Contract, which I objected to them, and I still object to now.
>> > If there was a GR which chainged the Debian Social contract which
>> > relaxed the first clause to only include __software__ running on the
>> > Host CPU, I would enthusiastically vote for such a measure.
>> 
>> I think it's not that simple anymore.
>> 
>> For instance, while I have no particular opinion on firmware, I object
>> to packages in main which, when run on a web browser, execute
>> proprietary Javascript blobs (either by shipping them in the package,
>> or by linking them in some way).
>
> Following the same logic, you should be opposing to packages such as the
> kernel, that allows to run proprietary ELF blobs. This is ridiculous.

If the kernel automatically downloaded some binary from the network
and executed it, I would consider that unacceptable for a default
configuration, too.

It's not the mere possibility that counts.  I'm against doing this by
default (or requiring it for almost any use of a package).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Theodore Tso]

On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote:
> 
> I would prefer this.  But I am afraid of it, and so I would vote against
> it.  I am afraid that there are folks in the project who really don't
> care if Debian is 100% free--even as a goal.  I think that Ted Tso is
> even one of them.

Fear is a terrible thing to use as the basis of decisions and of
votes; consider it was fear that drove many people to vote for
Proposition 8 in California

As I said in my recent blog entry[1], I believe that "100% free" is a
wonderful aspirational goal --- other things being equal.  However, I
don't believe it to be something that should be Debian's Object of
Ultimate Concern; there are other things that need to be taken into
consideration --- for example, allowing various machines owned by
Debian to be able to use their network cards might be a nice touch.

[1] http://thunk.org/tytso/blog/2008/12/28/debian-philosophy-and-people/

In other words, I believe in 100% Free as a goal; but I'm not a
fundamentalist nor a fanatic about it.

> I wish we could have in the world of GNU/Linux one, just one,
> please--just one--distribution which really took free software as of
> cardinal importance.

As others have pointed out, there is such a distribution, gNewSense; in
fact, if you look at [2], you will find that there are five others,
Ututu (the first fully free GNU/Linux distribution recognized by the
FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel.  So not only is
there one such distribution that takes free software of cardinal
importance, there are six in the world already.  Does Debian really
need to be the seventh such distribution?

[2] http://www.gnu.org/links/links.html#FreeGNULinuxDistributions

> In my opinion, developers who are unwilling to abide by the Social
> Contract in their Debian work should resign.  But they don't, and this
> is what has me afraid.

That would be like saying that people who don't agree with Proposition
Eight's amendment to the California constitution should leave the
state, as opposed to working to change it.  I prefer to stay within
Debian in the hopes that I can help it change to something which I
think is better; at the very release, reverting the 1.1 version of the
Social Contract, and perhaps, clarifying it.  I will note that Option
1, "Reaffirm the Social Contract" came in *dead* *last*:

  Option
  1 2 3 4 5 6 7
===   ===   ===   ===   ===   ===   ===
Option 1   4660727389   117
Option 2281 160   160   171   177   224
Option 325561 125   137   151   204
Option 4253   121   146 160   166   194
Option 5234   105   128   135 136   191
Option 6220   118   134   125   134 180
Option 7226   129   145   153   160   169

It was beaten by options 2 (281 - 46 = 235), 3 (255 - 60 = 195), 4
(253 - 72 = 181), 5 (234 - 73 = 161), 6 (220 - 89 = 131) and 7/FD (226
- 117 = 109).  Put another way, _very_ few people are willing to take
a fundamentalist interpretation of the Social contract (by AJ's
calculation, 9.3%) ahead of delaying Lenny.

I don't think encouraging 90% of the Debian Developers to resign would
be a particularly constructive suggestion.  Fixing the Social Contract
so it reflects our common understanding of what's best for the Debian
Community, both users and developers, is IMHO a better choice than
striving to become the Seventh Fundamentalist Linux Distribution on
the FSF's approved list.

Best regards,

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Mike Hommey]

On Mon, Dec 29, 2008 at 09:11:01AM -0500, Theodore Tso  wrote:
> As others have pointed out, there is such a distribution, gNewSense; in
> fact, if you look at [2], you will find that there are five others,
> Ututu (the first fully free GNU/Linux distribution recognized by the
> FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel.  So not only is
> there one such distribution that takes free software of cardinal
> importance, there are six in the world already.  Does Debian really
> need to be the seventh such distribution?

Except that none of these distros existed when Debian set the "100% free"
goal. Should it drop this goal now there are others such distros ? I don't
think so. Should it make it less important than in the past ? I don't
think either.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Theodore Tso]

On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote:
> Using the word "software" as the basis for the divide might be too much:
> we've already done a lot of work restricting main to DFSG-free docs, and
> I think it makes sense to keep that. Having main be a functioning bunch
> of free stuff with a minimal and decreasing amount of random non-free
> stuff we still need to support it works well, it seems to me.

I'm not convinced that leaving important parts of Debian undocumented
over doctrinal disputes over licensing terms is actually in the best
interests of users, but I recognize that's a position that people of
good will can (and have) disagreed upon.  If it were up to me, I would
have Debian work towards a system where packages could be tagged to
allow enable common user preferences (we won't be able to make
everyone happy) be enforced by what packages they can see/install.

Some users are OK with GFDL documentation, others are not; some users
are OK with non-free firmware, other are not.  So why can't we tag
packages appropriately, so that this can be reflected in a
configuration file so that people who are passionate about some
particular issue can decide what tradeoffs they are willing to make
with respect to usability and/or documentation based on how
Fundamentalistic they want to be with regards to the "100% Free"
goal/requirement?

Separating packages into separate sections to support these sorts of
policy preferences is a hack, and with appropriate tagging, in the
long run we can allow users to be much more fined-grained about
expressing their preferences --- which would be in line with our goal
of being a Universal OS, I think.

> Back in the day, I tried writing a version of the SC that felt both
> inspiring and within the bounds of what we could actually meet. It looked
> like:

I like this a lot.  However, I do have a few nits...

>We, the members of the Debian project, make the following pledge:
> 
>1. We will build a free operating system
> 
>   We will create and provide an integrated system of free software
>   that anyone can use. We will make all our work publically available
>   as free software.

Given how literalistic some members of our community can be about
interpreting Foundation Documents, the second sentence is a little
worrying.  I can easily imagine a Free Software Fanatic using the
second sentance as an argument that we must stop distributing the
non-free section, since non-free is, by definition, not Free Software.
And it could easily be argued that the work that Debian Developers to
package non-free packages, which is after all distributed on the
Debian FTP servers and via Debian Mirrors, would fall under the scope
of "All our work".

I'm not sure what you were trying to state by the second sentence
above; one approach might be to simply strike it from the draft.  Or
were you trying to add the constraint that any work authored by DD's
on behalf of the Debian Project should be made available under a free
software license, even if in combination with other software being
packaged, the result is non-free?

>2. We will build a superior operating system
> 
>   We will collect and distribute the best software available, and
>   strive to continually improve it by making use of the best tools
>   and techniques available.

I'm worried about the first clause, because of the absolutist word
"best" in "best software available".  Again, some literally minded
DD's could view this as meaning that the best is the enemy of the
good, and use this as bludgeon to say that since we have package X, we
should not have packages Y or Z, because, X is the *best*.   

Again, I'm not sure what you intended to add by the first clause, so
my first reaction would be to strike it and make it shorter/simpler:

We will strive to continually improve the software we collect
and distribute by making use of the best tools and techniques
available.


> I don't think the "community" clause is terribly well worded, but
> that's what you get when you make stuff up out of whole cloth rather
> than building on previous attempts.

It's not bad.  The one thing that I noted was "community" wasn't
terribly well defined.  Do we mean the user community?  The developer
community?  Upstream developers?  All of the above?  Adding an initial
phrase or sentence that affirmed that everyone who touches Debian in
some way (users, developers, upstream) are considered part of the
community --- and then follow it with your formulation pledging that
we will work to ensure that members of the community shall be treated
with respect --- would be the way I would go.

> Anyway, given the last proposal I made [0] went nowhere, unless people
> want to come up with their own proposals, or want to second the above as
> a draft proposal to be improved and voted on, I suspect nothing much will
> change, and we'll have this discussion again in a few years when squeeze
> is

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Romain Beauxis]

(Resending a previous private answer to Theodore since I believe it is 
relevant to the discussion..)

Le Monday 29 December 2008 15:11:01 Theodore Tso, vous avez écrit :
> As I said in my recent blog entry[1], I believe that "100% free" is a
> wonderful aspirational goal --- other things being equal.  However, I
> don't believe it to be something that should be Debian's Object of
> Ultimate Concern; there are other things that need to be taken into
> consideration --- for example, allowing various machines owned by
> Debian to be able to use their network cards might be a nice touch.
>
> [1] http://thunk.org/tytso/blog/2008/12/28/debian-philosophy-and-people/
>
> In other words, I believe in 100% Free as a goal; but I'm not a
> fundamentalist nor a fanatic about it.

I read your post. It is interesting and well argued.

However, I have the impression that it somehow draws the picture of a 
seperation between "productive pragmatic" guys and "idealist unproductive" 
ones.

For instance, you could also mention all the great work the the GNU and 
Stallman pioneered at there time. After all, if the pragmatic guy, Linus, 
decided to go for the GPL as it was GCC's licence, it was because the 
idealist one had prepared this for more than 10 years before.

Yes, pragmatism is a need when something has to happen sooner rather than 
later. I, too, believe that in the case of lenny, this was an issue.

But when it comes to more general purpose, I really support the central place 
of idealism. That is only this way that you can prepare and build a great 
change such as the GNU fondation did.

To me, the social contract is a very good compromise. It states first an 
idealist acheivement, but moderates it by some pragmatism concerning the 
users. "unproductive" discussions fall into the same category, when they do 
not end as flames or trolls.

That is mainly why I am against the notion of Code of Conduct.

Eventually, that is also the same vision that drives me in politics: an ideal 
goal moderated by pragmatism. Not the converse.


Romain


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Wouter Verhelst]

On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote:
> I wish we could have in the world of GNU/Linux one, just one,
> please--just one--distribution which really took free software as of
> cardinal importance.  Debian has promised to be that, while living up to
> the promise only in fits and starts.  That's ok with me.  But I'm afraid
> that if we stopped the promise, and simply decided it would be our goal,
> the folks who are against the promise will be against the goal, and will
> see this as permission to simply *never* work toward the goal, and to
> obstruct others who do.

I do not believe for a second that there is anyone in the Debian project
who would *oppose* working toward a goal of free software. However, I
also believe that pragmatism is a necessary requirement for a project as
large as Debian.

I am not in the camp of those who think that getting Debian to be
completely and utterly free software should be our one and only goal,
and that all the rest is unimportant; therefore, I did also vote for a
pragmatist option during this vote. But I will now solemny pledge that
if you can ever convince me (by pointing to BTS logs, or mailinglist
threads, or some such) that one of our developers is actively
*obstructing* the replacement of non-free software by free software, I
will immediately second a vote to expel them from the project. Freedom
may not be the primary goal for this project in my personal opinion, it
still is a goal that I find extremely important, and those who oppose it
have no place in the Project, ever.

Personally, I think that aj's proposed text actually makes it much more
clear that the social contract is not a statement of fact, but rather is
a promise and a goal. I do not think we should forget about the goal;
but I do think that if currently there is an idea for a perfect option
(which as of yet is vapourware) and an imperfect option that already
exists, we should go with imperfection.

[...]
> In my opinion, developers who are unwilling to abide by the Social
> Contract in their Debian work should resign.  But they don't, and this
> is what has me afraid.

I agree with you on that one, and I think you'll find that many
developers do. I also think you'll find that it would be easy to get
such developers kicked from the project.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


signature.asc
Description: Digital signature

[s...@powerlinux.fr: Re: Results for General Resolution: Lenny and resolving DFSG violations]

[Wouter Verhelst]

Hi,

Sven asked me to forward this message to the list. Since it does not
contain any of the vitriol for which he was expelled from the project,
and since it does contain some valid points on the discussion in
question, I decided to comply with his request.

I'd like to say, though, that this does not mean I necessarily agree
with his PoV.

- Forwarded message from Sven Luther  -

X-Spam-Checker-Version: SpamAssassin 3.1.7-deb3 (2006-10-05) on samba.grep.be
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 required=3.0 tests=AWL,BAYES_00,
UNPARSEABLE_RELAY autolearn=ham version=3.1.7-deb3
Date: Mon, 29 Dec 2008 11:39:25 +0100
To: Anthony Towns , lea...@debian.org,
da-mana...@debian.org, listmas...@debian.org, s...@powerlinux.fr
Cc: debian-v...@lists.debian.org, debian-devel@lists.debian.org,
Theodore Tso 
Subject: Re: Results for General Resolution: Lenny and resolving DFSG violations
Message-ID: <20081229103925.ga22...@powerlinux.fr>
In-Reply-To: <20081229050241.gd11...@blae.erisian.com.au>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Sven Luther 

On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote:
> 
> On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote:
> > On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote:
> > > I wonder how many DDs were ashamed to vote the titled "Reaffirm the
> > > social contract" lower than the choices that chose to release.
> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> > Social Contract, which I objected to them, and I still object to now.
> > If there was a GR which chainged the Debian Social contract which
> > relaxed the first clause to only include __software__ running on the
> > Host CPU, I would enthusiastically vote for such a measure.
> 
> So what would such a SC look like?
> 
> We previously had a vote to revert the SC to 1.0, and while it defeated
> reaffirming the current SC, it lost to the option of simply postponing it.
> Maybe with nearly four years of experience since then, that's changed
> though.

I think the problem is not really the social contract, what it currently
says is just fine, and we all agree with it.

We have free stuff, which is in main, and non-free stuff of diverse
variety, which is in non-free (plus the hybrid contrib).

My own guess is that all those clamoring to have non-free firmware and
non-free documentation or images or whatever in main, would be just as
satisfied if we decided to support non-free more (and maybe put choice
non-free stuff on our CD medias).

I believe this will satisfy everyeone, there will be no loss of
freeness over what we have now (we distribute this non-free stuff from
our ftp/http servers, which is just another distribution media compared
to CDs), while it allows for transparent installation of those non-free
drivers, and thus those wanting to be able to install on
non-free-firmware needing hardware should be happy too.

So, what is really needed is that we take the time to make the non-free
firmware support upto par to what we promised in our social contract :

  We acknowledge that some of our users require the use of works that do
  not conform to the Debian Free Software Guidelines. We have created
  "contrib" and "non-free" areas in our archive for these works. The
  packages in these areas are not part of the Debian system, although
  they have been configured for use with Debian

So, in this case, "configured for use with Debian", means that the
non-free firmware is well integrated with both d-i and our kernel.

So, basically, there is nothing to do here, nothing which will cause a
ideological schism, or which makes some of us forget our vows to support
the social contract when we joined debian (independent of what you
consider software or not).

We simply say :

  - non-free firmware and other stuff, are supported through the
non-free area of debian (which we may subclasify or something such,
but we need no social-contract change for that).

  - the stuff in non-free should be well integrated in debian, and we
will distribute the non-free stuff on our CD or other installation
media, that are needed for installing on modern hardware, provided
we are legally able to do so.

Then the question that remains is simple :

  - will we hold lenny until all remaining non-free stuff is moved to
non-free, and support for well integrated non-free is added into
debian where needed.

or 

  - will we release lenny as is, knowing that serious effort has been
made to make this separation easier, that non-free firmware has been
moved into non-free modules, and d-i support it to a degree, but
more work is needed for it ?

I guess that if asked such, there will be load of support for the second
option, since it is the most reasonable one, and none can deny that
there has been progress made on this front since our last release.

That will also allow us to put all these conflicts aside, and put our
energy

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Theodore Tso]

On Mon, Dec 29, 2008 at 04:38:25PM +0100, Romain Beauxis wrote:
> 
> To me, the social contract is a very good compromise. It states first an 
> idealist acheivement, but moderates it by some pragmatism concerning the 
> users. "unproductive" discussions fall into the same category, when they do 
> not end as flames or trolls.

It's a claim which has never been true.  "Debian shall _remain_ 100%
free"?  Remain implies that at one stage Debian had reached such a
state of Nirvana.  That has never been the case!  The disputes that we
have had, at each stable release since the 1.1 revision to the Social
Contract, have been precisely because some large, and vocal, set of
developers have not been willing to be pragmatic, but who have instead
argued for a very literalistic reading of the Social Contract.

> That is mainly why I am against the notion of Code of Conduct.

I don't see the connection which leads you to be against a Code of
Conduct, but I will note that Ubuntu CoC does not use any absolute
words.  It merely asks participants to:

* Be considerate
* Be respectful
* Be collaborative
* When you disagree, consult others
* When you are unsure, ask for help
* Step down considerately

These are idealistic goals --- by your own argument, what's wrong with
having them?  We need to moderate them by an understanding that human
nature being what it is, we will occasionally fail at this ideal; and
then ecourage and remind each other to try to strive for this as an
ideal --- not throw people out of the project when they fail to live
up to such a goal. 

Maybe you don't like the name "Code of Conduct", because it implies a
certain amount of inflexibility?  If so, maybe a different name would
make you more comfortable?

> Eventually, that is also the same vision that drives me in politics:
> an ideal goal moderated by pragmatism. Not the converse.

That's my vision as well; we might disagree about how far our
pragmatism might take us, but our ideals tell us which direction to
go, even if we are far from it at the moment.  The question is how
much patience do we have, and should we have?

I do feel quite strongly, that aspirational goals, if they are going
to be in Foundation Documents, must be clearly *labelled* as
aspirational goals, and not as inflexible mandates that _MUST_ be
kept.  In politics, can have aspirational ideals such as "a chicken in
every pot and two cars in every garage" which get used in campaign
slogans, but you don't put such things as a MUST in a country's
constitution.

- Ted


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Romain Beauxis]

Le Monday 29 December 2008 17:21:16 Theodore Tso, vous avez écrit :
> I do feel quite strongly, that aspirational goals, if they are going
> to be in Foundation Documents, must be clearly *labelled* as
> aspirational goals, and not as inflexible mandates that _MUST_ be
> kept.  In politics, can have aspirational ideals such as "a chicken in
> every pot and two cars in every garage" which get used in campaign
> slogans, but you don't put such things as a MUST in a country's
> constitution.

Freedom of speech is a constitutional disposition, and I don't think it is 
something that could be acheive. It really is a constitutional act. 

It is also why I am against the Code of Conduct. Freedom of speech is an 
utopism that I support for Debian, and a Code of Conduct, or whatever you 
call it, is a way to shut those who do abid to the politically-correctness 
way of expressing oneself.

As Orwell noticed it 50 years ago, restricting expressiveness is also 
restricting though. When someone shocks you with a broomstick, a Teletubies 
or a ironic picture, it breaks the lines and helps to reconsider you thoughs 
too.

More generally, the Human Rights is also a list of idealistic acheivements. 
However, it is a fundamental document at the United Nations for instance.

From time to time, people complain about the unrealistic consequences of them, 
such as our foreign minister here, but still they remain central in every 
place.

To transpose the discussion, how would you argue in the same debate, but about 
utopism generated by the Human Rights ? That Guantanamo was a pragmatic need 
to the USA to protect themselves ? That torturing people in Algeria was a 
pragmatic need for the french people ? (*)

Yes, I am exagerating, but adding bit of utopism is more then only stating its 
good will to someday probably perhaps do something about that.


Romain

(*) Please note that I am not insinuating that you are pro-guantanamo :)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510133: ITP: mbrola-en1 -- British English male voice for Mbrola

[Samuel Thibault]

Package: wnpp
Version: N/A; reported 2008-12-29
Severity: wishlist

* Package name: mbrola-en1
  Version : 19980910
  Upstream Author : Faculte Polytechnique de  Mons  -  mbrola team 
 
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
  Description : British English male voice for Mbrola
 This package contains an English diphone database provided in the context
 of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
 .
 It provides a British English male voice (known as "Roger's voice") to be used
 with the Mbrola program. It has been built from the original Roger diphones
 made available by CSTR, University of Edinburgh, as part of their generic
 text-to-speech system Festival.
 .
 http://www.cstr.ed.ac.uk/projects/festival.html
 .
 Input files use the SAMPA phonetic notation, as adopted in other Mbrola
 databases. This package also provides the correspondence with the MRPA
 phonetic notation used in the original distribution of Roger's voice
 in the Festival TTS system.


This is the first of a series of voices for the non-free mbrola speech synthesis
and serves as a first example for discussion.  It would provide the following
virtual packages: mbrola-voice-en-uk, mbrola-voice-en, mbrola-voice



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Charles Plessy]

Le Mon, Dec 29, 2008 at 10:10:51AM +, Noah Slater a écrit :
> 
> [citation needed]
> 
> [citation needed]
> 
> [citation needed]
> 
> [citation needed]
> 

Hi all,

while I can not tell for debian-women, I would like to stress out that for
debian-devel, what is needed is not citations but the end of this thread!

PS: and if people could also stop cross-posting between debian-vote and
debian-devel, I think that it would be a great progress for the usefulness of
debian-devel.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Building only one package from control file

[Anil Gulecha]

Hi,

If debian/control defines many binary packages, and I only want to
build one of them, is there a simpler method than modifying the
control file and removing the unneeded ones? Perhaps by passing a
particular argument to dpkg-buildpackage?

--
Anil
http://www.gulecha.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [s...@powerlinux.fr: Re: Results for General Resolution: Lenny and resolving DFSG violations]

[Patrick Matthäi]

> I think the problem is not really the social contract, what it currently
> says is just fine, and we all agree with it.

ACK.

> We have free stuff, which is in main, and non-free stuff of diverse
> variety, which is in non-free (plus the hybrid contrib).
> 
> My own guess is that all those clamoring to have non-free firmware and
> non-free documentation or images or whatever in main, would be just as
> satisfied if we decided to support non-free more (and maybe put choice
> non-free stuff on our CD medias).

I also agree in parts with you.
There was already somewhere a discussion about, my opinion is, that it
would be good to have e.g. an additional non-free netinstaller medium,
which includes non-free parts like bnx2 firmwares, some non-free drivers
which are necessary to run this machine and to get a connectivity (so on
also WLAN blobs).
e.g. we have some servers with those bnx2 (aka brotcom netextreme II)
cards, with the netinstaller we can not get a connectivity to the
network, remote installations are so on for the a... :)

> 
> I believe this will satisfy everyeone, there will be no loss of
> freeness over what we have now (we distribute this non-free stuff from
> our ftp/http servers, which is just another distribution media compared
> to CDs), while it allows for transparent installation of those non-free
> drivers, and thus those wanting to be able to install on
> non-free-firmware needing hardware should be happy too.

The point is (except from some realy crazy licenses) that the most ppl
in Debian (I am counting myself to this group) do not want to support
non-free stuff, which is also an enforcement for the vendor/programmer
to switch to a free solution.


-- 
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi

E-Mail: patrick.matth...@web.de

Comment:
Always if we think we are right,
we were maybe wrong.
*/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510136: ITP: libwirble-ruby -- extensions for the Ruby irb command line shell

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 


* Package name: libwirble-ruby
  Version : 0.1.2
  Upstream Author : Paul Duncan 
* URL : http://pablotron.org/software/wirble
* License : MIT/X
  Programming Lang: Ruby
  Description : extensions for the Ruby irb command line shell

A handful of useful Irb features, including colorized results,
tab-completion, history, a simple prompt, and several helper
methods, all rolled into one easy to use package.

-- System Information:
Debian Release: 5.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function

[Josselin Mouette]

Le dimanche 28 décembre 2008 à 15:38 +0100, Evgeni Golov a écrit :
> On Mon, 29 Dec 2008 00:04:58 +1000 Kel Modderman wrote:
> 
> >  Touchfreeze docks in your system tray and disables your touchpad
> >  while typing. It re-enables your touchpad when typing stops, using a
> >  configurable delay time.
> 
> How does this compare to syndaemon from xserver-xorg-input-synaptics?

Especially, does it avoid waking up the CPU several tens of times per
seconds like syndaemon does?

-- 
 .''`.
: :' :  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: Building only one package from control file

[Eduard Bloch]

#include 
* Anil Gulecha [Mon, Dec 29 2008, 10:49:31PM]:
> Hi,
> 
> If debian/control defines many binary packages, and I only want to
> build one of them, is there a simpler method than modifying the
> control file and removing the unneeded ones? Perhaps by passing a
> particular argument to dpkg-buildpackage?

Depends on what you are using to build the package. If that's debhelper,
read debhelper(7) to learn about the -p option and others. And please
ask on the debian-mentors ML next time.

Regards,
Eduard.

-- 
 Bietet Debian eigentlich auch die Möglichkeit, Sounds abzuspielen?
 Freezer|: nein, debian ist nur fuer gehoerlose


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Daniel Moerner]

On Mon, Dec 29, 2008 at 7:54 AM, Wouter Verhelst  wrote:
> On Sun, Dec 28, 2008 at 09:55:36PM -0800, Thomas Bushnell BSG wrote:
>> I wish we could have in the world of GNU/Linux one, just one,
>> please--just one--distribution which really took free software as of
>> cardinal importance.  Debian has promised to be that, while living up to
>> the promise only in fits and starts.  That's ok with me.  But I'm afraid
>> that if we stopped the promise, and simply decided it would be our goal,
>> the folks who are against the promise will be against the goal, and will
>> see this as permission to simply *never* work toward the goal, and to
>> obstruct others who do.
>
> I do not believe for a second that there is anyone in the Debian project
> who would *oppose* working toward a goal of free software. However, I
> also believe that pragmatism is a necessary requirement for a project as
> large as Debian.
>

I agree.  But I think the gap in understanding here is that there are
different interpretations of obstruct in play.  I think that the
hardcore idealists (excuse this extreme term, but it's the most
descriptive at hand) believe that the Social Contract produces some
sort of positive obligation to work as hard as possible to make Debian
as free as possible.  Under this interpretation of the Social
Contract, anything which is not in the name of promoting free software
would count as obstruction.

In contrast, it seems like the pragmatists (again, I think Romain
makes an excellent post--I will only use this terminology because it
seems common in the thread) see the Social Contract as promoting a
sort of dualism. [0] That is to say, the Social Contract says that we
should distribute free software and that we should serve our users.
It creates negative obligations not to promote non-free and not to
harm our users, but not a particular positive obligation in terms of
favoring one or the other. At times when these goals are
incommensurate, we must decide between them, instead of always
defaulting in favor of one or the other.  In other words, you only
obstruct free software if you actively work to include it in
Debian--and I don't think anyone is advocating this (no one wants to
fork the kernel to avoid upstream's decision to split out non-free
blobs!)

Ted Tso seems to point out the problem with second perspective--the
Social Contract seems to, in its present wording, deny us access to
this dualism.  It has very strong rhetoric in favor of free software,
with more pliant rhetoric in favor of our users. I think that it is
preferable if the Social Contract were revised to be less absolutist.
Debian needs such flexibility, in my opinion. Since I'm not a
developer, I don't feel qualified to really speak to such a change.

Daniel

[0] http://en.wikipedia.org/wiki/Dualism

-- 
Daniel Moerner 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: "Debian women may leave due to 'sexist' post"

[Eduard Bloch]

#include 
* Noah Slater [Mon, Dec 29 2008, 10:13:10AM]:
> On Mon, Dec 29, 2008 at 10:55:54AM +0100, Peter Tuhársky wrote:
> > There are many things people did and do wrong. Enslaving anyone if bad.
> > Irrespectedly of gender. However, the feminism of its current shape, in
> > countries where no discrimination is pushed on women, is making the same
> > mistake, just in other direction. You know, apartheid has been cancelled not
> > so long ago, and what took place then? Reversed apartheid. It is 
> > well-pictured
> > in the Babylon 5 series, the Narn-Centauri neverending conflict. Bad for
> > anyone, both sides just revenging the old sins, ad infinitum.
> 
> Wait, what?
> 
> > It is well-pictured in the Babylon 5 series
> 
> Tell me you didn't just cite a fictional universe...

And? IIRC there is a large fan base among Debian developers including
leading ones (hello Vorlon). And, after all, JMS created a good space
opera reflecting many issues of today's politics and human interaction.

But if you dislike SF by heart, take any real example of never ending
blood feud.

Regards,
Eduard.

-- 
 HE: oder bist du schon ins cabal eingeschworen worden?
 mrvn: Klar. Ich musste eine Hand in die Hose stecken, eine auf ein
Notebook legen und laut "I agree to distribute free p0rn to our users"
sagen.
 Erm. Mist. Das war die Lesbian-CABAL.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#510005: ITP: touchfreeze -- a facility for disabling touchpad tap-to-click function

[Kel Modderman]

On Tuesday 30 December 2008 03:44:26 Josselin Mouette wrote:
> Le dimanche 28 décembre 2008 à 15:38 +0100, Evgeni Golov a écrit :
> > On Mon, 29 Dec 2008 00:04:58 +1000 Kel Modderman wrote:
> > 
> > >  Touchfreeze docks in your system tray and disables your touchpad
> > >  while typing. It re-enables your touchpad when typing stops, using a
> > >  configurable delay time.
> > 
> > How does this compare to syndaemon from xserver-xorg-input-synaptics?
> 
> Especially, does it avoid waking up the CPU several tens of times per
> seconds like syndaemon does?
> 

I think they are similar in that regard ...

Thanks, Kel.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Gerfried Fuchs]

* Florian Weimer  [2008-12-29 15:01:19 CET]:
> * Theodore Tso:
> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> > Social Contract, which I objected to them, and I still object to now.
> > If there was a GR which chainged the Debian Social contract which
> > relaxed the first clause to only include __software__ running on the
> > Host CPU, I would enthusiastically vote for such a measure.
> 
> I think it's not that simple anymore.
> 
> For instance, while I have no particular opinion on firmware, I object
> to packages in main which, when run on a web browser, execute
> proprietary Javascript blobs (either by shipping them in the package,
> or by linking them in some way).

 But it is. The web browser does run on the Host CPU, thus the
javascript engine does run on the Host CPU, too.

 Problem solved. :)
Rhonda
P.S.: Was there a MF'up2 anywhere? Not sure if this should/has to
   continue on both lists?
P.P.S.: Weren't the Results usually mailed to d-d-a, too? Was this a
   mistake here, or is my memory flawed?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Desktop standards, MIME info cache, and Lintian

[Russ Allbery]

Loïc Minier  writes:

>  (I have no idea why it's not mentionned anymore.)  Yes, the program is
>  still used; it's in charge of generating
>/usr/share/applications/mimeinfo.cache (and
>  /usr/local/share/applications/mimeinfo.cache); these files may then be
>  used by e.g. gio (in GLib) to map MIME types to .desktop files
>  (really applications).  This can be used for example to open web
>  objects with the correct application according to its MIME type, or via
>  shared-mime-info + gio -- which allow mapping of a file's content or
>  filename to a MIME type -- to open any file with an application
>  handling this MIME type.

Thanks for the confirmation!

>  I can see how it would be useful to recommend calling dh_desktop as
>  soon as you distribute .desktop files just like it would be more useful
>  if we could inject any rules in packages via cdbs or the new "dh".
>  However, this is really packaging style and using an extensible
>  packaging style shouldn't be imposed by a checker tool like lintian;
>  I'm not aware of any different dh_desktop usage which would justify
>  raising a warning right now.
>
>  Also, would we have to do more things on .desktop files, we would have
>  more options to implement them without requiring dh_desktop (triggers
>  come to mind).
>
>  So not raising a lintian warning when dh_desktop isn't called on
>  .desktop file would be more to my taste.

Okay, that matches my reasoning.  I'll remove that tag in the next version
of Lintian.  Thank you very much!

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Russ Allbery]

Romain Beauxis  writes:
> Le Monday 29 December 2008 17:21:16 Theodore Tso, vous avez écrit :

>> I do feel quite strongly, that aspirational goals, if they are going to
>> be in Foundation Documents, must be clearly *labelled* as aspirational
>> goals, and not as inflexible mandates that _MUST_ be kept.  In
>> politics, can have aspirational ideals such as "a chicken in every pot
>> and two cars in every garage" which get used in campaign slogans, but
>> you don't put such things as a MUST in a country's constitution.

> Freedom of speech is a constitutional disposition, and I don't think it
> is something that could be acheive. It really is a constitutional act.

Which constitution?  I don't see any reference to it in Debian's
constitution, and the constitution of the country in which I live doesn't
guarantee anything at all about someone's ability to use project mailing
lists.  It only constrains the actions of the *government*, not private
projects and their use of their own resources.

I've stopped working on other projects in the past because this idea that
anyone can and should be able to say anything that enters their head at
any time, no matter how uncomfortable or miserable they made it for other
people working on the same project, became so prevelant that the
atmosphere became so hostile that it became impossible to have a
reasonable conversation about any even mildly controversial topic.  Debian
isn't there now, and maybe it's not in imminent danger of degrading to
that point, but I've watched it happen and know that it *can* happen.
It's not a theoretical scenario.

People like to advocate the merits of personal filtering as if it solves
all of these problems.  I used to do that myself before I lived through
one of those collapses of good will.  Personal filtering is not a bad
answer to individual people who are widely ignored.  It does nothing when
the tone of conversation degrades to the point where polite conversation
is drowned out by multiple people yelling at each other.  It's also rather
hard to just ignore people when they start calling you things like
pedophile out of the blue (yes, this actually happened).

I'm not, at present, wholly convinced that a Code of Conduct would help or
how it would work.  But this dedication to free speech inside a working
project is, in my opinion, a nasty bit of blindness.  I've seen that ideal
rip people to shreds and tear apart previously working communities.  I
think one can possibly make an argument that Debian is unlikely to be
susceptible to that, but I think that argument has to be made.  The
problem can't be casually dismissed -- it's happened elsewhere.

> It is also why I am against the Code of Conduct. Freedom of speech is an
> utopism that I support for Debian, and a Code of Conduct, or whatever
> you call it, is a way to shut those who do abid to the
> politically-correctness way of expressing oneself.

> As Orwell noticed it 50 years ago, restricting expressiveness is also 
> restricting though.

I'm in the middle of a study of Orwell's fiction and non-fiction writing
and therefore can say with quite a bit of confidence that Orwell would not
have supported the position that you're taking.

Political correctness is apparently what people now call basic human
politeness when they want to ridicule it.  *There's* your Orwellian
Newspeak.

-- 
Russ Allbery (r...@debian.org)   


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2008-5378: possible symlink attacks

[Andreas Tille]

On Mon, 22 Dec 2008, Thomas Viehmann wrote:


Oh, and if you really care, be sure that it's a regular file (not a
symlink pointing to something) owned by yourself before using it as a
hint to kill your processes.


Thanks for your hints.  I've prepared a patch at

  
http://svn.debian.org/wsvn/debian-med/trunk/packages/arb/trunk/debian/patches/tmpfile_CVE-2008-5378.patch?op=file&rev=0&sc=0

and

  
http://svn.debian.org/wsvn/debian-med/trunk/packages/arb/trunk/debian/bin/arb-kill?op=file&rev=0&sc=0

Could you please inspect this patch before I do the upload?

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Mark Brown]

On Mon, Dec 29, 2008 at 04:20:28PM +0100, Mike Hommey wrote:
> On Mon, Dec 29, 2008 at 09:11:01AM -0500, Theodore Tso  wrote:

> > FSF), Dynebolic, Musix GNU+Linux, BLAG, and Trisquel.  So not only is
> > there one such distribution that takes free software of cardinal
> > importance, there are six in the world already.  Does Debian really
> > need to be the seventh such distribution?

> Except that none of these distros existed when Debian set the "100% free"
> goal. Should it drop this goal now there are others such distros ? I don't
> think so. Should it make it less important than in the past ? I don't
> think either.

Debian has always had a more relaxed view on these matters than the free
software purists would like - things like providing contrib and non-free 
aren't entirely acceptable to them and are one of the reasons why people
go to these other distributions with their stronger political focus.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2008-5378: possible symlink attacks

[Thomas Viehmann]

Hi,

Andreas Tille wrote:
> On Mon, 22 Dec 2008, Thomas Viehmann wrote:
> 
>> Oh, and if you really care, be sure that it's a regular file (not a
>> symlink pointing to something) owned by yourself before using it as a
>> hint to kill your processes.
> 
> Thanks for your hints.  I've prepared a patch at
>http://svn.debian.org/wsvn/debian-med/trunk/packages/arb/trunk/debian/patches/tmpfile_CVE-2008-5378.patch?op=file&rev=0&sc=0

The creation of tempfiles in shell looks OK save the processing of the
exit code (unless you set -e or somesuch) and the hardcoding of /tmp,
for the C side, let me quote the manpage (man 3 mktemp):
   Never use mktemp().
(This is what I meant with my comment to think about securely created
filenames instead of files, you need to use mk*s*temp which has
different semantics).
The killing part is also still somewhat wrong, IMO you want something
along the lines of
x=$(stat -c '%u %f' x) ; [ "${x%???}" == "$UID 8" ] || echo fail
to test whether it's a regular file that you own (though there is bound
to be a prettier way to verify that, even if [ -f ... ] is not part of it).

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[OT] American Slavery (was Re: "Debian women may leave due to 'sexist' post")

[Ron Johnson]

On 12/29/08 03:55, Peter Tuhársky wrote:

gregor herrmann  wrote / napísal(a):


Maybe you missed the "old enough" in Lisi's mail.
In Austria for example equal rights between man and woman in a
marriage exist only since 1975.
Cf. http://www.demokratiezentrum.org/media/pdf/info_familienrecht.pdf


Well, I've heard, that formally, a slavery has been cancelled just 1994 
in some states of USA.


Maybe some old Jim Crow[0] laws that hadn't been enforced in 20 
years.  Slavery, though, has been illegal since December 1865.


[0] http://en.wikipedia.org/wiki/Jim_Crow_laws

--
Ron Johnson, Jr.
Jefferson LA  USA

I like my women like I like my coffee - purchased at above-market
rates from eco-friendly organic farming cooperatives in Latin America.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510148: ITP: coinor-osi -- COIN-OR Open Solver Interface

[Aramian Wasielak]

Package: wnpp
Severity: wishlist
Owner: Aramian Wasielak 


* Package name: coinor-osi
  Version : 0.99.1
  Upstream Author : Matthew Saltzman , and others
* URL : https://projects.coin-or.org/Osi
* License : CPL
  Programming Lang: C++
  Description : COIN-OR Open Solver Interface

The COIN-OR Open Solver Interface is a uniform API for interacting with
callable solver libraries. It supports linear programming solvers as well as
the ability to "finish off" a mixed-integer problem calling the solver
library's MIP solver.

Osi is part of the larger COIN-OR initiative (Computational Infrastructure
for Operations Research).

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Florian Weimer]

* Gerfried Fuchs:

>> For instance, while I have no particular opinion on firmware, I object
>> to packages in main which, when run on a web browser, execute
>> proprietary Javascript blobs (either by shipping them in the package,
>> or by linking them in some way).
>
>  But it is. The web browser does run on the Host CPU, thus the
> javascript engine does run on the Host CPU, too.
>
>  Problem solved. :)

The counterargument is that for a server application, the Javascript
blob isn't intended to run on the host CPU, but on the client. 8-/

(Conversely, firmware shouldn't doesn't non-free material only because
you can run it using qemu because it happens to be a supported
architecture.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Mike Hommey]

On Mon, Dec 29, 2008 at 03:16:05PM +0100, Florian Weimer wrote:
> * Mike Hommey:
> 
> > On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer 
> >  wrote:
> >> * Theodore Tso:
> >> 
> >> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> >> > Social Contract, which I objected to them, and I still object to now.
> >> > If there was a GR which chainged the Debian Social contract which
> >> > relaxed the first clause to only include __software__ running on the
> >> > Host CPU, I would enthusiastically vote for such a measure.
> >> 
> >> I think it's not that simple anymore.
> >> 
> >> For instance, while I have no particular opinion on firmware, I object
> >> to packages in main which, when run on a web browser, execute
> >> proprietary Javascript blobs (either by shipping them in the package,
> >> or by linking them in some way).
> >
> > Following the same logic, you should be opposing to packages such as the
> > kernel, that allows to run proprietary ELF blobs. This is ridiculous.
> 
> If the kernel automatically downloaded some binary from the network
> and executed it, I would consider that unacceptable for a default
> configuration, too.
> 
> It's not the mere possibility that counts.  I'm against doing this by
> default (or requiring it for almost any use of a package).

Forget my message, I was reading "Java blobs" and thought you were
talking about the openjdk plugin.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2008-5378: possible symlink attacks

[Andreas Tille]

On Mon, 29 Dec 2008, Thomas Viehmann wrote:


  Never use mktemp().


Args - I've read this and intended to use in both cases mkstemp - but then
just forgot this.  I think just for reading files mktemp is fine.  The
rationale is that I do not really want to rewrite the reading routine
which opens the file to read.  The mkstemp function also opens the file
and returns a handle - which is just very different from the current code.
I commited a hopefully better patch (where mkstemp is used for writing
a file).


(This is what I meant with my comment to think about securely created
filenames instead of files, you need to use mk*s*temp which has
different semantics).


At least I had the good idea to ask vor cross checking ...


The killing part is also still somewhat wrong, IMO you want something
along the lines of
x=$(stat -c '%u %f' x) ; [ "${x%???}" == "$UID 8" ] || echo fail
to test whether it's a regular file that you own (though there is bound
to be a prettier way to verify that, even if [ -f ... ] is not part of it).


Do you think that this is definitely needed to avoid any security
problem in this specific case?

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2008-5378: possible symlink attacks

[Thomas Viehmann]

Andreas Tille wrote:
> On Mon, 29 Dec 2008, Thomas Viehmann wrote:
> 
>>   Never use mktemp().
> 
> Args - I've read this and intended to use in both cases mkstemp - but then
> just forgot this.  I think just for reading files mktemp is fine.  The
> rationale is that I do not really want to rewrite the reading routine
> which opens the file to read.  The mkstemp function also opens the file
> and returns a handle - which is just very different from the current code.
> I commited a hopefully better patch (where mkstemp is used for writing
> a file).
Hm. What is reading here?
Also, mkstemp(3):
   The last six characters of template must be "XX" and these
   are replaced with a string that makes the  filename
   unique.   Since it will be modified, template must not be a
   string constant, but should be declared as a character array.
so you have the name readily available.

>> The killing part is also still somewhat wrong, IMO you want something
>> along the lines of
>> x=$(stat -c '%u %f' x) ; [ "${x%???}" == "$UID 8" ] || echo fail
>> to test whether it's a regular file that you own (though there is bound
>> to be a prettier way to verify that, even if [ -f ... ] is not part of
>> it).

> Do you think that this is definitely needed to avoid any security
> problem in this specific case?

Don't know, causing people to accidentally kill their processes seems
nasty to me, but it might not be that critical.

Kind regards

T.

-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: CVE-2008-5378: possible symlink attacks

[Russ Allbery]

Thomas Viehmann  writes:
> Andreas Tille wrote:

>> Args - I've read this and intended to use in both cases mkstemp - but
>> then just forgot this.  I think just for reading files mktemp is fine.
>> The rationale is that I do not really want to rewrite the reading
>> routine which opens the file to read.  The mkstemp function also opens
>> the file and returns a handle - which is just very different from the
>> current code.  I commited a hopefully better patch (where mkstemp is
>> used for writing a file).

> Hm. What is reading here?
> Also, mkstemp(3):
>The last six characters of template must be "XX" and these
>are replaced with a string that makes the  filename
>unique.   Since it will be modified, template must not be a
>string constant, but should be declared as a character array.
> so you have the name readily available.

Right, mkstemp gives you a file name that you can then safely open.  In
code where I didn't want to break the existing flow, I've used the
following pattern many times:

fd = mkstemp(filename);
if (fd < 0) {
perror("mkstemp");
return NULL;
}
close(fd);
/* Go on to use filename as the name of the temporary file... */

It's an extra few system calls, but usually it doesn't matter.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[gregor herrmann]

On Mon, 29 Dec 2008 17:45:56 +0100, Romain Beauxis wrote:

> Freedom of speech is a constitutional disposition, and I don't think it is 
> something that could be acheive. It really is a constitutional act. 
>
> It is also why I am against the Code of Conduct. Freedom of speech is an 
> utopism that I support for Debian, and a Code of Conduct, or whatever you 
> call it, is a way to shut those who do abid to the politically-correctness 
> way of expressing oneself.

TTBOMK there's no unrestricted Freedom of Speech in any constitution.

The constitutional Freedom of Speech does not cover what someone is
allowed to do in my living room, does not allow to shout aloud at 4
a.m. in front of my sleeping room and makes libellous public
statements prosecutable. (And I'm ignoring here more local
restrictions like political campaigning on election days or denial of
the Holocaust etc.)

If Debian adopts a CoC (which probably is nothing more than writing
down patterns of obvious behaviour among civilized grown-ups) that
would not be an infringement of Freedom of Speech -- it would just
set rules for specific fora and it would not hinder anyone from
expressing there thoughts in their preferred way in other media.

I also agree with Russ' statement that guarantees about Freedom of
Speech (and against censorship) "only constrain[s] the actions of the
*government*". Or more bluntly: Debian simply cannot censor anyone,
and an inflationary use of "censorship" just blurs and weakens
this term.

On a more personal note: I still don't understand why the expressed
wish of several people "please treat your fellows with respect" can
cause such a stir.

Cheers,
gregor
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Tina Turner: The Best


signature.asc
Description: Digital signature

Re: mass bug filing for undefined sn?printf use

[Kees Cook]

On Sun, Dec 28, 2008 at 01:51:45PM -0600, Steve Langasek wrote:
> On Sun, Dec 28, 2008 at 12:42:46AM -0800, Kees Cook wrote:
> > samba
> 
> Another false positive, AFAICS:
> 
> $   pcregrep -rM 'sprintf\s*\(\s*([^,]*)\s*,\s*"%s[^"]*"\s*,\s*\1\s*,' source
> source/libads/kerberos.c: fname = talloc_asprintf(dname, 
> "%s/krb5.conf.%s", dname, domain);

Thanks, I've marked samba and wmi as false alarms.

> Perhaps adding a \b to the front of the regexp would be appropriate?

I didn't include a word-break intentionally; I think the benefits are
greater, since it catches luckily-named variations like g_sprintf (which
I knew of ahead of time) and ircsprintf (found during search).

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: mass bug filing for undefined sn?printf use

[Kees Cook]

Hi,

On Sun, Dec 28, 2008 at 03:10:37PM +0100, Thomas Viehmann wrote:
> How about either matching stuff against the build logs or recompiling

I didn't have the resources to do this, but it's be great if someone could.

> with a compiler that actually fails when asked to compile a file that
> matches? That would seem to have potential for reducing the number of
> false positives.

I'd really love that too -- I just don't know how to modify the compiler to
do it.  :)

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: mass bug filing for undefined sn?printf use

[Kees Cook]

On Sun, Dec 28, 2008 at 10:27:16AM +, Neil Williams wrote:
> On Sun, 28 Dec 2008 00:42:46 -0800 Kees Cook  wrote:
> > In Debian, some tools already compile natively with -D_FORTIFY_SOURCE=2,
> > and some have Build-Depends on "hardening-wrapper", which enables this
> > compiler flag.  As such, it seems sensible to have all affected packages
> > fixed since the results of such a call could change.  (Though it is not an
> > RC issue.)
> 
> By all affected packages, do you mean packages that use the code or
> packages that use the code *AND* compile with  or
> Build-Depend on hardening-wrapper?
> 
> IMHO any bugs filed merely due to the presence of the code without the
> means to trigger the error in normal builds should be wishlist.

Sorry for the confusion -- I meant "present in the code", not "actively
broken".  I agree it's not a "normal" bug, but I'd like to see the bug at
least as "low" since (with a stock glibc) the bug would appear if a
maintainer decided to use "hardening-wrapper".

> > Thoughts?
> 
> Split the list according to packages that merely match the regexp and
> those that match the regexp *AND* match a second regexp indicating that
> the build system either uses -D_FORTIFY_SOURCE=2 or hardening-wrapper?

Good idea, those can be opened with "normal" severity.

-Kees

-- 
Kees Cook@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: mass bug filing for undefined sn?printf use

[Asheesh Laroia]

On Mon, 29 Dec 2008, Kees Cook wrote:


Hi,

On Sun, Dec 28, 2008 at 03:10:37PM +0100, Thomas Viehmann wrote:

How about either matching stuff against the build logs or recompiling


I didn't have the resources to do this, but it's be great if someone could.


I'll work on this now.

-- Asheesh.

--
Your ignorance cramps my conversation.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Anthony Towns]

On Mon, Dec 29, 2008 at 10:03:20AM -0500, Theodore Tso wrote:
> On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote:
> > Using the word "software" as the basis for the divide might be too much:
> I'm not convinced that leaving important parts of Debian undocumented
> over doctrinal disputes over licensing terms is actually in the best
> interests of users, but I recognize that's a position that people of
> good will can (and have) disagreed upon.  If it were up to me, I would
> have Debian work towards a system where packages could be tagged to
> allow enable common user preferences (we won't be able to make
> everyone happy) be enforced by what packages they can see/install.

Sure, I agree, and have supported similar proposals in the past. [0]

  [0] http://lists.debian.org/debian-project/2005/04/msg00074.html

> Separating packages into separate sections to support these sorts of
> policy preferences is a hack, 

Not entirely. The pool/main (and dists/*/main) separation makes it easy
for mirrors to only get DFSG-free stuff (ie, they can just use rsync,
rather than needing to parse Debian-specific policy files). 

Otherwise, though, yes, definitely agree.

> I like this a lot.  However, I do have a few nits...
> >We, the members of the Debian project, make the following pledge:
> >1. We will build a free operating system
> >   We will create and provide an integrated system of free software
> >   that anyone can use. We will make all our work publically available
> >   as free software.
> Given how literalistic some members of our community can be about
> interpreting Foundation Documents, the second sentence is a little
> worrying.  I can easily imagine a Free Software Fanatic using the
> second sentance as an argument that we must stop distributing the
> non-free section, since non-free is, by definition, not Free Software.

The non-free stuff in non-free isn't "our work" though -- it's stuff
other people have made that we redistribute. "our work" is things like
debbugs, dak, debhelper, *.diff.gz, etc.

Maybe some DDs write non-free software that gets packaged, but that
can at least be differentiated by "Joe Random " versus
using a d.o address.

> And it could easily be argued that the work that Debian Developers to
> package non-free packages, which is after all distributed on the
> Debian FTP servers and via Debian Mirrors, would fall under the scope
> of "All our work".

I think any packaging code, even for non-free stuff, should be DFSG-free.
That might require dual-licensing, but that's okay.

> I'm not sure what you were trying to state by the second sentence
> above; one approach might be to simply strike it from the draft.  Or
> were you trying to add the constraint that any work authored by DD's
> on behalf of the Debian Project should be made available under a free
> software license, even if in combination with other software being
> packaged, the result is non-free?

Pretty much, yeah.

> >2. We will build a superior operating system
> >   We will collect and distribute the best software available, and
> >   strive to continually improve it by making use of the best tools
> >   and techniques available.
> I'm worried about the first clause, because of the absolutist word
> "best" in "best software available".  Again, some literally minded
> DD's could view this as meaning that the best is the enemy of the
> good, and use this as bludgeon to say that since we have package X, we
> should not have packages Y or Z, because, X is the *best*.   

There's nothing there that says we won't also distribute the worst
software available, though. If you're worried about "the best" being
exclusionary, though, the same applies to tools/techniques. If bugzilla
is the best tool for bug tracking, we must immediately stop using
debbugs, eg. Ditto wiki software, list software, etc.

> I would certainly be willing to second and support such a proposal,
> should you decide that you are willing to make it as a formal proposal
> for a GR.

So that's one, but at least four more would be needed...

Here's a wiki page for people who think this is a reasonable or desirable
sort of thing to do: http://wiki.debian.org/SocialContractRevision . I've
only added my caveats, not ones that other people have already brought up.

Cheers,
aj



signature.asc
Description: Digital signature

Re: mass bug filing for undefined sn?printf use

[LI Daobing (李道兵)]

On Sun, Dec 28, 2008 at 4:53 PM, Adeodato Simó  wrote:
>> Attached is a list of affected packages,
>
> Piping through dd-list(1) gives:
>
> LI Daobing 
>   liblunar
forwarded to upstream, and he will fix it in next release.

>   openbabel (U)
left to debichem team.



-- 
Best Regards,
 LI Daobing


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Anthony Towns]

On Mon, Dec 29, 2008 at 10:10:24PM +0900, Osamu Aoki wrote:
> But the way you wrote in 4 as "we will make any private discussions
> publically available at the earliest opportunity." is problematic since
> it is 100% disclosure pledge. I suggest something along "we will make
> any private discussions publically available at the earliest opportunity
> to the extent appropriate for this objective."  I am using "this
> objective" as "to allow anyone to follow our discussions".   I hope
> someone can rephrase this better. 

IMO, discussion that leads to technical changes, is really part of the
source, much like in-code comments, READMEs, and version control logs. If
you've got access to the reasoning that led up to a decision, you can
have a much better understanding of what's going on, just as if you have
access to criticisms being made, and what people propose to do about them,
you've got a much better idea of what the code's capabilities are.

There's nothing wrong with having a closed discussion with some friends
about how to improve your packages, but it's much better if after the fact
you make that discussion available to everyone who might be interested.

The same thing applies to discussions about the direction of Debian --
when it might release, how decisions get made, what exciting new things
we might consider doing. These are important bits of information that
users, upstream, and developers of other distros should have access to.

That doesn't mean *every* private discussion DDs have -- "gosh, wasn't
the football exciting last night?" isn't very interesting to Debian, eg.
But equally, it's not especially on-topic for most Debian areas, either.
If there's a casual environment -- like debconf, or a pub, or an IRC
channel; there's no need for complete logs or video records for everyone
to be able to pore over, but summaries of the technical bits would be
a win.

> > Since it's worded as a pledge, it might make sense that if it (or
> > something like it) is ever adopted, that existing developers membership
> > being dependent on them agreeing to the pledge. That didn't happen with
> > the previous SC change, but it seems strange to claim to have a social
> > contract when a significant number of members don't actually support
> > it 100%.
> I am not sure about the last part.  If you said "when a significant
> number of members don't actually abide by it 100%.", I can agree.  As
> much as we are discussing SC change now, we should allow us to discuss
> changing it as long as we abide by the current SC during its valid term.
> I mean people with view to have stricter FREE requirement should not be
> forced to leave project via this "pledge process". 

I don't think the text I wrote puts any limits on how much you can support
free stuff; it only puts limits on how much you can ignore other people's
opinions and how poorly you can treat other people. If you only want to
license your work under the MIT license, and never the GPL because you think
that is too restrictive, eg, you can perfectly well make that pledge.

> To me, none of us made action which does not abide to the valid current
> SC.  We only overruled a part of SC when it conflicted with another one
> in SC via GR.  I.e. "100% free" vs. "user".

I'm not saying the project doesn't support the SC as it stands, just that
some DDs don't. That applies to both the "remain 100% free" claim ("it's
silly to do that now, because it wouldn't be a functioanl OS" or "we've
never been 100% free up 'til now, how can we `remain' that way?") or the
"we support [non-free works'] use and provide infrastructure for non-free
packages" ("but Debian will remain 100% free", "I certainly won't",
"non-free should be dropped").

It makes sense that day-to-day decisions that flow from the social
contract might result in disagreements (eg, "is the GFDL ever free?",
"should non-free be released as part of stable, or kept separately?",
"should packages in non-free ever delay packages in main getting released
into testing or stable?"), but when the social contract *itself* is the
cause of disagreement within the project, I find that troubling.

> Although I did not agree to the current SC vote, I have been abiding to
> the current SC. Thus we casted our vote for this GR for lenny.

Yeah, you can abide by a document you don't support, but if it's
possible to get a document that 95% of the project as it stands actually
*supports*, I think it makes sense to consider whether keeping the remaining
5% who have principled disagreements with some part or other is going to
be a good way of running the project.

My draft was written with the aim of being something that who simply
want complete (software) freedom above all else could readily agree with,
and sign their name to, as can people who don't much care about the politics
or philosophy of free software and just want to keep some non-free packages
well maintained. Maybe it doesn't succeed at that, I don't know.

> > Anyway, given t

Re: mass bug filing for undefined sn?printf use

[Thomas Viehmann]

Hi,

Kees Cook wrote:
> On Sun, Dec 28, 2008 at 03:10:37PM +0100, Thomas Viehmann wrote:
>> How about either matching stuff against the build logs or recompiling

> I didn't have the resources to do this, but it's be great if someone could.

If you have the means of recompiling, say with pbuilder, that should
give you logs to look at.

>> with a compiler that actually fails when asked to compile a file that
>> matches? That would seem to have potential for reducing the number of
>> false positives.
> 
> I'd really love that too -- I just don't know how to modify the compiler to
> do it.  :)

You could try to use a wrapper for the various gcc binaries that greps
through the *.c?? it is passed with your regexp, logging the matches and
then calling the real binary. But then maybe I just don't have a clue
how to do it better.
It'll still have false positives from the regexp itself, but you'll
exclude code that isn't used.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#510184: ITP: gtk-qt-engine-kde4 -- theme engine using Qt 4 for GTK+ 2.x

[Fathi Boudra]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Package name: liborigin2
Version: 20081216
Upstream Author: Alex Kargovsky 
URL: http://sourceforge.net/projects/liborigin
License: GPL
Description: library for reading OriginLab Origin 7.5 project files

liborigin2 is a library for reading the project files from the OriginLab 
Origin 7.5 plotting program. OriginLab Origin provides extensive scientific 
graphing and data analysis capabilities and includes several new tools that 
simplify common operations.

The archive contains already liborigin which I co-maintain. liborigin2 is a 
rewrite that support only OriginLab Origin 7.5 projects.

cheers,

Fathi




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org