=== _salem is now known as salem_ === Spads_ is now known as Spads === salem_ is now known as _salem === nudtrobert1 is now known as nudtrobert === nudtrobert1 is now known as nudtrobert [05:27] pitti: hey, does current systemd in wily/xenial restart logind on upgrade? I know it doesn't with 226-4 on debian, wonder if that got backported [05:29] Good morning [05:30] tjaalton: wily's (and xenial's) systemd does not restart logind on upgrade any more, this got backported [05:30] ok good, so I can merge xserver.. [05:30] tjaalton: right, this was a blocker for enabling logind support in Xserver, as that apparently immediately terminates X when restarting logind [05:31] yep [05:31] which is quite "meh", but was the pragmatic approach [05:31] I'll just fix the Breaks [05:31] tjaalton: for the lower systemd version? [05:31] yeah [05:32] tjaalton: I'll soon merge systemd (in fact I already have it prepared here), then you can drop that Breaks: delta again [05:32] ah [05:32] maybe I'll just wait then :) [05:32] tjaalton: I was about to upload it today indeed [05:32] though I could test it on wily first.. [05:33] tjaalton: if you need other ubuntu changes, then lowering the breaks: can't hurt; if it's the difference between sync and merge, just stash it in -proposed, and it'll go in with the merged systemd? [05:33] true [05:33] well I'd like to test it first of course [05:34] tjaalton: you can use https://launchpad.net/~pitti/+archive/ubuntu/systemd, those systemd xenial packages are very close [05:34] ok, thx [06:27] kirkland, hi, regarding byobu, adding this seems wrong "+StartupWMClass=gnome-terminal-server" and breaks the bamf matching afaics [06:35] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst [06:37] hey darkxst, enjoy your flight ;) === not_phunyguy is now known as phunyguy [06:41] didrocks, will do ;) [06:43] darkxst: Indeed, have fun. Though does this mean we get to ping you with sponsorship requests now? [06:45] Unit193, you can, if they are in ubuntu-desktop, ubuntu-gnome, desktop-extra packagesets [06:45] Nope! [06:54] Unit193, happy to review other requests, but won't have upload rights for them! [06:55] I poked -motu several hours ago about https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/5608954/+listing-archive-extra, can't submit a MP as the branch is way out of date. [06:56] Unit193: just attach a debdiff to a sponsoring bug? [06:56] this is way easier for a sponsor, and (IMHO) still faster/easier for the creator [06:57] Unit193, many of the udd branches are broken, don't worry to much about MP's unless there is a vcs-bzr packaging branch in the control file [06:57] pitti: Yeah, was just trying to take the easy way out first. :P [07:17] pitti, darkxst, hey [07:17] pitti, maybe you like to take a look at https://launchpad.net/~ricotz/+archive/ubuntu/staging/+sourcepub/5603831/+listing-archive-extra [07:19] ricotz, hey [07:35] good morning [07:37] hey dholbach [07:37] hey seb128 === ara is now known as Guest43853 === nudtrobert1 is now known as nudtrobert [07:51] ricotz: hmm, well, what's the solution, then? [07:51] ricotz: as of wily, unity no longer displays byobu's icon [07:52] ricotz: instead, it just shows the gnome-terminal [07:53] ricotz: I honestly have no idea what +StartupWMClass=gnome-terminal-server means, but it was suggested in a comment in the bug and it seems to fix the problem for me [07:53] kirkland, with this change it seems the other way around now, so always matching byobu [07:54] (I am not using unity though) [07:55] ricotz: okay, well, I could use some help with this, then [07:55] kirkland, so if you actually start gnome-terminal it doesn't show byobu for you [07:59] this was meant to be a question ;) [08:05] ricotz: yep, that does seem to be the case [08:05] ricotz: I'm open to other suggestions [08:08] kirkland, you mean the bybou-icon shows up regardless? (so you mean "no" it always show byobu for you too) [08:12] using "StartupWMCLass=byobu" while passing "--class=byobu" to gnome-terminal should somehow work [08:44] hi, anybody wants to sponsor a pbuilder merge for me? [08:48] sitter, Riddell: several KDE tests now fail with "FAIL stderr: cc1: warning: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C"; e. g. kio, plasma-workspace, kcoreaddons [08:48] these could be quiesced with "allow-stderr", but presumably this should be fixed more properly? [08:48] I guess that appeared with new gcc in xenial [08:51] pitti: piware.de doesn't seem very pleased with the world. [08:52] StevenK: indeed, thanks for the ping; apache started [08:52] I stopped it this morning as I suffered a huge flood of wordpress login attempt DoS/brute force [08:53] pitti: It still times out over IPv6, at least. [08:53] StevenK: WFM (also IPv6) [08:54] Right, IPv6 looks to be suffering from conference fun. [09:03] pitti: forward to kubuntu-devel [09:04] sitter: danke [09:12] sil2100, I hadn't realized that the ocaml transition already started, so yes, looks like an ocaml merge is required [09:23] hi cjwatson do you have any advice for lp: #1510451 [09:23] Launchpad bug 1510451 in Ubuntu "Sync skype4py 1.0.35-1 (multiverse) from Debian unstable (contrib)" [Undecided,New] https://launchpad.net/bugs/1510451 [09:23] ? [09:27] dholbach, LocutusOfBorg1, https://launchpad.net/ubuntu/+source/skype4py/1.0.35-1 ? [09:27] dholbach, what issue did you get? It was just in NEW I think, I newed it like 10 minutes ago [09:28] <3 thanks [09:28] :D [09:28] yw [09:28] I didn't see it in the queue [09:28] but I might be wrong === vrruiz_ is now known as rvr [10:13] pitti, seb128: you did uploads for bluez recently but those are not present in https://code.launchpad.net/~bluetooth/bluez/ubuntu which should be the primary source for the bluez so we can switch to dual landing as soon as we have bluez5 in Touch. Also the idea was to do MPs so we can review those changes in a group as those affecting a lot of different things nowadays [10:15] morphis, right, I wanted to do the update before wily but you add work staged there which was not suitable for the archive before release [10:15] ok [10:15] I think I pinged you on IRC back then to say I was going to do a version update directly [10:15] seb128: right, there was something ... I remember [10:15] but yeah, we should use the vcs from now on [10:16] seb128: was just commenting on https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1510570 which brought me to the thought how we can make sure every bluez landing is done this way rather than direct uploads [10:16] Launchpad bug 1510570 in bluez (Ubuntu) "BLE pairing fail" [Undecided,Confirmed] === greyback__ is now known as greyback [10:28] tjaalton: 227-2ubuntu1 is in -proposed FYI [10:33] utlemming: hey, how are you? [10:33] utlemming: could we please have http://cloud-images.ubuntu.com/xenial/? :-) [10:41] pitti: Hola! We're working on a new, improved way of building cloud images for xenial, but we aren't quite there yet. What's being blocked by the lack of images? [10:42] Odd_Bloke: ah, ok [10:42] Odd_Bloke: mostly that we need them for running tests; for now I wrote a script which builds a xenial image based on the latest wily image by dist-upgrading [10:42] Odd_Bloke: but developers have to do that too when they run tests locally [10:43] Odd_Bloke: so it's not OMGurgent, but I wondered if that's just a simple forgotten "update cron job" [10:43] but it seems it's not [10:44] pitti: Understood. :) [10:44] Odd_Bloke: out of interest, how are you going to build them? [10:45] pitti: So for vivid/wily, we produce an ext4 filesystem in Launchpad, and then use kvm instances to make all the various artifacts that you see in cloud-images.ubuntu.com. [10:46] pitti: But with the shift to POWER8, we're shifting to build a lot more stuff in the buildds. [10:46] pitti: (Well, and because running the amount of kvms we were/are running is unsustainable on the hardware we have available to us) [10:46] Odd_Bloke: interesting, so similar to how we produce desktop images [10:46] pitti: Our entire build tooling assumes that things will happen in a KVM instance, and so there's a decent amount of brain surgery that needs to happen. [10:47] pitti: I believe so; one difference is that we produce images with serials, so we want all of (-disk1.img, .tar.gz, ...) to have exactly the same packages. [10:47] Odd_Bloke: OOI, did you ever try vmdebootstrap? that's how I build VMs for Debian sid locally, and while it's a bit clumsy it works reasonably well [10:48] pitti: So we use the same buildd process to build all the various artifacts using binary hooks. [10:48] Odd_Bloke: (this is totally off-topic of course, just some experience exchange) [10:48] pitti: I haven't come across it, no. :) [10:48] Odd_Bloke: this came up every once in a while, in questions like "how can we build a snappy image (or similar) with one proposed package for testing" [10:48] and for these scenarios, or local testing, it's much nicer to have something available which you could run on your laptop or a cloud image [10:49] LP builds are really hard to reproduce [10:49] Yeah, agreed. [10:49] but maybe LP is actually using something these days which one *can* reproduce, I haven't checked in a while [10:50] Odd_Bloke: anyway, thanks! I'll keep the "geneate dist-upgrade image every day" approach for a bit === nudtrobert1 is now known as nudtrobert [10:50] pitti: Cool, appreciate it. :) [10:57] pitti: LP livefs builds are certainly reproducible (it just uses livecd-rootfs); it would perhaps be worth some effort to make it easier [10:58] cjwatson: ah, just that now? nice! It used to be this huge cdimage scriptery [10:59] so we're essentialaly adding a cloud image flavor to livecd-rootfs? [11:01] pitti: livecd-rootfs has had cpc for a while, but Odd_Bloke is extending it, indeed [11:02] pitti: for desktop images, LP builds the squashfs component but cdimage is still involved after that (mainly because of needing to add a package pool etc.) [11:02] pitti: but I believe that cloud images will just be spat straight out by LP [11:03] @pilot: out [11:03] Error: "pilot:" is not a valid command. [11:03] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [11:03] cjwatson: ah right, that was it; I thought in the past there was at least another layer of live-build (that's how we built the first -kylin flavors), did that go away now too? [11:03] pitti: Kylin was always kind of weird [11:04] pitti: I think it was done out of band for a while. There was also an even weirder thing with the Ubuntu Chinese Edition before it was taken over by Kylin [11:05] cjwatson, it only gets worse when you see what the unofficial spins do! [11:05] Yeah [11:05] pitti: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/view/head:/lib/cdimage/build.py#L356 (bring scuba gear) [11:28] pitti: excellent, thanks [11:31] darkxst: congrats and thanks for your first pilot shift! [11:43] darkxst, you're a hero! [11:43] thanks a lot! :-D [12:06] dholbach, pitti, np, ended up being a busy evening all up ;) [12:09] doko: hi, do you know what release of glibc 16.04 is going to ship with? === _salem is now known as salem_ [12:52] tseliot, >= 2.21 [12:52] doko: ok, thanks [13:06] "squid3" is moving to "squid" and I need to adapt the Ubuntu delta for conffiles we added. [13:06] I see many dpkg-maintscript-helpers calls (it uses cdbs) which I mostly understand fine. [13:06] But how is it handling the conffiles being moved from one package to another? [13:07] It seems to just duplicate the dpkg-maintscript-helper calls in both the squid package and the now transitional squid3 package. [13:07] Is this the right way to do it and what's the mechanism involved? I'd like to understand so as not to botch this merge. [13:07] rbasak: the package it moves to needs a .maintscripts with "mv_conffile", see line 2 (press h for help or q to quit) [13:07] erk [13:07] rbasak: see "dpkg-maintscript-helper(1)" [13:07] pitti: yeah, so it's calling that. I get that part. [13:07] rbasak: IIRC the old packge doesn't need any magic [13:08] Hmm. The old package has all the same magic. [13:08] that'll generate a preinst to remove an unmodified file, and postinst to handle a modified one [13:08] Unless I've botched something. [13:08] rbasak: that seems redundant; the transitional package should just stop shipping the conffiles [13:09] mv_conffile doesn't move between packages, it just handles renames. [13:09] oh, right [13:09] erk, it's that time again [13:09] Yeah the Debian maintainer has definitely put dpkg-maintscript-helper mv_conffile (and rm_conffile) calls in both the squid and squid3 packages. [13:09] like 20 years, and indeed there's *still* no way to move a conffile [13:09] dpkg itself will take over conffiles with a Replaces *if* the conffile has the same path. [13:10] squid does have Replaces: squid3 [13:10] But are the conffiles in a new location? [13:10] I'm assuming yes. [13:10] Yes [13:10] Moving from /etc/squid3 to /etc/squid [13:10] Right, so the replaces won't help you there of course (it helps for other bits, but not for files that have moved). [13:10] rbasak: ah, then you need some preinst script to mv them manually if modified, or rm them if unmodified [13:10] I also need to take care of things like /etc/apparmor/usr.bin.squid3 or whatever and /etc/init/squid3 that we were adding in a delta. [13:11] infinity: hmm. So does that mean the package is broken in Debian? [13:11] Probably. [13:11] But for subtle values of "broken". [13:12] Any suggestions? [13:12] Are the squid mv_conffile calls in preinst calling with the "package" argument and, if so, is it pretending to be "squid3"? [13:12] Cause that might work. [13:13] Yes, it's doing that. [13:13] ie: if squid's preinst moves squid*3*'s conffiles, then replaces them. [13:13] In both squid... and squid3... maintainer sscripts [13:13] That might actually function. [13:13] Because Replaces happens after preinst. [13:13] preinst -> unpack (replaces) -> postinst [13:13] Basically. [13:14] So, if you can get squid3's conffiles to all move to the new location before squid unpacks, then squid will take them over. [13:14] But that suggests that squid3.preinst dpkg-mainscript calls aren't needed, and it's still doing that? [13:14] May still lead to a prompt or two you didn't want, but you can experiment with that. [13:14] Yeah, I see no reason squid3 needs any of the magic at all. [13:15] Will it cause any harm? [13:15] Unless he was trying to work around nondeterministic unpack order. [13:15] Because I'm tempted to follow Debian's pattern exactly for the Ubuntu delta bits here. [13:15] Now that you've explained the mechanism and provided you think that's OK :) [13:16] I'm not sure what happens with two identical mv_conffile calls. I'd like to think the second is a no-op. [13:16] If the Debian packages were actually tested, it probably is. :P [13:17] A more elegant way to force the ordering would probably have been to make squid3 Pre-Depends on squid. [13:17] * rbasak looks [13:17] So you guarantee the mv_conffile from squid completes and the conffiles are taken over before squid3 is upgraded and its files removed. [13:18] Yes, it does. [13:18] Package: squid3 [13:18] Pre-Depends: squid (>= ${source:Version}) [13:18] Oh. Then the squid3 Mv_conffile stuff is completey redundant. [13:18] I feel like that's left over from debugging ordering problems, probably. [13:18] OK [13:18] If you think it's harmless then I think I'm best following the pattern though. [13:18] Less confusing for future merges. [13:19] Because with a pre-depends, squid will preinst/unpack/replaces/postinst all before squid3 even preinsts. [13:19] So, squid3's maint scripts become completely useless at that point, as you've already moved everything around. [13:19] Hmm. [13:19] I think it really should be fixed in Debian to avoid the redundancy, IMO. [13:19] There are also rm_conffiles [13:19] I guess that wants to be in squid3 but not squid? [13:19] Both are in both. [13:20] squid3 should just be a completely empty package with no maintainer scripts, and all this magic should be in squid. The pre-dep pretty much requires that anyway. [13:20] s/requires/assumes/ anyway. [13:21] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801564 looks like fun [13:21] Debian bug 801564 in squid "squid: prompting due to modified conffiles which were not modified by the user: /etc/squid/squid.conf" [Serious,Open] [13:24] rbasak: That one's about squid 2.7 -> squid 3.5, we don't have that issue. Maybe. I hope. [13:24] rbasak: Since our squid is squid3. [13:25] Yeah I think Precise is on 3, so we don't have to worry about 2.7. [14:05] pitti: looks like we had a timeout for armhf in one of the linux-meta-lts-utopic autopkgtest tests. would it be possible to re-run it? [14:06] pitti: here's the link for the test log: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/armhf/v/v4l2loopback/20151027_025222@/log.gz [14:06] pitti: and the command to re-run it: run-autopkgtest -s trusty -a armhf --trigger linux-meta-lts-utopic/3.16.0.52.43 v4l2loopback [14:06] henrix: done [14:06] pitti: awesome, thanks! [14:07] henrix: no worries! I think there are some more MISSes on http://people.canonical.com/~kernel/status/adt-matrix/ though, I'll check [14:07] I retried a bunch of them this morning after fixing kernel installation even harder [14:07] like the four MISSes on http://people.canonical.com/~kernel/status/adt-matrix/precise-linux-meta.html [14:08] apw: ^ are these still current? we do have runs for those [14:08] e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-precise/precise/armhf/o/openvswitch/20151028_101407@/log.gz for the openvswitch one [14:08] pitti: heh, yeah. i just started looking a few minutes ago and that one caught my attention as it was REGR [14:08] pitti, let me check i didnt' disable it [14:08] pitti, yeah its 2 hours old, bah [14:09] pitti, i stopped it to prevent it eating its own cache, and ... failed [14:11] pitti, henrix, ok that looks better [14:17] apw: the three MISSes on http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta-raspi2.html have results too [14:18] apw: queued http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.cmds now, but without ppc64 [14:18] hm, https://launchpad.net/ubuntu/+source/qemu/1:2.4+dfsg-4ubuntu1/+build/8200106 build on ppc64el fails, but seems to do so mysteriously. the build log just says "Session terminated, terminating shell... ...terminated." [14:18] hm, I already retried that two times [14:18] pitti, looking ... [14:18] hallyn: that's a hang after inactivity [14:20] that is, it was inactive for 2.5 hours so was autokilled [14:20] hm. Build killed with signal TERM after 150 minutes of inactivity [14:20] do you start a test suite around there perhaps? [14:20] but that's suspicious, [14:20] which might not autoflush its logs [14:20] bc the builder says the build time was 2'44" [14:21] right, so it probably spent 14 minutes getting up to that point and then hung [14:21] guess a porter is my best bet [14:21] I think there may not be a porter box you can use at the moment, due to the power8 switch [14:21] pitti, [14:21] I: [Wed Oct 28 14:20:09 2015] - Fetched test result for acpi-call/1.1.0-2/armhf 20151028_102038@: pass (kernel linux-meta-raspi2 4.2.0-1013.19) [14:21] I: [Wed Oct 28 14:20:09 2015] - Fetched test result for asic0x/1.0.1-1/armhf 20151028_101929@: fail (kernel UNKNOWN 4.2.0-1013.19) [14:21] pitti, so thats rather odd, i will trying and figure out why one is matched and the other not [14:21] d'oh [14:21] hallyn: you can experiment in a PPA: http://blog.launchpad.net/ppa/ppas-for-ppc64el [14:21] crank up debugging around there or something [14:22] apw: oh - E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/i/isl/libisl13_0.14-2_armhf.deb Temporary failure resolving 'ftpmaster.internal' [14:22] apw: time for another try I guess [14:22] pitti, oh yeah its one of your "tempfail" reported in the test, but not detected as tmpfail but the greater adt thing [14:23] pitti, and a tricky one to detect of course [14:23] hallyn: (and you can watch the build log and cancel after the hang, so you won't actually have to wait nearly three hours for each iteration) [14:23] apw: requeued [14:24] apw: yeah, that woudl ideally count as "tmpfail" indeed [14:30] cjwatson: thx. looks like the next step was supposed to be running 'dtc -o qemu-build/pc-bios/bamboo.dtb pc-bios/bamboo.dts [14:37] hallyn: I wonder if this is your first build for power8 [14:38] cjwatson: nope, https://launchpad.net/ubuntu/+source/qemu/1:2.3+dfsg-5ubuntu9 [14:39] hallyn: the wily toolchain doesn't default to power8 [14:40] oh [14:40] hallyn: and that was on the old builders too, though I suspect the power8 switch is more relevant [15:12] pitti: stgraber; should we have a uos session on cgroup boot time configuration (for ppl looking for libcgroup replacement), or do we just accept "use systemd for it, anything it can't do you can't do yet" as the long-term answer? [15:13] seems like that *will8 be the long-term answer anyway... [15:13] short-term ppl seem to want more [15:13] larsu, I'm not getting changed events from gsettings-qt, and I'm wondering why. Looking at this [1], it seems something related to it has recently changed. Maybe you can help me out? [1] https://code.launchpad.net/~lukas-kde/gsettings-qt/queued-processing/+merge/259883 [15:15] hallyn: I don't expect any of us to have time to work on new cgroup features so not sure it's worth making plans [15:15] hallyn: so yeah, use systemd, if that doesn't do it, you can configure things yourself, through cgroupfs or using cgmanager [15:15] right, that ^ seems to be the status quo [15:16] it seems there are still some bugs with that, stgraber found that for some services like lxcfs systemd seems to put those into all controllers [15:16] but well, these are bugs [15:16] hallyn: but if you have something that we should talk about, sure! [15:17] pitti: no i don't care to have a session if it's not needed - thx! [15:17] pitti: we should however talk about shifting the cgroup-login functionality to libpam-cgm [15:17] (not in uos, just here :) [15:18] stgraber: probably cares more than you do, [15:18] i assume you (pitti) are just happy to have that patch out of systemd :) [15:18] hallyn: ah, ye olde cpu hotplug bug [15:18] workaround [15:18] hallyn: heh, yes; although AFAIUI there will still be some bit left? [15:18] it tends to subtly break every now and then, although we now have an autopkgtest for it [15:18] hallyn: what happens if you have both the patched systemd and libpam-cgm installed? [15:19] but that of course still doesn't fix the cpu hotplug issue [15:30] stgraber: systemd still creates the directories, but you end up in the libpam-cgm cgroups. (it's what i have on my laptop) [15:30] so i'm in /user/serge/1 for most cgroups except 1:name=systemd:/user.slice/user-1000.slice/session-c4.scope [15:34] hallyn: ok, good. So we can have LXC depend on libpam-cgm, promote it to main (source is already in main so no MIR required, the package was in universe just because it was unused), then once that's done we can drop the patch from systemd. [15:35] hallyn: did you get someone from security to look at libpam-cgm? [15:35] good q. i can't recall whether sarnold looked at it or not [15:35] (i've bugged him on so many...) [15:36] mitya57, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802427 isn't 3.5 not yet supported? [15:36] Debian bug 802427 in python3.5-doc ""async" and "await" keywords are not highlighted as such" [Minor,Open] [15:37] hallyn: so I'd say, re-check with sarnold that libpam-cgm looks sane, then I'll make LXC recommend it and soon after that we can drop the patch from systemd, sounds good? [15:39] sounds good to me. sarnold: please ping me when you're in [15:41] jgdx: that was an issue with qt's event dispatching which should be fixed now [15:41] jgdx: do you see the change events in `gsettings monitor`? [15:42] larsu, yes. And I just commented after doing a bisect. [15:43] jgdx: it works without that patch?! [15:44] larsu, r71 works fine, yeah [15:44] jgdx: neat :) how can I reproduce? [15:46] larsu, let me make a couple of steps for you. [15:47] larsu, do you have System Settings installed? [15:47] ubuntu-system-settings that is [15:47] yes [15:48] I'd prefer a small test program if you have that [15:48] larsu, sure [15:48] jgdx: only if it's not to much effort though of course :) [15:49] larsu, nah, it'd be good to isolate completely to make sure I'm not blaming gsettingsqt needlessly. [15:49] ya, thanks [16:06] larsu, okay, here http://pastebin.ubuntu.com/12990612/ [16:07] larsu, if your idle-timeout was 42, you're outta luck === mbiebl_ is now known as mbiebl [16:09] larsu, all you do now is switch between r71 and r72 and observe the difference in behaviour. [16:11] larsu, (i.e. on r71 “Changed events” increases on each change, where on r72 it remains 0) [16:12] jgdx: indeed. cool stuff [16:16] jgdx: that's because it doesn't change ... [16:16] it's on 42 [16:16] changing it to 42 doesn't actually change it [16:17] so you don't get the event [16:17] don't know why that commit should change this behavior though [16:18] larsu, maybe the second time, but if you open that qml when idle-timeout is 600 (like on my system), it changes from 600 to 42. On 71 that emits changed, on 72 it doesnt. [16:18] Sorry, I should've used random values. [16:19] so when both buttons are 42, of course that's not going to emit anything [16:21] jgdx: this works for me [16:21] if it's on 600 and I change it to 42, I get the changed event [16:21] larsu, where, on the counter or in gsettings-monitor? [16:22] jgdx: both [16:22] hm, I don't when on gsettings-qt 0.1+15.04.20150810-0ubuntu1 [16:25] I have a version from August [16:25] which *should* include that fix from June... but apparently it doesn't [16:25] is that version only in xenial? [16:25] * larsu should upgrade [16:25] i'm on vivid+overlay [16:26] can't you just build r72 from source? [16:26] yes, doing that right now [16:26] I wonder why this is not in vivid - the fix is from ages ago [16:27] hasn't vivid frozen over ages ago? :p [16:27] heh, not that long ago ;) [16:28] larsu, what's the eta on your r72 build? [16:29] already playing with QML2_IMPORT_PATH [16:31] jgdx: ok I can reproduce [16:32] larsu, thanks, glad to hear it [16:32] I get the change event when changing it from outside the program, but not when clicking the button [16:32] that's what i see too === fionnan_ is now known as fionnan === henrix_ is now known as henrix [16:53] jgdx: bah, setting QML2_IMPORT_PATH has no effect [16:53] any idea how I can make it load this module without installing it? [16:54] larsu, .local/lib install and ldconfig? dunno [16:54] uninstalling the system's version makes it work :D [16:57] jgdx: got it. [16:57] ok this is kind of bad [16:57] and not easily fixable [16:58] :s [16:58] the problem is that the qqmlpropertymap gets set from qml, so the next time settingChanged() is called, it doesn't actually emit the signal because it already has the same value [16:58] and we need that to avoid endless loops [16:59] and apparently back when we used a direct connection, the value wasn't set yet [17:15] jgdx: ok I have a fix, but it breaks the tests - they assume that values are changed immediately [17:16] all of this because of that one stupid qt bug [17:16] that nobody seems to want to fix :/ [17:17] larsu, ugh.. let me know when you have a branch, I can confirm the fix in uss as well. [17:18] jgdx: might not make it before tomorrow. could you please file a bug? [17:20] larsu, https://launchpad.net/bugs/1503693 [17:20] Launchpad bug 1503693 in Canonical System Image "Dim timeout gsetting key not set anymore" [High,Confirmed] [17:20] thanks [17:28] jgdx: is there a way to let a qml test wait until some change signals came in? [17:32] larsu, signalspy? [17:33] larsu, but the event loop need to run. [17:33] jgdx: it always runs in qml, doesn't it? [17:34] larsu, in that case, signalspy is the only thing you need [17:35] cool thanks [17:51] cjwatson, doko, cyphermox: pushed a few no-change rebuilds, the prooftree installability problem will be fixed once the new no-change rebuild of coq will finish [17:56] sil2100: ok [17:56] need sponsoring? [17:56] hallyn, good morning. :) I can't recall if I've looked at libpam-cgm either. I know I had a tab open for it for a while but thought I heard that it'd been supplanted by systemd integration work instead [17:57] nope , it's still the plan [17:57] just wsn't in plan for 15.10 [18:04] i think http://changelogs.ubuntu.com/changelogs/pool/universe/m/mysql-5.6/mysql-5.6_5.6.27-0ubuntu0.14.04.1/changelog the last commit here is causing this problem for me: http://paste.pound-python.org/show/SBk7YQWRrQAH7NaRJikD/ [18:04] cyphermox: no no, so far all packages I poked were universe ones - not that I looked for universe ones, just going through the list as is [18:05] not entirely sure. thoughts? the date of the commit and the problem is matching up [18:08] tsukasa_: did you see my recommendation in #ubuntu just now? [18:08] sil2100: ack [18:20] hallyn: aha, thanks :) [18:23] I've found a package (https://tracker.debian.org/pkg/fop) which I believe can be synced since the Ubuntu delta is now included in the Debian package as well. However, I noticed this package is in main and I skimmed the list of new dependencies and at least one of them is in universe so it won't build out of the box on Ubuntu. Is that a concern or should it be synced regardless and then we can figure out what we do about the dependencies. [18:23] (It's not clear to me who makes the decisions on which packages should go through the mir process and which should be worked around) [18:57] cyphermox, doko, cjwatson: so, the reverse-deps of coq I will rebuild and fix once all coq binaries are built [18:57] Since those need no-change rebuilds mostly, but I can't do it earlier [18:57] A few archs still building [19:12] infinity, pitti, mdeslaur: so I'm trying to work on my TB action item to document the exceptions for juju, maas, etc. and I'm having a very hard time *locating* the maas exception that was approved - either in IRC meeting logs or in the mailing list. Do any of you remember when/where this happened, and what was approved? [19:17] if it helps, the emails I have related to that are from 27 feb 2015 through 2 mar 2015 [19:23] sarnold: oh, is this somewhere in the "please demote maas 1.2" thread? [19:23] slangasek: yeah, that's the thread, but I don't have any TB-related stuff, just their mentions that they were going to talk to TB at the time [19:25] * mdeslaur is still looking [19:28] slangasek: last we discussed, we were waiting for a new proposal from them: http://irclogs.ubuntu.com/2015/03/17/%23ubuntu-meeting-2.html [19:31] mdeslaur: so... we don't actually have a maas exception on the books? [19:31] slangasek: that would be my understanding, yes [19:31] that's interesting; how did I take an action item to document it in that case :) [19:32] fwiw what sent me looking is that there is a maas SRU in the queue [19:32] documenting that there isn't any is easy :) [19:32] lamont, roaksoax: ^^ [19:34] slangasek, got upgrade aborted goign to wily, any advice? [19:36] lamont, roaksoax: we need to have an actual signed-off test plan for the stable updates in order to let this maas 1.8.3 SRU in; it seems no one has reported regressions against maas 1.7 in trusty, but it also appears the SRU team didn't follow the procedure because we all gaslighted ourselves into believing there was a SRE approval in place [19:37] lamont, roaksoax: ("It has been QAed in a CI lab" is not sufficient detail here) [19:37] pmcgowan: aborted how / with what exact error message? [19:38] slangasek, I may have gotten it to finish [19:39] it just said upgrade aborted, unstable blah blah [19:39] I reran the upgrader and it said it finished [19:39] after an autoremove [19:39] slangasek, anything else I should check before reboot? [19:40]