/srv/irclogs.ubuntu.com/2017/05/23/#snappy.txt

nacckyrofa: of course they do :)00:00
kyrofanacc, they're essentially dynamically-created channels. Perfect for creating a snap of "this" pull request00:00
kyrofanacc, they're ephemeral, though, and expire after a month00:01
nacckyrofa: ah i see00:01
kyrofa(unless published to again)00:01
nacckyrofa: interesting, will read up on it tmrw00:01
nacckyrofa: snaps feel like such a moving target  sometimes :)00:01
kyrofanacc, yeah I feel ya00:01
Chipacaoooh, i think i know how to make the keygen tests quicker00:02
kyrofaChipaca, what the heck man, were you asleep and awoke with a genius idea?00:02
Chipaca… don't we all?00:02
kyrofaYes :P00:02
Chipacakyrofa: also, manchester explosion has me woke00:04
* kyrofa googles manchester explosion00:04
kyrofaDang00:05
kyrofaChipaca, you're not close, I hope00:06
Chipacanor is any of my family as far as i know00:06
kyrofaGood00:07
Chipacaneed to check with samuele wrt sanity, but this makes the key generation step of the tests ~20× faster00:12
mupPR snapd#3383 opened: Fix spread flaky tests linode <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3383>01:55
mupPR snapcraft#1327 opened: tests: small updates for manual kernel tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1327>02:50
=== chihchun_afk is now known as chihchun
=== pbek_ is now known as pbek
elfgohI had a question regarding sanitisation of snap interfaces: https://forum.snapcraft.io/t/sanitisation-of-snaps-requested-interfaces/73904:58
mupPR snapd#3382 closed: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3382>05:43
mupPR snapd#3379 closed: cmd/snap,tests: show the snap id if available in snap info <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3379>05:49
mupPR snapd#3226 closed:  snap-repair: add `snap-repair run`  <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3226>06:16
zygagood morning06:37
zygamvo: hey06:38
zygamvo: just to give you some more context for my message yesterday06:38
zygamvo: gustavo reviewed the way we convey meta-data for interfaces and wanted to make some changes06:38
zygamvo: we had a quick brainstorm session and the bottom line is that the current rest API has to be reverted to what it was before meta-data layer was merged06:38
zygamvo: and the meta-data must move to a new endpoint "interface" (vs "interfaces" currently)06:39
zygamvo: I will work on this and the CE blocker today06:39
zygamvo: when do you plan to release?06:39
morphiszyga: morning!07:11
zygamorphis: good morning07:14
pstolowskimorning07:15
palassoHello, I'm not following snap development closely. I'm wondering on why the OS snap ubuntu-core was renamed to core?07:21
morphismvo, zyga, pedronis, Pharaoh_Atem, niemeyer: can you guys look into https://github.com/snapcore/snapd/pull/3222 again today? Would like to get that merged soon07:30
mupPR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>07:30
pstolowskihello palasso! this was mainly to avoid confusion about cross-distro support07:32
palassoty pstolowski for the answer07:32
morphiscan it be that Linode/spread is pretty unreliable these days? Trying to get a green light on a PR which touches nothing which is tested anywhere but running into a lot of timeout issues: https://github.com/snapcore/snapd/pull/337107:50
mupPR snapd#3371: packaging: import packaging bits for opensuse <Created by morphis> <https://github.com/snapcore/snapd/pull/3371>07:50
mvomorphis: yeah, looks like it, maybe worth poking the store people about: "DEBUG: The retry loop for https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2 finished after 4 retries, elapsed time=40.008154662s, status: Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/99T7MUlRhtI3U0QFgl5mXXESAiSwt776?max-format=2: net/http: request canceled while waiting for connection (Client08:04
mvo.Timeout exceeded while awaiting headers)"08:04
mvomorphis: 40s and 4 retries is a pretty long wait08:05
fgimenezhi morphis in that build you had a lot of connectivity problems, seems that between linode instances and the store, at least two "dial tcp 162.213.33.92:443: getsockopt: no route to host" (162.213.33.92 is public.apps.ubuntu.com), "dial tcp 162.213.33.92:443: i/o timeout", timeouts awaiting for headers from assertions.ubuntu.com, the tests/main/completion error seems to be related to connectivity too, maybe the store was down or all the instances08:05
fgimenezinvolved (more than one had errors) lose connection08:05
morphisyeah08:11
morphisis pretty nasty and it looks like I am getting similar problems with all my PRs08:11
morphismvo: what is a good place to poke on the store people?08:12
cjwatsonkyrofa: not yet; at the time when we were adding publish-to-track support to LP, branches were only defined for stable, and automatic jobs shouldn't be publishing directly to stable.  Some of the assumptions here may have changed since though08:14
zygare08:15
zygageez, firefox ate 3GB of ram on 4 tabs open08:17
pedronismy 2.27 PRs need reviews08:36
Chipacapedronis: hiya08:39
mupPR snapd#3384 opened: tests: use pollinate to seed the rng <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3384>08:46
fgimenezhi Chipaca, could you please take a look at ^^^? never use pollinate before, seems to be working fine with a plain call08:46
Chipacafgimenez: yup08:51
Chipacafgimenez: i also want to check with samuele about what happens if we use a gpg in testing that clamps keys to 1024 bits08:52
fgimenezChipaca: great thanks!08:55
pedronisChipaca: where? we check that the keys we get have the expected length08:59
Chipacapedronis: we do? where?08:59
Chipacasnap create-key seemed to be happy with them09:00
Chipacapedronis: good morning!09:00
pedronisChipaca: well, when you try to sign with it, it won't (maybe that test doesn't use the key it makes, but as a general strategy across all tests doesn't work)09:01
pedronisChipaca: here,  https://github.com/snapcore/snapd/blob/master/asserts/crypto.go#L36709:02
* Chipaca pokes at his internet09:04
Chipacapedronis: sadface09:13
Chipacapedronis: maybe i should override gpg and then un-override it when tests break :-)09:13
pedronisChipaca: override it with what anyway ?09:14
Chipacapedronis: sed and more gpg :-)09:16
pedronisChipaca: anyway we do have  a snap-sign test09:16
morphiszyga: step 1, CI passes on https://github.com/snapcore/snapd/pull/3365 :-)09:16
mupPR snapd#3365: tests,packaging: add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>09:16
Chipacapedronis: yeah, that's the one i was poking around in last night09:16
pedronisChipaca: which funnily I never seen fail09:16
Chipacapedronis: oh, i did09:17
Chipacapedronis: I'd point you at https://s3.amazonaws.com/archive.travis-ci.org/jobs/234990914/log.txt?X-Amz-Expires=30&X-Amz-Date=20170523T012508Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170523/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=2f9a55bec2d1b61a8c23f3b46d7c955155fc8e2f719cb66e788743bc7181c36a but travis has already been "helpful"09:17
pedronisChipaca: anyway what you could do is merge create-key into snap-sign09:17
pedronisso you need less overall entropy09:17
Chipacapedronis: the entropy doesn't seem to be the problem afaict09:17
pedronisChipaca: what is the problem then?09:17
Chipacapedronis: at least, every time i've looked we've had ~3k of entropy09:18
pedronisdoesn't compute09:18
pedroniswhy would create-key take forever if not that09:18
Chipacapedronis: I'm guessing here but we might be getting penalized09:18
Chipacafor heavy cpu use09:18
pedronisanyway my point stand09:19
Chipacayep09:19
pedroniswe would use less CPU if we create less keys :)09:19
Chipacadon't get me wrong, we might also be running out of entropy09:19
Chipacaand i think we need to add that to the debug output09:19
Chipacaso we can see09:20
Chipaca(also to the regular output! but that's going to be harder)09:20
pedronisChipaca: so mergeing  snap-sign create-key  and the key completion test into one09:20
ogra_[   12.818573] F2FS-fs (sda): Can't find valid F2FS filesystem in 1th superblock09:22
ogra_[   12.829425] F2FS-fs (sda): Can't find valid F2FS filesystem in 2th superblock09:22
ogra_hmpf09:22
ogra_i wonder if we cant quieten f2fs on a kernel level09:22
Chipacaaugh09:23
Chipacawho writes that code :-(09:23
Chipacawho writes "%dth" and thinks that's a good idea09:23
ogra_someone who doesnt know about english numbering ?09:23
Chipacabut then there's like 5 other people that looked at that code and thought "fine whatever" and let it pass :-/09:24
ogra_yeah09:24
Chipacaanyway09:24
Chipacaalways too easy to criticise other projects09:24
* Chipaca shuts up09:24
ogra_well, i'm sure whatever code there is probes all possible filesystems ... but only f2fs prints that stuff09:25
ogra_apw, do you think we could quieten such f2fs messages ?09:26
apwogra_, why do you care about two lines in your dmesg ?09:27
Chipacaapw: users (actually, device developers) see them and freak out09:27
apwogra_, and indeed what is triggering them from userspace09:27
ogra_apw, dunno, i'm german :P09:27
apwChipaca, i think device developers need to develop thicker skin :)09:27
ogra_apw, snapd checks all attached non rootfs devices for possible snap assertions on boot ... so it mounts them once ...09:28
* apw sticks several fingers in each of his ears ...09:28
ogra_apw, we used to include ramdisks in that... when we did that i have about 30 of these messages ... now i get them for the one atttached usb device only ... but still only f2fs (which we never used) prints that stuff09:29
* Chipaca wonders how apw types with several fingers in several ears09:29
ogra_s/i have/i had/09:29
apwChipaca, with my feet, the only way09:29
Chipacapedal keyboards ftw09:29
apwogra_, surely we do not try all the possible filesystem types though09:29
apwogra_, that way lies _vast_ attack surface09:29
ogra_apw, well, we just call mount i guess ... the rest is kernel09:30
ogra_(or internal logic of mount)09:30
apwogra_, they kernel does not guess you filesystem type, that would be mount09:30
Chipacaogra_: do we explicitly load f2fs?09:30
=== pachulo_ is now known as pachulo
ogra_Chipaca, nope09:30
apwogra_, so what is on that stick which triggers that error09:31
ogra_Chipaca, i think it is compiled in09:31
Chipacaogra_: at least here it's a module09:31
ogra_apw, a vfat fs09:31
Chipacadunno on other arches etc09:31
apwogra_, ie what does blkid say on it09:31
ogra_Chnot in xenial09:31
ogra_Chipaca, ^09:32
apwas one would expect mount to ask what it is and then mount that specific type09:32
Chipacaogra_: chtotally in xenial09:32
ogra_ogra@pi3:~$ lsmod|grep f2fs09:32
ogra_ogra@pi3:~$ grep f2fs /proc/filesystems09:32
ogra_f2fs09:32
ogra_ogra@pi3:~$09:32
ogra_ogra@pi3:~$ sudo blkid /dev/sda109:33
ogra_ogra@pi3:~$09:33
ogra_bah09:33
ogra_/dev/sda1: UUID="72AD-5403" TYPE="vfat" PARTUUID="7524a7a6-01"09:33
ogra_silly IRC09:33
Chipacaogra_: try: modinfo f2fs09:33
apwheh, so why the heck is f2fs being used against it09:33
ogra_apw, dunno, why was it being used on all the ramdisks before09:33
apwogra_, can you manually try mounting it with mount /dev/sda2 /mnt09:34
ogra_this isnt new or anything ...09:34
apwand with mount -t vfat /dev/sda2 /mnt09:34
apwsort of thing09:34
apwand see if the latter is quieter09:34
* apw would suggest we should be using blkid and only attempting to mount if it is one of a very very limited set of formats, ones we are willing to work hard to keep security good on09:34
apwelse i could format it as some utterly nasty format and you will mount it, w09:35
apwwhich is just asking to be attacked09:35
apwi would vote for one format if i was involved, perhaps vfat09:35
ogra_apw, neirther mount nr mount -t vfat print anything09:36
apwogra_, nothing in dmesg you mean ?09:36
ogra_right09:36
apwthen you have a new mystery, who the heck is triggering that09:36
apware you using some magical go helper09:36
ogra_pedronis, mvo, ^^^ does snapd rotate over filesystems when mounting a device to lok for assertions ?09:37
ogra_*look09:37
pedronisno clue, that's really for mvo09:39
zygare09:42
zygamorphis: that's great :)09:42
zygaI need to catch up with PRs but first I need to prepare two important things for 2.27 for mvo09:42
ogra_looks like this is the mount code https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_auto_import.go09:43
morphiszyga: do that09:43
ogra_cmd := exec.Command("mount", "-o", "ro", "--make-private", deviceName, tmpMountTarget)09:43
ogra_nothing fancy regarding filesystems09:43
zygahmm hmm09:47
zygathose are two distinct mount syscalls AFAIK09:47
ogra_because of the --make-private ??09:49
zygayes09:49
zygafirst you do mount -o ro deviceName tmpMountTarget09:49
zygathen mount --make-private09:49
zygait's not atomic09:49
zyga(mount-the-command does that internally)09:49
ogra_ mount(8)  does  not  read  fstab(5)  when a --make-* operation is requested.  All necessary information has to be specified on the command09:50
ogra_              line.09:50
ogra_hmm09:50
Chipacahow do you un-duplicate a bug?09:50
ogra_Chipaca, iirc somewhere in the target bug09:50
Chipacaah09:50
mvoogra_: I'm not sure what rotate over filesystems means, but it does look at block devices for assertions, yes09:55
mvoapw: aha, just finished reading backlog - sure, we can make this smarter to only mount ext{2,3,4} and vfat or maybe even only vfat09:56
zygamvo: we may even do more, register a GUID09:58
zygamvo: that is unique to snapd09:58
mupPR snapd#3385 opened: cmd: add stub new snap-repair command and add timer <Created by mvo5> <https://github.com/snapcore/snapd/pull/3385>09:58
zygamvo: (not partition ID, but partition *type* ID)09:58
zygamvo: then you can make a stick, with any filesystem, and snapd will recognize it09:59
apwzyga, you don't want it to support "any" anything, if any device will mount and consume it on b09:59
apwzyga, boot.  that is just asking for people to exploit every possible filesystme bug10:00
zyga(you can still add extra requirements, but the guid makes it distinct even before we mount it)10:00
mvozyga: maybe, but OTOH anything that makes it harder for people to use this feature is not ideal IMO, I like the simplicify of the current: grab random-usb-stick, copy file, done10:00
zygaapw: I agree10:00
zygamvo: it all depends on tooling10:00
apweasy is the antithisys of secure10:00
mvozyga: well, yes, but its still at least one extra step: find the right tool for your $OS, download, run10:01
zygamvo: more like "make disk image" website10:01
mvoapw: you think even limiting to vfat would be an issue?10:01
zygamvo: but I agree10:01
apwmvo, i would cirtainly recommend limititing it to something vfat might be that thing10:02
mvoapw, zyga: once I finished with my current branch I will do that then10:02
apwmvo, though i would ask the security team for a recomendation if anything10:02
mvoapw: good point10:02
mupPR snapd#3386 opened: interfaces, osutil: move flock code from interfaces/mount to osutil <Created by mvo5> <https://github.com/snapcore/snapd/pull/3386>10:09
mupPR snapd#3387 opened: cmd: auto import assertions only from vfat file systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/3387>10:12
zygamvo: thank you for moving the flock code10:13
mvozyga: thanks for writing it :)10:15
zygamvo: what is the `wrong prefix` test from?10:17
zygaah10:18
zygaI misread10:18
zygathat's just a comment10:18
ogra_mvo, s/rotate/loop/ :)10:27
ogra_apw, still though, why do the fs drivers print such stuff at all ... this is similar to the ext2/3 messages you get when mounting an ext4 fs, that also spills a lot scary messages10:27
ogra_i.e.10:28
ogra_[    6.720679] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities10:28
ogra_[    6.729695] EXT4-fs (mmcblk0p2): couldn't mount as ext2 due to feature incompatibilities10:28
ogra_[    6.755923] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: errors=remount-ro10:28
pstolowskiguys, i've a longer power outage today. i'm using my cellphone as a hotspot, but going for a lunch now and will be offline for ~1h10:28
apwogra_, so that you can diagnose why a mount fails, as all you get in user space is EINVAL10:28
ogra_hmm10:29
apwthey are not scarey they are informative and useful if a mount you intended to make fails10:29
ogra_they are scary for someone not understanding them10:29
apwsomeone not understanding them is unlikely to be able to find them10:29
* ogra_ had enough bugs from users that got confused by these messages over the years10:30
apwthat is why they are not on the screen, but in a hidden kernel buffer10:30
apwyes users will always find somethign to be confused about, but in this context it is unlikely a user can even see this buffer10:30
ogra_dmesg shows it prominently as does syslog and the kern.log file10:31
ogra_so if an illiterate user has a prob he looks at it and reacts with "OMG filesystem errors" ...10:31
apwfew illiterate users know about any of those logs, or how to find them10:31
ogra_well10:32
apwand a semi-literate user will always be scared by everything10:32
apwand if you don't record them, their literate friend they go and ask10:32
apwwill have literally nothing to work with10:32
ogra_heh, k10:32
apwcomputer equipement should have "no user servicable parts" on the front :)10:32
ogra_lol10:33
apwwe log a lot more of that kind of thing than necessary because we are lazy in usersapce and10:33
apwtry things because we know the kernel will fail to do things which are silly10:33
apwinstead of only asking it to do things we want to do10:33
* apw goes back to punching docker repeatedly wishing it _would_ log something useful10:34
Chipacaapw: punch harder?10:37
apwif only i could punch it hard enough10:37
Chipacamaybe a hydraulic punch10:38
mupPR snapcraft#1328 opened: qmake plugin: set default qt version <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1328>10:45
pedronismvo: made a comment about snap-reapir branch, my explanation yesterday might have been confused, I still owe to update the forum entry10:52
pedroniss/confused/confusing/10:52
Chipacapedronis: I requested changes on one of your PRs, so it all evens out10:54
pedronisChipaca: seems we have not tests for snap info directory fwiw10:54
Chipacapedronis: there are10:54
Chipacapedronis: just not with --verbose10:54
pedronisso we have no ---verbose tests?10:55
Chipacacertainly none for ---verbose :-p  and only a rather bare local check for --verbose10:56
Chipacawait10:56
Chipacataht might be yours10:56
Chipaca:-)10:56
Chipacaso, no, no tests for --verbose10:56
pedronisChipaca: I added it10:56
Chipacapedronis: yeah10:57
Chipacapedronis: any reason not to also show the sha3 for remote snaps in info?10:57
pedronisChipaca: we don't have that info around10:58
pedronisah remote ones10:58
Chipacapedronis: it's in DownloadInfo10:58
pedronisbut not locals?10:58
Chipacapedronis: ¯\_(ツ)_/¯10:58
pedronisbecause that needs thinking, if we want local too10:59
Chipacait's strange that we don't store it in state10:59
Chipacai guess it's somewhere in the asserts db?10:59
pedronisit's in the assert db10:59
Chipacathinking is hard10:59
Chipacalet's have lunch10:59
Chipacapedronis: to be clear, i'm not saying this is in any way a blocker to the pr you have up11:00
Chipacabut every time i look at snap info i want to make it better :)11:00
Chipacaand then i remember making it better starts by looking at goyaml11:00
pedronisChipaca: anyway that's not a snap info problem, we need to think how to put the ash back into api.go11:01
pedronisthen info is easy11:01
Chipacayup11:01
pedronisthere's remote, local unasserted, and local asserted11:01
pedronisto consider11:02
_28Kbwhy there's no php7 server snap?11:11
Chipaca_28Kb: what's a php7 server?11:14
_28Kblike one in XAMPP11:15
Chipaca_28Kb: I don't think there's a reason11:17
mupPR snapcraft#1329 opened: tour: use https for source urls <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1329>11:18
Chipacamvo: have you seen the travis error on snapd#3374?11:19
mupPR snapd#3374: partition: add directory sync to the save uboot.env file code <Created by mvo5> <https://github.com/snapcore/snapd/pull/3374>11:19
_28Kbi need apache, php and mysql for my ubuntu core..11:19
Chipacamvo: (hint: it goes “can't load package: package github.com/mvo5/uboot-go/uenv: [...]”)11:20
_28Kbi got only this nextcloud option offered11:20
Chipaca_28Kb: out of curiosity, why do you need a snap with these things?11:24
_28Kbi got snappy core, so i need snaps i guess11:24
Chipaca_28Kb: _for what_?11:25
Chipaca_28Kb: that is, you don't need a server, nobody needs a server. Servers are for building services with. What service are you building?11:25
_28Kbservice which i could access from outside the box11:26
Chipaca_28Kb: and this is for a single box, your box, not for building a bunch of boxes that use this?11:26
_28Kbthrough websocket for example11:26
_28Kbi can't build one.. bunch is for distant future :)11:27
mupPR snapd#3377 closed: asserts: simplify and adjust repair assertion definition <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3377>11:28
pstolowskiChipaca, pedronis, zyga, mvo is any of you working on retry for deltas? if not, I'll do it today11:28
Chipaca_28Kb: it should be fairly straightforward to build a snap like that; nobody's done it because they haven't felt the need i guess? all the needed bits are there11:29
pedronispstolowski: retry in which sense?11:29
pedronisbut no11:29
_28Kbok, i see11:29
Chipacapstolowski: i can confirm that I am not working on retry for deltas11:31
Chipacain fact, I'm going to start working on lunch.11:32
pstolowskipedronis, ah, nvm... I thought we don't retry deltas after a quick look yesterday when we failed in the tests on travis, but looking again now and we actually do retry11:33
mupPR snapd#3380 closed: cmd/snap,tests: show the sha3-384 of the snap for snap info --verbose SNAP-FILE <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3380>12:05
pedronisChipaca: about info and sha3-384, proably leaving it out for unasserted local snaps would be ok or desired, so that would make it relatively doable12:07
Chipacapedronis: well, snap info _could_ cheat and go look at the .snap in that case :-)12:12
pedronisChipaca: yes, it could but not as I said it could be argued that it doesn't make sense12:13
pedroniss/but not/but/12:13
mupPR snapd#3388 opened: osutil: add non-blocking flock <Created by mvo5> <https://github.com/snapcore/snapd/pull/3388>12:14
mupPR snapd#3384 closed: tests: use pollinate to seed the rng <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3384>12:16
mupPR snapd#3378 closed: tests: fixes for executions using the staging store <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3378>12:17
ogra_mvo, hmm, your uboot change failed all tests ... something still looks for github.com/mvo5/uboot-go/uenv somewhere12:39
mvoogra_: checking12:39
mupPR snapd#3389 opened: overlord/snapstate: have an explicit code path last-refresh unset/zero => immediatey refresh try <Created by pedronis> <https://github.com/snapcore/snapd/pull/3389>12:53
pedronismvo: small PR of something I mentioned/we discussed ^  (also forum https://forum.snapcraft.io/t/refresh-schedule-via-core-config/434/9 )12:55
mvozyga: any progress on the work for seccomp constants resolving (the things we talked about yesterday) btw?12:55
mupPR core#47 closed: keep version Makefile in sync with version-script <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/47>12:56
mvopedronis: very nice, thanks a lot12:57
morphisniemeyer: can you snapshot spread-61 as opensuse-42.2-64 when you have a minute? :-)13:03
draglyIs there anything apart from the "camera" plug I need to request for camera access? I'm currently running a Qt app on a computer without a camera and get the following error:13:13
draglydefaultServiceProvider::requestService(): no service found for - "org.qt-project.qt.camera"13:13
Chipacafgimenez: how much were you giggling while adding "pollinate"13:35
* Chipaca just realised it might be funny in Spain13:36
fgimenezChipaca: :D yes something you wouldn't hear from your grandmother13:39
pedronisniemeyer: this is the PR  I mentioned:  https://github.com/snapcore/snapd/pull/3375  (also I pointed to it from aliases topic)13:41
mupPR snapd#3375: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>13:41
niemeyerpedronis: Thanks for the pointer13:42
Chipacaone more review wanted for snapd#3342 please13:42
mupPR snapd#3342: many: refactor in preparation for 'snap start' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342>13:42
niemeyerChipaca: Will look into it too13:42
Chipacaniemeyer: taw13:43
niemeyerIt's sad we're still blocked from using our neat state patching mechanism...13:53
niemeyerIt'd be nice to be able to drag comments to different lines before the review has been delivered13:55
Chipacaniemeyer: as opposed to cut, delete, recomment?13:58
niemeyerChipaca: Yeah13:58
Chipaca(like a caveman)13:58
niemeyerExactly :)13:58
Chipacaniemeyer: drop wossisname a tweet13:58
niemeyerChipaca: Who's that?14:00
Chipacaniemeyer: back when pyconar and pyconbr worked together one of the guests we brought was this github guy14:00
Chipaca(i don't even know if he's still at github :-) )14:01
niemeyerChipaca: The account on Twitter seems dead14:01
Chipacaah well14:02
mupPR snapd#3389 closed: overlord/snapstate: have an explicit code path last-refresh unset/zero => immediately refresh try <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3389>14:04
pedronismvo: thanks for merging ^   it also cuts down snapstate tests to <1s (go test displayed time) here14:07
niemeyerChipaca: Reviewed14:07
niemeyerpedronis: Too14:07
pedronisniemeyer: thanks, saw that, trying to add the tests John asked for14:07
mvopedronis: neat14:07
Chipacaniemeyer: thanks!14:09
mupPR snapd#3342 closed: many: refactor in preparation for 'snap start' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3342>14:09
Chipacamvo: “snap log -p” ftw14:09
Chipacamvo: also https://github.com/golang/go/issues/612314:12
Chipaca(which didn't get anywhere, but that's neither here nor there)14:12
mvoChipaca: ok, if everyone is happy with TryLock I will rename it14:13
Chipacahaving said all this, remember: don't trust me with names :-)14:13
Chipacaniemeyer: defunkt!14:13
mvoniemeyer: are you ok with FLock.{Lock,TryLock} for a blocking and non-blocking file lock ?14:13
fgimenezmvo: before i forget this is the error on the docker test execution https://travis-ci.org/snapcore/spread-cron/builds/235061721#L452 (only failed on amd64)14:14
niemeyermvo: As in, introducing such a type with those methods?  Didn't we have flocking somewhere already?14:14
mvoniemeyer: yeah, we had blocking flock so far, we are brainstorming names for the non-blocking variant of this14:15
mupPR snapcraft#1330 opened: storeapi: log download retries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1330>14:15
mvofgimenez: interessting and strange, especially if it only failed on a single arch14:16
niemeyermvo: TryLock sounds nice14:16
fgimenezmvo: i'm trying to reproduce locally, will let you know how it goes14:17
niemeyermvo: perhaps FileLock rather than FLock14:17
mvoniemeyer: great, I will make this happen, thanks for your input!14:17
niemeyermvo: Thanks for working on it.. are we flocking something new?14:18
mvoniemeyer: yes, snap-repair14:19
mvoniemeyer: we want only a single snap-repair running, this is the prereq for this14:19
niemeyermvo: Cool.. should be safe enough, assuming the snap-repair process itself doesn't get frozen for whatever reason :)14:20
mvoniemeyer: yeah, that would be bad(tm)14:21
kyrofacjwatson, indeed, I only just discovered that branches only exist on stable14:23
Chipacamvo: should probably grow into something lockfileish if it's a concern14:23
Chipacaas in, write the pid when locking, and then other lockers get to kill you if you take too long14:25
mvoChipaca: yeah14:28
* Chipaca gives reviews in bites14:29
pedronisChipaca: pushed some more tests to snapd#337514:29
mupPR snapd#3375: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>14:29
Chipacapedronis: yep, looking now14:30
mupPR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>14:35
mupPR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>14:36
Chipacamvo: boooo to returning errno :-)14:41
Chipaca(yes sure it knows its an errno so .Error() gives you "resource temporarily unavailable", but it's still 0xb)14:42
mupPR snapd#3390 opened: tests: remove additional setup for docker on core <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3390>14:42
* ogra_ is dizzy ... u-boot all around me ... 14:48
* zyga has food poisoning; sorry guys, will be back some other time today14:50
Chipacazyga: I ate tomato sauce that was out all night, and _you_get food poisoning?15:02
Chipacazyga: something is wrong15:02
morphisniemeyer: you saw my message about labeling a spread node for opensuse?15:03
morphismvo: can you merge https://github.com/snapcore/snapd/pull/3357 now that CI passes?15:03
mupPR snapd#3357: tests/lib: abstract build dependency installation a bit more <Created by morphis> <https://github.com/snapcore/snapd/pull/3357>15:03
Chipacaniemeyer, pedronis: bug #1692866 might be something you guys can follow and have useful input on (i don't feel i can given it's juju which i know next to nothing about)15:11
mupBug #1692866: /snap/bin not in path for juju run/juju ssh <juju:Incomplete> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1692866>15:11
niemeyermorphis: I haven't seen it15:12
morphisniemeyer: ok, here it comes again: need spread-61 tagged as opensuse-42.2-6415:12
niemeyermorphis: You mean a new image snapshot out of it, right?15:12
morphisniemeyer: yes15:13
morphisPR for spread-images is coming now15:13
niemeyermorphis: Cool, thanks. Will do that first thing after lunch.15:13
morphisniemeyer: thanks!15:15
ogra_Chipaca, you ate tomato sauce that went clubbing ? doesnt all that dancing turn it into "salsa" anyway ?15:16
Chipacaogra_: you're saying this as if it were a bad thing?15:16
ogra_nah, not a bad thing at all15:16
ogra_In file included from include/common.h:22:0,15:17
ogra_                 from lib/asm-offsets.c:15:15:17
ogra_include/errno.h:12:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘extern’15:17
ogra_ extern int errno;15:17
ogra_*that* is a bad thing :(15:17
Chipacaogra_: I agree. Get your cat off your keyboard.15:21
ryebotzyga: are you available to discuss that "cannot change profile for the next exec call: No such file or directory" bug from yesterday?15:30
ryebotI attempted the suggested fix (no classic installation), but it's still happening15:30
ryebotI also checked /var/lib/snapd/seccomp/profiles/snap.etcd.etcd (http://paste.ubuntu.com/24634459/) to see if it was indeed not being installed classically, and it seems to check out. (I assume I'm looking for the absence of @unrestricted at the top?)15:31
ryebotah, I see he's out sick15:33
ryebot^ Anyone else want to take a swing at it? :)15:34
Chipacano, but i'll take a swing at a cuppa tea15:45
ogra_such a "danceish" day ...15:45
ogra_swing and salsa ...15:46
ralsinaI have two snaps in my account I really don't care about anymore (gatertest and gatedtest) since they were used for OLS development. However, neither one has the trashcan icon to delete it. Can any of you people delete them?15:53
ralsinaThey are https://dashboard.snapcraft.io/dev/snaps/6115/ and https://dashboard.snapcraft.io/dev/snaps/6114/15:54
ogra_GRRRRR15:55
* ogra_ curses u-boot ... 15:56
ogra_finally got 2017.01 building for the hummingborat ... now the SPL doesnt init it ... :(15:56
Facuralsina, I don't know if that's possible after they got releases...16:06
ralsinaFacu: hmmm ok, that's very annoying16:06
roadmrmake them private, then nobody will be able to see them at least16:07
Facuralsina, mmm... I have this package, with a release to edge, and I can delete it! https://dashboard.snapcraft.io/dev/snaps/7466/16:07
niemeyermorphis: The image is way too large at the moment, at 2.8GB16:08
Facuthis one I can not delete: https://dashboard.snapcraft.io/dev/snaps/7544/16:08
ralsinaFacu: can't unpublish it either, or can't see how to, even when the help says I can "unpublish at any time"16:08
sergiusensralsina: have you tried `snapcraft close <snap-name> <channel>`?16:09
Facuralsina, that what sergiusens says16:10
ralsinasergiusens: nevwer thought I needed to use the command line to make something go away on a website16:10
Facuralsina, I unpublished everything in https://dashboard.snapcraft.io/dev/snaps/7544/ and still can not delete it16:10
Facunessita, may you know what makes a package "undeleteable"?16:10
ralsina"Your account lacks permission to close channels for this snap."16:10
ChipacaFacu: somebody installing it, is what i was told way back16:11
FacuChipaca, "in the process of installing it"? mmm16:11
ralsinaoh, well, who cares16:11
Chipacaralsina: but since you're here16:11
Chipacaralsina: (hola!)16:11
morphisniemeyer: hm16:11
ralsinaI'll rename them zzzzzfoo and zzzzzbar since they are in the middle of two snaps I actually care about :-P16:11
ralsinahola Chipaca!16:11
Chipacaralsina: what was that about you not being able to publish to edge from travis?16:11
morphisniemeyer: you killed the instance?16:12
morphisah no you didn't16:12
ralsinaChipaca: not travis, build.snapcraft.io16:12
niemeyermorphis: Yeah, still there16:12
ralsina Chipaca: it builds every commit, and then doesn't actually have a knob to make it release to edge16:12
Facuralsina, build.snapcraft.io pushes to edge every 'fades' release16:12
morphisniemeyer: hm, looks like I forgot to do the cleanup on the new install I spawned up this afternoon after my previous one got removed16:13
ralsinaFacu: how?16:13
Facuralsina, don't remember doing anything special16:13
=== chihchun is now known as chihchun_afk
ralsinaFacu: the only things the UI lets you configure is the repo and the package name16:13
ryebotI updated the relevant bug; if anyone could assist me with finding a fix or workaround, that would be awesome. https://bugs.launchpad.net/snappy/+bug/168707916:13
mupBug #1687079: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>16:13
Facuralsina, I had something in edge before setting up build.s.io16:14
Facuralsina, does your package? maybe that's a detail?16:14
=== heber is now known as heber_lunch
mupPR snapd#3387 closed: cmd: auto import assertions only from ext4,vfat file systems <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3387>16:36
mupPR snapd#3391 opened: tests: reboot after upgrading to snapd on the -proposed pocket <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3391>16:50
morphisniemeyer: running out of time, will ping you tomorrow again16:54
niemeyermorphis: Sounds good, thanks!16:54
ralsinaFacu: yeah, had stuff in all channels, really17:01
pedronisseems timeouts are really trying to stop me from landing snapd#3375 :(17:20
mupPR snapd#3375: snapstate,many: implement snap install --unaliased <Created by pedronis> <https://github.com/snapcore/snapd/pull/3375>17:20
=== heber_lunch is now known as heber
mupPR snapd#3386 closed: interfaces, osutil: move flock code from interfaces/mount to osutil <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3386>17:37
mupPR snapd#3357 closed: tests/lib: abstract build dependency installation a bit more <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3357>17:39
=== cachio_ is now known as cachio
cachioniemeyer, after review many errors in travis, I think basd on the errors that are causing the fails perhaps we could adopt a different strategy to deal with flaky tests18:13
niemeyercachio: That's a bit too general to correlate.. what's the issue, what's the first approach, what's the different approach, etc? :)18:14
niemeyercachio: Sounds like a forum topic.. it'll quickly go out of hand here18:14
cachioniemeyer, have you ever read this post https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html ?18:14
cachioniemeyer, agree with that, I'll move out to the forum18:14
niemeyercachio: We need data about what's going on.. not a blog post :)18:15
cachioniemeyer, of course, i am caollecting data18:15
niemeyercachio: I suggest starting small.. take one single test that you'd like to fix and explain what is happening and how you'd like to fix it18:15
niemeyercachio: Rather than trying to solve the world at once18:15
cachioniemeyer, i am doing that, but i see that some tests are failing because of external dependencies such as internet connection18:16
cachioniemeyer, just to clarify, I am not saying that we dont have to fix tests18:17
cachioniemeyer, I'll start a forum thread, better :)18:18
niemeyercachio: Yeah, I get it.. I'm just suggesting to start with small but solid incremental steps18:18
naccsigh, anyone else getting proxy errors for LP to the store?18:18
nacci'll wait a bit and retry, but just wondering if it's a known issue18:18
niemeyercachio: Thanks!18:18
* zyga feels terrible but returned to the office for his laptop18:25
mupPR snapcraft#1331 opened: integrations: use the snapcore/snapcraft docker image in travis <Created by filibtester> <https://github.com/snapcore/snapcraft/pull/1331>18:48
pedroniswell for sure we have now a category of tests where prepare usually takes less than the timeout but sometimes more18:49
mupPR snapd#3375 closed: snapstate,many: implement snap install --unaliased <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3375>18:51
niemeyerpedronis: fgimenez has a branch bumping the timeout.. did we merge this?18:54
pedronisniemeyer: it was bumped to 20mins, but I still saw prepare kill-timeout failures18:57
pedronistoday18:57
pedronisanyway now that I have green run I don't see anythin taking more than 1000s,  so it's either load or network when they take that really long time19:04
=== ondra- is now known as ondra
niemeyerpedronis: 20 minutes preparing?  That ought to be something frozen19:20
cachioniemeyer, do you know the configuration needed to run tests in fedore?19:30
cachiofedora?19:30
niemeyercachio: I wouldn't worry too much about anything that is not already enabled in Linode on master19:32
cachioniemeyer, ok19:32
=== cachio is now known as cachio_afk
mupPR snapd#3392 opened: interfaces: add minimal seccomp resolver to avoid backward compatiblity issues <Created by mvo5> <https://github.com/snapcore/snapd/pull/3392>20:01
mupBug #1693016 opened: snap install conjure-up fails if juju snap installed <Snappy:New> <https://launchpad.net/bugs/1693016>20:04
kyrofastore... proxy errors....20:28
mupPR snapcraft#1332 opened: cli: provide a whoami command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1332>20:33
kyrofanoise][, I'm having trouble installing the snap I just released into a branch. `snapcraft status` shows it's there. Is this a cache issue?20:37
kyrofaIt's been about ten minutes now20:37
noise][kyrofa: not a cache issue, but let me see if someone can help investigate20:44
kyrofanoise][, alright, thanks. Snapcraft show me http://pastebin.ubuntu.com/24637022/ , but when I install I get http://pastebin.ubuntu.com/24637027/20:46
kyrofaNote that pr-283 works fine, however20:46
Facuhola kyrofa20:47
kyrofaHey Facu :)20:47
noise][kyrofa: refresh into the branch works20:52
kyrofanoise][, weird... how can that be?20:53
kyrofanoise][, but install fails?20:53
noise][different endpoints, might be a bug in details (used for install), but if so clearly we are missing a big test!20:53
Facunoise][, you say that a refresh from the branch worked, while installing from that branch didn't?20:57
noise][yes: https://pastebin.ubuntu.com/20:58
noise][and although the output doesn't show it, it did change to the proper revision20:59
kyrofanoise][, wrong link, I think :P21:05
noise][woops21:05
noise][https://pastebin.ubuntu.com/24637178/21:06
Facukyrofa, would you please tell me the snap_id of that package?21:06
kyrofaFacu, njObIbGQEaVx1H4nyWxchk1i8opy4h5421:07
Facukyrofa, thanks!21:07
mupBug #1693037 opened: Can’t start a snap app <Snappy:New> <https://launchpad.net/bugs/1693037>21:10
Facukyrofa, it's strange, indeed21:11
kyrofaFacu, yeah, weird. Any ideas?21:13
Facukyrofa, not yet, and I need to run now :(, but I'll grab this until I figure it out, can I get to you tomorrow about this?21:14
Facu(if somebody didn't get to you with this before)21:15
=== cachio_afk is now known as cachio
thomikyrofa: I'll take a look after I'm out of this call21:19
kyrofathomi, alright I appreciate it, thank you.21:19
thominp21:19
thomikyrofa: OK, I'm out of the call. Just to make sure I understand the problem, you have some branches that you can refresh into, but you can't install from?21:56
kyrofathomi, one, yes. The other branches work fine21:56
thomiit's the 283 branch that you can't install from?21:56
kyrofa28421:56
kyrofa283 works21:57
thomiahh ok. Thanks.21:57
thomiI'll investigate. When's your EOD, and how should I let you know what I find if it's late?21:57
thomiwgrant: So the branch kyrofa is looking for doesn't exist in snaprevs: https://pastebin.canonical.com/188993/ I guess this may be an SCA integration issue?22:10
kyrofathomi, in about an hour or so, but this is standing in the way of some stuff so I'll be checking back periodically-- feel free to just ping me here22:11
thomikyrofa: ok, thanks22:11
wgrantthomi: Yeah, I think it's a combination of SCA and snapd bugs.22:12
wgrantthomi: Bret's refresh worked because snapd doesn't always parse out the branch22:12
thomibut you think it's not actually getting a revision from that branch?22:13
thomiI cna't see hwo it could, if we don't have that branch in our db22:13
thomiugh. typoing22:13
thomiwow...22:13
wgrantWell, there could easily be a bug in snapdevicegw that caused this22:14
wgrantBut the code in this case is pretty clear, and looking at snapd HTTP requests the client is doing some weird stuff.22:14
wgrantTrying to work out exactly what22:14
wgrantHm. I just told it to refresh to "lalala", it made a query for "lalala/stable" which is correct, got an empty response as expected, but then said it upgraded22:15
wgrantAnd before I told it to refresh to "stable/1234" and it asked for edge.22:16
kyrofaYikes22:18
wgrantOh, no, that latter one was a typo.22:18
wgrantBut it still says the snap was refreshed even if the server returns nothing at all for the channel.22:19
wgrantSo Bret's test doesn't reveal anything, really. The only real issue here is that the branch never got pushed for some reason.22:19
thomiwgrant: want me to file a snapd bug for the poor UX around refreshing, while you investigate the push issue?22:20
wgrantthomi: Sounds reasonable.22:20
wgrantThe really confusing thing is that it prints the version and says it was refreshed, even if nothing changed.22:20
wgrantAnd also even if the server doesn't give anything to suggest that the requested channel actually exists.22:21
kyrofawgrant although note that snapcraft thinks it does: http://pastebin.ubuntu.com/24637022/ .22:21
Chipacawhat's the ux around refreshing that's bad?22:21
Chipacaand what is the weird stuff you see snapd doing?22:22
wgrantkyrofa: Right, somehow it didn't make it from dashboard to the services that serve devices.22:22
wgrantChipaca: wgrant@lamuella:~$ sudo snap refresh core --channel=totally/bogus22:22
wgrantcore (totally/bogus) 16-2.26.3+git204.1bc8375 from 'canonical' refreshed22:22
kyrofawgrant, ah, right22:22
Chipacahuh22:22
thomiwgrant: what's worrying is what snapd shows if you do 'snap info core' after that22:22
Chipacayeap, that's a bug22:22
thomiI'm filing the bug now...22:23
wgrantMay 24 08:22:27 lamuella /usr/lib/snapd/snapd[12917]: logger.go:75: DEBUG: < "HTTP/1.1 200 OK\r\nContent-Length: 40\r\nContent-Type: application/json\r\nDate: Tue, 23 May 2017 22:22:27 GMT\r\nServer: gunicorn/19.7.1\r\nStrict-Transport-Security: max-age=2592000\r\nX-Request-Id: e8ab92e3-449f-4531-9cf1-60933ff2f0b1\r\nX-Vcs-Revision: 51cfdf0\r\n\r\n{\"_embedded\":{\"clickindex:package\":[]}}\n"22:23
wgrantSo the server correctly returned nothing.22:23
Chipacathomi: so it changes the tracking channel, indeed22:23
Chipaca:-(22:23
Chipacathomi: wgrant: nice catch22:23
Chipacahmmmm22:24
Chipacawait22:24
wgrantI don't think this can be a server-side change.22:24
Chipacawhy is the store not saying something like "404"?22:24
wgrantBut let me check.22:24
wgrantChipaca: It's a metadata request.22:25
wgrantIt takes multiple snaps, so can't 404.22:25
Chipacaright22:25
wgrantUnless it's meant to, that'd be weird and a bug in the new services.22:25
wgrantWell, a bug in the API22:25
wgrantAnd a bug in the new services for not emulating that API bug22:25
Chipaca:-)22:25
ChipacaI didn't remember metadata requests started with the _embedded/clickindex:package thing, thought that was just search22:26
thomihttps://bugs.launchpad.net/snapd/+bug/1693042 filed22:26
mupBug #1693042: snapd will refresh to a channel that does not exist <snapd:New> <https://launchpad.net/bugs/1693042>22:26
thomisadly it's everything that CPI used to return.22:26
Chipacaso, about the message, that's the correct message for when you switch to a channel that has the same snap revision as you already have22:26
Chipacaie if you then do "snap refresh --channel=<whatever you were in before>" it'll say refreshed22:27
thomiChipaca: but you agree that it's the wrong message for the case where the channel you're switching to doesn't exist?22:27
thomiyeah, that makes sense to me22:27
Chipacathomi: the bug is that it switches successfully to a channel that doesn't exist, indeed22:27
thomiI must remember to refresh my core back to a channel that exists :D22:27
wgrantChipaca, thomi: Confirmed that the same thing happens on CPI, so it's not a regression.22:29
thomiGood.22:30
wgrantThere is a slight behaviour change in that CPI didn't include _embedded/clickindex:package at all if it was empty, but snapd doesn't care about that.22:30
thomioh, are you sure? I could imagine perhaps snapd would fail to parse the json of that was missing, resulting in a different error path22:31
wgrantI just tested.22:31
thomiahh ok22:31
wgrantOverriding SNAPPY_FORCE_CPI_URL=http://cpisnap.ols.internal/api/v1/22:31
Chipacaso, here's one thing i don't understand22:32
thomiwgrant: ahh22:32
Chipacathe metadata response is supposed to be22:32
Chipacaa json document with 'snaps' and 'fields'22:32
Chipacae.g. something that starts {\"snaps\":[{\"snap_id\":\"....22:32
Chipacaand that's what you get when you refresh to 'beta'22:33
Chipacaactually, give me a bit22:34
wgrantYou might think that22:34
* Chipaca 's not too bright right now22:34
wgrantsnapd probably strips the extra wrapping pretty early.22:34
wgrantBut checking.22:34
thomiit's parsed in store.go22:35
wgranttype searchResults struct {22:35
wgrant        Payload struct {22:35
wgrant                Packages []snapDetails `json:"clickindex:package"`22:35
Chipacathe log is from the wire, directly22:35
wgrant        } `json:"_embedded"`22:35
wgrant}22:35
Chipacawhich is what i'm looking at22:35
wgrantThat's used for metadata as well22:35
wgrantChipaca: The *request* looks like what you pasted22:35
wgrantThe response is not.22:35
Chipacaah, sorry then22:35
Chipacai should redo this without the macaroon; it makes it very hard to read the logs22:36
Chipacadoes the same thing happen when refreshing more than one snap i wonder?22:38
Chipaca(yes it's a different codepath)22:38
Chipaca(shut up)22:38
wgrantChipaca: It's not possible to override the channel for a multi-snap refresh, but I imagine so.22:39
Chipacaah, of course it won't happen22:39
Chipacabecause you can't set channel in the other codepath22:39
Chipaca(that's why the single snap codepath exists and is different)22:39
wgrantIf they were already on an invalid channel they'd erroneously think they were up to date, though.22:39
Chipacawgrant: they'd think that because we told them so, you mean? :-)22:40
wgrantChipaca: Well, ish.22:40
wgrantChipaca: Long term we probably want the server to be able to report "hey, this channel doesn't exist any more, you should probably warn your user"22:40
wgrantWhich makes the distinction between "there is no update" and "there is nothing at all" important.22:40
wgrantEven on non-switching refresh22:41
Chipacaah that reminds me22:41
wgrantAnd bulk refresh22:41
Chipacaniemeyer: is there anywhere i can read about the reasoning behind not having snapd boot a system of a branch when the branch closes?22:41
niemeyerChipaca: Probably not in the depth you'd like to hear about, but I'm happy to provide the proper rationale here or in the forum22:42
Chipacaniemeyer: and perhaps more importantly, a branch that closes can't ever be re-used, right?22:43
niemeyerChipaca: It can, and that's one side of the argument.. we have existing behavior in that regard22:43
niemeyerChipaca: Think beta closing22:44
Chipacawell.. beta has a defined meaning around risk22:44
Chipacahotfix, a lot less so22:44
Chipacaand my hotfix could well be my neighbour's nightmare22:45
niemeyerChipaca: Interestingly and neatly, the behavior is exactly the same in both cases as far as channels are concerned22:45
niemeyerChipaca: beta falls back to candidate once closed.. the branch falls back to its underlying risk level22:46
Chipacaniemeyer: I can see the mechanics at our end being the same and that being nice and consistent, but I fear the two things are going to be used very differently and that's going to get users into trouble22:46
niemeyerChipaca: In my mind it's quite the opposite.. It sounds terrible to fiddle with configuration behind the administrator's back22:47
Chipacabasically the scenario where today there's a stable/hotfix for problem A, that's incorporated into stable and hotfix is closed, and then that makes problem B happen, so a hotfix for that is put out that reverts22:47
Chipacai'm _just_ talking about letting branches be reused22:48
kyrofathomi, wgrant so the refresh versus install test wasn't real. The real issue with my branch not showing up is a communications breakdown between the dashboard and the backend?22:48
niemeyerChipaca: Okay, I don't understand the case you just described22:48
Chipaca(it's bad in both cases, the reverting-to-underlying and the non-reverting-to-underlying)22:48
Chipaca(for different but similar reasons)22:48
Chipacaaww22:48
thomikyrofa: that's a reasonable summary, yes22:48
niemeyerChipaca: If stable/fix-terrible-problem is closed because stable has the fix, it will fallback to stable.. end of story?22:49
Chipacaniemeyer: i need a way to just dump my brain state somewhere for you to look at22:49
Chipacawriting is too much work22:49
niemeyerChipaca: :D22:49
Chipacaniemeyer: the way i imagine branches being used is to address urgent problems with particular users (or classes of users)22:50
niemeyerChipaca: Yeah, that's one reasonable use case22:50
kyrofathomi, if I release to another branch, will that interfere with your debugging?22:50
Chipacae.g. you put out a stable, a week later it's discovered it's quietly corrupting rpi3s that have a particular wifi card22:50
Chipacayou can't bump roll back the release for x reason22:51
Chipacayou can't tell them to jump to beta for some other reason22:51
Chipacaso you put out a hotfix for them22:51
thomikyrofa: should be fine22:51
Chipacaniemeyer: then you fix the underlying problem (or you think you do!) and close the hotfix branch after the next release to stable22:51
niemeyerOkay, so far with you22:52
Chipacaniemeyer: so now the users that are on hotfix are tracking stable again22:52
niemeyerYeah, woohay22:52
niemeyerBug fixed, people are back into the normal line22:52
Chipacaniemeyer: but now you find out that what you thought was a fix from the above problem is now making printers on people that have a particular bluetooth card on rpi 2s print nasty messages22:53
Chipacaniemeyer: so, you put out a hotfix for those users22:53
Chipacathe hotfix is basically undoing what you thought was a fix (but not quite, because of other unrelated changes)22:53
Chipacaniemeyer: with me so far?22:54
niemeyerOkay.. the problem there is that the branch name was reused, which is a very bad idea if you are convey two opposite meanings to the same content22:54
niemeyerEven snapd aside, people might end up installing the wrong thing because they've read someone's blog post abou tit22:54
niemeyerSo, IMO a case of "doctor, it hurts!"22:55
Chipacaniemeyer: so how would this play out, in your view? what's the bit that went wrong?22:57
niemeyerChipaca: Reusing the branch name for something that is not intended to be a real sequence..22:58
Chipacaniemeyer: right, how is that being explained/communicated/enforced?22:58
kyrofathomi, alright, done. I'm now unblocked22:58
niemeyerChipaca: This is just like any other channel.. when we put two sequential things into a channel, we need to have in mind that people might install the first, the second, or both in succession..22:59
thomikyrofa: \o/22:59
Chipacathomi, wgrant, spotted where we mess up i think (still digging though)22:59
niemeyerChipaca: and again, this is not specific to branches.. every channel behaves like that22:59
wgrantkyrofa: Releasing to another branch would have actually run into the same problem, but we've fixed both now.22:59
wgrantkyrofa: Your missing branches are no longer missing.22:59
wgrantkyrofa: We're investigating how this happened.23:00
kyrofawgrant, thanks for that23:00
Chipacaniemeyer: ok, i need to think about this some more. you're probably right, but something has me uneasy23:00
niemeyerChipaca: Thanks for trying to find out what it is.. sometimes we do find curious edge cases with those conversations23:00
noise][fwiw, i'm in total agreement with niemeyer here on the branch behavior23:10
noise][publishers can absolutely screw their users if they repurpose a branch name for different cases, so they shouldn't do that, and we should make it clear in the docs23:11
noise][but there's absolutely cases where you'd want to re-open a closed branch23:11
wgrantkyrofa: We're still investigating how nextcloud got into that bad state, but it looks like it might be a race in dashboard.snapcraft.io's automatic review process. The new store infrastructure noticed the data inconsistency and refused to accept the channel updates. We'll get alerted if it happens again, and we have a button to fix it immediately.23:26

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