| mup | PR snapd#2970 opened: Add support for retrieving snap history from API <Created by justincan> <https://github.com/snapcore/snapd/pull/2970> | 03:02 |
|---|---|---|
| mup | PR snapcraft#1165 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1165> | 04:01 |
| mup | PR snapcraft#1167 opened: tests:install wget in the container that triggers the beta tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1167> | 04:01 |
| === nhaines_ is now known as nhaines | ||
| mup | PR snapd#2959 closed: data: re-add snapd.refresh.{timer,service} with weekly schedule <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2959> | 07:07 |
| mup | PR snapd#2971 opened: data: ship "snap.mount" service that ensures /snap is MS_SHARED <Created by mvo5> <https://github.com/snapcore/snapd/pull/2971> | 07:23 |
| mup | PR snapd#2972 opened: cmd/libsnap: add sc_quote_string <Created by zyga> <https://github.com/snapcore/snapd/pull/2972> | 08:15 |
| mup | PR snapd#2973 opened: cmd/snap-confine: use sc_do_mount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2973> | 08:57 |
| mup | PR snapcraft#1168 opened: Add support for 7-zip sources <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1168> | 09:21 |
| === JamesTait is now known as Guest34673 | ||
| === Guest34673 is now known as JamesTait | ||
| pshod | installedsnappy ubuntu for pi3 | 10:02 |
| pshod | able to ssh into it with my sso login | 10:02 |
| pshod | how do i install my snaps developed at host | 10:02 |
| pshod | ? | 10:02 |
| mup | Bug #1669329 opened: "error: cannot install snap has changes in progress" should exit >1 <Snappy:New> <https://launchpad.net/bugs/1669329> | 10:07 |
| ogra_ | pshod, snap install ... | 10:14 |
| pshod | i would also want to develop for the pi3 | 10:16 |
| pshod | can i scp my snap into the pi? | 10:16 |
| ogra_ | well, unless your snap only contains shell scripts you probably want to build on the pi to get the binaries built for the armhf architecture | 10:18 |
| ogra_ | you can easily set up a classic development environment on the pi: | 10:18 |
| ogra_ | snap install classic --devmode --edge | 10:18 |
| ogra_ | sudo classic | 10:18 |
| pshod | i want to build for the pi arch so either i will have to develop on board or using alaunchpad project | 10:18 |
| ogra_ | then ... in the classic shell ... sudo apt update and you are good to go ... it behaves like any other ubuntu in there | 10:19 |
| pshod | building on board sounds better | 10:19 |
| pshod | why whould i sudo apt update? | 10:19 |
| ogra_ | to exit the classic shell you can just hit ctrl-d (or type exit) ... to enter it again just run "sudo classic" again | 10:19 |
| pshod | if release my snap onto edge or beta | 10:20 |
| pshod | then i can use only snap install | 10:20 |
| ogra_ | the classic shel gives you a deb based system ... you can apt install snapcraft to build snaps | 10:20 |
| pshod | yes yes | 10:20 |
| ogra_ | the shell shares the same home dir with the outside snap system | 10:20 |
| pshod | doesnt that bring in security vulnerablities? | 10:21 |
| ogra_ | so once you built your snap inside the classic shell, you exit it and run snap install /path/to/your.snap to install it | 10:21 |
| ogra_ | only if you give people full access to the board :) | 10:21 |
| pshod | if i develop there then I wont have to publish my snap too | 10:22 |
| pshod | hmmmm | 10:22 |
| pshod | i can always remove the classic env | 10:22 |
| pshod | right? | 10:22 |
| ogra_ | (teh classic shell cant run system daemons (well, it can if you manually start them for dev. purposes, but they wont auto-start)) | 10:22 |
| ogra_ | just snap remove classic and it is all gone | 10:22 |
| pshod | before sending it to production i would do that then | 10:22 |
| pshod | ogra: remember _prasen_? | 10:23 |
| pshod | i guess that is the user name i was using | 10:23 |
| ogra_ | if it is a larger project launchpad is surely better for building and all ... but for quick iteration and development on the board the classic shell is the best option | 10:23 |
| ogra_ | yup, i do :) | 10:23 |
| pshod | trying to run core on a vm | 10:23 |
| pshod | well I have got the pi now | 10:23 |
| pshod | :D | 10:23 |
| pshod | hey! | 10:24 |
| pshod | hell everything is better outside the office | 10:24 |
| pshod | took the pi home yesterday | 10:24 |
| pshod | was able to do some stuff | 10:24 |
| pshod | brought it back | 10:24 |
| pshod | network proxy and lack of hdmi monitor | 10:25 |
| pshod | :'( | 10:25 |
| ogra_ | sad | 10:26 |
| pshod | yes | 10:30 |
| Rumple | I have a package stuck on 'Manual review pending', and can't push a new version - which would fix the review issue. The same issue as in https://bugs.launchpad.net/snapcraft/+bug/1632136 | 10:56 |
| mup | Bug #1632136: Releasing a new snap is blocked by a previous uploading pending manual review <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1632136> | 10:56 |
| Rumple | Can the 'Manual review pending' revision be removed? The package is fancon | 11:06 |
| mup | PR snapd#2954 closed: overlord: phase 2 with 2nd setup-profiles and hook done after restart for core installation <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2954> | 11:30 |
| mup | PR snapd#2974 opened: many: add new (hidden) `snap debug ensure-state-soon` command and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2974> | 11:31 |
| mup | PR snapd#2975 opened: overlord/snapstate: small cleanup of ensureForceDevmodeDropsDevmodeFromState <Created by chipaca> <https://github.com/snapcore/snapd/pull/2975> | 11:57 |
| gbisson_ | hi all, what's the latest stable core version/rev of snappy? | 13:09 |
| gbisson_ | I built an image for my platform (i.MX6Q) and get core 16-2 1292 canonical - | 13:09 |
| === gbisson_ is now known as gbisson | ||
| gbisson | however when I look at RPi3 I get: core 16-2 1267 canonical - | 13:10 |
| gbisson | (even after a snap refresh) | 13:10 |
| gbisson | why aren't the two revisions aligned? | 13:10 |
| ogra_ | gbisson, run snap info core on both of them ;) | 13:11 |
| ogra_ | i assume you use different channels (unless they are actually different arches ... i.e. arm64 vs armhf) | 13:12 |
| gbisson | ogra_: thanks yes my boards tracks beta... | 13:13 |
| ogra_ | i'd use edge while doing development | 13:14 |
| gbisson | whereas rpi follows stable which makes sense | 13:14 |
| gbisson | ogra_: thanks for the quick reply | 13:14 |
| ogra_ | (it rarely breaks) | 13:14 |
| gbisson | well the problem I have with beta it that I can't install snapwbe | 13:14 |
| gbisson | snapweb | 13:14 |
| ogra_ | oh ? | 13:14 |
| ogra_ | whats the error ? | 13:14 |
| gbisson | error: cannot install "snapweb": snap "snapweb" has changes in progress | 13:14 |
| gbisson | so I'd rather stick to the stable version ;) | 13:15 |
| ogra_ | and snap changes ? what does it tell ?? | 13:15 |
| ogra_ | (you can see details with "snap change $changenumber") | 13:15 |
| gbisson | http://pastebin.com/TqkCk936 | 13:16 |
| gbisson | nothing about snapweb I think | 13:16 |
| ogra_ | Error 2017-03-01T17:39:40Z 2017-03-01T17:39:49Z Install "webdm" snap | 13:16 |
| gbisson | then I tried webdm | 13:16 |
| gbisson | but it's not the same right? | 13:16 |
| ogra_ | no, indeed | 13:16 |
| gbisson | I have to say webdm/snapweb is confusing | 13:16 |
| ogra_ | webdm was the old name of snapweb | 13:16 |
| gbisson | depending on the website you read it's either one or the other that is mentioned | 13:17 |
| gbisson | how can I clear the snap changes ? | 13:17 |
| ogra_ | well, old docs might still mention webdm | 13:17 |
| gbisson | how can I switch to stable channel for core? | 13:17 |
| ogra_ | sure | 13:17 |
| ogra_ | snap refresh core --stable | 13:17 |
| gbisson | error: cannot refresh "core": snap "core" has changes in progress | 13:18 |
| gbisson | I'm cursed | 13:18 |
| gbisson | 1 Doing 2017-03-01T17:06:27Z - Initialize system state | 13:19 |
| gbisson | isn't this stuck somehow? | 13:19 |
| ogra_ | looks like | 13:19 |
| ogra_ | how did you create that image ... looks like there are issues with it | 13:20 |
| gbisson | yes I'll check that process, thanks for the precious feedback | 13:20 |
| ogra_ | not properly signed assertion, broken gadget or some such | 13:20 |
| gbisson | yes it's weird cause I don't see my kernel snap | 13:20 |
| ogra_ | yeah, that definitely means it wasnt properly initialized | 13:20 |
| gbisson | yep, I'll let you know, thanks! | 13:21 |
| ogra_ | core, kernel and gadget should always be there before you do anything | 13:21 |
| ogra_ | else it would install a core ... rthats definitely worng | 13:21 |
| jdstrand | mvo: thanks for reviewing and merging my branches yesterday :) | 14:32 |
| mup | PR snapd#2714 closed: interfaces: interface to allow autopilot introspection <Created by sbaldassin> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2714> | 14:57 |
| mterry | didrocks: looks like in snapd trunk, the content: field for content interfaces is now mandatory -- so that bit of doc in snapcraft-desktop-helpers might need updating to include it | 15:24 |
| didrocks | mterry: hum, is that an error? on the spec it's told that content is implicitely plugname is not named | 15:25 |
| didrocks | unsure if zyga is around ^ | 15:26 |
| didrocks | if so, it's a regression compared to previous behavior | 15:26 |
| mterry | agreed it's a regression compared to before | 15:30 |
| mup | PR snapd#2969 opened: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 15:30 |
| mterry | But spec is correct for latest stable release at least | 15:30 |
| mterry | Just won't be soon | 15:30 |
| didrocks | mterry: mind opening a bug? :) | 15:31 |
| didrocks | should be high/critical before release | 15:31 |
| didrocks | mvo: ^ | 15:31 |
| didrocks | let's avoid that regression | 15:31 |
| jdstrand | morphis: hey, fyi https://github.com/snapcore/snapd/pull/2969. This is the PR I was talking about last week | 15:32 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 15:32 |
| morphis | jdstrand: oh nice | 15:32 |
| mterry | didrocks: https://bugs.launchpad.net/snappy/+bug/1669476 | 15:33 |
| mup | Bug #1669476: content: piece of content interfaces now mandatory in trunk <Snappy:New> <https://launchpad.net/bugs/1669476> | 15:33 |
| mup | Bug #1669476 opened: content: piece of content interfaces now mandatory in trunk <Snappy:New> <https://launchpad.net/bugs/1669476> | 15:33 |
| didrocks | mterry: commented, thanks! I hope mvo is going to have a look at it | 15:35 |
| mup | Bug #1669477 opened: Snap installed as devmode can end up running confined <Snappy:New> <https://launchpad.net/bugs/1669477> | 15:36 |
| morphis | jdstrand: btw. I am going to hook up our CI soon so it runs nightly against edge for the core snap so that we spot problems early on | 15:38 |
| pedronis | didrocks: which spec? | 15:46 |
| jdstrand | morphis: that sounds great :) | 15:56 |
| mup | PR snapd#2967 closed: tests: remove workaround for docker again, snap-declaration is fixed now <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2967> | 16:02 |
| amosbird | hi | 16:30 |
| amosbird | does snap support centos 6? | 16:31 |
| ogra_ | amosbird, https://github.com/snapcore/snapd/wiki/Distributions | 16:33 |
| amosbird | hmm | 16:34 |
| mvo | didrocks: looking now | 16:36 |
| mvo | didrocks: I will look over the code, I don't remember reviewing that | 16:36 |
| didrocks | mvo: thanks! | 16:38 |
| cvldrg | Hi, would anyone help me to install wget or curl with snao ? | 17:43 |
| joc | elopio: hi, do you think the plainbox-provider plugin PR will be ok to go in next snapcraft release? | 18:03 |
| elopio | joc: oh, I hope so. I'm seeing that the test error is not related to your change. I'll hit update to get a fresh run. | 18:06 |
| joc | elopio: great, thank you | 18:07 |
| jdstrand | tyhicks: hey, wondering if you would have time to review the description and my comments in this PR: https://github.com/snapcore/snapd/pull/2969 (ie, don't need a code review yet (unless you want to), just verify the approach and advise on my comment) | 18:10 |
| mup | PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969> | 18:10 |
| mup | PR # closed: snapd#2230, snapd#2302, snapd#2592, snapd#2624, snapd#2644, snapd#2749, snapd#2752, snapd#2782, snapd#2787, snapd#2793, snapd#2837, snapd#2855, snapd#2869, snapd#2877, snapd#2895, snapd#2929, snapd#2930, snapd#2932, snapd#2938, snapd#2941, snapd#2942, snapd#2944, snapd#2947, | 18:10 |
| mup | snapd#2950, snapd#2951, snapd#2952, snapd#2953, snapd#2963, snapd#2969, snapd#2970, snapd#2971, snapd#2972, snapd#2973, snapd#2974, snapd#2975 | 18:10 |
| genii | Whoa | 18:10 |
| jdstrand | tyhicks: if now isn't convenient, I have other things I can work on | 18:10 |
| mup | PR # opened: snapd#2230, snapd#2302, snapd#2592, snapd#2624, snapd#2644, snapd#2749, snapd#2752, snapd#2782, snapd#2787, snapd#2793, snapd#2837, snapd#2855, snapd#2869, snapd#2877, snapd#2895, snapd#2929, snapd#2930, snapd#2932, snapd#2938, snapd#2941, snapd#2942, snapd#2944, snapd#2947, | 18:11 |
| mup | snapd#2950, snapd#2951, snapd#2952, snapd#2953, snapd#2963, snapd#2969, snapd#2970, snapd#2971, snapd#2972, snapd#2973, snapd#2974, snapd#2975 | 18:11 |
| tyhicks | jdstrand: how come you were thinking that netlink_sendmsg() doesn't call out to the LSM in some situations? | 18:18 |
| mup | PR snapd#2977 opened: releasing package snapd version 2.23 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2977> | 18:18 |
| tyhicks | I quickly walked through netlink_sendmsg() but don't see any short circuits for the root user | 18:18 |
| tyhicks | jdstrand: oh, I think I see it now | 18:19 |
| * tyhicks reads | 18:19 | |
| jdstrand | tyhicks: early in the function. search for -EPERM | 18:20 |
| tyhicks | jdstrand: that's equiv to DAC being applied before MAC (the only time the LSM isn't called is when the user doesn't have CAP_NET_ADMIN and the sendmsg() fails) | 18:21 |
| jdstrand | tyhicks: yes | 18:22 |
| tyhicks | jdstrand: ah! I thought you were saying that LSM is bypassed in some non-error conditions | 18:22 |
| tyhicks | I misunderstood | 18:22 |
| jdstrand | tyhicks: no. I was only saying that I observed socket(AF_NETLINK, ..., NETLINK_ROUTE) as root did not go through the lsm | 18:23 |
| tyhicks | ok | 18:23 |
| tyhicks | I need to go back and read the first comment in the PR | 18:23 |
| tyhicks | there looks to be a good amount to digest so it'll take me a little bit | 18:24 |
| jdstrand | tyhicks: because if I remove 'socket AF_NETLINK - NETLINK_ROUTE', I get a seccomp denial. if I add it, I get no apparmor denial for a lack of 'network netlink ...,' rule | 18:24 |
| tyhicks | jdstrand: ok, I'm still missing some context on why you think the netlink-audit and netlink-connector "escape hatches" are needed | 18:33 |
| tyhicks | I can say that NETLINK_AUDIT will be needed by any trusted helpers that audit through the audit subsystem (dbus-daemon is an example) | 18:36 |
| jdstrand | tyhicks: currently, NETLINK_AUDIT is only in account-control. I did a rdepends on libaudit1 and there was enough there that made me feel like a 3rd party app may try to use it | 18:37 |
| jdstrand | tyhicks: and we wouldn't want something that simply uses 'python-audit' to be able to create user accounts | 18:38 |
| tyhicks | jdstrand: ok, I understand the desire for netlink-audit | 18:38 |
| tyhicks | jdstrand: you didn't justify netlink-connector very much | 18:39 |
| tyhicks | jdstrand: it has been years since I looked at NETLINK_CONNECTOR but I don't remember anything using it | 18:39 |
| jdstrand | tyhicks: NETLINK_CONNECTOR isn't used in any of the policy, but I saw it in a few places on codesearch | 18:40 |
| jdstrand | lvm2, ulatencyd, ruby-god, powerstat and v86d | 18:40 |
| jdstrand | and stress-ng | 18:41 |
| tyhicks | jdstrand: ok, that makes some sense but note that we won't be able to mediate individual NETLINK_CONNECTOR users | 18:42 |
| jdstrand | tyhicks: my concern is that we had a bare socket rule before and that all accesses aren't going through the lsm. I was hoping every AF_NETLINK would need a corresponding 'network netlink <type>' rule, but at least with NETLINK_ROUTE, that isn't the case | 18:42 |
| tyhicks | jdstrand: from what I remember, it is just a common transport mechanism and anything that we can NETLINK_CONNECTOR access to will be able to set up a side channel | 18:42 |
| tyhicks | s/that we can/that we grant/ | 18:43 |
| jdstrand | tyhicks: right, which is why I thought a separate interface that requires manual connection would be good | 18:43 |
| jdstrand | same with audit | 18:43 |
| mup | PR snapcraft#1169 opened: tests: update the ftp source for integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1169> | 18:43 |
| tyhicks | well, not quite the same | 18:43 |
| tyhicks | I think the routing for NETLINK_CONNECTOR is done based on the addr.nl_groups value | 18:44 |
| jdstrand | tyhicks: because we are now mediating all socket(AF_NETLINK, ...) socket calls, I wanted to make sure people had a way to do what they could do before | 18:44 |
| jdstrand | tyhicks: all I meant by same was the base declaration requires manual connection | 18:44 |
| tyhicks | ah, gotcha | 18:45 |
| jdstrand | tyhicks: is that a +1 on netlink-audit and netlink-connector? | 18:47 |
| tyhicks | jdstrand: still confused about one thing... the java server that hit the NETLINK_ROUTE seccomp denial worked fine after you added the seccomp rule even thought you didn't add an apparmor rule? | 18:48 |
| jdstrand | tyhicks: that is precisely correct, which was puzzling. I did not chase down why | 18:48 |
| tyhicks | jdstrand: ok, +1 on both (I'll leave a comment) but I'm going to spend a little bit of time looking at the NETLINK_ROUTE code path | 18:50 |
| jdstrand | tyhicks: ok, thanks (on both) | 18:54 |
| lazyPower | mvo is my new hero. Holy cow the response time on http://pad.lv/1668659 is intense. Just wanted to stop by and say thanks for all the help both in here and on the bug everyone. | 20:28 |
| === JanC_ is now known as JanC | ||
| jhodapp | Is there a standard place that I should put a custom wrapper script in for an app for my snap's source tree? | 21:20 |
| kyrofa | jhodapp, nope, it's completely your playground! | 21:21 |
| kyrofa | jdstrand, I typically just put stuff like that in a bin/ dir in the root of the snap | 21:21 |
| jhodapp | kyrofa, so putting it in snap/ is not bad? I heard that snap/ is starting to become standard directory for other things | 21:21 |
| kyrofa | jdstrand, sorry, I meant jhodapp | 21:21 |
| jhodapp | it's ok, that happens to jdstrand and me all the time :) | 21:21 |
| kyrofa | jhodapp, I'm just so used to typing his nick! :P | 21:22 |
| kyrofa | jhodapp, anyway, you're right-- snap is actually not the best place | 21:22 |
| kyrofa | jhodapp, snapcraft likes to own that dir | 21:22 |
| jhodapp | ok, I saw another snap use it and I copied that...so I'll make sure to move away from that | 21:22 |
| jhodapp | thanks kyrofa | 21:22 |
| kyrofa | jhodapp, so you're not asking about where it should be the _final_ snap so much as asking for recommendations about how to organize your source tree? | 21:22 |
| jhodapp | kyrofa, yes exactly | 21:23 |
| kyrofa | jhodapp, I typically make a src/ directory, with a subdirectory for each part | 21:23 |
| jhodapp | kyrofa, hmm interesting | 21:23 |
| jhodapp | kyrofa, this might be something to start recommending...maybe a blog post or whatnot | 21:24 |
| kyrofa | jhodapp, yeah, perhaps elopio and I could put together a weekly "tips and tricks" post of some kind | 21:25 |
| jhodapp | kyrofa, would love that...snaps are so powerful with so much choice...knowing best practices would be *very* helpful | 21:26 |
| jhodapp | kyrofa, to take off of Effective C++, could be an Effective Snapping series | 21:26 |
| kyrofa | Ah, my favorite book | 21:26 |
| jhodapp | mine too :) | 21:26 |
| kyrofa | jhodapp, you and I need to meet sometime ;) | 21:27 |
| jhodapp | haha, cheers | 21:27 |
| kyrofa | Hmm. That came off creepier than I anticipated | 21:27 |
| jhodapp | no I got your gist ;) | 21:27 |
| jhodapp | no worries | 21:27 |
| kyrofa | Hahaha | 21:27 |
| kyrofa | elopio, how do you feel about something along those lines? ^^ | 21:27 |
| jdstrand | mwhudson: fyi, I approved your snap, but you need to release it still | 21:39 |
| mwhudson | jdstrand: thanks | 21:39 |
| mwhudson | huh snap install core in my lxd container downloads 5 megs really quickly then fails | 22:03 |
| mwhudson | outside the container it is much slower but appears to be working? | 22:03 |
| mwhudson | oh no, snap download core in the container is slow and working too | 22:04 |
| mwhudson | hm if i've run snap download, how do i make snapd see the assertions file? | 22:08 |
| kyrofa | mwhudson, snap ack | 22:09 |
| kyrofa | mwhudson, then you can just `snap install` without --dangerous | 22:09 |
| mwhudson | kyrofa: oh of course | 22:10 |
| mwhudson | mount: wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1395.snap, | 22:11 |
| mwhudson | eh what | 22:11 |
| kyrofa | mwhudson, do you have squashfuse? | 22:11 |
| mwhudson | yes | 22:11 |
| kyrofa | mwhudson, you've reached the limit of my expertise :P | 22:11 |
| kyrofa | (I've not tried this before) | 22:12 |
| mwhudson | i'm trying to reproduce that thing where classic snap builds on !amd64 don't work | 22:13 |
| mwhudson | "interpreter /snap/core/current/i386-linux-gnu/ld-2.23.so" | 22:15 |
| mwhudson | that path looks pretty unlikely | 22:15 |
| mwhudson | it's missing a /lib | 22:15 |
| mwhudson | because someone didn't understand how symlink resolution works?? | 22:17 |
| kyrofa | Hmm... it actually looks like i386 is missing the core-dynamic-linker field all-together | 22:18 |
| kyrofa | So it does a readlink on /snap/core/current/lib/ld-linux.so.2 and appends that to /snap/core/current | 22:21 |
| kyrofa | Which of course won't work if the link is relative | 22:22 |
| kyrofa | mwhudson, is that what you're talking about? | 22:22 |
| mwhudson | kyrofa: yes | 22:25 |
| kyrofa | Yeah, it should make that link relative to the core path before appending back onto it | 22:26 |
| mwhudson | uh i hope /lib/ld-linux.so.2 is always a symlink | 22:30 |
| kyrofa | Indeed | 22:31 |
| mwhudson | oh readlink raises if it's not a symlink | 22:43 |
| mwhudson | that's at least confusing than if it just returned its argument | 22:44 |
| mwhudson | *less confusing | 22:44 |
| elopio | kyrofa: +1. Like a short post of a couple of paragraphs? Or like a tutorial to snap something from 0, including an interesting detail? | 22:59 |
| kyrofa | elopio, I was thinking something relatively short and sweet. The Effective Snapping idea was excellent | 23:00 |
| mwhudson | https://github.com/snapcore/snapcraft/pull/1170 | 23:01 |
| mup | PR snapcraft#1170: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170> | 23:01 |
| mup | PR snapcraft#1170 opened: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170> | 23:02 |
| kyrofa | Thanks for that mwhudson | 23:02 |
| mwhudson | after the amount of time i spent figuring out what was going on, the least i can do is save anyone else from the pain | 23:02 |
| mwhudson | now can i have the fix on launchpad pls? :) | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!