uvos | Wizzup: upps | 00:24 |
---|---|---|
uvos | i see | 00:24 |
Wizzup | do you need a full list? :P | 00:25 |
uvos | eh should not be to hard to fix | 00:25 |
Wizzup | I can pass along my cron job mail | 00:25 |
Wizzup | it contains all the tags you pushed today | 00:25 |
uvos | ah great | 00:25 |
uvos | yes | 00:25 |
Wizzup | ygm | 00:26 |
mighty17[m] | freemangordon: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16289/diffs we need this to get mesa working with llvm15 | 06:54 |
freemangordon | mighty17[m]: ok, thanks | 07:46 |
freemangordon | Wizzup: ^^^ | 07:46 |
Wizzup | ok | 08:39 |
Wizzup | modest stopped auto fetching emails since my disk gor full | 08:39 |
Wizzup | should debug that soon | 08:39 |
mighty17[m] | https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17518 this as well | 09:35 |
mighty17[m] | cant we update mesa itself :P | 09:35 |
rafael2k_ | hi all | 10:07 |
rafael2k_ | btw, I couple of months ago I send a ringtones package which fixes the original ringtones: https://www.abradig.org.br/maemo-crazyness/maemo-ringtones-mr0_1.2+0m7_all.deb | 10:08 |
rafael2k_ | I can see it is not in repo... did anyone found a problem with it? | 10:08 |
rafael2k_ | the version with wrong paths and non-existant files references is still there... http://maedevu.maemo.org/leste/pool/main/m/maemo-ringtones-mr0/maemo-ringtones-mr0_1.1%2B0m5_all.deb | 10:09 |
rafael2k | now we have telephony in place... keeping the phone not ringing just because of the wrong ringtones package is odd | 10:10 |
Wizzup | rafael2k: we don't just import random pkgs, either we take ones from nokia or we rebuild them from src | 14:28 |
freemangordon | tmlind: uvos: did you receive my pings re upstream patches? | 14:30 |
freemangordon | I am starting to think my mails get dropped somehow, I don't believe upstream maintainers are so impolite to not even reply with a NACK | 14:31 |
uvos | freemangordon: mailinglist is fwd your emails just fine here | 14:46 |
uvos | Wizzup: did you see leste config pr https://github.com/maemo-leste/leste-config/pull/35 | 14:46 |
uvos | this one is important to get into devel asap | 14:46 |
Wizzup | will do today | 14:47 |
Guest47 | Hello everyone, installed maemo leste version: | 15:01 |
Guest47 | maemo-leste-1.0-armhf-n900-20221029.img.xz | 15:01 |
Guest47 | I was pleased with the appearance of the choice of hardware keyboard, but it does not work, unfortunately. | 15:01 |
Guest47 | I choose the hardware keyboard "Russian" but the hardware layout remains unchanged | 15:02 |
Guest47 | I add the second language "Russian", when switching the keyboard layout, the Latin layout remains | 15:02 |
Guest47 | What can be done? | 15:02 |
uvos | https://github.com/maemo-leste/bugtracker/issues/634 | 15:03 |
Wizzup | uvos: done | 15:12 |
sicelo | i think removing ofono from runlevel would have been better. in future we will need the files being deleted by that commit | 15:29 |
Wizzup | sicelo: that should just work with an upgrade | 15:30 |
Wizzup | removing it from runlevel won't do anything | 15:30 |
Wizzup | it will just get started by services that have 'need ofono' or 'depend ofono' | 15:30 |
sicelo | except it does work ... that's what i have on mine | 15:31 |
Wizzup | you did 'rc-update del ofono' and it doesn't crash anymore? that'd be insane :D | 15:31 |
sicelo | anyway, guess when modem is fixed, we'll need to remember this commit and revert it | 15:31 |
Wizzup | and it would mean cellulard is buggy as it must depend on ofono | 15:31 |
sicelo | Wizzup: there's no problem even having ofono running. the problem is only when *using* modem. i always have the module and ofono running in my postmarketOS install | 15:33 |
Wizzup | right, it's just that your suggestion of removing it from runlevel doesn't prevent ofono from being started by openrc and doesn't prevent the bug as cellulard will still do its thing | 15:34 |
Wizzup | which is why I think the module blacklits is better, at least for people who upgrade devel and are unaware | 15:34 |
Wizzup | (and honestly we need to figure out how to fix this asap, since it's kind of a really bad regression) | 15:35 |
sicelo | yes | 15:37 |
uvos | also removeing ofono from the runlevel is mutch harder to do via pacakging | 16:23 |
uvos | since you have to do mutch more fragile postins things | 16:24 |
tmlind | freemangordon: my guess is no easy solution to give, too many emails, too late in the merge window.. best to try again after -rc1 | 16:37 |
tmlind | uvos: interesting if the te makes things worse.. for other idea, with a command mode panel the 60hz refresh rate should not matter i think | 16:38 |
uvos | tmlind: rolling is unchaiged | 16:39 |
uvos | but the pannel now failes to update multiple frames in a row | 16:39 |
uvos | anyhow i reverted it again for leste | 16:39 |
nerdcore | I just put ML 20221113 onto a PinePhone and I am very confused. I called the device from another telephone and nothing happened inside ML to indicate an incoming call. Does it not have a Phone application or something? | 16:51 |
Wizzup | nerdcore: only -devel has the calls enabled, and we're working on pushing our chimaera where it will be integrated by default. | 16:51 |
nerdcore | oh... | 16:52 |
nerdcore | how do I obtain a devel release? Do I need to build it myself with the Image Builder? | 16:54 |
sicelo | edit sources.list to add the devel repository component | 16:59 |
Guest47 | uvos thanks helped | 17:02 |
sicelo | please educate me here - 1. i see the vibrator regression is reported as fixed. however, there's no commit adding the kernel config, besides a version bump. how does this work? | 17:54 |
freemangordon | debian/patches? | 17:55 |
sicelo | 2. the version bump is in beowulf-experimental branch. breakage is in devel however | 17:55 |
sicelo | so i'm not sure i understand | 17:55 |
uvos | your looking in the wrong place | 17:55 |
uvos | the beowulf/experiamental branch dosent contain the kernel source tree | 17:55 |
sicelo | what's the right place? | 17:55 |
uvos | maemo-6.1 | 17:55 |
sicelo | the problem is that you always say others are wrong | 17:56 |
uvos | huh? | 17:56 |
sicelo | maemo-6.1 was last modified 2 days ago | 17:56 |
sicelo | i looked there first | 17:56 |
uvos | https://github.com/maemo-leste/droid4-linux/commit/997ac6df64d8b82a819285948fe073628cb1e864 | 17:57 |
uvos | its there | 17:57 |
sicelo | https://github.com/maemo-leste/droid4-linux/tree/maemo-6.1 not here | 17:57 |
uvos | but i forgot to push the branch, but this dosent matter (for the build at least) since it just checks out the tag | 17:57 |
sicelo | as for experimental, i know the beowulf/* branches don't contain kernel source. my question is, this updated kernel will end up in devel? or experimental? | 17:59 |
uvos | experimental for a couple of h untill i can test if the kernel in question dosent break d4/bionic | 18:00 |
uvos | so yes the closing of the bug was maybe slightly premature | 18:00 |
sicelo | ah yes, d4 | 18:00 |
uvos | it works on n900 i tried that alleady | 18:00 |
uvos | not sure what your insinuateing | 18:00 |
sicelo | of course it works on N900. why would it break d4 or anything else? | 18:00 |
uvos | thus far i have not tested the expiramental kernel at all on d4 | 18:01 |
uvos | and it contains alot of changes to benefit xt910 | 18:01 |
uvos | that very mutch touch it | 18:01 |
sicelo | touch TWL4030_VIBRA? | 18:01 |
uvos | no but theres lots of changes in expiramental that are not in devel arround restructureing mapphone dts | 18:02 |
uvos | so i cant just merge rn | 18:02 |
uvos | without testing | 18:02 |
sicelo | i don't understand why it went to experimental in the first place, when the breakage is in devel | 18:02 |
uvos | because i dont thing diverging the branches for the benefit of the the vibra being broken for a couple less hours is sane | 18:03 |
uvos | this line of questioning is useless | 18:03 |
sicelo | right. | 18:03 |
uvos | no one even noticed vibra being broken for manny months | 18:04 |
uvos | it can wait another 4 hours | 18:04 |
sicelo | right. | 18:06 |
freemangordon | uvos: my question was more like " is it possible their spam filters drop my mails" | 18:22 |
freemangordon | I am not really sure how to handle that | 18:23 |
uvos | freemangordon: understood, i dont know why they wont awnser the patch looks perfectly sane to me | 18:23 |
uvos | freemangordon: at least my spam filter has never filterd you | 18:23 |
freemangordon | however, sre reviewed your patch in a day, so it is not that he is so overloaded | 18:23 |
uvos | yeah no idea | 18:23 |
freemangordon | I'll ask to tmlind when he is around to replay to sre asking if he receives my mails at all | 18:24 |
freemangordon | *reply | 18:24 |
freemangordon | uvos: also, it is not 1, but 5 patches, basically | 18:25 |
uvos | right | 18:25 |
freemangordon | one series and 2 independent patches | 18:25 |
uvos | series looks perfectly sane to me | 18:25 |
uvos | but what is sane to me is maybe not sane to kernel folks, they want me to enable all leds for mapphone then disable them again and then re-enable them again per device after all :) | 18:26 |
uvos | sounds insane to me, but if that want that ill give them that | 18:26 |
freemangordon | this is different, like, they don't like something and tell you what too change | 18:29 |
freemangordon | almost all I got so far is silence :) | 18:29 |
freemangordon | maybe you should send my paches | 18:29 |
uvos | we can try that, but i got the silent tretment with touchscreen-buttons too | 18:30 |
freemangordon | hmm | 18:30 |
freemangordon | what the? | 18:31 |
freemangordon | time to write to FSF? | 18:31 |
freemangordon | Not that I know if they have any influence | 18:32 |
freemangordon | I really hope Pavel will help | 18:32 |
uvos | i doubt it will help | 18:33 |
uvos | anyhow ttyl | 18:33 |
freemangordon | why? | 18:33 |
freemangordon | ok | 18:33 |
sicelo | he does take a long time sometimes too :-) | 18:33 |
freemangordon | yes, I know | 18:33 |
uvos | well its hard to make volenteers do anything | 18:33 |
uvos | same with coperate types outside thair interests | 18:34 |
freemangordon | I am not sure those are volunteers | 18:34 |
sicelo | they are | 18:34 |
freemangordon | most-probably they are paid for | 18:34 |
freemangordon | anyway, lets wait a bit longer and then I'll try to make some noise | 18:35 |
uvos | to be fair mr freemangordon also sometimes takes a long time to review prs :P | 18:35 |
uvos | its just how this goes with people | 18:36 |
freemangordon | uvos: but, at least I respond when you aske me "WTF is with my PRs", right | 18:36 |
uvos | true | 18:37 |
freemangordon | speaking of which - is there any other but h-d PR you are waiting for me to review? | 18:38 |
uvos | sure theres several, ill make a list later | 18:38 |
uvos | ttyl really now | 18:38 |
freemangordon | please do | 18:38 |
mighty17[m] | freemangordon: https://paste.debian.net/1263223/ | 20:17 |
mighty17[m] | `gvc_mixer_stream_get_port: assertion 'stream->priv->ports != NULL' failed` | 20:17 |
mighty17[m] | another thing broke now? :( | 20:17 |
mighty17[m] | oh phosh* | 20:17 |
mighty17[m] | `Assertion failed: sigbus_data->current_pool == NULL || sigbus_data->current_pool == pool (../src/wayland-shm.c: wl_shm_buffer_begin_access: 649)` or this | 20:19 |
tmlind | uvos: maybe tweaking the max_hs_rate changes something on the xt91x panel? also maybe reading the sysfs entry for num_dsi_errors increases when the image jumps? just guessing by looking at the code.. | 20:53 |
tmlind | ttyl | 20:56 |
freemangordon | mighty17[m]: I am missing how is this related to leste or me :) | 21:26 |
uvos | tmlind: ok, ill try it when i find the time to work on xt91x nex | 22:16 |
uvos | t | 22:16 |
uvos | freemangordon: so besides the 2 h-d prs | 22:22 |
uvos | there is: | 22:22 |
uvos | https://github.com/maemo-leste/osso-xterm/pull/4 | 22:22 |
uvos | https://github.com/maemo-leste/osso-applet-notificationlight/pull/1 | 22:22 |
uvos | https://github.com/maemo-leste/osso-applet-display/pull/2 | 22:22 |
uvos | https://github.com/maemo-leste/hildon-status-menu/pull/3 | 22:22 |
uvos | freemangordon: btw dose gconf_client_get_int have any side effects i dont know about? this is a bug right: https://github.com/maemo-leste/osso-xterm/blob/c856bb52b6fb5ba5fa82797460416bef4cc7a94e/src/terminal-window.c#L373 | 22:26 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!