[00:36] <qengho> ayan: Yes. Instead of extending snapcraft.BasePlugin, extend snapcraft.plugins.existingpluginmodulename.ExistingPluginClassName
[00:42] <ayan> ah  -- so also import snapcraft.plugins.existingplugin as well?
[00:43] <ayan> for for nil:
[00:43] <ayan> import snapcraft.plugins.nil
[00:43] <ayan> class Foo(snapcraft.plugins.nil.NilPlugin):
[00:43] <ayan>   ...
[00:46] <qengho> ayan: Yeah, s.plugins doesn't import all of its children or something, perhaps because it's trying not to pretend to know all of them that could be found, because plugins. Import the whole thing instead of trying to walk down the path from "snapcraft".
[00:47] <qengho> ^whole thing^specific thing
[00:47] <qengho> Zzzz
[00:47]  * ayan nods.
[05:13] <lathiat> when does snappy day start, uk time?
[05:20] <Hichhiker> do snaps allow/designed for permanent data storage across updates? I see $SNAP_APP_DATA_PATH - but it appears that that is a per-version location. Where does one place data to be kept with the app but not be lost due to update
[05:49] <didrocks> good morning
[06:01] <stevebiscuit> lathiat: the core team is mostly in mainland Europe, UK and S. America
[06:42] <popey> morning
[06:43] <didrocks> hey popey
[06:50] <dholbach> hello hello
[06:51] <didrocks> hey dholbach
[06:55] <popey> what's the most advanced (in terms of working) GTK app which has been snappified, which I could use as a template for another app? Is it seb128's GNOME calculator work from Prague?
[06:55] <popey> I assume Krita is the most advanced (in terms of working) KDE app?
[06:58] <dpm> good question - I think we really need at least one GTK app in the playpen, seb128 (morning!) where does the code for the desktop's team snaps live?
[06:59] <didrocks> argh, if I snapcraft clean an older project with newer snapcraft, it doesn't clean the parts/ directory
[06:59] <didrocks> I guess it's because they renamed it to prime but didn't handle older formats
[07:01] <dholbach> dpm, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
[07:02] <dpm> thanks dholbach :)
[07:02] <dpm> I wonder if we should make http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc a part as we did with the qt5 wrapper
[07:03] <dpm> I mean a wiki part
[07:04] <didrocks> that was my plan (but it seems my plan for the day changed)
[07:05] <dpm> hey, morning didrocks! - you mean you no longer think it's a good idea, or something in snapd has changed... or that you've got other things to do for the day?
[07:05] <didrocks> dpm: other things that happened unexpectly
[07:05] <dpm> ok ok
[07:06] <dpm> I was originally planning to have a go ad snapping Dekko, but I might actually give this a go instead
[07:15] <popey> The reason I asked is because there's a couple of gnomeish apps like Ardour and Inkscape which would be interesting to snap.
[07:16] <popey> and some KDEish ones like Kdenlive.
[07:16]  * dpm tries to build GNOME calc first
[07:39] <seb128> hey dpm dholbach popey
[07:39] <dholbach> salut seb128
[07:40] <popey> morning!
[07:40] <seb128> dpm, we don't have a shared space for snaps, just one main example which is the one dholbach pointed
[07:40] <seb128> and it's not hackish enough yet
[07:40] <dholbach> maybe we can add it to snappy playpen too?
[07:40] <seb128> like translations, input methods, etc don't work
[07:40] <dholbach> it'll be a WIP snap
[07:40] <seb128> dholbach, your call, as long as those ^ are not working I'm not "advertizing" anything
[07:41] <dholbach> right
[07:41] <dholbach> we want to collect best practices in there
[07:41] <seb128> "best"
[07:41] <seb128> don't use that calculator snap then :p
[07:41] <seb128> that's hackiest hacks
[07:43] <dholbach> I feel like we're currently in the stage, where we need to find hacks to make stuff work
[07:43] <dholbach> and then figure out how to make things work more generally
[07:43] <dpm> indeed
[07:46] <seb128> yeah, I'm just not able to find hacks that work for some of the things
[07:46] <seb128> I feel like hacks are not enough to get things fully working
[07:47] <seb128> we need more support from snappy itself
[07:52] <seb128> dpm, dholbach, I'm fine moving things to another place if you feel like it would be better
[07:55] <dpm> thanks seb128, for now we'll try to make a gtk part that can be edited in one place and reused by gtk apps
[07:56] <seb128> good luck getting one to work
[07:56] <seb128> I'm not wanting to recommend anyone to copy the shell hacks in the calculator used to copy schemas&co though
[07:58] <dpm> ok ok :)
[09:50] <d_ed> is there a way of handling i18n in the snapcraft descriptions?
[09:57] <ogra_> d_ed, see http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh and http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml
[09:57] <ogra_> that deals with basic locale support
[09:58] <didrocks> ogra_: I think d_ed is asking about the snapcraft.yaml file itself
[09:58] <didrocks> getting that translated
[09:58] <ogra_> didrocks,  well, there was support added for env vars inside snapcraft.yaml ....
[09:58] <ogra_> but i'm not sure that got released yet
[09:59] <didrocks> ogra_: how is it related to translating strings in snapcraft.yaml itself?
[09:59] <didrocks> like description
[09:59] <didrocks> or summary
[09:59] <ogra_> so 2/3 from the script above could live in snapcraft.yaml
[09:59] <ogra_> didrocks, aaah !
[09:59] <ogra_> got it :)
[10:00] <ogra_> (ignore me then :) )
[10:00] <d_ed> AFAIK debian packages didn't, but it's an important part of appstream
[10:00] <didrocks> :p
[10:00] <d_ed> and snapcraft metadata is sort of halfway between the two
[10:01] <ogra_> d_ed, definitely worth having a whishlist bug against snapcraft for that
[10:01] <didrocks> yeah
[10:03] <JamesTait> 👋  Morning, folks!
[10:04] <d_ed> ack, will do
[10:04] <d_ed> launchpad?
[10:05] <ogra_> yep
[10:05] <JamesTait> Can anybody offer advice to help me package ejabberd? https://github.com/jamestait/snappy-playpen/blob/master/ejabberd/snapcraft.yaml is what I have so far, but I then need to tweak a couple of files in snap/ to prepend $SNAP to some file locations.
[10:05] <ogra_> https://bugs.launchpad.net/snapcraft
[10:06] <JamesTait> I've got as far as an installable snap for amd64 with that, but only with the default config (I just need to relocate the config dir to $SNAP_DATA I think).
[10:12] <ogra_> JamesTait, use a wrapper script that parses the config ?
[10:14] <ogra_> (i'd use the config from SNAP_DATA, then have a startup wrapper script that checks if the target has a config file, if not, parse $SNAP/etc/ejabberd into $SNAP_DATA/etc/ejabberd and adjust the paths)
[10:16] <JamesTait> ogra_, maybe!  I'm not quite sure what the "standard" approach would be.  ejabberdctl is a bash script, which sets up some environemtn and calls erl, which is another bash script that sets up some environment and calls erlexec.
[10:17] <JamesTait> ogra_, so a wrapper would definitely work, but I wasn't sure it was the right approach - it feels a lot like replicating the functionality of ejabberdctl, so I wondered if I could just set some autoconf parameters and have it all magically work.
[10:18] <JamesTait> But for handling the config file, that makes a lot of sense - "if none exists, copy from the default location."
[10:20] <ogra_> well, if the builtin scripts can be handled by vars you can indeed just set the vars
[10:20] <ogra_> and use the default scripts
[10:23] <JamesTait> I'll give that a try then, as a next step.  I think I tentatively poked at that before and got some complaint about something needing to be an absolute path.
[10:51] <sabdfl> hi all, nice to be visiting the playpen from tokyo :)
[10:52] <dpm> \o/
[10:53] <sabdfl> hi dpm
[10:53] <dpm> hi
[10:56] <dpm> we're at https://gitter.im/ubuntu/snappy-playpen too, getting more apps added to the playpen
[11:38] <sabdfl> sergiusens, you were right, moving those deps to build-packages cleared the issue on gpsd
[11:43] <ogra_> hmm, i wonder ... if i put a desktop ... say lubuntu inside a snap ... and add aethercast and bluetooth support and some scrpitery ... if that could become a wireless thing client server ...
[11:44] <ogra_> thin
[11:55] <kyrofa> Too many chat clients open...
[11:56] <ogra_> heh
[12:00] <AndyWojo> Are system monitoring tools not great to make snaps of? Can they see the performance counters within the kernel?
[12:01] <AndyWojo> I wanted to create a snap of nmon
[12:01] <ogra_> you will definitely bbe able to use it in --devmode
[12:02] <ogra_> beyond that you will likely need some interfaces that might not be there yet ... (but without you creating a snap we wont know which ones you need, so go ahead, start with the snap and file bugs for the non --devmode cases)
[12:03] <AndyWojo> Great
[12:03] <AndyWojo> Thanks
[12:19] <sgclark> hi all
[12:20] <kyrofa> Hey there sgclark
[12:21] <dpm> morning sgclark o/
[12:25] <dpm> d_ed, not as far as I know. However, the store supports translations for descriptions of phone clicks, so I'm thinking it should support translations for descriptions of snaps too
[12:25] <dpm> JamesTait, that might be a question for you? ^
[12:50] <netphreak> Hi, guys!
[12:53] <ogra_> hey netphreak
[12:54] <dpm> hi netphreak :)
[12:54] <kgunn> mvo: you about?
[12:56] <kgunn> mvo: not sure what's going on (altho i was an early user?) but snap on classic i'm getting
[12:56] <kgunn> https://pastebin.canonical.com/158168/
[12:57] <JamesTait> dpm, sorry, what was the question?
[12:57] <mvo> kgunn: does it make a difference if you run this with sudo?
[12:58] <JamesTait> Metadata translations?
[12:58] <d_ed> JamesTait: yeah
[12:59] <JamesTait> There's a translations section in the package details page on myapps where you can add localised metadata for the phone scope and snap client to use.
[12:59] <dpm> JamesTait, exactly, are these supported in the store for snaps?
[12:59] <dpm> excellent
[13:00] <JamesTait> The snaps API works in exactly the same way as the clicks API in that regard - if the client sends the Accept-Language header, the response should be automatically translated.
[13:00] <JamesTait> Assuming the developer has entered the translations, of course.
[13:01] <kgunn> mvo: nope, same response
[13:01] <JamesTait> We currently don't support extracting translations from, say, snap.yaml or .desktop files.
[13:01] <ogra_> looks like snapd isnt running ?
[13:06] <mvo> kgunn: hm, in a meeting right now, could you please check the last few lines of /var/log/syslog
[13:06] <kgunn> ack
[13:06] <mvo> kgunn: and if there is nothing interessting in there, could you mail me the full syslog ? I will inspect it then and see if it gives me some clues
[13:07] <dpm> thanks JamesTait, d_ed hopefully that answers your question?
[13:07] <d_ed> yep
[13:07] <dpm> in short, you can enter translations in the store's web UI
[13:07] <dpm> ok, cool
[13:11] <kgunn> mvo: ta
[13:11] <kgunn> mvo: i just uploaded it here https://drive.google.com/a/canonical.com/file/d/0B4GvOYxwuvpFTllJdk9QYS1vQUk/view?usp=sharing
[13:12] <kgunn> mvo: fwiw, a couple of confessions...i have stable-phone-overlay ppa applied
[13:12] <kgunn> for unity8
[13:12] <kgunn> desktop-session-mir, and i also ran the little script for "early users" as advertised in
[13:13] <kgunn> https://docs.google.com/document/d/1LsWd76jH9pEep8tz1SI4UPBFmbFTJGec9u518UJnW9Y/edit#heading=h.qxx7ico5okhd
[13:14] <mvo> kgunn: ta, I can't see anything obvious here, hmmm
[13:15] <slvn> sergiusens, Hello! you suggested me to set an env variable for this issue. https://bugs.launchpad.net/snapcraft/+bug/1575582
[13:15] <slvn> I tried, but there is still some erros ... If you have some more ideas ..
[13:16] <sergiusens> slvn have you checked for any errors and/or debug messages?
[13:17] <sergiusens> so vejmarie solve gl a while back, my recomendation was based on what was done for freecad
[13:18] <slvn> sergiusens, I don't know much about gl ... I have written the new errors on the tickets
[13:18] <sergiusens> sabdfl using build-packages you also get a smaller snap :-)
[13:19] <sergiusens> kyrofa agreed, it is like to many channels but worse as each has its own mechanics :-P
[13:19] <kyrofa> sergiusens, no kidding
[13:24] <ogra_> hmm, so how do i convinnce my snap to have a .desktop file
[13:27] <kgunn> mvo: i'll take any advice, i did a remove and reinstall of ubuntu-snappy-cli and ubuntu-core.... but i'd like to get back to a state where i can work on unity8 interfaces with ted
[13:29] <dpm> ogra_, perhaps with something like this? (files under setup/gui) -> http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/files/head:/setup/gui/
[13:29] <ogra_> dpm, ah, that was the bit i was missing
[13:29] <ogra_> thanks
[13:29] <dpm> excellent
[13:32] <netphreak> Has the classic mode been reintroduced again?
[13:32] <mvo> kgunn: can you please run sudo systemctl stop snapd.service snapd.socket  ;  sudo /lib/systemd/systemd-activate -E SNAPD_DEBUG=1 -l /run/snapd.socket /usr/lib/snapd/snapd on a terminal and run snap list in a different terminal and see if this debug switch helps and prints something useful?
[13:38] <kyrofa> stevebiscuit, I forgot we had wgrant there, he could tell you everything about the builders
[13:38] <kyrofa> stevebiscuit, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way if you haven't done it before
[13:39] <kgunn> mvo: hmmm, now list works :) https://pastebin.canonical.com/158171/
[13:39] <kgunn> the debug out for snapd is here https://pastebin.canonical.com/158172/
[13:39] <kgunn> in case your interested
[13:42] <sergiusens> ogra_ if you need help go to gitter :-P
[13:48] <ogra_> sergiusens, i am there ...
[13:52] <ogra_> sergiusens, my prob is that i start running out of free space on my desktop for the different chat clients :P
[13:52] <Mikaela> is gitter also open for curious idlers?
[13:52] <kyrofa> ogra_, make more virtual workspaces, duh
[13:52] <kyrofa> Mikaela, certainly!
[13:53] <ogra_> kyrofa, i have 6 already :)
[13:53] <kyrofa> Mikaela, https://gitter.im/ubuntu/snappy-playpen
[13:53] <ogra_> Mikaela, definitely !
[13:53] <kyrofa> ogra_, try 9
[13:53] <ogra_> haha
[13:53] <Mikaela> thanks, I will take a look on PC
[13:53] <kyrofa> ogra_, it will satisfy your desire for symmetry
[13:53] <ogra_> i guess then i'll slowly start running out of ram for snapcraft
[13:53] <kyrofa> Hahaha
[14:23] <kyrofa> And now my wife starts talking to me on hangouts. Now I have telegram, xchat, gitter, and hangouts
[14:24] <ogra_> kyrofa, join us on slack in the warthogs chat !
[14:25] <ogra_> :P
[14:25] <kyrofa> Oh man, I was on there but forgot about it
[14:29] <mvo> kgunn: hm, list works but it is empty, is that expected?
[14:30] <kgunn> mvo: got distracted with a meeting...lemme check more
[14:30] <mvo> kgunn: same problem, long phonecall :)
[14:35] <kgunn> mvo: so weird, find worked ok, but install problematic
[14:36] <kgunn> https://pastebin.canonical.com/158177/
[14:36] <mvo> kgunn: hm, 500 error is a store side thing
[14:36] <mvo> kgunn: is that reproducable?
[14:37] <seb128> kgunn, is your (hotel?) internet filtered in some ways?
[14:39] <kgunn> seb128: well, we're on classic canonical wifi
[14:39] <seb128> k, asking in case
[14:39] <seb128> you might have reconnected to the hotel one or something
[14:40] <seb128> oh
[14:40] <seb128> kgunn, mvo, install errors 500 here as well
[14:41] <seb128> seems like a store issue
[14:41] <seb128> nessita, ^
[14:46] <sergiusens> kyrofa tell her to use telegram :-P
[14:46] <kgunn> dpm: hey what's the lp branch where i can rebuild calc/clock snap to attempt side load ?
[14:47] <dpm> kgunn, `bzr branch lp:~dpm/ubuntu-clock-app/snap-all-things`
[14:47] <kgunn> ta
[14:47] <dpm> `bzr branch lp:~dpm/ubuntu-calculator-app/snap-all-things`
[14:47] <dpm> np
[14:47] <kyrofa> sergiusens, :P
[14:48] <nessita> seb128, sorry otp, can you please join the internal store channel and report there?
[14:49] <seb128> kgunn, ^
[14:53] <Sutter> Hi!..
[14:55] <Sutter> So... How Can i Do a snappy app?:D
[14:59] <elopio> Sutter: hello.
[15:00] <elopio> Sutter: you can start here: https://developer.ubuntu.com/en/snappy/build-apps/
[15:01] <jamieben_> Sutter: you could also join the playpen initiative going on right now with experts to guide you through the experience - https://lists.ubuntu.com/archives/snapcraft/2016-June/000090.html
[15:01] <jamieben_> Sutter: and the details on how to connect - https://lists.ubuntu.com/archives/snapcraft/2016-June/000119.html
[15:01] <Sutter> wow!..ok! tnx
[15:19] <ogra_> Sutter, all conversation currently happens in https://gitter.im/ubuntu/snappy-playpen
[15:19] <ogra_> oh, he's gone
[15:20] <ogra_> (or she)
[15:25] <ev> kgunn: is snap install working for you now?
[15:29] <kgunn> bout to check
[15:30] <ev> cheers
[15:31] <kgunn> ev: appears to be working....
[15:31] <ev> excellent
[15:31] <ev> really sorry that this happened. We’re working on an incident report now to ensure it doesn’t repeat
[15:32] <kgunn> ev mvo fwiw, interesting i was trying to install sideload style...but grabbed from the store?
[15:32] <kgunn> https://pastebin.canonical.com/158193/
[15:38] <kgunn> but at least the store works ;)
[15:41] <sethj> can someone confirm this is a bug in snapcraft and not in Unity Tweak Tool? https://bugs.launchpad.net/snapcraft/+bug/1587193
[15:45] <ev> kgunn: I don’t think that’s correct. Your first pastebin tries to install a snap from the store and fails
[15:45] <ev> oh wow no
[15:45] <ev> I see what you mean now
[15:46] <ev> mvo: https://pastebin.canonical.com/158193/ - any idea why it’s fetching from the store instead of sideloading here?
[15:47] <mvo> ev: does it make a difference if you do sudo snap install ./ubuntu-calculator-app_2.1+snap3_amd64.snap
[15:47] <mvo> kgunn: -^
[15:47] <mvo> ev: this looks like a bug I'm not entirely sure yet about the details
[15:48] <kgunn> mvo: yes, ./ worked to sideload...i shoulda tried that
[15:49] <dpm> hey, can someone help us answer this question from the community team Q&A?
 QUESTION: Due to snappy using A/B partitioning, when we get system updates will that mean that we will have to reboot to install these? Or will we be able to have live system updates?
[15:49] <dholbach> hey attente - how are you? do you have any experience with qt4 apps?
[15:49] <dpm> ahayzen, ^ :-)
[15:49] <dholbach> qt4 snaps I should say
[15:49] <ahayzen> dpm, \o/
[15:49] <dholbach> I'm working on https://github.com/ubuntu/snappy-playpen/tree/musique right now
[15:50] <dholbach> and it looks for /etc/xdg/Trolltech.conf instead of its $SNAP/... counterpart
[15:50] <dholbach> and I can't find that in its source code
[15:51] <mvo> kgunn: thanks for confirming still a bug on our side
[15:51] <kgunn> mvo: want me to file one?
[15:51] <kgunn> just to have it...
[15:51] <kgunn> realize not a huge deal
[15:54] <dpm> dholbach, you might wanto to have a look at how we deal with qt5.conf in the qt5-launcher part. Perhaps we can do something similar for qt4 apps?
[15:54] <dholbach> dpm, it's what I borrowed a lot of ideas from :)
[15:55] <dpm> ok ok :)
[15:55] <attente> dholbach: can you try setting $XDG_CONFIG_DIRS in the wrapper script?
[15:56] <attente> dholbach: alternatively, maybe there's some way to set $sysconfdir at build time?
[15:56] <dholbach> attente, like this?
[15:56] <dholbach> export XDG_CONFIG_DIRS=$SNAP/etc/xdg:$XDG_CONFIG_DIRS
[15:56] <dholbach> export XDG_CONFIG_DIRS=$SNAP/usr/xdg:$XDG_CONFIG_DIRS
[15:57] <attente> dholbach: yeah, does that do anything?
[15:57] <dholbach> no
[15:57] <dholbach> I couldn't find the lookup in the source, so I suspect its further down the stack somewhere
[15:57] <dholbach> but $sysconfdir sounds like something I should try
[15:59] <dholbach> no mention of sysconf anywhere
[16:06] <dholbach> attente, ^ do you know of any other qt4 snaps?
[16:09] <attente> dholbach: no, sorry. if you want, i can help take a look at your snap
[16:11] <verterok> mvo: doing a rollout, might get a couple 500's from downloads ATM
[16:12] <dholbach> attente, I'll need to run in a few, but if you have a bit of time, that'd be great
[16:12] <dholbach> I suspect this might be similar in other qt4 apps
[16:13] <seb128> dholbach, attente, http://sources.debian.net/src/qt4-x11/4:4.8.7%2Bdfsg-8/src/corelib/io/qsettings.cpp/?hl=2672#L3531
[16:13] <seb128> dholbach, attente, basically you need to rebuild your qt4 with different buildtime option
[16:14] <dholbach> ouch
[16:14] <attente> seb128: thanks
[16:14] <seb128> that's back to the issue I'm trying to point on the mailing list
[16:14] <ogra_> seb128, well, but datadir is defined at build time ... you can just set it to the right snap dir :)
[16:14] <dholbach> ok, I'll take a look at that tomorrow morning
[16:14] <dholbach> and see if that helps
[16:14] <seb128> rebuilding?
[16:14] <seb128> or the list discussion?
[16:15] <ogra_> seb128, all your complaints assume you just (ab)use the debs
[16:15] <seb128> ogra_, no they don't
[16:15] <ogra_> would you build from source you could adjust the built time env
[16:15] <seb128> right
[16:15] <seb128> but that wouldn't work
[16:15] <ogra_> which would immediately solve all yoour issues
[16:15] <ogra_> why not ?
[16:15] <seb128> no
[16:15] <seb128> because what value would you use?
[16:16] <seb128> --sysconfdir=/snap/currrent/software/etc ?
[16:16] <ogra_> yeah,something like that ...
[16:16] <seb128> that directory has no garantie to not change in a futur snapd version
[16:16] <seb128> and that would make the file installed in "/snap/currrent/software/etc
[16:16] <ogra_> i thinnk it is supposed to stay stable over the iteration of 16
[16:16] <seb128> in the squashfs
[16:17] <seb128> so be on "/snap/currrent/software//snap/currrent/software/etc"
[16:17] <seb128> in the mounted snap
[16:17] <ogra_> an you cant use ./software/etc ?
[16:17] <seb128> well then the code would try to open /software/etc/config
[16:17] <seb128> which doesn't exist
[16:18] <ogra_> it would remove the dot ?
[16:18] <ogra_> that sounds like a broken build system
[16:18] <seb128> I don't understand what you mean
[16:18] <seb128> it tries to open the conf at $sysconfdir/config
[16:18] <ogra_> make your dirs relative, cd too the workdir from a wrapper script
[16:18] <attente> think ogra_ is suggesting using a relative path for $sysconfdir
[16:18] <ogra_> yeah
[16:19] <ogra_> for all dirs
[16:19] <seb128> so your program would only work if you start if from some specific dir?
[16:19] <seb128> also I don't think that would work
[16:19] <ogra_> well, from its confined dir ...
[16:19] <seb128> make install would get confused
[16:19] <ogra_> it cant work anywhere else anyway
[16:19] <zyga> o/
[16:19] <seb128> k
[16:19] <seb128> well, make install is the issue there
[16:20] <seb128> it's going to try to install to a relative path
[16:20] <ogra_> i'm sure you can trick it sommehow to DTRT
[16:20] <seb128> it's like the locales right?
[16:20] <seb128> again I'm happy if you find the "somehow"
[16:20] <attente> is there a way to tell qt4 to check a different dir at runtime? no envvar?
[16:20] <ogra_> (i totally agree about the distro patch complaint btw)
[16:21] <ogra_> qt4 ? is that still a thing ?
[16:21] <seb128> attente, seems not, did you see the url I shared?
[16:21]  * ogra_ thought qt4 would have been gone the way of gtk1.2 by now :)
[16:21] <attente> seb128: yeah, i saw. but i was wondering if there's some codepath that overrides it at runtime
[16:21] <seb128> not that I found
[16:23] <attente> seb128: what about https://sources.debian.net/src/qt4-x11/4:4.8.7%2Bdfsg-8/src/corelib/io/qsettings.cpp/?hl=2672#L1107
[16:24] <seb128> attente, that's only for the user config?
[16:25] <ogra_> grrr ... upstreams ... even canonical peoplle hardcode paths in their upstream code !!!
[16:25]  * ogra_ tries to cook up a patch for the webbrowser app so it becomes usable in snaps
[16:25] <seb128> lol
[16:27] <ogra_> and this one is really evil ... "cant find my app in /usr/share/webbrowser-app ... so i *must* be on a developer system ... lets hardcode all paths to ./src then !"
[16:27] <seb128> that's common practice
[16:28] <seb128> well not unseen at least
[16:28] <ogra_> (but indeed lets expand the path to the full absolute one starting at / before we inject it into the binary)
[16:28] <attente> seb128: XDG_CONFIG_HOME=/ASDF strace musique 2>&1 | grep ASDF
[16:28] <ev> mvo, kgunn: heads up that the store is down again
[16:28] <attente> it seems to be looking there after defining it
[16:28] <ev> we’re in the process of rolling back the bad deployment
[16:29] <seb128> attente, yes, that's what the url I share was documenting?
[16:29] <attente> seb128: yes, but it doesn't require a rebuild of qt4
[16:31] <seb128> attente, well it's the user config
[16:31] <seb128> attente, it's trying to append .config to it no?
[16:31] <seb128> like /ASDF/.config/Trolltech.conf ?
[16:31] <seb128> (I didn't try here, just my reading)
[16:32] <seb128> unsure if relative paths would work
[16:32] <attente> seb128: it looks at "/ASDF/Trolltech.conf" for me
[16:32] <seb128> oh oh
[16:32] <seb128> ah, makes sense
[16:32] <attente> so i guess just defining XDG_CONFIG_HOME=/snap/<name>/current/etc/xdg should work
[16:33] <seb128> that seems wrong
[16:33] <seb128> but yeah, could work
[16:33] <seb128> well it would need to be made a list
[16:33] <seb128> so it still find the real user config if there is one
[16:34] <attente> yeah
[16:42] <wililupy> Question: Is anyone else getting http error 500 when trying to snap refresh ubuntu-core?
[16:42] <wililupy> I'm getting this error on my 16.04 laptop and from my Ubuntu-core KVM's.
[16:44] <popey> wililupy: i just tried and it worked here
[16:44] <wililupy> Interresting....
[16:45] <popey> not in a kvm, but on bare metal, if that matters
[16:45] <wililupy> That is so weird, I have been trying for 30 minutes and as soon as I question it here it is working.
[16:45] <popey> hah
[16:45] <popey> magic
[16:45] <wililupy> I should have asked sooner ;P
[16:46] <wililupy> Thanks popey
[16:46] <seb128> there was an issue with the store earlier it seems
[16:46] <seb128> but yeah, it has been fixed
[16:46] <popey> np
[17:17] <ogra_> ev, is the store supposed to be ok again ? all my phones just spin endless "looking for updates" now
[17:19] <ogra_> hmm, snap find on the desktop also hangs hard
[17:20] <noise][> ogra_: looks like a connectivity outage
[17:20] <ogra_> ah, finally timed out with a horrible 5 line traceback error message
[17:20] <ogra_> Chipaca, ^^ could we make that a little less scary looking ?
[17:21] <ogra_> noise][, lovely
[17:22] <hichhiker> hi, what is the _proper_ location to store snap-specific data to make it keep across version updates (in Snappy)? Specifically I am playing around with making a Redis snap package - but want to know where do I put the data dumps, etc
[17:23] <hichhiker> APP_USER_DATA seems to be versioned along with the app, so each time I update the app I seem to get a new user data directory :-(
[17:26] <kyrofa> hichhiker, indeed, each version gets a new directory, but the old version's data should be copied into the new one
[17:26] <kyrofa> hichhiker, this helps in case the snap needs to be rolled back
[17:27] <hichhiker> hmm,  I will check on that. How does old data in USER_DATA is cleaned up then? I get current and 1 last version of the app, but it seems that every version of the user data is still there
[17:28] <kyrofa> hichhiker, I believe it will keep three versions before pruning them
[17:29] <hichhiker> kyrofa, thanks, I am just starting out with Core/Snappy and find the learning curve is a bit steep - (mostly because of lack of documentation and conflicting docs)
[17:29] <kyrofa> hichhiker, yeah docs are a known weak point-- we're working on that :)
[17:30] <hichhiker> kyrofa, not the case on my box, I get at least 16 versions of data
[17:30] <kyrofa> hichhiker, hmm, that may have changed. Or it may only apply to snaps in the store
[17:34] <hichhiker> kyrofa, could be... I am on 15.04 if it matters (could not find 16.04 release to download) - also, for whatever reason my snap version is ignored and version looks like a hash of some sort - like this: 'IVMeYWXTaHdc' - the package.yaml has the right value, so not sure why that is happening
[17:34] <kyrofa> Oh!
[17:34] <kyrofa> That's the difference then
[17:34] <hichhiker> 15.04 or hash?
[17:34] <kyrofa> You should just use snappy on 16.04 desktop or server while waiting for images
[17:35] <kyrofa> The fact that you're using 15.04 invalidates a lot of assumptions I was making. The hash means your app is sideloaded
[17:35] <hichhiker> the key thing I need from it is the Core read-only OS deployment - is that part of desktop now?
[17:36] <kyrofa> No, the desktop OS is not read-only, but you can use snaps on it just like you can in the images
[17:36] <hichhiker> BTW, the device I am working on will not be connected directly(or more likely at all) to internet - is there a way to deliver snaps beside sideloading?
[17:37] <kyrofa> There are probably other ways that will be supported, but sideloading is likely the easiest
[17:39] <hichhiker> Ok, my hope is to deliver snaps (preferably signed/encrypted) on removable media that is automatically recognized on insert and updated if needed - but I am sure we are far away from that dream yet :-)
[17:41] <hichhiker> 16.04 seems like it is going to be drastically different, but since it is not out yet, I may switch back to using ubuntu server for now as a half-way step. It is just too tempting to just give up on snaps and go back to .debs once I do that :-/ I really like the Core idea for appliances
[17:41] <hichhiker> I assume server 16.04 has snappy as well?
[17:41] <qengho> Yes.
[17:42] <qengho> Not "snappy" program. Some renaming. Just "snap".
[17:43] <hichhiker> quengho - is that true of Core 16.04 as well?
[17:44] <hichhiker> one more question, is the Grub for Core custom or off-the-shelf? It is possible to replace it with another grub fork or is there Core specific stuff there?
[17:45] <sergiusens> hichhiker if you do snaps now, you will be ready for when ubuntu core comes out
[17:45] <sergiusens> you will be able to migrate transparently
[17:45] <gouchi> is it possible to know if you are in mobile or desktop environment with snapcraft ? So that we can push different configuration file ?
[17:45] <qengho> hichhiker: Yes. Ubuntu 16.04 was released with our progressing work on snappy. It's the best place to work on snaps.
[17:46] <hichhiker> Thanks
[17:47] <kyrofa> hichhiker, the grub question is one for ogra_ I think
[17:48] <qengho> hichhiker: ubuntu-core will want to manage the bootloader configuration, so I would be scared of messing around with it much.
[17:50] <hichhiker> qungho - I wanted to see if I can get TrustedGrub(1 or 2) to work (it uses TPM to store drive encryption/boot signing keys) - but it is another pipe dream :-/
[17:53] <qengho> hichhiker: I know pretty much nothing about this, but I am pretty sure there will be a way for you. It might be that you create your own os or grub package too.
[19:03] <wililupy> I'm trying to build a .snap for armhf so I tried snapcraft --target-arch armhf snap and I get the following error: http://pastebin.ubuntu.com/17098210/
[19:03] <wililupy> its the hello world example from snapcraft-examples git.
[19:04] <wililupy> Not sure what it means. Do I need to add the arch to the snapcraft.yaml for the hello part?
[19:05] <qengho> wililupy: The "hello" plugin doesn't implement building another architecture. It lacks a function that says it supports it, and it lacks test and settings in build() that implement it.
[19:05] <mrasif> hello sir
[19:06] <mrasif> I developed an app.
[19:06] <qengho> wililupy: You need a armhf machine or to borrow one from launchpad's builders for branches there.
[19:06] <sergiusens> wililupy is there a hello plugin in there?
[19:07] <mrasif> then I upload it to ubuntu distro
[19:07] <mrasif> but it still in review section
[19:07] <wililupy> sergiusens: no, the hello-world example uses cmake plugin
[19:10] <niemeyer_> jdstrand: Curious about why my spread snap hit the review queue
[19:10] <wililupy> qengho: so your saying I should build my .snap on an armhf device instead of an amd64 server?
[19:10] <niemeyer_> jdstrand: Are we reviewing for home?
[19:11] <qengho> wililupy: The best thing is to help implement cross-platform support, but the fastest thing is to use a real or virtual machine to make your package.
[19:14] <dpm> jdstrand, do you use askubuntu?
[19:14] <dpm> jdstrand, if so, what you just posted in the mailing list would be a perfect answer to http://askubuntu.com/questions/783979/how-to-debug-snaps ? :)
[19:17] <jdstrand> niemeyer_: I approved
[19:25] <qengho> wililupy: in a plugin, implement enable_cross_compilation(), which peeks at self.project to set values in self that inform the build() about architecture.
[19:26] <wililupy> I'm using the cmake plugin, shouldn't that already be implemented?
[19:26] <wililupy> qengho ^^
[19:27] <qengho> wililupy: cmake doesn't mean anything about what you're compiling. Are you passing the right flags to the Fortran compiler or whatever?
[19:29] <qengho> wililupy: That's my way of saying, no, knowing that you're running cmake to run a compiler doesn't mean the compiler knows enough to switch architecture targets.
[19:29] <qengho> It *could* be enough. It might not be.
[19:30] <wililupy> qengho, that makes sense, which is why snapcraft wants me to make sure that I have the arch in the hello parts section.
[19:30] <qengho> wililupy: and today, the cmake plugin doesn't try to know...
[19:30] <wililupy> That is extremely helpful qengho.
[19:31] <qengho> wililupy: waaaait, snapcraft doesn't require arch. Not any recent version. Are you on 16.04?
[19:31] <wililupy> qengho. Yes.
[19:32] <qengho> wililupy: make a new dir. and cd there. Run "snapcraft init". Does the new yaml have arch in it?
[19:33] <wililupy> qengho no.
[19:33] <qengho> wililupy: it's not required.
[19:34] <wililupy> the snapcraft.yaml file I was using was from a clone from github.com/ubuntu-core/snapcraft-examples
[19:34] <wililupy> I'm just trying to snap the hello world cli example, which works fine from amd64, but when I try to make it for armhf I get the errors.
[19:35] <qengho> wililupy: I'm very sorry, but that example must be older than dirt.
[19:35] <wililupy> most of the examples are ;)
[19:36] <sergiusens> wililupy cmake plugin has no cross compilation support either
[19:36] <sergiusens> wililupy we don't expect it any time soon either
[19:36] <wililupy> sergiusens: ok. I'm going to try to build my .snap on my pi2 running 16.04 server.
[20:52] <erio> Hello
[20:52] <erio> Couldn't solve the locale error the other day
[20:52] <erio> http://askubuntu.com/questions/783758/snap-build-fail-on-locale-error
[20:53] <erio> Leaving here in case someone has seen this already and know how to solve
[21:45] <wililupy> sergiusens, qengho: I successfully got the hello world example to build on my pi2 and it works on my test device. I'm going to read more up on the --target-arc flag on snapcraft to see what exactly it does work on.
[21:51] <sergiusens> wililupy it only really works for building kernels
[21:51] <sergiusens> it is rather low priority everywhere else
[21:54] <wililupy> sergiusens: Ok. I was just hoping that porting a app snap or gadget snap from one arch to another would be as simple as just the --target-arch flag in snapcraft. Its like you say, not a high priority since I can build on either arm or x86.
[21:59] <eriow> Could one use ELDK to build, throw the binaries in the same folder and call snapcraft snap after?
[22:04] <eriow> https://wiki.ubuntu.com/ARM/RootfsFromScratch
[22:04] <eriow> Good luck wililupy