| === JoshStrobl is now known as JoshStrobl|zzz | ||
| === akash_ is now known as akash | ||
| === clemensv__ is now known as clemensv | ||
| === psftw_ is now known as psftw | ||
| === DedSec__ is now known as DedSec_ | ||
| mup | Bug #1721676 opened: implement errno action logging in seccomp for strict mode with snaps <Snappy:In Progress by tyhicks> <linux (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu | 02:18 |
|---|---|---|
| mup | Xenial):In Progress by tyhicks> <linux (Ubuntu Zesty):In Progress by tyhicks> <linux (Ubuntu Artful):Fix Released by tyhicks> <https://launchpad.net/bugs/1721676> | 02:18 |
| mup | PR snapcraft#1585 closed: lxd: pass SNAPCRAFT_PARTS_URI through into container <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1585> | 02:24 |
| mup | PR snapd#4009 opened: tests: adding test for network-manager interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4009> | 02:45 |
| mup | PR snapcraft#1593 opened: catkin tools plugin: add catkin tools support <Created by cratliff> <https://github.com/snapcore/snapcraft/pull/1593> | 03:39 |
| zyga-fedora | o/ | 06:43 |
| zyga-fedora | tests are sad today | 06:43 |
| zyga-fedora | travis has some issues | 06:43 |
| kalikiana | o/ | 07:12 |
| zyga-fedora | hey kalikiana | 07:15 |
| mup | PR snapcraft#1484 closed: lxd: configure user in container <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1484> | 07:24 |
| mup | PR snapd#4010 opened: tests: do not use http://canihazip.com/ which appears to be down <Created by mvo5> <https://github.com/snapcore/snapd/pull/4010> | 07:30 |
| ackk | hi, I'm getting these errors when running snapd tests in master: http://paste.ubuntu.com/25684549/ | 07:39 |
| ackk | they take a long time to run and eventually hang | 07:39 |
| __chip__ | ackk: you're needing some dependencies | 08:03 |
| __chip__ | ackk: what system are you running the tests on? | 08:03 |
| __chip__ | what distro i mean | 08:03 |
| ackk | __chip__, yakkety | 08:03 |
| __chip__ | ackk: sudo apt build-dep ./ | 08:03 |
| ackk | __chip__, thanks | 08:04 |
| __chip__ | ackk: and ./run-checks might be more helpful than running go test by hand | 08:04 |
| __chip__ | ackk: OTOH running go test by hand you can add a "-timeout 15s" :-) | 08:05 |
| __chip__ | (go test's default timeout is 10 minutes i think?) | 08:05 |
| __chip__ | ackk: that unit test is failing because KB vs KiB -- means you're using a different version of chegggaa's progress bar lib, there (but run-checks should sort that out for you | 08:07 |
| mup | PR snapd#4010 closed: tests: do not use http://canihazip.com/ which appears to be down <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4010> | 08:12 |
| ackk | __chip__, thanks, running now | 08:13 |
| __chip__ | ackk: run-checks will set the right gopath, then use govendor to get the right libs in place, etc | 08:13 |
| __chip__ | via get-deps | 08:14 |
| __chip__ | ackk: also it'll run some static checks | 08:14 |
| ackk | yeah, some shellcheck is failing here | 08:14 |
| ackk | might be the different shellcheck version | 08:14 |
| ackk | __chip__, do you guys run it on xenial usually? | 08:14 |
| __chip__ | ackk: your shellcheck is probably too old | 08:15 |
| __chip__ | ackk: yes, xenial, but with shellcheck from zesty at least | 08:15 |
| __chip__ | ackk: you can't just install the one from zesty, but you can rebuild the zesty one for yakkety) | 08:16 |
| __chip__ | ackk: or, you can remove it and it won't complain -- it'll only run shellcheck if available | 08:16 |
| ackk | yeah I disabled the check | 08:18 |
| ackk | tests are running now | 08:18 |
| ackk | __chip__, passed! thanks | 08:19 |
| __chip__ | ackk: does the older shellcheck have a -V option? | 08:19 |
| ackk | yes | 08:20 |
| ackk | 0.4.4 fwiw | 08:20 |
| __chip__ | ackk: the deeper tests are run via spread, for which you'll need that and kvm | 08:20 |
| __chip__ | ackk: hey, i've got 0.4.4 and last i checked they passed | 08:20 |
| __chip__ | so maybe something snuck in | 08:20 |
| __chip__ | i'll take a look | 08:20 |
| __chip__ | ackk: 0.4.4 _should_ work (so i was wrong and it's the one from Y not Z that we use) | 08:20 |
| __chip__ | ackk: WRT the spread tests, https://github.com/snapcore/snapd/blob/master/HACKING.md#running-the-spread-tests | 08:22 |
| __chip__ | one thing it doesn't say is that that .spread directory is in from ~ | 08:22 |
| ackk | __chip__, http://paste.ubuntu.com/25684673/ | 08:22 |
| __chip__ | gah | 08:23 |
| __chip__ | ok, i'll fix | 08:23 |
| ackk | cheers | 08:23 |
| ackk | cool, tests pass in my branch too now :) | 08:25 |
| zyga-fedora | mvo: quiet day, how are you | 10:48 |
| mvo | hey zyga-fedora | 10:49 |
| mvo | zyga-fedora: I'm feeling a bit so-so, maybe getting a cold or something. looks quiet indeed | 10:49 |
| ogra_ | mvo, i saw you answered on the DHCP thread, did you get any info out of your tests ? | 10:49 |
| mvo | ogra_: I can reproduce it reliable using a similar setup as the report but thats all I did so far. I | 10:50 |
| mvo | ogra_: I bet its possible to reproduce with classic as well but I have not spend time on that | 10:50 |
| mvo | ogra_: did you find anything out? it bothers me a great deal | 10:51 |
| ogra_ | yeah, i bet it is systemd-networkd and it simply isnt seen elsewhere because we only use it in core in xenial | 10:51 |
| ogra_ | mvo, not really, which is why i was hoping xnox could give some hints what to look for ... | 10:52 |
| ogra_ | (but he didnt like to :P ) | 10:52 |
| mvo | ogra_: right, it seems like hte issue is in a bit of a limbo | 10:53 |
| xnox | ogra_, i've requested steps to reproduce, logs, and /run state - i got nothing back in return. Also my work pipeline is full of customer work, and if you have things to escalate to foundations, it should be done via salesforce as it is done for all the other customer work. | 10:55 |
| xnox | ogra_, networkd is used on xenial on some cloud images in production | 10:55 |
| xnox | but cloud images typically have stable/non-changing dhcp | 10:55 |
| ogra_ | xnox, well, customer or not ... it is an issue for eveyone (just that others dont use core in a way that triggers this bug) | 10:56 |
| ogra_ | i dont see why a serious bug is any different if a customer reports it, a bug is a bug is a bug ;) | 10:57 |
| jamespage | o/ | 11:00 |
| jamespage | any chance on the track setup detailed under https://forum.snapcraft.io/t/track-request-for-openstack-projects/2377 for the gnocchi snap - I'm working on testing that atm and installing from the default track is awkward for my charm | 11:00 |
| ogra_ | 100% sure, but i think it needs three) | 11:02 |
| ogra_ | argh | 11:03 |
| ogra_ | jamespage, i think that needs a third +1 first (not 100% sure, but i think it needs three) | 11:03 |
| jamespage | ogra_: ack - anyone around who can do a third +1 ? | 11:03 |
| === JoshStrobl|zzz is now known as JoshStrobl | ||
| xnox | ogra_, sure a bug is a bug.... but i have 4 srus of systemd in progress, all of which fix critical bugs for $cloud $another_cloud $this_person $that_person =) | 11:13 |
| xnox | ogra_, and this dhcp issue is incomplete, as i'm yet to receive "steps to reproduce, logs, /run state" as requested a few days back. Do you have that for me? | 11:13 |
| ogra_ | did you ask for that in the bug ? | 11:14 |
| xnox | without that, there is nothing i, or anybody on my team, can do, to start picking that bug up | 11:14 |
| * ogra_ checks | 11:14 | |
| xnox | ogra_, i've asked that _from you_ when you first pinged me about it | 11:14 |
| xnox | ogra_, and again mvo | 11:14 |
| xnox | ogra_, harrasing customer around is not a good idea. | 11:14 |
| ogra_ | no, you asked me to please turn the forum thread into a bug report | 11:14 |
| ogra_ | which i asked the OP to do (and he did) | 11:14 |
| xnox | ogra_, but then it somehow escalated with multiple people pinging me and my manager. | 11:15 |
| xnox | ogra_, are you aware of the process for UA customers? and the use of salesforce? | 11:15 |
| ogra_ | xnox, well, NCuralli pinged here first but got no reaction | 11:15 |
| ogra_ | xnox, i dont care about customers if such a bug shows up, it is a serious issue no matter who was the original reporter | 11:16 |
| ogra_ | xnox, if it is a customer request i would expect it to go through the dedicated business coontacts ... but this is a generic bug in one of your products and was generically reported | 11:18 |
| xnox | ogra_, i understand that. but my time is limited and it is prioritised within the work my team commits to fix. | 11:18 |
| xnox | ogra_, we do not drop everything on the floor and fix your issue. | 11:18 |
| ogra_ | i dont expect that ... | 11:18 |
| ogra_ | but after being asked to turn it into a proper bug report a one line comment on the bug that it was recognized would have been nice ... completely independent from any processes just by common sense | 11:20 |
| xnox | ogra_, for whatever reasons there were multiple people, managers and tams pressuring and pinging my manager to somehow escalate this particular issue | 11:20 |
| xnox | ogra_, i'm concerned why that has happened. have you been talking to anybody about this particular issue? somehow it was artficially inflated. | 11:20 |
| NCuralli | @ogra @xnox what could I make for you? | 11:25 |
| nothal | NCuralli: No such command! | 11:25 |
| NCuralli | ogra_ xnox what could I make for yours? | 11:26 |
| ogra_ | NCuralli, xnox wants "steps to reproduce, logs, and /run state" (quoting from above) ... but prhaps mvo can give that tooo since he can reproduce | 11:29 |
| xnox | NCuralli, i am interested to see the journal and copies of /run/systemd/netif/ directory between all the leases are obtained/changed. as that directory has serialised state of lease files. | 11:31 |
| xnox | NCuralli, comparing that, with logs, and server side leases logs - we can establish where things go wrong in terms of lease renewals and changes. | 11:31 |
| mup | PR snapcraft#1554 closed: store: handle revoked developers <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1554> | 11:31 |
| NCuralli | ogra can mvo take care of xnox requests? | 11:36 |
| NCuralli | ogra_ can mvo take care of xnox requests? | 11:36 |
| NCuralli | ogra_ if mvo can not. I can take of xnox requests | 11:37 |
| mvo | NCuralli, xnox let me check, I can provide most, I'm not sure about /run/systemd/netif iirc that was not showing up on my pi2 but let me double check (it did show up in my x86 vm) | 11:37 |
| NCuralli | mvo if you need something ping me | 11:39 |
| xnox | mvo, it should if you are using networkd, if the device is using networkmanager it would not. | 11:40 |
| xnox | mvo, i don't know which devices are affected. | 11:40 |
| ogra_ | xnox, all | 11:40 |
| ogra_ | xnox, and by default core uses netplan with networkd only ... no other method preinstalled | 11:40 |
| xnox | mvo, and for networkmanager case it matters if isc-dhcp is installed or not; as networkmanager can either use isc-dhclient or use networkd's dhcp lease. | 11:40 |
| xnox | ogra_, that is not true =)))))) as i am aware of several core devices shipping with netowkrmanager backend | 11:41 |
| xnox | of netplan | 11:41 |
| ogra_ | xnox, well, i'm tallking about all our referenced images | 11:41 |
| ogra_ | there are some customer setups using NM alongside, yes | 11:41 |
| xnox | ogra_, i am talking about the particular bug in question, have you reproduced it on the reference images yet and can provide logs? | 11:42 |
| ogra_ | but they are custiom things ... | 11:42 |
| ogra_ | xnox, not me, but michael | 11:42 |
| ogra_ | xnox, and NCuralli too | 11:42 |
| ogra_ | (also the bug description is pretty clear "we use the default network stack based on networkd + netplan." ) | 11:43 |
| zyga-fedora | wooooooooooot | 12:40 |
| zyga-fedora | man | 12:40 |
| zyga-fedora | I'm terrible | 12:40 |
| zyga-fedora | :) | 12:40 |
| zyga-fedora | but I fixed it | 12:40 |
| __chip__ | zyga-fedora: what did you woot fix? | 12:56 |
| zyga-fedora | just small part of code I was working on | 13:08 |
| zyga-fedora | it's working now | 13:08 |
| * zyga-fedora -> lunch | 13:49 | |
| wdouglass | i'm trying to build a snap package using the snapcraft docker image under debian. When i run 'snapcraft', i get 404 not found for linux-libc-dev libdns-export, and libins-export. i've tried doing 'apt-get update' in my docker container, what else should i try? | 14:06 |
| ogra_ | where do these requirements come from ? your snapcraft.yaml ? | 14:08 |
| wdouglass | i guess python may need them? the package i'm building is a python program that uses the 'python2' build plugin | 14:09 |
| ogra_ | (the latter lib doesnt exist at all in ubuntu, libdns-export has a versioned package name ... ) | 14:09 |
| wdouglass | sorry, it's libdns-export162 | 14:09 |
| ogra_ | linux-libc-dev should simply be there | 14:09 |
| ogra_ | and your docker container runs xenial ? | 14:10 |
| ogra_ | (16.04) | 14:10 |
| wdouglass | yeah, snapcore/snapcraft, distributed by the snapcraft.io tutorial | 14:10 |
| * ogra_ always only uses lxd ... so hard to tell whats wrong there ... theoretically it should work i guess | 14:11 | |
| ogra_ | kalikiana, ^^^ any idea ? | 14:11 |
| wdouglass | hmmm. i guess i could try lxd, i'll bang my head against docker a bit more first | 14:11 |
| kalikiana | wdouglass: does your container have ip4 networking? Somewhat random guess perhaps, but last week I was looking at an aws container that only had ip6 configured and some package downloads failed because of it | 14:16 |
| wdouglass | oh that's interesting, i'll look into that | 14:17 |
| __chip__ | kyrofa: ping | 14:28 |
| ppisati_ | ogra_: i guess you don't rebuild the LK bootloader in the dragonboard gadget, i mean, you reuse the binaries shipped by linaro | 14:32 |
| __chip__ | kyrofa: I read something about you being saddened by having to use --prefix=/snap/yadda/current because it limited cross-distro portability -- but the snap you were talking about is strict, meaning that it doesn't | 14:35 |
| __chip__ | kyrofa: because a strict snap always sees itself installed under /snap/ | 14:35 |
| wdouglass | kalikiana: i needed to run apt update in my container, that was the problem. thanks to you and ogra_ for your help! | 14:36 |
| ogra_ | ppisati_, i think one of ondra's recent changes actually started building two lk's (one for mmc and one for sd) from source | 14:55 |
| ondra | ogra_ ppisati_ no lk is taken from code there, as we do not need to rebuild or modify | 14:56 |
| ondra | ogra_ ppisati_ though I have somewhere code to build it from code as well if needed | 14:57 |
| ondra | so if there is interest I can test it and push it as well | 14:57 |
| ondra | ogra_ I did pull request with fix, since I got one extra dragoboard I could test on | 14:57 |
| ogra_ | ondra, cool, i'll try to get to it before EOD | 14:58 |
| ppisati_ | the patches to modify the bt address require a new property in the dtb, if that property is not present, the driver fails to initialize | 14:58 |
| ondra | ppisati_ dtb is fine, that lives in kernel snap | 14:59 |
| ppisati_ | so, before i commit this stuff, i need a new LK bootloader, else i break the bt on the dragonboard | 14:59 |
| ondra | ppisati_ there shouldn't be need to rebuild lk for that | 14:59 |
| ondra | ppisati_ new lk for changed dtb? | 14:59 |
| ppisati_ | https://git.linaro.org/landing-teams/working/qualcomm/lk.git/commit/?h=release/LA.BR.1.2.7-03810-8x16.0&id=372982a4d4c4922e9214ff7d6aa5348aaba602a7 | 14:59 |
| ppisati_ | yes, it requires this patch | 15:00 |
| ppisati_ | and they havent' built a release since this stuff was committed | 15:00 |
| === longsleep_ is now known as longsleep | ||
| ondra | ppisati_ right | 15:02 |
| ondra | ppisati_ so if needed we can update gadget and start building it | 15:02 |
| ondra | ppisati_ shall I spin for you gadget with patch in the mean time? | 15:02 |
| ogra_ | ppisati_, just compile it yourself and dd the resulting binary to part 7 | 15:03 |
| ogra_ | (for testing at least) | 15:04 |
| ogra_ | lk lives in the "aboot" partition usually | 15:04 |
| ppisati_ | ogra_: testing is already done, what i'm saying is "do you want to rebuild the gadget snap with that patch, or shall we wait for linaro to do another release, you pick the binaries and then i commit my stuff?" | 15:20 |
| ppisati_ | ondra: ^ | 15:20 |
| kyrofa | __chip__, interesting, even on fedora? | 15:22 |
| __chip__ | kyrofa: _inside_ the snap, yes, everywhere | 15:22 |
| __chip__ | kyrofa: of course it's still not ideal because it would break on rename | 15:23 |
| kyrofa | Indeed, but that's an improvement, certainly | 15:23 |
| __chip__ | kyrofa: (you can test this with 'snap run --shell snap.app' on a fedora vm | 15:23 |
| __chip__ | ) | 15:23 |
| __chip__ | kyrofa: devmode snaps also | 15:24 |
| __chip__ | kyrofa: just classic is weird and different and terrible and sad | 15:24 |
| kyrofa | __chip__, amen | 15:24 |
| ondra | ppisati_ we can then just update with new version | 15:48 |
| ondra | ppisati_ if you are inpatient, we can start building it from source | 15:48 |
| ondra | ppisati_ up to you, I can prepare the change | 15:49 |
| ogra_ | ondra, well, there are customers that want to use BT with a proper MAC ... sho we should probably add the lk build to the gadget | 15:53 |
| ogra_ | but thats something for next week IMHO | 15:53 |
| ogra_ | ondra, thanks btw ... it didnt strike me that the magic number error was about the FIT format ... | 15:54 |
| ppisati_ | ogra_: k, no rush | 15:56 |
| ppisati_ | ondra: ^ | 15:56 |
| ondra | ogra_ yeah I missed that communication and when I was reading it today, I realised I only shared gadget snapd, but not kernel snap. So my bad | 15:57 |
| ondra | ppisati_ ogra_ I'm sprinting next week, but if jet lag hits me I might as well prepare it :) | 15:58 |
| ppisati_ | ondra: np | 16:01 |
| __chip__ | mvo: dunno if you noticed but i pushed tests to the ansimeter pr | 16:09 |
| __chip__ | mvo: an' they're all green and lovely-like | 16:09 |
| elopio | stgraber: is it possible now to use the lxd snap without sudo? Just the lxd group? | 16:15 |
| stgraber | elopio: it is | 16:21 |
| * elopio tries in a clean machine. It doesn't work on mine, but mine is always crazy. | 16:29 | |
| elopio | nessita or cprov or somebody: can you please remind me the URL with the docs for store api errors? | 16:33 |
| kyrofa | zyga-fedora, snapd is out of date on arch. Any idea who I poke about that? | 16:46 |
| kyrofa | Looks like it's been flagged, but it's considered an orphan package | 16:48 |
| kyrofa | elopio, curious what you think about https://github.com/snapcore/snapcraft/pull/1583#issuecomment-334620307 | 16:52 |
| mup | PR snapcraft#1583: ament plugin: new plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1583> | 16:52 |
| zyga-fedora | kyrofa: hey | 16:55 |
| zyga-fedora | kyrofa: we know, we are working on resolving this | 16:55 |
| zyga-fedora | kyrofa: for now we are trying to get a person with commit access | 16:55 |
| kyrofa | zyga-fedora, very good, thank you :) | 16:58 |
| * __chip__ ~> EOW | 17:01 | |
| kalikiana | elopio: leaving now, will be idling later, feel free to ping in case I'm needed | 17:16 |
| mvo | Chipaca: I have not noticed, I was digging into this ipv4 problem | 17:28 |
| === JanC_ is now known as JanC | ||
| === ShalokShalom_ is now known as ShalokShalom | ||
| cprov | elopio: https://dashboard.snapcraft.io/docs/ | 18:42 |
| elopio | thanks cprov | 18:43 |
| === JanC is now known as Guest38427 | ||
| === JanC_ is now known as JanC | ||
| wdouglass | hey, i'm trying to package a python program, which works fine on my machine. For some reason in my snap, it can't import numpy.core.multiarray | 19:03 |
| wdouglass | i've got 'python-numpy' in my stage-packages list | 19:03 |
| wdouglass | what else should I be looking at? | 19:04 |
| nacc | wdouglass: is your app python2 or python3? | 19:11 |
| wdouglass | python2 | 19:11 |
| nacc | wdouglass: snapcraft.yaml link? | 19:11 |
| wdouglass | hold on...i'll paste it up | 19:11 |
| wdouglass | https://pastebin.com/xuc9fZfb | 19:12 |
| nacc | wdouglass: i would suggest dropping into your snap's shell (snap run --shell <app>) and then taking a look around | 19:13 |
| nacc | wdouglass: specifically, at that point, run the interpreter and see what sys.path is pointing at | 19:13 |
| nacc | wdouglass: and perhaps see if the numpy modules showed up | 19:14 |
| wdouglass | sounds like a good idea! this is my first day using snappy... thanks for the direction! | 19:14 |
| nacc | wdouglass: np, gl | 19:15 |
| wdouglass | hmmm...python2 isn't installed. I thought it would be an automatic dependancy becuase 'python-version: python2', but apparrently not. there's the problem. thanks again nacc | 19:15 |
| nacc | wdouglass: hrm, it's not in your snap at all? it might be in the core snap | 19:16 |
| wdouglass | can't get to it from the shell....just python2 | 19:16 |
| wdouglass | i mean just python3 | 19:16 |
| nacc | wdouglass: that's odd (to me) | 19:17 |
| wdouglass | yerp, adding python2.7 as a stage-package fixed it. thanks again | 19:21 |
| nacc | wdouglass: interesting, that feels sort of like a bug | 19:28 |
| wdouglass | yeah, seems like that should be in core | 19:28 |
| nacc | wdouglass: or definitely already there if you installed with the python2 plugin | 19:29 |
| nacc | wdouglass: is 'python' available? | 19:29 |
| wdouglass | now that i added 'python2.7' as a stage-package it is, but not by default with the python2 plugin | 19:30 |
| nacc | wdouglass: hrm ok | 19:30 |
| zyga-fedora | jdstrand: hey | 19:38 |
| zyga-fedora | jdstrand: I saw your feedback on 4008 | 19:38 |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| zyga-fedora | jdstrand: do you want me to freeze them for the update process then? | 19:38 |
| zyga-fedora | jdstrand: or what else should we do? | 19:38 |
| zyga-fedora | jdstrand: I'm trying to make a roadmap in landable chunks | 19:38 |
| wdouglass | does stage-packages include dependancies? | 19:45 |
| wdouglass | or do i have to list them all manually? | 19:46 |
| kyrofa | wdouglass, dependencies of the stage-packages are included | 19:47 |
| wdouglass | thanks kyrofa | 19:48 |
| jdstrand | zyga-fedora: not in 4008. yes in the PR when you perform the mount | 20:06 |
| mup | PR core#60 opened: Fix handling of secondary addresses <Created by mvo5> <https://github.com/snapcore/core/pull/60> | 20:18 |
| mvo | ogra_, zyga-fedora (or anyone interessted). if you are still around I would appreciate a review for the above -^ | 20:18 |
| kyleN | I'm trying a build a pi3 image - it fails with "error: cannot find snap "pi2-kernel": snap not found". This used to work on amd64 laptop and on pi3 itself. Now, neither. Is this a known issue, or has someting changed? | 20:32 |
| kyleN | on pi3, "snap find pi2-kernel" does find it, but still image build fails with that message | 20:33 |
| nacc | sergiusens: classic snap, that is calling gpg. gpg on Artful fails (possibly elsewhere) because it is linked against libreadline6, which may or may not exist on the host | 21:00 |
| nacc | sergiusens: http://paste.ubuntu.com/25688146/ | 21:01 |
| nacc | sergiusens: i'm not sure if i need to somehow exec into the core snap so taht works, but someone is reporting affecting them from running within the classic snap | 21:01 |
| nacc | kyrofa: --^ or is that nother case of, if on classic, i really need to build gpg as well? | 21:02 |
| nacc | seems like a real pain that a classic snap can't rely on using anything from the core snap, if so | 21:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!