<uvos>
and SPHONE_STORE_TREE_MODEL_FILTER_SMS_MATCH_DIAL_ID SPHONE_STORE_TREE_MODEL_FILTER_SMS_MATCH_CONTACT_ID with something that matches on line_identifier and backend
<uvos>
*replace
pere has quit [Quit: Leaving]
pere has joined #maemo-leste
<Wizzup>
I don't know what dependencies the rtcom libraries have, but it might be entirely without hildon
<uvos>
Wizzup: sure that might be ok
<Wizzup>
seems to be just glib and sqlite3
<Wizzup>
and dbus
<Wizzup>
(not sure what for)
<Wizzup>
rtcom-eventlogger-plugins has rtcom-el-plugin-call and rtcom-el-plugin-sms
<uvos>
idealy id like to replace sphone-store-tree-model with something that just ingests a vector of CallProperties or MessageProperties to create the GtkTreeModel
<Wizzup>
to be clear I have not looked rtcom eventlogger in detail at all yet
<Wizzup>
but finding some interesting things
<Wizzup>
looks like there is some code there to populate a gtk tree view and such from the events as well
<Wizzup>
so I think rtcom-eventlogger-ui is mostly testing stuff, not things we'd need, and then rtcom-eventlogger and rtcom-eventlogger-plugins are ui and hildon agnostic
<Wizzup>
the rtcom-eventlogger-ui seems to do abook stuff as well
<Wizzup>
from a quick glance
<Wizzup>
uvos: so do you want me to look at the specific sql question you had now or do you want to investigate a more abstract model and/or rtcom-el?
<uvos>
im fine with either
<uvos>
rtcom looks ok to depend on i think
<uvos>
"please figure out how to make this work while not forceing sphone ui to be gtk and preferably just provide the ui with an array of sphone call/message structs"
<Wizzup>
ok so the rtcom dbus dependency is only for timezone changes
<uvos>
depending on dbus isent a big issue
<uvos>
sphone dose too
<Wizzup>
yeah, just wanted to make sure there wasn't some other service
<uvos>
for uinque
<uvos>
(and some of its modules also depend)
<Wizzup>
so my plan is to finish the news post by tonight or tomorrow at latest
<uvos>
ok
<uvos>
neat
<Wizzup>
and then work on audio (hopefully just a few days) and then this/rtcom/conversations
<uvos>
i would enjoy if you flip the last 2 things
<Wizzup>
ok
<Wizzup>
could probably do that
<uvos>
also gives me some time to look into plug detection again
<uvos>
ok need to run ttyl
<Wizzup>
ttyl
uvos has quit [Ping timeout: 260 seconds]
Danct12 has quit [Remote host closed the connection]
<Wizzup>
uvos: maybe grep logs in this channel for pacmd, I solved it for myself a whileago
<Wizzup>
parazyd: me neither, but the current maemo setup felt like a hack for me
<uvos>
Wizzup: grep pacmd in the logs dosent bring anything up
<Wizzup>
uvos: sec
<uvos>
except clort complaining about the same problem
<Wizzup>
ok
<Wizzup>
uvos: found it in my notes
<Wizzup>
Making pacmd work
<Wizzup>
Add this line to /etc/pulse/system.pa:
<Wizzup>
Then run as::
<Wizzup>
load-module module-cli-protocol-unix
<Wizzup>
=================
<Wizzup>
PULSE_RUNTIME_PATH=/var/run/pulse pacmd
<uvos>
side note
<uvos>
/etc/init.d/pulseaudio restart is broken
<uvos>
it starts pulse to soon (before the old instance exits)
<uvos>
Wizzup: yeah that works
<parazyd>
Maybe that can be exported in /etc/profile?
<uvos>
why dont we just start pulse as a session deamon...
<parazyd>
Wizzup: Should I port our DNS setup to resolvconf?
<parazyd>
I think I know how to do it
<parazyd>
Wizzup: But I'll need some help since I don't have a SIM ready so can't test both connections at the same time.
<Wizzup>
I think it's worth trying, yes
<parazyd>
ok
<Wizzup>
I don't think we can have both connections at the same time
<Wizzup>
what makes you think we can do that?
<uvos>
btw
<parazyd>
Wizzup: Oh, we can't?
<uvos>
i hate whoever decided to name a popular sound server jack
<Wizzup>
parazyd: I don't know any way to do it with the UI for sure
<parazyd>
Wizzup: It's possible on linux in general, so I thought so
<Wizzup>
uvos: poettering started pulse
<parazyd>
But true, icd doesn't allow this
<uvos>
i cant google jack about pulse and jacks without jack geing in the way
<Wizzup>
oh
<Wizzup>
you mean JACK
<uvos>
yeah
amk has quit [Read error: Connection reset by peer]
amk has joined #maemo-leste
inky_ has joined #maemo-leste
inky has quit [Ping timeout: 258 seconds]
_inky has quit [Ping timeout: 245 seconds]
<parazyd>
Wizzup: So, without changes, our current DNS setup works with resolvconf as well. It still seems to respect the 00leste_dns
<parazyd>
Wizzup: Can you tell me how you trigger the breakage?
<tmlind>
nice :)
<tmlind>
for the event code i mean
<Wizzup>
parazyd: when I start something in wg, and disable wg again, I have no working dns
<Wizzup>
all resolves fail
<Wizzup>
and this is because of dnsmasq trying to load servers from a non existent file
<parazyd>
My current /etc/resolv.conf is generated by resolvconf. Removing /var/run/resolv.conf.wlan0, and kill -SIGHUP `pidof dnsmasq` makes DNS not resolve. Reconnecting wifi brings back the wlan0 file and DNS continues working.
<parazyd>
Ok, I will try now with wireguard.
<Wizzup>
it should not try to load the wlan0 file ever since resolvconf exists
<Wizzup>
per the config/init script of dnsmasq
<parazyd>
Wizzup: It loads it, that's /etc/dnsmasq.d
<Wizzup>
I'll redo my research and explain, just a second
<parazyd>
We never change /etc/dnsmasq.conf
<uvos>
pa works :)
<Wizzup>
so in /etc/init.d/dnsmasq:
<Wizzup>
if [ ! "$RESOLV_CONF" ] &&
<Wizzup>
[ -x /sbin/resolvconf ]
<Wizzup>
[ "$IGNORE_RESOLVCONF" != "yes" ] &&
<Wizzup>
then
<Wizzup>
RESOLV_CONF=/run/dnsmasq/resolv.conf
<Wizzup>
fi
<uvos>
i have fully working plug deteion on my d4 :)
<Wizzup>
and then it starts with:
<Wizzup>
${RESOLV_CONF:+ -r $RESOLV_CONF} \
<uvos>
well except that the device dosent know if its booted with hp plugged or not
<Wizzup>
parazyd: so the command line args tell it to ignore other stuff and only read the ones from that file afaict
<Wizzup>
uvos: sweet, what else did you change
<uvos>
i was reporting the jack on the wrong dpms pin
<uvos>
(ie was kernel problem)
<Wizzup>
parazyd: this is worked around in /etc/default/dnsmasq by setting IGNORE_RESOLVCONF
<uvos>
and i had to add load-module module-switch-on-port-available
<Wizzup>
parazyd: this was the only way I was able to get dns
<uvos>
to system.pa
<Wizzup>
uvos: ok, in other settings ohm might do this
<parazyd>
Wizzup: Have you looked at /run/dnsmasq/resolv.conf ?
<parazyd>
For me it points to 127.0.0.1, and then dnsmasq continues with our .$interface resolv files.
<parazyd>
(This is a new image, with only resolvconf installed)
<parazyd>
I'll try now with wg and see what happens.
<Wizzup>
I do have the ignore option set, but I recall that file was empty before I set that option as well
<Wizzup>
which is why I disabled the resolvconf integration
<Wizzup>
It's not clear to me what writes that file
<Wizzup>
thanks for chasing this down
<parazyd>
Wizzup: Is wireguard-maemo the package that'll pull everything?
<parazyd>
(I forgot, sry)
<Wizzup>
I don't know, I'd do it through the application manager
<Wizzup>
(just to see what else might break/complain)
<parazyd>
Wizzup: Mind if I remove wireguard-dkms dep from libicd-wireguard?
<Wizzup>
I think we should remove it
<Wizzup>
so please do
<parazyd>
*nod*
<Wizzup>
(since we ship it in our kernels)
<parazyd>
Exactly
<Wizzup>
uvos: that's great though, does it also switch the UCM profile(s)?
<Wizzup>
(I suppose it shouldn't)
<uvos>
ofc it dose
<uvos>
well not profiles
<uvos>
it switches the profile outputs
<uvos>
as defined in ucm
_inky has joined #maemo-leste
<Wizzup>
ok
<uvos>
sphone swtiches profiles
<uvos>
for ringing and for volice call
<uvos>
its route-pulseaudio module dose this
<uvos>
you can unload it ofc
<Wizzup>
ok
<Wizzup>
well you asked me to postpone ohm stuff until some rtcom stuff, so I'm just going to try not to think about it too much since my head is full :p
<Wizzup>
that's really great though
<parazyd>
Wizzup:
<parazyd>
Setting up libicd-network-wireguard:armhf (0.1.2+2m7.3) ...
<parazyd>
bash: icd2-manage-modules: command not found
<parazyd>
That's a bug
<Wizzup>
hm let me see
<Wizzup>
what is this command a part of again :)
<parazyd>
I think the script you wrote to edit gconf arrays
<Wizzup>
yeah
<parazyd>
maemo-system-services
<Wizzup>
isn't that installed already?
<Wizzup>
or was it not pulled in as upgraded package?
<parazyd>
Let me see
<parazyd>
I think the latter indeed, I have about 75 devel updates
<uvos>
we should downmerge into stable too
<uvos>
for this newspost
<uvos>
(imo)
<uvos>
at least some safe stuff
<Wizzup>
yes
<Wizzup>
that's the plan
<parazyd>
Wizzup: After that:
<parazyd>
Setting up libicd-network-wireguard:armhf (0.1.2+2m7.3) ...
<parazyd>
ERROR: requested network_type GPRS does not exist in /system/osso/connectivity/network_type (['WLAN_ADHOC', 'WLAN_INFRA'])
<parazyd>
Wizzup: It shouldn't fail on this
<parazyd>
(Can also continue in private if you prefer and this is too noisy)
<Wizzup>
parazyd: this is also fixed, did you fully update?
<Wizzup>
oh, I see
<parazyd>
Yes just got the latest maemo-system-services-dev
<Wizzup>
I see, that's a problem
<Wizzup>
I guess one of the tricky parts here is that if we ignore the error, and if you then install gprs network modules after, the gprs module will not contain the proper entries
<Wizzup>
unless there is some trigger to re-run the script(s)
<parazyd>
Yes, but for example we can also run the scripts on hildon-connectivity-* metapackage (un)installs
<parazyd>
Maybe that's a good way to keep gconf up to date
<Wizzup>
what if someone installs gprs pkgs manually?
<Wizzup>
I don't know how triggers work, but they might be better here imho
<Wizzup>
as in, we can change many things without bumping the meta pkg
<parazyd>
An example hook we have is /etc/apt/apt.conf.d/142updatehildonmenu
<parazyd>
That's the only way I know to always trigger some binary on apt
<Wizzup>
run, and it runs every time
<parazyd>
Yep
<Wizzup>
I don't know what a good solution is here tbh
<Wizzup>
I can make the error non fatal for starters
<parazyd>
Me neither
<Wizzup>
but more needs to happen to make it not painful later on
<parazyd>
That'd be good, thanks
<Wizzup>
pushed to master on maemo-system-services
<parazyd>
ty
<parazyd>
Wizzup: Install goes through now, thanks. Note that it'd fail both on GPRS and DUMMY.
<parazyd>
Wizzup: So we probably want some general trigger for icd modules.
<Wizzup>
right
uvos has quit [Ping timeout: 245 seconds]
<parazyd>
Wizzup, uvos: Ping
<parazyd>
Do you have a wireguard applet setup already?
<Wizzup>
pong
<parazyd>
Hey
<parazyd>
Could you try reenabling resolvconf in /etc/default
<parazyd>
And then connect and disconnect wireguard
<parazyd>
See if DNS breaks then
<parazyd>
If so, then `touch /var/run/resolv.conf.*`. See if DNS is fixed.
<parazyd>
If not, `kill -SIGHUP `pidof dnsmasq``
<parazyd>
See if you can do DNS then.
<sicelo>
touch /var/run/resolv.conf.* will create that file. is that what you really want?
<parazyd>
No, but it'll work
<parazyd>
There should be a wlan0 or some
<Wizzup>
parazyd: yeah ok let me test
<Wizzup>
parazyd: so when I uncommented the line in /etc/default/dnsmasq, and restarted dnsmasq, I immediately have dns problems
<Wizzup>
I didn't even enable wireguard
<Wizzup>
do you want me to try the touch now?
<Wizzup>
(I was on gprs)
<Wizzup>
restarting dns on wifi also causes the error(s)
<Wizzup>
as in, try to connect over wifi, and then issue /etc/init.d/dnsmasq restart
<parazyd>
Reconnect icd
<Wizzup>
parazyd: as a workaround, or what?
<parazyd>
Reconnecting icd should make dns work
<parazyd>
And then try wireguard
<Wizzup>
can we make it so that restarting dnsmasq while connected to an AP doesn't make it fail?
<Wizzup>
the touch works for me
<parazyd>
I have to check @ restart
<parazyd>
But nothing should be restarting dnsmasq anyway
<parazyd>
In any case
<parazyd>
We then need to touch the files after wg-quick down
<parazyd>
You didn't have to sighup dnsmasq?
<Wizzup>
no
<Wizzup>
is there no more robust way?
<Wizzup>
as in, why does this even happen exactly?
<parazyd>
ok, great
<Wizzup>
so what's the real difference, why does this happen?
<parazyd>
This happens because resolvconf and wg-quick change the configuration upon enabling. So when after wg-quick down it returns, the files have to be triggered for dnsmasq to pick up the change.
<Wizzup>
there must be a way to make dnsmasq not that stupid
<parazyd>
This ia because our setup is watching those multiple resolv.conf.interface files
<parazyd>
I don't know another way
<parazyd>
And touching the files doesn't really seem bad tbh
<Wizzup>
I think it is pretty darn bad
<sicelo>
maybe we don't need dnsmasq anymore? the main reason it was there in fremantle was to help with caching, and not having to muck with /etc/resolv.conf for each connection
<Wizzup>
parazyd: so what file does wg-quick create
<sicelo>
if we are using resolvconf, i guess that negates its need
<Wizzup>
parazyd: shouldn't dnsmasq.conf have interface=lo ? I don't think we want it to be lo,wlan0
<parazyd>
We aren't changing dnsmasq.conf
<Wizzup>
same question :)
<parazyd>
I dunno, there's a dnsmasq.lo file
<parazyd>
And it points to localhost
<Wizzup>
yes, but the service is exposed over wireless
<Wizzup>
as I discovered a few weeks ago
<parazyd>
But our icd ipv4 setup makes the other files
<parazyd>
So if someone wants to change that setup, they're more than welcome
<parazyd>
I'm just trying to solve this with our current setup, and this is the solution I'm offering.
<Wizzup>
so the solution is to add C code to libicd-wireguard to touch a glob of files upon disconnect?
<parazyd>
I suppose
<Wizzup>
not going to happen
<Wizzup>
so why do you think the problem is gone when -r /run/dnsmasq/resolv.conf is not passed?
<Wizzup>
is it just an mtime thing?
<parazyd>
I think so, dnsmasq seems to watch those files we set in /etc/dnsmasq.d
<Wizzup>
as far as I can tell the problem is that /run/dnsmasq/resolv.conf is empty and it tries to use that
<parazyd>
That's not the problem, it can remain empty
<Wizzup>
if resolvconv would manage our iface addrs it should be fine, too
<Wizzup>
then it would never be empty
<Wizzup>
but that requires use to change our icd scripts to use resolvconf
<parazyd>
Actually I think it's empty even when wg-quick up
<parazyd>
Need to check
<Wizzup>
it's not
<Wizzup>
that was in my bug report iirc
<parazyd>
It should be possible to add a script in /etc/maemo-dhcp
<Wizzup>
so with wireguard on it contains 'nameserver 8.8.8.8'
<parazyd>
To so some kind of resolvconf setup
<parazyd>
aha
<parazyd>
Then maybe we can move the dns setup from the current script and split it into another
<parazyd>
And use resolvconf
<Wizzup>
yeah, and only use the resolvconf file in dnsmasq
<parazyd>
Yes
<Wizzup>
I wonder if it is also because we use udhcpcd
<Wizzup>
there seems to be a dhclient hook available