Livio has quit [Remote host closed the connection]
Daanct12 has joined #maemo-leste
joerg has quit [Ping timeout: 248 seconds]
joerg has joined #maemo-leste
Anasko has quit [Ping timeout: 248 seconds]
mkf has joined #maemo-leste
vectis has quit [Ping timeout: 276 seconds]
<freemangordon>
sicelo: did you manage to gather some logs?
ceene has joined #maemo-leste
xmn has quit [Ping timeout: 276 seconds]
cel_ has quit [Server closed connection]
cel_ has joined #maemo-leste
Anasko has joined #maemo-leste
mkf has left #maemo-leste [#maemo-leste]
joerg has quit [Ping timeout: 244 seconds]
joerg has joined #maemo-leste
ceene has quit [Ping timeout: 252 seconds]
ceene has joined #maemo-leste
<sicelo>
it's the age old adage, that a watched ketthle never boils. so far i can't reproduce. seems to be working fine all the time with your patch only
<sicelo>
which is absolutely weird, since it was 100% reproducible before.
<freemangordon>
Linux devuan-droid4 6.6.92 #1 SMP PREEMPT Sun Jun 15 10:14:03 UTC 2025 armv7l GNU/Linux
<freemangordon>
sicelo: ^^^
<freemangordon>
Wizzup: could you remove icd2 wpa plugin from -devel (and perhaps tinymail, if you are not sure about it)
xmn has joined #maemo-leste
<Wizzup>
yes, in a bit
<sicelo>
freemangordon: I rarely run my own kernel (because of how long it takes to compile) 😆
<freemangordon>
sicelo: sure. however, you said you have no /dev/gsmtty1 (and you see errors from mce), however, I upgraded to the version from -devel and I have /dev/gsmtty1
<freemangordon>
so, could you confirm you don't have /dev/gsmtty1 on droid4
joerg has quit [Ping timeout: 260 seconds]
joerg has joined #maemo-leste
n900 has quit [Server closed connection]
n900 has joined #maemo-leste
akossh has joined #maemo-leste
<sicelo>
Linux devuan-droid4 6.6.92 #1 SMP PREEMPT Sun Jun 15 10:14:03 UTC 2025 armv7l GNU/Linux
<sicelo>
ii linux-image-omap 6.6.92.0-1+4m7 armhf Linux kernel for OMAP devices running Maemo Leste
<sicelo>
ls: cannot access '/dev/ttygsm1': No such file or directory
<sicelo>
ls: cannot access '/dev/ttygsm*': No such file or directory
<freemangordon>
sicelo: it is gsmtty*
<freemangordon>
not ttygsm*
<sicelo>
ah, my bad
<sicelo>
that does exist.
* sicelo
must been drunk. sorry for noise
<freemangordon>
so, where did you see the errors?
<freemangordon>
skol
<sicelo>
in /var/log/maemo/mce.log :
<sicelo>
2025-05-14T16:03:17.555352+02:00 devuan-droid4 mce[2580]: quirks-mapphone: can not open /dev/gsmtty1 [Error opening file “/dev/gsmtty1”: Level 2 halted]
<sicelo>
2025-05-14T16:26:37.733911+02:00 devuan-droid4 mce[2580]: quirks-mapphone: can not open /dev/gsmtty1 [Error opening file “/dev/gsmtty1”: Level 2 halted]
<sicelo>
2025-05-14T16:29:10.558404+02:00 devuan-droid4 mce[2580]: quirks-mapphone: can not open /dev/gsmtty1 [Error opening file “/dev/gsmtty1”: Level 2 halted]
<sicelo>
2025-05-14T16:29:27.346734+02:00 devuan-droid4 mce[2580]: quirks-mapphone: can not open /dev/gsmtty1 [Error opening file “/dev/gsmtty1”: Level 2 halted]
<sicelo>
2025-05-14T16:30:34.537561+02:00 devuan-droid4 mce[2580]: quirks-mapphone: can not open /dev/gsmtty1 [Error opening file “/dev/gsmtty1”: Level 2 halted]
<sicelo>
2025-05-14T17:14:42.895105+02:00 devuan-droid4 mce[2580]: quirks-mapphone: can not open /dev/gsmtty1 [Error opening file “/dev/gsmtty1”: Level 2 halted]
<sicelo>
indeed. guess no issue now. no idea what was happening in May
<freemangordon>
yeah
<freemangordon>
ok
<freemangordon>
so, what with your wifi issue? cannot repro, right?
<sicelo>
yeah for now seems ok even without my patch
<freemangordon>
ok, I'll remove it from the daedalus-devel git repo and will force-push
<sicelo>
sure. please also issue a build. i'll reinstall from repo and see if issue returns.
<sicelo>
for now, i built vanilla 0.1.18 tag, with the DEBUG enabled.
ceene has quit [Remote host closed the connection]
FANTOM has quit [Quit: Connection error?!]
vectis has joined #maemo-leste
rhn_mk1 has quit [Read error: Connection reset by peer]
<sicelo>
the issue is still there, but caught me unawares now, without debug enabled. will do it an see if i can reproduce
rhn_mk1 has joined #maemo-leste
rhn has joined #maemo-leste
rhn_mk1 has quit [Ping timeout: 276 seconds]
Twig has joined #maemo-leste
pere has joined #maemo-leste
_fab has joined #maemo-leste
arno11 has joined #maemo-leste
rhn has quit [Read error: Connection reset by peer]
rhn has joined #maemo-leste
xmn has quit [Read error: Connection reset by peer]
peetah has quit [Quit: -]
peetah has joined #maemo-leste
xmn has joined #maemo-leste
uvos has joined #maemo-leste
<uvos>
sicelo: i dont see this replaceing mces led handling
<uvos>
for one thing mce dosent hardcode anything, its all in the ini files. Granted it cant autodetect it either, it needs to be configured
<uvos>
but led handling is farily complex as we have multiple cases
<uvos>
we have the keyboard led(s) for one that need to be turned on when the slider is uncovered
<uvos>
but we also have leds on devices that need to be on when the display is on but not dimed
<uvos>
and of course the notification led(s) are also handled by mce
<uvos>
i dont see the advantage of letting udev detect the leds vs setting the sysfs path in mces config files, if you sill need to tell mce what eatch led needs to do via its config files
<uvos>
btw mces led handling used to be compleatly hardcoded, but i dehardcoded it long ago and now its a pretty flexible system
<sicelo>
adding led paths in ini file === hardcoding.
gnarface has quit [Quit: Leaving]
<uvos>
I see hardcodeing as something coded in c in this case but thats not important.
<uvos>
I dont see how using upower would do us any good here. As far as i can tell the only difference it would make that instead of setting a sysfs path to a led in mces config file and then settig up its beahvior we would be setting some id of a led (probubly the udev path) in mces config file and then configurein the leds behavior the same way
<uvos>
so all we gained is added complexiy of going though an additional deamon
<uvos>
unless i am missing something
<sicelo>
we don't really need it :-)
<uvos>
i am open to it if there is any advantage
<sicelo>
i was saying it's already there, and maybe we *could* look at using it ... it's a daemon we already use anyway
<uvos>
but i dont see it atm
rhn has quit [Read error: Connection reset by peer]
<sicelo>
as an example, if we support the FxTec Pro1 and Pro1X some day, we will have to set sysfs paths for those. with this, the led would always be `org.freedesktop.UPower /org/freedesktop/UPower/KbdBacklight`
rhn has joined #maemo-leste
<uvos>
ok
<uvos>
but how would mce know that the backlight on this device is covered by a slider
<uvos>
while on other devices it is not
<uvos>
and while that might be nice for the keyboard backlight, other auxilary lights (like the soft touch button lights on mapphones or the extra charging light on droid3) would still have to be handled by mce directly
<sicelo>
but how would mce know that the backlight on this device is covered by a slider <<== it doesn't know this even with the sysfs paths.
<sicelo>
i.e. we'd still need mce for the fancy stuff. point is - we no longer need to know what the sysfs paths are. they're just in one simple dbus interface
<sicelo>
but yeah, was just a (passing) thought
<uvos>
sicelo: yeah but what i am saying is that you still have to configure mce's config files per device, so you dont gain anything over also setting the sysfs name of the led there since currently the sysfs name is also used as the id and you need to use _some_ id to id the led to configure it
<uvos>
sicelo: its nice to know this exists if nothing else (udev led handling)
<uvos>
sicelo: but really shutting off the core is a workaround for a bug in the kernel
_fab has quit [Read error: Connection reset by peer]
<uvos>
before makeing any improvements please check if the workaround is even still nesscary at all
_fab_ is now known as _fab
<uvos>
idealy the kernel would simply park the core when there are few tasks
<uvos>
waiting for cpu time
<sicelo>
this has bitten me when i was compiling on the device
<uvos>
yeah i have this disabled on mine
<uvos>
turning it off while on charger is a no brainer imo
_fab has quit [Ping timeout: 245 seconds]
rhn has quit [Ping timeout: 245 seconds]
narodnik has quit [Quit: WeeChat 4.6.3]
narodnik has joined #maemo-leste
narodnik has quit [Client Quit]
narodnik has joined #maemo-leste
arno11 has quit [Quit: arno11]
FANTOM has joined #maemo-leste
parazyd has quit [Ping timeout: 248 seconds]
parazyd has joined #maemo-leste
vectis has quit [Ping timeout: 252 seconds]
ninjacode has joined #maemo-leste
<ninjacode>
Hi, new here. I am planning to buy a second hand Nokia N900, anyone knows a good source? I have the intention to use the N900 as portable SSH client, thanks
<dsc_>
im not aware of any resellers
<dsc_>
Ebay perhaps your best bet
<dsc_>
or any other 2nd hand website
<ninjacode>
thanks dsc_ I looked to some sellers in Ebay and someones seem legit and providing what it seems almost brand new devices, but unsure since this device is discontinued and somehow old
<dsc_>
I found a n900 on a 2nd hand website in my country, they're selling it for 60eu :)
<dsc_>
as in, I checked just now
vectis has joined #maemo-leste
<ninjacode>
i believe is a very good price if the device is in good condition
<ninjacode>
one question, do you believe is a good use case? as a pocket ssh client? I believe it will be fantastic but honestly I also considered the hackberry
<ninjacode>
but the form factor of the n900 is unbeatable and may fit my use case, but unsure
<sicelo>
as an ssh client, absolutely perfect, if you're happy with the size of the keyboard (may be small, depending on the size of your hands/fingers)
<ninjacode>
as ssh / tmux client i believe it should not consume much resources, reading the maemo docs I am sure it supports to be as ssh client but unsure about if the repo packages will support the modern cyphers and so
<ninjacode>
yes my hands are ok for this keyboard i believe
<ninjacode>
im sure the hackberry with the pi5 will perform much better but for my use case i believe is not needed so much power, i liked a lot the maemo project and ended up here
<ninjacode>
is awesome that the community is still active, giving life to this precious old tech
<sicelo>
of course i'f you're going to be using old Maemo Fremantle, you'll likely not be able to connect to most of the SSH servers used nowadays
<sicelo>
but with Leste, you have up-to-date software.
<ninjacode>
yes thats exactly what I want
<ninjacode>
also had a doubt about battery life, considering my use case as ssh / tmux client, i believe is cool to have the UI features to open the ssh / terminal app, if any but unsure about how battery will perform, i would be using wifi only and if i would have the possibility i would like to programatically disable gsm and bluetooth to not consume power
<ninjacode>
and avoid noise
<ninjacode>
is that possible?
<ninjacode>
maybe some day I decide to use the gsm functions to get internet but i would like to be able to programatically disable the unneded radio devices / unused features in a way that are not consuming power, maybe I am exagerating and for my use case the battery will last for days, but is also a health concern bcause there's already too much radio
<ninjacode>
sources and if we can programatically disable them is always plus
<ninjacode>
dsc_ just messaged you
<sicelo>
bluetooth isn't working on the N900. GSM can be disabled. depending on the state of the battery, you can get around 12 hours of idle time ... it's not as efficient with Leste as it is on Fremantle
enyc_ has quit [Ping timeout: 268 seconds]
<ninjacode>
thanks sicelo
arno11 has joined #maemo-leste
<arno11>
hmm, 12 hours idle ? with a broken battery maybe :P
<arno11>
around 22h idle with wifi on with 1300mA
<ninjacode>
what about active usage as SSH client / tmux terminal with wifi? arno11
<ninjacode>
22h is good for idle
<ninjacode>
also I believe mod can be done for double up battery capacity or maybe just with powerbank
<ninjacode>
battery is not a problem i believe, but I am wondering about out of the box autonomy for this kind of use case, i don't plan to play media or open websites
<arno11>
with a good battery, i think around 10h @ssh client
<ninjacode>
just ssh client , but with UI open for iterate over terminals i guess
<ninjacode>
that's a lot actually
<arno11>
10h UI opened
<arno11>
that is the max imo
<arno11>
*with 1300mA
<ninjacode>
is good
vectis has quit [Ping timeout: 248 seconds]
<ninjacode>
just wondering, do you know any good source to get a nice N900 ? arno11 I am in EU
<arno11>
in 2025, i really don't know sorry
<arno11>
bbl
<Wizzup>
probably the local ebay for your country
<ninjacode>
yeah, is difficult to find realiable source
<Wizzup>
I think the n900's on ebay from china seemed ok
<Wizzup>
at least, I heard some folks got them and were happy
<ninjacode>
yes, that's what I see
enyc_ has joined #maemo-leste
<ninjacode>
for about 100€
Twig has quit [Remote host closed the connection]
akossh has quit [Quit: Leaving.]
<Wizzup>
right
<Wizzup>
not cheap for a not very powerful device
<Wizzup>
but for support/nostalgia reasons :)
uvos has quit [Quit: Konversation terminated!]
<ninjacode>
I believe it is a good productivity tool specially for the keyboard and form factor
<ninjacode>
can't find anything on pair with new devices
<ninjacode>
my use case is mostly for ssh'ing
<ninjacode>
also I trust more the old tech than the new one
<Wizzup>
yeah, there's the droid 4 mostly I guess :)
<ninjacode>
not sure if maemo is privacy oriented but i believe just for not be attatched to google is a plus
<ninjacode>
is the droid 4 better suported in memo than the n900 ?
<ninjacode>
maemo * sorry for the typo
<ninjacode>
wich one would be better?
lyubov has quit [Ping timeout: 276 seconds]
lyubov has joined #maemo-leste
<ninjacode>
I've read that the N900 is better suported but unsure
<arno11>
ATM support is quite similar but droid 4 is 4 times more powerful
<arno11>
but VERY difficult to find
<ninjacode>
true arno11 thanks
<arno11>
but for ssh only, N900 is enough imo
<sicelo>
a few more things work better on Droid 4, e.g. bluetooth works, and power management is better. but yeah, since the goal is SSH, N900 is OK, especially for EU, where obtaining Droid 4 might be harder
<ninjacode>
yes, finding that is difficult to get in good condition
<sicelo>
it was mostly made for US market, so yeah
<ninjacode>
guys, i did not tested the maemo but is obvious that you did an awesome work here, congrats
<ninjacode>
i did not tested the maemo (yet)
<ninjacode>
as soon as get a device i maybe dig into the sources to figure things out but honestly for now my understanding about how the thing works behind the scenes in this kind of work you made is very limited, im experienced linux user tho
<ninjacode>
i've seen the motorola droid 4 was one of the first to introduce 4g and i don't like so much g's, i would prefer the N900 also because is more realistic to get a good condition unit, gsm is not a priority for me
<sicelo>
there is also a VM, which can give you an idea of the system
<sicelo>
the 4G modem doesn't work actually
<ninjacode>
yes but maybe is on by default, unsure about it
Pali has quit [Quit: Pali]
<sicelo>
well, it's more complicated than that. to make it short - it only ever worked on Verizon USA, tightly locked to their frequencies, etc.
<ninjacode>
I understand that but I mean at low level the module may still be on despite is not connected to any network, but totally unsure about that
<ninjacode>
my main phone is mostly off because that reasons, the frequencies they use make people getting sick, but we never know if they'r still emmiting there are experiments that people do and many claim that even with the smart phones powered off, they still emit, that's why a N900 makes also much more sense bcause has removable battery
arno11 has quit [Quit: arno11]
<ninjacode>
i also power off the wifi and told the neighbor to do the same, most ppl say its safe, that everything is cool, but the truth is that frequencies interfer with organic cells own-frequencies, i know many of you may be aware about that also, most ppl may think im paranoic lol
<ninjacode>
srry for oftopic but thats also one of the main reasons i wanted to get some of this old-tech devices, because hopefully they are less powerful / harmful in this aspects
<ninjacode>
i believe, for example that the N900 is like half or more than a half of the power of the new devices modems