xubuntu | Does anyone know where the "modprobe" command went? | 00:54 |
---|---|---|
xubuntu | I'm a root user on a Devuan install but there is no modprobe command | 00:54 |
UsL | works for me™ | 00:56 |
UsL | which install? | 00:57 |
xubuntu | net install iso | 00:57 |
xubuntu | with XFCE installed | 00:57 |
xubuntu | also I have no "ifconfig" even though net-tools is installed | 00:57 |
xubuntu | beowulf | 00:58 |
UsL | huh.. | 00:58 |
xubuntu | i've seen this behavior when I'm not a root user where it seems to hide those commands | 00:58 |
xubuntu | but I'm root | 00:59 |
UsL | sure, but not from root as you say. | 00:59 |
xubuntu | i think I just got it | 01:00 |
fluffywolf | did you become root in some fashion that did not set the path? | 01:00 |
xubuntu | Apparently /sbin is not in the root $PATH variable | 01:01 |
debdog | root via "su", perhaps, xubuntu? | 01:01 |
debdog | right | 01:01 |
xubuntu | Yea I was root via su | 01:01 |
UsL | su - root | 01:01 |
xubuntu | su - root does it | 01:02 |
xubuntu | thanks! | 01:02 |
UsL | good. | 01:02 |
xubuntu | I'm coming from FreeBSD where just su works | 01:02 |
xubuntu | although I remember just su working on Linux a while back. | 01:02 |
UsL | I don't remember when that changed tbth | 01:03 |
debdog | I think there is an option to return to the old behaviour I just cannot remember how. but it ist should be on the forums somewhere | 01:03 |
xubuntu | strange. Anyways thanks for the help guys | 01:04 |
rwp | It was a change from linuxutils su to coreutils su (or was it the reverse) and it changed PATH setting. | 01:04 |
xubuntu | ahh i see | 01:04 |
debdog | there it is: https://files.devuan.org/devuan_beowulf/Release_notes.txt | 01:04 |
UsL | ah, right | 01:04 |
rwp | I have always used "su -" or "su - rwp" and so forth to load the target environment. Otherwise HOME doesn't change and damn aptitude will leave root owned files there! | 01:05 |
UsL | ah, that is why I have su - root/user as my aliases. | 01:06 |
UsL | now I remember | 01:06 |
rwp | It used to be the "login" package /bin/su and it is the "util-linux" package /bin/su now. | 01:07 |
UsL | I remember I thought it was logical to have smthng after su since it means susbtitute user. For what? ah, - root/user. Made more sense in my mind | 01:09 |
rwp | The choice of the "-" is because login shells always start with a "-" such as "-bash" and that tells the shell it is a login shell and should source the .profile file. | 01:10 |
UsL | ah, right | 01:10 |
rwp | And it doesn't matter about the rest of the name either. So "-su" could be a bash shell and since it starts with a "-" it tells bash to load the login profile. | 01:12 |
rwp | Of course these days the "-" confuses people and so they added "-l" as a more normal looking option to do the same thing. | 01:13 |
rwp | Being a traditionalist I use the traditional way myself with "su -" no "-l" for me. | 01:13 |
xubuntu | interestingly, If I do "sudo su" without the "-", its loads /sbin in the $PATH | 01:15 |
rwp | Introducing "sudo" to things introduces the rules "sudo" uses to do things. | 01:16 |
rwp | I am perfectly fine with "sudo su -" but just to note that "sudo -i" is the same as "su -" as far as the result and it only uses one set of rules and stacks one fewer processes. | 01:16 |
UsL | I disabled sudo since I didn't understand it quite and thought it was a security risk. | 01:16 |
fluffywolf | I've used "su -" since well before sudo existed. | 01:17 |
rwp | UsL, Humorously other people do the exact opposite for the exact same reason! :-) (I enable both.) | 01:17 |
UsL | hehe : ) | 01:17 |
rwp | I enable both, which is to say that neither are more risky than the other. | 01:17 |
fluffywolf | I think sudo is much riskier in a multi-user system where multiple people use it. | 01:18 |
UsL | wasn't there like a ten year old bug in sudo fixed fairly recently now that I came to think about it | 01:18 |
* UsL goes look | 01:18 | |
rwp | Both sudo and each of the su flavors have had a few bugs posted against them over the last decade. | 01:19 |
fluffywolf | sudo makes you think you can let people do some things but not other things, while in reality, letting people run anything more than "ping" as root is the same as giving them the root password. | 01:19 |
fluffywolf | it gives admins a false impression that they can grant limited admin access | 01:19 |
rwp | Ah... fluffywolf has hit the problem precisely. "sudo -i" is the same as "su -" so no problems swapping the use of those around. | 01:19 |
fluffywolf | while giving them the password to su makes the admin actually evaluate whether they really want someone to have full control of the system. | 01:19 |
rwp | But if one tries to limit commands and restrict them to a specific thing, and screw it up, then they allow users to escape to root with a privilege escalation. | 01:20 |
fluffywolf | for example, any program that is capable of writing a text file, if ran as root, can give the user root access. | 01:20 |
rwp | Yes. But see the "sudoedit" command and features for editing a root owned file as non-root. | 01:21 |
rwp | sudo can be used safely in that way but su has nothing equivalent. | 01:21 |
fluffywolf | even if it's some feature you didn't expect, like a command line option to change where the program save some log file. someone can easily abuse that to overwrite something with a crafted log entry and have root access. | 01:22 |
rwp | Yes. But that is one way of "screwing it up". So if one is trying to limit access then one must also limit access completely, by blocking arguments. | 01:22 |
fluffywolf | I don't believe it's possible to restrict sudo safely on linux. the security it pretends to offer needs to be implemented somewhere else. | 01:23 |
fluffywolf | so it gives admins a false sense of security. | 01:23 |
fluffywolf | and thus is more dangerous than su. :) | 01:23 |
rwp | I disagree that there is no way to use sudo to give limited access safely. One just needs to read the docs and follow the rules for it. | 01:24 |
fluffywolf | I'm sure you can come up with specific programs with specifically crafted sudo configs that aren't a risk. ping, like I already said. but in general, I'd say the vast majority of programs can be used to gain root access, often in ways most admins would never suspect. | 01:25 |
rwp | For example I allow non-root on some systems to stop, start, restart, the Apache web server. Doing that does not allow them root access. | 01:25 |
rwp | And apache so often gets wedged where it needs it. (Never seen Nginx wedged that way.) | 01:26 |
fluffywolf | I've never had to restart apache. lol | 01:26 |
unixman_home | I can't recall a time I had to restart Apache for anything but an update to Apache. | 01:27 |
fluffywolf | if they can run the apache binary directly, not just the /etc/init.d script, I'm sure they could get root from it. | 01:27 |
rwp | But mostly I use sudo in the simple way of "sudo -i" and it is certainly not less secure than "su -" in that case. | 01:27 |
fluffywolf | since it takes every config option on the command line, including dangerous ones. | 01:27 |
rwp | I do not allow random options on the command line. Just "service apache2 restart" and the others. No others are allowed. | 01:28 |
fluffywolf | ... service? eww. | 01:28 |
UsL | isn't a service? | 01:29 |
rwp | Oh look at the time! I need to run. I'll be back on again for rebuttals later. TTFN! (Why eww? service is the clean environment way to run init scripts. Are you using systemd? Here in #devuan??) | 01:29 |
unixman_home | I have a cow-orker who swears 'doas' is more secure than 'sudo'. :D | 01:29 |
fluffywolf | oh, wait, there's a non-evil service command too. | 01:29 |
fluffywolf | my bad. | 01:29 |
fluffywolf | I forgot someone made one that uses sysv scripts. heh. | 01:29 |
UsL | you had me stumped there for a second fluffywolf | 01:29 |
UsL | rwp see you later | 01:30 |
fluffywolf | I forgot it wasn't always pointed at systemctl. :) | 01:30 |
UsL | a what now? | 01:30 |
UsL | : ) | 01:30 |
UsL | I need to go for a while as well. Se you all later | 01:31 |
fluffywolf | of course, some form of watchdog cronjob might be an even better option. :P | 01:32 |
fluffywolf | cyas | 01:32 |
Xenguy | Strangely I always used 'su -' to become root, cos I thought if I didn't I wouldn't get the full root environment. It turns out that's the way it actually works now, so I just lucked out : -) | 02:11 |
fluffywolf | it's always been that way? | 02:12 |
fsmithred | yeah, that part has always been that way. | 02:12 |
Xenguy | Well I thought it was, but apparently people are saying I was wrong about that, for a time | 02:12 |
fsmithred | the change is if you just use su | 02:12 |
fsmithred | you don't get root's path | 02:12 |
Xenguy | But I thought it was always that way, but more recently people say that's not true | 02:13 |
Xenguy | So, dunno | 02:13 |
fsmithred | the old way, 'su' got you root's path but didn't change you to root's home. | 02:13 |
Xenguy | Ohhhh | 02:13 |
fsmithred | which is what I usually want | 02:13 |
Xenguy | I see, interesting | 02:14 |
fluffywolf | I could have sworn su with no - didn't get you root's path, or anything else - it just changed your uid. | 02:14 |
Xenguy | Well anyway, I have the muscle memory now, cos I always did it that way | 02:14 |
fsmithred | fluffywolf, I've seen it change at least a couple of times in the last 20 years. | 02:15 |
fluffywolf | maybe I missed it changing to where it worked, then. lol | 02:18 |
fluffywolf | since I don't remember any time you ever didn't use -, since you always wanted a login shell. | 02:18 |
fsmithred | ascii | 02:21 |
fsmithred | I guess it wasn't a login shell because you didn't cd | 02:21 |
* fluffywolf has been using su - for like 25 years. lol | 02:26 | |
onefang | Ah I knew there was a reason I don't use the service command. Just read the man page, the mere existence of a systemd unit means it takes precedence over init.d scripts, and there's still too much systemd cruft left laying around in Devuan. If there was away to switch that off, would be good. | 09:36 |
onefang | Apache was mentioned above. Yep, I got an apache2 systemd unit in one of the places the service command searches. | 09:37 |
oldmate | Hi, i just installed mate desktop on chimeara and when i try to poweroff it goes to the lightdm login screen and the power menu is all greyed out? I think i maybe missing something. In a terminal when i type "loginctl poweroff" a password prompt appears? | 14:13 |
oldmate | The power menu in lightdm is greyed out, not in mate desktop. | 14:13 |
oldmate | The iso is the latest netinstall from 23rd august | 14:14 |
oldmate | I didnt use tasksel to install mate desktop, i did it from tty when i installed the base and system utils only. | 14:16 |
gnarface | could be a missing package | 14:27 |
gnarface | permissions backend dependency library or such perhaps | 14:28 |
fsmithred | maybe policykit-1-gnome | 14:30 |
oldmate | id say so @gnarface im just at a loss what it could be. @fsmithred ill try that and report back later on. Thanks | 14:31 |
oldmate | policykit-1-gnome - that was it, thanks @fsmithred | 14:43 |
fsmithred | yw | 14:44 |
fsmithred | oldmate, I don't know the situation with mate in chimaera, but in earlier releases some people were using xfce-power-manager. Keep an eye out for issues. | 14:45 |
oldmate | okay will do. | 14:48 |
Guest56 | Hi! I have a problem with Thunar. For some reason it can't start without root. | 18:59 |
Guest56 | How can I check what causes the issue and how to fix it? | 19:00 |
Guest56 | After I tried to run it from the terminal, there was no response for a longer while, and after this "Failed to register: Timeout was reached" | 19:01 |
Guest56 | It started to fail like this after some package installation, and restart. | 19:02 |
Guest56 | It starts fine with root though. | 19:02 |
rwp | Guest56 has quit but to me that sounds like it was run by root and Thunar as root chown'd files in $HOME to root. | 19:39 |
rwp | I would "find ~ -user root -ls" to look for them and "sudo find ~ -user root -exec chown -v $USER: {} +" to fix them. | 19:41 |
Tenkawa | rwp: I was thinking that or possibly the user doesn't have the right /etc/group perms for the daemon | 19:49 |
Tenkawa | that would usually only happen though if someone had manually created the user and it didnt get added to the gvfs and other groups | 19:50 |
rwp | Whatever group permission the user has is okay as long as they use it consistently throughout the timeline. | 19:52 |
Tenkawa | policykit it is also something else that acts up on this from time to time for file managers | 19:53 |
rwp | But what user these days would have modified their group in /etc/group? Most newbies take some time to skill up to learning about UPG and other group things. | 19:53 |
rwp | Policykit! Well... Possible. But that usually affects devices. I am thinking that Thunar could no longer talk to communication sockets. | 19:54 |
Tenkawa | rwp: a lot of users start clicking things | 19:54 |
rwp | Yes. Sadly. And the new interface makes changes immediately without Apply/Ok and there is no Undo action. Sigh. | 19:55 |
Tenkawa | ack | 19:55 |
Tenkawa | did not hear about that | 19:55 |
* Tenkawa lives almost completely in cli on the Linux side | 19:56 | |
rwp | I should note here that having sudo to root interactions and root owned files has been such a problem for me that I have a crontab entry to notify me if any happen appear. So I can note them and fix them. | 20:06 |
Guest56 | Thanks for the help. I will try those commands(I checked in the chat archive). Also, since the installation, the sudo command didn't work, because "user is not in sudoers". Should it be like this, by default? | 21:55 |
fsmithred | Guest56, yes, if you created a root password during install, then user is not in sudo group. | 21:57 |
Guest56 | I tried "find ~ -user root -ls". This returned nothing. | 21:58 |
rwp | Guest56, If you haven't used sudo then the same result might have happened using "su" (without "su -") which keeps HOME set as before. | 21:58 |
Guest56 | Also, what is the use of "~" here? | 21:58 |
rwp | Guest56, Good! Then that is not the problem. And the problem is something different. | 21:59 |
rwp | The ~ character is expanded by the command line shell (bash?) to be $HOME your home directory, likely something like /home/rwp for example for me. | 21:59 |
rwp | You can see what it expands to by using "echo" to echo print out the command. Try this: echo find ~ -user root -ls | 22:00 |
Guest56 | fsmithred I think I created it back then. | 22:00 |
rwp | That will show the ~ expanded. Using ~ is a very typical shortcut and you will see it used everywhere. "ls -l ~/.profile" or whatever. | 22:00 |
Guest56 | rwp About su. I know. It is the only way for me to use thunar for now. | 22:01 |
rwp | Historical note: At one time the ~ character on keyboards was on the same key as the Home key. And that is why it has been used for that ever since. | 22:01 |
rwp | Guest56, I sympathize but I don't know what the problem might be. Don't know. But it's not right. | 22:02 |
Guest56 | Thanks! I understand now. What could cause the issue, then? | 22:02 |
rwp | If it were me I would create a new pristine user account as a test. Then reboot (to ensure all processes have exited) and log in as that new pristine user. Then see if it is happy or unhappy. | 22:02 |
rwp | If it works then the problem is definitely in the configuration files of the home directory. If not then the problem is in the system somehow. | 22:03 |
fsmithred | create a new user and see if that user can start thunar | 22:03 |
rwp | If it were me I would "su -" to jump to root with root's environment. Then "adduser testuser" answer the questions interactively. Then exit, exit, exit, reboot, log in as testuser. | 22:04 |
rwp | Okay to use any name you want for "testuser" which is just an arbitrary name. | 22:04 |
rwp | For me I might use "rwp2" or something. | 22:05 |
Guest56 | I just checked the /etc/group | 22:05 |
n4dir | if already root, you might just as well run "reboot" straight away. | 22:06 |
Guest56 | If there is no user name after the "daemon:x:1:", would that make a problem? | 22:06 |
rwp | No "daemon:x:1:" is okay. | 22:06 |
rwp | In /etc/passwd your account has two numbers. "rwp:x:1000:1000:Bob Proulx:/home/rwp:/bin/bash" for example for me. | 22:07 |
Guest56 | Right. What deamon would it be exactly in this cause? | 22:07 |
rwp | I am using uid 1000 and gid 1000. And that is the beginning and end of it. Then in /etc/group "rwp:x:1000:" defines a name for the gid. This follows the UPG User Private Group strategy. | 22:08 |
Guest56 | Cause all those are deamons, I guess, and just some have on the end user name. | 22:08 |
rwp | As far as what the problem is very sorry but I don't know. | 22:08 |
rwp | For the /etc/group entries that have a user appended to the end those get added to the user process at login time as *additional* groups. | 22:09 |
n4dir | what is the problem, in short words? | 22:10 |
rwp | Such as the "sudo" group we have been talking about. And possibly other groups. I always add myself to "adm" and "staff". Group adm gives read-only access to /var/log/* without needing root. | 22:10 |
fsmithred | n4dir, only root can start thunar | 22:11 |
rwp | n4dir, Previously Guest56 described that trying to run thunar "After I tried to run it from the terminal, there was no response for a longer while, and after this "Failed to register: Timeout was reached" | 22:11 |
rwp | But if "su" is used then thunar starts and runs as root. | 22:11 |
fsmithred | is this beowulf or chimaera? | 22:12 |
Guest56 | chimaera | 22:12 |
fsmithred | actually, it should not work in either of them | 22:12 |
n4dir | ok, i figured that, but then all the /etc/groups and other staff made me wonder. This way that way your "testuser" is sure what i'd do next too | 22:12 |
fsmithred | i.e. you should not be able to run thunar from a root terminal unless you changed something. | 22:12 |
fsmithred | something= root's PATH or an entry in /etc/default/su | 22:13 |
n4dir | like no display-manager, or did that change too? | 22:13 |
n4dir | sure the other way around is the usual problem, not the user not being able to | 22:13 |
fsmithred | Guest56, you said this started after installing some packages and rebooting. What packages? Look in /var/log/apt/history.log | 22:14 |
Guest56 | chimaera Why so? I always used this, when I needed to change something that needed the root permissions. It was easier that way. | 22:14 |
fsmithred | since beowulf/buster, they changed some things regarding su, and root can't run X apps. | 22:14 |
Guest56 | I have no internet for now too, because that installation. I tried to bring back working n-m. | 22:15 |
n4dir | nothing written in stone, but without a display-manager i can start the mate filemanager as root from terminal | 22:15 |
fsmithred | it's possible I'm wrong about that last point. | 22:15 |
Guest56 | Wait...Strange. It started to work again on its own. | 22:15 |
Guest56 | I mean, I can open thunar with the user account. | 22:16 |
n4dir | yee-haw ! | 22:16 |
Guest56 | But I couldn't before, and I have no idea why I can now. | 22:16 |
n4dir | you did reboot? or did it come out of nothing? | 22:16 |
rwp | Computers are like cats. Subtle and quick to anger. | 22:16 |
fsmithred | do you have a web browser open with a lot of tabs sucking up all your RAM? That'll slow things down. | 22:17 |
Guest56 | It was like this after a restart. I reboot again, and it was still like this. Then after I turned on it again later, as I tried that command for search, it again started to work. | 22:17 |
fsmithred | did you run the command that had 'chown' in it? | 22:18 |
rwp | Guest56, Hmm... It's not explained but perhaps it will remain unexplained. Unless you see the problem again. | 22:18 |
Guest56 | Just a moment before, as I clicked a thunar icon by a habit. | 22:18 |
Guest56 | I will ask again, if it happens. | 22:19 |
Guest56 | fsmithred I doubt about if it could be a ram issue. It could start from root, and it couldn't start from default user since the very session start. | 22:20 |
rwp | I would also look through /var/log/syslog and see if there are any clues or error messages recorded there. | 22:21 |
rwp | However there will be a lot of entries there for *everything* and not everything will be related to thunar. | 22:21 |
rwp | But hopefully perhaps something about thunar might be recorded there. | 22:21 |
Guest56 | fsmithred I did not, since "find ~ -user root -ls" returned nothing. | 22:23 |
Guest56 | So I didn't used that with chown. | 22:23 |
rwp | Guest56, I will offer jokingly that if you are comfortable on the command line that "ls" on the command line is enough! No need to ever run thunar. I don't. :-) | 22:23 |
n4dir | i assume the web result from that arch bug report were discussed about the thunar problem? someone mentions ~/.cache/... others mention other stuff, which is just voodoo to me | 22:23 |
Guest56 | rwp Right, just that it seems faster to navigate with a gui. :) | 22:24 |
n4dir | not for everyone, Guest56 :-) | 22:25 |
rwp | ykinmkbykiok! :-) | 22:25 |
Guest56 | But I need to write in the entire folder names, that are often lengthy, in order to go there. Isn't it? | 22:26 |
n4dir | Guest56: it usually autocompletes just fine. Depends on the details, of course. | 22:27 |
n4dir | on cli i don't really type a lot | 22:27 |
n4dir | really not trying to convince you. If you like file-managers, nothing wrong, as far it is me | 22:27 |
fsmithred | I do both, sometimes on the same desktop. | 22:28 |
rwp | Guest56, On the command line in bash one types in the first part of the name, then types TAB to have it auto-complete the rest. If it does not due to multiple selections possible then type TAB again and it will list the possibilities. Type in another character and hit TAB again to complete more. | 22:28 |
n4dir | and in addition there is the alternative history completion, set in /etc/inputrc . Also a time saver | 22:29 |
rwp | You say "it seems faster to navigate with a gui" but for me it is the opposite. Because I have to stop and move my hands over to the mouse, find the pointer on screen, then click on it. | 22:32 |
Guest56 | Ny batery run out. | 22:32 |
rwp | Guest56, Happy to hear your problem has mostly been resolved. Good luck! :-) | 22:32 |
Guest56 | I will check for the autocompletion, I guess. I didn't used such till now. | 22:33 |
Guest56 | Finding pointer on the screen is rather an instant thing to me. I guess it could be harder by default with a very high resolution. | 22:36 |
n4dir | Guest56: also a good one: !$, which is like the ~ from above, but for the last argument of the last command run (say i case it it is a long path). And all this is just the beginning. I only know what i need, and that is very little. - as said, imho nothing wrong with a filemanager, if one likes it | 22:36 |
Guest56 | Right, :) I used it because it was more intuitive, and I didn't find time to remember well use of the commands. | 22:40 |
Guest56 | Though, there is little of them just for navigation, I guess. | 22:40 |
Guest56 | I have other question. | 22:44 |
Guest56 | Why cannot I initialize some programs from root terminal? Like the "mousepad". I get the "Failed to initialize xfconf: The connection is closed" error. | 22:45 |
fsmithred | Guest56, that's because of the changes in su. It's possible to revert to the old way. | 22:46 |
Guest56 | How so? | 22:47 |
fsmithred | see 'man su'. Put 'ALWAYS_SET_PATH yes' in /etc/default/su | 22:47 |
fsmithred | you will have to create the file | 22:47 |
n4dir | then you can start X apps even if a display-manager is running? | 22:47 |
fsmithred | then when you become root with su you will have root's path, you will stay in the current directory, and you will be able to run X apps as root. | 22:48 |
fsmithred | yeah, I have a display manager. | 22:48 |
Tenkawa | I'm just catching up.. what about xhost/xaccess? isn't he still going to have to deal with that? | 22:48 |
fsmithred | nope | 22:48 |
n4dir | what a confusing situation. Let's change it every other day, so it gets even more confusing | 22:48 |
Guest56 | n4dir Yes. Why not to? | 22:49 |
n4dir | why would it bother anyone if i want to run an app as root? shesh. Developers | 22:49 |
fsmithred | I know that su got moved to a different package, but I've never seen an explanation of why they changed the behavior. | 22:50 |
Tenkawa | fsmithred: how is it getting around setuid root? | 22:50 |
Guest56 | I needed to do that to change the restricted files faster. | 22:50 |
Tenkawa | export DISPLAY=:0 | 22:50 |
Tenkawa | root@omen:~# xterm | 22:50 |
Tenkawa | No protocol specified | 22:50 |
fsmithred | Tenkawa, I'm not sure I understand the question. | 22:50 |
fsmithred | did you do anything to change the default behavior? | 22:51 |
Tenkawa | nope.. non-root that works fine | 22:51 |
fsmithred | the behavior of su, I mean | 22:51 |
Tenkawa | it "suppose" to be that way | 22:51 |
Tenkawa | by design | 22:51 |
n4dir | i will just keep claiming a display-manager is the culprit. | 22:51 |
Tenkawa | its a security feature | 22:51 |
fsmithred | I find it an annoyance. I want root's path and I don't want to change directory to /root. | 22:52 |
Guest56 | Anyways,thanks for the help! I will read try the fix from answers later. :) | 22:53 |
fsmithred | I don't much care about running graphical apps as root, but that comes along with the change. | 22:53 |
fsmithred | good luck | 22:53 |
n4dir | pretty sure it was like that before. | 22:54 |
fsmithred | up until buster/beowulf. Then su got moved from login to util-linux | 22:54 |
n4dir | thats why way back we had what? kexec? gtkexec? whatever it was called | 22:54 |
fsmithred | gksu | 22:54 |
n4dir | right. | 22:54 |
fsmithred | kdesu | 22:54 |
Tenkawa | they are still around | 22:55 |
n4dir | it was easy. Lets quickly remove that | 22:55 |
fsmithred | gksu is not in repo | 22:55 |
Tenkawa | not in devuan/debian no | 22:56 |
Tenkawa | other distros | 22:56 |
Tenkawa | ahh | 22:57 |
Tenkawa | integrated into a policykit gksu module | 22:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!