[00:12] Hii there, so im using crux [00:12] anyway for me to install snap from source ? [01:03] niemeyer: you there? [01:03] Ronin: no [01:03] Ronin: unless you're referring to snapd? [01:04] Pharaoh_Atem: yee i was referring to snapd [01:05] Ronin: crux would be difficult due to missing systemd [01:06] i wouldnt call it missing , but thats unlucky i guess [01:06] my search for a way to get discord continues lol [01:07] Ronin: does CRUX provide flatpak? [01:09] hmm guess not [01:09] Ronin: Discord is available as a snap and a flatpak [01:10] Pharaoh_Atem: yupp i know [01:10] its the one package im missing [01:10] heh [01:10] it's the first time in a while I've heard of anyone using CRUX [01:19] im using void linux on my main system [01:19] installed crux on my laptop to try it out, gotta say i quite like it so far [01:19] just that im missing some packages [04:25] Bug #1781120 opened: 18.04 kernel 4.15.0-24 snappy can't start [06:47] good morning === pstolowski|afk is now known as pstolowski [06:54] mornings, hey zyga [07:13] cześć! [08:01] pedronis: hey [08:01] pedronis: around? [08:10] pstolowski: I'll move json serialization of various repo types to the daemon [08:12] zyga: makes sense [08:12] I think we agreed to do this long time ago [08:12] or something similar [08:19] wow [08:20] I found a file with copyright 2014 [08:22] wow [08:22] we have copies of repo json code in daemon :) [08:22] * zyga is happy to clean this up [08:27] can someone in the know confirm that when a snap is unpublished from the store, it doesn't get uninstalled from user's devices? [08:28] oSoMoN: that's correct [08:28] we don't have any code that could uninstall a snap [08:28] this way that is [08:33] zyga, thanks [08:47] pstolowski: can you please look at https://github.com/snapcore/snapd/pull/5496 [08:47] PR #5496: interfaces,daemon: move JSON types to the daemon [08:47] zyga: sure [08:48] PR snapd#5496 opened: interfaces,daemon: move JSON types to the daemon [08:48] I'll keep hacking in that direction, there is clearly some more cruft there [08:49] Chipaca: hey [08:49] around? [08:50] zyga: no [08:50] :D [08:50] zyga: asquare [08:51] perfect [08:51] daemon api question [08:51] how would you feel if I moved all the jsonization types to api_json.go [08:51] I added some there because I'm cleaning up the interface repository json story [08:51] and I noticed we have a few types scattered around the api.go file [08:51] zyga: including the stuff in snap.go? [08:52] while you think please look at 5496 api_json.go to see what that would look like [08:52] no, only stuff unique to the api layer [08:52] that is currently in random places in api.go [08:52] zyga: daemon/snap.go [08:52] ah, this one [08:52] no, I don't think so [08:53] zyga: it's the only snap.go :-) [08:53] nothing there uses json tags [08:53] I though of snap/*.go [08:53] zyga: correct, code there just builds map[string]stuff [08:53] that is fine [08:53] I just noticed we have some duplication in the types [08:54] because they were in separate packages [08:54] and also some types were super-alike [08:54] and just defined few pages away from each other [08:54] zyga: if it's duplication between daemon and client, that was intentional [08:54] no no [08:54] (which isn't to say i agree with it) [08:55] this is all in the daemon/* area [08:55] I know about the purpuseful duplication with the client package [08:55] k [08:57] zyga: I'm not sure I understand 5496 [08:57] zyga: in general I think it's better to have the marshaller next to the type it's marhsalling [08:57] yes, but: [08:58] zyga: were the slotJSON etc in daemon even used? [08:58] 1) we never intended to return snap.{Plug,Slot}Info this way [08:58] 2) we had duplicates between repo and daemon [08:58] (yes, both were used /o\) [08:59] 3) we want to introduce code that changes some of the info's just before they are sent and pedronis opposed doing that to the original types [08:59] so I want to do that to the json types instead [08:59] hence the clenaup [08:59] *cleanup [08:59] both types were used because we have legacy/non-legacy interface APIs [08:59] fair [08:59] and they used both by accident [08:59] a bit silly [09:03] zyga: seems my worry is introducing lots of complications, otoh that remapping by taking an info and just changing name inside looks very strange/fragile at face value [09:03] pedronis: not complications, cleanups [09:04] pedronis: there were clearly copy/pasted types around [09:04] pedronis: not that I didn't change the info that was handed in, I returned a modified copy [09:04] some day I'll have time to rewrite daemon [09:04] I know [09:04] there's so much stuff i'd do better today [09:04] still strange [09:05] I'm also not sure did those infos had implicit slots in them, does it matter ? [09:06] pedronis: they had slots, both implicit and not [09:07] pedronis: they were added at a much earlier stage [09:07] in the request/response timeline, not in our git log timeline) [09:07] so were basically taking a snapd snap info (with implicit slots) and calling it core ? or the other way around [09:07] that's admittedly strange [09:07] yes [09:08] in reality it was just a way to return a snap name and slot name [09:09] zyga: thanks for that cleanup.. i remember cleaning some of that (the legacy connections) but missed the second part [09:10] pstolowski: I pushed the second patch to the PR so that there is no duplication inside the daemon either now [09:12] ok, with this the re-mapping code should no longer have to touch snap.Info [09:23] * zyga cannot wait for tests to finish [09:42] * Chipaca afk for a while [10:42] pstolowski, pedronis: https://github.com/snapcore/snapd/pull/5496 is green and blocking me [10:42] PR #5496: interfaces,daemon: move JSON types to the daemon [10:42] can we land it [10:45] PR core18#44 closed: hooks: fix 030-fix-timedatectl.chroot to DTRT when running on non-core devices [10:49] guys? [10:50] jdstrand: hey, around? [11:04] zyga: i need to give it proper looked, only skimmed through it; will review before/after standup [11:04] *look [11:05] thanks [11:05] zyga: sorry about that [11:09] PR snapd#5497 opened: overlord/patch: patch for static plug/slot attributes === pstolowski is now known as pstolowski|lunch [11:12] pedronis: hmm is this expected: [11:12] https://www.irccloud.com/pastebin/8R1R97lR/ [11:12] pedronis: I cannot abort change 54 [11:13] kyrofa, when snapcraft can finally build Fedora based snaps, it should forbid excluding `/usr/share/licenses`: https://forum.snapcraft.io/t/legal-issues-when-excluding-usr-share-doc/6341 [11:13] zyga: no idea [11:13] ah, it timed out now [11:13] it has an undo [11:13] but systemctl as well [11:13] niemeyer: hey, you there? [11:40] * zyga iterates on the signal test [11:43] Chipaca: around? [11:43] Chipaca: can you please review https://github.com/snapcore/snapd/pull/5496 [11:44] PR #5496: interfaces,daemon: move JSON types to the daemon [11:44] zyga: knee deep in spread tests [11:44] ack [11:44] next step: waist deep? :) [11:51] zyga: I daren't venture more into the miasma, as it sucks you in [11:51] also, I daren't postpone lunch [11:51] * Chipaca goes to sort that out === apw_ is now known as ap === ap is now known as Guest79801 === Guest79801 is now known as apw [12:00] * zyga prepares for lunch [12:11] eh eh eh [12:11] Chipaca: would it make sense to have a way to install a snap without starting the services [12:12] because the services require connection to an interface [12:12] that is not denied but also not auto-connected [12:12] Chipaca: the particular use-case is daemon-notify [12:12] it is a bit silly but it is not auto-connected [12:13] and this prevents daemon: notify services [12:13] this prevents the snap from being installed [12:13] catch 22 [12:13] in effect nobody can develop a daemon: notify service ever [12:14] jdstrand: ^ FYI daemon: notify requires connected daemon-notify plug (not auto-connected) but this can never be done because failing services prevent the snap from being installed [12:16] jdstrand: I'm not sure if a snap-declaration assertion can override this (auto-connection of a slot that can be connected manually) but this is not useful for developers as far as experience is concerned [12:16] I think something has to go [12:23] zyga: yes, snap-declaration can set auto-connect per snap [12:24] pedronis: thanks [12:31] zyga: it isn't silly that it isn't auto-connected. there have been vulnerabities on the notify socket. there is a card (still) to investigate that further, but the decision was to manually connect for now. [12:32] zyga: this sounds like a problem with the application. why is it crashing so hard? === pstolowski|lunch is now known as pstolowski [12:34] jdstrand: systemd kills a notify daemon if it doesn't notify within a timeout [12:34] I see [12:34] well, yes, auto-connection is available for now [12:35] but I thought you could just use snapctl to disable the service from the instlal hook [12:37] jdstrand: it is not crashing, it is not starting according to systemd as Chipaca explained [12:38] hmm, I wonder what to do, this is really about me fixing a flaky test [12:38] jdstrand: so it _should_ auto connect in when installed locally with --dangerous? [12:39] * zyga removed it for now, trying to see if this helps [12:40] it's quite annoying trying to develop a snap that keeps failing to install :) [12:40] I should break [12:40] see you at the startup [12:42] hi guys, I have a java web application, now i want to create a snap for this app. when I tried to create a snap it shows "[Redirection detected from https to http. Protocol switch unsafe, not allowed.]" in the build part. please someone guide me to solve this problem. [12:43] newbee: not a snapcraft expert but this seems like the URL was specified as HTTPS but something (perhaps a proxy) redirected that to a HTTP, thus nullifying the encryption of the connection. [12:43] what is the URL you are hitting? [12:46] @zyga, I am not using any URL for this, in my snap I call tomcat in the part. In the building part it shows this error. [12:48] @zyga : the snap access the URL in the build.xml file to buils the tomcat [12:50] @zyga :Can you please give me some examples to create the tomcat snap. [12:50] no [12:50] I don't know anything about tomcat [12:50] let me look if we have any stock examples though [12:51] Okay thank you... [12:51] newbee: looking at https://wiki.ubuntu.com/snapcraft/parts I see some tomcat parts, maybe that will be of some help [12:52] Is there any other way to create the web snap in ubuntu core? [12:55] newbee: I think you'd be best starting a topic on the forum [12:59] newbee: I think you can create a web-talking snap using the typical suspects: python, java, go; it's just that I'm not the best person to share examples with you as I work on the other side of snappy (the service) [12:59] newbee: perhaps kyrofa or popey have some tomcat-based snaps they can point you to [13:00] newbee: though Chipaca's advice stands: this is a perfect topic for the forum where people will see it outside of the 15minute focus window of your question here [13:03] @zyga : Thanks for your help... I will start this topic on the forum... [13:04] hmm, standup [13:05] @Chipaca : Okay.... [13:14] zyga: i have no tomcat snaps [13:44] jdstrand: hey, about sd-notify, did we consider having snapd be the proxy for the socket [13:44] jdstrand: so it could read the requests, inspect them and forward/ignore [13:45] jdstrand: is this something that is doable or is systemd going to ignore the messages relayed by another process? [13:46] zyga: we didn't afaik. I suspect that systemd would then monitor snapd in that case [13:46] mmm, interesting, [13:46] if this is something that would need systemd patches then we cannot rely on it [13:46] so no notification by default, no proxying possible, [13:47] jdstrand: although systemd-notify has a --pid argument so _perhaps_ we could [13:48] zyga: as mentioned, this isn't a feature I'm super familiar with. there is a card to investigate further to see if we can make it auto-connect. that card continues to have several things in front of it [13:49] jdstrand: sure, no worries, this is not a priority bump of any kind [13:50] zyga: I triple-checked, with --dangerous auto-connect are based on the base declaration, so you get the things that are allowed there [13:50] pedronis: thank you! [13:50] pedronis: this makes sense now [13:50] zyga: I can say that if snapd could somehow proxy it, it could probably be made auto-connectable (just need to make sure that a snap couldn't interfere with other snaps via the proxy [13:50] pedronis: because base declaration connections vs no connections at all makes the difference [13:50] jdstrand: right [13:50] thank you both [13:51] zyga: notice that if we made non-installable vs not auto-connectable, it would also solve the issue [13:51] given that it seems installing doesn't work anyway [13:51] hmm, what do you mean by non-installable? [13:52] say you annot install a snap with interface, unless the snap-declaration says so [13:52] ah, right [13:52] yes [13:52] though I'm not sure if we would dump the plug/slot and carry on as today or refuse outright [13:52] ? [13:53] it refuses outright [14:06] re [14:34] zyga: that said, writing up a proxy just because an analysis isn't done isn't great. someone could write up an in depth analysis and provide it to me, justifying auto-connecction (ie, that the code is safe from root attacks and the mechanism can't be used to influence other snaps) [14:35] * jdstrand -> errand [14:45] jdstrand: I won't write the proxy anytime soon, though the analysis seems like more complex (given the extent of systemd and the numerous versions we'd have to inspect) [14:45] Chipaca, pstolowski: gentle ping about https://github.com/snapcore/snapd/pull/5496 [14:45] PR #5496: interfaces,daemon: move JSON types to the daemon [14:45] zyga: reviewing is happening as we speak [14:46] zyga: or rather, it would be, but instead we're speaking [14:46] zyga: you got my +1 an hour ago [14:50] oh [14:50] drat, github stale page :) [14:51] zyga: what happened to the tests [14:51] I would love to use github on a text mode interface with mouse clicks support if it at least reliably worked [14:51] Chipaca: the tests for MarshalJSON, gone with the method, this is already tested by the api tests [14:52] specifically for the code that runs getInterfaces or getLegacyConnections (AFAIR, the typing names from memory) [14:52] the single call was inlined and that is tested as before, note that this patch didn't change any outcomes anywhere [14:52] just removed redundancy [15:04] Chipaca: thank you :) [15:04] PR snapd#5496 closed: interfaces,daemon: move JSON types to the daemon [15:04] zyga: that's not a thumbs up, that's a "if the nuclear explosion is bigger than my thumb i need to evacuate" [15:04] haha :) [15:04] aka the "nuclear painter's algoritm" [15:04] algoritm [15:04] man [15:04] algorithm [15:06] zyga: al juarismi [15:06] zyga: so we can get into a gif vs jif fight about that as well [15:06] giajef? [15:07] poles often enumerate the letters in abbreviations [15:07] so things are more like G-I-F than jif or gif [15:07] zyga: it depends on whether you can read it or not i guess; Spanish does that for jpg but not for gif [15:08] heta-i-efa [15:08] or something [15:08] efe [15:08] * zyga needs to run an errand [15:08] zyga: is it very obvious that we're waiting for spread here [15:09] * Chipaca looks into tea [15:18] zyga: niemeyer: what we should do i snapd is not try to start a service if it's type:notify and it's not connected [15:18] that's enough [15:18] in a world with warnings, we'd issue a warning at the same time [15:21] Chipaca, found anything interesting in your tea ? [15:21] ogra_: enlightenment [15:21] ! [15:22] ogra_: a very narrow enlightenment, but still [15:28] PR snapd#5490 closed: store: make snap blobs be 0600 === matteo| is now known as matteo === twobitsp1ite is now known as twobitsprite [15:44] niemeyer, zyga good news, the libudev internal data header for udev events is the same in 14.04 and 18.04 [15:46] * zyga is in Łukta now [15:49] zyga: is that pronounced "wukta"? [15:57] Chipaca: wookta [15:58] pstolowski: tks === pstolowski is now known as pstolowski|afk [17:13] PR snapcraft#2178 closed: lifecycle: pass commands to containerbuild, not steps [17:39] hi. if i try to register a name (pdftk) and it is coming up as "reserved". does that mean it has been reserved by someone else ? or possibly just that it is reserved due to there being a package name ? [17:43] or per https://forum.snapcraft.io/t/pending-review-on-flock-reserved-name/5442 maybe all binaries in ubuntu got reserved names automatically ? [18:09] smoser, indeed, just submit a claim for it [19:21] * zyga returns for some evening hacking :) [19:21] hey kyrofa [19:21] how have you been? [20:54] Hey zyga, not bad, how about you? [20:57] matiasb_: hi! with the full epoch syntax, is this true: read and write must be lists of positive integers, with no transition specified (ie, no '*') and '0' not allowed? [20:58] matiasb_: ie, this is ok epoch: {'read': [1, 2]} [20:58] matiasb_: but this is not: epoch: {'write': [0, 1]} [20:58] matiasb_: and neither is this: epoch: {'write': [1, 2*]} [20:59] matiasb_: from the examples, it seems clear [1, 2*] is not allowed, but nowhere does it say n>0, so not sure about [0, 1] [21:00] matiasb_: (n>0 is only specified with the simple syntax) [21:00] jdstrand, o/ right, I think 0 is allowed in the lists; the only case where 0 is not allowed is when using the * syntax, which is not allowed inside a list [21:01] ah, 0 is ok, just not with * [21:01] gotcha [21:01] exactly [21:01] matiasb_: thanks! [21:01] np! [22:19] PR snapd#5498 opened: snap: support hook environment [23:02] niemeyer, that's ^ for you [23:02] <3 [23:02] kyrofa: Thanks! [23:20] niemeyer, I just learned that the `command` of an app doesn't take the PATH in the `environment` key into account. Is that on purpose, or a bug? [23:21] It always just appends it to the snap mountdir [23:23] kyrofa: Yeah, it's on purpose.. what would be the use case for looking at an arbitrary path? [23:24] niemeyer, for binaries in bin, for example [23:24] Snapcraft supports this by placing wrappers in the root with the PATH defined, if snapd doesn't support it migration will be somewhat rough [23:24] kyrofa: Sure, but what's the use case for not defining that explicitly? [23:26] A nicety, I suppose. You can put a dir in the PATH and then not have to include the entire path in the command [23:26] The real issue is that people are doing it today, so getting rid of wrappers either means rewriting folks `command`, or adding support to snapd to check the PATH [23:27] kyrofa: They need to touch the command either way [23:27] Right? [23:27] Sorry, perhaps not the command.. the yaml I mean [23:27] Since we need to support the current files untouched [23:28] No, snapcraft does. Today it generates the wrapper and rewrites the command. Tomorrow it (ideally) stops generating the wrapper and only touches the `environment` of the command. But that can't happen if the command isn't found [23:28] The user should notice no difference [23:28] Again, ideally [23:29] kyrofa: Yeah.. it's a bit of a bummer.. [23:30] Snapcraft can rewrite the app to be absolute, but that kinda sucks [23:30] Err, relative to the root of the snap I mean [23:30] kyrofa: I guess snapcraft could resolve the PATH itself in those cases [23:30] Indeed [23:30] Still probably better than a wrapper, but I was hoping we wouldn't have to touch what the user provided anymore [23:30] kyrofa: and then ideally stop doing it when we detect a new format yaml [23:30] (with base, etc) [23:31] niemeyer, it also means that command chain items need paths to them. That doesn't seem overly verbose? [23:32] kyrofa: No, seems okay.. the PATH in general is something the user sets up for their environment.. for a snap, we are explicitly defining what the command means.. it shouldn't change if things fiddle with the path [23:33] Okay. Caught me by surprise, it may catch others [23:33] kyrofa: I'm surprised in the opposite direction :D [23:33] Heh [23:34] Snapcraft can help with the messaging [23:58] Hmm... that still won't solve all the cases though, e.g. where people actually use shell commands as a command [23:59] `command: echo "hello"` works today. It can never work in that world