| ogra_ | kyrofa, i'm pretty sure we could just add a serial interface to all gadgets by default, lets talk tomorrow | 01:34 |
|---|---|---|
| mup | PR snapd#2939 closed: cmd/libsnap: add sc_string_append_char <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2939> | 06:41 |
| mup | PR snapd#2949 opened: cmd/libsnap: add sc_string_append_char_pair <Created by zyga> <https://github.com/snapcore/snapd/pull/2949> | 07:00 |
| === caribou_ is now known as caribou | ||
| === tinwood_swap is now known as tinwood | ||
| === JanC is now known as Guest13435 | ||
| === JanC_ is now known as JanC | ||
| === JamesTait is now known as Guest52630 | ||
| RoninDev | Hello! Can you help me please. I try to make snap using github sources. Github sources contains perl scripts. I need to run perl build script and after it copy all directory into the snap. But my prime and stage folders are empty. I use plugin dump, scriptlet "build: perl build.pl". If i comment build scriptlet, all sources persists in destination stage and prime. But if I uncomment it, destination folders are empty | 09:51 |
| === Guest52630 is now known as JamesTait | ||
| mup | PR snapd#2950 opened: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <https://github.com/snapcore/snapd/pull/2950> | 09:52 |
| mup | PR snapd#2899 closed: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2899> | 09:53 |
| mup | PR snapd#2951 opened: interfaces: use seccomp specs <Created by stolowski> <https://github.com/snapcore/snapd/pull/2951> | 09:55 |
| mup | PR snapd#2940 closed: interfaces: use seccomp specs <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2940> | 09:56 |
| === JamesTait is now known as Guest48538 | ||
| === Guest48538 is now known as JamesTait | ||
| === zsombi_ is now known as zsombi | ||
| om26er | Hi! where can I get snapcraft lxd image ? | 10:25 |
| om26er | do we maintain one ? | 10:25 |
| ogra_ | om26er, iirc a "snapcraft cleanbuild" downloads it, it should show the download location it uses (i could be wrong though) | 10:47 |
| om26er | ogra_: hmm, seems snapcraft downloads a normal ubuntu image and installs packages afterwards | 10:53 |
| kalikiana_ | om26er: what else do you expect? regular snapcraft also builds on your classic ubuntu | 11:32 |
| om26er | kalikiana_: just an image with upto date snapcraft preinstalled :) | 11:32 |
| kalikiana_ | om26er: You don't need snapcraft in the image. It copies itself | 11:33 |
| mup | PR snapd#2952 opened: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/2952> | 12:09 |
| === tedg_ is now known as tedg | ||
| mup | PR snapd#2953 opened: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/2953> | 14:48 |
| mup | Bug #1667844 changed: r1325 core snap candidate rebooting every 7 min without iTCO_wdt module loaded <Snappy:Fix Released> <https://launchpad.net/bugs/1667844> | 14:50 |
| mup | PR snapd#2954 opened: wip: 2nd setup-profiles done after restart for installing core <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2954> | 15:14 |
| === iliv_ is now known as iliv | ||
| mup | PR snapd#2955 opened: cmd: fixes to run correctly on opensuse <Created by mvo5> <https://github.com/snapcore/snapd/pull/2955> | 15:33 |
| === dgadomski_ is now known as dgadomski | ||
| Pharaoh_Atem | wut | 15:40 |
| Pharaoh_Atem | mvo: openSUSE?! | 15:40 |
| Pharaoh_Atem | oh, these are zyga commits in disguise | 15:42 |
| mup | Bug #1642581 changed: Livepatch checkState: check-failed <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1642581> | 15:53 |
| kyrofa | Hey ogra_, I don't think the serial-port interface has an "all" option, does it? | 16:10 |
| ogra_ | kyrofa, no, but if your plug defines it and the device is fixed it should still work | 16:11 |
| kyrofa | ogra_, judging from this comment, the definition of individual devices actually needs to be slot-side right now: https://bugs.launchpad.net/snapd/+bug/1645445/comments/2 | 16:12 |
| mup | Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1645445> | 16:12 |
| kyrofa | ogra_, i.e. in the gadget itself | 16:13 |
| ogra_ | kyrofa, so we could define two at least .... /dev/ttyS0 and /dev/ttyUSB0 | 16:14 |
| kyrofa | ogra_, yeah that's the best we could do I think, and it doesn't help I'm afraid. Not only does it not work for multiple devices, but the inability to determine which device is which means even if we expanded that it's not very helpful | 16:19 |
| kyrofa | ogra_, we have udev as an interface backend. I don't understand why the serial-port is slot-only | 16:20 |
| ogra_ | why ? if you have a single usb dongle attached it will always be USB0 | 16:20 |
| kyrofa | ogra_, as soon as you have more than one that breaks down | 16:20 |
| ogra_ | and if there is a local serial port the first one is always ttyS0 | 16:20 |
| ogra_ | indeed | 16:21 |
| ogra_ | but it works for a single serial port device, either native or USB | 16:21 |
| ogra_ | and you can add more slots ... USB1 ttyS1 | 16:21 |
| ogra_ | for USB that becomes kind of tricky indeed | 16:21 |
| ogra_ | since the order wont be fixed | 16:22 |
| kyrofa | ogra_, yeah that's what I mean by the inability to determine which device is which | 16:22 |
| ogra_ | and you have multiple in all your cases ? ? | 16:22 |
| kyrofa | For my specific use-case, no. I'm currently only using one. But in the systems I've used in the past we had several | 16:23 |
| thresh | so... "\Adjusting snap declaration for the slot side to include "deny-auto-connection": "true" since it was mistakenly omitted.รข" what does that mean? | 16:25 |
| kyrofa | thresh, where are you seeing that? | 16:56 |
| lazyPower | is there a way to skip the fetch phase of the dump plugin? My upstream source seems to be having flakey connectivity issues today, i have the .tar.bz2 source already fetched, seems like it should just take that unless i clean it? | 18:27 |
| kyrofa | lazyPower, if the pull step has already completed it shouldn't be trying it again | 18:27 |
| kyrofa | lazyPower, are you cleaning it each time? | 18:27 |
| lazyPower | kyrofa: :| thats unfortunate. its attempting to fetch etcd over and over | 18:27 |
| lazyPower | i was, however i've placed the release tarball its expecting in $PWD and it seems to think thats not good enough, its still attempting to fetch it. | 18:28 |
| kyrofa | lazyPower, yeah snapcraft does its own state tracking | 18:28 |
| kyrofa | lazyPower, stop cleaning the pull step, then. You can clean each step of the lifecycle individually. If you don't want to pull again, just clean back to the build step: snapcraft clean -s build | 18:28 |
| lazyPower | ahhhh ok | 18:29 |
| kyrofa | lazyPower, you can do that per-part as well: snapcraft clean <part> -s build | 18:29 |
| lazyPower | now i just need to get past this connectivity issue and we should be golden once i've got the package fetched again | 18:29 |
| lazyPower | thanks for the details kyrofa | 18:29 |
| kyrofa | lazyPower, it's why I'm here! Any time | 18:29 |
| lazyPower | oh, also! I discovered what my issue seems to have been wrt snap refresh bailing... (i think it was zyga that followed up actually... but i pinged you instead. derp!) https://bugs.launchpad.net/snapd/+bug/1668659 | 18:30 |
| mup | Bug #1668659: Using snaps in lxd can be problematic during refresh (using squashfuse) <snapd:New> <https://launchpad.net/bugs/1668659> | 18:30 |
| lazyPower | looks like squashfuse works great until you go to refresh and the apparmor profile steps in to create schenanigans | 18:30 |
| kyrofa | Ah interesting | 18:30 |
| lazyPower | so its isolated to lxd, i gave it some additional love on clouds and things were working as expected | 18:30 |
| lazyPower | i expected to find dragons in there tbh... snaps in lxd is still experimental no? | 18:31 |
| kyrofa | lazyPower, as far as I know, yes. But that's a better question for stgraber | 18:31 |
| lazyPower | fair enough, consult with the oracle of containers | 18:31 |
| kyrofa | Indeed :) | 18:31 |
| lazyPower | kyrofa: i just need to edit a shellscript to resolve some syntax errors i built with the last push. is it going to set off alarms if i just edit the wrapper in place? | 18:44 |
| lazyPower | on the installed unit (not sure if we tripwire or crc check or whatever integrity checks in snaps... but i know its a big deal) | 18:45 |
| kyrofa | lazyPower, "in place" meaning what... within the installed snap itself? You will quickly become sad if so | 18:45 |
| lazyPower | oooookay, thats why i asked before i hozed it :) | 18:46 |
| kyrofa | lazyPower, haha, so yes, that's what you meant? | 18:46 |
| kyrofa | lazyPower, we don't check the integrity within the snap as it's immutable-- it's a squashfs image, you can't actually change it | 18:47 |
| kyrofa | lazyPower, so: you won't be sad because things will break, but because you won't actually succeed | 18:47 |
| lazyPower | ooo | 18:47 |
| lazyPower | okay, well that makes sense | 18:47 |
| lazyPower | sorry still wrapping my head around the tech and poking it with progressively longer sticks to see what it does | 18:48 |
| kyrofa | lazyPower, squashfs is a compressed filesystem that is by definition read-only | 18:48 |
| mup | PR snapcraft#1164 opened: tests: run the master tests against the staging server <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1164> | 18:49 |
| kyrofa | lazyPower, and no apology necessary, sorry if I came off as abrasive there, I'm just messing with ya | 18:50 |
| lazyPower | no way :) you're good kyrofa | 18:51 |
| kyrofa | lazyPower, are you still developing this snap? Or when you say "[...] with the last push" did you release something? | 18:51 |
| lazyPower | not to the store, no. I'm picking up where sabdfl left off with etcd and massaging it into the charm | 18:51 |
| kyrofa | lazyPower, do you know about `snap try`? | 18:52 |
| lazyPower | i do not | 18:52 |
| kyrofa | lazyPower, well, squashfs images being read-only is a cool, important part of the snap story. But it's incredibly annoying when you're still developing your snap, as you may have noticed | 18:52 |
| lazyPower | yeah, this looks like the devmode stuff from before but minus the squashfs bits | 18:52 |
| lazyPower | interesting | 18:52 |
| kyrofa | lazyPower, snapcraft's 'prime' step creates a `prime` directory that is literally the final snap, but not put into the final image | 18:53 |
| kyrofa | lazyPower, instead of running all the way through snapcraft's lifecycle, you could stop on `prime` and just `snap try prime` | 18:54 |
| kyrofa | lazyPower, then instead of installing/mounting the squashfs image (which would be read-only), snapd will bind-mount the `prime` directory into place and treat it as the snap | 18:54 |
| lazyPower | ok, i'll give this a go once i can unblock snapcraft (s3 is down \o/) | 18:54 |
| kyrofa | lazyPower, which means it's no longer read-only. As you change stuff in `prime`, you change the snap | 18:54 |
| kyrofa | lazyPower, s3 is only down in us-east I think | 18:55 |
| kyrofa | lazyPower, us-west-2 is working here | 18:55 |
| lazyPower | seems to be what i'm routing to :( | 18:55 |
| kyrofa | Poor guy | 18:55 |
| kyrofa | lazyPower, anyway, consider that your snappy lesson of the day | 18:55 |
| lazyPower | thanks kyrofa :) its very helpful | 18:56 |
| kyrofa | lazyPower, any time | 18:57 |
| mup | PR snapcraft#1155 closed: beta <Created by snappy-m-o> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1155> | 19:04 |
| lazyPower | kyrofa: one additional question you might have insight into | 19:04 |
| kyrofa | lazyPower, sure | 19:05 |
| lazyPower | kyrofa: We have user requests to support durable storage for applications. /var/snap/$snap/$revision is a versioned fs path, i cant just bindmount the block device to a specific version. The only way to work around this would be to take over the /var/snap/$snap path? | 19:05 |
| kyrofa | lazyPower, durable storage = remains when the snap is removed? | 19:06 |
| lazyPower | well, think AWS EBS volumes. | 19:06 |
| lazyPower | yeah | 19:06 |
| kyrofa | lazyPower, ah sure | 19:06 |
| lazyPower | you could nuke the application, and restore from that data dir and dump + restore | 19:06 |
| lazyPower | but snap remove would effectively wipe that out wouldn't it? | 19:06 |
| kyrofa | lazyPower, I suggest using the `removable-media` plug | 19:06 |
| kyrofa | lazyPower, that would allow access to disks in /media/ | 19:07 |
| lazyPower | hmmm ok | 19:07 |
| lazyPower | https://github.com/CanonicalLtd/snappy-docs/blob/master/reference/interfaces.md - that appears undocumented | 19:07 |
| * lazyPower files a bug | 19:07 | |
| kyrofa | lazyPower, I see it there | 19:08 |
| lazyPower | argh darn me and my typos | 19:08 |
| lazyPower | you are correct its inline | 19:08 |
| jsolano | hello, any freelancers out there in Germany or Switzerland with experience with Ubuntu Core and snaps on ARM hardware? | 19:39 |
| jsolano | or any hint at where to find them? Somebody I know is looking for an engineer for a short placement with this kind of experience | 19:40 |
| diddledan | jdstrand: I got a notification that you made a change to corebird-diddledan to a slot declaration. Do I need to make any changes to my snapcraft.yml at all for future uploads to automatically have that or is the fix entirely store-side? | 19:40 |
| jdstrand | diddledan: no. just a store side thing | 19:40 |
| kyrofa | jsolano, have you mentioned this to Canonical? They might be able to help you | 19:40 |
| diddledan | thanks | 19:41 |
| jdstrand | diddledan: np | 19:41 |
| jdstrand | diddledan: I just wanted you and other reviewers to know I did it | 19:41 |
| diddledan | cool :-) | 19:41 |
| jsolano | kyrofa, yes, I checked with them and I think they posted the information on linkedin, but no luck so far | 19:41 |
| kyrofa | jsolano, did you speak to them about a commercial engagement for them to do the work? | 19:42 |
| balloons | if i snap refresh --revision, what happens when the next refresh happens? | 19:43 |
| kyrofa | balloons, I have that same question. Chipaca, are you around to answer that one? | 19:43 |
| jsolano | kyrofa, actually not, I didn't think about that route, perhaps something worth considering | 19:43 |
| kyrofa | jsolano, direct message your contact info to me, I can put you in touch with the right people | 19:44 |
| kyrofa | (if you're interested, of course) | 19:46 |
| balloons | kyrofa, I think it would require you to be the owner to do it? I'm not sure. The same question exists if you revert to a specific revision. I imagine either way you'll be bumped forward again by the next one | 19:54 |
| kyrofa | balloons, indeed, I know that in order to use specific revisions you need to be a developer for the snap in question | 19:54 |
| kyrofa | balloons, but the question about what happens by an update, no idea | 19:54 |
| mup | Bug #1668738 opened: core snap with configure hook fails for some people <Snappy:New> <https://launchpad.net/bugs/1668738> | 19:55 |
| bdmurray | Is there something equivalent to cronjobs in snaps? | 20:53 |
| mup | PR snapd#2945 closed: interfaces: miscellaneous policy updates for unity7, udisks2 and browser-support (LP: #1667480) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2945> | 20:55 |
| lazyPower | Is there a way to query the snap package listing in a format other than smart output? I need to surface some data and >>> check_output(split('snap list | grep rclone')).strip().split(b'\n')[-1].split(b' ')[2] seems like a really ugly and brittle way to do this | 20:56 |
| mup | PR snapd#2946 closed: interfaces: consistently use 'const' instead of 'var' for security policy <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2946> | 20:57 |
| thresh | how do I ship logrotate files and systemd service files in snap packages? I want to package a server-side software. | 20:57 |
| lazyPower | thresh: so snappy creates systemd files for you when you declare daemons in the snapcraft.yaml | 20:58 |
| lazyPower | thresh: for example i'm working with the etcd snap and it creates a 'snap.etcd.etcd' service which is the etcd systemd job that controls ensuring the daemon is up and running. | 20:58 |
| thresh | kyrofa, I believe jdstrand did something to my VLC snap that is uploaded to the store :) | 20:58 |
| thresh | lazyPower, aha, nice, thanks! | 20:59 |
| lazyPower | thresh: regarding the logrotate jobs, i'm not positive on that front, might be worth a ping to the snapcraft ML if nobody pipes up here | 20:59 |
| jdstrand | thresh: I did not touch the snap. I adjusted its snap declaration | 21:02 |
| thresh | jdstrand, do we have to do anything on our side? | 21:02 |
| jdstrand | thresh: nope | 21:02 |
| thresh | It was a bit weird, though. | 21:02 |
| jdstrand | thresh: just wanted people to know the change was made | 21:03 |
| thresh | OK, thanks! | 21:03 |
| mwhudson | can i build classic snaps in launchpad yet> | 21:05 |
| mwhudson | ? | 21:05 |
| kyrofa | mwhudson, I haven't tried lately, but I _think_ so | 21:08 |
| mwhudson | ah heck, i can't use the same snap name for two branches | 21:16 |
| mwhudson | although maybe that doesn't actually matter here | 21:17 |
| mwhudson | Setting up '/home/buildd/.cache/snapcraft/projects/snapcraft-core/snap_hashes/ppc64el/d8e9e73dabe243321f9df8b09e270bccfde6f273f05d90a21365aa6f77574127274479af8033389c0be076797c74a595' in '/snap/core/current' | 21:19 |
| mwhudson | looks promising | 21:19 |
| kyrofa | mwhudson, yeah, the snap name in LP is specific to LP. When it comes to uploading it, it uses the one declared in the YAML | 21:36 |
| mwhudson | kyrofa: makes sense, if i a bit confusing at first | 21:36 |
| kyrofa | Indeed | 21:36 |
| mwhudson | kyrofa: i guess support for auto pushing to tracks from lp is on some trello board somewhere but not yet done? | 21:38 |
| kyrofa | mwhudson, yeah no idea on that one | 21:38 |
| mwhudson | paging cjwatson wgrant etc | 21:39 |
| mwhudson | hmm would also be nice if snap builds dumped out the build environment like sbuild does | 21:47 |
| mwhudson | oh right i guess cleanbuild works with classic snaps now too | 21:47 |
| kyrofa | It should, yes | 21:48 |
| wgrant | mwhudson: Yeah, we're a bit busy atm, but it's on the agenda. | 21:50 |
| mup | PR snapd#2956 opened: interfaces: 'getent' by default; add /etc/ethers to network_{control,observe} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2956> | 21:52 |
| jdstrand | kyrofa: fyi ^ | 21:53 |
| kyrofa | jdstrand, hey thanks! | 21:55 |
| jdstrand | np | 21:55 |
| kyrofa | jdstrand, did you see on the mailing list that I finally learned what was going on with the DNS issues? | 21:55 |
| jdstrand | kyrofa: I did. a cname bug. annoying :\ | 21:55 |
| kyrofa | Indeed | 21:55 |
| jdstrand | kyrofa: but at least the mystery is solved | 21:56 |
| kyrofa | jdstrand, no kidding. Man was I ever confused | 21:56 |
| jdstrand | ssweeny: fyi, this is committed now: https://github.com/snapcore/snapd/pull/2945/files#diff-52246fa9c4d8b0b81c71014fbec7b1b6R91 | 22:03 |
| mup | PR snapd#2945: interfaces: miscellaneous policy updates for unity7, udisks2 and browser-support (LP: #1667480) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2945> | 22:03 |
| cjwatson | mwhudson: yep, I'm due to talk with Facu about it when not entirely swamped with MWC | 22:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!