| Kabouik | Rinigus is it possible with Chum to have two versions of the same software? | 00:09 |
|---|---|---|
| Kabouik | qtwayland was updated so supporting both old and new SFOS versions needs changes in the code itself, not just in the spec file | 00:10 |
| Kabouik | So I was thinking I could set the harbour-containers dep at >=0.0.6, then offer qxcompositor 0.0.6 (old qtwayland, compatible with old devices), and qxcompositor 0.6.1 (new qtwayland, latest sfos versions). But I don't know if that complies with Chum standards, and how to do it | 00:11 |
| rinigus | Kabouik: morning! Re qxcompositor SPEC: you had commit ID in _service that was pointing to master. as a result, OBS pulled that ID despite discrepancy between suggested branch and ID. for consistency, I removed branch from _service after accepting it to chum | 06:13 |
| rinigus | see _service file at OBS | 06:13 |
| rinigus | Yes, Repo is the one that counts in this respect | 06:14 |
| rinigus | in principle, you can have different OBS packages for the same app for tackling SFOS version differences. see storeman for example onnnnnnnn how to achieve it. Note that you would have to induce build limitations using package Meta info (see storeman). Alternative, is to use macros and select implementation on the basis of SFOS versions | 06:16 |
| rinigus | Kabouik: ^ | 06:16 |
| Thaodan | Kabouik: Chum separates per sfos version (as sfos itself does), if have stuff that depends a dependency a or b you can test for either. | 06:26 |
| Thaodan | Depending on the project you can also use rpm build conditions to enable features only per sfos or if enabled in the obs prjconf. | 06:27 |
| Kabouik | rinigus: Re qxcompositor SPEC: Yes that makes sense, that's what I finally figured out yesterday when tryin to understand why it didn't build for late SFOS versions. I realized my commit hash was master (wrong, but this is where I made my .spec changes, by mistake :facepalm:) and branch was qtwayland-5.6 (correct). This is now fixed, I submitted a new package whereby _service has a commit hash that matches the branch. | 07:41 |
| Kabouik | Should be ok for late SFOS versions. | 07:41 |
| rinigus | Kabouik: note that you are made maintainer in chum:testing for your packages. so, please make changes there directly and when ready submit the requests to sailfishos:chum from :testing | 07:42 |
| Kabouik | Then on OBS, I create a branch to that package, that builds SFOS for older versions (master branch, before the qtwayland-5.6 changes). Its version number is 0.0.6 while the above one is 0.0.6.1, but the plan is 0.0.6.1 should only install on devices that support the new qtwayland. harbour-containers requires only >= 0.0.6 so in theory that should work (?). This 0.0.6 package, I didn't submit to Chum because I did not know | 07:43 |
| Kabouik | how to deal with the two versions and Chum. | 07:43 |
| rinigus | Kabouik: take a look into storeman at :testing | 07:43 |
| Kabouik | I'll look | 07:43 |
| rinigus | you will see multiple packages and it is probably the way for you | 07:44 |
| Kabouik | Can you point me to the url? I'm not sure how to browse packages in :testing | 07:44 |
| Kabouik | https://build.merproject.org/package/show/home:olf:harbour-storeman-testing-cd/harbour-storeman-testing ? | 07:48 |
| Thaodan | Kabouik: If possible don't branch, you can do ifdefs for older versions. | 07:57 |
| Thaodan | https://build.merproject.org/project/show/sailfishos:chum:testing | 07:58 |
| Kabouik | Thank you Thaodan. So if I understand well, I should look at these three different storeman versions: https://0x0.st/oLwC.png Check their .spec file and try to do the same in qxcompositor, and then make two different qxcompositor packages (one for old, one for recent sfos) on OBS with their own service file | 08:00 |
| Thaodan | Kabouik: Chum has different repos per package, if you can do ifdefs for parts that are different for the older sfos than you can have one package that builds differently for older versions | 08:01 |
| Thaodan | You shouldn't care anymore for versions older the 4.x | 08:02 |
| Kabouik | But to be clear, package has to be built from two different source branches to cover all sfos versions. Is that what ifdef can do? | 08:02 |
| Thaodan | Kabouik: You should be able to use the same source on the older version too, you just need to use idefs were you need to call the older version. | 08:05 |
| Thaodan | From what I there's isn't much diff between the 5.6 branch and master. | 08:05 |
| Thaodan | https://github.com/elros34/qxcompositor/compare/master...Kabouik:qxcompositor:qtwayland-5.6?expand=1 | 08:06 |
| Thaodan | You should just rebase and cleanup | 08:06 |
| Kabouik | elros (author of qxcompositor) said there's change in the code of the program itself to comply with new qtwayland, not just build instructions, that's why we need two different branches | 08:06 |
| Kabouik | In fact I tried, the new version rpm does install on old SFOS devices, but it will throw errors | 08:07 |
| Kabouik | I'm new to all this, I'm sorry if I fail to grasp at trivial things | 08:07 |
| Kabouik | I see no ifdefs in Storeman .spec files that rinigus advised me to look at, but specific .spec files for each of three versions | 08:10 |
| Kabouik | And _service files pointing at different source branches | 08:11 |
| Thaodan | Kabouik: np, I think it comes down to the refactoring that elros did. | 08:18 |
| Thaodan | You should be able to use the QtWayland 5.6 version for all versions starting with 4.2 | 08:19 |
| Thaodan | If you can't make the 5.6 refactor from elros work on older versions either drop it or move it into a separate branch. | 08:20 |
| Thaodan | Then you add something like qxcompositor-5.4 as obs package name and point the _service to a different branch. | 08:21 |
| Kabouik | Could be, in fact my "old sfos" test devices are 3.3 and 3.4. This may seem old and I know we could skip them, but I'd find it more elegant if we can avoid making them obsolete for an app that coul work on them if I can package the two branches of qxcompositor and distinguish them as deps depending on the sfos version in use | 08:21 |
| Thaodan | Well that's really to old, everything below 4.x is obsolete except for old devices like Jolla 1. | 08:22 |
| Thaodan | I would argue on such old devices it's not fun to use such a package anyway. | 08:23 |
| Thaodan | Can you use git rebase to cleanup the commit history? | 08:23 |
| Kabouik | Sure | 08:23 |
| Kabouik | Should be done for qtwayland-5.6 branch | 08:25 |
| Kabouik | But that's just for the existing commits, I haven't made any commit regarding our discussions above | 08:25 |
| Thaodan | https://github.com/elros34/qxcompositor/pull/3/commits/4a7b3181ebddb7acb0aa3570541fb6ce333b2c25 this isn't just about chum but just building in a clean build env, the sdk targets have some dependencies preinstalled making it a little harder to reproducible packages. | 08:25 |
| Kabouik | The url is not valid anymore, I rebased | 08:26 |
| Thaodan | Kabouik: Good work on cleaning up the spec file, just one short thing if you change the License: field check the Fedora license table for the name we use in the license field. | 08:28 |
| Thaodan | https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ | 08:29 |
| Kabouik | The table says BSD-3-Clause, I think that's what I filled | 08:31 |
| Kabouik | Or I should use the abbreviation instead? | 08:31 |
| Thaodan | Yes | 08:32 |
| Kabouik | BSD NetCDF then | 08:33 |
| Kabouik | 08:33 | |
| Kabouik | So to double check that I didn't worsen the situation: qtwayland-5.6 branch: https://github.com/Kabouik/qxcompositor/commit/72bf10f39fd59b6db470647a56aa39e039014561 | 08:55 |
| Kabouik | master (qtwayland-5.4) branch: https://github.com/Kabouik/qxcompositor/commit/2b0057291d58a07e0803c541d9c5e1783277fc0f | 08:55 |
| Kabouik | I take it I can now make two packages on OBS and point the _service fils at these two branches, correct? | 08:55 |
| Kabouik | See https://build.merproject.org/package/show/home:kabouik/qxcompositor-sfos4.2 and https://build.merproject.org/package/show/home:kabouik/qxcompositor-sfos3.1 | 09:15 |
| Kabouik | Is that what you suggested rinigus? | 09:15 |
| Kabouik | (I did it in my home repo only for now) | 09:16 |
| Kabouik | Now what I don't understand really is the two unresolvable ones here: https://build.merproject.org/package/show/home:kabouik/qxcompositor-sfos3.1 The same package builds just fine for i486, and sfos3.4 has the requried dependency at a higher version number, so I don't get why OBS fails | 09:40 |
| Thaodan | Kabouik: Yes but you only need two packages that's why I said qtwayland 5.4 and 5.6 since that's more accurate | 09:56 |
| Thaodan | But you have two packages that seems to look good. You can disable aarch64 pre 4.x | 09:57 |
| Thaodan | I don't think there are any ports stuck on pre 4.2 that support aarch64 | 09:57 |
| Kabouik | Ok | 09:57 |
| Kabouik | The armv7hl fails too though, I don't get why | 09:57 |
| Thaodan | same for x86 | 09:58 |
| Thaodan | Don't set release to anything but a number | 09:58 |
| Thaodan | Obs will override so just set it to 0 | 09:58 |
| Kabouik | I just mimicked what storeman did there | 09:59 |
| Thaodan | What store man does is also wrong | 09:59 |
| Kabouik | Just changed the release numbers to 0 in both branch (not pulled on OBS yet) | 10:01 |
| Thaodan | Kabouik: try to remove qtbase from your project | 10:02 |
| Thaodan | It will be pulled in. | 10:02 |
| Kabouik | I disabled it, is that enough? | 10:03 |
| Thaodan | It was build already you have to delete the binaries that were build | 10:04 |
| Thaodan | https://build.merproject.org/package/wipe_binaries/home:kabouik/qtbase?repository=sailfish_3.4.0.24_aarch64 | 10:05 |
| Thaodan | https://build.merproject.org/package/binaries/home:kabouik/qtbase?repository=sailfish_3.4.0.24_aarch64 | 10:05 |
| Kabouik | Nice, qxcompositor-3.1 building for armv7hl now | 10:06 |
| Kabouik | So I think I can now delete qxcompositor from chum:testing, and submit both qxcompositor-3.1 and qxcompositor-4.2 instead | 10:07 |
| Thaodan | great | 10:07 |
| Thaodan | yes | 10:07 |
| Kabouik | Awesome, thanks a lot Thaodan | 10:07 |
| Thaodan | But you can keep the regular qxcompositor since the old one will go away | 10:08 |
| Thaodan | why did you name them after the minium sfos version and not the Qt-Wayland? version | 10:08 |
| Kabouik | I didn't quite get what you meant above with the fact that I only need two packages so qtwayland 5.4 and 5.6 are more accurate, I suppose it's for the package naming? I hope what I went for is not too wrong | 10:08 |
| Kabouik | I thought it was easier to understand (and again I took inspiration from storeman there) | 10:09 |
| Kabouik | Re But you can keep the regular qxcompositor since the old one will go away: I already had deleted it when you said that | 10:10 |
| Thaodan | Oh hm than add it again or keep the naming. | 10:10 |
| Thaodan | Re naming being more accurate: | 10:11 |
| Thaodan | I mean that because not the sfos version is the deciding factor but the Qt-Wayland version. | 10:11 |
| Kabouik | It's true but the spec files filter on sailfishos-version | 10:12 |
| Thaodan | Since it doesn't something to do with the provided SFOS version directly just which of the Qt-Wayland version provided by SFOS. Someone on like lets say sfos 4.0 might think which version should I pick. | 10:12 |
| Thaodan | Kabouik: Sure but you can also filter on Qt-Wayland version. | 10:13 |
| Kabouik | From a noob perspective, I was thinking that if I see a package named blah-sfos4.2 and I'm in 4.1, I would understand that I may not meet minimal requirements for that package | 10:14 |
| Kabouik | I'd be tempted to try it, of course, but I would understand if it doesn't work without goingto check dependencies | 10:14 |
| Thaodan | Ah and re using the version qt that works with Qt-Wayland 5.6 on sfos with Qt Wayland 5.4: You have to build your package against the older Qt Wayland. | 10:14 |
| Thaodan | In your project you had qtbase 5.6 which makes the package be build against that qt version even for the older sfos. | 10:15 |
| Kabouik | I had no idea that packages in the same home project would know about each other and interact | 10:15 |
| Thaodan | np | 10:16 |
| Thaodan | but that's the primary concept in obs | 10:17 |
| Thaodan | You can have multiple projects that interact with each other in a web. | 10:17 |
| Kabouik | That's really cool yes, I just fell in the trap that they were independent, and was already happy with "just" the building feature | 10:17 |
| Kabouik | Thanks a lot, Thaodan, rinigus. The two new packages are now submitted to :testing. When accepted, I'll test if dep resolution is working as expected, and if so submit to chum | 10:19 |
| Thaodan | Kabouik: good to hear :) | 10:20 |
| Kabouik | Thaodan do you know if Jolla is planning to support what elros did there (https://github.com/elros34/qtbase/tree/evdevmouse-3.4.0) with their in-house USB mouse support? I enabled display_cursor in dconf and it works great, but is limited to portrait. | 11:32 |
| Thaodan | Kabouik: I don't know, I only used evdev with a mouse under qemu. | 11:33 |
| Kabouik | Elros' work on qtbase was to make it support rotation (mouse coordinates rotating as well), but as you saw above, my attempt at building it on OBS were not going very well | 11:33 |
| Thaodan | Personally I see no future in using evdev directly but through libinput. | 11:34 |
| Kabouik | Elros' work was also before Jolla came up with the in-house cursor support. It'd be more future-proff to use Jolla's solution, but it really needs to support rotation to be useful | 11:34 |
| Kabouik | I don't really know the different to be honest, to me what is key is being able to use the mouse in both orientations (not only for LXC, but especially for LXC, and even more if we get HDMI-out support one day… We'd literally have non-HW accelerated desktop distro UMPC in our pockets) | 11:36 |
| Kabouik | rinigus when you see this, could you please just accept the two qxcompositors packages in testing so that I could do some testing? I won't submit them to the main repo before getting further approval from you, no worries | 13:08 |
| Kabouik | I mean no pressure, but it's just in case you would be delaying them to give them more scrutiny in prevision of the submission to main repo | 13:08 |
| rinigus | Kabouik: evening! now I just have to catch up ... | 17:48 |
| Kabouik | Long story short: Thaodan helped me and we have two different qxcompositor versions which should allow covering both old SFOS versions (qith qtwayland 5.4) and new ones (5.6), and I'm crossing fingers in hope that what I did with spec files and dependencies works to automatically install the right one in every situation :> | 17:51 |
| Kabouik | I'm not going to lie, I'm eagerly looking forward to test it, and if it doesn't work I'll hide and cry a bit. | 17:52 |
| rinigus | Re licenses: we use list as in https://github.com/sailfishos/rpmlint/blob/master/rpm/sailfish.toml#L150-L459 . That one lists BSD-3-Clause just fine. If you prefer some other way to name it, it is OK. Just not needed :) | 17:58 |
| rinigus | Re storeman: not the best way to do it, but as you were not very happy with hacking in C++ it was a way out of it. Namely, have separate brunches and OBS packages for different versions | 17:58 |
| rinigus | Thaodan did well with helping you out, thanks a lot! | 17:58 |
| Kabouik | I named it BSD-3-Clause originally but Thaodan said I should use the abbreviated column from the Fedora table, which was BSD NetCDF | 17:58 |
| Kabouik | Yes, I'm very grateful to you both for your time and patience. | 17:59 |
| rinigus | yeah, I saw that in the logs. now will go and look into the packages. | 17:59 |
| rinigus | at obs | 17:59 |
| Kabouik | Re: licences: I can change that again, but if that's no issue, you can just accept in :testing so that I can test different dependency-resolution scenarios, and then polish License in :testing before submitting to main repository. | 18:00 |
| mal | just a note about license string formatting in spec https://github.com/sailfishos/rpmlint/blob/master/rpm/sailfish.toml#L165 that has the list used by our rpmlint, quite directly taken from fedora I think | 18:01 |
| Kabouik | Okay, I'll change it again into BSD-3-Clause then. I see I need to change harbour-containers' "GNU GPLv3" into "GPLv3" too. | 18:02 |
| rinigus | Kabouik: I will immediately change the build flags for the version with older SFOS | 18:02 |
| Kabouik | Awesome! | 18:06 |
| rinigus | Kabouik: should be OK now. Over to you for testing | 18:06 |
| rinigus | When ready, just submit packages from sailfishos:chum:testing to sailfishos:chum | 18:07 |
| rinigus | Kabouik: ^ | 18:07 |
| Kabouik | Thanks. Just to be sure, my copy in my home project is not automatically synchronized, is it? I don't think I even need to keep it, but I can use it for testing I assume. | 18:11 |
| Kabouik | For testing new versions I mean. | 18:11 |
| Kabouik | First observation: Chum sees that available versions have version numbers above the ones installed already, but there is no update button. Did I do something wrong? | 18:13 |
| rinigus | No, it should not be synchronized. Those are separate | 18:13 |
| Kabouik | So I need to uninstall manuall first, good | 18:14 |
| Kabouik | Oh sorry you were answering to the other question. | 18:14 |
| rinigus | Kabouik: yes, if installed from other repo then you have to uninstall first. it is a protection that allows users to mix chum and non-chum packages | 18:15 |
| Kabouik | I see, so Chum somehow keeps metadata somewhere of what it did | 18:15 |
| Kabouik | Or recognizes where the packages originate from. | 18:16 |
| rinigus | Kabouik: it just sets Vendor tag for generated RPMs. No mystery. If vendor tags are different from what's installed on the phone, RPM is not updated | 18:19 |
| Kabouik | Should release be 0 or 1? | 18:19 |
| Kabouik | I used 1 first but then was told to use 0, I see both in packages from others | 18:20 |
| Kabouik | This suggests 1 as standard: https://rpm-packaging-guide.github.io/#hello-world I'll bump it to 1 in qxcompositor | 18:22 |
| rinigus | Kabouik: keep Release as it is - it will be overwritten by OBS and incremented after each rebuild. Focus on Version and set it as you find appropriate | 18:27 |
| Kabouik | Just having it set as 0 in qxcompositor, and 1 in lxc-templates-desktop and harbour-containers triggers some OCDs… ! | 18:28 |
| Kabouik | But yeah, leaving as is then. | 18:29 |
| Kabouik | I don't see GPLv2.1 in the abbreviations. | 18:32 |
| Kabouik | Is GPLv2+ the correct synonym mal? | 18:33 |
| rinigus | Its OK, just leave it. We don't run any automatic checks anyway - main thing is that it is clear | 18:33 |
| mal | I think GPLv2+ is ok | 18:34 |
| Kabouik | Thanks! I'll do it rinigus just because I already started | 18:34 |
| mal | yeah, rpmlint errors/warnings are not critical, just something that would be nice if people look at, those sometimes show real issues | 18:35 |
| Kabouik | Yeah, I'm slow but at the very least I'm trying to comply with the standards, maybe unreasonably :p | 18:51 |
| Kabouik | Okay I have a small issue | 19:02 |
| Kabouik | I triggered a rebuild for harbour-containers and the filename is called 0.4+master… Yet the .spec file and .yaml file all state 0.6 as version number. I also made a release on github which I tagged 0.6. | 19:03 |
| Kabouik | How can I make the versioin built by OBS chum:testing reflect 0.6? | 19:03 |
| Kabouik | Same problem with lxc-templates-desktop actually | 19:03 |
| Kabouik | qxcompositor reports 0.0.6 as it should, no problem for that one | 19:04 |
| Kabouik | rinigus would you by any chance know what is happening? I imagine OBS ignores the version in .spec and just increments from something else? | 19:14 |
| Kabouik | Seems to be related to Github releases. I created a 1.3 release for lxc-templates-desktop and now OBS names the tarball 1.3, and rpm too. Not sure why it doesn't do that for harbour-containers despite a release already existing with the tag number I want. | 19:26 |
| piggz[m] | @kabouic obs names releases based on git tag. Use x.y.z+gitN | 19:31 |
| Kabouik | I don't understand, I have a 0.6 tag here https://github.com/sailfish-containers/harbour-containers/releases/tag/0.6 | 19:36 |
| Kabouik | It still uses 0.4 in OBS | 19:36 |
| Kabouik | Actually I see that on Github my tag 0.6 is tied to an old commit, weird | 19:37 |
| Kabouik | Does that mean my later commits defaulted to an older tag? | 19:37 |
| Kabouik | I just deleted the tag and then ran `git tag 0.6 hash of latest commit`, let's see | 19:39 |
| Kabouik | Nope, tag stays assigned to that older commit | 19:40 |
| attah | pushing tags is screwy | 19:42 |
| Kabouik | I finally managed to assign the tag to the latest commit | 19:42 |
| Kabouik | Somehow it was staying tied to the old one, I guess I forgot to push | 19:42 |
| Kabouik | https://0x0.st/oLle.png YAY | 19:43 |
| Kabouik | Chum seems to be a success! A small step for man, a giant leap for me | 19:55 |
| Thaodan | Kabouik: you have to do git push remote --tags | 20:57 |
| Thaodan | or just the tag you want to push | 20:57 |
| Kabouik | Thanks! | 21:11 |
| Kabouik | rinigus, mal, it seems Chum doesn't support multi-user | 22:22 |
| Kabouik | The main dev of harbour-containers was testing it and was logged as secondary user, Chum was unhappy about everything he tried (including CLI) | 22:23 |
| Kabouik | https://github.com/Kabouik/qxcompositor/blob/qtwayland-5.6/rpm/qxcompositor.spec#L16 unfortunately this was not enough apparently rinigus. On his 3.4 device, Chum still installed this version of qxcompositor, and not the one for 3.1 > sfos < 4.2 | 22:28 |
| Kabouik | For me on 4.4, it installed that version of qxcompositor too but that's expected | 22:29 |
| Kabouik | Scrap this, he forgot to uninstall qxcompositor from other vendor. | 22:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
