| *** Colgate_ is now known as Colgate | 03:29 | |
| adantes | hi | 10:51 |
|---|---|---|
| *** frinring_ is now known as frinring | 12:42 | |
| PureTryOut[m] | lbt: Sage_ I read on https://git.sailfishos.org/users/sign_in that I need to ask one of you guys for an account. I'd like to make a bug report for a compilation failure of libresource (although it doesn't have the issue tracker enabled) | 15:22 |
| mal | PureTryOut[m]: what kind of issue do you have building it? | 16:11 |
| PureTryOut[m] | Basically the compilation order is wrong when building with multiple threads. I have to use `-j1` to get it to compile properly | 16:12 |
| mal | PureTryOut[m]: that sounds odd, usually multithreaded build handles that automatically | 16:55 |
| PureTryOut[m] | Normally yes | 16:56 |
| kimmoli | ((i have same with onyx kernel on clean build, DTB is created too late and it complains it being missing. Just rerun or -j1 and it works)) | 17:11 |
| PureTryOut[m] | Yeah I'm using `-j1` for now which works fine, but I just wanted to report the bug so someone can take a look at it later | 17:12 |
| PureTryOut[m] | It's just that you can't get an account on the Gitlab instance that easy and even if you have one libresource doesn't have the issue tracker enabled | 17:13 |
| kimmoli | issues are in mer bugzilla | 17:23 |
| kimmoli | which is under same account | 17:23 |
| kimmoli | iirc/afaik disclaimers apply | 17:24 |
| PureTryOut[m] | Bugzilla? Why do some packages have the issue tracker on Gitlab then? | 17:36 |
| PureTryOut[m] | Also, what's the URL for bugzilla? And I guess I can't just make an account there either? | 17:36 |
| kimmoli | bugs.merproject.org, and no | 17:40 |
| PureTryOut[m] | That is... Annoying | 17:41 |
| mal | PureTryOut[m]: mer/sailfish doesn't use the gitlab issues | 17:49 |
| PureTryOut[m] | There still are some issues reported there though https://git.merproject.org/groups/mer-core/-/issues | 17:52 |
| PureTryOut[m] | Anyways, if I can't report the issue, please someone else do | 17:52 |
| mal | PureTryOut[m]: I will mention that internally tomorrow, if you could grab the failing build output it would be nice, are you using which environment to build it? | 17:57 |
| PureTryOut[m] | mal: thanks! build output: http://dpaste.com/16NHSMD | 18:00 |
| mal | PureTryOut[m]: please provide details of the build environment you use while building, platform sdk, application sdk or something else? | 18:01 |
| PureTryOut[m] | The reason I'm building libresource is unrelated to SailfishOS. I'm building it in postmarketOS, The environment uses Musl (which hasn't caused issue with any Mer stuff so far, thanks for keeping away from GNUisms) and GCC8 | 18:02 |
| mal | oh | 18:02 |
| PureTryOut[m] | I was typing still hold on 😉 | 18:02 |
| PureTryOut[m] | kimmoli could reproduce the issue though, and I'm assuming he/she is using the regular SailfishOS build environment | 18:03 |
| mal | ok, need to test a bit | 18:03 |
| PureTryOut[m] | Unrelated question, but is there any roadmap for SailfishOS moving from Qt5.6 to say 5.12? | 18:04 |
| kimmoli | my issue was not specific to that package | 18:14 |
| kimmoli | just saying that s* happens | 18:15 |
| r0kk3rz | PureTryOut[m]: 5.9 is next jump | 18:55 |
| PureTryOut[m] | Big improvement already, when is that happening? | 18:55 |
| r0kk3rz | nfi | 18:57 |
| r0kk3rz | SoonTM | 18:57 |
| PureTryOut[m] | That... Doesn't really say much lol | 18:58 |
| r0kk3rz | you must be new around here, jolla doeant do timeframes | 19:00 |
| PureTryOut[m] | I'm not new to SailfishOS (own a Jolla phone) but am new here indeed | 19:04 |
| PureTryOut[m] | I recognize your name, from Nemo by any chance? | 19:04 |
| r0kk3rz | we've chatted in several places now :) | 19:06 |
| r0kk3rz | even in person at fosdem i think | 19:06 |
| PureTryOut[m] | We did? Wow, sorry, I can't remember | 19:06 |
| r0kk3rz | it was at a big group thing abour purism | 19:07 |
| PureTryOut[m] | Oh in 2018 then. That's quite some time ago | 19:08 |
| r0kk3rz | aye | 19:08 |
| r0kk3rz | hows postmarketos going? | 19:09 |
| PureTryOut[m] | Quite well! Thanks for asking! We're quite busy with the PinePhone and PineTab atm, hopefully we'll soon be able to use our system on a properly mainlined device | 19:10 |
| PureTryOut[m] | I try things with Mer stuff every once and while but keep having issues with it. There are multiple projects using it which we'd like to package (Glacier from Nemo Mobile, AsteroidUI from AsteroidOS, and Hildon from Maemo Leste) but they all use different versions and have different quirks, it's a bit annoying | 19:12 |
| Thaodan | Is hildon really something that is still alive? | 19:14 |
| PureTryOut[m] | Hildon uses bits of forked Mer stuff which doesn't work with any other project. Glacier uses straight up Mer which is nice, but is stuck to ancient Qt 5.6 because of it so unusable for us. AsteroidUI uses a forked Mer to bring it up to date with more recent Qt, it works on Qt 5.12.3 but not on Qt 5.12.4 | 19:14 |
| r0kk3rz | yeah it can be a bit tough to use some of these things on a newer base | 19:14 |
| PureTryOut[m] | Thaodan: yes it is, it's being used in Maemo Leste | 19:14 |
| Thaodan | Looked like necromancy at first for me. | 19:14 |
| r0kk3rz | it kinda is necromancy | 19:15 |
| PureTryOut[m] | I'd say AsteroidOS's base is most promising for us at it runs on the most recent Qt, but it still uses a private Wayland API which Qt removed so we need to revert a commit in every version (and it doesn't currently work for Qt 5.12.4) | 19:15 |
| Thaodan | I hope the switch to glacier. I don't see the reason for yet another ui. | 19:15 |
| Thaodan | I hope the advancements in AsteroidUI go back to mer and help Silica. | 19:16 |
| PureTryOut[m] | Thaodan: I'd personally drop Hildon in a heartbeat if Glacier worked on Qt 5.12.4 although I'm not sure others would agree with me. | 19:16 |
| PureTryOut[m] | But it's not an option for now | 19:16 |
| r0kk3rz | PureTryOut[m]: necuno did aome work porting nemo to open embedded which could help there | 19:16 |
| PureTryOut[m] | Yeah I saw the post, porting it to the Yocto build environment | 19:16 |
| PureTryOut[m] | I haven't checked, but does it use a newer Qt? | 19:16 |
| Thaodan | PureTryOut[m]: I understand the only issue is that Meaemo was dead and was reborn under mer. Now it sucks of useful resources. | 19:17 |
| Thaodan | *sucks up | 19:17 |
| r0kk3rz | maybe? not sure, neochapay was doing qt5.9 nemo stuff | 19:18 |
| PureTryOut[m] | Maemo was dead, but I guess it was reborn twice. With Mer and Maemo Leste | 19:18 |
| PureTryOut[m] | Would be nice if the multiple projects using Mer could coordinate... | 19:18 |
| Thaodan | yeah please. | 19:18 |
| r0kk3rz | pfft, nobody cooedinates in open source | 19:19 |
| PureTryOut[m] | There is too much work being spread out over multiple projects atm. Stuff could go a lot quicker when a common based between the 3 is used | 19:19 |
| Thaodan | The guy at last fosdem already showed his revivial of meamo his kinda pointless | 19:19 |
| Thaodan | and more about revieving an old thing | 19:19 |
| PureTryOut[m] | Thaodan: last FOSDEM? Wizzup you mean? | 19:19 |
| r0kk3rz | the maemo leste talk? | 19:20 |
| Thaodan | yes | 19:20 |
| PureTryOut[m] | Not sure how it showed it being pointless tbh, although I have no need for it myself whatsoever | 19:21 |
| PureTryOut[m] | Still, it uses part of the Mer base but is incompatible with Sailfish's and Nemo's Mer | 19:22 |
| Thaodan | I was there, abranson too and someone other too maybe veskuh | 19:22 |
| r0kk3rz | mer isnt really mer anymore either, its sailfish-core | 19:23 |
| Thaodan | its still there just renamed | 19:23 |
| Thaodan | if Silica would go open it could save us al ressources and time. | 19:23 |
| r0kk3rz | never going to happen | 19:25 |
| Thaodan | A man can dream? :D | 19:26 |
| Thaodan | Its just its a huge pita to have different ui across this platforms that kinda do the same thing. Also it would have a great symbol power and save mich time. | 19:27 |
| *** Renault_ is now known as Renault | 19:29 | |
| r0kk3rz | agreed | 19:32 |
| PureTryOut[m] | Stuff like this is why I'm afraid for the future of Linux on mobile. If an app developer wants to make some mobile application for Linux on mobile, they have to target multiple different UI's and maintain multiple interfaces for them if they want their app to look native. They'd need to target GTK3 with Phosh, GTK2 with Hildon, several kinds of QML with Plasma Mobile, Ubuntu Touch, Silica, Glacier and LuneUI (from | 19:36 |
| PureTryOut[m] | LuneOS). That just scares people away | 19:36 |
| Thaodan | Thats why I always ask Purism why GTK?! | 19:38 |
| Thaodan | With Qt its atleast kinda the same. | 19:38 |
| Thaodan | Also GTK2 for wayland is non existant | 19:38 |
| PureTryOut[m] | Well that wouldn't be as big of a problem if it were just GTK and QML. But inside QML you have even more different platforms | 19:38 |
| PureTryOut[m] | Yeah Hildon is only X11 for the forseeable future. Another reason why I don't care much for it | 19:38 |
| PureTryOut[m] | Besides the man power Mer as a whole could use | 19:38 |
| PureTryOut[m] | At least all mobile development (besides Maemo Leste) seems to focus on Wayland which is good | 19:39 |
| Thaodan | GTK folks tend to ignore efforts that are Qt based an are affected by NIH | 19:39 |
| Thaodan | A good example current is using modemmanager instead of ofono. | 19:39 |
| PureTryOut[m] | Yeah that one stands out to me as well | 19:40 |
| Thaodan | Modemmanager is to limited for phones and currently gets ducktaped to work like this at all | 19:40 |
| PureTryOut[m] | Anyway, forget Purism for now, they are irrelevant to the Mer platform. | 19:40 |
| Thaodan | Just to don't loose face | 19:40 |
| PureTryOut[m] | At least all the Mer based projects should imo combine their efforts. Different UI's is one thing, but at least use the same, updated, base damn it | 19:41 |
| Thaodan | Thats true. But still they put a bad light on the whole idea. | 19:41 |
| Thaodan | I think one hinder is the Qt 5.6 base of #sailfishos | 19:41 |
| PureTryOut[m] | Agreed, it's a giant hinder | 19:41 |
| Thaodan | if upstream would move forward. | 19:41 |
| Thaodan | Better communicatin. | 19:42 |
| PureTryOut[m] | At least AsteroidOS, Nemo and Sailfish could work together well if the base were just updated to a higher Qt | 19:42 |
| Thaodan | Lets the what fosdem 2020 brings | 19:42 |
| Thaodan | Maybe we get a meeting similar to 2018 | 19:42 |
| PureTryOut[m] | Well, we can organize one. I doubt anything is going to happen otherwise | 19:43 |
| r0kk3rz | jolla movea too slowly for asteroid and nemo | 19:43 |
| PureTryOut[m] | then at least let Asteroid and Nemo work together? | 19:44 |
| r0kk3rz | they do already | 19:44 |
| PureTryOut[m] | How so? Nemo still uses the SailfishOS base and thus Qt 5.6 no? | 19:45 |
| r0kk3rz | true, but they know about each other and shate knowledge | 19:46 |
| r0kk3rz | not sure what else you expect | 19:46 |
| PureTryOut[m] | That's good | 19:46 |
| PureTryOut[m] | Is there a chance Nemo could at least move to the more updated Asteroid base? | 19:46 |
| r0kk3rz | afaik thats what the necuno thing was | 19:47 |
| r0kk3rz | nemo on asteroid base | 19:47 |
| PureTryOut[m] | Ah cool. Is Nemo Mobile going to use it? | 19:49 |
| r0kk3rz | not sure | 19:50 |
| Thaodan | PureTryOut[m]: thats true. Maybe before or after the SailfishOS community event | 19:55 |
| PureTryOut[m] | I just thought next FOSDEM 😜 | 19:59 |
| abranson | I think the necuno nemo build is a great opportunity to highlight any problems with the middleware and newer qt, such as with lipstick. the work on asteroid os has already contributed to that for 5.9. | 20:12 |
| PureTryOut[m] | A big problem I see with Lipstick is that it uses a private Qt5Wayland API. This API has been removed somewhere in Qt 5.12 so although it'll work on 5.9, it'll just keep causing problems. You can't just keep reverting a commit forever | 20:21 |
| abranson | Is there a public one to switch to? | 20:24 |
| PureTryOut[m] | Not atm no, which is the big problem | 20:31 |
| PureTryOut[m] | Also do note that Qt 5.9 support will end on the 31st of May 2020 already, less then a year. Yes Qt 5.9 is a big bump from the already unsupported Qt 5.6, but it's still too far behind | 20:34 |
| abranson | yeah, there's already been a lot of work done to move to Qt 5.9, but the reason sailfish/mer is still on 5.6 is a licensing issue. | 20:39 |
| *** Renault_ is now known as Renault | 20:40 | |
| abranson | if they still have pages like https://doc.qt.io/qt-5/wayland-and-qt.html in the current docs, then what's a project supposed to do? | 20:41 |
| PureTryOut[m] | I'm not sure I understand? What does that page have to do with licensing? | 20:58 |
| abranson | nothing, separate point sorry. | 21:01 |
| abranson | just wondering why that page is in the latest docs if there's no public qt wayland api | 21:02 |
| abranson | or is it just a subset of the api that's been removed? | 21:02 |
| PureTryOut[m] | Oh you misunderstood me, only a subset has been removed | 21:03 |
| PureTryOut[m] | The QWaylandExtendedSurface bit of the private compositor API. https://github.com/AsteroidOS/meta-asteroid/blob/master/recipes-qt/qt5/qtwayland/0002-Revert-most-of-Remove-QWaylandExtendedSurface-from-t.patch is used with Qt 5.12.3 to revert it | 21:04 |
| abranson | ah ok, thanks | 21:21 |
| PureTryOut[m] | Np! | 21:28 |
| PureTryOut[m] | So what is the licensing issue with Qt then? And how is it going to be resolved? SailfishOS/Mer can't seriously stay on Qt 5.6 forever, it's support has already been dropped upstream | 21:29 |
| abranson | it's been mentioned a few times in the community meetings. going past 5.6 involves either gplv3 or a commercial license, and both of those choices carry restrictive conditions for jolla's customers. | 21:35 |
| PureTryOut[m] | You mean Silica has to go GPL3? That would be awesome imo but ok | 21:37 |
| PureTryOut[m] | Isn't Qt LGPL licensed though so any software based on it can basically be licensed whatever as long as the Qt code used stays LGPL? | 21:37 |
| abranson | it's the tivoization thing. any gplv3 component must be able to be replaced by the user. that's fine for most of jolla's stuff now, because you get developer mode and can do anything like that whenever you feel like. but forcing that restriction onto any embedded device that could ever use sailfish is a tall order. | 21:41 |
| abranson | i'm sure there'll be a solution at some point, but it's not easy given that either of those choices will restrict what can be done with sailfish in the future. | 21:43 |
| abranson | but it's important to point out that it's not due to any perceived low priority of the issue | 21:43 |
| PureTryOut[m] | At least large parts of the Linux community does think it's some low priority issue. Besides, they're not, and neither am I, a fan of proprietary software so the whole reasoning isn't accepted by the community anyway. I guess most SFOS for some reason don't much care about it | 21:45 |
| PureTryOut[m] | *most SFOS users | 21:45 |
| abranson | I don't think it's really related to the open source/proprietary angle. the packages we're talking about are fully open source, but that doesn't mean that there can't be some commercial deployment of them that might require that those packages aren't modified for reasons of security/certification/whatever. if these customers help pay the bills of the developers who put a lot of time and effort into developing other components | 21:53 |
| abranson | that the whole mobile linux community benefits from, then I think that's something that can be at least tolerated. | 21:53 |
| PureTryOut[m] | But is there a commercial deployment currently that requires those packages to be modified under a proprietary license? It might become a problem in the future, but does it really have to hold back progress now? | 21:56 |
| abranson | no, it's nothing to do with any proprietary modifications. as stated in blog posts etc, a big reason why jolla/sailfish is still around is because it's interesting to large organizations, who can deploy and administer sailfish devices without having to defer control of those devices to apple/google/microsoft/whoever. it's reasonable to expect that if you get given a 'company phone' then you won't have administrative access to | 22:01 |
| abranson | it, and won't be able to do the things that the gplv3 insists that you should be able to. the device will be controlled by the IT department of your employer. | 22:01 |
| abranson | if we're talking about Qt, then you can still get the source from the sfos git for the packages that are running on your device, and change them however you like. and if you have another, personal, sfos phone then you can enable developer mode and install your new versions on that. but it's not a surprise that your employer won't want you to do that on your company device. | 22:05 |
| abranson | btw, i'm not saying that this problem won't be solved. i'm just trying to explain the problem that I personally don't know how to solve, but I'm sure that it will be eventually solved by the folks who are trying really hard to do so. | 22:09 |
| abranson | i think there are other examples of this gpl stalemate out there. iirc, OSX has the same ancient version of bash that sailfish does, though sailfish recently switched to busybox bash instead. | 22:10 |
| PureTryOut[m] | Ah ok that explanation makes more sense. The FOSS license newer Qt version use requires the user to be able to replace any GPL3 part of their phone, which an employer might not want their employees to be able to do. I guess simply removing developer mode for those users and making it "hard" to replace parts (but not impossible) won't do? | 22:11 |
| abranson | yes! gplv3 means you can't remove or disable developer mode | 22:12 |
| PureTryOut[m] | Ah... That is annoying then. The average SFOS consumer won't care about those companies obviously but I understand Jolla does | 22:13 |
| abranson | yes it's really annoying, but you can understand both why the tivoization clause exists, and why it's not acceptable for many commercial ventures. most sfos consumers won't care superficially, except that they're benefiting from the resources that go into improving sailfish for them, which far exceed anything that such a small community could support. | 22:15 |
| PureTryOut[m] | Thanks for the explanation! As a previous SFOS user I'm still annoyed by the proprietary bits and outdated Qt, but at least I understand the reasoning for the outdated Qt now. As a developer, I really just want the Mer base updated to Qt 5.12, it holds back progress 😛 | 22:16 |
| abranson | well that's why the stuff eetu did is so promising. if we can manage to keep all the mer packages in his openembedded/asteroid version the same as the sailfish ones and avoid too much forking, then nemo and sailfish can continue to share the vast majority of their mobile linux specific packages, and everybody wins. | 22:19 |
| PureTryOut[m] | Agreed, although it won't fix the licensing problem obviously. Also, does Silica even work on Qt 5.9 out of the box? | 22:20 |
| abranson | jolla will have less work to do on fixing the middleware for higher versions of qt when (not if) the time comes for that, and concentrate on more exciting new stuff, while nemo can benefit on all the work jolla does on middleware in the meantime. | 22:21 |
| abranson | I'm not sure how far along the 5.9 work is, but from what I recall the majority of it is done. You can see a lot of 5.9 branches on the mer git, so far unmerged. | 22:22 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!