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