On Fri, 12 May 2006 01:10:17 +0200, Eugen Paiuc <[EMAIL PROTECTED]>
wrote:
>I'd add localepurge - witch save my >25 % disk space on 6-700 mb
>installation.
Localepurge is a bad hack which tries to compensate for a shortcoming
in dpkg, one that I have been waiting to be fixed since I started
using
On Fri, 5 May 2006 18:56:21 +0200, Pierre Habouzit
<[EMAIL PROTECTED]> wrote:
> that would obviously mean two signatures per package (but I don't
> think that's that much work)
Considered that we are currently waiting since months (half a year?)
for a security feature that used to work and has b
Roberto Lumbreras wrote:
Hey, again, don't be so rude...
Being harsh is not the same as being rude.
some of those serious policy violations are things like mistakes
erasing logfiles and editing conffiles that couldn't be done in
another way.
Are you serious? There's no excuse, ever, for e
Adam Borowski <[EMAIL PROTECTED]> writes:
> On Thu, May 11, 2006 at 04:49:26PM -0400, Joe Smith wrote:
>> On the other hand, if we continue that thought process we could end up
>> with all headers and libraries in /usr/share/, which is absurd.
>
> Why? This is exactly what's beautiful, especially
"Olaf van der Spek" <[EMAIL PROTECTED]> writes:
> On 5/10/06, Matt Taggart and others <[EMAIL PROTECTED]> wrote:
>> For a couple years now a few of us have been talking about an idea called
>> "multiarch". This is a way to seamlessly allow support for multiple different
>> binary targets on the sa
"Joe Smith" <[EMAIL PROTECTED]> writes:
> "Daniel Ruoso" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>>Em Qui, 2006-05-11 às 09:56 +0200, Gabor Gombas escreveu:
>>> On Wed, May 10, 2006 at 03:33:45PM +0200, Olaf van der Spek wrote:
>>> > Why would that not fly?
>>> > Both version
[EMAIL PROTECTED] writes:
> There is yet another issue with the $arch portion of the canonical system
> name: chips which are upgrades of other chips. For instance, Fedora will
> give you 'i686', while Debian will give you 'i486'. This will (and should)
> result in two different directories -- d
Thiemo Seufer <[EMAIL PROTECTED]> writes:
> I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which
> provides mappings for multiarch-sensitive programs.
I have dpkg-multiarch for that and other things like cflags, ldflags,
libdir and the like. dpkg-multiarch is used just like
dpkg-ar
On 5/13/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
That would be total insanity. Just think about the number of scripts
with "#!/usr/bin/python" in it that would have to be changed. And how
Shouldn't such hard-coded paths be avoided in the long term (anyway)?
would you even change th
On Fri, 12 May 2006, Andreas Barth wrote:
> > How about, right now, just a statement "this is what the issues are".
> > Or even, "this [URL here] is the mailing list post where the issues
> > are outlined."
>
> I forgot about them. So, I need to collect them again. Even release
> managers don't ha
Le Sam 13 Mai 2006 08:45, Adrian von Bidder a écrit :
> On Wednesday 10 May 2006 16:21, Daniel Schepler wrote:
> > Le Mardi 09 Mai 2006 22:49, Bill Allombert a écrit :
> > > Debian Qt/KDE Maintainers
> >
> > ...
> >
> > > libkcal2b
> > > libkdepim1a
> >
> > It looks like these two have circula
Hello Debian people,
I am proposing a new version of the new Debian menu structure proposal
incorporating changes that have been proposed.
Here the change from the previous draft:
- change 'HAM Radio' to 'Amateur Radio'.
- revert change 'Educational' -> 'Education'.
- add 'Electronics' in place
Neil McGovern wrote:
> ---
> Debian Testing Security Team May 12th, 2006
> secure-testing-team@lists.alioth.debian.org
> http://secure-testing-master.debian.net/
> ---
On Wed, May 10, 2006 at 11:05:03AM +0200, Goswin von Brederlow wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> > Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit :
[..]
> Except that apt-get fails if any of the signatures are unknown or
> expired. So you still need both keys and not just one
I wrote a network byte monitor in BSD, thinking that it would port
directly to GNU with a few minor changes. However, I've found that the
if_addr structure does not contain a link to the if_data struct on GNU
stdlib.
What function calls should I make to get this similar data in GNU land?
--
Rega
Em Qui, 2006-05-11 às 15:05 -0300, Gustavo Franco escreveu:
> by mail, really ? Well, that's weird. Why we've usertags[0] too ?
>
> [0] = http://wiki.debian.org/bugs.debian.org/usertags
Usertags are not simply for "blocking" relations tagging. Usertags are
supposed to be a way for users to do wh
Hi,
in login 4.0.13, /usr/bin/nologin has appeared which seems to be a
good default choice for accounts that do not allow shell login.
I am now wondering whether (and when) I should change adduser to use
/usr/bin/nologin instead of /bin/false in the default case of disabled
login.
Are we suffici
* Marc Haber <[EMAIL PROTECTED]> [060513 16:34]:
> in login 4.0.13, /usr/bin/nologin has appeared which seems to be a
> good default choice for accounts that do not allow shell login.
/bin/false and /bin/true have the advantage of relatively well-defined
meanings (no login vs. no shell login).
So
Bernhard R. Link wrote:
> * Marc Haber <[EMAIL PROTECTED]> [060513 16:34]:
>
>>in login 4.0.13, /usr/bin/nologin has appeared which seems to be a
>>good default choice for accounts that do not allow shell login.
>
>
> /bin/false and /bin/true have the advantage of relatively well-defined
> meani
I just felt like interjecting after having been reading up on this
tread. The whole multiarch situation is exactly why my workstation was
re-installed with FC5's x86_64 from the old Debian amd64 distro. Someday
when Debian has multiarch I'll switch it back but for now all my 64 bit
machines
On Sat, May 13, 2006 at 01:17:02PM -0400, Roberto C. Sanchez wrote:
> Out of curiousity, what happens when someone tries to login and /usr is
> unavailable? If the shell is set to something in /bin, it will still be
> used. What is the default action when the user's shell is not available?
foo:x
I use deborphan to get rid of unneeded packages on my system.
But I have various lib*-dev packages installed to satisfy the
build-dependencies of packages that I maintain or otherwise build from
source. Deborphan reports these as orphaned, but I (usually) still need
them. (When the build-dependen
* Roberto C. Sanchez:
> Out of curiousity, what happens when someone tries to login and /usr is
> unavailable? If the shell is set to something in /bin, it will still be
> used. What is the default action when the user's shell is not available?
It's also interesting how this interacts with non-
Package: wnpp
Severity: wishlist
Owner: Piotr Ozarowski <[EMAIL PROTECTED]>
* Package name: advancecomp
Version : 1.15
Upstream Author : Andrea Mazzoleni <[EMAIL PROTECTED]>
* URL : http://advancemame.sourceforge.net/
* License : GPL, LGPL
Programming Lang: C,
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]>
> Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
>> That would be total insanity. Just think about the number of scripts
>> with "#!/usr/bin/python" in it that would have to be changed. And how
> Shouldn't such hard-coded paths be avoided in the l
Package: wnpp
Severity: wishlist
Owner: Julien BLACHE <[EMAIL PROTECTED]>
* Package name: airport-utils
Version : undecided yet
Upstream Author : Jon Sevy <[EMAIL PROTECTED]>
* URL :
http://edge.cs.drexel.edu/GICL/people/sevy/airport/index.html
* License : GPL
On Sat, May 13, 2006 at 10:54:57PM +0200, Henning Makholm wrote:
> The Linux kernel requires a full path for #! scripts. This makes
> sense if one considers a #! program to be something that should have
> predictable behavior no matter what the user happens to have in his
> $PATH.
The standard id
Henning Makholm wrote:
In multiarch, the right approach to this particular problem is to
arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python
with $arch chosen (somehow) appropriately for a default python
interpreter.
Apart from the fact that no multiarch proposals have tried t
28 matches
Mail list logo
