[06:10] <jam> bigjools: ping if you are still around
[06:10] <bigjools> jam: I am here
[06:10] <jam> bigjools: /wave.
[06:10] <bigjools> surprisingly awake too :)
[06:10] <jam> We've been landing our changes into the 1.2 branch
[06:10] <jam> but I'm realizing they should also get merged into trunk, right?
[06:10] <bigjools> I saw
[06:10] <jam> I tried doing the obvious merge, but there are a handful of conflicts.
[06:10] <bigjools> ideally they need to start in trunk because I wanted to do a bug-only SRU into quantal :(
[06:11] <jam> bigjools: I can revert the changes, but the bug was on the 12.10-stabilization
[06:11] <jam> which I thought meant it needed to be in the 1.2 branch.
[06:12] <bigjools> It does.  I had intended to SRU features later but I realise that the bugtask was a bit misleading :(
[06:12] <jam> bigjools: so, if you want I can revert what I've landed so far, retarget them onto trunk.
[06:12] <jam> There is still the fact that 1.2 doesn't merge cleanly into trunk, should it?
[06:12] <jam> or are they intended to diverge?
[06:14] <jam> (So in the *immediate* term, I can put together my teams changes as a single branch, which you can land once you have done the bugfix SRU, and are ready to do a feature SRU)
[06:14] <jam> though I imagine any branch will bitrot if not landed soon
[06:16] <jam> bigjools: is it worth doing that effort?
[06:16] <bigjools> they are diverged
[06:17] <bigjools> (sorry had to deal with a large insect)
[06:17] <bigjools> you need to cherry pick revisions
[06:17] <jam> so, they *have* diverged, but it would be possible to converge them. s there something you don't want in trunk that is in 1.2?
[06:17] <bigjools> hmmmm let me think more about the feature branch
[06:18] <bigjools> there's stuff in trunk we don't want in 1.2
[06:18] <jam> bigjools: right, I'm talking about the other direction
[06:18] <jam> I was thinking to land our code in 1.2 then merge up into trunk
[06:18] <bigjools> there *might* be stuff in 1.2 - jtv has been landing there first and forward porting
[06:18] <jam> but it isn't possible today because of divergence on both side.
[06:18] <jam> mostly simple textual conflicts that are fairly easy to resolve
[06:18] <bigjools> you should be able to CP stuff though?
[06:19] <jam> bigjools: we can, but it seems a waste to do so unless there is stuff you really don't want in trunk
[06:19] <bigjools> if you can work out which revisions are missing we can decide
[06:19] <bigjools> but there should be nothing that's not in trunk
[06:19] <bigjools> unless there was a separate fix landed just for a bug in 1.2
[06:19] <jam> I'm willing to do the conflict cleanup. The main problem with specific revisions is that cherrypicking makes it hard to see where things specifically come from.
[06:20] <bigjools> ok thanks
[06:31] <jam> bigjools: so one diff between 1.2 and trunk that I think you worked on. There is a pserv task "import_pxe_files" in 1.2, and "import_boot_images" in trunk.
[06:31] <jam> I'm not sure which name you want to use
[06:31] <jam> .
[06:32] <bigjools> jam: rvba renamed the former to the latter; he needs to backport it
[06:32] <jam> k
[06:32] <jam> I'll make sure to use boot_images after the merge.
[06:32] <bigjools> rightyo
[08:27] <bigjools> jam: I think you need to revert the 1.2 features and land them on trunk
[08:47] <jam> bigjools: i'm willing to do so, do you know an ETA when 1.2 would be opened again.
[08:47] <jam> I guess at this point, we would essentially just hand it off to your team for that, though.
[09:10] <jam>  /wave mgz, dimitern
[09:11] <dimitern> jam: /wave :)
[09:11] <jam> I'm sitting in mumble if you guys would care to join.
[09:12] <dimitern> ok
[09:14] <jam> w7z: poke
[09:15] <mgz> hey jam
[09:17] <mgz> ...I wonder if I can find an extra network cable
[09:18] <jam> mgz: I've got about 10 of them here.
[09:18] <jam> If you feel like dropping by :)
[09:18] <jam> mgz: care to join us on mumble?
[09:19] <jam> bigjools: https://code.launchpad.net/~jameinel/maas/1.2-remove-kernel-opts/+merge/133424
[09:20] <jam> and now https://code.launchpad.net/~jameinel/maas/1.2-remove-kernel-opts/+merge/133425 to properly target 1.2
[09:27] <bigjools> jam: if you make a branch targeted to 1.2, we can land it after the first SRU
[09:27] <jam> bigjools: sure
[09:27] <jam> the patch is essentially revert this revision :)
[09:27] <bigjools> ok :)
[09:27]  * bigjools heading off shortly, tired.com
[09:29] <jam> mgz: https://code.launchpad.net/~jameinel/maas/1.2-remove-kernel-opts/+merge/133425
[09:49] <jam> mgz, dimitern: https://code.launchpad.net/~jameinel/maas/merge-1.2/+merge/133418
[09:59] <jam> mgz: DatabaseError: column maasserver_tag.kernel_opts does not exist
[09:59] <jam> LINE 1: ...er_tag"."definition", "maasserver_tag"."comment", "maasserve...
[10:05] <jam> evilnickveitch: just to let you know, I'm landing a 1.2 merge  => trunk which includes your doc fixes
[10:06] <evilnickveitch> jam, thanks for the headsup
[10:07] <jam> mgz, dimitern: https://code.launchpad.net/~jameinel/maas/land-kernel-opts-in-trunk/+merge/133434
[10:11] <w7z> failure is https://jenkins.qa.ubuntu.com/job/maas-merger-quantal/264/console
[10:52] <jam> mgz w7z: Did you see bug #1073090 ?
[10:53] <jam> I didn't think this was specific to something we've changed, but I could be wrong.
[10:53] <w7z> looking
[10:54] <jam> w7z: from what I can see, we already have: 'available_nodes.filter(status=NODE_STATUS.READY)'
[10:54] <w7z> hm, we probably inherit the same dodgy logic for other constraints though
[10:54] <jam> so get_available_ shouldn't be allowing it if the status isn't actually ready.
[10:55] <jam> though maybe juju keeps poking at us for a specific node, and the status goes to READY before some action actually finishes?
[10:55] <jam> w7z: is it a possible data race between multiple juju requests to acquire a node, and the backend having a specific node ready?
[10:55] <w7z> hm, right, only accepting READY seems fine
[10:56] <w7z> I wonder if a symptom is being misdiagnosed and it's actually some other issue with using maas-name
[10:57] <w7z> when does READY get changed to something else...
[10:58] <jam> w7z: when it is "damn well read
[10:58] <jam> ready"
[10:58] <jam> :)
[10:58] <w7z> in acquire, which is before the api returns
[10:58] <jam> w7z: I think you mean in RELEASE
[10:58] <w7z> so, no obvious chance for maas to mislead juju here
[10:59] <jam> but note, any HTTP level request is inside a transaction that doesn't commit until it returns.
[10:59] <w7z> right, READY->ALLOCATED in acquire, ...->READY in release
[11:00] <w7z> I think the bug description is just wrong
[11:00] <jam> w7z: right, and the API level is "get_available(), node.acquire()"
[11:00] <jam> so we shouldn't return a node without it already being marked acquired.
[11:01] <w7z> the issue is that if you try to allocate more than one machine with the same maas-name constraint, juju will get no possible options for the second, and be stuck in pending
[11:01] <w7z> the fix being, don't use that constraint then
[11:01] <dimitern> jam, mgz: my branch is ready for review https://code.launchpad.net/~dimitern/maas/1.2-node-view-shows-kernel-params/+merge/133449
[11:02] <jam> w7z: it sounds more like if you do a deploy before the machine has finished being ready, juju will just stop trying
[11:02] <w7z> I don't think he's actually confirmed that, though release does seem optimistic
[11:03] <jam> becoming ready
[11:03] <w7z> sending reboot then immediately putting in READY may not be good enough
[11:04] <w7z> I don't think that's what he's observing though
[11:04] <jam> w7z: from what I can pull out of the bug comments, the issue is that you do a 'juju deploy' and it doesn't do anything, because there are no nodes matching the constraint that are READY
[11:05] <jam> then juju doesn't wake up and realize once the machine is actually ready.
[11:05] <w7z> I think what he's seeing is just the known issue with trying to deploy with a set of constraints that returns no acquirable nodes
[11:06] <jam> w7z: is there a specific bug on it?
[11:06] <jam> I agree that it doesn't seem specific to maas-name, just easier to trigger because maas-name can have at most 1 machine available.
[11:07] <jam> dimitern: I'm curious about the CSS in your patch.
[11:08] <w7z> there's a helpful mailing list thread where melmoth was trying to use maas-name... annoyingly it's not the public list >_<
[11:08] <dimitern> jam: the css just sets the line input to be longer on the settings page
[11:09] <jam> dimitern: sure, it just seems odd to have it be tied to '.size12'
[11:09] <jam> .size12 doesn't seem related to 'input'
[11:09] <dimitern> jam: well, it's what was used for other form fields, so I thought I should reuse it
[11:11] <dimitern> jam: the problem is, that you cannot set easily (at least I could not find an easy way) the css class of a form field in the template, that's why I changed the parent and made the child input take 100% width, because it was constrained otherwise
[11:12] <w7z> jam: so, I suspect if the bug reporter checks /var/log/maas/maas.log he will also see "NodesNotAvailable: No matching node is available"
[11:13] <w7z> likewise the juju provisioning agent log will have something along those lines
[11:13] <jam> w7z: right, so where is the failure that is preventing  the *user* from understanding that things aren't going to work?
[11:13] <jam> Is juju deploy failing to give the message immediately
[11:13] <w7z> that juju doesn't forward errors from the provisioning agent to the client
[11:13] <jam> is it not supposed to fail right away
[11:14] <jam> but is failing to retry later?
[11:14] <w7z> if this happened on bootstrap, the client you're running is talking directly to maas, and you'd see the error
[11:15] <w7z> but once the master node is up, all the client does is say "juju please make the state look like this" and the provision agent does all the actions against maas
[11:15] <jam> w7z: sure, and what happens if it can't do so immediately?
[11:15] <w7z> this means any errors after bootstrap go in the provisioning agent log on the master, and the client never sees them
[11:16] <w7z> so, `juju deploy something --constraints=maas-name=bogus` will always succeed... and give you an ever pending machine
[11:17] <w7z> whereas `juju bootstrap --constraints=maas-name=bogus` will fail with the nice error the maas api returns
[11:17] <jam> w7z: as would `juju deploy something --constraints=maas-tag=no-available-machines
[11:17] <jam> where the tag exists, but all machines are busy rightnow.
[11:17] <jam> It may be that juju isn't meant to handle it, as it assumes providers that have capacity...
[11:18] <w7z> right. anything that doesn't return a machine, or any transient error (though things do get retried in some circumstances that I'm still not completely clear on)
[11:23] <Daviey> evilnickveitch: Hey, can you join #ubuntu-server pls?
[11:23] <w7z> so, basically bug 984640
[12:15] <jam> w7z: so the only bit that makes me think bug #1073090 may not be bug #984640 is that the 'retry forever' doesn't seem to be working.
[12:15] <jam> Specifically, after the node *is* ready, it doesn't actually get activated.
[12:18] <w7z> right, juju gets the "there are no acquirable nodes" response and takes that as immutable truth
[12:22] <jam> w7z: I thought juju was supposed to retry forever, if it isn't retrying again... sigh
[12:22] <jam> It feels like they said, no no, you shouldn't care that it isn't ever working because we'll do it again, except we don't do it again.
[12:22] <jam> You don't need any actual information about what is going wrong...
[12:23] <jam> anyway, bath time for the boy, have a good weekend mgz, maybe I'll see you in dota2?
[12:23] <jam> I *think I sent you a friend request, so maybe I'll catch you around there.
[13:14] <dimitern> jam: ping
[13:17] <jam> dimitern: pong
[13:17] <dimitern> jam: so I see the branch is now merged - now what?
[13:17] <dimitern> should I go back to go?
[13:18] <jam> 1: work with mgz tomorrow, 2: if you see roaksoak or smoser online, chat with them to see if we can get them to test the kernel opts once it hits the daily ppa.
[13:18] <jam> 3: work on Go if you run out of things.
[13:20] <dimitern> jam: ok 10x
[14:02] <rbasak> roaksoax: around? In maas-import-squashfs, you have "set -o nounset" but etc/maas/import_squashfs doesn't set RELEASES (commented out) so maas-import-pxe-files fails when running out of trunk. What's your intention here? Do you want RELEASES to be set to an empty string in etc/maas/import_squashf?
[14:05] <roaksoax> rbasak ill have a look in a bit ( taking care of something else right now)
[14:06] <rbasak> OK thanks
[14:13] <roaksoax> rbasak: can you pastebin the failure?
[14:13] <roaksoax> rbasak: and yes i want it to not be set to a string in etc/maas/import_squashfs
[14:14] <rbasak> roaksoax: http://paste.ubuntu.com/1342601/
[14:14] <roaksoax> same as what happens with maas-import-ephemerals
[14:14] <w7z> roaksoax: we've landed all the bits we think you need for customising kernel parameters
[14:14] <roaksoax> w7z: cool, thanks! how can I customize it?
[14:14] <rbasak> roaksoax: I think we need a different test on line 47 then
[14:14] <w7z> can you find a way of trying it out on trunk, and telling us if it does what you need?
[14:14] <w7z> and also what documentation you want :)
[14:15] <roaksoax> rbasak: so my intention there is that if in etc/maas/import_pxe_files quantal has not been set, then maas-import-squashfs should not import anything
[14:16] <roaksoax> w7z: documentation on hjow to add/modify kernel parameters for each particular host or group of hosts
[14:16] <roaksoax> s/host/nodes
[14:18] <roaksoax> rbasak: http://pastebin.ubuntu.com/1342612/
[14:19] <w7z> basically, when creating or modifying a tag, you can supply an optional kernel_opts param (see the for the cli to double check),
[14:19] <w7z> which will then be appended to the kernel opts used by the provisioning server on boot
[14:19] <roaksoax> w7z: an example would be helpful :)
[14:20] <roaksoax> w7z: and you need to let evilnickveitch know too to add that to the documentation on maas.ubuntu.com eventually
[14:21] <evilnickveitch> w7z, yes, that would definitely help!
[14:22] <w7z> it's essentially as per the auto generated docs
[14:22] <w7z> but, specifically
[14:23] <w7z> something like `maas-cli tag create --name=00-default-console --definition=true --kernel_opts=console=ttyS0`
[14:24] <w7z> will make all nodes (the defintion says effectively match everything) boot with the extra kernel param "console=ttyS0" after all the other ones maas uses
[14:24] <w7z> or for a similar thing
[14:25] <roaksoax> w7z: cool, thanks
[14:27] <w7z> the current highbank special case could be redone as a tag like `maas-cli tag create --name=01-highbank-console --definition="contains(/node/product,'Highbank')" --kernel_opts=console=tty`
[14:27] <w7z> or, you can set stuff manually just on one machine
[14:29] <rbasak> roaksoax: this scripts fails on a fresh updated quantal machine (with multiverse enabled for python-selenium): http://paste.ubuntu.com/1342651/
[14:29] <w7z> `maas-cli tag create --name=99-special-snowflake --kernel_opts=whatever_magic_param_here` followed by `maas-cli tag update-nodes 99-special-snowflake --add SYSTEM_ID`
[14:30] <w7z> plus or minus typos
[14:30] <w7z> the naming scheme is something work mentioning in the docs, if multiple tags match, the last in lexi-order will be used, so number prefixing or a similar obvious scheme should be encouraged
[14:45] <Lele_> Hi guys, in 12.10 maas doesnt have the snippets and the maas_proxy file
[14:45] <Lele_> were can i setup http proxy for the image installation
[14:46] <Lele_> oh i found it :) enlist_userdata
[14:51] <roaksoax> Lele_: enlist_userdata is for enlistment, not for installation
[14:55] <Lele_> oh ! i see cause didnt work
[14:55] <Lele_> where i can configure proxy por installation ?
[14:56] <Lele_> roaksoax :)
[14:56] <rbasak> roaksoax: I've filed bug 1076409
[15:03] <roaksoax> rbasak: ack
[16:03] <jtv> Code review needed!  https://code.launchpad.net/~jtv/maas/import-from-configured-mirror/+merge/133505
[16:09] <rvba> jtv: I'll take it.
[16:09] <jtv> Thanks.
[16:10] <rvba> jtv: I've got a few branches up for review my self if you fancy doing some reviewing ;)
[16:10] <jtv> I can get to that pretty soon!
[16:10] <rvba> Cool, ta.
[16:44] <jkordish> so the maas on 12.10 (non clobber version - I'm actually pulling from the daily-builds ppa) - where are the preseed files? can't seem to find it in the docs anywhere :/
[16:47] <roaksoax> jkordish: /usr/share/maas/preseeds
[16:50] <jkordish> roaksoax: wow. that simple.
[16:50] <roaksoax> :)
[16:50] <jkordish> roaksoax: feel like an idoit for missing it. I was doing a dpkg -L on all the maas packages and didn't see it :/
[16:51] <roaksoax> :)
[16:51] <roaksoax> jkordish: the maas-region-controller package installs them
[16:57] <jkordish> thanks roaksoax
[17:05] <roaksoax> jkordish: you're welcome :)
[23:08] <roaksoax> _


[22:24] <krytarik> OvenWerks: "..and your resources are limited, it's simply wasteful to implement two options" - hiloriously enough, the first was meant irt Gnome itself, while the latter is actually mostly about dropping existing options (like just today announced again) rather than adding new ones.
[22:48] <OvenWerks> krytarik: I guess that was my point, gnome has less features and uses more resources.
[22:49] <OvenWerks> add to that, everyone has more resources now than they did in gnome2 days
[22:50] <krytarik> They aren't referring to the software there though, but the dev team.
[22:51] <OvenWerks> Ah, ok.
[22:53] <OvenWerks> In any case, I have found that I could work with any of the DEs that are available. If the rest of the team wanted gnome based, that is what we would work with
[22:55] <ErichEickmeyer> Just seemed as though Plasma would be easiest, especially considering the menus.
[22:56] <OvenWerks> ErichEickmeyer: I didn't see any complaints at the meeting
[22:58] <krytarik> Btw, I also think that Plasma could be an awesome choice of a default DE.
[23:15] <ErichEickmeyer> krytarik: Same, but, at least for this cycle, I think that would cause an uprising. Maybe 19.04 or 19.10 if we were to go down that road. Just my opinion.
[23:15] <ErichEickmeyer> KXStudio uses it (albiet an old version) pretty successfully.
[23:17] <OvenWerks> I think the new one will too
[23:17] <ErichEickmeyer> Fedora JAM uses it successfully as well.
[23:17] <OvenWerks> From what FalkTX has said in various places
[23:18] <krytarik> ErichEickmeyer: ...Didn't you want a reboot? :P
[23:19] <SlidingHorn> s/reboot/revolt/
[23:19] <SlidingHorn> :P
[23:19] <krytarik> But yeah, that's quite a bit of work to get right too.
[23:19] <ErichEickmeyer> LOL
[23:19] <ErichEickmeyer> Yep. Let's give ourselves some time.


[00:04] -queuebot:#lubuntu-devel- New binary: qpdfview [armhf] (hirsute-proposed/universe) [0.4.18-3] (lubuntu)
[00:04] -queuebot:#lubuntu-devel- New binary: qpdfview [arm64] (hirsute-proposed/universe) [0.4.18-3] (lubuntu)
[00:07] -queuebot:#lubuntu-devel- New binary: qpdfview [riscv64] (hirsute-proposed/universe) [0.4.18-3] (lubuntu)
[00:16] <kc2bez> wxl[m]: cala has someone from SOK (season of kde) that has expressed an interest recently. I know [ade] has some things he tagged for hacktoberfest that would be good for a potential GSOC/SOK candidate.
[00:16] <kc2bez> and +1 on a hirsute Lenny
[03:02] <RyuKurisu[m]> Lenny? 🧐
 https://wiki.ubuntu.com/Lubuntu/Marketing/Lenny
[03:05] <RyuKurisu[m]> Ah, that penguin used in the channel logo on matrix
[03:06] <RyuKurisu[m]> I was wondering what its original was 🙃
[03:07] <cool_skeleton_95> Yeah same lol, I wasn’t entirely sure what it was meant to be
 I'm not sure which Lenny is in Matrix but I am guessing Lenny of Borg?
[03:09] <RyuKurisu[m]> kc2bez you mentioned that what I'm trying to do in -offtopic (whoops, meant to post it here) was already possible with the current installer?
 I think with manual partitioning some of that is possible, yes.
[03:10] <RyuKurisu[m]> I'm trying to script this tutorial: https://mutschler.eu/linux/install-guides/ubuntu-btrfs/
[03:12] <RyuKurisu[m]> <lubot "<kc2bez> I think with manual par"> Which parts would be possible?  The subvolumes?  Or the encryption?
 I think the encryption part. You may have to create the subvolumes after installation but that should be possible from what I know about BTRFS.
[03:14] <RyuKurisu[m]> AFAIK the installer doesn't create subvolumes for root, home or swap, or did I miss something?
 The installer does not create the subvolumes yet, there is a WIP upstream to support that.
 Calamares just released a new version today. I haven't got around to looking at that yet.
 I have the one before that in my ppa https://launchpad.net/~kc2bez/+archive/ubuntu/testing
[15:53] <RyuKurisu[m]> I've been reading into Calamares, and apparently it creates a root (@) and home (@home) subvolumes when selecting Btrfs during installation.  At least that is currently the default, but one maintainer is pretty adamantly about removing that for distro or user specific set up.
[16:06]  * RyuKurisu[m] will check the next time I'm on my laptop 😎
[19:10] <KGIII> It's snowing again. Hopefully it'll stick around this time. I normally have at least a couple of feet by now. http://www.baldmountaincamps.com/webcams.html
[19:27] <KGIII> Oops. That was meant to go in off-topic.
[22:16] <RyuKurisu[m]> <KGIII "Oops. That was meant to go in of"> We all have moments that we post something in the wrong channel 😅
[22:20] <kc2bez> Yeah, it is all good. :D
[23:08] <wxl[m]> <RyuKurisu[m] "We all have moments that we post"> I never do. Ever.
[23:09] <kc2bez> True ^
[23:16] <tsimonq2> 🤣
[23:33] <wxl> @kc2bez: remember the whole weird sddm on pi thing? check this out:
[23:33] <wxl> 1530 < Razathorn:#kubuntu> FWIW, found out why SDDM didn't load on raspberry pi 4 on server.  Desktop firmware included the pi 4 config to enable FKMS 3d capabilities and without that, SDDM refuses to load.  Coppied 20.10 desktop firmware config settings over to mine and 20.04 server now loads SDDM.
[23:34] <kc2bez> I was reading over at #SDDM
[23:34] <kc2bez> I asked the question ;)
[23:37] <kc2bez> [18:17:17] <kc2bez> Razathorn: what exactly did you add?
[23:37] <kc2bez> [18:23:04] <Razathorn> in the firmware filesystem (fat fs that contains vmlinuz and configuration and boot loader handed off from the pi) I added the following lines:
[23:38] <kc2bez> [18:23:04] <Razathorn> dtoverlay=vc4-fkms-v3d
[23:38] <kc2bez> [18:23:04] <Razathorn> gpu_mem=128
[23:38] <kc2bez> [18:23:04] <Razathorn> start_x=1
[23:38] <kc2bez> [18:23:04] <Razathorn> disable_overscan=1
[23:39] <kc2bez> [18:23:55] <Razathorn> start_x is probably not needed as it just enables the camera port
[23:39] <kc2bez> I need to do some testing on my pi3 now


[02:44] <dragonbite> I have a problem when trying to run the Ubuntu-SDK...
[02:45] <dragonbite> It comes up with updates available for my kits and the option to select "ubuntu-sdk-15.04-amd64"
[02:48] <dragonbite> I check it, let it run and get the following error message
[02:48] <dragonbite> "You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies:
[02:48] <dragonbite> qtdeclarative5-ubuntu-ui-toolkit-plugin : Depends: libubuntugestures5 (= 1.3.1795+15.04.20160106-0ubuntu1)
[02:48] <dragonbite> E: Unmet dependencies. Try using -f.
[02:48] <dragonbite> Command returned 100: schroot -u root -c source:click-ubuntu-sdk-15.04-amd64 -- apt-get dist-upgrade --yes
[02:48] <dragonbite> ---Click exited with errors, please check the output---"
[02:48] <dragonbite> qtdeclarative5-ubuntu-ui-toolkit-plugin is already installed
[02:49] <dragonbite> libubuntugestures5 it cannot find  to install
[03:18] <Son_Goku> does Unity 8 have a hard dependency on Mir, or is that dependency abstracted out through its usage of Qt and QML?
[04:18] <RAOF> Son_Goku: I think it's still capable of being run without Mir, yes.
[04:19] <RAOF> There was certainly a time where you could run a Unity8 session under X11; I don't think we're making any particular effort to preserve that, though, so it might not work anymore :)
[05:46] <hallyn> hm, so both 'shut down' and 'restart' from the menu lead to the same popup with the two 'restart' and 'shut down' options
[06:31] <pitti> Good morning
[06:47] <cpaelzer> good morning
[06:53] <slangasek> morning ;)
[06:54] <ginggs> Pharaoh_Atem, nacc: I sync'd pcre3 from Debian. Is someone going to look at php?
[07:00] <slangasek> ginggs: once pcre3 has been built in xenial-proposed, we can try to build https://launchpad.net/ubuntu/+source/twig/1.23.1-1ubuntu3/+build/9275887 again and see if it's fixed
[07:04] <slangasek> pitti: problems creating nova instances for ppc64el autopkgtests this morning? http://autopkgtest.ubuntu.com/running.shtml
[07:04] <pitti> slangasek: yes, see #is
[07:04] <slangasek> ok :)
[07:04] <pitti> slangasek: buildds are down too
[07:04] <pitti> slangasek: I just filed bug #89226
[07:04] <pitti> slangasek: err, RT #89226
[07:04] <slangasek> pitti: got it, thanks
[07:05] <pitti> I suppose they saw the 30.000 test rebuild requests, cried, and died
[07:06] <slangasek> I don't imagine I should wait up for the test results, then
[07:06] <pitti> I can temporarily disable ppc64el in britney
[07:06] <pitti> that doesn't help with getting builds on ppc64el, but might unblock at least some stuff
[07:13] <pitti> slangasek: force-skiptest php-zend-code> it's more elegant to re-run the test against all of -proposed
[07:13] <pitti> slangasek: run-autopkgtest --all-proposed [...]; or specify both packages as --trigger, but --all-proposed is simpler
[07:13] <pitti> as you can just copy&paste it from ALL_PROPOSED=1 retry-autopkgtest-regressions
[07:14] <slangasek> pitti: oh, you can pass --trigger multiple times; that's the thing I forgot.  Would love to have an example of that on the wiki page :)
[07:15] <pitti> slangasek: I did document --all-proposed
[07:15] <slangasek> yeah, but I don't like --all-proposed ;)
[07:18] <pitti> slangasek: https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure?action=diff&rev2=57&rev1=56
[07:19] <pitti> ppc64el autopkgtests temporarily disabled
[07:23] <slangasek> nacc: looks like phpunit, php-defaults, php7.0 are now wedged in -proposed because of the missing php7.0-zip; what's the plan for getting that restored?
[08:01] <loop> guys why you do not  write anything?
[08:02] <loop> anyone is active?
[08:03] <loop> Guys wake up. I want to share with you my advice and opinion about ubuntu as regular user.
[08:07] <dholbach> good morning
[08:07] <loop> yo
[08:07] <loop> I suggest: Make the new app store (that will operate on the principle of Steam and will be the most important program in the system). With him will could download any application (eg. steam, vokoscreen, audacity ...). There will be no need to add the repo when u want install sth. Only each application exists on Linux will be there to download.  Close to ~ 80% of the problems of people with askubuntu is installation problems with the program - which will solve the new ubuappstore. Remember that the majority of users are simple people in matters of IT - as I do. All is more difficult cuz of model-behavior of the system.
[08:08] <loop> Get rid of the .deb file type and substitute is an  .uni typ file that will be associated with the shop and it will be installed as 2 clicks in windows. You have a problem with the quality and popularity of software, bugs, and causing it lack of the store (model: Play Store, Steam) and install with performance based management system through apt - which are outdated and fit into the shell text.
[08:08] <loop> To graphical shell fits only app store and the type of executable file .uni. Listen to me and soon show the streamergamers, YouTubers who are you doing free advertising and will promote your free system as for Valve tournaments esports promoted the CS GO which in 2012 was at the bottom. Now it is no. 1 eSports on world. For example look at YT gamers scene in EU at the moment.
[08:09] <infinity> loop: This not a channel for complaints and walls of suggestion text.
[08:10] <loop> I leave your system. By the described disadvantages. You want to start gaining users, in first care in order for the players and the people who use specialized software, creators programmed into .uni. I know that the closed software does slowly in digital society  slaves of men, but I will sit on the windows  if you really are idiots and do not see that what i wrote.
[08:10] <loop> The small things make the difference, and those I have described are enough to your system was popular, like Windows is now popular.
[08:10] <loop> I leave your chat too bye.
[08:10] <loop> ban me :)
[08:11] <dholbach> nobody said they'd like to ban you... this is just not a good way of making yourself heard
[08:11] <infinity> loop: As a general rule, wandering into a room with a bunch of people and suggesting that they're all idiots if they don't immediately implement your idea is likely not the best way to be heard.
[08:12] <infinity> loop: For the record, we're toying with new appstore models (see: snappy), and indeed, some third party software will be delivered that way in the near future.
[08:13] <infinity> loop: You'll be happier to know that we read your comment, were appropriate shamed by your tone, invented a time machine, and started working on it a year ago.
[08:13] <infinity> s/appropriate/appropriately/
[08:14] <loop> I ll read about yout work.
[08:14] <loop> Have politely :) Have fun.
[08:14] <loop> bb
[08:17] <dholbach> @pilot in
[10:25] <mapreri> dholbach: fancy syncing libeatmydata ? :)
[10:25] <mapreri> i did an upload yesterday in debian
[10:25] <dholbach> mapreri, taking a look
[10:28] <darkxst> pitti, vmware no longer gets "splash" on the kernel command line, was that intended?
[10:28] <pitti> darkxst: I don't know, but I doubt that's vmware specifc
[10:29] <pitti> darkxst: it should be specific to the kind of image (cloud/server/desktop)
[10:29] <dholbach> mapreri, done
[10:29] <darkxst> pitti, it happend on installed xenial ubuntu-gnome's
[10:29] <mapreri> dholbach: ♥
[10:29] <darkxst> but not on my laptop
[10:29] <dholbach> :)
[10:54] <pitti> xnox: hmm, is https://launchpadlibrarian.net/243987535/buildlog_ubuntu-xenial-amd64.upstart_1.13.2-0ubuntu20_BUILDING.txt.gz due to a new coreutils or something such?
[10:54] <pitti> not ok 38 - with single-line command that writes 1 line to stderr
[10:54] <pitti> wrong content in file 0x7f0d28045740 (output), expected '0 bytes (0 B) copied,*
[10:54] <pitti> ' got '0 bytes copied, 2.9651e-05 s, 0.0 kB/s
[11:01] <ogra_> at least it is fast
[11:18] <darkxst> pitti, it doesnt seem to affect the live images
[11:27] <Odd_Bloke> xnox: Does the latest kernel (with its modified initrd handling) mean that we can drop your s390x-specific hack from livecd-rootfs?
[11:46] <davmor2> cyphermox, seb128: upgrade from 14.04 → 16.04 really hates us, it broke again bug #1551198
[11:46] <LocutusOfBorg> what did happen to ppc64el buildds?
[11:59] <cpaelzer> LocutusOfBorg: for ppc64el see this channel around 5h before now between pitti and slangasek as well as #is
[12:13] <LocutusOfBorg> thansk cpaelzer
[12:17] <LocutusOfBorg> please seb128 can you retry https://launchpad.net/ubuntu/+source/inkscape/0.91-7ubuntu2/+build/9276902 ?
[12:17] <LocutusOfBorg> :)
[12:22] <seb128> LocutusOfBorg, why is there no build log?
[12:26] <seb128> LocutusOfBorg, retried
[12:34] <LocutusOfBorg> seb128, ppc64el disabled
[12:34] <LocutusOfBorg> so it will be retried when they will become online again, and thanks BTW
[12:34] <seb128> LocutusOfBorg, yw
[12:35] <seb128> ppc64el disabled? do we know what's the issue?
[12:35] <LocutusOfBorg> scroll above ^^
[12:35] <LocutusOfBorg> :)
[12:36] <seb128> I looked to the logs and I didn't see much useful
[12:36] <seb128> oh, well, let's wait then
[12:50] <rbasak> If using dh_install with --fail-missing to better manage a complex package (mysql-5.7), how should we handle files that we deliberately don't want installed? dh_install -X, or some other way?
[12:51] <rbasak> Also, Skuggen reports that --list-missing is reporting manpages installed correctly by dh_installman, and so needs to explicitly exclude those too.. Is that expected?
[12:58] <dholbach> @pilot out
[12:58] <xnox> pitti, looks like it. open a bug and assign to me?!
[12:58] <xnox> Odd_Bloke, possibly, needs testing. I'll spin a rebuild in my ppa and see what happens.
[13:06] <jibel> stgraber, Hi, could you have a look at bug 1551150? lxc is a primary suspect.
[13:55] <cjwatson> pitti: is ppc64el happier for you now?
[13:56] <cjwatson> ah yes, the RT was updated too
[14:01] <pitti> cjwatson: it is indeed, thanks
[14:02] <pitti> l
[14:07] <cyphermox> davmor2: it says module-init-tools in unauthenticated, does it come from some other testing?
[14:12] <davmor2> cyphermox: nope default install of 14.04.4 + updates and then running update-manager -d in atl+F2
[14:41] <tjaalton> anyone know what changed the default monospace font?
[14:41] <tjaalton> in xenial
[14:41] <tjaalton> it's much wider than the old
[14:43] <rbasak> tjaalton: https://lists.ubuntu.com/archives/ubuntu-devel/2016-February/039224.html maybe?
[14:44] <tjaalton> rbasak: exactly
[14:53] <tjaalton> before I had a split terminator instance with four columns, 125+94+94+94 wide (roughly). Now they are 125+94+64+64..
[14:53] <tjaalton> unusable :/
[14:53] <tjaalton> smaller font size is not an option
[14:57] <pitti> xnox: I pushed http://bazaar.launchpad.net/~ubuntu-core-dev/upstart/ubuntu/revision/1628 now, this seems to work fine
[14:58] <xnox> pitti, cool!
[14:58] <pitti> xnox: while I'm at it, do you have an idea about that flaky test:
[14:58] <pitti> not ok 26 - with single-line script that is killed
[14:58] <pitti>  wrong value for WIFSIGNALED (status), expected TRUE got FALSE
[14:58] <pitti>  at tests/test_job_process.c:1760 (test_start).
[14:58] <pitti> 1..153
[14:58] <pitti> FAIL: test_job_process
[14:58] <pitti> xnox: this seems to fail in most autopkgtset runs
[14:59] <pitti> and currently we force-badtest the entire thing, which is a shame
[14:59] <pitti> as we don't hear about other regressions that way
[14:59] <xnox> pitti, yes -> it is possible that a short lived process exits faster than we manage to kill it, and catch the signal.
[14:59] <pitti> xnox: would it be okay to disable that particular test for now, so that the others become useful again?
[14:59] <xnox> i wonder if we should "loop" / re-attempt the test a few times before giving up.
[14:59] <xnox> ok.
[15:03] <pitti> xnox: I think the rest of the test is okay, so http://paste.ubuntu.com/15244176/
[15:04] <xnox> doko, please RM unity-scope-snappy as per bug #1542451 which also fixes bug #1542376 and bug #1534346
[15:04] <xnox> pitti, yeap, looks good.
[15:04] <pitti> xnox: thanks
[16:05] <nacc> ginggs: hey, pcre3 question for you, when you have a moment
[16:16] <ginggs> nacc: just ask
[16:19] <nacc> ginggs: ok, we've deduced that the twig testsuite is failing with php7 due to a pcre bug. Thanks to Pharaoh_Atem's debugging with the SCL maintainer, we know that FC23 doesn't have this problem, but both SCL and Ubuntu do. I'm trying to understand how Debian/Ubuntu pull in the fixes normally? There are a lot of upstream bugfixes since 8.38 that Debian & Ubuntu seem to be missing. I just noticed you did
[16:19] <nacc> the last merge, and wasn't sure if you had more context.
[16:25] <ginggs> nacc: i would say normally fixes come in upstream releases, which get packaged in debian and then make their way into ubuntu. sometimes, a bug may be filed in debian (e.g. debian #815921) and it may be important enough for the maintainer to upload a new debian release.
[16:32] <ginggs> nacc: do you know which bug it is? http://vcs.pcre.org/pcre/code/trunk/ChangeLog?view=markup
[16:32] <nacc> ginggs: ok, thanks -- I figured that was the case, but wasn't sure, I might just have hit a window where the debian bug wasn't fixed yet.
[16:33] <nacc> ginggs: sadly not yet :/ i'm trying with all of fc23's patches applied just to get a bseline, but i know it's just not the abvoe-mentioned issue
[16:34] <nacc> ginggs: it's something to do with the jit (as if we disable pcre.jit in PHP, it goes away)
[16:45] <nacc> ginggs: the tricky part is i have to rebuild php7 to test :)
[17:34] <seb128> bdmurray, you said that https://code.launchpad.net/~seb128/software-properties/newtab-enable-proposed/+merge/286626 looked fine to you, could you comment on it saying so?
[17:37] <bdmurray> seb128: Yep
[17:37] <seb128> bdmurray, thanks
[17:41] <jderose> cyphermox: so i'm taking a stab at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1508865 today... sometime during the 15.10 cycle this was introduced. something is different about how the first-run DM is setup compared to the normal installation DM... any ideas?
[17:41] <jderose> cyphermox: i've been looking the the changes in bzr, but nothing has stood out to me yet
[17:46] <xnox> jderose, the networking page steps got re-arranged, maybe that affected things?! (e.g. the step that oem-config starts from should be like -1 or some such?!)
[17:46] <xnox> jderose, however i thought networking is generally not enabled at all during user config.
[17:47] <jderose> xnox: it used to be, because that's how ubiquity could guess your timezone using your IP
[17:47] <xnox> ok.
[17:47] <jderose> xnox: happen to know where in the ubiquity code said networking setup happens?
[17:48] <xnox> it's a separate page/plugin.
[17:48] <xnox> a stand-alone file i believe.
[17:49] <cyphermox> jderose: what do you mean by "DM" ?
[17:50] <ginggs> cjwatson: where can I find the specs of the powerpc buildds sagari, denneed* and fisher* please?
[17:50] <jderose> cyphermox: my terminology might be wrong... i'm looking at, for example, bin/ubiquity-dm
[17:50] <cyphermox> this isn't a new change; oem-config needs to get rid of any oem-specific networking config; NM would re-write new config files as necessary
[17:51] <cyphermox> but I see what might be wrong
[17:52] <cyphermox> for wired you probably need to go an click on nm-applet and pick the wired device for it to connect, and it's not doing so automatically
[17:52] <jderose> cyphermox: i do recall a bug about prepare for shipping to end user should delete stuffs in /etc/NetworkManager/system-connections/... could that have resulted in networking being completely disabled during the user first-run?
[17:53] <cjwatson> ginggs: What in particular are you trying to figure out?
[17:53] <cyphermox> not disabled, but NM gets confused because "Ethernet 1" gets deleted and it won't just automatically recreate it, because reasons
[17:53] <jderose> cyphermox: in my experience, th nm applet is only shown when on wifi... otherwise it silently connects to ethernet without displaying the nm applet
[17:54] <ginggs> cjwatson: still trying to figure out the openmpi failures with powerpc LP: #1550863 / Debian #814183
[17:54] <jderose> ubiquity also no longer prompts to connect to wifi during the user first-run
[17:54] <cjwatson> ginggs: they're all POWER7; sagari is bare metal, denneed*/fisher* are VMs
[17:54] <cyphermox> jderose: no, the applet should always show
[17:54] <cyphermox> jderose: wifi should not try to connect automatically to anything
[17:55] <cjwatson> ginggs: the usual relevant difference is that sagari has something like 15GB of RAM while the VMs have somewhat less (don't know exactly how much)
[17:55] <cjwatson> ginggs: for more details ask infinity
[17:55] <jderose> cyphermox: it didn't do it automatically... when there was no ethernet, it would prompt you to connect to wifi. it still does this during the initial install, but doesn't anymore during the first-run user config
[17:56] <cyphermox> I'm not sure it ever did in the oem context
[17:56] <ginggs> cjwatson: thanks (again)
[17:56] <cyphermox> but that should be easy enough to fix
[17:57] <cjwatson> ginggs: (something more like denneed*/fisher* should be considered future direction, though we can adjust available RAM a bit just as we recently did on ppc64el)
[17:57] <cyphermox> jderose: I'll look as soon as I'm done eating lunch :)
[17:58] <jderose> cyphermox: i'm 100% certain it used to do this during the oem first-run user setup. this is a bug that flexiondotorg found just prior to the 15.10 release during his ISO testing
[17:59] <ginggs> cjwatson: I was just looking for a pattern, in Debian it appeared that things FTBFS on POWER8, but built on PPC970FX
[17:59] <jderose> cyphermox: no rush, enjoy your lunch! :)
[18:35] <jderose> cyphermox: just confirmed to make sure i'm not talking crazy... when no ethernet is plugged it but you have a wifi card, 14.04.4 prompts you to join a wifi network during oem first-run user config on the 2nd page; 15.10 and xenial go directly to the timezone selection page, without networking enabled
[18:36] <nacc> ginggs: another question, if you happen to know, does libpcre3 allow for runtime disabling of JIT?
[18:42] <cyphermox> jderose: sounds like maybe the network screen crashes when running in oem
[18:43] <cyphermox> jderose: that would show up in /var/log/syslog, or /var/log/installer/debug (or /var/log/ubiquity/debug, I think)
[18:43] <jderose> cyphermox: for wired, 14.04.4 automatically connects to the network, but doesn't show the nm applet; 15.10 and xenial never show the nm applet, neither for wireless nor weired
[18:44] <jderose> okay, i'll check the logs...
[18:44] <cyphermox> well, much of this is wrong then, nm-applet should always show
[18:45] <cyphermox> jderose: please file bugs for each different thing, and I'll get to them as soon as I can
[19:28] <nacc_> Pharaoh_Atem: hrm, so i built a version of pcre3 that compile-time had jit disabled. still get a segfault unless i tell php pcre.jit=0 (which all it does is not call pcre_study, afaict).
[19:33] <ginggs> nacc_: don't know, sorry
[19:34] <vooze> Hello dear devs ;) I have reported this bug, but I can't figure what what package is responsible to setting the wallpaper. https://bugs.launchpad.net/ubuntu/+bug/1550815 - The issue is it changes the colors on the wallpaper from the original image
[19:34] <nacc_> ginggs: np, i'm figuring it out as i go ... it is a pcre bug, but i think one that may not yet have been found upstream (as i can reproduce it with the latest svn)
[19:34] <nacc_> Pharaoh_Atem: --^ which is confusing to me that fc23 works at all
[19:35] <nacc_> Pharaoh_Atem: fc23 doesn't happen to use the php7 src pcrelib, does it?
[19:43] <nacc_> Pharaoh_Atem: but in more positive news, i've reduced the twig segfault to a one line change in the testcase, so i know *why* it's failing (as in what particular test in the testcase)
[19:58] <cjwatson> nacc_: sorry if you've talked about this already, but I keep seeing you talking about pcre3, is there a reason you aren't using the (newer!) pcre2?
[19:58] <cjwatson> if upstream only works with pcre3 then that's a valid reason of course
[19:58] <Pharaoh_Atem> nacc_: that's awesome
[19:59] <Pharaoh_Atem> and horrifying
[19:59] <Pharaoh_Atem> maybe Fedora is optimizing out the issue with its more aggressive gcc flags?
[19:59] <Pharaoh_Atem> cjwatson: someone needs to kill that soversion mutation in Debian for pcre
[19:59] <Pharaoh_Atem> it *should* be pcre1
[20:02] <ginggs> Pharaoh_Atem: hopefully pcre3 will disappear soon, and then we'll only have pcre2
[20:03] <dobey> hmm, why is "do-release-upgrade -d" complaining that it can't authenticate module-init-tools from us.archive.u.c on my laptop?
[20:04] <nacc_> cjwatson: php7 only supports building against pcre3 (afaict) ... i guess i could try and move the build-dep, but i think that's how upstream is too
[20:05] <dobey> vooze: what ubuntu is that?
[20:05] <vooze> dobey: on the images: ubuntu 14.04 (unity) but I have found the "bug?" in Linux Mint, Ubuntu Gnome 15.10, Ubuntu 16.04 and Xubuntu as well.
[20:06] <nacc_> Pharaoh_Atem: it could be ... it does sound like php & pcre have had issues int he past, i'm filing a pcre bug now to see if they can help debug
[20:06] <dobey> vooze: what resolution is your screen?
[20:06] <vooze> dobey: 1920x1080 on laptop and 2560x1440 on desktop (bug present on both)
[20:07] <vooze> Also Laptop uses Intel GPU and Desktop Nvidia
[20:10] <dobey> vooze: nautilus is what renders the background; i moved the bug there; but when i open the image in eog on my computer, it is not as orange as you claim it should be
[20:10] <cjwatson> Pharaoh_Atem: about a decade too late
[20:11] <cjwatson> Pharaoh_Atem: no point going through a painful transition when we want to end up on pcre2 anyway
[20:12] <vooze> dobey: maybe a different color profile (or just different tuned monitor?) Would it be possible for you to set it as wallpaper while having it open in eog to see if there is a difference?
[20:13] <dobey> vooze: this is intel with a dell 4k monitor that is 100% rgb
[20:13] <vooze> It is different from image to image "how much" it changes I think. That is just the "best" image I could find to show the difference.
[20:16] <vooze> dobey: okay. Could you possible try to apply it as wallpaper? Also thanks for taking the time to help me.
[20:17] <dobey> vooze: for me it seems slightly more orange there when applied as a wallpaper; perhaps due to a different scaling method used for the background, versus for eog
[20:18] <dobey> granted, i also have redshift running
[20:19] <vooze> dobey: Could be. But at least now the bug is open and maybe some nautilus-devs? (But thats gnome devs I guess? Can take a look at it. Otherwise I will just have to wait for Unity 8 :)
[20:20] <vooze> Maybe that will handle it differently with mir.
[20:20] <dobey> well, if you want gnome devs to look at it, probably also needs to be forwarded upstream
[20:20] <vooze> dobey: Well, I checked on Ubuntu Gnome and the issue is there as well, so could not hurt I guess.
[20:25] <vooze> dobey: is this something I can do from the bugtracker on launchpad or should I post elsewhere and link it on launchpad?
[20:26] <dobey> i don't recall the exact procedure for pushing bugs upstream, sorry
[20:26] <dobey> ask in #ubuntu-bugs perhaps
[20:26] <vooze> dobey: Okay, I will try to figure it out. Thank you again for your time.
[20:49] <stefanct> hm, is there a lp: containing the xenial package that i can use for a nest-part packaging directive in a recipe?
[20:50] <stefanct> i have seen lp:debian/sid which is almost as good, but referring to the "real" thing seems better
[20:50] <cjwatson> not in general, the bzr importer was creakingly bad and we haven't turned it on for xenial
[20:50] <dobey> stefanct: there are no source imports of xenial packages, no
[20:50] <dobey> ah i see cjwatson is still here :)
[20:51] <cjwatson> I'm three hours west of usual this week
[20:52] <dobey> ah
[20:52] <dobey> at the ols sprint?
[20:52] <cjwatson> yep
[20:53] <stefanct> ok thanks
[20:53] <dobey> cool. bet the weather is nice there :)
[20:58] <sarnold> coreycb: congratulations :)
[20:58] <coreycb> sarnold, thanks!
[21:35] <slangasek> nacc_: hi, did you see my follow-up on bug #1549942 yesterday?
[21:35] <slangasek> nacc_: I believe that's the last blocker for getting php7.0/phpunit/php-defaults migrated now
[22:02] <stefanct> is there an easy way to exclude a directory (e.g. debian/patches) when using nest-part?
[22:48] <ScottK> caribou: If you care about armv5 at all (not sure if Ubuntu does, but its derivatives might) you should definitely merge clamav again.
[22:49] <teward> ScottK: I don't think there's any Ubuntu supporting anything less than armv7 right now?  Unless I misread the architectures documentation
[22:49] <ScottK> I think that's right, but I don't know about derivatives.
[22:50] <ScottK> That or sparc, which is definitely at most a derivative's concern.
[22:52] <teward> ScottK: i hate to be argumentative, but with Xenial sparc's not even on our arch list - at that point would it not be up to the derivatives alone to provide support/fixes for those patches?  (And I am excluding officially recognized flavors of *buntu from "derivatives")
[22:52] <teward> s/our arch/the arch/
[22:53] <teward> (basically, how much do we need to provide support for unsupported archs for derivatives)
[22:53] <teward> my two cents though, i have no say ultimately :)
[22:53] <ScottK> Since Debian's already fixed the bug and all it takes is a merge, meh.
[22:53]  * teward shrugs
[23:10] <Pharaoh_Atem> cjwatson: then someone should probably port php to use pcre2 :/


[08:27] <tsdgeos> MacSlow: ping
[08:30] <tsdgeos> MacSlow: seen http://paste.ubuntu.com/7183774/ ?
[08:32] <Mirv> Saviq: FYI I gave a silo for greeter split back, now that we're in _much_ better situation silo wise (lots of landings on Friday). tried a build, merge conflict.
[08:44] <Saviq> Mirv, ok thanks
[08:51] <Saviq> mzanetti, I'll be trying right edge again, we're sorted with everything there, are we?
[08:56] <mzanetti> Saviq: yeah, I'd say so
[08:58] <mzanetti> dednick: hey
[08:59] <dednick> mzanetti: yo
[08:59] <mzanetti> dednick: for some reason, the "Unlock SIM" doesn't appear any more on my phone
[08:59] <mzanetti> did there anything change lately?
[08:59] <dednick> mzanetti: the menu item?
[08:59] <mzanetti> yeah
[09:00] <dednick> mzanetti: i havent changed anything lately.
[09:00] <dednick> mzanetti: i'll check it out
[09:00] <mzanetti> hmm... ok... then I'll check with ofono.
[09:00] <mzanetti> just thought that this might be gone in favor of popping it up automatically
[09:02] <dednick> mzanetti: nothing changed in indicator-network in the last few months, so not sure. should still be there.
[09:02] <dednick> mzanetti: you sure you still have a pin on your sim? :)
[09:03] <dednick> mzanetti: just thought i'd ask the question before diving into it
[09:03] <mzanetti> dednick: yeah.. I am
[09:03] <mzanetti> dednick: but let me make sure its not ofono first.
[09:07] <tsdgeos> mzanetti: ping
[09:08] <mzanetti> tsdgeos: o/
[09:08] <MacSlow> tsdgeos, that's new to me
[09:08] <tsdgeos> mzanetti: can you review https://code.launchpad.net/~aacid/unity8/lvwphnoprocessevents/+merge/213306 ? it's for the ocassional random crash we get in https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1297240
[09:08] <mzanetti> tsdgeos: ack
[09:08] <tsdgeos> MacSlow: happens in https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1542/testReport/%28root%29/qmltestrunner/VisualQueueTest__test_VisualSnapDecisionsQueue/
[09:09] <tsdgeos> with my branch changing nothing related to that test
[09:09] <tsdgeos> MacSlow: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/1542/consoleFull for the log
[09:09] <MacSlow> tsdgeos, I'll look into that today
[09:09] <MacSlow> tsdgeos, thx
[09:09] <tsdgeos> http://paste.ubuntu.com/7183924/
[09:14] <mzanetti> dednick: yeah... ofono seems to work still: http://paste.ubuntu.com/7183940
[09:15] <mzanetti> dednick: but no Unlock SIM entry since yesterday morning. I've rebooted a 100 times to get back my phone. no avail.
[09:15] <mzanetti> dednick: weird thing is, I didn't do an upgrade in the last days even
[09:16] <mzanetti> but I'm sure it was working last week. I think I used it last on Thursday
[09:16] <mzanetti> dednick: let me know if I can help you to debug it. the phone is still in that state
[09:20] <dednick> mzanetti: ok, i'll take a look. dont think i have a pin on my sim anymore though :(
[09:20] <mzanetti> dednick: you should be able to enable it with dbus calls
[09:21] <dednick> mzanetti: oh yeah...
[09:24] <dednick> ... would probably help to have a sim card in my phone as well..
[09:24] <dednick> sigh
[09:25] <mhr3> Saviq, can i get ack on https://code.launchpad.net/~mhr3/unity-scopes-shell/expose-attributes/+merge/212213 ?
[09:26] <dednick> mzanetti: give me a few hours; I went into the office this morning not realising there wasn't any power. Just about to head home. So i'll test it out there where i have a spare sim
[09:27] <Saviq> mhr3, you might, let me see quickly
[09:27] <mzanetti> dednick: yeah, sure. no rush. I'll keep my phone broken :)
[09:27] <dednick> mzanetti: thanks :)
[09:28] <Saviq> mhr3, you got «"background": null», other's don't have space after colon
[09:31] <Saviq> mhr3, you didn't limit it to 3 attributes did you?
[09:32] <mhr3> Saviq, right
[09:32] <mhr3> do you want me to?
[09:41] <mhr3> Saviq, pushed
[09:42] <Saviq> mhr3, k
[09:46]  * mzanetti likes how searching for "a" brings up Xbmcremote in the apps scope :D
[09:47] <Saviq> mhr3, test the limiting?
[09:55] <tsdgeos> Cimi: you doing https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941 ?
[09:55] <mhr3> Saviq, you're demanding :P
[09:55] <mhr3> Saviq, pushed
[10:07] <Cimi> tsdgeos, my comments are still valid no
[10:07] <Cimi> ?
[10:07] <tsdgeos> Cimi: which ones?
[10:07] <tsdgeos> he rewrote the thing, no?
[10:08] <Saviq> mzanetti, when I have a sidestage open and go to the dash via ubuntu button or long left swipe, I get a black side stage, that one would be good to fix
[10:08] <mzanetti> Saviq: strange. quite sure that was working. ok. will look into it
[10:34] <Cimi> tsdgeos, sorry was upgrading
[10:35] <Cimi> tsdgeos, I'd like to see tested fixed values
[10:35] <Cimi> tsdgeos, like, pinching 100 px results in 1.1 (example) scaling
[10:36] <tsdgeos> Cimi: can you comment in there again so paulliu knows it still needs fixing?
[10:36] <Cimi> tsdgeos, also, I'm not convinced of this
[10:36] <Cimi> tsdgeos, for of lne 334 of the diff
[10:36] <Cimi> *line
[10:37] <Cimi> tsdgeos, I think this should be reviewed by daniel
[10:37] <tsdgeos> Cimi: ok, ask him then :)
[10:37] <Cimi> tsdgeos, I asked paul to talk with daniel
[10:37] <Cimi> tsdgeos, I'll ask daniel directly
[10:37] <tsdgeos> Cimi: :)
[10:38] <Saviq> mzanetti, which ap failure do you mean on the lvwph thing?
[10:38] <Saviq> latest result only mentions a qmluitest failure
[10:38] <MacSlow> tsdgeos, I have a potential fix for the issue you reported... but it doesn't fail on my machine so I've to first test-run it against jenkins
[10:38] <mzanetti> Saviq: upstart integration tests
[10:39] <tsdgeos> MacSlow: good
[10:39] <MacSlow> tsdgeos, to verify that's fixing the jenkins issue
[10:39] <mzanetti> Saviq: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/3774/?
[10:39] <mzanetti> Saviq: ah right. I didn't refresh the site with the latest posts from jenkins. seems gone indeed
[10:39] <Saviq> mzanetti, right, that looks flaky, 2 subsequent runs don't show these fails
[10:40] <Saviq> mzanetti, push-ups?
[10:40] <MacSlow> tsdgeos, it's all just guess-work... another odd thing is that all of a sudden I get these tons of QWARNings which I never got before
[10:40] <mzanetti> :D
[10:40] <mzanetti> Saviq: on it...
[10:41] <mzanetti> done
[10:43] <Saviq> mzanetti, ap results look good, though, doing test plan now, only issue would be the black side stage then
[10:43] <mzanetti> Saviq: yep. I'm confident for the test plan. Mirco and Gerry walked through it a couple of times already
[10:44] <mzanetti> just flashing the tablet to investigate in the black side stage
[10:44] <MacSlow> is the s-jenkins site responsive for anybody?
[10:44]  * mzanetti tries
[10:44] <MacSlow> it works... but... doh... it's slow
[10:45] <mzanetti> MacSlow: yeah... the initial page with all the jobs is. the rest works fine
[10:45] <mzanetti> just try to avoid it
[10:45] <MacSlow> mzanetti, yeah
[10:45] <mzanetti> by using the on-hover menus
[10:46] <Saviq> mzanetti, hmm... the main stage gets confused sometimes, too :/
[10:47]  * Saviq tries to find steps
[10:48] <Saviq> aand crash
[10:48] <Saviq> and no .crash file... hum
[10:49] <Saviq> wth
[10:56] <Saviq> mzanetti, hmm is it expected that you don't get a right-edge hint with only one app open?
[10:57] <mzanetti> Saviq: yeah. have been talking with design about this. There are still a bit unsure what to do in this case.
[10:57] <mzanetti> Saviq: discussions are between: hint, open spread nevertheless or open spread with this app and the dash
[10:58] <mzanetti> Saviq: we agreed to wait on a final decision
[10:58] <Saviq> +1
[11:05] <mzanetti> Saviq: pushed a fix for the black side stage
[11:05] <Saviq> mzanetti, ok cool, kicking a rebuild
[11:05] <mzanetti> +1
[11:09] <Saviq> mzanetti, it seems more fragile when apps fail to start than what we have now... like unity8 exits (but does not crash ¿?) when it's trying to get a screenshot of a non-existing app, any idea about that?
[11:10] <mzanetti> humm... that's news too. I had tons of not starting apps.
[11:10]  * mzanetti tries to reproduce
[11:11] <mzanetti> Saviq: do you know an app that's reliably failing to start right now?
[11:13] <mzanetti> Saviq: ok. got one. its not crashing here.
[11:13] <mzanetti> it shows the empty screenshot but still running
[11:14] <Saviq> mzanetti, try left-swiping now
[11:14] <Saviq> mzanetti, empty as in black?
[11:15] <mzanetti> no, transparent
[11:15] <mzanetti> Saviq: well, when the app is focused its black, yes.
[11:15] <Saviq> mzanetti, ok yeah
[11:15]  * mzanetti keeps on digging
[11:15] <Saviq> mzanetti, long-left-swipe caused it to exit for me in that situation
[11:15] <Saviq> mzanetti, on both manta and mako
[11:17] <mzanetti> Saviq: should we be worried that lxc-android-config fails to dist-upgrade?
[11:19] <mzanetti> Saviq: nope. just dist-upgraded to the ppa on a freshly fleshed phone. still not "exiting" on empty apps. no matter which gesture
[11:19] <mzanetti> Saviq: altough there might be a difference in the "app not starting" thing
[11:19] <Saviq> mzanetti, lxc is fine
[11:20] <mzanetti> e.g. crashing at startup vs not launching anything all
[11:20] <Saviq> mzanetti, it's because the file it wants to update is bind-mounted writable
[11:20] <Saviq> mzanetti, ok, I'll let you know if I can find some steps
[11:20] <mzanetti> ok. espected something like that. just wanted to make sure we don't mess up
[11:20] <mzanetti> expected, even
[11:20] <mzanetti> lxc, that is ^
[11:27] <Cimi> dednick, hey dude!
[11:31] <dednick> Cimi: hey
[11:32] <mhr3> dednick, crap, we need you here
[11:32] <mhr3> dednick, can you come back?
[11:32] <dednick> mhr3: heh. no chance :)
[11:32] <mhr3> dednick, j/k :)
[11:33] <Cimi> dednick, I think we should write that component for dealing with bindings!
[11:33] <Cimi> dednick, I really need it for the wizard
[11:34] <dednick> Cimi: why?
[11:35] <dednick> Cimi: but yeah, should be dne
[11:35] <Cimi> dednick, because they have same issue all around in system settings
[11:36] <dednick> Cimi: i see. ok, well I'm busy with something at the moment, but I'll try take a look at it later today
[11:37] <mzanetti> tsdgeos: do you still have your first proposed patch for the move/layoutChanged/modelReset issue around?
[11:38] <tsdgeos> it should be in gerrit
[11:38] <tsdgeos> let me see
[11:38] <mzanetti> seing that sort() always calls layoutChanged (which does sound correct to me) I'm really not convinced the _q_layoutChanged() should call modelReset()
[11:38] <mhr3> Saviq, also ack on https://code.launchpad.net/~mhr3/unity8/fix-1297246/+merge/212593 would be appreciated
[11:39] <mzanetti> but rather the move operation should do something that makes it update properly
[11:39] <mzanetti> which I assume was your first try too
[11:39] <tsdgeos> ye
[11:39] <tsdgeos> see https://codereview.qt-project.org/#patch,all_unified,67214,6
[11:39] <tsdgeos> specially steveire's comment
[11:39] <tsdgeos> "Not exactly. The view on *any* model (not specific to QSFPM) is supposed to re-query everything from the model when the layout changes. The number of items in the model, as well as their position might have changed."
[11:40] <mzanetti> tsdgeos: hmm... I always thought layoutChanged would update everything except number of items
[11:41] <mzanetti> which is what modelReset is for
[11:41] <tsdgeos> don't ask me :D
[11:41] <tsdgeos> as i said
[11:41] <tsdgeos> i am not sure i really understand what's the difference between layoutChanged and resetModel
[11:43] <mzanetti> well, after this change there isn't really a difference any more
[11:43] <mzanetti> the one that was committed
[11:46] <tsdgeos> i mean on the model level
[11:46] <tsdgeos> not on the view level
[11:53] <Saviq> mhr3, add http://pastebin.ubuntu.com/7184458/ to tst_GenericScopeView.qml please?
[11:57] <mhr3> Saviq, thx, pushed
[11:57] <Saviq> mhr3, k
[12:15] <Cimi> seb128, any update on this? https://code.launchpad.net/~unity-team/ubuntu-system-settings/wizard.wifi/+merge/212675
[12:17] <seb128> Cimi, no, I'm busy with other things atm, I don't really have time for the wizard, maybe try to catch mterry?
[12:20] <MacSlow> tsdgeos, the fix seems to work... https://code.launchpad.net/~macslow/unity8/fix-jenkins-issue-with-visual-snap-decisions-queue-qml-test/+merge/213432
[12:31] <paulliu> Cimi: you talked to Daniel already? I've talked to him last week. Seems ok.
[12:46] <Cimi> paulliu, ok
[12:46] <Cimi> paulliu, so only thing I'd do now is checking if the scaling works as expected
[12:47] <Cimi> paulliu, by testing the actual scaling factor
[12:47] <Cimi> paulliu, so instead testing if it scales up or down, test the exact scale
[12:49] <paulliu> Cimi: I've added that already.
[12:50] <paulliu> Cimi: The test.answer4 is the exact scaling factor
[12:50] <Cimi> I didn't see it, sorry
[12:51] <Cimi> paulliu, I don't think it's enough, we should test more values
[12:51] <paulliu> Cimi: ok. Do you mean the image size or?
[12:52] <Cimi> paulliu, testing more than 1 zoom action
[12:52] <Cimi> maybe a long pinch, a small pinch, a pinch out...
[12:52] <paulliu> Cimi: ok. got it.
[12:52] <Cimi> at least this is IMHO
[12:52] <Cimi> mzanetti, what would you test in a zoomable image component?
[12:52] <Cimi> in reference of this https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941
[12:52]  * mzanetti looks at the code
[12:56] <mzanetti> Cimi: mousewheel, pinching, flickable's contentHeight/width after zooming to max/min
[12:56] <Cimi> paulliu, ^
[12:57] <mterry> kgunn, looks like silo 004 was needed for non split stuff?
[12:57] <kgunn> mterry: ok, we can keep pestering for a silo throughout the day
[12:57] <mzanetti> Cimi, paulliu: seems the MouseAray is supposed to NOT accept keypresses. Maybe place another one one behind it and make sure the first one is indeed click-through
[12:57] <mzanetti> MouseArea
[12:58] <kgunn> mterry: i imagine that's a weekend symptom....alot of stuff should land today and clear out the silos...i reckon
[12:58] <mterry> kgunn, makes sense
[13:01]  * mzanetti hopes to free silo 15 today :D
[13:01] <paulliu> mzanetti: you mean put mousearea inside the PinchArea?
[13:02] <mzanetti> paulliu: hmm... does the PinchArea "eat" mouse presses?
[13:02] <mzanetti> paulliu: or better: Is the reason for the topmost MouseArea to forward events to the PinchArea only?
[13:02] <paulliu> mzanetti: MouseArea eat TouchEvents.
[13:02] <paulliu> mzanetti: yes..
[13:03] <mzanetti> paulliu: ah ok. in that case, ignore the MouseArea comment and just make sure the PinchArea works
[13:03] <paulliu> mzanetti: Actually there's some weirdness here. After an upgrade I found I have to move PinchArea in front of MouseArea. or things doesn't work.
[13:04] <mzanetti> ok.. in which case I guess the event.accepted = false could go away
[13:04] <paulliu> mzanetti: Flickable handles the mouse key presses by itself. So the images can move around.
[13:05] <paulliu> mzanetti: ok. thanks. I'll add the tests you mentioned.
[13:05] <tsdgeos> MacSlow: you're missing the checklist :D
[13:05] <tsdgeos> MacSlow: why is the forceLayout needed?
[13:05] <MacSlow> tsdgeos, doh... right :)
[13:05] <tsdgeos> i mean shouldn't the backend do that?
[13:05] <mzanetti> paulliu: that's just what comes from the top of my head after giving it a quick look
[13:07] <Saviq> mzanetti, we don't have the deps sorted out properly yet
[13:07] <mzanetti> hmm...
[13:08] <mzanetti> Saviq: which ones in particular?
[13:08] <Saviq> mzanetti, unity8 does not depend on unity-application-impl, which it should (it only depends on -impl-2)
[13:08] <Saviq> mzanetti, and unity-mir does not provide neither
[13:08] <MacSlow> tsdgeos, you're the Qt-expert :) I just now it's also needed in the tst_Notifications.qml to make it work
[13:08] <Saviq> mzanetti, results in unity8-fake-env being pulled on the device
[13:09] <mzanetti> oh... I c
[13:09] <tsdgeos> MacSlow: hmmmah, didn't realize this was Item forceRelayout, i thought it was a Notifications specific thing
[13:09] <MacSlow> tsdgeos, besides... forceLayout() is a method of the ListView (thus part of the frontend/renderer) the backend could not (and should not) mess with that.
[13:09] <Saviq> mzanetti, unity8-fake-env needs to Provides: unity-application-impl and unity-application-impl-2, too
[13:10] <tsdgeos> MacSlow: ok, i see we're using this already in one place so let's get it merged i guess
[13:10] <mzanetti> Saviq: what's this? "Provides: qtubuntu-shell"
[13:10] <mzanetti> found in unityfake-env
[13:10] <Saviq> mzanetti, that's probably exactly that
[13:10] <MacSlow> tsdgeos, also added the checklist.
[13:11] <Saviq> mzanetti, needs to be dropped
[13:11] <mzanetti> ack
[13:11] <tsdgeos> MacSlow: i'll force a rebuild, just to make sure it works again
[13:11] <MacSlow> tsdgeos, don't
[13:11] <MacSlow> tsdgeos, I just did that...
[13:11] <Saviq> mzanetti, from qtubuntu's Provides, too
[13:11] <tsdgeos> MacSlow: ah, cool
[13:11] <MacSlow> tsdgeos, http://s-jenkins.ubuntu-ci:8080/job/unity8-ci/2679/
[13:11] <Saviq> mzanetti, as it doesn't actually provide it any more
[13:11] <mzanetti> yep
[13:12] <tsdgeos> MacSlow: oki, will approve if that one suceeds then :)
[13:13] <MacSlow> tsdgeos, yeah... it should... I mean it already did just an hour ago... but better wait for the current build, just to be sure...
[13:13] <tsdgeos> yep :)
[13:13] <Saviq> didrocks, q: unity8-fake-env and libunity-mir1 will: Provides foo-impl, foo-impl-2; unity8 will Depends: libunity-mir1 | foo-impl, foo-impl-2; will libunity-mir1 be upgraded in favour of installing unity8-fake-env?
[13:14] <Saviq> when upgrading unity8, that is?
[13:14] <MacSlow> tsdgeos, btw... that visual-snap-decision branch did pass before... I'm just puzzled it failed on that test after the merge to trunk.
[13:14] <Saviq> mterry, hey, there's a conflict in split greeter again
[13:14] <tsdgeos> MacSlow: things randomly are slower or not slower
[13:15] <MacSlow> tsdgeos, probably... it's sad
[13:16] <mterry> Saviq, will update
[13:17] <Saviq> didrocks, mzanetti, also, I think we should add Breaks: lxc-android-config (<= blah), so that upgrade of unity8 will force upgrades of all the packages deprecated surfaceflinger support, wdyt?
[13:17]  * mzanetti believes whatever didrocks will say :D
[13:17] <Saviq> mzanetti, yeah, it's a bit convoluted here
[13:18] <Saviq> mzanetti, but I think we should achieve a state where "apt-get install unity8" will result in effectively installing all the things from the PPA
[13:18] <mzanetti> I agree, yes
[13:22] <mzanetti> Saviq: does this look sane to you? http://paste.ubuntu.com/7184799
[13:25] <Saviq> mzanetti, unity8-private does not implement Unity.Application does it?
[13:25] <Saviq> mzanetti, should be libunity-mir1?
[13:26] <mzanetti> Saviq: no, it's unity-fake-env & libunity-mir1
[13:26] <Saviq> mzanetti, +         unity8-private | unity-application-impl,
[13:26] <mzanetti> both provide Unity.Application
[13:26] <Saviq> mzanetti, yeah, so that above is wrong
[13:27] <mzanetti> ah... got it. true
[13:27] <Saviq> mzanetti, the whole idea behind foo | foo-impl is for "foo" to be the default selection
[13:27] <Saviq> mzanetti, so foo needs to provide foo-impl
[13:27] <mzanetti> so should this just be application-impl or "libunity-mir1 | unity-application-impl" right?
[13:27] <mzanetti> err, yes, the latter
[13:28] <Saviq> mzanetti, it needs to be |, otherwise apt will not resolve
[13:28] <Saviq> mzanetti, 'cause there can't be an only-virtual Depends
[13:29] <mzanetti> ok. fixed
[13:29] <mzanetti> and hopefully understood it a bit better
[13:29] <mzanetti> thanks for all the patience.
[13:37] <Saviq> mzanetti, I think qtubuntu needs Breaks: unity8 (<= $new_version)
[13:38] <Saviq> mzanetti, as that's actually what happens - it doesn't install the Unity.Application plugin any more
[13:38]  * Saviq needs to summarize this
[13:40] <mzanetti> Saviq: hmm... where is that?
[13:40] <Saviq> mzanetti, where is what?
[13:41] <mzanetti> Saviq: re "http://paste.ubuntu.com/7184799"
[13:41] <mzanetti> ah... wrong paste
[13:41] <mzanetti> Saviq: now "I think qtubuntu needs Breaks: unity8 (<= $new_version)"
[13:41] <MacSlow> mzanetti, tsdgeos: I've updated all related branches to "modal snap-decisions".  Ubuntu.Application vs. unity-application-impl....
[13:43] <Saviq> or is it Unity.Application already?
[13:43] <mzanetti> yes, it is
[13:43] <Saviq> ah U.A., ok
[13:43] <Saviq> that's better
[13:44] <mzanetti> Saviq: I changed that when introducing it in unity-api
[13:45] <mzanetti> Saviq: thinking about it. does it really break unity8?
[13:45] <Saviq> mzanetti, it does when you'd have mir disabled
[13:45] <mzanetti> it just wouldn't install the SF support any more. but with Mir, unity still works
[13:46] <Saviq> mzanetti, yeah, but if you use sf, and upgrade qtubuntu, but don't upgrade unity8
[13:46] <Saviq> mzanetti, broken
[13:46] <mzanetti> but the package is still required (for Qt QPA). so not sure its really a good idea to add the Breaks
[13:46] <Saviq> mzanetti, it will just ensure upgrading of unity8
[13:46] <Saviq> mzanetti, nothing else
[13:46] <mzanetti> ah ok
[13:46] <mzanetti> ok, adding it
[13:46] <Saviq> mzanetti, as it will only break previous unity8 versions
[13:47] <Saviq> mzanetti, I pushed a debian/changelog bump to unity8 right-edge-2
[13:47] <mzanetti> ack
[13:48] <Saviq> mzanetti, so Breaks: unity8 (<= 7.85)
[13:48] <Saviq> but I'm analyzing the other things
[13:49] <mzanetti> Saviq: <= 7.84, right?
[13:49] <Saviq> mzanetti, no, 7.84 is the current version
[13:49] <Saviq> mzanetti, ah yeah
[13:49] <mzanetti> yep, there's a =
[13:49] <Saviq> < vs. <=
[13:49] <Saviq> mzanetti, we need < 7.85 then I think
[13:50] <mzanetti> Saviq: seeing other examples its either <= or <<
[13:50] <Saviq> yes <<
[13:50] <mzanetti> ok
[13:59] <fginther> mterry, regarding the unity8 unlock script.  Is the unlock permanent (at least until unity8 is restarted) or can the screen lock back on it's own after a timeout?
[14:03] <Cimi> dunno
[14:03] <mterry> fginther, with this unlock script alone, the screen will timeout, but the jenkins scripts separately add a powerd block so it doesn't
[14:11] <didrocks> Saviq: yeah, libunity-mir1 shold be upgraded in favour of installating unity8-fake-env
[14:12] <didrocks> (sorry, back from running, backlogging)
[14:12] <didrocks> Saviq: so, both latest unity8 and lxc-android-config should be installed once we drop SF, right?
[14:13] <didrocks> Saviq: or the new unity8 with the old lxc-android-config is fine?
[14:13] <didrocks> (it seems it will be to me, no?)
[14:14] <fginther> mterry, oh ok. that's the question I was trying to resolve with doanac and the use of system settle
[14:14] <Saviq> didrocks, yeah, lxc-android-config shouldn't break anything
[14:14] <Saviq> didrocks, but then there's ubuntu-touch-session
[14:14] <didrocks> ah, and this one needs to be upgraded in sync with unity8,
[14:14] <didrocks> ?
[14:14] <MacSlow> tsdgeos, that last rebuild I triggered failed because of a defuct package-download... *sigh* just retriggered it.
[14:15] <Saviq> didrocks, yeah, I think so, otherwise people who ran sf before will still run sf, but there's no more ubuntuappmanager plugin
[14:16] <didrocks> Saviq: ok, so I guess new touch-session breaks: unity8 (<< first-version-without-sf-support)
[14:18] <Saviq> didrocks, qtubuntu also Breaks: ubuntu-touch-session (<< first-version-without-sf-support), right?
[14:19] <Saviq> didrocks, since u-t-s might want to launch unity8 with sf support, but there's no application plugin for sf from qtubuntu any more?
[14:19] <didrocks> Saviq: yeah, seems it's in that way
[14:19] <Saviq> didrocks, and the last thing... lxc-android-config disables surfaceflinger unconditionally, so should Breaks: ubuntu-touch-session (<< foo), too?
[14:20]  * Saviq summarizes
[14:21] <didrocks> hum, unsure about lxc-android-config and u-t-s. isn't it u-t-s disabling surfaceflinger launched in the session?
[14:21] <Saviq> didrocks, l-a-c is the one actually preventing the surfaceflinger service to start in the container
[14:21]  * Saviq thinks http://pastebin.ubuntu.com/7184985/
[14:21] <didrocks> you didn't draw a map! :p
[14:22] <Saviq> didrocks, I know, I should, tried to explain as best I understand it
[14:22] <didrocks> heh, no worry
[14:22] <didrocks> so, on the first 2 ones, ack, let me reread for lxc-android-config and u-t-s though
[14:22] <didrocks> ah, so, it's not u-t-s starting surfaceflinger, but l-a-c
[14:23] <Saviq> didrocks, stopping, rather than starting, but yeah
[14:23] <Cimi> dednick, could you have a look at a branch and tell me what's wrong with it?
[14:23] <didrocks> Saviq: ahhhh, got it
[14:23] <didrocks> Saviq: so yeah, making sense
[14:23] <dednick> Cimi: i can try
[14:23] <dednick> but you'll need to give me a indication as to what i'm looking for
[14:24] <Cimi> dednick, this one
[14:24] <Cimi> https://code.launchpad.net/~cimi/ubuntu-system-settings/wizard.privacy/+merge/213124
[14:24] <didrocks> Saviq: yeah, just reread and +1 on the plan
[14:24] <Cimi> dednick, the settings are not in sync
[14:24] <Cimi> dednick, when I set something in the wizard, it doesn't get updated in the system settings
[14:24] <Cimi> dednick, but it works opposite way
[14:24] <Cimi> code seems the same
[14:25] <dednick> Cimi: checked: diagnosticsWidget.canReportCrashes
[14:26] <dednick> binding is broken when checked changes in the DiagnosticsCheckEntry
[14:27] <Cimi> dednick, but this changes back, no?
[14:27] <dednick> Cimi: same as the slidermenu before
[14:27] <dednick> need a serverValue kind of thing
[14:27] <Cimi> mmm o
[14:29] <mzanetti> dednick: jfi. entering the pin using qdbus still works. the phone gets signal afterwards
[14:30] <dednick> mzanetti: i've just tested it with devel-proposed. seems fine on my phone :(
[14:31] <mzanetti> dednick: hmm... strange... anything I could do to get you more information?
[14:31]  * mzanetti reboots the phone
[14:32] <mzanetti> dednick: nope. not here again after a reboot
[14:32] <Saviq> mzanetti, please bump ubuntu-touch-session to 0.107, and add the Breaks as described in http://pastebin.ubuntu.com/7184985/
[14:32] <dednick> mzanetti: hm. hang on. just trying again
[14:33] <Saviq> mzanetti, where $first-without-sf-support is 0.107
[14:37] <dednick> mzanetti: can you check with indicator-network version you have?
[14:38] <mzanetti> dednick: 0.5.1+14.04.20140318-0ubuntu1
[14:39] <dednick> mzanetti: libqmenumodel0 as well please?
[14:40] <mzanetti> dednick: 0.2.7+14.04.20140305-0ubuntu1
[14:42] <Cimi> dednick, where was your branch with the server value? I cannot remmber
[14:42] <dednick> Cimi: MenuItemFactory
[14:53] <Saviq> mterry, shall I kick the split greeter silo yet?
[14:53] <dednick> mzanetti: hmm.. all same as me. very strange
[14:53] <mterry> Saviq, yeah OK!  I think there are some newer Mir branches we might want.  Let me check
[14:53] <Saviq> mterry, btw, it's silo 002 now
[14:53] <dednick> mzanetti: can you run up the indicators-client app on the phone and send me a screenshot of the network page?
[14:53] <mterry> Saviq, k
[14:54] <Saviq> mterry, yeah, please look through the list of MPs if we want anything new, or drop anything
[14:54] <mterry> Saviq, lp:~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server and lp:~alan-griffiths/mir/another-Surface-bites-the-dust (which is already in mir/devel, so I guess you don't need it?)
[14:55] <mterry> tedg, what's the story with landing indicator-sound again?  Is there a silo in queue?
[14:56] <Saviq> mterry, anpok's one was already in the list, so we only need that, all in all?
[14:56] <tedg> mterry, Was waiting on beta freeze and then thostr to be off vacation, asked about getting a silo about 10 minutes ago :-)
[14:56] <Saviq> mterry, anything else we could drop? http://pastebin.ubuntu.com/7185109/
[14:56] <mterry> tedg, awesome  :)
[14:57] <mterry> tedg, with the volume schema branch too!  ;)
[14:57] <tedg> mterry, Yup, it's on the sheet.
[14:57] <mterry> Saviq, I think that's everything
[14:57] <Saviq> mterry, ok, kicking mir to start with
[14:57] <mterry> tedg, ah yes, we talked about that last week
[14:58] <anpok> Saviq: the one from alan fixes some issue that crept up with osk
[14:58] <Cimi> mterry, could you review my wifi branch?
[14:58] <Saviq> anpok, kthx
[14:58] <mterry> Cimi, OK, will look today
[14:58] <Saviq> mzanetti, please ping when we're ready to kick the right edge silo again
[15:03] <mzanetti> Saviq: yep. doing now. was eating.
[15:03] <Saviq> mzanetti, ok nw
[15:04] <mzanetti> Saviq: just realized that we have a hard dep on libunity-mir1 already
[15:04] <mzanetti> Saviq: I supposed that one should go in favor of the | app-impl
[15:05] <mzanetti> or is there anything else in there we hard-depend on?
[15:05] <Saviq> mzanetti, we dlopen the actual lib, not just the plugin
[15:05] <mzanetti> ok.
[15:06] <Saviq> mzanetti, so it's good for it to be logically there
[15:06] <Saviq> mzanetti, especially since foo | bar could arguably be fulfilled by bar, at which point foo wouldn't be pulled in
[15:07] <mzanetti> yep, in that case it is. doesn't make it easier to understand by reading th depends, but its the most correct thing, I agree
[15:07] <Saviq> scratch that, we're actually linking against libunity-mir, not dlopen'ing it
[15:07] <Saviq> mzanetti, which means yeah
[15:07] <Saviq> mzanetti, drop it
[15:07] <Saviq> mzanetti, only leave the | unity-application-impl-1 one, the hard one will get there from shlibs anyway
[15:07] <mzanetti> ah ok
[15:08] <mzanetti> just wanted to say that it is needed still
[15:08] <mzanetti> but yep, didn't think about shlibs
[15:08] <Saviq> mzanetti, noticed «qgetenv("QT_QPA_PLATFORM") == "ubuntu"»
[15:08] <Saviq> mzanetti, can begone, too
[15:08] <mzanetti> oh dear... I'm afraid I opnened another can :D
[15:09] <Saviq> I think that's the last one :D
[15:09] <Saviq> or well, maybe it could stay still
[15:09] <Saviq> mzanetti, leave it
[15:09] <mzanetti> :D
[15:09] <Saviq> mzanetti, so we can still run under surfaceflinger in fullscreen with the fake app
[15:09] <Saviq> mzanetti, since we're not dropping the surfaceflinger QPA (yet)
[15:10] <mzanetti> ah right. true
[15:10] <mzanetti> makes sense
[15:11] <mzanetti> not saying that I want to change it, but looks intersting too:
[15:11] <mzanetti> Replaces: unity-mir,
[15:11] <mzanetti> Conflicts: unity-mir,
[15:11] <mzanetti> Provides: unity-mir,
[15:11] <Saviq> there's no such package :)
[15:11] <mzanetti> lol
[15:11] <Saviq> mzanetti, where did you find that?
[15:12] <mzanetti> libunity-mir1
[15:12] <Saviq> mzanetti, unity-mir debian/control?
[15:12] <mzanetti> yeah
[15:12] <Saviq> mzanetti, yeah, leave it
[15:12] <Saviq> mzanetti, does not hurt, we'll drop it sometime
[15:12] <mzanetti> yep
[15:13] <Saviq> mterry, only mir needs to be built before the rest, right? so after mir completes, I can kick the rest?
[15:13] <mterry> Saviq, should be
[15:13] <Saviq> mterry, kk
[15:15] <mzanetti> Saviq: all branches pushed
[15:15] <mzanetti> triggering rebuild
[15:16] <Saviq> mzanetti, k
[15:16] <Saviq> let's see if that will be the last one :D
[15:16]  * mzanetti hopes :D
[15:56] <elopio> hello people. Can I get a review here? https://code.launchpad.net/~elopio/unity8/search_updated/+merge/213155
[15:56] <elopio> tsdgeos: you reviewed the original branch, so...
[15:57]  * tsdgeos is sprinting
[15:57] <tsdgeos> let me run a bit faster
[15:57] <tsdgeos> :D
[16:00] <Cimi> dednick, still no luck http://paste.ubuntu.com/7185444/
[16:03] <dednick> Cimi: does the maybeUpdate code get executed?
[16:05] <dednick> Cimi: oh, it was removed..
[16:05] <dednick> Cimi: are you sure that canReportCrashes is changing?
[16:06] <Cimi> dednick, unless it's bugged...
[16:06] <dednick> Cimi: perhaps you should check :)
[16:06] <Cimi> dednick, dunno how
[16:06] <dednick> Cimi: eh?
[16:07] <Cimi> printing it
[16:07] <Cimi> ok
[16:08] <Cimi> dednick, indeed doesn't seem to change
[16:08] <dednick> Cimi: wel...
[16:09] <Cimi> dednick, it's not my code :P
[16:09] <Cimi> dednick, someone reviewed and approved that :P
[16:11] <Cimi> dednick, http://bazaar.launchpad.net/~system-settings-touch/ubuntu-system-settings/trunk/view/head:/plugins/security-privacy/diagnostics/diagnostics.cpp
[16:11] <Cimi> dednick, maybe the signal update is not emitted?
[16:12] <Cimi> dednick, or is just emitted for one single ownwer?
[16:13] <Cimi> wondering if it's emitted or not
[16:15]  * Cimi rebuilds
[16:15] <dednick> Cimi: no idea. code looks like it should be
[16:28] <Saviq> mzanetti, ubuntu-touch-session still at v0.106, we need to bump it to 0.107
[16:31] <Saviq> mzanetti, /me bumped
[16:33] <mzanetti> Saviq: thanks
[16:36] <Saviq> hmm we still can upgrade unity8 separately, 'cause of unity8-fake-env already being there I think...
[16:37] <Saviq> damn what pulled that thing in...
[16:42] <Saviq> mzanetti, humpf, unity8-private has "provides: unity-application-2"
[16:42] <Saviq> mzanetti, that's wrong, it doesn't provide it
[16:44] <Saviq> mzanetti, fixed
[16:58] <Saviq> mterry, looks like there are some build failures https://launchpadlibrarian.net/171368822/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.2%2B14.04.20140331.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[17:02] <mterry> Saviq, looking
[17:02] <Saviq> mterry, also weird - https://launchpad.net/~ci-train-ppa-service/+archive/landing-002/+sourcepub/4056446/+listing-archive-extra
[17:03] <mterry> Presumably the ftbfs is due to mir changes
[17:03] <Saviq> yeah
[17:03] <Saviq> mterry, tries to pull old libplatform-api1-dev for some reason...
[17:03] <mterry> Saviq, what am I looking at with that listing-archive-extra link
[17:04] <mterry> oh the ftbfs
[17:04] <Saviq> mterry, yup
[17:04] <mterry> Saviq, that could be due to synchronization issues -- probably should build platform-api before unity-mir then
[17:05] <Saviq> mterry, yeah, might not have gotten ready yet
[17:05] <Saviq> mterry, probably kicked the build too early for those two
[17:06] <mterry> I didn't realize they needed to be in sequence either
[17:07] <mterry> Er, I mean not sequence.  But standard settling differences between any / all packages
[17:08] <kgunn> mterry:  i unity-mir does need to build after platform-api
[17:08] <mterry> kgunn, k
[17:08] <kgunn> mterry: uh-oh...is that just an api break on mir tho ?
[17:09] <mterry> kgunn, well, we are testing with mir/devel so probably.  That breaks all the time, eh?
[17:14] <kgunn> mterry: well it can for ABI...but API shouldn't without warning and is much more rare
[17:16] <mterry> kgunn, well not in my experience, but probably because I'm always prodding the edges of the API in USC
[17:17] <kgunn> mterry: if you need any help updating....ping kdub, i know he and duflu have been tinkering with compositor/render classes....
[17:17] <kgunn> looks like you got hit with that....
[17:17] <mterry> kgunn, this seems to be scene / surface reorganization
[17:18] <mterry> I will poke if I need help, but it might be easy change
[17:18] <kgunn> oh..you're right, just saw surface ranker
[17:18] <kgunn> which would be alan_g
[17:18] <kdub> yeah, we've been remodeling around the scene
[17:19] <kgunn> greyback: ^ you might potentially be effected ?
[17:19] <kgunn> (maybe less so with qtsg)
[17:20] <greyback> kgunn: I believe alan_g|EOD has a branch for unity-mir to update it for mir API changes
[17:21] <kgunn> mterry: guess alan_g doesn't like you as much as gerry :)
[17:21] <mterry> :)
[17:22] <mterry> Well, I think his reorganization fixed an issue split was seeing.  So I'll survive
[17:23] <kgunn> josharenson: yo, how's the plodding along for glmark2
[17:24] <josharenson> kgunn: it was working great on Friday, and not at all today. I have some theories, and I'm working on it.. I also wrote some simple unit-test for mir just to familiarize myself
[17:27] <kgunn> josharenson: great
[18:32] <tedg> Updated my phone and now it's not showing anything graphical on boot.
[18:32] <tedg> Unity is sucking CPU.
[18:32] <tedg> Not sure what's up.
[18:39] <tedg> Looks like it's just looping with this: http://pastebin.ubuntu.com/7186210/
[18:41] <tedg> Installed libunity-core-6.0-9 and that fixed it.
[21:26] <kgunn> josharenson: hey, so from earlier...when you said "it was working" before it didn't :)
[21:26] <kgunn> did you mean that glmark2 was actually running as part of the ci ?
[21:26] <josharenson> kgunn: yeah I build from source and it works now
[21:27] <josharenson> kgunn: no I just meant the gles2-mir version wasn't working
[21:27] <kgunn> mmm
[21:27] <kgunn> ok
[21:28] <josharenson> kgunn: built from source _and_ installed the deb.. I think the deb may have been trying to run all tests (ie: x11)
[21:30] <josharenson> kgunn: currently trying to duplicate the jenkins build process locally, as closely as practical so I don't have to keep pushing branches (just for now while I learn)
[21:46] <kgunn> josharenson: cool
[22:11] <greyback> bregma: ping
[22:11] <bregma> greyback, pong
[22:13] <greyback> bregma: hey, a while back I recall Qt was compiled using GL when GLES was needed - was there a workaround to select GLES instead of GL? Or is it fixed build-time?
[22:14] <greyback> I'm getting http://pastebin.ubuntu.com/7187111/
[22:14] <greyback> oh hang on, GLES is being used...
[22:14] <bregma> I split qtubuntu into a -desktop build that is compile-time GL and a -android build that is compile-time GLES
[22:15] <bregma> that problem looks like the more recent QT5.2-on-EGL problem
[22:15] <greyback> oh joy
[22:15] <greyback> any bug or anything reported for that?
[22:17] <bregma> greyback, not upstream, I wasn;t sure if the problem was in qtubuntu not getting a context correctky or Qt itself not handling an EGL context that supports both GL and GLES
[22:17] <bregma> need an EGL expert to decide that
[22:17] <greyback> bregma: ok. You've put me on an attack path anyway, thank you
[22:18] <bregma> the root of the problem is that Qt5.2 will compile the shaders for GL only if the QPA supports _only_ GL, and not, say, the default
[22:18] <bregma> it's using an enum when a bitmask may be more appropriate