Re: Policy §10.4 as a divergence from usptr eam (renamings to remove extensions like .pl an d .sh).

[Vincent Danjean]

Charles Plessy wrote:
> I use the packages I made, and renaming upstream programs names makes my 
> scripts
> incompatible with my colleagues work environments using other distributions or
> installations from source. So as a maintainer, I spend time creating extra 
> work
> for myself as a user. That does not make sense.

It is also possible to add symlinks into a private directory. Users willing
to use names with extensions only have to add this directory to their PATH.
For example, you can ship:
/usr/bin/util
/usr/share/package/bin/util.sh -> /usr/bin/util

Users willing to use names with extension on Debian only have to do
PATH=/usr/share/package/bin:$PATH

  Regards,
Vincent


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

Re: Patch Tagging Guidelines (aka DEP3)

[Raphael Hertzog]

On Wed, 23 Sep 2009, Kurt Roeckx wrote:
> For elfutils, I have 2 patches that I take from the upstream git
> repo.  Both patches have their own branch, and upstream/redhat
> merges the master branch into them.  So around the time of an
> upstream release I do git diff release...branch to get the new patch.
> 
> Those branches contain several patches, so it's not a single
> commit.  And I'm not sure how to properly put in the header
> where it comes from.

I would suggesto to put an URL pointing to a branch instead of pointing to
a specific commit. And explain in the description how the patch was
generated.

Cheers,
-- 
Raphaël Hertzog


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

Re: renamings to remove extensions

[Ben Finney]

"Steve M. Robbins"  writes:

> I agree with Charles: this is unncessary, unproductive busy-work.

The same characterisation could be given to other changes that raise the
quality of software in Debian (e.g. ensuring that commands are
accompanied by man pages, or that the package synopsis should not be
repeated in the extended description).

Improving quality may be strictly unnecessary, and may be not directly
productive, but that doesn't mean there's no good reason to expect it.

-- 
 \“Choose mnemonic identifiers. If you can't remember what |
  `\mnemonic means, you've got a problem.” —Larry Wall |
_o__)  |
Ben Finney


pgpZfCOcoX2rn.pgp
Description: PGP signature

Re: renamings to remove extensions

[Mike Hommey]

On Tue, Sep 29, 2009 at 07:30:44PM +1000, Ben Finney wrote:
> "Steve M. Robbins"  writes:
> 
> > I agree with Charles: this is unncessary, unproductive busy-work.
> 
> The same characterisation could be given to other changes that raise the
> quality of software in Debian (e.g. ensuring that commands are
> accompanied by man pages, or that the package synopsis should not be
> repeated in the extended description).

None of these have an impact on *other* software. Renaming a file does.

> Improving quality may be strictly unnecessary, and may be not directly
> productive, but that doesn't mean there's no good reason to expect it.

Improving quality only for the sake of it is not necessarily a good
idea. I do agree that if everyone but Debian expects foo to be called
as foo.pl, there is a bug in Debian.

Mike


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

Re: renamings to remove extensions

[Peter Eisentraut]

On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote:
> "Steve M. Robbins"  writes:
> 
> > I agree with Charles: this is unncessary, unproductive busy-work.
> 
> The same characterisation could be given to other changes that raise the
> quality of software in Debian (e.g. ensuring that commands are
> accompanied by man pages, or that the package synopsis should not be
> repeated in the extended description).

This is not a useful analogy.  Software will continue to work with or
without documentation or description.  Renaming programs breaks
interfaces.


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

Re: renamings to remove extensions

[Bernhard R. Link]

* Mike Hommey  [090929 11:43]:
> > Improving quality may be strictly unnecessary, and may be not directly
> > productive, but that doesn't mean there's no good reason to expect it.
>
> Improving quality only for the sake of it is not necessarily a good
> idea. I do agree that if everyone but Debian expects foo to be called
> as foo.pl, there is a bug in Debian.

If that is the case that only means that upstream should be educated and
one has to choose between keeping bugs to be compatible and creating
problems by fixing bugs. (File names is not the only case where fixing
bugs can cause problems even to an extend where in same cases not fixing
the bug can be the better solution).

Hochachtungsvoll,
Bernhard R. Link


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

Re: renamings to remove extensions

[Ben Finney]

Mike Hommey  writes:

> On Tue, Sep 29, 2009 at 07:30:44PM +1000, Ben Finney wrote:
> > "Steve M. Robbins"  writes:
> > 
> > > I agree with Charles: this is unncessary, unproductive busy-work.
> > 
> > The same characterisation could be given to other changes that raise
> > the quality of software in Debian (e.g. ensuring that commands are
> > accompanied by man pages, or that the package synopsis should not be
> > repeated in the extended description).
>
> None of these have an impact on *other* software. Renaming a file
> does.

Peter Eisentraut  writes:

> This is not a useful analogy. Software will continue to work with or
> without documentation or description. Renaming programs breaks
> interfaces.

This is a different complaint from “unnecessary, unproductive
busy-work”. I was answering only that complaint.

So, if the change can be made *without* breaking existing interfaces
(e.g. by providing a compatibility symlink to the suffix-less real
program file), then the “breaks interfaces” complaint is addressed and
is no longer an impediment to providing well-named program files.

-- 
 \“Holy contributing to the delinquency of minors, Batman!” —Robin |
  `\   |
_o__)  |
Ben Finney


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

Re: renamings to remove extensions

[Giacomo A. Catenazzi]

Peter Eisentraut wrote:

On Tue, 2009-09-29 at 19:30 +1000, Ben Finney wrote:

"Steve M. Robbins"  writes:


I agree with Charles: this is unncessary, unproductive busy-work.

The same characterisation could be given to other changes that raise the
quality of software in Debian (e.g. ensuring that commands are
accompanied by man pages, or that the package synopsis should not be
repeated in the extended description).


This is not a useful analogy.  Software will continue to work with or
without documentation or description.  Renaming programs breaks
interfaces.


I totally agree. For this reason the suffix must be removed!
Program interfaces remain, but implementation language changes
(see many "-ng" packages).

ciao
cate


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

Re: Orphaning my packages...

[Bastien ROUCARIES]

Le mardi 29 septembre 2009 03:04:25, Kevin B. McCarty a écrit :
> Hi all,
> 
> I unfortunately don't have the free time at the moment to do much for
> the Debian Project, so I'm orphaning my packages.
> 
> If anyone wants to stake a claim to any of the following, please go
> ahead and say so, otherwise I'll file the orphaning bugs within a couple
> days.  (Follow-ups set to debian-devel.)
> 
> Cernlib-related (Cernlib is a huge, mostly obsolete set of physics
> libraries and tools) packages.  These all have corresponding wnpp ITO
> bugs that can be changed to ITA / closed as desired.  Note, Francois
> Niedercorn (in CC) has first dibs on these if he wants them.  Francois,
> if you still do, please reply to debian-devel.
> 
> cernlib - #508413
> cfortran - #508500
I am not a debian developer but i could comaintain cfortran


Bastien
> geant321 - #508496
> mclibs - #508498
> mn-fit - #508501
> paw - #508495
> 
> Other packages:
> 
> feynmf
> viewglob
> 
> 
> best regards,
> 


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Peter Eisentraut]

On Tue, 2009-09-29 at 13:36 +0900, Charles Plessy wrote:
> I know that there has already been much of talk about this, but I am am 
> getting
> more and more uncomfortable removing .pl or .sh extensions from programs when
> upstream does not.

At least in cases where the programs/scripts could be considered part of
a programming interface, this requirement is approximately equivalent to
requiring the exported symbols of libraries to conform to some spelling
scheme.  While Debian has occasionally altered or broken the exported
interfaces of libraries in cases of severe trouble, this is not
routinely done, and usually not merely in the name of prettiness.



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

Re: renamings to remove extensions

[Josselin Mouette]

Le mardi 29 septembre 2009 à 11:43 +0200, Mike Hommey a écrit : 
> Improving quality only for the sake of it is not necessarily a good
> idea. I do agree that if everyone but Debian expects foo to be called
> as foo.pl, there is a bug in Debian.

Which is why lintian warnings are left at the appreciation of the
maintainer.

Renaming binaries in a way that breaks interfaces or expectations is not
desirable, of course. That doesn’t prevent the goal of removing useless
script extensions from being a worthy one.

The idea of putting extensions in scripts is stupid; it denotes a lack
of understanding of the Unix way, and makes it harder to make them
evolve in the future. Which is why we should remove these extensions
when possible, and ask upstream to do so when it is not.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Abou Al Montacir]

Le mardi 29 septembre 2009 à 13:21 +0800, Paul Wise a écrit :
> On Tue, Sep 29, 2009 at 1:09 PM, Reinhard Tartler  wrote:
> 
> > Would you consider this a blocker to inclusion into Debian? Upstream may
> > either release very slowly or may just not care about Debian, which
> > would result in the package to never end up in Debian.
> 
> I'd consider not fixing it in the .deb (irrespective of what upstream
> does) as a blocker.
> 
> Having an uncooperative upstream would likely make me think twice
> about putting it in Debian in the first place.

You can also try to make the world look like you want not adapt your
eyes to see the world as is, no?

Please note that upstream could not adapt themselves to all distribution
policies which may be contradictory, but a distribution could and
probably should adapt itself to upstream.

In addition, many of upstream won't change their work just because we
want them to do so because of our policy. In my case, I tried many times
and most of my tries failed. You can not force others to adopt the same
vision as you (at least in a democratic world).

I consider this is a nice to have, that's all.

Abou Al Montacir,


signature.asc
Description: Ceci est une partie de message numériquement signée

Webinar (free sign-up) on Google ranking: Top 10 SEO Tools

[Jason McDonald]

Good day,

I came across your company in my research on potential firms
and marketers (ad agencies, PR firms) that may be active in "Internet 
Marketing," including S.E.O. or Search Engine Optimization for ranking higher 
on Google.

I'd like to invite you to my upcoming free webinar on the "Top Ten Free Tools
for S.E.O. / Google Rank" being held online on Oct 8th and 12th.  The webinar
is free, and the tools I identify are free as well - all are focused on
helping you and your company improve your rank on Google searches.

To register - more details on the eg3.com class I am teaching -

 http://seo-webinars.org/go.cgi?debian-de...@lists.debian.org

> Because it identifies the best free tools for SEO and ways to leverage
Google's free (aka "organic") listings - it usually fills up when
 I do offer it.

> I am usually too busy to offer this webinar, except a few times each year.

> About me - I am a researcher, journalist, and teacher living in the SF Bay 
> Area
working more on Google and S.E.O. issues.

Hope to "see" you there.  It will be time well spent!
 

Best regards,

Jason McDonald
j.mcdon...@seo-webinars.org

p.s. - I'd prefer that you minimize any forwarding of this announcement to 
colleagues as the webinars do usually fill up, and I try to limit the 
attendence to seriously minded marketers, ad agencies types, PR firms, etc.

* To remove yourself from my contact list - 
 http://www.seo-webinars.org/stop.html?debian-de...@lists.debian.org

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

How I do hate those enemies of the human race who go around enslaving God's 
free people with pledges- to quit drinking instead of to quit wanting to drink.
 -Letter to Henry W. Beecher, 9/11/1885 


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

Bug#548872: ITP: libjgraphx-java -- Java Swing Diagramming Library

[Sylvestre Ledru]

Package: wnpp
Severity: wishlist
Owner: Sylvestre Ledru 


* Package name: libjgraphx-java
  Version : 1.0.2.4
* URL : http://www.jgraph.com/jgraphx.html
* License : LGPL
  Programming Lang: Java
  Description : Java Swing Diagramming Library

 JGraph X is based on the mxGraph architecture, a re-designed core based 
 on JGraph experience. 
 .
 The new library API is designed to provide a much lower learning curve as
 well as making the feature set easier to extend and integrate. Sharing the
 model code base of mxGraph, the web diagramming library, enabling applications
 written in Java to be more easily ported to mxGraph-based web applications.
 .
 Overall, JGraph X provides more features that JGraph, with a far smaller code
 size and complexity. Redesigning the codebase from scratch now means
 implementing common feature extensions are easier and require less coding.
 A number of new loosely coupled application-centric features have been added,
 making prototyping even faster, without their usage restricting application
 flexibility.



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

Re: PLEASE REPLY ME ITS URGENT FOR HOME DECOR WEBSITES

[Ronald Roddick]

Hi,

I have signed up for this company

And i have earned money from here

You also can gain from here...

Free sign up here and follow the instructions

Its a online earning programme.No scams...because i have earned and
still doing work for the company

Free Register here:

http://www.earnparttimejobs.com/index.php?id=2451106

For more knowledge you can see the "Read More" button

Thanks
Ronald

Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Andreas Tille]

On Tue, Sep 29, 2009 at 10:40:23AM +0200, Vincent Danjean wrote:
> It is also possible to add symlinks into a private directory. Users willing
> to use names with extensions only have to add this directory to their PATH.
> For example, you can ship:
> /usr/bin/util
> /usr/share/package/bin/util.sh -> /usr/bin/util

But this will break the interface for users as well as long as they not
explicitely extend their path to
   /usr/share/{packages_with_extensions_in_names}/bin
The only way to not break the interfaces is to invent a dir say

   /usr/not_policy_compliant_named_dust-bin/

and move everything there ans set the policy compliant links to /usr/bin.
Not that I would be in favour of this suggestion but this is the only
way I would see to let things work out of the box if you globally set
your PATH to this dir.
 
> Users willing to use names with extension on Debian only have to do
> PATH=/usr/share/package/bin:$PATH

The problem is: A user has to read the docs before and adding this to
the PATH explicitely is as easy as learning about a renamed executable.
The goal is to let things work out of the box.

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: renamings to remove extensions

[George Danchev]

Quoting "Josselin Mouette" :


Le mardi 29 septembre 2009 à 11:43 +0200, Mike Hommey a écrit :

Improving quality only for the sake of it is not necessarily a good
idea. I do agree that if everyone but Debian expects foo to be called
as foo.pl, there is a bug in Debian.


Which is why lintian warnings are left at the appreciation of the
maintainer.

Renaming binaries in a way that breaks interfaces or expectations is not
desirable, of course. That doesn’t prevent the goal of removing useless
script extensions from being a worthy one.

The idea of putting extensions in scripts is stupid; it denotes a lack
of understanding of the Unix way, and makes it harder to make them
evolve in the future. Which is why we should remove these extensions
when possible, and ask upstream to do so when it is not.


I've also read people claiming that preserving extensions could  
actually help evolving and migrations in the future and it is as  
simple as app.lang1 being rewritten as app.lang2, both stay on board  
as needed or for a reasonable amount of time, then at some point  
app.lang1 could actually be changed to just call app.lang2 when it's  
considered mature enough. That is absolutely fine with me as long as  
app.* are kept in reasonable amount of disk space, but scripts usually  
don't tend to become that large. (even small sizes could not be that  
practical for embedded when doubled, but that is another story).



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

Re: Policy §10.4 as a divergence from usptr eam (renamings to remove extensions like .pl an d .sh).

[Giacomo A. Catenazzi]

Abou Al Montacir wrote:

Le mardi 29 septembre 2009 à 13:21 +0800, Paul Wise a écrit :

On Tue, Sep 29, 2009 at 1:09 PM, Reinhard Tartler  wrote:


Would you consider this a blocker to inclusion into Debian? Upstream may
either release very slowly or may just not care about Debian, which
would result in the package to never end up in Debian.

I'd consider not fixing it in the .deb (irrespective of what upstream
does) as a blocker.

Having an uncooperative upstream would likely make me think twice
about putting it in Debian in the first place.


You can also try to make the world look like you want not adapt your
eyes to see the world as is, no?

Please note that upstream could not adapt themselves to all distribution
policies which may be contradictory, but a distribution could and
probably should adapt itself to upstream.

In addition, many of upstream won't change their work just because we
want them to do so because of our policy. In my case, I tried many times
and most of my tries failed. You can not force others to adopt the same
vision as you (at least in a democratic world).


IMHO this is not true. Look at Linux 10-15 years ago: it was completely
different: every program was different: different option conventions,
different commands to configure and build, different paths, different keys,
different interpretation of free software, etc.

Debian tried hard to standardize such things, and IMHO because of Debian
(or with some Debian help) a lot of things changed.
Your arguments are old, but fortunately we look forward, and now we have
the open source definition, we have FHS, we have LSB, backspace/delete/C-H
have a consistent behaviour, we don't need to use any special environment
variable for any program, ...

It is not a different vision, but a forward looking: user are interested
in interfaces, not in the underlying details and languages. Thus
*in general* (there are always exceptions), the suffix causes difficulties
to reprogram the utility in an other language.

It is not the upstream task to simplify forks and concurrent utilities
(in an other language), so you cannot always agree/convince upstream
to remove suffix, but we will have do deal with such enhancements.

We cannot force the other to adapt to our vision, but we can have
a common vision. Users (and developers) have the choice of distributions.
Debian, unlike other old distribution, still exist, proving our vision
is good.


ciao
cate


PS: I see this issue the same as FHS (but one is about "path prefix",
and this in about suffix). Thus we experienced a lot on how to modify
upstreams (a lot of upstreams still don't know about FHS).


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

What is this rule for? (was: Re: renamings to remove extensions)

[Andreas Tscharner]

On 29.09.2009 08:21, Steve M. Robbins wrote:


On the other hand, Section 10.4 says only "the script name should not
include an extension".  So you can leave the extension for


What is the intention of this rule anyway?

Thank you and best regards
Andreas
--
Andreas Tscharner
--
"Intruder on level one. All Aliens please proceed to level one."
  -- Call in "Alien: Resurrection"


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

Re: What is this rule for?

[Ben Finney]

Andreas Tscharner  writes:

> On 29.09.2009 08:21, Steve M. Robbins wrote:
>
> > On the other hand, Section 10.4 says only "the script name should not
> > include an extension".  So you can leave the extension for
>
> What is the intention of this rule anyway?

To encourage command names (and hence command APIs, since the name is
part of the API for the command) that do not encode implementation
details, such as the programming language. This allows the program to be
later re-implemented in a different language without the command name
being misleading.

-- 
 \ “If we don't believe in freedom of expression for people we |
  `\   despise, we don't believe in it at all.” —Noam Chomsky, |
_o__)   1992-11-25 |
Ben Finney


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

Bug#548895: ITP: pinyin-database -- PinYin database used by ibus-pinyin

[LI Daobing]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: pinyin-database
Version: 1.2.99
Upstream Author: Huang Peng 
URL: http://code.google.com/p/ibus
License: GPLv2
Description: PinYin database used by ibus-pinyin

 This package provide pinyin-database-.tar.bz2 which is required when
 compile ibus-pinyin.
Homepage: http://code.google.com/p/ibus




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

Re: What is this rule for?

[Stéphane Glondu]

Andreas Tscharner a écrit :
>> On the other hand, Section 10.4 says only "the script name should not
>> include an extension".  So you can leave the extension for
> 
> What is the intention of this rule anyway?

So I'm not the only one to wonder about this.

After digging I've found the following discussion:

  http://lists.debian.org/debian-policy/2003/04/msg00031.html

which led to the following bugreport:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=190753

which was fixed in version debian-policy/3.7.0.0.

I agree with the arguments, but I am not convinced we should diverge
from upstream on this topic, by the way.


Cheers,

-- 
Stéphane


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

O: mantis - web-based bug tracking system

[Patrick Schoenfeld]

retitle 471094 O: web-based bug tracking system
noowner 471094
thanks

Hi,

as I do not use mantis anymore and I don't have the time nor interest
to keep up with the mantis development, I'm hereby orphaning mantis.

If you want to be the new maintainer, please take it -- see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Please note:
There currently exists a SVN repository and a git repository.
The latter is where the more recent development took place.
I just let the SVN exist, because older versions referred to
that repository in their control file and I didn't want
to let it fail when checking them out (e.g. with debcheckout).

If you need any information: I'm not out of the world
or anything, so you can still reach me.

CC'ing Olivier Berger, because he already made significant
contributions to the mantis package. Maybe you are interested
in taking it.

Best Regards,
Patrick


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

Re: Patch Tagging Guidelines (aka DEP3)

[Kurt Roeckx]

On Tue, Sep 29, 2009 at 11:25:17AM +0200, Raphael Hertzog wrote:
> On Wed, 23 Sep 2009, Kurt Roeckx wrote:
> > For elfutils, I have 2 patches that I take from the upstream git
> > repo.  Both patches have their own branch, and upstream/redhat
> > merges the master branch into them.  So around the time of an
> > upstream release I do git diff release...branch to get the new patch.
> > 
> > Those branches contain several patches, so it's not a single
> > commit.  And I'm not sure how to properly put in the header
> > where it comes from.
> 
> I would suggesto to put an URL pointing to a branch instead of pointing to
> a specific commit. And explain in the description how the patch was
> generated.

That assumes you can point to a URL.  It might have a public VCS
repo, but not some website.


Kurt


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

Re: What is this rule for?

[Gunnar Wolf]

Ben Finney dijo [Tue, Sep 29, 2009 at 11:40:46PM +1000]:
> > > On the other hand, Section 10.4 says only "the script name should not
> > > include an extension".  So you can leave the extension for
> >
> > What is the intention of this rule anyway?
> 
> To encourage command names (and hence command APIs, since the name is
> part of the API for the command) that do not encode implementation
> details, such as the programming language. This allows the program to be
> later re-implemented in a different language without the command name
> being misleading.

And because extensions truly mean nothing. Of course, I can
implement foo.py in Ruby as I am just prototyping but later decide to
reimplement it (using the same name, as many scripts already depend on
it) in Perl. 

In a Unix system, extensions are usually appended garbage which adds
very, very little real value.

...Or possibly we could decide on renaming /bin/ls to /bin/ls.elf in
order to show what kind of file it is, and allowing for different
implementations to coexist?

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

Re: renamings to remove extensions

[John H. Robinson, IV]

Mike Hommey wrote:
> 
> I do agree that if everyone but Debian expects foo to be called as
> foo.pl, there is a bug in Debian.

/var/qmail/bin/qmail-send
/command/supervise

These are what are expected when you use qmail and daemontools the DJB
way. 

  http://cr.yp.to/unix.html

We solve the first one with /var/qmail/bin being a symlink to /usr/sbin.
We don't solve the latter one at all.

Debian bug, or DJB bug?

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


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

Debconf and PackageKit

[Daniel Nicoletti]

Hi,
following pusling advice I'd like to explain the issues
involved in this subject and a proposed solution.
If you don't know anything about PackageKit it might
be interesting to look at www.packagekit.org.

I started to contribute to PackageKit willing to have it
working on the system I use (Debian of course), but
after I "finished" KPackageKit Debian support was almost
at the same stage an apt backend written in python that didn't
support lots of apt features like localizing, media changing,
and installing packages that need removal of others...

As I'm not a python fan i decided to do a new apt backend 
written in cpp (which does a difference in speed), apcc was created
and most of the issues the py version had aptcc does not have
I added media change support to Pk, descriptions of packages
are now localized, and recently i added a new method called
simulate that allowed me to emit packages to be removed in an
install transaction. So now it works very close to what apt-get
does.

Installing/Removing/Updating are the last problem of this backend
mostly because of debconf.
PackageKit works this way (if you didn't take a look at the web site):

Backend (apt | aptcc | yum | zyppy )
||
|| (some are completely separated process like python backends)
||
PackageKitD (an activated DBus service)
||
|| (DBus interface)
||
GUI tools (gnome-packagekit, kpackagekit...)

Some problems:
1. Looking at the above you probably already guessed
that we have an already specified API,
like search_name, get_details.. and adding
something strickly debconf specific is not soo simple.
2. The user is able to start an update and logout
his session, so where the DebConf dialog will be shown?
Will it hang for ever?

We thought of various solutions to these problems,
and the one that might put and end to this would work like this:
- The user asks to install foo
- Backend creates a socket for debconf and (don't know how yet)
  keep an eye on it.
- Backend starts installing foo...
- Backend detects that a debconf dialog is needed
- Backend check if the caller (the app that asked to install foo) is active,
  then one of the two actions must be taken:
   1. If active sends a signal with the socket path and the path of an script 
that
  can set up a front end using this socket
   2. If not, behave like in noninteractive mode chosing default answears
   OR finding a way to fail the instalation if the user is not present
   (dunno which is best)

>>>This solution is not implemented as I don't know debconf verry well
but there is one problem that I'd like to know if there is a already a way
to deal with this:
when aptcc backend starts installing packages it's status are in a fd
which might be localized is LANG is set, so I clean LANG
and get dpkg to give strings like
removing, unpacking, that can be converted to an enum.
The problem is if i unset LANG debconf is not localized too
so the user will see debconf dialog in english.

My solution would be to have an extra env var like
DEBCONF_LANG or DPKG_LANG
(sorry if they already exist but i could not find it)
This way dpkg can run not localized and debconf
will have the right locale.

Please be kind as I'm not familiar with this list :P
and don't know debconf and dpkg internals...
If you want download PackageKit and please
try aptcc :D

(BTW please send me links with intesreting
info about debconf protocol, I could only find it
from a package maintainer POV)

Thanks,
Daniel.



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com


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

Re: What is this rule for?

[George Danchev]

> Ben Finney dijo [Tue, Sep 29, 2009 at 11:40:46PM +1000]:
> > > > On the other hand, Section 10.4 says only "the script name should not
> > > > include an extension".  So you can leave the extension for
> > >
> > > What is the intention of this rule anyway?
> >
> > To encourage command names (and hence command APIs, since the name is
> > part of the API for the command) that do not encode implementation
> > details, such as the programming language. This allows the program to be
> > later re-implemented in a different language without the command name
> > being misleading.
> 
> And because extensions truly mean nothing. Of course, I can
> implement foo.py in Ruby as I am just prototyping but later decide to
> reimplement it (using the same name, as many scripts already depend on
> it) in Perl.
> 
> In a Unix system, extensions are usually appended garbage which adds
> very, very little real value.

True. However, it makes no big difference whether people use (or resp. abuse) 
file extensions to claim the language a program is implemented in, or they do 
it within the base name. There are plenty of apps starring with py* and perl*, 
(and we have them most for years, which is not that different from *.py and 
*.pl) and I'd hesitate to characterize their naming style as tasteless or non-
Unix way, instead I'd rather accept it as is, since this was what the author 
decided on and is what the rest of the world got used to.
 
> ...Or possibly we could decide on renaming /bin/ls to /bin/ls.elf in
> order to show what kind of file it is, and allowing for different
> implementations to coexist?

This is of course good argument. Perhaps, some groups of apps, are not that 
challenging to be reimplemented in different ways, for various reasons 
including historical ones.

-- 
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: Debconf and PackageKit

[Julien Cristau]

On Tue, Sep 29, 2009 at 10:26:01 -0700, Daniel Nicoletti wrote:

> >>>This solution is not implemented as I don't know debconf verry well
> but there is one problem that I'd like to know if there is a already a way
> to deal with this:
> when aptcc backend starts installing packages it's status are in a fd
> which might be localized is LANG is set, so I clean LANG
> and get dpkg to give strings like
> removing, unpacking, that can be converted to an enum.
> The problem is if i unset LANG debconf is not localized too
> so the user will see debconf dialog in english.
> 
I don't understand this part.  Why would you have to unset LANG?  What
exactly do you want to avoid being localized?

> My solution would be to have an extra env var like
> DEBCONF_LANG or DPKG_LANG
> (sorry if they already exist but i could not find it)
> This way dpkg can run not localized and debconf
> will have the right locale.
> 
> Please be kind as I'm not familiar with this list :P
> and don't know debconf and dpkg internals...
> If you want download PackageKit and please
> try aptcc :D
> 
> (BTW please send me links with intesreting
> info about debconf protocol, I could only find it
> from a package maintainer POV)
> 
/usr/share/doc/debian-policy/debconf_specification.html

Cheers,
Julien


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

Re: Debconf and PackageKit

[Josselin Mouette]

Le mardi 29 septembre 2009 à 10:26 -0700, Daniel Nicoletti a écrit : 
> Installing/Removing/Updating are the last problem of this backend
> mostly because of debconf.
> PackageKit works this way (if you didn't take a look at the web site):
> 
> Backend (apt | aptcc | yum | zyppy )
> ||
> || (some are completely separated process like python backends)
> ||
> PackageKitD (an activated DBus service)
> ||
> || (DBus interface)
> ||
> GUI tools (gnome-packagekit, kpackagekit...)
> 
> Some problems:
> 1. Looking at the above you probably already guessed
> that we have an already specified API,
> like search_name, get_details.. and adding
> something strickly debconf specific is not soo simple.
> 2. The user is able to start an update and logout
> his session, so where the DebConf dialog will be shown?
> Will it hang for ever?

Currently, the question will simply be ignored, the frontend being set
to noninteractive when there is no TTY nor display available.

> We thought of various solutions to these problems,
> and the one that might put and end to this would work like this:
> - The user asks to install foo
> - Backend creates a socket for debconf and (don't know how yet)
>   keep an eye on it.
> - Backend starts installing foo...
> - Backend detects that a debconf dialog is needed
> - Backend check if the caller (the app that asked to install foo) is active,
>   then one of the two actions must be taken:
>1. If active sends a signal with the socket path and the path of an script 
> that
>   can set up a front end using this socket
>2. If not, behave like in noninteractive mode chosing default answears
>OR finding a way to fail the instalation if the user is not present
>(dunno which is best)

This is one of the possible solutions indeed. The thing you need is
actually a new frontend for Debconf, that should probably be based on
D-Bus so that you can map the authentication and permissions from what
comes from PackageKit.

This frontend would actually consist in a middleware that forwards
requests through D-Bus. The real frontend would be called by the
PackageKit frontend itself. You could probably directly re-use the
existing Gnome frontend to show the actual dialogs.

> >>>This solution is not implemented as I don't know debconf verry well
> but there is one problem that I'd like to know if there is a already a way
> to deal with this:
> when aptcc backend starts installing packages it's status are in a fd
> which might be localized is LANG is set, so I clean LANG
> and get dpkg to give strings like
> removing, unpacking, that can be converted to an enum.

Ugh, that’s an absolutely horrible and broken solution. You should use
the --status-fd dpkg option instead.

> The problem is if i unset LANG debconf is not localized too
> so the user will see debconf dialog in english.

This is not a problem. The frontend is responsible for extracting the
templates (the protocol only tells which questions to ask), and the
locale in the frontend remains that of the user.

> Please be kind as I'm not familiar with this list :P
> and don't know debconf and dpkg internals...
> If you want download PackageKit and please
> try aptcc :D

Maybe you should be aware that because of the shortcomings you describe,
some Ubuntu people started to work on aptdaemon as a possible PackageKit
replacement, PackageKit being absolutely unsuitable for a Debian-based
system at the moment. 

> (BTW please send me links with intesreting
> info about debconf protocol, I could only find it
> from a package maintainer POV)

The protocol is described in debconf-devel(7).

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Manoj Srivastava]

On Tue, Sep 29 2009, Abou Al Montacir wrote:

> You can also try to make the world look like you want not adapt your
> eyes to see the world as is, no?

We try to fix the world, yes. Systems integrations, and
 consistent policies, is what make Debian a superior OS.

> Please note that upstream could not adapt themselves to all distribution
> policies which may be contradictory, but a distribution could and
> probably should adapt itself to upstream.

A distribution should not adapt itself to 1 different
 upstreams with different polices, that would be a inconsistent madness,
 and would serve our end users ill. Part of what we do as Debian
 maintainers is to make software fit better with other bits of Debian,
 and this we do by creating and following a technical policy.

manoj
-- 
We don't care how they do it in New York.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: renamings to remove extensions

[Manoj Srivastava]

On Tue, Sep 29 2009, George Danchev wrote:

> I've also read people claiming that preserving extensions could
> actually help evolving and migrations in the future and it is as
> simple as app.lang1 being rewritten as app.lang2, both stay on board
> as needed or for a reasonable amount of time, then at some point
> app.lang1 could actually be changed to just call app.lang2 when it's
> considered mature enough. That is absolutely fine with me as long as
> app.* are kept in reasonable amount of disk space, but scripts usually
> don't tend to become that large. (even small sizes could not be that
> practical for embedded when doubled, but that is another story).

Since it is  being claimed that the script name is an
 "interface" that other software uses, then basic encapsulation 101 says
 that one should maintain the interface, but not rely on implementation
 (which, in the case of scripts, includes the language the script is
 implemented in).

manoj
-- 
But Officer, I stopped for the last one, and it was green!
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: renamings to remove extensions

[Manoj Srivastava]

On Tue, Sep 29 2009, Mike Hommey wrote:


>> Improving quality may be strictly unnecessary, and may be not directly
>> productive, but that doesn't mean there's no good reason to expect it.
>
> Improving quality only for the sake of it is not necessarily a good
> idea. 

!!!

If we are trying to provide the best OS ever, improving quality
 is _always_ a good idea. It might be too hard, or too time consuming,
 to implement all the quality improvements, but that does not make the
 improvement of quality "not a good idea".

> I do agree that if everyone but Debian expects foo to be called as
> foo.pl, there is a bug in Debian.

I think I disagree.  As my mother used to say, if all your
 friends jump into the well, that does not make it a good idea.

manoj
-- 
"The one charm of marriage is that it makes a life of deception a
neccessity." Oscar Wilde
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: renamings to remove extensions

[Manoj Srivastava]

On Tue, Sep 29 2009, Josselin Mouette wrote:

> Le mardi 29 septembre 2009 à 11:43 +0200, Mike Hommey a écrit : 
>> Improving quality only for the sake of it is not necessarily a good
>> idea. I do agree that if everyone but Debian expects foo to be called
>> as foo.pl, there is a bug in Debian.
>
> Which is why lintian warnings are left at the appreciation of the
> maintainer.
>
> Renaming binaries in a way that breaks interfaces or expectations is not
> desirable, of course. That doesn’t prevent the goal of removing useless
> script extensions from being a worthy one.

Damn. Must be a cold day in hell, since I am on the same page here.

> The idea of putting extensions in scripts is stupid; it denotes a lack
> of understanding of the Unix way, and makes it harder to make them
> evolve in the future. Which is why we should remove these extensions
> when possible, and ask upstream to do so when it is not.

Also, it breaks encapsulation; and makes it unnecessarily hard
 to re-implement the functionality in a different language (unless one
 thinks it is a good idea to have a python script have the name foo.sh).

manoj
-- 
This was the most unkindest cut of all. William Shakespeare, "Julius
Caesar"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Res: Debconf and PackageKit

[Daniel Nicoletti]

> De: Julien Cristau 

> > >>>This solution is not implemented as I don't know debconf verry well
> > but there is one problem that I'd like to know if there is a already a way
> > to deal with this:
> > when aptcc backend starts installing packages it's status are in a fd
> > which might be localized is LANG is set, so I clean LANG
> > and get dpkg to give strings like
> > removing, unpacking, that can be converted to an enum.
> > The problem is if i unset LANG debconf is not localized too
> > so the user will see debconf dialog in english.
> > 
> I don't understand this part.  Why would you have to unset LANG?  What
> exactly do you want to avoid being localized?
>
When apt-get install foo is installing things dpkg prints removing,
unpacking, installing and those need to be mapped to enums
that will be localized in PackageKit frontends.

Thanks,
Daniel.


  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com


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

Re: What is this rule for?

[Don Armstrong]

On Tue, 29 Sep 2009, George Danchev wrote:
> True. However, it makes no big difference whether people use (or
> resp. abuse) file extensions to claim the language a program is
> implemented in, or they do it within the base name. There are plenty
> of apps starring with py* and perl*, (and we have them most for
> years, which is not that different from *.py and *.pl) and I'd
> hesitate to characterize their naming style as tasteless or non-
> Unix way,

Both of these naming styles are annoying. Wasting characters in
commands on non-useful information gets in the way of users doing what
they want to do.

If you're going to stick a command into a directory which is in
PATH,[1] then it should be named as precisely and concisely as
possible, while still being unique. If an executable encodes an
interface which is widely used outside of Debian, then a compatibility
symlink might still be in order, but otherwise, ditch the extension,
submit a patch upstream,[2] and get on with life. [But whatever is
done, don't spend too much time on it; if an upstream is doing this
sort of thing, odds are there are other, more insidious things
lurking, and it'd be a beter use (or waste!) of time trying to find
them.]


Don Armstrong

1: If this is some piddly executable in /usr/lib/foobar/blah.sh, then
it doesn't really matter; the author could call it
blah.sh.because.its.cool.nyatch because presumably no one is going to
actually run the executable directly.

2: It's perfectly fine if its named blah.sh in the source, so long as
it installs as blah on UNIX-y operating systems.
-- 
"Ban cryptography! Yes. Let's also ban pencils, pens and paper, since
criminals can use them to draw plans of the joint they are casing or
even, god forbid, create one time pads to pass uncrackable codes to
each other. Ban open spaces since criminals could use them to converse
with each other out of earshot of the police. Let's ban flags since
they could be used to pass secret messages in semaphore. In fact let's
just ban all forms of verbal and non-verbal communication -- let's see
those criminals make plans now!"

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


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

Re: DEB_MAINTAINER_MODE=1 versus DEB_BUILD_OPTIONS=network.

[Manoj Srivastava]

On Mon, Sep 28 2009, Paul Wise wrote:

> On Tue, Sep 29, 2009 at 9:37 AM, Charles Plessy  wrote:
>
>> in my first experimentations I used DEB_BUILD_OPTIONS, but this leads
>> to the possibility of clashing with flag names that can be reserved
>> later with a different behaviour. On the other hand, if there are
>> enough packages made using the same convention, then we may set the
>> standard by our usage. Would there be other maintainers interested in
>> using a 'network' flag for DEB_BUILD_OPTIONS?
>
> Just use something like DEB_BUILD_OPTIONS=x-check-network until there
> is an option for this enshrined in policy.

Creating a working example, which is used in a number of
 packages (enough packages that most of the kinks in implementation of
 the handling have been worked out) would be a great first step towards
 getting it into policy anyway.

manoj
-- 
I am here by the will of the people and I won't leave until I get my
raincoat back.- a slogan of the anarchists in Richard Kadrey's
"Metrophage"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Bug#548931: ITP: liburcu -- a userspace RCU (read-copy-update) library

[Jon Bernard]

Package: wnpp
Severity: wishlist
Owner: Jon Bernard 

* Package name: liburcu
  Version : 0.1
  Upstream Author : Mathieu Desnoyers 
* URL : http://ltt.polymtl.ca/?q=node/18
* License : GPL, LGPL, MIT/X
  Programming Lang: C
  Description : a userspace RCU (read-copy-update) library

This data synchronization library provides read-side access which scales
linearly with the number of cores. It does so by allowing multiples
copies of a given data structure to live at the same time, and by
monitoring the data structure accesses to detect grace periods after
which memory reclamation is possible.



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

Re: Debconf and PackageKit

[Daniel Nicoletti]

> De: Josselin Mouette

> Currently, the question will simply be ignored, the frontend being set
> to noninteractive when there is no TTY nor display available.
The hard work imo will be if i start in an interactive mode (in the backend)
but when a question needs to popup the user loged out and i need to
ignore the questions..

 
> This is one of the possible solutions indeed. The thing you need is
> actually a new frontend for Debconf, that should probably be based on
> D-Bus so that you can map the authentication and permissions from what
> comes from PackageKit.
> 
> This frontend would actually consist in a middleware that forwards
> requests through D-Bus. The real frontend would be called by the
> PackageKit frontend itself. You could probably directly re-use the
> existing Gnome frontend to show the actual dialogs.
Well I think it might be easy to get accepts by Upstream if
this was a separate app since no change in gnome or kde frontends
would be needed to add a strictly Debian Feature,
I thought of using a socket since it could be chmod to 600 for example.

> > >>>This solution is not implemented as I don't know debconf verry well
> > but there is one problem that I'd like to know if there is a already a way
> > to deal with this:
> > when aptcc backend starts installing packages it's status are in a fd
> > which might be localized is LANG is set, so I clean LANG
> > and get dpkg to give strings like
> > removing, unpacking, that can be converted to an enum.
> 
> Ugh, that’s an absolutely horrible and broken solution. You should use
> the --status-fd dpkg option instead.
hmm ok I'll investigate on how to use that in an apt-get based code..


> > The problem is if i unset LANG debconf is not localized too
> > so the user will see debconf dialog in english.
> 
> This is not a problem. The frontend is responsible for extracting the
> templates (the protocol only tells which questions to ask), and the
> locale in the frontend remains that of the user.
hmm nice to know :D 

> > Please be kind as I'm not familiar with this list :P
> > and don't know debconf and dpkg internals...
> > If you want download PackageKit and please
> > try aptcc :D
> 
> Maybe you should be aware that because of the shortcomings you describe,
> some Ubuntu people started to work on aptdaemon as a possible PackageKit
> replacement, PackageKit being absolutely unsuitable for a Debian-based
> system at the moment. 
Yep I know they worked on aptdaemon but as the author
told me it does not fit well in PackageKit as this could do.

Thanks,
Daniel.



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com


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

Re: Debconf and PackageKit

[Josselin Mouette]

Le mardi 29 septembre 2009 à 11:37 -0700, Daniel Nicoletti a écrit : 
> > Currently, the question will simply be ignored, the frontend being set
> > to noninteractive when there is no TTY nor display available.
> The hard work imo will be if i start in an interactive mode (in the backend)
> but when a question needs to popup the user loged out and i need to
> ignore the questions..

In this case, just don’t set the questions as seen, and that’s all.
They’ll be ignored or re-asked later, depending on the case. You could
also switch to emulating the noninteractive frontend when that happens. 

> > This frontend would actually consist in a middleware that forwards
> > requests through D-Bus. The real frontend would be called by the
> > PackageKit frontend itself. You could probably directly re-use the
> > existing Gnome frontend to show the actual dialogs.
> Well I think it might be easy to get accepts by Upstream if
> this was a separate app since no change in gnome or kde frontends
> would be needed to add a strictly Debian Feature,
> I thought of using a socket since it could be chmod to 600 for example.

I was talking about the Gnome.pm frontend for Debconf.
As for the socket idea, this is just a hack; if you’re working on a
D-Bus-based frontend for APT, you need to use D-Bus for all
communication.

> > Ugh, that’s an absolutely horrible and broken solution. You should use
> > the --status-fd dpkg option instead.
> hmm ok I'll investigate on how to use that in an apt-get based code..

Why do you use apt-get and not libapt? Especially if you’re working on a
C++ frontend…

> Yep I know they worked on aptdaemon but as the author
> told me it does not fit well in PackageKit as this could do.

Yes, OTOH it could fit as a backend to update-manager.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Russ Allbery]

Peter Eisentraut  writes:

> At least in cases where the programs/scripts could be considered part of
> a programming interface, this requirement is approximately equivalent to
> requiring the exported symbols of libraries to conform to some spelling
> scheme.  While Debian has occasionally altered or broken the exported
> interfaces of libraries in cases of severe trouble, this is not
> routinely done, and usually not merely in the name of prettiness.

The argument for the Policy change wasn't about prettiness, but rather
about not encoding the implementation language into the interface name.
When the shell script named foo.sh gets rewritten into Perl, having it
stay foo.sh or be renamed to foo.pl are both kind of broken.

That may not be a good enough argument to continue this policy, but that
was the argument for why it's now in Policy.

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


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

Re: What is this rule for?

[George Danchev]

> On Tue, 29 Sep 2009, George Danchev wrote:
> > True. However, it makes no big difference whether people use (or
> > resp. abuse) file extensions to claim the language a program is
> > implemented in, or they do it within the base name. There are plenty
> > of apps starring with py* and perl*, (and we have them most for
> > years, which is not that different from *.py and *.pl) and I'd
> > hesitate to characterize their naming style as tasteless or non-
> > Unix way,
> 
> Both of these naming styles are annoying. Wasting characters in
> commands on non-useful information gets in the way of users doing what
> they want to do.
> 
> If you're going to stick a command into a directory which is in
> PATH,[1] then it should be named as precisely and concisely as
> possible, while still being unique. If an executable encodes an
> interface which is widely used outside of Debian, then a compatibility
> symlink might still be in order, but otherwise, ditch the extension,
> submit a patch upstream,[2] and get on with life. [But whatever is
> done, don't spend too much time on it; if an upstream is doing this
> sort of thing, odds are there are other, more insidious things
> lurking, and it'd be a beter use (or waste!) of time trying to find
> them.]
> 
> 
> Don Armstrong
> 
> 1: If this is some piddly executable in /usr/lib/foobar/blah.sh, then
> it doesn't really matter; the author could call it
> blah.sh.because.its.cool.nyatch because presumably no one is going to
> actually run the executable directly.
> 
> 2: It's perfectly fine if its named blah.sh in the source, so long as
> it installs as blah on UNIX-y operating systems.

Don,

I hereby agree with the above (hence fully quoted & signed), believe me or 
not. However, I'm afraid that we have some sort of asymmetry at our side, 
since we claim that both (py* vs. *.py) are annoying, but make sure policy 
discriminates only one of them. It is the asymmetry I have mostly misgivings 
with, hence I'd hesitate to use adjectives the authors naming styles.
 
-- 
pub 4096R/0E4BD0AB 


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

Re: Debconf and PackageKit

[Daniel Nicoletti]

> De: Josselin Mouette
> Le mardi 29 septembre 2009 à 11:37 -0700, Daniel Nicoletti a écrit : 
> > > Currently, the question will simply be ignored, the frontend being set
> > > to noninteractive when there is no TTY nor display available.
> > The hard work imo will be if i start in an interactive mode (in the backend)
> > but when a question needs to popup the user loged out and i need to
> > ignore the questions..
> 
> In this case, just don’t set the questions as seen, and that’s all.
> They’ll be ignored or re-asked later, depending on the case. You could
> also switch to emulating the noninteractive frontend when that happens. 
Good :D

> > > This frontend would actually consist in a middleware that forwards
> > > requests through D-Bus. The real frontend would be called by the
> > > PackageKit frontend itself. You could probably directly re-use the
> > > existing Gnome frontend to show the actual dialogs.
> > Well I think it might be easy to get accepts by Upstream if
> > this was a separate app since no change in gnome or kde frontends
> > would be needed to add a strictly Debian Feature,
> > I thought of using a socket since it could be chmod to 600 for example.
> 
> I was talking about the Gnome.pm frontend for Debconf.
> As for the socket idea, this is just a hack; if you’re working on a
> D-Bus-based frontend for APT, you need to use D-Bus for all
> communication.
Well the socket idea was one way to talk to debconf, I could setup an
DBus interface to debconf so that debconf frontends could talk..
I just don't want to create another one.


> > > Ugh, that’s an absolutely horrible and broken solution. You should use
> > > the --status-fd dpkg option instead.
> > hmm ok I'll investigate on how to use that in an apt-get based code..
> 
> Why do you use apt-get and not libapt? Especially if you’re working on a
> C++ frontend…
I do use libapt, but I find it's docs too simple to write a whole aplication,
in the code i do:
result = DoInstall(file_descriptor);
Probably dpkg has some env var to enable this --status-fd, or
maybe this file descriptor is this ( i have to code this part.. :P )

Cheers,
Daniel.



  

Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com


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

LSI MegaRAID SAS 9260-4i and Lenny

[Niccolò Belli]

Hi all,
Is there any way to make it work under Debian Lenny?
I saw only RHE/SLE drivers on the LSI website...
Is there an open source driver? If yes, will it be backported into lenny?

Cheers,
Darkbasic


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

Re: What is this rule for?

[Peter Samuelson]

[George Danchev]
> However, I'm afraid that we have some sort of asymmetry at our side,
> since we claim that both (py* vs. *.py) are annoying, but make sure
> policy discriminates only one of them.

I think that is a historical accident.  Before python got so popular,
language-based prefixes were not common, but suffixes have always been
popular, probably because people came from MS-DOS and its spiritual
descendent, Windows NT.

The other reason suffixes are worse is, again due to influence from
MS-DOS, people don't think of them as part of the name.  And, removing
the suffix does not cause problems with tab completion in the shell.
So it seems less harsh to strip suffixes than to strip prefixes.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: LSI MegaRAID SAS 9260-4i and Lenny

[Ben Hutchings]

On Tue, 2009-09-29 at 21:10 +0200, Niccolò Belli wrote:
> Hi all,
> Is there any way to make it work under Debian Lenny?

Maybe, but you're asking on the wrong list...

> I saw only RHE/SLE drivers on the LSI website...
> Is there an open source driver?

Yes.

> If yes, will it be backported into lenny?

Maybe, if you file a wishlist bug against linux-2.6.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp


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

Re: link to link

[Kishore]

For link ex..:-

seo.kishor...@gmail.com

Re: LSI MegaRAID SAS 9260-4i and Lenny

[Niccolò Belli]

Il 29 settembre 2009 21.47, Ben Hutchings  ha scritto:
> On Tue, 2009-09-29 at 21:10 +0200, Niccolò Belli wrote:
>> Is there any way to make it work under Debian Lenny?
>
> Maybe, but you're asking on the wrong list...

Where shall I ask? I already tried debian-italian without success...

>> Is there an open source driver?
>
> Yes.

Really? Where can I find it?

>> If yes, will it be backported into lenny?
>
> Maybe, if you file a wishlist bug against linux-2.6.

I'll do it, thank you.

Cheers,
Darkbasic


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[David Goodenough]

On Tuesday 29 September 2009, Russ Allbery wrote:
> Peter Eisentraut  writes:
> > At least in cases where the programs/scripts could be considered part of
> > a programming interface, this requirement is approximately equivalent to
> > requiring the exported symbols of libraries to conform to some spelling
> > scheme.  While Debian has occasionally altered or broken the exported
> > interfaces of libraries in cases of severe trouble, this is not
> > routinely done, and usually not merely in the name of prettiness.
>
> The argument for the Policy change wasn't about prettiness, but rather
> about not encoding the implementation language into the interface name.
> When the shell script named foo.sh gets rewritten into Perl, having it
> stay foo.sh or be renamed to foo.pl are both kind of broken.
>
> That may not be a good enough argument to continue this policy, but that
> was the argument for why it's now in Policy.
>
> --
> Russ Allbery (r...@debian.org)   

I am a newcommer to this particular bit of policy, but it occurs to me that
the answer is to add links to the original commands to conform to 
Debian standards while leaving the upstream commands intact.  This 
would then also mean that any documentation or howtos or tutorials
or blogs written around the upstream commands will still work.  Otherwise
not only does Debian have to modify the commands but also all the
documentation and write its own howtos and blogs.  Also somehow
we would need to subvert Google so it finds our copies for Debian users.

David

David


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

Re: What is this rule for?

[Andreas Tscharner]

Gunnar Wolf wrote:

[snip]

And because extensions truly mean nothing. Of course, I can


This is true for Unix/Posix systems, but unfortunately not for Windows 
systems. And if the maintainer of a great Perl script wants his script 
to work on both platforms, he'll probably will name it GreatPerlScript.pl
If the extension .pl is linked with a Perl interpreter in Windows, he'll 
be able to run it on both systems without a prepending "perl"


Don't get me wrong here: I see the reasons for removing the extensions, 
but I think this is a valid point for having one in the first place.


Best regards
Andreas
--
Andreas Tscharner  starf...@sunrise.ch
--
"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs, and the Universe trying
to produce bigger and better idiots. So far, the Universe is winning."
  -- Rich Cook


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

Re: What is this rule for?

[Russ Allbery]

Andreas Tscharner  writes:

> This is true for Unix/Posix systems, but unfortunately not for Windows
> systems. And if the maintainer of a great Perl script wants his script
> to work on both platforms, he'll probably will name it
> GreatPerlScript.pl If the extension .pl is linked with a Perl
> interpreter in Windows, he'll be able to run it on both systems without
> a prepending "perl"

If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows,
he'll be able to run it on both systems as GreatPerlScript.

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


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

Re: What is this rule for?

[Frank Küster]

Russ Allbery  wrote:

> Andreas Tscharner  writes:
>
>> This is true for Unix/Posix systems, but unfortunately not for Windows
>> systems. And if the maintainer of a great Perl script wants his script
>> to work on both platforms, he'll probably will name it
>> GreatPerlScript.pl If the extension .pl is linked with a Perl
>> interpreter in Windows, he'll be able to run it on both systems without
>> a prepending "perl"
>
> If he names it GreatPerlScript on Unix and GreatPerlScript.pl on Windows,
> he'll be able to run it on both systems as GreatPerlScript.

Yes. And those scripts that would run on Windows and expect
GreatPerlScript.pl, but do not run on Unix *only* because the pl is
missing - those script probably don't exist.

Regards, Frank

-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: Policy §10.4 as a divergence from usptream (renamings to remove extensions like .pl and .sh).

[Frank Küster]

David Goodenough  wrote:

> I am a newcommer to this particular bit of policy, but it occurs to me that
> the answer is to add links to the original commands to conform to 
> Debian standards while leaving the upstream commands intact.

That would horribly clutter the bin directories.  I think the approach
with a /usr/share/$packagename/bin/ that contains the old names as
links, and can be added to PATH, is the best we can do for supporting
scripts that assume extensions.

Regards, Frank
-- 
Dr. Frank Küster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grüne KV Miltenberg


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

Re: What is this rule for?

[Russ Allbery]

Frank Küster  writes:
> Russ Allbery  wrote:

>> If he names it GreatPerlScript on Unix and GreatPerlScript.pl on
>> Windows, he'll be able to run it on both systems as GreatPerlScript.

> Yes. And those scripts that would run on Windows and expect
> GreatPerlScript.pl, but do not run on Unix *only* because the pl is
> missing - those script probably don't exist.

Oh, I'm sure they do.  I know that renaming binaries can break
compatibility; I'm not arguing that.  I'm just pointing out that it's not
impossible to do the right thing.

Transition issues certainly still apply.

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


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

Re: renamings to remove extensions

[Cyril Brulebois]

John H. Robinson, IV  (29/09/2009):
> These are what are expected when you use qmail and daemontools the
> DJB way.
> 
>   http://cr.yp.to/unix.html
> 
> We solve the first one with /var/qmail/bin being a symlink to
> /usr/sbin.  We don't solve the latter one at all.
> 
> Debian bug, or DJB bug?

The Debian bug is to have anything DJB-related in the first place.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: What is this rule for?

[Gunnar Wolf]

Andreas Tscharner dijo [Tue, Sep 29, 2009 at 10:35:46PM +0200]:
>> And because extensions truly mean nothing. Of course, I can
>
> This is true for Unix/Posix systems, but unfortunately not for Windows  
> systems. And if the maintainer of a great Perl script wants his script  
> to work on both platforms, he'll probably will name it GreatPerlScript.pl
> If the extension .pl is linked with a Perl interpreter in Windows, he'll  
> be able to run it on both systems without a prepending "perl"
>
> Don't get me wrong here: I see the reasons for removing the extensions,  
> but I think this is a valid point for having one in the first place.

That's the reason we sometimes diverge away from upstream: We don't
cater for the exact same audience, and we might modify their chosen
binary names to make things easier and more coherent for our users.

-- 
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#548972: ITP: gross -- fast and efficient greylist server

[Antonio Radici]

Package: wnpp
Severity: wishlist
Owner: Antonio Radici 


* Package name: gross
  Version : 1.0.2
  Upstream Author : Eino Tuominen , Antti Siira  
* URL : http://code.google.com/p/gross/
* License : BSD
  Programming Lang: C
  Description : fast and efficient greylist server with DNSBL support

Gross is a resource efficient greylist server written in C that supports
greylisting and/or blocking based on DNSRBL so it will not impact legitimate
mails
.
It also contains a milter implementation and natively supports Postfix, Exim and
Sendmail.



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

Re: /var/www is depracated, which directory to use?

[Steve McIntyre]

Tollef wrote:
>
>I realise you've had good an constructive responses for webapps, so
>commenting on /srv in particular:
>
>As I read it, putting stuff there is absolutely not fine.  It's even
>more off-limits than /usr/local (where you can create directories, but
>not remove them).

I'm still unconvinced by /srv personally - we've strived for years in
Debian to make things work as much as possible straight from initial
installation, yet now we're expected to deliberately leave services
unconfigured. I don't think this is progress for most of our users...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Since phone messaging became popular, the young generation has lost the
 ability to read or write anything that is longer than one hundred and sixty
 characters."  -- Ignatios Souvatzis


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

Re: /var/www is depracated, which directory to use?

[Russ Allbery]

Steve McIntyre  writes:

> I'm still unconvinced by /srv personally - we've strived for years in
> Debian to make things work as much as possible straight from initial
> installation, yet now we're expected to deliberately leave services
> unconfigured. I don't think this is progress for most of our users...

I don't think /srv is the answer to any question about "where do Debian
packages put data in their default configuration."  /srv is really
intended to be a place where the local system administrator organizes
their service data, which means we need to let them choose to organize it
however they wish.

I think the real problem here is that we have some missing integration
glue.  A lot of packages want to serve things out via the web by default
unless the sysadmin has indicated that they want control over the URL
space.  Apache sort of provides a way to do that, but it isn't very good.
Other web servers in Debian so far as I know don't at all.  And there
isn't a common interface supported by all of them.

I think we need to put together a standard definition of how a Debian
package can specify "please serve out this data and this CGI script at
these URLs unless the sysadmin has said to leave the web configuration
alone," using a standard API implemented by all web servers in Debian.  I
suspect that will get everyone what they want.

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


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

Re: /var/www is depracated, which directory to use?

[mli...@stacktrace.us]

Russ Allbery wrote:

Steve McIntyre  writes:


I'm still unconvinced by /srv personally - we've strived for years in
Debian to make things work as much as possible straight from initial
installation, yet now we're expected to deliberately leave services
unconfigured. I don't think this is progress for most of our users...


I don't think /srv is the answer to any question about "where do Debian
packages put data in their default configuration."  /srv is really
intended to be a place where the local system administrator organizes
their service data, which means we need to let them choose to organize it
however they wish.

I think the real problem here is that we have some missing integration
glue.  A lot of packages want to serve things out via the web by default
unless the sysadmin has indicated that they want control over the URL
space.  Apache sort of provides a way to do that, but it isn't very good.
Other web servers in Debian so far as I know don't at all.  And there
isn't a common interface supported by all of them.

I think we need to put together a standard definition of how a Debian
package can specify "please serve out this data and this CGI script at
these URLs unless the sysadmin has said to leave the web configuration
alone," using a standard API implemented by all web servers in Debian.  I
suspect that will get everyone what they want.



I agree on this one.

I personally prefer to keep files served by a webserver in /var/www/


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

Re: /var/www is depracated, which directory to use?

[Russ Allbery]

"mli...@stacktrace.us"  writes:

> I personally prefer to keep files served by a webserver in /var/www/

Local sysadmins can of course use that path, but Debian packages aren't
allowed to according to the way most of us have read the FHS.

Debian web application packages should really put their static files in
/usr/share/ and their data files in /var/lib/ just like
every other package does, and then use the web configuration to serve out
the correct parts of the file system.  That way there's never any
accidental, unexpected results from dropping files into an area that a
sysadmin may think they can use for some other purpose.

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


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

Re: renamings to remove extensions

[Steve Langasek]

On Tue, Sep 29, 2009 at 10:05:29AM -0700, John H. Robinson, IV wrote:
> Mike Hommey wrote:

> > I do agree that if everyone but Debian expects foo to be called as
> > foo.pl, there is a bug in Debian.

> /var/qmail/bin/qmail-send
> /command/supervise

> These are what are expected when you use qmail and daemontools the DJB
> way. 

>   http://cr.yp.to/unix.html

> We solve the first one with /var/qmail/bin being a symlink to /usr/sbin.
> We don't solve the latter one at all.

> Debian bug, or DJB bug?

DJB bug.  (And a symlink doesn't make the software FHS-compliant.)

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

Processed: Re: Bug#548661: dpkg: Override package dependencies

[Debian Bug Tracking System]

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

> reassign 548661 apt
Bug #548661 [general] dpkg: Override package dependencies
Bug reassigned from package 'general' to 'apt'.
> 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

Re: Orphaning my packages...

[Kevin B. McCarty]

Bastien ROUCARIES wrote:

> Le mardi 29 septembre 2009 03:04:25, Kevin B. McCarty a écrit :
>> Hi all,
>> 
>> I unfortunately don't have the free time at the moment to do much for
>> the Debian Project, so I'm orphaning my packages.
[...]
>> Cernlib-related (Cernlib is a huge, mostly obsolete set of physics
>> libraries and tools) packages.  These all have corresponding wnpp ITO
>> bugs that can be changed to ITA / closed as desired.  Note, Francois
>> Niedercorn (in CC) has first dibs on these if he wants them.  Francois,
>> if you still do, please reply to debian-devel.
>> 
>> cernlib - #508413
>> cfortran - #508500
> I am not a debian developer but i could comaintain cfortran

If you don't hear from Francois within the next couple days, please feel
free to claim it.  (If you do hear from him, the two of you will have to
work something out.)

Note that I unfortunately will not have the time to co-maintain or
sponsor any uploads.

best regards,

-- 
Kevin B. McCarty 
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751



signature.asc
Description: OpenPGP digital signature

Bug#548661: dpkg: Override package dependencies

[Stefan Monnier]

reassign 548661 apt
thanks

>> But as seen in bug#542095, some dependencies are not really hard, yet
>> you don't want them to be "recommends" because that would be too easy
>> for users to ignore.  So bug#542095 shows that there is a need for
>> something between "recommends" and true dependencies that can only be
>> ignored if the user very specifically requests to ignore this precise
>> dependency (I already ignore all recommends).
> I don't agree that we need something in between. You decide what you want
> to install. the gnome meta-packages doesn't correspond to what you want?
> don't install it and install the various components by hand or create an
> alternative meta-package.

While it's not too difficult to install some of the components by hand
("aptitude show gnome" makes it easy to see which components are
needed), doing it leads to lots of headaches in the long run, since when
new components come around, nothing will tell you about it (and even
less install them for you), and when old ones become replaced or
obsolete, agai nobody will tell you (and even less install the
replacement for you).
That's what the `gnome' package is for, and that's why it's important to
be able to install that package (and other metapackages) rather than
its dependencies.

> You come up with this request only because Josselin Mouette doesn't
> want to drop network-manager to a Recommends or put an alternative
> in place.

Actually, no.  It's a kind of problem that has shown up several times
already in the past, for various reasons.  Sometimes it's just a bug in
the packaging other times the maintainer has good reasons to keep the
dependencies in a particular way, even if they don't fit my needs.

Clearly, the current network-manager-in-gnome issue is the one that
prompted this bug-report, but only because it finally occurred to me
that a good solution to this problem is a more general solution that
gives more power to the end-user.

> The solution exists but because the maintainer doesn't want to
> implement it, you request a third way to respond to your need under
> control of the user.  How is that reasonable?

Because in the world of Free Software, last I heard, giving more control
to the end user is generally considered a good thing, so she doesn't
have to rely on the goodwill/agreement/help of "the men in charge".

>> What alternative solution do you propose if I want to both have wicd
>> and gnome installed?  Or if my system is memory constrained and
>> I want xserver-xorg installed but not hal? Or ...?
> gnome is not required at all, it's only a meta-package, don't install it
> but install manually all the other dependencies.
> For the xserver, talk to the X maintainers or use a lighter distribution.

So for each problem in the packaging dependencies, you advocate to use
a different solution, each one of those with its own set of problems.
Instead, I advocte a single solution that can solve each one of those
problems in a uniform manner: tell the packaging system (I originally
thought dpkg would be a good place for that, but I now realize that APT
is a better place for it) about some constraints that need to be
ignored.  This could include not only Dpends-constraints (as suggested
originally in this bug-report), but also Conflicts-constraints (e.g., so
I can install grub-pc, grub-efi-amd64 and and grub-efi-ia32 on my Debian
rescue USB key).

Clearly, ignoring such constraints is risky business (not like ignoring
"recommends" constraints), so you'd want to force the user to think hard
before doing so, and you'd only let her ignore specific constraints,
you might ask for confirmation before adding such an ignore-constraint
to the list of ignored constraints, and you might even query the user
every once in a while to make sure she still wants to keep those
ignore-constraints.


Stefan



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

Re: DEB_MAINTAINER_MODE=1 versus DEB_BUILD_OPTIONS=network.

[Charles Plessy]

Le Tue, Sep 29, 2009 at 01:12:14PM -0500, Manoj Srivastava a écrit :
> On Mon, Sep 28 2009, Paul Wise wrote:
> 
> > On Tue, Sep 29, 2009 at 9:37 AM, Charles Plessy  wrote:
> >
> >> in my first experimentations I used DEB_BUILD_OPTIONS, but this leads
> >> to the possibility of clashing with flag names that can be reserved
> >> later with a different behaviour. On the other hand, if there are
> >> enough packages made using the same convention, then we may set the
> >> standard by our usage. Would there be other maintainers interested in
> >> using a 'network' flag for DEB_BUILD_OPTIONS?
> >
> > Just use something like DEB_BUILD_OPTIONS=x-check-network until there
> > is an option for this enshrined in policy.
> 
> Creating a working example, which is used in a number of
>  packages (enough packages that most of the kinks in implementation of
>  the handling have been worked out) would be a great first step towards
>  getting it into policy anyway.

Hi all,

since there was no ‘me too’ message in this thread from developers wanting to
optionaly enable network tests, I will keep on using DEB_MAINTAINER_MODE and
will not go further in proposing a new DEB_BUILD_OPTIONS flag.

This said, I will be happy to update my package to use DEB_BUILD_OPTIONS in the
future if some standard emerges.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
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: Policy §10.4 as a divergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Mike Hommey]

On Tue, Sep 29, 2009 at 10:59:03PM +0200, Frank Küster wrote:
> David Goodenough  wrote:
> 
> > I am a newcommer to this particular bit of policy, but it occurs to me that
> > the answer is to add links to the original commands to conform to 
> > Debian standards while leaving the upstream commands intact.
> 
> That would horribly clutter the bin directories.  I think the approach
> with a /usr/share/$packagename/bin/ that contains the old names as
> links, and can be added to PATH, is the best we can do for supporting
> scripts that assume extensions.

That would mean a possibly overlong PATH. A single place for those
scripts would be better.

Mike


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

Bug#548991: ITP: libcriticism-perl -- Perl pragma to enforce coding standards and best-practices

[david wright]

Package: wnpp
Severity: wishlist
Owner: david wright 


* Package name: libcriticism-perl
  Version : 1.02
  Upstream Author : Jeffrey Thalhammer 
* URL : http://search.cpan.org/dist/criticism/
* License : Artistic | GPL-1+
  Programming Lang: Perl
  Description : Perl pragma to enforce coding standards and best-practices
 This pragma enforces coding standards and promotes best-practices by running
 your file through Perl::Critic before every execution. In a production
 system, this usually isn't feasible because it adds a lot of overhead at
 start-up. If you have a separate development environment, you can effectively
 bypass the criticism pragma by not installing Perl::Critic in the production
 environment. If Perl::Critic can't be loaded, then criticism just fails
 silently.



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

Re: /var/www is depracated, which directory to use?

[sean finney]

On Tue, Sep 29, 2009 at 04:12:58PM -0700, Russ Allbery wrote:
> I think the real problem here is that we have some missing integration
> glue.  A lot of packages want to serve things out via the web by default
> unless the sysadmin has indicated that they want control over the URL
> space.  Apache sort of provides a way to do that, but it isn't very good.
> Other web servers in Debian so far as I know don't at all.  And there
> isn't a common interface supported by all of them.

there is, it's called webapps-common[1].  unfortunately what *is* missing
is developers with time to put into maintaining it, which is why it
has not been uploaded or integrated with support for more httpd services.


sean

[1] http://webapps-common.alioth.debian.org/draft-wac/html/
-- 


signature.asc
Description: Digital signature

Re: Res: Debconf and PackageKit

[Raphael Hertzog]

On Tue, 29 Sep 2009, Daniel Nicoletti wrote:
> > I don't understand this part.  Why would you have to unset LANG?  What
> > exactly do you want to avoid being localized?
> >
> When apt-get install foo is installing things dpkg prints removing,
> unpacking, installing and those need to be mapped to enums
> that will be localized in PackageKit frontends.

You want to use dpkg --status-fd  to watch for this information. You
should be able to tell apt to pass this option to dpkg.

IIRC it's not localized in that case. Apt might also use it but dpkg
supports multiple status-fd.

Cheers,
-- 
Raphaël Hertzog


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

Re: Policy §10.4 as a d ivergence from usptrea m (renamings to remove extensions like .pl and .sh).

[Andreas Tille]

On Wed, Sep 30, 2009 at 08:02:57AM +0200, Mike Hommey wrote:
> 
> That would mean a possibly overlong PATH. A single place for those
> scripts would be better.

That's what I meant when I wrote

/usr/not_policy_compliant_named_dust-bin/ [1]

I kept on thinking about this issue and I wonder whether there is a
chance to find a pragmatical solution in the Blends scope.  Knowing that
the initiator of this thread comes form Debian Med Blend and considering
the fact that you might frequently find specific applications in a
certain field and external scripts / programs that are using this API in
the same field of work.  Moreover the Blends maintainer team has control
or at least a good overview about the packages in the field.  So we
might do the following:

  1. Install the policy compliant named executable to /usr/bin
  2. Symlink to this from /usr/share//bin with the
 name choosen by upstream.
  3. Use /etc/profile.d/ to extend the path
 (I just realised that lsb-core package installs /etc/profile.d
  and notice that the suggestion I wanted to make here is just
  implemented.  I definitely have to read about its usage but
  it is exactly what I wanted to implement to extend the PATH
  reasonably.)

There are plans to differentiate system users of a machine whether they
should get the Blend specific settings or not.  Currently this is
implemented for the user menu system based on users in /etc/passwd but
this method sucks for several reasons and has to be enhanced.  But a
way to do this settings for a certain set of users will be implemented
sooner or later - so the question if everybody gets this PATH extension
should be dealt with in the future.

Kind regards

   Andreas.

[1] http://lists.debian.org/debian-devel/2009/09/msg01016.html

-- 
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: /var/www is depracated, which directory to use?

[Russ Allbery]

sean finney  writes:
> On Tue, Sep 29, 2009 at 04:12:58PM -0700, Russ Allbery wrote:

>> I think the real problem here is that we have some missing integration
>> glue.  A lot of packages want to serve things out via the web by
>> default unless the sysadmin has indicated that they want control over
>> the URL space.  Apache sort of provides a way to do that, but it isn't
>> very good.  Other web servers in Debian so far as I know don't at all.
>> And there isn't a common interface supported by all of them.

> there is, it's called webapps-common[1].  unfortunately what *is* missing
> is developers with time to put into maintaining it, which is why it
> has not been uploaded or integrated with support for more httpd services.

Yeah, that looks like the right direction to go.

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