=== akgraner` is now known as akgraner === tilgovi_ is now known as tilgovi === asac_ is now known as asac === wgrant_ is now known as wgrant === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === htorque_ is now known as htorque [06:21] slangasek: BTW, aptitude seems to fail miserably at multiarch deps [06:22] micahg: oh? [06:22] yeah [06:24] oh, maybe not, I'm confused now...well, I have the old e-d-s-common installed [06:25] before I installed all the i386 libs for flashplugin, it used to be able to resolve the dependencies, now it wants to remove a lot of stuff [06:27] hmm [06:27] how are you invoking aptitude? interactively, or commandline? [06:28] interactive [06:44] well, I certainly get a lot of error output whenever I try to change the state of a package [06:57] slangasek: http://wedontsleep.org/~steven/libao_1.1.0-2.debdiff [06:59] StevenK: LGTM; mark libao4 Multi-Arch: same, and send it to Debian? [06:59] slangasek: But what about the -dev changes? [06:59] what about them? [07:00] I had to move where the .a files are and so on, is that a problem? [07:00] I'm also a little concern about the plugins [07:00] nope; already allowed for by policy, and the standard way to go about it - it does mean that it may break reverse-build-depends, though, so you shouldn't upload to oneiric without an FFe [07:01] what worries you about the plugins? [07:01] slangasek: That the path changed [07:01] well, I was assuming you had tested that the library still finds its plugins ;) [07:02] slangasek: I haven't yet, I wanted to check that you thought the diff was sensible first [07:02] yep [07:03] slangasek: Only libao4 gets Multi-Arch: , nothing else does? [07:04] well, libao-common should be made Multi-Arch: foreign (and probably also Architecture: all) [07:04] libao-dbg can probably be marked M-A: same [07:05] Yes, it's strange that -common isn't. [07:05] and libao-dev, it depends on whether there are architecture-dependent headers in there [07:05] It contains a conffile and a manual page only for pitys sake [07:06] looks like the headers are arch-neutral, so you can mark libao-dev M-A: same as well [07:06] that will make cross-building nicer :) [07:07] btw, as long as you're in here you might as well drop the .la files from the package [07:07] nothing in the archive uses them, and if something did, that something would be broken by them moving directory [07:07] Even though it installs usr/include/ao/ao.h and so on? [07:07] yep - as long as the files are the same across all archs, they get refcounted [07:08] Ahh, but dpkg won't complain like it usually does when two packages contains the same file [07:11] right, multiarch handles file overlapping differently [07:11] since /usr/share/doc/*/changelog.Debian.gz exists in every package, for example [07:12] slangasek: Good to know :-) [07:12] Now, how to test plugin loading ... === Rincewind is now known as WizRincewind === Quintasan_ is now known as Quintasan === tkamppeter_ is now known as tkamppeter [10:48] hi, I have another problem with Bug #193507 [10:48] Launchpad bug 193507 in linux (Ubuntu) "compile fails without BLK_DEV_INITRD" [Medium,Fix released] https://launchpad.net/bugs/193507 [10:49] I got this error with BLK_DEV_INITRD enabled [10:52] hello everybody [10:52] anybody can help me [10:52] with lamp configuration? [10:52] no developer active here now [10:52] I am waiting too [10:52] support is in #ubuntu [10:53] ok thank u! [10:53] for kernel problems too? [10:53] no [10:53] okay [10:53] then can you help me [10:53] i am tryng to install [10:53] mysql on dropbox [10:54] but i got a problem with phpmyadmin [10:54] * Hobbsee has no idea on that kernel issue [10:54] damn... [10:54] no sorry [11:20] any kernel professional here? [11:23] irgendwer4711: There is a #ubuntu-kernel I think specifically for kernel issues - but always ask the question rather than asking if anyone is here! [11:24] I asked already ;-) [11:24] I have another problem with Bug #193507 ; this problem occures with BLK_DEV_INITRD enabled too [11:24] Launchpad bug 193507 in linux (Ubuntu) "compile fails without BLK_DEV_INITRD" [Medium,Fix released] https://launchpad.net/bugs/193507 [11:25] hmm ancient bug [11:26] I am using LTS ubuntu [11:26] irgendwer4711: Lucid or Hardy ? [11:26] hardy [11:27] irgendwer4711: OK, so you're rebuilding your kernel just without BLK_DEV_INITRD and you get the same error? [11:27] no with BLK_DEV_INITRD [11:28] ok, so what are you changing and what exactly is the error? [11:28] (.init.text+0x82e): undefined reference to `early_populate_rootfs' [11:29] and which version source are you using exactly? [11:29] 2.6.24.6 I think [11:30] can you check ? That fix in that bug went in 2.6.25-10.16 [11:31] wich file [11:31] dpkg says "2.6.24.29.31" [11:32] irgendwer4711: sounds promising [11:32] ok [11:32] can you pastebin your config? [11:33] I try a diff to last working conf [11:33] yeh [11:36] hm how to print only diffrent with diff ^^ [11:37] diff oldfile newfile [11:37] I mean with wide format [11:38] I think that's sdiff - but can't remember how to get it to just show changes [11:38] done [11:39] http://pastebin.com/2KYn6DR3 [11:40] I tried to activate some energy savings options und disabled unused drivers [11:41] irgendwer4711: Without having a dig in the source I'd suggest putting the CONFIG_ACPI_CUSTOM_DSDT_INITRD back the way it was? [11:41] but I dont have a dsdt patch file [11:42] * penguin42 doesn't know much about DSDT [11:42] there is a file in initrd that patches the acpi tables [11:43] but not for mine acpi [11:43] but I can enable this an try [11:47] irgendwer4711: Yeh looking at the Ubuntu diff the early_populate_rootfs is ifdef'd on CONFIG_ACPI_CUSTOM_DSDT_INITRD but the ifdef in init/main.c is ifdef'd on CONFIG_BLK_DEV_INITRD [11:48] irgendwer4711: If you've not got the custom dsdt initrd just comment out the call in init/main.c somewhere around line 650 [11:48] I do a new kernel make now [11:49] a missing dsdt patch file is not a problem, just a short message in dmesg [11:49] irgendwer4711: But yeh it does look like it's using the wrong ifdef - I don't know the history of the older version where bug 193507 was fixed whether the ifdef changed from there [11:49] Launchpad bug 193507 in linux (Ubuntu) "compile fails without BLK_DEV_INITRD" [Medium,Fix released] https://launchpad.net/bugs/193507 [11:51] wait to end of kernel make [11:56] okay its donw [11:56] no error now [11:56] good [11:56] thank you [11:56] bye [11:57] bah, I was going to tell him to open a new bug === abhinav_ is now known as abhinav- [13:00] Hello. To prevent all packages from modifying /etc/example, do I do "dpkg-divert /etc/example --rename /dev/null" or is there some more elegant way? [13:21] Alternatively, how can I prevent any package from writing to /etc/example [13:28] natschil: create a dummy package with a random name containing this file? [13:29] what about dpkg-divert --divert /etc/example --rename /tmp/some_random_file_name ? [14:23] natschil: 'chattr +i /etc/example' would cause any attempt to write to that file to file [14:23] er, to fail [14:24] personally I would be hesitant about trying to use dpkg-divert for that because at least historically it has had odd interactions with dpkg conffiles and it doesn't do anything useful for maintainer-script-managed configuration files [14:31] ScottK: I may be able to help with k3b in the not too distant future, if somebody else can test the result; I'll queue it up [15:07] cjwatson: let's say im installing something that wants to change /etc/example. Will that still fail? [15:10] natschil: I'm not sure how to respond except by repeating what I said above [15:11] cjwatson: ok thanks. I think I will use dpkg-divert instead and hope for the best :/ [15:11] well, I can repeat the fact that I do not recommend that [15:11] chattr +i will cause *any* attempt to write to that file to fail [15:12] dpkg-divert will arrange for a very limited subset of writes to be redirected elsewhere, which doesn't cover all the things packages do with files in /etc, and which I suspect will have crazy problems even if it does sometimes work [15:12] the only advantage of dpkg-divert here is that it would arrange for the package to install successfully anyway [15:13] (maybe) [15:17] cjwatson: I should be able to test it. [15:17] Help would be much appreciated. [15:19] most of them aren't too hard once you get the patterns. xvidcap is stubbornly segfaulting right now ... [15:27] Laney found the mono commit which breaks on some (not all) i386 buildds === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk [17:04] lamont: [ -x /usr/bin/dh_apport ] maybe ? [17:05] lamont: for the build-dep we can do an | to make it optional, right? === phantomcircuit is now known as C4SHM0N3Y [17:53] cjwatson: for what it's worth, i used diversions heavily when i was at mit, and i think we whined enough that we were able to get the bugs with diversions+conffiles ironed out [17:57] broder: ah, that's something at least === abhinav_ is now known as abhinav- === Testy is now known as JasonO === JasonO is now known as Guest78948 [18:45] ScottK: give http://paste.ubuntu.com/671830/ a try? [18:45] (please try not to laugh at my rusty C++) [20:21] hmm, I wonder if my xvidcap crash is actually a libav bug [20:24] looks like its MAP_ANON detection fell over in 0.7 or so [20:25] * cjwatson tries to construct a test that isn't "build xvidcap with this dodgy patch" === jcastro_ is now known as jcastro === Quintasan_ is now known as Quintasan === em is now known as botten_emma === botten_emma is now known as boten_emma === boten_emma is now known as em === C4SHM0N3Y is now known as phantomcircuit === _LibertyZero is now known as LibertyZero === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === yofel_ is now known as yofel