noidea_ has quit [Remote host closed the connection]
rafael2k has quit [Ping timeout: 260 seconds]
uvos has quit [Ping timeout: 260 seconds]
noidea_ has joined #maemo-leste
noidea_ has quit [Quit: Leaving]
noidea_ has joined #maemo-leste
uvos has joined #maemo-leste
uvos has quit [Remote host closed the connection]
xmn has quit [Quit: xmn]
joerg has quit [Ping timeout: 246 seconds]
k1r1t0 has joined #maemo-leste
joerg has joined #maemo-leste
doc has joined #maemo-leste
doc has quit [Remote host closed the connection]
Twig has joined #maemo-leste
ceene has joined #maemo-leste
k1r1t0 has quit [Ping timeout: 246 seconds]
doc has joined #maemo-leste
Twig has quit [Read error: Connection reset by peer]
pere has quit [Ping timeout: 248 seconds]
<dsc_> Wizzup: on what hardware do you build maemo leste deb packages?
<dsc_> which cpu
pere has joined #maemo-leste
rafael2k has joined #maemo-leste
<uvos__> dsc_: since he isent here: ci runs on a https://www.solid-run.com/arm-servers-networking-platforms/honeycomb-servers-workstation/#overview in think locally we all build on d4 if it is to be for arm
dos has quit [Quit: Kabum!]
dos has joined #maemo-leste
<uvos__> the amd64 packages are bult on some regular ibm pc comaptable machine
<uvos__> and an rpi4 and some Opteron A (amd arm chip) was used in the past
dos has quit [Client Quit]
dos has joined #maemo-leste
<Wizzup> dsc_: honeycomb lx1 I believe
<Wizzup> sicelo: thanks for finding that
<Wizzup> uvos__: armhf builds are not done on a d4, they're done on the honeycomb as well
<uvos__> Wizzup: read again "locally"
<uvos__> :)
<sicelo> you can ping me when it's built. i may have time to test
<Wizzup> uvos__: right
<Wizzup> sicelo: building atm
<sicelo> ok. let me boot device then
<Wizzup> sicelo: it will take 40 mins probably or so
<dsc_> uvos__ & wizzup: thanks
<dsc_> so, my software at the build stage decides what compiler flags to use based on the CPU
<dsc_> SIMD related GCC flags for ARM are kinda important
<dsc_> so if it is build using machine A, and deployed on machine B it may result in degraded performance :D
<dsc_> or not run at all
<uvos__> not great
<Wizzup> you could maybe assume neon for now
<Wizzup> but usually this uses some detection at runtime
<uvos__> the last relevant arm cpu without neon was tegra 2
<uvos__> same generation as omap4 same specs
<dsc_> yeah I suppose assuming neon is not so bad
<Wizzup> right, but n900 has neon
<uvos__> (relevant in the mobile phone space)
<uvos__> Wizzup: i know im just saying
<Wizzup> :)
<uvos__> the tega 2 was used by the other motorola phones that where areound when the d4 was
<uvos__> ie atrix 1 and xoom 1
<Wizzup> uvos__: any idea if it would be hard or crazy to make a c++/qt based module for sphone, for the tp part?
<uvos__> no not at all
<uvos__> sphone works with qt just fine
<uvos__> there is even a qt module that pops up error dialogs
<dsc_> for example: n900 is cortex a8 (-fmpu=neon), d4 is cortex a9 (-fmpu=neon-fp16)
<Wizzup> does that work with gtk modules active at the same time?
<uvos__> Wizzup: yes
<uvos__> and sphone core bridges everything
<dsc_> for both you could just specificy `-fmpu=neon` but it would perhaps result in degraded performance
<Wizzup> dsc_: I would target the lowest common denominator, and perhaps later add the various paths and do runtime detection
<dsc_> alright
<Wizzup> uvos__: but it's all in the same process right?
<uvos__> Wizzup: it is int eh same process
<uvos__> it dosent interfer at all
<uvos__> qt uses the gtk event loop
<Wizzup> uvos__: ok, I might try to write a c++ tp module instead of a glib one, since I now already have experience with the C++ way
<uvos__> Wizzup: you do have to recompile sphone with qt support however
<uvos__> its disabled on ci
<uvos__> Wizzup: thats fine
<uvos__> i plan to replace the gtk2 modules with qt at some point anyhow
<uvos__> (which is why sphone works the way it dose)
<uvos__> if you want to use .ui files
<uvos__> btww you will have to invoke the generator by hand in cmakelists
<Wizzup> I think we use cmake also for conversations
<Wizzup> so I'll probably figure it out :)
<Wizzup> so is qtloop a sample app?
<uvos__> no
<uvos__> qtloop is needed if there is any qt module you want to load
<Wizzup> ok
<freemangordon> uvos__: actually qt uses glib loop ;)
<freemangordon> not gtk
<uvos__> freemangordon: right glib
<uvos__> on linux
<uvos__> qtloop checks for this
<freemangordon> Re NEON - do we want to support anything non-NEON?
<freemangordon> I vote 'no'
<uvos__> Wizzup: ^^
<uvos__> freemangordon: unless we want to support motorola tegra 2 devices, no
<freemangordon> also, do we want to support anything non-thumb2?
<uvos__> freemangordon: yes
<freemangordon> what?
<Wizzup> uvos__: ty
<freemangordon> allwinner?
<uvos__> wasent thumb dropped in recent 32bit arm cpus?
<freemangordon> no
<Wizzup> pretty sure a10 can do thumb
<freemangordon> why is that?
<uvos__> it was dropped for recent arm64 ones for sure
<freemangordon> well, I mean arm32 anyways
<Wizzup> it might be worth checking what the default debian arm targtes are, we might get some more neon optimisations
* Wizzup bbl
<freemangordon> Wizzup: if we agree on, (and I see no reason to not), please add,somehow, -mthumb -mfpu=neon to CFLAGS/CXXFLAGS
<freemangordon> to CI that is
<freemangordon> IIRC, debian disabled NEON in qt for some reason
<freemangordon> if we re-enable(for example) that would give a big performance boost in some qt applications
<freemangordon> I am not going to explain why we would want thumb :p https://talk.maemo.org/showthread.php?t=84829
<uvos__> sure neon i would enable
<uvos__> thumb2 might be more neabulous in terms of beneift
<freemangordon> read the link ^^^
<freemangordon> uvos__: you may trust me on thumb, I spent years on it :)
<freemangordon> and given that we anyway should clear BTB etc because of spectre/meltdown and friends...
<buZz> freemangordon: also GLES is disabled in debian qt , afaik
<Wizzup> pretty sure gles works now in chimaera with maemo qpa
<dsc_> +1 assume NEON
<buZz> Wizzup: ah, might have been debian 10 then
<dsc_> only the super cheap CPUs dont have NEON
<dsc_> most have it
<Wizzup> freemangordon: I am fine with both those options, I'll check in a bit what the default flags rae
<Wizzup> freemangordon: doesn't look like it includes either mthumb or mneon
<Wizzup> ( dpkg-buildflags )
<Wizzup> we can change /etc/dpkg/
<Wizzup> buildflags.conf
<Wizzup> /etc/dpkg/buildflags.conf *
<Wizzup> on the armhf builder
<Wizzup> freemangordon: let me know what you'd like to see rebuilt if/when we have these flags
System_Error has quit [Ping timeout: 255 seconds]
<sicelo> Wizzup: yes, UDC fixed. now usbnet is working
rafael2k has quit [Remote host closed the connection]
rafael2k has joined #maemo-leste
<sicelo> for my wireless, i guess it's not working because it's (mysteriously?) named wlan1, while libicd-network-wpasupplicant appears to expect wlan0 (according to `strings`)
<sicelo> yes, fixed now, by modifying /etc/udev/rules.d/70-persistent-net.rules
<sicelo> i'm back at wlan0
<freemangordon> Wizzup: qt (including webengine) for sure
<freemangordon> maybe gtk as well
<freemangordon> ah, yes, glib/gtk, they will benefit memory-wise because of thumb2
<freemangordon> mesa?
<freemangordon> but, before that, just lemme check my allwinner
<freemangordon> I don;t want to break allwinner 32bit SoCs
<freemangordon> seems ok, /proc/cpuinfo seems to hint thumb and neon
k1r1t0 has joined #maemo-leste
<Wizzup> sicelo: right yes @ iface names
<Wizzup> freemangordon: ok
<sicelo> i want to troubleshoot my SIM provisioning
<sicelo> what starts icd2? it respawns when i kill it. dsmetool is unable to kill it, and rc-service says it's already stopped
elastic_dog has quit [Ping timeout: 265 seconds]
<sicelo> or i confused the device. let me reboot. i can see it should be started and managed by dsme
elastic_dog has joined #maemo-leste
<sicelo> freemangordon: i think i need help. how to stop icd2 properly? and to start it correctly?
<rafael2k> my 2nd pinephone keyboard is already in the country... lets see if I'm lucky this time
<buZz> sicelo: what worked for me to force gprs provisioning ; was deleting -all- gprs connections from gconf
<buZz> sicelo: and then rebooting
<buZz> somehow something seems to prevent provisioning from happening when 'something' is already there
<sicelo> ok. anyway looks like i have run out of spare time for now ... i'd like to troubleshoot this properly. i guess in the meantime i'll do as you suggest, which sucks
<buZz> provisioning was very difficult for me, as my provider seems to want -no- APN configured (and just willy nilly picks one on connecting)
<buZz> on my bill specification i can see which APN it used, and there's about 3 different ones it picks :D
<buZz> very bizar
pere has quit [Ping timeout: 260 seconds]
<Wizzup> rafael2k: with keyboard?
<Wizzup> freemangordon: if you need me to test some charger patches, let me know ;)
<Wizzup> my car always leaves my d4 thinking that it is still charging
<rafael2k> Wizzup: the PinePhone keyboard
<rafael2k> Wizzup: just the keyboard
norayr has left #maemo-leste [Error from remote client]
<uvos__> sicelo: that can happen if your wifi interface changes mac for any reason
<uvos__> sicelo: udev (not unreasonably) then thinks its a new adapter
<uvos__> really icd should just not hardcode wlan0 use the "first" wifi adapter then we could ditch this saveing mac addresses for persitant names mess and use the modern persistant names based on bus location
<Wizzup> uvos__: yes we eventually have to fix that
norayr has joined #maemo-leste
pere has joined #maemo-leste
<Wizzup> sicelo: so should we revert the rndis stuff soon?
<Wizzup> as in, revert back
norayr has left #maemo-leste [Error from remote client]
norayr has joined #maemo-leste
<uvos__> opertune timeing?
<sicelo> i think we should use NCM, not go back to ECM
<sicelo> updated versions of window 10 and 11 support ncm, and i've successfully tested it with mainline linux (using pmos, but the whole thing is kernel based, so will not be different for leste)
<Wizzup> ok
pere has quit [Ping timeout: 265 seconds]
<freemangordon> buZz: please, we want to find the but
<freemangordon> *bug
<freemangordon> cleaning gconf entry is not really a solution
<freemangordon> sicelo: /etc/init.d/icd2 stop
<sicelo> will do that
<sicelo> sphone suggestions: (1) remove "Cancel" button, (2) remove "backend" button and place it in sphone options, (3) rearrange the remaining buttons so the keypad can be displayed in landscape
<uvos__> 1 no i use it all the time
<uvos__> 2. no, altho its maybe misslabled, this really is the protocoll to use to place the call, the user def needs to set this for every call
<uvos__> 3. sure, but it wont do this as i want to replace the dialogs with qt ones, patches welcome for this one however
<Wizzup> freemangordon: I still have a linking problem with (I think) rtcom, could you help?
<Wizzup> conversations: symbol lookup error: /usr/lib/arm-linux-gnueabihf/rtcom-eventlogger/plugins/libchat.so: undefined symbol: rtcom_el_plugin_chat_get_group_title
<Wizzup> this happens on any arch btw
<sicelo> n900's portrait bug bit me a few moments ago, because i received an unexpected call, and sphone switched orientation to portrait :p
<sicelo> btw still no clue why we have that issue with portrait there?
<Wizzup> does the screen still turn black?
<Wizzup> freemangordon for sure knows what's up with this
<sicelo> yes, turned black.
<Wizzup> I think this is about some omap tiler stuff
<Wizzup> I thought that we fixed sphone not to do this
<Wizzup> (force portrait)
<sicelo> after the call ended, and i slid keyboard up, hildon reappeared (in landscape) ... but then display was shrunk. i ended up rebooting
<sicelo> Wizzup: i forget - is there a way (in mce.ini perhaps?) to tell h-d to never attempt to rotate? maybe we just need a device specific rule like that for the N900, so we don't inconvenience devices that don't have rotation issues
<sicelo> ah, lock applet. i should install that on my n900
<Wizzup> freemangordon: this works:
<Wizzup> LD_PRELOAD=/usr/lib/x86_64-linux-gnu/librtcom-el-plugin-chat.so.1.0.0 python -c 'import ctypes; ctypes.CDLL("/usr/lib/x86_64-linux-gnu/rtcom-eventlogger/plugins/libchat.so");'
<Wizzup> sicelo: on the n900 we 'fixed' it by not loading accelerometer module
<Wizzup> sicelo: I don't know of a better way atm
<Wizzup> freemangordon: so somehow libchat needs to link against librtcom-el-plugin-chat.so.1.0.0 but I am not sure how to do this in autotools
<uvos__> my understanding was that current video -omap should just prevent rotation
k1r1t0 has quit [Read error: Connection reset by peer]
<uvos__> if it dosent lets disable the randr extension on n900's xorg
<uvos__> no need to let the user/hildon break thair machine with broken randr
<dsc_> Wizzup: is this linking stuff conversations related?
<dsc_> linking error*
<Wizzup> dsc_: no, but it does break conversations
<dsc_> kk
<Wizzup> my autotools knowledge messes with me :)
<uvos__> sicelo: rotation is allready disable in mce on n900 btw, but this just means mce wont tell hildon to rotate
<uvos__> it can still decide to rotate on its own
<dsc_> Wizzup: any 'not founds' in `ldd /usr/lib/arm-linux-gnueabihf/rtcom-eventlogger/plugins/libchat.so` ?
<freemangordon> Wizzup: where is the code?
<freemangordon> IOW- what do you try to build?
<Wizzup> freemangordon: this is at runtime, not at build time
<freemangordon> ok
<Wizzup> freemangordon: so the confusing this is
<Wizzup> -lrtcom-el-plugin-call -lrtcom-el-plugin-sms -lrtcom-el-plugin-chat -lrtcom-eventlogger -lgobject-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lglib-2.0 -lsqlite3
<Wizzup> $ pkg-config --libs rtcom-eventlogger-plugins
<Wizzup> and the package builds libchat.so with these flags
<Wizzup> but -lrtcom-el-plugin-chat is not available as far as I can see, since it's part of the same package
<Wizzup> and this somehow messes up linking I suppose
<freemangordon> sec
<Wizzup> even for building the lib it apparently tried to link this
<Wizzup> which makes no sense to me
<Wizzup> oh
<freemangordon> maybe add libchat.la to librtcom_el_plugin_chat_la_LIBADD
<Wizzup> I think the whole thing doesn't even exist
<Wizzup> hmm
<Wizzup> so librtcom-eventlogger-plugins-dev seems to provide similar libs? wtf
<Wizzup> hm, ok, this makes sense
<Wizzup> freemangordon: I assume you mean add librtcom_el_plugin_chat.la to libchat_la_LIBADD ?
<Wizzup> ok, that might have done it
<freemangordon> whatever lib defines that symbol
<Wizzup> let me try to build htis on d4
<freemangordon> Your IP address 95.43.220.235 has been blocked for violating the dpaste.com Terms of Service. IP will be unblocked after not connecting for 15 days. To file a support ticket please visit https://dpaste.freshdesk.com/support/home
<freemangordon> :)
<Wizzup> wtf
<freemangordon> no idea
<Wizzup> btw, somewhat unrelated, in the last month or two, is the status applet also slow to show for you?
<Wizzup> it takes 1-2 seconds usually to show
<Wizzup> I think this was since some modem icd work
<Wizzup> (might be wrong)
<freemangordon> which status applet?
<Wizzup> just activating the status menu
<Wizzup> tapping where the wifi/battery/time is
<Wizzup> on my d4 this takes 2-3 seconds
<freemangordon> hmm
rafael2k_ has joined #maemo-leste
<Wizzup> maybe it's some misconfig
<Wizzup> it seems fast on my bionic
<freemangordon> no
<Wizzup> my d4 is a bit off a mess since the 'disk' has gotten full over 10 times
<Wizzup> this tends to mess with config files
<freemangordon> no issue here
<Wizzup> ok
<Wizzup> probably some local thing
<Wizzup> btw, I just build libpurple-slack, and of course since 2022 15 dec the login is broken :D
<freemangordon> sorry, not following, what is the issue there?
<Wizzup> nevermind, it was just funny
rafael2k has quit [Ping timeout: 260 seconds]
<Wizzup> in any case conversations starts, so we can consider the rt com plugins things resolved
<Wizzup> ty
<Wizzup> the libpurple slack thing was just me trying to use it with haze, but slack.com deprecated some api point it was hitting
<freemangordon> ah
rafael2k__ has joined #maemo-leste
rafael2k__ is now known as rafael2k
rafael2k_ has quit [Ping timeout: 268 seconds]
<uvos__> Wizzup: i have the same problem wih the status menu speed
<Wizzup> ok
<uvos__> Wizzup: and yes its only on the deivces where cellular is installed
<uvos__> so it might be related
<Wizzup> right
<Wizzup> we can check what happens if libicd-network-ofono is removed
<uvos__> eh its long enough that i can just trapp it in gdb
<uvos__> and see where it is
<Wizzup> fair I suppose
<freemangordon> my device have SIM card in it
<Wizzup> same, of course :)
<freemangordon> what is "cellular"?
<uvos__> same here
<uvos__> freemangordon: the metapackage
<freemangordon> umm... what makes you think I don;t have that?
<uvos__> dunno, how should i know what you have installed, it was not default on beowulf
<uvos__> issue is on beowulf here to be specific (but only primary droid and bionic have mobile and sim so no idea if its on devuan 11 too)
<freemangordon> well, I am on chimaera, but Wizzup too, AFAIK
<Wizzup> yes
<uvos__> ok so issue persists
rafael2k has quit [Ping timeout: 255 seconds]
uvos__ has quit [Ping timeout: 246 seconds]
pere has joined #maemo-leste
uvos__ has joined #maemo-leste
rafael2k has joined #maemo-leste
ceene has quit [Ping timeout: 272 seconds]
rafael2k has quit [Ping timeout: 265 seconds]
Twig has joined #maemo-leste
akossh has joined #maemo-leste
System_Error has joined #maemo-leste
uvos has joined #maemo-leste
System_Error has quit [Remote host closed the connection]
System_Error has joined #maemo-leste
<buZz> freemangordon: i totally want to find it too, that was just the only working route in the end
<buZz> at the time*
akossh has quit [Quit: Leaving.]
akossh has joined #maemo-leste
pere has quit [Ping timeout: 272 seconds]
Twig has quit [Remote host closed the connection]
pere has joined #maemo-leste
akossh has quit [Quit: Leaving.]
xmn has joined #maemo-leste