| robert_ancell | elopio, did lots of talking here, it looks like we might be able to use macaroons to validate the user thus avoiding the need for PolicyKit (at least initially). So it may be possible to avoid adding these tests. | 01:34 |
|---|---|---|
| robert_ancell | elopio, thanks for the info | 01:34 |
| elopio | robert_ancell: cool. | 01:34 |
| elopio | now we need to figure out how to test macaroons authentication :) | 01:36 |
| robert_ancell | elopio, yeah, hopefully that wont be my problem! ;) | 01:36 |
| sergiusens | elopio, kyrofa in case you get bored https://github.com/ubuntu-core/snapcraft/pull/328 | 02:20 |
| dholbach | good morning | 07:49 |
| didrocks | hey dholbach! | 07:51 |
| dholbach | salut didrocks | 07:53 |
| zyga | good morning :) | 08:04 |
| zyga | fgimenez: hey :)o/ | 08:04 |
| fgimenez | good morning zyga :) | 08:04 |
| zyga | friday, I cannot believe how quick this week was | 08:05 |
| shuduo_ | hello, i'm working on a snappy lights-on on a rockchip board. i'm reading the doc from https://developer.ubuntu.com/en/snappy/guides/porting/. the first step in "Getting started" section but wonder if there is an official document regarding how to build oem snap. i can read code by referring to https://github.com/longsleep/snappy-odroidc but would like to know if official/internal doc exist. Thanks. | 08:21 |
| === faenil_ is now known as faenil | ||
| shuduo | ogra_: ping | 08:51 |
| longsleep | Good morning snappy, so my snap for 16.04 from yesterday was reviewed and accepted, but the new version shows as "unpublished" while the top of the myapps page says it is published. Any suggestions? | 09:05 |
| longsleep | ah just found the Publish button at the very bottom of the page after all the history :) | 09:06 |
| ogra_ | shuduo, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files has our official gadgets, note that trhis is for 16.04 and already uses the all-snaps setup for images though | 09:30 |
| shuduo | ogra_: i'm reading on it too. i tried to build them but only pi2.moved be made successfully. i can refer to pi2.moved too but wonder why others don't work. Or should I need switch to 16.04? Another question is where i can download 16.04's decice.tar.xz armhf version? I tried u-d-f query but can't get it as I don't know what 16.04 channel exactly is. | 09:37 |
| ogra_ | shuduo, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ | 09:39 |
| shuduo | ogra_: got it. thanks. | 09:39 |
| zyga | hmm, my pi updated last night | 09:43 |
| zyga | but crashed (didn't reboot successfully) | 09:44 |
| ogra_ | capture the serial log (if you can) | 09:46 |
| ogra_ | thats not the all-snaps one i assume ? | 09:46 |
| longsleep | ogra_: when i start with getting 16.04 on the odroidc1 should i look for that all-snap thing you are talking about? | 09:52 |
| * longsleep might have some time on the weekend | 09:53 | |
| ogra_ | longsleep, yeah, the old system-image stuff is dead, we'll default to all-snaps in 16.04 very soon | 09:55 |
| longsleep | ogra_: ok cool, and what tool would i use to create a device snap or whatever it is called :) | 09:56 |
| ogra_ | longsleep, http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files | 09:58 |
| longsleep | ogra_: awesome thanks! | 09:59 |
| ogra_ | longsleep, you need xeinal for this (for the --squashfs support in snappy) | 09:59 |
| ogra_ | *xenial | 09:59 |
| ogra_ | longsleep, also: http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/ you need this u-d-f | 10:00 |
| ogra_ | (see the README for the options, --gadget, --kernel and --os all also take a local path to a snap) | 10:01 |
| longsleep | great, i will have a look tomorrow. I also have the Pine64 and might try that one first | 10:02 |
| popey | Still can't quite figure out how to do network client (not server) from my snappy app. examples seem to mostly be services/servers... any clues? | 10:33 |
| ogra_ | you'd do it the exactly same way | 10:33 |
| ogra_ | i.e. define the skill under "apps:" and just dont set "daemon:" for the app | 10:34 |
| popey | got an example of something that's a client? | 10:35 |
| didrocks | popey: 16.04? | 10:36 |
| ogra_ | popey, http://paste.ubuntu.com/15130014/ | 10:39 |
| ogra_ | try something like this | 10:39 |
| popey | didrocks: yes | 10:39 |
| didrocks | yeah, ogra beats me to it :) | 10:40 |
| ogra_ | well, untested :) | 10:40 |
| didrocks | looks like typo free :) | 10:40 |
| * popey tries this | 10:42 | |
| ysionneau | any idea what could be the origin of this error? http://paste.ubuntu.com/15130024/ | 10:43 |
| === faenil is now known as faenil_ | ||
| === faenil_ is now known as faenil | ||
| popey | hm. "Bad system call" from the application 😖 | 10:46 |
| ogra_ | popey, check syslog, i bet there is a seccomp error | 10:46 |
| popey | [262021.832942] audit: type=1326 audit(1455878770.782:89): auid=1000 uid=1000 gid=1000 ses=30 pid=32171 comm="whois" exe="/snaps/whois.sideload/INCRgCAKgHXE/usr/bin/whois" sig=31 arch=40000028 syscall=282 compat=0 ip=0x76ed2348 code=0x0 | 10:46 |
| ogra_ | sig=31 | 10:47 |
| popey | wonder if it's trying to write to /tmp or something | 10:47 |
| ogra_ | scmp_sys_resolver 31 | 10:48 |
| ogra_ | check that | 10:48 |
| ogra_ | (tells you the syscall) | 10:48 |
| ogra_ | all apps can write to /tmp ... the yhave a transparently mounted one that they own | 10:48 |
| popey | oh | 10:49 |
| ogra_ | oh, wait | 10:49 |
| popey | scmp_sys_resolver 31 returns UNKNOWN | 10:49 |
| ogra_ | scmp_sys_resolver 282 | 10:49 |
| ogra_ | yeah | 10:49 |
| ogra_ | i picked the wrong thing from your line | 10:49 |
| ogra_ | not sig ... buts syscall= (obviously) | 10:49 |
| ogra_ | ysionneau, never seen that | 10:50 |
| ogra_ | but data.tar.gz sounds like a debian package somehow | 10:50 |
| ysionneau | I've built a .snap package with snapcraft, it contains data.tar.gz inside | 10:51 |
| ysionneau | the .snap seems to be pretty close from a .deb | 10:51 |
| ogra_ | that might not be allowed | 10:51 |
| ysionneau | why would snapcraft generate something not allowed? :o | 10:52 |
| ogra_ | (not sure though) | 10:52 |
| didrocks | ysionneau: that's the case in 15.04, it's using the same format (ar) | 10:52 |
| ysionneau | yes | 10:52 |
| didrocks | which has the control and data.tar.gz | 10:52 |
| ogra_ | ah, 15.04 | 10:52 |
| ysionneau | yes 15.04 | 10:52 |
| ysionneau | ok, let me explain what I'm doing, I'm adding support for cross compilation to snapcraft | 10:53 |
| ysionneau | but in the control/manifest it still shows "amd64" instead of "armhf" | 10:53 |
| ysionneau | so I modified the ar archive (extracted control.tar.gz, modified the amd64 to armhf, put back control.tar.gz in the .snap) | 10:54 |
| ysionneau | but now I get this error | 10:54 |
| popey | ogra_: scmp_sys_resolver 282 returns "bind" | 10:55 |
| popey | it's whois, so it's doing a dns lookup I imagine | 10:55 |
| ogra_ | popey, hmm, then you might need more network- skills ... | 10:55 |
| popey | I need more skills for sure ã‹› | 10:56 |
| popey | are they listed somewhere? | 10:56 |
| ogra_ | try adding "network-listener, network-service" to the caps line | 10:56 |
| ogra_ | servuice might be a bit much though, since you dont run a server | 10:56 |
| ogra_ | ysionneau, i'm pretty sure snappy creates checksums of the files it carries internally ... | 11:05 |
| popey | hmmm | 11:05 |
| popey | $ whois.whois 8.8.8.8 | 11:05 |
| popey | getaddrinfo(whois.arin.net): Servname not supported for ai_socktype | 11:05 |
| ogra_ | well, check syslog, there might be more | 11:05 |
| popey | nothing | 11:06 |
| popey | only the profile replace when it was installed | 11:06 |
| ogra_ | well, whois surely tries to access a socket it isnt allowed to (yet) | 11:07 |
| popey | I guess. | 11:07 |
| popey | is there no "give it all network access" like we do with clicks? | 11:07 |
| ogra_ | dunno, i'm still learning about skills | 11:08 |
| ricmm | longsleep: hey simon | 11:31 |
| ricmm | longsleep: I'm trying to run the webrtc client running on the arm64 device | 11:31 |
| ricmm | works fine in local lan, over internet it cant stablish the call | 11:31 |
| ricmm | "peer connection failed" but we can chat just fine | 11:31 |
| ricmm | I'm exposing 8443 over the internet through a reverse ssh tunnel to a VPS of mine | 11:32 |
| ricmm | could that be getting in the way? does spreed attempt to open other ports on demand for the peers? | 11:32 |
| ogra_ | you probably need other ports for the webrtc | 11:32 |
| ricmm | hmm I cant reach it from my phone | 11:34 |
| ogra_ | weird | 11:35 |
| ogra_ | i did a call from laptop to desktop yesterday | 11:35 |
| ricmm | oh, jesus | 11:35 |
| ogra_ | can you ping it from your phone ? | 11:35 |
| ricmm | longsleep: yea I guess it opens more ports on demand | 11:45 |
| kyrofa | ogra_, classic dimension doesn't seem to work for me on the dragonboard. Is that a known issue? | 12:10 |
| ogra_ | yes | 12:10 |
| ogra_ | bug 1543764 | 12:10 |
| ubottu | bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] https://launchpad.net/bugs/1543764 | 12:10 |
| kyrofa | ogra_, ahh, right I remember that one now | 12:22 |
| kyrofa | ogra_, no known workaround? | 12:23 |
| ysionneau | ogra_: would you know where those checksums are stored? | 12:23 |
| ysionneau | ogra_: I found hashes.yaml which contains sha512 of the files in data.tar.gz , but nothing for files in control.tar.gz | 12:24 |
| kyrofa | ogra_, I seem to remember you mentioning setting up a chroot? | 12:27 |
| ogra_ | kyrofa, scp http://cdimage.ubuntu.com/ubuntu-core/daily/current/xenial-core-amd64.tar.gz to the board ... create a dir under /home/ubuntu and extract it there ... then copy /etc/resolv.conf to etc/ and you can chroot ... | 13:07 |
| ogra_ | ysionneau, no, i have no idea, but i doubt you can safely hack an already assembled snap like you try to | 13:07 |
| ysionneau | hmm too bad :/ | 13:11 |
| ysionneau | is snapcraft doing the .snap? or is it calling snappy? | 13:11 |
| kyrofa | ogra_, sweet, okay. Hopefully this kernel doesn't have the swap deadlock bug that the linaro image had :P | 13:12 |
| kyrofa | ysionneau, depends on the version of snapcraft | 13:12 |
| ogra_ | kyrofa, i have been using a 2G swapfile here, worked fine | 13:12 |
| kyrofa | ysionneau, Version > 2, snapcraft does it. < 2, snappy | 13:12 |
| kyrofa | ogra_, awesome :) | 13:12 |
| kyrofa | ogra_, that should unblock the owncloud snap | 13:12 |
| ogra_ | yay | 13:12 |
| kyrofa | ogra_, and I'm crossing my fingers for ROS | 13:13 |
| ogra_ | haha, yeah | 13:13 |
| ysionneau | ok I'm using snapcraft 1.0.2 so it's snappy doing it... | 13:13 |
| ysionneau | thanks kyrofa ! | 13:13 |
| ysionneau | cool now I can see in snappy code where is the error message "Can not handle" | 13:15 |
| ysionneau | I had to checkout the 15.04 branch! | 13:15 |
| ysionneau | it means it does not understand which kind of compression algorithm to use... | 13:16 |
| zyga | good afternoon :) | 13:18 |
| zyga | (lovely day here today) | 13:18 |
| ysionneau | ok, it seems that when I use ar rD to replace control.tar.gz in the .snap by another one, it changes data.tar.gz name to data.tar.gz/ (at least that's what the sappy code sees, even if ar tv does not show the '/' suffix) | 13:24 |
| ysionneau | this extra / makes the code fail to recognize a tar.gz | 13:24 |
| ysionneau | by hexdumping I can indeed see extra / in the ar file header ... | 13:25 |
| ysionneau | so that would be a bug in the ar tool? :o | 13:25 |
| nessita | kyrofa, hi! I'm looking for a specific information and perhaps you can help. You know how snaps for 15.04 are totally incompatible with snaps for rolling-core, right? I wanted to know if there is such a clear difference between snaps targetting rolling-core and rolling-personal | 13:30 |
| kyrofa | nessita, great question | 13:30 |
| kyrofa | nessita, as of now, I don't believe so. Snappy (and snapcraft) don't do anything special for Personal right now. For example, there are no .desktop files, etc | 13:31 |
| nessita | kyrofa, we are improving the Store UI and we are gonna restrict the releases a developer can choose for his uploads | 13:31 |
| nessita | kyrofa, so you are saying that targetting both -personal and -core is safe, correct? | 13:32 |
| kyrofa | nessita, right now I'd say yes, but it's important to point out that there isn't even a personal image right now | 13:32 |
| nessita | kyrofa, I understand, so you are implying we should remove the rolling-personal release (or disable)? | 13:32 |
| kyrofa | nessita, while there will be eventually, I'm not sure hiding that option would be a bad thing right now | 13:32 |
| nessita | understood, thank you! | 13:33 |
| kyrofa | nessita, though you probably want to check that with someone who knows more than I do | 13:33 |
| nessita | kyrofa, yes, no worries, you will not be blamed :-) | 13:33 |
| kyrofa | nessita, ha! I just mean I don't want you to do any work only to find out I was wrong and you have to put it back :P . | 13:34 |
| ysionneau | ok I found the origin of the issue | 13:41 |
| ysionneau | trailing slashes are legal in ar format : https://en.wikipedia.org/wiki/Ar_%28Unix%29#System_V_.28or_GNU.29_variant | 13:42 |
| ysionneau | but the deb.go part of snappy does not handle them | 13:42 |
| noizer | HI guys, just a short question. Is it the same when how I can communicate with gpio's from my raspberry pi with ubuntu-snappy | 14:24 |
| noizer | ? | 14:24 |
| zyga | noizer: hmm, can you ask that again please>? | 14:27 |
| zyga | noizer: I've implemented a skill that allows to expose gpio's as "bool-file" | 14:27 |
| zyga | noizer: but this is not the full GPIO, no way to set direction, etc | 14:27 |
| ogra_ | most likely via the skills system ... in 15.04 hw-assign worked for that, but this got moved into skills now | 14:27 |
| zyga | noizer: (though that's east to add, bool-file was just the very first skill I made) | 14:27 |
| zyga | noizer: easy* not east :) | 14:28 |
| zyga | noizer: this week I also created an i2c skill and a demo snap that uses it | 14:28 |
| zyga | noizer: I plan to expose subsequent hardware feature of the pi as we progress | 14:28 |
| zyga | noizer: some things are not ready so you cannot still use skills for real, with released version of snappy | 14:29 |
| zyga | noizer: if you want you can try my development branch that allows you to do more | 14:29 |
| ogra_ | zyga, the question is if the store already knows about these new skills, i guess noizer would like to upload his snap at some point | 14:30 |
| zyga | noizer: have a look at http://github.com/zyga/snappy-pi2-piglow and https://github.com/zyga/snappy/tree/skills-demo-i2c | 14:30 |
| zyga | ogra_: no, the store doesn't currently know but at the same time, it never will know about particular skill types, just what snaps declare and what devices declare | 14:30 |
| zyga | noizer: so if you tell me more about what you need then perhaps I might be able to help you, perhaps not immediately but still | 14:31 |
| noizer | ogra_ zyga when will the store know this skills? | 14:31 |
| ogra_ | perhaps it already lets them through ... i was just asking too :) | 14:31 |
| noizer | I need i2c for an sensor and other gpio just for settings things | 14:31 |
| noizer | zyga | 14:32 |
| zyga | noizer: cool, stay in touch and we can talk | 14:32 |
| zyga | noizer: I can create a simple gpio skill that exposes both the value and direction of a particular pin | 14:32 |
| noizer | zyga So its not possible at this moment to use the gpio's | 14:32 |
| noizer | zyga ok | 14:33 |
| noizer | zyga how long does it takes to make this skill? | 14:33 |
| zyga | noizer: no, skills are not "glued" to the rest of snappy, that's our focus | 14:33 |
| zyga | noizer: depends on what you mean, it takes minutes to create a new skill but it will be a while before you can really use them with stuff in vanilla images | 14:33 |
| noizer | zyga but it this snap won't be in the store. So I think | 14:35 |
| zyga | noizer: if you develop it now with me | 14:35 |
| zyga | noizer: you can be ready for skills in 16.04 | 14:35 |
| zyga | noizer: and you can help us iron out issues | 14:36 |
| zyga | noizer: there's nothing better that I can think of, all of this will be live soon, just not today | 14:36 |
| noizer | Zyga So when I'm developing it and pushes to the git it will be in 16.04 | 14:36 |
| zyga | noizer: but you can get the skill side to work, starting now, by working with me | 14:36 |
| kyrofa | elopio, gah, I'm sorry, I lost track of the time | 14:37 |
| kyrofa | elopio, oh wait, you're off | 14:37 |
| zyga | noizer: I'm not sure I understand what you just said about git | 14:38 |
| zyga | noizer: if you can, please tell me about your devleopment setup | 14:39 |
| zyga | noizer: and about your needs for i2c and gpio | 14:39 |
| zyga | noizer: I can also show you how to run my branch to see if your snap will work with what I'm building | 14:39 |
| noizer | zyga Ok, I am making a device with many Sensors . On my OS there is Ubuntu Snappy with a snap that needs to connect with the gpio's of my raspberry pi | 14:41 |
| noizer | These sensors need to interact with some status leds | 14:42 |
| noizer | I know there needs to be I2C but for what. Thats now a mistery because my colleague knows that and is not at the office at the moment | 14:43 |
| noizer | Zyga maybe that we can talk in a private conversation how we can make this | 14:44 |
| longsleep | ricmm: Hey, did you ping me? | 14:56 |
| ogra_ | longsleep, yeah, he tried to run a spreed install behind a NAT ... and while we could see each others users we couldnt really establish a call | 14:57 |
| ogra_ | (i assume just opening 8443 wasnt enough) | 14:57 |
| longsleep | ogra_: well you need a TURN server somewhere outside | 14:57 |
| longsleep | or at least STUN | 14:57 |
| longsleep | so the peer to peer connections can work | 14:58 |
| ogra_ | well, it works fine doing it in my LAN | 14:58 |
| longsleep | yes peer to peer in LAN works | 14:58 |
| longsleep | but to bridge the NAT some external help is required | 14:58 |
| ogra_ | i assume P2P on two realy internet IPs too ... | 14:58 |
| ogra_ | *real | 14:58 |
| ogra_ | right ... but our usecase is LAN only anyway ... so we're fine | 14:59 |
| longsleep | the browsers have real internet addresses? | 14:59 |
| ogra_ | hah, no, the server does :P | 14:59 |
| ogra_ | anyway, we'Äll only use it in LAN setups anyway | 14:59 |
| ogra_ | so all is fine | 14:59 |
| longsleep | ok in LAN its easy. It depends on the firewall for the browsers if and what external help is needed. Most of the time STUN is good enough if the firewall allows UDP | 15:00 |
| longsleep | if not, a TURN server is required (which is essentially a proxy) where all peers connect to | 15:01 |
| longsleep | You could set this up easily on the server as well | 15:01 |
| ricmm | longsleep: how can I set one of these servers up? | 15:01 |
| ricmm | if I'd like to try | 15:02 |
| longsleep | ogra_: https://github.com/coturn/rfc5766-turn-server/ | 15:02 |
| longsleep | ricmm: ^^^ | 15:02 |
| ricmm | cool | 15:02 |
| longsleep | let me check if we have some instructions | 15:02 |
| ricmm | spreed exposes config to point it to the server? | 15:02 |
| ricmm | thanks | 15:02 |
| longsleep | might have a miss in the config hook | 15:02 |
| longsleep | but the server.conf has it | 15:02 |
| longsleep | ricmm: the repository for the TURN server moved here it seems: https://github.com/coturn/coturn | 15:03 |
| longsleep | for our public services we provide this (configured with shared secret authentication) | 15:03 |
| ricmm | got it | 15:04 |
| ricmm | ok, we'll keep demos to LAN only then | 15:04 |
| longsleep | ricmm: we have this ticket to get better docs how to set up TURN :) https://github.com/strukturag/spreed-webrtc/issues/199 | 15:04 |
| ricmm | if we run into issues at setup at least I know how to set one up ;) | 15:04 |
| longsleep | yeah - i can certainly also help if there are issues | 15:05 |
| longsleep | ricmm: we recommend 2 public IP addresses for the TURN server and at least one of the listeners to use port 443 | 15:06 |
| kyrofa | nessita, the name collisions apply to 15.04 as well? | 15:13 |
| kyrofa | (just got your email) | 15:14 |
| * zyga -> tea | 15:17 | |
| nessita | kyrofa, yeah, otherwise the store-side implementation gets super more complex and, as per my talk with martin, we prefer to apply this to 15.04 as well | 15:23 |
| kyrofa | nessita, ah okay. I ended up responding to that email, so sorry for the redundancy | 15:23 |
| kyrofa | zyga, I just built a new vanilla edge image, and ubuntu/ubuntu isn't letting me in. Any clues? | 15:38 |
| zyga | kyrofa: o_O? | 15:42 |
| zyga | kyrofa: any serial ports to see what's going on | 15:42 |
| zyga | kyrofa: does it boot | 15:42 |
| zyga | kyrofa: can you ping it | 15:42 |
| zyga | kyrofa: do you have a screen attached to it? | 15:43 |
| ogra_ | kyrofa, that happens if cloud-init didnt run properly | 15:43 |
| kyrofa | zyga, it's virtualbox. Yeah, it boots and I have the ability to login, it's just not accepted ubuntu/ubuntu as valid | 15:43 |
| kyrofa | zyga, ah, okay | 15:43 |
| kyrofa | zyga, I'll toast it and run again, see if I can spot any errors | 15:44 |
| zyga | kyrofa: man, why virtualbox | 15:44 |
| zyga | kyrofa: just use kvm | 15:44 |
| ogra_ | did you build it with u-d-f ? check if it was properly built actually | 15:44 |
| kyrofa | zyga, because you can't do both and I already have vbox machines | 15:44 |
| zyga | kyrofa: ah | 15:44 |
| kyrofa | zyga, long story :P | 15:44 |
| kyrofa | ogra_, yeah. How would I check that it was properly built? | 15:45 |
| ogra_ | first of all by seeing no errors during building :) | 15:45 |
| kyrofa | ogra_, ahh | 15:45 |
| kyrofa | ogra_, the uber-technical way | 15:45 |
| ogra_ | kpartx is a constant source of pain ... | 15:45 |
| ogra_ | (i cant build any all-snaps image on any of my trusty systems ... they all fall over when loop mounting for example) | 15:46 |
| ogra_ | (they still produce an image though ... but with only half the content) | 15:46 |
| kyrofa | ogra_, yeah I'm using a xenial VM. Can't make an image in an lxc container either... weird partition errors | 15:47 |
| ogra_ | yeah, needs an actual /dev for kpartx i guess | 15:47 |
| ogra_ | the worst part is that if you screwed that up once you *have* to reboot | 15:48 |
| ogra_ | and indeed my trusty machines run tons of scripts ... rebooting my desktop is 1h of work to get everything back in order | 15:48 |
| ogra_ | super annoying | 15:48 |
| kyrofa | ogra_, you would die with my flaky multi-monitor setup, then :P | 15:49 |
| kyrofa | ogra_, I have to reboot multiple times a day because my mouse pointer decides to go on vacation until I do | 15:49 |
| zyga | kyrofa: man, why do you use stuff like that | 15:50 |
| kyrofa | zyga, haha, two monitors? | 15:50 |
| zyga | no, stuff not working | 15:50 |
| * ogra_ has three on his desktop | 15:50 | |
| * zyga has one, and two children with their own computers now ^_^ | 15:50 | |
| ogra_ | but a proper nvidia card :) | 15:50 |
| zyga | ogra_: I was super surprised how stable amd has gotten lately | 15:51 |
| kyrofa | zyga, I'd love to solve those problems, but then I wouldn't get my job done | 15:51 |
| nessita | kyrofa, do you confirm I can remove your owncloud? | 15:51 |
| ogra_ | zyga, nah ... i like to play a game occasionally ... no more amd for me | 15:52 |
| zyga | ogra_: on windows or ubuntu? he uses xenial and plays games all day | 15:52 |
| zyga | ogra_: I have a wintendo for my games :( | 15:52 |
| kyrofa | nessita, sure. Though do you know the answer to my question? Who's in charge of that Canonical ownCloud snap? | 15:52 |
| ogra_ | i use trusty for playing | 15:52 |
| ogra_ | but i honestly didnt manage to play anything since november or so | 15:53 |
| zyga | ogra_: though I use ubuntu for playing casual games with my son :) | 15:53 |
| kyrofa | zyga, ogra_ huh, regenerated the image and it works fine | 16:04 |
| ogra_ | well, good then :) | 16:04 |
| nessita | kyrofa, you mean the owncloud from the canonical shared account? | 16:09 |
| kyrofa | nessita, yes | 16:09 |
| nessita | kyrofa, the account is generic, and I think many have access: snappy-canonical-storeaccount@canonical.com | 16:10 |
| nessita | kyrofa, I can't not identify an individual | 16:10 |
| nessita | kyrofa, is whoever can access that account in myapps | 16:10 |
| kyrofa | nessita, very good, thank you! | 16:10 |
| nessita | you are welcome! | 16:10 |
| zyga | kyrofa: magic | 16:11 |
| zyga | and I tell my children everything is rational | 16:11 |
| zyga | while we deal with magic all day | 16:11 |
| nessita | kyrofa, all reldeted! :-) | 16:15 |
| nessita | deleted* | 16:15 |
| === chihchun_afk is now known as chihchun | ||
| * zyga feels sleepy | 16:28 | |
| dholbach | elopio, is there anything blocking landing https://github.com/ubuntu-core/snapcraft/pull/318? | 16:37 |
| kyrofa | dholbach, I'm afraid he's out today and Monday | 16:39 |
| dholbach | oh ok, no worries | 16:39 |
| dholbach | thanks kyrofa | 16:39 |
| kyrofa | dholbach, it looks good, but since he's been looking at it I'd like to wait for him to review one last time | 16:39 |
| dholbach | right, makes sense | 16:40 |
| didrocks | balloons: all good on the Ubuntu Core front for gsoc? | 16:41 |
| balloons | didrocks, I think everything looks good. | 16:41 |
| didrocks | \o/ | 16:41 |
| didrocks | thanks :) | 16:41 |
| balloons | Thank you. We'll see what the students think soon enough :-) | 16:41 |
| didrocks | yeah! ;) | 16:43 |
| kyrofa | ogra_, what's with the dragonboard wifi driver and its handling of broadcasts? | 16:50 |
| ogra_ | kyrofa, working on that | 16:52 |
| tbr | kyrofa: there have been claims that it was fixed on the linaro side | 16:53 |
| tbr | kyrofa: it used to be horribly b0rken | 16:53 |
| tbr | one reason why my board is collecting dust | 16:53 |
| kyrofa | tbr, still seems kinda horribly broken :P | 16:53 |
| tbr | no doubt | 16:53 |
| tbr | the RE'd driver doesn't seem to be getting much love | 16:54 |
| kyrofa | ogra_, alright cool. I've been reading blog post after blog post about yucky workarounds, and not one person discussed fixing the thing. | 16:54 |
| tbr | linaro has other priorities | 16:54 |
| ogra_ | kyrofa, well, no idea yet how much the patch we have fixes it ... thanks to squashfs my turnaround time for doing tests did massively increase ... so its a very slow process now | 16:55 |
| kyrofa | ogra_, yeah I feel ya | 16:55 |
| kyrofa | ogra_, glad you're working on it though, thanks for your efforts :) | 16:55 |
| zyga | kyrofa: what is the issue? wonky driver? | 16:58 |
| ysionneau | allright I can now install my cross compiled .snap o/ | 16:59 |
| kyrofa | zyga, I assume so. It doesn't respond to ARP requests, so you can't reach it unless, say, it pings you first :P | 16:59 |
| zyga | ahhh | 16:59 |
| zyga | that explains some stuff :D | 16:59 |
| kyrofa | zyga, so people are writing startup scripts to nmap the entire network | 16:59 |
| zyga | well, non mainline kernel | 16:59 |
| zyga | could be worse | 17:00 |
| zyga | could be another blob | 17:00 |
| kyrofa | zyga, true enough | 17:00 |
| tbr | that only works in case of IPv4, IPv6 remains pretty much broken | 17:02 |
| kyrofa | tbr, ah, I hadn't thought of that | 17:02 |
| ogra_ | who uses that anyway :P | 17:02 |
| tbr | I've been complaining about this b0rkenness since last summer to the linaroooo people | 17:02 |
| kyrofa | ogra_, haha, my lack of knowledge of ipv6 is staggering | 17:02 |
| tbr | in the beginning they were blissfully unaware as everyone used usb-ethernet | 17:03 |
| zyga | tbr: https://xkcd.com/865/ | 17:03 |
| tbr | hehe | 17:04 |
| tbr | btw: if you urgently need it to work, you can probably just transplant the closed source module from the android images | 17:04 |
| ogra_ | heh, i'm working on an official image ... cant really do that :) | 17:05 |
| tbr | yeah, but someone else might not | 17:05 |
| tbr | the whole 96boards thing seems like dead on announcement anyway. there are two official boards, none of them compliant with official specifications. no enterprise boards. Meh, I'm starting to rant again. | 17:06 |
| ogra_ | tbr, i must admit i really like the dragonboard | 17:12 |
| tbr | ogra_: if you successfully ignore all the closed source boot-loaders that it requires, the missing software support for a lot of the hardware, ... | 17:13 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| sergiusens | jdstrand, snappy dimmension problem [jue feb 18 20:33:58 2016] audit: type=1400 audit(1455912316.447:48): apparmor="DENIED" operation="open" profile="shout.sergiusens_server_0.52.0-1" name="/run/resolvconf/resolv.conf" pid=13224 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 | 20:15 |
| sergiusens | Chipaca`, https://github.com/ubuntu-core/snapcraft/pull/328 | 20:16 |
| jdstrand | sergiusens: are you using the network-client cap? | 20:39 |
| sergiusens | jdstrand, I think I am; this works fine on ubuntu-core proper | 20:43 |
| sergiusens | jdstrand, it fails with the snappy dimmension on classic | 20:43 |
| jdstrand | sergiusens: can you file a bug with steps to reproduce? | 20:44 |
| sommar | Hi, have a quick snappy question. How can I oweride the : failed to install: Signature verification failed, at installation of a package? | 20:59 |
| sommar | I have seen som switches on a vid-clip on youtube, but cant remember it. | 21:00 |
| jdstrand | --allow-unauthenticated | 21:00 |
| sommar | Ahhh.. | 21:00 |
| sommar | Where can I find information about this switches? | 21:00 |
| sommar | Thanks.. | 21:00 |
| jdstrand | snappy install --help | 21:01 |
| jdstrand | there is also https://developer.ubuntu.com/en/snappy/ | 21:01 |
| jdstrand | I'm not sure if all of the switches are documented outside of the help system | 21:02 |
| sommar | I feeling a litlebit stupid, why dident i try that one (snappy install --help). | 21:03 |
| sommar | Thanks.. | 21:03 |
| sommar | I manage to install the package. | 21:03 |
| jdstrand | cool :) | 21:03 |
| jdstrand | np | 21:04 |
| jdstrand | and no need to feel stupid. this is a whole new system :) | 21:04 |
| qengho | I'm worried about differing behavior on identical runs of snapcraft. I can get an error message once, and run snapcraft again and get a different result. | 21:29 |
| qengho | It could be related to another problem I'm working on, I suppose. I'll solve other first. | 21:32 |
| qengho | Oh man. That's ugly. Found it. | 21:42 |
| qengho | So, should parts be used as a kind of flow-control between discrete stages of building one thing? download and unpack tarball, then configure source, then build source and package? | 22:23 |
| qengho | Or, are parts supposed to be discrete sources of code that are used to create a package? | 22:24 |
| qengho | I see a "copy" that makes me think the source of one part could be the output of another part. | 22:24 |
| qengho | :q | 22:33 |
| qengho | :q | 22:33 |
| === chihchun is now known as chihchun_afk | ||
| qengho | Ah, I guess they are all discrete units of code. Dang. | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!