[02:10] <smoser> infinity, https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/+merge/146760
[02:10] <smoser> that is tested now.
[02:11] <smoser> and i'd like it pulled.
[02:11] <smoser> tested on actual hardware (that takes 3 minutes to boot)
[02:11] <smoser> now i go to bed.
[02:11] <infinity> smoser: Heh.  Cool.  Thanks.
[06:56] <pitti> Good morning
[07:03] <vibhav> hey pitti
[07:06] <vibhav> 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] <vibhav> s/manageed/managed/ , s/functoins/functions/
[07:07] <pitti> vibhav: hey
[07:07] <pitti> vibhav: oh, very good! That almost sounds like upstream tests already
[07:07] <pitti> vibhav: does upstream have a test suite which we could run in autopkgtest?
[07:08] <vibhav> Taking a look
[07:08] <pitti> vibhav: I haven't tried this, but perhaps one could run it under Xvfb and inject keypresses through xtest
[07:09] <vibhav> pitti: ah, yes there are test suites
[07:10] <vibhav> pitti: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/ncurses/raring/files/head:/test/
[07:10] <pitti> vibhav: if they run during the build, then the "detailled" functionality doesn't need to be tested again in autopkgtest
[07:11] <pitti> 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] <vibhav> pitti: So Ill assert() some basic functions for autopkgtest. Thaat should do it, right?
[07:13] <pitti> 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] <vibhav> Basically, the aim is to see if the headers and pkg-config and alright, they shouldnt be that comprehensive too
[07:13] <pitti> vibhav: or maybe a subset of them will work
[07:13] <pitti> vibhav: right; that's what I meant with compile/link/run tests
[07:14] <pitti> vibhav: such as http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/glib2.0/raring/view/head:/debian/tests/build
[07:15] <vibhav> pitti: I was following this :)
[07:15] <infinity> 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] <infinity> smoser: I'm also not entirely convinced we actually care about loading the _ib driver, and might only care about _en...
[07:20] <alexlist> siretart: do you have a minute for dput stuff?
[07:23] <alexlist> siretart: any reason not to add the upstream git to https://launchpad.net/dput/trunk ?
[07:27] <vibhav> pitti: As the tests will be compiled by gcc, should I use function attributes too? (They _might_ optimize the tests)
[07:27] <pitti> vibhav: do you think that will make them less likely to succeed? I. e. cover more corner cases?
[07:28] <vibhav> pitti: nope
[07:29] <vibhav> All functions are pure, so __attribute__((pure)) and stuff
[07:29] <pitti> 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] <vibhav> ah, ok
[07:45] <vibhav> 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] <pitti> vibhav: what does wgetch() read from?
[07:47] <pitti> vibhav: i. e. how do you emulate pressing 'a' there?
[07:48] <pitti> vibhav: can you just call this with "echo a | ./test-curses ?
[07:48] <dholbach> good morning
[07:49] <dholbach> does anyone have any comments/input on the last comment in bug 1113529?
[07:52] <vibhav> pitti: Yes, it works!
[07:52]  * vibhav cheers
[07:52] <pitti> vibhav: with echo, or does that function not actually read from the console?
[07:53] <vibhav> pitti: wgetch() also works without echo (when I enter myself)
[07:54] <vibhav> So, yes it works from the console
[07:59] <pitti> vibhav: ok, so the test would use echo, so that it runs noninteractively
[07:59] <pitti> vibhav: congrats!
[08:01] <vibhav> pitti: thanks
[08:02] <vibhav> Okay, Ill branch ncurses and request a merge
[08:05] <vibhav> pitti: Any other suggesstions?
[08:05] <pitti> vibhav: if you take glib's debian/tests/ script as an example, please add -Wall -Werror for extra pickiness
[08:06] <pitti> vibhav: I did that for a few packages already, but not for glib yet
[08:11] <vibhav> pitti: Should I add "ncurses" to depends in debian/tests/control?
[08:12] <pitti> vibhav: I rather think you'd need a -dev, and build-essential?
[08:13] <vibhav> pitti: Okay so, will it be libncurses5-dev, build-essential, pkg-config
[08:13] <pitti> that ought to suffice
[08:14] <vibhav> perfect
[08:27] <jibel> vibhav, hey, I reviewed your patch, the test script is fine, but the test of es_str2cstr fails
[08:33] <vibhav> jibel: Thans for the notice, I will hve a look soon
[08:37] <vibhav> pitti: done :) https://code.launchpad.net/~vibhavp/ubuntu/raring/ncurses/add-autopkgtest/+merge/147038
[08:43] <vibhav> jibel: Uploaded correct diff
[08:48] <jibel> vibhav, it passes, congrats!
[08:49] <vibhav> This is a good day
[08:49] <vibhav> Everything is working perfectly.
[08:54] <vibhav> pitti: I need to go, please inform if there are any more chaanges to be done.
[09:13] <tjaalton> is there a way to stop sbuild from generating ddeb's? reprepro can't import them..
[09:15] <geser> IIRC pkg-create-dbgsym has a config file to disable it (or delete the package completely from your sbuild)
[09:16] <tjaalton> thanks, I'll check it out
[09:27] <tjaalton> meh, I'll just add an exit 0 to the script..
[09:29] <Laney> I just sed -i '/\.ddeb/d' foo.changes if I want to reprepro it
[09:37] <tjaalton> that would be one way, though I can't see much use for local ddebs anyway :)
[09:37] <cassidy|Nexus> hey everyone
[09:37] <cassidy|Nexus> I was told yo come
[09:37] <cassidy|Nexus> *to come here from #ubuntu-on-air
[09:38] <Laney> depends how often you like to debug stuff
[09:38] <tjaalton> the ones I build usually have -dbg anyway
[09:38] <cassidy|Nexus> Is anyone working on a service like Contractor or Android Intents?
[09:38] <cassidy|Nexus> http://www.omgubuntu.co.uk/2011/03/contractor-brings-seamless-file-sharing-between-apps-to-the-linux-desktop
[09:38] <tjaalton> like most of pkg-xorg stuff
[09:38] <cassidy|Nexus> or would it be possible for some collaboration with elementary on Contractor? :)
[09:39] <cjwatson> tjaalton: Not sure why you wouldn't just remove pkg-create-dbgsym from the relevant build chroot
[09:40] <cjwatson> tjaalton: It's not build-essential - it's just that mk-sbuild puts it there by default for Ubuntu
[09:42] <RAOF> cassidy|Nexus: That looks like it's trivially implementable by the existing .desktop file infrastructure?
[09:43] <tjaalton> cjwatson: right, best to just remove it then
[09:53] <cassidy|Nexus> 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] <cassidy|Nexus> *file
[09:54] <RAOF> cassidy|Nexus: You're basically asking for mime-type handlers; these exist - it's what populates “open with”
[09:55] <RAOF> So it's not entirely implemented, but you can pretty easily implement it on top of what we've got.
[09:55] <cassidy|Nexus> 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] <cassidy|Nexus> RAOF, it's a very distinct use case
[09:56] <RAOF> So annotate the desktop files.
[09:56] <RAOF> It's not *that* distinct a use case ☺
[09:56] <cassidy|Nexus> RAOF, I encourage you to chat with the devs in #elementary-dev about in.
[09:56] <cassidy|Nexus> *it
[09:57] <RAOF> Not that I think this is a bad idea at all, just that I don't see why it requires extra infrastructure.
[09:57] <cassidy|Nexus> I'm not a desktop dev myself so I'm probably not doing a very good job of explaining it. :-P
[09:58] <cassidy|Nexus> RAOF, but iirc there was a very specific reason it wasn't done through .desktops... :-/
[09:59] <cassidy|Nexus> 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] <cassidy|Nexus> 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] <cassidy|Nexus> 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] <RAOF> Yeah, it's kinda interesting.
[10:54] <mjt> 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] <lifeless> barry: do you know whats up with https://bugs.launchpad.net/subunit/+bug/1025392 ?
[11:33] <pitti> 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] <xnox> lifeless: i had a branch for that indeed.
[11:34] <xnox> lifeless: https://code.launchpad.net/~xnox/subunit/hash-ordering/+merge/131732 ?!
[11:35] <xnox> 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] <lifeless> xnox: the merge proposal for it got cancelled by you AFAICT ?
[11:35] <lifeless> xnox: so was waiting for an updated version ...
[11:35] <xnox> I think I did push an updated revision later.
[11:36] <xnox> Also I uploaded twice into https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/subunit/raring-proposed
[11:36] <xnox> (revisions 16 & 17)
[11:36] <lifeless> xnox: [not to mention that the original change wasn't suitable for production use]
[11:36] <xnox> lifeless: what do you mean by not suitable for production use?
[11:36]  * xnox was just doing bulk porting to python3.
[11:36] <xnox> You mean shebang changes?
[11:37] <lifeless> xnox: I said it in the review; the code was correct, the issue was only in the test suite.
[11:37] <lifeless> xnox: making the actual code slower to make tests pass is inappropriate
[11:38] <xnox> ah, ok.
[11:40] <lifeless> the serialiser is in the critical path for speed
[11:40] <lifeless> its not as fast as it probably needs to be already, so I'm a tad sensitive.
[11:40] <xnox> ok. I'll rework it. But i have a few urgent things to push out today.
[11:41] <lifeless> no rush
[11:41] <lifeless> I just released 0.0.10, which doesn't have that patch.
[11:41] <lifeless> but fixes some more python 3 issues
[11:43] <xnox> cool
[11:44] <lifeless> (subtle ones that you can only detect with stuff running on stop of subunit :))
[12:04] <mjt> 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?
[12:39] <geser> mjt: if nothing needs changing (like an additional patch) the the package is taken from Debian as-is
[12:40] <xnox> 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] <xnox> mjt: and target raring
[12:48] <mjt> ok, thanks!
[12:48] <mjt> (i'm not uploading anything to ubuntu, i'm just making life for some ubuntu'ers easier :)
[13:18] <xnox> =)
[14:20] <hallyn> mjt: oh, ok, thanks
[14:28] <hallyn> 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] <hallyn> hm, the raring netboot image (which worked for me two weeks ago) is failing to boot
[14:33] <barry> hi lifeless, xnox all sorted out?
[14:33] <mjt> hallyn: i just replied to your email.  If Liang wont reply tomorrow I'll just push it
[14:33] <hallyn> mjt: awesome, thanks, then i'll wait
[14:33] <mjt> hallyn: together with the configure fix
[14:34] <xnox> barry: yeah. mostly agreed what I should do next.
[14:34] <barry> xnox: excellent!
[14:41] <cjwatson> hallyn: failing how?
[14:54] <cjwatson> hallyn: oh, yeah, I think I heard there was some syslinux breakage, could be that
[14:55] <cjwatson> hallyn: it's been reported in Debian too ...
[14:55] <cjwatson> oh my god, enormous thread on debian-ctte about it
[14:57] <Laney> oh yes.
[15:02] <cjwatson> well, I can cherry-pick the reported patches to d-i/debian-cd at least and see if they help
[15:08] <hallyn> cjwatson: yeah, it's right at boot failing to find ldlinux32.c32
[15:08] <hallyn> sounds like it's covered then, thanks :)
[15:08]  * hallyn goes to look for that m-l
[15:08] <hallyn> oh.  heh.
[15:11] <seiflotfy> hey guys
[15:11] <seiflotfy> mhall119: http://libqzeitgeist.geekyogre.com/ :D
[15:11] <seiflotfy> booom
[15:20] <mpt> Hey seiflotfy, long time no see
[15:20] <seiflotfy> hey mpt
[15:20] <seiflotfy> mpt: how are you
[15:20] <seiflotfy> ?
[15:21] <mpt> seiflotfy, splendid. Have you heard from Manish Sinha lately?
[15:21] <seiflotfy> yeah, he was working on the activity log manager
[15:21] <seiflotfy> he has exams atm
[15:21] <seiflotfy> mpt i am willing to take a look after the weekend
[15:21] <seiflotfy> i am busy releasing zeitgeist 1.0
[15:21] <mpt> Ooh, congrats
[15:22] <seiflotfy> thanks
[15:22] <seiflotfy> much faster, directreading (no dbus roundtrips) and gobject introspection support
[15:23] <mpt> Will that make the Dash faster? :-)
[15:23] <seiflotfy> yep
[15:23] <seiflotfy> much faster
[15:23] <seiflotfy> dash is mostly slow due to ubuntu1 spamming it
[15:24] <seiflotfy> mpt if you want to make it faster, just delete the DB and make it rebuild itself
[15:24] <seiflotfy> :D
[15:24] <seiflotfy> because old u1 entries kinda messed things up big time
[15:25] <mpt> ooh, how do I do that
[15:26] <seiflotfy> ok
[15:26] <seiflotfy> first
[15:26] <seiflotfy> in a temrinal
[15:26] <seiflotfy> zeitgeist-daemon --replace
[15:26] <seiflotfy> then kill it
[15:27] <seiflotfy> the mv ~/mpt/.local/share/zeitgeist ~/mpt/.local/share/zeitgeist-backup
[15:27] <seiflotfy> then in a terminal
[15:27] <seiflotfy> zeitgeist-daemon --replace
[15:28] <mpt> woo-hah
[15:28] <mpt> Now it opens in less than two seconds!
[15:29] <seiflotfy> mpt: its still busy
[15:29] <seiflotfy> give it time
[15:29] <seiflotfy> it gets quicker
[15:29] <seiflotfy> :d
[15:29] <seiflotfy> zeitgeist is busy building the index again
[15:29] <seiflotfy> takes 60 seconds or so
[15:29] <jpds> seiflotfy: http://zeitgeist-project.com/ - you need to update that logo.
[15:29] <mpt> ok
[15:29] <seiflotfy> jpds: i know, but i am lacking resources
[15:29] <seiflotfy> right now we are 4 ppl doing the zeitgeist besides our real jobs
[15:30] <seiflotfy> mpt: run zeitgeist in a terminal
[15:30] <seiflotfy> zeitgeist-daemon --replace
[15:30] <seiflotfy> then open the dash
[15:30] <mpt> seiflotfy, it is
[15:30] <seiflotfy> and show me the output on the terminal
[15:30] <seiflotfy> mpt: ^
[15:31] <mpt> Hm, the Terminal is stuck behind a HUD that won't close
[15:31] <marga> tseliot, hey there, are you around?
[15:31] <seiflotfy> oh man
[15:31] <mpt> "Thanks HUD! ... Thud!"
[15:31] <tseliot> marga: yep
[15:32] <marga> tseliot, I work with Michael Wisheu, he sent you a mail regarding the regeneration of initramfs images in nvidia's postinst
[15:32] <jpds> seiflotfy: http://www.canonical.com/sites/default/themes/canonical10/images/footer_logo.png
[15:32] <seiflotfy> jpds: on it later today
[15:33] <marga> 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] <tseliot> marga: right, I haven't replied to him yet
[15:33] <marga> tseliot, if you think this approach is fine, I could prepare the patch for you.
[15:34] <tseliot> 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] <marga> 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] <marga> What were the debconf headaches of the past?
[15:35] <tseliot> marga: some serious problems with the nvidia-common package causing problems during dist-upgrades, etc.
[15:36] <marga> tseliot, hm, knowing what the problems actually were might be helpful in not falling into the same mistakes.
[15:37] <xnox> what's the question here?
[15:37] <tseliot> 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] <marga> 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] <marga> 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] <marga> So, we want to _optionally_ regenerate all images.
[15:39] <mpt> seiflotfy, http://paste.ubuntu.com/1621263/
[15:40] <seiflotfy> mpt now keep it running and open dash
[15:40] <seiflotfy> then tell me what the terminal says
[15:40] <tseliot> 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] <mpt> seiflotfy, no further output.
[15:42] <marga> 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] <seiflotfy> mpt: my bad
[15:42] <seiflotfy> zeitgeist-daemon --replace --log-level=debug
[15:42] <marga> Do you want me to send you the patch?
[15:43] <tseliot> marga: or you can touch the file and do dpkg-reconfigure nvidia-310 (or whatever)
[15:43] <tseliot> marga: aah, I see your problem
[15:44] <seiflotfy> mpt: what does it spit
[15:44] <tseliot> marga: patches are always welcome
[15:45] <seiflotfy> mpt: ?
[15:46] <mpt> seiflotfy, http://paste.ubuntu.com/1621279/
[15:47] <seiflotfy> so when you open dash it does not contact zeitgeist :D
[15:47] <seiflotfy> but the times are very fast
[15:47] <seiflotfy> [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] <seiflotfy> woops sorry
[15:48] <seiflotfy> mpt: the first search is slow iwth 0.2 second
[15:48] <seiflotfy> but then all under 0.1 seconds
[15:48] <seiflotfy> do you notice a difference
[15:50] <mpt> seiflotfy, yes. :-) It now has what, in the early days of Mozilla, we used to call "teh snappy"
[15:51] <seiflotfy> my DB is HUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUGE
[15:51] <seiflotfy> mpt: but with the next release it will be faster
[15:51] <seiflotfy> :DS
[15:52] <seiflotfy> http://seilo.geekyogre.com/2013/01/zeitgeist-1-0-almost-there-call-for-hackers/
[15:58] <luist> hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories?
[16:09] <dholbach> kirkland, intriguing changelog entry ;-)
[16:12] <kirkland> dholbach: which one?
[16:12] <stgraber>   * UNRELEASED
[16:12] <stgraber> ^ that one :)
[16:12] <dholbach> https://lists.ubuntu.com/archives/raring-changes/2013-February/005725.html
[16:12] <dholbach> :)
[16:13] <kirkland> wtf
[16:13] <kirkland> dholbach: stgraber: thanks... let me see what went wrong with my release scripts....
[16:14] <dholbach> don't worry - it might feed some rumour mill somewhere ;-)
[16:14] <kirkland> dholbach: I'm your Huckleberry!
[16:14] <mpt> seiflotfy, maybe the OS upgrade script should rebuild the zeitgeist database?
[16:15] <mpt> seiflotfy, though I guess that doesn't really work if it's user-specific
[16:16] <mpt> Maybe zeitgeist updates set a RebuildIfLastRebuildWasEarlierThan flag, and looks at it on each login
[16:16] <mpt> or something
[16:16] <seiflotfy> mpt: just delete all u1 entries
[16:17] <seiflotfy> and things are back to normal
[16:17] <seiflotfy> :P
[16:17] <caribou> 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] <caribou> xnox: Bug #833368
[16:21] <kirkland> 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] <xnox> 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] <caribou> xnox: ok, thanks for the info
[16:23] <xnox> caribou: yeah, currently 12.04.2 is in preparation for candidate images.
[16:25] <rbasak> 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] <cjwatson> rbasak: what's the package?
[16:26] <rbasak> cjwatson: I'm experimenting with puppet 3.1 out of debian git vcs
[16:26] <rbasak> success: https://launchpadlibrarian.net/130544489/buildlog_ubuntu-raring-i386.puppet_3.1.0-0ubuntu1~ppa1_UPLOADING.txt.gz
[16:26] <rbasak> failed: https://launchpad.net/~racb/+archive/experimental/+build/4279299
[16:27] <rbasak> 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] <cjwatson> 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] <cjwatson> Haven't analysed this particular case but that should bring it closer
[16:28] <rbasak> 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] <rbasak> Sorry, that the first build on the PPA succeeded and the second failed
[16:28] <cjwatson> Dunno, could be changes elsewhere in the archive
[16:28] <rbasak> OK
[16:29] <cjwatson> I'm partially guessing :)
[16:37] <Riddell> tjaalton: ping
[16:39] <rbasak> 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] <tjaalton> Riddell: pong
[16:40] <Riddell> tjaalton: xfixes seems to cause breakage
[16:40] <Riddell> http://paste.kde.org/666956/
[16:40] <Riddell> tjaalton: sorry xinput rather
[16:40] <Riddell> tjaalton: clashing variable name with xfixes
[16:40] <tjaalton> huh
[16:41] <tjaalton> ok then
[16:41] <Riddell> tjaalton: is there an upstream to moan to?
[16:41] <tjaalton> my bad, should've pushed it to the staging ppa..
[16:41] <tjaalton> no, it's conflicting with our old implementation aiui
[16:42] <tjaalton> which is shipped by the xserver
[16:44] <Riddell> tjaalton: with an old xfixes?
[16:44] <tjaalton> Riddell: right that's where it's from..
[16:46] <tjaalton> Riddell: ok, I'll revert it from libxi for now
[16:50] <Riddell> 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] <luist> hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories?
[16:59] <tjaalton> Riddell: uploaded -0u2 which reverts the upstream code for now
[17:00] <Riddell> thanks tjaalton
[17:00] <Riddell> tjaalton: will you also file a bug upstream, or should I?
[17:02] <tjaalton> 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] <tjaalton> Riddell: so kde has added support for our own implementation of it (like unity) you'd need to port it
[17:04] <tjaalton> +if
[17:04] <Riddell> tjaalton: own implementation of what?
[17:05] <tjaalton> Riddell: once the build works with -0u2 I'll upload -0u3 to canonical-x/x-staging ppa which restores the upstream stuff
[17:05] <tjaalton> Riddell: pointer barrier events
[17:05] <Riddell> 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] <tjaalton> no this is for dualhead, resistance for the pointer when crossing screen barriers
[17:06] <tjaalton> so if you don't have versioned build-deps against our libxfixes then you're safe :)
[17:07] <tjaalton> it's just that including both new and old headers cause issues, like you pointed out..
[17:10] <smoser> infinity, ping.
[17:26] <infinity> smoser: Pong, ish.
[17:27] <smoser> just asking about 115710 (kmod mellanox)
[17:27] <infinity> smoser: Yeah, I nick highlighted you overnight, I think.
[17:27] <smoser> shoot.
[17:28] <infinity> 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] <smoser> infinity, i think the issue is present on raring also
[17:28] <smoser> i can veryify that though.
[17:28] <infinity> 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] <smoser> the update-initramfs... i think thats where i was testing.
[17:29] <infinity> smoser: It works fine in raring.
[17:29] <smoser> really?
[17:29] <infinity> Yeah.
[17:30] <infinity> Given that kmod and module-init-tools share absolutely zero code, the behaviour changing isn't shocking.
[17:30] <infinity> Not that m-i-t is "wrong" for noting the loop (mlx4_en depends on mlx4_core, after all).
[17:30] <marga> 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] <marga> tseliot, thanks for your time :)
[17:31] <tseliot> marga: you'll still have to rebuild the modules manually
[17:31] <smoser> infinity, ok. so you're right. it seems cleaner with the post in raring.
[17:31] <smoser> and i just tested no crying there.
[17:32] <smoser> so lets do that.
[17:32] <smoser> so, then, reguarding the _ib module...
[17:32] <smoser> i just think if we believe that _en should be loaded, then why would we not load _ib ?
[17:32] <infinity> 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] <smoser> it seems arbitrary to decide that ethernet usage is expected but infiniband is not.
[17:33] <smoser> (they get pulled in with the soft-dep)
[17:33] <infinity> They sure don't.
[17:33] <smoser> http://paste.ubuntu.com/1621558/
[17:34] <infinity> Is that with the install or softdep setup?
[17:34] <infinity> I didn't get that behaviour on either raring or precise when I tested.
[17:35] <smoser> softdep
[17:35] <infinity> And what release?
[17:36] <smoser> i just re-built that initramfs with no soft-dep and its gone.
[17:36] <smoser> that is raring, but i'm running quantal kernel
[17:36] <smoser> because of hardware issues.
[17:36] <infinity> Oh, confusing.
[17:36] <smoser> 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] <infinity> So, I intentionally deleted the _ib module while testing a different thing, let me restore that and see. :P
[17:37] <infinity> But it also would pull in the whole _ib stack into the initrd too.
[17:37] <smoser> it would, yes.
[17:37] <smoser> is there a reason we wouldn't want that?
[17:38] <smoser> i wondered about this too, and thought maybe we should not do _ib
[17:38] <infinity> Well, I'm not sure how all of this is generally used, to be honest.
[17:38] <smoser> but it just seems random to decide that "of course you want ethernet drivers for your hardware, but maybe not infiniband"
[17:39] <infinity> 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] <smoser> "if you want infiniband, then manual action is required"
[17:39] <smoser> i dont know.
[17:39] <infinity> Yeah, me neither. :P
[17:44] <smoser> infinity, well., you want to ditch the _ib ?
[17:45] <infinity> smoser: I'm thinking no one will notice if we do.
[17:45] <smoser> ok.
[17:45] <smoser> so soft-dep for raring
[17:45] <smoser> and no _ib loading
[17:45] <infinity> smoser: And it gets rid of the minor initramfs-tools/modprobe interaction issue for the backport. :P
[17:46] <smoser> ?
[17:46] <infinity> Well, for precise, where the _ib module doesn't end up in the initrd, but then modprobe still tries to install it.
[17:46] <infinity> Anyhow.  I think it's sane to keep it small, and _en is small.
[17:50] <smoser> infinity, so what do you want from me?
[17:50] <smoser> i'll change my non-raring branches
[17:50] <smoser> and comment in the bug to this decision
[17:50] <smoser> but you pick up raring ?
[17:50] <infinity> smoser: Yeahp, that works for me.
[17:51] <infinity> smoser: Well, if you want upload credit, you can give me a branch/diff for raring too.
[17:51] <infinity> 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] <smoser> i'l update raring
[18:13] <smoser> infinity, ok. we're good at https://code.launchpad.net/~smoser/ubuntu/raring/kmod/lp-1115710/+merge/146760
[18:27] <seb128> 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] <siretart> alexlist: now I'm around. what's up about dput?
[18:44] <dobey> 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] <seb128> slangasek, ^ want to sponsor it? ;-)
[18:45] <seb128> or I can dput but I will deny any responsability if it has issues ;-)
[18:45] <siretart> 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] <siretart> any takers?
[18:49] <Kano> hi, what tool is used to create the final ubuntu iso?
[19:04] <luist> hey guys... how can i generate my customized ubuntu image considering i have a list of packages and some repositories?
[19:09] <roadmr> luist: did you read https://help.ubuntu.com/community/LiveCDCustomization ?
[19:13] <lifeless> barry: yeah thanks
[19:20] <arges> 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] <xnox> arges: do that, but in an lxc container? =)
[19:24] <arges> xnox: yea i'm doing this in a vm for sure
[19:26] <arges> but last time I did it completely borked the system, and I couldn't even 'ls' anymore
[19:27] <sarnold> vm with rollback :)
[19:28] <xnox> arges: always install busybox-static ;-)
[19:28] <sarnold> you might wish to glance over https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment and see if the uvt tool is something you'd like to steal :) I like using it, anyway..
[19:28] <arges> sarnold: thanks i'll take a look
[19:29] <arges> xnox: yea, that's not a bad idea. I'll put that in there too
[19:29] <sarnold> uvt stop -rf virt-machine-name ; uvt start -v virt-machine-name -- and try again :)
[19:30] <arges> sweet.
[19:38] <siretart> I'm looking for the script/program that creates the Ubuntu server CDROM. can someone please point me to the right direction? I need to recreate it with less packages.
[19:38] <stgraber> seems like it's a popular question lately ;)
[19:39] <siretart> stgraber: oh, did I miss the answer?
[19:39] <stgraber> short answer for the server CD is, it's not public
[19:39] <cjwatson> eh, the server CD is practically all debian-cd
[19:39] <stgraber> siretart: not today, no. Kano asked the same question a bit earlier on but nobody replied.
[19:39] <stgraber> cjwatson: even with the new fancy livefs stuff?
[19:39] <cjwatson> lp:ubuntu-cdimage + lp:~ubuntu-cdimage/debian-cd/ubuntu
[19:40] <Kano> why not main?
[19:40] <cjwatson> I think you might have to glue something in manually to call BuildLiveCD from livecd-rootfs - the glue in ubuntu-cdimage is "ssh to another server of the right architecture" in any event
[19:40] <seb128> cjwatson, did you see my g-c-c 12.04 ping on -release earlier?
[19:40] <cjwatson> Yeah, been on a call since, having a look
[19:41] <cjwatson> I assume you've eyeballed the logo and I needn't bother :)
[19:41] <seb128> cjwatson, ok, no hurry, you timeouted at some point so I wanted to make sure you got it
[19:41] <seb128> cjwatson, I copied back the one we have in precise at release time
[19:41] <seb128> had
[19:41] <siretart> cjwatson: thanks a lot, I'll have a look at the scripts!
[19:43] <bdmurray> hallyn: the qemu-kvm upload in the proposed queue for quantal does not have bug 1033727 in the changelog ... only a debian bug
[19:43] <infinity> arges: make and make install from upstream glibc sources will land you in pain.
[19:44] <infinity> arges: Build the package, then apply your patch, make, and copy the one library/binary you're testing.
[19:44] <infinity> arges: The re-make will be pretty quick cause, y'know, that's how make works.
[19:46] <slangasek> seb128: feel free to dput and redirect the blame to me :-)
[19:47] <hallyn> bdmurray: well <slap>
[19:47] <seb128> slangasek, thanks ;-)
[19:49] <arges> infinity: ok that sounds a  lot more sane
[19:52] <cjwatson> grr, having serious network problems today
[19:52] <cjwatson> seb	accepted now, thanks
[19:52] <cjwatson> seb128: ^-
[19:52] <seb128> cjwatson, thank you! ;-)
[19:56] <hallyn> bdmurray: resubmitting
[19:56] <infinity> arges: Out of curiosity, what's the bug you're hunting?
[19:57] <Kano> cjwatson: can you update ntfs-3g to 2013 release because of w8?
[19:57] <arges> infinity: bug 1109327
[20:00] <infinity> arges: Oh right.  Well, tracing where it gets leaky and dies might be helpful, then you can biset a bit more fine-grained.
[20:00] <arges> infinity: yea i've been gdbing it, it happens when asprintf returns an err
[20:04] <infinity> arges: I assume this is a somehow broken/corrupt wtmp?
[20:04]  * arges checks
[20:05] <infinity> Well, random googling suggests this has been on-again/off-again through the ages (like, back to 1998 or more), and wiping wtmp, or even logging out and back in has "fixed" it for people.
[20:05] <arges> infinity: yes afaik it was a validly created wtmp (i had to replace the hostnames)
[20:05] <arges> infinity: the odd thing is that with this input it works with eglibc-2.16 and greater, but not 2.15
[20:08] <infinity> arges: And if I tell you it works fine on precise for me...?
[20:09] <arges> infinity: you typed 'who wtmp.clean'
[20:09] <infinity> Yes...
[20:09] <arges> at the end did you get 'who: memory exhausted'
[20:09] <infinity> No.
[20:09] <arges> precise amd64 ?
[20:10] <infinity> Just tried amd64 and i386
[20:10] <arges> i can reproduce this on my desktop/laptop/vms etc
[20:10] <arges> i've reproduced this on raring install with eglibc-2.15 installed
[20:10] <arges> amd or x86?
[20:11] <infinity> Works here with libc6 2.15-0ubuntu10 and 2.15-0ubuntu10.4
[20:11] <infinity> Intel CPU.
[20:11] <infinity> Don't have any AMD kit handy.
[20:11] <arges> yea i've tested on intel and was able to reproduce
[20:11] <arges> hmm
[20:12]  * ajmitch can reproduce on precise amd64
[20:12]  * infinity blinks.
[20:12] <infinity> Kernel?
[20:12] <infinity> These are precise chroots on a raring kernel in my case.
[20:12] <arges> 3.2.0-37, and raring 3.8
[20:12] <arges> umm let me try in a chroot
[20:13] <ajmitch> 3.5.0-22-generic for me, libc6 2.15-0ubuntu10.3
[20:14] <arges> infinity: ok works fine in a precise chroot
[20:14] <arges> for me
[20:14] <infinity> Okay, that's what I was seeing, so that's comforting.
[20:14] <infinity> But on a precise kernel with raring's glibc, it works?
[20:15] <arges> infinity: yes this I've tested
[20:15] <infinity> Or was that test on a raring kernel too? :P
[20:15] <arges> i did it both ways
[20:15] <arges> tested the raring/precise versions of the libraries both ways
[20:19] <infinity> arges: I was about to say "works fine on Debian's 2.13 as well", but that's a kFreeBSD machine, not Linux.
[20:19] <infinity> arges: So... One more "maybe the kernel matters" datapoint, I guess. :P
[20:20] <arges> infinity: i can try testing that as well... i imagine this bisect will be slow and painful
[20:23] <ajmitch> fwiw, I can reproduce on lucid amd64
[20:24] <infinity> Yeah, pure precise reproduces it fine, but raring kernel fixes it.
[20:24] <infinity> So.  I'm not sure what to make of that, if the inverse (precise kernel and raring glibc) also fixes it.
[20:28] <arges> infinity: testing that now
[20:31] <infinity> Uhm, this is absolutely corrupt.
[20:31] <arges> infinity: precise userland / 3.8 kernel still fails
[20:31] <infinity> Who has TTYs that are random unicode garbage?
[20:31] <dobey> slangasek: thanks! (re: gnome-keyring)
[20:32] <infinity> arges: precise userland and 3.8 kernel worked fine here...
[20:32] <infinity> arges: Anyhow, seriously, have you looked at what it's failing ON?
[20:32] <arges> non chroot?
[20:32] <arges> yes I know the odd unicode char
[20:32] <infinity> "Odd"?
[20:32] <infinity> Where and how did they get that in there?
[20:33] <infinity> stat("/dev/\260", 0x7fff42df8100)       = -1 ENOENT (No such file or directory)
[20:33] <infinity> ^-- That's not a sane device node.
[20:33] <arges> you could do something like: sudo sessreg -l � -h "127.0.0.1" -a test
[20:33] <arges> so should this fail and cause a memory exhausted error? though
[20:34] <infinity> arges: The better question might be how are they getting those sessions, not why does who dislike them.
[20:34] <infinity> arges: No, it probably shouldn't throw the error it does, but this could also be a big "who cares", when the real bug is that data being in wtmp in the first place.
[20:35] <infinity> Waaaaaitaminute.
[20:35] <infinity> I bet it doesn't fail in my chroot because of the locale.
[20:36] <infinity> Or maybe not.
[20:36] <arges> mine has been en_US.UTF-8 on both fail and passing cases
[20:36]  * infinity generates some locales...
[20:37] <infinity> Nope, I was right.
[20:37] <infinity> arges: LANG=C fixes it, LANG=en_US.UTF-8 reproduces it.
[20:37] <infinity> arges: (in a precise chroot)
[20:37]  * arges checks
[20:37] <arges> (not that i don't believe you)
[20:37] <arges> it works!
[20:38] <infinity> If this is something that's hindering some internal script of theirs or something, "export LANG=C" is the workaround for now, at least.
[20:39] <arges> infinity: yes
[20:39] <infinity> But it also hints somewhat at places to look for the fix.
[20:39] <infinity> But seeing the char it was vomiting on was enough of a hint there. :P
[20:40] <arges> this is why it helps to check with the local guru.
[20:41] <infinity> arges: 9954432e309c8fddaec2fe53e601702a5c981624 perhaps
[20:41] <arges> infinity: i'll make a test build now
[20:42] <infinity> arges: That's just a random stab from git log, I haven't read the commit or anything. :P
[20:43] <arges> infinity: works now for UTF-8 locales...
[20:43] <infinity> Though not entirely implausible.
[20:43] <infinity> arges: srsly?  First try?
[20:44] <arges> infinity: no no just reading the git commit
[20:44] <arges> : )
[20:44] <infinity> Oh.  Heh.
[20:44] <infinity> Well, yes, the commit is entirely about abuse of wchars in UTF-8, which definitely touches on this area.
[20:44] <infinity> But if it actually was what fixed the bug, I don't know.
[20:45] <arges> yea testing it out now
[20:45] <arges> or rather building the package
[20:51] <arges> hmm backporting will take some work for this one
[20:58] <infinity> arges: Stacking d3ed722566f42d3f614b1221a8e4f19092976531 on top might help.  It kinda reverts half of it. :P
[21:00] <infinity> arges: What are you trying to backport this to?  Just 2.15?
[21:00] <arges> infinity: yea
[21:01] <infinity> Let me spin up a build tree here.
[21:24] <dobey> woah ev
[21:24] <dobey> dude
[21:44] <idank> hello, I'd like to do some research with man pages and could really use a dump of those available here http://manpages.ubuntu.com/manpages/precise/en/man1/ (the .gz format)
[21:44] <idank> kirkland (the maintainer of that subdomain) suggested I create my own mirror, but I was hoping someone with access to the machines that hosts it could be of assistance
[21:50] <NishanthMenon> Fuchs, thx
[21:51] <Fuchs> You're welcome
[21:53] <kirkland> lamont: infinity: elmo: is there an rsync-able Ubuntu archive mirror within ec2?
[21:53] <kirkland> lamont: infinity: elmo: AFAICT the s3 backed mirrors are not rsyncable
[22:14] <luv> hi there - what would be the best place to discuss ubuntu online accounts - the inability to logout/revoke tokens is unacceptable for me and is the reason why im sticking with 12.04 LTS, im happy to help with coding to add the functionality though!
[22:20] <infinity> kirkland: No idea.
[22:20] <infinity> utlemming: You're a cloudy guy, do you know the answer to Dustin's question?
[22:31] <dobey> what the heck
[22:31] <dobey> i just installed valgrind, and "Ubuntu Core Installer" dialog popped up
[22:38] <dobey> does anyone know a possible way to run /usr/lib/squid3/ncsa_auth outside of the squid process, to test it? it's crashing on raring, and the backtrace is a bit lacking of usefuleness, so i need to run it under valgrind
[22:40] <infinity> tjaalton: Wat.
[22:40] <tjaalton> infinity: que?
[22:40] <infinity> tjaalton: Looking at your sssd uploads via mdeslaur in the security PPA (sorry for the delay).
[22:40] <tjaalton> oh
[22:41] <infinity> tjaalton: Same changelog entry for each.  One is a 718 byte diff, the other is 639 KBytes.  That seems.  Wrong.
[22:41] <tjaalton> hum
[22:43] <utlemming> infinity: chatting with dustin now
[22:45] <tjaalton> infinity: oh, it's correct, they had the same flaw :)
[22:45] <infinity> tjaalton: What's correct?
[22:45] <tjaalton> ah...
[22:45] <infinity> tjaalton: if the changelogs are correct, the diffs aren't.
[22:45] <tjaalton> kB
[22:45] <tjaalton> infinity: the quantal one should be fine, need to check the precise upload..
[22:47] <cr3> jdstrand: in bug #1031090, you mention "add the required flag to the MSRs passed to guests" so that quantal guests can load from precise host. I'm not seeing what those flags are in the bug report though, do you have a hint? :)
[22:57] <tjaalton> infinity: the diff for precise shows files "removed" that aren't in git that the tarball has, for one reason or another.. I'll check with upstream
[22:59] <infinity> tjaalton: Not sure how upstream relates here.  There shouldn't be a change between two packaging revisions.
[22:59] <infinity> tjaalton: It's not like this was a diff between two upstream tarballs.
[23:00] <tjaalton> infinity: well running debdiff against the versions I had built shows only the changes to debian/*
[23:00] <tjaalton> the tarball doesn't have those files either
[23:01] <infinity> tjaalton: Is the version in precise-proposed the same as on your computer? :P
[23:01] <tjaalton> I'll check :)
[23:02] <infinity> tjaalton: The one in precise-proposed has all that junk in the diff.gz
[23:03] <infinity> tjaalton: So, someone screwed up.  And if it's not meant to be there, cool.  But you need to make sure the current one's now right. :P
[23:03] <tjaalton> oh
[23:07] <tjaalton> infinity: 0.1 isn't the same
[23:07] <tjaalton> as here
[23:07] <tjaalton> the diff.gz is nearly 1MB
[23:07] <tjaalton> perhaps a bit too sensitive to how it's generated..
[23:08] <tjaalton> still amazing how it has files the tarball doesn't :)
[23:10] <tjaalton> so yeah, 0.2 looks fine, the diff still has the po stuff but not much can be done there
[23:21] <tjaalton> infinity: satisfied? :)
[23:25] <infinity> tjaalton: Never.
[23:25] <infinity> tjaalton: But this'll have to do for now. ;)
[23:25] <infinity> tjaalton: Say, did someone actually fix my intel GPU lockups, or have I just been having a good week?
[23:26] <tjaalton> infinity: did you enable some workaround?
[23:26] <infinity> Nope.
[23:26] <tjaalton> and running the current packages?
[23:27] <infinity> Oh...
[23:27] <infinity> xserver-xorg-video-intel (2:2.20.19-0ubuntu1) raring; urgency=low
[23:27] <infinity>   * Merge from unreleased debian git
[23:27] <infinity>   * rules: Use SNA as the default acceleration method.
[23:27] <infinity>  -- Timo Aaltonen <tjaalton@ubuntu.com>  Mon, 21 Jan 2013 10:18:31 +0200
[23:27] <infinity> I didn't enable a workaround, but you did. :P
[23:27] <tjaalton> oh sna helped, thought you tried it out earlier
[23:28] <infinity> No, I intentionally didn't switch, cause you told me it was a performance loss.
[23:28] <infinity> And I'm not keen on hackish workarounds.
[23:28] <tjaalton> no that was the semaphore thingy, sna was testable to see if switching uxa->sna would fix this hang :)
[23:29] <infinity> Hrm.  Well, it hasn't hung, so success, I guess.
[23:29] <tjaalton> yeah, nice
[23:56] <cjwatson> dobey: hm, "Ubuntu Core Installer" popped up for me earlier after a dist-upgrade - I didn't track down why
[23:58] <sarnold> cjwatson,dobey: does this look familiar? https://bugs.launchpad.net/bugs/1117165
[23:58] <sarnold> s/familiar/similar/
[23:59] <sarnold> similer? sigh. now nothing I type looks correct.