[01:42] <johangm90> hi guys is there some example of qmake part?
[06:00] <ned__> I seem to have a problem and need someone's help.  I just did a clean install of Ubuntu 16.04 desktop and I installed the Tiger auditing tool from debian.  After the scan it shows:                               #checking md5sums of installed files  --Fail-- [lin005f] Installed file '/boot/vmlinuz-4.4.0-21-generic'  checksum differs from installed package 'Linux-image-4.4.0-21-generic'.     I am confused as to how this is when granted 
[06:01] <ned__> I checked the md5sum with microsoft checksum tool and everything was verified, so why is tiger telling me different
[06:23] <dholbach> hey hey
[06:29] <seb128> hey dholbach, how are you?
[06:29] <dholbach> good good - how about yourself?
[06:29] <seb128> I'm good as well, thanks ;-)
[07:39] <zyga> o/
[07:46] <zyga> mwhudson: thank you :)
[07:46] <zyga> mwhudson: curious, are you interested in snap-confine or just moving closer to snappy bits
[08:08]  * davidcalle is impressed by the simplicity of the blender snap, would love to see the snapcraft.yaml
[08:10] <seb128> davidcalle, "simplicity"?
[08:11] <seb128> you mean the content of the snap itself is like one file?
[08:11] <mcphail> blender is designed to he self contained. Ideal for a snap
[08:11] <davidcalle> seb128: no launch wrapper and /snap/blender/meta/snap.yaml is super straightforward
[08:14]  * mcphail wonders whether the CUDA acceleration would work?
[08:19] <seb128> davidcalle, it's likely that blender itself is built to be started from random locations and not tight to a linux distro layout
[08:19] <seb128> I doubt there is snapcraft magic in action there
[08:19] <seb128> davidcalle, who did the snap? upstream?
[08:19] <didrocks> yeah, like no appmenu as no standard toolkit
[08:22] <davidcalle> seb128: https://uappexplorer.com/app/blender-tpaw.tpaw
[08:23] <seb128> davidcalle, well you have the snapcraft.yaml in the upstream url indicated there, https://github.com/tpaw/snap-repository/blob/master/third-party/blender-tpaw/snapcraft.yaml
[08:30] <zyga> mcphail: it should work on Arch, I didn't test this on ubuntu as I dont' have the required hardware
[08:30] <zyga> mcphail: but we could use a dedicated cuda interface for this
[08:31] <mcphail> zyga: i haven't managed to get any graphical snaps running on an nvidia machine anyway, so I suppose CUDA is a step beyond me at this point ;)
[08:32] <zyga> mcphail: why not?
[08:32] <zyga> mcphail: did you try snap-confine 1.0.33 and snapd 2.0.9?
[08:32] <zyga> mcphail: I have a very old mobile nvidia gpu and it works very well there
[08:33] <zyga> mcphail: (on ubuntu and arch) with prorietary and free drivers
[08:33] <mcphail> zyga: just used whatever is stock on 16.04. Always fails with gl error
[08:33] <zyga> mcphail: I see, may I ask which GPU you have and which drivers are you using?
[08:34] <dpm> davidcalle, have you tested the blender-tpaw snap?
[08:34] <mcphail> Not on the machine just now, but it is a 650 using whatever is latest prop driver from defaulr repo (352 i think)
[08:36] <mcphail> Same problem with a 430 running proprietary driver
[08:36] <davidcalle> dpm: yep, works great
[08:37] <dpm> davidcalle, awesome, in --devmode?
[08:37] <zyga> mcphail: which version of ubuntu-core-launcher or snap-confine do you have now?
[08:37] <davidcalle> dpm: strict :)
[08:37] <dpm> oh wow!
[08:38] <mcphail> zyga: I can't tell you, I'm afraid, as I'm IRCing from my phone
[08:38] <zyga> mcphail: woot :)
[08:38] <zyga> mcphail: stay in touch, I worked on a lot of improvements for nvidia
[08:40] <mcphail> zyga: good stuff. Hope it filters down! Have to steal the wife's laptop for graphical snaps just now :)
[08:44] <palasso> zyga: when updating the AUR PKGBUILD for the new version, consider updating the snapd.install with http://pastie.org/private/zbhszcpwn40trlthbcg7a
[08:47] <zyga> palasso: looking
[08:47] <palasso> zyga: the differences are very small, do a diff to see them ;) 1) removed line 1 2) removed 2 spaces in line 9 3) replaced installation with instructions in line 11
[08:48] <zyga> palasso: note that the next release will be in the community archive
[08:48] <zyga> palasso: but I'll pass this along to the maintainer
[08:49] <palasso> Ahh that's great!
[08:49] <palasso> Probably he'll remove this then, arch users are expected to check the archwiki or upstream documentation to see if there are any necessary units to enable/start or any kind of cleanup work to do
[08:50] <zyga> palasso: he's definitely more experienced than I am
[09:10] <Chipaca> pcoca: why are you making another snap of httpie?
[09:11] <Chipaca> pcoca: did you do "snap find httpie" before starting?
[09:16] <Chipaca> pcoca: ah, i missed the bit in the backlog where you said you already knew there was one
[09:16] <Chipaca> still don't understand why you're doing another though :-)
[09:27] <Chipaca> pcoca: welcome back
[09:27] <Chipaca> pcoca: not sure if you saw my answer above before your network awol'ed
[09:31] <pcoca> Chipaca, Yes, thanks.
[09:31] <pcoca> Chipaca, The snapcraft that I got is this one: https://github.com/pedrococa/httpie_snap/blob/master/snapcraft.yaml
[09:32] <pcoca> Chipaca, 1.0.0-dev version
[09:32] <Chipaca> pcoca: sorry to repeat my question, but why?
[09:33] <Chipaca> pcoca: is the existing httpie snap bad in some way?
[09:34] <pcoca> Chipaca, not at all, I just picked httpie as a learning one to make if from scratch and compare with an existing one if i got stuck.
[09:34] <Chipaca> pcoca: ah ok
[09:35] <Chipaca> pcoca: maybe it was a bad choice then :-)
[09:35] <Chipaca> pcoca: the existing httpie snap does not use snapcraft
[09:35] <Chipaca> pcoca: https://github.com/chipaca/httpie-snap
[09:37] <Chipaca> pcoca: I'm sure if I started doing it today I *would* use snapcraft
[09:37] <Chipaca> pcoca: but when I started it wasn't "there" yet
[09:37] <Chipaca> and now all the work is done, so ¯\_(ツ)_/¯
[09:37] <pcoca> Chipaca, yes, I saw it :) ... I wanted to use snapcraft for my version.
[09:38] <Chipaca> oh alright then
[09:38] <pcoca> Chipaca, I got some issues, and didrocks was able to help me.
[09:38] <Chipaca> pcoca: there are some environment variables that help
[09:38] <Chipaca> pcoca: look at the python wrapper I wrote
[09:38] <Chipaca> granted it's a bit messy and does more than set up the environ
[09:38] <Chipaca> but you've got HTTPIE_CONFIG_DIR
[09:39] <pcoca> Chipaca, I will, and also as my next learning step I will add the man pages.
[09:40] <Chipaca> pcoca: if all you are doing is shipping regular httpie, httpie --help is a manpage already, i think?
[09:40] <pcoca> Chipaca, Yes.
[11:08] <dpm> didrocks, David C mentioned you were looking at the VLC theming issues. Have you figured out what needs to be done to get the theme working? Is it a matter of having a 'themes' interface?
[12:29] <didrocks> dpm: I do have some workarounds working for the theme
[12:29] <didrocks> dpm: I still have 2 issues as of now with my new qt launcher:
[12:29] <didrocks> 1. appmenu export (works only in devmode)
[12:29] <didrocks> 2. icon themes (the gtk ones aren't loaded)
[12:30] <didrocks> I'm going to look at it this afternoon with seb
[12:30] <didrocks> I have a last idea that I got while running :)
[12:35] <kyrofa> didrocks, I'm curious to see where you get with that
[12:35] <kyrofa> Can you let me know if you get it working?
[12:36] <didrocks> kyrofa: sure! I'm taking your example app btw while working on this :)
[12:36] <kyrofa> didrocks, yay! That's exactly what I was thinking of fixing with your results :P
[12:37] <didrocks> ahah, you will be the #1 demo! :)
[12:37] <kyrofa> Woohoo!
[12:37] <didrocks> well, there is a difference
[12:37] <didrocks> I remove your plugin
[12:37] <kyrofa> Of course
[12:37] <didrocks> "someone" did the qmake plugin in snapcraft
[12:37] <didrocks> not sure who is this guy :p
[12:37] <kyrofa> Yeah that person must have been amazing
[12:37] <didrocks> exactly!
[12:37] <didrocks> :)
[12:38] <didrocks> more seriously, I'll keep you posted
[12:38] <kyrofa> Thank you :)
[12:38] <didrocks> the concerning part is that our dependency chain is pulling both gtk2 and gtk3 though
[12:38] <didrocks> if we want the theme in :p
[12:38] <kyrofa> Yikes
[12:38] <didrocks> isn't it?
[12:38] <didrocks> we need at least one for the theme
[12:38] <didrocks> the 2… hum :p
[12:38] <didrocks> (because we don't have compatibility qt theme engine under unity)
[12:38] <didrocks> it's only the gtk one
[12:47] <davidcalle> jdstrand: hey, when you have a minute, could you have a look at this: http://paste.ubuntu.com/18166127/ ? This is what happens when using the mpris slot in VLC and trying to look at it with d-feet (I do see it in the list of dbus interfaces, but when I click on it to get details, ths error happens, VLC does not appear in the sound menu as well)
[13:00] <jdstrand> davidcalle: note that I couldn't get vlc in the sound menu and there were no apparmor denials. I think that must have something to do with the packaging
[13:00] <jdstrand> davidcalle: as for d-feet-- what version of snapd do you have installed?
[13:05] <davidcalle> jdstrand: 2.0.10+ppa145-1
[13:06] <jdstrand> davidcalle: can you paste 'grep audit /var/log/syslog'?
[13:06] <dholbach> seb128, have you seen this already: https://github.com/ubuntu/snappy-playpen/issues/128?
[13:07] <seb128> jdstrand, can apps own their dbus name now?
[13:07] <jdstrand> seb128: not yet: https://github.com/snapcore/snapd/pull/1446
[13:07] <seb128> dholbach, unsure what he means by url-to-path
[13:08] <seb128> jdstrand, isn't that needed for mpris?
[13:08] <dholbach> seb128, me neither
[13:08] <seb128> dholbach, but I guess gvfs doesn't work, I can have a look now
[13:08] <jdstrand> seb128: no. mpris is different
[13:08] <dholbach> seb128, should this be a bug report somewhere else?
[13:08] <seb128> dholbach, against the snap?
[13:08] <jdstrand> seb128: mpris needs a different dbus api
[13:09] <jdstrand> seb128: so it got a different interface
[13:09] <seb128> jdstrand, k, you mean to get the player listed in the sound menu there?
[13:09] <dholbach> seb128, oh... I thought it was a more general thing?
[13:09] <jdstrand> seb128: that is in 2.0.10
[13:09] <seb128> dholbach, well, it's the same class of issues, snappy forces you to bundle things but that's sort of by design
[13:09] <jdstrand> seb128: as mentioned to davidcalle-- I could not get vlc to show up in the sound menu. I think it is a packaging issue (no denials)
[13:10] <jdstrand> davidcalle: can you also paste the meta/snap.yaml for vlc?
[13:13] <davidcalle> jdstrand: http://paste.ubuntu.com/18167536/  http://paste.ubuntu.com/18167588/
[13:14] <jdstrand> davidcalle: I don't see any dbus denials
[13:15] <jdstrand> davidcalle: is this the vlc that is in the store now?
[13:16] <davidcalle> No, that's what in the store + camera, optical-drive, mpris
[13:17] <jdstrand> ok, then that's similar to mine
[13:17] <jdstrand> let me try this locally. I tested d-feet
[13:18] <jdstrand> so it should work, but maybe I missed something. give me a few minutes
[13:18] <davidcalle> jdstrand: the source (minus the new interfaces) is here https://github.com/ubuntu/snappy-playpen/tree/master/vlc
[13:19] <sergiusens> didrocks are you a pkg-config expert?
[13:20] <seb128> sergiusens, don't ask to ask just ask
[13:20] <seb128> others might be able to reply
[13:20] <seb128> and non experts as well
[13:20] <didrocks> sergiusens: I did play with it quite a lot, but I'm not alone either :)
[13:20] <didrocks> what's up?
[13:22] <sergiusens> didrocks I am playing with this https://github.com/snapcore/snapcraft/pull/612/files which allows mhall119 to build pantheon mail but it breaks everything else
[13:22] <sergiusens> didrocks all due to sysroots most likely, you need to satisfy all your pc deps in the same sysroot
[13:23] <sergiusens> didrocks I am thinking of biting the bullet and rewriting all .pc files as part of snapcraft to get the correct paths and just forget the use of sysroot and just add to pkg_config_path
[13:24] <didrocks> let me have a look (in a meeting, but will do just afterwards)
[13:25] <sergiusens> didrocks k, I would really like to explore the latter approach though :-)
[13:28] <seb128> sergiusens, easiest way would be to build in a contained env with the local and system /usr merged with a mount namespace?
[13:30] <sergiusens> seb128 merged or overlayed? I would still need some mechanism to track what came from where while building
[13:30] <seb128> any, just "merged"
[13:33] <tsimonq2> elopio: when you get a minute, could you please look at https://github.com/snapcore/snapcraft/pull/619 ?
[13:33] <didrocks> hum
[13:33] <didrocks> I maybe don't understand well enough
[13:33] <didrocks> but you didn't just try to export PKG_CONFIG_PATH?
[13:34] <didrocks> instead of using the PKG_CONFIG_LIBDIR, which erase system's defaults pc
[13:35] <didrocks> that way you get those from the sysroot and the stage/ dir?
[13:39] <popey> sergiusens: do we have a bug for this? It affects a few things I want to package :)
[13:42] <sergiusens> popey you know I do
[13:42] <seb128> jdstrand, davidcalle, k, I know why vlc is not listed in the sound menu
[13:42] <popey> I do? ok.
[13:42] <sergiusens> didrocks if I don't change the sysroot for each location then the include paths pkg-config returns will be wrong
[13:43] <sergiusens> which is why seb128 advocates for merging /usr (which opens a different set of problems)
[13:46] <jdstrand> davidcalle: I can confirm the issue with d-feet. I think there wasn't a log due to kernel rate limiting. 'snappy-debug.security scanlog' would disable that for you, but you can also use sudo sysctl -w kernel.printk_ratelimit=0
[13:46] <seb128> jdstrand, vlc has its dbus property DesktopEntry = vlc or the snap .desktop is vlc_vlc.desktop, if you rename/copy it as /var/lib/snapd/desktop/applicatons/vlc.desktop it's added as it should, we wouldn't be hitting those bug if we were using upstream .desktop (bug #1576595)
[13:46] <seb128> sergiusens, ^ can we get that on the next milestone list somewhat?
[13:46] <seb128> the current design breaks users and doesn't allow for easy translations
[13:46] <didrocks> sergiusens: sorry, what do you mean for each location? basically your parts sysroots are depending on 3 folders, right? your insider build/, your stage and system root path?
[13:47] <sergiusens> seb128 I need to have a heated discussion with a couple of people first
[13:47] <jdstrand> note we are generating the desktop file for safety since the desktop file specification is rich
[13:47] <sergiusens> didrocks parts/<part>/install, stage and /
[13:47] <seb128> sergiusens, can I be included? I'm curious to know they argument for reinventing the wheel
[13:47]  * ogra_ hands sergiusens icecream for the heated discussion
[13:47] <jdstrand> obviously we should support this case, but taking the upstream file might not be the way to go
[13:47] <seb128> like we have upstream providing those including translations
[13:47] <jdstrand> I guess this is all part of said heated discussion
[13:48] <seb128> jdstrand, no, but taking the upstream one would make sense, we are duplicating it for a non translated copy that get outdated just to be able to change the Exec, why just not copying with a sed?
[13:48] <sergiusens> seb128 well all this is a snappy thing; there are some comments about doing something smart, but that doesn't cope well with replacing what needs replacing; I want to make it declarative
[13:48] <seb128> yeah, fine
[13:48] <seb128> get the yaml to have
[13:48] <seb128> desktop:
[13:48] <seb128> command: <bla>
[13:48] <seb128> icon: <great>
[13:48] <seb128> and sed those
[13:48] <seb128> you can also have url:
[13:49] <seb128> to point to the upstream one you want to sed/copy
[13:49] <jdstrand> seb128: verifying a rich specification is much harder than generating your own subset
[13:49] <sergiusens> seb128 yes, that is my idea
[13:49] <seb128> jdstrand, well, everything in that spec is useful and needed
[13:49] <seb128> they wouldn't be there is they weren't
[13:49] <jdstrand> which is why it is the way it is. again, obviously this issue needs to be fixed, I'm just saying why the situation is what it is
[13:49] <jdstrand> you could say that about anything
[13:49] <sergiusens> I sent a gazillion emails, requests and even commented on the reviews to not due freaking things by convention as it would be super hard to deal with all the corner cases this would bring
[13:50] <jdstrand> that spec was not designed for snappy
[13:50] <jdstrand> it was designed for the old world
[13:50] <seb128> well, fine
[13:50] <seb128> copy the Name/Comment from upstream at least
[13:50] <seb128> those for sure make sense and are safe?
[13:50] <seb128> that would give you translations
[13:50] <seb128> and non duplication of strings
[13:51]  * jdstrand notes that he is not the blocker on this but just knows a bit about the previous conversation and issues
[13:51] <seb128> jdstrand, do you have any of those keys that you see unfit for snappy though?
[13:51] <seb128> like ShowOnlyIn is also useful in snappy
[13:51] <seb128> as are the NotShowIn&co
[13:52] <seb128> same for MimeType
[13:52] <seb128> which is another funny/buggy thing today
[13:52] <seb128> if you snap gedit you can't get it to open files when clicking on those
[13:52] <jdstrand> what you are suggesting would need proper review of the desktop file specification and design of what is appropriate for snappy and how
[13:52] <seb128> yes
[13:53] <jdstrand> I don't have a list of unfit things otoh because that design hasn't happened
[13:53] <seb128> or review and flag things to filter out
[13:53] <seb128> my guess there is that it's little or nothing
[13:53] <jdstrand> better to say what is ok to let in and filter everything else out
[13:54] <seb128> my guess is that it would have taken less time to do that upfront that redesign a buggy solution temporary solution and dealing with the issues it creates
[13:54] <jdstrand> seb128: can you tell me exactly what I need to do to test vlc in the sound menu? I was a little confused by your previous comment
[13:54] <seb128> jdstrand, sudo cp /var/lib/snapd/desktop/applications/vlc_vlc.desktop /var/lib/snapd/desktop/applications/vlc.desktop
[13:54] <jdstrand> seb128: you are assuming that snappy on classic was a thing when this was implemented
[13:54] <seb128> jdstrand, then start vlc and play a sound
[13:55] <seb128> well works at least in devmode here
[13:55] <jdstrand> weird
[13:55] <seb128> I didn't try in non-dev because I didn't have my snapd updated yet
[13:55] <jdstrand> I don't have /var/lib/snapd/desktop/applications/vlc_vlc.desktop
[13:55] <jdstrand> maybe I have a too old vlc
[13:55] <seb128> I just did a fresh snap install vlc on and amd64 xenial machine with snappy 2.0.9
[13:56] <seb128> jdstrand, do you have any .desktop in there?
[13:56] <jdstrand> krita
[13:56] <jdstrand> seb128: are you building vlc from snapcraft or installing from the store?
[13:56] <davidcalle> jdstrand: store vlc has one
[13:56] <seb128> jdstrand, cf 2 lines up ;-)
[13:57] <seb128> "snap install vlc"
[13:57] <seb128> sorry that was meant as typing that command
[13:57] <seb128> so store version
[13:57] <jdstrand> yeah, I'm grabbing it
[13:57] <seb128> cool
[13:57] <jdstrand> the store one doesn't have the camera, optical-drive or mpris changes
[13:58] <jdstrand> so I need to grab the store one, unpack, adjust, repack, etc
[13:58] <jdstrand> I think I just had an old repack
[14:00] <jdstrand> davidcalle: ok, I see the problem. I think this is only an issue with d-feet's way of introspecting. I added rules to support introspection for 'snap connect'ing vlc to a remote, but not for unconfined on classic. this is a minor bug that I'll fix in a minute
[14:01] <jdstrand> davidcalle: now that seb128 told me how to test the indicator, I'll test that too. there may be adjustments there as well
[14:02] <davidcalle> jdstrand: thank you for this
[14:10] <seb128> dholbach, sorry things got a bit crazy and I think I forgot to reply to you
[14:10] <seb128> dholbach, or I did, don't remember
[14:10] <seb128> dholbach, for gvfs my guess is that you need to bundle the gvfs gio .so
[14:10] <dholbach> seb128, I asked for an example in the bug report
[14:10] <seb128> k
[14:16] <jdstrand> davidcalle: meh, the version in the store does something different with mpris :\
[14:16] <davidcalle> o_o
[14:16] <jdstrand> actually, maybe not
[14:18] <davidcalle> jdstrand: most recent commit on vlc master is older than the latest store snap version, there should be no diff there
[14:18] <jdstrand> davidcalle: ok, strike that, I did something dumb
[14:21] <jdstrand> davidcalle, seb128: ok, in strict mode after copying the desktop file, it shows up in the indicator and I can stop/play/etc
[14:22] <jdstrand> davidcalle: so, yes, I'll fix the d-feet issue, but that is minor and specific to d-feet (or anything introspecting, but not the indicator)
[14:22] <seb128> jdstrand, \o/
[14:23] <jdstrand> using 'slots: [ mpris ]' of course
[14:23] <davidcalle> jdstrand: brilliant! Can you paste the desktop file you have now?
[14:23] <seb128> it's the same
[14:23] <seb128> just renamed
[14:23] <seb128> using the upstream name
[14:23] <jdstrand> davidcalle: all I did was cp vlc_vlc.desktop vlc.desktop like seb128 suggested
[14:23] <davidcalle> Oh
[14:23] <jdstrand> it worked fine
[14:23] <seb128> vlc has a properties that it export over dbus with the name
[14:23] <seb128> in the mpris interface
[14:24] <seb128> which has vlc
[14:24] <davidcalle> I see
[14:27] <zyga> jdstrand: hey, how is snapd 2.0.10 and vlc?
[14:27] <jdstrand> zyga: I just reported on that :)
[14:28] <kyrofa> zyga, jdstrand where is snap-exec?
[14:28] <jdstrand> zyga: it works great with one thing: the desktop file should be named 'vlc.desktop' instead of 'vlc_vlc.desktop'
[14:28] <zyga> jdstrand: is the name of the desktop file significant?
[14:28] <zyga> jdstrand: AFAIR now it is just $SNAP_NAME.$APP_NAME
[14:29] <zyga> kyrofa: in snapd
[14:29] <iliv> if my binary is under prime/bin/ what should my apps: definition look like? bin/mybinary?
[14:29] <zyga> iliv: apps: somename: command: mybinary
[14:29] <zyga> iliv: (assuming mybinary is on PATH)
[14:29] <jdstrand> zyga: if vlc adds 'slots : [ mpris ]'. I didn't test camera and optical drive, but I did test that specifying them in the yaml generates the policy
[14:30] <zyga> jdstrand: I tested both
[14:30] <zyga> jdstrand: but I'll test everything again if you have a snap handy
[14:30] <jdstrand> zyga: I don't have a lot of insight into the desktop file name. seb128 indicated it is significant at least for vlc
[14:30] <zyga> seb128: can you tell me more about that
[14:30] <zyga> seb128: we can fix that easily for .11
[14:31] <davidcalle> zyga: for me camera doesn't seem to work
[14:31] <iliv> zyga, where does the PATH come from? I certainly did not specify it anywhere myself.
[14:31] <seb128> zyga, in an hangout but basically vlc (and some other program) look for their known .desktop name
[14:31] <jdstrand> zyga: I do have a snap handy, but it would probably take longer for me to upload and you to download than for you to 'snap install vlc', grab the snap from /var/lib/snapd/snaps, unsquashfs it, modify meta/snap.yaml accordingly, then snapcraft snap ./squashfs-root, then remove/install the new snap
[14:32] <kyrofa> zyga, ah, it must be u-c-l then. Is that still on LP, or in github nowadays?
[14:32] <jdstrand> which, I have to say, is a convenient property of snaps
[14:32] <zyga> kyrofa: no, that's in snapd itself
[14:32] <davidcalle> zyga: I can push one to the edge channel if you want to, but my network tells me it will be faster for you to do ^ :)
[14:32] <zyga> kyrofa: in the repo
[14:32] <kyrofa> zyga, sorry, no-- the problem I'm running into must be u-c-l
[14:33] <zyga> davidcalle: please push it, I have network issues
[14:33] <davidcalle> zyga: alright
[14:33] <zyga> jdstrand: ah
[14:33] <jdstrand> zyga: is the new u-c-l upload planned? I thought it was going to accompany 2.0.10
[14:33] <zyga> jdstrand: yes, please share the meta.yaml
[14:33] <zyga> jdstrand: it is coming
[14:33] <zyga> jdstrand: just last minute stuff
[14:34] <jdstrand> zyga: great :)
[14:34] <jdstrand> zyga: http://paste.ubuntu.com/18171909/
[14:34] <jdstrand> zyga: if you rename the desktop file, then it shows up in indicator sound and that works :)
[14:34] <jdstrand> fun stuff :)
[14:37] <kyrofa> jdstrand, is u-c-l still in LP?
[14:38] <jdstrand> kyrofa: yes. auiu the snappy team is going to continue to use that name for the source package in xenial
[14:38] <kyrofa> jdstrand, ah, even when it actually changes to snap-confine?
[14:38] <jdstrand> yes
[14:38] <kyrofa> Makes sense
[14:38] <jdstrand> there will be transition binaries in the xenial packaging
[14:43] <kyrofa> jdstrand, am I being dumb? I thought it was here: https://launchpad.net/ubuntu-core-launcher
[14:50] <zyga> jdstrand: I'll look at it in a sec, just in a meeting now
[14:51] <jdstrand> kyrofa: that is the lp project
[14:51] <kyrofa> jdstrand, it's a 404 for me
[14:51] <jdstrand> kyrofa: snap-confine has moved to github
[14:52] <kyrofa> jdstrand, what's running xenial today? It's still the LP u-c-l, right?
[14:52] <jdstrand> kyrofa: https://github.com/snapcore/snap-confine
[14:52] <jdstrand> kyrofa: today it is https://launchpad.net/ubuntu/+source/ubuntu-core-launcher
[14:53] <kyrofa> Ah, that's what I was looking for, thanks!
[14:53] <kyrofa> Wait... no source there? I guess I can just pull the source deb
[14:53] <jdstrand> kyrofa: in other words, the u-c-l LP project is gone and moved to snap-confine on github, but the Ubuntu sources for u-c-l live on in the archive
[14:53] <kyrofa> Ah, okay that explains my confusion :)
[14:53] <jdstrand> kyrofa: right, source deb
[14:54] <jdstrand> and it is the Ubuntu source deb that, aiui, will remain named as u-c-l for xenial, but have the snap-confine code, when that happens (soon I'm told)
[14:55] <zyga> kyrofa, jdstrand: it's been renamed everywhere except for the source package AFAIK
[14:55] <jdstrand> right
[14:55] <zyga> eh. google down :/
[14:55] <zyga> time to get a coffee
[14:55] <jdstrand> yeah
[14:55] <jdstrand> annoying
[14:55] <zyga> they should adopt snaps, at least there's rollback :)
[14:55] <kyrofa> zyga, is there though? :P
[14:55] <kyrofa> zyga, has it been released?
[14:58] <zyga> kyrofa: hmmm
[14:58] <zyga> maybe not released, .11 ?
[14:58] <kyrofa> Indeed. I stopped touting that feature until it actually worked
[14:58] <kyrofa> Got called on it too many times :P
[15:00] <kyrofa> zyga, too late to get something into the snap-confine upload?
[15:05] <tsimonq2> sergiusens: when you get a minute, could you please look at https://github.com/snapcore/snapcraft/pull/619 ?
[15:05] <zyga> kyrofa: nope
[15:05] <zyga> kyrofa: gimme!
[15:05] <kyrofa> zyga, a little modification to the appname whitelist to allow hooks
[15:05] <zyga> kyrofa: I was planning to do the release at EOD and that's still far a way
[15:06] <zyga> kyrofa: sure, just send it in
[15:06] <kyrofa> zyga, alright, will do
[15:06] <zyga> kyrofa: and <3 hooks :)
[15:06] <sergiusens> tsimonq2 yeah, enqueued
[15:06] <tsimonq2> thank you sergiusens
[15:07] <kyrofa> zyga, also, I see that run-checks only runs spread tests. Are you moving away from the tests dir?
[15:08] <sergiusens> kyrofa mind looking at https://github.com/snapcore/snapcraft/pull/617
[15:08] <zyga> kyrofa: that's somewhat confusing, tests/ is ran at package build time
[15:08] <zyga> kyrofa: which is done by spread
[15:08] <kyrofa> zyga, oh, haha, okay
[15:08] <zyga> kyrofa: but yes,  we do move oaway from tests/ today
[15:09] <zyga> kyrofa: because when snap-exec hits, those will all break
[15:09] <zyga> kyrofa: and they don't really test the real code entirely, just the seccomp part
[15:09] <zyga> kyrofa: I plan to port them to spread
[15:09] <kyrofa> zyga, so there are already whitelist tests in tests/. I was going to just add to that, but I can add a spread test instead if you prefer
[15:09] <zyga> kyrofa: I'd prefer a spread test
[15:09] <kyrofa> zyga, okay
[15:09] <zyga> kyrofa: or a unit test :)
[15:09] <zyga> kyrofa: if this is easier to do as a unit test
[15:09] <kyrofa> zyga, where are the units? It probaby would be, yeah
[15:09] <zyga> kyrofa: or more sane, you pick
[15:09] <zyga> kyrofa: landing in a sec
[15:10] <kyrofa> zyga, ah ha :)
[15:10] <zyga> kyrofa: I was just distracted with arch discussion elsehwere
[15:10] <kyrofa> zyga, yeah, ping me when that lands and I'll pull and add
[15:10] <zyga> yep
[15:12] <davidcalle> zyga: I did domething wrong apparently. Rebuilding the snap... hold on, I'll ping you when it's on the edge channel. :)
[15:13] <zyga> davidcalle: OK
[15:37] <zyga> kyrofa: ok, fire away
[15:37] <zyga> kyrofa: you can run make check in src/ to run unit tests
[15:37] <zyga> kyrofa: or you can use the appropriate spread task
[15:37] <zyga> kyrofa: to add one just look at mount-support-test.c
[15:38] <kyrofa> zyga, excellent, doing now, thanks!
[15:38] <zyga> kyrofa: you essentially need a static test function
[15:38] <zyga> kyrofa: and a static initializer that registers it
[15:42] <kyrofa> zyga, FYI mount-support-test.c copyright is 2015
[15:47] <ogra_> living in the past
[15:47] <davidcalle> I can confirm vlc<->mpris and camera work. Can't test dvd. Very slow upload to the edge channel in progress... /me goes pick up the kids in the meantime
[15:48] <zyga> davidcalle: try an audio CD
[15:49] <zyga> davidcalle: thanks for testing!
[15:49] <zyga> ogra_: why? :)
[15:49] <seb128> tedg, jdstrand, didrocks, debugging appmenu for qt5 with didrocks, seems like with a qt5 example the path is "/MenuBar/1" and not "/MenuBar" which triggers apparmor errors ... would "/MenuBar*" works/be correct? or "/MenuBar/[0-9]*"?
[15:49] <ogra_> zyga, dunno, you tell me )
[15:50] <zyga> because you smoke! quit already man :)
[15:50] <zyga> ;-)
[15:52] <ogra_> lol
[15:52] <ogra_> you sound like my dentist
[15:56] <didrocks> jdstrand: btw, it was puzzling because the denial wasn't in auditlog, but only in syslog. The label was correct though.
[15:57] <zyga> jdstrand: what's the policy for fix commited on ubuntu tasks?
[15:57] <zyga> jdstrand: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1595029
[15:59] <zyga> jdstrand: can we close this bug: https://bugs.launchpad.net/snap-confine/+bug/1460517
[16:00] <zyga> kyrofa: is this still applicable to snap-confine? https://bugs.launchpad.net/snap-confine/+bug/1559248
[16:00] <kyrofa> zyga, no, that's done in snap run now
[16:00] <zyga> kyrofa: cool, let's close the snap-confine task then
[16:03] <jdstrand> zyga: for Ubuntu, it is marked fix committed when it is in -proposed
[16:04] <zyga> jdstrand: ah, I see, thanks!
[16:04] <dholbach> all rightie - I call it a day - see you next week Monday!
[16:04] <ogra_> enjoy your long weekend !
[16:04] <zyga> jdstrand: I know we talked about it but if you have a moment, can you write something on https://bugs.launchpad.net/snap-confine/+bug/1595092 -- this is the last current NEW bug on snap-confine
[16:04] <zyga> dholbach: o/
[16:04]  * zyga envies long weekend :)
[16:05]  * ogra_ too
[16:05] <jdstrand> zyga: I closed 1460517 just now
[16:07] <jdstrand> tyhicks: I can't recall what we said about bug #1595092 - I thought we decided either you or sarnold_ would comment since you did the code review of that part of the code, but maybe I am making that up :)
[16:09] <kyrofa> zyga, is there a reason you're not just making a lib and linking to it from the tests?
[16:09] <kyrofa> Including .c files feels dirty :P
[16:16] <tyhicks> jdstrand: I don't think I've seen that bug before
[16:18] <zyga> kyrofa: yes, static function
[16:18] <zyga> kyrofa: it's a "pick your poison" problem either ifdefs or this
[16:19] <zyga> kyrofa: I like how it has a -test.c theme that looks closer to go
[16:19] <zyga> kyrofa: I know it cannot be really go because of translation units vs modules
[16:19] <zyga> kyrofa: but it's better than nothing :)
[16:19] <tyhicks> jdstrand: I left a comment and will discuss with Seth some more once he joins
[16:19] <jdstrand> cool, thanks
[16:19] <didrocks> seb128: jdstrand: FYI, /MenuBar* doesn't work (/MenuBar/* works), but we need as well /MenuBar for gtk
[16:19] <jdstrand> tyhicks: I guess you're saying I made that up then? :P
[16:19] <seb128> didrocks, thanks for trying
[16:20] <jdstrand> didrocks: please file a bug with steps to reproduce and add the 'snapd-interface' tag
[16:20] <didrocks> jdstrand: we can even add a PR ;) it's apparmor?
[16:20] <didrocks> or snapd?
[16:21] <jdstrand> it's snapd, but if doing a PR, ping me
[16:21] <didrocks> sure! (a task for tomorrow now, EOD), seb or I will do!
[16:21] <tyhicks> jdstrand: one of us is forgetful but I'm not sure which one it is :)
[16:22] <jdstrand> didrocks: fyi, ./interfaces/builtin/unity7.go. note, I'm off tomorrow and Monday, but I'll look at it Tuesday which is more than enough time to get it in 2.0.11. if you need it sooner, you might ask another member of the security team
[16:31] <tsimonq2> !info default-jdk
[16:31] <tsimonq2> !info default-jdk wily
[16:38] <davidcalle> zyga: jdstrand: fyi, vlc in edge
[16:40] <zyga> davidcalle: \o/
[16:41] <zyga> davidcalle: great, I'll play with it soon
[17:09] <zyga> kyrofa: will you provide the hook patch today?
[17:09] <kyrofa> zyga, yeah, almost done
[17:09] <zyga> kyrofa: I'm looking at a release in 1-2 hours or later after the portugal/poland game
[17:10] <zyga> kyrofa: thanks!
[17:10] <kyrofa> zyga, the udev profiles not containing periods is taking me a little while to work around
[17:17] <kyrofa> Err, the tag rather
[17:33] <kyrofa> zyga, alright, take a look: https://github.com/snapcore/snap-confine/pull/64
[17:33] <kyrofa> zyga, I also copied the regex from snapd to reflect it a bit more closely
[17:41] <zyga> kyrofa: have a look at this one in return please: https://github.com/snapcore/snap-confine/pull/65
[17:48] <zyga> kyrofa: reviewed
[17:49] <zyga> kyrofa: just one change and few nitpicks
[17:53] <kyrofa> zyga, also reviewed yours. By the way, looks like travis isn't able to authenticate to linode?
[17:55] <zyga> kyrofa: yes, that's my fault; there's something I have to do but I was putting it off
[17:55] <zyga> kyrofa: spread.yaml doesn't list the key
[17:55] <zyga> kyrofa: the key is in travis itself
[17:55] <zyga> kyrofa: but that apparently doesn't work for forks at all
[17:55] <zyga> kyrofa: to compute a key I can stick into spread.yaml I'd have to install a bunch of ruby stuff
[17:56] <kyrofa> zyga, haha, I have the travis gem if you want me to do it
[17:56] <zyga> kyrofa: and I just want to do that in a vm/container that I throw away later
[17:56] <zyga> kyrofa: if you can, please
[17:56] <zyga> kyrofa: if you have the spread key
[17:56] <zyga> kyrofa: please add it
[17:56] <kyrofa> zyga, I don't actuallly-- want to email it to me? You can encrypt it if you like
[17:57] <zyga> kyrofa: that's okay, I'll get the gem eventually :)
[17:57] <kyrofa> Okay
[18:24] <kyrofa> zyga, I left a few questions for you on my PR
[18:25] <zyga> kyrofa: checking
[18:26] <zyga> kyrofa: merged, thank you!
[18:27] <kyrofa> Thanks zyga!
[18:30] <juanrubio> \quit
[18:46] <zyga> kyrofa: can you have a 2nd look on https://github.com/snapcore/snap-confine/pull/65/files
[18:46] <zyga> kyrofa: something as simple as is_subdir and still can be broken
[18:54]  * zyga -> off to watch the game
[18:54] <kyrofa> zyga, done!
[18:54] <kyrofa> Looks good
[18:54] <zyga> woot; thanks :)
[19:44] <thomi> Hey snappy experts: I have a python snap (built with python2 snapcraft plugin) that's really not very happy - I get this when trying to run the command: http://paste.ubuntu.com/18191348/
[19:44] <thomi> does anyone have any ideas? The same source, when installed to a py2 virtualenv works fine
[20:02] <zyga> thomi: odd, no idea
[20:02] <zyga> thomi: can you triple check that your snap ships python2
[20:02] <thomi> :(
[20:02] <zyga> thomi: I recommend adding busybox app / part to your snap
[20:02] <zyga> thomi: then run busybox sh to experiment
[20:03] <zyga> thomi: you can check environment, etc
[20:03] <thomi> zyga: /snap/sofastats/x1/usr/bin/python2.7 exists
[20:03] <thomi> ahh - nice tip
[20:03] <zyga> sergiusens: ^^
[20:03]  * zyga off to watch 2nd part of POL vs POR game
[20:06] <thomi> I didn't know those countries played cricket ;)
[20:30] <zyga> thomi: heh :)
[20:33] <thomi> zyga: I think I might be hitting confinement issues - I see apparmor denials in syslog when trying the busybox hack, which is odd, since it's a devmode snap
[20:33] <thomi> My understanding is that devmode snaps should essentially have confinement turned off?
[20:34] <zyga> thomi: paste one line here
[20:36] <thomi> zyga: hmmm - when I try it in a new shell it works fine. Perhaps I had something set that caused breakage
[20:36] <thomi> zyga: but I can confirm that python is installed, and seems to work
[20:37] <tyhicks> sarnold: hey - could you double check my comment in bug #1595092?
[20:38] <thomi> zyga: ahh, but the #! line on the app still points to the python interpreter in my snapcraft 'parts' directory. Shouldn't that be updated to point to the python installed in /snap/<snapname>/current/usr/bin/ ?
[20:43] <sergiusens> zyga what?
[20:44] <thomi> sergiusens: what should the #! line of a python script in a snap be that's been built with the python2 plugin? It should point to the shipped python2 interpreter, right?
[20:44] <sergiusens> thomi we already had barry log a bug about that on python
[20:44] <thomi> sergiusens: the bug is in python itself?
[20:45] <sergiusens> thomi all setup_scripts and such get that; what we are doing in snapcraft is calling python or python3 on the declared command
[20:45] <sergiusens> thomi setuptools overwrites shebangs and there is no way to disable it
[20:45] <thomi> sergiusens: ahh ok, so it's probably not the cause of my issue then
[20:47] <thomi> sergiusens: however, the script is still trying to open the stdlib from my parts directory: Jul  1 08:46:36 thinkpad kernel: [185816.217465] audit: type=1400 audit(1467319596.615:122): apparmor="DENIED" operation="open" profile="snap.sofastats.sofa" name="/home/thomi/code/snapcraft/sofa/parts/sofa/install/usr/lib/python2.7/os.py" pid=19150 comm="sofa"
[20:47] <thomi> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[20:49] <thomi> sergiusens: I think it's because the command wrapper ends in "exec "sofa" "$@""
[20:49] <thomi> sergiusens: so we're not explicitly invoking the python in the snap, but rather using the python mentioned in the scripts !# line
[20:50] <thomi> does that make sense?
[21:02] <sergiusens> thomi let me check the code, this was a nice contribution from BjornT_
[21:02] <sergiusens> kyrofa mind looking at this https://github.com/snapcore/snapcraft/pull/620 ? I am still missing one thing, installdir
[21:02] <thomi> sergiusens: thanks - I'm on snapcraft version 2.11 BTW
[21:03] <sergiusens> thomi no worries, everyone should have this fix by now...
[21:05] <sergiusens> thomi so wait, I might go faster if I see your yaml
[21:07] <sergiusens> thomi so https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta.py#L190 is the logic, it should have the correct statement
[21:08] <thomi> sergiusens: hmm - this is in snapcraft 2.11?
[21:08] <sergiusens> thomi but, the command needs to be a full relative path or else... https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/meta.py#L218
[21:08] <sergiusens> thomi yeah, no worries, you found a bug it seems
[21:08] <sergiusens> should be easy to fix
[21:09] <sergiusens> thomi as a workaround though, instead of `command: sofa` try `command: bin/sofa` (or usr/bin or whatever applies)
[21:09] <thomi> cool
[21:09] <sergiusens> and that would confirm this
[21:09] <thomi> sergiusens: will do, thanks
[21:10] <sergiusens> if you want to log a bug I will fix faster too :-P
[21:11] <thomi> sergiusens: that workaround does indeed fix the issue
[21:11] <thomi> sergiusens: sure thing - bugs on github or lp?
[21:12] <sergiusens> thomi https://bugs.launchpad.net/snapcraft/+filebug
[21:13] <thomi> ta
[21:18] <thomi> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1597919 hope that's clear enough
[22:02] <jdstrand_> davidcalle: fyi, this fixes d-feet with vlc: https://github.com/snapcore/snapd/pull/1460
[23:27] <mwhudson> wow snappy and go 1.7 do not get on very well
[23:33] <qengho> mwhudson: how so?
[23:33] <mwhudson> qengho: some json thing, i'll file a bug in a moment
[23:41] <mwhudson> hm or maybe my go tip build was out of date
[23:42] <mwhudson> yes seems so, phew
[23:43] <mwhudson> https://bugs.launchpad.net/snappy/+bug/1597948 is real though