| Wizzup | sicelo: probably the ack is not being received by the operator (or sent by us) | 00:46 |
|---|---|---|
| sicelo | yes, i think we have a regression in the d4 stack (ofono?). i was using this sim on leste+n900 all this time and didn't have this sms problem | 06:58 |
| freemangordon | Wizzup: I wonder why rtcomel was ever working properly on any platform | 07:50 |
| freemangordon | see https://git.maemo.org/leste/rtcom-eventlogger/src/branch/master/src/eventlogger.c#L831 | 07:51 |
| freemangordon | here we call time(), but printf() specifier is '%d' | 07:52 |
| freemangordon | perhaps time.h was never included befor, so compiler was assuming time() returns 32 bits | 08:22 |
| freemangordon | this still does not explain it why it is ok on 64 bit platforms | 08:22 |
| sicelo | freemangordon: what's the context for that? | 08:40 |
| freemangordon | time_t is 64 bits | 08:41 |
| sicelo | i mean, this is in connection with which issue? :-) | 08:45 |
| freemangordon | rtcomel tests fail on trixie | 08:45 |
| freemangordon | Wizzup: so, I am not really sure what to do: if I cast to int, we will hit year 2038 problem | 08:46 |
| freemangordon | if I implement support for 64bits, then we have issue with rtcom_el_query_prepare() that expects pointers | 08:47 |
| freemangordon | and we cannot fit 64bits in 32 bit pointer | 08:47 |
| sicelo | cast to int and leave a TODO :p | 08:48 |
| freemangordon | well.. | 08:48 |
| Wizzup | freemangordon: good find | 09:35 |
| Wizzup | freemangordon: let me think a bit on the best thing to do here | 09:35 |
| Wizzup | sicelo: we'll still be running maemo in 2039, so we'll need a good fix :p | 09:36 |
| uvos__ | sicelo: this has always been a problem on d4 | 09:36 |
| uvos__ | but its operator dependant, with some sim cards it dosent happen | 09:37 |
| uvos__ | so yeah somehow the modem is not acking the sms, and different operators behehave diferently when this happens | 09:38 |
| uvos__ | i think remote party never gets a deivery report even when the operator dosent keep repeating the sms but i would have to check again | 09:38 |
| sicelo | uvos__: the same sim has had no repeated SMSes on the N900, so in this case i can almost say it's not the operator. | 09:57 |
| sicelo | Wizzup: yeah, i was mostly joking :p | 09:57 |
| Wizzup | I suspect the right way here is perhaps to make a new function prototype and pass args in differently | 10:23 |
| Wizzup | like glib does I guess | 10:23 |
| uvos__ | sicelo: i dont think its ever on the operator | 11:23 |
| uvos__ | it never happens on d4 android either | 11:23 |
| uvos__ | its just that operators handle the d4 misbehaveing differently | 11:23 |
| freemangordon | Wizzup: I think I fixed it properly | 11:33 |
| freemangordon | will push in a couple of minutes, if you think that's not the proper way, just LMK | 11:33 |
| freemangordon | sicelo: if you can gather ofono logs, perhaps we can fix it | 11:58 |
| freemangordon | Wizzup: rtcomel excalibur is fixed, however, build fails in CI on daedalus with some dbus error | 12:38 |
| freemangordon | see https://phoenix.maemo.org/job/rtcom-eventlogger-binaries/architecture=armhf,label=armhf/16/console | 12:38 |
| freemangordon | this is the fix https://git.maemo.org/leste/rtcom-eventlogger/commit/f9f316f6dacc4e2c4419a7e8baa66789887c4ee8 | 12:39 |
| uvos__ | freemangordon: isent time_t still 32 bits on x86-32? | 13:02 |
| freemangordon | seems no | 13:02 |
| sicelo | debian recently had a massive t64 related transition. AFAIK, even armhf has t64 now in debian | 13:04 |
| freemangordon | yes, and that's our issue | 13:04 |
| uvos__ | maybe we should assert on sizeof(time_t) then? | 13:05 |
| freemangordon | no, see the commit ^^^ | 13:05 |
| freemangordon | I think current code is wrong even on 64bit | 13:08 |
| uvos__ | hmm is intmax_t __int128 on platforms that supports it (like x86-64) | 13:08 |
| uvos__ | if so useing that seams excessive | 13:08 |
| freemangordon | do you have a better idea? | 13:08 |
| freemangordon | use long long ? | 13:09 |
| uvos__ | sure or stdint.h | 13:09 |
| freemangordon | lemme check the actual size of intmax_t on amd64 | 13:09 |
| uvos__ | https://stackoverflow.com/questions/20459513/is-intmax-t-the-same-as-long-long-int | 13:10 |
| uvos__ | seams gcc breaks spec and it is not | 13:10 |
| freemangordon | ok, so we are ok | 13:10 |
| freemangordon | uvos__: so, shall I change to signed long long int? | 13:12 |
| uvos__ | i dont think it makes a difference, just like intmax_t could (really should) be 128 long long can be anything too, but in practice is 64bit. So no strong opinion | 13:14 |
| uvos__ | its fine | 13:15 |
| freemangordon | ok | 13:15 |
| freemangordon | so, it seems time_t is 32bits on daedalus and 64 bits on excalibur | 13:19 |
| Wizzup | freemangordon: great :) | 13:41 |
| sicelo | yup, excalibur being based on trixie, which had the t64 transition :-) | 13:49 |
| Wizzup | freemangordon: ok, well, with that out of the way we should release daedalus soon (assuming no more big blockers) | 14:29 |
| freemangordon | Wizzup: right | 16:00 |
| uvos__ | do we have a daedalus-devel repo already? | 16:24 |
| freemangordon | I think yes | 16:24 |
| uvos__ | ok so if we are releasing deadalus soon i presume i shal now stop building for non devlel daedalus directly and will do so. | 16:33 |
| sicelo | uvos__: freemangordon: i think sphone needs to be rebuilt asap ... the rtcom change is crashing sphone | 16:57 |
| sicelo | "rtcom_el_iter_get_values: bug in library, unexpected type gint64" | 16:57 |
| sicelo | started just after upgrading | 16:57 |
| ladslat | hello | 17:03 |
| ladslat | frick | 17:03 |
| ladslat | i mispelled ladsalt | 17:03 |
| ladsalt | back | 17:03 |
| ladsalt | hello everyone | 17:03 |
| ladsalt | id like to know if maemo supports modern firefox | 17:04 |
| uvos__ | freemangordon: please rebuild sphone, i cant atm | 17:24 |
| uvos__ | ladsalt: sure maemo is just devuan (which is essentally debian) | 17:24 |
| uvos__ | you can install and run anything that runs on debian | 17:24 |
| uvos__ | however of our supported phones only the pinephone is fast enough to have a decent expirance | 17:25 |
| uvos__ | n900 just flat dosent have the ram and droid 4/ mapphones is are painfull with modern ff | 17:25 |
| uvos__ | chromium dose a bit better, jib dose better still but is still a bit unfinished, theres also qtwebbrowser | 17:26 |
| uvos__ | for n900 the only thing you can really use is dillo and things like links2 | 17:27 |
| ladsalt | i hope one day maemo will be supported on anything with a unlocked bios like other linux phones | 17:29 |
| ladsalt | in the mean time ill just have to wait for my pixel 8a to crap out so i can switch to pinephone | 17:29 |
| uvos__ | its hard as arm based phones dont follow a standard and are all special snoflakes you need to write specific support for | 17:30 |
| uvos__ | a generic arm phone distro will never happen as a result | 17:30 |
| uvos__ | with current hardware anyhow | 17:30 |
| uvos__ | google is slowly pushing for things to standardize as they are a bit sick of dealing with this with android too | 17:31 |
| ladsalt | also x86 phones must hog up the battery like crazy | 17:32 |
| ladsalt | although one could use limbo vm or somethin and use it as there launcher on android | 17:33 |
| ladsalt | however i know it will happen someday | 17:35 |
| sicelo | ladsalt: well, any mainlined phone should be supported in leste. just needs someone to do the basic integration work (not a lot if mainline linux is already working well on said phone) | 17:36 |
| * sicelo is working on Librem5 support, for example (but getting sidetracked a lot - but at least so far it's been distraction with important leste stuff) | 17:37 | |
| sicelo | so if you have in mind a phone that pmOS supports using mainline, this channel might be able to help you get it up and running with Leste to nearly the same level of functionality as pmOS | 17:38 |
| ladsalt | well im not sure getting it running on a tensor cpu will be very pratical | 17:39 |
| ladsalt | why does my maemo vm just go blank after a while | 17:45 |
| ladsalt | is it in sleep mode or something? | 17:45 |
| sicelo | yes, because the phone also defaults to that | 17:50 |
| sicelo | just go to Display settings and disable the timeout (i seem to think it should default to that on VM) | 17:50 |
| ladsalt | oddly enough i cant seem to wake it up | 17:55 |
| uvos__ | we dont currently have a mechnaism to have different gconf defaults for specific device builds | 17:55 |
| uvos__ | ladsalt: you have to press power | 17:55 |
| ladsalt | problem | 17:55 |
| ladsalt | im on a vm | 17:55 |
| ladsalt | there is no power button | 17:55 |
| uvos__ | vms ususally have a way to press power | 17:55 |
| Wizzup | the qemu gtk interface has a 'shut down' option | 17:55 |
| Wizzup | hit that and it'll press the button | 17:55 |
| ladsalt | on virtualbox | 17:55 |
| uvos__ | "also x86 phones must hog up the battery like crazy" x86 phones exited | 17:58 |
| uvos__ | they where not really better | 17:58 |
| uvos__ | as just becasue you are x86 dosent mean you are a pc with acpi and probeable buses like pci | 17:58 |
| uvos__ | the x86 phones where also special snoflakes that needed you to write specific support | 17:58 |
| uvos__ | what you want is a phone that is also an IBM PC comptable / acpi device | 17:59 |
| ladsalt | interesting | 18:01 |
| ladsalt | i just have always heard that x86 tends to use more power | 18:01 |
| uvos__ | thats not really true, i mean its bearly true the instruction decoder uses a tiny bit more power | 18:02 |
| uvos__ | but the main reason why practical x86 devices use more power is because they are not as optimized for that | 18:02 |
| uvos__ | the instruction set has very litttle to do with it | 18:02 |
| uvos__ | Motorola made a x86 phone that is related to the devices we support at around the same time: | 18:03 |
| uvos__ | https://en.wikipedia.org/wiki/Motorola_RAZR_i | 18:03 |
| ladsalt | wonder why there arent that many x86 phones compared to arm then | 18:03 |
| ladsalt | well ill be back i need to do something | 18:04 |
| ladsalt | i have returned | 18:10 |
| ladsalt | it seems maemo would be great for tablets | 18:12 |
| Wizzup | yeah it is | 18:16 |
| uvos__ | we kinda support 1 tablet the mz617, but its a huge pain to install leste there | 18:16 |
| uvos__ | for tablet use i think however hildon lacks mulit window | 18:17 |
| ladsalt | also the app store is doesnt work on virtual box it just says no connections available | 18:18 |
| Wizzup | you need to install the dummy internet conn, I think that is on the wiki | 18:18 |
| Wizzup | hm, looks like it's *not* on the wiki | 18:19 |
| Wizzup | sudo apt install libicd-network-dummy | 18:19 |
| Wizzup | and then follow the gconf instructions | 18:19 |
| ladsalt | if maemo was released by nokia now it would be a very big boost for the linux phone community | 18:21 |
| ladsalt | not just be limited to a fairly unknown linux phone operating system | 18:22 |
| ladsalt | libicd-network-dummy seems to not work i mean i did what it told me to do | 18:30 |
| ladsalt | with gconftool | 18:30 |
| ladsalt | yet another question i have is how usable is meamo leste on the droid 4? | 18:35 |
| sicelo | very usable | 18:35 |
| ladsalt | good thats all i need to hear to expand my ancient ass phone collection | 18:35 |
| ladsalt | wait if maemo is meant for a x86 cpu then why does it work so well on a droid 4 which uses arm | 18:37 |
| sicelo | architecture is not really important for Leste... Droid 4 just happens to be the fastest phone with mainline and a hardware keyboard | 18:39 |
| sicelo | and actually maemo was originally meant for arm, not x86. where did you get that? | 18:39 |
| ladsalt | know that you bring it up i have no fucking idea something in my mind assured me that it was x86 but it was wrong and i am very sorry | 18:41 |
| sicelo | maemo started with the N770, then N800 & N810, N900, and finally N9 & N950 | 18:41 |
| uvos__ | N9 still counts as maemo? | 18:41 |
| ladsalt | n9 is meego | 18:42 |
| sicelo | that's why Leste is Maemo 7, not 6 :-D | 18:42 |
| ladsalt | ok if the n770 was the first device to use maemo and it used 2.2 that what happened to older versions? | 18:43 |
| sicelo | what older versions | 18:44 |
| ladsalt | like a 1.0 | 18:44 |
| ladsalt | surely they didnt just start at 2.2 | 18:44 |
| sicelo | in house maybe :-) | 18:45 |
| sicelo | not everything Nokia made made it to the sales shops | 18:45 |
| ladsalt86 | why did i just get disconnected | 18:45 |
| ladsalt86 | hold on | 18:45 |
| ladsalt40 | why is there a 40 at the start of my name now | 18:46 |
| ladsalt40 | end* | 18:46 |
| ladsalt40 | IM SO CONFUSED??? | 18:46 |
| ladsalt40 | anyway | 18:47 |
| ladsalt40 | i wonder what this inhouse 1.0 looked like | 18:47 |
| ladsalt40 | maybe it was a pre-release? | 18:48 |
| sicelo | no idea. I'm not into | 18:49 |
| sicelo | Anyway, the Hildon (Maemo) UI borrows from Symbian S90, which was somewhat related to Symbian S80 | 18:50 |
| sicelo | so looking at those two might give you hints ... Anyway, I don't have any idea (or interest) in unreleased products or prototypes | 18:51 |
| ladsalt | back | 19:18 |
| ladsalt | im trying to get maemo leste to work on a pixel 8a via limbo | 19:19 |
| ladsalt | should be no reason for it to not owkr | 19:19 |
| ladsalt | work* | 19:19 |
| sicelo | uh, limbo ... | 19:23 |
| sicelo | you might as well try it via Android chroot or similar ... it's been done before | 19:24 |
| ladsalt | that is smart but im going to be honest im just lazy | 19:25 |
| ladsalt | and i have to deal with this shitty xz extractor | 19:28 |
| ladsalt | for android | 19:28 |
| ladsalt | welp all it does is boot me back to grub and grub doesnt even give me a meny | 19:42 |
| ladsalt | menu* | 19:42 |
| ladsalt | after saying "loading inital ramdisk" | 19:43 |
| sicelo | ladsalt: https://github.com/diejuse/proot_MaemoLeste_on_Android/ | 19:44 |
| sicelo | ladslat: also, regarding Maemo 1, https://wiki.maemo.org/Maemo_basics#How_can_I_run_Maemo.3F | 19:47 |
| sicelo | aka 1.x is OS2005, 2.x is OS2006. The 770 ran both. and sorry, it's not N770 :-) | 19:48 |
| ladsalt | i give up lol | 19:59 |
| sicelo | use the proot way really | 19:59 |
| ladsalt | cant get adb to work | 19:59 |
| ladsalt | id rather just wait for a chance to get a pine phone | 20:00 |
| ladsalt | you know what would be really cursed? | 20:00 |
| ladsalt | wine | 20:00 |
| ladsalt | on maemo | 20:01 |
| ladsalt | how do i get snap working? | 20:08 |
| ladsalt | just doing "sudo apt install snap" seems not to work | 20:08 |
| ladsalt | i type snap after and returns a not found | 20:08 |
| sicelo | isn't that an Ubuntu thing? | 20:12 |
| sicelo | anyway, the OS is basically Devuan ... so whatever way works on Devuan/Debian should work | 20:12 |
| ladsalt | how would i get glibc working? | 20:43 |
| sicelo | it's working already, no? deb/vuan is a glibc distro | 20:46 |
| ladsalt | i meant it isnt preinstalled | 20:46 |
| sicelo | it is | 20:52 |
| sicelo | without it, there's basically no distro :-) | 20:52 |
| ladsalt | when i try to run snap it says its missing | 20:53 |
| sicelo | then snap is wrong or you should share the real error from snap | 20:53 |
| sicelo | glibc --> lib6 2.36-9 is the version we're currently running in Leste | 20:54 |
| sicelo | s/lib6/libc6/ | 20:54 |
| sicelo | btw, what you you want/need snap for? | 20:55 |
| ladsalt | its just easier to use then apt | 20:55 |
| sicelo | easier for? | 20:56 |
| ladsalt | snap: /lib/x86_64-linux-gnu/libc.so.6: version "GLIBC_2.34" not found (required by snap) | 20:56 |
| sicelo | i admit i don't know a lot about snaps, but afaik it's for specially packaged packages, not just about anything | 20:56 |
| sicelo | so if you want a replacement for apt, snap is likely not the solution ... | 20:57 |
| ladsalt | its easier because you usually dont have to get dependencies and also firefox requires it from what ive experienced | 20:57 |
| sicelo | FF doesn't require it, no | 20:57 |
| ladsalt | huh odd | 20:58 |
| ladsalt | awhile back i tried making my own bloatfree distro without snap and when i ran firefox it required snap | 20:58 |
| sicelo | what's the real problem with FF :-) | 20:58 |
| ladsalt | well there is that firefox also is demanding glibc | 20:59 |
| sicelo | i'm still using FF (currently v. 138) and I've never installed snap | 20:59 |
| ladsalt | my memory is wrong i guess | 20:59 |
| sicelo | 20:56 < ladsalt> snap: /lib/x86_64-linux-gnu/libc.so.6: version "GLIBC_2.34" not found (required by snap) <<< looks like here it's looking for a very specific glibc version | 21:00 |
| sicelo | as indicated already, daedalus has glibc 2.36 | 21:00 |
| ladsalt | tryin to run --fix-broken install just removes snapd guess it cant find the version specifyed | 21:01 |
| ladsalt | this is very confusign | 21:03 |
| ladsalt | confusing* | 21:03 |
| sicelo | still didn't understand why snapd is needed in the first place though ... so it's not easy to advise accordingly | 21:06 |
| sicelo | why not install Synaptic? | 21:08 |
| ladsalt | good idea | 21:19 |
| ladsalt | just repeats waiting for cache lock: could not get lock | 21:20 |
| ladsalt | what is the sudo password on the vm (synaptic requires it | 21:25 |
| ladsalt | fixed | 21:30 |
| ladsalt31 | any good browsers on synaptic? | 21:40 |
| ladsalt31 | that supports maemo | 21:40 |
| sicelo | firefox? | 21:42 |
| sicelo | might be named firefox-esr | 21:42 |
| sicelo | freemangordon: i suddenly miss the sharing plugins from Fremantle :p | 21:44 |
| ladsalt31 | i tried "firefox" and it said it was basically a package that didnt exist and was just refrenced by another one from what i remember | 21:48 |
| ladsalt31 | yup it was that it was firefox-esr | 21:49 |
| ladsalt31 | a maemo themed android launcher would be really cool | 21:58 |
| ladsalt31 | and it could have termux as the terminal | 21:58 |
| ladsalt31 | would 100% use that | 21:59 |
| ladsalt31 | bye! | 22:02 |
| ladsalt | back | 22:05 |
| ladsalt | how good does leste run on a n900? | 22:05 |
| f_ | ladsalt Apparently very good | 22:46 |
| freemangordon | sicelo: will do, tomorrow | 23:47 |
| freemangordon | though, I don;t see why would sphone crash | 23:48 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!