| daker | hello, build.snapcraft.io question: how can i tell the site to pull submodules too ? | 00:12 |
|---|---|---|
| chatter29 | hey guys | 00:14 |
| chatter29 | allah is doing | 00:14 |
| chatter29 | sun is not doing allah is doing | 00:14 |
| chatter29 | to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger | 00:14 |
| daker | captine: i guess it's commercial | 00:17 |
| Hilikus | is there a browser available in snappy? i am not sure how snappy works with GUIs. will it pull the whole X-server, window manager, etc?? | 00:21 |
| captine | daker, thanks.the liune "available as an image so anyone can download" is a little misleading if it is commercial only | 04:32 |
| mup | PR snapd#3394 closed: interfaces/seccomp: add bind() syscall for forced-devmode systems <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3394> | 06:01 |
| NicolinoCuralli | hi guy, i'm tryng to run the command snapctl set device-service.url="https://device-service" from the login shell but i have the following error: *error running snapctl: cannot set without a context* - where is the problem? | 06:49 |
| morphis_ | NicolinoCuralli: you can only run snapctl from within a hook, like the prepare-device hook | 06:57 |
| morphis_ | manually invoking snapctl from outside of any context is not possible | 06:57 |
| mvo | pstolowski: are you still having this autopkgtest problem? | 06:58 |
| NicolinoCuralli | morphis_: can i run it on configure hook for a snap? | 06:58 |
| morphis_ | yes | 06:58 |
| morphis_ | NicolinoCuralli: however, "snapctl set device-service.url .." only makes sense as part of the prepare-device hook | 06:58 |
| NicolinoCuralli | morphis: I undestand it but i can't setup a Serial Vault for problem that I wrote in a post on forum ( no response until now) and i need to go in production in a few week with our brand store | 07:02 |
| pstolowski | mvo, hi! no, I followed advice from fgimenez and started from a clean directory, it's actually a problem in my branch | 07:05 |
| morphis_ | NicolinoCuralli: you have a link to that thread? | 07:07 |
| NicolinoCuralli | morphis_: https://forum.snapcraft.io/t/how-configure-serial-vault-for-signing-serial-assertion-with-a-key-registered-to-a-store/731/6 | 07:07 |
| fgimenez | hey pstolowski good to know! :) | 07:08 |
| morphis_ | NicolinoCuralli: ah I see, so the problem is just with the setup of the serial-vault, that is up to James | 07:08 |
| fgimenez | good morning mvo! quick question, we didn't have new edge core snaps this morning, is that expected? | 07:09 |
| morphis_ | NicolinoCuralli: but it is essential that snapctl set device-service.url is called from within the prepare-device hook of the gadget snap | 07:09 |
| morphis_ | NicolinoCuralli: otherwise your device bootstrap process may be broken | 07:09 |
| mvo | fgimenez: not expected, let me check | 07:09 |
| fgimenez | mvo: ok thanks! | 07:09 |
| mvo | pstolowski: aha, ok. thank you, still curious what could have caused this. when I have a free minute I will try to dig some more | 07:10 |
| mvo | fgimenez: ha! "store upload failed: service unavailable" … | 07:10 |
| pstolowski | mvo, the root cause i'm chasing is configure hook failure in my branch, and this is related to the renaming of SNAP_CONTEXT variable in my branch (which breaks all hooks in my branch atm) | 07:11 |
| zyga | hey hey | 07:13 |
| NicolinoCuralli | morphis_ : then I am blocked until jamej fix the problem :( | 07:13 |
| fgimenez | mvo: aha, ok, at least the dashboard seems to be fine now | 07:14 |
| morphis_ | NicolinoCuralli: you mean you're blocked because your device gets no serial-assertion? | 07:14 |
| NicolinoCuralli | morphis_ : i need to use Serial-Vault to block device not mine then i'm blocked | 07:16 |
| morphis_ | NicolinoCuralli: you mean you want to block other devices from accessing your branded store? | 07:17 |
| NicolinoCuralli | morphis_ :yes | 07:17 |
| morphis_ | ok | 07:17 |
| morphis_ | you could, as a workaround, turn device authentication off in the branded store and keep things in place until James fixes the problem | 07:18 |
| zyga | mvo: I need some time to get my stuff together and catch up, do I understand that the key issue to fix is still seccomp format? | 07:31 |
| NicolinoCuralli | morphis: prepare-device is very simple but without test it I am sure taht it works: it is very dangerous | 07:37 |
| NicolinoCuralli | morphis: prepare-device is very simple but without test it I am not sure that it works: it is very dangerous for us | 07:37 |
| mvo | zyga: no worries, the seccomp issue has multiple dimensions, the most pressing one is that we need to unblock 2.25, I will catchup with gustavo about this today in a hangout | 07:39 |
| zyga | mvo: how can I help? | 07:39 |
| morphis_ | NicolinoCuralli: sure, but at least you can verify that snapd takes up the right URL but fails to contact it | 07:40 |
| morphis_ | NicolinoCuralli: that is visible in the logs | 07:40 |
| mvo | zyga: then there is the bpf thing which will not help with the immediate issue but will help in the longer term (and is fun :) | 07:41 |
| mvo | zyga: let me think for a sec, the immediate issue is kind-of-blocked on design, I made various suggestions we now just need to decide which one we use | 07:42 |
| zyga | mvo: understood | 07:43 |
| zyga | mvo: I'll try to look at that lock issue | 07:43 |
| mvo | zyga: what was that again about? | 07:43 |
| zyga | mvo: the errors that show up on the errtracker | 07:45 |
| zyga | mvo: about /run/snapd/lock access | 07:45 |
| zyga | mvo: and one working theory that has a hard time to explain the volume of reports | 07:45 |
| mvo | zyga: aha, right, thank you | 07:46 |
| ogra_ | bah ... all core uploads tonight failed with LP OOPSes | 08:02 |
| wgrant | ogra_: https://forum.snapcraft.io/t/store-upload-issue/819/1, fixed a few hours ago. I think Michael's retrying them. | 08:06 |
| ogra_ | mvo, are you ? (else i'll do it now) | 08:07 |
| mvo | ogra_: I have not yet, so go ahead | 08:07 |
| * ogra_ does so :) | 08:07 | |
| ogra_ | oh, interesting ... at the same time i see that LP auto-retries the failed uploads now ... | 08:09 |
| ogra_ | so we'll get two sets :) | 08:09 |
| wgrant | Oh? | 08:09 |
| wgrant | Oh, you requested fresh builds? | 08:09 |
| ogra_ | https://launchpad.net/~snappy-dev/+snap/core/+build/41415 | 08:09 |
| wgrant | I retried that one myself a couple of minutes ago | 08:10 |
| ogra_ | i requested fresh builds ... right afterwards i got a mail for a successfull upload | 08:10 |
| ogra_ | (from the former build obviously) | 08:10 |
| wgrant | If the upload fails, you can just hit the Retry button on the build page. | 08:10 |
| ogra_ | ah, then that was you, ok | 08:10 |
| wgrant | It retries just the upload step | 08:10 |
| ogra_ | yep, i know | 08:10 |
| ogra_ | clicking on 6 buttons on 6 pages is more work than calling a script for a full rebuild though ... i'm lazy ;) | 08:11 |
| wgrant | Heh, fair enough. | 08:13 |
| wgrant | My poor buildds :'( | 08:13 |
| ogra_ | wgrant, FYI, all uploads worked fine for this build | 08:27 |
| wgrant | ogra_: Excellent, thanks for confirming. | 08:28 |
| zyga | pedronis: hey, could you please look at https://forum.snapcraft.io/t/the-gadget-snap/696/4 | 08:32 |
| mvo | zyga: he may not be around today | 09:01 |
| zyga | Chipaca: hey | 09:08 |
| Chipaca | zyga: hiya! | 09:08 |
| JamieBennett | How was the weekend zyga? | 09:08 |
| Chipaca | i've seen photos of zyga doing stuff on twitter | 09:09 |
| zyga | JamieBennett: busy :) | 09:11 |
| zyga | JamieBennett: it was great, just wish I didn't spend nearly two days traveling there | 09:11 |
| zyga | JamieBennett: I sent you some quick thoughts yesterday | 09:11 |
| JamieBennett | zyga: ouch, I didn't realise it was so long for you | 09:11 |
| JamieBennett | zyga: saw the draft feedback, I look forward to the full report | 09:12 |
| zyga | yes, connections | 09:12 |
| ogra_ | zyga, The route is the goal ;) | 09:12 |
| zyga | I'm getting back to speed, catching up on stuff first (I was home past 23:00) | 09:12 |
| JamieBennett | zyga: lets catch up in 45 mins :) | 09:13 |
| zyga | sounds good | 09:13 |
| zyga | mvo: I commented a little on https://forum.snapcraft.io/t/snapd-2-25-blocked-because-of-revert-race-condition/722/13 | 09:15 |
| zyga | mvo: I think the divest idea is sound, I think it may have to be runtime (at least partially) detected but we can work with that | 09:15 |
| zyga | mvo: I'm somewhat on edge about the digest itself, it could be nice to just call this a feature string so that we can easily eyeball things and understand what's going on | 09:15 |
| mvo | zyga: yeah, right now its not much of a digest, I also like the property that it is human readable, lets see what gustavo thinks when we have the catchup. one thing I am slightly worried about is that we need to be careful to make it not too ambitious (at least v1) because we are currently blocking on it | 09:25 |
| mup | PR snapd#3350 closed: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3350> | 09:36 |
| zyga | pedronis: thank you! | 09:43 |
| zyga | pedronis: I'm sorry I didn't review that | 09:43 |
| zyga | mvo: re | 09:44 |
| zyga | mvo: let's finish here | 09:44 |
| zyga | mvo: how would you feel about teaching cmd.go to use the current revision rather than "current"? | 09:45 |
| zyga | Chipaca: hey | 09:46 |
| mvo | zyga: you mean for InternalToolPath? | 09:46 |
| zyga | Chipaca: maybe you can have a saner idea | 09:46 |
| zyga | yes | 09:46 |
| zyga | Chipaca: we have a problem where we use internal tool path that follows the current symlink | 09:46 |
| zyga | Chipaca: and in the upgrade path of core itself, we rely on that _before_ we link the now snap | 09:46 |
| zyga | Chipaca: so new snapd wishing to use its new internal tools uses the old internal tools | 09:46 |
| zyga | Chipaca: and in this case the old internal tool reports "sorry, I'm not implemented" and fails | 09:47 |
| Chipaca | zyga: is this master, or omg-how-on-earth released? | 09:47 |
| * Chipaca wants to know whether to have a heart attack or not | 09:47 | |
| zyga | Chipaca: I think this is master and OMG people tracking channels but I think mvo knows better | 09:48 |
| zyga | Chipaca: but it would explain lots of error reports | 09:48 |
| Chipaca | zyga: master breaks ¯\_(ツ)_/¯ it's why it's edge, i'm less worried | 09:48 |
| mvo | Chipaca: I think its also affecting beta | 09:49 |
| zyga | Chipaca: right but the point is we cannot release and need to fix this | 09:49 |
| Chipaca | mvo: augh | 09:49 |
| mvo | Chipaca: I'm trying to verify this right now, sorry, we are still in the early stages of investigations | 09:49 |
| Chipaca | np! | 09:49 |
| pedronis | zyga: what tools are we calling before we set the symlinks ? | 09:49 |
| mvo | Chipaca: the symptoms are snap refresh outputs: "setup snap "core" (2053) security profiles (cannot update mount namespace of snap "go-example-webserver": cannot update preserved namespace of snap "go-example-webserver": cannot update snap namespace: not implemented)" and fails | 09:49 |
| pedronis | ah | 09:50 |
| zyga | pedronis: update-ns | 09:50 |
| zyga | pedronis: because we follow current symlink | 09:50 |
| pedronis | so there was an assumption that we can call setup-profiles both in the old world and the new world | 09:50 |
| zyga | a naive approach would be to just follow the revision matching core that is running | 09:50 |
| pedronis | zyga: I'm a bit confused though, if the old core is still running why is it trying to call a new tool? | 09:51 |
| Chipaca | zyga: is this actually related to current? | 09:51 |
| zyga | pedronis: it's the new core already | 09:51 |
| pedronis | how can it be | 09:51 |
| Chipaca | runNamespaceTool calls mountNsPath calls mountNsPath which doesn't look at current | 09:51 |
| pedronis | something is not maing sense to me | 09:52 |
| zyga | I'm looking at | 09:52 |
| zyga | https://errors.ubuntu.com/oops/ef5ad412-4519-11e7-ac3f-fa163ebeb28a | 09:52 |
| zyga | look what happens there | 09:52 |
| zyga | we never ran update-ns before it was implemented | 09:52 |
| zyga | but here we run update ns on core (so new snapd is doing that) | 09:52 |
| zyga | and it reaches the never-used, not-implemented version that just says it's not implemented and fails | 09:52 |
| Chipaca | ah, current is used by InternalToolPath | 09:53 |
| zyga | yes | 09:53 |
| zyga | Chipaca: yes, that's exactly the issue | 09:53 |
| Chipaca | zyga: thing is, it isn't current yet | 09:53 |
| pedronis | we run setup-profiles firs time before we run link-snap | 09:53 |
| pedronis | that's by definition the old core | 09:53 |
| Chipaca | so setup-profiles neeeds to run in the new core | 09:53 |
| zyga | pedronis: yes, but pre-restart snapd never touched update-ns | 09:54 |
| Chipaca | so it shouldn't be calling InternalToolPath | 09:54 |
| pedronis | zyga: you understand the question is not how to make it work, why at all is the new core involved at that point? | 09:54 |
| Chipaca | zyga: question: do you know what core you're running for, from UpdateSnapNamespace? | 09:54 |
| zyga | pedronis: aha, I see | 09:55 |
| Chipaca | pedronis does have a good point there though | 09:55 |
| zyga | Chipaca: maybe, we could look at argv[0] or /proc/self/exe | 09:55 |
| Chipaca | zyga: does that get updated on execve? (i don't remember) | 09:56 |
| pedronis | we split setup-profiles to avoid that sort of problem | 09:56 |
| pedronis | if it's happenign a lot of other assumptions are wrong | 09:56 |
| zyga | maybe something else is at play | 09:56 |
| zyga | I have a sync call now but I will look at the revisions used there | 09:57 |
| zyga | and see if there was something wrong at that stage | 09:57 |
| * zyga joins sync call | 10:00 | |
| mvo | Chipaca, zyga: *maybe* it only affects people on 2.26.3+201705171658.git.78e21e6 | 10:08 |
| mvo | zyga, Chipaca: when going over the error reports from the last two days I found only 2.26.3+201705171658.git.78e21e6, 2.26.3+201705191509.git.f89261c, 2.26.3+git209.2f19233 to be affected, everything before and after appears to be fine | 10:17 |
| Chipaca | _and after_? | 10:18 |
| mvo | Chipaca: well, its a good question, things do not refresh so maybe it is something else and this is just where it started | 10:19 |
| pedronis | mvo: maybe that error is from an undo path? not the forward path | 10:23 |
| zyga | JamieBennett: is this me or you? | 10:23 |
| kyrofa | davidcalle, "download ubuntu core" on https://www.ubuntu.com/core is a 404... | 10:27 |
| davidcalle | kyrofa: thanks, the WIP dev.ubuntu.com has been mistakenly deployed when I was off on friday and I'm collecting the pieces... | 10:28 |
| kyrofa | davidcalle, ah, okay. Sorry man, that's never fun | 10:28 |
| davidcalle | kyrofa: I believe you are in Bluefin today? | 10:29 |
| kyrofa | davidcalle, I am! | 10:29 |
| kyrofa | davidcalle, why, are you around? | 10:29 |
| davidcalle | kyrofa: then hug the webteam for me, I'm sending them a ton of bug reports about it ;-) | 10:30 |
| kyrofa | Hahaha | 10:30 |
| davidcalle | kyrofa: no, I'll be there next week for a couple days | 10:30 |
| kyrofa | davidcalle, dangit, come on man, we need to coordinate. I'll be back end of June, come back then | 10:30 |
| davidcalle | kyrofa: well, I could be there, we'll see :) | 10:32 |
| kyrofa | ;) | 10:32 |
| pedronis | Chipaca: btw maybe you can do a 2nd review for snapd#3373 | 10:32 |
| mup | PR snapd#3373: snapstate: consider connect/disconnect tasks in CheckChangeConflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/3373> | 10:32 |
| Chipaca | I can | 10:33 |
| Chipaca | these tests make my head hurt anyway | 10:33 |
| zyga | re | 10:37 |
| * zyga lunch | 11:12 | |
| ogra_ | davidcalle, according to a post in https://forum.snapcraft.io/t/startx-as-a-regular-user/460 the mir-kiosk docs are also gone from dev.ubuntu.com ... | 11:33 |
| davidcalle | ogra_: I know, see above | 11:33 |
| davidcalle | Oh, sorry, missed the "also" | 11:33 |
| ogra_ | :) | 11:34 |
| davidcalle | Saviq: by any chance, when you worked on it a couple weeks ago, did you kept a backup of the content? I may be able to poke around in #IS and get something (archive.org most recent is april 16th from last year), but if you have it in some form it would be way faster to get it back online | 11:41 |
| * Chipaca ~> lunch | 11:54 | |
| ogra_ | pedronis, hmm ... my snap changes on self-built images is full with re-occuring "Initialize Device" entries ... i cant remember having that before (Initialize Device used to run only once and never again when it failed) ... is there any reason that we run it in a loop even though we alredy know the brand id will not be signable ? | 12:07 |
| ogra_ | that makes the snap changes output really noisy and hard to read | 12:08 |
| daker | davidcalle: https://webcache.googleusercontent.com/search?q=cache:K946WjTJyyoJ:https://developer.ubuntu.com/en/snappy/guides/mir-snaps/+&cd=1&hl=en&ct=clnk | 12:19 |
| daker | (21 May 2017) | 12:20 |
| davidcalle | daker: ah! *hug* | 12:27 |
| daker | davidcalle: if you need more content, you can just paste the link on google, there is a little arrow to get the cached version https://imgur.com/a/hDK0D | 12:36 |
| pedronis | ogra_: it's a long while it behaves like that, it has a back off though, at it end it tries 1 or 2 times per day | 12:40 |
| ogra_ | hmm, then i probably didnt see it because my images were old installs ... | 12:41 |
| cachio | mvo, any idea what could be affecting that I run the spread tests in linode from my machine and everything works and when I run the tests from travis the snap-confine-from-core which I modified is failing? | 12:41 |
| ogra_ | pedronis, but i still think trying more than once (as long as we know we reach the store and all) is a waste ... or is there any expectation that all of a sudden my barnd id can sign it ? | 12:42 |
| ogra_ | *brand | 12:42 |
| cachio | mvo, I mean, is there something different in the runs we do from travis? | 12:42 |
| pedronis | ogra_: we expect all devices ideally to have a serial, we are erring on the side of trying by design, as I said after a while it tries 1 or 2 times per day | 12:43 |
| mvo | cachio: a good question, do you have a link to the failure? what travis runs is in .travis.yml, its very little, ./run-check.sh --static, --unit, --spread - does it maybe fail in one of the earlier tests? | 12:44 |
| ogra_ | pedronis, right, but it is very unlikely that a brand id that can not sign suddenly changes its behaviour | 12:44 |
| pedronis | ogra_: we don't interpret the errors | 12:44 |
| ogra_ | so trying it over and over doesnt feel like it makes any sense | 12:45 |
| fgimenez | hi pedronis, new create-key timeout on i386 https://travis-ci.org/snapcore/spread-cron/builds/237349446#L1551 | 12:46 |
| cachio | mvo, this is the link https://travis-ci.org/snapcore/snapd/builds/237376386?utm_source=github_status&utm_medium=notification | 12:47 |
| cachio | mvo, I have executed those tests in the same way and I don't see any error | 12:47 |
| cachio | mvo, also I executed the failing tests from my machine using linode repeating 200 times and all tests passed | 12:48 |
| cachio | mvo, I have modified the test snap-confine-from-core to add a missing check | 12:49 |
| jdstrand | mvo: hey, do you have time to talk about the seccomp/snap-confine issue? | 12:51 |
| jdstrand | mvo: I feel like people aren't hearing my concerns about determinism | 12:51 |
| mvo | jdstrand: I have 8min, then meeting, then time again | 12:52 |
| mvo | cachio: looking, one sec | 12:52 |
| mvo | cachio: hm, that sounds strange indeed | 12:53 |
| mvo | jdstrand: am I one of the people who fail to hear your concern bout determinsim? if so, I definitely want to understand them | 12:53 |
| jdstrand | mvo: well, I don't know if you are-- I feel that way because I haven't heard anyone acknowledge my point :) | 12:55 |
| jdstrand | mvo: my point is-- the actually problem is that the policy on disk is not reflective of the snapd/snap-confine version that is used | 12:56 |
| jdstrand | actual* | 12:56 |
| mvo | jdstrand: not sure how busy you are today, but I would love to talk about it after our standup (so in ~30min or 45min depending how long it runs) | 12:56 |
| jdstrand | mvo: please ping me whenever you are free | 12:56 |
| jdstrand | mvo: it shouldn't take terribly long, but likely more than 8 minutes | 12:57 |
| zyga | jdstrand, mvo: I'd like to participate please | 12:57 |
| zyga | jdstrand: I think I understand your concern | 12:57 |
| zyga | (and what mvo is trying to do) | 12:57 |
| mvo | jdstrand: great, I will. however I'm not sure if thats the actual problem, I think we have a various ones (startup race, profiles not forward compatible, not versionized) but I think we will fix them all :) | 12:58 |
| mvo | zyga: sounds good | 12:58 |
| mvo | zyga: super keen to hear yours and jdstrand ideas what we can do | 12:59 |
| jdstrand | mvo: I don't mind any of the improvements, but my point is that it just pushes the problem around. we need to have policy that is generated by the running snapd/snap-confine version otherwise there will always be other issues. it just so happens, if that is fixed, all the improvements are less important | 12:59 |
| zyga | mvo: I think your idea is OK but jdstrand wants to ensure snapd still starts before services / commands can run, | 13:00 |
| zyga | standup! | 13:00 |
| jdstrand | yes | 13:00 |
| mvo | jdstrand, zyga: yes, I think we want the same, its just one of the steps | 13:00 |
| jdstrand | but if it is the first step, things are nice :) | 13:01 |
| jdstrand | anyway :) | 13:01 |
| roadmr | jdstrand: tools r822 are now in prod \o/ | 13:45 |
| jdstrand | roadmr: woohoo! :) | 13:48 |
| jdstrand | roadmr: thanks :) | 13:48 |
| morphis_ | zyga: I sadly don't have time for that today but it would be great if we could sync up about the suse stuff tomorrow | 13:48 |
| * Chipaca kicks off spread tests and goes for a cuppa tea | 13:59 | |
| didrocks | sergiusens: hey! small question: is it possible in the dump plugin, or via a scriptlet to differ actions (files to install) through arch? | 14:50 |
| didrocks | I can ofc run "arch" in the scriplets, and depending on the result do some magic… | 14:50 |
| didrocks | was wondering if there was something more "out of the box" | 14:50 |
| mvo | zyga: ping me once you have build/downloaded a snapd with the right revision to reproduce the refresh hang | 14:51 |
| zyga | mvo: sure | 14:54 |
| kyrofa | didrocks, not right now, but it's on the roadmap | 14:55 |
| zyga | mvo: I cannot find core at revision 1968, I no longer have access to core | 14:59 |
| didrocks | kyrofa: ok, so you would advise relying on `arch` right now? | 15:00 |
| kyrofa | didrocks, if that covers your use-case, go for it. It obviously won't solve everything | 15:01 |
| kyrofa | We're trying to make a generic way to specify most things using a grammar similar to the stage-packages | 15:02 |
| niemeyer | Lunch! | 15:02 |
| mvo | zyga: you are still listed as a collaborator | 15:03 |
| zyga | hmm | 15:03 |
| zyga | sudo snap refresh --revision=1968 core | 15:03 |
| zyga | this fails with: error: cannot refresh "core": snap not found | 15:03 |
| mvo | zyga: oh, that will not work | 15:03 |
| mvo | zyga: or maybe it should | 15:03 |
| mvo | zyga: interessting | 15:03 |
| zyga | I think it should work | 15:03 |
| ogra_ | it should | 15:03 |
| zyga | Chipaca: ^^ | 15:03 |
| ogra_ | i use that all the time | 15:03 |
| zyga | anyway, I need that coffee | 15:04 |
| zyga | brb | 15:04 |
| ogra_ | are you sure 1968 is the one you want ? | 15:04 |
| zyga | maybe, mvo is that the one you are on? | 15:04 |
| ogra_ | (i.e. is it your arch) | 15:04 |
| mvo | zyga: I'm on 1968 | 15:04 |
| mvo | zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages?field.name_filter=snapd&field.status_filter=&field.series_filter= might also be a place to look for the revno | 15:04 |
| pedronis | --revision works only if you can push to the snap | 15:04 |
| ogra_ | oh | 15:04 |
| ogra_ | indeed ... and i can | 15:05 |
| ogra_ | (for core) | 15:05 |
| zyga | and supposedly so can I | 15:05 |
| ogra_ | i dont think so | 15:05 |
| * ogra_ checks | 15:05 | |
| ogra_ | (if the dashboard ever loads ... tap ... tap ... tap) | 15:05 |
| Chipaca | zyga: log in | 15:05 |
| Chipaca | zyga: assuming you've got dev access to core, you can pull arbitrary revisions with --revision; otherwise no | 15:06 |
| zyga | ah | 15:06 |
| ogra_ | yeah, zyga should be able to ... | 15:06 |
| zyga | that was it | 15:06 |
| zyga | sorryt | 15:06 |
| zyga | I used sudo | 15:06 |
| zyga | it works | 15:07 |
| azubieta | Hello, I'm traing to build an snap of Konsole. I followed this tutorial https://apachelog.wordpress.com/2016/12/02/snapping-kde-applications/ but I'm getting the following error "" | 15:07 |
| azubieta | You need to connect this snap to the kde-frameworks-5 snap. | 15:07 |
| azubieta | You can do this with those commands: | 15:07 |
| azubieta | snap install kde-frameworks-5 | 15:07 |
| azubieta | snap connect :kde-frameworks-5-plug kde-frameworks-5:kde-frameworks-5-slot | 15:07 |
| azubieta | I already did what the instructions says without success | 15:08 |
| * zyga looks at a 48GB 24CPU box | 15:09 | |
| zyga | but first, coffee | 15:10 |
| * genii sips | 15:10 | |
| zyga | re | 15:18 |
| zyga | ok, back with my coffee | 15:18 |
| kyrofa | Chipaca, if a channel closes, is snapd not currently falling back today? | 15:18 |
| zyga | mvo: I'm on the smae revision now | 15:18 |
| Chipaca | kyrofa: yes, why? | 15:18 |
| Chipaca | kyrofa: I mean yes it is falling back | 15:18 |
| kyrofa | Chipaca, in a released version? | 15:19 |
| Chipaca | kyrofa: I don't think it's ever not fallen back | 15:19 |
| pedronis | also that behavior is fully on the store side | 15:19 |
| Chipaca | kyrofa: you're making me nervous :-) | 15:20 |
| kyrofa | Chipaca, sergio is claiming it doesn't.... made ME nervous | 15:20 |
| mvo | zyga: does snap refresh --edge work for you? | 15:21 |
| pedronis | fgimenez: https://travis-ci.org/snapcore/snapd/builds/237053889 seems to be failing with timeouts in lots of prepares | 15:21 |
| Chipaca | kyrofa: psh. What does sergiusens know | 15:21 |
| Chipaca | sergiusens: no seriously tell us | 15:21 |
| zyga | mvo: trying | 15:23 |
| fgimenez | pedronis: thx looking | 15:23 |
| zyga | mvo: yes | 15:23 |
| zyga | mvo: I'm now on 2053 | 15:23 |
| zyga | mvo: which version of the package are you on? | 15:23 |
| zyga | mvo: I suspect it worked for me because I installed locally-built package earlier | 15:24 |
| mvo | zyga: aha, you were on a non-rexec version? | 15:24 |
| zyga | mvo: possibly | 15:24 |
| mvo | zyga: snap version will know | 15:24 |
| mvo | zyga: but not anymore :) | 15:24 |
| zyga | mvo: anyway, I should reinstall snapd from the archive | 15:24 |
| zyga | ok | 15:25 |
| zyga | I'm on 2.25 | 15:25 |
| fgimenez | pedronis: on of the errors is super weird https://travis-ci.org/snapcore/snapd/builds/237053889#L1220 it previously checked for SNAP_REEXEC != 0 here https://travis-ci.org/snapcore/snapd/builds/237053889#L1187 | 15:25 |
| fgimenez | one of the errors | 15:25 |
| zyga | mvo: now to switch back core | 15:25 |
| zyga | and try | 15:25 |
| pedronis | fgimenez: also one of the restore timed out, I suppose one a restore fails then we can be in really weird stats | 15:26 |
| pedronis | s/one a /once a/ | 15:26 |
| zyga | mvo: reproduced! | 15:26 |
| zyga | mvo: thank you | 15:26 |
| zyga | mvo: so, quick suspicion, there was one day when snapd from core would run snap-update-ns from distro | 15:27 |
| fgimenez | pedronis: indeed, if they don't come alone the restore errors might be caused by something that failed before | 15:27 |
| zyga | mvo: I fixed that on monday after landing update-ns on friday | 15:27 |
| mvo | zyga: it might be that, yeah. | 15:27 |
| zyga | mvo: if this is that version then there's no bug to look for (hopefully) | 15:27 |
| mvo | zyga: this would explain the narrow set of versions we are seeing this | 15:27 |
| mvo | zyga: plus it never left edge | 15:27 |
| zyga | mvo: yes | 15:27 |
| zyga | mvo: so the snap-update-ns in core is correct (does real stuff) | 15:28 |
| zyga | mvo: but we are running the one I have in /usr/lib/snapd | 15:28 |
| pedronis | from 2.25 | 15:28 |
| zyga | yes | 15:28 |
| zyga | essentially | 15:28 |
| mvo | zyga: now the question is what we do about all N people who are affected. we could simply ignore the problem | 15:28 |
| zyga | mvo: aha, good question | 15:28 |
| zyga | mvo: eventual exnial release will fix it | 15:29 |
| mvo | zyga: good point | 15:29 |
| zyga | mvo: we could do a point release | 15:29 |
| zyga | mvo: and SRU it quickly | 15:29 |
| zyga | mvo: to have update-ns just return 0 | 15:29 |
| zyga | while saying not implemented | 15:29 |
| zyga | mvo: I can prepare a debdiff if you think this is worth doing | 15:30 |
| === heber_ is now known as heber | ||
| ogra_ | if it never left edge anyway ... why bother | 15:30 |
| mvo | zyga: probably fine to ignore for now as long as the number is very small | 15:31 |
| zyga | mvo: use repair assertion :D | 15:31 |
| mvo | zyga: soon | 15:31 |
| * zyga would love if we could try that :-) | 15:31 | |
| zyga | but still chicken-and-egg | 15:31 |
| pedronis | we should tell the pople with it what to do though on the forum | 15:31 |
| pedronis | *people | 15:31 |
| zyga | pedronis: good point | 15:31 |
| zyga | pedronis: I think refreshing to stable | 15:31 |
| zyga | pedronis: and to edge should fix it | 15:32 |
| * zyga tries | 15:32 | |
| zyga | mvo: actually, maybe universal recovery stragegy for broken edge? | 15:32 |
| pedronis | no, because with patches or patch like stuff it might break as well | 15:35 |
| fgimenez | pedronis: interfaces-cups-control got stuck too on apt-get install (18mb) https://travis-ci.org/snapcore/snapd/builds/237053889#L6883 | 15:36 |
| zyga | pedronis: in theory yes but we stopped doing that, right? | 15:36 |
| pedronis | well we stopped using patches | 15:36 |
| pedronis | but we do some stuff like that in ensure | 15:36 |
| pedronis | so not completely broken | 15:36 |
| pedronis | but you can get interesting effects | 15:37 |
| zyga | pedronis: indeed though those are (for now) still safe | 15:37 |
| pedronis | so really edge to beta or edge to candidate | 15:37 |
| pedronis | might be better | 15:37 |
| pedronis | than jumping all the way to stable | 15:37 |
| zyga | mvo: anyway, I think for this case refresh to core does not work | 15:37 |
| pedronis | if possible | 15:37 |
| zyga | mvo: so we need to help people but we need something else | 15:37 |
| zyga | mvo: I'd suggest replacing update-ns in the package with bin/true | 15:37 |
| zyga | mvo: from there on it would work, if you want I can write a blog post | 15:37 |
| zyga | mvo: I can even make a shell script that "recovers" the system | 15:38 |
| pedronis | fgimenez: I wonder, would increasing the timeout help, or do we get into stuck states somehow for which even waiting forever wouldn't help, also wonder whether we should do the reverse, see what are the usual times, and reduce the timeout, so we fail fast | 15:45 |
| zyga | mvo: let me know if you want me to do that | 15:48 |
| fgimenez | pedronis: yes, i don't think increasing the timeout further would help too much | 15:50 |
| fgimenez | pedronis: i was wondering if keeping disabled ip6 here would help https://github.com/snapcore/snapd/blob/master/spread.yaml#L258, most of these timeouts happen during downloads for installations | 15:53 |
| kyrofa | Chipaca, https://forum.snapcraft.io/t/channel-fallback-doesnt-change-tracked-channel/828 | 15:55 |
| Chipaca | kyrofa: but fallback != changing tracked | 15:56 |
| kyrofa | It continues tracking the closed channel? | 15:56 |
| Chipaca | kyrofa: the channel tracked does not change | 15:56 |
| Chipaca | kyrofa: correct | 15:56 |
| Chipaca | kyrofa: if you're tracking beta, and beta closes for a bit, you don't want to be dumped onto stable indefinitely | 15:57 |
| kyrofa | Chipaca, huh... seems unintuitive for branches though | 15:57 |
| kyrofa | Chipaca, I mean, that revision that I just refreshed to did _not_ come from stable/junk. I never released it there | 15:58 |
| Chipaca | kyrofa: maybe snap info could say something like "tracking: foo/stable/hotfix (from foo/stable)? Although I don't know how we'd get that info | 15:59 |
| Chipaca | s/\)\?/)"?/ | 15:59 |
| kyrofa | Yeah... it's just not stating the truth there :P | 16:00 |
| Chipaca | kyrofa: it is stating the truth | 16:01 |
| Chipaca | kyrofa: you're misunderstanding the truth that it's stating | 16:01 |
| ogra_ | alternative facts! | 16:01 |
| ogra_ | belive in them! | 16:01 |
| Chipaca | kyrofa: if you were to reopen and push a snap into foo/stable/hotfix, and a different one into foo/stable, it would get the one from foo/stable/hotfix and not the other one | 16:02 |
| kyrofa | Hahaha | 16:02 |
| niemeyer | sergiusens: What's WW21? | 16:07 |
| Chipaca | world war 21: madagascar is back for more | 16:08 |
| nacc | What Would 2 1 | 16:09 |
| niemeyer | Chipaca: That's what I associated with as well :) | 16:09 |
| jdstrand | mvo: approved https://github.com/snapcore/snapd/pull/3397 | 16:13 |
| mup | PR snapd#3397: interfaces: disable "mknod |N" in the default seccomp template again <Created by mvo5> <https://github.com/snapcore/snapd/pull/3397> | 16:13 |
| Son_Goku | niemeyer, zyga, morphis_: can we adjust the man page generation code to mark it as section 8? | 16:15 |
| jdstrand | mvo: if you put the digest one in PR form, I can comment on the approach (I don't seem to be able to comment on the link you gave) | 16:15 |
| Son_Goku | I got a bug report about a file conflict: https://bugzilla.redhat.com/show_bug.cgi?id=1456847 | 16:16 |
| niemeyer | Son_Goku: I recall we discussed this before.. what was the agreement last time? | 16:16 |
| jdstrand | mvo: actually, I see the forum topic now | 16:16 |
| Son_Goku | niemeyer: you said it makes sense, but the code that generates it doesn't actually support selecting sections, and "it doesn't matter" | 16:17 |
| Son_Goku | fwiw, for the longest time, the man page in Ubuntu was written out as snap.8 until I pointed out the mismatch | 16:17 |
| niemeyer | Son_Goku: What I recall from the discussion is that section 1 was actually fine.. is it not? | 16:19 |
| Son_Goku | it's not | 16:20 |
| niemeyer | Why not? | 16:20 |
| Son_Goku | there's already a snap(1) | 16:20 |
| Son_Goku | from https://apps.fedoraproject.org/packages/snap | 16:20 |
| Son_Goku | a backup utility | 16:20 |
| Son_Goku | switching computers, will be Pharaoh_Atem | 16:22 |
| zyga | morphis_: ^^ this is the bug I mentioned earlier today | 16:25 |
| morphis_ | zyga: interesting | 16:26 |
| morphis_ | niemeyer: ping, you have some time discussing `snapd --user`? | 16:26 |
| niemeyer | Pharaoh_Atem: I see.. | 16:27 |
| niemeyer | Pharaoh_Atem: Should be very easy to hack the output of snap help --man so it reports .8 without us having to fix go-flags everywhere | 16:28 |
| niemeyer | Pharaoh_Atem: To be clear, tough, that's a hack.. the .1 section is in fact fine for the tool | 16:28 |
| niemeyer | Even systemctl is in there | 16:28 |
| niemeyer | morphis_: Yeah | 16:29 |
| morphis_ | Pharaoh_Atem: just tested the latest snapd package in updates-testing, only seeing an empty /var/lib/snapd/ left after snapd is removed | 16:30 |
| morphis_ | Pharaoh_Atem: all other things are removed this time | 16:30 |
| morphis_ | niemeyer: sent you a PR with a HO link | 16:30 |
| morphis_ | s/PR/PM/ | 16:31 |
| Pharaoh_Atem | niemeyer: I guess I'll do that | 16:33 |
| sergiusens_ | niemeyer: work week 21 of the calendar year | 16:34 |
| __chip__ | Pharaoh_Atem: sorry, i missed the start of this; you're wanting it to be snap(8) and not snap(1) | 16:34 |
| __chip__ | ? | 16:34 |
| Pharaoh_Atem | __chip__: yeah | 16:35 |
| Pharaoh_Atem | but I think I might have just found another solution (for the moment) | 16:35 |
| __chip__ | Pharaoh_Atem: what's the driver of that change? | 16:35 |
| Pharaoh_Atem | file conflict: https://bugzilla.redhat.com/show_bug.cgi?id=1456847 | 16:36 |
| === jkridner|pd is now known as jkridner | ||
| Pharaoh_Atem | but that said, this might actually be solvable in a different way | 16:36 |
| __chip__ | Pharaoh_Atem: if you move the manpage out of the way, won't the binary be the thing reported as conflicting? | 16:36 |
| Pharaoh_Atem | nope | 16:36 |
| __chip__ | how come? | 16:36 |
| Pharaoh_Atem | it doesn't provide /usr/bin/snap | 16:36 |
| Pharaoh_Atem | it provides /usr/bin/snaptool | 16:37 |
| Pharaoh_Atem | apparently, it *used* to be snap, and now it's not | 16:37 |
| __chip__ | ah | 16:37 |
| Pharaoh_Atem | the man page is symlinked to the old name as well | 16:37 |
| Pharaoh_Atem | so I'm going to see if I can just get them to drop the old symlink | 16:37 |
| Pharaoh_Atem | because otherwise, I guess I'm sedding to section 8 | 16:37 |
| __chip__ | I can understand why they'd do that, but it would be very confusing for a user seeing 'snap' and 'snaptool' binaries, and the manpages not lining up | 16:38 |
| Pharaoh_Atem | Yep | 16:38 |
| __chip__ | I mean, I'd probably notice (after the initial WTF) but it'd be surprising (and so derailing) to people | 16:39 |
| __chip__ | anyway, preaching to the choir, probably | 16:39 |
| * __chip__ goes back to hacking | 16:39 | |
| niemeyer | sergiusens_: Can we agree on a summary that works for both snapd and snapcraft, and preferably one that doesn't remind us of world wars? :) | 16:43 |
| ogra_ | niemeyer, but then we'll miss the beautiful and funny comments from __chip__ ;) | 16:45 |
| sergiusens_ | niemeyer: sure, I don't mind changing the subject line/title | 17:04 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/3410 | 17:04 |
| mup | PR snapd#3410: cmd/hotfix: add hotfix tool <Created by zyga> <https://github.com/snapcore/snapd/pull/3410> | 17:04 |
| mup | PR snapd#3410 opened: cmd/hotfix: add hotfix tool <Created by zyga> <https://github.com/snapcore/snapd/pull/3410> | 17:04 |
| zyga | mvo: in case we want to help anyone particular that may be affected | 17:04 |
| niemeyer | sergiusens_: "Week 21/2017 in snapcraft"? | 17:06 |
| * zyga breaks | 17:10 | |
| * ogra_ looks for the glue to fix zyga | 17:11 | |
| mup | PR snapd#3411 opened: tests/main: enable a first set of test cases for Fedora and openSUSE <Created by morphis> <https://github.com/snapcore/snapd/pull/3411> | 17:11 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#3412 opened: tests: fix for snapd-reexec test cheking for restart info on debug log <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3412> | 18:32 |
| === chihchun is now known as chihchun_afk | ||
| === cachio is now known as cachio_afk | ||
| luk3yx | How do I specify a folder in a GitHub repo for build.snapcraft.io? | 20:06 |
| kyrofa | luk3yx, cprov might be able to answer that | 20:13 |
| luk3yx | cprov, can you? | 20:17 |
| luk3yx | kyrofa, thanks. | 20:19 |
| cprov | sorry, otp. I don't understand the folder question. do you mean a folder within the repo with snapcraft.yaml|.snapcraft.yaml ? | 20:19 |
| luk3yx | A folder in the repo. | 20:19 |
| luk3yx | *within | 20:19 |
| cprov | that is not supported, IFAICT | 20:20 |
| cprov | 1 repo per snap, basically | 20:20 |
| thomi | This has also been suggested here: https://forum.snapcraft.io/t/one-folder-per-snap-in-build-snapcraft-io/792 but it's not clear to me how it'd work | 20:21 |
| luk3yx | I keep different versions of the same snap in different directories. | 20:46 |
| luk3yx | Does it do 32-bit builds? | 20:50 |
| luk3yx | ...or do I still need to manually do i686 builds? | 20:50 |
| nacc | luk3yx: wouldn't you just have them in different branches? | 20:51 |
| luk3yx | I've simplified it now, commits can roll back if required. | 20:52 |
| luk3yx | One question. | 20:53 |
| luk3yx | It can't build my snap, as it's designed for the latest release (17.04). | 20:53 |
| luk3yx | Can it build the non-LTS release? | 20:54 |
| nacc | luk3yx: meaning you are using some packages from 17.04? | 20:54 |
| luk3yx | Yes. | 20:54 |
| luk3yx | ...that don't exist on 16.04. | 20:54 |
| nacc | luk3yx: i've only used the LP builders, but there, you can tell it what release to build under | 20:54 |
| luk3yx | Okay. | 20:54 |
| nacc | luk3yx: i'm looking on b.s.io | 20:55 |
| luk3yx | Okay. | 20:55 |
| luk3yx | I've send feedback. | 20:56 |
| luk3yx | *sent | 20:56 |
| luk3yx | Hopefully they'll fix the issue. | 20:56 |
| === cachio_afk is now known as cachio | ||
| === cachio_afk is now known as cachio | ||
| cachio | niemeyer, do you know why the tests usually don't uninstall the snaps used? | 22:01 |
| daker | anyone to help with a store issue ? i can't install a snap that is published in the edge channel | 22:57 |
| luk3yx | Did you use --edge? | 22:59 |
| luk3yx | daker, did you? | 23:01 |
| daker | luk3yx: yes sudo snap install --edge $snapname --revision=1 | 23:02 |
| luk3yx | What's the error? | 23:02 |
| daker | it's says : snap not found | 23:02 |
| nacc | daker: what's the snap's name? | 23:02 |
| daker | nginx-rtmp | 23:03 |
| nacc | daker: i'm not sure such a snap exists | 23:06 |
| nacc | daker: where did you find a reference to it? | 23:06 |
| daker | nacc: i used snapcraft build site to publish, i can see it in the store (dashboard.snapcraft.io) https://i.imgur.com/3vCeFJr.png | 23:08 |
| nacc | daker: possiblyou also need to tell it y ou want devmod | 23:09 |
| nacc | daker: by default it won't install such a thing, iirc | 23:09 |
| daker | nacc: yes you are right, i need to add --devmode, it works now | 23:11 |
| nacc | daker: great! :) | 23:12 |
| daker | nacc: thanks | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
