Re: can buildd logs be sorted (again)?

[Neil Williams]

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

//
// PHP Apt-file parser, Version 1.2
//
// The following PHP functions parse Debian APT-repository files
// (Packages.gz, Sources.gz) and generate an XHTML summary of them.
//
// Written by Jarno Elonen in 2003, 2004

#  Copyright (c) 2003-2006 Jarno Elonen <[EMAIL PROTECTED]>

Working examples:
http://www.emdebian.org/toolchains/search.php

http://www.emdebian.org/packages/search.php

http://www.emdebian.org/locale/search.php

(Actually all are the same file with different configurations passed to
parse-apt.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




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

Re: can a kernel in main depend on firmware in non-free to work?

[Josselin Mouette]

Le jeudi 30 octobre 2008 à 17:37 -0200, Alexandre Oliva a écrit :
> It does make a difference when the components don't quite form an
> inseparable unit, but rather they're just put together in a single
> tarball for convenience.

Kernel modules are not really separable from the kernel image. You can
split the files in different packages, but in functional terms they
would have to be always installed together. (This is because of serious
issues in the Linux kernel, but it is quite unrelated to this
discussion.)

> The fact that Debian does hard work to split Free from non-Free to
> keep portions of a package in main while moving others to non-free
> shows that this upstream package boundary is quite a thin argument for
> you to stand on.

> > The only thing that matters is package dependencies.
> 
> But not as in '.deb requirements tags', but rather in 'compilation or
> execution requirements', as per the Debian policies, right?  And then,
> ultimately, it's Debian that decides what a Debian package amounts to.

Precisely. And because it’s pointless to split kernel modules from the
kernel image, there is all reason to put them in the same binary
package.

> >> There *is* reason to split the linux package, I thought that was
> >> beyond any doubt by now.  Debian isn't supposed to ship non-Free
> >> Software, and Linux does include non-Free firmwares.
> 
> > And this has already been the case for long.
> 
> I can't tell what point you're trying to make with this statement, or
> how it relates with the conversation underway.  Can you please
> elaborate, so that I don't misunderstand what you were trying to
> communicate?

Non-free components (mostly firmware) have been split off from the
upstream sources in a separate source package in non-free
(firmware-nonfree) since before the etch release.

> > No, there is no doubt about that either. There is absolutely no need to
> > split these modules.
> 
> Err...  Are you just voicing your personal opinion, or is this
> authoritative information about a decision you're in charge of, or
> widely known among Debian developers?  I don't know your role in the
> Debian project, so please bear with my ignorance.

This is just common sense from the only developer who is still losing
his time discussing with you.

> But do policies make room for a single Debian package build to create
> a binary .deb that goes in main and another binary .deb that goes in
> contrib?

Yes, it’s possible. But there is no reason to do that in most cases, and
especially for the kernel where it would annoy our users without
bringing anything good for the free/non-free distinction.

> Please do share.  What is contrib for, in your understanding?  

Contrib is a place for packages that require non-free components to run.
It is not meant as a pretext for hair-splitting. The distinction between
main and contrib is often blurry (see e.g. game console emulators), and
in doubtful cases our choice is generally to put the package in main. 

> And
> pretty please copy me, as requested in the Mail-Followup-To header,
> I'm not on this list.

Please do not rely on non-standard headers that a only handful of
clients understand, and that violate the protocol by not using the X-
prefix.

> BTW, is this an appropriate forum for seeking enlightenment and
> offering suggestions about Debian policies, and how they apply to the
> decision at hand?  If not, I'd be glad to abide by suggestions of more
> appropriate Debian mailing lists.

If you have useful general suggestions, this is the place. If you have
useful suggestions about kernel packaging, you should write to
debian-kernel. If you want to go on this discussion, I suggest you do it
on debian-curiosa.

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

Possibility for dependencies against specific kernel modules

[Bastian Blank]

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 found a variant which seems to work, but produces dependency packages
for fun:

| Package: test
| Depends: test-modules-fallback
|
| Package: test-modules-fallback
| Depends: test-modules | test-source, linux-image-2.6.26-1-powerpc | 
linux-image-2.6.26-1-powerpc64 | test-source
|
| Package: test-modules
| Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64
|
| Package: test-source

Now the question is clearly, do we want/need such a possibility? And if
yes, how should it work. If the answer is no, I have to refuse to build
modules like vbox[1].

Bastian

[1]: The virtualbox modules don't define a stable ABI, it actually
 changes for every release.
-- 
Virtue is a relative term.
-- Spock, "Friday's Child", stardate 3499.1


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

Re: Possibility for dependencies against specific kernel modules

[Josselin Mouette]

Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit :
> 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.

I think this is something good to have, but I’m skeptical about the
fallback to the source. It will, in unstable and sometimes in testing or
even stable, to situations where the modules are not available for a
while, and the source will get installed, leaving the system in a broken
state. Unless the source can use DKMS or a similar mechanism to
automatically generate modules, this is not very reliable.

-- 
 .''`.
: :' :  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

Bug Sprint results (draft)

[Josselin Mouette]

Hi folks,

the lenny Bug Sprint is over. I think it is a mitigated success. A
success since a number of RC bugs were fixed, but mitigated by the small
number of players.

I’d like to thank all players for their contributions. The game was not
really fair since some issues were much easier to deal with than others,
but it was very nice to see people all over the world fix RC bugs for
fun and cookies.

Now for the results. I have checked the related bugs, but I don’t know
deeply enough the issues to judge, so this is only a draft. Please
correct me if some people who deserve cookies have been misjudged! I’ve
also added the people’s locations to help defining who will send cookies
to whom, please correct them if they are wrong.


The following people definitely deserve cookies. They provided patches
for long-standing RC issues which are all fixed or soon to be.
  * Yves-Alexis Perez (fr) for closing #486400, fixing #501997 and
sending a patch for #448470
  * Stefano Zacchiroli (fr) for dealing with #501423 and fixing
#434647
  * Riku Voipio (fi) for fixing #501301
  * Clint Adams (us) for fixing #496269
  * Sean Finney (us) for downgrading #501574 and fixing #267040
  * Lucas Nussbaum (fr) and Emmanuel Bouthenot (fr) for working
together on #501800/#496954
  * Paul Wise (au) for fixing #479607 (still to be uploaded)

The following people will also receive cookies if there are enough left.
  * Raphaël Hertzog (fr) for proposing a patch to #501306
  * Thijs Kinkhorst (nl) for backporting the fix for #496418 to
testing

The following people deserve a honorable mention for dealing with their
bugs.
  * Ben Hutchings for downgrading #452377
  * Joost Damad for patiently dealing with the submitter of #449497
  * Gaudenz Steinlin for proposing approaches for #488669 (this is
still work in progress)
  * Steve Langasek for downgrading #500482
  * Kees Cook for downgrading #501903

The following people failed to fix the bugs they were assigned, but the
issues were either too complex or already tackled by other people. They
are encouraged to contribute to the baking effort, still!
  * Josselin Mouette (fr) for not fixing the hppa kernel (I will
bake cookies anyway)
  * Julien Danjou (fr) for not fixing the glibc on s390
  * Dominic Hargreaves (li) for letting the maintainer fix #501427
  * Tim Retout (uk) for letting the maintainer fix #393837
  * Christoph Berg (de) for investigating #470882 without success
  * Y Giridhar Appaji Nag (in) for not fixing gecko embedding
  * Moritz Muehlenhoff (de) and Charles Plessy (fr) for letting the
maintainer fix #486334/#492488
  * Ghe Rivero (es) for letting the maintainer fix #434040
  * Bruno Beaufils (fr) for letting Sean Finney fix #267040

The following people failed to fix their bugs and have to bake cookies.
  * Franklin Piat (fr)
  * David Moreno Garza (us)
  * Jeremiah Foster (se)
  * Nicolas Valcarcel (pe)

The following people volunteered to bake cookies anyway. BTW we’re
missing one in the US area - we can’t let damog handle it all by
himself, and I fear cookies made in Europe wouldn’t be tasty after going
through Atlantic.
  * Frank Lienhard (de)
  * Josselin Mouette (fr)
  * José Luis Tallón (es)
  * Tim Richardson (au)
  * Steve McIntyre (uk) (he proposed money, but we really want
cookies instead)

As soon as we agree on the list of winners and bakers, I will make
assignments.

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: Possibility for dependencies against specific kernel modules

[Kel Modderman]

On Friday 31 October 2008 22:20:26 Josselin Mouette wrote:
> Le vendredi 31 octobre 2008 à 12:44 +0100, Bastian Blank a écrit :
> > 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.
> 
> I think this is something good to have, but I’m skeptical about the
> fallback to the source. It will, in unstable and sometimes in testing or
> even stable, to situations where the modules are not available for a
> while, and the source will get installed, leaving the system in a broken
> state. Unless the source can use DKMS or a similar mechanism to
> automatically generate modules, this is not very reliable.
> 

fwiw, I have tried to address the issue of having $module-source packages
have their binary product built and installed rather transparently, you may
look at the initial hackwork at:

http://svn.berlios.de/svnroot/repos/fullstory/dmakms/trunk/
http://svn.berlios.de/svnroot/repos/fullstory/dmakms/trunk/debian/README.Debian

It's the start of a solution for: #299727

dmakms has got technical flaws, I know, but it works well enough for my current
needs (without patching existing tools such as module-assistant, which could
probably do with some lovin'), maybe it could be extended and fixed up to be
technically better and useful for others.

Thanks, Kel.


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

Re: Bug Sprint results (draft)

[Steve McIntyre]

Joss wrote:
>
>The following people failed to fix the bugs they were assigned, but the
>issues were either too complex or already tackled by other people. They
>are encouraged to contribute to the baking effort, still!
>  * Josselin Mouette (fr) for not fixing the hppa kernel (I will
>bake cookies anyway)
>  * Julien Danjou (fr) for not fixing the glibc on s390
>  * Dominic Hargreaves (li) for letting the maintainer fix #501427

Dom's actually in the UK, ignore the .li email address. :-)

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
Google-bait:   http://www.debian.org/CD/free-linux-cd
  Debian does NOT ship free CDs. Please do NOT contact the mailing
  lists asking us to send them to you.


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

Re: Bug#484656: Fw: gnome, kde, xfce use non-policy main menu

[Michelle Konzack]

Hello *,

while reading the forwarded messages in the BTS, I  am  supporting  Bill
to continue maintaining "menu" since the "desktop" is  hit  by  to  many
limitations.

I have an Add-On to "menu" called "tdfvwm-menu" which is  currently  not
updated since I have some problems here in France...



However, I will continue updating my package AFTER release of Lenny...

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant



Am 2008-08-15 21:07:08, schrieb Daniel Dickinson:
> 
> 
> Begin forwarded message:
> 
> Date: Mon, 7 Jul 2008 21:44:29 +0200
> From: Bill Allombert <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], debian-devel@lists.debian.org
> Subject: Re: gnome, kde, xfce use non-policy main menu
> 
> 
> On Sun, Jul 06, 2008 at 01:08:40PM -0400, Joey Hess wrote:
> > Josselin Mouette wrote:
> > > Therefore, I still feel that, despite it being a big mess, the
> > > current situation is the best:
> > >   * the default menu contains only what is needed, and we are
> > > still hunting down entries that are useless to make them not show up
> > > by default;
> > >   * users wanting the Debian menu and its gazillions of entries
> > > including window managers, terminal emulators and shell
> > > interpreters can enable it easily in the menu editor;
> > >   * those really wanting only the Debian menu can replace
> > > gnome-applications.menu by debian-menu.menu.
> > > 
> > > If you want this to change, you need to seriously think about
> > > evolutions to both XDG and Debian menu systems, to convince fd.o
> > > and the Debian menu maintainer to implement them
> > 
> > Actually, no, if you want this to change, you have only to do nothing.
> > 
> > People (many of them MOTUs from Ubuntu in my experience) are filing
> > lots of requestes for random packages to have .desktop files added to
> > them, so they appear in the gnome menu. The criteria seems to be "a
> > program that $RANDOM_USER would like to have on the menu and files a
> > bug about || that $RANDOM_UPSTREAM ships a desktop file for, for
> > whatever reason".
> > 
> > So, after sufficient time, the gnome menu will contain a random
> > assortment of the menu items that also appear in the debian menu. Not
> > a well-chosen and consistent assortment, but the kind of random
> > assortment that you get when you ignore policy and go off on your own
> > way.
> 
> I agree with you, but I am only the 'Debian menu maintainer' and I do
> not have time or interest to maintain the .desktop files in Debian.
> Instead people (not you) ask me transparently to stop maintaining menu
> and maintain the .desktop files instead, but no one is willing to do
> the work. (And of course .desktop is about 10% of the XDG spec).
> 
> Cheers,
> -- 
> Bill. <[EMAIL PROTECTED]>
> 
> Imagine a large red swirl here. 
> 
> 
> -- 
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
> 
> 
> -- 
> And that's my crabbing done for the day.  Got it out of the way early, 
> now I have the rest of the afternoon to sniff fragrant tea-roses or 
> strangle cute bunnies or something.   -- Michael Devore
> GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org
> No more sea shells:  Daniel's Webloghttp://cshore.wordpress.com
> 
> 
> 
> 
 END OF REPLIED MESSAGE 




-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

Re: DFSG violations: non-free but no contrib

[Lennart Sorensen]

On Thu, Oct 30, 2008 at 09:01:18PM -0700, Thomas Bushnell BSG wrote:
> On Thu, 2008-10-30 at 16:33 -0400, Lennart Sorensen wrote:
> > So if any of the hardware that requires non-free firmware to operate and
> > currently works in etch was to not work with Lenny, then that's
> > completely unacceptable?
> > 
> > If that's the case, then there is no way EVER to make Debian comply with
> > the DFSG since you aren't going to get free firmware for all those
> > devices.
> 
> Um, yes there is.  We could do the same thing we do with codecs, file
> formats, and all the rest--in the absence of support with free software,
> we don't support it in Debian.

That's what I said.

Those people who insist there can't be any regressions, are simply
kidding themselves.  Debian never should have supported that hardware.

-- 
Len Sorensen


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

Re: Is Christian Sánchez still active?

[José Miguel Parrella Romero]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Damyan Ivanov escribió, en fecha 31/10/08 02:08:
> [Cc me on replies, thanks]
> 
> Hi Jose and Anibal,
> 
> You did sponsor packages for Christian Sánchez before, do you know if 
> he is still active in Debian or how could I contact him?

Hello,

I've seen Christian IRL recently, he seems to be lacking some time for
Debian but he's still 'active' and interested. I'm CC'ing him through
other email address.

- --
José Miguel Parrella Romero   PGP Key 0x005C3B82
Debian Developer  www.bureado.com.ve
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkLGBMACgkQUWAsjQBcO4KP4ACfdkuhVXSReIL01j7OilLDJrRw
g1kAn2kxmOfGXGF62GdClnl96V8+ieoA
=Z4we
-END PGP SIGNATURE-


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

Re: Bug Sprint results (draft)

[sean finney]

On Fri, Oct 31, 2008 at 01:39:47PM +0100, Josselin Mouette wrote:
>   * Sean Finney (us) for downgrading #501574 and fixing #267040

i'm in .se, actually :)


sean


signature.asc
Description: Digital signature

Re: Possibility for dependencies against specific kernel modules

[Frans Pop]

Bastian Blank wrote:
> 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.

Exactly because of the option of using custom built kernels, virtualbox 
does not depend on the Debian modules packages, but only recommends them 
(which IMO is correct: the Debian module package will be installed by 
default, but you can skip/remove it if you don't need it).

I don't see how adding source as a fallback serves any real purpose in 
this particular case as you always have the option of installing source 
and building the module manually.

But IMO we do want to have standard modules for virtualbox available in 
stable for the Debian kernels and not force end users to build their own 
kernel modules. Whether those modules should be built as part of l-m-e or 
not is a separate issue.

Cheers,
FJP


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

Re: Bug Sprint results (draft)

[Lucas Nussbaum]

On 31/10/08 at 13:39 +0100, Josselin Mouette wrote:
> The following people definitely deserve cookies. They provided patches
> for long-standing RC issues which are all fixed or soon to be.
>   * Lucas Nussbaum (fr) and Emmanuel Bouthenot (fr) for working
> together on #501800/#496954

Emmanuel did most of the work while I was busy trolling on [EMAIL PROTECTED]
I don't desserve cookies, but he does! :-)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: can a kernel in main depend on firmware in non-free to work?

[Peter Samuelson]

[Alexandre Oliva]
> That's why packages that contain Free Software along with
> documentation under licenses that don't pass the DFSG end up split
> into separate packages.  Keeping the documentation that didn't pass
> the DFSG wasn't deemed acceptable, neither was moving the whole
> package to non-free.

The difference between main and contrib is not at all the same as the
difference between main and non-free.

> > Because the kernel is perfectly usable without the firmwares.
> 
> But how about the specific modules that require them, the ones that
> got this sub-thread started in the first place?  It doesn't make
> sense to me to frame the discussion in such terms as most of Linux is
> useful without the component's dependencies, when what we're talking
> about is the component, not the whole.

This really is about our package dependency relationships.

1) The Social Contract says we will not make the system require the use
   of non-free components.  We interpret this to mean 'main' (i.e.,
   Debian GNU/Linux) needs to be a closure across Depends.

2) We recognize that a lot of free software does depend on non-free
   components - hence our 'contrib' section.  However, we do _not_ say
   that contrib is not free software.  So the reason we have contrib is
   _not_ so that Debian can be only free software, but so that Debian
   can be self-contained.

3) From a technical standpoint, if you have one big package that has
   lots of little executables or plugins or modules, some of which do
   not work unless a third-party component is present, obviously you
   can do it either of two ways:

   3a) main package Suggests: plugin package
   plugin package Depends: third-party package

   3b) full package Suggests: third-party package

   The effect on "user freedom" is exactly the same.  We are shipping
   (in main) only software that meets our licensing requirements.
   Users have the same choice of whether to install the non-free
   software to obtain the corresponding functionality.  The only real
   difference (again, from a technical standpoint) is whether there are
   2 packages to keep track of, or 3.

> > Does the kernel require the firmwares in non-free for execution?
> 
> Portions of it do, for sure.  Those portions are artificially
> packaged together with the rest of Linux.  If that's an argument to
> put something in main rather than contrib, then there's no reason for
> contrib to exist, since all of main+contrib amounts to a single
> "package" called Debian.

It is not artificial; our kernel package follows the same aggregation
as upstream (ftp.kernel.org).  It is true that we could decide to
unbundle some or all modules, for various reasons.  But the bundling is
certainly more convenient, and (as I argue in points 3a / 3b above) I
don't believe it has any real effect on user freedom.

HOWEVER, if we had several packages originally separate, and decided to
bundle them not for technical reasons, but so that a 'contrib' package
could be pulled into 'main', I think that would be wrong.  Because, as
you say, that would be gaming the system, letting a technical decision
be adversely affected by a desire to exploit a loophole in our
interpretation of the Social Contract.  We aren't, or shouldn't be,
looking for loopholes.  We are, or should be, making the best technical
decisions we can, and then ensuring that those decisions are consistent
with our foundation documents.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: Possibility for dependencies against specific kernel modules

[Bastian Blank]

On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote:
> Bastian Blank wrote:
> > 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.
> Exactly because of the option of using custom built kernels, virtualbox 
> does not depend on the Debian modules packages, but only recommends them 
> (which IMO is correct: the Debian module package will be installed by 
> default, but you can skip/remove it if you don't need it).

No, it is not. Recommends are only tried during the first installation,
but this relation is version dependant.

Bastian

-- 
He's dead, Jim.
-- McCoy, "The Devil in the Dark", stardate 3196.1


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

Re: Bug Sprint results (draft)

[Gaudenz Steinlin]

On Fri, Oct 31, 2008 at 01:39:47PM +0100, Josselin Mouette wrote:
 
> The following people deserve a honorable mention for dealing with their
> bugs.
>   * Gaudenz Steinlin for proposing approaches for #488669 (this is
> still work in progress)

Oh thanks for the honorable mention. I will be unable to pursue this myself 
in the next few days, because yesterday heavy snow cut the phone line to my
home and the DSL line is gone with it too. I'm now waiting for the phone 
company to fix the line. Until then I will only have internet access very 
rarely. 

I will summarize my findings to the bug report and hope that someone else
will take up the work. It will also be easyer for you to fix the bug if 
you have console access to the specific SPARC hardware affected by the bug, 
which I have not.

Gaudenz

-- 
Ever tried. Ever failed. No matter.
Try again. Fail again. Fail better.
~ Samuel Beckett ~


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

Re: Bug Sprint results (draft)

[Stefano Zacchiroli]

On Fri, Oct 31, 2008 at 01:39:47PM +0100, Josselin Mouette wrote:
> the lenny Bug Sprint is over. I think it is a mitigated success.
  ^^^
  this

I think it was a great success, it has proven that fun/game is a good
motivation among hackers, and that initiatives like this should be
done more frequently. Thanks again for organizing this.

... hence, given that Lenny hasn't been release yet, when are we gonna
make another one? :)

> The following people definitely deserve cookies. They provided patches
> for long-standing RC issues which are all fixed or soon to be.
>   * Stefano Zacchiroli (fr)

/me willing to prove that:
(1) I was one of the lucky guys with an easy RC to fix
(2) my cookies are nothing special, as the next WINNERs will learn
with their mouths BWAWAHAHAHHAHHA

Cheers.

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


signature.asc
Description: Digital signature

Re: Possibility for dependencies against specific kernel modules

[Frans Pop]

Bastian Blank wrote:
> On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote:
>> Exactly because of the option of using custom built kernels, virtualbox
>> does not depend on the Debian modules packages, but only recommends
>> them (which IMO is correct: the Debian module package will be installed
>> by default, but you can skip/remove it if you don't need it).
> 
> No, it is not. Recommends are only tried during the first installation,
> but this relation is version dependant.

I guess one solution could be to have virtualbox-ose not depend on 
virtualbox-modules, but on virtualbox-ose-modules-$ABI.

But I'd really hate for any solution to this to force me to install 
packages I don't use or need on the system. Maybe virtualbox could also 
build some empty dummy modules package that has a provides which always 
satisfies the virtualbox-ose-modules-$ABI.


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

Re: Bug Sprint results (draft)

[Moritz Muehlenhoff]

Stefano Zacchiroli wrote:
>=2E.. hence, given that Lenny hasn't been release yet, when are we gonna
> make another one? :)

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.

Cheers,
Moritz


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

Bug#504134: ITP: ssvnc -- Enhanced TightVNC viewer with SSL/SSH tunnel helper

[Magnus Holmgren]

Package: wnpp
Severity: wishlist
Owner: Magnus Holmgren <[EMAIL PROTECTED]>

* Package name: ssvnc
  Version : 1.0.20
  Upstream Author : Karl J. Runge <[EMAIL PROTECTED]>
* URL : http://www.karlrunge.com/x11vnc/ssvnc.html
* License : GPL 2
  Programming Lang: C, Shell, Java
  Description : Enhanced TightVNC viewer with SSL/SSH tunnel helper

VNC stands for Virtual Network Computing. It is, in essence, a remote display 
system which allows you to view a 
computing `desktop' environment not only on the machine where it is running, 
but from anywhere on the Internet and from a 
wide variety of machine architectures.

SSVNC is two things:

- An enhanced version of the TightVNC client with support for more encodings 
and color modes, support for x11vnc and 
UltraVNC extensions, dynamic screen resizing, an improved popup menu, etc.

- A GUI that helps set up an SSL (using stunnel) or SSH tunnel to connect to 
the VNC server through, as well as forwarding 
of ports for audio (esound/aRts), SMB, CUPS etc.



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

Re: For those who care about bts-link: call for adoption

[Christoph Berg]

Re: Pierre Habouzit 2008-10-30 <[EMAIL PROTECTED]>
> On Thu, Oct 30, 2008 at 04:52:58PM +, Christoph Berg wrote:
> > Re: Pierre Habouzit 2008-10-30 <[EMAIL PROTECTED]>
> > > Anyways, the information is: I don't intend to maintain or run bts-link
> > > anymore[2], it is up for adoption. If the BTS people wish to inherit the
> > > beast they come first, but any motivated group of people are welcomed.
> > 
> > If the BTS folks don't want it, we should put it into the QA realm.
> 
> Well, I have a small issue with that, in the sense that the QA "team" is
> completely disorganized, as every single DD is de facto a QA team
> member. I'd prefer if there are designated people(s) in charge, even if
> the chosen way to maintain it is to put it on collab-maint and can be
> altered by any DD.

The QA infrastructure usually works better in the long run than many
other 1-person projects because there's more hands to take care. But
of course that won't work if there's not a primary maintainer, so I'd
expect the person moving bts-link to qa.debian.org to also maintain
it.

Christoph
-- 
[EMAIL PROTECTED] | http://www.df7cb.de/


signature.asc
Description: Digital signature

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

[Aurelien Jarno]

On Tue, Oct 21, 2008 at 11:41:14AM +0200, Aurelien Jarno wrote:
> Package: general
> Severity: serious
> Justification: DFSG
> 
> raff.debian.org uses a Compaq Smart 5i RAID card. A flash memory is used
> to store the firmware. While the firmware is freely downloadable (as in
> beer) on HP website [1], we don't have the corresponding source code.
> 
> I suggest that someone works with HP to get the corresponding source
> code. Until we found a solution, I recommend we simply shutdown the
> machine.
> 

Yesterday on raff.debian.org:

| Broadcast message from [EMAIL PROTECTED] (pts/1) (Thu Oct 30 22:29:44 2008):
|
| firmware upgrades to fix raid failure from hell
| The system is going down for reboot NOW!

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net



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

Re: Bug Sprint results (draft)

[Stefano Zacchiroli]

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 :) So
let's generalize it to whatever liquid containing alcohol, and I'm in!
(Still, BeerSprint is a cool name, let's keep it anyhow.)

Cheers.

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


signature.asc
Description: Digital signature

Re: Bug Sprint results (draft)

[John H. Robinson, IV]

Stefano Zacchiroli wrote:
> 
> 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 :) So
> let's generalize it to whatever liquid containing alcohol, and I'm in!
> (Still, BeerSprint is a cool name, let's keep it anyhow.)

There are a lot of local breweries and wineries here in San Diego,
California, USA.

I might recommend the name of SloshBugs ;)

http://www.urbandictionary.com/define.php?term=sloshball

Bug Sloshing Party, anyone?

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: Bug Sprint results (draft)

[Paul Wise]

On Fri, Oct 31, 2008 at 9:39 PM, Josselin Mouette <[EMAIL PROTECTED]> 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


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