| === tyhicks` is now known as tyhicks | ||
| === plars-off is now known as plars | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 08:06 |
|---|---|---|
| fgimenez | good morning | 08:09 |
| anpok | I continued toying around with a nfs server snap... now there is a library opening a config file in /etc/.. libtripc within rpcbind. The path is a compile time literal. Whats the right way to solve that? Is snappy doing something on startup to remap paths for each app? Should I change that to a relative path.. or use an env var? | 08:15 |
| asac | happy new year! | 08:49 |
| dholbach | asac: and the same to you! | 08:53 |
| * asac hugs dholbach | 08:54 | |
| * dholbach hugs asac | 08:54 | |
| === davmor2_ho-ho-ho is now known as davmor2 | ||
| JamesTait | Good morning all; happy Monday, happy New Year, and happy World Braille Day! 😃 | 09:25 |
| anpok | snappy new year! | 09:31 |
| === xnox_2016 is now known as xnox | ||
| asac | ubuntu@localhost:~$ snappy enable-classic | 10:21 |
| asac | 147.41 KB / 73.75 MB [______________________________________________________________________________] 0.20 % 367.10 KB/s 3m25s | 10:21 |
| asac | 73.75 MB / 73.75 MB [====================================================================================] 100.00 % 1.12 MB/s | 10:21 |
| asac | failed to create classic mode dir: mkdir /writable/classic: permission denied | 10:21 |
| asac | mvo: ? | 10:21 |
| asac | $ snappy list | 10:21 |
| asac | Name Date Version Developer | 10:21 |
| asac | canonical-linux-raspi2 2015-12-17 4.2.0-1014-3 canonical | 10:21 |
| asac | ubuntu-core-armhf 2015-12-21 16.04.0-4 canonical | 10:21 |
| asac | canonical-pi2 2015-12-17 2.2 canonical | 10:21 |
| asac | dont see an apparmor error for that... so guess just missing directory? | 10:22 |
| * asac mkdir /wrtable/classic and then retries | 10:22 | |
| asac | mvo: oh i think its bnecause i didnt use sudo | 10:24 |
| * asac retries another time | 10:24 | |
| asac | bah lp timeout when filing this as a bug :(\ | 10:27 |
| mvo | asac: yeah, sudo - but that is a bug in itself that it tries to do that even without uid=0 | 10:30 |
| asac | mvo: nexty problem ist hat i cant apt-get install in classic\ | 10:30 |
| asac | tried to snappy classic shell with sudo, but didnt work | 10:30 |
| asac | also when running snaoppy shell classic i end up with ubuntu user in the container | 10:31 |
| asac | mvo: https://bugs.launchpad.net/snappy/+bug/1530826 | 10:31 |
| ubottu | Launchpad bug 1530826 in Snappy "enable-classic should fail fast if not run with sudo/as root" [Undecided,New] | 10:31 |
| asac | bug one | 10:31 |
| asac | mvo: bug two: https://bugs.launchpad.net/snappy/+bug/1530827 | 10:33 |
| ubottu | Launchpad bug 1530827 in Snappy "cannot apt-get install in snappy shell classic" [Undecided,New] | 10:33 |
| mvo | asac: that seems to be something new in xenail I will debug | 10:36 |
| mvo | asac: releated to the new apt sandbox stuff | 10:36 |
| asac | mvo: what is apt sandbox | 10:40 |
| asac | ? | 10:40 |
| ogra_ | asac, apt has its own user now | 10:40 |
| ogra_ | (broke the images for a week :P ) | 10:40 |
| ogra_ | so it drops privs (abd does other stuff to operate more securely) | 10:41 |
| ogra_ | *and | 10:41 |
| mvo | asac: yeah, what ogra_ says. the idea is that if e..g there is a buffer overflow in the http downloader then the attacker does not get root right away | 10:42 |
| mvo | asac: on fixing the issues now (but may get interrupted by a lunch break soon :) | 10:45 |
| ogra_ | mvo, are you actually working already again ? | 10:46 |
| asac | mvo: so we got debian crack that broke everywhere? nice :P | 10:48 |
| ogra_ | it only broke snappy and touch due to the added user :) | 10:49 |
| mvo | ogra_: I think so, I need to check the calendar but I think I do :) | 10:50 |
| anpok | hm i guess there is no policy called network-servr | 10:50 |
| anpok | *server | 10:50 |
| mvo | ogra_: may take a day off during the week | 10:50 |
| mvo | asac: *cough* yeah | 10:50 |
| ogra_ | mvo, heh ... i'm still off til 16th ... but wanted to poke you with that pending u-d-f merge .... and snappy FTBFS on arm64 in xenial since a few weeks now | 10:51 |
| ogra_ | would be good if someone could handle that | 10:51 |
| mvo | ogra_: 16! woah :) | 10:52 |
| ogra_ | well, i had to burn vac. days and decided to actually burn some in advance this year :) | 10:52 |
| mvo | ogra_: u-d-f> I have a look, I think I need to spend some time on that one :/ | 10:52 |
| ogra_ | oh, why is that ? | 10:53 |
| mvo | ogra_: just because noone else is and the all-snap branch needs integration in there too | 10:53 |
| ogra_ | it applies, builds an runs fine for me | 10:53 |
| mvo | ogra_: oh, sorry, not specific to your diff, thats just a tiny part of it :) | 10:53 |
| ogra_ | i dont think it should be affected by all-snaps ... at least not beyond some preipherial bits | 10:53 |
| mvo | ogra_: thats good | 10:53 |
| mvo | ogra_: arm64> is it just a test failure? if you don't know from the top of your head don't worry, I check it out | 10:54 |
| ogra_ | i dont know, i just see the image build failure since a while, i didnt check the snappy build itself | 10:54 |
| * ogra_ sighs ...snow ... i thought i'd get away without shoveling this year | 10:55 | |
| mvo | asac: sorry for the apt trouble, I looked at this and you need to run "sudo apt update", this is a bug in apt that it does not tell you this. plus you probably can't use sudo in classic right now because the fix https://github.com/ubuntu-core/snappy/pull/266 is not merged yet :/ | 11:19 |
| pindonga | sergiusens, mvo jdstrand_ hi there... if I need to add a dependency to snapcraft for a feature I'm proposing, I also need to package that dependency as an ubuntu package right? | 12:17 |
| pindonga | but that would also mean having to introduce a PPA until the pkg is available in the main repos | 12:17 |
| pindonga | maybe there's a better alternative? | 12:17 |
| sergiusens | pindonga, you only want to target xenial for snapcraft 2.0 (if the question is about that) | 12:18 |
| sergiusens | pindonga, landing in xenial is pretty fast | 12:18 |
| pindonga | sergiusens, so the answer would be 1) yes, package deps for ubuntu (xenial), 2) yes, use main repos | 12:18 |
| pindonga | right? | 12:19 |
| sergiusens | pindonga, yeah, I was also suggesting no need to think about backporting | 12:19 |
| pindonga | ack | 12:19 |
| asac | mvo: no worries.... thanks! let me try | 12:40 |
| asac | so yeah, no sudo in classic (e.g. lack of sudoers) | 12:42 |
| ogra_ | ppisati, http://paste.ubuntu.com/14399210/ ... worjking dragonboard config with your branch ... it isnt merged with the std ubuntu one yet so a bit messy, but it makes all HW work fine | 12:47 |
| ogra_ | ppisati, it uses the apq8016-sbc.dtb DT | 12:48 |
| mvo | asac: yeah, this is fixed in the branch above, once that branch is merged it will be fine | 12:53 |
| asac | cool... waiting then | 12:54 |
| kyrofa | Good morning | 13:06 |
| kyrofa | Chipaca, so `snappy remove` doesn't remove any of the snap's data? | 13:29 |
| ppisati | ogra_: i've seen your email from december | 13:35 |
| ppisati | ogra_: the kernel with your config changes is building ATM | 13:35 |
| ppisati | ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+build/8800172 | 13:35 |
| ogra_ | ppisati, yeah, but i re-did a lot of that stuff since | 13:35 |
| ogra_ | cool ! | 13:35 |
| ppisati | ogra_: ah | 13:35 |
| ppisati | ogra_: did you change anything in the config? | 13:36 |
| ogra_ | initially i was using the wrong DT ... | 13:36 |
| ogra_ | a lot, yeah | 13:36 |
| ppisati | ogra_: oh ok, then i'll do anothe config diff and repush | 13:36 |
| ogra_ | effectively i went back to the 96boards one plus systemd and apparmor options | 13:36 |
| ppisati | ogra_: anyhow, i couldn't test this kernel | 13:37 |
| ogra_ | i.e. you will have to go over it and somehow merge it with the normal ubuntu config (not all USB modules, etc etc ... ) | 13:37 |
| ppisati | ogra_: cause i've a problem with your img | 13:37 |
| ogra_ | oh ? | 13:37 |
| ppisati | ogra_: it's weird, but after the first boot | 13:37 |
| ppisati | ogra_: my board refuses to boot subsequently from sd | 13:38 |
| ogra_ | you made sure it is a 4G card ? | 13:38 |
| ppisati | ogra_: 8G | 13:38 |
| ogra_ | ! | 13:38 |
| ogra_ | there is a reaadme next to the image :P | 13:38 |
| ogra_ | resizing is still broken, it wipes your GPT | 13:38 |
| ppisati | ogra_: fuck | 13:38 |
| ogra_ | you need a 4G card | 13:38 |
| ppisati | i haven't see that | 13:38 |
| ppisati | that explain it | 13:39 |
| ppisati | ok | 13:39 |
| ogra_ | yeah | 13:39 |
| * ppisati search for a 4G card then | 13:39 | |
| ogra_ | i might fix the resizing during my vacation :) | 13:39 |
| * ogra_ is still officially off til 16th | 13:39 | |
| ppisati | ogra_: no prob, i'll play with your img and my kernel | 13:40 |
| ppisati | ogra_: till it works fine | 13:40 |
| ogra_ | well, the current cnfig should work fine but surely has glitches (iirc it has preempt turned on and stuff) | 13:41 |
| ppisati | ogra_: the kernel compiling there, it's the same from december + the config diff you posted back then | 13:41 |
| ogra_ | i also havrnt looked at the firewall options, i think most are missing as well | 13:41 |
| ppisati | ogra_: i'll make sure eveyrhing is fine | 13:41 |
| ogra_ | yeah, i just used your source package ;) | 13:41 |
| ppisati | at least now i know why the img had that weird behaviour | 13:42 |
| ogra_ | yeah | 13:42 |
| ogra_ | note that you have to replace the wrongly named DTB when you change the kernel on it | 13:42 |
| ogra_ | uboot still points to the wrong name | 13:42 |
| ogra_ | (<ou need to copy apq8016-sbc.dtb over it) | 13:43 |
| ppisati | ok | 13:43 |
| ogra_ | oh, and with that kernel there is a bug with console blanking(havent checked if the 96boards kernel has it too) ... it doesnt wake up on keystroke | 13:44 |
| ogra_ | in case you plan to use the tty console :) | 13:44 |
| ppisati | ogra_: i even tried to install uboot on the boot partion on the internal flash | 13:45 |
| ppisati | ogra_: but i couldnt make the board boot in that case | 13:46 |
| sergiusens | kyrofa, morning | 13:46 |
| ppisati | lets' see if i can figure that out too | 13:46 |
| kyrofa | Hey sergiusens! | 13:46 |
| kyrofa | Good vacation? | 13:46 |
| sergiusens | kyrofa, you can tell from my absence here :-) | 13:46 |
| ogra_ | ppisati, well, you need to turn it into a boot.img first if you use the internal flash i think | 13:46 |
| kyrofa | sergiusens, haha :) | 13:47 |
| sergiusens | it was pretty good, really humid and rainy though, flooded cities everywhere | 13:47 |
| kyrofa | Ugh | 13:47 |
| kyrofa | Everyone save though? | 13:47 |
| ppisati | ogra_: i did that, my problem was that i couldn't boot the board | 13:47 |
| kyrofa | s/save/safe/ | 13:47 |
| asac | mvo: can i hack my classic stuff so that ubuntu is in sudoers maybe? | 13:47 |
| asac | would really love to unblock what i am really after: "get an armhf build env" | 13:48 |
| ppisati | ogra_: it was like, after kernel / dtb load and decompression, the board hung there | 13:48 |
| ogra_ | ppisati, like ... not at all ? i.e. not even messages from the SPL on the serial console ? | 13:48 |
| ppisati | ogra_: zero | 13:48 |
| sergiusens | kyrofa, mostly evacuated and the losses are only monetary; but it hasn't been without losses | 13:48 |
| ogra_ | ppisati, well, you should at least get the SBL messages, else you messed something up ... | 13:48 |
| ppisati | ogra_: i was following this, i guess you saw that too | 13:48 |
| ppisati | ogra_: http://rglinuxtech.com/?p=1606 | 13:49 |
| ppisati | ogra_: sorry | 13:49 |
| ppisati | ogra_: still sleepy :P | 13:49 |
| sergiusens | kyrofa, how was your time off? | 13:49 |
| kyrofa | sergiusens, I'm sorry :( | 13:49 |
| ppisati | ogra_: yes, i got a "complete boot" up to the point of loading kernel / dtb | 13:49 |
| ogra_ | ah | 13:49 |
| ppisati | ogra_: so uboot was live and 'working' | 13:49 |
| ogra_ | that was with your kernel back then ? | 13:49 |
| ppisati | ogra_: right, but even with the config change you pasted back then | 13:50 |
| ogra_ | oh | 13:50 |
| kyrofa | sergiusens, mine was nice, but a little tough-- my wife has been having some pretty good contractions and we're still over a month out. She's been more or less on bed rest | 13:50 |
| ogra_ | but you used the right dtb :) | 13:50 |
| ppisati | ogra_: right | 13:50 |
| ppisati | ogra_: apq- | 13:50 |
| ogra_ | my first config change only worked withteh wrong one | 13:50 |
| ppisati | ogra_: that might explain it | 13:51 |
| ogra_ | the pasteed config above now works with the right one :) | 13:51 |
| sergiusens | kyrofa, yeah, that can be tough | 13:51 |
| ppisati | ogra_: cool, i'll do config diff, recompile and reboot tests | 13:51 |
| sergiusens | kyrofa, I get you guys are getting pretty anxious due to that | 13:51 |
| kyrofa | sergiusens, yeah it's a bit stressful | 13:51 |
| ppisati | ogra_: it'll be ready for when you are back | 13:51 |
| ogra_ | :D | 13:52 |
| mvo | asac: yes, just do "sudo vi /writable/classic/etc/group" and add "ubuntu" to the "sudo" group | 13:55 |
| mvo | asac: and bribe someone to review my branch that fixes the issue :P | 13:56 |
| asac | mvo: i need your branch on top? | 14:00 |
| === chihchun is now known as chihchun_afk | ||
| mvo | asac: just that, then you should be fine | 14:05 |
| mvo | asac: the branch will do it automatically | 14:05 |
| sergiusens | kyrofa, elopio should we do a quick standup? | 14:33 |
| elopio | Hello everybody. | 14:33 |
| elopio | it's good to be back. | 14:33 |
| kyrofa | sergiusens, yeah | 14:33 |
| elopio | sergiusens: yes. | 14:33 |
| sergiusens | elopio, trading a natural jungle with a software one :-) | 14:33 |
| sergiusens | elopio, kyrofa I'm in | 14:33 |
| kyrofa | asac, how are those snapcraft PRs coming? I'd be happy to push them the rest of the way if you like | 14:56 |
| kyrofa | sergiusens, the ld.so.conf.d idea is really elegant. I'm wondering if we should perhaps do that throughout snapcraft rather than just the catkin plugin. Thoughts? | 15:02 |
| kyrofa | sergiusens, might save some pain for devs | 15:03 |
| kyrofa | elopio, ^^ | 15:04 |
| sergiusens | kyrofa, +1 on that | 15:18 |
| kyrofa | sergiusens, excellent :) | 15:18 |
| asac | kyrofa: could be that we can abandon them... let me try something | 15:24 |
| kyrofa | asac, alright let me know | 15:25 |
| asac | and hny! | 15:25 |
| asac | sergiusens: heya! can we ahve a default target back to be snap? | 15:26 |
| asac | on master | 15:26 |
| asac | utlemming: do you have xenial snappy all-snaps builds set up for aws, gcloud etc. yet? | 15:27 |
| asac | that would make my month :) | 15:27 |
| sergiusens | asac, we can, yes; I just need to make it clear in the spec. | 15:29 |
| asac | cool | 15:30 |
| asac | i think that would feel more natural than bailing out | 15:30 |
| asac | kyrofa: https://github.com/asac/etherpad-lite-snap/commit/e68ad2fd5ab2d75034c5fc32466c32eb380a0417 | 15:30 |
| kyrofa | asac, happy new year to you as well! | 15:30 |
| asac | that seems to work; entirely due to my lack of node knowledge | 15:30 |
| asac | i have to dobule check but for now assume its an abandon | 15:30 |
| kyrofa | asac, ah, interesting. And yeah, I can't help you on the node knowledge-- maybe sergiusens can? I think he made the plugin | 15:31 |
| asac | i think its fine as above | 15:31 |
| asac | and i wont need a new feature for node plugin this way | 15:31 |
| asac | just have to test the runtime package :) | 15:31 |
| kyrofa | asac, I'll go ahead and close them, then-- you can always reopen if you still want it :) | 15:31 |
| asac | will do thanks! | 15:32 |
| asac | if anyone wants to install http://people.canonical.com/~asac/etherpad-lite_master_amd64.snap and see if the pad is working on 9001 port after | 15:32 |
| asac | that would be cool | 15:32 |
| sergiusens | kyrofa, I am not a node expert, only looked at it for one day and came up with a simple hand written app and an existing popular one :-) | 15:32 |
| asac | i only have my new "production" etherpad snappy instance | 15:33 |
| sergiusens | asac, if you need node help, beowulf is the guy we want to talk to | 15:33 |
| kyrofa | sergiusens, heh | 15:33 |
| sergiusens | asac, is that snap built with snapcraft? | 15:33 |
| asac | sergiusens: of course | 15:34 |
| sergiusens | asac, nice! | 15:34 |
| asac | with the branch above | 15:34 |
| asac | https://github.com/asac/etherpad-lite-snap/ | 15:34 |
| * beowulf looks to see what kind of bus sergiusens has thrown him under | 15:34 | |
| asac | is legacy already though, because the real variant moved it into real tree | 15:34 |
| asac | https://github.com/asac/etherpad-lite | 15:34 |
| asac | e.g. in tree snapcraft | 15:35 |
| asac | vs. out of tree snapcraft which is the -snap repo above | 15:35 |
| asac | will hack on awesome config support today | 15:35 |
| kyrofa | Haha, hey beowulf | 15:35 |
| asac | https://github.com/asac/etherpad-lite/tree/snap-support/bin/snappy | 15:35 |
| asac | thats the in-tree snapcraft | 15:36 |
| beowulf | o/ kyrofa | 15:36 |
| kyrofa | beowulf, it's been a while! What are you working on nowadays? | 15:36 |
| asac | would love to consolidate the README to just have "snapcraft" for both 1.x and 2.x | 15:36 |
| beowulf | kyrofa: i'd like to say i work on the store, but it's more like the store works on me | 15:37 |
| === chihchun_afk is now known as chihchun | ||
| kyrofa | beowulf, :D | 15:37 |
| === josepht` is now known as josepht | ||
| elopio | ping plars. Are you working today? | 16:15 |
| plars | elopio: yes, Happy New Year :) | 16:15 |
| plars | elopio: what's up? | 16:16 |
| elopio | plars: same to you! | 16:16 |
| elopio | plars: we are wondering about making an ubuntu-device-flash specific for 16.04. That would mean that you need xenial to build new images, and an older distro to generate 15.04 images. | 16:17 |
| elopio | plars: could you get two agents working, one for new and one for old images? | 16:17 |
| plars | elopio: no, it's not really possible to have two different agents coordinating the same device | 16:18 |
| plars | elopio: it may be possible to somehow give a hint to how it's built, but it couldn't be on two different agents. Wouldn't it be possible to just have two different ubuntu-device-flash binaries? Why does the whole distro it's built on need to be different? | 16:19 |
| elopio | plars: well, there are many options, I just thought two builders was the easiest. The u-d-f from xenial will build 16.04, the u-d-f from the other distros will build 15.04. If you can install both on the same agent, and tell me how to choose, I think that works too. | 16:21 |
| plars | elopio: so it's just a different binary then, the whole distro you are building the image on does not need to be updated correct? | 16:22 |
| plars | a different udf binary that is | 16:23 |
| elopio | plars: afaik, yes. sergiusens: right? | 16:24 |
| plars | elopio: do you know if there's any plan to add backward compatibility support? | 16:24 |
| elopio | plars: that's what we want to avoid. | 16:24 |
| plars | elopio: There are a few different approaches we could take, either way you'll definitely want to set up a new "image" in spi (since it is a new image) | 16:25 |
| plars | elopio: for that image, you'll need to tell it to use the new udf binary to build the image, not the default one | 16:25 |
| elopio | plars: sure. So what remains is to see if we can have both installed in the same machine. | 16:26 |
| sergiusens | elopio, I don't know, that is a mvo question, but I am thinking that there is a dependency on using 16.04 for the new stuff | 16:29 |
| plars | elopio: this will require some rethinking of how the agents work too I'm afraid... we never anticipated needing multiple versions of UDF, rather it was assumed that we want to carefully control the version of udf installed and make sure it's updated only when needed | 16:29 |
| plars | elopio: so as a result, you specify the options to udf, rather than a script to just go get whatever version of udf you want (like you do with the tests) and run it | 16:30 |
| plars | sergiusens: dependency on using 16.04? or a dependency on using 16.04 version of udf? And can that version also build 15.04 based images? | 16:30 |
| elopio | plars: worst case scenario, we'll want the agents to be xenial. And fgimenez and I can run the 15.04 tests manually on our homemade labs :p | 16:30 |
| noise][ | elopio: wasn't there some talk about u-d-f becoming ubuntu-image + ubuntu-flash as 2 new separate binaries for 16.04? | 16:30 |
| plars | elopio: it may not be so simple... what about others that may want to test 15.04 images? | 16:31 |
| elopio | noise][: yup. We are planning the transition for that. | 16:31 |
| plars | elopio: hopefully there's some transition path for all of this? Otherwise everything will just be broken for a while | 16:31 |
| plars | elopio: of course, for bbb, I think we're still down because of that bug right? | 16:32 |
| noise][ | if that were the case, couldn't the existing 15.04 compat. u-d-f still be packaged for xenial alongside the 16.04 split ones? | 16:32 |
| sergiusens | noise][, u-d-f can still be there in xenial; but the new ubuntu-image will only build with all snaps in mind | 16:33 |
| elopio | noise][: maybe. So far I'm just asking the questions to see what are the requirements for the transition. | 16:33 |
| elopio | I'm ok with a little downtime, if that speeds up the transition to all-snaps. | 16:33 |
| elopio | Also we want to avoid having u-d-f generating 15.04 and 16.04 images. | 16:33 |
| anpok | Jan 4 16:33:03 localhost systemd[1]: Cannot add dependency job for unit ubuntu-snappy.snapd.socket, ignoring: Unit ubuntu-snappy.snapd.socket failed to load: No such file or directory. | 16:34 |
| anpok | ^ something I should care about? | 16:34 |
| plars | elopio: so it's a whole new command - ubuntu-image, that will be used? | 16:38 |
| plars | elopio: is there any documentation about this? | 16:38 |
| elopio | plars: that's the final solution, yes. While that command is ready, we need to support building new images. | 16:39 |
| plars | elopio: it would be a little weird to run these agent hosts on xenial I think, is there no plan to build a trusty version of the new ubuntu-image binary? | 16:40 |
| plars | elopio: it's still not clear to me if the build host *must* run xenial, or if it just needs the new binary | 16:40 |
| elopio | plars: we want to avoid that. We want to have people writing things for xenial to be using xenial. | 16:40 |
| plars | elopio: but we're not developing anything on that system, just building an image | 16:41 |
| plars | elopio: In either case, I think we'll need to extend the json you pass for spi to support a new field for using ubuntu-image vs. udf | 16:42 |
| elopio | plars: again, right now I'm just asking for requirements. If we can completely ignore trusty, that would be easier for sure. | 16:42 |
| plars | elopio: then once all 15.04 images are deprecated, we can just kill the previous stuff | 16:42 |
| plars | elopio: I think in the near future though, we have to support both | 16:43 |
| kyrofa | Chipaca, ping | 16:45 |
| kyrofa | Chipaca, I'm having trouble merging my understanding of snappy with my understanding of this purge code :P | 16:46 |
| kyrofa | Chipaca, specifically, if DataDirs returns multiple results, Purge seems to try and deactivate the snap more than once, resulting in an error after the first deactivation since it was already deactivated | 16:47 |
| kyrofa | Chipaca, I thought that was a common scenario? | 16:48 |
| === chihchun is now known as chihchun_afk | ||
| kyrofa | Chipaca, trying to fix https://github.com/ubuntu-core/snappy/pull/264 by the way | 16:58 |
| kyrofa | sergiusens, any chance you know what I'm talking about? | 16:59 |
| Chipaca | kyrofa: sorry, hadn't brought irc up yet. am here now. | 17:07 |
| Chipaca | reading backlog | 17:07 |
| kyrofa | Chipaca, ah, no problem :) | 17:07 |
| Chipaca | kyrofa: so, correct, `snappy remove` leaves data in place | 17:08 |
| kyrofa | Chipaca, makes sense given how apt-get works | 17:08 |
| kyrofa | Chipaca, or dpkg I guess | 17:08 |
| Chipaca | kyrofa: yeap, which is why it's this way, but it is surprising if you don't come from apt, so it'll change for 16.04 to be less so | 17:09 |
| Chipaca | kyrofa: oh dear, you are correct in that the use of datadirs is buggy :-( | 17:09 |
| Chipaca | hmm | 17:10 |
| kyrofa | Chipaca, oh *whew* that's better than me being incredibly confused :P | 17:10 |
| Chipaca | :-) | 17:10 |
| Chipaca | well, users might disagree with you on that =) | 17:10 |
| kyrofa | Hahaha | 17:10 |
| kyrofa | Chipaca, well I've got fixed (i.e. failing) tests anyway | 17:11 |
| Chipaca | hmm | 17:11 |
| kyrofa | Chipaca, I can make a PR to fix it before fixing #264 | 17:11 |
| Chipaca | on the other hand, maybe not | 17:11 |
| Chipaca | ah! yes because it'll do deactivate in the second path | 17:12 |
| Chipaca | bah humbug :-( | 17:12 |
| Chipaca | kyrofa: +1 | 17:12 |
| Chipaca | kyrofa: things current code doesn't consider is a snap using both data dir and user data dir, and multiple users | 17:12 |
| Chipaca | kyrofa: both would fail in similar ways | 17:12 |
| kyrofa | Chipaca, ah, indeed | 17:13 |
| Chipaca | kyrofa: in both cases moving deactivate to inside the first loop would solve it i think? | 17:13 |
| kyrofa | Chipaca, what was the purpose of looping through the data dirs in the first place? Is there a use-case I'm missing? | 17:13 |
| Chipaca | kyrofa: as opposed to what? | 17:13 |
| kyrofa | Chipaca, ah, it was for multiple VERSIONS | 17:13 |
| kyrofa | Chipaca, yes? | 17:13 |
| Chipaca | ah, yes | 17:14 |
| kyrofa | Chipaca, okay, I'll point you to the PR when I make it, if that's alright | 17:14 |
| Chipaca | kyrofa: that would be very alright | 17:15 |
| Chipaca | kyrofa: going back on this a bit, depending on the size of the change, maybe moving it to pkg/lightweight is better | 17:33 |
| kyrofa | Chipaca, ah, I've never looked at that package | 17:35 |
| Chipaca | kyrofa: they're both my fault, but datadirs is rather adhoc for the purge command, whereas lightweights is an iteration of the idea made more generally useful (only i didn't get around to removing datadirs) | 17:36 |
| kyrofa | Chipaca, I don't think the change is large, but it sounds like a refactor that should happen at least eventually. Would you like me to do that here? | 17:37 |
| Chipaca | kyrofa: as the whole purge command is going away, probably not worth it unless fixing datadirs is big | 17:38 |
| kyrofa | Chipaca, I think not. But I'll keep it in mind just in case | 17:38 |
| * Chipaca nods | 17:38 | |
| kyrofa | Chipaca, https://github.com/ubuntu-core/snappy/pull/283 | 18:27 |
| sergiusens | kyrofa, so should we do a 1.x today? | 19:47 |
| kyrofa | sergiusens, we can, but this ld.so.conf.d feature will need to get into 1.x as well. I'm fine with waiting on it or releasing twice-- up to you | 19:49 |
| kyrofa | sergiusens, but I know we've been wanting to get that out | 19:49 |
| sergiusens | kyrofa, depends on how long it will take, I don't want to delay too much ;-) | 19:50 |
| sergiusens | kyrofa, also, do the docs need more work or can they merge? | 19:50 |
| kyrofa | sergiusens, agreed. How about we wait until tomorrow. If it's not done and looking good, we'll release | 19:51 |
| kyrofa | sergiusens, ah, let me look them over again now | 19:51 |
| sergiusens | kyrofa, yeah, releasing on wednesday is fine by me | 19:51 |
| sergiusens | kyrofa, it would be nice to get the qml fix backported too | 19:51 |
| kyrofa | sergiusens, agreed. I didn't see a response on that, so I can cherry pick | 19:52 |
| sergiusens | kyrofa, is it CLA worthy? A single cherry requires squashing though iirc | 19:52 |
| kyrofa | sergiusens, the qml fix guy did sign the CLA | 19:53 |
| sergiusens | great | 19:56 |
| brei | is it possible to define an unpack path for the tar_content.py plugin? | 20:31 |
| kyrofa | sergiusens, the ld.so.conf idea may not actually work. At least from what I've seen so far, those files are placed in the .deb postinst, which doesn't seem to have an effect since we're really only unpacking them | 21:01 |
| sergiusens | kyrofa, oh bummer | 21:07 |
| kyrofa | sergiusens, yeah it's sad... it was such a good idea | 21:07 |
| sergiusens | kyrofa, I can't think of another way that can reliably work for all cases | 21:08 |
| kyrofa | sergiusens, I want all that stuff to be done in some sort of temporary lxc so the packages can actually be installed or something | 21:08 |
| sergiusens | kyrofa, we should only focus on lxc for 2.x | 21:12 |
| sergiusens | kyrofa, I'd say, send some sort of proposal to the devel list to see what comes | 21:12 |
| kyrofa | sergiusens, alright... I guess I'll scrap this idea for 1.x then, unless you think walking /lib and /usr/lib and adding them all to LD_LIBRARY_PATH is an acceptable backup plan | 21:13 |
| sergiusens | kyrofa, what about things in /opt' and such? | 21:13 |
| sergiusens | it sort of gets some things working, but not all | 21:14 |
| kyrofa | sergiusens, yeah, it doesn't work in all cases, but it works better than what we have now | 21:14 |
| kyrofa | Exactly :P | 21:14 |
| sergiusens | kyrofa, can we use rpath with relative paths? | 21:14 |
| sergiusens | probably not a good solution either | 21:14 |
| kyrofa | sergiusens, I think you can with some special keywords, but it's been a long time since I played with that | 21:17 |
| kyrofa | sergiusens, yeah... I'm not a huge fan of either. Do we like one better than the other, or stick the .snap author with making wrappers every time they have a lib outside of the standard? | 21:18 |
| sergiusens | kyrofa, the general consensus was that most of this is a project specific problem | 21:19 |
| kyrofa | sergiusens, which makes a certain amount of sense, but also can mean a nightmare for someone just trying to package something with a lot of .deb dependencies | 21:20 |
| sergiusens | kyrofa, personally, snapcraft magic voodoo should only be done when there's something we can hold on to | 21:20 |
| kyrofa | sergiusens, yeah, you're right | 21:21 |
| sergiusens | kyrofa, there's nothing reliable we can use here | 21:21 |
| sergiusens | too bad those ld things are postinst :-( | 21:21 |
| sergiusens | I thought they'd be config files at most | 21:21 |
| kyrofa | sergiusens, agreed. Let's scrap the idea and revisit if we ever get some sort of contained build | 21:21 |
| kyrofa | sergiusens, they are, but they're symlinked in | 21:22 |
| sergiusens | kyrofa, is there any specific path that is already blocking something? | 21:22 |
| kyrofa | sergiusens, I ran into it making a ROS .snap that uses opencv, which relies on opengl, which is in /usr/lib/arch/mesa | 21:23 |
| sergiusens | kyrofa, for the case of mesa/egl/gl, right? | 21:23 |
| kyrofa | sergiusens, right | 21:23 |
| sergiusens | kyrofa, those are sufficiently common I guess to be able to track and check for | 21:23 |
| kyrofa | sergiusens, I can at the very least add it to the catkin env(). Want me to add them to the overall runtime_env()? | 21:24 |
| sergiusens | kyrofa, overall is fine | 21:26 |
| sergiusens | kyrofa, I wonder if this is a pattern ''/etc/alternatives/.*_conf | 21:27 |
| sergiusens | something we can check for | 21:27 |
| kyrofa | sergiusens, in the case I'm looking at, the real .conf is distributed within /usr/lib/arch/mesa, and the postinst installs it with update-alternatives | 21:31 |
| kyrofa | So yes.... but no | 21:31 |
| kyrofa | Because in that case, even the etc/alternatives is a symlink | 21:31 |
| sergiusens | kyrofa, ah/usr/lib/x86_64-linux-gnu/mesa-egl/ld.so.conf | 21:32 |
| kyrofa | sergiusens, right | 21:32 |
| kyrofa | Stupid chicken and egg problems... | 21:33 |
| sergiusens | kyrofa, the other option is to search for ld.so.conf files | 21:33 |
| sergiusens | but that can be dangerous too | 21:33 |
| kyrofa | sergiusens, I assume that name is nonstandard | 21:33 |
| sergiusens | kyrofa, exactly | 21:34 |
| sergiusens | kyrofa, so maybe search for those specific egl ones and read them through | 21:34 |
| sergiusens | kyrofa, we'll need to figure out what nvidia does as well | 21:34 |
| sergiusens | gl is sort of an important topic | 21:34 |
| sergiusens | ah, nvidia is mostly a runtime thing, disregard me | 21:35 |
| kyrofa | sergiusens, alright, I can do that | 21:36 |
| sergiusens | kyrofa, elopio is this just me with a new pep? http://paste.ubuntu.com/14404846/ | 22:11 |
| sergiusens | easy fix, just want to know how it got through :-) | 22:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!