Bug#835753: [PATCH] konsole: FTBFS: dh_install: missing files, aborting
Hi Looks like this is caused by an upstream change in extra-cmake-modules https://quickgit.kde.org/?p=extra-cmake-modules.git&a=commitdiff&h=5d10e167854af172b785b5d1f6b50baa09ddb87b A backwards-compatible way to deal with it might be: diff --git a/debian/konsole.install b/debian/konsole.install index 8a22b68..31a5d88 100644 --- a/debian/konsole.install +++ b/debian/konsole.install @@ -1,7 +1,7 @@ usr/bin/konsole usr/bin/konsoleprofile usr/lib/*/libkdeinit5_konsole.so -usr/share/appdata/org.kde.konsole.appdata.xml +usr/share/*/org.kde.konsole.appdata.xml usr/share/applications/org.kde.konsole.desktop usr/share/doc/HTML/*/konsole/ usr/share/knotifications5/konsole.notifyrc (vs https://anonscm.debian.org/git/pkg-kde/applications/konsole.git 38677584db655103ba4c068cf03ca554f3a1133b) Cheers Duncan
Bug#572162: Iceweasel may fall into busy loop on exit, depending on theme
Hello
I can reproduce this on my amd64 laptop (prefers testing) which has
iceweasel3.5.8-1
iceweasel-l10n-en-gb 1:3.5.8+debian-1
gtk-qt-engine1:1.1+svn5-4
gtk2-engines-qtcurve 1.2.0-1
kde-config-gtk-style 1:1.1+svn5-4
It appears the firefox-bin process continuously poll()s fd 3 after the
fd has been closed. Looks like fd 3 is the socket used to talk to X;
strace says:
[... during startup ...]
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
[... during buggy shutdown ...]
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
writev(3,
[{"<\2\2\0=\0\340\2<\4\2\0\232\0\340\2<\4\2\0\226\0\340\2<\4\2\0\7\1\340\2"...,
1044}, {NULL, 0}, {"", 0}], 3) = 1044
poll([{fd=3, events=POLLIN}], 1, -1)= 1 ([{fd=3, revents=POLLIN}])
read(3,
"\1\1\257:\0\0\0\0\35\0\240\3\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0",
4096) = 32
read(3, 0x7ff4f3d91074, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
close(3)= 0
close(26) = 0
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLNVAL}])
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLNVAL}])
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLNVAL}])
I have my gtk themes config set to "use my KDE styles". Of the
available widget themes on this machine, I can reproduce the bug using:
Cleanlooks
Oxygen (the default)
GTK+
Phase
but *not* when I use:
CDE
QTcurve
Motif
Plastique
Hope that's useful info to someone.
Cheers
Duncan
--
Duncan Gibb - Technical Director
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk/ || t: +44 870 608 0063
Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#454498: What is the status of Cyrus IMAPD?
Henrique de Moraes Holschuh wrote: BS> Help is needed, we just don't have enough time right now. Ironically, the thing which is eating my time this weekend is a big Cyrus 2.2/Sarge-i386 to Cyrus 2.3/Lenny-amd64 migration... HMH> Well, give me confirmation that I can scrap every change outside of HMH> debian/ in the 2.3 branch, and I will have one based on the HMH> upstream tarball + separate patch with anything already in CVS by HMH> the end of the next week... I'm not sure that's such a good idea. Policywise it seems good to base our releases on the "clean" upstream tarball, but actually those tarballs aren't really clean. The 2.3.15 release from CMU still contains assorted CVS cruft and a large number of generated files which we've deliberately removed from our svn repo. I will have a look at any missing updates and whitespace differences as soon as I can. The update from 2.3.14+security to 2.3.15 will require porting a few patches we use on the Sirius builds. I notice Simon Matter has already done an unofficial UoA auto-* patchset for 2.3.15, which will save some time. HMH> But that won't help with the 2.3 migration to unstable, the upgrade HMH> path is still missing, and help with that would be very, very HMH> welcome. Yes, please. Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#454498: cyrus-imapd-2.3: just for information, the current package doesn't build anymore
Xavier Bestel wrote: XB> just FYI, I tried building cyrus-imapd-2.3 today (because the binary package XB> depends on libdb4.4 which doesn't exists). XB> /home/xav/cyrus/cyrus-imapd-2.3-2.3.8/sieve 2.3.8 is obsolete. Try 2.3.14 from svn export https://mail.incase.de/svn/cyrus22/branches/cyrus23/cyrus-imapd-2.3-development/ Tested best with libdb 4.7 (Lenny-Backports). Not yet tested with 4.8. XB> We're in real need of an updated package :) Yep. I'll merge 2.3.15 as soon as I have time. Others are working on upgrade scripts from 2.2. Once that's done we can start some release-engineering branches for Sid and for Lenny-Backports so people can actually use the thing ;-) Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#421942: [pkg-kolab] Bug#524427: kolab-cyrus-imapd: Please update to newer libdb
Clint Adams wrote: DG> Work is in progress on updating 2.3.13 tree to 2.3.14. CA> And now? Right now (svn r842), the 2.3.x branch at https://mail.incase.de/svn/cyrus22/branches/cyrus23/cyrus-imapd-2.3-development/ is 2.3.14 plus a dpatchified fix for CERT VU #336053, AKA http://www.debian.org/security/2009/dsa-1881 Sven has kindly merged his recent packaging improvements from the 2.2 branch. As soon as time permits, the development branch will get bumped to the 2.3.15 release with additional security patches, or 2.3.16 if upstream increment their version number again before then. The closely-related Sirius customer packages (which are an identical code base plus with some functionality patches like UoA auto-*) are in production on Lenny/amd64 with our in-house backport of BDB 4.7. We're now building with BDB 4.7 from backports.org, which potentially means a lenny-backports branch for Debian mainline as well as Sid and Squeeze. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#542833: cyrus-common-2.3: postrm file seems to be broken
Francis Russell wrote: FR> The cyrus-common-2.3 postrm script appears to be broken. Thank you for your bug report. This is a duplicate of bug #439217 - which was fixed in SVN by Sven more than a year ago (r743). We _really_ need to get a new release out ;-) Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#541739: cyrus-imapd-2.2: Please add Autocreate patch
David Stanaway wrote: DS> There is a patch maintained by the University of Athens which allows DS> autocreation of inboxes. See also bug #431931 which requests this be added to cyrus-imapd-2.3 - something much more likely to happen as UoA for 2.3.x is maintained in dpatch format, by me, for the Sirius builds. DS> This is useful in an environment with directory/krb5 auth that would DS> allow a simple account created email to trigger their mailbox to be DS> built, and stanndard subfolders created. Ought to be a standard feature. There has been some discussion about putting this patch in upstream: http://lists.andrew.cmu.edu/pipermail/info-cyrus/2009-June/thread.html But CMU are apparently working on a different approach. There are some issues with UoA auto-* in Murder environments. IMHO, this is not a reason to exclude a very useful patch, which does nothing without extra config options enabled, from the Debian builds. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525391: cyrus-imapd-2.3: please upload 2.3.x to unstable/sid
Noel Köthe wrote: NK> upstream declared 2.3 as the stable release since some time Thank you for your bug report. I have merged it with http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454498 so we don't have too many multiple "Oi! There's a new version!" bugs outstanding. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#454498: 2.3.14 in SVN
https://mail.incase.de/svn/cyrus22/branches/cyrus23/cyrus-imapd-2.3-development/ is now 2.3.14 -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524427: Bug#421942: [pkg-kolab] Bug#524427: kolab-cyrus-imapd: Please update to newer libdb
Mathieu Parent wrote: MP> Any news from Debian Cyrus Team about #421942 ? Discussion is ongoing. MP> Linked to this, upstream kolab cyrus imapd is version 2.3. MP> Will cyrus-imapd-2.3 hit unstable soon? Work is in progress on updating 2.3.13 tree to 2.3.14. Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524427: Bug#421942: [pkg-kolab] Bug#524427: kolab-cyrus-imapd: Please update to newer libdb
Mathieu Parent wrote: MP> Any news from Debian Cyrus Team about #421942 ? Discussion is ongoing. MP> Linked to this, upstream kolab cyrus imapd is version 2.3. MP> Will cyrus-imapd-2.3 hit unstable soon? Work is in progress on updating 2.3.13 tree to 2.3.14. Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 Debian Cyrus Team - https://alioth.debian.org/projects/pkg-cyrus-imapd/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#523989: cyrus-imapd-2.2: [debconf_rewrite] Debconf templates and debian/control review
Sven Mueller wrote: SM> Apart from that I'm quite fine with the reworded english text. I have formed the intention to drop these changes into the honestly-it-will-get-done-real-soon-now 2.3.14 branch. Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#121132: Regex vs glob for pinning (was Re: Bug#121132: [patch] Proposed regex pinning feature)
Josef Kufner wrote: DG> So you can write, for example: DG> Package: /.*openoffice\.org.*/ JAK> I would like to have something like this instead: JAK> Package: openoffice.org-* JAK> This is also similar to what seems to be available JAK> for versions already (according to apt_preferences(5)): JAK> Pin: version 5.8* JK> It would be nice to have both syntaxes. Perl regexp is JK> powerful; shell-like wildcards are short and mostly sufficient. I agree, but I wrote the patch the way I did for two reasons: - I wanted it working that afternoon - Apt already uses this regex engine for searching It would be possible to write a globbing engine, or a glob-to-regex translator, but that would be a more intrusive patch. The places where "*" already has meaning in Apt preferences are in fact neither - they're just a way to say "all" or "prefix match" (so "Pin: version 5.8*" does what you expect, but "Pin: version *sirius*" does nothing). JK> When we have perl regexp support, it should be easy to add JK> shell-like wildcards. Maybe just escape dots and other characters JK> and replace "?" -> "." and "*" -> ".*". I think if we're going to have globs, we should have fully-functioning globbing such that the syntax means the same everywhere. Perhaps someone from the Apt team could comment on what feature set is actually desirable. Cheers Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ || t: +44 870 608 0063 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#121132: [patch] Proposed regex pinning feature
Hi
The attached patch adds a very basic and crufty extension to apt policy
such that pinnings can use regex matching. If the name given on the
"Package:" line in the apt preference file begins and ends with '/', it
is interpreted as a regular expression (with ^ and $ pre- and post-fixed
for a semblance of safety).
So you can write, for example:
Package: /.*openoffice\.org.*/
Pin: release a=unstable
Pin-Priority: 900
and get approximately the behaviour you might expect.
This is potentially dangerous, potentially expensive, and not the glob
feature more intuitively suggested by the original reporter of bug
#121132. There is no error reporting and no documentation. And it's
been written by someone with no prior knowledge of the apt internals,
and who does not speak C++.
If people are interested, I'll try to find time to fix some of those
issues ;-)
As it stands this applies to the Lenny and the Experimental source.
Tested only briefly, only on Lenny/amd64.
Cheers
Duncan
--
Duncan Gibb - Technical Director
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk/ || t: +44 870 608 0063
diff -rub apt-0.7.20.2/apt-pkg/policy.cc apt-0.7.20.2/apt-pkg/policy.cc
--- apt-0.7.20.2/apt-pkg/policy.cc 2009-02-07 15:09:35.0 +
+++ apt-0.7.20.2/apt-pkg/policy.cc 2009-03-28 17:08:34.0 +
@@ -34,6 +34,7 @@
#include
#include
+#include
/*}}}*/
using namespace std;
@@ -181,8 +182,14 @@
Pin *P = 0;
if (Name.empty() == true)
+ {
P = &*Defaults.insert(Defaults.end(),PkgPin());
- else
+ // Set..
+ P->Type = Type;
+ P->Priority = Priority;
+ P->Data = Data;
+ }
+ else if (Name[0] != '/')
{
// Get a spot to put the pin
pkgCache::PkgIterator Pkg = Cache->FindPkg(Name);
@@ -201,12 +208,34 @@
{
P = Pins + Pkg->ID;
}
+ // Set..
+ P->Type = Type;
+ P->Priority = Priority;
+ P->Data = Data;
}
+ else // Do a regex pin
+ {
+ if (Name[(Name.length()-1)] != '/')
+ return; // Regex pins must begin and end with '/'.
- // Set..
+ regex_t Pattern;
+ string mypat = "^" + Name.substr(1,(Name.length()-2)) + "$";
+ if (regcomp(&Pattern, mypat.c_str(), REG_EXTENDED | REG_ICASE | REG_NOSUB) != 0)
+ return; // Regex does not compile.
+
+ for (pkgCache::PkgIterator Pkg = Cache->PkgBegin(); !Pkg.end(); ++Pkg)
+ {
+ if (regexec(&Pattern,Pkg.Name(),0,0,0) == 0)
+ {
+ P = Pins + Pkg->ID;
P->Type = Type;
P->Priority = Priority;
P->Data = Data;
+ }
+ } // end package iteration loop
+
+ regfree(&Pattern);
+ }
}
/*}}}*/
// Policy::GetMatch - Get the matching version for a package pin /*{{{*/
Bug#454498: 2.3.13 now available.
Centurion Computer Technology (2005) Ltd wrote: CCT> Now for cyrus 2.3. CCT> What's the status I've created a proposed 2.3.13 branch - see http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/2009-February/002609.html and replies - and am trying to make time to clean/post/commit other patches currently in the Sirius repo, starting with the smallest, best-tested, and already-committed-upstream ones. CCT> and what needs to be done. Testing. Feedback. More testing. A clean upgrade path from 2.2. Duncan -- Duncan Gibb - Technical Director Sirius Corporation plc - control through freedom http://www.siriusit.co.uk/ t: +44 870 608 0063 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#454498: 2.3.13 now available.
Centurion Computer Technology (2005) Ltd wrote: DG> What help would the Debian Cyrus Team most appreciate? [I deliberately didn't copy my original message to the bug address, since it was a rather general discussion. But others have, so browsers of the bugs database may wish to read http://lists.alioth.debian.org/pipermail/pkg-cyrus-imapd-debian-devel/2008-December/002585.html for context.] OS> I see no sense to package cyrus-imapd 2.3 right now, it will OS> not get into next stable, so sensible approach is to wait for OS> lenny to release and after that move cyrus-imapd-2.3 to OS> unstable CCT> I disagree. It should get into experimental ASAP and start CCT> getting some work done so that by the time lenny releases, CCT> we have it ready to move into unstable I think both points of view can be accommodated. We're already producing, and will continue to maintain, unofficial 2.3 packages for Etch and for Lenny, but it's unlikely we'll need binaries beyond amd64 and i386. Of course it's too late even to think about official Lenny, but maybe backports would carry 2.3 once it's in Sid... 2.3.8 is already in experimental, but incase's cyrus23 SVN branch hasn't been touched for a year. I'm guessing from the tiny volume of traffic on the coordination list, and the quietness of the SVN repo that the team don't have time to update to 2.3.13. We've already done that, and added a bunch of tweaks and new patches that suit _our_ needs. We'd love to see a 2.3 package set in official Debian that meets _everyone's_ needs. We're willing to contribute existing code, people's time, SVN servers, build hosts, etc, to help that happen. How can we best do this? Who else is doing the same things? CCT> We are talking about a relatively well tested and stable CCT> upstream source My personal perception is that the upstream developers are mostly dealing with large but fairly static installations (in universities), so while they do care deeply about scalability and do drive some new features, they don't hit as many corner cases or experience as much demand for cool new shiny stuff as we do deploying mainly in the SME and local government space. But that's just my excuse for all the patches we put in ;-) "Stable" in this context can mean "slow-moving"... Cheers Duncan -- Duncan Gibb, Technical Director Sirius Corporation plc - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#466404: RTNL: assertion failed at net/ipv4/devinet.c when using bonding
We can reproduce this bug - or something remarkably similar - in a running (as opposed to newly booting) system of a different architecture to the original reporter. Our kernel is linux-image-2.6.18-6-686 version 2.6.18.dfsg.1-18etch1 and we get the dmesg output RTNL: assertion failed at net/ipv4/devinet.c (985) [] inetdev_event+0x3e/0x286 [] _spin_lock_bh+0xb/0x18 [] _spin_lock_bh+0x8/0x18 [] rt_run_flush+0x68/0x8f [] notifier_call_chain+0x19/0x32 [] dev_set_mac_address+0x46/0x4b [] alb_set_slave_mac_addr+0x5a/0x7f [bonding] [] alb_swap_mac_addr+0x99/0x138 [bonding] [] bond_change_active_slave+0x187/0x27f [bonding] [] bond_select_active_slave+0x8d/0xbb [bonding] [] bond_mii_monitor+0x363/0x3a8 [bonding] [] bond_mii_monitor+0x0/0x3a8 [bonding] [] run_timer_softirq+0xfb/0x151 [] __do_softirq+0x5a/0xbb [] do_softirq+0x36/0x3a [] apic_timer_interrupt+0x1f/0x24 [] default_idle+0x0/0x59 [] default_idle+0x31/0x59 [] cpu_idle+0x9f/0xb9 [] start_kernel+0x379/0x380 when we "ifconfig down" or "ethtool -s speed " one of the slaves of a bond running in mode 6 (balance-alb). This does not happen in mode 0 (balance-rr). Each of our bonded interfaces has two e1000 slaves, which are are on different physical cards on the same PCI bus. Each card has two NICs but no bond uses two NICs on the same card. The relevant PCI bus looks like this: 02:08.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 02:08.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 02:09.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 02:09.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 02:0a.0 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) 02:0a.1 Ethernet controller: Intel Corporation 82546EB Gigabit Ethernet Controller (Copper) (rev 01) The modprobe config looks like this: alias bond0 bonding options bond0 mode=balance-alb miimon=100 max_bonds=8 alias bond1 bonding options bond1 mode=balance-alb miimon=100 max_bonds=8 The interfaces config looks like this: auto bond0 iface bond0 inet static address 192.168.1.1 netmask 255.255.255.0 pre-up /sbin/modprobe bond0 pre-up /sbin/ifconfig bond0 up pre-up /sbin/ifenslave bond0 eth2 eth4 down /sbin/ifenslave -d bond0 eth2 eth4 auto bond1 iface bond1 inet static address 192.168.2.1 netmask 255.255.255.0 pre-up /sbin/modprobe bond1 pre-up /sbin/ifconfig bond1 up pre-up /sbin/ifenslave bond1 eth5 eth7 down /sbin/ifenslave -d bond1 eth5 eth7 I've tried to find out whether this is a know problem upstream and if so whether it's fixed in a later kernel version. I've not found an answer yet. -- Duncan Gibb, Technical Architect Sirius Corporation - The Open Source Experts http://www.siriusit.co.uk/ Tel: +44 870 608 0063 || +44 7977 441 515 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
