[00:17] <mup> PR snapcraft#1558 closed: tests: add fake pip fixture <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>
[06:18] <mup> PR snapd#3947 closed: cmd/snap-repair: fix tests when running as root <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3947>
[06:22]  * zyga-ubuntu has the worst friday possible
[06:22] <zyga-ubuntu> I removed my snapd tree, including all of git history last night
[06:25] <zyga-ubuntu> so plan for today, is to ensure this doesn't happen again
[06:27] <mup> PR snapcraft#1566 opened: recording: record build-snaps installed during the pull <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1566>
[06:28] <zyga-ubuntu> kyrofa: hey
[06:28] <zyga-ubuntu> kyrofa: did you use that pastebin I gave you last night?
[06:35] <cjwatson> daily automated backups of everything - it's the only way
[06:39] <zyga-ubuntu> cjwatson: deja dup backups got corrupted
[06:40] <zyga-ubuntu> cjwatson: I'll use something else as this is not the first time backup was not working, just this time was more damaging
[06:40] <cjwatson> Yeah, I used deja-dup for a little while and then decided it was far too complex
[06:41] <cjwatson> I use rsbackup now which is basically just glorified rsync --link-dest; much less to go wrong
[06:42] <zyga-ubuntu> thank you, I'll check that out
[06:49] <mvo> zyga-ubuntu: could oyu please check 3953?
[06:49] <zyga-ubuntu> mvo: sure
[06:50] <zyga-ubuntu> mvo: why not go all the way and just do this unconditionally?
[06:54] <mvo> zyga-ubuntu: not sure, to minimize risk maybe?
[06:54] <mvo> zyga-ubuntu: I'm fine with all-the-way for 2.29
[06:54] <zyga-ubuntu> mvo: sounds good to me
[06:55] <mvo> thanks
[06:56] <zyga-ubuntu> done
[07:00] <mup> PR snapd#3953 closed: snap-confine: fix base snaps on core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3953>
[07:00] <mvo> thanks zyga-ubuntu
[07:01] <zyga-ubuntu> thank you for doing this :)
[07:04] <mvo> Pharaoh_Atem: is 2.28~rc3 doing ok on fedora or anything needs fixing before 2.28-final?
[07:09] <kalikiana> zyga-ubuntu: backups of git? in my word, that's what you get by pushing ;-)
[07:10] <kalikiana> good morning, snappy world
[07:12]  * kalikiana no more headache for now, just caughing, may the health be with me today
[07:12] <oSoMoN> My latest upload to the store of chromium failed the automated review because the chrome sandbox executable has the setuid bit set, but that used to be allowed previously (not sure if it was an exception for that snap only, or something else). Can anyone from the store/review team help?
[07:12] <oSoMoN> (oh, and good morning everyone, by the way!)
[07:24] <mvo> zyga-ubuntu: http://paste.ubuntu.com/25590963/ <- snapd needs to create that dir in the re-exec case or fail gracefully, right now re-exec with edge is briken
[07:24] <mvo> broken
[07:25] <zyga-ubuntu> mvo: loking
[07:26] <zyga-ubuntu> oh
[07:26] <zyga-ubuntu> good point
[07:26] <zyga-ubuntu> mvo: how did tests not catch that?
[07:26] <zyga-ubuntu> mvo: ah, I think I know
[07:33] <zyga-ubuntu> mvo: ok I have a patch
[07:39] <mup> PR snapd#3955 opened: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <https://github.com/snapcore/snapd/pull/3955>
[07:39] <zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/3955
[07:39] <mup> PR #3955: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <https://github.com/snapcore/snapd/pull/3955>
[08:03] <zyga-ubuntu> Chipaca: can you please look at https://github.com/snapcore/snapd/pull/3955/files
[08:03] <mup> PR #3955: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <https://github.com/snapcore/snapd/pull/3955>
[08:04] <Chipaca> aye aye cap'n
[08:04] <zyga-ubuntu> thank you
[08:04] <zyga-ubuntu> Chipaca: I lost my snapd tree with 2 weeks of code in it
[08:04] <zyga-ubuntu> not a great day
[08:04] <Chipaca> zyga-ubuntu: did you look under the bed
[08:05] <zyga-ubuntu> Chipaca: I wanted to stay there today actually
[08:07] <Chipaca> zyga-ubuntu: under the bed?
[08:08] <zyga-ubuntu> in it
[08:08] <Chipaca> zyga-ubuntu: my dog hides under the bed during thunderstorms
[08:09] <Chipaca> she's brave like that
[08:33] <zyga-ubuntu> CI is slow today?
[08:35]  * Chipaca quotes poetry at niemeyer 
[08:45] <sparkiegeek> Chipaca: Vogon poetry?
[08:45] <Chipaca> sparkiegeek: unix poetry
[08:45] <Chipaca> sparkiegeek: tomeito/tomahto
[08:48] <mup> PR snapcraft#1567 opened: recording: record the snaps installed in the machine <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1567>
[08:52] <mup> PR snapd#3956 opened: snap-confine: bind mount /usr/lib/snapd relative to snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3956>
[08:53] <mvo> zyga-ubuntu: ^- something for you :) should be easy but was a bit tricky to figure out
[08:59] <zyga-ubuntu> looking
[09:03] <zyga-ubuntu> mvo: interesting,
[09:03] <zyga-ubuntu> mvo: I suspect we can do away with _some_ of those snprintfs but it looks good
[09:04] <mup> PR snapd#3955 closed: dirs,interfaces: create snap-confine.d on demand when re-executing <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3955>
[09:10] <zyga-ubuntu> mvo: done
[09:28] <pedronis> mvo: zyga-ubuntu: should 't we change the name of sc_mount_config.on_classic_distro to something else , now that is true on core also with base snaps
[09:34] <zyga-ubuntu> pedronis: yes, I think it will become "use_classic_confinement" or similar
[09:34] <zyga-ubuntu> pedronis: as everything else will be identical
[09:34] <zyga-ubuntu> we may not need that variable afte rall
[09:38] <pedronis> classic_confinement is a bit strange given that is not confiment: classic
[09:39] <zyga-ubuntu> in which way?
[09:40] <zyga-ubuntu> I mean that the only remaning boolean variable is if we need a mount namespace or not
[09:43] <pedronis> I'm saying that using classic in the name of a bool that we use both on classic and core is strange, that classic confiment means too many things already
[09:44] <zyga-ubuntu> pedronis: right, I think we are in agreement, it is not done yet but eventually there will be just one flag "mount namespace needed", we need to finish the transition and rename things
[10:35] <ackk> niemeyer, hi, left a question on https://github.com/snapcore/snapd/pull/3916 about validateion
[10:35] <mup> PR #3916: snap,wrappers: add support for socket activation <Created by albertodonato> <https://github.com/snapcore/snapd/pull/3916>
[10:35] <ackk> *validation
[10:44] <doko> snapcraft autopkg test failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/amd64/s/snapcraft/20170922_010609_57ea7@/log.gz
[10:45] <doko> output: {{{b'/snap/godd/x1/bin/godd: relocation error: /snap/godd/x1/lib/x86_64-linux-gnu/libpthread.so.0: symbol __mmap, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference\n'}}}
[10:46] <doko> but it's built with glibc-2.26 ...
[10:48] <ogra_> godd is also a properly confined snap (i have only seen that with --classic snaps on artful yet) which makes it even weirder ...
[10:48] <ogra_> mvo, ^^^
[10:48] <ogra_> *classic snaps that get built *on* and *against* artful
[10:49] <mvo> ogra_: looking
[11:35] <mup> PR snapd#3934 closed: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3934>
[11:36] <mup> PR snapd#3928 closed: interfaces/system-observe: allow clients to enumerate DBus connection names <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3928>
[11:41] <ackk> ogra_, mvo does snapd already have code to validate URIs (hostname:port, ip:port, ipv6:port, port and so on)?
[11:49]  * ogra_ doesnt know ... i think we used to have code to check for occupied ports when we used to support the "ports:" keyword in snap.yaml during 15.04, but i dont know if that code survived
[11:52] <ackk> ogra_, now that I think about it, for the listen-stream case I think I could just validate that it's a port, there's no real point in specifying an address
[11:52] <ackk> well, maybe localhost
[11:52] <ogra_> ackk, well, what happens if i install a snap using port 80 that already has an apache deb installed ?
[11:53] <ackk> ogra_, that's a separate issue though
[11:53] <ogra_> right, but there needs to be some check so my snap doesnt madly try to respawn
[12:07] <kyrofa> zyga-ubuntu, I did, thank you! It was tremendously helpful. I tried to thank you last night, but you were gone :(
[12:08] <sergiusens> kyrofa up so early?
[12:08] <kyrofa> sergiusens, I've been a little more popular than I was anticipating... haven't had time to put that lightning talk together! This is my solution :P
[12:08] <sergiusens> elopio mind looking at the artful issues with snapcraft (mentioned on ubuntu-release and here by doko)? I'll be running errands all day today
[12:18] <zyga-ubuntu> kyrofa: I was upset because while doing that I removed my whole snapd tree with unmerged code
[12:18] <zyga-ubuntu> kyrofa: I had a symlink
[12:19] <kyrofa> zyga-ubuntu, I'm sorry about that! Were you able to recover from backup?
[12:19] <zyga-ubuntu> kyrofa: and I wasn't operating on a copy :(
[12:19] <zyga-ubuntu> kyrofa: no, my backup was broken (deja-***-dup)
[12:19] <kyrofa> :(
[12:19] <zyga-ubuntu> anyway
[12:19] <zyga-ubuntu> I kind of remember what I wrote
[12:19] <zyga-ubuntu> guess what I'm doing today
[12:21] <mvo> ackk: hi, re url parsing> is https://golang.org/pkg/net/url/#Parse that you need?
[12:22] <Chipaca> I wish there was an Equals interface in go
[12:25] <ackk> mvo, not really. listen-stream for TCP/UDP is basically in the form of  [address:]port
[12:26] <mvo> ackk: hm, I see
[12:27]  * Chipaca takes a break
[12:28] <ackk> mvo, I mean, I can implement the validation, just wondering if there's something like that already
[12:29] <mvo> ackk: not sure what exactly listen-stream looks like, but https://play.golang.org/p/Fi-0n-cRNF is using url.Parse() even without schema
[12:29] <ackk> mvo, also, it may be that we just care about the port (see my comment https://forum.snapcraft.io/t/socket-activation-support/2050/28?u=ack)
[12:29] <mvo> ackk: I have a meeting now, but can check after the meeting for listen-stream
[12:34] <ackk> mvo, it doesn't really work https://play.golang.org/p/QPUxhKV_Dv :)
[12:49] <niemeyer> Moin moin
[12:55] <niemeyer> ackk: Thanks, responded
[13:00] <mvo> niemeyer: please start without me, I'm in a different meeting
[13:02] <zyga-ubuntu> oh
[13:02] <zyga-ubuntu> standup
[13:02] <zyga-ubuntu> joining
[13:06] <phil_m> zyga-ubuntu: hi, how are you today?
[13:07] <zyga-ubuntu> phil_m: hi
[13:07] <zyga-ubuntu> phil_m: I'm around
[13:09] <phil_m> good.
[13:09] <phil_m> just wanted to ask you about the current progress you made with Manjaro.
[13:09] <phil_m> any news. some I should test on my end?
[13:12] <zyga-ubuntu> phil_m: I didn't have time to try it on real hardware but I have a spare HDD so I plan to install it over weekend; apart from that it is ready and I just want to test it
[13:12] <zyga-ubuntu> phil_m: (on hardware, works in VM)
[13:13] <zyga-ubuntu> phil_m: I had a pretty bad day last nigth though because my I managed to rm -rf my work directory on my main desktop
[13:14] <phil_m> zyga-ubuntu: ouch.
[13:14] <phil_m> that is really sad to hear.
[13:14] <ackk> niemeyer, thanks. basically I think I only need a final decision about what is acceptable for listen-stream
[13:18] <ogra_> niemeyer, how do i add an "ogra" tag in the forum (does that need you with admin rights ?)
[13:18] <niemeyer> ogra_: Yeah, not just me, but someone with permissions
[13:18] <zyga-ubuntu> phil_m: but no worries, all my patches are still in that VM so I didn't completely blow my data
[13:19] <niemeyer> ogra_: Only thing I ask is to please follow the conventions in that topic (can find the link if you want) about tagging with upcoming and backlog as well, so the username tag should not be alone
[13:19] <phil_m> zyga-ubuntu: ok. makes sense
[13:19] <ogra_> niemeyer, it is for https://forum.snapcraft.io/t/split-initrd-implementation/2224/1
[13:20] <ogra_> (allready has upcoming and will likelyy get more names on it)
[13:20] <ogra_> niemeyer, thanks!
[13:20] <niemeyer> ogra_: Done, tag created
[13:20] <ogra_> oh, gone again
[13:20] <niemeyer> ogra_: You should be able to use it now
[13:20] <ogra_> k
[13:21] <ogra_> yup, works
[13:21] <mup> PR snapcraft#1568 opened: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568>
[13:22] <mvo> jdstrand: when you have a moment (not urgent) a review of 3956 would be appreciated
[13:23]  * kalikiana feeling dizzy and hungry, taking a break and looking for some food
[13:39] <mup> Bug #1718942 opened: running favorited snap shows two icons in Ubuntu dock <Snappy:New> <https://launchpad.net/bugs/1718942>
[13:52] <phil_m> zyga-ubuntu: I just created a new package of snapd with version 2.28dev+g0723493
[13:53] <phil_m> zyga-ubuntu: still face the error 'cannot locate the base snap: ubuntu-core: No such file or directory' on my end.
[13:54] <ogra_> phil_m, weird, does it really still say ubuntu-core ?
[13:54] <ogra_> phil_m, also ... did you see https://forum.snapcraft.io/t/snap-on-arch-liri-os/2223/1
[13:54] <phil_m> yep.
[13:55] <phil_m> zyga-ubuntu: used files can be found here: https://github.com/manjaro/packages-community/tree/master/snapd-git
[13:55] <phil_m> and the standard stable release at: https://github.com/manjaro/packages-community/tree/master/snapd
[13:56] <ogra_> (funny that is seems to be kind of working with a few minor changes on liriOS but not on manjaro ... )
[13:57] <phil_m> maybe I should change PATH=$PATH:/var/lib/snapd/snap/bin:/snap/bin to just PATH=$PATH:/snap/bin
[14:00] <phil_m> orga_: we already use: https://github.com/snapcore/snapd/commit/413a2a099dc57e3fb7c7e82a6c7250cf4c2f74fd
[14:01] <ogra_> yeah
[14:05] <zyga-ubuntu> phil_m: hmmmmm
[14:05] <zyga-ubuntu> phil_m: we had a patch for that error message
[14:05] <zyga-ubuntu> phil_m: one sec
[14:06] <kyrofa> Hey kalikiana I've got an odd bug. As you've been touching the repo code most recently, any chance you've come across it? https://bugs.launchpad.net/snapcraft/+bug/1686481
[14:06] <mup> Bug #1686481: stage-packages doesn't respect architectures <kubernetes> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1686481>
[14:07] <kyrofa> Or otherwise have any insight
[14:08] <zyga-ubuntu> phil_m: do you have 8c821c13bb62703c5119a1b0b1edbd53ce7f48aa in your tree?
[14:09] <phil_m> let me check
[14:10] <phil_m> no, will try some now.
[14:13] <mup> PR snapd#3957 opened: cmd,dirs: treat "liri" the same way as "arch" <Created by zyga> <https://github.com/snapcore/snapd/pull/3957>
[14:14] <phil_m> hmm, the error is gone, but now it simply hangs a while
[14:14] <phil_m> chromium now started with a delay
[14:14] <ogra_> well
[14:14] <phil_m> second start was faster.
[14:14] <ogra_> snaps typically coopy some stuff arund on first start
[14:14] <ogra_> s thats kind of expected
[14:14] <phil_m> seems it is now kinda working
[14:15] <ogra_> \o/
[14:15] <zyga-ubuntu> phil_m: is snapd running?
[14:15] <phil_m> seems so
[14:16] <ogra_> if the chroium snap runs it better should :P
[14:16] <phil_m> now I only don't know if it is in /snap or in the /var/lib/snapd/snap
[14:17] <zyga-ubuntu> phil_m: what did you rebuild?
[14:17] <zyga-ubuntu> phil_m: can you please look at https://forum.snapcraft.io/t/snap-on-arch-liri-os/2223/4
[14:17] <zyga-ubuntu> phil_m: using that source package (just with .6 and manjaro patch instead of liro patch) you should be mostly fine
[14:17] <phil_m> will upload the changes soon
[14:38] <jdstrand> mvo: done
[14:40] <flexiondotorg> Hey zyga-ubuntu
[14:41] <flexiondotorg> So, you're still seeking an Arch TU to collaborate with?
[14:46] <zyga-ubuntu> flexiondotorg: hey
[14:46] <zyga-ubuntu> flexiondotorg: yes, very much so
[14:46] <zyga-ubuntu> flexiondotorg: especially now with arch derivatives suffering from old package ther
[14:48] <zyga-ubuntu> flexiondotorg: do you have someone that could help?
[14:49] <flexiondotorg> Well, I've been reaching out to the main derivatives Manjaro and Antergos.
[14:50] <flexiondotorg> I'll see if I still have any credit in the Arch community. I'll see if I can find a sponsor to reprise my role as Arch Linux TU
[14:50] <zyga-ubuntu> flexiondotorg: thank you!
[14:53] <flexiondotorg> If I can get a sponsor, it will still be down to a vote and that takes a month
[14:55] <zyga-ubuntu> yes, I read the protocol
[14:55] <zyga-ubuntu> the best we can do though
[14:55] <zyga-ubuntu> I really wish timothy didn't abandon the package
[14:55] <zyga-ubuntu> but it seems he has
[14:56] <zyga-ubuntu> (also ignoring email)
[14:56] <flexiondotorg> Yep, I've tried contacting him too
[14:57] <zyga-ubuntu> maybe we could give him a ring via RH
[14:57] <flexiondotorg> Indeed😉
[14:57] <zyga-ubuntu> "step down considerably" is not a virtue it seems
[14:57] <zyga-ubuntu> e
[14:57] <zyga-ubuntu> er
[14:57] <zyga-ubuntu> "resposibly" was it?
[14:57] <zyga-ubuntu> anyway
[15:01] <Pharaoh_Atem> mvo: let me give it a whirl
[15:02] <Pharaoh_Atem> zyga-ubuntu: I'll see if I can get a hold of tradelli
[15:02] <mvo> Pharaoh_Atem: thanks
[15:03] <Pharaoh_Atem> zyga-ubuntu: he's in the Fedora community somewhat since he now works at Red Hat
[15:03] <zyga-ubuntu> Pharaoh_Atem: thank you!
[15:04] <zyga-ubuntu> Pharaoh_Atem: note that we made multiple attempts to contact him (irc, twitter, email, linkedin) and got no replies
[15:04] <zyga-ubuntu> (over extended amount of time)
[15:04] <Pharaoh_Atem> zyga-ubuntu: I've talked to him a couple of times recently
[15:04] <Pharaoh_Atem> his dead is down in the weeds in DPDK and kernel networking stuff
[15:04] <Pharaoh_Atem> s/dead/head/
[15:04] <mvo> jdstrand: thanks a bunch! I addressed your comments
[15:05] <zyga-ubuntu> Pharaoh_Atem: haha
[15:05] <Pharaoh_Atem> he took over from Panu Matilainen when he returned to the helm of rpm development/maintenence
[15:05] <zyga-ubuntu> Pharaoh_Atem: DPDK?
[15:05] <Pharaoh_Atem> Data Plane Developer Kit
[15:05] <Pharaoh_Atem> from Intel, now a Linux Foundation project
[15:05] <Pharaoh_Atem> does weird things to network subsystem to make things go fasterer
[15:06] <Pharaoh_Atem> https://en.wikipedia.org/wiki/Data_Plane_Development_Kit
[15:06]  * ogra_ points to apt-cache show dpdk
[15:07] <zyga-ubuntu> magic
[15:07] <Pharaoh_Atem> but basically, DPDK is terrible and sucks the life out of you
[15:08] <zyga-ubuntu> Pharaoh_Atem: it must pay well then
[15:09] <Pharaoh_Atem> mvo: err, why is the spec in 2.28 branch telling me it's 2.27.5?
[15:11] <phil_m> zyga-ubuntu: Manjaro now supports fully snaps
[15:12] <Pharaoh_Atem> mvo: ah, you haven't been bumping the versions like you did for 2.27 during the rc development
[15:12] <phil_m> I've tested the curren stable v2.17 and current dev series v2.28
[15:18] <zyga-ubuntu> phil_m: \o/ !!
[15:18] <zyga-ubuntu> phil_m: excellent
[15:18] <zyga-ubuntu> phil_m: what kind of GPU do you have?
[15:18] <zyga-ubuntu> phil_m: and can you tell me more about your kernel
[15:18] <zyga-ubuntu> phil_m: (and can we add a logo with installation instructions to snapcraft.io?)
[15:22] <phil_m> you can add a logo and the instruction # pacman -Sy snapd when we released it also to our stable branches
[15:23] <phil_m> I've an Nvidia gpu
[15:23] <zyga-ubuntu> phil_m: excellent, I'll make that happen! Thank you! :)
[15:23] <phil_m> and the kernel is more or less vanilla with some patches added.
[15:23] <zyga-ubuntu> phil_m: do you have a preferred logo (quality, etc) I should use?
[15:23] <davidcalle> zyga-ubuntu: phil_m: can you open a bug with the logo?
[15:23] <phil_m> https://github.com/manjaro/packages-core/tree/master/linux413
[15:24] <phil_m> is the current stable kernel
[15:24] <phil_m> davidcalle: in which tracker should I open the bug?
[15:25] <davidcalle> https://github.com/canonical-websites/snapcraft.io-static-pages
[15:25] <davidcalle> Thanks phil_m :)
[15:25] <zyga-ubuntu> thank you both!
[15:29] <kalikiana> kyrofa: Sorry for the late reply, this stupid cold forced me to rest... regarding bug 1686481 I'll add a comment in a moment
[15:29] <mup> Bug #1686481: stage-packages doesn't respect architectures <kubernetes> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1686481>
[15:31] <jdstrand> mvo: hey, did you see my followup comment on PATH_MAX?
[15:31] <jdstrand> mvo: also, think you need a go fmt
[15:32] <phil_m> davidcalle: https://github.com/canonical-websites/snapcraft.io-static-pages/issues/387
[15:33] <zyga-ubuntu> jdstrand: thank you for the instructive reviews!
[15:33] <zyga-ubuntu> mvo: can I merge https://github.com/snapcore/snapd/pull/3952
[15:33] <mup> PR #3952: cmd: update "make hack" <Created by zyga> <https://github.com/snapcore/snapd/pull/3952>
[15:40] <zyga-ubuntu> one more test...
[15:49] <kalikiana> kyrofa: Good job spotting that old bug :-D I posted a test snippet that seems to work for me. Although this is almost untested so not sure if it does what they need - but at least I've got some tests for this in my queue
[15:53] <kyrofa> kalikiana, excellent, thank you very much :)
[16:05] <ogra_> ARGH !
[16:05] <ogra_> my rocket snap just made my system get stuck
[16:06] <ogra_> niemeyer, is it wanted that mup just sent ~1000 PR messages to #snapcraft on rocket ?
[16:06] <niemeyer> ogra_: I hope you know the answer to that :)
[16:06] <ogra_> heh
[16:07] <ogra_> well, something is weird
[16:07] <niemeyer> ogra_: IIRC mup was actually disabled there
[16:07] <ogra_> yeah
[16:07] <niemeyer> ogra_: Someone is probably fiddling with settings
[16:07] <ogra_> thats what i meant with weird :)
[16:08] <niemeyer> ogra_: They broke the plugin API for the Nth time a couple of months ago and I disabled it.. need to look into it to see if it's fixed
[16:08] <ogra_> seems to have stopped now
[16:08] <sergiusens> kalikiana elopio how about a look on snapcraft#1565 ?
[16:08] <mup> PR snapcraft#1565: cli: add the assemble command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1565>
[16:08] <niemeyer> ogra_: Probably someone just flipped the switch enabling it
[16:08] <ogra_> yep, for a minute or two and it replayed some caxche i guess
[16:21] <kalikiana> sergiusens: You got some comments
[16:25] <ikey> looks like manjaro landed snap support
[16:25] <ikey> the commune groweth
[16:31] <zyga-ubuntu> ikey: indeed :)
[16:33] <ikey> looks like everyone is getting on the bandwagon now
[16:33]  * ikey likes cascading self ordering chaos
[16:49] <niemeyer> ikey, zyga-ubuntu: Nice!
[16:52] <ogra_> nacc, i guess kyrofa would know more about that ;)
[16:52] <ogra_> (and i'm saying this here because he isnt in #ubuntu-release=
[16:52] <ogra_> )
[16:53] <ogra_> :)
[16:55] <nacc> ogra_: ack :)
[16:57] <mvo> zyga-ubuntu: I think so
[16:58] <mvo> jdstrand: yeah, I fixed that, thanks and sorry :)
[16:58] <mvo> Pharaoh_Atem: I can push with 2.28~rc4 if you want
[16:58] <mup> PR snapd#3952 closed: cmd: update "make hack" <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3952>
[17:01] <jdstrand> mvo: thanks!
[17:07] <zyga-ubuntu> mvo: thank you
[17:15] <Pharaoh_Atem> mvo: I'm testing to see if the new cheggaaa-pb package works without the hack atm
[17:15] <mvo> Pharaoh_Atem: thanks
[17:15] <Pharaoh_Atem> if it does, I'm going to send a PR to revert that commit and then the corresponding revert can be done in 2.28
[17:17]  * zyga-ubuntu -> supper
[18:03] <kyrofa> Nooo, I got up at 5am to prep a lightning talk only to arrive and learn they switched it to a raffle instead of first-come-first-served... and didn't get in
[18:06] <kyrofa> nacc, ogra_ I seem to be missing the scrollback that contains context. What would I know more about?
[18:06] <nacc> kyrofa: it's mostly in #ubuntu-release
[18:07] <nacc> kyrofa: let me get the linnk
[18:07] <kyrofa> Haha, well that would explain the missing context
[18:07] <nacc> https://irclogs.ubuntu.com/2017/09/22/%23ubuntu-release.html
[18:07] <nacc> kyrofa: exec. summary: 1) snapcraft dep8 tests are broken on artful 2) artful builds of snaps are broken
[18:08] <nacc> aiui, the solutions are multiple: 1) snapcraft dep8 should use cleanbuild
[18:08] <zyga-ubuntu> man, travis and github don't love me today
[18:08] <nacc> 2) there needs to be blacklist libs file added for all non-16.04 releases (elopio had a test for this for 17.10 specifically)
[18:08] <zyga-ubuntu> network isuses
[18:08] <kyrofa> Yes indeedy, that's not surprising at all
[18:09] <nacc> 3) the fallback for not havinng a filelist should be an error (IMO), not a fallback. As it just doesn't work. Or the fallback list should be everything the libc deb provides
[18:09] <nacc> now that won't fix artful builds of snaps, as they still have a xenial core snap and there be dragons
[18:10] <nacc> but it means the libc issue that's currently busted would work, i think
[18:10] <nacc> s/would work/would not manifest itself/
[18:11] <kyrofa> Sorry guys, I didn't realize that was a room in which I should idle
[18:11] <kyrofa> Rectified now
[18:11] <nacc> kyrofa: we probably should have brought the convo here
[18:13] <kyrofa> nacc, so yeah, snapcraft crawls prime and essentially sucks over any libs it discovers via ldd on every elf
[18:13] <kyrofa> nacc, it ships the libraries/16.04 file as a blacklist of stuff in the core snap to NOT suck over
[18:14] <kyrofa> But of course, it checks the OS before deciding whether or not to use libraries/16.04, or libraries/16.10, etc
[18:14] <kyrofa> The latter of which doesn't exist
[18:14] <kyrofa> Thus nothing gets excluded, and it sucks everything off the host
[18:14] <nacc> kyrofa: yep that was my analysis from the source as well
[18:15] <nacc> kyrofa: since snapcraft's dep8 is runnig natively on artful, it didn't find any blacklist file
[18:15] <kyrofa> This is a problem not only per release, but per arch, as different arch core snaps contain different things, and thus need separate blacklists
[18:15] <nacc> kyrofa: ouch :/
[18:15] <kyrofa> To compound matters, we've decided the library sucking feature sucks (heh) because it's magical and unreliable, as you've discovered, so we haven't really invested in making it better
[18:16] <nacc> well, as of right now there are two relatively high-profile (to me) issues then: snapcraft dep8 is failing and any snap built on artful right now is going to be broken
[18:16] <kyrofa> Yes and yes. Agreed
[18:16] <nacc> I happened to get built by the latter before the former was seen, I guess :)
[18:16] <asafniv1[m]> any good snap apps?
[18:17] <kyrofa> I really don't think we should just remove the feature though, or current snaps will stop working
[18:17] <kyrofa> So we probably need to invest some time in improving it
[18:17] <asafniv1[m]> we should make snaps use system fonts and theme
[18:17] <nacc> kyrofa: yeah, i'm not sure the best way forward -- i think elopio's file list is a good start (i'm not sure how many non-amd64 non-classic snaps are being built on artful, e.g.)
[18:17] <nacc> kyrofa: but like you said, that's insufficient on its own
[18:18] <nacc> i'm also switching my snap to build on xenial (presuming the tests pass :)
[18:20] <kyrofa> ogra_, if I install a snap on artful, what core snap am I getting? The 16 one, right?
[18:21] <kyrofa> Which means even if we DO blacklist the stuff in the core snap, if the libc in artful changes, it'll still be pulled in
[18:21] <zyga-ubuntu> kyrofa: yes
[18:22] <kyrofa> Even if the library sucking feature was gone, the snap would be built against a different libc version than that with which it will be run
[18:22] <kyrofa> There's no solution to this problem!
[18:22] <kyrofa> :P
[18:22] <nacc> kyrofa: yeah, this is all pretty buggy (building on artful) until we get base snaps
[18:22] <kyrofa> Yep
[18:22] <nacc> that's why, honestly, it should be disabled (but there's no way to communicate that effectively it feels like)
[18:22] <nacc> it's just guaranteed to have weird failures eventually :)
[18:23] <kyrofa> nacc, well, like I said, even if it was disabled, building on artful won't result in a snap that runs
[18:23] <nacc> kyrofa: no, i mean, don't allow buildig on artful :)
[18:23] <nacc> at least not via LP
[18:23] <kyrofa> Ahhh
[18:23] <asafniv1[m]> Don't use ubuntu
[18:23] <kyrofa> Agreed. It should only be xenial
[18:23] <nacc> it's just goign to lead to bad publishes to the store right now
[18:23] <nacc> kyrofa: yep
[18:23] <kyrofa> Indeed
[18:24] <kyrofa> And the autopkgtests should be cleanbuild
[18:24] <nacc> kyrofa: yeah, that will at least get them passing, regardless of aythign
[18:24] <kyrofa> Although that means less of snapcraft is tested, which isn't great
[18:25] <asafniv1[m]> what if someone makes a snap virus
[18:25] <zyga-ubuntu> asafniv1[m]: what then?
[18:25] <asafniv1[m]> would canonical remove it?
[18:25] <asafniv1[m]> btw do they test snaps?
[18:26] <asafniv1[m]> or scan?
[18:27] <zyga-ubuntu> asafniv1[m]: we don't test snaps
[18:27] <zyga-ubuntu> asafniv1[m]: we scan them for certain things
[18:27] <zyga-ubuntu> asafniv1[m]: and check which interfaces they want to use, snaps get manual review if they request privileged interface for the first time
[18:28] <asafniv1[m]> ok
[18:28] <nacc> kyrofa: yeah, the coverage would go down, i suppose
[18:29] <zyga-ubuntu> asafniv1[m]: the security model depends on a combination of sandbox, distinction between privileged and common interfaces and packages that are signed by the snap store
[18:29] <zyga-ubuntu> asafniv1[m]: you can upload any code you like, it will not be allowed to do anything from the privileged set unless there is a store review and we essentially trust you
[19:20] <zyga-ubuntu> niemeyer: hey
[19:21] <zyga-ubuntu> ah, found it :)
[19:21] <niemeyer> zyga-ubuntu: Heya :)
[19:22] <zyga-ubuntu> niemeyer: I flagged some spam on the forum
[19:22] <zyga-ubuntu> niemeyer: wasn't sure if you are still around
[19:28] <niemeyer> zyga-ubuntu: Done
[19:36] <zyga-ubuntu> thank you :)
[19:39] <niemeyer> zyga-ubuntu: np, thanks for flagging!
[19:51] <nacc> we've got a jenkins job that is trying to test MPs for git-ubuntu before we land them by building a snap on xenial (using cleanbuild) in a xenial VM and then testing that locally built snap. Anyone know why we're gettinng the following error related to the core snap?https://paste.ubuntu.com/25594413/
[20:29] <sergiusens> kyrofa nacc we shouldn't improve it, we should remove it as we discussed months ago, breakage here is a simple fix
[20:30] <sergiusens> and there probably won't be base snaps for non LTS releases
[20:30] <sergiusens> but we haven't gotten into the details around that, probably a discussion for next week with niemeyer
[20:31] <nacc> sergiusens: yeah, i'm +1 onn removing it if there really can't be support for it
[20:31] <nacc> sergiusens: i'm not going to be at the rally, but i thikn i'll be getting hte info from my team
[20:54] <mup> Bug #1690880 changed: test_snappy_version fails on artful <cloud-init:Fix Released> <Snappy:Fix Released> <https://launchpad.net/bugs/1690880>
[21:00] <kyrofa> sergiusens, I don't think that's a good idea-- lots of snaps will break. But it's your call
[21:02] <sergiusens> kyrofa they will have a simple fix
[21:03] <kyrofa> sergiusens, it's still breakage that requires them to fix it
[21:03] <nacc> sergiusens: build from source on xenial?
[21:03] <kyrofa> Think CI, daily builds
[21:04] <sergiusens> kyrofa if CI never breaks, why do you run it?
[21:04] <sergiusens> I know it will break, people running CI will detect it fast and adapt
[21:04] <kyrofa> CI is for catching MY problems :P
[21:04] <sergiusens> same thing for new features and deprecations in snapd (e.g.; aliases)
[21:05] <kyrofa> But yeah, your call
[21:06] <nacc> sergiusens: is what i said the fix?
[21:40] <nacc> is this expected?
[21:40] <nacc> ls -ahl /snap/core/current/lib64/ld-linux-x86-64.so.2
[21:40] <nacc> lrwxrwxrwx 1 root root 32 Sep 11 23:36 /snap/core/current/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.23.so
[21:40] <nacc> (which does't exist on artful)
[21:40] <nacc> ogra_: --^ i switched my snnap to build with cleanbuild and now i get the relocation error on artful :)
[21:41] <ogra_> heh
[21:41] <nacc> still waiting for jenkins to finish to see if it works on 16.04 now, at least
[21:43] <nacc> specifically /usr/bin/python3: /snap/core/current/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /usr/bin/python3)
[21:43] <nacc> not sure why it' susing the python3 from the host
[21:46] <ogra_> is it using the python plugin ?
[21:47] <nacc> ogra_: no, my app just uses the dump plugin
[21:47] <nacc> and every command is pointed at a wrapper script
[21:47] <nacc> that invokes python3 *in* my snap
[21:47] <ogra_> kyrofa, sorry, i didnt mean you should permanently idle in #ubuntu-release ... that was more a ping for if you were around to participate in the discussion :)
[21:48] <ogra_> nacc, right ... the pytjon plugin makes sure you get the interpreter inside iirc
[21:48] <ogra_> *python
[21:48] <nacc> ogra_: hrm, by doing what? i mean does it tell snapd something?
[21:49] <ogra_> so you should perhaps add another part using the python plugin and not doing anything else
[21:49] <ogra_> it ships it in $SNAPp
[21:49] <nacc> oh i do have one for python2
[21:49] <ogra_> it ships it in $SNAP/bin
[21:49] <nacc> hrm
[21:49] <nacc> ok
[21:49] <nacc> ogra_: i have a python3 in my snap
[21:49] <nacc> i'm wondering if env is messed up now
[21:49]  * ogra_ gets dinner and needs to go afk ... 
[21:50] <nacc> ogra_: np, thanks for all the help today!
[21:50] <ogra_> :)
[21:54] <nacc> ok relocation error was a bug in how i was calling the python3 argcomplete
[21:57] <kwmonroe> ahoy snapaholics - in the content interface doc (https://forum.snapcraft.io/t/the-content-interface/1074) it mentions writable data should "share all of $SNAP_DATA or $SNAP_COMMON for now."  is that still a thing?  i'm able to share writable subdirs in core-16-2.27.6, but dunno what nasties may come.
[22:01] <nacc> ogra_: lol, i see it now and am not sure how to fix it
[22:01] <nacc> #!/usr/bin/env python3 in my pseudo-confined snap will segfault on artful
[22:02] <nacc> because i've modified LD_LIBRARY_PATH to point to the core snap
[22:02] <nacc> but /usr/bin/env is from artful
[23:42] <nacc> ogra_: so that was definitely one issue (which is hard to debug, as the segfault happens in the python script wrapped)
[23:42] <nacc> ogra_: and i foudn the other one, i had forgotten to drop the stage-packages i was no building from src, so they were overriding my built binaries and leading to segfaults ;)
[23:42] <nacc> i'm rebuilding now to test
[23:47] <mup> PR snapcraft#1569 opened: tests: refactor the fake snapd to not hardcode values <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1569>
[23:50] <nacc> kyrofa: sergiusens: do you want me to file a bug or something for this?
[23:50] <nacc> ogra_: --^