Bug sprint !

[Josselin Mouette]

Hi,

there are currently 122 RC bugs remaining that affect both testing and
unstable. We need to fix them NOW.

However, in the permanent BSP state that has lasted for quite some time,
people seem to lose focus on this urgent need for the release. So the
idea is:
122 developers × 5 days = 122 RC bugs fixed

The rules are : at the end of a 5-day period, the bug you are assigned
must be closed in unstable or have a lenny-ignore tag. Otherwise this is
a free-for-all.

The first 5 developers to fix their bugs will be sent a box of home-made
cookies. Those who can’t fix their bugs in 5 days will receive the visit
of a release manager who will hit them with a rusty shovel.

All we need is 122 skilled developers willing to sign in this contract
(with their blood).

Does it sound like a realistic idea? If people agree with it, I’ll setup
a wiki page to collect the volunteer list and send an announcement.

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


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

Re: debian package dependencies

[Osamu Aoki]

Hi,

This should have been debian-user posting...  This is not right list.

On Fri, Oct 10, 2008 at 12:42:39PM +0200, Jan U. Hartmann wrote:
> Hi,
>
> I'm maintaining the Debian Package for a network appliance. The Update
> is executed via Webinterface.  My problem is that I need an additional
> package in a newer Version of my appliance.

Then use or make a back ported pakage.

> I can't change dependencies, that would lead to an error, right?
> Do I have any chance to tell my new paket it needs package xy??

s/paket/package/ , I guess...

You make your own or use one available in backports.org etc.
  http://www.backports.org/dokuwiki/doku.php

> The User does not have shell nor console access.

But administer have access to the machine via sshe/fai, etc., I guess.
No problem.

> Thanks a lot,

Read some basic documentations:
  http://www.debian.org/doc/
Of course my docs:
  http://www.debian.org/doc/manuals/reference/ (old version)
and my new version for lenny:
  http://people.debian.org/~osamu/pub/getwiki/html/index.en.html
  http://wiki.debian.org/DebianReference

Osamu


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

Re: Bug sprint !

[Simon Josefsson]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Hi,
>
> there are currently 122 RC bugs remaining that affect both testing and
> unstable. We need to fix them NOW.
>
> However, in the permanent BSP state that has lasted for quite some time,
> people seem to lose focus on this urgent need for the release. So the
> idea is:
>   122 developers × 5 days = 122 RC bugs fixed
>
> The rules are : at the end of a 5-day period, the bug you are assigned
> must be closed in unstable or have a lenny-ignore tag. Otherwise this is
> a free-for-all.
>
> The first 5 developers to fix their bugs will be sent a box of home-made
> cookies. Those who can’t fix their bugs in 5 days will receive the visit
> of a release manager who will hit them with a rusty shovel.

Would using a gnuherds.org pledge on RC bugs be useful here?  Then
people can donate money to get RC bugs fixed in debian, and people who
fix the bug can claim the money.  The claims and pledges would be open,
which I think is important.

I understand there could be conflicts in agreeing on who actually closed
a particular RC bug though.  Hm.  Maybe voting could resolve that...

Just an idea.

/Simon


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

Rejuvenated kernel-package uploaded to unstable, please test

[Manoj Srivastava]

Hi folks,

A new version of kernel-package has made its way to unstable.
 This is a extensive change, and addresses most of the problems that
 have been plaguing kernel-package, partially thanks to patches provided
 by other folk.

The new version works with the merged x86 code in recent
 kernels, while retaining compatibility with older kernel sources. It
 correctly generates the right set of headers. It is again
 cross-compilation friendly. The postinst no longer runs lilo when it
 thinks there is no other bootloader (it used to detect grub, but not
 grub2). It correctly installs firmware in a versioned location under
 /lib/firmware.

More significantly, the build system has moved to a more
 streamlined, make -j friendly build system While I am not sure of this
 fixes some of the nagging problems we have been facing in recent
 versions of kernel-package, where we used double colon rules, which
 were convenient, sure, but played havoc with ordering of the rules, and
 had to have various band-aids to help out with the ordering. The system
 was rapidly growing complex, with clear indication that it was actually
 faster.

The new target mechanism does away with doublecolon rules, and
 should play better with parrallel compilation. We try to use upstream
 kbuild as far as possible, to reduce churn as the files upstream
 installs change. Some added checks of the Makefile are now in place so
 we retain backwards compatibility. This should improve things lot wrt
 header files.  We also now add dependencies to more packages actually
 required to build kernel images.

We also try to look for the kbuild created KERNELRELEASE
 variable, which is designed to be used by distros to figure out where
 modules are to be loaded from, etc. This should help reduce version
 mismatches. We also prepare the kernel.release file early, to help
 that.

We also refitted to support the new XEN code in mainstream, in
 that the same image can be booted normally or be used as a XEN
 image. This support probably needs to be improved.

The make target dependencies have been extensively reworked, to
 minimize surprises and wasted effort. We also strip modules, based on
 DEB_BUILD_OPTIONS (nostrip).

Extra care is now taken so we do not accidentally remove
 ./debian while cleaning, thanks to upstream helpfully removing ./debian
 when cleaning.  This should prevent dpkg-buildpackage from accidentally
 shooting itself in the foot by removing ./debian as its first action.
 
Finally, the changes have made it possible to create a
 kernel-image straight out of a git working directory, partially because
 the upstream script does not think that the changes kernel-package
 makes to the source make it dirty, and partially because we run the
 kernel.release creation script early, just after patching the
 sources, but before generating the ./debian/changelog, and this,
 abetted by using KERNELRELEASE, ensures that we correctly capture the
 version.

I have also added dependencies to kernel package, the kerel
 source package, the kernel header package, with the basic tools
 required to build a kernel, so by installing the source package, or the
 header package, the user should have most of the things required to
 compile their own kernel.

Anyway, this was a marathon two day hack session, and while I
 have compiled 2.6.25.8 and 2.6.26 several dozen times, I would
 appreciate testing this version, so we may get it into lenny.

manoj
-- 
Dungeons and Dragons is just a lot of Saxon Violence.
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 sprint !

[Pierre Habouzit]

On Fri, Oct 10, 2008 at 12:04:12PM +, Josselin Mouette wrote:
> Hi,
> 
> there are currently 122 RC bugs remaining that affect both testing and
> unstable. We need to fix them NOW.
> 
> However, in the permanent BSP state that has lasted for quite some time,
> people seem to lose focus on this urgent need for the release. So the
> idea is:
>   122 developers × 5 days = 122 RC bugs fixed
> 
> The rules are : at the end of a 5-day period, the bug you are assigned
> must be closed in unstable or have a lenny-ignore tag. Otherwise this is
> a free-for-all.
> 
> The first 5 developers to fix their bugs will be sent a box of home-made
> cookies. Those who can’t fix their bugs in 5 days will receive the visit
> of a release manager who will hit them with a rusty shovel.
> 
> All we need is 122 skilled developers willing to sign in this contract
> (with their blood).
> 
> Does it sound like a realistic idea? If people agree with it, I’ll setup
> a wiki page to collect the volunteer list and send an announcement.

Sadly something like 20 to 30 bugs aren't easy to solve even by the best
developpers in only 5 days[e.g. look at the tokyocabinet bug, I don't
think I'm unskilled even if there is a lot of better DDs than me, and I
just don't know where to start]. but still that is clearly a good idea.
I would sign on this.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp5GZVV9z0f6.pgp
Description: PGP signature

debian package dependencies

[Jan U. Hartmann]

Hi,

I'm maintaining the Debian Package for a network appliance. The Update 
is executed via Webinterface.
My problem is that I need an additional package in a newer Version of my 
appliance.


I can't change dependencies, that would lead to an error, right?
Do I have any chance to tell my new paket it needs package xy??

The User does not have shell nor console access.

Thanks a lot,

Jan U. Hartmann


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

Re: Rejuvenated kernel-package uploaded to unstable, please test

[Manoj Srivastava]

Hi,

 Be sure to get kernel-package_11.005_all.deb. The 11.005 fixes a
 critical regression, born of a copy&paste error from late night
 hacking. Sorry for the inconvenience.

manoj

-- 
Spence's Admonition: Never stow away on a kamikaze plane.
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]

The kernel-img.conf man page

[Manoj Srivastava]

Hi,

The kernel images produced by kernel package all obey the
 directives in /etc/kernel-img.conf, for example, to trigger
 lilo/grub. Currently, users only get to see the man page if they happen
 to have the 'kernel-package' package installed. As Bug#373872 shows,
 even official kernel images follow the same convention.

Now, one could create a linux-image-common package to hold this
 man page and perhaps other docs and utilities common to all kernel
 images, and have the image packages depend on that, which would be
 simple to do.

Alternately, we can ship the man page in the package manpages,
 since it is effectively useful on any Debian install, but then the
 issue comes of updating the man page. With the previous proposal, I can
 just update the linux-image-common package version, and make the kernel
 image dependency a versioned dependency, and ensure each kernel image
 is associated with the correct man page (however, since kernel-img.conf
 deals with installation option, it is doubtful how useful the
 dependency is, since the package must be installed to learn how to
 manage to modify the installation.

I can go either route. Comments?

manoj
-- 
Neutrinos are into physicists.
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 sprint !

[Vincent Bernat]

OoO En ce  début d'après-midi nuageux du vendredi  10 octobre 2008, vers
14:04, Josselin Mouette <[EMAIL PROTECTED]> disait :

> The rules are : at the end of a 5-day period, the bug you are assigned
> must be closed in unstable or have a lenny-ignore tag. Otherwise this is
> a free-for-all.

The developer that will get Iceweasel unreproducible bugs will be unlucky.
-- 
printk("??? No FDIV bug? Lucky you...\n");
2.2.16 /usr/src/linux/include/asm-i386/bugs.h


pgpmGCTzFKDjx.pgp
Description: PGP signature

Re: Bug sprint !

[Stefano Zacchiroli]

On Fri, Oct 10, 2008 at 02:04:12PM +0200, Josselin Mouette wrote:
> All we need is 122 skilled developers willing to sign in this contract
> (with their blood).
> 
> Does it sound like a realistic idea? If people agree with it, I’ll setup
> a wiki page to collect the volunteer list and send an announcement.

I'm not sure I'm willing to sign the contract with my blood :), but
beside that I think it is a wonderful idea: it is opt-in, visible,
... and looks like fun!

Go for the wiki page and then announce it on d-d-a (with the details
of which RM will be traveling which country to kick the needed
asses!).

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled /\ All one has to do is hit the
XML stuff is so ... simplistic  -- Manoj \/ right keys at the right time


signature.asc
Description: Digital signature

Re: Bug sprint !

[Thomas Viehmann]

Simon Josefsson wrote:
> Would using a gnuherds.org pledge on RC bugs be useful here?  Then
> people can donate money to get RC bugs fixed in debian, and people who
> fix the bug can claim the money.  The claims and pledges would be open,
> which I think is important.

> I understand there could be conflicts in agreeing on who actually closed
> a particular RC bug though.  Hm.  Maybe voting could resolve that...

Personally, I think we should just do it for the fun.

Kind regards

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


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

Re: Bug sprint !

[Steve Langasek]

On Fri, Oct 10, 2008 at 07:50:10PM +0200, Vincent Bernat wrote:
> OoO En ce  début d'après-midi nuageux du vendredi  10 octobre 2008, vers
> 14:04, Josselin Mouette <[EMAIL PROTECTED]> disait :

> > The rules are : at the end of a 5-day period, the bug you are assigned
> > must be closed in unstable or have a lenny-ignore tag. Otherwise this is
> > a free-for-all.

> The developer that will get Iceweasel unreproducible bugs will be unlucky.

If the bugs are unreproducible, why have they not been downgraded?

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


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

Re: Bug sprint !

[Mike Hommey]

On Fri, Oct 10, 2008 at 11:55:46AM -0700, Steve Langasek wrote:
> On Fri, Oct 10, 2008 at 07:50:10PM +0200, Vincent Bernat wrote:
> > OoO En ce  début d'après-midi nuageux du vendredi  10 octobre 2008, vers
> > 14:04, Josselin Mouette <[EMAIL PROTECTED]> disait :
> 
> > > The rules are : at the end of a 5-day period, the bug you are assigned
> > > must be closed in unstable or have a lenny-ignore tag. Otherwise this is
> > > a free-for-all.
> 
> > The developer that will get Iceweasel unreproducible bugs will be unlucky.
> 
> If the bugs are unreproducible, why have they not been downgraded?

Because several people got the same crash with the same stack trace.

Mike


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

Re: The kernel-img.conf man page

[Stephen Gran]

This one time, at band camp, Manoj Srivastava said:
> I can go either route. Comments?

I'd say a -common package makes the most sense to me.  The other way
seems like you could conceivably end up with several roughly identical
manpages installed, which seems like a waste.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug sprint !

[Mohammed Adnène Trojette]

On Fri, Oct 10, 2008, Simon Josefsson wrote:
> Would using a gnuherds.org pledge on RC bugs be useful here?  Then
> people can donate money to get RC bugs fixed in debian, and people who
> fix the bug can claim the money.  The claims and pledges would be open,
> which I think is important.
> 
> I understand there could be conflicts in agreeing on who actually closed
> a particular RC bug though.  Hm.  Maybe voting could resolve that...
> 
> Just an idea.

Good idea! There's even gonna be a free domain name soon to do that
properly:

% whois dunc-tank.org|grep -i status
Status:CLIENT DELETE PROHIBITED
Status:CLIENT RENEW PROHIBITED
Status:CLIENT TRANSFER PROHIBITED
Status:CLIENT UPDATE PROHIBITED
Status:AUTORENEWPERIOD

Joss, après vous.

No seriously, fun will do just fine ;-)

-- 
Mohammed Adnène Trojette


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

Re: Bug#501717: ITP: libnet-mac-vendor-perl -- Look up the vendor for a MAC

[Ben Hutchings]

On Fri, 2008-10-10 at 09:14 +0300, Niko Tyni wrote:
> On Thu, Oct 09, 2008 at 10:38:30PM +0200, Franklin PIAT wrote:
> > On Thu, 2008-10-09 at 14:54 -0500, Matt Zagrabelny wrote:
> > > * Package name: libnet-mac-vendor-perl
> > >   Description : Look up the vendor for a MAC
> > 
> > I'm currious on how many MAC-prefix to OUI we have in Debian...
> >  nmap:   /usr/share/nmap/nmap-mac-prefixes

# $Id: nmap-mac-prefixes 7804 2008-05-30 21:47:20Z fyodor $ generated with 
make-mac-prefixes.pl
# Original data comes from http://standards.ieee.org/regauth/oui/oui.txt
# These values are known as Organizationally Unique Identifiers (OUIs)
# See http://standards.ieee.org/faqs/OUI.html
# We have added a few unregistered OUIs at the end.

> >  kismet: /etc/kismet/ap_manuf

This has more than just OUIs, like default ESSID and administration IP
address.

> >  wireshark-common: /usr/share/wireshark/manuf

# This file was generated by running ./make-manuf.
# Don't change it directly, change manuf.tmpl and wka.tmpl instead.
#
# The data below has been assembled from the following sources:
#
# The IEEE public OUI listing available from:
# http://standards.ieee.org/regauth/oui/index.shtml
# http://standards.ieee.org/regauth/oui/oui.txt
#
# Michael Patton's "Ethernet Codes Master Page" available from:
# 
# 
#
# Well-known addresses.
# The data below has been assembled from the following sources:
#
# Michael Patton's "Ethernet Codes Master Page" available from:
# 
# 
#
# Microsoft Windows 2000 Server
# Operating System
# Network Load Balancing Technical Overview
# White Paper

> > But there are probably lot more.
> 
> I know there's one compiled into ipv6calc. 
> 
> Furthermore, 'apt-file search oui' reveals at least these:
> 
> arp-scan: /usr/share/arp-scan/ieee-oui.txt

# ieee-oui.txt -- Ethernet vendor OUI file for arp-scan
#
# This file was automatically generated by get-oui at 2007-05-22 21:59:31
# using data from http://standards.ieee.org/regauth/oui/oui.txt

> btscanner: /usr/share/btscanner/oui.txt
> kdebase-data: /usr/share/apps/kcmview1394/oui.db

These are concise versions of
http://standards.ieee.org/regauth/oui/oui.txt

> ntop: /etc/ntop/oui.txt
> ocsinventory-reports: /usr/share/ocsinventory-server/ocsreports/files/oui.txt

Copies of http://standards.ieee.org/regauth/oui/oui.txt

> swscanner: /etc/swscanner/oui_sws.txt

Concise version.

> wireshark-dev: /usr/include/wireshark/epan/oui.h

This only has a tiny number of OUIs; I don't see what the point of it.

I'd be willing to create a package that contains an OUI list and a
script to update it.

Ben.



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

Re: autoreconf and quilt

[Paul Wise]

On Sat, Oct 11, 2008 at 2:16 PM, Sylvain Beucler <[EMAIL PROTECTED]> wrote:

> What kind of elegant solution would you recommend? :)

debian/rules:

clean:
 ...
 make maintainer-clean

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

autoreconf and quilt

[Sylvain Beucler]

Hi,

(please keep in me Cc:, I'm not on the list)

The 'ballz' package (platform/puzzle game) requires a few changes in
the build system to avoid using the builtin copy of 'chichan' (GUI
toolkit for games)


I checked autotools-dev and decided to implement a solution that
re-run the autotools suite through 'autoreconf' at build time.


The drawback is that the working directory is modified, and it's not
possible to revert those changes in the 'clean target'.  As such it's
easy to build the package twice, forget about that drawback, and
generate a huge diff.gz.

This is especially dirty since I'm supposed to use quilt only for this
package.

It was suggested to run 'autoreconf' manually and convert this to a
static patch.  But this miss the point of regenerating the build
system at package build time (keeping config.* files up-to-date, etc.)


What kind of elegant solution would you recommend? :)


Thanks,

-- 
Sylvain


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