=== tyhicks` is now known as tyhicks
=== plars-off is now known as plars
=== chihchun_afk is now known as chihchun
dholbachgood morning08:06
fgimenezgood morning08:09
anpokI 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
asachappy new year!08:49
dholbachasac: and the same to you!08:53
* asac hugs dholbach 08:54
* dholbach hugs asac08:54
=== davmor2_ho-ho-ho is now known as davmor2
JamesTaitGood morning all; happy Monday, happy New Year, and happy World Braille Day! 😃09:25
anpoksnappy new year!09:31
=== xnox_2016 is now known as xnox
asacubuntu@localhost:~$ snappy enable-classic10:21
asac147.41 KB / 73.75 MB [______________________________________________________________________________] 0.20 % 367.10 KB/s 3m25s10:21
asac73.75 MB / 73.75 MB [====================================================================================] 100.00 % 1.12 MB/s10:21
asacfailed to create classic mode dir: mkdir /writable/classic: permission denied10:21
asacmvo: ?10:21
asac$ snappy list10:21
asacName                   Date       Version      Developer10:21
asaccanonical-linux-raspi2 2015-12-17 4.2.0-1014-3 canonical10:21
asacubuntu-core-armhf      2015-12-21 16.04.0-4    canonical10:21
asaccanonical-pi2          2015-12-17 2.2          canonical10:21
asacdont see an apparmor error for that... so guess just missing directory?10:22
* asac mkdir /wrtable/classic and then retries10:22
asacmvo: oh i think its bnecause i didnt use sudo10:24
* asac retries another time10:24
asacbah lp timeout when filing this as a bug :(\10:27
mvoasac: yeah, sudo - but that is a bug in itself that it tries to do that even without uid=010:30
asacmvo: nexty problem ist hat i cant apt-get install in classic\10:30
asactried to snappy classic shell with sudo, but didnt work10:30
asacalso when running snaoppy shell classic i end up with ubuntu user in the container10:31
asacmvo: https://bugs.launchpad.net/snappy/+bug/153082610:31
ubottuLaunchpad bug 1530826 in Snappy "enable-classic should fail fast if not run with sudo/as root" [Undecided,New]10:31
asacbug one10:31
asacmvo: bug two: https://bugs.launchpad.net/snappy/+bug/153082710:33
ubottuLaunchpad bug 1530827 in Snappy "cannot apt-get install in snappy shell classic" [Undecided,New]10:33
mvoasac: that seems to be something new in xenail I will debug10:36
mvoasac: releated to the new apt sandbox stuff10:36
asacmvo: what is apt sandbox10:40
ogra_asac, apt has its own user now10: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
mvoasac: 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 away10:42
mvoasac: 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
asacmvo: so we got debian crack that broke everywhere? nice :P10:48
ogra_it only broke snappy and touch due to the added user :)10:49
mvoogra_: I think so, I need to check the calendar but I think I do :)10:50
anpokhm i guess there is no policy called network-servr10:50
mvoogra_: may take a day off during the week10:50
mvoasac: *cough* yeah10: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 now10:51
ogra_would be good if someone could handle that10:51
mvoogra_: 16! woah :)10:52
ogra_well, i had to burn vac. days and decided to actually burn some in advance this year :)10:52
mvoogra_: 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
mvoogra_: just because noone else is and the all-snap branch needs integration in there too10:53
ogra_it applies, builds an runs fine for me10:53
mvoogra_: 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 bits10:53
mvoogra_: thats good10:53
mvoogra_: arm64> is it just a test failure? if you don't know from the top of your head don't worry, I check it out10:54
ogra_i dont know, i just see the image build failure since a while, i didnt check the snappy build itself10:54
* ogra_ sighs ...snow ... i thought i'd get away without shoveling this year10:55
mvoasac: 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
pindongasergiusens, 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
pindongabut that would also mean having to introduce a PPA until the pkg is available in the main repos12:17
pindongamaybe there's a better alternative?12:17
sergiusenspindonga, you only want to target xenial for snapcraft 2.0 (if the question is about that)12:18
sergiusenspindonga, landing in xenial is pretty fast12:18
pindongasergiusens, so the answer would be 1) yes, package deps for ubuntu (xenial), 2) yes, use main repos12:18
sergiusenspindonga, yeah, I was also suggesting no need to think about backporting12:19
asacmvo: no worries.... thanks! let me try12:40
asacso 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 fine12:47
ogra_ppisati, it uses the apq8016-sbc.dtb DT12:48
mvoasac: yeah, this is fixed in the branch above, once that branch is merged it will be fine12:53
asaccool... waiting then12:54
kyrofaGood morning13:06
kyrofaChipaca, so `snappy remove` doesn't remove any of the snap's data?13:29
ppisatiogra_: i've seen your email from december13:35
ppisatiogra_: the kernel with your config changes is building ATM13:35
ppisatiogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+build/880017213:35
ogra_ppisati, yeah, but i re-did a lot of that stuff since13:35
ogra_cool !13:35
ppisatiogra_: ah13:35
ppisatiogra_: did you change anything in the config?13:36
ogra_initially i was using the wrong DT ...13:36
ogra_a lot, yeah13:36
ppisatiogra_: oh ok, then i'll do anothe config diff and repush13:36
ogra_effectively i went back to the 96boards one plus systemd and apparmor options13:36
ppisatiogra_: anyhow, i couldn't test this kernel13: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
ppisatiogra_: cause i've a problem with your img13:37
ogra_oh ?13:37
ppisatiogra_: it's weird, but after the first boot13:37
ppisatiogra_: my board refuses to boot subsequently from sd13:38
ogra_you made sure it is a 4G card ?13:38
ppisatiogra_: 8G13:38
ogra_there is a reaadme next to the image :P13:38
ogra_resizing is still broken, it wipes your GPT13:38
ppisatiogra_: fuck13:38
ogra_you need a 4G card13:38
ppisatii haven't see that13:38
ppisatithat explain it13:39
* ppisati search for a 4G card then13:39
ogra_i might fix the resizing during my vacation :)13:39
* ogra_ is still officially off til 16th13:39
ppisatiogra_: no prob, i'll play with your img and my kernel13:40
ppisatiogra_: till it works fine13:40
ogra_well, the current cnfig should work fine but surely has glitches (iirc it has preempt turned on and stuff)13:41
ppisatiogra_: the kernel compiling there, it's the same from december + the config diff you posted back then13:41
ogra_i also havrnt looked at the firewall options, i think most are missing as well13:41
ppisatiogra_: i'll make sure eveyrhing is fine13:41
ogra_yeah, i just used your source package ;)13:41
ppisatiat least now i know why the img had that weird behaviour13:42
ogra_note that you have to replace the wrongly named DTB when you change the kernel on it13:42
ogra_uboot still points to the wrong name13:42
ogra_(<ou need to copy apq8016-sbc.dtb over it)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 keystroke13:44
ogra_in case you plan to use the tty console :)13:44
ppisatiogra_: i even tried to install uboot on the boot partion on the internal flash13:45
ppisatiogra_: but i couldnt make the board boot in that case13:46
sergiusenskyrofa, morning13:46
ppisatilets' see if i can figure that out too13:46
kyrofaHey sergiusens!13:46
kyrofaGood vacation?13:46
sergiusenskyrofa, 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 think13:46
kyrofasergiusens, haha :)13:47
sergiusensit was pretty good, really humid and rainy though, flooded cities everywhere13:47
kyrofaEveryone save though?13:47
ppisatiogra_: i did that, my problem was that i couldn't boot the board13:47
asacmvo: can i hack my classic stuff so that ubuntu is in sudoers maybe?13:47
asacwould really love to unblock what i am really after: "get an armhf build env"13:48
ppisatiogra_: it was like, after kernel / dtb load and decompression, the board hung there13:48
ogra_ppisati, like ... not at all ? i.e. not even messages from the SPL on the serial console ?13:48
ppisatiogra_: zero13:48
sergiusenskyrofa, mostly evacuated and the losses are only monetary; but it hasn't been without losses13:48
ogra_ppisati, well, you should at least get the SBL messages, else you messed something up ...13:48
ppisatiogra_: i was following this, i guess you saw that too13:48
ppisatiogra_: http://rglinuxtech.com/?p=160613:49
ppisatiogra_: sorry13:49
ppisatiogra_: still sleepy :P13:49
sergiusenskyrofa, how was your time off?13:49
kyrofasergiusens, I'm sorry :(13:49
ppisatiogra_: yes, i got a "complete boot" up to the point of loading kernel / dtb13:49
ppisatiogra_: so uboot was live and 'working'13:49
ogra_that was with your kernel back then ?13:49
ppisatiogra_: right, but even with the config change you pasted back then13:50
kyrofasergiusens, 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 rest13:50
ogra_but you used the right dtb :)13:50
ppisatiogra_: right13:50
ppisatiogra_: apq-13:50
ogra_my first config change only worked withteh wrong one13:50
ppisatiogra_: that might explain it13:51
ogra_the pasteed config above now works with the right one :)13:51
sergiusenskyrofa, yeah, that can be tough13:51
ppisatiogra_: cool, i'll do config diff, recompile and reboot tests13:51
sergiusenskyrofa, I get you guys are getting pretty anxious due to that13:51
kyrofasergiusens, yeah it's a bit stressful13:51
ppisatiogra_: it'll be ready for when you are back13:51
mvoasac: yes, just do "sudo vi /writable/classic/etc/group" and add "ubuntu" to the "sudo" group13:55
mvoasac: and bribe someone to review my branch that fixes the issue :P13:56
asacmvo: i need your branch on top?14:00
=== chihchun is now known as chihchun_afk
mvoasac: just that, then you should be fine14:05
mvoasac: the branch will do it automatically14:05
sergiusenskyrofa, elopio should we do a quick standup?14:33
elopioHello everybody.14:33
elopioit's good to be back.14:33
kyrofasergiusens, yeah14:33
elopiosergiusens: yes.14:33
sergiusenselopio, trading a natural jungle with a software one :-)14:33
sergiusenselopio, kyrofa I'm in14:33
kyrofaasac, how are those snapcraft PRs coming? I'd be happy to push them the rest of the way if you like14:56
kyrofasergiusens, 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
kyrofasergiusens, might save some pain for devs15:03
kyrofaelopio, ^^15:04
sergiusenskyrofa, +1 on that15:18
kyrofasergiusens, excellent :)15:18
asackyrofa: could be that we can abandon them... let me try something15:24
kyrofaasac, alright let me know15:25
asacand hny!15:25
asacsergiusens: heya! can we ahve a default target back to be snap?15:26
asacon master15:26
asacutlemming: do you have xenial snappy all-snaps builds set up for aws, gcloud etc. yet?15:27
asacthat would make my month :)15:27
sergiusensasac, we can, yes; I just need to make it clear in the spec.15:29
asaci think that would feel more natural than bailing out15:30
asackyrofa: https://github.com/asac/etherpad-lite-snap/commit/e68ad2fd5ab2d75034c5fc32466c32eb380a041715:30
kyrofaasac, happy new year to you as well!15:30
asacthat seems to work; entirely due to my lack of node knowledge15:30
asaci have to dobule check but for now assume its an abandon15:30
kyrofaasac, ah, interesting. And yeah, I can't help you on the node knowledge-- maybe sergiusens can? I think he made the plugin15:31
asaci think its fine as above15:31
asacand i wont need a new feature for node plugin this way15:31
asacjust have to test the runtime package :)15:31
kyrofaasac, I'll go ahead and close them, then-- you can always reopen if you still want it :)15:31
asacwill do thanks!15:32
asacif anyone wants to install http://people.canonical.com/~asac/etherpad-lite_master_amd64.snap and see if the pad is working on 9001 port after15:32
asacthat would be cool15:32
sergiusenskyrofa, 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
asaci only have my new "production" etherpad snappy instance15:33
sergiusensasac, if you need node help, beowulf is the guy we want to talk to15:33
kyrofasergiusens, heh15:33
sergiusensasac, is that snap built with snapcraft?15:33
asacsergiusens: of course15:34
sergiusensasac, nice!15:34
asacwith the branch above15:34
* beowulf looks to see what kind of bus sergiusens has thrown him under15:34
asacis legacy already though, because the real variant moved it into real tree15:34
asace.g. in tree snapcraft15:35
asacvs. out of tree snapcraft which is the -snap repo above15:35
asacwill hack on awesome config support today15:35
kyrofaHaha, hey beowulf15:35
asacthats the in-tree snapcraft15:36
beowulfo/ kyrofa15:36
kyrofabeowulf, it's been a while! What are you working on nowadays?15:36
asacwould love to consolidate the README to just have "snapcraft" for both 1.x and 2.x15:36
beowulfkyrofa: i'd like to say i work on the store, but it's more like the store works on me15:37
=== chihchun_afk is now known as chihchun
kyrofabeowulf, :D15:37
=== josepht` is now known as josepht
elopioping plars. Are you working today?16:15
plarselopio: yes, Happy New Year :)16:15
plarselopio: what's up?16:16
elopioplars: same to you!16:16
elopioplars: 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
elopioplars: could you get two agents working, one for new and one for old images?16:17
plarselopio: no, it's not really possible to have two different agents coordinating the same device16:18
plarselopio: 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
elopioplars: 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
plarselopio: 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
plarsa different udf binary that is16:23
elopioplars: afaik, yes. sergiusens: right?16:24
plarselopio: do you know if there's any plan to add backward compatibility support?16:24
elopioplars: that's what we want to avoid.16:24
plarselopio: 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
plarselopio: for that image, you'll need to tell it to use the new udf binary to build the image, not the default one16:25
elopioplars: sure. So what remains is to see if we can have both installed in the same machine.16:26
sergiusenselopio, 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 stuff16:29
plarselopio: 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 needed16:29
plarselopio: 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 it16:30
plarssergiusens: 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
elopioplars: 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 :p16: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
plarselopio: it may not be so simple... what about others that may want to test 15.04 images?16:31
elopionoise][: yup. We are planning the transition for that.16:31
plarselopio: hopefully there's some transition path for all of this? Otherwise everything will just be broken for a while16:31
plarselopio: 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
sergiusensnoise][, u-d-f can still be there in xenial; but the new ubuntu-image will only build with all snaps in mind16:33
elopionoise][: maybe. So far I'm just asking the questions to see what are the requirements for the transition.16:33
elopioI'm ok with a little downtime, if that speeds up the transition to all-snaps.16:33
elopioAlso we want to avoid having u-d-f generating 15.04 and 16.04 images.16:33
anpokJan  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
plarselopio: so it's a whole new command - ubuntu-image, that will be used?16:38
plarselopio: is there any documentation about this?16:38
elopioplars: that's the final solution, yes. While that command is ready, we need to support building new images.16:39
plarselopio: 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
plarselopio: it's still not clear to me if the build host *must* run xenial, or if it just needs the new binary16:40
elopioplars: we want to avoid that. We want to have people writing things for xenial to be using xenial.16:40
plarselopio: but we're not developing anything on that system, just building an image16:41
plarselopio: 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. udf16:42
elopioplars: again, right now I'm just asking for requirements. If we can completely ignore trusty, that would be easier for sure.16:42
plarselopio: then once all 15.04 images are deprecated, we can just kill the previous stuff16:42
plarselopio: I think in the near future though, we have to support both16:43
kyrofaChipaca, ping16:45
kyrofaChipaca, I'm having trouble merging my understanding of snappy with my understanding of this purge code :P16:46
kyrofaChipaca, 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 deactivated16:47
kyrofaChipaca, I thought that was a common scenario?16:48
=== chihchun is now known as chihchun_afk
kyrofaChipaca, trying to fix https://github.com/ubuntu-core/snappy/pull/264 by the way16:58
kyrofasergiusens, any chance you know what I'm talking about?16:59
Chipacakyrofa: sorry, hadn't brought irc up yet. am here now.17:07
Chipacareading backlog17:07
kyrofaChipaca, ah, no problem :)17:07
Chipacakyrofa: so, correct, `snappy remove` leaves data in place17:08
kyrofaChipaca, makes sense given how apt-get works17:08
kyrofaChipaca, or dpkg I guess17:08
Chipacakyrofa: 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 so17:09
Chipacakyrofa: oh dear, you are correct in that the use of datadirs is buggy :-(17:09
kyrofaChipaca, oh *whew* that's better than me being incredibly confused :P17:10
Chipacawell, users might disagree with you on that =)17:10
kyrofaChipaca, well I've got fixed (i.e. failing) tests anyway17:11
kyrofaChipaca, I can make a PR to fix it before fixing #26417:11
Chipacaon the other hand, maybe not17:11
Chipacaah! yes because it'll do deactivate in the second path17:12
Chipacabah humbug :-(17:12
Chipacakyrofa: +117:12
Chipacakyrofa: things current code doesn't consider is a snap using both data dir and user data dir, and multiple users17:12
Chipacakyrofa: both would fail in similar ways17:12
kyrofaChipaca, ah, indeed17:13
Chipacakyrofa: in both cases moving deactivate to inside the first loop would solve it i think?17:13
kyrofaChipaca, what was the purpose of looping through the data dirs in the first place? Is there a use-case I'm missing?17:13
Chipacakyrofa: as opposed to what?17:13
kyrofaChipaca, ah, it was for multiple VERSIONS17:13
kyrofaChipaca, yes?17:13
Chipacaah, yes17:14
kyrofaChipaca, okay, I'll point you to the PR when I make it, if that's alright17:14
Chipacakyrofa: that would be very alright17:15
Chipacakyrofa: going back on this a bit, depending on the size of the change, maybe moving it to pkg/lightweight is better17:33
kyrofaChipaca, ah, I've never looked at that package17:35
Chipacakyrofa: 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
kyrofaChipaca, 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
Chipacakyrofa: as the whole purge command is going away, probably not worth it unless fixing datadirs is big17:38
kyrofaChipaca, I think not. But I'll keep it in mind just in case17:38
* Chipaca nods17:38
kyrofaChipaca, https://github.com/ubuntu-core/snappy/pull/28318:27
sergiusenskyrofa, so should we do a 1.x today?19:47
kyrofasergiusens, 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 you19:49
kyrofasergiusens, but I know we've been wanting to get that out19:49
sergiusenskyrofa, depends on how long it will take, I don't want to delay too much ;-)19:50
sergiusenskyrofa, also, do the docs need more work or can they merge?19:50
kyrofasergiusens, agreed. How about we wait until tomorrow. If it's not done and looking good, we'll release19:51
kyrofasergiusens, ah, let me look them over again now19:51
sergiusenskyrofa, yeah, releasing on wednesday is fine by me19:51
sergiusenskyrofa, it would be nice to get the qml fix backported too19:51
kyrofasergiusens, agreed. I didn't see a response on that, so I can cherry pick19:52
sergiusenskyrofa, is it CLA worthy? A single cherry requires squashing though iirc19:52
kyrofasergiusens, the qml fix guy did sign the CLA19:53
breiis it possible to define an unpack path for the tar_content.py plugin?20:31
kyrofasergiusens, 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 them21:01
sergiusenskyrofa, oh bummer21:07
kyrofasergiusens, yeah it's sad... it was such a good idea21:07
sergiusenskyrofa, I can't think of another way that can reliably work for all cases21:08
kyrofasergiusens, I want all that stuff to be done in some sort of temporary lxc so the packages can actually be installed or something21:08
sergiusenskyrofa, we should only focus on lxc for 2.x21:12
sergiusenskyrofa, I'd say, send some sort of proposal to the devel list to see what comes21:12
kyrofasergiusens, 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 plan21:13
sergiusenskyrofa, what about things in /opt' and such?21:13
sergiusensit sort of gets some things working, but not all21:14
kyrofasergiusens, yeah, it doesn't work in all cases, but it works better than what we have now21:14
kyrofaExactly :P21:14
sergiusenskyrofa, can we use rpath with relative paths?21:14
sergiusensprobably not a good solution either21:14
kyrofasergiusens, I think you can with some special keywords, but it's been a long time since I played with that21:17
kyrofasergiusens, 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
sergiusenskyrofa, the general consensus was that most of this is a project specific problem21:19
kyrofasergiusens, 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 dependencies21:20
sergiusenskyrofa, personally, snapcraft magic voodoo should only be done when there's something we can hold on to21:20
kyrofasergiusens, yeah, you're right21:21
sergiusenskyrofa, there's nothing reliable we can use here21:21
sergiusenstoo bad those ld things are postinst :-(21:21
sergiusensI thought they'd be config files at most21:21
kyrofasergiusens, agreed. Let's scrap the idea and revisit if we ever get some sort of contained build21:21
kyrofasergiusens, they are, but they're symlinked in21:22
sergiusenskyrofa, is there any specific path that is already blocking something?21:22
kyrofasergiusens, I ran into it making a ROS .snap that uses opencv, which relies on opengl, which is in /usr/lib/arch/mesa21:23
sergiusenskyrofa, for the case of mesa/egl/gl, right?21:23
kyrofasergiusens, right21:23
sergiusenskyrofa, those are sufficiently common I guess to be able to track and check for21:23
kyrofasergiusens, I can at the very least add it to the catkin env(). Want me to add them to the overall runtime_env()?21:24
sergiusenskyrofa, overall is fine21:26
sergiusenskyrofa, I wonder if this is a pattern ''/etc/alternatives/.*_conf21:27
sergiusenssomething we can check for21:27
kyrofasergiusens, in the case I'm looking at, the real .conf is distributed within /usr/lib/arch/mesa, and the postinst installs it with update-alternatives21:31
kyrofaSo yes.... but no21:31
kyrofaBecause in that case, even the etc/alternatives is a symlink21:31
sergiusenskyrofa, ah/usr/lib/x86_64-linux-gnu/mesa-egl/ld.so.conf21:32
kyrofasergiusens, right21:32
kyrofaStupid chicken and egg problems...21:33
sergiusenskyrofa, the other option is to search for ld.so.conf files21:33
sergiusensbut that can be dangerous too21:33
kyrofasergiusens, I assume that name is nonstandard21:33
sergiusenskyrofa, exactly21:34
sergiusenskyrofa, so maybe search for those specific egl ones and read them through21:34
sergiusenskyrofa, we'll need to figure out what nvidia does as well21:34
sergiusensgl is sort of an important topic21:34
sergiusensah, nvidia is mostly a runtime thing, disregard me21:35
kyrofasergiusens, alright, I can do that21:36
sergiusenskyrofa, elopio is this just me with a new pep? http://paste.ubuntu.com/14404846/22:11
sergiusenseasy 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!