antranigv has quit [Quit: ZNC 1.9.0 - https://znc.in]
antranigv has joined #maemo-leste
akossh has quit [Quit: Leaving.]
xes has quit [Ping timeout: 264 seconds]
akossh has joined #maemo-leste
nmdv has quit [Remote host closed the connection]
nmdv has joined #maemo-leste
akossh has quit [Remote host closed the connection]
nmdv has quit [Read error: Connection reset by peer]
xes has joined #maemo-leste
nmdv has joined #maemo-leste
nmdv has quit [Ping timeout: 260 seconds]
cockroach has quit [Quit: leaving]
Daanct12 has joined #maemo-leste
hexnewbie has quit [Ping timeout: 252 seconds]
Daanct12 has quit [Quit: WeeChat 4.3.5]
Daanct12 has joined #maemo-leste
hexnewbie has joined #maemo-leste
xmn has quit [Ping timeout: 264 seconds]
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 276 seconds]
joerg has quit [Ping timeout: 248 seconds]
joerg has joined #maemo-leste
ceene has joined #maemo-leste
Livio has joined #maemo-leste
KREYREN has joined #maemo-leste
<KREYREN> Referencing https://github.com/NixOS/nixpkgs/issues/328952#issuecomment-2255739446 -> Are there any plans to update the GTK toolkit in maemo-leste? The NixOS's security team is not very happy about it's dependency on gtk2
uvos__ has joined #maemo-leste
<uvos__> KREYREN: i mean yeah we are sortof moving towards qt but geting rid of gtk2 wont happen soon or really ever
<uvos__> conisdering the amount of work
<uvos__> also if the maemo ui is ported to qt its very possible this would leave the n900 behind
<KREYREN> uvos__, is there any tracking for this so that i can be referenced in the issue?
<uvos__> KREYREN: no
<KREYREN> hmm O.o
<uvos__> given this would make it more resource intensive and the n900 is at its limit as is
<uvos__> KREYREN: its not a current target
<uvos__> only a this would be nice at some point
<uvos__> we dont have the resources to do it atm
<KREYREN> uvos__, what should be the approach for N900 UI beyond WMs then? gnome-mobile adjusted for N900's formfactor?
<sicelo> we're moving to hildon to qt? i thought we'd be moving it to GTK3 (at least that's what's on Github)
<KREYREN> sicelo, link plz
<uvos__> sicelo: its not really decided
<uvos__> but all the work on new stuff has been qt
<sicelo> KREYREN: i *dont* think N900 is holding back any progress ... if, someday, N900 really can't be supported, I don't see why it can't be dropped. There's no nostalgia involved.
<uvos__> but this bug is about running gtk3 applications on otherwise gtk2 maemo-leste
<uvos__> yes currently the n900 is not holding back progress at all
<uvos__> since we dont have the resources for a big change anyhow
<KREYREN> uvos__, what kind of resources? Just human?
<uvos__> yes
<sicelo> KREYREN: no surprise @ stance on GTK2 ... it's the same problem in other distros. FYI, hildon has been in Debian proper, and postmarketOS
<uvos__> esp given that hildon needs patched gtk2 which breaks non-hildon apps
<uvos__> gtk2 is a problem yes
<uvos__> we might be better off hard forking it into htk or something at some point
<uvos__> so it can co-exist
<KREYREN> uvos__, the gtk2 breaking other apps is not a problem on NixOS dependencies are packed with the binaries through symlinks and PATH management
<uvos__> KREYREN: sure but it is for other distros
<KREYREN> yea
<KREYREN> uvos__, htk is probably a good approach for nixos security team to be happy.. they afaik just don't like unmaintained packages that is bitrotting
<uvos__> not sure this will fool them
<uvos__> but sure :P
<KREYREN> i don't want to fool them, rather getting htk the support it needs to be secure in a more manageable way
<uvos__> well our gtk2 dosent get mutch changes either
<KREYREN> kinda like packages that are in LTS with security support and super rare to get new features
<uvos__> is what i am saying
<KREYREN> uvos__, Like if maemo-leste would be to fix any security vulnerabilities that show up in that thing then that would make it acceptable i think
<KREYREN> or like using gtk2 directly for that as there are still lot of apps that depend on it
<KREYREN> e.g. gimp afaik
<uvos__> gimp for just a couple more months
<uvos__> but yes
<uvos__> gimp3 is finially allmost ready now for real
<uvos__> :P
<KREYREN> i feel like i heard that sentence way too many times in the last 4 years :D
<uvos__> i belive this time
<KREYREN> Still a lot of software tht depends on gtk2 afaik to justify receiving security updates to make distro's security teams happy imho
<uvos__> gimp and sphone are the only 2 applications depending on gtk2 on my desktop arch linux system
<uvos__> so idk
<KREYREN> not much but seem to share the same issue to maemo that they can't be easily ported
Livio has quit [Ping timeout: 255 seconds]
ceene has quit [Read error: Connection reset by peer]
ceene has joined #maemo-leste
ikmaak has quit [Ping timeout: 252 seconds]
mdz has joined #maemo-leste
ikmaak has joined #maemo-leste
<Wizzup> KREYREN: we are not moving everything to qt, we're both gtk and qt in maemo
<KREYREN> Wizzup, noted thanks
ikmaak has quit [Read error: Connection reset by peer]
<Wizzup> whether we will move to gtk3 or not will depend on how well gtk3 works/runs and how much more ram it uses, amongst other things
<Wizzup> we already did a big gtk3 port but the theming was still lacking so we have not migrated other
<Wizzup> s/other/over/
<Wizzup> 09:40 < sicelo> we're moving to hildon to qt? i thought we'd be moving it to GTK3 (at least that's what's on Github)
<Wizzup> we're not
<Wizzup> I don't know why this (going qt only) keeps getting brought up
<Wizzup> KREYREN: personally I don't think gtk2 is going away anytime soon, I think it's stll in debian testing as well, so doesn't seem like it'll go away that quickly
<uvos__> i bring up that defacto all stuff we write is qt atm thats all
ikmaak has joined #maemo-leste
<uvos__> Wizzup: gtk2 is for sure leaving in the near future pretty mutch every distro has drop gtk2 on the agenda, atho its usually stalled by some packages for now
<uvos__> https://archlinux.org/todo/gtk-2-eol/ arch for instance
<uvos__> as allways debian will be last
<uvos__> so it will take a while still
<Wizzup> there is no question if but when, and for now when hasn't happened for a long time
<uvos__> but yeah
<Wizzup> it's definitely going to be in trixie https://packages.debian.org/source/trixie/gtk+2.0
<Wizzup> so that will carry us 3-4 years forward at least
<Wizzup> and then the question is if it will go after that
<uvos__> proubly forking it is better than the current situation anyhow
<Wizzup> so yeah, don't worry about gtk2 now for maemo, we have other things to work on
<Wizzup> I don't think we're going to take over any gtk2 security maintenance though, so don't count on that :)
KREYREN has quit [Ping timeout: 260 seconds]
<sicelo> :-)
uvos__ has quit [Quit: Konversation terminated!]
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
nela has quit [Quit: Ping timeout (120 seconds)]
nela has joined #maemo-leste
mdz has quit [Ping timeout: 260 seconds]
KREYREN has joined #maemo-leste
KREYREN has quit [Ping timeout: 260 seconds]
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
Livio has quit [Ping timeout: 252 seconds]
<arno11> Wizzup: boot issue is back :( seems memory is not the issue (just get lucky yesterday)
Livio has joined #maemo-leste
<dsc_> arno11: is there a document somewhere with your issue?
<dsc_> like github issue
<arno11> not atm
<Wizzup> is is about conversations using more ram on startup?
<arno11> i mean, even with conversations and mafw removed on boot, same issue this morning
<arno11> *screen freeze after H-D completely loaded
<arno11> i've been able to boot on a custom uImage with higher freq (on boot) and lower voltage btw
<arno11> maybe cpufreq / power usage are involved (?)
<arno11> still nothing relevant in logs, time to serial lol
<Wizzup> I suspect OOM still
<arno11> ok
<arno11> but seems after H-D
<arno11> *i mean something loaded after
<arno11> there are no troubles before, even able to navigate a bit before the freeze
<Wizzup> yeah, it is possible and in this case serial will definitely surcace the issue
<Wizzup> surface*
<Wizzup> but to me it feels like getting stuck with little to no ram
<arno11> ok
<arno11> (i still see zram0 activated btw in dmesg)
Livio has quit [Ping timeout: 248 seconds]
<Wizzup> arno11: hm, is /etc/init.d/zram present?
<Wizzup> I have the file but it doesn't start on boot
<arno11> yes i have the file too
<Wizzup> if you type 'sudo rc-update', does it show there in the overview?
<Wizzup> if it doesn't show then it won't run
<Wizzup> If you just see 'zram: Added device zram0' I don't think it is harmful
<arno11> ok
<Wizzup> but if it is something like 'Adding ... swap on /dev/zram0 ...' then it is being activated
<Wizzup> at least that is my understanding
<Wizzup> but you can blacklist the zram module if you want
<Wizzup> actually it doesn't seem to be a module
<arno11> ok
<arno11> seems it's ok
<Wizzup> I can put my n900 on serial today or tomorrow to see if it is some kernel issue
<Wizzup> it would perhaps make sense to see when swap is added
<Wizzup> if it is added late in the process, we can fix it by making it run earlier
<Wizzup> I can only envision this going OOM because there is no swap yet, agreed?
<Wizzup> (and otherwise it is not oom)
<Wizzup> btw, I agree n900 is quite usable now, I do still need to try your transitions :)
<Wizzup> lots of stuff going on irl
<arno11> yep agreed for swap
<arno11> huge diff with custom transitions :)
<arno11> remember that you have to remove 250 freq on each boot btw
<arno11> otherwise it is a way slower
<Wizzup> hm
<Wizzup> I think I manually set it to 250, not 500
<Wizzup> maybe I should try 500 only
<arno11> 500 is far better
<Wizzup> yeah I can see now
<arno11> it means you have no troubles on boot btw ?
<Wizzup> I do, some times
<arno11> ah ok
KREYREN has joined #maemo-leste
xmn has joined #maemo-leste
<inky> my all d4 batteries died. :/
<Wizzup> how did they die?
<inky> well... one after another.
<inky> they all were bad i think. each was working normally for about several months.
<inky> i got a batch, but they didn't look good in the first place.
xmn has quit [Client Quit]
<inky> well this last one works for about 1 hour.
<inky> but it makes the phone unusable.
<inky> will try to search something cheap on ebay again.
<Wizzup> but the phone doesn't power up anymore, or?
<inky> no no it does. just it works for an hour.
<Wizzup> yikes, yeah, ok
<inky> i will finish some freelance and ask for a couple of more repos/jenkins.
<inky> so razr batteries won't work on droid?
<Wizzup> inky: sweet sounds good @ repos
<inky> eb-20? because i see eb-20 for $11.90
<Wizzup> inky: for any battery questions please ask uvos or someone who actually knows these things
<inky> yeah... i think there are no d4 batteries on ebay right now.
<Wizzup> eb41?
<inky> will wait for him. he said something about soldering but i am afraid to solder on batteries.
<Wizzup> aliexpress probably has a bunch but they are not great
<inky> i'll see, thank you!
<Wizzup> yeah my last soldering session on a battery ended up in a minor fire
<Wizzup> :D
<dsc_> lol
<arno11> lol
uvos__ has joined #maemo-leste
<uvos__> if disablein lowg n900 cpufreq states help
<uvos__> maybe we should consider pulling the interactive cpufreq gov.
<uvos__> i gues someone has tried schedutil allready?
<Wizzup> I don't think the low states help with the freeze
<uvos__> should not no
<uvos__> on boot it should be busy enough to be fulll speed anyhow
<uvos__> but i mean if it helps after
<uvos__> might be worth investigateing tuning the gov. vs disableing states
narodnik has quit [Ping timeout: 248 seconds]
xmn has joined #maemo-leste
<arno11> i already tried lot of stuff with cpufreq last year: tuning gov has almost no impact vs disab. states
<uvos__> arno11: what did you try gov wise?
<inky> i got battery from aliexpress, thank you.
<arno11> uvos: long story lol
<arno11> what's your plan with gov btw ?
narodnik2 has joined #maemo-leste
<uvos__> arno11: well maybe find a up to date port of the interactive gov
<uvos__> and merge that
<uvos__> arno11: i presume you tried schedutil?
<uvos__> interactive helped some on the droid 1 back in the day
<uvos__> and since that has the same hw as n900....
<arno11> ok i see
Daanct12 has quit [Quit: WeeChat 4.3.5]
<arno11> nope for schedutil atm
<uvos__> trying schedutil first makes sense i think
<uvos__> since its part of mianline and like interactive it can predict when to ramp up, instead of reacting
<arno11> yep
ceene has quit [Remote host closed the connection]
KREYREN has quit [Remote host closed the connection]
KREYREN has joined #maemo-leste
nmdv has joined #maemo-leste
nmdv has quit [Remote host closed the connection]
nmdv has joined #maemo-leste
uvos__ has quit [Ping timeout: 265 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
nmdv has quit [Ping timeout: 252 seconds]
Livio has joined #maemo-leste
f_ has quit [Ping timeout: 260 seconds]
f_ has joined #maemo-leste
KREYREN has quit [Ping timeout: 260 seconds]
<arno11> Wizzup: uvos: i'm running Leste with lower cpu voltages atm (from fremantle cssu ideal profile) and it works very well (from 0.975v @500 to 1.2v @805)
<arno11> interesting imo
<arno11> not related with boot or cpufreq issues ofc but default voltages seem very high compared to last stuff from cssu
Livio has quit [Ping timeout: 252 seconds]
KREYREN has joined #maemo-leste
KREYREN has quit [Ping timeout: 260 seconds]
uvos__ has joined #maemo-leste
uvos__ has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
KREYREN has joined #maemo-leste
uvos has joined #maemo-leste
uvos__ has quit [Quit: Konversation terminated!]
akossh has joined #maemo-leste
<uvos> arno11: the voltages in mainline where put there by ti, so thats all they really guarantee. While its probable most chips can do better we cant really reduce the voltages just because they work on some/ our devices
<uvos> same thing as overclocking really
uvos has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
uvos__ has quit [Read error: Connection reset by peer]
uvos__ has joined #maemo-leste
<arno11> um, well, ok but i'm not talking about random values i got from a random guy on the web, i'm talking about stuff from cssu, tested by numerous guys (like me) during 14 years now. i doubt TI did the same.
KREYREN has quit [Ping timeout: 260 seconds]
<uvos__> arno11: you may have tested units longer but ti certenly tested more units, that is to say they tested every single one during binning
<uvos__> im not opposed to aving options
<uvos__> but imo during first boot by default everything shal be ran strictly in spec
kiva has joined #maemo-leste
KREYREN has joined #maemo-leste
Livio has joined #maemo-leste
kiva has quit [Quit: Client closed]
uvos__ has quit [Quit: Konversation terminated!]
uvos has joined #maemo-leste
KREYREN has quit [Ping timeout: 260 seconds]
arno11 has left #maemo-leste [#maemo-leste]
uvos has quit [Ping timeout: 264 seconds]
xmn has quit [Quit: ZZZzzz…]
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
branon has quit [Ping timeout: 264 seconds]
System_Error has quit [Remote host closed the connection]
branon has joined #maemo-leste
Livio has quit [Ping timeout: 276 seconds]
xmn has joined #maemo-leste
System_Error has joined #maemo-leste
Wikiwide has quit [Remote host closed the connection]
Wikiwide has joined #maemo-leste
cockroach has joined #maemo-leste
pagurus has quit [Ping timeout: 260 seconds]
pagurus has joined #maemo-leste
cockroach has quit [Quit: leaving]
Rodney- has quit [Ping timeout: 248 seconds]