| Wizzup | Pali: as mailed, I can look at u-boot starting around ~10 feb, and then it shouldn't be more than a few days I think to get a rfc patch | 10:40 |
|---|---|---|
| Wizzup | let's hope that's okay for them | 10:40 |
| Pali | ACK! | 10:40 |
| lel | boshtannik opened an issue: https://github.com/maemo-leste/bugtracker/issues/601 (Language switch, or spec symbol window open by Ctrl + Space and fn + ctrl are broken for me. (russian 2 arrow keyboard)) | 12:21 |
| Wizzup | uvos: wondering if it is possible that the shift logic improvements cause the above problem (at least for special keys) | 13:32 |
| reinob | Yesterday when I installed leste I also noticed that the arrow keys on my German keyboard where wrong. I could "solve" it by replacing the keypad with a US one, which is something I had always planned on doing :) | 13:57 |
| reinob | In my case I had set the hardware keyboard language using the settings (so no ctrl-space, just the standard setting) | 13:57 |
| humpelstilzchen[ | https://kernc.github.io/xsuspender/ interesting (via hn) | 16:06 |
| freemangordon | Wizzup: dma_buf issue is still not solved, I know why the leak but still don;t know how ti fix it without sacrificing the performance a bit | 16:28 |
| freemangordon | in 1-2 days hopefully will have a fix | 16:28 |
| Wizzup | freemangordon: ok :) | 17:16 |
| Wizzup | reinob: I think you should be able to configure the hw layout | 17:17 |
| Wizzup | reinob: right, like you said | 17:17 |
| reinob | Wizzup: sorry I didn't make it clear. Configuring the HW keyboard settings didn't help.. I physically replaced the German layout (the keyboard overlay) with a US one I had lying around nearby :) | 17:37 |
| Wizzup | reinob: ok, I think it should work, but currently it is set to us in /etc/default/keyboard | 17:41 |
| Wizzup | to 'us' in* | 17:41 |
| Wizzup | so that's a part of what needs changing I think | 17:41 |
| Wizzup | and hildon-input-method seems a bit broken regarding this too | 17:41 |
| Wizzup | s/and/but/ | 17:41 |
| reinob | yup. As a test I just changed the setting back to German but it didn't have any effect. I have yet to have a look at the whole init process.. | 17:48 |
| Wizzup | I think this is more a matter of 'yeah, we still have to finish this part' :-) | 17:49 |
| reinob | sure :) for all I care, this is a finished product :). I mean, it boots to something one can work/play with, and it's debian (pardon, devuan), so the limit is actually the 256MB of RAM :), but it's still nice to have such a useful N900 in 2022 :) | 17:50 |
| Wizzup | yeah, there's definitely a few tings to fix before it's a finished product, though ;) | 17:57 |
| uvos | Wizzup: what shift key logic improvements? | 18:26 |
| uvos | Wizzup: we dident change anything with that | 18:26 |
| uvos | Wizzup: i uredirected return | 18:26 |
| uvos | Wizzup: but the redirected return was KP_RETURN | 18:26 |
| uvos | Wizzup: not return | 18:26 |
| uvos | Wizzup: so this dident affect d4 at all , except solve issues where gtk2 applications dident accept return as return (only kp) | 18:27 |
| uvos | wrt special keys breaking, this might have happend with the xcb input method, not sure, but was maybe around this time | 18:28 |
| Wizzup | so it's not say 24edfc425808f6cfed026f70d9c5c7e8bdb2a56a | 18:28 |
| uvos | not sure why that would happend, theroetcily this isent touched at all | 18:28 |
| Wizzup | right | 18:28 |
| uvos | whats that hash of? | 18:29 |
| uvos | him? the vkb plugin? | 18:29 |
| uvos | or gtk2 | 18:29 |
| Wizzup | hildon-input-method | 18:29 |
| uvos | no | 18:30 |
| uvos | thats changes the bavrior of the utf-8 -> xcb keysmb | 18:30 |
| uvos | translator | 18:30 |
| uvos | this dosent touch the vkb or the hwkbd at all | 18:30 |
| Wizzup | ok | 18:30 |
| uvos | hildon-im-xcode.c is the xcb backend | 18:31 |
| uvos | the most likely culprit is src/hildon-im-ui.c changes in fad2c3540ff8bb74a687d6cf8538d2c276a02186 | 18:34 |
| uvos | for special keys | 18:34 |
| uvos | maybe regession test that | 18:34 |
| uvos | yeah ok | 18:39 |
| uvos | i see the problem | 18:39 |
| Wizzup | :) | 18:42 |
| Wizzup | btw, I don't recall ctrl+space ever working (to cycle through keyboard layout), but if you feel like looking at that, I think that would help with https://github.com/maemo-leste/bugtracker/issues/601 | 19:26 |
| Wizzup | humpelstilzchen[: xsuspender looks interesting | 19:26 |
| uvos | heh | 19:48 |
| uvos | its sigstoped | 19:48 |
| Wizzup | basically yeah | 19:48 |
| Wizzup | uvos: one other thing, no hurry, but can you issue a new mce build if it's ready? I'd like to test the lock speedups/race fixes | 19:48 |
| uvos | freemangordon: why did you just do this? https://github.com/maemo-leste/mce/commit/e87defa05f048e9933c9722d3770cf312d0fd9ad | 19:53 |
| uvos | mce allready explicitly adds its own warning flags for instance | 19:53 |
| uvos | quite explictly the ones set in cmakelists | 19:54 |
| Wizzup | The hardening+=all might not be possible through cmake and require a debian/rules tweak, right? | 19:54 |
| uvos | not sure still the others are bullshit | 19:55 |
| Wizzup | strong words but yeah, does not look like they are necessary | 19:56 |
| uvos | well they are worse than not nescesarry since it will leave you quite confised if you change the waring flags in the build system because of some specific false positive | 19:57 |
| Wizzup | right | 19:59 |
| uvos | i also dislike DEB_BUILD_MAINT_OPTIONS | 20:01 |
| uvos | makes more sense to just apply the harding flags yourself | 20:01 |
| uvos | as i use it not just on debian | 20:01 |
| uvos | im just going to revert this | 20:01 |
| Wizzup | It is considered good practice to have hardening flags on in debian | 20:02 |
| Wizzup | And debian has specific spec files for those | 20:02 |
| Wizzup | https://wiki.debian.org/HardeningWalkthrough#Selecting_security_hardening_options | 20:04 |
| Wizzup | cmake doesn't follow CPPFLAGS. A fix was briefly available in sid, but had been revoked since upstream rejected the patch. See bug 653916 for details. As a workaround appending CPPFLAGS to CFLAGS and CXXFLAGS should work in most cases. Debhelper (since 0.9.20120417, only with compat=9 and dh_auto* commands!) and cdbs (since 0.4.110) handle this automatically so the workaround is no longer necessary if | 20:04 |
| Wizzup | they are used. | 20:04 |
| Wizzup | from above page | 20:04 |
| Wizzup | looks like with autotools it's supposed to just work, which is probably why most of our packages don't specify this stuff | 20:05 |
| uvos | the bug dosent apply here | 20:06 |
| Wizzup | uvos: it seems to relate mostly to -D_FORTIFY_SOURCE, do you mean you already set that? | 20:09 |
| Wizzup | in any case I don't have a strong opinion here either way | 20:09 |
| uvos | no im saying i also build for arch | 20:09 |
| uvos | and that is usefull | 20:09 |
| uvos | and therefore it makes more sense to have int in buildystem | 20:10 |
| uvos | instead of applying it in both packages | 20:10 |
| uvos | *in the buildsystem | 20:10 |
| Wizzup | the problem is that if debian change the hardening spec in say stable+1, then you won't notice and won't be in sync | 20:12 |
| Wizzup | gentoo just adds a whole lot of flags by itself typically iirc | 20:12 |
| uvos | sure yes | 20:12 |
| uvos | anyhow how im reading this it should be applied atomaticly anyhow | 20:13 |
| uvos | so this is unesscary | 20:13 |
| uvos | have to check if it dose | 20:13 |
| Wizzup | *nod* | 20:15 |
| sicelo | Wizzup: from GKH, "[PATCH 5.10 297/563] ARM: dts: omap3-n900: Fix lp5523 for multi color" - what does this mean? he's importing it into LTS? | 20:59 |
| Wizzup | yeah | 21:02 |
| sicelo | wow, that's nice :-) | 21:03 |
| Wizzup | let's hope they also pick the patch I send :) | 21:04 |
| uvos | -D_FORTIFY_SOURCE=2 | 23:32 |
| uvos | yeah its added allready | 23:32 |
| lel | IMbackK closed a pull request: https://github.com/maemo-leste/mce/pull/53 (Workaround power key menu appearing for a split second) | 23:37 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!