[05:32] <zyga> o/
[07:03] <pstolowski> mornings
[07:30] <pstolowski> pedronis: hey, thanks for the review! i've updated #5952
[07:30] <mup> PR #5952: tests/ifacestate: moved asserts-related mocking into helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
[08:00] <pstolowski> niemeyer: woah, thanks for the reviews on hotplug stuff!
[08:02] <alexlarsson> zyga: HAH! flatpak got a haters site before snap! i won! :)
[08:04] <zyga> alexlarsson: (insert meddling kids comment)
[08:04] <zyga> alexlarsson: I firmly believe we are both building the better future for app developers
[08:04] <alexlarsson> No no no
[08:04] <alexlarsson> We're evil masterminds!
[08:04] <zyga> alexlarsson: I woundn't mind that website much if the person was not anonymous
[08:05] <alexlarsson> Man, you're not following the PLAN!
[08:05] <zyga> ah, where is my script :)
[08:05] <zyga> "what are we going to do tonight brain"
[08:07] <alexlarsson> I think my problem with it is that *all* the things in there all apply to .deb/.rpm too (other than potentially flathub having less resources for CVE fixing than some distros)
[08:07] <alexlarsson> So, what do they recommend?
[08:07] <zyga> still one thing I would agree on, the sandboxing tech available in linux is still spotty, there are compromises for early usability
[08:08] <zyga> I think those are fine as long as we are 100% honest about it
[08:08] <alexlarsson> Well, *allowing* a sandbox is better than not allowing it. And if we enforced it no apps would work and people would make hater sites for that.
[08:09] <alexlarsson> can't win the internet
[08:16] <zyga> alexlarsson: although I think flatpack could use some of the --classic prompts from snapd
[08:16] <zyga> alexlarsson: to install an app that has wide-open access to one's system requires to be explicit about it
[08:16] <alexlarsson> We do that in the CLI
[08:16] <alexlarsson> but gnome-software doesn't atm
[08:16] <zyga> mmm, I see
[08:17] <alexlarsson> org.gnome.gedit/x86_64/stable        flathub a03b66681bce
[08:17] <alexlarsson>   permissions: ipc, wayland, x11
[08:17] <alexlarsson>   file access: host, xdg-run/dconf, ~/.config/dconf:ro
[08:17] <alexlarsson>   dbus access: ca.desrt.dconf, org.gtk.vfs.*
[08:17] <alexlarsson> Is this ok [y/n]:
[08:18] <alexlarsson> and we track it so you get deltas displayed on update
[08:18] <zyga> alexlarsson: those are super technical and end with a yes-no question
[08:18] <zyga> those are really asking "do you want this app or not"
[08:18] <zyga> I think it could still use a lot of polish and change to the final prompt
[08:18] <alexlarsson> Yeah, but its *hard* though
[08:18] <alexlarsson> like
[08:19] <Chipaca> alexlarsson: g-s doesn't? i thought we'd fixed that?
[08:19] <alexlarsson> many of those are instant sandbox escape
[08:19] <alexlarsson> x11 => escape
[08:19] <zyga> I think we should phrase it around "do you want to give this application access to your system"
[08:19] <alexlarsson> write to home => escape
[08:19] <alexlarsson> write to dconf => escape
[08:19] <zyga> not around technojargon that even system developers may not fully grasp (the consequences of granting)
[08:20] <zyga> dconf? because auto-start unconfined this way?
[08:20] <alexlarsson> (i'm sure there is a list of things that is spawned stored somewhere in dconf)
[08:20] <zyga> right
[08:20]  * zyga wonders what we do about dconf
[08:20] <alexlarsson> We want to do a portal for it
[08:20] <alexlarsson> but it hasn't happened yet
[08:20] <alexlarsson> TingPing is looking at it soon
[08:21] <alexlarsson> org.freedesktop.ibus.engine.anthy.common add-word-command ['/usr/bin/kasumi', 'kasumi', '-a']
[08:21] <alexlarsson> dconf exploit
[08:23] <alexlarsson> org.gnome.desktop.default-applications.office.calendar exec 'evolution -c calendar'
[08:23] <alexlarsson> another one
[08:24] <alexlarsson> Basically, i think its to risky to try to describe it in non technical words and give people the feeling that they only gave "secure" access
[08:25] <alexlarsson> The only thing i think is possible is to mark what we consider a good sandbox with some "sandbox" tag
[08:25] <alexlarsson> and then the rest is, "do you trust these guys, oh and here is some techincal gobbeligok"
[08:25] <zyga> hmm, I think I recall we did apparmor for dconf somehow
[08:25] <zyga> but perhaps that didn't materialise in the end
[08:26] <zyga> one that would see the get/set arguments (normal apparmor dbus doesn't)
[08:26] <zyga> I agree on the trust aspect
[08:26] <zyga> it's either strong tech or it is trust
[08:27] <niemeyer> pstolowski: np
[08:27] <niemeyer> Mornings
[08:27] <zyga> hey hey
[08:30] <Chipaca> there is no runuser in 14.04 /o\
[08:30]  * Chipaca thinks SRU thoughts
[08:31] <diddledan> Chipaca: careful, that kinda thinking leads to dangerous places
[08:31] <Chipaca> IKR
[08:32] <diddledan> next thing you'll be doing a version bump
[08:32] <zyga> Chipaca: please update centos kernel too ;)
[08:32] <diddledan> yes. and replace yum with apt-get
[08:32] <Chipaca> zyga: I'll file an SRU for that
[08:32] <Chipaca> zyga: OH WAIT
[08:33] <diddledan> that'ld be an epic project - a seamless upgrade from centos to debian or ubuntu :-p
[08:33] <diddledan> i.e. one that doesn't require a separate boot disk
[08:33] <Chipaca> reminds me of a conversation we had way back in the Córdoba LUG
[08:33] <zyga> diddledan: curl flash.io/whatever  | sudo dd of=/dev/sda
[08:33] <zyga> ;-)
[08:34] <Chipaca> right about when macro virii became "popular", and we were building linux distros of the size of these things
[08:34] <Chipaca> anyhoo
[08:35] <diddledan> speaking of virii /me downloads backorifice and sub7
[08:35] <diddledan> I'm hip now
[08:35] <Chipaca> I guess what I need to do is make maybeRunuserCommand check the release and use sudo if runuser isn't available
[08:35] <Chipaca> … or maybe run sudo always?
[08:35] <Chipaca> grmbl grmbl grmbl
[08:37] <diddledan> I love maybe functions - maybeSaveDataThatCannotBeLost
[08:37] <diddledan> and then you get really functions - reallySaveTheData
[08:38] <zyga> niemeyer: is this for real? https://twitter.com/Zondi_Elihle/status/1049557185502609409
[08:40] <Chipaca> diddledan: names are hard; suggestions always welcome
[08:40] <Chipaca> i'd have a tattoo, if i did tattoos
[08:44] <mborzecki> morning
[08:45] <pstolowski> hey mborzecki o/
[08:46] <zyga> hey guys
[08:49] <mup> PR snapd#5953 closed: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5953>
[08:49] <zyga> thank you again mvo
[08:50] <mvo> zyga: for what?
[08:50] <zyga> for that PR
[08:50] <mvo> zyga: I mean, appreciated :)
[08:50] <mvo> zyga: oh, yeah
[08:50] <mvo> zyga: it was slightly tricky to find but simple in the end
[08:53] <niemeyer> zyga: That's so over the top that it's hard to believe indeed.. let me check
[08:53] <pstolowski> mborzecki: do you have a moment for https://github.com/snapcore/snapd/pull/5952 ?
[08:53] <mup> PR #5952: tests/ifacestate: moved asserts-related mocking into helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
[08:53] <dot-tobias> zyga & niemeyer: re tweet → https://twitter.com/_majubs/status/1049794758162432002
[08:54] <mborzecki> pstolowski: will do
[08:54] <zyga> ah
[08:54] <mvo> pstolowski: I just did that one
[08:55] <niemeyer> dot-tobias, zyga: There are many non-joke programs in Multi Show, and it's a channel from Globo which tends to be trustable..
[08:55] <pstolowski> mvo: ah, thanks!
[08:55] <pstolowski> mborzecki: no need then, thanks!
[08:56] <dot-tobias> niemeyer ,zyga: Maybe the security cam footage is real and they added a satirical “interview” – his answers are just so full with double-entendre and humor 😄
[08:57] <niemeyer> dot-tobias, zyga: Yeah, it's a joke.. JS, "Satirical Journal"
[09:00] <Chipaca> zyga: hey
[09:00] <Chipaca> zyga: snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[09:00] <Chipaca> zyga: what did that mean?
[09:00] <zyga> it mean that snap-confine was not confined but should be
[09:00]  * Chipaca looks for his trout
[09:00] <zyga> it runs on a kernel with apparmor support that is enabled
[09:00] <zyga> but it has no profile of itself
[09:00] <Chipaca> zyga: this is inside a 14.04 spread thing
[09:00] <zyga> so it chooses to stop operating
[09:00] <zyga> it means that apparmor service did not load apparmor profile for snap-confine
[09:01] <zyga> is this in a live CD?
[09:01] <Chipaca> zyga: no, spread, using the qemu backend, on 14.04
[09:01] <zyga> uname -a?
[09:01] <Chipaca> Linux autopkgtest 4.4.0-135-generic #161~14.04.1-Ubuntu SMP Tue Aug 28 11:17:49 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[09:01] <zyga> hmmm
[09:01] <zyga> magic
[09:01] <mup> PR #161: Fix unclean tests <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/161>
[09:02] <zyga> what is the status of apparmor.service?
[09:02] <Chipaca> mup: go home, you're drunk
[09:02] <mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
[09:02] <Chipaca> zyga:    Loaded: error (Reason: No such file or directory)
[09:02] <zyga> oh, there you go
[09:02] <Chipaca> zyga: um
[09:02] <Chipaca> zyga: wait, this is 14.04
[09:02] <zyga> so?
[09:02] <Chipaca> zyga: no systemd
[09:02] <zyga> on 14.04 it should still be there
[09:02] <mborzecki> heh https://github.com/snapcore/snapd/pull/5951 travis status on github is still pending, but the travis job has successfuly finished 13h ago
[09:02] <zyga> aaaah
[09:02] <zyga> oh boy
[09:02] <Chipaca> i mean, systemd isn't in charge
[09:02]  * zyga thinks
[09:02] <mup> PR #5951: spread-shellcheck: fix interleaved error messages, tweaks <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5951>
[09:02] <zyga> so, ...
[09:02] <zyga> er
[09:03] <zyga> I forgot the upstart equivalent
[09:03] <Chipaca> mborzecki: hi! do you remember why I switched snapshots to use runuser instead of sudo?
[09:03] <zyga> Chipaca: can you please look at /sys/kernel/security/apparmor
[09:03] <zyga> and cat the policy file
[09:03] <mborzecki> Chipaca: nope, was sudo an option?
[09:04] <zyga> er
[09:04] <zyga> sorry
[09:04] <Chipaca> zyga: 1 sec
[09:04] <Chipaca> zyga: when do we print that message, in particular?
[09:04] <zyga> cat /sys/kernel/security/apparmor/profiles
[09:04] <zyga> not policy, profiles
[09:04] <zyga> Chipaca: when snap-confine starts up and noticed this
[09:04] <Chipaca> zyga: so
[09:05] <Chipaca> zyga:  test-snapd-tools.echo hello
[09:05] <Chipaca> zyga: works
[09:05] <Chipaca> # su -l -c 'test-snapd-tools.echo hello' test
[09:05] <Chipaca> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[09:05] <diddledan> who has access to the forum? should this post be reinstated? it appears to have been flagged for some reason: https://forum.snapcraft.io/t/call-for-testing-savage-xr-battle-for-newerth-game/7754
[09:05] <zyga> yes
[09:05] <zyga> Chipaca: because then it's not privilege ecalation
[09:05] <zyga> you were root
[09:05] <Chipaca> diddledan: too many  links on a newcomer topic
[09:05] <Chipaca> diddledan: unhidden
[09:05] <diddledan> aha
[09:06] <diddledan> thanks
[09:07] <mborzecki> Chipaca: i think we moved from a helper to a goroutine with set*uid and then to runuser
[09:07] <Chipaca> zyga: I don't understand
[09:07] <Chipaca> mborzecki: i did try sudo first
[09:08] <Chipaca> mborzecki: in fact the variable in which I build the command is still called sudoArgs :)
[09:08] <zyga> Chipaca: when you are the user test
[09:08] <zyga> snap-confine gives you root
[09:08] <zyga> so it looks for confinement
[09:08] <mborzecki> Chipaca: hah :) so something must have been off about it then
[09:08] <zyga> when you were root, we just carry on
[09:08] <zyga> it is the logic we picked a while ago
[09:08] <Chipaca> mborzecki: exactly, and I remember you suggesting runuser instead, but I don't remember why
[09:08] <Chipaca> mborzecki: so, I'm going to just plug sudo back in there and see what breaks :-D
[09:09] <mborzecki> Chipaca: sec, let me check the logs
[09:09] <mvo> niemeyer: when you have a moment, could you please check if the name in the system-user assertion to force a password change (pr 5949) is ok. right now it is using "force-password-change: {true,false}"
[09:09] <mup> PR #5949: osutil,asserts,daemon: support force password change in system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5949>
[09:09] <Chipaca> zyga: so how do I work around this?
[09:09] <niemeyer> mvo: That sounds great already
[09:09] <zyga> Chipaca: well, figure out why the profile was not loaded
[09:09] <zyga> it should have
[09:09] <zyga> fist of all, please check if the profile is really absent
[09:11] <Chipaca> zyga: how do i check that?
[09:11] <mborzecki> Chipaca: https://paste.ubuntu.com/p/jNc3bTXKDR/
[09:11] <mborzecki> i should trim the log file
[09:11] <zyga> Chipaca: please look at /sys/kernel/security/apparmor/profiles
[09:12] <Chipaca> zyga: snap.test-snapd-tools.echo (enforce)   (and a bunch more)
[09:12] <zyga> do you see one for snap-confine itself?
[09:12] <zyga> this is about snap-confine profile, not app-specific profile
[09:12] <Chipaca> # grep snap-confine /sys/kernel/security/apparmor/profiles
[09:12] <zyga> snap-confine effectively kills itself by choice
[09:12] <Chipaca> zyga: yes, two results, which irc won't show as pasted because they start with / :)
[09:13] <zyga> haha
[09:13] <Chipaca> # grep snap-confine /sys/kernel/security/apparmor/profiles
[09:13] <Chipaca> /usr/lib/snapd/snap-confine (enforce)
[09:13] <zyga> yes, thank you IRC
[09:13] <Chipaca> /usr/lib/snapd/snap-confine//mount-namespace-capture-helper (enforce)
[09:13] <zyga> so that's the main profile
[09:13] <zyga> what we are missing is the reexec profile
[09:13] <zyga> this very much feels like the bug mvo just fixed
[09:13]  * Chipaca hugs mvo
[09:13] <zyga> is /var/lib/snapd/apparmor/snap-confine present?
[09:13] <Chipaca> zyga: no
[09:14] <zyga> an /var/lib/snapd/apparmor?
[09:14] <zyga> mkdir it please and restart snapd
[09:14] <Chipaca> wait
[09:14] <Chipaca> yes
[09:14] <Chipaca> yes, it's there, just empty
[09:14] <Chipaca> (i misread ls's output /o\)
[09:14] <zyga> ok, restart snapd and let's see
[09:15] <Chipaca> how do i restart snapd on 14.04
[09:15] <Chipaca> man
[09:15] <zyga> ha
[09:15] <zyga> sudo service restart
[09:15] <zyga> AFAIR
[09:15] <zyga> but I may not remember much
[09:15] <Chipaca> it looks like snapd is running under systemd
[09:16] <zyga> oh right
[09:16] <zyga> well
[09:16] <Chipaca> there
[09:16] <Chipaca> restarted
[09:17] <zyga> any new profiles?
[09:17] <Chipaca> JamieBennett: are snaps part of the 14.04 ESM offer?
[09:18] <Chipaca> zyga: not that i can see
[09:18] <JamieBennett> Chipaca: not that I know of
[09:18] <JamieBennett> Chipaca: why?
[09:18] <Chipaca> JamieBennett: because I'd be happier if we could stop worrying about 14.04 soon :)
[09:18] <JamieBennett> :)
[09:19] <Chipaca> zyga: so now what
[09:19] <zyga> Chipaca: I assume you have the core snap installed
[09:20] <Chipaca> zyga: i do
[09:20] <zyga> Chipaca: upon restart of snapd I would expect to see the reexec profile in the places you looked
[09:20] <zyga> ah
[09:20] <zyga> wait
[09:20] <zyga> I'm silly
[09:20] <zyga> the reexec profile is in /etc/apparmor.d
[09:21] <zyga> is there one in /etc/apparmor.d/snap.core.$NUMBER.usr.lib.snapd.snap-confine
[09:21] <Chipaca> zyga: no
[09:21] <zyga> any logs from snapd?
[09:21] <Chipaca> zyga: plenty
[09:21] <Chipaca> this is in spread, so all debug knobs are on
[09:21] <zyga> oh man
[09:21] <Chipaca> "all" <- most
[09:22] <zyga> can you please pastetem?
[09:22] <Chipaca> zyga: as of the last restart?
[09:22] <mborzecki> pedronis: splitting validation from snap is quite a puzzle
[09:22] <zyga> yeah, though no need to limit them just paste what you have
[09:24] <mborzecki> Chipaca: so sudo vs runuser was just about package dependencies?
[09:24] <Chipaca> mborzecki: looks like it, but i'll need to test
[09:24] <Chipaca> mborzecki: thank you for those logs :)
[09:24] <Chipaca> zyga: https://pastebin.ubuntu.com/p/Mc8jwBqMXk/
[09:24] <Chipaca> zyga: slightly truncated horizontally; let me know if you need the full width
[09:25] <zyga> hmmm, nothing out of the ordinary
[09:25] <zyga> I don't know, why is the profile not there ?
[09:25] <zyga> hmm
[09:25] <zyga> actually
[09:25] <zyga> perhaps when we installed the core snap and the directory was missing
[09:25] <zyga> can you refresh core
[09:25] <zyga> to anything
[09:25] <Chipaca> sure 1 sec
[09:25] <zyga> that ought to trigger the right thing
[09:26] <Chipaca> refreshing to beta
[09:26] <Chipaca> (was on edge)
[09:26] <Chipaca> hmm, it hangs
[09:26] <Chipaca> hmm
[09:26] <Chipaca> oh no it worked
[09:26] <Chipaca> just no progress bar
[09:26] <Chipaca> wat
[09:26] <Chipaca> anyway, one wat at a time
[09:26] <zyga> no progrès bar?
[09:26] <Chipaca> zyga: # ls /etc/apparmor.d/
[09:26] <Chipaca> abstractions  cache  disable  force-complain  local  sbin.dhclient  snap  tunables  usr.lib.snapd.snap-confine	usr.sbin.cups-browsed  usr.sbin.cupsd  usr.sbin.rsyslogd  usr.sbin.tcpdump
[09:26] <niemeyer> mvo: LGTM.. couple of trivial optional suggestions only
[09:26] <zyga> hola accents
[09:27] <zyga> Chipaca: hmmm no idea, something is bad
[09:27] <mvo> niemeyer: thank you!
[09:27] <Chipaca> zyga: :-/
[09:27] <niemeyer> mvo: np and thanks!
[09:29] <Chipaca> zyga: should I throw it away and hope it doesn't happen a second time?
[09:29] <zyga> mmm, mmm ...
[09:29] <zyga> mmm
[09:29] <zyga> I'm having conflicts in my head
[09:30] <Chipaca> zyga: just push --force
[09:46] <Chipaca> mborzecki: getting back to runuser-vs-sudo, I'll just add a check and if runuser isn't there, try to use sudo instead
[09:47] <Chipaca> zyga: i'm going to take a break, and go do some physio; if there's anything I should do with this trusty vm let me know otherwise i'll be killing it when i get back
[09:48] <zyga> Chipaca: ack
[09:49] <pedronis> mborzecki: ah,  as I said, just an idea, might be too much of a pain to do quickly now
[09:50] <pedronis> it might be easier to have a copy of the regexp for now
[09:50] <mborzecki> pedronis: interesting idea nonetheless, but i think it's more of a followup material
[09:51] <mborzecki> pedronis: i've added snap/name package and moved some validation code there
[09:51] <mborzecki> pedronis: could be beneficial in the long run
[09:52] <mup> PR snapd#5951 closed: spread-shellcheck: fix interleaved error messages, tweaks <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5951>
[09:52] <sil2100> ogra: hey! Should I kick new pi3 stable images now?
[09:54] <mvo> sil2100: how are things looking on the pi3b+? anything I can/should test?
[09:56] <mvo> Chipaca: I'm inclined to merge 5944 and just see what will happen in adt
[09:56] <mvo> Chipaca: the only open question was slow machines here
[09:56] <mvo> Chipaca: and we will get tests on the pi
[09:58] <mup> PR snapd#5940 closed: store: speedup unit tests <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5940>
[10:03] <mup> PR snapd#5917 closed: cmd/snap: attempt to start the document portal if running with a sess… <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5917>
[10:13] <pstolowski> pedronis: hey, can you re-review #5952 when you have a moment?
[10:13] <mup> PR #5952: tests/ifacestate: moved asserts-related mocking into helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5952>
[10:21] <ogra> sil2100, yeah ... saw your mail, note that pi2 and dragonboard need updating too
[10:22] <ogra> mvo, at least core 16 edge seems to be fine on pi3 b+ here
[10:22] <ogra> (and after the rebuild also stable)
[10:25] <mup> PR snapcraft#2327 closed: pluginhandler: remove prepare, build and install scriptlets <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2327>
[10:27] <mvo> ogra: interessting, I had trouble with uc18, I will dig into it
[10:28] <ogra> mvo, what kind of trouble ?
[10:28] <ogra> booting should generally work
[10:28] <mvo> ogra: yeah booting is fine, I had no network
[10:29] <ogra> (not sure about preipherials with the 4.15 kernel, havent tested with it, but 4.4 is definitely fine, i'm just using it here on a b+)
[10:30] <mvo> ogra: ok, cool
[10:31] <mup> PR snapcraft#2332 closed: waf plugin: support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2332>
[10:35] <mvo> ppisati: hey, with uc18 and kernel 4.15 from the snap I have no networking on my pi3 b+. do you have any suggestions for me how to debug this? does 4.15 work on classic ubuntu with the 3b+?
[10:36] <ogra> mvo, you said /proc/net/dev shows them ... sounds less like a kernel issue then
[10:37] <mup> PR snapcraft#2333 closed: catkin, catkin-tools: add support for bases <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2333>
[10:37] <mup> PR snapd#5871 closed: snapstate: only report errors if there is an actual error  <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5871>
[10:38] <mvo> ogra: yeah, they are visible but not connected, neither wifi nor wired
[10:38] <ogra> right, but the modules seem to load and init the HW ...
[10:39] <ogra> which makes it sound suspiciously like userspace
[10:39] <mvo> ogra: maybe, the same image works on the pi3 (without b+) as a dateapoint
[10:40] <ogra> well, they have the same wifi AFAIK ... but the b+ has a different ethernet NIC
[10:40] <mborzecki> pedronis: i've pushed a fix with copied snap name validation, but if you'd like to entertain the idea of a separate package, I did a quick implementation here: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/validate-name-separate-package
[10:41] <ogra> so at leat wifi should work the same as in the normal pi3
[10:41] <mvo> mborzecki: fwiw (without having looked at the package you just linked to) I like the idea of a snap/validate package
[10:41] <mborzecki> pedronis: i actually sort of like it, probably needs some tweaking still, but could be interesting
[10:42] <mborzecki> mvo: snap/validate may be harder because some validation code touches Info and inside structs directly, so Info would have to be defined elsewhere too
[10:42] <mborzecki> mvo: that PoC is a snap/name with name validation code pulled out, so that you could import it safely in assserts
[10:43] <mvo> mborzecki: aha, I see
[10:43] <mborzecki> mvo:  in that sense it's mostly the validation functions which are pure and take plain arguments
[10:44]  * mvo nods
[10:45] <ppisati> mvo: yes, it works
[10:45] <ppisati> mvo: let me dig out my board and test it
[10:46] <mvo> ppisati: ok, thank you. I guess I need to compare dtb versions and all that to see whats going on?
[10:46] <mvo> ppisati: pardon my ignorance, can I just download an armhf bionic image to test this? or will I need to grab a special ubuntu image somewhere?
[10:48] <mvo> actually maybe my pi3 b+ is just broken, I need to test for this as well
[10:48] <ppisati> mvo: afaik foundation never produced a rpi3(b+) image, so you probably need to roll your own
[10:49] <ppisati> mvo: from time to time i build some classic images just for debugging, let me find one that works
[10:50] <mvo> ta
[10:51] <ogra> mvo, just use a core 16 edge to verify the HW
[10:53] <mborzecki> Chipaca: can you do a quick pass over https://github.com/snapcore/snapd/pull/5946 again?
[10:53] <mup> PR #5946: cmd/snap: unhide --name parameter to snap install, tweak help message <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5946>
[10:55] <cachio> mvo,hello
[10:55] <cachio> mvo, about sru validation
[10:55] <mvo> ogra: sounds sensible
[10:55] <mvo> cachio: hey
[10:55] <cachio> mvo, I have seen some errors which could be related to the snapd.socket which I mentioned yesterday
[10:55] <cachio> https://paste.ubuntu.com/p/2Nyq9GtppF/
[10:57] <mvo> cachio: thanks! hm, hm, the error looks a bit mysterious, any feedback from the checkbox/plainbox people about this?
[10:58] <cachio> mvo, I can't reproduce the same error which I see in the logs but if I could reproduce another related to the snapd.socket
[10:58] <cachio> if you restart the snapd.socket in a look it fails after several tries
[10:59] <cachio> mvo, similar error to the once which is in this log
[10:59] <cachio> https://api.travis-ci.org/v3/job/438978598/log.txt
[11:00] <mvo> cachio: thanks, checking
[11:01] <cachio> mvo, for i in $(seq 100); do sudo systemctl restart snapd.socket; done
[11:02] <cachio> this fails
[11:02] <cachio> if you restart the socket with some sleep time it works well
[11:04]  * pstolowski lunches
[11:11] <mvo> cachio: interessting - do you see anything in the journalctl log when this happens?
[11:11] <mvo> cachio: anything that indicates *why* it fails?
[11:22] <cachio> mvo, no
[11:22] <cachio> mvo, nothing in the logs
[11:24] <cachio> oct 10 08:23:32 cachiomachineold snapd[14837]: main.go:121: Exiting on terminated signal.
[11:24] <cachio> mvo, this https://paste.ubuntu.com/p/sGzrBMt2CK/
[11:25] <Chipaca> mvo: yay, thank you for merging 5944
[11:25] <Chipaca> mborzecki: looking at 5946
[11:28] <Chipaca> mborzecki: grah. Still not happy with the wording, and yet I don't like blocking on this
[11:28] <Chipaca> mborzecki: I'll have a bite to eat and think about this a bit
[11:30] <cachio> mvo, this is the log what I have
[11:30] <cachio> https://paste.ubuntu.com/p/sfpTMSjqTC/
[11:30] <cachio> mvo, systemd could be stopping the restart
[11:30] <cachio> not sure if the error on the tests are related to the same
[11:33] <mup> PR snapd#5956 opened: image: fetch device store assertion if available <Created by pedronis> <https://github.com/snapcore/snapd/pull/5956>
[11:33] <pedronis> mvo: ^
[11:35] <ogra> did #5746 land in any releae yet ?
[11:35] <mup> PR #5746: wrappers: remove Wants=network-online.target <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5746>
[11:35] <ogra> (i dont see any version tag on the PR)
[11:46] <jdstrand> zyga: fyi, re dconf-- there was the idea, design and an implementation that was never agreed to for dconf mediation
[11:50] <mborzeck1> hm a bunch of tests returns early when there's partial confinement, wonder if instead of just looking at partial we could look at specific features reported by snap debug sandbox-features
[11:54] <Chipaca> zyga: so, on 14.04, refreshing core to beta _and then back to edge_ makes the error go away
[11:54] <zyga> oh
[11:54] <zyga> with the profile in place?
[11:54] <zyga> I think it was the missing dir
[11:55] <Chipaca> zyga: i see no file in /etc/apparmor.d/ with a revision in it
[11:56] <Chipaca> zyga: so what does refreshing back and fro do, that restarting snapd doesn't?
[11:56] <zyga> installing core snap is speciall
[11:56] <zyga> we do per-core-rev snap-confine profile generation then
[11:56] <zyga> can you peek at the list of profiles in sysfs/
[11:56] <Chipaca> remind me where that was plz?
[11:57] <Chipaca> ah found it
[11:57] <Chipaca> yes
[11:57] <Chipaca> /snap/core/5694/usr/lib/snapd/snap-confine (enforce) etc
[11:57] <zyga> so that's that
[11:57] <Chipaca> so what's the fix?
[11:57] <Chipaca> do we need to generate those on startup?
[11:59] <Chipaca> zyga: and, why does this only hit 14.04?
[11:59] <zyga> I don't think it hits any specific release, it depends on packaging shipping a directory or not
[11:59] <zyga> perhaps we are not
[12:00] <Chipaca> zyga: which is the directory that should, or shouldn't, exist?
[12:00] <zyga> one sec
[12:01] <mup> PR snapcraft#2334 opened: schema: enfore string for versions <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2334>
[12:01]  * Chipaca goes to hang up some washing
[12:01] <zyga> Chipaca: the one on 563b94dc8fd4ea10daef9e176301efc141c9c5b3
[12:02]  * Chipaca looks
[12:02] <zyga> that it is...
[12:02] <zyga> dirs.SnapConfineAppArmorDir,
[12:02] <zyga> and I think that is /var/lib/snapd/apparmor/snap-confine
[12:02]  * zyga checks
[12:02] <zyga> yes, that's the one
[12:03] <Chipaca> ok, i'll cycle the spread and check that
[12:05] <cachio> mborzecki, hi, to merge #5894 you need the apparmor image by default, right?
[12:05] <mup> PR #5894: many: enable AppArmor on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5894>
[12:05] <mborzecki> cachio: yes
[12:05] <mborzecki> cachio: i've switched the image there
[12:06] <cachio> ok, let me update the default image with apparmor enabled
[12:06] <cachio> that should go by default
[12:07] <mborzecki> cachio: hm i think it should be ok to update the default image, snapd will generated the profiles but s-c will not use them, so the spread suite should not be affected
[12:09] <Chipaca> zyga: and does it have to exist, or does it have to not exist?
[12:09] <zyga> I think it should not exist for a broken system symptom
[12:09] <zyga> since mvo's patch creates it
[12:09] <cachio> mborzecki, ok
[12:22] <mvo> pedronis: thanks, looking at your PR now
[12:31] <Chipaca> zyga: I can confirm that adding a mkdir -p /var/lib/snapd/apparmor/snap-confine early in prepare_project makes the bug go away
[12:31] <zyga>  whee
[12:31] <zyga> I wonder how/why we missed it this long
[12:32] <Chipaca> zyga: because we don't have many tests that do su … <something from a snap>
[12:32] <mvo> if the fix is merged, why are we still seeing this?
[12:32] <zyga> aaah
[12:32] <zyga> good point
[12:32] <Chipaca> mvo: which fix
[12:32] <zyga> Chipaca: the patch ID I referenced
[12:32] <Chipaca> ah
[12:32] <Chipaca> I don't know :)
[12:33] <mvo> Chipaca: https://github.com/snapcore/snapd/pull/5953
[12:33] <mup> PR #5953: apparmor: create SnapAppArmorDir in setupSnapConfineReexec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5953>
[12:33] <mvo> Chipaca: maybe its missing in antoher place as well
[12:33] <Chipaca> mvo: for extra fun, with core tracking edge, snap refresh --beta core && snap refresh --edge core makes the bug go away
[12:34] <mvo> Chipaca: fun!
[12:34] <Chipaca> mvo: easy to reproduce: boot a 14.04, install snapd etc etc, and then try «su -l -c 'test-snapd-tools.echo ohi' test»
[12:34] <mvo> Chipaca: sorry, I missed parts of the backtrace, what is the exact error message oyu get?
[12:34] <mvo> *you
[12:34] <Chipaca> mvo:  snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
[12:35] <mvo> Chipaca: aha, ok - I think this is slightly different from my fix
[12:35] <mvo> Chipaca: I think in your case setupSnapConfineReexec is not run at all
[12:35] <mvo> Chipaca: again pardon my ignorance, how do I reproduce this?
[12:36] <Chipaca> mvo: spread -shell qemu:ubuntu-14.04-64:tests/main/<choose one>
[12:37] <Chipaca> mvo: and then, snap install test-snapd-tools
[12:37] <pstolowski> niemeyer: i've addressed your comments to hotplug PRs; #5860 needs your re-review
[12:37] <mup> PR #5860: interfaces/hotplug: helpers and struct updates <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860>
[12:37] <Chipaca> mvo: and then, su -l -c 'test-snapd-tools.echo ohi' test
[12:38] <pstolowski> niemeyer: and once it's ready it will unblock all the other PRs for landing
[12:38] <mvo> Chipaca: ta
[12:39] <Chipaca> mvo: 14.04 only, not 16.04, and mkdir -p /var/lib/snapd/apparmor/snap-confine in prepare_project makes it go away, as does going to beta and back
[12:39] <Chipaca> mvo: that's all i know :)
[12:40] <Chipaca> now i need to propose a pr that'll fall back to sudo if runuser isn't there, because 14.04
[12:40]  * Chipaca stashes his spread fixes
[12:41] <mvo> Chipaca: ok, running this now and having a look
[12:43] <mvo> 5950 needs a second review
[12:45] <mborzecki> Chipaca: https://paste.ubuntu.com/p/hVYnc6DBv2/
[12:45] <mborzecki> Chipaca: snap services with your suggestion
[12:45] <mup> PR snapd#5950 closed: tests: running the snapd tests on Ubuntu 18.10 <Created by sergiocazzolato> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5950>
[12:47] <pstolowski> mborzecki: i was 4 seconds quicker... the typo goes in ;)
[12:47] <mborzecki> haha :)
[12:48] <Chipaca> mvo: i just failed to reproduce this though :-/ dunno
[12:48] <mvo> Chipaca: ok
[12:48] <mvo> Chipaca: my spread is still running
[12:48] <Chipaca> mborzecki: looking
[12:50] <Chipaca> mborzecki: what do _you_ think of it?
[12:50] <Chipaca> I wish we had a single word that meant "see details", for one
[12:50] <Chipaca> we're abusing the hyphen a bit :)
[12:50] <mborzecki> inquire
[12:51] <mvo> Chipaca: works for me (with latest master)
[12:51] <mborzecki> what was the thesaurus thing niemeyer used?
[12:51] <Chipaca> mvo: as in, you could reproduce it, or it failed?
[12:51] <mvo> Chipaca: it does not fail
[12:51] <Chipaca> mvo: grr
[12:52] <mvo> Chipaca: and I also see the right snap-confine.core.5694 profile in /var/lib/snapd/apparmor/profiles
[12:52] <mvo> Chipaca: was it reliable to reproduce before for you?
[12:52] <Chipaca> mvo: 4 out of 4 times
[12:52] <mvo>  /o\
[12:52] <mvo> hm, hm, hm
[12:53] <Chipaca> mvo: but maybe all i need to do is merge master?
[12:53] <pedronis> Chipaca: hi, could you look at #5956 , it's small, it's a follow up to something you already reviewed
[12:53] <mup> PR #5956: image: fetch device store assertion if available <Created by pedronis> <https://github.com/snapcore/snapd/pull/5956>
[12:53] <mvo> Chipaca: worth a shoot
[12:53] <Chipaca> pedronis: yep, on my list
[12:53] <pedronis> thx
[12:53] <Chipaca> mvo: let me see if i can repro just doing what i did before
[12:53] <Chipaca> mvo: and then i'll merge master
[12:53] <Chipaca> mvo: (what i did before should be what you just did now, but … ¯\_(ツ)_/¯)
[12:53] <mvo> ok
[12:54]  * Chipaca ~> tea and standup
[12:55] <niemeyer> mborzecki: Just add .com :)
[13:11] <mborzecki> debian-9-64 prepare failing? https://paste.ubuntu.com/p/zGNDtwyKVB/
[13:32] <mvo> sil2100: if I want to propose changes to console-conf for uc18, what git PR should I base it on?
[13:40] <mvo> cachio: a link to a log with "	
[13:40] <mvo> Sergio Cazzolato	3:23 PM
[13:40] <mvo> snap list
[13:40] <mvo> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: read unix @->/run/snapd.socket: read: connection reset by peer" would be great
[13:56] <mvo> zyga: http://people.canonical.com/~mvo/core18/core18-dragonboard-18-beta20181009.img
[13:56] <zyga> mvo: thnx
[13:57] <zyga> 5 minutes to download
[14:02] <mvo> zyga: ta
[14:04] <ogra> mvo, btw, thanks for quietening the boot, it i noticeable ... (noticeable enough that i now notice that mount seem to print "ext4" twice on startup)
[14:04] <ogra> *it is
[14:05] <zyga> mvo: flashing now, the rest of the hardware is ready
[14:05] <zyga> what do I need to test exactly?
[14:06] <ogra> this 2min timeout because we hardocde eth0 in the config is still super annoying ... i wish we could leave that hardcoded bit out :(
[14:09] <zyga> mvo: check your telegram
[14:09] <zyga> feel free to push to niemeyer
[14:09] <zyga> mvo: let me know if you need more testing
[14:11] <zyga> niemeyer: bottom line, it doesn't work
[14:18] <niemeyer> Ack
[14:18] <niemeyer> We just need that captured somewhere in a way people can follow up
[14:23] <zyga> I have a photo and a short clip. I can add that anywhere appropriate
[14:35] <mborzecki> cachio: just to be clear, i should switch back to the default arch image now?
[14:35] <zyga> mvo: where shall I add the test result?
[14:41] <mvo> zyga: let me add a bug
[14:41] <mvo> zyga: thanks, this is exactly the old bug
[14:41] <zyga> thank you
[14:42] <zyga> will my testimony on the bug report suffice?
[14:47] <cachio> mborzecki, yes
[14:47] <cachio> the default one has apparmor enabled now
[14:47] <mborzecki> cachio: the problem with restarting snapd.socket reproduces in https://github.com/snapcore/snapd/pull/5948 i've pushed a commit to get more logs
[14:47] <mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
[14:55]  * cachio nice
[14:55] <cachio> mborzecki, nice
[14:55] <cachio> I'll take a look after lunch
[14:55]  * cachio lunch
[14:55] <mup> PR snapcraft#2331 closed: meson plugin: add support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2331>
[14:56] <mvo> mborzecki, cachio I also hit it in my PR and also in debian-9
[14:57] <sil2100> mvo: hey! So we don't have any git repos for what's in the images, which is a big ugh, for now you can prepare a PR for the master branch of subiquity and we'll cherry pick it to the PPA
[14:57] <sil2100> mvo: maybe it's a good idea for me to create a git repo for it
[14:57] <sil2100> For tracking
[14:57] <sil2100> console-conf/subiquity was always slightly hacked-in ;/
[15:06] <sil2100> ogra, lool: I kicked a new stable series of images for 16
[15:06] <ogra> sil2100, awessome !
[15:07] <cwayne> sil2100: hm?
[15:09] <sil2100> cwayne: I think we poked you about that on the sprint, we'll be asking you for some testing of the rpi3 images since we'd like to update those
[15:09] <sil2100> cwayne: for pi3 b+ support
[15:10] <sil2100> For now I kicked the images only
[15:10] <cwayne> sil2100: righto, so those are ready to test?
[15:10] <sil2100> cwayne: not yet! Just kicked the builds, wanted to send you a poke with the image links already
[15:11] <sil2100> Those should be available soonish
[15:11] <ogra> sil2100, we really want to update all arm/arm64 images, the pi2 as well as the db are also massively behind in stable
[15:11] <ogra> but they are less urgent though
[15:12] <sil2100> I guess we'll start with the pi3's for now, not sure we have enough capacity to take on all the others this week
[15:12] <ogra> (pi2 is missing thermal and power-mgmt fixe in the binary firmware and misses interface declarations in snapcraft.yaml in stable)
[15:12] <sil2100> Too much going on
[15:13] <sil2100> ogra: are those changes in the pi2 edge gadget already?
[15:13] <ogra> dragonboard has a ton of changes from ondra to support the internall MMC and such that we also want to ue in customer projects
[15:13] <sil2100> Or should I kick a new build for those to be picked up?
[15:13] <ogra> sil2100, yeah
[15:13] <ogra> well, they are in the git tree since ages
[15:13] <sil2100> Ok o/
[15:14] <ogra> not sure if pi2 also hass not picked them up ...
[15:14] <ogra> *has
[15:14] <mborzecki> cachio: so now it's no reproducing anymore :/
[15:15] <ogra> declare it fixed then ;)
[15:15]  * zyga -> post office
[15:22] <ogra> sil2100, given the state of the arm builders i guess you can forget about re-building the gadget anyway for today (i had no luck with a single build all day here, started to build my snaps locally)
[15:26] <mborzecki> cachio: 3rd restart and still not reproduced
[15:34] <ondra> @ogra without resize fix, new gadget will fail when booted from internal storage (unless you are quick to call resize after first boot)
[15:35] <ogra> ondra, oh, ok
[15:35] <ogra> sil2100, hold back on the dragonboard then
[15:41] <kyrofa> Hey ondra, you around?
[15:42] <ondra> kyrofa yep
[15:42] <mvo> sil2100: ok, I would like to work on the experience of the console-conf-wrapper but lets catch up tomorrow whats the best way for me to do this and how we get into into the image
[15:42] <ondra> ogra it works with sdcard, this only issue when booting from emmc
[15:42] <mvo> sil2100: (in a meeting right now)
[15:43] <ogra> ondra, hmm, which we havent much promoted anyway
[15:43] <ondra> ogra yep
[15:43] <kyrofa> ondra, can you share a snapcraft.yaml using layouts?
[15:43] <ogra> graaaah !
[15:44] <ogra> so just as i'm done doing my chromium snap build on my pi locally and finished the upload the build.s.io armhf builders come back to life !!!
[15:45] <mborzecki> ogra: how long did that take? :) a day?
[15:46] <ogra> well, it uses the binary deb ... just some snap stuff around it ... so only 1h
[15:46] <mborzecki> oh, that's cheating :)
[15:46] <ogra> hahaha
[15:46] <ogra> yeah
[15:56] <kyrofa> zyga, are the target paths or any part of the declaration of a layout validated?
[15:58] <kyrofa> At the string level, I mean
[15:59] <sergiusens> ogra: do you even have enough ram to successfully build that from source?
[16:00] <ogra> there is always swap
[16:00] <ogra> just delays the build by another half day i guess :)
[16:00] <ogra> but i'm sure you *can* build it from source on a Pi if you wanted
[16:01] <mup> PR snapd#5957 opened: overlord/snapshotstate/backend: fall back on sudo when no runuser <Created by chipaca> <https://github.com/snapcore/snapd/pull/5957>
[16:04] <mup> PR snapcraft#2335 opened: lifecycle: remove lxd support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2335>
[16:14] <cachio> mborzecki, I was trying to reproduce it here, left some scripts running an hour and could't reproduce it
[16:23] <mup> PR snapd#5958 opened: NOT-REVIEW: tests: Add debug info main suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5958>
[16:26] <zyga> kyrofa: yes
[16:26] <zyga> kyrofa: all of it is
[16:26] <kyrofa> zyga, I see logic sanity checking what the mounts actually are, but I haven't found any regex
[16:26] <zyga> kyrofa: it's not a simple regex.
[16:26] <zyga> there are rules and more rules
[16:27] <zyga> kyrofa: the up side is that snap validate checks that
[16:27] <kyrofa> Yeah just wanted to see if there was a sanity check I could run up front, but it seems not
[16:55] <mup> PR snapd#5959 opened: systemd: extend Status() to work for socket and timer units <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5959>
[16:56] <mborzecki> cachio: dropped the debug commit in #5948 since the problem stopped reproducing, i'm quite sure it'll reproduce now that i gave up ;)
[16:56] <mup> PR #5948: asserts, image: ensure kernel, gadget, base and required-snaps use valid snap names <Parallel installs ⛓> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5948>
[17:35] <mup> PR snapd#5860 closed: interfaces/hotplug: helpers and struct updates <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5860>
[17:37] <mup> PR snapd#5863 closed: overlord/ifacestate: add hotplug slots with implicit slots <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5863>
[17:39] <mup> PR snapd#5880 closed: interfaces/repo: two helper methods for hotplug <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5880>
[18:32] <mup> PR snapcraft#2336 opened: schema, meta: support layout <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2336>
[18:37] <Chipaca> ooh, guess what, suse failing again
[18:44] <mup> PR snapcraft#2335 closed: lifecycle: remove lxd support for bases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2335>
[19:03]  * cachio afk
[19:26] <mup> PR snapcraft#2337 opened: pluginhandler: library detection instead of injection <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2337>
[19:49] <smoser> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1797218
[19:49] <mup> Bug #1797218: boot hangs in curtin vmtest <amd64> <apport-bug> <cosmic> <uec-images> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1797218>
[19:49] <smoser> is that known ?
[20:02] <mup> PR snapcraft#2336 closed: schema, meta: support layout <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2336>
[20:05] <luk3yx> When I try and build my snap on Ubuntu 18.04 (it needs newer libraries), I get this error:
[20:05] <luk3yx> The linker version '2.23' used by the base 'core' is incompatible with files in this snap
[20:05] <luk3yx> Can I fix it without compiling with older 16.04 libraries?
[20:08] <ijohnson> luk3yx: are you using `base: core18` in your snapcraft.yaml?
[20:08] <luk3yx> No, do I need it?
[20:08] <mup> PR snapcraft#2338 opened: schema, meta: support layout <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2338>
[20:08] <ijohnson> if you are building a snap that targets using 18.04 libraries, then yes you need to add `base: core18` to your snapcraft.yaml
[20:09] <luk3yx> If I add that, will build.snapcraft.io use 18.04 libraries?
[20:10] <ijohnson> I believe that build.snapcraft.io was recently updated to work with core18 bases, so yes it should work
[20:10] <luk3yx> Thanks.
[20:16] <luk3yx> The build is erroring because of a missing package: CalledProcessError: Command '['lxc', 'exec', 'lp-xenial-ppc64el'...
[20:16] <luk3yx> I think that means it's not using 18.04.
[20:16] <ijohnson> Can you link to a more complete build log? I'm not sure that means it's not using 18.04
[20:17] <mup> PR snapcraft#2339 opened: lifecycle: switch to multipass by default <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2339>
[20:17] <ijohnson> Also are you intending to build your snap on ppc64el?
[20:17] <luk3yx> No, build.snapcraft.io did it for me.
[20:18] <luk3yx> Could not find a required package in 'build-packages': libluajit-5.1-dev
[20:18] <luk3yx> When a local apt search displays it.
[20:18] <ijohnson> Okay, so firstly you can specify what specific architectures you want to build your snap on using the `architectures` yaml spec
[20:18] <ijohnson> See https://forum.snapcraft.io/t/architectures/4972
[20:19] <ijohnson> Secondly, I think I mispoke earlier, build.snapcraft.io doesn't support using core18 as a base and you need to use launchpad for it, see https://forum.snapcraft.io/t/core18-base-in-build-snapcraft-io/7715
[20:22] <luk3yx> Now build.snapcraft.io is being unresponsive with removing repos, it says 'IntegrityError'.
[20:22] <luk3yx> Is there a tutorial for setting up a launchpad build?
[20:23] <ijohnson> I don't know of any tutorials for setting up launchpad snap, but basically the process is make an Ubuntu SSO account if you haven't already, then configure your project to have an upstream remote at launchpad, i.e. for git add a new launchpad remote and push the code there. Then on launchpad.net there's a thing you can click to setup a snap package from that code you pushed
[20:24] <ijohnson> Re: IntegrityError, I am not sure about that
[20:24] <ijohnson> You might try asking in #launchpad about that
[20:39] <luk3yx> Thanks, I think I've created it.
[20:44] <luk3yx> It appears to have worked.
[20:55] <kyrofa> zyga, do you know of anything that changed recently on debian? https://github.com/nextcloud/nextcloud-snap/issues/745
[21:05] <mup> PR snapcraft#2340 opened: pack: restrict snap pack to just type app <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2340>
[21:53] <mup> PR snapcraft#2338 closed: schema, meta: support layout <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2338>
[22:44] <mup> PR snapcraft#2340 closed: pack: restrict snap pack to just type app <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2340>
[23:26] <mup> PR snapcraft#2341 opened: schema, meta: support command-chain <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2341>
[23:50] <sergiusens> kyrofa: did we ever merge that LD_LIBRARY_PATH you did to make trusty work?
[23:50] <sergiusens> I think this is a good opportunity to bring it back