504 Gateway Time-out

[02:48] Is there a way to utilizr a bz2 file in the source directive? [02:48] utilize* [02:50] I'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:51] I'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] Thanks all. [03:53] bashfulrobot: atm, there's no bz2 support in snapcraft, iirc [03:53] debian doesn't generally encounter bz2 that much anymore, so I would guess they didn't think about it [04:32] Son_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. [06:07] morning [06:11] morning [06:11] * Son_Goku needs to sleep [06:12] anyway, if anyone sees robert-ancell, can someone poke him about this? https://github.com/snapcore/snapd-glib/issues/32 [06:24] o/ [06:25] Son_Goku: zyga-ubuntu: morning guys [06:27] hey, good morning [06:27] uefi greeted me today with "ubuntu (disk not present)" [06:27] I think this is not a happy day [06:29] * zyga-ubuntu boots from usb and hopes the disk isn't dead yet [06:32] zyga-ubuntu: whad did you do? another dead disk? [06:37] mborzecki: no, just booted it again today [06:37] man, I'm not lucky [06:37] it shows up and mounts from live media [06:38] drive not present... [06:38] sounds like bad news [06:39] Hey guys (morning to those of you in Europte, etc) [06:39] I have a snap that I'm getting ready for snapcrafters. [06:40] It is going to need classic confinment as it is a backup program. [06:41] Going 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:42] And 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] once in the beta channel? [06:43] * bashfulrobot getting sleepy - almost bed time. [06:50] bashfulrobot: hey [06:50] hello [06:50] bashfulrobot: you can request classic confinement on the forum (forum.snapcraft.io), there is a process to follow there [06:51] I'll search it up then. [06:51] bashfulrobot: 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-cases [06:51] bashfulrobot: you can test in classic mode as well, though devmode and classic are quite different [06:51] Well basically you need ot be able to backup any location on the file system [06:52] I was under the impression classic was the onbly way to do that [06:52] backup and restore, which is read and write anywhere [06:52] yes, I think so [06:52] exactly [06:52] you *can* do that in devmode [06:52] but it's more tricky [06:52] ok, I'm going to apply for classic then [06:52] and there's no interface for backup programs yet [06:52] ah ok. [06:52] sorry for brief answers, I think monday doesn't like me (my computer is not working) [06:52] hey - nooo worries [06:53] It's almost 11 pm Sunday for me... so my brain is giving up on me. :-) [06:54] "logical sector size is zero" [06:54] my ESP partition is broken [06:54] ok, that's it [06:54] I'm turning this machine off and I'll go and buy a new computer today [06:54] I'm so so so fed up with it [06:54] bashfulrobot: enjoy your evening and thank you for making snaps! [06:56] no 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] zyga-ubuntu: hope the day gets better! [06:58] yes, the store category is right [07:06] good mornin mvo [07:08] hey zyga-ubuntu - good monring [07:08] morning even [07:08] zyga-ubuntu: shall we continue with this systemd shared unit today? [07:08] zyga-ubuntu: appreciate the help. Classic has been requested. Have a good day. I'm off to bed. [07:09] * bashfulrobot zzzzzzz [07:12] mvo: 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 work [07:12] mvo: I'm throwing the towel on my desktop today [07:13] zyga-ubuntu: "esp"? [07:13] zyga-ubuntu: sorry to hear that things are broken :( [07:13] mvo: the system boot partiotion on efi systems [07:13] zyga-ubuntu: ohhh, ok [07:13] my disks are failing on me :( [07:14] zyga-ubuntu: get ssds :P [07:14] I can boot the live media but I cannot boot the disk anymore [07:14] zyga-ubuntu: when they fail, they fail faaaaster [07:14] mvo: yeah, I'm considering just getting out and going to buy a new computer now [07:14] hahaha [07:16] PR snapd#4558 opened: cmd/snap-mgmt: fix out of source tree build [07:16] mvo: morning [07:17] zyga-ubuntu: get intel ssds, they got crazy 5y warranty [07:17] already had 2 disks replaced under warranty :) not a single complaint [07:18] mborzecki: goooood morning [07:20] yocto segfault thing, i can reproduce it on 2.31 too [07:21] a simple fix that resolves/masks the problem is moving progress bar Finished() call in store dowload to happen after checking the errors [07:21] good run log with breadcrumbs; https://paste.ubuntu.com/26482312/ [07:22] otherwise the crash looks like this: https://paste.ubuntu.com/26482304/ [07:22] 2018/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] 2018/01/29 07:16:11.641850 task.go:248: -- in task 0xb77006fc set progress, state 0xe3f [07:24] these 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] somehow the pointer to the task changed from 0x967d8780 to 0xb77006fc [07:25] mborzecki: which golang is used on that yocto build? [07:26] 1.9 [07:26] mborzecki: is it a compiler bug maybe? [07:26] mborzecki: any patches in ubuntu or debian or any patches in yocto that may be relevant? [07:26] update to 1.9.3 is on my list, but the interaction cycle is long [07:27] looked through commits between 1.9 and 1.9.3 nothing that looks relevant [07:27] mborzecki: do you think this is something in our code? [07:27] not sure yet [07:28] for 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] albeit in the good run there's no call to pbar.Finished() [07:29] mborzecki: oh, doing the Kill twice sounds wrong, do you have more info? [07:29] mborzecki: also no call to Finish sounds wrong :( [07:29] mvo: take a look at the logs i posted [07:30] this is the diiff i'm working with: https://paste.ubuntu.com/26482348/ [07:32] mvo: in taskrunner.Ensure() there's a call to tomb.Kill() for the running task [07:33] aiui that kill will trigger cancel on the context [07:36] mborzecki: interessting [07:43] mborzecki: 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 invalid [07:45] morning snappy [07:46] hey kalikiana [07:46] kalikiana: morning [07:54] zyga-ubuntu: mvo: forcing a static build of snapd makes the problem go away https://paste.ubuntu.com/26482426/ [07:56] mborzecki: oh, this is also interessting. how dynmaic is the dynamic build? i.e. what is linked? [07:57] hmm ... [08:01] mvo: nothing special, libc and libstd (that's go) [08:01] good morning! [08:01] pstolowski: morning [08:03] mborzecki: I wonder if that would fail if you used a ubuntu-build of snapd [08:03] btw. also according to the forum post the problem is only on x86, does not appear on x86-64 [08:03] mborzecki: I read about some peculiar crash of golang when gentoo used new kernel optimization flag and broke the vsdo [08:04] i've tried rebuilding snapd locally, with same flags but no success [08:04] mborzecki: that was a golang bug, assuming too much about kernel behavior [08:05] i mean, GOARCH=386 GO386=387 CGO_ENABLED={0,1} all worked fine when deployed to the vm [08:05] hoped to use -race but it's 386 ;) so no race for me [08:06] mborzecki: can you try a i386 kernel from ubuntu there? [08:06] and see if the same binary of snapd tests wokrs [08:06] *works [08:06] just a long shot but somethig that could help bisect the area that is broken [08:18] zyga-ubuntu: can you take a look at #4558? this is an easy one [08:18] PR #4558: cmd/snap-mgmt: fix out of source tree build [08:18] yep [08:19] mborzecki: you could use | there [08:19] to make it an ordering-only rule [08:19] mborzecki: just add a | before the new dependency [08:19] either way +1 [08:21] yocto does out of the source builds by default, and this came up there :) [08:22] there's actually a separate class for packages that have broken separation [09:03] zyga-ubuntu: mvo: could you take another look at 4487? [09:07] mborzecki: sure [09:08] looking [09:08] mborzecki: heh, sorry that my suggestion to use "internal" error was wrong [09:11] mborzecki: looks good to me! zyga-ubuntu can merge once he finished (unless he has more suggestions of course) [09:11] mvo: thanks [09:12] yes, I'm just re-reading [09:16] mborzecki: done, have a look please [09:16] brrr, cold, let me make some more tea [09:17] zyga-ubuntu: thanks, good catch [09:20] mvo: I'm juming into lxd issue now [09:20] mvo: I don't have anything to do before 4471 lands [09:21] zyga-ubuntu: cool I'm working on xdg-settings final touches and then ~rc2 [09:21] zyga-ubuntu: but let me know if I can do anything to help with that, happy to tweak the packaging [09:21] mvo: land 4471 [09:21] zyga-ubuntu: but my feeling is right now the solution is not clear [09:21] I think we're wasting time now [09:21] it's blocking everything related to mount work [09:22] zyga-ubuntu: don't we need gustavo for this? [09:22] well, I am waiting [09:22] I'm just saying it's a bit unreasonable now [09:23] (that branch hasn't been touched in weeks) [09:27] * mvo nods [09:38] moin moin [09:39] ho ho [09:39] zyga-ubuntu: http://i.imgur.com/AAGJvD1.png [09:40] Chipaca: \o/ you made my morning [09:40] mvo: woo! [09:40] mvo: how tho :-) [09:40] Chipaca: the subway map [09:41] it's rather brilliant, isn't it [09:41] neat [09:41] Chipaca: oh yes [09:41] love it [10:02] * kalikiana going for a short walk, need a little fresh air [10:04] PR snapd#4559 opened: snap-confine/nvidia: Support legacy biarch trees for GLVND systems [10:04] * ikey now unblocks solus sync. :p [10:16] ikey: [10:16] pretty much lol [10:16] we were gonna sync last night, but i couldnt get the snapd patch (above) working [10:17] turns out i was missing a comma -_- [10:22] mvo, 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:23] ikey: it's better to miss a comma than to miss the point [10:24] hah [10:24] * zyga-ubuntu gets back to being reasonable [10:24] zyga-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] zyga-ubuntu: This week I should get back to reviews and discussions [10:24] niemeyer: I understand that, no apologies needed; I think that code is critical enough to warrant the wait [10:24] niemeyer: I'm trying to get useful in other areas [10:25] niemeyer: and I think the new spread work is brilliant and we will benefit tremendously mid/long term [10:25] niemeyer: (and rest of canonical and anyone who uses it as well) [10:25] I always wished spread either did queueing or do dynamic allocation and now it does [10:25] zyga-ubuntu: I hope the benefit is immediate.. [10:26] niemeyer: it is, I meant that it's not just short term benefit [10:26] zyga-ubuntu: The practical consequence is ~23 minutes runs, and no more limiting on the number of runs, so everybody gets more productive.. [10:26] I postponed that for quite a while last year, but now it was getting a bit unreasonable.. [10:27] and less issues hand holiding systems and re-starting failed tests due to overuse [10:27] Anyway, I hope that's now done [10:27] i dont understand how or why my PR failed [10:28] ikey: concurrent non-deterministic software that is connected to the internet has that property a lot [10:28] :D [10:36] * kalikiana re [10:37] ohh [10:37] * zyga-ubuntu has an insight [10:38] .ubuntu.com? [10:38] >_> [10:39] no, maybe a fix for the bug mvo and me were fighting for a long time [10:39] mvo: no double mounts! [10:40] zyga-ubuntu: tell me more! [10:40] mvo: hold on, just a teaser, let me do more experiments first [10:43] * zyga-ubuntu fiddles thumbs while package builds [10:56] if I could get a review for 4342 that would be great. its the last bit of polish I would like to get in for ~rc2 [11:03] ikey: you drank some punny water this morning? :-P [11:04] perhaps. :p [11:08] mvo: still no double mounts, things look good so far, let me do some more and then try a spread run [11:09] zyga-ubuntu: what is the gist of the alternative idea? [11:09] zyga-ubuntu: I'm really curious [11:09] mvo: well, ... it's silly really [11:09] mvo: one char less than yours probably [11:09] zyga-ubuntu: hu? [11:10] zyga-ubuntu: was there a typo in my unit? [11:10] not really, I don't quite know if you got the double entries because of that [11:10] so so far so good, I'll try to cause the problem by doing what you initially did to confirm [11:10] zyga-ubuntu: so this is a mount unit, we still need all the scaffolding ? i.e. write out from snapd.postinst etc? [11:10] mvo: yes [11:11] zyga-ubuntu: ok - what does this one look like :) please, I'm really curious [11:11] mvo: hold on, one test will tell me if this makes sense, [11:12] hmmmmm [11:12] mvo: so, no double mounts but now I did what you did [11:12] unless lxd is doing something magic [11:12] ok, to be sure I'll just reboot [11:12] brb [11:12] mvo: sorry to keep you waiting, I don't want to say "got it" before it really works and I know *why* [11:13] zyga-ubuntu: no double mounts inside lxd? or no double mounts inside *and* outside of lxd? [11:16] mvo: so, let me check something, I'm on artful now, the container is xenial [11:16] mvo: I disabled reexec to test my build easily [11:16] mvo: (and it works so far) [11:17] mvo: did you do anything different? [11:17] mvo: I'll try to remove the package now, wonder if that will crash like it did before [11:17] but no double mounts, right sharing and snaps can be removed allright [11:17] so that counts as an improvement [11:17] now the last bit is packaging [11:18] zyga-ubuntu: no double mounts outside as well? [11:20] nope [11:20] mvo: actually, I didn't run many snaps and now I see that: [11:20] (though I doubt this is related, probably a bug) [11:20] ubuntu@experiments:~$ hello [11:20] snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks [11:21] but I heard that there was a bug in lxd+apparmor about recently [11:21] * zyga-ubuntu looks at loaded profiles [11:21] ha [11:21] indeed [11:21] only snapd-managed profiles are active [11:22] we didn't load the profile for snap confine [11:22] mvo: that's a separate bug manifested if you disable re-exec [11:22] Jan 29 11:15:49 experiments apparmor[85]: * Not starting AppArmor in container [11:22] Jan 29 11:15:49 experiments apparmor[85]: ...done. [11:22] jdstrand, stgraber: ^ [11:23] is this reported or am I dreaming things? [11:23] mvo: once I load snap-confine's profile manually things are ok [11:23] mvo: also inside process namespace [11:24] mvo: ok, let me get back and make this into a proper patch I can share with you [11:24] mvo: and see if I can run the test I wrote a while back against it [11:24] jdstrand, stgraber: this is with apparmor 2.10.95-0ubuntu2.7 [11:27] mvo: this still makes little sense to me, it works but the difference between your branch seems meaningless [11:33] hmmm [11:33] mvo: wow, it even removed the package allright [11:33] * zyga-ubuntu is so confused now [11:33] mvo: it only printed tihs [11:33] dpkg: warning: while removing snapd, unable to remove directory '/snap': Device or resource busy - directory may be a mount point? [11:34] and purged cleanly [11:34] :-)) [11:34] * zyga-ubuntu has a happy monday now [11:34] zyga-ubuntu, https://www.youtube.com/watch?v=SsmVgoXDq2w :) [11:35] zyga-ubuntu: did it actually stop your mount unit? [11:35] zyga-ubuntu: it sounds a bit dubious :) [11:36] zyga-ubuntu: but I'm keen to see your PR [11:36] mvo: yes [11:36] zyga-ubuntu: woah, ok [11:36] mvo: it's totally clean [11:36] mvo: it's so weird [11:36] zyga-ubuntu: looking forward to the diff [11:36] zyga-ubuntu: I have a small test in my PR that will be fun to test against [11:36] zyga-ubuntu: by all means, if we have a solution and I will sing and dance and hug you :) [11:41] me too :) [11:42] I'll build another package that doesn't involve any hand-holding anymore [11:42] and re-test [11:42] and then send a PR [11:42] and then find and cherry pick those tests we wrote [11:42] you're so unromantic ! [11:42] ogra_: ? [11:43]

I'll build another package that doesn't involve any hand-holding anymore [11:43] but first, my tea has run out [11:43] mvo: btw I have t otell you [11:43] haha [11:43] banning hand holding, and we're coming up to the 14th soon enough [11:43] sheesh [11:43] ogra_: but there will be hugging instead [11:43] ah ! [11:43] mvo: my favourite tea is in stock again, it is called ... [11:43] thats an improvement then :) [11:43] sir adalbert's tea, soursop green tea [11:44] it has a big elephan on a decorative green box, not sure if you know it [11:44] zyga-ubuntu: I don't let me search for it [11:45] zyga-ubuntu: the downside of not sharing an office, I would love to try it :) [11:45] it's awesome, I can bring you a bag next time we meet [11:48] mvo: the trick is that fruit they added, soursop [11:49] maybe if you like traditional tea it's "meh flavoured" but there's something really tasty about it [11:49] zyga-ubuntu: I'm a bit of a traditionalist :) but also open so I'm certainly curious [11:49] zyga-ubuntu: *cough* diff *cough* ;) [11:50] zyga-ubuntu: else I'm gone for lunch and will be curious all the time [11:51] mvo: here it is [11:51] https://github.com/zyga/snapd/tree/fix/fix-snap-share-v3 [11:51] don't open PR yet please, I didn't touch packaging [11:52] mvo: if you build that and run it, does it show duplicates or misbehaves for you? [11:52] I'll proceed with proper tests now [11:53] zyga-ubuntu: heh [11:53] zyga-ubuntu: ConditionVirtualization=lxc [11:53] that's just making it easy to ship [11:53] zyga-ubuntu: I was thinking something like this this morning, if we should make it conditional [11:53] zyga-ubuntu: and it works fine inside? [11:53] yes [11:53] just try it [11:53] zyga-ubuntu: awesome [11:53] I'll fix packaging and get that spread test that tried it merged [11:53] mvo: note [11:53] mvo: the conditional part is irrelevant [11:53] zyga-ubuntu: thank you [11:54] zyga-ubuntu: hu? how so? [11:54] mvo: there's no difference from what you wrote [11:54] mvo: (your unit was started the same way in the end) [11:54] mvo: I really don't know why this works yet [11:54] zyga-ubuntu: it was, but mine ran on classic as well [11:54] mvo: I used a different wants [11:54] ahhhhh [11:54] zyga-ubuntu: and caused all sorts of problems there [11:54] oh, that's it then [11:54] zyga-ubuntu: yeah, thats it :) [11:54] on classic it's not sane [11:54] heh [11:54] zyga-ubuntu: (I think at least) [11:54] sounds like a good day then :) [11:54] zyga-ubuntu: very nice, thank you! [11:54] ok, let me finish the polish on this [11:55] zyga-ubuntu: good luck, I get dinner now [11:55] enjoy! [12:04] mvo, should I file a bug about that missing file? [12:05] spread running [12:05] kyrofa: IT'S HAPPENING [12:08] * zyga-ubuntu thinks about lunch [12:08] PR snapd#4560 opened: many: fix removal of snaps inside LXD [12:12] * pstolowski lunch [12:22] hmmm [12:22] - Download snap "lxd" (5522) from channel "stable" (sha3-384 mismatch for "lxd": got 3ed1910ba0d678da4820c74e35f288db4feb6dcad637466ab6c2bee26fca363b1cdb42e6b81e3f4fb834b672c64457c2 but expected 05ca4d0b5cd936beff0323dd786f2787fdf1783fbb7ffb89c09143c49a6e2269aca4a76e12d34422ea59826129f6009f) [12:22] Chipaca: ^ [12:22] is this store being funky or do I have a bad day? [12:25] is 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] zyga-ubuntu: mvo: disabling optimizations and inlining resolves the problem [12:32] sitter: no, not at present [12:40] mvo: things passed in my spread [12:40] mvo: I think it's a winner, let' see how the PR fares [12:52] I got called out of physio to go pick up one of the boys who's being sick all over school (apparently) [12:52] will miss the standup [12:52] ttfn [12:53] mvo: 4560 is ready for review [12:54] brb, see you at the call [12:56] ls [12:58] mvo: that pr needs one more patch, to give the mount unit the right name (following snap mount dir) [12:58] I'll do that [13:00] zyga-ubuntu: ok [13:28] * kalikiana going for lunch break in a few minutes [13:33] PR snapd#4561 opened: tests: generic detection of gadget and kernel snaps [13:52] * kalikiana off for lunch now [13:52] mvo, hey, any specific reason why we abandoned these build stamp / system key branches? [13:54] mvo, hey [14:04] hey cachio [14:04] pstolowski: 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 postpone [14:04] mvo, is the rc2 comming today? [14:05] cachio: thats my goal, however I need a review for the xdg-settings UI branch [14:06] cachio: https://github.com/snapcore/snapd/pull/4342 [14:06] PR #4342: userd: add support for a simple UI that can be used from userd [14:07] mvo, good, I'll take a look [14:08] mvo, I am also working on the test i18n which is failing on master for debian 9 and trusty [14:13] mvo, i see. okay, it seems like a requirement now [14:14] cachio: thank you [14:15] pstolowski: yeah, let me finish my current task, then I can merge master and see how bad the conflicts are :) [14:15] pstolowski: there is also a forum discussion - have you seen that one? [14:17] mvo, not yet, but I think it's linked in one of the PRs [14:18] mvo: another random failure [14:18] (on lxd / 4560) [14:18] I re-started [14:18] mvo, has the ship sailed for 2.31 yet? [14:18] timeout [14:19] kenvandine: no, just initial RCs [14:19] great [14:19] * zyga-ubuntu goes to cook some lunch and then gets back to mount magic [14:19] i thought jamesh's per-user mounts PR would be included [14:19] any chance of that? [14:19] kenvandine: that's possible but unlikely [14:19] :( [14:19] kenvandine: and even if so it won't be "live" [14:19] kenvandine: it will only be useful once we have interfaces using that [14:19] yeah [14:19] kenvandine: I asked jdstrand to review it [14:20] can we get a milestone set on the PR? [14:20] kenvandine: and I will jump onto it soon as now (just this minute) I have my review on my only pending work [14:20] kenvandine: no, I think it's premature [14:20] kenvandine: there are things to do there and it's not something that benefits users yet [14:20]