mupPR snapcraft#1879 opened: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>02:00
niemeyerMorning all05:42
niemeyerSaviq: I've added the additional machines you requested on Spread, should be accessible to you already05:42
=== chihchun_afk is now known as chihchun
Saviqniemeyer: fantastic, thank you06:26
mupPR snapd#4464 closed: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4464>07:40
mvo_cachio: everything ready in the beta channel for validation. as yesterday no new snapd, just package updates (see http://people.canonical.com/~mvo/core-changes/html/beta/ for details)07:45
mborzeckimvo_: morning07:47
mvo_hey mborzecki !07:49
mborzeckimvo_: do you know if snapcraft also needs to do some work on https://forum.snapcraft.io/t/snap-service-start-ordering/1470/ ?07:49
mborzeckimvo_: that's also what pedronis suggested, what leaves me wondering if i should poke someone from the snapcraft07:50
mvo_mborzecki: I think it does, it has a yaml schema for everything that can go into snapcraft.yaml. so the new things need to be added there iirc07:53
mvo_mborzecki: you can poke sergiusens (at a sprint) or kalikiana07:53
mborzeckiok, thanks07:53
mvo_mborzecki: probably relatively easy, you could give it a stab yourself07:53
zyga-ubuntugood morning07:55
mborzeckizyga-ubuntu: hey07:55
zyga-ubuntuhow are you all feeling? :)07:55
kalikianahey mborzecki07:58
kalikianaI can give you some pointers if needed07:59
kalikianaadding that should be pretty straightforward07:59
kalikianaassuming you'll want basically the same yaml as in the snap.yaml08:00
sergiusensmvo_ mborzecki we got guidance at the sprint that the user docs need to be written first before proceeding on features so a PR against the docs would be nice to see08:05
zyga-ubuntusergiusens: interesting, thanks for sharing08:05
* zyga-ubuntu enjoys morning coffee08:06
mupPR snapd#4492 closed: spread: try to enable Fedora once more <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4492>08:39
mupPR snapd#4504 opened: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>08:39
mborzeckifigured i might as well add support for the watchdog if i'm to update snapcraft and the docs08:40
mvo_mborzecki: +108:44
mupPR snapd#4500 closed: snapstate: make no autorefresh message clearer <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4500>09:13
zyga-ubuntu4499 needs a 2nd review09:13
zyga-ubuntupstolowski: perhaps?09:14
pstolowskiloooooking, but github is sooo slooow atm09:16
* Chipaca waves09:16
zyga-ubuntumborzecki: does this need a gustavo approval? https://github.com/snapcore/snapd/pull/448709:17
mupPR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>09:17
zyga-ubuntuChipaca: o/ \o \o/09:17
mborzeckizyga-ubuntu: yes, probably09:17
Chipacamvo_: I'd added the "sleep 1" thinking that the reason it wasn't seeing the messages in the journal was a race, when in the end it was git being a git09:17
Chipacamvo_: so i was able to drop the sleep 1 \o/09:17
mborzeckiasked niemeyer to take a look at both #4487 and #447609:18
mupPR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>09:18
mupPR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476>09:18
pstolowskiuhm no github for me atm, anyone else having problems?09:22
zyga-ubuntupstolowski: works for me09:24
mvo_Chipaca: yeah, I noticed09:25
* zyga-ubuntu solicits reviews for https://github.com/snapcore/snapd/pull/447109:25
mupPR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>09:25
mvo_mborzecki: I added a suggestion to the 4467, maybe a personal thing, but I found it slighly easier this way. please check it out.09:26
mborzeckimvo_: it's much cleaner indeed, thanks09:28
Chipacahurray for enabling opensuse spread tests again, but … they're failing again? :-(09:33
mvo_mborzecki: thank you09:37
mvo_Chipaca: yeah, tests are a bit unstable again :/09:37
Chipacawith the EOF thing I thought was my fault in the user pr!09:37
Chipacathat one was driving me crazy(er)09:37
Chipacagood luck :-D09:37
mvo_mborzecki: thanks for working on 4504! quick question: aiui for watchdogSec to work the app must call sd_notify() which needs to talk to a system socket - does that mean this pr also needs apparmor rules so that the app can access this socket?09:39
Chipacamvo_: hah! i just commented trying to point mborzecki along those lines :-D09:40
Chipacaget out of my head :-p09:40
mborzeckimvo_: yeah, this was mentioned by Chipaca in https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/226809:40
* mvo_ hugs Chipaca (from the inside)09:40
mborzeckianways, i'm about to find out the hard way :)09:40
mvo_mborzecki: haaha09:40
* Chipaca installing every app in /var/cache/snapd/names to check for validation problems09:42
Chipacas|app|snap with type:app|09:43
mvo_mborzecki: its slightly annoying that the NOTIFY_SOCKET is set via an env, it seems it is currently /run/systemd/notify it seems there is no grantee about this09:43
=== chihchun is now known as chihchun_afk
mvo_Chipaca: what is annoying is that 4503 failed three times already for different reasons :(09:49
Chipacamvo_: if you've restarted it 3 times, then it's been restarted at least 509:53
zyga-ubuntuoh, I restarted it too09:55
mvo_Chipaca: *weep*09:55
zyga-ubuntuthat's one unlucky bastard then09:55
mvo_and also *moreweep*09:55
zyga-ubuntumaybe it will be around when we hit PR 10K09:55
mupPR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>09:55
Chipacawe should have a 'carbon footprint per PR' competition09:55
mvo_pr #10009:55
mupPR #100: Ongoing work on the capability APIs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/100>09:55
mvo_pr #100009:55
mupPR #1000: debian: use sudo in setup of the proxy environment <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1000>09:55
mvo_pr #109:56
mvo_Chipaca: heh, pretty even, no? 10: you, 100: zyga, 1000: me09:56
mvo_pr 109:56
mvo_*pff* no pr 1?09:56
Chipacait was probably an issue09:57
zyga-ubuntubug #1 ;-)09:57
mupBug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for ramvi>09:57
mup<Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <ReactOS Core Operating System:Incomplete> <Tabuntu:Invalid by09:57
muptinarussell> <Tivion:Invalid by shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Confirmed> <Ubuntu:Fix Released> <Arch Linux:New>09:57
mup<Baltix:Confirmed> <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>09:57
* zyga-ubuntu gets back to work09:57
Saviqjdstrand: fwiw, it's just a case of installing xrdp and a desktop environment, and putting the session name (like "mate-session") in ~/.xsession10:03
zyga-ubuntukind ping about 447110:15
zyga-ubuntuit's blocking everything for me10:15
zyga-ubuntuplease halp10:15
ogramvo_, i have some weird behaviour of core on one of my boards here, seems it auto-refreshed to the beta one even though it tracks edge10:17
mvo_ogra: what do you see in "snap changes"?10:19
ogramvo_, https://paste.ubuntu.com/26409733/10:19
ogratracking:    edge10:19
ograinstalled:   16-2.30 (3872) 71MB core10:19
mvo_ogra: I switched edge/beta around a bit in the morning, so maybe you see effects from this10:19
ograin the morning ? ... thats 3:30am !10:20
mvo_ogra: this an non i386/amd64 system, right?10:20
ogra(admittedly in technical sense that is "morning" indeed :P )10:20
ogramvo_, armhf10:21
mvo_ogra: heh :) yeah, I did not mess around with things at this time10:21
mvo_ogra: when is the next auto-refresh (snap refresh --time)?10:21
ogra$ snap refresh --time10:21
ograschedule: 00:00-05:59/6:00-11:59/12:00-17:59/18:00-23:5910:21
ogralast: 2018-01-18T06:21:00Z10:21
ogranext: 2018-01-18T15:55:00Z10:21
mvo_ogra: I wonder if the next auto-refresh will push you back to a +git version10:21
ograthe revision is lower now ...10:22
ogra(in edge(10:22
ograi could run a manual refresh ...10:22
mvo_ogra: yeah, this is what I did this morning, moved edge back to a git version10:22
mvo_ogra: yeah, just snap refresh should bring you back. I think its "expected" (in an unexpected way)10:22
ogra(should not be different from auto, right ?)10:22
ograand so it does ...10:23
ograMake snap "core" (3852) available to the system10:23
mvo_ogra: i.e. yesterday edge was "2.30" and there was a core snap build in the night which also had 2.30, then later your board refrehsed to 2.30 and in my morning I pushed edge back into +git land and now it should refresh to this (does that make sense)10:23
ograyeah, makes complete sense10:24
ograthanks for clearing the myth :)10:24
mvo_ogra: its all (more) confusing because no auto-builds, everything need to be manually approved for building10:25
ogra(i only noticed because i had put the revision into a release note for a customer ... and was just shocked that i typoed 3852 for 3872 when i looked at it this morning :P )10:25
ogramean that the revisions were so similar :)10:26
ads20000Speaking of `beta`s...the beta is a different revision to candidate/stable but the same version number? Seems confusing...what happened there?10:51
ads20000Was it just because you were switching them around? :10:51
ads20000* :P10:51
ograversion numbers in snaps are shallow10:54
ograthey are just a string in snapcraft.yaml ...10:54
ograrevisions are what counts10:54
ograthat said ...10:54
Chipacaversions are for human consumption :-)10:55
ograit is likely the content is actually the same in the case of core10:55
Chipacaand are merely descriptive10:55
ogra(unless some of the additional packages changed ... the core snapcraft.yaml actually generates the version from the snapd version)10:55
zyga-ubuntuChipaca: it failed again11:16
zyga-ubuntuon fedora11:16
mupPR snapd#4503 closed: osutil/sys: ppc has 32-bit getuid already <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4503>11:27
zyga-ubuntumvo_: was it green in the end/11:31
mvo_zyga-ubuntu: no, i merged it anyway11:31
mvo_zyga-ubuntu: I need to get a deb build to see if it fixes the build failure11:32
Chipaca"contact develper"11:33
* Chipaca looks for a brown paper bag11:33
Chipacaand i only realised when writing https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/356611:34
zyga-ubuntuwhat is contact developer about?11:47
mvo_zyga-ubuntu: "develper"11:51
jdstrandzyga-ubuntu: fyi, I reviewd 447211:54
jdstrandreviewed even11:54
zyga-ubuntuthank you!@11:58
zyga-ubuntuthanks! I'll update the rules and merge11:59
zyga-ubuntujdstrand: I'm working on layouts now, while they won't work (apparmor) they are now applied to mount profile, the PR will need some discussion but it looks like a good start11:59
* pstolowski lunch12:01
jdstrandgreyback: ok, so, in thinking about this, I think we want to adjust the *mir*ConnectedPlugAppArmor policy to have '/{dev,run}/shm/\#* mrw,', then have your snap plugs mir and x1112:02
jdstrandgreyback: the idea is that if your snap snips xwayland, it is a mir client, so needs to 'plugs: [mir]', then the thing that talks to x11 needs to 'plugs: [x11]'12:04
greybackjdstrand: xwayland is a wayland client, it's not using the mirclient libraries12:05
jdstrandgreyback: this is slightly odd because the app is really the slot for x11 though12:05
greybackyeah I know12:05
jdstrandgreyback: the shm access is really a mir thing though, no?12:05
greybackis having a separate xwayland snap, which has the x11 slot, too much?12:06
greybackjdstrand: that is something I've never quite figured out12:06
greybackperhaps I should, to get things straight12:06
jdstrandgreyback: in terms of policy, the shm access is only in mir12:06
jdstrandI was extrapolating from there when I suggested adjusting mir12:07
greybackyep, understood12:07
jdstrandI also understand the the shm access within the context of mir is considered safe12:07
greybacklet me ask around and try verify that12:08
greybackor at least figure out exactly what in /dev/shm is needed12:08
greybackand by what12:08
jdstrandgreyback: ftr, having a separate xwayland snap would not be required. you could embed it; your snap would just slots x11 (assuming we had that policy)12:09
jdstrandso you slot it to yourself12:09
jdstrandbut, let me read something back you said a minute ago12:09
greybackI didn't know you could slot to yourself12:09
greybackthat would do the trick12:10
jdstrandlet's assume that xwayland is one command in your snap and chromium another12:10
jdstrand(for clarity)12:10
jdstrandif xwaland is a wayland client, it should plugs wayland (let's not worry about shm for the moment)12:10
jdstrandchromium is not a wayland client, so it should plugs x1112:11
jdstrandxwayland command is providing x1112:11
jdstrandso xwayland slots x1112:11
jdstrandthe x11 interface grows the slot side (perhaps we can put the shm access in PermanentSlotAppArmor...)12:12
greybackright so ar12:12
jdstrandthe you have12:12
jdstrandname: foo12:12
jdstrand  apps:12:12
jdstrand    chromium:12:13
jdstrand      plugs: [ x11 ]12:13
jdstrand    xwayland:12:13
jdstrand      slots: [ x11 ]12:13
jdstrand      plugs: [ wayland ]12:13
jdstrandgreyback: I think that aligns with how you described how xwayland works12:14
mvo_Chipaca: and another ppc failure: https://paste.ubuntu.com/26410328/ - this time in boltdb12:14
greybackjdstrand: yes that makes sense12:14
greybackI'll give that a go12:15
greybackjdstrand: thanks for the advice12:15
jdstrandgreyback: *today* a full on Xorg xserver wouldn't be able to run with the slot policy you right for x11, but that is ok. if that ever comes up, we can adjust the policy. this way you can focus just on the xwayland bits12:15
mupPR snapd#4505 opened: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>12:15
jdstrand(what an ugly typo)12:16
zyga-ubuntuChipaca: ^ early PR for layouts,12:16
zyga-ubuntumvo_: ^12:16
greybackjdstrand: heh, silly english with homonyms12:16
zyga-ubuntusmall, just for quick feedback on the idea12:17
jdstrandgreyback: for your testing, perhaps just tuck the shm access into the PermamentSlotAppArmor bit of x11 and add a TODO comment to investigate. before we merge, you investigate. it might be that we adjust mirConnectedPlugAppArmor to have the shm access and xwayland to plugs: [ wayland, mir ] since *this* wayland client happens to need it cause of some mir thing12:19
jdstrandobviously depending on your investigation12:19
greybackjdstrand: *nod*12:19
greybackthat's a plan12:19
jdstrandgreyback: ok, sorry for the lagginess on this. I'll be back from sprinting next week12:19
greybackjdstrand: not at all, thank you for the help12:20
mupPR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506>12:51
zyga-ubuntuChipaca: sorry to bug you but could you please (perhaps) split that PR into distinct commits that can be reviwed earliy12:55
zyga-ubuntuChipaca: maybe one for typo, one for mv, more for extra features12:56
zyga-ubuntuotherwise that's a 1K diff12:56
Chipacazyga-ubuntu: I can. Most of the diff is the move from snapstate to snap, i guess12:56
Chipacalemme close that12:56
Chipacabefore it chomps up a travis12:56
zyga-ubuntuoh drat, standup12:57
zyga-ubuntu... quick coffeee12:57
mupPR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4506>12:58
Chipacazyga-ubuntu: there you go13:01
mupPR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506>13:02
mupPR snapd#4499 closed: packaging/14.04: move linux-generic-lts-xenial to recommends <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4499>13:06
mborzeckicachio: do you the version of fedora kernel used on linode?13:16
* kalikiana time for lunch13:32
zyga-ubuntuwoot, one branch merged :)13:34
mupPR snapd#4472 closed: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4472>13:35
zyga-ubuntupstolowski: about 4358, how to approach it?13:35
zyga-ubuntupstolowski: any advice on how to review it?13:35
tyhickszyga-ubuntu: hey - I never saw if you got the apparmor label query issue straightened out?13:40
zyga-ubuntutyhicks: yes and no13:41
zyga-ubuntutyhicks: I drowned in dbus, iteration is a pain13:41
zyga-ubuntutyhicks: but mvo added a label that jdstrand suggested that fixed the problem13:42
zyga-ubuntutyhicks: (labeling the snap userd service as unconfined)13:42
tyhickszyga-ubuntu: do I need to fix a bug caused by that upstream change?13:42
zyga-ubuntutyhicks: it looks like the bug is real but it's not a pressing issue for us now13:42
zyga-ubuntutyhicks: I think so, it will affect other things13:42
zyga-ubuntu(not just snapd)13:42
tyhickszyga-ubuntu: what's a simple reproducer? attempt to query a label of a peer connection in bionic?13:43
zyga-ubuntutyhicks: on bionic, revert mvo's change (I'll give you a link in a moment), install gimp (probably works with other snaps but this works for sure); snap run --shell gimp; xdg-open http://example.org13:44
zyga-ubuntutyhicks: the logs indicate that there's no peer label information and thus the rule for peer=unconfined doesn't apply and the activation is denied13:44
pstolowskizyga-ubuntu, it would probably make sense to start by getting the understanding of the associated spread test and its 2 test snaps and their hooks13:44
zyga-ubuntutyhicks: it's *just* activation that is broken13:44
zyga-ubuntutyhicks: once activated it works correctly13:45
zyga-ubuntupstolowski: thank you, let's see13:45
zyga-ubuntutyhicks: I attached logs on the forum if you need those13:46
zyga-ubuntu(and some advice on how to collect them)13:46
zyga-ubuntutyhicks: I think activation should happen regardless and not bail out on lack of the label13:46
zyga-ubuntutyhicks: or activation should carry implicit confinement "unconfined"13:47
zyga-ubuntutyhicks: reading the code it seems that activation should fail (by design) only on explicit deny rules13:47
zyga-ubuntutyhicks: that was the intent13:47
zyga-ubuntutyhicks: but this is not how it behaves13:47
pstolowskizyga-ubuntu, then repo.go and doConnect handler. policy and connection.go changes last13:48
tyhickszyga-ubuntu: thanks - that helps a lot to understand the problem13:51
tyhickszyga-ubuntu: I have some ideas about how to do this correctly13:51
zyga-ubuntutyhicks: the branch to revert, once it lands, is https://github.com/snapcore/snapd/pull/449513:54
mupPR #4495: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495>13:54
jdstrandtyhicks: bug #174268713:55
mupBug #1742687: Launching URLs in snapped applications no longer works in 18.04 <AppArmor:Invalid> <D-Bus:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687>13:55
seb128jdstrand, zyga-ubuntu, is there really a bug there? to be it looks like that dbus/apparmor enforces more checking that it used to and that the autoactivated services that AssumedAppArmorLabel info by design14:05
* zyga-ubuntu lunch14:06
zyga-ubuntuseb128: yes, I think so14:06
zyga-ubuntuseb128: reading the code and patch descriptions seems to imply it should not behave this way14:06
zyga-ubuntuseb128: I'll defer to tyhicks's decision14:06
seb128zyga-ubuntu, you should report it upstream, they might just fix it for us14:07
zyga-ubuntuseb128: yeah, I can do that, good idea14:08
seb128zyga-ubuntu, thanks14:10
zyga-ubuntuok, let's review things14:31
zyga-ubuntuthen let's file that bug14:31
zyga-ubuntuand then, let's ... not sure yet :)14:31
zyga-ubuntumborzecki: https://github.com/snapcore/snapd/pull/450514:31
mupPR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>14:31
zyga-ubuntumborzecki: would the group / user thing be a problem on arch?14:31
mborzeckizyga-ubuntu: there's a 'nobody' group around here only14:33
mborzeckizyga-ubuntu: the uids in tests are hardcoded too14:37
mborzeckizyga-ubuntu: maybe it would be best to guess nobody/nogroup the same way we deal with directories14:39
mborzeckizyga-ubuntu: li.Group is coming from the snap right?14:40
zyga-ubuntumborzecki: hymm14:41
zyga-ubuntumborzecki: yes14:42
zyga-ubuntumborzecki: I think that I need to tweak that to contain a fixed mapping14:42
zyga-ubuntumborzecki: this mapping must make sense on the inside, not for classic host14:42
zyga-ubuntumborzecki: and we only support 'root' and 'nobody'14:42
zyga-ubuntuChipaca: did you see 4506 failures?14:56
Chipacazyga-ubuntu: i saw your comment14:56
Chipacai'll dig in a bit14:56
Chipaca(that pr is a backburner one)14:57
jdstrandseb128 (cc zyga-ubuntu and tyhicks): tyhicks and I talked about it. it is fine that dbus is offering more mediation, but the way it is doing it is a bit weird. tyhicks will comment in the bug14:57
seb128jdstrand, thanks14:58
* kalikiana really, really hates regex today15:24
* kalikiana getting more tea15:24
zyga-ubuntukalikiana: regex is your friend, imagine if you had to do it by hand15:31
zyga-ubuntukalikiana: btw, do you knof about regex derivatives?15:32
zyga-ubuntukalikiana: I found that interesting a while back15:32
zyga-ubuntukalikiana: https://en.wikipedia.org/wiki/Brzozowski_derivative15:32
mvo_Chipaca: looks like we need https://paste.ubuntu.com/26411304/ in upstream bolt (funny enough this seems to be not fixed in the coreos fork either - ppc seems to be not super popular)15:36
zyga-ubuntumvo_: before it blows up, can we check if this builds on other fringe arches?15:36
mvo_zyga-ubuntu: which one do you have in mind?15:38
zyga-ubuntumvo_: s390 and all the other ones nobody has but will block us in next package build in the archive15:41
Chipacaooh, just got a very helpful email, trying to sell me email listings of redhat users15:46
kalikianazyga-ubuntu: hmmm I did not know that! will have to read up on it15:47
* Chipaca considers forwarding it to info@centos.org :-p15:47
zyga-ubuntukalikiana: it's not useful very often as it's not something implemented in any standard library I know15:50
zyga-ubuntukalikiana: but since I love that topic, I wanted to share it :)15:50
zyga-ubuntuChipaca: how much?15:50
kalikianazyga-ubuntu: usually I adore the concept as well, just not today when I'm fighting with a tricky case :-P15:51
zyga-ubuntukalikiana: what is the case? I will be your garden dwarf friend15:51
zyga-ubuntukalikiana: explain the problem to me15:52
cachioniemeyer, when you have some time, could you please take a look to https://github.com/snapcore/spread/pull/4915:54
mupPR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>15:54
kyrofakalikiana, I also find rubular.com to be helpful15:55
zyga-ubuntupstolowski: some early feedback on 435815:55
Chipacazyga-ubuntu: no idea15:55
zyga-ubuntupstolowski: marked as requeste changes because I'm still going through it and I have more questions pending15:55
zyga-ubuntupstolowski: sorry about that but if you follow the diff from the end and go up the order of my questions will be more logical15:56
* zyga-ubuntu reads diffs from the other end usually15:56
pstolowskizyga-ubuntu, ty!15:56
zyga-ubuntucan I ask for firmer vote on https://github.com/snapcore/snapd/pull/450215:57
mupPR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>15:57
zyga-ubuntupstolowski: sorry for the needs fixing, I don't see anything strongly broken, just want to understand it15:57
zyga-ubuntupstolowski: what's the idea with the new interface btw? are we adding a new interface designed for testing?15:57
pstolowskizyga-ubuntu, sure, no worries15:57
Chipacahere's an initeresting test to do: set up a long loop that installs and removes the same snap. compare how long it takes to install the 2nd time, vs the Nth time.15:58
zyga-ubuntuChipaca: what's the result you got?15:58
pstolowskizyga-ubuntu, yes, this is something I brought up on the standup (limited testatibility with existing ifaces) and Gustavo suggested to created a new interface just for testing15:58
kalikianazyga-ubuntu, kyrofa: I'm staring at this `\A(on)\s+([^,\s](?:,?[^,\s]+)*)(\s(to)\s+([^,\s](?:,?\S+)*)|)\Z` which rejects "on i386, ubuntu to armhf" as invalid. due to the extra space after the comma. Except we *want* to parse it so we can show a special error. Now if I remove the change the two `[^,\s]` to `[^,]` it parses but the groups are merged in one15:58
Chipacaon this machine, subjectively (because i didn't start out to measure this) it looks like as changes hit 10k, things get a lot slower15:58
zyga-ubuntupstolowski: should it be in a different file name?15:58
zyga-ubuntupstolowski: er, should the file have a different name15:58
* kalikiana finds https://regex101.com/ quite nice but sadly it can't extrapolate the intended use case15:59
zyga-ubuntupstolowski: test_... go is not usually built, rightt?15:59
ChipacaI don't think I'll have time to run that test today, but i might tomorrow :-)15:59
zyga-ubuntukalikiana: looking15:59
pstolowskizyga-ubuntu, i'm open to renaming it. I if the only expectation is about display name, it should clearly indicate it's not an interface for normal use15:59
pstolowskid/I if/16:00
zyga-ubuntupstolowski: yes, i would add some provisions for hiding it (though not needed now)16:00
zyga-ubuntukalikiana: man, that could use the mode that enables whitespace and comments16:01
zyga-ubuntukalikiana: did you think about using a lexer and parser to make things like that easier to follow?16:01
zyga-ubuntukalikiana: can you please remind me what \A and \Z does in the engine you are working with (I presume python)16:02
Chipacazyga-ubuntu: start and end of string16:03
kalikianazyga-ubuntu: start and end of the string16:03
kalikianaand yes, it's Python16:03
zyga-ubuntukalikiana: are those different from ^ and $?16:04
Chipacazyga-ubuntu: the m modifier changes ^ and $ to start of lines inside the string, so you need a bigger anchor16:04
zyga-ubuntuI see16:04
Chipacaor was it the s modifier16:04
Chipacaone of 'em two16:04
zyga-ubuntuI think it's 'm'16:04
zyga-ubuntukalikiana: ok and the (?: ) syntax, what does that introduce?16:04
kalikianazyga-ubuntu: it ignores the group in the results16:05
zyga-ubuntukalikiana: that's dangerous perhaps16:05
zyga-ubuntukalikiana: it can cause states to be combined in the resulting DFA16:05
zyga-ubuntuI'm not sure how much nfa->dfa action happens in python tho16:05
* zyga-ubuntu experiments 16:05
Chipacazyga-ubuntu: it's like () but without capture16:05
Chipacazyga-ubuntu: which is nice, because (foo)+ is weird16:06
zyga-ubuntuperfect, thank you16:06
zyga-ubuntukalikiana: and what would you like this to match, in geral16:11
zyga-ubuntukalikiana: do you have a spec of what is valid (in english)16:11
zyga-ubuntukalikiana: I'll be back, I need to walk outside for an hour, see you later (just write the spec please)16:14
kalikianazyga-ubuntu: enjoy!16:15
Chipacamvo_: I subscribed you to #1744113 because I thought you might have something to add to the discussion16:16
mupBug #1744113: should the /names endpoint include kernels, gadgets, cores? <Snap Store:New> <https://launchpad.net/bugs/1744113>16:16
kalikianakyrofa: if you wanna have a look wrt the refactor, to re-uses on now in snapcraft#1800 - aside from my fighting with the regex the code works16:19
mupPR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>16:19
Chipacamvo_: dear IT worker, Good work.16:22
Chipacamvo_: that doesn't happen often! :-)16:22
mupPR snapd#4336 closed: spread.yaml: add fedora 27 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>16:22
kalikianakyrofa: I've found an interesting problem btw. having both `to armhf` and `on i386 to armhf` will be counted as duplicates. I'm not sure how to address that... the refactoring is turning out to be a little less straightforward16:23
kyrofakalikiana, well they kind of are, aren't they?16:24
kyrofaIt's possible for them both to match16:25
kyrofaelopio, what's on your docket for today? Looks like I owe you a few reviews16:28
elopiokyrofa: I want to finish collecting all the existing translations for the repo, and start the docs that Sergio requested.16:30
elopiokyrofa: I am on vacations tomorrow, so it would be nice to finish the PRs today too.16:30
kalikianakyrofa: I found myself trying out `on amd64 to amd64` because why not, and that's an error. Which is probably fine since it's somewhat pointless. But separate `on amd64` statements probably do make sense in some cases.16:31
cachiozyga-ubuntu, please take a look to #4351 when you have a time16:33
mupPR #4351: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4351>16:33
blackboxswgood day folks, I'm looking at creating a snapd/seed  directory for curtin & cloud-init  and wanted to chat about what I might be missing. Is it preferable for me to start a forum post for that?16:34
* kalikiana going to wrap up for today in a bit16:40
kyrofakalikiana, curious to hear what cases16:41
kyrofaI can't think of any cases where they couldn't be merged16:42
kyrofaHahaha snapcraft#1877 is hilarious16:44
mupPR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>16:44
kyrofaEasiest review ever, close my eyes and +116:44
kyrofaelopio, any chance you made sure autopkgtests ran correctly as well (since those are effected by this as well)?16:45
kalikianakyrofa: Yeah. Arguably it's totally okay to fail like that. I just wanted to be sure to bring it up. Could still add that later in any case.16:47
blackboxswalso quick question on snap auto-import. Is this command line utility which is actually searching for /var/lib/snapd/seed ?16:48
kyrofakalikiana, yeah it's part of the initial yaml spec, which may not grow quite as well as we would hope16:48
kyrofaNot yaml spec, sorry, grammar spec16:48
elopiokyrofa: we can get the bot to do that16:48
kyrofaelopio, oh wait, amd64 is back huh?16:48
kyrofaelopio, I've just been assuming everything was still down16:49
elopiosnappy-m-o autopkgtest 1877 xenial:amd6416:49
snappy-m-oComputer says nooo. See logs for details:16:49
snappy-m-o Command '['/tmp/tmp02uqh_h1/retry_autopkgtest.sh', '1877', 'xenial:amd64']' returned non-zero exit status 116:49
mvo_Chipaca: sure, looking16:52
mvo_Chipaca: re dear it works> where did you see that?16:53
Chipacamvo_: #174307916:53
mupBug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>16:53
kyrofaelopio, I assume you have access to those logs?16:54
elopiokyrofa: yes, checking.16:55
elopioIt would be more useful if the bot made a summary of the exception, instead of just exit 116:55
mvo_Chipaca: haha - right16:59
mvo_Chipaca: I guess I will make this my new job title "IT worker"17:00
* Chipaca bbiab17:02
mupPR snapcraft#1874 closed: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1874>17:03
elopiokyrofa: it's replying with a 500, so not yet.17:03
elopioI'll give them a try here.17:04
kyrofaUh oh17:04
cjwatsonkyrofa: Surprising that GH doesn't handle that.  I fixed that kind of thing in LP a while back AFAIK (https://bugs.launchpad.net/turnip/+bug/1712754)17:21
mupBug #1712754: git diffs do not track renames <canonical-is> <turnip:Fix Released by cjwatson> <https://launchpad.net/bugs/1712754>17:21
zyga-ubuntuback now17:22
zyga-ubuntucachio: approved17:24
cachiozyga-ubuntu, tx17:24
blackboxsw   17:38
zyga-ubuntuso now that we have slack17:38
zyga-ubuntuis there a slack for snappy?17:38
mupPR snapd#4507 opened: advisor: use forked bolt to make it work on ppc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4507>17:53
kyrofaelopio, I really only have one issue with snapcraft#187917:55
mupPR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>17:55
lotuspsychjegood evening to all18:15
lotuspsychjei have a wish for a snap command, whats the prefered way to do this? bug/wishlist?18:16
zyga-ubuntulotuspsychje: try opening a forum topic on forum.snapcraft.io18:16
lotuspsychjezyga-ubuntu: ok thank you18:16
zyga-ubuntulotuspsychje: pleasure :)18:17
lotuspsychjezyga-ubuntu: https://forum.snapcraft.io/t/req-snap-list-command-to-see-latest-added-snaps/358118:26
zyga-ubuntulotuspsychje: nice! I commented alreay18:28
lotuspsychjezyga-ubuntu: nice thank you!18:29
lotuspsychjezyga-ubuntu: sudo snap find lists a few  but not all right18:37
zyga-ubuntulotuspsychje: yes, those are "curated snaps" (not really curated much ATM)18:37
zyga-ubuntulotuspsychje: but a feed of recently added or refreshed snaps would be interesting18:37
lotuspsychjezyga-ubuntu: atm i always have to go to the store website and filter recently added18:39
mvo_Chipaca: my bbolt (coreos fork) PR for fixing ppc got merged within 30min, that is quite impressive18:42
Chipacamvo_: niice19:05
Chipacamvo_: tag me on the pr, i'll look at it later tonight19:05
Chipacabye for now19:05
Chipacamvo_: i mean on the pr to move to the fork, if there is one :-)19:05
smisohi: Any one who any ideeas how to persistent add ip forwarding to ubuntu core?19:29
zyga-ubuntusmiso: hey19:30
zyga-ubuntusmiso: you can implement that in a snap that uses the network-control interface19:30
zyga-ubuntulet me check19:30
zyga-ubuntusmiso: you may need either or both network-control and firewall-control19:31
zyga-ubuntuand then you should be able to set that up yourself (in your snap)19:31
zyga-ubuntuI don't think we offer any default way to manage that today19:31
zyga-ubuntuonly as interfaces to snap applications19:31
cachiozyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/19:53
cachiozyga-ubuntu, this is executed with the interface connected https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind19:58
=== epod is now known as luk3yx
blackboxswhrm. snap known --remote model series=16 model=generic-classic brand-id=generic returns an ill-formed yaml file for sign-key-sha3-384 value the multi-line value doesn't use22:46
blackboxswnevermind.... not supposed to be yaml22:47

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!