[00:32] <barry> cyphermox: ping, re: dbusmenu (maybe)
[00:32] <cyphermox> barry: pong
[00:33] <barry> cyphermox: after the last update, two of my applications lost their global menu.  iirc there was a new dbusmenu uploaded recently, and i was wondering if that could be the culprit.  the apps are emacs and claws-mail
[00:35] <cyphermox> it's not impossible but it's the second time I hear about this today
[00:35] <cyphermox> not that I do much on dbusmenu ;)
[00:35] <barry> cyphermox: yeah, i was going to ping tedg, but he's offline and you're next on my "hey, i recognize that guy on the dbus menu team" :)
[00:35] <barry> cyphermox: i'm just wondering where i should report the bugs.  reporting them on emacs and claws-mail probably won't get much attention ;)
[00:36] <cyphermox> barry: check if UBUNTU_MENUPROXY is set in your environment
[00:36] <cyphermox> barry: I'd say either unity or libdbusmenu?
[00:38] <cyphermox> barry: I wonder if the correct place for the bug isn't indicator-appmenu
[00:38] <barry> % echo $UBUNTU_MENUPROXY
[00:38] <barry> 1
[00:39] <barry> ;)
[00:39] <barry> (although that's definitely not a new setting)
[00:39] <cyphermox> nah, it's not
[00:39] <barry> cyphermox: i guess it should be set, right?
[00:39] <cyphermox> robru: did you fix that on your system ^ ?
[00:40] <cyphermox> barry: yes, it should be
[00:40] <cyphermox> that just means to use them
[00:40] <cyphermox> (global menus)
[00:40] <barry> i vaguely remember that ;
[00:40] <cjwatson> oh hey, you could fix up the libdbusmenu ftbfs :)
[00:40] <cyphermox> barry: robru asked about this earlier too, but I'm not sure if he fixed it
[00:41] <cyphermox> cjwatson: I could try, but I'd do that only in a few hours
[00:41] <cjwatson> I think it's http://paste.ubuntu.com/7111413/ (following https://bugzilla.gnome.org/show_bug.cgi?id=701638, you might want a different approach, not sure) plus documenting the symbols that it complains about now)
[00:41] <robru> cyphermox, barry no never got it fixed
[00:41] <robru> barry what symptoms are you seeing?
[00:41] <cjwatson> easier with my mp to make the test suite verbose
[00:41] <cyphermox> I'm trying to go to bed very soon, I will need to be up in very few hours
[00:41] <cjwatson> sure
[00:42] <cjwatson> just hoping to hand off one of the zillion things I've been working on today to somebody with more clue about it :)
[00:42] <cyphermox> should be simple enough to fix yeah
[00:43] <barry> robru: both emacs and claws have lost their global menu.  go to the global menubar and the app name never fades into the menu
[00:43] <barry> robru: this definitely worked a few days ago.  those are the only two apps that i've identified so far as busted
[00:44] <cyphermox> cjwatson: ftbfs where? I don't see it in LP or on ubuntuwire?
[00:44] <robru> barry, ok, i'm having the same symptoms on *every* window. I have zero menubar integration right now. luckily the traditional menubars are showing up so apps are usable, just ugly
[00:44] <cjwatson> cyphermox: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20140307-trusty.html
[00:44] <cyphermox> oops
[00:44] <cjwatson> cyphermox: also https://jenkins.qa.ubuntu.com/job/libdbusmenu-trusty-amd64-ci/8/console
[00:45] <barry> robru: interesting.  chromium seems okay
[00:45] <barry> ff seems okay
[00:45] <barry> gtimelog seems okay
[00:45] <robru> barry, lol, chromium is particularly bad, I get a unity titlebar around the chromium window. no menus either. nor ff
[00:49] <barry> robru: have you filed a bug?
[00:49] <robru> barry, not yet, haven't had time to troubleshoot and I wasn't sure if it was something I broke myself (i was tinkering a bit around the time it broke)
[00:50] <barry> robru: naw, it's at least also partially broken for me too.  i'll ping tedg in the morning (if he's around)
[00:50] <robru> barry, ok. please email me the bug and I'll mark it as affecting me
[00:50] <robru> when you do eventually file it ;-)
[00:51] <barry> robru: +1
[01:03] <cyphermox> barry: does gedit not show menus either?
[01:04] <barry> cyphermox: it does
[01:04] <cyphermox> ah
[01:04] <cyphermox> but not firefox and others
[01:05] <cyphermox> I'm mixing things up, sorry, I see, only claws and emacs
[01:06] <barry> cyphermox: well, ff and chrome work for me.  just claws and emacs broken (so far)
[01:25] <TheMuso`> barry: Is emacs using GTK2?
[01:26] <TheMuso`> Firefox works because it has a special plugin to work with the menus... But if emacs is GTK2, there is a chance that other GTK2 apps are broken as well, I assume claws is GTK2 also...
[01:28] <barry> TheMuso`: i bet you're right that both claws and emacs are using tgk2
[01:28] <barry> *gtk2
[01:28] <barry> TheMuso`: hmm, maybe not: libgtk-3-0 (>= 3.2.1)
[01:28] <barry> that's emacs24
[01:29] <TheMuso`> Hrm ok.
[01:29] <barry> claws-mail is though: libgtk2.0-0 (>= 2.24.0)
[01:44] <TheMuso`> barry: Well I have just confirmed its not all GTK2 apps, I just tried one now and menus behave as normal.
[01:50] <barry> TheMuso`: hmm.  okay
[03:21] <infinity> barry: Asking the obvious question, have you logged out or rebooted since your last upgrade?  I've noticed that upgrades to the menu stuff seem to do weird things to active sessions sometimes.
[06:36] <pitti> Good morning
[06:36] <pitti> sarnold: bah, 'connecting to Launchpad failed: unclosed token: line 16399, column 6'; yay
[06:37] <pitti> sarnold: I wonder why that started happening so often; it has worked for years without such cache problems..
[06:37] <pitti> sarnold: thanks for pointing out, restarting
[06:38] <pitti> RAOF: I think you actually want to use umockdev for the recording
[06:38] <RAOF> pitti: Yeah, ish.
[06:39] <pitti> RAOF: otherwise I'd have to add the whole ioctl decoding and evemu .desc parsing/ioctl synthesis
[06:39] <RAOF> Right.
[06:39] <pitti> RAOF: so with umockdev being able to record and read .events files it should be fine, right?
[06:39] <RAOF> Yeah, mostly.
[06:39] <pitti> RAOF: ah, what's missing?
[06:39] <pitti> RAOF: ioctls should  be fine
[06:40] <pitti> (on same endianess, anyway)
[06:40] <RAOF> It just kinda irks me that if I change the order, or set of ioctls that I use, I need to re-record.
[06:40] <RAOF> (Not that I've had to do that, just reading the code that's what I think happens)
[06:40] <pitti> RAOF: no, umockdev's recorded ioctls don't need to be replayed in order
[06:41] <RAOF> Ah, sweet. I guess I mis-skimmed the code.
[06:41] <pitti> RAOF: in fact, evdev ioctls are all independent from each other, so you can call them in any order and any number you like
[06:41] <RAOF> pitti: In which case I could probably just umockdev evemu-record, right?
[06:41] <pitti> RAOF: .record must exactly match the original; .ioctl is a tree
[06:41] <pitti> RAOF: well, yes; it's a bit redundant, though :)
[06:42] <RAOF> pitti: Only if you've already implemented the ability to record .events as well as replay them :)
[06:42] <pitti> RAOF: so, I'll clean up .events reading this morning and then look into .events writing; that should be fairly easy
[06:42] <RAOF> Bitchn'
[06:42] <pitti> reading is more work (that's why I started with that)
[06:42] <RAOF> Ah, cool. Thanks muchly!
[07:20] <pitti> RAOF: does that description make sense to you, or is it confusing somehow? http://paste.ubuntu.com/7112693/
[07:25] <pitti> RAOF: refined: http://paste.ubuntu.com/7112707/
[07:34] <pitti> zul: apparently the new python-taskflow is missing some new dependencies? (autopkgtest failure)
[07:50] <pitti> cjwatson: pkgbinarymangler fixed; it was an actual regression, but a corner case (handling of files containing '%'); bash 4.3 apparently got a stricter escaping behaviour
[08:03] <Noskcaj> mlankhorst, Would you mind fixing the libgphoto b-dep of wine1.6?
[08:31] <dholbach> good morning
[08:38] <mlankhorst>  morning
[09:31] <RAOF> pitti: Description looks good. Is there any way we can shoe-horn a default-device into the evemu format? :)
[09:31] <cjwatson> pitti: thanks
[09:31] <pitti> RAOF: the documentation doesn't document it; but I'd expect "# comment" lines to work
[09:32] <pitti> RAOF: (i. e. they work with umockdev, not sure if they work with evemu itself)
[09:32] <RAOF> Yeah, they won't work with evemu, because it doesn't make sense - evemu creates a new uinput device to replay through.
[09:32] <pitti> RAOF: I mean if evemu will ignore comment lines
[09:33] <RAOF> Oh, right.
[09:33] <RAOF> Eh.
[09:33]  * RAOF is not particularly interested in that.
[09:33] <pitti> RAOF: I just don't want to claim "it writes an evemu .events file" when that file can't be used with evemu
[09:34] <pitti> RAOF: ah, seems it does
[09:34] <pitti> i. e. '#' comments are fine
[09:36] <RAOF> Sweet.
[09:50] <Saviq> diwic, hey, question about the "what did you plug in" dialog: I have a combo jack (Dell Latitude E6420), but I never get the dialog, nor do I ever actually get mic input from the headset, is there something I could provide you with that needs to be added to some hw quirks or something to fix that?
[09:51] <diwic> Saviq, sure, start with alsa-info: https://wiki.ubuntu.com/Audio/AlsaInfo
[09:52] <Saviq> diwic, http://www.alsa-project.org/db/?f=449823acea2249ba25ab19e793c91858f4965769
[09:53] <Saviq> diwic, want me to file a bug (against ?) with that?
[09:53] <diwic> Saviq,
[09:53] <diwic> Kernel release:    3.11.0-12-generic <- any reason you're not running a 3.13 kernel?
[09:54] <Saviq> diwic, good question, no
[09:55] <Saviq> hmm update-grub doesn't find the kernel...
[09:55] <Saviq> ah, 'cause it's not there, must've dropped linux-generic at some point
[09:55] <diwic> Saviq, and second, your machine is not one of the affected ones, at least not at this point...is it Certified/Enabled by Canonical?
[09:56] <Saviq> diwic, yeah http://www.ubuntu.com/certification/desktop/models/?query=6420&category=Desktop&category=Laptop&level=Any&release=
[09:57] <Saviq> diwic, they're not *exactly* like mine is - I've nVidia with Optimus
[09:58] <mardy> cjwatson: hi! About https://code.launchpad.net/~cjwatson/libaccounts-glib/multiarch/+merge/211468, it's the first time I see Multi-Arch so my question might not make much sense:
[09:58] <mardy> cjwatson: don't we need a similar line for the -dev package?
[09:58] <diwic> Saviq, so it's a computer from 2010? Has the Mic worked in previous releases?
[09:59] <Saviq> diwic, yeah, it's an old one, and I can't say that it ever worked
[10:00] <Saviq> diwic, it's definitely only using the internal mic now
[10:00] <Saviq> diwic, I can try  a live saucy if you'd like
[10:01] <diwic> Saviq, when you submitted the alsa info, was a headset plugged into the jack?
[10:01] <Saviq> diwic, no, let me
[10:02] <Saviq> diwic, does it matter what do I plug in? i.e. headset vs. headphones?
[10:02] <diwic> Saviq, yes
[10:03] <diwic> Saviq, if I understand you correctly, plugging in headphones works as it should, whereas plugging in a headset you can't use the headset's mic?
[10:03] <Saviq> diwic, yes
[10:04] <Saviq> diwic, this is with a headset http://www.alsa-project.org/db/?f=b661fa1c8d2824b76db10b5cc4e20ebfab6b93aa
[10:05] <diwic> Saviq, ok, so in your case it does not detect the headset mic, although the hardware claims it should be able to.
[10:06] <cjwatson> mardy: it would be nice to get that far, but it isn't required.  I haven't worked out whether the files in the -dev package are multiarch-safe (any files in paths that are common between architectures must be bitwise-identical on all architectures)
[10:06] <cjwatson> mardy: let me have a quick look at that if you want
[10:06] <diwic> Saviq, at this point I think your best workaround is to use hdajackretask (in the alsa-tools-gui package) and remove jack detection for the headset mic pin
[10:07] <diwic> Saviq, that probably won't give you a dialog (I think...), but should enable you to manually select mic in sound settings
[10:08] <cjwatson> mardy: so, I *could*, but it would be futile; it depends on gir1.2-accounts-1.0, and /usr/lib/girepository-1.0/Accounts-1.0.typelib in that package has different contents on different architectures
[10:09] <cjwatson> mardy: since this isn't required to make "click chroot" work, I'd rather leave that problem for another day
[10:09] <cjwatson> (well, strictly, to make "apt-get install ubuntu-sdk-libs-dev:armhf" work)
[10:13] <cjwatson> mardy: by the way, I see there's a new upstream in trunk - is that planned to land for trusty, or should I be looking at doing a direct upload of this to the archive based on what's in trusty now?
[10:13] <Saviq> diwic, hmm indeed, got it to show up, but still no input (tried with an android/iOS ↔ nokia adapter, too, just to check)
[10:13] <mardy> cjwatson: thanks, I see there's little point in doing that
[10:14] <cjwatson> mardy: https://wiki.debian.org/Multiarch if you want background on multiarch, maybe https://wiki.debian.org/Multiarch/Implementation in particular
[10:14] <diwic> Saviq, ok, assuming you have increased the gain (it's quite low in your latest alsainfo) then maybe a hardware failure
[10:14] <Saviq> diwic, yeah, I up'ed it to 100%, no go
[10:15] <Saviq> diwic, so, I'll have to check if windoze let's me work with it, then, will do, thanks!
[10:15] <Saviq> lets
[10:15] <diwic> Saviq, ok!
[10:16] <mardy> cjwatson: I'd like to land the new version in trusty, yes. So I think we'll take care of landing it.
[10:16] <cjwatson> ok, great, thanks
[10:17] <cjwatson> Laney: are you likely to be able to land https://code.launchpad.net/~cjwatson/ubuntu-system-settings/arch-any/+merge/211426 today?  it's blocking several things in -proposed
[10:18] <Laney> cjwatson: Sure, I can do
[10:18] <mardy> dbarth: hi! Can you make https://code.launchpad.net/~cjwatson/libaccounts-glib/multiarch/+merge/211468 land?
[10:18] <Laney> seb128: ^ doing that on its own to unblock stuff, okay?
[10:19] <seb128> Laney, no, please wait
[10:19] <Laney> why?
[10:19] <seb128> Laney, I've some trivial changes for the wizard I want to include
[10:19] <Laney> could do another one ...
[10:19] <Laney> but okay, you do it
[10:19] <seb128> those can't bug anything, the wizard is not used
[10:19] <seb128> ok, sure
[10:19] <seb128> it just feels like we could batch them
[10:20] <seb128> but go ahead if you want, I can do another one later
[10:20] <seb128> cjwatson, just curious, how is u-s-s blocking things? it shouldn't have much rdepends
[10:20] <seb128> oh, I guess it's the online account panel needed it, and that one has rdepends
[10:21] <dbarth> mardy: hi
[10:21] <cjwatson> seb128: {clickmanager-plugin, ubuntu-purchase-service} -> ubuntuone-credentials -> ubuntu-system-settings-online-accounts -> ubuntu-system-settings
[10:22] <seb128> cjwatson, right, online-accounts, thanks ;-)
[10:22] <cjwatson> I mean it's all stuff nothing needs yet but I still want to keep the list short
[10:22] <seb128> right
[10:22] <seb128> Laney, well, your call, feel free to land it now if needed, I can put another landing in a few hours for the one things on the backlog
[10:22] <dbarth> mardy: will add to the silo
[10:23] <mardy> dbarth: thanks!
[10:23] <Laney> seb128: thanks, I will do so that proposed can clear out
[10:23] <seb128> Laney, thanks
[10:23] <dbarth> mardy: added line 13, along with the rest of the online accounts MPs
[10:23] <Laney> well, they are in firefighting mode again so you never know ...
[10:24] <dbarth> mardy: it's a no-op on desktop, but we will need to re-test on the phone with all of the recent changes
[10:25] <cjwatson> Laney: they're being fairly good about letting through obvious packaging adjustments, so far anyway
[10:25] <Laney> Yeah, but there's a new problem today in that the images don't boot, apparently. :P
[10:25]  * Laney goes to ask anyway
[10:28] <Laney> bah, I can't cross-build system-settings any more
[10:29] <Laney> http://paste.ubuntu.com/7113317/
[10:31] <seb128> qt5.2 regression?
[10:32] <Laney> sec
[10:41] <xnox> slangasek: bdmurray: updated app-install-data-ubuntu uploaded. But we also need updated "command-not-found" data, which is separate?! I'm not sure how that is generated.
[11:23] <zul> pitti: ack
[11:32] <Laney> ah I think it's the M-A: foreign on qt5-qmake
[11:33] <Laney> it now installs stuff in triplet-namespaced locations
[11:35] <Laney> http://anonscm.debian.org/gitweb/?p=pkg-kde/qt/qtbase.git;a=commitdiff;h=dd85a4c4d6eb19a01e75959d4725f7298b63b852;hp=c5a1ab594b27738adec10d346def2bc71b23f58f
[11:40] <cjwatson> Laney: yeah, I noticed the M-A: foreign seemed wonky given the paths
[11:44] <Laney> It looks like it could be made M-A: same
[11:46] <Laney> assuming the manpage compresses the same way, I guess
[11:46] <Laney> Mirv: ^ wdyt?
[11:48] <Mirv> Laney: looks like :same to me now that the mkspecs were moved
[11:49] <Mirv> MR:s welcome, there's one new qtbase upload being prepared in CI Train already
[11:50] <Laney> ok, if we check coinstallability explicitly
[11:57] <Laney> Mirv: how does it work with the source package?
[11:57] <Laney> do I add a changelog entry?
[11:57] <Laney> I'd expected to see stuff merged into the packaging branch but there is nothing there
[12:04] <Mirv> Laney: full changelog entry at all, propose against https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src and CI will run tests and merge after top-approving
[12:04] <Mirv> s/at/and/
[12:05] <Mirv> at the same time, it can be uploaded to a landing PPA via CI Train, but it's not possible right now since qtbase is already being released via CI Train (ETA 1-2 hours)
[12:05] <Laney> ok
[12:07] <Mirv> Laney: so, umm, maybe merge in lp:~timo-jyrinki/kubuntu-packaging/qtbase_sync_from_archives_and_add_harfbuzz_patches first since it's likely to go in, and prepare ubuntu10 upload
[12:08] <Mirv> there was yet another upload by ricardo in the morning without CI involved
[12:12] <Laney> Mirv: ok, there it is & requested your review
[12:12] <Laney> let me know when it's up & built so that I can test it out
[12:18] <Mirv> Laney: thanks, I will
[12:30] <apachelogger> tseliot: bug 1291526  ... what I don't get, why would it run into an xioerror when prime selecting nvidia, but not when using intel?
[12:40] <Mirv> Laney: bzr is choking on your changelog entry, the time stamp is mangled (missing '0')
[12:40] <Laney> oops
[12:40] <Laney> it probably got damaged in the merge
[12:40] <Laney> there was a conflict of course
[12:41] <Laney> Mirv: try that
[12:41] <Mirv> works
[12:43] <Laney> Riddell: I'm getting reject emails from this merge proposal I just made
[12:44] <Laney> Can you maybe make them be discarded instead? Or better have a code review list where they are accepted
[12:44] <Riddell> Laney: from kubuntu-devel?
[12:44] <Laney> yes
[12:44] <Laney> I guess because kubuntu-packagers had a requested review
[12:47] <Riddell> Laney: unfortunately merge request have an implicit destination so I don't think there's a way to have mailman accept them automatically
[12:53] <Laney> Riddell: AFAICS the best you could do would be to add a spam filter for it
[12:54] <Laney> those can match any header
[12:54] <Laney> For example you could match on X-Launchpad-Message-Rationale: Reviewer @kubuntu-packagers
[13:29] <jamespage> I can't quite believe I've not had todo this before but what's the right way to move upstart configs between files at the same time as renaming them?
[13:30] <barry> cyphermox: an update and reboot seemed to bring back the global menu for claws at least.  not for emacs (but a menu bar is kind of an anathema for that anyway :)
[13:34] <cyphermox> barry: good :)
[13:59] <Mirv> release team acked bug #1207812 so if anyone ready for an upload please sponsor the branch I prepared during my patch pilot turn
[14:04] <seb128> Mirv, I can do that
[14:06] <Mirv> seb128: thanks.
[14:06] <seb128> Mirv, yw, thanks for working on the update ;-)
[14:10] <cjwatson> tjaalton: do you think you could sort out the libxmlrpc-c3-dev reverse-build-deps on http://people.canonical.com/~ubuntu-archive/nbs.html ?  I assume they need to be libxmlrpc-core-c3-dev now, but I don't really now
[14:10] <cjwatson> *know
[14:11] <cjwatson> tjaalton: (you can probably ignore tcos; it seems to have Build-Depends: libxmlrpc-c3-dev | libxmlrpc-core-c3-dev already)
[14:11] <tjaalton> cjwatson: okay
[14:11] <cjwatson> thanks
[14:11] <tjaalton> seems I missed the old names
[14:12] <tjaalton> although.. *cough* it failed to build on arm64/ppc64el
[14:12] <cjwatson> what did?
[14:12] <tjaalton> no wait
[14:12] <cjwatson> https://launchpad.net/ubuntu/+source/xmlrpc-c/1.33.06-0ubuntu1 looks fine
[14:12] <tjaalton> that got fixed by itself?
[14:12] <tjaalton> oh good
[14:12] <cjwatson> maybe it was transient
[14:13] <tjaalton> yeah it was weird
[14:13] <tjaalton> some test failed
[14:49] <tedg> slangasek, url-dispatcher didn't officially get added to the touch FFE, do you think we can add it?  bug 1208989
[15:01] <cjwatson> GunnarHj: mythes-sv is stuck in trusty-proposed because it builds uninstallable binaries on arm64 and ppc64el.  You'll probably end up with something similar in Debian.  Would it perhaps be worth an artificial build-dependency on libreoffice-dev (or something like that) so that you only build on the architectures that have libreoffice?
[15:02] <cjwatson> GunnarHj: Or maybe the binary package should be Architecture: all (which would avoid this problem)?  It doesn't seem to do anything in its build phase
[15:11] <Laney> cjwatson: Already fixed, see -2
[15:12] <cjwatson> Laney: oh right
[15:15] <pitti> cjwatson: right, I uploaded -2 to Debian, will sync once it gets imported
[15:16] <cjwatson> ta
[15:47] <Saviq> Mirv, xnox, bug #1294186, otherwise we'll never get it done...
[15:49] <Laney> Saviq: I have that fix building in a silo now
[15:49] <Laney> well, potential fix
[15:50] <Saviq> Laney, oh, great
[15:50] <Laney> we'll see, it might need extra fixes for looking up too
[15:51] <ritz> wtf, my precise boot up shows a debian logo on vm
[15:51] <ritz> when did this happen
[15:52] <heath> I'm wanting to write an app which utilizes the play/pause, prev, next, and volume buttons on my macbook. Tips on where to get started?
[15:53] <ritz> heath,  configure the shortcuts keys
[15:53] <ritz> why write an app ?
[15:53] <ritz> assuming linux understands the keys
[15:54] <Saviq> heath, they should be delivered to your app as XF86Audio* keys, see http://wiki.linuxquestions.org/wiki/XF86_keyboard_symbols
[15:55] <heath> ritz: If there are multiple running apps which utilize the media keys, which one has preference?
[15:55] <GunnarHj> cjwatson: Thanks for your head up re mythes-sv!
[15:55] <Saviq> heath, so yeah, for Ubuntu it's rather different, you need to connect to the sound indicator which takes the keys
[15:55] <cjwatson> Sorry it was a duplicate one
[15:56] <Saviq> heath, http://askubuntu.com/questions/7342/how-do-i-integrate-an-application-in-the-sound-menu-using-python should get you started
[15:57] <ritz> heath,  whichever you configure the shortcuts for
[15:57] <ritz> or write a script to be called upon multimedia keys
[15:57] <ritz> heath, http://askubuntu.com/questions/48393/how-to-make-the-keyboard-media-keys-to-work-with-vlc-globally
[16:03] <heath> That's a neat link ritz
[16:04] <heath> Saviq: I'll definitely be utilizing your link
[16:04] <heath> Thanks
[16:05]  * heath wonders if it's possible for a web app to connect to the sound indicator
[16:06] <heath> Hrm, if youtube can be integrated, then yes
[16:15] <hallyn> xnox: jodh: I went ahead and filed bug 1294200
[17:12] <Laney> Mirv: this is no good
[17:12] <Laney> It wans to reference an armhf uic
[17:33] <bdmurray> juliank: I've made uploaded another change to python-apt it seems slangasek and I missed a bit
[17:35] <juliank> bdmurray: Thanks for letting me know. I also have some patches in upstream git, I'll do a 0.9.3.4 release soon.
[17:36] <xnox> Laney: qmake doesn't know how to reference "built_arch" tools, cmake does.
[17:36] <xnox> Laney: that's a known bug I haven't fixed yet.
[17:36] <juliank> Bug fixes only of course (yes, I'm counting uncompressed data.tar support as a bug fix)
[17:36] <Laney> xnox: It is using cmake
[17:37] <juliank> bdmurray: It's a bit unfortunate to only have non-public errors.ubuntu.com resources in the changelog. I cannot seem them at all
[17:38] <juliank> The bug fix seems strange
[17:39] <xnox> Laney: oh.
[17:40] <bdmurray> juliank: here is the traceback http://pastebin.ubuntu.com/7115343/
[17:41] <Laney> xnox: Qt5WidgetsConfigExtras.cmake looks for host arch tools
[17:41] <Laney> Dunno how to fix that
[17:43] <juliank> bdmurray: I believe a better fix would be to change parse() to not generate bytes strings.
[17:43] <juliank> in self.comment
[17:45] <juliank> It looks like parse() was called with a bytes string (that is, not read using the SourcesList class). In such a case, we need to decode the line if it is not unicode already (once in __init__ and once in __parse__, to make sure)
[17:46] <xnox> Laney: in cmake itself, i added a whole bunch of overrides for all the tools to look for correct arch tools, when building under environment like the one exported by dpkg-architecture -aarmhf-c
[17:46] <xnox> Laney: maybe i need to fix/tweak those. Do you have an easy/simple reproducer for me to iterate with?
[17:46] <bdmurray> juliank: okay
[17:48] <Laney> xnox: landing-001 ppa, cross-build ubuntu-system-settings
[17:49] <Laney> xnox: I'm guessing you want a similar override to those cmake ones in this file then
[17:51] <juliank> bdmurray: This is still Python 2 code? It also crashes for me in another location in Python 3 with a simple test line in bytes.
[17:54] <xnox> Laney: i'll look into it.
[17:54] <xnox> Laney: probably not tonight though, need to finish on time today.
[17:54] <Laney> nm
[18:00] <juliank> bdmurray: Have you checked whether your fix actually work. I believe the problem is more that we now return a unicode object in __str__, causing it too fail afterwards because builtin str() tries to convert the unicode to str.
[18:01] <juliank> There's not much we can do about that, except for adding __unicode__ and changing the other code to use __unicode__ instead.
[18:01] <juliank> or using python 3 instead of 2.
[18:03] <Laney> xnox: oh, I added some rules which make it work
[18:03] <bdmurray> juliank: not that specific change no, I've had a hard time recreating this specific dist upgrade errors with sources list
[18:03] <xnox> Laney: cool, i'll probably will snitch them to keep cmake just working for all packages.
[18:04] <Laney> xnox: I added them to that MultiArchCross.cmake file
[18:04] <Laney> lemme get a diff
[18:04] <Laney> it just copies ones that are already there for some new tools
[18:04] <Laney> or newly-moved, what evs
[18:05] <juliank> bdmurray: I'm probably going to commit http://paste.debian.net/88436/ for this. It decodes byte strings to utf-8 and encodes the internal unicode to utf-8 if you call str() in Python 2 or bytes() in Python 3
[18:06] <juliank> It even has a test case for both bytes and unicode.
[18:07] <juliank> Not only that, it even contains a German word.
[18:09] <bdmurray> juliank: okay, great.
[18:12] <infinity> jodh: Any hope of my chroot-sessions bug being fixed pre-beta?
[18:13] <infinity> jodh: It's amazingly noisy on machines that set up and tear down chroots constantly (*cough*buildds*cough*)
[18:26] <Laney> xnox: bug #1294186 - please review the debdiff when you have time
[18:26] <juliank> bdmurray: Actually, instead of using unicode everywhere, even if not needed in python 2, how about simply opening the files in utf-8 in Python 3, and keeping the Python 2 code in bytes strings? I think this would work better, as that's the way we handle it everywhere else in the code.
[18:43] <juliank> bdmurray: I now (locally) reverted the unicode patch and added http://paste.debian.net/88438/ instead; which only forces utf-8 in Python 3.
[18:44] <juliank> It seems to work just fine in both Python 2 and 3 with the test case and has minimum impact.
[18:47] <juliank> We would not have those problems if people did not write files in an UTF-8 environment and then run reading code in a non-UTF-8 environment like C instead of C.UTF-8
[18:49] <juliank> apt_pkg.size_to_str() is broken in a non-unicode environment as well, BTW.
[19:09]  * juliank is waiting for his CI to start & complete
[19:50] <juliank> bdmurray: I have reverted the unicode change in upstream git for now. I'm not sure what I really want to do. Just hardcoding UTF-8 seems wrong. People might run in a non-UTF-8 locale, and things would break then. I have looked at the other code and we do not assume seem to assume UTF-8 for TagFile, but rather use the default encoding there as well (right, cjwatson?). I'd much prefer if code that sets a wrong locale like aptdaemon just gets f
[19:50] <juliank> ixed instead.
[19:50] <juliank> This way everyone can use the encoding they prefer.
[19:53] <juliank> Python 3 uses the LANG environment variable to determine file encoding.
[19:54] <bdmurray> juliank: it looks like the release upgrader sets the following - locale.setlocale(locale.LC_ALL, "")
[19:55] <juliank> Which just is the default encoding. But someone must set it to a non-unicode encoding before running it, otherwise things would not break.
[19:56] <juliank> locale.setlocale() seems to not influence the default encoding, BTW
[19:56] <juliank> It will determine that during startup AFAICT
[19:56] <juliank> It=Python 3
[22:55] <lamont> why is it that after I unlock my screen, it generally re-locks the first time?
[22:55] <UserError> lustre adds 10~ MB to kernel size
[22:57] <infinity> lamont: Because reasons.
[22:57] <infinity> lamont: There's already a bug (or three) filed about it.
[23:00] <lamont> infinity: cool
[23:27] <UserError> Why are there so many ARM platforms in the libsound2 package? It keeps growing with bloat.
[23:27] <UserError> ALSA-know is that ain't right
[23:28] <infinity> UserError: It's 204k of text files.
[23:29] <UserError> the /usr/share/alsa/ucm/ dir is complete trash
[23:30] <infinity> "complete trash".  Thanks for your input.
[23:30] <UserError> for x86 platforms
[23:30] <infinity> It's 204k of text files.
[23:30] <UserError> it doesn't belong
[23:30] <infinity> Also, it's 204k of text files.
[23:30] <UserError> it has existed for years
[23:30] <infinity> Your crusade, and the language used to fight it, aren't going to win you any friends.
[23:31] <UserError> I know, it really bytes
[23:36] <UserError> in 12.04 it was 120K. That is almost a +100% growth from LTS to LTS.
[23:37] <infinity> It's tiny either way.
[23:37] <UserError> also that means that writes are being used against NAND, SSD, and eMMC storage for 4k blocks
[23:38] <UserError> Now, multiply that by the number of devices and SSD servers that exist
[23:41] <infinity> You're making and argument for removing every package from the archive.
[23:41] <infinity> Wouldn't want to write to those precious disks and harm them.
[23:42] <UserError> and EC2 instances, Azure (copied from EC2) and OpenVZ appliance (proxmox too)
[23:42] <UserError> I understand why certain things are there for supporting hardware. I do not understand files there for impossible reasons.
[23:42] <infinity> None of those should have libasound2 installed in the first place.
[23:42] <infinity> The simple answer to your question is because it's an arch:all package, and includes support for *drum roll* all arches.
[23:43] <infinity> And, curiously, ARM seems to be the only arch that leverages UCM sanely, so it's the only one that ships a bunch of (tiny) UCM profiles.
[23:43] <UserError> and yet the container profile for ubuntu minimal VM still has plenty of modules that shouldn't be there
[23:43] <UserError> I agree there.