| lutostag | on my rpi3 after I snap install pulseaudio I don't see any cards/sinks, anything I need to do to set that up? | 00:23 |
|---|---|---|
| Son_Goku | morphis: I think I'll crash and burn if someone suggests double LSM again as a solution | 01:05 |
| ngaio | Is anyone interested in helping me create a snap for Rapid Photo Downloader? | 01:37 |
| Croepha | perhaps if you ask a specific question :) | 01:40 |
| Croepha | but im actually about to go for the day | 01:41 |
| ngaio | Croepha, I'm a bit confused about the relationship between getting something from pip via the requirements.txt and that thing requiring dependencies to be present beforehand | 01:43 |
| ngaio | outside of a snap environment, one has to apt install all the build requirements first, naturally | 01:44 |
| Croepha | are you using the python plugin in snapcraft? | 01:44 |
| ngaio | I don't know if I should be or not | 01:44 |
| ngaio | it's a python program, but it's dependencies are not trivial | 01:45 |
| Croepha | if you want to do the equivalent of an apt-install for a snap, you can do something called "stage-packages" | 01:46 |
| Croepha | but, that usually isn't the best for python requirements | 01:47 |
| Croepha | im not very familiar with the python plugin, but I think it expects a properly structured python package source, and it will bundle requirements that are specified in the setup.py | 01:48 |
| gregl | One thing i can't get a handle on is how do you make changes to a snap app? I i'll use Hexchat as an example,I usually change the colors in it by changing some config files. Snap is a read only file system,so i am a bit lost here.. | 01:48 |
| Croepha | gregl: everything that needs to be variable, should be located in one of the writable directories | 01:49 |
| ngaio | ok thanks Croepha I'll look into it some more | 01:49 |
| Croepha | gregl: use https://snapcraft.io/docs/reference/env | 01:50 |
| Croepha | gregl: you could also look at the users home directory for settings files, but that isn't a snap supported thing to do | 01:50 |
| Croepha | but it works | 01:50 |
| gregl | Croepha, Ok thanks,I did find the writeable folders.. | 01:51 |
| gregl | Cool .I will look a bit more.. | 01:51 |
| nacc | ok, i must be doing something obviously wrong. given the following yaml: http://paste.ubuntu.com/24364688/ i want the run.sh in snap/run.sh in the same git repository as the main part to be included in the built snap as the application. Basically, add a custom wrapper that is in the same repository | 02:57 |
| mup | PR snapcraft#1250 opened: Fixed links to doc <Created by andyli> <https://github.com/snapcore/snapcraft/pull/1250> | 03:05 |
| nacc | but when i use the builders on launchpad, i just get errors consistently about being unable to find run.sh | 03:06 |
| nacc | ah, i might be being bit by LP: #1663534 ... i wonder why `snapcraft cleanbuild` on my 17.04 machine at home doesn't complain, though? | 03:58 |
| mup | Bug #1663534: Dump plugin can't copy files from snap/ <Snapcraft:Confirmed> <https://launchpad.net/bugs/1663534> | 03:58 |
| mup | PR snapcraft#1251 opened: internal: remove empty lines in the unclean parts message <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1251> | 05:12 |
| stub | I've got revision 9 of a snap published in the stable channel in the store that I can install with 'sudo snap install wal-e --classic'. However, doing that in an lxd container on the same box is getting revision 6. | 05:46 |
| stub | I suspect it is a permissions issue, and the difference is the lxd container is not logged on at all. But I can't see where it is screwed up. | 05:47 |
| stub | oh, got it. The scripted install in the container was using the wrong channel. | 05:49 |
| === chihchun_afk is now known as chihchun | ||
| * stub wonders if 'snap list' and 'snap refresh' should mention channels | 05:53 | |
| mup | PR snapd#3178 closed: Release 2.24 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3178> | 06:09 |
| morphis_ | Son_Goku: you mean AppArmor and SELinux in parallel? | 06:14 |
| mup | PR snapd#3180 opened: many: fixes for `go vet` in go 1.7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3180> | 06:32 |
| mvo | jdstrand: hey, I heard rumors that there is an issue with the renamed snap-confine apparmor profile in 2.24/2.23.6 - if you have more details I would love to hear them | 06:51 |
| sbeattie | mvo: it looked like the ADT tests for the kernel would uninstall the 2.22.6 snapd (without purging and without uninstalling snap-confine) and then later install snapd 2.23.6. Because of that, I think the postrm bit to remove the old snap-confine profile wouldn't get triggered. | 06:55 |
| sbeattie | So both versions of the profile would exist after the "upgrade". | 06:56 |
| mvo | sbeattie: aha, thank you. let me try that | 06:58 |
| mvo | sbeattie: do you happen to know if there is a log or a bug available for this? | 06:59 |
| sbeattie | mvo, jdstrand: I'm not sure a bug got filed for it | 07:00 |
| sbeattie | mvo: log is at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-hwe-edge/20170410_201241_f4dfd@/log.gz | 07:00 |
| mvo | sbeattie: ta! | 07:01 |
| sbeattie | mvo: I'm not honestly sure if it's a snapd bug or an ADT bug. | 07:01 |
| sbeattie | but I can file one in case you decide to upload something on the snapd side to fix/work around it. | 07:02 |
| mvo | sbeattie: definitely worth persuing, I suspect that we left a file behind (/etc/apparmor.d/usr.lib.snapd.snap-confine) in some upgrade screnario | 07:02 |
| zyga | good morning | 07:06 |
| pstolowski | hey zyga, morning! | 07:06 |
| zyga | hey hey | 07:09 |
| zyga | sorry, overslept | 07:09 |
| zyga | how's everything? | 07:09 |
| sbeattie | mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023 | 07:09 |
| mup | Bug #1682023: snapd/snapd-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade <snapd (Ubuntu):New> <https://launchpad.net/bugs/1682023> | 07:09 |
| mvo | thanks sbeattie | 07:11 |
| mvo | hey zyga and pstolowski | 07:11 |
| mvo | and good morning fgimenez_ :) | 07:11 |
| mvo | fgimenez_: I added a forum topic and invited for you, not sure if that works | 07:12 |
| fgimenez_ | mvo: zyga pstolowski good morning | 07:12 |
| fgimenez_ | mvo: sure, already ack'ed with a hearth :) | 07:12 |
| mvo | sbeattie: apw figured out that on purge the apparmor profile is removed from disk but not unloaded from the kernel. not sure if that is expected behaviour ? maybe a precaution to ensure that running binaries that are removed from disk but still in memory are still protected? in any case it explains the error but its a bit unclear what we can do about it | 07:13 |
| fgimenez_ | mvo: i'm currently involved in core validation at candidate too, as soon as that is sorted i'll put hands on the sru | 07:13 |
| mvo | fgimenez_: thank you, no problem, I just got asked about it via irc and with a forum topic its much easier for me, I can just point people to that :) | 07:14 |
| zyga | sbeattie: if you purge snap-confine does that go away? | 07:14 |
| fgimenez_ | mvo: totally, the forum is a huge improvement for that | 07:15 |
| zyga | aha | 07:15 |
| zyga | it didn't purge | 07:15 |
| pstolowski | o/ | 07:16 |
| mvo | zyga: yeah, I suspect we need a dpkg-mainthelper to remove the conffile on the snap-confine package as well | 07:16 |
| zyga | mvo: the package gets removed on purge | 07:17 |
| zyga | mvo: I tested this when we were working on the .real workaround | 07:17 |
| apw | i think the suggestion is you have old snapd + fat snap-confine installed | 07:18 |
| apw | you now purge snapd only | 07:19 |
| apw | and then install the -updates snapd | 07:19 |
| apw | i am trying to get into that situation here | 07:19 |
| mvo | zyga, apw: http://paste.ubuntu.com/24365745/ might be all we need - but first we need to reproduce :) | 07:21 |
| * zyga looks | 07:22 | |
| zyga | mvo: thank you | 07:22 |
| * zyga is still sleepy | 07:22 | |
| * mvo hugs zyga | 07:22 | |
| apw | mvo, ok reproduced | 07:28 |
| mvo | apw: I think I did so as well and the mainthelper did help me, could you pastebin your steps so that I can double check? | 07:29 |
| apw | mvo, just doing it again with a transcript to be sure i did it sane | 07:30 |
| mup | PR snapd#3181 opened: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3181> | 07:32 |
| apw | mvo, ok reproduced and documented: http://paste.ubuntu.com/24365841/ | 07:43 |
| apw | mvo, shall i add that to the bug as well | 07:43 |
| mup | PR snapd#3182 opened: store: tests for unexpected EOF <Created by stolowski> <https://github.com/snapcore/snapd/pull/3182> | 07:44 |
| mvo | apw: \o/ #3181 should help, I wonder what the easiest way for you to double check might be (if you are still interessted). I could do a PPA build for you? or I just reproduce all your steps once its in master and it gets into our daily edge ppa. | 07:46 |
| mbriza | when trying to run the anbox snap in fedora, i get "execv failed: No such file or directory" - is that a problem of snapd or the snap? | 07:47 |
| apw | mvo, if you have a .deb set i thnk i can legitimatly test those by hand to confirm | 07:47 |
| apw | all this because people are not doing upgrades right, sigh | 07:50 |
| mvo | apw: http://people.canonical.com/~mvo/tmp/for-andy/ | 07:51 |
| mvo | apw: this one is hopefully good | 07:51 |
| zyga | mbriza: hey, perhaps snapd, can you please tell me which release are you on? | 07:53 |
| apw | Removing obsolete conffile /etc/apparmor.d/usr.lib.snapd.snap-confine ... | 07:54 |
| apw | mvo, ^ i assume that is a good sign | 07:54 |
| apw | and i have only the .real | 07:54 |
| apw | so i call that fixed in your packages | 07:55 |
| morphis_ | zyga: looks like today is happy we-update-all-distros-with-2.24-day :-) | 07:55 |
| zyga | morphis_: indeed | 07:57 |
| zyga | morphis_: congratulations on android box :) | 07:57 |
| zyga | morphis_: did you try it on fedora, mbriza above said there is something fishy | 07:57 |
| morphis_ | zyga: thanks, that was a long overdue thing | 07:57 |
| morphis_ | zyga: no, not yet but I know people tried | 07:57 |
| morphis_ | zyga: it will be a bit harder as we don't have dkms packages for the binder/ashmem kernel drivers there yet | 07:58 |
| zyga | morphis_: aha | 07:58 |
| zyga | morphis_: how does the snap work? | 07:59 |
| morphis_ | zyga: devmode-only :-D | 07:59 |
| morphis_ | zyga: and https://github.com/anbox/anbox/blob/master/scripts/container-manager.sh#L31 | 07:59 |
| zyga | aha | 08:00 |
| zyga | morphis_: I think you could detect if you have apparmor around you and skip aa-exec | 08:00 |
| zyga | morphis_: but I bet this will come with time | 08:00 |
| zyga | mbriza: ^^ | 08:00 |
| morphis_ | zyga: yes, for non-apparmor enabled systems we have | 08:01 |
| morphis_ | zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1647168 | 08:01 |
| mup | Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168> | 08:01 |
| morphis_ | that was the initial reason for the aa-exec call | 08:02 |
| morphis_ | didn't investigated that further yet | 08:02 |
| mvo | apw: \o/ | 08:02 |
| mvo | apw: if you could comment in https://github.com/snapcore/snapd/pull/3181 that would be great | 08:03 |
| mup | PR snapd#3181: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3181> | 08:03 |
| apw | mvo, am just making sure i did the test right (i am sure i did) and scipting it | 08:07 |
| apw | mup, ok that worked and i am happy i am sure it did :) | 08:07 |
| mup | apw: I apologize, but I'm pretty strict about only responding to known commands. | 08:07 |
| apw | mvo, ok that worked and i am happy i am sure it did :) | 08:07 |
| mvo | \o/ again! | 08:08 |
| apw | mvo, is that sufficient (as a comment) | 08:10 |
| mvo | apw: absolutely, thank you | 08:10 |
| abeato | ogra_, I have flashed latest rpi3 image, but I am not able to connect to the store from console-conf, is that a known issue? It hangs in "Contacting store..." | 08:17 |
| ogra_ | abeato, Bug #1638537 | 08:17 |
| mup | Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537> | 08:17 |
| abeato | ogra_, not sure if it is the same, I can enter console-conf, it fails when trying to contact the store | 08:19 |
| ogra_ | like ... with an error ? | 08:21 |
| ogra_ | or does it just sit there ? | 08:21 |
| ogra_ | if the latter ... give it time ... if not, thats something different then | 08:22 |
| abeato | ogra_, sits there, although it has just entered in the end... took really long :/ | 08:22 |
| ogra_ | yep, there is a fix ... but not landed yet | 08:22 |
| abeato | weird... | 08:22 |
| abeato | ok, good to know | 08:22 |
| ogra_ | it generates the device gpg key | 08:22 |
| abeato | ogra_, another thing, which is the recommended way to get wifi working on rpi3? | 08:23 |
| ogra_ | and go's routine for that is extremely resource consuming ... | 08:23 |
| ogra_ | configure with wired ... ssh in, run: sudo console-conf ... disable wired, enabled wlan, reboot | 08:23 |
| ogra_ | the wlan only has issues on the very first boot | 08:24 |
| abeato | ogra_, hm, is disabling wired needed? | 08:24 |
| ogra_ | not really ... just the german in me that wants it cleaned up :P | 08:24 |
| abeato | lol | 08:25 |
| abeato | thanks! | 08:25 |
| pstolowski | zyga, hey, do you have a moment to review #3182? it's just a test and I need 2nd review | 09:02 |
| zyga | pstolowski: yes, looking | 09:04 |
| zyga | pstolowski: stopped mid-way, brb | 09:10 |
| zyga | re | 09:20 |
| zyga | pstolowski: so, not sure I understand what's going on there, I'll ask a few questions if that's okay | 09:21 |
| nottrobin | how do I get the ownership of a snap transferred to a different user/namespace? | 09:23 |
| zyga | nottrobin: I think you can file a bug in the store | 09:24 |
| zyga | http://launchpad.net/snapstore | 09:24 |
| nottrobin | ta | 09:24 |
| zyga | fun fact: scaleway offers ubuntu without 'updates' repository enabled | 09:25 |
| zyga | so just security | 09:25 |
| zyga | and main | 09:25 |
| zyga | I just installed snapd 2.0.2 /o\ | 09:26 |
| nottrobin | bug filed: https://bugs.launchpad.net/snapstore/+bug/1682063 | 09:26 |
| mup | Bug #1682063: Transfer documentation-builder from nottrobin to canonicalwebteam <Snap Store:New> <https://launchpad.net/bugs/1682063> | 09:26 |
| ogra_ | zyga, hmm, we should probably make a deal with the security team to push it to -security in parallel (like kernels) ... that setup is surely not uncommon | 09:27 |
| zyga | pstolowski: commented | 09:32 |
| zyga | ogra_: yes, I agree | 09:32 |
| zyga | ogra_: but I also wonder if ubuntu is certified there | 09:32 |
| pstolowski | zyga, thanks! | 09:37 |
| ogra_ | zyga, well, disabling updates and leaving security on is not uncommon on servers i think | 09:38 |
| === pbek_ is now known as pbek | ||
| sbeattie | ogra_: we only push kernels to security when we know of security issues fixed in them; alas, that happens 90% of the time. But we do push non-security toolchain things to security (to fix security builds or boot issue breakages), I suspect snapd would fall under this area. | 09:43 |
| ogra_ | sbeattie, yeah | 09:44 |
| ogra_ | given the amount of apparmor and seccomp changes each release has :) | 09:44 |
| zyga | ogra_: aha, I didn't know that | 09:44 |
| zyga | ara: hey, certification question, do we (as canonical) give any guarantee what it means to run "ubuntu" wrt updates? are you expected to have updates disabled when you install ubuntu? | 09:45 |
| ara | zyga, not sure I understand the question | 09:46 |
| zyga | ara: the case is that scaleway offers xenial images but the sources.list file only lists xenial-security and custom scaleway repo | 09:46 |
| zyga | ara: you boot an ubuntu xenial instance from some cloud provider | 09:46 |
| ogra_ | zyga, by default they are always on ... but you can indeed preseed installs | 09:46 |
| zyga | ara: is it still ubuntu if they disabled updates by default? | 09:46 |
| ara | zyga, well, I think you are able to just keep xenial-security (kernel udpates go to the security pocket) | 09:47 |
| ara | zyga, that's why those are different pockets | 09:47 |
| ara | zyga, in case you just want security-updates but not bug fixes | 09:47 |
| ara | zyga, so I guess the answer might be "yes, that's still 'ubuntu'" | 09:48 |
| zyga | ara: aha, I see, thanks for clarifying that | 09:48 |
| zyga | ara: do you know if we certify scaleway images? | 09:48 |
| ara | zyga, no idea, you can ask that question to patricia, she may know | 09:49 |
| ara | zyga, (Gaughen) | 09:49 |
| zyga | thank you! :) | 09:49 |
| zyga | gaughen: do you know if we certify scaleway xenial images? | 09:50 |
| Chipaca | this multiple-services-in-one-snap demo thing is proving to be a trove of fails | 09:50 |
| Chipaca | e.g., install it, installation fails because one of the services doesn't start, installation undoes, random services left running | 09:51 |
| zyga | Chipaca: smells like 2.25 bugfix | 09:52 |
| Chipaca | if i can get to the bottom of it all in time, sure | 09:52 |
| Chipaca | :-) | 09:52 |
| Chipaca | those two random branches yesterday were a part of it | 09:52 |
| Chipaca | (and there's more weirdness in 'snap try', but i'm leaving that for later) | 09:52 |
| zyga | Chipaca: I kind of like EnsureDir approach | 09:54 |
| zyga | Chipaca: so we "ensure" service files are in place | 09:54 |
| zyga | Chipaca: or that they are fully gone | 09:54 |
| zyga | Chipaca: problem with stranded services is also interesting but separate | 09:54 |
| zyga | Chipaca: did we forget to kill them | 09:55 |
| zyga | Chipaca: or did they just refuse to die for some reason? | 09:55 |
| Chipaca | the service files go away as is appropriate | 09:55 |
| Chipaca | the services themselves don't | 09:55 |
| Chipaca | if i had answers to your questions i'd be a day ahead of where i am :-) | 09:55 |
| zyga | Chipaca: :-) | 09:56 |
| pedronis | Chipaca: we have a few things that have an undo, but not a undo what we did if we fail in the middle | 10:00 |
| pedronis | Chipaca: you can look at doLinkSnap for something that tries to do that properly | 10:00 |
| zyga | pedronis: idea | 10:01 |
| zyga | pedronis: not sure if good but still | 10:01 |
| zyga | pedronis: let's add a "cleanup stack" to a change | 10:01 |
| zyga | pedronis: any task can register cleanup actions that only get ran if we fail | 10:02 |
| pedronis | ? | 10:02 |
| zyga | pedronis: then if we fail we run the undo handlers and the cleanup list | 10:02 |
| pedronis | well we have cleanup | 10:02 |
| pedronis | nowadays for some stuff | 10:02 |
| zyga | pedronis: the reason is that this way each task can have fine-grained elements that get added as the task progresses | 10:02 |
| zyga | oh? | 10:02 |
| Chipaca | there's a cleanup task | 10:02 |
| zyga | so something like this exists? | 10:02 |
| pedronis | not like this | 10:02 |
| zyga | aha | 10:02 |
| zyga | I was thinking along the lines of: | 10:03 |
| pedronis | I'm mostly worried about the multiplication of concepts | 10:03 |
| zyga | (inside one task) | 10:03 |
| zyga | doA() | 10:03 |
| pedronis | we have undos | 10:03 |
| zyga | if not error, cleanupOnFailure(undoA) | 10:03 |
| zyga | doB() | 10:03 |
| zyga | if not error, cleanupOnFailure(undoB) | 10:03 |
| zyga | ... | 10:03 |
| pedronis | what we are not good at is dealing with the task that errored itself | 10:03 |
| zyga | aha | 10:03 |
| pedronis | but there's defer and stuff for that in theory | 10:03 |
| zyga | well | 10:03 |
| zyga | I worry that some of those concepts span one task | 10:04 |
| zyga | so a chain of tasks in one change assumes some structure | 10:04 |
| zyga | well | 10:04 |
| zyga | anyway, just an idea | 10:04 |
| zyga | I'm looking forward to see what Chipaca comes up with | 10:04 |
| pedronis | well if undoing one error span tasks | 10:04 |
| pedronis | then those tasks are not quite right | 10:04 |
| zyga | pedronis: I think we are in this situation now still | 10:05 |
| pedronis | that's a different kind of bug | 10:05 |
| pedronis | not a reason to add complexity | 10:05 |
| mup | PR snapd#3174 closed: interfaces,overlord: log interface auto-connection failures <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3174> | 10:06 |
| zyga | right, I agree | 10:06 |
| zyga | thank you mvo! | 10:06 |
| * zyga considers upgrading to 17.04 to run polaris as IRC client | 10:06 | |
| zyga | anyone doing that | 10:06 |
| zyga | it has nice UI and nice notification | 10:06 |
| pstolowski | zyga, refactored 3182 test per your commnet | 10:07 |
| pedronis | Chipaca: that's that don't manipulate state too much can usually be fixed by calling their undo manually on their failure path | 10:07 |
| pedronis | s/that's/tasks/ | 10:07 |
| mvo | zyga: 17.04 ftw! | 10:07 |
| zyga | mvo: are you on it? | 10:08 |
| pedronis | assuming they are correctly idempotent | 10:09 |
| pedronis | Chipaca: we basically need quite a few integration undo tests | 10:11 |
| pedronis | mmh, not undo | 10:12 |
| pedronis | error and undo to be precise | 10:12 |
| mvo | zyga: my workstation, works very well | 10:12 |
| Son_Goku | morphis_: yes | 10:12 |
| zyga | pstolowski: thank you! | 10:14 |
| zyga | pstolowski: checking | 10:14 |
| zyga | pstolowski: commented | 10:17 |
| pstolowski | zyga, looking, thanks | 10:18 |
| Chipaca | mvo— on unity 8? :-) | 10:23 |
| mvo | Chipaca: *cough* | 10:29 |
| pstolowski | zyga, ok, updated | 10:31 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/3183 :) | 10:38 |
| mup | PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183> | 10:38 |
| zyga | pstolowski: (replied to your PR, just add a comment there and +1) | 10:38 |
| zyga | pstolowski: have a look, you reviewed -1 in this series already | 10:38 |
| mup | PR snapd#3104 closed: tests: fix unity test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3104> | 10:39 |
| mup | PR snapd#3183 opened: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183> | 10:39 |
| zyga | pstolowski: not sure if I should parse mount and super-block options or optional fields deeply | 10:39 |
| zyga | Chipaca: go-ness review appreciated ^^ | 10:39 |
| Son_Goku | mvo: you have a typo in your release notes | 10:43 |
| Son_Goku | I think you mean "joystick" instead of "joystrick" | 10:43 |
| mvo | Son_Goku: autsch, thank you! I will fix it | 10:43 |
| Son_Goku | mvo: The 2.24 packages should synchronize out to updates-testing in Fedora in a few hours, so you can probably simultaneously mention Fedora and Ubuntu in the 2.24 release announcement | 10:44 |
| mvo | Son_Goku: awesome! you rock! | 10:46 |
| zyga | Son_Goku: awesome work! :) | 10:46 |
| * zyga might consider switching to Fedora 25 for daily work | 10:47 | |
| Son_Goku | mvo: I don't know if you make the release announcement usually before or after it is approved to go into ubuntu updates, so if you usually do it after, then I think we should probably push for people to test the Fedora package updates first | 10:47 |
| Son_Goku | zyga: :D | 10:47 |
| Son_Goku | Fedora master race :D | 10:47 |
| mvo | Son_Goku: I draft the release annoucement (its in the forum) and JamieBen_ is now handling the announcing, but usually we announce when its in -proposed | 10:48 |
| === JamieBen_ is now known as JamieBennett | ||
| Son_Goku | speak of the devil :P | 10:49 |
| JamieBennett | :) | 10:49 |
| Son_Goku | but yeah, I submitted the updates to be released to updates-testing yesterday | 10:50 |
| zyga | (especially if someone asks me to work on selinux) | 10:50 |
| zyga | I need to spend some time at the forum today | 10:50 |
| Son_Goku | so they should go out in a couple hours or so | 10:50 |
| Son_Goku | people are also now asking about being able to craft Fedora-based snaps too | 10:50 |
| zyga | Son_Goku: this is a compound question, we can craft a snap that uses fedora bits on top of the current ubuntu-based core snap or a fully fedora based "base" snap that we don't support yet | 10:54 |
| Son_Goku | yeah, I know | 10:54 |
| zyga | Son_Goku: I think we should get base snaps first | 10:54 |
| sborovkov | Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior? | 10:54 |
| morphis_ | Son_Goku: btw. you want to push 2.24 to stable already now? | 10:54 |
| Son_Goku | zyga: well we can't do either right now, because snapcraft needs work | 10:55 |
| zyga | Son_Goku: then we will be able to do what people are really asking for: snapd not tied to ubuntu "base" | 10:55 |
| Son_Goku | zyga: yes | 10:55 |
| zyga | Son_Goku: note that snapcraft is not the only way to make snaps | 10:55 |
| Son_Goku | I know, but it's what we're pushing | 10:55 |
| zyga | Son_Goku: I think initially it is fine to just hand-craft snaps :) | 10:55 |
| zyga | (I love that hame) | 10:55 |
| zyga | name* | 10:55 |
| morphis_ | Son_Goku: one thing I talked with zyga about earlier today was that we wait for the official release date as everyone is having it just as candidate right now | 10:55 |
| zyga | Son_Goku: I think snapcraft can only really be done when we have base snaps | 10:55 |
| Son_Goku | yes | 10:55 |
| Son_Goku | morphis_: what *is* the official release date? | 10:56 |
| morphis_ | 4/24 | 10:56 |
| Son_Goku | April 24?! | 10:56 |
| Son_Goku | for 2.24? | 10:56 |
| morphis_ | yes | 10:56 |
| === morphis_ is now known as morphis | ||
| morphis | yes | 10:56 |
| Son_Goku | wow, that's two weeks from now | 10:56 |
| zyga | Son_Goku: that's confusing | 10:56 |
| morphis | Son_Goku: that is the regular candence time period for a snapd release | 10:56 |
| zyga | the reality is this: | 10:56 |
| zyga | 2.24 is in candidate/beta channel now | 10:56 |
| morphis | through those two weeks it goes through all kinds of QA | 10:56 |
| zyga | it's not a stable release | 10:56 |
| zyga | it's a source tarball release | 10:57 |
| zyga | + invitation to test the binary | 10:57 |
| zyga | since we have channels and are actively using them | 10:57 |
| zyga | the term "release" is not the same | 10:57 |
| zyga | as we traditionally are used to | 10:57 |
| zyga | I think we need to write this down | 10:57 |
| zyga | and use clear terminology all the time | 10:57 |
| morphis | zyga: but if you take the original "release" term, the release date is April 24 and what we have today is more of a 2.24-rc1 | 10:57 |
| zyga | and attach a short summary to each announcement | 10:58 |
| Son_Goku | wow, there was literally no point in me pushing 2.24 at all, then | 10:58 |
| morphis | Son_Goku: there is! | 10:58 |
| zyga | morphis: exactly so | 10:58 |
| morphis | Son_Goku: we need to send calls out for testing in the community | 10:58 |
| Son_Goku | morphis: the problem is that if I'm ahead of Ubuntu, things are going to be broken | 10:58 |
| Son_Goku | VERY broken | 10:58 |
| morphis | a bodhi request is fine but it should land until th real 2.24 is out | 10:58 |
| Son_Goku | Ubuntu moves too slowly in almost every regard when it comes to this | 10:58 |
| Son_Goku | but if we're going to hold back the final release, I better turn off the autopush | 10:59 |
| zyga | Son_Goku: why would they be broken? | 10:59 |
| zyga | Son_Goku: yes, please turn off autopush for this | 10:59 |
| Son_Goku | because the core snap is always broken on classic distros when it has an older snapd than what I run | 11:00 |
| zyga | Son_Goku: are you sure/ | 11:00 |
| zyga | Son_Goku: why would it be broken? | 11:00 |
| * Son_Goku shrugs | 11:00 | |
| * zyga tries to understand | 11:00 | |
| zyga | Chipaca: thanks for the feedback | 11:00 |
| zyga | Chipaca: I think I'll leave the int parsing asis | 11:00 |
| Son_Goku | it's not worth debugging because it's a spaghetti of interface things and weird errors | 11:00 |
| zyga | Chipaca: but I was wondering about OptinalFlds | 11:01 |
| zyga | Chipaca: and mount and super-block option | 11:01 |
| zyga | Son_Goku: I mean, what error did you see | 11:01 |
| Son_Goku | mainly non-existent interface errors | 11:01 |
| zyga | Chipaca: should I call it OptionalFields and make it []string that I really parse? | 11:01 |
| Son_Goku | they have no practical effect on Fedora now, since interfaces mean nothing | 11:01 |
| zyga | Son_Goku: which interface specifically? | 11:01 |
| zyga | Son_Goku: this may be an unrealted bug that I need to fix | 11:01 |
| zyga | (same happens on ubuntu now) | 11:01 |
| Son_Goku | well, I don't remember, since this was a week ago | 11:02 |
| zyga | is it about network-bind or core-support? | 11:02 |
| Chipaca | zyga— ah, i might be the wrong person to talk with about names. OptionalFields is probably better than OptionalFlds though | 11:02 |
| Son_Goku | core-support, I think | 11:02 |
| zyga | if so this is a harmless note and I do need to correct that | 11:02 |
| zyga | there's a branch that's pending merge and it will be in 2.25 | 11:02 |
| Chipaca | zyga— about whether to leave it as an array, depends what you use it for | 11:02 |
| Son_Goku | though it might have also been network stuff *shrugs* | 11:02 |
| Son_Goku | in any case, it has no appreciable affect in Fedora | 11:02 |
| zyga | Son_Goku: both are expected | 11:02 |
| Son_Goku | since confinement is broken | 11:02 |
| zyga | Son_Goku: it's not really related to confinement this time :) | 11:02 |
| zyga | Son_Goku: it is the thing where we renamed plugs and there's no nice method to forget old connection | 11:03 |
| Son_Goku | well, the interface/plug stuff is enforced through AppArmor | 11:03 |
| zyga | Chipaca: ok, let's review/land this and I'll follow up with better names and perhaps deeper parsing | 11:03 |
| zyga | mvo: can you review/land https://github.com/snapcore/snapd/pull/3183 for further iteration? | 11:03 |
| mup | PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183> | 11:03 |
| Son_Goku | zyga, mvo, morphis: Bodhi's auto push on +3 stable karma is disabled | 11:04 |
| morphis | Son_Goku: good! | 11:04 |
| zyga | Son_Goku: thank you! | 11:04 |
| Son_Goku | now it's basically up to me to push if no one tests after 7 days | 11:04 |
| zyga | mvo: maybe we can edit the forum post here to indicate when we expect to release it in binary form and when was the source tarball released | 11:05 |
| pedronis | zyga: Chipaca: yes, Opts is kind of common, Flds not as much | 11:05 |
| zyga | https://github.com/snapcore/snapd/pull/3183 | 11:05 |
| mup | PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183> | 11:05 |
| zyga | pedronis: +1 | 11:05 |
| Son_Goku | morphis, zyga: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/LT2Y5JKCT2FIM2Q6HMZHNTEXEPGW4JZI/ | 11:05 |
| zyga | pedronis: I'm inclined to spell it Options as that matches mount.Entry for fstab | 11:05 |
| morphis | Son_Goku: nice! | 11:06 |
| mvo | zyga: sure, go ahead, its a wiki (I think) | 11:06 |
| Son_Goku | zyga, since we're going to have Fedora in parallel to Ubuntu, might as well make the announcement reflect that | 11:08 |
| zyga | mvo: can you push the 2.24 tag to master? | 11:08 |
| zyga | mvo: ah, I see it now | 11:09 |
| zyga | sorry | 11:09 |
| mvo | zyga: :) | 11:10 |
| zyga | mvo: edited | 11:10 |
| mvo | ta | 11:11 |
| sborovkov | Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior? Is that done by configure hook or what? | 11:14 |
| morphis | sborovkov: sounds more like the wrong config.txt gets copied into place | 11:15 |
| mvo | sborovkov: I think its done by the configure hook, it will unset things that it has not in the internal snapd config iirc | 11:15 |
| * zyga switches gears for a moment | 11:16 | |
| morphis | mvo: isn't that coming with 2.24 or is already part of 2.23? | 11:16 |
| mvo | morphis: 2.23.6 has a bug so yeah, only in 2.24 | 11:16 |
| sborovkov | mvo: any idea how to change that? I mean I could set those config options myself but that would require additional restart | 11:16 |
| morphis | sborovkov: so from which channel is your core snap coming? | 11:16 |
| sborovkov | edge | 11:17 |
| morphis | ah | 11:17 |
| sborovkov | morphis: can't be wrong config.txt - otherwise all my options would not be in there even commented out | 11:17 |
| morphis | sborovkov: any specific reason to use edge? | 11:17 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/3184 | 11:17 |
| mup | PR snapd#3184: store: misc cleanups in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3184> | 11:17 |
| zyga | sborovkov: maybe bug in ubuntu-image | 11:17 |
| zyga | sborovkov: wrt channels | 11:18 |
| sborovkov | morphis: yes. because it has a bunch of resloved bugs that are blockers | 11:18 |
| zyga | I think it handles that poorly now | 11:18 |
| mup | PR snapd#3184 opened: store: misc cleanups in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3184> | 11:18 |
| morphis | sborovkov: ah I see | 11:18 |
| sborovkov | also a bit annoying that you can't make ubuntu-image to use your snap for instance from edge channel but core snap from the beta | 11:18 |
| morphis | sborovkov: you can manually add snaps to your resulting image | 11:19 |
| mvo | sborovkov: we could change the configure hook code to simply ignore anything that is not set. the downside is of course that if you snap core set pi-config.something="" that would go directly into config.txt, i.e. there is no way anymore to uncomment things. but maybe thats ok | 11:19 |
| * mvo is away for lunch | 11:19 | |
| sborovkov | mvo: I am ok with everything. Though just for my case since I build gadget snap myself can't I set those options manually somewhere? So it does not unset them. | 11:20 |
| morphis | sborovkov: https://gist.github.com/morphis/abdc1e83ba0578e756073bd89fa128ed | 11:20 |
| morphis | sborovkov: especially https://gist.github.com/morphis/abdc1e83ba0578e756073bd89fa128ed#file-create-image-sh-L225 | 11:20 |
| morphis | sborovkov: if you download the snap before together with its assertion via snap download you can drop the unasserted: true | 11:21 |
| zyga | morphis: scaleway arm servers use patched non ubuntu kernel | 11:22 |
| zyga | morphis: no chance for apparmor | 11:22 |
| zyga | morphis: I don't think it's worth pursuing yet | 11:22 |
| morphis | zyga: ah | 11:23 |
| morphis | zyga: the better go with what plars is building | 11:23 |
| zyga | morphis: yes | 11:23 |
| zyga | morphis: I'll check their x86 VMs out of curiosity | 11:23 |
| morphis | :-) | 11:23 |
| renat | Hi, guys=) It's Renat from Screenly=) | 11:24 |
| renat | Hi, sborovkov=) | 11:24 |
| morphis | renat: hey! | 11:27 |
| renat | I have just a small question - snappy core doesn't ship with udisks2 installed, and I should install udisks2 into my snap, is it correct? | 11:27 |
| morphis | renat: we have a udisks2 snap in the store you can | 11:27 |
| morphis | renat: you wont be able to get udisks2 into your own snap | 11:27 |
| pstolowski | Chipaca, hey, are you working on any of this https://forum.snapcraft.io/t/easy-way-to-get-last-change/246 ? | 11:28 |
| renat | morphis, thanks! That's exactly what I need! | 11:28 |
| Chipaca | pstolowski— negatory | 11:28 |
| morphis | renat: there is upcoming documentation for that snap which is currently available here: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/udisks2/tree/docs | 11:28 |
| morphis | renat: but the same will be soon on docs.ubuntu.com | 11:29 |
| pstolowski | Chipaca, ok. bonus question then | 11:29 |
| renat | Thanks, morphis! | 11:29 |
| Chipaca | I should charge for these | 11:29 |
| morphis | davidcalle: you know when a new deployment of the docs will happen? | 11:29 |
| morphis | davidcalle: especially for https://github.com/CanonicalLtd/ubuntu-core-docs/pull/29 ? | 11:29 |
| mup | PR CanonicalLtd/ubuntu-core-docs#29: Enable udisks2 documentation and fix up broken links <Created by jhodapp> <Merged by caldav> <https://github.com/CanonicalLtd/ubuntu-core-docs/pull/29> | 11:29 |
| pstolowski | Chipaca, yesterday on the standup we discussed making "task" alias for "change" command (and make the latter hidden but still supported), but reading that forum topic makes me think that perhaps I missed something | 11:31 |
| Chipaca | the other way around, making change alias for task | 11:31 |
| Chipaca | i did not update the forum after the meeting | 11:31 |
| Chipaca | also, tasks, not task | 11:31 |
| davidcalle | morphism: later today | 11:31 |
| pstolowski | Chipaca, ah! | 11:31 |
| Chipaca | 1 change -> multiple tasks | 11:31 |
| davidcalle | morphis | 11:32 |
| sborovkov | mvo: I am still a bit confused. On the first boot pi-config is not actually set. But it's not like it removes kernel, dtparam and so on and so on from config.txt? Or is it not touching them because they can't be changed via configure hook? | 11:32 |
| pstolowski | chihchun, "tasks" yes. suddenly it all makes more sense and you will not get any more bonus questions, i'm sorry | 11:32 |
| Chipaca | pstolowski— and it wouldn't be an alias in the sense that go-flags supports aliases; it'd be a separate hidden command that just calls the other one | 11:32 |
| pstolowski | uh, Chipaca ^ | 11:32 |
| pstolowski | Chipaca, yes yes sure | 11:32 |
| Chipaca | woah, you need four chars to get my name | 11:33 |
| === Chipaca is now known as __chip__ | ||
| __chip__ | there | 11:33 |
| __chip__ | now i'm special | 11:33 |
| zyga | morphis: can we relase 2.24 jointly to suse too? | 11:33 |
| * __chip__ looks at _28Kb | 11:33 | |
| pstolowski | in fact I did this change already in cmd, it just felt strange.. "tasks" it's then | 11:33 |
| __chip__ | pstolowski— how does it feel strange? | 11:33 |
| Son_Goku | davidcalle: can we have snappy-docs move to the snapcore org? | 11:34 |
| pstolowski | __chip__, only in that's mutiple tasks realy, plural | 11:34 |
| morphis | zyga: yes, working on that | 11:34 |
| __chip__ | pstolowski— ah :-) | 11:34 |
| ogra_ | ooh .... Chipaca has wings! | 11:35 |
| jdstrand | mvo: not sure if you saw, but fyi https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023 | 11:36 |
| mup | Bug #1682023: snapd/snap-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1682023> | 11:36 |
| zyga | morphis: sounds good | 11:36 |
| jdstrand | mvo: at, it looks like you probably did see it now that I am reading backscroll | 11:38 |
| mup | PR snapcraft#1247 closed: Fixing Store integration tests <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1247> | 11:45 |
| jdstrand | mvo: responded in 3181 | 11:45 |
| zyga | jdstrand: hey | 11:47 |
| zyga | jdstrand: can you have a look at https://github.com/snapcore/snapd/pull/3138 -- it is a tiny RFC branch about mounting | 11:48 |
| mup | PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138> | 11:48 |
| pstolowski | http://www.omgubuntu.co.uk/2017/04/use-snap-fedora | 11:50 |
| zyga | mvo: can you have a 2nd look to ensure that we want to land https://github.com/snapcore/snapd/pull/3160/files | 12:08 |
| mup | PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160> | 12:08 |
| mup | PR snapd#3182 closed: store: tests for unexpected EOF <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3182> | 12:09 |
| pstolowski | zyga, ^ you will probably need to merge master into 3184 | 12:09 |
| zyga | pstolowski: looking | 12:10 |
| zyga | aha | 12:10 |
| zyga | thanks! | 12:10 |
| * zyga is a bit hungry and parched, sounds like a time for a break | 12:11 | |
| zyga | done | 12:12 |
| zyga | see you at the stand-up | 12:12 |
| zyga | niemeyer: please have a look at https://github.com/snapcore/snapd/pull/3138 -- it is on the critical path for update-ns now | 12:13 |
| mup | PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138> | 12:13 |
| morphis | zyga, mvo: looks like spread tests are a bit flawky today, is that known? | 12:16 |
| zyga | morphis: URL please | 12:20 |
| zyga | morphis: I didn't see any failures | 12:20 |
| morphis | https://s3.amazonaws.com/archive.travis-ci.org/jobs/221306064/log.txt | 12:21 |
| morphis | linode:ubuntu-14.04-64:tests/main/refresh-delta-from-core is failing here | 12:21 |
| morphis | zyga: that is for https://github.com/snapcore/snapd/pull/3170 | 12:21 |
| mup | PR snapd#3170: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170> | 12:21 |
| mup | PR snapd#3185 opened: snap: added tasks subcommand <Created by stolowski> <https://github.com/snapcore/snapd/pull/3185> | 12:23 |
| mvo | morphis: https://forum.snapcraft.io/t/autopkgtest-failues-with-master/260 - I think its because of the interfaces change but I did not look deeper | 12:24 |
| morphis | mvo: hm ok | 12:25 |
| morphis | then let me don't count on this and I will wait until the dust settles :-) | 12:25 |
| zyga | morphis: just merge master | 12:25 |
| zyga | aha | 12:26 |
| zyga | the failure is in delta-from-core | 12:26 |
| zyga | morphis: you just joined and disconnected | 12:30 |
| === __chip__ is now known as Chipaca | ||
| mup | PR snapcraft#1252 opened: ci: split plugin integration tests out <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1252> | 12:57 |
| Son_Goku | zyga, morphis: https://lists.fedoraproject.org/admin/lists/ci.lists.fedoraproject.org/ | 13:21 |
| zyga | Son_Goku: I got 503 | 13:22 |
| Son_Goku | hmm, Postorius seems to be down | 13:23 |
| zyga | aha | 13:23 |
| zyga | what was the thing behind the URL? | 13:23 |
| zyga | ah, it's up now | 13:24 |
| Son_Goku | the mailing list for Fedora CI | 13:24 |
| morphis | ah :-) | 13:25 |
| morphis | 403 forbidden for me | 13:25 |
| morphis | zyga: btw. did you manage to file all bugs for the SELinux denials on Fedora? | 13:27 |
| zyga | morphis: I filed two | 13:27 |
| zyga | morphis: I didn't file more as we need to check if it makes sense | 13:27 |
| morphis | zyga: have those two on my list | 13:27 |
| morphis | good | 13:27 |
| zyga | morphis: and I think we need to see if the format is right | 13:27 |
| zyga | morphis: I can file the rest | 13:28 |
| morphis | zyga: lets wait with that | 13:30 |
| morphis | I will look first and then we can decide | 13:31 |
| Chipaca | niemeyer— want me to open a topic about snap service? | 13:44 |
| niemeyer | Chipaca: Almost done with it already | 13:44 |
| Chipaca | niemeyer— :-D | 13:44 |
| * zyga goes to eat that lunch he was meant to earlier | 13:44 | |
| zyga | I'll focus on focum / email after that | 13:45 |
| zyga | enjoy easter holidays o/ | 13:45 |
| niemeyer | Chipaca: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262 | 13:53 |
| Pharaoh_Atem | zyga, morphis, sergiusens: don't forget to respond to mattdm's email :) | 13:56 |
| sergiusens | Pharaoh_Atem: yeah, I'll reply with what I know, but leave the other paragraphs we discussed to zyga or morphis | 13:56 |
| Pharaoh_Atem | sergiusens: that's fine | 13:59 |
| ogra_ | hah ... the right keyboard for core developers ... finally ... https://www.massdrop.com/buy/vortex-core-47 | 13:59 |
| Chipaca | ogra_— what, no GOTO key? | 14:00 |
| ogra_ | probably at the bottom :) | 14:00 |
| Chipaca | ogra_— http://4.bp.blogspot.com/-lUibvtAqm2E/UYVrSpG_4MI/AAAAAAAAAxE/oov7bXRCLw4/s1600/keyboard.jpg | 14:00 |
| ogra_ | ! | 14:01 |
| Chipaca | ogra_— or, rather, http://images.eurogamer.net/2013/articles/1/6/5/1/7/8/3/139143204009.jpg/EG11/resize/600x-1/quality/80/format/jpg | 14:01 |
| ogra_ | yeah, i think popey raved about that one before on G+ | 14:01 |
| Chipaca | heh | 14:01 |
| Chipaca | massdrop is so expensive from uk though | 14:02 |
| Chipaca | also, i can't really justify another keyboard | 14:02 |
| Chipaca | it is a beaut tho | 14:02 |
| ogra_ | heh, yeah, i ddint mean to push you towards buying it ... | 14:02 |
| jdstrand | niemeyer: fyi, I plan to start an 'ownership' topic today. I can layout the various use case that have been accumulating as well as what we discussed yesterday | 14:02 |
| jdstrand | cases* | 14:03 |
| ogra_ | i'm typing on the pok3er ... next bigger model with 67 keys | 14:03 |
| jdstrand | niemeyer: and hi! | 14:03 |
| jdstrand | niemeyer: I figured it might be easier this way since I've thought about this for a while (ie, if I lay it out rather than responding with other use cases) | 14:03 |
| niemeyer | jdstrand: Sounds great, thank you! | 14:04 |
| jdstrand | np | 14:04 |
| Chipaca | cuppa tea anyone? | 14:10 |
| * Chipaca goes | 14:10 | |
| * tvoss tea, earl grey, hot | 14:12 | |
| * genii hugs his pot of coffee instead | 14:13 | |
| * ogra_ joins genii in huggung coffee pots | 14:14 | |
| morphis | zyga: the export_test.go trick is good, but how can I share the best way a Mock* method across modules? | 14:18 |
| morphis | adding it to testsutils? | 14:19 |
| tvoss | niemeyer: hey, https://github.com/snapcore/snapd/pull/3130 just went green :) would be great if you could have a look | 14:21 |
| mup | PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 14:21 |
| niemeyer | tvoss: WIll do.. a bit busy this morning, but will do in the afternoon | 14:23 |
| tvoss | niemeyer: great, thank you | 14:23 |
| * tvoss goes to build docker snaps with configurable cert directory | 14:24 | |
| ogra_ | would be awesome if that finally landed | 14:24 |
| ogra_ | so much back and forth ... | 14:24 |
| Chipaca | tvoss— now rewrite it using libressl | 14:25 |
| * Chipaca hides | 14:25 | |
| tvoss | Chipaca: I would rather look at golang's BigInt and optimize that a little ;) | 14:26 |
| ogra_ | make it EvenBiggerInt | 14:26 |
| === chihchun is now known as chihchun_afk | ||
| bspock | Which folder should be added in my $PATH in order to run the installed snaps? | 14:27 |
| ogra_ | bspock, the snapd package adds that autiomatically ... | 14:28 |
| ogra_ | (you need to log out and back in if you only just installed snapd though) | 14:28 |
| bspock | ogra_: Ah, that's probably my problem. Will try that, thanks | 14:28 |
| ogra_ | your path should then have /snap/bin at the end | 14:28 |
| Chipaca | tvoss— just math/big.divWVW | 14:29 |
| Chipaca | tvoss— although math/big.bitLen probably also | 14:29 |
| tvoss | yup, gcd might be candidate as well, haven't look further, though | 14:29 |
| tvoss | looked | 14:29 |
| sborovkov | mvo: btw why does rpi-config has _ converted to '-'. But not everywhere? :) Like here - framebuffer-ignore_alpha | 14:46 |
| kyrofa | sborovkov, OCD sniping? | 14:50 |
| kyrofa | I'm unhappy you even typed it here :P | 14:50 |
| kyrofa | ogra_ might have an idea | 14:51 |
| Chipaca | sborovkov, kyrofa, different things | 14:53 |
| Chipaca | _ is within a name | 14:53 |
| Chipaca | - is between scopes | 14:53 |
| Chipaca | levels | 14:53 |
| Chipaca | whatever you want to call them :-) | 14:53 |
| kyrofa | Ah, thanks Chipaca :) | 14:53 |
| Chipaca | there's a hierarchy in there | 14:53 |
| stub | -_- | 14:53 |
| Chipaca | totally (-_-) | 14:54 |
| Chipaca | (i wasn't saying it was a *good* reason :) ) | 14:54 |
| sborovkov | Hmm, alright. It's just not very convenient when you have a list of config.txt options you want to actually set | 14:58 |
| sborovkov | Because they all need converted according to different rules then | 14:58 |
| Chipaca | sborovkov— do you think you could raise the issue on the forum? | 15:00 |
| Chipaca | sounds like something that needs to be spelled out in more detail | 15:00 |
| sborovkov | Chipaca: sure, what forum are you talking about | 15:00 |
| Chipaca | sborovkov— forum.snapcraft.io | 15:01 |
| ogra_ | sborovkov, see topic :) | 15:01 |
| Chipaca | :-) | 15:01 |
| sborovkov | Damn, did not think of that | 15:01 |
| sborovkov | Like that's just a bit inconvenient. Can't even replace dashes with underscores. Because there gpu-mem-256. Need to have 2 maps to convert it. | 15:01 |
| mup | PR snapd#3186 opened: tests: allow installing snapd from -proposed for SRU validation <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3186> | 15:11 |
| t-mon | Hi everyone! I'wanted to ask how I can access gpio's from my snap since the gpio interface is missing on my system. I'm using snapd on a debian. Is there any other way how I can workaround this for development? | 15:12 |
| t-mon | Should I move this question to the forum? | 15:13 |
| Nicolino_ | hi all : i don't find a command for producing a list of all avalaible revision of a snap on the store | 15:15 |
| Chipaca | Nicolino_— snapcraft history, i think? | 15:15 |
| Nicolino_ | thanks | 15:15 |
| Nicolino_ | also fot the core? | 15:15 |
| sborovkov | Chipaca: according to this hierarchy how are those options called? config_hdmi_boost, hdmi_force_hotplug (I am not sure how to query all supported names...) | 15:15 |
| Chipaca | Nicolino_— "for the core"? you mean for the core snap? | 15:16 |
| Chipaca | Nicolino_— you can only get the list of revisions of the snaps you have dev rights to | 15:16 |
| Chipaca | i mean upload privs | 15:16 |
| Nicolino_ | yes i mean core snap | 15:16 |
| ogra_ | well ... there is "snap info core" | 15:16 |
| ogra_ | but that only shopws current versions | 15:17 |
| Chipaca | Nicolino_— you can't get a list of all revisions | 15:17 |
| Chipaca | Nicolino_— you can get a list of published revisions, via 'snap info' | 15:17 |
| Nicolino_ | i would test my uboot setting with a core upgrade | 15:17 |
| Nicolino_ | i create an device image right now Chipaca | 15:18 |
| ogra_ | Nicolino_, just switch channels then | 15:18 |
| Chipaca | Nicolino_— you could `snap refresh --beta core`, starting from stable | 15:18 |
| Chipaca | yeah | 15:18 |
| ogra_ | snap refresh core --edge | 15:18 |
| Nicolino_ | thanks a lot to all :D | 15:18 |
| ogra_ | (and to switch back later just replace --edge with --stable) | 15:18 |
| Chipaca | ogra_— http://i.imgur.com/XbjbHlM.jpg | 15:27 |
| ogra_ | :D | 15:27 |
| mup | PR snapd#3183 closed: interfaces/mount: add parser for mountinfo entries <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3183> | 15:49 |
| Croepha | anyone know off hand an easy way to get usb keyboard in the initramfs shell? | 15:56 |
| pstolowski | it would be great to get 2nd review for 3184 and land it quickly, a trivial MP | 15:58 |
| Chipaca | Croepha— ogra_, if anyone | 16:33 |
| mup | PR snapd#3184 closed: store: misc cleanups in tests <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3184> | 16:33 |
| mup | PR snapcraft#1252 closed: ci: split plugin integration tests out <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1252> | 16:33 |
| mvo | sborovkov: autsch, if it does not do it everywhere that is a bug | 16:40 |
| sborovkov | mvo: IS there a way to query all supported keys? I was checking the names from your post actually https://forum.snapcraft.io/t/configuration-options-for-core-snap/87 - specifically framebuffer-ignore_alpha | 16:52 |
| ogra_ | Croepha, no easy way i fear ... you would have to re-pack it and add the respective modules (or simply use a serial console) | 16:52 |
| Croepha | ogra_, ok thanks, this is a custom kernel I made 6 months ago, I just finished downloading the Intel NUC image for 16, hopefully that will work, if not I'll rebuild | 16:54 |
| sborovkov | mvo: or was that typo in the post and I can just replace underscores with dashes? :-) | 16:54 |
| ogra_ | well, that wont have hid modules either in the initrd | 16:54 |
| Croepha | for the record, im actually using the intel compute stick, and several months ago, the kernel that shipped with didn't have good support for the hardware | 16:55 |
| ogra_ | we are very explicit to only include drivers that are needed to find the rootfs | 16:55 |
| Croepha | ogra_: ok good to know, im hoping that maybe the new kernel might fix another problem and make the initramfs KB driver unessasary | 16:55 |
| Croepha | but if it doesn't, then I might pop open the device physically and look for serial headers | 16:56 |
| ogra_ | that could well be, i remember adding some modules on request of the team that was working with the NUC | 16:56 |
| Croepha | that might be easier then using a custom kernel | 16:56 |
| ogra_ | afaik the normal pc-kernel snap should now work | 16:56 |
| Croepha | btw, is the NUC image the same as the regular amd64 image? | 16:57 |
| Croepha | like, is it a generic kernel? | 16:57 |
| ogra_ | not sure ... there might be additional snaps in it by defult | 16:57 |
| ogra_ | the kernel is definitely the same though | 16:58 |
| Croepha | ok good to know | 16:58 |
| Croepha | thanks | 16:58 |
| ogra_ | that got fixed between 15.04 and 16 snappy images | 16:58 |
| Croepha | I just got a USB 3 thumb-drive, eager to see the perf differences first hand | 17:00 |
| Croepha | I wanted to try the new image, but didn't want to overwrite the image that kinda works on my other thumbdrive | 17:00 |
| Croepha | ehh, a bit underwhelming | 17:06 |
| niemeyer | tvoss: reviewed, thanks for all the work there! | 17:08 |
| sborovkov | mvo: yeah, it was typo in your post. Nice. Cause I was already doing 2 maps to convert back and forth :-) | 17:30 |
| Croepha | ogra_ im assuming that the serial interface for the initramfs requires a real BIOS serial port, i.e. a USB to serial wont work? | 17:46 |
| ogra_ | USB to serial would be exactly the opposite | 17:46 |
| ogra_ | so no, i dont think it would | 17:46 |
| Croepha | right, thanks, figured Id ask | 17:47 |
| jdstrand | morphis: I want to think about your bug #1647168 more but will ask here, quickly, snap-confine 1.0.43? shouldn't you be on at least 2.22.6 if not 2.23.6 (proposed)? | 18:10 |
| mup | Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168> | 18:10 |
| morphis | jdstrand: that bug is quite old but thanks for looking into that! | 18:25 |
| morphis | jdstrand: need to see if I can still reproduce this with the latest snapd/snap-confine | 18:26 |
| morphis | jdstrand: http://anbox.io/ is the application I was experiencing this with | 18:26 |
| === nacc is now known as Guest42667 | ||
| === nacc_ is now known as nacc | ||
| pompomJuice | hi | 18:58 |
| kyrofa | Hey there pompomJuice, welcome | 18:58 |
| Croepha | it appears that the pc-kernel rev 60 doesn't support HDMI audio on the intel compute stick | 19:01 |
| pompomJuice | How do I get snappy install to install my locally made snapcraft packages? the unauthorized setting does not work? | 19:02 |
| pompomJuice | Installing my-open-vm-tools_0.1_amd64.snap Signature verification failed with exit status 14 | 19:02 |
| kyrofa | pompomJuice, what do you mean mine "unauthorized setting?" | 19:02 |
| kyrofa | s/mine/by/ | 19:02 |
| kyrofa | pompomJuice, ah, installing local snaps requires you to use the --dangerous flag | 19:03 |
| pompomJuice | kyrofa: snappy install --allow-unauthenticated my-open-vm-tools_0.1_amd64.snap | 19:03 |
| pompomJuice | none of those things work with snappy | 19:03 |
| pompomJuice | just snap | 19:03 |
| kyrofa | pompomJuice, ah, that's snappy 15 speak | 19:03 |
| kyrofa | pompomJuice, it's changed a bit since then | 19:03 |
| pompomJuice | So are these snappy cloud images usable? | 19:03 |
| Croepha | so, what is the appropriate bug tracker for getting patches into the core kernel? | 19:04 |
| pompomJuice | I cannot change the channel and I cannot install dangerous modes | 19:04 |
| kyrofa | pompomJuice, https://askubuntu.com/questions/822765/snap-install-failure-error-cannot-find-signatures-with-metadata-for-snap | 19:04 |
| kyrofa | pompomJuice, is that what you're seeing? | 19:04 |
| pompomJuice | kyrofa: Yes know about those options. The problem I have is I am trying to use the ubuntu core cloud image. It does not comes with snapd. Rather with "snappy"... a front end of sorts for snap | 19:05 |
| kyrofa | pompomJuice, that sounds wrong | 19:06 |
| pompomJuice | it has different options | 19:06 |
| kyrofa | ogra_, do you know anything about that ^^ ? | 19:06 |
| pompomJuice | it does sound wrong! | 19:06 |
| pompomJuice | I want snapd | 19:06 |
| pompomJuice | it has what I need | 19:06 |
| kyrofa | pompomJuice, yeah, the command called "snappy" is very old. It sounds like you're using a distro based on 15.04 | 19:06 |
| pompomJuice | but this cloud image comes with a noob mode snappy so I was wondering what is going on | 19:06 |
| kyrofa | pompomJuice, what cloud image are we talking about? Do you have a link? | 19:07 |
| pompomJuice | kyrofa: http://cloud-images.ubuntu.com/snappy/devel/core/current/ | 19:08 |
| kyrofa | pompomJuice, whoa, super old | 19:08 |
| kyrofa | That is indeed 15.04 | 19:09 |
| pompomJuice | ok lol | 19:10 |
| pompomJuice | no wonder I am getting nowhere with this | 19:10 |
| pompomJuice | thanksman | 19:10 |
| jdstrand | morphis: oh weird that it is quite old, I only just saw it recently | 19:14 |
| zyga | hey guys | 19:17 |
| morphis | jdstrand: you think it could have been a bug in snap-confine? | 19:18 |
| morphis | zyga: hey! :-) | 19:18 |
| jdstrand | morphis: there is a lot going in with bind mounts. I'm not prepared to say what the problem is | 19:19 |
| zyga | what are you chatting about? | 19:19 |
| jdstrand | though I have a lot of concerns regarding /dev/binder | 19:19 |
| morphis | jdstrand: ok, then let me try that again and see if is still a problem | 19:19 |
| jdstrand | going on* | 19:19 |
| morphis | zyga: https://launchpad.net/bugs/1647168 | 19:19 |
| mup | Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168> | 19:19 |
| zyga | aha | 19:20 |
| zyga | This is with snap-confine 1.0.43 on Ubuntu 16.04 | 19:20 |
| jdstrand | hey zyga | 19:20 |
| zyga | snap-confine 1.0.43 | 19:20 |
| jdstrand | yeah, that was what I mentioned | 19:20 |
| jdstrand | too old | 19:20 |
| * zyga reads the bug | 19:20 | |
| jdstrand | zyga: fyi, I'm not actively looking at it atm. it is on my list to circle back to cause I have some pretty strong opinions about /dev/binder | 19:21 |
| zyga | morphis: do you have the apparmor denials at hand? | 19:21 |
| zyga | jdstrand: binder is the android RPC-like IPC right? | 19:21 |
| jdstrand | yes | 19:21 |
| zyga | you syscall and start executing in the same time slice, in another process | 19:21 |
| jdstrand | it is a window to a whole new, glorious attack sruface... err... world | 19:22 |
| morphis | zyga: it is, not I don't that is quite a long time ago | 19:23 |
| morphis | jdstrand: :-) | 19:23 |
| zyga | aha | 19:23 |
| zyga | jdstrand: is binder now in the kernel? I didn't know this | 19:23 |
| zyga | and ashmem | 19:23 |
| zyga | wow | 19:23 |
| morphis | jdstrand: guess what, we need a binder interface :-) | 19:23 |
| morphis | zyga: its in staging but disable by default in the std. Ubuntu kernel | 19:23 |
| zyga | morphis: aha | 19:24 |
| morphis | I have dkms packages for both | 19:24 |
| zyga | well, I'd say, letem have it for android-support interface | 19:24 |
| zyga | and just grant it to this snap | 19:24 |
| zyga | it's all software | 19:24 |
| zyga | and you know | 19:24 |
| morphis | or something like this | 19:24 |
| zyga | windows xp wasn't exactly safe | 19:24 |
| zyga | ;-) | 19:24 |
| morphis | far from :-) | 19:27 |
| jdstrand | zyga: no, this would have to be on an android kernel | 19:28 |
| jdstrand | morphis: I know you said that, but that is a *lot* more complicated than just saying 'yes, you can use /dev/binder' | 19:29 |
| morphis | jdstrand: yeah :-) | 19:30 |
| morphis | jdstrand: that is one of the cases why anbox will be devmode-only for quite some time | 19:30 |
| jdstrand | zyga: I'm going to pretend your argument was a joke :) | 19:30 |
| zyga | jdstrand: well, it was a joke but I was actually serious about it as well, if we don't provide it as an interface everyone will just use devmode; is that better? | 19:32 |
| jdstrand | I don't want to have this conversation :) | 19:33 |
| jdstrand | really, it depends on what is running on the other side | 19:34 |
| jdstrand | if it is like on Touch, then the services are pruned and hardened | 19:34 |
| jdstrand | it we are exposing the whole android service set, then, no, it probably isn't terribly better than devmode | 19:35 |
| morphis | jdstrand: in this case it would be more granting a single which isn't used outside of the snap | 19:35 |
| morphis | jdstrand: actually I have patches to make binder namespace aware | 19:36 |
| jdstrand | well, let's not distract ourselves atm :) | 19:36 |
| morphis | absolutely not :-) | 19:36 |
| morphis | just thinking out loud | 19:37 |
| jdstrand | I just wanted to put forth that devmode may work better with a newer snapd/snap-confine | 19:37 |
| * jdstrand nods | 19:37 | |
| jdstrand | zyga: "Once Linux 4.13 is released any distribution can choose to enable apparmor and get complete confinement without rebuilding most of snapd" - where did you get 4.13? | 19:40 |
| Erix | hi | 19:45 |
| Erix | i installed nextcloud snap on ubuntu server 16.10 | 19:46 |
| Erix | cannot find a2ensite for apache2 | 19:46 |
| nacc | kyrofa: --^ redirected them from #ubuntu-server | 19:46 |
| kyrofa | nacc, ah, thank you | 19:46 |
| Erix | thanks nacc | 19:46 |
| kyrofa | Erix, nextcloud embeds upstream apache within it. There is no a2ensite | 19:46 |
| nacc | np, figured you'd be able to answer quicker than I :) | 19:46 |
| kyrofa | Erix, it ships pre-configured and ready to go, but it's not a general purpose apache | 19:47 |
| kyrofa | Its sole purpose is to serve Nextcloud | 19:47 |
| Erix | kyrofa, I'm kind of newbie about this | 19:47 |
| redpill | are snaps supposed to mount on /snap/bin ? | 19:47 |
| kyrofa | Erix, oh that's okay, let's back up a little :) | 19:47 |
| kyrofa | Erix, is this the first time you've setup Nextcloud? | 19:48 |
| Erix | I'm trying to edit a virtualhost config file | 19:48 |
| kyrofa | Erix, what is your end goal? | 19:48 |
| Erix | Actually I edited but guides tell me to run a2ensite | 19:48 |
| Erix | direct http to https | 19:48 |
| Erix | I'm following nextcloud guide about https | 19:49 |
| nacc | redpill: i think they are mounted on /snap/<snapname>/<rev> | 19:49 |
| nacc | redpill: based upon what i see in my test VM :) | 19:49 |
| kyrofa | Erix, there's a huge difference between setting Nextcloud up by installing apache, choosing a database, etc. and just installing the snap | 19:49 |
| kyrofa | Erix, the snap takes care of all that stuff for you (but limits your power a bit as a result), whereas if you want to setup it all up yourself you can't use the snap | 19:50 |
| redpill | odd my are not | 19:50 |
| Erix | kyrofa, I get that | 19:50 |
| kyrofa | Erix, if you want to set it up yourself you need to use the Nextcloud release tarball | 19:50 |
| Erix | it was just too easy | 19:50 |
| Erix | :) | 19:50 |
| Erix | I'm running nextcloud with my little linux knowledge | 19:50 |
| kyrofa | Erix, enabling HTTPS using the snap is easy, and you don't need to play with Apache configs to get there | 19:50 |
| nacc | redpill: iiuc, /snap/bin is now just a place for symlinks to /usr/bin/snap to live (for each snapped application) -- based upon the one snap i have installed :) | 19:51 |
| kyrofa | Erix, assuming you still want to use the snap, what documentation are you following so I can know what you've done? | 19:51 |
| nacc | redpill: since /snap/bin is on PATH | 19:51 |
| Erix | kyrofa, https://docs.nextcloud.com/server/11/admin_manual/configuration_server/harden_server.html#use-https-label | 19:51 |
| redpill | ty that helps | 19:52 |
| redpill | nacc: ^ | 19:52 |
| nacc | redpill: i'm not an expert, but that's what i see in my 16.04 vm | 19:52 |
| kyrofa | Erix, and what vhost are you editing? | 19:52 |
| Erix | kyrofa, nextcloud.enable-https: section on your snap site is about this also? | 19:52 |
| nacc | redpill: you should be able to see what's mounted where with `mount | grep squashfs` | 19:52 |
| kyrofa | Erix, indeed | 19:53 |
| nacc | kyrofa: is there a general "I installed this snap, how do I use it" functionality? (or even just for nextcloud)? | 19:53 |
| Erix | kyrofa, BTW thanks for the great work | 19:53 |
| nacc | kyrofa: i'm thinking similar to regular manpages, but specific to the snap's quirks | 19:53 |
| Erix | it was not poosible for me to install nextcloud without your snap | 19:53 |
| kyrofa | nacc, this pretty much: https://github.com/nextcloud/nextcloud-snap#how-to-use | 19:54 |
| nacc | kyrofa: ack, just wondering how a user should go from `snap install nextcloud` to that URL without coming here :) | 19:54 |
| nacc | kyrofa: i guess `snap info nextcloud` has the url | 19:54 |
| kyrofa | nacc, yeah, that's the idea | 19:54 |
| kyrofa | nacc, still not super friendly, but I'm not sure how to make it better | 19:54 |
| nacc | kyrofa: duly noted for when i see that kind of question in the future, thanks | 19:55 |
| nacc | kyrofa: yeah, i was just thinking -- given that you know which commands you are exposing in the yaml, it'd be nice for there to be blurb for each | 19:55 |
| kyrofa | Erix, so: is the snap actually working for you, then? You just want to enable HTTPS? | 19:55 |
| nacc | kyrofa: in they yaml, then you could in theory do `snap man nextcloud` and it'd just spit out those fields, if there | 19:55 |
| kyrofa | nacc, in the `snap info` output? | 19:56 |
| nacc | kyrofa: not "great", but it'd be a bit more user-friendly then "go to this URL" | 19:56 |
| nacc | kyrofa: i think it'd be a separate command, or maybe a flag? | 19:56 |
| kyrofa | nacc, yeah, best I can do as a snap author is add `-h` options to my commands :P | 19:56 |
| nacc | kyrofa: yeah -- i guess we also have to get used to doing <snap_name>[tab] to see the commands | 19:56 |
| kyrofa | nacc, indeed. At least for now, yeah | 19:56 |
| Erix | kyrofa, yes | 19:57 |
| Erix | kyrofa, everything works as I like | 19:57 |
| kyrofa | Erix, oh, did you figure out how to use `enable-https`? | 19:58 |
| Erix | I just want to force every connection to https | 19:58 |
| kyrofa | Ah, okay, sorry. Happy to walk you through if you like | 19:58 |
| kyrofa | Erix, `nextcloud.enable-https -h` might be helpful | 20:00 |
| Erix | kyrofa, just reading the -h output | 20:00 |
| kyrofa | Great minds | 20:00 |
| mcphail | A solution for man pages and bash compketion is needed | 20:00 |
| kyrofa | Erix, it really comes down to "how do you want to get your cert/do you already have a cert" | 20:00 |
| kyrofa | mcphail, yeah I think both are in the works | 20:01 |
| mcphail | great | 20:01 |
| Erix | kyrofa, self-signed seems easier option for me | 20:02 |
| Erix | going with that | 20:02 |
| kyrofa | Erix, yeah that's pretty easy. Easy to change to something like let's encrypt later if you want | 20:03 |
| Erix | kyrofa, restarted apache | 20:04 |
| Erix | is it done? | 20:04 |
| kyrofa | Erix, yep | 20:04 |
| kyrofa | Erix, just visit it again and you'll see http redirect to https | 20:05 |
| Erix | kyrofa, I see https but its red and labeled not secure by chrome | 20:05 |
| kyrofa | Erix, yeah, because it's self-signed | 20:05 |
| Erix | ok. I guessthat | 20:05 |
| Erix | but it is secure connection | 20:06 |
| kyrofa | Erix, you'll need to use Let's Encrypt (or another CA) if you want web browsers to be happy | 20:06 |
| kyrofa | Indeed, it's encrypted | 20:06 |
| zyga | re | 20:06 |
| zyga | jdstrand: from jjohansen | 20:06 |
| Erix | kyrofa, it was so easy also | 20:06 |
| Erix | thanks again | 20:06 |
| Erix | very much | 20:06 |
| kyrofa | Erix, my pleasure, any time | 20:07 |
| kyrofa | Erix, FYI, I also idle in #nextcloud if you ever run into issues | 20:07 |
| Erix | ok. I'm there also | 20:08 |
| Erix | Although I read as much as needed but | 20:08 |
| Erix | is this right; | 20:08 |
| Erix | snaps are combinations of pre configured software for a specific target in mind | 20:09 |
| Erix | thats is what I understood | 20:09 |
| jjohansen | zyga: that is the goal, it is possible I want get everything landed by then, especially if some of it gets stuck for testing in the -next tree | 20:09 |
| jdstrand | zyga: hmm, I thought that was an estimation, not a hard date, but I don't know | 20:10 |
| jdstrand | it's super important to be sure | 20:10 |
| jjohansen | jdstrand: yeah, that is the goal | 20:10 |
| jjohansen | I do have some concerns around the extended network mediation, which unix sockets are the first of | 20:11 |
| zyga_ | re | 20:17 |
| zyga_ | sorry, network | 20:18 |
| tvoss | niemeyer: thanks for the review :) let me get to your final remarks | 20:18 |
| jdstrand | zyga_: in case you missed it: | 20:21 |
| jdstrand | 15:09 < jjohansen> zyga: that is the goal, it is possible I want get everything | 20:21 |
| jdstrand | landed by then, especially if some of it gets stuck for testing | 20:21 |
| jdstrand | in the -next tree | 20:21 |
| zyga_ | aha | 20:21 |
| jdstrand | 15:10 < jdstrand> zyga: hmm, I thought that was an estimation, not a hard date, but | 20:21 |
| jdstrand | I don't know | 20:21 |
| zyga_ | thank you jdstrand | 20:21 |
| jdstrand | 15:10 < jdstrand> it's super important to be sure | 20:21 |
| jdstrand | 15:10 < jjohansen> jdstrand: yeah, that is the goal | 20:21 |
| jdstrand | 15:11 < jjohansen> I do have some concerns around the extended network mediation, | 20:21 |
| jdstrand | which unix sockets are the first of | 20:21 |
| jdstrand | np | 20:21 |
| zyga_ | jjohansen: do you think there will be any pushback? | 20:21 |
| jjohansen | ugh, now you have sent /me into panic mode, my deadline is only 7-8 weeks out | 20:22 |
| * jjohansen so prefers to ignore reality | 20:23 | |
| zyga_ | hard time to | 20:23 |
| jjohansen | yeah | 20:23 |
| zyga_ | in case we get hit, I really enjoy working with you | 20:24 |
| kyrofa | Erix, sorry I missed your question. Yeah, that seems like a reasonable way to think of them | 20:26 |
| Croepha | does there exist a snap for the 4.11 kernel? | 20:27 |
| tvoss | niemeyer: done and pushed | 20:27 |
| stokachu | facubatista: around? | 20:29 |
| stokachu | getting a proxy error trying to upload to the store | 20:29 |
| facubatista | stokachu, here | 20:30 |
| facubatista | stokachu, "proxy error"? | 20:30 |
| stokachu | yea | 20:30 |
| facubatista | stokachu, using snapcraft? | 20:30 |
| stokachu | yep | 20:30 |
| Erix | kyrofa, thanks | 20:30 |
| stokachu | facubatista: http://paste.ubuntu.com/24369710/ | 20:30 |
| stokachu | facubatista: http://paste.ubuntu.com/24369715/ in its entirety | 20:31 |
| facubatista | stokachu, looks like a generic server error, will take a look | 20:31 |
| stokachu | thanks, a kubernetes release for juju is blocked on us | 20:31 |
| facubatista | stokachu, did you retry? | 20:33 |
| stokachu | just twice | 20:33 |
| stokachu | you want me to try again? | 20:33 |
| stokachu | facubatista: ^ | 20:35 |
| facubatista | stokachu, 1' | 20:35 |
| facubatista | stokachu, mind to try once again? thanks | 20:42 |
| stokachu | ok | 20:43 |
| stokachu | facubatista: looks like it went through | 20:45 |
| facubatista | stokachu, oh, ok | 20:45 |
| stokachu | facubatista: what was the issue? | 20:46 |
| * facubatista has mixed feelings in this situations.. glad it worked, but sad the original problem couldn't be debugged further | 20:46 | |
| facubatista | stokachu, we were experiencing some storage issues, I just tried to confirm if it was the case here... but now it worked :/ | 20:46 |
| stokachu | facubatista: ah ok | 20:46 |
| stokachu | facubatista: ill let you know on the next issue :D | 20:47 |
| facubatista | stokachu, thanks :) | 20:47 |
| facubatista | stokachu, how big is your snap file? | 20:49 |
| stokachu | facubatista: 92.5MB | 20:50 |
| facubatista | stokachu, thanks! (collecting info for people that also studied these transient errors) | 20:51 |
| stokachu | anytime | 20:51 |
| mup | PR snapcraft#1245 closed: nodejs plugin: add support for yarn <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1245> | 21:09 |
| === koza is now known as koza|away | ||
| gregl | If I install a snap of a running program (plexmediaserver),will it mess up my running version?? | 21:33 |
| mcphail | Can anyone point me to a Rails application which has been snapped? Wondering if I should try to tackle snappificating Mastodon | 23:16 |
| mwhudson | so something in snapd is filtering out the TMPDIR environment var | 23:41 |
| mwhudson | any ideas where? grepping isn't finding anything | 23:41 |
| oky | mwhudson: do you need to set it? | 23:55 |
| mwhudson | a user of my classic snap wants to set it, yes | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
