[00:10] 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] ClientAlive: investigate xwininfo [00:11] sarnold: thx. will do [00:12] ClientAlive: oh! also xprop [00:12] sarnold: Oh, that's coool... :> [00:13] there's also xlsclients === czchen_ is now known as czchen [00:14] (but xprop's attempt at ansi-text'fying an app's icon is pretty cute) [00:15] sbeattie: no kidding [00:17] 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] I sure sure would appreciate it. [00:17] Then I can move along on my own [00:19] sbeattie: ? sarnold: ? [00:21] Problem is, I don't see that particular information with xwininfo or xprop [00:21] ClientAlive: no idea, sorry [00:21] k [00:22] 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] but I've never tried devilspie before [00:23] sarnold: It's a start. thx [00:26] 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 ). === jono is now known as Guest13828 === TheLordOfTime is now known as teward === mwhudson is now known as zz_mwhudson === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson === timrc is now known as timrc-afk [05:36] Good morning [05:36] l [05:37] sarnold: right, the amd64 one crashed; restarted [05:39] 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] 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] answered my own question i think : package libdbusmenu-gtk-doc [05:57] maybe not :\ [05:58] 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] thanks pitti [06:14] pitti: good morning :) thanks! [06:18] 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] 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] RAOF: feels API-breaky to me, but if it's particularly helpful for some use case we can certainly do it [06:23] it's not yet that widely used [06:25] I'm not entirely sure if that's what I want, either. [06:25] RAOF: thanks for your pull requests, looking at them now [06:25] RAOF: btw, if you add NEWS entries they can be merged fully automatically [06:26] pitti: Ah, let me do so then. [06:26] RAOF: I can add them during the merge this time, no worries (although github supports push -f just fine) [06:31] I should probably make testbed_remove send "remove" uevents, too, for symmetry. [06:32] RAOF: I merged the DEVNAME one, and put a qestion on the uevent one [06:33] Sure, I can add a test. [06:34] or, probably, change an existing one to ensure that the uevent is received [06:34] RAOF: so, for the "return sysfs paths" thing, what's your use case for that? [06:35] 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] 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] 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] ah [06:37] yes, that's much easier then [06:55] mlankhorst: hey, how are you? [06:56] 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] 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) === zz_mwhudson is now known as mwhudson === freeflying is now known as freeflying_away [07:47] 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] bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,New] https://launchpad.net/bugs/1278737 [07:47] jibel: ^ FYI (for tracking) === maclin_ is now known as maclin [08:11] Good morning, I need someone to process a sync request for checkbox please: bug 1278747 [08:11] bug 1278747 in Ubuntu "Sync plainbox-provider-checkbox 0.3-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1278747 === freeflying_away is now known as freeflying [08:34] good morning [08:37] dholbach: Good morning, may I ask you to process a sync request (for checkbox)? [08:38] it's bug 1278747 [08:38] bug 1278747 in Ubuntu "Sync plainbox-provider-checkbox 0.3-2 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1278747 [08:38] hi spineau [08:39] spineau, I'll take a look at it in a bit [08:39] dholbach: thanks a lot [08:39] pitti: yeah ok :P [08:40] mlankhorst: good morning; thanks! [09:05] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [09:20] pitti: if you want to test, just a second [09:20] Laney, Hi [09:20] hiya [09:20] since you piloting can you take a look at gcc vanilla MP? [09:21] where? [09:22] Laney, ubuntu-desktop branch [09:23] lp:~darkxst/gnome-control-center/vanilla [09:24] dude [09:24] using gcc like that is confusing [09:25] but if it is what it sounds like then I might punt to robert_ancell :-) [09:30] pitti: can you add a ppa for testing? [09:30] mlankhorst: yes, when doing it manually [09:31] hold on a sec, I should be able to upload oldxorg shortly [09:31] Laney: On man, I absolutely thought he meant GNU Compiler Collection. [09:32] darkxst: g-c-c, not GCC, if you want to avoid heart attacks. [09:32] infinity: No need to worry, I'd have blindly sponsored it anyway. :) [09:32] Laney: You desktop people scare me. [09:32] "YOU AREN'T A CORE-DEV?" DEBSIGN DPUT [09:33] "it starts with g*, must be desktop" [09:34] pitti: I copied the oldxorg pkg to ppa:canonical-x/x-staging [09:35] pitti, it's why the kernel is a kubuntu thing, right? ;-) [09:35] seb128: yeah; and you already lost one of your pets when glibc got renamed to eglibc.. [09:35] seb128: No, we cleverly made the source package start with 'l' to avoid that. [09:35] edubuntu claimed that one [09:35] seb128: besides, lubuntu (it's linux, not kernel) [09:36] Also, we have too many flavours. Somene seems to be able to claim every letter. [09:36] pitti, infinity: oh, right ;-) [09:36] Time to invent more letters. Unicode FTW. [09:37] * infinity renames glibc to ☭libg. [09:37] μbuntu [09:37] * pitti registers ƃɹo˙nʇunqn [09:38] 可u般你他去 [09:39] mlankhorst: thanks! I'll wait until it's built and published and then test === freeflying is now known as freeflying_away [09:39] it almost finished building empty files. :P [09:39] I really wanted to that be code-of-conduct violating. Google Translate let me down. [09:39] oops.. needs multi-arch: same.. [09:40] Also, Google's "did you mean?" sugestions for Chinese are hilariously awful. [09:40] mlankhorst: err, does it? they are arch:all, aren't they? [09:40] "Did you mean: 可u盘你他去" [09:40] "U disk you can go to him" [09:40] looks exactly the same to me [09:40] Thanks, Google. That's exactly what I meant. [09:40] pitti: hm no it should be arch: amd64 i386 [09:41] because we don't want to break upgrading libgl-mesa etc [09:41] or end up with a 32-bits xserver on amd64! :D [09:52] pitti, https://code.launchpad.net/~thomas-voss/process-cpp/add_death_observer_for_child_processes/+merge/204629 [10:06] pitti: ok pushed, can you check if it works? also can you check if /usr/lib/xorg/protocol.txt exists after upgrading? [10:11] mlankhorst: yes, as soon as it gets published === mwhudson is now known as zz_mwhudson [10:18] mlankhorst: are the other packages in that PPA "safe" for an upgrade test? [10:22] they won't explode or anything [10:23] 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] mlankhorst: will still take a bit; I killed the test machine during the test dist-upgrade :/ [10:53] on heavy I/O with containers wazn sometimes just dies [10:54] !! [10:55] mlankhorst: (not your fault at all, just keeping you posted why you don't get a response from me) [11:03] pitti: bug 1278820 might be intersting, or at the very least it seems a bit odd ^^ [11:03] bug 1278820 in ubuntu-drivers-common (Ubuntu) "system not detected as needing nvidia" [Undecided,New] https://launchpad.net/bugs/1278820 [11:04] DEBUG:root:X.org log reports loaded intel driver, disabling driver nvidia-173 for hybrid system [11:04] apachelogger: that's deliberate ATM, I'm afraid [11:04] ok [11:04] at least when we wrote that check, we couldn't use the intel and nvidia drivers in parallel [11:04] so you'd have to disable the intel card in the bios if you want to use the nvidia one [11:05] pitti: seems to work right now though [11:05] or at least the nvidia module is loaded and GL lists nvidia as vendor [11:06] apachelogger: you manually installed the nvidia driver? [11:06] apachelogger: yes, that'll kill the intel driver as well, and shoudl then display it [11:07] pitti: maybe, the system was upgraded from saucy, so I might have manually installed it back then [11:10] oh [11:10] pitti: jockey lists the drivers, so since we used jockey in saucy still I guess I used that to install it [11:11] apachelogger: hm, we had a similar check in jockey [11:12] pitti: http://i.imgur.com/1S7h2oh.png [11:14] apachelogger: apparently that's when you already have one installed, so your X.org isn't using intel any more, right? [11:17] pitti: yeah, xorg.0.log is attached to the bug [11:23] apachelogger, pitti: that will be fixed in trusty soon [11:24] tseliot: oh, nice! how will that work, does the nvidia driver use the mesa libGL now? [11:26] 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] this will replace the hybrid-detect program in ubuntu-drivers-common [11:27] the new program is still written in C [11:28] neat === _salem is now known as salem_ [11:35] 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] pitti: yeah linux does their own thing :) [11:40] mlankhorst: so should linux-meta also build those for quantal, raring, and trusty? [11:40] ask the kernel team [11:40] I can't predict the future so I don't handle lts-trusty yet in my packaging [11:41] 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] apw: want a bug for that? [11:43] apw: err, wait; they are built, but apt-cache search lts-raring spectacularly fails to find them [11:43] apw: so nevermind, sorry for the noise [11:45] apt-cache search lts-saucy works just fine, curiously [12:05] 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] mlankhorst: followed up to bug 1278737 [12:12] bug 1278737 in xorg (Ubuntu Trusty) "Upgrade to trusty fails from precise backported enablement stacks" [High,In progress] https://launchpad.net/bugs/1278737 === MacSlow is now known as MacSlow|lunch [12:37] yeah [12:59] pitti: oh right, libxatracker1 -> libxatracker2 [13:11] 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] cjwatson: once you confirm it's OK, I'll fix the documentation [13:13] 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] mardy: (I usually write documentation for this kind of thing before I write the code) [13:14] 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] I could swear you said you wouldn't do another release after 12.04.2 iirc ;) [13:15] cjwatson: OK, then I will :-) [13:17] mlankhorst: Yeah, I think I got voluntold [13:17] 12.04.2 was awful [13:18] 12.04.5 is going to be bad too, need to backport dri3 support ;) [13:19] I think you should practice saying '123 NOT ME' faster this time. === MacSlow|lunch is now known as MacSlow [13:32] 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] 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] depend on libgl1-mesa-dri | libgl1 [13:35] and include libhybris first so libgl1-mesa-dri doesn't end up being installed [13:35] mlankhorst: excellent! let me see if i can make this work. [13:35] mlankhorst: oh, you mean libxatracker1-lts-saucy actually ought to move people to libxatracker2, not to libxatracker1? [13:36] yeah or do nothing, but i moved it to 2 [13:38] 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] davmor2: you shouldn't be ;) [13:39] tseliot: thanks I'll grab the update and do a few reboot tests latter then [13:40] thanks [13:40] should be impossible really [13:41] too bad, using intel as a source and a sink at the same time was fun :P [13:43] mlankhorst: I should be able to at least avoid doing two in a row [13:48] or should you?! === timrc-afk is now known as timrc [13:54] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [13:56] pitti: ah right, libglamor-ltss0 conflicts with libglamor0 [13:57] incorrectly, but still, I guess I'll need to transition that too === greyback is now known as greyback|lunch [14:08] hmm, what happened to the right mouse button in trusty? Button positions seem to have recently switched [14:18] clickpad? [14:18] tjaalton, no, a five button USB mouse [14:19] i have a 10+ button mouse and it seems to work like before :) [14:20] tjaalton: 10+ button mouse? [14:20] ok, 11 [14:20] tjaalton, okay...I wonder what happened to this one then? [14:20] tjaalton: pics or it didn't happen. [14:20] soren: if you count the scroll wheel as three [14:20] logitech mx revolution [14:21] tjaalton, ok, mine is seven buttons if you count the scroll wheel as three [14:21] tjaalton: That's crazy. [14:21] mine has a "wheel" for thumb too [14:21] I don't even have a mouse. [14:21] hehe [14:22] tjaalton, so what used to be the "popup menu" button now seems to do "open in new tab" in nautilus [14:22] tjaalton, and the popup menu button is now what used to be back button in firefox [14:23] diwic: what does xev show [14:23] hmm, and the forward button in firefox is now the back button [14:23] or xinput test-xi2 [14:25] diwic: maybe try an earlier kernel to be sure [14:25] the mappings/quirks are there [14:25] tjaalton, hmm, both the scroll wheel button and the second button is now numbered 2 [14:26] tjaalton, I bet that's not the case on 12.04 [14:26] what isn't? [14:29] tjaalton, booting a 3.12 kernel has the same results, so I think it's somewhere else in the stack [14:29] you don't have any special xorg.conf then? [14:29] tjaalton, if I press the buttons in order, I end up with: 1, 2, 2, 3, 8. === doko_ is now known as doko [14:31] tjaalton, whereas in 12.04 I end up with: 1, 2, 3, 8, 9 [14:32] tjaalton, not that I'm aware of, where should I look for one? [14:33] there's no /etc/X11/xorg.conf [14:34] ok [14:34] so you haven't used any release in between? [14:35] try the guest session too [14:36] xmodmap -pp shows "13 buttons" and a straight mapping. [14:36] I booted my laptop with saucy, it works fine there. [14:36] k [14:37] tjaalton, guest session on trusty desktop = buggy [14:37] what mouse is it btw? [14:37] jamespage, https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/1278897 [14:37] Launchpad bug 1278897 in dovecot (Ubuntu) "dovecot warns about moved ssl certs on upgrade" [Undecided,New] [14:37] tjaalton, Evoluent Verticalmouse 3 [14:38] doko, ta [14:39] diwic: ah, well a quick google shows it has needed special mappings.. [14:39] so dunno [14:41] tjaalton, !! it is in 10-quirks.conf [14:43] tjaalton, that is just...stupid. I liked it the way it was. Can I override it? [14:44] tjaalton, without changing a system file that will be overwritten on upgrade? [14:44] 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] bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,New] https://launchpad.net/bugs/1278822 [14:44] diwic: yes, put something in /etc/X11/xorg.conf or .d === freeflying_away is now known as freeflying [14:46] spineau, OK [14:46] tjaalton, it works, thanks for saving my day! :-) And my fingers [14:46] yw [14:47] didn't know that got added upstream === greyback|lunch is now known as greyback [14:51] doko, is that 12.04 ->14.04? [14:52] jamespage, no, that had 11.04 or 11.10 [14:55] pitti: what are you using? lxc-start-ephemeral or lxc-clone -B overlayfs? [14:55] stgraber: start-ephemeral [14:55] pitti: start-ephemeral should be tmpfs by default [14:55] stgraber: ah, does the clone -B one allow that? [14:55] pitti: unless you manually pass -k (keep data) or set the storage type to dir instead of tmpfs [14:56] stgraber: this morning I had a temporary (trusty-jf923blabla) one laying around from a few days ago, and I reboot every day [14:56] stgraber: and I could still start it, so it was there still [14:56] pitti: did it actually contain any data in /var/lib/lxc//delta0? [14:56] pitti: the container definition itself is on disk but the overlay is location (delta0) is a tmpfs by default [14:57] (unless you pass -k or --storage-type dir) [14:57] stgraber: hm, not sure, I removed it already; I'll re-create that situation and investigate [14:57] stgraber: so /delta0 is the tmpfs mount point? [14:58] stgraber: i. e. the container started alright, but it was like its pristine template, without the delta? [14:58] right [14:59] 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//delta0 (which remains empty at all time) [14:59] 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] right [14:59] stgraber: ok, so that was probably it; thanks! [15:00] np === freeflying is now known as freeflying_away [15:37] pitti: I tested lts-saucy, that one should work, multiarch'd too [15:51] doko, afaict dovecot's never actually used the snakeoil certs... [15:51] bah [15:52] ohh :-/ [15:53] doko: I guess doxygen is still using tmake? I was looking at bug 1196347. [15:54] bug 1196347 in tmake (Ubuntu) "[MIR] promote tmake (already included in main in the doxygen sources)" [Undecided,Fix released] https://launchpad.net/bugs/1196347 [15:54] doko: you'd mentioned they were moving to qmake [15:55] bdmurray, yes, no change yet [15:55] doko, yeah - looks like it generates one instead in 12.04 at least [15:57] mlankhorst: ah, splendid; btw, could you rename "oldxorg" to perhaps "xorg-lts-transitional" or so? [15:59] sil2100, around? [15:59] pitti: are the other ones tested too [16:00] mlankhorst: I can do that now [16:00] mlankhorst: with simulation, but that should be good enough for now [16:01] simulation is fine [16:17] mlankhorst: done, and followed up to the bug [16:17] mlankhorst: so mostly good now, except for that weird geode thing [16:17] 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] pitti: geode is i386 only [16:18] mlankhorst: right, it's just weird that the upgrade says that it's holding it back [16:18] mlankhorst: those three tests were on amd64, doing i386 now [16:19] 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] mlankhorst: it's like some metapackage now wants to pull in the geode:i386 package for the upgrade [16:19] odd :/ [16:19] sil2100, well, not override, but just merge the patch [16:20] pitti: well I'm not respecting m-a for all original packages, probably something like that causing it [16:21] seb128, is there any reason to hard-code the list of architectures? [16:21] mlankhorst: i386 is fine (also just said that in the bug) [16:22] mlankhorst: many thanks! can you perhaps just rename this, and then get it uploaded? (I can sponsor if you need) [16:23] 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] doko, it stopped being buildable on e.g ppc since qtdeclarative is not available there [16:23] pitti: you shouldn't install a i386 geode on amd64 [16:23] mlankhorst: well, I didn't [16:23] hm :p [16:23] mlankhorst: that's the point -- the upgrade apparenlty tried to install it (through some new dependency), and then holds it back [16:24] would need a full log [16:24] to see why it tries to install it [16:24] 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] same here: https://bugs.launchpad.net/ubuntu/+source/account-plugins/+bug/1278953 [16:24] Launchpad bug 1278953 in gnome-control-center-signon (Ubuntu) "package should be built on any arch" [Undecided,New] [16:24] 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] doko, well, anyway, please submit a mp to the vcs with your changes [16:26] doko, you just screwed a planned landing by not follow the process [16:29] mlankhorst: attached (although I can't really see from it what's pulling it in) [16:30] maybe video-all:i386 [16:30] I'm guessing xserver-xorg*) needs to be m-a foreign [16:30] 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] mlankhorst: but *shrug*, good enough for the first iteration :) [16:31] pitti: without even looking at the log I'll give that a shot [16:31] seb128: otherwise to britney it does look like: mipsel binary in -release, no mipsel binary in -proposed. *regression* [16:31] xnox, right, but those debs had still rdepends, and Colin didn't want to go for brutal deleting [16:31] xnox, I don't remember the details [16:31] eh wut? [16:31] that was blocking things [16:31] which packages? [16:32] 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] 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] cjwatson, at the time it did qt4 -> qt5 [16:32] it was a bit of a mess [16:32] but I don't remember the specifics of the situation [16:32] right, I think that was a change I requested [16:32] cjwatson, oh, you are not named as a blocker [16:32] cjwatson, I'm trying to remember why we did that change by then [16:32] doko: I'm pretty sure that limiting the set of arches was necessary there, as otherwise it built binaries that were uninstallable [16:32] doko was asking why it was made [16:33] doko: the right answer is to leave it alone for now and wait for Qt 5.2 [16:33] cjwatson, hmm, ok [16:33] 5.2 will (should?) give us a working qtscript everywhere and then we can stop worrying about this [16:34] and I gather that's pretty close [16:34] I hate explicit architecture lists as much as you do - it was a last resort [16:35] that's my understanding as well, qt5.2 should resolve those issues [16:36] 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] barry: you could nuke the .py files and only leave python3.3 bytecode =))))) [16:38] barry: and have a custom pyupdate which uses .py files not from a public location. [16:39] xnox: heh, yeah, probably fails the "easy" test but that's a possibility ;) [16:40] barry: i guess you can't drop invalid 3.4 bytecode? since python will invalidate it and import .py file instead? [16:40] 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] barry: why not take your patch and apply it in debian/ubuntu? or does it have side-effects? [16:41] barry: it's not uncommon for debian/ubuntu to patch support in ahead of upstreams... [16:41] does genshi ship any binaries? [16:42] 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] are there any rdeps? [16:43] 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] doko: ditto other web-frameworks/webapps of the day. [16:43] doko: there are no, pyhon3-genshi reverse depends at the moment. [16:44] 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] barry: why not simply ship the module into /usr/lib/python3.3 and be done with it? [16:44] xnox, no. would be /usr/lib/python3.3/dist-packages, and we don't have this one yet [16:45] I like the import error much more [16:46] 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] doko: =/ i see, and it doesn't make sense to create one just because of genshi. [16:51] just like with 2.5, will 3.5 be the release that will act like a barrier?! =) [16:51] pitti: ok uploading ppa6, can you give it a shot when it finshed? [16:53] I killed off the m-a same for everything except a few packages [16:56] xnox: huh? [16:57] 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] maybe it's just my impression. [16:58] as in maybe around 3.5 time, genshi like problems will be widespread enough, to warrant /usr/lib/python3.x/dist-packages [16:59] I think chose not to was more common; 2.4 support seemed quite sticky [16:59] 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] xnox: genshi's failure is rather unique actually because it depends on the AST, which doesn't have a guaranteed stable API. [17:01] so it probably breaks with every release (that's what you get for depending on a library documented to not be stable ;) [17:02] 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] (something i actually favor, in the abstract ;) [17:05] 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:05] Launchpad bug 1278582 in hud (Ubuntu) "Regression: cannot set HUD key binding" [Undecided,New] https://launchpad.net/bugs/1278582 [17:05] Launchpad bug 1278511 in unity (Ubuntu) "CTRL-Space no longer works under Unity" [Undecided,Confirmed] https://launchpad.net/bugs/1278511 [17:06] barry, Hmm, seems seb128 just set it to fix committed :-) [17:06] tedg, barry: yeah, commenting on both [17:06] barry, In general that's probably a bregma thing though. [17:07] it's a "we need unity trunk to land in trusty, one day" [17:07] one day soon [17:07] tedg, barry: you can access it by running gnome-control-center.real [17:07] or http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/3643 [17:08] seb128: oh wow. why doesn't .real run when you hit the gear->System Settings? :) [17:08] barry, you get unity-control-center (our new default UI) [17:09] seb128: ah, and this setting hasn't been added to u-c-c yet? [17:09] barry, the Unity xml is missing because unity didn't get a landing for ages [17:09] cf the commit I just pointed [17:09] it's fixed in trunk [17:09] but bregma's ass has been kicked by unity autopilot tests recently it seems [17:09] those guys didn't manage to do a landing for ages [17:09] seb128: awesome, thanks. i will try .real and wait for the fix-released there [17:10] yw! [17:10] barry, the other one should be an ibus issue, please try if unsetting in ibus-setup fixes it [17:11] seb128: yeah, i actually uninstalled ibus ;) [17:11] we're spending more time fixing bugs in autopilot itself than in unity [17:11] bregma, :-( [17:12] bregma, are those regressions in autopilot? can't we just back out the buggy version? [17:12] 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:12] Launchpad bug 1271710 in unity (Ubuntu) "duplicate for #1278582 doesn't list compiz/unity keybindings" [Low,Triaged] https://launchpad.net/bugs/1271710 [17:13] 40 new regressions due to #1278917 [17:13] bregma: yeah, i am struggling with autopilot failures all over the place :/ [17:14] 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] seb128: fair enough. i suppose i should open a new bug on that issue. would that be on unity then? [17:14]