[06:46] <zyga-suse> good morning
[06:47] <mvo> hey zyga-suse, good morning
[06:47] <zyga-suse> mvo: hey,
[06:48] <zyga-suse> mvo: did you see https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446/9 ?
[06:52] <zyga-suse> mvo: I thought this is another instance of the rrexec bug from last week but I'm not so sure anymore
[06:53] <zyga-suse> I found it interesting that half of snapd reexecuted
[06:53] <zyga-suse> but the rest did not
[06:58] <zyga-ubuntu> mvo: I'll grab some food and I'll be back soon to do code reviews
[06:58] <mvo> zyga-ubuntu: yeah, will do the same
[06:59] <mvo> zyga-ubuntu: interessting bug :/
[07:14] <mup> PR snapd#3614 closed: daemon, client, cmd/snap: implement "snap services" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3614>
[07:24] <zyga-suse> mvo: last night gustavo asked everyone to upgrade spread
[07:29] <zyga-ubuntu> I wrote a test simulating 2.0.2 and re-execing snapd, let's see how it works
[07:34]  * zyga-suse wonders what the movie crew outside is doing?
[07:36] <zyga-suse> I need a 2nd review for 3619
[07:38] <zyga-suse> they are shooting a TV show outside now
[07:38]  * zyga-suse wonders what's going on
[07:39] <pedronis> zyga-suse: why each of this check that the interface match?  shouldn't this be done before/somewhere in the caller?  is there a case where that shouldn't hold?
[07:39] <zyga-suse> pedronis: I think we never call this incorrectly but this is part of the code that was written veeery long time ago
[07:39] <zyga-suse> pedronis: and I think we just kept the cross-checking semantics
[07:40] <zyga-suse> pedronis: I wasn't trying to change it, just improve how it is done
[07:40] <pedronis> well, given we are cleaning up, I question why not clean up even more
[07:40] <pedronis> notice that pawel will have to touch these again btw
[07:40] <pedronis> new names, new signatures
[07:40] <zyga-suse> aha, indeed
[07:41] <zyga-suse> well, I can yank the sanitize calls if you feel strongly about them
[07:41] <zyga-suse> in theory this ensures that we are not, by mistake, allowing sanitize to pass with a wrong interface
[07:41] <pedronis> I don't feel strongly but you are asking to check you put everywhere something, where that probably means it's done in the wrong place
[07:44] <zyga-suse> I think it's more of a security paranoia at play; I just checked how we call Sanitize and we always call it with a matching interface that is looked up from the Interface field
[07:44] <zyga-suse> so again, I can remove it as there seems to be no harm done
[07:45] <pedronis> well, you can define helpers on repo
[07:45] <pedronis> sanitizePlug  and sanizeSlot
[07:45] <pedronis> that would do the check
[07:45] <pedronis> if you feel the paranoia is worth
[07:46] <pedronis> it's a bit strange to ask everybody writing an interface to help taking of this paranoia
[07:46] <zyga-suse> they are taking another shot of the same scene
[07:46] <zyga-suse> indeed
[07:46] <pedronis> this things are called in 4 places at all
[07:46] <zyga-suse> though I think we had those helpers and they were nacked before (they checked for any panics as well)
[07:46] <pedronis> I think Gustavo was gainst the catching panics
[07:47] <pedronis> not the helpers
[07:47] <zyga-suse> I think you are right
[07:47] <zyga-suse> let me put private helpers in the repo and drop the checks in each interface then
[07:49] <pedronis> you could even have private helpers sanitize on Slot and Plug themselves
[07:49] <zyga-suse> hmm, interesting
[07:49] <zyga-suse> let me experiment
[07:50] <zyga-suse> (and another shot)
[07:52] <pedronis> mmh
[07:52] <pedronis> sorry
[07:52] <zyga-suse> about what?
[07:53] <pedronis> nothing was thinking something
[08:18] <zyga-suse> mvo: ha
[08:18] <zyga-suse> mvo: so weird
[08:18] <zyga-suse> mvo: if I start with 2.0.2
[08:18] <zyga-suse> mvo: there's no core transition yet
[08:18] <zyga-suse> so.... we're on 2.0.2 forever
[08:18] <zyga-suse> (and ever and ever)
[08:18] <zyga-suse> it seems
[08:19] <zyga-suse> not sure if we can even do anything about it
[08:20] <mvo> zyga-suse: does 2.0.2 do re-exec?
[08:24] <zyga-suse> nope
[08:24] <zyga-suse> I don't see any traces of that
[08:24] <mvo> zyga-suse: then there is really nothing we can do :/
[08:24] <mup> PR snapd#3615 closed: add broadcom-asic-control interface <Created by knitzsche> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3615>
[08:24] <zyga-suse> I think we only managed to do it for a later version that was also in debian stable
[08:25] <zyga-suse> mvo: yep, I just found this very unfortunate as this is the version the reporter of that bug was using
[08:25] <mvo> zyga-suse: I mean, without re-exec its irrelevant if it fetches core or ubuntu-core. in general if things re-exec it will work even if ubuntu-core is used. then it will fetch ubuntu-core re-exec into that snapd and that snapd will transition to core
[08:26] <mvo> zyga-suse: version 2.21 is doing re-exec but we had a experimental re-exec in some earlier versions that got disabled again. iirc 2.0.10 is also re-execing
[08:26] <mvo> zyga-suse: unfortunate> totally :/
[08:26] <zyga-suse> mvo: one idea, unpublish ubuntu-core
[08:26] <zyga-suse> or even tweak the store to say something like "update your snapd package"
[08:26] <zyga-suse> as an error message, if one can be shoved to 2.0.2
[08:28] <mvo> zyga-suse: if people start from a version that fetches ubuntu-core, thats fine, things will work.
[08:28] <zyga-suse> do we know which version is requesting the snap?
[08:28] <mvo> zyga-suse: I mean, the problem with 2.0.2 is that it is not doing re-exec at all. or am I missing something?
[08:28] <zyga-suse> maybe we could reject ubuntu-core on 2.0.2 installs
[08:28] <zyga-suse> mvo: yes, that's the problem
[08:28] <zyga-suse> and somehow people keep having it because it's on the ISO
[08:31] <mvo> zyga-suse: aha, I see. well, ideally the store would reply to every request from 2.0.2 with "please upgrade your snapd". so +1 for this proposal, we just need to check if the error message is visiable to the end-user
[08:31] <zyga-suse> now we just need to check with store people to see if we can craft this
[08:36] <zyga-ubu1tu> Chipaca: o/
[08:36] <Chipaca> zyga-ubuntu: \o
[08:38] <mvo> zyga-ubuntu: does 3591 look good to you?
[08:38] <mvo> zyga-ubuntu: you did a review before and jamie addressed things afaict
[08:38] <mvo> hey Chipaca
[08:38] <Chipaca> mvo: how's things with you?
[08:39] <zyga-suse> mvo: just a sec
[08:39] <zyga-ubuntu> mvo: I wrote a forum topic on the 2.0.2 problem https://forum.snapcraft.io/t/snapd-2-0-2-doesnt-reexecute-pulls-in-ubuntu-core-stays-stale/1455
[08:40] <zyga-ubuntu> mvo: yep, +1
[08:40] <mvo> Chipaca: doing well, finally doing reviews :)
[08:40] <mvo> Chipaca: and you?
[08:40] <Chipaca> mvo: no longer working on 'snap status'!
[08:40] <zyga-ubuntu> Chipaca: congrats on merging your PR
[08:41]  * Chipaca dances
[08:41] <Chipaca> of course, the next one is 'snap logs', so... :-)
[08:41] <Chipaca> ¯\_(ツ)_/¯
[08:41] <zyga-ubuntu> Chipaca: just put an easter egg when you run "snap logs everything"
[08:41] <mup> PR snapd#3591 closed: interfaces/greengrass-support: adjust accesses now that have working snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3591>
[08:41] <zyga-ubuntu> could be an ester egg theme
[08:42] <Chipaca> zyga-ubuntu: I couldn't possibly comment
[08:47] <mvo> Chipaca: yay!
[09:50] <ppisati> ogra_: since when we required the dtb to be part of the kernel snap? wasn't it supposed to be part of the gadget snap?
[10:07] <zyga-suse> ppisati: it was discussed in london, the idea is that it is tied to the kernel snap as the kernel may or may not boot depending on the dbt that is used
[10:07] <zyga-suse> ppisati: (in the pi specific case)
[10:07] <ppisati> zyga-suse: ok
[10:11] <zyga-suse> ppisati: https://forum.snapcraft.io/t/development-sprint-june-26th-2017/415/46?u=zyga
[10:35] <ogra_> ppisati, it is only part of the gadget for pi ... all other boards use it from the kernel snap
[10:36] <ogra_> ppisati, and what we discussed in london was to move for the pi to the same model and additionally include the binary blobs in the kernel snap
[10:37] <ogra_> ppisati, essentially everything that is version wise bound together will go into the kernel snap on pi ... making us lose any kind of rollback for the kernel though
[10:40] <ppisati> ogra_: ack
[11:26] <zyga-ubuntu> changing anything about interfaces in genral is a chore
[11:26] <morphis> mvo, zyga-ubuntu: do you guys have time to look at https://github.com/snapcore/snapd/pull/3260 ?
[11:26] <mup> PR snapd#3260: cmd/snap: implement userd command as replacement for snapd-xdg-open <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
[11:27] <zyga-ubuntu> morphis: not at present
[11:27] <morphis> hm
[11:27] <zyga-ubuntu> I'm wrapping up stuff to switch to packaging and layouts
[11:27] <zyga-ubuntu> maybe after packaging
[11:32] <flexiondotorg> Trevinho Afternoon. What is the current status of your Telegram snap?
[11:32] <Trevinho> flexiondotorg: hey
[11:32] <Trevinho> flexiondotorg: I've replied to an email from popey some weeks ago about it..
[11:32] <flexiondotorg> Can you forward that to me please?
[11:33] <Trevinho> flexiondotorg: basically, it needs work... Which I might do to finish if there's interest and we can have proper upstream contacts
[11:33] <Trevinho> flexiondotorg: sure I can
[11:33] <flexiondotorg> Thanks.
[11:33] <flexiondotorg> Does the email outline what work is required?
[11:34]  * zyga-ubuntu uses telegram snap all the time, would love to see upstream adopt it
[11:38]  * ogra_ uses sergios telegram snap ... 
[11:40] <ogra_> i didnt even know Trevinho has one as well !
[11:40] <Trevinho> ogra_: mine is basde on sources
[11:40] <Trevinho> ogra_: but I didn't publish on store
[11:40] <Trevinho> ogra_: or well not public
[11:40] <ogra_> ah
[11:40] <Trevinho> I wanted to get snapcraft to do the cool job of compilinng all the ellemtns and such
[11:40] <Trevinho> as they do upstream..
[11:41] <Trevinho> ogra_: there is an email I sent to canonical-snapcraft ML
[11:42] <ogra_> ages ago ... i remember that
[11:42] <Trevinho> flexiondotorg: sent
[11:42] <flexiondotorg> ty
[11:44] <Chipaca> Trevinho: flexiondotorg: what's the relation between your telegram snap and sergiusen's?
[11:45] <Trevinho> Chipaca: none..
[11:45] <Trevinho> Chipaca: sergio's one takes the upstream built telegram and ships it
[11:45] <Trevinho> mine takes upstream code, and builds it as telegram does
[11:46] <Trevinho> it doesn't sign the binary of course, as it's something they only can do
[11:54] <zyga-ubuntu> pedronis: 3619 updated
[12:02] <pedronis> zyga-ubuntu: did you change anything in core/repo ?
[12:03] <zyga-ubuntu> pedronis: I'm adding {plug,slot}.Sanitize
[12:03] <zyga-ubuntu> and making Sanitize{Plug,Slot} optional :D
[12:03] <pedronis> in the branch ?
[12:03] <zyga-ubuntu> yep
[12:04] <pedronis> but not yet?
[12:04] <zyga-ubuntu> I just pushed the initial huge patch in case I missed something there
[12:04] <zyga-ubuntu> in a moment
[12:56] <pedronis> cachio: hi, I'm getting this unrelated errors on this branch, quite regularly:  https://travis-ci.org/snapcore/snapd/builds/257198925?utm_source=github_status&utm_medium=notification  do I need to merge branch or they new problems
[12:56] <cachio> pedronis, taking a look
[12:57] <pedronis> merge trunk
[13:02] <magicaltrout> hello folks
[13:02] <magicaltrout> random snap creation question
[13:02] <magicaltrout> if I use the maven plugin to build some archive
[13:02] <magicaltrout> can i then use something to extract the finished tarball?
[13:07] <magicaltrout> or use the dump plugin to extract stuff from a previous part?
[13:08] <ogra_> snapcraft keeps every by-product around after build ... so yes, if there is a tarball created, you will find it somewhere in your build directory
[13:08] <ogra_> btw, http://rocket.ubuntu.com is probably the better place for snapcraft questions
[13:09] <ogra_> (there is a #snapcraft channel)
[13:09] <magicaltrout> aww but that involves more browser tabs
[13:09] <ogra_> snap install rocketchat-desktop
[13:09] <ogra_> ;)
[13:09] <ogra_> no tabs needed
[13:21] <mup> PR snapcraft#1403 closed: lxd: Only remove container if one exists <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1403>
[13:24] <ogra_> morphis, hey
[13:25] <morphis> ogra_: hey
[13:25] <ogra_> morphis, could i bribe you for a second ack on https://github.com/snapcore/pi3-gadget/pull/11 (already tested and ondra reviewed and approved it already)
[13:25] <mup> PR pi3-gadget#11: build uboot from source, pull blobs from upstream, use dtbs from archive <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/11>
[13:26] <morphis> ogra_: sure
[13:26] <morphis> will have a look in a bit
[13:26]  * ogra_ hugs morphis 
[13:26] <morphis> :-)
[13:26] <zyga-ubuntu> fg
[13:26] <zyga-ubuntu> bg
[13:26] <zyga-ubuntu> ah
[13:26] <zyga-ubuntu> darn )
[13:27] <ogra_> pick the middle ground ... thats the best compromise
[13:35] <fgimenez> cachio: you can point the suite to staging with "export SPREAD_REMOTE_STORE=staging" before executing
[13:36] <cachio> fgimenez, ok, thanks
[13:41] <fgimenez> cachio: np, this is the forum post with the beta validation details https://forum.snapcraft.io/t/core-snap-validation-process-at-beta-channel/1454
[13:42] <cachio> fgimenez, great!!!
[13:47] <fgimenez> zyga-ubuntu: this is the error in the orangepi using the latest core from edge https://forum.snapcraft.io/t/how-to-use-spread-to-test-ubuntucore-image/1323/44?u=fgimenez
[13:49] <fgimenez> zyga-ubuntu: if you could take a look that would be great, it seems to pass with core from beta
[13:49] <zyga-suse> ack
[13:49] <zyga-suse> I'll check it out after lunch
[13:55] <fgimenez> zyga-suse: great, thanks!
[14:21] <zyga-suse> mvo: did you push that parser branch by any chance?
[14:22] <zyga-ubuntu> mvo: we hit the hook issue again
[14:22] <zyga-ubuntu> - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install")
[14:22] <zyga-ubuntu>  :/
[14:24] <pedronis> zyga-ubuntu: is that on a revert?
[14:24] <zyga-ubuntu> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170727_125232_a75a6@/log.gz
[14:24] <zyga-ubuntu> upgrade/basic
[14:27] <mvo> zyga-ubuntu: meh, how annoying
[14:29] <zyga-suse> feels like a blocker to me
[14:29] <zyga-suse> we need to understand what is going on
[14:30] <fgimenez> it happened on amd64 this time, yesterday it was i386
[14:30] <zyga-ubuntu> I think it is random
[14:30] <zyga-ubuntu> something is racing there
[14:35] <ogra_> hmm
[14:35] <ogra_> ogra@styx:~/tmp$ snap run --shell hello-world
[14:35] <ogra_> To run a command as administrator (user "root"), use "sudo <command>".
[14:35] <ogra_> See "man sudo_root" for details.
[14:35] <ogra_> why do i get that sudo hint ?
[14:38] <Chipaca> of course the only path I didn't unit test has a off-by-one panic
[14:38] <zyga-suse> huh, interesting
[14:38]  * Chipaca hugs everything
[14:39] <zyga-suse> is that done by profilerc perhaps?
[14:39] <zyga-suse> hehe
[15:03] <Slashman> hello, I'm stuck on debian 9 after "snap install lx" with "[/] Run configure hook of "core" snap if present", any idea how I can solve this?
[15:04] <zyga-suse> Slashman: hey
[15:04] <zyga-suse> hmm
[15:04] <zyga-suse> mvo: ^
[15:04] <zyga-suse> Slashman: I think rebooting will just fix that
[15:04] <zyga-suse> and after that it will work OK
[15:04] <Slashman> zyga-suse: ok, I wanted to avoid that but oh well
[15:05] <zyga-suse> techincally
[15:05] <ogra_> well, it is a bug ...
[15:05] <zyga-suse> try this:
[15:05] <zyga-suse> sudo umount /run/snapd/ns/core.mnt
[15:05] <Slashman> too late, I just rebooted :p
[15:05] <zyga-suse> ah
[15:05] <zyga-suse> :D
[15:05] <zyga-suse> ok
[15:05] <zyga-suse> anyway, rebooting is easier to explain
[15:05] <zyga-suse> ogra_: yes, but a pretty obscure one
[15:06] <zyga-suse> it's not obvious what is going on
[15:06] <ogra_> yeah, i just meant to say that it isnt normal that you have to reboot for anything *snap
[15:06] <Slashman> hm, now I have 'error: cannot install "lxd": snap "lxd" has changes in progress'
[15:07] <Slashman> snap list doesn't list lxd
[15:07] <zyga-suse> Slashman: what does snap changes say?
[15:07] <Slashman> "1    Doing   2017-07-27T14:51:42Z  -                     Install "lxd" snap"
[15:07] <zyga-suse> snap change 1
[15:08] <Slashman> https://apaste.info/GmKr
[15:09] <zyga-suse> Slashman: is it stuck there now?
[15:09] <zyga-suse> you can perhaps kill snapctl process (it should be stuck somewhere)
[15:09] <Slashman> how can I know ?
[15:09] <zyga-suse> that will unblock it
[15:09] <zyga-suse> it should finish in a few seconds
[15:09] <zyga-suse> if not it's the bug
[15:10] <Slashman> snapctl is already dead it seems: https://apaste.info/1hOT
[15:11] <Slashman> well I killed it
[15:12] <Slashman> not sure if the error are a real issue: https://apaste.info/rut0
[15:12] <zyga-suse> hmmm
[15:12] <zyga-suse> man
[15:12] <zyga-suse> mvo: ^^
[15:12] <Slashman> https://apaste.info/qrre
[15:13] <zyga-suse> yeah it's gone
[15:13] <zyga-suse> please unmount /run/snapd/ns/core.mnt
[15:13] <zyga-suse> sudo snap install core
[15:13] <zyga-suse> and let's see if that works
[15:13] <zyga-suse> which version of snapd are you on right now? 2.21 something?
[15:13] <mvo> Slashman: what is the output of "snap version"?
[15:13] <Slashman> yeah, the one on debian 9
[15:13] <Slashman> 2.21-2
[15:14] <mvo> Slashman: "snap version" may give different numbers, snapd will try to use bits from the core if it can
[15:14] <Slashman> ok, here is the output: https://apaste.info/Vqic
[15:15] <zyga-suse> ok
[15:15] <zyga-suse> mvo: again
[15:15] <zyga-suse> same case as https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446/9
[15:16] <Slashman> anyway I can make it work?
[15:16] <mvo> zyga-suse: yeah, snapd restarted, configure failed and it reverted to 2.21 but did not restart the new snapd
[15:17] <mvo> Slashman: sudo systemctl restart snapd should bring it back to normal operation. then "snap install core"  - would be interessting to see if that works
[15:17] <ogra_> what a mess :(
[15:17] <mvo> yes, re-exec has a problem we have not found yet on debian
[15:18] <Slashman> seems to work, one strange info message but I see the core snap: https://apaste.info/1z60
[15:18] <Slashman> trying lxd now
[15:18] <ogra_> devmode ?!?
[15:18] <mvo> Slashman: and snap version should how now that you are on 2.26.14 - does it do that?
[15:19] <Slashman> indeed
[15:19] <zyga-suse> ogra_: that's been fixed post 2.21, I think new snapd will correct that
[15:19] <mvo> Slashman: could you try something trivial like snap install hello ?
[15:19] <ogra_> ah, k
[15:19] <Slashman> I just installed the lxd snap
[15:19] <ogra_> irritating though ... :)
[15:19] <mvo> Slashman: even better!
[15:19] <Slashman> mvo: https://apaste.info/olsa
[15:19] <mvo> zyga-suse: I suspect it has something to do with "snap install $thing" without core, i.e. the implicit download of core
[15:19] <zyga-suse> mvo: we need a debian-9 out of the box test ra
[15:20] <zyga-suse> mvo: yes
[15:20] <zyga-suse> mvo: I agree
[15:20] <mvo> Slashman: yes, that looks better :)
[15:20] <zyga-suse> mvo: note that we don't have a debian 9 linode image
[15:20] <mvo> zyga-suse: yeah, I have a debian-9 and couldn't find a way to reproduce the error in there :/
[15:20] <Slashman> so, if I understand correctly, after snap installation, I should: 1) reboot 2) snap install core 3) systemctl restart snap 4) snap install core ?
[15:21] <ogra_> Slashman, normally not ... but yes
[15:21] <zyga-suse> Slashman: I think we don't know yet
[15:21] <ogra_> :P
[15:21] <zyga-suse> Slashman: umounting one special file and restarting snapd is the trick
[15:21] <zyga-suse> but we're hazy on the details
[15:21] <ogra_> Slashman, the normal behaviour is that you snap install lxd and it automagically pulls in core first without you having to do anythinng
[15:22] <Slashman> yeah, I understand that's not the normal behavior :D
[15:23] <Slashman> but until it is fixed, I'll have to document it my team doesn't get stuck trying to install it
[15:24] <Slashman> anyway, thank you for your help guys!
[15:29] <mup> PR snapd#3630 opened: many: implement "snap logs" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3630>
[15:29] <zyga-suse> Slashman: thank you for reporting this, we're sorry for the bad experience
[15:29] <Chipaca> ^ "snap logs" \o/
[15:29] <zyga-ubuntu> Chipaca: nice!!
[15:29] <Chipaca> favourite thing i learned: http.Flusher
[15:30] <Chipaca> (making "snap logs -f" nice an' responsive)
[15:30] <zyga-suse> what is it?
[15:30] <Slashman> zyga-suse: don't worry about it, I'm grateful that snap exists ;)
[15:30] <zyga-suse> flush an ongoing log?
[15:30] <zyga-suse> like tail -f?
[15:31] <zyga-suse> Slashman: thank you! :-)
[15:31] <Chipaca> zyga-suse: http.ResponseWriter can optionally also be an http.Flusher
[15:31] <Chipaca> zyga-suse: if it is, then you can call w.Flush()
[15:31] <Chipaca> and it flushes the writer
[15:31] <Chipaca> the default writers are flushers
[15:31] <Pharaoh_Atem> 😩
[15:32]  * Chipaca hugs Pharaoh_Atem 
[15:32] <Pharaoh_Atem> 😫
[15:32] <Chipaca> Pharaoh_Atem: what's wrong?
[15:32] <Pharaoh_Atem> I was working late last night on a maint window and it went wrong
[15:32] <Chipaca> ouh :-(
[15:32] <zyga-suse> ouch
[15:34] <Pharaoh_Atem> so now I'm really tired today
[15:35]  * Chipaca sends cake
[15:35] <mvo> fgimenez, cachio: 2.27~rc4 for testing is now available in beta
[15:35]  * mvo hugs Pharaoh_Atem
[15:36] <Pharaoh_Atem> zyga-suse: I don't suppose you've fixed 32-bit arches for fedora yet on snap-seccomp>
[15:36] <Pharaoh_Atem> ?
[15:36] <mvo> Chipaca: nice, I learned something new!
[15:37] <Pharaoh_Atem> zyga-suse: it's the same thing that bit us before with snap-confine a long time back
[15:37] <zyga-suse> no, I'm still burried
[15:37] <zyga-suse> sorry :/
[15:43] <Pharaoh_Atem> zyga-suse: could you please fix it before mvo makes 2.27?
[15:43] <Pharaoh_Atem> I'd really rather not have to skip 2.27 :(
[15:44] <mcphail> Is it safe to remove old revisions of the core snap?
[15:44] <zyga-suse> yeah, I think it should be easy
[15:44] <zyga-suse> mvo: when do you want to tag 2.27?
[15:44] <zyga-suse> mcphail: yes
[15:45] <mcphail> zyga-suse: thanks!
[15:45] <Pharaoh_Atem> we should also probably add an i686 fedora test
[15:45] <Pharaoh_Atem> to make sure we don't break this again
[15:46] <zyga-ubuntu> I don't know if we have a compatible i386 image in linode today
[15:46] <zyga-ubuntu> but totally agreed otherwise
[15:53] <zyga-suse> pedronis: pushed with all the stuff I wanted
[15:53] <zyga-suse> oh wow
[15:53] <zyga-suse> github has a new "jump to symbol" feature!
[15:54] <pedronis> sorry chasing something completely different
[15:54] <zyga-suse> pedronis: no worries
[15:54] <zyga-suse> -1449 +618
[15:54] <zyga-suse> my fingers hurt
[15:55] <ogra_> from running rm ?
[15:55] <ogra_> :P
[16:03] <zyga-suse> I think pawel's work will be easier now
[16:03] <zyga-suse> 1722 removed
[16:04] <zyga-suse> only 24 actual non-empty sanitize functions left
[16:07]  * zyga-ubuntu -> coffee 
[16:08]  * genii sips
[16:26] <fgimenez> mvo: \o/ thanks a lot, cachio want to give it a try? :)
[16:27] <cachio> fgimenez, mvo sure, I'll do
[16:28] <cachio> fgimenez, starting now
[16:29] <fgimenez> cachio: great thanks a lot, pls let me know how it goes and if i can be of any help, i think the forum post has all the details, let's see
[16:29] <cachio> fgimenez, I'll follow that
[16:29] <fgimenez> cachio: cool thank you
[16:30] <cachio> fgimenez, yaw
[16:45] <mup> PR snapd#3631 opened: tests: apply underscore convention for SNAPMOUNTDIR variable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3631>
[16:47] <zyga-ubuntu> mvo: do you intend to investigate the debian issue?
[16:47] <zyga-ubuntu> if not I can pick that up
[16:50] <zyga-ubuntu> Chipaca: why don't you write longer commit messages?
[16:52] <cachio> mvo, if you have 1 minute to look at PR 3631
[16:52] <cachio> it is trivial but large
[16:52] <zyga-ubuntu> cachio, mvo: note that I'd like to squash merge it
[16:53] <zyga-ubuntu> there's a lot of junk in the history for a patch like that
[16:53] <cachio> zyga-ubuntu, yes, trying to fix that
[16:53] <cachio> not sure why it is showing the history
[16:53] <zyga-ubuntu> I can explain later, for now it's just a matter of squash merging that
[16:53] <cachio> but most of the commits are already merged
[16:54] <zyga-ubuntu> alternatively you can squash locally and push that over
[16:54] <cachio> zyga-ubuntu, i'll try that
[16:54] <zyga-ubuntu> cachio: git rebase -i origin/master
[16:54] <zyga-ubuntu> squash everything
[16:54] <zyga-ubuntu> and reuse the commit message from the PR (I edited it)
[16:57] <zyga-ubuntu> cachio: also if you do this, please pull
[16:57] <zyga-ubuntu> cachio: I pushed one patch into your branch
[17:06] <zyga-ubuntu> cachio: did you force push?
[17:06] <zyga-ubuntu> cachio: my commit is gone and the whole history is there still
[17:06] <cachio> zyga-ubuntu, I found the problem why it is showing all the commits
[17:06] <cachio> one sec
[17:12] <cachio> zyga-ubuntu, I'll create a new Pr
[17:12] <zyga-ubuntu> cachio: stop
[17:12] <zyga-ubuntu> cachio: why?
[17:12] <zyga-ubuntu> cachio: let me show you how to fix this, ok?
[17:12] <zyga-ubuntu> cachio: do you want to hop on a hangout?
[17:12] <cachio> I had differences between origin/master and upstream/master
[17:12] <zyga-ubuntu> cachio: (why do you think a new PR is needed)
[17:12] <zyga-ubuntu> anyway
[17:12] <cachio> zyga-ubuntu, so I reset my master and then merged
[17:12] <zyga-ubuntu> mmm
[17:13] <zyga-ubuntu> why didn't you do what I said earlier?
[17:13] <zyga-ubuntu> git fetch origin; git rebase -i origin/master; squash everything
[17:13] <zyga-ubuntu> you have one commit then
[17:13] <zyga-ubuntu> you can review it to ensure it's sane
[17:13] <zyga-ubuntu> then push that over this
[17:13] <cachio> zyga-ubuntu, tried, but ti was not fixing the root cause
[17:13] <zyga-ubuntu> in which way?
[17:13] <zyga-ubuntu> can we do that together?
[17:14] <zyga-ubuntu> cachio: I'll join the standup HO
[17:14] <cachio> just a minute, letme try to rebase the branch
[17:31]  * zyga-ubuntu takes a break and will look at the hook issue breaking everything on master now
[17:31] <zyga-ubuntu> I wonder why it doesn't show up in spread linode, just autopkgtest
[17:31] <zyga-ubuntu> mvo: can this be related to autopkgtest talking directly to DC vs the CDN?
[17:31] <zyga-ubuntu> and getting some weird different copy of the core?
[17:50]  * zyga-ubuntu installs debian 9 to explore the bug
[19:38] <cachio> Chipaca, could you please take a quick view to the PR 3631
[19:39] <cachio> Chipaca, I would like to merge it asap  :)
[20:30] <mup> PR snapcraft#1424 opened: Release changelog for 2.33 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1424>
[21:25] <cachio> Chipaca, there?
[22:30] <mup> PR snapcraft#1425 opened: options: properly handle missing compiler prefix <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1425>