| stan | Droid4 question, on the back shell in teh battery compartment, there's a metal plate on the right side (seen with camera on top) - is that some kind of temperature sensor for battery? | 01:24 |
|---|---|---|
| stan | it seems to connect to mainboard via three contacts | 01:25 |
| buZz | i do believe there's no thermometer inside the battery | 01:39 |
| buZz | its only got two contacts | 01:39 |
| stan | not inside the battery buZz | 02:15 |
| stan | back shell of the device, along the black plastic, there is a metal strip | 02:15 |
| buZz | yeah i mean, many portable devices have 3 pins to the battery, because there's a thermistor is similar inside | 02:15 |
| buZz | or* similar | 02:16 |
| stan | have you a disassembled droid4 handy? | 02:16 |
| buZz | no, just one here :) | 02:16 |
| buZz | step 12 on https://www.ifixit.com/Teardown/Motorola+Droid+4+Teardown/7759 | 02:20 |
| buZz | perhaps? | 02:20 |
| stan | buzz, seems to boot without any of those things on the back cover connected | 03:15 |
| stan | there's a removable rubber tab next to the speaker also, i wonder what that was intended for | 03:16 |
| Daanct12 | Good morning aikon fellas | 05:06 |
| stan | hi Daanct12 hows your maemo-leste experiences | 05:09 |
| Daanct12 | Pretty ok, except for the fact that i couldn't find apps i need | 05:26 |
| parazyd | Wizzup: Could you link to the code where this advanced_show ism | 08:43 |
| parazyd | is? | 08:43 |
| _uvos_ | stan: the contacts in the rear frame are antennas. from memor,y the ones at the bottom are for cellular | 09:13 |
| _uvos_ | the rubber around the speaker is for dampening ofc | 09:14 |
| Wizzup | parazyd: the plugin part or the plugin loader part? | 11:07 |
| parazyd | 22:30 <Wizzup> parazyd: freemangordon: looks like connui plugins can have plugin->advanced_show = to have settings show up in advanced settings, so we could do that for provider | 11:08 |
| parazyd | This | 11:08 |
| Wizzup | https://github.com/maemo-leste/connui-wlan/blob/master/wizard/wlan.c#L1886 | 11:08 |
| parazyd | Thanks | 11:09 |
| freemangordon | Pali: hi! | 12:26 |
| freemangordon | Do you think we can do anything else re u-boot but migrate to DT? | 12:26 |
| Pali | freemangordon: Hi! | 12:26 |
| freemangordon | keep in mind that ACM functionality won;t be affected by that, IIUC | 12:27 |
| Pali | I'm wondering how long would take them again to review patches... | 12:28 |
| freemangordon | and by removing dead code we can keep -mthumb disabled | 12:28 |
| Pali | there are still more n900 patches in queue | 12:28 |
| freemangordon | well, I guess we can put pressure now we are forced to do DT | 12:28 |
| freemangordon | also, I still think Tom is a reasonable guy | 12:29 |
| Pali | do we have enough space for DTB blob? and do we have space for libfdt code? | 12:29 |
| freemangordon | yes, we do | 12:29 |
| freemangordon | once we remove host and hub code | 12:29 |
| freemangordon | worst case we'll enable -mthumb | 12:30 |
| freemangordon | NOLO manages to live with it, so I am (almost) sure u-boot will do too | 12:30 |
| Pali | I do not have power for this project anymore... | 12:31 |
| freemangordon | :) | 12:31 |
| Pali | they just want from us things which are not required for other subsystems, like that requirement for DT | 12:31 |
| freemangordon | well, we can jsut fork | 12:31 |
| Pali | and I really do not have power to discuss on this topic anymore | 12:32 |
| freemangordon | ok | 12:32 |
| Pali | I did everything what was possible, but everytime they either ignore pending patches or come up with new idea how to increase work on this project, just because they can | 12:33 |
| Pali | I really do not understand this discussion as year ago we were told that U_BOOT_DRVINFOS() approach is OK | 12:37 |
| Pali | and now when we sent last patches for DM, somebody said that DTS is required | 12:38 |
| Pali | so it means that whole work which was done can be trashed and migration can start from zero again | 12:38 |
| Pali | not mentioning that these patches were waiting in queue for review for a very long time and nobody complained | 12:39 |
| freemangordon | ok then, I'll make one last effort(not now though) to convince Tom their approach is destructive and if that disagree, well, not much that can be done | 12:41 |
| uvos | Pali: dont let it get yourself down :) | 12:41 |
| freemangordon | uvos: feel free to join the discussion on the ML | 12:41 |
| uvos | Pali: besides, its a bootloader keeping it at some old working version as a fork is not sutch a huge loss | 12:41 |
| uvos | freemangordon: i think youd rather i not :P i think the "demands" are resonable. | 12:42 |
| Pali | you can guess what happen if we invest lot of time to DTS migration... | 12:42 |
| Pali | ... somebody else come up with another idea what is requirement for us and say that it must be done | 12:42 |
| Pali | and we will start again this discussion which ends up with the fact that what we did was useless... | 12:43 |
| freemangordon | yeah, looks like | 12:43 |
| uvos | i mean thair goal is pretty obivous, they want n900 to be as little maintaints burden as possible, that means proting to whatever is the latest mechanisum in uboot so it istent in the way of droping old mechanisums | 12:44 |
| uvos | would this be a good thing? yes! is it reasonable to make you do it? maybe no. | 12:45 |
| Wizzup | freemangordon: should we have one tab per provider in advance settings, or one tab with providers? I think the former | 12:45 |
| Pali | guess, how long would be this patch in queue? http://patchwork.ozlabs.org/project/uboot/patch/20210618132704.32066-1-pali@kernel.org/ | 12:46 |
| uvos | if its causing stress i would just fork. the it seams unlikely that uboot would add any functionality we would need within the resonable usefull life of the n900 no? | 12:46 |
| Pali | 3 months ? or 6 months? or 9 months? | 12:46 |
| lel | MerlijnWajer created a repository: https://github.com/maemo-leste/connui-provider | 12:55 |
| sicelo | freemangordon, sounds like you would be willing/able to do some of the DT migration for N900 u-boot? :) | 13:25 |
| sicelo | assuming you have the time/energy for it, i guess it's worthwhile to investigate | 13:26 |
| Wizzup | we really have a lot of other thing we'd rather focus on though. | 13:27 |
| Wizzup | that we need fmg for, too | 13:27 |
| Wizzup | uvos: btw, using mdbus2 you can see if ofono is willing to activate context at all, I find that sometimes the call to set the context to active just times out and it never works | 13:27 |
| Wizzup | and I don't know why ofono does that, but then the state forever cannot be changed | 13:27 |
| Wizzup | it will always say "operation in progress" | 13:28 |
| uvos | Wizzup: ok | 13:28 |
| uvos | Wizzup: ill take a look at ofono, but | 13:28 |
| Wizzup | one thing we could consider for debugging some of this is to use the ofono path where it does everything over usb | 13:29 |
| Wizzup | it's a big power draw but we can rule out ofono specific bugs this way | 13:29 |
| Wizzup | not for production usage, of course | 13:29 |
| uvos | my current todo list looks like this 1. add a mixer controll to kernel that activates the PGA for voice 2. rebase cmake mce 3. implment minimal mce stuff needed for sphone 4. fix sphone ofono 5. look a ofno | 13:30 |
| sicelo | of course | 13:30 |
| Wizzup | let's add mine as well then: 1. create connui-provider and learn about connui plugins 2. libicd-dummy-provider to act more like normal provider 3. wlan scan troubles 4. pulseaudio setup/integration (would give volume applet, alarms actually working, ...) | 13:31 |
| Wizzup | there's a lot of misc stuff too but that's my plan code wise | 13:31 |
| uvos | sounds good | 13:32 |
| Wizzup | If connui plugins work like how I understand they work, then it's kinda neat | 13:33 |
| uvos | thats good. so far connui has been a bit of a minefield from a users perspective | 13:34 |
| uvos | btw any idea about this https://github.com/maemo-leste/bugtracker/issues/476? | 13:35 |
| Wizzup | first time I see the ticket | 13:37 |
| Wizzup | not atm | 13:37 |
| uvos | ok | 13:37 |
| Wizzup | I'd have to test | 13:37 |
| uvos | not sure if its still a thing with connui changes | 13:37 |
| Wizzup | would be good to check I guess | 13:43 |
| tmlind | uvos: your voice call todo list order sounds good to me :) | 14:00 |
| Wizzup | freemangordon: ah, looks like connui will only allow one "plugin" per network type, so the idea of connui-provider as iapsettings plugins does not work | 14:22 |
| Wizzup | we'll have to add it to connui-internet or add some other plugin loading capabilities, potentially regardless of network type | 14:23 |
| Wizzup | so currently there can only be one active "advanced" plugin per network type | 14:30 |
| Wizzup | I will turn this into connui-dummy to at least make a simple plugin to show how it can work, and then look at adding providers to connui-internet directly, I think | 14:31 |
| lel | MerlijnWajer renamed a repository: https://github.com/maemo-leste/connui-dummy | 16:18 |
| sicelo | decision is to not RE the maemo phone application? | 16:21 |
| Wizzup | sicelo: if you have 5 years of your life to spare and want to fully RE it :) | 16:22 |
| Wizzup | we can definitely take parts, but all of it seems way too much work | 16:22 |
| sicelo | Ok | 16:25 |
| Wizzup | freemangordon: is this code correct? https://github.com/maemo-leste/connui-internet/blob/master/src/settings/wizard.c#L420 | 17:38 |
| Wizzup | freemangordon: nvm, I'll debug more later | 17:52 |
| Wizzup | uvos: ok yeah I can confirm that scans are started but the results aren't read by icd2 plugin somehow | 18:19 |
| Wizzup | will investigate that a bit later, spend quite a few hours on this connui-dummy now | 18:20 |
| Wizzup | uvos: oh... I think I see it | 18:23 |
| Wizzup | will confirm a bit later | 18:25 |
| Wizzup | uvos: so one problem was in my code which checked the return code of the wpa_ctrl_request, but it also looks like wpa supplicant does not populate bss info or something | 19:04 |
| Wizzup | running this | 19:04 |
| Wizzup | mdbus2 -s fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/0 org.freedesktop.DBus.Properties.Get fi.w1.wpa_supplicant1.Interface BSSs | 19:04 |
| Wizzup | mdbus2 -s fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/0/BSSs/418 org.freedesktop.DBus.Properties.GetAll org.freedesktop.DBus.Properties | 19:04 |
| Wizzup | ({},) | 19:04 |
| Wizzup | like wth | 19:04 |
| Wizzup | wpa_supplicant :-( | 19:08 |
| Wizzup | ah nevermind, my bad | 19:11 |
| Wizzup | that should be fi.w1.wpa_supplicant1.BSS | 19:11 |
| Wizzup | uvos: lol, this gets better, I'll let you know after coffee | 19:41 |
| Wizzup | so wpa_ctrl_request often returns -1 when it succeeds | 19:59 |
| Wizzup | and my code was checking for it to be == 0, and it should be != 0 because of how the function returns its result, but then I got no scans at all since it always reported failure, even though it did scan | 19:59 |
| Wizzup | just ignoring the result all together seems to make it work just like old times (well) | 19:59 |
| Wizzup | I'll have to dive in a bit more I suppose, see why it's failing like this | 20:00 |
| Wizzup | uvos: please apt update && apt upgrade | 20:57 |
| Wizzup | I think I fixed the problem | 20:57 |
| lel | MerlijnWajer closed an issue: https://github.com/maemo-leste/bugtracker/issues/554 (Flakey wifi scanning) | 20:57 |
| stan | congratulations Wizzup | 20:57 |
| Wizzup | parazyd: I think with new ke-recv the reboot problem might be gone? seems weird though, I can't reproduce anymore | 21:00 |
| Wizzup | stan: yw hope it helps | 21:00 |
| bencoh | sicelo: the fremantle phoneapp isn't that good anyway, in my opinion | 21:08 |
| Wizzup | we'll keep the rtcom-eventlogger backend and stuff, and also have tp integration eventually of course | 21:11 |
| Wizzup | parazyd: connui-dummy is there, it's not of much use, but it was missing and it was good for me to learn how to do this | 21:33 |
| bencoh | Wizzup: was the wifi-switcher applet left behind on purpose? | 21:35 |
| bencoh | oh btw, I get 116mW on droid4 after boot and wlan0 interface down, which is nice | 21:38 |
| stan | btw i have one otg hub that works, but the very compact one here does not for me - as soon as i plugin a device i get disconnects/reconnects on the usb hub https://www.ebay.de/itm/294134869562?hash=item447bcdee3a:g:8csAAOSwbhNgNhR4 | 21:38 |
| Wizzup | this? http://maemo.org/packages/view/wifi-switcher/ | 21:39 |
| bencoh | Wizzup: yeah | 21:39 |
| bencoh | Wizzup: I'm building it right now, I need to know what should be kept then | 21:39 |
| bencoh | (if at all) | 21:39 |
| Wizzup | bencoh: hm, we can include it, the other thing we can do is have the icd2 plugin just off the interface if auto scanning is not enabled | 21:39 |
| bencoh | Wizzup: that'd be even better tbh | 21:39 |
| Wizzup | (I looked at the required ioctl's for that a while ago) | 21:39 |
| bencoh | err, actually maybe not | 21:39 |
| bencoh | well, maybe add an option for it | 21:40 |
| bencoh | because I wouldn't want it to interfere with me playing with my wifi from the shell | 21:40 |
| Wizzup | I can do that now with my newfound connui knowledge | 21:40 |
| Wizzup | maybe see if you can get it going (wifi-switcher) | 21:40 |
| bencoh | Wizzup: your option sounds much better, as long as it is configurable | 21:41 |
| bencoh | although ... I wonder what should happen when opening the connection dialog | 21:42 |
| bencoh | should it just activate it and start scanning? | 21:42 |
| Wizzup | yes | 21:43 |
| Wizzup | and then deactivate after some timer | 21:43 |
| bencoh | meaning we don't offer the user an option to disable wifi altogether | 21:44 |
| Wizzup | right | 21:44 |
| bencoh | well ... I dunno :) | 21:45 |
| bencoh | do we have wlancond on leste btw? | 21:45 |
| bencoh | for the past few days I feel like I'm digging a graveyard | 21:45 |
| bencoh | I keep fiddling with 10yo broken buildsystems and their silly deps | 21:46 |
| stan | what application are you ressurrecting bencoh ? | 21:46 |
| bencoh | stan: right now, wifi-switcher | 21:46 |
| bencoh | before that, I brought the pidgin-status applet back | 21:47 |
| bencoh | and fiddled with pidgin libnotify | 21:47 |
| bencoh | which reminds me ... should libnotify notifications work on leste/hildon? | 21:47 |
| stan | a few minutes of searching did not reveal what wifi-switcher is for. can you tell me please bencoh? | 21:50 |
| bencoh | stan: http://maemo.org/packages/view/wifi-switcher/ | 21:51 |
| stan | looks nice. is there a gpsd switcher also? | 21:52 |
| bencoh | gps/location is handled automagically and configurable | 21:53 |
| bencoh | you can disable location altogether from the Settings | 21:54 |
| Wizzup | bencoh: no, we don't have wlancond | 21:54 |
| Wizzup | bencoh: and yes, sometimes the ancient build systems are terrible and it's best to just re-do them | 21:54 |
| sixwheeledbeast | didn't wifi-switcher have some issue? | 21:55 |
| bencoh | sixwheeledbeast: what kind of issue? | 21:55 |
| bencoh | Wizzup: yeah, I reached the same conclusion and started removing everything | 21:55 |
| sixwheeledbeast | I recall it as one of those packages to avoid but I can't recall exactly, wifi issues maybe? | 21:56 |
| sixwheeledbeast | like autodisconnect | 21:56 |
| bencoh | dunno, I use it daily on n900 | 21:57 |
| stan | i found a thread where one user reported problems with one AP using wifi-switcher | 21:57 |
| sixwheeledbeast | maybe that was it | 21:58 |
| sixwheeledbeast | http://wiki.maemo.org/Community_SSU/known_broken_packages | 21:58 |
| sixwheeledbeast | not clearly proven, so left in devel maybe? | 21:58 |
| sixwheeledbeast | oh no its extras package | 21:59 |
| bencoh | looks like I have something working ... apart from the fact that it doesn't update the status applet (it should say "off" when wifi is disabled) | 22:20 |
| bencoh | heh, the applet itself checks whether module is loaded or not ... | 22:21 |
| Wizzup | bencoh: it's possible that the current icd2 module doesn't handle the interface going off (i.e. the applet might still show connected) | 22:23 |
| Wizzup | I think I need to handle that wpa_supplicant dbus signal still | 22:24 |
| bencoh | Wizzup: it reads /proc/modules | 22:24 |
| Wizzup | I meant wrt updating the status applet | 22:24 |
| bencoh | yeah, me too | 22:24 |
| Wizzup | ok | 22:24 |
| bencoh | but I don't unload the driver, so it's makes sense | 22:24 |
| Wizzup | ok | 22:24 |
| Wizzup | reading specific driver name is not ideal | 22:24 |
| Wizzup | we could probably find out which driver owns which interface | 22:25 |
| bencoh | I don't intend to unload the driver anyway, unless you think it'd be better | 22:25 |
| bencoh | oh, I'm currently testing on droid4, btw | 22:25 |
| Wizzup | check | 22:26 |
| bencoh | we might want to release a slightly different version for n900 | 22:26 |
| Wizzup | why? | 22:27 |
| bencoh | on n900 it used to unload driver, I dunno if this is still required on mainline | 22:31 |
| Wizzup | https://wizzup.org/provider-connui.mp4 wip | 22:45 |
| Wizzup | parazyd: ^ :) | 22:45 |
| bencoh | :) | 22:46 |
| Wizzup | does anyone know any sensible dummy icons? | 22:47 |
| Wizzup | preferrably already avail on leste | 22:47 |
| * bencoh gives a dummy look | 22:48 | |
| Wizzup | hehe | 22:48 |
| Wizzup | maybe I can use a 'no connection' icon | 22:51 |
| Wizzup | general_presence_offline will do | 22:56 |
| sicelo | Wizzup: wifi connection working better now - seems bug fixed. gsm internet still won't connect | 22:57 |
| Wizzup | sicelo: yeah, didn't work on it | 23:01 |
| Wizzup | (gsm) | 23:01 |
| Wizzup | freemangordon: would it be a problem to link libconnui in a icd2 provider? | 23:02 |
| Wizzup | I want to use it's gconf IAP config read stuff | 23:02 |
| Wizzup | freemangordon: in particular iap_settings_get_gconf_value | 23:02 |
| sicelo | i don't know if it was mentioned, regarding the gsm issue, that it's not possible to set APN now, as clicking Next after the connection name dialog goes nowhere | 23:04 |
| bencoh | alright, the good news is that the switcher works properly on droid4. but it looks like it hardly has any noticeable effect on battery use | 23:05 |
| Wizzup | bencoh: there are bursts every now and then | 23:06 |
| Wizzup | there should be a small effect | 23:06 |
| sicelo | i don't recall that it had that much noticeable effect on N900 too :) | 23:06 |
| bencoh | Wizzup: even with wifi off? well, glad I ported it then :) | 23:06 |
| bencoh | (I mean, disconnected*) | 23:06 |
| Wizzup | bencoh: yes | 23:06 |
| Wizzup | no | 23:06 |
| Wizzup | not with wifi off | 23:06 |
| Wizzup | sorry | 23:06 |
| Wizzup | with the interface disabled I think it's the same | 23:07 |
| Wizzup | cool that it works | 23:07 |
| bencoh | oh and, serial power management is great :) | 23:08 |
| Wizzup | yup, just something to be aware off when pasting | 23:09 |
| Wizzup | (since you lose the first char) | 23:09 |
| bencoh | :) | 23:09 |
| Wizzup | sicelo: thanks for testing wlan fixes btws | 23:09 |
| Wizzup | s/btws/btw/ | 23:10 |
| bencoh | should I assume ifconfig is availabel on leste? (I guess no, but ...) | 23:11 |
| sicelo | it is available | 23:11 |
| Wizzup | for the applet? | 23:11 |
| sicelo | Wizzup: cool | 23:11 |
| bencoh | Wizzup: yeah | 23:11 |
| bencoh | that tool has been obsolete for a decade :] | 23:12 |
| Wizzup | bencoh: is it written in C? | 23:12 |
| bencoh | Wizzup: part of it is a script | 23:12 |
| Wizzup | I mean the applet | 23:12 |
| Wizzup | oh, ok | 23:12 |
| Wizzup | because: https://stackoverflow.com/questions/5858655/linux-programmatically-up-down-an-interface-kernel | 23:12 |
| sicelo | bencoh: but i switched to `ip` for the widgets i ported (yes @ obsolescence, but people still use it, and i guess for script compatibility) | 23:12 |
| Wizzup | but yes, you can use ifconfig, just depend on it in debian/control | 23:12 |
| Wizzup | (net-tools) | 23:13 |
| bencoh | Wizzup: we need to sudo in the middle anyway | 23:13 |
| Wizzup | keep in mind it might not be $PATH of user | 23:13 |
| bencoh | Wizzup: unless I missed something | 23:13 |
| sicelo | s/script/old scripts/ | 23:13 |
| bencoh | (and it already does it) | 23:13 |
| sicelo | you don't need sudo if you specify full path, /sbin/ifconfig | 23:13 |
| bencoh | uh? | 23:14 |
| Wizzup | he might need sudo for something else, like actually disabling the interface :P | 23:14 |
| sicelo | oh, sorry. you're changing iface state :) | 23:14 |
| bencoh | :) | 23:14 |
| Wizzup | sicelo: if I have time tomorrow I'll try to look at the gprs connection properly waiting for state change | 23:14 |
| Wizzup | atm I'm rather happy I managed to mostly untangle this connui stuff | 23:15 |
| sicelo | bencoh: i still recommend iproute2 stuff though :) | 23:16 |
| lel | MerlijnWajer opened a pull request: https://github.com/maemo-leste/connui-internet/pull/2 (WIP: add providers tab to advanced iap settings) | 23:30 |
| parazyd | Wizzup: Awesome work <3 | 23:31 |
| Wizzup | you're welcome | 23:34 |
| parazyd | :) | 23:36 |
| lel | MerlijnWajer closed an issue: https://github.com/maemo-leste/bugtracker/issues/532 (Look at initial (stub) icd2 'provider') | 23:38 |
| parazyd | I'll integrate this with my Tor code on monday | 23:38 |
| parazyd | And then we can use that as a base for Wireguard and OpenVPN | 23:38 |
| parazyd | These two need more configuration options | 23:39 |
| parazyd | I need to think a bit on how to store it properly in gconf | 23:39 |
| Wizzup | yeah, let's start with one (tor) and review | 23:39 |
| parazyd | mhm | 23:39 |
| Wizzup | wrt gconf, we probably want the service_id to point to the config values | 23:39 |
| parazyd | Yeah | 23:40 |
| parazyd | Do you know if hashmaps are possible in gconf? | 23:40 |
| Wizzup | nah, probably not | 23:40 |
| parazyd | (Can research, but just wondering if you know an instant answer) | 23:40 |
| parazyd | ok | 23:40 |
| Wizzup | I mean, it depends on what you want to do | 23:40 |
| Wizzup | directories are essentially a hash map | 23:40 |
| parazyd | We want to support multiple configs | 23:41 |
| parazyd | Yeah, a dir is probably the solution | 23:41 |
| Wizzup | gconftool -R /system/osso/connectivity/srv_provider/DUMMY/configs/<config1> | 23:41 |
| parazyd | Yup | 23:42 |
| Wizzup | (just a guess) | 23:42 |
| parazyd | And that would be linked with some uuid or name | 23:42 |
| Wizzup | it could also be a path elsewhere, it could also be that configs is a dir with just names that point to other gconf hierarchy | 23:42 |
| parazyd | mhm | 23:42 |
| Wizzup | yeah or make config1 also a dir and stash it all in there | 23:42 |
| parazyd | I'll think about it because I also need to decide which values it should be | 23:42 |
| Wizzup | btw I kind of like the connui wizard setup now that I understand it | 23:42 |
| parazyd | For now I just have some port configs for Tor | 23:43 |
| parazyd | :) | 23:43 |
| parazyd | Yeah maybe I should use it | 23:43 |
| parazyd | Currently my code uses GtkAssistant | 23:43 |
| parazyd | But connui looks much nicer | 23:43 |
| Wizzup | https://github.com/maemo-leste/connui-dummy/blob/master/wizard/dummy.c#L63 + https://github.com/maemo-leste/connui-dummy/blob/master/wizard/dummy.c#L114 | 23:43 |
| Wizzup | maybe some of it relies on connui internals and it is harder in a separate cpa though | 23:44 |
| Wizzup | meant to link to this in particular https://github.com/maemo-leste/connui-dummy/blob/master/wizard/dummy.c#L128 | 23:44 |
| parazyd | Will check | 23:44 |
| Wizzup | going afk for a bit now | 23:44 |
| parazyd | I mean, we can port it later too | 23:44 |
| parazyd | GtkAssistant is also using "pages" | 23:44 |
| parazyd | ttyl | 23:45 |
| bencoh | is it just me, or there is no user-defined .xsession.d thing (only ~/.xsession, ~/.xsessionrc, or system-wide /etc/X11/Xsession.d)? | 23:58 |
| parazyd | We place everything in /etc | 23:58 |
| parazyd | There's also Xsession.post btw | 23:59 |
| bencoh | yeah, but what if user wants to run something at session start? | 23:59 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!