[00:14] any word on installing snappy in centos7? [00:14] i saw a few bug report notes but nothing to indicate i could use it [00:30] soo [00:30] i have a snap with a plugin [00:30] the plugin depends on pyelftools [00:30] i have python3-pyelftools in my snap's build-packages [00:31] if i build with the dpkg snapcraft, this works fine [00:31] but if i build with a snapped snapcraft, the plugin can't import the dependency [00:31] any ideas? [00:53] mwhudson yeah, does it use ctypes? If that is the case, we have a patched up library finder [00:53] sergiusens: no [00:53] sergiusens: the games this plugin is up to will stop being relevant when classic snap creation gets fixed properly though :) [00:53] mwhudson oh, this is like a venv ignoring system packages [00:54] sergiusens: yes, i guess so, i think the PYTHONPATH for the snapcraft process only includes things from the snapcraft snap, and the plugin runs in the same process so... [00:55] mwhudson yeah, we don't set any PYTHONPATH though, we just rely on the default sys.prefix setup by python itself [00:59] sergiusens: well ok [00:59] i guess the general case is "how do i write a plugin that has an external (python) dependency" [00:59] maybe the answer is "don't do that" [01:33] kyrofa, I was taking a look at the issue and now my problem is something else. Is there a variable with the value Snapcraft I can get to pass in to %(prog)? [06:08] morning === chihchun_afk is now known as chihchun [06:36] PR snapd#4372 closed: snap: YAML and data structures for app before/after ordering [06:38] PR snapd#4352 closed: tests: increase amount of workers for ubuntu-16.04-64 by one === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:40] mvo: morning [07:41] hey mborzecki [07:49] mvo: have you seen #4326 maybe? [07:49] PR #4326: interfaces/builtin: blacklist zigbee dongle [07:51] i wonder if there's a way to ship extra udev rules with such quirks as separate files read at runtime rather than embedding them in snapd code [07:51] mborzecki: I have seen it but didn't pay close attention (yet) [07:51] mborzecki: right, thats a gustavo topic, we discussed this a long time ago and then the conclusion was that we want it centralized for now [07:52] mborzecki: but "now" maybe well be past now, especially when there is a compelling use-case [07:52] the thing fixed in the pr seems to be a workaround for a very specific hardware [07:53] wouldn't be surprised if that's even some engineering unit that reports bad vid/pid (not like i haven't seen things like such things in the past) [07:55] morning [07:55] * kalikiana coffee [07:58] PR snapd#4376 opened: tests: fix external backend for tests that need DEBUG output [07:58] mborzecki: *nod* no disagreement, we need to discuss with gustavo [07:58] mvo: https://forum.snapcraft.io/t/refresh-time-should-next-conform-to-core-api-schedule/3088 weekday schedule is not supported right? [07:59] mborzecki: correct, the current snapd only supports settings inside the 24h window [08:00] mborzecki: your work will fix this :) [08:00] mborzecki: feel free to reply and pitch your branch [08:00] mborzecki: the fact that this it not rejected outright is a bug that I think we fixed in 2.30 [08:09] thanks :) [08:17] pstolowski: morning [08:17] mborzecki, hey! [08:22] hey pstolowski ! [08:27] hm we really should be doing `set -e` in all scripts [08:27] /home/gopath/src/github.com/snapcore/snapd/tests/lib/mkpinentry.sh: 3: /home/gopath/src/github.com/snapcore/snapd/tests/lib/mkpinentry.sh: MATCH: not found [08:27] this script is ran instead of being sourced in the tests [08:32] mborzecki, sounds sensible to me [08:34] mborzecki: +1 [08:34] or we could tweak spread to write MATCH to ~/.bashrc even if not runnig with -shell or -debug [08:37] PR snapd#4377 opened: tests/main: source mkpinentry.sh [08:37] PR snapd#4378 opened: tests: do not disable refresh timer on external backend [08:39] * mvo runs the full pi3 validation after fixing the known issues === __chip__ is now known as Chipaca [09:22] PR snapd#4379 opened: client: send all snap related bool json fields [09:56] pstolowski: ping [09:56] Chipaca, hey [09:56] pstolowski: hiya [09:57] pstolowski: what's required of a hook in order for a user to run it? unix permissions wise [09:57] pstolowski: are hooks run as root, or as the user? [09:58] Chipaca, they are run by snapd, so root === chihchun is now known as chihchun_afk [10:01] pstolowski: pedronis: if you think of anything further we should do on https://forum.snapcraft.io/t/incorrect-permissions-in-meta-snap-yaml/1161/7 please raise it there [10:09] mborzecki: hey, mind if I write a tiny snap-mgmt test? its the perfect task while waiting for a pi3 execution of tests. or have you started already? [10:10] mvo: go ahead, i haven't started working on it yet [10:11] mborzecki: great, will push a PR in some minutes [10:12] Chipaca: we should ping jdstrand to have checks like that in review-tools [10:12] snapd is useful but very late here [10:16] mborzecki, #4357 looks very nice, but one question [10:16] PR #4357: wrappers: autogenerate After/Before in systemd's service files for apps [10:17] pstolowski: thanks for the review [10:26] PR snapd#4380 opened: tests: add simple snap-mgmt test [10:31] i'm adding those workarounds for /dev/random running out of entropy, but gpg called in snap create-key is smart, looks like it's using the real random device anyway [10:32] mborzecki: woah, annoying [10:35] pedronis: the whole stack should check, yes [10:56] mvo: right, so there's a gpg agent, and it seems that it's started while proper /dev/random is still around [11:00] mborzecki: yes, if the distro is usigng gpg 2.x [11:01] it can be restarted though (don't know the exact incantation) [11:17] pushed a fix with `pkill -e gpg-agent`, i tried `gpgconf --kill gpg-agent` but that wasn't reliable at all [11:41] kyrofa: seen https://bugs.launchpad.net/snapcraft/+bug/1736963 ? [11:41] Bug #1736963: "snapcraft enable-ci travis" won't accept my password [11:41] kyrofa: i was writing some simple travis docs but fail because that command is broken [11:49] mborzecki: nice find! [12:32] * kalikiana need to take a short break [12:59] pedronis: as it happens, the review-tools have a check for the config hook, but not the other hooks [12:59] * jdstrand adds a note to update them for the others [13:22] * sergiusens waves from a holiday [13:22] Bug #1732555 changed: Installing bad snap has snapd crashing [13:22] elopio the register thing is broken now on the fakes [13:27] PR snapd#4363 closed: cmd/snap-mgmt: add more directories for cleanup and refactor purge() code [13:28] sergiusens: what are you doing here then, you should enjoy your day off :-P [13:34] Bug #1723974 changed: snap client doesn't work with Croatian language/characters [13:34] mvo: I was looking at this code: https://github.com/snapcore/snapd/blob/master/tests/main/auto-refresh/task.yaml#L21 the if doesn't make sense anymore, right? also refresh.disabled is not used either? [13:37] Bug #1722882 changed: Ubuntu Core 16: Error: cannot refresh "pi2-kernel": snap "pi2-kernel" has changes in progress [13:38] Chipaca: is architectures mandatory in snap.yaml? [13:39] pedronis: correct, the "if" can be killed and the disabled=false can also be killed. will you do that or shall I push a PR? [13:39] mvo: I can do in my upcoming PR, I'm creating a auto-refresh-private test [13:39] that will be similar [13:40] pedronis: thank you [13:41] PR snapd#4368 closed: tests: fix security-device-cgroups-serial-port test for rpi and db [13:43] jdstrand: re 4100> I'm inclined to merge it, gustavo is not around for a re-review but it looks like you addressed his comment. what is your feeling about it? good to go in ß [13:43] ? [13:49] Bug #1717857 changed: UDisks2 interface restricts sending DBus.Properties.Get message from the client to udisksd service [13:49] Bug #1717900 changed: Confined snap fail for user with homedir in /var/lib [13:52] Bug #1718026 changed: Applications from installed snaps don't appear in activities overview [13:55] How do I see the last changes on a snap (ie. paintsupreme-3d ) ? [13:55] Bug #1717375 changed: snap find behaviour? [14:03] PR snapd#4377 closed: tests/main: source mkpinentry.sh [14:07] * kalikiana lunch time [14:10] PR snapd#4381 opened: interfaces: add /proc/partitions to system-observe [14:16] jdstrand: have you seen this discussion: https://forum.snapcraft.io/t/snap-rejected-because-of-use-of-browser-support/3089/8 ? [14:23] jdstrand: fwiw, I work on fixing the failures in 4374 now [14:30] elopio: is this still a bug, if so, can it please be made into a bug report? https://forum.snapcraft.io/t/go-homedir-reads-etc-passwd-not-home/2727 [14:32] segiusens: I'll update the fake [14:32] popey, I need to find the log changes in this snap : https://uappexplorer.com/snap/ubuntu/paintsupreme-3d how do i do that ? [14:32] Log changes? [14:32] right - to see if its been updated. [14:33] popey: it depends very much on how to define a bug. I will report one [14:33] elopio: lemme have the bug number pls [14:35] all I see is this & I've forgotten how to see that yaml changes :( http://paste.ubuntu.com/26139743/ [14:35] what changes are you expecting to see? [14:36] well I asked the developer by email last month that it didn't work on xubuntu 17.10 & debian - just wondering if they'd worked on it since ? [14:37] doesn't look like it. "snap info " [14:38] only two revisions in the store [14:46] popey, thankyou for helping me track changes, popey :) [14:46] np [14:46] Bug #1707474 changed: FTBFS on i386: incompatibility with new xfsprogs [14:49] Bug #1701510 changed: Unbind brcmfmac_sdio crashes netplan [14:51] * diddledan ninja-cuddles people as they walk by [15:00] re [15:00] diddledan: :-o [15:10] some of the 2.30 targeted PRs need a second review, if someone could have a look, that would be great [15:13] Bug #1705486 changed: SPI not working on Raspberry Pi with ubuntu core [15:14] PR snapcraft#1799 opened: tests: update the registered snap fake [15:16] ogra_: 1689037 is assigned to you, are you still happy that this is assigned to you? [15:16] Bug #1686852 changed: Can only run hello snap as root [15:19] Hi. I'm struggling to see why a git repo isn't being cloned by snapcraft. My snapcraft.yaml is at http://paste.ubuntu.com/26139967/ and the output is at http://paste.ubuntu.com/26139961/. What have I done wrong? [15:19] Bug #1684525 changed: panic: assignment to entry in nil map [15:21] I don't know if it is anything to do with the "nil" plugin type but the same error happens if I change it to "make" [15:33] mvo: oh, I'm already doing that [15:33] mvo: shoot. did you do it already? [15:34] (that is why I didn't respond immediately) [15:34] popey, thanks for the ping, I'll take a look [15:35] jdstrand: meh, yes, all fixed already, sorry for the ocd, I still hope to push a new 2.30~rc3 tonight thats why I pushed hard on this [15:35] mvo: right, well, I was pushing hard to get all the stuff in too [15:35] :( [15:35] sorry [15:35] ok, well, let me sync and see what happens [15:35] mvo: no, thank you. sorry I didn't see the ping [15:40] mvo: restarted release/2.30 travis build, snap store returned 418 in tests/main/interfaces-snapd-control-with-manage [15:40] mborzecki: thank you [15:42] mvo: i'm also looing at #4100, https://github.com/snapcore/snapd/pull/4100/files#diff-67fc5f3eff966220ca21940106198de5R96 this is just for future reference, right? [15:42] PR #4100: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces [15:44] popey: https://bugs.launchpad.net/snapd/+bug/1737197 [15:44] Bug #1737197: Go HomeDir reads /etc/passwd, not $HOME [15:45] thanks [15:47] popey, I can't duplicate :( [15:48] mborzecki: I was not following this, not sure what the status of s.iface.AutoConnec() is currently [15:48] mborzecki: I think zyga knows [15:48] kyrofa: wat, and you're logging in with your ubuntu one sso user/pass and 2fa? [15:48] Yeah [15:49] popey, can you try export-login instead? [15:49] It should use the same code path [15:49] what's export-login? Is it documented? [15:49] `snapcraft export-login --snaps --channels edge` [15:49] Not yet, it's how we're going to support circle CI [15:49] I mean, you can run --help of course [15:49] I'll be writing a tutorial on it [15:49] so for travis I should use that too, instead of the enable-ci travis? [15:50] You can, but no, this is just a test [15:50] I'm curious if it fails the same way [15:50] uh [15:50] Wow, I didn't even give you the right command :P . You need a file [15:50] it fails asking for a file [15:51] mvo, i'm fine to keep it, doesnt look like there is any hurry to fix ... [15:51] Yeah, you're exporting the login to a file that you can then use to login with `snapcraft login --with ` [15:51] mvo, though if you have a quick fix, feel free to grab it [15:51] kyrofa: whats the right command? [15:51] `snapcraft export-login --snaps --channels edge foo` [15:51] Then your login will be in foo [15:52] mvo, oh, wait ... silly me ... we re-added lsb-release to the core snap tarball a while ago (together with locales) ... it can actually be closed ... /me does so [15:52] (which you can just delete. It's just the macaroons) [15:52] kyrofa: fails [15:52] Same way? [15:53] https://www.irccloud.com/pastebin/Sl1kCNFt/ [15:53] Bug #1689037 changed: apt-add-repository in classic snap on core always adds artful repos [15:54] popey, can you try running that with debug enabled? `snapcraft -d export-login [...]` [15:54] You'll see a few API hits, maybe we can get some insight from that [15:55] hahahahahahahaahahahahahaha [15:55] I know what it is [15:55] this is ace [15:55] https://www.irccloud.com/pastebin/WRpBeKif/ [15:55] I bet you a pound that api has moved [15:55] bet it's not /dev anymore [15:55] 404... [15:55] Oh com eon [15:56] I JUST added support for that [15:56] But why did it work for me?! [15:56] afaik it's where it always was [15:56] if I had a shrug emoji, I'd likely use it here [15:56] Also, the fact that a 404 is turned into "invalid creds" is annoying [15:56] I agree :) [15:57] would you like a separate bug for that? :) [15:57] I had the same problem when I was posting with the wrong package format [15:57] Made it take forever to figure out what was happening. I've never typed my password so many times [15:57] popey, no, just put a royal whine in the bug [15:58] ok [15:58] Hey cprov, any idea why this is a 404? https://www.irccloud.com/pastebin/WRpBeKif/ [16:01] popey: here, ¯\_(ツ)_/¯ [16:04] +1 [16:05] mvo, i linked all PRs to bug 1701018 [16:05] Bug #1701018: Splash screen is not enabled in kernel [16:05] popey, can you run enable-ci with -d as well? [16:05] (it is largely done ... just missing a dragonboard PR) [16:05] I'm not 100% sure it hits the acl API [16:05] sure [16:06] I wonder if your login actually fails and then we malform the acl URL or something [16:06] "POST /dev/api/acl/ HTTP/1.1" 404 None [16:06] can I get someone who knows python combined with gtk/wayland to have a look at this person's snapcraft problem? https://forum.snapcraft.io/t/snap-to-test-gtk3-glibc-2-25-not-found/3073 [16:06] Ah okay good [16:06] I can't figure out why it's segfaulting but I can replicate it locally [16:06] kenvandine: might be up your street ^ [16:07] popey, I have to run for just a bit, but I'll look into this a bit more when I return [16:07] thanks popey [16:07] diddledan, can you try building it with the gnome-3-26 ppa enabled? [16:08] I'll give it a go [16:08] i'm not sure if libwayland in xenial works right [16:08] diddledan, i'd be very interested in the results :) [16:08] please let me know [16:09] diddledan, i've hit a separate issue today that made me worry about libwayland/gtk in xenial [16:10] ogra_: thanks [16:11] Bug #1705486 opened: SPI not working on Raspberry Pi with ubuntu core [16:13] popey: you bet a pound you say? :) [16:13] popey: curl -d '{"permissions": ["package_access"]}' https://dashboard.snapcraft.io/dev/api/acl/ -H 'Content-Type: application/json' [16:14] works fine here [16:14] * popey blows the dust off his wallet [16:14] popey: none of them round pounds either! ;) [16:15] kenvandine: good instincts! using the ppa fixes it right up [16:16] diddledan, good to know [16:16] I guess the xenial archive has a buggy libwayland or a buggy libgtk3 [16:17] diddledan, i think it might not be protocol compatible with artful [16:17] or really anything newer than xenial [16:18] but i fear updating libwayland might require more than just a rebuild of gtk [16:18] so hard to sru [16:18] gah [16:19] nothing wrong with using the gnome-3-26 ppa though :) [16:19] it's just not obvious to developers to do that [16:19] i'd like snaps built against gtk3/wayland from xenial to actually work in wayland :/ [16:24] yeah [16:27] PR snapd#4382 opened: snap: show header/footer when `snap find` is used without arguments [16:33] jdstrand: how do you feel about 4100? it looks good to me but gustavo is not around for a re-review for a couple of days. so we either need to merge without him or push it out into 2.31. wdyt? [16:36] mvo: I answered his questions and adjusted for the lock files. we have an ack on the the naming. the only thing technically outstanding is the 'w' random_seed, but it is needed by gpg for encryt/sign [16:37] mvo: I think it is safe to land. if Gustavo doesn't like the random_seed, we can do a followup PR [16:37] jdstrand: ok [16:38] mvo: I will prepare a PR for 2.30 for that then [16:39] mvo: I've also got extra tests for 4374 [16:41] mvo: I'll be updated pr 4375 too [16:41] PR #4375: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 [16:41] mvo: (the 2.30 PR) [16:41] jdstrand: aha, nice. thank you [16:42] jdstrand: its in [16:42] PR snapd#4100 closed: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces [16:42] mvo: thanks fthanks! [16:43] jdstrand: :) thank you, looking forward to the 2.30 PR [16:43] jdstrand: do you have more pending for 2.30? just asking so that I can plan the 2.30~rc3 accordingly [16:43] (i.e. no pressure or anything) [16:44] mvo: fyi, this was the change for 4374: https://github.com/snapcore/snapd/pull/4374/commits/29c3619b2c217d0003013733c7d1c91328b2b341 [16:44] PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging [16:44] mvo: let me double check [16:46] biometrics is blocked but can be 2.31. screen-lock I was planning on doing today, but could be 2.31 if needed. layouts and xdg-settings were post 2.30. 4375 is 2.30, ssh/gpg upcoming PR is 2.30 [16:47] the policy update xxxiii was committed already [16:47] ah, jhenstridge's gnome-online-accounts would be nice to have in 2.30, but I don't think it is ready (I reviewed it hoping it would get in) [16:48] mvo: so, bottom line, from me, 4375 and new ssh/gpg [16:48] mvo: I'm going to work on screen-lock and if you respin/whatever and want to pull it in, cool, if not, fine [17:04] kyrofa: hey [17:05] jdstrand: thank you. screen-lock is probably fine for 2.30, I can do 2.30~rc3 monday morning, not much will happen over the weekend anyway (sergio is on vac so no QA today) :) [17:10] mvo: 4375 is messed up. let me get you the ssh/gpg for 2.30 and circle back [17:10] jdstrand: its ok, its targeted for master [17:10] jdstrand: to get travis results [17:10] jdstrand: but we need to re-target to 2.30 [17:11] I don't see where to do that in the ui [17:11] jdstrand: [edit] next to the title [17:11] jdstrand: its a bit confusing :) [17:11] jdstrand: just target to 2.30 and ignore the warning [17:11] ok [17:11] kyrofa: I'm about to eod soon... but wondering if I can ask you to have a look at snapcraft#1800 (perhaps easier to see just the changes: https://github.com/kalikiana/snapcraft/compare/to_statement...kalikiana:on_to) when you have some time, this would be the second piece of the spec, basically looking for some feedback on the approach before finishing this with tests etc. [17:11] PR snapcraft#1800: grammar: on..to statement [17:11] that was not particularly discoverable [17:12] jdstrand: no disagreement :) [17:12] ok, back to no conflicts [17:12] jdstrand: yay [17:12] thanks jdstrand [17:12] PR snapcraft#1800 opened: grammar: on..to statement [17:12] mvo: so travis doesn't run on non-master? [17:20] mvo: hmm, looks like we have no luck running the tests today [17:23] I'm relocating... afk for a while [17:25] mborzecki: all? or a particular PR? [17:25] mborzecki: I had some successes. but it sad that tests are unreliable [17:25] jdstrand: it should run on non-master, it did in the past, I'm not sure what changed [17:39] Now to call it a day/ week [17:43] kalikiana, I'll take a look in a bit [17:46] kyrofa: Grand, thanks. No particular rush. FYI also shared the notes of our brainstorming for the record [17:46] kalikiana, sounds good. Have a wonderful weekend! [17:48] mvo: had to restart release/2.30 job again, it failed with some dns resolution issues this time [17:49] Thanks! Have a nice last day of the week yourself! [17:55] mborzecki: thanks! and annoying [17:55] mborzecki: annoying that its so unreliable currently [18:01] mvo: fyi, ssh/gpg for 2.30 will be submitted in a few minutes. had to unravel the testsuite changes which took a little longer than expected [18:10] PR snapd#4383 opened: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces for 2.30 [18:18] Hey! can someone point me to an example that extends the dump plugin. [18:22] kyrofa: ^ [18:22] om26er, hmm... let me see [18:23] om26er, none that I know of off the top of my head, but there are several examples of local plugins if that's all you're looking for [18:23] (I have one that inherits from make, for example) [18:24] kyrofa: I am trying to do what you suggested here https://forum.snapcraft.io/t/dump-source-per-architecture/3069/2 [18:24] I thought that might be it [18:25] kyrofa: any example that inherits a plugin will help [18:25] om26er, here's one: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-redis.py [18:25] There are a few in that repo [18:25] om26er, that particular example isn't necessary anymore with some new features the make plugin grew a while back, but it's still used [18:26] kyrofa: do you know which variable contains the 'source' ? [18:28] om26er, you see how I overwrote the `build` method there? You'll want to overwrite the `pull` method [18:30] om26er, you can refer to other plugins in the snapcraft tree for details of how they download stuff [18:30] kyrofa: alright looking [18:30] om26er, you can also look at the php plugin in nextcloud, which pulls extensions: https://github.com/nextcloud/nextcloud-snap/blob/master/snap/plugins/x-php.py [18:31] kyrofa: only in my case, I want to alter the `source` url based on arch. [18:31] that example seems to call the super() method, so its not exactly doing what I want to. But I'll try to figure that out [18:32] om26er, you won't be able to just set a variable and call it good, I'm afraid. You'll need to do the download [18:48] mvo: ok, PR 4374 passed. PR 4374 is in CI now. PR 4383 is in CI now. [18:48] PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging [18:48] PR #4383: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces for 2.30 [18:48] PR 4375 is in CI I meant to say [18:48] PR #4375: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 [19:05] hm, promising. [19:05] https://twitter.com/techieg33k/status/938840281646026753 [19:05] codeweavers retweeted it [19:06] jdstrand: great [19:10] ikey: nice :) [19:10] here's hoping :] === Son_Goku is now known as Conan_Kudo === Conan_Kudo is now known as Son_Goku [19:54] PR snapcraft#1799 closed: tests: update the registered snap fake [20:20] mvo: 5 restarts later, the release/2.30 branch travis job finally completed successfuly [20:34] Agghhhh /me throws all raspberry pis out of his window [20:34] We have awesome moonshot ARM servers. I want a VM on one [20:45] mborzecki: yay! [20:46] PR snapd#4383 closed: add ssh-keys, ssh-public-keys, gpg-keys and gpg-public keys interfaces for 2.30 [20:47] mvo: thanks! [20:48] jdstrand: thank *you* [20:49] mvo: fyi, I keep restarting PR 4375 since it is failing in unrelated ways [20:49] PR #4375: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging for 2.30 [20:49] mvo: but PR 4374 passed [20:49] PR #4374: interfaces: interfaces: also add an app/hook-specific udev RUN rule for hotplugging [20:51] PR snapd#4384 opened: interfaces/desktop,unity7: allow status/activate/lock of screensavers [20:53] PR snapd#4385 opened: interfaces/desktop,unity7: allow status/activate/lock of screensavers for 2.30 [20:55] mvo: fyi screenlock ^ for master and 2.30 [20:56] mvo: that's it for things I'm driving for 2.30 [21:00] jdstrand: cool, I have a look [22:59] kyrofa, you around tonight? [22:59] gsilvapt, I am [23:00] kyrofa, could we wrap up the string? I've tried a few combos but I'm still unable to get it right [23:00] gsilvapt, sure, where did you leave off? [23:01] I understood I need to pass in the arguments to %(prog) and %(version). So I tried adding .format when the variable we defined is called and pass in "snapcraft", snapcraft.__version__ [23:01] None of those works and the string literal is still printed to the console [23:02] gsilvapt, .format is the new format string method, you need to use the old one [23:02] I sent you a link yesterday, I think? [23:02] You did. Lets see if I can try that [23:04] kyrofa, but do I need to define a name placeholder too? Or that is not necessary for this? [23:04] gsilvapt, I'm not sure I understand what you're asking [23:05] In the link: https://pyformat.info/ There's a section called Named Placeholders. [23:05] I'm trying to figure out if I need to define a 'data' placeholder to pass into the string variable [23:07] gsilvapt, yeah you need to create a dict corresponding to the named placeholders you have in the string [23:07] Hum, let's try that [23:07] print('test is a %(test)s' % {'test': 'foo'}) [23:07] >>> test is a foo [23:10] Finally it worked, yey. [23:10] kyrofa, yea, I tried that to avoid creating another variable. My issue now will be formatting. You guys will kill me :D [23:12] Actually, now snapcraft --version is outputting something different. Weird, I'll have to review the command [23:15] kyrofa, I might need to re-do the decorator. snapcraft --version is printing snapcraft, version snapcraft, version 2.34 [23:16] It seems it is adding my message to a previous one defined somewhere else? [23:16] gsilvapt, I'll have to see code to know what's happening [23:16] snapcraft version is printing the desired output though [23:16] Perhaps I can push this to my fork and sent the link to you, kyrofa ? [23:16] gsilvapt, of course [23:31] kyrofa, here's version.py https://github.com/gsilvapt/snapcraft/blob/update_version_command/snapcraft/cli/version.py [23:31] and init: https://github.com/gsilvapt/snapcraft/blob/update_version_command/snapcraft/cli/__init__.py [23:36] gsilvapt, the variable needs to hold the template string, not the completed template [23:36] gsilvapt, click will complete it, and your command also needs to complete it [23:36] So instead of doing the % thing in the global, do it in the command [23:36] And just hand the template string to click [23:38] kyrofa, I'm still unable to have snapcraft --version working right [23:39] gsilvapt, push again [23:39] So I have the variable and pass in the % part in the click.echo command (in version.py). This is still working as expected [23:39] The cli/__init__.py is still repeating itself [23:40] gsilvapt, I think that's a kwarg, it needs to be message=MESSAGE_SNAPCRAFT_VERSION [23:41] this works: @click.version_option(message = MESSAGE_SNAPCRAFT_VERSION, [23:41] version = snapcraft.__version__) [23:41] Sorry for the weird formatting. [23:41] Yeah that looks more like it [23:42] Ok, I'll try prepping this up before updating the PR. Thanks for your help! [23:42] Sure thing [23:43] Hum, I'm not sure if I can squash the commit right now though. There has been so many pushes now. Is that okay? [23:44] kyrofa, ^ [23:44] Yeah that's fine [23:51] I really hope I'm not messing up the PR with this thing. [23:52] kyrofa, Now we have another issue. The unit test is not passing again. The cli command outputs run, version 2.34 and the other prints snapcraft, version 2.34 [23:52] gsilvapt, which is why I suggested not using %(prog)s [23:53] hardcoding snapcraft works, yes [23:58] kyrofa: dashboard.s.io/dev/api/acl seems to behave fine on empty payloads, https://pastebin.canonical.com/205119/ [23:59] let me check if it would 404 on bad payload, unknown snap name, for instance