| *** zbenjamin_ is now known as zbenjamin | 01:33 | |
| *** frinring_ is now known as frinring | 01:46 | |
| deloptes | Hi, someone knows how to install kf5calendarcore in the SDK? | 10:38 |
|---|---|---|
| deloptes | SDK vers=3.3.0.16 | 10:38 |
| rinigus | I have trouble with using bison. Always getting errors "bison: m4 subprocess failed: No such file or directory" | 13:37 |
| rinigus | SDK target 4.0.1 | 13:37 |
| Nico[m] | No m4 installed? | 13:37 |
| rinigus | It is | 13:42 |
| rinigus | Nico: and for some reason it does work on OBS while it doesn't work on SDK @ PC | 13:44 |
| Nico[m] | Very weird | 13:45 |
| Nico[m] | Which file is missing? | 13:45 |
| rinigus | Nico: now that's a problem - it doesn't say | 13:46 |
| Nico[m] | Yeah, it never does, huh? | 13:46 |
| Nico[m] | Stracing is probably difficult? | 13:46 |
| rinigus | from make? hmm, thanks - will try. let's see if I get to it that way | 13:48 |
| rinigus | thanks | 13:48 |
| mal | rinigus: can you link to the obs project? | 14:00 |
| rinigus | mal: https://build.merproject.org/package/show/home:rinigus:flatpak/ostree | 14:13 |
| rinigus | same issue was with collectd, but I cheated there and added parse .c | 14:13 |
| rinigus | so, n=2 | 14:13 |
| mal | rinigus: hmm, in my devel target that built without issues | 14:23 |
| mal | I can try in 4.0.1 also if needed | 14:23 |
| rinigus | mal: on PC? | 14:26 |
| rinigus | mal: please try with current SDK that we have access to | 14:26 |
| mal | rinigus: yes, that was on my laptop using platform sdk | 14:29 |
| rinigus | mal: would be good to test with the released target. | 14:30 |
| mal | trying with 4.0.1 now | 14:32 |
| rinigus | mal: thanks | 14:32 |
| mal | rinigus: built fine also in 4.0.1.48 target | 14:35 |
| mal | fresh clone of the sources, with submodules synced also | 14:36 |
| mal | rinigus: can you verify that submodules are synced in your local sources? | 14:36 |
| rinigus | mal: will try again with the fresh clone. was it out-of-tree build or within the src dir? | 14:37 |
| mal | just normal mb2 build | 14:37 |
| rinigus | don't think it matters, but I will try to reproduce it | 14:37 |
| rinigus | mal: thanks. will try again and report back | 14:37 |
| rinigus | mal: no luck. have tried with sfdk after making fresh clone - failed. made new fresh clone and it failed the same way with mb2. tried -j1 - no help. will try to reinstall SDK | 14:47 |
| rinigus | mal: fresh SDK install, fresh clone, still failed. even rebooted for a good measure - no help | 15:13 |
| rinigus | will have to look whether it works on some other PC or server | 15:13 |
| mal | rinigus: hmm, wondering if some dependency is missing or something | 15:46 |
| rinigus | mal: testing now in platform sdk that I use for ports | 15:46 |
| rinigus | but it would be odd if some dep is missing and it would compile fine on OBS | 15:47 |
| rinigus | platform SDK was fine... | 15:47 |
| rinigus | mal: let's see if docker would help in my case | 15:48 |
| mal | hmm, what is so different in app sdk | 15:49 |
| mal | rinigus: I often build even apps in platform sdk | 15:49 |
| rinigus | mal: no idea why it trips. can only speculate at this point, but let's see if docker will help | 15:51 |
| rinigus | nope - docker tripped on the same spot | 15:52 |
| rinigus | mal: would take a break and think a bit. right now now idea how to approach it even. strace didn't help either, but can try again | 15:55 |
| rinigus | mal and Nico : strace helped, but had to read it right and run to follow forked processes. bison forks m4 while running. in SDK, bison runs under sb2 (was longish strace exec name with /srv/mer/targets/SailfishOS-4.0.1.48-i486/lib/ld-linux.so.2) while tries to fork /usr/bin/m4 | 16:59 |
| rinigus | somehow, m4 escaped sb2 and was run on host (docker main shell or vbox main env). | 17:00 |
| rinigus | as m4 was not installed there, it failed | 17:00 |
| Nico[m] | Maybe m4 is one of those whitelisted binaries? | 17:01 |
| rinigus | after installing m4 and bison into the "host" env (docker and vbox main), all worked as expected) | 17:01 |
| rinigus | I presume, those are installed at OBS and platform SDK, but not for app SDK. | 17:02 |
| rinigus | so, for docker env, solution was to run `docker exec sailfish-os-build-engine zypper --non-interactive in bison` | 17:02 |
| rinigus | notice absence of targets | 17:02 |
| ol | <rinigus "somehow, m4 escaped sb2 and was "> I remember this problem. It's not because of the way m4 is started, using posix_spawn() function that is not wrapped by sb2. | 17:16 |
| ol | > <@freenode_rinigus:infoserver.lv> somehow, m4 escaped sb2 and was run on host (docker main shell or vbox main env). | 17:16 |
| ol | * I remember this problem. It's not because m4 is special, byt because of the way m4 is started, using posix_spawn() function that is not wrapped by sb2. | 17:16 |
| ol | * I remember this problem. It's not because m4 is special, but because of the way m4 is started, using posix_spawn() function that is not wrapped by sb2. | 17:16 |
| ol | (Not sure how message edits are shown on IRC side.) | 17:17 |
| rinigus | ol: poor wording on my side. your explanation makes sense and maybe bison+m4 should be included into sdk by default | 17:17 |
| ol | rinigus (IRC): It doesn't matter whether bison is included by default or not. If it uses posix_spawn(), the process started is not wrapped by sb2 anyway. | 17:19 |
| rinigus | ol: it does. then it calls /usr/bin/m4 from host and if it is available build goes on just fine | 17:20 |
| ol | The way sb2 wraps file access and starting processes is very fragile. It's impossible to wrap only system calls using LD_PRELOAD magic. If all system calls were in a separate shared library (like in Windows), it would be possible. But glibc doesn't so it: fopen() and other higher level file access function are in the same library as open(), so all of these functions should be wrapped by preloaded library, and there are hundreds of them. And some of them are | 17:24 |
| ol | impossible to wrap correctly (like popen(), for example). | 17:24 |
| Nico[m] | <ol "(Not sure how message edits are "> horribly | 17:24 |
| ol | <Nico[m] "<ol "(Not sure how message edits"> I hope IRC will eventually die. | 17:25 |
| mal | never! | 17:27 |
| ol | There is no reason to keep using IRC when Matrix is superior in everything. | 17:29 |
| Nico[m] | <ol "<Nico[m] "<ol "(Not sure how mes"> He says on IRC from a Matrix server bridged to another Matrix server VIA IRC | 17:29 |
| ol | And this is also a problem. I don't want to use matrix.org bridge because I don't want to share my registered nick's password with a third party. | 17:31 |
| Nico[m] | Fair | 17:32 |
| ol | If IRC bridges were smart enough to detect that Matrix user is bridged using another bridge, I would just bridge the same Matrix room using my own bridge just for me. But they are not, so this would lead to disastrous results. | 17:34 |
| Nico[m] | We just need to move this room to matrix and bridge it to IRC ;p | 17:35 |
| Nico[m] | So that matrix users don't need a nick pw | 17:35 |
| ol | Or just move this room and don't bridge. So all remaining IRC users will switch to Matrix. | 17:36 |
| Nico[m] | That would be very rude | 17:37 |
| ol | It depends on what we want to achieve. | 17:37 |
| Nico[m] | I'm not on bord with forcing anything ;p | 17:38 |
| ol | Some users don't even know about Matrix and how it's superior to IRC. | 17:38 |
| attah | Accessibility presumably? | 17:38 |
| Nico[m] | I mean, none ever made a good matrix client for Sailfish either! | 17:38 |
| attah | Until then it seems a bit hypothetical... | 17:39 |
| ol | <Nico[m] "I mean, none ever made a good ma"> I don't want to point a finger. | 17:39 |
| ol | <attah "Accessibility presumably?"> Yes, including accessibility. Matrix is superior on this front as well. | 17:39 |
| Nico[m] | One day I will have the time to work on mine again .-. | 17:39 |
| *** karmar281 is now known as karmar | 18:02 | |
| rinigus | mal: next problematic package that fails on appSDK. It builds just fine on platformSDK as well as OBS. | 19:39 |
| rinigus | https://build.merproject.org/package/show/home:rinigus:flatpak/libappstream-glib | 19:39 |
| rinigus | error while loading shared libraries: libgdk_pixbuf-2.0.so.0: cannot open shared object file: No such file or directory | 19:39 |
| rinigus | however, it is installed in the target as it is added to buildrequires | 19:40 |
| rinigus | mal: ^ | 19:40 |
| rinigus | hmm, and it build fine for aarch64 when using appSDK | 20:00 |
| elros1 | rinigus not sure if its' any help for you but that libappstream-glib build fine using mb2 in application sdk (virtualbox) for armv7hl | 20:00 |
| rinigus | elros1: looks like that issue is limited to i686 - target I use for faster checks | 20:01 |
| rinigus | thanks for checking | 20:01 |
| elros1 | ah ok, I don't have i686 installed currently but if you want I coud check that also | 20:02 |
| rinigus | if you don't mind, please do. I used docker over here | 20:04 |
| mal | rinigus: ah, could the same issue have been with the other package also, I used aarch64 target | 20:04 |
| rinigus | mal: no, ostree got fixed by adding bison / m4 into main env, as described above. after that, x86 target worked fine. | 20:06 |
| rinigus | although, I can't be sure | 20:06 |
| rinigus | ... that I would get error if I would start from aarch64 | 20:07 |
| Thaodan | rinigus: Is the tooling/target up to date? I remember fixing that. | 20:08 |
| rinigus | Thaodan: wiped it and reinstalled it today. should be | 20:10 |
| rinigus | unless I need to install some EA version | 20:10 |
| mal | sometimes people forget to update tooling (and also sdk itself) at least porters do | 20:12 |
| rinigus | mal: true, have done it as well. so legitimate question | 20:12 |
| mal | "sdk-foreach-su -ly zypper dup" is a nice thing (and other command you run the same way) | 20:14 |
| mal | that is how I update my devel targets | 20:15 |
| elros1 | rinigus: I got warnings like: (WARNING) ldd{bash}[4300]Executing statically linked native binary /srv/mer/targets/SailfishOS-4.0.1.48-i486/lib/ld-2.30.so but looks it also builds fine for i486 | 20:16 |
| rinigus | elros1: thanks! I have those warnings as well. no idea then why it failed over here | 20:18 |
| rinigus | mal: thanks - but my targets/tooling should be fine as they were installed today. although, handy command | 20:20 |
| elros1 | here is full build log if you want to compare: https://pastebin.com/sJLuYasM | 20:21 |
| rinigus | elros1: thanks. | 20:22 |
| rinigus | it looks good | 20:22 |
| rinigus | as it is late, gn | 20:22 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!