[07:57] <mcphail> Is there a definitive list of what plugs are allowed in snapcraft.yaml, including detail on exactly what they do and don't allow the app to do?
[08:10] <seb128> mcphail, "snap interfaces" gives you a list, unsure about descriptions
[08:12] <qengho> ...but those vary by snapd, not the snapcraft version.
[08:18] <willcooke> hey qengho didrocks
[08:19] <didrocks> hey willcooke!
[08:19] <didrocks> so, as we discussed on #ubuntu-desktop, to move your snap to the new launcher desktop
[08:19] <seb128> popey, hey, on that snaps list document, for gtetrinet you have a systemctl cassandra cmd as "where", I guess that's a copy error?
[08:19] <willcooke> qengho, it's nice having you around in the morning!  Please move to Taiwan full time.
[08:19] <didrocks> willcooke: you just need to replace gtk3conf -> desktop/gtk3
[08:20] <didrocks> and for the command: gtk-launch -> desktop-launch
[08:20] <didrocks> and that should be it!
[08:20] <willcooke> oh
[08:20] <willcooke> wow
[08:20] <willcooke> nice
[08:20] <didrocks> if you are using snapcraft 2.12, you need to "snapcraft update" before running "snapcraft"
[08:20] <willcooke> didrocks, sudo that? ^
[08:22] <didrocks> no need for sudo
[08:22] <willcooke> running....
[08:22] <willcooke> didrocks, do you know if anyone is working on command completion for snapd at all?
[08:23] <didrocks> willcooke: not that I know of. I would like to have some time to do it, it's part of the dev experience to me :)
[08:23] <didrocks> (and yeah, we need advanced shell completion)
[08:23] <willcooke> didrocks, would love to help with that.  Learn a bit of Go too
[08:24] <willcooke> didrocks, maybe a good 1st job for the new snappy focused desktop team member when we hire them too
[08:28] <qengho> willcooke: It's tempting! I like it here. But, it's 16:30 now. And I might grow fat because the food is so good.
[08:29] <popey> seb128: uh, dunno how that got there
[08:30] <popey> seb128: someone else probably pasted crap in by accident
[08:30] <seb128> yeah, likely
[08:30] <seb128> can you put back the right value?
[08:40] <popey> uhm
[08:41] <popey> i dont think it had anything in it
[08:42] <seb128> k, it's in the store?
[08:44] <popey> no
[08:47] <mcphail> seb128: qengho: thanks. So is there any way to find this out directly from the running snapd, or do I need to dig into the source of the version of snapd to see what the plugs can and cannot do?
[08:47] <joc_> didrocks: hey, sorry to bug you, wondered if you were interested in commenting on this PR? (sergio thought you might be) https://github.com/snapcore/snapcraft/pull/614
[08:48] <seb128> popey, well, I can have a look to the warning if you share the snapcraft.yaml/script with me in some way
[08:49] <popey> I'll take another look at it. not touched gtetrinet for 2.5 months
[08:49] <popey> so probably needs to switch to the gtk launcher
[08:49] <popey> among other things
[08:50] <qengho> mcphail: plugs are complicated combinations of system-call filters and filesystem/dbus/socket/etc filters, and those are too detailed to make sense in a small list, except where it glosses over a lot of stuff.
[08:50] <seb128> right
[08:50] <willcooke> didrocks, quick initial test - settings are now preserved, but menus are not exported
[08:51] <qengho> mcphail: If the name isn't meaningful, then something is wrong. A plug should fit a whole class of needs. If it doesn't we would love to have a bug report to suggest tweaks. So, use what you see, and tell us if it's wrong or insufficient.
[08:52] <qengho> mcphail: The short answer is "it changes all the time, and please try it and we'll fix problems."
[08:53] <mcphail> qengho: ok, if it is a moving target that s fair enough
[08:53] <didrocks> jdstrand_: https://github.com/snapcore/snapd/pull/1463 here we go, do not hesitate if you have any question! :)
[08:53] <seb128> I still think that's a valid point
[08:53] <didrocks> joc_: yeah, I need to give a look, will do before EOD
[08:53] <seb128> those might be documented
[08:53] <seb128> didrocks, do you know if interfaces are documented somewhere?
[08:53] <didrocks> willcooke: yeah, known bug
[08:53] <joc_> didrocks: ack, thanks
[08:53] <seb128> like the list of ones available with the version they have been added to and a short description?
[08:54] <didrocks> seb128: oh wait, no, it's gtk…
[08:54] <didrocks> oupss
[08:54] <didrocks> willcooke: ^
[08:54] <didrocks> willcooke: let's look at it together in a sec
[08:54] <didrocks> seb128: yeah, there are some descriptions, one sec
[08:54] <mcphail> qengho: am I right that the "home" plug restricts access to dot files and directories? What is the rationale for that?
[08:55] <willcooke> didrocks, sure thing, just testing again against the other launcher, where I think it worked.  If so, should be easy to fix
[08:55] <didrocks> seb128: the best resource we have on this is https://developer.ubuntu.com/en/snappy/guides/interfaces/
[08:55] <didrocks> willcooke: interesting… it's a gtk app, right?
[08:55] <qengho> mcphail: I don't know.
[08:56] <mcphail> That page is helpful. Thanks didrocks and seb128
[08:56] <mcphail> qengho: cheers
[08:57] <didrocks> yw!
[08:57] <popey> Issue detected while analyzing snapcraft.yaml: Cannot find definition for part 'gtkconf'. It may be a remote part, run `snapcraft update` to refresh the remote parts cache
[08:57] <popey> when doing a cleanbuild ^
[08:57] <popey> how do you do a snapcraft update inside lxd?
[08:58] <davmor2> popey: same way surely
[08:58] <popey> no, that is inside lxd
[08:59] <davmor2> popey: does the container have an network connection?
[08:59] <popey> lxd/lxc is clean inside
[08:59] <popey> yes
[08:59] <didrocks> popey: yeah, cleanbuild doesn't work inside lxd
[08:59] <popey> so inside the container it doesn't "know" about gtkconf
[08:59] <didrocks> sorry
[08:59] <seb128> didrocks, 'ci
[08:59] <didrocks> cloud parts don't work inside lxd
[08:59] <popey> sorry, maybe I meant lxc
[08:59] <didrocks> AFAIK
[08:59] <didrocks> unsure anyone opened a bug yet
[08:59] <popey> hm
[08:59] <didrocks> I guess it's missing "snapcraft update"
[08:59] <popey> no
[09:00] <popey> thats not true
[09:00] <popey> because I have another one here which works using qt5conf
[09:00] <popey> but gtkconf fails
[09:00] <didrocks> and it works? oO
[09:00] <didrocks> ok, so not that issue
[09:00] <popey> does snapcraft ship "knowing" about qt5conf?
[09:00] <mcphail> popey: no
[09:00] <didrocks> I doubt
[09:00] <seb128> is gtkconf still a thing?
[09:00] <popey> is it not? :)
[09:00] <popey> it works outside the container
[09:00] <seb128> k, dunno then
[09:01] <seb128> didrocks superseeded it with a better version
[09:01] <seb128> but gtkconf should still work I guess
[09:01] <davidcalle> didrocks speaking of desktop confs, I'm trying your qt5 launcher with vlc, but no dice: the menu disappears from vlc, but never gets exported. No theming either. Do you want the snap?
[09:02] <popey> http://paste.ubuntu.com/18220245/ is my super simple yaml if anyone wants to reproduce
[09:02] <popey> snapcraft works, snapcraft cleanbuild does not
[09:02] <didrocks> davidcalle: ah, no theming is weird
[09:02] <didrocks> davidcalle: but appmenu not working is expecting
[09:02] <davidcalle> Ok
[09:02] <didrocks> see my messages from yesterday
[09:03] <popey> seb128: ^ fwiw that's as far as I got with gtetrinet - it launches but theme is broken and it doesnt launch properly
[09:03] <didrocks> davidcalle: snapd needs https://github.com/snapcore/snapd/pull/1463
[09:03] <didrocks> davidcalle: so yeah, we need to look at the theme
[09:03]  * davidcalle cat * | grep didrocks
[09:03] <davidcalle> didrocks: ok :)
[09:05] <didrocks> davidcalle: do you have the theme unconfined?
[09:09] <davidcalle> didrocks: nope (but I have the menu)
[09:10] <didrocks> yeah, menu is expected
[09:10] <didrocks> theme, ok, we need to look at it together
[09:10] <didrocks> mind having a HO in like, I don't know… 20 minutes ?
[09:11] <popey> In another app of mine, I am using qt5conf but get this when I launch it:-
[09:11] <popey> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
[09:11] <popey> anyone seen that before?
[09:11] <seb128> popey, did you bundle libgtk2.0-0?
[09:11] <popey> no
[09:11] <popey> should I?
[09:11] <seb128> likely the issue
[09:11] <popey> ok, thanks
[09:11] <seb128> if you want the QGtkStyle to work yes
[09:11]  * popey rebuildificates
[09:11] <mcphail> Hmm. Is there any way to give a snap access to dotfiles and dotdirectories in $HOME without running completely unconfined? I can't understand the thinking behind this
[09:11] <seb128> I think didrocks's new launcher handle that for you
[09:12] <popey> oooh
[09:12] <popey> new launcher
[09:12] <didrocks> it does!
[09:12] <seb128> mcphail, thinking is that apps are not able to steal your gpg or ssh keys or stored password in .config
[09:12] <didrocks> popey: new launcher*s* :)
[09:12] <seb128> mcphail, normal apps want to access files/documents, not configs from the system
[09:13] <mcphail> seb128: there'll be equally valuable credentials stored in normal files, though.
[09:13] <mcphail> seb128: i need my app to access
[09:14] <mcphail> .gitignore files etc
[09:15] <seb128> I'm sure that could be whitelisted
[09:15] <seb128> open a bug?
[09:15] <mcphail> seb128: against snapd?
[09:15] <seb128> mcphail, and "there could be other issues" it's a rational for "don't try to protect the user at all"
[09:15] <seb128> yes
[09:15] <seb128> tag it snapd-interface
[09:15] <seb128> it's *not* a rational
[09:15] <mcphail> seb128: thanks. will do
[09:16] <seb128> mcphail, would maybe be better to give access to specific xdg dirs
[09:16] <seb128> like xdg music/video
[09:16] <seb128> that would be even less likely to have the issue
[09:17] <mcphail> Maybe. so many overlapping concerns
[09:17] <seb128> I think the rational is that usually users don't go browser .config files
[09:17] <seb128> browse
[09:17] <seb128> that's system details
[09:18] <seb128> anyway the proper solution there is to have a file picker interface or a prompt saying "apps try to access ~/.gitignore, auth/nack"
[09:19] <mcphail> seb128: i'll maybe tidy up my yaml file and ask on mailing list for opinions
[09:19] <seb128> great
[09:20] <didrocks> willcooke: want to have a look together at the menu thingy?
[09:20] <didrocks> if it works with gtkconf
[09:20] <didrocks> and not with the new launcher
[09:22] <seb128> didrocks multi-hangouts :p
[09:22] <didrocks> ahah, oki!
[09:22] <seb128> didrocks, I can help will while you help david if you want
[09:22] <didrocks> let's do this!
[09:22] <willcooke> didrocks, sure thing!
[09:22] <seb128> cool
[09:23] <seb128> willcooke, sorry, you are stucked with me helping you :p
[09:23] <willcooke> :D
[09:23] <seb128> willcooke, can you push your current version to github?
[09:23] <willcooke> how shall we do this, hangout or IRC?
[09:24] <popey> what is the current way to fix theme issues? I have an app which looks like Windows 95
[09:24] <willcooke> popey, gtk app?
[09:24] <popey> qt
[09:24] <didrocks> popey: interesting, with the new launcher?
[09:24] <seb128> popey, using didiers' launcher?
[09:24] <didrocks> desktop/qt5?
[09:25] <popey>     after: [qt5conf]
[09:25] <popey> ^ doing that
[09:25] <didrocks> use my launcher
[09:25] <didrocks> it's supposed to fix it
[09:25] <popey> how?
[09:25] <didrocks> replace qt5conf -> desktop/qt5
[09:25] <didrocks> qt-launch -> desktop-launch
[09:25] <didrocks> and rebuild
[09:26] <seb128> willcooke, we can hangout in a few minutes if you want? if you push your changes I can build it here while making some coffee and then we can have a look
[09:26] <popey> ok
[09:26] <didrocks> popey: the example qt app is at least themed with it :)
[09:26] <didrocks> no promise on yours! the painting is still fresh on walls
[09:27] <popey>  😃
[09:27] <popey> building!
[09:27] <willcooke> seb128, pushed: https://github.com/8none1/gedit310
[09:28] <seb128> good
[09:31] <willcooke> Friday shared listening:  https://heylisten.io/snappy
[09:32] <willcooke> popey, ^
[09:32] <popey> heheh
[09:35] <popey> didrocks: your launcher seems to be trying to launch something in my home directory
[09:35] <popey> this is in my snapcraft.yaml:-
[09:35] <popey>     command: desktop-launch usr/local/bin/bitcoin-qt
[09:35] <didrocks> popey: hum, I don't cd on purpose, is your stuff in the path?
[09:35] <popey> and this is what happens when I run it
[09:35] <seb128> $ sendmykeystodidrocks.sh
[09:36] <didrocks> you need $SNAP
[09:36] <popey> /snap/bitcoin/x11/bin/desktop-launch: line 153: /home/alan/Development/Snappy/snappy-playpen/bitcoin/usr/local/bin/bitcoin-qt: No such file or directory
[09:36] <popey> oh
[09:36] <popey> in the yaml?
[09:36] <didrocks> yep
[09:36] <didrocks> I don't cd $SNAP in the launcher anymore
[09:36] <popey> okay
[09:36] <didrocks> I did forgot about it
[09:36] <didrocks> thanks for reminding me :)
[09:36] <didrocks> you don't need to rebuild
[09:36] <popey>     command: desktop-launch $SNAP/usr/local/bin/bitcoin-qt
[09:36] <popey> ?
[09:36] <didrocks> you can change the prime directory
[09:36] <didrocks> yeah
[09:36] <popey> ok
[09:36] <didrocks> or if usr/local/bin is in PATH
[09:36] <didrocks> just desktop-launch bitcoin-qt
[09:37] <popey> how would that snap be in the path?
[09:37] <didrocks> $SNAP/usr/bin as $SNAP/bin
[09:37] <didrocks> are
[09:37] <popey>  /snap/bin is in the path, but /snap/<snapname>/current/ etc aren't
[09:37] <popey> O RLY
[09:37] <didrocks> it is once launched from the u-c-l wrapper
[09:37] <didrocks> they add those to the PATH :)
[09:37] <popey> cunning
[09:38] <popey> okay. thanks
[09:38] <didrocks> I wonder if we should get usr/local/bin added
[09:38] <ogra_> just build your app with --prefix=/usr and not with --prefix=/usr/local
[09:38] <didrocks> ogra_: well, that's the next step :)
[09:38] <popey> yeah, will do that
[09:38] <popey> currently using that prefix
[09:38] <didrocks> let's get it running right now
[09:38] <didrocks> yeah, we know it's working that way for now, let's see if the theme is fixed then!
[09:39] <didrocks> seb128: sshhhhhhhhhhh, that was supposed to be a secret malware script ;)
[09:39] <seb128> :-)
[09:45] <popey> didrocks: fyi ln: failed to create symbolic link '/home/alan/snap/bitcoin/x12/.themes/themes': Read-only file system
[09:45] <popey> didrocks: and theme still looks ye olde
[09:45] <didrocks> hum
[09:46] <didrocks> do you have your source somewhere?
[09:46] <popey> didrocks: http://paste.ubuntu.com/18222328/
[09:48] <didrocks> hum onfigflags: [--prefix=/usr
[09:49] <didrocks> did you run that version?
[09:49] <didrocks> (as you still ref usr/local)
[09:49] <popey> yes
[09:49] <popey> uh.
[09:49] <popey> where do I reference usr/local?
[09:49] <didrocks> broken --prefix option maybe?
[09:49] <didrocks> ah
[09:49] <didrocks> sorry, it's commented :)
[09:49] <didrocks> #    command: qt5-launch usr/local/bin/bitcoin-qt
[09:49]  * popey sends didrocks to get his eyes tested
[09:50] <didrocks> popey: I'll send you the bill back :)
[09:51] <popey>  😃
[09:54] <seb128> willcooke, hum, the menus work fine here :-/
[09:54] <willcooke> hmm
[09:54] <willcooke> seb128, using the new launcher?
[09:54] <seb128> well, got your git, did snapcraft, installed the snap and typed gedit310
[09:55] <seb128> got gedit opening with integrated menu and proper look
[09:55]  * willcooke tries again 
[09:56] <didrocks> seb128: sure it works, this is a quality launcher! :)
[09:56] <seb128> lol
[09:56] <didrocks> not manager-proof though :p
[09:56]  * didrocks runs away
[09:56] <seb128> willcooke, just try to snap remove & install?
[09:56]  * willcooke slaps didrocks with a fish 
[09:56] <seb128> willcooke, if it's buggy let's debug it together anyway, you keep having things working on every other try which is weird
[09:56] <didrocks> willcooke: can I choose which kind of fish? :)
[09:56] <seb128> didrocks, that's because you didn't integrate slides
[09:57] <didrocks> oh right!
[09:57]  * didrocks adds slides and attach it to a meeting
[09:57] <willcooke> please do a spreadsheet as well
[09:57] <didrocks> and send an email :)
[09:57] <willcooke> now you're getting it
[09:57]  * didrocks applies for manager role then
[09:58] <didrocks> hum, desktop team manager position :)
[09:58] <willcooke> send your CV in Excel format
[09:58] <didrocks> heh
[09:59] <didrocks> finally, bitcon-qt built
[09:59] <willcooke> \o/
[10:01] <didrocks> popey: waow, snapcraft is trying to do some magic…
[10:01] <didrocks> which is failing in that case
[10:01] <seb128> willcooke, so, works after a remove/install?
[10:01] <popey> \o/
[10:01] <didrocks> popey: ah no, it's your fault!
[10:01] <didrocks>     command: desktop-launch $SNAP/bitcoin-qt
[10:01] <popey> oh :(
[10:01] <willcooke> seb128, just waiting for the build to finish
[10:01] <didrocks> popey: -> command: desktop-launch bitcoin-qt
[10:01] <seb128> willcooke, you should still have the old .snap could try with that
[10:01] <seb128> but ok
[10:01] <popey> oh
[10:01] <willcooke> seb128, deleted everything just to be sure
[10:01] <popey> good point
[10:01] <didrocks> popey: I have a gtk theme here
[10:02] <popey> hang on didrocks
[10:02] <didrocks> at least first dialog
[10:02] <popey> i have command: desktop-launch bitcoin-qt here
[10:02] <didrocks> what?
[10:02] <seb128> willcooke, k, I was suggesting to try without deleting, just to see why you get things that don't work until you wipe and rebuild
[10:02] <seb128> not the first time you need to re-re-build
[10:02] <didrocks> popey: your pastebin is correct
[10:02] <popey> http://paste.ubuntu.com/18222328/
[10:02] <popey> yes
[10:02] <popey> which I am using
[10:02] <didrocks> popey: ok, I'm probably stupid and the other me did something while I wasn't looking
[10:02] <willcooke> if you'd used google docs this wouldnt have happened
[10:03] <seb128> lol
[10:03]  * popey looks around the room
[10:03] <didrocks> :p
[10:03] <popey> didrocks: so how do you now have the gtk theme?
[10:03] <didrocks> I think I started to type it while talking about the usr/local prefix thing
[10:03] <didrocks> popey: the "Welcome screen" is clearly gtk themed
[10:03]  * didrocks takes screenshot to ensure we talk about the same thing
[10:04] <popey> http://imgur.com/IkTgAqQ
[10:04] <popey> thats what I see
[10:04] <willcooke> seb128, oki, rebuilt, installed -> http://imgur.com/LLPLKAR
[10:04] <seb128> willcooke, hangout?
[10:04] <didrocks> popey: my laptop is better than yours!
[10:05] <popey> bah
[10:05] <seb128> didrocks 1 - 0 popey
[10:05] <willcooke> ha!
[10:05]  * popey #brexits
[10:05] <seb128> seb128 1 - 0 willcooke
[10:05]  * didrocks is tempted about making jokes about europe
[10:05] <seb128> europe 2 - 0 u.k
[10:05] <didrocks> rohhh, popey…
[10:05] <didrocks> :)
[10:05] <seb128> in your face brexit!
[10:05] <didrocks> rohhh, seb
[10:05] <willcooke> seb128, https://hangouts.google.com/hangouts/_/canonical.com/will?authuser=0
[10:05] <seb128> :-)
[10:05] <popey> willcooke: music....
[10:05]  * willcooke loving the Friday 
[10:05] <didrocks> heh
[10:05] <willcooke> popey, had to join a HO
[10:05] <willcooke> popey, soz
[10:06] <willcooke> #bants
[10:06] <didrocks> popey: http://imgur.com/a/0ZItS
[10:06] <didrocks> and I didn't get any warning
[10:07] <didrocks> popey: snapd version?
[10:07] <didrocks> 2.0.9 here
[10:07] <popey> same
[10:07] <didrocks> and rebooted on the new snapd daemon, I guess?
[10:07] <popey> maybe I have some crap in my snap home dir due to previous builds
[10:07] <popey> reboot?
[10:07] <popey>  /join #windows
[10:07] <didrocks> well
[10:07] <didrocks> brought down the snapd service :)
[10:08] <popey> ok, well, I'll have a play then, thanks for confirming the natural superiority of the French.
[10:08] <popey> oh, did you install in --devmode?
[10:08] <popey> (I didn't)
[10:08] <didrocks> popey: nope!
[10:08] <didrocks> I didn't
[10:08] <popey> good
[10:09] <didrocks> popey: right, we could have done France 2 - 0 UK
[10:09] <didrocks> well, 1.5 because of seb128 ofc
[10:09] <popey> aha, deleting ~/snap/bitcoin has 'fixed' it
[10:09] <didrocks> and give 0.5 to Germany :p
[10:09] <seb128> lol
[10:09] <didrocks> popey: ah, hum, did you remove the previous version first?
[10:09] <popey> no
[10:09] <didrocks> that's why
[10:09] <popey> well that sucks
[10:09] <didrocks> there is a stamp with the launcher
[10:09] <popey> :)
[10:10] <didrocks> not really IRL
[10:10] <didrocks> because here, snapd is reusing the same revision
[10:10] <popey> http://imgur.com/LJuL5jC  great success!
[10:10] <didrocks> but once installed from the store, a different revision is issued
[10:10] <didrocks> \o/
[10:10] <popey> thank you!
[10:10] <didrocks> popey: want to confirm the fix for menu?
[10:10] <didrocks> (if they have any menu)
[10:10] <popey> the what for the what?
[10:10] <didrocks> popey: does this application supposed to have menus?
[10:11] <didrocks> is*
[10:11] <popey> don't think so
[10:11] <didrocks> ah ok, so nothing for you then :)
[10:11] <didrocks> popey: FYI, based deps are brought by the launcher itself
[10:12] <didrocks> so you can clean some, like the gtk2 one
[10:12] <didrocks> snapcraft define desktop/qt5
[10:12] <didrocks> shows them to you
[10:12] <didrocks> (in case you have some duplicates)
[10:13] <dpm> didrocks, ooh, do we have a qt5 launcher already?
[10:14] <didrocks> yep!
[10:14] <didrocks> desktop/qt5
[10:14] <didrocks> change qt-launch -> desktop-launch
[10:14] <didrocks>  /!\ it doesn't cd $SNAP
[10:15] <didrocks> you have supposively theme support, icon support, img caching
[10:15] <didrocks> appmenu needs a fix in snapd where a PR is above ^
[10:15] <didrocks> (funny debugging session yesterday with seb128)
[10:18] <popey> didrocks: neat!
[10:29] <seb128> didrocks, https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/gtk/launcher-specific#L25
[10:29] <seb128> tssss
[10:29] <popey> lulz
[10:29] <seb128> didrocks, arch coded,which is why it works for me and not for willcooke :p
[10:30] <mcphail> http://termbin.com/tfek - if I have a set of headers in the "build-packages" stanza, should I be adding the corresponding libs to the "stage-packages" section?
[10:30] <popey> didrocks: I do like your new shoes... http://imgur.com/OUU78ly
[10:30] <popey> mcphail: probably not
[10:30] <popey> unless it explicitly calls them
[10:31] <mcphail> popey: the app will call them, but they are "standard" libs
[10:31]  * popey goes to walk the dogs.
[10:31] <popey> biab
[10:31] <ogra_> dogs ?
[10:31] <didrocks> seb128: ohhhhhhhhhhhhh
[10:31] <didrocks> sad
[10:31] <didrocks> so sad :)
[10:31] <seb128> :-)
[10:31] <didrocks> ok, fixing
[10:32] <seb128> thanks
[10:32] <didrocks> popey: definitively! :-)
[10:32] <didrocks> that's exactly my style :)
[10:32] <popey> ogra_: my brother is on holiday, I'm walking his dogs :)
[10:32] <ogra_> ah
[10:32] <didrocks> seb128: what arch is willcooke using?
[10:32] <seb128> didrocks, amd64
[10:32] <ogra_> enjoy :)
[10:32] <didrocks> seb128: well, it's this file, right?
[10:32] <seb128> didrocks, btw if you use desktop/gtk3 it's already gtk3 can't we force from there?
[10:33] <seb128> didrocks, yeah, it was working for me because it wasn't finding gtk2
[10:33] <seb128> which made it stay on gtk3
[10:33] <seb128> which gedit uses
[10:33] <didrocks> seb128: I can add an arg for this to put a build time option
[10:33] <didrocks> seb128: I was unsure about this though
[10:33] <didrocks> ah ok :)
[10:33] <seb128> didrocks, are you pulling in gtk2-engines-murrine?
[10:33] <seb128> I don't understand where it comes form
[10:33] <seb128> from
[10:33] <didrocks> seb128: not directly
[10:33] <seb128> that seems what puts gtk2 in the snap
[10:34] <seb128> but gedit doesn't do it
[10:34] <seb128> oh, arg
[10:34] <didrocks> I wonder how our gtk3 demo was working though
[10:34] <seb128> light-themes does
[10:34] <seb128> stupid themes
[10:34] <didrocks> yeah, I was going to say…
[10:35] <didrocks> (fixed pushed)
[10:35] <didrocks> fix*
[10:35] <didrocks> I wonder though why gtk3-demo is working and themed
[10:36] <seb128> did we pull light-themes there?
[10:36] <didrocks> the launcher does
[10:36] <davmor2> didrocks: because it hates you?
[10:36] <seb128> oh
[10:36] <seb128> OH
[10:37] <seb128> didrocks, gtk3-demo uses gmenumodel proper, no need of the unity-gtk-module exporter, where gedit 3.10 uses old school standard gtk menus and does
[10:38] <didrocks> ahah
[10:38] <didrocks> yes! good catch :)
[10:38] <seb128> so I don't think being clever works
[10:38] <seb128> also bundling light-themes sucks, it makes everyone get a gtk2 stack
[10:38] <didrocks> but GTK_MODULES= is exported, right?
[10:38] <didrocks> ah no
[10:39] <didrocks> because we fallback to gtk2
[10:39] <didrocks> because of this files
[10:39] <seb128> yes
[10:39] <didrocks> yeah, there is no other way than bundling until we have an interface though, right?
[10:39] <seb128> well, we could have the desktop/gtk getting the theme from bzr
[10:39] <seb128> or something
[10:39] <seb128> rather than installing the deb which install the gtk2 depends
[10:39] <didrocks> we need the deps though?
[10:40] <didrocks> like humanity-icon-theme,
[10:40] <didrocks> ubuntu-mono
[10:40] <seb128> we don't need gtk2-engine-murine though
[10:40] <seb128> we could side package those
[10:40] <didrocks> let's see if those won't pull gtk2
[10:41] <didrocks> well, it's pulling gtk3
[10:41] <didrocks> which means the other way around is sucky though
[10:41] <didrocks> (adwaita-icon-theme)
[10:42] <didrocks> light-themes needs the engine for gtk2, right?
[10:42] <seb128> yes
[10:43] <didrocks> we won't be able dh_scour or such, but I guess, until we have an interface, it's ok
[10:43] <didrocks> I wonder if we should take the pain to build it from source
[10:43] <didrocks> (for gtk3)
[10:43] <didrocks> gtk2 will pull gtk3 anyway, so meh
[10:44] <didrocks> (through the icon themes)
[10:46] <didrocks> seb128: what do you think is the best?
[10:46] <didrocks> I guess that prooves we need to be imperative at build time at least
[10:47] <didrocks> (and I can change that)
[10:47] <didrocks> then, for the snap size, I'm unsure (there are other things to fix as well, but in general)
[10:47] <seb128> didrocks, we have different issues there
[10:47] <seb128> - the gtk version autodetect is flacky
[10:47] <seb128> - we pull in too much
[10:48] <didrocks> yeah, we need to fix #1
[10:48] <didrocks> and I can
[10:48] <seb128> how?
[10:48] <didrocks> for #2, it's a bigger issue
[10:48] <seb128> just be declarative?
[10:48] <didrocks> having the makefile taking an arg
[10:48] <seb128> k
[10:48] <seb128> let's do that
[10:48] <didrocks> and so, transparent for the user
[10:48] <didrocks> yeah
[10:48] <seb128> if you use /gtk3 then build with that
[10:48] <didrocks> yep
[10:48] <seb128> #2 as different possible fixes
[10:49] <didrocks> right
[10:49] <didrocks> let's focus on #1
[10:49] <seb128> k
[10:49] <didrocks> I have a doctor appointment, but as they are late, I'm bringing my laptop with 3G, will probably work from there
[10:49] <didrocks> but I'll ping you once I pushed the fixes
[10:49] <seb128> for #2 we can probably just checkout the theme from bzr and copy it to the right location
[10:49] <seb128> k
[10:49] <seb128> thanks
[10:49] <didrocks> (just maybe I won't test it under 3G, so waiting to go back ;))
[10:50] <didrocks> seb128: yeah, it will still means that gtk2 apps brings gtk3
[10:50] <seb128> because of adwaita?
[10:50] <seb128> but yeah
[10:51] <seb128> optimization are for later
[10:51] <seb128> or for shared vendor snaps
[10:51] <didrocks> yep
[10:51] <didrocks> because of humanity-icon-theme
[10:51] <seb128> we might want to fix the theme
[10:52] <seb128> I don't think adwaita needs to depends on gtk
[10:52] <seb128> is snapcraft taking recommends?
[10:53] <didrocks> good question, I never looked closely
[10:54]  * ogra_ hopes not
[10:56] <didrocks> using apt-cache
[10:57] <didrocks>                 self.apt_cache[name].mark_install()
[10:57] <didrocks> so, following default on your machine
[10:57] <didrocks> meaning, I guess… recommends
[10:57] <didrocks> I don't see after a first quick look any override
[10:57] <didrocks> oh sorry
[10:57] <didrocks> there is
[10:57] <didrocks>     apt.apt_pkg.config.set('Apt::Install-Recommends', 'False')
[10:57] <didrocks> ok, so no recommends :)
[10:58] <ogra_> phew
[10:58]  * didrocks bbl
[10:59] <seb128> didrocks, great!
[12:23] <zyga> slangasek: hey
[12:24] <zyga> slangasek: how can I offload mvo with debian/ubuntu uploads
[12:29] <ogra_> OsError("XOpenIM failed")
[12:29] <ogra_> seb128, ^^ do you perhaps have any wrapper setup  that could overcome this ?
[12:31] <ogra_> (i have tried unsetting XMODIFIERS and forcing LC_CTYPE=C and even added ibus to stage-packages alrady)
[12:40] <timothy> hi, is there any snap-confine developer here?
[12:46] <kyrofa> timothy, you want zyga
[12:46] <kyrofa> timothy, or jdstrand once he's in
[12:47] <kyrofa> timothy, what's up?
[12:47] <timothy> I'm creating the official packages of snappy for archlinux (by mainly porting the zyga one)
[12:48] <kyrofa> timothy, wonderful!
[12:48] <timothy> but there is a bug that prevent me to do that (https://github.com/snapcore/snap-confine/pull/69)
[12:49] <timothy> actually I patch this on archlinux package
[12:49] <timothy> :)
[12:49] <timothy> just to let you know
[12:49] <kyrofa> timothy, ah, thanks for the pointer!
[12:50] <timothy> missing () so only last check is evaluated
[12:50] <seb128> ogra_, no, when do you hit that one?
[12:50] <ogra_> seb128, tryingto ackage the servo browser (rust based app)
[12:50] <ogra_> *package
[12:50] <seb128> hum, k, I don't know about that stack sorry
[12:52] <kyrofa> timothy, indeed, I gave it a review
[12:52] <kyrofa> timothy, but I'll let zyga give it a quick look at merge it
[12:53] <kyrofa> s/at/and/
[13:03] <dpm> didrocks, re: qt-launch -> desktop-launch \o/
[13:03] <didrocks> dpm: working well for you? :-)
[13:04] <dpm> didrocks, bad news is just that I probably won't be able to test it in my qt snap until next week. Not today or over the weekend :/
[13:05] <didrocks> dpm: no worry! :)
[13:05] <didrocks> that will let people getting allll the bugs :)
[13:05] <didrocks> s/people/popey/
[13:06] <dpm> didrocks, yeah, it was all planned :)
[13:06] <didrocks> \o/
[13:07] <popey> didrocks: trying your gtk2 desktop launcher... not working here. are you in a position to help?
[13:08] <seb128> didrocks, you trolled popey and now he's making you pay back...
[13:08] <popey> http://paste.ubuntu.com/18232902/ is my gtetrinet simple yaml, using your desktop/gtk2 launcher. The app launches, but there's a fair number of console errors, and the UI pops up some theme errors, despite it looking okay.
[13:09] <popey>  😃
[13:09] <didrocks> arghhhhh ;)
[13:09] <popey> You're welcome!  😃
[13:09] <popey> /snap/gtetrinet/x1/bin/desktop-launch: line 72: /snap/gtetrinet/x1/.flavor-select: No such file or directory
[13:09] <didrocks> popey: errors are not something specifically launcher related
[13:09] <popey> that kind of thing
[13:09] <didrocks> popey: ah, you just got this one
[13:09] <didrocks> yea, it's my current change and I got that
[13:09] <popey> yay
[13:09] <didrocks> I'm debugging this as we speak :)
[13:09] <popey> good good
[13:10] <didrocks> I think the issue is that the wiki isn't updated
[13:10] <didrocks> well
[13:10] <didrocks> the cronjob isn't update
[13:10] <didrocks> but the source is
[13:10] <didrocks> and so, it doesn't get the right parameter
[13:10] <ogra_> didrocks, does any of yuor launcher have handling for input methods yet ?
[13:10] <didrocks> (should be fixed by itself on next cronjob run)
[13:10] <didrocks> but I'm checking
[13:10] <didrocks> ogra_: yes
[13:11]  * ogra_ tries to overcome OsError("XOpenIM failed") in one app 
[13:12] <didrocks> popey: and found a snapcraft bug!
[13:12] <didrocks> sergiusens: it seems you are not staging hidden files
[13:12] <didrocks> when they are at the root
[13:12] <didrocks> (of any part)
[13:13] <ogra_> didrocks, whihc one ? i cant find any twiddling with XMODIFIERS or such in any of them
[13:13] <didrocks> ogra_: just use one of the launcher
[13:13] <didrocks> and see how it goes :)
[13:13] <sergiusens> didrocks that is very much likely to be the case
[13:13] <sergiusens> didrocks but iirc we os.walk
[13:13] <ogra_> didrocks, nah, i dont want a full launcher, only the code for me five line wrapper :)
[13:13] <didrocks> sergiusens: I can have a look, unbreaking menawhile
[13:14] <didrocks> ogra_: ok, I will help you once I've fixed things and get my launcher working then :)
[13:14] <didrocks> ogra_: but it's bad in term of maintainance and the idea is to have small launchers as well sharing code
[13:14]  * sergiusens reads the backlog in the meantime
[13:14] <ogra_> didrocks, the app uses raw XIM (its a rust based static binary that i can even launch fine from /sbap/<package>/current directly)
[13:15] <sergiusens> didrocks btw in case you want to give a quick look https://github.com/snapcore/snapcraft/pull/620
[13:15] <ogra_> didrocks, i dont want the extra 100MB :)
[13:15] <ogra_> only the right vars to kill off XIM completely
[13:15] <didrocks> ogra_: unsure then, contribute to the launcher with your minimal ones once you get something :p
[13:15] <ogra_> i only see GTK_IMMODULES in your code ... which would mean that i would have to include gtk just for that
[13:16] <ogra_> (the app doesnt use any toolkit)
[13:16] <sergiusens> popey 2.13 fixes cleanbuild with remote parts
[13:16] <popey> sergiusens: yay
[13:17] <didrocks> sergiusens: how often is the importer ran?
[13:18] <didrocks> sergiusens: been 20 minutes I pushed a change to my snapcraft.yaml
[13:18] <didrocks> sergiusens: but snapcraft define desktop/gtk2 doesn't reflect it yet
[13:20] <didrocks> popey: once "snapcraft define desktop/gtk2" shows     make-parameters: ["FLAVOR=gtk2"]
[13:20] <didrocks> popey: you can snapcraft and it should work correctly
[13:20] <didrocks> sergiusens: we have an issue due to this cronjob, like new code pushed, but definition not updated ^
[13:20] <didrocks> and popey just experienced it :)
[13:20] <didrocks> (that + the hidden file)
[13:21] <didrocks> seb128: FYI, if you try to build any gtk2 apps for now ^
[13:21] <didrocks> (the fallback is gtk3)
[13:21] <seb128> didrocks, fallback you mean default?
[13:22]  * sergiusens checks again to see if he is not on a #brexit eu vs uk channel
[13:22] <popey> I love being on the edge of bugs :)
[13:22] <popey>  😃
[13:22] <timothy> is zyga working on snapd too?
[13:23] <sergiusens> didrocks importer, every 10 minutes, but josepht has those numbers
[13:23] <didrocks> sergiusens: hum, seems it doesn't work that way
[13:23] <didrocks> josepht: mind having a look? ^
[13:23] <didrocks> popey: sorry for this…
[13:24] <sergiusens> didrocks maybe every hour, I get confused, but here's a little secret https://parts.snapcraft.io/v1/status
[13:24] <popey> didrocks: it's all good.
[13:24] <sergiusens> didrocks if you are in a hurry hurry, josepht can probably manually trigger
[13:25] <didrocks> sergiusens: yeah, updating would be great! I am semi-afaid of premature optimization as here, the wiki page didn't change at all
[13:26] <didrocks> (it's only the snapcraft.yaml that changed)
[13:26] <didrocks> + the code ofc
[13:26] <didrocks> sergiusens: ok, almost done, looking at your branch in a bit
[13:27] <sergiusens> kyrofa are you around and about?
[13:27] <kyrofa> sergiusens, yessir
[13:27] <sergiusens> didrocks sure, my branch is WIP (missing one crucial thing)
[13:27] <sergiusens> kyrofa the reason I sent an early draft of the branch was to discuss part.installdir and pkgconfig :-)
[13:27] <didrocks> sergiusens: ah, mind repinging me for the final review if you prefer?
[13:28] <didrocks> sergiusens: I want to check as well this hidden file staging issue meanwhile
[13:28] <kyrofa> sergiusens, happy to!
[13:28] <sergiusens> didrocks sure thing
[13:28] <sergiusens> kyrofa wanna do a hangout?
[13:28] <kyrofa> sergiusens, sure, standup url?
[13:28] <sergiusens> kyrofa ea, give me a minute to brush my teath so you don't smell my bad breath :-P
[13:29] <kyrofa> sergiusens, haha, yes please, ping me
[13:30] <sergiusens> kyrofa done :-)
[13:31] <kyrofa> sergiusens, I'll be right there, I may have had a genius breakthrough and want to test it real quick
[13:31] <sergiusens> kyrofa k
[13:33] <kyrofa> sergiusens, coming now
[13:36] <timothy> hi zyga, I have a couple of push requests for you :P
[13:57] <niemeyer> Who maintains ubottu?
[14:01] <didrocks> sergiusens: josepht: I think the importer is broken, it did fetch but didn't reflect the new snapcraft.yaml changes
[14:01] <didrocks> "snapcraft define desktop/gtk2"
[14:02] <didrocks> sergiusens: josepht: this is the missing line: https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/snapcraft.yaml#L19
[14:02] <didrocks> popey: FYI ^
[14:04] <didrocks> thanks zyga for the merge :)
[14:09] <didrocks> sergiusens: josepht: ok, another snapcraft update and it's in now
[14:09] <didrocks> popey: you can play after your next snapcraft update ^ :)
[14:12] <popey> now?
[14:12] <popey>   make-parameters:
[14:12] <popey>   - FLAVOR=gtk2
[14:12] <popey> \o/
[14:13] <popey> biab, need to get kids from school
[14:14] <sergiusens> didrocks nice, I was hoping to see the original dual qt/gtk thing solve with build params
[14:14] <sergiusens> didrocks might as well just offer one and use composition as well ;-)
[14:14] <didrocks> sergiusens: composition? :)
[14:15] <didrocks> (it's sourcing some common files)
[14:15] <didrocks> to avoid too much duplication
[14:19] <sergiusens> didrocks ignore the self promotion http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/
[14:19] <tyhicks> zyga: hi - the partial confinement branch goes against our previous decision to make confinement all or nothing since all the pieces of confinement depend on each other
[14:19] <tyhicks> zyga: what was the reasoning for the change?
[14:19] <kyrofa> sergiusens, can you explain all the checks here? https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/sources.py#L335
[14:20] <zyga> tyhicks: that's not reverted in any way, snaps are still in devmode
[14:20] <kyrofa> sergiusens, I know it's in order to re-pull when the pull failed, but why check to make sure the dir is empty etc.? Now that it's not a symlink, I think I might have to just blow it away. Do you see a downside there?
[14:20] <zyga> tyhicks: this just lests us see if anything is missing in other distributions
[14:20] <zyga> tyhicks: snaps still run as before
[14:20] <zyga> tyhicks: (missing as in build dependencies)
[14:21] <zyga> tyhicks: with .34 I'm pulling in libudev and libseccomp as build deps
[14:21] <zyga> tyhicks: confinement is still controlled by snapd and no change was made there
[14:21] <zyga> tyhicks: what I want to do is to ensure that all the distros have the right userspace parts
[14:21] <zyga> tyhicks: and I *could* build a fully supported snap-confine
[14:21] <didrocks> sergiusens: oh that (overriding some parts of the launcher), yeah, that's what decided me to have clean launchers that you can override and putting deps there :)
[14:22] <didrocks> sergiusens: that's a nice feature!
[14:22] <didrocks> sergiusens: btw, you lied to me
[14:22] <zyga> tyhicks: eventually I want snap confine to look the same everywhere, with snapd knowing what to do based on system release and kernel
[14:22] <didrocks> snapcraft doesn't use walk, but glob.glob() :)
[14:22] <didrocks> that's why it doesn't like '*'
[14:22] <sergiusens> didrocks oh, I said most likely, there's a mix of os.walk and glob
[14:22] <didrocks> yep
[14:23] <didrocks> trying to think of the best way
[14:23] <tyhicks> zyga: got it - thanks for explaining it to me :)
[14:24] <zyga> tyhicks: yep, thanks for being vigilant :)
[14:31] <iliv> zyga, FYI if binaries are under prime/bin command: has to be bin/$YOURPROGRAM, not just command: $YOURPOGRAM as you said yesterday.
[14:32] <zyga> iliv: hmm, maybe it was usr/bin, snapcraft does expand and search $PATH
[14:33] <zyga> iliv: it doesn't hurt to spell out the full path
[14:33] <zyga> iliv: but you can abbreviate in many cases
[14:33] <iliv> not without changing something
[14:33] <iliv> e.g. $PATH etc.
[14:33] <niemeyer> sergiusens: ping
[14:33] <zyga> iliv: if bin/ is not on path then I bet sergiusens can fix that
[14:33] <sergiusens> niemeyer pong
[14:33] <zyga> I mean this should work, it's probably a bug somewhere
[14:33] <niemeyer> sergiusens: Heya
[14:33]  * zyga hugs sergiusens 
[14:33] <zyga> snapcraft rocks man :)
[14:34] <niemeyer> sergiusens: Did you ever fix the QTCOMPOSE / Compose file thing on the Telegram snap?
[14:34] <niemeyer> sergiusens: I'm still getting that warning and ã doesn't work there
[14:34] <iliv> also, I think app: definitions should support underscore symbol. I was trying to use pg_basebackup: as an app name and that lead to errors about incorrect YAML syntax
[14:35] <sergiusens> niemeyer hmm, no; just noticing this as á works fine
[14:35] <niemeyer> It works here as well
[14:35] <sergiusens> but ã and others don't
[14:36] <zyga> iliv: underscore is reserved, you can use it in the command section internally but on the outside it is not allowed
[14:36] <iliv> seems harmless really
[14:36] <iliv> but okay
[14:36] <iliv> I guess there's a reason for this
[14:36] <zyga> iliv: it was used as a field separator earlier
[14:36] <zyga> iliv: I think it's good to be strict, we can allow it later but in the past there was a good reason to exclude it
[14:37] <iliv> I see
[14:38] <iliv> > hmm, maybe it was usr/bin // not sure if you're talking about your experience or my particular case... in my case all binaries are under prime/bin and snapd (or whatever the process is) never could find a daemon binary if appname: ismyapp. it has to be appname: bin/ismyapp.
[14:40] <zyga> iliv: prime/bin is not in path
[14:40] <zyga> iliv: if you install your apps so that they are under usr/bin or bin/ then it should work, if not, then you can just specify the path in the command, both should work okay
[14:42] <iliv> but prime/ is a directory created by snapcraft. it holds bin/ usr/ include/ etc. the autotools (which is my part) installed everything in bin/.
[14:43] <iliv> it seems like snapcraft is not aware of its own fs layout ?
[14:43] <iliv> or I am terribly confused about how it all is supposed to work :)
[14:44] <kyrofa> zyga, iliv indeed, snapcraft adds bin, usr/bin, etc. to the path
[14:44] <tsimonq2> sergiusens: what unit tests need to be updated? it seems like none of what I've looked at used the contstructors you mentioned
[14:44] <tsimonq2> sergiusens: (that are breaking)
[14:44] <kyrofa> iliv, but you still need to declare runnable stuff in `apps`
[14:45] <tsimonq2> sergiusens: and there's multiple different failures, I don't know which one you are talking about to update
[14:46] <iliv> kyrofa, which I believe I did. I have apps: myapp: bin/myapp for every binary under prime/bin. yet what you and zyga seem to be saying is that apps: myapp: myapp should work too. if that's case, it doesn't appear to be the case.
[14:46] <kyrofa> iliv, you're missing a `command` there somewhere
[14:47] <zyga> iliv: you can think of the root of your snap as a little root filesystem
[14:47] <kyrofa> iliv, can I see your yaml?
[14:47] <zyga> iliv: there $SNAP/bin and $SNAP/usr/bin are on path
[14:47] <iliv> oh sorry
[14:48] <iliv> here's an example:
[14:48] <iliv> apps:
[14:48] <iliv>   clusterdb:
[14:48] <iliv>        command: bin/clusterdb
[14:48] <iliv> I have a dozen of these
[14:48] <szszsz> hi! I would like to access to a device from within snap
[14:48] <iliv> and strangely none are exposed to a system
[14:48] <kyrofa> Yeah you should definitely be able to simply use `command: clusterdb` there
[14:48] <szszsz> I got message from app armor: * use gadget hardware assign to access '/dev/bus/usb/003/046'
[14:49] <szszsz> Where could I find more info about it?
[14:49] <kyrofa> iliv, how are you trying to run that app, then?
[14:49] <kyrofa> i.e. how do you know it's not in PATH?
[14:49] <iliv> I assume that when an app is exposed I can just run clusterdb on my terminal
[14:49] <iliv> $ clusterdb
[14:49] <kyrofa> iliv, no, you need to prefix it with the snap name. <snapname>.<appname>
[14:49] <iliv> oohhh
[14:49] <iliv> interesting
[14:50] <kyrofa> iliv, that prevents multiple snaps from declaring the same command and fighting with each other
[14:50] <kyrofa> iliv, the only special case there is when appname == snapname, then you can just run <snapname>
[14:51] <zyga> szszsz: hey
[14:52] <zyga> szszsz: snappy applications run under confinement and by default they cannot poke at hardware
[14:52] <zyga> szszsz: snaps can gain more permissions with interfaces
[14:52] <zyga> szszsz: we have many interfaces for various things but obviously not everything is supported yet
[14:52] <szszsz> zyga: I would need one for talking to usb devices
[14:52] <zyga> szszsz: can you please report a bug on launchpad.net/snappy with the description of the problem and all the context (e.g. what kind of device it is)
[14:53] <zyga> szszsz: I'm sure we can support it
[14:53] <szszsz> zyga: ok!
[14:53] <zyga> szszsz: if you know how please tag the issue with snapd-interfaces
[14:53] <zyga> szszsz: you can run your snap if you install it in devmode
[14:53] <zyga> szszsz: snap install --devmode your-snap.snap
[14:53] <zyga> szszsz: that should log about various apparmor denials but should still let your application run
[14:54] <zyga> szszsz: based on those logs and your bug description we should be able to create an interface for the thing you are trying to access
[14:54] <didrocks> ogra_: you may have an answer for this one, btw? http://askubuntu.com/questions/792555/how-to-implement-or-call-up-bluetooth-in-snappy-ubuntu-of-beaglebone-black
[14:54] <szszsz> zyga: I will attach them then
[14:54] <zyga> szszsz: since snapd is released every week you can use devmode for now but you should be able to use the new interface very soon
[14:54] <zyga> szszsz: perfect, thank you :-)
[14:54] <szszsz> zyga: wow, great! :]
[14:55] <szszsz> zyga: thanks!
[14:56] <slangasek> zyga: sorry, don't understand what you mean by offloading
[14:56] <slangasek> zyga: are you asking what you need to do in order to take over the debian/ubuntu uploads, so mvo doesn't have to?
[14:57] <arcade_droid> How do you do partial updates in a snap? Assume you have a game, one image file in the snap needs to be updated.
[14:57] <arcade_droid> Because full re-download of a 8GB snap won't please any sane user.
[14:57] <zyga> slangasek: offloading so he can focus on hacking more than on the release process
[14:58] <zyga> arcade_droid: we don't have delta updates enabled yet but we are well aware of this
[14:58] <sergiusens> tsimonq2 the general route to fix tests is to look at the traceback and got to the line it says it failed on that corresponds to the unit test file
[14:58] <tsimonq2> sergiusens: which is what I've done
[14:59] <zyga> arcade_droid: snaps should be very natural to do delta downloads and it will be added sometime later as a feature that is transparent to all users
[14:59] <arcade_droid> zyga, so this is a planned feature of snaps to do partial updates?
[14:59] <tsimonq2> sergiusens: but I'm not finding the problem
[14:59] <zyga> arcade_droid: very much so
[14:59] <sergiusens> tsimonq2 I havne't looked in detail, but since you added a param to the constructors I bet some of these None values are related to that
[14:59] <tsimonq2> sergiusens: I'll double-check everything, thanks for clarifying
[15:00] <slangasek> zyga: well, mvo isn't doing the Debian uploads, so no need to offload from him on that.  For Ubuntu uploads, that's not a quick or easy thing to take over if you aren't already a core-dev; but maybe it makes sense for you to take over driving the SRUs / proposed-migration propagation?
[15:00] <slangasek> zyga: (currently, yakkety hasn't had any version of snapd newer than 2.0.2, because there have been autopkgtest failures that no one has had time to investigate/resolve...)
[15:00] <zyga> slangasek: anything that helps is useful
[15:01] <zyga> slangasek: how can I iterate on that? I can run yakkety, run autopkgtests there, how can I upload new versions of snapd to yakkety?
[15:02] <slangasek> zyga: I believe shepherding the packages through queues is the easy win.  For getting new versions into yakkety, you could give me packages to sponsor uploads of?
[15:04] <zyga> slangasek: so I prepare the package, ping you and you do the upload?
[15:04] <kyrofa> tsimonq2, are you running those tests locally?
[15:04] <slangasek> zyga: yes.  For snapd, I would certainly want your changes to be committed upstream first
[15:05] <slangasek> zyga: since currently xenial+yakkety are "in sync"
[15:05] <zyga> slangasek: yep
[15:05] <zyga> slangasek: I'll see what is blocking current yakkety and I'll work on that next week
[15:05] <zyga> slangasek: and eventually I could apply to be a core dev
[15:05] <slangasek> zyga: cool, thanks!
[15:05] <slangasek> zyga: yes :)
[15:05] <tsimonq2> kyrofa: yep, same errors
[15:05] <tsimonq2> kyrofa: I just pushed because I was stuck and needed help
[15:06] <szszsz> I have one more question, if I may. I have published app but I cannot downloaded it through snap install nitrokey-app --channel beta . How to make it work?
[15:06] <iliv> kyrofa, I see good to know. I have apparently larger problems as my snap package can't even be installed.
[15:07] <kyrofa> tsimonq2, you see where you added source_checksum=None here? https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR101
[15:07] <kyrofa> iliv, huh... what do you mean? What's happening?
[15:07] <szszsz> I have checked all channels but with no luck. Checked channels in web gui and set all available, but have not helped
[15:08] <didrocks> szszsz: is it confinment: strict or devmode?
[15:08] <didrocks> confinement*
[15:09] <kyrofa> tsimonq2, you switched the order here: https://github.com/snapcore/snapcraft/pull/619/files#diff-e6205a80af76b4faec1d9241dc3b3b7cR296
[15:09] <kyrofa> So that's failing a lot
[15:09] <maxiberta> hi, I have an issue with htop snap: it's being denied sending signals by apparmor (it's plugged into system-observe); any way to fix that?
[15:09] <tsimonq2> kyrofa: heh what? the order matters? that's something I didn't consider for sure
[15:10] <zyga> szszsz: not sure
[15:10] <zyga> szszsz: maybe you have to login as yourself first
[15:10] <kyrofa> tsimonq2, it does it you're not using variable=value
[15:10] <tsimonq2> kyrofa: thanks, I'll play with it
[15:11] <kyrofa> tsimonq2, so that's causing failures like "__init__() missing 1 required positional argument: 'source_dir'" for the tar source
[15:11] <tsimonq2> oh okay
[15:12] <tsimonq2> kyrofa: sorry for being a n00b :P
[15:12] <kyrofa> tsimonq2, relax man, before snapcraft I didn't know python at all :)
[15:12] <kyrofa> tsimonq2, you're in good company!
[15:12] <tsimonq2> good to know :)
[15:13] <kyrofa> sergiusens, elopio I need to take an extended lunch today, I may very well not make standup. I'll be working later this afternoon/evening
[15:14] <tsimonq2> kyrofa: I guess that I'm saying is thanks, and sorry for (in my mind at least) not seeing the obvious
[15:14] <szszsz> I
[15:14] <tsimonq2> s/that/what/
[15:14] <szszsz> I have used devmode for 0.1 and strict for 0.2. I was logged in during upload.
[15:15] <kyrofa> tsimonq2, I just spent hours on what ended up being a one-liner. We all run into that type of thing! No apology necessary
[15:15] <szszsz> 0.2 is now under review if I see correctly in web app.
[15:15] <tsimonq2> alright kyrofa :)
[15:16] <iliv> kyrofa, see this paste https://dpaste.de/UokM/raw. it includes my snapcraft.yml. So, clearly postgres is being run as root user and I'm wondering if we have any control over which user a service which is part of a snap can be run as?
[15:16] <szszsz> but what about 0.1 and beta/edge channels? zyga didrocks ^^^
[15:16] <didrocks> szszsz: did you see my question about confinement?
[15:16] <kyrofa> iliv, ah!
[15:17] <szszsz> didrocks: yes, I have responded earlier
[15:17] <kyrofa> So it installs, but doesn't run :) . Does postgres have a --yes-i-know-what-im-doing flag?
[15:17] <didrocks> szszsz: sorry, I did miss it :)
[15:17] <didrocks> so yeah, devmode is private to you AFAIK
[15:17] <kyrofa> iliv, other daemons are like that as well, php-fpm needs a special flag, apache needs special configs, etc
[15:17] <didrocks> szszsz: did you use snap login as well?
[15:17] <kyrofa> iliv, but every one I've done has given me ways around it
[15:18] <kyrofa> iliv, services are always run as root-- no way around it
[15:18] <szszsz> didrocks: yes, I have logged in
[15:18] <didrocks> szszsz: I think you should have access once you are logged in snap (not snapcraft)
[15:18] <didrocks> interesting, nessita may help you maybe? ^
[15:18] <sergiusens> kyrofa no worries
[15:18] <kyrofa> iliv, those daemons have those protections in place for good reasons, but those reasons are not valid within snaps
[15:18] <szszsz> didrocks: why bother then setting edge/beta channels in app store?
[15:18] <didrocks> szszsz: you can publish beta version (confined) that everyone can try :)
[15:19]  * kyrofa -> lunch
[15:19]  * zyga needs to buy a tshirt after unfortunate accident in the coffee shop, ttyl
[15:19] <didrocks> szszsz: AFAIK, there will be a way for you soon to share your unconfined version with some people
[15:19] <szszsz> didrocks: I will check login info once again in both snap and snapcraft
[15:19] <didrocks> but it's not there yet
[15:19] <didrocks> yeah, ensure you are logged in in "snap"
[15:19] <szszsz> didrocks: I am trying too currently :]
[15:19] <nessita> didrocks, sorry, what's the question (unclear from backlog)?
[15:19] <szszsz> *to
[15:20] <didrocks> nessita: szszsz says "I have published app but I cannot downloaded it through snap install nitrokey-app --channel beta . How to make it work"
[15:20] <didrocks> nessita: "I have used devmode for 0.1 and strict for 0.2. I was logged in during upload."
[15:20] <didrocks> that's the gist of it
[15:20] <szszsz> didrocks: nice
[15:20] <nessita> didrocks, let me check
[15:20] <didrocks> szszsz: you are in good hands now :)
[15:21] <szszsz> nessita: here is the url if it helps: https://myapps.developer.ubuntu.com/dev/click-apps/5313/rev/2/
[15:21] <szszsz> didrocks: thx! :]
[15:21] <nessita> szszsz, hi! so looking at your package in the store, what I see is: revno 1 (0.1) is published (green box) but revno 2 is not published (thumbs up)
[15:21] <nessita> szszsz, so you have a few options:
[15:22] <nessita> 1- to install the revno 1, devmode, you need to pass --devmode to snap install
[15:22] <nessita> (plus the channel)
[15:22] <nessita> snap install nitrokey-app --devmode --channel beta
[15:22] <szszsz> nessita: I have published 0.1 in edge channel, shouldn't that work?
[15:22] <didrocks> nessita: oh, the client already enforce the --devmode? nice! :)
[15:22] <nessita> szszsz, if it's a devmode snap, you need to install it with --devmode, because the user needs to be aware some security checks are being bypassed
[15:23] <nessita> szszsz, your revno 2 is not devmoe (yey!) but it not published, to publish it you need to visit https://myapps.developer.ubuntu.com/dev/click-apps/5313/rev/2/ and click publish at the bottom
[15:24] <nessita> (we are working to make this screen a bit more user friendly)
[15:24] <didrocks> nessita: maybe the issue is in the client side return message? (not clear enough it exists, but in devmode)
[15:24] <didrocks> error: cannot perform the following tasks:
[15:24] <didrocks> - Download snap "nitrokey-app" from channel "beta" (snap not found)
[15:24] <didrocks> yeah, it's not really clear
[15:24] <nessita> didrocks, what version of snapd are you running?
[15:24] <didrocks> nessita: 2.0.9
[15:24] <szszsz> nessita: woah, haven't seen that one, just clicked
[15:26] <nessita> szszsz, so now, since your revno 2 is in stable, you could do: snap find nitrokey-app
[15:26] <nessita> nessita@miro:~$ snap find nitrokey-app
[15:26] <nessita> nitrokey-app             0.2                     nitrokey              -      Nitrokey Application
[15:26] <nessita> (among other results)
[15:26] <nessita> szszsz, your devmode revision will never appear in searches
[15:26] <nessita> didrocks, could you ping Chipaca about that? it should work (snap install nitrokey-app --devmode --channel beta)
[15:27] <szszsz> nessita: thanks, it started working just now
[15:27] <didrocks> sure
[15:27] <didrocks> even with 0.2 published now?
[15:27] <didrocks> (maybe it wasn't published in the beta channel)
[15:27] <nessita> didrocks, it was, revno 1 was in beta and edge
[15:28] <didrocks> ok, and 2 isn't? only stable?
[15:28] <didrocks> as I guess otherwise, it will take rev 2 now
[15:28] <nessita> didrocks, 2 is in stable, candidate and beta
[15:28] <didrocks> ah, so can't be reproduced for now
[15:28] <nessita> didrocks, perhaps with edge:
[15:28] <nessita> snap install nitrokey-app --devmode --channel edge
[15:28] <didrocks> yeah
[15:29] <sergiusens> kyrofa didrocks sans tests, this is good for a review https://github.com/snapcore/snapcraft/pull/620/files
[15:30] <sergiusens> just sending out now as you are EODing or having a long lunch ;-)
[15:30] <szszsz> nessita: didrocks rev 2 is all but edge, 0.1 is only edge
[15:30] <didrocks> sergiusens: sureeeeeeeee, I see your strats :)
[15:30] <didrocks> sergiusens: do you really want a review now? I was really going to EOD :p
[15:31] <didrocks> or Monday is ok?
[15:31] <szszsz> nessita: didrocks well, it is working now, thank you!
[15:31] <didrocks> nice! :)
[15:31] <sergiusens> didrocks just an overpass, if not, don't worry, it is what we discussed
[15:31] <didrocks> sure, can do an overpass
[15:32]  * sergiusens goes and writes unit tests
[15:41] <maxiberta> hi all, need some help with apparmor
[15:42] <maxiberta> apparmor is preventing htop from sending signals to other processes
[15:42] <didrocks> sergiusens: ok, really did a quick overpass, functionnally-wise, it's great! I didn't spot any issue. Just some comments on some style nitpicking!
[15:42] <tyhicks> maxiberta: hi - that's by design
[15:42] <tyhicks> maxiberta: if a process can send another process signals, it can do nasty things like kill another snap's processes
[15:43] <maxiberta> tyhicks: yep, I get it but... even with system-observe?
[15:43] <tyhicks> oh
[15:43] <tyhicks> let me take a look at the system-observe policy
[15:43] <tyhicks> maxiberta: do you have any apparmor denials in the logs?
[15:44] <maxiberta> tyhicks: apparmor="DENIED" operation="signal" profile="snap.htop.htop" pid=19011 comm="htop" requested_mask="send" denied_mask="send" signal=term peer="unconfined"
[15:46] <tyhicks> maxiberta: sending SIGTERM to another process doesn't really fit into system-observe which is defined as, "Can query system status information."
[15:46] <tyhicks> maxiberta: when you're sending SIGTERM out, you're actively managing the system at that point
[15:48] <iliv> kyrofa, I see, so overall it's generally safe to run a service as root as long as it is confined. I'm also wondering what happens when we punch holes in the security confinement with plugs. For example, network. I realize this is a very generalized question but how secure is this model? If a ...
[15:48] <iliv> ... program is running as root and it is confined but we then let it interface (I think would be the word) with unconfined system resources do any of the risks that are typical to a normal system apply to a snap package? At least within the boundaries of the type of plug being used?
[15:49] <maxiberta> tyhicks: sure, but that's breaking htop's functionality
[15:49] <tyhicks> maxiberta: perhaps you need a new interface to be defined for what you need
[15:49] <popey> didrocks: so now I'm getting a dialog in gtetrinet which says "Warning: Theme does not have a name, reverting to default" 😖
[15:49] <ogra_> didrocks, sorry, havent touched beaglebone since we dropped it from our default supported arches
[15:50] <maxiberta> tyhicks: that'd be good
[15:50] <popey> didrocks: I suspect it requires some massage to make it look i different directories
[15:50] <didrocks> popey: you knew I was just typing /quit in my weechat window, didn't you? :p
[15:50] <popey> hahah
[15:50] <didrocks> popey: yeah, would be interested
[15:50] <popey> sorry, see you monday
[15:50] <didrocks> popey: looking on Monday?
[15:50] <popey> ya
[15:50] <didrocks> yeah ;)
[15:50] <popey> o/
[15:50] <didrocks> we can have some debug sessions then!
[15:50] <didrocks> see you guys & popey ;)
[15:50] <maxiberta> tyhicks: should I report a bug?
[15:50] <tyhicks> maxiberta: can you file a request at https://bugs.launchpad.net/ubuntu/+source/snapd/+filebug and add the "snapd-interface" tag?
[15:51] <maxiberta> tyhicks: sure, thanks!
[15:51] <tyhicks> maxiberta: thank you :)
[15:56] <timothy> who can change something on http://snapcraft.io/ website?
[15:57] <tsimonq2> timothy: it's a GitHub repo somewhere
[15:57] <maxiberta> tyhicks: done, thanks
[15:59] <tsimonq2> kyrofa: for when you come back, I can fix TypeError: join() argument must be str or bytes, not 'NoneType' by doing a sed of s/source_checksum=None/source_checksum/ but that adds a lot of new errors about missing arguments
[15:59] <tsimonq2> kyrofa: I'm hesitating to commit and push because maybe it's associated with the lack of "=None"
[16:01] <tsimonq2> kyrofa: the new result of `./runtests unit`: http://paste.ubuntu.com/18244502/
[16:02] <tsimonq2> kyrofa: what's also puzzling me is failures like this: https://travis-ci.org/snapcore/snapcraft/jobs/141462851#L2066
[16:08] <ogra_> nessita, oh, is --channel supposed to work now ? still doesnt for my giter app
[16:08] <ogra_> *gitter
[16:08] <ogra_> ogra@styx:~/Devel/packages/snaps/servo$ sudo snap install gitter --devmode --channel edge
[16:08] <ogra_> error: cannot perform the following tasks:
[16:08] <ogra_> - Download snap "gitter" from channel "edge" (snap not found)
[16:09] <ogra_> that is ... https://myapps.developer.ubuntu.com/dev/click-apps/5257
[16:09] <ogra_> (same error for beta)
[16:13] <nessita> ogra_, well, in theory the spec requires that snap install uses --edge
[16:13] <nessita> ogra_, so the specific response should come from Chipaca/pedronis
[16:14] <ogra_> uh, we dont default to stable ?
[16:32] <nessita> ogra_, I think we do
[16:35] <ogra_> nessita, your comment sounded different
[16:35] <ogra_> "the spec requires that snap install uses --edge"
[16:35] <ogra_> i thought you meant in general
[16:39] <nessita> ogra_, ah, I was talking about the format of the command line
[16:39] <ogra_> ah
[16:39] <ogra_> well using --edge gets me an error
[16:39] <nessita> when passing a channel, it should be --channel=name but --name
[16:39] <nessita> ogra_, rigth, that was in progress last time I asked
[16:40] <ogra_> the error when using --channel edge indicates it actually looked in the edge channel though
[16:40] <ogra_> ogra@styx:~/Devel/packages/snaps/servo$ sudo snap install gitter --devmode --channel=edge
[16:40] <ogra_> error: cannot perform the following tasks:
[16:40] <ogra_> - Download snap "gitter" from channel "edge" (snap not found)
[16:41] <timothy> sudo is not necessary if you are in sudo, wheel or adm group :)
[16:42] <ogra_> timothy, only if you use an U1 login
[16:42] <ogra_> (which i dont want on this machine)
[16:44] <timothy> [maybe-OT] snapd package moved to official community repository on archlinux
[16:44] <ogra_> nice !
[16:44] <ogra_> totally not OT !
[16:46] <ogra_> nessita, well, in any case, the gitter snap is in the store in edge and beta ... shouldnt i be able to install it ?
[16:47] <nessita> ogra_, let me check
[16:48] <ogra_> https://myapps.developer.ubuntu.com/dev/click-apps/5257/rev/1/
[16:48] <nessita> ogra_, what exact command are you running?
[16:48] <ogra_> see above :)
[16:48] <ogra_> sudo snap install gitter --devmode --channel=edge
[16:48] <ogra_> i also tried with gitter.ogra
[16:48] <ogra_> and with --channel=beta
[16:48] <nessita> ogra_, let me check the fine details
[16:49] <nessita> ogra_, short answer is yes, you should, now let me debug if this is an store issue or snapd issue
[16:49] <nessita> ogra_, what version of snapd are you using?
[16:49] <ogra_> i upgraded it today ... one sec
[16:50] <ogra_> ah, no, that was snapcraft ... snapd is 2.0.9 still
[16:50] <nessita> ogra_, is that latest?
[16:51] <ogra_> seems a newer one is in -proposed, let me grab that one
[16:53] <ogra_> nessita, ok, fasle alarm ... works with 2.0.10
[16:53] <ogra_> sorry for the noise
[16:54] <nessita> ogra_, oh, but that is not released yet?
[16:54] <ogra_> it is sitting in -proposed ... waiting for th SRU process
[16:54] <nessita> ah...
[16:54] <ogra_> i just grabbed it from there
[16:54] <nessita> ogra_, so well, yeah, latest snappy honors --devmode
[16:54] <nessita> but pervious don't
[16:54] <nessita> previous*
[16:54] <ogra_> yeah
[16:55] <ogra_> finally i can advertise my snaps :)
[17:04] <niemeyer> mup: You ok there?
[17:04] <mup> niemeyer: In-com-pre-hen-si-ble-ness.
[17:05] <niemeyer> Good
[17:06] <ogra_> bug #1
[17:07] <ogra_> bug 12345
[17:07] <ogra_> niemeyer, no bugs yet ?
[17:26] <niemeyer> ogra_: Sorry, involved on a snap find-related discussion.. will finish the set up
[17:27] <ogra_> yeah, no hurry, i thought it was a default feature :)
[17:33] <niemeyer> bug #1
[17:34] <niemeyer> Did I do something wrong
[17:34] <niemeyer> ?
[17:34] <niemeyer> mup: bug #1
[17:34] <mup> niemeyer: Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for
[17:34] <mup> ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by
[17:34] <mup> shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Unknown> <Ubuntu:Fix Released by sabdfl> <Arch Linux:Confirmed> <Baltix:Confirmed> <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>
[17:34] <niemeyer> bug #123456
[17:35] <ogra_> lol, you killed ubot9
[17:35] <niemeyer> :)
[17:36] <niemeyer> Hmm.. it should it be overhearing conversations as well about bugs.. #123456
[17:39] <niemeyer> bug #123456
[17:43] <niemeyer> Ah, got it..
[17:44] <niemeyer> bug #123456
[17:46] <niemeyer> bug #123456
[17:46] <mup> Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> <https://launchpad.net/bugs/123456>
[17:46] <niemeyer> There you go..
[17:46] <ogra_> \o/
[17:46] <niemeyer> Now let's get the new bugs reported here too..
[17:48] <niemeyer> Done
[17:50] <niemeyer> Okay, next.. GH issues and PRs
[17:50] <niemeyer> But must move the server first..
[18:03] <mup> Bug #1598266 opened: Cannot read/write to usb device [libusb][hidapi] <snapd-interfaces> <Snappy:New> <https://launchpad.net/bugs/1598266>
[19:06] <sergiusens> mhall119 hey, now I see you :-) Mind trying https://github.com/snapcore/snapcraft/pull/620 with pantheon?
[19:06] <sergiusens> mhall119 I can help you out running from source if you need to
[19:11] <saalen> how to define environment variables in the application start wrapper script created by snapcraft?
[19:12] <mhall119> sergiusens: I'll try, I have no internet access tody though, outside my phone
[19:44] <jrwren> can I make a snap not depend on ubuntu-core?
[20:09] <mhall119> sergiusens: I'll try that once my home network is coneccted to the internet again
[20:24] <niemeyer> mup: Are you still ok?
[20:24] <mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
[20:25] <niemeyer> mup is now living its life inside a snap..
[20:26] <mhall119> that's cool, but it sounds a little sheltered :)
[20:41] <niemeyer> mhall119: In which sense?
[21:08] <niemeyer> issue snapd#1124
[21:08] <mup> PR snapd#1124: integration-tests: add coverage flags to snapd.service ExecStart setting when building from branch <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1124>
[21:09] <kyrofa> elopio, sergiusens I give you: https://github.com/snapcore/snapcraft/pull/622
[21:09] <mup> PR snapcraft#622: Hard-link local sources instead of symlinking them <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/622>
[21:09] <kyrofa> Whoa, thanks mup!
[21:09] <kyrofa> Haha, niemeyer I should have seen what you just did
[21:10] <kyrofa> niemeyer, so is # -> LP, <something># -> github?
[21:10] <kyrofa> Does LP require "bug" and github require "issue" ?
[21:11] <sergiusens> elopio so, I just found an issue ;-)
[21:17] <sergiusens> elopio so https://github.com/snapcore/snapcraft/pull/623 will pass unit tests, but there is overmocking in test_commands_register
[21:17] <mup> PR snapcraft#623: Proper message when registering an already registered snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/623>
[21:18] <sergiusens> elopio https://github.com/snapcore/snapcraft/blob/23732a5db53b3f1caf14d10845b2cec518530c9e/snapcraft/tests/test_commands_register.py#L52
[21:18] <kyrofa> sergiusens, any idea why this line https://github.com/snapcore/snapcraft/blob/master/integration_tests/test_store_download.py#L40 is checking to make sure the OS snap is in the project dir instead of parts/<name>/src ?
[21:18] <kyrofa> sergiusens, does it actually need to be in the project dir?
[21:20] <sergiusens> kyrofa probably better lived in src
[21:22] <kyrofa> sergiusens, good deal
[21:25] <mup> Bug #1598304 opened: systemd services created by snappy breaks etckeeper <Snappy:New> <https://launchpad.net/bugs/1598304>
[21:27] <sergiusens> kyrofa btw have you checked https://github.com/snapcore/snapcraft/pull/620 again?
[21:27] <mup> PR snapcraft#620: Alter prefix for pkg-config to get correct values <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/620>
[21:28] <kyrofa> sergiusens, ah, doing now, sorry
[21:28] <sergiusens> kyrofa I consider it complete ;-)
[21:31] <tsimonq2> o/ kyrofa
[21:31] <kyrofa> Hey there tsimonq2 :)
[21:38] <tsimonq2> kyrofa: you see the stuff I pinged you about earlier? :)
[21:39] <kyrofa> tsimonq2, yeah, give me just a minute and I'd be happy to chat :)
[21:40] <tsimonq2> alright thanks kyrofa :)
[22:02] <kyrofa> Okay tsimonq2, I'm all yours. Let me re-read what you said
[22:02] <tsimonq2> \o/
[22:04] <kyrofa> tsimonq2, I'll just pull your branch and see where it is, okay? That way we don't need to refer to travis
[22:04] <tsimonq2> alright cool :)
[22:14] <kyrofa> tsimonq2, alright, first error:
[22:14] <kyrofa> tsimonq2, snapcraft.tests.test_base_plugin.GetSourceTestCase.test_get_source_with_branch_must_raise_error
[22:16] <kyrofa> tsimonq2, you can run just that test with: python3 -m unittest snapcraft.tests.test_base_plugin.GetSourceTestCase.test_get_source_with_branch_must_raise_error
[22:19] <tsimonq2> oh that's convenient
[22:19] <kyrofa> tsimonq2, indeed, focus on one at a time
[22:19] <tsimonq2> alright
[22:19] <kyrofa> This one should be relatively straightforward
[22:20] <tsimonq2> so it lists 3 things
[22:20] <tsimonq2> an error and 2 fails
[22:20] <tsimonq2> the fails are common so I might as well see if I can knock that out, unless you disagree
[22:21] <niemeyer> kyrofa: They don't require it.. LP will only "overhear" bugs with 5 digits or more
[22:21] <kyrofa> tsimonq2, indeed, I agree
[22:21] <niemeyer> kyrofa: So, #123456, but not #123
[22:21] <mup> Bug #123456: podcast crashes amarok <Amarok:Invalid> <xine-lib (Ubuntu):Fix Released> <https://launchpad.net/bugs/123456>
[22:21] <kyrofa> niemeyer, ah, okay good to know!
[22:21] <niemeyer> kyrofa: For this channel, I've limited the GH plugin to require the repository prefix, and default to the snapcore organization
[22:21] <kyrofa> tsimonq2, note that these are all the same test, just different test data
[22:22] <tsimonq2> yep I figured that out kyrofa
[22:22] <kyrofa> niemeyer, how would we do a different org?
[22:22] <niemeyer> kyrofa: snapcore/snapcraft#123
[22:22] <mup> PR snapcraft#123: Added an argument to filter examples tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/123>
[22:22] <kyrofa> niemeyer, just like github org/proj#num
[22:22] <kyrofa> Ah
[22:22] <niemeyer> Yeah
[22:22] <kyrofa> niemeyer, excellent, I've wanted that for a while now thank you!
[22:22] <tsimonq2> kyrofa: so it looks like the mismatch is that raised.exception isn't equal to the appropriate string
[22:23] <kyrofa> tsimonq2, indeed, you added some new validation checks there
[22:23] <kyrofa> tsimonq2, which means the test data also needs to be updated
[22:23] <kyrofa> tsimonq2, and add some cases to catch your new option
[22:23] <tsimonq2> oh okay I get it
[22:24] <tsimonq2> let me play with that in the GetSourceTestCase function
[22:24] <kyrofa> tsimonq2, yeah do that. Go through the failures one by one, running them individually like I showed you. You should find them all similarly trivial
[22:24] <tsimonq2> alright
[22:33] <tsimonq2> kyrofa: so I've had some luck, thank you! :D
[22:33] <tsimonq2> but
[22:33] <tsimonq2> it's failing on something that should be trivial to fix
[22:33] <tsimonq2> AssertionError: "can't specify source-checksum for a bzr source" != "can't specify a source-checksum for a bzr source"
[22:34] <kyrofa> tsimonq2, one error message has an "a" in it, the other doesn't?
[22:34] <tsimonq2> yep
[22:34] <tsimonq2> that's it
[22:34] <tsimonq2> ahhh
[22:34] <tsimonq2> figured it out
[22:35] <tsimonq2> all solved \o/
[22:35] <tsimonq2> I'll run ./runtests unit to pick out more to solve
[22:35] <tsimonq2> thanks for getting me started kyrofa
[22:53] <kyrofa> tsimonq2, no problem! Best of luck :)
[22:57] <niemeyer> kyrofa: np!
[23:02] <tsimonq2> that feeling when a one line fix reduces the failing unit tests from 33 to 9! \o/
[23:02] <niemeyer> and that completes the mup hackery of the day.. probably..
[23:03] <niemeyer> mup: infer day of the week
[23:03] <mup> niemeyer: Friday.
[23:03] <niemeyer> Exactly.. and dinner time too
[23:04] <niemeyer> mup: infer dinner time
[23:04] <mup> niemeyer: Basic information: composer Busta Rhymes.
[23:04] <niemeyer> What? LOL
[23:05] <niemeyer> mup: infer -all dinner time
[23:05] <mup> niemeyer: Basic information: composer Busta Rhymes — Recordings: album music act release date, Street Hop Royce da 5′9″ Tuesday, October 20, 2009.
[23:05] <tsimonq2>  
[23:05] <niemeyer> Okay.. enough playing, sorry. :)
[23:08] <tsimonq2> kyrofa: you still around? I think the last 9 failing might have a common cause, I pushed the changes I made, mind pointing me in the right direction?
[23:11]  * tsimonq2 adds unit tests for source-checksum, maybe that's the issue but we'll see
[23:15] <tsimonq2> nope
[23:31] <tsimonq2> well I'll play more tomorrow, I'm off for the day, o/