/srv/irclogs.ubuntu.com/2018/01/29/#snappy.txt

bashfulrobotIs there a way to utilizr a bz2 file in the source directive?02:48
bashfulrobotutilize*02:48
bashfulrobotI'm working on a snap for restic in which the author prefers that the snap use the "official" binary (hope to change that later). But his releases come out as a bz2 file. When targeting the file I get an error stating that there is no handler for the bz2 file.02:50
bashfulrobotI'm in the middle of working on it - so was hoping for a quick ping type answer, otherwise I will move this over to the forum.02:51
bashfulrobotThanks all.02:51
Son_Gokubashfulrobot: atm, there's no bz2 support in snapcraft, iirc03:53
Son_Gokudebian doesn't generally encounter bz2 that much anymore, so I would guess they didn't think about it03:53
bashfulrobotSon_Goku: thanks for the info. I had pretty much came to that same answer. I guess I'll have to figure out the best way to maybe wget the file in the build, and extract, then just use `organize` to getit where it needs to go.04:32
mborzeckimorning06:07
Son_Gokumorning06:11
* Son_Goku needs to sleep06:11
Son_Gokuanyway, if anyone sees robert-ancell, can someone poke him about this? https://github.com/snapcore/snapd-glib/issues/3206:12
zyga-ubuntuo/06:24
mborzeckiSon_Goku: zyga-ubuntu: morning guys06:25
zyga-ubuntuhey, good morning06:27
zyga-ubuntuuefi greeted me today with "ubuntu (disk not present)"06:27
zyga-ubuntuI think this is not a happy day06:27
* zyga-ubuntu boots from usb and hopes the disk isn't dead yet06:29
mborzeckizyga-ubuntu: whad did you do? another dead disk?06:32
zyga-ubuntumborzecki: no, just booted it again today06:37
zyga-ubuntuman, I'm not lucky06:37
zyga-ubuntuit shows up and mounts from live media06:37
zyga-ubuntudrive not present...06:38
mborzeckisounds like bad news06:38
bashfulrobotHey guys (morning to those of you in Europte, etc)06:39
bashfulrobotI have a snap that I'm getting ready for snapcrafters.06:39
bashfulrobotIt is going to need classic confinment as it is a backup program.06:40
bashfulrobotGoing through the checklist it states "Convert the snap to `strict` confinement, or `classic` confinement if it qualifies". Is there some sort of qualifier process to allow a classic confiment for hte store?06:41
bashfulrobotAnd then a few lines down it states to move it into beta once it has been made either strict or classic. Do others generally just do locally testing in devmode nad hten call the comminuity in for review?06:42
bashfulrobotonce in the beta channel?06:42
* bashfulrobot getting sleepy - almost bed time.06:43
zyga-ubuntubashfulrobot: hey06:50
bashfulrobothello06:50
zyga-ubuntubashfulrobot: you can request classic confinement on the forum (forum.snapcraft.io), there is a process to follow there06:50
bashfulrobotI'll search it up then.06:51
zyga-ubuntubashfulrobot: if you can become a strictly confined snap it is much easier, obviously, but for a backup program it may be challenging, depending on the use-cases06:51
zyga-ubuntubashfulrobot: you can test in classic mode as well, though devmode and classic are quite different06:51
bashfulrobotWell basically you need ot be able to backup any location on the file system06:51
bashfulrobotI was under the impression classic was the onbly way to do that06:52
zyga-ubuntubackup and restore, which is read and write anywhere06:52
zyga-ubuntuyes, I think so06:52
bashfulrobotexactly06:52
zyga-ubuntuyou *can* do that in devmode06:52
zyga-ubuntubut it's more tricky06:52
bashfulrobotok, I'm going to apply for classic then06:52
zyga-ubuntuand there's no interface for backup programs yet06:52
bashfulrobotah ok.06:52
zyga-ubuntusorry for brief answers, I think monday doesn't like me (my computer is not working)06:52
bashfulrobothey - nooo worries06:52
bashfulrobotIt's almost 11 pm Sunday for me... so my brain is giving up on me. :-)06:53
zyga-ubuntu"logical sector size is zero"06:54
zyga-ubuntumy ESP partition is broken06:54
zyga-ubuntuok, that's it06:54
zyga-ubuntuI'm turning this machine off and I'll go and buy a new computer today06:54
zyga-ubuntuI'm so so so fed up with it06:54
zyga-ubuntubashfulrobot: enjoy your evening and thank you for making snaps!06:54
bashfulrobotno worries! Last questoin - I see that the requests for classic seem to be in the store category. I'll put my request in there. Appreciate the direction!06:56
bashfulrobotzyga-ubuntu: hope the day gets better!06:56
zyga-ubuntuyes, the store category is right06:58
zyga-ubuntugood mornin mvo07:06
mvohey zyga-ubuntu - good monring07:08
mvomorning even07:08
mvozyga-ubuntu: shall we continue with this systemd shared unit today?07:08
bashfulrobotzyga-ubuntu: appreciate the help. Classic has been requested. Have a good day. I'm off to bed.07:08
* bashfulrobot zzzzzzz07:09
zyga-ubuntumvo: yes, let's do that; though please forgive me for being grumpy today as my computer has a broken ESP partition and I'm on the backup laptop without my work07:12
zyga-ubuntumvo: I'm throwing the towel on my desktop today07:12
mvozyga-ubuntu: "esp"?07:13
mvozyga-ubuntu: sorry to hear that things are broken :(07:13
zyga-ubuntumvo: the system boot partiotion on efi systems07:13
mvozyga-ubuntu: ohhh, ok07:13
zyga-ubuntumy disks are failing on me :(07:13
mvozyga-ubuntu: get ssds :P07:14
zyga-ubuntuI can boot the live media but I cannot boot the disk anymore07:14
mvozyga-ubuntu: when they fail, they fail faaaaster07:14
zyga-ubuntumvo: yeah, I'm considering just getting out and going to buy a new computer now07:14
zyga-ubuntuhahaha07:14
mupPR snapd#4558 opened: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4558>07:16
mborzeckimvo: morning07:16
mborzeckizyga-ubuntu: get intel ssds, they got crazy 5y warranty07:17
mborzeckialready had 2 disks replaced under warranty :) not a single complaint07:17
mvomborzecki: goooood morning07:18
mborzeckiyocto segfault thing, i can reproduce it on 2.31 too07:20
mborzeckia simple fix that resolves/masks the problem is moving progress bar Finished() call in store dowload to happen after checking the errors07:21
mborzeckigood run log with breadcrumbs; https://paste.ubuntu.com/26482312/07:21
mborzeckiotherwise the crash looks like this: https://paste.ubuntu.com/26482304/07:22
mborzecki2018/01/29 07:16:11.641340 progress.go:71: progress adapter--- &{task:0x967d8780 unlocked:true label:core total:8.0797696e+07 current:2.784677e+06}07:22
mborzecki2018/01/29 07:16:11.641850 task.go:248: -- in task 0xb77006fc set progress, state 0xe3f07:22
mborzeckithese 2 lines are interesting, the first one is pbar.Finished() in store.go, the second is a call to task.SetProgress() inside pbar.Finished()07:24
mborzeckisomehow the pointer to the task changed from 0x967d8780 to 0xb77006fc07:24
zyga-ubuntumborzecki: which golang is used on that yocto build?07:25
mborzecki1.907:26
zyga-ubuntumborzecki: is it a compiler bug maybe?07:26
zyga-ubuntumborzecki: any patches in ubuntu or debian or any patches in yocto that may be relevant?07:26
mborzeckiupdate to 1.9.3 is on my list, but the interaction cycle is long07:26
mborzeckilooked through commits between 1.9 and 1.9.3 nothing that looks relevant07:27
zyga-ubuntumborzecki: do you think this is something in our code?07:27
mborzeckinot sure yet07:27
mborzeckifor instance, no clue why we try to do Kill() on the tomb twice, but the same sequence is visible in the 'good' run :/07:28
mborzeckialbeit in the good run there's no call to pbar.Finished()07:28
mvomborzecki: oh, doing the Kill twice sounds wrong, do you have more info?07:29
mvomborzecki: also no call to Finish sounds wrong :(07:29
mborzeckimvo: take a look at the logs i posted07:29
mborzeckithis is the diiff i'm working with: https://paste.ubuntu.com/26482348/07:30
mborzeckimvo: in taskrunner.Ensure() there's a call to tomb.Kill() for the running task07:32
mborzeckiaiui that kill will trigger cancel on the context07:33
mvomborzecki: interessting07:36
mvomborzecki: I guess I'm stating the obvious, it looks like task.state is corrupted, might be interessting (no idea how painful it is to do one of those runs) to output the value of the task.state pointer to see when it becomes invalid07:43
kalikianamorning snappy07:45
zyga-ubuntuhey kalikiana07:46
mborzeckikalikiana: morning07:46
mborzeckizyga-ubuntu: mvo: forcing a static build of snapd makes the problem go away https://paste.ubuntu.com/26482426/07:54
mvomborzecki: oh, this is also interessting. how dynmaic is the dynamic build? i.e. what is linked?07:56
zyga-ubuntuhmm ...07:57
mborzeckimvo: nothing special, libc and  libstd (that's go)08:01
pstolowskigood morning!08:01
mborzeckipstolowski: morning08:01
zyga-ubuntumborzecki: I wonder if that would fail if you used a ubuntu-build of snapd08:03
mborzeckibtw. also according to the forum post the problem is only on x86, does not appear on x86-6408:03
zyga-ubuntumborzecki: I read about some peculiar crash of golang when gentoo used new kernel optimization flag and broke the vsdo08:03
mborzeckii've tried rebuilding snapd locally, with same flags but no success08:04
zyga-ubuntumborzecki: that was a golang bug, assuming too much about kernel behavior08:04
mborzeckii mean, GOARCH=386 GO386=387 CGO_ENABLED={0,1} all worked fine when deployed to the vm08:05
mborzeckihoped to use -race but it's 386 ;) so no race for me08:05
zyga-ubuntumborzecki: can you try a i386 kernel from ubuntu there?08:06
zyga-ubuntuand see if the same binary of snapd tests wokrs08:06
zyga-ubuntu*works08:06
zyga-ubuntujust a long shot but somethig that could help bisect the area that is broken08:06
mborzeckizyga-ubuntu: can you take a look at #4558? this is an easy one08:18
mupPR #4558: cmd/snap-mgmt: fix out of source tree build <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4558>08:18
zyga-ubuntuyep08:18
zyga-ubuntumborzecki: you could use | there08:19
zyga-ubuntuto make it an ordering-only rule08:19
zyga-ubuntumborzecki: just add a | before the new dependency08:19
zyga-ubuntueither way +108:19
mborzeckiyocto does out of the source builds by default, and this came up there :)08:21
mborzeckithere's actually a separate class for packages that have broken separation08:22
mborzeckizyga-ubuntu: mvo: could you take another look at 4487?09:03
mvomborzecki: sure09:07
zyga-ubuntulooking09:08
mvomborzecki: heh, sorry that my suggestion to use "internal" error was wrong09:08
mvomborzecki: looks good to me! zyga-ubuntu can merge once he finished (unless he has more suggestions of course)09:11
mborzeckimvo: thanks09:11
zyga-ubuntuyes, I'm just re-reading09:12
zyga-ubuntumborzecki: done, have a look please09:16
zyga-ubuntubrrr, cold, let me make some more tea09:16
mborzeckizyga-ubuntu: thanks, good catch09:17
zyga-ubuntumvo: I'm juming into lxd issue now09:20
zyga-ubuntumvo: I don't have anything to do before 4471 lands09:20
mvozyga-ubuntu: cool I'm working on xdg-settings final touches and then ~rc209:21
mvozyga-ubuntu: but let me know if I can do anything to help with that, happy to tweak the packaging09:21
zyga-ubuntumvo: land 447109:21
mvozyga-ubuntu: but my feeling is right now the solution is not clear09:21
zyga-ubuntuI think we're wasting time now09:21
zyga-ubuntuit's blocking everything related to mount work09:21
mvozyga-ubuntu: don't we need gustavo for this?09:22
zyga-ubuntuwell, I am waiting09:22
zyga-ubuntuI'm just saying it's a bit unreasonable now09:22
zyga-ubuntu(that branch hasn't been touched in weeks)09:23
* mvo nods09:27
Chipacamoin moin09:38
zyga-ubuntuho ho09:39
Chipacazyga-ubuntu: http://i.imgur.com/AAGJvD1.png09:39
mvoChipaca: \o/ you made my morning09:40
Chipacamvo: woo!09:40
Chipacamvo: how tho :-)09:40
mvoChipaca: the subway map09:40
Chipacait's rather brilliant, isn't it09:41
zyga-ubuntuneat09:41
mvoChipaca: oh yes09:41
mvolove it09:41
* kalikiana going for a short walk, need a little fresh air10:02
mupPR snapd#4559 opened: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>10:04
* ikey now unblocks solus sync. :p10:04
zyga-ubuntuikey: <bring on the kraken!>10:16
ikeypretty much lol10:16
ikeywe were gonna sync last night, but i couldnt get the snapd patch (above) working10:16
ikeyturns out i was missing a comma -_-10:17
ackkmvo, hi, it seems base-18/edge is still missing the distro-info csv that the version you gave me a while ago has. any chance you could push that fix?10:22
zyga-ubuntuikey: it's better to miss a comma than to miss the point10:23
ikeyhah10:24
* zyga-ubuntu gets back to being reasonable10:24
niemeyerzyga-ubuntu: I apologize for the delay. My #1 priority last week was to get our CI in good shape, as that unblocks and improves everybody's daily workflow.10:24
niemeyerzyga-ubuntu: This week I should get back to reviews and discussions10:24
zyga-ubuntuniemeyer: I understand that, no apologies needed; I think that code is critical enough to warrant the wait10:24
zyga-ubuntuniemeyer: I'm trying to get useful in other areas10:24
zyga-ubuntuniemeyer: and I think the new spread work is brilliant and we will benefit tremendously mid/long term10:25
zyga-ubuntuniemeyer: (and rest of canonical and anyone who uses it as well)10:25
zyga-ubuntuI always wished spread either did queueing or do dynamic allocation and now it does10:25
niemeyerzyga-ubuntu: I hope the benefit is immediate..10:25
zyga-ubuntuniemeyer: it is, I meant that it's not just short term benefit10:26
niemeyerzyga-ubuntu: The practical consequence is ~23 minutes runs, and no more limiting on the number of runs, so everybody gets more productive..10:26
niemeyerI postponed that for quite a while last year, but now it was getting a bit unreasonable..10:26
zyga-ubuntuand less issues hand holiding systems and re-starting failed tests due to overuse10:27
niemeyerAnyway, I hope that's now done10:27
ikeyi dont understand how or why my PR failed10:27
zyga-ubuntuikey: concurrent non-deterministic software that is connected to the internet has that property a lot10:28
ikey:D10:28
* kalikiana re10:36
zyga-ubuntuohh10:37
* zyga-ubuntu has an insight10:37
ikey.ubuntu.com?10:38
ikey>_>10:38
zyga-ubuntuno, maybe a fix for the bug mvo and me were fighting for a long time10:39
zyga-ubuntumvo: no double mounts!10:39
mvozyga-ubuntu: tell me more!10:40
zyga-ubuntumvo: hold on, just a teaser, let me do more experiments first10:40
* zyga-ubuntu fiddles thumbs while package builds10:43
mvoif I could get a review for 4342 that would be great. its the last bit of polish I would like to get in for ~rc210:56
kalikianaikey: you drank some punny water this morning? :-P11:03
ikeyperhaps. :p11:04
zyga-ubuntumvo: still no double mounts, things look good so far, let me do some more and then try a spread run11:08
mvozyga-ubuntu: what is the gist of the alternative idea?11:09
mvozyga-ubuntu: I'm really curious11:09
zyga-ubuntumvo: well, ... it's silly really11:09
zyga-ubuntumvo: one char less than yours probably11:09
mvozyga-ubuntu: hu?11:09
mvozyga-ubuntu: was there a typo in my unit?11:10
zyga-ubuntunot really, I don't quite know if you got the double entries because of that11:10
zyga-ubuntuso so far so good, I'll try to cause the problem by doing what you initially did to confirm11:10
mvozyga-ubuntu: so this is a mount unit, we still need all the scaffolding ? i.e. write out from snapd.postinst etc?11:10
zyga-ubuntumvo: yes11:10
mvozyga-ubuntu: ok - what does this one look like :) please, I'm really curious11:11
zyga-ubuntumvo: hold on, one test will tell me if this makes sense,11:11
zyga-ubuntuhmmmmm11:12
zyga-ubuntumvo: so, no double mounts but now I did what you did11:12
zyga-ubuntuunless lxd is doing something magic11:12
zyga-ubuntuok, to be sure I'll just reboot11:12
zyga-ubuntubrb11:12
zyga-ubuntumvo: sorry to keep you waiting, I don't want to say "got it" before it really works and I know *why*11:12
mvozyga-ubuntu: no double mounts inside lxd? or no double mounts inside *and* outside of lxd?11:13
zyga-ubuntumvo: so, let me check something, I'm on artful now, the container is xenial11:16
zyga-ubuntumvo: I disabled reexec to test my build easily11:16
zyga-ubuntumvo: (and it works so far)11:16
zyga-ubuntumvo: did you do anything different?11:17
zyga-ubuntumvo: I'll try to remove the package now, wonder if that will crash like it did before11:17
zyga-ubuntubut no double mounts, right sharing and snaps can be removed allright11:17
zyga-ubuntuso that counts as an improvement11:17
zyga-ubuntunow the last bit is packaging11:17
mvozyga-ubuntu: no double mounts outside as well?11:18
zyga-ubuntunope11:20
zyga-ubuntumvo: actually, I didn't run many snaps and now I see that:11:20
zyga-ubuntu(though I doubt this is related, probably a bug)11:20
zyga-ubuntuubuntu@experiments:~$ hello11:20
zyga-ubuntusnap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks11:20
zyga-ubuntubut I heard that there was a bug in lxd+apparmor about recently11:21
* zyga-ubuntu looks at loaded profiles11:21
zyga-ubuntuha11:21
zyga-ubuntuindeed11:21
zyga-ubuntuonly snapd-managed profiles are active11:21
zyga-ubuntuwe didn't load the profile for snap confine11:22
zyga-ubuntumvo: that's a separate bug manifested if you disable re-exec11:22
zyga-ubuntuJan 29 11:15:49 experiments apparmor[85]:  * Not starting AppArmor in container11:22
zyga-ubuntuJan 29 11:15:49 experiments apparmor[85]:    ...done.11:22
zyga-ubuntujdstrand, stgraber: ^11:22
zyga-ubuntuis this reported or am I dreaming things?11:23
zyga-ubuntumvo: once I load snap-confine's profile manually things are ok11:23
zyga-ubuntumvo: also inside process namespace11:23
zyga-ubuntumvo: ok, let me get back and make this into a proper patch I can share with you11:24
zyga-ubuntumvo: and see if I can run the test I wrote a while back against it11:24
zyga-ubuntujdstrand, stgraber: this is with apparmor 2.10.95-0ubuntu2.711:24
zyga-ubuntumvo: this still makes little sense to me, it works but the difference between your branch seems meaningless11:27
zyga-ubuntuhmmm11:33
zyga-ubuntumvo: wow, it even removed the package allright11:33
* zyga-ubuntu is so confused now11:33
zyga-ubuntumvo: it only printed tihs11:33
zyga-ubuntudpkg: warning: while removing snapd, unable to remove directory '/snap': Device or resource busy - directory may be a mount point?11:33
zyga-ubuntuand purged cleanly11:34
zyga-ubuntu:-))11:34
* zyga-ubuntu has a happy monday now11:34
ikeyzyga-ubuntu, https://www.youtube.com/watch?v=SsmVgoXDq2w :)11:34
mvozyga-ubuntu: did it actually stop your mount unit?11:35
mvozyga-ubuntu: it sounds a bit dubious :)11:35
mvozyga-ubuntu: but I'm keen to see your PR11:36
zyga-ubuntumvo: yes11:36
mvozyga-ubuntu: woah, ok11:36
zyga-ubuntumvo: it's totally clean11:36
zyga-ubuntumvo: it's so weird11:36
mvozyga-ubuntu: looking forward to the diff11:36
mvozyga-ubuntu: I have a small test in my PR that will be fun to test against11:36
mvozyga-ubuntu: by all means, if we have a solution and I will sing and dance and hug you :)11:36
zyga-ubuntume too :)11:41
zyga-ubuntuI'll build another package that doesn't involve any hand-holding anymore11:42
zyga-ubuntuand re-test11:42
zyga-ubuntuand then send a PR11:42
zyga-ubuntuand then find and cherry pick those tests we wrote11:42
ogra_you're so unromantic !11:42
zyga-ubuntuogra_: ?11:42
ogra_<zyga-ubuntu> I'll build another package that doesn't involve any hand-holding anymore11:43
zyga-ubuntubut first, my tea has run out11:43
zyga-ubuntumvo: btw I have t otell you11:43
zyga-ubuntuhaha11:43
ikeybanning hand holding, and we're coming up to the 14th soon enough11:43
ikeysheesh11:43
zyga-ubuntuogra_: but there will be hugging instead11:43
ogra_ah !11:43
zyga-ubuntumvo: my favourite tea is in stock again, it is called ...11:43
ogra_thats an improvement then :)11:43
zyga-ubuntusir adalbert's tea, soursop green tea11:43
zyga-ubuntuit has a big elephan on a decorative green box, not sure if you know it11:44
mvozyga-ubuntu: I don't let me search for it11:44
mvozyga-ubuntu: the downside of not sharing an office, I would love to try it :)11:45
zyga-ubuntuit's awesome, I can bring you a bag next time we meet11:45
zyga-ubuntumvo: the trick is that fruit they added, soursop11:48
zyga-ubuntumaybe if you like traditional tea it's "meh flavoured" but there's something really tasty about it11:49
mvozyga-ubuntu: I'm a bit of a traditionalist :) but also open so I'm certainly curious11:49
mvozyga-ubuntu: *cough* diff *cough* ;)11:49
mvozyga-ubuntu: else I'm gone for lunch and will be curious all the time11:50
zyga-ubuntumvo: here it is11:51
zyga-ubuntuhttps://github.com/zyga/snapd/tree/fix/fix-snap-share-v311:51
zyga-ubuntudon't open PR yet please, I didn't touch packaging11:51
zyga-ubuntumvo: if you build that and run it, does it show duplicates or misbehaves for you?11:52
zyga-ubuntuI'll proceed with proper tests now11:52
mvozyga-ubuntu: heh11:53
mvozyga-ubuntu: ConditionVirtualization=lxc11:53
zyga-ubuntuthat's just making it easy to ship11:53
mvozyga-ubuntu: I was thinking something like this this morning, if we should make it conditional11:53
mvozyga-ubuntu: and it works fine inside?11:53
zyga-ubuntuyes11:53
zyga-ubuntujust try it11:53
mvozyga-ubuntu: awesome11:53
zyga-ubuntuI'll fix packaging and get that spread test that tried it merged11:53
zyga-ubuntumvo: note11:53
zyga-ubuntumvo: the conditional part is irrelevant11:53
mvozyga-ubuntu: thank you11:53
mvozyga-ubuntu: hu? how so?11:54
zyga-ubuntumvo: there's no difference from what you wrote11:54
zyga-ubuntumvo: (your unit was started the same way in the end)11:54
zyga-ubuntumvo: I really don't know why this works yet11:54
mvozyga-ubuntu: it was, but mine ran on classic as well11:54
zyga-ubuntumvo: I used a different wants11:54
zyga-ubuntuahhhhh11:54
mvozyga-ubuntu: and caused all sorts of problems there11:54
zyga-ubuntuoh, that's it then11:54
mvozyga-ubuntu: yeah, thats it :)11:54
zyga-ubuntuon classic it's not sane11:54
zyga-ubuntuheh11:54
mvozyga-ubuntu: (I think at least)11:54
zyga-ubuntusounds like a good day then :)11:54
mvozyga-ubuntu: very nice, thank you!11:54
zyga-ubuntuok, let me finish the polish on this11:54
mvozyga-ubuntu: good luck, I get dinner now11:55
zyga-ubuntuenjoy!11:55
ackkmvo, should I file a bug about that missing file?12:04
zyga-ubuntuspread running12:05
zyga-ubuntukyrofa: IT'S HAPPENING12:05
* zyga-ubuntu thinks about lunch12:08
mupPR snapd#4560 opened: many: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>12:08
* pstolowski lunch12:12
zyga-ubuntuhmmm12:22
zyga-ubuntu- Download snap "lxd" (5522) from channel "stable" (sha3-384 mismatch for "lxd": got 3ed1910ba0d678da4820c74e35f288db4feb6dcad637466ab6c2bee26fca363b1cdb42e6b81e3f4fb834b672c64457c2 but expected 05ca4d0b5cd936beff0323dd786f2787fdf1783fbb7ffb89c09143c49a6e2269aca4a76e12d34422ea59826129f6009f)12:22
zyga-ubuntuChipaca: ^12:22
zyga-ubuntuis this store being funky or do I have a bad day?12:22
sitteris there a way to switch all of snapd to a different default channel? (e.g. install all future snaps and refresh all existing everything from edge)12:25
mborzeckizyga-ubuntu: mvo: disabling optimizations and inlining resolves the problem12:25
zyga-ubuntusitter: no, not at present12:32
zyga-ubuntumvo: things passed in my spread12:40
zyga-ubuntumvo: I think it's a winner, let' see how the PR fares12:40
ChipacaI got called out of physio to go pick up one of the boys who's being sick all over school (apparently)12:52
Chipacawill miss the standup12:52
Chipacattfn12:52
zyga-ubuntumvo: 4560 is ready for review12:53
zyga-ubuntubrb, see you at the call12:54
zyga-ubuntuls12:56
zyga-ubuntumvo: that pr needs one more patch, to give the mount unit the right name (following snap mount dir)12:58
zyga-ubuntuI'll do that12:58
mvozyga-ubuntu: ok13:00
* kalikiana going for lunch break in a few minutes13:28
mupPR snapd#4561 opened: tests: generic detection of gadget and kernel snaps <Created by plars> <https://github.com/snapcore/snapd/pull/4561>13:33
* kalikiana off for lunch now13:52
pstolowskimvo, hey, any specific reason why we abandoned these build stamp / system key branches?13:52
cachiomvo, hey13:54
mvohey cachio14:04
mvopstolowski: no specific reason, happy to pick them up again and/or work with you on them. the main issue was that we had too many open PRs and a lack of reviewers so I closed to postpone14:04
cachiomvo, is the rc2 comming today?14:04
mvocachio: thats my goal, however I need a review for the xdg-settings UI branch14:05
mvocachio: https://github.com/snapcore/snapd/pull/434214:06
mupPR #4342: userd: add support for a simple UI that can be used from userd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4342>14:06
cachiomvo, good, I'll take a look14:07
cachiomvo, I am also working on the test i18n which is failing on master for debian 9 and trusty14:08
pstolowskimvo, i see. okay, it seems like a requirement now14:13
mvocachio: thank you14:14
mvopstolowski: yeah, let me finish my current task, then I can merge master and see how bad the conflicts are :)14:15
mvopstolowski: there is also a forum discussion - have you seen that one?14:15
pstolowskimvo, not yet, but I think it's linked in one of the PRs14:17
zyga-ubuntumvo: another random failure14:18
zyga-ubuntu(on lxd / 4560)14:18
zyga-ubuntuI re-started14:18
kenvandinemvo, has the ship sailed for 2.31 yet?14:18
zyga-ubuntutimeout14:18
zyga-ubuntukenvandine: no, just initial RCs14:19
kenvandinegreat14:19
* zyga-ubuntu goes to cook some lunch and then gets back to mount magic14:19
kenvandinei thought jamesh's per-user mounts PR would be included14:19
kenvandineany chance of that?14:19
zyga-ubuntukenvandine: that's possible but unlikely14:19
kenvandine:(14:19
zyga-ubuntukenvandine: and even if so it won't be "live"14:19
zyga-ubuntukenvandine: it will only be useful once we have interfaces using that14:19
kenvandineyeah14:19
zyga-ubuntukenvandine: I asked jdstrand to review it14:19
kenvandinecan we get a milestone set on the PR?14:20
zyga-ubuntukenvandine: and I will jump onto it soon as now (just this minute) I have my review on my only pending work14:20
zyga-ubuntukenvandine: no, I think it's premature14:20
zyga-ubuntukenvandine: there are things to do there and it's not something that benefits users yet14:20
kenvandineyeah, but we need it in place for other things that we need for 18.0414:20
zyga-ubuntukenvandine: as it will only be used by interfaces and it's not yet, so I can merge it now and it's not changing anything yet14:20
kenvandinequickly running out of time14:21
kenvandineyeah14:21
zyga-ubuntukenvandine: sure but that's not related to merging14:21
zyga-ubuntukenvandine: development, sure14:21
kenvandinebut i'd like to get that stuff in for 2.3214:21
zyga-ubuntukenvandine: I will work on that branch (and related branches) this week for sure14:21
zyga-ubuntukenvandine: it's aggressive but we'll see what needs to be done14:21
kenvandinei'll talk to james as well, but I think he's already working on stuff that depends on it14:21
zyga-ubuntukenvandine: yes, I'm in contact with james14:22
zyga-ubuntukenvandine: and we discussed it (james and me) with niemeyer14:22
mvokenvandine: for what? session startup?14:23
kenvandinefreeze is march 1, so we'd really like to land his desktop portal work before then14:23
kenvandinemvo, this is for portals14:23
mvookay14:23
* mvo reads backlog14:23
kenvandinei'm just trying to make sure all the pieces we need fall into place before feature freeze14:24
kenvandineor soon after if we can get a freeze exception14:24
zyga-ubuntukenvandine: understood14:24
zyga-ubuntukenvandine: are those on halt now?14:24
zyga-ubuntuor can they be deveoped while this gets ready?14:24
kenvandinebut we really don't want an LTS release to pass without the portal work14:24
kenvandinethey can still be worked on14:24
kenvandineit's just over a month away though, so i'm getting stressed :)14:25
zyga-ubuntuniemeyer: ^ FYI14:25
kenvandinewe can still fix bugs in anything related after of course14:25
kenvandinebut we prefer not to beg for freeze exceptions for features :)14:26
kenvandinewhich are harder to get for an LTS14:26
ackkwhat's the $PWD a "daemon: simple" app is run from? is it $SNAP?14:27
zyga-ubuntuackk: I think it could be /root but ... I forgot, sorry14:28
* zyga-ubuntu -> kitchen14:29
ackka "command: bin/mybinary" works so I had thought it was $$NAP14:33
zyga-ubuntuackk: no, those are reslved and that doesn't matter14:34
ackkah I see14:35
zyga-ubuntuackk: those would work regardless of working directory14:35
ackkzyga-ubuntu, so if snap run --shell gives you the same env I guess it's /root14:35
zyga-ubuntuackk: ok, that's good then14:37
zyga-ubuntuwe tried to be consistent14:37
zyga-ubuntubut for services we wanted to be a bit special14:37
zyga-ubuntuHOME depends on user14:37
zyga-ubuntuanyway,14:38
zyga-ubuntulunch is ready now14:38
kalikianare14:40
ikey$HOME is where the <3 is14:40
* ikey ducks14:40
kalikianazyga-ubuntu: but are you ready for it? ;-)14:40
kalikianaikey: me $HOME es su $HOME14:41
ikeyd'aww14:41
ikeylol14:41
kalikianathat shoul've been "mi...", my Spanish spelling is terrible14:41
zyga-ubuntuHOME is when you don't have to change your namespace14:44
* zyga-ubuntu gets back to lunch14:44
cachiomvo, how should I make to reproduce the scenario with the ui for xdg-settings?14:58
cachiomvo, I would like to manually test it14:58
cachiomvo, is there any snap that I could use?14:59
zyga-ubuntumvo: man14:59
zyga-ubuntuluck hates me today14:59
zyga-ubuntu/dev/stdin: line 2: `<head><title>504 Gateway Time-out</title></head>14:59
zyga-ubuntumaybe you can hit the restart button14:59
mupPR snapcraft#1889 opened: tests: remove plainbox part from plugin tests <Created by jocave> <https://github.com/snapcore/snapcraft/pull/1889>15:05
mvocachio: sorry for the delay. you can run "$ go build && ./snap userd" and then install the brave snap15:11
mvocachio: and brave will ask you15:11
mvocachio: to make itself default browser15:11
cachiomvo, great, tx15:12
mvocachio: you may need to killall snap first if there is one already running in your session15:12
cachiomvo, ok15:16
jdstrandkenvandine: you do realize that you got the review of that PR preempted by another PR, right? ;)15:16
jdstrandI guess now that the reprioritized one is done, it is time to have the other one preempt things :P15:16
jdstrandanyway, it is on the list. it isn't for 2.31 at this point, so I put it behind the steam one for the moment, but I'll get to it soon15:17
* jdstrand notes that he will be at the snapcraft sprint this week so will likely not get to everything this week15:18
zyga-ubuntujdstrand: o/15:18
zyga-ubuntujdstrand: did you notice my earlier ping about an apparmor bug in apparmor inside lxdd?15:19
niemeyerzyga-ubuntu, kenvandine: What are the dependencies for the user mount PR?15:20
zyga-ubuntuniemeyer: I want jdstrand's ack on it, then we merge and iterate on small chunks15:20
zyga-ubuntuniemeyer: on specific points to iterate on: maybe handling /media, handling root user, handling updates, etc15:21
jdstrandI started to look at that pr on friday, but it is massive15:21
niemeyerYeah, that's not a good thing15:21
jdstrand(in terms of interelated changes)15:21
mborzeckihmm yocto uses `-linkshared ink against installed Go shared libraries (experimental).`15:22
mborzeckitaking snapd and linux_386_dynlink/libstd.so to artful i386 i can reproduce the segfault15:23
mborzeckithe address that ends up replacing task pointer is within a region like:15:24
mborzeckib770f000-b7753000 rw-p 012cc000 fd:00 1371       /usr/lib/go/pkg/linux_386_dynlink/libstd.so15:24
jdstrandzyga-ubuntu: I saw your comment re lxd. it sounds like the thing that I mentioned last week and alerted mvo to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1744738/comments/215:24
mupBug #1744738: snapd 2.29.4.2 ADT test tests/main/lxd failure with linux-hwe 4.13.0-30.33~16.04.1 <snapd (Ubuntu):New> <https://launchpad.net/bugs/1744738>15:24
mupPR snapd#4562 opened: debian: add a zenity|kdialog suggests <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>15:25
jdstrandzyga-ubuntu: ie https://irclogs.ubuntu.com/2018/01/09/%23ubuntu-devel.html#t03:34. my understanding is that jjohansen sent up a pr for the hwe kernel15:25
jdstrandzyga-ubuntu: is what you're seeing on an hwe kernel?15:25
zyga-ubuntujdstrand: I saw this on artful kernel15:32
zyga-ubuntujdstrand: with xenial userspace15:33
jdstrandzyga-ubuntu: that is essentially the same thing, yes. the hwe kernel is 4.13, like artful15:33
jdstrandzyga-ubuntu: it should just naturally fix itself once the patch makes it into the Ubuntu kernel15:34
jdstrandzyga-ubuntu: that said, I don't have the timing of this work. jj is traveling. tyhicks, do you happen to have details on the 4.13 kernel fix for apparmor profiles not loading inside lxd containers?15:36
zyga-ubuntujdstrand: ack, thank you!15:39
kenvandinejdstrand, indeed, totally understand15:44
kenvandinejdstrand, just getting things lined up so we have no surprises as feature freeze approaches15:45
mvozyga-ubuntu: I added some comments on 4560, would be awesome to have for 2.3115:48
mvozyga-ubuntu: do we need jamie for 4559?15:49
mvocan someone please review 4342? it soft blocks 2.31~rc215:50
zyga-ubuntumvo: I saw, thanks15:51
tyhicksjdstrand: no, I'm not sure how far along the 4.13 kernel fix is15:52
jdstrandkenvandine: note that snapd is not bound by feature freeze15:52
jdstrandkenvandine: I'm not sure if the portals side is, but a ffe would certainly be possible15:52
kenvandinejdstrand, exactly... but the portal work is15:53
kenvandineyeah, possible15:53
zyga-ubuntukenvandine: is the portal work something that is ubuntu specific15:53
jdstrandand I think that the portals side could continue without it15:53
kenvandinejdstrand, just trying to plan ahead :)15:53
zyga-ubuntukenvandine: we also have to have portals and snaps work on fedora and debian and opensuse and elsewhere15:53
kenvandinezyga-ubuntu, we're doing it with upstream15:53
jdstrandkenvandine: sure, I understand. it it just more of the 'everything it critical priority, so nothing is' syndrome15:53
kenvandinebut it's enabling snaps15:53
zyga-ubuntukenvandine: there are no freezes upstream!15:53
kenvandinezyga-ubuntu, but to get it in ubuntu :)15:54
zyga-ubuntu(kudos to upstream work)15:54
kenvandinethx15:54
mupPR snapd#4517 closed: data: add systemd unit that unshares /snap <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4517>15:57
zyga-ubuntumvo: yes15:58
zyga-ubuntujdstrand: low hanging fruit on https://github.com/snapcore/snapd/pull/455915:58
mupPR #4559: snap-confine/nvidia: Support legacy biarch trees for GLVND systems <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4559>15:58
zyga-ubuntuliterally one line of lstat of unlink to review15:58
mborzeckidisablink -linkshared makes the segfault problem go away15:58
* zyga-ubuntu feels ... sleepy... must coffee15:58
mborzeckieverything else is enabled15:59
zyga-ubuntumborzecki: that's something mwhudson may want to know16:00
zyga-ubuntuhe likely wrote it16:00
zyga-ubuntuniemeyer: please look at https://travis-ci.org/snapcore/snapd/builds/334699893?utm_source=github_status&utm_medium=notification16:00
zyga-ubuntuniemeyer: linode hicckup16:00
zyga-ubuntuniemeyer: returning HTML on api request16:00
zyga-ubuntuOur development team has been alerted to this error.  If you continue to have problems please contact support:16:00
zyga-ubuntueee16:01
zyga-ubuntugee16:01
zyga-ubuntuthey could _at least_ return that in a RPC response16:01
ackkmvo hi, around?16:01
mvoackk: yes16:01
zyga-ubuntuwith X-Linode-Coupon-Code: header16:01
ackkmvo any chance you could push the changes to include the distro-info csvs in base-18/edge ?16:02
cachiomvo, when I set the default browser on brave, then I open a url, it is opened on chrome16:02
niemeyerzyga-ubuntu: Thanks, this is the issue I mentioned earlier..16:03
niemeyerzyga-ubuntu: Shouldn't affect the run16:03
mborzeckihaha once linshared is disabled even remote gdb magically started to work16:03
niemeyerBut needs fixing as the machines stay around16:03
mvoackk: yes, its tiny, let me add it16:04
mvocachio: oh? what do you get with "xdg-settings get default-web-browser" ?16:04
cachiogoogle-chrome.desktop16:05
cachiomvo,16:05
mvocachio: did you get the dialog from snap userd asking for confirmation? it sounds for some reason it did not work. are you on the edge core?16:05
cachiomvo, beta16:06
cachiomvo, using the one I just built16:07
mvocachio: hm, you *might* need edge, I'm not 100% certain16:07
cachiomvo, updating16:07
mvocachio: you can check if you have /snap/core/current/usr/bin/xdg-settings - it should consists of a bunch of dbus- calls16:07
cachiorefreshing16:07
mvocachio: but updating is easier :)16:07
mvoackk: pushed, let me trigger a built16:07
cachiomvo, in progress16:07
cachiomvo, tx16:08
ackkmvo, thanks!16:08
mvoackk: I pulled in distro-info-data (so just the csv) should be availalbe in ~30min (once the build is finished)16:10
ackkmvo, is it automatically published?16:10
mvoackk: it should be, yes16:10
ackkah, cool16:10
ackkthanks16:10
zyga-ubuntukyrofa: https://github.com/snapcore/snapd/pull/456016:15
mupPR #4560: many: fix removal of snaps inside LXD <Created by zyga> <https://github.com/snapcore/snapd/pull/4560>16:15
ackkmvo, it seems some builds failed16:23
mvoackk: yeah, the ports nameserver lookup failed, looks very internal to me16:29
mvoackk: meh, all failed16:29
mvoackk: looking at it now16:30
* zyga-ubuntu afk but will be back, needs to refresh16:32
niemeyerlxd pr reviewed16:52
mupPR snapcraft#1889 closed: tests: remove plainbox part from plugin tests <bug> <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1889>17:00
kyrofazyga-ubuntu, yeeeeesssssss17:00
zyga-ubuntukyrofa: indeed17:01
zyga-ubuntukyrofa: we're just polishing the details17:01
zyga-ubuntubut it works for real17:01
kyrofazyga-ubuntu, no security review yet, does it have security implications?17:02
zyga-ubuntukyrofa: nope17:02
zyga-ubuntukyrofa: it's all good17:02
kyrofaSo happy to hear it, thanks for sticking with it zyga-ubuntu17:02
zyga-ubuntukyrofa: it will be in 2.31 for sure (next RC)17:02
* kyrofa subscribes to PR17:02
zyga-ubuntukyrofa: I only did that because I had a terrible morning where another HDD broke and it was monday and it was raining and kids were crazy about returning back to school17:02
zyga-ubuntukyrofa: it turned out to be a good day after all :)17:03
kyrofaHaha, good!17:03
stgraberzyga-ubuntu: there is a bug with apparmor in containers when running on some > 4.4 ubuntu kernel, tyhicks is aware and jj was supposed to look into it17:03
tyhicksstgraber: that's the bug that he's referring to17:04
jdstrandstgraber: I pointed him to the relevant conversation17:04
zyga-ubuntuyes, thank you everyone!17:04
stgraberperfect :)17:05
tyhicksjdstrand: now that I think about it, didn't jj say that he had test kernels available for testing?17:05
zyga-ubuntuit's not an immediate probem because snapd manages its own profiles and reexecs but it will bite some people sooner or later17:05
tyhicksjdstrand: does that ring any bells for you? if so, I can try to dig up the conversation17:05
jdstrandtyhicks: well, yes, it does, but I couldn't remember the deatils so came to you :)17:09
jdstrandtyhicks: I don't even know if there is a bug tbh17:09
zyga-ubuntujdstrand: the error message seems like it's a deliberate thing17:11
zyga-ubuntujdstrand: but unexpected17:11
zyga-ubuntujdstrand: it looks like apparmor thinks the container is privileged and doesn't do apparmor stacking17:11
* kalikiana wrapping up after a frustrating day of debugging symlink issues17:11
zyga-ubuntukalikiana: ln -s kalikiana /dev/bed17:12
zyga-ubuntuor was it the other way around17:12
zyga-ubuntuI hate "ln -s" syntax17:12
kalikianazyga-ubuntu: haha. you know, I've written a love poem about it, because that command annoys me so much (not a joke in fact)17:13
jdstrandzyga-ubuntu, tyhicks: what I recall is that lxd is using a funky way to detect things because libapparmor doesn't provide something better. the kernel never meant to have what lxd is currently checking be depended on. the kernel changed this for some other reason and the check broke17:13
stgraberjdstrand: the problem is that the broken kernel return an empty string at /sys/kernel/security/apparmor/.ns_name rather than the profile name17:13
stgraberjdstrand: and the apparmor init script uses that string being non-empty as a way to detect stacking and so fails17:13
jdstrandzyga-ubuntu, tyhicks: so jj was going to fix the kernel for now. I suspect he is going to also provide a libapparmor change, but I don't know that for a fact17:14
jdstrandstgraber: right17:14
stgraberjdstrand: the LXD side of the detection actually does work fine, LXD does setup stacking and everything but the container itself can't detect it17:14
jdstrandand that was never meant to be 'the right check'17:14
jdstrandbut it is all you have17:14
jdstrandok, right, it was /lib/apparmor/functions that was wrong17:15
stgraberjdstrand: so it's either a kernel bug that this string is now empty or it's an apparmor init script bug that it's relying on something which is meant to be empty :)17:15
jdstrandbut it was changed for lxd. anyway...17:15
jdstrandstgraber: I think I said as much17:15
stgraberyep17:15
pstolowskiniemeyer, pedronis I'd be useful to conclude #4401 (but #4400 first) as it will clear the way for interface hooks PR (and will help me a bit with resolving the issue of running hooks on refresh). AFAIR the most problematic point in 4401 was conflict resoluton, I've improved it and looking forward for feedback17:19
mupPR #4401: snapstate/ifacestate: auto-connect tasks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401>17:19
mupPR #4400: tests/main/searching: handle changes in featured snaps list <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4400>17:19
zyga-ubuntujdstrand: quoting linus, "fu... nvidia"^H^H "never break userspace" :-)17:20
zyga-ubuntuI'm sure it will be resolved quickly17:20
pstolowskiniemeyer, pedronis ah, mistake, not after 4400, but after #444017:20
mupPR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>17:20
niemeyerpstolowski: #4440 LGTM17:27
mupPR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>17:27
pstolowskiniemeyer, thanks17:32
kyrofazyga-ubuntu, have you messed with snapd in docker lately?17:40
zyga-ubuntukyrofa: no, never17:47
zyga-ubuntukyrofa: like literally never ever17:47
kyrofaYeah me neither, but I seem to remember other people running into issues17:47
zyga-ubuntukyrofa: is docker the deb something that I can try to use? or should I use docker the snap17:47
zyga-ubuntuguess I should try today17:47
kyrofazyga-ubuntu, no idea :D17:48
* zyga-ubuntu handles some important errand at home and will be back to snapd in a moment17:48
mupPR snapcraft#1890 opened: Fixed typo <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1890>18:36
zyga-ubuntuniemeyer: can you please look at 4560 again please?18:49
zyga-ubuntutoo much pleasure ;-)18:49
zyga-ubuntuniemeyer: I changed how I generate the unit and made the name dynamic18:49
zyga-ubuntuand fixed some silly things in that makefile while I was at it18:49
zyga-ubuntuspread is in progress, local testing was ok18:49
zyga-ubuntuman, where is everyone, no chipaca, no mvo :/ I should sleep at night and work during the day more18:50
bashfulrobotQuestion - staged packages in a confined snap.. are they updated when apt is run? Or only when the snap package is refreshed/19:01
kyrofabashfulrobot, anything in the snap is only updated when the snap is updated19:05
kyrofaRemember the snap is read-only19:05
bashfulrobotI suspected. I have a use case for a snap at my work, but I know it will likely have to be classic (display related - remoting protocol). But the base software does not need to be updated often. So I was trying to figure out if there si a negative aspect to snapping it.19:07
cachio<cachio> zyga-ubuntu, about the hidraw interface19:08
cachio<cachio> zyga-ubuntu, I cannot see it as part of the interfaces in my machine19:08
cachio<cachio> zyga-ubuntu, do you19:08
cachio<cachio> ?19:08
cachiozyga-ubuntu, I got disconnected19:08
zyga-ubuntucachio: re19:16
zyga-ubuntucachio: AFAIK it's juts added in gadget snaps, it's not implicit19:17
zyga-ubuntubashfulrobot: snaps can be updated as often as you want19:17
zyga-ubuntubashfulrobot: you just have to do the update19:17
zyga-ubuntubashfulrobot: snapcraft.io can help, you can just rebuild your pacakge19:17
zyga-ubuntu*package19:17
cachiozyga-ubuntu, ok, tx19:18
bashfulrobotAh ok, so you almost need to rebuild regularly in this case regardless of the packaged software itself.19:18
* ikey issued "normal" updates for the lsi edge snaps..19:38
bashfulrobotThanks for the info zyga-ubuntu19:54
mupPR snapcraft#1891 opened: lifecycle: use in-snap mksquashfs if running from snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1891>20:09
roadmrjdstrand: hi there! would it be OK for me to update the reviewer tools to r978? or would that need the extra packages for the resquash work? my reason for asking: there's at least one snap using a 2.30 interface which is failing review because said interface is not yet known by tools r950 which is what the store has20:12
ackkthere is a typo in base-18 Makefile: s,curren/t,current/20:13
ackk* s,curren/t,current/,20:13
ackkmvo ^ in case you're around20:13
ackkFTR: https://github.com/snapcore/base-18/pull/3620:18
mupPR base-18#36: Makefile: fix typo in base URL <Created by albertodonato> <https://github.com/snapcore/base-18/pull/36>20:18
zyga-ubuntuackk: looking20:23
zyga-ubuntuackk: I cannot merge it, tests failed, I'm looking at why but this looks like something mvo knows better20:25
ackkzyga-ubuntu, ok. it's probably not related to this change, though20:31
ackkzyga-ubuntu, can you kick a build on current master to see if it hits the same error?20:33
zyga-ubuntuackk: I restarted that test20:35
zyga-ubuntuchroot: failed to run command ‘/tmp/999-clean-resolv-conf.chroot’: Permission denied20:36
zyga-ubuntuhmm hmm20:37
zyga-ubuntuackk: is this https://github.com/snapcore/base-18/blob/master/hooks/999-clean-resolv-conf.chroot file +x in your branch?20:37
zyga-ubuntucna you please check that20:37
ackkzyga-ubuntu, it's not20:41
ackknor in master20:41
ackkzyga-ubuntu, should I chmod it?20:41
* ackk tries20:42
ackklet's see if tests pass now20:42
zyga-ubuntuyes20:45
niemeyerzyga-ubuntu: First comment wasn't addressed or responded20:48
ackkzyga-ubuntu, tests passed20:50
zyga-ubuntuniemeyer: oh, let me check20:50
zyga-ubuntuhmm, that's odd, I responded but my response is gone now20:51
zyga-ubuntuniemeyer: let me respond again, I certainly didn't ignore it20:52
zyga-ubuntuand odd20:52
zyga-ubuntuI cannot respnd to the thread there20:52
* zyga-ubuntu reloads20:52
zyga-ubuntuniemeyer: anyway, let's do it here so that we can reach an agreement20:52
zyga-ubuntumy initial response was that I'd prefer to fail close and early rather than notice the situation we don't support and fail open later when snap is refreshed or removed20:53
zyga-ubuntuif you think this is too grave concern we can reomve that whole section now, it's not doing anything apart from checking and failing when the externally satisfied precondition is not met20:53
zyga-ubuntuniemeyer: let me know what you think20:57
niemeyerzyga-ubuntu: Yeah, I found it awkward that there's no way to add comments there indeed20:57
niemeyerzyga-ubuntu: My concern (and mvo's I think) is not that it's better to fail one way or the other, but rather that we have existing logic and no clue whether people are depending on it today or not20:58
zyga-ubuntuniemeyer: yes, that's a valid concern, as I said I responded to the comment (somehow) and I wanted to discuss it more hence no changes20:58
niemeyerzyga-ubuntu: Before, there was nothing there.. then, in an automatic update, we go from "no worries!" to "BOOM!"20:59
zyga-ubuntuniemeyer: I think for now we can make the die go away and land this, to the happiness of LXD uses20:59
zyga-ubuntuand we could look at a way for snapd to measure the environment say "gee, I cnanot work here" perhaps20:59
niemeyerzyga-ubuntu: And we need some kind of heads up before we do hard changes21:00
niemeyerzyga-ubuntu: So we have a clue if we're breaking any existing environment for which we don't currently have tests for21:00
zyga-ubuntuniemeyer: shall we printf something or just do nothing at all now?21:01
zyga-ubuntu(as in rip that code path out)21:02
niemeyerzyga-ubuntu: I would not touch that kind of logic right now21:06
niemeyerzyga-ubuntu: There's just too much going on21:06
niemeyerzyga-ubuntu: Just add a note of what the intention is for the near future and why21:06
niemeyerzyga-ubuntu: Then, when everything else settles, we can poke at it and see what happens21:06
niemeyerzyga-ubuntu: Certainly with a warning before we do anything aggressive21:07
zyga-ubuntuok21:07
zyga-ubuntuniemeyer: updated21:14
* zyga-ubuntu doesn't like old make :/21:16
cachiozyga-ubuntu, I see the error 'runtime/cgo: ' when we run the i18n test21:18
niemeyerzyga-ubuntu: Looking again21:18
cachiozyga-ubuntu, any idea if it is an error or a message that could be discarded?21:19
zyga-ubuntucachio: that looks like one of those go bugs we had21:19
zyga-ubuntuI thought those were fixed21:19
zyga-ubuntuare those on 14.04?21:19
niemeyerzyga-ubuntu: Can we please not touch that logic right now instead?21:20
cachiozyga-ubuntu, yes, it is making the i18n test fail21:20
zyga-ubuntuniemeyer: no21:20
zyga-ubuntuniemeyer: that logic as it was was broken21:20
zyga-ubuntuniemeyer: it was either inactive or it was broken21:20
zyga-ubuntuniemeyer: (see the original bug description from stgraber)21:20
niemeyerzyga-ubuntu: Why?21:20
zyga-ubuntuniemeyer: it was running to late, creating mirror entries21:20
cachiozyga-ubuntu, it is also failing on debian-921:20
niemeyerzyga-ubuntu: I won't re-read the *whole* bug right now trying to guess hints of this :)21:21
zyga-ubuntucachio: so on 14.04 and on debian-9 we probably have the bug still, I don't know really21:21
zyga-ubuntuniemeyer: essentially the self-bind mount would duplicate existing mount entries21:21
zyga-ubuntuniemeyer: and then apply sharing over them21:21
zyga-ubuntuniemeyer: but keep the old entries intact21:21
cachiozyga-ubuntu, do you remember in which PR it was fixed for the other systems? so I can take a look21:21
zyga-ubuntuniemeyer: there were two lines there: a rbind and a rshare21:21
zyga-ubuntuniemeyer: the rbind gives us a thing that can control sharing (sharing is per mount entry not per directory)21:22
zyga-ubuntuniemeyer: and the sharing is obvious21:22
zyga-ubuntuniemeyer: but at that time /snap was already populated21:22
zyga-ubuntuniemeyer: the result confuses systemd and mount units cannot stop correctly21:22
zyga-ubuntuniemeyer: that's about it21:22
zyga-ubuntucachio: it was a (perhaps more than one) update to the golang compiler, but perhaps I don't recall correctly; mwhudson would know21:23
* zyga-ubuntu will snap ancient make for self-punishment and testing21:23
niemeyerzyga-ubuntu: Yes, I get that.. I thought that was exactly what was fixed21:24
niemeyerzyga-ubuntu: and this path shouldn't be reachable given that21:24
zyga-ubuntuniemeyer: yes!21:24
zyga-ubuntuniemeyer: that's why I used die21:24
zyga-ubuntuand argued we could rip it out21:24
niemeyerzyga-ubuntu: Well.. now you are saying that if we preserve the logic we have a bug..21:24
zyga-ubuntuno no, sorry, we have a comms problem over irc21:25
zyga-ubuntuif we keep the old bind mount + share code there we will have problems on systems that the new snap.mount unit doesn't fix (e.g. on a non-container with that behavior)21:25
zyga-ubuntuessentially, that whole code was wrong and it should be removed regardless21:25
zyga-ubuntubut for initial version of this patch in the morning I used die to see if it would fail anywhere21:26
zyga-ubuntuone place we could perhaps explore is 14.04 as a non-container21:26
niemeyerzyga-ubuntu: If we have code that the change doens't fix, then you'd be blowing it up with die()21:26
zyga-ubuntuyes21:26
mwhudsonzyga-ubuntu: hmmm21:26
zyga-ubuntuniemeyer: but 14.04 is using a different mechanism to fix it21:27
zyga-ubuntuniemeyer: so nothing (apart from build failure now with make) was broken21:27
zyga-ubuntuniemeyer: either way, I would leave: printf (as it is now) or nothing; I would not keep that mount rbind, mount rshare code as we used to have21:27
zyga-ubuntuwe *could* keep it21:28
zyga-ubuntuand it would not alter behavior21:28
zyga-ubuntu*behaviour21:28
zyga-ubuntubut I think it's just buggy21:28
mwhudsonzyga-ubuntu: +?21:28
zyga-ubuntuwe can do that on another iteration if you are worried about something unanticipated21:28
zyga-ubuntumwhudson: hmm?21:28
mwhudsonzyga-ubuntu: "mwhudson should know" -- know what? :)21:28
niemeyerzyga-ubuntu: I've been saying that for some time :)21:28
zyga-ubuntumwhudson: ah, sorry, cachio saw "cgo runtime" thing again21:28
mwhudsonzyga-ubuntu: cgo runtime?21:29
zyga-ubuntumwhudson: and asked if we there was a patch for that somewhere21:29
zyga-ubuntu22:18 < cachio> zyga-ubuntu, I see the error 'runtime/cgo: ' when we run the i18n test21:29
mwhudsonzyga-ubuntu: i'm just back from leave so have no context at all21:29
niemeyerzyga-ubuntu: We have several concurrent ideas of what's supposed to happen:21:29
niemeyer1. Nobody will ever reach this logic21:29
niemeyer2. We want to kill those who reach this logic21:29
zyga-ubuntuniemeyer: sure, I just wanted to explain the motivation of the patches I sent so far so that my ideas are clear21:29
niemeyer3. We want to preserve the behavior of those reaching this logic21:29
niemeyerThose are all incompatible with each other21:30
zyga-ubuntuI agree21:30
cachiomwhudson, hey21:30
cachiomwhudson, https://travis-ci.org/snapcore/snapd/builds/334699893#L212921:30
mupPR snapcraft#1890 closed: Fixed typo <Created by chrisglass> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1890>21:30
zyga-ubuntuniemeyer: 1 can still happen on systems that don't use systemd to boot but we don't support that21:30
mwhudsonzyga-ubuntu: i don't know what that means21:31
cachiomwhudson, when we run a test that tries the different languages with the command snap21:31
zyga-ubuntumwhudson: I was under the impression that we ran into a bug in golang where exec + fork were racing21:31
zyga-ubuntumwhudson: but perhaps that was fixed in the kernel, I don't recall21:31
niemeyerzyga-ubuntu: I don't want to go hunting that sort of bugs *right now*21:31
cachiomwhudson, we can see an error "runtime/cgo:"21:31
niemeyerzyga-ubuntu: Or to burn mvo with late releases to fix serious issues in unexpected environments21:31
zyga-ubuntuniemeyer: understood21:31
niemeyerzyga-ubuntu: We need to focus on delivering the few things which are high prio at the moment.. layouts, interface hooks, etc21:32
zyga-ubuntuI'll restore the code and leave a todo to remove this after the release21:32
niemeyerThanks!21:32
mwhudsoncachio: oh well i18n is disabled entirely in debian21:32
zyga-ubuntuniemeyer: thank you! :)21:32
cachiomwhudson, it is just happening on debian-9 and ubuntu-14.0421:32
mwhudsonzyga-ubuntu: aaah the fork/exec thing21:32
mwhudsonwait one version of that is just a warning21:33
zyga-ubuntucachio: was it failing or just printing and you noticed?21:33
cachiozyga-ubuntu, it is printing21:33
niemeyerzyga-ubuntu: Why was the unit file embedded in the makefile?21:33
cachiozyga-ubuntu, If I reexec it doesn't fail21:33
mwhudsonhmmm i thought that was fixed in debian though21:33
niemeyerzyga-ubuntu: That sounds a bit less nice than what you had there earlier21:34
mwhudsonoh wait, probably only in buster21:34
zyga-ubuntuniemeyer: it was nice when it worked, no need to sed, just expand variables21:34
cachiomwhudson, zyga-ubuntu if I exec the command that failed in a debug session, it works well21:34
zyga-ubuntuniemeyer: but given that old make sucks I think I must go back to sed21:34
mwhudsoncachio: it's only ever a 1 in a 1000 type thing, it's a race21:34
zyga-ubuntuniemeyer: the advantage was that we didn't have to duplicate a rule for a file with variable target name21:34
zyga-ubuntuniemeyer: anyway, I'll sort it out21:35
cachiomwhudson, it seems so21:35
mwhudsonthere is also the kernel bug where a setuid executable doesn't get uid=0, no idea if that's fixed in debian yet21:35
niemeyerzyga-ubuntu: I don't see the relationship21:35
niemeyerzyga-ubuntu: Embedding everything in the Makefile isn't so nice, whether make rocks or not21:35
zyga-ubuntuniemeyer: it was nice for this case IMO, because I could didn't have to duplicate rules that sed the vars in and get the new filename I had to use21:36
zyga-ubuntualmost there...21:38
cachiomwhudson, something that I already tried is to add a sleep between different tries and the issue also happened21:39
cachiomwhudson, any idea where I could start looking at to fix it?21:40
mwhudsoncachio: it's a race within the go start up routines21:40
cachiomwhudson, ah, ok21:41
cachiozyga-ubuntu, is it ok if we ignore these kind of errors or set this to manual?21:43
cachiozyga-ubuntu, also we could skip the failing systems until the issue is resolved21:46
cachiomwhudson, how did you deal with these kind of issues in the past?21:46
zyga-ubuntucachio: well, it's not really honest, we should get the relevant fixes to those systems if that makes snapd work better21:47
jdstrandroadmr: it is probably ok but I haven't fully verified it21:48
roadmrjdstrand: oh ok... I'd rather wait until you greenlight it properly then21:48
cachiozyga-ubuntu, of course, but the fixes should go in snapd?21:48
jdstrandroadmr: right now most of that is behind env vars21:48
roadmrjdstrand: what can cachio do in the meanwhile, with that interface he wants to use that the old tools don't grok?21:49
jdstrandroadmr: but we/I can be responsive to the queue for now too21:49
zyga-ubuntucachio: no21:49
roadmrjdstrand: ok... hm this snap was marked as "failed review", not as "held for manual review", whic was odd21:49
zyga-ubuntucachio: to kernel/golang AFAIK21:49
jdstrandroadmr: he can request a manual review21:49
roadmrcachio: ^^ oh yay!21:50
mwhudsoncachio: hm the fix for this is https://go-review.googlesource.com/c/go/+/33894 which is in go 1.8 which i thought was what stretch had...21:50
mwhudsonah no 1.721:51
cachiomwhudson, ok21:51
zyga-ubuntuniemeyer: I think this is it21:52
zyga-ubuntulets see if tests pass21:52
cachioroadmr, sure, I'll do21:53
cachioroadmr, done21:53
roadmrwhee :0 cachio that way no need to wait for the tools upgrade because it might be a bit longer than expected21:53
roadmrcachio: great, that puts it in the queue and someone will look shortly.21:53
cachioroadmr, I'll have to request also for all the other arquitectures21:54
cachioarchitectures21:54
cachioroadmr, np, thanks21:54
jdstrandcachio: if it is test-snapd-gpio-memory-control, I just approved it, but you'll need to publish21:55
cachiojdstrand, yes, thanks21:55
cachiozyga-ubuntu, i18n is making snapd fail 1/3 executions, so, what do you think is the best idea to deal with this one21:56
zyga-ubuntucachio: well, it depends, we could just ignore that result, ideally we'd try to get the fix released if the frequency is that high people will also hit that bug often21:56
cachiozyga-ubuntu, it is often because the test is going through all the langs and trying LANG=xxx snap21:58
zyga-ubuntuI see21:58
zyga-ubuntuwell21:58
zyga-ubuntuI don't think that changes anything21:58
* zyga-ubuntu reads about dell vmware merger21:59
zyga-ubuntuimagine a laptop with "vmware" logo on it :)22:00
zyga-ubuntuon the other hand vmware metal servers would be fun22:00
niemeyerzyga-ubuntu: LGTM assuming it works :)22:00
zyga-ubuntuthank you!22:00
zyga-ubuntuI'll get the other branch working now22:01
zyga-ubuntuand in some alternative universe we're all running dell VMs using dell workstation which is a program22:02
zyga-ubuntu....22:02
zyga-ubuntudell and vmware watch too many mirror universe trek episodes22:02
roadmrhaha22:03
roadmrgood one22:03
zyga-ubuntubut, at least dell fusion makes sense, with vmware, that is22:07
zyga-ubuntuniemeyer: tests are green :)22:24
zyga-ubuntuwe need a 2nd review22:24
zyga-ubuntuI'll ask mvo for one in the morning22:24
zyga-ubuntuhmm, no vmware would probably not be affected22:36
zyga-ubuntuthat's curious, I wonder if I could reproduce that22:36
zyga-ubuntukyrofa: it looks like I will have clean plate soon (I will work on per-user mounts with jamesh and on layout policy with jdstrand) but this can be my backburner task22:37
kyrofazyga-ubuntu, no problem, just comment on that issue when you're able, I'll leave it open22:38
zyga-ubuntukyrofa: actually, with my gazillion tabs lost on my desktop22:39
zyga-ubuntudo you have a link?22:39
jameshzyga-ubuntu: fwiw, I'm in UTC-8 this week (rather than UTC+8)22:39
kyrofazyga-ubuntu, https://github.com/nextcloud/nextcloud-snap/issues/42522:39
kyrofaHaha, no problem22:39
roadmrjamesh: oh what happened :( who multiplied you by -1?22:39
zyga-ubuntujamesh: oh, cool, sprinting?22:39
zyga-ubuntukyrofa: thank you22:39
zyga-ubunturoadmr: LOL22:40
jameshzyga-ubuntu: yeah.  At the Snapcraft Summit with kyrofa and others22:40
zyga-ubuntucool, is jdstrand there too?22:42
zyga-ubuntujamesh please talk to jdstrand about your PR, if he acks it I'll merge and we can iterate22:42
jameshzyga-ubuntu: I think he's arriving later in the week22:42
zyga-ubuntuexcellent, don't let him leave without that :)22:43
zyga-ubuntu;-)22:43
jdstrandzyga-ubuntu, jamesh: fyi, I just reviewed it22:43
kyrofajamesh, yeah, Thursday22:43
zyga-ubuntuooooh22:43
* zyga-ubuntu is looking22:43
jdstrandI'll be there Wed and Thu22:44
jdstrand(leaving tomorrow)22:44
mwhudsonwhat https://paste.ubuntu.com/26486123/22:44
mwhudson(tldr snapcraft.storeapi.errors.StoreReleaseError: <exception str() failed>)22:45
zyga-ubuntujdstrand: nice, thank you!22:45
zyga-ubuntukyrofa: ^22:45
kyrofaOh right, was thinking Thursday/Friday22:45
kyrofaGlad you said something :P22:45
mwhudsonhm i tried running snapcraft login again and now it's just hanging22:47
kyrofamwhudson, hmm... what version22:48
kyrofa?22:48
mwhudson2.35 (stable channel)22:48
mwhudson... because snap install --edge --classic snapcraft was failing too :)22:49
mwhudsonclearly i shouldn't be near computers today22:49
kyrofaHuh, sounds like the store is having issues then22:49
zyga-ubuntumwhudson: snap install weekend -> EMONDAY22:49
mwhudsonkyrofa: could be22:50
zyga-ubuntuwhere is that apt thing22:50
zyga-ubuntuwhere it prints something odd once in blue moon22:50
zyga-ubuntuwhen something else fails22:50
zyga-ubuntuit's a bit insane22:50
zyga-ubuntuah, past midnight something22:50
mwhudsonzyga-ubuntu: it's a 'man after midnight' think i think22:51
mwhudson(and cj-watson's fault)22:51
zyga-ubuntuah :D22:51
zyga-ubuntuit was man22:51
mwhudsonhttps://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-003022:52
mwhudsonkyrofa: it's working now22:53
kyrofaWeird22:55

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