Re: Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies

[Lucas Nussbaum]

On 22/10/08 at 20:38 -0500, Raphael Geissert wrote:
> Pierre Habouzit wrote:
> 
> > On mar, oct 21, 2008 at 11:57:48 +, Josselin Mouette wrote:
> >> Le mardi 21 octobre 2008 à 08:53 -0300, David Bremner a écrit :
> >> > So downgrading bugs to non-RC severity (with appropriate rationale)
> >> > does not count in the great cookie contest?
> >> 
> >> Of course it does count; added to the rules in the wiki page.
> > 
> > Does bribing lucas into not using grid5k anymore works too ? :)
> > 
> > 
> 
> If everything goes the way I want it to be, it won't be just lucas the one
> filing reports: I asked lucas if he could do the remove/purge test in lenny

I'll do that.

> and
> the full install/remove/purge test in etch (yeah, you know, there were some
> changes in etch since r0 that could make packages break).

That's not going to be easy.

Please choose randomly 100 packages that are in etch. Then run the test
you want to run using piuparts, and check that you don't find any FP.
Adapt piuparts if you find problems. Provide me with a (modified)
piuparts that does the test correctly, a list of (binary) packages in
etch that I should test, and an etch chroot (as a tarball) I can use to
test into.

IOW, please turn this from "please fix piuparts for me" to "please
provide computing power".
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

RC bugs in lenny, sorted by maintainer

[Lucas Nussbaum]

Hi,

Here is a list of RC bugs in lenny, sorted by maintainer. If you want to
reply to the list to comment on specific bugs, it's fine, but please Cc
the bug reports so the information you provide is also available on the
BTS.

The list can also be found on
http://udd.debian.net/cgi-bin/lenny_rc_ddlist.cgi (generated on the fly
from UDD).

[T] means "affects only testing", [TU] means "affects testing and
unstable".

<->
Steve McIntyre <[EMAIL PROTECTED]>
[TU] (U) debian-cd #497270 debian-cd: includes embedded copies of bootloa

Kurt Roeckx <[EMAIL PROTECTED]>
[TU] linux32 #502716 linux32: should be removed, it's replaced by uti

Adam Conrad <[EMAIL PROTECTED]>
[TU] poppassd #502830 poppassd: piuparts test fails: /var/lib/dpkg/in

Alexandre Fayolle <[EMAIL PROTECTED]>
[T]  (U) matplotlib #502134 matplotlib: undefined symbol: __gxx_personali
[T]  (U) matplotlib #503093 python-matplotlib: importing matplotlib fails

Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>
[TU] netkit-rusers #502822 rusersd: piuparts test fails: /var/lib/dpk
[TU] netkit-rwall #502828 rwalld: piuparts test fails: /var/lib/dpkg/

akira yamada <[EMAIL PROTECTED]>
[TU] ruby1.9 #478717 ruby1.9: FTBFS on hppa: make[1]: *** [all] Segme
[TU] ruby1.9 #491930 ruby1.9: needs a removal-transition on hppa

Alejandro Rios P. <[EMAIL PROTECTED]>
[T]  (U) destar #501207 destar doesn't start, backtrace shown

Ana Beatriz Guerrero Lopez <[EMAIL PROTECTED]>
[TU] (U) kdebase #500540 kdebase: automounting vfat (partialy) case sensi
[T]  (U) kdeedu #495770 marble has rpath to insecure location (/tmp/build
[TU] (U) kdelibs #502459 konqueror: Crash on eBay page

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
[T]  apmd #475432 apmd: stop depending on sysv-rc
[TU] portmap #424957 portmap includes non-DFSG-compliant code
[T]  (U) acpid #487815 acpid: dies on any given Sunday
[T]  (U) acpid #491058 acpid exits
[T]  (U) acpid #495686 acpid not starting after (re)boot

Adam Di Carlo <[EMAIL PROTECTED]>
[TU] (U) docbook-xml #482140 docbook-xml: Package does not install: updat
[TU] (U) docbook-xml #502781 docbook-xml: upgrading from etch to lenny - 

Arnaud Quette <[EMAIL PROTECTED]>
[TU] nut #502757 nut-cgi: piuparts test fails: chmod: cannot access `
[TU] (U) libhid #476525 python-hid: hid module will not import since pyth

Arthur Loiret <[EMAIL PROTECTED]>
[T]  (U) llvm #499469 llvm-examples: binNMU-unsafe dependency on llvm-dev
[TU] (U) wine #493169 libwine-jack: segfaults on start (connection attemp

Alexander Sack <[EMAIL PROTECTED]>
[TU] enigmail #468954 enigmail: icedove does not detect upgrade to co
[TU] enigmail #486491 enigmail: does not upgrade from etch to lenny i
[TU] enigmail #501973 enigmail: diff for NMU version 2:0.95.0+1-3.2
[TU] icedove #497491 icedove: Icedove inappropriately sets file-/MIME
[TU] icedove #500721 Thunderbird 2.0.0.17 available

Aurelien Jarno <[EMAIL PROTECTED]>
[T]  (U) glibc #494468 Postinst violates Debian policy (10.7.3) by not pr

Arnaud Vandyck <[EMAIL PROTECTED]>
[TU] (U) classpath #267040 remote code execution hole due to lack of Java
[TU] (U) classpath #301134 gcjwebplugin: no mention of non-active securit
[T]  (U) kaffe #467486 kaffe: Builds broken package with gcc-4.3

Barak A. Pearlmutter <[EMAIL PROTECTED]>
[T]  djvulibre #491123 djview: update-alternatives breaks apt-get

Ben Collins <[EMAIL PROTECTED]>
[T]  (U) glibc #494468 Postinst violates Debian policy (10.7.3) by not pr

Bdale Garbee <[EMAIL PROTECTED]>
[T]  p10cfgd #502832 p10cfgd: piuparts test fails: /var/lib/dpkg/info
[TU] (U) bind9 #496954 bind9: Fails to start due to SIGSEGV
[TU] (U) bind9 #501800 bind9: bind crashes with a list for allow-update

Barry deFreese <[EMAIL PROTECTED]>
[TU] (U) conquest #502740 conquest-server: piuparts test fails: mkdir: ca
[T]  (U) ketm #502765 ketm: piuparts test fails: touch: cannot touch `/va
[T]  (U) sabre #433996 unsecure usage of /tmp files

Brice Goglin <[EMAIL PROTECTED]>
[TU] (U) xorg-server #488669 kernel changes break X on sparc64/pci
[TU] (U) xorg-server #500358 mach64 stopped working on the Sun Ultra 5 gr

Michael Biebl <[EMAIL PROTECTED]>
[TU] (U) dbus #501443 dbus: CVE-2008-3834, possible DoS

Blars Blarson <[EMAIL PROTECTED]>
[TU] nntp #502829 nntp: piuparts test fails: /var/lib/dpkg/info/nntp.
[TU] nntp #502855 nntp: might not be distributable at all

A. Maitland Bottoms <[EMAIL PROTECTED]>
[T]  vtk #498053 fslview ftbfs on arm due to a segfault in libQVTKWid

Christian Perrier <[EMAIL PROTECTED]>
[T]  (U) localization-config #498095 localization-config: configures kde 

Bernd Zeimetz <[EMAIL PROTECTED]>
[T]  (U) zsi #502453 python-zsi: Depends on specific version of Python

Bastian Kleineidam <[EMAIL PROTECTED]>
[T]  libpam-mount #502146 libpam-mount: conffile conversion during up

Camm Maguire <[EMAIL PROTECTED]>
[TU] acl2 #494328 acl2: FTBFS in lenny: Initialization FAILED: acl

DFSG-violations and NEW and DFSG-violations and I would fix them, but...

[Thomas Viehmann]

Raphael Hertzog wrote:
> Every kernel upload changing the ABI goes through NEW.

The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware). Sure, the ftp team can make this into a stand-off,
but the situation is much less clear than e.g. when the ftp team had
openjdk-6 in NEW, which had its (known or discovered during the vetting)
DFSG problems fixed rather fast and before it entered the archive in
first place, thanks to the maintainer (Matthias) willing to get the bugs
fixed and thanks to a cooperative upstream.

So let's evaluate options other than rejecting:
As for the suggestions to move linux-2.6 to non-free (which, again,
would have required someone to upload that): The ftp team usually are
pretty ruthless about pulling stuff from main with problems if it
doesn't get fixed fast, but in the case of the kernel and glibc the
Social Contract's
  We will never make the system require the use of a non-free component.
puts a limit on what can be done: Aside from the additional work it
would cause to everyone (installer, ...) and the undesirable effect of
effectively forcing people to add non-free, moving stuff required for
running Debian into non-free seems shady from a Social Contract point of
view.
Note how the situation would be vastly different if we had a known-good
kernel package was somewhere in the archive (be it testing or unstable).

And about the options of fixing it or just insulting other people to fix
it I should note that the objection that finding a widely welcomed fix
involves work (on blob loaders) that someone interested in a free kernel
has no intrinsic motivation to do: A lot of tasks do that. I want a
release and when I ask the release team, they tell me to fix RC bugs in
stuff I personally don't care about one single bit. I don't get to yell
at the release team for that (though I do at the maintainers of RC buggy
packages possibly more than I should), but have the choice of working on
stuff or not. Claiming that "I want a release now and we could just
release, all the RC bugs are in packages I have no interest in" would be
openly preposterous and in the case of "I would work on freeing the
kernel of but finding something to make everyone happy involves making
the firmware loadable in non-free" thinly disguises the same sentiment
of "I'm not going to help unless it's 100% my way" in the disguise of a
taking a higher moral stance than everyone else. "Moral, das ist, wenn
man moralisch ist, versteht Er."

Kind regards

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


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

Check on DD

[W. van den Akker]

Hi,

I am trying to get in contact with the DD who maintains the Scid package.
From end of may until now he is non-responsive.
I want to take over the maintainership of Scid and some other packages
because there are new upstream versions available.
Can somebody of you DD check if the maintainer of Scid has been active or
is inactive.
Besides that I have a non-responsive mia (at) qa.debian.org. Posted 3 mails
but have no real answers back

Please advise

You may reply on my private email if needed.

gr,
Willem



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Check on DD

[W. van den Akker]

Hi,

I am trying to get in contact with the DD who maintains the Scid package.
From end of may until now he is non-responsive.
I want to take over the maintainership of Scid and some other packages because
there are new upstream versions available.

Can somebody of you DD check if the maintainer of Scid has been active or is 
inactive.
Besides that I have a non-responsive mia (at) qa.debian.org. Posted 3 mails 
but have no real answers back 

Please advise 

You may reply on my private email if needed.

gr,
Willem

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Re: Check on DD

[Paul Wise]

On Thu, Oct 23, 2008 at 3:42 PM, W. van den Akker <[EMAIL PROTECTED]> wrote:

> Can somebody of you DD check if the maintainer of Scid has been active or is
> inactive.

Last activity according to mia-query was October 2006.

> Besides that I have a non-responsive mia (at) qa.debian.org. Posted 3 mails
> but have no real answers back

It appears they marked him as inactive in response to your emails:

2008-10-21: inactive; {from [EMAIL PROTECTED]

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: RC bugs in lenny, sorted by maintainer

[Michael Meskes]

On Thu, Oct 23, 2008 at 09:26:43AM +0200, Lucas Nussbaum wrote:
> The list can also be found on
> http://udd.debian.net/cgi-bin/lenny_rc_ddlist.cgi (generated on the fly
> from UDD).
> 
> [T] means "affects only testing", [TU] means "affects testing and
> unstable".

Wouldn't it make sense to only send [TU] bugs as these are the bugs we have to
fix for the release? [T] normaly means fix just waiting for migration, isn't
it?

> ...
> Michael Meskes <[EMAIL PROTECTED]>
> [TU] watchdog #503080 watchdog.postinst: line 18: /sbin/MAKEDEV: No s
> [T]  (U) acpid #487815 acpid: dies on any given Sunday
> [T]  (U) acpid #491058 acpid exits
> [T]  (U) acpid #495686 acpid not starting after (re)boot

Using my bugs as an example. All four of them are fixed in unstable, so neither
needs work. Watchdog was reported and uploaded yesterday, so no surprise it's
still listed as [TU]. 

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

Re: Bug#502959: general: raff.debian.org uses non-free software

[Pierre Habouzit]

On Wed, Oct 22, 2008 at 10:53:46PM +, Norbert Preining wrote:
> On Mi, 22 Okt 2008, Josselin Mouette wrote:
> > > In the end, all these discussions showed that many people here don't
> > > give a piss for the users.
> > 
> > Many? I only see 2 or 3 of them around.
> 
> Ok, many *loud* voices ...
> 
> How many times did I see that binary firmware discussion in my few years
> as DD ...

Each time we release ?
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpleYuMepK6J.pgp
Description: PGP signature

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

[Luca Capello]

Hi there!

On Wed, 22 Oct 2008 15:28:08 +0200, Manoj Srivastava wrote:
> On Tue, Oct 21 2008, Henrique de Moraes Holschuh wrote:
>
>> On Tue, 21 Oct 2008, Manoj Srivastava wrote:
>>>  acceleration, right? So the box can be installed, and is usable for
>>>  non-gaming purposes. The drm stuff can possibly be gotten from non
>>
>> You can always use VESA, yes.  I don't think the X.org driver can get an ATI
>> GPU to work without the memory management *microcode* (but I didn't know that
>> thing was still non-free).
>
> That should be good enough to install, and then add non-free to
>  sources.list and get the firmware required for the driver to work
>  (absent a non-free debian installer that bundles non-free bits). This
>  is no different from what I have had to do already for my nvidia card
>  (degraded X support until I arranged to have non-free nvidia drivers
>  installed). I would think that was an acceptable solution.

+1.

Thx, bye,
Gismo / Luca


pgp74T5YinD2E.pgp
Description: PGP signature

Re: Check on DD

[Dmitry E. Oboukhov]

On 09:42 Thu 23 Oct , W. van den Akker wrote:
WvdA> Hi,

WvdA> I am trying to get in contact with the DD who maintains the Scid package.
WvdA> From end of may until now he is non-responsive.
WvdA> I want to take over the maintainership of Scid and some other packages 
because
WvdA> there are new upstream versions available.

WvdA> Can somebody of you DD check if the maintainer of Scid has been active or 
is
WvdA> inactive.
WvdA> Besides that I have a non-responsive mia (at) qa.debian.org. Posted 3 
mails
WvdA> but have no real answers back

WvdA> Please advise

WvdA> You may reply on my private email if needed.


send mail to [EMAIL PROTECTED] for orphan this package :)
--
... mpd is off

. ''`.   Dmitry E. Oboukhov
: :’  :   email: [EMAIL PROTECTED] jabber://[EMAIL PROTECTED]
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: Check on DD

[Paul Wise]

On Thu, Oct 23, 2008 at 5:46 PM, Dmitry E. Oboukhov <[EMAIL PROTECTED]> wrote:

> send mail to [EMAIL PROTECTED] for orphan this package :)

You must have misread the part of the email where it was mentioned
that [EMAIL PROTECTED] is itself MIA and doesn't reply.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#503185: ITP: chname -- Utility which runs a command with a new system hostname

[Mikhail Gusarov]

Package: wnpp
Severity: wishlist
Owner: Mikhail Gusarov <[EMAIL PROTECTED]>

* Package name: chname
  Version : 1.0
  Upstream Author : Michael Marineau
* URL : http://code.google.com/p/chname/
* License : GNU General Public License v2
  Programming Lang: C
  Description : Utility which runs a command with a new system hostname

Utility that runs a command with a new system hostname.

This requires Linux and utsname namespace support in 2.6.19 or later.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (750, 'testing'), (700, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)



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

Re: RC bugs in lenny, sorted by maintainer

[Lucas Nussbaum]

On 23/10/08 at 10:21 +0200, Michael Meskes wrote:
> On Thu, Oct 23, 2008 at 09:26:43AM +0200, Lucas Nussbaum wrote:
> > The list can also be found on
> > http://udd.debian.net/cgi-bin/lenny_rc_ddlist.cgi (generated on the fly
> > from UDD).
> > 
> > [T] means "affects only testing", [TU] means "affects testing and
> > unstable".
> 
> Wouldn't it make sense to only send [TU] bugs as these are the bugs we have to
> fix for the release? [T] normaly means fix just waiting for migration, isn't
> it?

No: in some cases, the maintainer forgot to send an unblock request to
-release@, or the fix was inappropriate, and the bug will have to be
fixed through a testing-proposed-updates upload.

The release team isn't proactively tracking those AFAIK, it's still the
maintainer's responsibility to take care of this.

> > Michael Meskes <[EMAIL PROTECTED]>
> > [TU] watchdog #503080 watchdog.postinst: line 18: /sbin/MAKEDEV: No s
> > [T]  (U) acpid #487815 acpid: dies on any given Sunday
> > [T]  (U) acpid #491058 acpid exits
> > [T]  (U) acpid #495686 acpid not starting after (re)boot
> 
> Using my bugs as an example. All four of them are fixed in unstable, so 
> neither
> needs work. Watchdog was reported and uploaded yesterday, so no surprise it's
> still listed as [TU]. 

... and watchdog also needs an unblock.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: RC bugs in lenny, sorted by maintainer

[Sandro Tosi]

On Thu, Oct 23, 2008 at 12:40, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
> No: in some cases, the maintainer forgot to send an unblock request to
> -release@, or the fix was inappropriate, and the bug will have to be
> fixed through a testing-proposed-updates upload.
>
> The release team isn't proactively tracking those AFAIK, it's still the
> maintainer's responsibility to take care of this.

Just to clarify, dato yesterday told me that what's in t-p-u it's
under the release team attention, and the usually take care of it.

Cheers,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Re: RC bugs in lenny, sorted by maintainer

[Ana Guerrero]

On Thu, Oct 23, 2008 at 09:26:43AM +0200, Lucas Nussbaum wrote:
> Hi,
> 
> Here is a list of RC bugs in lenny, sorted by maintainer. If you want to
> reply to the list to comment on specific bugs, it's fine, but please Cc
> the bug reports so the information you provide is also available on the
> BTS.
> 
> The list can also be found on
> http://udd.debian.net/cgi-bin/lenny_rc_ddlist.cgi (generated on the fly
> from UDD).
> 
> [T] means "affects only testing", [TU] means "affects testing and
> unstable".

> Ana Beatriz Guerrero Lopez <[EMAIL PROTECTED]>
> [T]  (U) kdeedu #495770 marble has rpath to insecure location (/tmp/build

This is wrong, I have nothing to do with marble in testing, where is made from
the source package marble, only with the experimental version where it is from
the source package kdeedu (KDE 4.1.2).


Ana


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

Re: RC bugs in lenny, sorted by maintainer

[Michael Meskes]

> > Wouldn't it make sense to only send [TU] bugs as these are the bugs we have 
> > to
> > fix for the release? [T] normaly means fix just waiting for migration, isn't
> > it?
> 
> No: in some cases, the maintainer forgot to send an unblock request to
> -release@, or the fix was inappropriate, and the bug will have to be
> fixed through a testing-proposed-updates upload.

Okay, makes sense.

> The release team isn't proactively tracking those AFAIK, it's still the
> maintainer's responsibility to take care of this.

Sure.

> > > Michael Meskes <[EMAIL PROTECTED]>
> > > [TU] watchdog #503080 watchdog.postinst: line 18: /sbin/MAKEDEV: No s
> > > [T]  (U) acpid #487815 acpid: dies on any given Sunday
> > > [T]  (U) acpid #491058 acpid exits
> > > [T]  (U) acpid #495686 acpid not starting after (re)boot
> > 
> > Using my bugs as an example. All four of them are fixed in unstable, so 
> > neither
> > needs work. Watchdog was reported and uploaded yesterday, so no surprise 
> > it's
> > still listed as [TU]. 
> 
> ... and watchdog also needs an unblock.

I know. Usually I wait some days to see whether other bugs come up from the new
upload before sending out that email.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


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

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

[Ben Hutchings]

On Wed, 2008-10-22 at 11:38 +0200, Bastian Blank wrote:
> On Wed, Oct 22, 2008 at 10:54:41AM +0200, Thomas Weber wrote:
> > Am Mittwoch, den 22.10.2008, 08:36 +0200 schrieb Bastian Blank:
> > > On Wed, Oct 22, 2008 at 08:07:52AM +0200, Michal Čihař wrote:
> > > > At least ipw2100 drivers changed firmware name if they required
> > > > different version, so I guess this is also used by others...
> > > If they need an incompatible one. Not necessarily if they just need a
> > > newer one.
> > I'm not really into hardware, but how often does kernel firmware change
> > in an incompatible way?
> 
> The iwl4965 firmware changed 2 times incompatible since the driver
> exists.

That makes me wonder just how separate the driver and firmware are.  If
they are tightly coupled then the firmware may become subject to the GPL
as well.

Ben.



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

Re: RC bugs in lenny, sorted by maintainer

[Lucas Nussbaum]

On 23/10/08 at 13:05 +0200, Ana Guerrero wrote:
> On Thu, Oct 23, 2008 at 09:26:43AM +0200, Lucas Nussbaum wrote:
> > Hi,
> > 
> > Here is a list of RC bugs in lenny, sorted by maintainer. If you want to
> > reply to the list to comment on specific bugs, it's fine, but please Cc
> > the bug reports so the information you provide is also available on the
> > BTS.
> > 
> > The list can also be found on
> > http://udd.debian.net/cgi-bin/lenny_rc_ddlist.cgi (generated on the fly
> > from UDD).
> > 
> > [T] means "affects only testing", [TU] means "affects testing and
> > unstable".
> 
> > Ana Beatriz Guerrero Lopez <[EMAIL PROTECTED]>
> > [T]  (U) kdeedu #495770 marble has rpath to insecure location (/tmp/build
> 
> This is wrong, I have nothing to do with marble in testing, where is made from
> the source package marble, only with the experimental version where it is from
> the source package kdeedu (KDE 4.1.2).

I know. The problem is that the BTS doesn't know that. Bugs are filed
against binary packages (most of the time), and I think that the BTS
uses the last upload to determine to which source package a binary
package belongs to.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


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

Re: RC bugs in lenny, sorted by maintainer

[Matthew Johnson]

On Thu Oct 23 12:53, Sandro Tosi wrote:
> On Thu, Oct 23, 2008 at 12:40, Lucas Nussbaum <[EMAIL PROTECTED]> wrote:
> > No: in some cases, the maintainer forgot to send an unblock request to
> > -release@, or the fix was inappropriate, and the bug will have to be
> > fixed through a testing-proposed-updates upload.
> >
> > The release team isn't proactively tracking those AFAIK, it's still the
> > maintainer's responsibility to take care of this.
> 
> Just to clarify, dato yesterday told me that what's in t-p-u it's
> under the release team attention, and the usually take care of it.

Yes, but the maintainer has to make the upload to t-p-u (or send the
unblock etc)

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Include justification in tagging bugs ‘$FOO -ignore’

[Ben Finney]

Filipus Klutiero <[EMAIL PROTECTED]> writes:

> > In other words, if a tag indicates a special case, that special case
> > should be justified with a specific explanation.
> >
> > I would like to see such justification expected for every such tag,
> > enforced by the convention that tags with *no* justification provided
> > can be summarily removed by anyone. This would place the burden of
> > argument in the correct place, as I see it, while not needing anything
> > as heavy-handed as a policy requirement.
> >
> > Is that feasible? Is it reasonable?
> >   
> Anyone can certainly remove the tag, but I don't think it's a good
> idea that such a tag be removed without the release team's approval.

Notice that I only advocate removing the tag when it's not accompanied
by a clear, explicit justification.

> I see these tags as being for the release team's use

I disagree; the ‘foo-ignore’ bug tags have an explicit mechanical
effect on how the corresponding package will be treated by the tools.

> hence the team should determine by itself whether these tags should
> be applied.

All I propose is that the ‘foo-ignore’ tags by themselves communicate
nothing to the (human) reader about why this particular bug is
special-cased, and that without an explicit justification accompanying
the tag it should be removed by anyone who finds it in that state.

> Maybe the tags should also be moved from the main namespace to the
> release team's "usertags".

If these ‘foo-ignore’ tags were *only* usertags, with no mechanical
effect on any release tools, I would have no quarrel. My proposal is
based on the important effect these tags have upon the release, and
that justification should be expected in each instance of their use.

-- 
 \ “Ours is a world where people don't know what they want and are |
  `\   willing to go through hell to get it.” —Donald Robert Perry |
_o__)  Marquis |
Ben Finney


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

Inactive MIA team

[Mohammed Adnène Trojette]

On Thu, Oct 23, 2008, Paul Wise wrote:
> You must have misread the part of the email where it was mentioned
> that [EMAIL PROTECTED] is itself MIA and doesn't reply.

MIA currently does reply but does not necessarily follows up with action
(more than adding hints in the MIA database).

However, I can confirm that MIA is currently lacking man power.

I can't go and orphan someone's packages without doing the effort of
contacting him myself. And I am a bit busy to do it currently.

Feel free to jump in: there is a great README on merkel and you'll find
advice on #debian-qa.

-- 
Mohammed Adnène Trojette


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

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

[Robert Millan]

On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote:
> On Tuesday 21 October 2008, you wrote:
> > But, in fact, fixes are not welcome from the team.  They have raised a
> > major roadblock, allowing only one kind of fix which requires a lot of
> > work, and rejecting anything simpler.
> 
> Ever hear of the Technical Committee?

The Technical Committee is not empowered to override foundation documents.

-- 
Robert Millan

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


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

Re: RC bugs in lenny, sorted by maintainer

[Adeodato Simó]

* Lucas Nussbaum [Thu, 23 Oct 2008 12:40:03 +0200]:

> The release team isn't proactively tracking those AFAIK

Except that we... are.

Thank you very much.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The pure and simple truth is rarely pure and never simple.
-- Oscar Wilde


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

Re: [DRAFT] resolving DFSG violations

[Robert Millan]

On Thu, Oct 23, 2008 at 08:36:24AM +0200, Raphael Hertzog wrote:
> 
> Every kernel upload changing the ABI goes through NEW.
> 
> Your lack of knowledge of Debian processes sucks (that means: you
> annoy us (at least me) with your stance and the fanatic way you defend it
> in public, please stop this and come back to more constructive
> discussions).

And I take it that Thomas is supposed to take your attitude as an example
on how being constructive?

-- 
Robert Millan

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


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

Re: Bug#503096: ITP: alpaca -- GnuPG file handling for Emacs

[Tatsuya Kinoshita]

Hi Luca, thanks for the comment.

On October 22, 2008 at 7:18PM +0200,
luca (at pca.it) wrote:

> > * Package name: alpaca
> [...]
> > * URL : http://www.mew.org/~kazu/proj/cipher/
>
> I think that a package for one single file is too much.

Even so, the Debian package is helpful for users to install,
upgrade and use it.

> >   Description : GnuPG file handling for Emacs
> >  `alpaca' is an Emacs Lisp package to edit GnuPG files encrypted with
> >  shared-key cryptography on GNU Emacs.
> >  .
> >  If this package is installed, when handling of a file whose suffix
> >  is ".gpg", this package asks your passphrase and then the file is
> >  automatically decrypted/encrypted.
>
> What are the advantages of alpaca over EasyPG [1]?  FWIW with EasyPG you
> get the same behavior when you handle a .gpg file and I was thinking
> that (finally) EasyPG was the Emacs choice for everything GPG related.

`alpaca' is an old and simple way.

The old version of alpaca (named gpg.el) was released in 2003 and
has been useful ever since.  EasyPG, "yet another GnuPG interface
for Emacs", version 0.0.1 was released in 2006, and then merged the
development version of Emacs (will be 23.1 release) in 2008.

`alpaca' just provides a hook function for *.gpg file handling.
Meanwhile EasyPG is a powerful tool which also provides keyring
browser, dired integration, mail functions and so on.  So, the
source code of alpaca is more small and simple.

If you always use symmetric (shared-key) encryption for *.gpg
files, alpaca is fit for you.  Because alpaca always use symmetric
encryption, while EasyPG asks user to select recipients and then
symmetric encryption is used if no one is selected.

Anyway, I'll add more information to the package description and
README.Debian.  Also, I'll consider the conflict of EasyPG.  The
alpaca feature should not be enabled when EasyPG's epa-file feature
is enabled.

Thanks,
--
Tatsuya Kinoshita


pgpNfMjqTIU8E.pgp
Description: PGP signature

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

[Neil McGovern]

On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote:
> On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote:
> > On Tuesday 21 October 2008, you wrote:
> > > But, in fact, fixes are not welcome from the team.  They have raised a
> > > major roadblock, allowing only one kind of fix which requires a lot of
> > > work, and rejecting anything simpler.
> > 
> > Ever hear of the Technical Committee?
> 
> The Technical Committee is not empowered to override foundation documents.
> 

6.1.4 of the constitution should help you in this case.

Neil
-- 
int getRandomNumber() {
return 4; // chosen by fair dice roll. guaranteed to be random.
}
// http://xkcd.com/c221.html


signature.asc
Description: Digital signature

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

[Robert Millan]

On Thu, Oct 23, 2008 at 05:41:05PM +0100, Neil McGovern wrote:
> On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote:
> > On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote:
> > > On Tuesday 21 October 2008, you wrote:
> > > > But, in fact, fixes are not welcome from the team.  They have raised a
> > > > major roadblock, allowing only one kind of fix which requires a lot of
> > > > work, and rejecting anything simpler.
> > > 
> > > Ever hear of the Technical Committee?
> > 
> > The Technical Committee is not empowered to override foundation documents.
> > 
> 
> 6.1.4 of the constitution should help you in this case.

I don't see how does 6.1.4 enable the TC to override foundation documents.
Did I miss something?

-- 
Robert Millan

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


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

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

[Neil McGovern]

On Thu, Oct 23, 2008 at 07:06:14PM +0200, Robert Millan wrote:
> On Thu, Oct 23, 2008 at 05:41:05PM +0100, Neil McGovern wrote:
> > On Thu, Oct 23, 2008 at 03:51:22PM +0200, Robert Millan wrote:
> > > On Tue, Oct 21, 2008 at 11:23:50PM +0200, Frans Pop wrote:
> > > > On Tuesday 21 October 2008, you wrote:
> > > > > But, in fact, fixes are not welcome from the team.  They have raised a
> > > > > major roadblock, allowing only one kind of fix which requires a lot of
> > > > > work, and rejecting anything simpler.
> > > > 
> > > > Ever hear of the Technical Committee?
> > > 
> > > The Technical Committee is not empowered to override foundation documents.
> > > 
> > 
> > 6.1.4 of the constitution should help you in this case.
> 
> I don't see how does 6.1.4 enable the TC to override foundation documents.
> Did I miss something?
> 

The need for the TC to override a foundation document. If you have what
you believe to be a fix that's not welcome from the team, and they want
a different one, the TC could use 6.1.4 to rule in your favour (or more
precisely, against the team that your course of action should be
taken).

Perhaps I'm mis-reading the above. Which bit of the foundation documents
do you think would need overriding for the tech-ctte to rule on which
fix to take?

Thanks,
Neil
-- 
 I use three different operating systems: Sarge, Etch, and Sid.


signature.asc
Description: Digital signature

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

[Thilo Six]

Luca Capello wrote the following on 23.10.2008 10:53

<- *snip* ->

>> That should be good enough to install, and then add non-free to
>>  sources.list and get the firmware required for the driver to work
>>  (absent a non-free debian installer that bundles non-free bits). This
>>  is no different from what I have had to do already for my nvidia card
>>  (degraded X support until I arranged to have non-free nvidia drivers
>>  installed). I would think that was an acceptable solution.
> 
> +1.
> 
> Thx, bye,
> Gismo / Luca

What does that mean?

Is it:
one more *pseudo-freeness-preacher* that is OK with delaying the lenny
release *to remove a handful bytes which makes hardware work at all* but then
finds it absolutely perfect to install a several *megabytes of CLOSED driver*
just to increase performance on an already working device??

Really i can't take you seriously

-- 
bye Thilo

key: 0x4A411E09


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

Re: [DRAFT] resolving DFSG violations

[Manoj Srivastava]

On Wed, Oct 22 2008, Pierre Habouzit wrote:


> At some point, someone has to decide. Doing a vote for each is
> impractical. As our choice is _not_ silent, if someones (like usually
> the reporter who _sees_ such tags happen) disagree, he can raise a
> discussion. AFAICT it's what is happening currently, and it shows that
> the system is sane and works. At some point if we want to scale, we have
> to delegate, and it's just that.

Look, I am not proposing we have a GR for every upload. I am
 saying that non-free bits in main are a bug. A serious bug. A RC
 bug. It is a big fucking deal. It comes to the core of what Debian is.

Now, we know there are unknon bugs and known bugs in the
 archive, especially in Sid. Shit happens.  Bugs take time to fix. But
 releasing with DFSG violations should still be a big deal. It is not
 something that some delegate decides is OK to do. The project tands up,
 acknowledges we failed out users by not providing them a free operating
 system like we promised in the social contract, acknowledge that the
 SC is still what we would like to do, but we failed this time around,
 and, as a project, take responsibility for our failure.

This is what we have done in the past, through GR's for Sarge
 and Etch. We should not become Blase about shipping non-free operating
 systems. It should not become common place.

manoj
-- 
Ditat Deus. [God enriches]
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: [DRAFT] resolving DFSG violations

[Manoj Srivastava]

On Thu, Oct 23 2008, martin f krafft wrote:

> It's all a matter of defining what your priorities are, which brings
> us back to the Social Contract, which says that these include:
>
>   - 100% freeness
>   - cater best to the interests of our users

Frankly, this mindset infuriates me. It frames the discussion
 incorrectly, it implies that freeness and user interest are at
 odds. Logically, it aargues that Windows is the best for users, since
 it caters to newbies, and is not free-  and since the implication is
 that freedom can be taken too far, allowing the users freedom to see
 movies legally, to use MS office and photoshop legally might triump the
 new fangled linux thingy.

No. Freedom is in the long term best interests of the users. We
 allow people to use non-free stuff, yes -- but we do so not by
 tainting main, but by putting these tools to help the unfortunate
 folks who cannot take advantage of a free operating system.
 

The same goes for people who are complaining oabout advocates
 of the social contract and libre software, calling them folks who do
 not care for users. I contend that people who stuff main with non-free
 stuff _are_ the ones acting against the interests of the suers in the
 long term, since freedom is the gift that Debian started out trying to
 give users.

Why is not putting non-free firmware in non-free not the right
 thing to do? Why is trying to create a 100% free distribution, as our SC
 states, supposed ot be the dark side? I hope the few loud voices acting
 against the interests of the users by trying to prevent Debian from
 providing them a free operating system are indeed few.

manoj
-- 
The beauty of a pun is in the "Oy!" of the beholder.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

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

[Thomas Bushnell BSG]

On Thu, 2008-10-23 at 18:13 +0100, Neil McGovern wrote:
> Perhaps I'm mis-reading the above. Which bit of the foundation documents
> do you think would need overriding for the tech-ctte to rule on which
> fix to take?

One might think that this is the situation: two alternative fixes for
the DFSG problem, and a dispute about which one is better.  But
actually, that's not the situation.

We have instead an easy trivial fix, all but complete.  (Really, just
disabling the hardware, or the accelerations, depending on the case.)
And maintainers saying that this is an unacceptable fix--and no actual
alternative fix sitting around.

I think everyone would regard the fix preferred by the maintainers as
superior--there is no technical dispute.  The dispute is *not* between
the two fixes.  It is between these two approaches:

1) Install easy fix now; install fancy fix when it's ready, thus
complying with the DFSG at all times;

2) Install no fix now; install fancy fix when it's ready, thus violating
the DFSG in the meanwhile.

This is not a dispute about technical means or which is the best
solution to a technical problem; it is a dispute about whether we are
actually supposed to be doing our best to comply with the DFSG at all
times.

Thomas



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

Re: [DRAFT] resolving DFSG violations

[Ean Schuessler]

- "Manoj Srivastava" <[EMAIL PROTECTED]> wrote:

> On Thu, Oct 23 2008, martin f krafft wrote:
> 
> > It's all a matter of defining what your priorities are, which brings
> > us back to the Social Contract, which says that these include:
> >
> >   - 100% freeness
> >   - cater best to the interests of our users
> 
> Frankly, this mindset infuriates me. It frames the discussion
>  incorrectly, it implies that freeness and user interest are at
>  odds. Logically, it aargues that Windows is the best for users, since
>  it caters to newbies, and is not free-  and since the implication is
>  that freedom can be taken too far, allowing the users freedom to see
>  movies legally, to use MS office and photoshop legally might triump the
>  new fangled linux thingy.

Its a lot like exercise. Its not convenient and its not easy but in the long 
run its a good idea.

I think the loud voices you are talking about are the same kind of loud, 
short-term gain voices that have caused so much trouble for the American 
economy. The point is that what is "best for the user" and what is "convenient 
or easy for the user" may not be the same thing. It is convenient and easy to 
eat fast food every day but it will make you fat and unhealthy.

So it is the same way with your computer. It is easy and convenient to give up 
freedom and control so you can watch a movie and play a cool 3D game, but you 
end up with your data trapped in an infrastructure controlled by the interests 
of others.

Now, breaking the law to keep control... I don't know how we advocate that. 
That's a harder question. Without law the whole notion of copyright is farcical 
and the DFSG becomes largely meaningless unless we are looking to some kind of 
"higher law". Not clear how that works.

-- 
Debian, choice of a GNU generation.


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

Re: Re: Include justification in tagging bugs ‘$FOO-ignore’

[Filipus Klutiero]

Filipus Klutiero <[EMAIL PROTECTED]> writes:

> > In other words, if a tag indicates a special case, that special case
> > should be justified with a specific explanation.
> >
> > I would like to see such justification expected for every such tag,
> > enforced by the convention that tags with *no* justification provided
> > can be summarily removed by anyone. This would place the burden of
> > argument in the correct place, as I see it, while not needing anything
> > as heavy-handed as a policy requirement.
> >
> > Is that feasible? Is it reasonable?
> >   
> Anyone can certainly remove the tag, but I don't think it's a good

> idea that such a tag be removed without the release team's approval.

Notice that I only advocate removing the tag when it's not accompanied
by a clear, explicit justification.
  
I'm advancing something wider than this, but it also covers the case you 
brought up.

> I see these tags as being for the release team's use

I disagree; the ‘foo-ignore’ bug tags have an explicit mechanical
effect on how the corresponding package will be treated by the tools.
  
Which tools? I can think of britney, which is already under the release 
team's control anyway.

> hence the team should determine by itself whether these tags should
> be applied.

All I propose is that the ‘foo-ignore’ tags by themselves communicate
nothing to the (human) reader about why this particular bug is
special-cased, and that without an explicit justification accompanying
the tag it should be removed by anyone who finds it in that state.
Yes...and all I was saying is that I don't think your proposal is a good 
idea.



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

Re: [DRAFT] resolving DFSG violations

[Thilo Six]

Manoj Srivastava wrote the following on 23.10.2008 19:06


<- *snip* ->


> Look, I am not proposing we have a GR for every upload. I am
>  saying that non-free bits in main are a bug. A serious bug. A RC
>  bug. It is a big fucking deal. It comes to the core of what Debian is.
> 
> Now, we know there are unknon bugs and known bugs in the
>  archive, especially in Sid. Shit happens.  Bugs take time to fix. But
>  releasing with DFSG violations should still be a big deal. It is not
>  something that some delegate decides is OK to do. 

manoj
 who has not yet switched to the free drivers for nvidia cards yet


<- *snip* ->



-- 
bye Thilo

key: 0x4A411E09


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

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

[Vincent Danjean]

Ben Hutchings wrote:
> On Wed, 2008-10-22 at 11:38 +0200, Bastian Blank wrote:
>> The iwl4965 firmware changed 2 times incompatible since the driver
>> exists.
> 
> That makes me wonder just how separate the driver and firmware are.  If
> they are tightly coupled then the firmware may become subject to the GPL
> as well.

Firmware and driver do not run on the same CPU. There is no 'linkage'
between them. With a client/server application, a GPL client does not
enforce the server to be GPL, even if client and server are tightly
coupled.

  Vincent


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

Re: Bug Sprint - Oct 25 to Oct 30 - Register and eat cookies

[Raphael Geissert]

Lucas Nussbaum wrote:

> On 22/10/08 at 20:38 -0500, Raphael Geissert wrote:
>> 
>> If everything goes the way I want it to be, it won't be just lucas the one
>> filing reports: I asked lucas if he could do the remove/purge test in lenny
> 
> I'll do that.

Thanks :)

> 
>> and
>> the full install/remove/purge test in etch (yeah, you know, there were some
>> changes in etch since r0 that could make packages break).
> 
> That's not going to be easy.
> 
> Please choose randomly 100 packages that are in etch. Then run the test
> you want to run using piuparts, and check that you don't find any FP.
> Adapt piuparts if you find problems. Provide me with a (modified)
> piuparts that does the test correctly, a list of (binary) packages in
> etch that I should test, and an etch chroot (as a tarball) I can use to
> test into.
> 
> IOW, please turn this from "please fix piuparts for me" to "please
> provide computing power".

Hmm, I wouldn't expect piuparts causing more FPs in etch than in lenny or sid;
though I'll check some packages just make sure.

Cheers,
Raphael Geissert



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

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

[Thomas Bushnell BSG]

On Thu, 2008-10-23 at 21:13 +0200, Vincent Danjean wrote:
> Ben Hutchings wrote:
> > On Wed, 2008-10-22 at 11:38 +0200, Bastian Blank wrote:
> >> The iwl4965 firmware changed 2 times incompatible since the driver
> >> exists.
> > 
> > That makes me wonder just how separate the driver and firmware are.  If
> > they are tightly coupled then the firmware may become subject to the GPL
> > as well.
> 
> Firmware and driver do not run on the same CPU. There is no 'linkage'
> between them. With a client/server application, a GPL client does not
> enforce the server to be GPL, even if client and server are tightly
> coupled.

That is not true.  It simply depends on whether they are one program or
not, which is a human-level concept, and not a technical one.  There is
no "magic boundary" at which the GPL would neve cross.

For example, if you were to split GCC into two executables, one which
parsed and generated intermediate code, and another which did
optimization and codegen, the result would still be the one GCC, covered
by the GPL.  And this is true even if you then write your own version of
the first part, implementing your seekrit proprietary language: the GPL
on the back end would require that the *whole program* be distributed
under the GPL, any separation into different executables
notwithstanding.

There is nothing in the GPL about "running on the same CPU" or
"client/server" exceptions.  If you use GPLd code, then the *whole
program* (whatever that is, it is a human-level concept requiring
understanding and not rote following of rigid rules) must be
distributable under terms no more restrictive than the GPL itself.

Thomas



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

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

[Lennart Sorensen]

On Tue, Oct 21, 2008 at 04:50:23PM -0500, William Pitcock wrote:
> In the kernel itself, yes. Provided that:
> 
>   * the kernel framework for loading firmware is used for drivers
> depending on non-free firmware, and
>   * that firmware is available in non-free via firmware-nonfree

What if the firmware has a license on it that doesn't permit
redistribution in non-free?  Then what?

> Infact, once I have time, I intend to start pushing patches upstream to
> make this happen.
> 
> But this is going to take another kernel release cycle... if we intend
> to release Lenny with 2.6.26, than this is not an option.

Well, if 2.6.27 in fact fixes a large amount of the firmware problem,
and happens to be a long term support kernel which is going to be used
by many distributions, then perhaps releasing Lenny with 2.6.26 is the
wrong choice and should be reconsidered.

> For hardware where this is an unacceptable solution, rewriting the
> driver to not use the firmware may still be possible.

Sometimes.  Certainly some hardware doesn't do anything without its
firmware.  Perhaps alternate firmware could be written, although often
there isn't any documentation around to do that.

-- 
Len Sorensen


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

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

[Ansgar Burchardt]

Thomas Bushnell BSG wrote:
> On Thu, 2008-10-23 at 21:13 +0200, Vincent Danjean wrote:
> > Firmware and driver do not run on the same CPU. There is no 'linkage'
> > between them. With a client/server application, a GPL client does not
> > enforce the server to be GPL, even if client and server are tightly
> > coupled.
> 
> That is not true.  It simply depends on whether they are one program or
> not, which is a human-level concept, and not a technical one.  There is
> no "magic boundary" at which the GPL would neve cross.
> 
> For example, if you were to split GCC into two executables, one which
> parsed and generated intermediate code, and another which did
> optimization and codegen, the result would still be the one GCC, covered
> by the GPL.  And this is true even if you then write your own version of
> the first part, implementing your seekrit proprietary language: the GPL
> on the back end would require that the *whole program* be distributed
> under the GPL, any separation into different executables
> notwithstanding.

The FSF seems to disagree on this[1]:

Can I release a non-free program that's designed to load a GPL-covered
plug-in?

It depends on how the program invokes its plug-ins. For instance, if
the program uses only simple fork and exec to invoke and communicate
with plug-ins, then the plug-ins are separate programs, so the
license of the plug-in makes no requirements about the main program.

The general idea seems to be that (at least the FSF) only linked modules
are considered as a "single program" and only in this case all parts
have to be GPL-compatible (not necessarily released under the GPL
itself).

Note that the GPL defines a covered work as "the unmodified Program or a
work based on the Program".  In my opinion this does *not* include a
program just calling the GPL-covered software (but then I'm neither a
lawyer nor particularly familiar with legal English).

Trying to extend this to separate executables would open a can of worms:
For example, is an IDE that includes the GCC compiler a "single work"
and must thus be released under the GPL?

Regards,
Ansgar

[1] http://www.gnu.org/licenses/gpl-faq.html#NFUseGPLPlugins

-- 
PGP: 1024D/595FAD19  739E 2D09 0969 BEA9 9797  B055 DDB0 2FF7 595F AD19


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

RC bug for >10 packages

[Francis Tyers]

Hi,

I'd like to open an RC bug for the following packages, following [1] I
am asking the list.

apertium-en-ca
apertium-en-es
apertium-eo-ca
apertium-eo-es
apertium-es-ca
apertium-es-gl
apertium-es-pt
apertium-es-ro
apertium-fr-ca
apertium-fr-es
apertium-oc-ca
apertium-pt-gl
apertium-oc-es

There are no dependent maintainers according to "whodepends" and I am
the only maintainer for these packages.

The bug is that the language packages require a specific version of
libpcre to function. It has worked up until now with various versions,
but moving from 7.4 to 7.6 breaks the packages with:

  Error: Unknown error matching regexp (code -16)

The fix will be to set a Depend in the apertium package to a particular
version of libpcre3, then set a Depend in the language packages to that
particular version of apertium, then recompile and upload the packages.

Please advise if I should go ahead.

Thanks,

Fran

1.
http://www.debian.org/doc/developers-reference/beyond-pkging.html#submit-many-bugs



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

Bug#503241: ITP: bti -- command line micro-blogging tool

[gregor herrmann]

Package: wnpp
Severity: wishlist
Owner: gregor herrmann <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: bti
  Version : 006
  Upstream Author : Greg Kroah-Hartman <[EMAIL PROTECTED]>
* URL : http://www.kernel.org/pub/linux/kernel/people/gregkh/bti/
* License : GPL-2
  Programming Lang: C
  Description : command line micro-blogging tool

 bti sends a tweet message to twitter.com or identi.ca.
 .
 bti provides an easy way to send tweet messages direct from the command line
 or any script. It reads the message on standard input and uses the account
 and password settings either from the command line options, or from a config
 file, to send the message out.


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

iEYEARECAAYFAkkA8BEACgkQOzKYnQDzz+RXiACfQLaBEFCOBqf+FgldFV/8N8AU
BgoAnAkUjXlTvSsy0xa7ZqulXpVNS/9R
=YQZw
-END PGP SIGNATURE-

-- 
 .''`.   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: Supertramp: Lord Is It Mine



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

Re: RC bug for >10 packages

[Adeodato Simó]

* Francis Tyers [Thu, 23 Oct 2008 22:47:20 +0200]:

> Hi,

Hello, Francis.

> The bug is that the language packages require a specific version of
> libpcre to function.

Could you explain a bit the technical background for this? Do the data
files in the language packages embed any data that is pcre-related, and
that makes that later on apertium can't open them if it uses an
incompatible version of pcre?

I'm asking because knowing the details is going to be better in order
for people to be able

> It has worked up until now with various versions, but moving from 7.4
> to 7.6 breaks the packages with:

>   Error: Unknown error matching regexp (code -16)

With respect the above, it would be good to find out if pcre is making
any promises of keeping compatibility when opening files that contain
data generated by it (or whatever apertium is doing), and then this is a
bug, or it doesn't, and then the problem does indeed need addressing.

> The fix will be to set a Depend in the apertium package to a particular
> version of libpcre3,

Note that binary packages get their dependencies via the shlibs
mechanism, and not hard-coded...

> then set a Depend in the language packages to that
> particular version of apertium, then recompile and upload the packages.

The option that sounds more realistic, at least for now, is having the
language packages Depend: libpcre3 (<< next_upstream_version), or
something along the lines.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
  Listening to: Andrés Calamaro - Paloma


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

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

[Thomas Bushnell BSG]

On Thu, 2008-10-23 at 22:08 +0200, Ansgar Burchardt wrote:
> 
> The FSF seems to disagree on this[1]:
> 
> Can I release a non-free program that's designed to load a GPL-covered
> plug-in?
> 
> It depends on how the program invokes its plug-ins. For instance, if
> the program uses only simple fork and exec to invoke and communicate
> with plug-ins, then the plug-ins are separate programs, so the
> license of the plug-in makes no requirements about the main program.
> 
> The general idea seems to be that (at least the FSF) only linked modules
> are considered as a "single program" and only in this case all parts
> have to be GPL-compatible (not necessarily released under the GPL
> itself).

This is (or when the text was originally written), about programs *as
released by the FSF*, but not about the GPL in general.  It may be that
the older text is now getting used in a broader context.  I do not know
if this represents a change in the FSF's position.

Thomas



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

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

[Ben Hutchings]

On Thu, 2008-10-23 at 15:51 -0400, Lennart Sorensen wrote:
> On Tue, Oct 21, 2008 at 04:50:23PM -0500, William Pitcock wrote:
> > In the kernel itself, yes. Provided that:
> > 
> >   * the kernel framework for loading firmware is used for drivers
> > depending on non-free firmware, and
> >   * that firmware is available in non-free via firmware-nonfree
> 
> What if the firmware has a license on it that doesn't permit
> redistribution in non-free?  Then what?

Then we must not distribute it.  However, it appears that in most cases
where the licence for firmware does not permit redistribution (e.g.
GPLv2, where we cannot satisfy clause 3) this is a mistake and the
copyright holder did intend to allow redistribution.

[...]
> > For hardware where this is an unacceptable solution, rewriting the
> > driver to not use the firmware may still be possible.
> 
> Sometimes.  Certainly some hardware doesn't do anything without its
> firmware.  Perhaps alternate firmware could be written, although often
> there isn't any documentation around to do that.

In many cases firmware runs on an embedded microcontroller which
implements a well-known architecture (e.g. 8051 or MIPS), which provides
a starting point for reverse-engineering the code.  Working out the
programming model could be a long job though, depending on just how much
functionality is dependent on the firmware.

Ben.



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

web site

[Lily Zey]

Dear:Debian-devel

We can see you have a good site but you could use a significant increase in 
targeted web traffic.  We
can review your site for free and show you how you can improve this portion of 
your online business
right away.  Email us now at [EMAIL PROTECTED] and include your web site and 
how we can reach you.

Sincerely,
Lily Zey



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

web site

[Lily Zey]

Dear:Debian-devel

If you're wondering why you're online business is not doing as well as you 
would like - the answer is
web traffic.  Basically - you need a lot more visibility.  Email us today at 
[EMAIL PROTECTED]  We will
take a look at your site and give you an assessment free of charge.  It doesn't 
have to cost a fortune to
make business happen online.  Be sure to include all of your URL(s) and how you 
prefer we contact
you.

Sincerely,
Lily Zey



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

Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...

[Steve Langasek]

On Thu, Oct 23, 2008 at 09:44:33AM +0200, Thomas Viehmann wrote:
> Raphael Hertzog wrote:
> > Every kernel upload changing the ABI goes through NEW.

> The typical situation here is that code that has the same set of DFSG
> bugs is already in place and so it is questionable of what a reject
> really achieves (i.e. does the archive become more DFSG-compliant or
> not) and quite typically fixes some RC bugs (not always trashing
> people's hardware).

This does not seem to be a position universally held by the ftp team, given
that a library I uploaded to binary NEW ths summer for a
release-team-approved transition was rejected over a source-only issue of
not mentioning in debian/copyright a pre-existing user guide not shipped in
any of the binary packages.  Or is it only kernel DFSG-compliance bugs that
get ignored in binary NEW, while all the other nitpicky checks are grounds
for a package reject?

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


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

Work-needing packages report for Oct 24, 2008

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 435 (new: 1)
Total number of packages offered up for adoption: 124 (new: 0)
Total number of packages requested help for: 49 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   libapache2-mod-auth-shadow (#503184), orphaned today
 Description: Apache2 module for authentication using shadow

434 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 124 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   apache2 (#470795), requested 224 days ago
 Description: Co-maintainer wanted
 Reverse Depends: achims-guestbook ampache apache2 apache2-dbg
   apache2-mpm-event apache2-mpm-itk apache2-mpm-prefork
   apache2-mpm-worker apache2-prefork-dev apache2-suexec (154 more
   omitted)
 Installations reported by Popcon: 40047

   ara (#450876), requested 347 days ago
 Description: utility for searching the Debian package database
 Installations reported by Popcon: 116

   athcool (#278442), requested 1458 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 231

   bash-completion (#472468), requested 213 days ago
 Description: programmable completion for the bash shell
 Installations reported by Popcon: 17723

   cvs (#354176), requested 973 days ago
 Description: Concurrent Versions System
 Reverse Depends: crossvc cvs-autoreleasedeb cvs-buildpackage cvs2cl
   cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (12 more
   omitted)
 Installations reported by Popcon: 22239

   darcs (#486192), requested 131 days ago
 Description: an advanced revision control system
 Reverse Depends: arch2darcs darcs-buildpackage darcs-load-dirs
   darcs-monitor darcs-server darcsweb
 Installations reported by Popcon: 1375

   dctrl-tools (#448284), requested 362 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies dlocate feta
   haskell-devscripts hg-buildpackage ia32-archive ia32-libs-tools
   mlmmj sbuild (1 more omitted)
 Installations reported by Popcon: 9146

   dpkg (#282283), requested 1433 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb cacao-oj6-dbg cacao-oj6-jdk
   (118 more omitted)
 Installations reported by Popcon: 78798

   drscheme (#402589), requested 682 days ago
 Description: PLT scheme programming environment
 Reverse Depends: drscheme minlog proofgeneral-minlog
 Installations reported by Popcon: 346

   elvis (#432298), requested 472 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 372

   fglrx-driver (#454993), requested 320 days ago (non-free)
 Description: non-free AMD/ATI r5xx, r6xx display driver
 Reverse Depends: fglrx-amdcccle fglrx-atieventsd fglrx-control
   fglrx-driver fglrx-glx fglrx-glx-ia32 fglrx-kernel-src
 Installations reported by Popcon: 2181

   flightgear (#487388), requested 124 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 937

   gentoo (#422498), requested 536 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 283

   gnat-4.3 (#475374), requested 196 days ago
 Description: help needed to execute test cases
 Reverse Depends: adabrowse adacontrol asis-programs ghdl gnade-bin
   gnat gnat-4.3 gnat-gps libadasockets-dev libahven13 (45 more
   omitted)
 Installations reported by Popcon: 503

   gnat-gps (#496905), requested 56 days ago
 Description: co-maintainer needed
 Installations reported by Popcon: 119

   grub (#248397), requested 1627 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: brdesktop-artwork-grub dfsbuild grub-choose-default
   grub-doc replicator startupmanager
 Installations reported by Popcon: 72272

   hotkey-setup (#483107), requested 149 days ago
 Description: auto-configures laptop hotkeys
 Installations reported by Popcon: 38293

  

Bug#503264: ITP: viper -- minimalistic scientific plotter and run-time visualization module

[Johannes Ring]

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

Package name: viper
Version: 0.3.0
Upstream author: Ola Skavhaug
URL: http://www.fenics.org/wiki/Viper
License: LGPL
Description: minimalistic scientific plotter and run-time visualization
module

Viper is a minimalistic scientific plotter and run-time visualization
module. Viper has support for visualizing meshes and solutions in DOLFIN.
Features includes:

 o Light-weight and minimalistic
 o Extended keybindings
 o Interactive
 o Save as png, VTK
 o 2D and 3D
 o Scalar, vector, and displacement fields
 o Multiple input formats
 o Can be used as standalone plotting application, or used as part of
PyDOLFIN

A version of the Debian files is already available in the pkg-scicomp
Subversion repository.


Johannes Ring





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

Bug#503265: ITP: fenics -- automation of computational mathematical modeling

[Johannes Ring]

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

Package name: fenics
Version: 8.10
Upstream author: FEniCS developers
URL: http://www.fenics.org
License: none (meta package)
Description: automation of computational mathematical modeling

The vision of FEniCS is to set a new standard in Computational
Mathematical Modeling (CMM), which is the Automation of CMM (ACMM),
towards the goals of generality, efficiency and simplicity, concerning
mathematical methodology, implementation and application. FEniCS is
organized as a collection of sub projects/components, including DOLFIN,
FErari, FFC, FIAT, Instant, Ko, Puffin, SyFi, UFC and Viper.

A version of the Debian files is already available in the pkg-scicomp
Subversion repository.


Johannes Ring





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