Dear Maintainer, I would want to report a bug in package gdebi. When i attempt to install some package with gdebi it just closes without displaing any error. I found a error message in .xsession-errors saying "Refusing to render service to dead parents.". Tried on my host system with debian 10 and not modified debian 10 in vbox. Gdebi is not usable.
Dear Maintainer, When attempting last try through cli i managed to get to the authentication phase, but auth with correct password failed. The failure was with following message "polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED === Error executing command as another user: Not authorized This incident has been reported. ".
This might be the same problem I encountered on a clean install of buster. In my case it turns out gdebi-gtk is dependant on package dbus-x11, but it's not listed as a dependency. Could you try to install package dbus-x11 and see if it solves your problem?
Hey, on bullseye, with dbus-x11 installed, same bug with gdebi-gtk about crashing whenever I click "install". Crash and in the loggs I can read "refusing to render service to dead parents." The workaround I found for now is just "wrapping" debus-gtk in a shell (as I discovered that launching gdebi-gtk from a terminal emulator worked). That launcher work : Exec=sh -c "gdebi-gtk %f" Why ? I have no clue.
Dear Maintainer,
I meet the same bug.
I use Buster 10.7, I installed XFCE,MATE,GNOME desktop in my computer.
But this bug only occur in XFCE, MATE and GNOME is no problem.
BTW:
dbus-x11 is already installed in my compurter.
I also strace the pid of gdebi-gtk, the last error lines is following:
mprotect(0x7f6abcb42000, 4096, PROT_READ) = 0
mprotect(0x7f6abc710000, 4096, PROT_READ) = 0
mprotect(0x7f6abc6ff000, 32768, PROT_READ) = 0
mprotect(0x7f6abc7b4000, 4096, PROT_READ) = 0
mprotect(0x7f6abc9ce000, 4096, PROT_READ) = 0
mprotect(0x7f6abc9af000, 4096, PROT_READ) = 0
mprotect(0x7f6abcb53000, 4096, PROT_READ) = 0
mprotect(0x55c84fb26000, 4096, PROT_READ) = 0
mprotect(0x7f6abcba2000, 4096, PROT_READ) = 0
munmap(0x7f6abcb57000, 147011) = 0
set_tid_address(0x7f6abbcfa810) = 25973
set_robust_list(0x7f6abbcfa820, 24) = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7f6abc9896b0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f6abc995730}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7f6abc989740, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f6abc995730}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(NULL) = 0x55c851978000
brk(0x55c851999000) = 0x55c851999000
statfs("/sys/fs/selinux", 0x7ffd9c0c23b0) = -1 ENOENT (No such file or directory)
statfs("/selinux", 0x7ffd9c0c23b0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 377
read(3, "", 1024) = 0
close(3) = 0
access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory)
futex(0x7f6abcaedf58, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f6abcaedf58, FUTEX_WAKE_PRIVATE, 2147483647) = 0
geteuid() = 1001
openat(AT_FDCWD, "lib/x86_64-linux-gnu/charset.alias", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26402, ...}) = 0
mmap(NULL, 26402, PROT_READ, MAP_SHARED, 3, 0) = 0x7f6abcb74000
close(3) = 0
futex(0x7f6abc97ca08, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "pkexec must be setuid root\n", 27) = 27
exit_group(127) = ?
+++ exited with 127 +++
Is this bug possible have relation to the selinux ?
I'd installed the package about selinux:
dpkg -l|grep selinux
ii libselinux1:amd64 2.8-1+b1 amd64 SELinux runtime shared libraries
ii libselinux1:i386 2.8-1+b1 i386 SELinux runtime shared libraries
Dear Maintainer,
/usr/bin/python3 /usr/bin/gdebi-gtk process don't has correct PPID in XFCE, the parent ID is 1 in the XFCE.
atzlinux 3424 1 24 16:09 ? 00:00:10 /usr/bin/python3 /usr/bin/gdebi-gtk /home/atzlinux/download/qqmusic_1.0.5_amd64.deb
~~~
When I click Install button,I get the error info in .xsession-errors:
Refusing to render service to dead parents.
But in MATE, the gdebi-gtk process has the PPID of caja:
atzlinux 1631 1455 1 15:52 ? 00:00:02 caja
atzlinux 2023 1631 11 15:54 ? 00:00:10 /usr/bin/python3 /usr/bin/gdebi-gtk /home/atzlinux/download/qqmusic_1.0.5_amd64.deb
The caja is the file manager of MATE.
When I click Install button, there is a root password input display, the process user became the root, pkexec can been invoked:
atzlinux 1631 1455 1 15:52 ? 00:00:02 caja
root 2023 1631 6 15:54 ? 00:00:10 pkexec gdebi-gtk --non-interactive /home/atzlinux/download/qqmusic_1.0.5_amd64.deb
The deb package can install success.
在 2020/12/15 下午12:09, xiao sheng wen 写道: /usr/bin/python3 /usr/bin/gdebi-gtk process don't has correct PPID in XFCE, the parent ID is 1 in the XFCE. atzlinux 3424 1 24 16:09 ? 00:00:10 /usr/bin/python3 /usr/bin/gdebi-gtk /home/atzlinux/download/qqmusic_1.0.5_amd64.deb ~~~ When I click Install button,I get the error info in .xsession-errors: Refusing to render service to dead parents. But in MATE, the gdebi-gtk process has the PPID of caja: atzlinux 1631 1455 1 15:52 ? 00:00:02 caja atzlinux 2023 1631 11 15:54 ? 00:00:10 /usr/bin/python3 /usr/bin/gdebi-gtk /home/atzlinux/download/qqmusic_1.0.5_amd64.deb The caja is the file manager of MATE. When I click Install button, there is a root password input display, the process user became the root, pkexec can been invoked: atzlinux 1631 1455 1 15:52 ? 00:00:02 caja root 2023 1631 6 15:54 ? 00:00:10 pkexec gdebi-gtk --non-interactive /home/atzlinux/download/qqmusic_1.0.5_amd64.deb The deb package can install success.
control: found -1 0.9.5.7+nmu6 control: reassign -1 thunar Hi, IMHO, #932088 is the bug of Xfce file manger Thunar, not the bug of gdebi itself. I find some infos about it: Fixed in xfce4-panel: https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/52 https://gitlab.xfce.org/xfce/xfce4-panel/-/issues/407 But this bug still exist in thunar.
control: found -1 4.17.11-1 Hi, I'd test this bug in thunar 4.17.11-1 in experimental, It's exist too. Login in to Xfce use normal user account, when I double click one deb package file in thunar, the gdebi start up on screen, The parent ID of "/usr/bin/python3 /usr/bin/gdebi-gtk" is 1: ps -efww|grep gdebi atzlinux 68506 1 56 15:17 ? 00:00:02 /usr/bin/python3 /usr/bin/gdebi-gtk /path/any.deb When I click install button, the gdebi crash, ~/.xsession-errors has the error info: Refusing to render service to dead parents. as it can't invoke pkexec to input root password. I guess this is a bug of upstream. 在 2022/11/11 11:58, xiao sheng wen (肖盛文) 写道: Regards,
The symptoms here sound very much like https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1854588 which has now been fixed in Ubuntu, but not submitted to Debian There was also a fix drafted in https://salsa.debian.org/atzlinux-guest/gdebi/-/commit/1de6b00bef539de4458021dc02ed2110f76ab630 but not record if it worked. It wasn't uploaded to Debian. I think the root cause why gdebi is broken is that it is unmaintained. Looking at https://tracker.debian.org/pkg/gdebi the source code hosting points to https://code.launchpad.net/~gdebi-developers/gdebi/trunk. Last version in this source code was 0.9.5.7 in 2015, followed by commit that source code moved to https://code.launchpad.net/~gdebi-developers/gdebi/+git/main in 2022, yet that location has zero new commits since the 0.9.5.7 in 2015. If it was maintained, and there was a git repository people could contribute to, many of these bugs would have been fixed. Currently it is just maintainers doing one-off emergency fixes without storing anything in git in a way that would allow for contributions from users like Doug Brown in LP#1854588.
Control: reassign -1 gdebi Agreed there, and reassigning back to gdebi. Regards,
Can anybody reproduce this in Debian with an up to date version? To me it looks like this was fixed by this commit https://salsa.debian.org/debian/gdebi/-/commit/467def1dc59d3e2427b7fa9788c8c3abf74506a0 which is present in gdebi 0.9.5.7+nmu8, which already is in trixie? Please inform me if I am mistaken. best /Andreas Rönnquist gusnan@debian.org
I just tested on forky, and on my end it silently closes *after* asking for the root password now. This is both when opening the .deb using Firefox or Nemo. I tried it with this .deb file: https://mega.nz/linux/repo/Debian_13/amd64/thunar-megasync-Debian_13_amd64.deb Starting from command line, in the hopes of getting more information, yields it just not asking for root: juliangro@x299-workstation ~/temp> gdebi ./thunar-megasync-Debian_13_amd64.deb Traceback (most recent call last): File "/usr/bin/gdebi", line 76, in <module> debi = GDebiCli(options) File "/usr/share/gdebi/GDebi/GDebiCli.py", line 67, in __init__ self._cache = Cache(tp, rootdir=options.rootdir) ~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/apt/cache.py", line 149, in __init__ self._check_and_create_required_dirs(rootdir) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^ File "/usr/lib/python3/dist-packages/apt/cache.py", line 191, in _check_and_create_required_dirs open(rootdir + f, "w").close() ~~~~^^^^^^^^^^^^^^^^^^ PermissionError: [Errno 13] Permission denied: '//etc/apt/sources.list' juliangro@x299-workstation ~/temp [1]> —Julian Groß
Also see the last comment at the Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/1854588 which confirms my thoughts - marking as fixed with version number. /Andreas Rönnquist gusnan@debian.org andreas@ronnquist.net
Control: notfixed 932088 0.9.5.7+nmu8 Thanks - marking as not fixed again (I did send my previous mail before seeing your message, it was just slow getting delivered to the BTS). best /Andreas