Package: openstreetmap-carto
Version: 5.7.0-1
Followup-For: Bug #1053458
X-Debbugs-Cc: mx...@hotmail.com
Dear Maintainer,
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'sta
close 965282
thanks
The bug is not in Debian packaging, so I'm closing this bug.
--
Atte. Félix Arreola
«Sin firma GPG»
Finally found the issue.
Looks like the ctrl unix sockets are not created if network-manager is
not installed. Not sure about the complete work-flow, but goes like
this:
* wpa_supplicant inits. It doesn't create any unix socket on normal
startup
* network-manager ask for something in the db
El 18/07/2020 3:40 pm, Andrej Shadura escribió:
Hi,
Could it be that /var/run is for some reason not a symlink to /run?
Please note that the socket directory is in fact in /run. It would be
strange, but let's eliminate that before we go deeper in the
investigation :)
Nice check. /run and /var
El 18/07/2020 2:59 pm, Andrej Shadura escribió:
Hi,
Thanks for the bug report, but could you please provide more details?
Not sure what extra info is needed. But, let's check some examples:
Machine with Debian 9 and wpa_supplicant service running:
root@nohost:~# systemctl status wpa_supplica
Package: wpasupplicant
Version: 2:2.7+git20190128+0c1e29f-6+deb10u2
Severity: minor
Dear Maintainer,
I was trying to make use of the control interface of wpasupplicant, but
found out that it was not created. The service is running and no default
options (or configurations have been changed), b
The problem lies in the created chroot itself. The root directory had
'0700', so I fixed by entering chroot and changing permissions.
The bug doesn't apply to schroot itself
Special thanks to Roger for pointing the permissions problem.
--
Atte. Félix Arreola
«Sin firma GPG»
El 03/10/2017 3:57 pm, Roger Leigh escribió:
What are the permissions on the root directory of the chroot? You
might have permission to access it as root for the chroot call, but
that might not apply to the user after we call setuid/setgid to switch
the user and group. But does the user or gro
Ok, I went further with the dbug messages. I added more debug messages
to schroot and found that after calling chroot (and the call was
successful) executing chdir fails with the error "EACCES".
So, I removed the "chdir" for loop part, and tried to execute the shell,
and the following "stat" c
Ok, I still can't schroot as normal user, but adding some debugging
messages to schroot found that a chdir call fails, even if the directory
exists (example /, /tmp).
Running getcwd BEFORE doing the chdir return "/". That means that the
chroot call actually worked, but the next calls to chdir
Package: schroot
Version: 1.6.10-3+b1
Severity: normal
Dear Maintainer,
Can't run schroot as normal user in the schroot stretch version. I've
done the following:
I've installed a new, clean Debian stretch installation, without any
graphical interface. Next, created a normal user, and then ad
11 matches
Mail list logo
