[03:18] <srinira> catbus1 ping
[03:18] <catbus1> srinira: pong
[03:39] <vlad_starkov> Question: Just installed Ubuntu 12.04 LTS 64bit. On boot it freezes and shows "BUG: soft lockup - CPU stuck for 21s". Anyone know what is that?
[06:44] <pitti> Good morning
[06:44] <pitti> ev: we don't have it because no human being is supposed to use devel-proposed
[06:45] <pitti> ev: if we add it, the retracers would indeed install -proposed for most packages and get a version mismatch; it's not yet clever enough to install packages by version
[06:49] <pitti> stgraber: libguestfs> argh, my bad; reuploaded with bug ref
[07:26] <hyperair> hmm, odd. ctrl+pgup/n doesn't work in emacs when running in tmux/byobu
[07:53] <dholbach> good morning
[08:01] <ion> that
[09:43] <jamespage> ev, hey - would you be offended if I removed whoopsie from the server seeds?  I'm not sure its adding any value for server
[09:44] <ev> jamespage: go for it. We can always add it back when we solve the server crash reporting story
[09:44] <jamespage> ev, great - thanks
[09:44] <ev> pitti: *nods*
[09:44] <ev> thanks
[10:08] <jamespage> xnox, have you looked at dm-cache?  just wondering whether installer support might be in desktop plans for this cycle
[10:10] <xnox> jamespage: mdadm powered fakeraid is in the plan (Intel Rapid Storage aka Matrix storage). at the vUDS-1308 Rapid Start was discussed but not implemented at the moment.
[10:11] <xnox> jamespage: dm-cache and/or Intel Rapid Response support would be nice, but not implemented in the installer. But i thought dm-cache is easy enough to enable post-install, no?
[10:11] <jamespage> xnox, yeah - I've been looking at it
[10:12] <jamespage> xnox, I asked because I was poking at a iMac with a Fusion 'drive' the other day and I'm pretty sure that's using dm-cache
[10:12] <jamespage> i.e. its not just a single drive - its actually an SSD + a big spindle
[10:12] <xnox> right.
[10:13] <xnox> macs do have tendency to use intel tech, so yeah it could be "Rapid Response" / dm-cache compatible.
[12:39] <Mirv> doko_: did_rocks asked to bring to your attention bug #1255505 regarding python2.7 update. downgrading to 2.7.5-8ubuntu4 fixed running autopilot for me.
[12:47] <Mirv> regarding https://wiki.ubuntu.com/SponsorshipProcess links, I wonder if the larger scope (bugs not necessarily under /ubuntu) https://bugs.launchpad.net/bugs/+bugs?field.subscriber=ubuntu-sponsors would be beneficial to link to / go through?
[12:49] <Mirv> dholbach: what do you think ^ (I came to look at that after reading your PatchPilot report), do you for example ever look at those bugs or just those under /ubuntu?
[12:51] <dholbach> Mirv, I usually look at everything that's listed on here: http://reqorts.qa.ubuntu.com/reports/sponsoring/
[12:52] <dholbach> Mirv, which probably is what you're referring to
[12:52] <Mirv> well hmm yeah there's noise in that link of mine, not sure if there is any signal ie. lost bugs
[12:52] <dholbach> Mirv, do you have an example bug that is not on the report I mentioned?
[12:52] <Mirv> dholbach: right, that web page is anyhow better. I'll look through, and tell if there's something that would be missed.
[12:53] <dholbach> awesome
[13:00] <Mirv> dholbach: ok it seems there are a couple of things that fall through the cracks if not using the global search. examples include bugs against 'Backports' project like bug #853511 (I saw only one another, for Hardy), bugs against DDTP that would need the magic DDTP updating mvo used to do, and then there might be "please get to Ubuntu" at upstream projects like bug #841191 (I targeted it now to Ubuntu)
[13:04] <dholbach> Mirv, can you file a bug on https://bugs.launchpad.net/ubuntu-sponsoring?
[13:06] <Mirv> dholbach: ok
[13:06] <dholbach> thanks muchly!
[13:14] <dholbach> robru, happy birthday! :)
[14:56] <pitti> seb128: it seems the qt telephony stuff has been uninstallable in -proposed for a week or more, due to e-d-s/folks
[14:57] <pitti> elopio: ^
[14:57] <pitti> seb128: do you know any details there?
[14:57] <pitti> this causes upstream MPs to get rejected as they are uninstallable on desktop
[14:57] <seb128> pitti, uninstallability in proposed? no I don't
[14:57] <seb128> pitti, the e-d-s transition is linked to the libav and samba ones due evolution-mapi
[14:58] <seb128> pitti, with the tb upload we should almost be good
[14:58] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt says the new e-d-s makes folks and qtdeclarative5-ubuntu-telephony0.1 and several dozen others uninstallable
[14:58] <pitti> seb128: ah, so e-d-s changed ABI and all rdepends need to be rebuilt?
[14:58] <seb128> shrug
[14:58] <seb128> how did we regress?!
[14:58] <seb128> pitti, that list was down to 3 sources yesterday, we have been doing rebuilds for a week
[14:58] <seb128> Laney, xnox: ^ do you know what's going on?
[14:59] <pitti> seb128: thanks for the update; so what I hear is "it's known and being worked on"?
[15:00] <seb128> pitti, let's say that, the transition is actively being worked on, the un-installable list seems to have increased today for some reason though :/
[15:00] <Laney> why do you think it got worse?
[15:00] <Laney> it has not
[15:00] <pitti> not that easy to read
[15:00] <Laney> look for "Trying easy from autohinter: libebml/1.3.0-2"
[15:00] <pitti> seb128: ok, thanks
[15:00] <seb128> doh
[15:00] <seb128> I was reading the wrong line
[15:00] <seb128>     * i386: evolution-mapi, evolution-mapi-dbg, libexchangemapi-1.0-0, libexchangemapi-1.0-dev, thunderbird-gnome-support, thunderbird-gnome-support-dbg, thunderbird-testsuite
[15:00] <seb128> ok, that didn't change
[15:00] <seb128> Laney, I don't even know what libebml is, what is that one special?
[15:00] <pitti> right, I looked at e-d-s, not -mapi (thakns for pointing out)
[15:01] <Laney> it's just the fist package in the hint for whatever reason
[15:01]  * seb128 is never going to understand how the output stuff works :/
[15:01] <Laney> the lines after that show you the remaining packages, which are the ones you expect it to be
[15:19] <xnox> seb128: pitti: Laney: I see that once samba, thunderbird, and mythtv are fixed - both libav & e-d-s transitions will migrate to release pocket.
[15:19] <seb128> xnox, tb is almost done building on armhf ... what's needed for samba and mythtv? is somebody working on those?
[15:19] <xnox> with mythtv building =)
[15:20] <Laney> sambaaaaa
[15:20] <xnox> seb128: and i'm working on samba4 transitional packages. Although I can upload a hack into samba4 package =)
[15:22] <seb128> shrug
[15:22] <seb128> doko, are you working on fixing python2.7?
[15:25] <doko> seb128, ?
[15:28] <seb128> doko, http://irclogs.ubuntu.com/2013/11/27/%23ubuntu-devel.html#t12:39
[15:28] <seb128> doko, the python2.7 update in trusty is making autopilot and other tools unhappy
[15:29] <seb128> doko, you did see Mirv ping earlier?
[15:31] <doko> no
[15:31] <seb128> doko, :-(
[15:31] <seb128> doko, ok, well can you please have a look to the bug linked in the url I just gave
[15:33] <seb128> doko, thanks
[15:33] <doko> seb128, and it's not an issue with autopilot?
[15:34] <seb128> doko, it's only happening since the python update, downgrading python fixes it ... but if autopilot is doing something wrong that stopped working could you help by telling what it should be doing differently?
[15:34] <doko> seb128, I'll look, but probably not today anymore
[15:38] <seb128> doko, ok, thanks
[15:38] <seb128> hum, something made python-dbus really unhappy on my trusting, it keeps segfaulting (trying to run versions)
[15:39] <lfaraone> Ursinha: I'm still confused by the "Policy: filing bugs…" thread. Is it difficult to file against both if applicable?
[15:39] <lfaraone> its, like, two clicks.
[15:39] <Ursinha> lfaraone, I don't think so
[15:39] <Ursinha> yeah, that, we only need to agree we'd file distro bugs against distro packages, and it seems some people don't agree with that/don't do that
[15:39] <lfaraone> Ursinha: okay. I still think https://lists.ubuntu.com/archives/ubuntu-devel/2013-November/037832.html is a straightforward workflow that would enable you to avoid missing things.
[15:41] <lfaraone> Ursinha: ah, I see. Sigh.
[15:41] <Ursinha> :)
[15:45] <Ursinha> lfaraone, I need to understand why all things that Saviq pointed are like that
[15:45] <Ursinha> there's some confusion when it comes to dealing with launchpad
[15:46] <ogra_> lfaraone, theoretically only ubuntu-bug should be used on official ubuntu images ... that would DTRT
[15:47] <Ursinha> ogra_, what about Saviq not being able to triage distro bugs?
[15:47] <ogra_> (if it doesnt, we need to fix it ... if LP doesnt work for some pepople, we need to fix *that* ... )
[15:47] <Ursinha> yes, agreed
[15:47] <ogra_> Ursinha, his team just needs to be added to the bugsquad
[15:48] <ogra_> no rocket science ... that the reason why we have the bugsquad team
[15:48] <Ursinha> ogra_, I know... is that I don't see your reply to the list saying that's what needs to be done :P
[15:49] <ogra_> Ursinha, because someone had me debug very weird session init behavior :P
[15:49] <Ursinha> ogra_, :P
[15:49] <ogra_> i'll get to my mails later today :)
[15:50] <lfaraone> there's even a policy to add the entire team to bugsquad
[15:52] <ogra_> lfaraone, where we need to get to is that by the time we converge phone/tablet/desktop that the bugtracking is in a state that https://errors.ubuntu.com/ can be used for all in-distro pieces
[15:53] <ogra_> so this is the cycle to sort all the process and policy issues in a proper way
[15:59] <Ursinha> ogra_, +10000 on that
[16:00] <Ursinha> lfaraone, I started that thread so we can all be in the same page
[16:01] <Ursinha> there are established policies that not everyone is aware of, or nobody discussed before if the current process is good enough or not
[16:01] <Ursinha> for specific upstreams
[16:06] <lfaraone> Ursinha: that makes sense.
[16:37] <ogra_> GRRR
[16:37] <ogra_> dear G+ ... stop putting unclosable hangout notifiers into my firefox !
[16:38] <davmor2> ogra_: but how else will they get you to look at the adverts
[16:39] <ogra_> well, there are no ads ... it just shows the hangouts i was in ... as if i wouldnt know to whom i talked
[16:41] <davmor2> ogra_: the amount of hangouts you must be in you probably don't ;)
[16:42] <davmor2> ogra_: it's a subtle reminder to write actions up from the hangout :D
[16:42] <shadeslayer> ogra_: http://www.linuxmint.com/rel_petra_cinnamon_whatsnew.php "System improvements" "APT "recommends" disabled by default."
[16:43] <ogra_> haha
[16:43] <ogra_> lovely
[16:43] <shadeslayer> Indeed
[16:43] <ogra_> as long as they file their bugs against mint ...
[16:43] <seb128> ogra_, well, I wouldn't mind if they were sending some patches our way, never saw one coming from them though
[16:43] <shadeslayer> heh, yeah, but now you can close bugs filed in Launchpad as invalid :P
[16:44] <ogra_> seb128, yeah
[16:44] <ogra_> seb128, instead of telling people that installing security updates make systems unstable ... now *that* will teach your mom how linux is more secure than windows :P
[16:45] <seb128> ;-)
[16:47] <seb128> looking to their screenshots on that NEW, nice UI/design is not their thing
[16:47] <seb128> e.g http://www.linuxmint.com/pictures/screenshots/petra/cinnamon_sounds.png
[16:47] <seb128> wth
[16:47] <seb128> that looks like GNOME1 style
[16:49] <davmor2> seb128: but that's what people want back :)
[16:49] <shadeslayer> ^^
[16:49] <seb128> haha, maybe
[16:49] <seb128> not me at least ;-)
[16:49] <davmor2> seb128: I'm with you
[16:49] <seb128> I can see the ability to configure sound events as useful, the layout of that panel is really not nice though
[16:50] <seb128> small details at least, like they could have showed nice names for the sounds, like stripping the .oga from the display name
[16:51] <ogra_> seb128, thats the mate desktop
[16:51] <ogra_> it *is* gnome2 :)
[16:51] <seb128> ogra_, well, I said GNOME1
[16:51] <ogra_> oh
[16:51] <davmor2> seb128: it will be useful on the Phone what with people grouped ringtones, sms, mms, email........all having seperate tones :D
[16:51] <ogra_> yeah
[17:00] <robru> dholbach, thanks!
[17:38] <infinity> hallyn_: Not suitable for upstream (obviously), but this fixes your arm64/qemu problem for now: http://paste.ubuntu.com/6485441/
[17:39] <infinity> hallyn_: A proper fix would be a series of version comparisons and forcing anything that's "too low" for the target to use the target's stated minimum.
[17:39] <hallyn_> infinity: all very sad, but thanks :)  I wonder if the too-low version info is already in the qemu source somewhere
[17:40] <hallyn_> assume so
[17:40] <infinity> It's not, that I could find.
[17:40] <infinity> But easy enough to whip that up properly, if you bug me another time.
[17:40] <infinity> This small patch should unblock us getting things working in the archive for now, though.
[17:40] <infinity> Plus adding the binfmt magic file, and adjusting postinst to import it.
[18:41] <dobey> where should i be seeing dpkg-gensymbols run, in the build log for a library?
[18:41] <seb128> dobey, in the build log? ;-)
[18:41] <seb128> dobey, if you want to make sure the variable is working, just drop a line from your .symbols and see if the build fails
[18:42] <dobey> seb128: i mean, i am not seeing dpkg-gensymbols at all in the build log
[18:42] <dobey> which seems a bit odd to me
[18:43] <seb128> dobey, dh_makeshlibs
[18:44] <dobey> so i won't see a "dpkg-gensymbols" in the log, if it's not failing?
[18:44] <seb128> dobey, you see a dh_makeshlibs in the build log, which calls dpkg-gensymbols
[18:44] <seb128> gtk+3.0_3.10.5-0ubuntu1_i386.build:dh_makeshlibs -plibgtk-3-0 -Xusr/lib/i386-linux-gnu/gtk-3.0/3.0.0 -V --add-udeb=libgtk-3-0-udeb -- -c4
[18:44] <seb128> dobey, e.g ^
[18:44] <dobey> ok
[18:45] <dobey> i was looking for the gensymbols string
[18:45] <seb128> right
[18:45] <seb128> those helpers wrap things
[18:45] <seb128> usually I've to look to the list of dh_* to remember which one does what I'm looking for :p
[18:46] <dobey> sure. was just hoping to see gensymbols in the log somewhere
[18:46] <seb128> dobey, export DH_VERBOSE=1 I guess if you want to see the details
[18:47] <xnox> dobey: yeah, if it doesn't fail, one doesn't see any commands executed by dh_*
[18:48] <xnox> dobey: hence, i choose to build with export DH_VERBOSE=1 non-trivial / large packages.
[18:48] <dobey> sure
[18:49] <dobey> anyway, i justa dded an invalid symbol to the file, so it should fail this time
[18:49] <dobey> and hopefully i'll see the command line
[20:57] <hallyn_> infinity: new package in ppa:serge-hallyn/virt works.  i'll run the regression testsuite and then hopefully push to trusty
[20:59] <Laney> :-o
[21:01] <infinity> hallyn_: Missing the postinst bit.
[21:02] <hallyn_> hm
[21:02] <infinity> Oh.
[21:02] <infinity>         # list of architectures is autogenerated from debian/rules
[21:02] <infinity> Probably not, then. ;)
[21:02] <hallyn_> right
[21:02] <hallyn_> though i would've believed you since i tested on the vm i'd already hacked up a bit
[21:02] <hallyn_> i can compile hello world.c fwiw :)
[21:03] <hallyn_> anyway i'll set up a clean vm to test once more, and do the regression tests there.
[21:10] <infinity> hallyn_: Once that all seems somewhat sane, can you push it to vagrant as well for Debian, so he doesn't go and duplicate the effort and cause both you and him a headache?
[21:17] <hallyn_> infinity: sure, lemme mention it on #debian-qemu right now
[21:30] <ogra_> infinity, do you have an idea about http://paste.ubuntu.com/6486604/ (on precise)
[21:36] <infinity> ogra_: Try 'apt-get install libshell-perl perl' to see if apt gives more info.
[21:38] <infinity> ogra_: I wonder if you may have a multiarch perl installed that doesn't match your apache arch.  Hard to say without more info, though.
[21:48] <ogra_> infinity, i surely have, i was just verifying some odd mail from ubuntu-users
[21:48] <ogra_> and found they are right that it behaves weird :)
[21:49] <ogra_> aha
[21:49] <ogra_> The following packages have unmet dependencies:
[21:49] <ogra_>  perl-modules : Breaks: libshell-perl (< 0.72.01)
[21:49] <ogra_> looks like this was missed in the perl transition
[21:50] <infinity> Possibly, yeahp.  An SRU of 0.72.01-1 as 0.72.01-0ubuntu1 would fix it up.
[22:59] <mdz> trying to figure out why neither my suspend hotkey nor the suspend menu item works anymore for me in 13.10 on this laptop. I verified that the correct keycode is generated, and that suspending with dbus-send ... org.freedesktop.UPower.Suspend works, so I'm thinking gnome-settings-daemon it at fault? does that sound right?
[23:00] <mdz> seems like g-s-d should be listening for the keycode and sending the appropriate message to upower
[23:01] <sarnold> mdz: how about closing your laptop's lid? that also fails for me (in addition to the menu entry)
[23:02] <mdz> haven't tried that
[23:02] <sarnold> what's the keyboard shortcut for suspending?
[23:02] <mdz> Fn+F4
[23:02] <mdz> just tried closing the lid, does nothing
[23:03] <sarnold> thanks; turns out that also doesn't work for me. :) heh. have you filed a bug yet? I'd love to hit the "me too" button if you've already started :)
[23:03] <mdz> not sure yet where to file the bug, but thinking gnome-settings-daemon
[23:04] <mdz> sarnold, does your menu item work?
[23:04] <mdz> oh, you said not
[23:05] <sarnold> mdz: I was torn between gnome-power-manager, upower, and gnome-settings-daemon too. I just don't know who to blame. :/
[23:05] <mdz> AIUI gnome-power-manager shouldn't be involved in this anymore, it's just UI
[23:05] <mdz> and upower seems to be doing its job when I run dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend
[23:07] <sarnold> mdz: that dbus-send command actually does make my system suspend.
[23:07] <mdz> I'm wondering if systemd-logind has a role to play here
[23:08] <mdz> when I run gnome-settings-daemon --debug --replace and press the sleep hotkey, I only get: (gnome-settings-daemon:1809): media-keys-plugin-DEBUG: Launching action for key type '48' (on device id 14)
[23:08] <mdz> I expected to get an answer from the power plugin, not media-keys
[23:13] <mdz> if i strace systemd-logind, it is logging the suspend keypress but doesn't take any action in response
[23:20] <mdz_> aha! telling systemd-logind to ignore the suspend key fixes it
[23:20] <mdz_> sarnold, perseus:[~] tail -1 /etc/systemd/logind.conf
[23:20] <mdz_> HandleSuspendKey=ignore
[23:20] <mdz_> that does the trick for me
[23:22] <sarnold> mdz: hrm, looks like it needs a session restart to test, I'll get around to it shortly. Thanks for doing the heavy lifting! :)
[23:39] <sbeattie> hrm, that's useful to know