Package: wnpp
Severity: wishlist
Owner: Marco Balmer
* Package name: couriergrey
Version : 0.2.2
Upstream Author : Matthias Wimmer
* URL : http://couriergrey.com
http://mentors.debian.net/package/couriergrey
* License : GPL-3
Programming
On Tue, 1 Nov 2011 15:23:05 -0700
Josh Triplett wrote:
> Bernd Zeimetz wrote:
> > And I believe that NM should not be something gnome should depend on as
> > there are various other ways to configure your network. Imho it should
> > Recommend network-manage | wicd-gtk | similar-tools-if-they-exis
Package: wnpp
Severity: wishlist
Owner: "B. Clausius"
* Package name: pybik
Version : 0.4
Upstream Author : B. Clausius
* URL : https://launchpad.net/pybik
* License : GPL-3+
Programming Lang: Python
Description : 3D Rubik's cube game
Pybik is an inte
Ian Jackson chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: Minified files and source code requirement"):
> > I'd like to poke a little bit at the assumption that these two things are
> > the same and that Debian necessarily uses the GPL term as our definition
> > of source.
>
> I thi
On 10/27/2011 03:03 AM, Charles Plessy wrote:
> Le Wed, Oct 26, 2011 at 07:08:14PM +0200, Raphael Hertzog a écrit :
>>
>> But with more liberal licenses, we should certainly accept that the
>> minified files are their own sources much like we accept any other blob of
>> data under a free license.
>
Dear NMUers,
Please keed in mind that:
1) Uploading to DELAYED/0 doesn't exempt you from the obligation to post
NMU diff to the BTS.
2) It's not OK to upload a fix both a weeks-old RC bug and another one
that has just popped up to DELAYED/0. Such upload should normally go to
DELAYED/5 at le
Package: wnpp
Severity: wishlist
Owner: Olivier Sallou
* Package name: libbio-chado-schema-perl
Version : 0.09010
Upstream Author : Robert Bruels
* URL :
http://search.cpan.org/~rbuels/Bio-Chado-Schema/lib/Bio/Chado/Schema.pm
* License : Artistic or GPL-1+
2011/11/2 Joey Hess :
> Steve McIntyre wrote:
>> I'd like to help, but I may take a while to find time for it...
>
> I would be glad to have you, but there's still room for people with more
> time than us..
>
> --
> see shy jo
>
is there any special condition to help?...i'd love to help..:)
--
Package: wnpp
Severity: wishlist
Owner: Olivier Sallou
* Package name: libdbix-class-tree-nestedset-perl
Version : 0.10
Upstream Author : Ian Docherty
* URL :
http://search.cpan.org/~icydee/DBIx-Class-Tree-NestedSet-0.10/
* License : Artistic or GPL-1+
Pro
Ian Jackson writes:
> One thing we and our users need to be able to do is to modify the code
> we distribute and still continue to take other changes from upstream.
> So any format that is unnecessarily hard to merge (see below for more
> discussion of this) is not suitable.
I think it's importa
Do we have any policy/recommendation forbidding/disadvising having
subdirectories under /usr/bin?
Conventionally, for packages which ship bulk of command line tools with
possible naming conflicts we seems to place them under /usr/lib/PACKAGE
(often regardless them being arch-dep or not)
I am pac
On Wed, Nov 02, 2011 at 06:48:44PM +0100, Sébastien Riccio wrote:
[...]
> I don't understand everything that has been said about this topic,
> I'll ask a simple question:
> are the firmwares going to be included in the firmware-bnx2x package
> anytime soon or is
> there a way to build them and add
On 31.10.2011 14:31, Ben Hutchings wrote:
On Mon, 2011-10-31 at 11:25 +0200, Dmitry Kravkov wrote:
On Sun, 2011-10-30 at 08:06 -0700, Ben Hutchings wrote:
On Sun, 2011-10-30 at 10:49 +0100, Sébastien Riccio wrote:
On 30.10.2011 10:42, Niels Thykier wrote:
Our upstream for (most of) firmware-n
On Nov 02, Yaroslav Halchenko wrote:
> Do we have any policy/recommendation forbidding/disadvising having
> subdirectories under /usr/bin?
We have the FHS, which says that you do not do this.
--
ciao,
Marco
signature.asc
Description: Digital signature
> -Original Message-
> From: Sébastien Riccio [mailto:s...@swisscenter.com]
> >
> > David, we need to either keep on importing changes from the linux tree
> > or get rid of the firmware directory altogether. I notice that one new
> > driver has even added a blob there recently.
> >
> > Ben
I uploaded a new version today which includes the versions requested
by the bnx2x driver in Linux 3.0 and 3.1.
Sorting out the mess upstream will take a little longer...
Ben.
Hi ben, ok thanks for the info!
Sébastien
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with
On Wed, Nov 02, 2011 at 01:31:06PM -0400, Yaroslav Halchenko wrote:
> Do we have any policy/recommendation forbidding/disadvising having
> subdirectories under /usr/bin?
> Conventionally, for packages which ship bulk of command line tools with
> possible naming conflicts we seems to place them un
Marco d'Itri wrote:
> On Nov 02, Yaroslav Halchenko wrote:
>
> > Do we have any policy/recommendation forbidding/disadvising having
> > subdirectories under /usr/bin?
> We have the FHS, which says that you do not do this.
Where? Section 4.5. /usr/bin Most User Commands[1] specfically allows
dir
> Hi,
>
> On Wed, 26 Oct 2011, Adam D. Barratt wrote:
> > http://ftp-master.debian.org/REJECT-FAQ.html
>
> Hum, it looks like some ftpmaster added a new entry in the FAQ (since it's
> dated October 2011). Probably Mike O'Connor since he replied to #646729
> and re-raised its severity.
>
> Mike,
Thank you John for extending my argument with adequate references which
I have swallowed while composing my question email.
And if we are after reading FHS /usr/lib section:
/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by
Package: wnpp
Severity: wishlist
Owner: Sebastian
* Package name: qasmixer-l10n
Version : 0.15.0
Upstream Author : Sebastian Holtermann
* URL : http://xwmw.org/qasmixer
* License : GPL-3
Programming Lang: C++
Description : Localization package for QasM
Thank you Steve !
With all due respect -- I disagree with your lines of
reasoning/support.
> The per-package subdir should be created instead under
> /usr/lib, and /usr/bin/cmtk can dispatch subcommands over there.
as I and John argued, FHS doesn't mandate them to be
under /usr/lib and actually
Russ Allbery wrote:
> I think a better line is whether the source tarball includes all the
> pieces required for someone with appropriate skills to make modifications
> to the software with reasonable ease. The advantage of that, as opposed
> to trying to weigh whether upstream has additional adv
Package: wnpp
Severity: wishlist
Owner: Sebastian
* Package name: qasconfig-l10n
Version : 0.3.0
Upstream Author : Sebastian Holtermann
* URL : http://xwmw.org/qasconfig
* License : GPL-3
Programming Lang: C++
Description : Localization package for Qas
Jonathan Nieder writes:
> Russ Allbery wrote:
>> I think a better line is whether the source tarball includes all the
>> pieces required for someone with appropriate skills to make
>> modifications to the software with reasonable ease. The advantage of
>> that, as opposed to trying to weigh whet
On Tue, 01 Nov 2011 17:54:14 +0100, Florian Reitmeir
wrote:
>i believe a way of installing network-manager, but disabling it
>completly would be enough for many people.
I would be misleading if a software is installed, but disabled. Leads
debugging people into the wrong direction.
Greetings
Marc
]] Florian Reitmeir
Hi,
| i believe a way of installing network-manager, but disabling it
| completly would be enough for many people.
like update-rc.d disable network-manager or dpkg-divert --rename --local
/usr/sbin/NetworkManager or just using equivs?
Cheers,
--
Tollef Fog Heen
UNIX is use
On Wed, Nov 02, 2011 at 03:43:08PM -0400, Yaroslav Halchenko wrote:
> Thank you John for extending my argument with adequate references which
> I have swallowed while composing my question email.
>
> And if we are after reading FHS /usr/lib section:
>
> /usr/lib includes object files, librar
On Thu, 27 Oct 2011 09:08:37 +0200, Raphael Hertzog wrote:
> On Thu, 27 Oct 2011, Paul Wise wrote:
> > On Thu, Oct 27, 2011 at 1:08 AM, Raphael Hertzog wrote:
> > > I don't agree that minified files are a violation of DFSG #2. If the
> > > library is under the GPL then it would be a problem becaus
On Wed, 02 Nov 2011, Mike O'Connor wrote:
> > > What is the preferred form for modification for a work (aka source) is
> > > highly context-dependent.
> >
> > I share entirely the opinion of Russ who replied to this specific point.
>
> Am I misreading you? or are you making an argument here that
On Wed, 02 Nov 2011, Roger Leigh wrote:
> > Altogether, according to FHS /usr/lib/PKG is actually not preferable
> > location for them since indeed it is for solely internal use (and it is
> > now used to keep shared libraries)
> This is just nitpicking over the precise wording used.
really? s
On Wed, Nov 02, 2011 at 03:53:04PM -0400, Yaroslav Halchenko wrote:
> Thank you Steve !
> With all due respect -- I disagree with your lines of
> reasoning/support.
> > The per-package subdir should be created instead under
> > /usr/lib, and /usr/bin/cmtk can dispatch subcommands over there.
> a
Package: wnpp
Severity: wishlist
Owner: "Ondřej Surý"
* Package name: knot
Version : 0.8.0
Upstream Author : CZ.NIC Labs
* URL : http://www.knot-dns.cz/
* License : GPL
Programming Lang: C
Description : authoritative domain name server
Knot DNS is a f
thanks once again
> Your understanding is misguided. If you intend it to be a user interface,
> it belongs on the PATH. If you don't, it belongs under /usr/lib.
I hear you regarding that ideally they should be on the PATH...
but -- nothing in FHS talks about PATH.
thoughts aloud:
science c
On Wed, 2 Nov 2011 13:31:06 -0400
Yaroslav Halchenko wrote:
> Do we have any policy/recommendation forbidding/disadvising having
> subdirectories under /usr/bin?
[...]
> I have checked FHS which only says:
> "The following directories, or symbolic links to directories, must be
> in /usr/bin...
On Wed, 2 Nov 2011 18:41:20 -0400
Yaroslav Halchenko wrote:
> thanks once again
>
> > Your understanding is misguided. If you intend it to be a user
> > interface, it belongs on the PATH. If you don't, it belongs
> > under /usr/lib.
>
> I hear you regarding that ideally they should be on the
On Wed, 02 Nov 2011, Yaroslav Halchenko wrote:
> really? since when it is nitpicking to quote FHS verbatim? once
> again:
>
> "The following directories, or symbolic links to directories, must be in
> /usr/bin, if the corresponding subsystem is installed:
>
> Directory Description
>
Karl Goetz (03/11/2011):
> I don't have a link at the moment (because linuxfoundation
> bugzilla/bzr/etc is still MIA), but I'm pretty sure its been clarified
> forbidding subdirs in any of the (s)bin directories for FHS 3.0 (and
> the exceptions you cite have also been removed).
> If/when all the
On Thu, 03 Nov 2011, Karl Goetz wrote:
> Not sure what you're trying to suggest here? The FHS *is* clear on what
> goes in /usr/games:
> games Games and educational binaries (optional)
I wasn't really suggesting anything I guess... just objected suggested
PATH-driven interpretation of what go
thanks Cyril -- that indeed clarifies it (finally)!
it is all clear now that users would need to invoke them from under
/usr/lib/
Cheers,
P.S. so no need for me to repost it to fhs-discuss now I guess ;)
On Thu, 03 Nov 2011, Cyril Brulebois wrote:
> In the meanwhile, posted by Jeff Licquia[2]:
Tollef Fog Heen wrote:
]] Florian Reitmeir
| i believe a way of installing network-manager, but disabling it
| completly would be enough for many people.
like update-rc.d disable network-manager or dpkg-divert --rename --local
/usr/sbin/NetworkManager or just using equivs?
sure, it also woul
On Wed, 2 Nov 2011 19:11:11 -0400
Yaroslav Halchenko wrote:
>
> On Thu, 03 Nov 2011, Karl Goetz wrote:
> > Not sure what you're trying to suggest here? The FHS *is* clear on
> > what goes in /usr/games:
> > games Games and educational binaries (optional)
>
> I wasn't really suggesting anyth
On Sun, Oct 30, 2011 at 01:14:59PM +0100, Frank lin Piat wrote:
> > On Sun 30/10/11 11:31 , Daniel Baumann wrote::
> > > On 10/29/2011 08:49 PM, Frank lin Piat wrote:
> >> I intend to submit a mass bug filling to ask packages maintainer to drop or
> >> downgrade their dependency on "menu":
> >
> >
Am 03.11.2011 00:15, schrieb Yaroslav Halchenko:
> it is all clear now that users would need to invoke them from under
> /usr/lib/
If at all, the binaries would need to be placed into
/usr/lib/. But as Steve already said, if those binaries are
part of the interface and supposed to be called by th
44 matches
Mail list logo
