[01:14] <kyrofa> jdstrand, I needed to push an update to the dragonboard-turtlebot-kyrofa gadget snap if you could take another look (changing the arch. For some reason the official one is armhf... ?)
[03:35]  * mwhudson looks at the task of shuffling three releases and six architectures into tracks
[06:58] <mup> PR snapd#3090 closed: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3090>
[07:01] <mup> PR snapd#3099 opened: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker <Created by mvo5> <https://github.com/snapcore/snapd/pull/3099>
[07:16] <Son_Goku> morphis: yo
[07:16] <morphis> Son_Goku: hey!
[07:17] <Son_Goku> ugh, I hate being up this early, but w/e
[07:17] <Son_Goku> once I'm up, I'm up
[07:18] <morphis> :-)
[07:19] <Son_Goku> morphis: did you do your initial import of the golang packages yet?
[07:26] <morphis> Son_Goku: its on my list for this morning
[07:32] <Son_Goku> morphis: the sooner, the better ;)
[07:32] <morphis> yeah
[07:33] <morphis> Son_Goku: first one builds for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=18657838
[07:34] <Son_Goku> shit, you didn't import for F24, too?
[07:35] <Son_Goku> according to pkgdb, you only requested branches for Rawhide, F26, and F25
[07:36] <morphis> Son_Goku: should I?
[07:36] <Son_Goku> yes
[07:36] <Son_Goku> I expect to be able to build snapd at least ONCE for F24
[07:36] <morphis> ok
[07:36] <morphis> let me change that
[07:37] <morphis> Son_Goku: however, I get "BuildError: package golang-gopkg-retry not in list for tag f27-pending"
[07:37] <morphis> any idea?
[07:38] <Son_Goku> not really, no
[07:38] <morphis> https://koji.fedoraproject.org/koji/taskinfo?taskID=18657838
[07:38] <Son_Goku> you might want to pop into #fedora-releng and ask about it
[07:39] <morphis> Son_Goku: done
[07:41] <morphis> Son_Goku: I maybe have an idea ..
[07:50] <morphis> Son_Goku: my fault, should be fixed now
[07:51] <Son_Goku> morphis: did zyga show you how fedpkg workflow is supposed to work?
[07:51] <morphis> Son_Goku: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package is what I am using
[07:52] <Son_Goku> okay, good
[07:54] <morphis> Son_Goku: but it doesn't tell if the package is now directly available in rawhide or not, just that I need to use bodhi for anything !rawhide
[07:55] <Son_Goku> for rawhide (which currently is f27), it will automatically transition f27-pending -> f27
[07:55] <morphis> ok
[07:55] <Son_Goku> for branched releases, (f26 and below), it will transition from fXX-pending -> fXX-update-candidate
[07:56] <Son_Goku> from there, you need to use "fedpkg update" to make them available
[07:56] <morphis> Son_Goku: ok, let me get builds for f26-25
[07:56] <Son_Goku> the pending tags refer to pending the packages being signed with the Fedora GPG key
[07:57] <Son_Goku> in RPM distributions, we sign the packages themselves, so that they are cryptographically verifiable no matter how you got the package
[07:59] <Son_Goku> uhh
[07:59] <Son_Goku> morphis: you messed up golang-gopkg-retry-v1
[07:59] <Son_Goku> https://koji.fedoraproject.org/koji/rpminfo?rpmID=9416927
[07:59] <morphis> how?
[07:59] <Son_Goku> look at the Provides
[08:00] <morphis> %{import_path_sec} ?
[08:00] <Son_Goku> yeah
[08:00] <Son_Goku> you used a macro that's not defined
[08:00] <morphis> hm
[08:00] <morphis> time for an update then :-)
[08:01] <Son_Goku> incidentally, please don't do commit reverts
[08:01] <Son_Goku> you can just incrementally commit like any other git repo
[08:02] <morphis> Son_Goku: isn't that what I do with a revert? but ok if that is considered a bad practise
[08:02] <Son_Goku> well, for imports it's bad
[08:02] <Son_Goku> because then no one can tell the actual change in the spec you did
[08:03] <Son_Goku> btw, why does this obsolete gocheck?
[08:04] <Son_Goku> morphis: I think you forgot to remove some stuff :)
[08:04] <morphis> yeah
[08:05] <morphis> Son_Goku: didn't we go through the review process :-)
[08:05] <Son_Goku> you didn't tell me you didn't generate it with gofed
[08:06] <Son_Goku> I don't look too much into gofed-generated specs because they're complex and usually correct
[08:07] <morphis> Not this one, the gettext one is; this one didn't pass gofed because its using gopkg.in and has two identities
[08:07] <morphis> Son_Goku: however, look at the top two commits in http://pkgs.fedoraproject.org/cgit/rpms/golang-gopkg-retry-v1.git/
[08:08] <Son_Goku> looks good to me now
[08:09] <morphis> lets see what the build says
[08:09] <Son_Goku> you'll need to bump the release
[08:09] <Son_Goku> and add to the changelog
[08:09] <Son_Goku> once a successful koji build has occurred, you can never reuse the EVR again
[08:09] <morphis> yeah on that already
[08:21] <morphis> Son_Goku: f24 branches are there now too
[08:34] <mup> PR snapd#3100 opened: tests: fix interfaces-cups-control for zesty (#3035) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3100>
[09:03] <ogra_> kyrofa, indeed it should, but since it is full of binaries and ubuntu-image doesnt complain it does technically not matter if it is armhf ... thanks for the pointer though
[09:12] <mup> PR snapd#3099 closed: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3099>
[09:22] <zyga> morphis: hey, can you please have a look at https://github.com/snapcore/snapd/pull/3095
[09:22] <mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
[09:24] <Son_Goku> zyga: mixing C and Go like this seems like it'd make things worse rather than better
[09:55] <morphis> zyga: sure
[09:56] <zyga> morphis: thanks
[09:58] <mup> PR snapd#3100 closed: tests: fix interfaces-cups-control for zesty (#3035) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3100>
[09:58] <morphis> zyga: so why are we mixing C and Go code here?
[09:59] <zyga> morphis: because go cannot do what we want
[09:59] <zyga> morphis: see the comment up fron the bootstrpa.go
[09:59] <zyga> bootstrap.go
[09:59] <zyga> morphis: if go had any control over threads we could
[09:59] <zyga> morphis: but alas, no
[10:01] <morphis> ah I see you use a constructor
[10:01] <morphis> tricky ..
[10:01] <morphis> was searching the actual call to bootstrap from the Go code
[10:05] <zyga> morphis: yes, it's tricky but that's the only way we found to achieve this
[10:06] <morphis> is that a limitation of setns?
[10:06] <morphis> or a bug?
[10:06] <zyga> morphis: note that this is the 2nd approach
[10:06] <zyga> morphis: it's a feature, that's how setns is documented to work
[10:06] <morphis> I see
[10:06] <zyga> morphis: the 1st approach was all-C but the complexity of the code kept growning
[10:06] <zyga> morphis: and we had 1000s of lines of tests and code that would be far far shorter in go
[10:07] <mup> PR snapd#3029 closed: snapstate: introduce helper to apply to disk a alias states change for a snap (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3029>
[10:10] <morphis> zyga: reviewed
[10:15] <morphis> Son_Goku: https://koji.fedoraproject.org/koji/rpminfo?rpmID=9416966 looks much better
[10:15] <Son_Goku> yep
[10:28] <morphis> Son_Goku: let me get builds for everything else
[10:29] <zyga> morphis: thank you :-)
[10:29]  * zyga has stuff to do now
[10:29] <morphis> zyga: np
[10:31] <morphis> zyga: btw. I see my deb builds for snapd failing because my shellcheck on xenial does not know about -x
[10:34] <morphis> zyga: looks like you changed that recently
[10:38] <morphis> zyga: is it intended that shellcheck isn't pulled in for the deb build?
[10:39] <zyga> morphis: ah, I noticed that too
[10:39] <zyga> morphis: yes, shellcheck is absent on 14.04 and I think it's not that critical anymore
[10:39] <zyga> morphis: we have less and less shell code
[10:39] <morphis> zyga: however with it installed the tests fail for me :-)
[10:40] <zyga> morphis: yeah, we'd have to check if shellcheck groks -x
[10:40] <mup> PR snapd#3101 opened: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3101>
[10:40] <zyga> morphis: but I was too lazy to do that TBH (at the time)
[10:40] <morphis> zyga: ok, so we should have an explicit --disable-shellcheck in debian/rules until we have that
[10:40] <morphis> as otherwise a shellcheck present on the build host causes the build to fail
[10:42] <zyga> morphis: well, that's also too much, just DTRT or remove shellcheck
[10:42] <zyga> morphis: I wonder if shellcheck sans -x is actually useful
[10:43] <zyga> morphis: maybe just check if shellcheck exists *and* supports -x
[10:43] <zyga> morphis: than again, maybe not, -x is needed for out-of-tree builds AFAIR
[10:45] <morphis> for now I removed shellcheck from my host but actually this is a problem we need to fix one or another way
[11:12] <ogra_> ppisati, i have added a linux-raspi2 task to bug 1674509 ... seems the documented overlays that should switch UARTs for BT use do not work
[11:12] <mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1674509>
[11:20] <LinAGKar> I don't seem to be able to run any graphical snaps on OpenSUSE Tumbleweed
[11:21] <ogra_> zyga, ^^ ?
[11:21] <LinAGKar> For example when trying to run keepassxc I get:
[11:21]  * LinAGKar sent a long message: LinAGKar_2017-03-29_11:21:22.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/NYEoBtzLLcrJlbDYTqgPCHzA
[11:29] <ogra_> LinAGKar, is the x11 interface connected for the app ? perhaps SuSE doesnt auto-connect it ... check with "snap interfaces"
[11:31] <LinAGKar> It says:
[11:31] <LinAGKar> :x11                      dwarf-fortress,keepassxc
[11:53] <morphis> Son_Goku: which karma level should I set for my bodhi requests?
[11:54] <King_InuYasha> morphis: "1"
[11:55] <King_InuYasha> new packages can't possibly have any terrible effect on things, so setting stable karma to "1" is fine
[11:55] <morphis> ok
[11:55] <morphis> both for stable and unstable?
[11:55] <King_InuYasha> morphis: for all branches you're making a bodhi update to, yes
[11:56] <King_InuYasha> it should be 1 / -3 for the autokarma settings
[11:57] <morphis> King_InuYasha: thanks!
[11:59] <zyga> ogra_: hey, who had issues with X/Display?
[12:05] <morphis> Son_Goku: ok, bodhi requests are out now; added all in https://docs.google.com/document/d/1l9xS8RqSSjASNEIcHAOanlURNrpmfodf4Fd79QXdLG4/edit
[12:13] <LinAGKar> zyga: I did
[12:17] <mup> PR snapd#3052 closed: overlord: remove snap config values when snap is removed <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3052>
[12:18] <mup> PR snapd#3102 opened: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102>
[12:23] <King_InuYasha> zyga, morphis: if you've tried the new build of golang-github-go-tomb-tomb like I have, you can leave positive feedback+karma to get the ball rolling: https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb
[12:23] <morphis> King_InuYasha: sounds good!
[12:27] <zyga> LinAGKar: hey
[12:27] <zyga> LinAGKar: sorry for the lag, I was away
[12:27] <zyga> LinAGKar: can you tell me more
[12:27] <zyga> LinAGKar: I suspect you use KDE, is that correct?
[12:28] <zyga> King_InuYasha: I'll try it back in the office, I didn't bring my VMs on the road today
[12:29]  * ogra_ imagines zyga to have a bag with VMs in them ... 
[12:30] <zyga> ogra_: really a HDD
[12:32] <LinAGKar> Hi
[12:33] <LinAGKar> zyga: I do use KDE
[12:35] <LinAGKar> zyga: When I try to run keepassxc I get:
[12:35] <LinAGKar> No protocol specified
[12:35] <LinAGKar> QXcbConnection: Could not connect to display :0
[12:35] <LinAGKar> Avbruten (SIGABRT)
[12:35] <LinAGKar> Or for dwarf-fortress I get:
[12:35] <LinAGKar> Gtk-Message: Failed to load module "canberra-gtk-module"
[12:36] <LinAGKar> No protocol specified
[12:36] <LinAGKar> Display not found and PRINT_MODE not set to TEXT, aborting.
[12:37] <mup> PR snapd#3103 opened: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103>
[12:38] <LinAGKar> This is on OpenSUSE Tumbleweed, with snapd from the snappy OBS repo
[12:40] <AndyS2> oh, seems like it builds on opensuse now. interesting, that's why I originally joined this channel. thanks for the info, LinAGKar
[12:41] <LinAGKar> zyga: From snap interfaces I get this: https://pastebin.com/vqLxV0zd
[12:46] <Son_Goku> niemeyer: does snapd's sources offer an API for things to build off of?
[12:47] <Son_Goku> as a golang library, I mean
[12:47] <niemeyer> Son_Goku: Heya
[12:47] <niemeyer> Son_Goku: Yeah, let me get you a link
[12:47] <Son_Goku> hey
[12:47] <niemeyer> Son_Goku: https://godoc.org/github.com/snapcore/snapd/client
[12:57] <zyga> LinAGKar: thanks, I think I know what this is about
[12:57] <zyga> LinAGKar: can you check if you have /tmp/.Xauthority file?
[12:58] <zyga> morphis: ^^
[12:58] <zyga> LinAGKar: (sorry for being disconnected earlier)
[12:58] <LinAGKar> zyga: I do not have that
[12:59] <mup> PR snapd#3104 opened: tests: fix unity test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3104>
[12:59] <zyga> LinAGKar: hmm, curious
[13:00] <zyga> LinAGKar: ok, which distribution relaease are you on?
[13:05] <LinAGKar> zyga: Tumbleweed, it's rolling release
[13:06] <Son_Goku> zyga: I've got snapd built on Fedora for rawhide locally
[13:06] <Son_Goku> 2.23.5
[13:06] <Son_Goku> with nine patches
[13:08] <coreycb> hi, for snappy config schema, am i right to assume that eventually i'll be able to snap install xyz with a specific config schema, in order to set specific configs at install time?
[13:17] <zyga> LinAGKar: Ack, can you please report a bug on the systems:snappy repository
[13:17] <zyga> LinAGKar: we'll try the KDE build and debug it
[13:18] <zyga> LinAGKar: (I was using gnome out of habbit)
[13:18] <zyga> Son_Goku: anything serious?
[13:18] <zyga> Son_Goku: try out some snaps if you can
[13:18] <zyga> Son_Goku: but this feels like something that we will release soon
[13:18] <Son_Goku> I will, but I have to go to work first :)
[13:18] <ogra_> zyga, could it be that our xauth setup is a bit more losely defined than suses ? iirc we have a pretty lose setup for localhost
[13:18] <zyga> Son_Goku: understood, thank you, a *lot*  :-)
[13:18] <zyga> ogra_: yes, perhaps
[13:18] <zyga> ogra_: but I remember seeing something that fails in KDE
[13:18] <zyga> ogra_: but works in GNOME
[13:19] <ogra_> yeah, might not be that
[13:19] <zyga> Son_Goku: FYI: https://forum.snapcraft.io/t/towards-working-snap-update-ns/23 :-)
[13:20] <zyga> ogra_: because I checked tumbleweed in gnome and it was all good
[13:20] <ogra_> right, was just a thought
[13:21] <Son_Goku> zyga: I'd like to have most of these patches merged in some form in an upstream release :/
[13:22] <Son_Goku> by the way, I don't see a PR or a commit resembling the change for making snap-confine internal lib use libtool?
[13:22] <zyga> Son_Goku: I have that patch in suse, I'll try to merge it buuut we may not be able to
[13:22] <zyga> Son_Goku: because there's another PR that adds fine-grained control (per lib) of what to link in statically
[13:23] <Son_Goku> so that PR will supersede it?
[13:23] <zyga> Son_Goku: anyway, I'm sure morphis will have a lot of fun upstreaming that :)
[13:28] <LinAGKar> zyga: Bug report here: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501
[13:28] <mup> PR snapd#3098 closed: cmd: select what socket to use in cmd/snap{,ctl} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3098>
[13:29] <mup> PR snapd#3101 closed: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3101>
[13:31] <morphis> Son_Goku, zyga: I am working through sorting all these patches so only have a minimal set downstream in the distributions
[13:31] <morphis> that is also highly necessary to be able to build packages later on in CI
[13:31] <zyga> morphis: can you please look into that bug ^^
[13:31] <zyga> morphis: thanks for working on the patches!
[13:32]  * zyga needs to get into the car, brb
[13:32] <morphis> zyga: will do
[13:33] <Son_Goku> morphis: https://github.com/Conan-Kudo/snapd/commit/ad2f6b49603b920b7de13b0431587857d31aca86 (clean), https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/tree/snapd-pkg-dev (actual tree)
[13:33] <Vktn> Somebody here?
[13:33] <Vktn> I need help
[13:34] <Vktn> I wanted to install deepin music player in linux mint 18.1
[13:34] <Son_Goku> morphis: if it passes my basic sanity tests (that is, I can run some dead-simple snaps), then I'll prepare the update today
[13:34] <morphis> Son_Goku: 0008, 0007 can be dropped once we have 2.24
[13:35] <morphis> Son_Goku: awesome!
[13:35] <morphis> Son_Goku: 0006 too
[13:35] <Son_Goku> patches 0001, 0004, 0007, and 1001 have not been merged in some form
[13:35] <Vktn> @Morphis can you help me
[13:35] <nothal> Vktn: No such command!
[13:36] <morphis> Son_Goku: for 0007 there is a PR
[13:36] <Vktn> Buddy the thing is I am installing in snap form
[13:36] <morphis> Son_Goku: https://github.com/snapcore/snapd/pull/3096
[13:36] <mup> PR snapd#3096: many: abstract path to /bin/{true,false} <Created by morphis> <https://github.com/snapcore/snapd/pull/3096>
[13:36] <Son_Goku> morphis: I'm aware, see comments :)
[13:37] <morphis> Son_Goku: don't see any on that PR :-)
[13:37] <Vktn> Its stuck on "run configure hook of core snap if present"
[13:37] <morphis> Vktn: what is the problem you have?
[13:37] <Son_Goku> look at my gitlab repo spec file: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec
[13:37] <morphis> Vktn: on which distribution you see this problem?
[13:38] <Vktn> Linux mint 18.1
[13:38] <morphis> Son_Goku: ah good
[13:38] <Vktn> I know snap is not completely supported
[13:38] <morphis> Vktn: you seem to be running into a bug we're currently fixing
[13:38] <Vktn> But I still tried to install by first installing package snapd as suggested by someone on reddit
[13:39] <Vktn> Ok thanks buddy
[13:39] <Vktn> It would be helpful if you give me some more information
[13:39] <Vktn> Is it just because of linux mint
[13:39] <Vktn> ?
[13:40] <Son_Goku> Vktn: no, it's because snapd comes from Ubuntu for mint
[13:40] <Son_Goku> and the bug affects ubuntu
[13:41] <Vktn> Ok thanks buddy :)
[13:41] <Vktn> Somebody's also having same problem on mail-archive.com
[13:41] <mup> PR snapd#3105 opened: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3105>
[13:42] <ogra_> Son_Goku, we rolled back the affected core snap in the stable channel
[13:42] <morphis> Son_Goku: not necessarily, this is more what we see where AppArmor doesn't work
[13:42] <ogra_> so nobody should actualyl see it unless they are not using stable
[13:42] <pedronis> mvo: niemeyer: do you think I can reapply the bits of my overlord reorg that I reverted to help with 2.23.6 ? I need to make snapstate changes and I think they would be better done after that is reapplied
[13:43] <Vktn> https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02782.html
[13:44] <morphis> ogra_: I feel this is more https://bugs.launchpad.net/snappy/+bug/1674193
[13:44] <mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:In Progress by morphis> <snapd (Debian):New> <snapd (Fedora):In Progress> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
[13:44] <niemeyer> pedronis: Can you open a topic for that with details?
[13:44] <ogra_> morphis, ah, right, there were two issues
[13:45] <niemeyer> pedronis: (what PRs, etc)
[13:45] <morphis> ogra_: right, so in this case we run into the problem that the configure hook calls snapctl
[13:45] <morphis> and AppARmor + Seccomp are enabled for the snapd package in Mint
[13:45] <ogra_> yeah, i remember
[13:45] <morphis> so snapctl gets killed by seccomp
[13:46] <morphis> ogra_: and https://github.com/snapcore/snapd/pull/3101 is what should fix this
[13:46] <mup> PR snapd#3101: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3101>
[13:47] <morphis> ogra_: however in cases like Mint we now have the problem that people run into this problem still and I don't see a clear migration path
[13:47] <ogra_> yeah
[13:47] <ogra_> well, update snapd is obviously the path :)
[13:48] <ogra_> we just need to release it
[13:48] <morphis> ogra_: yes
[13:51] <morphis> ogra_: and problem is that we can even recommend manually adding bind to the seccomp profile as it will be regenerated on every core snap updated ..
[13:51] <morphis> Vktn: we're about to release snapd 2.23.5 which will fix that problem which mainly is one on distributions having AppArmor disabled and seccomp on which is the case for Mint
[13:52] <Son_Goku> morphis: anyway, while I'm at work, please work on trying to get the patch situation resolved: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec#L49-65
[13:52] <jdstrand> morphis: note https://github.com/snapcore/snapd/pull/3101 is the proper fix for this
[13:52] <mup> PR snapd#3101: cmd: explicit use of snapd sockets (for 2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3101>
[13:52] <jdstrand> morphis: and https://github.com/snapcore/snapd/pull/3098
[13:52] <mup> PR snapd#3098: cmd: select what socket to use in cmd/snap{,ctl} <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3098>
[13:53] <Son_Goku> morphis: also leave feedback for the golang-github-go-tomb-tomb package in bodhi
[13:53] <morphis> jdstrand: right, but will not help people being blocked by the bug it fixes right now unitl 2.23.6 lands
[13:53] <jdstrand> morphis: both merged now
[13:53]  * jdstrand nods
[13:53] <morphis> Son_Goku: sure but we wont get them all in for 2.23.x
[13:53] <morphis> we can drop them with followup upstream releases
[13:53] <Son_Goku> morphis: I just want them all in master
[13:53] <jdstrand> morphis: but it is nice that a simple core update will resolve it
[13:54] <morphis> Son_Goku: before we release a package to fedora?
[13:54] <jdstrand> that's all I meant
[13:54] <Son_Goku> morphis: yes it's fine
[13:54] <morphis> jdstrand: yes
[13:54] <Son_Goku> morphis: well it doesn't matter about that
[13:54]  * jdstrand hugs mvo for fixing that and the noisy denial in on shot
[13:54] <Son_Goku> but ideally I need something for documenting all the patches
[13:54] <Son_Goku> morphis ^
[13:54] <Son_Goku> snapd moves too quickly for out of tree patches to be sustainable
[13:55] <morphis> +1
[13:55] <morphis> we only have on left so I will take care
[13:55] <Son_Goku> so at the minimum, I need PRs
[13:55] <Son_Goku> ideally, they would all be merged into master :)
[13:56] <Son_Goku> anyway, g2g
[13:56] <Son_Goku> bye
[13:56] <zyga> Son_Goku: o/
[13:56] <Son_Goku> zyga: hi
[13:56] <Son_Goku> zyga: quick catchup: I need at least all patches listed here to have PRs: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec#L49-65
[13:56] <Son_Goku> ideally, all of those should be merged in master
[13:57] <Son_Goku> I do not mind carrying patches, I do mind carrying them forever
[13:59] <morphis> Son_Goku: if you just need a PR, that's a minute work :-)
[14:00] <Son_Goku> morphis: at LEAST a PR
[14:04] <mup> PR snapd#3106 opened: tests: enable docker test for more ubuntu-core systems <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3106>
[14:21]  * mvo hugs jdstrand for his excellent analysis of the problem
[14:21] <pedronis> going ahead (https://forum.snapcraft.io/t/finish-overlord-reorg-to-enable-further-work/37/3)
[14:24] <kyrofa> ogra_, if you use snapcraft to build and then release, it ends up in the armhf set of channels, which means when you use ubuntu-image to build (and specify arm64), ubuntu-image doesn't find it. Are you building in a different way?
[14:25] <ogra_> nope, weridly it pulls the right stuff from the store for me
[14:25] <ogra_> kyrofa, you are using https://github.com/snapcore/dragonboard-gadget right ?
[14:26] <kyrofa> ogra_, indeed
[14:26] <ogra_> oh, and i see you changed it there
[14:26] <kyrofa> ogra_, well, I _offered_ to change it there ;)
[14:26]  * zyga goes to pick up kids from school
[14:26] <ogra_> yeah, mvo was fast and already merged it
[14:27] <kyrofa> Oh nice. I haven't gone through my emails yet
[14:27] <ogra_> ogra@dragonboard:~$ snap info dragonboard|grep refresh
[14:27] <ogra_> refreshed:   2016-10-28 13:04:19 +0200 CEST
[14:27] <ogra_> ugh
[14:28]  * ogra_ notes that we have actually never used the GH one then
[14:30] <ogra_> so tomorrows dragonboard edge image will be interesting :)
[14:31] <kyrofa> Ha!
[14:34] <mup> PR snapd#3107 opened: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" <Created by pedronis> <https://github.com/snapcore/snapd/pull/3107>
[14:40] <pmcgowan> jdstrand, crap does unity8 trigger manual review? I added it back thinking it was ok now
[14:41] <jdstrand> pmcgowan: yes, it is reserved for Canonical employees
[14:41] <jdstrand> "The 'unity8' interface is in development and not yet ready for production. Please remove from your snap's plugs and feel free to reupload. After that your snap should pass automated review."
[14:41] <jdstrand> that is what we say to non-Canonical ^
[14:42] <pmcgowan> jdstrand, ok but I need to wait for a review now? would be happy to reupload
[14:42] <jdstrand> pmcgowan: you are a Canonical employee. you can either remove it, or I can add a snap decl
[14:42] <jdstrand> note if I grant it, you'll get an email that says "Granting use of the 'unity8' interface to Canonical employee. Note that this interface is not complete and subject to break applications at any time."
[14:43] <jdstrand> :)
[14:43] <pmcgowan> :)
[14:43] <pmcgowan> let me remove it and re-upload jdstrand
[14:45] <pedronis> mvo: niemeyer: proposed https://github.com/snapcore/snapd/pull/3107
[14:45] <mup> PR snapd#3107: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" <Created by pedronis> <https://github.com/snapcore/snapd/pull/3107>
[14:45] <pmcgowan> jdstrand, how do I get those out of the review queue? I rejected the first one
[14:47] <mup> PR snapd#3108 opened: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3108>
[14:47] <pmcgowan> rejected them all then
[14:48] <jdstrand> pmcgowan: ok. yeah, there is a mechanism in the web frontend of the store to reject them that it seems you found
[14:52] <ogra> err
[14:59] <mup> PR snapd#3109 opened: Merge 2.23.6 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3109>
[15:04] <kyrofa> Hey jdstrand, what is the rationale for requiring manual review of gadget snaps? They're completely unusable without creating an image seeded with it, right?
[15:05] <ogra> kyrofa, probably to make sure nobody steals the name
[15:06] <jdstrand> kyrofa: cause the necessary assertions dictated by the design of the system aren't implemented yet
[15:06] <jdstrand> kyrofa: in other news, I approved your snap earlier if you didn't see
[15:06]  * ogra saw it on G+ :)
[15:06] <ogra> uappexplorer is very helpful there :)
[15:10] <kyrofa> ogra, that's registration
[15:10] <ogra> yeah, indeed
[15:10] <kyrofa> jdstrand, ahh, makes sense okay
[15:11] <kyrofa> jdstrand, I did see, thank you! Now my images generate
[15:11] <morphis> mvo: does 2.23.6 enable reexecution from core again?
[15:12] <morphis> mvo: seeing snap crashing in cmd.ExecinCoreSnap() on Yocto with 2.23.6
[15:12] <morphis> mvo: this is when using the current beta core snap
[15:12] <niemeyer> ogra: Can we please keep the simpler topic for a while.. we can revert after a few days, once the regulars here are aware
[15:13] <niemeyer> (or we can keep it as well.. let's see what happens)
[15:13] <mvo> morphis: it has not chnaged anything, maybe we need to blacklist on yocto
[15:13] <mvo> morphis: blacklist re-exec there - what kind of crash do you get?
[15:14] <niemeyer> mvo, morphis: Good topic for the forum thread?
[15:14] <ogra> niemeyer, well, that sigles out the snapcraft people as well as hiding the docs
[15:14] <morphis> mvo: https://mm.gravedo.de/files/crash-yocto.png
[15:14] <niemeyer> ogra: The topic is dynamic.. we can bring it back later
[15:15] <morphis> niemeyer: :-)
[15:15] <zyga> morphis: you need to add yocto to a blacklist to have that
[15:15] <niemeyer> ogra: My hope is also that the snapcraft developers come along
[15:15] <zyga> morphis: reexec is on by default
[15:15] <morphis> ahh
[15:15] <niemeyer> ogra: For the same reasons stated in that topic
[15:15] <ogra> niemeyer, well, a forum is not a chat ...
[15:15] <ogra> but we'll see
[15:15] <niemeyer> ogra: Actually, according to the real definition of "chat", it is
[15:16] <ogra> heh, well, lets agree to disagree on that one :)
[15:16] <niemeyer> ogra: You'll need to disagree with the dictionary rather than with me
[15:17] <niemeyer> ogra: We could be having that unnecessary discussion there just as well.. I'm glad we're not, though. :)
[15:17]  * niemeyer steps out for lunch
[15:17] <ogra> heh
[15:18] <morphis> mvo, zyga: where is the blacklist in snapd?
[15:20] <zyga> morphis: I think in cmd/cmd.go
[15:20] <morphis> ok
[15:20] <morphis> zyga: and here it gets tricky ..
[15:21] <morphis> we can't really predict what the release id is for Yocto based systems
[15:22] <morphis> so SNAP_REEXEC it means here
[15:22] <zyga> morphis: that's fine, we will support a reference yocto image
[15:23] <zyga> morphis: and over time the reasons for having the blacklist will go away
[15:23] <zyga> morphis: it's just a temporary measure
[15:23] <morphis> zyga: what means temporary? one release cycle?
[15:23] <niemeyer> Sorry, came back quickly just to not leave snapcraft in a bad place in the forum
[15:23] <niemeyer> kyrofa, sergiusens, ogra: https://forum.snapcraft.io/c/snapcraft
[15:23] <zyga> morphis: a few cycles
[15:23] <niemeyer> Let's please have a hangout at some point today to discuss more details of this initiative
[15:24]  * niemeyer back to lunch
[15:25] <morphis> zyga: sounds like "later this year"
[15:25] <zyga> morphis: once we have CI for yocto (reference) we can add that
[15:25] <zyga> morphis: and once the issues are fixed we can remove that entirely
[15:25] <zyga> niemeyer: the forum died?
[15:25] <zyga> https://forum.snapcraft.io/ gives me "network error"
[15:25] <ogra> works here
[15:26] <zyga> morphis: with you on board I think that's faster
[15:26] <morphis> zyga: hah :-)
[15:26] <zyga> morphis: we have snap-confine that's detached from reexec
[15:26] <zyga> morphis: and we have known ways to fix that
[15:26] <zyga> morphis: we also need to have snap-confine talk to snapd better
[15:26] <zyga> morphis: then we have no issues
[15:27] <morphis> zyga: let me do a distro-patch for now
[15:28] <zyga> morphis: for blacklist? feel free to merge that back
[15:29] <morphis> will do
[15:30] <morphis> zyga: btw. the open-suse bug exists on 42.2 too, so its not wayland
[15:30] <zyga> morphis: are you sure? maybe 42.2 has wayland too/
[15:30] <zyga> morphis: btw, fedora 25 has wayland/gnome as default
[15:30] <zyga> morphis: worth checking
[15:32] <morphis> it doesn't
[15:32] <morphis> its using xcb platform here so no wayland natively in KDE
[15:34] <zyga> morphis: aha
[15:34] <zyga> morphis: well, so it's not wayland
[15:34] <pedronis> niemeyer: I created a topic around the things we discussed after standup: https://forum.snapcraft.io/t/transactionality-locking-and-other-concurrency-coordination/50
[15:34] <zyga> morphis: curious what it might be
[15:35] <morphis> zyga: looking
[15:36] <mup> PR snapd#3110 opened: cmd: add poky to the list of distros which don't support reexec <Created by morphis> <https://github.com/snapcore/snapd/pull/3110>
[15:37] <morphis> zyga: ^^
[15:40] <zyga> morphis: perfect, thanks
[15:42] <niemeyer> pedronis: Woah, sweet!
[15:54] <morphis> zyga: this is a KDE specific problem, same distro using gnome shell those apps work
[15:55] <morphis> zyga: I have the feeling there is some disagreement between what the Qt/gtk version in those snaps expect and what they get from KDE in this case
[15:56] <niemeyer> pedronis: Do you have at hand the etherpad link for the snap aliases discussion we had?  I want to complete the topic about it including the user experience we discussed (or a tweaked version of it)
[15:58] <pedronis> niemeyer: we have the gdoc , it probably needs a bit of edits after what we discussed yesterday though
[15:59] <niemeyer> pedronis: Found it, thanks!
[16:13] <morphis> seb128: ping
[16:19] <mup> PR snapd#3111 opened: snapd: initial implementation for systemd software watchdog for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/3111>
[16:26] <mup> PR snapd#3107 closed: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3107>
[16:39] <LinAGKar> zyga: I don't seem to be able to run those apps under GNOME either (I'm now on my desktop with Leap 42.2 BTW). Maybe it has something to do with, KDE being installed first, or with SDDM?
[16:43] <morphis> Pharaoh_Atem: I've pushed a PR for the last patch without a PR reference, see https://github.com/snapcore/snapd/pull/3108
[16:43] <mup> PR snapd#3108: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3108>
[16:47] <jdstrand> kyrofa: hey, can you see if installing turtlebot-demo-kyrofa auto-connects the interface? either pc or dragonboard is fine
[16:47] <kyrofa> jdstrand, sure, I'll generate a new image now and try it
[16:48] <jdstrand> kyrofa: curious. is the demo snap preinstalled?
[16:48] <kyrofa> jdstrand, indeed
[16:48] <jdstrand> I don't know if this is going to help then. morphis saw issues with preinstalled snaps and auto connection
[16:49] <jdstrand> and that was without a snap decl involved
[16:49] <kyrofa> Hmm... that somewhat defeats the purpose of my blog series, haha! Let me try and see
[16:50] <kyrofa> jdstrand, I guess it depends on how snapd deals with that on boot, eh?
[16:51] <kyrofa> If this image doesn't work, I'll make an image without it preinstalled and see if it auto-connects upon install
[16:53] <jdstrand> kyrofa: I could do the snap decl for the gadget (slot) or the app (plug). I chose the gadget, but can also try it for the app
[16:53] <kyrofa> jdstrand, alright, I'll keep you in the loop here, see if we can't get this to happen
[16:55] <jdstrand> kyrofa: fyi, here is the bug about not being able to do this in the gadget snap: https://bugs.launchpad.net/snappy/+bug/1644074
[16:55] <mup> Bug #1644074: auto connect none auto-connect interfaces of snaps in gadget snap <Snappy:New> <https://launchpad.net/bugs/1644074>
[16:56] <kyrofa> jdstrand, oh darn, I logged one too against snapd
[16:57] <jdstrand> I didn't know the one I just pasted existed (just found it looking for another bug)
[16:58] <kyrofa> Yeah, I've stopped looking in the snappy project :P
[16:58] <kyrofa> I logged bug #1677015
[16:58] <mup> Bug #1677015: My app snap's plug is not auto-connected to my gadget snap's slot <snapd:New> <https://launchpad.net/bugs/1677015>
[16:59] <kyrofa> jdstrand, hey hey, your snap decl change worked
[17:00] <jdstrand> oh!
[17:00] <jdstrand> nice :)
[17:00] <kyrofa> jdstrand, did you do it for both gadgets?
[17:00] <jdstrand> I did
[17:01] <kyrofa> jdstrand, wonderful, thank you :)
[17:01] <jdstrand> np
[17:01]  * jdstrand updates wiki for instructions on working around lack of gadget auto-connect with snap decls
[17:03] <kyrofa> jdstrand, what is the logic in the snap decl exactly: "this app snap can automatically connect to my slot" ?
[17:03] <kyrofa> Similarly, if you did it from the app snap side: "I can automatically connect to that gadget snap's slot" ?
[17:04] <jdstrand> kyrofa: in each of the gadget snaps, there is this snap decl: http://paste.ubuntu.com/24275679/
[17:04] <jdstrand> kyrofa: (for the slot)
[17:04] <kyrofa> Ah ha, okay same page
[17:05] <jdstrand> kyrofa: from the app's side, I'd use the slot-snap-id in the plugs
[17:05] <kyrofa> With the gadget's snap ID
[17:05] <jdstrand> kyrofa: I chose the gadget's snap decl since I figured that it is better mimicking what we are working around: ie, the gadget saying what can autoconnect
[17:05] <kyrofa> Indeed
[17:05] <kyrofa> And agreed
[17:06] <kyrofa> jdstrand, I'm going to write the list with a summary email with some of the issues encountered during this process, just want to make sure I understand
[17:09] <jdstrand> kyrofa: sounds great
[17:14] <kyrofa> jdstrand, does that snap decl apply to updates, as well?
[17:29] <kyrofa> jdstrand, pedronis any idea what this means? task.go:303: DEBUG: 2017-03-29T17:26:45Z ERROR cannot deliver device serial request: Cannot process serial request for device with brand "4tSgWHfAL1vm9l8mSiutBDKnnSQBv0c8", store can sign serial only for brand "canonical"
[17:29] <kyrofa> My demo snap stops running after that, it seems
[17:33] <zyga> kyrofa: it means that you have a custom gadget snap
[17:33] <zyga> kyrofa: and as the brand owner you need to deploy a serial vault to sign assertions from your devices
[17:34] <zyga> kyrofa: the one from canonical doesn't sign assertions from other brands
[17:34] <kyrofa> zyga, any reason why that would halt my app service?
[17:34] <zyga> kyrofa: it would not
[17:34] <zyga> kyrofa: this is just a debug log from snapd
[17:34] <mup> PR snapd#3110 closed: cmd: add poky to the list of distros which don't support reexec <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3110>
[17:35] <zyga> kyrofa: but maybe a bug related to this fact is affecting something else
[17:35] <zyga> kyrofa: suggestion to use the forum :)
[17:36] <jdstrand> kyrofa: fyi, I see the same thing on bbb from ogra. it doesn't seem to affect anything functionally
[17:36] <ogra> what did i break ?
[17:36] <ogra> :)
[17:41] <zyga> ogra: you didn't deploy a serial vault for bbb
[17:41] <jdstrand> ogra: nothing. just saying your bbb gadget throws up the same debug message as kyrofa's gadget
[17:41] <ogra> yeah, because my last name isnt canonical
[17:42] <ogra> :)
[17:42]  * jdstrand notes that kyrofa thought the debug message might be causing a problem. I was reassuring him it doens't seem to
[17:43] <kyrofa> jdstrand, I'm not sure... whenever I first boot, my service starts running fine, then I see http://pastebin.ubuntu.com/24275842/
[17:44] <kyrofa> The service spams the logs, but once that print happens it stops showing anything and the bot stops moving
[17:44] <kyrofa> The service is still running though.... something weird is happening here
[17:44] <zyga> ogra: you make a mistake here, it's *your* brand now, the bbb gadget is not owned by canonical
[17:44] <ogra> zyga, ?
[17:45] <zyga> ogra: you said your last name is not canonical
[17:45] <ogra> yes, the model assertion is completely created by me
[17:45] <jdstrand> kyrofa: idk, just saying I have a service that doesn't suffer from that
[17:45] <zyga> ogra: so you own it
[17:45] <ogra> zyga, yeah, my last name is grawert ;)
[17:45] <zyga> ogra: and you can deploy a serial valut
[17:45] <ogra> oh, can i ? (and should i )
[17:46] <jdstrand> zyga: is that documented somewhere? /me wonders if kyrofa would want to document that as well
[17:46] <jdstrand> meh
[17:46] <ogra> brand and authority id's are min as is the gadget
[17:46] <zyga> ogra: you can and probably should over time
[17:46] <ogra> **mine
[17:46] <jdstrand> if kyrofa would want to blog about that as well
[17:46] <ogra> zyga, i never had any probs due to it
[17:46] <kyrofa> jdstrand, zyga I don't even know enough about the serial vault to know why I'd want one
[17:46] <zyga> jdstrand: I don't think it is; I know CE makes some customer documentation that could be read and trascribed into a public format
[17:46] <zyga> ogra: yet :)
[17:47] <zyga> kyrofa: it's something that signs your serial assertion
[17:47] <kyrofa> zyga, why do I care?
[17:47] <zyga> kyrofa: when a new device shows up it creates a serial assertion
[17:47] <ogra> (i noticed the message above though ... but since all bits of the image work reliable i never bothered about it)
[17:47] <zyga> kyrofa: and asks the brand "here, sign this so that you ack my existence"
[17:47] <zyga> kyrofa: and then you know that you have a device that the brand really blessed
[17:47] <zyga> kyrofa: (not a knock-off or something)
[17:47] <pedronis> kyrofa: that should be a read herring, not something that blocks anything else in the system
[17:47] <ogra> right
[17:48] <pedronis> s/read/red/
[17:48] <ogra> though we should have documentation for it :)
[17:48] <zyga> kyrofa: your brand seems like random garbage though
[17:48] <zyga> ogra: yes, definitely
[17:48] <kyrofa> zyga, isn't that why the model assertion is an assertion, so that I know I'm booting a real image?
[17:48] <ogra> in case you actually want it blessed
[17:48] <zyga> kyrofa: model assertion is just a model assertion
[17:48] <zyga> kyrofa: anyone can slap that on a fake device
[17:48] <kyrofa> zyga, but it's signed
[17:48] <zyga> kyrofa: but anyone can copy it :)
[17:48] <pedronis> kyrofa: not really, assertions are not secrets, they don't grant auth without some context
[17:49] <ogra> right, the brand-id needs to match the signer of the gadget
[17:49] <pedronis> you can take a device copy out it's model assertion etc
[17:49] <ogra> so at least on that level there is some blessing going on
[17:49] <zyga> kyrofa: e.g. company inc makes 1000 devices in factory inc; the factory now runs 2nd batch and sells them for 30% off
[17:49] <zyga> kyrofa: now company inc has twice the support cost and no QA over half of the laptop with its logo
[17:49] <zyga> kyrofa: serial assertion lets you see and respond to that
[17:49] <ogra> pedronis, well, we just learned that your firstboot wont set up the gadget if the signatures dont match
[17:50] <pedronis> ogra: well yes, your brand-id and auth-id on the model must match
[17:50] <ogra> pedronis, so there is *some* brand-id vs gadget signature
[17:50] <kyrofa> zyga, is this something done store side? Or is the "vault" some third-party software?
[17:50] <zyga> kyrofa: because if you ordered 1000 devices and you see 2000 boot you know someone's faking something
[17:50] <zyga> kyrofa: vault is a 3rd party software
[17:50] <pedronis> ogra: yes, but has nothing to do with tha log or the serial
[17:50] <ogra> indeed
[17:50] <zyga> kyrofa: it's literally called serial-vault AFAIR
[17:50] <ogra> thats cherry on top stuff :)
[17:50] <zyga> kyrofa: (well, 1st party but not the store)
[17:51] <pedronis> ogra: it's the new rule I was asked to implement that gadget publisher and model signer need to match unless the gadget comes from canonical
[17:51] <kyrofa> zyga, right, heh, same page
[17:51] <zyga> kyrofa: CE wrote tat
[17:51] <zyga> that*
[17:51] <ogra> pedronis, yeah, and i remember when we discussed that in heidelberg ... serial is just an additional security measure on top
[17:52] <pedronis> serial is super relevant mostly if you want to have controlled access to a branded store
[17:52] <ogra> right
[17:52] <pedronis> (we really would like most thing to have a serial, but that's the main purpose atm)
[17:52] <ogra> but not for a home brewed developer image
[17:52] <pedronis> no
[17:52] <pedronis> as I said that log be benign
[17:52] <ogra> so kyrofa and i should both be fine as is
[17:52] <pedronis> if other things are not aligned it's a different matter
[17:53] <ogra> yeah
[17:54]  * zyga EODs
[17:54] <zyga> see you later guys
[17:55] <pedronis> kyrofa: model assertion authority-id must == brand-id  and gadget publisher ( != canonical) must be == brand-id , if the gadget is from canonical doesn't matter
[17:56] <pedronis> same for custom kernels well
[17:58] <kyrofa> pedronis, right
[17:59] <mup> PR snapd#3094 closed: cmd: rework header check for xfs/xqm.h <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3094>
[18:00]  * pedronis afk
[18:14] <kyrofa> Alright, nevermind guys-- seems to be an issue with the USB passthrough to my VM. As soon as I disconnect/reconnect it things start working
[18:35] <kyrofa> pmcgowan, did I see that you were able to unpublish a single revision of your snap?
[18:39] <kyrofa> pmcgowan, if so, how? I don't see an obvious way to do it
[18:44] <pmcgowan> kyrofa, I cleared a failed one from the review queue
[18:44] <pmcgowan> kyrofa, button way at the bottom of the page
[18:45] <kyrofa> pmcgowan, oh, not an already published rev?
[18:45] <pmcgowan> no but I know there is a way to do that, isnt it just the button at the top?
[18:45] <kyrofa> pmcgowan, doesn't that unpublish the entire snap?
[18:45] <kyrofa> pmcgowan, I was afraid to press it :P
[18:46] <pmcgowan> kyrofa, I havent done it but I know it can be done
[18:46] <jdstrand> don't press that
[18:46] <pmcgowan> lol
[18:46] <jdstrand> :)
[18:46] <kyrofa> Hahaha
[18:46] <pmcgowan> kyrofa, I was going to offer to try one here
[18:47] <kyrofa> jdstrand, do you know how to do this?
[18:47] <jdstrand> I thought it was in there too and I just looked but didn't see it
[18:47] <kyrofa> Huh. Maybe I need nessita to do it manually?
[18:47] <jdstrand> I thought it was specific to a revision. I suspect it can't have ever been released
[18:47] <kyrofa> I released my gadget on the wrong arch at first. I'd like to remove that rev
[18:48] <pmcgowan> kyrofa, I just unpublished all my versions :(
[18:48] <kyrofa> pmcgowan, agh, I knew that was a dangerous-looking button
[18:48] <pmcgowan> but I know you can do it
[18:50] <kyrofa> Hey nessita, I accidentally published revision 1 of dragonboard-turtlebot-kyrofa targeting armhf, when it should have been arm64. Revision 2 is correct, but rev 1 is still available for armhf. There doesn't seem to be a way for me to remove it myself-- can you help me?
[18:53] <nessita> kyrofa, right, unpublishing is not defined for snaps, you need to release a new revision to that channel, or close the channel
[18:53] <kyrofa> nessita, can I close all channels for a given arch?
[18:54] <nessita> kyrofa, hum, no, channel closing is per channel :-/
[18:54] <nessita> kyrofa, what channel you released to?
[18:54] <kyrofa> nessita, stable, for both armhf and arm64. I just want the arm64 one
[18:56] <pmcgowan> kyrofa, so once they are all unpublished you can selectively release them again
[18:56] <pmcgowan> kyrofa, but rather tricky since the dates not listed in the summary
[18:56] <kyrofa> pmcgowan, ah ha! Brilliant! I only have two revs, that's easy
[18:58] <nessita> kyrofa, hum, I can't change the status of the revision in any simple way. Can you try closing stable and then releasing a new amd64 revno to stable?
[19:00] <kyrofa> nessita, pmcgowan's suggestion seems to have worked-- I just unpublished the whole thing, and then published only rev 2
[19:00] <kyrofa> Thanks pmcgowan :)
[19:00] <pmcgowan> great
[19:00] <nessita> kyrofa, ahaha that button is super closed to be removed, you just reminded me :-D
[19:00] <nessita> thanks
[19:00] <nessita> (is just there for clicks)
[19:00] <kyrofa> nessita, whew, made it just in time! :P
[19:01] <nessita> yeah :-)
[19:01] <kyrofa> nessita, thanks for your time
[19:01] <nessita> kyrofa, sorry I couldn't be of more help
[19:07] <kyrofa> My upload speed to people.canonical is so bad...
[19:07] <kyrofa> Oh what do you know, as soon as I whine it perks up a bit
[19:10] <kyrofa> Nope... back to 100k
[19:30] <pmcgowan> nessita, which button, unpublish? that seems quite useful, would be better if it was version/arch specific
[19:30] <nessita> pmcgowan, the snap design does not allow for unpublishing (unreleasing), and is really a risk that someone unpublishes without wanting to
[19:31] <nessita> pmcgowan, people have complained about how risky it is
[19:32] <pmcgowan> nessita, I would concur on that, but sometimes we have reverted a publish
[19:32] <pmcgowan> guess it will require a new version now
[19:34] <nessita> pmcgowan, yes, you need to release a new revision to the channel, or close it
[19:35] <pmcgowan> nessita, how is closing a channel different from unpublishing
[19:35] <pmcgowan> risk wise
[19:38] <nessita> pmcgowan, unpublishing removes all revnos from all channels. Closing a branch makes it show the content of the channel "above" it because of channel tracking (this is valid for all channels but stable, when closing stable it just gets emptied)
[19:39] <nessita> pmcgowan, imagine a very complex matrix of released revnos to many series, many archs, many channels including tracks and hotfixes
[19:39] <nessita> you can have more than 100 released revisions
[19:39] <pmcgowan> indeed
[19:39] <nessita> imagine unpublishing them all
[19:39] <nessita> *by mistake*
[19:39] <nessita> imagine you have paying customer depending on availability of that snap
[19:39] <nessita> so, way too risky
[19:40] <pmcgowan> agreed
[19:40] <nessita> while closing a specific channel affects only revision in that track/risk/hotfix channel
[19:47] <kyrofa> jdstrand, I made a forum post instead of a ML post: https://forum.snapcraft.io/t/issues-encountered-while-creating-custom-gadget-and-image/66
[19:48] <mup> PR snapcraft#1225 opened: channels: Fix staging store test for Tracks <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1225>
[20:05] <jdstrand> kyrofa: nice
[20:06] <mup> PR snapcraft#1205 closed: asset-tracking: track source VCS details <Created by josepht> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1205>
[20:57] <cachio> jdstrand, any idea about this error ?
[20:57] <cachio> [81414.597898] audit: type=1400 audit(1490820896.938:1993): apparmor="DENIED" operation="exec" profile="snap.kpi-ubuntu-app-platform-tests.load" name="/lib/x86_64-linux-gnu/ld-2.23.so" pid=10908 comm="ldd" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
[21:00] <cachio> jdstrand, snappy debug is giving me this http://paste.ubuntu.com/24277039/
[21:00] <jdstrand> cachio: that should be allowed by this rule: /lib/@{multiarch}/ld{,32,64}-*.so    mrix,
[21:01] <jdstrand> cachio: where are you seeing this? what is the output of apparmor_parser -p /var/lib/snapd/apparmor/profiles/snap.kpi-ubuntu-app-platform-tests.load |grep multiarch | grep '/ld'
[21:02] <cachio> jdstrand,  /{usr/,}lib/@{multiarch}/ld{,32,64}-*.so    mr,
[21:02] <cachio> I see this executing "sudo snappy-debug.security scanlog"
[21:06] <jdstrand> cachio: what ubuntu release?
[21:06] <cachio> zesty
[21:06] <cachio> jdstrand, zesty
[21:06] <jdstrand> cachio: ok, so classic distro?
[21:06] <cachio> jdstrand, yes
[21:08] <jdstrand> cachio: oh, the rule you have doesn't include 'ix'
[21:08] <cachio> jdstrand, I see that, but how I should do to add that ix
[21:09] <cachio> jdstrand, I am using content interface to read the libs directory
[21:09] <jdstrand> that rule comes from the apparmor base abstraction
[21:09] <jdstrand> let me see if I can track it down
[21:09] <mwhudson> hi is there an eta on the next snapd release?
[21:11] <jdstrand> cachio: is kpi-ubuntu-app-platform-tests not published anywhere?
[21:11] <cachio> jdstrand, no yet
[21:12] <cachio> I can share it
[21:12] <kyrofa> jdstrand, the review tools flag a symlink to libc6 on ppc64 as an error
[21:12] <kyrofa> jdstrand, no other arch, though
[21:13] <kyrofa> jdstrand, specifically, a symlink to /lib/powerpc64le-linux-gnu/ld-2.23.so
[21:13] <jdstrand> cachio: it's an apparmor bug introduced in r3593.1.6
[21:13] <cachio> jdstrand, ok, bad news for me
[21:13] <cachio> any workaround?
[21:14] <cachio> jdstrand, do you have the bug id?
[21:14] <jdstrand> cachio: you can sed the profile in /var/lib/snapd/apparmor/profiles to add back the ix. can you file a bug?
[21:14] <cachio> jdstrand, sure, where in snappy?
[21:15] <jdstrand> cachio: no, apparmor
[21:15] <jdstrand> https://bugs.launchpad.net/apparmor/+filebug
[21:15] <jdstrand> tyhicks: the zesty apparmor upload is breaking snaps due to r3593.1.6
[21:16] <jdstrand> tyhicks: see cachio's denial
[21:17] <cachio> jdstrand, sorry but I have to leave now, I'll be back in 1 hour
[21:18] <cachio> jdstrand, I'll raise that issue, thanks for the support
[21:18] <kyrofa> jdstrand, note that the symlink itself is named lib64/ld64.so.2
[21:19] <jdstrand> kyrofa: do you have the snap?
[21:19] <kyrofa> jdstrand, I do
[21:19] <kyrofa> Let me make it available
[21:19] <jdstrand> kyrofa: is it in the store?
[21:19] <jdstrand> you can just give me the link to the revision
[21:21] <kyrofa> jdstrand, actually wait... is the click-reviewers-tools in the xenial archives up to date?
[21:21] <jdstrand> kyrofa: no
[21:22] <jdstrand> zesty is
[21:22] <jdstrand> kyrofa: but I think I see the issue. I just need the snap
[21:23] <kyrofa> jdstrand, sent via PM
[21:27] <tyhicks> jdstrand: I'm busy with something else at the moment but I'll be able to read backscroll soon
[21:27] <jdstrand> kyrofa: ok, fixed in trunk. if the publisher/you request a manual review, I can accept it
[21:27] <kyrofa> jdstrand, excellent, thank you!
[21:32] <jdstrand> tyhicks: we should probably discuss in #apparmor
[22:04] <jdstrand> cachio_afk: fyi, we are discussing this in #apparmor on OFTC. I'm not able to reproduce. when you file the bug, please give complete instructions, ideally with a downloadble snap and access to its source code
[22:11] <kyrofa> jdstrand, alright, if I want to test a profile change, I add it to the profile in /var/lib/snapd/apparmor/profiles, and then... what? How do I reload it again?
[22:12] <jdstrand> kyrofa: sudo apparmor_parser -r /path/to/profile
[22:12] <kyrofa> jdstrand, thank you!
[22:14] <kyrofa> jdstrand, sweet, /dev/input/js* is all I need
[22:27] <kyrofa> jdstrand, you mentioned to refer to framebuffer for implementation and gave me a link to bug #1675738, but it seems like work is ongoing to remove udev tagging. Should I not worry about that aspect, then?
[22:27] <mup> Bug #1675738: OpenGL interface should udev tag all /dev/fb* files <snapd-interface> <snapd:In Progress> <https://launchpad.net/bugs/1675738>
[22:45] <mup> PR snapcraft#1166 closed: tests: Fix name registration window limit test to latest changes <Created by fgallina> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1166>
[23:25] <mup> PR snapd#3112 opened: interfaces: add a joystick interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3112>
[23:25] <kyrofa> jdstrand, there's my crack at it ^^
[23:35] <slangasek> does someone here know why I have /etc/ld.so.conf.d/conjure-up.conf on my system, pointing at /snap/conjure-up/156/usr/lib/x86_64-linux-gnu/ ?
[23:36] <slangasek> a directory which contains an incompatible version of libapt-pkg.so?
[23:41] <cachio_afk> jdstrand, sure, I'll upload the snap