Search guix IRC channel logs

These are the channel logs matching your query lightdm

2020-12-20[10:35:45] <olivuser> I mean currently I am trying to configure mcron jobs, and I had been trying to replace GDM with lightdm. If any of such "one feats" fails, how do you proceed?
2020-12-01[23:14:32] <dannym> While we have perfectly good updates for both gdm, and lightdm
2020-10-06[16:32:50] <Zambonifofex> It seems lprndn was working on a LightDM service, but that seems to have stalled a couple months ago. It seems that it is in a “good enough” working state. Would anyone mind helping me with trying it out for myself? (I’m not too familiar with Scheme.)
2020-09-30[13:31:01] <mbakke> Brendan[m]2: lightdm by any chance? /me recalls a discussion about how to configure lightdm-gtk-greeter with the same service...
2020-09-04[07:47:31] <str1ngs> I guess we could go with lightdm?
2020-08-01[21:39:00] <GNUtoo> - systemctl start lightdm (or any other dm)
2020-08-01[21:39:56] <GNUtoo> So anything after that (like lightdm or a shell) can still load the blacklisted modules
2020-08-01[21:48:53] <GNUtoo> Note that lightdm and similar programs have the habit of loading modules for you
2020-08-01[21:49:03] <butterypancake> lightdm?
2020-08-01[21:50:59] <GNUtoo> oh ok, that's not a gpu, so lightdm shound't be an issue
2020-07-25[18:06:21] <nckx> Tirifto: I don't get it. I find answers on-line that suggest that the fix to reloading /etc/profile on XFCE is restarting the lightdm service, implying that it's in charge of loading it. Which would also be logical. /etc/profile is supposed to set session-wide variables, once, which is what we want.
2020-07-25[18:51:42] <Tirifto> nckx: Actually it looks like lightdm might be the cause.
2020-07-25[20:30:53] <nckx> Tirifto: I still don't get it (unsurprising since I use neither lightdm nor Arch): assuming Parabola is simply Arch+ideology, is <> wrong?
2020-07-25[20:31:23] <nckx> ‘By default, /etc/lightdm/Xsession is run. The script checks and sources /etc/profile …’
2020-06-18[17:23:36] <lprndn> rekado, bricewge1 : On the LightDM service, How dirty would it be to use a third servicewhich would expect extentions from lightdm and greeters just to merge everything..? (My brain is melting.)
2020-06-18[18:59:37] <lprndn> bricewge1: the service would be private. I'm not a big fan of the added complexity but it allows the user to define either a lightdm service, a greeter one or both and always get a working service... (does it?) I'm just exploring ideas really... I don't remember why but I ended up discarding most other possibilities (and this one too soon...)
2020-06-17[10:55:30] <lprndn> bricewge1: hey! looking at the lightdm service right now. I'm trying one last thing.
2020-06-17[11:09:57] <bricewge1> That lightdm service is a hard nut to crack
2020-06-17[11:11:14] <efraim> it should be possible, something like (if (not (null (lightdm-configuration-field field))) (extend-field-with-that-other-service) '())
2020-06-17[11:13:59] <lprndn> bricewge1: I try: One service for lightdm, one for each greeter. Seats are defined in the lightdm service only. Then we collect greeter-sessions from seats and extend necessary greeter-services to activate them.
2020-06-17[11:36:58] <efraim> so in my example above (not (null (lightdm-configuration-field field))) is the (test-statement)
2020-06-17[11:49:29] <lprndn> efraim: hum... ok so I think my problem is that the service configuration is no available in the extensions field scope (or does it?). Maybe I should make a procedure of lightdm-service-type but it's done nowhere else so I'm not sure it's ok...
2020-05-31[20:42:22] <lle-bout> hey, there's no lightdm service, how are we intended to use lightdm in GNU Guix? Or one just needs to contribute a service?
2020-05-31[20:43:50] <nckx> lle-bout:
2020-05-26[10:23:00] <lprndn> rekado: just to say that I'll probably try something on the lightdm service. (getting rid of the greeters field altogether)
2020-05-26[14:34:37] <lprndn> rekado: for the lightdm service, what do you think about adding not documented fields to greeter fields to set greeter-name and stuff necessary to avoid using (cond ...)? Or is it awkward programming practice?
2020-05-26[14:57:29] <lprndn> bricewge: Here I don't refer to any field we use for now. I meant "the name used in the greeter-session field of lightdm.conf". I'm exploring other possibilities.
2020-05-26[15:14:42] <bricewge> lprndn: I'm lost here, a 'lightdm-configuration-greeter-name' field does exist (at least in some revision of your patchset, but I don't find it on my branch...) and rekado's diff does contains a 'greeter-name' procedure that uses a 'cond' but he doesn't use it in its diff...
2020-05-26[15:28:13] <lprndn> to remove the `greeters field of the lightdm-service-type used in rekado's diff.
2020-05-26[17:16:56] <lprndn> rekado: I have news on the lightdm PATH issue you had. In fact lightDM doesn't need the greeter in its path but its own /bin, /sbin.
2020-05-26[18:59:54] <bricewge> lprndn: You said that "lightDM doesn't need the greeter in its path but its own /bin, /sbin." which I understand to be /gnu/store/...-lightdm-1.30.0/{,s}bin which is problematic in Guix since those paths will only contains lightdm's own binaries and not the greeter
2020-05-26[19:07:45] <bricewge> lprndn: Hum, RIcardo's patch correctly set greeters-directory put he got rid off lightdm-profile-service, so /run/current-system/profile/share/xgreeters is probably empty
2020-05-26[19:14:52] <lprndn> bricewge: haha no problem. :) Just to clarify, what I found is that lightdm needs to have its own binaries in its path to work. The greeters'ones aren't needed, probably because we hardcode their path in the greeter's .desktop file.
2020-05-25[14:41:24] <rekado> lprndn: hello! About lightdm: I’m currently stuck after I implemented my changes. lightdm fails to start now and I haven’t been able to debug it yet.
2020-05-25[14:47:42] <rekado> lprndn:
2020-05-25[20:16:16] <lprndn> rekado: I won't have time to explore more your lightdm service today. But I just found out that it's was probably a PATH issue. Adding back the profile service + environment variables of the shepherd service makes it work. I think it just doesn't find the greeter executable ;)
2020-05-25[20:20:23] <rekado> I’ll see if we can set PATH for the lightdm shepherd service without resorting to using the profile service.
2020-05-24[08:41:44] <rekado> I’m still neck-deep in Haskell / lightdm / documentation stuff at the moment :-/
2020-05-23[20:24:03] <rekado_> bricewge: BTW I thought I finished my work on lightdm, but I can’t get it to work in a VM since my changes.
2020-05-21[00:00:40] <rekado> hmm, I think I have to give up on trying to make the lightdm service “nicer”
2020-05-21[00:02:10] <rekado> I guess we could make lightdm-service-type fail right away when it hasn’t been extended with a greeter
2020-05-21[00:16:17] <bricewge> rekado: lprndn explicitly wanted for lightdm-service-type to work without a greeter to be more straight forward for newcomers
2020-05-21[11:20:59] <lprndn> rekado_: I answered your email about the lightdm service. ;) I can try to build something and send new patches if you want. Maybe not today but soon.
2020-05-21[11:57:24] <lprndn> First, I suppose you mean lightdm-gtk-greeter-service-type, right? Also, It should only override seats that are defined inside its own service or did I miss something?
2020-05-21[12:26:54] <rekado_> lprndn: no, I did mean lightdm-service-type. I’m talking about the extensions the lightdm-gtk-greeter-service-type provides.
2020-05-21[12:27:53] <rekado_> lprndn: having a greeter override the seat configurations that a user may have specified for lightdm-service-type seems wrong.
2020-05-21[12:28:13] <rekado_> say I want to have one seat with lightdm-gtk-greeter and another with lightdm-mini-greeter
2020-05-21[12:28:41] <rekado_> adding lightdm-gtk-greeter-service-type to the list of services would override all my seat configurations and force the use of lightdm-gtk-greeter for all of them.
2020-05-21[12:29:21] <rekado_> the seat configuration comes from lightdm-service-type, the “top level”. We shouldn’t mess with it downstream.
2020-05-21[12:30:25] <rekado_> lightdm-service-type could take an arbitrary list of configuration objects, but they all have a different type so we can’t do anything with their values
2020-05-21[12:31:56] <lprndn> rekado_: can you tell where lightdm-service-type overrides greeter-session? It was not intentional, hence my poor understanding...
2020-05-21[12:32:23] <rekado_> lightdm-service-type does not override anything
2020-05-21[12:32:43] <rekado_> it has a “seats” field that takes a list of lightdm-seat-configuration objects
2020-05-21[12:33:20] <rekado_> (the default is “lightdm-gtk-greeter”, but it doesn’t have to be this way)
2020-05-21[12:34:50] <rekado_> the lightdm-gtk-greeter-lightdm-service procedure takes the seats from the “config” value and replaces them with a new seat configuration where the “greeter-session” field is overridden with the string "lightdm-gtk-greeter".
2020-05-21[12:35:23] <rekado_> that procedure is used by lightdm-gtk-greeter-service-type as an extension to the lightdm-service-type
2020-05-21[12:36:15] <rekado_> this means that whatever seat configurations lightdm-service-type contains will be changed to use the greeter-session “lightdm-gtk-greeter”
2020-05-21[12:44:46] <bricewge> rekado_: FWIU it's not the case, the procedure 'lightdm-gtk-greeter-lightdm-service' which returns a list of seat to extend 'lightdm-service-type' only override the 'greeter-session' field for the seats that this greeter contains.
2020-05-21[12:44:51] <lprndn> rekado_: (don't get me wrong I agree with you, I just miss something...) I thought using extension would mean lightdm-gtk-greeter-service would just pass its own (overriden) seats field to lightdm-service-type. But if I understeand correctly, it gets the whole list of seats (it's own + those defined in lightdm-service-type or nother greeter service) and override them before passing them back to lightdm-service-type, is that right?
2020-05-21[12:45:30] <bricewge> rekado_: In other words it won't override seats in other greeter. The procedure could do without overriding of 'greeter-session' since it seems to only do it to avoid a user misconfiguring lightdm-gtk-greeter seats with an other greeter.
2020-05-21[12:47:32] <rekado_> isn’t that all terribly confusing? To have seats in lightdm-service-type and in the greeters? And then also to have “greeter-session”?
2020-05-21[12:47:32] <bricewge> lprndn, rekado_: Regarding XDG_CONFIG_DIRS, I recall that lightdm-gtk-greeter does respect it but other greeters may not.
2020-05-21[12:54:59] <lprndn> rekado_, bricewge: To me, our main problem might just a UI one. Do we want to have greeters defined inside the lightdm service or not? I think we have solutions for both (with pros and cons). But I might forget things...
2020-05-21[12:58:13] <rekado_> and then it needs to make lightdm-service-type arrange for the config file to be found, e.g. by setting XDG_CONFIG_DIRS
2020-05-21[12:59:16] <rekado_> if there’s nothing in common then I don’t see how lightdm-service-type could do any such setup work *without* the use of service extensions.
2020-05-21[13:11:39] <lprndn> rekado_, bricewge: FYI, greeters "often" use /etc/lightdm/... for their configuration files. But for example, I think elementary-greeter uses GSettings... in this case we might just give up on its configuration all together. So there are ways.
2020-05-21[13:25:06] <lprndn> we could pass greeters' configuration as a list of records in a greeters field. Each record would probably be more or less the same as the current implementation. we dispath themwith (case ) or something to specific procedures outputing a list composable with the list of service-extension of lightdm-service-type. compose them. magic happens.
2020-05-21[13:27:51] <lprndn> rekado_, bricewge : Also, reminder for thoughts. LightDM should be able to work without greeter (autologin).
2020-05-21[14:32:07] <rekado_> bricewge: I’m working on the greeter-aware, cond-augmented lightdm-service-type now
2020-05-21[15:03:06] <bricewge> rekado_: So no greeters service-type anymore, instead just a big lightdm-service that grows with each new greeters that gets added?
2020-05-21[15:20:38] <bricewge> rekado_: How would the interface look like for lightdm-service-type with your work?
2020-05-20[17:48:35] <rekado> oh, but first: lightdm service!
2020-05-19[14:45:12] <lprndn> Hey rekado! any news for lightdm? I can take on some work to ease your burden if you need to.
2020-05-19[14:47:03] <rekado_> lprndn: I’d like to finish replacing the lightdm-gtk-greeter string with the actual package
2020-05-17[13:49:05] <bricewge> lprndn: The screenshot in looks a lot like the recent issue with fonts is lightdm. WDYT?
2020-05-17[13:52:00] <bricewge> Before that issue with lightdm fonts, font-gnu-freefont wasn't installed in my system but the issue wasn't present
2020-05-17[14:01:41] <bricewge> mbakke: Thank you! It makes sense know. Yestday lfam said such issues was pango related, but I didn't understood why: I couldn't find pango in lightdm-gtk-greeter's dependency graph
2020-05-17[14:09:20] <bricewge> './pre-inst-env guix graph lightdm-gtk-greeter' =>
2020-05-16[21:51:36] <bricewge> alextee: Same issue with lightdm
2020-05-16[21:56:36] <bricewge> alextee: I mean I have the exact same issue with lightdm-gtk-greeter, lprndn reproduced it and opened that issue.
2020-05-13[10:28:48] <bricewge> Also since core-update lightdm as some issue with fonts, all character are replaced with boxes.
2020-05-13[10:43:26] <lprndn> bricewge: also it needs a second patch you can find in the lightdm patch serie. I shamefully forgot to add an extension to polkit...
2020-05-13[10:53:20] <rekado> I’m still working on lightdm, by the way
2020-05-13[14:41:55] <lprndn> bricewge: On the lightdm's font issue. Adding font-dejavu works but not font-gnu-freefont... I don't know what to think about it...
2020-05-13[14:52:31] <bricewge> I glimpsed over conversation about font issue since core-updates merging so lightdm is probably not alone with such issues
2020-05-13[16:12:49] <lprndn> bricewge: I tried disabling the fontconfig-file-system when debugging lightdm and it didn't work so I would go for the second one. Should I send a bug report?
2020-05-11[11:05:06] <rekado_> srandom: lightdm is coming soon
2020-05-11[11:05:54] <srandom> Will lightdm support starting .xsession or .xinitrc in the user directory?
2020-05-11[11:13:54] <rekado_> srandom: lightdm-configuration has a field sessions-directories, which takes a list of directories where to look for sessions’ .desktop files.
2020-05-11[11:44:35] <bricewge> srandom, rekado_ : Actually you can directly specify a xinitrc by using the field lightdm-seat-configuration-session-wrapper
2020-05-11[19:25:12] <lprndn> accountsservice looks in XDG_DATA_DIRS for dbus interfaces. It's used at least by lightdm. Currently, it doesn't find anything as this variable is not set. Should I just wrap accountsservice or are there better ways?
2020-05-08[22:14:12] * rekado_ still works on the lightdm service review
2020-05-06[11:15:29] <rekado_> lprndn: re your LightDM service: there are a few things that I’d like to see comments for, e.g. the removal of Python and the addition of the lightdm-disable-python-tests.patch
2020-05-06[11:23:58] <rekado_> in the wonderful documention additions I see ‘lightDM’ and ‘LightDM’; better to be consistent
2020-05-06[11:26:10] <rekado_> the documentation for ‘lightdm-gtk-greeter-service-type’ should wrap ‘lightdm-gtk-greeter’ in @code{}
2020-05-06[11:27:07] <rekado_> same for ‘ligtdm-gtk-greeter’ (typo!) and ‘lightdm-gtk-greeter-configuration-file’ in the documentation of ‘lightdm-gtk-greeter-configuration’
2020-05-06[11:29:24] <rekado_> I’m not a fan of the many spaces in lightdm-seat-configuration->list; I think we could use ‘format’ with a format string that does padding for us.
2020-05-06[16:08:51] <lprndn> rekado: sent a new set of patches for the lightdm services if you happen to have some more time. :)
2020-05-06[16:10:46] <lprndn> I didn't touch the lightdm-seat-configuration->list procedure nor the format thing as I'm not really sure that I understood everything.
2020-05-05[15:45:26] <lprndn> Is there any maintainer with some time and motivation on their hands to review #35305 (lightdm service)?