Anasko has quit [Read error: Connection reset by peer]
lul4 has quit [Client Quit]
Anasko has joined #maemo-leste
g4rrgl3n0m4d has quit [Remote host closed the connection]
HappyNewYear2025 has quit [Ping timeout: 244 seconds]
hawer has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
xmn has quit [Ping timeout: 260 seconds]
Anasko has joined #maemo-leste
xmn has joined #maemo-leste
xmn_ has joined #maemo-leste
xmn__ has joined #maemo-leste
xmn has quit [Ping timeout: 248 seconds]
xmn__ has quit [Ping timeout: 248 seconds]
xmn_ has quit [Ping timeout: 248 seconds]
tvall has quit [Ping timeout: 244 seconds]
joerg has quit [Ping timeout: 244 seconds]
tvall has joined #maemo-leste
joerg has joined #maemo-leste
vectis_ has quit [Ping timeout: 244 seconds]
vectis_ has joined #maemo-leste
_fab has joined #maemo-leste
ceene has joined #maemo-leste
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
ungeskriptet has joined #maemo-leste
_fab has quit [Ping timeout: 252 seconds]
_fab has joined #maemo-leste
<mkf>
freemangordon: hm. ok
Anasko has quit [Remote host closed the connection]
Anasko has joined #maemo-leste
_fab has quit [Quit: _fab]
_fab has joined #maemo-leste
_fab has quit [Remote host closed the connection]
_fab has joined #maemo-leste
Juest has quit [Ping timeout: 252 seconds]
Juest has joined #maemo-leste
pere has quit [Ping timeout: 248 seconds]
Juest has quit [Ping timeout: 272 seconds]
<mkf>
arno11: ssh on u3 feels faster... :o
Juest has joined #maemo-leste
Twig has joined #maemo-leste
Twig has quit [Quit: Leaving]
Twig has joined #maemo-leste
pere has joined #maemo-leste
Juest has quit [Ping timeout: 252 seconds]
Juest has joined #maemo-leste
_fab has quit [Ping timeout: 248 seconds]
nela has quit [Quit: bye]
nela has joined #maemo-leste
<Wizzup>
freemangordon: do you need me to do something wrt elogind/xorg?
<Wizzup>
or seatd
<freemangordon>
no
<Wizzup>
ok
<freemangordon>
I am just busy with RL job
<Wizzup>
:)
<Wizzup>
I know the feeling :D
<Wizzup>
I'll work on the few remaining pkgs in the meantime then
<freemangordon>
yeah, will work either tonight (if I have energy left) or during the weekend
<Wizzup>
ok
<mkf>
is there anything i can do with a broken chager port to improve the experince? (i already have those univeral external battery chargers, but i wonder if somehing else can be done)
<mkf>
it feels very raw to disconnect battery, charge it externally, etc
<mkf>
oh and, it requires power plug, can't do it with a powerbank.
<mkf>
is there a better solution given how many broken n900s are there?
<Wizzup>
I can't think of one
<mkf>
oh well
uvos__ has joined #maemo-leste
halftux has joined #maemo-leste
<halftux>
mkf: I never tried but if you have an old battery you could get out the connection with the chip and solder a power supply to the contacts where the battery was connected. But for sure you need the chip.
<halftux>
Wizzup: I tried the first time the maemo leste image builder for rpi2 and rpi3 but was not successful
<halftux>
Do you know if it should run flawless for rpi? Are the ready to download images from meadevu working for sure for the rpis?
Livio has joined #maemo-leste
arno11 has joined #maemo-leste
<arno11>
mkf: not a surprise @u3 :P
ceene has quit [Ping timeout: 260 seconds]
<Wizzup>
no, I don't know if that is the case
<Wizzup>
it should not be too hard but I believe debian got better rpi support wise
<Wizzup>
we just need some firmware and bootEnv.txt or whatever rpi needs
<Wizzup>
that might just not be set up
<Wizzup>
how did the image builder fail for you?
<arno11>
mkf: then your install should work far better if you follow the wiki: expandcard, check if sdswap is ok, reboot, block apt-worker, add .nomedia in $home, dist-upgrade to devel, reboot, adjust transitions.ini (block mafw optionally)
<arno11>
ah, and remove lock pin with ofono scripts if you use a sim card. it avoids hildon-desktop to be unresponsive for a while on boot...
<arno11>
note that boot takes around 2min and hildon is still unresponsive for another 1min30, even with tweaks. if you touch the screen before that, the device can be unresponsive for several min or very very slow
<mkf>
um. i have ran out of battery during the update, now it says no applications are found...
<mkf>
thanks halftux
<uvos__>
i see we are well underway with the debain upgrade
<uvos__>
unfortionatly i have been fully swamped lately
<Wizzup>
yeah we're pretty much there, few things remain
<uvos__>
great
<Wizzup>
I made some tools to make it easier next time hopefully, automate more of it
<Wizzup>
for trixie the main thing will be gconf I think
<uvos__>
anything specific in my domain package mainter wise?
<uvos__>
Wizzup: yeah
<Wizzup>
I don't think so, I think things just built mostly
<Wizzup>
there might be some extras
<uvos__>
ok
<Wizzup>
also, we have a qt vkb using h-i-m now (wip but it works)
<uvos__>
oh sweet
<uvos__>
usefull jib
<uvos__>
(on bionic)
<Wizzup>
I use it on mz617 with jib
<Wizzup>
it's not in the meta pkg yet though
pere has quit [Ping timeout: 265 seconds]
<uvos__>
i should make an install procedure for that
<uvos__>
(mz617)
<Wizzup>
yeah
<Wizzup>
we have the images now but the wiki lacks instructions still
<uvos__>
i think instructions are not enough on mz617
<uvos__>
we need something that comes with the tiny image
<uvos__>
and installs the full image
<uvos__>
like a small qt app or something
<Wizzup>
that would be nice
Livio has quit [Ping timeout: 264 seconds]
joerg has quit [Ping timeout: 265 seconds]
joerg has joined #maemo-leste
<mkf>
Wizzup: any idea? :(
<uvos__>
your dervice crashed while updateing?
<uvos__>
what sais no applications found?
<mkf>
hildon menu
<mkf>
yeah it ran out of battery during updating, i've ran dpkg-configure -a
<mkf>
also dpkg-reconfigure for the package in which battery ran out
<uvos__>
hmm
<uvos__>
try reinstalling hildon-desktop and home. Maybe the icon cache got corrupted, you can regenrate it but im not sure how of the top of my head
_fab has joined #maemo-leste
<mkf>
did so, didnt worked. :(
<freemangordon>
uvos__: hi!
<freemangordon>
did you see my mail re TS buttons patch?
<freemangordon>
uvos__: re your domain: linux 6.12
<freemangordon>
I saw you did something, but I assume you gave-up on audio stuff
<mkf>
ah, worked after reboot. nice.
<halftux>
Wizzup: builder fails for arm64 because iphb-dkms dpends on wrong arch for linux-headers
<uvos__>
freemangordon: I did but i dont think this will change anything
<freemangordon>
uvos__: did they refuse that patch or just silently ignore it?
<uvos__>
i have tried upstreaming that driver 4 times in total and it has been silently ignored every time
<uvos__>
i actually dont remember how far i got with 6.12
<freemangordon>
any reason for that?
<uvos__>
have to look at the branch
<uvos__>
freemangordon: no idea i get no feedback so i cant really say
<freemangordon>
hmm...
<uvos__>
maybe they just hate the idea of a driver that filters another driver but they never said so
<freemangordon>
well, something is not about right
<freemangordon>
I sent a patch series that properly implements jack detection support on cpcap, so far only DT change was commentged
<freemangordon>
*commented
<uvos__>
freemangordon: ok great
<uvos__>
i saw that
<uvos__>
one thing is
<freemangordon>
but, there were holidays, so...
<uvos__>
i think android also keeps VAUDIO disabled
<freemangordon>
no
<freemangordon>
I tested it
<uvos__>
ok
<freemangordon>
it is always-on on board file
<uvos__>
ok
<freemangordon>
but please, if you have concerns, double check
<freemangordon>
in any case, if you disable VAUDIO, jack detection does not work
<uvos__>
yeah i know
<uvos__>
but it did work in practice since the irq just comes when audio is played so it swiches then
<uvos__>
i thought i did see this behavior too on android userland
<freemangordon>
so we keep it always on and raise the "low power" bit when we don;t need it
<uvos__>
(ie switch hapens on first play)
<freemangordon>
I doubt
<freemangordon>
see audio control reg in idle
<freemangordon>
(on android)
<freemangordon>
it has 'low power' bit on
<uvos__>
ok
<uvos__>
wel its fine then
<uvos__>
about the led patches
<uvos__>
they rejected those, they dont want them as platform devices, they want all the leds configured on all devices (even when the led is not installed on the device)
<freemangordon>
that kinda make sense
<freemangordon>
despite is is boring
<freemangordon>
do we have any real issue with that?
uvos__ has quit [Ping timeout: 276 seconds]
System_Error has quit [Remote host closed the connection]
<Wizzup>
halftux: on wronch arch? hmm
<Wizzup>
halftux: I'll try to look this weekend, I also want to fix sunxi imagees
<halftux>
Wizzup: for rpi3 and rpi4 arm64 the control file is missing depends linux-headers-arm64 for package iphb-dkms
<uvos>
freemangordon: but i dont like it that mutch and the current patches have allways rebased cleanly so far so have not goten to enableing all the channels we need in the upstream aproved way
<freemangordon>
uvos: but, we carry too many patches
<freemangordon>
if we can drop some of them, why not?
<uvos>
sure
<uvos>
but we need to update the driver to support all the channels regardless
<uvos>
so we need to seperate the mfd -> palatform driver changes from the new channels
<Wizzup>
halftux: you could also try to build a tiny img instead
<Wizzup>
that might not depend on iphbd
<Wizzup>
final note, the current rpi kernel in arm sdk is probably really old, which is not great either
<halftux>
how i build a tiny image?
<halftux>
I would like to update the kernel in arm-sdk is it enough to edit the raspberry-piX.sh file?
<Wizzup>
halftux: there's a value tiny_image in the .config or the .blend file
<Wizzup>
halftux: you can do that, but it won't solve the iphd issue
<Wizzup>
we should really never build a kernel in arm-sdk
<Wizzup>
iphbd wants a kernel package with headers and everything, and if you just build some kernel in arm-sdk it won't be packaged
<Wizzup>
maemo never had a rpi kernel package, but we should have one, or just use the debian one at least
<halftux>
so the kernel is pulled from leste repository or devuan?
<halftux>
what I need to modify to get a custom kernel package or a kernel package from different location integrated in the image?
<Wizzup>
16:29 < halftux> so the kernel is pulled from leste repository or devuan?
<Wizzup>
right now, neither.
<Wizzup>
there is no kernel pulled
<Wizzup>
that's the point
<Wizzup>
but *debian* has a rpi image
<halftux>
so I need to manually modify a leste image and take the debian image as a source?
<Wizzup>
depends on what you are trying to do?
<halftux>
I would like to run maemo leste on the rpi2/3/4 and for the future make it happen that the image builder builds images for these
<Wizzup>
then you need to take a debian or devuan os and work on the packaging for it
<Wizzup>
but as stated, I think debian -already has- kernels for the rpi
<Wizzup>
so we might not have to do that work at all
<Wizzup>
freemangordon: wondering if we can use the pine64 kernel repo for armhf sunxi as well
<Wizzup>
we'd have to rename the pkg though
<Wizzup>
halftux: in any case, it's probably not too hard, and we had this worked a long time ago, just before iphdb was packaged and now it's a lbocker
<halftux>
as far as I see rpi3 uses standard kernel but needs these non free blobs dtb files manually integrated
<Wizzup>
I can't give exact guidance because I need to look at some stuff myself because I can give good guidance
<Wizzup>
hm, I saw debian fw pkgs for it
<Wizzup>
maybe try one of the debian rpi images and see how it goes?
<Wizzup>
that will tell us how that works at least
<halftux>
I dont want to put additional load onto you I will try to investigate