Packages that should use "interest-noawait" trigger directive

[Raphael Hertzog]

[ Bccing the maintainers of packages quoted in this mail ]

Hi,

On Fri, 23 Sep 2011, Raphael Hertzog wrote:
> * There are some new trigger directives ("interest-noawait" and
>   "activate-noawait") that work like the existing directives except
>   that packages activating the triggers are not put in the
>   "triggers-awaited" status, they go straight to "installed" or
>   "triggers-pending". The difference is significant because packages
>   in "triggers-awaited" do not satisfy dependencies and can thus
>   force an early trigger processing that we'd like to avoid.
> 
>   If the trigger processing is not critical for the activating package
>   to actually work, then you should consider using these new
>   directives. If you do so, you will have to add a
>   “Pre-Depends: dpkg (>= 1.16.1)” to ensure the new dpkg is
>   installed even before your package is unpacked. If you're not
>   sure whether it's safe to add this Pre-Depends on your package,
>   please consult debian-devel@lists.debian.org for advice. See
>   deb-triggers(5) for details on this new feature.

Let's save some time and discuss immediately in which case it's worth
to add a Pre-Depends and to make use of this feature.

IMO the main criteria is the number of packages that are activating the
trigger. As such, packages like "man-db", "python-support", "menu",
"hicolor-icon-theme", "shared-mime-info", "gnome-menus",
"desktop-file-utils" are probably good candidates. Except for
shared-mime-info I already verified with the respective maintainers that
those are good candidates for this new directive, i.e. activating packages
can be considered configured straight away.

It's much less important for very specialised triggers like the lintian
one which detects when a new locale package is installed.

That said dpkg is traditionnaly one of the package that release notes
recommend to upgrade first (together with apt/aptitude) so in general
the supplementary Pre-Depends do not cause any complication in the
upgrade process. Thus I don't mind if packages with low-impact triggers
will want to switch to the new directive too. Others might have differing
opinion, we'll see. The few packages that should not use such a Pre-Depends
are the one that dpkg (transitively) pre-depends on.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110923065310.gc11...@rivendell.home.ouaza.com

Re: alternative dependency ordering - with respect of packages in main

[Adam Borowski]

On Thu, Sep 22, 2011 at 05:14:32PM -0500, Matt Zagrabelny wrote:
> Hi Bruce,
> 
> >> > I hope Debian would honour the Social Contract and put the needs of the
> >> > users ahead of software freeness concerns in that case.
> >>
> >> Do we have a name for the DFSG equivalent of Godwin's Law?  Because you
> >> just failed it.
> >
> > Well, that's disappointing... called a Nazi for daring to explore the
> > possibilities. 
> 
> I think you misread what Steve was saying. When you were calling out
> those who are concerned about software free-ness, you were calling
> them "Nazis". Steve was not calling you a Nazi.

I for one parsed his statement as:

In any discussion that involves the line "Our priorities are our users
and free software", someone will use the first half to completely
disregard the second and say anything non-free is ok as long as it might
be useful to an user.

-- 
1KB // Yo momma uses IPv4!


signature.asc
Description: Digital signature

Re: alternative dependency ordering - with respect of packages in main

[Matt Zagrabelny]

Hi Bruce,

>> > I hope Debian would honour the Social Contract and put the needs of the
>> > users ahead of software freeness concerns in that case.
>>
>> Do we have a name for the DFSG equivalent of Godwin's Law?  Because you
>> just failed it.
>
> Well, that's disappointing... called a Nazi for daring to explore the
> possibilities. 

I think you misread what Steve was saying. When you were calling out
those who are concerned about software free-ness, you were calling
them "Nazis". Steve was not calling you a Nazi.

Anyhow...

If we don't have software free-ness, we don't really have much of a
social contract.

-mz


--
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/caolfk3wimovdqj7bryziw5jix1cs+bezebs-rbydqzbv+py...@mail.gmail.com

Re: alternative dependency ordering - with respect of packages in main

[Bruce Sass]

On September 22, 2011 12:23:00 PM Jonas Smedegaard wrote:
> On 11-09-22 at 08:19am, Bruce Sass wrote:
> > On September 22, 2011 02:50:25 AM Gerfried Fuchs wrote:
> > > * Bruce Sass  [2011-09-21 23:18:54 CEST]:
> > > > Debian already favours Main packages by default
> > >  
> > >  Not if the alternative dependency chain has a non-free package
> > > 
> > > first. I know what you mean with that non-free isn't enabled by
> > > default, but the way the dependency chain is written still favours
> > > non-free packages by default, when available -- which is the thing
> > > you like to emphasis on, but the favour is still the other way
> > > round.
> > 
> > I disagree. The only way a non-free package is going to be
> > automatically selected is if the sysadmin has added non-Main lines to
> > sources.list, and the Maintainer has placed a non-Main package before
> > one from Main in the dependency statement--that's two explicit actions
> > that need to be taken, compared to zero if non-Main stuff isn't
> > wanted.
> 
> Another way a non-free package gets automatically selected is if some
> package which conflicts with the free alternative, when the package
> containing non-free alternative (no matter the order) is installed.

Wouldn't that be a technical issue, and not something which could be fixed by 
adjusting the dependency statements or how the tools parse them?


-- 
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/201109221615.54767.bms...@shaw.ca

Re: alternative dependency ordering - with respect of packages in main

[Steve Langasek]

On Thu, Sep 22, 2011 at 10:25:06PM +0200, Bill Allombert wrote:
> >  I know that the buildd system likes to pull in the first package in
> > such an alternative dependency chain.  And now I start to wonder:

> >  Is it allowed for a package in main to have a package _outside_ of main
> > as first component of an alternative dependency?  The package in
> > question is extremely unlikely to ever be used as Build-Depends, so this
> > is of a more general question.

> >  What also might be used as argument is the social contract, DFSG #4:
> > "Our priorities are our users and free software" -- it can be argued
> > that we don't put the priority on free software in such a case.

> >  tl;dr - what do you think, is a "Depends: foo-contrib | foo" acceptable
> > for packages in main or should it be "Depends: foo | foo-contrib"
> > instead?

> Policy 2.2.1 forbid both usages: it says:

>  the package must not declare a "Depends", "Recommends", or "Build-Depends"
>  relationship on a non-_main_ package

> Nowhere in policy there is an indication that the first alternative is
> special.

That is a bug in the policy wording.  What is meant by "Depends
relationship" and "Recommends relationship" is "the package must not under a
normal configuration cause a package outside of main to be pulled in to
satisfy the dependency", which is the *relationship* expressed; it does not
mean that a non-free package may not appear anywhere in the Depends *field*.

> I suggest that foo-contrib Provides: foo instead.

Are you sure that can't give results that are contrary to policy's intent?
Whereas 'Depends: foo | foo-contrib' will always install the real 'foo' by
preference, as far as I know once you make foo-contrib Provides: foo,
'Depends: foo' could result in 'foo-contrib' being given preference
arbitrarily.  Or does apt have a guarantee that real packages will be given
preference, or that main packages will be given preference over non-free
ones, when resolving virtual packages?

In any case, you can't have versioned provides, so there are some use cases
where this would still not be sufficient.

-- 
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: alternative dependency ordering - with respect of packages in main

[Bruce Sass]

On September 22, 2011 12:06:11 PM Steve Langasek wrote:
> On Thu, Sep 22, 2011 at 08:19:32AM -0600, Bruce Sass wrote:
> > >  So *every* time a package outside of main is an installation candidate
> > > 
> > > the decision should be made, not once, very much indeed.
> > 
> > As someone who doesn't care about licences
> 
> Since this effectively translates to not caring about the freedom of the
> software you install, I think it's safe to say you're in the minority among
> Debian users - and certainly among Debian developers.

Your translation is off. It is simply a consequence of not being in a position 
where the restrictions that come with any license which allow Debian to 
distribute the software are relevent to my use of it.

> I'm confident that Debian will continue to prefer to install only free
> software as dependencies when installing from main, even when contrib and
> non-free are enabled on the system.

As am I.

> > I disagree. The only way a non-free package is going to be automatically
> > selected is if the sysadmin has added non-Main lines to sources.list, and
> > the Maintainer has placed a non-Main package before one from Main in the
> > dependency statement--that's two explicit actions that need to be taken,
> > compared to zero if non-Main stuff isn't wanted.
> 
> The latter is not something the maintainer is allowed to do, because it's
> making a decision for non-free software *on behalf of the user*.
> 
> If the free alternative doesn't work well enough to be listed first, then
> the package depending on it belongs in contrib, *not* in main.

That's my understanding of how things should be setup.

> > I hope Debian would honour the Social Contract and put the needs of the
> > users ahead of software freeness concerns in that case.
> 
> Do we have a name for the DFSG equivalent of Godwin's Law?  Because you
> just failed it.

Well, that's disappointing... called a Nazi for daring to explore the 
possibilities. 


-- 
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/201109221553.54795.bms...@shaw.ca

Re: alternative dependency ordering - with respect of packages in main

[Bill Allombert]

On Tue, Sep 20, 2011 at 01:12:37PM +0200, Gerfried Fuchs wrote:
> Hi!
> 
>  Policy is clear on packages in main aren't allowed to depend on
> packages outside of main.  Now in a fair amount of cases this has been
> worked around by having the package outside of main as alternative
> dependency and a package in main offer basic functionality for the
> package to still be able to work.
> 
>  I know that the buildd system likes to pull in the first package in
> such an alternative dependency chain.  And now I start to wonder:
> 
>  Is it allowed for a package in main to have a package _outside_ of main
> as first component of an alternative dependency?  The package in
> question is extremely unlikely to ever be used as Build-Depends, so this
> is of a more general question.
> 
>  What also might be used as argument is the social contract, DFSG #4:
> "Our priorities are our users and free software" -- it can be argued
> that we don't put the priority on free software in such a case.
> 
>  tl;dr - what do you think, is a "Depends: foo-contrib | foo" acceptable
> for packages in main or should it be "Depends: foo | foo-contrib"
> instead?

Policy 2.2.1 forbid both usages: it says:

 the package must not declare a "Depends", "Recommends", or "Build-Depends"
 relationship on a non-_main_ package

Nowhere in policy there is an indication that the first alternative is special.

I suggest that foo-contrib Provides: foo instead.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
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/20110922202506.GB15478@yellowpig

Bug#642472: ITP: aces2 -- Advanced Concepts in Electronic Structure II

[Michael Banck]

Package: wnpp
Severity: wishlist
Owner: Michael Banck 

* Package name: aces2
  Version : 2.8.0
  Upstream Author : Quantum Theory Project, University of Florida
* URL : http://www.qtp.ufl.edu/ACES
* License : GPL
  Programming Lang: Fortran
  Description : Advanced Concepts in Electronic Structure II

 ACESII is an electronic structure calculation program with a focus on
 correlated methods like many-body perturbation theory or
 coupled-cluster theory.  It is the non-parallelized predecessor to 
 ACESIII but some of its methods are not yet availble in ACESIII, most
 notably analytic gradients for the following methods:
  * Fourth order many-body perturbation theory (MP4)
  * Coupled-cluster singles and doubles (CCSD) or including perturbative
triples (CCSD(T))
  * Quadratic Configuration-interaction singles and doubles (QCISD) or
including perturbative triples (QCISD(T))



-- 
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/20110922200348.ga4...@nighthawk.chemicalconnection.dyndns.org

Bug#642452: SetUID-enabled binary doesn't run as root

[Julien Cristau]

On Thu, Sep 22, 2011 at 13:56:47 -0500, Jeffrey G Thomas wrote:

> > > chgrp -R staff /home/wvincent/public_html/lps/sites
> > > chgrp: changing group of 
> > > `/home/wvincent/public_html/lps/sites/default/files/feeds/studiolocations.csv':
> > >  Operation not permitted
> > 
> > I'm afraid that sounds like a bug in your program.
> 
> I don't see where that is a bug, when the command itself is displayed on the 
> console and fails.  Not to say that you're wrong, but the command is being 
> built and run properly it appears to me.
> 
I don't know what your program does, so I'm not going to guess further.
If you have something that can be reproduced by other people then please
share this, otherwise I don't think there's much more we can do.

Cheers,
Julien



-- 
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/20110922190224.gk3...@radis.liafa.jussieu.fr

Bug#642452: marked as done (SetUID-enabled binary doesn't run as root)

[Debian Bug Tracking System]

Your message dated Thu, 22 Sep 2011 20:52:30 +0200
with message-id <20110922185230.ga8...@radis.liafa.jussieu.fr>
and subject line Re: Bug#642452: SetUID-enabled binary doesn't run as root
has caused the Debian Bug report #642452,
regarding SetUID-enabled binary doesn't run as root
to be marked as done.

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

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


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

*** Please type your report below this line ***
We have a custom C binary that checks for permitted paths and users, and if 
those checks pass, our binary runs as set-uid (as root) chmod and chgrp on some 
directories.

The general idea is that our programmers can correct permissions on folders to 
allow wider access for the other programmers, assuming the checks all pass.

Note this isn't *always* a problem, on either the 32 nor 64 bit machines 
discussed below.  Running the chmod and chgrp commands as root from the command 
line works fine when these fail.

This SetUID option works fine on Debian 5 machines here, but on Debian 6 x64 
(x86.64) we get SegFaults:
cweber@athens:~/public_html/lps$ chperms `pwd`
Segmentation fault

and on Debian 6 x86.32 we get 'Operation not permitted':
wvincent@athens:~/public_html/lps/sites$ chperms `pwd`
chgrp -R staff /home/wvincent/public_html/lps/sites
chgrp: changing group of 
`/home/wvincent/public_html/lps/sites/default/files/feeds/studiolocations.csv': 
Operation not permitted
chgrp: changing group of 
`/home/wvincent/public_html/lps/sites/default/files/feeds': Operation not 
permitted
chmod -R g+wrx /home/wvincent/public_html/lps/sites
chmod: changing permissions of 
`/home/wvincent/public_html/lps/sites/default/files/feeds': Operation not 
permitted
chmod: changing permissions of 
`/home/wvincent/public_html/lps/sites/default/files/feeds/studiolocations.csv': 
Operation not permitted 



The file in question does have its permissions set correctly AFAICT:
-rwsr-sr-x 1 root root 7860 Sep  1 14:24 /bin/chperms.orig

The same file should be running on both Debian6 x86.64 and x86.32

root@berlin:~# file /bin/chperms.orig
/bin/chperms.orig: setuid setgid ELF 32-bit LSB executable, Intel 80386, 
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, 
stripped

athens:~# file /bin/chperms.orig 
/bin/chperms.orig: setuid setgid ELF 32-bit LSB executable, Intel 80386, 
version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, 
stripped





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

Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


--- End Message ---
--- Begin Message ---
On Thu, Sep 22, 2011 at 13:07:28 -0500, Jeffrey G Thomas wrote:

> Package: setuid
> Severity: normal
> 
> *** Please type your report below this line ***
> We have a custom C binary that checks for permitted paths and users, and if 
> those checks pass, our binary runs as set-uid (as root) chmod and chgrp on 
> some directories.
> 
> The general idea is that our programmers can correct permissions on folders 
> to allow wider access for the other programmers, assuming the checks all pass.
> 
> Note this isn't *always* a problem, on either the 32 nor 64 bit machines 
> discussed below.  Running the chmod and chgrp commands as root from the 
> command line works fine when these fail.
> 
> This SetUID option works fine on Debian 5 machines here, but on Debian 6 x64 
> (x86.64) we get SegFaults:
> cweber@athens:~/public_html/lps$ chperms `pwd`
> Segmentation fault
> 
> and on Debian 6 x86.32 we get 'Operation not permitted':
> wvincent@athens:~/public_html/lps/sites$ chperms `pwd`
> chgrp -R staff /home/wvincent/public_html/lps/sites
> chgrp: changing group of 
> `/home/wvincent/public_html/lps/sites/default/files/feeds/studiolocations.csv':
>  Operation not permitted

I'm afraid that sounds like a bug in your program.

Cheers,
Julien

--- End Message ---

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Jonas Smedegaard]

On 11-09-22 at 05:03pm, Jérémy Lal wrote:
> On 22/09/2011 16:54, Paul Tagliamonte wrote:
> > I think this would be better as libnode-which

> It will probably be named "libnode-which" but i started a discussion 
> on pkg-javascript-devel about that naming scheme [1]

Until that other discussion eventually turn into a decision, please 
stick to the current naming scheme.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Processed: Re: Bug#642452: SetUID-enabled binary doesn't run as root

[Debian Bug Tracking System]

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

> reassign 642452 general
Bug #642452 [setuid] SetUID-enabled binary doesn't run as root
Warning: Unknown package 'setuid'
Bug reassigned from package 'setuid' to 'general'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
642452: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642452
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.131671579622342.transcr...@bugs.debian.org

Re: alternative dependency ordering - with respect of packages in main

[Jonas Smedegaard]

On 11-09-22 at 08:19am, Bruce Sass wrote:
> On September 22, 2011 02:50:25 AM Gerfried Fuchs wrote:
> > * Bruce Sass  [2011-09-21 23:18:54 CEST]:
> > > Debian already favours Main packages by default
> > 
> >  Not if the alternative dependency chain has a non-free package 
> > first. I know what you mean with that non-free isn't enabled by 
> > default, but the way the dependency chain is written still favours 
> > non-free packages by default, when available -- which is the thing 
> > you like to emphasis on, but the favour is still the other way 
> > round.
> 
> I disagree. The only way a non-free package is going to be 
> automatically selected is if the sysadmin has added non-Main lines to 
> sources.list, and the Maintainer has placed a non-Main package before 
> one from Main in the dependency statement--that's two explicit actions 
> that need to be taken, compared to zero if non-Main stuff isn't 
> wanted.

Another way a non-free package gets automatically selected is if some 
package which conflicts with the free alternative, when the package 
containing non-free alternative (no matter the order) is installed.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: alternative dependency ordering - with respect of packages in main

[Steve Langasek]

On Thu, Sep 22, 2011 at 08:19:32AM -0600, Bruce Sass wrote:
> >  So *every* time a package outside of main is an installation candidate
> > the decision should be made, not once, very much indeed.

> As someone who doesn't care about licences

Since this effectively translates to not caring about the freedom of the
software you install, I think it's safe to say you're in the minority among
Debian users - and certainly among Debian developers.

I'm confident that Debian will continue to prefer to install only free
software as dependencies when installing from main, even when contrib and
non-free are enabled on the system.

> I disagree. The only way a non-free package is going to be automatically 
> selected is if the sysadmin has added non-Main lines to sources.list, and the 
> Maintainer has placed a non-Main package before one from Main in the 
> dependency statement--that's two explicit actions that need to be taken, 
> compared to zero if non-Main stuff isn't wanted.

The latter is not something the maintainer is allowed to do, because it's
making a decision for non-free software *on behalf of the user*.

If the free alternative doesn't work well enough to be listed first, then
the package depending on it belongs in contrib, *not* in main.

> I hope Debian would honour the Social Contract and put the needs of the
> users ahead of software freeness concerns in that case.

Do we have a name for the DFSG equivalent of Godwin's Law?  Because you just
failed it.

-- 
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: Re: Proxy compliance and assistance.

[Mike Mestnik]

On Wed, 21 Sep 2011 at 14:13:31 -0500, Mike Mestnik wrote:

I'd like to start a movement to verify and assist projects/packages
with the proper deployment of software that supports proxies.


In GLib-based applications, connecting using GSocketClient while having
glib-networking installed will automatically use a configured proxy; this
is much less ongoing maintenance burden than adding specific proxy support
to every networked application, so please use this route where feasible in
GLib/GNOME applications, rather than repeatedly writing app-specific proxy
code. Recent versions of telepathy-gabble (as used by Empathy for XMPP) will
automatically pick up GNOME/KDE proxy settings in this way, for instance.

(There's probably an equivalent thing I could say about Qt/KDE applications,
if I knew Qt better.)

This is the kind of information I'd intend to propagate and turn into 
release goals.  Understanding that there's more then one way...   Debian 
may need a centralised configuration where all of the deployed 
back-ends(GSocketClient/Qt/other:apt:wget:axel) would be configured.


Let me make myself clear, "I fully support and advocate using 
centralised librarys, especially when they implement tasks common to 
many applications."


However the real work is a little different then that Utopia.  I belive 
that leeway should be given in the short term for things that are deemed 
important.  I belever that proxy support is so important.



What I need most of all is community support, it's no good to
confront developers or package maintainers that are insistent on
rebelling against the use of proxies.


There's an important difference between "I think proxies don't matter" and
"I think this particular patch to support use of proxies is more maintenance
burden than it's worth"; be careful not to mistake the second for the first.
Part of a maintainer's job is to say "no" to things they're not going to be
able to maintain in future.

Well, I'll say one thing.  I'm a little bit retarded so forgive me as 
there should be some one other then me doing PR(I rather like Paul 
Wise's comments, nice work...  Don't take that the wrong way I 
understand you don't have the time.) anything I'm involved in.  I 
understand that the following point of view is likely to be overkill, 
however if no-one is willing to stake a flag down in there utopia then 
any line drawn could be misplaced.


If an application, any application, lacks proxy support and a patch 
exists that's five lines enabling environment variables then in the 
absence of any other patch it should be...


A. Disabled by default, but compiled in at least one package.

There is no point in fighting about the better way if the person 
advocating the better way is not willing or able to do anything more 
then put pen to paper.  Either write a better patch or get out of the 
way of progress.


I can't understand why this "I don't like it." attitude would ever fly. 
 There are plenty of ways to guard against new code from causing 
problems...  For example "Disabled by default" could mean that the code 
is only executed when a new command line flag is present.  The dev. can 
put a patch on top of the submitted patch to ensure any level of 
disabling they are comfortable with.  There is even a possibility to 
split the proxy support out into another binary package if it's the only 
way to work around technical issues.


This "It might not work attitude" is worthless if it is working and I 
assure you that proxy support is nothing to cry weapons of mass 
destruction over.  It's completely harmless, even if done improperly. 
*Beyond the average rate of failure for any additional patch.



I for one would tend to reject a patch to add a "full" proxy implementation
to any network application that I maintained, but I'd be more likely to accept
a patch that used GProxyResolver or g_socket_client_add_application_proxy
(for GLib code) or something like libproxy or pacrunner (for non-GLib code).

Again, if you want it done right then you'll just have to do it 
yourself.  When it's a this is un-usable in a given environment there 
just needs to be a solution, instead of excuses.



S



--
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/4e7b6f16.9020...@mikemestnik.net

Re: RE : Re: Proxy compliance and assistance.

[Simon McVittie]

On Thu, 22 Sep 2011 at 18:31:46 +0200, Bastien ROUCARIES wrote:
> See libproxy package

> Le 22 sept. 2011 12:10, "Simon McVittie"  a écrit :
> In GLib-based applications, connecting using GSocketClient while having
> glib-networking installed will automatically use a configured proxy

FYI, that currently uses libproxy behind the scenes, although I think there
might be plans to make it use pacrunner instead/as well. libproxy is fine
as a way to get proxy support too.

Using the facilities in GLib is probably better for already-GLib-based
projects, though, since it's implementation-neutral and makes sure to do the
Javascript stuff out-of-process (proxy auto-configuration needs a Javascript
interpreter!), both for performance (one Javascript-engine instance shared
between apps) and stability (you really don't want two incompatible versions
of libmozjs, or the Webkit equivalent, in your process space).

S


-- 
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/20110922170359.ga13...@reptile.pseudorandom.co.uk

Re: Re: Bug#616317: base: commit= ext3 mount option in fstab has no effect.

[Kalyuzhnyy, Ilya - Contractor]

I`ll check it out, thanks.

RE : Re: Proxy compliance and assistance.

[Bastien ROUCARIES]

See libproxy package

It could be improved but it. Work

Bastien

Le 22 sept. 2011 12:10, "Simon McVittie"  a écrit :

On Wed, 21 Sep 2011 at 14:13:31 -0500, Mike Mestnik wrote:
> I'd like to start a movement to verify ...
In GLib-based applications, connecting using GSocketClient while having
glib-networking installed will automatically use a configured proxy; this
is much less ongoing maintenance burden than adding specific proxy support
to every networked application, so please use this route where feasible in
GLib/GNOME applications, rather than repeatedly writing app-specific proxy
code. Recent versions of telepathy-gabble (as used by Empathy for XMPP) will
automatically pick up GNOME/KDE proxy settings in this way, for instance.

(There's probably an equivalent thing I could say about Qt/KDE applications,
if I knew Qt better.)


> What I need most of all is community support, it's no good to
> confront developers or package ma...
There's an important difference between "I think proxies don't matter" and
"I think this particular patch to support use of proxies is more maintenance
burden than it's worth"; be careful not to mistake the second for the first.
Part of a maintainer's job is to say "no" to things they're not going to be
able to maintain in future.

I for one would tend to reject a patch to add a "full" proxy implementation
to any network application that I maintained, but I'd be more likely to
accept
a patch that used GProxyResolver or g_socket_client_add_application_proxy
(for GLib code) or something like libproxy or pacrunner (for non-GLib code).


S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsub...
Archive:
http://lists.debian.org/20110922100949.ga21...@reptile.pseudorandom.co.uk

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Simon McVittie]

On Thu, 22 Sep 2011 at 16:50:43 +0200, Jérémy Lal wrote:
> By no means it is a replacement to existing 'which' tools, and no executable
> would be provided, only a library file.

Please use a short description that makes it look like a library rather
than calling it "a utility", then (or a module or package or whatever libraries
are normally called in Node). libfile-which-perl is the same thing for Perl,
so its description might be a good example to consult.

S


-- 
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/20110922153107.ga7...@reptile.pseudorandom.co.uk

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Jérémy Lal]

On 22/09/2011 16:54, Paul Tagliamonte wrote:
> On Thu, Sep 22, 2011 at 10:38 AM, Simon McVittie  wrote:
>> On Thu, 22 Sep 2011 at 15:34:31 +0200, Jérémy Lal wrote:
>>> node-which finds the first instance of a specified executable
>>> in the PATH environment variable.
>>
>> How does this differ from:
>>
>> * the 'which' utility in debianutils (which is Essential: yes)
>>
>> * the 'which' builtin in shells that have copied it from csh (including zsh)
>>
>> * command -v, which exists on every POSIX system supporting the User
>>  Portability Utilities option, and in particular is a builtin in dash
>>
>> * command -V, a more verbose form of command -v, which exists on every POSIX
>>  system supporting the User Portability Utilities option, and in particular
>>  is a builtin in dash
>>
>> and how/when is it be better or more useful than those?
>>
>>S
>>
> 
> AFAICT it's not meant to be used from the CLI - I think this would be
> better as libnode-which - but it's also like 70 lines.

It will probably be named "libnode-which" but i started a discussion on
pkg-javascript-devel about that naming scheme [1]

 
> I'm not sold on this package, either TBH, but I think it would
> actually be useful to someone, somewhere at sometime. Perhaps consider
> this for inclusion when it's needed?

npm 1.0 depends on it, otherwise i wouldn't dare packaging this.

Jérémy.


-- 
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/4e7b4e51.5090...@edagames.com

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Jérémy Lal]

On 22/09/2011 16:38, Simon McVittie wrote:
> On Thu, 22 Sep 2011 at 15:34:31 +0200, Jérémy Lal wrote:
>> node-which finds the first instance of a specified executable
>> in the PATH environment variable.
> 
> How does this differ from:
> 
> * the 'which' utility in debianutils (which is Essential: yes)
> 
> * the 'which' builtin in shells that have copied it from csh (including zsh)
> 
> * command -v, which exists on every POSIX system supporting the User
>   Portability Utilities option, and in particular is a builtin in dash
> 
> * command -V, a more verbose form of command -v, which exists on every POSIX
>   system supporting the User Portability Utilities option, and in particular
>   is a builtin in dash
> 
> and how/when is it be better or more useful than those?

It's native js code.
By no means it is a replacement to existing 'which' tools, and no executable
would be provided, only a library file.
We are questioning the pertinence about packaging such a small lib by itself,
on another thread.

Jérémy.


-- 
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/4e7b4b43.4070...@edagames.com

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Paul Tagliamonte]

On Thu, Sep 22, 2011 at 10:38 AM, Simon McVittie  wrote:
> On Thu, 22 Sep 2011 at 15:34:31 +0200, Jérémy Lal wrote:
>> node-which finds the first instance of a specified executable
>> in the PATH environment variable.
>
> How does this differ from:
>
> * the 'which' utility in debianutils (which is Essential: yes)
>
> * the 'which' builtin in shells that have copied it from csh (including zsh)
>
> * command -v, which exists on every POSIX system supporting the User
>  Portability Utilities option, and in particular is a builtin in dash
>
> * command -V, a more verbose form of command -v, which exists on every POSIX
>  system supporting the User Portability Utilities option, and in particular
>  is a builtin in dash
>
> and how/when is it be better or more useful than those?
>
>    S
>

AFAICT it's not meant to be used from the CLI - I think this would be
better as libnode-which - but it's also like 70 lines.

I'm not sold on this package, either TBH, but I think it would
actually be useful to someone, somewhere at sometime. Perhaps consider
this for inclusion when it's needed?

-- 
All programmers are playwrights, and all computers are lousy actors.

#define sizeof(x) rand()
:wq


--
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/CAO6P2QRnj=AoZ7WOoxpgE-wRi8=by+yskd+obsaxzz8p-1b...@mail.gmail.com

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Simon McVittie]

On Thu, 22 Sep 2011 at 15:34:31 +0200, Jérémy Lal wrote:
> node-which finds the first instance of a specified executable
> in the PATH environment variable.

How does this differ from:

* the 'which' utility in debianutils (which is Essential: yes)

* the 'which' builtin in shells that have copied it from csh (including zsh)

* command -v, which exists on every POSIX system supporting the User
  Portability Utilities option, and in particular is a builtin in dash

* command -V, a more verbose form of command -v, which exists on every POSIX
  system supporting the User Portability Utilities option, and in particular
  is a builtin in dash

and how/when is it be better or more useful than those?

S


-- 
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/20110922143840.ga10...@reptile.pseudorandom.co.uk

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Jérémy Lal]

On 22/09/2011 16:04, Andrew O. Shadura wrote:
> Hello,
> 
> On Thu, 22 Sep 2011 15:34:31 +0200
> Jérémy Lal  wrote:
> 
>>   Description : which-like utility for Node
> 
> Why not make a single package e.g. node-utils which would include many
> such small libraries, just like tcllib does? I suppose most of those
> script aren't or particularly big size so shipping them as a zillion
> packages doesn't really make any sense.
> 

cc-ing to pkg-javascript-devel

Thank you for raising that issue.
I have indeed several small libraries, mostly single files, to package.
Most of them are dependencies of another package i'm preparing.

Why doesn't it really make any sense to package each of them separately ?

What would be the criteria to decide that several small libraries better be
distributed as a single package ?

Jérémy.


-- 
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/4e7b44ed.5030...@melix.org

Re: alternative dependency ordering - with respect of packages in main

[Bruce Sass]

On September 22, 2011 02:50:25 AM Gerfried Fuchs wrote:
> * Bruce Sass  [2011-09-21 23:18:54 CEST]:
> > On September 20, 2011 02:24:33 PM Stefano Zacchiroli wrote:
> > > On Tue, Sep 20, 2011 at 01:12:37PM +0200, Gerfried Fuchs wrote:
> > > >  tl;dr - what do you think, is a "Depends: foo-contrib | foo"
> > > >  acceptable
> > > > 
> > > > for packages in main or should it be "Depends: foo | foo-contrib"
> > > > instead?
> > > 
> > > I think the first form above ("foo-contrib | foo") is not acceptable.
> > > My argument is that we should make choice of non-free software an
> > > explicit action of Debian users, rather than an implicit/automated
> > > one.
> > 
> > Would once be fine, or should contrib/non-free users need to make an
> > explicit choice every first time a package outside of Main is an
> > installation candidate?
> 
>  For me, once wouldn't be fine. Just because I might be interested in a
> non-free package for a specific task/documentation/whatever, I am *not*
> interested in general to pull in non-free stuff into my system.  Reason
> is simple:  Every single non-free package has different reasons for
> being there, and while I might be fine with having non-modifyable stuff
> on my system for something specific, when being in a work environment
> non-commercial restriction is a pain, or patent-related restrictions
> should also be explicitly chosen.
> 
>  So *every* time a package outside of main is an installation candidate
> the decision should be made, not once, very much indeed.

As someone who doesn't care about licences I would find it very onerous to 
have to confirm everytime a non-Main package is up for installation, and would 
quickly hack my way around it if necessary.

> > Debian already favours Main packages by default
> 
>  Not if the alternative dependency chain has a non-free package first. I
> know what you mean with that non-free isn't enabled by default, but the
> way the dependency chain is written still favours non-free packages by
> default, when available -- which is the thing you like to emphasis on,
> but the favour is still the other way round.

I disagree. The only way a non-free package is going to be automatically 
selected is if the sysadmin has added non-Main lines to sources.list, and the 
Maintainer has placed a non-Main package before one from Main in the 
dependency statement--that's two explicit actions that need to be taken, 
compared to zero if non-Main stuff isn't wanted.

Why would a Maintainer want to place a non-Main package ahead of one from Main 
in a dependency statement? I can think of two potential reasons: to work 
around a dependency system deficiency; or because the Main alternative really, 
really, sucks. In the first case the solution should be to fix the dependency 
system. In the second there is a choice to be made between providing users 
with the best possible system with the minimum of hoops to jump through to get 
it, or pushing a particular philosophical ideology on them at the expense of 
stability/functionality/etc.--I hope Debian would honour the Social Contract 
and put the needs of the users ahead of software freeness concerns in that 
case.

> > Personally: I'd like to see any philosophical overloading of dependency
> > statements disappear. The statement "A|B|C" should mean that A is the
> > best choice from a technical perspective (stability, functionality,
> > etc.)
> 
>  Not only technical perspective, the DFSG are also very relevant for
> such a decision making.

I don't disagree with that, the two just shouldn't be mashed together because 
any relationship between them is arbitrary. In programming terms, it is a poor 
choice of data structure for the problem. In DB terms, it should be 
normalized.

>  Please don't forget that the reason for one non-free package might be
> acceptable for a fair amount of users (like debate about GFDL showed)
> while the reason for another non-free package crosses the line for most.
> A general statement of "I installed that one non-free package so I'm
> fine with other non-free packages on my system" is flawed in very many
> senses.

I haven't forgotten, it is where I started, but it quickly became apparent 
that a system for keeping track of preferences on a per-package/suite basis 
would be needed if it was to be done properly. [Since, "Every single non-free 
package has different reasons for being there", it is not reasonable to expect 
that a coarse grained system will satisfy all the potential reasons for 
wanting them.] I believe that it would also require per-reason (non-
commercial, patented, documentation, etc.), and perhaps per-subsystem 
preference tracking and conflict resolution. That seems like it could be a 
huge amount of work so I choose to explore the `fix the tools so that the 
order doesn't matter' and `separate the two functions' options.


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

Re: Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Andrew O. Shadura]

Hello,

On Thu, 22 Sep 2011 15:34:31 +0200
Jérémy Lal  wrote:

>   Description : which-like utility for Node

Why not make a single package e.g. node-utils which would include many
such small libraries, just like tcllib does? I suppose most of those
script aren't or particularly big size so shipping them as a zillion
packages doesn't really make any sense.

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#642416: ITP: node-which -- Like which(1) unix command for Node

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 


* Package name: node-which
  Version : 1.0.2
  Upstream Author : Isaac Z. Schlueter 
* URL : https://github.com/isaacs/node-which
* License : Expat
  Programming Lang: JavaScript
  Description : which-like utility for Node

Node is an event-based server-side JavaScript engine.
.
node-which finds the first instance of a specified executable
in the PATH environment variable.




--
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/20110922133431.13036.37406.reportbug@imac.chaumes

Re: TranscriberAG: successor of Transcriber as a Debian/Ubuntu package

[Kai Wasserbäch]

[Dropping most of the CCs.]

Dear Mr. Busson,
bastien.bus...@dga.defense.gouv.fr schrieb am 22.09.2011 11:16:
> We would be very pleased to see a TranscriberAG package be part of the 
> repositories as many people, especially from the research community, hope 
> after the removal of the Transcriber package.

you either need to file a RFP (Request For Packaging) or an ITP (Intend To
Package) bug. In the former case you just ask the project in general that
somebody please start packaging TranscriberAG. No guarantee that this happens
(maybe you can contact the previous Transcriber maintainer(s) and ask them,
whether they'd be interested in packaging TranscriberAG).
In the latter case you'd become the new maintainer of TranscriberAG and package
it for Debian. Any questions regarding how to package something for Debian are
either answered already by the documents listed under [0] (not all will apply to
your case) or you can ask at [1]

> This email and any attachments are intended solely for the use of the 
> individual to whom they are addressed.If you have received this e-mail in 
> error, please inform the sender immediately without keeping any copy 
> thereof and delete it from your system.

Oh please don't send these standard disclaimers, especially not, when you're
contacting a public mailing list.

Kind regards,
Kai Wasserbäch


[0] 
[1] 



-- 

E-Mail: cu...@debian.org
IRC: Curan
Jabber: dri...@debianforum.de
URL: http://wiki.debian.org/C%C3%B9ran
GnuPG: 0xE1DE59D2  0600 96CE F3C8 E733 E5B6 1587 A309 D76C E1DE 59D2



signature.asc
Description: OpenPGP digital signature

Re: Proxy compliance and assistance.

[Simon McVittie]

On Wed, 21 Sep 2011 at 14:13:31 -0500, Mike Mestnik wrote:
> I'd like to start a movement to verify and assist projects/packages
> with the proper deployment of software that supports proxies.

In GLib-based applications, connecting using GSocketClient while having
glib-networking installed will automatically use a configured proxy; this
is much less ongoing maintenance burden than adding specific proxy support
to every networked application, so please use this route where feasible in
GLib/GNOME applications, rather than repeatedly writing app-specific proxy
code. Recent versions of telepathy-gabble (as used by Empathy for XMPP) will
automatically pick up GNOME/KDE proxy settings in this way, for instance.

(There's probably an equivalent thing I could say about Qt/KDE applications,
if I knew Qt better.)

> What I need most of all is community support, it's no good to
> confront developers or package maintainers that are insistent on
> rebelling against the use of proxies.

There's an important difference between "I think proxies don't matter" and
"I think this particular patch to support use of proxies is more maintenance
burden than it's worth"; be careful not to mistake the second for the first.
Part of a maintainer's job is to say "no" to things they're not going to be
able to maintain in future.

I for one would tend to reject a patch to add a "full" proxy implementation
to any network application that I maintained, but I'd be more likely to accept
a patch that used GProxyResolver or g_socket_client_add_application_proxy
(for GLib code) or something like libproxy or pacrunner (for non-GLib code).

S


-- 
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/20110922100949.ga21...@reptile.pseudorandom.co.uk

TranscriberAG: successor of Transcriber as a Debian/Ubuntu package

[bastien . busson]

Dear ftpmasters, package developers and maintainers,

The Transcriber package (http://packages.qa.debian.org/t/transcriber.html) 
was removed last year.
The reasons were:
Please remove transcriber:
- orphaned for more than 3.5 years, last maintainer upload in 2005
- dead upstream (last release from 2005, according to the sourceforce page 
a complete rewrite was planned in 2008)
- minimal popcon
source : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=595993

TranscriberAG (http://transag.sourceforge.net) is the successor of 
Transcriber and has been released as an open source software (GPLv3) last 
July.
Compilation as is was successful under Ubuntu 10.4 and 10.10 and went okay 
with a patch under Ubuntu 11.04 (information available here: 
http://sourceforge.net/mailarchive/forum.php?thread_name=4E35D2B5.4020104%40vista.se&forum_name=transag-general).

We would be very pleased to see a TranscriberAG package be part of the 
repositories as many people, especially from the research community, hope 
after the removal of the Transcriber package.

Please feel free to contact me (bus...@users.sourceforge.net) should you 
require any further information.

Thank you very much and I'm looking forward to hearing back from you.

Best regards,

Bastien Busson


[ENVOYE PAR INTERNET]

This email and any attachments are intended solely for the use of the 
individual to whom they are addressed.If you have received this e-mail in 
error, please inform the sender immediately without keeping any copy 
thereof and delete it from your system.

Re: alternative dependency ordering - with respect of packages in main

[Gerfried Fuchs]

* Bruce Sass  [2011-09-21 23:18:54 CEST]:
> On September 20, 2011 02:24:33 PM Stefano Zacchiroli wrote:
> > On Tue, Sep 20, 2011 at 01:12:37PM +0200, Gerfried Fuchs wrote:
> > >  tl;dr - what do you think, is a "Depends: foo-contrib | foo" acceptable
> > > for packages in main or should it be "Depends: foo | foo-contrib"
> > > instead?
> > 
> > I think the first form above ("foo-contrib | foo") is not acceptable. My
> > argument is that we should make choice of non-free software an explicit
> > action of Debian users, rather than an implicit/automated one.
> 
> Would once be fine, or should contrib/non-free users need to make an explicit 
> choice every first time a package outside of Main is an installation 
> candidate?

 For me, once wouldn't be fine. Just because I might be interested in a
non-free package for a specific task/documentation/whatever, I am *not*
interested in general to pull in non-free stuff into my system.  Reason
is simple:  Every single non-free package has different reasons for
being there, and while I might be fine with having non-modifyable stuff
on my system for something specific, when being in a work environment
non-commercial restriction is a pain, or patent-related restrictions
should also be explicitly chosen.

 So *every* time a package outside of main is an installation candidate
the decision should be made, not once, very much indeed.

> Debian already favours Main packages by default

 Not if the alternative dependency chain has a non-free package first. I
know what you mean with that non-free isn't enabled by default, but the
way the dependency chain is written still favours non-free packages by
default, when available -- which is the thing you like to emphasis on,
but the favour is still the other way round.

> Personally: I'd like to see any philosophical overloading of dependency 
> statements disappear. The statement "A|B|C" should mean that A is the best 
> choice from a technical perspective (stability, functionality, etc.)

 Not only technical perspective, the DFSG are also very relevant for
such a decision making.

 Please don't forget that the reason for one non-free package might be
acceptable for a fair amount of users (like debate about GFDL showed)
while the reason for another non-free package crosses the line for most.
A general statement of "I installed that one non-free package so I'm
fine with other non-free packages on my system" is flawed in very many
senses.
 
 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


-- 
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/20110922085025.ga23...@anguilla.debian.or.at