| freemangordon | dsc_: 4 cores, intel i5 from 2011 | 06:47 |
|---|---|---|
| freemangordon | 16GB RAM | 06:48 |
| Wizzup | https://forgejo.org/ this looks like a gitea fork that might suit us better | 11:08 |
| Wizzup | it has no 'enterprise' features and seems to deal with any security issues better | 11:08 |
| Wizzup | do we want to try it before we migrate from github? better now than later | 11:08 |
| Wizzup | it should be mostly the same I guess | 11:08 |
| mkf | what's the main reason of their fork? | 11:26 |
| Wizzup | mkf: https://forgejo.org/faq/ | 11:33 |
| Wizzup | https://forgejo.org/compare-to-gitea/ | 11:33 |
| Wizzup | it's basically the same thing just seems to have better governance / security policy | 11:52 |
| Wizzup | I think fedora is also moving to forgejo | 12:00 |
| Wizzup | https://discussion.fedoraproject.org/t/fedora-chooses-forgejo/140622 | 12:03 |
| Wizzup | it's also gplv3 I think | 12:04 |
| sicelo | freemangordon: https://gitlab.freedesktop.org/upower/upower/-/issues/301#note_2831220 and https://gitlab.freedesktop.org/upower/upower/-/merge_requests/259/diffs . let's see how this goes | 13:16 |
| sicelo | Wizzup: mmm, how are you able to send emails to the ML and it arrives this quick? I normally Cc the ML when sending kernel patches, but they take ages to show up on the ML | 13:18 |
| Wizzup | sicelo: maybe some of them require manual review | 13:22 |
| mkf | https://github.com/maemo-leste/arm-sdk/tree/master/boards/kernel-configs | 13:48 |
| mkf | is this where kernel configs are? | 13:48 |
| Wizzup | no | 13:49 |
| Wizzup | a lot of the arm-sdk stuff is old/outdated | 13:50 |
| mkf | where should i start | 13:50 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commits/maemo-6.12.y/ | 13:50 |
| Wizzup | e.g. | 13:50 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commit/26e6e9c6a77d07d81a3609895d07390b43e110be | 13:50 |
| Wizzup | we just modify omap2plus_defconfig | 13:50 |
| Wizzup | we also have this https://github.com/maemo-leste/sunxi-linux/ | 13:51 |
| Wizzup | but this was not updated since beowulf | 13:51 |
| mkf | well what if i'm not omap2plus | 13:51 |
| mkf | is it a good idea to work on arm-sdk instead of having another seprate tree for each kernel? | 13:51 |
| Wizzup | then either you enable some additional arches (like sunxi) or you create a whole new copy | 13:51 |
| Wizzup | we will not build any kernels in arm-sdk any more | 13:52 |
| Wizzup | it's not sustainable and a hack | 13:52 |
| Wizzup | want to distribute kernels in packages | 13:53 |
| mkf | ok | 13:53 |
| mkf | is one kernel to rule them all achieveable? | 13:53 |
| Wizzup | you will also need stuff like this if you're going to make a separate kernel | 13:53 |
| mkf | or one kernel for each device/arch? | 13:53 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commit/0c4218ebd5d888fdb708238f9dbe835321798918 | 13:53 |
| Wizzup | https://github.com/maemo-leste/droid4-linux/commit/7bdf8dbcf9da99fde4e26b71c7abb967e1dfe026 | 13:53 |
| Wizzup | I think one kernel for armhf would be great from a maintenance perspective but you can also take the droid4-linux and remove most of the omap patches and build a different defconfig | 13:54 |
| mkf | hm | 13:57 |
| mkf | i pretty much needed no patch for my tablet, mainline just worked™ | 13:58 |
| mkf | however for some of my devices i don't know how to test properly, like screen rotation or bluetooth | 13:58 |
| mkf | i guess i'll fork droid4 then or update sunxi | 13:59 |
| sicelo | freemangordon: Wizzup: as far as the Maemo/Leste stack is concerned, which process is the most important, and which is not allowed to be stopped/restarted, i.e. restarting it basically requires a reboot, or similar? | 14:24 |
| sicelo | i guess dsme can be restarted without ill effect? | 14:25 |
| sicelo | but looks like dsme is the answer for my question, at least what i have in mind. while looking at the upower thing, i noticed that actually https://github.com/maemo-leste/mce/blob/master/src/modules/battery-guard.c#L31-L33 couldn't have worked, since upower requests the shutdown on its own, without involving mce | 14:34 |
| Wizzup | I don't think restarting dsme is a great idea | 14:35 |
| sicelo | i think correct solution is for dsme to take an inhibitor lock at startup, which would ensure it sees all requests for shutdown and can decide whether or not to honor them. anyway, maybe job for 2030, but this would do a lot of good, i think | 14:37 |
| sicelo | maybe then that gives us also the chance to remove battery stuff from mce, fulfilling uvos' wish :-) | 14:38 |
| Wizzup | can we have upowerd make no decisions about shutdow and ignore its requests? | 14:38 |
| Wizzup | or, why do we want to utilise upowerd here? | 14:39 |
| sicelo | yes we can tell upower to not request the shutdown, if we ship a suitable config (AllowRiskyCriticalPowerAction=true and CriticalPowerAction=Ignore). | 14:44 |
| Wizzup | that seems to be all we need for now, right? | 14:46 |
| Wizzup | I'm trying to understand if/why we would want deeper integration with upowerd, it is not clear to me that it will offer the smarts that we need | 14:46 |
| sicelo | yes i didn't mean integrating upower with dsme :-) | 14:47 |
| sicelo | i just observed that dsme would probably benefit from taking an inhibitor lock, so it can reliably control/manage requests for shutdown, whether coming from upower or anything else | 14:49 |
| Wizzup | I see, and this lock is some systemd interface, or? | 14:56 |
| sicelo | yes. elogind also implements it, so it can work on Leste/Devuan too. anyway, it's not an immediate thing to implement. lots of other stuff is more urgent | 14:58 |
| Wizzup | I see, so it was ultimately elogind that did the actual shutdown | 14:59 |
| sicelo | yes. upower just requests it | 14:59 |
| Wizzup | can we disable that in elogind? | 15:00 |
| Wizzup | then we could make things work without a upower fork now, I think | 15:00 |
| sicelo | if we had an inhibitor lock held by something else, then yes, we can disable it | 15:01 |
| sicelo | anyway, i think the fork will help us in other ways (e.g. we do need to show some sort of status icon, even if inhibit solves the shutdown problem), so let's pursue the fork first, and do the inhibitor later. the idea/plan is for the fork to be upstreamed anyway, so it will not be a maintenance burden like previously | 15:04 |
| mkf | freemangordon: should i put my device trees in linux sunxi or should i fork linux-droid4? | 15:16 |
| mkf | Wizzup: btw have you considered source hut? | 15:45 |
| Wizzup | not really | 15:51 |
| mkf | it's nice imho. | 15:53 |
| Wizzup | I don't have a good personal experience with the author of the sw and I think it's perhaps a bit too 'hacker focussed'. I'd consider using it for some personal project | 15:54 |
| mkf | fair enough, author was indeed a bit controversial. | 15:55 |
| mkf | however it's nice that it doesn't require js. i often find myself around computers without browsers with js support or too weak to handle modern day js. | 15:56 |
| Wizzup | true... | 15:57 |
| Wizzup | gitea/forgejo makes things quite easy though, with good migrations tools, oauth2, etc | 15:58 |
| Wizzup | I think either will be a big usability change over github | 15:58 |
| Wizzup | btw, re kernel. I think maybe just take 6.12 or whatever kernel, add the build deb patches we have in linux-droid4, and then push to linux-sunxi or so | 15:59 |
| Wizzup | the build dep patches are really most of what you need, and probably also take a new debian dir from droid4-linux and change the right names/etc for sunxi | 15:59 |
| Wizzup | I can help with some of it | 16:00 |
| Wizzup | btw, might be worth testing how usable forgejo is without js | 16:00 |
| mkf | is it up? | 16:01 |
| Wizzup | currently git.maemo.org runs gitea still, but I plan to nuke it this week and replace it with forgejo | 16:01 |
| Wizzup | did you try git.maemo.org without js? | 16:02 |
| mkf | let me do so | 16:02 |
| Wizzup | I tried dillo and it's ... eh :) | 16:05 |
| mkf | mothra looks like what mothra would generally look like | 16:06 |
| mkf | netsurf is... at least that works. | 16:06 |
| Wizzup | this is forgejo https://codeberg.org/explore/repos | 16:07 |
| mkf | let me see microb too | 16:07 |
| Wizzup | microb, from frenatle? | 16:07 |
| Wizzup | fremantle? | 16:07 |
| mkf | yes | 16:07 |
| Wizzup | heh | 16:07 |
| Wizzup | does that even connect over tls? | 16:07 |
| mkf | i suppose so | 16:08 |
| mkf | is the tls enforced? | 16:08 |
| mkf | forodo looks better | 16:08 |
| mkf | at least in netsurf | 16:08 |
| mkf | useableish | 16:08 |
| mkf | https://cloud9p.org/usr/mkf/tmp/forodo.png | 16:12 |
| Wizzup | cool, another vote for forgejo then | 16:15 |
| Wizzup | (apart from the name, I have trouble typing it every time) | 16:15 |
| Wizzup | is this 9front ? | 16:15 |
| mkf | yes. | 16:18 |
| mkf | https://cloud9p.org/usr/mkf/tmp/gitea.png | 16:18 |
| mkf | here is how gitea looks in contrast | 16:18 |
| Wizzup | ok | 16:25 |
| Wizzup | yeah seems like forgejo is better | 16:25 |
| moparisthebest | don't forget https://git.inept.dev/~doyle/rgit.git/about :) | 16:26 |
| Wizzup | yaeh but I'd like oauth2, some api, issues, github migration path, etc | 16:28 |
| moparisthebest | Oh, then do forget it :D | 16:29 |
| Wizzup | ci/cd too | 16:29 |
| mkf | i guess there are cgits and githubs. | 16:30 |
| mkf | rgit is a cgit. | 16:30 |
| moparisthebest | I'm still running gitea & jenkins, also likely need to upgrade to forgejo (and probably keep Jenkins) at some point | 16:30 |
| mkf | Wizzup: could we merge all linux sources into one repo? | 16:32 |
| mkf | with seprate branches for each device | 16:32 |
| Wizzup | it would be better from storage perspective I guess, the main issue here is that we can't build multiple packages for say daedalus | 16:32 |
| Wizzup | we can have multiple branches, but our jenkins CI looks at a branch named maemo/<releasename> | 16:33 |
| mkf | i'm not into linux a lot so i dont know whats the best practice in this case | 16:33 |
| Wizzup | I think for now we can have a/the linux-sunxi repo | 16:33 |
| Wizzup | if you can make a kernel with the right changes / version that works for you can I look at packaging | 16:33 |
| mkf | ok | 16:33 |
| Wizzup | if that's just out 6.12 droid4-linux head or something that can work too | 16:34 |
| Wizzup | s/out/our/ | 16:34 |
| mkf | forked :) | 16:37 |
| freemangordon | guys, wait | 16:41 |
| freemangordon | do we really need another kernel for sunxi? | 16:42 |
| mkf | idk, do we? | 16:42 |
| freemangordon | can;t we just have a single one, based on d4? | 16:42 |
| freemangordon | Wizzup: ^^^? | 16:42 |
| Wizzup | I am ok with having a single one for armhf | 16:44 |
| Wizzup | I would prefer it in fact | 16:44 |
| mkf | sounds good to me. | 16:44 |
| Wizzup | but we'll need to enable additional arches and modules | 16:44 |
| Wizzup | and we'll want to somehow merge the sunxi_defconfig and omap2plus_defconfig's | 16:44 |
| mkf | also how do we keep versions in sync? | 16:45 |
| Wizzup | freemangordon: iirc you always advocated for the most minimal kernel | 16:45 |
| Wizzup | mkf: we rebase on mainline once the pvrsgx patches come out and as time permits iirc | 16:45 |
| freemangordon | Wizzup: right, because n900 | 16:46 |
| mkf | what if at somepoint some bug blocks a device from going latest version but other devices could? | 16:46 |
| freemangordon | but we lack manpower to maintain kernel for every device around | 16:47 |
| Wizzup | then we have to fix it | 16:47 |
| Wizzup | freemangordon: yeah I prefer having a single kernel fyi, but for initial testing I don't mind having a separate pkg | 16:47 |
| freemangordon | mkf: we have -devel repo for that reason | 16:47 |
| Wizzup | if it makes it easier to test now | 16:47 |
| freemangordon | Wizzup: we'd better not, as it will affect metapackages | 16:48 |
| freemangordon | but no hard preference | 16:48 |
| mkf | freemangordon: ok | 16:48 |
| Wizzup | not too hard to make replaces: sunxi-linux or something but sure | 16:48 |
| freemangordon | Wizzup: upstream works with no patches (more or less), we just need to turn the correct knobs in omap2plus_defconfig | 16:49 |
| Wizzup | yes, but sunxi has its own CONFIG_ARCH_ and its own defconfig | 16:50 |
| Wizzup | I think there is or was a multi config for all armv7 targets, but that will take days to build on CI/CD | 16:51 |
| Wizzup | (and have a really large pkg for all modules) | 16:51 |
| freemangordon | so, we can't have both arches enabled at once? | 16:51 |
| Wizzup | sure we can, but where do you enable them | 16:51 |
| freemangordon | well, we can have modules per device | 16:51 |
| Wizzup | in omap2plus_defconfig? | 16:51 |
| freemangordon | yes | 16:51 |
| mkf | Wizzup: which config was it? | 16:51 |
| Wizzup | freemangordon: how do we have modules per device? | 16:51 |
| freemangordon | we can rename ofc :) | 16:51 |
| mkf | i'd like to use that one for personal tests | 16:52 |
| freemangordon | Wizzup: .deb with modules per device | 16:52 |
| Wizzup | that sounds like a serious project | 16:52 |
| Wizzup | mkf: it benig the multi arch one? | 16:52 |
| mkf | one with all modules | 16:52 |
| Wizzup | let me see | 16:53 |
| Wizzup | mkf: multi_v7_defconfig | 16:53 |
| freemangordon | Wizzup: speaking of kernel, who maintains our d4 kernal? | 16:57 |
| freemangordon | *kernel | 16:58 |
| Wizzup | freemangordon: you/me/uvos I guess | 16:59 |
| freemangordon | hmm... | 17:01 |
| freemangordon | ok, my cpcap/asoc fixes will be in 6.15, I think this shall be the kernel to move to once it is released | 17:11 |
| freemangordon | I will work on ngsm fixes for it | 17:12 |
| mkf | hm | 17:57 |
| mkf | there is this odd behavior | 17:57 |
| mkf | if you change hostname @ /etc/hostname but dont update /etc/hosts if you lock screen you can't unlock it anymore | 17:57 |
| mkf | because dbus can't find some dbus service? (tklock_close?) | 17:57 |
| freemangordon | weird | 18:01 |
| mkf | prob. because it tries to connect to your new hostname but can't resolve it | 18:01 |
| freemangordon | I would expect it to use unix domain sockets | 18:02 |
| mkf | freemangordon: https://github.com/lwfinger/rtl8xxxu/blob/main/rtl8xxxu_8723b.c | 18:15 |
| mkf | have you seen this? | 18:15 |
| freemangordon | no, but i don think bs is supported by that driver | 18:22 |
| mkf | i keep seeing people mention 8723bs driver is going to be replace by rtl8xxxx family | 18:22 |
| mkf | but i dont see explict code of 8723bs driver | 18:23 |
| freemangordon | "Driver for Realtek RTL8XXXXU usb wifi chips, which is backported from linux mainline" | 18:23 |
| mkf | hm. | 18:24 |
| mkf | oh well. | 18:28 |
| gnarface | what i seemed to be able to gather, is that basically people don't know that the 8723bs is not the same as the 8723cs | 18:28 |
| mkf | yeah seems no sdio varient exists yet | 18:28 |
| freemangordon | mkf: so, with my band patch your chip cannot connect? | 18:29 |
| gnarface | so there's apparently this widespread mistaken assumption that recent efforts to get the 8723cs working with the new (rtw88?) driver also magically inherited 8723bs support, which is not the case | 18:29 |
| mkf | it seems that patch doesn't effect me much, it's still 1 in 10 with maemo ui | 18:29 |
| freemangordon | hmm... | 18:29 |
| mkf | (but better with wpa cli?) | 18:29 |
| gnarface | however, they might not be so different that it can't still be added, reports are that the staging driver is still faster | 18:29 |
| mkf | if i restart icd like ten times i might get that working | 18:30 |
| freemangordon | mkf: that should not be the case, I put a fix in icd plugin, lemme check if it is in stable | 18:30 |
| freemangordon | mkf: your device is on chimaera, right? | 18:30 |
| freemangordon | oh, fixes are not in -stable :( | 18:32 |
| freemangordon | mkf: later on will build those fixes for stable, it should get better after that | 18:32 |
| mkf | by stable you mean debian terminology? isnt chimaera oldstable? | 18:36 |
| mkf | i can update to dadelus | 18:42 |
| freemangordon | no | 18:46 |
| freemangordon | bu stable I mean chimaera-stable | 18:46 |
| freemangordon | *by | 18:46 |
| freemangordon | do you have chimaera-devel repos enabled? | 18:46 |
| mkf | no, but i can do so. | 18:46 |
| freemangordon | no, don't | 18:46 |
| mkf | ok | 18:46 |
| freemangordon | we have to mova that to stable anyways | 18:46 |
| freemangordon | *move | 18:47 |
| freemangordon | argh, another typo day | 18:47 |
| freemangordon | Wizzup: do we have a list of diffs between -sable and -devel? for chimaera | 18:47 |
| mkf | there are like two streams one being devuan and other being leste? | 18:55 |
| sicelo | no. leste is based on devuan ... | 19:03 |
| freemangordon | no, what do you mean? | 19:03 |
| sicelo | freemangordon: your ofono CVE fix has been merged ;-) | 19:04 |
| mkf | like leste version x can be installed in devuan x and y | 19:04 |
| sicelo | like leste version x is devuan version x with leste-specific packages on top | 19:06 |
| mkf | okay. so leste isn't really a os like original maemo | 19:06 |
| sicelo | well ... :-) | 19:06 |
| mkf | it's a customized devuan installation with specfic config and packages | 19:07 |
| mkf | i.e, not a hard fork i guess | 19:07 |
| sicelo | it can be argued that the original maemo was debian with maemo-specific stuff on top ;-) | 19:07 |
| sicelo | yes no, not a hard fork. in fact not a fork at all | 19:07 |
| mkf | true. :) | 19:07 |
| sicelo | look at /etc/apt/sources.list ... you'll see the devuan repos there | 19:07 |
| mkf | freemangordon: please let me know once that's available. | 19:29 |
| Wizzup | freemangordon: I can make a repodiff list | 19:30 |
| Wizzup | brb though | 19:30 |
| freemangordon | Wizzup: please do | 19:31 |
| freemangordon | sicelo: :) | 19:31 |
| Wizzup | freemangordon: https://bpa.st/XOKQ | 19:48 |
| freemangordon | thanks | 19:48 |
| freemangordon | Wizzup: cannot rebase libicd-network-wpasupplicant stable on devel :( | 19:54 |
| freemangordon | mkf: done | 20:04 |
| freemangordon | Wizzup: any clue why xorg in stable differs from the one in -devel? | 20:13 |
| Wizzup | freemangordon: did you need me to look at the rebase still | 20:36 |
| freemangordon | no | 20:36 |
| freemangordon | I somehow managed to push :) | 20:36 |
| freemangordon | I guess new development will happen on daedalus or newer, so lets pretend there is no issue | 20:37 |
| freemangordon | still, do you know why xorg differ? | 20:37 |
| Wizzup | freemangordon: no, I'd have to check the branches and see how they are different | 20:42 |
| freemangordon | could you do, you might know better than me about xorg history. At least I don't remember doing anything about it | 20:48 |
| mkf | installed it | 20:54 |
| mkf | seems to work. | 21:00 |
| Wizzup | freemangordon: will look | 21:05 |
| Wizzup | freemangordon: the branches seem to be the same | 21:06 |
| Wizzup | freemangordon: oh I see | 21:06 |
| Wizzup | freemangordon: yeah the same | 21:06 |
| Wizzup | -devel is just stable + a revert and a revert of the revert | 21:06 |
| Wizzup | which really makes it the same | 21:06 |
| Wizzup | we could remove the pkg from -dfevel | 21:06 |
| freemangordon | ok | 21:07 |
| freemangordon | hmm... sphone 0.9.5+m7 (> 0.7.5+m7 ) | 21:07 |
| freemangordon | uvos__: ^^^ | 21:07 |
| freemangordon | Wizzup: what about https://github.com/maemo-leste/hildon-connectivity-meta/compare/maemo/chimaera...master ? I guess this needs sphone from devel, right? | 21:13 |
| mkf | how can i connect to irc using converstions | 21:14 |
| freemangordon | mkf: is wlan better after the upgrade? | 21:15 |
| mkf | yeah. a lot. :D | 21:16 |
| mkf | what did that changed? | 21:16 |
| freemangordon | well, fixed bugs | 21:16 |
| mkf | wonderful, fixed bugs are. | 21:17 |
| mkf | do bugs go to heaven after they are fixed? | 21:17 |
| freemangordon | I doubt, I guess they roam between the planes for the eternity | 21:18 |
| freemangordon | see https://github.com/maemo-leste/libicd-network-wpasupplicant/commits/maemo/chimaera | 21:18 |
| freemangordon | last 4 commits | 21:18 |
| mkf | so we shall meet that bug again, perhaps elsewhere | 21:19 |
| mkf | farewell james the bug | 21:19 |
| Wizzup | freemangordon: looking | 21:46 |
| Wizzup | freemangordon: yeah I think so | 21:46 |
| freemangordon | Wizzup: what about tp-haze, shall I prompte it from -devel? | 22:33 |
| freemangordon | *promote | 22:34 |
| Wizzup | freemangordon: yeah | 22:59 |
| mkf | touch screen fixed. | 23:40 |
| mkf | i might have a 1024x768 (or 600?) screen | 23:41 |
| mkf | i thought i had a 800x480 | 23:41 |
| mkf | a33-q8h-v1.5/GSL1688_A70_FW.fw: 960x640 | 23:42 |
| mkf | right, screen resolution doesn't always apply 1:1 to screens size | 23:43 |
| Wizzup | mkf: making progress! | 23:53 |
| sicelo | Wizzup: where does devuan keep their development work? i'm looking for their upower packaging. https://git.devuan.org/devuan/upower seems too ancient | 23:57 |
| sicelo | at least https://pkginfo.devuan.org/cgi-bin/policy-query.html?c=package&q=upower&x=submit suggests there should be a 1.90.7 somewhere ... i don't suppose they're getting it directly from debian, since the debian one build-depends on systemd, | 23:58 |
| sicelo | https://salsa.debian.org/utopia-team/upower/-/blob/debian/master/debian/control?ref_type=heads#L24 | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
