=== slank is now known as slank_away === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ [02:10] infinity, https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/+merge/146760 [02:10] that is tested now. [02:11] and i'd like it pulled. [02:11] tested on actual hardware (that takes 3 minutes to boot) [02:11] now i go to bed. [02:11] smoser: Heh. Cool. Thanks. === Ursinha_ is now known as Ursinha === rsalveti_ is now known as rsalveti === Jacky_ is now known as jackyalcine === BruceMa is now known as Bruce_afk === jackyalcine is now known as Jacky_ [06:56] Good morning === amitk is now known as amitk-afk [07:03] hey pitti [07:06] pitti: I was writing autopkgtest cases for ncurses. I have manageed to cover all library functoins relating to output, any idea how do I test input functions? Is there any idea except redirecting input? [07:06] s/manageed/managed/ , s/functoins/functions/ [07:07] vibhav: hey [07:07] vibhav: oh, very good! That almost sounds like upstream tests already [07:07] vibhav: does upstream have a test suite which we could run in autopkgtest? [07:08] Taking a look [07:08] vibhav: I haven't tried this, but perhaps one could run it under Xvfb and inject keypresses through xtest [07:09] pitti: ah, yes there are test suites [07:10] pitti: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/ncurses/raring/files/head:/test/ [07:10] vibhav: if they run during the build, then the "detailled" functionality doesn't need to be tested again in autopkgtest [07:11] vibhav: for autopkgtest it's more important to test "is the library working at all", and "can I build something against it which works", such as most of our compile/link/run tests that we have in glib, gtk, and many others [07:12] pitti: So Ill assert() some basic functions for autopkgtest. Thaat should do it, right? [07:13] vibhav: it seems the upstream tests don't run during package build; fixing that would also help, but if they are too broken then maybe they can at least serve as an inspiration on how to run input tests [07:13] Basically, the aim is to see if the headers and pkg-config and alright, they shouldnt be that comprehensive too [07:13] vibhav: or maybe a subset of them will work [07:13] vibhav: right; that's what I meant with compile/link/run tests [07:14] vibhav: such as http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/glib2.0/raring/view/head:/debian/tests/build [07:15] pitti: I was following this :) [07:15] smoser: So, I'm going to go with sotfdep in raring, since it works right with kmod, and it feels like the Right Way to do this. For the SRUs, of course, we can go the more hackish route. [07:16] smoser: I'm also not entirely convinced we actually care about loading the _ib driver, and might only care about _en... === Jacky_ is now known as jackyalcine [07:20] siretart: do you have a minute for dput stuff? [07:23] siretart: any reason not to add the upstream git to https://launchpad.net/dput/trunk ? [07:27] pitti: As the tests will be compiled by gcc, should I use function attributes too? (They _might_ optimize the tests) [07:27] vibhav: do you think that will make them less likely to succeed? I. e. cover more corner cases? [07:28] pitti: nope [07:29] All functions are pure, so __attribute__((pure)) and stuff [07:29] I don't know what this is doing, but it doesn't seem to me that this is something we ought to put into a simple compile test? [07:29] ah, ok [07:45] pitti: If you have some time could you have a look at http://paste.ubuntu.com/1619001/ ? If it is right I will make a merge proposal for it. [07:47] vibhav: what does wgetch() read from? [07:47] vibhav: i. e. how do you emulate pressing 'a' there? [07:48] vibhav: can you just call this with "echo a | ./test-curses ? [07:48] good morning [07:49] does anyone have any comments/input on the last comment in bug 1113529? [07:49] bug 1113529 in Ubuntu "[sponsor request]add into archive for UbuntuKylin" [Wishlist,Confirmed] https://launchpad.net/bugs/1113529 [07:52] pitti: Yes, it works! [07:52] * vibhav cheers [07:52] vibhav: with echo, or does that function not actually read from the console? [07:53] pitti: wgetch() also works without echo (when I enter myself) [07:54] So, yes it works from the console [07:59] vibhav: ok, so the test would use echo, so that it runs noninteractively [07:59] vibhav: congrats! [08:01] pitti: thanks [08:02] Okay, Ill branch ncurses and request a merge [08:05] pitti: Any other suggesstions? [08:05] vibhav: if you take glib's debian/tests/ script as an example, please add -Wall -Werror for extra pickiness [08:06] vibhav: I did that for a few packages already, but not for glib yet [08:11] pitti: Should I add "ncurses" to depends in debian/tests/control? [08:12] vibhav: I rather think you'd need a -dev, and build-essential? [08:13] pitti: Okay so, will it be libncurses5-dev, build-essential, pkg-config [08:13] that ought to suffice [08:14] perfect === smb` is now known as smb [08:27] vibhav, hey, I reviewed your patch, the test script is fine, but the test of es_str2cstr fails === tkamppeter_ is now known as tkamppeter [08:33] jibel: Thans for the notice, I will hve a look soon [08:37] pitti: done :) https://code.launchpad.net/~vibhavp/ubuntu/raring/ncurses/add-autopkgtest/+merge/147038 === amitk-afk is now known as amitk [08:43] jibel: Uploaded correct diff [08:48] vibhav, it passes, congrats! [08:49] This is a good day [08:49] Everything is working perfectly. [08:54] pitti: I need to go, please inform if there are any more chaanges to be done. [09:13] is there a way to stop sbuild from generating ddeb's? reprepro can't import them.. [09:15] IIRC pkg-create-dbgsym has a config file to disable it (or delete the package completely from your sbuild) [09:16] thanks, I'll check it out [09:27] meh, I'll just add an exit 0 to the script.. [09:29] I just sed -i '/\.ddeb/d' foo.changes if I want to reprepro it [09:37] that would be one way, though I can't see much use for local ddebs anyway :) [09:37] hey everyone [09:37] I was told yo come [09:37] *to come here from #ubuntu-on-air [09:38] depends how often you like to debug stuff [09:38] the ones I build usually have -dbg anyway [09:38] Is anyone working on a service like Contractor or Android Intents? [09:38] http://www.omgubuntu.co.uk/2011/03/contractor-brings-seamless-file-sharing-between-apps-to-the-linux-desktop [09:38] like most of pkg-xorg stuff [09:38] or would it be possible for some collaboration with elementary on Contractor? :) [09:39] tjaalton: Not sure why you wouldn't just remove pkg-create-dbgsym from the relevant build chroot [09:40] tjaalton: It's not build-essential - it's just that mk-sbuild puts it there by default for Ubuntu [09:42] cassidy|Nexus: That looks like it's trivially implementable by the existing .desktop file infrastructure? [09:43] cjwatson: right, best to just remove it then === yofel_ is now known as yofel === emma is now known as em === henrix_ is now known as henrix [09:53] RAOF, not using anything that exists so far. It's not just telling an app to open a fine, but acting upon the data in a way that makes sense in that context [09:54] *file [09:54] cassidy|Nexus: You're basically asking for mime-type handlers; these exist - it's what populates “open with” [09:55] So it's not entirely implemented, but you can pretty easily implement it on top of what we've got. [09:55] RAOF, but I wouldn't want to share a picture to a gallery app, I'd want to share it to my email app or gwibber [09:55] RAOF, it's a very distinct use case [09:56] So annotate the desktop files. [09:56] It's not *that* distinct a use case ☺ [09:56] RAOF, I encourage you to chat with the devs in #elementary-dev about in. [09:56] *it [09:57] Not that I think this is a bad idea at all, just that I don't see why it requires extra infrastructure. [09:57] I'm not a desktop dev myself so I'm probably not doing a very good job of explaining it. :-P [09:58] RAOF, but iirc there was a very specific reason it wasn't done through .desktops... :-/ [09:59] RAOF, either way, it'd be sweet to work together on a standard implementation. I think part of that is how apps that can share data display the sharing menu and whatnot. [10:03] RAOF, some interesting use cases we've already seen devs using it for are like highlighting text in a code editor and then sharing it to pastebin with a single click, uploading videos to online services, and even providing a simple plugin architecture for the file manager (for things like archiving files) [10:04] There's even a "set as wallpaper" contract so any app that is sharing image data can share to that and it sets it as the wallpaper. lot's of really interesting things. [10:10] Yeah, it's kinda interesting. [10:54] hallyn: re spice in experimental - i pushed it just to the repository, not yet to any archive. I had no chance to reply to your email or to do anything else with spice, was very busy a few last days. As for uploading, I hoped that Liang will reply -- it looks like he will not... [11:26] barry: do you know whats up with https://bugs.launchpad.net/subunit/+bug/1025392 ? [11:26] Ubuntu bug 1025392 in subunit "FTBFS with Python 3.3: tests fail" [High,Triaged] [11:33] vibhav: splendid, thanks! I'm in a train, too little bw to sponsor; but please feel free to add me as a reviewer, then I'll get mail for it [11:33] * xnox recalls fixing something like that [11:34] lifeless: i had a branch for that indeed. [11:34] lifeless: https://code.launchpad.net/~xnox/subunit/hash-ordering/+merge/131732 ?! [11:35] lifeless: jelmer did upload this to experimental https://bazaar.launchpad.net/~ubuntu-branches/debian/experimental/subunit/experimental/revision/13#debian/patches/fix-ftbfs-python3.3.patch [11:35] xnox: the merge proposal for it got cancelled by you AFAICT ? [11:35] xnox: so was waiting for an updated version ... [11:35] I think I did push an updated revision later. [11:36] Also I uploaded twice into https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/subunit/raring-proposed [11:36] (revisions 16 & 17) [11:36] xnox: [not to mention that the original change wasn't suitable for production use] [11:36] lifeless: what do you mean by not suitable for production use? [11:36] * xnox was just doing bulk porting to python3. [11:36] You mean shebang changes? [11:37] xnox: I said it in the review; the code was correct, the issue was only in the test suite. [11:37] xnox: making the actual code slower to make tests pass is inappropriate [11:38] ah, ok. [11:40] the serialiser is in the critical path for speed [11:40] its not as fast as it probably needs to be already, so I'm a tad sensitive. [11:40] ok. I'll rework it. But i have a few urgent things to push out today. [11:41] no rush [11:41] I just released 0.0.10, which doesn't have that patch. [11:41] but fixes some more python 3 issues [11:43] cool [11:44] (subtle ones that you can only detect with stuff running on stop of subunit :)) === _salem is now known as salem_ === doko_ is now known as doko [12:04] when importing package from debian, should something be changed in d/control if the rest is okay? Maybe, if the said pkg is maintained by other people, ubuntu maintainer should be added to Uploaders? And, how about revision numbers? === MacSlow is now known as MacSlow|lunch [12:39] mjt: if nothing needs changing (like an additional patch) the the package is taken from Debian as-is [12:40] mjt: if you are uploading into ubuntu ahead of debian's -1 : version should be -0ubuntu1. And maintainer should be changed using update-maintainer utility from ubuntu-dev-tools (available in debian as well) [12:40] mjt: and target raring [12:48] ok, thanks! [12:48] (i'm not uploading anything to ubuntu, i'm just making life for some ubuntu'ers easier :) === jackyalcine is now known as Jacky_ === amitk is now known as amitk-afk === MacSlow|lunch is now known as MacSlow [13:18] =) === slank_away is now known as slank === Jacky_ is now known as jackyalcine [14:20] mjt: oh, ok, thanks [14:28] mjt: do you expect to push it to archive this week? If not I'll go ahead and merge the current debian-experimental version with the cleanups on top [14:33] hm, the raring netboot image (which worked for me two weeks ago) is failing to boot [14:33] hi lifeless, xnox all sorted out? [14:33] hallyn: i just replied to your email. If Liang wont reply tomorrow I'll just push it [14:33] mjt: awesome, thanks, then i'll wait [14:33] hallyn: together with the configure fix [14:34] barry: yeah. mostly agreed what I should do next. [14:34] xnox: excellent! === amitk-afk is now known as amitk [14:41] hallyn: failing how? [14:54] hallyn: oh, yeah, I think I heard there was some syslinux breakage, could be that [14:55] hallyn: it's been reported in Debian too ... [14:55] oh my god, enormous thread on debian-ctte about it [14:57] oh yes. === jono is now known as Guest81910 === Quintasan_ is now known as Quintasan [15:02] well, I can cherry-pick the reported patches to d-i/debian-cd at least and see if they help [15:08] cjwatson: yeah, it's right at boot failing to find ldlinux32.c32 [15:08] sounds like it's covered then, thanks :) [15:08] * hallyn goes to look for that m-l [15:08] oh. heh. === security is now known as megha [15:11] hey guys [15:11] mhall119: http://libqzeitgeist.geekyogre.com/ :D [15:11] booom [15:20] Hey seiflotfy, long time no see [15:20] hey mpt [15:20] mpt: how are you [15:20] ? [15:21] seiflotfy, splendid. Have you heard from Manish Sinha lately? [15:21] yeah, he was working on the activity log manager [15:21] he has exams atm [15:21] mpt i am willing to take a look after the weekend [15:21] i am busy releasing zeitgeist 1.0 [15:21] Ooh, congrats [15:22] thanks [15:22] much faster, directreading (no dbus roundtrips) and gobject introspection support [15:23] Will that make the Dash faster? :-) [15:23] yep [15:23] much faster [15:23] dash is mostly slow due to ubuntu1 spamming it [15:24] mpt if you want to make it faster, just delete the DB and make it rebuild itself [15:24] :D [15:24] because old u1 entries kinda messed things up big time [15:25] ooh, how do I do that [15:26] ok [15:26] first [15:26] in a temrinal [15:26] zeitgeist-daemon --replace [15:26] then kill it [15:27] the mv ~/mpt/.local/share/zeitgeist ~/mpt/.local/share/zeitgeist-backup [15:27] then in a terminal [15:27] zeitgeist-daemon --replace [15:28] woo-hah [15:28] Now it opens in less than two seconds! [15:29] mpt: its still busy [15:29] give it time [15:29] it gets quicker [15:29] :d [15:29] zeitgeist is busy building the index again [15:29] takes 60 seconds or so [15:29] seiflotfy: http://zeitgeist-project.com/ - you need to update that logo. [15:29] ok [15:29] jpds: i know, but i am lacking resources [15:29] right now we are 4 ppl doing the zeitgeist besides our real jobs [15:30] mpt: run zeitgeist in a terminal [15:30] zeitgeist-daemon --replace [15:30] then open the dash [15:30] seiflotfy, it is [15:30] and show me the output on the terminal [15:30] mpt: ^ [15:31] Hm, the Terminal is stuck behind a HUD that won't close [15:31] tseliot, hey there, are you around? [15:31] oh man [15:31] "Thanks HUD! ... Thud!" [15:31] marga: yep [15:32] tseliot, I work with Michael Wisheu, he sent you a mail regarding the regeneration of initramfs images in nvidia's postinst [15:32] seiflotfy: http://www.canonical.com/sites/default/themes/canonical10/images/footer_logo.png [15:32] jpds: on it later today [15:33] tseliot, my idea was to add a low priority debconf question that asks if the user wants the current (default) behaviour, or wants all kernels [15:33] marga: right, I haven't replied to him yet [15:33] tseliot, if you think this approach is fine, I could prepare the patch for you. [15:34] marga: but given the headaches we've had with debconf in the past I'd rather not do that. Maybe it's simpler if I check the existence of a file in /etc such as /etc/dkms_build_all_kernels, or something like that [15:34] tseliot, hm, that had been my first thought, but it's rather ugly that you have to have the package there before installing the package [15:35] What were the debconf headaches of the past? [15:35] marga: some serious problems with the nvidia-common package causing problems during dist-upgrades, etc. [15:36] tseliot, hm, knowing what the problems actually were might be helpful in not falling into the same mistakes. [15:37] what's the question here? [15:37] marga: and this has to work smoothly also with our drivers manager app, so we don't want users to have to answer questions during the installation [15:37] But, in any case, if you prefer dropping a file somewhere, I can try to find a place to drop a file and then send you the patch. [15:38] xnox, nvidia-current only regenerates the initramfs for the running kernel and the newest kernel. This might be problematic in cases where the user wants to run an older kernel [15:39] So, we want to _optionally_ regenerate all images. [15:39] seiflotfy, http://paste.ubuntu.com/1621263/ [15:40] mpt now keep it running and open dash [15:40] then tell me what the terminal says [15:40] marga: so yes, advanced users (or maybe only developers) could do something like "touch /etc/dkms_build_all_kernels" and then install the package [15:41] seiflotfy, no further output. [15:42] Alright. I see this as less than optimal, because you need to do that before the package is installed. And the package is installed at installation time in the machine. It's easier to pre-seed than to pre-write a file. But, we'll manage. [15:42] mpt: my bad [15:42] zeitgeist-daemon --replace --log-level=debug [15:42] Do you want me to send you the patch? [15:43] marga: or you can touch the file and do dpkg-reconfigure nvidia-310 (or whatever) [15:43] marga: aah, I see your problem [15:44] mpt: what does it spit [15:44] marga: patches are always welcome [15:45] mpt: ? [15:46] seiflotfy, http://paste.ubuntu.com/1621279/ [15:47] so when you open dash it does not contact zeitgeist :D [15:47] but the times are very fast [15:47] [15:45:11.377989 DEBUG] ext-fts.vala:186: Got 13[/398] results from indexer (in 0.229272 seconds) [15:45:11.378658 DEBUG] ext-fts.vala:186: Got 10[/54] results from indexer (in 0.083086 seconds) [15:45:11.713494 DEBUG] ext-fts.vala:186: Got 0[/0] results from indexer (in 0.017680 seconds) [15:45:17.236664 DEBUG] zeitgeist-daemon.vala:181: Zeitgeist.Daemon.find_events executed in 0.009232 seconds [15:45:17.240314 DEBUG] zeitgeist-daemon.vala:181: Zeitge [15:47] woops sorry [15:48] mpt: the first search is slow iwth 0.2 second [15:48] but then all under 0.1 seconds [15:48] do you notice a difference [15:50] seiflotfy, yes. :-) It now has what, in the early days of Mozilla, we used to call "teh snappy" [15:51] my DB is HUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUGE [15:51] mpt: but with the next release it will be faster [15:51] :DS [15:52] http://seilo.geekyogre.com/2013/01/zeitgeist-1-0-almost-there-call-for-hackers/ [15:58] hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories? [16:09] kirkland, intriguing changelog entry ;-) [16:12] dholbach: which one? [16:12] * UNRELEASED [16:12] ^ that one :) [16:12] https://lists.ubuntu.com/archives/raring-changes/2013-February/005725.html [16:12] :) [16:13] wtf [16:13] dholbach: stgraber: thanks... let me see what went wrong with my release scripts.... [16:14] don't worry - it might feed some rumour mill somewhere ;-) [16:14] dholbach: I'm your Huckleberry! [16:14] seiflotfy, maybe the OS upgrade script should rebuild the zeitgeist database? [16:15] seiflotfy, though I guess that doesn't really work if it's user-specific [16:16] Maybe zeitgeist updates set a RebuildIfLastRebuildWasEarlierThan flag, and looks at it on each login [16:16] or something [16:16] mpt: just delete all u1 entries [16:17] and things are back to normal [16:17] :P [16:17] xnox: sorry to bother you with that, but do we have any idea of how long it can take for the lvm2 SRU to get to -proposed ? [16:18] xnox: Bug #833368 [16:18] bug 833368 in lvm2 (Ubuntu Precise) "clustered lvm commands fail with "activation/monitoring=0 is incompatible with clustered Volume Group" error" [High,In progress] https://launchpad.net/bugs/833368 [16:21] dholbach: stgraber: ah, I missed a debcommit in my upstream tree; thanks; I'll add a bzr stat check in my release scripts [16:22] caribou: not until after 12.04.2 is released. If it's urgent to get into 12.04.2 (which I thought it isn't since clvm package is not on the server cds) you can raised it with cjwatson / release team [16:22] xnox: ok, thanks for the info [16:23] caribou: yeah, currently 12.04.2 is in preparation for candidate images. [16:25] I've got an FTBFS in a PPA builder that I can't reproduce using sbuild. I think it's because of an extra build-depend that's being pulled in for some reason, but I can't figure out why (ruby1.9.1 in addition to ruby1.8). Is there a way I can get sbuild to do exactly what the PPA builder is doing for build dependency resolution please? And oddly, the last build I did didn't change the build dependencies but worked. [16:25] * rbasak is confused [16:26] rbasak: what's the package? [16:26] cjwatson: I'm experimenting with puppet 3.1 out of debian git vcs [16:26] success: https://launchpadlibrarian.net/130544489/buildlog_ubuntu-raring-i386.puppet_3.1.0-0ubuntu1~ppa1_UPLOADING.txt.gz [16:26] failed: https://launchpad.net/~racb/+archive/experimental/+build/4279299 [16:27] failed: https://launchpad.net/~racb/+archive/experimental/+build/4279299/+files/buildlog_ubuntu-raring-i386.puppet_3.1.0-0ubuntu1%7Eppa2_FAILEDTOBUILD.txt.gz [16:27] rbasak: So two things: (a) --resolve-alternatives (generally makes sbuild operate more like the LP one) (b) since puppet is in main, configure your schroot to have only main sources [16:27] Haven't analysed this particular case but that should bring it closer [16:28] OK, I'll try that, thanks. What confuses me is that two subsequent builds on the PPA failed, but I only changed control fields that shouldn't matter. [16:28] Sorry, that the first build on the PPA succeeded and the second failed [16:28] Dunno, could be changes elsewhere in the archive [16:28] OK [16:29] I'm partially guessing :) [16:37] tjaalton: ping [16:39] So removing !main didn't work (and then I noticed that the PPA FTBFS log has universe et al. enabled), and nor did --resolve-alternatives. I'll keep looking [16:39] Riddell: pong [16:40] tjaalton: xfixes seems to cause breakage [16:40] http://paste.kde.org/666956/ [16:40] tjaalton: sorry xinput rather [16:40] tjaalton: clashing variable name with xfixes [16:40] huh [16:41] ok then [16:41] tjaalton: is there an upstream to moan to? [16:41] my bad, should've pushed it to the staging ppa.. [16:41] no, it's conflicting with our old implementation aiui [16:42] which is shipped by the xserver [16:44] tjaalton: with an old xfixes? [16:44] Riddell: right that's where it's from.. [16:46] Riddell: ok, I'll revert it from libxi for now === jackyalcine is now known as Jacky_ [16:50] tjaalton: I'll also upload kde-workspace without the patch that uses xfixes for now since upstream is unsure if it's a good idea [16:57] hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories? [16:59] Riddell: uploaded -0u2 which reverts the upstream code for now [17:00] thanks tjaalton [17:00] tjaalton: will you also file a bug upstream, or should I? [17:02] Riddell: no upstream is fine, we'll be dropping our own implementation of pointer barrier events together with xserver 1.14 before feature freeze [17:04] Riddell: so kde has added support for our own implementation of it (like unity) you'd need to port it [17:04] +if [17:04] tjaalton: own implementation of what? [17:05] Riddell: once the build works with -0u2 I'll upload -0u3 to canonical-x/x-staging ppa which restores the upstream stuff [17:05] Riddell: pointer barrier events [17:05] tjaalton: when I tried kubuntu on a nexus recently I couldn't interact with plasma widgets or anything QML so we have something messed up [17:05] no this is for dualhead, resistance for the pointer when crossing screen barriers === slank is now known as wedgwood [17:06] so if you don't have versioned build-deps against our libxfixes then you're safe :) [17:07] it's just that including both new and old headers cause issues, like you pointed out.. [17:10] infinity, ping. [17:26] smoser: Pong, ish. [17:27] just asking about 115710 (kmod mellanox) [17:27] smoser: Yeah, I nick highlighted you overnight, I think. [17:27] shoot. [17:28] smoser: Started off by saying I thought softdep was the cleaner way to go in raring, there's no reason to make it be stuck with the same hack as older releases. [17:28] infinity, i think the issue is present on raring also [17:28] i can veryify that though. [17:28] smoser: But then I got to wondering if we really need the automloading magic to load the _ib module too. Is that a behaviour people will expect/want? [17:28] the update-initramfs... i think thats where i was testing. [17:29] smoser: It works fine in raring. [17:29] really? [17:29] Yeah. [17:30] Given that kmod and module-init-tools share absolutely zero code, the behaviour changing isn't shocking. [17:30] Not that m-i-t is "wrong" for noting the loop (mlx4_en depends on mlx4_core, after all). [17:30] tseliot, in the end, no changes will be needed. There already is a flag in the update-initramfs.conf file that allows to regenerate for all kernels. [17:30] tseliot, thanks for your time :) [17:31] marga: you'll still have to rebuild the modules manually [17:31] infinity, ok. so you're right. it seems cleaner with the post in raring. [17:31] and i just tested no crying there. [17:32] so lets do that. [17:32] so, then, reguarding the _ib module... [17:32] i just think if we believe that _en should be loaded, then why would we not load _ib ? [17:32] Note that the _ib module hack doesn't actually work for you from initrds anyway, since infiniband modules aren't included in initrds by default. [17:33] it seems arbitrary to decide that ethernet usage is expected but infiniband is not. [17:33] (they get pulled in with the soft-dep) [17:33] They sure don't. [17:33] http://paste.ubuntu.com/1621558/ [17:34] Is that with the install or softdep setup? [17:34] I didn't get that behaviour on either raring or precise when I tested. [17:35] softdep [17:35] And what release? [17:36] i just re-built that initramfs with no soft-dep and its gone. [17:36] that is raring, but i'm running quantal kernel [17:36] because of hardware issues. [17:36] Oh, confusing. [17:36] well if you want to fix compiz so it doesn't hang after 3 minutes of use, i'd love to use a 3.8 kernel [17:36] So, I intentionally deleted the _ib module while testing a different thing, let me restore that and see. :P [17:37] But it also would pull in the whole _ib stack into the initrd too. [17:37] it would, yes. [17:37] is there a reason we wouldn't want that? [17:38] i wondered about this too, and thought maybe we should not do _ib [17:38] Well, I'm not sure how all of this is generally used, to be honest. [17:38] but it just seems random to decide that "of course you want ethernet drivers for your hardware, but maybe not infiniband" [17:39] Isn't infiniband something people have to consciously configure anyway? We don't have any out-of-the-box It Just Works IB stuff, do we? [17:39] "if you want infiniband, then manual action is required" [17:39] i dont know. [17:39] Yeah, me neither. :P [17:44] infinity, well., you want to ditch the _ib ? [17:45] smoser: I'm thinking no one will notice if we do. [17:45] ok. [17:45] so soft-dep for raring [17:45] and no _ib loading [17:45] smoser: And it gets rid of the minor initramfs-tools/modprobe interaction issue for the backport. :P [17:46] ? [17:46] Well, for precise, where the _ib module doesn't end up in the initrd, but then modprobe still tries to install it. [17:46] Anyhow. I think it's sane to keep it small, and _en is small. [17:50] infinity, so what do you want from me? [17:50] i'll change my non-raring branches [17:50] and comment in the bug to this decision [17:50] but you pick up raring ? [17:50] smoser: Yeahp, that works for me. [17:51] smoser: Well, if you want upload credit, you can give me a branch/diff for raring too. [17:51] smoser: (My name doesn't need to be in the changelog to keep TIL for merges, I just need to sponsor it :P) [17:51] i'l update raring === megha is now known as baba === henrix is now known as henrix_ === henrix_ is now known as henrix === baba is now known as gia === gia is now known as baba [18:13] infinity, ok. we're good at https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/+merge/146760 [18:27] marga, I rejected the g-c-c update for precise that I sponsored earlier this week, don't worry about it if you get a rejected email. I'm going to upload, I had to do a small update to update the version logo to stop saying 12.04.1 in preparation of 12.04.2 [18:44] alexlist: now I'm around. what's up about dput? [18:44] seb128: hi there. what about https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/859600 ? slangasek said in IRC at least that my patch looked sane to him. :) [18:44] Ubuntu bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] [18:44] slangasek, ^ want to sponsor it? ;-) [18:45] or I can dput but I will deny any responsability if it has issues ;-) [18:45] alexlist: oh, I see. it seems that I'm the 'owner' of that project. I don't even remember when I have touched that entry the last time [18:45] any takers? [18:49] hi, what tool is used to create the final ubuntu iso? [19:04] hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories? [19:09] luist: did you read https://help.ubuntu.com/community/LiveCDCustomization ? [19:13] barry: yeah thanks [19:20] infinity: hey. i'm looking at an eglibc issue. Is there a wiki on bisecting between svn commits? Make && make install looks dangerous [19:24] arges: do that, but in an lxc container? =) [19:24]