=== marcoceppi_ is now known as marcoceppi === chihchun_afk is now known as chihchun === alecu_ is now known as alecu === chihchun_afk is now known as chihchun [06:30] what's the status of snappy becoming the default package manager in Ubuntu Desktop? anywhere on the net I could find some up-to-date info? [06:42] I'm pretty excited about the idea but it's difficult to find a central point with current status, or info on how to get involved in this particular project [07:16] oobartez, it's currently not plan of record for Ubuntu Desktop [07:17] once 16.04 is out we might start working on a modern rendition of Ubuntu, which will incorporate technologies from the phone and be snappy based, but there is no specific & detailed plan yet [07:24] ok, I understand it's a long haul, in the mean time I also found this: http://ubuntuforums.org/showthread.php?t=2312045&p=13432475#post13432475 [07:24] still, I personally find it super interesting. are there any conceptual discussions going that I could dig through? [07:33] hm where is an up to date documentation on writing an oem snap? [07:35] the doc in developer.ubuntu.com/en/snappy/guides/oem differs from examples in http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files [07:38] is it gadget or oem currently? [07:38] whats the immutable-config good for? === dvladar_ is now known as dvladar [08:07] good morning [09:33] Good morning all! Happy Thursday, and happy Create a Vacuum Day! 😃 [09:41] oem_snap/bananapi_1.0_all.snap failed to install: Signature verification failed: No signatures, or no origin signature. (exit code 10) [09:41] trying to create a new image using a just recently created oem snap.. === kickinz1 is now known as kickinz1-sprint === kickinz1 is now known as kickinz1-sprint [10:54] Hi, I want to make some services in snapcraft 2.1 but when I do that it tells met services was unexpected [10:56] http://pastebin.com/zmisT1nt [10:56] thats a part of my yaml [10:56] any clues === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [11:51] hey beuno, do you know when the new reviewers tools will land in myapps? I think all new snaps are being rejected right now? at least the one I uploaded with 'snapcraft upload' got rejected. [11:58] dholbach, hi. Rejected with what message? [11:59] - meta/readme.md does not exist lint_snappy_readme.md [11:59] - (NEEDS REVIEW) squashfs pkg lint_is_squashfs [11:59] - unknown entries in package.yaml: 'apps,description,summary' lint_snappy_unknown [11:59] with the most recent reviewers tool I think most of the above are fixed [12:00] beuno: ^ [12:02] dholbach, the readme is fixed, but I don't think squashfs verification has landed yet, has it? [12:03] dholbach, hmm, there shouldn't be a package.yaml [12:04] sergiusens: lp:~dholbach/+junk/moon-buggy is what I tried to upload with 'snapcraft upload' [12:06] dholbach, I think we'll need a week or so more until 16.04 snaps auto-approve [12:08] ok [12:09] auto-uploaded auto-approving snaps would be something really nice to demo :) [12:15] dholbach, yes indeed :) [12:15] dholbach, maybe clean and rebuild, I don't see package.yaml in the latest snapcraft builds [12:15] Good morning [12:15] Hi [12:16] kyrofa, morning [12:16] short question i want to make services in snapcraft 2.1 but it seems i don't work with the normal services tag [12:17] noizer, no, the syntax has changed in version 2 [12:17] kyrofa ok where can I find the syntax then? [12:18] noizer, https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-syntax.md [12:18] sergiusens, kyrofa: I'm still seeing "sh -c /usr/lib/update-notifier/update-motd-updates-available 2>/d..." as a hanging process [12:19] dholbach, I have no idea what you are talking about [12:19] kyrofa how does it work with the ports then? [12:19] sergiusens: http://paste.ubuntu.com/14876880/ [12:20] dholbach, in what point of snapcraft does it hang? [12:21] noizer, what do you mean? [12:21] dholbach, or at what point is it called [12:21] sergiusens: that's in the 'pull' stage [12:21] I need something with sockets but then i tought i need services. So services with the previous version there you can open some ports. But is it possible now with the deamons? [12:22] kyrofa [12:22] pindonga, question about the store; every time we upload with the store API through snapcraft we have to re-set the supported releseases, is there a way to make that stick? [12:22] sergiusens: first apt-get update is called, then something calls /usr/lib/update-notifier/update-motd-updates-available [12:23] basically after "apt update" pull hangs [12:23] noizer, sure it is. You just need to set the right permissions. If you're binding to a port you'll need network-service [12:24] ok i will look in to it :p [12:25] mvo, somehow /etc/writable stopped working with the switch to squashfs [12:25] dholbach, so if it is when installing build packages, we don't call update https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/repo.py#L60 [12:25] dholbach, but we do call it here: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/repo.py#L232 [12:26] dholbach, nothing fancy though, just using python apt in a different rootdir (this will go away soon for everything but ros) [12:26] sergiusens: when the apt lists are obtained in any case [12:27] dholbach, yeah, you hit this when adding stage packages [12:27] I wonder how we can turn off bits like update notifier [12:27] it must be possible [12:27] dholbach, maybe mvo knows [12:29] mvo: do you know an apt config option which would turn off update-notifier scripts and stuff (when using a local sources.list) [12:29] ? [12:29] kyrofa is there already documentation of network-services? [12:31] didrocks, hello there! Was there any issue with the upload? If you are too busy I can bother dholbach :-) [12:32] what what? [12:32] dholbach, I just distro patched someting until a release is avail http://paste.ubuntu.com/14871051/ [12:32] for a broken package [12:33] ok... [12:33] noizer, check out this example: https://github.com/ubuntu-core/snapcraft/blob/master/examples/shout/snapcraft.yaml [12:35] mvo, oh, ignore me ... /etc/writable is fine, it is the atomic write issue once again [12:35] kyrofa thx [12:36] sergiusens: on it [12:37] sergiusens: please bother him, yeah! here, it's quite crazy :p [12:38] noizer, does that make sense? You're just saying "my service needs to listen on the network" [12:38] I think it make sense [12:38] i will try it [12:39] because when when I'm testing it with normal command the permission was denied kyrofa [12:39] (tornado sockets) [12:40] noizer, do you know about snappy-debug? [12:40] i did not used it before [12:40] noizer, this may be helpful, from our brilliant dholbach: https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md [12:41] ok pray all dholbach :D [12:42] didrocks, I imagined as much [12:42] dholbach, thanks !!! [12:42] * sergiusens hugs dholbach [12:49] * dholbach hugs sergiusens back [12:50] kyrofa, noizer: to be fair... the content was written mostly by Jamie IIRC :) === bpierre_ is now known as bpierre === JamesTai1 is now known as JamesTait [12:59] dholbach: you can clean the dpkg::post-invoke, is snapcraft using "import apt"? if so I can provide an example in a bit (meeting) [13:00] mvo, yessir it is [13:03] kyrofa: please try apt.apt_pkg.config.clear("dpkg::post-invoke") [13:03] is there a way to use an oem snap with ubuntu-device-flash without signing it? [13:04] kyrofa what does the type migration-skill? [13:06] Thanks mvo! dholbach it sounds like you have a good failing test case, think you can throw that in and give it a try? [13:06] noizer, so for 16.04 the ability to share things between snaps is calls "skills" [13:07] oooh ok :D [13:07] noizer, there's still in development, so right now there's only a single skill called the "migration-skill" that essentially offers backward compatibility with the old stuff [13:07] kyrofa ok thx :D [13:07] noizer, thought not really backward as it changes the yaml anyway... but you get the idea [13:08] yea [13:11] noizer, there have been a few threads on snappy-devel regarding this. If you're using 16.04 snappy you might consider getting on there so you know what's happening :) [13:12] kyrofa ok i will check it out today :D. first, I will take care of my application so it is working on snappy [13:19] kyrofa: I'm not quite sure where to throw it in to make it work - I tried in a couple of places, but it doesn't seem to have an effect [13:19] I tried L60 and L232 in snapcraft/repo.py, tried after the apt import and elsewhere [13:19] dholbach: just anywhere in the code, its a global option [13:20] dholbach: having said this, I have no idea if what I said actually made sense, maybe I should read backlog first ;) [13:20] mvo: /usr/lib/update-notifier/update-motd-updates-available is still being called [13:20] which in our context hangs (as non-root user) [13:20] (mv /tmp/tmp.HSo85YHW5T /var/lib/update-notifier/updates-a...) [13:22] dholbach: hm, the apt.apt_pkg.config.clear() should prevent this. are there more ways that snapcraft drives apt in addition to the import apt? [13:23] mvo: these are all notable occurences: http://paste.ubuntu.com/14877293/ [13:29] dholbach: the subprocess call there looks suspicious :) [13:29] dholbach: is that were it crashs and burns? [13:30] I think it's before: http://paste.ubuntu.com/14877327/ [13:30] that's where it tries to install build-packages which is not my local case [13:34] dholbach: apt_cache = apt.Cache(rootdir=rootdir, memonly=True) will reset the config, could you please stick the clear() after thi sline? [13:36] mvo: no dice [13:36] :( [13:36] meh [13:36] printing out apt.apt_pkg.config.get("dpkg::post-invoke") before and after the clear() gives nothing [13:40] mvo: ah ok - I used .value_list now [13:40] it's "['adequate --help >/dev/null 2>&1 || exit 0; exec adequate --debconf --user nobody --pending', 'if [ -d /var/lib/update-notifier ]; then touch /var/lib/update-notifier/dpkg-run-stamp; fi'] [13:40] " before the .clear() [13:40] and [] after [13:41] could it be that the motd bits are somewhere else? [13:44] dholbach: hm, one sec [13:45] mvo: [13:45] /etc/apt.conf.d/99update-notifier:APT::Update::Post-Invoke-Success {"/usr/lib/update-notifier/update-motd-updates-available 2>/dev/null || true";}; [13:45] dholbach: try APT::Update::Post-Invoke-Success: [13:45] dholbach: try APT::Update::Post-Invoke-Success [13:45] dholbach: yeah, if you clean that, it should be ok [13:45] * dholbach crosses fingers [13:45] come on apt, make me happy :) [13:45] <3 [13:46] what a day ... so much ap5t talk in the snappy channel [13:46] ogra_, hahaha [13:46] sergiusens_, kyrofa: http://paste.ubuntu.com/14877432/ [13:46] I need to run for a bit, so feel free to push this one [13:47] dholbach, thanks for that! [13:47] anytime [13:47] anpok, with --developer-mode iirc [13:48] dholbach, mvo thanks [13:48] sergiusens_: I did a fresh build and upload of moon buggy - still the same errors/warnings from the reviewers tools [13:49] 1) meta/readme.md does not exist lint_snappy_readme.md - 2) (NEEDS REVIEW) squashfs pkg lint_is_squashfs - 3) unknown entries in package.yaml: 'apps,description,summary' lint_snappy_unknown [13:49] really need to run now - see you later [13:52] dholbach, oh, now I recall mvo saying he mixup the error message; it should say snap.yaml there; [13:52] there is still support required for those tools though [13:52] dholbach: yeah, the store is a bit confused, the click-reviewers-tools are not fully updated yet [13:52] dholbach: eh, s/store/c-r-t/ [13:53] sergiusens_: I have some snapcraft.yaml which just download debs and a shell script. I wonder if I can say "please create a armhf .snap" (with snapcraft1) easily? [13:53] sergiusens_, is this on subsequent uploads for the same pkg? ie, just new versions? [13:53] as I have no compilation at all [13:54] sergiusens_, this == having to re-set the releases [13:54] didrocks, the problem will be pulling the .debs from the arm repos [13:54] kyrofa: exactly! [13:55] didrocks, pretending you didn't have that to worry about, you can actually put the .snap together yourself and just run snapcraft snap [13:55] didrocks, but I'm not sure there's a good way to get the .debs without running on target or hacking snapcraft [13:55] kyrofa: sounds like an option. I'm looking as well in the code if I can spoof your arch detection :p [13:55] (if you are using a chroot for download from the archive) [13:55] or are you using the system sources.list? [13:56] didrocks, heh, going the hacking snapcraft route eh? [13:56] didrocks, hold on, let me find you a link [13:56] kyrofa: seems to be in snapcraft/common.py [13:56] heh 'dpkg-architecture', '-qDEB_BUILD_ARCH' [13:56] and the arch triplet [13:57] didrocks, check out snapcraft/repo.py [13:57] ah nice, it seems you not relying on system sources.list [13:58] but rather building one [13:58] didrocks, right. stage-packages and build-packages are different [13:58] didrocks, you want the stage-packages stuff, which is repo.py [13:59] kyrofa: thanks for the pointer! going to mess from there! :-) [14:00] didrocks, good luck! Interested to hear how it goes [14:00] yeah, well… snapcraft1 and it's changing with the classic dimension then [14:00] didrocks, remember you can always download the .debs yourself and unpack them [14:00] so, more of a stop gap :) [14:00] yeah [14:01] in download/ from the part [14:01] sergiusens_: ah that worked .. now it cannot find the package.yaml in the gadget snap [14:01] but 134 of them [14:01] so getting lazy! :) [14:01] didrocks, ugh! [14:01] anpok, I'll refer to mvo for that [14:02] pindonga, yes, new versions of the same package [14:03] sergiusens_, I guess we could default to any release set for the latest published version [14:03] sergiusens_, could you file a bug on lp:software-center-agent please? [14:03] well [14:03] or maybe store it locally? [14:03] in a local config [14:03] didrocks, your code is old, we removed the dep on dpkg-dev hence we don't have dpkg-architecture anymore either [14:03] last release targeted? [14:04] pindonga, I agree on that [14:04] beuno, well I was asking about the store api at first ;-) Since I need to add 'release' to snapcraft.yaml to support cleanbuild anyways [14:05] sergiusens_, I worry a bit about the server auto-filling data [14:05] but only a bit [14:05] :) [14:05] i creates a gadget/oem? snap that has a meta/package.yaml .. u-boot binary .. now it ubuntu-device-flash fails with 'Determining oem configuration\nno oem package found' [14:05] *created [14:06] beuno, this being for new version uploads only, I thought relying on existing releases if none is specified was ok [14:06] of course if the pkg contains the releases in the metadata, we should grab it from there [14:07] it's probably ok, yeah [14:07] it just feels like the wrong place to define intention === alexabreu is now known as alex-abreu [14:12] beuno, it's not autofilling [14:12] beuno, or not less than it used to [14:12] beuno, if I upload the snap from the ui it is filled in with the previous stuff; at least it was a week a go [14:13] beuno, I don't mind if it is an api; maybe this can also play with the stability level (grade) in snap.yaml [14:14] sergiusens_: it's snapcraft v1 [14:14] beuno, I'd much like to define which pockets to upload to, something like 'snapcraft upload --releases ubuntu-core,ubuntu-personal,...' [14:14] sergiusens_: from git [14:14] didrocks, oh, right [14:14] sergiusens_: we have to use it for mwc :p === sergiusens_ is now known as sergiusens [14:16] mvo, I tried installing hello-world.mvo on my new amd64 rolling image and it fails. Is this a known issue? [14:16] didrocks, oh yeah, that reminds me-- snapcraft snap is in version 2. If you're using 15.04 that functionality still exists in snappy itself, which you can use via snappy build [14:17] sergiusens, I managed to get everything re-worked last night [14:17] didrocks, works the same way though [14:18] one question... since I can't get hello-world working, what's the name of the user-specific writable env var? [14:18] awe__, $SNAP_USER_DATA [14:18] (if 16.04) [14:18] great, thanks [14:18] did SNAP_APP_DATA_PATH also get shortened? [14:19] ( for 16.04 )? [14:19] awe__, $SNAP_APP_USER_DATA_PATH if 15.04 [14:19] awe__, indeed, $SNAP_DATA [14:19] SNAP_DATA ? [14:19] yeah [14:19] * ogra_ still cant memorize them [14:19] is the old env var still supported though in the latest images? [14:19] ogra_, it's okay, me too [14:19] awe__, yes, just deprecated [14:19] ok, great; will change now [14:22] awe__, I guess email subjects are a thing of the past; https://lists.ubuntu.com/archives/snappy-devel/2016-January/001392.html :-) [14:22] ppisati, mvo, i'm nearly readey witrh my rpi firmware update for gadget and oem snap .... i was wondering if we should perhaps bump the default kernel version to the latest xenial one though (which means i'd need to update the dtbs in the snap) [14:22] awe__, what fails with hello-world? If it is installation, try snappy install hello-world/edge [14:23] (that is ... 4.2 to 4.3) [14:23] sergiusens, ok, one sec [14:23] ogra_: +1 [14:23] ppisati, any possible regressions (i.e. config changes) i shold be aware of ? [14:24] mvo, did you ever learn anything about that weird systemd %h thing? [14:24] sergiusens, that works [14:25] mvo, never mind my last statement about hello-world [14:26] matiasb, I uploaded another version of that owncloud snap, but I'm not seeing it in snappy again. When you get a sec would you mind patching that framework thing on it? [14:26] kyrofa, ack, sure, in a bit [14:27] ogra_: nothing on purpose at least :) [14:27] ogra_: let me check one thing [14:27] ppisati, heh, ok [14:27] matiasb, thank you! [14:27] kyrofa, fyi, we expect to get a fix for this deployed today, hopefully [14:27] matiasb, excellent! Thanks for letting me know :) [14:31] the problem seems to be that the oem/gadget snap looks different.. when in stalled in temp the package.yaml ends up being here: [14:31] sergiusens, +1 to the idea of passing releases via api [14:31] ./apps/bananapi.sideload/ILfDRVXaWFBX/meta/package.yaml [14:32] s/in stalled/installed [14:33] kyrofa, updated, you should see latest revision now [14:37] matiasb, perfect, works! [14:37] I rebooted - which apparently installed some new rootfs? - and now pulseaudio doesn't start: [14:38] didrocks, try the new version of owncloud.kyrofa when you get a sec, app store should be working [14:38] ogra_: http://paste.ubuntu.com/14877727/ [14:39] ogra_: that's the config diff between latest 4.2 and x/master 4.3 raspi2 kernel [14:39] ogra_: other than that, it works fine on my board and in my test [14:39] ppisati, do you plan to bump to 4.4 before final ? [14:39] ogra_: we make use of =m as mush as possible, so it should be fine [14:39] (giving us the free graphics driver) [14:39] ogra_: we already have a 4.4 [14:39] ogra_: but it's the first cycle [14:40] ogra_: so it's marked as unstable [14:40] not on rpi yet [14:40] ah, k [14:40] ogra_: yep, on rpi2 too [14:40] well, but you plan to bump it ? [14:40] ogra_: ys [14:40] ppisati, hmm, then i'll probably push the update til 4.4 is consumable [14:40] the wrapper script claims it cannot find the executable [14:41] and stay with 4.2 til then [14:41] ogra_: probably yes [14:41] ogra_: i really like X because we syncronized with an upstream LTS kernel [14:41] ogra_: so align nicely [14:41] when everyone moves there [14:42] yeah [14:43] kyrofa: oh nice! will definitively do:) [14:51] ping pitti. I need help trying to reproduce the snapcraft autopkgtest. Canonistack has timed out all week before starting to run the tests. [14:51] do you have any tips to reproduce locally? [14:56] elopio: it works in qemu? [14:56] elopio: looks like it's trying to contact https://repo.maven.apache.org/maven2 [14:56] elopio: possibly it's not respecting $https_proxy for that? [14:57] tests need to use the proxy in the environment, they can't talk directly to the network [14:58] pitti: I haven't even gotten there with qemu: https://paste.ubuntu.com/14863428/ [14:59] I have everything timing out in different ways :( [15:02] elopio: wow, how big is that tree? [15:03] elopio: you can try with --timeout-copy=3000 (default is 300, i. e. 5 mins) [15:03] but I guess something else is wrong, unless your tree really is Gigabytes big [15:04] * pitti runs "adt-run snapcraft --- qemu /srv/vm/adt-xenial-amd64-cloud.img" [15:06] pitti: ummm, we pollute the repository when we build snaps. I'll try cleaning everything up first. [15:07] elopio: ah, in your ./ ? yes, do that, or run "snapcraft" instead of ".//" to use apt-get source [15:07] elopio: I started it, and I now see ".......EEE..." [15:07] elopio: i. e. some tests fail, but it's runing [15:07] elopio: wrt. trying to download from maven: don't we have tha particular module packaged? we have hundreds of maven packages [15:08] elopio: i. e. if you add this as a test dependency, then it would avoid having to call out to the internet [15:08] pitti: ok! seems promision. /me tries. [15:08] pitti: we decided for some reason to use upstream. Not sure about what was that reason now. [15:08] sergiusens: ^ ? [15:09] elopio: ok, then I figure you either don't respect $https_proxy, or something cleans the environment [15:13] elopio, pitti well one of the purposes for those examples is to use upstream; I I can look into seeing if http_proxy gets wiped or not [15:13] thanks [15:13] thanks pitti! it's running now locally. I can start debugging now. [15:23] mvo: hey, fyi, both systems are continuing to install hello-world.canonical 1.0.18 [15:23] I didn't check to see if they stopped during the night [15:23] I can if you need me to [15:24] jdstrand: meh, thanks [15:40] mvo, sergiusens much simpler reproducible case for the broken $SNAP_USER_DATA here: https://bugs.launchpad.net/snappy/+bug/1541898 [15:40] Launchpad bug 1541898 in Snappy "Broken $SNAP_USER_DATA for services" [Undecided,New] [15:53] * dholbach hugs sergiusens [15:55] sergiusens, jsonschema question (context: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/yaml.py#L343) [15:55] sergiusens, if I load the YAML via yaml.load (which gives me a dict) and hand the dict to jsonschema, how can jsonschema _possibly_ back that out to a line number in the yaml? [15:57] kyrofa what is the correct syntax for the copy plugin? [15:58] noizer, copy has one parameter, "files", which is a map of source->destinations [15:58] noizer, so something like: http://pastebin.ubuntu.com/14878198/ [15:59] kyrofa ok but in Private chat you said i did it wrong for my nginx.conf file [15:59] noizer, right, you have a copy plugin with no files-- just a stage-package [16:01] yea ok that was wrong but the part under that it will copy the nginx.conf over the other one but it don't work [16:02] noizer, you may need to exclude that conf file from the stage-packages [16:02] noizer, if two parts try to write the same file but they differ, snapcraft will throw a fit [16:02] noizer, since it doesn't know which one you actually want [16:03] ok [16:04] noizer, look in that syntax file for the `stage` and `snap` keywords for the parts [16:05] noizer, you can use those to exclude the config file [16:06] kyrofa, it is impossible [16:06] kyrofa, but you can get the key that cause the issue [16:06] sergiusens, yeah okay, that's what I thought [16:07] sergiusens, gotcha [16:32] Hi guys! [16:33] We have application. Screenly Viewer. Slide Show application which uses opengl to show it's slides. [16:33] renat, hi! [16:34] When I start the binary - everything works well, and it works. But when I'm trying to start it as a systemd service. I loads. Shows the first asset and stops. Just using 100% cpu. [16:34] beuno, Hi! [16:34] renat, lets start off with some basic information [16:35] what release of snappy are you using? [16:35] 15.04 [16:35] stable [16:35] It doesn't show any apparmor and seccomp warnings [16:36] renat, ok, lets ping some folks who might be better suited to help debug [16:36] beuno, thanks! [16:36] jdstrand, sergiusens, kyrofa, any pointers? ^ [16:36] kgunn, maybe you have some thoughts? [16:36] mvo, yo, you know things ... ubuntu-core 15.04 has extended support relative to 15.04 which is just EOL'ing [16:37] mvo, as i understand things you have an overlay PPA which will take over to supply updates for things after EOL of 15.04 ... [16:37] renat, are you using mir or something? [16:37] mvo, so we are trying to confirm that you are needing vivid kernel updates for that, and how those would make it to you [16:38] kyrofa, hi! No. I'm now 100% sure how it works. But it uses Qtt OpenGL [16:38] renat: and what exactly are you running on ? amd64? vm? arm? [16:38] kyrofa, it's Raspberry Pi2 ARM [16:38] kyrofa, it's Raspberry Pi2 armhf [16:38] apw, ricmm might be better suited to answer that [16:38] renat, are you using the qml plugin in snapcraft, then? [16:38] ricmm, ^^ [16:40] kyrofa, no. We use our patched version of Qt as I know. Build everything into squashfs using buildroot. I create a snap by extracting everything from the squashfs and setting appropriate paths in LD_LIBRARY_PATH and all other libraries. [16:40] renat, oh [16:40] hmm [16:40] I think 15.04 doesn't support squashfs? [16:40] does it? [16:41] beuno, right [16:41] but he says it loads/works.... [16:41] only until he tries to start it as a systemd service does it not work (stalls on first frame) [16:41] iiuc [16:42] renat: if it shows 100%cpu...what's the process using cpu? [16:43] kgunn, executable itself [16:44] renat: mmm, but seems you have a ton of stuff inside that snap... [16:44] kgunn. I'm placing logging functions to different places. But don't get any output. [16:45] What is difference between running as executable and as a systemd service? [16:45] renat: that i really don't know...others would be better to speak [16:47] renat, I'm confused. You say it's Qt and OpenGL. You must be using a display server of some kind? [16:47] kyrofa, it uses framebuffer [16:49] renat, ah, okay [16:49] It should be something systemd or cgroups related. [16:50] renat, have you tried running this as an app with sudo? [16:51] kyrofa, Yes. It works [16:51] renat, have you tried via su as well? [16:51] renat, real=effective uid [16:54] kyrofa, worked again [16:55] renat, when running as a service, I'm assuming it doesn't fork right? [16:55] No. It doesn't I use exec in all wrappers [16:56] No. It doesn't. I use exec in all wrappers === kickinz1-sprint is now known as kickinz1|afk [16:57] renat, by running under su you've eliminated the differences as far as I can tell. I'm really not sure why it's not working when running as a service. Everything else should be the same [16:59] renat, what you need is gdb :( [16:59] kyrofa, no. 1 more difference. Different slice. system.slice vs user.slice. [17:01] renat, hmm, yeah you can either start adding prints to the application to figure out where it's looping, or wait for sergiusens or mvo to give you some more pointers [17:04] renat, snappy service logs [snap] gives no output? [17:06] renat (otoh, I can't think of something. however, it is possible you aren't seeing security denial due to kernel rate limiting. I suggest: sudo snappy install snappy-debug ; sudo reboot ; login ; sudo snappy-debug.security scanlog ; exercise your snap [17:09] Thanks. trying. [17:10] beuno: awe__ asked me to upload bluez to rolling using the shared acount (fine). there is an amd64 and an armhf snap with the same version number. anything special I need to know when doing this? [17:10] jdstrand, they can't have the same version right now [17:10] Unless that's changed since yesterday [17:10] awe__: fyi, ^ [17:10] jdstrand, so I just append -amd64 and -armhf to the versions [17:11] ok; so build one as -1 [17:11] and the second as -2 [17:11] jdstrand, other than that, seems to work great! [17:11] or that [17:11] awe__, yeah, whatever doesn't imply that the versions are actually different, you know? [17:11] kyrofa: thanks! [17:11] beuno: nm [17:11] sure [17:12] awe__, kyrofa wait, for 16.04 we have multi arch pockets in the store since monday [17:13]