Debian vs. Ubuntu source control file

[Xavier Roche]

[ Don't hesitate to redirect me to an already discussed 
solution/thread/FAQ/anything if necessary, but I didn't find anything 
related in recent (months) debian-devel. ]


Hi folks (and happy new year to all DD),

A minor issue (reported by Nick Ellery) with debian vs. ubuntu package 
is that the two package namespaces are not necessarily identical. An 
example is my httrack package, which on Ubuntu depends alternatively on 
abrowser, which is NOT in debian.


See BUG 530031 :


I could depend on abrowser on Debian, but the package doesn't exist, and 
lintian may be a bit annoyed. Besides, we may package in the future 
something called abrowser, which wouldn't be the same package (is that 
possible ? do we enforce "two different packages on debian/ubuntu should 
not have the same name" -- sorry if I am beating a dead horse)


This is the only reason why a patch is needed for all releases on 
ubuntu. The patch () is basically 
a one-liner in the control file (plus changelog and friends):


-Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | mozilla-firefox | www-browser
+Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | abrowser | mozilla-firefox | www-browser


What do you, folks, think of this case ?

(1) Not a very common case, which can be left as is (ie. patch all 
further control files)


(2) We may want to have a namespaced control fields, such as:

Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | mozilla-firefox | www-browser
Ubuntu:Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | abrowser | mozilla-firefox | www-browser


-and/or-

Debian:Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | mozilla-firefox | www-browser
Ubuntu:Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | abrowser | mozilla-firefox | www-browser


We could namespace all possible fields in the control file, introducing 
ubuntu-specific fields that would be ignored by the debian side.


(3) Namespace specific packages ?

Ubuntu:Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
iceweasel | mozilla | firefox | ubuntu:abrowser | mozilla-firefox | 
www-browser


(the dependency checker on our side would then ignore all non-debian 
namespaces)


(4) Ubuntu-specific optional control file ?

ie. an optional ubuntu/control file

(5) Something totally obvious I did not notice yet


Regards,
Xavier



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

Re: "upgrading" my gpg key

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Mo den  4. Jan 2010 um 21:36 schrieb brian m. carlson:
> For maximum long-term security, I recommend a 3072-bit DSA key
> (preferably with SHA-512) or a 4096-bit RSA key.

Hmmm, that advice is a bit odd. RSA is a bit better in security than DSA
so the length of the DSA key has to be a bit longer than the length of
the RSA key to have the same strength. Though the difference are only
little so in practice it makes no real difference.

Regard
   Klaus Ethgen
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBS0MTz5+OKpjRpO3lAQq2BggAjkCM3LDvJcA9YGd+jWnxJvgmwzVqjusW
TTFz7owwlCrse8kUVJnbDLEqZrVnja5jVowGj19yJ7QrnGi0A3KD63xpBhaFdi3Z
JDKp8CEOoHx93rN1oIztMDu7P7AOsb1n7E7TDrIRlRUP4CfYu+Vgy28Suf0T1EAM
secSbpF+/UF7z9q/9sEdGOEgNwcb+thhwOH1ulBNPJgQu9rbInqD6QgHJQmXQANy
vq/ClTCgWL5BQEsZSs9dNJjF5KTMcKtBLMcyQSRJHf+47urktkvMOkT9veaRjuZz
nQHkRKhxjNcCuXWyhP2iUerE2BheiJrh1ZrNnpibNFfD/J4hJBWVcw==
=Recg
-END PGP SIGNATURE-


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

Re: Debian vs. Ubuntu source control file

[David Paleino]

Xavier Roche wrote:

> [..]
> 
> (1) Not a very common case, which can be left as is (ie. patch all
> further control files)
> 
> (2) We may want to have a namespaced control fields, such as:
> 
> (3) Namespace specific packages ?
> 
> (4) Ubuntu-specific optional control file ?
> 
> (5) Something totally obvious I did not notice yet

I remember, some time ago, there has been some discussion about treating 
ubuntu as a "pseudo-arch", so that we could do something like:

Depends: foo | bar [ubuntu]

I also remember this proposal was rejected, or hostaged to say the least, 
because in this case we should provide "pseudo-arches" for every Debian 
derivative -- Ubuntu is a big one, but not the only one out there.

This is my opinion, and not the official position of the project as a whole.

Kindly,
David

-- 
 . ''`.   Debian developer | 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


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

Re: Debian vs. Ubuntu source control file

[Roger Leigh]

On Tue, Jan 05, 2010 at 10:36:33AM +0100, Xavier Roche wrote:
> This is the only reason why a patch is needed for all releases on  
> ubuntu. The patch () is basically  
> a one-liner in the control file (plus changelog and friends):
>
> -Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser |  
> iceweasel | mozilla | firefox | mozilla-firefox | www-browser
> +Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser |  
> iceweasel | mozilla | firefox | abrowser | mozilla-firefox | www-browser
>
> What do you, folks, think of this case ?

I think this is a specific case of a more general problem: we
don't have a mechanism to provide a distribution-wide default
for a virtual package.  The result is that you end to with
dependencies such as this hard-coded into individual packages
(which is ugly, unmaintainable and inconsistent):

  iceape-browser | iceweasel | mozilla | firefox | abrowser | mozilla-firefox | 
www-browser

rather than this:

  www-browser
or this
  default-www-browser

(where default-www-browser is a dependency on e.g. iceweasel|www-browser)

We solved this for mail-transport-agent with default-mta, but it's
a more general (and unsolved) problem for *all* virtual packages.
I did propose (and implement) a "virtual-defaults" package some four
years back which created such a set of metapackage dependencies, but
this wasn't adopted.  However, we do need some system to handle this.
NB: http://people.debian.org/~rleigh/virtual-policy_1.dsc

ajt (IIRC) said work was going on in dpkg to implement a cleaner
solution than the above, but AFAIK this never materialised, and I've
never seen anything more about it.  It would be trivial to update
the above to fold default-mta into it and provide defaults for all
key virtual packages.  This *single* package could then be customised
by derived distributions to provide specific defaults.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Debian vs. Ubuntu source control file

[Daniel Leidert]

Am Dienstag, den 05.01.2010, 10:36 +0100 schrieb Xavier Roche:
> [ Don't hesitate to redirect me to an already discussed 
> solution/thread/FAQ/anything if necessary, but I didn't find anything 
> related in recent (months) debian-devel. ]
> 
> Hi folks (and happy new year to all DD),
> 
> A minor issue (reported by Nick Ellery) with debian vs. ubuntu package 
> is that the two package namespaces are not necessarily identical. An 
> example is my httrack package, which on Ubuntu depends alternatively on 
> abrowser, which is NOT in debian.
> 
> See BUG 530031 :
> 
> 
> I could depend on abrowser on Debian, but the package doesn't exist, and 
> lintian may be a bit annoyed. Besides, we may package in the future 
> something called abrowser, which wouldn't be the same package (is that 
> possible ? do we enforce "two different packages on debian/ubuntu should 
> not have the same name" -- sorry if I am beating a dead horse)
> 
> This is the only reason why a patch is needed for all releases on 
> ubuntu. The patch () is basically 
> a one-liner in the control file (plus changelog and friends):
> 
> -Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
> iceweasel | mozilla | firefox | mozilla-firefox | www-browser
> +Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser | 
> iceweasel | mozilla | firefox | abrowser | mozilla-firefox | www-browser
> 
> What do you, folks, think of this case ?

I have the same issue with e.g. gnome-chemistry-utils. Further Ubuntu
applies a few patches related to their build system in e.g. gnupg or for
their design decisions (gelemental dbg package).

On one side I think: Well, they decided to do things their own way, so
they have carry about fixing my packaging files for their build and
package environment. On the other side it would be of course easier, if
such changes, which will always be applied to Ubuntu only, could be
marked/added somehow to the Debian package. I hope, they time savings
are then spent into *fixing bugs reported to launchpad and reporting
fixes back to us* (my dear Ubuntu developers!!111).

[snip the possible solutions]
I was thinking about similar things.

Maybe the source format v3 is the solution if we can mark changes as
patch-in-debian and patch-in-ubuntu only?

Regards, Daniel


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

Re: Debian vs. Ubuntu source control file

[Fabian Greffrath]

AFAIUI this is the reason why virtual packages have been introduced. 
You cannot - and definitely should not - alternatively depend on each 
and every webbrowser in Debian (or ubuntu), but every webbrowser 
should do "Provides: x-www-browser". So all you have to do is depend 
on the default webbrowser and on the virtual package alternatively, 
e.g. "Depends: iceweasel | x-www-browser" or even "Depends: iceweasel 
| abrowser | x-www-browser" to also cover the ubuntu case.


Cheers,
Fabian

--
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax: +49 (0)234 / 32-14227
E-Mail:  greffr...@leat.ruhr-uni-bochum.de


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

Re: Debian vs. Ubuntu source control file

[Raphael Hertzog]

Hi,

On Tue, 05 Jan 2010, Xavier Roche wrote:
> This is the only reason why a patch is needed for all releases on
> ubuntu. The patch () is
> basically a one-liner in the control file (plus changelog and
> friends):
> 
> -Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser |
> iceweasel | mozilla | firefox | mozilla-firefox | www-browser
> +Depends: ${shlibs:Depends}, webhttrack-common, iceape-browser |
> iceweasel | mozilla | firefox | abrowser | mozilla-firefox |
> www-browser
> 
> What do you, folks, think of this case ?

I would merge the change even if the package doesn't exist.

> (2) We may want to have a namespaced control fields, such as:

Please no. We have proper support for generating different dependencies
depending on the distribution, it's a combination of substvars and
dpkg-vendor.

On Tue, 05 Jan 2010, Daniel Leidert wrote:
> Maybe the source format v3 is the solution if we can mark changes as
> patch-in-debian and patch-in-ubuntu only?

You can have debian/patches/ubuntu.series and
debian/patches/debian.series in the same source package and the right one
is picked depending on /etc/dpkg/origin/default.

But patches are not allowed to modify the debian directory so that only
works for upstream changes.

Cheers,
-- 
Raphaël Hertzog


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

Re: Debian vs. Ubuntu source control file

[Xavier Roche]

Raphael Hertzog a écrit :

What do you, folks, think of this case ?

I would merge the change even if the package doesn't exist.


What about lintian crying in the rain ? More seriously, can we assume 
that we'll never have package name collisions (ie. "foo", if exist on 
two distributions, are guaranteed to be the same package) ?



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

Re: Debian vs. Ubuntu source control file

[Mike Hommey]

On Tue, Jan 05, 2010 at 02:00:46PM +0100, Xavier Roche wrote:
> Raphael Hertzog a écrit :
> >>What do you, folks, think of this case ?
> >I would merge the change even if the package doesn't exist.
> 
> What about lintian crying in the rain ? More seriously, can we
> assume that we'll never have package name collisions (ie. "foo", if
> exist on two distributions, are guaranteed to be the same package) ?

Well, for "abrowser", i doubt we'll ever see something called "abrowser"
that is not "abrowser". OTOH, "abrowser" being quite similar to
iceweasel (unbranded firefox), I don't even see why "abrowser" would end
up in Debian.

Mike

PS: I don't even understand why there is "abrowser" in Ubuntu,
especially considering it depends on firefox and not the other way
around...


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

Re: Debian vs. Ubuntu source control file

[Raphael Hertzog]

On Tue, 05 Jan 2010, Xavier Roche wrote:
> Raphael Hertzog a écrit :
> >>What do you, folks, think of this case ?
> >I would merge the change even if the package doesn't exist.
> 
> What about lintian crying in the rain ?

What tag does it generate?

AFAIK lintian has no knowledge of what package exist or not. And even if
it does, you can override the tag justifying that it exists in ubuntu.
It would be legitimate for me given that it has no negative impact for
Debian.

> More seriously, can we
> assume that we'll never have package name collisions (ie. "foo", if
> exist on two distributions, are guaranteed to be the same package) ?

There's nothing to guarantee this but you can generally assume it
nevertheless IMO.

Cheers,
-- 
Raphaël Hertzog


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

Re: Debian vs. Ubuntu source control file

[Paul Wise]

On Tue, Jan 5, 2010 at 9:12 PM, Raphael Hertzog  wrote:
> On Tue, 05 Jan 2010, Xavier Roche wrote:
>> Raphael Hertzog a écrit :
>> >>What do you, folks, think of this case ?
>> >I would merge the change even if the package doesn't exist.
>>
>> What about lintian crying in the rain ?
>
> What tag does it generate?
>
> AFAIK lintian has no knowledge of what package exist or not.

Presumably he was thinking of debcheck:

http://qa.debian.org/debcheck.php

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Debian vs. Ubuntu source control file

[Lucas Nussbaum]

On 05/01/10 at 13:56 +0100, Raphael Hertzog wrote:
> But patches are not allowed to modify the debian directory so that only
> works for upstream changes.

That's only true with the v3 format. If you stick with v1, you can
patch debian/control at unpack time.

And in both cases, you are free to modify it manually during the build.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Xen support on Squeeze

[Jon Dowland]

I think you are addressing the wrong list. This is
debian-devel, for discussion of Debian development.
Your question is off-topic here. Please try one of
the debian-user mailing lists instead.

As a second point, you have replied to an unrelated
message on debian-devel and referenced the unrelated
messsage in your "References" header as a result.
You also have not set a meaningful subject. These are
all things which mean many people may miss your
message or skip over it altogether.

Finally, when you repost your message to a more
appropriate list, you should include the versions of
the software you are talking about (before and after,
if possible).


-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: Debian vs. Ubuntu source control file

[Raphael Hertzog]

On Tue, 05 Jan 2010, Lucas Nussbaum wrote:
> On 05/01/10 at 13:56 +0100, Raphael Hertzog wrote:
> > But patches are not allowed to modify the debian directory so that only
> > works for upstream changes.
> 
> That's only true with the v3 format. If you stick with v1, you can
> patch debian/control at unpack time.

Well, with v1 debian/control is entirely created by the debian diff
(unless upstream provides it) so there's usually no further patching involved.

With v3, it's provided by debian.tar.gz (and any upstream debian directory
is scratched away) and patching it by debian/patches/* means that you
don't get the same debian directory after unpack than what
is contained in debian.tar.gz and this will lead to problems during
creation of the automatic patch (which is created by diffing an unpacked
copy of the upstream sources with the same debian directory injected and
with patches applied — the patch that modifies the debian dir will fail to
apply on that copy because the change is already applied).

> And in both cases, you are free to modify it manually during the build.

Indeed.

Cheers,
-- 
Raphaël Hertzog


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

Re: "upgrading" my gpg key

[brian m. carlson]

On Tue, Jan 05, 2010 at 11:26:23AM +0100, Klaus Ethgen wrote:
> Am Mo den  4. Jan 2010 um 21:36 schrieb brian m. carlson:
> > For maximum long-term security, I recommend a 3072-bit DSA key
> > (preferably with SHA-512) or a 4096-bit RSA key.
> 
> Hmmm, that advice is a bit odd. RSA is a bit better in security than DSA
> so the length of the DSA key has to be a bit longer than the length of
> the RSA key to have the same strength. Though the difference are only
> little so in practice it makes no real difference.

RFC 4880 states the NIST size requirements for DSA keys.  If NIST
provided a 4096-bit p size, I would recommend that people use that.
Also, GnuPG will not generate a key outside of the range [1024,3072].

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

enabling software rendering in libxine

[Andreas Marschke]

Hi,

applications ddepending on xine or using the phonon-backend-xine backend in 
KDE are currently having problems since features such as videosettings in 
dragonplayer and bangaraang arent working. As reported to me there are 2 
options how to enable this either via software rendering or hardware as far as 
it is able to. Currently this is managed via the hardware option. 
Unfortunately right now only hardware rendering is enabled but doesnt work on 
every piece of graphics-hardware. As this is a feature bug and reported here : 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563265

For this I would like to ask the maintainer if he could enable this or forward 
it to him. 

Sincerely,

Andreas Marschke.


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

Re: dpkg 3.0 (quilt) packages not being accepted?

[Gunnar Wolf]

Rene Engelhard dijo [Tue, Jan 05, 2010 at 02:21:30AM +0100]:
> > libprawn-ruby uses the 3.0 (quilt) format and is built from three
> > tarballs
> > (libprawn-ruby_0.7.1+dfsg.orig.tar.gz,libprawn-ruby_0.7.1+dfsg.orig-pdf-inspector.tar.gz
>  ^
> > and libprawn-ruby_0.7.1+dfsg.orig-ttfunk.tar.gz). It correctly builds
> [...]
> > 
> > Please provide any pointers on what am I doing wrong, or any other
> > failure cases.
> 
> pdf-inspector.
> 
> the hyphen is the problem. dpkg in lenny can't yet do that (and dak
> tries it on lenny). Raphael uploaded a new dpkg for the next point
> release. When that happens and ftp-naster/the buildds get uploaded
> we can use - in the component name. Not now unfortunately :/
> 
> (/me waits for - being allowed, too...)

Confirmed, yesterday night I uploaded the same package with a
pdfinspector component insteaed - and it worked perfectly.

Thanks,

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Bug#563843: ITP: libmoosex-types-varianttable-perl -- Moose extension for a type-constraint based dispatch table

[Jonathan Yu]

Package: wnpp
Owner: Jonathan Yu 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-types-varianttable-perl
  Version : 0.03
  Upstream Author : Yuval Kogman 
* URL : http://search.cpan.org/dist/MooseX-Types-VariantTable/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Moose extension for a type-constraint based dispatch table

MooseX::Types::VariantTable is a Moose extension that implements a simple
dispatch table based on Moose type constraints. Subtypes will be checked
before their parents, meaning that the order of the declaration does not
matter.



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

Re: Debian vs. Ubuntu source control file

[Russ Allbery]

Raphael Hertzog  writes:
> On Tue, 05 Jan 2010, Xavier Roche wrote:

>> What about lintian crying in the rain ?

> What tag does it generate?

> AFAIK lintian has no knowledge of what package exist or not. And even if
> it does, you can override the tag justifying that it exists in ubuntu.
> It would be legitimate for me given that it has no negative impact for
> Debian.

I'm pretty sure Lintian doesn't care.

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


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

Bug#563841: ITP: xylib -- library for reading x-y data from several file formats

[Marcin Wojdyr]

Package: wnpp
Severity: wishlist
Owner: Marcin Wojdyr 

* Package name: xylib
  Version : 0.5
  Upstream Author : Marcin Wojdyr 
* URL : http://www.unipress.waw.pl/fityk/xylib/
* License : LGPL
  Programming Lang: C++
  Description : library for reading x-y data from several file formats

C++ library for reading files that contain x-y data from powder diffraction,
spectroscopy and other experimental methods. The supported formats include:
VAMAS, pdCIF, Bruker UXD and RAW, Philips UDF and RD, Rigaku DAT,
Sietronics CPI, DBWS/DMPLOT, Koalariet XDD and others.

This library will be required for a future version of fityk, which
is already packaged for Debian.  (I'm upstream author of both)



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

Re: Debian vs. Ubuntu source control file

[Xavier Roche]

Russ Allbery wrote :

I'm pretty sure Lintian doesn't care.


Yep, but not debcheck (as Paul Wise corrected), which would produce 
another warning



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

ITP: graphy -- chart generation library for Python

[Miguel Landaeta]

Package: wnpp
Owner: Miguel Landaeta 
Severity: wishlist

* Package name: graphy
  Version : 1.0
  Upstream Author : Google Inc.
* URL : http://code.google.com/p/graphy/
* License : Apache-2.0
  Programming Lang: Python
  Description : chart generation library for Python

Graphy is a simple Python library for generating charts. It tries
to get out of the way and let you just work with your data. It
produces charts using the Google Chart API.


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


-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche


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

Re: Debian vs. Ubuntu source control file

[Joerg Jaspert]

>>> What do you, folks, think of this case ?
>> I would merge the change even if the package doesn't exist.
> What about lintian crying in the rain ? More seriously, can we assume
> that we'll never have package name collisions (ie. "foo", if exist on
> two distributions, are guaranteed to be the same package) ?

It would be wrong to depend on abrowser in Debian, imo.
And no, there is no guarantee that this package might not ever be
something different.

-- 
bye, Joerg
> What would you do if you wanted to retire from the project?
This is far easier than to get in! ;)


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

Re: Debian vs. Ubuntu source control file

[Joerg Jaspert]

> That's only true with the v3 format. If you stick with v1, you can
> patch debian/control at unpack time.

> And in both cases, you are free to modify it manually during the build.

Err, what? debian/control modified during build? Sure not.

-- 
bye, Joerg
 anyone from the MIA team around? tbm?
 sounds nice. how long do you have to be MIA to get into that team? :)
 you need to have a pgp key, I suppose. and no gpg one, and only a bo box
 yes, but it must be expired


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

Re: Debian vs. Ubuntu source control file

[Lucas Nussbaum]

On 05/01/10 at 21:39 +0100, Joerg Jaspert wrote:
> 
> > That's only true with the v3 format. If you stick with v1, you can
> > patch debian/control at unpack time.
> 
> > And in both cases, you are free to modify it manually during the build.
> 
> Err, what? debian/control modified during build? Sure not.

What is preventing it from being modified during the build?

L.


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

Re: Debian vs. Ubuntu source control file

[Russ Allbery]

Xavier Roche  writes:
> Russ Allbery wrote :

>> I'm pretty sure Lintian doesn't care.

> Yep, but not debcheck (as Paul Wise corrected), which would produce
> another warning

Yeah, but debcheck produces warnings about lots of things that aren't
really problems, just things it doesn't understand.  I wouldn't worry too
much about that.

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


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

Re: Debian vs. Ubuntu source control file

[Don Armstrong]

On Tue, 05 Jan 2010, Lucas Nussbaum wrote:
> On 05/01/10 at 21:39 +0100, Joerg Jaspert wrote:
> > 
> > > That's only true with the v3 format. If you stick with v1, you can
> > > patch debian/control at unpack time.
> > 
> > > And in both cases, you are free to modify it manually during the build.
> > 
> > Err, what? debian/control modified during build? Sure not.
> 
> What is preventing it from being modified during the build?

Nothing besides seriously affecting mine and other's sanity if we ever
glance at such packages. DEBIAN/control is an entirely different
matter.


Don Armstrong

-- 
Il semble que la perfection soit atteinte non quand il n'y a plus rien
a ajouter, mais quand il n'y a plus rien a retrancher.
(Perfection is apparently not achieved when nothing more can be added,
but when nothing else can be removed.)
 -- Antoine de Saint-Exupe'ry, Terres des Hommes

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: enabling software rendering in libxine

[Darren Salt]

I demand that Andreas Marschke may or may not have written...

> applications depending on xine or using the phonon-backend-xine backend in
> KDE are currently having problems since features such as videosettings in
> dragonplayer and bangaraang aren't working. As reported to me there are 2
> options how to enable this either via software rendering or hardware as far
> as it is able to. Currently this is managed via the hardware option.
> Unfortunately right now only hardware rendering is enabled but doesnt work
> on every piece of graphics-hardware. As this is a feature bug and reported
> here : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563265

For reference, here's the conversation in #xine on freenode:

 Hi i am using xine as my favourite backend for phonon and its
  quite good. But recently on the debian (squeeze/sid) package
  things such as changing the hue or saturation are not working can
  this be something that happens when you have special build
  options? 
<_ds_>xxtjaxx, see what xvinfo reports.
 _ds_: I havent had a dive at such things before would you be so
  kind and tell me what I should actually look for?
<_ds_>See what XV_* controls are reported for the first adaptor listed.
* _ds_ is assuming that Xv is being used…
 I do not actually know what it is but: http://pastebin.ca/1734099
<_ds_>There you go: no XV_HUE, no XV_SATURATION…
<_ds_>What hw, which driver?
<_ds_>(hmm, actually, looks like there are two Xv adaptors there)
 Its a nv card 
 _ds_: is this something to change at build time?
<_ds_>No.
 so it is a hw issue not xine?
<_ds_>Hardware or the X driver for it.
 thanks for the help!
<_ds_>You can use the eq2 video post-processing plugin, though.
<_ds_>(That does it all in software.)
 And that I can do how?
<_ds_>Wherever the post-plugin chains are configured.
<_ds_>(Don't ask me; I don't use phonon.)
 I dont do anything special with it myself (just using it) but
  thanks though
* xxtjaxx has quit (Remote closed the connection

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army
| + Vermin Media. It's not "nothing to hide" but "you're invading my
privacy".

He is always right who suspects that he makes mistakes.


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

Bug#563865: ITP: python-wifi -- Linux Wireless Extensions in Pure Python

[Henning Heinold]

Package: wnpp
Severity: wishlist
Owner: Henning Heinold 

* Package name: python-wifi
  Version : 0.5.0
  Upstream Author : Sean Robinson 
* URL : http://pythonwifi.wikispot.org/
* License : GPL, LGPL, Creative Commons Attribution License
  Programming Lang: Python
  Description : Linux Wireless Extensions in Pure Python

Python WiFi is a Python module that provides read and write
access to a wireless network card's capabilities using
the Linux Wireless Extensions.



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

Re: Debian vs. Ubuntu source control file

[Steve Langasek]

On Tue, Jan 05, 2010 at 03:52:46PM -0800, Don Armstrong wrote:
> On Tue, 05 Jan 2010, Lucas Nussbaum wrote:
> > On 05/01/10 at 21:39 +0100, Joerg Jaspert wrote:
> > > 
> > > > That's only true with the v3 format. If you stick with v1, you can
> > > > patch debian/control at unpack time.
> > > 
> > > > And in both cases, you are free to modify it manually during the build.
> > > 
> > > Err, what? debian/control modified during build? Sure not.

> > What is preventing it from being modified during the build?

> Nothing besides seriously affecting mine and other's sanity if we ever
> glance at such packages. DEBIAN/control is an entirely different
> matter.

No, it also breaks assumptions about debian/control that the buildds, the
archive, and various supplementary checker tools (e.g., lintian.debian.org)
rely on.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Switch on compiler hardening defaults

[Kees Cook]

On Thu, Dec 24, 2009 at 12:23:01PM +0100, Stefan Fritsch wrote:
> On Thu, 24 Dec 2009, Kees Cook wrote:
> >>>With the new package, the arch-specific logic for hardening defaults
> >>>is in one place, and a maintainer can selectively disable anything they
> >>>don't want on by default.
> >>
> >>This might be a good compromise to get network services hardened
> >>without changing the default build system.  Is there a plan for which
> >
> >That's certainly a viable plan.  This is kind of the approach we took in
> >Ubuntu for the PIE feature.  We also considered packages with a less than
> >stellar security history.  The list of packages built with PIE in Ubuntu
> >is: (see https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/BuiltPIE )
> >
> >amavisd-new apache2 asterisk bind9 cups cyrus-sasl2 dhcp3 dovecot exim4
> >ipsec-tools mysql-dfsg-5.1 nagios3 nagios-plugins ntp openbsd-inetd
> >openldap openssh postfix postgreqsl-8.3 samba sendmail squid wireshark
> >xinetd
> 
> The problem with PIE is that it is not supported by Debian's gdb
> (#346409). That's why I disabled it again for apache2.

There is a maintained (by RedHat) patch for dealing with PIE.  I already
maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
the gdb maintainer doesn't want it until it's in upstream.  I, obviously,
think that's ridiculous.  PIE works and is useful.  Blocking its rollout
because gdb's support for it isn't upstream just furthers the catch-22.

> IIRC, there were also some apps (python?) that have performance
> problems with PIE. Therefore, PIE should not be switched on by
> default yet.

Yes, some programs show slow-down on i386 and other architectures with
limited registers.  Those packages are exceptions, and should just
disable PIE in their build when they add hardening-includes:
DEB_BUILD_HARDENING_PIE:=0

-Kees

-- 
Kees Cook@debian.org


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

Re: Debian vs. Ubuntu source control file

[Steve Langasek]

On Tue, Jan 05, 2010 at 12:39:40PM +0100, David Paleino wrote:
> I remember, some time ago, there has been some discussion about treating 
> ubuntu as a "pseudo-arch", so that we could do something like:

> Depends: foo | bar [ubuntu]

> I also remember this proposal was rejected, or hostaged to say the least, 
> because in this case we should provide "pseudo-arches" for every Debian 
> derivative -- Ubuntu is a big one, but not the only one out there.

More to the point, this causes unpleasant namespacing issues for the [] arch
specifiers.  We shouldn't mash this into the architecture specifier just
because it's there; there are other ways to accomplish this already
(e.g., substvars as mentioned up-thread).

-- 
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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Lintian error on- rpath: Would like an exemption

[Dirk Eddelbuettel]

littler (aka 'r') is a small wrapper around GNU R that Jeff Horner and I
released in 2006 and have been maintaining since.  It is similar to Rscript
(which appeared a little later as part of base R) but implemented differently
-- we query a lot of the environment at build time and encode this.  And we
also use an -rpath against R's main dynamic library.  As a consequence, we
start faster than either Rscript or R.

And I was about to make a new upstream release, but now see

E: littler: binary-or-shlib-defines-rpath ./usr/bin/r

and can no longer override this.  This is too strict as littler has only one
purpose purpose: wrap around R for faster and lighter starts in scripting,
direct evaluation, one-liner etc.

And on Debian I can control where R lives, depend on the package etc pp.
This is a legitimate use of -rpath, and I would like to upload this.  Without
getting the package rejected.  Can I?

Dirk
 
-- 
Three out of two people have difficulties with fractions.


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

Re: Lintian error on- rpath: Would like an exemption

[Dirk Eddelbuettel]

Never mind. Lintian 1, Dirk 0 -- I actually had one redundant / empty entry in
there which was a minor bug.  Now fixed, and 0.1.3 should be on its merry ways
shortly.

Dirk




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

Re: Switch on compiler hardening defaults

[Paul Wise]

On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook  wrote:

> There is a maintained (by RedHat) patch for dealing with PIE.  I already
> maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
> the gdb maintainer doesn't want it until it's in upstream.  I, obviously,
> think that's ridiculous.  PIE works and is useful.  Blocking its rollout
> because gdb's support for it isn't upstream just furthers the catch-22.

It is perfectly reasonable to reject patches until they are upstream.
I personally will never add patches to Debian without either
committing them upstream myself or some indication that they already
have been or will be accepted upstream. IIRC the Debian kernel team
has similar policies. Why hasn't RedHat upstreamed the patch? They are
usually good about doing that. Perhaps you could push them to do so.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Switch on compiler hardening defaults

[Michael Gilbert]

On Wed, 6 Jan 2010 11:01:01 +0800 Paul Wise wrote:

> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook  wrote:
> 
> > There is a maintained (by RedHat) patch for dealing with PIE.  I already
> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
> > the gdb maintainer doesn't want it until it's in upstream.  I, obviously,
> > think that's ridiculous.  PIE works and is useful.  Blocking its rollout
> > because gdb's support for it isn't upstream just furthers the catch-22.
> 
> It is perfectly reasonable to reject patches until they are upstream.
> I personally will never add patches to Debian without either
> committing them upstream myself or some indication that they already
> have been or will be accepted upstream. IIRC the Debian kernel team
> has similar policies. Why hasn't RedHat upstreamed the patch? They are
> usually good about doing that. Perhaps you could push them to do so.

While normally I would agree with your logic, when it comes to security
I think a more cautious logic must prevail.  Remember that item 4 of
the social contract states that: "Our priorities are our users and free
software."  An aspect of that guidance is providing high quality
security for those users.  Hence, when a feature improves security (or
provides additional harding) the convenience factor of not differing
from upstream should be considered a lower priority than normal.

Best wishes,
Mike


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

Re: Switch on compiler hardening defaults

[Kees Cook]

Hi,

On Wed, Jan 06, 2010 at 11:01:01AM +0800, Paul Wise wrote:
> On Wed, Jan 6, 2010 at 9:20 AM, Kees Cook  wrote:
> 
> > There is a maintained (by RedHat) patch for dealing with PIE.  I already
> > maintain a delta for this in Ubuntu, but as you can see in the gdb bug,
> > the gdb maintainer doesn't want it until it's in upstream.  I, obviously,
> > think that's ridiculous.  PIE works and is useful.  Blocking its rollout
> > because gdb's support for it isn't upstream just furthers the catch-22.
> 
> It is perfectly reasonable to reject patches until they are upstream.
> I personally will never add patches to Debian without either
> committing them upstream myself or some indication that they already
> have been or will be accepted upstream. IIRC the Debian kernel team
> has similar policies. Why hasn't RedHat upstreamed the patch? They are
> usually good about doing that. Perhaps you could push them to do so.

Normally, I'd totally agree.  I do not know why RedHat has chosen to carry
the PIE patches for 5 years[1], but they have.  I[2] and others[3]
have asked over the years, but no one with a deep enough understanding
of the affected code has had the time to get it upstream.

That said, the patches[4] in RedHat have a full test-suite associated with
them.  They're applied after their massive Archer patchset[5], so I had to
fiddle pretty hard to get the PIE support working in the Debian package.

As seen at the end of the Ubuntu gdb series file:

# RH stack that seems to be needed for sane PIE handling
gdb-6.3-test-pie-20050107.patch
gdb-6.5-bz203661-emit-relocs.patch
gdb-workaround-rh-stack-on.patch
gdb-6.6-buildid-locate.patch
gdb-6.3-pie-20050110.patch
gdb-workaround-rh-stack-off.patch

-Kees

[1] https://bugzilla.redhat.com/show_bug.cgi?id=130423
[2] http://sourceware.org/ml/gdb-patches/2008-05/msg00269.html
[3] http://sourceware.org/ml/gdb/2006-08/msg00188.html
[4] http://cvs.fedora.redhat.com/viewvc/devel/gdb/
[5] http://fedoraproject.org/wiki/Features/Archer

-- 
Kees Cook@debian.org


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

Re: Debian vs. Ubuntu source control file

[Lucas Nussbaum]

On 05/01/10 at 16:31 -0800, Steve Langasek wrote:
> On Tue, Jan 05, 2010 at 03:52:46PM -0800, Don Armstrong wrote:
> > On Tue, 05 Jan 2010, Lucas Nussbaum wrote:
> > > On 05/01/10 at 21:39 +0100, Joerg Jaspert wrote:
> > > > 
> > > > > That's only true with the v3 format. If you stick with v1, you can
> > > > > patch debian/control at unpack time.
> > > > 
> > > > > And in both cases, you are free to modify it manually during the 
> > > > > build.
> > > > 
> > > > Err, what? debian/control modified during build? Sure not.
> 
> > > What is preventing it from being modified during the build?
> 
> > Nothing besides seriously affecting mine and other's sanity if we ever
> > glance at such packages. DEBIAN/control is an entirely different
> > matter.
> 
> No, it also breaks assumptions about debian/control that the buildds, the
> archive, and various supplementary checker tools (e.g., lintian.debian.org)
> rely on.

Modifying the source stanza is debian/control is clearly a bad idea. But
for binary stanzas, debian/control is only a template from which
DEBIAN/control is generated. If tools get information about binary
packages using debian/control, then it's probably a bug (lintian is a
different case, because it analyzes the build process itself, and makes
assumptions about what the maintainer is doing. However, misleading
lintian into thinking something about your package is not a serious
issue).

Anyway, to avoid modifying debian/control directly, it's easy to add an
additional substvar (ubuntu:Browser?):
debian/control:
Depends: [...], iceweasel | ${ubuntu:Browser}

debian/rules:
 if dpkg-vendor --is ubuntu; then \
   echo "ubuntu:Browser=abrowser" >> debian/feed2imap.substvars ;\
 fi
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Debian vs. Ubuntu source control file

[Russ Allbery]

Lucas Nussbaum  writes:

> Modifying the source stanza is debian/control is clearly a bad idea. But
> for binary stanzas, debian/control is only a template from which
> DEBIAN/control is generated. If tools get information about binary
> packages using debian/control, then it's probably a bug (lintian is a
> different case, because it analyzes the build process itself, and makes
> assumptions about what the maintainer is doing. However, misleading
> lintian into thinking something about your package is not a serious
> issue).

Lintian tries to keep its analysis of debian/control to only those things
that it can't figure out for one reason or another from the generated
*.dsc or debian/CONTROL files precisely because doing that parsing and
drawing inferences from it are tricky.

> Anyway, to avoid modifying debian/control directly, it's easy to add an
> additional substvar (ubuntu:Browser?):
> debian/control:
> Depends: [...], iceweasel | ${ubuntu:Browser}

> debian/rules:
>  if dpkg-vendor --is ubuntu; then \
>echo "ubuntu:Browser=abrowser" >> debian/feed2imap.substvars ;\
>  fi

Yeah, that's what I was thinking of suggesting.

I am personally not horribly fond of a package building differently on
Debian or Ubuntu via only this mechanism, though.  I think it violates a
very important invariant:  the same package with the same version number
will have the same contents.  It's normally possible to freely mix Debian
and Ubuntu packages provided that the dependencies are met, but if the
Debian and Ubuntu packages have different contents despite being
indistinguishable from the perspective of the package manager, that makes
it extremely difficult to do that.  Now, every system must be exclusively
Debian or Ubuntu or risk getting inconsistent packages that can't be
distinguished from each other.

Maybe there's some way that could also be addressed, such as by having the
source package build binary packages with a different version number
depending on what platform on which they're built?  Add "ubuntu" to the
end of the source version number to form the binary version number if
built on Ubuntu, for instance?

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


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