=== asac__ is now known as asac [00:29] https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/179767 [00:29] Launchpad bug 179767 in update-notifier "update-notifier doesn't report unreachable mirror" [Undecided,New] === asac_ is now known as asac === asac_ is now known as asac === bigon is now known as bigon` === XSource_ is now known as XSource [06:39] Good morning [06:40] pitti! [06:41] * pitti hugs Hobbsee, happy new year! [06:41] * Hobbsee hugs pitti back! Happy New Year to you too! [06:43] grumble. i refuse to blackout, dammit! [06:47] * pitti dist-upgrades and gets "E: Internal Error, Could not perform immediate configuration (2) on libstdc++6" [06:47] Just like the buildds! [06:48] pitti: Leave all gcc stuff alone, upgrade libc6 and tzdata first. [06:48] (at least that works for me, both the real system and the pbuilder) [06:49] * persia advocates aptitude which has not exposed this error on live systems or chroots [06:50] * minghua think that's an error message from APT. [06:50] minghua: ah, thanks, that work [06:50] s [06:50] minghua: yes, it is [06:50] pitti: Glad to help. :-) [06:59] pitti: http://launchpadlibrarian.net/11059338/buildlog_ubuntu-hardy-powerpc.libsdl1.2_1.2.12-1ubuntu2_CHROOTWAIT.txt.gz [06:59] pitti: So, it's not just you [07:00] StevenK: So there are still buildds broken by that upgrade bug? [07:01] powerpc and sparc, it looks like. [07:01] i386 and amd64 were busted, but they were fixed [07:02] Yeah, I remember hearing someone fixed the buildds during the holiday, wasn't sure if all are fixed. [07:02] We're waiting on infinity to do sparc/powerpc, but elmo consented to doing i386/amd64. === asac_ is now known as asac === fabbione is now known as thegodfather [08:10] moin [08:11] hey stgraber, happy new year! [08:12] hi pitti, an happy new year to you too !!! [08:45] infinity: did the new pkg-create-dbgsym -proposed packages work? if so, I'd like to move them to -updates === pitti is now known as pitti_ === stu1 is now known as stub === XSource_ is now known as XSource === luka74 is now known as Lure === pedro__ is now known as pedro_ === amit1 is now known as amitk [11:38] pitti: Hi, please give back: cheops-ng. Thanks. [11:47] * Hobbsee waves [11:47] * Hobbsee sighs at $work [11:47] Hi Hobbsee [11:47] * Hobbsee is glad for the good relationship $employees at $work have with the local police. [11:48] australian emergency number really does work! [11:49] Hobbsee: what happened? [11:49] geser: drunken idiots, theiving. [11:49] unfortunately, no one could really go near them terribly much, as they were carrying glass bottles. [11:50] they'd learnt from last time, it appears, where they only managed to look suspicious, and call me a bitch. *shrug* [11:50] http://nobodyscores.loosenutstudio.com/index.php?id=318 <-- Hobbsee [11:50] mvo: Hi, we have libcompizconfig-backend-{gconf,kconfig} and compizconfig-backend-{gconf,kconfig} (imported from Debian). Do we need both? [11:51] Spads: heh === cjwatson_ is now known as cjwatson [12:10] hello, can anyone help me with dependency problem in debian package? [12:10] https://launchpad.net/~xmlich02/+archive/+builds?build_text=&build_state=all [12:11] joejoe: That's not a package from Debian. [12:11] joejoe: is that a l (ell) instead of a | (pipe) before autotools-dev? [12:11] This is also not a support channel, for PPA or otherwise. [12:13] oh i'm sorry, can you tell me where is right place to ask? [12:13] * Fujitsu suggests that #launchpad would be the correct place, but is likely entirely useless. [12:14] looks like a package problem to be [12:14] "lautotools-dev" => no such package [12:14] It is. [12:15] Fujitsu: it's #launchpad in the hope that someone takes action, and answers [12:15] Fujitsu: which usually ends up being you. [12:18] okay, thank you, i'm just newbie [12:18] joejoe: Anyway, drop the l from the start of lautotools-dev, and things might work. [12:20] Assuming somebody hasn't uploaded broken fixes to buildd-killing bugs, or has fluked impressively and broken the known-broken brokenness fix. [12:22] Fujitsu: well, assuming they don't do that until...what is it...let me check - has it been delayed again? oh, until 2.2 now, yes. [12:23] Fujitsu: what's the known-broken brokenness fix? [12:24] Some people apparently feel it a good idea to upload fixes that they know are broken to PPA. [12:24] oh, right, so that's what you meant. [12:24] Fujitsu: bring on mid-jan, that's all i have to say. [12:25] Fujitsu: and if mid-jan doesn't bring anything interesting, bring on the ritual burnings of the end of jan! [12:25] Haha. [12:26] * Hobbsee checks over her collection of flaming torches and pitchforks, and sees them all in good working order. [12:28] Fujitsu: did you call jono, then? [12:29] Hah, I was thinking of commenting on the timing. [12:38] geser: no, the one from debian looks like a duplicate with a different name [12:41] imbrandon: could you come around in #debian-qt-kde to talk about the kde4 bindings? [13:20] pitti: They seem to be working well. [13:21] pitti: I may quickly go through some PPA logs when I'm "at work" (in about 4 hours) and make sure before I give you a green light. [13:25] infinity: the problem is the chroot waiting ones in buildd [13:26] * Hobbsee preemptively offers infinity the link to the Kmos Report. [13:27] * persia notes that Google now has that, as a lucky guess for "KmosReport" [13:27] hah [13:27] * Hobbsee wonders how high that comes up in a "kmos" search. [13:28] nope, not very high. aww [13:28] Kmos: oh, and seeing as you now *aren't* externally scheduled now, and are clearly here, would you care to continue the discussion? [13:29] but in -motu [13:30] Hobbsee: what are you talking about ? [13:30] Kmos: https://wiki.ubuntu.com/MOTU/Council/KmosReport - 4th from the bottom [13:30] * Hobbsee forgot that you're probably not subscribed to that page, so didn't see the wording [13:31] Hobbsee: No, I'm not. are you talking about persia? [13:31] Kmos: about persia's entry, yes. [13:32] Hobbsee: I think I should not discuss that things with you.. [13:32] only by the ones from MOTU Council. [13:33] I believe the discussion was ongoing in #ubuntu-motu until you had to attend to something else. [13:33] Kmos: actually, you should probably discuss it with those who you were previously discussing it with, before you went to lunch, in #ubuntu-motu, which was where the previous discussion was. [13:34] Hobbsee: it's lunch time here.. but let's go for another one. [14:02] hi folks [14:02] anyone around? [14:04] no [14:06] well that sucks [14:06] most of us are on holiday ... [14:06] I see... [14:07] If I have questions say regarding Gtkmm, would this be a good place to ask? [14:07] ogra: holiday? you get holidays? [14:07] !ask [14:07] Please don't ask to ask a question, ask the question -- All On One Line, so others can read it and follow it easily --. and if anyone knows the answer they will most likely answer. :-) [14:08] Hobbsee, we pretend to [14:08] CheGuevara: I didn't ask to as a question [14:08] CheGuevara: I'm trying to find a channel where I can discuss Gtk [14:08] probably #gtk ? [14:09] roydog: If it's not specific to Ubuntu's gtkmm package, then it's not a good place to ask. [14:09] well I am using ubuntu's Gtkmm package [14:09] and I'm trying to develop software for gnu/linux/ubuntu [14:10] I kinda figured this place might apply since it's design to help folks develop ubuntu no? [14:10] then this is clearly the wrong channel (see topic) [14:10] ah yeah [14:10] I see hehe [14:10] :( [14:10] tx [14:24] Keybuk: not sure whether you saw the wiki diff for policykit-integration: considering sudoers as 'admins' is highly non-trivial [14:24] Keybuk: ATM PK considers members of group 'admin' as admins [14:25] ideally we would have admins == set of people who can run arbitrary sudo commands, but determining this set of people is hard [14:27] pitti: this doesn't surprise me :-/ [14:27] it's probably easier to have sudo talk to PK than PK talk to sudo === cprov is now known as cprov-lunch [14:27] (ie. sudo uses PK instead of sudoers) [14:27] Keybuk: so, the spec needs some more discussion now which I hoped to do in tomorrow's meeting (but that was cancelled now) [14:28] Keybuk: well, 'sudo uses PK' would mean to have %admin ALL=(ALL) ALL in /etc/sudoers AFAICS [14:29] Keybuk: anyway, just to inform you about the changing of an approved spec; not sure ATM what the best solution is [14:30] discussion is probably best for ubuntu-devel ML [14:30] right [14:38] doko: do you happen to have merged sane-backends already? [14:39] doko: I need to change the package, and I can merge it along the way if not [14:39] pitti: no, please go ahead === Ubulette_ is now known as Ubulette [14:57] doko: libsane-doc> it would be significantly easier, and AFAICS not less correct to install the documentation into libsane-dev; WDYT? [14:58] pitti: np, as long as it doesn't land on the CD [14:58] yes, we don't install -dev on CDs [15:01] pitti: Could you give back: cheops-ng. Or should I wait with give-back till the ppc and sparc buildds are also fixed? [15:01] geser: might be better, since they'll fail; I hope infinity can fix the buildd chroots once he wakes up (or mvo fix apt :) ) [15:03] mvo: so it's ok to request the removal of compizconfig-backend-{gconf,kconfig} (the imported one) from hardy? [15:06] geser: that may be best for now, also I would like to resolve this in a way that we are package name compatible again (I wonder why the debian ones are named differently) [15:06] pitti: what is broken with apt ? [15:07] http://launchpadlibrarian.net/11116411/buildlog_ubuntu-hardy-powerpc.sudo_1.6.9p10-1ubuntu1_CHROOTWAIT.txt.gz [15:07] mvo: ^ this happened in all buildd chroots, and I got it on my laptop this morning, too [15:07] E: Internal Error, Could not perform immediate configuration (2) on libstdc++6 [15:08] mvo: pitti: elmo explained that this was because some things were treated differently for Essential packages [15:08] *ick* [15:08] infinity: was looking into that, too [15:09] persia/mvo/pitti: (FWIW) that was only part of the problem, even taking that out of the equation didn't seem to help [15:12] * mvo checks if he can reproduce it [15:12] mvo: this morning I was advised to first upgrade libc6 and tzdata, and then the rest; this worked [15:13] mvo: I have a backup of the chroot I can make available to you, if you can't easily reproduce [15:19] * pitti sighs at the mess in sane-backends [15:20] oh no ! [15:21] * ogra curses consolekit ... *nothing* works in LTSP anymore [15:21] ogra: ? [15:21] pitti, i cant do *any* administrative stuff at all [15:22] not even time-admin [15:22] ogra: you don't get a console on the thin clients? [15:22] ldm runs client side .... and starts ssh -X [15:22] consolekit doesnt know about ssh connections it seems [15:22] ah, I guess we need to teach CK about those kind of sessions then [15:23] even worse the unencrypted mode connects diretly to the clients X server by setting DISPLAY while doing everything else via ssh [15:23] (no XDMCP involved) [15:24] phew ... [15:24] Keybuk: got time to discuss UdevLvmMdadmEvmsAgain? [15:25] that'll be a good amount of work i guess ... === \sh_away is now known as \sh [15:30] doko: "Link using -Bsymbolic-functions." in sane-backends did not have a rationale; what does it do? [15:30] or, rather, why? [15:31] pitti: -Bsymbolic-functions does resolve intra-library symbols at link time, not at load time, reducing startup time, (run time, and shlib size) [15:31] psusi: sure, what's up? [15:32] doko: ah, ok; so it's purely optimization? or something to do with newer compiler? [15:32] Keybuk: well, I've spent the last few days working on the dmraid package and trying to make some headway in that area [15:32] optimization (and newer linker) [15:32] doko: thanks [15:32] Keybuk: one thing that I noticed is that vol_id has code built into it to regognize a dmraid siganture on a disk [15:33] right, that's not surprising [15:33] it has code to recognise most formats [15:33] Keybuk: this strikes me as a bad duplication of code... would it not be better to have udev call dmraid and ask IT if it sees a signature, and if so, set the variables appropriately? [15:33] psusi, well, that code3 is also in mdadm afaik ... [15:34] so you already have duplication [15:34] -3 [15:34] ogra: mdadm doesn't have anything to do with dmraid ;) [15:34] psusi: udev would have to then call about 500 helpers [15:34] one to detect lvm, one to detect dmraid, one to detect dm, one to detect ext3, one to detect ext2, etc. [15:34] far better to have one single library to do it all [15:34] right... [15:34] is it? [15:35] given the above, yes [15:35] is it really better if vol_id is out of date and fails to recognize a signature? [15:35] don't let vol_id get out of date? [15:35] mvo: request to remove compizconfig-backend-{gconf,kconfig} filed as bug #179876 [15:35] Launchpad bug 179876 in compizconfig-backend-kconfig "[Remove] Please remove compizconfig-backend-{gconf,kconfig} from hardy" [Wishlist,Confirmed] https://launchpad.net/bugs/179876 [15:35] difficult to do when you have to duplicate the code by hand [15:35] it's better than running 500 programs every single time a block device is dected [15:35] is it really that slow? [15:35] and what do you do when several programs both believe they have the block device? [15:35] psusi, oh, sorry for the unqualified statement then :) (/me is old mdadm user, was always enough for my raid0 setups) [15:35] if the block device has both ext3, lvm and dmraid signatures [15:36] udev needs to arbitrate... have some priority and once one claims it, the others can't have it [15:36] that's what vol_id does [15:36] yea... it's just with out dated duplicate code [15:36] update the code :) [15:37] all we use vol_id for largely is to detect the signature [15:37] ;) [15:37] (it's also used by HAL, etc.) [15:38] another issue I noticed is that it correctly identifies my disks as raid members, but then udev asks it to id the partitions on sda, of which, only the first is actually accessible since the others are beyond the end of the device [15:38] ? [15:38] so it identified my windows partition as a usable fs, which resulted in a UUID link being created to it, which is in fact, broken [15:38] ? [15:38] the raw disk is a raid member [15:38] why ? [15:38] ? = I don't understand [15:39] but the kernel still sees the partition table on it and tries to create the partitions [15:39] sda and sdb are in a raid0 [15:39] but the kernel still sees the partition table on sda, even though it applies to the raid as a whole, not just to sda [15:39] so it goes ahead and creates an sda1 for my windows partition [15:39] sounds like a kernel issue [15:39] and vol_id is run on sda1, which says it's a usable fs [15:40] in a way, it is... it would be easily solvable if we relied on udev to worry about the partitions instead of the kernel [15:40] we don't [15:40] we rely on the kernel [15:40] is there any movement towards doing that? with kpartx or somesuch? [15:40] right, but is there any plan to change that? [15:40] no [15:40] no plans [15:40] damn [15:41] well then, another possible solution is that if vol_id has tagged the entire disk as a raid member, then any partitions on it should be ignored [15:41] ignored by what? [15:41] (that's possible, btw) [15:42] vol_id [15:42] IMPORT{parent}=="IS_RAID", ENV{IS_RAID}=="YES", OPTIONS+="ignore_device" [15:42] and well, everything really [15:42] that would make udev ignore partitions on entire-disk raids [15:42] and wouldn't even tell HAL about them [15:42] (assuming the disk has IS_RAID=YES of course) [15:42] hrm.... I don't think it's IS_RAID, I think it's ID_FS_USAGE=raid_member or something [15:43] but yea, that's the idea [15:44] ok... that would take care of that part... now I have removed the initramfs scripts for dmraid to run it during boot, and am working on a udev rule now to ask it to probe a block device to see what raid set it is a member of [15:44] and store that information as a variable, then invoke dmraid and ask it to assemble that raid set [15:45] normally you'd have two sets of udev rules [15:45] I was thinking of keying on the ID_FS info vol_id pulls... it identifies the disk as an "nvidia_raid_member" for instance [15:46] first set to check whether it is a raid device, and then activate dmraid [15:46] and a second set to run vol_id on the filesystem inside the assembled raid device [15:46] so when that variable is set, it should know it should run dmraid, and not other stuff [15:46] right [15:46] well, that comes into the next problem [15:46] how to mark the assembled device as published [15:50] Hi, i wanna know why warsow-0.32 was only published in Ubuntu Hardy, and Ubuntu Gutsy still have warsow-0.31 [15:50] as it is udev ignores dm* devices [15:50] see mdadm, devmapper, etc. [15:50] they have a second 85-* rules file that runs vol_id again [15:50] aye [15:50] this time on the raid itself [15:50] ohh [15:50] I thought that was not done currently due to race conditions? [15:51] need a way for the tool to mark the device as published? [15:51] no [15:51] it might be 65-* [15:51] I forget [15:52] I thought that was the whole point of that spec... it was saying that udev sees the md device as soon as it is created, before it is actually usable [15:52] right [15:52] so there has to be a method for the tools to inform udev that it is now ok to diddle with the device [15:52] and then we ask mdadm whether it's usable [15:52] it says no, so we ignore iot [15:52] and we get a change event later when it is available [15:52] ohh [15:52] as long as dmraid follows the same pattern, you're fine [15:53] but that doesn't cover the case of snapshot volumes and such that should never be published [15:53] why shouldn't they? [15:53] because they would be tagged with the same UUID? [15:53] OPTIONS="link_priority=-100" [15:53] ENV{DM_TARGET_TYPES}=="*snapshot-origin*", OPTIONS="link_priority=-90" [15:53] elmo: thanks, but I can reproduce it now [15:53] we adjust the link priority [15:53] and other dm devices are created by the tools internally that should NEVER be opened [15:53] so the UUID we want wins [15:54] ahhh [15:54] though actually.... the thing is... when using a snapshot, you have an original device which starts out as just a linear mapping [15:54] that's the device you mount the filesystem on [15:55] right, the snapshot-origin one [15:55] Hi, i wanna know why warsow-0.32 was only published in Ubuntu Hardy, and Ubuntu Gutsy still have warsow-0.31 [15:55] then when you make the snapshot, that linear mapping is replaced with a snapshot-origin [15:55] it goes from being linear to snapshot-origin [15:55] yea [15:55] so we give that one a higher link priority [15:55] so it wins the /dev/disk/by-uuid thingy [15:55] -90 > -100 [15:55] https://edge.launchpad.net/ubuntu/+source/warsow/ [15:55] but that's still where the uuid should point [15:55] that's what happens [15:55] Zero: You might want #ubuntu-backports [15:56] =/ [15:56] ok [15:56] well, that might not be correct thoguh, because you can also do it the other way around, where the mounted device is the snapshot, not the origin [15:56] *shrug* [15:56] at that point, I cease caring :) [15:56] heh [15:56] if you want to do it the other way around, you can use the /dev/mapper names :-) [15:56] well, that's kind of why that spec was written... [15:56] no [15:57] well the problem is that certain things that udev does automatically can cause breakage [15:57] yea... the whole published flag bit [15:57] udev doesn't do anything harmful automatically [15:57] auto mounting? ;) [15:57] udev doesn't mount anything [15:57] it might not... but things higher up do [15:57] *shrug* [15:58] based on what udev has done and found [15:58] it doesn't matter that it does the right thing or not [15:58] it just matters that it's consistent [15:58] and predictable [15:58] if you want to do something other than the default, there are changes you make to do that [15:58] the whole point of that spec was that there needs to be a way for the tools to explicitly let udev know it's ok to do all of its probulating and such, or not... it just can't decide reliably on its own [15:59] right, and we have that mostly ;) [16:00] hrm... though I suppose that in dmraid's case... as long as the synthetic devices get link priority that will fix that UUID problem [16:00] AND lock out lvm from claiming the devices [16:01] there's one bug I saw where a guy was trying to use lvm on top of dmraid and the lvm tools were trying to bypass dmraid and act directly on the underlying disk partitions [16:01] we do? [16:03] ohh, you were refering to the UUID part? [16:07] hey folks. Is there any reason /etc/init.d/rc.local does not have a stop section? 'cause is getting a little tedious to add a do_stop on my ubuntu machines and symlink it to the appropriate runlevels [16:07] not to mention presumably will be a hassle in future updates at some point [16:10] ... also not sure it is quite correct to symlink it to K00rc.local in 0,1,6 [16:10] nemo: why do you need one? [16:11] Keybuk: well, for local stuff that needs cleaning up [16:11] Keybuk: that's what that runlevel is for :) [16:11] Keybuk: in this case, killing non-ubuntu handled services [16:11] like my test servers [16:11] nemo: why not just write your own init script? [16:11] and unmounting CIFS shares [16:11] why does the service need killing? [16:11] Keybuk: because that's the appropriate place to put it? [16:11] no [16:11] rc.local is not appropriate for anything [16:12] ok. let me rephrase. [16:12] why does ubuntu not have a shutdown script section [16:12] if that is not rc.local [16:12] because that's not what rc.local is for [16:12] it does [16:12] which is... [16:12] /etc/rc0.d and /etc/rc6.d [16:12] put files in there [16:12] *sigh* I mean a generic one similar to /etc/rc.local [16:12] a convenient place for adding various user-specific shutdown commands [16:12] because that would be silly [16:12] no more silly than having an /etc/rc.local [16:13] if you need to shut things down, you need more complicated care than "drop it here" [16:13] adding scripts to /etc/init.d *is* convenient :) [16:13] we only have rc.local because some standards body says we should :-/ [16:13] most services don't need shutting down [16:13] they get shut down automatically when the power goes away ;) [16:14] Keybuk: the mounts are the big thing. vboxfs and CIFS in particular [16:14] since otherwise they !@#$ up ubuntu on shutdown [16:14] they're unmounted if they're in fstab anyway [16:14] the application server, I like to do it a bit more tidily [16:14] Keybuk: they get done in wrong order [16:14] after the kernel unload [16:14] thus fails. [16:14] tidy => write an init script of your own and symlink it into the appropriate runlevels [16:14] tidy != rc.local [16:15] Keybuk: bah. whatever. not going to write 3 scripts for just a few lines of cleanup. I like rc.local, clearly you guys do not. question answered === marek is now known as five_ === five_ is now known as marek [16:15] wherever we put the shutdown equivalent, it would not be in the right place for you [16:15] the only logical place is right at the *start* of shutdown [16:15] at that point, all the daemons are still running [16:16] even X is still running [16:16] absolutely [16:16] so you inherently *CANNOT* unmount filesystems there [16:16] perfect place for it [16:16] that's why I have K00 there [16:16] since the filesystems are still in use [16:16] Keybuk: right. nice place for local shutdowns :) [16:16] except it isn't [16:16] what can you shut down from there? [16:16] the 3 things I just mentioned. [16:16] they all work fine [16:16] no, you can't [16:16] sorry, but I seriously doubt they work fine [16:17] and if they do happen to, for some bizarre circumstance, work fine for you [16:17] they would not work fine for everybody [16:17] they work better than ubuntu freezing on shutdown, which is well covered in forums [16:17] filesystems can not be unmounted reliably until all processes are killed [16:17] ubuntu freezes on shutdown in its default configuration? [16:17] well, yes, that's where a little common sense occurs [16:17] do you have bug#s for that? [16:17] Keybuk: if using CIFS mounts, yes [16:17] how are you using the CIFS mounts? [16:18] how come they aren't unmounted by S40umountfs ? [16:18] ... userspace mounts. I have no control over 'em except to clean 'em up [16:18] Keybuk: perhaps because umountfs only checks fstab? [16:18] instead of scanning mount table? [16:18] how do you mount something not in fstab? [16:18] haven't checked [16:18] BZZZT [16:18] umountfs scans /proc/mounts [16:18] alrighty. well. it is missing 'em somehow [16:18] or wrong order, or something. [16:18] so that's a "bug" :-) [16:18] anyway, plenty of others have run into it in forums [16:18] not a reason to complicate the process even more [16:19] have any of them filed bug reports? [16:19] well. good to know, anyway, for me, rc.local works well :) the vbox thing, no good workaround for that [16:19] dunno. my issue was not about fixing that. :-p [16:19] vbox? [16:19] that is only one of the things I use an initial shutdown script for [16:19] why does vbox need to be shut down? [16:19] Keybuk: you do the vboxfs kernel module load prior to loading fstab, and prior to unloading fstab [16:20] so, any vbox mounts fail on startup/shutdown [16:20] I have those in rc.local as a workaround [16:20] and rc.local.stop :-p [16:20] calc: can you please build the next OO.o against libneon27-dev instead of libneon26-dev? [16:20] yes, but why do you need to do anything on shutdown? [16:20] what are you doing there? [16:20] Keybuk: 'cause otherwise the kernel module fails to unload cleanly? [16:20] 'cause it complains about still being in use? [16:20] Keybuk: anyway, those are two of 'em the third is issuing app server shutdowns. [16:21] why is the kernel module being unloaded at all? [16:21] why do app servers need to be shut down? [16:21] having a local shutdown script section is not that unusual frankly [16:21] not everything warrants an init.d entry [16:21] Keybuk: dude. I've stopped caring long ago. there are reasons for it, clearly you don't feel they are legit, fine, that's why you don't have an rc.local shutdown section [16:21] no [16:21] they aren't reasons for it ;-) [16:21] I appreciate you investing the time [16:21] but. whatever. if you fix the CIFS bug, I'll remove that section [16:21] 95% of the things people try and do on shutdown are bogus [16:22] the power is about to go away [16:22]