| bananabot | hi, i'm trying to build a snap which includes a opencv program accessing an openni2 camera. wondering if someone has any hints on getting setting the permissions so the snap thing gets access to the hardware. is there any way to define this in snapcraft? I found this here https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ but it seems to be old documentation from when snap was called snappy. is there an equivalent to sudo | 00:27 |
|---|---|---|
| bananabot | snappy hw-assign webcam-demo.canonical /dev/video0 or better something to define udev rules for a snap? | 00:27 |
| ali1234 | there is a v4l plug/interface | 00:33 |
| ali1234 | you put plugs: [camera] in your snapcraft.yaml | 00:35 |
| ali1234 | then you connect it after installing it | 00:35 |
| ali1234 | something like sudo snap connect camera <snap> | 00:36 |
| bananabot | the problem is that camera doesn't show up as a /dev/video device. i think openni uses libusb to access the camera directly | 00:45 |
| ali1234 | then you are out of luck because there is no interface for that yet | 00:56 |
| ali1234 | bug 1598266 | 00:56 |
| mup | Bug #1598266: Cannot read/write to usb device [libusb][hidapi] <snapd-interfaces> <Snappy:Triaged> <https://launchpad.net/bugs/1598266> | 00:56 |
| mup | Bug #1607265 changed: Ubuntu-core downloads before querying store for missing snap <Snappy:Invalid> <https://launchpad.net/bugs/1607265> | 00:58 |
| bananabot | hm ok. that makes it pretty hard to use in robotic applications then. thanks for the link that explains at least that snappy hw-assign got removed. | 01:09 |
| ali1234 | you can always run in devmode until it gets implemented | 01:10 |
| ali1234 | i'm waiting on the same stuff | 01:10 |
| bananabot | is there anything else other than "confinement: devmode" i need change to get it working. i have udev rules to get the camera working in the normal system. | 01:15 |
| ali1234 | yes you have to sudo snap install --devmode | 01:22 |
| kalikiana | Note: sudo is only needed if you're not logged in ;-) | 01:41 |
| ali1234 | logged in to what? | 01:43 |
| bananabot | thanks, it seems to be working in devmode now | 02:41 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#1614 opened: Update documentation of /v2/system-information GET result <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/1614> | 03:28 |
| liuxg | has anyone tried the example mosqitto at https://github.com/snapcore/snapcraft/tree/master/demos/mosquitto. after I install the app, it seems there is no output. | 04:01 |
| qengho | liuxg: What output are you expecting? | 05:14 |
| liuxg | qengho, I did not see any output from running http://paste.ubuntu.com/21857552/. it could possible that the broker is not ready before the publish app is running | 05:15 |
| liuxg | qengho, I can see the output of the broker at http://paste.ubuntu.com/21857599/, it seems that it is running. the subscriber is not running as well. | 05:16 |
| qengho | liuxg: Ah. | 05:16 |
| liuxg | qengho, this is the output of the subscriber http://paste.ubuntu.com/21857694/. I think it is good to define the order of the running services in snapcraft since some of the apps depending on the some of of services. | 05:18 |
| qengho | liuxg: "not found" seems weird. | 05:22 |
| liuxg | qengho, i did not install the snapd from the proposed channel. I just install it from the normal channel.my snapd version is like http://paste.ubuntu.com/21858068/ | 05:24 |
| liuxg | qengho, I think it could be possible that broker should be running first, then subscriber/publisher | 05:25 |
| qengho | liuxg: I don't think you're seeing the systemctl message correctly "No such file or directory" is a big deal. | 05:27 |
| qengho | That's not an app failure. That's a systemd failure, right? | 05:27 |
| liuxg | qengho, I am not quite sure about that. it is weired to me. | 05:29 |
| qengho | liuxg: systemd could not reach down into the app to find out how and why it failed to find something. systeemd itself(!) couldnot find something. | 05:30 |
| liuxg | qengho, OK. does it mean that it is a bug somewhere? | 05:34 |
| qengho | liuxg: Yes. Probably snapcraft.yaml | 05:35 |
| liuxg | qengho, do you how I can install the latest snapd 2.11 version? | 05:35 |
| qengho | Though, I thoughsnapcraft catchesthis problem. | 05:36 |
| liuxg | qengho, maybe I file a bug against snapcraft? | 05:36 |
| qengho | [5~Sure. | 05:37 |
| liuxg | qengho, thanks. my colleague got the latest https://paste.ubuntu.com/21858180/ snapd version. How can I install it without installing the latest xenial-proposed? thanks | 05:37 |
| qengho | liuxg: you need the deb file. | 05:39 |
| liuxg | qengho, where can I find the debian file? | 05:39 |
| qengho | liuxg: And you need luck that it doesn't pull new deps. | 05:39 |
| qengho | How should I know? | 05:39 |
| liuxg | qengho, what is your version of it? | 05:40 |
| qengho | liuxg: If it's in Y, you can use "APT pinning" to upgrade only it. Google will help. | 05:40 |
| liuxg | qengho, ok. thanks | 05:41 |
| qengho | liuxg: I'm stale because I can't afford to break anything right now. | 05:41 |
| liuxg | qengho, yeah, I am using the stable as well :) | 05:42 |
| liuxg | qengho, I just reported a bug at https://bugs.launchpad.net/snapcraft/+bug/1608794 | 05:46 |
| mup | Bug #1608794: snapcraft mosquitto demo got "not-found (Reason: No such file or directory)" <Snapcraft:New> <https://launchpad.net/bugs/1608794> | 05:46 |
| qengho | liuxg: is your colleague with snapd YC? | 05:55 |
| liuxg | qengho, yes | 05:55 |
| mup | PR snapcraft#706 opened: Added "camera" plug into the example <Created by liu-xiao-guo> <https://github.com/snapcore/snapcraft/pull/706> | 06:01 |
| liuxg | qengho, sorry, I made mistake in running the mosquitto demo app. the "subscribe" and "publish" are both apps instead of daemon. they both need to run using commands. now, the demo works fine as expected :) | 06:24 |
| mup | Bug #1608807 opened: create-user fails to create user <create-user> <Snappy:New> <https://launchpad.net/bugs/1608807> | 06:30 |
| dholbach | hey hey | 06:35 |
| didrocks | good morning dholbach! | 06:36 |
| dholbach | hey didrocks | 06:36 |
| trijntje | when I open a file dialog from a snapped program it starts in $USER/snap/snapname/x1 | 06:37 |
| trijntje | Is there a way to have it start in $HOME so the user doesnt have to navigate there each time the app is used? | 06:38 |
| didrocks | trijntje: there is no env variable AFAIK pointing to user's $HOME, $HOME in the snap is in $USER/snap/snapname/<version>/ as you told | 06:38 |
| didrocks | maybe a discussion to trigger on the ML? | 06:38 |
| didrocks | (ask niemeyer about his thoughts on this) | 06:39 |
| trijntje | didrocks: Ok thanks, I thought so. Maybe add a soft link to home in the snap folder itself? You can set HOME for most programs, but then it will try to put configs and data in there which is not allowed | 06:42 |
| didrocks | trijntje: that's exactly the issue, worth raising it IMHO :) | 06:45 |
| trijntje | didrocks: I'll put it on the ML later today, I'll just wait a bit for niemeyer to respond | 06:48 |
| didrocks | yeah, let's see :) | 06:49 |
| mup | PR snapd#1614 closed: Update documentation of GET /v2/system-information result <Created by robert-ancell> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/1614> | 07:08 |
| === hikiko is now known as hikiko|afk | ||
| mwhudson | ogra_: good morning | 07:55 |
| mwhudson | ogra_: we (cyphermox and i) have been having some fun with ubuntu-core images that don't dhcp | 07:55 |
| mwhudson | ogra_: do you know anything about any problems like this? | 07:55 |
| mwhudson | (sometimes they do dhcp... just not very often) | 07:56 |
| kalikiana | trijntje: You can do HOME=/home/$USER so long as you tell the app not to use it for . files. That's what I do in neovim. | 08:13 |
| kalikiana | XDG_ variables point inside the snap folders | 08:13 |
| qengho | That is a big assumption about home dir. Be careful. Convention is not law. | 08:15 |
| kalikiana | Law very often is based on convention ;-) | 08:16 |
| kalikiana | Alternate suggestions welcome, I'm really just tweaking things as I go along as many things aren't established | 08:21 |
| === JanC is now known as Guest77763 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapd#1615 opened: overlord/snapstate, daemon: support for multi-snap refresh <Created by chipaca> <https://github.com/snapcore/snapd/pull/1615> | 09:44 |
| ogra_ | mwhudson, i see the firstboot setup stuff panic in syslog, and i noticed that i sometimes dont end up with a /etc/network/interfaces.d/eth0 ... which i think the firstboot job sets up | 09:48 |
| ogra_ | so yeah, that usually results in not getting dhcp requests | 09:48 |
| mwhudson | ogra_: hm, what does that panic look like? | 09:52 |
| mwhudson | Aug 2 02:55:41 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE | 09:54 |
| mwhudson | Aug 2 02:55:41 localhost systemd[1]: Failed to start Run snappy firstboot setup. | 09:54 |
| mwhudson | hm informative | 09:54 |
| mwhudson | oh is error: cannot read seed yaml: /var/lib/snapd/seed/seed.yaml related? | 09:55 |
| mwhudson | hmm maybe | 09:58 |
| mup | PR snapd#1616 opened: tests, integration-tests: implement the cups-control manual test as a spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1616> | 09:58 |
| mwhudson | ogra_: what is supposed to create seed.yaml? | 09:58 |
| ogra_ | mwhudson, ubuntu-devcie-flash i think | 10:01 |
| ogra_ | (or in the new worldorder perhaps "snap prepare-image" | 10:02 |
| ogra_ | ) | 10:02 |
| mwhudson | ogra_: ah so maybe my bootleg ubuntu-device-flash is too old? | 10:02 |
| ogra_ | mwhudson, is that syslog or journald ? i thin journald doesnt show the panic | 10:02 |
| mwhudson | ogra_: syslog | 10:02 |
| ogra_ | k | 10:02 |
| mwhudson | i don't see an actual panic though | 10:02 |
| mwhudson | in my case :-) | 10:02 |
| ogra_ | and is that real HW ir kvm ? | 10:02 |
| ogra_ | *or | 10:02 |
| mwhudson | kvm | 10:02 |
| ogra_ | interesting ... i see the panic all the time | 10:03 |
| mwhudson | i come from the server space, none of these toys :-) | 10:03 |
| ogra_ | lol | 10:03 |
| ogra_ | http://people.canonical.com/~mvo/all-snaps/16/ ... thats the latest udf | 10:03 |
| ogra_ | it seems to have issues when you use any local snaps though ... works fine with snaps from the store | 10:04 |
| * mwhudson bangs head on desk | 10:04 | |
| ogra_ | the seed.yaml actually describes the preinstalled and existing snaps ... when you boot like that, does snap list show you anything ? | 10:05 |
| mwhudson | no | 10:06 |
| ogra_ | right | 10:06 |
| mwhudson | i have noticed the oddness where on a system like this when you run snap install hello-world, the first thing it does is install the ubuntu-core snap | 10:06 |
| ogra_ | yeah | 10:06 |
| mwhudson | which given what you said is not surprising | 10:07 |
| ogra_ | well, the feature comes from the desktop... | 10:07 |
| ogra_ | not sure if it should even kick in here | 10:07 |
| ogra_ | you dont have a kernel or gadget snap either ... | 10:07 |
| ogra_ | (i mean, you have thgem, but snapd doesnt know) | 10:07 |
| mwhudson | hmmm | 10:11 |
| mwhudson | this is all interesting but seems unrelated to networking, on looking at the code | 10:11 |
| mwhudson | ogra_: what panic do you see, do you have one lying around to pastebin? | 10:12 |
| ppisati_ | is there a way to patch an app on-the-fly when snappying it? | 10:12 |
| ogra_ | mwhudson, http://paste.ubuntu.com/21754413/ | 10:15 |
| mwhudson | ogra_: wee | 10:16 |
| ogra_ | and this is the seed.yaml i end up when sideloading ubuntu-core http://paste.ubuntu.com/21762356/ | 10:16 |
| ogra_ | not sure if the two are actually related though | 10:16 |
| mwhudson | heh so i make an image to test this and of course it dhcp's this time | 10:21 |
| ogra_ | heh | 10:21 |
| kalikiana | ppisati_: Not formally, no. You'd have to add your own build scripts. | 10:23 |
| kalikiana | Unless you count environment variables. | 10:23 |
| mwhudson | ogra_: so yeah, on an image that got networking there is /e/n/i.d/eth0, on one that did not there is not | 10:27 |
| ogra_ | right | 10:27 |
| ogra_ | Chipaca, do you happen to know what is supposed to create /e/n/i.d/eth0 nowadays ? | 10:28 |
| === hikiko|afk is now known as hikiko | ||
| ogra_ | (i know we forcefully disable cloud-init network setup currently because snapd used to be supposed to create it, perhaps thats not the case anymore ? ) | 10:29 |
| mwhudson | it sure looks like snapd is trying to create it | 10:29 |
| ogra_ | k | 10:29 |
| ogra_ | i wonder if it is supposed to change though | 10:29 |
| Chipaca | ogra_: `snap firstboot` creates it | 10:29 |
| mwhudson | could this be a race with whatever populates /sys/class/net/eth* ? | 10:30 |
| ogra_ | ok | 10:30 |
| ogra_ | mwhudson, hmm, that would be the NIC module | 10:30 |
| mwhudson | looks from the code that the only reason EnableFirstEther would return without writing a file is no /sys/class/net/ thingies | 10:30 |
| ogra_ | probably firstboot should wait til module-init-tools (or however systemd calls it) has run | 10:31 |
| Chipaca | ogra_: mwhudson: snapd.firstboot.service is run before network-pre.target which might be bad | 10:31 |
| Chipaca | in that the whole early boot ordering is a nightmare | 10:32 |
| Chipaca | early for snappy that is | 10:32 |
| Chipaca | :-) | 10:32 |
| ppisati_ | kalikiana: what you mean "Unless you count environment variables"? | 10:32 |
| ogra_ | well, snappy is also special in the initrd setup ... we dont ship each and every NIC module in the world like a classic install would | 10:33 |
| ogra_ | so module loading actually only happens after the rootfs is fully set up | 10:33 |
| ogra_ | which is a lot later than in classic | 10:33 |
| mwhudson | Chipaca: should i file a bug at launchpad.net/snappy saying 'firstboot does not always create populate /e/n/i.d' or something like htat? | 10:33 |
| Chipaca | ogra_: mwhudson: could you post the output of `systemd-analyze --system plot` somewhere? | 10:33 |
| Chipaca | I'm assuming this is in an all-snaps system | 10:34 |
| mwhudson | yes | 10:34 |
| Chipaca | good :-) | 10:34 |
| kalikiana | ppisati_: You can supply a wrapper that tweaks the environment as needed, maybe affects modules loaded by the binary, or even edits use-writable files during launch. | 10:34 |
| mwhudson | Chipaca: can you remind me how to run kvm so that i get the tty on stdin/stdout, not in a window? | 10:34 |
| ppisati_ | kalikiana: nope, a wrapper in this case won't cut it | 10:34 |
| mwhudson | Chipaca: also a non-custom ubuntu-core snap would make this easier... | 10:34 |
| Chipaca | mwhudson: -nographic ? | 10:35 |
| kalikiana | ppisati_: Personally I would aim for solving everything through config values - if the snapped binary has no option to let you snap it properly, it can probably be added | 10:35 |
| mwhudson | oh wait, i have a sufficiently un-custom snap i think | 10:35 |
| flixr | hi guys, I'm wondering what happend to the support of assiging udev rules to allow a snap to access certain hw devices as described in https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ | 10:35 |
| flixr | has this support gone away with 16.04 and snapcraft? | 10:36 |
| flixr | how would I allow my snap to access multiple cameras and other hw devices like sensors connected via iio? | 10:36 |
| mwhudson | Chipaca: oh heh, right | 10:36 |
| Chipaca | mwhudson: if this is to get the output of analyze, note it's an svg | 10:37 |
| mwhudson | Chipaca: oh | 10:37 |
| kalikiana | ppisati_: In the short term you can of course simply fork whatever it is and patch that before you consider upstreaming (as I did because I required new options in neovim's build) | 10:37 |
| ppisati_ | kalikiana: yeah, i see what you mean | 10:37 |
| mwhudson | Chipaca: i guess i can scp after running dhclient manually... | 10:37 |
| Chipaca | :-) | 10:38 |
| Chipaca | thank you | 10:38 |
| mwhudson | of course now my images are consistently managing to dhcp by themselves | 10:38 |
| ppisati_ | kalikiana: i'm actually snaping two apps: midnight command (so i can probably tweak some stuff with ./configure --... there) and a second unrelated python scrpt based app (that requires the patching too) | 10:38 |
| ppisati_ | let's see | 10:38 |
| Chipaca | mwhudson: oh, wait, this is a "sometimes yes sometimes no" problem? have you checked journalctl for circular deps? | 10:39 |
| Chipaca | otherwise yeah timing probably | 10:39 |
| Chipaca | meaning the deps are wrong one way or another | 10:39 |
| ogra_ | on my working system the firstboot job runs ~2sec before network-pre | 10:39 |
| mwhudson | Chipaca: i did look in journalctl but not specifically for that, how does it show up? | 10:40 |
| Chipaca | mwhudson: in angry red (if your term supports it), search for "cyclic" | 10:40 |
| mwhudson | Chipaca: nothing like that | 10:41 |
| mwhudson | i've just had a terrible thought | 10:41 |
| mwhudson | which is that i didn't see this with -nographic | 10:41 |
| mwhudson | a difference with nographic is that you don't see grub and so have to wait 2 seconds for the default to be taken | 10:42 |
| mwhudson | whereas with kvm in a window i can be impatient and hit return early | 10:42 |
| trijntje | kalikiana: The app I'm snapping looks for .dot files and folders in$HOME, so I have to set $HOME to the snapdir. Ideally, we would have something for every snap that takes care of this, so we don't have to modify every app ;) | 10:43 |
| mwhudson | Chipaca: http://people.canonical.com/~mwh/plot.svg | 10:46 |
| ogra_ | wow | 10:48 |
| ogra_ | your boot takes awfully long | 10:48 |
| Chipaca | mwhudson: and that time it worked? | 10:49 |
| Chipaca | mwhudson: (i'm assuming you remove the stampfile or start from pristine every time) | 10:49 |
| ogra_ | nearly 5sec longer than mine here | 10:49 |
| Chipaca | actually if the stampfile is there systemd would not even run it, so yeh | 10:50 |
| mwhudson | Chipaca: no that was a failed boot | 10:50 |
| mwhudson | Chipaca: i've been re-running udf between boots | 10:50 |
| Chipaca | oooh, what is sys-subsystem-net-devices-eth0.device | 10:50 |
| mwhudson | well not a failed boot but a failed to network boot | 10:50 |
| Chipaca | mwhudson: can you edit the firstboot service file? | 10:52 |
| Chipaca | mwhudson: by copying it to /etc/systemd/system for example | 10:52 |
| Chipaca | mwhudson: and change it to be After: network-pre.target Before: snapd.service networking.service | 10:53 |
| mup | PR snapcraft#702 closed: Use the new snapcraft.io mailing list as contact information <Created by seb128> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/702> | 10:53 |
| mwhudson | Chipaca: it's nearly 2300 here so... | 10:53 |
| * ogra_ notes he definitely does not have sys-subsystem-net-devices-eth0.device on a successfully booted setup | 10:53 | |
| trijntje | Can anyone build the plank snap from the snappy playpen? It asks me for my git.launchpad.net credentials but fails anyway. I want to take a look at how the mime types are defined in the final snap https://github.com/ubuntu/snappy-playpen/tree/53d3668ab6dc1a5c711f9c5e2deddd6abd59482b/plank | 10:53 |
| ogra_ | oh | 10:53 |
| ogra_ | wait, i do | 10:53 |
| Chipaca | mwhudson: aw | 10:53 |
| Chipaca | mwhudson: get out of here then :-) | 10:53 |
| mwhudson | Chipaca: let's give it one shot | 10:53 |
| Chipaca | hoping that one's not cyclic :-/ | 10:55 |
| mwhudson | Chipaca: seems to have worked! | 10:58 |
| mwhudson | of course it sometimes worked anyway, but eh | 10:58 |
| Chipaca | mwhudson: go to bed, more tomorrow | 10:59 |
| mwhudson | Chipaca: feel free to talk to cyphermox about this when he wakes up :-) | 10:59 |
| Chipaca | and if there isn't a tomorrow, not going to bed won't fix it either | 10:59 |
| mwhudson | (if you are still around then) | 10:59 |
| mwhudson | heh | 10:59 |
| mwhudson | i like your plan though | 10:59 |
| * mwhudson zzz | 10:59 | |
| trijntje | I'm reading the terms on the ubuntu snap store, and it says "App(s): one or more applications or content items owned by you which you submit through the Developer Site and any associated screen shots and marketing materials provided by you. " | 11:19 |
| trijntje | what about snapping software that you are not the owner of, like most open source projects? | 11:20 |
| mwhudson | Chipaca: final thought, this will all change when netplan takes over the world i guess! | 11:21 |
| mwhudson | Chipaca: i need to talk to someone about that, definitely not right now though | 11:21 |
| Chipaca | mwhudson: i can't hear you because you are asleep | 11:21 |
| ogra_ | mwhudson, depends if pitti plans to backport everything to 16.04 :) | 11:23 |
| ogra_ | (and i mean everything ... ) | 11:23 |
| kalikiana | trijntje: Teach the app XDG_ variables. Other than that what else would you do? Bind-mount . files to fool the snapped executable? | 11:56 |
| trijntje | kalikiana: no, the app respects XDG_ variables, but then we tell it that its home is in $USER/snap/mysnap/x1. So when we then go to open a file, the file dialog starts there, instead of in /home/$USER | 11:58 |
| kalikiana | trijntje: Which is why I would map HOME=/home/$USER | 12:11 |
| stokachu | so how does one include config files into our snap that's not in the same directory as our snapcraft file? | 12:27 |
| kalikiana | stokachu: Where do those files come from? A subfolder? Or a separate repository? | 12:28 |
| stokachu | kalikiana: https://github.com/conjure-up/conjure-up is my current directory structure, snapcraft/snapcraft.yaml holds that metadata and etc/conjure-up.conf holds the config | 12:29 |
| stokachu | i want to make sure etc/conjure-up.conf ends up in my snap user data directory | 12:29 |
| kalikiana | stokachu: Afair it must be in the read-only bit first, then the wrapper could determine if it exists and create/copy it on startup | 12:31 |
| kalikiana | You could use the copy plugin to make sure it's in there | 12:31 |
| stokachu | i tried the copy plugin but i don't know where to copy the config from while int he build | 12:32 |
| stokachu | i have to do weird stuff with the requirements.txt file, requirements: parts/conjure/src/requirements.txt | 12:33 |
| stokachu | i dont understand why it doesn't just pick it up during the build | 12:33 |
| kalikiana | stokachu: Copy is relative to the snapcraft.yaml, so files: etc/conjure-up.conf: etc/conjure-up.conf should work | 12:34 |
| stokachu | kalikiana: snapcraft/snapcraft.yaml is the location | 12:34 |
| stokachu | and doing ../etc/conjure-up.conf: etc/conjure-up.conf doesn't work | 12:34 |
| kalikiana | Oh, I see | 12:35 |
| stokachu | i could just move the snapcraft.yaml but i want to understand how to grab those files regardless of location of snapcraft.yaml | 12:35 |
| stokachu | like what if snapcraft.yaml was a different repo from the source | 12:35 |
| kalikiana | stokachu: I think in theory you could use copy with the same git repo and get it from there, although I've not tried it | 12:36 |
| flixr | is there any replacement for giving access to devices in snappy 16.04 (was possible via assign: rules: -kernel: foo in 15.04), is there anything planned? | 12:36 |
| flixr | or why was it removed in the first place? | 12:36 |
| kalikiana | stokachu: ie. if you specify source, it won't look at the snapcradft folder | 12:36 |
| flixr | kind of makes it not usable for IoT devices anymore | 12:36 |
| stokachu | kalikiana: ok ill play with that a bit | 12:37 |
| flixr | zyga, r u there? | 12:39 |
| stokachu | can you specify multiple plugins for a single part? | 12:39 |
| Mirv | is there something like source-sha256: or how would I make a validation of the upstream source fetched? | 12:41 |
| Mirv | if source is upstream tarball, or do I need to just download the source locally and validate manually? | 12:42 |
| kalikiana | stokachu: No. But snapcraft should be smart enough to re-use it and not re-download. | 12:45 |
| stokachu | kalikiana: it rechecks out the git source it looks like | 12:45 |
| kalikiana | stokachu: Hrm. I'd say that's a bug. | 12:46 |
| stokachu | verifying now with a clean install | 12:46 |
| kalikiana | There's one bug about deb packages being pulled in by multiple parts so there might be other flaws in the caching. | 12:47 |
| stokachu | sergiusens: ^ do you know if this is the case | 12:47 |
| stokachu | hmm, the snap shows /etc/conjure-up.conf but conjure-up.shell doesn't see that file at all | 12:51 |
| ali1234 | by default snapd doesnt set up XDG_DATA_DIRS | 12:52 |
| ali1234 | so "teaching" the app about them doesn't actually help very much | 12:52 |
| stokachu | so in my snapcraft.yaml where do i copy those files too? | 12:52 |
| stokachu | right now it's etc/conjure-up.conf: etc/conjure-up.conf | 12:53 |
| stokachu | this is my current yaml https://gist.github.com/battlemidget/1bb079992272b96e85ab2ac135a0d541 | 12:54 |
| ali1234 | that seems reasonable? | 12:54 |
| stokachu | im guessing it's not reasonable? since it doesn't work | 12:55 |
| ali1234 | you need to make the app look for $SNAP/etc/conjure-up.conf | 12:55 |
| ali1234 | by changing the source code if necessary | 12:55 |
| stokachu | so we have to basically code our applications to be snap specific? | 12:56 |
| ali1234 | no | 12:56 |
| ali1234 | you just have to code them with a command line option that allos you to specify the location of the config file | 12:56 |
| ali1234 | all good software already does that since years... | 12:57 |
| ahoneybun | cwayne: I'm using your snapcraft.yaml to try to build atom 1.9 that came out today | 12:57 |
| stokachu | same with directory structure since years... | 12:57 |
| ali1234 | yes, XDG_DATA_DIRS has been around for a long time | 12:58 |
| kalikiana | stokachu: So what doesn't work? Is the file in the snap? | 12:58 |
| stokachu | the file is in the snap | 12:58 |
| stokachu | but not when i run conjure-up.shell | 12:58 |
| stokachu | unsquashfs list the file | 12:58 |
| cwayne | ahoneybun: are you hitting any issues? i know didrocks cleaned mine up quite a bit | 12:59 |
| ahoneybun | not sure yet still building | 12:59 |
| ahoneybun | I used your snap to make mine lol | 12:59 |
| ahoneybun | or try to | 13:00 |
| ali1234 | the problem is this https://github.com/conjure-up/conjure-up/blob/master/conjureup/app.py#L185 | 13:00 |
| stokachu | so if conjure-up.shell shows files in /etc, why doesn't my file show up there even though is specifically told it to copy there | 13:01 |
| ali1234 | because that is not what copy plugin does | 13:02 |
| ali1234 | copy plugin copies a file in to your snap | 13:02 |
| didrocks | cwayne: IIRC, yours should work without devmode | 13:02 |
| kalikiana | stokachu: If they are in the snap, where are they? .shell should see anything that is in there once it's installed | 13:02 |
| stokachu | ali1234: if it's in the snap why isn't it in the shell? | 13:02 |
| ali1234 | what do you mean "in the shell"? | 13:03 |
| stokachu | https://www.irccloud.com/pastebin/V9HfBlV2/ | 13:03 |
| stokachu | kalikiana: ^ | 13:03 |
| stokachu | ali1234: conjure-up.shell | 13:03 |
| ali1234 | because snaps arent uncompressed over /? | 13:03 |
| stokachu | ali1234: are you asking me if they are? | 13:04 |
| kalikiana | stokachu: As the code looks for ../etc/conjure-up.conf maybe you need a subfolder in there | 13:04 |
| ali1234 | no | 13:04 |
| ali1234 | your code looks for /etc/conjure-up.conf and ../etc/conjuse-up.conf. the file will actually be at /snap/conjure-up/xn/etc/conjuse-up.conf | 13:05 |
| cwayne | didrocks: nope, cause it tries to call nohup | 13:05 |
| cwayne | for some reason | 13:05 |
| ahoneybun | mm an error | 13:06 |
| stokachu | ali1234: so that goes back to using $SNAP to figure out where the file is | 13:06 |
| ali1234 | stokachu: yes, exactly | 13:07 |
| ahoneybun | cwayne: http://pastebin.ubuntu.com/21888796/ | 13:07 |
| stokachu | ali1234: even if i give it a cli option to poitn to the config file | 13:07 |
| ahoneybun | I used the one from playpen | 13:07 |
| stokachu | it still requires $SNAP | 13:07 |
| ali1234 | stokachu: then you use the cli option from within your wrapper script | 13:07 |
| stokachu | and where do i edit that file? | 13:08 |
| stokachu | in the apps section? | 13:08 |
| ali1234 | yes | 13:08 |
| stokachu | command: conjure-up <what goes here> | 13:08 |
| ali1234 | command: mywrapper conjure-up | 13:08 |
| stokachu | just the relative path to the config? | 13:08 |
| stokachu | oh i see | 13:08 |
| stokachu | i have to create another file to do this | 13:08 |
| ali1234 | yes | 13:08 |
| ali1234 | see for example the desktop-launcher | 13:09 |
| stokachu | https://github.com/snapcore/snapcraft/tree/master/demos? | 13:09 |
| ali1234 | you could also do it by just supplying arguments | 13:09 |
| stokachu | where is that example | 13:09 |
| ali1234 | https://github.com/ubuntu/snapcraft-desktop-helpers | 13:09 |
| ali1234 | so you could probably just do command: conjure-up -c <path-to-config> | 13:10 |
| ali1234 | if conjure-up accepted a -c option | 13:10 |
| stokachu | ali1234: can i do conjure-up -c $SNAP/etc/conjure-up.conf | 13:10 |
| ali1234 | yes | 13:10 |
| stokachu | i didnt realize $SNAP was translated in the snapcraft.yaml file | 13:11 |
| stokachu | or do i still need the wrapper? | 13:11 |
| ali1234 | $SNAP isn't know until install time | 13:11 |
| stokachu | ok so still need the wrapper | 13:11 |
| ali1234 | no, you don't | 13:11 |
| ali1234 | maybe not for this | 13:11 |
| ali1234 | but you might need it for something else | 13:11 |
| ali1234 | depends what problem you run into next? | 13:11 |
| stokachu | how do i know where the conjure-up.conf file is located if i just wanted to do it in the snapcraft.yaml? | 13:12 |
| ali1234 | you write $SNAP | 13:12 |
| ali1234 | snapcraft.yaml copies it into the shell script it generates automatically | 13:12 |
| balloons | hey kyrofa, do you expect your godeps PR to land soon? https://github.com/snapcore/snapcraft/pull/691 | 13:12 |
| mup | PR snapcraft#691: Add godeps plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/691> | 13:12 |
| ali1234 | look at /snap/bin/conjure-up | 13:12 |
| ali1234 | it is a shell script | 13:12 |
| stokachu | i see | 13:12 |
| stokachu | ali1234: https://gist.github.com/battlemidget/1bb079992272b96e85ab2ac135a0d541#file-snapcraft-yaml-L12 can i do something liek this? | 13:13 |
| ali1234 | when you run a snap it is shell scripts inside shell scripts | 13:13 |
| ali1234 | yes if you add that command lne option to conjure-up | 13:13 |
| stokachu | yea i will | 13:13 |
| stokachu | just curious on that part with snapcraft | 13:13 |
| stokachu | ali1234: kalikiana: this clears up a lot, thanks for putting up with my questions | 13:14 |
| ali1234 | you can also do it with a wrapper script, which is neater if you need a lot of arguments and environment variables | 13:14 |
| ali1234 | it is just up to your personal preference | 13:14 |
| stokachu | ali1234: yea I will probably end up doing that | 13:14 |
| cwayne | ahoneybun: that looks like an issue within atom itself somehow | 13:17 |
| cwayne | as its failing to run its own bootstrap script.. | 13:17 |
| === mhall119_ is now known as mhall119 | ||
| mhall119 | sergiusens: kyrofa: can one of you let me know when my patch is in a snapcraft release? I'd like to propose my packaging configs to upstream Arduino, but can't until it "just works" | 13:40 |
| mup | PR snapd#1511 closed: overlord: actually run hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1511> | 13:42 |
| didrocks | cwayne: interesting, I was sure it was it was working, did you talk with the security team about ideas to circumvent that? | 13:45 |
| cwayne | nope | 13:45 |
| didrocks | cwayne: another way, we can set -f by default, this shouldn't call nohup? | 13:45 |
| cwayne | didrocks: i think i tired that, but didnt change anything | 13:45 |
| didrocks | interesting, I was sure to have run atom unconfined from the latest playpen | 13:48 |
| didrocks | but I might be wrong | 13:48 |
| didrocks | or have bad memory :p | 13:48 |
| didrocks | but otherwise, open a bug and try to talk about it on the ML with the security guys for ideas | 13:48 |
| didrocks | (but the answer might just be "fix upstream" :p | 13:48 |
| ali1234 | didrocks: is there some better way to achieve this, without putting a wrapper in a wrapper? http://paste.ubuntu.com/21893086/ | 13:54 |
| didrocks | ali1234: for now, this is the best you can do. I wonder strongly if the desktop-launch wrapper can't source some directories for this | 13:55 |
| didrocks | (that would avoid chaining wrappers) | 13:55 |
| ali1234 | i was thinking more like... make it pull stuff from the yaml | 13:55 |
| didrocks | but yeah, no other way right now, sorry | 13:55 |
| didrocks | ali1234: easy for simple case like FOO=bar | 13:55 |
| didrocks | a little bit less for FOO=$FOO:bar | 13:56 |
| didrocks | because in your specific case, you want this to apply after desktop-launch is running | 13:56 |
| didrocks | just before its exec= | 13:56 |
| didrocks | (you may dep on some variables set by the wrapper) | 13:56 |
| ali1234 | maybe | 13:56 |
| ali1234 | however you could just insert things from the yaml verbatim into the launcher | 13:57 |
| didrocks | yeah, for env variables, this is planned | 13:57 |
| ali1234 | cool :) | 13:57 |
| didrocks | I don't know where sergiusens is on his long priority list :) | 13:57 |
| didrocks | but this is definitively part of it | 13:57 |
| ali1234 | in this specific case i should probably just build everything with /usr prefix | 13:58 |
| ali1234 | i'm not really sure about the implications of doing that though | 13:59 |
| didrocks | you will get your result in $SNAP/usr/… | 13:59 |
| ali1234 | that's what i want | 13:59 |
| ali1234 | but is there any risk that absolute paths could creep in? | 14:00 |
| ali1234 | should i use /usr or usr/? | 14:00 |
| ali1234 | or just "usr"? | 14:00 |
| didrocks | depends on the build system :) | 14:01 |
| ali1234 | autotools | 14:01 |
| didrocks | if they generate a config.h file | 14:01 |
| didrocks | (yeah, but what modules?) | 14:01 |
| didrocks | for instance, some are doing: | 14:01 |
| ali1234 | no idea | 14:01 |
| didrocks | DATADIR=$PREFIX/share | 14:01 |
| didrocks | and so you will get some tools fetching sources from a hardcoded /usr/share | 14:02 |
| didrocks | (and so, not being relocatable) | 14:02 |
| ali1234 | yeah that's the problem that i have | 14:02 |
| ali1234 | except that if you don't supply a prefix then the plugin uses "" | 14:02 |
| ali1234 | and it looks in /share | 14:02 |
| ali1234 | so maybe i should just use "usr" AND ALL MY PROBLEMS GO AWAY LIKE MAGIC | 14:02 |
| ali1234 | oops caps :) | 14:02 |
| didrocks | yeah, setting the prefix wouldn't help in that case IMHO :) | 14:02 |
| didrocks | is there any env var to override this? | 14:03 |
| ali1234 | yes, XDG_DATA_DIRS | 14:03 |
| mup | PR snapd#1617 opened: many: move to purely hash based key lookup and to new key/signature format (v1) <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/1617> | 14:03 |
| ali1234 | hence my wrapper script | 14:03 |
| ali1234 | but it looks in $XDG_DATA_DIRS/share and not $XDG_DATA_DIRS/usr/share | 14:03 |
| ali1234 | unless you build it with prefix="/usr" (or some variation) | 14:03 |
| kalikiana | ali1234: didrocks Environment variables is bug 1583259 | 14:04 |
| mup | Bug #1583259: Snappy needs to influence environment variables in applications <snap-desktop-issue> <Canonical Click Reviewers tools:Fix Committed by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <https://launchpad.net/bugs/1583259> | 14:04 |
| ali1234 | thanks | 14:04 |
| didrocks | ali1234: yeah, so "fixable" at least :) | 14:04 |
| didrocks | kalikiana: thanks for the ref! | 14:04 |
| ali1234 | yeah but fixable in multiple ways, i don't know which way is the right one :) | 14:04 |
| didrocks | env var for now I would say | 14:05 |
| ali1234 | so double wrapper... okay | 14:05 |
| didrocks | yeah, we'll get better at it, but it's an incremental process :) | 14:05 |
| ali1234 | so it would be nice if you could achieve what the desktop-launcher does, with only the correct lines in the yaml | 14:05 |
| ali1234 | or at least most of it | 14:06 |
| jdstrand | cwayne: please file a bug for nohup and paste the security denials (grep audit /var/log/syslog) for that app | 14:06 |
| jdstrand | cwayne: add the snapd-interface tag | 14:06 |
| didrocks | jdstrand: I don't think it's something you would really want to allow right? | 14:07 |
| didrocks | ali1234: yeah, it's the long term goal :) | 14:07 |
| didrocks | nohup wouldn't give you long running process that you wouldn't like? | 14:07 |
| ali1234 | didrocks: also it would be nice if this was one of the standard built-in vars: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L13 | 14:08 |
| ali1234 | maybe $SNAP-LIBDIR or something | 14:08 |
| Odd_Bloke | Hello all, I'm getting 'This application failed to start because it could not find or load the Qt platform plugin "xcb".' when building a PyQT5 application; I'm stage-package'ing python3-pyqt5 and libx11-xcb1. Am I missing something else I need to add? | 14:09 |
| jdstrand | didrocks: well, we already allow background processes in the form of daemons. but, I think the denial is only for the nohup command. and app could ship that itself or trap the signal itself so I don't really see the point in blocking it | 14:09 |
| Odd_Bloke | (I'm getting this even in devmode) | 14:09 |
| jdstrand | we'll see what the denial is | 14:09 |
| didrocks | ali1234: oh don't tell me, it's on my list since a very long time :) | 14:09 |
| didrocks | jdstrand: oh, good point | 14:11 |
| qengho | Odd_Bloke: that is the most common complaint I see. :( | 14:35 |
| kyrofa | balloons, I expect the godeps plugin to land in master tomorrow-ish | 15:02 |
| kyrofa | mhall119, will do! I've been in that boat before :) | 15:03 |
| kyrofa | mhall119, though you can keep an eye on your bug as well-- it'll be updated as it goes through the SRU process | 15:03 |
| renatu | hey guys how I can force snapcraft to re-download the deps after update the stage-packages list. | 15:05 |
| SamYaple | can I get some help with this PR? I can't actually access the autopkgtest to see why it failed. https://github.com/snapcore/snapcraft/pull/663 | 15:07 |
| mup | PR snapcraft#663: Improve python2 test coverage <Created by SamYaple> <https://github.com/snapcore/snapcraft/pull/663> | 15:07 |
| SamYaple | it was passing before I rebased it since it had gone a while without review | 15:08 |
| kyrofa | Odd_Bloke, you're missing the stage-package that includes those plugins (and potentially missing the environment variable to pick them up in the snap) | 15:15 |
| kyrofa | Odd_Bloke, is this qt5? | 15:15 |
| Spads | https://github.com/scummvm/scummvm/pull/800 <-- zyga | 15:19 |
| mup | PR scummvm/scummvm#800: Add snapcraft.yaml so you can `snapcraft build` <Created by spads-spads> <https://github.com/scummvm/scummvm/pull/800> | 15:19 |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | Spads \o/ | 15:46 |
| sergiusens | hello everyone | 15:47 |
| seb128 | hey sergiusens | 15:48 |
| stokachu | ugh, sudo snap install conjure_up_2.0.0.7_amd64.snap --devmode works, sudo snap install conjure-up --devmode does not | 15:51 |
| stokachu | i dont understand why | 15:52 |
| seb128 | stokachu, does conjure-up exist? | 15:52 |
| stokachu | yea | 15:52 |
| seb128 | is that in the store? | 15:53 |
| seb128 | or a local snap? | 15:53 |
| stokachu | both | 15:53 |
| seb128 | what error do you get if you try to install the .snap? | 15:53 |
| seb128 | can you pastebin the cmd and output? | 15:53 |
| stokachu | that way works, it's installing from the store that fails | 15:53 |
| stokachu | it just hangs when i run `conjure-up -h` | 15:53 |
| stokachu | https://www.irccloud.com/pastebin/ZkY2QFmd/ | 15:54 |
| sergiusens | stokachu did you "release" your latest upload? | 15:54 |
| stokachu | just tried this ^ | 15:54 |
| stokachu | sergiusens: yep | 15:54 |
| stokachu | https://myapps.developer.ubuntu.com/dev/click-apps/5479/rev/9/ | 15:54 |
| sergiusens | so hashes match | 15:54 |
| stokachu | conjure-up 2.0.0.7 9 adam-stokes devmode | 15:55 |
| stokachu | from snap list | 15:55 |
| sergiusens | what's the sha512 of conjure_up_2.0.0.7_amd64.snap ? | 15:55 |
| stokachu | 9c43bfeb723da09b1e56adb8b42cc41977a937153a34a24ea2211ffb250c71f882b4e16c00f79ad01686dd86bec3176ba129acca2dc2025f33bfdea464f89377 conjure-up_2.0.0.7_amd64.snap | 15:55 |
| stokachu | https://github.com/conjure-up/conjure-up/blob/f7ec4ea632ab5f8b8d4f368bcdb09475b6e6f8cd/snapcraft/snapcraft.yaml is my snappy file | 15:57 |
| sergiusens | Chipaca can you give us some insight on the client installing with --devmode from the stable channel ? | 15:57 |
| stokachu | sergiusens: are you able to download the snap directly and install it? | 16:00 |
| sergiusens | stokachu I can, but there is no user facing api that allows this | 16:00 |
| stokachu | https://myapps.developer.ubuntu.com/dev/click-apps/5479/download/rev/9/ | 16:01 |
| stokachu | that doesn't work for you? | 16:01 |
| sergiusens | stokachu oh, I can fetch that snap, yes | 16:01 |
| stokachu | and then install it locally to see if it works | 16:01 |
| * sergiusens is downloading | 16:01 | |
| sergiusens | stokachu you can also just install remotely and copy over the .snap from /var/lib/snapd/snaps | 16:02 |
| * sergiusens is unsure about the exact path | 16:02 | |
| stokachu | im just curious if it fails the same way for you | 16:02 |
| stokachu | installing it locally should allow you to do conjure-up -h | 16:02 |
| sergiusens | stokachu will install as soon as it finishes downloading | 16:02 |
| stokachu | ok | 16:02 |
| * sergiusens leaves to pick up his son from daycare in the meantime | 16:03 | |
| sergiusens | stokachu sorry to say I am on 3Mbps here ;-) | 16:03 |
| stokachu | :\ https://www.irccloud.com/pastebin/kRLqcOUN/ | 16:06 |
| tianon | jdstrand: ah, good point re seccomp -- I'd managed to narrow down the list of calls Docker itself makes, but forgot that it starts arbitrary processes within containers which might need more O:) | 16:16 |
| brendand | https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ seems to imply that after adding the 'parts' section and running snapcraft stage that i should have something in stage/bin, but it's empty | 16:24 |
| brendand | the only output i saw that was suspicious was 'Please consider setting `go-importpath` for the 'cam' part' | 16:24 |
| sergiusens | stokachu did you get around to logging the snappy bug for that? | 16:27 |
| trijntje | kalikiana: but HOME gets mapped to $SNAP_USER_DATA for all snaps: | 16:27 |
| trijntje | export HOME="$SNAP_USER_DATA" | 16:27 |
| stokachu | sergiusens: no, im not sure if it's a bug on my end or snappy | 16:27 |
| sergiusens | stokachu it is snappy for that one, it should exit and be done with it | 16:28 |
| stokachu | ok ill file a bug now | 16:29 |
| sergiusens | stokachu but it seems to be reexec'ing on and on | 16:29 |
| stokachu | sergiusens: file against which project? snapcraft? | 16:30 |
| arges | hi is there a way to re-run autopkgtest on a pull request? i seem to have a failure but it seems to be unrelated to my change | 16:30 |
| arges | https://github.com/snapcore/snapd/pull/1612 | 16:30 |
| mup | PR snapd#1612: interfaces: add /proc/version_signature to appamor template <Created by arges> <https://github.com/snapcore/snapd/pull/1612> | 16:30 |
| sergiusens | stokachu launchpad.net/snappy | 16:31 |
| Chipaca | sergiusens, what about the client installing with --devmode from the stable channel? | 16:31 |
| Chipaca | ouch, that linkfest looks wrong :-( | 16:33 |
| stokachu | sergiusens: https://bugs.launchpad.net/snappy/+bug/1609045 | 16:33 |
| mup | Bug #1609045: running conjure-up -h results in the snap re-execing itself over and over <Snappy:New> <https://launchpad.net/bugs/1609045> | 16:33 |
| mup | Bug #1609045 opened: running conjure-up -h results in the snap re-execing itself over and over <Snappy:New> <https://launchpad.net/bugs/1609045> | 16:34 |
| Chipaca | stokachu, can you add information about where you're running thins? | 16:34 |
| Chipaca | this* | 16:34 |
| Chipaca | stokachu, like the distro you're on, and the snapd version, etc | 16:34 |
| stokachu | Chipaca: done | 16:35 |
| seb128 | no mvo around? | 16:36 |
| Chipaca | seb128, no | 16:36 |
| seb128 | Chipaca, do you know when he's back? | 16:36 |
| sergiusens | seb128 tomorrow | 16:37 |
| seb128 | sergiusens, thanks | 16:37 |
| stokachu | sergiusens: were you able to run conjure-up -h or did it hang? | 16:37 |
| trijntje | kalikiana: wait nevermind, that is before the wrapper is called, so you can still change it their | 16:39 |
| Chipaca | stokachu, you're re-execing the thing again and again i guess? | 16:41 |
| mup | PR snapcraft#663 closed: Improve python2 test coverage <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/663> | 16:41 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapcraft#706 closed: Added "camera" plug into the example <Created by liu-xiao-guo> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/706> | 16:47 |
| sergiusens | Chipaca his code isn't doing it | 16:47 |
| sergiusens | Chipaca in his snapcraft generated wrapper script I added some echo's to be sure; zyga said something weird was going on | 16:48 |
| kyrofa | Hey sergiusens, I expected you to be out another day | 16:49 |
| sergiusens | kyrofa next week | 16:49 |
| kyrofa | sergiusens, ah! | 16:49 |
| sergiusens | but I am so tired; not really inspired today | 16:49 |
| sergiusens | so just clearing the PR queue which I would feel bored to do some other day ;-) | 16:49 |
| sergiusens | kyrofa is godeps good to go btw? | 16:50 |
| kyrofa | sergiusens, yessir! | 16:50 |
| kyrofa | I just updated it | 16:50 |
| kyrofa | (from master, I mean) | 16:50 |
| Chipaca | sergiusens, um | 16:54 |
| Chipaca | sergiusens, conjure-up | 16:54 |
| Chipaca | sergiusens, calls a wrapper script, something like command-conjure-up.wrapper | 16:54 |
| Chipaca | sergiusens, which exec's conjure-up | 16:54 |
| sergiusens | Chipaca yes | 16:54 |
| sergiusens | Chipaca in that wrapper I added "echo running" and I see that echo'ed eternally | 16:55 |
| Chipaca | which, if your machine has a python3 interpreter in /home/adam/something, will pick up a conjure up inside the snap | 16:55 |
| Chipaca | but if not, it will look up the path | 16:55 |
| Chipaca | and find the conjure-up where it all started | 16:55 |
| stokachu | https://www.irccloud.com/pastebin/0XFp8Crt/ | 16:55 |
| stokachu | Chipaca: should i cahnge the conjure-up key to something else? | 16:55 |
| stokachu | is it looping b/c of that? | 16:55 |
| Chipaca | "key"? | 16:55 |
| stokachu | the key in snapcraft.yaml | 16:56 |
| ogra_ | well ... dont use the machines interpreter ... | 16:56 |
| Chipaca | ah, in the yaml | 16:56 |
| stokachu | line 2 | 16:56 |
| ogra_ | but ship your oown python | 16:56 |
| stokachu | can i just add that to my stage packages | 16:56 |
| stokachu | and does that fix my current issue? | 16:56 |
| ogra_ | well, what Chipaca said sounded like it could | 16:57 |
| Chipaca | let me see | 16:57 |
| Chipaca | stokachu, are you familiar with "snap try"? | 16:57 |
| stokachu | Chipaca: a little | 16:57 |
| ogra_ | if you ever want conjure to run on a snap image instead of a classic install it is safer to ship your own interpreter anyway ... | 16:57 |
| ogra_ | same goes for making your snap cross dristro | 16:58 |
| Chipaca | ogra_, they are shipping their own interpreter | 16:58 |
| stokachu | i would've though the python3 plugin would take care of that | 16:58 |
| ogra_ | ah | 16:58 |
| Chipaca | in fact they're shipping two of them just to be safe :-p | 16:58 |
| Chipaca | snapcraft is putting python 2 and 3 in the snap | 16:58 |
| ogra_ | well, as long as all shebangs are mangled to point to that ... | 16:58 |
| Chipaca | but that's not the issue | 16:58 |
| Chipaca | the issue is the shebang | 16:58 |
| Chipaca | stokachu, so, do this | 16:58 |
| Chipaca | stokachu, in your conjure-up script and all other scripts you want to use | 16:58 |
| Chipaca | you see to have | 16:59 |
| Chipaca | #!/home/adam/Projects/conjure/snapcraft/parts/conjure/install/usr/bin/python3 | 16:59 |
| Chipaca | stokachu, change that to #!/usr/bin/env python3 | 16:59 |
| Chipaca | stokachu, that will work; i've just tried it | 16:59 |
| stokachu | ok what do i need to do in my snapcraft.yaml to make that happen? | 16:59 |
| Chipaca | it's not snapcraft | 16:59 |
| Chipaca | it's the project itself | 16:59 |
| stokachu | Chipaca: so i use setuptools to generate the script | 17:00 |
| stokachu | https://github.com/conjure-up/conjure-up/blob/master/setup.py#L21 | 17:00 |
| Chipaca | bah, maybe snapcraft is responsible for the bad mangling of the shebang? sergiusens? | 17:00 |
| Chipaca | stokachu, that works | 17:00 |
| Chipaca | well, actually i don't know | 17:00 |
| Chipaca | i don't know what's generating the conjure-up script itself | 17:00 |
| stokachu | so i dont know where to put that shebang line at | 17:00 |
| ogra_ | i think the python plugin actually re-writes them | 17:01 |
| Chipaca | that is the usr/bin/conjure-up script in the snap | 17:01 |
| stokachu | it's all happening via setuptools | 17:01 |
| Chipaca | sergiusens, this is all on you, it seems :-D | 17:01 |
| stokachu | sergiusens: also the python3 plugin still won't pick up my requirements.txt | 17:01 |
| stokachu | this all makes | 17:02 |
| * stokachu very sad | 17:02 | |
| * Chipaca hugs stokachu | 17:03 | |
| stokachu | sergiusens: feel free to try and reproduce with https://github.com/conjure-up/conjure-up | 17:03 |
| stokachu | Chipaca: \o/ | 17:03 |
| sergiusens | Chipaca oh we fixed that in master, in any case the exec should be fine | 17:03 |
| sergiusens | stokachu I can fix requirements.txt today; I thought I told you to use master | 17:03 |
| Chipaca | sergiusens, I'm not following what you mean about the exec being fine | 17:03 |
| sergiusens | Chipaca in any case, how would the outside app find the exec from the inside? isn't that just wrong in any case? | 17:04 |
| sergiusens | Chipaca shebangs are fixed in master | 17:04 |
| Chipaca | sergiusens, because the .wrapper is doing PATH=$SNAP/bin:$SNAP/usr/bin:$PATH, and PATH already has /snap/bin | 17:04 |
| mup | PR snapd#1618 opened: interfaces: add lscpu to apparmor template <Created by arges> <https://github.com/snapcore/snapd/pull/1618> | 17:05 |
| sergiusens | Chipaca so /snap/bin exists inside the contained environment? for what possible reason? | 17:05 |
| Chipaca | sergiusens, what do you mean? the whole system is there | 17:05 |
| ogra_ | i think he meant $SNAP/bin | 17:05 |
| Chipaca | no, /snap/bin | 17:05 |
| sergiusens | ogra_ no, I mean /snap/bin | 17:05 |
| ogra_ | what would a snap do with /snap/bin ? | 17:06 |
| Chipaca | nothing | 17:06 |
| ogra_ | it cant exec anything there by default | 17:06 |
| Chipaca | nothing, for now at least | 17:06 |
| sergiusens | ogra_ which is why I think it shouldn't be there after snap-confine sets up the env | 17:06 |
| ogra_ | right | 17:06 |
| ogra_ | well, it should be in the users PATH | 17:07 |
| ogra_ | but not in any of the wrappers | 17:07 |
| sergiusens | also, $SNAP/bin/conjure-up should resolve before /snap/bin/conjure-up given the way we resolve the path | 17:07 |
| Chipaca | sergiusens, first, snap-confine isn't a thing yet | 17:07 |
| sergiusens | Chipaca heh, zyga sold it to me as a thing ;-) | 17:08 |
| sergiusens | talked about it all week ;-) | 17:08 |
| ogra_ | it is definitely in proposed | 17:08 |
| Chipaca | sergiusens, second, the idea isn't that it gives you a chroot-like experience where only your things exist | 17:08 |
| Chipaca | sergiusens, snap-confine is 2.11 which is proposed. debian has 2.08 still /o\ | 17:08 |
| Chipaca | sergiusens, it's still apparmor and seccomp mediating stuff, with the whole system there but inaccessible | 17:09 |
| Chipaca | right? | 17:09 |
| sergiusens | Chipaca so what is with my statement that $SNAP/bin/conjure-up should resolve before /snap/bin/conjure-up given precedence of path? | 17:10 |
| Chipaca | i saw no such statement, but i'll address it now | 17:10 |
| Chipaca | sergiusens, that is correct, but only if $SNAP/bin/conjure-up has a valid shebang | 17:10 |
| Chipaca | sergiusens, that is, the wrapper sets it up that way | 17:10 |
| sergiusens | Chipaca as it is invalid, should it just exit? | 17:11 |
| Chipaca | as I said: the .wrapper is doing PATH=$SNAP/bin:$SNAP/usr/bin:$PATH | 17:11 |
| Chipaca | sergiusens, feel free to file a bug against posix or something; this isn't our behaviour | 17:11 |
| Chipaca | sergiusens, wiht an invalid shebang it is not a valid executable | 17:11 |
| Chipaca | sergiusens, so the search continues along the path | 17:11 |
| Chipaca | sergiusens, i mean: this is /bin/sh doing the work, not us | 17:12 |
| sergiusens | Chipaca http://paste.ubuntu.com/21914894/ | 17:13 |
| sergiusens | it didn't bounce to the next here | 17:13 |
| Chipaca | sergiusens, now try with exec | 17:16 |
| sergiusens | Chipaca ah, there we go :-) | 17:16 |
| sergiusens | stokachu can you try master with your branch? in the meantime I'll fix that requirements.txt issue | 17:19 |
| stokachu | sergiusens: i tried building snapcraft from master and it failed | 17:19 |
| sergiusens | stokachu building with snapcraft or building snapcraft? | 17:20 |
| stokachu | sergiusens: building snapcraft itself | 17:20 |
| stokachu | sergiusens: sorry, ./setup.py install seems tow ork now | 17:22 |
| stokachu | lemme try to rebuild | 17:22 |
| sergiusens | stokachu how did you try and build? gbp buildpackage? | 17:22 |
| sergiusens | stokachu in any case you can just use the sources directly | 17:22 |
| ogra_ | gbp ? | 17:22 |
| stokachu | sergiusens: what do you want me to try master with? | 17:22 |
| ogra_ | you need to pay in british pounds ? | 17:22 |
| stokachu | i thought it was snapcraft | 17:22 |
| sergiusens | stokachu just run snapcraft as <path to snapcraft source>/bin/snapcraft | 17:22 |
| stokachu | ok | 17:23 |
| sergiusens | stokachu master has your shebang fix | 17:23 |
| kyrofa | sergiusens, are you +1 on godeps? I can babysit and merge when green if so | 17:23 |
| sergiusens | ogra_ gbp == git build package | 17:23 |
| ogra_ | ah | 17:23 |
| sergiusens | kyrofa I want balloons to try it out though | 17:23 |
| sergiusens | ogra_ akin to bzr bd | 17:23 |
| ogra_ | yeah | 17:23 |
| balloons | I tried it and failed in Leiden | 17:24 |
| ogra_ | got it ... never used git for package trees :) | 17:24 |
| balloons | as in I failed to get it to run.. it ate my snapcraft | 17:24 |
| kyrofa | balloons, huh? | 17:24 |
| kyrofa | balloons, you mean you weren't successful in running snapcraft from source? | 17:24 |
| balloons | kyrofa, in other words, I have no useful data for you. But yes, I would really like it to land to use it | 17:24 |
| balloons | kyrofa, right. I failed to get it to run (though I did a make install) | 17:25 |
| balloons | err.. setup.py install | 17:25 |
| sergiusens | balloons oh, just run from source | 17:25 |
| kyrofa | balloons, yeah just clone snapcraft and run snapcraft from `<snapcraft root>/bin/snapcraft` | 17:25 |
| sergiusens | kyrofa do we have docs for running from source? | 17:25 |
| kyrofa | sergiusens, honestly I don't think so | 17:25 |
| kyrofa | We should | 17:25 |
| sergiusens | seems like we should | 17:25 |
| * sergiusens is enjoying a nice blackout tethering with a very slow 3g connection for the past hour | 17:26 | |
| kyrofa | sergiusens, we have "bin: Holds the main snapcraft script. Putting this bin in your PATH or directly running scripts from it will find the rest of the source tree automatically." | 17:26 |
| ogra_ | could be worse ... | 17:26 |
| kyrofa | in HACKIND.md | 17:26 |
| kyrofa | sergiusens, haha: https://github.com/snapcore/snapcraft/blob/master/HACKING.md#installing-in-a-virtualenv | 17:26 |
| kyrofa | sergiusens, I doubt that actually works | 17:27 |
| ogra_ | (smoke signs ... having to translate to morse code ... etc) | 17:27 |
| stokachu | cant wait for deltas... | 17:27 |
| kyrofa | sergiusens, I seem to remember josepht making some setup.py changes to make that better | 17:27 |
| kyrofa | But yeah, balloons running straight from source is probably the easiest | 17:28 |
| kyrofa | balloons, any chance you can give that a shot for me? Uninstall snapcraft from the system and run from source to use the new plugin, then you can just install snapcraft from the archive again | 17:28 |
| balloons | kyrofa, ohh.. I remember one other bit about my attempt actually. It wasn't clear how to use the plugin | 17:29 |
| balloons | kyrofa, but yes I can try now. My snap needs this plugin | 17:29 |
| kyrofa | balloons, `snapcraft help godeps` will give you the various options it supports | 17:30 |
| stokachu | sergiusens: still seems to be re-execing | 17:31 |
| stokachu | using snapcraft from master | 17:31 |
| stokachu | https://www.irccloud.com/pastebin/FZvrc3li/ | 17:32 |
| stokachu | sergiusens: ^ maybe running from snapcraft/bin/snapcraft isn't using the source from that tree? | 17:33 |
| kyrofa | stokachu, uninstall the snapcraft deb, first | 17:36 |
| stokachu | running it in pyenv | 17:36 |
| stokachu | should be ok that way | 17:37 |
| jcastro | hey, if I apt install snapd on a system that doesn't have it, do I need to logout and back in for the path to work? Seems like /snap/bin wasn't in my patyh | 17:40 |
| stokachu | https://www.irccloud.com/pastebin/VkC9E3HR/ | 17:43 |
| stokachu | sergiusens: still uses this shebang path | 17:43 |
| stokachu | holy balls | 17:53 |
| stokachu | i think it is working now | 17:53 |
| kyrofa | jcastro, yeah, probably. /snap/bin is in /etc/profile.d | 17:54 |
| kyrofa | set in, rather | 17:54 |
| stokachu | can someone else run `snap install conjure-up --devmode`, then run `conjure-up -h` to see if the help screen works | 17:58 |
| * balloons tries | 18:01 | |
| balloons | whoa, 150mb! | 18:01 |
| stokachu | balloons: hah | 18:02 |
| stokachu | i even stripped out the juju packages except for the binaries | 18:02 |
| stokachu | thats like 40mb | 18:02 |
| balloons | kyrofa, I believe my yaml file is correct now, it's cloned and pulling depends. Hopefully my import path is correct | 18:03 |
| kyrofa | balloons, it just needs to be whatever the project expects it to be-- the plugin doesn't care | 18:04 |
| balloons | stokachu, it works | 18:07 |
| stokachu | balloons: \o/ | 18:07 |
| stokachu | balloons: thanks for checking | 18:07 |
| jhobbs | https://github.com/snapcore/snapcraft/pull/697 how do i proceed with this PR? autopkgtest snaps failed, though I can't see its results, and didn't make any changes that would have affected package builds afaict | 18:08 |
| mup | PR snapcraft#697: Also use INSTALLROOT for make plugin <Created by jhobbs> <https://github.com/snapcore/snapcraft/pull/697> | 18:08 |
| jcastro | stokachu: works for me too | 18:09 |
| stokachu | jcastro: sweet! it doesn't deploy yet but im working on that now | 18:10 |
| kyrofa | jhobbs, I just requested a retest, but it looks like it's out of date with master as well. Can you hit the "update branch" button, there? | 18:11 |
| balloons | kyrofa, is there a way to easily reattempt the build step? I don't want to have to pull everything again | 18:11 |
| balloons | IMHO, snapcraft should just re-execute a step if I specify it specifically | 18:11 |
| kyrofa | balloons, indeed, you can `snapcraft clean --step=build` (or `snapcraft clean <part> --step=build`) and then run `snapcraft` again | 18:12 |
| jhobbs | kyrofa: k, just did | 18:12 |
| balloons | kyrofa, yea go-importpath is not happy | 18:15 |
| kyrofa | balloons, what's happening? | 18:15 |
| balloons | kyrofa, typically I would go install github.com/juju/juju/... | 18:16 |
| kyrofa | balloons, so I assume you specified github.com/juju/juju as the go-importpath? | 18:17 |
| balloons | that causes warning: "./github.com/juju/juju/..." matched no packages | 18:17 |
| balloons | kyrofa, right | 18:17 |
| sergiusens | kyrofa can you look at 707? | 18:17 |
| mup | PR snapcraft#707 opened: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707> | 18:17 |
| kyrofa | balloons, any chance you could pastebin your YAML? Or if this is contained within a source tree, push it up somewhere I can take a look? | 18:18 |
| balloons | kyrofa, and sure enough, there is no parts/juju/go/src/github.com/juju/juju | 18:18 |
| kyrofa | balloons, huh. That should be done as part of the pull step | 18:19 |
| kyrofa | Actually, that's not true | 18:19 |
| sergiusens | kyrofa during standup I will go over the changes we will do with the go plugin which we could reflect in godeps | 18:19 |
| balloons | well, I got parts/juju/go/src/github.com/juju, but not parts/juju/go/src/github.com/juju/juju | 18:19 |
| kyrofa | balloons, it should just be a symlink to parts/juju/src | 18:20 |
| kyrofa | balloons, so what are you pulling? | 18:20 |
| balloons | kyrofa, https://github.com/nskaggs/snap-juju.git | 18:20 |
| mup | PR snapd#1619 opened: Add initial "docker" interface based on some of 15.04's privileges <Created by tianon> <https://github.com/snapcore/snapd/pull/1619> | 18:21 |
| kyrofa | balloons, take a look at parts/juju/src. Does it contain the entire repo? | 18:21 |
| kyrofa | Or is it missing stuff, too? | 18:21 |
| balloons | it looks correct | 18:22 |
| balloons | hmmm | 18:23 |
| balloons | found the symlink | 18:24 |
| balloons | it's parts/juju/go/src/src/github.com/juju/juju | 18:24 |
| kyrofa | balloons, wait.. src is duplicated? Okay, let me clone your project. It's up to date? | 18:26 |
| balloons | yes, it is | 18:26 |
| balloons | I may be at fault here | 18:26 |
| balloons | fixing the bad symlink is getting a good run now | 18:27 |
| balloons | I think I pulled with the import path containing an extra src argument in it. That's my guess | 18:28 |
| kyrofa | Oh oops | 18:28 |
| balloons | kyrofa, I have a snap now | 18:28 |
| kyrofa | balloons, I'll verify what you have up there real quick | 18:29 |
| balloons | ack, ty | 18:29 |
| mup | PR snapcraft#698 opened: Add option disable-parallel for autotools plugin <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/698> | 18:29 |
| balloons | snap works. This is nice. +1 from me | 18:30 |
| kyrofa | balloons, I'm testing on a clean lxc. Mind +1ing the PR? | 18:34 |
| balloons | btw, testing a new plugin is actually really simple as you say. Just add the python file to the plugins dir :-) | 18:36 |
| kyrofa | balloons, indeed. Did you know that you can use plugins from parts/plugins as well? | 18:42 |
| kyrofa | balloons, so you can test/develop before upstreaming, or just distribute plugins that do things for weird build systems that shouldn't necessarily be upstreamed | 18:42 |
| balloons | kyrofa, I believe I learned that last week, but it's a good reminder. Parts can be reused; not something I've played with yet | 18:45 |
| sergiusens | balloons can you unsquashfs -l <snap> and show me the contents? | 18:46 |
| kyrofa | balloons, I'm not talking about the parts, I mean plugins. Like you could have copied the godeps.py src and put it into parts/plugins/godeps.py and run snapcraft using the plugin from there | 18:46 |
| kyrofa | balloons, you should add bzr as a build-package on this, by the way | 18:46 |
| kyrofa | balloons, but yeah, things look good | 18:46 |
| sergiusens | kyrofa standup | 18:47 |
| kyrofa | sergiusens, finding headphones | 18:47 |
| balloons | sergiusens, sure | 18:48 |
| balloons | kyrofa, add bzr as a build-package for juju? | 18:48 |
| kyrofa | balloons, indeed, some of the godeps pull via bzr | 18:48 |
| balloons | kyrofa, ohh.. good catch | 18:49 |
| balloons | sergiusens, http://paste.ubuntu.com/21927350/ | 18:49 |
| balloons | kyrofa, right, you discovered that by running in the lxc container I'd guess :-) | 18:50 |
| kyrofa | balloons, you got it. cleanbuild (or running on LP) would discover that as well | 18:50 |
| balloons | right -- I hope to have LP build it | 18:50 |
| balloons | I need to look into how that works | 18:50 |
| SamYaple | sergiusens: regarding https://github.com/snapcore/snapcraft/pull/707 , what behaviour would that be changing? | 18:56 |
| mup | PR snapcraft#707: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707> | 18:56 |
| SamYaple | sergiusens: os.getcwd() should always be self.sourcedir right? | 18:57 |
| sergiusens | SamYaple you saw my PR? | 19:02 |
| SamYaple | sergiusens: i see all PRs | 19:03 |
| sergiusens | SamYaple yeah, for when using remote sources | 19:03 |
| SamYaple | oh. ok that makes more sense | 19:03 |
| sergiusens | SamYaple I was going to ask you if you minded updating with my | 19:03 |
| SamYaple | ill update my constraints PR | 19:03 |
| sergiusens | SamYaple thanks | 19:19 |
| sergiusens | balloons thanks | 19:19 |
| sergiusens | balloons was your intention to have all those binaries? | 19:20 |
| sergiusens | build them even | 19:20 |
| kyrofa | balloons, things have changed slightly since I wrote this, but it'll still be helpful: https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way | 19:22 |
| balloons | sergiusens, an excellent question. I want juju, jujud, juju-metadata, juju-upgrade-mongo | 19:22 |
| SamYaple | sergiusens: hitting C901, pep8 complexity on _pip() | 19:22 |
| SamYaple | :/ | 19:22 |
| balloons | sergiusens, and sometimes I don't want jujud | 19:23 |
| SamYaple | sergiusens: let me refactor it, but one of us will have to rebase | 19:23 |
| SamYaple | sergiusens: if you remove the python2 changes from your PR i can incorprate them in mine | 19:23 |
| mup | PR snapcraft#691 closed: Add godeps plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/691> | 19:23 |
| kyrofa | \o/ | 19:24 |
| sergiusens | SamYaple I have static conflicts and integration test conflicts | 19:24 |
| sergiusens | SamYaple so I need to look at those for a bit | 19:24 |
| sergiusens | SamYaple that means, I will rebase | 19:24 |
| nacc | so I've got a fairly simple python script in snap, and sys.getfilesystemencoding() is reporting 'ascii'. This is leading to issues with subprocesses, which are unable to parse UTF8 (aiui). Is this a limitation of squashfs? Any suggested workarounds? | 20:07 |
| nacc | as far as I've been able to tell, setting LC_ALL or LANG or LC_CTYPE has no effect on the sys.getfilsystemencoding() value | 20:09 |
| kgunn | jdstrand: so if my interface is "autoconnect" for mir, does that mean both the server side and the client side are autoconnect? | 20:24 |
| mup | Bug #1609045 changed: running conjure-up -h results in the snap re-execing itself over and over <conjure> <Snapcraft:New> <https://launchpad.net/bugs/1609045> | 20:45 |
| stokachu | sergiusens: ^ just moved that over, feel free to close it if it's going in the next snapcraft release | 20:46 |
| stokachu | kyrofa: ^ not sure if you're also a maintainer | 20:47 |
| kyrofa | stokachu, what about the directory creation to be investigated by zyga? Do you want that? | 20:49 |
| stokachu | kyrofa: ah, im not entirely sure what sergiusens was referring to | 20:50 |
| kyrofa | stokachu, that was Chipaca, from the bug. If this is referring to the python shebang lines, indeed this is a dupe. But it also sounds like there's a snapd bug there | 20:50 |
| stokachu | kyrofa: ok i think it'll be best if i get with sergiusens and create a new bug for snapd | 20:51 |
| stokachu | so they don't get mixed | 20:51 |
| kyrofa | stokachu, alright, I'll dupe | 20:51 |
| stokachu | thanks | 20:51 |
| kyrofa | stokachu, thank you! | 20:53 |
| jdstrand | kgunn: the 'permanent' slot or plug policy is generated unconditionally. auto-connect true will auto-connect a snap that slots: [ mir ] to all snaps that plugs: [ mir ] | 21:03 |
| tianon | I wish "snappy-debug.security scanlog" supported colors somehow so the output was easier to visually skim O:) | 22:07 |
| tianon | anyone know where I'd report such a "feature request" for that specific snap? :) | 22:08 |
| kgunn | jdstrand: what did you mean by "The connected plug should actually be 'common'." in terms of a change? | 22:20 |
| tianon | (in case anyone else is interested, if you don't need the suggestions that "scanlog" provides, I've been having reasonable success with "dmesg --follow --color=always | grep --color=none 'audit.*docker'" for colored audit logs that are also single-line and way easier to just skim) | 22:26 |
| kyrofa | tianon, I'm not sure where the code for the snappy-debug snap is hosted, but jdstrand might be able to tell you how to log bugs against it | 22:42 |
| tianon | sounds like all roads lead to jdstrand eventually :D | 22:42 |
| kyrofa | tianon, indeed. jdstrand knows all things | 22:48 |
| tianon | :D | 22:51 |
| kyrofa | kgunn, where did he say that? He seems to be away, can I help? | 22:52 |
| qengho | Okay, so I have a snap. I worked on it for a while, made some local data. I tested new revisions by installing local snaps, and it pulls my data forward each time. Great. Now I have a new version in the store and I want to refresh and I don't want to uninstall and lose that data. | 23:35 |
| kyrofa | qengho, unfortunately, sideloaded snaps and snaps from the store, even while sharing names, are completely different snaps | 23:37 |
| kyrofa | qengho, there's really no way to do what you ask | 23:37 |
| qengho | kyrofa: I don't know what "are different" means when I can't "snap install" a version from the store. | 23:38 |
| qengho | Store -> local was trivial. Once I install a local file with same name, it poisons everything? | 23:39 |
| kyrofa | qengho, ah, you initially had a version installed from the store and you sideloaded over the top, now you want to go back? | 23:39 |
| qengho | Can I uninstall that different snap, then? | 23:39 |
| qengho | Yes. | 23:39 |
| kyrofa | What does snap refresh <snapname> tell you? | 23:40 |
| qengho | '''error: cannot refresh "tor-middle-relay": cannot refresh local snap "tor-middle-relay"''' | 23:41 |
| kyrofa | qengho, let me try something, hold on | 23:42 |
| qengho | I recall one of the promises of snaps was that one could "roll back" changes. | 23:42 |
| kyrofa | qengho, indeed, the initial bits of that is in -proposed, but it's not yet complete | 23:43 |
| qengho | kyrofa: I'm looking around, and I see only three xNN revision directories for data. Maybe I'm too far into the future since the store version? | 23:44 |
| kyrofa | qengho, no revisions start without x? | 23:45 |
| qengho | kyrofa: correct. | 23:45 |
| kyrofa | Argh! | 23:45 |
| kyrofa | There's obviously a bug here. I'm not sure what it is though. Should it be impossible to sideload over a store snap if you can't go back? | 23:45 |
| === chihchun is now known as chihchun_afk | ||
| kyrofa | I didn't think revision cleaning was released yet | 23:46 |
| kyrofa | qengho, are you on -proposed? | 23:46 |
| qengho | kyrofa: No, stable. Pretty sure. | 23:47 |
| qengho | I don't know how to check. | 23:47 |
| kyrofa | qengho, that's okay, then you probably aren't on proposed | 23:47 |
| kyrofa | qengho, you have a few options. You can come back tomorrow a little earlier in the day when snapd devs are around who can answer your question, or you can log a bug to make it more asynchronous | 23:49 |
| kyrofa | qengho, actually, you should send an email to the mailing list | 23:49 |
| kyrofa | Since we're not sure where the bug lies | 23:49 |
| qengho | kyrofa: I think the first bug is that I can't roll back. | 23:49 |
| kyrofa | qengho, that's known though, and in progress | 23:49 |
| qengho | kyrofa: The second bug is that installing a local package with the same name is possible. OR, that once a snap is installed locally, "snap refresh" never looks at the store for a replacement. | 23:51 |
| kyrofa | qengho, indeed, it's the OR that suggests this would be a good mailing list post | 23:51 |
| qengho | kyrofa: It's my 8AM, so I'll be around for a bit. I'll see about the mailing list. | 23:52 |
| kyrofa | qengho, yeah, you're pretty much exactly opposite the rest of the team, so that may be your best bet | 23:52 |
| qengho | kyrofa: I'm returning to the US tonight, so will be back in sync with them soon. | 23:53 |
| kyrofa | qengho, ah! Where are you if I may ask? | 23:53 |
| qengho | <- Desktop team guy, spent the summer in Taiwan. | 23:54 |
| kyrofa | Nice | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
