akossh has quit [Ping timeout: 260 seconds]
xmn has quit [Quit: ZZZzzz…]
thunderysteak has quit [Ping timeout: 256 seconds]
mrkrisprolls has quit [Quit: Tchussss!]
xmn has joined #maemo-leste
mrkrisprolls has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
xmn has joined #maemo-leste
SuperMarioSF has joined #maemo-leste
pagurus has quit [Ping timeout: 268 seconds]
RedW has quit [Quit: huh upgrades]
pagurus has joined #maemo-leste
RedW has joined #maemo-leste
joerg has quit [Ping timeout: 246 seconds]
Juest has quit [Quit: Client closed]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
SuperMarioSF has quit [Quit: Client closed]
ceene has joined #maemo-leste
pere has quit [Ping timeout: 248 seconds]
pere has joined #maemo-leste
xmn has quit [Ping timeout: 268 seconds]
ikmaak has quit [Read error: Connection reset by peer]
ikmaak has joined #maemo-leste
Twig has joined #maemo-leste
loumber has joined #maemo-leste
loumber has quit [Remote host closed the connection]
uvos__ has joined #maemo-leste
pere has quit [Ping timeout: 268 seconds]
<sicelo> maybe leste should look at using CONFIG_LEDS_TRIGGER_PATTERN then use mce or something else to provide the led patterns
<Wizzup> does this support phones like the n900 with dedicated hw?
<Wizzup> or do you mean just moving some of it to the kernel for non-specialised hw?
<sicelo> that looks like it supports nearly all leds
uvos__ has quit [Ping timeout: 256 seconds]
<sicelo> i guess others may feel doing it in hw leads to device-specific hacks
<Wizzup> supporting nearly all leds doesn't mean it supports the n900 specific led driver, right?
<Wizzup> the one that does all the patterns without hw wakeups
<sicelo> yes it doesn't.
<sicelo> but i am not sure ... you want to keep n900's hw setup?
<Wizzup> we support it in mce
<Wizzup> and it definitely saves power, no?
<sicelo> oh ok. i am not averse to the n900 interface. i think it's cool actually
<sicelo> just thought this could help those devices which don't have such functionality, e.g. pp
<Wizzup> right
<Wizzup> so will it have less wakeups or something, or?
<sicelo> no idea tbh :-)
<Wizzup> I'm trying to see how it helps, other than perhaps less context switches for mce
<Wizzup> since we already have a generic led sys interface
<sicelo> you tell sysfs the pattern you want and kernel handles it by itself
<sicelo> i know d4's cpcap can d patterns in hw too, but seems the function isn't currently exposed in the driver
uvos__ has joined #maemo-leste
<uvos__> so cpcap can do patterns in hw (well in fw android dose it in fw)
<uvos__> the problem with the pattern trigger is it creats a lot of wakeups when used without any hw support, mces implementation wakesup alot les at the expense of being able to do alot less
<uvos__> so this dosent really help us, if the n900's hw accel works via pattern trigger thats cool
<uvos__> but theres no real incentive to replaceing mces code that uses the hw here
uvos__ has quit [Ping timeout: 260 seconds]
pere has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: Received SIGTERM]
norayr has joined #maemo-leste
<Wizzup> uvos: imho we could have closed that ticket, but fine to keep it open if you want :p
uvos__ has joined #maemo-leste
<uvos__> well as you mentioned bluetooth dosent work
<uvos__> also that bug contains plenty of usefull information for a proper solution
<uvos__> maybe we can rename it
<Wizzup> fine by me
<sicelo> ok. so how are we planning on using the leds for notifications in leste, on devices other than N900?
<sicelo> e.g. droid 4
<Wizzup> don't we have this working already? or?
<sicelo> no idea. never seen led doing anything useful on my d4, except steady green when charging, and steady white when powering off
xmn has joined #maemo-leste
<sicelo> anyway, it's not very important to me atm ... i just came across the kernel PATTERNS while looking at feedbackd source
<sicelo> Wizzup: you said to ping you regarding our HSI/ISI issue. hope you'll have some spare cycles maybe weekend
<uvos__> the leds work fine on d4
<uvos__> works with modest
<uvos__> otherwise we just have nothing that activates any patterns
<uvos__> same is true for all devices
<BlagovestPetrov[> Wizzup: https://bpa.st/QGWQ I have ignorred the warning with the flags but it warns about possible buffer overflows
<BlagovestPetrov[> libicd-wireguard
Juest has joined #maemo-leste
<Wizzup> BlagovestPetrov[: let me see if I can fix the code
<Wizzup> btw the changelog entries lacks some spaces I think
<BlagovestPetrov[> right, empty line
<BlagovestPetrov[> fixed
<BlagovestPetrov[> I don't see calendar-ui-widgets in GitHub
<Wizzup> freemangordon: I'm almost done trying to port eds-backend-telepathy, but will need you to review it
<BlagovestPetrov[> tinymail is also failing because of multiple declarations. I'm trying to fix it..
<Wizzup> BlagovestPetrov[: no, I cannot build calendar-ui-widgets because it all depends on eds-backend-telepathy
<Wizzup> anything that uses abook cannot be built
<Wizzup> which is most of the remaining packages
<BlagovestPetrov[> but I don't even see it as a repository
<BlagovestPetrov[> it may be part of another package
<BlagovestPetrov[> it's not even in beowulf
<freemangordon> BlagovestPetrov[: hmm? https://github.com/maemo-leste/calendar-ui-widgets
<BlagovestPetrov[> weird
<freemangordon> see what apt-get source calendar-ui-widgets in beowulf will tell you :p
<BlagovestPetrov[> I tried only with apt-cache :)
<freemangordon> Wizzup: ok, will try
<freemangordon> well, M$
<BlagovestPetrov[> :D
<uvos__> the search is toaly uesless
<freemangordon> no idea why it would not be visible/searchable
<uvos__> it dosent even find "sdl" in upstream forks
<freemangordon> uvos__: usually it works
<uvos__> altho we have libsdl1.2 and libSDL2 as repos
<uvos__> freemangordon: no this has never worked
<uvos__> it randomly dosent work for certain querys
<uvos__> and for those querys it never has or will
<freemangordon> ok
<uvos__> this has also been reported to gh often (at least you can find posts all over)
<uvos__> with no improvement
<uvos__> so yeah M$
<BlagovestPetrov[> windows update on one of the data nodes..
<uvos__> there for an example
<uvos__> the same problem also exits when searching though code on gh
<uvos__> so this causes lots of false conculstions
<uvos__> like "this function is never used" etc
<uvos__> its just horrible
<freemangordon> BlagovestPetrov[: Wizzup: WTF is actually this https://github.com/maemo-leste/libicd-wireguard/blob/master/src/libicd_wireguard_config.c#L161 ?
<freemangordon> gcc is absolutely right
ceene has quit [Remote host closed the connection]
<freemangordon> why is strncat used in first place ?
<uvos__> freemangordons head explodeing
* freemangordon gets stack overflow
<uvos__> yeah this function hat alot to gain from using g_str_* functions :P
<freemangordon> BlagovestPetrov[: do you have an idea how to fix that properly? and if you have, do you want to?
<freemangordon> especially g_str_concat ;)
<BlagovestPetrov[> I'm not sure
<freemangordon> ok, I will fix that
<Wizzup> freemangordon: just a sec, I made it compile, will push momentarily
<freemangordon> yeah
<uvos__> on the bright side, its probubly very fast this way compeard to using g_str_* :P
<uvos__> way less mallocs
<Wizzup> freemangordon: the main thing that needs a look I think is 'status' handling when it's actually not an error
<Wizzup> there is no 'new variant' of E_DATA_BOOK_STATUS_SUCCESS
<Wizzup> which might mean the respond functions shouldn't actually use e_client_error_create at all, and rather perhaps pass NULL ?
<Wizzup> I suppose the old e_data_book_create_error function returned NULL if status was E_DATA_BOOK_STATUS_SUCCESS
<Wizzup> looks like it
<Wizzup> e-book-backend-ldap.c does this with ldap_error_to_response
<freemangordon> uvos__: right... until you get buffer overflow :)
<freemangordon> Wizzup: just a minute to push WG fix
<Wizzup> freemangordon: I think what I said is above is correct and the status handling needs some additional ctx
<freemangordon> I think this whole code needs review
<Wizzup> ok, well, I need to go and arrange some dinner for myself, so I'll be back in an hour or more
<Wizzup> I can rework the status handling as above, but please look if you see other problems
<Wizzup> bbl
<freemangordon> ok
<freemangordon> BlagovestPetrov[: could you pull https://github.com/maemo-leste/libicd-wireguard master and try to compile it? If it is ok, please, pull in/release for beowulf-devel as well
<Wizzup> (he doesn't have privs to release or push branches atm)
<Wizzup> (I've been doing it)
<freemangordon> ah, ok
<freemangordon> Wizzup: E_CLIENT_ERROR_INVALID_ARG = 0
<freemangordon> so setting status to 0 is not ok, IIUC
<BlagovestPetrov[> it's ok in master
<BlagovestPetrov[> tested..
<freemangordon> great
Juest has quit [Quit: Client closed]
<freemangordon> so yeah, it seems e_data_book_respond_remove_contacts() (and others) shall be called with NULL error in case of success
<Wizzup> sicelo: btw yes I should have time tonight
<Wizzup> freemangordon: ok, will rewrite the logic then
Guest224 has joined #maemo-leste
<Guest224> Is hildon-connectivity-mobile inside in any _stable_ SD-card images yet?
<uvos__> no
<sicelo> Guest224: what device are you using
<sicelo> Wizzup: great. looking forward
<Guest224> pinephone
<Guest224> I also have N900..and might soon Droid4.
<sicelo> the full package :-)
<Guest224> but now running PostmarketOS in pinephone, cause it works on the road, I hate PMOS, but it has 4G and when Leste has working connection in _stable_ then I change permanently to it.
nerdcore has joined #maemo-leste
<sicelo> i don't think you should *hate* pmOS ... it's fine to not like it though
<sicelo> why do you feel you need 'stable' specifically?
<nerdcore> i quite like pmOS, but it's been mashing my SMS messages together, and mislabeling them :(
<nerdcore> gonna try ML instead I think
<nerdcore> I see that there are ML instructions on building a custom image, but they do not explain how to replace the default user/pass... Is that easily done?
<Guest224> sicelo: ok..hate might too strong word...but gui is horrible...when it is stable then it is "stable enough" for me, for beta testing :)
<sicelo> nerdcore: it's not pmOS mashing your messages ... most probably modem-manager. actually, to a large extent, pmOS doesn't make software
<sicelo> Guest224: you may want to consider devel, if you reall want to help with testing ;-)
<Wizzup> chimaera will have modem stuff by default
<sicelo> Guest224: pmOS doesn't have a gui ... which gui do you find horrible? phosh, plasma mobile, or sxmo?
<uvos__> hell for a while it had hildon-desktop
<nerdcore> I like phosh because elsewhere I run GNOME, so it feels very comfortable :)
<nerdcore> sicelo: appreciate the input. It's a PinePhone (not Pro) device, so do you expect I may have similar issues in ML?
<nerdcore> I tried a couple different firmwares, to varying results.
<Guest224> sicelo: thats true...I have tested phosh and plasma...there was some reason I didn't test sxmo (I dont remeber why..)
<nerdcore> i3/sxmo has a steep learning curve ;)
<sicelo> nerdcore: i don't know. ML uses ofono. maybe the message handling is different there ... not really sure. as for which distro to choose up to you. we're in ML chat so choose ML :-p
<nerdcore> yeah I've only tried 2-3 OS on the device so far. I know buZz from elsewhere so ML seems like a good choice ;)
<sicelo> great then
<nerdcore> its so easy to drop a new OS onto microSD, and leave the internal storage untouched. Great for testing new OSes
<nerdcore> will probably try the custom image builder too, for max authority heh
<sicelo> of course ML's DE is the lightest mobile DE, so I guess it really is the better choice. i read pinephone cpu isn't as beefy as people would like
<nerdcore> yeah, defoz chunky running phosh
<nerdcore> I mean, when I click the phone icon in the Messages application to call that person, it takes around 60s to launch the Phone application and then dial the number :(
<nerdcore> but it works ... eventually lol
<Wizzup> sicelo: no ncpu is ever as beefy as people like
<buZz> sicelo: i think pp nonpro has quite a slow gpu specifically
<buZz> the panfrost/lima stuff helps a lot though
<Wizzup> bottom line is that low footprint matters
<Guest224> nerdcore: I tested ML shortly in september and it is fast in Pinephone...only reason why I moved to PmOS was that mobile-connectivity wasn't ready to dayly use.
thunderysteak has joined #maemo-leste
<nerdcore> does ML use glibc? pmOS is using MUSL C and giving me some specific issues as well
<Wizzup> yespglibc
<Wizzup> it,s just debian/devun
<nerdcore> Guest224: "mobile connectivity" such as sharing your 4G with a laptop?
<buZz> Guest224: i've been daily'ing ML on d4 with data since ~april
<Wizzup> we're porting to bullseye atm
<nerdcore> excellent. I have some time in the coming week, so keen to try ML. I'll stick around. :)
<Guest224> nerdcore: plain 4G connection.
<buZz> yay :)
<freemangordon> still, mobile connectivity is WIP
<nerdcore> hmm, I do use the mobile data. I turned my home wifi Off last year ;)
<buZz> the whole thing is WIP :P
<freemangordon> connectivity as such works
<nerdcore> does /usr/bin/ssh work?
<freemangordon> but, UI for changing PIN for example does not
<freemangordon> or, manualy selecting operator
<freemangordon> etc
<nerdcore> because I can just run lynx on a VPS haha
<freemangordon> chromium works pretty well
<buZz> yeah, fast too
<freemangordon> but, you have to connect a keyboard
<buZz> and nice touch support
<freemangordon> otherwise it is very hard to enter the url ;)
<nerdcore> Is it possible to import a CSV or VCF file into the contacts application in ML? That would save me a lot of setup time
<buZz> maybe get a d4 to remote control the pp?
<buZz> hmm
<Guest224> nercore: I can recomend Pinephone keyboard for Pinephone.
<freemangordon> nerdcore: vcf is ok
* buZz suddenly sees a cyberdeck made of cellphones running leste
<nerdcore> sometimes I use my PP via its serial UART in the 3.5mm headphone jack. I connect it to a rpi and run minicom
<freemangordon> actually it has UI to import a directory containing vcfs
<freemangordon> so you import all contacts at once
<nerdcore> excellent. Thanks freemangordon that will save me a lot of time. I had to type all my contacts by hand into pmOS :(
<buZz> the pp i borrowed had to go back :(
<nerdcore> i have a USB-C hub here with all sorts of connections like RJ-45 ethernet, and HDMI. Makes it possible to hook my PP up like a PC, but the battery dies in < 2h
<buZz> still doubting any new device, d4 is great but limited, pp same, pocophone f1 looks cool in support but no hw keyb
<buZz> specs of poco look good too
<nerdcore> i have a small BT keyboard here, but I find it equally as frustrating as OSK
<Guest224> freemangordon: Is that vcfs importer tool on default SD-image, it is something that should?
<sicelo> buZz: yes the sdm845 kernel support is maturing fast
<freemangordon> it is part of the addressbook
<freemangordon> not a separate tool
<buZz> sicelo: do you think that device will get some futureproofing through it?
<sicelo> meaning?
<buZz> will-it-mainline
<buZz> hehe
<buZz> like how n900 can nowadays boot straigthup debian installers
<Guest224> freemangordon: that is good!
<sicelo> mainline? I was talking about sdm845 mainline :-)
<buZz> hehe ok
<buZz> i have good hopes, but really needs some keyb, touchscreen input makes me feel demented, lol.
<Wizzup> nerdcore: you can also use syncevolution for contacts
<buZz> ML + selfhosted radicale = syncable agenda and contacts to my desktop and laptops
<buZz> 'cloudfree'
<Guest224> Cloudfree sounds always good.
<Guest224>  ad text:"With Maemo Leste you can see the sun, because you don't have to stick in clouds."
<buZz> Guest224: we need more memes
<buZz> 'de-mist your phonelife'
<Guest224> or just "cloudfree phonelife"
<buZz> 'get ready to uncloud, maemo leste is coming'
<buZz> haha yeah and then we can post pictures of ppl with stuff like 'my cellphone is a minecraft server' and some blurb
<Guest224> "You can use Maemo Leste in offline, when you want."
<Wizzup> freemangordon: please re-check porting-wip
Guest224 has quit [Quit: Client closed]
norayr has quit [Quit: Gateway shutdown]
norayr has joined #maemo-leste
<Wizzup> freemangordon: merged it to master
Guest224 has joined #maemo-leste
<freemangordon> Wizzup: sorry, was having dinner
<Wizzup> np
<Wizzup> the only remaining question was about E_DATA_BOOK_STATUS_BOOK_REMOVED
<Wizzup> I quote:
<Wizzup> I wasn't sure how to map E_DATA_BOOK_STATUS_BOOK_REMOVED - I went for
<Wizzup> E_BOOK_CLIENT_ERROR_NO_SUCH_BOOK for now
* freemangordon checks if there is more appropriate status
<tmlind> uvos: got output on xt910 lcd with some copy paste android code :)
<tmlind> so the backlight controller is integrated into the panel
<tmlind> and the panel init sequence is a bit crazy set of mip dcs writes..
_uvos_ has joined #maemo-leste
<Wizzup> tmlind: sweet :)
<_uvos_> tmlind: sweet :)
<_uvos_> maybe this is true on d3 aswell
<Wizzup> _uvos_: echo
<_uvos_> i wasent able to find who dose the backlight there
<Guest224> nerdcore: btw..if you are frustrating battery life with USB-C devices then you should think Pinephone Keyboard it gives extra battery life (it has 6000mAh battery inside)..but you cannot charge when useing USC-C devices or at least this page saying it: https://talk.maemo.org/showpost.php?p=1574678&postcount=25
<tmlind> heh now need to sort of understand what is going on.. it's the panel-mapphone.c dsi_mipi_430_cm_540_960_amoled_panel_enable
<_uvos_> schould just look in android kernel
<Wizzup> Guest224: yeah I found out the hard way and broke mine
<nerdcore> ty
<Guest224> Wizzup: :( ..it should have big warning manual.
<freemangordon> Wizzup: hmm, is mixing EClientError with EBookClientError ok?
<tmlind> _uvos_: well bunch of the mipi commands are now implemented in a generic way, see "MIPI DCS commands" in include/video/mipi_display.h
<tmlind> _uvos_: maybe check the panel id for d3?
_uvos_ has quit [Ping timeout: 252 seconds]
<tmlind> xt910 has panel_id=0x90006, so you can grep for 0x00090006 in android panel-mapphone.c
<freemangordon> Wizzup: like, e_client_error_create() wants EClientError, but you do https://github.com/maemo-leste/eds-backend-telepathy/blob/master/src/e-book-backend-tp.c#L3141
<Wizzup> freemangordon: good question, probably not...
<tmlind> i added motorola-mapphone-xt875-xt984-common.dtsi and moved the lcd regulator and backlight there
<freemangordon> Wizzup: which repo is EDS?
<freemangordon> upstrem-forks?
<Wizzup> yes
<Wizzup> evolution-data-server
<freemangordon> not visible :D
<freemangordon> umm
<freemangordon> 404
<Wizzup> maybe not upstream-forks then
<freemangordon> well, this is not 'upstream-forks' ;)
<Wizzup> yup, I thought it was there
<freemangordon> np
<Wizzup> you can move it and I can update the jenkins job
<freemangordon> not important
<freemangordon> but, see what ldap does
<Wizzup> yeah, I saw that basically after I ported the code
<freemangordon> ok :)
<freemangordon> if you want, I can fix it, but tomorrow
uvos has joined #maemo-leste
<Wizzup> ok, I'll see if I feel like it today
<Wizzup> rtcom-eventlogger-ui also needs changes :(
<Wizzup> gcc detects that one case of the switch was not covered
<freemangordon> I really like this gcc10, not a single false positive so far
<Wizzup> yes, it's good in that sense
<Wizzup> annoying otherwise :P
<freemangordon> well, yeah, but at least something we get help from upstream :)
<uvos> tmlind: xt984?
<uvos> this is typo in irc only i hope :P
<Wizzup> freemangordon: yup
<uvos> tmlind: yeah i dident look at the android source at all for d3 i just checked if changeing the cpcap backlight led channel changes the backlight (this was not used on any device, i wonder why) on d3 or if any of the lm* channels do and dident find it
<uvos> ill get back to it at some point
<tmlind> uvos: ok, yeah sorry xt894 typo :)
Guest224 has quit [Quit: Client closed]
<Wizzup> so notify_notification_attach_to_widget seems to be done from libnotify
<Wizzup> commit 27e05d0f9562a26163493d6cc1d5924b9a4ebf68
<Wizzup> Author: William Jon McCann <jmccann@redhat.com>
<Wizzup> Date: Fri Oct 8 22:47:06 2010 -0400
<Wizzup> Remove the ability to attach notifications to widgets or positions
<Wizzup> well, I'll continue this later
<Wizzup> It looks like python2 stuff will be hard to keep going, there's a lot more to import now, cython, python-notify, etc
SuperMarioSF has joined #maemo-leste
<Wizzup> sicelo: ok let me get the trace, then I really have to go
<sicelo> awesome. thanks
<Wizzup> sicelo: hrm, it's not showing kernel console atm :(
<Wizzup> sicelo: when does it reset for you
<sicelo> just before h-d shows up
<sicelo> which i assume is when modem is brought online
<sicelo> anyway, i did remove ofono from default runlevel, and then h-d does come up. so it's definitely modem related. did yours boot into h-d right away?
<Wizzup> no, it was slow and serial was on tty0
<sicelo> ah.
<Wizzup> I need to redo it with serial on ttyS*
<Wizzup> but...tomorrow morning :)
<Wizzup> I'mm keeping people waiting
<sicelo> doesn't the kernel already have ttyS2? which kernel did you try
<sicelo> at /proc/cmdline
<sicelo> root=/dev/mmcblk0p2 rootwait console=ttyO2,115200
<sicelo> root@devuan-n900:~# uname -r
<sicelo> 6.1.0-rc6
<sicelo> that's the one from repos
<sicelo> but sure, tomorrow
<Wizzup> I think my uboot overrides it
<sicelo> ok. tomorrow then
<Wizzup> yup. :)
<sicelo> you don't even need to recompile kernel for this .. uboot has `setenv bootargs ....`
<Wizzup> I forgot how long it took for the n900 to upgrade :P
<Wizzup> sicelo: yeah but I'm already outside now
<sicelo> uvos: please restore CONFIG_RFKILL in kernel. this broke wifi on N900
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #maemo-leste
akossh has joined #maemo-leste
doc has quit [Quit: Things to do]
<uvos> sicelo: not sure what you mean by "restore"
<uvos> neither our 6.1 nor 5.18 set this
<uvos> see
<sicelo> "restore" means current kernel does not have the config. it was there before.
<uvos> this dosent apear true
<uvos> if wifi broke this is something new
<sicelo> fine
<uvos> so dose setting CONFIG_RFKILL to something help in 6.1?
mardy has quit [Quit: WeeChat 3.5]
_uvos_ has joined #maemo-leste
_uvos_ has quit [Ping timeout: 260 seconds]
SuperMarioSF has quit [Quit: Client closed]
uvos has quit [Quit: Konversation terminated!]
Twig has quit [Remote host closed the connection]
sunshavi_ has quit [Remote host closed the connection]
sunshavi_ has joined #maemo-leste
sunshavi_ has quit [Remote host closed the connection]
uvos has joined #maemo-leste