Re: Of the use of native packages for programs not specific to Debian.

[Wouter Verhelst]

On Thu, Sep 17, 2009 at 07:46:08AM +0200, Giacomo A. Catenazzi wrote:
> On native package the debian/changelog is also used for upstream
> changelog: upstreams tend to package their packages as native.
[...]
> Thus non debian specific package, which are also native,
> should (must on GPL licensed packages) have a separate
> "upstream" changelog.

That doesn't follow. You're assuming it's going to be impossible to keep
the original debian/changelog file, and/or that the only way to package
something that an upstream has packaged as native is to package it as
non-native.

If I'm an upstream and a Debian maintainer for a particular package, and
a downstream distribution wants to modify my package, then I think it's
fairly reasonable for them to just modify the package, without having to
repackage it entirely.

People fork software *all the time*. This is no different.

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


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

Re: Of the use of native packages for programs not specific to Debian.

[Giacomo A. Catenazzi]

Wouter Verhelst wrote:

On Thu, Sep 17, 2009 at 07:46:08AM +0200, Giacomo A. Catenazzi wrote:

On native package the debian/changelog is also used for upstream
changelog: upstreams tend to package their packages as native.

[...]

Thus non debian specific package, which are also native,
should (must on GPL licensed packages) have a separate
"upstream" changelog.


That doesn't follow. You're assuming it's going to be impossible to keep
the original debian/changelog file, and/or that the only way to package
something that an upstream has packaged as native is to package it as
non-native.


hmm. Do you think we should pack an external package as native, if
upstream (or "upstream distribution") packages it as native?

I think this is not intended by our polict, but OTOH it is the easier
way: we should only take care about version conflicts (automatically
adding a suffix could not be enough on few seldom cases).

But if we pack as non-native (as it should be: we are not upstream),
more problems arises:
we cannot patch anymore debian directory: on 3.0 source format
the original debian dir will disappear, thus removing the
debian/changelog (which is required by GPL for upstream changes).

It is not impossible to solve this problem: we can manually copy the
original changelog to our diff/patches.

So the question is:

Is it really worth to use "native package for programs not
specific to Debian" ?

I still think it is not nice for downstream.




If I'm an upstream and a Debian maintainer for a particular package, and
a downstream distribution wants to modify my package, then I think it's
fairly reasonable for them to just modify the package, without having to
repackage it entirely.


This is the problem with sources 3.0, on non-native packages: we cannot
modify the package, we must repack discarding all original files in debian/



People fork software *all the time*. This is no different.


Yes, but it is not our job to fork packages (freely interpreted from devref 
3.5).

ciao
cate


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

Re: Of the use of native packages for programs not specific to Debian.

[Mike Hommey]

On Thu, Sep 17, 2009 at 09:25:39AM +0200, Giacomo A. Catenazzi wrote:
> But if we pack as non-native (as it should be: we are not upstream),
> more problems arises:
> we cannot patch anymore debian directory: on 3.0 source format
> the original debian dir will disappear, thus removing the
> debian/changelog (which is required by GPL for upstream changes).

What kind of insane upstream that is not debian would put upstream change
log in the *debian*/changelog file ?

Mike


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

Re: [DEP-5] Short license names (was: Re: DEP-5: query about possible inheritence of License:)

[Stefano Zacchiroli]

On Thu, Sep 17, 2009 at 10:55:45AM +0900, Charles Plessy wrote:
> Given that identifiers like ‘Other1’, ’Other2’… are ugly or even confusing, 
> and
> that the machine-readable format has the goal to be very human-readable as
> well, I propose to remove the default to ’other’ from the DEP and leave the
> responsability of dealing with empty first lines to the parsers. Of course, 
> for
> licenses that have no short name proposed by the DEP, the person writing the
> copyright file is free to pick whatever makes sense instead of leaving the
> field empty. You nicely summarised this in the patch you sent previously.

FWIW, that sounds reasonable to me. In fact, that's already the practice
I'm using when encountering weird licenses that needs to be factorized
out in debian/copyright.

> Nevertheless, this leaves us in a situation where the machine-readable format
> can not indicate that a license is derived from a very frequent template such
> as the BSD license. For that case, I think that we could add a ’Similar to’
> qualifier, like in the following example:

Looks unneededly difficult to parse to me, considering that in that
field you already have to parse "boolean license formulae" and the
various postfix decorators (e.g., "+"). Continuing that stile, having a
postfix "-like" sounds more reasonable to me, e.g.: "BSD-like | foo |
bar". That way you will preserve the good parsing property that all
atomic tokens denote a single license.

If you go that way, the DEP text should then be changed to clarify that
all license keywords decorated by a postfix "-like" will need a
mandatory "License:" block (probably you can reuse the mention that was
there for "other").

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Bug#547144: ITP: python-editdist -- small and fast implementation of Levenshtein's edit distance algorithm for Python

[Ehren Kret]

Package: wnpp
Severity: wishlist
Owner: Ehren Kret 


* Package name: python-editdist
  Version : 0.3
  Upstream Author : Damien Miller 
* URL : http://www.mindrot.org/projects/py-editdist/
* License : ISC
  Programming Lang: Python, C
  Description : small and fast implementation of Levenshtein's edit 
distance algorithm for Python

python-editdist is a Python module to calculate the Levenshtein edit distance
between two strings.  It is implemented as a CPython module and is quite fast.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 'jaunty')
Architecture: amd64 (x86_64)


signature.asc
Description: Digital signature

The 'git' Debian package in squeeze

[Gerrit Pape]

Hi,

thanks to Ian Beckwith, the GNU Interactive Tools package 'git' has been
renamed to 'gnuit' in lenny.  In lenny 'git' is a transitional package
that depends on gnuit, in squeeze and sid there's no 'git' package
anymore.

I'm about to provide a new git binary package from the git-core (the
distributed revision control system) source, so that 'apt-get install
git' installs the git content tracker in squeeze.  For people upgrading
from lenny with git (from gnuit) installed, this means the new git (from
git-core) package will be installed even if git-core wasn't installed
before.  I don't think it's that bad, should it be documented in
NEWS.Debian in the new git package nevertheless?

Thanks, Gerrit.


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

Re: Bug#547144: ITP: python-editdist -- small and fast implementation of Levenshtein's edit distance algorithm for Python

[Sandro Tosi]

On Thu, Sep 17, 2009 at 10:25, Ehren Kret  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ehren Kret 
>
>
> * Package name    : python-editdist
>  Version         : 0.3
>  Upstream Author : Damien Miller 
> * URL             : http://www.mindrot.org/projects/py-editdist/
> * License         : ISC
>  Programming Lang: Python, C
>  Description     : small and fast implementation of Levenshtein's edit 
> distance algorithm for Python
>
> python-editdist is a Python module to calculate the Levenshtein edit distance
> between two strings.  It is implemented as a CPython module and is quite fast.

what's the difference with python-levenshtein:

$ apt-cache show python-levenshtein
...
Description: extension for computing string similarities and edit distances
 The Levenshtein module computes Levenshtein distances, similarity ratios,
 generalized medians and set medians of Unicode or non-Unicode strings.
 Because it's implemented in C, it's much faster than the corresponding
 Python library functions and methods.
 .
 The Levenshtein distance is the minimum number of single-character
 insertions, deletions, and substitutions to transform one string into
 another.
 .
 It is useful for spell checking, or fuzzy matching of gettext messages.

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


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

Bug#547162: ITP: nautilus-pastebin -- Nautilus extension to send files to a pastebin

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: nautilus-pastebin
  Version : 0.1.1
  Upstream Author : Alessio Treglia 
* URL : https://launchpad.net/nautilus-pastebin
* License : GPL
  Programming Lang: Python
  Description : Nautilus extension to send files to a pastebin

 nautilus-pastebin is a Nautilus extension written in Python, which allows
 users to upload text-only files to a pastebin service just by right-clicking
 on them.
 .
 After sending the files, a notification will be shown and the paste URL
 copied into the clipboard.
 .
 Users can also add their favorite service just by editing the configuration
 file.

-- System Information:
Debian Release: 5.0
  APT prefers jaunty-updates
  APT policy: (500, 'jaunty-updates'), (500, 'jaunty-security'), (500, 
'jaunty-backports'), (500, 'jaunty')
Architecture: amd64 (x86_64)



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

Re: The 'git' Debian package in squeeze

[Cyril Brulebois]

Gerrit Pape  (17/09/2009):
> I'm about to provide a new git binary package from the git-core (the
> distributed revision control system) source, so that 'apt-get
> install git' installs the git content tracker in squeeze.

Nice. :)

> For people upgrading from lenny with git (from gnuit) installed,
> this means the new git (from git-core) package will be installed
> even if git-core wasn't installed before.  I don't think it's that
> bad, should it be documented in NEWS.Debian in the new git package
> nevertheless?

(I'm not familiar with this very subject but:) Maybe also documented
in the release notes?

Mraw,
KiBi.


signature.asc
Description: Digital signature

RFC: Proposal to improve package configuration upgrades

[Dominique Dumont]

Hello

The other day, I was upgrading cups and dpkg did ask me the usual way
if I wanted to keep my cups config file or take the upstream version.

Like always, I asked for a diff and was quite puzzled because I did
not remember anything about editing this file. Then I remembered that
I did a modification through cups admin web interface.

Previous common story you might say. But for a casual user (like my
mother-in-law which now use Debian Lenny ;-) ), this can be
frustrating:
- I did modify the config through a nice web interface
- during the upgrade, I either have to look at all the gory details of
  cupsd config file or I have to loose my configuration.

I was thinking that this is a typical case where package upgrade
could be better handled with Config::Model help.

So, I've written a wiki page [1] that explains:
- how configuration upgrade are managed by Config::Model
- how to implement such upgrades with Approx example:
  * create a configuration model for approx.conf
  * the patch required for approx package scripts
- how to use a new dh_ tool that will simplify setup of configuration
  upgrade for package based on debhelper (dh_config_model_upgrade). A
  patch for openssh-server is provided.
- the bonus (config GUI)
- the current limitations (*)

To approx and openssh maintainers: Is there something missing that would
prevent you to use Config::Model for your package ?

Other package maintainers: what do you think ? Can this be applied to the
configuration of your packages ?

You can either reply to this mail or directly edit the wiki page [1].

All the best


[1] http://wiki.debian.org/PackageConfigUpgrade

(*) Manoj, I have not attempted a model for sendmail... ;-)

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: RFC: Proposal to improve package configuration upgrades

[Guy Hulbert]

On Thu, 2009-17-09 at 14:11 +0200, Dominique Dumont wrote:
> The other day, I was upgrading cups and dpkg did ask me the usual way
> if I wanted to keep my cups config file or take the upstream version.

This email looks very familiar.  Did you send something quite similar a
few months ago?

I see the wiki page started on: 2009-03-23

but there is no discussion page yet ... perhaps we should use it ?

-- 
--gh



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

Re: RFC: Proposal to improve package configuration upgrades

[Dominique Dumont]

Guy Hulbert  writes:

> On Thu, 2009-17-09 at 14:11 +0200, Dominique Dumont wrote:
>> The other day, I was upgrading cups and dpkg did ask me the usual way
>> if I wanted to keep my cups config file or take the upstream version.
>
> This email looks very familiar.  Did you send something quite similar a
> few months ago?

Yes, one very first stab in debian-devel aroundin February . I was
encouraged by Zach to write some code. I felt that the code alone would
not be enough so I created the wiki page.

I sent a first request for comment of the first draft of the wiki page
in April to debian-perl. Thanks to the comment from Jonas Smedegaard,
this led to some clarification of the specification of a configuration
model and the creation of dh_config_model_upgrade.

Then GSoC happened. Being GSoC mentor did slow down work on
Config::Model and package config upgrade. ;-)

> I see the wiki page started on: 2009-03-23
>
> but there is no discussion page yet ... perhaps we should use it ?

That's a good idea !

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Gerrit Pape  [090917 05:18]:
> Hi,
> 
> thanks to Ian Beckwith, the GNU Interactive Tools package 'git' has been
> renamed to 'gnuit' in lenny.  In lenny 'git' is a transitional package
> that depends on gnuit, in squeeze and sid there's no 'git' package
> anymore.
> 
> I'm about to provide a new git binary package from the git-core (the
> distributed revision control system) source, so that 'apt-get install
> git' installs the git content tracker in squeeze.  For people upgrading
> from lenny with git (from gnuit) installed, this means the new git (from
> git-core) package will be installed even if git-core wasn't installed
> before.  I don't think it's that bad, should it be documented in
> NEWS.Debian in the new git package nevertheless?
> 
> Thanks, Gerrit.

IANADD, but as a user I think you should wait one release before reusing
an old package name for a different package.

Let me say that this specific case does not affect me; I already use
git-core, so there would be no issue for me with an upgrade changing
packages.

But, if I were a gnuit user and not a git-core user, I would find it
annoying (and possibly confusing) when upgrading from lenny to squeeze
to have a new package added that I didn't want and that is completely
unrelated to anything I had already installed simply because a more
popular package wanted to take over the name of a different package that
I was using.

There is also the package version issue.  If the new git (from git-core)
keeps the epoch, then there won't be an issue, as the old git (gnuit)
did not have an epoch.  But in the general case, thought should be given
to any effects of the version numbers of the defunct package compared
with the version of the new, unrelated package with the same name.

...Marvin


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

The 'git' Debian package in squeeze

[Leandro Doctors]

2009/9/17 Marvin Renich :
> * Gerrit Pape  [090917 05:18]:
>> Hi,
>>
>> thanks to Ian Beckwith, the GNU Interactive Tools package 'git' has been
>> renamed to 'gnuit' in lenny.
:-)

>> I'm about to provide a new git binary package from the git-core (the
>> distributed revision control system) source, so that 'apt-get install
>> git' installs the git content tracker in squeeze.
:-)

> Let me say that this specific case does not affect me; I already use
> git-core, so there would be no issue for me with an upgrade changing
> packages.
>
> But, if I were a gnuit user and not a git-core user, I would find it
> annoying (and possibly confusing) when upgrading from lenny to squeeze
> to have a new package added that I didn't want and that is completely
> unrelated to anything I had already installed simply because a more
> popular package wanted to take over the name of a different package that
> I was using.
Perhaps including the version in the dependency helps?

After all:
if version(git) <= LENNY_GIT_VERSION --> git == "GNU Interactive Tools"
if version(git) > LENNY_GIT_VERSION --> git == "Git Version Control
System and Friends"

Right?

L
(IANADD)


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

Re: The 'git' Debian package in squeeze

[Vincent Danjean]

Leandro Doctors wrote:
> 2009/9/17 Marvin Renich :
>> But, if I were a gnuit user and not a git-core user, I would find it
>> annoying (and possibly confusing) when upgrading from lenny to squeeze
>> to have a new package added that I didn't want and that is completely
>> unrelated to anything I had already installed simply because a more
>> popular package wanted to take over the name of a different package that
>> I was using.
> Perhaps including the version in the dependency helps?
> 
> After all:
> if version(git) <= LENNY_GIT_VERSION --> git == "GNU Interactive Tools"
> if version(git) > LENNY_GIT_VERSION --> git == "Git Version Control
> System and Friends"
> 
> Right?

No. You do not need of any external dependency to have the problem :
You have a etch machine with only git
You upgrade to lenny. The git package is upgraded (and pulls gnuit)
You upgrade to squeeze. The git package is 'upgraded' (and pulls git-core).

There is no way APT (or dpkg) knows that git/lenny should be remove
instead of being 'upgraded' in git/squeeze.

Note that adding a release (squeeze) without a git package will not
solve the problem: the git/lenny package will not be removed from
the system without an explicit action of the administrator.
And the administrator can already remove the empty git/lenny package.

  I cannot see a good solution here.

  Regards,
Vincent
-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


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

Re: The 'git' Debian package in squeeze

[Patrick Schoenfeld]

On Thu, Sep 17, 2009 at 05:06:02PM +0200, Vincent Danjean wrote:
>   I cannot see a good solution here.

Well, the obvious solution is to include it in the Release Notes.

Best Regards,
Patrick


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

Bug#547184: ITP: pixelmed -- PixelMed Java DICOM Toolkit

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: pixelmed
  Version : 20090816
  Upstream Author : David Clunie
* URL : http://www.pixelmed.com/
* License : BSD
  Programming Lang: Java
  Description : PixelMed Java DICOM Toolkit

This is a stand-alone DICOM toolkit that implements code for reading and 
creating DICOM data, DICOM network and file support, a database of DICOM 
objects, support for display of directories, images, reports and spectra, and 
DICOM object validation.
The toolkit is a completely new implementation, which does not depend on any 
other DICOM tools, commercial or free. It does make use of other freely 
available pure Java tools for compression and XML and database support.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)



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

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Leandro Doctors  [090917 10:41]:
> 2009/9/17 Marvin Renich :
> > But, if I were a gnuit user and not a git-core user, I would find it
> > annoying (and possibly confusing) when upgrading from lenny to squeeze
> > to have a new package added that I didn't want and that is completely
> > unrelated to anything I had already installed simply because a more
> > popular package wanted to take over the name of a different package that
> > I was using.
> Perhaps including the version in the dependency helps?
> 
> After all:
> if version(git) <= LENNY_GIT_VERSION --> git == "GNU Interactive Tools"
> if version(git) > LENNY_GIT_VERSION --> git == "Git Version Control
> System and Friends"
> 
> Right?
> 
> L
> (IANADD)

Adding the version to which dependency?  How does that prevent
git(lenny) being upgraded to git(squeeze)?

gnuit already Conflicts and Replaces git (< 4.9.2-1).  It also Provides
git.  This Provides should, I believe, be removed for either squeeze or
squeeze+1.  But there is a dummy (real) package git 4.9.4-1 in lenny.
If aptitude (and other package managers) remove git automatically when
upgrading from etch to lenny, then my objection is void, since lenny
users will not have git installed unless they explicitly installed the
dummy package.  But if the upgrade causes both git 4.9.4-1 and gnuit
4.9.4-1 to be installed, then squeeze gnuit should conflict and replace
git (< 4.9.5) so that anyone upgrading to squeeze will have git removed
automatically, and the upgrade to squeeze+1 will not bring in git(-core)
gratuitously.

...Marvin


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

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Vincent Danjean  [090917 11:05]:
> There is no way APT (or dpkg) knows that git/lenny should be remove
> instead of being 'upgraded' in git/squeeze.
> 
> Note that adding a release (squeeze) without a git package will not
> solve the problem: the git/lenny package will not be removed from
> the system without an explicit action of the administrator.
> And the administrator can already remove the empty git/lenny package.
> 
>   I cannot see a good solution here.

If gnuit(squeeze) Conflicts and Replaces git (< 4.9.5) and squeeze does
not have git, then git will be removed on upgrade to squeeze (there is
no git >= 4.9.5).

I do not know how aptitude deals with the automatic/manual flag in this
case, though.  Suppose a user has etch installed with git 4.3.20-10
(marked as manual in aptitude).  The upgrade to lenny will bring in
gnuit 4.9.4-1; I think aptitude will mark it automatic, but I am not
clear how aptitude handles the automatic flag when dealing with a
package that both Conflicts and Replaces a dummy transitional package.
If gnuit(squeeze, currently 4.9.5-1) Conflicts and Replaces git (<
4.9.5), the dummy transitional package will be removed, but since (in
the simple case) nothing else depends on gnuit and it is still marked
automatic, it will also be removed.

...Marvin


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

Re: The 'git' Debian package in squeeze

[Marvin Renich]

* Marvin Renich  [090917 11:40]:
> I do not know how aptitude deals with the automatic/manual flag in this
> case, though.  Suppose a user has etch installed with git 4.3.20-10
> (marked as manual in aptitude).  The upgrade to lenny will bring in
> gnuit 4.9.4-1; I think aptitude will mark it automatic, but I am not
> clear how aptitude handles the automatic flag when dealing with a
> package that both Conflicts and Replaces a dummy transitional package.
> If gnuit(squeeze, currently 4.9.5-1) Conflicts and Replaces git (<
> 4.9.5), the dummy transitional package will be removed, but since (in
^ on upgrade to
  squeeze
> the simple case) nothing else depends on gnuit and it is still marked
> automatic, it will also be removed.


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

Re: The 'git' Debian package in squeeze

[Peter Samuelson]

[Vincent Danjean]
>   I cannot see a good solution here.

Well, except _not_ to abet the hostile takeover of a project name that
has been around since ... I don't know, but the Debian package goes
back to 1997.

I know git is the awesomest thing since tla, but I'm disappointed that
8 or 9 years of seniority did not, in the end, count for anything.

But then, I sided with the Firebird database engine, too.
(Fortunately, so did Mozilla.)


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

Taiwan Mini-DebConf to visit world's tallest building, Google 2009.09.28

[jidanni]

We have added a day trip to the Taiwan Mini-DebConf program, to visit
the Google Corporation, in Taipei 101, the world's tallest building.
http://wiki.debian.org/DebianTaiwan/MiniDebConf2009#Monday2009-09-28


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

Packages that download/install unsecured files

[Christoph Anton Mitterer]

Hi.

Some time ago, I've wrote several bug reports to packages, that download
files from some non-apt-secured sources of the web, and install them.

I got more or less positive feedback from maintainers that happily
accepted my suggestions, to those who thought they were crap and not
necessary ;)


Some days ago Tom Feiner opened #546945 (and CC'ed) me, which proved me
that I'm not the only one concerned about this issues.


So I thought it might be worth to bring them up for discussion here.




CURRENT SITUATION:
One can differ between three classes of packages:
0) Packages who do not download anything from the web.

1) Packages which download stuff but this is just normal data like
pidgin, firefox (I mean html here, not plugins), wget,..

2) Package installation already downloads something and installs this
e.g. some font packages (msttcorefonts) or documentations (susv2/3) do
this.

3) The package provides automatic update scripts (like here), where
content that in principle belongs to the package is replaced/updated.
Many packages do this (clamav-freshclam, rkhunter, tiger, some packages
for firmwares)


Of course we cannot secure case 1.
But we should cover 2 and 3.




WHAT I'D SUGGEST:
On class (2):
Here it is really important. The end-user does not know in advance that
such a package behaves like this. He thinks that he just gets
debian-apt-secured stuff.

I think susv2 and susv3 was an example of such a package, that did not
any checksumming (no I do not want to blame the maintainer here,
actually I like these packages very much):
Although this is just documentation, it adds some space that could be
used by attackers (malicious HTML code, PNG files, etc.)


Those packages should include hashsums of the downloaded files, verify
them and if they don't match:
- the installation should fail (leaving the package in a broken state)
- the pre/postinst should remove all data that was downloaded (and that
is potentially compromised).

I'd even suggest that this should be enforced by the policy.
The policy should also mandate a "good" hash-algo,.. at least SHA-256,
I'd say...


On class (3):
Here it's difficult. I'd say the following:
If the package does this downloading and installing automatically (or
mostly automatically),... it should be REQUIRED to do this via
checksumming (hashes added to the update scripts).
Examples for this can be clamav-freshclam, rkhunter.

If the user really manually invokes some command e.g. update-rkhunter-db
or so,.. it just SHOULD do this checksumming.




POTENTIAL PROBLEMS:
As we see all this is doable; we already have quite a number of
packages, which perfectly check hashes, and fail installation if they
don't match.

It gets however difficult if the data to be secured changes very
often...
For clamav-freshclam it's practically impossible for the maintainer to
provide debian-apt-secured packages with new hashes in time (btw: I
don't know if clamav already does some "internal" verification).
For such packages one should contact upstream, and ask them to add such
a functionality.
As the clamav exmaple shows (if it does not already verification) it can
be a security threat, if the virus-definitions are not signed => an
attacker could simply remove the definitions from the viruses he want's
to use.
The same is the case for the rkhunter weekly DB update example.




WHO SHOULD "CONTROL" THE HASHES/SIGNATURES?:
Apart from those volatile stuff, definitely the Debian maintainer.
What do I mean here? I'll try to give an example:
There's the flashplugin-nonfree package which downloads the most recent
version.
If adobe would provide own signatures (e.g. GPG) the package could
simply use this, to do the checks.
The problem is then of course,.. that Adobe has the power of what can go
in and what not.
I'd suggest, that the maintainer uses the Adobe-key to verify the files,
from which he's creating hashes, that are going into his packages (for
later verification).




FOR CLOSED SOURCE STUFF,... IS IT WORTH AT ALL?:
In the flashplugin example form above, I've suggested, that Debian
should keep the control over the sigs.
But one could even ask if verification in such a closed source thingy is
it worth anyway?
I'd say: Definitely yes.
Although no one can read the source code of those plugin (to tell
whether it has backdoors or not ;) )... we can at least secure that ALL
users have the same binaries of it.
Thus we prevent single users from being attacked by forged versions.
Even if the maintainer itself would have created the hashes from a
forged version,.. we'd probably all notice very soon (as the
verification fails for the rest of the world).
Of course,.. if the attacker managed to replace the upstream version by
his forged one... we're still screwed.






Of course all the above could mean more or less effort (depending on the
specific case),.. but at least it's good to start discussion.



Cheers,
Chris.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a

Re: Packages that download/install unsecured files

[Patrick Matthäi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Christoph Anton Mitterer schrieb:
> Hi.
> 
> Some time ago, I've wrote several bug reports to packages, that download
> files from some non-apt-secured sources of the web, and install them.
> 
> I got more or less positive feedback from maintainers that happily
> accepted my suggestions, to those who thought they were crap and not
> necessary ;)
> 
> 
> Some days ago Tom Feiner opened #546945 (and CC'ed) me, which proved me
> that I'm not the only one concerned about this issues.
> 
> 
> So I thought it might be worth to bring them up for discussion here.

Maybe we should also think about the downloaded files itself.
A firmware for Linux or a plugin for firefox could do realy bad things.

In the case of geoip it is just a data file (like a .svg etc) with no
attacking vector. The attacker could only inject a corrupted database
and geoip will throw errors/false positions.

Is this realy a vector for it?

- --
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkqyj/QACgkQ2XA5inpabMcu2QCcDPhC6W99H+VCyQNbfE5FItiE
MXgAoJko/JL4r7yXSIpnmgrLZKWpMqoI
=mQ9S
-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: The 'git' Debian package in squeeze

[Adam Borowski]

On Thu, Sep 17, 2009 at 05:10:45PM +0200, Patrick Schoenfeld wrote:
> On Thu, Sep 17, 2009 at 05:06:02PM +0200, Vincent Danjean wrote:
> >   I cannot see a good solution here.
> 
> Well, the obvious solution is to include it in the Release Notes.

That would just spam and mud down the Notes.
The "worst case" is be that people will have a not so big package installed. 
Just compare that with what Gnome or KDE does.  And if you have anything
that depends on gettext, you will have musty old crap (CVS) pulled in
through recommends.

Plus, having git is a blessing not a problem :p

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Packages that download/install unsecured files

[calestyo]

On Thu, 17 Sep 2009 21:37:24 +0200, Patrick Matthäi 
wrote:
> Maybe we should also think about the downloaded files itself.
> A firmware for Linux or a plugin for firefox could do realy bad things.
Yes true,.. for firefox this is (IMHO) a very big problem,.. many plugins
out there,.. lots of them are not open source at all, the update goes often
via the upstream website (AFAIK) and not via addons.mozilla.org..
So the ideal way for FF plugins is to have them packaged.


> In the case of geoip it is just a data file (like a .svg etc) with no
> attacking vector. The attacker could only inject a corrupted database
> and geoip will throw errors/false positions.
> 
> Is this realy a vector for it?
1) Generally yes,... because these files are somehow interpreted and most
of those applications have security holes (just think of png and libpng).
But with these kind of programs (rkhunter, clamav) its even more severe
than with libpng,.. some of them run as root,.. while libpng (or similar
things) run mostly as normal user.

2) For geoip it's even more specific,...
geoip data is often used for firewall rules or similar,.. one don't want to
have these data messed up by an attacker,.. this wouldn't just lead to
"false positives".
Of course this does not answer the question, if or how we could trust the
upstream source of this data ;)


Cheers,
Chris,


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

Re: Packages that download/install unsecured files

[Leo "costela" Antunes]

Hi,

Patrick Matthäi wrote:
> Maybe we should also think about the downloaded files itself.
> A firmware for Linux or a plugin for firefox could do realy bad things.
> 
> In the case of geoip it is just a data file (like a .svg etc) with no
> attacking vector. The attacker could only inject a corrupted database
> and geoip will throw errors/false positions.
> 
> Is this realy a vector for it?

GeoIP's database is AFAICT a binary format, which means the library
could theoretically suffer from buffer-overflows and such. If this is
indeed correct, you'd just need apache's mod-geoip, for instance, to put
your server in potential trouble.

Being strict, almost any format can be an attack vector in some way
(phishing sites are another extreme example, and obviously one we
shouldn't try to solve through the packaging system), but I somewhat
agree with Christoph that we could draw the line on packages that
perform automatic installations of binaries from external unchecked sources.

Cheers

-- 
Leo "costela" Antunes
[insert a witty retort here]


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

Bug#547220: general: Lenny Upgrade Documentation Typos

[Ken Schweigert]

Package: general
Severity: minor

While doing my first dist-upgrade I noticed a few typos that 
may cause some confusion to other users.

In the document referenced at:
http://www.debian.org/releases/lenny/i386/release-notes/ch-upgrading.en.html

Section 4.3. Manually unmarking packages
contains the following line:

aptitude unmarkauto $(dpkg-query -W 'kernel-image-2.6.*' | cut -f1)

I believe this should be:

aptitude unmarkauto $(dpkg-query -W 'linux-image-2.6.*' | cut -f1)

Here is the output when I run each of these commands:

ns3:~# dpkg-query -W 'kernel-image-2.6.*'
No packages found matching kernel-image-2.6.*.
ns3:~# dpkg-query -W 'linux-image-2.6.*'
linux-image-2.6.18-4-powerpc2.6.18.dfsg.1-12etch2
linux-image-2.6.18-5-powerpc2.6.18.dfsg.1-13etch6
linux-image-2.6.18-6-powerpc2.6.18.dfsg.1-24etch4
ns3:~#


Also, in Section 4.5.6. Minimal system upgrade
it says to run:

aptitude upgrade

When running this from the command line I get a deprecation warning:

ns3:~# aptitude upgrade
W: The "upgrade" command is deprecated; use "safe-upgrade" instead.
Reading package lists... Done

The upgrade does continuem but may want to update this in the docs.
Thanks!

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

Kernel: Linux 2.6.26-2-powerpc
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Re: Packages that download/install unsecured files

[Patrick Matthäi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Leo "costela" Antunes schrieb:
> Hi,
> 
> Patrick Matthäi wrote:
>> Maybe we should also think about the downloaded files itself.
>> A firmware for Linux or a plugin for firefox could do realy bad things.
>>
>> In the case of geoip it is just a data file (like a .svg etc) with no
>> attacking vector. The attacker could only inject a corrupted database
>> and geoip will throw errors/false positions.
>>
>> Is this realy a vector for it?
> 
> GeoIP's database is AFAICT a binary format, which means the library
> could theoretically suffer from buffer-overflows and such. If this is
> indeed correct, you'd just need apache's mod-geoip, for instance, to put
> your server in potential trouble.

Sure if the library / program itself is vulnerable for it, then it is a
real problem.
I should be more precise:
Is it realy a problem if the user "just" gets a corrupted database?
There are _currently_ no known security issues in this way.
That is what I mean with "realy".

> 
> Being strict, almost any format can be an attack vector in some way
> (phishing sites are another extreme example, and obviously one we
> shouldn't try to solve through the packaging system), but I somewhat
> agree with Christoph that we could draw the line on packages that
> perform automatic installations of binaries from external unchecked sources.
> 
> Cheers
> 


- --
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkqynHQACgkQ2XA5inpabMfiUQCdFf6gjXFwicnax/JB3W0LILlq
ll0AoKCI9Nw0dOj3SPJKKZlWMAWJ1llA
=L6uy
-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: Packages that download/install unsecured files

[Russ Allbery]

 writes:

> Yes true,.. for firefox this is (IMHO) a very big problem,.. many
> plugins out there,.. lots of them are not open source at all, the update
> goes often via the upstream website (AFAIK) and not via
> addons.mozilla.org..  So the ideal way for FF plugins is to have them
> packaged.

Many of those updates are insanely volatile, though.  Things like NoScript
change constantly.

-- 
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

News: l'immigration au Canada

[news]

L’immigration et la citoyenneté canadienne

La population immigrée du Québec

 

Le Recensement de 2006 a montré que 11,5 % de la population totale du Québec
est immigrante, la proportion la plus forte jamais constatée dans l’histoire
de la province. Cette proportion est de presque 20% pour le Canada, de 28,3
% pour l’Ontario et de 27,5 % pour la Colombie-Britannique.  La Région
métropolitaine de Montréal continue de regrouper la grande majorité des
immigrants résidant au Québec, soit 86,9 %.  Le plan stratégique 2008-2012,
prévoit une augmentation importante du nombre des immigrants UNIQUEMENT de
la province du Québec, qui doit passer à 55.000 en 2010. 

Source: Fiche synthèse sur l’immigration au québec – année 2008  du MICC

Comment devenir citoyen canadien? Il faut :

*   Être résident permanent du Canada, 

*   avoir vécu au Canada pendant au moins trois ans, 

*   connaître le français ou l’anglais, 

*   avoir une certaine connaissance du Canada.

Si vous avez des questions ou vous souhaitez immigrer au Québec, simplement
 cliquez ici!

 

English

Immigration in Canada

The census enumerated 6,186,950 foreign-born in Canada in 2006. They
represented one in five of the total population, the highest proportion
since 1931. In 2001, the foreign-born represented 18.4% of the population.

How to become a Canadian citizen? You must :

*   be a permanent resident, 

*   have lived here for at least three years, 

*   know English or French, 

*   learn about Canada.

If you have questions or want to immigrateto Canada,
 apply immediately! 

Cet émail est envoyé exclusivement au candidats inscrits. Pour ne plus
recevoir d'émail de notre part, cliquez sur:
 se désinscrir , this
email is sent only to subscribers. To be removed from our mailing list,
click on:   unsubscribe

**

Theinformation transmitted is intended only for the person or entity to
which  it is addressed and may contain confidential and/or privileged
material. Any   review, retransmission, dissemination or other use of, or
taking of any action   in reliance upon, this information by persons or
entities other than intended recipient is prohibited. If you received this
in error, please contact the sender and delete the material from any
computer.L'information transmise dans ce message est destinée uniquement à
la personne ou l'entité auxquelles elle est adressée et peut contenir du
matériel confidentiel et/ou privilégié.  N'importe quelle revue,
retransmission, diffusion ou toute autre utilisation de cette information
par des personnes ou des entités autres que le destinataire prévu est
interdite. Si vous recevez ceci par erreur, entrez en contact SVP avec
l'expéditeur et supprimez le matériel à partir de n'importe quel ordinateur
ou support d’information.

Transitional (dummy) packages considered silly

[Magnus Holmgren]

When a binary package is renamed or split, as well as if several packages are 
merged under a new name, transitional packages are normally created, which 
depend on the new packages, which in turn Replaces and Conflicts with, and 
possibly Provides, the old packages. I find those dummy packages as silly to 
create as to uninstall after upgrading.

I propose a new control field called e.g. Supersedes that will provide the 
same semantics. In its simplest form, a renamed package will declare that it 
Supersedes the old package name. That will be considered equivalent to 
conflicting with/replacing earlier versions of the superseded package, as well 
as providing a new version of it, just like a dummy package. Multiple packages 
can supersede the same package (but they should probably be the same version), 
and one package can of course supersede many others.

This proposal should be feasible; APT scans all Packages lists searching for 
the best version of a given package to install, doesn't it? so it will be able 
to find the Supersedes fields at the same time.

This would, among other things, solve the git problem; gnuit would supersede 
git, which would tell APT that the latter should be upgraded into the former, 
and that git the VCS is something else entirely.

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 


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

Processed: reassign 547220 to release-notes

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 547220 release-notes
Bug #547220 [general] general: Lenny Upgrade Documentation Typos
Bug reassigned from package 'general' to 'release-notes'.
>
End of message, stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: Packages that download/install unsecured files

[Steve Kemp]

On Thu Sep 17, 2009 at 21:26:38 +0200, Christoph Anton Mitterer wrote:

> CURRENT SITUATION:
> One can differ between three classes of packages:
> 0) Packages who do not download anything from the web.
>
> 1) Packages which download stuff but this is just normal data like
> pidgin, firefox (I mean html here, not plugins), wget,..
>
> 2) Package installation already downloads something and installs this
> e.g. some font packages (msttcorefonts) or documentations (susv2/3) do
> this.
>
> 3) The package provides automatic update scripts (like here), where
> content that in principle belongs to the package is replaced/updated.
> Many packages do this (clamav-freshclam, rkhunter, tiger, some packages
> for firmwares)

  I'd add :

  4) The package downloads insecure code and directly executes it.

  For an example of this see #451303 - which is fixed - but a perfect
  example.

Steve
--


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

Re: Packages that download/install unsecured files

[Tom Feiner]

Patrick Matthäi wrote:
> In the case of geoip it is just a data file (like a .svg etc) with no
> attacking vector. The attacker could only inject a corrupted database
> and geoip will throw errors/false positions.
> 
> Is this realy a vector for it?
> 

I think it there is an attack vector for it.

What the example update scripts (debian/scripts/geolite*.sh) in the geoip
package do is basically:

wget
http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
| gunzip

Anyone who has access to the DNS server used in order to resolve
geolite.maxmind.com can cause the script to download malicious code. And even
 though the script does not execute the code, it does use wget to download it,
and pipes it through gunzip. If any unknown security vulnerabilities exist in
either wget/gunzip/libgeoip then it's possible to use this as an attack vector
- especially if the user puts this script in cron under the root user. (There
are probably many more ways to attack, but this is the most obvious way).

I hope this clarifies why I think we should find a better solution to this 
issue.

Regards,
Tom Feiner



signature.asc
Description: OpenPGP digital signature

Re: Of the use of native packages for programs not specific to Debian.

[Wouter Verhelst]

Sigh.

On Thu, Sep 17, 2009 at 09:25:39AM +0200, Giacomo A. Catenazzi wrote:
> Wouter Verhelst wrote:
> >That doesn't follow. You're assuming it's going to be impossible to keep
> >the original debian/changelog file, and/or that the only way to package
> >something that an upstream has packaged as native is to package it as
> >non-native.
> 
> hmm. Do you think we should pack an external package as native, if
> upstream (or "upstream distribution") packages it as native?

No, of course not. Please don't put any words in my mouth.

What I'm trying to discuss here is that Debian Developers who package
their own software as Debian native packages should be allowed to do so,
if they know what the downsides are. That is not even remotely similar
to upstreams doing the wildest things. I've said so multiple times now.

[...]
> >People fork software *all the time*. This is no different.
> 
> Yes, but it is not our job to fork packages (freely interpreted from
> devref 3.5).

I didn't even come close to saying that.

When downstreams change a Debian-native package, they are in fact
forking our software. That is what I was referring to with the
above-quoted sentence. However, that is not the same, nor does it even
remotely have anything to do, with Debian Developers forking upstream
software.

Of course, if someone packages software for Debian as a native package,
doing so will encourage downstreams to fork their software. That is one
of the downsides of packaging software natively, and again, this should
be documented; but there's nothing inherently wrong with that. If an
upstream were to say that a Debian Developer should stop sending them
patches, and that they instead should just develop their own version,
then that, perhaps, would be somewhat similar. If you really must have
an upstream analogy.

Now, can you please stop twisting this discussion into insanity?

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


signature.asc
Description: Digital signature

Work-needing packages report for Sep 18, 2009

[wnpp]

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

Total number of orphaned packages: 495 (new: 0)
Total number of packages offered up for adoption: 161 (new: 0)
Total number of packages requested help for: 56 (new: 0)

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



No new packages have been orphaned, but a total of 495 packages are
orphaned.  See http://www.debian.org/devel/wnpp/orphaned
for a complete list.



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



For the following packages help is requested:

   apt-cross (#540341), requested 41 days ago
 Description: retrieve, build and install libraries for
   cross-compiling
 Reverse Depends: apt-cross emdebian-buildsupport emdebian-qa
   emdebian-rootfs emdebian-tools libemdebian-tools-perl
 Installations reported by Popcon: 283

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

   asymptote (#517342), requested 202 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 1004

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

   boinc (#511243), requested 252 days ago
 Description: BOINC distributed computing
 Reverse Depends: boinc-app-milkyway boinc-app-seti boinc-dbg
 Installations reported by Popcon: 1616

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

   dctrl-tools (#448284), requested 691 days ago
 Description: Command-line tools to process Debian package
   information
 Reverse Depends: aptfs debian-goodies debtree dlocate
   haskell-devscripts hg-buildpackage libsbuild-perl mlmmj simple-cdd
 Installations reported by Popcon: 12731

   dietlibc (#544060), requested 20 days ago
 Description: diet libc - a libc optimized for small size
 Reverse Depends: libowfat-dev
 Installations reported by Popcon: 221

   dpkg (#282283), requested 1761 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: adacontrol alien alqalam alsa-source am-utils-doc
   apt-build apt-cross apt-src aspell-doc asymptote (334 more omitted)
 Installations reported by Popcon: 85119

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

   emdebian-tools (#540333), requested 41 days ago
 Description: emdebian crossbuilding tool set
 Reverse Depends: emdebian-buildsupport emdebian-qa emdebian-rootfs
   emdebian-tools
 Installations reported by Popcon: 163

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

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

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

   gnat-4.4 (#539562), requested 525 days ago
 Description: help needed to execute test cases
 Reverse Depends: gnat-4.4 libgnat-4.4 libgnat-4.4-dbg libgnatprj4.4
   libgnatprj4.4-dbg libgnatprj4.4-dev libgnatvsn4.4 libgnatvsn4.4-dbg
   libgnatvsn4.4-dev
 Installations reported by Popcon: 12

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

   graphviz (#536245), requested 71 days ago
 Description: rich set of graph drawing tools
 Reverse Depends: anjuta dot2tex frama-c ggobi graphviz graphviz-dev
   libdeps-renderer-dot-perl libgraphviz-dev libgraphviz-perl
   libgv-guile (16 more omitted)
 Installations reported by Popcon: 40640

   grub2 (#248397), requested 1956 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: 

Re: Of the use of native packages for programs not specific to Debian.

[Charles Plessy]

Le Fri, Sep 18, 2009 at 12:51:14AM +0200, Wouter Verhelst a écrit :
> 
> What I'm trying to discuss here is that Debian Developers who package
> their own software as Debian native packages should be allowed to do so

Hi Wouter and everybody,

it seems to me that the difficulties in this discussion come from the fact that
’native’ is used to mean two different things:

 - Packages using a dpkg format called ‘native’.
 - Software made by Debian for Debian.

This creates confusion, as there are arguments in favor of using the format
called ‘native’ for software not specific to Debian, but on the othe hand there
is a general perception that if a package uses a native format, the software
has special ties to Debian. Interestingly, when the format ‘3.0 (git)’ will be
accepted in our archive, there may be a lot of ‘native’ programs that will be
using a non-native package format.

Maybe the problem could simply solved by renaming one of the two concepts?
Native format could be called ‘direct’, or native packages could be called
’original’, for instance. This would help the Project to keep track of what
programs it is upstream for.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


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

Re: Packages that download/install unsecured files

[Michael S Gilbert]

On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote:
> Hi.
> 
> Some time ago, I've wrote several bug reports to packages, that download
> files from some non-apt-secured sources of the web, and install them.

i also started a similar discussion a while back, which was met with
mixed opinion [0].  i tried to lay out the full spectrum of issues
related to this problem, but many just focused on the non-free aspect.
no consensus was reached.

checksums are a good start, but if the data itself is non-free (or
closed or obscured), then how can you be sure it is not malicious?

i think it is a matter of trust, and maybe the key would be that scripts
should only accept the external data if it is signed and hashed by an
authenticated DD's gpg key.

mike

[0] http://lists.debian.org/debian-devel/2009/02/msg00461.html


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

Re: Packages that download/install unsecured files

[Patrick Matthäi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael S Gilbert schrieb:
> On Thu, 17 Sep 2009 21:26:38 +0200 Christoph Anton Mitterer wrote:
>> Hi.
>>
>> Some time ago, I've wrote several bug reports to packages, that download
>> files from some non-apt-secured sources of the web, and install them.
> 
> i also started a similar discussion a while back, which was met with
> mixed opinion [0].  i tried to lay out the full spectrum of issues
> related to this problem, but many just focused on the non-free aspect.
> no consensus was reached.
> 
> checksums are a good start, but if the data itself is non-free (or
> closed or obscured), then how can you be sure it is not malicious?
> 
> i think it is a matter of trust, and maybe the key would be that scripts
> should only accept the external data if it is signed and hashed by an
> authenticated DD's gpg key.

This would be a good option. But I think you do not have access to the
upstream files and also you can not sign them, maybe upstream itself
also do not want to do it.

Hosting them on my own host is also not a good option.

> 
> mike
> 
> [0] http://lists.debian.org/debian-devel/2009/02/msg00461.html
> 
> 


- --
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkqzGJEACgkQ2XA5inpabMf8LgCgiHwsWxk12w91O4ozp2vEwLsD
IuoAoIErTVqIMWd9muwK0tfBWAgycf3n
=r5nE
-END PGP SIGNATURE-


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