Re: [DNG] How to construct a testing .deb binary with dpkg-buildpackage?
Am Sonntag, 14. November 2021 schrieb Haines Brown: > Given the absence of a backport for nano, my aim is to construct > a .deb for the testing version of nano (nano-9.5). This is what I > did: > > In apt sources.list IO added the lines > > deb http://deb.devuan.org/merged chimaera-backports main contrib > non-free deb-src http://deb.devuan.org/merged chimaera-backports main > contrib non-free Above you showed that you added the lines for source repository of "chimaera-backports"… Why not "testing" if that is where you want to build from? > I expected # aptitude search nano would now return a nano package > with the .bpo extendion. It did not. Whe not? You already said that there is no backport version of nano. > Next I tried to satisfy dependencies: > > # apt-get build-dep -t testing nano > but this returns: > > E: The value 'testing' is invalid for APT::Default-Release as such > a release is not available in the sources ^^^ I guess that you don't have entries for release testing in your sources.list… If you want to compile a testing version of nano then you need the source repository for the testing release, not the "chimaera-backports" one, I think. HTH Kind regards, Stefan ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] pkexec in Chimaera
Lars Noodén via Dng wrote: > sudoedit is running as root there, but it is not itself an editor. > > You can verify for yourself that the editor runs under the unprivileged > account. Here is an example of using sudoedit to fire up Geany: > > $ EDITOR=geany sudoedit /etc/group & > > $ ps -p $(pgrep -d , 'sudoedit|geany') -o user,pid,ppid,args > USER PID PPID COMMAND > root 221381 221316 sudoedit /etc/group > lars 221382 221381 geany /var/tmp/group.XXm6gNkW > > As you see, sudoedit is a wrapper which supervises the editor and a > temporary file. > I see. Was confused not seeing "vi" in process list, only sudoedit. Turns out, it was running as /usr/bin/editor (as local user, not root). Thanks for your explanation and patience :-) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] pkexec in Chimaera
On 11/14/21 20:44, tempforever wrote: Lars Noodén via Dng wrote: [snip] On 11/8/21 05:12, tempforever wrote: > You say that sudoedit will run the editor itself under the unprivileged account; however, it appears it does run as root: [snip] Yes, I say that, but I got it from the manual page which is much more authoritative. It goes through the steps: 1. Temporary copies are made of the files to be edited with the owner set to the invoking user. 2. The editor specified by the policy is run to edit the temporary files. The sudoers policy uses the SUDO_EDITOR, VISUAL and EDITOR environment variables (in that order). If none of SUDO_EDITOR, VISUAL or EDITOR are set, the first program listed in the editor sudoers(5) option is used. 3. If they have been modified, the temporary files are copied back to their original location and the temporary versions are removed. sudoedit is running as root there, but it is not itself an editor. You can verify for yourself that the editor runs under the unprivileged account. Here is an example of using sudoedit to fire up Geany: $ EDITOR=geany sudoedit /etc/group & $ ps -p $(pgrep -d , 'sudoedit|geany') -o user,pid,ppid,args USER PIDPPID COMMAND root 221381 221316 sudoedit /etc/group lars 221382 221381 geany /var/tmp/group.XXm6gNkW As you see, sudoedit is a wrapper which supervises the editor and a temporary file. /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] pkexec in Chimaera
Lars Noodén via Dng wrote: > On 11/8/21 05:12, tempforever wrote: > [snip]> Lars Noodén via Dng wrote: >>> You could consider running sudoedit instead. That will allow you to >>> edit a file as root (or any other designated account) while still >>> running the editor itself under the unprivileged account. One should >>> not run graphical programs as root, if it can be avoided. >>> >> Thank you for the help also. sudoedit requires user "a" to be in sudo >> group, which I'd prefer not to do. A non-gui text editor invoked with >> su -c will work for now. > > Please take another look at /etc/sudoers because the system is allowed > to have more than one group and users may be in more than one group at a > time. Also, there can be more than one single line in /etc/sudoers or > in any of the files beneath /etc/sudoers.d/ > > Thus you can have a group for account "a" which allows it to run > sudoedit but nothing else, and it doesn't even have to be a new group: > > %a ALL=(ALL:ALL) sudoedit > > See "man sudoers" for that. sudo is certanly one of the most > misunderstood and misused utilities around, in part because of the > tragic default settings spread by the Ubuntu distros, an affliction it > gets from Debian's default settings. > Thanks again for pointing me to sudoers. I was (mistakenly) under the impression that the user had to be in the sudo group. And yes, I did previously use mint/ubuntu. I had played around with sudoers previously for a different system (including once when I messed it up badly, not using visudo; had to boot from a live disk to fix it). You say that sudoedit will run the editor itself under the unprivileged account; however, it appears it does run as root: tempo@dev1:~$ ps aux|grep sudoedit root 3167 0.0 0.1 11176 5332 pts/0 S+ 13:42 0:00 sudoedit /etc/hosts tempo 3177 0.0 0.0 6180 664 pts/1 S+ 13:42 0:00 grep sudoedit Le 08/11/2021 à 14:16, Didier Kryn a écrit : > There is a hand-made replacement for pkexec and the good old gksu > and gksudo: > > In your sudoers file (edited with visudo), put the following line > > Defaults env_keep = "XAUTHORITY DISPLAY" > > Note there can be other variables in the list, like EDITOR, but the > above are the ones which will allow you to run GUIs under root priviledge. > > Then allow yourself to run foo with sudo (also by editing your sudoers > file vith visudo) and then > > sudo foo Nice to know this also; I can now verify that it does indeed work as you describe. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] lpr command not working
I reinstalled a printer on a Chimaera box. The CUPS test file prints just fine. The lpr Printers, the status of the old printer Idle, Accepting Jobs, Not Shared. Under its Administration I select Delete Printer and verify that I want it deleted. This returns the message that it has been successfully deleted. Yet it is still listed in Administration. A problem might be that the printer can't be deleted because it is shared by other systems despite its status. Where can I uncheck printer-is-shared for remote queues. Its status is Idle, Accepting Jobs, Not Shared. The best I can do is change its status to Rejecting Jobs. Restartintg CUPS sever did not help. The status of the printer I'm trying to delete is Not shared. But I can't deetete it. -- Haines Brown ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] How to construct a testing .deb binary with dpkg-buildpackage?
As a long time debian/devuan user I always feel ashamed to ask such a pedestrian question as this. Given the absence of a backport for nano, my aim is to construct a .deb for the testing version of nano (nano-9.5). This is what I did: In apt sources.list IO added the lines deb http://deb.devuan.org/merged chimaera-backports main contrib non-free deb-src http://deb.devuan.org/merged chimaera-backports main contrib non-free and ran an update and upgrade I expected # aptitude search nano would now return a nano package with the .bpo extendion. It did not. Whe not? Next I tried to satisfy dependencies: # apt-get build-dep -t testing nano but this returns: E: The value 'testing' is invalid for APT::Default-Release as such a release is not available in the sources E: Unable to find a source package for nano # apt-get build-dep nano-5.9 still can't find the source pacakage. I thought the -t would override the deault stable, but instead it seems the default value stable is negating the -t option. -- Haines Brown ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] eudev issue after beowulf upgrade
Hi, On 11/13/21 4:06 PM, Riccardo Mottola via Dng wrote: thanks for the hint. I did the upgrade using directly two of the packages and, voilà things work again and USB disks and CD-ROM appear correctly again in xfce. actually, I was too quick too rejoyce. Installed new eudev and rebooted, all fine. Strangely, after a new reboot the day after, even with the new udev stuff, xfce shows wrong mounted filesystems: Usually I only see one icon "File System" and if I put in a removable device, like an USB key or a CD, it pops up on the desktop. Now, instead, I see, other than "FileSystem" also "Filesystem root" (duplicate essentially but shown as a removable device) and "cdrom0" even if there is no CD. If I put in a USB key nothing gets shown, so I cannot access it. What could be going wrong? strange it is so stable during boots. Riccardo ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
