[09:20] <mup> PR snapd#7954 opened: changelog: fix typos <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7954>
[09:39] <sdhd-sascha> Hi, is there any newer docs to setup an snapstore, like this: https://ubuntu.com/blog/howto-host-your-own-snap-store ?
[09:43] <Chipaca> sdhd-sascha: not that I am aware of
[09:44] <sdhd-sascha> Chipaca: How can i build my own ubuntu-core and add my own kernel and gadget.
[09:44] <sdhd-sascha> In the store it needs a review and i have to wait
[09:44] <Chipaca> sdhd-sascha: I'd expect ubuntu-image to let you use a local (unasserted) snap
[09:45] <sdhd-sascha> Chipaca: thank you :-) yesterday i already cloned ubuntu-image, because i'm looking for an error message :-)
[09:46] <sdhd-sascha> sudo ubuntu-image -c beta -O rk3318-test rk3318.model
[09:46] <sdhd-sascha> Warning: for backwards compatibility, `ubuntu-image` falls back to `ubuntu-image snap` if no subcommand is given
[09:46] <sdhd-sascha> error: model with series "18" != "16" unsupported
[09:46] <sdhd-sascha> COMMAND FAILED: snap prepare-image --channel=beta rk3318.model /tmp/tmpdh568a0l/unpack
[09:46] <jamesh> sergiusens: a little Christmas present for you: https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930
[09:47] <sergiusens> hello jamesh, thanks!
[09:47] <sdhd-sascha> jamesh: +1
[09:47] <Chipaca> sdhd-sascha: series 18??
[09:47] <pedronis> sdhd-sascha: that's correct, series is fixed to 16, there is nothing like series 18
[09:47] <pedronis> even if you use core18
[09:47] <pedronis> as your base
[09:47] <sdhd-sascha> ?
[09:48] <pedronis> we thought we would have a series 16, 18, 20 etc
[09:48] <pedronis> but in the end it's not what happened
[09:48] <sdhd-sascha> https://www.irccloud.com/pastebin/RwdFllwF/
[09:48] <pedronis> it might change at some point in the future if something changes is an very incompatible
[09:48] <pedronis> way
[09:48] <jamesh> sdhd-sascha: different values for series imply incompatible platforms.  You can mix snaps built for core and core18 on a single system
[09:48] <pedronis> but hasn't so far
[09:49] <pedronis> so series: 16 is fixed everywhere atm
[09:49] <sdhd-sascha> i copied the linux raspi
[09:49] <Chipaca> sdhd-sascha: change series:18 to series:16 in that model and it'll be better
[09:50] <Chipaca> sdhd-sascha: there is no series 18
[09:50] <Chipaca> sdhd-sascha: there never has been, and never will be
[09:50] <sdhd-sascha> What is "series" for ?
[09:50] <Chipaca> sdhd-sascha: resetting the universe
[09:50] <sdhd-sascha> :-D
[09:50] <Chipaca> sdhd-sascha: if we find a fundamental problem with the way we do snaps, and have to restart from scratch in an incompatible way
[09:51] <pedronis> sdhd-sascha: the idea was that at each lts we could have completely disjoin sets of snaps, but we didn't proceed that way atm. it's just a format version number at this point
[09:51] <pedronis> whose change would represent a non-backward compatible change
[09:51] <pedronis> to a lots of things
[09:51] <sdhd-sascha> i understand - thank you :-)
[09:53] <sdhd-sascha> Is there a way, to store my passphrase with "snap sign" ? Currently i only can sign if i call "register-key" again
[10:33] <Chipaca> sdhd-sascha: I'm not sure I understood your question
[10:35] <sdhd-sascha> Chipaca: "snap sign" says: `error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key 0x.... --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n") `
[10:35] <ogra> you dont have the key ;)
[10:35] <sdhd-sascha> Then i call "snap register-key" again. Then it works for a moment.
[10:36] <sdhd-sascha> "register-key" ask me for my passphrase of the key
[10:37] <Chipaca> sdhd-sascha: there is no register-key
[10:37] <ogra> thats a snapcraft option...
[10:38] <sdhd-sascha> Oh, sorry "snapcraft register-key" from https://docs.ubuntu.com/core/en/guides/build-device/image-building#image-building
[10:40] <sdhd-sascha> In this documentation on step 2 is "snap sign", which only works after "snapcraft register-key"
[10:41] <sdhd-sascha> Did i need some "gpg-agent" or something?
[10:43] <ogra> does "snapcraft list-keys" list your key ?
[10:43] <sdhd-sascha> ogra: yes, "default" key
[10:44] <ogra> and you are calling register-key with "default" as option ?
[10:45] <sdhd-sascha> https://www.irccloud.com/pastebin/a7OgLbOb/
[10:46] <sdhd-sascha> And going to 2FA site https://login.ubuntu.com/device-list
[10:46] <sdhd-sascha> i get a 404 page
[10:47] <ogra> well, and you get a 500 error in that paste
[10:47] <sdhd-sascha> yes
[10:48] <sdhd-sascha> the first time it works.
[10:48] <sdhd-sascha> but i need to call "register-key", that "snap sign" works for a moment
[10:49] <sdhd-sascha> https://www.irccloud.com/pastebin/TOfRf5RN/
[10:49] <sdhd-sascha> and snapcraft:3.8
[11:02] <ackk> hi, I have a (go-based) snap which has been failing for a while on BSI, but I can't reproduce the issue locally. https://build.snapcraft.io/user/albertodonato/h2static/785325 is an example of a failing build
[11:02] <ackk> I tried both with and without go-importpath, they both work locally but both fail over there
[11:06] <sdhd-sascha> ackk: is this a local path in the log? `go get -t -d ./github.com/albertodonato/h2static/...`
[11:06] <ackk> sdhd-sascha, yeah that's based on go-importpath
[11:06] <ackk> sdhd-sascha, https://github.com/albertodonato/h2static/blob/master/snap/snapcraft.yaml is the config
[11:07] <sdhd-sascha> ackk: i try it here on my machine and will report, what happens here
[11:07] <ackk> sdhd-sascha, I assume something has changes either with snapcraft or with the building env on launchpad, as I also had to add gcc as build-packages, which wasn't needed before
[11:08] <ackk> sdhd-sascha, thanks
[11:10] <sdhd-sascha> ackk: it works here, too
[11:11] <sdhd-sascha> but i build it with multipass + vm
[11:13] <sdhd-sascha> I will test it now with: `snapcraft build --use-lxd --debug`
[11:13] <ackk> sdhd-sascha, yeah I did --use-lxd, worked for me
[11:18] <sdhd-sascha> ackk: you are right about the env or something. --use-lxd runs without problem here
[11:18] <ackk> I wonder if it's running the right "go" binary on LP
[11:20] <ackk> actually, it doesn't seem it's running "go mod download", which looking at the plugin source code shoud do when go.mod is presente
[11:20] <ackk> *present
[11:22] <ogra> if i call snapctl from within an app, it does properly set the value for a key but doesnt run the configure hook at all ... is that a known issue ?
[11:24] <ackk> ogra I think I've encountered that issue before, ISTR it was intentional (probably to avoid infinite loops?)
[11:26] <ackk> sdhd-sascha, oddly, I get that error if I build with --destructive-mode
[11:27] <ogra> ackk, well, sadly thats not helpful if you need to force-restart an app to make it pick up the new configuration ... :)
[11:28] <ogra> (even worse if the configure hook actually re-writes a config file ... then the app config and snap values get completely out of sync)
[11:29] <ogra> pedronis, ^^^ is that true (not running hooks for snapctl calls when they come from inside an app) ?
[11:29] <ackk> ogra, yeah I agree it should call the hook, maybe it could either detect when it's being run inside a hook and not call it just in that case, or have a flag to do so
[11:29] <pedronis> ogra: yes, that's by design, there has been discussions to support snapctl set --configure to get the other behavior
[11:29] <ogra> ah, thanks ...
[11:29] <ogra> very confusing behaviour :)
[11:30] <ackk> sdhd-sascha, oh, it seems the stable snapcraft doesn't handle go.mod
[11:31] <sdhd-sascha> ackk: oh
[11:31] <sdhd-sascha> i can't use snapcraft:3.9 because of https://github.com/snapcore/snapcraft/pull/2840
[11:31] <mup> PR snapcraft#2840: plugs: plugs can have no element <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2840>
[11:33] <sdhd-sascha> i use snapcraft:3.8
[11:33] <sdhd-sascha> stable
[11:36] <zyga> hey mvo
[11:37] <zyga> are we supposed to work today or did I get my dates messed up?
[11:37] <sdhd-sascha> ackk: i need to ask again. I didn't understand the error cause. What's wrong and in which case?
[11:38] <mvo> zyga: isn't there a public holiday in .pl today?
[11:39] <zyga> yeah, I think so
[11:39] <zyga> ah, but not in .de?
[11:39] <ackk> sdhd-sascha, I get the same error as the build on LP if I run "snapcraft --destructive-mode"
[11:41] <mvo> zyga: not in .de
[11:41] <zyga> ah, that explains everything, I was worried seeing the release that I should be in the office for hours :)
[11:41] <mvo> zyga: well, my understanding is that you guys have a public holiday but you should know better than me :)
[11:44] <Chipaca> mvo: https://mobile.twitter.com/qikipedia/status/1213731861660413952 :)
[11:47] <Chipaca> pedronis: reviewed #7935, i think i'll hold off going on down the stack for a bit
[11:47] <mup> PR #7935: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7935>
[11:47] <mvo> Chipaca: haha - good one
[11:49] <ackk> sdhd-sascha, ah, I think I got it. it seems that the stable snapcraft doesn't handle go modules, but since it's using go1.13 by default now, go tried to pull them. if I remove go.mod it builds.
[11:49] <sdhd-sascha> ah, ok
[11:50] <ackk> so it probably broke for me when go1.13 snap was pushed to stable
[12:00] <ackk> is there a way to extend the environment for pull/build steps? it doesn't seem that exporting a var in override-* works
[12:03] <Chipaca> ackk: do you need to compute the value?
[12:03] <Chipaca> otherwise the environment block should work
[12:03] <ackk> Chipaca, no, it's afixed one. basically a workaround for the issue above ^ would be to set GO111MODULE=off for pull
[12:04] <ackk> Chipaca, can I use "environment" in a part?
[12:04] <Chipaca> ackk: build-environment IIRC
[12:04] <ackk> ah, TIL
[12:06] <ackk> Chipaca, out of curiosity, why is that a list of dicts rather than a dict like the app environment?
[12:07] <Chipaca> ackk: hmm?
[12:08] <Chipaca> ackk: I don't know
[12:08] <Chipaca> ackk: question for sergiusens maybe
[12:14] <ackk> disabling modules via build-environment worked, thanks sdhd-sascha and Chipaca
[12:34] <pedronis> Chipaca: thx for the review
[12:35] <Chipaca> pedronis: i change-requested it because of the error, if i goofed just holler :)
[12:48] <pedronis> Chipaca: no, I think you are right, but need to do some other things before going back to those Prs
[13:02] <pedronis> mvo: Chipaca: what should we do with this bug, it's not clear to me which bits are snapd and which are lubuntu? https://bugs.launchpad.net/snapd/+bug/1858303
[13:02] <mup> Bug #1858303: Snaps don't work unless pre-installed or user logs out and logs back in <snapd> <snapd:New> <https://launchpad.net/bugs/1858303>
[13:14] <mvo> pedronis: hmhm, interessting, looking
[13:20] <mup> PR snapd#7955 opened: tests: remove "test-snapd-tools" in smoke/sandbox on restore <Created by mvo5> <https://github.com/snapcore/snapd/pull/7955>
[13:22] <mup> Bug #1555140 changed: unit test apiSuite.TestGetOpInfoIntegration fails when building the deb in jenkins <Snappy:Won't Fix by chipaca> <https://launchpad.net/bugs/1555140>
[13:23] <mup> PR snapd#7956 opened: packaging: ship var/lib/snapd/desktop/applications in the pkg <Created by mvo5> <https://github.com/snapcore/snapd/pull/7956>
[13:23] <Chipaca> pedronis: that was figured out in the forum
[13:23] <Chipaca> mvo: ^
[13:23] <Chipaca> ah, mvo spotted that already
[13:23] <Chipaca> anyway it's https://forum.snapcraft.io/t/snapd-required-dependencies-to-start/14904
[13:25] <mup> Bug #1611068 changed: 401 when trying to install any snap due to invalid credentials in ~/.snap/auth.json <amd64> <apport-bug> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1611068>
[13:25] <mvo> Chipaca: yeah, 7956 should address it
[13:25] <Chipaca> mvo: ah, nice
[13:28] <mup> Bug #1665756 changed: environment variable setting issue <Snappy:Fix Released> <https://launchpad.net/bugs/1665756>
[13:57] <mup> PR snapd#7948 closed: spread: drop copr repo with F30 build dependencies <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7948>
[14:23] <Chipaca> degville: turing tumble is aweseme (only ever seen it in video -- i assume it's as good as it looks?)
[14:23] <degville> Chipaca: yes! it's really good! :)
[14:24] <mvo> degville: woah, that looks fun!
[14:24] <degville> it's brilliant actually seeing and trying to physically work out how to solve the problems.
[14:50] <sdhd-sascha> ogra: i think i found the problem with "snap sign". The passphrase wasn't shown because of the stdin-pipe.
[14:51] <ogra> ah, ouch
[14:51] <sdhd-sascha> Now i want to refactor the "snap sign"
[14:52] <sdhd-sascha> But can i break backward-compatibility or not
[14:52] <ogra> (i always use a dedictaed "build" or "image" key for my models that goes witjout passphrase)
[14:53] <ogra> (snapcraft allows to give them names at creation time)
[14:53] <sdhd-sascha> ogra: normally, i too ... but this time ...
[14:54] <sdhd-sascha> i'm looking for a "snap delete-key" command, yesterday. Or how can registered keys be deleted ?
[14:54] <ogra> i dont think they can easily
[14:54] <sdhd-sascha> Ok, no delete
[14:55] <ogra> (ask in the forum, i might be wrong ... i know they couldnt a year ago)
[14:55] <sdhd-sascha> Then how about to make "snap sign -k default <filename>"
[15:07]  * cachio lunch
[15:08] <mup> PR snapcraft#2844 closed: Add punctuation rule for comments <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2844>
[15:16]  * Chipaca wonders at what time he should stop with the coffee
[15:16] <ijohnson> grr the snapcraft forum seems even slower this year
[15:20] <ogra> ijohnson, just append "?slow=false" to the url !
[15:21] <ogra> ... and happy new year :)
[15:21] <ijohnson> can I just do ?speed=plaid instead ? :-)
[15:21] <ijohnson> happy new year ogra!
[15:23] <mup> PR snapcraft#2837 closed: remote-build: gpg-signing and usability fixes <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2837>
[15:36] <pedronis> Chipaca: I updated #7935
[15:36] <Chipaca> pedronis: tks
[15:36] <mup> PR #7935: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7935>
[15:37] <Chipaca> pedronis: I presume the dropping of the NoState error is because it's umpossible :)
[15:37] <Chipaca> unpossible*
[15:37] <pedronis> Chipaca: yes, it should not happen, if we have kernel, we should have a model
[15:37] <pedronis> and we check whether we have a kernel just before
[15:38] <Chipaca> yep
[15:38] <Chipaca> +1, thank you
[15:47] <mup> PR snapd#7957 opened: snap-bootstrap: mount the correct snapd snap to /run/mnt/snapd <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7957>
[15:56] <mup> PR core20#18 opened: static: try using /run/mnt/snapd first in run-snapd-from-snap <Created by mvo5> <https://github.com/snapcore/core20/pull/18>
[16:26] <cachio> mvo, hey, having troubles to login into the uc20 instnace as root
[16:26] <cachio> using your branch
[16:27] <cachio> did you change anything today?
[16:28] <pedronis> Chipaca: I reviewed your channel PRs
[16:28] <pedronis> thank you
[16:33] <mvo> cachio: I don't think I did - stange
[16:33] <Chipaca> pedronis: thank you!
[16:34] <Chipaca> pedronis: you're right about InstallPath, i'll fix that in a bit
[16:34] <Chipaca> need to pop some state first :)
[16:36] <Chipaca> also, need to reboot for a new kernel, and go to the shops and stuff. So AFK for a bit.
[16:39] <cachio> mvo, np, I'll continue researching
[16:40] <mvo> cachio: thank you
[16:40] <mvo> cachio: s/stange/strange/ :)
[16:40] <mvo> cachio: there were some core20/gadget changes over the break, maybe something there broke it, but AFAICT the spread test itself is still working on the uc20 tests
[16:45] <cachio> mvo, with your branch didnt work today, the system reboots and it seems to be ok but I cant connect using root
[16:46] <cachio> I was using a branch with my chnges and it was manually adding a access for the users
[16:46] <cachio> and restarting ssh
[16:47] <cachio> I just restarted the travis job to cehck it is wotking after the break
[16:50] <mvo> cachio: oh, ok
[16:51] <mvo> cachio: interessting, so something did change :/ please keep me update!
[16:51] <mvo> updated
[16:56] <cachio> mvo, sure
[17:34] <mup> PR snapd#7958 opened: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
[17:38] <mup> PR snapcraft#2849 closed: rust plugin: split RUSTUP_HOME and CARGO_HOME <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2849>
[17:56] <mup> PR snapcraft#2833 closed: catkin: remove rospack workaround <Created by Arnatious> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2833>
[18:20] <J_C> Hi there. Upon installing chromium-browser - which in my current version of Ubuntu (Kubuntu 19.10) subsequently installs the snapd version - the cursor theme is different to the one I currently use (Breeze theme) whilst it hovers over Chromium's contents. I have gtk-common-themes installed via snapd. Is there a way to force the snap to use the appropriate cursor theme? Thanks.
[18:41] <ijohnson> J_C: you might try asking in #ubuntu-desktop or on the forums, I think most folks here who would be able to help you with that are offline due to TZ's
[19:11] <J_C> ijohnson: Heh, I was actually suggested to ask in here from #ubuntu. No worries.
[19:11] <ijohnson> J_C: ah ok, well anybody else in #snappy is free to speak up but I myself don't know :-)
[19:12] <J_C> ijohnson: It's nothing too urgent anyway, just a small vidual quirk and nothing that impacts functionality at the very least. :)
[20:23] <mup> PR snapd#7956 closed: packaging: ship var/lib/snapd/desktop/applications in the pkg <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7956>
[20:49] <Chipaca> J_C: that will happen for any themes not included in the gtk-common-themes snap
[20:52] <J_C> Chipaca: I was under the impression that both Breeze and Breeze Dark were in gtk-common-themes.
[20:53] <Chipaca> J_C: cursor themes are separate though
[20:53] <Chipaca> and I don't see anything under Breeze/cursors
[20:54] <J_C> That's a shame. At least I know why the cursor isn't showing properly now. Thanks.
[20:55] <mup> PR snapd#7959 opened: tests: fix classic-ubuntu-core-transition-two-cores after refactor of MATCH -v <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7959>
[20:55] <Chipaca> J_C: what this says to me is that the cursor you're seeing is not of the theme but of some kde default
[20:55] <Chipaca> J_C: if you figure out where it's from, maybe see about getting it included?
[20:56] <Chipaca> if it is the default kde one, we should probably include it :)
[20:58] <Chipaca> kenvandine: does that ^ sound sane to you? (about where the cursor is coming from)
[20:59] <thiras> hello
[20:59] <J_C> Chipaca: Sure, I'll have a look into it :) Should I submit a ticket to the gtk-common-themes repo or elsewhere? Would you like a screenshot as to what the current cursor looks like?
[20:59] <thiras> is there a way to give local filesystem permission to snap package?
[21:00] <Chipaca> thiras: not in general no. What are you trying to do in particular?
[21:00] <thiras> specifically dbeaver package. it needs to access native mysql client installed on my system through apt
[21:00] <Chipaca> J_C: i wouldn't know what to do with the screenshot other than agree with you, and i already believe you :)
[21:01] <Chipaca> thiras: that sounds wrong
[21:01] <thiras> you cannot use it's internal drivers to dump a database. it needs native mysql client to do that
[21:01] <thiras> https://github.com/dbeaver/dbeaver/issues/1361
[21:02] <thiras> obviously package maintainer seems be missed that detail. so the current package is totally isolated
[21:02] <thiras> to be*
[21:03] <Chipaca> thiras: there isn't a way of doing that, no
[21:03] <thiras> too bad
[21:04] <thiras> should i open a bug report to package maintainer?
[21:04] <thiras> i guess some of the snap packages can have access to filesystem (like vscode)
[21:04] <Chipaca> classic snaps can, yes
[21:05] <Chipaca> but i don't think it's a bug, this seems more like working as intended
[21:05] <Chipaca> thiras: what is the snap name by the way?
[21:05] <thiras> Chipaca, dbeaver-ce
[21:06] <thiras> maintainer is the dbeaver company itself
[21:06] <thiras> then how modern snaps handles if they need to access to the filesystem?
[21:07] <Chipaca> thiras: 'access to the filesystem' is one thing, what you're wanting is being able to run arbitrary things
[21:07] <Chipaca> thiras: the short answer is that you don't, you can't, that's not how it's supposed to work
[21:08] <Chipaca> anyway, EOD for me
[21:08] <thiras> so i assume that snap package should contain native client within?
[21:08] <Chipaca> 👋
[21:08] <thiras> thanks for help
[21:08] <Chipaca> thiras: exactly, yes
[21:09] <Chipaca> bye!
[21:29] <mup> PR snapd#7960 opened: tests: use unbuffered python output for daemons, misc formatting <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7960>
[22:20] <sdhd-sascha> Where is the place to ask question about "ubuntu-image" ? `error: cannot use kernel "linux-generic-allwinner" published by "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" for model by "go2ddtVdG0SlCsLDKX7cd9IWiZoEbSym"`
[22:21] <sdhd-sascha> Oh, sorry. This is a "snap sign" error
[22:24] <sdhd-sascha> (revert last line)
[22:32] <mup> PR snapd#7961 opened: cmd: sign: add filename param <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7961>
[23:06] <mup> PR snapcraft#2852 opened: wstool: don't rely on host git <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2852>