akossh has quit [Ping timeout: 264 seconds]
<joerg> s/ check what you're missing/ check IF you're missing anything/
nmdv has joined #maemo-leste
nmdv has quit [Ping timeout: 255 seconds]
joerg has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
joerg has joined #maemo-leste
rafael2k_ has joined #maemo-leste
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 248 seconds]
<freemangordon> uvos__: at least in the VM the issue is fixed
<freemangordon> nela: please try to upgrade when you have a chance
mro has joined #maemo-leste
uvos__ has quit [Ping timeout: 248 seconds]
mro has quit [Quit: Leaving...]
maemish_ has joined #maemo-leste
uvos has joined #maemo-leste
<uvos> freemangordon: great
Twig has joined #maemo-leste
<Wizzup> uvos: ping
<Wizzup> uvos: fmg and I planned to do elogind work today, there is the summary of where you are at in the logs ~1-2 days ago
<Wizzup> where can we find that work? I know there are packges I built for -experimental
<Wizzup> iirc there were two approaches, one is just having elogind run xsession
<Wizzup> the other is to port things to more elogind-specific startup things
<uvos> you install those 2 packages, h-s starts xsession scripts. but you have to remove all the init scripts that eventualy depend on the xsession one
<uvos> theres nothing to useing elogind besides createing a session with pam_open_session
<uvos> this autologin dose for you
<uvos> the problem is that starting af-services breaks everything pretty mutch, elogind becomes unresponsive and you cant log out etc
<uvos> educated guess is that because af-services joins user and roots session dbus bus, and elogind works via dbus, elogind gets very confused by the broken session cookies
<freemangordon> uvos: what does this mean - joins session?
<freemangordon> *sessions
<freemangordon> it just starts user dbus session (iirc) and export the path in /tmp file
<uvos> on leste the session bus is seemingly the same no matter if you are root or user
<uvos> this is how mce can modify users gconf keys for instance
<freemangordon> umm, not sure, lemme check
<uvos> this seams very broken as it exposes all of roots interfaces to user
<freemangordon> no
<freemangordon> sec
<freemangordon> see https://pastebin.com/LWHhY5Xf
<uvos> so?
<freemangordon> ah, you mean there is no separate session bus for root?
<uvos> yes
<uvos> and root users of the session bus end up on users bus
<freemangordon> but, isn;t root supported to work on system bus?
<uvos> no
<freemangordon> ok
<uvos> the system bus is global yes
<uvos> but root should have its own bus
<freemangordon> I see
<freemangordon> so, besides mce, what else is accessing user session bus?
<uvos> anything that needs gconf
<uvos> and is root
<uvos> nothing uses it directly afaik
<uvos> (mce dosent)
<freemangordon> I see
<freemangordon> but then again, I think back in fremantle days this was not broken
<uvos> this is also what breaks gsettings
<freemangordon> because gconf was not using dbus, adaik
<freemangordon> *afaik
<uvos> since gsettings will use dbus to send signals to write to the store
<uvos> but will read directly
<freemangordon> ok, so, to sum it up - this seems the same or similar issue we have with gconf in general, no?
<uvos> this means that root gsettings clients on leste read from roots gsettings but write to users gesettings
<Wizzup> as I understand it, and you might be at this point already, is that a certain dbus user sesssion is forced for 'user' user and root on leste
<uvos> wich is quite problematic
<freemangordon> maybe it is time to get back to the drawing board and decide what to replace gconf with
<Wizzup> which elogind disallows
<freemangordon> maybe not 'disallows' but rather 'never tested and not working'
<Wizzup> I really hope we can separate gsettings/gconf and elogind
<Wizzup> freemangordon: no, probably very explicitly disallows
<freemangordon> right, in the context of systemd tracking user processes
<uvos> it also feals like a huge security risk to me
<Wizzup> ever since I have elogind on my laptop many things are all weird
<uvos> imo
<freemangordon> uvos: kinda agree
<Wizzup> what, because root can do what user does?
<freemangordon> though rott is allowed to do many things anyways
<freemangordon> *root
<Wizzup> we might want to check what actually blocks things
<freemangordon> right
<Wizzup> since currently we have uvos' educated guess
<freemangordon> I will install elogind in my vm
<Wizzup> in any case we will probably want to change af-services to use the dbus set up by elogind
<Wizzup> so no longer should it make its own thing in /tmp
<Wizzup> the path should be predictable given a username, too
<Wizzup> so that way root could just access it all the same
<Wizzup> if that makes sense
<freemangordon> umm...
<freemangordon> IIUC, this will allow 2 users to log in, no?
<Wizzup> huh?
<freemangordon> how is root supposed to know which exactly user to use dbus of?
<Wizzup> well, it's 'user'
<uvos> witch session
<freemangordon> mhm
<Wizzup> do you mean user vs system dbus?
<freemangordon> this is simply not meant to be used on mobile IMO
<freemangordon> if use 'user' have more than one session
<freemangordon> is that allowed?
<freemangordon> *user 'user'
<Wizzup> I am not sure if I follow why this matters
<uvos> you should be able to restict user to one session via pam
<uvos> not sure if has side effects
<uvos> ssh maybe
<Wizzup> yes, ssh for sure
<freemangordon> ssh should not start its own dbus, no?
<Wizzup> I don't think so
<freemangordon> that's why run-standalone.sh
<Wizzup> I don't think that if we use elogind we will have trouble with dbus
<Wizzup> the only thing we should fix is whatever overrides the session for root to be the user sesssion
<Wizzup> that needs updating
<Wizzup> (just my educated guess anyway)
<freemangordon> but that, how is root going to access user's gconf settings?
<uvos> or we kcik the can down the road
<uvos> and just have elgoind installed
<freemangordon> not time now
<freemangordon> ah
<uvos> and try to figure out how to disable it
<freemangordon> yes, I will do that in few minutes
<uvos> so it dosent interfeer
<freemangordon> just want to have some background
<Wizzup> the issue here is I think that it conflicts with ck and the other stuff
<Wizzup> ok
<freemangordon> ck?
<Wizzup> ConsoleKit
<freemangordon> it replaces it actually
<freemangordon> so, going to remove hildon-meta and install elogind
<freemangordon> do you want me to create some shared ssh session for you to watch?
<freemangordon> or jit.si meeting?
<Wizzup> that's fine, in 15 mins or so if you can wait
<freemangordon> sure
<Wizzup> ok
<Wizzup> brb then
<freemangordon> I will create jit.si meeting and will wait for both of you to join
<freemangordon> uvos: ^^^
<freemangordon> brb lunch
druk13 has joined #maemo-leste
druk13 has quit [Remote host closed the connection]
<Wizzup> freemangordon: i'm back, but will make a coffee and wait for you to return :D
<freemangordon> I am back as well
<Wizzup> ok
<Wizzup> 2 mins and I will join
<freemangordon> so, I made a snapshot of the vm and installed elogind
* Wizzup joins
<freemangordon> do you see VM screen?
<Wizzup> yes
<freemangordon> ok
<freemangordon> ok, seems this is what uvos is talking about
<freemangordon> but it is not logind that nags IIUC
<freemangordon> *hangs
<Wizzup> what hangs?
<freemangordon> it was sitting on "starting dbus"
<Wizzup> for me hangs = no progress
<freemangordon> right
<freemangordon> it progressed while I was swithing between windows
<freemangordon> lemme open ssh session
Twig has quit [Ping timeout: 248 seconds]
<freemangordon> what now?
<freemangordon> we have both h-d and elogind running
<Wizzup> I missed if you installed the pkgs from extras
<freemangordon> I did not
<Wizzup> is elogind running, or just installed?
<freemangordon> I just installed modified hildon-base that does not conflict with elogind
<freemangordon> see what I share on jitsi
<Wizzup> yeah, I see
<freemangordon> to me elogind seems running
<Wizzup> ps xua | grep logind
<freemangordon> and we still have the same dbus sessions
<Wizzup> hmm
<freemangordon> what now?
<Wizzup> type 'loginctl'
<Wizzup> well, this -seems- fine
<freemangordon> I mean - what issues do we expect
<freemangordon> lemme try to reboot
<Wizzup> black screen, no h-d
<freemangordon> hmm?
<Wizzup> that's the issue I experienced when I installed elogind
<Wizzup> (arguably a bit ago now)
<freemangordon> lemme poweroff first
<Wizzup> ok
<freemangordon> seems I cannot open power button meny
<freemangordon> *menu
<Wizzup> that's probably dbus related
<Wizzup> you can check /proc/<pid>/environ | grep -a DBUS
<Wizzup> to see what certain programs run as
<freemangordon> it powered down
<Wizzup> ok
<freemangordon> probably by elogind
<Wizzup> ah, yes.
<Wizzup> this is a config option
<freemangordon> lemme check how to disable elognd power button attach
<Wizzup> HandlePowerKey=ignore
<freemangordon> k
<Wizzup> under [Login]
<freemangordon> k
<Wizzup> I am kind of dumbfounded that it would just work though, I think this is because we have my patched X
<Wizzup> maybe we should check if X runs as root or not
akossh has joined #maemo-leste
<freemangordon> root
<Wizzup> right, that's nor normal under elogind
<Wizzup> so I wonder if we are started by elogind, or just /etc/init.d/xorg and /etc/init.d/xsession
<freemangordon> it is because our scripts start it
<Wizzup> I think the latter
<Wizzup> yes
<freemangordon> sure
<Wizzup> but I am not sure if it even counts as elogind session then
<freemangordon> but, do we *want* it started by logind *now*
<Wizzup> I agree
<uvos> sorry, im currently indisposed
<freemangordon> or, we want to release chimaera
<uvos> if you h
<Wizzup> I'm just surprised it 'works'
<Wizzup> uvos: np, this is kind of impromptu :)
<uvos> if you start x via autologin/no-dm it will run as user
<uvos> but you have to have it build with logind support
<Wizzup> freemangordon: maybe we shall try the same on a d4 and see what happens
<Wizzup> uvos: right, that is my understanding too, but that is only true of X in chimaera-experimental
<uvos> its true on beowulf too
<uvos> if you rebuild it
<uvos> unless thats what you mean
<freemangordon> ok, but lets set our goals, ok?
<Wizzup> right, what I mean is that I build a X without logind for normal chimaera and beowulf, but for chimaera-experimental I built one with logind
<freemangordon> what do we want?
<Wizzup> freemangordon: IMO, to release chimaera, regardless of elogind integration
<freemangordon> agree
Twig has joined #maemo-leste
<Wizzup> but it might make sense to see if the apps that 'require' elogind work
<Wizzup> was it gparted? or something?
<freemangordon> then, we want to remove conflict from hildon-base and provide elogind config that is appropriate with current setup
<freemangordon> lemme see
<Wizzup> for me the confusing part is that I am pretty sure I did this for chimaera-experimental (hildon-base changes)
<Wizzup> maybe the problem is that it was combined with my X changes, and this caused issues
<Wizzup> looks like gparted didn't start, I am assuming you're checking via ssh?
<Wizzup> oh I see it now
<freemangordon> yes, started from command line with sudo gparted
<Wizzup> what are the errors without sudo
<freemangordon> otherwise it fails with "Error executing command as another user: No authentication agent found."
<Wizzup> because it wants to become super user for some things
<Wizzup> right
<freemangordon> maybe we lack some other package
<Wizzup> either that or something is on the wrong bus
<Wizzup> can you inspect ps again and see if there is any other dbus
<Wizzup> I think I saw three
<Wizzup> this predates elogind
<freemangordon> yes, 3, but we have the same before logind as well
<Wizzup> hmm
<Wizzup> can you show them in terminal again?
<freemangordon> ops, sorry
<Wizzup> can also be vm terminal :D
<freemangordon> no idea
<freemangordon> but yeah
<freemangordon> could be ssh session
<Wizzup> no, I mean, you could type in vm terminal instead of share this one
<freemangordon> ah
<Wizzup> the third one seems like one we probably didn't want to start
<freemangordon> no, that one is ssh one I guess
<freemangordon> but that's normal
<freemangordon> lemme exit ssh session
<freemangordon> and check from xterm
<freemangordon> no idea what it is then
<Wizzup> pstree?
<freemangordon> but it is there even on beowulf
<Wizzup> oh, ok
<Wizzup> maybe some auto start
<freemangordon> mhm
<freemangordon> anywayt, this is not new
<Wizzup> ok
<freemangordon> IIRC it was there even back in ...umm...
<freemangordon> what was before beowulf? ascii?
<freemangordon> yeah, it iwas there in ascii as well
<Wizzup> ok
<freemangordon> see
<Wizzup> the only reason I asked about gparted was to check if our potential solution, just running elogind without any integration would cause unexpected issues
<freemangordon> the same on beowulf
<freemangordon> we lack auth agent
<freemangordon> this is not lack of integration IIUC
<Wizzup> I understand, but I am not sure even sure what this would be on gnome / kde, I assume it is just a way to become root
<Wizzup> like some gtk sudo thing
Blikje has joined #maemo-leste
<Wizzup> right, I see what you show, but I think polkit is replaced by elogind
<Wizzup> maybe gparted isn't the best test program in any case :)
<freemangordon> I understand what you mean, but, I don;t hink that shall stop us from releaseing chimaera
<Wizzup> yes
<freemangordon> you can always start with sudo
<Wizzup> shall I try it on my d4?
<freemangordon> lemme see power button config first
<Wizzup> right
<Wizzup> I saw the key was already set, did you set it earlier?
<freemangordon> hmm
<freemangordon> no
<freemangordon> this is the first boot with that key set
<freemangordon> hmm, maybe there was some oops
<freemangordon> now, why it waits there?
<Wizzup> is this any different from beowulf?
<freemangordon> lemme check
<freemangordon> hmm
<freemangordon> pressing power button does nothing
<Wizzup> might take a bit
<Wizzup> btw, maybe also worth checking if acpid is somehow pulled for your amd64 machine
<Wizzup> that can also mess with the power button
<freemangordon> see beowulf VM
<freemangordon> it started in 20 seconds
<Wizzup> ah
<Wizzup> maybe it's blocking on elogind starting or something?
<Wizzup> is elogind in any runlevel?
<freemangordon> will have to enable boot log to see what it waits for
<freemangordon> no idea
<freemangordon> now it does nothing as well
<Wizzup> what if you wait a bit longer
<freemangordon> it boots
<Wizzup> hmm
<freemangordon> but waits twice for about 20 seconds doing nothing
<Wizzup> smells like some dbus timeout
<freemangordon> anyway, lemme see if power button is active
<freemangordon> cool :)
<Wizzup> :)
<Wizzup> so why did it not work before?
<freemangordon> ok, what else?
<freemangordon> why do you ask me?
<Wizzup> hehe
<freemangordon> I never tried that :p
<freemangordon> well, I have a theory
<freemangordon> it works because it is *me* trying it :p
<freemangordon> this happens 95% of the time :D
<Wizzup> hehe
<Wizzup> maybe it is polkit then
<freemangordon> lemme install polkit
<freemangordon> do you know tha package name?
<Wizzup> apt-cache search polkit
<Wizzup> ?
<freemangordon> any idea what ukui-polkit is?
<Wizzup> no
maemish_ has quit [Quit: Connection closed for inactivity]
<Wizzup> I don't think ukui is relevant
<Wizzup> maybe try libpolkit-agent-1-0
<Wizzup> is it running?
<freemangordon> no, I will have to start it it seems
<freemangordon> hmmm
<Wizzup> compare dbus addrs maybe
<Wizzup> although you did run standalone for both
<Wizzup> maybe dbus-monitor or something?
<freemangordon> right
<Wizzup> I mean, this might not be very important
<freemangordon> yeah, but I want to spend few more minutes
<Wizzup> :)
<Wizzup> should the agent run as user? I mean, probably, but?
<Wizzup> and is polkitd running?
<freemangordon> polkitd?
<Wizzup> oh, it's not in bullseye
<Wizzup> nevermind then I guess
<Wizzup> I think the agent still needs a handler so that there is user interaction
<freemangordon> what do you mean?
<Wizzup> something that shows a dialog
<Wizzup> like gtk-pinentry or something (analogous?)
<Wizzup> freemangordon: ^
<freemangordon> how did you do that?
<uvos> gtk askpass implementation
<Wizzup> but this is not polkit, this is gksudo
<freemangordon> ok, but what is the package?
<Wizzup> right?
<uvos> Wizzup: no idea it just installed it and it worked in most places
<Wizzup> uvos: what about gparted?
<freemangordon> uvos: I am getting "Error executing command as another user: No authentication agent found." despite I installed ukui-polkit
<uvos> good question about pacakge
<freemangordon> ok, lets sum up
<freemangordon> the only issue with logind so far is power button handling, from leste POV
<uvos> ssh-askpass-fullscreen
<uvos> if you have that installed and remove the ssh all all thing it will pop up in ham etc
<Wizzup> freemangordon: I would like to check that it is also ok on phones
<uvos> ill check gparted in a bit
<freemangordon> I will do now
<uvos> *sudo all all thing
<uvos> not ssh
<uvos> ie nopasswd sudo
<freemangordon> "Could not open a connection to your authentication agent."
<freemangordon> this is from ssh-add
<freemangordon> in the meanwhile I have run-standalone.sh /usr/lib/x86_64-linux-gnu/ukui-polkit/polkit-ukui-authentication-agent-1 running
<Wizzup> freemangordon: ukui is a desktop environment like MATE and gnome
<freemangordon> right
<Wizzup> so maybe it needs it's own session before any of this will work
<freemangordon> ok
<Wizzup> are you doing as d4 elogind instal or shall I try it?
<freemangordon> anyway, shall we sum up and decide what next?
<freemangordon> yes, will do
<freemangordon> Wizzup: how to start virtual ssh or whatever?
<Wizzup> I don't understand the questionb
<freemangordon> anyway
<freemangordon> shared ssh session
<freemangordon> but not important
<freemangordon> Wizzup: see jitsi
<Wizzup> ok
<Wizzup> if you git fetch you can checkout experimental branch
<Wizzup> that works too
<Wizzup> does this device have ck installed?
<freemangordon> lemme check
<freemangordon> yes, removing
<freemangordon> that's it, right?
<freemangordon> Wizzup: ^^^
<freemangordon> shall I reboot and see
<Wizzup> yes
<Wizzup> I think so
maemish_ has joined #maemo-leste
<freemangordon> it is up and running
<Wizzup> ok
<Wizzup> shall I make a hildon-base for chimaera-devel?
<Wizzup> and maybe have it conflict with consolekit
<freemangordon> what about logind.conf?
<freemangordon> we have to divert. or, does it support run-parts/
<freemangordon> ?
<freemangordon> yes, it does
<freemangordon> so we need /etc/elogind/logind.conf.d/maemo-leste.conf
<Wizzup> right
<freemangordon> are you going to do it?
<freemangordon> BTW, why chimaera-devel?
<Wizzup> ok, but let's try it on your phone
<freemangordon> lets push that to chimaera and call it a day
<freemangordon> sure, NP
<Wizzup> -devel because then we don't accidentilly break the users who are already on chimaera
<Wizzup> we can move it over an hour later
<freemangordon> me and you I guess :D
<Wizzup> I think more
<Wizzup> rafael too for sure, maybe some users
<freemangordon> oh, ok
<Wizzup> so do we place the =ignore stuff there?
<Wizzup> (teh file)
<freemangordon> lemme test it gere
<freemangordon> /etc/elogind/logind.conf.d/maemo-leste.conf thingie
<freemangordon> *here
<Wizzup> I doubt that is can restart, but maybe :D
<Wizzup> try
<Wizzup> sudo loginctl reload
<Wizzup> freemangordon: ^
<freemangordon> ummm
<freemangordon> /etc/init.d/elogind restart
<freemangordon> but ok
<Wizzup> System Commands
<Wizzup> reload
<Wizzup> Reload the elogind configuration. While the daemon is being reloaded, all sockets elogind listens on behalf of user configuration will stay accessible.
<Wizzup> ok, feel free to try
<freemangordon> already did
<Wizzup> :)
<freemangordon> it works
<Wizzup> ok, maybe try restart
<Wizzup> I will prepare packages
<freemangordon> Wizzup: https://pastebin.com/hLRp8wJp
<freemangordon> so, once we have that released, I guess we can come-up with our own auth agent
<freemangordon> should;t be that hard.
<freemangordon> assuming we know how to properly register it
<Wizzup> right
nmdv has joined #maemo-leste
<freemangordon> blueman is running
<freemangordon> I guess I have to review uvos' PR about hildon-status-menu
<Wizzup> hildon-base is building
<Wizzup> now leste-config
<freemangordon> cool
<freemangordon> Wizzup: why the conflict with consolekit?
<maemish_> Following this at my friends summer cottage having my birthday party.
<freemangordon> cheers and happy birthday
* freemangordon is afk for 5 minutes
<Wizzup> I left the jitsi, I'm going to upgrade from -devel
<Wizzup> oh, -devel has the xorg with elgoind changed
<Wizzup> I will remove it from there and move it to experimental
<freemangordon> on my d4 I have 1:7.7+22
<Wizzup> E: This installation run will require temporarily removing the essential package hildon-base:armhf due to a Conflicts/Pre-Depends loop. This is often bad, but if you really want to do it, activate the APT::Force-LoopBreak option.
<Wizzup> E: Reverse conflicts early remove for package 'elogind:armhf' failed
<Wizzup> freemangordon: huh, xorg?
<freemangordon> yes
<Wizzup> it should be 1.20.11.1
<Wizzup> you might be checking some other version
<freemangordon> oh, wait
<freemangordon> this is xserver-xorg
<freemangordon> xserver-xorg-core is 2:1.20.11.1-1+m7
<Wizzup> right
<freemangordon> is this the "correct" version
<freemangordon> ?
<Wizzup> yes
<freemangordon> ok
<freemangordon> Wizzup: ok, why do we conflict consolekit and require alogind?
<freemangordon> *elogind
<Wizzup> why not?
<Wizzup> do we want users to 'choose' which they want?
<Wizzup> (that sounds funny out of context)
elastic_dog has quit [Quit: elastic_dog]
<freemangordon> right now we do not *require* any of those
<Wizzup> I think it is better to have a consistent base
<Wizzup> otherwise when we get reports we have to ask
<freemangordon> when we have proper integration, well, that's another story
<freemangordon> ok, we can only conflict with ck without requiring elogind
<Wizzup> that will still make it inconsistent
<freemangordon> so if one wants to install blueman or something, elogind will be installed
<Wizzup> I am fine if you want to go this way btw
<Wizzup> just wasn't my first thought
<freemangordon> as you wish, but I think this is more sane
<freemangordon> Wizzup: do you want me to do anything else now?
<freemangordon> uvos: could you help with investigating how to properly register auth agent when you have some spare time?
<Wizzup> ok, my droid dist-upgraded to devel also boots
<freemangordon> also, do we really need elogind for anything but that one?
<freemangordon> sorry my ignorance
<Wizzup> eventually if we can use it, it won't be bad for us I think
<Wizzup> like we can run X as user
<Wizzup> and streamline the dbus setup
<Wizzup> I don
<Wizzup> I don't know what -requires- it
<Wizzup> hm, my device just rebooted
<Wizzup> let's see if it's power button related
<Wizzup> very much like what happened to you
<freemangordon> maybe config didn;t make it
<Wizzup> mhm
<freemangordon> ugh
<freemangordon> got sms while powering off :)
<Wizzup> heh
<Wizzup> telephony is *hard* :)
<freemangordon> and that seems to hung the device
<Wizzup> for me the power button worked just once
<Wizzup> and now it's rebooting
<Wizzup> the config seemed to be there though
<freemangordon> hmm
<freemangordon> thats why I powered down
<Wizzup> hm?
<freemangordon> to see if after power-up the config will still work
<Wizzup> I don't follow
<freemangordon> after I created the run-parts file, I didn't reboot
<freemangordon> just restarted the service
<Wizzup> I rebooted after installing elogind
<Wizzup> first thing
<Wizzup> and it doesn't seem to work as expected yet
<freemangordon> and did sudo loginctl reload
<Wizzup> let me check the mainconfig file
<freemangordon> works here after reboot as well
<freemangordon> maybe you have a typo or missing new line or dunno
<Wizzup> and double press lock works too?
<freemangordon> yes
<freemangordon> single-press opens the menu
<freemangordon> it is as it should be
<freemangordon> *is it
<freemangordon> do you have \n at the end of /etc/elogind/logind.conf.d/maemo-leste.conf ?
<Wizzup> will check
<Wizzup> after that I have go to for a bit
<freemangordon> me too
<Wizzup> wait
<Wizzup> ok
<Wizzup> I messed up the config place
<freemangordon> hmm?
<freemangordon> ah :)
<Wizzup> ok
<freemangordon> check for the right placehttps://pastebin.com/hLRp8wJp
<Wizzup> yeah I did
<Wizzup> I will fix when I get back
<freemangordon> ok
<freemangordon> ttyl
akossh has quit [Ping timeout: 255 seconds]
akossh has joined #maemo-leste
pere has quit [Ping timeout: 255 seconds]
mro has joined #maemo-leste
mro has quit [Remote host closed the connection]
mro has joined #maemo-leste
k1r1t0 has joined #maemo-leste
mro has quit [Remote host closed the connection]
mro has joined #maemo-leste
mro has quit [Remote host closed the connection]
rafael2k_ has joined #maemo-leste
mro has joined #maemo-leste
mro has quit [Remote host closed the connection]
rafael2k__ has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 246 seconds]
pere has joined #maemo-leste
Blikje has quit [Remote host closed the connection]
rafael2k_ has joined #maemo-leste
rafael2k__ has quit [Ping timeout: 248 seconds]
Blikje has joined #maemo-leste
Twig has quit [Remote host closed the connection]
rafael2k__ has joined #maemo-leste
rafael2k_ has quit [Ping timeout: 248 seconds]
mro has joined #maemo-leste
<freemangordon> oh, ok, got it
<freemangordon> we have to run auth agent in the same session as gparted, for example
<buZz> uvos: what changed in the latest sphone release? could i already add new contacts from it now?
<buZz> i tried longclicking or maemo context menus , but nothing seemed to do anything
maemish_ has quit [Quit: Connection closed for inactivity]
xmn has quit [Ping timeout: 268 seconds]
maemish_ has joined #maemo-leste
<uvos> nothing changed
<uvos> the rebuild was nesscary because of the bug in ci
<buZz> ahh ok
<buZz> uvos: so just refactoring?
<buZz> i mean the rebuild was just of a refactoring build?
<uvos> no there was a bug in ci that caused beowulf to get the chimaera package
<uvos> i had to bump the version and rebuild the pacakge
<uvos> thats it
<uvos> there are no code changes
<buZz> ah ok
<freemangordon> uvos: why don;t we use autologin to start maemo-launcher process?
<uvos> why would we
<uvos> and we do
<uvos> in my system
<uvos> the vm
<freemangordon> because hildon-desktop is runs in maemo-launcer process env
<freemangordon> we don;t need tinydm, IIUC
<uvos> well tinydm is just a script that execs something in a .desktop file
<freemangordon> mhm
<uvos> in our case hildon-session
<freemangordon> but it relies on autologin
<uvos> we do want tinydm however
<uvos> yes i know
<uvos> hildon-session then runs scripts in a dir
<uvos> thats all
<freemangordon> and it is maemo-launcher that must be started as session parent
<buZz> Wizzup: what was that application called, which you use to hookup droid4 to car media system?
<uvos> i have a script there that starts the stuff in xsession
<uvos> as well as m-l and some other sutff
<freemangordon> ah
<uvos> this is best
<uvos> because this way hildon-sesson can be started by other dms too
<uvos> like gdm or whatever
<freemangordon> because what I did here:
<freemangordon> start Xorg as root (no session)
<freemangordon> start maemo-launcer via auto-login
<uvos> why would you want to do that?
<freemangordon> start hildon-desktop as normal
<uvos> start x as root instead of in the session (by the dm)
<freemangordon> because I don;t want to put even more packages just to fulfull some desktop-style boot/login process
<freemangordon> *pull
<uvos> but this is just worse
<freemangordon> why it is better to start X as user?
<uvos> for a 100 script? really?
<uvos> because its often the target of cves?
<uvos> not useing the desktop style session startup to spare 100 lines of bash is silly
<freemangordon> ok, ok
<uvos> the mapphones allso have a extreamly good case to want this system too
<uvos> since they transform into laptops
<freemangordon> am still trying to figure out how it is coupled
<uvos> where you might wan to start another session
<freemangordon> ok, so we start tinydm through autologin and the?
<freemangordon> *then?
<uvos> tinydm looks for a file in the xdg sessions dir
<uvos> there is a file that points to hildon-session
<uvos> then it starts x
<freemangordon> 'it'?
<uvos> and execs the hildon-sessoin script
<uvos> tinydm
<freemangordon> ok
<uvos> the hildon-session script runs the stuff in xsession
<freemangordon> and our hildon-session file start everything that is neeed
<uvos> all of this works fine
<uvos> if you avoid starting af-services
<freemangordon> so, maemo-launcher shall be started by session script as well, right?
<uvos> yes
<freemangordon> I still don;t see why af-services is an issue
<freemangordon> like, you explained...
<freemangordon> but I don;t get the problem
<uvos> its just a script that runs a .d
<freemangordon> sure
<freemangordon> I am talking about dbus user session
<freemangordon> anyway, I need to think about that for a while
<freemangordon> ttyl
nmdv has quit [Ping timeout: 255 seconds]
mro has quit [Remote host closed the connection]
mro has joined #maemo-leste
Twig has joined #maemo-leste
rafael2k__ has quit [Ping timeout: 264 seconds]
<buZz> 1668604753 <Wizzup> bt+mpris works in my car
<buZz> ah, was that it?
<buZz> i think so!
mro has quit [Remote host closed the connection]
<Wizzup> will catch up later tonight
mro has joined #maemo-leste
mro has quit [Quit: Leaving...]
maemish_ has quit [Quit: Connection closed for inactivity]
Twig has quit [Remote host closed the connection]
<joerg> you can tell buZz is a geek, from the timestamps they use ;-)
<joerg> hmm
<joerg> cmd: date -d @1668604753 >Wed Nov 16 14:19:13 CET 2022
<buZz> joerg: its from the irc.txt in topic ;)
maemish_ has joined #maemo-leste
akossh has quit [Ping timeout: 255 seconds]
pere has quit [Ping timeout: 246 seconds]