Re: nmcli connection edit introduces duplicate connection

2025-05-29 Thread gene heskett
On 5/28/25 17:06, accipiter wrote: On 5/27/25 7:40 PM, Titus Newswanger wrote: On 5/26/25 14:20, accipiter wrote: Attempting to delete/remove the connection entry with the wrong data simply caused the defective connection entry to be replicated, only now with yet another UUID.  It is this err

Re: nmcli connection edit introduces duplicate connection

2025-05-28 Thread fxkl47BF
On Wed, 28 May 2025, accipiter wrote: > On 5/27/25 7:40 PM, Titus Newswanger wrote: >> >> On 5/26/25 14:20, accipiter wrote: >>> Attempting to delete/remove the connection entry with the wrong data >>> simply caused the defective connection entry to be replicated, only >>> now with yet another UUI

Re: nmcli connection edit introduces duplicate connection

2025-05-28 Thread accipiter
On 5/27/25 7:40 PM, Titus Newswanger wrote: On 5/26/25 14:20, accipiter wrote: Attempting to delete/remove the connection entry with the wrong data simply caused the defective connection entry to be replicated, only now with yet another UUID.  It is this erroneous connection entry that appear

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread Max Nikulin
On 28/05/2025 09:06, accipiter wrote: but also had IP4 parameters with the 169.254... crap. Ignore it, it should not harm as an additional address. It is a link-local address and it should not prevent routing to the gateway. It *may* mean that some tool is trying to get an IP address through

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread Greg Wooledge
On Tue, May 27, 2025 at 19:06:22 -0700, accipiter wrote: > At first it didn't seem to do any good, mis-replicating the eth0 connection > when I killed that particular eth0 using its UUID. But then I tried killing > *both* eth0 connections, then trying to re-edit / create the e

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread Titus Newswanger
On 5/26/25 14:20, accipiter wrote: Attempting to delete/remove the connection entry with the wrong data simply caused the defective connection entry to be replicated, only now with yet another UUID.  It is this erroneous connection entry that appears connected to the eth0 device. I had a simil

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread accipiter
On 5/26/25 7:40 PM, Max Nikulin wrote: On 27/05/2025 02:20, accipiter wrote:     nmcli c edit eth0 [...] Attempting to delete/remove the connection entry with the wrong data simply caused the defective connection entry to be replicated, only now with yet another UUID. Is there a chance

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread Max Nikulin
On 28/05/2025 06:44, accipiter wrote: Oh - sorry forgot: there's *nothing* in /etc/network/interfaces.d/ While I have no reason to not trust you, it would be more convincing to post exact command and its output, e.g. grep -RE '^\s*[^#]' /etc/network/interfaces /etc/network/interfaces.d In

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread accipiter
On 5/26/25 11:10 PM, Andy Smith wrote: Hi, On Mon, May 26, 2025 at 08:46:37PM -0700, accipiter wrote: In the past it was the old standard /etc/network/interfaces setup. I had commented-out all the lines associated with 'eth0', but it's possible there's something that I haven't adequately kille

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread accipiter
On 5/26/25 9:40 PM, Charles Curley wrote: On Mon, 26 May 2025 20:46:37 -0700 accipiter wrote: If you are using Network Manager, you should not have anything else setting up interfaces that NM manages for you. What did you use for the purpose in the past? In the past it was the old standar

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread accipiter
On 5/26/25 11:10 PM, Andy Smith wrote: Hi, On Mon, May 26, 2025 at 08:46:37PM -0700, accipiter wrote: In the past it was the old standard /etc/network/interfaces setup. I had commented-out all the lines associated with 'eth0', but it's possible there's something that I haven't adequately kille

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread Eben King
On 5/26/25 15:20, accipiter wrote: I updated an old laptop to bookworm - but on reboot the hard-wired ethernet connection wouldn't work. Maybe the ethernet hardware is unsupported? Can you see in journalctl where the module loads? You can find the driver name with ls -l /sys/class/net//

Re: nmcli connection edit introduces duplicate connection

2025-05-27 Thread Greg Wooledge
On Mon, May 26, 2025 at 20:46:37 -0700, accipiter wrote: > On 5/26/25 6:20 PM, Charles Curley wrote: > > On Mon, 26 May 2025 12:20:22 -0700 > > accipiter wrote: > > > > > it showed not 1 but 2 entries for eth0 - though with different UUIDs. > > > > If you are using Network Manager, you should no

Re: nmcli connection edit introduces duplicate connection

2025-05-26 Thread Andy Smith
Hi, On Mon, May 26, 2025 at 08:46:37PM -0700, accipiter wrote: > In the past it was the old standard /etc/network/interfaces setup. I had > commented-out all the lines associated with 'eth0', but it's possible > there's something that I haven't adequately killed off. Is > there some way to ensur

Re: nmcli connection edit introduces duplicate connection

2025-05-26 Thread accipiter
On 5/26/25 6:20 PM, Charles Curley wrote: On Mon, 26 May 2025 12:20:22 -0700 accipiter wrote: it showed not 1 but 2 entries for eth0 - though with different UUIDs. If you are using Network Manager, you should not have anything else setting up interfaces that NM manages for you. What did you

Re: nmcli connection edit introduces duplicate connection

2025-05-26 Thread Charles Curley
On Mon, 26 May 2025 20:46:37 -0700 accipiter wrote: > > If you are using Network Manager, you should not have anything else > > setting up interfaces that NM manages for you. What did you use for > > the purpose in the past? > > > In the past it was the old standard /etc/network/interfaces set

Re: nmcli connection edit introduces duplicate connection

2025-05-26 Thread accipiter
On 5/26/25 7:40 PM, Max Nikulin wrote: On 27/05/2025 02:20, accipiter wrote:     nmcli c edit eth0 [...] Attempting to delete/remove the connection entry with the wrong data simply caused the defective connection entry to be replicated, only now with yet another UUID. Is there a chance

Re: nmcli connection edit introduces duplicate connection

2025-05-26 Thread Max Nikulin
On 27/05/2025 02:20, accipiter wrote:    nmcli c edit eth0 [...] Attempting to delete/remove the connection entry with the wrong data simply caused the defective connection entry to be replicated, only now with yet another UUID. Is there a chance that NetworkManager is under control of

Re: nmcli connection edit introduces duplicate connection

2025-05-26 Thread Charles Curley
On Mon, 26 May 2025 12:20:22 -0700 accipiter wrote: > it showed not 1 but 2 entries for eth0 - though with different UUIDs. If you are using Network Manager, you should not have anything else setting up interfaces that NM manages for you. What did you use for the purpose in the past? -- Does a

nmcli connection edit introduces duplicate connection

2025-05-26 Thread accipiter
I updated an old laptop to bookworm - but on reboot the hard-wired ethernet connection wouldn't work. Trying to manually configure the networking via nmcli c edit eth0 appeared to work ('print' gave the right values) BUT networking still didn't work. Old standby /sbin

Re: Return to previous presentation edit Grub

2024-01-24 Thread Greg Wooledge
On Wed, Jan 24, 2024 at 10:50:25AM +, Simeone Dominique wrote: > Good morning, > > I had Debian 10 with two other linŭes that I could access at startup. > > I installed Debian 11 and the new grub only offers me Debian. > > How can I return to the presentation of my three operating systems fr

Return to previous presentation edit Grub

2024-01-24 Thread Simeone Dominique
Good morning, I had Debian 10 with two other linŭes that I could access at startup. I installed Debian 11 and the new grub only offers me Debian. How can I return to the presentation of my three operating systems from the command line? Debianement your. Mr.Dominique Simeone Mr.Dominique Sime

Re: Edit NIC Address

2024-01-05 Thread Timothy M Butterworth
On Fri, Jan 5, 2024 at 12:18 PM David wrote: > On Fri, 2024-01-05 at 00:43 -0500, Felix Miata wrote: > > David composed on 2024-01-04 04:30 (UTC): > > > > > With the latest Debian I'm trying to find the file to edit to > > > change > > > the IP a

Re: Edit NIC Address

2024-01-05 Thread Pocket
On 1/5/24 05:41, David wrote: On Fri, 2024-01-05 at 00:43 -0500, Felix Miata wrote: David composed on 2024-01-04 04:30 (UTC): With the latest Debian I'm trying to find the file to edit to change the IP address of a remote box, can anybody point me in the correct direction please? I ca

Re: Edit NIC Address

2024-01-05 Thread Marco Moock
Am 05.01.2024 um 10:41:26 Uhr schrieb David: > But I cannot find the file to edit. Use the Networkmanager (nmcli, nmtui) to edit it. nmcli connection show nmcli connection edit "print" gives all attributes set changes it. save to write it and then nmcli connection up to apply it.

Re: Edit NIC Address

2024-01-05 Thread David
On Fri, 2024-01-05 at 00:43 -0500, Felix Miata wrote: > David composed on 2024-01-04 04:30 (UTC): > > > With the latest Debian I'm trying to find the file to edit to > > change > > the IP address of a remote box, can anybody point me in the correct > > direction

Re: Edit NIC Address

2024-01-05 Thread Geert Stappers
On Fri, Jan 05, 2024 at 08:15:08PM +1100, Keith Bainbridgge wrote: > On 5/1/24 15:30, David wrote: > > Morning Group, > > > > With the latest Debian I'm trying to find the file to edit to change > > the IP address of a remote box, can anybody point me in

Re: Edit NIC Address

2024-01-05 Thread Keith Bainbridgge
ning Group, With the latest Debian I'm trying to find the file to edit to change the IP address of a remote box, can anybody point me in the correct direction please? I can SSH into this box, but cannot find the file to edit. Thank you, David.

Re: Edit NIC Address

2024-01-05 Thread Marco Moock
Am 05.01.2024 um 04:30:44 Uhr schrieb David: > With the latest Debian I'm trying to find the file to edit to change > the IP address of a remote box, can anybody point me in the correct > direction please? There are various ways to configure it. Files in /etc/network, sy

Re: Edit NIC Address

2024-01-04 Thread Felix Miata
David composed on 2024-01-04 04:30 (UTC): > With the latest Debian I'm trying to find the file to edit to change > the IP address of a remote box, can anybody point me in the correct > direction please? > I can SSH into this box, but cannot find the file to edit. Traditional

Edit NIC Address

2024-01-04 Thread David
Morning Group, With the latest Debian I'm trying to find the file to edit to change the IP address of a remote box, can anybody point me in the correct direction please? I can SSH into this box, but cannot find the file to edit. Thank you, David.

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-14 Thread Yvan Masson
Le 09/03/2023 à 12:11, Vincent Lefevre a écrit : On 2023-03-09 08:33:08 +0100, Yvan Masson wrote: I might be the same issue indeed. A temporary workaround I have just found is to run KDE on Wayland. But I suppose it is not possible with FVWM. In any case, I sometimes need to run remote X appli

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-14 Thread Vincent Lefevre
On 2023-03-09 04:19:22 +0100, Vincent Lefevre wrote: > FYI, my bug reports for Firefox 110, with some details on the > behavior I get: > https://bugzilla.mozilla.org/show_bug.cgi?id=1820542 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032428 Now it appears that this bug is actually a F

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread tomas
On Thu, Mar 09, 2023 at 03:34:05PM -0500, Stefan Monnier wrote: > >> > AFAIK, "apt full-upgrade" is for stable to the next stable, > >> > not for testing and unstable (one typically resolves conflicts > >> > interactively). > >> > >> Interesting. I don't use `apt` but "full-upgrade" is what I've

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Vincent Lefevre
On 2023-03-09 15:34:05 -0500, Stefan Monnier wrote: > >> > AFAIK, "apt full-upgrade" is for stable to the next stable, > >> > not for testing and unstable (one typically resolves conflicts > >> > interactively). > >> > >> Interesting. I don't use `apt` but "full-upgrade" is what I've been > >> us

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Stefan Monnier
>> > AFAIK, "apt full-upgrade" is for stable to the next stable, >> > not for testing and unstable (one typically resolves conflicts >> > interactively). >> >> Interesting. I don't use `apt` but "full-upgrade" is what I've been >> using with testing for the last 20 years, first with `apt-get` the

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread tomas
On Thu, Mar 09, 2023 at 10:40:14AM -0500, Stefan Monnier wrote: > > AFAIK, "apt full-upgrade" is for stable to the next stable, > > not for testing and unstable (one typically resolves conflicts > > interactively). > > Interesting. I don't use `apt` but "full-upgrade" is what I've been > using wi

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Brad Rogers
On Thu, 9 Mar 2023 17:57:12 +0100 Yvan Masson wrote: Hello Yvan, >Yes, I did that, but thanks for the suggestion. NP. Shame it didn't help. > >As I do not always use X11, I am thinking that maybe my issue has begun >on a previous update… Always a possibility. Another possibility is that, so

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Yvan Masson
Le 09/03/2023 à 12:40, Brad Rogers a écrit : On Wed, 8 Mar 2023 18:02:42 +0100 Yvan Masson wrote: Hello Yvan, Thanks for your insights, You have a lot of Plasma related updates there. Have you; Logged out and back in? or Rebooted? Yes, I did that, but thanks for the suggestion. As I do

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Stefan Monnier
> AFAIK, "apt full-upgrade" is for stable to the next stable, > not for testing and unstable (one typically resolves conflicts > interactively). Interesting. I don't use `apt` but "full-upgrade" is what I've been using with testing for the last 20 years, first with `apt-get` then with `aptitude`.

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Brad Rogers
On Wed, 8 Mar 2023 18:02:42 +0100 Yvan Masson wrote: Hello Yvan, >Thanks for your insights, You have a lot of Plasma related updates there. Have you; Logged out and back in? or Rebooted? I found I had a few issues after the upgrade from 5.26 to 5.27. A reboot solved some of them (update coi

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Vincent Lefevre
On 2023-03-09 04:32:05 -0500, Timothy M Butterworth wrote: > On Thu, Mar 9, 2023 at 4:06 AM Timothy Butterworth < > timothy.m.butterwo...@gmail.com> wrote: > > > Try running apt fully upgrade > > > `sudo apt full-upgrade` sorry about that my tablet auto-corrected. AFAIK, "apt full-upgrade" is for

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Vincent Lefevre
On 2023-03-09 08:33:08 +0100, Yvan Masson wrote: > I might be the same issue indeed. A temporary workaround I have just found > is to run KDE on Wayland. But I suppose it is not possible with FVWM. In any case, I sometimes need to run remote X applications transparently, so Wayland is not an optio

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Tixy
On Thu, 2023-03-09 at 04:32 -0500, Timothy M Butterworth wrote: > On Thu, Mar 9, 2023 at 4:06 AM Timothy Butterworth < > timothy.m.butterwo...@gmail.com> wrote: > > > Try running apt fully upgrade > > > `sudo apt full-upgrade` sorry about that my tablet auto-corrected. And it broke threading. -

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Timothy M Butterworth
/2023 à 04:19, Vincent Lefevre a écrit : > > On 2023-03-08 18:02:42 +0100, Yvan Masson wrote: > >> Using testing with KDE, I have an issue since last update: for many QT > >> applications and some GTK applications, menus (File, Edit…) or even > >> drop-down li

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-09 Thread Timothy Butterworth
TK applications, menus (File, Edit…) or even >> drop-down lists are difficult to trigger (Moste often I need to click and >> then press Alt). I would like to ensure this bug has already been reported >> (which might not has it has already entered testing), but I don't know

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-08 Thread Yvan Masson
Le 09/03/2023 à 04:19, Vincent Lefevre a écrit : On 2023-03-08 18:02:42 +0100, Yvan Masson wrote: Using testing with KDE, I have an issue since last update: for many QT applications and some GTK applications, menus (File, Edit…) or even drop-down lists are difficult to trigger (Moste often I

Re: Strange application menus (File, Edit…) behaviour since last update

2023-03-08 Thread Vincent Lefevre
On 2023-03-08 18:02:42 +0100, Yvan Masson wrote: > Using testing with KDE, I have an issue since last update: for many QT > applications and some GTK applications, menus (File, Edit…) or even > drop-down lists are difficult to trigger (Moste often I need to click and > then press A

Strange application menus (File, Edit…) behaviour since last update

2023-03-08 Thread Yvan Masson
Hi Debian users, Using testing with KDE, I have an issue since last update: for many QT applications and some GTK applications, menus (File, Edit…) or even drop-down lists are difficult to trigger (Moste often I need to click and then press Alt). I would like to ensure this bug has already

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-09 Thread MichaIng
Your right /tmp is not a tmpfs by default on Debian. I though it was, maybe being too much used to it as this is configured by default on our images. /dev/shm or /run would work better then, although /run IMO is more aimed for non-temporary files, relevant through the whole runtime of the relat

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-09 Thread Andrei POPESCU
On Mi, 09 dec 20, 16:46:17, MichaIng wrote: > Please note that it by default appears on Bullseye only. See that last mails > regarding this issue, the related changed sysfs setting has identified > already do: > --- > sysctl fs.protected_regular=2 > --- > and retry the steps, which will the

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-09 Thread MichaIng
Please note that it by default appears on Bullseye only. See that last mails regarding this issue, the related changed sysfs setting has identified already do: --- sysctl fs.protected_regular=2 --- and retry the steps, which will then fail. --- sysctl fs.protected_regular=0 --- t

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-09 Thread Andrei POPESCU
On Ma, 08 dec 20, 15:57:17, MichaIng wrote: > > root@VM-Bullseye:/tmp# cd /root > root@VM-Bullseye:~# mkdir testdir > root@VM-Bullseye:~# chmod 1777 testdir > root@VM-Bullseye:~# > testdir/testfile > root@VM-Bullseye:~# chown www-data testdir/testfile > root@VM-Bullseye:~# > testdir/testfile > -ba

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-09 Thread Andrei POPESCU
On Ma, 08 dec 20, 16:45:08, MichaIng wrote: > > Jep, based on the way the list mail address was shown on the Debian bug > report page, I was actually hoping to reach official maintainers, but this > seems to be more an end-user support list? Yes, this is an end-user support list. The idea is tha

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread Greg Wooledge
On Wed, Dec 09, 2020 at 12:02:17AM +0100, MichaIng wrote: > Sharing files through /tmp is probably rare, but /tmp it is for temporary > files, it's by default a tmpfs No, it's not. It's just a directory inside the root file system by default, in Debian. > (relevant when one wants to minimize fil

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread MichaIng
or intentionally) such a way. Your unique situation, where user A is putting a file in /tmp for some reason, and then user R is supposed to edit it in place, is really weird. I don't know why you're putting this important shared file in /tmp, but you might want to move it to a more approp

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread Greg Wooledge
unique situation, where user A is putting a file in /tmp for some reason, and then user R is supposed to edit it in place, is really weird. I don't know why you're putting this important shared file in /tmp, but you might want to move it to a more appropriate place.

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread MichaIng
I think the topic with the modes just applies when the file is actually created, hence not existing yet. However, aiming for a method to edit a file without O_CREAT, and voila: --- root@VM-Bullseye:~# cat testdir/testfile 143 root@VM-Bullseye:~# sed -i 's/1/5/' testdir/testfi

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread Greg Wooledge
On Tue, Dec 08, 2020 at 06:40:38PM +0100, to...@tuxteam.de wrote: > I lost track a bit about your other hypotheses, but this mode changing > bit when O_CREAT is given somehow rings a bell. I googled "linux o_creat sticky" and got this: https://patchwork.kernel.org/project/kernel-hardening/patch/2

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread tomas
On Tue, Dec 08, 2020 at 06:08:12PM +0100, MichaIng wrote: > Good idea, although it would have been recognised much earlier > during nearly every normal system operation: > --- > root@micha:/tmp# set -o | grep noclobber > noclobber off > --- > > strace is a fantastic idea, but it seem

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread MichaIng
Good idea, although it would have been recognised much earlier during nearly every normal system operation: --- root@micha:/tmp# set -o | grep noclobber noclobber off --- strace is a fantastic idea, but it seems to fail on the lowest level "EACCES (Permission denied)": --- ro

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread tomas
On Tue, Dec 08, 2020 at 05:09:09PM +0100, MichaIng wrote: [...] > >>dash: 1: cannot create testfile: Permission denied > > > >Oh, I see. Strange error message though -- I'd expect dash to > >try to open the file in append mode, not to `create' it. > I was also wondering about that, but dash prin

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread MichaIng
Am 08.12.2020 um 16:55 schrieb to...@tuxteam.de: @Tomas: --- root@VM-Bullseye:/tmp# id uid=0(root) gid=0(root) groups=0(root) root@VM-Bullseye:/tmp# >> testfile -bash: testfile: Permission denied root@VM-Bullseye:/tmp# dash -c '>> testfile' dash: 1: cannot create testfile: Permission denied

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread tomas
On Tue, Dec 08, 2020 at 03:57:17PM +0100, MichaIng wrote: [...] > @Tomas: > --- > root@VM-Bullseye:/tmp# id > uid=0(root) gid=0(root) groups=0(root) > root@VM-Bullseye:/tmp# >> testfile > -bash: testfile: Permission denied > root@VM-Bullseye:/tmp# dash -c '>> testfile' > dash: 1: cannot creat

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread MichaIng
Am 08.12.2020 um 16:15 schrieb Greg Wooledge: It *has* to be related to the kernel. Where else would the permissions (capabilities) be applied? That is exactly what I am wondering about. Those are pretty minimal Debian install, no SELinux and no AppArmor actively installed, only what is pull

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread Greg Wooledge
On Tue, Dec 08, 2020 at 03:57:17PM +0100, MichaIng wrote: > root@VM-Bullseye:/tmp# cd /root > root@VM-Bullseye:~# mkdir testdir > root@VM-Bullseye:~# chmod 1777 testdir > root@VM-Bullseye:~# > testdir/testfile > root@VM-Bullseye:~# chown www-data testdir/testfile > root@VM-Bullseye:~# > testdir/tes

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-08 Thread MichaIng
Sorry for the late reply guys, I was not subscribed to the list, just got the address from the bug report instructions in case the related package could not be identified, and thought I get an answer directly to my mailbox xD: https://www.debian.org/Bugs/Reporting.en.html Back to topic. I tot

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-04 Thread Greg Wooledge
On Fri, Dec 04, 2020 at 02:40:02PM +0100, MichaIng wrote: > Even the root user is not permitted to write to an existing file that is > owned by another user within a sticky bit directory: > --- > 2020-12-04 14:16:58 root@micha:/tmp# whoami > root "id" is a better command for determining your c

Re: Where to report: root fails to edit other users file in sticky bit directory

2020-12-04 Thread tomas
On Fri, Dec 04, 2020 at 02:40:02PM +0100, MichaIng wrote: > Hi Debian team, > > I'm sorry to contact you here, but I ran into an IMO extremely > important bug where I don't know which package is actually > responsible. > > Even the root user is not permitted to write to an existing file > that is

Where to report: root fails to edit other users file in sticky bit directory

2020-12-04 Thread MichaIng
Hi Debian team, I'm sorry to contact you here, but I ran into an IMO extremely important bug where I don't know which package is actually responsible. Even the root user is not permitted to write to an existing file that is owned by another user within a sticky bit directory: --- 2020-12

Re: Starting network after setting configuration with nmtui-edit ignores IPv6 configuration

2018-07-27 Thread john doe
used nmtui-edit to configure the network and got: ~# cat /etc/NetworkManager/system-connections/Wired\ connection\ 1 [connection] id=Wired connection 1 uuid=475dd973-64e7-38b7-aefe-e8df6f58fb0f type=ethernet autoconnect-priority=-999 permissions= timestamp=1532707850 [ethernet] mac-address

Starting network after setting configuration with nmtui-edit ignores IPv6 configuration

2018-07-27 Thread Freek de Kruijf
I am using packet network-manager. ~# dpkg --status network-manager Package: network-manager Status: install ok installed Priority: optional Section: net Installed-Size: 9673 Maintainer: Utopia Maintenance Team Architecture: arm64 Version: 1.6.2-3 I used nmtui-edit to configure the network and

Re: what package to edit colors?

2017-11-03 Thread tomas
urce code for xcoloredit is? > >xcolors and xcolorsel may be used to view system standard colors. > >To view/edit colors, there is gcolor2. > >BTW, kcolorchooser also works without KDE. > > > > > Hi, > I don't know why I couldn't find those. I spent about

Re: what package to edit colors?

2017-11-03 Thread Fred
x27;t use. Is there another color viewer/editor package for Debian (Jessie) or does anyone know where the source code for xcoloredit is? xcolors and xcolorsel may be used to view system standard colors. To view/edit colors, there is gcolor2. BTW, kcolorchooser also works without KDE. Hi, I don&#

Re: what package to edit colors?

2017-11-03 Thread Siard
ere another color > viewer/editor package for Debian (Jessie) or does anyone know where the > source code for xcoloredit is? xcolors and xcolorsel may be used to view system standard colors. To view/edit colors, there is gcolor2. BTW, kcolorchooser also works without KDE.

Re: what package to edit colors?

2017-11-03 Thread tomas
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 03, 2017 at 09:46:37AM -0700, Fred wrote: > Hello, > > Xcoloredit was available for Solaris to view system standard colors > and enter rgb values. I found this is available for some of the BSD > distributions but not Debian. All I could

what package to edit colors?

2017-11-03 Thread Fred
Hello, Xcoloredit was available for Solaris to view system standard colors and enter rgb values. I found this is available for some of the BSD distributions but not Debian. All I could find is kcolorchooser which is associated with KDE which I don't use. Is there another color viewer/edito

Re: [TEST RUNS] Re: installer defaults for desktops (was Re: Suggested edit)

2017-04-01 Thread Lisi Reisz
On Saturday 01 April 2017 21:23:21 Cindy-Sue Causey wrote: > On 4/1/17, cbannis...@slingshot.co.nz wrote: > > On Wed, Mar 22, 2017 at 03:33:08PM +, Lisi Reisz wrote: > >> In all this talk of Debian being the universal operating system, and > >> helping > >> newbies ... > > > > I'm not sure tho

Re: [TEST RUNS] Re: installer defaults for desktops (was Re: Suggested edit)

2017-04-01 Thread Cindy-Sue Causey
On 4/1/17, cbannis...@slingshot.co.nz wrote: > On Wed, Mar 22, 2017 at 03:33:08PM +, Lisi Reisz wrote: >> >> In all this talk of Debian being the universal operating system, and >> helping >> newbies ... > > I'm not sure those two concepts are related. My understanding of Debian > being the un

Re: [TEST RUNS] Re: installer defaults for desktops (was Re: Suggested edit)

2017-04-01 Thread Lisi Reisz
On Saturday 01 April 2017 18:59:48 cbannis...@slingshot.co.nz wrote: > On Wed, Mar 22, 2017 at 03:33:08PM +, Lisi Reisz wrote: > > In all this talk of Debian being the universal operating system, and > > helping newbies ... > > I'm not sure those two concepts are related. My understanding of De

Re: [TEST RUNS] Re: installer defaults for desktops (was Re: Suggested edit)

2017-04-01 Thread cbannister
On Wed, Mar 22, 2017 at 03:33:08PM +, Lisi Reisz wrote: > > In all this talk of Debian being the universal operating system, and helping > newbies ... I'm not sure those two concepts are related. My understanding of Debian being the universal operating system is that it can run on as many ha

Re: installer defaults for desktops (was Re: Suggested edit)

2017-04-01 Thread cbannister
On Wed, Mar 22, 2017 at 09:10:16AM +, Darac Marjal wrote: > On Tue, Mar 21, 2017 at 06:03:12PM +, Lisi Reisz wrote: > >On Tuesday 21 March 2017 17:15:32 Catherine Gramze wrote: > >>Sent from my iPad > > > >Note it is sent from an iPad! Open Source all the way! > > > >Incidentally, why

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-25 Thread Lisi Reisz
On Friday 24 March 2017 18:25:30 Joe wrote: > On Fri, 24 Mar 2017 15:18:31 + > > Lisi Reisz wrote: > > On Friday 24 March 2017 12:06:58 Joe wrote: > > > I've mentioned recently that I once did a non-expert netinstall, in > > > the days when I used static addresses and no DHCP, and was miffed >

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread David Wright
On Fri 24 Mar 2017 at 18:46:43 (-0400), Catherine Gramze wrote: > > > On Mar 24, 2017, at 6:05 PM, David Wright wrote: > > > >> On Fri 24 Mar 2017 at 15:44:15 (-0400), Catherine Gramze wrote: > >> Sent from my iPad > >> > >>> On Mar 24, 2017, at 2:30 PM, Steve McIntyre wrote: > >>> > >>> but

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Steve McIntyre
Catherine Gramze wrote: > On Mar 24, 2017, at 6:05 PM, David Wright wrote: >> Here's the netinst installation menu after Advanced/Expert options >> have been chosen. The asterisks are mine, and show what's probably >> the most typical path from start to finish (in order). >> At which step is the r

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Catherine Gramze
> On Mar 24, 2017, at 6:05 PM, David Wright wrote: > >> On Fri 24 Mar 2017 at 15:44:15 (-0400), Catherine Gramze wrote: >> Sent from my iPad >> >>> On Mar 24, 2017, at 2:30 PM, Steve McIntyre wrote: >>> >>> but that went away years ago. At the end of the single installer run, >>> it should be

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread David Wright
On Fri 24 Mar 2017 at 15:44:15 (-0400), Catherine Gramze wrote: > Sent from my iPad > > > On Mar 24, 2017, at 2:30 PM, Steve McIntyre wrote: > > > > but that went away years ago. At the end of the single installer run, > > it should be finished. Do you mean "reboots into the newly installed > >

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Catherine Gramze
Sent from my iPad > On Mar 24, 2017, at 2:30 PM, Steve McIntyre wrote: > > but that went away years ago. At the end of the single installer run, > it should be finished. Do you mean "reboots into the newly installed > system" instead, maybe? > Yes, it boots into that bare bones system before

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Brian
On Fri 24 Mar 2017 at 18:23:26 +, Steve McIntyre wrote: > Catherine Gramze wrote: > > > >The point of free software is not to cater to your personal > >preferences, or mine, but to make that software accessible and useful > >to the greatest number of people. The netinst installer doesn't do >

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Curt
On 2017-03-24, Catherine Gramze wrote: > > > > > Sent from my iPad >> On Mar 24, 2017, at 2:08 PM, Curt wrote: >> >> I'd just wish you'd wrap your lines in accordance to rule number 87 of the >> "Debian Etiquette Guidelines," by I.M. Sikothis. > > Thank you for mentioning this. I was not aware t

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Catherine Gramze
Sent from my iPad > On Mar 24, 2017, at 2:08 PM, Curt wrote: > > I'd just wish you'd wrap your lines in accordance to rule number 87 of the > "Debian Etiquette Guidelines," by I.M. Sikothis. Thank you for mentioning this. I was not aware that my iPad does not wrap lines appropriately for ev

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Steve McIntyre
Catherine Gramze wrote:> >> On Mar 23, 2017, at 9:22 PM, Steve McIntyre wrote: >> >> Catherine, I'm curious - when was the last time you installed Debian >> using d-i? I've now seen you several times write (like above) about >> "backing out of the installer after the reboot". Are you talking abou

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Joe
On Fri, 24 Mar 2017 15:18:31 + Lisi Reisz wrote: > On Friday 24 March 2017 12:06:58 Joe wrote: > > I've mentioned recently that I once did a non-expert netinstall, in > > the days when I used static addresses and no DHCP, and was miffed > > to find I had no network interfaces at the end of th

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Steve McIntyre
Catherine Gramze wrote: > >The point of free software is not to cater to your personal >preferences, or mine, but to make that software accessible and useful >to the greatest number of people. The netinst installer doesn't do >that when it allows a very broken installation to result. There will >in

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Curt
On 2017-03-23, Catherine Gramze wrote: > > > Sent from my iPad > >> On Mar 23, 2017, at 2:03 PM, Steve McIntyre wrote: >> >> Please calm down, why the aggression? :-( > > Lisi is incensed with my suggestion that the netinst installer should refuse > to continue if no network c Cathy I'd just w

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Curt
On 2017-03-24, Andy Smith wrote: > > It can be useful to note the names of people who can't seem to > prevent themselves from writing argumentative and massively > off-topic responses over and over again. It's a relatively small but > vocal list. Right. Let's write the names down and communicate

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Andy Smith
Hi Jonathan, On Fri, Mar 24, 2017 at 10:16:16AM +, Jonathan Dowland wrote: > On Fri, Mar 24, 2017 at 06:29:35AM +, Andy Smith wrote: > > It can be useful to note the names of people who can't seem to > > prevent themselves from writing argumentative and massively > > off-topic responses ov

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Lisi Reisz
On Friday 24 March 2017 12:06:58 Joe wrote: > I've mentioned recently that I once did a non-expert netinstall, in the > days when I used static addresses and no DHCP, and was miffed to find I > had no network interfaces at the end of the process. Until fairly recently I have always had static IPs

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Lisi Reisz
On Friday 24 March 2017 12:06:58 Joe wrote: > the user > should be notified and asked whether to continue. The user *is* notified and asked whether to continue. The user is not *prevented* from continuing, should he or she be perverse enough to wish to do so. Lisi

Re: installer defaults for desktops (was Re: Suggested edit)

2017-03-24 Thread Lisi Reisz
On Friday 24 March 2017 12:07:59 Richard Owlett wrote: > It might be just the ticket for some > of my minimalist experiments. ;-) It would. The other minimalist install media have mostly gone by the board. I have just checked, and amazingly LNX-BBC (Linux Bootable Business Card) and DSL (Damn

  1   2   3   4   5   >