| qengho | hindle: If it's between the same system user's running apps, just use $SNAP_USER_DATA/socket1 | 00:01 |
|---|---|---|
| josharenson | Does anyone know anything about a snapcraft.yaml for unity8? | 01:26 |
| josharenson | I know it doesn't really work yet, but I'm trying not to reinvent the wheel. | 01:26 |
| ahoneybun | mhall119: that RocketChat snap is really bad on mainline kernels | 02:12 |
| ahoneybun | apparmor complains all over | 02:12 |
| ahoneybun | someone in here told me I have to recompile the kernel with the patches but that is just too much work | 02:13 |
| mup | Bug #1637046 opened: requesting "quiet" mode <canonical-is> <Snappy:New> <https://launchpad.net/bugs/1637046> | 02:52 |
| === hikiko|off is now known as hikiko | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:46 |
| didrocks | hey dholbach | 06:56 |
| dholbach | salut didrocks | 06:56 |
| mup | Bug #1637093 opened: docs/config.md needs an update <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1637093> | 07:21 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| vigo | ogra_, morning, I got "Can't find valid F2FS filesystem" in pi3 after runnning spread | 08:35 |
| ogra_ | vigo, hmm, i thought mvo fixed that yesterday, thats an old warning | 08:45 |
| mvo | ogra_: not quite fixed, the branch was up but tests need some serious rethinking (we use the ramdisks in the tests to simulate block devices) | 08:46 |
| vigo | mvo, morning, have you a bug for it? | 08:47 |
| vigo | mvo, I watched the rc2 images, the one for pi3 is building right? | 08:49 |
| mvo | vigo: http://people.canonical.com/~mvo/all-snaps/rc2/ is the current place for them | 08:51 |
| vigo | mvo, great :) flashing dragonboard | 08:52 |
| bzoltan | hi folks. Is there a way to trigger an action in the snapcraft after the stage to tar.gz up a part of the stage? | 08:58 |
| didrocks | bzoltan: I would go for a custom plugin, which will be set "after: <other-parts>". This plugin can then access to the stage/ directory (and so tar.gz it) | 08:59 |
| didrocks | does this make sense to you? | 09:00 |
| bzoltan | didrocks: not really :) | 09:01 |
| didrocks | ok, so you have multiple parts… | 09:01 |
| bzoltan | didrocks: Ok, so you mean that i should create a snapcraft plugin for this feature? | 09:02 |
| didrocks | yep | 09:02 |
| didrocks | you create on part which is "tarring-stage", which is using your custom snapcraft plugin "tarring-stage" | 09:02 |
| didrocks | this plugin, in the install phase for instance, do only one thing: take the stage/ directory and tar it up | 09:02 |
| didrocks | to ensure this is ran after all other parts have done their jobs | 09:03 |
| didrocks | you will need to specifying in tarring-stage: | 09:03 |
| didrocks | after: [list-of-other-parts] | 09:03 |
| didrocks | to ensure all other parts have run the "install" step first (you may want rather to try "stage" btw) | 09:04 |
| bzoltan | didrocks: is there a plugin template or a reasonable simple plugin I could use as pattern? | 09:04 |
| didrocks | bzoltan: sure, look at the dump plugin for instance | 09:05 |
| bzoltan | didrocks: okey, I will look at that and others too. Thanks :) i kind of hoped for a ready feature for hooking up scripts | 09:06 |
| didrocks | bzoltan: yeah, I know that was discussed, but not scheduled AFAIK | 09:06 |
| didrocks | the plugin should be straightforward, do not hesitate to ask if you need any help | 09:06 |
| bzoltan | didrocks: no probs... it is doable | 09:06 |
| didrocks | bzoltan: yeah, should be a couple of hours at max (with the example) :) | 09:07 |
| bzoltan | didrocks: :) | 09:07 |
| didrocks | bzoltan: again, do not hesitate if you need help with this, I'm happy to have a look | 09:07 |
| bzoltan | didrocks: I am fairly new to snapcraft internals... i was reading the scripts this week. There are few strange things there... but i will figure out | 09:08 |
| ogra_ | mvo, why is the dragonboard built from edge ? | 09:18 |
| rvr | ogra_: Not correct? | 09:18 |
| ogra_ | rvr, well, after all we want to release candidate/beta | 09:19 |
| === robertliu is now known as robertliu_ | ||
| rvr | ogra_: Ok, I will create an image with beta channel | 09:21 |
| === robertliu_ is now known as robertliu__ | ||
| === chihchun is now known as chihchun_afk | ||
| === robertliu__ is now known as robertliu | ||
| ogra_ | rvr, no, that wont help if the snaps have not been updated | 09:21 |
| rvr | ogra_: Oh | 09:22 |
| ogra_ | (i would have expected they move to candidate, then we get an image from there, test it and move them to beta ) | 09:22 |
| ogra_ | (and do a final smoke test with a beta built image) | 09:22 |
| mvo | ogra_: because I want to test it first before I promote it to candidate, once its promoted that snap goes out to all the candidate people | 09:28 |
| ogra_ | uuuh | 09:28 |
| mvo | ogra_: we will have to do a final run after the image is in candidate | 09:29 |
| mvo | ogra_: eh, build from candidate | 09:29 |
| * ogra_ just hit crtl-alt-delete in console-conf | 09:29 | |
| ogra_ | bad stuff ... | 09:29 |
| ogra_ | mvo, ah, we're not that far yet, ok | 09:29 |
| mvo | ogra_: yeah, just dragonboard is missing, the other arches got promoted to candidate but I have no positive report from the dragon sofar | 09:30 |
| ogra_ | so my rpi3 hops from service to service on reboot ... 2x it sat there "waiting for job to stop" with a 2min timeout | 09:30 |
| ogra_ | one of them said "Snappy services" (whatever that is) | 09:31 |
| ogra_ | the other was something with "Sync from Network" | 09:31 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | mvo, oh, btw ... if the gadget doesnt update files in /boot is that also true for all possible extra files it ships /the ones that get copied to /writable/system-data at image build time) | 09:32 |
| ogra_ | i envision we want to be able to update firmware files or binary blobs from the gadget | 09:33 |
| mvo | ogra_: correct, this is currently not possible | 09:33 |
| ogra_ | ouch | 09:33 |
| mvo | ogra_: we want this, its also very dangerous because if it goes wrong -> brick | 09:34 |
| ogra_ | well, i meant more extra files in /lib/frimware and graphics drivers we can not ship with the kernel snap | 09:34 |
| ogra_ | (that first sentence sounded wrong) | 09:35 |
| mvo | ogra_: oh, ok. yeah, well, we need to add code for this, its not supported yet. | 09:35 |
| ogra_ | i.e. nothing bootloader related that could hard-brick anything | 09:35 |
| mvo | yeah, thats fine, thats something we can easily add | 09:36 |
| mvo | ogra_: if you want, plesae create a trello card | 09:36 |
| ogra_ | grrr ... wlan on pi3 still times out even on second boot ... | 09:37 |
| ogra_ | it is funny, i can configure eth0, ssh in and *then* run sudo console-conf and reconfiguring the network works just fine ... i get wlan and all | 09:38 |
| bzoltan | didrocks: kind of starting with this - http://pastebin.ubuntu.com/23387537/ i wonder how I can know wherethe stage is? | 09:38 |
| ogra_ | just not when i do it on the first console-conf run | 09:38 |
| ogra_ | thats a joke ! | 09:43 |
| ogra_ | so third attempt of configuring wlan on the pi3 the system boots and console-conf shows me the IP for wlan0 ... | 09:43 |
| ogra_ | yet ... configuring the network still times out | 09:43 |
| * ogra_ wonders if we should have a skip button in the network settings of console-conf | 09:45 | |
| ogra_ | i can actually ping the system until i hit "Done" in console-conf | 09:46 |
| ogra_ | mwhudson, ^^^ any idea ? seems a configured wlan gets messed up on second boot if i have not set up a user yet | 09:47 |
| mup | PR snapd#2221 opened: tests: skip tests that use /dev/ptmx on ppc64el - it does not work here <Created by mvo5> <https://github.com/snapcore/snapd/pull/2221> | 09:50 |
| cellash | Hello everyone, I have an issue with Snap that is frustrating me. I am trying to snapcraft the Telegram app (we have a repo on LaunchPad where we've added all the required files etc.) which snaps up perfectly fine on 16.04 Unity 7 however I'm currently on 16.10 and I keep getting this error and cannot resolve the problem and wondered if anyone on here would know what this error means or shed some light to how to resolve this? Heres what the console returns: | 09:51 |
| cellash | http://pastebin.ubuntu.com/23387557/ Appreciate your time. | 09:51 |
| ogra_ | mwhudson, bah, i still see my wlan password in the console-conf logs ... right before the netplan yaml gets printed | 09:53 |
| ogra_ | hmm, actually multiple times | 09:54 |
| ogra_ | the actual yaml output says "REDACTED" | 09:55 |
| joc_ | cellash: is it the error on line 443 of your pastebin? missing intltool build-package possibly? | 10:02 |
| ogra_ | mwhudson, bug 1637145 for you ... (logs attached) | 10:06 |
| mup | Bug #1637145: console-conf breaks working wifi when rebooting before user is created <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637145> | 10:06 |
| mup | Bug #1637145 opened: console-conf breaks working wifi when rebooting before user is created <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637145> | 10:07 |
| cellash | joc_: Installing intltool fixed the error! Thank you so much joc_!! | 10:10 |
| joc_ | yw :) | 10:11 |
| mvo | ogra_: I think morphis found the bug | 10:22 |
| ogra_ | "the bug" ? | 10:22 |
| vigo | ogra_, just confirmed that bug, it happened to me with db first and now with the pi3 :\ | 10:27 |
| ogra_ | well, the pi3 still has other wifi probs | 10:27 |
| ogra_ | but yeah it is annoying | 10:28 |
| bzoltan | didrocks: got it working http://paste.ubuntu.com/23387713/ | 10:29 |
| dhiraj | Hello guys! | 10:33 |
| dhiraj | I would like to know if it is possible to use DDS middleware for communication between various snaps | 10:34 |
| dhiraj | has anybody tried something similar? if not DDS then any other data sharing middlewares like zeromq, rabbitmq of sorts? | 10:36 |
| ogra_ | mwhudson, and Bug #1637153 for you ... | 10:36 |
| mup | Bug #1637153: plugging in a network cable when wifi config failed causes a traceback when restarting console-conf <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637153> | 10:36 |
| === hikiko is now known as hikiko|ln | ||
| rvr | ogra_: mvo: Image is not resized again in the dragonboard :( | 10:37 |
| ogra_ | rvr, works fine here again :) | 10:37 |
| rvr | /dev/mmcblk1p9 488M 477M 0 100% /writable | 10:37 |
| mup | Bug #1637153 opened: plugging in a network cable when wifi config failed causes a traceback when restarting console-conf <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1637153> | 10:37 |
| ogra_ | rvr, yeah ... but unless anyone can reproduce it .... | 10:38 |
| ogra_ | rvr, i switched to godd recetly, try the same so we can rule out any dd options or weirdness | 10:40 |
| ogra_ | (snap install godd ...) | 10:40 |
| rvr | ogra_: Ack | 10:40 |
| ogra_ | xzcat ./ubuntu-core-16-pi3.img.xz | sudo godd - /dev/sdc | 10:40 |
| ogra_ | thats what i do with it | 10:40 |
| mup | PR snapd#2222 opened: tests: do not hardcode the size of /dev/ram0 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2222> | 10:50 |
| didrocks | bzoltan: nice! :) | 10:53 |
| bzoltan | didrocks: i am hacking it forward to add the exludes and stuff... the idea is to provide a generic way to produce API packages. | 10:53 |
| didrocks | bzoltan: yeah, I got what you wanted to do regarding SDK from your questions :) | 10:54 |
| bzoltan | didrocks: :) | 10:54 |
| mvo | ogra_: hi, sorry for not getting back earlire. what was the status of the dragonboard with networking? is it possible to generate a wlan config now? (that works)? | 11:06 |
| ogra_ | mvo, yeah | 11:08 |
| ogra_ | pi3 is still broked ... dragon works | 11:08 |
| rvr | mwhudson: Hi. Does console-conf has any test suite? | 11:08 |
| mvo | ogra_: pi3 is broken in what way? wireless not working at all, but wired works? | 11:08 |
| ogra_ | mvo, yep | 11:09 |
| ogra_ | mvo, no wlan0 on first boot ... and on every subsequent boot console-conf falls over when trying to configure the device ... funnily once you attempted to set it up it will be online just fine on reboot before console-conf touches it ... if it does thouh, the worlld falls apart (tracebacks, timeouts etc) | 11:10 |
| rvr | lol | 11:13 |
| rvr | If I configure incorrectly the network, I have no way to log in the machine | 11:13 |
| rvr | 127.0.0.1 after reboot. Nice. | 11:15 |
| ogra_ | what board ? | 11:16 |
| rvr | Dragonboard | 11:16 |
| ogra_ | is it just not showing the right IP or is it really not up ? | 11:16 |
| rvr | I was re-running console-conf via ssh | 11:16 |
| ogra_ | ah | 11:16 |
| ogra_ | i have only done that on pi3 yet (because then wlan works just fine) | 11:17 |
| rvr | ogra_: And pressed Done to re-apply the same settings | 11:17 |
| ogra_ | check /etc/netplan/, i think that doesnt store your wireless key anymore then | 11:17 |
| ogra_ | i have seen that | 11:17 |
| rvr | I can't check anything :P | 11:18 |
| ogra_ | you cant yank out the SD ? | 11:18 |
| rvr | Oh, that way | 11:18 |
| ogra_ | ogra@localhost:~$ uname -a | 11:18 |
| ogra_ | Linux localhost.localdomain 4.4.0-1032-snapdragon #36-Ubuntu SMP Wed Oct 19 14:37:43 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux | 11:18 |
| ogra_ | ogra@localhost:~$ df -h /writable/ | 11:18 |
| ogra_ | Filesystem Size Used Avail Use% Mounted on | 11:18 |
| rvr | Reflashing now, will reproduce later | 11:19 |
| ogra_ | /dev/mmcblk1p9 57G 341M 54G 1% /writable | 11:19 |
| ogra_ | all fine here | 11:19 |
| ogra_ | (regarding resize | 11:19 |
| ogra_ | ) | 11:19 |
| rvr | ogra_: Weird :-/ | 11:19 |
| ogra_ | yes, and nobody at the sprint could repro it | 11:19 |
| sitter | hey. I am trying to upload the kde-frameworks-5 content share, it's being auto rejected based on 2 fails https://paste.kde.org/pty2tu57i the first I sounds like content interface is being rejected and the second I have no clue about. any help would be appreciated :/ | 11:19 |
| ogra_ | i really dont get what your write process does to make this break | 11:19 |
| === hikiko|ln is now known as hikiko | ||
| mvo | sitter: when jdstrand is around he can probably help you. the content interface seems to need adding | 11:32 |
| mvo | sitter: the other one is about a bunch of files with "sticky" bit, a bit strange, if you click on "request manual review" we can investigate more | 11:32 |
| === chihchun is now known as chihchun_afk | ||
| sitter | mh, I think the +s comes from the docker volume we build on. not that I'd know why it would be +s to begin with ^^ | 11:38 |
| * sitter investigates | 11:38 | |
| mardy | pstolowski: hi! Do you have a minute for a question on interface hooks? | 11:38 |
| rvr | ogra_: Well, not it is resized (used godd) | 11:39 |
| didrocks | sitter: for the first one, jdstrand is already aware about it (he had to approve mine manually) | 11:42 |
| didrocks | not sure about the second one as well, you have quite some sticky bits, and I guess in doesn't like it | 11:42 |
| === chihchun_afk is now known as chihchun | ||
| ogra_ | ppisati, bah | 11:44 |
| ogra_ | ppisati, did the beaglebone fix get reverted when the CVE fix landed ? | 11:44 |
| ogra_ | the oops is back | 11:44 |
| sitter | didrocks: right, I'll try to get the stickies sorted and request a manual review then. cheers | 11:45 |
| ogra_ | ppisati, http://paste.ubuntu.com/23387924/ | 11:45 |
| ogra_ | (not sure it is the same one) | 11:45 |
| ogra_ | ppisati, yeah, seems to be the same oops, the system moves on and i dont have any network device in console-conf | 11:46 |
| ogra_ | ppisati, oh sigh, i think the same issue like on rpi did hit us here, the proposed kernel was wiped for the CVE and only re-uploaded to proposed on friday, so the fix for the OOPS didnt make it to the archive | 11:51 |
| * ogra_ hacks the bbb kernel snap to default to proposed | 11:59 | |
| pstolowski | mardy, hey! sure, what is it? | 12:00 |
| mardy | pstolowski: AFAIU, the builtin interfaces are interfaces were the slot is implemented by snapd itself (correct me if I'm wrong). Will it be possible to have hooks for these slots too (in snapd)? | 12:01 |
| === Guest21645 is now known as ahasenack | ||
| mardy | s/were/where/ :-) | 12:02 |
| === ahasenack is now known as Guest91977 | ||
| ogra_ | mvo, mind approving https://myapps.developer.ubuntu.com/dev/click-apps/5912/rev/6/ ? | 12:09 |
| ogra_ | ( jdstrand did add it to the exception list but seems that did still not land yet) | 12:09 |
| mvo | ogra_: sure | 12:09 |
| ogra_ | thx | 12:09 |
| mvo | ogra_: if you have a usb network card, could you please check if the dragonboard tgets an dhcp from that on firstboot | 12:10 |
| ogra_ | will do | 12:10 |
| mvo | ogra_: thanks | 12:10 |
| rvr | Dragonboard boots and sets up the wifi with rc2 | 12:11 |
| pstolowski | mardy, what you're referring to are slots "provided" by the os. i haven't thought about it yet and it wasn't raised in any of the discussions we had internally. I think it may make sense if we have use cases. | 12:12 |
| rvr | ogra_: and filesystem is correctly resized | 12:12 |
| ogra_ | rvr, oho !! | 12:12 |
| rvr | ogra_: Cool dd be the culprit? | 12:12 |
| rvr | Could | 12:12 |
| ogra_ | rvr, thats the first time since last week ? | 12:12 |
| rvr | ogra_: I think yesterday it worked for me sometimes | 12:13 |
| rvr | I could run the spread test suite | 12:13 |
| ogra_ | and this time you used godd ? | 12:14 |
| rvr | ogra_: Yes | 12:15 |
| ogra_ | well, yeah, then this could be the issue | 12:15 |
| ogra_ | (if it keeps working now :) ) | 12:15 |
| ogra_ | mvo, all fine with USB nic on the dragonboard for me (configuring wired only) | 12:19 |
| mvo | ogra_: cool - it also got an IP on firstboot? | 12:19 |
| ogra_ | yes, before console-conf | 12:20 |
| * ogra_ runs sudo console-conf to see if he can switch over to wlan now | 12:21 | |
| mardy | pstolowski: I was thinking that bug 1633520 could be solved by interface hooks, see comments 2 & 3 | 12:22 |
| mup | Bug #1633520: Support dbus runtime relocation <patch> <D-Bus:Unknown> <dbus (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1633520> | 12:22 |
| === chihchun is now known as chihchun_afk | ||
| ogra_ | yeah, works but needs a reboot, else the new config doesnt get applied | 12:23 |
| mvo | ogra_: \o/ | 12:25 |
| ogra_ | hmm, beagle doesnt though :( | 12:27 |
| ogra_ | interface is not pre-confoigured from first boot and times out trying to apply console-conf settings | 12:27 |
| faenil | hey guys | 12:32 |
| faenil | isn't "snap find" supposed to show the snaps in the store? | 12:32 |
| faenil | (or at least that's what some guides report) | 12:33 |
| ogra_ | nope, it is supposed to find them | 12:33 |
| ogra_ | i.e. a blind "snap find" wont show anything | 12:33 |
| faenil | although it used to | 12:33 |
| ogra_ | you need to give some search info | 12:33 |
| ogra_ | i dont think "snap" did | 12:33 |
| ogra_ | snappy did though | 12:33 |
| faenil | I see | 12:33 |
| ogra_ | it also only searches the stable channel | 12:34 |
| faenil | suer | 12:34 |
| === chihchun_afk is now known as chihchun | ||
| faenil | so, how do you list apps in the stable channel nowadays? | 12:35 |
| ogra_ | you dont | 12:35 |
| faenil | I see....ok | 12:36 |
| ogra_ | not sure if uappexplorer can filter by channel | 12:36 |
| faenil | alright, thanks ogra_ | 12:36 |
| faenil | is that intentional? | 12:36 |
| ogra_ | well, the prob is once the stable channel has 87234582 packages, what do you do ? | 12:36 |
| faenil | is it because it doesn't scale? | 12:36 |
| faenil | yeah | 12:37 |
| ogra_ | right | 12:37 |
| pstolowski | mardy, yes, this sounds sensible to me. but this needs discussing. what i'm working on right now is to allow hooks on plug/slot sides of regular snaps; special handling for OS will come next | 12:39 |
| faenil | ogra_: is there a plan to make it possible to search the other channels, that you know of? | 12:40 |
| ogra_ | nope, not that i know of | 12:41 |
| faenil | ok | 12:41 |
| faenil | cheers | 12:41 |
| mardy | pstolowski: OK; how can I make sure that this is not forgotten? Should I file a bug? | 12:43 |
| * ogra_ really loves to see the beaglebone only using 42MB ram in htop ... | 12:43 | |
| ogra_ | (of which 6.5MB is actually used by htop alone :) ) | 12:44 |
| ogra_ | i wonder if we could boot with less than 50MB RAM | 12:44 |
| ppisati | ogra_: i see all the patches are queued in x/master-next, yes, it appears that CVE hit the BBB too | 12:46 |
| ogra_ | ppisati, well, with the snap built from proposed everything is fine | 12:47 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-beaglebone.img.xz works pretty well | 12:47 |
| ppisati | ogra_: oh good | 12:47 |
| ogra_ | luckily the bbb isnt supported so i can do such stuff there ;) | 12:47 |
| ogra_ | (and just re-bump the kernel once it went to updates) | 12:48 |
| pstolowski | mardy, don't worry, it won't be forgotten ;) | 12:49 |
| mardy | pstolowski: OK, thanks :-) | 12:49 |
| ogra_ | mvo, so apart from the pi3 wlan issues, all arm images look fine to me | 12:50 |
| ogra_ | (apart from the known slowness of console-conf and such) | 12:50 |
| * ogra_ takes a break | 12:50 | |
| mhall119 | ahoneybun: that's not the rocket.chat snap, that's snapd/snap-confine itself | 12:56 |
| mhall119 | since mainline doesn't yet have all the apparmor patches merged in | 12:57 |
| mvo | ogra_: great, thank you | 12:59 |
| jdstrand | ogra_: I see linux-generic-bbb was approved. yes, the fix is in the tools, no it isn't sync'd yet | 13:06 |
| jdstrand | ogra_: speaking of bbb, is there a model assertion for it? I created one using linux-generic-bbb and bbb and it seemed to work, but not sure if I should be using something else | 13:07 |
| ogra_ | jdstrand, no official one (since we dont officially support it) ... i'm using a self created one for the daily images | 13:08 |
| jdstrand | ogra_: ah, where are those daily images? | 13:08 |
| ogra_ | http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-beaglebone.img.xz should be golden though ... in case you want to try | 13:08 |
| jdstrand | cool | 13:09 |
| jdstrand | ogra_: I guess soon they will be moved to stable? I forget if it was the gadget or kernel (or both) that wasn't(/weren't) in stable | 13:10 |
| ogra_ | yeah, with the release | 13:10 |
| ogra_ | i could move them to beta already i guess ... will do that later today | 13:10 |
| jdstrand | mvo: hey at some time that is convenient, would you mind approving https://myapps.developer.ubuntu.com/dev/click-apps/5063/review/rev/3/? I've made a change to the review tools so that will pass | 13:10 |
| jdstrand | mvo: but that isn't in the store yet | 13:10 |
| jdstrand | ogra_: no need on my account-- just curious | 13:11 |
| mvo | jdstrand: sure | 13:11 |
| jdstrand | ogra_: where will pi2, pi3 and dragonboard official images end up? http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/ with i386 and amd64? | 13:12 |
| jdstrand | ogra_: (I'm updating my images and also updating the security team's documentation) | 13:13 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | mvo: thanks! :) | 13:15 |
| ogra_ | jdstrand, good question ... perhaps mvo has an idea | 13:17 |
| * mvo is in a meeting | 13:18 | |
| popey | Pi3 disappeared from network *again* on update | 13:18 |
| ogra_ | we used to release under ubuntu-snappy in 15.04 ... but now we own the ubuntu-core name so i guess it will be somewhere under ubuntu-core | 13:18 |
| ogra_ | popey, wireless ? | 13:18 |
| popey | wired only | 13:18 |
| ogra_ | very weird, doesnt happen to me with wlan | 13:19 |
| popey | and I have no way of logging in on serial cable because no user ID | 13:19 |
| popey | so I cannot debug this | 13:19 |
| jdstrand | I need to look up how to setup wireless on series 16 | 13:19 |
| sitter | jdstrand: hey kde-frameworks-5 content snap filed for manual review as it fails lint due to content interface | 13:19 |
| popey | ethernet light is on, on the switch | 13:19 |
| popey | ogra_: should I file a bug, this has happened multiple times | 13:20 |
| ogra_ | jdstrand, doesnt work on pi3 ... so set up wired, make sure to reboot, ssh in, run sudo console-conf again and disable wired and configure wireless ... another reboot and you rshould be good | 13:20 |
| jdstrand | sitter: approved, but you need to press the publish button. fyi, there is a fix for that in trunk, it just isn't sync'd with the store yet | 13:20 |
| jdstrand | ogra_: oh, console-conf can do wireless too? | 13:21 |
| jdstrand | after initial bringup? | 13:21 |
| sitter | jdstrand: thanks | 13:21 |
| ogra_ | popey, definitely ... i suspect it doesnt shut down properly ... but that would need a serial console permanently attached to see | 13:21 |
| ogra_ | jdstrand, yeah, it should theoretically even work on first boot but there is some bug on the pi ... dragonboard works OOTB with wifi | 13:22 |
| ogra_ | still trying to hunt that down before release next week | 13:22 |
| jdstrand | an interesting side-effect of the whole user from LP stuff is that there is no way to set a password for the user (not so much for ssh logins, but for serial console logins). I guess the default is reasonable cause it is easy enough to do 'sudo passwd <id>', but perhaps it is interesting in console-conf... | 13:23 |
| ogra_ | sudo passwd $USER | 13:24 |
| jdstrand | of course, then you'd want to tweak sshd_config and likely /etc/sudoers.d/create-user-<id>... | 13:24 |
| ogra_ | (indeed you need to ssh in once for this) | 13:24 |
| jdstrand | ogra_: yeah, I mentioned that :) | 13:24 |
| popey | ogra_: no, it's rebooted fine i think, but comes back without network | 13:25 |
| ogra_ | ah, didnt see it :) | 13:25 |
| jdstrand | anyway, I don't feel strongly enough to advocate for a change to console-conf | 13:25 |
| ogra_ | popey, smells like some race then | 13:25 |
| ogra_ | i never see it with wlan | 13:25 |
| popey | ok filed 1637196 | 13:30 |
| mup | Bug #1637196 opened: Pi 3 drops off network on update <Snappy:New> <https://launchpad.net/bugs/1637196> | 13:32 |
| sitter | jdstrand: I also requested the reserved name 'kblocks' in case you can have a look at that ^^ | 13:33 |
| jdstrand | sitter: you'll need a store admin for that (I am a store reviewer) | 13:34 |
| jdstrand | nessita: can you help sitter? ^ | 13:34 |
| jdstrand | hmm, /etc/rsyslog.d is still read-only and no way to setup log forwarding yet | 13:34 |
| jdstrand | same with /etc/systemd/timesyncd.conf | 13:35 |
| popey | jdstrand: i thought you had rights to allow names too? | 13:39 |
| popey | (I just approved it) sitter | 13:40 |
| popey | sitter: feel free to ping me also next time you want a reservation approved | 13:40 |
| sitter | thanks | 13:42 |
| popey | np | 13:42 |
| jdstrand | popey: if I do, I don't know how or the processes surrounding allowing it | 13:46 |
| popey | ok | 13:47 |
| faenil | looking at http://bazaar.launchpad.net/~ubuntu-calendar-dev/ubuntu-calendar-app/trunk/view/head:/snapcraft.yaml#L9 | 13:48 |
| faenil | I should be able to run the app just by running "ubuntu-calenda-app" from terminal, after installing the snap, right? | 13:48 |
| faenil | I updated a laptop (not mine) to Zesty, and I can't get snaps to run | 13:49 |
| popey | that should work, yes. | 13:52 |
| faenil | it says command not found | 13:54 |
| faenil | can anyone confirm if snaps are running ok on zesty? | 13:54 |
| faenil | desktop-launch also does not exist | 13:55 |
| faenil | (maybe that's expected though?) | 13:56 |
| faenil | if anyone has an idea on how to debug this, please let me know ;) | 13:59 |
| pmcgowan | faenil, I saw similar behavior when my snapd was out of date | 14:01 |
| pmcgowan | or was it my core snap, forget | 14:01 |
| === petevg_afk is now known as petevg | ||
| faenil | 2.16+16.10ubuntu1 | 14:01 |
| faenil | core 16.04.1 | 14:01 |
| faenil | rev423 | 14:02 |
| faenil | pmcgowan: ubuntu-calendar-app.ubuntu-calendar-app says command not found (same if I just run ubuntu-calendar-app). While "snap run ubuntu-calendar-app" works! (thanks dobey) but trying to run it from the apps scope results in an endless spinner | 14:06 |
| Son_Goku | zyga: I fixed it! | 14:06 |
| dobey | faenil: i think the problem there is that command: | 14:07 |
| pmcgowan | faenil, seems broken for sure, just running u-c-a should work | 14:07 |
| faenil | I guess I should report a bug :P | 14:09 |
| faenil | tentatively snapd | 14:09 |
| dobey | so, the .desktop file is broken, which is why it doesn't start from the dash i guess | 14:13 |
| Son_Goku | zyga: https://github.com/zyga/snapcore-fedora/pull/9 | 14:13 |
| mup | PR zyga/snapcore-fedora#9: Update SELinux subpackage packaging <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/9> | 14:13 |
| faenil | dobey: or is it not that the dash fails because the command is not found? | 14:13 |
| faenil | or does it go through snap run? | 14:13 |
| faenil | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1637220 | 14:13 |
| mup | Bug #1637220: Command not found when launching snaps via terminal on Zesty <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637220> | 14:13 |
| faenil | who should I ping? zyga ? | 14:14 |
| dobey | faenil: no, the dash does the same as running "ubuntu-app-launch $APP_ID" | 14:14 |
| faenil | ok | 14:14 |
| dobey | but the .desktop file doesn't have $SNAP/bin/ in the Exec= line, or at least, doesn't have bin/. i don't know why the window stays around and you can't close it though. | 14:15 |
| dobey | the .desktop file has full paths to icons too, which seems wrong | 14:15 |
| faenil | dobey: should desktop-launch be availble from cmd? or is it just something that is preprocessed? | 14:17 |
| dobey | faenil: no idea. but it's not used for launching from the dash anyway since the .desktop file doesn't mention it | 14:17 |
| dobey | faenil: for all i know that could be some magic thing in snapcraft itself | 14:18 |
| faenil | sure | 14:18 |
| faenil | yeah | 14:18 |
| dobey | faenil: maybe in your ~/.cache/upstart/unity8-dash.log there is some error about calendar app, when you tried to start it from dash | 14:19 |
| faenil | dobey: nope | 14:20 |
| alex-abreu | faenil, you are trying in the unity8 session? | 14:24 |
| faenil | yep | 14:24 |
| mup | PR snapd#2223 opened: image: init "snap_mode" on image creation time to avoid ugly messages <Created by mvo5> <https://github.com/snapcore/snapd/pull/2223> | 14:24 |
| sitter | jdstrand, popey: I think #2 of kblocks is marked for manual review. if you could kick that please. I think it's holding up autoreview of #3 | 14:40 |
| jdstrand | sitter: I rejected r2. r3 was auto-approved (perhaps just now) and you need only press the publish button | 14:50 |
| sitter | jdstrand: thanks | 14:51 |
| === ondra_ is now known as ondra | ||
| mup | PR snapd#2224 opened: overlord/snapstate: update ux around explicit refresh of reverted, an… <Created by chipaca> <https://github.com/snapcore/snapd/pull/2224> | 15:07 |
| mup | PR snapd#2221 closed: tests: skip tests that use /dev/ptmx on ppc64el - it does not work here <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2221> | 15:09 |
| mup | PR snapd#2225 opened: Implement lxd-client interface exposing the lxd snap <Created by kalikiana> <https://github.com/snapcore/snapd/pull/2225> | 15:19 |
| mup | PR snapd#2226 opened: Eds <Created by renatofilho> <https://github.com/snapcore/snapd/pull/2226> | 15:24 |
| alex-abreu | nessita, trying to use the staging store to reach the new endpoints (sections, featured snaps, etc.) but I get a 404, are they in place ? | 15:25 |
| mup | PR snapcraft#873 closed: Release changelog for 2.20 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/873> | 15:25 |
| sergiusens | alex-abreu in the snapcraft we have a tools/staging_env.sh which we source to avoid the confusion of all the endpoints | 15:26 |
| sergiusens | try and use that as a reference | 15:26 |
| alex-abreu | sergiusens, ah great, I was manually setting the env vars, let me check that | 15:27 |
| alex-abreu | sergiusens, the URLs look reasonnably similar to what I have been using, although setting them manually | 15:29 |
| mup | PR snapcraft#834 closed: Remove the debian packaging <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/834> | 15:31 |
| sitter | mhall119: sudo snap install --edge kde-frameworks-5 && sudo snap install --edge --devmode kblocks | 15:34 |
| sitter | I do have a feeling that we are missing some "automatic dependency install" system for content sharing (i.e. one can install kblocks without having frameworks installed) | 15:35 |
| kyrofa | Hey ogra_, what is the difference between the pi2 RC and pi3? | 15:38 |
| Pharaoh_Atem | zyga: ping | 15:39 |
| mhall119 | sitter: auto-dependency installation is being worked on, IIRC it will check if you already have something installed that fulfills the content need, and if not it will look for the defined default snap and install that | 15:41 |
| mhall119 | zyga: ^^ is that correct? | 15:41 |
| Pharaoh_Atem | mhall119: this morning, I managed to get the selinux policy to let snapd start and run :) | 15:41 |
| mhall119 | Pharaoh_Atem: \o/ | 15:41 |
| mhall119 | sitter: are the edge channel builds coming from our CI now? | 15:43 |
| mup | PR snapcraft#874 opened: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/874> | 15:43 |
| zyga | Pharaoh_Atem: hey | 15:46 |
| zyga | sitter: that's correct, it's planned but not implemented yer | 15:46 |
| Pharaoh_Atem | zyga: the systemd units need to be refreshed | 15:48 |
| Pharaoh_Atem | they're wrong vs the canonical (pun intended) ones | 15:48 |
| ogra_ | kyrofa, about 30 lines of uboot code | 15:49 |
| kyrofa | ogra_, ah, okay. Still 32-bit, right? | 15:50 |
| ogra_ | yeah | 15:50 |
| kyrofa | ogra_, is it "officially" supported? | 15:50 |
| ogra_ | ppisati already landed an arm64 kernel but i didnt find the time to tinker with that | 15:51 |
| zyga | Pharaoh_Atem: how can I do that? | 15:51 |
| ogra_ | yeap, pi2 and 3 are official ... drgoboard too ... | 15:51 |
| Pharaoh_Atem | zyga: first, pull in my PR | 15:51 |
| ogra_ | beaglebone is community supported | 15:51 |
| zyga | yep | 15:51 |
| jdstrand | ogra_: hey-- in the snapcraft@ mailing list you mention a README for flashing the dragonboard. I created an image, dd'd it to a device then botted up be get some qualcomm thing. is there more information on how to boot from the sd card? | 15:51 |
| Pharaoh_Atem | then next, regenerate that patch with new systemd units based on the ones from upstream, merging in the differences from the old units to the new ones (paths, environmentfile, etc.) | 15:52 |
| jdstrand | ogra_: I don't see that README file anywhere | 15:52 |
| ogra_ | jdstrand, well ... use mvo's godd snap ;) | 15:53 |
| Pharaoh_Atem | zyga: also, keep in mind, stuff that refers to /snap will need to change to /var/lib/snapd/snap | 15:53 |
| ogra_ | jdstrand, beyond that ... the only thing you need to do is to turn the dip switch for SD booting on the bottom of the board on | 15:53 |
| zyga | Pharaoh_Atem: ack | 15:54 |
| jdstrand | ogra_: ah! | 15:54 |
| zyga | Pharaoh_Atem: merged | 15:55 |
| ogra_ | jdstrand, xzcat ./ubuntu-core-16-dragonboard.img.xz | sudo godd - /dev/sdc | 15:55 |
| ogra_ | jdstrand, thats how i flash it | 15:55 |
| elopio | pitti: ping. Can you help me debugging why the autopkgtests from snapcraft github are not running? | 15:56 |
| pitti | elopio: oh, welcome back! I was going to ask you how that went some weeks ago | 15:56 |
| elopio | I've just updated the branches now that we are clean after a release, but I don't see any results | 15:56 |
| elopio | https://github.com/snapcore/snapcraft/pull/874 | 15:56 |
| mup | PR snapcraft#874: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/874> | 15:56 |
| pitti | elopio: in the middle of building psql updates and running out for dinner, but sure | 15:56 |
| elopio | pitti: I can wait until tomorrow. | 15:57 |
| pitti | elopio: well, whatever these tests are, it's not the autopkgtest.u.c. infra | 15:57 |
| pitti | these are pointing to some jenkins? | 15:57 |
| Pharaoh_Atem | elopio: errm, what do I do about this? https://travis-ci.org/snapcore/snapcraft/jobs/170776507#L2096 | 15:57 |
| elopio | Pharaoh_Atem: hello. Looking. | 15:58 |
| Pharaoh_Atem | elopio: Hi :) | 15:58 |
| elopio | pitti: ignore all those failing tests. They are for our existing jenkins, which will fail of course because they are expecting a debian directory. | 15:59 |
| elopio | My idea is to replace the four of them with your infrastructure. | 15:59 |
| elopio | Pharaoh_Atem: oh, sucks. Do you get that out of memory error running locally? | 16:00 |
| pitti | elopio: I don't see a recent snapcraft related error in the logs; can you prod the web hook on your side? does a ping work? | 16:00 |
| pitti | elopio: i. e. maybe some mismatch in the password? | 16:00 |
| elopio | pitti: I can't change the hook because I'm not admin. But sergiusens can. | 16:01 |
| elopio | Sergio, are you around? | 16:01 |
| pitti | bbl | 16:02 |
| pitti | (back in ~ 3 hours) | 16:02 |
| elopio | pitti: have a good night! | 16:03 |
| sitter | mhall119: not from CI yet. I hope to have everything done on automation earlier next week so I can write a blog post and invite more of our devs to join in improving their snaps. | 16:05 |
| Pharaoh_Atem | elopio: hmm, weird, I get an OOM error locally now too | 16:10 |
| elopio | Pharaoh_Atem: you are using a scary library there :) | 16:10 |
| Pharaoh_Atem | :S | 16:10 |
| sergiusens | elopio for a bit | 16:11 |
| === kallisti6 is now known as kallisti5 | ||
| gQuigs | is it just me or does snapd.firstboot.service start up every boot? | 16:12 |
| mup | PR snapd#2198 closed: tests: only check pc model for the ubuntu-core-16-64 system <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2198> | 16:13 |
| mup | PR snapd#2217 closed: tests: increase wait time for service to be up <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2217> | 16:13 |
| gQuigs | a /var/lib/snapd/firstboot/stamp is never created.... | 16:13 |
| mup | PR snapcraft#875 opened: Add the test upstream rules <Created by elopio> <https://github.com/snapcore/snapcraft/pull/875> | 16:13 |
| mup | PR snapcraft#875 closed: Add the test upstream rules <Created by elopio> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/875> | 16:16 |
| Pharaoh_Atem | elopio: okay, this is retarded | 16:17 |
| Pharaoh_Atem | I can only have a list of one object, or it breaks | 16:17 |
| Pharaoh_Atem | mugh | 16:17 |
| elopio | sergiusens: there's something wrong in our autopkgtest hook, but I'm not sure how to debug it. | 16:18 |
| elopio | Pharaoh_Atem: not funny. Is that a bug on the library? | 16:19 |
| Pharaoh_Atem | I think so, yes | 16:19 |
| Pharaoh_Atem | I have a tiny reproducer test case sample, so I'll probably file a bug with python-libarchive-c about it | 16:19 |
| Pharaoh_Atem | but :S | 16:20 |
| elopio | Pharaoh_Atem: alright! one point for the test suite, it's even finding bugs in libarchive :D | 16:20 |
| mup | PR snapd#2227 opened: overlord/snapstate: add dynamic snapdX.Y assumes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2227> | 16:21 |
| Pharaoh_Atem | elopio: libarchive is scary :( | 16:22 |
| Pharaoh_Atem | but the alternative of having to detect every single possible compression algorithm that could be used in an rpm payload is simply not worth it | 16:23 |
| elopio | Pharaoh_Atem: I agree. Any possible workaround while they release a fix? | 16:23 |
| MikeB | sergiusens, a couple days ago we chatted about the issues surrounding the kernel plugin pulling from edge... | 16:27 |
| MikeB | As an experiment, I changed it to pull from stable. | 16:27 |
| MikeB | Thane ran ubuntu-image pulling from stable. | 16:27 |
| MikeB | s/thane/then/ | 16:28 |
| Croepha | Where can I find the snapcraft.yaml for the official vanilla kernel that comes with core 16? | 16:28 |
| MikeB | Still didn't work - get the error about snapd being too old. | 16:28 |
| MikeB | Any suggested workaround? | 16:28 |
| jdstrand | ogra_: my dragonboard gets a dhcp address, but ssh connection is slow and I see it asking for an ip frequently. is this known? I guess it could be this: wcn36xx: ERROR hal_remove_bsskey response failed err=16 | 16:29 |
| ogra_ | weird, i dont have such things here | 16:29 |
| ogra_ | ogra@wall2:~$ grep DHCPREQ /var/log/syslog|grep dragon | 16:30 |
| ogra_ | Oct 27 12:29:36 wall2 dhcpd: DHCPREQUEST for 192.168.2.69 (192.168.2.2) from 02:00:25:af:71:aa (dragon) via p4p1 | 16:30 |
| ogra_ | Oct 27 13:17:55 wall2 dhcpd: DHCPREQUEST for 192.168.2.56 (192.168.2.2) from 02:00:25:af:71:aa (dragon) via p4p1 | 16:30 |
| ogra_ | Oct 27 15:17:54 wall2 dhcpd: DHCPREQUEST for 192.168.2.56 from 02:00:25:af:71:aa (dragon) via p4p1 | 16:30 |
| ogra_ | Oct 27 17:17:52 wall2 dhcpd: DHCPREQUEST for 192.168.2.56 from 02:00:25:af:71:aa (dragon) via p4p1 | 16:30 |
| sergiusens | MikeB said it was wrong, but ogra_ told me to leave it there for a bit | 16:30 |
| ogra_ | right, until stable isnt so outdated anymore ... i doubt the initrd would successfully boot | 16:31 |
| MikeB | sergiusens, understood. Just looking for an interim workaround I could implement if there is one. | 16:32 |
| ogra_ | (or it might boot but things would fail during boot due to missing mounts etc) | 16:32 |
| ogra_ | MikeB, if you tell ubuntu-image to use stable *everything* comes from stable | 16:32 |
| MikeB | Any idea when stable may be modernized? | 16:32 |
| ogra_ | in ~7 days | 16:33 |
| ogra_ | build from edge,beta or candidate until then | 16:33 |
| MikeB | ogra_, Great. I can wait. | 16:33 |
| ogra_ | candidate should largely be what will go to stable next week | 16:33 |
| elopio | Croepha: http://bazaar.launchpad.net/~snappy-dev/pc-kernel-snap/trunk/view/head:/snapcraft.yaml | 16:34 |
| MikeB | I've had no luck with edge and beta. Haven't tried candidate. I'll give that a try. Thanks. | 16:34 |
| Croepha | elopio: Thank you so much ! :) | 16:34 |
| Croepha | wow, thats really different then the ones in the examples | 16:35 |
| ogra_ | MikeB, well, edge and beta work for all other images ... su better track down why exactly it fails, jumping around on different channels wont solve that | 16:36 |
| ogra_ | Croepha, that is because it needs to use the deb package from the archive | 16:36 |
| ogra_ | other kernels do not need that | 16:37 |
| ogra_ | (the binaries in the deb are signed with the ubuntu archive key, which is essential for secure boot environments to work) | 16:37 |
| ogra_ | mvo, yummy ! betas with pi and more ! | 16:38 |
| Croepha | hmm, well, maybe instead of trying to emulate what the vanilla core kernel is doing, maybe i should just say what my problem is... I tried to build a custom kernel for the intel compute stick based on a source tree I found on github (linuxium) ive used their binaries before and they work... When I booted off the drive there isn't any drivers in the initramfs just squashfs (probably just because that was the one listed in the 96boards kernel | 16:41 |
| Croepha | snapcraft.yaml that I copied over...) , I want the image to be general purpose so I want a good set of drivers.... | 16:41 |
| ogra_ | no, you dont :) | 16:41 |
| MikeB | ogra_ I think the problem is related to using a custom kernel to build the image. The error message implies a version/channel mismatch somewhere... | 16:42 |
| ogra_ | you want a handfull of controller drivers and filesystems ... we do not support anything more than detecting your rootfs from the initrd | 16:42 |
| ogra_ | (no netbooting or any such fancy stuff) | 16:42 |
| ogra_ | you can try to grab the config from a xenial ubuntu desktop install and base on that ... then add a few basic controller drivers to the snapcraft..yaml and be done | 16:43 |
| Croepha | ogra_, ok I'll try that, thanks | 16:44 |
| mhall119 | sitter: sounds great, let me know when the blog post is up, I'd love to share it around | 16:44 |
| Croepha | ogra_: btw, it looks like a full set of drivers got built and made it into the .snap, they just didn't make it into the initrd | 16:48 |
| ogra_ | on purpose | 16:48 |
| elopio | sergiusens: pitti: oh it's running, it's awesome! I used the retry script, so the problem is in our hook for sure. | 16:48 |
| ogra_ | we dont want big initrds on IoT devices | 16:48 |
| Croepha | makes sense | 16:49 |
| Croepha | just saying its not a kernel .config problem | 16:49 |
| ogra_ | we put ahci, usbstrorage and a few MMC controller drivers into the pc-kernel snap initrd currently | 16:49 |
| ogra_ | all filesystems are builtin | 16:50 |
| Croepha | so i just add that to "kernel-initrd-modules" section and that should be it right? | 16:50 |
| ogra_ | yep | 16:50 |
| Croepha | sweet | 16:50 |
| Croepha | Thanks for the help :) | 16:50 |
| mup | PR snapd#2220 closed: overlord/snapstate: fix missing argument to Noticef <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2220> | 16:52 |
| jdstrand | well, I reflashed the dragonboard with mvo's images and it's the same thing. if there is network traffic, it starts disassociating and reassociating | 17:15 |
| ogra_ | strange | 17:26 |
| ogra_ | jdstrand, are you using the default power supply ?? | 17:27 |
| ogra_ | might be a low current issue | 17:27 |
| jdstrand | ogra_: I was sent the board with a power supply in a box. I guess it is default for me | 17:42 |
| ogra_ | yeah, same here | 17:42 |
| ogra_ | do you have any 5GHz in your house (only 2.x here) | 17:42 |
| ogra_ | perhaps that makes some difference | 17:43 |
| jdstrand | I do | 17:44 |
| jdstrand | and it is connecting to it. is there a way in console-conf to prefer 2.4? | 17:44 |
| jdstrand | 5G and 2.4G use the same ssid | 17:44 |
| ogra_ | i dont think there is a way, no | 17:46 |
| ogra_ | you'd hack it yourself into the wpa-supplicant config i fear | 17:46 |
| jdstrand | ogra_: hrmm... of course, I don't have a reliable console to do that. maybe if I can set a password then I can hook up a keyboard and login | 17:49 |
| ogra_ | yep | 17:49 |
| jdstrand | that's a big if at this point :) | 17:49 |
| dobey | wrap the antenna in a physical filter that blocks 5GHz but allows 2.4GHz? | 17:50 |
| kyrofa | jdstrand, the wifi driver in my dell M3800 periodically disconnected from 2.4 and connected to 5 (like every 10 minutes) when they had the same SSID | 17:50 |
| kyrofa | I had to change it | 17:51 |
| dobey | why does everything have crappy wifi chips | 17:51 |
| kyrofa | dobey, I think that every time I install ubuntu on something and cross my fingers | 17:52 |
| jdstrand | most of my devices are pretty happy with it. I guess I'll need to consider that | 17:52 |
| kyrofa | jdstrand, took me way too long to figure out that was the cause | 17:53 |
| dobey | kyrofa: i just only buy laptops with intel wifi and only buy phones with qualcomm. works pretty well then :) | 17:53 |
| kyrofa | jdstrand, and historically, the dragonboard wifi driver has been terrifyingly bad | 17:53 |
| dobey | though i guess dragonboard is qualcomm | 17:53 |
| jdstrand | dobey: interestingly, my wife's wifi has iwlwifi (intel) and I had to disable 5g on it and this is a qualcomm :P | 17:54 |
| kyrofa | Hahaha | 17:54 |
| jdstrand | (this meaning the dragonboard) | 17:54 |
| dobey | the dragonboard is weird though i guess becuase unlike the phones we don't have the android device tree binary blobs | 17:54 |
| jdstrand | this is slowly killing me. now it won't associate at all | 17:55 |
| dobey | so we're stuck with the reverse engineered open source drivers | 17:55 |
| stgraber | sergiusens: hey there, would I be right in assuming that stage-packages will be a bit unhappy if a package isn't available (architecture specific)? | 17:57 |
| kyrofa | stgraber, yeah it'll fail | 17:58 |
| dobey | heh | 17:59 |
| stgraber | well, that sucks :) | 17:59 |
| * stgraber goes to file another snapcraft bug | 17:59 | |
| dobey | i guess someone could build a 3.10 kernel snap for dragonboard using the lollipop device tree for it | 18:00 |
| dobey | bet wifi might work better then | 18:00 |
| bzoltan | sergiusens: I am working on a snapcraft plugin. How can I know the main project's name and how can I copy out stuff from the parts to the same place where the result .snap is placed? | 18:07 |
| pstolowski | kyrofa, ping | 18:19 |
| kyrofa | Hey pstolowski! | 18:19 |
| kyrofa | What's up? | 18:19 |
| jdstrand | ok, I give up. it was connecting to 2.4G, I tried forcing to 5G, it just doesn't work | 18:39 |
| jdstrand | I tried using a usb wifi, nope. I tried unloading the other module, segfault | 18:40 |
| * jdstrand goes to be productive somewhere | 18:40 | |
| mup | PR snapcraft#876 opened: Allow for architecture-specific packages <Created by stgraber> <https://github.com/snapcore/snapcraft/pull/876> | 18:52 |
| pitti | elopio: hmm, "running", I don't see it queued or running? | 19:02 |
| pitti | elopio: what's the PPA you run these tests with? I'd like to check swift if there's any result, i. e. whether it's the request or the status_url end | 19:06 |
| dobey | i presume that attempting to do "snap login" with an e-mail address that i've already logged in with, returning an error about username/password being wrong, is a bug? | 19:24 |
| kyrofa | dobey, what... that's not expected behavior? | 19:29 |
| dobey | kyrofa: ah i miss your sarcasm ;) | 19:33 |
| kyrofa | dobey, nice to see you around, too ;) . Yeah, log a bug | 19:33 |
| kyrofa | Now I wonder how snapcraft handles that | 19:34 |
| dobey | yeah, i'm trying to decide how to deal with all these weird little conditions, to make the u1 online-accounts plug-in log in via snapd, and not cause the world to implode | 19:35 |
| kyrofa | dobey, are you using the REST API for that, then? | 19:38 |
| dobey | kyrofa: yeah, to snapd | 19:38 |
| kyrofa | dobey, and that's saying wrong username/password if you're already logged in? | 19:39 |
| dobey | kyrofa: presumably it is. i haven't got that code implemented yet. i was just trying with snap cli to see what happens | 19:39 |
| dobey | kyrofa: or maybe it's just bloody confusing and i typed the wrong password | 19:41 |
| kyrofa | dobey, hmm, looking at the "error kinds" in rest.md, there doesn't seem to be one for invalid login info | 19:41 |
| kyrofa | dobey, there's invalid-auth-data, but the example it gives is an invalid email address | 19:41 |
| dobey | kyrofa: because when you type "sudo ..." and the only line is "Password:" it's not entirely clear which password one needs to type | 19:42 |
| dobey | so i can log in a second time just fine, it seems | 19:42 |
| dobey | but the cli is a bit unclear | 19:42 |
| kyrofa | dobey, whoops, just sent your sudo password to the store eh? | 19:43 |
| dobey | kyrofa: well, the password for the user in the vm :) | 19:43 |
| kyrofa | dobey, heh | 19:44 |
| dobey | https://bugs.launchpad.net/snappy/+bug/1637299 | 19:46 |
| mup | Bug #1637299: sudo snap login "Password:" prompt unclear what password to type <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637299> | 19:46 |
| mup | Bug #1637299 opened: sudo snap login "Password:" prompt unclear what password to type <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637299> | 19:47 |
| pitti | sergiusens, elopio: still here for about an hour or so, if you want to look at the snapcraft tests | 20:03 |
| Pharaoh_Atem | elopio: I've worked around the issue with libarchive | 20:10 |
| Pharaoh_Atem | the integration test passes now | 20:10 |
| Croepha | is there a known issue where snapcraft'ing a kernel can lead to a "File exists" error when building the initrd? | 20:44 |
| pitti | elopio: oh look, a snapcraft upstream request in http://autopkgtest.ubuntu.com/running#queue-upstream-xenial-amd64 | 21:29 |
| pitti | (doing maintenance, will run soon) | 21:29 |
| === matteo` is now known as matteo | ||
| mup | Bug #1637324 opened: snapd does not provide a REST API to log out <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637324> | 21:42 |
| mup | Bug #1637325 opened: snapd provides no way to register a new account <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637325> | 21:42 |
| sethj | does snappy put $SNAP in XDG_CONFIG_DIRS? | 22:01 |
| kyrofa | sethj, I don't believe so. Nothing defined that config files should go there | 22:05 |
| mup | Bug #1637328 opened: Ubuntu Core 16 includes libnss-resolve from universe <Snappy:New> <https://launchpad.net/bugs/1637328> | 22:06 |
| kyrofa | e.g. they might be in SNAP_DATA | 22:06 |
| sethj | kyrofa, sorry, just realized I meant XDG_DATA_DIRS, not CONFIG_DIRs. | 22:06 |
| sethj | I'm trying to figure out how to make my app work with snaps without too much source change, since it's looking in /usr/share/app-name for stuff. | 22:07 |
| kyrofa | sethj, the answer still applies. Nothing says you have data in $SNAP/, or $SNAP/data, or $SNAP/usr/share/app-name | 22:08 |
| josharenson | How can I increase the size of my snappy core image? I think I made the /writable device larger, but "/" is still out of space | 22:08 |
| kyrofa | sethj, but if you know where the data is, you can define it, no? | 22:08 |
| sethj | kyrofa, I'm not sure I understand what you are saying. The app puts files in /usr/share/app-name. snappy puts them in /snap/app-name/#######/usr/share/app-name, but that doesn't work because the app itself looks in /usr/share/app-name. I thought if I changed the app to look in XDG_DATA_DIRS it might work, but it has been a long time since I thought about that and I lost my source. | 22:11 |
| kyrofa | sethj, ah, I see what you're saying. I thought you had an app that looked in XDG_DATA_DIRS and was confused why it wasn't working as a snap | 22:12 |
| kyrofa | sethj, there's no FHS enforced or even suggested when it comes to snaps. You can format them however you wish. The only requirement is that it's self-contained (i.e. everything is inside $SNAP somewhere) | 22:15 |
| kyrofa | sethj, you have an application that sounds like it's hard-coded to assume the presence of a FHS | 22:15 |
| kyrofa | sethj, if you're considering a patch, might I suggest simply supporting a cli flag (--data-dir or similar) to redirect it? | 22:15 |
| kyrofa | josharenson, not only do you have to make the partition larger, but you have to resize the filesystem as well | 22:18 |
| kyrofa | josharenson, e.g. resize2fs | 22:19 |
| sethj | kyrofa, I may be ignorant, but the app is a collection of shell/python scripts. How else would I find config files/scripts it placed other than hard coded the location? I put them there, after all.. | 22:19 |
| kyrofa | sethj, but the hard-coded path is in /usr/share, which isn't contained in the snap | 22:21 |
| sethj | right | 22:21 |
| sethj | but that's snappy's problem, not the apps. | 22:21 |
| sethj | I'm not the one doing semi-sandboxing ;) I didn't explicitely put the files in $SNAP/usr/share. I put them in /usr/share. snappy decided to put them under $SNAP (which makes sense) but how good is a packaging format if I have to edit the code so it works? Neither debian nor rpm packaging makes it that hard. | 22:22 |
| dobey | well it's the app developer making the assumptiong that XDG_DATA_DIRS is available/used everywhere | 22:23 |
| josharenson | kyrofa: ah thanks... that grew the writable partition, but installing snaps still results in "no space left on device" | 22:23 |
| sethj | dobey, you'll note I haven't even used XDG_DATA_DIRS yet. But hard coding $SNAP into my paths is just as bad, no, worse, than hard coding /usr/share. | 22:23 |
| dobey | sethj: snap is not simply a "packaging format" in the traditional sence of the word | 22:23 |
| dobey | sense | 22:24 |
| dobey | sethj: i'm not saying that's what you should, or implying that you are using XDG_DATA_DIRS directly. glib for example has no idea about containment, and is the owner of the implementation that a great many things use when it comes to finding files that those things have installed to the system | 22:25 |
| dobey | so you would need a patched glib that handles the $SNAP for you | 22:25 |
| sethj | that's insane. | 22:26 |
| dobey | no, it's different | 22:27 |
| sethj | they aren't mutually exclusive. | 22:28 |
| dobey | well, not that different really. distributors have had to take upstream source code and patch it to fit into a productized system for decades | 22:28 |
| sethj | ;) | 22:28 |
| sethj | dobey, yes and I have my fair share of experience with that, but not quite like this. | 22:28 |
| sethj | I hate to be "that guy", but I can't be the only person having this problem and the lack of solutions makes me wonder what the goal is here. | 22:29 |
| pitti | you aren't | 22:30 |
| pitti | I've seen crazy patches like https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 :) | 22:30 |
| dobey | well i don't quite understand what your problem is. you're saying that the way you package things for a different system doesn't work for this system. this is no different than if you were to package your thing for native windows. the way files are placed and discovered by the installer and application there works completely differently from debs and rpms too | 22:31 |
| sethj | dobey, no, I'm saying snappy puts my files in places I didn't put them, but provides me no method of finding them unless I hard code my app to figure out where snappy puts things (which is NOT where I put them) | 22:32 |
| dobey | yes, some applications and libraries may be more difficult to fit into the snap world than others | 22:32 |
| dobey | but that doesn't make it insane | 22:32 |
| dobey | sethj: it puts them exactly where you put them. that's the problem | 22:32 |
| sethj | you guys express shock at my hard coded paths but then tell me the only way to get my files is to hard code the snappy path... | 22:33 |
| dobey | i didn't say anything about hard coded paths | 22:33 |
| dobey | there are many solutions to this problem | 22:33 |
| kyrofa | sethj, I never suggested hard-coding anything. I suggested making the app more flexible via cli-flags (find my data there, find my configs there, etc.) | 22:33 |
| dobey | you could fix your application to resolve file paths relatively | 22:33 |
| kyrofa | sethj, darktable does it this way, apache does it this way, etc. | 22:34 |
| dobey | you could compile your data into the application as resources | 22:34 |
| dobey | getenv("SNAP") is also not at all "hard coding a path" | 22:34 |
| sethj | yes it is. since snappy is the only thing that sets snap. Hence my desire to use XDG_DATA_DIRS (which I still think would work) because it already works with Debian/Ubuntu and should work with Fedora and Arch too. | 22:35 |
| kyrofa | sethj, indeed, that would work, but you'll need to set it | 22:36 |
| sethj | kyrofa, fair enough. I apologize if I come across upset. | 22:36 |
| dobey | well snapdir = getenv("SNAP"); setenv("XDG_DATA_DIRS", sanpdir) | 22:36 |
| dobey | whatever | 22:36 |
| kyrofa | sethj, you're having understandable frustrations. One of the biggest complications when snapping something can be the requirement that it should be relocatable. This is historically not something to which projects are accustomed | 22:37 |
| dobey | you need to fix your app to be relocatable (work as installed in a different root path) and to work in a confined world | 22:38 |
| sethj | again, I don't mean to be "that guy" (I've dealt with him enough), but I really don't see how this is supposed to catch on. I've already had to hack font and gtk support, now this... | 22:38 |
| sethj | dobey, but there is no way to do that without hard coding your list of root paths. at least not in snappy's case if it doesn't set any env variables to help (unless it does and I missed something somewhere?) | 22:39 |
| dobey | yes there is | 22:39 |
| dobey | it sets $SNAP | 22:39 |
| dobey | the system doesn't know where the files are inside your snap that you need to find, so it can't possibly set XDG variables to something inside your snap for you | 22:40 |
| sethj | which is practically the same thing as hard coding the root path as only snappy will ever set $SNAP. Oh well. | 22:40 |
| dobey | it can only tell you the root to your snap, and then you have to find things under it yourself | 22:41 |
| sethj | dobey, right. shouldn't it add $SNAP/usr/share to XDG_DATA_DIRS? | 22:41 |
| dobey | well, nothing other than snappy is going to install or run your thing that's a snap | 22:41 |
| dobey | no | 22:41 |
| kyrofa | sethj, no, $SNAP/usr/share isn't a standard path | 22:42 |
| dobey | maybe snapcraft could have some convenience things that does something like that, to make it easier to migrate things | 22:42 |
| dobey | but once your app is installed in the system, all that should be inside your snap, in a wrapper script or something | 22:43 |
| kyrofa | dobey, indeed, I suspect some of the desktop-helper parts do that | 22:43 |
| dobey | if you want to migrate something and aren't using snapcraft, it's going to be a fair bit more work to do, but if done right, will be closer to what an ideal snapped application should be | 22:44 |
| sethj | is the ideal snapped application layed out somewhere? I am using snapcraft, but tbh I have no way of knowing how well I am using it. The documentation isn't great. Or at least it wasn't 6 months ago when I started this. | 22:45 |
| dobey | for gui applications on ubuntu, the "ideal" snap of an app i suspect won't be terribly far off from what clicks are on the phone today | 22:46 |
| sethj | if only I knew anything about clicks. | 22:48 |
| dobey | there are certainly things about how gtk+ and traditional applications work, that makes confining such applications quite difficult | 22:49 |
| kyrofa | sethj, snapcraft has a concept of remote parts (i.e. parts defined by others). There are several out there for gtk- and qt-based apps. Have you seen those? Or the examples in the playpen? | 22:49 |
| sethj | kyrofa, I think I've seen some. I started this a few days before the playpen became a thing though. I should look at it again. | 22:50 |
| dobey | anyway, time for me to go. good luck | 22:50 |
| kyrofa | sethj, the gtk parts define a slew of environment variables that might interest you | 22:50 |
| kyrofa | sethj, an example: https://github.com/ubuntu/snappy-playpen/blob/master/hexchat/snapcraft.yaml | 22:50 |
| nacc | sethj: i would recommend refreshing the documentation, as it's quite a bit more updated (not perfect by any means) than it was 6 months ago | 22:50 |
| kyrofa | Note that the app is launched with a wrapper provided by the desktop-gtk2 part called `desktop-launch` | 22:51 |
| sethj | alright, I'll give it a shot. | 22:51 |
| kyrofa | Alright, EOD here as well. Have a great day everyone! | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!