Paul Wise | 1 Nov 06:39
Picon
Favicon
Gravatar

Re: Bug Sprint results (draft)

On Fri, Oct 31, 2008 at 9:39 PM, Josselin Mouette <joss <at> debian.org> wrote:

>      * Paul Wise (au) for fixing #479607 (still to be uploaded)

:D cookies :D

On the serious side, as I wrote in the bug report, I'm not as familiar
with debconf and maintainer scripts as I should be in order to fix
this bug satisfactorily. If anyone who does know debconf/maint scripts
could review the script, I'd be prepared to share my cookies with you,
or shout you a beer at LCA 2009 in Tasmania or DebConf9 in Spain.

--

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

David Paleino | 1 Nov 10:22
Picon
Gravatar

Re: Bug Sprint results (draft)

On Sat, 1 Nov 2008 00:21:07 +0100, Stefano Zacchiroli wrote:

> On Fri, Oct 31, 2008 at 07:48:21PM +0100, Moritz Muehlenhoff wrote:
> > Let's make it a Beer Sprint. The winners receive a package with the
> > local brew from the people who didn't manage to fix their bugs. I'm
> > offering German beer to five winners, just as Joss did for cookies.
> 
> Why not, but note that local breweries are not that common around the
> world as they are (IIRC) in Germany. At least they weren't that common
> in Italy, but that's compensated by home-made liquors usually :)

In Sicily we *do* have local breweries ;)

http://www.birraceria.it/
http://www.lacavernadelmastrobirraio.com/
http://www.naxosbeer.it/ (this one is from my city!!)
http://www.birracurella.it/
http://www.erixbirra.com/
http://www.paulbricius.com/
http://www.laterraeilsole.it/

:)

David

--

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
(Continue reading)

Giuseppe Iuculano | 1 Nov 10:46
Picon
Favicon
Gravatar

Bug#504165: ITP: dm-raid45 -- Source for the dm-raid45 driver

Package: wnpp
Severity: wishlist
Owner: Giuseppe Iuculano <giuseppe <at> iuculano.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Package name    : dm-raid45
  Version         : 20081027
  Upstream Author : Heinz Mauelshagen <hjm <at> redhat.com>
* URL             : http://people.redhat.com/heinzm/sw/dm/dm-raid45/
* License         : GPL
  Programming Lang: C
  Description     : Source for the dm-raid45 driver

 This package provides the source code for the dm-raid45 kernel modules.
 This software extends device-mapper by RAID4 and RAID5 mappings.

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

iEYEARECAAYFAkkMJWIACgkQNxpp46476aovqACePI2pnTKfV54Xd4BHaHuTd2JV
dhQAnjVhdSb3w5aq2q23wMMis/PUNewY
=uArc
-----END PGP SIGNATURE-----

Stefano Zacchiroli | 1 Nov 11:32
Picon
Favicon

Re: Bug Sprint results (draft)

On Sat, Nov 01, 2008 at 10:22:57AM +0100, David Paleino wrote:
> In Sicily we *do* have local breweries ;)

WOW o_O. In Bologna I was aware of only one :(

So you just have to *loose* the forthcoming competition and send beer
to everybody :-P

--

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

Re: Bug Sprint results (draft)

On Sat, 1 Nov 2008 11:32:37 +0100, Stefano Zacchiroli wrote:

> On Sat, Nov 01, 2008 at 10:22:57AM +0100, David Paleino wrote:
> > In Sicily we *do* have local breweries ;)
> 
> WOW o_O. In Bologna I was aware of only one :(
> 
> So you just have to *loose* the forthcoming competition and send beer
> to everybody :-P

Most of the beers I cited cannot go very far: they must be kept at a controlled
temperature :)

So, sorry, I cannot send my local beer :)

If you're coming to Sicily, then... that's another story! ;)

--

-- 
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
Michael Meskes | 1 Nov 20:41
Picon
Favicon

Re: Possibility for dependencies against specific kernel modules

On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote:
> I guess one solution could be to have virtualbox-ose not depend on 
> virtualbox-modules, but on virtualbox-ose-modules-$ABI.

Building vbox modules from lme makes no real sense to me because lme is not
supposed to be reupped for each new version of virtualbox. On the other hand
building them with virtualbox-ose makes no sense because vbos is not supposed
to be reupped for each new kernel.

How about adding a new package, virtualbox-ose-modules-2.6, mirroring lme only
for the virtualbox modules? This package could be handled by teh virtualbox
team? I spend enough time debugging that I know lme quite well and Panthera is
a member of both teams, so technically this shouldn't be a problem.

I CCed debian-release to learn whether this is okay for Lenny.

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: meskes <at> jabber.org
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!

Frans Pop | 1 Nov 21:37
Picon

Re: Possibility for dependencies against specific kernel modules

Michael Meskes wrote:
> On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote:
>> I guess one solution could be to have virtualbox-ose not depend on
>> virtualbox-modules, but on virtualbox-ose-modules-$ABI.
> 
> Building vbox modules from lme makes no real sense to me because lme is
> not supposed to be reupped for each new version of virtualbox. On the
> other hand building them with virtualbox-ose makes no sense because vbos
> is not supposed to be reupped for each new kernel.

Sounds like a good plan. Only disadvantage is that for ABI-changing kernel 
updates in stable this will mean one more package to track for whoever 
handles those, but I'd guess that is acceptable.

For a really neat and complete solution you'd IMO still need something 
like I proposed though to make the vbox ABI visible in package names, but 
that can probably be postponed until after Lenny.

> How about adding a new package, virtualbox-ose-modules-2.6, mirroring
> lme only for the virtualbox modules? This package could be handled by
> the virtualbox team? I spend enough time debugging that I know lme quite
> well and Panthera is a member of both teams, so technically this
> shouldn't be a problem.

Consequence would be that we'll need uploads of both l-m-e (to remove the 
vbox-modules package) and this new package.

*If* we can be sure that for Lenny there will not be any vbox ABI changes 
(which I'd think is a certainty), we could also for lenny go for a 
pragmatic solution: just reupload l-m-e once now (built against new vbox 
(Continue reading)

Bastian Blank | 1 Nov 21:54
Picon
Favicon

Re: Possibility for dependencies against specific kernel modules

On Sat, Nov 01, 2008 at 08:41:46PM +0100, Michael Meskes wrote:
> On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote:
> > I guess one solution could be to have virtualbox-ose not depend on 
> > virtualbox-modules, but on virtualbox-ose-modules-$ABI.
> Building vbox modules from lme makes no real sense to me because lme is not
> supposed to be reupped for each new version of virtualbox. On the other hand
> building them with virtualbox-ose makes no sense because vbos is not supposed
> to be reupped for each new kernel.

You are solving problem 2 before problem 1.

> I CCed debian-release to learn whether this is okay for Lenny.

You forgot -security.

Bastian

--

-- 
You can't evaluate a man by logic alone.
		-- McCoy, "I, Mudd", stardate 4513.3

Filipus Klutiero | 2 Nov 00:29
Picon

Re: Possibility for dependencies against specific kernel modules

>
> Hi folks
>
> Because of some recent events, I thought about the possibility for
> packages to depend against kernel module packages. As we don't want to
> dictate the usage of Debian provided kernels, we need a last resort
> fallback to the modules source.
>
> My first solution was something like the following:
>
> | Package: test
> | Depends: test-modules | test-source
> |
> | Package: test-modules
> | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64
> |
> | Package: test-source
>
> Both apt and aptitude would always try to install test-modules. The
> problem is that neither apt nor aptitude are smart enough to find the
> best solution in the dependency tree, both only evaluate deps of depth 1
> at one time.
I don't understand why APT would always try to install test-modules. 
Suppose you're on lenny and you have speex installed, then APT won't 
propose to install vorbis-tools when you request to install abcde, 
despite its dependency on vorbis-tools (>= 1.0beta4-1) | lame | flac | 
bladeenc | speex

Are you saying there's a difference in your example? If so, what is it?

(Continue reading)

Raphael Geissert | 2 Nov 01:24
Picon

Re: can buildd logs be sorted (again)?

Neil Williams wrote:

> On Thu, 2008-10-30 at 20:02 -0600, Raphael Geissert wrote:
>> [1] I promised Christoph Berg that I am going to write a PHP extension,
>> [actually
>> an interface, to libapt's functions; but I haven't been lucky enough to find
>> the docs (libapt-pkg-doc isn't what I expected). If somebody can point me to
>> the right documents it would be great.
> 
> libapt-pkg-doc is what there is, apart from the source. Recursion is a
> constant nightmare with the perl bindings for apt so you have to be very
> careful in your debugging cases for the PHP version. Take a look at
> libcache-apt-perl for a sane way to handle at least some of the apt
> bindings with safe recursion. I've no idea whether that design could
> work in PHP but it is (hopefully) clearer than the docs for the bindings
> themselves.
> 
> You might also want to look at the source code for edos-debcheck and
> other routines that do dependency iterations etc.
> 
> Note that there *is* a PHP interface to the Packages.gz file itself -
> see Emdebian SVN:
>
http://buildd.emdebian.org/svn/browser/current/website/trunk/english/toolchains
> 
[...]

Thanks for the pointers :)

I'm not actually trying to provide a complete binding, but just a couple of
(Continue reading)


Gmane