Bug#647356: ITP: couriergrey -- Mail filter interface of Courier-MTA to support greylisting

[Marco Balmer]

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 Lang: C++
  Description : Mail filter interface of Courier-MTA to support greylisting

 Couriergrey implements the mail filter interface of Courier MTA to
 support the greylist filtering method.
 .
 The software supports the IPv6 protocol, and is easy to use.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2002071258.28538.65961.report...@mbalmer.nine.ch

Re: Bug#645656: network-manager in Gnome

[Neil Williams]

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-exist.
> 
> Those packages do not provide the NetworkManager DBus interface expected
> by other components of GNOME.

I've not noticed any lack of functionality. There again, I regard less
notifications as an improvement in functionality. I probably don't have
the "other components of GNOME" installed.

(In case it matters, I tried the new gnome-session and didn't like the
whole lack-of-menu/fading-with-icons thing, so I'm using
gnome-session-fallback. I don't know if it affects things other than
the panels or notifications. I'm not 100% happy with the fallback
either TBH.)

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpVtlbl4lkXl.pgp
Description: PGP signature

Bug#647390: ITP: pybik -- 3D Rubik's cube game

[B. Clausius]

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 interactive, graphical, single player puzzle.
This program renders an image of a cube, like that invented
by Erno Rubik. You have to manipulate the cube using the mouse. When each
face shows only one color, the game is solved.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002084641.24507.60582.reportbug@System7

Re: Minified files and source code requirement

[Uoti Urpala]

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 think it's a good rule of thumb.  Another alternative formulation is
> that the source is the form actually used by upstream to make their
> modifications.

I think that rule of thumb is not as practical as you seem to assume.


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

Who qualifies as "upstream"? What if upstream reformats his own code (the
version he himself works on) every week, making merging changes from past
versions difficult? Does that render his code "non-free" in your opinion?


> So considering minified JS: even if we run a formatter over it to put
> the whitespace back, what we have differs from source code in the
> following ways:
> 
>  * The variable names are still all smashed, so it's hard to see
>what's going on;
> 
>  * Future versions from upstream may suffer from wholesale changes,
>invalidating our local patches, if upstream change their minifier
>or perhaps even if they make minor changes to the original source.
>(Eg sequentially named variables might all get changed.)
> 
>  * The original source may have been transformed by an optimiser into
>something which is much harder to edit due to being more fragile.

As for the first and third points, Russ clearly talked about versions that _are
suitable_ for modification. If the code is unreasonably unreadable or fragile
then it doesn't pass that test either. As for the second, there are various
unambiguously free modifications that cause the same problems.


> Also I think the question of fairness is important: someone who forks
> the work based on the source code in Debian should not inherently be
> in a worse a position than the original author, as regards ability to
> modify and update the work.  
> 
> Now obviously there are all sorts of advantages to original authors:

So you accept that this "not inherently worse" requirement is not reasonable in
practice, but you still insist that it should be strictly followed in at least
one case?


> But I think we should draw the line at software whose original authors
> prevent us from using the most convenient form for our modifications.
> That is not Free Software and it should not be in Debian.

Why should we draw the line there? If original author A is a dick and withholds
something, while original author B is an idiot and writes bad code, should the
code from author B really be preferred? Even if the code from author A is
overall a perfectly reasonable free software project and much more convenient to
modify (even given the missing data) than the code from author B?


> Otherwise where are we to draw the line ?  The difference between
> being editing minified javascript, or deliberately-obfuscated C, or
> preprocessed C, or C compiled to assembly language, or even C compiled
> to object files, is just a matter of degree in awkwardness, not a
> difference in kind.

You do have to draw the line at some arbitrarily picked unimportant difference.
If you are not willing to accept this fact you'll end up arguing for completely
absurd positions.

Suppose someone starts with a sourceless binary blob released under a free
license. He runs a decompiler on it, producing a C file that contains unreadable
messy code. He then edits the file, each change a minimal one that modifies a
couple of lines. Eventually he has a C file that is higher quality than the one
the original blob was produced from (at which point this happens may be
impossible to know for people who don't have the original source). He then
continues fixing bugs and adding features, eventually completely superseding the
original blob. In the end his version is unambiguously the "upstream source". At
exactly which minimal change do you draw the line?


> And asking for the *actual source* is in no way unreasonable, if
> upstream are claiming to be a Free Software or Open Source project.

I think that involving the other upstream behavior this way (as opposed to the
specific code considered for inclusion in Debian by itself) is problematic when
talking about basic "what is considered free software" or "what is acceptable in
Debian" questions. Does previously unacceptable software really turn acceptable
if the upstream says "OK we deleted those files so we don't have them either"?
At what point does a fork become the "new upstream" that is modifying the code
without using those files (after all the assumption was that even without those
files the code was in a reasonably modifiable form, so they wouldn't be
necessary to 

Re: Minified files and source code requirement

[Bernd Zeimetz]

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.
> 
> Hello Raphaël and everybody,
> 
> one of the problem with minified JavaScript libraries is that it is difficult
> to know what they really do.  Are they really what the upstream author thinks
> they are, or was he tricked in cut-and-pasting a fake version containing a
> spyware ?
> 
> On the other hand, if the minified file you would like to distribute matches
> exactly a minified file that has been distributed by Debian in the past, then
> indeed, why not running that version ?  You are an experienced developer and I
> trust you to understand, balance and negociate the costs and benefits on a
> case-by-case basis.

Because even the old minified version should not have been distributed
unless we have the not minified version available (at least in the
source of the package), too?

> For the compliance with DFSG – and this is the main message here – we could
> reach it considering all the packages that are part of the same release, by
> using the dpkg source format 3.0 (git), which would be an efficient way to
> distribute past source versions and point at the preferred one at the same
> time.

How the source is distributed does not matter. Please don't abuse this
for yet another dpkg 3.0 git discussion.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb11b45.5000...@bzed.de

Friendly reminder to NMUers

[Jakub Wilk]

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


Similarly, if your NMU combines a fix for weeks-old RC bug with a fix 
for a minor bug, the appropriate delay is 10 days, not 0.


Reference:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-guidelines

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002103031.ga8...@jwilk.net

Bug#647416: ITP: libbio-chado-schema-perl -- object-relational mapping layer for use with the GMOD Chado database schema

[Olivier Sallou]

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+
  Programming Lang: Perl
  Description : object-relational mapping layer for use with the GMOD Chado 
database schema

This is a standard object-relational mapping layer for use with the GMOD Chado 
database schema.
This layer is implemented with DBIx::Class, generated with the help of the very 
fine DBIx::Class::Schema::Loader module.
Chado is an open-source modular database schema for biological data. It is 
divided into several notional "modules", which are reflected in the namespace 
organization of this package. Note that modules in the Chado context refers to 
sets of tables, they are not modules in the Perl sense.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2002131738.29034.70434.report...@debiansid.genouest.org

Re: seeking comaintainer for debmirror

[shero azura]

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..:)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAO_xynnnzndhaYsxasYjApjZJw5Sa6Yc9O=w0rgnocxexwk...@mail.gmail.com

Bug#647417: ITP: libdbix-class-tree-nestedset-perl -- Manage trees of data using the nested set model

[Olivier Sallou]

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+
  Programming Lang: Perl
  Description : Manage trees of data using the nested set model

Manage trees of data using the nested set model



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2002134124.29178.39101.report...@debiansid.genouest.org

Re: Minified files and source code requirement

[Russ Allbery]

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 important to realize here that we've now drifted away from
the original topic (whether something is free software by our definition)
and into a question of bugginess, maintainability, and suitability for the
Debian archive for non-DFSG reasons.

You have a reasonable point about being concerned about upstream practices
that make it very difficult for us to maintain Debian-specific patches, or
for our users to modify the software without having to irrevocably fork
it.  But that's tricky territory with a lot of tradeoffs, and it's not
directly related to DFSG freeness.  If it were, we would have to consider
non-free the previous free releases of upstream software whose subsequent
releases are now non-free, since obviously one cannot merge new upstream
changes there at all.  We don't do that for good reasons.

> Another way to look at this is that if what we have is actually the
> ouput of some automated process done by upstream from secret (or
> unpalatably licensed) input files, anyone who modifies our source
> package will be committing the cardinal programming sin of editing an
> output file.

I don't think this line is as clear as it sounds.  I know of several
software packages where the source code was originally output from some
other tool, but even upstream now tweaks the output instead of re-running
the tool; either the tool is impractical, or in many cases has actually
been lost.

> Also I think the question of fairness is important: someone who forks
> the work based on the source code in Debian should not inherently be in
> a worse a position than the original author, as regards ability to
> modify and update the work.

I agree with this as a general ethical principle that I personally would
follow, but this is not an explicit requirement of the DFSG, and I don't
think we should write it into the DFSG implicitly.  As I mentioned in my
previous message, there are a lot of ways to create such a disadvantage,
and we don't enforce many of them.

To take a specific example, the upstream of GNAT, the Ada compiler, makes
use of a very comprehensive and exhaustive validation test suite when
making changes to the compiler.  People who do not have access to that
test suite are in an inherently worse position with respect to their
ability to modify and update the compiler, but that test suite is not free
software; it contains, among other things, large numbers of test cases
that upstream developed from code provided by companies with support
contracts which was only provided under an NDA or non-free licenses.  I
don't believe that makes GNAT non-free under the DFSG.

> Now obviously there are all sorts of advantages to original authors:
> they are most familiar with the code; they may have private tools which
> help with editing the source; they have the benefit of the inertia of
> downstreams; etc.

Exactly.

> But I think we should draw the line at software whose original authors
> prevent us from using the most convenient form for our modifications.
> That is not Free Software and it should not be in Debian.

I don't think there's anything magical about that particular line, which
is the extent of what I'm arguing.  I do agree that this might frequently
make the software non-free, but I don't think it's something about which
one can write a hard and fast rule without having to think about it a
little bit.

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 advantages, is that
it's a judgement call that can be made solely based on the contents of the
source tarball without reference to anything external.

Although yes, we may need to make some special exceptions for software
where *no one* can make modifications with reasonable ease because the
tools required to do so have all been lost, which I suppose does come
closer to your point.  But I think that's a relatively rare case, to the
point where it can probably be considered as one-by-one exceptions.

>> For example, suppose I include an image in a piece of software that I
>> generated by taking a digital photograph of something in RAW,
>> manipulating it in Photoshop, and then exporting it as a JPEG.  What's
>> the source?  In the GPL sense, one can make an argument that the
>> original RAW image is the preferred form for modification, since if I
>> had it available I'd probably use it rather than the JPEG to make
>> further changes.

> No, the source is not the RAW image.  It is the Photoshop file, which
> contains the additional layers information and me

directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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 packaging CMTK, where upstream agreed also to deliver a wrapper
script (/usr/bin/cmtk) so there would be a single point of entry to run
any needed command (in similar fashion to git), but also he made all
cmdline tools become available from ... /usr/bin/CMTK

I have checked FHS which only says:
"The following directories, or symbolic links to directories, must be in 
/usr/bin..."

so it seems to be ok to have subdirectories under /usr/bin (for /bin
there is strict "must not"), and I failed to find something in
debian policy forbidding or allowing taht.  So would it be ok?

I kinda like that setup because then user doesn't need to
search anywhere under /usr/lib for a script I need from CMTK -- it
becomes available where I would expect it to find -- under
/usr/bin(/CMTK)

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002173106.gh10...@onerussian.com

Re: Debian unstable/expirental missing some bnx2 firmwares

[Ben Hutchings]

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 them manually on a debian unstable
> machine ?
 
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.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002175501.gx3...@decadent.org.uk

Re: Debian unstable/expirental missing some bnx2 firmwares

[Sébastien Riccio]

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-nonfree is the linux-firmware
repository, and it appears that Broadcom never sent version 6.2.9.0 of
the bnx2x firmware there.  It's also possible that the request was
dropped somewhere along the way.


Hi Ben,
The firmware was submitted to firmware/bnx2x folder using
96b8e1a0e96bd30ffb07e739b29b8c4c5759b93f in IHEX form with appropriate
changes in firmware/Makefile and firmware/WHENCE.

So it's in the linux tree but not linux-firmware?  Well that's fairly
useless.

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 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 them manually on a debian unstable 
machine ?


thanks :)

Sébastien


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb1827c.40...@swisscenter.com

Re: directory under /usr/bin -- Ok or not?

[Marco d'Itri]

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

RE: Debian unstable/expirental missing some bnx2 firmwares

[Dmitry Kravkov]

> -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 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 them manually on a debian unstable
> machine ?

We should add the FW to linux-firmware, then you will be able to take it from 
there

David,
do you want me to provide the firmware files for your tree, or you will be
able build it from linux tree by yourself?

Thanks

Re: Debian unstable/expirental missing some bnx2 firmwares

[Sébastien Riccio]

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 a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb1889c.1070...@swisscenter.com

Re: directory under /usr/bin -- Ok or not?

[Steve Langasek]

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 under /usr/lib/PACKAGE
> (often regardless them being arch-dep or not)

> I am packaging CMTK, where upstream agreed also to deliver a wrapper
> script (/usr/bin/cmtk) so there would be a single point of entry to run
> any needed command (in similar fashion to git), but also he made all
> cmdline tools become available from ... /usr/bin/CMTK

> I have checked FHS which only says:
> "The following directories, or symbolic links to directories, must be in 
> /usr/bin..."

> so it seems to be ok to have subdirectories under /usr/bin (for /bin
> there is strict "must not"), and I failed to find something in
> debian policy forbidding or allowing taht.  So would it be ok?

No, it's not ok.  The per-package subdir should be created instead under
/usr/lib, and /usr/bin/cmtk can dispatch subcommands over there.

/usr/bin is on the path.  Subdirs of /usr/bin are not on the path and should
not have to be added.  Therefore there is no point in having subdirs of
/usr/bin, regardless of whether the FHS currently makes it explicit that
it's prohibited.

(It actually *is* a requirement from the FHS, because the FHS says that a
subdir in /usr/lib is the place where things must be placed; there's just no
backlink from the definition of /usr/bin that makes this clear without
reading the full FHS for context.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: directory under /usr/bin -- Ok or not?

[John H. Robinson, IV]

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
directories, going so far as to explictly mentioning one directory, and
mandating a link to another directory.

You may be thinking of Section 3.4.2 Requirements[2] which forbids
directories; however that section refers only to /bin.

  [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 19
  [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 5

-- 
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
Archive: http://lists.debian.org/2002182428.ga4...@a.mx.sbih.org

Re: Minified files and source code requirement

[Mike O'Connor]

> 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, it would be still nice to have some official answer to
> <20111027070837.gm...@rivendell.home.ouaza.com>. At least so that the
> reasoning of the FTP masters is recorded for posterity.
> 
> I'm not going to argue further since it looks like the consensus seems to
> be to enforce this requirement for this specific case.
> 
> It would still be nice if ftpmasters mailed debian-devel when they
> extend their FAQ to rule on new kinds of issues.
> 

Raphael,

It wasn't I who edited the FAQ, nor am I an ftpmaster.  I don't believe
that this FAQ entry was made in order to make a rule on a new kind of
issue.  I think it is to clarify a misconception that seems to be
becoming more common about "what is the source code".  I don't belive
that this stance we are taking about what constitutes source code is at
all a new one.

stew


pgpADfk4cJqTE.pgp
Description: PGP signature

Re: directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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 users or shell scripts.

and in my case it becomes more interesting -- those tools *are intended*
to be executed by (interested) users directly.  It is just due to proliferation
in number of the tools and conflicts with other packages they cannot go under
/usr/bin directly.

That is why for this package (as for few others we maintain already) we
are shipping also /etc/PKG/pkg.sh script so (interested) users could
source to have their PATH adjusted to get preference to execute tools
from the PKG instead of possibly available conflicting one under
/usr/bin.   Wrapper script shipped directly under /usr/bin/ is only for
possible future adoption  since at the moment all users (and their
scripts) rely on direct names of the cmdline tools.

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)

On Wed, 02 Nov 2011, John H. Robinson, IV 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
> directories, going so far as to explictly mentioning one directory, and
> mandating a link to another directory.

> You may be thinking of Section 3.4.2 Requirements[2] which forbids
> directories; however that section refers only to /bin.

>   [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 19
>   [1] http://www.pathname.com/fhs/pub/fhs-2.3.pdf pg 5
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002194308.gi10...@onerussian.com

Bug#647448: ITP: qasmixer-l10n -- Localization package for QasMixer

[Sebastian]

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 QasMixer

QasMixer is a volume mixer application for the Linux sound 
architecture ALSA.

This is the localization(l10n) package for QasMixer.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002194852.27352.58759.reportbug@blauwal

Re: directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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 allows for subdirectories under /usr/bin
(more below)

> /usr/bin is on the path.

100% correct

> Subdirs of /usr/bin are not on the path 

also 100% correct, although could be made to be on the path (as any
other directory) upon user's intent, and could be executed "directly"

> and should not have to be added.
> (It actually *is* a requirement from the FHS, because the FHS says that a
> subdir in /usr/lib is the place where things must be placed; there's just no
> backlink from the definition of /usr/bin that makes this clear without
> reading the full FHS for context.)

as I have mentioned -- I see nowhere such a requirement, Moreover:

 - FHS seems to allow subdirectories under /usr/bin:
   "The following directories, or symbolic links to directories, must be
   in /usr/bin ..."
 
   and gives a nice example:

   "mh  Commands for the MH mail handling system (optional)"

 - /usr/lib is destined for 
   "/usr/lib includes object files, libraries, and internal binaries
   that are not intended to be executed directly by users or shell
   scripts"

   so indeed anything which cannot be executed directly -- should go
   there.  But "executed directly" in my understanding is not solely
   being on the PATH -- if I can execute a tool via
   /usr/lib/PKG/bin/xxx -- it is direct execution  and thus should not
   be hidden under /usr/lib


-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002195304.gj10...@onerussian.com

Re: Minified files and source code requirement

[Jonathan Nieder]

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 advantages, is that
> it's a judgement call that can be made solely based on the contents of the
> source tarball without reference to anything external.

Do we agree that minified Javascript libraries do not meet this
criterion (for non-broken definitions of "reasonable")?  If so, I'd
leave the other theoretical cases for until someone proposes an
appropriate wording for a change to the constitution or policy (so
then we can have the shared goal of debugging that wording[*]).

If not, of course, that point of disagreement seems like a good place
to focus the discussion.

Hope that helps,
Jonathan

[*] of course, the current wording ("The program must include source
code") is buggy because vague.  But that's harder to debug without an
example people disagree about.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002195530.ga17...@elie.hsd1.il.comcast.net

Bug#647450: ITP: qasconfig-l10n -- Localization package for QasConfig

[Sebastian]

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 QasConfig

The configuration of the Linux sound system ALSA 
resides in a tree structure which is built by reading several 
configuration files like /etc/asound.conf and ~/.asoundrc.
QasConfig is a simple browser for this configuration tree
and can help to analyze and debug an ALSA setup.

This is the localization(l10n) package for QasConfig.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002200137.27576.48892.reportbug@blauwal

Re: Minified files and source code requirement

[Russ Allbery]

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 whether upstream has additional
>> advantages, is that it's a judgement call that can be made solely based
>> on the contents of the source tarball without reference to anything
>> external.

> Do we agree that minified Javascript libraries do not meet this
> criterion (for non-broken definitions of "reasonable")?

Given what's been described in this thread, yes, I don't think it's
reasonable to expect people to modify minified Javascript.

-- 
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
Archive: http://lists.debian.org/874nymthkd@windlord.stanford.edu

Re: Bug#645656: network-manager in Gnome

[Marc Haber]

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
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1rlh9c-0004rg...@swivel.zugschlus.de

Re: Bug#645656: network-manager in Gnome

[Tollef Fog Heen]

]] 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 user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y5vy6yj3@qurzaw.varnish-software.com

Re: directory under /usr/bin -- Ok or not?

[Roger Leigh]

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, libraries, and internal binaries that
> are not intended to be executed directly by users or shell scripts.
> 
> and in my case it becomes more interesting -- those tools *are intended*
> to be executed by (interested) users directly.  It is just due to 
> proliferation
> in number of the tools and conflicts with other packages they cannot go under
> /usr/bin directly.
[...]
> 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.  In practice,
this *is* where they belong, and it is what every other package does
(for example, postgresql).  You can add that specific directory to
your path, should you choose.

When considering the divide between "internal use" and "for users",
consider that if it's for users to invoke then it should simply be
in the default path.  It's not typical to need to add special
directories to one's path, and it's certainly not encouraged or
recommended.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002204856.gj28...@codelibre.net

Re: Minified files and source code requirement

[Mike O'Connor]

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 because it's not the
> > > preferred form of modification.
> > 
> > I think this is exactly the same as xserver-xorg-video-nv, which
> > contained obfuscated C code instead of the actual source code. I
> > personally considered that a DFSG violation but I guess you would not?
> 
> I would consider it a DFSG violation. It's all a matter of intent.

I don't think we should use the author's intent when trying to determine
of a work of software is DFSG free.  I don't think we have a good reason
to make such a compromise.

> Obfuscated != minified.
> 
> In one case we have unreadable C code where you don't have access to
> the unobfuscated version and this was done on purpose by the upstream
> authors to make it difficul to understand what the code does.

In this case we have unreadable javascript code where you don't know
whether or not you have access to the unobfuscated version or not and
although this may or may not have been done on purpose by the authors to
make it more difficult to understand, it has that effect regardless.
> 
> In the other case you have unreadable javascript code but you can easily
> find the corresponding source code on numerous places (sometimes in the
> corresponding Debian package, sometimes in an older version of it on
> snapshot.debian.org and generally on its upstream website). The
> minification was not even done by the upstream that uses that file but
> by the original project who delivers both files. The minification is not
> done to make it more difficult to understand the code or make changes, but
> to save time when downloading the file.
> 
> Requiring the non-minified file to be provided in the same source package
> is not a very productive use of our time. In particular if you don't go
> to the step beyond which is to modify the upstream build process to
> regenerate the minified file from the original one. Otherwise modifying
> that file in the source and rebuilding it does not have the expected
> result.

In the case where the code is generated from source code in another
package, it seems to make sense to me to package this separately.  I
think we need to have the 'preferred form of modification' available to
the end user in order to comply with the spirit of the DFSG.  I also
don't think it is feasible to expect that the FTP team would go
searching for other projects and try to find the minified version of the
javascript file in some other project then try to determine if it is
actually generated from its source before deciding if we are complying
with the spirit of the DFSG.

To me, telling the user that the minified javascript is usable and
editable as source is close to saying "yeah, we don't have the C code
that generated this but you can disassemble it and edit the asm."

I agree that it is more useful to the user if we make sure that the
minimized javascript be able to be regenerated when you edit the source
and rebuild.

> 
> I think it's great to encourage this sane behaviour, but it's not a
> bug that's worth a serious severity.
> 
> > 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 it might be
preferred to edit minimized javascript instead of the original? 

stew


pgpv8jrZqWwLT.pgp
Description: PGP signature

Re: Minified files and source code requirement

[Raphael Hertzog]

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 it might be
> preferred to edit minimized javascript instead of the original? 

You're misreading me. Russ gave other examples where the preferred form
of modification implied much more than something convenient to do
modifications. Cf mid:87k47r2e3x@windlord.stanford.edu

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/go/ulule-rh/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002211134.ga19...@rivendell.home.ouaza.com

Re: directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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?  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
mh  Commands for the MH mail handling system (optional)"

?

> In practice,
> this *is* where they belong, and it is what every other package does
> (for example, postgresql).  You can add that specific directory to
> your path, should you choose.

and I have been doing that for quite a few packages myself -- so I am
quite aware of this current "common practice".  And that is why I
actually decided to check among standards and ask here either it
is mandated, because I always felt that executing anything from /usr/lib
felt awkward.

You might consider me blind or naive -- but so far none of the arguments
for not having a subdirectory under /usr/bin had any strongly supported
argument.

> When considering the divide between "internal use" and "for users",
> consider that if it's for users to invoke then it should simply be
> in the default path.  It's not typical to need to add special
> directories to one's path, and it's certainly not encouraged or
> recommended.

Well -- that is all cool and in an ideal world  I am with you on this
one.  BUT it is often the case (e.g.  with scientific software) that
suite provide bulk of (>100) cmdline tools.  Some of those come without
unique names and are already widely used by people running Debian or
whatnot, so changing their habbits/scripts is not as easy as "lets just
renamed them".  Sure thing we recommend upstream either coming up with
custom prefixes/unique names or gateway wrappers to avoid conflicts
and/or reduce hit on the proliferation of namespace of cmdline tools...
But once again -- it ain't happening at once and for all, so let's
not discuss this aspect further here.


-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002211926.gk10...@onerussian.com

Re: directory under /usr/bin -- Ok or not?

[Steve Langasek]

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.

> as I and John argued, FHS doesn't mandate them to be
> under /usr/lib and actually allows for subdirectories under /usr/bin
> (more below)

The subdirectories of /usr/bin that are allowed in the FHS are spelled out
because they are exceptions.

>  - /usr/lib is destined for 
>"/usr/lib includes object files, libraries, and internal binaries
>that are not intended to be executed directly by users or shell
>scripts"

>so indeed anything which cannot be executed directly -- should go
>there.  But "executed directly" in my understanding is not solely
>being on the PATH -- if I can execute a tool via
>/usr/lib/PKG/bin/xxx -- it is direct execution  and thus should not
>be hidden under /usr/lib

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.

It is a bug in the FHS that it allows for this interpretation, but I have no
doubt that it is a bug and which way the FHS would be clarified to fix this
hole.

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

Bug#647461: ITP: knot -- authoritative domain name server

[Ondřej Surý]

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 fast, authoritative only, high performance, feature
 full and open source name server.
 .
 Knot DNS is developed by CZ.NIC Labs, the R&D department of .CZ
 registry and hence is well suited to run anything from the root
 zone, the top-level domain, to many smaller standard domain names.
 .
 Note: this release is still EXPERIMENTAL and you should know what
 you are doing and be able to write bug reports.



Note for this bug: this will go first to experimental distribution.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2002221518.4359.50727.reportbug@localhost6.localdomain6

Re: directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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 could indeed be considered a  game -- may be I should advise
   on such PATH-driven interpretation and ask upstream to place
   their binaries under /usr/games then which is in the PATH -- then we
   should all be compliant with our intertrepations of FHS ;)   damn...
   there is only 1 /usr/games so once again -- conflicts conflicts
   conflicts

not sure if of any point, since the list seems to be only full of
SPAM I have posted my question to [1].

[1] 
http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.com&forum_name=freestandards-fhs-discuss

Cheers,

On Wed, 02 Nov 2011, Steve Langasek wrote:

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

> > as I and John argued, FHS doesn't mandate them to be
> > under /usr/lib and actually allows for subdirectories under /usr/bin
> > (more below)

> The subdirectories of /usr/bin that are allowed in the FHS are spelled out
> because they are exceptions.

> >  - /usr/lib is destined for 
> >"/usr/lib includes object files, libraries, and internal binaries
> >that are not intended to be executed directly by users or shell
> >scripts"

> >so indeed anything which cannot be executed directly -- should go
> >there.  But "executed directly" in my understanding is not solely
> >being on the PATH -- if I can execute a tool via
> >/usr/lib/PKG/bin/xxx -- it is direct execution  and thus should not
> >be hidden under /usr/lib

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

> It is a bug in the FHS that it allows for this interpretation, but I have no
> doubt that it is a bug and which way the FHS would be clarified to fix this
> hole.
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002224119.gm10...@onerussian.com

Re: directory under /usr/bin -- Ok or not?

[Karl Goetz]

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..."
> 
> so it seems to be ok to have subdirectories under /usr/bin (for /bin
> there is strict "must not"), and I failed to find something in
> debian policy forbidding or allowing taht.  So would it be ok?

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 infrastructure comes back, you can find links to them
at [1].

[1]
http://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-August/000334.html

thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: directory under /usr/bin -- Ok or not?

[Karl Goetz]

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 PATH...
> but -- nothing in FHS talks about PATH.
> 
> thoughts aloud:
> 
>science could indeed be considered a  game -- may be I should
> advise on such PATH-driven interpretation and ask upstream to place
>their binaries under /usr/games then which is in the PATH -- then
> we should all be compliant with our intertrepations of FHS ;)
> damn... there is only 1 /usr/games so once again -- conflicts
> conflicts conflicts

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)

> not sure if of any point, since the list seems to be only full of
> SPAM I have posted my question to [1].
> 
> [1]
> http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.com&forum_name=freestandards-fhs-discuss

This is not the proper location for FHS discussion, [1] is.

[1] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss

thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: directory under /usr/bin -- Ok or not?

[Don Armstrong]

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
> mh  Commands for the MH mail handling system (optional)"

There are exactly two packages in Debian which have subdirectories in
/usr/bin: mailutils-mh, and nmh. Nothing else does this, and having mh
do it in the first place seems to be a historical mistake. [The only
other slight exception is /usr/bin/X11, and we've done away with that
by making it X11 a symlink to .]

A package which uses names that are so general that it conflicts with
existing binary names and thus can't be stuck in /usr/bin by default
probably shouldn't be normally executed directly by users or scripts
in the first place. It shouldn't be encouraged to put such a package's
directories into PATH, either.


Don Armstrong

-- 
Herodotus says, "Very few things happen at the right time, and the
rest do not happen at all. The conscientious historian will correct
these defects".
 -- Mark Twain _A Horse's Tail_

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
Archive: http://lists.debian.org/2002224627.gf26...@teltox.donarmstrong.com

Re: directory under /usr/bin -- Ok or not?

[Cyril Brulebois]

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 infrastructure comes back, you can find links to them
> at [1].
> 
> [1]
> http://lists.linuxfoundation.org/pipermail/fhs-discuss/2011-August/000334.html

In the meanwhile, posted by Jeff Licquia[2]:

  “This draft removes quite a few historical artifacts, such as
   /usr/X11R6 and subdirectories in /usr/bin, and adds many recent
   developments, including /sys and /run.”

 2. 
https://www.linux.com/news/software/linux-kernel/493031:feedback-requested-filesystem-hierarchy-standard-released

Which should clarify the situation.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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 goes under /usr/bin

> > http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.com&forum_name=freestandards-fhs-discuss
> This is not the proper location for FHS discussion, [1] is.
> [1] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss

ah -- thanks -- I just followed a link on
http://www.pathname.com/fhs/
will repost to fhs-discuss now

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/200223.gn10...@onerussian.com

Re: directory under /usr/bin -- Ok or not?

[Yaroslav Halchenko]

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

>   “This draft removes quite a few historical artifacts, such as
>/usr/X11R6 and subdirectories in /usr/bin, and adds many recent
>developments, including /sys and /run.”

>  2. 
> https://www.linux.com/news/software/linux-kernel/493031:feedback-requested-filesystem-hierarchy-standard-released

> Which should clarify the situation.
-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002231536.go10...@onerussian.com

Re: Bug#645656: network-manager in Gnome

[Florian Reitmeir]

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 would be nice to get a question for disabling it by 
default, while installing, if a /etc/network/interface file is found. it 
would save many people a lot of pain.


--
Florian Reitmeir
E-Mail: flor...@reitmeir.org
Tel: +43 650 2661660


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb1cf79.20...@reitmeir.org

Re: directory under /usr/bin -- Ok or not?

[Karl Goetz]

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 anything I guess... just objected suggested
> PATH-driven interpretation of what goes under /usr/bin

ok

> > > http://sourceforge.net/mailarchive/forum.php?thread_name=200553.GL10325%40onerussian.com&forum_name=freestandards-fhs-discuss
> > This is not the proper location for FHS discussion, [1] is.
> > [1] https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss
> 
> ah -- thanks -- I just followed a link on
> http://www.pathname.com/fhs/

Not sure who can fix that page, a few links need updating to the new
location. The page source mentions Daniel Quinlan, if you're interested
in following up perhaps try him.

> will repost to fhs-discuss now

For FHS 3.0 its already changed to No subdirectories in {,/usr}/(s)bin.
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group


signature.asc
Description: PGP signature

Re: Possible mass bug filling for package depending on "menu".

[Bill Allombert]

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":
> >
> >[...]
> >
> > packages that need root have to use su-to-root in order to play well on
> > live systems (where you know at runtime if sudo, su, gksu, $whatever has
> > to be used). your package list contains such cases. [..]
> 
> What about moving the su-to-root binary to a different binary package ?
> Bill what's your PoV about spliting it ?

I am not very keen creating a new Debian package for a 3kB script.

I already answered that numerous time. See bugs #535064 and #514882.  Making
Debian-specific changes to .desktop files should be avoided if possible, since
they cannot be merged upstream. So it would be better if xdg-utils would
provide a script xdg-su that could be used by .desktop files and works on all
XDG systems, not just Debian.

The real issue is that nobody is really maintaining the XDG menu system.

Cheers,
Bill.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2002234829.GA2515@yellowpig

Re: directory under /usr/bin -- Ok or not?

[Michael Biebl]

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 the user, then they
belong on the PATH.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature