[01:14] jdstrand, I needed to push an update to the dragonboard-turtlebot-kyrofa gadget snap if you could take another look (changing the arch. For some reason the official one is armhf... ?) [03:35] * mwhudson looks at the task of shuffling three releases and six architectures into tracks === chihchun_afk is now known as chihchun === JanC is now known as Guest92965 === JanC_ is now known as JanC [06:58] PR snapd#3090 closed: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker [07:01] PR snapd#3099 opened: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker [07:16] morphis: yo [07:16] Son_Goku: hey! [07:17] ugh, I hate being up this early, but w/e [07:17] once I'm up, I'm up [07:18] :-) [07:19] morphis: did you do your initial import of the golang packages yet? [07:26] Son_Goku: its on my list for this morning [07:32] morphis: the sooner, the better ;) [07:32] yeah [07:33] Son_Goku: first one builds for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=18657838 [07:34] shit, you didn't import for F24, too? [07:35] according to pkgdb, you only requested branches for Rawhide, F26, and F25 [07:36] Son_Goku: should I? [07:36] yes [07:36] I expect to be able to build snapd at least ONCE for F24 [07:36] ok [07:36] let me change that [07:37] Son_Goku: however, I get "BuildError: package golang-gopkg-retry not in list for tag f27-pending" [07:37] any idea? [07:38] not really, no [07:38] https://koji.fedoraproject.org/koji/taskinfo?taskID=18657838 [07:38] you might want to pop into #fedora-releng and ask about it [07:39] Son_Goku: done [07:41] Son_Goku: I maybe have an idea .. [07:50] Son_Goku: my fault, should be fixed now [07:51] morphis: did zyga show you how fedpkg workflow is supposed to work? [07:51] Son_Goku: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Import.2C_commit.2C_and_build_your_package is what I am using [07:52] okay, good [07:54] Son_Goku: but it doesn't tell if the package is now directly available in rawhide or not, just that I need to use bodhi for anything !rawhide [07:55] for rawhide (which currently is f27), it will automatically transition f27-pending -> f27 [07:55] ok [07:55] for branched releases, (f26 and below), it will transition from fXX-pending -> fXX-update-candidate [07:56] from there, you need to use "fedpkg update" to make them available [07:56] Son_Goku: ok, let me get builds for f26-25 [07:56] the pending tags refer to pending the packages being signed with the Fedora GPG key [07:57] in RPM distributions, we sign the packages themselves, so that they are cryptographically verifiable no matter how you got the package [07:59] uhh [07:59] morphis: you messed up golang-gopkg-retry-v1 [07:59] https://koji.fedoraproject.org/koji/rpminfo?rpmID=9416927 [07:59] how? [07:59] look at the Provides [08:00] %{import_path_sec} ? [08:00] yeah [08:00] you used a macro that's not defined [08:00] hm [08:00] time for an update then :-) [08:01] incidentally, please don't do commit reverts [08:01] you can just incrementally commit like any other git repo [08:02] Son_Goku: isn't that what I do with a revert? but ok if that is considered a bad practise [08:02] well, for imports it's bad [08:02] because then no one can tell the actual change in the spec you did [08:03] btw, why does this obsolete gocheck? [08:04] morphis: I think you forgot to remove some stuff :) [08:04] yeah [08:05] Son_Goku: didn't we go through the review process :-) [08:05] you didn't tell me you didn't generate it with gofed [08:06] I don't look too much into gofed-generated specs because they're complex and usually correct [08:07] Not this one, the gettext one is; this one didn't pass gofed because its using gopkg.in and has two identities [08:07] Son_Goku: however, look at the top two commits in http://pkgs.fedoraproject.org/cgit/rpms/golang-gopkg-retry-v1.git/ [08:08] looks good to me now [08:09] lets see what the build says [08:09] you'll need to bump the release [08:09] and add to the changelog [08:09] once a successful koji build has occurred, you can never reuse the EVR again [08:09] yeah on that already [08:21] Son_Goku: f24 branches are there now too [08:34] PR snapd#3100 opened: tests: fix interfaces-cups-control for zesty (#3035) [09:03] kyrofa, indeed it should, but since it is full of binaries and ubuntu-image doesnt complain it does technically not matter if it is armhf ... thanks for the pointer though [09:12] PR snapd#3099 closed: configstate,hookstate: timeout the configure hook after 5 mins, report failures to the errtracker [09:22] morphis: hey, can you please have a look at https://github.com/snapcore/snapd/pull/3095 [09:22] PR snapd#3095: cmd/snap-update-ns: add C preamble for setns [09:24] zyga: mixing C and Go like this seems like it'd make things worse rather than better [09:55] zyga: sure [09:56] morphis: thanks [09:58] PR snapd#3100 closed: tests: fix interfaces-cups-control for zesty (#3035) [09:58] zyga: so why are we mixing C and Go code here? [09:59] morphis: because go cannot do what we want [09:59] morphis: see the comment up fron the bootstrpa.go [09:59] bootstrap.go [09:59] morphis: if go had any control over threads we could [09:59] morphis: but alas, no [10:01] ah I see you use a constructor [10:01] tricky .. [10:01] was searching the actual call to bootstrap from the Go code [10:05] morphis: yes, it's tricky but that's the only way we found to achieve this [10:06] is that a limitation of setns? [10:06] or a bug? [10:06] morphis: note that this is the 2nd approach [10:06] morphis: it's a feature, that's how setns is documented to work [10:06] I see [10:06] morphis: the 1st approach was all-C but the complexity of the code kept growning [10:06] morphis: and we had 1000s of lines of tests and code that would be far far shorter in go [10:07] PR snapd#3029 closed: snapstate: introduce helper to apply to disk a alias states change for a snap (aliases v2) [10:10] zyga: reviewed [10:15] Son_Goku: https://koji.fedoraproject.org/koji/rpminfo?rpmID=9416966 looks much better [10:15] yep [10:28] Son_Goku: let me get builds for everything else [10:29] morphis: thank you :-) [10:29] * zyga has stuff to do now [10:29] zyga: np [10:31] zyga: btw. I see my deb builds for snapd failing because my shellcheck on xenial does not know about -x [10:34] zyga: looks like you changed that recently [10:38] zyga: is it intended that shellcheck isn't pulled in for the deb build? [10:39] morphis: ah, I noticed that too [10:39] morphis: yes, shellcheck is absent on 14.04 and I think it's not that critical anymore [10:39] morphis: we have less and less shell code [10:39] zyga: however with it installed the tests fail for me :-) [10:40] morphis: yeah, we'd have to check if shellcheck groks -x [10:40] PR snapd#3101 opened: cmd: explicit use of snapd sockets (for 2.23) [10:40] morphis: but I was too lazy to do that TBH (at the time) [10:40] zyga: ok, so we should have an explicit --disable-shellcheck in debian/rules until we have that [10:40] as otherwise a shellcheck present on the build host causes the build to fail [10:42] morphis: well, that's also too much, just DTRT or remove shellcheck [10:42] morphis: I wonder if shellcheck sans -x is actually useful [10:43] morphis: maybe just check if shellcheck exists *and* supports -x [10:43] morphis: than again, maybe not, -x is needed for out-of-tree builds AFAIR [10:45] for now I removed shellcheck from my host but actually this is a problem we need to fix one or another way [11:12] ppisati, i have added a linux-raspi2 task to bug 1674509 ... seems the documented overlays that should switch UARTs for BT use do not work [11:12] Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16

[11:20] I don't seem to be able to run any graphical snaps on OpenSUSE Tumbleweed [11:21] zyga, ^^ ? [11:21] For example when trying to run keepassxc I get: [11:21] * LinAGKar sent a long message: LinAGKar_2017-03-29_11:21:22.txt - https://matrix.org/_matrix/media/v1/download/matrix.org/NYEoBtzLLcrJlbDYTqgPCHzA [11:29] LinAGKar, is the x11 interface connected for the app ? perhaps SuSE doesnt auto-connect it ... check with "snap interfaces" [11:31] It says: [11:31] :x11 dwarf-fortress,keepassxc [11:53] Son_Goku: which karma level should I set for my bodhi requests? [11:54] morphis: "1" [11:55] new packages can't possibly have any terrible effect on things, so setting stable karma to "1" is fine [11:55] ok [11:55] both for stable and unstable? [11:55] morphis: for all branches you're making a bodhi update to, yes [11:56] it should be 1 / -3 for the autokarma settings [11:57] King_InuYasha: thanks! [11:59] ogra_: hey, who had issues with X/Display? [12:05] Son_Goku: ok, bodhi requests are out now; added all in https://docs.google.com/document/d/1l9xS8RqSSjASNEIcHAOanlURNrpmfodf4Fd79QXdLG4/edit [12:13] zyga: I did [12:17] PR snapd#3052 closed: overlord: remove snap config values when snap is removed [12:18] PR snapd#3102 opened: interfaces/mount: add function for parsing mount entries [12:23] zyga, morphis: if you've tried the new build of golang-github-go-tomb-tomb like I have, you can leave positive feedback+karma to get the ball rolling: https://bodhi.fedoraproject.org/updates/?packages=golang-github-go-tomb-tomb [12:23] King_InuYasha: sounds good! [12:27] LinAGKar: hey [12:27] LinAGKar: sorry for the lag, I was away [12:27] LinAGKar: can you tell me more [12:27] LinAGKar: I suspect you use KDE, is that correct? [12:28] King_InuYasha: I'll try it back in the office, I didn't bring my VMs on the road today [12:29] * ogra_ imagines zyga to have a bag with VMs in them ... [12:30] ogra_: really a HDD [12:32] Hi [12:33] zyga: I do use KDE [12:35] zyga: When I try to run keepassxc I get: [12:35] No protocol specified [12:35] QXcbConnection: Could not connect to display :0 [12:35] Avbruten (SIGABRT) [12:35] Or for dwarf-fortress I get: [12:35] Gtk-Message: Failed to load module "canberra-gtk-module" [12:36] No protocol specified [12:36] Display not found and PRINT_MODE not set to TEXT, aborting. [12:37] PR snapd#3103 opened: interfaces/mount: add function for parsing fstab-like file [12:38] This is on OpenSUSE Tumbleweed, with snapd from the snappy OBS repo [12:40] oh, seems like it builds on opensuse now. interesting, that's why I originally joined this channel. thanks for the info, LinAGKar [12:41] zyga: From snap interfaces I get this: https://pastebin.com/vqLxV0zd [12:46] niemeyer: does snapd's sources offer an API for things to build off of? [12:47] as a golang library, I mean [12:47] Son_Goku: Heya [12:47] Son_Goku: Yeah, let me get you a link [12:47] hey [12:47] Son_Goku: https://godoc.org/github.com/snapcore/snapd/client [12:57] LinAGKar: thanks, I think I know what this is about [12:57] LinAGKar: can you check if you have /tmp/.Xauthority file? [12:58] morphis: ^^ [12:58] LinAGKar: (sorry for being disconnected earlier) [12:58] zyga: I do not have that [12:59] PR snapd#3104 opened: tests: fix unity test [12:59] LinAGKar: hmm, curious [13:00] LinAGKar: ok, which distribution relaease are you on? [13:05] zyga: Tumbleweed, it's rolling release [13:06] zyga: I've got snapd built on Fedora for rawhide locally [13:06] 2.23.5 [13:06] with nine patches [13:08] hi, for snappy config schema, am i right to assume that eventually i'll be able to snap install xyz with a specific config schema, in order to set specific configs at install time? [13:17] LinAGKar: Ack, can you please report a bug on the systems:snappy repository [13:17] LinAGKar: we'll try the KDE build and debug it [13:18] LinAGKar: (I was using gnome out of habbit) [13:18] Son_Goku: anything serious? [13:18] Son_Goku: try out some snaps if you can [13:18] Son_Goku: but this feels like something that we will release soon [13:18] I will, but I have to go to work first :) [13:18] zyga, could it be that our xauth setup is a bit more losely defined than suses ? iirc we have a pretty lose setup for localhost [13:18] Son_Goku: understood, thank you, a *lot* :-) [13:18] ogra_: yes, perhaps [13:18] ogra_: but I remember seeing something that fails in KDE [13:18] ogra_: but works in GNOME [13:19] yeah, might not be that [13:19] Son_Goku: FYI: https://forum.snapcraft.io/t/towards-working-snap-update-ns/23 :-) [13:20] ogra_: because I checked tumbleweed in gnome and it was all good [13:20] right, was just a thought [13:21] zyga: I'd like to have most of these patches merged in some form in an upstream release :/ [13:22] by the way, I don't see a PR or a commit resembling the change for making snap-confine internal lib use libtool? [13:22] Son_Goku: I have that patch in suse, I'll try to merge it buuut we may not be able to [13:22] Son_Goku: because there's another PR that adds fine-grained control (per lib) of what to link in statically [13:23] so that PR will supersede it? [13:23] Son_Goku: anyway, I'm sure morphis will have a lot of fun upstreaming that :) [13:28] zyga: Bug report here: https://bugzilla.opensuse.org/show_bug.cgi?id=1031501 [13:28] PR snapd#3098 closed: cmd: select what socket to use in cmd/snap{,ctl} [13:29] PR snapd#3101 closed: cmd: explicit use of snapd sockets (for 2.23) [13:31] Son_Goku, zyga: I am working through sorting all these patches so only have a minimal set downstream in the distributions [13:31] that is also highly necessary to be able to build packages later on in CI [13:31] morphis: can you please look into that bug ^^ [13:31] morphis: thanks for working on the patches! [13:32] * zyga needs to get into the car, brb [13:32] zyga: will do [13:33] morphis: https://github.com/Conan-Kudo/snapd/commit/ad2f6b49603b920b7de13b0431587857d31aca86 (clean), https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/tree/snapd-pkg-dev (actual tree) [13:33] Somebody here? [13:33] I need help [13:34] I wanted to install deepin music player in linux mint 18.1 [13:34] morphis: if it passes my basic sanity tests (that is, I can run some dead-simple snaps), then I'll prepare the update today [13:34] Son_Goku: 0008, 0007 can be dropped once we have 2.24 [13:35] Son_Goku: awesome! [13:35] Son_Goku: 0006 too [13:35] patches 0001, 0004, 0007, and 1001 have not been merged in some form [13:35] @Morphis can you help me [13:35] Vktn: No such command! [13:36] Son_Goku: for 0007 there is a PR [13:36] Buddy the thing is I am installing in snap form [13:36] Son_Goku: https://github.com/snapcore/snapd/pull/3096 [13:36] PR snapd#3096: many: abstract path to /bin/{true,false} [13:36] morphis: I'm aware, see comments :) [13:37] Son_Goku: don't see any on that PR :-) [13:37] Its stuck on "run configure hook of core snap if present" [13:37] Vktn: what is the problem you have? [13:37] look at my gitlab repo spec file: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec [13:37] Vktn: on which distribution you see this problem? [13:38] Linux mint 18.1 [13:38] Son_Goku: ah good [13:38] I know snap is not completely supported [13:38] Vktn: you seem to be running into a bug we're currently fixing [13:38] But I still tried to install by first installing package snapd as suggested by someone on reddit [13:39] Ok thanks buddy [13:39] It would be helpful if you give me some more information [13:39] Is it just because of linux mint [13:39] ? [13:40] Vktn: no, it's because snapd comes from Ubuntu for mint [13:40] and the bug affects ubuntu [13:41] Ok thanks buddy :) [13:41] Somebody's also having same problem on mail-archive.com [13:41] PR snapd#3105 opened: tests: download previous snapd package from published versions instead of specific PPA [13:42] Son_Goku, we rolled back the affected core snap in the stable channel [13:42] Son_Goku: not necessarily, this is more what we see where AppArmor doesn't work [13:42] so nobody should actualyl see it unless they are not using stable [13:42] mvo: niemeyer: do you think I can reapply the bits of my overlord reorg that I reverted to help with 2.23.6 ? I need to make snapstate changes and I think they would be better done after that is reapplied [13:43] https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02782.html [13:44] ogra_: I feel this is more https://bugs.launchpad.net/snappy/+bug/1674193 [13:44] Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel [13:44] pedronis: Can you open a topic for that with details? [13:44] morphis, ah, right, there were two issues [13:45] pedronis: (what PRs, etc) [13:45] ogra_: right, so in this case we run into the problem that the configure hook calls snapctl [13:45] and AppARmor + Seccomp are enabled for the snapd package in Mint [13:45] yeah, i remember [13:45] so snapctl gets killed by seccomp [13:46] ogra_: and https://github.com/snapcore/snapd/pull/3101 is what should fix this [13:46] PR snapd#3101: cmd: explicit use of snapd sockets (for 2.23) [13:47] ogra_: however in cases like Mint we now have the problem that people run into this problem still and I don't see a clear migration path [13:47] yeah [13:47] well, update snapd is obviously the path :) [13:48] we just need to release it [13:48] ogra_: yes [13:51] ogra_: and problem is that we can even recommend manually adding bind to the seccomp profile as it will be regenerated on every core snap updated .. [13:51] Vktn: we're about to release snapd 2.23.5 which will fix that problem which mainly is one on distributions having AppArmor disabled and seccomp on which is the case for Mint [13:52] morphis: anyway, while I'm at work, please work on trying to get the patch situation resolved: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec#L49-65 [13:52] morphis: note https://github.com/snapcore/snapd/pull/3101 is the proper fix for this [13:52] PR snapd#3101: cmd: explicit use of snapd sockets (for 2.23) [13:52] morphis: and https://github.com/snapcore/snapd/pull/3098 [13:52] PR snapd#3098: cmd: select what socket to use in cmd/snap{,ctl} [13:53] morphis: also leave feedback for the golang-github-go-tomb-tomb package in bodhi [13:53] jdstrand: right, but will not help people being blocked by the bug it fixes right now unitl 2.23.6 lands [13:53] morphis: both merged now [13:53] * jdstrand nods [13:53] Son_Goku: sure but we wont get them all in for 2.23.x [13:53] we can drop them with followup upstream releases [13:53] morphis: I just want them all in master [13:53] morphis: but it is nice that a simple core update will resolve it [13:54] Son_Goku: before we release a package to fedora? [13:54] that's all I meant [13:54] morphis: yes it's fine [13:54] jdstrand: yes [13:54] morphis: well it doesn't matter about that [13:54] * jdstrand hugs mvo for fixing that and the noisy denial in on shot [13:54] but ideally I need something for documenting all the patches [13:54] morphis ^ [13:54] snapd moves too quickly for out of tree patches to be sustainable [13:55] +1 [13:55] we only have on left so I will take care [13:55] so at the minimum, I need PRs [13:55] ideally, they would all be merged into master :) [13:56] anyway, g2g [13:56] bye [13:56] Son_Goku: o/ [13:56] zyga: hi [13:56] zyga: quick catchup: I need at least all patches listed here to have PRs: https://gitlab.com/Conan_Kudo/fedorapkgs-snapd/blob/snapd-pkg-dev/snapd.spec#L49-65 [13:56] ideally, all of those should be merged in master [13:57] I do not mind carrying patches, I do mind carrying them forever [13:59] Son_Goku: if you just need a PR, that's a minute work :-) [14:00] morphis: at LEAST a PR [14:04] PR snapd#3106 opened: tests: enable docker test for more ubuntu-core systems === vigo is now known as vigo|lunch [14:21] * mvo hugs jdstrand for his excellent analysis of the problem [14:21] going ahead (https://forum.snapcraft.io/t/finish-overlord-reorg-to-enable-further-work/37/3) [14:24] ogra_, if you use snapcraft to build and then release, it ends up in the armhf set of channels, which means when you use ubuntu-image to build (and specify arm64), ubuntu-image doesn't find it. Are you building in a different way? [14:25] nope, weridly it pulls the right stuff from the store for me [14:25] kyrofa, you are using https://github.com/snapcore/dragonboard-gadget right ? [14:26] ogra_, indeed [14:26] oh, and i see you changed it there [14:26] ogra_, well, I _offered_ to change it there ;) [14:26] * zyga goes to pick up kids from school [14:26] yeah, mvo was fast and already merged it [14:27] Oh nice. I haven't gone through my emails yet [14:27] ogra@dragonboard:~$ snap info dragonboard|grep refresh [14:27] refreshed: 2016-10-28 13:04:19 +0200 CEST [14:27] ugh [14:28] * ogra_ notes that we have actually never used the GH one then [14:30] so tomorrows dragonboard edge image will be interesting :) [14:31] Ha! === vigo|lunch is now known as vigo [14:34] PR snapd#3107 opened: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" [14:40] jdstrand, crap does unity8 trigger manual review? I added it back thinking it was ok now === ogra_ is now known as ogra [14:41] pmcgowan: yes, it is reserved for Canonical employees [14:41] "The 'unity8' interface is in development and not yet ready for production. Please remove from your snap's plugs and feel free to reupload. After that your snap should pass automated review." [14:41] that is what we say to non-Canonical ^ [14:42] jdstrand, ok but I need to wait for a review now? would be happy to reupload [14:42] pmcgowan: you are a Canonical employee. you can either remove it, or I can add a snap decl [14:42] note if I grant it, you'll get an email that says "Granting use of the 'unity8' interface to Canonical employee. Note that this interface is not complete and subject to break applications at any time." [14:43] :) [14:43] :) [14:43] let me remove it and re-upload jdstrand === ogra changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug, join the snapcraft discussion https://rocket.ubuntu.com/channel/snapcraft | Join the forum: https://forum.snapcraft.io [14:45] mvo: niemeyer: proposed https://github.com/snapcore/snapd/pull/3107 [14:45] PR snapd#3107: overlord: finish reorg, revert "be more conservative until we have cut 2.23.x" [14:45] jdstrand, how do I get those out of the review queue? I rejected the first one [14:47] PR snapd#3108 opened: cmd: use libtool for the internal library [14:47] rejected them all then [14:48] pmcgowan: ok. yeah, there is a mechanism in the web frontend of the store to reject them that it seems you found === ChanServ changed the topic of #snappy to: Join the forum: https://forum.snapcraft.io/t/when-to-use-forum-vs-irc/38 [14:52] err === ogra changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug, join the snapcraft discussion https://rocket.ubuntu.com/channel/snapcraft | Join the forum: https://forum.snapcraft.io === chihchun is now known as chihchun_afk [14:59]