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 ove
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 whet
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
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
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
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
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 na
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
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 o
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
(
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 qmai
"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 sta
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
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 ou
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 uncon
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 gr
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 pl
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?
T
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
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
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 .
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
> in
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 GreatPerl
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
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 the
For link ex..:-
seo.kishor...@gmail.com
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 l
[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
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 "unsubscr
> 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
> 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*, (an
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
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 whe
> 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 n
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-
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,
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
> 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 locali
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.
>
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
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, the
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 upstr
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 )
> ||
> || (so
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
> 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
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 (Deb
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
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
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 t
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/d
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 d
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: PinYi
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
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
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 res
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 warn
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
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:/
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
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 Te
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 p
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 apprec
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 c
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, other
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
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
* 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
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
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 comman
"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
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 ne
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. T
72 matches
Mail list logo
