Re: when and why did python(-minimal) become essential?
Bill Allombert [EMAIL PROTECTED] writes: Interestingly the size is highly dependent on the architecture: [EMAIL PROTECTED]:~$ ls -l postrm-* -rwxr-xr-x 1 ballombe ballombe 6960782 Jan 30 14:10 postrm-amd64 -rwxr-xr-x 1 ballombe ballombe 266065 Jan 30 14:09 postrm-i386 [EMAIL PROTECTED]:~$ strip postrm* [EMAIL PROTECTED]:~$ ls -l postrm-* -rwxr-xr-x 1 ballombe ballombe 4702544 Jan 30 14:10 postrm-amd64 -rwxr-xr-x 1 ballombe ballombe 156720 Jan 30 14:10 postrm-i386 Ups, that seems wrong :) I thought that AMD64 maybe wasn't a registered port in Sarge GHC, but it is. Anyways, using an hypothetical shared runtime would be too much bloat for maintainer scripts anyways. A far better approach would be to use Haskell as a script language, but AFAIK this is not really possible yet. Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Bill Allombert [EMAIL PROTECTED] writes: The only (very minor) drawback is that above haskell scripts when compiled is about 7MB in size, but the huge gain in reliability I think you're somewhat joking about using Haskell, but your script weights: [EMAIL PROTECTED]:~/tmp$ ls -lh a.out -rwxr-xr-x 1 egallego egallego 182K 2006-01-30 00:19 a.out This is including all the Haskell runtime. Using a shared runtime would be the optimal solution, as the compiled module is about 9Kb (without stripping): -rw-r--r-- 1 egallego egallego 9652 2006-01-30 00:19 Main.o and stripped: -rw-r--r-- 1 egallego egallego 3584 2006-01-30 00:25 Main.o However, AFAIK GHC doesn't support sharing the runtime. Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: udev now can rename the interfaces, because they haven't a name yet. udev still loads the modules, you just have been lucky. This is not a solution in any way. Maybe network interface renaming doesn't belong in udev, as they're really kernel assigned names. I think this point has been raised before, ( but I couldn't find any thread relating to it), but the right place to do that would be in the ifupdown package, that could have the right logic to do so. A (somewhat flawed) metaphor regarding this topic would be that IP address configuration doesn't belong in udev either. I've looked into the Suse sysconfig package, and it includes all the network configuration utils, such as ifup and dhcp handling, and they're coupled with the udev rules. As previously said those interactions are tricky, in order to guarantee that there are no race conditions. Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Some bug numbers talking about this: 182012 227283 Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
[EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 19, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: Merging that into Debian would mean that udev would replace some ifupdown planned functionality. Wrong. I think that ifupdown maintainers are the ones who can say that for sure, looking at the bugs I didn't get that impression. OTOH it would be useful if ifupdown allowed reporting to udev the name of an interface given its MAC address. Interfaces renaming must be handled by udev because if it's not then network hotplug handlers will be called with the wrong interface name. The point is to call them with the kernel generated name, and let them to rename the iface. The bad is that then ifupdown should look at sysfs or some other place to get again the interface info. Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Davide Natalini [EMAIL PROTECTED] writes:
Hi all
I'm trying to get static naming for my network interfaces with udev,
without success.
As far as I can tell, network interface names are given by the kernel
and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
the system is debian sarge based, with udev version 0.076-6 and kernel
2.6.14-7-686-smp on a P4. the network interfaces are a realtek 8139
integrated in the motherboard (eth0) and a 3com pci (eth1)
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
beside the fact that I find useful to name eth0 the realtek and eth1
the other, there is a casuality in the naming process that I cannot
remove :-(
my /etc/udev/rules.d/000local.rules looks like this:
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
SYSFS{address}==00:10:4b:b2:1e:6e, NAME=eth1, RUN+=/bin/echo 2
/root/udev.log
KERNEL==eth*, ID==:02:05.0, NAME=eth1, RUN+=/bin/echo 3
/root/udev.log
DRIVER==3c59x, NAME=eth1, RUN+=/bin/echo 4 /root/udev.log
SUBSYSTEM==net, SYSFS{address}==00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 5 /root/udev.log
KERNEL==eth*, SYSFS{address}!=00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 6 /root/udev.log
SYSFS{device}==0x9055, NAME=eth1, RUN+=/bin/echo 7 /root/udev.log
in the hope that the creation of the ethernet interface could match at
least one of these rules (and log wich), but this isn't happening.
I tried to add this at the top of the file:
ACTION==add, DEVPATH==/devices/*, ENV{PHYSDEVBUS}==?*, \
WAIT_FOR_SYSFS=bus
but it didn't help.
can anybody tell me what I'm doing wrong?
I hope this helps,
Emilio
p.d: I think this is a debian-user question, setting MFT, but I'm not
subscribed to debian-user, so CC me please.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Hello!
martin f krafft [EMAIL PROTECTED] writes:
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
As it has been pointed by Tomas Hood, udev is the same hack that
ifrename of a custom nameif script and it is not race free. Indeed,
some of the DEV_NET events are special-cased in half of udev due to
not having a device file associated.
A netif name is given in the kernel, udev only tries to rename it (as
the other tools do):
udev_add.c:287
} else if (udev-type == DEV_NET) {
/* look if we want to change the name of the netif */
if (strcmp(udev-name, udev-kernel_name) != 0) {
retval = rename_net_if(udev);
if (retval != 0)
goto exit;
info(renamed netif to '%s', udev-name);
/* we've changed the name, now fake the devpath, cause
the
* original kernel name sleeps with the fishes and we
don't
* get an event from the kernel with the new name
*/
pos = strrchr(udev-devpath, '/');
if (pos != NULL) {
pos[1] = '\0';
strlcat(udev-devpath, udev-name,
sizeof(udev-devpath));
strlcpy(udev-kernel_name, udev-name,
sizeof(udev-kernel_name));
setenv(DEVPATH, udev-devpath, 1);
setenv(INTERFACE, udev-name, 1);
}
}
With the current situation, upstream (kernel) support is needed to do
the rename in a successfully way. You could retry the rename, but then
you'd get into liveliness issues (you want eth0-eth1 and eth1-eth0,
etc...).
So I think that using other tools for the job is equally appropriate.
I'll stop now as I really have no clue about udev and this has nothing
to do with the original post.
Regards, sorry for the noise and keep up the good work with Debian,
Emilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Someone to take over XMTLV packages
Kenneth Pronovici [EMAIL PROTECTED] writes: Hi, I have to, I will also continue to host the backport APT repository, although I would prefer not to. Wouldn't this be a good candidate for volatile.debian.net? Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: how to make a patch
Paolo Pantaleo [EMAIL PROTECTED] writes: I have spent some time to write the bash completion for apt-file command. I have written a pair of email to [EMAIL PROTECTED] and i didn't get any response. Now i want to submit a patch for bash_completion file that add the apt-file support. [EMAIL PROTECTED]:~$ apt-file [Double TAB] listpurge search showupdate It seems for me that apt-file completion is working perfectly. Regards, Emilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Debian exim 4 packages suck badly on exim-users@exim.org
Thomas Bushnell BSG wrote: I have found the exim-4 packages to be extremely well organized and handy. I used to use the one-file method, and was simply delighted when I found how easy it was to switch and tweak the individual files that I needed to when I had to create a more complicated mail server. Me too, I think exim4 packages are very well done, keep the good work. Regards, Emilio, Debian user. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: possible mass bug filing: spamassassin 3
El jue, 07-10-2004 a las 09:52 +0200, Tollef Fog Heen escribi: * Duncan Findlay | On Wed, Oct 06, 2004 at 06:43:47PM +0200, Tollef Fog Heen wrote: | * martin f krafft | | | What do you think? | | API changed generally means you bump soname. Why not for SA as well. | | Also, SA3 is useless, as it eats about half a gig of RAM on my | system. Per child. | | Umm... I'd like to see that 7122 root 15 0 660m 332m 4692 D 0.0 43.8 8:18.64 spamd 7123 nobody15 0 287m 257m 4692 D 0.0 34.0 0:17.01 spamd | Furthermore, you should use the -m option to limit the number of | children to something sane, like 5 or so. This is per child, as I wrote. For me sa work well: ii spamassassin 3.0.0-1Perl-based spam filter using text analysis [EMAIL PROTECTED]:~$ ps axum | grep spam 0:00 /usr/sbin/spamd --port 7830 --local --daemonize emilio5160 0.2 5.0 28352 25972 ? -13:00 0:38 spamd child emilio5161 0.0 5.1 28872 26408 ? -13:00 0:04 spamd child emilio5162 0.0 5.0 28612 26252 ? -13:00 0:04 spamd child emilio5163 0.0 5.0 28344 25924 ? -13:00 0:03 spamd child emilio5164 0.0 5.0 28744 26308 ? -13:00 0:04 spamd child emilio5810 0.0 0.1 2184 768 pts/0-16:39 0:00 grep spam Can you give some steps to reproduce such memory comsuption. Regards, Emilio
