With glib2 2.68 gdebi is an FTBFS (hangs)

Bug #1931394 reported by Christian Ehrhardt 
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gdebi (Debian)
Fix Released
Unknown
gdebi (Ubuntu)
Fix Released
Undecided
Brian Murray

Bug Description

Ubuntu https://launchpad.net/ubuntu/+source/gdebi/0.9.5.7+nmu5 is an FTBFS
https://launchpadlibrarian.net/542966965/buildlog_ubuntu-impish-amd64.gdebi_0.9.5.7+nmu5_BUILDING.txt.gz

The same https://launchpad.net/ubuntu/+source/gdebi/0.9.5.7+nmu4 worked as it was builds against glib2.0 2.66 back in the day.

Debian still works as they have 2.66 still
https://buildd.debian.org/status/fetch.php?pkg=gdebi&arch=all&ver=0.9.5.7%2Bnmu5&stamp=1621453414&raw=0

At build time it is getting stuck until a timeout kills it:

Log:
```
running build_ext
test_simple (tests.test_gdebi_gtk.GDebiGtkTestCase) ... WARNING:root:Error loading logo gtk-icon-theme-error-quark: Icon 'gnome-mime-application-x-deb' not present in theme Yaru (0)

(setup.py:7825): Gtk-WARNING **: 05:55:50.408: Error loading theme icon 'dialog-error' for stock: Icon 'dialog-error' not present in theme Yaru
E: Build killed with signal TERM after 150 minutes of inactivity
```

This is reproducible locally and the process tree looks like:

F   UID     PID    PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
4     0   39842       0  20   0   9328  3000 do_wai Ss   pts/2      0:00 bash
0     0   40835   39842  20   0  22136 13032 do_wai S+   pts/2      0:00  \_ /usr/bin/perl /usr/bin/debuild -i -us -uc -b
0     0   40852   40835  20   0   7392   604 pipe_w S+   pts/2      0:00      \_ tee ../gdebi_0.9.5.7+nmu5_amd64.build
0     0   40853   40835  20   0  25328 16328 do_wai S+   pts/2      0:00      \_ /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc -ui -i -b
0     0   40891   40853  20   0   7764  1616 do_wai S+   pts/2      0:00          \_ /usr/bin/make -f debian/rules build
0     0   40892   40891  20   0  24356 15260 do_wai S+   pts/2      0:00              \_ /usr/bin/perl /usr/bin/dh build --with python3 --buildsystem pybuild
0     0   41533   40892  20   0   7764  1572 do_wai S+   pts/2      0:00                  \_ /usr/bin/make -f debian/rules override_dh_auto_test
0     0   41535   41533  20   0   2620  1320 do_wai S+   pts/2      0:00                      \_ /bin/sh /usr/bin/xvfb-run -a python3.9 setup.py test
4     0   41545   41535  20   0 1034648 37536 ep_pol Sl+ pts/2      0:00                          \_ Xvfb :99 -screen 0 1280x1024x24 -nolisten tcp -auth /tmp/xvfb-run.RlZdX8/Xauthority
0     0   41560   41535  20   0 1331396 131060 poll_s Sl+ pts/2     0:01                          \_ python3.9 setup.py test

From there the test is stuck.
Some debugging revealed that it does no more come back from:
GDebiGtkTestCase
 -> test_lintian
  -> GDebiGtk (init)
    -> gio_copy_in_place
      -> show_alert

That alert only happens because we run as root, but even if that is avoided
(e.g. by running as another user) then it blocks at the next message. E.g.
when failing to download.

But these blocking alerts are only secondary symptoms.

I've found that all issues come back to a check that seems wrong.
The test wants to copy a non-existing file into a temp path.
At least the current version of Gio.File hates this and errors out
  g-io-error-quark: Operation not supported (15)

Maybe Gio was more tolerant in the past, but checking a non existing
file makes no sense anyway. We can guard that step a bit better than all works.

A fix could look like:
--- /home/ubuntu/gdebi-0.9.5.7+nmu5/GDebi/GDebiGtk.py 2021-06-09 10:17:06.516869439 +0000
+++ /root/gdebi-0.9.5.7+nmu5/GDebi/GDebiGtk.py 2021-06-09 10:09:35.113662314 +0000
@@ -119,7 +119,8 @@
                                  self.on_window_main_drag_data_received)

         # Check file with gio
-        file = self.gio_copy_in_place(file)
+        if file != "" and os.path.exists(file):
+            file = self.gio_copy_in_place(file)

         #self.vte_terminal.set_font_from_string("monospace 10")
         self.cprogress = self.CacheProgressAdapter(self.progressbar_cache)

I've proposed the same to the project [1], but I'm unsure about the speed this
is picked up there.
I've also filed this in Debian for them to be aware when the 2.68 switch happens.

[1]: https://code.launchpad.net/~paelzer/gdebi/gdebi-fix-glib-2.68/+merge/403954
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989647

Related branches

summary: - FTBFS
+ With glib2 2.68 gdebi is an FTBFS (hangs)
tags: added: update-excuse
Changed in gdebi (Debian):
status: Unknown → New
Revision history for this message
Brian Murray (brian-murray) wrote :

I went ahead and uploaded this to Impish given that the version in the release pocket also FTBFS.

Changed in gdebi (Ubuntu):
assignee: nobody → Brian Murray (brian-murray)
status: New → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gdebi - 0.9.5.7+nmu5ubuntu1

---------------
gdebi (0.9.5.7+nmu5ubuntu1) impish; urgency=medium

  * GDebi/GDebiGtk.py: Don't call gio_copy_in_place if there is no path / uri
    being passed. Thanks to Christian Ehrhardt for the patch. (LP: #1931394)

 -- Brian Murray <email address hidden> Mon, 02 Aug 2021 09:51:14 -0700

Changed in gdebi (Ubuntu):
status: In Progress → Fix Released
Changed in gdebi (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.