[00:17] PR snapcraft#1558 closed: tests: add fake pip fixture === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === JoshStrobl|zzz is now known as JoshStrobl === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [06:18] PR snapd#3947 closed: cmd/snap-repair: fix tests when running as root [06:22] * zyga-ubuntu has the worst friday possible [06:22] I removed my snapd tree, including all of git history last night [06:25] so plan for today, is to ensure this doesn't happen again [06:27] PR snapcraft#1566 opened: recording: record build-snaps installed during the pull [06:28] kyrofa: hey [06:28] kyrofa: did you use that pastebin I gave you last night? [06:35] daily automated backups of everything - it's the only way [06:39] cjwatson: deja dup backups got corrupted [06:40] 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] Yeah, I used deja-dup for a little while and then decided it was far too complex [06:41] I use rsbackup now which is basically just glorified rsync --link-dest; much less to go wrong [06:42] thank you, I'll check that out [06:49] zyga-ubuntu: could oyu please check 3953? [06:49] mvo: sure [06:50] mvo: why not go all the way and just do this unconditionally? [06:54] zyga-ubuntu: not sure, to minimize risk maybe? [06:54] zyga-ubuntu: I'm fine with all-the-way for 2.29 [06:54] mvo: sounds good to me [06:55] thanks [06:56] done [07:00] PR snapd#3953 closed: snap-confine: fix base snaps on core [07:00] thanks zyga-ubuntu [07:01] thank you for doing this :) === ikey is now known as ikey|zzz [07:04] Pharaoh_Atem: is 2.28~rc3 doing ok on fedora or anything needs fixing before 2.28-final? [07:09] zyga-ubuntu: backups of git? in my word, that's what you get by pushing ;-) [07:10] good morning, snappy world [07:12] * kalikiana no more headache for now, just caughing, may the health be with me today [07:12] 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] (oh, and good morning everyone, by the way!) [07:24] 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] broken [07:25] mvo: loking [07:26] oh [07:26] good point [07:26] mvo: how did tests not catch that? [07:26] mvo: ah, I think I know [07:33] mvo: ok I have a patch [07:39] PR snapd#3955 opened: dirs,interfaces: create snap-confine.d on demand when re-executing [07:39] mvo: https://github.com/snapcore/snapd/pull/3955 [07:39] PR #3955: dirs,interfaces: create snap-confine.d on demand when re-executing [08:03] Chipaca: can you please look at https://github.com/snapcore/snapd/pull/3955/files [08:03] PR #3955: dirs,interfaces: create snap-confine.d on demand when re-executing [08:04] aye aye cap'n [08:04] thank you [08:04] Chipaca: I lost my snapd tree with 2 weeks of code in it [08:04] not a great day [08:04] zyga-ubuntu: did you look under the bed [08:05] Chipaca: I wanted to stay there today actually [08:07] zyga-ubuntu: under the bed? [08:08] in it [08:08] zyga-ubuntu: my dog hides under the bed during thunderstorms [08:09] she's brave like that [08:33] CI is slow today? [08:35] * Chipaca quotes poetry at niemeyer [08:45] Chipaca: Vogon poetry? [08:45] sparkiegeek: unix poetry [08:45] sparkiegeek: tomeito/tomahto [08:48] PR snapcraft#1567 opened: recording: record the snaps installed in the machine [08:52] PR snapd#3956 opened: snap-confine: bind mount /usr/lib/snapd relative to snap-confine [08:53] zyga-ubuntu: ^- something for you :) should be easy but was a bit tricky to figure out [08:59] looking [09:03] mvo: interesting, [09:03] mvo: I suspect we can do away with _some_ of those snprintfs but it looks good [09:04] PR snapd#3955 closed: dirs,interfaces: create snap-confine.d on demand when re-executing [09:10] mvo: done [09:28] 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] pedronis: yes, I think it will become "use_classic_confinement" or similar [09:34] pedronis: as everything else will be identical [09:34] we may not need that variable afte rall [09:38] classic_confinement is a bit strange given that is not confiment: classic [09:39] in which way? [09:40] I mean that the only remaning boolean variable is if we need a mount namespace or not [09:43] 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] 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] niemeyer, hi, left a question on https://github.com/snapcore/snapd/pull/3916 about validateion [10:35] PR #3916: snap,wrappers: add support for socket activation [10:35] *validation [10:44] 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] 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] but it's built with glibc-2.26 ... [10:48] 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] mvo, ^^^ [10:48] *classic snaps that get built *on* and *against* artful [10:49] ogra_: looking [11:35] PR snapd#3934 closed: snap-repair: implement `snap-repair {list,show}` [11:36] PR snapd#3928 closed: interfaces/system-observe: allow clients to enumerate DBus connection names [11:41] 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] 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] well, maybe localhost [11:52] ackk, well, what happens if i install a snap using port 80 that already has an apache deb installed ? [11:53] ogra_, that's a separate issue though [11:53] right, but there needs to be some check so my snap doesnt madly try to respawn [12:07] zyga-ubuntu, I did, thank you! It was tremendously helpful. I tried to thank you last night, but you were gone :( [12:08] kyrofa up so early? [12:08] 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] 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] kyrofa: I was upset because while doing that I removed my whole snapd tree with unmerged code [12:18] kyrofa: I had a symlink [12:19] zyga-ubuntu, I'm sorry about that! Were you able to recover from backup? [12:19] kyrofa: and I wasn't operating on a copy :( [12:19] kyrofa: no, my backup was broken (deja-***-dup) [12:19] :( [12:19] anyway [12:19] I kind of remember what I wrote [12:19] guess what I'm doing today [12:21] ackk: hi, re url parsing> is https://golang.org/pkg/net/url/#Parse that you need? [12:22] I wish there was an Equals interface in go [12:25] mvo, not really. listen-stream for TCP/UDP is basically in the form of [address:]port [12:26] ackk: hm, I see [12:27] * Chipaca takes a break [12:28] mvo, I mean, I can implement the validation, just wondering if there's something like that already [12:29] 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] 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] ackk: I have a meeting now, but can check after the meeting for listen-stream [12:34] mvo, it doesn't really work https://play.golang.org/p/QPUxhKV_Dv :) [12:49] Moin moin [12:55] ackk: Thanks, responded [13:00] niemeyer: please start without me, I'm in a different meeting === ShalokShalom_ is now known as ShalokShalom [13:02] oh [13:02] standup [13:02] joining [13:06] zyga-ubuntu: hi, how are you today? [13:07] phil_m: hi [13:07] phil_m: I'm around [13:09] good. [13:09] just wanted to ask you about the current progress you made with Manjaro. [13:09] any news. some I should test on my end? [13:12] 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] phil_m: (on hardware, works in VM) [13:13] 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] zyga-ubuntu: ouch. [13:14] that is really sad to hear. [13:14] niemeyer, thanks. basically I think I only need a final decision about what is acceptable for listen-stream [13:18] niemeyer, how do i add an "ogra" tag in the forum (does that need you with admin rights ?) [13:18] ogra_: Yeah, not just me, but someone with permissions [13:18] phil_m: but no worries, all my patches are still in that VM so I didn't completely blow my data [13:19] 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] zyga-ubuntu: ok. makes sense [13:19] niemeyer, it is for https://forum.snapcraft.io/t/split-initrd-implementation/2224/1 [13:20] (allready has upcoming and will likelyy get more names on it) [13:20] niemeyer, thanks! [13:20] ogra_: Done, tag created [13:20] oh, gone again [13:20] ogra_: You should be able to use it now [13:20] k [13:21] yup, works [13:21] PR snapcraft#1568 opened: lxd: don't re-inject the same snaps [13:22] 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] Bug #1718942 opened: running favorited snap shows two icons in Ubuntu dock [13:52] zyga-ubuntu: I just created a new package of snapd with version 2.28dev+g0723493 [13:53] zyga-ubuntu: still face the error 'cannot locate the base snap: ubuntu-core: No such file or directory' on my end. [13:54] phil_m, weird, does it really still say ubuntu-core ? [13:54] phil_m, also ... did you see https://forum.snapcraft.io/t/snap-on-arch-liri-os/2223/1 [13:54] yep. [13:55] zyga-ubuntu: used files can be found here: https://github.com/manjaro/packages-community/tree/master/snapd-git [13:55] and the standard stable release at: https://github.com/manjaro/packages-community/tree/master/snapd [13:56] (funny that is seems to be kind of working with a few minor changes on liriOS but not on manjaro ... ) [13:57] maybe I should change PATH=$PATH:/var/lib/snapd/snap/bin:/snap/bin to just PATH=$PATH:/snap/bin [14:00] orga_: we already use: https://github.com/snapcore/snapd/commit/413a2a099dc57e3fb7c7e82a6c7250cf4c2f74fd [14:01] yeah [14:05] phil_m: hmmmmm [14:05] phil_m: we had a patch for that error message [14:05] phil_m: one sec [14:06] 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] Bug #1686481: stage-packages doesn't respect architectures [14:07] Or otherwise have any insight [14:08] phil_m: do you have 8c821c13bb62703c5119a1b0b1edbd53ce7f48aa in your tree? [14:09] let me check [14:10] no, will try some now. [14:13] PR snapd#3957 opened: cmd,dirs: treat "liri" the same way as "arch" [14:14] hmm, the error is gone, but now it simply hangs a while [14:14] chromium now started with a delay [14:14] well [14:14] second start was faster. [14:14] snaps typically coopy some stuff arund on first start [14:14] s thats kind of expected [14:14] seems it is now kinda working [14:15] \o/ [14:15] phil_m: is snapd running? [14:15] seems so [14:16] if the chroium snap runs it better should :P [14:16] now I only don't know if it is in /snap or in the /var/lib/snapd/snap [14:17] phil_m: what did you rebuild? [14:17] phil_m: can you please look at https://forum.snapcraft.io/t/snap-on-arch-liri-os/2223/4 [14:17] phil_m: using that source package (just with .6 and manjaro patch instead of liro patch) you should be mostly fine [14:17] will upload the changes soon === cachio_ is now known as cachio [14:38] mvo: done [14:40] Hey zyga-ubuntu [14:41] So, you're still seeking an Arch TU to collaborate with? [14:46] flexiondotorg: hey [14:46] flexiondotorg: yes, very much so [14:46] flexiondotorg: especially now with arch derivatives suffering from old package ther [14:48] flexiondotorg: do you have someone that could help? [14:49] Well, I've been reaching out to the main derivatives Manjaro and Antergos. [14:50] 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] flexiondotorg: thank you! [14:53] If I can get a sponsor, it will still be down to a vote and that takes a month [14:55] yes, I read the protocol [14:55] the best we can do though [14:55] I really wish timothy didn't abandon the package [14:55] but it seems he has [14:56] (also ignoring email) [14:56] Yep, I've tried contacting him too [14:57] maybe we could give him a ring via RH [14:57] Indeed😉 [14:57] "step down considerably" is not a virtue it seems [14:57] e [14:57] er [14:57] "resposibly" was it? [14:57] anyway [15:01] mvo: let me give it a whirl [15:02] zyga-ubuntu: I'll see if I can get a hold of tradelli [15:02] Pharaoh_Atem: thanks [15:03] zyga-ubuntu: he's in the Fedora community somewhat since he now works at Red Hat [15:03] Pharaoh_Atem: thank you! [15:04] Pharaoh_Atem: note that we made multiple attempts to contact him (irc, twitter, email, linkedin) and got no replies [15:04] (over extended amount of time) [15:04] zyga-ubuntu: I've talked to him a couple of times recently [15:04] his dead is down in the weeds in DPDK and kernel networking stuff [15:04] s/dead/head/ [15:04] jdstrand: thanks a bunch! I addressed your comments [15:05] Pharaoh_Atem: haha [15:05] he took over from Panu Matilainen when he returned to the helm of rpm development/maintenence [15:05] Pharaoh_Atem: DPDK? [15:05] Data Plane Developer Kit [15:05] from Intel, now a Linux Foundation project [15:05] does weird things to network subsystem to make things go fasterer [15:06] https://en.wikipedia.org/wiki/Data_Plane_Development_Kit [15:06] * ogra_ points to apt-cache show dpdk [15:07] magic [15:07] but basically, DPDK is terrible and sucks the life out of you [15:08] Pharaoh_Atem: it must pay well then [15:09] mvo: err, why is the spec in 2.28 branch telling me it's 2.27.5? [15:11] zyga-ubuntu: Manjaro now supports fully snaps [15:12] mvo: ah, you haven't been bumping the versions like you did for 2.27 during the rc development [15:12] I've tested the curren stable v2.17 and current dev series v2.28 [15:18] phil_m: \o/ !! [15:18] phil_m: excellent [15:18] phil_m: what kind of GPU do you have? [15:18] phil_m: and can you tell me more about your kernel [15:18] phil_m: (and can we add a logo with installation instructions to snapcraft.io?) === ikey|zzz is now known as ikey [15:22] you can add a logo and the instruction # pacman -Sy snapd when we released it also to our stable branches [15:23] I've an Nvidia gpu [15:23] phil_m: excellent, I'll make that happen! Thank you! :) [15:23] and the kernel is more or less vanilla with some patches added. [15:23] phil_m: do you have a preferred logo (quality, etc) I should use? [15:23] zyga-ubuntu: phil_m: can you open a bug with the logo? [15:23] https://github.com/manjaro/packages-core/tree/master/linux413 [15:24] is the current stable kernel [15:24] davidcalle: in which tracker should I open the bug? [15:25] https://github.com/canonical-websites/snapcraft.io-static-pages [15:25] Thanks phil_m :) [15:25] thank you both! [15:29] 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] Bug #1686481: stage-packages doesn't respect architectures [15:31] mvo: hey, did you see my followup comment on PATH_MAX? [15:31] mvo: also, think you need a go fmt [15:32] davidcalle: https://github.com/canonical-websites/snapcraft.io-static-pages/issues/387 [15:33] jdstrand: thank you for the instructive reviews! [15:33] mvo: can I merge https://github.com/snapcore/snapd/pull/3952 [15:33] PR #3952: cmd: update "make hack" [15:40] one more test... [15:49] 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] kalikiana, excellent, thank you very much :) [16:05] ARGH ! [16:05] my rocket snap just made my system get stuck [16:06] niemeyer, is it wanted that mup just sent ~1000 PR messages to #snapcraft on rocket ? [16:06] ogra_: I hope you know the answer to that :) [16:06] heh [16:07] well, something is weird [16:07] ogra_: IIRC mup was actually disabled there [16:07] yeah [16:07] ogra_: Someone is probably fiddling with settings [16:07] thats what i meant with weird :) [16:08] 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] seems to have stopped now [16:08] kalikiana elopio how about a look on snapcraft#1565 ? [16:08] PR snapcraft#1565: cli: add the assemble command [16:08] ogra_: Probably someone just flipped the switch enabling it [16:08] yep, for a minute or two and it replayed some caxche i guess [16:21] sergiusens: You got some comments [16:25] looks like manjaro landed snap support [16:25] the commune groweth [16:31] ikey: indeed :) [16:33] looks like everyone is getting on the bandwagon now [16:33] * ikey likes cascading self ordering chaos [16:49] ikey, zyga-ubuntu: Nice! === alan_g is now known as alan_g_ [16:52] nacc, i guess kyrofa would know more about that ;) [16:52] (and i'm saying this here because he isnt in #ubuntu-release= [16:52] ) [16:53] :) [16:55] ogra_: ack :) [16:57] zyga-ubuntu: I think so [16:58] jdstrand: yeah, I fixed that, thanks and sorry :) [16:58] Pharaoh_Atem: I can push with 2.28~rc4 if you want [16:58] PR snapd#3952 closed: cmd: update "make hack" [17:01] mvo: thanks! [17:07] mvo: thank you [17:15] mvo: I'm testing to see if the new cheggaaa-pb package works without the hack atm [17:15] Pharaoh_Atem: thanks [17:15] 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] 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] nacc, ogra_ I seem to be missing the scrollback that contains context. What would I know more about? [18:06] kyrofa: it's mostly in #ubuntu-release [18:07] kyrofa: let me get the linnk [18:07] Haha, well that would explain the missing context [18:07] https://irclogs.ubuntu.com/2017/09/22/%23ubuntu-release.html [18:07] kyrofa: exec. summary: 1) snapcraft dep8 tests are broken on artful 2) artful builds of snaps are broken [18:08] aiui, the solutions are multiple: 1) snapcraft dep8 should use cleanbuild [18:08] man, travis and github don't love me today [18:08] 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] network isuses [18:08] Yes indeedy, that's not surprising at all [18:09] 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] now that won't fix artful builds of snaps, as they still have a xenial core snap and there be dragons [18:10] but it means the libc issue that's currently busted would work, i think [18:10] s/would work/would not manifest itself/ [18:11] Sorry guys, I didn't realize that was a room in which I should idle [18:11] Rectified now [18:11] kyrofa: we probably should have brought the convo here [18:13] nacc, so yeah, snapcraft crawls prime and essentially sucks over any libs it discovers via ldd on every elf [18:13] nacc, it ships the libraries/16.04 file as a blacklist of stuff in the core snap to NOT suck over [18:14] But of course, it checks the OS before deciding whether or not to use libraries/16.04, or libraries/16.10, etc [18:14] The latter of which doesn't exist [18:14] Thus nothing gets excluded, and it sucks everything off the host [18:14] kyrofa: yep that was my analysis from the source as well [18:15] kyrofa: since snapcraft's dep8 is runnig natively on artful, it didn't find any blacklist file [18:15] 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] kyrofa: ouch :/ [18:15] 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] 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] Yes and yes. Agreed [18:16] I happened to get built by the latter before the former was seen, I guess :) [18:16] any good snap apps? [18:17] I really don't think we should just remove the feature though, or current snaps will stop working [18:17] So we probably need to invest some time in improving it [18:17] we should make snaps use system fonts and theme [18:17] 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] kyrofa: but like you said, that's insufficient on its own [18:18] i'm also switching my snap to build on xenial (presuming the tests pass :) [18:20] ogra_, if I install a snap on artful, what core snap am I getting? The 16 one, right? [18:21] 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] kyrofa: yes [18:22] 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] There's no solution to this problem! [18:22] :P [18:22] kyrofa: yeah, this is all pretty buggy (building on artful) until we get base snaps [18:22] Yep [18:22] that's why, honestly, it should be disabled (but there's no way to communicate that effectively it feels like) [18:22] it's just guaranteed to have weird failures eventually :) [18:23] nacc, well, like I said, even if it was disabled, building on artful won't result in a snap that runs [18:23] kyrofa: no, i mean, don't allow buildig on artful :) [18:23] at least not via LP [18:23]