[02:14] <mup> PR snapcraft#1517 closed: vcs: ignore .vscode project settings  <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1517>
[05:41] <zyga-ubuntu> good morning
[05:58]  * zyga-ubuntu updates debian snapd to .5 
[06:01] <zyga-ubuntu> hello mvo
[06:04] <mup> PR snapd#3502 closed: snap-seccomp: add in-kernel bpf tests  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3502>
[06:04] <mvo> hey zyga-ubuntu, good morning
[06:04] <mvo> zyga-ubuntu: how are you? happy about better network :)?
[06:05] <zyga-ubuntu> mvo: yes, I just installed debian-keyring in a blink of an eye
[06:05] <zyga-ubuntu> mvo: and that's a welcome sight :)
[06:05] <zyga-ubuntu> mvo: I'm working on the .5 update for debian
[06:15] <zyga-ubuntu> mvo: could you please upload the extra tarballs to https://github.com/snapcore/snapd/releases/tag/2.27.5
[06:20] <mvo> zyga-ubuntu: uh, thank you, doing that now. sorry
[06:23]  * zyga-ubuntu is sad to see gustavo remove 2.28 from 3814
[06:23] <mvo> zyga-ubuntu: updated
[06:24] <zyga-ubuntu> thank you
[06:37] <mup> PR snapd#3812 closed: interfaces: expose bluez interface on classic OS <Created by willdeberry> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3812>
[06:57] <zyga-ubuntu> hmm
[06:57]  * zyga-ubuntu tries to wrap his head around the git tree for debian snapd
[07:18] <abeato> lool, maybe you know, what is this flash-kernel package?
[07:42] <mvo> pedronis: 3781 has two +1 and green tests, this can go in, right?
[07:47] <pedronis> mvo: yes, I think so
[07:53] <mup> PR snapd#3781 closed: cmd/snap-repair: track and use a lower bound for the time for TLS checks <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3781>
[08:06] <zyga-ubuntu> mwhudson: hey
[08:06] <zyga-ubuntu> mwhudson: around?
[08:06] <mwhudson> zyga-ubuntu: ish
[08:06] <zyga-ubuntu> mwhudson: so, I looked at other distros but now I'm back to debian
[08:06] <zyga-ubuntu> mwhudson: how should I approach this? I see git-buildpackage files
[08:06] <zyga-ubuntu> mwhudson: what is the workflow?
[08:07] <zyga-ubuntu> mwhudson: I have both the gbp tree and the dst files from .4
[08:07] <zyga-ubuntu> mwhudson: should I import-orig?
[08:07] <mwhudson> zyga-ubuntu: i don't really use gbp much i guess
[08:07] <zyga-ubuntu> mwhudson: ok, so how do you maintain the git repo at alioth?
[08:08] <mwhudson> git merge 2.27.5; dch; git push i think
[08:08] <mwhudson> oh git commit as well of course :)
[08:08] <zyga-ubuntu> mwhudson: so merge the snapd upstream repository in this manually?
[08:09] <mwhudson> yeah, i have upstream as a remote
[08:09]  * zyga-ubuntu tries
[08:14]  * zyga-ubuntu tries building
[08:14] <zyga-ubuntu> mwhudson: thanks, I was approaching this from the wrong angle
[08:14] <zyga-ubuntu> mwhudson: will you dput if I push it back?
[08:14] <zyga-ubuntu> mwhudson: reviewdput
[08:14] <zyga-ubuntu> review/dput
[08:14] <mwhudson> zyga-ubuntu: yes, tomorrow :)
[08:15] <zyga-ubuntu> mwhudson: ok
[08:15] <zyga-ubuntu> mwhudson: I mean, just the changelog
[08:15] <zyga-ubuntu> apart from that it was a clean merge
[08:15] <mwhudson> zyga-ubuntu: cool
[08:15] <zyga-ubuntu> http://paste.ubuntu.com/25437187/
[08:16] <zyga-ubuntu> mwhudson: I can dput if I have the permissions to do so
[08:16] <mwhudson> zyga-ubuntu: push
[08:16] <mwhudson> pls
[08:16] <zyga-ubuntu> k
[08:16] <mwhudson> :)
[08:16] <mwhudson> sorry for terseness, a bit tired :)
[08:18] <pedronis> mvo: what's the plan for 2.28 now?
[08:20] <zyga-ubuntu> mwhudson: pushed
[08:23] <mvo> pedronis: I it seems 2.27.5 is looking good, so today might be a good day to fork it, I have not checked the 2.28 milestones yet though
[08:25] <pedronis> mvo: there's one PR by zyga, seems a bit of a stretch to fit it in, unless we want to do it next week
[08:26] <mvo> pedronis: let me have a look, we could create the 2.28 branch on monday too, that has the added benefit that 2.27 should be out of the door by then
[08:26] <mvo> pedronis: 2.27.5 in stable hopefully
[08:26] <pedronis> mvo:  #3621
[08:26] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[08:26] <mvo> pedronis: aha, yeah, this one looks risky
[08:27] <zyga-ubuntu> mvo: risky?
[08:27] <mvo> zyga-ubuntu: well, lots of feedback from jamie, no gustavo review yet, risky in the sense that it may take time to get it in shape
[08:28] <zyga-ubuntu> mvo: this was reviewed by gustavo already
[08:28] <zyga-ubuntu> mvo: we did it over a hangout
[08:28] <zyga-ubuntu> mvo: the feedback I reacted to was actually from gustavo originally
[08:28] <pedronis> he should probably vote too for clarity
[08:28] <mvo> zyga-ubuntu: aha, I don't see anything in the PR itself about this
[08:28] <zyga-ubuntu> mvo: I'm only worried about one thing: https://github.com/snapcore/snapd/pull/3621#discussion_r136204646
[08:28] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[08:28] <mvo> zyga-ubuntu: exactly what pedronis said, hard for others to know that
[08:28] <zyga-ubuntu> mvo: yes, gustavo didn't comment
[08:28] <pedronis> anywway jamie didn't finish his review yesterday
[08:29] <zyga-ubuntu> mvo: I think I need to talk to jamie about that point as I wasn't planning on confining snap-update-ns yet
[08:29] <mvo> zyga-ubuntu: aha, ok
[08:29] <zyga-ubuntu> it's way further down the line and I don't think this is any less safe
[08:29] <zyga-ubuntu> (since snapd already calls it unconfined on interface changes)
[08:29] <mvo> zyga-ubuntu: right, so that is what I mean with "risky", it seems there are some open points still
[08:30] <mvo> zyga-ubuntu: anyway, if its important we can wait, but I don't want to wait long :)
[08:30]  * zyga-ubuntu would love to get some real-world testing for this
[08:30] <zyga-ubuntu> right
[08:30] <pedronis> we should be careful not too move thing so much that 2.29 is after the rally
[08:31] <mvo> pedronis: gustavo has some questions in 3773 about the possiblity to simplify the repair logs by overwriting some old data. I'm slightly concerned about the possible information loss but OTOH it will mean a much more tidy output. have you seen his comment?
[08:31] <pedronis> yes, I have seen his comment
[08:32] <mvo> pedronis: good point about the rally
[08:33] <pedronis> mvo: I suppose if we send   execution where  exit status != 0 to errtracker, losing data is a bit less of an issue
[08:33] <pedronis> the script doesn't change for the same revision
[08:33] <pedronis> so as long as we keep enough info to know which revno we *did* run, it should be ok
[08:33]  * zyga-ubuntu reboo/
[08:34] <pedronis> mvo: less files around would be nicer
[08:34] <stub> Would it be possible to make a classic snap that exposes an arbitrary filesystem path to a contained snap via the content interface ?
[08:35] <pedronis> mvo: then we would renames all files  to r#.ext   as we discussed already
[08:36] <lool> abeato: what do you need to know about flash-kernel?
[08:36] <ogra_> stub, ICBW but i think classic turns off all interface capabilities
[08:36] <lool> abeato: it's an ad hoc way to install kernels on random ARM and other boards
[08:36] <lool> e.g. in flash, on this or that partition, in this or that format etc.
[08:37] <mvo> pedronis: aha, excellent plan - so errtracker+simplified logs. I will do that
[08:37] <stub> oh, I thought that sort of thing was starting to be allowed to make it easier to transition from classic -> contained.
[08:38] <ogra_> that would be quite a security hole
[08:38] <abeato> lool, yeah, I was wondering what did it support. uboot only? would it support creating and flashing an android boot partition?
[08:41] <lool> abeato: it does support flashing an android style image
[08:41] <lool> abeato: see https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/functions search for abootimg
[08:42] <lool> abeato: this is how the db entries look like https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/db/all.db
[08:42] <lool> abeato: search for android in there too
[08:42] <abeato> lool, hmm, so to have a new device supported, it would need to be added to that DB
[08:45] <lool> abeato: Yes; I think you can override it localy, but the easiest is to edit a .db file to your looking until it works
[08:45] <lool> *locally
[08:46] <abeato> lool, got it, thanks
[08:46] <lool> abeato: note that Ubuntu's and Debian's flash-kernel often have a large delta, but the general concepts and architecture should be the same
[08:47] <abeato> lool, ok, noted
[09:11] <mvo> pedronis: 2.28 has one blocker right now, we need to sort some armhf/arm64 syscall in the seccomp tests, I will dig into that later, right now arm builds are broken :/
[09:17] <pedronis> mvo: oops, ok
[09:17] <mwhudson> i guess zyga's reboot didn't go so well
[09:17] <mvo> yeah, but no worries, I will look into it soon
[09:28] <zyga> re
[09:28]  * zyga sent kids to the cinema and resumes work
[09:29] <zyga> mwhudson: sorry for being off, if you are still around just tell me if I shall dput now
[09:49] <mwhudson> zyga: this is splitting hairs a bit but uploaders has me@zygoon.pl but the changelog is @canonical.com
[09:50] <mwhudson> zyga: otherwise looks fine, i assume you've test built it?
[09:50] <zyga> mwhudson: aw, sorry, shall I amend and force pus>
[09:50] <mwhudson> zyga: pls
[09:50] <zyga> yes, certainly
[09:50] <zyga> mwhudson: doing that now
[09:53] <zyga> mwhudson: edited, let me rebuild ... just in case
[09:54] <zyga> I also fixed the local repo config so that the right email gets used in the future
[10:12] <mup> PR snapcraft#1519 opened: lxd: use a unique temporary folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1519>
[10:18]  * zyga sighs
[10:18] <zyga> artful is artfoul for me :/
[11:06] <mup> PR snapd#3831 opened: store: move device auth endpoint uris to config <Created by atomatt> <https://github.com/snapcore/snapd/pull/3831>
[11:30] <pedronis> mvo: Chipaca: do you remember what's the state of this:  https://forum.snapcraft.io/t/hashsum-failures-during-tests/198/4
[11:57] <jdstrand> mvo: you need set_tls
[11:57] <pedronis> so fedora is back to flakyness
[11:58] <pedronis> https://travis-ci.org/snapcore/snapd/builds/270368782?utm_source=github_status&utm_medium=notification
[11:58] <jdstrand> mvo: syscall=983045. scmp_sys_resolver -a arm 983045
[12:00] <jdstrand> mvo: also, syscall=78, scmp_sys_resolver -a aarch64 78: readlinkat
[12:03] <jdstrand> mvo: so, set_tls for armhf and readlinkat for arm64
[12:03] <jdstrand> mvo: i386 failure was unrelated to seccomp
[12:04] <jdstrand> mvo: with old snap-confine I think we may have limited the architectures we ran the testsuite on, so didn't have the full list
[12:10] <jdstrand> mvo: I'm going to try to build snapd from the ppa in a classic chroot on armhf and see if it needs more than set_tls
[12:10] <jdstrand> mvo: my dragonboard is not readily available, but if you need me to do the same there, I can
[12:24] <mup> PR snapd#3832 opened: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3832>
[12:25] <jdstrand> mvo: that is for you ^ (I'm still checking armhf)
[12:25]  * ogra_ glares at 983045 ... i always thought syscall is an int
[12:26] <jdstrand> that's an int :)
[12:26] <jdstrand> arm has a few high numbered syscalls for historical reasons
[12:27] <mvo> jdstrand: aha, excellent, thank you
[12:28] <ogra_> heh, i guess i'm to old ... somehow my brain made int a 16bit thing :)
[12:28] <mvo> jdstrand: yeah, our testing is now much much better with the new code, thanks a bunch for the PR
[12:31] <jdstrand> mvo: ok  github.com/snapcore/snapd/cmd/snap-seccomp99.356s (armhf)
[12:31] <jdstrand> mvo: let me dig up my dragonboard
[12:32] <mvo> jdstrand: thanks a bunch. I'm running the tests in my pi2 currently too, but I gues I could hit ctrl-cl now :)
[12:33] <jdstrand> mvo: you can :)
[12:35] <mvo> jdstrand: all green, thanks a bunch
[12:37] <jdstrand> mvo: I *think* arm64 is going to be ok if I remember previous patches, but will run the tests in classic on there and update the PR. I'll ping you either way
[12:39] <mvo> jdstrand: if its much of a hassle we can merge/upload it and see if the arm64 build still fails
[12:40] <mvo> jdstrand: getting the dragnboard to work I mean
[12:42] <jdstrand> mvo: we may have to do that, give me a few minutes. lights are lit...
[12:47] <jdstrand> mvo: https://github.com/snapcore/snapd/pull/3832#issuecomment-326284730
[12:47] <mup> PR #3832: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3832>
[12:48] <Chipaca> pedronis: I don't remember the state of that
[12:49] <cachio_> Chipaca, https://paste.ubuntu.com/25438314/
[12:49] <cachio_> Chipaca, i have this in a linode machine
[12:50] <Chipaca> cachio_: with shell access?
[12:50] <cachio_> yes
[12:50] <Chipaca> cachio_: PM me the creds?
[12:50] <Chipaca> cachio_: from .spread*
[12:52] <zyga-ubuntu> RE
[12:54] <zyga-ubuntu> mvo: re,
[12:54] <zyga-ubuntu> mvo: I can now push that udev fix
[12:54] <zyga-ubuntu> mvo: and other changes
[12:55] <zyga-ubuntu> mvo: did you do the udev fix already by any chance?
[12:55] <zyga-ubuntu> mwhudson: pushed as agreed earlier
[12:55] <zyga-ubuntu> mwhudson: aha, except that !ff are rejected
[12:56] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3833 is the fix I talked about
[12:56] <mup> PR #3833: interfaces/opengl: use == to compare, not = <Created by zyga> <https://github.com/snapcore/snapd/pull/3833>
[12:57] <mup> PR snapd#3833 opened: interfaces/opengl: use == to compare, not = <Created by zyga> <https://github.com/snapcore/snapd/pull/3833>
[13:00] <niemeyer> Hey!
[13:00] <niemeyer> Will be a couple of mins late. Just finishing the mate
[13:01] <jdstrand> omg
[13:01] <pedronis> mvo: I justed noticed (because zyga didn't delete it), that the link to the contributing guide in the PULL TEMPLATE ends up wrong
[13:01] <zyga-ubuntu> niemeyer: ok
[13:01] <zyga-ubuntu> jdstrand: ?
[13:02] <jdstrand> mvo: the sd card wasn't pushed in all the way :P
[13:02] <mvo> jdstrand: haha
[13:02] <mvo> jdstrand: ok
[13:02] <zyga-ubuntu> jdstrand: LOL
[13:02] <mvo> pedronis: meh, ok
[13:02] <pedronis> we probably need an absolute link there
[13:02] <pedronis> mvo: we get this atm:  https://github.com/snapcore/snapd/pull/CONTRIBUTING.md
[13:03] <mvo> pedronis: ok
[13:03]  * Chipaca omw
[13:03] <jdstrand> mvo: ok, give me a few minutes. I'm in
[13:04] <mvo> jdstrand: great, thanks you
[13:20] <zyga-ubuntu> mwhudson: resolved
[13:20] <ikey> zyga-ubuntu, im gonna have some time again for my PR in the next couple of days so im tempted to withdraw and make new
[13:20] <ikey> so that its logically organised
[13:21] <ikey> haven't been on top of it as much as i woulda liked, sorry, but a ton of stuff going on atm
[13:22] <zyga-ubuntu> ikey: that's okay
[13:22] <zyga-ubuntu> ikey: consider chopping it in pieces that can land separately
[13:22] <ikey> between post solus 3, kernels, budgie 11, mate bits... zonked.
[13:22] <zyga-ubuntu> ikey: small diff >> chance of landing IMO
[13:22] <Son_Goku> morning all
[13:22] <ikey> yeah thats what im thinking
[13:22] <zyga-ubuntu> ikey: thank you for doing this
[13:22] <ikey> the PR is a bit convoluted right now if we're honest
[13:23] <ikey> should be **initial** solus support, then apparmor refinement, then GPU stuff, etc
[13:23] <zyga-ubuntu> ikey: and part of the PR landed through my opensuse work
[13:23] <ikey> oh ok
[13:23] <ikey> hm yeah they'd share some common paths with us
[13:23] <ikey> lib64 bits
[13:23] <zyga-ubuntu> I was very generic
[13:24] <ikey> best way
[13:24] <zyga-ubuntu> I think it will work for you
[13:24] <Son_Goku> niemeyer, did you see my post yesterday evening?
[13:25] <zyga-ubuntu> Son_Goku: we're in a call now, will be done in ~20 min
[13:39] <greyback> hey, I'm trying to get ubuntu core working on my raspberry pi3, but it is hanging when applying my network config (using wifi, it is stuck at 66%)
[13:39] <greyback> what could I do to debug/where can I log a bug?
[13:40] <ogra_> greyback, which image (you need edge/daily)
[13:40] <greyback> ogra_: ah, I'm using stable.
[13:40] <greyback> ok, I'll switch image
[13:40] <ogra_> yeah, dont do that on the pi's
[13:41] <greyback> we should not point to stable on https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3
[13:42] <davidcalle> greyback: why?
[13:43] <ogra_> davidcalle, because the kernels are ancient
[13:43] <ogra_> but we can not point to daily/unstable eithere
[13:43] <greyback> davidcalle: if it doesn't work... or at least admit there may be wifi issues
[13:44] <ogra_> the prob is that we can not upgrade kernels on the pi ... until we have gadget upgrades in snapd
[13:45] <davidcalle> ogra_: IIRC, wifi works after first boot, right?
[13:45] <ogra_> davidcalle, not sure if the old stable kernel even has all firmware included
[13:46] <ogra_> (we could never test it back when that kernel was created because back then netplan was still completely broken)
[13:47] <ogra_> (regarding the brcmfmac driver)
[13:47] <davidcalle> ogra_: ok, let's present the issue on the page then, with both links. Which image do you recommend to get wifi working?
[13:48]  * greyback trying edge, will let you know if it works out of the box
[13:48] <ogra_> davidcalle, daily/edge ... one sec
[13:49] <ogra_> davidcalle, http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ ... (or my images from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/)
[13:49] <zyga-ubuntu> mvo: about the base snaps, let me drive home and let's have the call on telegram
[13:49] <davidcalle> greyback: thanks for testing (at a coworking space today)
[13:49] <zyga-ubuntu> mvo: when would be a comfortable time for you?
[13:50] <greyback> davidcalle: np
[13:50] <mvo> zyga-ubuntu: maybe in ~30-45min?
[13:50] <mvo> zyga-ubuntu: or later
[13:50] <zyga-ubuntu> mvo: that sounds good to me
[13:50] <zyga-ubuntu> 45-60 min
[13:50] <mvo> zyga-ubuntu: sounds good
[13:50] <zyga-ubuntu> I'll be home then
[13:50] <zyga-ubuntu> on my business network :D ^_^
[13:52]  * zyga-ubuntu heads home 
[14:01] <jdstrand> mvo: so, I'm having a number of problems. notably: /usr/lib/go-1.6/pkg/tool/linux_arm64/link: running gcc failed: fork/exec /usr/bin/gcc: cannot allocate memory
[14:03] <greyback> davidcalle: ogra_: edge/daily fixes my wifi issue, all seems to be working well now, thanks!
[14:03] <jdstrand> mvo: but also, the core snap is stuck on r1432. it keeps wanting to reboot, so I do, then it says it needs to reboot. r2781 is present, but I guess it fails to boot, goes back into r1432 and then loops
[14:03] <Chipaca> jdstrand: does setting GOMAXPROCS=1 help the memory issue?
[14:04]  * jdstrand tries
[14:05] <Chipaca> jdstrand: what board is this, btw?
[14:05] <jdstrand> Chipaca: dragonboard
[14:05] <Chipaca> jdstrand: that had a reasonable amount of memory. strange.
[14:06] <niemeyer> Son_Goku: Thanks for the post!
[14:06] <jdstrand> Chipaca: looks like 8G
[14:06] <Chipaca> :-(
[14:06] <jdstrand> oh no
[14:06] <jdstrand> it is 800M
[14:07] <jdstrand> that seems weird
[14:07] <jdstrand> Chipaca: that did not help
[14:07] <mvo> jdstrand: snap version would be nice to kow what is goind on, i.e. why you can't refresh
[14:07] <mvo> jdstrand: 800mb seems a bit on the low side indeed
[14:07] <jdstrand> $ snap version
[14:07] <jdstrand> snap    2.23~201703020745.git.0f2bdc1~ubuntu16.04.1
[14:07] <jdstrand> snapd   2.23~201703020745.git.0f2bdc1~ubuntu16.04.1
[14:07] <jdstrand> series  16
[14:07] <jdstrand> kernel  4.4.0-1049-snapdragon
[14:08]  * jdstrand hadn't booted this in a while
[14:10] <jdstrand> https://developer.qualcomm.com/hardware/dragonboard-410c says it has 1G of memory. so I guess the kernel is taking up the first 200M
[14:12] <Chipaca> jdstrand: any swap? is /tmp a tmpfs?
[14:12] <jdstrand> Chipaca: no swap
[14:12] <Son_Goku> niemeyer, I think I covered everything okay
[14:12] <Chipaca> Son_Goku: niemeyer: is the idea to then have a "amd64 can install amd64, i686, ..., i385" thing?
[14:13] <Chipaca> that'd be awesome
[14:13] <Son_Goku> Chipaca, that's one hope, yes
[14:13] <Son_Goku> in rpm, we have an arch compatibility table that allows for that semi-automagically
[14:14] <Son_Goku> once the architecture name scheme is fixed up, we can rather easily port that table into snapd and allow that
[14:15] <Son_Goku> so like, for example, x86_64 can install x86_64/amd64, i686, i586, ..., i386 and so on
[14:16] <Son_Goku> and armv7hl can install armv7hl, armv6hl, but not armv6hnl or armv7hnl
[14:17] <Chipaca> yeah that sort of thing
[14:17] <Chipaca> i'm sold already :-)
[14:17] <Chipaca> it's going to be a bunch of work though
[14:17] <Son_Goku> yeah
[14:17] <Chipaca> at least
[14:17] <Chipaca> on intel, ia64 and ia32 use different syscalls
[14:17] <Son_Goku> yeah
[14:17] <Chipaca> so seccomp is munged up
[14:17] <Chipaca> i dunno arm
[14:17] <Chipaca> but i expect surprises
[14:18] <Chipaca> still, we've got the former covered already (because you can ship ia32 binaries in ia64 snaps)
[14:18] <Son_Goku> speaking of which, it's somewhat sad how often I get asked if people can run amd64 stuff on their 64-bit x86 machine
[14:18] <mvo> kyrofa: hey, do you know if anything is missing from my side for the snapcraft pr#1420?
[14:18] <Chipaca> Son_Goku: "no, sorry, itanium only"
[14:18] <davidcalle> ogra_: greyback: thanks for the heads up/testing, adding edge to the page with some explanations. Is it the case for Pi2 and Pi3 or just Pi3?
[14:18] <Son_Goku> which is partly why I use "x86_64" as the name, as it's pretty damn generic
[14:19] <Son_Goku> people seem to get that it's Intel or AMD with that name
[14:20] <ogra_> davidcalle, no wlan on pi2 ;)
[14:21] <davidcalle> ogra_: so it doesn't work? :p
[14:21] <ogra_> Son_Goku, but totally historically incorrect :)
[14:21] <ogra_> davidcalle, there is no wlan hardware :)
[14:21] <jdstrand> Chipaca: 'so seccomp is muged up' -- what exactly are you talking about?
[14:21] <jdstrand> munged*
[14:21] <Son_Goku> ogra_, yeah, yeah
[14:21] <Son_Goku> I know AMD invented it
[14:22] <lool> So I have a working image with a signed kernel; I'm trying to test a new kernel without reflashing the device entirely; I get: - Mount snap "joule-linux" (unset) (cannot replace signed kernel snap with an unasserted one)
[14:22] <lool> I guess there's no way to bypass this?
[14:22] <Chipaca> jdstrand: i mean: seccomp rules for ia32 and ia64 are separate (right?)
[14:22] <ogra_> Son_Goku, well, alpha did ... AMD just poiorted it to x86 compatibility
[14:22] <ogra_> *ported
[14:22] <Son_Goku> well yes
[14:23] <Chipaca> lool: why not push the new kernel up, so it gets signed?
[14:23] <Son_Goku> but Linux, the compiler, and several other things call it x86_64
[14:23] <Son_Goku> which just makes the 'amd64' name more confusing
[14:23] <lool> Chipaca: cause I dont have the permissions to do so, it's a canonical signed kernel and I'm not in the right teams
[14:23] <ogra_> Son_Goku, and while i dont really care about the arches i use as a developer ... you have to take familiarity into accoount as well ... users of debian based distros know the other namings ...
[14:24] <Son_Goku> ogra_: IMO, just support both names as aliases to each other
[14:24] <ogra_> i wonder if it would make sense to have a "visible layer" that can be distro specific
[14:24] <lool> this is me testing a kernel change/rebuild, but a partner has the same issue: they need to test a new kernel and they are not Canonical and not in a position to publish a test kernel
[14:24] <ogra_> so endusers see their distro naming ...
[14:24] <Son_Goku> yeah
[14:25] <Son_Goku> if the distro name is known, use that, otherwise fallback to generic name ('x86_64', 'armv7hl', etc.)
[14:25] <jdstrand> Chipaca: what do you mean by ia32 and ia64? do you mean i386 and amd64 in Ubuntu speak?
[14:25] <Son_Goku> x86_32 and x86_64, jdstrand
[14:25] <Son_Goku> so, yes
[14:26] <Son_Goku> i686 and x86_64 / i386 and amd64
[14:26] <Chipaca> jdstrand: we were talking about amd64 vs i[3456]86
[14:26] <jdstrand> ok
[14:26] <Chipaca> so i used ia32 for the latter
[14:26] <jdstrand> so, there is a syscall table for each architecture
[14:26] <Son_Goku> ia64 unfortunately is Itanium
[14:26] <Chipaca> ouch :-)
[14:26] <Chipaca> sorry then
[14:26] <jdstrand> the names of the syscalls are usually the same,but some architectures have different names
[14:27] <jdstrand> for amd64, it also supports compat syscalls for i386
[14:27] <Chipaca> lool: I'm not sure (maye noise][ can add info here), but do you need to be canonical to push kernels at all? I'd imagine you'd trigger a manual review, but other than that it should work?
[14:27] <Chipaca> lool: i mean, you can't push a canonical kernel, but you can push a lool kernel surely?
[14:27] <jdstrand> so while the names are the same (eg, 'read'), the syscall number in the kernel is different
[14:27] <jdstrand> $ scmp_sys_resolver -a x86_64 open
[14:27] <jdstrand> 2
[14:28] <jdstrand> $ scmp_sys_resolver -a x86 open
[14:28] <jdstrand> 5
[14:28] <ogra_> Son_Goku, also your argument about raspbians armhf is a bit moot given they break the standard with that to (falsely) have users be able to use the normal debian rachive alongside
[14:28] <jdstrand> Chipaca: so, technically, 'yes' things are different, but how we write our policy, it doesn't matter
[14:28] <ogra_> armhf is always 'armv7hl' ...
[14:28] <Son_Goku> ogra_, the 'why' is beside the point
[14:28] <ogra_> that has been pretty much standardized when we started it
[14:29] <jdstrand> Chipaca: we write our policy, we include all the relevant syscalls for the architectures
[14:29] <Son_Goku> the point I was trying to illustrate is that base arch names are too coarse
[14:29] <jdstrand> Chipaca: eg, all the policy has 'open', but it has *both* getfid and getgid32
[14:29] <Son_Goku> and can be arbitrary or redefined
[14:29] <jdstrand> err, getgid and getgid32
[14:29] <ogra_> you cant really punish everyone just because an outsider distro decided to break it
[14:29] <ogra_> (against better advise actually)
[14:29] <Son_Goku> ogra_: can it really be considered an outsider distro any more than Ubuntu is to Debian?
[14:30] <Son_Goku> also, that's a shitty argument to make to begin with
[14:30] <Chipaca> jdstrand: right, and that's the kind of fiddly thing i'd imagine we'd have to loop around to support running two slightly different flavour of arm binaries in the same snappy system
[14:30] <jdstrand> Chipaca: if a syscall that we specify doesn't exist on an arch, we ignore it. so set_tls only exists on arm, but it is in the default template, so on amd64 set_tls is ignred
[14:30] <Son_Goku> ogra_, and this is not even really punishing anyone
[14:30] <ogra_> measured by userbase and amount of derivatives ? ... yeah
[14:30] <Son_Goku> as it is today, even Fedora's ecosystem can't properly handle this
[14:30] <Chipaca> jdstrand: ah, i didn't realise we shipped everything everywhere, that might make it easier
[14:30] <Son_Goku> because we do have derivatives that do this
[14:30] <jdstrand> Chipaca: so... adding other architectures is easy-- if there are other syscalls (there wouldn't be terribly many-- most syscall names are shared), we just add them to the appropriate interface
[14:31] <ogra_> Son_Goku, that is why we tired to form a standard back then ...
[14:31] <Chipaca> yup
[14:31] <ogra_> across distros actually
[14:31] <Chipaca> jdstrand: i get that it wouldn't be a lot of work, but i see it as fiddly work (that i'd be terrible at)
[14:31] <Son_Goku> well, I was around during the arm bootstraps for these, and I don't recall such a thing happening
[14:31] <jdstrand> Chipaca: so to bring on itanium, if execve was execve_itanium, then we just add execve_itanium to the default template
[14:31] <Son_Goku> the rpm guys reached out to arm to actually figure out how to do it
[14:31] <Son_Goku> and we followed their advice
[14:31] <ogra_> somewhere in there https://lists.linaro.org/pipermail/cross-distro/
[14:32] <jdstrand> Chipaca: sure. that is something I could help with
[14:32] <Son_Goku> anyway, g2g to work
[14:32] <Son_Goku> bbs as Pharaoh_Atem
[14:32] <jdstrand> it isn't as fiddly as you might think
[14:32] <Chipaca> jdstrand: i stopped listening after you promised to do the work yourself
[14:32] <Chipaca> =D
[14:32] <jdstrand> because I have the entire list of syscalls for all architectures that Ubuntu builds in ./cmd/snap-confine/README.syscalls
[14:33] <Chipaca> jdstrand: aha, but that's the thing, we're talking about arch flavours we _don't_ currently build in
[14:33] <jdstrand> and there are only a few arch-specific syscalls
[14:33] <Chipaca> but yeah, i get that there wouldn't be a lot of variation
[14:33] <jdstrand> Chipaca: I understand. there is nothing saying we can't add to that
[14:33] <Chipaca> like, maybe armv7potato adds one or two
[14:33] <jdstrand> maybe
[14:33] <Chipaca> over basic armv7whatever that we currently have
[14:33] <jdstrand> unlikely, but not impossible
[14:34] <Chipaca> also why am i, like, suddenly using "like"
[14:34]  * Chipaca eyes his boys with suspicion
[14:34] <jdstrand> it is actually probably more possible with arm kernels, since there are so many and they are heavily patched, but it's easy t see when something goes wrong
[14:35] <jdstrand> importantly though, the arch needs to be supported by libseccomp
[14:35] <jdstrand> (and I guess the go one, if it doesn't use libseccomp)
[14:35] <cachio_> mvo, did you trigger snapd in update_excuses?
[14:35] <jdstrand> otherwise you end up with 'unknown syscall'
[14:35] <cachio_> I don't see it
[14:37] <mvo> cachio_: I didn't, let me check the status
[14:37] <mvo> cachio_: do you see any errors/regressions there?
[14:39] <lool> Chipaca: hmm I'll try uploading then
[14:41] <jdstrand> mvo, Chipaca: ok, I removed several snap revisions, upgrade the dragon-board kernel and was able to refresh core to 2776
[14:41] <jdstrand> so, that part is resolved
[14:42]  * jdstrand tries to wrestle with the testsuite and memory
[14:43] <lool> Chipaca: so type: kernel snap goes to manual review queue
[14:43] <Chipaca> lool: ok, so now you need to request a manual review
[14:43] <Chipaca> (there's a button in there for that)
[14:43] <lool> yeah, that's automatic
[14:44] <Chipaca> it is? it used to be that you had to hit the button
[14:44] <Chipaca> but ok
[14:44] <lool> I have a button to remove it from the queue and I got an email telling me it is going into manual review queue
[14:45] <Chipaca> mvo: ping?
[14:45] <jdstrand> oh, I should use my swaps snap
[14:45] <mvo> Chipaca: pong
[14:45] <Chipaca> mvo: who'd be best for reviewing lool's kernel snap?
[14:45] <jdstrand> or is that core config now...
[14:45] <pedronis> mvo: rereviewed a couple of your PRs
[14:46] <mvo> Chipaca: a good question, what is jdstrand opinion here?
[14:46] <jdstrand> I can do it
[14:47] <mvo> ta
[14:47] <Chipaca> mvo: while he answers that, should ubuntu-16.04/snap-confine.maintscript be in 14.04 also?
[14:47] <mvo> pedronis: thank you
[14:47] <jdstrand> done
[14:47] <Chipaca> lool: done ^
[14:47] <Chipaca> jdstrand: thanks :-)
[14:47] <mvo> Chipaca: we don't need it there because we do not do the conffine rename in trusty for apparmor
[14:47] <jdstrand> lool: if you upload another revision, ping me. the store needs an update to pass automated review
[14:48] <mvo> Chipaca: we could add it to trusty too though just to have a smaller delta
[14:48] <Chipaca> mvo: do maintscripts support comments?
[14:48] <lool> thanks
[14:48] <jdstrand> lool: are you aware of the 'joule-linux' snap?
[14:48] <Chipaca> mvo: (are they just shell scripts?)
[14:49] <lool> jdstrand: well that's the snap I've forked from
[14:49] <jdstrand> I see
[14:49] <jdstrand> ok
[14:49] <lool> I dont think this approach scales well for kernel development on top of UC
[14:49] <lool> (I realize UC is not really meant to be a devel platform)
[14:49] <lool> - Mount snap "joule-linux-lool" (1) (cannot replace kernel snap with a different one)
[14:49] <jdstrand> lool: it doesn't. there is model assertion work that needs to be done
[14:49] <lool> so I can't switch kernels either
[14:49] <Chipaca> lool: oh drat
[14:50] <ogra_> dont rename it
[14:50] <pedronis> jdstrand: we did some of that work,  we need to sync up on what is missing
[14:50] <pedronis> jdstrand: I mean model assertion work
[14:50]  * jdstrand nods
[14:51] <jdstrand> pedronis: really, I just need to be told when to change the review tools
[14:51] <cachio_> mvo, I don't see an entry for snapd
[14:51] <jdstrand> pedronis: as in, if it is now safe for anyone to upload kernels and gadgets, I can remove the check
[14:51] <mvo> cachio_: there is one file for each distro release, let me check. for example http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#snapd does not has any autopkgtest runs yet it seems
[14:52] <mvo> cachio_: aha, its missing in artful because it already promoted from artful-proposed to artful
[14:52] <pedronis> Chipaca: well that's part of the work that should let us drop the manual reviews
[14:52] <pedronis> you cannot have but the kernel in your model assertion
[14:53] <pedronis> and that kernel publisher needs to match the model as well
[14:53] <jdstrand> ogra_: looking at the core snap configure hook, I don't see anything for swaps. I thought I remembered that was going to happen. am I misremembering?
[14:53]  * jdstrand is not blocked and installs his 'swaps' snap
[14:53] <ogra_> jdstrand, we have the backend but no config hook
[14:53] <Chipaca> pedronis: ah :-(
[14:53] <Chipaca> lool: see what pedronis is saying ^
[14:53] <Chipaca> so hacking it by hand isn't going to work either
[14:53] <Chipaca> so, bottom line: no, you can't
[14:53] <Chipaca> not right now
[14:53] <ogra_> ogra@bbb:~$ cat /etc/default/swapfile
[14:53] <ogra_> FILE=/var/tmp/swapfile.swp
[14:53] <ogra_> SIZE=0
[14:53] <Chipaca> not yet
[14:53] <Chipaca> no
[14:53] <ogra_> jdstrand, ^^^^
[14:54] <ogra_> jdstrand, if you set it != 0 it creates a swapfile
[14:54] <cachio_> mvo,
[14:54] <pedronis> Chipaca: if you want to swap kernels around you need to start with a sideloaded kernel
[14:54] <jdstrand> Chipaca: size is bytes?
[14:54] <cachio_> mvo, ok
[14:54] <Chipaca> ogra_: potatoes
[14:54] <pedronis> at least that's the current status
[14:54]  * ogra_ tries to remember ... 
[14:54] <ogra_> ... looking at the code
[14:55] <ogra_> jdstrand, MB http://paste.ubuntu.com/25438844/
[14:55] <cachio_> mvo, so, manual tests passed
[14:56] <cachio_> just missing update_excuses now to finish the sru
[14:57] <mvo> cachio_: yay for passing tests, thank you! you mean you miss the output of the autopgktest in update_excuses ? or am I missunderstanding?
[14:57] <jdstrand> ogra_: thanks
[14:57] <cachio_> mvo, yes
[14:57] <Chipaca> mvo: but, i mean, "snap-confine.maintscript"?
[14:57] <lool> pedronis, Chipaca: So just to share this specific context: this is a partner trying to do the right thing of targeting UC from day one as to avoid developing on classic and moving to UC for production at the end of the devel cycle and running into tons of issues; this means we either currently require classic for devel iterations, or that the CI process has to be architectured around image builds and image tests which is heavier than local iterations with
[14:57] <Chipaca> mvo: there's also a snapd.maintscript
[14:58] <Chipaca> lool: cut off at "local iterations wit"
[14:58] <mvo> cachio_: sounds like we just need to be patient
[14:58] <cachio_> mvo, yes, almost there
[14:58] <mvo> Chipaca: correct, we used to ship snap-confine as its own package
[14:58] <pedronis> lool: as I said if they make an image with a sideloaded kernel they can be able to swap it around, but I'm not sure what's their starting point here
[14:58] <mvo> cachio_: great, thanks a lot for the quick validation
[14:59] <Chipaca> lool: so, you start with their own kernel, in their model
[14:59] <pedronis> swap it around in development I mean
[14:59] <Chipaca> lool: and then they can refresh it and everything just fine (once they're into the whitelist for reviews)
[14:59] <lool> pedronis: I was trying to start from a working signed image, but if a sideloaded kernel in an image allows more sideloading, I guess that might be enough
[15:00] <pedronis> but I'm not sure why didn't start with a development model assertion
[15:00] <lool> I think I'll rebuild the official image with the official kernel minus its assertions to get the effect of sideloading but the same image contents
[15:00] <pedronis> anyway
[15:00] <lool> what's a development model assertion?
[15:00] <pedronis> just a model assertion with their name for stuff
[15:00] <pedronis> but they can sideload it
[15:00] <lool> right
[15:00] <pedronis> until they have stuff in the store
[15:00] <lool> well it's a long story
[15:00] <Pharaoh_Atem> back
[15:01]  * Pharaoh_Atem sighs
[15:01] <lool> with things delivered across multiple partner teams and canonical teams
[15:01] <pedronis> lool: just trying to explain what is possible atm
[15:01] <lool> pedronis: yup, thanks
[15:01] <lool> and I'm also learning what good devel cycles we can use in the process
[15:01] <Pharaoh_Atem> mvo: do you have any idea when we're going to see 2.28 with base snap support and stuff?
[15:02] <jdstrand> ogra_: fyi $ cat /etc/default/swapfile
[15:02] <jdstrand> FILE=/var/tmp/swapfile.swp
[15:02] <jdstrand> SIZE=512
[15:02] <jdstrand> ogra_: I rebooted and no swap file
[15:02]  * jdstrand googles for other setup
[15:03] <mvo> Pharaoh_Atem: I need to convince zyga to accept 3625, then very basic base snap support should be ready, I will try my best for today
[15:03] <jdstrand> ogra_: /etc/systemd/system/swapfile.service isn't on the device
[15:04] <jdstrand> ogra_: /usr/bin/mkswapfile is
[15:04] <jdstrand> ogra_: looks like https://bugs.launchpad.net/snappy/+bug/1560942 is only fix committed for ubuntu-core-config
[15:04] <mup> Bug #1560942: Support swap <snapd:Invalid> <Snappy:In Progress by ogra> <ubuntu-core-config (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1560942>
[15:05] <ogra_> jdstrand, hmm https://github.com/snapcore/core-build/tree/master/config/etc/systemd/system
[15:06] <jdstrand> ogra_: dpkg.list says 0.6.40+ppa46 is installed
[15:06] <ogra_> ogra@bbb:~$ ls /etc/systemd/system/swapfile.service
[15:06] <ogra_> /etc/systemd/system/swapfile.service
[15:06] <ogra_> thats on edge though
[15:06] <jdstrand> I'm on candidate
[15:07] <ogra_> ah
[15:07] <jdstrand> r2776
[15:07] <jdstrand> but, the fix was supposedly in ppa41, and this has ppa46
[15:08] <ogra_> which is actually the latest package
[15:09] <ogra_> and definitely ships /etc/systemd/system/swapfile.service here for me
[15:09] <ogra_> (it isnt enabled though ... you need to do that manually atm)
[15:10] <jdstrand> sudo systemctl list-unit-files|grep swap
[15:10] <ogra_> jdstrand, what arch/device is that
[15:10] <jdstrand> only swap.target
[15:10] <jdstrand> dragonboard
[15:11] <ogra_> very weird ... there is nothing arch specific about this file
[15:11] <jdstrand> ogra_: it isn't on my bbb, which is on stable with ppa45
[15:12] <ogra_> hmm, even 45 should have had it ... that really landed a while ago
[15:12] <jdstrand> ogra_: it isn't on my amd64 vm, which is stable with ppa45
[15:13] <ogra_> it landed in ppa41 and had a small change in 42
[15:13] <jdstrand> ogra_: /snap/core/current/etc/systemd/system/swapfile.service exists (amd64)
[15:13] <ogra_> right, my bbb on armhf has it too
[15:14] <jdstrand> /etc/systemd/system/swapfile.service does not exist
[15:14] <jdstrand> these are all just normal upgraded machines
[15:15] <ogra_> well, it only exists on core ...
[15:15] <ogra_> and it is shipped by the squashfs
[15:15] <jdstrand> these are all core devices
[15:15] <jdstrand> dragnboard, bbb, the amd64 vm
[15:17] <ogra_> ogra@nanopi-air:~$ grep systemd/system /etc/system-image/writable-paths
[15:17] <ogra_> /etc/systemd/system                     auto                    persistent  transition  none
[15:17] <ogra_> /etc/systemd/system.conf.d              auto                    persistent  transition  none
[15:17] <ogra_> thats the issue ....
[15:17] <ogra_> "transition"
[15:17]  * ogra_ points to http://manpages.ubuntu.com/manpages/xenial/man5/writable-paths.5.html 
[15:17] <jdstrand> ah
[15:17] <ogra_> i suspect we'd need to "synced"
[15:18] <ogra_> *need to switch to
[15:18] <jdstrand> yeah, these are all pretty old machines
[15:18] <jdstrand> so, I'm not blocked or anything
[15:19] <ogra_> mvo, what do you pothink about switching /etc/systemd/system to "synced2 intead of "transition" ... so new systemd units from the squashfs get actually copied in place on updates ?
[15:19] <ogra_> s/pothink/think/
[15:19] <jdstrand> I guess I could just cp that file into place...
[15:19] <ogra_> yes, you can
[15:20] <ogra_> but we want users to recieve such changes automatically i guess :)
[15:21] <jdstrand> yeah
[15:21] <jdstrand> ok, if I copy it, enable it and start it, I have a swap
[15:21] <ogra_> cool, so it works as intended
[15:21] <mvo> ogra_: yeah, lets try it
[15:21] <ogra_> i''m a bit scared of braking something though
[15:22] <ogra_> but i cant put my finger on any clear breakage that could happen
[15:24] <mvo> ogra_: this definitely needs to get tested carefully, I guess the risk is that we can never remove files from synced dirs
[15:25] <jdstrand> another option would be to update the core snap to copy the file into placec
[15:25] <jdstrand> place
[15:26] <jdstrand> (eg, in configure hook on upgrade)
[15:27] <mup> PR core-build#17 opened: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>
[15:27] <jdstrand> the core-support interface would need to be updated for that
[15:27] <jdstrand> but I see you are going with the other method :)
[15:28] <ogra_> heh
[15:28] <ogra_> yeah, i think we always want new units to be copied if they dont exist in the target dir
[15:28] <jdstrand> it does make sense
[15:28] <jdstrand> we don't have interfaces for adding units
[15:29] <ogra_> which is fine
[15:30]  * jdstrand nods
[15:30] <jdstrand> point I was making is that snaps aren't supposed to be able to interact with systemd directly like that
[15:30] <jdstrand> so, should be good
[15:34] <zyga-ubuntu> testing
[15:36] <mup> PR snapd#3832 closed: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3832>
[15:37] <zyga-ubuntu> mvo: I think I'm online now
[15:38] <zyga-ubuntu> mvo: updated my 1-5KB/s network to 70Mbit
[15:38] <zyga-ubuntu> 76Mbit down, 21 down
[15:43] <Pharaoh_Atem> mvo, zyga-ubuntu, I'm debating on whether I should do 2.27.5 or wait for 2.28
[15:43] <roadmr> zyga-ubuntu: so it's 1400 times faster? that's quite an upgrade.
[15:43] <Pharaoh_Atem> since there's also a snapd-glib update, and I like doing those two together
[15:48] <zyga-ubuntu> roadmr: yes, and no longer the crap consumer type
[15:48] <zyga-ubuntu> Pharaoh_Atem: 2.28 is monday at the earliest
[15:48] <zyga-ubuntu> Pharaoh_Atem: I'd do .5
[15:48]  * zyga-ubuntu notices ipv6 
[15:48] <zyga-ubuntu> oooohh
[15:48]  * zyga-ubuntu looks at the account page
[15:52] <Pharaoh_Atem> zyga-ubuntu: keep in mind no one ever tests the updates to make them go quickly
[15:52] <Pharaoh_Atem> so they sit for a week in updates-testing before shipping out as updates
[15:52] <mup> PR snapcraft#1514 closed: docs: add github processed templates <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1514>
[15:55] <zyga-ubuntu> Pharaoh_Atem: I'd go with .5 because it is more stable (lesser change) than 2.28 which will likely go through the same .1, .2, .3 cycle
[15:56] <zyga-ubuntu> I didn't look at the glib package in a long time
[15:56] <zyga-ubuntu> are you sure that it will work with << 2.28 snapd?
[15:59] <Chipaca> pedronis: question for you, about packaging
[15:59] <jdstrand> mvo: fyi, it will need at least one more syscall for arm64. I have a working test environment now so will send up another pr
[16:00] <pedronis> Chipaca: about packaging? are you sure it's for me ?
[16:00] <Chipaca> pedronis: yes :-)
[16:00] <Chipaca> pedronis: in the 14.04 rules you added a check for a second sha3 sum
[16:00] <pedronis> I added it in both places
[16:00] <pedronis> or so I hope
[16:00] <Chipaca> pedronis: but in 14.04 you didn't bump the check on how many sha3 sums there are in total
[16:01] <pedronis> oh
[16:01] <Chipaca> pedronis: would it be safe to assume that they need to be the same :-)
[16:01] <pedronis> yes
[16:01] <Chipaca> ok then
[16:01] <pedronis> I wonder how tests pass though
[16:01] <pedronis> ah, it's autopkgtest
[16:01] <pedronis> that use that
[16:01] <pedronis> we don't have 14.04 autopkgtests
[16:01] <pedronis> I mean in the travis runs
[16:02] <jdstrand> mvo: ok, just one: https://github.com/snapcore/snapd/pull/3834
[16:02] <Chipaca> pedronis: we don't run the package tests in travis
[16:02] <mup> PR #3834: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
[16:02] <Chipaca> pedronis: we explicitly skip 'em
[16:02] <mup> PR snapd#3834 opened: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
[16:02] <pedronis> Chipaca: well they use packaging enough to be upset if that is not set right
[16:03] <pedronis> that's how I re-learned about that
[16:03] <pedronis> fwiw
[16:03] <Chipaca> pedronis: i don't follow
[16:03] <Chipaca> pedronis: it was a different checksum before?
[16:04] <Chipaca> hash, not checksum, ykwim
[16:04] <pedronis> Chipaca: all the autopkgtest in travis were failing when -eq was still 1 for 16.04
[16:04] <Chipaca> pedronis: autopkgtest yes, travis no
[16:04] <pedronis> ah
[16:04]  * zyga-ubuntu has 1TB data cap a month now
[16:04] <pedronis> now understand
[16:04] <pedronis> sorry
[16:04] <Chipaca> no prob
[16:04] <pedronis> I mean the CI tests kicked from github
[16:05] <pedronis> yes, the autopkgtest don't go through travis
[16:05]  * Chipaca continues looking at the diff
[16:05] <Chipaca> pedronis: thank you
[16:05] <pedronis> but we don't have 14.04 autopktest there
[16:06] <pedronis> Chipaca: fwiw the 2nd hash is the 'generic' authority models key
[16:06] <mvo> jdstrand: thanks a bunch
[16:08] <pedronis> Chipaca: does this mean we want some kind of shared  common.mk file ?
[16:08] <pedronis> or that we need a 14.04 autopkgtest ?
[16:08] <Chipaca> pedronis: I think we never got the 14.04 autopkgtest to work, but i'm not sure
[16:08] <jdstrand> mvo: np
[16:12] <Chipaca> zyga-ubuntu: how would you best describe snap.mount.service?
[16:13] <Chipaca> zyga-ubuntu: i'm going with “trusty needs this to make /snap rshared” but let me know if that could be made clearer
[16:17] <mup> PR snapcraft#1520 opened: tour: remove the tour assets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1520>
[16:18]  * zyga-ubuntu reinstalls xenial
[16:21] <zyga-ubuntu> actually, I should talk to mvo and I need to do a backup anyway
[16:22] <zyga-ubuntu> mvo: would you like to talk about that base snap branch?
[16:26] <Chipaca> what's the right way for a postinst to alert the user about something?
[16:26] <Chipaca> “echo” is probably not it
[16:30] <zyga-ubuntu> eh, deja-dup doesn't work on artful
[16:47] <Chipaca> zyga-ubuntu: neither does curl
[16:47] <zyga-ubuntu> Chipaca: really?!
[16:47] <zyga-ubuntu> Chipaca: I'm hand-backing up stuff now
[16:47] <Chipaca> well, not properly :-)
[16:47] <Chipaca> zyga-ubuntu: like a caveman!
[16:48] <Chipaca> zyga-ubuntu: we found that out yesterday digging into some weirdness sergiusens came across
[16:48]  * zyga-ubuntu is tempted to boot tumbleweed on his laptpo 
[16:48] <Chipaca> zyga-ubuntu: in the old “curl -N -0 -s --unix-socket /run/snapd.socket http:/v2/<blah>” you need to add another /v2 for it to work
[16:48] <Chipaca> O
[16:49] <Chipaca> I'd imagine /// instead of /v2 would also do the job
[16:49] <zyga-ubuntu> why another /v2
[16:49] <Chipaca> zyga-ubuntu: well, we were writing /v2/snap and the server was only getting /snap
[16:49] <zyga-ubuntu> oood?
[16:49] <zyga-ubuntu> why
[16:49] <Chipaca> zyga-ubuntu: because, curl is broken on artful? QED
[16:50] <zyga-ubuntu> yeah, I'm just trying to figure out what kind of feature would chop /v2
[16:50] <Chipaca> the docs say nothing about having to add more stuff, and it's documented everywhere as just http:<path> when using a unix socket
[16:51] <Chipaca> sergiusens: did you file that bug btw?
[16:53]  * zyga-ubuntu steps out for the backup to continue
[17:16] <mvo> Chipaca: re altering users in postinst> what do you want to alert about? there is no really good way, you can select debconf (which users may not see) or using a user notification (https://wiki.ubuntu.com/InteractiveUpgradeHooks)
[17:16] <mvo> Chipaca: eh, I mean notifying users (not altering them ;)
[17:16] <Chipaca> mvo: there's currently an
[17:16] <Chipaca> 		echo "Please reboot, logout/login or source /etc/profile to have /snap/bin added to PATH."
[17:16] <Chipaca> in the 14.04 postinst
[17:17] <Chipaca> mvo: that sounds like the wrong way to do it, but maybe there's no right way
[17:18] <mvo> Chipaca: all the way are nasty, I think this is ok(ish)
[17:18] <mvo> Chipaca: plus snapd is really optimized at server/cloud in 14.04
[17:18] <mvo> Chipaca: so the kind of user would probably use apt install snapd
[17:18] <mvo> Chipaca: but thanks for looking into it!
[17:19] <Chipaca> ok
[17:32] <zyga-ubuntu> Chipaca: for that I think snap (the command) should do it when running on 14.04 and seeing 3.13 kernel
[17:33] <Chipaca> zyga-ubuntu: why just there? any time it's not in the path would be good
[17:39] <zyga-ubuntu> Chipaca: specifically there because snapd doesn't work before
[17:39] <zyga-ubuntu> Chipaca: not just when it's not on path (that's a separate issue and I don't mind solving it)
[17:39] <Chipaca> zyga-ubuntu: but it does sound like the kind of cheap check we could do always
[17:39] <Chipaca> mvo: vvv for your entertainment
[17:40] <mup> PR snapd#3835 opened: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835>
[17:42] <jdstrand> niemeyer: hey, re https://github.com/snapcore/snapd/pull/3818#issuecomment-326186434, are you saying when I 'Approve changes' I should '+1', or something else?
[17:42] <mup> PR #3818: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818>
[17:43] <niemeyer> jdstrand: The opposite.. just saying +1 as a comment in the PR won't track the review as an actual review
[17:44] <pedronis> jdstrand: you didn't 'Approve Changes' in that one
[17:44] <niemeyer> jdstrand: If you do the approval, comment, or change request (with any comment) via the formal mechanism, we get a summary at the top right, and it's also tracked in the review board
[17:44] <jdstrand> ok
[17:45] <jdstrand> I find it weird how sometimes I see the 'Review Changes' button, but other times I need to go into /files
[17:45] <jdstrand> anyway, understood
[17:45] <jdstrand> "always use the formal method if doing a formal review"
[17:47] <Chipaca> zyga-ubuntu: little reminder about actually +1'ing snapd#3748 if that was your intent
[17:47] <mup> PR #3748: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>
[17:50] <mup> PR snapcraft#1521 opened: python plugin: always record constraints and requirements contents <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1521>
[17:56] <zyga-ubuntu> Chipaca: ack, will do soon-ish
[17:57]  * zyga-ubuntu installs xenial
[17:57] <zyga-ubuntu> this new network is really insanely good
[17:57] <zyga-ubuntu> I just want to get back to stable OS as well
[18:00] <zyga-ubuntu> I'm getting 7MB/s to ubuntu.com archive
[18:00] <zyga-ubuntu> woah
[18:00] <zyga-ubuntu> 10
[18:00] <zyga-ubuntu> 10MB/s for larger downloads
[18:00] <zyga-ubuntu> 11MB/s :D
[18:00] <nacc> is the core-snap's path for a given snap a snap environemtn variable?
[18:00] <zyga-ubuntu> nacc: hmmm
[18:00] <zyga-ubuntu> nacc: can you say that again please?
[18:00] <zyga-ubuntu> nacc: do you want to find the core snap at runtime?
[18:00] <nacc> zyga-ubuntu: i'm trying to 'fake' my classic snap being confined (because i wnat to sure it doesn't happen to have dependencies on the system)
[18:00] <nacc> zyga-ubuntu: that involves not using $PATH, but setting it to some specific values in my snap
[18:00] <nacc> zyga-ubuntu: however, that then means the core snap is not in $PATH :)
[18:00] <nacc> e.g., /snap/core/current/bin, /snap/core/current/usr/bin ,etc
[18:00] <nacc> is /snap/core/current something i can just use? or is it stored in some env variable for portability
[18:00] <zyga-ubuntu> nacc: how is confinement needed for the classic snap?
[18:01] <nacc> zyga-ubuntu: it's not, but i want to ensure only my binaries are used
[18:01] <zyga-ubuntu> nacc: /snap/core/current is reliable
[18:01] <nacc> zyga-ubuntu: e.g., my version of git, not the system git
[18:01] <nacc> zyga-ubuntu: and so i need to manipulate PATH in very specific ways
[18:01] <zyga-ubuntu> ok
[18:01] <nacc> zyga-ubuntu: ok, i htink i can wrap that up then, for now
[18:01] <nacc> zyga-ubuntu: thanks!
[18:02] <zyga-ubuntu> yw!
[18:03] <zyga-ubuntu> backup's done
[18:03]  * zyga-ubuntu wonders what else to check
[18:04] <zyga-ubuntu> making live USB
[18:48] <jdstrand> roadmr: hi! has the reviewers page url changed? https://dashboard.snapcraft.io/dev/snaps/reviewer/ is giving me 404
[18:48] <jdstrand> roadmr: earlier today it worked
[18:54] <jdstrand> roadmr: so, I logged out and back in, then went to 'stores I can access', clicked on Ubuntu and the url is https://dashboard.snapcraft.io/dev/snaps/reviewer/ubuntu/
[18:55] <cachio> niemeyer, about the images with the dependencies installed
[18:55] <cachio> when I have them ready, you will take an screenshot?
[18:55] <jdstrand> roadmr: I wonder if ubuntu/ is the right name since the store is the public snap store, and not specific to ubuntu
[18:56] <jdstrand> roadmr: that is a different conversation though. should I update docs/etc for the new url?
[18:56] <cachio> niemeyer, should I create a PR first?
[18:57] <niemeyer> cachio: I'd prefer to see the spread project updated first, and then we change the images with it
[18:57] <niemeyer> cachio: So we're actually just persisting what we have already automated
[18:57] <cachio> ok, i'll create a PR
[18:58] <jdstrand> niemeyer: is there something wrong with travis? https://travis-ci.org/snapcore/snapd/builds/270480495?utm_source=github_status&utm_medium=notification from https://github.com/snapcore/snapd/pull/3834 doesn't seem to want to start
[18:58] <mup> PR #3834: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>
[18:59] <jdstrand> I already tried a cancel/restart once
[19:00] <niemeyer> jdstrand: Supposed to be fine: https://www.traviscistatus.com/
[19:00] <niemeyer> jdstrand: That works against you, actually..
[19:00] <niemeyer> jdstrand: Puts you back at the end of the queue
[19:01] <niemeyer> jdstrand: We have a limit of 3 concurrent jobs
[19:01] <jdstrand> niemeyer: I thought it might but I rolled the dice since it had been more than hour (maybe closer to two)
[19:01] <jdstrand> ok
[19:01]  * jdstrand stops watching the pot waiting for it to boil
[19:02] <jdstrand> niemeyer: thanks
[19:03] <niemeyer> jdstrand: You can see it here:
[19:03] <niemeyer> jdstrand: https://travis-ci.org/snapcore/snapd/pull_requests
[19:04] <niemeyer> jdstrand: and here: https://travis-ci.org/snapcore/snapcraft/pull_requests
[19:04] <niemeyer> jdstrand: We have quite a few PRs waiting indeed.. two of them running
[19:05] <niemeyer> jdstrand: You seem to be next in line on snapd.
[19:05] <niemeyer> (assuming you don't restart! ;)
[19:13] <mup> PR snapd#3833 closed: interfaces/opengl: use == to compare, not = <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3833>
[19:38]  * zyga-ubuntu reinstalled xenial
[19:38] <zyga-ubuntu> everything works again :)
[19:38] <zyga-ubuntu> time to sleep though
[19:47] <mup> PR snapcraft#1522 opened: catkin plugin: only append PYTHONPATH if set <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1522>
[19:51] <roadmr> jdstrand: hi! hm - there may have been some changes to how stores are accessed, let me check
[19:54] <nessita> jdstrand, hi!
[19:54] <nessita> jdstrand, could you please visit https://dashboard.snapcraft.io/dev/store/list/
[19:54] <nessita> and follow the links for review there?
[19:55] <nessita> jdstrand, we are working on removing the need to "be in a given store" to perform actions related to stores, so we are replacing generic URLs with URLs that have the store-id in it
[19:56] <roadmr> hi nessita hehe
[19:57] <cachio> niemeyer, https://github.com/snapcore/spread-images/pull/9
[19:57] <mup> PR spread-images#9: Install dependencies on the images <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/9>
[19:59] <cachio> niemeyer, I run it and I see this error for debian and opensuse: cannot send project content: remote directory /root/spread is not empty
[19:59] <cachio> the base images are not clean
[20:00] <cachio> niemeyer, I am going to bed now, I am feeling really bad
[20:07] <niemeyer> cachio: Sure thing, have a good rest there and hop you get better soon
[20:13] <jdstrand> nessita: I did that (hence me comment regarding ubuntu/)
[20:13] <jdstrand> I'll update my bookmark and docs
[20:14] <jdstrand> my*
[20:16] <nessita> jdstrand, I'm adding a redirect helper as well, for the deprecated URLs
[20:16] <nessita> jdstrand, sorry for not having that redirect in place before
[20:18] <nessita> jdstrand, regarding the name "ubuntu", that's the store id, and if we want to change it, we have to plan for it (is also the DB id). Regarding docs, please don't put the explicit URL in it, just say "in the dropdown under your name, at the top right corner, click on "stores you can access" and follow the reviewer link"
[20:18] <nessita> jdstrand, because URLs will change again
[20:41] <mup> PR snapcraft#1523 opened: python node: record installed node packages in manifest <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1523>
[20:55] <jdstrand> nessita: ok, thanks
[20:56] <pedronis> niemeyer: nessita: snapd itself doesn't use/send that store id directly, it's a legitimate question whether we want to change it now that is more prominent
[20:58] <nessita> pedronis, I agree
[21:02] <niemeyer> pedronis: You mean the one from the model?
[21:02] <pedronis> niemeyer: is not used in the model
[21:03] <pedronis> I mean it's the implicit default
[21:03] <pedronis> I don't think people have put it directly into models
[21:03] <pedronis> for sure we don't
[21:03] <niemeyer> pedronis: That would be incorrect then?
[21:03] <pedronis> niemeyer: ?
[21:03] <niemeyer> Sorry, I mean
[21:04] <niemeyer> If the store side is assuming "ubuntu" to be a default, it doesn't seem right
[21:05] <pedronis> yes, the store side is doing that, because the main/default store atm  has id ubuntu
[21:05] <pedronis> in the store side
[21:05] <pedronis> snapd simply doesn't send anything to get the default
[21:06] <niemeyer> Yeah, that seems fine.. the default is just the default
[21:06] <niemeyer> The store just shouldn't assume that.. sounds like a simple string change
[21:07] <pedronis> I'll let nessita comment on the simple, but we need a new more neutral name/id then
[21:10] <nessita> niemeyer, is not simple because is also the DB table ID (historic reasons)
[21:11] <nessita> doable, for sure
[21:14] <nessita> niemeyer, pedronis it may hardcoded in some other places, it needs some planning and checking, but doable for sure
[21:14] <nessita> will add an item to our rally agenda
[21:15] <niemeyer> nessita: Ack, not a big deal either as long as this isn't showing anywhere
[21:15] <nessita> pedronis, niemeyer what would be the ideal store id for the main/default store?
[21:22] <pedronis> niemeyer: did you see this comment by jdstrand on the reuse snap-update-ns PR:  https://github.com/snapcore/snapd/pull/3621#discussion_r136437075
[21:23] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[21:23] <niemeyer> pedronis: Not yet, and I need to run out just now to pick kid up in school
[21:23] <niemeyer> Back in a bit
[21:28] <pedronis> nessita: main would be the obvious one, sounds  a Gustavo's question though
[21:29]  * pedronis -> rest
[21:32] <mup> PR snapd#3834 closed: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3834>