/srv/irclogs.ubuntu.com/2017/08/31/#snappy.txt

=== JoshStrobl|AFK is now known as JoshStrobl
=== jamesh_ is now known as jamesh
mupPR snapcraft#1517 closed: vcs: ignore .vscode project settings  <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1517>02:14
zyga-ubuntugood morning05:41
* zyga-ubuntu updates debian snapd to .5 05:58
zyga-ubuntuhello mvo06:01
mupPR 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
mvohey zyga-ubuntu, good morning06:04
mvozyga-ubuntu: how are you? happy about better network :)?06:04
zyga-ubuntumvo: yes, I just installed debian-keyring in a blink of an eye06:05
zyga-ubuntumvo: and that's a welcome sight :)06:05
zyga-ubuntumvo: I'm working on the .5 update for debian06:05
zyga-ubuntumvo: could you please upload the extra tarballs to https://github.com/snapcore/snapd/releases/tag/2.27.506:15
mvozyga-ubuntu: uh, thank you, doing that now. sorry06:20
* zyga-ubuntu is sad to see gustavo remove 2.28 from 381406:23
mvozyga-ubuntu: updated06:23
zyga-ubuntuthank you06:24
mupPR snapd#3812 closed: interfaces: expose bluez interface on classic OS <Created by willdeberry> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3812>06:37
zyga-ubuntuhmm06:57
* zyga-ubuntu tries to wrap his head around the git tree for debian snapd06:57
abeatolool, maybe you know, what is this flash-kernel package?07:18
mvopedronis: 3781 has two +1 and green tests, this can go in, right?07:42
pedronismvo: yes, I think so07:47
mupPR 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>07:53
zyga-ubuntumwhudson: hey08:06
zyga-ubuntumwhudson: around?08:06
mwhudsonzyga-ubuntu: ish08:06
zyga-ubuntumwhudson: so, I looked at other distros but now I'm back to debian08:06
zyga-ubuntumwhudson: how should I approach this? I see git-buildpackage files08:06
zyga-ubuntumwhudson: what is the workflow?08:06
zyga-ubuntumwhudson: I have both the gbp tree and the dst files from .408:07
zyga-ubuntumwhudson: should I import-orig?08:07
mwhudsonzyga-ubuntu: i don't really use gbp much i guess08:07
zyga-ubuntumwhudson: ok, so how do you maintain the git repo at alioth?08:07
mwhudsongit merge 2.27.5; dch; git push i think08:08
mwhudsonoh git commit as well of course :)08:08
zyga-ubuntumwhudson: so merge the snapd upstream repository in this manually?08:08
mwhudsonyeah, i have upstream as a remote08:09
* zyga-ubuntu tries08:09
* zyga-ubuntu tries building08:14
zyga-ubuntumwhudson: thanks, I was approaching this from the wrong angle08:14
zyga-ubuntumwhudson: will you dput if I push it back?08:14
zyga-ubuntumwhudson: reviewdput08:14
zyga-ubuntureview/dput08:14
mwhudsonzyga-ubuntu: yes, tomorrow :)08:14
zyga-ubuntumwhudson: ok08:15
zyga-ubuntumwhudson: I mean, just the changelog08:15
zyga-ubuntuapart from that it was a clean merge08:15
mwhudsonzyga-ubuntu: cool08:15
zyga-ubuntuhttp://paste.ubuntu.com/25437187/08:15
zyga-ubuntumwhudson: I can dput if I have the permissions to do so08:16
mwhudsonzyga-ubuntu: push08:16
mwhudsonpls08:16
zyga-ubuntuk08:16
mwhudson:)08:16
mwhudsonsorry for terseness, a bit tired :)08:16
pedronismvo: what's the plan for 2.28 now?08:18
=== JoshStrobl is now known as JoshStrobl|AFK
zyga-ubuntumwhudson: pushed08:20
mvopedronis: 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 though08:23
pedronismvo: there's one PR by zyga, seems a bit of a stretch to fit it in, unless we want to do it next week08:25
mvopedronis: 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 then08:26
mvopedronis: 2.27.5 in stable hopefully08:26
pedronismvo:  #362108:26
mupPR #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
mvopedronis: aha, yeah, this one looks risky08:26
zyga-ubuntumvo: risky?08:27
mvozyga-ubuntu: well, lots of feedback from jamie, no gustavo review yet, risky in the sense that it may take time to get it in shape08:27
zyga-ubuntumvo: this was reviewed by gustavo already08:28
zyga-ubuntumvo: we did it over a hangout08:28
zyga-ubuntumvo: the feedback I reacted to was actually from gustavo originally08:28
pedronishe should probably vote too for clarity08:28
mvozyga-ubuntu: aha, I don't see anything in the PR itself about this08:28
zyga-ubuntumvo: I'm only worried about one thing: https://github.com/snapcore/snapd/pull/3621#discussion_r13620464608:28
mupPR #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
mvozyga-ubuntu: exactly what pedronis said, hard for others to know that08:28
zyga-ubuntumvo: yes, gustavo didn't comment08:28
pedronisanywway jamie didn't finish his review yesterday08:28
zyga-ubuntumvo: I think I need to talk to jamie about that point as I wasn't planning on confining snap-update-ns yet08:29
mvozyga-ubuntu: aha, ok08:29
zyga-ubuntuit's way further down the line and I don't think this is any less safe08:29
zyga-ubuntu(since snapd already calls it unconfined on interface changes)08:29
mvozyga-ubuntu: right, so that is what I mean with "risky", it seems there are some open points still08:29
mvozyga-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 this08:30
zyga-ubunturight08:30
pedroniswe should be careful not too move thing so much that 2.29 is after the rally08:30
mvopedronis: 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
pedronisyes, I have seen his comment08:31
mvopedronis: good point about the rally08:32
pedronismvo: I suppose if we send   execution where  exit status != 0 to errtracker, losing data is a bit less of an issue08:33
pedronisthe script doesn't change for the same revision08:33
pedronisso as long as we keep enough info to know which revno we *did* run, it should be ok08:33
* zyga-ubuntu reboo/08:33
pedronismvo: less files around would be nicer08:34
stubWould it be possible to make a classic snap that exposes an arbitrary filesystem path to a contained snap via the content interface ?08:34
pedronismvo: then we would renames all files  to r#.ext   as we discussed already08:35
loolabeato: what do you need to know about flash-kernel?08:36
ogra_stub, ICBW but i think classic turns off all interface capabilities08:36
loolabeato: it's an ad hoc way to install kernels on random ARM and other boards08:36
loole.g. in flash, on this or that partition, in this or that format etc.08:36
mvopedronis: aha, excellent plan - so errtracker+simplified logs. I will do that08:37
stuboh, I thought that sort of thing was starting to be allowed to make it easier to transition from classic -> contained.08:37
ogra_that would be quite a security hole08:38
abeatolool, yeah, I was wondering what did it support. uboot only? would it support creating and flashing an android boot partition?08:38
loolabeato: it does support flashing an android style image08:41
loolabeato: see https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/functions search for abootimg08:41
loolabeato: this is how the db entries look like https://anonscm.debian.org/cgit/d-i/flash-kernel.git/tree/db/all.db08:42
loolabeato: search for android in there too08:42
abeatolool, hmm, so to have a new device supported, it would need to be added to that DB08:42
loolabeato: Yes; I think you can override it localy, but the easiest is to edit a .db file to your looking until it works08:45
lool*locally08:45
abeatolool, got it, thanks08:46
loolabeato: note that Ubuntu's and Debian's flash-kernel often have a large delta, but the general concepts and architecture should be the same08:46
abeatolool, ok, noted08:47
mvopedronis: 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:11
pedronismvo: oops, ok09:17
mwhudsoni guess zyga's reboot didn't go so well09:17
mvoyeah, but no worries, I will look into it soon09:17
zygare09:28
* zyga sent kids to the cinema and resumes work09:28
zygamwhudson: sorry for being off, if you are still around just tell me if I shall dput now09:29
mwhudsonzyga: this is splitting hairs a bit but uploaders has me@zygoon.pl but the changelog is @canonical.com09:49
mwhudsonzyga: otherwise looks fine, i assume you've test built it?09:50
zygamwhudson: aw, sorry, shall I amend and force pus>09:50
mwhudsonzyga: pls09:50
zygayes, certainly09:50
zygamwhudson: doing that now09:50
zygamwhudson: edited, let me rebuild ... just in case09:53
zygaI also fixed the local repo config so that the right email gets used in the future09:54
mupPR snapcraft#1519 opened: lxd: use a unique temporary folder <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1519>10:12
* zyga sighs10:18
zygaartful is artfoul for me :/10:18
=== ShalokShalom_ is now known as ShalokShalom
mupPR snapd#3831 opened: store: move device auth endpoint uris to config <Created by atomatt> <https://github.com/snapcore/snapd/pull/3831>11:06
pedronismvo: Chipaca: do you remember what's the state of this:  https://forum.snapcraft.io/t/hashsum-failures-during-tests/198/411:30
jdstrandmvo: you need set_tls11:57
pedronisso fedora is back to flakyness11:57
pedronishttps://travis-ci.org/snapcore/snapd/builds/270368782?utm_source=github_status&utm_medium=notification11:58
jdstrandmvo: syscall=983045. scmp_sys_resolver -a arm 98304511:58
=== rumble is now known as grumble
jdstrandmvo: also, syscall=78, scmp_sys_resolver -a aarch64 78: readlinkat12:00
jdstrandmvo: so, set_tls for armhf and readlinkat for arm6412:03
jdstrandmvo: i386 failure was unrelated to seccomp12:03
jdstrandmvo: with old snap-confine I think we may have limited the architectures we ran the testsuite on, so didn't have the full list12:04
jdstrandmvo: 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_tls12:10
jdstrandmvo: my dragonboard is not readily available, but if you need me to do the same there, I can12:10
mupPR 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:24
jdstrandmvo: that is for you ^ (I'm still checking armhf)12:25
* ogra_ glares at 983045 ... i always thought syscall is an int12:25
jdstrandthat's an int :)12:26
jdstrandarm has a few high numbered syscalls for historical reasons12:26
mvojdstrand: aha, excellent, thank you12:27
ogra_heh, i guess i'm to old ... somehow my brain made int a 16bit thing :)12:28
mvojdstrand: yeah, our testing is now much much better with the new code, thanks a bunch for the PR12:28
jdstrandmvo: ok  github.com/snapcore/snapd/cmd/snap-seccomp99.356s (armhf)12:31
jdstrandmvo: let me dig up my dragonboard12:31
mvojdstrand: thanks a bunch. I'm running the tests in my pi2 currently too, but I gues I could hit ctrl-cl now :)12:32
jdstrandmvo: you can :)12:33
mvojdstrand: all green, thanks a bunch12:35
jdstrandmvo: 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 way12:37
mvojdstrand: if its much of a hassle we can merge/upload it and see if the arm64 build still fails12:39
mvojdstrand: getting the dragnboard to work I mean12:40
jdstrandmvo: we may have to do that, give me a few minutes. lights are lit...12:42
jdstrandmvo: https://github.com/snapcore/snapd/pull/3832#issuecomment-32628473012:47
mupPR #3832: cmd/snap-seccomp/main_test.go: add syscalls for armhf and arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3832>12:47
Chipacapedronis: I don't remember the state of that12:48
cachio_Chipaca, https://paste.ubuntu.com/25438314/12:49
cachio_Chipaca, i have this in a linode machine12:49
Chipacacachio_: with shell access?12:50
cachio_yes12:50
Chipacacachio_: PM me the creds?12:50
Chipacacachio_: from .spread*12:50
zyga-ubuntuRE12:52
zyga-ubuntumvo: re,12:54
zyga-ubuntumvo: I can now push that udev fix12:54
zyga-ubuntumvo: and other changes12:54
zyga-ubuntumvo: did you do the udev fix already by any chance?12:55
zyga-ubuntumwhudson: pushed as agreed earlier12:55
zyga-ubuntumwhudson: aha, except that !ff are rejected12:55
zyga-ubuntumvo: https://github.com/snapcore/snapd/pull/3833 is the fix I talked about12:56
mupPR #3833: interfaces/opengl: use == to compare, not = <Created by zyga> <https://github.com/snapcore/snapd/pull/3833>12:56
mupPR snapd#3833 opened: interfaces/opengl: use == to compare, not = <Created by zyga> <https://github.com/snapcore/snapd/pull/3833>12:57
niemeyerHey!13:00
niemeyerWill be a couple of mins late. Just finishing the mate13:00
jdstrandomg13:01
pedronismvo: I justed noticed (because zyga didn't delete it), that the link to the contributing guide in the PULL TEMPLATE ends up wrong13:01
zyga-ubuntuniemeyer: ok13:01
zyga-ubuntujdstrand: ?13:01
jdstrandmvo: the sd card wasn't pushed in all the way :P13:02
mvojdstrand: haha13:02
mvojdstrand: ok13:02
zyga-ubuntujdstrand: LOL13:02
mvopedronis: meh, ok13:02
pedroniswe probably need an absolute link there13:02
pedronismvo: we get this atm:  https://github.com/snapcore/snapd/pull/CONTRIBUTING.md13:02
mvopedronis: ok13:03
* Chipaca omw13:03
jdstrandmvo: ok, give me a few minutes. I'm in13:03
mvojdstrand: great, thanks you13:04
zyga-ubuntumwhudson: resolved13:20
ikeyzyga-ubuntu, im gonna have some time again for my PR in the next couple of days so im tempted to withdraw and make new13:20
ikeyso that its logically organised13:20
ikeyhaven't been on top of it as much as i woulda liked, sorry, but a ton of stuff going on atm13:21
zyga-ubuntuikey: that's okay13:22
zyga-ubuntuikey: consider chopping it in pieces that can land separately13:22
ikeybetween post solus 3, kernels, budgie 11, mate bits... zonked.13:22
zyga-ubuntuikey: small diff >> chance of landing IMO13:22
Son_Gokumorning all13:22
ikeyyeah thats what im thinking13:22
zyga-ubuntuikey: thank you for doing this13:22
ikeythe PR is a bit convoluted right now if we're honest13:22
ikeyshould be **initial** solus support, then apparmor refinement, then GPU stuff, etc13:23
zyga-ubuntuikey: and part of the PR landed through my opensuse work13:23
ikeyoh ok13:23
ikeyhm yeah they'd share some common paths with us13:23
ikeylib64 bits13:23
zyga-ubuntuI was very generic13:23
ikeybest way13:24
zyga-ubuntuI think it will work for you13:24
Son_Gokuniemeyer, did you see my post yesterday evening?13:24
zyga-ubuntuSon_Goku: we're in a call now, will be done in ~20 min13:25
greybackhey, 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
greybackwhat could I do to debug/where can I log a bug?13:39
ogra_greyback, which image (you need edge/daily)13:40
greybackogra_: ah, I'm using stable.13:40
greybackok, I'll switch image13:40
ogra_yeah, dont do that on the pi's13:40
greybackwe should not point to stable on https://developer.ubuntu.com/core/get-started/raspberry-pi-2-313:41
davidcallegreyback: why?13:42
ogra_davidcalle, because the kernels are ancient13:43
ogra_but we can not point to daily/unstable eithere13:43
greybackdavidcalle: if it doesn't work... or at least admit there may be wifi issues13:43
ogra_the prob is that we can not upgrade kernels on the pi ... until we have gadget upgrades in snapd13:44
davidcalleogra_: IIRC, wifi works after first boot, right?13:45
ogra_davidcalle, not sure if the old stable kernel even has all firmware included13:45
ogra_(we could never test it back when that kernel was created because back then netplan was still completely broken)13:46
ogra_(regarding the brcmfmac driver)13:47
davidcalleogra_: ok, let's present the issue on the page then, with both links. Which image do you recommend to get wifi working?13:47
* greyback trying edge, will let you know if it works out of the box13:48
ogra_davidcalle, daily/edge ... one sec13:48
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-ubuntumvo: about the base snaps, let me drive home and let's have the call on telegram13:49
davidcallegreyback: thanks for testing (at a coworking space today)13:49
zyga-ubuntumvo: when would be a comfortable time for you?13:49
greybackdavidcalle: np13:50
mvozyga-ubuntu: maybe in ~30-45min?13:50
mvozyga-ubuntu: or later13:50
zyga-ubuntumvo: that sounds good to me13:50
zyga-ubuntu45-60 min13:50
mvozyga-ubuntu: sounds good13:50
zyga-ubuntuI'll be home then13:50
zyga-ubuntuon my business network :D ^_^13:50
* zyga-ubuntu heads home 13:52
jdstrandmvo: 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 memory14:01
greybackdavidcalle: ogra_: edge/daily fixes my wifi issue, all seems to be working well now, thanks!14:03
jdstrandmvo: 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 loops14:03
Chipacajdstrand: does setting GOMAXPROCS=1 help the memory issue?14:03
* jdstrand tries14:04
Chipacajdstrand: what board is this, btw?14:05
jdstrandChipaca: dragonboard14:05
Chipacajdstrand: that had a reasonable amount of memory. strange.14:05
niemeyerSon_Goku: Thanks for the post!14:06
jdstrandChipaca: looks like 8G14:06
Chipaca:-(14:06
jdstrandoh no14:06
jdstrandit is 800M14:06
jdstrandthat seems weird14:07
jdstrandChipaca: that did not help14:07
mvojdstrand: snap version would be nice to kow what is goind on, i.e. why you can't refresh14:07
mvojdstrand: 800mb seems a bit on the low side indeed14:07
jdstrand$ snap version14:07
jdstrandsnap    2.23~201703020745.git.0f2bdc1~ubuntu16.04.114:07
jdstrandsnapd   2.23~201703020745.git.0f2bdc1~ubuntu16.04.114:07
jdstrandseries  1614:07
jdstrandkernel  4.4.0-1049-snapdragon14:07
* jdstrand hadn't booted this in a while14:08
=== JanC_ is now known as JanC
jdstrandhttps://developer.qualcomm.com/hardware/dragonboard-410c says it has 1G of memory. so I guess the kernel is taking up the first 200M14:10
Chipacajdstrand: any swap? is /tmp a tmpfs?14:12
jdstrandChipaca: no swap14:12
Son_Gokuniemeyer, I think I covered everything okay14:12
ChipacaSon_Goku: niemeyer: is the idea to then have a "amd64 can install amd64, i686, ..., i385" thing?14:12
Chipacathat'd be awesome14:13
Son_GokuChipaca, that's one hope, yes14:13
Son_Gokuin rpm, we have an arch compatibility table that allows for that semi-automagically14:13
Son_Gokuonce the architecture name scheme is fixed up, we can rather easily port that table into snapd and allow that14:14
Son_Gokuso like, for example, x86_64 can install x86_64/amd64, i686, i586, ..., i386 and so on14:15
Son_Gokuand armv7hl can install armv7hl, armv6hl, but not armv6hnl or armv7hnl14:16
Chipacayeah that sort of thing14:17
Chipacai'm sold already :-)14:17
Chipacait's going to be a bunch of work though14:17
Son_Gokuyeah14:17
Chipacaat least14:17
Chipacaon intel, ia64 and ia32 use different syscalls14:17
Son_Gokuyeah14:17
Chipacaso seccomp is munged up14:17
Chipacai dunno arm14:17
Chipacabut i expect surprises14:17
Chipacastill, we've got the former covered already (because you can ship ia32 binaries in ia64 snaps)14:18
Son_Gokuspeaking of which, it's somewhat sad how often I get asked if people can run amd64 stuff on their 64-bit x86 machine14:18
mvokyrofa: hey, do you know if anything is missing from my side for the snapcraft pr#1420?14:18
ChipacaSon_Goku: "no, sorry, itanium only"14:18
davidcalleogra_: 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_Gokuwhich is partly why I use "x86_64" as the name, as it's pretty damn generic14:18
Son_Gokupeople seem to get that it's Intel or AMD with that name14:19
ogra_davidcalle, no wlan on pi2 ;)14:20
davidcalleogra_: so it doesn't work? :p14:21
ogra_Son_Goku, but totally historically incorrect :)14:21
ogra_davidcalle, there is no wlan hardware :)14:21
jdstrandChipaca: 'so seccomp is muged up' -- what exactly are you talking about?14:21
jdstrandmunged*14:21
Son_Gokuogra_, yeah, yeah14:21
Son_GokuI know AMD invented it14:21
loolSo 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
loolI guess there's no way to bypass this?14:22
Chipacajdstrand: 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 compatibility14:22
ogra_*ported14:22
Son_Gokuwell yes14:22
Chipacalool: why not push the new kernel up, so it gets signed?14:23
Son_Gokubut Linux, the compiler, and several other things call it x86_6414:23
Son_Gokuwhich just makes the 'amd64' name more confusing14:23
=== JoshStrobl|AFK is now known as JoshStrobl
loolChipaca: cause I dont have the permissions to do so, it's a canonical signed kernel and I'm not in the right teams14: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:23
Son_Gokuogra_: IMO, just support both names as aliases to each other14:24
ogra_i wonder if it would make sense to have a "visible layer" that can be distro specific14:24
loolthis 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 kernel14:24
ogra_so endusers see their distro naming ...14:24
Son_Gokuyeah14:24
Son_Gokuif the distro name is known, use that, otherwise fallback to generic name ('x86_64', 'armv7hl', etc.)14:25
jdstrandChipaca: what do you mean by ia32 and ia64? do you mean i386 and amd64 in Ubuntu speak?14:25
Son_Gokux86_32 and x86_64, jdstrand14:25
Son_Gokuso, yes14:25
Son_Gokui686 and x86_64 / i386 and amd6414:26
Chipacajdstrand: we were talking about amd64 vs i[3456]8614:26
jdstrandok14:26
Chipacaso i used ia32 for the latter14:26
jdstrandso, there is a syscall table for each architecture14:26
Son_Gokuia64 unfortunately is Itanium14:26
Chipacaouch :-)14:26
Chipacasorry then14:26
jdstrandthe names of the syscalls are usually the same,but some architectures have different names14:26
jdstrandfor amd64, it also supports compat syscalls for i38614:27
Chipacalool: 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
Chipacalool: i mean, you can't push a canonical kernel, but you can push a lool kernel surely?14:27
jdstrandso while the names are the same (eg, 'read'), the syscall number in the kernel is different14:27
jdstrand$ scmp_sys_resolver -a x86_64 open14:27
jdstrand214:27
jdstrand$ scmp_sys_resolver -a x86 open14:28
jdstrand514: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 alongside14:28
jdstrandChipaca: so, technically, 'yes' things are different, but how we write our policy, it doesn't matter14:28
ogra_armhf is always 'armv7hl' ...14:28
Son_Gokuogra_, the 'why' is beside the point14:28
ogra_that has been pretty much standardized when we started it14:28
jdstrandChipaca: we write our policy, we include all the relevant syscalls for the architectures14:29
Son_Gokuthe point I was trying to illustrate is that base arch names are too coarse14:29
jdstrandChipaca: eg, all the policy has 'open', but it has *both* getfid and getgid3214:29
Son_Gokuand can be arbitrary or redefined14:29
jdstranderr, getgid and getgid3214:29
ogra_you cant really punish everyone just because an outsider distro decided to break it14:29
ogra_(against better advise actually)14:29
Son_Gokuogra_: can it really be considered an outsider distro any more than Ubuntu is to Debian?14:29
Son_Gokualso, that's a shitty argument to make to begin with14:30
Chipacajdstrand: 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 system14:30
jdstrandChipaca: 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 ignred14:30
Son_Gokuogra_, and this is not even really punishing anyone14:30
ogra_measured by userbase and amount of derivatives ? ... yeah14:30
Son_Gokuas it is today, even Fedora's ecosystem can't properly handle this14:30
Chipacajdstrand: ah, i didn't realise we shipped everything everywhere, that might make it easier14:30
Son_Gokubecause we do have derivatives that do this14:30
jdstrandChipaca: 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 interface14:30
ogra_Son_Goku, that is why we tired to form a standard back then ...14:31
Chipacayup14:31
ogra_across distros actually14:31
Chipacajdstrand: 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_Gokuwell, I was around during the arm bootstraps for these, and I don't recall such a thing happening14:31
jdstrandChipaca: so to bring on itanium, if execve was execve_itanium, then we just add execve_itanium to the default template14:31
Son_Gokuthe rpm guys reached out to arm to actually figure out how to do it14:31
Son_Gokuand we followed their advice14:31
ogra_somewhere in there https://lists.linaro.org/pipermail/cross-distro/14:31
jdstrandChipaca: sure. that is something I could help with14:32
Son_Gokuanyway, g2g to work14:32
Son_Gokubbs as Pharaoh_Atem14:32
jdstrandit isn't as fiddly as you might think14:32
Chipacajdstrand: i stopped listening after you promised to do the work yourself14:32
Chipaca=D14:32
jdstrandbecause I have the entire list of syscalls for all architectures that Ubuntu builds in ./cmd/snap-confine/README.syscalls14:32
Chipacajdstrand: aha, but that's the thing, we're talking about arch flavours we _don't_ currently build in14:33
jdstrandand there are only a few arch-specific syscalls14:33
Chipacabut yeah, i get that there wouldn't be a lot of variation14:33
jdstrandChipaca: I understand. there is nothing saying we can't add to that14:33
Chipacalike, maybe armv7potato adds one or two14:33
jdstrandmaybe14:33
Chipacaover basic armv7whatever that we currently have14:33
jdstrandunlikely, but not impossible14:33
Chipacaalso why am i, like, suddenly using "like"14:34
* Chipaca eyes his boys with suspicion14:34
jdstrandit 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 wrong14:34
jdstrandimportantly though, the arch needs to be supported by libseccomp14: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
jdstrandotherwise you end up with 'unknown syscall'14:35
cachio_I don't see it14:35
mvocachio_: I didn't, let me check the status14:37
mvocachio_: do you see any errors/regressions there?14:37
loolChipaca: hmm I'll try uploading then14:39
jdstrandmvo, Chipaca: ok, I removed several snap revisions, upgrade the dragon-board kernel and was able to refresh core to 277614:41
jdstrandso, that part is resolved14:41
* jdstrand tries to wrestle with the testsuite and memory14:42
loolChipaca: so type: kernel snap goes to manual review queue14:43
Chipacalool: ok, so now you need to request a manual review14:43
Chipaca(there's a button in there for that)14:43
loolyeah, that's automatic14:43
Chipacait is? it used to be that you had to hit the button14:44
Chipacabut ok14:44
loolI have a button to remove it from the queue and I got an email telling me it is going into manual review queue14:44
Chipacamvo: ping?14:45
jdstrandoh, I should use my swaps snap14:45
mvoChipaca: pong14:45
Chipacamvo: who'd be best for reviewing lool's kernel snap?14:45
jdstrandor is that core config now...14:45
pedronismvo: rereviewed a couple of your PRs14:45
mvoChipaca: a good question, what is jdstrand opinion here?14:46
jdstrandI can do it14:46
mvota14:47
Chipacamvo: while he answers that, should ubuntu-16.04/snap-confine.maintscript be in 14.04 also?14:47
mvopedronis: thank you14:47
jdstranddone14:47
Chipacalool: done ^14:47
Chipacajdstrand: thanks :-)14:47
mvoChipaca: we don't need it there because we do not do the conffine rename in trusty for apparmor14:47
jdstrandlool: if you upload another revision, ping me. the store needs an update to pass automated review14:47
mvoChipaca: we could add it to trusty too though just to have a smaller delta14:48
Chipacamvo: do maintscripts support comments?14:48
loolthanks14:48
jdstrandlool: are you aware of the 'joule-linux' snap?14:48
Chipacamvo: (are they just shell scripts?)14:48
looljdstrand: well that's the snap I've forked from14:49
jdstrandI see14:49
jdstrandok14:49
loolI dont think this approach scales well for kernel development on top of UC14: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
jdstrandlool: it doesn't. there is model assertion work that needs to be done14:49
loolso I can't switch kernels either14:49
Chipacalool: oh drat14:49
ogra_dont rename it14:50
pedronisjdstrand: we did some of that work,  we need to sync up on what is missing14:50
pedronisjdstrand: I mean model assertion work14:50
* jdstrand nods14:50
jdstrandpedronis: really, I just need to be told when to change the review tools14:51
cachio_mvo, I don't see an entry for snapd14:51
jdstrandpedronis: as in, if it is now safe for anyone to upload kernels and gadgets, I can remove the check14:51
mvocachio_: 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 seems14:51
mvocachio_: aha, its missing in artful because it already promoted from artful-proposed to artful14:52
pedronisChipaca: well that's part of the work that should let us drop the manual reviews14:52
pedronisyou cannot have but the kernel in your model assertion14:52
pedronisand that kernel publisher needs to match the model as well14:53
jdstrandogra_: 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' snap14:53
ogra_jdstrand, we have the backend but no config hook14:53
Chipacapedronis: ah :-(14:53
Chipacalool: see what pedronis is saying ^14:53
Chipacaso hacking it by hand isn't going to work either14:53
Chipacaso, bottom line: no, you can't14:53
Chipacanot right now14:53
ogra_ogra@bbb:~$ cat /etc/default/swapfile14:53
ogra_FILE=/var/tmp/swapfile.swp14:53
ogra_SIZE=014:53
Chipacanot yet14:53
Chipacano14:53
ogra_jdstrand, ^^^^14:53
ogra_jdstrand, if you set it != 0 it creates a swapfile14:54
cachio_mvo,14:54
pedronisChipaca: if you want to swap kernels around you need to start with a sideloaded kernel14:54
jdstrandChipaca: size is bytes?14:54
cachio_mvo, ok14:54
Chipacaogra_: potatoes14:54
pedronisat least that's the current status14:54
* ogra_ tries to remember ... 14:54
ogra_... looking at the code14:54
ogra_jdstrand, MB http://paste.ubuntu.com/25438844/14:55
cachio_mvo, so, manual tests passed14:55
cachio_just missing update_excuses now to finish the sru14:56
mvocachio_: yay for passing tests, thank you! you mean you miss the output of the autopgktest in update_excuses ? or am I missunderstanding?14:57
jdstrandogra_: thanks14:57
cachio_mvo, yes14:57
Chipacamvo: but, i mean, "snap-confine.maintscript"?14:57
loolpedronis, 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 with14:57
Chipacamvo: there's also a snapd.maintscript14:57
Chipacalool: cut off at "local iterations wit"14:58
mvocachio_: sounds like we just need to be patient14:58
cachio_mvo, yes, almost there14:58
mvoChipaca: correct, we used to ship snap-confine as its own package14:58
pedronislool: 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 here14:58
mvocachio_: great, thanks a lot for the quick validation14:58
Chipacalool: so, you start with their own kernel, in their model14:59
pedronisswap it around in development I mean14:59
Chipacalool: and then they can refresh it and everything just fine (once they're into the whitelist for reviews)14:59
loolpedronis: 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 enough14:59
pedronisbut I'm not sure why didn't start with a development model assertion15:00
loolI think I'll rebuild the official image with the official kernel minus its assertions to get the effect of sideloading but the same image contents15:00
pedronisanyway15:00
loolwhat's a development model assertion?15:00
pedronisjust a model assertion with their name for stuff15:00
pedronisbut they can sideload it15:00
loolright15:00
pedronisuntil they have stuff in the store15:00
loolwell it's a long story15:00
Pharaoh_Atemback15:00
* Pharaoh_Atem sighs15:01
loolwith things delivered across multiple partner teams and canonical teams15:01
pedronislool: just trying to explain what is possible atm15:01
loolpedronis: yup, thanks15:01
looland I'm also learning what good devel cycles we can use in the process15:01
Pharaoh_Atemmvo: do you have any idea when we're going to see 2.28 with base snap support and stuff?15:01
jdstrandogra_: fyi $ cat /etc/default/swapfile15:02
jdstrandFILE=/var/tmp/swapfile.swp15:02
jdstrandSIZE=51215:02
jdstrandogra_: I rebooted and no swap file15:02
* jdstrand googles for other setup15:02
mvoPharaoh_Atem: I need to convince zyga to accept 3625, then very basic base snap support should be ready, I will try my best for today15:03
jdstrandogra_: /etc/systemd/system/swapfile.service isn't on the device15:03
jdstrandogra_: /usr/bin/mkswapfile is15:04
jdstrandogra_: looks like https://bugs.launchpad.net/snappy/+bug/1560942 is only fix committed for ubuntu-core-config15:04
mupBug #1560942: Support swap <snapd:Invalid> <Snappy:In Progress by ogra> <ubuntu-core-config (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1560942>15:04
ogra_jdstrand, hmm https://github.com/snapcore/core-build/tree/master/config/etc/systemd/system15:05
jdstrandogra_: dpkg.list says 0.6.40+ppa46 is installed15:06
ogra_ogra@bbb:~$ ls /etc/systemd/system/swapfile.service15:06
ogra_/etc/systemd/system/swapfile.service15:06
ogra_thats on edge though15:06
jdstrandI'm on candidate15:06
ogra_ah15:07
jdstrandr277615:07
jdstrandbut, the fix was supposedly in ppa41, and this has ppa4615:07
ogra_which is actually the latest package15:08
ogra_and definitely ships /etc/systemd/system/swapfile.service here for me15:09
=== cachio_ is now known as cachio_lunch
ogra_(it isnt enabled though ... you need to do that manually atm)15:09
jdstrandsudo systemctl list-unit-files|grep swap15:10
ogra_jdstrand, what arch/device is that15:10
jdstrandonly swap.target15:10
jdstranddragonboard15:10
ogra_very weird ... there is nothing arch specific about this file15:11
jdstrandogra_: it isn't on my bbb, which is on stable with ppa4515:11
ogra_hmm, even 45 should have had it ... that really landed a while ago15:12
jdstrandogra_: it isn't on my amd64 vm, which is stable with ppa4515:12
ogra_it landed in ppa41 and had a small change in 4215:13
jdstrandogra_: /snap/core/current/etc/systemd/system/swapfile.service exists (amd64)15:13
ogra_right, my bbb on armhf has it too15:13
jdstrand/etc/systemd/system/swapfile.service does not exist15:14
jdstrandthese are all just normal upgraded machines15:14
ogra_well, it only exists on core ...15:15
ogra_and it is shipped by the squashfs15:15
jdstrandthese are all core devices15:15
jdstranddragnboard, bbb, the amd64 vm15:15
ogra_ogra@nanopi-air:~$ grep systemd/system /etc/system-image/writable-paths15:17
ogra_/etc/systemd/system                     auto                    persistent  transition  none15:17
ogra_/etc/systemd/system.conf.d              auto                    persistent  transition  none15: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
jdstrandah15:17
ogra_i suspect we'd need to "synced"15:17
ogra_*need to switch to15:18
jdstrandyeah, these are all pretty old machines15:18
jdstrandso, I'm not blocked or anything15:18
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
jdstrandI guess I could just cp that file into place...15:19
ogra_yes, you can15:19
ogra_but we want users to recieve such changes automatically i guess :)15:20
jdstrandyeah15:21
jdstrandok, if I copy it, enable it and start it, I have a swap15:21
ogra_cool, so it works as intended15:21
mvoogra_: yeah, lets try it15:21
ogra_i''m a bit scared of braking something though15:21
ogra_but i cant put my finger on any clear breakage that could happen15:22
mvoogra_: this definitely needs to get tested carefully, I guess the risk is that we can never remove files from synced dirs15:24
jdstrandanother option would be to update the core snap to copy the file into placec15:25
jdstrandplace15:25
jdstrand(eg, in configure hook on upgrade)15:26
mupPR core-build#17 opened: switch /etc/systemd/system to "synced" mode <Created by ogra1> <https://github.com/snapcore/core-build/pull/17>15:27
jdstrandthe core-support interface would need to be updated for that15:27
jdstrandbut I see you are going with the other method :)15:27
ogra_heh15:28
ogra_yeah, i think we always want new units to be copied if they dont exist in the target dir15:28
jdstrandit does make sense15:28
jdstrandwe don't have interfaces for adding units15:28
ogra_which is fine15:29
* jdstrand nods15:30
jdstrandpoint I was making is that snaps aren't supposed to be able to interact with systemd directly like that15:30
jdstrandso, should be good15:30
zyga-ubuntutesting15:34
mupPR 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:36
zyga-ubuntumvo: I think I'm online now15:37
zyga-ubuntumvo: updated my 1-5KB/s network to 70Mbit15:38
zyga-ubuntu76Mbit down, 21 down15:38
Pharaoh_Atemmvo, zyga-ubuntu, I'm debating on whether I should do 2.27.5 or wait for 2.2815:43
roadmrzyga-ubuntu: so it's 1400 times faster? that's quite an upgrade.15:43
Pharaoh_Atemsince there's also a snapd-glib update, and I like doing those two together15:43
zyga-ubunturoadmr: yes, and no longer the crap consumer type15:48
zyga-ubuntuPharaoh_Atem: 2.28 is monday at the earliest15:48
zyga-ubuntuPharaoh_Atem: I'd do .515:48
* zyga-ubuntu notices ipv6 15:48
zyga-ubuntuoooohh15:48
* zyga-ubuntu looks at the account page15:48
Pharaoh_Atemzyga-ubuntu: keep in mind no one ever tests the updates to make them go quickly15:52
Pharaoh_Atemso they sit for a week in updates-testing before shipping out as updates15:52
mupPR snapcraft#1514 closed: docs: add github processed templates <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1514>15:52
zyga-ubuntuPharaoh_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 cycle15:55
zyga-ubuntuI didn't look at the glib package in a long time15:56
zyga-ubuntuare you sure that it will work with << 2.28 snapd?15:56
Chipacapedronis: question for you, about packaging15:59
jdstrandmvo: fyi, it will need at least one more syscall for arm64. I have a working test environment now so will send up another pr15:59
pedronisChipaca: about packaging? are you sure it's for me ?16:00
Chipacapedronis: yes :-)16:00
Chipacapedronis: in the 14.04 rules you added a check for a second sha3 sum16:00
pedronisI added it in both places16:00
pedronisor so I hope16:00
Chipacapedronis: but in 14.04 you didn't bump the check on how many sha3 sums there are in total16:00
pedronisoh16:01
Chipacapedronis: would it be safe to assume that they need to be the same :-)16:01
pedronisyes16:01
Chipacaok then16:01
pedronisI wonder how tests pass though16:01
pedronisah, it's autopkgtest16:01
pedronisthat use that16:01
pedroniswe don't have 14.04 autopkgtests16:01
pedronisI mean in the travis runs16:01
jdstrandmvo: ok, just one: https://github.com/snapcore/snapd/pull/383416:02
Chipacapedronis: we don't run the package tests in travis16:02
mupPR #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
Chipacapedronis: we explicitly skip 'em16:02
mupPR 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
pedronisChipaca: well they use packaging enough to be upset if that is not set right16:02
pedronisthat's how I re-learned about that16:03
pedronisfwiw16:03
Chipacapedronis: i don't follow16:03
Chipacapedronis: it was a different checksum before?16:03
Chipacahash, not checksum, ykwim16:04
pedronisChipaca: all the autopkgtest in travis were failing when -eq was still 1 for 16.0416:04
Chipacapedronis: autopkgtest yes, travis no16:04
pedronisah16:04
* zyga-ubuntu has 1TB data cap a month now16:04
pedronisnow understand16:04
pedronissorry16:04
Chipacano prob16:04
pedronisI mean the CI tests kicked from github16:04
pedronisyes, the autopkgtest don't go through travis16:05
* Chipaca continues looking at the diff16:05
Chipacapedronis: thank you16:05
pedronisbut we don't have 14.04 autopktest there16:05
pedronisChipaca: fwiw the 2nd hash is the 'generic' authority models key16:06
mvojdstrand: thanks a bunch16:06
pedronisChipaca: does this mean we want some kind of shared  common.mk file ?16:08
pedronisor that we need a 14.04 autopkgtest ?16:08
Chipacapedronis: I think we never got the 14.04 autopkgtest to work, but i'm not sure16:08
jdstrandmvo: np16:08
Chipacazyga-ubuntu: how would you best describe snap.mount.service?16:12
Chipacazyga-ubuntu: i'm going with “trusty needs this to make /snap rshared” but let me know if that could be made clearer16:13
=== cachio_lunch is now known as cachio
mupPR snapcraft#1520 opened: tour: remove the tour assets <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1520>16:17
* zyga-ubuntu reinstalls xenial16:18
zyga-ubuntuactually, I should talk to mvo and I need to do a backup anyway16:21
zyga-ubuntumvo: would you like to talk about that base snap branch?16:22
Chipacawhat's the right way for a postinst to alert the user about something?16:26
Chipaca“echo” is probably not it16:26
zyga-ubuntueh, deja-dup doesn't work on artful16:30
Chipacazyga-ubuntu: neither does curl16:47
zyga-ubuntuChipaca: really?!16:47
zyga-ubuntuChipaca: I'm hand-backing up stuff now16:47
Chipacawell, not properly :-)16:47
Chipacazyga-ubuntu: like a caveman!16:47
Chipacazyga-ubuntu: we found that out yesterday digging into some weirdness sergiusens came across16:48
* zyga-ubuntu is tempted to boot tumbleweed on his laptpo 16:48
Chipacazyga-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 work16:48
ChipacaO16:48
ChipacaI'd imagine /// instead of /v2 would also do the job16:49
zyga-ubuntuwhy another /v216:49
Chipacazyga-ubuntu: well, we were writing /v2/snap and the server was only getting /snap16:49
zyga-ubuntuoood?16:49
zyga-ubuntuwhy16:49
Chipacazyga-ubuntu: because, curl is broken on artful? QED16:49
zyga-ubuntuyeah, I'm just trying to figure out what kind of feature would chop /v216:50
Chipacathe docs say nothing about having to add more stuff, and it's documented everywhere as just http:<path> when using a unix socket16:50
Chipacasergiusens: did you file that bug btw?16:51
* zyga-ubuntu steps out for the backup to continue16:53
mvoChipaca: 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
mvoChipaca: eh, I mean notifying users (not altering them ;)17:16
Chipacamvo: there's currently an17:16
Chipacaecho "Please reboot, logout/login or source /etc/profile to have /snap/bin added to PATH."17:16
Chipacain the 14.04 postinst17:16
Chipacamvo: that sounds like the wrong way to do it, but maybe there's no right way17:17
mvoChipaca: all the way are nasty, I think this is ok(ish)17:18
mvoChipaca: plus snapd is really optimized at server/cloud in 14.0417:18
mvoChipaca: so the kind of user would probably use apt install snapd17:18
mvoChipaca: but thanks for looking into it!17:18
Chipacaok17:19
zyga-ubuntuChipaca: for that I think snap (the command) should do it when running on 14.04 and seeing 3.13 kernel17:32
Chipacazyga-ubuntu: why just there? any time it's not in the path would be good17:33
zyga-ubuntuChipaca: specifically there because snapd doesn't work before17:39
zyga-ubuntuChipaca: not just when it's not on path (that's a separate issue and I don't mind solving it)17:39
Chipacazyga-ubuntu: but it does sound like the kind of cheap check we could do always17:39
Chipacamvo: vvv for your entertainment17:39
mupPR 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:40
jdstrandniemeyer: 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
mupPR #3818: interfaces: fix network-manager plug <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3818>17:42
niemeyerjdstrand: The opposite.. just saying +1 as a comment in the PR won't track the review as an actual review17:43
pedronisjdstrand: you didn't 'Approve Changes' in that one17:44
niemeyerjdstrand: 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 board17:44
jdstrandok17:44
jdstrandI find it weird how sometimes I see the 'Review Changes' button, but other times I need to go into /files17:45
jdstrandanyway, understood17:45
jdstrand"always use the formal method if doing a formal review"17:45
Chipacazyga-ubuntu: little reminder about actually +1'ing snapd#3748 if that was your intent17:47
mupPR #3748: many: fetch & cache remote snaps and sections; complete from there <Created by chipaca> <https://github.com/snapcore/snapd/pull/3748>17:47
mupPR snapcraft#1521 opened: python plugin: always record constraints and requirements contents <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1521>17:50
zyga-ubuntuChipaca: ack, will do soon-ish17:56
* zyga-ubuntu installs xenial17:57
zyga-ubuntuthis new network is really insanely good17:57
zyga-ubuntuI just want to get back to stable OS as well17:57
zyga-ubuntuI'm getting 7MB/s to ubuntu.com archive18:00
zyga-ubuntuwoah18:00
zyga-ubuntu1018:00
zyga-ubuntu10MB/s for larger downloads18:00
zyga-ubuntu11MB/s :D18:00
naccis the core-snap's path for a given snap a snap environemtn variable?18:00
zyga-ubuntunacc: hmmm18:00
zyga-ubuntunacc: can you say that again please?18:00
zyga-ubuntunacc: do you want to find the core snap at runtime?18:00
nacczyga-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
nacczyga-ubuntu: that involves not using $PATH, but setting it to some specific values in my snap18:00
nacczyga-ubuntu: however, that then means the core snap is not in $PATH :)18:00
nacce.g., /snap/core/current/bin, /snap/core/current/usr/bin ,etc18:00
naccis /snap/core/current something i can just use? or is it stored in some env variable for portability18:00
zyga-ubuntunacc: how is confinement needed for the classic snap?18:00
nacczyga-ubuntu: it's not, but i want to ensure only my binaries are used18:01
zyga-ubuntunacc: /snap/core/current is reliable18:01
nacczyga-ubuntu: e.g., my version of git, not the system git18:01
nacczyga-ubuntu: and so i need to manipulate PATH in very specific ways18:01
zyga-ubuntuok18:01
nacczyga-ubuntu: ok, i htink i can wrap that up then, for now18:01
nacczyga-ubuntu: thanks!18:01
zyga-ubuntuyw!18:02
zyga-ubuntubackup's done18:03
* zyga-ubuntu wonders what else to check18:03
zyga-ubuntumaking live USB18:04
=== chihchun_afk is now known as chihchun
jdstrandroadmr: hi! has the reviewers page url changed? https://dashboard.snapcraft.io/dev/snaps/reviewer/ is giving me 40418:48
jdstrandroadmr: earlier today it worked18:48
jdstrandroadmr: 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:54
cachioniemeyer, about the images with the dependencies installed18:55
cachiowhen I have them ready, you will take an screenshot?18:55
jdstrandroadmr: I wonder if ubuntu/ is the right name since the store is the public snap store, and not specific to ubuntu18:55
jdstrandroadmr: that is a different conversation though. should I update docs/etc for the new url?18:56
cachioniemeyer, should I create a PR first?18:56
niemeyercachio: I'd prefer to see the spread project updated first, and then we change the images with it18:57
niemeyercachio: So we're actually just persisting what we have already automated18:57
cachiook, i'll create a PR18:57
jdstrandniemeyer: 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 start18:58
mupPR #3834: cmd/snap-seccomp/main_test.go: add one more syscall for arm64 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3834>18:58
jdstrandI already tried a cancel/restart once18:59
niemeyerjdstrand: Supposed to be fine: https://www.traviscistatus.com/19:00
niemeyerjdstrand: That works against you, actually..19:00
niemeyerjdstrand: Puts you back at the end of the queue19:00
niemeyerjdstrand: We have a limit of 3 concurrent jobs19:01
jdstrandniemeyer: I thought it might but I rolled the dice since it had been more than hour (maybe closer to two)19:01
jdstrandok19:01
* jdstrand stops watching the pot waiting for it to boil19:01
jdstrandniemeyer: thanks19:02
niemeyerjdstrand: You can see it here:19:03
niemeyerjdstrand: https://travis-ci.org/snapcore/snapd/pull_requests19:03
niemeyerjdstrand: and here: https://travis-ci.org/snapcore/snapcraft/pull_requests19:04
niemeyerjdstrand: We have quite a few PRs waiting indeed.. two of them running19:04
niemeyerjdstrand: You seem to be next in line on snapd.19:05
niemeyer(assuming you don't restart! ;)19:05
=== ikey is now known as ikey|afk
mupPR snapd#3833 closed: interfaces/opengl: use == to compare, not = <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3833>19:13
* zyga-ubuntu reinstalled xenial19:38
zyga-ubuntueverything works again :)19:38
zyga-ubuntutime to sleep though19:38
mupPR snapcraft#1522 opened: catkin plugin: only append PYTHONPATH if set <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1522>19:47
=== JoshStrobl is now known as JoshStrobl|AFK
roadmrjdstrand: hi! hm - there may have been some changes to how stores are accessed, let me check19:51
nessitajdstrand, hi!19:54
nessitajdstrand, could you please visit https://dashboard.snapcraft.io/dev/store/list/19:54
nessitaand follow the links for review there?19:54
nessitajdstrand, 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 it19:55
roadmrhi nessita hehe19:56
cachioniemeyer, https://github.com/snapcore/spread-images/pull/919:57
mupPR spread-images#9: Install dependencies on the images <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/9>19:57
cachioniemeyer, I run it and I see this error for debian and opensuse: cannot send project content: remote directory /root/spread is not empty19:59
cachiothe base images are not clean19:59
cachioniemeyer, I am going to bed now, I am feeling really bad20:00
niemeyercachio: Sure thing, have a good rest there and hop you get better soon20:07
jdstrandnessita: I did that (hence me comment regarding ubuntu/)20:13
jdstrandI'll update my bookmark and docs20:13
jdstrandmy*20:14
nessitajdstrand, I'm adding a redirect helper as well, for the deprecated URLs20:16
nessitajdstrand, sorry for not having that redirect in place before20:16
nessitajdstrand, 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
nessitajdstrand, because URLs will change again20:18
mupPR snapcraft#1523 opened: python node: record installed node packages in manifest <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1523>20:41
jdstrandnessita: ok, thanks20:55
pedronisniemeyer: 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 prominent20:56
nessitapedronis, I agree20:58
niemeyerpedronis: You mean the one from the model?21:02
pedronisniemeyer: is not used in the model21:02
pedronisI mean it's the implicit default21:03
pedronisI don't think people have put it directly into models21:03
pedronisfor sure we don't21:03
niemeyerpedronis: That would be incorrect then?21:03
pedronisniemeyer: ?21:03
niemeyerSorry, I mean21:03
niemeyerIf the store side is assuming "ubuntu" to be a default, it doesn't seem right21:04
pedronisyes, the store side is doing that, because the main/default store atm  has id ubuntu21:05
pedronisin the store side21:05
pedronissnapd simply doesn't send anything to get the default21:05
niemeyerYeah, that seems fine.. the default is just the default21:06
niemeyerThe store just shouldn't assume that.. sounds like a simple string change21:06
pedronisI'll let nessita comment on the simple, but we need a new more neutral name/id then21:07
nessitaniemeyer, is not simple because is also the DB table ID (historic reasons)21:10
nessitadoable, for sure21:11
nessitaniemeyer, pedronis it may hardcoded in some other places, it needs some planning and checking, but doable for sure21:14
nessitawill add an item to our rally agenda21:14
niemeyernessita: Ack, not a big deal either as long as this isn't showing anywhere21:15
nessitapedronis, niemeyer what would be the ideal store id for the main/default store?21:15
pedronisniemeyer: did you see this comment by jdstrand on the reuse snap-update-ns PR:  https://github.com/snapcore/snapd/pull/3621#discussion_r13643707521:22
mupPR #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
niemeyerpedronis: Not yet, and I need to run out just now to pick kid up in school21:23
niemeyerBack in a bit21:23
=== ^arcade_droid is now known as aarcade_droid
pedronisnessita: main would be the obvious one, sounds  a Gustavo's question though21:28
* pedronis -> rest21:29
mupPR 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>21:32
=== aarcade_droid is now known as ^arcade_droid
=== chihchun_afk is now known as chihchun

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!