[00:44] <mup> PR snapd#2092 opened: store: do not set store auth for local users <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2092>
[01:06] <mup> PR snapd#2082 closed: overlord,daemon,snap: support gadget config defaults <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2082>
[01:07] <mup> PR snapd#2071 closed: interfaces,overlord/ifacestate: switch to use declaration-based checking for auto-connect <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2071>
[01:17] <mup> PR snapd#2089 closed: store: do not set store auth for local users <Created by matiasb> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2089>
[01:17] <mup> PR snapd#2092 closed: store: do not set store auth for local users <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2092>
[03:20] <mup> PR snapd#2093 opened: cmd/snap,ctlcmd: fix behavior of snap(ctl) get <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2093>
[06:06] <mup> PR snapd#2094 opened: docs: fix missing "=" in the systemd-active docs <Created by mvo5> <https://github.com/snapcore/snapd/pull/2094>
[06:18] <mvo> ogra_: thanks for setting up "core". could we make it so that core is auto-triggered to build daily just like ubuntu-core? that would be great!
[06:25] <dholbach> good morning
[06:40] <mup> PR snapd#2094 closed: docs: fix missing "=" in the systemd-active docs <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2094>
[07:22] <morphis_> zyga: ping
[07:43] <mvo> pitti: quick question - what is the best way to conditionall enable a systemd service (cloud-init in my case). during boot I want to evaulate via "snap get core cloud-init.enabled" if it should run or not and based on target start cloud-init.target. should I just do that in a new snapd.cloud-init.service  ? "ExecStart=/bin/sh -c "if snap get core cloud-init.enabled; do systemctl start cloud-init.target; fi"? or is there a better way to do that?
[07:45] <pitti> mvo: not sure that this works as cloud-init wants to run *very* early; you can't alter the early boot transaction while you are already in that
[07:45] <pitti> mvo: I can think of two ways:
[07:46] <pitti> 1) write a generator which does the get and enables cloud-init.service in the generator run dir
[07:46] <pitti> (that's the "official" way)
[07:46] <pitti> 2) run snapd.cloud-init.service Before=cloud-init-local.service, if enabled create a /run/somewhere/run_cloud_init, and add ConditionPathExists=/run/somewhere/run_cloud_init to cloud-init*.service
[07:47] <pitti> but the latter is the same effort with a non-standard way to enable it and requires modifying cloud-init.service (you can do that with drop-ins); so I'd actually just use a generator
[07:48] <pitti> mvo: I thought cloud-init already had like five different ways to enable/disable it -- none of them are suitable?
[07:48] <pitti> (kernel command line, flag files, etc.)
[07:48] <mvo> pitti: well, maybe I have not found the right one yet :) I want it to be totally disabled, i.e. no python running by default to not slow down boot on arm
[07:49] <mvo> pitti: the /etc/cloud/cloud-init.disabled does not do that, there is still python code run afaict (mind you, I'm not a cloud-init expert)
[07:49] <pitti> ah, too bad -- otherwise that could just be the flag file
[07:49] <pitti> although having it in /run would be better
[07:49] <mvo> pitti: yeah
[07:49] <pitti> mvo: so, I'd say just write a generator
[07:50] <mvo> pitti: this will run very early, right?
[07:50] <pitti> mvo: yes, before any unit starts; so you can make essentially zero assumptions about r/w mounts, remote mounts, networking etc.
[07:50] <pitti> but for checking a config option it should work fine
[07:50] <mvo> pitti: hm, that is also going to be tricky because of the way the snapd config works. hm hm
[07:51] <mvo> pitti: essentially a config get goes through snapd
[07:51] <pitti> oh
[07:51] <mvo> pitti: but thanks, I won't bother you more with this, let me think about this some more, this is really helpful so far
[07:51] <pitti> mvo: when does snapd start?
[07:51] <pitti> mvo: there is no way to get that config option without the daemon?
[07:51] <mvo> pitti: in multi-user somewhere
[07:52] <mvo> pitti: maybe, I need to check that out
[07:52] <pitti> mvo: ok, way too late; cloud-init (the earliest is cloud-init-local) runs basically as the second thing after boot
[07:52] <pitti> s/after/at/
[07:53] <mvo> pitti: uhhh
[07:53] <pitti> mvo: it wants to be able to change fstab entries, reformat partitions etc.
[07:53] <clobrano> Hi everybody, I was looking at some bugs to fix, and saw Bug #1470661. Is it still a valid one? The code has changed a lot, this problem is still reproducible,but snapcraft schema allows tilde in version
[07:53] <mup> Bug #1470661: Tilde allowed in version but systemd hates it <Snappy:Triaged> <Snappy 15.04:Won't Fix> <Snappy trunk:Triaged> <https://launchpad.net/bugs/1470661>
[07:54] <mvo> pitti: thanks, tricky
[07:55] <pitti> mvo: hm, I thought it had some ConditionSomething= on a file, seems not
[07:55] <pitti> mvo: then again, how many features of cloud-init would actually work on snappy? most certainly not the fstab, formatting, package installation, etc. parts
[07:56] <pitti> mvo: so on snappy you might actually get away with starting it later
[07:56]  * pitti suggests discussing that in a hangout with smoser
[07:56] <pitti> mvo: but still -- I'd say, find a way to get that flag without the daemon
[07:59] <mvo> pitti: yeah, that is a good point, again, thanks for your input
[08:56] <zyga> ara: hey
[08:57] <ackk> hey, I think you query'd the wrong nick :)
[08:57] <ackk> n/m, my client tricked me
[08:58] <zyga> ara: we found this bug https://bugs.launchpad.net/snap-confine/+bug/1630479
[08:58] <mup> Bug #1630479: permission denied while opening mount namespace file <Snappy Launcher:In Progress by zyga> <snap-confine (Ubuntu):In Progress by zyga> <https://launchpad.net/bugs/1630479>
[08:58] <zyga> ara: this will probably fail verification (well, it's a regression compared to .38) but we already fixed it and I'll probably upload .43
[09:04] <ara> zyga, thanks for the heads up
[09:04] <ara> zyga, (even if it is bad news!) :)
[09:06] <morphis_> zyga: ping
[09:11] <mup> PR snapd#2095 opened: snapstate: fix hanging `snap remove` if a try mount dir is no longer mounted <Created by mvo5> <https://github.com/snapcore/snapd/pull/2095>
[09:14] <zyga> morphis_: hey
[09:19] <morphis_> zyga: hey!
[09:19] <morphis_> zyga: you came forward yesterday with the /media share work?
[09:19] <zyga> morphis_: some, I'm working on that now
[09:20] <morphis_> zyga: I read yesterday here that you're out tomorrow and on friday, so you want to complete it today?
[09:20] <zyga> morphis_: yes
[09:20] <mup> PR snapcraft#716 closed: Add Waf plugin (LP: #1611335) <Created by cpaelzer> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/716>
[09:22] <morphis_> zyga: ok, then please lets discuss later today where you stop with this and what the status is
[09:22] <zyga> ok
[09:22] <zyga> sounds good
[09:32] <morphis_> zyga: I guess for the feature-freeze this needs to be done today anyway, right?
[09:33] <zyga> morphis_: I don't know
[09:33] <zyga> morphis_: gustavo said we might do this after ff and just treat it as a bug
[09:33] <zyga> morphis_: but my plan is to do it today
[09:33] <mup> PR snapd#2096 opened: tests: check for failure creating user on managed ubuntu-core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2096>
[09:39] <ogra_> mvo, i was waiting for the store to support auto landing (it was still failing yesterday on "type: os")
[09:40] <ogra_> but yeah, as i said yesterday, i'm plainning to set that up today
[09:41] <ara> hello! can I set up any env variable so that "snap login" uses the staging SSO site?
[09:49] <ogra_> zyga, a line or two in bug #1630492 would have avoided the heart attack i just had :P
[09:49] <mup> Bug #1630492: /var/lib/extrausers is wrong in all-snap <Snappy Launcher:In Progress by zyga> <https://launchpad.net/bugs/1630492>
[09:50] <ogra_> (though whats wrong about it ?)
[10:07] <mup> PR snapd#2085 closed: many: check installation of slots and plugs against declarations <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2085>
[10:18] <sborovkov> hmm, when I do snap revert for snap installed in devmode does it keep devmode?
[10:18] <zyga> ogra_: whaaat?
[10:18] <zyga> ara: pedronis would probably know this
[10:18] <zyga> ogra_: it's empty :) fixing it now
[10:19] <sborovkov> yeah, it does not... Does that even make any sense?
[10:20] <mup> PR snapd#2097 opened: snap: add `snap is-managed` for console-conf <Created by mvo5> <https://github.com/snapcore/snapd/pull/2097>
[10:21] <ara> zyga, thanks
[10:21] <ara> pedronis, question was whether there was an env variable (or other method) so that snap login points to the staging SSO site
[10:24] <pedronis> ara: yes, but it needs to be set of snapd, so you need some kind of  /etc/systemd/system/snapd.service.d/local.conf and setting USE_STAGING_STORE=1 there, but also you need a specially built with snapd
[10:24] <pedronis> s/of snapd/for snapd/
[10:25] <ara> pedronis, but does USE_STAGING_STORE set, also sets staging SSO?
[10:25] <pedronis> ara: yes
[10:25] <pedronis> it points everything to staging
[10:25] <ara> pedronis, OK, I will try that
[10:25] <ara> " but also you need a specially built with snapd"
[10:26] <ara> ?
[10:26] <ara> what does that mean
[10:26] <pedronis> ara: if you do anything that involves getting assertions you need a snapd with the staging root key
[10:26] <pedronis> otherwise it will try to verify with only the prod one and that won't work
[10:27] <ara> pedronis, how do you do that? a snapd with the staging root key
[10:27] <pedronis> ara: are you on classic? or using an all-snaps image?
[10:28] <ara> pedronis, classic
[10:30] <pedronis> ara: you need a deb of snapd built with something like  DEB_BUILD_OPTIONS='nocheck testkeys' dpkg-buildpackage -tc -b -Zgzip or building snapd with go and replacing your system one
[10:30] <ara> pedronis, OK, will try that
[10:30] <ara> pedronis,
[10:30] <ara> pedronis, thanks
[10:32] <pedronis> ara: if you just build with go   :     go build -tags withstagingkeys ./cmd/snap and go build -tag withstagingkeys ./cmd/snapd should do the trick
[10:32]  * pedronis lunch
[10:33] <sborovkov> Hello. How do I revert snap revert? snap refresh does not work it seems
[10:33] <ara> pedronis, cool, will try that
[10:37] <zyga> sborovkov: "snap revert"
[10:39] <mup> Bug #1630520 opened: snap login error message incorrect <Snappy:Triaged by chipaca> <https://launchpad.net/bugs/1630520>
[10:39] <sborovkov> zyga: wait won't it revert to even more previous version?
[10:40] <sborovkov> zyga: also how does that make any sense that snap revert removes devmode...
[10:42] <popey> hm. I have a pi2 which auto updated overnight and now won't boot
[10:42] <popey> http://paste.ubuntu.com/23279200/ hangs at Starting kernel...
[10:43] <ogra_> popey, anything on screen or serial ?
[10:43] <popey> yes ^
[10:43] <ogra_> hmm, weird
[10:44] <popey> i have two pi's (a pi 2 and a pi 3) on daily images and the pi3 came back okay, but pi2 didn't
[10:45] <ogra_> well, nothing changed in the kernel
[10:45] <popey> sorry, I have them the wrong way round, pi2 came back, pi3 didn't it seems
[10:47] <popey> i need to put stickers on my pis to idenify them :)
[10:49] <ogra_> the pi3 has a white plastic bar on the top
[10:49] <ogra_> at least mine does
[10:50] <zyga> sborovkov: look at --help
[10:51] <ogra_> mvo, so the auto-builds are set up, but since the store still doesnt accept them i wont set up a cron entry until i heard back from roadmr that the fixes landed (like i said yesterday as well)
[10:51] <zyga> sborovkov: 12:47 < popey> i need to put stickers on my pis to idenify them :)
[10:51] <zyga> ogra_: plastic bar?
[10:51] <zyga> ogra_: photo?
[10:52] <popey> mine are in cases
[10:52] <popey> i need to put a sticker on the case
[10:52] <popey> I saw some nice transparent cases recently, which will help
[10:52] <ogra_> mvo, also note that the store now blocks *all* subsequent uploads if there was one failure in one revision upload
[10:54] <sborovkov> ogra_: oh wow. Now I know how to differentiate my RPIs. Never noticed that bar before
[10:54] <ogra_> zyga, similar to the pi1 in that pic mine has that white plastic thingy (vs the same part in black on the left one) https://www.pretzellogix.net/wp-content/uploads/2015/08/flirc-rpi-3.jpg
[10:54] <ogra_> next to the headphone jack ...
[10:54] <sborovkov> ogra_: to be fair though it also says the model in text if you don't have it without case
[10:55] <ogra_> but very fine print :)
[10:57] <popey> old man eyes
[10:57] <popey> http://www.raspberrypi-spy.co.uk/2012/09/checking-your-raspberry-pi-board-version/ is useful if you "grep Revision /proc/cpuinfo" :)
[10:57] <zyga> ahh
[10:58] <zyga> ogra_: you mean the flat-flex connector latch
[10:58] <popey> anyway, what can I do with this pi3 that won't boot?
[10:58] <ogra_> zyga, yeah, the bar :P
[10:58] <zyga> :D
[10:58] <nhaines> popey: well, if you leave it running it's probably nice for a small space heater.
[10:58] <popey> should I get something off the sd card? logs or somesuch?
[10:58] <zyga> the thing ;-)
[10:58] <ogra_> popey, hard reset
[10:58] <popey> ogra_: que?
[10:58] <ogra_> youo wouldnt get anything off the card anyway before anything is mounted
[10:59] <ogra_> so just reset it
[10:59] <popey> as in, dd a new image on it?
[10:59] <ogra_> you can indeed check via HDMI
[10:59] <ogra_> if there is an oops or so
[10:59] <ogra_> but beyond that, just do a reset
[10:59] <ogra_> popey, that power plug thing ... pull it and plug it in again :P
[11:00] <popey> hah, okay
[11:00] <ogra_> (i would have said re-flash otherwise ;) )
[11:00] <popey> I was hoping for some leet reset tool :)
[11:00] <popey> indeed, "reset" has other connotations for me, "reboot" might work ;)
[11:01] <popey> also as we call it in our house "Do a Daddy Pig"
[11:01]  * ogra_ notes that down for next time :)
[11:02] <popey> https://www.youtube.com/watch?v=fxqw0am27Fk is the episode in question
[11:03] <mup> Bug #1572175 changed: change finished in status "Hold" with no error message <amd64> <apport-bug> <sdoc> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1572175>
[11:06] <mvo> ogra_: ok, thanks
[11:08] <popey> ogra_: magically came back after a reboot :S
[11:11] <mup> PR snapcraft#852 opened: Simplify the parser tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/852>
[11:16] <ogra_> popey, yeah, i thought so, there is a mystical OOPS that we are still trying to debug ... ppisati didnt get further on that one either and i didnt manage to capture it yet
[11:16] <popey> ogra_: ok, thanks
[11:19] <ogra_> mvo, once enabled core info for the auto-builds will be at http://people.canonical.com/~ogra/core-builds/ (much like http://people.canonical.com/~ogra/ubuntu-core-builds/ was for ubuntu-core before)
[11:19] <sborovkov> zyga: btw "look at help" does not have anything about devmode or whatever. Idk I might be on old version though. Not going to update until that issue that makes snaps not working becase of cross architecture stuff is fixed...
[11:23] <mvo> ogra_: neato
[11:25] <zyga> sborovkov: oh, yes, perhaps it is not released yet, I'm running master
[11:25] <zyga> sborovkov: I think behavior changed and it should not behave as you expect
[11:37] <ogra_> cjwatson, is there any specific reason why s3390x and ppc64el do not publish their manifest files (i see in the log that they built)
[11:37] <ogra_> -3
[11:39] <mup> PR snapd#2098 opened: store: retry store operations (WIP) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2098>
[11:41] <cjwatson> ogra_: s390x hasn't been upgraded to the new launchpad-buildd because I'm lazy; ppc64el hasn't been upgraded for some mysterious reason we've yet to properly investigate
[11:41] <cjwatson> (its image upgrader script is probably broken somewhere ...)
[11:42] <ogra_> ah, ok ... it isnt that important anyway, just curiosity ... i doubt anyone but me cares :)
[11:45] <cjwatson> ogra_: I'll take care of s390x at least, ppc64el will be a bit of a when-we-get-round-to-it
[11:46] <ogra_> yeah, dont put it on to high prio, i doubt there are even many users on these arches atm
[11:46] <ogra_> (i wish i could look up the numbers, but the store times out when i click on "stats" for ubuntu-core :)  )
[11:47] <ogra_> hah, and saying tht, this time it didnt
[11:47] <ogra_> but no downloads by arch :(
[11:52] <cjwatson> Mainly I just like having production revisions of things in sync where possible.
[11:53]  * ogra_ notes mvo is a busy bee manually approving stuff in the store :)
[11:56]  * ogra_ thinks this new store behaviour of blocking the world is insane ... approving a set now takes ages since you have to wait for the next fail first
[12:02] <mup> PR snapd#2099 opened: docs/hooks.md: fix typos <Created by pedronis> <https://github.com/snapcore/snapd/pull/2099>
[12:06] <daker> hi snapcraft question, how can i tell the make plugin to run two make commands (make something then make) ?
[12:06] <zyga> daker: write the make rules so that you don't have to
[12:07] <daker> zyga: what do you mean ? write another Makefile that will run thoses make commands ?
[12:08] <zyga> daker: if you can control the original makefile just change that
[12:09] <daker> zyga: no i don't have control that's an upstream project, and the first make commands is from a submodules
[12:10] <ogra_> well, a toplevel makefile would likely work ... just put your upstream project in a subdir and have the toplevel makefile drive everything
[12:13] <hikiko> just for the record I found a solution for my problem with the libcuda1-361 package but it was a hack: I edited the /var/lib/dpkg/info/libcuda1-361.prerm and put an "exit 0;" at the beginning so that the script doesn't run, then I purged nvidia* and libcuda1* and then I had no issues
[12:24] <morphis_> zyga: how are things going?
[12:31] <zyga> morphis_: I'm having issues using all-snap systems
[12:32] <zyga> morphis_: fighting console-conf
[12:32] <morphis_> zyga: what kind of issues?
[12:32] <zyga> i cannot log in
[12:34] <morphis_> zyga: do you have a ssh key registered with your sso account?
[12:34] <zyga> ah, I think I know what the problem is
[12:34] <zyga> trying again
[12:34] <zyga> yes, certainly, I was just using the wrong key to log in
[12:43] <zyga> morphis_: I'm in :)
[12:44] <mup> PR snapd#2100 opened: store: local users download from the anonymous url <Created by matiasb> <https://github.com/snapcore/snapd/pull/2100>
[12:44] <morphis_> zyga: ah
[12:44]  * ogra_ hands zyga a lockpick for the next time
[12:45] <mup> PR snapd#2099 closed: docs/hooks.md: fix typos <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2099>
[12:46] <ogra_> mvo, if someone sends me an updated set of official assertions i can also set up the dailies to use core by default btw
[12:46] <ogra_> (if snapd is ready for that already indeed)
[12:54] <popey> anyone seen this before:- popey@localhost:~$ sudo snap refresh
[12:54] <popey> error: cannot refresh []: cannot refresh snap-declaration for "pi2": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/ZbHoNCV2YMyGLhAf1U9SLaOvuVD02Sqs: dial tcp: lookup assertions.ubuntu.com: no such host
[12:55] <popey> hmm, dns issue on that box... odd.
[12:59] <morphis_> ogra_: is it known that the pi3 kernel crashes quite often on edge?
[13:02] <ogra_> morphis_, there is a known oops on boot, if you can capture something please give it to ppisati
[13:02] <ogra_> beyond that my pi is rock solid
[13:03] <morphis_> ogra_: yeah happens always at boot, something with the uart
[13:03] <ogra_> rather withthe wifi
[13:03] <morphis_> will take a picture next time
[13:04] <ogra_> thx
[13:04] <morphis_> ogra_: but it corrupts the whole firstboot so I have to reflash my sdcard
[13:05] <ogra_> yep
[13:05] <ogra_> annoying....
[13:06] <zyga> jdstrand: hey, can you look at https://github.com/snapcore/snap-confine/pull/162/files
[13:06] <mup> PR snap-confine#162: Set PATH unconditionally even if mount namespace is set up <Created by zyga> <https://github.com/snapcore/snap-confine/pull/162>
[13:06] <ogra_> it works with wired networkfor me though
[13:06] <zyga> jdstrand: I'm making a tiny tweak to the test but it's just polish, the semantics is okay as is
[13:11] <jdstrand> zyga: yeah, I am looking at it now
[13:11] <zyga> jdstrand: I need to cook a new release
[13:11] <zyga> jdstrand: so those two are going in for sure
[13:12] <zyga> jdstrand: I also merged this just a moment ago: https://github.com/snapcore/snap-confine/pull/163
[13:12] <mup> PR snap-confine#163: Disable quirks on all-snap systems <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/163>
[13:17] <jdstrand> zyga: does the lxd snap continue to work on all snaps?
[13:20] <zyga> jdstrand: that is irrelevant as the quirk was only meaningful in classic, /var/lib/lxd doesn't exist in the core snap
[13:20] <zyga> jdstrand: AFAIK it never worked there
[13:20] <zyga> but again, this is irrelevant for this reason
[13:21] <jdstrand> zyga: I was thinking perhaps this did work before because this created the /var/lib/lxd directory
[13:21] <zyga> jdstrand: it cannot create that directory
[13:22] <jdstrand> but maybe lxd does that already. idk. seems at least worth testing if it worked before and now doesn't so you could let the lxd guys know the snap will break on all snaps
[13:22] <zyga> jdstrand: on all-snap /var/lib is on the core snap, there's no mount point for /var/lib/lxd
[13:22] <zyga> root@localhost:~# mkdir /var/lib/lxd
[13:22] <zyga> mkdir: cannot create directory ‘/var/lib/lxd’: Read-only file system
[13:22] <jdstrand> well, right, which is partly what the quirk dealt with, no?
[13:23] <zyga> no, the qurik only made the host's version of /var/lib/lxd show up
[13:23] <zyga> if there was one
[13:23] <zyga> but there's no /var/lib/lxd here and the idea of "hostfs" is meaningless
[13:23] <jdstrand> hmm, I guess that's true
[13:24] <ogra_> om26er, while i appreciate https://code.launchpad.net/~om26er/core-snap/improve_build_script/+merge/307640 (a lot actually, my python is usually awful) ... there is sadly no python3 on any of the servers these scripts run on
[13:24] <diddledan> could someone enlighten me as to why my corebird experiment isn't showing up in the unity menu when I've installed it? I'm thinking it might be related to my use of an svg icon(?) otherwise I feel I must have seriously misunderstood the setup of the desktop file
[13:24] <diddledan> https://github.com/diddledan/corebird-snap
[13:24] <om26er> ogra_, oh, fun ;)
[13:24] <ogra_> the datacenter runs mostly on 12.04
[13:25] <om26er> ogra_, no problem, its only a matter of a few months when 12.04 goes EOL and I can resurrect my branch ;) :p
[13:26] <ogra_> heh, well, i can merge it into a lp-build-core-py3 or so
[13:26] <ogra_> so we are future proof
[13:27] <ogra_> morphis_, bug 1627643 btw
[13:27] <mup> Bug #1627643: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New for p-pisati> <https://launchpad.net/bugs/1627643>
[13:38] <morphis_> ogra_: different one here: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1630586/
[13:38] <mup> Bug #1630586: Pi3 kernel crash and is unreliable <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
[13:38] <ogra_> how do you know it is different ?
[13:39] <morphis_> ogra_: it crashes reliable at the same point here
[13:39] <ogra_> same here
[13:39] <morphis_> and there is nothing which relates to wifi
[13:39] <ogra_> and after the crash there is no wlan device setup possible
[13:40] <morphis_> ogra_: actually you can't even get into the device with this crash
[13:40] <ogra_> oh, it hangs hard ?
[13:40] <morphis_> yes
[13:40] <ogra_> then it actually is different
[13:40] <mup> Bug #1630586 opened: Pi3 kernel crash and is unreliable <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
[13:41] <morphis_> ppisati: https://bugs.launchpad.net/snappy/+bug/1630586
[13:41] <mup> Bug #1630586: Pi3 kernel crash and is unreliable <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
[13:41] <ogra_> for me i see the oops pass by but after a while (1-2 min) i get the "please press enter" prompt and can set up the device
[13:41] <ogra_> only with wired though
[13:57] <zyga> jdstrand: 1.0.43 released
[13:57] <zyga> jdstrand, ara: we should get it into yakkety and override the SRU to use it
[13:57] <zyga> it contains two fixes, one is very important and affects xenial
[14:12] <mup> PR snapcraft#852 closed: Simplify the parser tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/852>
[14:17] <cjwatson> ogra_: You should get s390x manifests now.
[14:17] <ogra_> cjwatson, yay, thanks !
[14:17] <morphis_> kyrofa: is this expected that snapd takes authority over the current configuration settings I can set via the config hook?
[14:23] <mup> PR snapd#2100 closed: store: local users download from the anonymous url <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2100>
[14:27] <ogra_> niemeyer, dbarth, so just in time for the meeting i had two WiFi SD cards and an adapter arrive :)
[14:27]  * ogra_ is just unpacking them here
[14:28] <didrocks> sergiusens: hey! I think I found a regression (or case that wasn't tested) in the go plugin with go-importpath
[14:28] <dbarth> ogra_: ah nice
[14:29] <didrocks> sergiusens: source: ., go-importpath: <matching-my-project-import-url>. I see that parts/go/src/<myproject-url> is still the git branch and not the local source
[14:29] <niemeyer> ogra_: Oh, nice
[14:29] <niemeyer> ogra_: Looking forward to the news there!
[14:29] <didrocks> sergiusens: so, local modification aren't reflected, I guess that's a bug and that was the purpose of importpath, correct?
[14:29] <ogra_> i'll report back what works and what doesnt once i had some time to play with them
[14:31]  * ogra_ shakes fist at google
[14:34] <ara> pedronis, I have built the debs with the parameters you mentioned and installed the new .debs, yet snap login cannot find the account that was created in staging
[14:35] <ara> pedronis, (and I have USE_STAGING_STORE=1)
[14:37] <pedronis> ara:  you can turn on debugging with SNAPD_DEBUG_HTTP=1  (only requests) or SNAPD_DEBUG_HTTP=7 (everything)
[14:37] <pedronis> and look at syslog
[14:37] <morphis_> zyga: you got it working already?
[14:37] <ara> pedronis, trying
[14:38] <zyga> morphis_: I fixed two issues in snap-confine, iterating on the problem
[14:38] <zyga> morphis_: (the problem==/media)
[14:39] <zyga> morphis_: I need to rebase it on top and try again, fingers crossed but outlook is positive
[14:39] <morphis_> zyga: ok, you think we need a plan to accommondate you being away starting tomorrow?
[14:40] <morphis_> zyga: if yes, lets bring that up in the team meeting
[14:40] <kyrofa> morphis_, I'm not sure what you're asking about the configuration settings
[14:42] <ara> pedronis, mmm, syslog doesn't give me a lot of info: Oct  5 16:39:01 sushirider /usr/lib/snapd/snapd[7573]: daemon.go:174: DEBUG: uid=0;@ POST /v2/login 1.734880238s 401
[14:42] <ara> pedronis, (for example, whether it is correctly pointing to staging)
[14:42] <pedronis> ara: seems the wway you are turning on those env var is wrong
[14:42] <pedronis> you should get a lot of spam
[14:42] <pedronis> with SNAPD_DEBUG_HTTP
[14:43] <om26er> How do I get pip on all-snaps ?
[14:43] <ogra_> you ue it in snapcraft ;)
[14:43] <ogra_> *use
[14:44] <morphis_> kyrofa: I started to play with it now that my hook is called and saw that the actual configuration state is stored in the snap which seems to be applied again when a new snap revision is installed
[14:44] <morphis_> kyrofa: which conflicts a bit if the snap has other mechanisms to change the same configuration items
[14:45] <morphis_> s/stored in the snap/stored in snapd/
[14:46] <kyrofa> morphis_, how is it applied again when a new revision is installed?
[14:46] <kyrofa> Are you saying the hook is called again?
[14:46] <morphis_> yes
[14:46] <ara> pedronis, I have them set up at /etc/systemd/system/snapd.service.d/local.conf
[14:46] <ara> pedronis, what's the right way?
[14:46] <pedronis> that's one of the ways
[14:47] <pedronis> one sec
[14:47] <morphis_> kyrofa: so "snap install my.snap" gives me a call on the configure hook where I then look into the existing config items via snapctl
[14:47] <morphis_> kyrofa: however those might be already overriden by something inside the snap
[14:48] <pedronis> ara: this what our tests do (just making sure we are on the same page):  http://pastebin.ubuntu.com/23280119/
[14:48] <ara> pedronis, definitely different, thanks for the pointer!
[14:48] <pedronis> replace SNAP_REEXEC=0 with USE_STAGING_STORE=1
[14:48] <kyrofa> morphis_, huh... I only added a hook call when `snap set` is called, I'm not sure why it would be called upon install
[14:49] <pedronis> ara: those conf are overrides, they follow systemd unit syntax
[14:49] <morphis_> kyrofa: so I am wondering who has authoritive over the current state of the configuration, the snap itself or snapd?
[14:49] <pedronis> ara: sorry I wasn't super clear when I mentioned that
[14:49] <om26er> ogra_, won't I be able to just pip install something ?
[14:49] <ara> pedronis, no worries, thanks a lot for the help
[14:49] <kyrofa> morphis_, we wanted it to be held within snapd, otherwise every snap would need some way to store it and respond to queries about it
[14:50] <ogra_> om26er, nope ... and python is not even guaranteed to be on the core snap
[14:50] <morphis_> kyrofa: so how can something inside the snap change the configuration? calling snap set?
[14:50] <ogra_> the only things we guarantee are snapd, systemd and /bin/sh
[14:50] <ogra_> everything else can change at any time
[14:50] <kyrofa> morphis_, admittedly we need a way to ask the snap for its configuration so we can initialize it within snapd
[14:50] <om26er> ogra_, a snap for pip, maybe ?
[14:51] <ogra_> om26er, you can intall the classic snap though .... so you have a "normal" deb env
[14:51] <kyrofa> morphis_, something within the snap can change config via `snapctl set`, and get it with `snapctl get`
[14:51] <ogra_> sudo snap install classic --devmode --edge
[14:51] <ogra_> then: sudo classic
[14:51] <om26er> ogra_, is that persistent now ? I was once told here that it will be wiped on reboot.
[14:51] <ogra_> that gives you a classic shell env
[14:51] <morphis_> kyrofa: you mean snap set or snap get, right?
[14:51] <kyrofa> morphis_, no, snapctl
[14:52] <om26er> I do use classic already in virt-manager
[14:52] <zyga> morphis_: snapctl is not the same as snap
[14:52] <morphis_> kyrofa: as for snapctl you need SNAP_CONTEXT being set
[14:52] <ogra_> it wont be wiped ... but services started in that enmv wont be started
[14:52] <zyga> morphis_: it uses another socket
[14:52] <morphis_> zyga: I know
[14:52] <kyrofa> snap get/set is for a user, it'll cause the hook to be called
[14:52] <kyrofa> morphis_, snap get/set allows one to change settings for all snaps
[14:52] <ogra_> *services installed in
[14:52] <kyrofa> morphis_, snapctl uses a context generated for hooks to determine the snap which is being altered, so snaps can't alter the config of other snaps
[14:53] <morphis_> kyrofa: so where do I get that context from when I want to change the config for my own snap from within an application of that snap?
[14:53] <kyrofa> morphis_, again though, we're missing a little bit of the picture for config, as you've noticed
[14:53] <om26er> ogra_, Whats the footprint you aiming for the core snap ?
[14:53] <morphis_> kyrofa: yeah, but trying to understand what you guys have in mind
[14:54] <ogra_> om26er, aiming for 0 ... :P ... reality is between 60 and 75MB
[14:54] <morphis_> kyrofa: as this conflicts with what we've build for a snap where snap actually has the authority over the configuration data
[14:55] <ppisati> morphis_: what's the kernel version?
[14:55] <kyrofa> morphis_, long-term I imagine we'll have a hook that runs upon install that the snap can use to pre-load snapd with its config
[14:55] <kyrofa> morphis_, or something similar
[14:55] <niemeyer> kyrofa: Not long term, today
[14:55] <kyrofa> niemeyer, we have that today?
[14:55] <morphis_> ppisati: added the kernel snap rev to the bug
[14:56] <niemeyer> kyrofa: Yep ;)
[14:56] <morphis_> niemeyer: how? :-)
[14:56] <kyrofa> niemeyer, ha!
[14:56] <ppisati> morphis_: 4.4.0-1023-raspi2 29 apparently
[14:56] <niemeyer> morphis_: The configure hook is called on every install and every refresh of the snap
[14:56] <morphis_> ppisati: yeah, just verified: 4.4.0-1023-raspi2 #29
[14:56] <niemeyer> morphis_: What exactly are you looking for?
[14:56] <ogra_> thats the current one
[14:56] <kyrofa> niemeyer, even without a configuration?
[14:57] <niemeyer> kyrofa: Right
[14:57] <morphis_> niemeyer: nothing urgent we have to discuss now if you have more important things to do for feature-freeze
[14:57] <kyrofa> morphis_, so upon first install, the snap can just `snapctl set` its config, basically
[14:57] <niemeyer> morphis_: Well, I'd like to clarify these points now, to ensure we don't have confusion on this area
[14:57] <morphis_> niemeyer: just trying to understand how these things are supposed to work as we have a snap which assume it has the authority over its configuration data which slightly conflicts with what snapd does with the config hook
[14:58] <kyrofa> morphis_, the snap still has authority, it just doesn't have the responsibility of storing it all. It can still change configs and veto change requests
[14:58] <niemeyer> morphis_: Every snap can continue to have authority of its configuration, and they don't even have to implement the configure hook
[14:58] <niemeyer> morphis_: snap set will fail if the configure hook is not in place, telling the user that's the case
[14:59] <ogra_> ppisati, perhaps i'm missing something in th config.txt for that image ? http://paste.ubuntu.com/23280174/
[14:59] <morphis_> niemeyer: yeah sure, but having a generic mechanism would make sense
[14:59] <morphis_> to not reinvent the wheel again and again
[14:59] <niemeyer> morphis_: Yes, and we've implemented that generic mechanism..
[14:59] <morphis_> niemeyer: yeah, which is great :-)
[15:00] <morphis_> niemeyer: as said, I don't say its incorrect or wrong, I am just trying to understand how its supposed to work :-)
[15:00] <niemeyer> morphis_: Right now snapctl get/set must be done from within a hook (any hook), but in the near future the snap as a whole will be able to use snapctl anywhere, and adjust its configuration accordingly
[15:01] <morphis_> niemeyer: yeah, that was the point I was missing
[15:01] <niemeyer> morphis_: Every time snap get/set is done, the configure hook is called again, and has a chance to adjust its configuration in any way it wants, and it may also reject the configuration proposed
[15:01] <om26er> ogra_, on another question, can I assume that installation of an all-snap Ubuntu Personal (read: desktop) would technically be even faster than it is today ? Just dump of the image on the partition and account setup ?
[15:02] <ogra_> om26er, well, it'd be closer to a phone or the M10 tablet we have today ... but yeah, dump it to disk and a (graphical) first-setup too runs
[15:03] <ogra_> *too
[15:03] <ogra_> pfft
[15:03] <morphis_> niemeyer: with the sync mechanism via snapctl set it makes more sense as then I can tell snapd when something else has changed the configuration item
[15:03] <ogra_> *tool
[15:03] <niemeyer> morphis_: The configure hook is called with the _whole_ configuration, not just the requested changes
[15:03] <niemeyer> morphis_: Yes, that's what the earlier point addresses
[15:04] <niemeyer> This, specifically:
[15:04] <niemeyer> 12:00:34 <niemeyer> morphis_: Right now snapctl get/set must be done from within a hook (any hook), but in the near future the snap as a whole will be able to use snapctl anywhere, and adjust its configuration accordingly
[15:04] <morphis_> niemeyer: what you mean with the whole configuration? I have to do a snapctl get call to get specific items in my configure hook implementation
[15:04] <niemeyer> morphis_: That's right.. I just mean the whole configuration is at hand
[15:04] <morphis_> ah
[15:05] <niemeyer> morphis_: Not just the delta that was requested via snap set
[15:06] <morphis_> niemeyer: what about the changes stored in the snapd transaction database, when I revert to an earlier revision of a snap are all configuration changes reverted back to that revision as well?
[15:06] <niemeyer> morphis_: Not yet, but I'm planning to fix that for the RC
[15:07] <niemeyer> Have a good idea for how to do that in a simple way already
[15:07] <om26er> Whats the speed difference of reading a file from ext4 and reading from a squashfs based snap(do we use compression of some sort?) place on ext4, have we measured that ?
[15:09] <elopio> sergiusens: kyrofa: does this make sense? https://github.com/elopio/QGIS/blob/snapcraft/snapcraft.yaml#L66
[15:09] <elopio> I had to move the stage packages to a different part, because otherwise it wouldn't find them during build.
[15:10] <kyrofa> elopio, so it only looks in stage, eh?
[15:10] <kyrofa> elopio, although you don't use `after` it seems?
[15:10] <kyrofa> elopio, oh nevermind, I'm blind
[15:11] <kyrofa> elopio, how does qgis find deps? cmake modules? pkg-config?
[15:11] <kyrofa> elopio, those deps, specifically
[15:11] <elopio> lots of cmake find modules
[15:12] <kyrofa> elopio, let me take a look, hold on
[15:12] <ogra_> morphis_, does your pi image with the oops actually use an unmodified config.txt ? i wonder if we are missing something there, the default is http://paste.ubuntu.com/23280174/
[15:13] <elopio> thanks
[15:13] <morphis_> niemeyer: sounds good
[15:13] <morphis_> ogra_: its the default one
[15:14] <morphis_> ogra_: that what comes via ubuntu-image/snap prepare-image
[15:14] <ogra_> ok ... well, i wonder i ppisati might find some missing option regarding the uart there
[15:14] <ogra_> morphis_, right, straight from the gadget snap
[15:14] <ppisati> ogra_: i'm flasging an image that i just preapared
[15:14] <ogra_> oki
[15:15] <elopio> ralsina: I think I removed the coverage checks on integration and snaps tests. But it makes sense to check the coverage of unit tests. If a line is not executed, it's very likely that it should be removed, don't you think?
[15:15] <ppisati> using the model posted in lp1630586
[15:15] <ppisati> let's see
[15:15] <mup> PR snapcraft#853 opened: Simplify the handler from uri tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/853>
[15:15] <ralsina> elopio: could be. I was just a it frustrated about being -0.006% but then I removed an unused line ;-)
[15:16] <elopio> ralsina: anyway, we don't really pay a lot of attention to those numbers, because coveralls is know to be bad at math. We only care when there's a clear missing test.
[15:16] <ralsina> elopio: cool with me :-)
[15:17] <ogra_> morphis_, woah, reading your syslog in bug 1630586 i see a lot of errors i dont see on any standard image ... specifically the squashfs errors are interesting
[15:18] <mup> Bug #1630586: Pi3 kernel crash and is unreliable <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1630586>
[15:20] <morphis_> ogra_: yeah possible that those come after the first boot or so
[15:20] <ogra_> hmm, actually i havent ooked into my syslog of the running pi3 here for a while ... i got the same here
[15:20] <ogra_> this is worrying
[15:21] <ogra_> mvo, ^^^^ did anything regarding squashfs change recently in snapd ?
[15:21] <ogra_> mvo, http://paste.ubuntu.com/23280252/
[15:22] <ogra_> and thre are a lot more errors
[15:24] <SuperJonotron> Trying to figure out the correct way to setup the environment variables for my snap to access the writable sections.  I know I can hard code the "current" version of the snap install but it seems like this should be the version number
[15:24] <SuperJonotron> not sure how to dynamically grab the version number when the snap launches
[15:24] <mvo> ogra_: auto-probe magic for assertion
[15:24] <mvo> ogra_: harmless
[15:24] <mvo> ogra_: but noisy:/
[15:24] <ogra_> phew !
[15:25] <ogra_> that had me shocked for a moment
[15:26] <kyrofa> SuperJonotron, have you seen this? https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
[15:27] <SuperJonotron> I have seen that but I was unclear on whether or not just accessing those variables alone would do the trick or if they needed to be initialized
[15:28] <kyrofa> SuperJonotron, just accessing them should be enough
[15:29] <SuperJonotron> I'll give that a shot.  I also have to figure out how the snap can generate a configuration file within it's read only folder where it's packaged or reference it's creation in the SNAP_DATA folder
[15:29] <SuperJonotron> is this possible with say a symbolic link?
[15:29] <morphis_> mvo: auto-probe magic for assertions? are they stored in squashfs?
[15:29] <ogra_> likely in /writable
[15:30] <ogra_> but the squashfses are matched against them i guess
[15:32] <kyrofa> elopio, hmm... this isn't just using cmake, it actually shells out to python scripts as well
[15:32] <kyrofa> elopio, you might need to set those variables for the build
[15:32] <elopio> kyrofa: but I think I'm misunderstanding stage packages. Shouldn't they be in the stage dir, before the part builds?
[15:33] <kyrofa> elopio, no, they're in the part's installdir
[15:33] <kyrofa> elopio, and they get migrated along with the rest of the part to stage
[15:33] <elopio> kyrofa: and they get to the installdir, before the part builds?
[15:34] <kyrofa> elopio, indeed
[15:34] <elopio> kyrofa: so, shouldn't the installdir be added to the paths, just like the stage dir?
[15:34] <mvo> morphis_: the code will probe any block device
[15:34] <morphis_> mvo: ah
[15:35] <kyrofa> elopio, yeah, that's what I mean to say. The find modules will need a PYTHONPATH looking in the installdir in order to find anything, it seems
[15:35] <kyrofa> elopio, but I'm a bit surprised this works with the stagedir, honestly
[15:36] <kyrofa> elopio, are you sure pyqt5-dev actually needs to be staged?
[15:36] <elopio> kyrofa: well, I meant that it should work magically using installdir, like it does with stage dir ^_^
[15:37] <kyrofa> elopio, haha, I agree! It just means we need to figure out the magic first :P
[15:37] <elopio> kyrofa: as a build package, it doesn't find it.
[15:37] <kyrofa> elopio, huh, that's interesting
[15:37] <elopio> and qgis does some weird things on loading, with python. So I think it's also needed in the final package. But I'm not totally sure.
[15:37] <kyrofa> Yeah, whenever I see -dev packages in stage-packages, I know something is off
[15:37] <kyrofa> Hmm
[15:53] <mup> Bug #1630652 opened: snap revert and refresh forwards and backwards causes breakage <Snappy:New for chipaca> <https://launchpad.net/bugs/1630652>
[16:02] <ppisati> ogra_: did you try to generate a pi3 image?
[16:03] <ogra_> ppisati, ?
[16:03] <ogra_> my scripts do that every day, why ?
[16:03] <ppisati> ogra_: i'm referring to morphis_ bug
[16:03] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
[16:04] <ppisati> ogra_: and does your image have that stack trace on boot?
[16:04]  * ppisati tries without the eth cable
[16:04] <ogra_> ppisati, it used to last week ... i havent freshly installed since
[16:04] <ogra_> but nothing changed afaik ... so it should still have it
[16:05] <ppisati> ogra_: ok, me tries without the eth cable and then tries your image
[16:08] <SuperJonotron> I have an application wrapped up in a snap and running but I know it lacks a license to operate fully and the application will want to write this license into a folder within the application structure (the read only section).  I have no control over changing this behavior and need to know how to give this folder writable access when it needs to update and/or create the license file
[16:09] <ara> pedronis, OK, it looks now that it takes those env variables into account, as i am getting a lot more debug messages
[16:09] <kyrofa> SuperJonotron, you can't tell it where to write with a cli parameter or anything?
[16:09] <ara> pedronis, but it looks like it still tries to connect to login.ubuntu.com (instead of loging.staging.ubuntu.com)
[16:10] <SuperJonotron> kyrofa, I am porting a piece of existing software into the ubuntu snappy os and so I have limitations on what is exposed.  I do have direct contact with the manufacturer so I can double check what I am allowed to do but as of right now, I have not found a way to overwrite this method.  What would you suggest a solution be to overwrite the apps behavior to write into the snap environment?
[16:11] <ara> pedronis, Oct  5 18:10:23 sushirider /usr/lib/snapd/snapd[21445]: logger.go:66: DEBUG: > "POST /api/v2/tokens/discharge HTTP/1.1\r\nHost: login.ubuntu.com\[...]
[16:11] <SuperJonotron> kyrofa, I would also imagine I would need to create a link to the file back into the application where it expects it to be?
[16:11] <kyrofa> SuperJonotron, that means the application could never be installed into e.g. /usr/local/bin either, since it's owned as root
[16:12] <kyrofa> SuperJonotron, if the app requires where it is to be writable, then really your only option is to copy the entire thing into writable space
[16:12] <kyrofa> And run from there
[16:12] <kyrofa> SuperJonotron, but that's kinda terrible
[16:13] <SuperJonotron> what about just the licensing section and create a link back to the file?
[16:13] <SuperJonotron> is that allowed or will the read only status block a link being made?
[16:13] <kyrofa> SuperJonotron, you can't write in $SNAP, plain and simple. No files, no links
[16:15] <mup> PR snapd#2101 opened: image: support gadget specific cloud.conf file <Created by mvo5> <https://github.com/snapcore/snapd/pull/2101>
[16:15] <SuperJonotron> kyrofa, thanks, I'll see if I can work with the manufacturer to overwrite the default licensing folder to reference one of the writable snap locations
[16:17] <kyrofa> SuperJonotron, yeah, I'd ask for either a CLI parameter or support for an environment variable
[16:23] <elopio> davidcalle: ping. Did you find the mapbox contact?
[16:26] <morphis_> zyga: what's the state now?
[16:28] <morphis_> zyga: can you drop me a mail before you leave tomorrow on where you leave this and what the next steps are?
[16:36] <elopio> kyrofa: synapse working \o/ https://gist.github.com/elopio/dffcda326f5b51feedeb09f012ac9a44
[16:43] <zyga> morphis_: yes, sure
[16:44] <ogra_> jdstrand, so mvo said core should auto-land in the store now ?
[16:44] <zyga> morphis_: still working on it, testing is slow
[16:45] <ogra_> jdstrand, i.e. i can enable the cron build now ?
[16:48] <pedronis> ara: it's my fault, the env var is SNAPPY_USE_STAGING_STORE=1
[16:48] <pedronis> ara: I totally went by memory, and it seems my brain has dropped the prefix
[16:48] <zyga> jdstrand: hey, I need your review on this https://github.com/zyga/snapd/pull/2/files
[16:48] <mup> PR zyga/snapd#2: Make sure gpio exported before apparmor setup <Created by jocave> <https://github.com/zyga/snapd/pull/2>
[16:49] <zyga> jdstrand: joc figured out how to solve the gpio issue but it requires that the permanent slot snippet exports the gpio to userspace
[16:49] <zyga> jdstrand: so by the time apparmor snippet needs to be comoputed the gpio directory already exists and we can run realpath on it (dereference all the symlinks)
[16:49] <zyga> jdstrand: I think that's okay but I wante to check with you first
[16:50] <zyga> joc: ^^
[16:50] <zyga> joc: good work and good thinking :) (unless jdstrand disagrees) I didn't think about it
[16:50] <zyga> s/about it/of it/
[16:50] <ogra_> these wifiSD cards are fun !
[16:51] <zyga> ogra_: do they work?
[16:51] <zyga> ogra_: tell me which you got,
[16:51] <zyga> I'll drop some to amazon inbox
[16:51] <joc> zyga: thanks, lets see what jamie says!
[16:51] <ogra_> zyga, well, i have to solder a serial port on ... seems the documented hacker backdoors hhave been fixed (some of them at least)
[16:52] <ogra_> but i guess we can actually use them for flashing the pi's for testing images
[16:52] <ogra_> they come with a very tiny linux
[16:52] <ogra_> and AP mode ...
[16:52] <ogra_> i guess i can hack the initrd on them to give us a flashsher tool
[16:53] <ogra_> zyga, transcend seems to be hackeble pretty well ...
[16:53] <zyga> ogra_: OMG :D
[16:53] <ogra_> i got a toshiba one as well, but that doesnt seem to run linux :/
[16:54] <zyga> ogra_: can you share the link to the product you think is woth getting
[16:56] <ogra_> zyga, https://www.amazon.de/dp/B010MQ13E8 ... i didnt get the transcend one from amazon though
[16:56] <ogra_> they only have the flashair toshiba one in germany atm
[16:56] <ogra_> or eyefi ...
[16:56] <ogra_> but afaik both arent easily hackeable
[16:56] <zyga> joc: please add that comment and I'll merge it into my branch
[16:56] <zyga> joc: this will update the pull requast
[16:56] <zyga> *request
[16:56] <zyga> the main one
[16:57] <zyga> joc: and if jdstrand gives it a +1 we'll be good to go
[16:59] <mup> PR snapd#2093 closed: cmd/snap,ctlcmd: fix behavior of snap(ctl) get <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2093>
[16:59] <zyga> ogra_: thanks, it is even cheaper on amazon.es
[17:00] <ogra_> heh
[17:02]  * zyga -> afk
[17:02] <zyga> I'll be back later, I need to rest
[17:03] <mup> PR snapcraft#853 closed: Simplify the handler from uri tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/853>
[17:09] <mup> PR snapd#2101 closed: image: support gadget specific cloud.conf file <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2101>
[17:11] <mup> PR snapd#2098 closed: store: retry store operations (WIP) <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2098>
[17:31] <jdstrand> ogra_: yes
[17:32] <ogra_> ok, let me try that ... you will have to approve each single one if you lied ;)
[17:33] <mup> Bug #1630690 opened: A snap with git fails because it can't access /etc/mailname <Snappy:New> <https://launchpad.net/bugs/1630690>
[17:49] <morphis_> zyga: aye
[17:51] <morphis_> zyga: please just drop me a note per mail where you leave this
[17:59] <ogra_> jdstrand, GOSH ! ... IT WORKS !
[17:59] <ogra_> :)
[18:00] <ogra_> http://people.canonical.com/~ogra/core-builds/ ...
[18:00] <ogra_> :)
[18:03] <rharper> hi, looking for any docs on creating assertions, like account and account-id;  I want to test out creating assertions, signing them and acking them;  I see various assertions in the snapd source but not sure of the required key and inputs
[18:07] <jdstrand> ogra_: yay :)
[18:09] <om26er> I cannot set password on all-snap image on RPi, it gives me:
[18:09] <om26er> om26er@localhost:~$ sudo passwd
[18:09] <om26er> passwd: Authentication token manipulation error
[18:09] <om26er> passwd: password unchanged
[18:10] <sergiusens> om26er shouldn't it be `sudo passwd $USER` ?
[18:10] <om26er> sergiusens, my bad, it worked that way.
[18:11] <om26er> I am actually used to digitalocean droplets where I am root and `passwd` just works
[18:27] <om26er> I have a new project https://github.com/om26er/pigpio, its specifically for the RPi but I haven't been able to find a way to build armhf snap. The only piece I found is https://developer.ubuntu.com/en/snappy/guides/cross-build/
[18:27] <om26er> which doesn't help much as there is no mention of snapcraft in that. Whats the recommended way to build armhf snaps ?
[18:27] <om26er> oh, btw upload to snap store was instant, much faster than I had expected.
[18:29] <om26er> brb
[18:38] <mup> PR snapd#2102 opened: cmd/snap: rename is-managed to managed and tune <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2102>
[18:47] <mup> PR snapd#2097 closed: snap: add `snap is-managed` for console-conf <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2097>
[18:48] <SuperJonotron> Is there a system variable when running a snap for the current version folder and/or the latest version number?  http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data mentions where to find the writable directories but can't seem to find where the app install directory is defined as a variable
[19:21] <cjwatson> om26er: You can build armhf snaps on Launchpad
[19:22] <om26er> cjwatson, do I need to register my project on launchpad for that ?
[19:22] <cjwatson> om26er: Yes.  Import the repository to a Launchpad branch (either push the same git repository manually to LP, or cross your fingers and do a git->bzr import, or wait for us to finish git-to-git imports), then you can create a snap package from the LP UI
[19:23] <cjwatson> om26er: We'll be automating this further in future
[19:23] <cjwatson> I think the guide you found is how to cross-build snapd itself, and it's out of date anyway ...
[19:24] <cjwatson> (refers to cmd/snappy, which isn't a thing any more)
[19:25] <om26er> cjwatson, ok, I will try that now.
[19:25] <om26er> cjwatson, is there a change in future when git becomes the primary version control for Launchpad ?
[19:25] <cjwatson> om26er: what would "primary" mean, in your opinion?
[19:26] <cjwatson> om26er: I mean, in what particular sense is it not that would be changed by being primary
[19:27] <om26er> cjwatson, launchpad code currently rings a be of bzr in my head, while we do have git support, most docs that we see around only refer to bzr.
[19:27] <cjwatson> om26er: there are probably a bunch of docs to update spread all over the place, it's a pretty Sisyphean task
[19:27] <cjwatson> om26er: many of them not maintained by us either
[19:28] <cjwatson> om26er: our git hosting is lacking maybe about two or three substantial features compared to our bzr hosting, but it's definitely the way forward
[19:29] <cjwatson> (imports, more useful subscriptions, direct translation commits)
[19:29] <om26er> cjwatson, ok, good to know.
[19:30] <cjwatson> om26er: shifting ten years of perception is going to take a while no matter what way you slice it though
[19:32] <mup> PR snapd#2095 closed: snapstate: fix hanging `snap remove` if a try mount dir is no longer mounted <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2095>
[19:37] <mup> PR snapcraft#851 closed: catkin plugin: nicely handle an invalid rosdistro <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/851>
[19:47] <kyrofa> Hey jdstrand, I lost track of the seccomp arg filtering, particularly relating to setpriority. Is that stuff still waiting to land?
[19:50] <jdstrand> kyrofa: the feature landed. the policy to use it has not. it was deprioritized in favor of a bunch of rtm interfaces and now other rtm/ga stuff. once that stuff is done, I'm back to dbus-app PR and after that, these seccomp arg policy
[19:51] <jdstrand> policies
[19:51] <kyrofa> jdstrand, sounds good, thanks for the update!
[19:51] <jdstrand> np
[20:04] <om26er> snap install gives me 401 on all-snap.
[20:04] <om26er> something broken in the image or server side ?
[20:09] <om26er> om26er@localhost:~$ sudo snap install classic --devmode --edge
[20:09] <om26er> error: cannot perform the following tasks:
[20:09] <om26er> - Download snap "classic" (17) from channel "edge" (received an unexpected http response code (401) when trying to download https://public.apps.ubuntu.com/download-snap/QbSFwGGAgvG8zHl9nWLY7vEee8lhgFsp_17.snap)
[20:11] <mwhudson> morning
[20:15] <lool> kyrofa: I sense you're about to snap cartografer for ROS!  http://opensource.googleblog.com/2016/10/introducing-cartographer.html   :-)
[20:20] <lool> damn, the laser seems to be 1000 USD
[20:23] <lool> there are some 150 USD ones, unidirectional though
[20:30] <kyrofa> lool, haha, awesome
[20:32] <kyrofa> lool, yeah, stereo SLAM is usually cheaper
[20:32] <kyrofa> optical, I mean
[20:33] <lool> kyrofa: I wonder if we could do the same kind of mapping with just a sonic depth sensor
[20:33] <lool> kyrofa: there is one on the slam dunk
[20:34] <lool> NB: running ubuntu and ROS :-D
[20:34] <kyrofa> lool, sonic sensors don't typically have great range though-- do you know what that one is?
[20:35] <lool> kyrofa: I'm afraid not, but you're right, it was in range at about 1m and out of range at <0.5 and >2m
[20:35] <lool> it was more for collisions
[20:35] <kyrofa> Yeah that's a typical use-case
[20:36] <kyrofa> And for some platforms, it might be enough for mapping (i.e. small and slow-moving)
[20:36] <kyrofa> Resolution wouldn't be great
[20:37] <rharper> mwhudson: hey;  I playing with snap ack and assertions, and I can't seem to construct anything that snap will actually ack;  I looked at the json input you used for system-user; but was hoping to have an account and account-id one so I can test out acking multiple assertions ;  any pointers to the right json format for account-id or such ?
[20:38] <mwhudson> rharper: you need a model where you are the authority, do you have that bit set up?
[20:38] <lool> kyrofa: did you manage to move our ros support to indigo before roscon?  :)
[20:38] <mwhudson> there is a google doc with instructions for that, let me dig it up
[20:38] <kyrofa> lool, indigo has been supported for ever. I'm assuming you mean kinetic? Yessir!
[20:38] <lool> err sorry kinetic
[20:39] <kyrofa> lool, yeah, just landed in 2.19
[20:39] <lool> nice!
[20:39] <mwhudson> rharper: https://docs.google.com/document/d/1cJvRnpoQyLvY6pOLFPgUxMHrFVBCDNwAlrORARBiZlU/edit
[20:40] <mwhudson> hm that doc could/should probably be updated to include the unattended user creation flow
[20:41] <rharper> mwhudson: yeah, I've followed that but I didn't build a new image;  I wanted to just ack the system-user (or in my case an account-id ) assertion
[20:42] <rharper> mwhudson: but I think you're suggesting that I have to boot into an image with my own model assertion enabled
[20:42] <mwhudson> rharper: i don't know about account-id assertions, but for system-user the authority has to be the brand, so you need an image where you can sign for the brand
[20:42] <mwhudson> presumably there is/will be some way to sign system-user assertions for the canonical brand but i certainly don't know what that is
[20:42] <rharper> mwhudson: right;  I'm hoping to test importing any type of assertion via the cloud-init user-data; so I was hoping to have *some* valid assertions that snap could actually ack
[20:42] <mwhudson> rharper: ahh
[20:43] <rharper> and right now I've got zero
[20:43] <rharper> so that makes testing a bit hard
[20:43] <mwhudson> rharper: use snap download to download a snap, this also downloads assertions
[20:44] <mwhudson> $ snap download hello
[20:44] <rharper> ok
[20:44] <mwhudson> $ ls hello_20.snap*
[20:44] <mwhudson> hello_20.snap  hello_20.snap.assertions
[20:44] <rharper> indeed
[20:44] <mwhudson> i assume snap will ack hello_20.snap.assertions ?
[20:44] <mwhudson> haven't tried but seems likely
[20:44] <rharper> yay
[20:44] <rharper> % sudo snap ack hello_20.snap.assertions
[20:44] <rharper> error: cannot assert: cannot decode request body into an assertion: assertion body length and declared body-length don't match: 3494 != 717
[20:44] <rharper> I've been seeing that a lot key body not matching
[20:44] <rharper> so maybe I did get one right
[20:45] <rharper> hard to tell
[20:45] <mwhudson> uhhh
[20:45] <mwhudson> now i guess you need someone who knows what they are talking about i guess :)
[20:46] <rharper> I'm one step further, so many thanks for your help
[20:46] <mwhudson> snap (on my desktop) seems happy with that file
[20:46] <rharper> lemme try on a fresh system
[20:46] <rharper> who knows what I've got on my laptop
[20:49] <caio1982> rharper, mwhudson: i am not very familiar with ack and dunno if it's a bug or by design but the assertions file download fetches contains *multiple* assertions and ack parses a single one, so you need to split it into (currently) 3: account-key, declaration and revision, then ack will work for each one of them
[20:49] <caio1982> that explains the body-length mismatch above
[20:49] <mwhudson> i really thought snap ack was supposed to handle that
[20:50] <caio1982> me too
[20:50] <mwhudson> but that would explain the problem indeed
[20:50] <caio1982> but as i said, i dont even use ack right now so i dont know if it's on purpose
[20:58] <rharper> caio1982: mwhudson: yes I think that's a bug;  I've been told to put multiple assertions into a single file
[20:59] <rharper> the assert.Decode() code comments suggests it's similar to a multi-part MIME format, with new lines separating portions
[20:59] <rharper> so certainly feels like a bug
[21:00] <caio1982> i would certainly subscribe to it if it was filed ;-)
[21:00] <rharper> fwiw, the 717 is the right size for the public-key
[21:01] <lool> rharper: hey have you by any chance latest email from MikeB on the devices list? he brings up a bunch of cloud-init start time questions, would you think we could extract some cloud-init runtimes from his system?
[21:01] <lool> run times, not runtimes sorry
[21:01] <rharper> lool: do we know if the image has the cache purged or not ?
[21:01] <lool> rharper: I do not
[21:02] <mup> PR snapd#2090 closed: interfaces,overlord/ifacestate: initial cleaning up of no arg AutoConnect related bits <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2090>
[21:02] <rharper> the python cache stuff that was discussed on the console-conf thread
[21:02] <lool> rharper: https://lists.snapcraft.io/archives/devices/2016-October/000082.html
[21:03] <lool> rharper: oh the missing cache creates performance issues?
[21:03] <lool> rharper: that might be it, but I'd be surprized it'd be that bad; these switches are supposed to be x86-64, typically some GHz and SSD storage
[21:03] <lool> the processing power is not crazy, it's more like a laptop configuration
[21:04] <rharper> it's not that bad on x86;  it's more likely something to do with the cloud-config
[21:04] <lool> Yes, I figured it would be more like timeouts
[21:04] <lool> he mentions an instance-data http connection
[21:04] <lool> you know, the AWS stuff
[21:04] <rharper> and which cloud-init;  the version in yakkety until yesterday or so had issues with DNS due to ordering around systemd's dbus socket
[21:04] <lool> that seemed weird
[21:04] <rharper> right, if those show up, very likely that the no-cloud seed was never embedded
[21:04] <lool> rharper: how about I ask these questions and Cc: you on it?
[21:04] <rharper> sure
[21:05] <lool> rharper: I guess you're not on the devices@ list
[21:05] <rharper> I am
[21:05] <rharper> I can reply
[21:05] <lool> thanks, that'd be great
[21:05] <rharper> and if you know how to create account-id or account assertions and be able to ack them; that'd help me work cloud-init importing snap assertions   (or point me to who does know)
[21:06] <lool> rharper: I wish I knew!  :-)
[21:06] <lool> rharper: let me check the snap login code
[21:08] <lool> rharper: at least I can point at sample data for it; check snapd/tests/main/ack/alice.account
[21:08] <rharper> heh
[21:09] <rharper> yeah, I'm looking for the json format for account-id or account, so I can pipe that through snap sign, and then snap ack the output of sign
[21:09] <mup> PR snapd#2103 opened: store: send correct JSON type of string for expected payment amount <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2103>
[21:12] <mup> PR snapd#2102 closed: cmd/snap: rename is-managed to managed and tune <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2102>
[21:15] <lool> rharper: so to dump account assertions of a system, snap known account; you can import with snap ack
[21:16] <lool> rharper: but I guess you wanted to create the contents from scratch?
[21:18] <rharper> that might be good enough
[21:25] <tyhicks> jdstrand, zyga: I'm trying to decide if a bug I'm seeing while running a snap inside a lxd container is caused by the container environment or possibly by snap-confine mount oddness - have you seen anything like this before? https://paste.ubuntu.com/23281705/
[21:34] <mup> PR snapcraft#854 opened: Decouple state handling from plugin options <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/854>
[21:48] <jdstrand> tyhicks: never seen that
[21:49] <jdstrand> tyhicks: but I've not tried running snaps in a container yet
[21:49] <jdstrand> getting there
[21:51] <tyhicks> jdstrand: no problem, I'm fairly confident that it is a container issue
[21:52] <mup> PR snapcraft#855 opened: tools: script to talk to the staging servers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/855>
[22:01] <zyga> tyhicks: looking
[22:02] <zyga> tyhicks: interesting
[22:02] <zyga> tyhicks: is 'd????????? ? ?    ?       ?            ? 27
[22:02] <zyga> tyhicks: is that caused by stat failure?
[22:02] <zyga> do you get any apparmor denials?
[22:03] <zyga> tyhicks: to answer, I haven't seen anything like this
[22:04] <tyhicks> zyga: that's what happens when a dentry in the kernel doesn't have a corresponding inode (negative dentry)
[22:04] <tyhicks> zyga: I'm not sure if there are other situations where that output is display
[22:04] <tyhicks> displayed*
[22:04] <zyga> tyhicks: oh
[22:04] <tyhicks> zyga: there are no apparmor denials
[22:04] <zyga> tyhicks: I did see sooome of that
[22:04] <rharper> caio1982: mwhudson: snapd 2.16  in xenial-proposed will snap ack the hello.snap.assertion just fine
[22:04] <zyga> tyhicks: can you cat mountinfo please?
[22:04] <zyga> tyhicks: does it contain "deleted" anywhere?
[22:05] <tyhicks> zyga: no "deleted" in mountinfo
[22:05] <zyga> tyhicks: I'm sure you know but there are a few pending pull requests on snap confine up
[22:06] <rharper> as well as the 'snap known account' output as well ; cool
[22:06] <zyga> tyhicks: it looks all sane?
[22:06] <zyga> tyhicks: and they relate to lxd
[22:06] <tyhicks> zyga: it does look sane
[22:06] <tyhicks> zyga: hmmm
[22:06] <tyhicks> zyga: btw, this is a yakkety environment with snapd from yakkety-proposed
[22:07] <tyhicks> zyga: thanks for your help, I'll file a bug and get some more eyes on the report
[22:09] <zyga> tyhicks: please do, I'll try to look at it when I can
[22:09] <zyga> I'm off next week though
[22:09] <zyga> and tomorrow/day after I'm flying
[22:09] <zyga> and then roscon
[22:09] <mup> PR snapd#2104 opened: debian, tests: enable spread tests on trusty <Created by vosst> <Conflict> <https://github.com/snapcore/snapd/pull/2104>
[22:13] <tyhicks> stgraber: are there still any pending snapd/snap-confine changes (outside of snapd from yakkety-proposed) needed for bug #1611078? I see that you have fix-committed for the Snappy task but I'm not sure what that represents
[22:13] <mup> Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <Snappy:Fix Committed by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
[22:14] <tyhicks> stgraber: I'm having trouble running snap commands as a normal user inside a container
[22:15] <pedronis> rharper: yes, we changed snap ack to take streams of assertions only in 2.16
[22:25] <mup> PR snapcraft#856 opened: Call organize() after building <Created by josepht> <https://github.com/snapcore/snapcraft/pull/856>
[22:28] <mup> Bug #1630789 opened: normal users can't run snaps inside of LXD containers <Snappy:New> <https://launchpad.net/bugs/1630789>
[23:03] <mwhudson> rharper: ah ok, good to hear


[05:46] <TiMiDo> is there any way i can have access to a certain translation team since i am active on launchpad?
[06:55] <sagaci> TiMiDo, yep, just go to your homepage in launchpad and on the left hand side down the bottom there's a section Latest Memberships, where you can click on All Memberships
[06:56] <TiMiDo> thank you sagaci


[00:50] <teward> guiverc: oh hello.  I'm testing the tor-browser launcher in my new Impish VM.  I'm going to spin tor browser via the CLI to pull stderr in :P
[00:51] <guiverc> :) thanks teward
[00:53] <teward> guiverc: E:NOREPO
[00:53] <teward> E:NOREPRO *
[00:54] <teward> fresh IMpish VM, fresh torbrowser-launcher run/install
[00:54] <teward> execution seemed to work fine
[00:54] <teward> how'd you execute after torbrowser-launcher installed it?
[00:54] <teward> (FYI torbrowser-launcher only handles the download and extraction of Tor Browser, it does NOT actually contain the tor-browser code)
[00:54] <guiverc> maybe i filed on wrong package - its the execution of the browser I have issues with
[00:54] <teward> (so any issues actually in Tor Browser *itself* (i.e. a crash in the tor browser binaries) is actually an upstream Tor issue and not a torbrowser-launcher issue - I know 'cause i've dug deep.)
[00:55] <teward> guiverc: then that's an Upstream Tor Problem
[00:55] <teward> guiverc: load up your terminal, run `find $HOME -iname '*start-tor-browser*'
[00:55] <teward> find the binary (NOT the desktop files!)
[00:56] <teward> execute the full binary path on the command line, pull any stdout
[00:56] <teward> or stderr
[00:56] <teward> see what *actually* happens behind the scenes
[00:56] <teward> (and again, I'm fairly fluent now in how the torbrowser-launcher scripts work 'cause I had SRU'd some major patches for it)
[00:57]  * guiverc will look in a few mins, after I complete a askubu comment
[01:01] <teward> guiverc: also run torbrowser-launcher on your command line if you want to, get that stderror as well
[01:01] <teward> that way we can actually see any useful error output
[01:01] <teward> though I think it's all Python o.O
[01:03] <teward> yeah to start Tor Browser, it calls a subprocess.call in Python so if it's not starting it's a Tor Upstream problem, but it might be localized to your environment because E:NOREPRO on a fresh Impish VM of Ubuntu (NOT lubuntu, but actual Ubuntu)
[01:03] <guiverc> my primary box has multiple DEs so I'd expect it to work here (GNOME/Ubuntu being one of them)
[01:04] <teward> guiverc: still why i asked :P
[01:06] <guiverc> comment made teward https://bugs.launchpad.net/ubuntu/+source/torbrowser-launcher/+bug/1933886/comments/4
[01:10] <teward> guiverc: `$HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/firefox --class "Tor Browser" -profile $HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser'profile.default "http://cnn.com" 2>*1 </dev/null`
[01:10] <teward> i know that's long
[01:10] <teward> but that's what the start-tor-browser stuff does except disowns by default
[01:10] <teward> so it won't include the stderr and stuff
[01:10] <teward> foo i mistyped
[01:11] <teward> guiverc: `$HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/firefox --class "Tor Browser" -profile $HOME/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser'profile.default "http://cnn.com"`
[01:11] <teward> there
[01:11] <teward> sorry to keep debugging :P
[01:11] <teward> but yeah I can't reproduce this on a fresh Impish
[01:12] <teward> so if this issue exists, unless someone else can reproduce it, I'm going to say "Something on your end is fubar"
[01:12] <teward> :)
[01:13] <guiverc> I'll zsync my ubuntu (impish) ISO & test there.. if it works there, but fails still on lubuntu - the issue maybe related to something in lubuntu & thus not upstream, but a lubuntu config issue maybe
[01:13] <teward> and then something i'll hunt
[01:13] <teward> but if it works fine in an Lubuntu environment then, then I have to start saying "It's a you problem"  ;P
[01:14] <guiverc> I think I see that as a "we" problem... you're lubuntu too :)
[01:14] <guiverc> when you change hats that is :)
[01:14] <teward> guiverc: true. but i don't have an lubuntu test env up yet
[01:14] <teward> ERR: ZSync Asploded
[01:15] <guiverc> thanks teward , appreciated
[01:16] <teward> ywp
[01:31] <teward> guiverc: prodded in #lubuntu-devel because Lubuntu confirmed failed
[01:31] <teward> but it's a segfault
[01:31] <teward> at the browser level so
[01:33]  * guiverc doesn't understand much of what you're saying.. I'm not at your level - but away in askubu as is common
[01:34] <teward> guiverc: basically: software crashes hard
[01:34] <guiverc> the package itself does install & runs correctly.. it even downloads & installs the later version then abends when it tries to run as I see it
[01:34] <teward> guiverc: it's not a problem at the torbrowser-launcher package
[01:34] <teward> it downloads the software
[01:34] <guiverc> (abend - abnormal end; I'm an ex-s390 coder)
[01:34] <teward> and runs it
[01:35] <teward> but the underlying Firefox executable it run segfaults
[01:35] <teward> and hard crashes
[01:35] <teward> i'm going to send to the tor browser UPSTREAM team at Tor to see if they've seen this
[01:36] <guiverc> thanks teward ... I have no issues with it in debian-testing
[01:36] <teward> fyi that Debian is under freeze
[01:36] <teward> so it's technically a bit behind impish
[01:37] <guiverc> yeah I know... I'm in debian publicity, but the few upgrades lets users know anyway
[01:38] <guiverc> i could test in opensuse tumbleweed; have to test something else there for lubuntu anyway when I can
[02:06] <guiverc> yeah teward ; ubuntu impish is good on same box; tor works as expected  (issue appears in lubuntu... since I've yesterday's kubuntu daily I'll try that next .. will add to bug report shortly)
[02:07] <teward> guiverc: check.  i have narrowed down the issue to SOMETHING torbrowser-launcher is doing.  Will probably run the crash logs by Tor upstream to see if they have any ideas, because the hash sums match upstream's stable release exactly for the actual binaries and such executed by the version downloaded by torbrowser-launcher
[02:07] <teward> ... tomorrow.
[02:07] <teward> I'm tired :)
[02:07] <teward> good night.
[02:08] <guiverc> Thanks heaps teward & sleep well !
[09:45] <seb128> xnox, hey, any idea when you will be able to do the initramfs-tools / zstd / bionic SRU?
[09:51] <mwhudson> seb128: hey so you tested my livecd-rootfs branch locally -- how did you run it? i've not been having much luck running it localy lately
[09:51] <mwhudson> and when i run it on launchpad it does this https://launchpadlibrarian.net/545981409/buildlog_ubuntu_impish_amd64_test_BUILDING.txt.gz which makes no sense at all
[09:52] <mwhudson> (the error is "config//lb_chroot_layered: 77: printf: %402.t: invalid directive")
[09:53] <seb128> weird one indeed
[09:55] <mwhudson> it's like the file is being rewritten under the shell or something
[09:55] <mwhudson> (there's no printf on line 77 of that file)
[10:33] <mwhudson> oh wait
[10:33] <mwhudson> seb128: suspect this will fix it https://git.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-rootfs/commit/?id=f67b58fce8bcd02c343bc952ac6c840f31a1d85e
[10:35] <seb128> mwhudson, what's the difference between echo "$var" and echo "%s" "$var"?
[10:35] <mwhudson> seb128: Echo_message uses printf under the hood
[10:35] <mwhudson> so if you have a filename that has a printf directive in it...
[10:36] <mwhudson> anyway i've kicked off a build and will see in the morning if it helped :)
[10:36] <seb128> mwhudson, I see, thanks
[10:37] <mwhudson> and then i can get into why it changes the contents of the layers
[11:34] <seb128> rbasak, the GNOME SRU discussion has been inactive again for a week, anything we can do to help things moving?
[11:40] <rbasak> seb128: how about a realtime sync in a hangout and we'll try to sync on getting it to a conclusion?
[11:41] <seb128> rbasak, wfm
[11:41] <rbasak> I stuck something in the calendar for tomorrow
[11:42] <seb128> rbasak, did you want to get more people in the discussion or just us is enough?
[11:46] <rbasak> seb128: I think just us for now. Let's try to define exactly what is remaining so it isn't open ended, and then if those individual tasks need other people we can get more people involved then.
[11:47] <seb128> rbasak, ack
[11:49] <seb128> rbasak, I don't know when you lunch break but in fact it would work better for me an hour or half an hour earlier if you can, I've an appointement outside after that slot and I will probably need to step out a bit earlier
[11:51] <rbasak> seb128: moved forward an hour.
[11:51] <seb128> rbasak, perfect, thanks
[11:51] <rbasak> seb128: to 1100 UTC, to confirm
[11:51] <seb128> rbasak, yes
[11:51] <seb128> 👍
[11:52] <rbasak> Just because I moved it twice by mistake :)
[11:52] <rbasak> Where it is now is good
[11:54] <seb128> yes, confirmed it works for me and accepted, thanks!
[13:37] <apteryx> hello!  I'm trying to understand why the icons in a custom-made .deb fail to be registered with the system (gtk-update-icon-cache needs to be called manually).  Comparing with other debs, they don't manually have gtk-update-icon-cache in a postinst script, so it seems my deb is lacking something.
[13:39] <apteryx> This page hints at the importance of the md5sums file in the .deb control archive: "Since the AppStream Generator relies on packages' md5sums file to determine the contents of a package, symbolic links are not recognized.", but that's for the Appstream Generator.  Does this thing run at .deb installation time?  Or is it a process running on the Ubuntu build farm side?
[13:50] <seb128> apteryx, in which dir is your deb installing the icons?
[13:50] <seb128> apteryx, the refresh is done by /var/lib/dpkg/info/hicolor-icon-theme.triggers (or similar to the gnome directory)
[14:04] <sil2100> laney: yaaay, some more progress - so one thing that I was debugging with the private-tests on the staging instance was that the private-results app wasn't able to authenticate properly via swiftclient, even though the creds seemed good
[14:04] <sil2100> laney: then finally I noticed that the creds file is malformed! It has additional "" double quotes around all the values
[14:04] <sil2100> Which for conffiles is not valid
[14:05] <sil2100> laney: guess this is something IS needs to fix on their side, so that future deployments with these 'staging private test reader' user are properly formatted without any quotes?
[14:06] <sil2100> It had things like 'username = "the-user"' while it should be just 'username = the-user' etc.
[14:06] <sil2100> With this, the private-result fetcher works like a charm (needed a few smaller fixes but oh well)
[14:10] <laney> sil2100: that's me
[14:11] <laney> look in the /srv/ whatever it is location (check shell history) and fix it in there, then mojo run
[14:11] <laney> the documentation should cover that ;-)
[14:12] <laney> I mean, we should have documentation about how to set this up when we merge the private stuff
[14:16] <sil2100> Aaa, ok! Didn't look for it in the docs even, will do o/
[14:16] <sil2100> I'll fix it uppp
[14:17] <sil2100> Just now experimenting with the britney parts
[14:17] <laney> well this isn't explicitly but config in general is and this comes in via config
[14:17] <laney> but the private stuff should get a bit of documentation too, like the bit about having a separate user and all that, how to get the right information to put in the file
[14:18] <laney> the pieces of the architecture you know
[14:18] <laney> :-)
[14:18] <laney> good you're making progress though
[15:20] <apteryx> seb128: it installs two icons; one at /usr/share/icons/hicolor/48x48/apps/jami.png and another one at /usr/share/icons/hicolor/scalable/apps/jami.svg
[15:21] <seb128> apteryx, then the cache should be updated through the triggers when the deb is installed
[15:21] <seb128> the png one
[15:21] <seb128> svg icons are not cached iirc
[15:21] <apteryx> it also has /usr/share/jami-qt/jami-qt.desktop and /usr/share/metainfo/jami-qt.appdata.xml files
[15:21] <apteryx> the .desktop refers to the icon as 'jami'
[15:22] <apteryx> seb128: is the optional md5sums control file (in the control.tar archive inside the ar'd .deb) used by hicolor-icon-theme.triggers?
[15:23] <seb128> I don't think so
[15:44] <apteryx> OK, thanks.  It's mysterious :-)
[15:45] <apteryx> can you think of a way to debug this?
[15:48] <seb128> apteryx, could you share the deb in a ppa maybe?
[15:49] <jawn-smith> Is any core dev available to restart https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=amd64&package=ubuntu-image&trigger=mtools/4.0.31-1
[15:49] <bryceh> jawn-smith, done
[15:50] <jawn-smith> thanks!
[15:50] <apteryx> I'm not well versed with PPAs but I can share it via an upload to gdrive, if that's workable for you?
[15:50] <apteryx> (the .deb)
[15:50] <apteryx> I'm testing directly via dpkg -i
[15:50] <jawn-smith> This one as well please!
[15:50] <jawn-smith> https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=ppc64el&package=ubuntu-image&trigger=mtools/4.0.31-1
[16:09] <apteryx> seb128: here's the file https://drive.google.com/file/d/16xAtuh0Yri7WAERDjsUBc-GkRtDAfIRL/view?usp=sharing; beware, it's large at 453M.  It carries the whole Guix-provided Qt 5.15.2 + run-time required to run Jami, so can be installed on any GNU/Linux, deb-based distribution (I'm testing on Ubuntu 20.04).
[16:11] <apteryx> it won't install anything outside of /gnu/store except a couple copies (it could be symlinks too) provided for easy integration such as /usr/bin/jami-qt, the icons and the metadata
[16:12] <apteryx> so what I'd expect following installing this .deb is to see the Jami icon in the Dash or elsewhere, but instead I get the generic one (the gears icon).
[16:26] <apteryx> if I then manually run 'for d in /usr/share/icons/*; do sudo gtk-update-icon-cache -f $d; done', the icon is correctly resolved
[17:05] <bdmurray> jawn-smith: I did the mtools ubuntu-image one
[17:05] <jawn-smith> thanks bdmurray
[17:19] <bdmurray> dannf: comment #30 in bug 1908452 says its on focal but the apt-get install command shows groovy...
[17:21] <dannf> bdmurray: nice catch, my mistake. i was using different machines for each release, and i see that both groovy and focal were on the same one. let me (re?)do the focal verification now
[17:25] <bdmurray> dannf: thanks
[18:04] <dannf> bdmurray: done
[20:17] <jawn-smith> Any core dev mind giving this another bump? It failed again but in a different place than the first time, so I'm pretty sure it's just flakey.
[20:17] <jawn-smith> https://autopkgtest.ubuntu.com/request.cgi?release=impish&arch=ppc64el&package=ubuntu-image&trigger=mtools/4.0.31-1
[20:31] <bdmurray> jawn-smith: done
[20:31] <jawn-smith> thanks again bdmurray


[01:15] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4454 Currently building (hirsute/signon-keyring-extension). Diff missing (hirsute/kaccounts-integration, hirsute/kaccounts-providers, hirsute/ktp-accounts-kcm, hirsute/ktp-approver, hirsute/ktp-auth-handler, hirsute/ktp-common-internals, hirsute/signon-kwallet-extension, hirsute/signon-plugin-oauth2, hirsute/signond). Failed to build (hirsute/accounts-qml-module, hirsute/signon-plugin-sasl, hirsute/
[01:35] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4454 Dependency wait (hirsute/signon-keyring-extension). Diff missing (hirsute/kaccounts-integration, hirsute/kaccounts-providers, hirsute/ktp-accounts-kcm, hirsute/ktp-approver, hirsute/ktp-auth-handler, hirsute/ktp-common-internals, hirsute/signon-kwallet-extension, hirsute/signon-plugin-oauth2, hirsute/signond). Failed to build (hirsute/accounts-qml-module, hirsute/signon-plugin-sasl, hirsute/sig
[13:35] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4454 Currently building (hirsute/signon-keyring-extension). Diff missing (hirsute/kaccounts-integration, hirsute/kaccounts-providers, hirsute/ktp-accounts-kcm, hirsute/ktp-approver, hirsute/ktp-auth-handler, hirsute/ktp-common-internals, hirsute/signon-kwallet-extension, hirsute/signon-plugin-oauth2, hirsute/signond). Failed to build (hirsute/accounts-qml-module, hirsute/signon-plugin-sasl, hirsute/
[13:41] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Successfully built
[13:55] -queuebot:#ubuntu-ci-eng- RikMills, https://bileto.ubuntu.com/#/ticket/4454 Dependency wait (hirsute/signon-keyring-extension). Diff missing (hirsute/kaccounts-integration, hirsute/kaccounts-providers, hirsute/ktp-accounts-kcm, hirsute/ktp-approver, hirsute/ktp-auth-handler, hirsute/ktp-common-internals, hirsute/signon-kwallet-extension, hirsute/signon-plugin-oauth2, hirsute/signond). Failed to build (hirsute/accounts-qml-module, hirsute/signon-plugin-sasl, hirsute/sig
[14:01] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Pending binary packages
[14:21] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Successfully built
[14:39] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4458 Needs rebuild due to burned version number (hirsute/grub2-signed). Needs rebuild due to higher version at destination (hirsute/grub2)
[14:41] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3840 Needs rebuild due to higher version at destination
[15:54] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Publish failed: Ready to build
[16:18] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Ready to build
[16:57] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Generating diffs
[16:58] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Ready to build
[16:58] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Generating diffs
[16:59] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Successfully built
[17:23] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Publishing packages
[17:39] -queuebot:#ubuntu-ci-eng- Laney, https://bileto.ubuntu.com/#/ticket/4478 Proposed pocket
[18:01] -queuebot:#ubuntu-ci-eng- xnox, https://bileto.ubuntu.com/#/ticket/4460 Ready to build (hirsute/linux, hirsute/systemd). Release pocket (hirsute/dpkg)


 qtbase and most of the rest on the transition is a valid candidate. a few things entangled via proj and re2
 @RikMills [qtbase and most of the rest on the transition is a valid candidate. a few things …], I see you retried http://autopkgtest.ubuntu.com/packages/r/r-cran-lwgeom/groovy/s390x but it failed again :(
 @mitya57 [I see you retried http://autopkgtest.ubuntu.com/packages/r/r-cran-lwgeom/groovy/ …], I just tried it for the hell of it.
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961211


[08:38] <smallsam> hey folks, full disclosure, I work for CloudBolt.io and am currently integrating maas.io into our cloud management product. I've mostly been able to achieve what I need using the api, just once so far reverting to the websocket interface (FWIW that's an interesting endeavour outside of a browser). Anyhow today I've been trying to use the
[08:38] <smallsam> machines/{}/?op=deploy call to deploy bionic, but I can't reliably provision centos/centos70, ubuntu/focal, ubuntu/bionic using different combinations of osystem and distro_series to the api method. It seems the api most of the time silently uses the default osystem and release and haven't tracked out the right combination to get it working. Are
[08:38] <smallsam> there any good logs that I can enable to determine which params it is using/ignoring.
[08:38] <smallsam> For example I'm sure at one stage I was passing just distro_series = centos70 and no osystem at all, but now can't seem to reproduce that success. I just can't believe it's non-deterministic. Has anyone got any advice on how to move forward?
[09:30] <smallsam> So, stepping away from my PC for a while I managed to solve my problem. The intermittent behaviour was caused by by recycling a pool of machines and the lack of params meant the node's existing settings were used for the deploy. I was passing a json blob in the post, not form params.
[09:30] <smallsam> The deploy continued even though it was ignoring the entire json post request rather than failing which was confusing.
[09:30] <smallsam> For reference the reason I use the websocket connection is to call general.osinfo, for which there doesn't appear to be an API equivalent to enumerate all the images.
[09:39] <mup> Bug #1917594 opened: Machine summary missing OS release title <ui> <MAAS:New> <https://launchpad.net/bugs/1917594>
[12:18] <mup> Bug #1917372 changed: maas ui missing buttons after updating to 2.8.3 <MAAS:Fix Released by adam-collard> <maas-ui:Fix Released> <https://launchpad.net/bugs/1917372>
[12:21] <mup> Bug #1917372 opened: maas ui missing buttons after updating to 2.8.3 <MAAS:Fix Released by adam-collard> <maas-ui:Fix Released> <https://launchpad.net/bugs/1917372>
[12:24] <mup> Bug #1917372 changed: maas ui missing buttons after updating to 2.8.3 <MAAS:Fix Released by adam-collard> <maas-ui:Fix Released> <https://launchpad.net/bugs/1917372>
[12:24] <mup> Bug #1917377 changed: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[12:27] <mup> Bug #1917377 opened: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[12:30] <mup> Bug #1917377 changed: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[12:33] <mup> Bug #1917377 opened: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[12:39] <mup> Bug #1917377 changed: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[12:42] <mup> Bug #1917377 opened: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[12:48] <mup> Bug #1917377 changed: maas 2.9.2 proxmox machine violates unique constraint "maasserver_bmc_power_type_parameters_idx" <db> <index> <proxmox> <MAAS:New> <https://launchpad.net/bugs/1917377>
[15:54] <mup> Bug #1917640 opened: MAAS deploy via API fails after upgrade - apparently server crashes on apparmor error <MAAS:New> <https://launchpad.net/bugs/1917640>
[17:45] <mup> Bug #1914807 opened: rack can't contact region, deployments fails <seg> <sts> <MAAS:New> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1914807>
[17:45] <mup> Bug #1917652 opened: 30-maas-01-bmc-config failing on commissioning Cisco UCSC-C220-M4L <hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1917652>
[17:48] <mup> Bug #1914807 changed: rack can't contact region, deployments fails <seg> <sts> <MAAS:New> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1914807>
[17:48] <mup> Bug #1917652 changed: 30-maas-01-bmc-config failing on commissioning Cisco UCSC-C220-M4L <hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1917652>
[17:51] <mup> Bug #1914807 opened: rack can't contact region, deployments fails <seg> <sts> <MAAS:New> <maas (Ubuntu):Confirmed> <https://launchpad.net/bugs/1914807>
[17:51] <mup> Bug #1917652 opened: 30-maas-01-bmc-config failing on commissioning Cisco UCSC-C220-M4L <hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1917652>
[20:15] <mup> Bug #1917667 opened: Commissioning/testing scripts no longer show ETA or progress <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1917667>
[20:15] <mup> Bug #1917669 opened: No way to view previous commissioning or testing script results <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1917669>
[20:15] <mup> Bug #1917670 opened: Storage and interface tests not assoicated with a device <ui> <MAAS:New> <https://launchpad.net/bugs/1917670>
[20:18] <mup> Bug #1917667 changed: Commissioning/testing scripts no longer show ETA or progress <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1917667>
[20:18] <mup> Bug #1917669 changed: No way to view previous commissioning or testing script results <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1917669>
[20:18] <mup> Bug #1917670 changed: Storage and interface tests not assoicated with a device <ui> <MAAS:New> <https://launchpad.net/bugs/1917670>
[20:24] <mup> Bug #1917667 opened: Commissioning/testing scripts no longer show ETA or progress <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1917667>
[20:24] <mup> Bug #1917669 opened: No way to view previous commissioning or testing script results <ui> <MAAS:New> <maas-ui:New> <https://launchpad.net/bugs/1917669>
[20:24] <mup> Bug #1917670 opened: Storage and interface tests not assoicated with a device <ui> <MAAS:New> <https://launchpad.net/bugs/1917670>
[20:28] <mup> Bug #1917671 opened: Commissioning/testing scripts not updated after starting commissioning or testing <ui> <MAAS:New> <https://launchpad.net/bugs/1917671>
[20:31] <mup> Bug #1917671 changed: Commissioning/testing scripts not updated after starting commissioning or testing <ui> <MAAS:New> <https://launchpad.net/bugs/1917671>
[20:37] <mup> Bug #1917671 opened: Commissioning/testing scripts not updated after starting commissioning or testing <ui> <MAAS:New> <https://launchpad.net/bugs/1917671>
[20:40] <mup> Bug #1917671 changed: Commissioning/testing scripts not updated after starting commissioning or testing <ui> <MAAS:New> <https://launchpad.net/bugs/1917671>
[20:43] <mup> Bug #1917671 opened: Commissioning/testing scripts not updated after starting commissioning or testing <ui> <MAAS:New> <https://launchpad.net/bugs/1917671>
[21:22] <mup> Bug #1917672 opened: When running 20.04 in ppc64el as KVM host I am not able to compose virutal machines <MAAS:New> <https://launchpad.net/bugs/1917672>
[21:25] <mup> Bug #1917672 changed: When running 20.04 in ppc64el as KVM host I am not able to compose virutal machines <MAAS:New> <https://launchpad.net/bugs/1917672>
[21:28] <mup> Bug #1917672 opened: When running 20.04 in ppc64el as KVM host I am not able to compose virutal machines <MAAS:New> <https://launchpad.net/bugs/1917672>