| T42 | <linusdan> Hi, guys! I have a question: Is it necessary to add something to make non neon devices compatible with Sailfish apps or is android hal enough? | 01:20 |
|---|---|---|
| r0kk3rz | non neon devices like what | 02:06 |
| r0kk3rz | sailfish rootfs only really comes in two flavours | 02:07 |
| rinigus | mal: I'll wait for your approval | 04:13 |
| rinigus | piggz: several goals here: help Nemo, check if latest obs is ok (should reduce maintenance), and get maps apps into obs with regular Linux | 04:24 |
| rinigus | Not much pushing Jolla in this respect :) | 04:25 |
| r0kk3rz | i got the impression that they've already decided to kill our obs | 04:26 |
| rinigus | Similar impression here. Question is then what will be instead, but that seems to be unknown. Maybe we can get help with setting up another OBS or reconfigure current one | 04:55 |
| rinigus | git.sailfishos.org admins: help! can you please increase the quota for number of projects to me on the server? as I fix trivial build issues, I may need way more projects than is available now | 05:45 |
| rinigus | mal: that exe bit is needed also to fill properly provides for rpm. without exe bit set, library is not listed in "provides" of the package on fedora | 08:25 |
| T42 | <adampigg> linux - Why are .so files executable? - Unix & Linux Stack Exchange | 08:33 |
| T42 | <adampigg> https://unix.stackexchange.com/questions/61646/why-are-so-files-executable | 08:33 |
| spiiroin | I blame rpm. IIRC etc, rpm build uses "locate +x bit files" as substitute for proper "find elf binaries" -> stripping debug symbols etc fails if libraries do not have x bit set | 08:37 |
| rinigus | @adampigg, mal: https://unix.stackexchange.com/questions/400187/why-should-or-should-not-shared-libraries-be-executable-e-g-red-hat-vs-debian | 08:37 |
| spiiroin | you can arrange it so that final packaged libs do not have x bit, but ... whether it is worthwhile | 08:38 |
| rinigus | spiiroin: according to the link above, it is default for gcc to set it executable | 08:38 |
| spiiroin | rinigus: well, it makes no sense unless it is very special library - you are not supposed to execute them | 08:39 |
| rinigus | spiiroin: as for blaming rpm, you are probably right. although it does seem to be default on rpm distros to have it set. and sfos is using rpm | 08:39 |
| r0kk3rz | moo spiiroin, is it important to build stuff with sb2 for sailfish, or would any cross compiler do? | 08:39 |
| rinigus | as for whether it makes sense, I agree with you | 08:39 |
| spiiroin | r0kk3rz: I guess it depends, there are some projects that use sailfish sw + completely different build envs and there is no harm in it as long as both can peacefully co-exist | 08:45 |
| spiiroin | like, if there are prs related to supporting other tools, sb2/obs/whatnot should keep on working | 08:46 |
| r0kk3rz | spiiroin: we were thinking about using OBS but with its kvm based cross compiler instead | 08:46 |
| r0kk3rz | and I wasnt sure whether that was a terrible idea or not, since theres presumably some benefit to using sb2 | 08:49 |
| r0kk3rz | or if sb2 is just used for hysterical reasons | 08:49 |
| spiiroin | r0kk3rz: personally I use only sb2. local builds. one component at time. then occasionally fix something if builds in obs fails after tagging... | 08:50 |
| spiiroin | but that is probably just because it is rather seldom that I need to touch more than one component simultaneously | 08:51 |
| r0kk3rz | yeah, but thats only because you guys have your own OBS chugging away in the background :P | 08:53 |
| rinigus | spiiroin & mal: (as it helps to have 2 discussions at the same time) so, any decision regarding +x set for libs? as we already have it for the most of the libs anyway | 08:56 |
| spiiroin | rinigus: IMO based on what I think I know: not having +x in rpm build system is fighting windmills | 08:58 |
| rinigus | it does feel so | 08:59 |
| spiiroin | I might have done something somewhere to avoid it, but I would not require anybody else do it as it does require going through otherwise unnecessary hoops and loops when most if not all packages still have the +x | 09:00 |
| rinigus | thanks! I have submitted 2 MRs last night: one for setting mer-dev to noarch (otherwise fedora looks for exe bits and complains about debug symbols) and one for libglibutil with +x | 09:02 |
| rinigus | mal wanted to check something as well before giving the green light, as far as I know | 09:03 |
| piggz | rinigus: top effort, will try to get on board soon to help out | 09:03 |
| rinigus | if all is OK, I can start submitting MRs as I encounter them | 09:03 |
| rinigus | piggz: thanks! | 09:04 |
| rinigus | spiiroin: who to ping to get git.sailfishos.org quotas lifted? | 09:04 |
| spiiroin | rinigus: lbt ^ | 09:05 |
| mal | rinigus: the thing I meant was just about bug references in the commit messages | 09:16 |
| mal | meaning what kind of bug ref to use in those | 09:16 |
| rinigus | mal: understood. I presume you want me to have the same ref in all of these trivial commits? | 09:18 |
| rinigus | or do you use it in the merge commit? | 09:18 |
| mal | rinigus: use JB#51013 as bug reference in the executable bit commits | 10:48 |
| rinigus | mal: will do. I will then change the commit message for the already submitted MR | 10:50 |
| rinigus | ... tonight | 10:50 |
| mal | rinigus: that was merged already | 10:51 |
| rinigus | mal: for some reason all messages from gitlab end up in spam :( | 10:53 |
| rinigus | will set the filter | 10:54 |
| mal | rinigus: https://git.sailfishos.org/mer-core/nemo-gst-interfaces/merge_requests/6 this won't work for us, maybe try to add --disable-static to configure line in the spec | 16:44 |
| mal | and then remove the new additions to files (sfos build removes the static files anyway) | 16:44 |
| rinigus | will do. I will close that PR then and make a new one | 16:44 |
| rinigus | mal ^ | 16:45 |
| mal | you can fix the PR | 16:45 |
| mal | unless you for some reason want to use a different branch | 16:45 |
| rinigus | OK, will fix PR then. no problem with the branch | 16:46 |
| rinigus | just hit gitlab limit again, but let me fix the PRs I have | 16:46 |
| rinigus | mal: disabling static and dropping .a was sufficient. is it OK now? | 17:07 |
| *** Oksana_ is now known as Oksana | 17:25 | |
| mal | rinigus: it still generates .la files? | 17:47 |
| rinigus | mal: it should, otherwise it would fail | 17:49 |
| rinigus | let me download rpm | 17:49 |
| mal | rinigus: I think that will still be a problem because sfos build won't have those | 17:49 |
| mal | rinigus: did you make test builds on both OBSes? | 17:50 |
| rinigus | mal: I was wondering about it. I can add %if 0{?fedora} in this case | 17:51 |
| rinigus | mal: no, I didn't test on SFOS one as I had issues with compilation of nemo core packages on it (tried on one of them). could be related to heavy project config used there | 17:51 |
| rinigus | maybe SDK would be more adequate in this case | 17:52 |
| mal | rinigus: in many of our spec files we have https://git.sailfishos.org/mer-core/rygel/blob/master/rpm/rygel.spec#L72 or some have "rm -f %{buildroot}/%{_libdir}/*.la" | 17:53 |
| mal | maybe not many but some | 17:53 |
| rinigus | mal: that should do, I will do it that way. it sounds like these files are not needed anymore | 17:53 |
| mal | rinigus: so if there are no subfolder then "rm -f %{buildroot}/%{_libdir}/*.la" is probably simpler | 17:54 |
| rinigus | mal: agree, let's keep it simple | 17:54 |
| mal | find is needed for more complex builds | 17:55 |
| mal | rinigus: platform sdk build is also a good way to test | 17:55 |
| rinigus | mal: submitted cleaned up commit. sorry for not testing it before with SFOS, should have done so | 18:36 |
| mal | rinigus: looking better now | 19:04 |
| mal | rinigus: also fix the PR title | 19:05 |
| rinigus | mal: done | 19:11 |
| pketo | rinigus: I increased your project limit on git.sailfishos.org (cc: lbt) | 23:17 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!