=== elkbuntu is now known as elky === ember_ is now known as ember [02:12] <__keybuk> kees: weird [02:13] <__keybuk> your patch to vte to fix bold fonts seems to break subpixel rendering [02:14] <__keybuk> I can't see why it would though [02:36] <__keybuk> oh, no, weird [02:36] <__keybuk> it's a fontconfig issue [02:38] <__keybuk> seems that its settings override gnome's, at least for gnome-terminal [02:38] <__keybuk> ArneGoetje: ? [02:49] Keybuk: gnome-terminal uses vte for its terminal. vte does not use gnome settings but fontconfig. That's why. [02:50] __keybuk: ^ [03:14] ArneGoetje: but it worked in gutsy? [03:15] oddly enough, if I remove the fontconfig directory, gnome-terminal does appear to obey gnome settings [03:16] indeed, it obeys them enough that they update live with changes to the font rendering dialog [03:16] so it seems that it's more that vte allows fontconfig to override xsetting [03:16] whereas other gnome apps only obey xsetting ? [03:17] (with the added sub-bugs that fontconfig doesn't follow the preferences *and* fontconfig doesn't honour user changes to its conf.d directory) [03:25] Yay for daily alternate CD brokenness. [03:34] Keybuk: yeah... seems like there is more to fix... [03:38] Keybuk: I guess that other gnome apps allow fontconfig to override xsetting... [03:39] Keybuk: err... do not allow, of course [03:46] oh its to do with a new kernel I think... [04:08] TheMuso: you get a chance to look at the mdadm/initramfs-tools stuff i was working on? [04:28] kirkland: Yeah looks fine to me. I also got my change uploaded as well. Now if someone uses usplash and has such errors, they will actually see them. [04:29] TheMuso: ;-) cool [04:29] thanks for taking a look [04:30] kirkland: np. [04:30] kirkland: One thing I forgot to check is that the documentation in the manpage was updated... [04:31] Rather, whether the docs were updated. [04:31] in the example script and the manpage. [04:32] i didn't touch the docs (yet) [04:32] kirkland: Right, because nothing is finalized? [04:33] TheMuso: right, i definitely have more to do on this [04:33] kirkland: Ok. [04:33] TheMuso: but my current focus has been shifted to iscsi support in the installer [04:33] kirkland: Gotcha. [04:33] kirkland: How is that going by the way? [04:34] TheMuso: well, i saw an iscsi target as a block device on the initiator for the first time today ;-) [04:34] TheMuso: it was an "aha" moment :-) [04:34] TheMuso: evand is here in Austin this week, so he's given me some good pointers [04:35] Ah ok. [04:35] kirkland: How much work was it to get the device to be seen in the initiator? [04:35] TheMuso: anyway, i've figured out the userspace magic to get it to the point of seeing a block device, so I'm over the initial hump [04:35] kirkland: Nice. [04:36] TheMuso: fairly well documented here: http://www.howtoforge.com/iscsi_on_linux [04:36] ah ok. [04:36] TheMuso: once you've discovered the target identifier, it's not much more than: [04:36] iscsiadm -m node -T iqn.1992-08.com.netapp:sn.84211978 -p 192.168.2.222:3260 --login [04:37] kirkland: Nice. [04:37] where "iqn...." is the identifier and 192..... is the IP [04:37] TheMuso: discovery is fairly straight forward too: [04:37] iscsiadm -m discovery -t st -p 192.168.2.222 [04:37] that should print out some awk-able iqn.1992-08.com.netapp:sn.84211978 looking strings [04:38] Nice. [04:38] TheMuso: I still need to figure out the /etc/fstab magic [04:39] TheMuso: i better call it a night... we're at Dell again tomorrow [04:40] kirkland: Ok have fun., [04:51] hi [04:51] any packages.ubuntu.com admin around? [05:02] jack: Frank Lichtenheld's email address is on the packages.ubuntu.com page [05:05] uhm, ok [05:06] just wanted to let someone know all source download links are broken [05:06] well, packages.ubuntu.com is still in a state of flux perhaps [05:07] how/why this? [05:07] jack: packages.ubuntu.com isn't formally run by the Ubuntu [05:07] it is/was Frank's service [05:07] oh ok [05:07] but he emailed a while back to say that he was running out of resources to do [05:08] it [05:08] a nicce service, though [05:08] so I'm not sure if it's on a new host now or not [05:08] perhaps that's what broke it [05:08] yes, it's a very needed service [05:08] you should sponsor that guy a bit maybe ;( [05:09] Well, the IP it's on now belongs to canonical. [05:09] well, I've just got a DSL connection and an old machine ;-) [05:09] johanbr: ah good [05:10] jack: my guess is that the move is still being worked out [05:10] ok [05:10] I'm not sure who'd responsible for it right now [05:10] *who'd be [05:11] it's a minor flaw anyway [05:11] i can find out the links of course [05:12] well, it'd be nice to get it fixed though [05:12] just a bit ugly ;) [05:12] yeah [05:30] anyone have a good citation for the time someone realize Debian had a ton of money just sitting around? [05:34] (am i miremembering it?) [05:35] doesn't ring a bell [05:37] i coulda sworn there was someone who was like "oh, we have all this money we forgot about" maybe im thinking of the linux fund? [05:37] like 2003, 2004-ish [05:38] I seem to recall something like that, too. Didn't a bunch of porter boxes get bought with it? [05:38] basically, im trying to do the research jeff atwood didnt [05:38] provided i dont get hit by tornado [05:39] sounds pretty bad outside right now [05:43] * RAOF doesn't get the reference [05:44] theres a thunderstorm [05:44] i mean a literal tornado; no metaphor here [05:45] http://www.wunderground.com/ [05:45] anyways, back to digging [05:53] pwnguin: I don't believe we ever discovered money we'd forgotten about; Debian's parent corporation, SPI, has a checkered history when it comes to receiving and accounting for donations [05:54] ("accounting for" in the sense that donations were received and in the early days, no records were kept of the earmarking and it wasn't clear how much of the money was meant to be an SPI cut vs. a Debian cut) [05:55] i guess it was linuxfund [05:56] not the spi [05:57] slangasek: But there was a period in 2003 or 2004 where we just spend any of it. I'm not sure if that has changed. [05:58] Debian did go through a phase when SPI suddenly was roused and became functional and Debian actually started /using/ some of the money, so I guess that sorta fits the description [05:58] heh [06:45] Good morning [06:45] ScottK: ah, not ATM; it won't give you the error for @kubuntu.org, although it probably should [06:53] moin pitti :-) [07:07] hi === tkamppeter_ is now known as tkamppeter === RAOF is now known as ROAF [09:16] morning all === seb128_ is now known as seb128 [09:48] pitti: do you have any idea about bug #249024 ? its the second report I have seen about this, it seems that for some reason localedef hangs for some people (#253180 is the other one) [09:48] Launchpad bug 249024 in update-manager "Process hanging while upgrading remotely to 8.04" [Undecided,New] https://launchpad.net/bugs/249024 [09:48] mvo: incidentally I'm just debugging this [09:49] pitti: heh :) is there another bug already that I should duplicate this to? [09:49] mvo: I'm using bug 249340 [09:49] Launchpad bug 249340 in langpack-locales "Gutsy->Hardy upgrade hangs in localedef" [High,Triaged] https://launchpad.net/bugs/249340 === ROAF is now known as RAOF [10:15] mvo: localedef uses a metric shitload of memory [10:15] mvo: in my "spare" time (ho ho) I've been working on paring it down, though am having some difficulty ensuring that it remains correct at the same time [10:16] mvo: but given that at the moment it uses 50MB or so, it's quite plausible that people's systems are simply thrashing to death [10:16] I just tried to create a gutsy chroot and upgrade locales, belocs-locales-bin, and libc6 to hardy, and it worked well (with the same locales as mentioned in the bug) [10:16] though that said I see that 253180 claims 1.2GB of memory, so probably not that in that case [10:16] cjwatson: hm, but 50 MB doesn't sound too scary? [10:16] I mean relative to modern memory sizes, not relative to the task it has to do [10:17] pitti: on a 256MB system it's probably enough to shove lots of other things into swap [10:17] cjwatson: I got a report by someone with 1,2gb of ram, so that is probably not the reason [10:17] it's certainly a chunk of what's responsible for making installations suck on 256MB systems [10:17] I was wondering if it might be a fd leak (update-manager might leak some) [10:18] but I haven't seen this problem in all my upgrade testing so far [10:20] cjwatson: ah, thanks for the reminder about memory thrashing. [10:20] * Hobbsee goes to burn an alternate cd, for the friend with 230mb of ram. [10:21] fd leak does seem plausible-ish if it only seems to happen in u-m [10:25] sjoerd: any idea how to forge intrepid's kvm to boot a gutsy CD? I just get an unintelligible exception dump [10:26] erm, soren ^ I mean; sorry, sjoerd [10:38] pitti: I actually thought it would Just Work[tm], but if not, there's the hack in the "How to boot Dapper, Edgy, Feisty or Gutsy ISO" section of https://help.ubuntu.com/community/KVM === giskard_ is now known as giskard [10:55] pitti: why does Jockey think that nvidia-glx-96 is the right driver for my card (ubuntu-core-dev/jockey/ubuntu branch)? === thekorn is now known as thekorn_ [10:59] pitti: my card is supported by 177, 171, 96 and Jockey doesn't show multiple version (on purpose, I guess) and installs 96. The highest number should be preferred over the lowest [11:02] unless there's a driver which supports all the available graphics cards [11:08] tseliot: it should show all three of them actually [11:09] pitti: I built jockey from the ubuntu-core-dev/jockey/ubuntu branch [11:09] tseliot: hm; do you have all modalias packages installed? [11:10] pitti: yes, they are installed [11:12] tseliot: hm; can you please do the foreground daemon/--debug exercise then? [11:12] tseliot: it did work fine the last time we tested it, didn't it? [11:13] pitti: yes, it did. I have modified xorg_driver.py and the custom handler but that should affect only the X part [11:13] aah [11:13] tseliot: does it work with the current intrepid packages? [11:14] pitti: I haven't checked yet [11:14] pitti: http://pastebin.com/m28cd8458 log [11:14] I currently have my amd64/nvidia box running, trying here.. [11:15] * tseliot gets the current package [11:16] 2008-07-30 11:11:30,712 DEBUG: querying driver db about HardwareID('modalias', 'pci:v000010DEd000002E2sv00000000sd00000000bc03sc00i00') [11:16] 2008-07-30 11:11:31,264 DEBUG: no corresponding handler available [11:16] tseliot: ^ seems it doesn't find it at all for you ATM [11:17] tseliot: with the current intrepid packages I get all three versions [11:17] (my GeForce 5200 is supported by all of them, it seems) [11:17] tseliot: did you run the test suite? any regressions from your modifications? [11:18] pitti: it seems to work well with the current package. [11:18] I'll do some testing with it [11:19] pitti: no, I didn't run your test suite. I would like to write something customised but I have to study your test suite first [11:19] tseliot: just try running it [11:19] tseliot: it doesn't make assumptions about guidance, it just does blackbox testing [11:20] after the move to x-kit, the entire set of tests should still succeed [11:22] pitti: is there a file which executes all the tests? [11:22] tseliot: just call "tests/run" [11:25] pitti: 3 failures and 2 errors. 2 errors and 1 failure should be my fault [11:25] * tseliot tries to debug things a bit [11:25] tseliot: please compare with current trunk [11:26] tseliot: occasionally one of the XML-RPC tests fails due to a race condition in the test suite [11:26] tseliot: feel free to pastebin and let me comment [11:26] pitti: ok, I'll try the current trunk [11:28] pitti: failures=2, errors=2 [11:28] errors for trunk: [11:28] tseliot: hm, fun; please show me? (they all succeed for me) [11:30] pitti: the log for trunk: http://pastebin.com/m4f1751bf [11:31] tseliot: can you please pastebin the test suite output? [11:31] tseliot: log is only helpful together with it [11:32] pitti: yes, I know, I'm uploading the output [11:33] pitti: output: http://pastebin.com/m4788c4fb [11:34] this is without X-Kit [11:34] mvo: hm, I just tried to upgrade a freshly installed gutsy to hardy in vmware; it gets as far as updating the package index, and then just disappears [11:35] mvo: main.log ends with "runing doUpdate() (showErrors=True)", no exception or so [11:36] mvo: http://piware.de/tmp/apt.log -> does that tell anything to you? [11:36] mvo: no exceptions on stdout/stderr either, BTW [11:38] tseliot: ah, the package thing is certainly because you don't have packagekit installed [11:40] * tseliot installs packagekit-gnome [11:40] tseliot: no, not -gnome [11:40] tseliot: the ubuntu branch doesn't use packagekit yet, but trunk does [11:40] (well, -gnome doesn't hurt of course, but jockey doesn't use it) [11:40] pitti: packagekit is a dependency of packagekit-gnome [11:41] * tseliot runs the test suit again [11:43] pitti: http://pastebin.com/m2a674f05 http://pastebin.com/m7d290e80 [11:44] tseliot: hm, no real idea right now about those two failures [11:44] but they should be totally unrelated to the xorg drivers, so maybe ignore them for now [11:45] tseliot: let's track those down later, shall we? [11:45] pitti: ok [11:47] mvo: I tried it again, this time with enabling universe/multiverse; same failure [12:08] tseliot: ping =) [12:08] sebner: yes? [12:09] tseliot: I was on holidays ^^, now time to look at my Xorg.log to discover why nvidia-glx isn't working? [12:10] sebner: can you send me an email with the log? I'll have a look at it later [12:10] tseliot: great, thx [12:12] pitti: oh, how strange. let me try that [12:15] pitti: could you strace it just to get some idea what might go wrong? maybe its segfaulting somewhere? [12:16] mvo: currently running apt-get dist-upgrade; I can do that afterwards, yes [12:16] mvo: shouldn't a segfault be displayed in the terminal, thuogh? [12:17] hm, maybe the root backend crashed, and the user-invoked GUI just exited with it [12:18] mvo: does it crash on unsatisfieable dependencies or so? apt.log seemed to have some resolution trouble, but nothing it couldn't handle AFAICS [12:20] pitti: it should not crash because of dependencies or anything like this, but if it does, the only explaination I have right now is a segfault somewhere [12:20] pitti: thanks, Please let me know what you found [12:20] ok, will do [12:20] mvo: dist-upgrade will still take a while, though [12:21] no problem, I fire up my vmware just to see if that is a general problem here [12:22] mvo: argh, I just accidentally killed the d-u, so I can as well do it now [12:23] mvo: how do I strace the 'inner' u-m which runs as roo? [12:23] mvo: or can I just call "sudo strace update-manager", does that work? [12:24] pitti: sudo strace -f update-manager should work I think [12:24] ok, doing [12:24] thanks [12:25] ok, crashed again [12:26] mvo: you were right, segfault [12:27] * pitti runs under gdb [12:28] mvo: ah, it's ignored by apport because it happens in the downloaded code [12:30] pitti: hm, that sets itself to /usr/bin/update-manager iirc. where does the crash happen ? somewhere in python-apt/libapt? [12:30] mvo: ?? -> ?? -> PyString_FromString () -> ?? [12:30] the second ?? is in libglib [12:31] and the topmost (first) ?? is at address 0 [12:31] not too helpful, I guess? [12:31] pitti: could you please paste the full thing somewhere? or is that all relevant information? [12:31] mvo: stack trace? that's all [12:31] pitti: meh, that is indeed not a lot [12:32] mvo: you can have the strace if you want, but it's largely uninteresting [12:33] it was a standard i386 gutsy desktop install, then apt-cdrom add the hardy.1 dvd [12:33] and then u-m [12:34] pitti: how big is the virutal image? I suppose to big to sent it over the network? === ogra_ is now known as ogra [12:34] pitti: I will try to reproduce it here [12:34] mvo: ugh, 8 GB; I'm afraid it is, yes :/ [12:35] pitti: hm, could you tar up /var/lib/dpkg and /var/lib/apt and /var/cache/apt (after apt-get clean) and /etc/apt/ and put that somewhere? maybe that is enough to reproduce it [12:35] sure [12:37] mvo: I'll add /var/log/dist-upgrade and /etc/apt, too [12:37] pitti: thanks [12:42] mvo: http://www.piware.de/tmp/apt-status-gutsy-about-to-upgrade.tar.bz2 [12:43] pitti: thanks, downloading [12:44] mvo: hm, hang on; I ran gutsy-final, not gutsy-updates; might that be it? [12:45] pitti: I can reproduce it here it seems, let me debug it further. it might be because of this, but I don't remember a fix in python-apt in gutsy-updates that would have this effect [12:45] mvo: there's no p-a in gutsy-updates [12:46] mvo: I'll upgrade some essential bits of this gutsy install before I dist-upgrade to hardy [12:48] pitti: ok [12:48] mvo: (python2.5, apt, update-manager) [12:49] Good morning pitti. I think allowing kubutu.org addresses is a good thing. I know a number of people who use those and not ubuntu.com even though they have one. [12:50] ScottK: it's not a matter of "allow"; it's a matter of requiring correct Maintainer: fields from @kubuntu.org maintainers, too [12:50] so it doesn't break, but of course I agree that the regexp shold be fixed [12:50] Ah. [12:52] mvo: damn, same segfault with those guty-updates packages :/ [12:53] pitti: :( I think I found the bug, strange that it wasn't seen earlier [12:53] mvo: oh, wow, that was fast. you rock! [12:54] pitti: it seems like the Priority is NULL for some package on the CD and that makes it crash, I'm trying to figure out which package is causing this now and add some safeguard against this kind of failure [12:56] * pitti runs another test dist-upgrade and toddles off to lunch in the meantime [12:58] err, there is both webkit and webkitkde??? [13:05] pitti: for some reason openssh-blacklist and openssl-blacklist have no priority, this is causing the crash. I'm preparing a sru for python-apt now so that it at least does not crash [13:07] seb128, asac_ : did gnome just copy webkit, and we now have two copies in main? one in qt4/kde4 and one for gnome? [13:08] doko: "webkit" is not a GNOME thing, it's upstream webkit [13:09] but kde doesn't use it? [13:09] its an apple thing :) [13:09] Riddell: ^^^ [13:10] pitti: seems to be only happening with the CD too [13:11] am i allowed to ask a silly bash question here? [13:17] pitti: I filed #253255 for this crash [13:49] slangasek: wondering if you have time for a pam, kerberos, auth-client-config question? [13:50] pitti: I wonder how it happens that the priority did not end up on the CD for those packages. I'm preparing fixes now [13:56] re [13:57] mvo: maybe because the 8.04.1 CD has a special hack to use ssh from hardy-final? we wanted to avoid adding the openssh-blacklist package to the live CD, since it took too much space and isn't necessary for the live environment === asac_ is now known as asac [14:04] Riddell (CC: doko): how come that webkitkde doesn't build-depend on webkit? /me sniffs a code copy [14:05] pitti: afaiu webkitkde is included in kdelibs5-dev [14:05] pitti: would that affect the alternate cd as well? because this is where I see the error [14:06] mvo: oh, right, of course the desktop CD is irrelevant here (I'm using /pool on the DVD as an apt source) [14:07] pitti, doko, https://wiki.ubuntu.com/MainInclusionProcess has a bug: Step 7 is unnecessary, as this part is already done in step 5. [14:08] doko: ah, and webkitkde is just the plugin, not the engine [14:08] doko, what does it mean that you have set my MIR bug 253123 to "In Progress"? Are you currently reviewing it? [14:08] Launchpad bug 253123 in pyusb "Main Inclusion Report for pyusb" [Medium,Fix released] https://launchpad.net/bugs/253123 [14:09] tkamppeter: waiting for an archive-admin to process [14:10] tkamppeter: I just promoted it FYI, and closed the bug [14:13] doko: ISTR that we can demote lesstif2 again? or was this just a dream? [14:13] oh, it is already [14:13] * pitti closes the bug then [14:13] pitti, thanks. [14:14] so, all remaining bugs on https://bugs.edge.launchpad.net/~ubuntu-mir/+subscribedbugs are incomplete [14:14] lesstif can go [14:14] * pitti hugs doko for his reviewing [14:16] Riddell, hal-cups-utils should get installable again in some hours. [14:26] mvo: is bug 253255 actually an issue in update-manager? or only in p-apt? [14:26] Launchpad bug 253255 in update-manager "crash gutsy -> hardy hardy 8.04.1 cdrom upgrade" [High,In progress] https://launchpad.net/bugs/253255 [14:26] pitti: python-apt, but I added a workaround into update-manager too for good measure [14:27] mvo: ah, sweet; do you think we need the workaround in hardy-updates, too? or will the p-apt fix suffice? [14:27] mvo: oh, I see; you mean for the cases where you dist-upgrade from gutsy-final instead of gutsy-updates [14:27] pitti: I think it won't hurt to have it in hardy-updates in updat-emanager too, its a pretty small workaround [14:27] mvo: I keep that VM around for verifying the SRU [14:27] pitti: thanks a lot! [14:27] mvo: I agree [14:28] mvo: thanks to you for the fast fix! [14:28] I still wonder how that slipped during the 8.04.1 qa :( [14:31] pitti: any luck with the localegen hang yet? [14:33] mvo: no, it worked fine in all three scenarios that I tried [14:33] I guess I have to try again with u-m [14:39] does ubuntu have a recovery mode invokable when the system's root partition fills up and writes become impossible? [14:44] erikg: in this case we mount an 1 MB tmpfs to /tmp, so that you can at least log in [14:45] we are still working on a program to do some guided cleaning, though, ATM you have to clean up yourself [14:45] pitti: i've worked out a scheme to run a union mount [14:46] erikg: there is also a recovery-menu that might be useful, however it does not have a "make free space" item yet (also that is probably a good idea to add) [14:46] ... a tmpfs+root overlay [14:46] with aufs (and the uber-buggy unionfs) you can run a script which checks which files are 'deleted' and remove them from the underlying fs [14:46] all software will run provided there is enough ram [14:47] is this roughly what y'all are doing? [14:48] we don't use a unionfs, we just slap a tmpfs on /tmp which is enough to get gdm going [14:48] we'd rather not have any kind of union filesystem involved outside the live CD [14:48] is the concern about code stability? [14:49] once bitten, twice shy [14:49] have you tested aufs? [14:49] * erikg is a two-brick kind've guy [14:49] I don't care :) [14:49] *cough* [14:49] the less code involved when your system is already screwed, the better [14:49] KISS [14:50] we're using aufs on the live CD now [14:50] evening [14:50] cool [14:50] that seems sufficient [14:50] cjwatson: yup. makes sense. [14:51] although, since I'm a pessimist, I assume that it will simply exchange the bugs we knew about for different bugs we haven't worked around yet :P [14:52] we had tested unionfs exhaustively in the live CD for two years, and worked around or fixed the major problems that bit us [14:52] we have tested aufs for one milestone release of intrepid [14:52] not really the same thing :) [14:53] I wonder which interesting interactions it will do with AppArmor this time [14:53] i ran into serious issues using unionfs on top of jffs2. aufs didn't smoke nearly as much. [14:53] I'll let you know in two years [14:54] i'll be happy to hear [14:54] until then, I'll remain sceptical, I think ;) [14:54] i admire your skepticism :) [14:55] if, in two years you find aufs to be trustable, you can use it to implement system recovery at a low enough level that software on the system need not be told what's going on. [14:55] that's my thought. i've been working on the idea for a week or so. [14:56] I don't think you'd want to run it too silently [14:56] you just need a flag of some kind that a recovery console can find on dm startup to inform the user of what's going on and offer recovery solutions. [14:56] after all, if the overlay is a tmpfs, power failures will lose any data that an unwitting user creates [14:56] right. ^^ [14:56] you have to tell them very loudly what's going on. [14:57] it seems like unnecessary complexity when you could just mount a tmpfs and help them to delete unnecessary files, though [14:57] what is the *advantage* of a union filesystem approach? [14:58] seems like you actively wouldn't want the user to be able to run all applications completely smoothly [14:58] because then, well, they might use them ... and start trying to save files etc. "well, it all seems to work, I'll just get this done" [14:58] right [14:59] you're just trading one set of problems for another [14:59] if you go the recovery console approach then there is no specific advantage. [15:00] in that case the union filesystem code paths add a lot of potential complexity. [15:02] the specific advantage of the recovery-mode solution is the amount of code change required to get unaware applications, dms, etc. running on the recovery-mode system is much less. [15:02] because the system presents a familiar face to them. [15:03] that's maybe totally unnecessary [15:04] and as you said potentially confusing. [15:08] Hi asac, can you please take a look at bug 252793 ? [15:08] Launchpad bug 252793 in xulrunner-1.9 "xulrunner ships some images as executables" [Undecided,Confirmed] https://launchpad.net/bugs/252793 === cr3_ is now known as cr3 [15:20] jdstrand: wth is /etc/apparmor/severity.db named that? it's not a *&)*^% db file [15:20] pitti: what does XorgDriverHandler.can_change() do? [15:23] lamont: *shrug* [15:23] meh [15:23] it offends me === jack- is now known as jack [15:24] tseliot: if can_change() returns a string (and not None), it is the rationale why the driver cannot be enabled/disabled [15:24] tseliot: see Handler.can_change() documentation [15:25] tseliot: if current xorg.conf cannot be parsed, we better not modify it any further [15:25] lamont: apparently apparmor uses that file to map events into severity levels when logging [15:25] lamont: this is a nice touch though: [15:25] $ file ./severity.db [15:25] ./severity.db: ASCII Pascal program text [15:26] pah, it doesn't even end with "END." [15:27] jdstrand: yeah, but it means I can't tell my /etc-VCS of any choice to ignore '*.db' [15:27] . o O { IMHO real .db files don't belong into /etc in the first place } [15:27] *cough* postfix *cough* [15:27] pitti: a dist-upgrade just finished for me (in vmware, gutsy->hardy with no hangs via update-manager) [15:27] just fyi [15:28] mvo: with thew new p-apt? rocking! [15:28] pitti: ok, thanks [15:28] yes [15:28] * pitti hugs mvo [15:28] pitti: well, it's not just postfix-- sendmail will do the same thing [15:28] pitti: but no hangs in localegen [15:28] jdstrand: yeah, unfortunately [15:28] but IMHO these belong into /var/cache/ [15:29] I'd agree with that [15:29] or at least /var/lib, if people want to deliberately keep the /etc/ master and .db file inconsistent [15:29] I see your point though-- users aren't suppoed to touch those .db files, so why in /etc? [15:30] /etc/libgda-3.0/sales_test.db [15:30] *blink* [15:30] haha [15:31] great [15:31] pitti: yeah - is historical in origin [15:33] * lamont wonders idly if xkb is needed anywhere outside of, um, X [15:33] (with apologies to the name-pedants from MIT) [15:34] /etc/hddtemp.db: ISO-8859 English text [15:34] sigh [15:38] soren: Hi, do you know why libipq_pic.a got dropped from iptables-dev in the last merge? [15:40] lamont: even then, what's wrong with ignoring all *.db by default? did you actually come across any which you would actively want to manage in VCS? [15:40] lamont: (even then you can still explicitly add it...) [15:41] pitti: depending on the vcs [15:41] but yeah [15:41] I’d suggest managing /etc with e.g. puppet and having puppetmaster’s rules in VCS, not the actual /etc. [15:41] one could also argue that keeping *.db in the vcs is perfectly fine [15:42] ion_: too much work. :-) [15:42] tkamppeter: ping [15:42] lamont: I only add/manage files I actually touched [15:43] pitti: managing everything is wonderful for noticing when (and how) a dist-upgrade trashed something you care about (now that it's wrong^Wdifferent) [15:44] I usually ignore unmodified conffiles, but yeah, for those purposes it's certainly handy [15:44] but too much noise for my taste [15:45] lamont: Initially there’s some work for sure, but if you ever have to replace the box with another that should behave identically, or replicate a certain change to multiple boxes, something like puppet will pay for itself. [15:46] true enough [15:46] ion_: is puppet VCS-centric? [15:46] Nope, you can pick any VCS you want. [15:50] ruby. vomit [15:51] ruby ♥ [15:51] language-du-jour crap [15:51] Not that you ever need to know or care which language puppet’s implemented in when using it. [15:52] AFAIU [15:53] indeed [15:57]