| inky | folks i am so glad i can use droid4 with maemo you cannot imagine. (: | 00:37 |
|---|---|---|
| inky | i run pidgin on it and chat whole day and it works | 00:37 |
| Wizzup | inky: cheers :) | 00:38 |
| Wizzup | it'll get better with our to-be-written telepathy stuff I hope | 00:38 |
| joerg | your chanlogs seem... not up to date | 01:17 |
| joerg | if you want http://maemo.cloud-7.de/irclogs/freenode/_maemo alike, drop me a note | 01:18 |
| Wizzup | this one should be: https://maedevu.maemo.org/irc.txt | 01:19 |
| Wizzup | whitequark's logs are still pending I think | 01:19 |
| joerg | I didn't hear of him since long | 01:19 |
| joerg | hope he's well | 01:19 |
| Wizzup | He's probably quite busy with all this migration going on | 02:27 |
| freemangordon | Wizzup: does it make sense it raise an issue against gtk2 upstream in regards to the memleak I fixed? Or maybe parazyd will deal with it through devuan bugtracker | 07:41 |
| freemangordon | *to raise | 07:41 |
| lel | freemangordon closed an issue: https://github.com/maemo-leste/bugtracker/issues/536 (Tklock is not a secure lock screen) | 08:45 |
| parazyd | freemangordon: ok @ gtk. I can see about upstream for sure. | 08:54 |
| freemangordon | thanks (upstream) | 09:02 |
| freemangordon | Wizzup: is it a known issue that alarms doesn't have sound? | 09:10 |
| freemangordon | also, for some reason volume keys on d4 doesn;t change font size in xterm | 09:11 |
| freemangordon | uvos: any clue? ^^^ | 09:12 |
| uvos | freemangordon: yes alarms are a know issue | 09:33 |
| uvos | freemangordon: infact it was you who traced this to some componant (i forget which) wating for a pulsaudio module that dosent exist | 09:34 |
| uvos | freemangordon: the volume keys on n900 generate f4 and f5 i think while on all other devices they generate the more sane Xf86VolumeUp/down | 09:35 |
| freemangordon | uvos: hmm, do you remember any more details (alarms)? | 09:36 |
| uvos | no sorry | 09:36 |
| freemangordon | ok | 09:36 |
| uvos | but search the logs | 09:36 |
| freemangordon | btw, tklock is in devel | 09:36 |
| uvos | theres a link to the code segment oin there somewhere | 09:36 |
| uvos | freemangordon: ok | 09:36 |
| freemangordon | along with powerkeymenu and systemui (fixed memory leaks and other issues) | 09:36 |
| uvos | ok | 09:37 |
| uvos | freemangordon: can we remove the buttons from powerkeymenu that are broken atm | 09:37 |
| uvos | or rather hide them | 09:37 |
| freemangordon | like which? | 09:37 |
| uvos | they cause unfortionate things to happen | 09:37 |
| uvos | like offline mode | 09:37 |
| freemangordon | yes, we can hide, just edit the xml | 09:37 |
| uvos | also slilent mode | 09:38 |
| uvos | and secure device | 09:38 |
| freemangordon | silent mode should work | 09:38 |
| uvos | all of these have missing pieces | 09:38 |
| freemangordon | profiles are there, in it is just a dbus call | 09:38 |
| uvos | well silent mode puts the device into "silent mode" | 09:38 |
| uvos | but that dosent affect pulse | 09:38 |
| freemangordon | ah | 09:38 |
| freemangordon | hmm, I guess volume applet | 09:38 |
| uvos | yeah | 09:38 |
| freemangordon | we desperately need someone who is influenced in PA to help :( | 09:39 |
| uvos | yes | 09:39 |
| freemangordon | Wizzup: parazyd: please hire some PA guy :) | 09:39 |
| freemangordon | hmm, upgraded libx11 in devuan? | 09:41 |
| freemangordon | ah, CVE-2021-31535 | 09:42 |
| freemangordon | parazyd: https://phoenix.maemo.org/job/gtk-repos/17/console | 10:39 |
| freemangordon | Cannot put file 'libgail18-udeb_2.24.32-3+2m7.2_amd64.udeb' of 'gtk+2.0_2.24.32-3+2m7.2_amd64.changes' into component 'main', as it is not listed in UDebComponents of 'beowulf-devel'! | 10:39 |
| diejuse | Uvos: Hello again. I have tested Marble, SMPlayer, VLC and other apps on QEMU with AMD64 virtual image. Menu options are not working when tapped. So XSDL XServer Android app is not the problem. | 10:58 |
| uvos | diejuse: hmm i use smplayer every day | 11:03 |
| uvos | freemangordon: Wizzup: interesing diejuse is not wrong | 11:12 |
| uvos | freemangordon: Wizzup: the menu bar on qt apps dosent work on vm | 11:13 |
| uvos | freemangordon: Wizzup: but it dose work on d4 | 11:13 |
| uvos | wierd | 11:13 |
| freemangordon | uvos: VM is 64 bits | 11:22 |
| freemangordon | I bet it is related :) | 11:22 |
| uvos | freemangordon: yeah might be arch | 11:22 |
| uvos | someone try pp | 11:23 |
| uvos | maybe | 11:23 |
| uvos | or its mouse | 11:23 |
| uvos | on android sdl xserver the input device is a mouse | 11:23 |
| uvos | as is on vm | 11:23 |
| uvos | on d4 its a ts | 11:23 |
| freemangordon | ah | 11:23 |
| freemangordon | TS vs mouse events | 11:23 |
| uvos | right | 11:23 |
| freemangordon | Wizzup: knows more | 11:23 |
| uvos | Wizzup: can test with pp | 11:23 |
| freemangordon | well, it is him that did the port of that part, IIRC | 11:24 |
| freemangordon | I have pp as well | 11:24 |
| uvos | freemangordon: it happens with -platform xcb | 11:24 |
| uvos | so his work is not involved | 11:24 |
| freemangordon | hmm, shouldn;t platform be maemo? | 11:24 |
| uvos | must be hildon misplacing the window | 11:24 |
| uvos | freemangordon: not for those programs they dont work right with platfrom maemo | 11:24 |
| freemangordon | so, you expect 'ordinary' menus to work? | 11:25 |
| uvos | freemangordon: yes | 11:25 |
| freemangordon | I see | 11:25 |
| uvos | freemangordon: i expect normal qt to work | 11:25 |
| freemangordon | hildon doesn;t place windows in regards to TS/mouse | 11:25 |
| uvos | hildon dosent/cant place drop down menus | 11:26 |
| freemangordon | so the issue is 64bit most probably | 11:26 |
| uvos | they are overide-redirect again :P | 11:26 |
| freemangordon | hehe :) | 11:26 |
| uvos | but clutter might misplace them | 11:26 |
| uvos | the surface only | 11:26 |
| uvos | not the window | 11:26 |
| freemangordon | well, pp won;t give us a clue if it is 32 vs 64 bits, because of the enidaness I am afraid | 11:27 |
| freemangordon | *endianess | 11:27 |
| freemangordon | but I can test in my VM later on | 11:27 |
| uvos | ? amd64 and arm64 are both le right | 11:27 |
| freemangordon | are they? | 11:28 |
| uvos | yeah i think so | 11:28 |
| uvos | google... | 11:28 |
| freemangordon | I though arm is BE | 11:28 |
| freemangordon | ok, if you say so | 11:28 |
| freemangordon | uvos: sorry, but what exactly is "menu bar"? | 11:29 |
| uvos | qmenubar | 11:29 |
| uvos | ie the file menu etc | 11:29 |
| freemangordon | ok | 11:29 |
| freemangordon | I just wanted to be sure | 11:29 |
| freemangordon | uvos: I am not sure clutter is involved at all here | 11:29 |
| freemangordon | it just displays TFP texture | 11:30 |
| uvos | clutter must render the surface | 11:30 |
| freemangordon | it renders a texture, nothing more | 11:30 |
| freemangordon | and it is Texture_From_Pixmap, as I said | 11:30 |
| uvos | it can render them out of order | 11:30 |
| freemangordon | it is a single texture, what do you mean? | 11:31 |
| uvos | this is what happend with fs overide redirect windows in the past | 11:31 |
| uvos | its mulitple x windows | 11:31 |
| uvos | so it should be muliple textures right | 11:31 |
| uvos | but its not that | 11:31 |
| uvos | the menu dosent apper with composeting suspended | 11:31 |
| freemangordon | ok | 11:32 |
| uvos | so xorg isent rendering the menu either | 11:32 |
| freemangordon | sorry, have to go afk for a while, ttyl | 11:32 |
| uvos | ttyl | 11:32 |
| Wizzup | uvos: freemangordon: I tested qt5 mostly in the vm | 11:55 |
| Wizzup | Is the problem with SMplayer? | 11:56 |
| Wizzup | freemangordon: regarding alarms and pulse, it's known and I've been gathering resources to start working on it | 11:56 |
| Wizzup | https://leste.maemo.org/Status/Audio | 11:57 |
| Wizzup | freemangordon: it's also required for the volumeapplet | 11:57 |
| uvos | Wizzup: its every qt app | 11:58 |
| Wizzup | huh? | 11:58 |
| uvos | menu bar works in no qt app | 11:58 |
| Wizzup | is this with normal qt menus that are not hildon menus? | 11:58 |
| Wizzup | ok | 11:58 |
| Wizzup | and this is not specific to our QT modules | 11:58 |
| Wizzup | ? | 11:58 |
| uvos | no just stock qt | 11:59 |
| Wizzup | just to be clear, that means these are also not set: | 11:59 |
| Wizzup | QT_STYLE_OVERRIDE=maemo5 | 11:59 |
| Wizzup | QT_QPA_PLATFORM=maemo | 11:59 |
| Wizzup | QT_IM_MODULE=him | 11:59 |
| Wizzup | right so the menus don't show / get misplaced | 12:00 |
| uvos | it means $(APP) -platform xcb -style fusion | 12:00 |
| Wizzup | I have also seen this with some gtk2 apps | 12:00 |
| uvos | which overrides the envvars | 12:00 |
| Wizzup | depending on the size of the menu | 12:00 |
| uvos | well it works on d4 but not on vm | 12:00 |
| uvos | so the menus fit for sure | 12:00 |
| uvos | since d4 is smaller | 12:00 |
| Wizzup | hm | 12:01 |
| Wizzup | ok, I will try to quickly reproduce on pp and droid4 (I see it does not work in vm), but cannot investigate rn | 12:01 |
| Wizzup | yep, works on d4 | 12:02 |
| Wizzup | freemangordon: uvos: yeah, no workie on pinephone (64bit) | 12:06 |
| Wizzup | that's surprising | 12:06 |
| uvos | its also not my recent override redirect changes | 12:07 |
| uvos | because my vm is not updated | 12:07 |
| diejuse | mmm logbot for libera chat to see the conversation history? | 12:13 |
| Wizzup | uvos: it's possible it never worked | 12:15 |
| diejuse | Wizzup: https://github.com/diejuse/chroot_Maemo-leste_on_Android But I haven't finished it yet. | 12:15 |
| diejuse | Some things are still missing. | 12:16 |
| Wizzup | diejuse: hey sweet | 12:16 |
| Wizzup | I think it would be good/interesting to also see how openrc softmode can work? Or how do you start services like mce currently? | 12:17 |
| Wizzup | diejuse: launchMaemo.sh is not in the repo yet | 12:19 |
| diejuse | Wizzup: Sure, I said I haven't finished everything yet. | 12:25 |
| Wizzup | diejuse: check | 12:25 |
| Wizzup | diejuse: maybe another way to test some of the non-android specific stuff is with Xnest and a chroot on regular linux | 12:25 |
| diejuse | Wizzup: maybe | 12:26 |
| Wizzup | diejuse: I'll try it later if you'd like | 12:27 |
| diejuse | Wizzup: Where can I consult the conversation of libera chat? I have to disconnect at times, I'm at work | 12:27 |
| Wizzup | diejuse: well we have a the everything-in-a-really-large-file log here: https://maedevu.maemo.org/irc.txt | 12:28 |
| Wizzup | the whitequark ones are not on libera yet I believe | 12:28 |
| diejuse | mm ok, mm it's a disadvantage, thanks | 12:29 |
| uvos | the real way for use to test hildon would be to make it a xdg-session | 12:43 |
| uvos | then you could just logg out of your gnome-dekstop or whatever and log into hildon on desktop | 12:43 |
| freemangordon | do we have something in the syslog when menus doesn;t work? | 12:48 |
| Wizzup | uvos: I just want to test openrc with chroot to make all the services start/work | 12:53 |
| Wizzup | idk how elogind does that stuff :) | 12:55 |
| freemangordon | Wizzup: couould you check in the syslog for some weird message by the time qt menu misbehaves? | 13:09 |
| freemangordon | Wizzup: alos, anything you can do about https://phoenix.maemo.org/job/gtk-repos/17/console as it seems parazyd is MIA | 13:11 |
| parazyd | hmm seems the udebs are trying to be built again | 13:26 |
| parazyd | Will fix | 13:26 |
| parazyd | note-to-self: Also update xorg | 13:27 |
| Wizzup | freemangordon: weird, this doesn't seem to be explicitly defined anywhere: https://github.com/search?q=org%3Amaemo-leste+ICD_GCONF_SRV_PROVIDERS&type=code | 14:06 |
| Wizzup | parazyd: freemangordon: libicd-service-dummy or libicd-provider-dummy ? | 14:18 |
| Wizzup | I suppose the latter naming might make a bit more sense than the generic 'service' | 14:18 |
| parazyd | Provider | 14:18 |
| parazyd | Yeah | 14:18 |
| Wizzup | ok | 14:18 |
| parazyd | Did you figure it out relatively? | 14:18 |
| parazyd | I wonder if there are parts not RE'd yet | 14:19 |
| diejuse | a xinput workaround could work to get the menu options to display? emulating the touchs with clicks, or something like that... | 14:20 |
| Wizzup | parazyd: working on it | 14:27 |
| diejuse | Wizzup: launchMaemo.sh uploaded, you can try if you want | 14:29 |
| Wizzup | diejuse: ok, thx, will try later (busy atm) | 14:29 |
| Wizzup | diejuse: great work though :) | 14:29 |
| diejuse | Wizzup: thanks! It is my pleasure, this Linux project for mobile phones is the one I like the most and it fits with my vision. | 14:31 |
| diejuse | * it is a pleasure for me | 14:31 |
| Wizzup | :) | 14:32 |
| Wizzup | parazyd: freemangordon: heh the init function is called icd_srv_init | 14:32 |
| Wizzup | let's just go with provider for now | 14:33 |
| Wizzup | in gconf it is key>/schemas/system/osso/connectivity/srv_provider/DUMMY/module | 14:33 |
| Wizzup | srv_provider | 14:33 |
| parazyd | I think provider is a good nomenclature | 14:33 |
| parazyd | Service is kinda ambiguous, and also links with initscripts | 14:34 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/libicd-provider-dummy | 15:46 |
| Wizzup | freemangordon: if you have some time later today (in the evening I think) I'd like to pick your brain for a moment about ^ | 15:53 |
| freemangordon | Wizzup: sure | 17:52 |
| Wizzup | Ack | 17:52 |
| Wizzup | freemangordon: what would be a good time? | 17:57 |
| freemangordon | for how long you need my brain? | 17:58 |
| freemangordon | because if it is a short discussion, we may even do it now | 17:59 |
| Wizzup | ok, give me a minute | 17:59 |
| Wizzup | freemangordon: so there's a few things, first news is that the libicd-provider-dummy module loads, and apparently there is an identify callback for the module to say if it supports the networktype/iap, and if it does, I believe the network attribute ICD_NW_ATTR_SRV_PROVIDER will be added | 18:02 |
| freemangordon | shaww we look at the code? | 18:03 |
| Wizzup | sure, I have it open | 18:03 |
| Wizzup | but there are a few more things | 18:03 |
| Wizzup | so currently the repo as linked sets up what I believe is the right schema, and then when I start the dummy network (using libicd-network-dummy), I get as far as this: | 18:04 |
| Wizzup | May 24 18:03:14 localhost icd2 0.96[30792]: calling service provider module | 18:04 |
| Wizzup | May 24 18:03:14 localhost icd2 0.96[30792]: srv type '' unknown | 18:04 |
| Wizzup | and then aside from all of this, connui-* seems to have various support things for service modules, with odd gconf keys | 18:04 |
| Wizzup | e.g. | 18:05 |
| Wizzup | https://github.com/maemo-leste/connui-common/blob/master/connui/iap-common.c#L160 | 18:05 |
| freemangordon | ok, so what is the issue? | 18:06 |
| freemangordon | "srv type '' unknown"? | 18:06 |
| Wizzup | yes, that's the main issue, but also it seems like there is some way to define custom ui modules in connui for services | 18:06 |
| Wizzup | through gconf or something | 18:06 |
| Wizzup | https://github.com/maemo-leste/connui-common/blob/master/connui/iap-settings.c#L546 | 18:07 |
| freemangordon | yeah, but lets first see why it fails to init | 18:07 |
| freemangordon | gimme a minute to start up the tools | 18:07 |
| Wizzup | ok | 18:08 |
| Wizzup | btw, looks like activated services even get their own icon: https://github.com/maemo-leste/connui-internet/blob/master/src/status-menu-item/status-menu-item.c#L117 | 18:11 |
| freemangordon | nice :) | 18:12 |
| freemangordon | BTW, may I have the full init log? | 18:12 |
| freemangordon | with debug loglevel | 18:12 |
| freemangordon | or shall I build that here? | 18:12 |
| Wizzup | the module should build locally, I think that might be easier | 18:13 |
| freemangordon | ok | 18:13 |
| freemangordon | Wizzup: make[2]: ./autogen.sh: Command not found | 18:15 |
| Wizzup | freemangordon: ah, sec | 18:16 |
| Wizzup | freemangordon: pushed | 18:16 |
| Wizzup | It does seem to call icd_srv_provider_connect | 18:16 |
| Wizzup | but this is what says that the type is unknown | 18:16 |
| freemangordon | yes, I see that | 18:16 |
| freemangordon | service type should come from the init function | 18:17 |
| freemangordon | but I want to see what it thinks about it | 18:17 |
| Wizzup | It looks like the iap service type is not ok: | 18:17 |
| Wizzup | (gdb) print iap->connection.service_type | 18:17 |
| Wizzup | $4 = (gchar *) 0x5555555a20d0 "" | 18:17 |
| freemangordon | sure it is noit | 18:17 |
| freemangordon | the log says the same :) | 18:17 |
| Wizzup | yes, but this is from the iap | 18:17 |
| Wizzup | so I am thinking maybe this is a service_type specific to the IAP | 18:17 |
| Wizzup | (perhaps read from gconf) | 18:17 |
| freemangordon | looks like, that's why I want the logs :) | 18:18 |
| Wizzup | ok | 18:18 |
| freemangordon | to confirm | 18:18 |
| Wizzup | Please let me know if you managed to build it | 18:18 |
| freemangordon | yep, just built it | 18:18 |
| Wizzup | icd_request.c assigned connection.service_type | 18:19 |
| Wizzup | Which is in icd_request_add_iap, but that is called through some policy or dbus code and then I lost track of where it comes from | 18:20 |
| freemangordon | hmm: service provider module 0x56342a36ff10 'libicd_provider_dummy.so' version 0.96 srv type '/DUMMY' | 18:21 |
| freemangordon | May 24 19:21:11 localhost icd2 0.96[11037]: Loading plugin /usr/lib/icd2/libicd_provider_dummy.so | 18:23 |
| freemangordon | May 24 19:21:11 localhost icd2 0.96[11037]: service provider module 0x56342a36ff10 'libicd_provider_dummy.so', network type 'DUMMY' | 18:23 |
| freemangordon | May 24 19:21:11 localhost icd2 0.96[11037]: service provider module 0x56342a36ff10 'libicd_provider_dummy.so' version 0.96 srv type '/DUMMY' | 18:23 |
| freemangordon | Wizzup: ^^^ | 18:23 |
| freemangordon | this looks fine to me | 18:23 |
| Wizzup | yes | 18:23 |
| Wizzup | freemangordon: ok, so now connect using the status bar to DUMMY network | 18:23 |
| Wizzup | this is when you will see the message from icd_srv_provider_connect | 18:23 |
| freemangordon | though, what I don;t like is that '/' in front of dummy | 18:23 |
| freemangordon | this could be a RE bug | 18:24 |
| Wizzup | yes, I saw that and wondered if that was a problem | 18:24 |
| Wizzup | my schemas looked OK | 18:24 |
| freemangordon | hmm, do I need wifi dongle? | 18:25 |
| freemangordon | or something else set up? | 18:25 |
| freemangordon | because connections list is empty here | 18:25 |
| freemangordon | Wizzup: ^^^ | 18:27 |
| Wizzup | freemangordon: do you have libicd-network-dummy installed? | 18:27 |
| Wizzup | (read: not libicd-provider-dummy, that's the one we're working on now) | 18:27 |
| freemangordon | no, I don;t | 18:28 |
| Wizzup | libicd-provider-dummy only likes networks from libicd-network-dummy | 18:28 |
| freemangordon | ok | 18:28 |
| Wizzup | ok, please install it and run the gconftool commands as postinst says | 18:28 |
| freemangordon | ok | 18:28 |
| freemangordon | Wizzup: ok, bug triggered | 18:34 |
| Wizzup | I believe I tried this and it didn't help: gconftool -t string -s /system/osso/connectivity/IAP/DUMMY/service_type DUMMY | 18:38 |
| Wizzup | (it's also not clear to me where the (internal) service_id's come from) | 18:39 |
| freemangordon | dinner, brb | 18:45 |
| Wizzup | same :) | 18:47 |
| freemangordon | Wizzup: service type comes from dbus ICD_DBUS_API_CONNECT_REQ | 19:18 |
| freemangordon | going to check who issues it | 19:18 |
| Wizzup | mhm | 19:19 |
| freemangordon | iap_network_entry_connect() (connui-common) | 19:20 |
| freemangordon | in iap_network_entry_connect(): | 19:26 |
| freemangordon | (gdb) p **entries | 19:26 |
| freemangordon | $2 = {service_type = 0x56068727aca0 "", service_attributes = 0, service_id = 0x5606871ea340 "", network_type = 0x56068717bd70 "DUMMY", network_attributes = 83886080, network_id = 0x5606871f14f0 "DUMMY"} | 19:26 |
| Wizzup | Is that read from gconf? | 19:28 |
| Wizzup | It shouldn't come from the identify callback, right? | 19:28 |
| freemangordon | trying to fugure out | 19:29 |
| Wizzup | hm, it looks like I do have 'gchar* service_id' as '0' in my code, but that should not matter (I'll work on fixing it) | 19:30 |
| freemangordon | Wizzup: seems to comr from iap_scan_icd_signal() | 19:42 |
| freemangordon | *come | 19:42 |
| freemangordon | seems icd2 sends service_type in ICD_DBUS_API_SCAN_SIG | 19:45 |
| Wizzup | those come from the dummy module amongst others then I guess | 19:47 |
| freemangordon | mhm | 19:48 |
| freemangordon | trying to figure out how it is sent to icd2 | 19:48 |
| Wizzup | well I guess they originally come from icd2, but then go to connui, and then back? | 19:49 |
| freemangordon | mhm | 19:51 |
| freemangordon | trying to figure out where icd2 gets them when sending the signal | 19:52 |
| freemangordon | *gets them from | 19:52 |
| Wizzup | sorry it's turning into a long search | 20:02 |
| freemangordon | Wizzup: "cannot accept partial srv info, type 'DUMMY' and id '(null)'" | 20:05 |
| freemangordon | this is in icd_srv_provider_identify_cb | 20:05 |
| Wizzup | why did I not see that message? | 20:06 |
| Wizzup | :( | 20:06 |
| Wizzup | so it is the service_id being zero | 20:06 |
| freemangordon | looks like | 20:06 |
| Wizzup | was this msg in syslog? | 20:07 |
| freemangordon | Wizzup: lemme fix it and see what will happen | 20:07 |
| freemangordon | yes | 20:07 |
| freemangordon | May 24 21:01:58 localhost icd2 0.96[12643]: '[SCAN]' type 'DUMMY' ICD_STATUS_CHANGED_SIG with status SCAN_START, '' sent to '(null)' | 20:07 |
| freemangordon | May 24 21:01:58 localhost icd2 0.96[12643]: sending ICD_SCAN_NEW nw DUMMY/5000000/DUMMY srv -/-/- | 20:07 |
| freemangordon | May 24 21:01:58 localhost icd2 0.96[12643]: cannot accept partial srv info, type 'DUMMY' and id '(null)' | 20:07 |
| freemangordon | May 24 21:01:58 localhost icd2 0.96[12643]: module 'libicd_network_dummy.so' scan completed | 20:07 |
| freemangordon | Wizzup: what is this service_id? | 20:07 |
| freemangordon | I don;t grok the documentation | 20:07 |
| Wizzup | freemangordon: same problem here :) | 20:08 |
| Wizzup | I set it to a random string and now it shows up in the connection dialog | 20:08 |
| freemangordon | :) | 20:08 |
| Wizzup | e.g. https://paste.villavu.com/raw/ltWeQzh2L8zcV48wMHhJ3qJwMak3u10inmfFkbf7/ | 20:08 |
| freemangordon | but you have preferred_id and preferred_type | 20:09 |
| Wizzup | It's not quite clear to me still how this works | 20:09 |
| Wizzup | if you apply that patch, you should see the same | 20:09 |
| freemangordon | better push it | 20:09 |
| Wizzup | ok, I am not sure if it's the correct code, but sure | 20:09 |
| Wizzup | in any case I think I can continue implementing some stubs | 20:10 |
| freemangordon | well, docs are not really helpful | 20:10 |
| Wizzup | the docs are mostly non existent, except for icd2/icd/srv_provider_api.h | 20:10 |
| Wizzup | that's why I was digging around in connui just to get a sense of what is even used where, etc | 20:11 |
| Wizzup | pushed btw | 20:11 |
| freemangordon | lemme pull, to see what is the result :) | 20:12 |
| Wizzup | you will see the service in the connection dialog | 20:12 |
| Wizzup | it's not clear that it belongs to the dummy network, or if you have to connect to the dummy network first, and then select it or something | 20:12 |
| Wizzup | but since I didn't actually implement dummy_connect() yet, nothing will happen on connect still | 20:12 |
| Wizzup | I should call the connect_cb at least :-) | 20:13 |
| freemangordon | I guess you should not connect to the network first, icd2 shall do it for you I hope | 20:14 |
| Wizzup | freemangordon: well, do you see what it looks like? | 20:17 |
| freemangordon | yep | 20:17 |
| freemangordon | also, it connected the DUMMY network automatically | 20:17 |
| Wizzup | when you click the "Dummy Provider", right? | 20:18 |
| freemangordon | yes | 20:18 |
| Wizzup | I am not sure how that works if it supports WLAN_INFRA network types | 20:18 |
| Wizzup | e.g. what does it even pick | 20:18 |
| Wizzup | I suppose the dummy_identify can poke around in gconf to see if it should be enabled | 20:18 |
| freemangordon | maybe if there are more networks, it will ask | 20:19 |
| Wizzup | btw, I get this now: | 20:19 |
| Wizzup | May 24 20:19:27 localhost icd2 0.96[6961]: srv type 'DUMMY' unknown | 20:19 |
| Wizzup | so that might be the RE bug mentioned earlier | 20:19 |
| Wizzup | let me verify that it is matching against '/DUMMY' | 20:20 |
| freemangordon | most-probably | 20:20 |
| Wizzup | (gdb) print icd_ctx->srv_type_to_srv_module | 20:21 |
| Wizzup | $4 = 0x5555555812a0 = {[0x555555595b40 "/DUMMY"] = 0x555555596f50} | 20:21 |
| Wizzup | (gdb) print iap->connection.service_type | 20:21 |
| Wizzup | $5 = (gchar *) 0x5555555a20d0 "DUMMY" | 20:21 |
| Wizzup | yup | 20:22 |
| freemangordon | mhm | 20:23 |
| freemangordon | lemme check why it is like that | 20:23 |
| freemangordon | Wizzup: yep. there is REing bug, going to fix | 20:29 |
| Wizzup | freemangordon: ty | 20:31 |
| Danct12 | o/ | 20:34 |
| Wizzup | hello | 20:34 |
| freemangordon | service provider module 0x555555597590 'libicd_provider_dummy.so' version 0.96 srv type 'DUMMY' | 20:35 |
| freemangordon | :) | 20:35 |
| freemangordon | ok, going to changelog and push and rebuild | 20:35 |
| Wizzup | freemangordon: ty | 20:36 |
| Wizzup | brb | 20:36 |
| Wizzup | I guess I will have to collect all the special service/provider related bits and log them somewhere | 20:36 |
| Wizzup | we will also need some UI to be able to configure it perhaps | 20:36 |
| freemangordon | nice, gtk2 no longer leaks memory, at least in icon_info_ensure_scale_and_pixbuf() | 20:46 |
| Wizzup | cool | 20:46 |
| Wizzup | I'll brb and then see if I can finish the dummy provider, and then look at how it stacks | 20:47 |
| Wizzup | and then make the tor provider :) | 20:47 |
| freemangordon | Wizzup: BTW, fixed icd2 should be in -devel in 3 minutes or so | 20:48 |
| Wizzup | yeah, watching channel | 20:48 |
| freemangordon | lets hope we will not need to build the modules | 20:49 |
| freemangordon | Wizzup: seems to work fine after the upgrade | 20:58 |
| Wizzup | getting a lot of this in daemon.log btw: | 21:02 |
| Wizzup | May 24 21:01:46 localhost mce[3349]: mce_write_string_to_file() called with file == NULL! | 21:02 |
| Wizzup | quite spammy | 21:02 |
| freemangordon | me too | 21:04 |
| freemangordon | but otherwise seems harmless | 21:04 |
| Wizzup | annoying when reading icd2 logs ;) | 21:04 |
| freemangordon | will see if I can fix that in the incomming days | 21:04 |
| freemangordon | well, you can | grep icd | 21:05 |
| freemangordon | parazyd: any idea why only libgtk2.0-common was upgraded on d4? | 21:48 |
| freemangordon | parazyd: this is crazy https://pastebin.com/cS0YWTmu | 21:51 |
| Wizzup | freemangordon: it's possible that the armhf machine got stuck | 21:52 |
| Wizzup | and this is causing it somehow | 21:52 |
| Wizzup | because the 'all' builds on another build host | 21:53 |
| freemangordon | yeah | 21:53 |
| freemangordon | actually it failed | 21:53 |
| Wizzup | I am moving the sata over ethernet to being SSD backed tonight | 21:53 |
| freemangordon | https://phoenix.maemo.org/job/gtk-binaries/architecture=armhf,label=armhf/11/console | 21:54 |
| freemangordon | shall I respin the build? | 21:54 |
| freemangordon | Wizzup: shall I restart the build? | 21:55 |
| Wizzup | freemangordon: let's try it | 22:05 |
| Wizzup | freemangordon: it feels like nokia had some neat ideas with the srv_provider code but it wasn't finished | 22:09 |
| Wizzup | as in, the service_id is probably to have multiple configurations of said services | 22:10 |
| Wizzup | but there's no UI to configure any of it if I understand correctly | 22:10 |
| freemangordon | Wizzup: it seems the UI shall be impemented per srv provider | 22:10 |
| freemangordon | I guess it is the same wizard as for an ordinary connection | 22:11 |
| freemangordon | to me the code (backend) seems finished | 22:11 |
| Wizzup | iap_settings_get_name seems like there is some UI code for it | 22:12 |
| freemangordon | where? | 22:14 |
| Wizzup | freemangordon: sorry, no actual gtk-ui, but I agree the backend seems mostly finished | 22:14 |
| Wizzup | so we'll have to figure out how to make wizard-ui's for this stuff | 22:15 |
| freemangordon | mhm | 22:15 |
| freemangordon | though I guess it shouldn;t be that hard | 22:15 |
| Wizzup | there does seem to be stuff like this: | 22:15 |
| Wizzup | else if (GTK_IS_LABEL(label)) | 22:16 |
| Wizzup | { | 22:16 |
| Wizzup | g_object_set(label, "label", service_text, NULL); | 22:16 |
| Wizzup | g_object_set(label, "use-markup", FALSE, NULL); | 22:16 |
| freemangordon | see https://github.com/maemo-leste/connui-cellular/blob/master/wizard/gprs.c | 22:17 |
| freemangordon | looks pretty easy | 22:17 |
| Wizzup | does it not need more glue and stuff? | 22:18 |
| Wizzup | that would be nice, I haven't looked in detail yet | 22:18 |
| freemangordon | no, iiuc | 22:18 |
| freemangordon | this set all the stuff under $IAP | 22:18 |
| freemangordon | IIRC | 22:18 |
| Wizzup | ok, maybe I will modify libicd-network-dummy a bit to add icons and also make a dummy wizard for learning purposes | 22:19 |
| Wizzup | So they go in here, ok: /usr/lib/*/iapsettings/ | 22:21 |
| freemangordon | I don't really remember how was all that glued | 22:21 |
| freemangordon | yah, seems like wizards are activated through iap_settings | 22:22 |
| freemangordon | look at connui-internet/src/settings/wizard.c on how wizards are invoked | 22:24 |
| freemangordon | maybe it is different for srv provider | 22:24 |
| freemangordon | seen http://maemo.org/api_refs/5.0/5.0-final/icd2/group__srv__provider__api.html ? | 22:31 |
| Wizzup | yes | 22:39 |
| Wizzup | nothing new though | 22:39 |
| freemangordon | Wizzup: maybe change srv provider type to WLAN_INFRA, maybe cpl inet settings applet will show some additional configs | 22:43 |
| freemangordon | I can try to do that as well | 22:43 |
| freemangordon | not now though, going to have some sleep | 22:43 |
| freemangordon | night! | 22:43 |
| Wizzup | gn | 22:57 |
| parazyd | gn! | 22:58 |
| Wizzup | well, I'm still awake :-p | 23:06 |
| parazyd | ^_^ | 23:08 |
| Wizzup | freemangordon: another reason for me to make a simple wizard for dummy connections, you you can 'edit' them in settings but the next button does nothing | 23:26 |
| Wizzup | freemangordon: once this works I'll look at the audio stuff | 23:31 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!