[00:10] <ClientAlive> Is there anywhere on my local computer or the internet to get information about window properties? Properties is probably not the right word, but what I need to find out is what the global identifiers are for things like an active window, an inactive window, a maximised window, a minimised window, and so on. Any info can give would be appreciated.
[00:11] <sarnold> ClientAlive: investigate xwininfo
[00:11] <ClientAlive> sarnold: thx. will do
[00:12] <sarnold> ClientAlive: oh! also xprop
[00:12] <ClientAlive> sarnold: Oh, that's coool...  :>
[00:13] <sbeattie> there's also xlsclients
[00:14] <sbeattie> (but xprop's attempt at ansi-text'fying an app's icon is pretty cute)
[00:15] <ClientAlive> sbeattie: no kidding
[00:17] <ClientAlive> Hey, I'm screwing around with devilspie and all/every window is opaque so it is hard to work/read. I want this, but I also need to make the active window ( whichever one happens to be active at the time ) to be solid/not opaque. To solve the immediate problem, what condition could Itest agains in order to select the active window?
[00:17] <ClientAlive> I sure sure would appreciate it.
[00:17] <ClientAlive> Then I can move along on my own
[00:19] <ClientAlive> sbeattie: ? sarnold: ?
[00:21] <ClientAlive> Problem is, I don't see that particular information with xwininfo or xprop
[00:21] <sarnold> ClientAlive: no idea, sorry
[00:21] <ClientAlive> k
[00:22] <sarnold> ClientAlive: if devilspie lets you find e.g. _NET_WM_STATE_FOCUSED in _NET_WM_STATE you might be able to match on that
[00:23] <sarnold> but I've never tried devilspie before
[00:23] <ClientAlive> sarnold: It's a start. thx
[00:26] <ClientAlive> It's test conditions seem to correspond to things like : class; xid; role; property; name; workspace   not sure what category _NET_WM_STATE would fall under ( ir any ).
[05:36] <pitti> Good morning
[05:36] <pitti> l
[05:37] <pitti> sarnold: right, the amd64 one crashed; restarted
[05:39] <mmazing> i'm looking to learn more about how the dbus system works, can anyone recommend a book/website that can help out? there doesn't seem to be much out there, im trying to break down the datetime-indicator-service but it's a bit complicated and i'm just recently jumping back into C development
[05:52] <pitti> stgraber: can I somehow convince lxc to put ephemeral overlays on /tmp/ (or another tmpfs)? putting them on the real HD makes things rather slow (aside from the HD wearout/fragmentation)
[05:55] <mmazing> answered my own question i think : package libdbusmenu-gtk-doc
[05:57] <mmazing> maybe not :\
[05:58] <pitti> mmazing: if you want to learn about the general D-BUS concepts, http://dbus.freedesktop.org/doc/dbus-tutorial.html is the place to start
[05:58] <mmazing> thanks pitti
[06:14] <sarnold> pitti: good morning :) thanks!
[06:18] <RAOF> pitti: How would you feel about having umockdev_load_from_file/string/etc return an array of udev sysfs paths rather than a boolean?
[06:23] <pitti> RAOF: well, it's not a "rather than", as the array of paths needs to become a new (out) argument; so the success flag should still stay
[06:23] <pitti> RAOF: feels API-breaky to me, but if it's particularly helpful for some use case we can certainly do it
[06:23] <pitti> it's not yet that widely used
[06:25] <RAOF> I'm not entirely sure if that's what I want, either.
[06:25] <pitti> RAOF: thanks for your pull requests, looking at them now
[06:25] <pitti> RAOF: btw, if you add NEWS entries they can be merged fully automatically
[06:26] <RAOF> pitti: Ah, let me do so then.
[06:26] <pitti> RAOF: I can add them during the merge this time, no worries (although github supports push -f just fine)
[06:31] <RAOF> I should probably make testbed_remove send "remove" uevents, too, for symmetry.
[06:32] <pitti> RAOF: I merged the DEVNAME one, and put a qestion on the uevent one
[06:33] <RAOF> Sure, I can add a test.
[06:34] <pitti> or, probably, change an existing one to ensure that the uevent is received
[06:34] <pitti> RAOF: so, for the "return sysfs paths" thing, what's your use case for that?
[06:35] <pitti> RAOF: usually you know which devices in your dump you want to work with, and if you load an unknown dump my feeling is that you usually want to use the libudev enumeration/filtering functions to find what you are looking for?
[06:36] <RAOF> I think what I want to do is ship foo.umockdev and foo.ioctl, and have a load_stuff("foo") call that loads them in, etc.
[06:37] <RAOF> I was thinking of the return sysfspath thing so that I could trigger uevents, but it's better to just get umockdev to trigger those events.
[06:37] <pitti> ah
[06:37] <pitti> yes, that's much easier then
[06:55] <pitti> mlankhorst: hey, how are you?
[06:56] <pitti> mlankhorst: can you please upload the various xserver-*-lts-{quantal,raring,saucy,trusty} metapackages to trusty soon which move people back to the normal trusty stack?
[06:56] <pitti> mlankhorst: upgrades are still broken (e. g. https://jenkins.qa.ubuntu.com/view/Trusty/view/All/job/upgrade-ubuntu-precise-trusty-desktop-lts-quantal-i386/11/artifact/results/bootstrap.log)
[07:47] <pitti> mlankhorst: I filed bug 1278737 about that and tentatively assigned it to you, IIRC you work on the enablement stacks? If not, please re-assign to someone more appropriate
[07:47] <pitti> jibel: ^ FYI (for tracking)
[08:11] <spineau> Good morning, I need someone to process a sync request for checkbox please: bug 1278747
[08:34] <dholbach> good morning
[08:37] <spineau> dholbach: Good morning, may I ask you to process a sync request (for checkbox)?
[08:38] <spineau> it's bug 1278747
[08:38] <dholbach> hi spineau
[08:39] <dholbach> spineau, I'll take a look at it in a bit
[08:39] <spineau> dholbach: thanks a lot
[08:39] <mlankhorst> pitti: yeah ok :P
[08:40] <pitti> mlankhorst: good morning; thanks!
[09:05] <Laney> @pilot in
[09:20] <mlankhorst> pitti: if you want to test, just a second
[09:20] <darkxst> Laney, Hi
[09:20] <Laney> hiya
[09:20] <darkxst> since you piloting can you take a look at gcc vanilla MP?
[09:21] <Laney> where?
[09:22] <darkxst> Laney, ubuntu-desktop branch
[09:23] <darkxst> lp:~darkxst/gnome-control-center/vanilla
[09:24] <Laney> dude
[09:24] <Laney> using gcc like that is confusing
[09:25] <Laney> but if it is what it sounds like then I might punt to robert_ancell :-)
[09:30] <mlankhorst> pitti: can you add a ppa for testing?
[09:30] <pitti> mlankhorst: yes, when doing it manually
[09:31] <mlankhorst> hold on a sec, I should be able to upload oldxorg shortly
[09:31] <infinity> Laney: On man, I absolutely thought he meant GNU Compiler Collection.
[09:32] <infinity> darkxst: g-c-c, not GCC, if you want to avoid heart attacks.
[09:32] <Laney> infinity: No need to worry, I'd have blindly sponsored it anyway. :)
[09:32] <infinity> Laney: You desktop people scare me.
[09:32] <Laney> "YOU AREN'T A CORE-DEV?" DEBSIGN DPUT
[09:33] <pitti> "it starts with g*, must be desktop"
[09:34] <mlankhorst> pitti: I copied the oldxorg pkg to ppa:canonical-x/x-staging
[09:35] <seb128> pitti, it's why the kernel is a kubuntu thing, right? ;-)
[09:35] <pitti> seb128: yeah; and you already lost one of your pets when glibc got renamed to eglibc..
[09:35] <infinity> seb128: No, we cleverly made the source package start with 'l' to avoid that.
[09:35] <Laney> edubuntu claimed that one
[09:35] <pitti> seb128: besides, lubuntu (it's linux, not kernel)
[09:36] <infinity> Also, we have too many flavours.  Somene seems to be able to claim every letter.
[09:36] <seb128> pitti, infinity: oh, right ;-)
[09:36] <rbasak> Time to invent more letters. Unicode FTW.
[09:37]  * infinity renames glibc to ☭libg.
[09:37] <Laney> μbuntu
[09:37]  * pitti registers ƃɹo˙nʇunqn
[09:38] <seb128> 可u般你他去
[09:39] <pitti> mlankhorst: thanks! I'll wait until it's built and published and then test
[09:39] <mlankhorst> it almost finished building empty files. :P
[09:39] <infinity> I really wanted to that be code-of-conduct violating.  Google Translate let me down.
[09:39] <mlankhorst> oops.. needs multi-arch: same..
[09:40] <infinity> Also, Google's "did you mean?" sugestions for Chinese are hilariously awful.
[09:40] <pitti> mlankhorst: err, does it? they are arch:all, aren't they?
[09:40] <infinity> "Did you mean: 可u盘你他去"
[09:40] <infinity> "U disk you can go to him"
[09:40] <pitti> looks exactly the same to me
[09:40] <infinity> Thanks, Google.  That's exactly what I meant.
[09:40] <mlankhorst> pitti: hm no it should be arch: amd64 i386
[09:41] <mlankhorst> because we don't want to break upgrading libgl-mesa etc
[09:41] <mlankhorst> or end up with a 32-bits xserver on amd64! :D
[09:52] <tvoss> pitti, https://code.launchpad.net/~thomas-voss/process-cpp/add_death_observer_for_child_processes/+merge/204629
[10:06] <mlankhorst> pitti: ok pushed, can you check if it works? also can you check if /usr/lib/xorg/protocol.txt exists after upgrading?
[10:11] <pitti> mlankhorst: yes, as soon as it gets published
[10:18] <pitti> mlankhorst: are the other packages in that PPA "safe" for an upgrade test?
[10:22] <mlankhorst> they won't explode or anything
[10:23] <mlankhorst> they were from the original xorg 1.15 test rebuild, left in because version is still newer, so someone can ppa-purge them :p
[10:53] <pitti> mlankhorst: will still take a bit; I killed the test machine during the test dist-upgrade :/
[10:53] <pitti> on heavy I/O with containers wazn sometimes just dies
[10:54] <mlankhorst> !!
[10:55] <pitti> mlankhorst: (not your fault at all, just keeping you posted why you don't get a response from me)
[11:03] <apachelogger> pitti: bug 1278820 might be intersting, or at the very least it seems a bit odd ^^
[11:04] <pitti> DEBUG:root:X.org log reports loaded intel driver, disabling driver nvidia-173 for hybrid system
[11:04] <pitti> apachelogger: that's deliberate ATM, I'm afraid
[11:04] <apachelogger> ok
[11:04] <pitti> at least when we wrote that check, we couldn't use the intel and nvidia drivers in parallel
[11:04] <pitti> so you'd have to disable the intel card in the bios if you want to use the nvidia one
[11:05] <apachelogger> pitti: seems to work right now though
[11:05] <apachelogger> or at least the nvidia module is loaded and GL lists nvidia as vendor
[11:06] <pitti> apachelogger: you manually installed the nvidia driver?
[11:06] <pitti> apachelogger: yes, that'll kill the intel driver as well, and shoudl then display it
[11:07] <apachelogger> pitti: maybe, the system was upgraded from saucy, so I might have manually installed it back then
[11:10] <apachelogger> oh
[11:10] <apachelogger> pitti: jockey lists the drivers, so since we used jockey in saucy still I guess I used that to install it
[11:11] <pitti> apachelogger: hm, we had a similar check in jockey
[11:12] <apachelogger> pitti: http://i.imgur.com/1S7h2oh.png
[11:14] <pitti> apachelogger: apparently that's when you already have one installed, so your X.org isn't using intel any more, right?
[11:17] <apachelogger> pitti: yeah, xorg.0.log is attached to the bug
[11:23] <tseliot> apachelogger, pitti: that will be fixed in trusty soon
[11:24] <pitti> tseliot: oh, nice! how will that work, does the nvidia driver use the mesa libGL now?
[11:26] <tseliot> pitti: I'm working on a program that will deal with the different GPUs and take care of the required changes (in this specific case, it will tell X to use the nvidia card if nvidia is installed). This program will run on boot and also detect any hardware changes, for example when users add a new card or swap an nvidia card with an amd card, etc.
[11:27] <tseliot> this will replace the hybrid-detect program in ubuntu-drivers-common
[11:27] <tseliot> the new program is still written in C
[11:28] <apachelogger> neat
[11:35] <pitti> mlankhorst: hm, it seems that our trusty linux-meta already builds metapackages for linux*-lts-saucy, but not for quantal/raring/trusty, and not for xorg*
[11:39] <mlankhorst> pitti: yeah linux does their own thing :)
[11:40] <pitti> mlankhorst: so should linux-meta also build those for quantal, raring, and trusty?
[11:40] <mlankhorst> ask the kernel team
[11:40] <mlankhorst> I can't predict the future so I don't handle lts-trusty yet in my packaging
[11:41] <pitti> apw: so linux-meta builds transitional packages for -lts-saucy; it should also build them for lts-{quantal,raring}, and presumably for lts-trusty as well (as we already know we are going to do it, right?)
[11:41] <pitti> apw: want a bug for that?
[11:43] <pitti> apw: err, wait; they are built, but apt-cache search lts-raring spectacularly fails to find them
[11:43] <pitti> apw: so nevermind, sorry for the noise
[11:45] <pitti> apt-cache search lts-saucy works just fine, curiously
[12:05] <apw> pitti, yeah i am pretty sure we have about 100 transitional packages :)  perhaps they are in different sections from each other or something
[12:12] <pitti> mlankhorst: followed up to bug 1278737
[12:37] <mlankhorst> yeah
[12:59] <mlankhorst> pitti: oh right, libxatracker1 -> libxatracker2
[13:11] <mardy> cjwatson: hi! When you have some time, can you tell me if the approach is right? https://code.launchpad.net/~mardy/click/lp1245826/+merge/204674
[13:11] <mardy> cjwatson: once you confirm it's OK, I'll fix the documentation
[13:13] <cjwatson> mardy: I think it's OK, yes, although FWIW I find it easier to decide whether I like the approach given the documentation :-)
[13:13] <cjwatson> mardy: (I usually write documentation for this kind of thing before I write the code)
[13:14] <cjwatson> mardy: Sorry, I've been buried in 12.04.4 and then a complex series of customer bugs for the last couple of weeks
[13:15] <mlankhorst> I could swear you said you wouldn't do another release after 12.04.2 iirc ;)
[13:15] <mardy> cjwatson: OK, then I will :-)
[13:17] <cjwatson> mlankhorst: Yeah, I think I got voluntold
[13:17] <cjwatson> 12.04.2 was awful
[13:18] <mlankhorst> 12.04.5 is going to be bad too, need to backport dri3 support ;)
[13:19] <mlankhorst> I think you should practice saying '123 NOT ME' faster this time.
[13:32] <xnox> mlankhorst: cjwatson: should things generally depend directly on libgl1-mesa-dri or should it be expected to be handled as a hardware specific thing and something should pull the right one in (either seed or ubuntu-drivers-common)?
[13:33] <xnox> mlankhorst: cjwatson: i see that qtdeclarative5-qtquick2-plugin and libgbm1 depend on libgl1-mesa-dri and thus end up pulling nvidia & radion dri onto ubuntu-touch seeds which seems pointless, as hybris is used.
[13:34] <mlankhorst> depend on libgl1-mesa-dri  | libgl1
[13:35] <mlankhorst> and include libhybris first so libgl1-mesa-dri doesn't end up being installed
[13:35] <xnox> mlankhorst: excellent! let me see if i can make this work.
[13:35] <pitti> mlankhorst: oh, you mean libxatracker1-lts-saucy actually ought to move people to libxatracker2, not to libxatracker1?
[13:36] <mlankhorst> yeah or do nothing, but i moved it to 2
[13:38] <tseliot> davmor2: mlankhorst fixed your problem in xorg-server (2:1.15.0-1ubuntu4). Let us know if you're still able to reproduce the problem with the new update
[13:39] <tseliot> davmor2: you shouldn't be ;)
[13:39] <davmor2> tseliot: thanks I'll grab the update and do a few reboot tests latter then
[13:40] <tseliot> thanks
[13:40] <mlankhorst> should be impossible really
[13:41] <tseliot> too bad, using intel as a source and a sink at the same time was fun :P
[13:43] <cjwatson> mlankhorst: I should be able to at least avoid doing two in a row
[13:48] <mlankhorst> or should you?!
[13:54] <Laney> @pilot out
[13:56] <mlankhorst> pitti: ah right, libglamor-ltss0 conflicts with libglamor0
[13:57] <mlankhorst> incorrectly, but still, I guess I'll need to transition that too
[14:08] <diwic> hmm, what happened to the right mouse button in trusty? Button positions seem to have recently switched
[14:18] <tjaalton> clickpad?
[14:18] <diwic> tjaalton, no, a five button USB mouse
[14:19] <tjaalton> i have a 10+ button mouse and it seems to work like before :)
[14:20] <soren> tjaalton: 10+ button mouse?
[14:20] <tjaalton> ok, 11
[14:20] <diwic> tjaalton, okay...I wonder what happened to this one then?
[14:20] <soren> tjaalton: pics or it didn't happen.
[14:20] <tjaalton> soren: if you count the scroll wheel as three
[14:20] <tjaalton> logitech mx revolution
[14:21] <diwic> tjaalton, ok, mine is seven buttons if you count the scroll wheel as three
[14:21] <soren> tjaalton: That's crazy.
[14:21] <tjaalton> mine has a "wheel" for thumb too
[14:21] <soren> I don't even have a mouse.
[14:21] <tjaalton> hehe
[14:22] <diwic> tjaalton, so what used to be the "popup menu" button now seems to do "open in new tab" in nautilus
[14:22] <diwic> tjaalton, and the popup menu button is now what used to be back button in firefox
[14:23] <tjaalton> diwic: what does xev show
[14:23] <diwic> hmm, and the forward button in firefox is now the back button
[14:23] <tjaalton> or xinput test-xi2
[14:25] <tjaalton> diwic: maybe try an earlier kernel to be sure
[14:25] <tjaalton> the mappings/quirks are there
[14:25] <diwic> tjaalton, hmm, both the scroll wheel button and the second button is now numbered 2
[14:26] <diwic> tjaalton, I bet that's not the case on 12.04
[14:26] <tjaalton> what isn't?
[14:29] <diwic> tjaalton, booting a 3.12 kernel has the same results, so I think it's somewhere else in the stack
[14:29] <tjaalton> you don't have any special xorg.conf then?
[14:29] <diwic> tjaalton, if I press the buttons in order, I end up with: 1, 2, 2, 3, 8.
[14:31] <diwic> tjaalton, whereas in 12.04 I end up with: 1, 2, 3, 8, 9
[14:32] <diwic> tjaalton, not that I'm aware of, where should I look for one?
[14:33] <diwic> there's no /etc/X11/xorg.conf
[14:34] <tjaalton> ok
[14:34] <tjaalton> so you haven't used any release in between?
[14:35] <tjaalton> try the guest session too
[14:36] <diwic> xmodmap -pp shows "13 buttons" and a straight mapping.
[14:36] <diwic> I booted my laptop with saucy, it works fine there.
[14:36] <tjaalton> k
[14:37] <diwic> tjaalton, guest session on trusty desktop = buggy
[14:37] <tjaalton> what mouse is it btw?
[14:37] <doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1278897
[14:37] <diwic> tjaalton, Evoluent Verticalmouse 3
[14:38] <jamespage> doko, ta
[14:39] <tjaalton> diwic: ah, well a quick google shows it has needed special mappings..
[14:39] <tjaalton> so dunno
[14:41] <diwic> tjaalton, !! it is in 10-quirks.conf
[14:43] <diwic> tjaalton, that is just...stupid. I liked it the way it was. Can I override it?
[14:44] <diwic> tjaalton, without changing a system file that will be overwritten on upgrade?
[14:44] <spineau> mterry: hello, I promise this is the last mir bug for checkbox, this one is very similar to the other plainbox provider package, just code relocation: bug 1278822
[14:44] <tjaalton> diwic: yes, put something in /etc/X11/xorg.conf or .d
[14:46] <mterry> spineau, OK
[14:46] <diwic> tjaalton, it works, thanks for saving my day! :-) And my fingers
[14:46] <tjaalton> yw
[14:47] <tjaalton> didn't know that got added upstream
[14:51] <jamespage> doko, is that 12.04 ->14.04?
[14:52] <doko> jamespage, no, that had 11.04 or 11.10
[14:55] <stgraber> pitti: what are you using? lxc-start-ephemeral or lxc-clone -B overlayfs?
[14:55] <pitti> stgraber: start-ephemeral
[14:55] <stgraber> pitti: start-ephemeral should be tmpfs by default
[14:55] <pitti> stgraber: ah, does the  clone -B one allow that?
[14:55] <stgraber> pitti: unless you manually pass -k (keep data) or set the storage type to dir instead of tmpfs
[14:56] <pitti> stgraber: this morning I had a temporary (trusty-jf923blabla) one laying around from a few days ago, and I reboot every day
[14:56] <pitti> stgraber: and I could still start it, so it was there still
[14:56] <stgraber> pitti: did it actually contain any data in /var/lib/lxc/<container>/delta0?
[14:56] <stgraber> pitti: the container definition itself is on disk but the overlay is location (delta0) is a tmpfs by default
[14:57] <stgraber> (unless you pass -k or --storage-type dir)
[14:57] <pitti> stgraber: hm, not sure, I removed it already; I'll re-create that situation and investigate
[14:57] <pitti> stgraber: so /delta0 is the tmpfs mount point?
[14:58] <pitti> stgraber: i. e. the container started alright, but it was like its pristine template, without the delta?
[14:58] <stgraber> right
[14:59] <stgraber> pitti: I just tried here with a new ephemeral container, did some changes and confirmed that none of that is committed to /var/lib/lxc/<container name>/delta0 (which remains empty at all time)
[14:59] <stgraber> it's just a bit tricky to see as the tmpfs is mounted by an lxc hook and is therefore not visible from either the host nor the container
[14:59] <pitti> right
[14:59] <pitti> stgraber: ok, so that was probably it; thanks!
[15:00] <stgraber> np
[15:37] <mlankhorst> pitti: I tested lts-saucy, that one should work, multiarch'd too
[15:51] <jamespage> doko, afaict dovecot's never actually used the snakeoil certs...
[15:51] <jamespage> bah
[15:52] <doko> ohh :-/
[15:53] <bdmurray> doko: I guess doxygen is still using tmake?  I was looking at bug 1196347.
[15:54] <bdmurray> doko: you'd mentioned they were moving to qmake
[15:55] <doko> bdmurray, yes, no change yet
[15:55] <jamespage> doko, yeah - looks like it generates one instead in 12.04 at least
[15:57] <pitti> mlankhorst: ah, splendid; btw, could you rename "oldxorg" to perhaps "xorg-lts-transitional" or so?
[15:59] <tvoss> sil2100, around?
[15:59] <mlankhorst> pitti: are the other ones tested too
[16:00] <pitti> mlankhorst: I can do that now
[16:00] <pitti> mlankhorst: with simulation, but that should be good enough for now
[16:01] <mlankhorst> simulation is fine
[16:17] <pitti> mlankhorst: done, and followed up to the bug
[16:17] <pitti> mlankhorst: so mostly good now, except for that weird geode thing
[16:17] <seb128> doko, can you get a mp with your gnome-control-center-signon changes up? your direct landing is conflicting with a CI landing that is waiting for some days
[16:18] <mlankhorst> pitti: geode is i386 only
[16:18] <pitti> mlankhorst: right, it's just weird that the upgrade says that it's holding it back
[16:18] <pitti> mlankhorst: those three tests were on amd64, doing i386 now
[16:19] <seb128> sil2100, doko just uploaded http://launchpadlibrarian.net/165639698/gnome-control-center-signon_0.1.7~%2B14.04.20131126.2-0ubuntu1_0.1.7~%2B14.04.20131126.2-0ubuntu2.diff.gz ... can we overwrite it with the planned landing?
[16:19] <pitti> mlankhorst: it's like some metapackage now wants to pull in the geode:i386 package for the upgrade
[16:19] <mlankhorst> odd :/
[16:19] <doko> sil2100, well, not override, but just merge the patch
[16:20] <mlankhorst> pitti: well I'm not respecting m-a for all original packages, probably something like that causing it
[16:21] <doko> seb128, is there any reason to hard-code the list of architectures?
[16:21] <pitti> mlankhorst: i386 is fine (also just said that in the bug)
[16:22] <pitti> mlankhorst: many thanks! can you perhaps just rename this, and then get it uploaded? (I can sponsor if you need)
[16:23] <seb128> doko, I don't remember the details, would need to ask didrocks, the issue happened when that package got ported from qt4 to qt5
[16:23] <seb128> doko, it stopped being buildable on e.g ppc since qtdeclarative is not available there
[16:23] <mlankhorst> pitti: you shouldn't install a i386 geode on amd64
[16:23] <pitti> mlankhorst: well, I didn't
[16:23] <mlankhorst> hm :p
[16:23] <pitti> mlankhorst: that's the point -- the upgrade apparenlty tried to install it (through some new dependency), and then holds it back
[16:24] <mlankhorst> would need a full log
[16:24] <mlankhorst> to see why it tries to install it
[16:24] <doko> seb128, sure, it would show up as a dep-wait or a ftbfs, but that would be preferred to limiting the set of archs
[16:24] <doko> same here: https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1278953
[16:24] <seb128> doko, I don't remember the details, britney didn't like the fact that it built before on those archs and was depwaiting after
[16:25] <seb128> doko, well, anyway, please submit a mp to the vcs with your changes
[16:26] <seb128> doko, you just screwed a planned landing by not follow the process
[16:29] <pitti> mlankhorst: attached (although I can't really see from it what's pulling it in)
[16:30] <mlankhorst> maybe video-all:i386
[16:30] <mlankhorst> I'm guessing xserver-xorg*) needs to be m-a foreign
[16:30] <xnox> seb128: "doko, I don't remember the details, britney didn't like the fact that it built before on those archs and was depwaiting after" when that happens, typically one should ask archive admin to remove binaries of the removed architectures from -release pocket.
[16:30] <pitti> mlankhorst: but *shrug*, good enough for the first iteration :)
[16:31] <mlankhorst> pitti: without even looking at the log I'll give that a shot
[16:31] <xnox> seb128: otherwise to britney it does look like: mipsel binary in -release, no mipsel binary in -proposed. *regression*
[16:31] <seb128> xnox, right, but those debs had still rdepends, and Colin didn't want to go for brutal deleting
[16:31] <seb128> xnox, I don't remember the details
[16:31] <cjwatson> eh wut?
[16:31] <seb128> that was blocking things
[16:31] <cjwatson> which packages?
[16:32] <seb128> cjwatson, http://launchpadlibrarian.net/143379896/gnome-control-center-signon_0.1.7~daily13.06.18-0ubuntu1_0.1.7~%2B13.10.20130625-0ubuntu1.diff.gz
[16:32] <cjwatson> I'm pretty sure I tore out bits of the signon stack before, bit surprised to hear my name invoked as a blocker ...
[16:32] <seb128> cjwatson, at the time it did qt4 -> qt5
[16:32] <seb128> it was a bit of a mess
[16:32] <seb128> but I don't remember the specifics of the situation
[16:32] <cjwatson> right, I think that was a change I requested
[16:32] <seb128> cjwatson, oh, you are not named as a blocker
[16:32] <seb128> cjwatson, I'm trying to remember why we did that change by then
[16:32] <cjwatson> doko: I'm pretty sure that limiting the set of arches was necessary there, as otherwise it built binaries that were uninstallable
[16:32] <seb128> doko was asking why it was made
[16:33] <cjwatson> doko: the right answer is to leave it alone for now and wait for Qt 5.2
[16:33] <doko> cjwatson, hmm, ok
[16:33] <cjwatson> 5.2 will (should?) give us a working qtscript everywhere and then we can stop worrying about this
[16:34] <cjwatson> and I gather that's pretty close
[16:34] <cjwatson> I hate explicit architecture lists as much as you do - it was a last resort
[16:35] <seb128> that's my understanding as well, qt5.2 should resolve those issues
[16:36] <cjwatson> basically once we have 5.2 I was going to crawl back up the stack and look for hacks that can be undone
[16:38] <xnox> barry: you could nuke the .py files and only leave python3.3 bytecode =)))))
[16:38] <xnox> barry: and have a custom pyupdate which uses .py files not from a public location.
[16:39] <barry> xnox: heh, yeah, probably fails the "easy" test but that's a possibility ;)
[16:40] <xnox> barry: i guess you can't drop invalid 3.4 bytecode? since python will invalidate it and import .py file instead?
[16:40] <barry> correct.  if the .py is available but __pycache__ isn't writable, then it will just run off the .py files, and you'll pay the compilation cost everytime
[16:41] <xnox> barry: why not take your patch and apply it in debian/ubuntu? or does it have side-effects?
[16:41] <xnox> barry: it's not uncommon for debian/ubuntu to patch support in ahead of upstreams...
[16:41] <doko> does genshi ship any binaries?
[16:42] <barry> xnox: which patch do you mean?  the one that prevents import, or the fix to genshi for 3.4?  i don't have the latter (and neither does upstream, it's not trivial)
[16:42] <doko> are there any rdeps?
[16:43] <xnox> doko: i think it's mostly used as a library, e.g. django can be made to use genshi templates and thus call into genshi on each request to generate .html.
[16:43] <xnox> doko: ditto other web-frameworks/webapps of the day.
[16:43] <xnox> doko: there are no, pyhon3-genshi reverse depends at the moment.
[16:44] <barry> doko: if you mean executables, no.  there is an optional .so for speedups, but it's only compatible with python2 (there's another unresolved upstream ticket for that)
[16:44] <xnox> barry: why not simply ship the module into /usr/lib/python3.3 and be done with it?
[16:44] <doko> xnox, no. would be /usr/lib/python3.3/dist-packages, and we don't have this one yet
[16:45] <doko> I like the import error much more
[16:46] <barry> doko: me too. as icky as it may be, it more or less mimics what you'd see if it wasn't installed for 3.4, so probably "good enough"
[16:50] <xnox> doko: =/ i see, and it doesn't make sense to create one just because of genshi.
[16:51] <xnox> just like with 2.5, will 3.5 be the release that will act like a barrier?! =)
[16:51] <mlankhorst> pitti: ok uploading ppa6, can you give it a shot when it finshed?
[16:53] <mlankhorst> I killed off the m-a same for everything except a few packages
[16:56] <barry> xnox: huh?
[16:57] <xnox> barry: a lot of projects struggled to move to 2.5, or choose not to. and later 2.5 projects didn't move to 2.7, at times getting 2.7 support together with 3.0 one.
[16:58] <xnox> maybe it's just my impression.
[16:58] <xnox> as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages
[16:59] <cjwatson> I think chose not to was more common; 2.4 support seemed quite sticky
[16:59] <xnox> as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages
[17:00]  * xnox -Efocus-follow-eye-sight
[17:00] <barry> xnox: genshi's failure is rather unique actually because it depends on the AST, which doesn't have a guaranteed stable API.
[17:01] <barry> so it probably breaks with every release (that's what you get for depending on a library documented to not be stable ;)
[17:02] <barry> one of the topics for the language summit in montreal pycon2014 will be the 3.5 release.  a strong possibility is a shorter dev cycle specifically focused on improving porting from python 2, with very limited feature set otherwise
[17:03] <barry> (something i actually favor, in the abstract ;)
[17:05] <barry> tedg: hi.  i was wondering if you could comment on LP: #1278582 and LP: #1278511.  they (and especially the former for me) are causing lots of pain for emacs users.  they seem to be recent regressions
[17:06] <tedg> barry, Hmm, seems seb128 just set it to fix committed :-)
[17:06] <seb128> tedg, barry: yeah, commenting on both
[17:06] <tedg> barry, In general that's probably a bregma thing though.
[17:07] <seb128> it's a "we need unity trunk to land in trusty, one day"
[17:07] <bregma> one day soon
[17:07] <seb128> tedg, barry: you can access it by running gnome-control-center.real
[17:07] <seb128> or http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3643
[17:08] <barry> seb128: oh wow.  why doesn't .real run when you hit the gear->System Settings? :)
[17:08] <seb128> barry, you get unity-control-center (our new default UI)
[17:09] <barry> seb128: ah, and this setting hasn't been added to u-c-c yet?
[17:09] <seb128> barry, the Unity xml is missing because unity didn't get a landing for ages
[17:09] <seb128> cf the commit I just pointed
[17:09] <seb128> it's fixed in trunk
[17:09] <seb128> but bregma's ass has been kicked by unity autopilot tests recently it seems
[17:09] <seb128> those guys didn't manage to do a landing for ages
[17:09] <barry> seb128: awesome, thanks.  i will try .real and wait for the fix-released there
[17:10] <seb128> yw!
[17:10] <seb128> barry, the other one should be an ibus issue, please try if unsetting in ibus-setup fixes it
[17:11] <barry> seb128: yeah, i actually uninstalled ibus ;)
[17:11] <bregma> we're spending more time fixing bugs in autopilot itself than in unity
[17:11] <seb128> bregma, :-(
[17:12] <seb128> bregma, are those regressions in autopilot? can't we just back out the buggy version?
[17:12] <barry> seb128: however, on LP: #1278582 i don't actually think it's fixed.  .real shows me "Key to show the HUD" as disabled, and yet both Alts still bring up the search dialog.  if in the settings panel, i hit alt-right or super, the key settings just reverts to "diabled".  but i don't think it's actually disabled!  maybe the search dialog is different than "Key to show the HUD"?
[17:13] <bregma> 40 new regressions due to #1278917
[17:13] <barry> bregma: yeah, i am struggling with autopilot failures all over the place :/
[17:14] <seb128> barry, well, the issue that bug describes "don't list keybindings" is fixed, not sure about the hud key not working as it should...
[17:14] <barry> seb128: fair enough.  i suppose i should open a new bug on that issue.  would that be on unity then?
[17:14] <seb128> yes and yes
[17:15] <barry> seb128: cool, thanks!
[17:15] <seb128> yw!
[17:27] <barry> seb128: LP: #1278985  - please let me know if my explanation was unclear or
[17:27] <barry> *unclear (no or :)
[17:30] <seb128> barry, seems clear, I can't confirm/reproduce though
[17:30] <brendand> barry, is that Alt+ something, or Alt, then something?
[17:30] <seb128> changing the keybinding works fine for me
[17:30] <samertm> barry: does that bug only appear in trusty?
[17:32] <rbasak> doko: for bug 1243076, the conclusion is to drop the package, unless you object? It seems that nobody has ported the code itself to Apache 2.4's new API.
[17:32] <rbasak> (and upstream and Debian are inactive)
[17:32]  * rbasak doesn't see any rdepends
[17:33] <barry> brendand: it's all muscle memory, but it seems to be roughly "press alt then quickly press f next' (of course, not just f - any key will do)
[17:33] <barry> brendand: although if i'm *really* careful i can press them both at the same time, and the same behavior is exhibited
[17:33] <barry> samertm: a very recent dist-upgrade of trusty, i.e. as of yesterday.  last week it all worked fine
[17:34] <barry> seb128: you're changing the keybinding via g-c-c.real?
[17:34] <seb128> barry, yes
[17:34] <samertm> barry: kk, thanks for the info
[17:35] <brendand> barry, but it doesn't work if held down?
[17:35] <brendand> barry, i.e. hold alt and press 'f' with other finger
[17:36] <barry> seb128: so, to be clear, if you open Keyboard->Shortcuts, click on "Key to show the HUD" and tap Super, you see it set to Super?  for me it just reverts to Disabled
[17:36] <seb128> barry, let me try with super, I tried "backspace" which set it to "disabled" which works
[17:37] <seb128> barry, super is the key used by the dash
[17:37] <seb128> that doesn't work
[17:37] <barry> brendand: correct.  hit and hold Alt for a few seconds, then tap 'f'.  the app with focus will *not* see the event
[17:37] <barry> seb128: what about right-alt?
[17:37] <seb128> that's the default key
[17:37] <seb128> oh, right alt
[17:37] <brendand> barry, but that works for me in e.g. chromium
[17:38] <barry> seb128: yes, it wouldn't be so disruptive if it was right-alt only (i personally use left-alt all the time for "alt")
[17:38] <seb128> barry, that doesn't work, right ctrl works, win key works
[17:38] <seb128> the menu key works
[17:39] <barry> seb128: i don't have any of those keys on this keyboard ;)  (no right control, menu, or win)
[17:39] <barry> i have right alt and right super though
[17:39] <seb128> barry, is disabled with backspace working?
[17:39] <barry> brendand: like, what key combination exactly?
[17:40] <barry> seb128: that's hard to tell, because Key to show the HUD is already "Disabled".  but hitting backspace/delete does still leave it disabled
[17:40] <brendand> barry, hold down left-alt and press f
[17:41] <seb128> barry, what is you pick any random key, e.g f8
[17:42] <barry> seb128: but i can set it to Super+Right and that does "work" in the sense that the shotcut is displayed that way.  and indeed, with show hud set to Super+Right, alt is not captured
[17:42] <seb128> ok
[17:42] <seb128> so dunno why right-alt doesn't work, likely an xkeyboard-config issue
[17:42] <seb128> you just need to find a key that exists on your keyboard and suits you
[17:43] <barry> brendand, seb128 so, setting it to Super+Right and *then* setting it back explicitly to Disabled (via backspace) defeats the capture too it seems
[17:43] <mlankhorst> pitti: if you feel like testing, I uploaded xorg-lts-transitional now
[17:43] <mlankhorst> should fix your geode issue
[17:43] <pitti> mlankhorst: oh, sweet, thanks
[17:44] <pitti> mlankhorst: I need to wrap up for today, will do it tomorrow morning
[17:44] <barry> seb128, brendand thanks.  i will update the bug, but now the pain is gone :)
[17:46] <seb128> barry, yw
[17:50] <rbasak> doko: I've filed bug 1278995
[18:18] <mdeslaur> xnox: if you do make a separate package for the two codecs, could you not name it with "bad" in the name? :)
[18:19] <mdeslaur> shipping a package called "bad" or "ugly" by default on devices doesn't sound too appealing :)
[18:19] <xnox> mdeslaur: it was going to be either inside the hybris package, or hybris-extra, or bad-subset.
[18:20] <mdeslaur> xnox: those two don't pull libav in, right?
[18:20] <xnox> mdeslaur: i think we are barred from shipping bad/ugly on default media, anyway... but i'm not going to get into that discussion.
[18:20] <xnox> mdeslaur: correct, they do not pull in libav, opecv / colorprint and a few other pieces however do.
[18:20] <xnox> mdeslaur: hence i want to drop them.
[18:20] <mdeslaur> ok, good
[18:21] <xnox> mdeslaur: i think we will still be linking to libstreamerparsersbad though, and that's library name....
[18:21] <xnox> so bad strings are here to stay =)
[18:21] <mdeslaur> meh, was just a suggestion :)
[18:21] <mdeslaur> bad-dog-bad-bad-no
[18:23]  * xnox "but, i just met you, and i already like you....." gosh, "Up" was a good movie!
[18:23] <Laney> umm
[18:37] <Laney> xnox: I'd prefer doing genuine splits rather than stuffing things into weird packages
[18:37] <Laney> please talk to Debian about it ...
[18:47] <Laney> but if they don't go for it, the normal split still feels right to me
[19:24] <vp7> is Ubuntu community participating in GSOC this year.
[22:31] <ScottK> Mirv: Do you know when Qt 5.2 is finally going to land?
[22:56] <hallyn> stgraber: thouhts on bug 1248283  (last few comments)?
[22:56] <hallyn> i should retitle that bug...  it's purely a dbus bug, not juju
[22:57] <xnox> ScottK: i spoke with Mirv about it last week, and there were still a few savere regressions on touch (e.g. screen doesn't unlock, unless one disables powerd before screen autolocks for the first time)
[22:57] <hallyn> there that's better
[22:57] <hallyn> bug 1248283
[22:57] <xnox> ScottK: =/
[22:58] <ScottK> xnox: I think our process is now fundamentally broken when it's apparently impossible to update libraries in the development release.
[22:59] <stgraber> hallyn: it's not really a bug because "restart networking" isn't supported, we just don't have a good way to prevent it. The supported way to bounce the network is "ifdown -a && do config changes && ifup -a" or the same but just for the interfaces you are changing.
[22:59] <xnox> ScottK: i agree. in the mean time i'm writting Qt patches against 5.3... which i'll then have to backport to 5.2, 5.0 and 4.8 by the looks of things.
[22:59] <stgraber> hallyn: we had a chat about this during the Core Sprint and the CTS folks said they'd make sure our documentation covers this properly (I sent a bunch of patches a while back to get rid of the worst cases)
[22:59] <hallyn> stgraber: oh that again :)
[23:00] <ScottK> Please not 4.8.
[23:00] <xnox> stgraber: if we make networking an instance job (with a default instance whatever, it will be a single one) then "restart networking" will do nothing.
[23:00] <stgraber> hallyn: "deconfiguring-network" is usually meant as "the system is going down, services should now die, please all exit because the fs is about to go away"
[23:01] <xnox> stgraber: or better, make it a task =) such that "restart networking" does no harm, or at least doesn't emit deconfiguring-network. What do you think?
[23:02] <stgraber> xnox: well, we need a started and stopped state because things unfortunately depend on this...
[23:02] <stgraber> xnox: and it needs to match name with the sysvinit job so services vaguely does the right thing
[23:02] <hallyn> stgraber: ok, so you would claim the bug is in juju or juju charms for using restart networking?
[23:03] <stgraber> hallyn: absolutely, nobody should even do restart networking
[23:03] <stgraber> *ever
[23:03] <hallyn> stgraber: I wonder if we did a poll, how many ppl would knwo that :)
[23:03] <stgraber> because it'll almost certainly always do everything but what you want it to do :)
[23:03] <hallyn> stgraber: thanks, i'll follow up in the bug
[23:04] <stgraber> well, eveyrone who used it at some point probably had problems and either filed a bug which I'd have closed as invalid/won't fix or they'd have found one of the hundred of places where I tried to explain this :)
[23:05] <stgraber> hallyn: most people using restart networking also forget that ifupdown isn't stateful, so if your interface was DHCP and you change it to static, then restart networking, this won't kill dhclient so 30min later your IP gets overriden by dhclient
[23:05] <sarnold> "oh I know I'll just restart networking, that'll do everything" --> "hunh, why is my system suddenly useless?"
[23:05] <stgraber> hallyn: hence which you're supposed to ifdown => change config => ifup
[23:05] <hallyn> i still have issues with that, but won't argue them now :)
[23:05] <stgraber> *why
[23:06] <hallyn> hm, but i can't figure out where it's being done.  maas and juju dont' seem to do it
[23:07] <stgraber> hallyn: from instance userdata apparently
[23:07] <stgraber> at least that's what they show in the bug description
[23:07] <stgraber> oh and indeed that's just completely wrong because they move eth0 into a bridge without first deconfiguring eth0, therefore leaving it with an IP and a running dhclient
[23:08] <stgraber> so even if the restart didn't blow things up to pieces, they'd end up with the network config being applied to both eth0 and br0 and two dhclient process running (one on eth0 and one on br0)
[23:09] <sarnold> what does it mean to run dhclient on a bridge device?
[23:09] <stgraber> oh and their config also doesn't need to mention eth0 at all, ifupdown is clever enough to figure it out from the br0 config
[23:09] <stgraber> sarnold: works fine, broadcasts to all devices on the bridge, attempts to get an IP and sets it on the bridge interface
[23:09] <sarnold> stgraber: crazy, I thought the point of the bridge interfaces was that they were 'below' IP, as it were.
[23:10] <hallyn> stgraber: i see it in the bug description, but the juju package doesn' tseem to include those.
[23:10] <stgraber> hallyn: so tl;dr, they should use ifdown eth0 => 'cat > /etc/network/eth0.conf << EOF\niface br0 inet dhcp\n bridge_ports eth0\nEOF\n" => ifup br0, that'll DTRT
[23:11] <xnox> ScottK: what's wrong with 4.8? there are plenty of apps still using that...
[23:11] <hallyn> /etc/network/eth0.conf?  that's new to me
[23:11] <ScottK> xnox: Are you fixing bugs or adding features?  If the former, then nothing.
[23:11] <xnox> ScottK: so we do still need to maintain it.
[23:12] <ScottK> Sure.
[23:12] <stgraber> sarnold: yeah, it's slightly trickier than that, because it both acts like a switch and a member of that switch. So it doesn't have its own MAC address (steals the lowest one in the bridge) but can have IP configuration on it and you can use it like a regular interface (so long as it has at least one member, otherwise it doesn't have a MAC and everything blows up)
[23:12] <xnox> ScottK: working on the gtk theming plugin.
[23:12] <xnox> (qgtkstyle)
[23:12] <sarnold> stgraber: thanks, I think that explains a lot about what I'd been misunderstanding about bridges :)
[23:13] <stgraber> hallyn: they're using the "source statement" to include an external file. Though they really should be using include-dir and /etc/network/interfaces.d/ since that's what's done by default on new installs now.
[23:13] <hallyn> stgraber: no no, include-dir isn't yet supported by augeas :)
[23:14] <stgraber> hallyn: well, clearly they're not using augeas at the moment, so who cares ;)
[23:14] <hallyn> they'll want to use libvirt using netcf and thatll fail
[23:14] <hallyn> anyone answer is noone seems to care so i'll probably ahve to update the lens :(
[23:15] <stgraber> so augeas supports source but not include-dir? that seems odd since the latter is basically a wildcard source (ish, there's a regexp in the interfaces manpage)
[23:15] <hallyn> stgraber: the source support is actually not yet committed iiuc.