| === marcoceppi_ is now known as marcoceppi | ||
| === chihchun_afk is now known as chihchun | ||
| === alecu_ is now known as alecu | ||
| === chihchun_afk is now known as chihchun | ||
| oobartez | what's the status of snappy becoming the default package manager in Ubuntu Desktop? anywhere on the net I could find some up-to-date info? | 06:30 |
|---|---|---|
| oobartez | I'm pretty excited about the idea but it's difficult to find a central point with current status, or info on how to get involved in this particular project | 06:42 |
| olli | oobartez, it's currently not plan of record for Ubuntu Desktop | 07:16 |
| olli | once 16.04 is out we might start working on a modern rendition of Ubuntu, which will incorporate technologies from the phone and be snappy based, but there is no specific & detailed plan yet | 07:17 |
| oobartez | ok, I understand it's a long haul, in the mean time I also found this: http://ubuntuforums.org/showthread.php?t=2312045&p=13432475#post13432475 | 07:24 |
| oobartez | still, I personally find it super interesting. are there any conceptual discussions going that I could dig through? | 07:24 |
| anpok_ | hm where is an up to date documentation on writing an oem snap? | 07:33 |
| anpok_ | the doc in developer.ubuntu.com/en/snappy/guides/oem differs from examples in http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files | 07:35 |
| anpok_ | is it gadget or oem currently? | 07:38 |
| anpok_ | whats the immutable-config good for? | 07:38 |
| === dvladar_ is now known as dvladar | ||
| dholbach | good morning | 08:07 |
| JamesTait | Good morning all! Happy Thursday, and happy Create a Vacuum Day! 😃 | 09:33 |
| anpok_ | oem_snap/bananapi_1.0_all.snap failed to install: Signature verification failed: No signatures, or no origin signature. (exit code 10) | 09:41 |
| anpok_ | trying to create a new image using a just recently created oem snap.. | 09:41 |
| === kickinz1 is now known as kickinz1-sprint | ||
| === kickinz1 is now known as kickinz1-sprint | ||
| noizer | Hi, I want to make some services in snapcraft 2.1 but when I do that it tells met services was unexpected | 10:54 |
| noizer | http://pastebin.com/zmisT1nt | 10:56 |
| noizer | thats a part of my yaml | 10:56 |
| noizer | any clues | 10:56 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | hey beuno, do you know when the new reviewers tools will land in myapps? I think all new snaps are being rejected right now? at least the one I uploaded with 'snapcraft upload' got rejected. | 11:51 |
| beuno | dholbach, hi. Rejected with what message? | 11:58 |
| dholbach | - meta/readme.md does not exist lint_snappy_readme.md | 11:59 |
| dholbach | - (NEEDS REVIEW) squashfs pkg lint_is_squashfs | 11:59 |
| dholbach | - unknown entries in package.yaml: 'apps,description,summary' lint_snappy_unknown | 11:59 |
| dholbach | with the most recent reviewers tool I think most of the above are fixed | 11:59 |
| dholbach | beuno: ^ | 12:00 |
| beuno | dholbach, the readme is fixed, but I don't think squashfs verification has landed yet, has it? | 12:02 |
| sergiusens | dholbach, hmm, there shouldn't be a package.yaml | 12:03 |
| dholbach | sergiusens: lp:~dholbach/+junk/moon-buggy is what I tried to upload with 'snapcraft upload' | 12:04 |
| beuno | dholbach, I think we'll need a week or so more until 16.04 snaps auto-approve | 12:06 |
| dholbach | ok | 12:08 |
| dholbach | auto-uploaded auto-approving snaps would be something really nice to demo :) | 12:09 |
| beuno | dholbach, yes indeed :) | 12:15 |
| sergiusens | dholbach, maybe clean and rebuild, I don't see package.yaml in the latest snapcraft builds | 12:15 |
| kyrofa | Good morning | 12:15 |
| noizer | Hi | 12:15 |
| sergiusens | kyrofa, morning | 12:16 |
| noizer | short question i want to make services in snapcraft 2.1 but it seems i don't work with the normal services tag | 12:16 |
| kyrofa | noizer, no, the syntax has changed in version 2 | 12:17 |
| noizer | kyrofa ok where can I find the syntax then? | 12:17 |
| kyrofa | noizer, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md | 12:18 |
| dholbach | sergiusens, kyrofa: I'm still seeing "sh -c /usr/lib/update-notifier/update-motd-updates-available 2>/d..." as a hanging process | 12:18 |
| sergiusens | dholbach, I have no idea what you are talking about | 12:19 |
| noizer | kyrofa how does it work with the ports then? | 12:19 |
| dholbach | sergiusens: http://paste.ubuntu.com/14876880/ | 12:19 |
| sergiusens | dholbach, in what point of snapcraft does it hang? | 12:20 |
| kyrofa | noizer, what do you mean? | 12:21 |
| sergiusens | dholbach, or at what point is it called | 12:21 |
| dholbach | sergiusens: that's in the 'pull' stage | 12:21 |
| noizer | I need something with sockets but then i tought i need services. So services with the previous version there you can open some ports. But is it possible now with the deamons? | 12:21 |
| noizer | kyrofa | 12:22 |
| sergiusens | pindonga, question about the store; every time we upload with the store API through snapcraft we have to re-set the supported releseases, is there a way to make that stick? | 12:22 |
| dholbach | sergiusens: first apt-get update is called, then something calls /usr/lib/update-notifier/update-motd-updates-available | 12:22 |
| dholbach | basically after "apt update" pull hangs | 12:23 |
| kyrofa | noizer, sure it is. You just need to set the right permissions. If you're binding to a port you'll need network-service | 12:23 |
| noizer | ok i will look in to it :p | 12:24 |
| ogra_ | mvo, somehow /etc/writable stopped working with the switch to squashfs | 12:25 |
| sergiusens | dholbach, so if it is when installing build packages, we don't call update https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/repo.py#L60 | 12:25 |
| sergiusens | dholbach, but we do call it here: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/repo.py#L232 | 12:25 |
| sergiusens | dholbach, nothing fancy though, just using python apt in a different rootdir (this will go away soon for everything but ros) | 12:26 |
| dholbach | sergiusens: when the apt lists are obtained in any case | 12:26 |
| sergiusens | dholbach, yeah, you hit this when adding stage packages | 12:27 |
| dholbach | I wonder how we can turn off bits like update notifier | 12:27 |
| dholbach | it must be possible | 12:27 |
| sergiusens | dholbach, maybe mvo knows | 12:27 |
| dholbach | mvo: do you know an apt config option which would turn off update-notifier scripts and stuff (when using a local sources.list) | 12:29 |
| dholbach | ? | 12:29 |
| noizer | kyrofa is there already documentation of network-services? | 12:29 |
| sergiusens | didrocks, hello there! Was there any issue with the upload? If you are too busy I can bother dholbach :-) | 12:31 |
| dholbach | what what? | 12:32 |
| sergiusens | dholbach, I just distro patched someting until a release is avail http://paste.ubuntu.com/14871051/ | 12:32 |
| sergiusens | for a broken package | 12:32 |
| dholbach | ok... | 12:33 |
| kyrofa | noizer, check out this example: https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/snapcraft.yaml | 12:33 |
| ogra_ | mvo, oh, ignore me ... /etc/writable is fine, it is the atomic write issue once again | 12:35 |
| noizer | kyrofa thx | 12:35 |
| dholbach | sergiusens: on it | 12:36 |
| didrocks | sergiusens: please bother him, yeah! here, it's quite crazy :p | 12:37 |
| kyrofa | noizer, does that make sense? You're just saying "my service needs to listen on the network" | 12:38 |
| noizer | I think it make sense | 12:38 |
| noizer | i will try it | 12:38 |
| noizer | because when when I'm testing it with normal command the permission was denied kyrofa | 12:39 |
| noizer | (tornado sockets) | 12:39 |
| kyrofa | noizer, do you know about snappy-debug? | 12:40 |
| noizer | i did not used it before | 12:40 |
| kyrofa | noizer, this may be helpful, from our brilliant dholbach: https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md | 12:40 |
| noizer | ok pray all dholbach :D | 12:41 |
| sergiusens | didrocks, I imagined as much | 12:42 |
| sergiusens | dholbach, thanks !!! | 12:42 |
| * sergiusens hugs dholbach | 12:42 | |
| * dholbach hugs sergiusens back | 12:49 | |
| dholbach | kyrofa, noizer: to be fair... the content was written mostly by Jamie IIRC :) | 12:50 |
| === bpierre_ is now known as bpierre | ||
| === JamesTai1 is now known as JamesTait | ||
| mvo | dholbach: you can clean the dpkg::post-invoke, is snapcraft using "import apt"? if so I can provide an example in a bit (meeting) | 12:59 |
| kyrofa | mvo, yessir it is | 13:00 |
| mvo | kyrofa: please try apt.apt_pkg.config.clear("dpkg::post-invoke") | 13:03 |
| anpok | is there a way to use an oem snap with ubuntu-device-flash without signing it? | 13:03 |
| noizer | kyrofa what does the type migration-skill? | 13:04 |
| kyrofa | Thanks mvo! dholbach it sounds like you have a good failing test case, think you can throw that in and give it a try? | 13:06 |
| kyrofa | noizer, so for 16.04 the ability to share things between snaps is calls "skills" | 13:06 |
| noizer | oooh ok :D | 13:07 |
| kyrofa | noizer, there's still in development, so right now there's only a single skill called the "migration-skill" that essentially offers backward compatibility with the old stuff | 13:07 |
| noizer | kyrofa ok thx :D | 13:07 |
| kyrofa | noizer, thought not really backward as it changes the yaml anyway... but you get the idea | 13:07 |
| noizer | yea | 13:08 |
| kyrofa | noizer, there have been a few threads on snappy-devel regarding this. If you're using 16.04 snappy you might consider getting on there so you know what's happening :) | 13:11 |
| noizer | kyrofa ok i will check it out today :D. first, I will take care of my application so it is working on snappy | 13:12 |
| dholbach | kyrofa: I'm not quite sure where to throw it in to make it work - I tried in a couple of places, but it doesn't seem to have an effect | 13:19 |
| dholbach | I tried L60 and L232 in snapcraft/repo.py, tried after the apt import and elsewhere | 13:19 |
| mvo | dholbach: just anywhere in the code, its a global option | 13:19 |
| mvo | dholbach: having said this, I have no idea if what I said actually made sense, maybe I should read backlog first ;) | 13:20 |
| dholbach | mvo: /usr/lib/update-notifier/update-motd-updates-available is still being called | 13:20 |
| dholbach | which in our context hangs (as non-root user) | 13:20 |
| dholbach | (mv /tmp/tmp.HSo85YHW5T /var/lib/update-notifier/updates-a...) | 13:20 |
| mvo | dholbach: hm, the apt.apt_pkg.config.clear() should prevent this. are there more ways that snapcraft drives apt in addition to the import apt? | 13:22 |
| dholbach | mvo: these are all notable occurences: http://paste.ubuntu.com/14877293/ | 13:23 |
| mvo | dholbach: the subprocess call there looks suspicious :) | 13:29 |
| mvo | dholbach: is that were it crashs and burns? | 13:29 |
| dholbach | I think it's before: http://paste.ubuntu.com/14877327/ | 13:30 |
| dholbach | that's where it tries to install build-packages which is not my local case | 13:30 |
| mvo | dholbach: apt_cache = apt.Cache(rootdir=rootdir, memonly=True) will reset the config, could you please stick the clear() after thi sline? | 13:34 |
| dholbach | mvo: no dice | 13:36 |
| mvo | :( | 13:36 |
| mvo | meh | 13:36 |
| dholbach | printing out apt.apt_pkg.config.get("dpkg::post-invoke") before and after the clear() gives nothing | 13:36 |
| dholbach | mvo: ah ok - I used .value_list now | 13:40 |
| dholbach | it's "['adequate --help >/dev/null 2>&1 || exit 0; exec adequate --debconf --user nobody --pending', 'if [ -d /var/lib/update-notifier ]; then touch /var/lib/update-notifier/dpkg-run-stamp; fi'] | 13:40 |
| dholbach | " before the .clear() | 13:40 |
| dholbach | and [] after | 13:40 |
| dholbach | could it be that the motd bits are somewhere else? | 13:41 |
| mvo | dholbach: hm, one sec | 13:44 |
| dholbach | mvo: | 13:45 |
| dholbach | /etc/apt.conf.d/99update-notifier:APT::Update::Post-Invoke-Success {"/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true";}; | 13:45 |
| mvo | dholbach: try APT::Update::Post-Invoke-Success: | 13:45 |
| mvo | dholbach: try APT::Update::Post-Invoke-Success | 13:45 |
| mvo | dholbach: yeah, if you clean that, it should be ok | 13:45 |
| * dholbach crosses fingers | 13:45 | |
| dholbach | come on apt, make me happy :) | 13:45 |
| dholbach | <3 | 13:45 |
| ogra_ | what a day ... so much ap5t talk in the snappy channel | 13:46 |
| kyrofa | ogra_, hahaha | 13:46 |
| dholbach | sergiusens_, kyrofa: http://paste.ubuntu.com/14877432/ | 13:46 |
| dholbach | I need to run for a bit, so feel free to push this one | 13:46 |
| kyrofa | dholbach, thanks for that! | 13:47 |
| dholbach | anytime | 13:47 |
| sergiusens_ | anpok, with --developer-mode iirc | 13:47 |
| sergiusens_ | dholbach, mvo thanks | 13:48 |
| dholbach | sergiusens_: I did a fresh build and upload of moon buggy - still the same errors/warnings from the reviewers tools | 13:48 |
| dholbach | 1) meta/readme.md does not exist lint_snappy_readme.md - 2) (NEEDS REVIEW) squashfs pkg lint_is_squashfs - 3) unknown entries in package.yaml: 'apps,description,summary' lint_snappy_unknown | 13:49 |
| dholbach | really need to run now - see you later | 13:49 |
| sergiusens_ | dholbach, oh, now I recall mvo saying he mixup the error message; it should say snap.yaml there; | 13:52 |
| sergiusens_ | there is still support required for those tools though | 13:52 |
| mvo | dholbach: yeah, the store is a bit confused, the click-reviewers-tools are not fully updated yet | 13:52 |
| mvo | dholbach: eh, s/store/c-r-t/ | 13:52 |
| didrocks | sergiusens_: I have some snapcraft.yaml which just download debs and a shell script. I wonder if I can say "please create a armhf .snap" (with snapcraft1) easily? | 13:53 |
| pindonga | sergiusens_, is this on subsequent uploads for the same pkg? ie, just new versions? | 13:53 |
| didrocks | as I have no compilation at all | 13:53 |
| pindonga | sergiusens_, this == having to re-set the releases | 13:54 |
| kyrofa | didrocks, the problem will be pulling the .debs from the arm repos | 13:54 |
| didrocks | kyrofa: exactly! | 13:54 |
| kyrofa | didrocks, pretending you didn't have that to worry about, you can actually put the .snap together yourself and just run snapcraft snap <directory> | 13:55 |
| kyrofa | didrocks, but I'm not sure there's a good way to get the .debs without running on target or hacking snapcraft | 13:55 |
| didrocks | kyrofa: sounds like an option. I'm looking as well in the code if I can spoof your arch detection :p | 13:55 |
| didrocks | (if you are using a chroot for download from the archive) | 13:55 |
| didrocks | or are you using the system sources.list? | 13:55 |
| kyrofa | didrocks, heh, going the hacking snapcraft route eh? | 13:56 |
| kyrofa | didrocks, hold on, let me find you a link | 13:56 |
| didrocks | kyrofa: seems to be in snapcraft/common.py | 13:56 |
| didrocks | heh 'dpkg-architecture', '-qDEB_BUILD_ARCH' | 13:56 |
| didrocks | and the arch triplet | 13:56 |
| kyrofa | didrocks, check out snapcraft/repo.py | 13:57 |
| didrocks | ah nice, it seems you not relying on system sources.list | 13:57 |
| didrocks | but rather building one | 13:58 |
| kyrofa | didrocks, right. stage-packages and build-packages are different | 13:58 |
| kyrofa | didrocks, you want the stage-packages stuff, which is repo.py | 13:58 |
| didrocks | kyrofa: thanks for the pointer! going to mess from there! :-) | 13:59 |
| kyrofa | didrocks, good luck! Interested to hear how it goes | 14:00 |
| didrocks | yeah, well… snapcraft1 and it's changing with the classic dimension then | 14:00 |
| kyrofa | didrocks, remember you can always download the .debs yourself and unpack them | 14:00 |
| didrocks | so, more of a stop gap :) | 14:00 |
| didrocks | yeah | 14:00 |
| didrocks | in download/ from the part | 14:01 |
| anpok | sergiusens_: ah that worked .. now it cannot find the package.yaml in the gadget snap | 14:01 |
| didrocks | but 134 of them | 14:01 |
| didrocks | so getting lazy! :) | 14:01 |
| kyrofa | didrocks, ugh! | 14:01 |
| sergiusens_ | anpok, I'll refer to mvo for that | 14:01 |
| sergiusens_ | pindonga, yes, new versions of the same package | 14:02 |
| pindonga | sergiusens_, I guess we could default to any release set for the latest published version | 14:03 |
| pindonga | sergiusens_, could you file a bug on lp:software-center-agent please? | 14:03 |
| beuno | well | 14:03 |
| beuno | or maybe store it locally? | 14:03 |
| beuno | in a local config | 14:03 |
| sergiusens_ | didrocks, your code is old, we removed the dep on dpkg-dev hence we don't have dpkg-architecture anymore either | 14:03 |
| beuno | last release targeted? | 14:03 |
| sergiusens_ | pindonga, I agree on that | 14:04 |
| sergiusens_ | beuno, well I was asking about the store api at first ;-) Since I need to add 'release' to snapcraft.yaml to support cleanbuild anyways | 14:04 |
| beuno | sergiusens_, I worry a bit about the server auto-filling data | 14:05 |
| beuno | but only a bit | 14:05 |
| beuno | :) | 14:05 |
| anpok | i creates a gadget/oem? snap that has a meta/package.yaml .. u-boot binary .. now it ubuntu-device-flash fails with 'Determining oem configuration\nno oem package found' | 14:05 |
| anpok | *created | 14:05 |
| pindonga | beuno, this being for new version uploads only, I thought relying on existing releases if none is specified was ok | 14:06 |
| pindonga | of course if the pkg contains the releases in the metadata, we should grab it from there | 14:06 |
| beuno | it's probably ok, yeah | 14:07 |
| beuno | it just feels like the wrong place to define intention | 14:07 |
| === alexabreu is now known as alex-abreu | ||
| sergiusens_ | beuno, it's not autofilling | 14:12 |
| sergiusens_ | beuno, or not less than it used to | 14:12 |
| sergiusens_ | beuno, if I upload the snap from the ui it is filled in with the previous stuff; at least it was a week a go | 14:12 |
| sergiusens_ | beuno, I don't mind if it is an api; maybe this can also play with the stability level (grade) in snap.yaml | 14:13 |
| didrocks | sergiusens_: it's snapcraft v1 | 14:14 |
| sergiusens_ | beuno, I'd much like to define which pockets to upload to, something like 'snapcraft upload --releases ubuntu-core,ubuntu-personal,...' | 14:14 |
| didrocks | sergiusens_: from git | 14:14 |
| sergiusens_ | didrocks, oh, right | 14:14 |
| didrocks | sergiusens_: we have to use it for mwc :p | 14:14 |
| === sergiusens_ is now known as sergiusens | ||
| awe__ | mvo, I tried installing hello-world.mvo on my new amd64 rolling image and it fails. Is this a known issue? | 14:16 |
| kyrofa | didrocks, oh yeah, that reminds me-- snapcraft snap <directory> is in version 2. If you're using 15.04 that functionality still exists in snappy itself, which you can use via snappy build | 14:16 |
| awe__ | sergiusens, I managed to get everything re-worked last night | 14:17 |
| kyrofa | didrocks, works the same way though | 14:17 |
| awe__ | one question... since I can't get hello-world working, what's the name of the user-specific writable env var? | 14:18 |
| kyrofa | awe__, $SNAP_USER_DATA | 14:18 |
| kyrofa | (if 16.04) | 14:18 |
| awe__ | great, thanks | 14:18 |
| awe__ | did SNAP_APP_DATA_PATH also get shortened? | 14:18 |
| awe__ | ( for 16.04 )? | 14:19 |
| kyrofa | awe__, $SNAP_APP_USER_DATA_PATH if 15.04 | 14:19 |
| kyrofa | awe__, indeed, $SNAP_DATA | 14:19 |
| ogra_ | SNAP_DATA ? | 14:19 |
| ogra_ | yeah | 14:19 |
| * ogra_ still cant memorize them | 14:19 | |
| awe__ | is the old env var still supported though in the latest images? | 14:19 |
| kyrofa | ogra_, it's okay, me too | 14:19 |
| kyrofa | awe__, yes, just deprecated | 14:19 |
| awe__ | ok, great; will change now | 14:19 |
| sergiusens | awe__, I guess email subjects are a thing of the past; https://lists.ubuntu.com/archives/snappy-devel/2016-January/001392.html :-) | 14:22 |
| ogra_ | ppisati, mvo, i'm nearly readey witrh my rpi firmware update for gadget and oem snap .... i was wondering if we should perhaps bump the default kernel version to the latest xenial one though (which means i'd need to update the dtbs in the snap) | 14:22 |
| sergiusens | awe__, what fails with hello-world? If it is installation, try snappy install hello-world/edge | 14:22 |
| ogra_ | (that is ... 4.2 to 4.3) | 14:23 |
| awe__ | sergiusens, ok, one sec | 14:23 |
| ppisati | ogra_: +1 | 14:23 |
| ogra_ | ppisati, any possible regressions (i.e. config changes) i shold be aware of ? | 14:23 |
| kyrofa | mvo, did you ever learn anything about that weird systemd %h thing? | 14:24 |
| awe__ | sergiusens, that works | 14:24 |
| awe__ | mvo, never mind my last statement about hello-world | 14:25 |
| kyrofa | matiasb, I uploaded another version of that owncloud snap, but I'm not seeing it in snappy again. When you get a sec would you mind patching that framework thing on it? | 14:26 |
| matiasb | kyrofa, ack, sure, in a bit | 14:26 |
| ppisati | ogra_: nothing on purpose at least :) | 14:27 |
| ppisati | ogra_: let me check one thing | 14:27 |
| ogra_ | ppisati, heh, ok | 14:27 |
| kyrofa | matiasb, thank you! | 14:27 |
| matiasb | kyrofa, fyi, we expect to get a fix for this deployed today, hopefully | 14:27 |
| kyrofa | matiasb, excellent! Thanks for letting me know :) | 14:27 |
| anpok | the problem seems to be that the oem/gadget snap looks different.. when in stalled in temp the package.yaml ends up being here: | 14:31 |
| pindonga | sergiusens, +1 to the idea of passing releases via api | 14:31 |
| anpok | ./apps/bananapi.sideload/ILfDRVXaWFBX/meta/package.yaml | 14:31 |
| anpok | s/in stalled/installed | 14:32 |
| matiasb | kyrofa, updated, you should see latest revision now | 14:33 |
| kyrofa | matiasb, perfect, works! | 14:37 |
| diwic | I rebooted - which apparently installed some new rootfs? - and now pulseaudio doesn't start: | 14:37 |
| kyrofa | didrocks, try the new version of owncloud.kyrofa when you get a sec, app store should be working | 14:38 |
| ppisati | ogra_: http://paste.ubuntu.com/14877727/ | 14:38 |
| ppisati | ogra_: that's the config diff between latest 4.2 and x/master 4.3 raspi2 kernel | 14:39 |
| ppisati | ogra_: other than that, it works fine on my board and in my test | 14:39 |
| ogra_ | ppisati, do you plan to bump to 4.4 before final ? | 14:39 |
| ppisati | ogra_: we make use of =m as mush as possible, so it should be fine | 14:39 |
| ogra_ | (giving us the free graphics driver) | 14:39 |
| ppisati | ogra_: we already have a 4.4 | 14:39 |
| ppisati | ogra_: but it's the first cycle | 14:39 |
| ppisati | ogra_: so it's marked as unstable | 14:40 |
| ogra_ | not on rpi yet | 14:40 |
| ogra_ | ah, k | 14:40 |
| ppisati | ogra_: yep, on rpi2 too | 14:40 |
| ogra_ | well, but you plan to bump it ? | 14:40 |
| ppisati | ogra_: ys | 14:40 |
| ogra_ | ppisati, hmm, then i'll probably push the update til 4.4 is consumable | 14:40 |
| diwic | the wrapper script claims it cannot find the executable | 14:40 |
| ogra_ | and stay with 4.2 til then | 14:41 |
| ppisati | ogra_: probably yes | 14:41 |
| ppisati | ogra_: i really like X because we syncronized with an upstream LTS kernel | 14:41 |
| ppisati | ogra_: so align nicely | 14:41 |
| ppisati | when everyone moves there | 14:41 |
| ogra_ | yeah | 14:42 |
| didrocks | kyrofa: oh nice! will definitively do:) | 14:43 |
| elopio | ping pitti. I need help trying to reproduce the snapcraft autopkgtest. Canonistack has timed out all week before starting to run the tests. | 14:51 |
| elopio | do you have any tips to reproduce locally? | 14:51 |
| pitti | elopio: it works in qemu? | 14:56 |
| pitti | elopio: looks like it's trying to contact https://repo.maven.apache.org/maven2 | 14:56 |
| pitti | elopio: possibly it's not respecting $https_proxy for that? | 14:56 |
| pitti | tests need to use the proxy in the environment, they can't talk directly to the network | 14:57 |
| elopio | pitti: I haven't even gotten there with qemu: https://paste.ubuntu.com/14863428/ | 14:58 |
| elopio | I have everything timing out in different ways :( | 14:59 |
| pitti | elopio: wow, how big is that tree? | 15:02 |
| pitti | elopio: you can try with --timeout-copy=3000 (default is 300, i. e. 5 mins) | 15:03 |
| pitti | but I guess something else is wrong, unless your tree really is Gigabytes big | 15:03 |
| * pitti runs "adt-run snapcraft --- qemu /srv/vm/adt-xenial-amd64-cloud.img" | 15:04 | |
| elopio | pitti: ummm, we pollute the repository when we build snaps. I'll try cleaning everything up first. | 15:06 |
| pitti | elopio: ah, in your ./ ? yes, do that, or run "snapcraft" instead of ".//" to use apt-get source | 15:07 |
| pitti | elopio: I started it, and I now see ".......EEE..." | 15:07 |
| pitti | elopio: i. e. some tests fail, but it's runing | 15:07 |
| pitti | elopio: wrt. trying to download from maven: don't we have tha particular module packaged? we have hundreds of maven packages | 15:07 |
| pitti | elopio: i. e. if you add this as a test dependency, then it would avoid having to call out to the internet | 15:08 |
| elopio | pitti: ok! seems promision. /me tries. | 15:08 |
| elopio | pitti: we decided for some reason to use upstream. Not sure about what was that reason now. | 15:08 |
| elopio | sergiusens: ^ ? | 15:08 |
| pitti | elopio: ok, then I figure you either don't respect $https_proxy, or something cleans the environment | 15:09 |
| sergiusens | elopio, pitti well one of the purposes for those examples is to use upstream; I I can look into seeing if http_proxy gets wiped or not | 15:13 |
| sergiusens | thanks | 15:13 |
| elopio | thanks pitti! it's running now locally. I can start debugging now. | 15:13 |
| jdstrand | mvo: hey, fyi, both systems are continuing to install hello-world.canonical 1.0.18 | 15:23 |
| jdstrand | I didn't check to see if they stopped during the night | 15:23 |
| jdstrand | I can if you need me to | 15:23 |
| mvo | jdstrand: meh, thanks | 15:24 |
| kyrofa | mvo, sergiusens much simpler reproducible case for the broken $SNAP_USER_DATA here: https://bugs.launchpad.net/snappy/+bug/1541898 | 15:40 |
| ubottu | Launchpad bug 1541898 in Snappy "Broken $SNAP_USER_DATA for services" [Undecided,New] | 15:40 |
| * dholbach hugs sergiusens | 15:53 | |
| kyrofa | sergiusens, jsonschema question (context: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L343) | 15:55 |
| kyrofa | sergiusens, if I load the YAML via yaml.load (which gives me a dict) and hand the dict to jsonschema, how can jsonschema _possibly_ back that out to a line number in the yaml? | 15:55 |
| noizer | kyrofa what is the correct syntax for the copy plugin? | 15:57 |
| kyrofa | noizer, copy has one parameter, "files", which is a map of source->destinations | 15:58 |
| kyrofa | noizer, so something like: http://pastebin.ubuntu.com/14878198/ | 15:58 |
| noizer | kyrofa ok but in Private chat you said i did it wrong for my nginx.conf file | 15:59 |
| kyrofa | noizer, right, you have a copy plugin with no files-- just a stage-package | 15:59 |
| noizer | yea ok that was wrong but the part under that it will copy the nginx.conf over the other one but it don't work | 16:01 |
| kyrofa | noizer, you may need to exclude that conf file from the stage-packages | 16:02 |
| kyrofa | noizer, if two parts try to write the same file but they differ, snapcraft will throw a fit | 16:02 |
| kyrofa | noizer, since it doesn't know which one you actually want | 16:02 |
| noizer | ok | 16:03 |
| kyrofa | noizer, look in that syntax file for the `stage` and `snap` keywords for the parts | 16:04 |
| kyrofa | noizer, you can use those to exclude the config file | 16:05 |
| sergiusens | kyrofa, it is impossible | 16:06 |
| sergiusens | kyrofa, but you can get the key that cause the issue | 16:06 |
| kyrofa | sergiusens, yeah okay, that's what I thought | 16:06 |
| kyrofa | sergiusens, gotcha | 16:07 |
| renat | Hi guys! | 16:32 |
| renat | We have application. Screenly Viewer. Slide Show application which uses opengl to show it's slides. | 16:33 |
| beuno | renat, hi! | 16:33 |
| renat | When I start the binary - everything works well, and it works. But when I'm trying to start it as a systemd service. I loads. Shows the first asset and stops. Just using 100% cpu. | 16:34 |
| renat | beuno, Hi! | 16:34 |
| beuno | renat, lets start off with some basic information | 16:34 |
| beuno | what release of snappy are you using? | 16:35 |
| renat | 15.04 | 16:35 |
| renat | stable | 16:35 |
| renat | It doesn't show any apparmor and seccomp warnings | 16:35 |
| beuno | renat, ok, lets ping some folks who might be better suited to help debug | 16:36 |
| renat | beuno, thanks! | 16:36 |
| beuno | jdstrand, sergiusens, kyrofa, any pointers? ^ | 16:36 |
| beuno | kgunn, maybe you have some thoughts? | 16:36 |
| apw | mvo, yo, you know things ... ubuntu-core 15.04 has extended support relative to 15.04 which is just EOL'ing | 16:36 |
| apw | mvo, as i understand things you have an overlay PPA which will take over to supply updates for things after EOL of 15.04 ... | 16:37 |
| kyrofa | renat, are you using mir or something? | 16:37 |
| apw | mvo, so we are trying to confirm that you are needing vivid kernel updates for that, and how those would make it to you | 16:37 |
| renat | kyrofa, hi! No. I'm now 100% sure how it works. But it uses Qtt OpenGL | 16:38 |
| kgunn | renat: and what exactly are you running on ? amd64? vm? arm? | 16:38 |
| renat | kyrofa, it's Raspberry Pi2 ARM | 16:38 |
| renat | kyrofa, it's Raspberry Pi2 armhf | 16:38 |
| beuno | apw, ricmm might be better suited to answer that | 16:38 |
| kyrofa | renat, are you using the qml plugin in snapcraft, then? | 16:38 |
| apw | ricmm, ^^ | 16:38 |
| renat | kyrofa, no. We use our patched version of Qt as I know. Build everything into squashfs using buildroot. I create a snap by extracting everything from the squashfs and setting appropriate paths in LD_LIBRARY_PATH and all other libraries. | 16:40 |
| kyrofa | renat, oh | 16:40 |
| kyrofa | hmm | 16:40 |
| beuno | I think 15.04 doesn't support squashfs? | 16:40 |
| beuno | does it? | 16:40 |
| kyrofa | beuno, right | 16:41 |
| kgunn | but he says it loads/works.... | 16:41 |
| kgunn | only until he tries to start it as a systemd service does it not work (stalls on first frame) | 16:41 |
| kgunn | iiuc | 16:41 |
| kgunn | renat: if it shows 100%cpu...what's the process using cpu? | 16:42 |
| renat | kgunn, executable itself | 16:43 |
| kgunn | renat: mmm, but seems you have a ton of stuff inside that snap... | 16:44 |
| renat | kgunn. I'm placing logging functions to different places. But don't get any output. | 16:44 |
| renat | What is difference between running as executable and as a systemd service? | 16:45 |
| kgunn | renat: that i really don't know...others would be better to speak | 16:45 |
| kyrofa | renat, I'm confused. You say it's Qt and OpenGL. You must be using a display server of some kind? | 16:47 |
| renat | kyrofa, it uses framebuffer | 16:47 |
| kyrofa | renat, ah, okay | 16:49 |
| renat | It should be something systemd or cgroups related. | 16:49 |
| kyrofa | renat, have you tried running this as an app with sudo? | 16:50 |
| renat | kyrofa, Yes. It works | 16:51 |
| kyrofa | renat, have you tried via su as well? | 16:51 |
| kyrofa | renat, real=effective uid | 16:51 |
| renat | kyrofa, worked again | 16:54 |
| kyrofa | renat, when running as a service, I'm assuming it doesn't fork right? | 16:55 |
| renat | No. It doesn't I use exec in all wrappers | 16:55 |
| renat | No. It doesn't. I use exec in all wrappers | 16:56 |
| === kickinz1-sprint is now known as kickinz1|afk | ||
| kyrofa | renat, by running under su you've eliminated the differences as far as I can tell. I'm really not sure why it's not working when running as a service. Everything else should be the same | 16:57 |
| kyrofa | renat, what you need is gdb :( | 16:59 |
| renat | kyrofa, no. 1 more difference. Different slice. system.slice vs user.slice. | 16:59 |
| kyrofa | renat, hmm, yeah you can either start adding prints to the application to figure out where it's looping, or wait for sergiusens or mvo to give you some more pointers | 17:01 |
| sergiusens | renat, snappy service logs [snap] gives no output? | 17:04 |
| jdstrand | renat (otoh, I can't think of something. however, it is possible you aren't seeing security denial due to kernel rate limiting. I suggest: sudo snappy install snappy-debug ; sudo reboot ; login ; sudo snappy-debug.security scanlog ; exercise your snap | 17:06 |
| renat | Thanks. trying. | 17:09 |
| jdstrand | beuno: awe__ asked me to upload bluez to rolling using the shared acount (fine). there is an amd64 and an armhf snap with the same version number. anything special I need to know when doing this? | 17:10 |
| kyrofa | jdstrand, they can't have the same version right now | 17:10 |
| kyrofa | Unless that's changed since yesterday | 17:10 |
| jdstrand | awe__: fyi, ^ | 17:10 |
| kyrofa | jdstrand, so I just append -amd64 and -armhf to the versions | 17:10 |
| awe__ | ok; so build one as -1 | 17:11 |
| awe__ | and the second as -2 | 17:11 |
| kyrofa | jdstrand, other than that, seems to work great! | 17:11 |
| awe__ | or that | 17:11 |
| kyrofa | awe__, yeah, whatever doesn't imply that the versions are actually different, you know? | 17:11 |
| jdstrand | kyrofa: thanks! | 17:11 |
| jdstrand | beuno: nm | 17:11 |
| awe__ | sure | 17:11 |
| sergiusens | awe__, kyrofa wait, for 16.04 we have multi arch pockets in the store since monday | 17:12 |
| sergiusens | is that right matiasb ^ ? | 17:13 |
| sergiusens | maybe for 15.04 two; the store doesn't care about releases | 17:13 |
| kyrofa | awe__, yeah multi arch uploads work, but the versions need to be different (same package) | 17:13 |
| kyrofa | sergiusens rather, sorry | 17:13 |
| sergiusens | right version~$arch seems saner than diffrent package names to me | 17:13 |
| kyrofa | sergiusens, yeah | 17:13 |
| ogra_ | shudder | 17:14 |
| kyrofa | sergiusens, that's what I was trying to say-- sorry I wasn't clear | 17:14 |
| sergiusens | "this is the armhf version of the snap" | 17:14 |
| ogra_ | we should really have a meta field for that | 17:14 |
| sergiusens | it even matches how you would mention it | 17:14 |
| sergiusens | ogra_, we do ;-) | 17:14 |
| ogra_ | why do i then need $version-arch ? | 17:15 |
| matiasb | sergiusens, awe, yes, you can upload multiple versions for different arch/release combination in the same package | 17:15 |
| sergiusens | ogra_, because the store doesn't upload every arch atomically | 17:15 |
| sergiusens | ogra_, it's like setting an arch in a deb and uploading N times swithing the arch field | 17:15 |
| ogra_ | sergiusens, yeah, nothing you would ever do with a deb :) | 17:15 |
| renat | sergiusens, snappy service logs doesn't give more information unfortunately. | 17:16 |
| ogra_ | but i guess thats a price we have to pay for binary uploads | 17:16 |
| renat | jdstrand, already tried scanlog. Nothing related to apparmor or seccomp | 17:16 |
| * awe__ ducks out for a bit; bbl | 17:16 | |
| jdstrand | renat: ok, so if you did the reboot (that is important so the kernel forgets about what it rate limited) and scanlog gave no output, it is something else | 17:17 |
| jdstrand | renat: the first place I would look is 'snappy service logs <foo>' | 17:18 |
| jdstrand | that will give all the systemd log output | 17:18 |
| renat | jdstrand, already done. Unfortunately somewhere infinite loop appeared. And it doesn't give additional logging | 17:18 |
| renat | Is it possible to start process inside custom cgroup hierarchy? | 17:23 |
| kyrofa | sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/296 when you're able | 17:26 |
| kyrofa | Huh. I can't reach github all of a sudden | 17:53 |
| kyrofa | Ah, and as soon as I say something, it's back | 17:54 |
| renat | kyrofa, What if I try to move to 16.04 snappy version? Can I just chroot to our squashfs there, and run program from inside the chroot? | 17:55 |
| kyrofa | renat, no not really-- you'd need to run it with ubuntu-core-launcher, with the right environment, etc. | 17:57 |
| kyrofa | renat, though that brings up my `snappy shell` question again. Chipaca, you around? | 17:57 |
| kyrofa | elopio, coveralls doesn't seem to be reporting back to https://github.com/ubuntu-core/snapcraft/pull/296 | 18:15 |
| kyrofa | elopio, travis says it submitted it successfully, but coveralls keeps saying "no data" | 18:16 |
| kyrofa | elopio, any ideas? | 18:16 |
| elopio | kyrofa: no, seems just to be dumb. I re-ran it. | 18:28 |
| kyrofa | elopio, ah, okay | 18:29 |
| kyrofa | sergiusens, the fix to bug #1541353 is to just parse the snapcraft.yaml, yes? | 18:29 |
| ubottu | bug 1541353 in Snapcraft "'snapcraft upload' says 'Invalid package filename.'" [High,Triaged] https://launchpad.net/bugs/1541353 | 18:29 |
| kyrofa | sergiusens, or would you go so far as to unsquashfs and extract metadata from the snap itself? | 18:30 |
| LefterisJP | beuno: Hey mate, I am uploading my snap to the MWC store and no matter what I do it seems that the icon.png from the snapcraft.yaml is not included. | 18:42 |
| elopio | kyrofa: one more time. Now it's travis with a mismatch hash | 18:43 |
| LefterisJP | beuno: if I upload the snap to a local snappy device the icon shows up fine in the WebDM interface, so it's probably an error with the store. | 18:45 |
| beuno | LefterisJP, hi | 18:46 |
| sergiusens | kyrofa, the fix is to remove the regex | 18:47 |
| beuno | LefterisJP, is this a 15.04 snap or a 16.04 snap? | 18:47 |
| kyrofa | sergiusens, but the upload code needs a name | 18:47 |
| kyrofa | sergiusens, it's not just a validation | 18:47 |
| sergiusens | kyrofa, oh, doesn't the upload code contruct a name in the code itself? | 18:47 |
| kyrofa | sergiusens, via the regex | 18:47 |
| sergiusens | kyrofa, oooh | 18:48 |
| sergiusens | kyrofa, one second, I'll get you pointers | 18:48 |
| kyrofa | sergiusens, so I figure, get the name from the yaml | 18:48 |
| sergiusens | kyrofa, extract these two functions https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/commands/snap.py#L47 | 18:49 |
| sergiusens | kyrofa, and also figure out why it refers to 'package.yaml' and how it works :/ | 18:49 |
| sergiusens | put them in common | 18:49 |
| kyrofa | sergiusens, uh oh :P | 18:50 |
| kyrofa | sergiusens, but yeah, okay, same page | 18:50 |
| sergiusens | kyrofa, expose format snap_name with docstrings and all tat magic | 18:50 |
| sergiusens | kyrofa, I don't understand how it works though; given all tests still pass | 18:50 |
| kyrofa | sergiusens, indeed, I'll look into it | 18:51 |
| sergiusens | kyrofa, oh, that first function is not used | 18:51 |
| kyrofa | sergiusens, perhaps the tests setup that directory with a package.yaml | 18:51 |
| sergiusens | kyrofa, just export format_snap_name in common | 18:51 |
| kyrofa | sergiusens, it's used if called with DIRECTORY | 18:51 |
| kyrofa | sergiusens, but yeah | 18:52 |
| sergiusens | kyrofa, ah, we have no test for that! | 18:52 |
| kyrofa | sergiusens, oops | 18:52 |
| LefterisJP | beuno: It's a 15.04 snap that's going in the MWC store | 18:52 |
| kyrofa | sergiusens, making bug now | 18:52 |
| sergiusens | kyrofa, units yes, not tests tests | 18:52 |
| sergiusens | kyrofa, even if we did, our prelayed out dir wouldn't of catched this | 18:52 |
| sergiusens | kyrofa, the easy way to have a test for this is to run `snapcraft snap` and then `snapcraft snap snap` | 18:53 |
| beuno | LefterisJP, while I look into that, can you add the icon separately to the app in the store? | 18:53 |
| kyrofa | sergiusens, oo, I like it | 18:53 |
| sergiusens | kyrofa, it may have merit for a separate bug | 18:53 |
| kyrofa | sergiusens, yeah I think so | 18:54 |
| LefterisJP | beuno: I think I can but then I won't be able to confirm it works fine when it does :) | 18:58 |
| beuno | LefterisJP, I can do that separately :) | 18:58 |
| LefterisJP | kk | 18:59 |
| kyrofa | sergiusens, yeah, just a bad test setup: https://github.com/ubuntu-core/snapcraft/pull/297 | 19:04 |
| kyrofa | sergiusens, old, rather-- not bad :) | 19:04 |
| elopio | kyrofa: sergiusens: I'm going to lie in bed for the rest of the day. | 19:20 |
| kyrofa | elopio, feel better! | 19:20 |
| awe__ | so earlier this morning, I installed hello-world using: 'sudo snappy install hello-world/edge | 19:23 |
| awe__ | when I try now | 19:23 |
| awe__ | I get snappy package not found | 19:23 |
| ogra_ | blame beuno ? | 19:23 |
| * ogra_ guesses the store was fixed during the day | 19:24 | |
| awe__ | kyrofa, is there anyway around a full rebuild of a autotools based snap when you only change a single file? | 19:27 |
| awe__ | right now I find myself having to do a clean first | 19:27 |
| awe__ | and this takes forever on a ripi2 | 19:28 |
| kyrofa | awe__, yeah I feel your pain. Unfortunately not, but it's something I'm hoping to solve soon | 19:28 |
| kyrofa | awe__, my ownCloud snap takes literall all day (or night) long to build on the rpi | 19:28 |
| sergiusens | kyrofa, right, which goes down to the fact that only units can't save you ;-) | 19:33 |
| sergiusens | elopio, get better | 19:33 |
| kyrofa | sergiusens, indeed. I added an integration test as well | 19:34 |
| kyrofa | sergiusens, so hopefully that doesn't bite us again | 19:34 |
| === dustino_ is now known as dustino | ||
| === cprov_ is now known as cprov | ||
| kgunn | jdstrand: ping | 21:22 |
| jdstrand | hey | 21:22 |
| kgunn | jdstrand: hey, was just updating to skills...and wanted a sane eye | 21:22 |
| kgunn | http://bazaar.launchpad.net/~mir-team/+junk/mir-server-snapcraft2.1/view/head:/snapcraft.yaml | 21:22 |
| kgunn | that format look right? | 21:22 |
| kgunn | like the "migration-one/two" can just be random/meaningless to me? | 21:23 |
| jdstrand | kgunn: you want to uses caps and not security-template | 21:23 |
| jdstrand | kgunn: plus you can combine those into one skill | 21:24 |
| jdstrand | migration-stuff: | 21:24 |
| jdstrand | type: migration-skill | 21:24 |
| jdstrand | caps: [display-server, unix-listener\ | 21:24 |
| kgunn | i get it | 21:24 |
| kgunn | altho...interesting, i thot the whole reason was to get rid of the "caps" nomenclature | 21:25 |
| * kgunn didn't really get the passion of the move to term "skill" | 21:25 | |
| kgunn | but thanks! | 21:25 |
| jdstrand | kgunn: it is, this is a 'migration-skill' | 21:26 |
| pedronis | well migration-skill is just an interim thing, so it crosses the old and new world (also terminology wise) | 21:26 |
| kgunn | i figured | 21:26 |
| kgunn | "interim" | 21:26 |
| jdstrand | when the security parts of skills a worked out, that can go away | 21:26 |
| jdstrand | are* | 21:26 |
| kgunn | jdstrand: just looking ahead, is the goal to be nailed down at 16.04? | 21:27 |
| jdstrand | zyga and I will be talking soon to sync up once I get the review tools changes done for 16.04 | 21:27 |
| kgunn | thanks again | 21:27 |
| jdstrand | kgunn: everyone wants that. from my side, I'm good with doing it for 16.04, but there might be things on the skills side I'm not aware of that might prevent it | 21:28 |
| jdstrand | I think it is ok to assume 'yes' | 21:28 |
| kgunn | :) | 21:29 |
| robert_ancell | elopio, around? | 21:46 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | kyrofa, i'm around now, what was the question? | 21:50 |
| sergiusens | kyrofa, you should join the fun and get onto the slack channel :-P | 22:03 |
| sergiusens | ETOOMANYCHANS | 22:03 |
| sergiusens | Chipaca, I think I know | 22:04 |
| sergiusens | Chipaca, systemd service units are not replacing %h properly | 22:04 |
| sergiusens | Chipaca, convert hello-world.env into a daemon and you will see | 22:05 |
| sergiusens | Chipaca, %h should be /root, instead it's plain `/` | 22:05 |
| Chipaca | sergiusens, can you pastebin the output of hello-world.env-as-a-daemon? | 22:05 |
| sergiusens | Chipaca, ok, first I need to unxz the latest image; give me 2' | 22:06 |
| Chipaca | sorry i'm being lazy | 22:07 |
| Chipaca | rough day | 22:07 |
| Chipaca | thinking of taking tomorrow off or somehting | 22:07 |
| zyga | jdstrand: with pleasure | 22:10 |
| sergiusens | Chipaca, look at SNAP_USER_DATA http://paste.ubuntu.com/14883057/ | 22:14 |
| sergiusens | Chipaca, notice the double `/` there | 22:15 |
| * sergiusens heads out for aikido | 22:15 | |
| Chipaca | sergiusens, yes yes. But is that *all* the output from env? (I want to see the environ :-) ) | 22:21 |
| Chipaca | sergiusens, my suspicion is that for some reason HOME isn't set | 22:21 |
| sergiusens | Chipaca, it is | 22:23 |
| Chipaca | drat | 22:23 |
| sergiusens | Chipaca, don't units set HOME accordingly or is that some sort of system setting? | 22:23 |
| sergiusens | the manpage says %h resolves to /root by default | 22:23 |
| sergiusens | I need to go | 22:23 |
| sergiusens | will bbl | 22:23 |
| sergiusens | if you want to drop lines here I'll read later :-) | 22:24 |
| Chipaca | sergiusens, go go | 22:24 |
| plars | elopio: I've cherry-picked your older patches into current trunk, and I'm trying to also cross-build the test binary for arm but I'm getting an error. Have you seen anything like this? | 22:26 |
| plars | /tmp/gotestbuild/src/github.com/ubuntu-core/snappy/progress/progress.go:200: undefined: isatty | 22:26 |
| grim__ | does anyone know if there are snappy images archived anywhere? The core updates cause some of our snaps to fail to install. We'd like to try to install on core versions 1-current to figure out what is going on. | 23:20 |
| neutrino | Any way to create self hosted snappy store for private snapps? | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!