| mup | Bug #1677417 opened: /etc/ld.so.conf.d/conjure-up.conf breaks apt on host system <Snappy:New> <conjure-up (Ubuntu):New for adam-stokes> <https://launchpad.net/bugs/1677417> | 00:35 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| === hikiko_ is now known as hikiko | ||
| mwhudson | who can help me with tracks in the store? | 07:17 |
| zyga | mwhudson: maybe open a store side question on the forum? | 07:22 |
| mwhudson | zyga: did the forum get mentioned on the mailing list yet? | 07:23 |
| zyga | mwhudson: it's metioned in the topic here :) | 07:23 |
| mwhudson | yes, that's the only place i've seen it mentioned | 07:23 |
| zyga | mwhudson: I think it will replace the mailing list entirely | 07:23 |
| * mwhudson gives an old man sign | 07:23 | |
| mwhudson | *sigh | 07:23 |
| mwhudson | https://forum.snapcraft.io/t/can-someone-set-up-guardrails-for-the-go-snaps-tracks/72 | 07:29 |
| mwhudson | also autopublishing to tracks from launchpad would save me a lot of effort :) | 07:29 |
| morphis | mwhudson: ping | 07:31 |
| mwhudson | morphis: hi | 07:32 |
| morphis | mwhudson: hey! how are things? :-) | 07:32 |
| mwhudson | morphis: not bad! | 07:32 |
| morphis | mwhudson: sounds good, I saw you're one of the maintainers of snapd in debian | 07:33 |
| mwhudson | morphis: yeah | 07:33 |
| morphis | mwhudson: any concrete plans to update the package real soon? | 07:33 |
| mwhudson | morphis: no, debian is in freeze | 07:33 |
| morphis | don't we have a package in unstable too? | 07:33 |
| mwhudson | morphis: i thought re-execing in the core snap mostly meant i didn't have to | 07:33 |
| mwhudson | well yeah but life is easier if stable and unstable don't diverge aiui | 07:34 |
| zyga | mwhudson: I think we could file an RC bug because we need to ship something or the package is totally broken :/ | 07:34 |
| mwhudson | i could upload a newer one to experimental | 07:34 |
| mwhudson | zyga: right, if we need to fix this core snap hanging thing with a new package, we need to do that | 07:34 |
| morphis | mwhudson: we had a few serious issues recently which are now patched in snapd 2.23.6, though I didn't checked yet if debian is affected | 07:34 |
| * zyga reboots to try new pulseaudio | 07:35 | |
| morphis | mwhudson: let me try the current snapd package in testing | 07:36 |
| mwhudson | morphis: i've not dealt with the politics of getting a release exception in debian | 07:37 |
| morphis | mwhudson: ok, so lets see if we an avoid this :-) | 07:37 |
| mwhudson | morphis: but it's at least possible that targeted fixes will be an easier sell than a wholesale upgrade | 07:37 |
| mwhudson | or not, i don't know | 07:37 |
| morphis | mwhudson: I think if there are single fixes needed to get snapd in debian re-exec into the one coming from the core snap we can do that | 07:38 |
| morphis | zyga: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501#c3 | 07:43 |
| zyga | morphis: looking | 07:48 |
| zyga | morphis: so 1) this will only work if home interface is connected (it doesn't even have to be used) | 07:48 |
| zyga | morphis: why does every non-snap app work? | 07:48 |
| zyga | morphis: there must be a different auth mechanism that is being tried | 07:49 |
| zyga | morphis: it fails and xauthority is a workaround | 07:49 |
| morphis | maybe | 07:49 |
| morphis | that is what I am currently looking into | 07:49 |
| morphis | zyga: it wouldn't even work with the home interface connected as it doesn't allow you to use .XAuthority | 07:49 |
| morphis | it only works in this case because we have no confinement at all | 07:50 |
| zyga | morphis: ah, right | 07:56 |
| morphis | zyga: ok, it gets interesting, XAUTHORITY is set to /tmp/xauth-1000-_0 in KDE on suse | 08:07 |
| morphis | zyga: are we doing any processing of the env vars when we spawn up the snap environment? | 08:07 |
| morphis | no, as it seems, it ends up the snap in the snap env | 08:08 |
| zyga | morphis: aha | 08:09 |
| zyga | morphis: see | 08:09 |
| zyga | morphis: it is /tmp related :) | 08:09 |
| morphis | zyga: flatpak is doing some extra stuff here | 08:09 |
| morphis | see https://sources.debian.net/src/flatpak/0.8.4-3/common/flatpak-run.c/?hl=1944#L1924 | 08:09 |
| zyga | morphis: yes, I think we need to extra stuff for x11 and pulseaudio | 08:09 |
| zyga | morphis: that feels like snap-confine's work | 08:10 |
| zyga | morphis: you could read the xauth config on startup | 08:10 |
| zyga | morphis: and after dropping privs write the file into the fresh /tmp | 08:10 |
| zyga | morphis: (remember that tmp is empty) | 08:11 |
| morphis | zyga: right | 08:11 |
| morphis | similar to what flatpak does | 08:11 |
| zyga | morphis: yeah | 08:14 |
| zyga | morphis: right now I'd code it in C directly | 08:14 |
| zyga | morphis: but I sooomewhat worry about how many hacks like this we'll need | 08:14 |
| zyga | morphis: I suspect that a bound set so this is oK | 08:14 |
| zyga | morphis: if it starts to look like each new interface needs this we may have to think about snapd assisting via a backend | 08:14 |
| morphis | zyga: right | 08:14 |
| morphis | zyga: lets start with a hack into snap-confine | 08:15 |
| morphis | actually this is kind of a problem and wondering if the KDE guys didn't experienced this problem with their snaps | 08:15 |
| morphis | zyga: let me take this problem as part of my cross-distro work | 08:16 |
| morphis | Son_Goku: ping | 08:26 |
| Son_Goku | pong | 08:26 |
| Son_Goku | :/ | 08:26 |
| morphis | Son_Goku: you saw the PR for the missing not upstream patch? | 08:30 |
| Son_Goku | yes | 08:30 |
| Son_Goku | I already added the comment to my spec | 08:30 |
| morphis | good | 08:30 |
| Son_Goku | I'm rebasing to 2.23.6, since you guys released that yesterday :/ | 08:30 |
| morphis | Son_Goku: :-) | 08:30 |
| Son_Goku | and I've already been bitten patchwise | 08:31 |
| morphis | in which way? | 08:31 |
| Son_Goku | the systemd unit template PR doesn't apply cleanly onto 2.23.6 | 08:31 |
| Son_Goku | the rules file hunks all fail | 08:31 |
| Son_Goku | so I've been purging those manually from the patch | 08:31 |
| morphis | yeah those things are nasty | 08:32 |
| morphis | Son_Goku: so really time to get them all dropped :-) | 08:32 |
| morphis | Son_Goku: I am trying to get that solved with 2.24 | 08:32 |
| Son_Goku | is seccomp still broken for 2.23.6? | 08:35 |
| Son_Goku | morphis ^ | 08:36 |
| morphis | Son_Goku: we have fixed one bug but I fear there might be more | 08:38 |
| Son_Goku | so still broken, yay :( | 08:38 |
| morphis | not directly broken | 08:38 |
| morphis | but as AppARmor is disabled we may run into situatuions where things would have been blocked already by AppArmor and not run into seccomp denials which lead to hanging processes like we had for snapctl | 08:39 |
| morphis | Son_Goku: once we're done with the basic packaging bits I will start working on getting proper CI up for fedora/debian/suse/.. | 08:39 |
| morphis | then we have a much safer way of handling and testing those things and can ensure they keep working | 08:40 |
| Son_Goku | I feel like banging my head into the ground with all this shit... :/ | 08:40 |
| Son_Goku | alright, I'm turning back on seccomp and damn the consequences | 08:40 |
| morphis | Son_Goku: things will be much easier once we have all patches upstream | 08:41 |
| morphis | and confinement is on my list too | 08:42 |
| Son_Goku | I hate golang so much | 08:42 |
| Son_Goku | it just adds so much complication to things | 08:42 |
| morphis | :-) | 08:42 |
| Son_Goku | I used to merely dislike golang, now I hate it | 08:43 |
| seb128 | hey morphis, sorry I was not around when you pinged yesterday and it was a contentless ping so couldn't reply when I came back ... I guess it was about that KDE/opensuse issue you are discussing on the list and now here? | 08:45 |
| morphis | seb128: right, I thought you might be one who knows what is going on but I've figured the real problem already: https://bugs.launchpad.net/snapd/+bug/1677513 | 08:46 |
| mup | Bug #1677513: snap-confine does not pass file referenced by XAUTHORITY env variable into the snap environment <snapd:Confirmed for morphis> <https://launchpad.net/bugs/1677513> | 08:46 |
| morphis | seb128: didn't checked KDE on Ubuntu yet but they might set XAUTHORITY to something in /run or /home too | 08:47 |
| morphis | seb128: but thanks for the late pong :-) | 08:47 |
| seb128 | np, glad that you figured it out :-) | 08:47 |
| Son_Goku | well, here we go... | 08:52 |
| Son_Goku | morphis: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678557 | 08:53 |
| morphis | Son_Goku: awesome! | 08:53 |
| pedronis | mvo: #3109 is mergeable, no? | 08:54 |
| morphis | Son_Goku: will give this some testing once ready | 08:54 |
| Son_Goku | oh crap | 08:55 |
| Son_Goku | I just realized something | 08:55 |
| morphis | ? | 08:55 |
| Son_Goku | I need to pull in my snapctl patch | 08:57 |
| Son_Goku | for selinux | 08:57 |
| Son_Goku | that was almost certainly not merged back in to 2.23.6 | 08:57 |
| Son_Goku | not knocking on mvo, but this was not exactly something he cared about for merging back into releases before | 08:58 |
| morphis | Son_Goku: ah, is that one already in master? | 08:58 |
| Son_Goku | yes | 08:58 |
| morphis | ok, another one we can drop with 2.24 then.. | 08:58 |
| Son_Goku | since the debubuntu packages don't ship the selinux module as a subpackage yet, he has no way of knowing or caring about changes to it | 08:58 |
| morphis | right | 08:59 |
| morphis | Son_Goku: this will get better once we have CI also caring about fedora | 08:59 |
| Son_Goku | I doubt it | 08:59 |
| Son_Goku | it'll be hard to spot selinux backport things because the domain is in permissive mode | 09:00 |
| morphis | I see | 09:01 |
| morphis | something I need to dive into at a later point | 09:01 |
| Son_Goku | generally, selinux policy module changes should be assumed to be backported, I think | 09:02 |
| Son_Goku | as they are generally reactive from when you guys change something, rather than proactive | 09:03 |
| mvo | Son_Goku: hey, sorry that some bits did not get backported, we want to do a 2.24 soon though. we did the 2.23.6 mostly to ensure we have some important bugfixes out before moving on. once 2.24 lands things should move more normal again, i.e. things in master also go into the release etc | 09:07 |
| Son_Goku | mvo: no worries | 09:08 |
| Son_Goku | I blame morphis anyway :P | 09:08 |
| Son_Goku | (not really!) | 09:08 |
| morphis | Son_Goku: :-D | 09:08 |
| Son_Goku | anyway, I expect that this will get better, vis-a-vis the selinux module, once someone adds the packaging for it to debubu packaging | 09:09 |
| Son_Goku | what I'm going to hate doing is packaging DNF debian-style for snapcraft | 09:10 |
| Son_Goku | I despise Debian-style packaging (I consider it way more complicated than it should be) | 09:10 |
| Son_Goku | it's not that I don't know how to do it... I certainly do | 09:10 |
| Son_Goku | after all, I used to use Ubuntu for years and almost became a Debian/Ubuntu contributor many years ago | 09:11 |
| Son_Goku | fuck | 09:13 |
| Son_Goku | snapd FTBFS on i686 | 09:14 |
| Son_Goku | and ppc64 | 09:14 |
| Son_Goku | well, at least it built on ppc64le | 09:15 |
| Son_Goku | https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723 | 09:15 |
| morphis | Son_Goku: ah, I have a fix for that one | 09:17 |
| * Son_Goku groans | 09:18 | |
| morphis | Son_Goku: https://github.com/snapcore/snapd/pull/3094 | 09:18 |
| mup | PR snapd#3094: cmd: rework header check for xfs/xqm.h <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3094> | 09:18 |
| Son_Goku | yay | 09:18 |
| Son_Goku | more patches | 09:18 |
| morphis | Son_Goku: with that everything should build fine, verified with https://copr.fedorainfracloud.org/coprs/mrmorph/snapcore/ | 09:18 |
| Son_Goku | you don't have a fix for ppc64, though | 09:18 |
| morphis | which doesn't build for ppc but for i386 | 09:19 |
| morphis | yeah looking into that one .. | 09:19 |
| morphis | Son_Goku: can I easily cross build with mock? | 09:20 |
| Son_Goku | no | 09:20 |
| Son_Goku | mock does not support foreign arches like that yet | 09:20 |
| Son_Goku | BUT | 09:20 |
| Son_Goku | Fedora offers contributors access to ppc64 VMs | 09:20 |
| morphis | ah | 09:20 |
| Son_Goku | morphis: I suggest hopping into #fedora-ppc and asking about it | 09:21 |
| morphis | Son_Goku: will do, need to care about a few other things first | 09:23 |
| morphis | pedronis: what retry interval do we have in snapd currently to reach the serial-vault as configured from the prepare-device hook? | 09:27 |
| pedronis | morphis: 1 minutes for dynamic errors, for things that look like the vault is not understanding a back off starting from 5 minutes and then doubling up to a max | 09:30 |
| Son_Goku | morphis: and joy of joys | 09:31 |
| Son_Goku | armv7hl failed too | 09:31 |
| morphis | pedronis: ok, but we don't block the further first-boot process when we can't the server, right? | 09:31 |
| morphis | Son_Goku: wonderful .. | 09:31 |
| Son_Goku | full list of failures: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723 | 09:31 |
| pedronis | morphis: first boot is completely independent, they are even two different changes | 09:31 |
| pedronis | morphis: what we block is the fist refresh for a bit | 09:31 |
| pedronis | we try to refresh witha serial if possible | 09:32 |
| pedronis | but after a while try anyway | 09:32 |
| Son_Goku | morphis: it looks like arm failed because of same issue with i686 | 09:32 |
| morphis | pedronis: ok, just wanted a confirmation on this | 09:32 |
| morphis | Son_Goku: yeah, which is a "good" thing :-) | 09:32 |
| Son_Goku | morphis: added patch, and trying again: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977 | 09:38 |
| morphis | Son_Goku: great | 09:38 |
| zyga | mvo: can you please have a 2nd look at https://github.com/snapcore/snapd/pull/3102 | 09:46 |
| mup | PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102> | 09:46 |
| Son_Goku | morphis: now i686 just fails to compile :( | 09:46 |
| Son_Goku | /usr/include/xfs/xfs.h:51:12: error: size of array 'xfs_assert_largefile' is too large | 09:47 |
| Son_Goku | extern int xfs_assert_largefile[sizeof(off_t)-8]; | 09:47 |
| Son_Goku | morphis: you need to go back to the drawing board on this | 09:47 |
| zyga | I see you two are having fun :) | 09:48 |
| * Son_Goku groans | 09:48 | |
| Son_Goku | I wanted this to be released already | 09:48 |
| Son_Goku | I want the buildsys to stop telling me that snapd-glib is broken | 09:48 |
| zyga | I start to see light at the end of my tunnel | 09:48 |
| zyga | with the move to go the coding moves faster than before | 09:49 |
| morphis | Son_Goku: hm, this worked for me well in Yocto .. | 09:49 |
| Son_Goku | I see crushing sadness and dispair | 09:49 |
| Son_Goku | morphis: Yocto is bullshit | 09:49 |
| morphis | Son_Goku: lets not get into this discussion, please :-) | 09:49 |
| Son_Goku | Yocto can be whatever you want, so it doesn't really serve as a great means of comparison | 09:49 |
| morphis | Son_Goku: you have a link to the last build? | 09:50 |
| zyga | Son_Goku: I think the more interesting fact is that it built on 32bit debian | 09:50 |
| Son_Goku | zyga: Debian has older compiler | 09:50 |
| zyga | Son_Goku: sid? | 09:50 |
| zyga | Son_Goku: very doubtful | 09:51 |
| Son_Goku | has debian moved onto GCC 7 yet? | 09:51 |
| Son_Goku | as far as I knew, they were still on 6.3.x | 09:51 |
| zyga | Son_Goku: yes | 09:51 |
| Son_Goku | are you using hardened build flags there? | 09:52 |
| zyga | https://packages.debian.org/experimental/gcc-7 | 09:52 |
| Son_Goku | because Fedora does by default | 09:52 |
| zyga | Son_Goku: I don't know | 09:52 |
| Son_Goku | I know Debian does not | 09:52 |
| zyga | but dones't look like related to what the error above says | 09:52 |
| zyga | it does look like the size of off_t is the relevant factor here | 09:52 |
| zyga | but TBH | 09:52 |
| zyga | this is all load of BS | 09:52 |
| Son_Goku | zyga: anyway, gcc-defaults in sid is gcc6 | 09:52 |
| zyga | because we should just check if that header file exists | 09:52 |
| Son_Goku | https://packages.debian.org/sid/gcc | 09:52 |
| zyga | all we need are _constants_ | 09:53 |
| zyga | morphis: feel free to hardcode those as those are kernel constants and kernel is not insane to change | 09:53 |
| zyga | morphis: and drop libxfsprogs-devel from dependencies | 09:53 |
| Son_Goku | morphis, zyga: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678977 | 09:53 |
| Son_Goku | the green, orange, and red links are clickable :) | 09:53 |
| zyga | the ppc one is interesting, checking | 09:54 |
| morphis | zyga: you propose that as an upstream change? :-) | 09:54 |
| Son_Goku | here's a previous failed build, too, prior to adding snap-confine patch: https://koji.fedoraproject.org/koji/taskinfo?taskID=18678723 | 09:54 |
| zyga | morphis: as a distro change and upstream change later | 09:54 |
| zyga | morphis: I see no reason to check linkability or work around this issue | 09:54 |
| zyga | morphis: if we care about a hanful of constants | 09:54 |
| morphis | Son_Goku: ok, this looks different now | 09:55 |
| Son_Goku | the failures are possibly caused by newer libxfs | 09:55 |
| morphis | maybe | 09:55 |
| Son_Goku | Fedora has xfsprogs 4.10.0 | 09:56 |
| Son_Goku | Debian has xfsprogs 4.9.0 | 09:56 |
| Son_Goku | since we update the kernel, we also update the tools too | 09:56 |
| morphis | Son_Goku: my guess is that we should get this building with add -D_FILE_OFFSET_BITS=64 to CFLAGS | 10:01 |
| Son_Goku | patch? | 10:01 |
| morphis | Son_Goku: something like https://paste.ubuntu.com/24280132/ but didn't tested it yet | 10:03 |
| Son_Goku | easy to test, I can just fire off a scratch build for it | 10:04 |
| Son_Goku | okay, I'm getting super sick of this | 10:04 |
| Son_Goku | someone needs to turn off OpenID auth on raw pastes | 10:04 |
| Son_Goku | morphis: if no one fixes that, please stop using paste.ubuntu.com | 10:04 |
| morphis | :-) | 10:05 |
| zyga | Son_Goku: I bet there's a reason for that | 10:06 |
| Son_Goku | zyga: I don't care | 10:06 |
| Son_Goku | it's stupid and aggravating and I can't curl anything | 10:06 |
| Son_Goku | morphis: please use paste.fedoraproject.org, if you need an alternative | 10:06 |
| Son_Goku | there's also a handy fpaste utility for pasting from the CLI :) | 10:07 |
| Son_Goku | https://pagure.io/fpaste | 10:07 |
| * zyga wonders why not pastebinit + config | 10:07 | |
| Son_Goku | well, I didn't know about pastebinit :) | 10:08 |
| zyga | it supports many paste services | 10:08 |
| zyga | simple python script AFAIR | 10:09 |
| Son_Goku | it has a fpaste config | 10:09 |
| Son_Goku | though I don't know if it works with the new pastebin software fedora deployed recently: https://fedoramagazine.org/hello-modern-paste/ | 10:10 |
| morphis | Son_Goku: looks nice | 10:11 |
| zyga | Son_Goku: I honestly don't like the new paste, there was a looot of negative feedback after it was rolled out | 10:12 |
| zyga | Son_Goku: I need to try it again though, I think/hope some of that feedback was addressed | 10:12 |
| Son_Goku | I don't care for it's look and the superlong URLs | 10:12 |
| zyga | Son_Goku: the URLs were totally broken wrt basic usaility | 10:13 |
| zyga | *usability | 10:13 |
| === carlolo_ is now known as carlolo | ||
| Son_Goku | morphis: trying a scratch build with your diff: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679354 | 10:16 |
| morphis | ok | 10:16 |
| morphis | ah | 10:17 |
| morphis | it wont work | 10:17 |
| morphis | needs to be = instead of += | 10:17 |
| morphis | Son_Goku: sorry for that | 10:17 |
| morphis | Son_Goku: https://paste.fedoraproject.org/paste/-NaL-TKvNct9~lx1tvVDdl5M1UNdIGYhyRLivL9gydE= | 10:18 |
| Son_Goku | does that mean all the hardening flags are clobbered? | 10:18 |
| morphis | no | 10:20 |
| morphis | if we add AM_CFLAGS then they are there | 10:20 |
| morphis | Son_Goku: so something like https://paste.fedoraproject.org/paste/k6OU-DUhS5tSIQ5cglQP7F5M1UNdIGYhyRLivL9gydE= is more correct | 10:21 |
| morphis | Son_Goku: this fork functionality is quite nice | 10:21 |
| Son_Goku | yes, it is | 10:21 |
| zyga | ogra: how do you reply with a quote on discourse? | 10:22 |
| ogra | zyga, just mark something in the text then a "quote" thing pops up | 10:22 |
| ogra | you also earn a new badge with it ;) | 10:22 |
| zyga | aah, nice! | 10:22 |
| zyga | thanks! | 10:22 |
| Son_Goku | morphis: take 2: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679427 | 10:25 |
| morphis | Son_Goku: lets hope this now works .. | 10:25 |
| Son_Goku | since arm takes too long, I'm going to assume it works if i686 does | 10:25 |
| Son_Goku | then you can prepare a formal PR and I can have a formal patch and we can try again for all arches | 10:26 |
| zyga | ogra: heh, my quote didn't really work :) | 10:26 |
| Son_Goku | I wish our discourse supported social sign on | 10:27 |
| zyga | fixed now | 10:27 |
| zyga | ogra: have a look at https://github.com/snapcore/core-build | 10:27 |
| Son_Goku | (not Ubuntu SSO, but normal SSO, like Google, Twitter, GitLab, GitHub, etc.) | 10:27 |
| zyga | ogra: what else do we need there? | 10:27 |
| zyga | Son_Goku: I think it doesn't upstream and that's why we don't have it here | 10:28 |
| Son_Goku | weird | 10:28 |
| zyga | Son_Goku: and as a plugin it is not supported from what I heard | 10:28 |
| zyga | Son_Goku: I think there's a thread about that actually | 10:28 |
| Son_Goku | hm | 10:28 |
| zyga | Son_Goku: no, let's start one | 10:28 |
| Son_Goku | the Rust forum uses social sign-on, I think | 10:28 |
| Son_Goku | yeah, Rust uses GitHub | 10:29 |
| zyga | https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75 | 10:29 |
| Son_Goku | one of the other ones I know of uses Google | 10:29 |
| morphis | Son_Goku: looks like the patch apply failed this time | 10:29 |
| Son_Goku | :/ | 10:30 |
| zyga | ogra: https://forum.snapcraft.io/t/gardening-in-github-com-snapcore-core-build/76 | 10:34 |
| Son_Goku | morphis: fixed the patch, but it didn't work | 10:36 |
| morphis | Son_Goku: you have the full patchset somewhere? | 10:36 |
| morphis | let me create the patch on top of that | 10:36 |
| Son_Goku | morphis: the patch set is http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/ + https://da.gd/qUH4P | 10:38 |
| morphis | Son_Goku: https://paste.fedoraproject.org/paste/AFR94F40CNQwmk3eFcy4Rl5M1UNdIGYhyRLivL9gydE= should cleanly apply on top of the patchset | 10:43 |
| Son_Goku | yes, but it still doesn't fix the problem | 10:44 |
| Son_Goku | oh wait | 10:44 |
| Son_Goku | la | 10:44 |
| ogra | zyga, if you mention me in the post you dont need to ping on IRC ;) | 10:44 |
| ogra | (was already writing an answer when you pinged) | 10:45 |
| zyga | ogra: aha, you get destkop notifications on @-mentions? | 10:46 |
| Son_Goku | morphis: take 4: https://koji.fedoraproject.org/koji/taskinfo?taskID=18679552 | 10:47 |
| ogra | zyga, yeah | 10:47 |
| morphis | Son_Goku: we're coming closer :-) | 10:49 |
| morphis | Son_Goku: ok, this didn't help | 10:50 |
| morphis | Son_Goku: need to scratch my head around this when I am done with my meetings | 10:51 |
| mup | PR snapd#3113 opened: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113> | 11:17 |
| pedronis | Chipaca: you might want to look at snapd#3113 when one have a moment, it's not big, it's the changes about locking discussed yesterday | 11:30 |
| mup | PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113> | 11:30 |
| Chipaca | pedronis— looking | 11:30 |
| mvo | pedronis: yes, 3109 is mergable | 11:32 |
| mvo | zyga: sure, I have a look at the fstab thing | 11:32 |
| mup | PR snapd#3109 closed: Merge 2.23.6 release back into master <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3109> | 11:34 |
| pedronis | mvo: done | 11:35 |
| ogra | zyga, https://github.com/snapcore/core-build/pull/1 | 11:35 |
| mup | PR core-build#1: adjust README file to proper reflect repo content <Created by ogra1> <https://github.com/snapcore/core-build/pull/1> | 11:35 |
| mvo | pedronis: ta | 11:37 |
| zyga | ogra: +1 | 11:38 |
| Chipaca | pedronis— +1; lgtm and good start | 11:57 |
| zyga | Chipaca: care to do a 2nd review of https://github.com/snapcore/snapd/pull/3102 | 11:58 |
| mup | PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102> | 11:58 |
| Chipaca | zyga— nah | 11:58 |
| * Chipaca grins | 11:58 | |
| zyga | Chipaca: et tu Brutus? | 11:58 |
| zyga | ;-) | 11:58 |
| Chipaca | zyga— et ideam habent quam multa. | 11:59 |
| jdstrand | morphis, Son_Goku: things will also get much better when we don't kill the process for a seccomp denial and instead return something like EPERM. this is in progress | 11:59 |
| morphis | jdstrand: yeah, that would help | 12:00 |
| morphis | jdstrand: however I still fear we will run into multiple bugs with just seccomp and no AppArmor | 12:00 |
| morphis | so having some extensive testing before we enable this would be good | 12:00 |
| jdstrand | morphis: the sandbox is definitely designed for both to be enabled. enabling seccomp without apparmor isn't really gaining you much | 12:01 |
| morphis | jdstrand: right | 12:01 |
| jdstrand | morphis: I mean, sure, you can't load a kernel module, but you can write a file to /etc/modules.d | 12:01 |
| morphis | jdstrand: so for other systems we need SELinux + Seccomp or nothing | 12:01 |
| jdstrand | /etc/modules-load.d | 12:02 |
| Chipaca | zyga— +1 (with a comment) | 12:03 |
| jdstrand | morphis: re selinux> yes, though selinux only has rudimentary dbus mediation compared to apparmor | 12:03 |
| morphis | jdstrand: yeah sadly, but this is something we need to talk in the near future | 12:03 |
| morphis | jdstrand: having this on my road map for cross-distro after I am through all the others things :-) | 12:03 |
| jdstrand | morphis: this was actually discussed a good bit in the Hague | 12:04 |
| zyga | jdstrand: FYI, overlayfs got good selinux support lately, is that because LSMs got improved or and so apparmor "groks" overlayfs automatically or is that selinux specific, do you know? | 12:04 |
| morphis | jdstrand: oh great, seems like I missed that session :-) | 12:04 |
| morphis | jdstrand: are there any notes available? | 12:04 |
| jdstrand | morphis: I suspect that the list of interfaces available will need to be different for an apparmor enabled system vs an selinux system | 12:04 |
| morphis | jdstrand: yeah, maybe | 12:05 |
| jdstrand | morphis: it was inconclusive. various problems were identified because of the capabilities of each system and how they both approach MAC differently | 12:05 |
| zyga | Chipaca: thanks for the hint, applied! | 12:06 |
| jdstrand | morphis: when you are starting to write selinux policy, you'll want to do a hangout with at least me, Tyler and jj | 12:06 |
| morphis | jdstrand: absolutely | 12:06 |
| Chipaca | zyga— as i said the compiler is probably good enough nowadays to not make it necessary, but sometimes (like here) it's probably clearer anyways | 12:06 |
| zyga | Chipaca: yeah, I really like it, feels pythonic in good way :) | 12:07 |
| Chipaca | :-) | 12:07 |
| morphis | jdstrand: this is currently somewhere on the horizon but I want to have proper CI for those systems in place first | 12:07 |
| Chipaca | zyga— yeah | 12:07 |
| zyga | morphis: I think you could start by trying to run unit tests on snapd build on fedora | 12:07 |
| zyga | morphis: that will show looooots of red because of /snap shift | 12:07 |
| morphis | zyga: yeah :-) | 12:07 |
| === cachio_afk is now known as cachio | ||
| zyga | morphis: niemeyer suggested that we add a mock call so that those tests assume /snap is still in place | 12:08 |
| zyga | morphis: for spread you will need a different tactics I fear, as those are integration tests | 12:08 |
| jdstrand | morphis: it is possible to do things like: the process with this label can talk to the process with that label over dbus with selinux (eg, I can talk to all of network-manager or I can't talk to network-manager at all), but for carving out parts of the dbus api-- no | 12:08 |
| zyga | morphis: while not perfect, I had an idea with snapd-fhs package that puts a /snap -> /var/lib/snapd/snap symlink in place | 12:08 |
| morphis | zyga: yeah, mock call sounds good, will need to look into that once we're through the current phase of getting distros into shape | 12:08 |
| zyga | morphis: as a $0.01 solution | 12:08 |
| morphis | zyga: depends if we can that approved by the other distros | 12:08 |
| jdstrand | morphis: but there are other issues that aren't at the top of my head | 12:09 |
| jdstrand | (even with dbus) | 12:09 |
| zyga | jdstrand: are you sure? I saw some fine-grained mediation for dbus + selinux lately (but maybe I was confused) | 12:09 |
| zyga | morphis: for spread testing | 12:09 |
| zyga | morphis: not for anything else | 12:09 |
| morphis | jdstrand: I think we should come together at some point and just brainstorm to see what problems we have and to guess possible solutions | 12:09 |
| jdstrand | zyga: patches to dbus deamon? | 12:09 |
| morphis | zyga: flatpak uses a proxy for that, maybe they added selinux to that | 12:10 |
| zyga | jdstrand: I think to selinux, I saw policy language that was referring to specific methods | 12:10 |
| * zyga googles | 12:10 | |
| jdstrand | if you're talking flatpak, they either write services where the whole api is safe or use a proxy | 12:10 |
| morphis | jdstrand: right | 12:11 |
| zyga | jdstrand: no, not flatpak | 12:11 |
| zyga | jdstrand: I know they use a proxy, it's a different approach altogether | 12:11 |
| pedronis | fgimenez: mvo: we are hitting /dev/ram0 issues now in the spread tests | 12:12 |
| zyga | pedronis: https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77 | 12:13 |
| zyga | jdstrand: I cannot find it, all I can find now confirms what you said earlier (no per-method control) | 12:14 |
| zyga | it would be nice if selinux supported that actually | 12:14 |
| jdstrand | zyga: indeed it would :) | 12:15 |
| zyga | jdstrand: the proxy based approach has one advantage, it can be rolled out on any old kernel | 12:15 |
| zyga | jdstrand: (and any old dbus) | 12:15 |
| zyga | jdstrand: do you think we should write such proxy? | 12:15 |
| jdstrand | zyga: but the kdbus discussions showed that people weren't really interested in it | 12:15 |
| zyga | jdstrand: in selinux over dbus? | 12:16 |
| zyga | jdstrand: I saw that kdbus disposed the xml language too | 12:16 |
| zyga | jdstrand: but I wasn't aware of any other details | 12:16 |
| jdstrand | zyga: I can't make that recommendation. putting a proxy in front of dbus-daemon would slow things down. it would have to be measured. it is certainly possible | 12:17 |
| * Chipaca ~> lunch | 12:17 | |
| === hikiko is now known as hikiko-ln | ||
| jdstrand | zyga: the gist of the kdbus conversations was that "selinux doesn't do interface/path/member mediation, why should we allow apparmor to do that? either the service is safe or it isn't" | 12:18 |
| zyga | jdstrand: hmm, who expressed this view? kernel developers or kdbus developers? | 12:19 |
| jdstrand | it's an interesting argument that has merit, but we fell on different sides. we felt it was useful to go to that depth, they (kdbus guys) did not | 12:20 |
| jdstrand | zyga: yes | 12:20 |
| jdstrand | if you recall, the kdbus discussions were lennart, kay and greg | 12:20 |
| zyga | jdstrand: well, I think I agree with kdbus developers for _new_ services written by security aware developers but that's not a good coverage of the software people want to use | 12:21 |
| jdstrand | Dan got into it a little bit, but not too much | 12:21 |
| zyga | jdstrand: what was his view? | 12:21 |
| zyga | (and the flatpak dbus proxy is a perfect example of that) | 12:22 |
| jdstrand | you should read the thread | 12:22 |
| zyga | jdstrand: is that the kdbus thread? any hints on what to google? | 12:22 |
| zyga | mvo: I applied your feedback on https://github.com/snapcore/snapd/pull/3102 | 12:25 |
| mup | PR snapd#3102: interfaces/mount: add function for parsing mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3102> | 12:25 |
| zyga | mvo: if we could merge that I have two more proposals to do on top | 12:25 |
| jdstrand | zyga: apparmor and kdbus | 12:25 |
| zyga | OK | 12:26 |
| zyga | thanks! | 12:26 |
| cachio | jdstrand, hey, fyi https://bugs.launchpad.net/apparmor/+bug/1677587 | 12:30 |
| mup | Bug #1677587: apparmor is denying access to executables shared through content interface <AppArmor:New> <https://launchpad.net/bugs/1677587> | 12:31 |
| Son_Goku | jdstrand: there's already a bit of a rudimentary selinux policy in data/selinux | 12:39 |
| Son_Goku | it needs beefing up, but at least it's enough to get snapd working | 12:39 |
| Son_Goku | snapd can't yet run properly confined :( | 12:39 |
| mvo | zyga: looking now, sorry for the delay | 12:45 |
| zyga | no worries | 12:47 |
| * zyga is a sad panda | 12:47 | |
| zyga | can't load package: package github.com/snapcore/snapd/cmd/snap-update-ns: use of cgo in test /home/zyga/go/src/github.com/snapcore/snapd/cmd/snap-update-ns/bootstrap_test.go not supported | 12:47 |
| mup | PR snapd#3102 closed: interfaces/mount: add function for parsing mount entries <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3102> | 12:49 |
| Chipaca | mvo, niemeyer, I'll be missing the standup today | 12:50 |
| mvo | Chipaca: no worries | 12:50 |
| fgimenez | ogra: snap kernel on edge is ok again \o/ https://travis-ci.org/snapcore/spread-cron/builds/216734158 | 12:52 |
| mvo | fgimenez: what happend? how did it get fixed? | 12:53 |
| zyga | mvo: it was reverted | 12:53 |
| zyga | mvo: look at this thread: https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77/16 | 12:53 |
| zyga | mvo: specifically this https://forum.snapcraft.io/t/spread-tests-fail-on-lack-of-dev-ram0/77/13 | 12:54 |
| mvo | ta | 12:55 |
| jdstrand | cachio: thanks, responded | 12:59 |
| jdstrand | Son_Goku: yeah, I was talking about the steps after that-- snap confinement and snap to snap communications | 13:00 |
| fgimenez | mvo: yep, it was finally fixed, i'll file a bug about the problem, ogra where should i report it? | 13:00 |
| ogra | fgimenez, against linux i guess | 13:00 |
| fgimenez | ogra: ok thanks | 13:01 |
| sergiusens | stgraber: hey, `lxc image list ubuntu:` doesn't return any 16.04 image (and it seems the aliases are all wonky too) | 13:02 |
| === hikiko-ln is now known as hikiko | ||
| jdstrand | roadmr: hi! can you pull r865? this isn't urgent and has code changes (tested of course :). I suggest not rolling out before weekend (ie, follow whatever staging procedures you'd normally use for code changes) | 13:04 |
| niemeyer | Chipaca: Ack, thanks for the note | 13:04 |
| niemeyer | Hello all | 13:05 |
| roadmr | jdstrand: sure! ok, let me check the commit log to see what the changes are about. But I'll have it in SCA trunk in a sec. | 13:05 |
| jdstrand | roadmr: code changes aren't extensive, it is just more than the last few pulls I've requested, | 13:09 |
| mup | PR snapd#3114 opened: interfaces/mount: add function for saving fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3114> | 13:19 |
| morphis | Son_Goku: hm, when I try to build snapd with mock for rawhide, shouldn't it fetch the golang-* packages we already pushed there? | 13:26 |
| morphis | always fails with saying it can't find those deps | 13:26 |
| Son_Goku | mirror sync is not complete, I suspect | 13:26 |
| Son_Goku | you can create custom mock targets to use | 13:27 |
| Son_Goku | I have a fedora-rawhide-x86_64-koji config that I use to access Koji's internal repos, since they are publicly accessible | 13:27 |
| Son_Goku | I'll paste it for you | 13:27 |
| morphis | thanks | 13:28 |
| Son_Goku | morphis: https://da.gd/Oh2U | 13:28 |
| Son_Goku | save it as "fedora-rawhide-x86_64-koji.cfg" | 13:29 |
| Son_Goku | then do "mock -r </path/to/fedora-rawhide-x86_64-koji.cfg> </path/to/package.src.rpm>" | 13:29 |
| morphis | ok | 13:29 |
| zyga | Chipaca: hey | 13:32 |
| zyga | Chipaca: you around? | 13:32 |
| Chipaca | zyga— with some latency yes | 13:32 |
| zyga | Chipaca: can you please eyeyball https://github.com/snapcore/snapd/pull/3103/files | 13:33 |
| mup | PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103> | 13:33 |
| zyga | Chipaca: if not too inconvenient | 13:33 |
| Chipaca | no probs | 13:33 |
| fgimenez | hey pstolowski during the 2.23.6 candidate validation vigo got this error on dragonboard http://paste.ubuntu.com/24281125/ afaik you have been working in this area, could you please take a look when you have a moment? | 13:38 |
| === jjohansen1 is now known as jj-cloaked | ||
| zyga | niemeyer: do you think we should have a "casual" category for posts that would not be related to snaps in any way? | 13:41 |
| ogra | "gossip" | 13:44 |
| ogra | :) | 13:44 |
| niemeyer | Hmm.. not sure.. problem is that they'd show in forum.snapcraft.io nevertheless.. | 13:45 |
| niemeyer | Let me see if there's some sort of "only inside category" setting | 13:45 |
| zyga | niemeyer: https://forum.snapcraft.io/t/should-we-have-category-casual-for-daily-chatter/80/1 | 13:45 |
| zyga | niemeyer: I see longue | 13:45 |
| zyga | niemeyer: but not sure if that's one post | 13:45 |
| zyga | niemeyer: or a category | 13:45 |
| Chipaca | zyga— +1'ed, with two ignorable notes | 13:47 |
| === jj-cloaked is now known as jjohansen | ||
| pedronis | niemeyer: I added the comment blocked to snapd#3113 if you want to review | 13:49 |
| mup | PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113> | 13:49 |
| pedronis | niemeyer: I put the PR link also in the forum | 13:50 |
| pedronis | s/blocked/block/ | 13:50 |
| fgimenez | ogra: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1677622 | 13:56 |
| mup | Bug #1677622: missing ramdisks in latest amd64 kernel snap <linux (Ubuntu):New> <https://launchpad.net/bugs/1677622> | 13:56 |
| ogra | fgimenez, great, thx | 13:57 |
| niemeyer | pedronis: Ack, thanks | 14:11 |
| pstolowski | fgimenez, sorry, i was in another meeting and missed your message. will take a look | 14:18 |
| fgimenez | pstolowski: np thanks | 14:19 |
| === josepht` is now known as josepht | ||
| mup | PR snapd#3115 opened: interfaces/unity7: support unity messaging menu <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3115> | 14:31 |
| King_InuYasha | zyga: morphis: make sure you guys give feedback on tomb updates: https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb | 14:34 |
| King_InuYasha | morphis: ahh, I see you did | 14:35 |
| pstolowski | fgimenez, this is super weird, I don't see a reason for it too fail on one arch and not others. any chance the tests were executed against an older revision of snapd for some reason? | 14:35 |
| King_InuYasha | zyga: please do so, so that it'll sync out to stable | 14:35 |
| pstolowski | vigo, ^ ? | 14:36 |
| fgimenez | pstolowski: i don't think so, dragonboard is notably slower than other platforms, afaik is the only diference, vigo can give you more details | 14:36 |
| pstolowski | fgimenez, ah, interesting | 14:36 |
| ogra | oh ? dragonboard is slower ? | 14:37 |
| ogra | (nobody told me yet) | 14:37 |
| vigo | pstolowski, my mistake I though I switched to the new branch | 14:38 |
| pstolowski | vigo, ah, so all good? | 14:43 |
| vigo | pstolowski, re-running spread tests | 14:43 |
| roadmr | hey folks, who can help me with the discourse.snapcraft.io forum? I tried signing up but it's not sending me the confirmation e-mail, so I can't really use it yet :( | 14:47 |
| ogra | niemeyer, is the admin ^^^ | 14:47 |
| roadmr | thanks! | 14:48 |
| niemeyer | roadmr: Heya | 14:53 |
| niemeyer | roadmr: Let me test the email sending | 14:53 |
| roadmr | thanks niemeyer! | 14:54 |
| roadmr | let me know if you need me to do anything | 14:54 |
| niemeyer | roadmr: Problem is in the system.. I'm probably blowing some quota | 14:56 |
| roadmr | oops :( | 14:56 |
| stgraber | sergiusens: that would be a CPC problem, the LXD team doesn't control the ubuntu: remote | 15:05 |
| mup | PR snapd#3116 opened: interfaces: allow executing ld.so (needed with new AppArmor base abstraction) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3116> | 15:08 |
| mup | PR snapd#2833 opened: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833> | 15:09 |
| vigo | pstolowski, ping | 15:12 |
| vigo | I ran again against current branch in i386 and failed again | 15:12 |
| vigo | https://pastebin.canonical.com/184322/ | 15:13 |
| niemeyer | roadmr: Looks like it was actually my own provider that crashed.. they have a critical announcement saying they're working on it | 15:14 |
| niemeyer | roadmr: I've shifted it to Canonical's SMTP.. can you please give it a try now? | 15:14 |
| roadmr | oh whoops :) | 15:14 |
| roadmr | niemeyer: sure thing, here I go | 15:15 |
| niemeyer | roadmr: You _migth_ have received the email already, actually | 15:15 |
| roadmr | niemeyer: none of the previous attempts have arrived, I just requested a new one, will wait a bit for it | 15:17 |
| niemeyer | roadmr: Thanks | 15:17 |
| pstolowski | vigo, hmm ok let me try it locally | 15:23 |
| roadmr | niemeyer: still nothing. ~10 mins feels slowish for an e-mail, right? | 15:25 |
| ogra | niemeyer, is there a setting in discourse that would open links in additional tabs or new windows ? currently a link i click replaces the forum .... | 15:28 |
| ogra | would be nice to have that opening in external pages | 15:28 |
| niemeyer | roadmr: Yeah | 15:30 |
| pstolowski | vigo, I just run this specific test against master and it passed here; are you running it against current master or a tagged version? | 15:30 |
| niemeyer | roadmr: There's definitely something broken, and I'm having a slightly harder time debugging because my own email is broken due to the provider | 15:31 |
| niemeyer | roadmr: Or there's just a big queue | 15:31 |
| vigo | pstolowski, np I updated to a non existing branch and lacked tests | 15:31 |
| vigo | it is correctly set now | 15:31 |
| roadmr | maybe queue + retries | 15:31 |
| === chihchun is now known as chihchun_afk | ||
| niemeyer | kyrofa: Did you just get an email from the forum? | 15:32 |
| pstolowski | vigo, hmm ok I'm confused now :), so is it all good and passing now after all? | 15:32 |
| kyrofa | niemeyer, just now? No | 15:32 |
| niemeyer | popey: What about you? | 15:33 |
| niemeyer | According to the logs the queue is slowly going out.. but I'm not sure about whether the SMTP host from Canonical has any constraints in terms of origin, etc | 15:34 |
| popey | hmm? | 15:36 |
| niemeyer | Yep, there we go.. | 15:37 |
| niemeyer | [Sender] 550 relay not permitted | 15:37 |
| roadmr | oops :) | 15:37 |
| niemeyer | Will need to do something else | 15:37 |
| popey | yeah, I have no emails for a while | 15:37 |
| popey | I'd recommend using a cloud email provider. flexiondotorg has done this at scale, and knows a good option | 15:37 |
| ogra | niemeyer, google smtp ... | 15:37 |
| flexiondotorg | No, don't use Google SMTP. Bad thing _will_ happen. | 15:38 |
| ogra | oh ? | 15:38 |
| flexiondotorg | I use Sendgrid. It's brilliant. | 15:38 |
| popey | yeah, you get blocked from google for using it too much | 15:38 |
| ogra | what are these bad things ? | 15:38 |
| popey | they have very strict limits | 15:38 |
| niemeyer | ogra: What is the password there? | 15:38 |
| ogra | oh | 15:38 |
| flexiondotorg | Google rejects lots of mail. | 15:39 |
| flexiondotorg | So the mailing list features of Discourse become unreliable and notifications don't work properly. | 15:39 |
| ogra | niemeyer, well, obviously gmail is a bad idea ... | 15:39 |
| niemeyer | flexiondotorg: Yeah, that was my idea too (sendgrid), except they deactivated my account for inactivity | 15:39 |
| flexiondotorg | Sendgrid is the way to go. | 15:39 |
| flexiondotorg | I have tried them all with Discource. | 15:39 |
| niemeyer | and guess what, I need email to re-activate it.. #FML | 15:39 |
| ogra | lol | 15:39 |
| roadmr | hehe :) | 15:41 |
| morphis | Pharaoh_Atem, King_InuYasha: lets give https://paste.fedoraproject.org/paste/DMpW-ZW11QIB76FA9DBnEF5M1UNdIGYhyRLivL9gydE= a try | 15:41 |
| lool | cjwatson: Hey | 15:47 |
| lool | cjwatson: I hope you had a good leave (if you're not back ignore this) | 15:47 |
| lool | cjwatson: I had a "store upload failed" for one snap build out of 4, I pressed "Retry" button, upload worked, but snap wasn't published to the channels it was supposed to be published in | 15:48 |
| lool | cjwatson: really minor but thought I'd mention it; would you like me to report this somewhere? | 15:48 |
| ogra | lool, are you sure it wasnt published ? note there is quite a delay | 15:49 |
| * ogra fell for that multiple times in the past | 15:49 | |
| lool | ogra: it passed review, and then was ready to publish | 15:49 |
| lool | I just clicked in the web UI to do so | 15:49 |
| ogra | right, and then between 10 and 20min later it publishes ... | 15:49 |
| lool | it had the "thumb up" icon | 15:49 |
| ogra | yeah | 15:49 |
| lool | and no channel selected | 15:50 |
| ogra | i see that at times for the core snap daily build ... but as i said, afetr a while it publishes then | 15:50 |
| cjwatson | lool: sure, report that as a Launchpad bug | 15:51 |
| kyrofa | ogra, lool I've seen the same 10 minute delay or so | 15:51 |
| lool | cjwatson: ok, seems to be normal; perhaps I only saw it because of the retry | 15:51 |
| roadmr | jdstrand: hello! oops, "unexpected output" from tools r865... | 15:54 |
| cjwatson | lool: so I mean there's the standard problem that we currently have to poll the store to find out when it's done with processing the actual upload, and we don't want to lock up a worker waiting for it, so we poll every so often | 15:54 |
| morphis | Pharaoh_Atem, King_InuYasha: lets see how it goes: https://koji.fedoraproject.org/koji/taskinfo?taskID=18684002 | 15:55 |
| lool | cjwatson: fine with me; I thought I had uncovered a weird case | 15:55 |
| jdstrand | roadmr: how did you invoke it? | 15:56 |
| jdstrand | roadmr: (I think I know the issue though) | 15:56 |
| roadmr | jdstrand: from latest trunk: $ PYTHONPATH=$PWD ./bin/click-review /tmp/hello-classic-tomechangosubanana-1_foo48_amd64.snap | 15:56 |
| roadmr | jdstrand: maybe you forgot to bzr add overrides? | 15:56 |
| roadmr | because "ImportError: No module named 'clickreviews.overrides'" | 15:57 |
| Pharaoh_Atem | morphis: you've already started a scratch build? | 15:57 |
| morphis | Pharaoh_Atem: yes | 15:57 |
| roadmr | jdstrand: (and I guess the trace is what the store is complaining about). | 15:57 |
| morphis | Pharaoh_Atem: tried to a local vm for i386 up but failed .. somehow vbox doesn't want to boot the fedora i386 images | 15:58 |
| jdstrand | did I forget to bzr add the file? | 15:58 |
| morphis | Pharaoh_Atem: and mock doesn't want to work on lxd | 15:58 |
| Pharaoh_Atem | morphis: you could have just done a mock build for i386 on x86_^4 | 15:58 |
| Pharaoh_Atem | *x86_64 | 15:58 |
| jdstrand | crap I did | 15:58 |
| roadmr | jdstrand: maybe :( so it'd work locally... | 15:58 |
| morphis | Pharaoh_Atem: tried this but failed :-) | 15:58 |
| morphis | Pharaoh_Atem: need to play a little bit more and look at what I am doing than just doing it next to a meeting | 15:59 |
| jdstrand | roadmr: r866. sorry | 16:00 |
| roadmr | jdstrand: no problem, at least we caught it quickly :) | 16:00 |
| === JanC is now known as Guest23500 | ||
| === JanC_ is now known as JanC | ||
| morphis | Pharaoh_Atem: we're coming closer: https://koji.fedoraproject.org/koji/taskinfo?taskID=18684268 | 16:15 |
| morphis | Pharaoh_Atem: for the ppc64 build I don't have any idea yet | 16:18 |
| Pharaoh_Atem | morphis: did you ask for a VM in #fedora-ppc yet? | 16:21 |
| morphis | Pharaoh_Atem: not yet | 16:23 |
| morphis | mvo, zyga: are we building snapd in ubuntu for ppc64? | 16:24 |
| Pharaoh_Atem | morphis: you're not in Debian | 16:27 |
| Pharaoh_Atem | but in Ubuntu, you're building against powerpc and ppc64el | 16:27 |
| morphis | yeah, just saw that | 16:27 |
| morphis | just want to get a baseline for things to look in | 16:27 |
| Pharaoh_Atem | I'm *guessing* that powerpc is the < POWER 7 big endian architectures | 16:28 |
| Pharaoh_Atem | aka, the 32-bit ones | 16:28 |
| nacc | Pharaoh_Atem: yes, BE power | 16:28 |
| Pharaoh_Atem | old BE POWER, but yes | 16:29 |
| Pharaoh_Atem | morphis: so endianness shouldn't break it :/ | 16:29 |
| morphis | Pharaoh_Atem: it shouldn't | 16:30 |
| morphis | but also we have go 1.6 vs. 1.8 | 16:30 |
| Pharaoh_Atem | right | 16:30 |
| morphis | latest we have in ubuntu is 1.7 in zesty | 16:30 |
| morphis | Pharaoh_Atem: sad that the build log doesn't give any error | 16:31 |
| morphis | Pharaoh_Atem: also interesting is that this (if the log can be trusted) fails when building golang.org/x/net/context/ctxhtt | 16:35 |
| Pharaoh_Atem | well, time to test a theory, I guess | 16:42 |
| morphis | Pharaoh_Atem: drop the guy (sharkcz) a mail to get VM access | 16:43 |
| Pharaoh_Atem | morphis: you mean you sent him an email | 16:46 |
| morphis | yes | 16:46 |
| morphis | s/drop/dropped/ | 16:46 |
| zyga | morphis: yes we do build snapd for ppc64 | 16:56 |
| morphis | zyga: any idea why https://kojipkgs.fedoraproject.org//work/tasks/4273/18684273/build.log fails? | 16:57 |
| morphis | zyga: our last issue on the way to have snapd in rawhide :-) | 16:57 |
| renatu | jdstrand, could you please :D? https://myapps.developer.ubuntu.com/dev/click-apps/6676/rev/2/ | 16:57 |
| zyga | morphis: checking | 16:59 |
| zyga | morphis: sorry, where is the error there? | 16:59 |
| zyga | that's pretty uncomprehensible to me | 17:00 |
| morphis | zyga: that is the question :-) | 17:00 |
| zyga | it looks like /usr/lib/golang/pkg/tool/linux_ppc64/compile -o $WORK/golang.org/x/net/context/ctxhttp.a -trimpath $WORK -p golang.org/x/net/context/ctxhttp -complete -buildid dd5b033021ca065fee8c7c29c22a9306c1500731 -D _/usr/share/gocode/src/golang.org/x/net/context/ctxhttp -I $WORK -I /usr/share/gocode/pkg/linux_ppc64 -pack ./ctxhttp.go fails to compile | 17:00 |
| morphis | yeah, trying to add a -v to that right now to get more details | 17:00 |
| zyga | i'd add --quiet to see less noise | 17:01 |
| zyga | and see just "this is what failed" | 17:01 |
| morphis | Pharaoh_Atem: did you saw this with your bundled builds too? | 17:01 |
| jdstrand | renatu: done | 17:01 |
| Pharaoh_Atem | the patches don't apply | 17:02 |
| morphis | Pharaoh_Atem: ah | 17:02 |
| zyga | why would that be only on one arch? | 17:02 |
| Pharaoh_Atem | it's the only big endian arch | 17:03 |
| morphis | "patch unexpectedly ends in middle of line" | 17:03 |
| morphis | but if something wouldn't apply it would fail the build | 17:03 |
| renatu | jdstrand, thanks | 17:03 |
| zyga | Pharaoh_Atem: how does that matter for patches? | 17:03 |
| renatu | jdstrand, did you add it to whitelist? | 17:03 |
| zyga | Pharaoh_Atem: note that this builds on ubuntu, we don't know what really fails as that log is garbage-ish | 17:04 |
| jdstrand | renatu: yes | 17:04 |
| Pharaoh_Atem | zyga: since the systemd unit patches fail to apply, the build stops | 17:04 |
| zyga | Pharaoh_Atem: aha, do we have any arch-specific patches? | 17:05 |
| renatu | jdstrand, thanks twice ;) | 17:05 |
| Pharaoh_Atem | nope | 17:05 |
| Pharaoh_Atem | the patch that failed was the one that rewrites the systemd unit files to use templates | 17:05 |
| Pharaoh_Atem | apparently it couldn't find the location to apply the files | 17:05 |
| zyga | Pharaoh_Atem: I still don't understand how that only fails on ppc64 | 17:06 |
| * Pharaoh_Atem shrugs | 17:06 | |
| zyga | Pharaoh_Atem: I bet I'm missing something :/ | 17:06 |
| morphis | Pharaoh_Atem: where do you see that in the logs? | 17:06 |
| morphis | + /usr/bin/cat /builddir/build/SOURCES/PR3084-packaging-use-templates-for-systemd-units.patch | 17:06 |
| morphis | doesn't give any error | 17:06 |
| Pharaoh_Atem | https://koji.fedoraproject.org/koji/taskinfo?taskID=18685116 | 17:07 |
| Pharaoh_Atem | https://kojipkgs.fedoraproject.org//work/tasks/5116/18685116/build.log | 17:07 |
| morphis | ah, that is a different build | 17:07 |
| Pharaoh_Atem | it fails because mvo strips .gitignore | 17:07 |
| morphis | ah so you're talking about the vendorized build? | 17:08 |
| Pharaoh_Atem | yes | 17:08 |
| morphis | ah :-) | 17:08 |
| morphis | that confused zyga I guess | 17:08 |
| Pharaoh_Atem | you asked about bundled/vendorized build | 17:08 |
| morphis | yeah I know | 17:08 |
| morphis | however close to EOD, will look again into this tomorrow morning | 17:09 |
| zyga | morphis: you know, just kill ppc64 | 17:09 |
| zyga | and revisit next time | 17:09 |
| morphis | Pharaoh_Atem: ^^ | 17:09 |
| Pharaoh_Atem | fine | 17:10 |
| Pharaoh_Atem | I'll do that for now | 17:10 |
| morphis | zyga: you know, I am pragmatic, I am all in for those things :-) | 17:10 |
| zyga | while I'd like to see ppc64 flourish the arch is dead dead dead and will stay dead unless something happens | 17:10 |
| morphis | :-) | 17:12 |
| Pharaoh_Atem | zyga: we do not support s390x, I guess? | 17:13 |
| Pharaoh_Atem | or mips? | 17:13 |
| zyga | Pharaoh_Atem: s390x is "supported" | 17:13 |
| zyga | Pharaoh_Atem: I think at least | 17:13 |
| zyga | Pharaoh_Atem: mips no because there's no mips build of ubuntu | 17:13 |
| zyga | Pharaoh_Atem: mips would be cool but it seems to be dominated by 4MB flash crap devices | 17:14 |
| Pharaoh_Atem | zyga: Fedora is in the middle of a MIPS bootstrap, which is why I asked | 17:17 |
| zyga | Pharaoh_Atem: do you know what kind of hardware is used? | 17:18 |
| Pharaoh_Atem | not yet, no | 17:18 |
| Pharaoh_Atem | I've not talked to Michel about it | 17:18 |
| zyga | Pharaoh_Atem: I have a ci20 but I must sadly say it's crap | 17:19 |
| zyga | Pharaoh_Atem: the kernel crashes in minutes | 17:19 |
| mup | PR snapd#3116 closed: interfaces: allow executing ld.so (needed with new AppArmor base abstraction) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3116> | 17:19 |
| Pharaoh_Atem | zyga: I need you to retire snap-confine for me | 17:25 |
| zyga | Pharaoh_Atem: how do I do that? | 17:26 |
| Pharaoh_Atem | zyga: fedpkg co snap-confine && fedpkg switch-branch f24 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f25 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f26 && fedpkg retire "Merged into snapd" fedpkg switch-branch master && fedpkg retire "Merged into snapd" | 17:27 |
| Pharaoh_Atem | err | 17:27 |
| Pharaoh_Atem | fedpkg co snap-confine && cd snap-confine && fedpkg switch-branch f24 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f25 && fedpkg retire "Merged into snapd" && fedpkg switch-branch f26 && fedpkg retire "Merged into snapd" fedpkg switch-branch master && fedpkg retire "Merged into snapd" | 17:27 |
| zyga | Pharaoh_Atem: thanks! | 17:27 |
| zyga | Pharaoh_Atem: I'll do that shortly :) | 17:27 |
| Pharaoh_Atem | actually, need to change command slightly | 17:27 |
| Pharaoh_Atem | one second | 17:27 |
| Pharaoh_Atem | I'm going to merge the commit I already made to all branches | 17:29 |
| morphis | Pharaoh_Atem: you're going to trigger new builds for snapd now or is that a thing for tomorrow? | 17:30 |
| Pharaoh_Atem | I'm doing it now, yes | 17:30 |
| morphis | Pharaoh_Atem: great, then we can call out for testing in the community tomorrow | 17:32 |
| Pharaoh_Atem | zyga: pkgdb-cli orphan --retire snap-confine f24 && pkgdb-cli orphan --retire snap-confine f25 && pkgdb-cli orphan --retire snap-confine f26 | 17:32 |
| Pharaoh_Atem | zyga: run this asap | 17:32 |
| zyga | Pharaoh_Atem: ack | 17:39 |
| Pharaoh_Atem | zyga: I've already retired it from rawhide, and you're the only person who can run it for the older branches | 17:39 |
| Pharaoh_Atem | building F26 package now | 17:40 |
| Pharaoh_Atem | at least now the buildsystem will stop bitching about the snapd-glib broken dep | 17:40 |
| zyga | 60 seconds | 17:40 |
| zyga | Pharaoh_Atem: it said I must use fedpkg retire first | 17:42 |
| Pharaoh_Atem | then do that | 17:42 |
| zyga | ay | 17:43 |
| zyga | Pharaoh_Atem: push got rejected | 17:43 |
| zyga | hmmm | 17:43 |
| zyga | Pharaoh_Atem: hook declined update | 17:44 |
| Pharaoh_Atem | did you do it with a fresh checkout? | 17:44 |
| zyga | Pharaoh_Atem: no, with one I had on disk | 17:44 |
| Pharaoh_Atem | it should already have "dead.package" files on every branch from f24 on up | 17:44 |
| zyga | Pharaoh_Atem: shall I try with a fresh one? | 17:44 |
| Pharaoh_Atem | yes | 17:44 |
| zyga | ok | 17:44 |
| Pharaoh_Atem | actually a fresh checkout may let you just use pkgdb CLI | 17:44 |
| Pharaoh_Atem | but try with fedpkg retire | 17:44 |
| Pharaoh_Atem | if fedpkg retire works, more power to us :) | 17:45 |
| zyga | Pharaoh_Atem: said I'm not allowed to retire f25 | 17:46 |
| zyga | hmmm | 17:46 |
| zyga | trying pkgdb | 17:46 |
| zyga | nope | 17:46 |
| zyga | any ideas? | 17:46 |
| Pharaoh_Atem | zyga: pop into #fedora-releng and ask about it | 17:47 |
| zyga | Pharaoh_Atem: "dead.package found" but then says "no `dead.package' for snap-confine on f24" | 17:47 |
| zyga | OK | 17:47 |
| jdstrand | ogra: can you kick off a build for linux-generic-bbb? | 17:50 |
| Pharaoh_Atem | morphis, zyga: snapd FTBFS on F24 and F25 | 17:54 |
| Pharaoh_Atem | oh wait, I know why | 17:54 |
| Pharaoh_Atem | because I need buildroot overrides | 17:54 |
| Pharaoh_Atem | duh | 17:54 |
| Pharaoh_Atem | zyga: drop your watch commits and approvacls here: https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/ | 17:57 |
| zyga | Pharaoh_Atem: trying | 17:57 |
| === TinoGuest_ is now known as TinoGuest | ||
| zyga | Pharaoh_Atem: I managed to orphan in f24/25 | 18:00 |
| zyga | Pharaoh_Atem: can you check | 18:01 |
| zyga | Pharaoh_Atem: I'm not sure what to do | 18:01 |
| Pharaoh_Atem | change your watchcommits to obsolete here: https://admin.fedoraproject.org/pkgdb/package/rpms/snap-confine/acl/watchcommits/ | 18:01 |
| zyga | that's done | 18:02 |
| Pharaoh_Atem | there, that's taken care of | 18:03 |
| niemeyer | roadmr: Should be all sorted out, btw | 18:04 |
| niemeyer | ogra: core-build reporting here too | 18:04 |
| Pharaoh_Atem | zyga: could you give positive karma on https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb ? | 18:16 |
| Pharaoh_Atem | that way it'll cycle out to stable quickly? | 18:16 |
| zyga | sure | 18:17 |
| Pharaoh_Atem | all the ones with +2 need good karma | 18:17 |
| Pharaoh_Atem | that way, they'll sync out with stable updates push in an hour or so | 18:18 |
| Pharaoh_Atem | at least, I think it's in an hour | 18:18 |
| Pharaoh_Atem | then I don't have to do too many buildroot overrides | 18:18 |
| zyga | Pharaoh_Atem: done | 18:21 |
| zyga | Pharaoh_Atem: gee, I should manage something myself, this feels good | 18:21 |
| zyga | Pharaoh_Atem: just golang packages are not very interesting "works for me" is hard to tes | 18:22 |
| zyga | test | 18:22 |
| jdstrand | kyrofa: to save you time: https://github.com/snapcore/snapd/pull/3112#discussion_r109008576 | 18:57 |
| mup | PR snapd#3112: interfaces: add a joystick interface <Created by kyrofa> <https://github.com/snapcore/snapd/pull/3112> | 18:57 |
| kyrofa | jdstrand, hahaha, right after I commented, I saw "AppArmor pcre syntax (currently not supported)" in the reference | 18:57 |
| kyrofa | Felt dumb | 18:57 |
| kyrofa | jdstrand, the "Documentation of language syntax" above is what misled me | 18:58 |
| jdstrand | no worries. it looks like regex sometimes, but it isn't | 18:58 |
| zyga | jdstrand: could you do a quick review for getmntent replacement? | 18:59 |
| zyga | https://github.com/snapcore/snapd/pull/3103#discussion_r108927742 | 18:59 |
| mup | PR snapd#3103: interfaces/mount: add function for parsing fstab-like file <Created by zyga> <https://github.com/snapcore/snapd/pull/3103> | 18:59 |
| jdstrand | zyga: I cannot, I'm time-shifting today and will be on the road in a few minutes. if you need it today, perhaps ask tyhicks to see if he can put someone on it, otherwise it will have to wait | 19:01 |
| kyrofa | jdstrand, wait, I'm a little confused. The PR in its current state will allow /dev/input/js. Is your snippet different? | 19:01 |
| zyga | jdstrand: OK | 19:01 |
| zyga | jdstrand: it's okay, it's not urgent | 19:01 |
| kyrofa | jdstrand, you say "if you want to support /dev/js" | 19:01 |
| zyga | kyrofa: maybe you? it's super short and I have one review already | 19:02 |
| jdstrand | kyrofa: sorry I wrote the comment too fast. I meant to have input/ in all reference to /dev/js | 19:03 |
| kyrofa | jdstrand, I know what you meant-- I'm really talking about js with no numbers following | 19:03 |
| jdstrand | kyrofa: do you want no numbers to be supported too? | 19:04 |
| kyrofa | jdstrand, at least in my experimentation, it always has a number | 19:04 |
| jdstrand | kyrofa: then leave it as is. reading https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/devices.txt it seems it always has a number | 19:05 |
| kyrofa | jdstrand, good deal | 19:05 |
| zyga | jdstrand: note that update-ns is not setuid root | 19:06 |
| zyga | jdstrand: it's just a program | 19:06 |
| Pharaoh_Atem | zyga: I'm sure you have some other interesting software you'd like in Fedora :) | 19:06 |
| zyga | jdstrand: if someone makes it crash, well, fine (though I think the current code is written in a way that won't easily crash) | 19:06 |
| jdstrand | kyrofa: actually in reading that I'm reminded that you also want: /run/udev/data/c13:{[0-9],[12][0-9],3[01]} r, | 19:06 |
| kyrofa | zyga, sorry man, I have no context for that review, I couldn't do it justice | 19:06 |
| zyga | Pharaoh_Atem: I'll think of something, maybe made in C, without many deps | 19:06 |
| zyga | kyrofa: no worries, thanks | 19:07 |
| kyrofa | jdstrand, whoa :P | 19:07 |
| zyga | kyrofa: I think your brain just exploded | 19:07 |
| jdstrand | zyga: I know it isn't setuid root. but if an unprivileged user can make snapd call update-ns with arbitrarily controlled arguments, then the unpriv user can try to attack update-ns | 19:08 |
| kyrofa | zyga, he says it so casually. "By the way, I should probably mention you need this insane glob in there" | 19:08 |
| zyga | jdstrand: update-ns is only called when we connect/disconnect content | 19:08 |
| zyga | jdstrand: and the argument is always just the snap name | 19:08 |
| zyga | jdstrand: no input | 19:08 |
| kyrofa | jdstrand, is that just where udev places the in-affect rules? | 19:10 |
| jdstrand | kyrofa: no, that is just some udev info on the device that some libraries like to read. go ahead and cat /run/udev/data/c13:0 if js0 is plugged in | 19:11 |
| jdstrand | zyga: can you add a comment to the PR that the arguments to update-ns are not user-controllable (like you just did here) | 19:11 |
| kyrofa | jdstrand, huh, neat | 19:12 |
| jdstrand | ok, heading out, 'see' you monday :) | 19:12 |
| zyga | yes | 19:12 |
| zyga | o/ | 19:12 |
| jdstrand | thanks | 19:13 |
| pedronis | niemeyer: have you looked at snapd#3113 ? | 19:22 |
| mup | PR snapd#3113: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3113> | 19:22 |
| niemeyer | pedronis: Not yet.. after solving a couple of details in the forum, I'm now running through the new threads and opening the PR review requests I found there in new tabs.. then will look through them all | 19:23 |
| niemeyer | pedronis: I can look at that one now if you can make good use of immediate feedback | 19:23 |
| JamieBennett | niemeyer: can we please enable other forms of auth on the forum for new users? Apparently its pretty easy to do. | 19:26 |
| niemeyer | JamieBennett: https://forum.snapcraft.io/t/support-for-sso-on-forum-snapcraft-io/75/5 | 19:26 |
| JamieBennett | Right but it would be good to enable that early no? | 19:27 |
| pedronis | mvo: there's a bunch of autopkgtest failing with something like: 2017/03/30 18:00:26 Discarding autopkgtest:ubuntu-16.04-amd64, cannot connect: cannot connect to autopkgtest:ubuntu-16.04-amd64: ssh: must specify HostKeyCallback | 19:27 |
| roadmr | thanks niemeyer ! I just got the confirmation e-mail. Awesome :) | 19:43 |
| niemeyer | pedronis: Reviewed, if you're not watching the forum | 19:59 |
| pedronis | niemeyer: yes, answered you concerens in the review and the forum | 20:04 |
| niemeyer | pedronis: vvv | 20:04 |
| niemeyer | Man.. that never works well.. it's merged. | 20:04 |
| mup | PR snapd#3113 closed: overlord/snapstate: unlock/relock the state less, especially not across mutating the SnapState of a snap <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3113> | 20:04 |
| niemeyer | mup: You're late! | 20:05 |
| mup | niemeyer: Roses are red, violets are blue, and I don't understand what you just said. | 20:05 |
| pedronis | niemeyer: thanks, was about to merge it | 20:07 |
| pedronis | niemeyer: about the aliases gdoc, I was a bit confused by your comments, are you planning to move to a wiki entry in the forum? or something I shoul do? | 20:13 |
| niemeyer | pedronis: I will.. I have it half-way done and ended up being distracted by other concerns yesterday | 20:13 |
| niemeyer | pedronis: Should be there by tomorrow | 20:13 |
| pedronis | ok | 20:13 |
| pedronis | np | 20:13 |
| pedronis | niemeyer: I updated snapd#3044 to follow current direction | 21:27 |
| mup | PR snapd#3044: snapstate: more helpers to work with alias states (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3044> | 21:27 |
| * pedronis calls it a day | 21:27 | |
| niemeyer | pedronis: Sweet, thanks! | 21:27 |
| niemeyer | I'm going to (try to) step out as well.. haven't had much sleep lately | 21:28 |
| cachio | jdstrand, do you know if there is a way to uninstall + install thte same snap without download it again? | 22:09 |
| kyrofa | cachio, snap download it first | 22:15 |
| kyrofa | cachio, that will obtain both the snap and its assertion. If you `snap ack` the assertion before installing it, you don't need --dangerous and it'll still update from the store | 22:16 |
| cachio | kyrofa, awesome, I'll try that, thanks | 22:16 |
| kyrofa | cachio, I believe you'll only need to `snap ack` once, and install however many times, but don't quote me on that. Removing the snap could possibly remove the assertion | 22:17 |
| cachio | kyrofa, ok | 22:18 |
| mwhudson | i don't think assertions are removed at all currently? | 22:23 |
| mwhudson | not sure either | 22:24 |
| kyrofa | mwhudson, I suspect you're right, just unverified | 22:24 |
| mwhudson | what's the easiest way to set up a daily build of a snap in launchpad? | 22:26 |
| mwhudson | in the case where the branch containing the snapcraft.yaml does not change | 22:26 |
| mwhudson | presumably i could call the launchpad api from a cronjob but wondering if there is anything neater | 22:27 |
| kyrofa | mwhudson, I use Travis daily jobs to make a new commit to change the version and force-push to a branch in LP which has a snap building/publishing on changes | 22:29 |
| kyrofa | mwhudson, gnarly | 22:29 |
| mwhudson | kyrofa: yeah, that doesn't sound much better than what i said | 22:29 |
| kyrofa | mwhudson, in fact, I prefer your solution | 22:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!