Friday, 2021-08-20

riniguspoetaster : that line 42 is indeed what makes it work. You could do the same with dropping 'auto' and using plane setup.05:00
poetasterrinigus: the problem I have is that I'm using the sdk which, in the imageworks case, does some of the lifting in the project file.06:32
poetasterrinigus: that obscures how to use the spec + git.06:33
riniguspoetaster: should work from SDK as well, just login into it (ssh) and make sure you clone repo recursively in git.06:35
poetasterrinigus: I'm not sure of the workflow. You lost me at log in to it. you mean the build engine image?06:36
poetasterrinigus: I want to build a pro file (probably a bad idea) that collects the depends. so, I guess subdirs style.06:37
poetasterrinigus: oh, you're just saying, clone the repo recursively into the {root} of my project/lib context?06:38
riniguspoetaster: ssh into build engine for building and use `mb2 -t xxxx build`06:54
rinigusas for dependencies, it is hard to judge. I guess it is case specific. what do you want to build?06:55
riniguspoetaster: ^06:55
poetasterrinigus: it's still about imageworks (harbour-simplecrop). My c++ projects I've managed to get library builds 'local'. But this is python+c06:57
riniguspoetaster: so problem was with PIL import, right? but that you could just impose as Requires and pull from the system, can't you?06:58
poetasterrinigus: not in harbour.06:58
riniguspoetaster: forget about harbour for a sec. would it work for chum/openrepos?06:59
poetasterrinigus: I've tried once and it failed, but I'll try again (Requires python3-imaging failed)07:00
poetasterrinigus: assuming you mean: 'Requires:   python3-imaging'  in spec07:00
riniguspoetaster: try to make it work for chum/openrepos and then let's see how to make it for harbour.07:00
riniguspoetaster: yes, that Requires should be it. not sure about package07:01
rinigusyou will have to check if that Requires leads to the lib which you can import in python07:01
poetasterIf the requires pulls, it will work. I had a third party verify that zypper installing on device (aarch64) works.07:02
riniguspoetaster: it does pull07:02
rinigusnow check which files does it install (`rpm -ql python3-imaging`) and check if it pulls in something in addition (requires of python3-imaging)07:03
rinigusfor harbour, youu would "just" need to copy these files into your app `shared` and make sure that you add corresponding path to import path of python07:04
poetasterworks with the expected ERROR [python3-imaging] Dependency not allowed07:04
riniguspoetaster: ^07:04
riniguspoetaster: is that ERROR in SDK and it is refusing to build RPM or it is just blabbing by lint?07:05
poetasterrinigus: sorry, just lint. not important07:05
riniguspoetaster: OK, so for chum and openrepos you could use that SPEC. we would need now just to add harbour bits07:06
poetasterrinigus: the problem with PIL is the c depends. But, martyone's workaround on arm will probably work.07:06
rinigususe that jolla_store macro (or similar) and add sections for harbour vs chum. in chum, keep Requires. in harbour, add BuildRequires: python3-imaging instead07:07
rinigusand start copying files as a part of install in SPEC (for harbour)07:07
riniguspoetaster: ^07:08
poetasterrinigus: using 'vendor' flag.07:08
rinigusyou can do that instead, indeed.07:08
rinigusbut I would recommend to setup in OBS a project for harbour and just define jolla_store in that07:09
rinigusanyway, you would need separate RPM for it07:09
poetasterrinigus: the reference to the solution for the PIL + c deps is:
poetasterrinigus: I just often don't understand what the pro file does vis. spec.07:12
riniguspoetaster: in this context, consider SPEC as bash script building and installing your package. PRO (or CMake analog) is what makes Makefile to build it07:13
rinigusreading that discussion, just copy those .so files as well into your libs. RPATH should be set automatically.07:14
rinigusone more solution: pull out of harbour07:14
riniguspoetaster: ^07:14
poetasterrinigus: then I might as well pull out of SFOS. I have users asking for aarch64 packages. store and openrepos.07:15
riniguspoetaster: harbour != sfos. but ok, if you wish to keep it in harbour, then just copy those libs07:16
rinigusas a part of SPEC install phase.07:16
poetasterrinigus: I feel it is important to support jolla. I get a very strong feeling you do not feel that way.07:17
poetasterrinigus: in any case, if I can go the requires root with copying, it's all good. I can please everyone.07:18
riniguspoetaster: I am not going to break my neck to get apps into Jolla Store. if it gets on the way of app development due to its rules, I prefer to develop and rely on OpenRepos / Chum. nothing to do with Jolla as such, it is their store => their rules.07:18
rinigussee example for copying in pure maps:
poetasterrinigus: where is jollastore defined?07:21
riniguspoetaster: in the project definition, similar to vendor at chum. so, you have to define it yourself in your OBS project07:24
poetasterrinigus: ok, got it.07:24
rinigusgood luck!07:25
poetasterrinigus: thanks. no luck needed, there are working examples :)07:26
riniguspoetaster: indeed. mainly patience07:27
poetasterrinigus: being stubborn also helps .07:27
poetasterrinigus: why did you chose clickable for ubuntu touch?07:41
riniguspoetaster: was selected by developer who packaged it. years ago07:45
poetasterrinigus: ah. it's a nice example of dealing with a lot of complexity + multiple dists. fahrplan is also not bad, but completely different.07:49
poetasterrinigus: do you actually have a qt creator file for pure-maps?07:52
riniguspoetaster: its cmake, yes I do07:52
rinigusused to be .pro, but got ported by another dev to cmake07:53
poetasterrinigus. ok, sorry, I've had to go in the other direction :) the one c++ library I use I ported to qmake ;)07:54
poetasterrinigus: but that library is 'wip' in the extreme. I really need to get up to speed on cmake.07:56
poetasterbut I'm not even up to speed on qmake++07:57
poetasterrinigus: I thought (well, use) {_libdir} as /usr/lib so I don't get how your jollastore copy of MapboxMap works.08:47
poetasterfrom the link you sent me (L126) ...08:48
poetasterdamn it. I'm screwed without an aarch64 device. ok. breathe.08:48
riniguspoetaster: `%{_libdir}` is /usr/lib64 on aarch64 device. so, you will be fine08:50
poetastersorry, I meant libdir in the context of copying like you do with qml/MapboxMap08:51
riniguspoetaster: you mean dir in /usr/share/appname? that one is plain `lib`08:52
poetasterrinigus: the last line is a reflection of my frustration that I can't test the build. should work.08:52
poetasterI was asuuming you supply the Mapbox data?08:52
riniguspoetaster: well, users will test and report back. it is a two-way street08:53
riniguspoetaster: no, it is QML and lib bits for mapboxqml plugin08:53
rinigusfor libs, see line 12708:53
poetasterrinigus: I don't get where the files are coming from. I have a spec where: 1. I use install to copy existing files into app/lib 2. I use the pro python files approach to ALSO copy files into app/lib08:56
poetasterrinigus:* comes from where?08:57
riniguspoetaster: let's make it more specific. which files?08:57
rinigus(crossposting, just a sec)08:57
riniguspoetaster: from Line 4708:58
poetasterOk, so first package install, then copy. got it.08:58
poetasterI have a bit too much stuff in the pro file.08:59
riniguspoetaster: that's if you need to include it into your package. then you add it as buildrequires as it becomes a part of your build.08:59
rinigusnotice that for chum, same is added as requires above (line 45)09:00
rinigusI propose to do the same for pil09:00
riniguspoetaster: ^09:00
poetasterrinigus: yes, that's what I'm working toward. problem is, can't test.09:00
poetasterI hate commiting code I can't test.09:01
riniguspoetaster: if it works on arm32, it will work on aarch64 as well. if it doesn't, you will get notified by users and will be able to fix it09:01
poetasterrinigus: That's a very slow iterative loop.09:04
poetasterif only I could flash piggz aarch64 image.09:05
riniguspoetaster: the one that works better than stalling on "cannot test" :)09:05
poetasterI ended up installing ubuntu touch just to justify having spent 2 hours failing to flash sfos 4.109:05
poetasterrinigus: I'm not stalling, I'm counting the cash. I didn't spend as much on vacation so, ...09:06
riniguswell, excuse to get new device is always there :)09:06
poetasterrinigus: I'll start by building the spec for chum and then I'll ask in the forum if someone is able to test.09:07
poetasterrinigus: why is  arch-dependent-file-in-usr-share (Badness: 590) this the 'Badness'?09:11
riniguspoetaster: adopt
rinigusstart with only arch-... one, see if you need the rest09:13
poetastersorry, I'm on obs now09:13
poetasterI'm embarrassed to be the failing package:
poetasterdamn. 3.4 python-imaging, 4.1 python3-imaging ... wonder if it's aliased.09:15
riniguspoetaster: lbt added `%sailfishos_version` macro for latest SFOS releases. see line 3 in
rinigusunfortunately, I don't think it was done for all older releases09:22
lbthmmm - we should do that09:22
riniguspoetaster: idea is that you could then add buildrequires depending on SFOS version09:23
riniguslbt: at least for those covered by chum, please09:23
riniguslbt: I wonder if new OBS handle requires as "python-imaging || python3-imaging"?09:25
lbtI don't think this version does09:26
poetasterrinigus: I just branched one package to deal with this. And it means I can keep my 3.4 workflow clean.09:26
poetasterwhere do I set the chum vendor flag again? project conig?09:27
riniguslbt: pity09:29
riniguslbt: but OK09:29
poetasterrinigus: thanks.09:29
lbtwhy do you need to branch to deal with Requires ?09:30
lbtI mean if we have sailfishos_version macro09:30
poetasterlbt: I'm branching because I want to maintain a spec file that works in a completely different way09:30
poetasterlbt: and it happens to correspond with a change that suits obs AND aarch64 devices.09:31
poetaster3.4/4.1 is kind of a watershed, branch moment, or?09:31
riniguslbt: don't think that branch is needed. but Jolla-Store specific project is needed to be able to compile package with bundled dependencies. for chum version, we can have requires in the package, something that is not allowed for store09:33
poetasterlbt: where is the macro defined?09:33
lbtin the prjconf ..see ^^09:33
poetasterlbt: thanks09:34
poetasterlbt: what values for sailfishos_version ? 3.4.? 4.1?10:03
poetaster3.4.0, 4.1.0 I think10:05
lbt30400  4010010:05
lbtok 30100 30201 30300 30400 40001 40100 are all defined now rinigus10:10
lbtthat covers all the chum targets10:10
poetasterlbt: thanks.10:26
poetasterlbt: so %if "%_sailfish_version" == 40100 ?10:27
lbtuse {} too10:29
lbta discussion on WTF in macros10:29
lbtas you can see I commented there in 2012 ... and still refer back to it today ;)10:32
poetasteryes. .spec files are insane and rpms ... are now well documented and insane :)10:33
poetasterlbt: this seems eviL %if "%{sailfish_version}" < "40000"10:36
poetasterlbt: I'm ignoring the is defined question for the time being.10:37
riniguslbt: thank you very much!!!10:47
poetasterit's beginning to look a lot like christmas.10:47
poetasterlbt: now I'm confused. I branched, removed cruft, rebuilt pro and spec and it still seems old build is being used?11:01
poetasterah, do It's pulling 1.1 instead of 1.1-211:02
poetasterI don't get it.11:03
poetasterlbt,rinigus:  what am I doing wrong. I suppllied 757bbf2 and still the wrong release files are being pulled. I specified branch11:05
poetastergood thing I branched :)11:07
riniguspoetaster: start with using correct version numbers - do not use `-` in them11:07
poetasterthere is no such thing as correct versioning. but I tried both.11:08
riniguspoetaster: don't see that commit while going through SFOS-4.1 branch. or did I just miss it?11:08
rinigusre versioning: use 1.1.211:09
poetasterrinigus, yes, yes, but it's not relevant.11:09
riniguspoetaster: so, but where do you see that it is not pulled?11:10
rinigusSPEC seems to be for that version11:10
rinigus(as you stated version is irrelevant you cannot use argument that .tbz2 has 1.1 as a version) :)11:11
riniguspoetaster: ^11:11
poetasteroh, where is that!11:13
poetasterwell it's working now.11:13
poetasterlooks like I had to kick it. I had switched from _service specifying 1.1-2 to the commit, but it still pulled 1.1.11:14
poetasterok. so now it's built. who knows if it works. maybe.11:15
riniguspoetaster: test your version and then let's push it to chum11:15
rinigusthen users can test11:15
poetasterrinigus: since this is a python thing, I might just be able to install the aarch64 on my volla11:16
poetasterrinigus, I am a user. I use that app. I wanna test it. And i don't trust user feedback :)11:16
poetasterfirst, try the 3.4 build.11:17
poetasterrinigus: looks promising. it's not as fast as the lib I included with 3.4 but it's version 8 as of 4.x SFOS so who knows.11:22
poetasterrinigus: well, it sort of works ;)11:23
poetasterrinigus: ah shit. broken, broken. but this is from testing. how do I make sure it's not availlable.11:27
riniguspoetaster: things in :chum:testing can be broken no problem. it is for testing after all11:28
rinigussame goes with the ports - we have devel projects for that11:29
poetasterrinigus: thought so, but I get jumpy when things are broken. that's why I don't actually like automated ci pipelines.11:29
poetasterAH, but a user reports that my simple fix works for aarch64.11:30
riniguspoetaster: relax and enjoy the process. :)11:31
poetasterrinigus: sigh, out of time. ah well ... later! thanks for the help11:32
rinigusyou're welcome11:33
poetasterrinigus: just got a mail that the route I've implemented on chum works with 4.x. But as I've seen it will not work with 3.4. PIL is too old.12:03
poetasterhmmm. hmmm. hmmm.12:03
riniguspoetaster: which is an issue, indeed. for some packages I decided to drop support for older releases. but you may wish to support them still...12:05
rinigusin principle, you could package PIL using Jolla's packaging work, but then we get into chum politics regarding distribution of libs that are in SFOS already. so far, I though we can avoid it12:06
riniguspiggz: ^12:06
poetasterrinigus: the PIL in 3.4 is python2.7 and very old. the PIL in 4.x is python3 and recent.12:07
poetasterrinigus: to do this clean, it looks like I'll have to rebuild this as a subdirs project and then do some copy stuff in the specs12:08
poetastercurses. foiled again.12:09
riniguspoetaster: or package newer PIL for older SFOS. ideally with the name that wouldn't clash with SFOS provided one. if we all agree that it is a correct way to do so12:09
riniguslet's see what piggz can add12:10
poetasterrinigus: ok. since the newer version is python3, this could probably be done. my sony aarch64 tester says the sfos lib works fine in 4.x12:11
poetasterlbt: judging by this:
poetasterlbt: %if "%{sailfish_version}" < "40000" does not work.13:34
riniguspoetaster: try sailfishos_version (notice the difference)13:55
poetasterach, veh.14:13
poetastertypo. of course.14:13
poetaster(multi-tasking, too many terminals)14:14
poetasterrinigus: that worked, of course. Now to find a victim to test the build.14:24
poetasterrinigus: the aarch64 packages of simplecrop 'just work' yipee!16:58
poetastercool. ich only I had an aarch64 device. piggz!17:03
riniguspoetaster: now you have to decide whether to ditch older versions due to PIL ...17:10
poetasterrinigus: I'm thinking, maintain 2 branches, restrict the chum build to archs that will build without nonsense.17:28
poetasterrinigus: use the original branch to maintain the older releases 'by hand'17:28
poetasterrinigus: it's a pain, but won't last for ever.17:28
poetasterbut first, some bug fixes so that the next release isn't just meta!17:29
poetasterrinigus: the pragmatic approach would lead me to say, reduce the target archs in chum to 4.x17:46
poetasterrinigus: do the releases for 3.4 in stor and open manually until I can get the library build integrated.17:47
riniguspoetaster: sounds fine - I think it makes sense17:48
poetasterrinigus: ok, I'll remove the stuff I can't support for now and chum has a new (and improved!) pkg.17:49
poetastervideoworks is gonna kill me.17:49
riniguspoetaster: when ready, submit the package at OBS from :testing to :chum17:50
poetasterwill do.17:50
poetasterbtw: I managed to re-animate the original developer. you can raise the dead!17:50
poetastercool, but it's just thanks to whoever packaged PIL 8.x for SFOS. I'm just pushing bits. I need to go to the basement and play my rhodes.18:04
poetasteroh, how I miss those days, ignorant and mindlessly pushing bits on a vax mainframe, unawares that I had signed my own sentence ....18:05
poetasterrinigus: damn, made an error, please ignore the machine.18:09
riniguspoetaster: so, should I reject your submit request at OBS? was that with some error?18:53
poetasterrinigus: well, I corrected it. but I don't know if the request is coupled to the build before.18:57
poetasterdamn it.18:58
riniguspoetaster: it is. so I will deny it and make a new one for you18:58
poetasteri'll do it.18:58
poetasterdamn it. why doesn't it pull the new spec!19:00
riniguspoetaster: done. if something is wrong in please submit update from chum:testing19:01
poetasterrinigus: sorry, I don't get it. the spec file is not being pulled. do I really have to bump the release?19:02
riniguspoetaster: see "revision" in _service. you have to have matching commit or release19:03
poetasterI modified the spec. I commited, pushed. I refreshed the release, I edited the _service file....19:03
poetasteryes, but it seems to be 'caching' oh, I've seen 1.1.3 before, nothing to do here.19:04
poetasterrinigus: ok, the trick is, treat it like a web hook. leave release blank and ... sigh.19:06
riniguspoetaster: in your :testing - e825ced is from 5 hours ago19:06
poetasterrinigus: yes, and I wanted it to resync. doesn't appear to work?19:07
poetasterrinigus: but releases can be 'altered'19:07
riniguspoetaster: before I forget - your package is named "Imageworks repository". what should it be?19:08
poetasterrinigus: Name, Title, Package Name, what 'field' are you referring too?19:08
riniguspoetaster: back to sync - how do you see that it does not resync? based on what? looking at SPEC, it is as old as your commit e825ced19:08
riniguspoetaster: title at OBS page19:09
rinigusas in
poetastersooooo, if you discover an error (in this case it was the Release:    1 in spec) and your want to correct it in the release (e825ced aka 1.1.3) how do you get the new spec with the SAME release into obs?19:11
rinigusOK, never mind the name. had simplecrop in my mind.19:11
poetasterobs has very aggressive caching.19:11
poetasterobs will force me to version bump. wtf.19:12
poetastersorry. I got it. hit Trigger Services?19:12
riniguspoetaster: you can also remove release and tag from github and define it again19:12
rinigusin github. but I still don't understand what do you want to achieve19:13
poetasterrinigus: that's what I did. but the spec file did not update. I just hit Trigger and am watching with baited breath.19:13
poetasterrinigus: f*** now that's aggresive caching.19:13
poetasterummm. this is a design flaw. I should be writing code and not babysitting a f****** build system.19:14
poetastersorry, not your fault ... LBT... where are you!19:14
riniguspoetaster: I see that still points to e825ced. what is it expected to point to?19:14
poetasterrinigus: I literally deleted the release and recreated it.19:15
riniguspoetaster: which commit is it expected to point to?19:16
poetasterrinigus: sec, I'm testing a theory.19:16
poetasterrinigus: it'f F***** github.19:18
riniguspoetaster: you have to remove release and tag, both19:19
poetasterrinigus: a tag that is used only in the context of the release. well, so much for 'ai'.19:20
poetasteroh. god.19:20
poetaster! how the hell do I get rid of this crud. oh. dear.19:21
poetasterrinigus: sorry, I didn't believe that github could be so 'thick'. you can't remove the tags. so, the release is effectivly omnipotent. idempotent making me impotent. tsk. tsk. tsk.19:22
riniguspoetaster: you can remove tags as well. click on tag and there will be an option19:23
poetasterah. you can delete them. fuck. what a ridiculous interface. the option to delete is ONLY shown when you click on the tag. which looks identical to the release.19:23
poetasterwho the hell designed this ! some dark patterns idiot!19:24
poetasterrinigus: ok. so, sorry, obs is doing this correctly and github is being very 'Stepmotherly' conservative and has a deffects in exposing simple ui.19:25
rinigusno problem - so, I just retrigger builds in :chum?19:26
poetasterrinigus: and now I hit the wrong branch :) that was me. all me. me.19:26
poetasterwait for it.19:26
riniguswill do. although, will be afk very soon and can probably trigger rebuild in sfos:chum only tomorrow morning19:29
poetasterrinigus: go for it. I have to bring my son to bed :)19:29
poetasterit's all good. thanks for your patience.19:29
riniguspoetaster: done19:30

Generated by 2.17.1 by Marius Gedminas - find it at!