Re: Bug#561868: ITP: piwigo -- photo gallery software for the web

[Andreas Tille]

On Sun, Dec 20, 2009 at 11:14:22PM +0100, Nicolas Roudaire wrote:
> 
> * Package name: piwigo
>   Version : 2.0.7
>   Upstream Author : Pierrick LE GALL 
> * URL : http://piwigo.org/
> * License : GPL
>   Programming Lang: PHP
>   Description : photo gallery software for the web
> 
> Piwigo is a photo gallery software for the web, built by an active community
>  of users and developers. Extensions make Piwigo easily customizable.
> 
>  Features:
>   - localization in english, french, german, spanish, italian, nederlands, 
> portuguese, ...
>   - tags
>   - permissions on photos and categories
>   - virtual category allowing picture to be in multiple categories
>   - meaningful URLs
>   - user comments and rating
>   - use of iptc and exif metadatas
>   - notification of news by email or RSS feed
>   - best rated, most view pictures
>   - web api allowing requests or administration from other applications.

That's a quite interesting package because I intend to implement such
gallery software soonish.  Could you please do some comparison against
ansel1 which is just inside Debian.  I'd be interested how both compare
to have some help for the decision which one to use.

Kind regards

Andreas.

-- 
http://fam-tille.de


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

Re: [RFC] DEP-6: Meta-Package debian/control field

[David Paleino]

Steve Langasek wrote:

> On Sun, Dec 20, 2009 at 09:30:04PM +0100, David Paleino wrote:
>> > Ubuntu defines a special archive section, 'metapackages', which results
>> > in special tagging/handling of the Depends and Recommends of the
>> > package so
>> > that they're not autoremoved if the metapackage is removed.  This is
>> > implemented in the high-level package management tools.
> 
>> Well, our proposal prospects something different: the metapackage is not
>> removed (thus everything else is not autoremoved) if one of its Meta-
>> Depends/Depends is removed.
> 
> From what I can tell, the only difference between the two implementations
> is compatibility with disabling installation of Recommends by default.

And, how do you achieve that?
I mean, meta-packages should *always* have their Recommends installed, 
otherwise they have no point in existing.
If we use Recommends instead of Depends, that becomes configurable with 
APT::Install-Recommends (or similar), and we totally miss the point of this 
DEP (and of meta-packages).

> I don't think this is a good rationale for adding yet another package
> relationship field.  The Recommends field is *already* defined in Policy
> to have the behavior you're looking for (installed by default but not a
> hard requirement), and I don't see any reason that metapackages should
> need the added complexity of a different field.

Then, how do you differentiate between "genuine" Recommends and "meta-
package" Recommends?
I only see two ways: Meta-Package: yes (but, like Daniel pointed out, 
changing the behaviour of a field basing on another doesn't seem so clean), 
or Meta-Depends (or whatever you want to call that).

>> > In this scenario, with Recommends installed by default (the only sane
>> > model),
> 
>> On my host, Recommends are not installed by default, and this is
>> configurable. A similar configuration, and meta-packages using Recommends
>> instead of Depends/Meta-Depends, would render them pretty useless.
> 
> There are good reasons for it to be configurable:
> 
> - it's useful for debugging purposes

In what ways? But this is getting OT now :)

> - in cases of specific packages, disabling recommends-by-default and then
>   hand-selecting the ones you want may be more efficient than installing
>   all recommends and selecting those to remove afterwards

This should be on a per-package basis, don't you believe?

  # apt-get --no-install-recommends install metapackage

But then again, I don't see a point here either.

What's the use of a metapackage if you only choose 2-3 from, say, 20-30 
"dependencies"?
You'd better go with selecting those 2-3 directly. At least IMHO :)

Try to change your POV from the uber-user, who knows how to install "base" 
packages and let others be pulled in, to the low-level users, which want 
"gnome" installed, but don't want "rhythmbox" nor "banshee" installed. This 
is what they do (writing the CLI version, but they're likely to use 
something like Synaptic):

  # aptitude install gnome
  # aptitude remove rhythmbox

OOPS! Since aptitude does "autoremove" by default, the users suddenly get 
asked to remove all their desktop environments. How many requests of this 
type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and 
that's why I drafted this DEP in the first place.

Definitely no, I don't think this is a marginal situation not worth doing 
some implementation work. (and I could help making patches, where I can)

> - it's how we want buildds and developer build chroots to be configured,
> so
>   that build-dependencies aren't overlooked because they're usually
>   installed as recommends

Uh?
Could you explain a bit more?

> But that doesn't mean it makes sense for users to set this setting
> globally on their systems, or to design further complexity into our
> package manager to accomodate such configurations.

How would this be any "complex"?
I mean, maybe handling a "blacklist" might be, but we're already having the 
"auto-installed" vs. "manually-installed" lists, so adding a new one 
shouldn't be too hard.

Also, since Meta-Depends would act as Recommends, with the only difference 
that it's not configurable, I can't see any complexity in changing the code 
from (pseudo-code):

  if field == "Recommends":
# do something, and handle APT::Install-Recommends

to:

  if field in ["Recommends", "Meta-Depends"]:
# do something
if field == "Recommends":
  # handle APT::Install-Recommends

?

This might be a bit simplistic, I agree, but I hope this clears my point.

>> > the vast majority of metapackage dependencies are moved from
>> > Depends to Recommends, so you can remove those Recommends manually
>> > without forcing removal of the metapackage;
> 
>> This already happens now, or did I miss something?
> 
> The difference is that the packages that are now listed as Depends would
> be moved to Recommends.

And they could be not installed at all, depending on the user's 
configuration, which 

Re: DEP-5: binary package affected by license $foo

[Steve Langasek]

Hello,

On Wed, Nov 04, 2009 at 11:47:52PM +0100, Frank Lin PIAT wrote:
> As I was updating the copyright file in a package, I wondered if it
> would be useful to add an optional header (named "Binary-Package" or
> whatever), to state which binary package is using that file and license.

> The rational is that sooner or later, we will want to use the
> machine-interpretable copyright file to validate packages freeness,
> license compatibilities and so on.

> Some sample scenario:

> Exemple 1:
> > File: doc/info/*
> > License: GFDL-NON-FREE
> > Binary-Package: none
> The package contains a file covered by a not-so-free license, but
> that file isn't used to build the binary file. And the file isn't
> shipped in the binary files.

I agree that it would be desirable to be able to record the copyright on a
per-binary-package basis.  Ideally, though, wouldn't we extract this
information automatically?  Realistically, any information of this sort
that gets recorded in debian/copyright is going to become outdated because
maintainers are going to forget to update this field when files are
moved between binary packages; and unlike sourceful copyright/license
information, there's no easy way to generate third-party reports about
possible mismatches for binary package copyright info.

Perhaps what would be best here is to apply the same format to binary
packages, but support "Files" fields referring to the contents of the binary
packages rather than the source packages; and then construct tools to
calculate the binary licenses based on, e.g., makefile dependencies?

Cheers,
-- 
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: [RFC] DEP-6: Meta-Package debian/control field

[Roland Mas]

David Paleino, 2009-12-21 09:13:17 +0100 :

[...]

> I mean, meta-packages should *always* have their Recommends installed,
> otherwise they have no point in existing.

  If it's *always*, then… isn't your proposal pointless?  If it's merely
a *should*, then Recommends is a fine solution.

[...]

> What's the use of a metapackage if you only choose 2-3 from, say, 20-30 
> "dependencies"?
> You'd better go with selecting those 2-3 directly. At least IMHO :)

  And that's what we have tasks for.

> Try to change your POV from the uber-user, who knows how to install "base" 
> packages and let others be pulled in, to the low-level users, which want 
> "gnome" installed, but don't want "rhythmbox" nor "banshee" installed. This 
> is what they do (writing the CLI version, but they're likely to use 
> something like Synaptic):
>
>   # aptitude install gnome
>   # aptitude remove rhythmbox
>
> OOPS! Since aptitude does "autoremove" by default, the users suddenly get 
> asked to remove all their desktop environments. How many requests of this 
> type have you seen on IRC, mailing lists, Usenet? I've seen *TOO MANY*, and 
> that's why I drafted this DEP in the first place.
>
> Definitely no, I don't think this is a marginal situation not worth
> doing some implementation work. (and I could help making patches,
> where I can)

  Then I suggest you just help converting the gnome metapackage to a
task, since this'll work with no intrusive changes in our tools.

Roland.
-- 
Roland Mas

Neko-no me-to, onna-gokoro-to, aki-no-sora. -- Proverbe japonais
(« Souvent femme varie, bien fol est qui s'y fie. »)


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

Re: Bug#561868: ITP: piwigo -- photo gallery software for the web

[Nicolas]

Hi,

thanks for your interest in piwigo.

> That's a quite interesting package because I intend to implement such
gallery software soonish.  Could you please do some comparison against
ansel1 which is just inside Debian.  I'd be interested how both compare
to have some help for the decision which one to use.

To be honest, I didn't know about ansel before you ask for comparaison. I
search for that application. I saw screenshot and features and it looks good
but I didn't find a simple way to install it. Maybe I forgot something.
I'm not sure I'm the right person to do an honest compaison because I'm
involved in piwigo development ! But I can say one thing. I think piwigo is
simple : simple to install and very intuitive to use. We embrassed KISS
concept.

Regards,
Nicolas

2009/12/21 Andreas Tille 

> On Sun, Dec 20, 2009 at 11:14:22PM +0100, Nicolas Roudaire wrote:
> >
> > * Package name: piwigo
> >   Version : 2.0.7
> >   Upstream Author : Pierrick LE GALL 
> > * URL : http://piwigo.org/
> > * License : GPL
> >   Programming Lang: PHP
> >   Description : photo gallery software for the web
> >
> > Piwigo is a photo gallery software for the web, built by an active
> community
> >  of users and developers. Extensions make Piwigo easily customizable.
> >
> >  Features:
> >   - localization in english, french, german, spanish, italian,
> nederlands, portuguese, ...
> >   - tags
> >   - permissions on photos and categories
> >   - virtual category allowing picture to be in multiple categories
> >   - meaningful URLs
> >   - user comments and rating
> >   - use of iptc and exif metadatas
> >   - notification of news by email or RSS feed
> >   - best rated, most view pictures
> >   - web api allowing requests or administration from other applications.
>
> That's a quite interesting package because I intend to implement such
> gallery software soonish.  Could you please do some comparison against
> ansel1 which is just inside Debian.  I'd be interested how both compare
> to have some help for the decision which one to use.
>
> Kind regards
>
>Andreas.
>
> --
> http://fam-tille.de
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>

Re: [RFC] DEP-6: Meta-Package debian/control field

[David Paleino]

Roland Mas wrote:

> David Paleino, 2009-12-21 09:13:17 +0100 :
> 
> [...]
> 
>> I mean, meta-packages should *always* have their Recommends installed,
>> otherwise they have no point in existing.
> 
>   If it's *always*, then… isn't your proposal pointless?  If it's merely
> a *should*, then Recommends is a fine solution.

No, I probably misworded my intention there.

A meta-package should always have their Recommends/Depends/whatever 
installed, and shouldn't get uninstalled when one of these gets removed 
(either, this removed one should be "blacklisted" someway)

> [...]
> 
>> What's the use of a metapackage if you only choose 2-3 from, say, 20-30
>> "dependencies"?
>> You'd better go with selecting those 2-3 directly. At least IMHO :)
> 
>   And that's what we have tasks for.

"Tasks" aren't for this, I suppose.

> [..]
> 
>   Then I suggest you just help converting the gnome metapackage to a
> task, since this'll work with no intrusive changes in our tools.

So you're suggesting me to also do a "wicd" task.
In experimental I have "wicd" depending on wicd-daemon + wicd-curses|wicd-
gtk -- (it's a simple case, where the user might manually choose the 
components, but it's good for the sake of exampling).
A user having "wicd" installed now, and upgrading to experimental, might 
want to remove one of the components:

  # apt-get --purge remove wicd-curses

This will also uninstall "wicd", and mark wicd-daemon and wicd-gtk for 
autoremoval.

I don't think we should escalate metapackages to tasks, sorry.

-- 
 . ''`.   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: [RFC] DEP-6: Meta-Package debian/control field

[David Paleino]

David Paleino wrote:

> [..]
> So you're suggesting me to also do a "wicd" task.
> In experimental I have "wicd" depending on wicd-daemon + wicd-curses|wicd-
> gtk -- (it's a simple case, where the user might manually choose the
> components, but it's good for the sake of exampling).

As explained on IRC, I might have pushed the example a bit had here, but I 
suppose from a pkg manager POV it's the same.

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: Bug#561868: ITP: piwigo -- photo gallery software for the web

[Andreas Tille]

On Mon, Dec 21, 2009 at 09:37:02AM +0100, Nicolas wrote:
> 
> To be honest, I didn't know about ansel before you ask for comparaison. I
> search for that application. I saw screenshot and features and it looks good
> but I didn't find a simple way to install it. Maybe I forgot something.

My guess is that

apt-get install ansel1

would do the trick.  If not filing an apropriate bug report would be a
reasonable action.

> I'm not sure I'm the right person to do an honest compaison because I'm
> involved in piwigo development ! But I can say one thing. I think piwigo is
> simple : simple to install and very intuitive to use. We embrassed KISS
> concept.

I have no problem with a 'biased' comparison.  If you are upstream
developer and Debian maintainer this at least is a good thing regarding
keeping the Debian package in sync with upstream.  This might be even
more a reason to have a deeper look on Ansel to get new ideas perhaps.

Kind regards

Andreas.

-- 
http://fam-tille.de


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

Bug#508644: Sorting out mail-transport-agent mess

[Holger Levsen]

Hi,

On Samstag, 19. Dezember 2009, Steve Langasek wrote:
> Yes, exim4-daemon-light now Provides: default-mta and a number of packages
> depend on it already.

So let's file bugs on all packages depending on "mail-transfer-agent" instead 
of "default-mta | mail-transfer-agent"? (And make those bugs blocking 
508644.)


regards,
Holger


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

Re: [RFC] DEP-6: Meta-Package debian/control field

[Thomas Goirand]

Steve Langasek wrote:
> In this scenario, with Recommends installed by default (the only sane
> model), the vast majority of metapackage dependencies are moved from Depends
> to Recommends, so you can remove those Recommends manually without forcing
> removal of the metapackage; and you can remove the metapackage without
> causing cascading autoremoval of e.g., half your desktop.

If I may, the "Recommends installed by default" scenario doesn't really
apply here, as the goal here is to remove some dependencies that you
don't want to have, because you want a smaller system. So what you are
asking for is having even MORE packages installed when we want LESS.

Thomas


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

Re: [RFC] DEP-6: Meta-Package debian/control field

[Thomas Goirand]

Steve Langasek wrote:
> From what I can tell, the only difference between the two implementations is
> compatibility with disabling installation of Recommends by default.
> 
> I don't think this is a good rationale for adding yet another package
> relationship field.  The Recommends field is *already* defined in Policy to
> have the behavior you're looking for (installed by default but not a hard
> requirement), and I don't see any reason that metapackages should need the
> added complexity of a different field.

Without this metapackage thing, the only option we have is to have so
many many metapackages, so we can choose one of them. This is not very
nice, because that means that maintainers have to have the will to do it
(which wont ever be the case for all of them). Which is why a real
system to manage this would be nice.

Another point would be that a meta-package could add a new
meta-dependency in a new release.

> Try to change your POV from the uber-user, who knows how to install
"base"
> packages and let others be pulled in, to the low-level users, which want
> "gnome" installed, but don't want "rhythmbox" nor "banshee" installed.
This
> is what they do (writing the CLI version, but they're likely to use
> something like Synaptic):
>
>   # aptitude install gnome
>   # aptitude remove rhythmbox
>
> OOPS! Since aptitude does "autoremove" by default, the users suddenly get
> asked to remove all their desktop environments. How many requests of this
> type have you seen on IRC, mailing lists, Usenet? I've seen *TOO
MANY*, and
> that's why I drafted this DEP in the first place.

EXACTLY! This is not only because of requests, this has annoyed everyone
for a long long time.

>   Then I suggest you just help converting the gnome metapackage to a
> task, since this'll work with no intrusive changes in our tools.

Well, the issue is not ONLY with gnome, there are many many more. For
example the X system installing all drivers, then you want to remove few
of them that you don't care and identify as not for you, but keep all
the rest of "just in case". I see few other examples in packages that I
maintain myself where removing 1 or 2 package could be nice, still
keeping new packages that would come with the metapackage in case of an
upgrade, and giving freedom to users to do what they want.

Andreas Metzler wrote:
> The current proposal is not backwards compatible since it fundamentally
> changes the meaning of Depends. Depends is transitive. If A depends on
> B, and B depends on C. A can rely on functionality proveided by C.
> Your proposal breaks that, since it allows removal of C (assuming B is
> a meta package), keeping it installed in a broken state.
>
> I am not convinced that the gain (easily install KDE without kmail, or
> something like that) is worth this price. It changes a clear relation
> to something that most of the times works as expected, except for some
> special cases.

I do agree that the proposed implementation is bad, and that Depends
should not change meaning. I do like more the Meta-Depends: instead of
Depends: if we want to keep the original idea. How about having a
differentiation about the idea and the implementation in this discussion? :P

Also, I think having a Metapackage: yes field IS a good idea anyway,
even if there's absolutely NOTHING ELSE implemented with it but search
functionalities, which would be very convenient (unless there's also
Meta-Depends, but we could imagine a package that would like the
functionality of Meta-Depends and still not being a Meta-Package and
installing useful files...). Does the majority agree with me on that
point here?

Just my 2 cents, as I wont be the one implementing anything... :)

Thomas


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

Bug#561955: ITP: libmoosex-types-common-perl -- Commonly used type constraints for Moose

[eloy]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyżaniak (eloy)" 


* Package name: libmoosex-types-common-perl
  Version : 0.001000
  Upstream Author : Guillermo Roditi (groditi) grod...@cpan.org
* URL : http://search.cpan.org/dist/MooseX-Types-Common/
* License : Perl: GPL/Artistic
  Programming Lang: Perl
  Description : Commonly used type constraints for Moose

 A set of commonly-used type constraints that do not ship with Moose by
 default.

 Package needed for new version of libcatalyst-perl



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

Re: [RFC] DEP-6: Meta-Package debian/control field

[Steve Langasek]

On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote:
> So you're suggesting me to also do a "wicd" task.
> In experimental I have "wicd" depending on wicd-daemon + wicd-curses|wicd-
> gtk -- (it's a simple case, where the user might manually choose the 
> components, but it's good for the sake of exampling).
> A user having "wicd" installed now, and upgrading to experimental, might 
> want to remove one of the components:

>   # apt-get --purge remove wicd-curses

> This will also uninstall "wicd", and mark wicd-daemon and wicd-gtk for 
> autoremoval.

> I don't think we should escalate metapackages to tasks, sorry.

Special autoremoval handling of metapackages addresses this, without
meddling with the existing package relationship fields.  This could be done
with special handling of 'Section: metapackages', or by adding a new
'Metapackage: yes' field (as I think some would prefer based on comments on
IRC).

Package: wicd
Section: metapackage
Depends: wicd-curses|wicd-gtk, wicd-daemon

# apt-get purge wicd-curses
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  wicd-curses* wicd*
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 57.3kB disk space will be freed.
Do you want to continue [Y/n]?

Those are exactly the correct semantics.  It makes no sense to remove the
depends of a metapackage *and leave the metapackage installed* - what
purpose would that serve?

-- 
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: [RFC] DEP-6: Meta-Package debian/control field

[David Paleino]

Steve Langasek wrote:

> Those are exactly the correct semantics.  It makes no sense to remove the
> depends of a metapackage *and leave the metapackage installed* - what
> purpose would that serve?

Being able to

# apt-get --purge remove wicd

(thus removing any dependency/recommends/anything), without caring for the 
removed parts singularly?

However, seems like on IRC we reached kind of a consensus on the fact that 
metapackages should use Recommends instead of Depends. I plan to do a mass-
bug filing on this issue sooner or later, just need some time to do it :)

I might change this DEP to propose a new field, halfway betwen Recommends 
and Depends (as weasel suggested, Weak-Depends), but haven't carefully 
thought at it yet.

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: [RFC] DEP-6: Meta-Package debian/control field

[Felipe Sateler]

On Mon, 2009-12-21 at 07:52 -0800, Steve Langasek wrote:
> On Mon, Dec 21, 2009 at 09:40:37AM +0100, David Paleino wrote:
> > So you're suggesting me to also do a "wicd" task.
> > In experimental I have "wicd" depending on wicd-daemon + wicd-curses|wicd-
> > gtk -- (it's a simple case, where the user might manually choose the 
> > components, but it's good for the sake of exampling).
> > A user having "wicd" installed now, and upgrading to experimental, might 
> > want to remove one of the components:
> 
> >   # apt-get --purge remove wicd-curses
> 
> > This will also uninstall "wicd", and mark wicd-daemon and wicd-gtk for 
> > autoremoval.
> 
> > I don't think we should escalate metapackages to tasks, sorry.
> 
> Special autoremoval handling of metapackages addresses this, without
> meddling with the existing package relationship fields.  This could be done
> with special handling of 'Section: metapackages', or by adding a new
> 'Metapackage: yes' field (as I think some would prefer based on comments on
> IRC).
> 
> Package: wicd
> Section: metapackage
> Depends: wicd-curses|wicd-gtk, wicd-daemon
> 
> # apt-get purge wicd-curses
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following packages will be REMOVED:
>   wicd-curses* wicd*
> 0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
> After this operation, 57.3kB disk space will be freed.
> Do you want to continue [Y/n]?
> 
> Those are exactly the correct semantics.  It makes no sense to remove the
> depends of a metapackage *and leave the metapackage installed* - what
> purpose would that serve?

In this particular case, none. But in the general case there are reasons
to keep the metapackage installed. For example, I want to try out gnome.
So I install the gnome metapackage. I do not want (say) brasero. But I
still want everything removable by just saying aptitude remove gnome.

-- 
Saludos,
Felipe Sateler



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

Bug#561961: general: add a language-selector like ubuntu

[Chris]

Package: general
Severity: normal


Add a language-selector like ubuntu to check and verify if available 
translation 
packages for installed applications, dictionary to check spelling or 
change system language.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

Bug#561962: general: On desktop enviroments open .deb files with "gksu gdebi-gtk" by default

[Chris]

Package: general
Severity: normal


On desktop enviroments open .deb files with "gksu gdebi-gtk" by default, 
like ubuntu.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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: [RFC] DEP-6: Meta-Package debian/control field

[Rene Engelhard]

On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
> However, seems like on IRC we reached kind of a consensus on the fact that 
> metapackages should use Recommends instead of Depends. I plan to do a mass-
> bug filing on this issue sooner or later, just need some time to do it :)

What sense does that have? apt-get install openoffice.org installing
nothing? (Assuming a system has a senseful configuration and has
the recommends-install thing removed? Ok, OOo is a bad example, let's get a
better one:

mysql-server or postgresql. On (minimal as you can get) servers you don't
want to install recommends, and this would break those, too.
(Yes, they are metapackages)

Grüße/Regards,

Rene
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70


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

Bug#561964: general: add the user also in scanner group by default

[Chris]

Package: general
Severity: normal


By default doesn't enabled my user to use the scanner.
Please add this by default.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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: [RFC] DEP-6: Meta-Package debian/control field

[David Paleino]

Rene Engelhard wrote:

> On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
>> However, seems like on IRC we reached kind of a consensus on the fact
>> that metapackages should use Recommends instead of Depends. I plan to do
>> a mass- bug filing on this issue sooner or later, just need some time to
>> do it :)
> 
> What sense does that have? apt-get install openoffice.org installing
> nothing? (Assuming a system has a senseful configuration and has
> the recommends-install thing removed? Ok, OOo is a bad example, let's get
> a better one:
> 
> mysql-server or postgresql. On (minimal as you can get) servers you don't
> want to install recommends, and this would break those, too.
> (Yes, they are metapackages)

Go tell this to people on IRC ;)

They've been saying that my "auto-recommends off, but I want working 
metapackages" configuration is insane! :P

That's why I wanted to propose a Meta-Depends (or whatever we call that), 
that must only be used by metapackages, and works like Recommends, but is 
not configurable.

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

Bug#561966: general: Centralized configuration for the hinting style and dpi

[Chris]

Package: general
Severity: wishlist


Centralized configuration for the hinting style and dpi so you do not 
have to worry about installing applications to different desktop 
environments.
example: on gnome I had to install "kcontrol" package to set dpi and 
hinting style for my kde applications like gnome. Uncomfortable.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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

Bug#561964: general: add the user also in scanner group by default

[Holger Levsen]

reassign 561964 installation-reports
tags 561964 + moreinfo
thanks

Hi Chris,

thanks for your bugreport. 

On Montag, 21. Dezember 2009, Chris wrote:
> By default doesn't enabled my user to use the scanner.
> Please add this by default.

I believe this is actually the case when you do a default desktop install. Can 
you confirm that this is what you did?


Thanks,
Holger


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

Processed: Re: Bug#561964: general: add the user also in scanner group by default

[Debian Bug Tracking System]

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

> reassign 561964 installation-reports
Bug #561964 [general] general: add the user also in scanner group by default
Bug reassigned from package 'general' to 'installation-reports'.
> tags 561964 + moreinfo
Bug #561964 [installation-reports] general: add the user also in scanner group 
by default
Added tag(s) moreinfo.
> thanks
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

Bug#561966: marked as done (general: Centralized configuration for the hinting style and dpi)

[Debian Bug Tracking System]

Your message dated Mon, 21 Dec 2009 17:42:44 +0100
with message-id <200912211742.51880.hol...@layer-acht.org>
and subject line Re: Bug#561966: general: Centralized configuration for the 
hinting style and dpi
has caused the Debian Bug report #561966,
regarding general: Centralized configuration for the hinting style and dpi
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
561966: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561966
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: wishlist


Centralized configuration for the hinting style and dpi so you do not 
have to worry about installing applications to different desktop 
environments.
example: on gnome I had to install "kcontrol" package to set dpi and 
hinting style for my kde applications like gnome. Uncomfortable.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---
Hi Chris,

On Montag, 21. Dezember 2009, Chris wrote:
> Centralized configuration for the hinting style and dpi so you do not
> have to worry about installing applications to different desktop
> environments.
> example: on gnome I had to install "kcontrol" package to set dpi and
> hinting style for my kde applications like gnome. Uncomfortable.
> Regards.

That is not something Debian should solve, rather it should be solved by 
free-desktop.org, thus closing.


regards,
Holger


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

Bug#561961: marked as done (general: add a language-selector like ubuntu)

[Debian Bug Tracking System]

Your message dated Mon, 21 Dec 2009 17:49:28 +0100
with message-id <200912211749.29307.hol...@layer-acht.org>
and subject line Re: Bug#561961: general: add a language-selector like ubuntu
has caused the Debian Bug report #561961,
regarding general: add a language-selector like ubuntu
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
561961: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561961
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal


Add a language-selector like ubuntu to check and verify if available 
translation 
packages for installed applications, dictionary to check spelling or 
change system language.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---
Hi Chris,

On Montag, 21. Dezember 2009, Chris wrote:
> Add a language-selector like ubuntu to check and verify if available
> translation
> packages for installed applications, dictionary to check spelling or
> change system language.

Closing too, sorry, but this is not the way Debian works. Please file correct 
ITP/RFP bugs and package that application from Ubuntu, once this is done we 
(no, not we, the maintainers of the desktops) can discuss whether to add this 
application to the default packages.


regards,
Holger


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

Bug#561962: marked as done (general: On desktop enviroments open .deb files with "gksu gdebi-gtk" by default)

[Debian Bug Tracking System]

Your message dated Mon, 21 Dec 2009 17:47:51 +0100
with message-id <200912211747.52205.hol...@layer-acht.org>
and subject line Re: Bug#561962: general: On desktop enviroments open .deb 
files with "gksu gdebi-gtk" by default
has caused the Debian Bug report #561962,
regarding general: On desktop enviroments open .deb files with "gksu gdebi-gtk" 
by default
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
561962: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561962
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal


On desktop enviroments open .deb files with "gksu gdebi-gtk" by default, 
like ubuntu.
Regards.

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

Kernel: Linux 2.6.26-2-686 (SMP w/2 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


--- End Message ---
--- Begin Message ---
Hi Chris,

On Montag, 21. Dezember 2009, Chris wrote:
> On desktop enviroments open .deb files with "gksu gdebi-gtk" by default,

sorry, I'm closing this bug report too. Maybe your wishlist bug is sensible 
for GNOME, but definitly not for KDE, so please file bugs against kde or 
gnome, but not against general. 

On a general note, I don't think .deb files should be opened with in installer 
by default, as with the current standard of unsigned .deb files this leaves 
an too easy attack vector for installing broken debs.


regards,
Holger


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

Re: [RFC] DEP-6: Meta-Package debian/control field

[Philipp Kern]

On 2009-12-21, Rene Engelhard  wrote:
> Assuming a system has a senseful configuration and has the recommends-install
> thing removed?

I am not really sure that you could use this to back up your claims, really.

"This declares a strong, but not absolute, dependency.  The Recommends field
should list packages that would be found together with this one in all but
unusual installations."

You're on your own with these.

Kind regards,
Philipp Kern




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

Re: [RFC] DEP-6: Meta-Package debian/control field

[George Danchev]

Rene Engelhard writes:
> On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
> > However, seems like on IRC we reached kind of a consensus on the fact
> > that metapackages should use Recommends instead of Depends. I plan to do
> > a mass- bug filing on this issue sooner or later, just need some time to
> > do it :)
> 
> What sense does that have? apt-get install openoffice.org installing
> nothing? (Assuming a system has a senseful configuration and has
> the recommends-install thing removed? Ok, OOo is a bad example, let's get a
> better one:
> 
> mysql-server or postgresql. On (minimal as you can get) servers you don't
> want to install recommends, and this would break those, too.
> (Yes, they are metapackages)

Given the fact that there is no clear definition what a metapackage is (yes, we 
all think we know what it is), the opposite is also true: openoffice.org, mysql-
server, postgresql could equally be thought of not being metapackages and 
their Depends are not to be demoted to Recommends. It all boils down to the 
maintainer decision what to put in Depends and Recommends, regardless of 
whether they thought of their package as being a metapackage or not.

-- 
pub 4096R/0E4BD0AB 


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

Processed: how to reproduce

[Debian Bug Tracking System]

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

> reassign 561068 linux-2.6
Bug #561068 [general] nfs crashes debian
Bug reassigned from package 'general' to 'linux-2.6'.
> tags 561068 + moreinfo unreproducible
Bug #561068 [linux-2.6] nfs crashes debian
Added tag(s) unreproducible and moreinfo.
> # as discussed with Womble2 on irc
> thanks
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

Bug#538022: PAGER as a pipeline

[Holger Levsen]

Hi Colin,

why did you reassign 538022 to general? From reading "If we want to extend 
PAGER in general, then I'm willing to revisit this." in  
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=149;bug=538022 I understand 
you want the projects opinion on whether man should implement this? If I got 
that correctly, I think  the bug should be reassigned to man - and the 
project can still discuss this.

Else, please explain what's the general bug to track here.


Thanks,
Holger


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

Bug#538022: PAGER as a pipeline

[Colin Watson]

On Mon, Dec 21, 2009 at 06:21:02PM +0100, Holger Levsen wrote:
> why did you reassign 538022 to general? From reading "If we want to extend 
> PAGER in general, then I'm willing to revisit this." in  
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=149;bug=538022 I understand 
> you want the projects opinion on whether man should implement this? If I got 
> that correctly, I think  the bug should be reassigned to man - and the 
> project can still discuss this.
> 
> Else, please explain what's the general bug to track here.

The general bug is that not even sensible-pager implements $PAGER as a
pipeline, and thus it seems to me that we systemically don't support
this facility. If we want to support that, we're talking about changes
to more than just man-db; I expect there are packages other than
sensible-utils and man-db that have problems.

-- 
Colin Watson   [cjwat...@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] DEP-6: Meta-Package debian/control field

[Steve Langasek]

On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:

> > Those are exactly the correct semantics.  It makes no sense to remove the
> > depends of a metapackage *and leave the metapackage installed* - what
> > purpose would that serve?

> Being able to

> # apt-get --purge remove wicd

> (thus removing any dependency/recommends/anything), without caring for the 
> removed parts singularly?

That result can be achieved by *not* making wicd a metapackage, and moving
its Depends to Recommends.  So removing wicd-curses will not remove wicd
automatically, but removing wicd will remove wicd-* automatically.

Or do you really mean that you expect the package manager to treat removal
of 'wicd' differently based on whether the removal is triggered by 'apt-get
remove wicd' vs. 'apt-get remove dependency-of-wicd'?

-- 
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: [RFC] DEP-6: Meta-Package debian/control field

[David Paleino]

Steve Langasek wrote:

> Or do you really mean that you expect the package manager to treat removal
> of 'wicd' differently based on whether the removal is triggered by
> 'apt-get remove wicd' vs. 'apt-get remove dependency-of-wicd'?

Exactly that, plus the fact that it is a metapackage.

-- 
 . ''`.   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: [RFC] DEP-6: Meta-Package debian/control field

[George Danchev]

David Paleino writes:
> Rene Engelhard wrote:
> > On Mon, Dec 21, 2009 at 05:00:35PM +0100, David Paleino wrote:
> >> However, seems like on IRC we reached kind of a consensus on the fact
> >> that metapackages should use Recommends instead of Depends. I plan to do
> >> a mass- bug filing on this issue sooner or later, just need some time to
> >> do it :)
> >
> > What sense does that have? apt-get install openoffice.org installing
> > nothing? (Assuming a system has a senseful configuration and has
> > the recommends-install thing removed? Ok, OOo is a bad example, let's get
> > a better one:
> >
> > mysql-server or postgresql. On (minimal as you can get) servers you don't
> > want to install recommends, and this would break those, too.
> > (Yes, they are metapackages)
> 
> Go tell this to people on IRC ;)
> 
> They've been saying that my "auto-recommends off, but I want working
> metapackages" configuration is insane! :P

There is a big difference between being insane and being on your own, really.

> That's why I wanted to propose a Meta-Depends (or whatever we call that),
> that must only be used by metapackages, and works like Recommends, but is
> not configurable.

Unfortunately, that Meta-Depends introduces new package relationship, while we 
already have three of them (absolute, strong, weak). Next, if you are going to 
register metapackages with the packaging system (which basically means yet 
another dedicated field or a dedicated section resp., I'm not arguing which is 
better) you should firstly propose a sensible and clear definition what a 
metapackage is, so it is clear when maintainers are supposed to use that 
metapackage field or section. That would eventually answer the question whether 
or not so defined metapackages must be treated specially on autoremove & Co.

I'm sorry I can't come with a complete solution, which is not that easy, but 
this is just my view how to start sorting out the mess.

-- 
pub 4096R/0E4BD0AB 


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

Re: [RFC] DEP-6: Meta-Package debian/control field

[Emilio Pozuelo Monfort]

Thomas Goirand wrote:
> Steve Langasek wrote:
>> In this scenario, with Recommends installed by default (the only sane
>> model), the vast majority of metapackage dependencies are moved from Depends
>> to Recommends, so you can remove those Recommends manually without forcing
>> removal of the metapackage; and you can remove the metapackage without
>> causing cascading autoremoval of e.g., half your desktop.
> 
> If I may, the "Recommends installed by default" scenario doesn't really
> apply here, as the goal here is to remove some dependencies that you
> don't want to have, because you want a smaller system. So what you are
> asking for is having even MORE packages installed when we want LESS.

No, he's not asking for anything because Recommends are already installed by
default. So by using Recommends instead of Depends in metapackages, you're able
to remove any package you don't like or want, resulting in less packages, not 
more.

Emilio


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

Bug#562009: ITP: python-keyring -- Python module to access the system keyring service

[David Paleino]

Package: wnpp
Severity: wishlist
Owner: David Paleino 

* Package name: python-keyring
  Version : 0.2
  Upstream Author : Kang Zhang 
* URL : http://home.python-keyring.org/
* License : PSF
  Programming Lang: Python
  Description : Python module to access the system keyring service

 The Python keyring module provides a easy way to access the system keyring  
 service from python. It can be used in any application that needs safe  
 password storage. It supports OSX, KDE, Gnome and Windows's native password 
 storing services. Besides this, it is shipped with kinds of Python 
 implemented keyring for the left environments.


I haven't yet checked whether PSF is DFSG-free, nor what version it exactly 
is. It's only mentioned on the PKG-INFO accompanying the sourcecode, will ask 
upstream for further clarification.

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


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

Re: Bug#562009: ITP: python-keyring -- Python module to access the system keyring service

[David Paleino]

On Monday 21 December 2009 23:56:52, Michal Čihař wrote:
> This package is already in Debian:
> 
> http://packages.debian.org/sid/python-keyring

Err, oops. I must have mistyped something, then. Sorry for the noise.

(and not the first time today I make such mistakes. Maybe it's time to go to 
bed)

Thanks for replying!
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


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

Re: Bug#560786: gdb: Please make the python dependency optional

[Daniel Jacobowitz]

Picking some arbitrary messages in this thread to respond to.

On Sun, Dec 20, 2009 at 03:30:20AM +1030, Ron wrote:
> I do appreciate, and share, your concern for not bloating the archive
> needlessly, but my concern is balancing that against the needs of small
> Debian systems, where the extra deps this drags in are of themselves a
> quite substantial and needless extra bloat.  They are considerably larger
> than gdb is itself, and needing to put extra flash on a board, just to
> install python, which the board itself will never use, hits a much harder
> limit than an extra 4MB package in the archive would.

There is not just one GDB package in the archive.  Many platforms have
two, and the build logic is tricky enough to produce all the variants
already... I really don't see the justification for another binary.

You've already said you don't have the space for GDB+Python.  So file
a wishlist bug to split gdbserver out to its own package, and I'll do
that for you happily.  Then you don't need to put the detached debug
info files on your target either.  If you are putting them on your
target, well, that explains why you can't fit GDB!

> Ideally this should really be some sort of runtime dependency, otherwise
> what happens when people also add perl, lua, ruby, etc. etc. bindings to
> do the same thing as this python dep does?

It's not going to happen.  We (the GDB developers) spent a long time
picking one language under the firm plan that we wanted exactly one.
We don't want to fragment available GDB scripts by language; that
defeats the point of making it scriptable.

>  - libgdb-dev appears to be unused, and itself recommends that it never
>should be.  That's the size of 2 gdb .debs itself, so if you really
>want to remain "archive neutral", we could trade it for a gdb-minimal
>package, and wind up using less archive space in the deal.

It exists for the benefit of the Free Pascal IDE.  Also, it takes
almost no additional build daemon time.

> I've cc'd -devel, as others may have even better or simpler solutions,
> but I'd appreciate your guidance on the best way to move forward with
> solving this from here.

I just don't see why a solution to this is necessary in the archive.
Nothing you've said has changed that.  Either we install gdbserver, or
else you can just throw a GDB binary around from system to system.
I don't think the range of systems which don't need and can't fit
Python, but can fit a GDB executable (and its substantial RAM
requirements, and the huge debuginfo files it needs to be useful)
is very large.

Remote debugging is easy, and this is exactly what it's for.

On Sun, Dec 20, 2009 at 11:45:00AM +0100, Eduard Bloch wrote:
> And people who don't care shouldn't be forced against their will.

I am not holding a gun to your head and making you install GDB.
I don't think this is an appropriate description.  Debian isn't
in the business of providing every possible combination of configure
options; there are some other distros with that philosophy.

Didn't there used to be a statement in policy or the developer's
reference that optional dependencies should generally be enabled,
which had some special words about X11?  I can't find it any more.

> Why don't we provide a gdb-tiny package, in the same fashion as
> vim-tiny? Or is the python support that much hardcoded into gdb source
> now that it can never separated?

It can be separated.

-- 
Daniel Jacobowitz
CodeSourcery


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

Re: Bug#562009: ITP: python-keyring -- Python module to access the system keyring service

[Michal Čihař]

Hi

Dne Mon, 21 Dec 2009 23:42:29 +0100
David Paleino  napsal(a):

> Package: wnpp
> Severity: wishlist
> Owner: David Paleino 
> 
> * Package name: python-keyring
>   Version : 0.2
>   Upstream Author : Kang Zhang 
> * URL : http://home.python-keyring.org/
> * License : PSF
>   Programming Lang: Python
>   Description : Python module to access the system keyring service
> 
>  The Python keyring module provides a easy way to access the system keyring  
>  service from python. It can be used in any application that needs safe  
>  password storage. It supports OSX, KDE, Gnome and Windows's native password 
>  storing services. Besides this, it is shipped with kinds of Python 
>  implemented keyring for the left environments.
> 
> 
> I haven't yet checked whether PSF is DFSG-free, nor what version it exactly 
> is. It's only mentioned on the PKG-INFO accompanying the sourcecode, will ask 
> upstream for further clarification.

This package is already in Debian:

http://packages.debian.org/sid/python-keyring

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: Debian packages and upstart jobs

[Gunnar Wolf]

Russ Allbery dijo [Fri, Dec 11, 2009 at 01:07:21PM -0800]:
> (...)
> Is there any reason why it would cause problems for me to add an upstart
> job to the Debian package, even though Debian doesn't currently use
> upstart?  (I realize that the logic around deactivating the init script if
> upstart is present may be a bit complex, but I suspect we can find ways of
> dealing with that.)  I assume the job just sit there quiescent until
> Debian switches to upstart.

Well, I guess that the init script can be made not to fail if it is
running. And although I'm not upstart-literate, I understand that the
event launched by upstart can make the initscript to be called. Just
make sure that starting an already started daemon, or stopping an
already stopped daemon, does not result in failure, and I guess that
would be enough.

-- 
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#562032: ITP: python-figleaf -- Python code coverage analysis

[Milton Mazzarri]

Package: wnpp
Severity: wishlist
Owner: Milton Mazzarri 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: python-figleaf
  Version : 0.6.1
  Upstream Author : C. Titus Brown 
* URL : http://darcs.idyll.org/~t/projects/figleaf/doc/
* License : MIT/X
  Programming Lang: Python
  Description : Python code coverage analysis

figleaf is a Python code coverage analysis tool, built somewhat on the model
of Ned Batchelder's fantastic coverage module. The goals of figleaf are to be
a minimal replacement of 'coverage.py' that supports more configurable
coverage gathering and reporting.

You should use coverage if you're primarily looking at code coverage of unit
tests; figleaf is probably more useful for situations where you are recording
code coverage in multiple execution runs and/or want to tweak the reporting
output

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

iQIcBAEBCAAGBQJLMEErAAoJELNAhRTZc35m55gQAJizqNTGfjFnPm+KSihQ8Twh
g79REeFvKhxKrzaRpBM6GNEm5LkRriFupQgJ/3ZxhtvxuqShrNtMQz6jDtLNjs10
9cUbfREXmN0905cnFEOlkLOmweEStBHxPCBLB0qB7ogXvl/2dOedQeKEuCuonaaS
1oXGen1lflahVjEHBZr/jGIMWM6e38nTy21KTrrzgKDVkUVs5IP7pdjk1Ed1WRxe
5iiv45L/GQ8cQmghHg5cHbjUQDpO/U8YK1qAeX7/7HDgKj5QJMtQ0DPravGW+R6L
ROvWNh3utoXB9k4QaiSIWS56JSQ/Ug2bYAdLgv4fJieQ2bR6vHIGyidhI9ra1g8V
jCipWKQw3yKBP9TBmTWdXu+w+GRAGW4COSAKRtDuqZ95iwntyVaZ6zUUS4dZNW1b
g2zZr4Z73qQHfrUBY4TyiWkmPlwG4BtjInMuKt12Efx8L0+0evm9FfMP/sUi01BZ
V7DEEGT1ARaXY53LYakSpPGb6DXXAA7DqybfTNqdpxQxkKlBSav4XvU+XKPC5Kfq
jDwf3rmKLIyvIhWrQubUNnl9XYFsnEoIbrlj/udUpIRXy16qKzdR6LBpDqic6OQk
yQuyKLM/JMdF/gen4snzfleFDbmCB4wx/RVhtwCxbOyiTjHYdaxc+K/H02JZ2ja7
/EO1F6qn7DUi+SkJkOJv
=9zt0
-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: [RFC] DEP-6: Meta-Package debian/control field

[Jean-Christophe Dubacq]

Felipe Sateler a écrit :

> In this particular case, none. But in the general case there are reasons
> to keep the metapackage installed. For example, I want to try out gnome.
> So I install the gnome metapackage. I do not want (say) brasero. But I
> still want everything removable by just saying aptitude remove gnome.

Just wait until somebody implements "somepackagemanager dummy brasero"
that would pull brasero, use equivs (or some other internal system) to
build a brasero equivalent (but without any files), remove brasero and
install it instead, put it in a special list, and do that everytime
brasero (real package) is meant to be installed. *That* would be
reasonable, and would not interfere with what the packagers do.

And you could get "somepackagemanager undummy brasero" and
"somepackagemanager dummylist", which would be a must.
-- 
Jean-Christophe Dubacq


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

Re: [Need Help] About file lock in Debian Sarge

[Muhammad H Hilman]

Wow, it's work

but, must I change the code on my application that needed filelock?
because, filelock code on that application stated as ubuntu command (just
filelock)
as far as I know debian command on filelock is (filelock-create)

can you tel me what's the different between (filelock-create) command and
lockf() and fcntl()
actually, I am still newbie on using Debian

Thanks,


On Mon, Dec 21, 2009 at 6:52 AM, Roger Leigh  wrote:

> On Thu, Dec 17, 2009 at 11:16:02PM +0100, Michelle Konzack wrote:
> > maybe
> > apt-get install liblockfile1
>
> Possibly, but lockf() and fcntl() are usually better, and are present
> in libc.
>
>
> --
>  .''`.  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.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAksuuKUACgkQVcFcaSW/uEi66ACgjEUjXA5/CSWzcL+KiKxnb4lV
> sKUAoLri4DdIZTwNUdQEzizrLPVLW1mD
> =/6Md
> -END PGP SIGNATURE-
>
>