Re: [joey@infodrom.north.de (Martin Schulze)] Re: Re: kernel building
>>>>> "JR" == Josip Rodin <[EMAIL PROTECTED]> writes: JR> On Thu, Mar 16, 2000 at 09:47:41PM +1100, Mikolaj J. Habryn JR> wrote: >> If you haven't sent from a root account there is a chance that >> our list server has inserted a line like "Sender: [EMAIL PROTECTED]" >> which confuses the lists software. In that case please wait >> few hours and resend. JR> Maybe this is the problem? Why would this happen, anyway? That would be a valid idea, were it not for the fact that it *consistently* bounces mail with a from address of <[EMAIL PROTECTED]>, and accepts <[EMAIL PROTECTED]>. Consistently. Within timespans of seconds, minutes, hours, days, weeks, or months. m.
[joey@infodrom.north.de (Martin Schulze)] Re: Re: kernel building
This is *still* happening. Will someone please do something about it? root isn't even mentioned in the headers. I get this error when I mail with one of my complex cookie'd from lines, and don't when I simplify it. Why is this feature even in place? Does it add any kind of value to stop root users posting, even if it doesn't kill innocent mail in the process? m. --- Begin Message --- You should not send mail from your »root« account. The »root« is a login that bypasses all security protection on your system. The root account should only be used to perform system administration, and only used for as short a time as possible. You should *not* use the »root« account for daily use or as your personal login. Why not? Well, one reason to avoid using root's privileges is that it is very easy to do irreparable damage as root. Another reason is that you might be tricked into running a Trojan-horse program -- that is a program that takes advantage of your super-user powers to compromise the security of your system behind your back. Any good book on Unix system administration will cover this topic in more detail -- consider reading one if it is new to you. Please use adduser and create a regular user account for you and send mail from that account. If you haven't sent from a root account there is a chance that our list server has inserted a line like "Sender: [EMAIL PROTECTED]" which confuses the lists software. In that case please wait few hours and resend. > From [EMAIL PROTECTED] Thu Mar 16 11:33:07 2000 > Return-Path: <[EMAIL PROTECTED]> > Received: at Infodrom Oldenburg (/\##/\ Smail-3.2.0.102 1998-Aug-2 #2) > from murphy.debian.org by finlandia.Infodrom.North.DE > via smail with smtp > id <[EMAIL PROTECTED]> > for <[EMAIL PROTECTED]>; Thu, 16 Mar 2000 11:33:04 +0100 (CET) > Received: from ([216.234.231.6]) by teergrube (0 sec delayed, relaying denied) > Received: (qmail 13818 invoked by uid 847); 16 Mar 2000 10:32:31 - > Received: (qmail 13781 invoked by uid 38); 16 Mar 2000 10:32:31 - > Received: (qmail 13774 invoked by uid 38); 16 Mar 2000 10:32:30 - > Date: 16 Mar 2000 10:32:30 - > X-From_:[EMAIL PROTECTED] Thu Mar 16 04:32:30 2000 > X-Envelope-Sender: [EMAIL PROTECTED] > Received: (qmail 13752 invoked from network); 16 Mar 2000 10:32:26 - > Received: from mooneye.ucc.gu.uwa.edu.au (HELO ucc.gu.uwa.edu.au) > (130.95.13.9) > by murphy.debian.org with SMTP; 16 Mar 2000 10:32:26 - > Received: from mussel.ucc.gu.uwa.edu.au ([EMAIL PROTECTED] [130.95.13.18]) > by ucc.gu.uwa.edu.au (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id > SAA17126; > Thu, 16 Mar 2000 18:32:22 +0800 > Received: (from [EMAIL PROTECTED]) > by mussel.ucc.gu.uwa.edu.au (8.9.3/8.9.3/Debian 8.9.3-6) id SAA01423; > Thu, 16 Mar 2000 18:32:21 +0800 > X-Authentication-Warning: mussel.ucc.gu.uwa.edu.au: dichro set sender to > [EMAIL PROTECTED] using -f > Sender: [EMAIL PROTECTED] > From: "Mikolaj J. Habryn" <[EMAIL PROTECTED]> > To: DI Peter Burgstaller <[EMAIL PROTECTED]> > Cc: debian-alpha@lists.debian.org > Subject: Re: kernel building > References: <[EMAIL PROTECTED]> > Old-Date: 16 Mar 2000 21:32:21 +1100 > In-Reply-To: DI Peter Burgstaller's message of "Wed, 15 Mar 2000 15:23:17 > +0100 (MET)" > Message-ID: <[EMAIL PROTECTED]> > Lines: 10 > User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/20.4 (Emerald) > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > X-Diagnostic: Mail coming from a daemon, ignored > X-Envelope-To: debian-alpha > Delivered-To: [EMAIL PROTECTED] > X-Loop: [EMAIL PROTECTED] > Regards, SPI and Debian listmaster -- Debian GNU/Linux - The Universal Operating System [EMAIL PROTECTED] [EMAIL PROTECTED] --- End Message ---
Re: libtool .la archives - name collision?
> "BC" == Ben Collins <[EMAIL PROTECTED]> writes: BC> No because the .la files only go into the -dev package for the BC> library, Section 4.2 of the policy manual, according to my reading, seems to disagree... Packages that use libtool to create shared libraries must include the _.la_ files in the _-dev_ packages, with the exception that if the package relies on libtool's _libltdl_ library, in which case the .la files must go in the run-time library package. This is a good idea in general, and especially for static linking issues. It seems to be suggesting that .la files in the run-time library package is a good idea in general, and even if I'm misreading that, they definitely go in if the libraries are used by something relying on libltdl. Or am I missing something? m.
libtool .la archives - name collision?
Hmm - it strikes me that there may be a potential problem with including .la archives with library packages. The filename for the libtool file is independent of the version number of the library. ie, libfish2 will ship with a libfish.la, and so will libfish3. This might be an obstacle to installing multiple versions of the same library, might it not? m.
Re: /usr/lib/libgnomeui.so.0: undefined symbol: argp_program_version
> "IEM" == Ivan E Moore <[EMAIL PROTECTED]> writes: IEM> /usr/lib/libgnomeui.so.0: undefined symbol: IEM> argp_program_version This happens with some of the GNOME IEM> based packages I've installed from both slink and potatoe IEM> lately... IEM> Any ideas what I'm missing or what I did??? One of the backend libraries changed. libimlib, from memory, caused this going from 1.8 to 1.9. Make sure you've upgraded everything, and if it still doesn't work, rebuild things in the right order. m, who did this for alpha just a few days ago.
Re: Getting Slink compatible with Linux-2.2.0
> "VR" == Vincent Renardias <[EMAIL PROTECTED]> writes: VR> The 2.9 Debian package already contains the alpha patches VR> supplied by Christopher C Chimelis VR> <[EMAIL PROTECTED]> (see bug report #17661). I am VR> not aware of any other patch or problem specific to the alpha VR> platform. Can you please elaborate? The structure in partition.h that's specific to the alpha does not match the generic one - the difference that I first noticed (from memory) was the naming of the last two fields in struct partition. One solution is to mark the generic structure definition with __attribute__((packed)), as this shouldn't make any difference to any platform other than those that actually need it there. I was going to test this before suggesting it, but time constraints etc, etc, etc :) m.
Re: Getting Slink compatible with Linux-2.2.0
> "VR" == Vincent Renardias <[EMAIL PROTECTED]> writes: VR> Including the current (2.9g-5) util-linux from unstable in VR> frozen is a Bad Idea(tm). This version has several big VR> packaging issues. On top of everything else, alpha support (and quite possibly other non-x86 architectures) in 2.9 is ever so slightly flaky. m.
Re: Bug#27050 (fdutils): A cause for security concern?
> "AF" == Anthony Fok <[EMAIL PROTECTED]> writes:
AF> if (geteuid()!=0) die("Must run with EUID=root");
AF> I am a little bit tempted to comment that line out, but it's
AF> probably there for a reason, and I am definitely not qualified
AF> to hack fdmount.c, so for now I should probably add a
AF> /usr/sbin/fdutilsconfig as Thomas has suggested.
This sort of thing should be shot on sight. It will need to be
removed one way or another when we move to a capability based
system. The downside is that the reason things like this exist is the
complete lack of any error handling in the rest of the code.
If you need something to do, dike it out. If it's run as root, it
will work as expected. If not, then it can't do any real damage,
right? ;)
m.
