| rinigus | poetaster : that line 42 is indeed what makes it work. You could do the same with dropping 'auto' and using plane setup. | 05:00 |
|---|---|---|
| poetaster | rinigus: 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 |
| poetaster | rinigus: that obscures how to use the spec + git. | 06:33 |
| rinigus | poetaster: should work from SDK as well, just login into it (ssh) and make sure you clone repo recursively in git. | 06:35 |
| poetaster | rinigus: I'm not sure of the workflow. You lost me at log in to it. you mean the build engine image? | 06:36 |
| poetaster | rinigus: I want to build a pro file (probably a bad idea) that collects the depends. so, I guess subdirs style. | 06:37 |
| poetaster | rinigus: oh, you're just saying, clone the repo recursively into the {root} of my project/lib context? | 06:38 |
| rinigus | poetaster: ssh into build engine for building and use `mb2 -t xxxx build` | 06:54 |
| rinigus | as for dependencies, it is hard to judge. I guess it is case specific. what do you want to build? | 06:55 |
| rinigus | poetaster: ^ | 06:55 |
| poetaster | rinigus: it's still about imageworks (harbour-simplecrop). My c++ projects I've managed to get library builds 'local'. But this is python+c | 06:57 |
| rinigus | poetaster: 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 |
| poetaster | rinigus: not in harbour. | 06:58 |
| rinigus | poetaster: forget about harbour for a sec. would it work for chum/openrepos? | 06:59 |
| poetaster | rinigus: I've tried once and it failed, but I'll try again (Requires python3-imaging failed) | 07:00 |
| poetaster | rinigus: assuming you mean: 'Requires: python3-imaging' in spec | 07:00 |
| rinigus | poetaster: try to make it work for chum/openrepos and then let's see how to make it for harbour. | 07:00 |
| rinigus | poetaster: yes, that Requires should be it. not sure about package | 07:01 |
| rinigus | you will have to check if that Requires leads to the lib which you can import in python | 07:01 |
| poetaster | If the requires pulls, it will work. I had a third party verify that zypper installing on device (aarch64) works. | 07:02 |
| rinigus | poetaster: it does pull | 07:02 |
| rinigus | now 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 |
| rinigus | for 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 python | 07:04 |
| poetaster | works with the expected ERROR [python3-imaging] Dependency not allowed | 07:04 |
| rinigus | poetaster: ^ | 07:04 |
| rinigus | poetaster: is that ERROR in SDK and it is refusing to build RPM or it is just blabbing by lint? | 07:05 |
| poetaster | rinigus: sorry, just lint. not important | 07:05 |
| rinigus | poetaster: OK, so for chum and openrepos you could use that SPEC. we would need now just to add harbour bits | 07:06 |
| poetaster | rinigus: the problem with PIL is the c depends. But, martyone's workaround on arm will probably work. | 07:06 |
| rinigus | use that jolla_store macro (or similar) and add sections for harbour vs chum. in chum, keep Requires. in harbour, add BuildRequires: python3-imaging instead | 07:07 |
| rinigus | and start copying files as a part of install in SPEC (for harbour) | 07:07 |
| rinigus | poetaster: ^ | 07:08 |
| poetaster | rinigus: using 'vendor' flag. | 07:08 |
| rinigus | you can do that instead, indeed. | 07:08 |
| rinigus | but I would recommend to setup in OBS a project for harbour and just define jolla_store in that | 07:09 |
| rinigus | anyway, you would need separate RPM for it | 07:09 |
| poetaster | rinigus: the reference to the solution for the PIL + c deps is: https://forum.sailfishos.org/t/application-sdk-bash-sdk-deploy-rpm-command-not-found/5743/26?u=poetaster | 07:10 |
| poetaster | rinigus: I just often don't understand what the pro file does vis. spec. | 07:12 |
| rinigus | poetaster: in this context, consider SPEC as bash script building and installing your package. PRO (or CMake analog) is what makes Makefile to build it | 07:13 |
| rinigus | reading that discussion, just copy those .so files as well into your libs. RPATH should be set automatically. | 07:14 |
| rinigus | one more solution: pull out of harbour | 07:14 |
| rinigus | poetaster: ^ | 07:14 |
| poetaster | rinigus: then I might as well pull out of SFOS. I have users asking for aarch64 packages. store and openrepos. | 07:15 |
| rinigus | poetaster: harbour != sfos. but ok, if you wish to keep it in harbour, then just copy those libs | 07:16 |
| rinigus | as a part of SPEC install phase. | 07:16 |
| poetaster | rinigus: I feel it is important to support jolla. I get a very strong feeling you do not feel that way. | 07:17 |
| poetaster | rinigus: in any case, if I can go the requires root with copying, it's all good. I can please everyone. | 07:18 |
| rinigus | poetaster: 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 |
| rinigus | see example for copying in pure maps: https://github.com/rinigus/pure-maps/blob/master/rpm/harbour-pure-maps.spec#L125 | 07:19 |
| poetaster | thanks! | 07:20 |
| poetaster | rinigus: where is jollastore defined? | 07:21 |
| rinigus | poetaster: in the project definition, similar to vendor at chum. so, you have to define it yourself in your OBS project | 07:24 |
| poetaster | rinigus: ok, got it. | 07:24 |
| rinigus | good luck! | 07:25 |
| poetaster | rinigus: thanks. no luck needed, there are working examples :) | 07:26 |
| rinigus | poetaster: indeed. mainly patience | 07:27 |
| poetaster | rinigus: being stubborn also helps . | 07:27 |
| poetaster | rinigus: why did you chose clickable for ubuntu touch? | 07:41 |
| rinigus | poetaster: was selected by developer who packaged it. years ago | 07:45 |
| poetaster | rinigus: 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 |
| poetaster | rinigus: do you actually have a qt creator file for pure-maps? | 07:52 |
| rinigus | poetaster: its cmake, yes I do | 07:52 |
| rinigus | used to be .pro, but got ported by another dev to cmake | 07:53 |
| poetaster | rinigus. ok, sorry, I've had to go in the other direction :) the one c++ library I use I ported to qmake ;) | 07:54 |
| poetaster | rinigus: but that library is 'wip' in the extreme. I really need to get up to speed on cmake. | 07:56 |
| poetaster | but I'm not even up to speed on qmake++ | 07:57 |
| poetaster | rinigus: I thought (well, use) {_libdir} as /usr/lib so I don't get how your jollastore copy of MapboxMap works. | 08:47 |
| poetaster | from the link you sent me (L126) ... | 08:48 |
| poetaster | damn it. I'm screwed without an aarch64 device. ok. breathe. | 08:48 |
| rinigus | poetaster: `%{_libdir}` is /usr/lib64 on aarch64 device. so, you will be fine | 08:50 |
| poetaster | sorry, I meant libdir in the context of copying like you do with qml/MapboxMap | 08:51 |
| rinigus | poetaster: you mean dir in /usr/share/appname? that one is plain `lib` | 08:52 |
| poetaster | rinigus: the last line is a reflection of my frustration that I can't test the build. should work. | 08:52 |
| poetaster | https://github.com/rinigus/pure-maps/blob/master/rpm/harbour-pure-maps.spec#L126 | 08:52 |
| poetaster | I was asuuming you supply the Mapbox data? | 08:52 |
| rinigus | poetaster: well, users will test and report back. it is a two-way street | 08:53 |
| rinigus | poetaster: no, it is QML and lib bits for mapboxqml plugin | 08:53 |
| rinigus | for libs, see line 127 | 08:53 |
| poetaster | rinigus: 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/lib | 08:56 |
| poetaster | rinigus: libqmapboxgl.so.1* comes from where? | 08:57 |
| rinigus | poetaster: let's make it more specific. which files? | 08:57 |
| rinigus | (crossposting, just a sec) | 08:57 |
| rinigus | poetaster: from Line 47 | 08:58 |
| rinigus | BuildRequires | 08:58 |
| poetaster | Ok, so first package install, then copy. got it. | 08:58 |
| poetaster | I have a bit too much stuff in the pro file. | 08:59 |
| rinigus | poetaster: 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 |
| rinigus | notice that for chum, same is added as requires above (line 45) | 09:00 |
| rinigus | I propose to do the same for pil | 09:00 |
| rinigus | poetaster: ^ | 09:00 |
| poetaster | rinigus: yes, that's what I'm working toward. problem is, can't test. | 09:00 |
| poetaster | I hate commiting code I can't test. | 09:01 |
| rinigus | poetaster: 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 it | 09:01 |
| poetaster | rinigus: That's a very slow iterative loop. | 09:04 |
| poetaster | if only I could flash piggz aarch64 image. | 09:05 |
| rinigus | poetaster: the one that works better than stalling on "cannot test" :) | 09:05 |
| poetaster | I ended up installing ubuntu touch just to justify having spent 2 hours failing to flash sfos 4.1 | 09:05 |
| poetaster | rinigus: I'm not stalling, I'm counting the cash. I didn't spend as much on vacation so, ... | 09:06 |
| rinigus | well, excuse to get new device is always there :) | 09:06 |
| poetaster | rinigus: 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 |
| poetaster | rinigus: why is arch-dependent-file-in-usr-share (Badness: 590) this the 'Badness'? | 09:11 |
| rinigus | poetaster: adopt https://github.com/rinigus/pure-maps/blob/master/rpm/harbour-pure-maps-rpmlintrc | 09:12 |
| rinigus | start with only arch-... one, see if you need the rest | 09:13 |
| poetaster | sorry, I'm on obs now | 09:13 |
| poetaster | I'm embarrassed to be the failing package: https://build.sailfishos.org/package/live_build_log/sailfishos:chum:testing/harbour-simplecrop/3.1.0.12_armv7hl/armv8el | 09:14 |
| poetaster | damn. 3.4 python-imaging, 4.1 python3-imaging ... wonder if it's aliased. | 09:15 |
| rinigus | poetaster: lbt added `%sailfishos_version` macro for latest SFOS releases. see line 3 in https://build.sailfishos.org/project/prjconf/sailfishos:4.1.0.24 | 09:22 |
| rinigus | unfortunately, I don't think it was done for all older releases | 09:22 |
| lbt | hmmm - we should do that | 09:22 |
| rinigus | poetaster: idea is that you could then add buildrequires depending on SFOS version | 09:23 |
| rinigus | lbt: at least for those covered by chum, please | 09:23 |
| poetaster | hmmm. | 09:25 |
| rinigus | lbt: I wonder if new OBS handle requires as "python-imaging || python3-imaging"? | 09:25 |
| lbt | I don't think this version does | 09:26 |
| poetaster | rinigus: I just branched one package to deal with this. And it means I can keep my 3.4 workflow clean. | 09:26 |
| poetaster | where do I set the chum vendor flag again? project conig? | 09:27 |
| rinigus | poetaster: https://build.sailfishos.org/project/prjconf/sailfishos:chum | 09:29 |
| rinigus | lbt: pity | 09:29 |
| rinigus | lbt: but OK | 09:29 |
| poetaster | rinigus: thanks. | 09:29 |
| lbt | why do you need to branch to deal with Requires ? | 09:30 |
| lbt | I mean if we have sailfishos_version macro | 09:30 |
| poetaster | lbt: I'm branching because I want to maintain a spec file that works in a completely different way | 09:30 |
| poetaster | lbt: and it happens to correspond with a change that suits obs AND aarch64 devices. | 09:31 |
| lbt | np | 09:31 |
| poetaster | 3.4/4.1 is kind of a watershed, branch moment, or? | 09:31 |
| rinigus | lbt: 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 store | 09:33 |
| poetaster | lbt: where is the macro defined? | 09:33 |
| lbt | in the prjconf ..see ^^ | 09:33 |
| poetaster | lbt: thanks | 09:34 |
| poetaster | lbt: what values for sailfishos_version ? 3.4.? 4.1? | 10:03 |
| poetaster | 3.4.0, 4.1.0 I think | 10:05 |
| lbt | 30400 40100 | 10:05 |
| lbt | ok 30100 30201 30300 30400 40001 40100 are all defined now rinigus | 10:10 |
| lbt | that covers all the chum targets | 10:10 |
| poetaster | lbt: thanks. | 10:26 |
| poetaster | lbt: so %if "%_sailfish_version" == 40100 ? | 10:27 |
| lbt | use {} too | 10:29 |
| lbt | https://backreference.org/2011/09/17/some-tips-on-rpm-conditional-macros/ | 10:29 |
| poetaster | bashism? | 10:29 |
| lbt | a discussion on WTF in macros | 10:29 |
| poetaster | thanks | 10:29 |
| lbt | as you can see I commented there in 2012 ... and still refer back to it today ;) | 10:32 |
| poetaster | yes. .spec files are insane and rpms ... are now well documented and insane :) | 10:33 |
| poetaster | lbt: this seems eviL %if "%{sailfish_version}" < "40000" | 10:36 |
| poetaster | lbt: I'm ignoring the is defined question for the time being. | 10:37 |
| rinigus | lbt: thank you very much!!! | 10:47 |
| poetaster | it's beginning to look a lot like christmas. | 10:47 |
| poetaster | lbt: now I'm confused. I branched, removed cruft, rebuilt pro and spec and it still seems old build is being used? | 11:01 |
| poetaster | ah, do It's pulling 1.1 instead of 1.1-2 | 11:02 |
| poetaster | I don't get it. | 11:03 |
| poetaster | lbt,rinigus: what am I doing wrong. I suppllied 757bbf2 and still the wrong release files are being pulled. I specified branch | 11:05 |
| poetaster | https://build.sailfishos.org/package/show/sailfishos:chum:testing/harbour-simplecrop | 11:05 |
| poetaster | good thing I branched :) | 11:07 |
| rinigus | poetaster: start with using correct version numbers - do not use `-` in them | 11:07 |
| poetaster | 757bbf2 | 11:07 |
| poetaster | there is no such thing as correct versioning. but I tried both. | 11:08 |
| rinigus | poetaster: don't see that commit while going through SFOS-4.1 branch. or did I just miss it? | 11:08 |
| rinigus | re versioning: use 1.1.2 | 11:09 |
| poetaster | https://github.com/poetaster/harbour-simplecrop/commit/757bbf26c254f5ea50a88cf87e7cff13a4bfd53a | 11:09 |
| poetaster | rinigus, yes, yes, but it's not relevant. | 11:09 |
| rinigus | poetaster: so, but where do you see that it is not pulled? | 11:10 |
| rinigus | SPEC seems to be for that version | 11:10 |
| rinigus | (as you stated version is irrelevant you cannot use argument that .tbz2 has 1.1 as a version) :) | 11:11 |
| rinigus | poetaster: ^ | 11:11 |
| poetaster | oh, where is that! | 11:13 |
| poetaster | well it's working now. | 11:13 |
| poetaster | looks 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 |
| poetaster | ok. so now it's built. who knows if it works. maybe. | 11:15 |
| rinigus | poetaster: test your version and then let's push it to chum | 11:15 |
| rinigus | then users can test | 11:15 |
| poetaster | rinigus: since this is a python thing, I might just be able to install the aarch64 on my volla | 11:16 |
| poetaster | rinigus, I am a user. I use that app. I wanna test it. And i don't trust user feedback :) | 11:16 |
| poetaster | first, try the 3.4 build. | 11:17 |
| poetaster | rinigus: 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 |
| poetaster | rinigus: well, it sort of works ;) | 11:23 |
| poetaster | rinigus: ah shit. broken, broken. but this is from testing. how do I make sure it's not availlable. | 11:27 |
| rinigus | poetaster: things in :chum:testing can be broken no problem. it is for testing after all | 11:28 |
| rinigus | same goes with the ports - we have devel projects for that | 11:29 |
| poetaster | rinigus: thought so, but I get jumpy when things are broken. that's why I don't actually like automated ci pipelines. | 11:29 |
| poetaster | AH, but a user reports that my simple fix works for aarch64. | 11:30 |
| rinigus | poetaster: relax and enjoy the process. :) | 11:31 |
| poetaster | rinigus: sigh, out of time. ah well ... later! thanks for the help | 11:32 |
| rinigus | you're welcome | 11:33 |
| poetaster | rinigus: 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 |
| poetaster | hmmm. hmmm. hmmm. | 12:03 |
| rinigus | poetaster: 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 |
| rinigus | in 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 it | 12:06 |
| rinigus | piggz: ^ | 12:06 |
| poetaster | rinigus: the PIL in 3.4 is python2.7 and very old. the PIL in 4.x is python3 and recent. | 12:07 |
| poetaster | rinigus: 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 specs | 12:08 |
| poetaster | curses. foiled again. | 12:09 |
| rinigus | poetaster: 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 so | 12:09 |
| rinigus | let's see what piggz can add | 12:10 |
| poetaster | rinigus: ok. since the newer version is python3, this could probably be done. my sony aarch64 tester says the sfos lib works fine in 4.x | 12:11 |
| poetaster | lbt: judging by this: https://build.sailfishos.org/package/binary/sailfishos:chum:testing/harbour-simplecrop?arch=aarch64&filename=harbour-simplecrop-1.1.2-1.6.1.jolla.aarch64.rpm&repository=4.1.0.24_aarch64 | 13:34 |
| poetaster | lbt: %if "%{sailfish_version}" < "40000" does not work. | 13:34 |
| rinigus | poetaster: try sailfishos_version (notice the difference) | 13:55 |
| poetaster | ach, veh. | 14:13 |
| poetaster | thanks | 14:13 |
| poetaster | typo. of course. | 14:13 |
| poetaster | (multi-tasking, too many terminals) | 14:14 |
| poetaster | rinigus: that worked, of course. Now to find a victim to test the build. | 14:24 |
| poetaster | rinigus: the aarch64 packages of simplecrop 'just work' yipee! | 16:58 |
| poetaster | cool. ich only I had an aarch64 device. piggz! | 17:03 |
| rinigus | poetaster: now you have to decide whether to ditch older versions due to PIL ... | 17:10 |
| poetaster | rinigus: I'm thinking, maintain 2 branches, restrict the chum build to archs that will build without nonsense. | 17:28 |
| poetaster | rinigus: use the original branch to maintain the older releases 'by hand' | 17:28 |
| poetaster | rinigus: it's a pain, but won't last for ever. | 17:28 |
| poetaster | but first, some bug fixes so that the next release isn't just meta! | 17:29 |
| poetaster | rinigus: the pragmatic approach would lead me to say, reduce the target archs in chum to 4.x | 17:46 |
| poetaster | rinigus: do the releases for 3.4 in stor and open manually until I can get the library build integrated. | 17:47 |
| rinigus | poetaster: sounds fine - I think it makes sense | 17:48 |
| poetaster | rinigus: ok, I'll remove the stuff I can't support for now and chum has a new (and improved!) pkg. | 17:49 |
| poetaster | videoworks is gonna kill me. | 17:49 |
| rinigus | poetaster: when ready, submit the package at OBS from :testing to :chum | 17:50 |
| poetaster | will do. | 17:50 |
| poetaster | btw: I managed to re-animate the original developer. you can raise the dead! | 17:50 |
| poetaster | cool, 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 |
| poetaster | oh, how I miss those days, ignorant and mindlessly pushing bits on a vax mainframe, unawares that I had signed my own sentence .... | 18:05 |
| poetaster | rinigus: damn, made an error, please ignore the machine. | 18:09 |
| rinigus | poetaster: so, should I reject your submit request at OBS? was that with some error? | 18:53 |
| poetaster | rinigus: well, I corrected it. but I don't know if the request is coupled to the build before. | 18:57 |
| poetaster | damn it. | 18:58 |
| rinigus | poetaster: it is. so I will deny it and make a new one for you | 18:58 |
| poetaster | i'll do it. | 18:58 |
| poetaster | damn it. why doesn't it pull the new spec! | 19:00 |
| rinigus | poetaster: done. if something is wrong in https://build.merproject.org/package/show/sailfishos:chum/harbour-simplecrop please submit update from chum:testing | 19:01 |
| poetaster | rinigus: sorry, I don't get it. the spec file is not being pulled. do I really have to bump the release? | 19:02 |
| rinigus | poetaster: see "revision" in _service. you have to have matching commit or release | 19:03 |
| poetaster | I modified the spec. I commited, pushed. I refreshed the release, I edited the _service file.... | 19:03 |
| poetaster | yes, but it seems to be 'caching' oh, I've seen 1.1.3 before, nothing to do here. | 19:04 |
| poetaster | rinigus: ok, the trick is, treat it like a web hook. leave release blank and ... sigh. | 19:06 |
| rinigus | poetaster: in your :testing - e825ced is from 5 hours ago | 19:06 |
| poetaster | rinigus: yes, and I wanted it to resync. doesn't appear to work? | 19:07 |
| poetaster | rinigus: but releases can be 'altered' | 19:07 |
| rinigus | poetaster: before I forget - your package is named "Imageworks repository". what should it be? | 19:08 |
| poetaster | rinigus: Name, Title, Package Name, what 'field' are you referring too? | 19:08 |
| rinigus | poetaster: 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 e825ced | 19:08 |
| rinigus | poetaster: title at OBS page | 19:09 |
| poetaster | Imageworks | 19:09 |
| rinigus | as in https://build.merproject.org/package/edit/sailfishos:chum:testing/harbour-simplecrop?spec_count=0 | 19:09 |
| poetaster | sooooo, 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 |
| rinigus | OK, never mind the name. had simplecrop in my mind. | 19:11 |
| poetaster | obs has very aggressive caching. | 19:11 |
| poetaster | obs will force me to version bump. wtf. | 19:12 |
| poetaster | sorry. I got it. hit Trigger Services? | 19:12 |
| rinigus | poetaster: you can also remove release and tag from github and define it again | 19:12 |
| rinigus | in github. but I still don't understand what do you want to achieve | 19:13 |
| poetaster | rinigus: that's what I did. but the spec file did not update. I just hit Trigger and am watching with baited breath. | 19:13 |
| poetaster | rinigus: f*** now that's aggresive caching. | 19:13 |
| poetaster | ummm. this is a design flaw. I should be writing code and not babysitting a f****** build system. | 19:14 |
| poetaster | sorry, not your fault ... LBT... where are you! | 19:14 |
| rinigus | poetaster: I see that https://github.com/poetaster/harbour-simplecrop/releases/tag/1.1.3 still points to e825ced. what is it expected to point to? | 19:14 |
| poetaster | rinigus: I literally deleted the release and recreated it. | 19:15 |
| rinigus | poetaster: which commit is it expected to point to? | 19:16 |
| poetaster | rinigus: sec, I'm testing a theory. | 19:16 |
| poetaster | rinigus: it'f F***** github. | 19:18 |
| rinigus | poetaster: you have to remove release and tag, both | 19:19 |
| poetaster | rinigus: a tag that is used only in the context of the release. well, so much for 'ai'. | 19:20 |
| poetaster | oh. god. | 19:20 |
| poetaster | ! how the hell do I get rid of this crud. oh. dear. | 19:21 |
| poetaster | rinigus: 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 |
| rinigus | poetaster: you can remove tags as well. click on tag and there will be an option | 19:23 |
| poetaster | ah. 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 |
| poetaster | who the hell designed this ! some dark patterns idiot! | 19:24 |
| poetaster | rinigus: 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 |
| rinigus | no problem - so, I just retrigger builds in :chum? | 19:26 |
| poetaster | rinigus: and now I hit the wrong branch :) that was me. all me. me. | 19:26 |
| poetaster | wait for it. | 19:26 |
| rinigus | will do. although, will be afk very soon and can probably trigger rebuild in sfos:chum only tomorrow morning | 19:29 |
| poetaster | rinigus: go for it. I have to bring my son to bed :) | 19:29 |
| poetaster | it's all good. thanks for your patience. | 19:29 |
| rinigus | poetaster: done | 19:30 |
| poetaster | ditto. | 19:36 |
| poetaster | thanks. | 19:36 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!