On Tue, Feb 03, 2009 at 09:47:53PM +0100, Pietro Battiston wrote:
> Googling a little, I couldn't understand if such a migration is legally
> plausible (I don't think so, but I'm not an expert). But even if it was,
> what is the reason?
The chart in [1] is a useful reference for such a query (and
* Pietro Battiston [Tue, 03 Feb 2009 21:47:53 +0100]:
Hello, Pietro, thanks for noticing this.
> Please forgive my ignorance, but why does package python-openid, which
> has an Apache license (with some boilerplate not filled at the end, I
> think) in LICENSE file, report LGPL in debian/copyright
Please forgive my ignorance, but why does package python-openid, which
has an Apache license (with some boilerplate not filled at the end, I
think) in LICENSE file, report LGPL in debian/copyright?
Googling a little, I couldn't understand if such a migration is legally
plausible (I don't think so,
On Tue, 2009-03-02 at 20:22 +, Floris Bruynooghe wrote:
> > Fortunately, I just spent 20-30 minutes going through this on
> Sunday.
> >
> > http://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html
> >
> > Scroll down to: 12.1.12 Operating system users and groups
>
> You can also
On Tue, Feb 03, 2009 at 09:18:31AM -0500, Guy Hulbert wrote:
> On Tue, 2009-03-02 at 09:06 -0500, Yaroslav Halchenko wrote:
> > Unfortunately I can't find clear description of the 'staff' group
> > destiny
> > nowhere in Debian documentation
>
> Fortunately, I just spent 20-30 minutes going throu
[Jonathan Wiltshire, 2009-02-03]
> http://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_0.5.3-1.dsc
`dh install --remaining` invokes dh_auto_install which is installing
files into old location. Please fix it.
You can reply me off-list once it's done, I'll upload the package.
PS
On Tue, 2009-03-02 at 10:00 -0500, Yaroslav Halchenko wrote:
> > It is a PITA for development but ...
> hm... sorry, but I don't see the actual point...
It's actually quite easy for someone in the 'staff' group to get root
privileges ... I told secur...@debian.org on Sunday exactly how and
exactly
ok -- here is my tentative cruel patch as a proof of concept. It should
not alter current behavior, but would allow to control for it.
See it attached
> configuration (.ini) needs to be under /etc, and that is what I am
> aiming at...
--
Yaroslav Halchenko
Research Assistant, Psychology Departm
thank you Josselin,
I've seen that one while I checked if there is any open issue
and I agree that FHS is all by hackish -- but unfortunately Debian has
diverged from it in terms of ownership, like we figured out elsewhere
in this thread: msg-id: 20090203143602.gt25...@washoe.rutgers.edu
so, it o
On Tue, 03 Feb 2009, Guy Hulbert wrote:
> You should do it under /usr/share/APP/ the /etc/APP/ directory is for
> your .ini files (see FHS).
> I have:
> /usr/share/APP/perl/
> /usr/share/APP/sbin/
> Scripts in sbin will have
> unshift @INC,'/usr/share/APP/perl'
> or
> use
Le lundi 02 février 2009 à 22:35 -0500, Yaroslav Halchenko a écrit :
> why in a hackish site.py those /usr/local paths are added?
Because we want to follow the FHS, which is all but hackish - but
Python, in many ways, doesn’t make it easy.
The real question is more: why aren’t these paths correc
ho ho -- thank you Guy!
so, here it is:
,-,
| staff: Allows users to add local modifications to the system (/usr/local,
|
| /home) without needing root privileges. Compare with group "adm", which is
more |
| re
On Tue, 2009-03-02 at 09:06 -0500, Yaroslav Halchenko wrote:
> in Python's case, there is NO way to have it
> configured in the desired way -- ie not to have /usr/local components
> loaded
> automagically. And that is the problem.
You can do:
#!python
import sys
and edit sys.path
On Tue, 2009-03-02 at 09:06 -0500, Yaroslav Halchenko wrote:
> Unfortunately I can't find clear description of the 'staff' group
> destiny
> nowhere in Debian documentation
Fortunately, I just spent 20-30 minutes going through this on Sunday.
http://www.debian.org/doc/manuals/securing-debian-how
On Tue, 2009-03-02 at 09:19 -0500, Yaroslav Halchenko wrote:
> Having proper configuration file under /etc sounds much more viable
> and correct solution.
You should do it under /usr/share/APP/ the /etc/APP/ directory is for
your .ini files (see FHS).
I have:
/usr/share/APP/perl/
> > > 1. remove /usr/local from site.py
> > This denies the ability of the system administrator to put local
> > overrides for Python library files in place as simply and consistently
> > as is done for other libraries and executables.
> indeed, precedence is smth I didn't think through in my sugg
Thank you guys for reference to FHS. I did read it long ago and now
glanced over again to confirm my knowledge.
Actually, since FHS does not say anything about ownership of the files in FH,
so Debian exploits that in its own way:
$> ls -ld /usr /usr/local
0 drwxr-xr-x 15 root root 440 2008-02-17
On Mon, Feb 02, 2009 at 11:46:57PM -0500, Yaroslav Halchenko wrote:
> > > what was the actual use-case they solved?
> > As I understand it, the use case is analogous to the addition of
> > ‘/usr/local/bin’ to the ‘PATH’ environment variable in the default
> > shell profile.
>
> ok -- that would
18 matches
Mail list logo
