Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gso...@packages.debian.org
Control: affects -1 + src:gsound
User: release.debian@packages.debian.org
Usertags: binnmu
nmu gsound_1.0.3-3.2 . armhf . unstable . -m "rebuild against libcanberra0t64"
This should unblock
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: clutter-gst-...@packages.debian.org
Control: affects -1 + src:clutter-gst-3.0
User: ftp.debian@packages.debian.org
Usertags: override
clutter-gst-3.0 is dead upstream, but cannot be removed immediately
due to reverse-dependencies
Source: plank
Version: 0.11.89-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Thanks for trying to address #1067764, but unfortunately the version that
was uploaded fails to build on all of the per-architecture buildds:
>
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: libj...@packages.debian.org
Control: affects -1 + src:libjcat
User: release.debian@packages.debian.org
Usertags: binnmu
nmu libjcat_0.2.0-2 . armel armhf . unstable . -m "rebuild against
libgpgme11t64"
Possibly not very high impact,
I think binNMUs for packages involved in
https://release.debian.org/transitions/html/auto-sphinxbase.html
would be useful. If I'm reading correctly, that would unblock ffmpeg
on armel/armhf (or at least get some way towards it), and ffmpeg is
involved in a bunch of other sub-transitions.
(I hope
On Tue, 26 Mar 2024 at 12:46:25 +, Simon McVittie wrote:
> valadoc is normally used to build developer-oriented API documentation
> in an Architecture: all package, in this case libplank-dev.
Sorry, of course that should have said: in this case libplank-doc.
smcv
Source: zeitgeist
Version: 1.0.4-5
Severity: wishlist
valadoc is normally used to build developer-oriented API documentation
in an Architecture: all package, in this case libzeitgeist-2.0-doc. It
has non-trivial dependencies that are part of a cycle, so we had to
disable it during the 64-bit
Source: rygel
Version: 0.42.5-1
Severity: wishlist
valadoc is normally used to build developer-oriented API documentation
in an Architecture: all package. It has non-trivial dependencies that
are part of a cycle, so we had to disable it during the 64-bit time_t
transition, which means rygel has
Source: plank
Version: 0.11.89-4.1
Severity: wishlist
valadoc is normally used to build developer-oriented API documentation
in an Architecture: all package, in this case libplank-dev. It has
non-trivial dependencies that are part of a cycle, so we had to disable
it during the 64-bit time_t
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ffm...@packages.debian.org
Control: affects -1 + src:ffmpeg
User: release.debian@packages.debian.org
Usertags: binnmu
Manual (bootstrap?) builds of ffmpeg on armel, armhf seem to have been done
with libglib2.0-0, which is depended on
It seems that some of the dependency chains for packages that are still
waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
default Java version for most architectures and Build-Depends on itself
(with an alternative dependency on openjdk-16, but that no longer exists).
Package: mugshot
Version: 0.4.3-1
Severity: important
Tags: bookworm sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs clutter
Control: block 996690 by -1
This package Recommends gir1.2-gtkclutter-1.0, which is no longer
maintained upstream (and has been
Source: clutter-gst-3.0
Version: 3.0.27-3
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
The build-dependency on libglib2.0-0 is no longer satisfiable in unstable
due to the 64-bit time_t
Source: gpick
Version: 0.2.6-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
gpick Build-Depends on:
debhelper-compat (= 13),
cmake,
libcairo2 (>=1.6),<---
On Sun, 24 Mar 2024 at 23:06:18 +0500, Andrey Rakhmatullin wrote:
> GLX/input_device_linuxevent.cpp: In member function ‘virtual void
> CL_InputDevice_LinuxEvent::keep_alive()’:
> GLX/input_device_linuxevent.cpp:269:72: error: ‘struct input_event’ has no
> member named ‘time’
> 269 |
>
On Sun, 24 Mar 2024 at 15:38:26 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
>
> >(Or of course porting libunwind to the remaining architectures would
> >be another obvious way that porters could address this.)
>
> Definitely. All three are valid possibilities
Control: tags -1 + pending
Control: forwarded -1 https://ftp-master.debian.org/new.html
On Mon, 27 Nov 2023 at 12:19:55 -0500, Jeremy Bícha wrote:
> FreeRDP 3.0.0 RC0 was just released. We should begin thinking about
> how we will handle its packaging.
Looks like Jeremy has uploaded an initial
On Sun, 24 Mar 2024 at 00:36:11 +, Thorsten Glaser wrote:
> libunwind-dev is not available for at least alpha, hurd-any,
> loong64, m68k, sparc64, x32.
>
> sysprof is a not unimportant part in the GNOME dependency chain
> (IIRC seeing it for weston) and part of the t64 transition, so
> having
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: roc-tool...@packages.debian.org, debian-...@lists.debian.org
Control: affects -1 + src:roc-toolkit
User: release.debian@packages.debian.org
Usertags: binnmu
Another binNMU suggestion for the 64-bit time_t transition. This one
would
sition has finished.
The others should be reverted after the relevant libraries become available
on the affected architectures.
smcv
>From c1de62b3c7b48f64df8f6c69ab9cb35fa9e775b8 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Fri, 22 Mar 2024 10:56:02 +
Subject: [PATCH 1/4] Only b
Package: debhelper
Version: 13.15
Severity: grave
Justification: renders package unusable
Control: block 1036884 by -1
debhelper 13.14.1 has:
Depends: autotools-dev, dh-autoreconf (>= 17~), dh-strip-nondeterminism (>=
0.028~), dpkg (>= 1.18.0~), dpkg-dev (>= 1.18.2~), dwz (>= 0.12.20190711),
Control: retitle -1 pulseaudio: FTBFS on x86: cpu-volume-test fails, segfault
in svolume_orc_test
Control: reassign -1 src:orc 1:0.4.38-1
Control: forwarded -1 https://gitlab.freedesktop.org/gstreamer/orc/-/issues/66
Control: tags 1067458 + ftbfs sid trixie
Control: merge 1067458 -1
Control:
lation of various build-dependencies, and skips production
of the -dev-doc package, but does not otherwise affect the package's
contents.
Thanks,
smcv
>From 21d265c1b839fcfa0933ddb963788b7f5f9662f1 Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Thu, 21 Mar 2024 17:29:31 +
Subject:
Control: tags -1 + moreinfo
On Thu, 21 Mar 2024 at 15:00:52 +0100, Christian Marillat wrote:
> I noticed this bug with the libopenshot-audio source and with
> armel, armh and powerpc architectures from buildd logs and my rebuild.
>
> I didn't pay attention for others sources, but I noticed that
Package: gnome-shell-extension-hard-disk-led
Version: 34-1
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46
As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is
Package: gnome-shell-extension-espresso
Version: 8-2
Severity: important
Tags: trixie sid upstream
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46
As with every 6-month GNOME Shell release cycle, extensions will need to
be updated for GNOME Shell 46, which is
Package: gnome-shell-extension-caffeine
Version: 48-1
Severity: important
Tags: trixie sid upstream patch
Forwarded: https://github.com/eonpatapon/gnome-shell-extension-caffeine/pull/317
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gnome-shell-46
As with every 6-month GNOME Shell
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: graph...@packages.debian.org, debian-...@lists.debian.org
Control: affects -1 + src:graphviz
User: release.debian@packages.debian.org
Usertags: binnmu
libgvc6_2.42.2-9_armel depends on libglib2.0-0t64 (the "new" side of
the 64-bit
On Wed, 20 Mar 2024 at 20:00:32 +, Thorsten Glaser wrote:
> Unfortunately, as with umockdev, I have no idea what is going on
> here… does it #undef _FILE_OFFSET_BITS or something?
Yes it does. padsp(1) is based on a LD_PRELOAD module similar to those
used in fakeroot, fakechroot, umockdev and
On Thu, 21 Mar 2024 at 14:13:38 +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 20, 2024 at 03:05:34AM +, Thorsten Glaser wrote:
> > cc -Ilibumockdev-preload.so.0.0.0.p -I. -I.. -fdiagnostics-color=always
> > -Wall -Winvalid-pch -std=gnu11 -Werror=missing-prototypes
> >
On Thu, 21 Mar 2024 at 15:45:13 +0500, Andrey Rakhmatullin wrote:
> On Wed, Mar 13, 2024 at 08:23:07AM +0100, Helge Deller wrote:
> > The patch below builds for me on the hppa platform.
> Unfortunately tests fail here with it in an armhf chroot, I don't know if
> it's generic or because the chroot
On Thu, 21 Mar 2024 at 11:49:22 +, Simon McVittie wrote:
> gst-plugins-base1.0 is currently unbuildable on armel and armhf due to
> gstreamer1.0 having been built before libdw1 transitioned to libdw1t64.
> Please consider:
>
> nmu gstreamer1.0_1.24.0-1 . armel armhf . unstabl
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gstreamer...@packages.debian.org, debian-...@lists.debian.org
Control: affects -1 + src:gstreamer1.0
User: release.debian@packages.debian.org
Usertags: binnmu
gst-plugins-base1.0 is currently unbuildable on armel and armhf due to
Control: retitle -1 gstreamer1.0: FTBFS: tests/check/libs/gstharness.c:
Received signal 11 (Segmentation fault)
On Wed, 13 Mar 2024 at 16:11:03 +0100, Lucas Nussbaum wrote:
> gstreamer1.0: FTBFS: gst-validate-1.0 Failed to execute child process
> ?gst-validate-1.0? (No such file or directory)
On Tue, 19 Mar 2024 at 22:55:31 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 22:25 Uhr schrieb Simon McVittie :
> > Yes, the library is renamed on all architectures. (On architectures where
> > the ABI didn't actually break, like amd64, it Provides the old name.)
>
On Tue, 19 Mar 2024 at 22:14:12 +0100, Matthias Klumpp wrote:
> Am Di., 19. März 2024 um 21:42 Uhr schrieb Simon McVittie :
> > libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
> > to be replaced by libgtk-3-0t64 after checking that the functions that
> >
Package: meld
Version: 3.22.1-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
meld is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect dependency
Source: gtk-d
Version: 3.10.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
libgtkd-3-0 has a hard-coded dependency on libgtk-3-0, which will need
to be replaced by libgtk-3-0t64 after
Package: gnome-subtitles
Version: 1.8-1
Severity: serious
Justification: 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
gnome-subtitles has a hard-coded dependency on libgtk-3-0, which needs to
be replaced with libgtk-3-0t64 as part of the 64-bit time_t transition.
Package: timekpr-next
Version: 0.5.4-1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
timekpr-next is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an
Package: syncthing-gtk
Version: 0.9.4.4+ds+git20221205+12a9702d29ab-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
syncthing-gtk is an Architecture: all package, but has a direct dependency
on
Package: exaile
Version: 4.1.3+dfsg-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
exaile is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect
Package: cpupower-gui
Version: 0.7.2-2.1
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
cpupower-gui is an Architecture: all package, but has a direct dependency
on libgtk-3-0, as well as an indirect dependency on
Package: clearlooks-phenix-theme
Version: 7.0.1-3
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
clearlooks-phenix-theme is an Architecture: all package, but has a
direct (versioned) dependency on libgtk-3-0.
On the
Package: bleachbit
Version: 4.6.0-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
bleachbit is an Architecture: all package, but has a direct dependency on
libgtk-3-0, as well as an indirect
Package: 0install
Version: 2.18-2
Severity: serious
Justification: blocker for 64-bit time_t transition
User: debian-...@lists.debian.org
Usertags: time-t
Control: block 1036884 by -1
Versions of 0install that have been rebuilt for the 64-bit time_t
transition (for example on amd64) have
Control: block 1036884 by -1
Control: block -1 by 1062840
On Sat, 03 Feb 2024 at 15:14:57 -0500, Jeremy Bícha wrote:
> dh-elpa is only used to build an Architecture: all package. Therefore,
> it is more correct to use Build-Depends-Indep instead of specifying
> specific architectures.
>
> We can
On Mon, 18 Mar 2024 at 09:12:36 +0100, Sebastian Ramacher wrote:
> arm-linux-gnueabihf-gcc -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g
> -Werror=implicit-function-declaration -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -g -O2
>
Control: tags -1 + moreinfo help
Control: severity -1 important
On Sun, 21 Jan 2024 at 13:17:45 +, Simon McVittie wrote:
> On Tue, 16 Jan 2024 at 20:37:49 +0100, Lucas Nussbaum wrote:
> > > 26/28 xdg-desktop-portal:pytest / pytest test_inputcaptureFAIL
> > &
Package: libruby
Version: 1:3.1
Severity: serious
Justification: blocker for 64-bit time_t transition
X-Debbugs-Cc: z...@debian.org, debian-...@lists.debian.org
Control: affects -1 + src:graphviz src:vala
Now that libruby3.1t64 has reached unstable, libruby is uninstallable on
the architectures
#1066821.
smcv
>From e36a8c4784278ccfb32d112b57cd2260fedb2e3c Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Sun, 17 Mar 2024 13:21:29 +
Subject: [PATCH 2/3] d/libaprutil1t64.symbols: Fix name of t64 binary package
It's libaprutil1t64 (with the "t"), not libaprutil164.
Close
Source: gmpc
Severity: important
Tags: upstream wontfix
X-Debbugs-Cc: gmpc-plug...@packages.debian.org
It appears that gmpc no longer has any sort of upstream developer.
https://github.com/DaveDavenport/gmpc is specifically labelled as
unmaintained, https://repo.or.cz/w/gmpc.git hasn't been
On Thu, 14 Mar 2024 at 22:03:57 -0700, Otto Kekäläinen wrote:
> For example curl isn't building on armel/armhf now and numerous packages that
> depend of curl are not building on armel/armhf.
I believe a maintainer upload or NMU of #1066981 and #1066982 would
now be enough to unblock curl, which
and should be reverted when the transition has finished.
Thanks,
smcv
>From bc8cd5d7a40c8acaf2c164c538b6c0b07f2d3dab Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date: Sat, 16 Mar 2024 11:36:05 +
Subject: [PATCH 2/3] Temporarily disable LDAP support on 32-bit non-x86
This makes offic
features that are unlikely to be
used by game engines. When I'm back at work I'd be happy to look at
contributing similar build-profiles to disable other optional bits if
there is interest.)
smcv
>From ae094c1e4b2b0ec943f39f2b6a6176091af20d33 Mon Sep 17 00:00:00 2001
From: Simon McVittie
D
Control: clone -1 -2
Control: retitle -2 gi-compile-repository: generates incorrect typelib when
cross-compiling with different type sizes
Control: reassign -2 libglib2.0-dev 2.79.3-1
Control: tags -2 = experimental
On Fri, 15 Mar 2024 at 07:48:17 +, Simon McVittie wrote:
> When it conve
Package: gobject-introspection
Version: 1.78.1-16
Severity: serious
Justification: results in misbuilt packages
X-Debbugs-Cc: debian-cr...@lists.debian.org
When it converts GIR XML to binary typelib files, g-ir-compiler replaces
abstract types such as int and gsize (size_t) with concrete types
atch. I've verified that it compiles
successfully in an armhf porterbox chroot (without ssh-askpass-gnome)
and on amd64 (with ssh-askpass-gnome), but I haven't otherwise tested it.
Thanks,
smcv
>From bbefe785a6ab567677af77ccd12b1fbb59a42d8d Mon Sep 17 00:00:00 2001
From: Simon McVittie
Date
Package: at-spi2-core
Version: 2.51.90-3
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org
Tags: patch
at-spi2-core has a circular build-dependency on itself when tests are
enabled, which makes its build-dependencies unsatisfiable (libglib2.0-dev
depends on libglib2.0-0t64, but
On Sat, 18 Mar 2023 at 14:46:47 +0100, Andrea Bolognani wrote:
> In other words, upstream developers have retroactively added symbols
> (fuse_new_31) to existing symbol groups (FUSE_3.1).
...
> really this looks like an upstream
> bug in my opinion: even if the function was present in the source
>
On Tue, 12 Mar 2024 at 23:13:30 -0500, Steven Robbins wrote:
> I checked the build logs for cargo and noticed that most architectures have
> been built on the buildds. All release arches except armel & armhf. How is
> it that these two have build dep installability problems but others do not?
On Tue, 12 Mar 2024 at 22:30:01 +0100, Michael Biebl wrote:
> On Wed, 9 Aug 2023 04:05:43 +0200 Bertram Felgenhauer wrote:
> > My speculation is that this happened while satisfying dependencies for
> > a third party i386 application. That meant installing required 32 bit
> > libraries, and one of
On Sun, 25 Feb 2024 at 20:36:58 +0100, Lucas Nussbaum wrote:
> > FAIL: test_black (devscripts.test.test_black.BlackTestCase.test_black)
> > Test: Run black code formatter on Python source code.
I think lint checks like this one should be run by contributors and CI
when targeting the main branch,
Control: block -1 by 1065787 1066049
One dependency chain that is blocking a lot of rebuilds right now is
this one:
... => curl -> stunnel4 -> python-cryptography => cargo => ...
key: => mandatory dependency
-> nocheck dependency
In the medium term, cargo needs
On Mon, 11 Mar 2024 at 20:09:06 +, Simon McVittie wrote:
> Thanks for proposing this, but I think these should be ifneq instead
> of ifeq
Actually, this patch also still allowed dh_auto_test to run on the
time64-affected architectures, which would presumably fail because the
Control: tags -1 + fixed-upstream
Control: block -1 by 1061616
Control: retitle 1061616 pixman: New upstream version 0.43.4
On Mon, 29 Jan 2024 at 10:23:45 +, Simon McVittie wrote:
> On Mon, 29 Jan 2024 at 05:13:59 +, Gayathri Berli wrote:
> > we found out that while
>
On Mon, 11 Mar 2024 at 19:54:00 +0100, Mattia Rizzolo wrote:
> +ifeq ($(DEB_HOST_ARCH_BITS)$(filter i386,$(DEB_HOST_ARCH_CPU)),32)
> execute_before_dh_auto_test:
> env PYTHONPATH='$(CURDIR)/debian/tests/python' \
> python3 -B -u -m struntime \
>
On Mon, 11 Mar 2024 at 08:13:30 -0400, Jeremy Bícha wrote:
> Although Debian has not yet gotten to pygobject in the time_t
> transition for armel/armhf, Ubuntu has and experienced a build test
> failure in test_gi.py for the test_time_t tests which I believe are
> using functions in glib2.0. I
On Sat, 09 Mar 2024 at 12:29:26 +0100, Sebastian Ramacher wrote:
> linux_input.c: In function ‘translate_event’:
> linux_input.c:761:28: error: ‘const struct input_event’ has no member named
> ‘time’
> 761 | devt->timestamp = levt->time;
> |^~
This seems
Control: retitle -1 librsvg: reftest regression for rtl-tspan with pango1.0
1.52.1: 2655 pixels differ from reference
Control: severity -1 important
On Sun, 10 Mar 2024 at 14:45:24 +, Simon McVittie wrote:
> For now, I'm testing an upload that will temporarily disable this test,
>
Source: shared-mime-info
Version: 2.4-1
Severity: wishlist
Tags: patch
In my experience it is usually easier to work with source packages in a VCS
if their upstream source code is also present in the same VCS, and is
merged into the packaging branch (the same layout used by the GNOME,
Perl,
Control: tags -1 + pending
On Sun, 10 Mar 2024 at 14:03:18 +, Simon McVittie wrote:
> On Sun, 10 Mar 2024 at 13:12:57 +0100, Sebastian Ramacher wrote:
> > rtl-tspan: 2655 pixels changed with maximum difference of 112
>
> This appears to have been caused by upgrading pango
On Sun, 10 Mar 2024 at 13:12:57 +0100, Sebastian Ramacher wrote:
> rtl-tspan: 2655 pixels changed with maximum difference of 112
This appears to have been caused by upgrading pango1.0 from 1.52.0
to 1.52.1. The librsvg test suite is unfortunately very sensitive to
differences in the exact version
Control: block 1036884 by -1
On Sun, 10 Mar 2024 at 10:37:51 +0100, Aurelien Jarno wrote:
> weston fails to build in unstable since the upload of neatvnc in version
> 8.0. From my build log on amd64:
...
> | Dependency neatvnc found: NO found 0.8.0 but need: '< 0.8.0' ; matched: '>=
> 0.7.0'
Package: libneatvnc0
Version: 0.8.0+dfsg-1
Severity: important
Justification: Policy 8.6.2
Tags: upstream
X-Debbugs-Cc: wes...@packages.debian.org, way...@packages.debian.org
libneatvnc 0.8.0 removes a public function from its API/ABI:
│ -const char* nvnc_client_get_hostname(const struct
Control: forcemerge 1065709 1057620
On Sat, 09 Mar 2024 at 11:06:46 +, Simon McVittie wrote:
> In a GNOME Wayland session, with qtwayland5 installed:
>
> $ doomsday
> QSocketNotifier: Can only be used with threads started with QThread
> [1]381459 segmentation fau
object
On Sun, 04 Feb 2024 at 12:31:35 +, Simon McVittie wrote:
> When I try the command above, on GNOME in Wayland mode, I get what
> appears to be a different crash
Now reported separately as #1065709, which I now see was a duplicate
of #1057620 (I'll merge them).
> which makes
Package: doomsday
Version: 2.3.1+ds1-1+b2
Severity: important
In a GNOME Wayland session, with qtwayland5 installed:
$ doomsday
QSocketNotifier: Can only be used with threads started with QThread
[1]381459 segmentation fault (core dumped) doomsday
Backtrace:
#0 0x7f9dc2c3ee83 in
Control: reassign -1 aptitude,libgtk2.0-0t64
Control: tags -1 + moreinfo
On Thu, 07 Mar 2024 at 16:10:17 +0100, Vincent Lefevre wrote:
> During an upgrade with aptitude:
>
> dpkg: dependency problems prevent removal of libgtk2.0-common:
> libgtk2.0-bin depends on libgtk2.0-common.
>
On Wed, 06 Mar 2024 at 21:40:10 +0100, Arnaldo Pirrone wrote:
> libgtk-3-0t64 3.24.41-1.1 is breaking libgtk-3-0
This is part of the ongoing 64-bit time_t transition (for details please
see a large proportion of recent traffic on the debian-devel mailing
list). Please be patient: sometimes
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach
An equivalent glib2.0 change
On Mon, 04 Mar 2024 at 20:21:56 +, Markus Koller wrote:
> So it's trying to use the `DND_IN_DRAG` cursor at [1].
That's not a concrete cursor name, it's an alias in libmutter. Depending
on version of libmutter, it could end up referring to either "dnd-none"
(which is no longer provided) or
Copying context from elsewhere in the thread, Sam Hartman wrote:
> Are there solutions in the space of having glib2.0-0 continue to exist
> as a package depended on by glib2.0-0t64 or depending on the new library
> allowing you to replace the postrm?
to which I replied:
If libglib2.0-0 continues
Source: libphonenumber
Version: 8.12.57+ds-4.1
Severity: important
X-Debbugs-Cc: vor...@debian.org
After the time64 transition, libphonenumber8t64 Provides
libphonenumber8t64-protobuf with no version suffix. This appears to be
caused by the rename of libprotobuf32 to libprotobuf32t64: the regex
On Sun, 03 Mar 2024 at 17:34:25 +0100, Harald Dunkel wrote:
> I got a few messages in kern.log:
>
> 2024-03-03T17:10:55.375204+01:00 cecil kernel: traps: at-spi-bus-laun[2238]
> trap int3 ip:7f52523f5587 sp:7ffded761730 error:0 in
> libglib-2.0.so.0.7800.4[7f52523b1000+99000]
Please try
Control: severity -1 important
On Tue, 20 Feb 2024 at 23:15:09 +0100, Matthias Klose wrote:
> On 20.02.24 22:50, Simon McVittie wrote:
> > If gobject-introspection explicitly depended on gobject-introspection-bin
> > by name (not just via a virtual package), would that hel
Package: low-memory-monitor
Version: 2.1-2
Severity: minor
low-memory-monitor appears to be an activatable D-Bus service with no
particular C/C++ ABI. If this is the case, then it could be marked
Multi-Arch: foreign (since D-Bus is normally an architecture-independent
protocol if the interface
On Sat, 02 Mar 2024 at 20:19:47 +, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach.
I've uploaded this to experimental, inc
Control: clone -1 -2
Control: reassign -2 gobject-introspection 1.78.1-15
Control: retitle -2 dh_girepository: generates unwanted dependency on
libgirepository1.0-dev if that package is installed
Control: severity -2 important
On Sun, 03 Mar 2024 at 00:40:52 +0100, Samuel Thibault wrote:
>
On Sat, 02 Mar 2024 at 20:19:50 +, Simon McVittie wrote:
> I am currently downloading all versions of libglib2.0-0 that have
> existed on amd64 as tracked by snapshot.d.o. My plan is to extract their
> DEBIAN/postrm, import them into a git branch and go back through the
> hist
undreds of thousands of systems, the expectation is that I must not
upload without sufficient testing. So, my intention is to do my best,
and then invite other developers to take responsibility for a better,
higher-version-numbered upload with different timing if they prefer.
On Fri, 01 Mar 2024 at 1
Control: tags -1 + pending
On Sat, 02 Mar 2024 at 11:51:26 +0100, Sebastian Ramacher wrote:
> Please add dpkg-dev (>= 1.22.5) to Build-Depends
This is already fixed in git, but we were told not to upload that version
yet, to avoid interfering with the migration of the NMU currently
in unstable
On Fri, 01 Mar 2024 at 13:21:51 +0100, Christoph Berg wrote:
> > Possible solution: other ideas?
>
> Make glib2.0-t64 use a different cache filename?
I'm not happy about the idea of introducing long-term divergence in
the upstream code as a result of a Debian-specific packaging problem;
I think
Package: tech-ctte
Severity: normal
X-Debbugs-Cc: debian-d...@lists.debian.org, debian-gtk-gn...@lists.debian.org,
vor...@debian.org
I'm requesting advice from the tech-ctte (or anyone else with relevant
knowledge, e.g. the dpkg team or the drivers of the time64 transition)
on how to resolve
On Thu, 29 Feb 2024 at 14:00:02 +0100, Christoph Anton Mitterer wrote:
> So the advise for "end users" is to simply re-install one package of
> both groups and everything should be cleaned up again?
The advice for "end users" would be don't run unstable or experimental,
and wait for maintainers
On Thu, 29 Feb 2024 at 08:40:28 -0300, Leandro Cunha wrote:
> Jeremy uploaded glib 2.0 to experimental which fixes such problems
libglib2.0-0t64 in experimental does not contain any changes that would
intentionally fix this.
Upgrading to the experimental libglib2.0-0t64 probably fixes this as a
On Thu, 29 Feb 2024 at 10:33:17 +, Simon McVittie wrote:
> Yes, the workaround for this is to reinstall any package that carries
> GSettings schemas. gsettings-desktop-schemas is a common one, but actually
> any package that has files in /usr/share/glib-2.0/schemas/ should be
>
Control: retitle -1 libglib2.0-0t64: transition from libglib2.0-0 breaks
GSettings, GIO modules
Ash Joubert wrote:
> Workaround for me was to reinstall gsettings-desktop-schemas:
>
> # apt-get reinstall gsettings-desktop-schemas
Yes, the workaround for this is to reinstall any package that
On Tue, 27 Feb 2024 at 23:07:33 +0100, Matthias Klose wrote:
> On 23.02.24 22:10, Jeremy Bícha wrote:
> > Since glib and gobject-introspection have migrated out of
> > noble-proposed, is there still a need to keep this bug open?
>
> Suppose you would start again building glib2.0 (and depending
(Sorry, I thought I had sent this earlier.)
On Tue, 27 Feb 2024 at 08:39:05 -0500, Jeremy Bícha wrote:
> On Tue, Feb 27, 2024 at 5:33 AM Simon McVittie wrote:
> > If that's the case, then we should have transitional packages with those
> > names that just depend on libpro
101 - 200 of 7745 matches
Mail list logo
