Bug#920024: Doesn't parse package architectures correctly when any-amd64 is used (etc.)
Quoting Johannes Schauer (2019-03-27 06:05:51)
> On Tue, 22 Jan 2019 00:44:03 +0100 Raphael Hertzog wrote:
> > On Mon, 21 Jan 2019, Steve McIntyre wrote:
> > > I've just been looking at the details for sbsigntool
> > > (https://tracker.debian.org/pkg/sbsigntool) It looks like the tracker
> > > code is confused by the architecture list for sbsigntool:
> > >
> > > Architecture: any-amd64 any-i386 arm64 armhf
> > >
> > > and is just showing
> > >
> > > arch: arm64 armhf
> > >
> > > which is quite confusing!
> >
> > Yeah, the data model includes a list of architectures by source package
> > and the parsing keeps only entries which are real architectures, the
> > architecture wildcards are just not handled.
> >
> > Extract from distro_tracker/core/retrieve_data.py:
> >
> > # Convert the parsed data into corresponding model instances
> > if 'architectures' in entry:
> > # Map the list of architecture names to their objects
> > # Discards any unknown architectures.
> > entry['architectures'] = Architecture.objects.filter(
> > name__in=entry['architectures'])
> >
> > I think we don't have any code in the tracker to handle architecture
> > wildcard
> > and try to do any mapping or expansion. Given the data model, that's we
> > should
> > aim to do here. Creating all the possible wildcards would be wrong, instead
> > we
> > want to process the list of architectures that the tracker knows of and see
> > whether it matches the wildcards listed in the source package field.
>
> Feel free to use this Debian architecture wildcard matching implementation:
>
> https://gitlab.mister-muffin.de/josch/debarchwildcardtest/blob/master/debarch.py
>
> In my opinion this code should really live in python-debian but hasn't been
> put there yet (#771058).
starting with python3-debian 0.1.45 you can do this:
from debian.debian_support import DpkgArchTable
arch_table = DpkgArchTable.load_arch_table()
print(arch_table.matches_architecture("amd64", "linux-any"))
if tracker is running on stable, then maybe this bug can be fixed after the
bookworm release?
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#984879:
1234
Bug#1019375: Not started under wayland/plasma
13 septembre 2022 20:33 "Axel Beckert" a écrit > Didier 'OdyX' Raboud wrote: >> https://bugs.debian.org/855868 suggests that a similar script as >> present in /etc/Xsession.d should be placed in >> /usr/lib/systemd/user-environment-generators/ for systemd/wayland >> systems to benefit from unburden-home-dir. > > So this is only needed in the combination of Wayland AND systemd? That > kinda sounds weird. My understanding is rather "Wayland does not use Xsession.d, and systemd provides an alternative to this Xsession.d mechanism that would run on these systems. I have not found a Wayland-specific way. >> As a temporary local configuration, I've done this; >> >> # mkdir -p /etc/systemd/user-environment-generators/ >> # cp /etc/X11/Xsession.d/95unburden-home-dir >> /etc/systemd/user-environment-generators/ > > Thanks for that tip. Is there a reason why you've copied it instead of > e.g. a symlink? Quick test only, good point. Of course I forgot to chmod +x. But it didn't work :-( Re-reading the doc, it seems that doing this would be an abuse of that user-environment-generators mechanism. The "right" systemd mechanism seems to be a Type=oneshot /lib/systemd/user/*.service with a Slice=session.slice. >> Will report back if that helps. It did not :-). I'll try with a user service and report again. If it works I'll propose a patch. Best, OdyX
Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.10.0-8-amd64
Hello, An upstream patch has been released [1] [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0-rc5=6b04ce966a738ecdd9294c9593e48513c0dc90aa
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
On the other hand, the fix has been known since 2019 and looks like a prime problem for an LTS newbie volunteer like me. I have created the fix based on the Debian/bzip2 repo, the fix is in the debian/buster branch. git clone http://digon.foursquare.net/debian-buster-bzip2/.git I have tested it on a 32bit buster, and it works on +2g files. I do not have privileges to push this to any server yet, so feel free to tweak the changelog and claim it as your own, whoever wishes to upload it. - Chris On Tue, Sep 13, 2022 at 04:46:14PM +0200, Sylvain Beucler wrote: > Hi, > > IIUC this is about fixing 2 non-security bugs, that were introduced prior to > buster's initial release. > > I personally don't think this fits the LTS project scope. > Maybe other LTS members will have a different opinion. > > Cheers! > Sylvain Beucler > Debian LTS Team > > On 13/09/2022 15:27, Santiago R.R. wrote: > > El 10/09/22 a las 19:11, Adam D. Barratt escribió: > > > On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: > > > > Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 > > > > CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. > > > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 > > > > > > > > I've uploaded a fixed version to unstable yesterday. It would be > > > > great > > > > to fix it also in buster. Please, consider the attached debdiff. > > > > Would it be OK for you to upload it? > > > > > > > > > > Apologies for apparently letting this sit unanswered. (FTR there was a > > > reply from a non-SRM member 18 months ago.) > > > > And I am sorry I missed that answer. > > > > > > > > The final point release for buster has now happened, so any further > > > updates to packages in buster will need to be handled via LTS. I'm > > > therefore going to close this request now. > > [snip] > > > > I am forwarding this to the LTS folks, so they can decide about this > > change.
Bug#1017996: dpkg: please provide `--force-really-unsafe-io` (or similar) option
Control: forcemerge 985888 -1 On Tue, 2022-08-23 at 22:40:37 +0200, Ansgar wrote: > Package: dpkg > Version: 1.21.9 > Severity: wishlist > Tags: upstream d-i > please reconsider to provide a `--force-really-unsafe-io` (or similar) > option that skips the calls to `fsync()` & friends in dpkg. I think I've mentioned this elsewhere, but the main blocker has been lack of database taint tracking support. I do have a draft branch for a --force-reckless-io. > I tried installing a larger package set (in stable), including > texlive-full, KDE, GCC and other packages. It took: > > Default dpkg: ~4h10m = 250m > --force-unsafe-io: ~2h20m = 140m > eatmydata: ~22m > > So skipping all fsync() calls provides a speedup of 11 compared to > dpkg's defaults and still 6 compared to --force-unsafe-io. This is a > very noticable change. All fsync()s from dpkg, which are not necessarily all fsync()s performed indirectly by maintscripts/triggers. Guillem
Bug#1017908: dpkg: Setting to change the diff tool to view conffile difference
Control: forcemerge 313204 -1 On Mon, 2022-08-22 at 11:41:19 +0200, Axel Beckert wrote: > Package: dpkg > Version: 1.21.9 > Severity: wishlist > it would be nice if there would be a setting (or environment variable or > interactive option) to use a different tool than "diff" to view conffile > differences. > > This would add the possibility to e.g. use colorized diffs as provided > by tools like colordiff, "dwdiff -c" or icdiff which allows to review > changes more easily (like the adduser.conf changes which came in today). > > P.S.: I've looked and searched through the man pages of dpkg(1) and > dpkg.cfg(5) but found no such setting, hence the wishlist bug report. Yeah, I've been meaning to add this, I just need to define a syntax so that the arguments can be specified independently of the tool. Merging with the older requests. Thanks, Guillem
Bug#1019544: Additional Information
As there were several changes in 5.10.140 to the kernel I/O code which could be the cause of my issue, I downloaded the vanilla source code for the 5.10.139 kernel and built it using my Debian kernel config from /boot. I installed the resulting kernel and kernel headers and DKMS built the required ZFS modules. Upon rebooting, all my ZFS pools are working as expected. In particular, the main pool that consistently showed six missing drives (A1-A6) under 5.10.140 is now showing all drives as online, just as it does with 5.10.136-1. In total, this system has 48 3.5" 7200 RPM SATA drives, two 1.92TB Samsung enterprise SATA SSDs, and three NVMe SSDs. The impacted drives are 16TB 3.5" drives, which are in two 4U DS4246 JBOD enclosures, and attached to a Dell R730xd server via an LSI 9207-8e HBA running P20 firmware in IT mode. I'm running ZFS 2.1.5 from bullseye-backports. Note that SMART data for the impacted drives is normal with no bad sectors. The only change I made was booting into a different kernel. Otherwise, it's running all the updates from the 11.5 point release. I will try to bisect 5.10.140 tomorrow to determine more precisely which commit(s) are causing my issue. NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 A1 ONLINE 0 0 0 A2 ONLINE 0 0 0 A3 ONLINE 0 0 0 A4 ONLINE 0 0 0 A5 ONLINE 0 0 0 A6 ONLINE 0 0 0 A7 ONLINE 0 0 0 A8 ONLINE 0 0 0 A9 ONLINE 0 0 0 A10 ONLINE 0 0 0 A11 ONLINE 0 0 0 A12 ONLINE 0 0 0 special mirror-1 ONLINE 0 0 0 nvme-HP_SSD_EX920_1TB_HBSE48481800144-part1 ONLINE 0 0 0 nvme-HP_SSD_EX920_1TB_HBSE48481800847-part1 ONLINE 0 0 0 logs mirror-2 ONLINE 0 0 0 nvme-HP_SSD_EX920_1TB_HBSE48481800144-part2 ONLINE 0 0 0
Bug#1019565: dpkg: incorrect profile in .dsc's Build-Depends if multiline value in d/control with profiles
Hi! On Mon, 2022-09-12 at 07:50:51 +0200, Fab Stz wrote: > Package: dpkg > Version: 1.20.12 > Severity: normal >* What led up to the situation? > > Have a package for which in debian/control there is this: > > Build-Depends: debhelper-compat (= 13), >android-sdk-build-tools > > > > , > > Note the fact that the build profiles are on several lines, and not on the > same line as the package name. >* What was the outcome of this action? > > .dsc then contains a faulty profile. Note the "<<" and ">>" in the line. > > Build-Depends: debhelper-compat (= 13), android-sdk-build-tools < android-6.4.armeabi-v7a pkg.qt-android-6.4.systemsdk> android-6.4.arm64-v8a pkg.qt-android-6.4.systemsdk> pkg.qt-android-6.4.systemsdk> android-6.4.systemsdk>> I've fixed this now locally, by converting the field values to a single line before parsing, and will be part of my next push targeting 1.21.10. > This value is not correct and makes other tools fail: > - `dpkg-source -b` will report > E: Problem parsing dependency: Build-Depends That's not an error message from dpkg-source, I'd assume that's apt complaining. Thanks, Guillem
Bug#1019693: dpkg-buildpackage: fails with unknown sequence when including missing file
Control: reassign -1 debhelper On Tue, 2022-09-13 at 15:50:07 +0200, Fab Stz wrote: > Package: dpkg-dev > Version: 1.29.9 > Severity: normal > File: /usr/bin/dpkg-buildpackage > This may be a regression because I don't have this problem with 1.20.12 which > is on bullseye. > > > When in debian/rules, I include a file that doesn't exists, dpkg will try to > run > > dh /path/to/missing/file > > which leads to this failure & error: > > dh: error: unknown sequence/path/to/missing/file (choose from: binary binary- > arch binary-indep build build-arch build-indep clean install install-arch > install-indep) > > > for example, in your debian/rules, at the top, put > > -include /path/to/missing/file > > then, run dpkg-buildpackage This seems like an issue with debhelper, if at all. As dpkg-buildpackage does not call dh directly, debian/rules does. Reassigning. Thanks, Guillem
Bug#1019688: unace FTCBFS: uses the build architecture compiler
Hi! On Sun, 2022-09-11 at 12:29:41 +0200, Helmut Grohne wrote: > Source: unace > Version: 1.2b-21 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > your -21 upload broke cross building by adding CC=$(CC) without > initializing $(CC) properly. As far as I understand it, you deliberately > added it to override the upstream choice (e.g. for supporting clang > builds). Unfortunately, you failed to add proper initialization. > Possibly, you thought that buildtools.mk was part of default.mk so that > was sufficient, but it is not as of today. Cannot recall what was the train of thought there TBH. :/ > Please either include it or > change default.mk in dpkg. I'm attaching a patch for the former for your > convenience. I'm afraid the builtools.mk was not added to default.mk on purpose, to avoid breakage. I've now added this commit to the dpkg-build-api branch and to the spec on the wiki: https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/perl-Dpkg-BuildAPI=cddecf191ed4c50536b625e4e370d733b083bf54 In any case, thanks! I've merged your patch and I'm uploading a fixed package right away. [ Would be nice to have cross building status on DDPO or the UDD dashboard, as that's the main reason I've missed this. :/ ] Regards, Guillem
Bug#1017944: Another reproduction of #1017944
On Sun, 11 Sep 2022 15:55:00 -0700 Elliott Mitchell wrote: > ... another > potential workaround is to add: > > deb https://snapshot.debian.org/archive/debian/20220801T032804Z/ bullseye main > > To /etc/apt/sources.list, then *hold* the GRUB packages at 2.04-20. A more recent version (grub-xen-bin 2.06-3~deb10u1) which works is in buster: deb http://debian.anexia.at/debian/ buster contrib non-free main
Bug#1019718: nrpe-ng: remote check_dns fails - change in nslookup behavior
Package: nrpe-ng
Version: 0.2.0-1
Severity: normal
Dear Maintainer,
I have a setup in which nrpe-ng is used to remotely check DNS
connectivity using check_dns. That is:
Host A (monitoring):
- Installed: nagios4, nrpe-ng
- IP address: 192.0.2.1
Host B (monitored):
- Installed: nrpe-ng, monitoring-plugins-standard, bind9-dnsutils
- IP address: 192.0.2.2
Host C (monitored through host B):
- Installed: bind9
- IP address: 192.0.2.3
- Configured to answer authoritatively for example.com on port 53.
nrpe
over HTTPS DNS
Host A --> Host B -> Host C
When nrpe-ng is running on host B, and host A runs the following, this
is the result:
$ /usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a
example.com 192.0.2.3 0.1 1.0
DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address
With some help over at the bind-users mailing list [1], I discovered
that nrpe-ng closes stdin when launching the command [2], and the new
version of nslookup (invoked by check_dns) has issues when stdin is
closed [3].
Redirecting stdin to /dev/null fixes the issue:
$ diff -u /usr/lib/python3/dist-packages/nrpe_ng/commands.py{.old,}
--- /usr/lib/python3/dist-packages/nrpe_ng/commands.py.old 2017-08-08
13:05:02.0 -0600
+++ /usr/lib/python3/dist-packages/nrpe_ng/commands.py 2022-09-13
17:00:36.767239885 -0600
@@ -85,6 +85,7 @@
proc = tornado.process.Subprocess(
run_args,
+stdin=subprocess.DEVNULL,
stdout=tornado.process.Subprocess.STREAM,
close_fds=True,
env=env)
Thanks,
Casey
[1] https://lists.isc.org/pipermail/bind-users/2022-September/10.html
[2] https://github.com/bootc/nrpe-ng/blob/master/nrpe_ng/commands.py#L86
[3] https://github.com/libuv/libuv/blob/v1.x/src/unix/core.c#L602
-- System Information:
Debian Release: 11.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages nrpe-ng depends on:
ii adduser3.118
ii init-system-helpers1.60
ii lsb-base 11.1.0
ii python33.9.2-3
ii python3-daemon 2.2.4-1.1
ii python3-pkg-resources 52.0.0-4
ii python3-requests 2.25.1+dfsg-2
ii python3-tornado6.1.0-1+b1
ii ssl-cert 1.1.0+nmu1
nrpe-ng recommends no packages.
nrpe-ng suggests no packages.
-- Configuration Files:
/etc/nagios/nrpe-ng.cfg changed [not included]
-- no debconf information
Bug#1019348: pidgin: after upgrading to libglib2.0-0, Pidgin crashes when I close a group chat
On Wed, 2022-09-07 at 18:30 +0200, Jeremyp3 wrote:
> Since updating libglib-2.0-0 to 2.73.3-3, pidgin crashes as soon as I
> close a group chat. I noticed this bug only on external plugins. the bug only
> occurs on group conversations. not in discussion with a contact
I am having this issue too, but it happens with all conversation
windows not just group conversations.
Here is the short backtrace, full log attached.
Thread 1 "pidgin" received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7f5ee739a00e "GLib", log_level=G_LOG_LEVEL_ERROR,
format=, args=) at ../../../glib/gmessages.c:1424
1424../../../glib/gmessages.c: No such file or directory.
#0 g_logv (log_domain=0x7f5ee739a00e "GLib", log_level=G_LOG_LEVEL_ERROR,
format=, args=) at ../../../glib/gmessages.c:1424
#1 0x7f5ee734cfef in g_log (log_domain=log_domain@entry=0x7f5ee739a00e
"GLib", log_level=log_level@entry=G_LOG_LEVEL_ERROR,
format=format@entry=0x7f5ee73a4e40 "%s: failed to allocate %lu bytes") at
../../../glib/gmessages.c:1462
#2 0x7f5ee734b67a in g_malloc0 (n_bytes=n_bytes@entry=11862534711660) at
../../../glib/gmem.c:162
#3 0x7f5ee734b7b6 in g_malloc0_n (n_blocks=n_blocks@entry=2965633677915,
n_block_bytes=n_block_bytes@entry=4) at ../../../glib/gmem.c:389
#4 0x7f5ee7331569 in g_hash_table_resize (hash_table=0x564fb1567240 =
{...}) at ../../../glib/ghash.c:884
#5 0x7f5ee733352e in g_hash_table_destroy (hash_table=0x564fb1567240 =
{...}) at ../../../glib/ghash.c:1515
#6 0x564fae90bc33 in gtk_imhtml_finalize (object=0x564fb0e56b20
[GtkIMHtml]) at ../../pidgin/gtkimhtml.c:1503
#7 0x7f5ee74424e7 in g_object_unref (_object=) at
../../../gobject/gobject.c:3905
#8 g_object_unref (_object=0x564fb0e56b20) at ../../../gobject/gobject.c:3780
#9 0x7f5ee7443ecf in g_object_notify_by_spec_internal (pspec=, object=0x564fb0e56b20 [GtkIMHtml]) at ../../../gobject/gobject.c:1548
#10 g_object_notify (object=object@entry=0x564fb0e56b20 [GtkIMHtml],
property_name=property_name@entry=0x7f5ee7aeae03 "buffer") at
../../../gobject/gobject.c:1594
#11 0x7f5ee79f4579 in IA__gtk_text_view_set_buffer
(text_view=0x564fb0e56b20 [GtkIMHtml], buffer=0x7fffcf8edcb0
[-g-type-private--IFaceHolder]) at ../../../../gtk/gtktextview.c:1507
#12 0x7f5ee79f79fd in get_buffer (text_view=0x564fb0e56b20 [GtkIMHtml]) at
../../../../gtk/gtktextview.c:1523
#13 IA__gtk_text_view_get_buffer (text_view=0x564fb0e56b20 [GtkIMHtml]) at
../../../../gtk/gtktextview.c:1545
#14 0x7f5ee59513a1 in spellchk_free (spell=0x564fb1bb6fb0) at
../../../pidgin/plugins/spellchk.c:292
#15 0x7f5ee73250af in g_datalist_clear (datalist=) at
../../../glib/gdataset.c:276
#16 0x7f5ee74424e7 in g_object_unref (_object=) at
../../../gobject/gobject.c:3905
#17 g_object_unref (_object=0x564fb0e56b20) at ../../../gobject/gobject.c:3780
#18 0x7f5ee799b600 in gtk_scrolled_window_forall (container=0x564fb1d13350
[GtkScrolledWindow], include_internals=0, callback=0x7f5ee7a57410
, callback_data=0x0) at
../../../../gtk/gtkscrolledwindow.c:1082
#19 0x7f5ee78bb437 in gtk_container_destroy (object=0x564fb1d13350
[GtkScrolledWindow]) at ../../../../gtk/gtkcontainer.c:1073
#23 0x7f5ee745787f in (instance=instance@entry=0x564fb1d13350,
signal_id=, detail=detail@entry=0) at
../../../gobject/gsignal.c:3606
#20 0x7f5ee743d441 in g_closure_invoke
(closure=closure@entry=0x564fb088fc20, return_value=return_value@entry=0x0,
n_param_values=1, param_values=param_values@entry=0x7fffcf8edfa0,
invocation_hint=invocation_hint@entry=0x7fffcf8edf20) at
../../../gobject/gclosure.c:832
#21 0x7f5ee7450be4 in signal_emit_unlocked_R
(node=node@entry=0x564fb0889b90, detail=detail@entry=0,
instance=instance@entry=0x564fb1d13350,
emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffcf8edfa0) at
../../../gobject/gsignal.c:3914
#22 0x7f5ee74576b5 in g_signal_emit_valist (instance=,
signal_id=, detail=,
var_args=var_args@entry=0x7fffcf8ee120) at ../../../gobject/gsignal.c:3549
#24 0x7f5ee795fd56 in gtk_object_dispose (gobject=0x564fb1d13350
[GtkScrolledWindow]) at ../../../../gtk/gtkobject.c:421
#25 0x7f5ee7443d18 in g_object_run_dispose (object=0x564fb1d13350
[GtkScrolledWindow]) at ../../../gobject/gobject.c:1448
#26 0x7f5ee78852c7 in gtk_box_forall (container=0x564fb10591d0 [GtkVBox],
include_internals=, callback=0x7f5ee7a57410
, callback_data=0x0) at ../../../../gtk/gtkbox.c:1251
#27 0x7f5ee78bb437 in gtk_container_destroy (object=0x564fb10591d0
[GtkVBox]) at ../../../../gtk/gtkcontainer.c:1073
#31 0x7f5ee745787f in (instance=instance@entry=0x564fb10591d0, signal_id=,
detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#28 0x7f5ee743d441 in g_closure_invoke
(closure=closure@entry=0x564fb088fc20, return_value=return_value@entry=0x0,
n_param_values=1, param_values=param_values@entry=0x7fffcf8ee400,
Bug#1019717: Display of an SVG file broken due to gsfonts transition
Package: graphicsmagick Version: 1.4+really1.3.38+hg16739-1 Severity: normal X-Debbugs-Cc: r...@debian.org Attempting to display an SVG file breaks due to a missing font file: % gm display _static/spawning.svg gm display: Unable to read font (/usr/share/fonts/type1/gsfonts/n019003l.pfb) [No such file or directory]. (The image in question was created via the Python seqdiag package, which is packaged in Debian as python3-seqdiag, although I am using it directly from PyPI via a virtualenv.) This is presumably due to the transition from gsfonts to fonts-urw-base35 recently discussed on debian-devel: https://lists.debian.org/debian-devel/2022/08/msg00263.html I'm not sure precisely what has to change in GraphicsMagick to use the new package, though. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages graphicsmagick depends on: ii libc62.34-8 ii libgraphicsmagick-q16-3 1.4+really1.3.38+hg16739-1 graphicsmagick recommends no packages. Versions of packages graphicsmagick suggests: pn graphicsmagick-dbg -- no debconf information
Bug#1019716: cron: does not check for timezone changes except during DST events or init
Package: cron
Version: 3.0pl1-137
Severity: normal
Tags: patch
X-Debbugs-Cc: stephan.marc.garl...@gmail.com
Dear Maintainer,
Please see the writeup for this bug at:
https://gist.github.com/stephanGarland/b7cdd963e0ac53ea42f8ed15e35b193d
In short, if the timezone for a system is changed while cron is running,
and the timezone change is _not_ due to a DST event, cron is unaware of
the change and will continue using the old `GMToff` value until it is
restarted.
While this seems like a bizarre edge case, and it is, it happened to me
via moving, booting up my server rack, realizing the timezone needed to
be modified, and then not restarting the server. I noticed afterwards
that a daily cronjob I have ran one hour late.
The supplied patch fixes this, although I am cognizant of the fact that
this may be intended behavior. I'm willing to modify it to include an
optional flag (default: false) to set this behavior.
-- Package-specific info:
--- EDITOR:
--- /usr/bin/editor:
/usr/bin/nvim
--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 43568 Feb 22 2021 /usr/bin/crontab
--- /var/spool/cron:
drwxr-xr-x 3 root root 4096 Dec 23 2021 /var/spool/cron
--- /var/spool/cron/crontabs:
drwx-wx--T 2 root crontab 4096 Sep 11 15:53 /var/spool/cron/crontabs
--- /etc/cron.d:
drwxr-xr-x 2 root root 4096 Sep 11 21:13 /etc/cron.d
--- /etc/cron.daily:
drwxr-xr-x 2 root root 4096 Sep 11 06:34 /etc/cron.daily
--- /etc/cron.hourly:
drwxr-xr-x 2 root root 4096 Dec 23 2021 /etc/cron.hourly
--- /etc/cron.monthly:
drwxr-xr-x 2 root root 4096 Dec 23 2021 /etc/cron.monthly
--- /etc/cron.weekly:
drwxr-xr-x 2 root root 4096 Dec 23 2021 /etc/cron.weekly
-- System Information:
Debian Release: 11.5
APT prefers stable
APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500,
'stable-updates'), (500, 'stable-security')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cron depends on:
ii adduser 3.118
ii debianutils 4.11.2
ii init-system-helpers 1.60
ii libc62.31-13+deb11u4
ii libpam-runtime 1.4.0-9+deb11u1
ii libpam0g 1.4.0-9+deb11u1
ii libselinux1 3.1-3
ii lsb-base 11.1.0
ii sensible-utils 0.0.14
Versions of packages cron recommends:
pn default-mta | mail-transport-agent
Versions of packages cron suggests:
pn anacron
pn checksecurity
ii logrotate 3.18.0-2+deb11u1
Versions of packages cron is related to:
pn libnss-ldap
pn libnss-ldapd
pn libpam-ldap
pn libpam-mount
pn nis
pn nscd
-- no debconf information
diff --git a/cron.c b/cron.c
index 613e7bf..7b0b69c 100644
--- a/cron.c
+++ b/cron.c
@@ -372,9 +372,9 @@ set_time(int initialize)
/* We adjust the time to GMT so we can catch DST changes. */
tm = *localtime();
+GMToff = get_gmtoff(, );
if (initialize || tm.tm_isdst != isdst) {
isdst = tm.tm_isdst;
- GMToff = get_gmtoff(, );
Debug(DSCH, ("[%d] GMToff=%ld\n",
getpid(), (long)GMToff))
}
Bug#1019418: Content-Location header patch
Here's a patch. It was just a matter of calling a different function. Index: modules/mappers/mod_negotiation.c === --- modules/mappers/mod_negotiation.c.orig +++ modules/mappers/mod_negotiation.c @@ -2791,7 +2791,7 @@ static int setup_choice_response(request } apr_table_setn(r->err_headers_out, "Content-Location", - ap_escape_path_segment(r->pool, variant->file_name)); + ap_os_escape_path(r->pool, variant->file_name, 0)); set_neg_headers(r, neg, alg_choice); /* add Alternates and Vary */
Bug#1019602: texlive-bin: CVE-2022-35486 CVE-2022-35485 CVE-2022-35484 CVE-2022-35483 CVE-2022-35482 CVE-2022-35481 CVE-2022-35479 CVE-2022-35478 CVE-2022-35477 CVE-2022-35476 CVE-2022-35475 CVE-2022-
Am 12.09.2022 um 22:46 teilte Moritz Mühlenhoff mit: Source: texlive-bin X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The otfccdump binary is not build by any source package, hence we are not affected. Yes, we carry the source code of the program, but we don't use it. The otfcc project seems to be dead anyway: https://github.com/caryll/otfcc Hilmar The following vulnerabilities were published for OFTCC, which starting with some texlive release after Bullseye gets included in texlive (web2c/mfluadir): https://cvjark.github.io/2022/07/06/CVE-2022-33047/ CVE-2022-35486[0]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x6badae. CVE-2022-35485[1]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x703969. CVE-2022-35484[2]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x6b6a8f. CVE-2022-35483[3]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x5266a8. CVE-2022-35482[4]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x65f724. CVE-2022-35481[5]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /multiarch/memmove-vec-unaligned-erms.S. CVE-2022-35479[6]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x4fbbb6. CVE-2022-35478[7]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x6babea. CVE-2022-35477[8]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x4fe954. CVE-2022-35476[9]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x4fbc0b. CVE-2022-35475[10]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6e41a8. CVE-2022-35474[11]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6b544e. CVE-2022-35473[12]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /release-x64/otfccdump+0x4fe9a7. CVE-2022-35472[13]: | OTFCC v0.10.4 was discovered to contain a global overflow via | /release-x64/otfccdump+0x718693. CVE-2022-35471[14]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6e41b0. CVE-2022-35470[15]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x65fc97. CVE-2022-35469[16]: | OTFCC v0.10.4 was discovered to contain a segmentation violation via | /x86_64-linux-gnu/libc.so.6+0xbb384. CVE-2022-35468[17]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6e420d. CVE-2022-35467[18]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6e41b8. CVE-2022-35466[19]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6c0473. CVE-2022-35465[20]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6c0414. CVE-2022-35464[21]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6171b2. CVE-2022-35463[22]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6b0478. CVE-2022-35462[23]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6c0bc3. CVE-2022-35461[24]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6c0a32. CVE-2022-35460[25]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x61731f. CVE-2022-35459[26]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6e412a. CVE-2022-35458[27]: | OTFCC v0.10.4 was discovered to contain a heap-buffer overflow via | /release-x64/otfccdump+0x6b05ce. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-35486 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35486 [1] https://security-tracker.debian.org/tracker/CVE-2022-35485 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35485 [2] https://security-tracker.debian.org/tracker/CVE-2022-35484 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35484 [3] https://security-tracker.debian.org/tracker/CVE-2022-35483 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35483 [4] https://security-tracker.debian.org/tracker/CVE-2022-35482 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35482 [5]
Bug#1018206: luatex loses or changes text when discretionaries with priorities are used
Control: tags -1 + fixed-upstream Am 27.08.2022 um 00:58 teilte Peter Mueller mit: Package: texlive-latex-base Version: 2022.20220605-1 Severity: wishlist As described in https://tex.stackexchange.com/q/652458 https://tex.stackexchange.com/q/652458, luatex loses or changes text (not formatting!) in particular circumstances. According to https://mailman.ntg.nl/pipermail/dev-luatex/2022-July/006684.html https://mailman.ntg.nl/pipermail/dev-luatex/2022-July/006684.html, this seems to be repaired in the revision 7531 in TL 2023 (perhaps a revision or two later). I know it's a long stretch, but I'd welcome it if, for proper testing, the fix finds its way into Debian, ideally into Debian stable, better sooner than later. Tagging as fixed in upstream, will be in next TL upstream. Hilmar -- sigfault OpenPGP_signature Description: OpenPGP digital signature
Bug#1019714: pipenv: Contains non-source file
Source: pipenv Version: 11.9.0-2 Severity: serious pipenv contains get-pipenv.py, which has a base85 blob that supposedly "contains an entire copy of pip." pipenv has a runtime dependency on python3-pip, so this is not actually needed and removing the file does not make the build fail. Please repack the source, excluding that file.
Bug#1015173: ITP: pwncat -- reverse shell handler with all netcat features
The progress on ITP can be seen at https://salsa.debian.org/debian/pwncat Best Regards, mt signature.asc Description: PGP signature
Bug#1019413: debcrossgen: host_arch.cpu_family() reports powerpc64le on ppc64el but should report ppc64
On Thu, 8 Sept 2022 at 23:33, Helmut Grohne wrote: > host_arch.cpu_family() should be reporting ppc64 on ppc64el according to > https://mesonbuild.com/Reference-tables.html, but it actually reports > powerpc64le when debcrossgen is in use. The relevant mapping should be > fixed in debcrossgen. I'm attaching a patch for your convenience. We have moved this functionality from debcrossgen to Meson itself. This means that the packaging tools should switch from calling debcrossgen to `meson env2mfile` as described in this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017436 Dunno what is the correct way to get that fixed, though...
Bug#1017157: gatling: FTBFS: cdefs.h:297:60: error: macro "__has_attribute" requires an identifier
Control: reassign -1 libowfat-dev 0.30-4 Control: retitle -1 libowfat byte.h incompatible with glibc 2.34 Control: affects -1 src:gatling On Sun, Aug 14, 2022 at 09:13:47AM +0200, Lucas Nussbaum wrote: >... > > gcc -c connstat.c -o connstat.o -I. -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -pipe -Wall > > -DUSE_ZLIB > > In file included from /usr/include/features.h:489, > > from > > /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33, > > from /usr/include/stdlib.h:25, > > from connstat.c:2: > > /usr/include/x86_64-linux-gnu/sys/cdefs.h:297:60: error: macro > > "__has_attribute" requires an identifier > > 297 | #if __GNUC_PREREQ (2,96) || __glibc_has_attribute (__pure__) > > |^ > > make[2]: *** [GNUmakefile:110: connstat.o] Error 1 >... This is a problem in the libowfat byte.h, which is incompatible with glibc 2.34. cu Adrian
Bug#1017720: nfs-common: No such file or directory
I downgraded the nfs-common package which required the downgrade of the libevent packages and am using the 4.19.X kernel. I see the issue running the initial test, but then the issue is gone when running the test a subsequent time. libevent-2.1-6:amd64 2.1.8-stable-4 amd64Asynchronous event notification library libevent-core-2.1-6:amd64 2.1.8-stable-4 amd64Asynchronous event notification library (core) libevent-pthreads-2.1-6:amd64 2.1.8-stable-4amd64 Asynchronous event notification library (pthreads) linux-image-4.19.0-21-amd644.19.249-2 amd64Linux 4.19 for 64-bit PCs (signed) nfs-common 1:1.3.4-2.5+deb10u1 amd64NFS support files common to client and server What other packages do I need to downgrade in order to get Debian 11.4 to behave like Debian 10.8? What additional questions can I answer so that we can move forward? > -Original Message- > From: Jason Breitman > Sent: Tuesday, September 6, 2022 5:18 PM > To: Ben Hutchings ; 1017...@bugs.debian.org > Subject: RE: Bug#1017720: nfs-common: No such file or directory > > I also see the failure with the kernels below, but the 4.19.X kernel resolves > the issue without dropping caches. > linux-image-4.19.0-14-amd64 4.19.171-2 amd64 > Linux 4.19 for > 64-bit PCs (signed) > linux-image-4.19.0-21-amd64 4.19.249-2 amd64 > Linux 4.19 for > 64-bit PCs (signed) > > I see the issue running the initial test, but then the issue is gone when > running the test a subsequent time. > I ran several tests to verify the behavior differences between the 4.19.X and > 5.X kernels. > > -- Test > ls -l /mnt/dir/someOtherDir/* | grep '?' > > -- Error message - the error message is showing files that have been erased > via rsync --delete > ls: cannot access 'filename': No such file or directory > -? ? ???? filename > > > -Original Message- > > From: Jason Breitman > > Sent: Friday, September 2, 2022 5:17 PM > > To: Ben Hutchings ; 1017...@bugs.debian.org > > Subject: RE: Bug#1017720: nfs-common: No such file or directory > > > > I have tested with the following kernels and see this issue in each case. > > > > linux-image-5.10.0-16-amd64 5.10.127-1 > > amd64 > Linux > > 5.10 for 64-bit PCs (signed) > > linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1 amd64 > > Linux 5.15 for 64-bit PCs (signed) > > linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1 amd64 > > Linux 5.18 for 64-bit PCs (signed) > > > > An interesting note is that when using the 5.18 kernel, I had to run echo 3 > > > > > /proc/sys/vm/drop_caches to resolve the issue. > > echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10 and > > 5.15 kernels. > > > > > -Original Message- > > > From: Jason Breitman > > > Sent: Friday, August 26, 2022 3:36 PM > > > To: 'Ben Hutchings' ; '1017...@bugs.debian.org' > > > <1017...@bugs.debian.org> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory > > > > > > I was able to identify another workaround today which may help you to > > > identify the issue. > > > The workaround is to touch the directory where the troubled files live on > > the > > > file server. > > > I believe this tells us that updating the modify time attribute is used by > the > > > cache. > > > It should be noted that access time updates are disabled on the file > server. > > > > > > I also wanted to restate that we use rsync to push out these application > > > updates and also use rsync to sync data files. > > > Our rsync options preserve timestamps, so it is possible that the new > > > files > > > have an older timestamp than "now". > > > It is not the case that the new files have an older timestamp than the > prior > > > version that is stuck in the cache. > > > > > > The rsync process that I describe has not changed and has been in use for > > > many years. > > > > > > > -Original Message- > > > > From: Jason Breitman > > > > Sent: Thursday, August 25, 2022 11:54 AM > > > > To: Ben Hutchings ; 1017...@bugs.debian.org > > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory > > > > > > > > I have the same issue after adding actimeo=30 to /etc/fstab, rebooting > > and > > > > testing. > > > > I also confirmed that those settings applied via /proc/mounts which > > shows > > > > the below snippet for each mountpoint. > > > > nfs4 > > > > > > > > > > rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=30,a > > > > > > > > > > cregmax=30,acdirmax=30,hard,noresvport,proto=tcp,timeo=600,retrans=2,s > > > > > > > > > > ec=krb5,clientaddr=X.X.X.X,lookupcache=pos,local_lock=none,addr=Y.Y.Y.Y 0 > > >
Bug#1016238: autofdo: diff for NMU version 0.19-2.2
Control: tags 1016238 + patch Dear maintainer, I've prepared an NMU for autofdo (versioned as 0.19-2.2) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru autofdo-0.19/debian/changelog autofdo-0.19/debian/changelog --- autofdo-0.19/debian/changelog 2021-10-07 15:13:26.0 +0300 +++ autofdo-0.19/debian/changelog 2022-09-13 23:41:57.0 +0300 @@ -1,3 +1,10 @@ +autofdo (0.19-2.2) unstable; urgency=medium + + * Non-maintainer upload. + * Build with LLVM 13. (Closes: #1016238) + + -- Adrian Bunk Tue, 13 Sep 2022 23:41:57 +0300 + autofdo (0.19-2.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru autofdo-0.19/debian/control autofdo-0.19/debian/control --- autofdo-0.19/debian/control 2021-10-07 15:13:26.0 +0300 +++ autofdo-0.19/debian/control 2022-09-13 23:41:19.0 +0300 @@ -7,7 +7,7 @@ libssl-dev, zlib1g-dev, libgoogle-glog-dev, libgflags-dev, libelf-dev, - llvm-dev, + llvm-13-dev, protobuf-compiler, libprotobuf-dev, Standards-Version: 4.4.1 diff -Nru autofdo-0.19/debian/rules autofdo-0.19/debian/rules --- autofdo-0.19/debian/rules 2021-10-07 15:13:26.0 +0300 +++ autofdo-0.19/debian/rules 2022-09-13 23:41:42.0 +0300 @@ -11,3 +11,6 @@ rm -rf glog rm -rf third_party/protobuf dh_auto_clean + +override_dh_auto_configure: + dh_auto_configure -- --with-llvm=/usr/bin/llvm-config-13
Bug#1014177: qemu-user-static: QEMU aarch64 user mode emulation always segfaults
On Fri, 01 Jul 2022 17:06:31 +0200 Jörn_Heusipp
wrote:
Package: qemu-user-static
Version: 1:7.0+dfsg-7
Severity: important
X-Debbugs-Cc: osm...@problemloesungsmaschine.de
Dear Maintainer,
I am using QEMU user mode emulation to test my software on non-amd64
architectures. I have qemu-user-static and binfmt-support installed so that I
can run foreign binaries seamlessly.
On Debian Testing with QEMU 7, aarch64 user mode emulation always segfaults:
```
manx@appendix:~/tmp$ cat nothing.c
int main() {
return 0;
}
manx@appendix:~/tmp$ aarch64-linux-gnu-gcc -std=c18 -O3 -Wall -Wextra
-Wpedantic nothing.c
manx@appendix:~/tmp$ ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault
This works fine on bullseye system with qemu-user-static 7.0 from backports.
This and the static build, which failed for you too.
I wonder if the difference is within gcc (which compiled your nothing.c)
or with glibc (which provides the dynamic linker and the startup code).
I uploaded new upstream release of qemu a few days ago, 7.1, can you verify
if that one makes any difference?
Thanks!
/mjt
Bug#1019661: lsb-base: Removing init-functions guaranteed to break EVERY init.d script
Package: lsb-base Followup-For: Bug #1019661 X-Debbugs-Cc: to...@atoth.sote.hu Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Regular nightly upgrade brought in 11.3 lsb-release and lsb-base, but didn't get newer sysvinit-utils (as I'm reading that mught have prevented the carnage if it placed the init-functionns to the exact expected path (/lib/lsb) - I'm verifying that now * What exactly did you do (or not do) that was effective (or ineffective)? This is a major PITA, I'm still trying to stand that system back up, somehow shoveling the required file, but the pen drive's /dev/sda1 is not created either. * What was the outcome of this action? Well, the outcome of the upgrade was that it totally broke the boot, like really bad. * What outcome did you expect instead? I'd expect the system booting even in unstable/testing. Back in the past I've had run-ins with network manager related stuff one time, but only one time I had broken boot due to some grib EFI update debacle about 5 years ago. *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-trunk-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#1019713: gargoyle-free: trying to overwrite .../application-x-tads.png, which is also in package qtads
Package: gargoyle-free Version: 2022.1-1 Severity: serious Justification: Policy 7.6.1 Unpacking gargoyle-free (2022.1-1) over (2019.1.1-2) ... dpkg: error processing archive /var/cache/apt/archives/gargoyle-free_2022.1-1_amd64.deb (--unpack): trying to overwrite '/usr/share/icons/hicolor/32x32/mimetypes/application-x-tads.png', which is also in package qtads 2.1.7-0.1+b1 Errors were encountered while processing: /var/cache/apt/archives/gargoyle-free_2022.1-1_amd64.deb Both packages (qtads and the new gargoyle-free) provide the icon for .tads files, so you probably need to set up alternatives. dpkg-divert would only work until a 3rd package also tries to provide that icon. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (800, 'unstable') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-rc5-pinguin20220912 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gargoyle-free depends on: ii fonts-go 0~20170330-1 ii fonts-liberation 1:1.07.4-11 ii fonts-linuxlibertine 5.3.0-6 ii fonts-noto-core 20201225-1 ii libc6 2.34-8 ii libfontconfig12.13.1-4.4 ii libfreetype6 2.12.1+dfsg-3 ii libgcc-s1 12.2.0-2 ii libglib2.0-0 2.73.3-3 ii libgtk2.0-0 2.24.33-2 ii libjpeg62-turbo 1:2.1.2-1 ii libpng16-16 1.6.37-5 ii libsdl-mixer1.2 1.2.12-17+b1 ii libsdl-sound1.2 1.0.3-9+b1 ii libsdl1.2debian 1.2.15+dfsg2-8 ii libstdc++612.2.0-2 ii zlib1g1:1.2.11.dfsg-4.1 gargoyle-free recommends no packages. gargoyle-free suggests no packages. -- no debconf information
Bug#720723: Please do not compress .vym files
Package: vym Version: 2.6.11-3+b2 Followup-For: Bug #720723 Just ran into this 9 yo issue. Should be easy to fix by excluding .vym from being compressed by dh_compress -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), (100, 'unstable-debug'), (100, 'stable-updates'), (100, 'stable-security'), (100, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vym depends on: ii libc62.34-4 ii libgcc-s1 [libgcc1] 12.2.0-1 ii libqt5core5a 5.15.4+dfsg-5 ii libqt5dbus5 5.15.4+dfsg-5 ii libqt5gui5 5.15.4+dfsg-5 ii libqt5network5 5.15.4+dfsg-5 ii libqt5printsupport5 5.15.4+dfsg-5 ii libqt5svg5 5.15.4-2 ii libqt5widgets5 5.15.4+dfsg-5 ii libqt5xml5 5.15.4+dfsg-5 ii libstdc++6 12.2.0-1 ii unzip6.0-27 ii xsltproc 1.1.35-1 ii zip 3.0-12 vym recommends no packages. Versions of packages vym suggests: ii ruby 1:3.0+1 -- debconf-show failed
Bug#1019700: Fwd: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
-- Forwarded message - From: Hank Barta Date: Tue, Sep 13, 2022 at 12:54 PM Subject: Re: Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt. To: Bjørn Mork Hi Bjørn, Many thanks for the prompt reply. In the mean time I have done the following: * Reimaged my SD card with `20220808_raspi_4_bookworm.img.xz` from Debian Tested images. (5.18.14-1 kernel) * Booted and noted *no* SD card timeouts. Rebooted and power cycled 3 times each with the same result. * Performed `apt update && apt upgrade -y` and rebooted. (5.19.6-1 kernel) * First boot - repeated SD timeouts and unable to log in. Power cycled to force reboot * Second reboot - no SD card timeouts. Added `dtparam=sd_poll_once=on` to `/boot/firmware/config.txt` * Third boot - repeated SD card timeouts. Evetually I was able to log in to the console. Network is not fully up. The repeated SD timeouts seem to be slowing normal boot. Actually I may not have been logged in but in the console that presents when there is a problem booting. I exited and now I see a login prompt. And Ethernet finally came up. 737 seconds post boot according to console messages. (It was some time later before I could ssh in.) The SD timeout messages stopped. I have a login prompt at the console but it takes about 30s to login. The system is now responsive, but WiFi modules did not load. I count 52 timeout messages in dmesg output. There is no response to at the console. Tried to shutdown using `shutdown -r now` and the system hangs. The system is most certainly not operating normally. Does Debian use the device tree? This is a Debian system, not R-Pi OS. If I reboot enough times I will get a clean boot followed by normal operation. I have tried different SD cards, USB SSDs and Pi 4Bs all with the same result so I do not believe this is a H/W problem. I do recall the previous SD timeout issue and I worked around that by inserting an SD card post boot but that no longer works. This seems to be a new problem. best, hank On Tue, Sep 13, 2022 at 11:32 AM Bjørn Mork wrote: > Hank Barta writes: > > > ** Kernel log: > > [ 723.735217] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 > > [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 > > [ 723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 > > [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 > > [ 723.761324] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 > > [ 723.767851] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x > > [ 723.774379] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x > > [ 723.780905] mmc0: sdhci: Host ctl2: 0x > > [ 723.785404] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x > > [ 723.791930] mmc0: sdhci: > > [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt. > > These repeated messages are normal on the RPi4 if you boot it without an > SD card. E.g. from USB or network. If that's what you intend to do, > then you can avoid the repeated messages by adding > > dtparam=sd_poll_once=on > > to the config.txt file in your firmware partition. Often mounted as > /boot/firmware/. > > The effect depends on which device-tree you are using. I believe it > will only work with the ones coming with the Raspberry Pi firmware. See > > https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README > > for docs. > > > Bjørn > -- Beautiful Sunny Winfield -- Beautiful Sunny Winfield
Bug#1019712: zanshin FTBFS: error: no matching function for call to ‘Plugin::Plugin(KontactInterface::Core*, const KPluginMetaData&, const QVariantList&)’
Source: zanshin Version: 22.04.2-1 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=zanshin=22.04.2-1%2Bb1 ... In file included from /usr/include/KF5/KontactInterface/KontactInterface/Plugin:1, from /<>/src/zanshin/kontact/kontact_plugin.h:10, from /<>/src/zanshin/kontact/kontact_plugin.cpp:6: /<>/src/zanshin/kontact/kontact_plugin.cpp: In static member function ‘static QObject* Instance::createInstance(QWidget*, QObject*, const KPluginMetaData&, const QVariantList&)’: /<>/src/zanshin/kontact/kontact_plugin.cpp:28:1: error: no matching function for call to ‘Plugin::Plugin(KontactInterface::Core*, const KPluginMetaData&, const QVariantList&)’ 28 | EXPORT_KONTACT_PLUGIN_WITH_JSON(Plugin, "zanshin_plugin.json") | ^~~ /<>/src/zanshin/kontact/kontact_plugin.h:18:5: note: candidate: ‘Plugin::Plugin(KontactInterface::Core*, const QVariantList&)’ 18 | Plugin(KontactInterface::Core *core, const QVariantList &); | ^~ /<>/src/zanshin/kontact/kontact_plugin.h:18:5: note: candidate expects 2 arguments, 3 provided /<>/src/zanshin/kontact/kontact_plugin.cpp: In constructor ‘Plugin::Plugin(KontactInterface::Core*, const QVariantList&)’: /<>/src/zanshin/kontact/kontact_plugin.cpp:31:53: error: no matching function for call to ‘KontactInterface::Plugin::Plugin(KontactInterface::Core*&, KontactInterface::Core*&, const char [8])’ 31 | : KontactInterface::Plugin(core, core, "zanshin") | ^ /usr/include/KF5/KontactInterface/kontactinterface/plugin.h:80:5: note: candidate: ‘KontactInterface::Plugin::Plugin(KontactInterface::Core*, QObject*, const KPluginMetaData&, const char*, const char*)’ 80 | Plugin(Core *core, QObject *parent, const KPluginMetaData , const char *appName, const char *pluginName = nullptr); | ^~ /usr/include/KF5/KontactInterface/kontactinterface/plugin.h:80:5: note: candidate expects 5 arguments, 3 provided make[3]: *** [src/zanshin/kontact/CMakeFiles/kontact_zanshinplugin.dir/build.make:93: src/zanshin/kontact/CMakeFiles/kontact_zanshinplugin.dir/kontact_plugin.cpp.o] Error 1
Bug#1010289: bug 1010289: audit: FTBFS: error: cast specifies array type
Hi, Very small update. On 09-09-2022 22:35, Paul Gevers wrote: I started to work on copying the idea, the work is unfinished. I also tried the latest upstream version, but that still fails in the same way. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1019711: readline: no Homepage field
Source: readline Version: 8.2~rc2-2 Severity: wishlist Please add Homepage: https://tiswww.case.edu/php/chet/readline/rltop.html to debian/control. -- Jakub Wilk
Bug#1019710: python-oauthlib: CVE-2022-36087: DoS when attacker provide malicious IPV6 URI
Source: python-oauthlib Version: 3.2.0-1 Severity: important Tags: security upstream X-Debbugs-Cc: car...@debian.org, Debian Security Team Hi, The following vulnerability was published for python-oauthlib. CVE-2022-36087[0]: | OAuthLib is an implementation of the OAuth request-signing logic for | Python 3.6+. In OAuthLib versions 3.1.1 until 3.2.1, an attacker | providing malicious redirect uri can cause denial of service. An | attacker can also leverage usage of `uri_validate` functions depending | where it is used. OAuthLib applications using OAuth2.0 provider | support or use directly `uri_validate` are affected by this issue. | Version 3.2.1 contains a patch. There are no known workarounds. Note, that while it is claimed to be fixed in 3.2.1, the two commits in [1] and [2] are not included in 3.2.1. There is a simple test case to show the issue as well in the commit expanding the unittests. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-36087 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36087 [1] https://github.com/oauthlib/oauthlib/security/advisories/GHSA-3pgj-pg6c-r5p7 [2] https://github.com/oauthlib/oauthlib/commit/e514826eea15f2b62bbc13da407b71552ef5ff4c [3] https://github.com/oauthlib/oauthlib/commit/5d85c61998692643dd9d17e05d2646e06ce391e8 Regards, Salvatore
Bug#1019139: ITP: zpaqfranz -- Swiss army knife for backup and disaster recovery
X-Debbugs-Cc: sk...@debian.org On Sun, 04 Sep 2022 14:53:45 +0200 root wrote: Package: wnpp Severity: wishlist Owner: Franco Corbelli * Package name: zpaqfranz Version : 55.14 Upstream Author : Franco Corbelli * URL : https://github.com/fcorbelli/zpaqfranz * License : MIT Programming Lang: C, C++ Description : Swiss army knife for backup and disaster recovery Like 7z or RAR on steroids,with deduplicated "snapshots" (versions) Conceptually similar to Mac time machine, but much more efficiently Keeps backup always-to-always, no need to ever prune (CryptoLocker) Easily handles millions of files and TBs of data, non-latin support Cloud backups with full encryption, minimal data transfer/bandwidth Data integrity check CRC32+XXHASH|SHA-1|SHA-2|SHA-3|MD5|XXH3|BLAKE3 Thorough data verification, multithread support (real world 1GB+/s) Specific zfs handling functions,full multiplatform interoperability Particularly suitable for minimal space storage of virtual machines Windows, FreeBSD, OpenBSD, Linux, MacOS, Solaris, OmniOS and others __ This is a fork of zpaq 7.15 (already in Debian) which was abandoned by the developer (Matt Mahoney) in 2016. As zpaqfranz is supposed to be a compatible replacement for zpaq, I suggest to make it the new upstream of the existing zpaq package. Stephen, any opinions on this?
Bug#1018296: ERROR: rejecting unrequested file-list name
Hello, I have uploaded rsync 3.2.6-2 to experimental a few minutes ago, it contains an upstream patch which should fix this as noted on https://github.com/WayneD/rsync/issues/356 Can you try it out and let upstream know if this addressed the issue, please? Thank you. -- Samuel Henrique
Bug#1017137: newsboat: diff for NMU version 2.21-1.4
Control: tags 1017137 + patch Control: tags 1017137 + pending Dear maintainer, I've prepared an NMU for newsboat (versioned as 2.21-1.4) and uploaded it to DELAYED/14. Please feel free to tell me if I should cancel it. cu Adrian diff -Nru newsboat-2.21/debian/changelog newsboat-2.21/debian/changelog --- newsboat-2.21/debian/changelog 2022-07-16 22:13:03.0 +0300 +++ newsboat-2.21/debian/changelog 2022-09-13 22:56:30.0 +0300 @@ -1,3 +1,11 @@ +newsboat (2.21-1.4) unstable; urgency=low + + * Non-maintainer upload. + * Use the packaged catch.hpp and json.hpp instead of vendored copies. +(Closes: #1017137) + + -- Adrian Bunk Tue, 13 Sep 2022 22:56:30 +0300 + newsboat (2.21-1.3) unstable; urgency=medium * Non-maintainer upload. diff -Nru newsboat-2.21/debian/clean newsboat-2.21/debian/clean --- newsboat-2.21/debian/clean 1970-01-01 02:00:00.0 +0200 +++ newsboat-2.21/debian/clean 2022-09-13 22:56:30.0 +0300 @@ -0,0 +1,2 @@ +3rd-party/catch.hpp +3rd-party/json.hpp diff -Nru newsboat-2.21/debian/control newsboat-2.21/debian/control --- newsboat-2.21/debian/control 2022-06-23 19:47:20.0 +0300 +++ newsboat-2.21/debian/control 2022-09-13 22:56:30.0 +0300 @@ -11,6 +11,8 @@ pkg-config, libcurl4-gnutls-dev, libjson-c-dev, + catch2, + nlohmann-json3-dev, asciidoctor, cargo, librust-chrono-0.4-dev, diff -Nru newsboat-2.21/debian/rules newsboat-2.21/debian/rules --- newsboat-2.21/debian/rules 2020-10-15 16:34:06.0 +0300 +++ newsboat-2.21/debian/rules 2022-09-13 22:56:30.0 +0300 @@ -13,6 +13,8 @@ override_dh_auto_build: rm -f Cargo.lock + ln -fs /usr/include/catch2/catch.hpp 3rd-party/ + ln -fs /usr/include/nlohmann/json.hpp 3rd-party/ dh_auto_build -- CARGO_HOME=debian/cargo_home prefix=/usr all make doc
Bug#929593: ITP: pistache -- C++ REST framework
Is there a particular reason why pistache should be in Debian? There are already a number of similar HTTP libraries and this package is not very common amongst other Linux distros.
Bug#1019709: wcc: typo in package descriptions
Source: wcc
Severity: minor
Tags: patch
liraries → libraries
--
Jakub Wilk
diff --git a/debian/control b/debian/control
index 134151b..198a9ae 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Depends:
${shlibs:Depends},
Suggests: lua
Description: Collection of tools to manipulate binaries and shared objects
- This tool permits one to manipulate binaries and shared liraries to reuse
+ This tool permits one to manipulate binaries and shared libraries to reuse
their API into an external usage, as a relocatable object that
can be linked to a new project, or through an interpreter (wsh)
to execute internal API directly.
Bug#1007000: thin FTBFS on IPV6-only buildds
Control: reopen -1 On Thu, Sep 01, 2022 at 03:36:43PM -0300, Lucas Kanashiro wrote: > This is a consequence of this bug filed against ruby-eventmachine: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998097 The bug is still present with ruby-eventmachine 1.3~pre20201020-b50c135-6: https://buildd.debian.org/status/fetch.php?pkg=thin=amd64=1.8.0-2=1662166302=0 > Lucas Kanashiro cu Adrian
Bug#943237: telepathy-rakia: diff for NMU version 0.8.0-4.1
Control: tags 943237 + pending
Dear maintainer,
I've prepared an NMU for telepathy-rakia (versioned as 0.8.0-4.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru telepathy-rakia-0.8.0/debian/changelog telepathy-rakia-0.8.0/debian/changelog
--- telepathy-rakia-0.8.0/debian/changelog 2020-12-02 16:44:50.0 +0200
+++ telepathy-rakia-0.8.0/debian/changelog 2022-09-13 22:16:31.0 +0300
@@ -1,3 +1,10 @@
+telepathy-rakia (0.8.0-4.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Add proposed patch for building with Python 3. (Closes: #943237)
+
+ -- Adrian Bunk Tue, 13 Sep 2022 22:16:31 +0300
+
telepathy-rakia (0.8.0-4) unstable; urgency=medium
[ Simon McVittie ]
diff -Nru telepathy-rakia-0.8.0/debian/control telepathy-rakia-0.8.0/debian/control
--- telepathy-rakia-0.8.0/debian/control 2020-12-02 16:44:50.0 +0200
+++ telepathy-rakia-0.8.0/debian/control 2022-09-13 22:16:31.0 +0300
@@ -12,7 +12,7 @@
libsofia-sip-ua-glib-dev (>= 1.12.11),
libtelepathy-glib-dev (>= 0.17.7),
libssl-dev,
- python2,
+ python3,
xsltproc
Standards-Version: 4.5.1
Vcs-Git: https://salsa.debian.org/telepathy-team/telepathy-rakia.git
diff -Nru telepathy-rakia-0.8.0/debian/patches/0001-Migrate-tools-to-python3-to-be-able-to-build-on-mode.patch telepathy-rakia-0.8.0/debian/patches/0001-Migrate-tools-to-python3-to-be-able-to-build-on-mode.patch
--- telepathy-rakia-0.8.0/debian/patches/0001-Migrate-tools-to-python3-to-be-able-to-build-on-mode.patch 1970-01-01 02:00:00.0 +0200
+++ telepathy-rakia-0.8.0/debian/patches/0001-Migrate-tools-to-python3-to-be-able-to-build-on-mode.patch 2022-09-13 22:15:50.0 +0300
@@ -0,0 +1,124 @@
+From b34225eeef0da38f41708c2fbf40ab196163c708 Mon Sep 17 00:00:00 2001
+From: Phillip Schichtel
+Date: Sat, 30 Nov 2019 19:33:23 +0100
+Subject: Migrate tools to python3 to be able to build on modern systems
+
+---
+ tools/glib-client-marshaller-gen.py | 19 +--
+ tools/glib-ginterface-gen.py| 7 +++
+ tools/glib-signals-marshal-gen.py | 5 ++---
+ tools/libglibcodegen.py | 4 ++--
+ 4 files changed, 16 insertions(+), 19 deletions(-)
+
+diff --git a/tools/glib-client-marshaller-gen.py b/tools/glib-client-marshaller-gen.py
+index 5444725..675c545 100644
+--- a/tools/glib-client-marshaller-gen.py
b/tools/glib-client-marshaller-gen.py
+@@ -31,22 +31,21 @@ class Generator(object):
+ for signal in signals:
+ self.do_signal(signal)
+
+-print 'void'
+-print '%s_register_dbus_glib_marshallers (void)' % self.prefix
+-print '{'
++print('void')
++print('%s_register_dbus_glib_marshallers (void)' % self.prefix)
++print('{')
+
+-all = self.marshallers.keys()
+-all.sort()
++all = sorted(self.marshallers.keys())
+ for marshaller in all:
+ rhs = self.marshallers[marshaller]
+
+-print ' dbus_g_object_register_marshaller (%s,' % marshaller
+-print ' G_TYPE_NONE, /* return */'
++print(' dbus_g_object_register_marshaller (%s,' % marshaller)
++print(' G_TYPE_NONE, /* return */')
+ for type in rhs:
+-print ' G_TYPE_%s,' % type.replace('VOID', 'NONE')
+-print ' G_TYPE_INVALID);'
++print(' G_TYPE_%s,' % type.replace('VOID', 'NONE'))
++print(' G_TYPE_INVALID);')
+
+-print '}'
++print('}')
+
+
+ def types_to_gtypes(types):
+diff --git a/tools/glib-ginterface-gen.py b/tools/glib-ginterface-gen.py
+index a8180b7..414a1f9 100644
+--- a/tools/glib-ginterface-gen.py
b/tools/glib-ginterface-gen.py
+@@ -619,8 +619,7 @@ class Generator(object):
+ self.b('#include %s' % header)
+ self.b('')
+
+-nodes = self.dom.getElementsByTagName('node')
+-nodes.sort(cmp_by_name)
++nodes = sorted(self.dom.getElementsByTagName('node'))
+
+ for node in nodes:
+ self.do_node(node)
+@@ -639,7 +638,7 @@ class Generator(object):
+
+
+ def cmdline_error():
+-print """\
++print("""\
+ usage:
+ gen-ginterface [OPTIONS] xmlfile Prefix_
+ options:
+@@ -659,7 +658,7 @@ options:
+ void symbol (DBusGMethodInvocation *context)
+ and return some sort of "not implemented" error via
+ dbus_g_method_return_error (context, ...)
+-"""
++""")
+ sys.exit(1)
+
+
+diff --git a/tools/glib-signals-marshal-gen.py b/tools/glib-signals-marshal-gen.py
+index 0d02c13..c76ff5e 100644
+--- a/tools/glib-signals-marshal-gen.py
b/tools/glib-signals-marshal-gen.py
+@@ -41,12 +41,11 @@ class Generator(object):
+ for signal in signals:
+ self.do_signal(signal)
+
+-all = self.marshallers.keys()
+-
Bug#1016445: 389-ds-base: diff for NMU version 2.0.15-1.1
Control: tags 1016445 + patch
Control: tags 1016445 + pending
Dear maintainer,
I've prepared an NMU for 389-ds-base (versioned as 2.0.15-1.1) and
uploaded it to DELAYED/15. Please feel free to tell me if I should
cancel it.
cu
Adrian
diff -Nru 389-ds-base-2.0.15/debian/changelog 389-ds-base-2.0.15/debian/changelog
--- 389-ds-base-2.0.15/debian/changelog 2022-04-13 14:11:20.0 +0300
+++ 389-ds-base-2.0.15/debian/changelog 2022-09-13 22:10:45.0 +0300
@@ -1,3 +1,11 @@
+389-ds-base (2.0.15-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * CVE-2022-0918: unauthenticated attacker with network access to
+the LDAP port could cause a denial of service (Closes: #1016445)
+
+ -- Adrian Bunk Tue, 13 Sep 2022 22:10:45 +0300
+
389-ds-base (2.0.15-1) unstable; urgency=medium
* New upstream release.
diff -Nru 389-ds-base-2.0.15/debian/patches/0001-Issue-5242-Craft-message-may-crash-the-server-5243.patch 389-ds-base-2.0.15/debian/patches/0001-Issue-5242-Craft-message-may-crash-the-server-5243.patch
--- 389-ds-base-2.0.15/debian/patches/0001-Issue-5242-Craft-message-may-crash-the-server-5243.patch 1970-01-01 02:00:00.0 +0200
+++ 389-ds-base-2.0.15/debian/patches/0001-Issue-5242-Craft-message-may-crash-the-server-5243.patch 2022-09-13 22:09:53.0 +0300
@@ -0,0 +1,45 @@
+From f46ab49c9f06b503f5ec8147f2c01dcacdb6a375 Mon Sep 17 00:00:00 2001
+From: tbordaz
+Date: Wed, 30 Mar 2022 18:07:23 +0200
+Subject: Issue 5242- Craft message may crash the server (#5243)
+
+Bug description:
+ A craft request can result in DoS
+
+Fix description:
+ If the server fails to decode the ber value
+ then return an Error
+
+relates: 5242
+
+Reviewed by: Pierre Rogier, Mark Reynolds (thanks !)
+
+Platforms tested: F34
+---
+ ldap/servers/slapd/filter.c | 10 --
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+diff --git a/ldap/servers/slapd/filter.c b/ldap/servers/slapd/filter.c
+index 40f11c230..dd3ce0340 100644
+--- a/ldap/servers/slapd/filter.c
b/ldap/servers/slapd/filter.c
+@@ -647,8 +647,14 @@ get_extensible_filter(BerElement *ber, mr_filter_t *mrf)
+ }
+ }
+
+-if ((tag != LBER_ERROR) && (len != -1)) {
+-goto parsing_error;
++if (tag == LBER_ERROR) {
++if (len == -1) {
++/* means that the ber sequence ended without LBER_END_OF_SEQORSET tag
++ * and it is considered as valid to ensure compatibility with open ldap.
++ */
++} else {
++goto parsing_error;
++}
+ }
+
+ slapi_log_err(SLAPI_LOG_FILTER, "get_extensible_filter", "<= %i\n", rc);
+--
+2.30.2
+
diff -Nru 389-ds-base-2.0.15/debian/patches/series 389-ds-base-2.0.15/debian/patches/series
--- 389-ds-base-2.0.15/debian/patches/series 2022-04-13 14:08:57.0 +0300
+++ 389-ds-base-2.0.15/debian/patches/series 2022-09-13 22:10:25.0 +0300
@@ -1,2 +1,3 @@
fix-saslpath.diff
0001-Revert-Issue-3584-Fix-PBKDF2_SHA256-hashing-in-FIPS-.patch
+0001-Issue-5242-Craft-message-may-crash-the-server-5243.patch
Bug#1019708: astropy: autopkgtest regression: No warnings of type (,) were emitted
Source: astropy
Version: 5.1-3
Severity: serious
User: debian...@lists.debian.org
Usertags: regression
Dear maintainer(s),
Your package has an autopkgtest, great. However, it recently started
to fail in testing.
Paul
https://ci.debian.net/packages/a/astropy/
https://ci.debian.net/data/autopkgtest/testing/amd64/a/astropy/25974808/log.gz
=== FAILURES
===
_ test_convert_overflow[False]
_
fast_reader = False
@pytest.mark.parametrize('fast_reader', [True, False,
{'use_fast_converter': False},
{'use_fast_converter':
True}, 'force'])
def test_convert_overflow(fast_reader):
"""
Test reading an extremely large integer, which falls through to
string due to an overflow error (#2234). The C parsers used to
return inf (kind 'f') for this.
"""
expected_kind = 'U'
> with pytest.warns(AstropyWarning, match="OverflowError
converting to IntType in column a"):
E Failed: DID NOT WARN. No warnings of type ('astropy.utils.exceptions.AstropyWarning'>,) were emitted. The list of
emitted warnings is: [].
/usr/lib/python3/dist-packages/astropy/io/ascii/tests/test_read.py:64:
Failed
OpenPGP_signature
Description: OpenPGP digital signature
Bug#1019707: snapd-glib: flaky autopkgtest, particularly on s390x: Test timed out after 300 seconds
Source: snapd-glib Version: 1.58-4 Severity: serious User: debian...@lists.debian.org Usertags: flaky Dear maintainer(s), I looked at the results of the autopkgtest of your package. I noticed that it regularly fails s390x and seems to fail everywhere once in a while. Because the unstable-to-testing migration software now blocks on regressions in testing, flaky tests, i.e. tests that flip between passing and failing without changes to the list of installed packages, are causing people unrelated to your package to spend time on these tests. Don't hesitate to reach out if you need help and some more information from our infrastructure. Paul All that I checked had (either test-glib or test-qt or both): Executing: snapd-glib/test-.test Test timed out after 300 seconds FAIL: snapd-glib/test-.test (Child process killed by signal 9) See: https://ci.debian.net/packages/s/snapd-glib/testing/s390x/ https://ci.debian.net/data/autopkgtest/testing/s390x/s/snapd-glib/25635393/log.gz https://ci.debian.net/data/autopkgtest/testing/armel/s/snapd-glib/23118663/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/s/snapd-glib/25944925/log.gz OpenPGP_signature Description: OpenPGP digital signature
Bug#1000171: xmlcopyeditor: diff for NMU version 1.2.1.3-4.2
Control: tags 1000171 + patch
Control: tags 1000171 + pending
Dear maintainer,
I've prepared an NMU for xmlcopyeditor (versioned as 1.2.1.3-4.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.
Regards.
diff -Nru xmlcopyeditor-1.2.1.3/debian/changelog xmlcopyeditor-
1.2.1.3/debian/changelog
--- xmlcopyeditor-1.2.1.3/debian/changelog 2020-05-27
07:47:55.0 -0400
+++ xmlcopyeditor-1.2.1.3/debian/changelog 2022-09-13
14:38:47.0 -0400
@@ -1,3 +1,11 @@
+xmlcopyeditor (1.2.1.3-4.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * debian/rules: Migrate to automatic dbgsym package.
+(Closes: #1000171)
+
+ -- Boyuan Yang Tue, 13 Sep 2022 14:38:47 -0400
+
xmlcopyeditor (1.2.1.3-4.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru xmlcopyeditor-1.2.1.3/debian/control xmlcopyeditor-
1.2.1.3/debian/control
--- xmlcopyeditor-1.2.1.3/debian/control2020-05-27
07:47:55.0 -0400
+++ xmlcopyeditor-1.2.1.3/debian/control2022-09-13
14:37:44.0 -0400
@@ -12,21 +12,8 @@
Package: xmlcopyeditor
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
-Suggests: xmlcopyeditor-dbg (= ${binary:Version})
Description: fast, free, validating XML editor
XML Copy Editor is an XML editor focusing on editing document markup
languages like DITA, DocBook, WordprocessingML. It features DTD/XML
Schema/RELAX NG validation, XSLT, XPath, pretty-printing, syntax
highlighting, folding, tag completion/locking, and a spelling/style check.
-
-Package: xmlcopyeditor-dbg
-Section: debug
-Architecture: any
-Depends: xmlcopyeditor (= ${binary:Version}), ${misc:Depends}
-Description: fast, free, validating XML editor - debug
- XML Copy Editor is an XML editor focusing on editing document markup
- languages like DITA, DocBook, WordprocessingML. It features DTD/XML
- Schema/RELAX NG validation, XSLT, XPath, pretty-printing, syntax
- highlighting, folding, tag completion/locking, and a spelling/style check.
- .
- This package contains the debugging symbols.
diff -Nru xmlcopyeditor-1.2.1.3/debian/rules xmlcopyeditor-
1.2.1.3/debian/rules
--- xmlcopyeditor-1.2.1.3/debian/rules 2020-05-27 07:47:55.0 -0400
+++ xmlcopyeditor-1.2.1.3/debian/rules 2022-09-13 14:38:38.0 -0400
@@ -90,7 +90,7 @@
sed -i 's/\r//g'
$(CURDIR)/debian/xmlcopyeditor/usr/share/applications/xmlcopyeditor.desktop
dh_installman debian/xmlcopyeditor.1
dh_link
- dh_strip --dbg-package=xmlcopyeditor-dbg
+ dh_strip --dbgsym-migration='xmlcopyeditor-dbg (<< 1.2.1.3-4.2~)'
dh_compress
dh_fixperms
[ ! -e /usr/bin/dh_buildinfo ] || dh_buildinfo
signature.asc
Description: This is a digitally signed message part
Bug#1019702: RM: golang-golang.zx2c4-go118-netip -- RoQA; superseded by stdlib in Go1.18
On Tue, Sep 13 2022, Shengjing Zhu wrote: > I have updated wireguard-go last month. > > Currently dak doesn't complain about the removal. Oh excellent! No concerns from me then. - John
Bug#1019375: Not started under wayland/plasma
Hi Didier, first thanks for the bug report. I only have a single Wayland system and that's clearly not yet ready for production use and currently offline. Didier 'OdyX' Raboud wrote: > https://bugs.debian.org/855868 suggests that a similar script as > present in /etc/Xsession.d should be placed in > /usr/lib/systemd/user-environment-generators/ for systemd/wayland > systems to benefit from unburden-home-dir. So this is only needed in the combination of Wayland AND systemd? That kinda sounds weird. > As a temporary local configuration, I've done this; > > # mkdir -p /etc/systemd/user-environment-generators/ > # cp /etc/X11/Xsession.d/95unburden-home-dir > /etc/systemd/user-environment-generators/ Thanks for that tip. Is there a reason why you've copied it instead of e.g. a symlink? > Will report back if that helps. And thanks for that, too, in advance. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1019375: #1019375: Not started under wayland/plasma
Hello again, https://bugs.debian.org/855868 suggests that a similar script as present in /etc/Xsession.d should be placed in /usr/lib/systemd/user-environment-generators/ for systemd/wayland systems to benefit from unburden-home-dir. As a temporary local configuration, I've done this; # mkdir -p /etc/systemd/user-environment-generators/ # cp /etc/X11/Xsession.d/95unburden-home-dir /etc/systemd/user-environment-generators/ Will report back if that helps. Best, OdyX 8 septembre 2022 08:03 "Didier 'OdyX' Raboud" a écrit: > Package: unburden-home-dir > Version: 0.4.2 > Severity: important > > Hello Axel, > > with KDE's Plasma under Wayland, unburden-home-dir isn't started at all, > although other XSession.d scripts are. > > What am I doing wrong? > > Best, > Didier > > -- System Information: > Debian Release: bookworm/sid > APT prefers buildd-unstable > APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (1, > 'buildd-experimental'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_CH:fr > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages unburden-home-dir depends on: > ii dpkg 1.21.9 > ii libconfig-file-perl 1.54-1 > ii libfile-basedir-perl 0.09-1 > ii libfile-rsync-perl 0.49-2 > ii libfile-touch-perl 0.12-1 > ii libfile-which-perl 1.27-1 > ii libipc-run-perl 20220807.0-1 > ii libstring-expand-perl 0.04-4 > ii libtry-tiny-perl 0.31-1 > ii perl 5.34.0-5 > > Versions of packages unburden-home-dir recommends: > ii lsof 4.95.0-1 > ii x11-common 1:7.7+23 > > Versions of packages unburden-home-dir suggests: > pn agedu > pn autotrash > pn bleachbit > pn corekeeper > ii eatmydata 130-2 > pn fslint > pn ncdu | baobab | filelight | xdiskusage | xdu > pn tmpreaper > pn unburden-home-dir-doc > > -- Configuration Files: > /etc/default/unburden-home-dir changed: > UNBURDEN_HOME=true > > /etc/unburden-home-dir.list changed: > m D .thumbnails thumbnails > m D .ccache ccache > m d .config/google-chrome/*/Thumbnails google-chrome-thumbnails-%1 > m f .config/google-chrome/*/Thumbnails-journal > google-chrome-thumbnails-journal-%1 > m d .config/chromium/*/Thumbnails chromium-thumbnails-%1 > m f .config/chromium/*/Thumbnails-journal chromium-thumbnails-journal-%1 > m d .mozilla/default/*/Cache mozilla-default-cache-%1 > m d .mozilla/default/*/startupCache mozilla-default-startup-cache-%1 > m d .mozilla/firefox/*/Cache firefox-cache-%1 > m d .mozilla/firefox/*/startupCache firefox-startup-cache-%1 > m d .mozilla/firefox/*/Cache.Trash firefox-cache-trash-%1 > m d .conkeror.mozdev.org/conkeror/*/Cache conkeror-cache-%1 > m d .conkeror.mozdev.org/conkeror/*/startupCache conkeror-startup-cache-%1 > m d .conkeror.mozdev.org/conkeror/*/Cache.Trash conkeror-cache-trash-%1 > m d .kazehakase/mozilla/kazehakase/Cache kazehakase-cache > m d .galeon/mozilla/galeon/Cache galeon-cache > m d .gnome2/epiphany/mozilla/epiphany/Cache epiphany-cache > m d .xxxterm/cache xxxterm-cache > m d .forg/cache forg-cache > m d .opera/cache opera-cache > m d .opera/cache4 opera-cache4 > m d .opera/opcache opera-opcache > m d .opera/cacheOp opera-cacheOp > m d .config/qupzilla/profiles/*/networkcache qupzilla-cache-%1 > m d .thunderbird/*/Cache thunderbird-cache-%1 > m d .mozilla-thunderbird/*/Cache debian-thunderbird-cache-%1 > m d .icedove/*/Cache icedove-cache-%1 > m d .buzzbird/*/Cache buzzbird-cache > m f .aptitude/cache aptitude-cache > m d .wesnoth*/cache wesnoth%1-cache > m d .gaia/cache gaia-cache > m d .googleearth/Cache google-earth-cache > m d .java/deployment/cache java-deployment-cache > m d .adobe/Acrobat/*/Cache adobe-acrobat-%1-cache > m d .shotwell/thumbs shotwell-thumbs > m D .sxiv sxiv-thumbs > m D .devscripts_cache devscripts_cache > r D .Trash trash > r D .local/Trash local-trash > r D Downloads downloads > r D Téléchargements downloads > > -- no debconf information
Bug#1019702: RM: golang-golang.zx2c4-go118-netip -- RoQA; superseded by stdlib in Go1.18
Hi, On Wed, Sep 14, 2022 at 2:05 AM John Goerzen wrote: > > Hello, > > Yggdrasil depends on wireguard-go, which (in the version Yggdrasil > wants), depends on netip. > I have updated wireguard-go last month. Currently dak doesn't complain about the removal. $ ssh mirror.ftp-master.debian.org "dak rm -Rn golang-golang.zx2c4-go118-netip" Will remove the following packages from unstable: golang-golang.zx2c4-go118-netip | 0.0~git2021.a4a02ee-3 | source golang-golang.zx2c4-go118-netip-dev | 0.0~git2021.a4a02ee-3 | all Maintainer: Debian Go Packaging Team --- Reason --- -- Checking reverse dependencies... No dependency problem found. > A newer version of wireguard-go does drop that dep. I guess we could > see about packaging that and see if it works with Yggdrasil? Yggdrasil > still supports 1.17 upstream which may be why they haven't updated the > dep yet. > -- Shengjing Zhu
Bug#1019702: RM: golang-golang.zx2c4-go118-netip -- RoQA; superseded by stdlib in Go1.18
Hello, Yggdrasil depends on wireguard-go, which (in the version Yggdrasil wants), depends on netip. A newer version of wireguard-go does drop that dep. I guess we could see about packaging that and see if it works with Yggdrasil? Yggdrasil still supports 1.17 upstream which may be why they haven't updated the dep yet. John On Tue, Sep 13 2022, Shengjing Zhu wrote: > Package: ftp.debian.org > Severity: normal > X-Debbugs-Cc: z...@debian.org, jgoer...@complete.org > > This library is a temporary copy of golang 1.18 stdlib for old go versions. > Now golang 1.18 is the default version in unstable/testing for a while, so > this > library is no longer useful.
Bug#1019549: fetchmail: can't accept options while a background fetchmail is running.
Control: tags -1 +moreinfo Hi, On Sun, Sep 11, 2022 at 9:42 PM Helge Kreutzmann wrote: > Since upgrading I get the error message: > fetchmail: can't accept options while a background fetchmail is running. > argc = 3, arg list: > arg 1 = "-a" > arg 2 = "-s" > > This also happens when called on the command line. > > However, fetchmail is not intended to run in the background, expecially: > > # cat /etc/default/fetchmail > … > # Declare here if we want to start fetchmail. 'yes' or 'no' > START_DAEMON=no Yes, this is for the initscripts. > But somehow it is in the background: > helge 2994 0.0 0.0 13984 8216 ?Ss 20:07 0:00 fetchmail > --nodetach --daemon 300 I think it is started by systemd. What do you get when issuing the following commands? $ systemctl --user status fetchmail.service $ systemctl --user disable fetchmail.service $ systemctl --user stop fetchmail.service # systemctl --global disable fetchmail (Please be aware the last command is run as root.) > In the system logs (from boot until now) I get lots of errors: This means the service is indeed installed and is in use. After executing the commands above, run your "fetchmail -a -s" again and see how it goes now. Sorry for the inconvenience, Laszlo/GCS
Bug#1019706: src:r-bioc-monocle: fails to migrate to testing for too long: new dependency not ready to migrate
Source: r-bioc-monocle Version: 2.22.0-2 Severity: serious Control: close -1 2.24.1-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing [1]. Your package src:r-bioc-monocle has been trying to migrate for 61 days [2]. Hence, I am filing this bug. Your package has a new dependency, but that dependency isn't ready to migrate yet. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=r-bioc-monocle OpenPGP_signature Description: OpenPGP digital signature
Bug#1019705: python-cachecontrol: release 0.12.12 was yanked from PyPI
Source: python-cachecontrol Version: 0.12.12-1 Severity: important X-Debbugs-Cc: cru...@debian.org https://pypi.org/project/CacheControl/0.12.12/ There should be a 0.13 with the lockfile → filelock changed dependency. https://github.com/ionrock/cachecontrol/issues/286 -- Michael R. Crusoe
Bug#1019704: poedit: Error msg on startup (wxwidgets3.2 regression?)
Package: poedit Severity: important Version: 3.1.1-2 X-Debbugs-CC: locutusofb...@debian.org gus...@debian.org Hi, Thanks for uploading poedit for wxwidgets3.2 transition. However, the rebuilt poedit would show the following error message as a popup window when opening a .PO file: can't open file '/org/gtk/libgtk/icons/16x16/actions/text-x-generic.png' (error 2: no such file or directory) Failed to load image from file "/org/gtk/libgtk/icons/16x16/actions/text-x- generic.png" Could you please look into it? Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#1019703: ITP: inkscape-silhouette -- inkscape extension to drive a Silhouette plotter
Package: wnpp Severity: wishlist Owner: Adam Borowski X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: inkscape-silhouette Version : 1.26+ Upstream Author : Juergen Weigert and contributors * URL : https://github.com/fablabnbg/inkscape-silhouette * License : GPL Programming Lang: Python Description : inkscape extension to drive a Silhouette plotter An extension to drive a Silhoutte Cameo and similar plotter devices from within inkscape. . You can access it via “Extensions -> Export -> Send to Silhouette” and “ ... -> Silhouette Multi Action”. . Supported devices: * Silhouette Portrait * Silhouette Portrait 2 * Silhouette Portrait 3 * Silhouette Cameo * Silhouette Cameo 2 * Silhouette Cameo 3 * Silhouette Cameo 4 * Silhouette Cameo 4 Pro * Silhouette Curio * Craft Robo CC200-20 * Craft Robo CC300-20 * Silhouette SD 1 * Silhouette SD 2
Bug#1019702: RM: golang-golang.zx2c4-go118-netip -- RoQA; superseded by stdlib in Go1.18
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: z...@debian.org, jgoer...@complete.org This library is a temporary copy of golang 1.18 stdlib for old go versions. Now golang 1.18 is the default version in unstable/testing for a while, so this library is no longer useful.
Bug#1012196: buglist
> No, you have not got it. But maybe this is because of a change in the GitHub release page: > > $ uscan --download-current-version > uscan warn: In debian/watch no matching hrefs for version 4.1.2 in watch line > https://github.com/exaile/exaile/releases .*/?(\d\.\d.\d*)\.tar\.gz Works if use the tags page instead of releases. > Hm... very-long-line-length-in-source-file is sometimes a good hint for non-source files. > Are the tagged files source files? What is their copyright status? Do the tests/data/music/delerium/chimera/05 - Truly* > files stem from a Delerium-copyrighted file? If so, is that song DFSG-free licensed? Else, you have to remove the files > from the Debian package. > This are only test files. How can I remove the files just in the debian package?
Bug#805646: [Pkg-openssl-devel] Bug#805646: Bug#805646: Package using openssl functions does not find default certificates
On Tue, Sep 13, 2022 at 06:40:19PM +0200, Sebastian Andrzej Siewior wrote: > On 2022-09-13 18:30:05 [+0200], Kurt Roeckx wrote: > > > > 3) provide a symlink from /usr/lib/ssl/cert.pem to > > > >/etc/ssl/certs/ca-certificates.crt > > > > > > Kurt, I tend to provide this symlink. Any objections? > > > I'm kind of confused that it works for others, like curl. But I don't > > > see anything wrong with what is done in this bug report. > > > > We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages. > > what I see is: > | openat(AT_FDCWD, "/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3 > | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such > file or directory) > | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such > file or directory) > > This is X509_CERT_FILE / X509_get_default_cert_file(). > > So it would need a symlink from this non existing file to > /etc/ssl/certs/ca-certificates.crt which is provided/ created by > ca-certificates. That works for me. Kurt
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
Hank Barta writes: > ** Kernel log: > [ 723.735217] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 > [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 > [ 723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 > [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 > [ 723.761324] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 > [ 723.767851] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x > [ 723.774379] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x > [ 723.780905] mmc0: sdhci: Host ctl2: 0x > [ 723.785404] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x > [ 723.791930] mmc0: sdhci: > [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt. These repeated messages are normal on the RPi4 if you boot it without an SD card. E.g. from USB or network. If that's what you intend to do, then you can avoid the repeated messages by adding dtparam=sd_poll_once=on to the config.txt file in your firmware partition. Often mounted as /boot/firmware/. The effect depends on which device-tree you are using. I believe it will only work with the ones coming with the Raspberry Pi firmware. See https://github.com/raspberrypi/firmware/blob/master/boot/overlays/README for docs. Bjørn
Bug#805646: [Pkg-openssl-devel] Bug#805646: Package using openssl functions does not find default certificates
On Tue, Sep 13, 2022 at 05:23:43PM +0200, Sebastian Andrzej Siewior wrote: > On 2016-01-04 23:50:10 [+0100], Jan Dittberner wrote: > > I don't know whether this will have negative side effects but from my point > > of view it would be nice if the openssl package would do one of the > > following to properly solve this issue: > > > > 1) properly load certificates from /etc/ssl/certs when > >SSL_CTX_set_default_verify_paths is called > > so I guess this works but it does not provide what it should provide, > right Kurt? > > > 2) change the default paths to /etc/ssl/certs and > >/etc/ssl/certs/ca-certificates.crt instead of /usr/lib/ssl/certs and > >/usr/lib/ssl/cert.pem > > > > 3) provide a symlink from /usr/lib/ssl/cert.pem to > >/etc/ssl/certs/ca-certificates.crt > > Kurt, I tend to provide this symlink. Any objections? > I'm kind of confused that it works for others, like curl. But I don't > see anything wrong with what is done in this bug report. We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages. Kurt
Bug#805646: [Pkg-openssl-devel] Bug#805646: Package using openssl functions does not find default certificates
On 2022-09-13 18:30:05 [+0200], Kurt Roeckx wrote: > > > 3) provide a symlink from /usr/lib/ssl/cert.pem to > > >/etc/ssl/certs/ca-certificates.crt > > > > Kurt, I tend to provide this symlink. Any objections? > > I'm kind of confused that it works for others, like curl. But I don't > > see anything wrong with what is done in this bug report. > > We have a symlink from /usr/lib/ssl/certs to /etc/ssl/certs for ages. what I see is: | openat(AT_FDCWD, "/usr/lib/ssl/openssl.cnf", O_RDONLY) = 3 | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory) | openat(AT_FDCWD, "/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory) This is X509_CERT_FILE / X509_get_default_cert_file(). So it would need a symlink from this non existing file to /etc/ssl/certs/ca-certificates.crt which is provided/ created by ca-certificates. > Kurt Sebastian
Bug#636977:
hello how are you doing
Bug#1019701: RFP: rpi-imager -- Raspberry Pi Imaging Utility
Package: wnpp Severity: wishlist * Package name: rpi-imager Version : 1.7.3 Upstream Author : Raspberry Pi * URL : https://github.com/raspberrypi/rpi-imager * License : Apache-2.0 Programming Lang: C++ Description : Raspberry Pi Imaging Utility Raspberry Pi Imager is the quick and easy way to install Raspberry Pi OS and other operating systems (but not Debian) to a microSD card, ready to use with your Raspberry Pi.
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
Behavior not seen before - panic during boot. https://photos.app.goo.gl/txcEsUCJuqMGmK1K6 -- Beautiful Sunny Winfield
Bug#1019284: transition: linphone-stack
Hi, only ortp has reverse dependencies outside of the linphone stack that will need >> a binNMU. They have been successfully built against the version in experimental. bcg729 trx libosmo-abis libosmo-netif osmo-bts Please go ahead All uploaded and built on all release architectures. As far as I can see, only libosmo-abis and trx need a binNMU. Bernhard
Bug#1010604: Support commonly used providers like github.com and gitlab.com within watch file
On Thu, 05 May 2022 16:06:14 +0530 Pirate Praveen wrote: Package: devscripts Severity: wishlist Currently when github or gitlab.com changes their tags page format, every affected package will need an update (#1010598). If this is centrally handled by uscan things will be much easier, we will only need to fix this in a single place. Now the release pages of both Gitlab and GitHub generate their hrefs via JavaScript which kills uscan for them. See #1019696. They should both have an API to handle this.
Bug#1019700: mmc0: Timeout waiting for hardware cmd interrupt.
Package: src:linux Version: 5.19.6-1 Severity: important X-Debbugs-Cc: hba...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Apparent inability to initialize/connect to the SD card H/W. This leads to the message below that is repeated about every 10s. It can manifest three ways. 1. Failure to boot - continuous retries to read SD card. 2. If a USB SSD is connected, it can skip the SD card and boot from the SATA SSD. (That is the coneition as I prepare this report.) 3. Completes boot, message repeats and there are no /dev/mmc* entries and WiFi H/W is not recognozed. 4. Completes boot, messages are repeated but /dev/mmc entries are present and can mount/read an SD card. And WiFi appears to be working 5. Completes boot, no SD card timeout messages are reported and system operates normally. * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? I build kernel 5.19.8 and found the same problem behavior. I booted a different SSD with Bullseye installed and on 5.10.0 kernel and do not see this issue. (Likely unrelated - The 5.10 and 5.19.0 kernels had a lot of vc4 related errors that seem to be fixed in 5.19.8) Additional information: The 5.19.8 kernel was built with the options found at https://github.com/HankB/Debian-Arm64-kernel-for-Pi-4B-on-X86_64 I have saved dmesg output from a normal boot and a boot that exhibted the timeout (but was otherwise able to complete booting) in paste.dmesg.net Normal - https://paste.debian.net/1253718/ Timeout - https://paste.debian.net/1253719/ Since the kernel log below doesn't include the information at the beginning of `dmesg` I will capture again. Or I won't. It already overflowed the dmesg buffer. If needed for this kernel I can dupicate the situation and capture before it overflows. -- Package-specific info: ** Version: Linux version 5.19.0-1-arm64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-09-01) ** Command line: video=HDMI-A-1:1600x1200M@60 dma.dmachans=0x37f5 bcm2709.boardrev=0xc03111 bcm2709.serial=0x44557cae bcm2709.uart_clock=4800 bcm2709.disk_led_gpio=42 bcm2709.disk_led_active_low=0 smsc95xx.macaddr=DC:A6:32:09:C6:71 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait ** Tainted: WC (1536) * kernel issued warning * staging driver was loaded ** Kernel log: [ 723.735217] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 723.741743] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 723.748270] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 [ 723.754797] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 [ 723.761324] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 [ 723.767851] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x [ 723.774379] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 723.780905] mmc0: sdhci: Host ctl2: 0x [ 723.785404] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 723.791930] mmc0: sdhci: [ 733.923993] mmc0: Timeout waiting for hardware cmd interrupt. [ 733.929837] mmc0: sdhci: SDHCI REGISTER DUMP === [ 733.936364] mmc0: sdhci: Sys addr: 0x | Version: 0x1002 [ 733.942892] mmc0: sdhci: Blk size: 0x | Blk cnt: 0x [ 733.949420] mmc0: sdhci: Argument: 0x | Trn mode: 0x [ 733.955946] mmc0: sdhci: Present: 0x1fff | Host ctl: 0x0001 [ 733.962473] mmc0: sdhci: Power: 0x000f | Blk gap: 0x0080 [ 733.969001] mmc0: sdhci: Wake-up: 0x | Clock:0xfa07 [ 733.975528] mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 [ 733.982055] mmc0: sdhci: Int enab: 0x00ff1003 | Sig enab: 0x00ff1003 [ 733.988582] mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 [ 733.995109] mmc0: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525 [ 734.001636] mmc0: sdhci: Cmd: 0x0502 | Max curr: 0x00080008 [ 734.008163] mmc0: sdhci: Resp[0]: 0x01aa | Resp[1]: 0x [ 734.014689] mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x [ 734.021216] mmc0: sdhci: Host ctl2: 0x [ 734.025716] mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x [ 734.032242] mmc0: sdhci: [ 744.164283] mmc0: Timeout waiting for hardware cmd interrupt. [ 744.170128] mmc0: sdhci: SDHCI REGISTER DUMP === [ 744.176655] mmc0: sdhci: Sys addr: 0x | Version: 0x1002 [ 744.183183] mmc0: sdhci: Blk size: 0x | Blk cnt: 0x [ 744.189711] mmc0:
Bug#1019518: ITP: gitsign -- keyless git signing using sigstore
On 2022-09-11 00:04:54, Leo Antunes wrote: > Package: wnpp > Severity: wishlist > Owner: Leo Antunes > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: gitsign > Version : 0.3.0 > Upstream Author : The Sigstore Authors > * URL : https://sigstore.dev > * License : Apache 2.0 > Programming Lang: go > Description : keyless git signing using sigstore > > Tool for keyless signing of git commits based on sigstore. It looks like a better URL for this would be: https://github.com/sigstore/gitsign ... which is fairly new (May 2022). I knew about sigstore but couldn't quite figure out how to integrate it in our workflow, so this is actually quite useful to know... Thanks for working on that package! -- That's the kind of society I want to build. I want a guarantee - with physics and mathematics, not with laws - that we can give ourselves real privacy of personal communications. - John Gilmore
Bug#1019697: debootstrap: aid reproducible boostrapping by providing a --cleanup-logs option
Package: debootstrap Version: 1.0.127 Severity: wishlist X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, using debootstrap 1.0.127 it's possible to reproducible bootstrap Debian, provided one does three extra steps: 1. rm /var/log/dpkg.log /var/log/alternatives.log /var/log/bootstrap.log 2. rm /etc/machine-id /var/cache/ldconfig/aux-cache 3. SOURCE_DATE_EPOCH=$some_sane_value ; sudo tar --mtime="@$SOURCE_DATE_EPOCH" --clamp-mtime $SUITE -cf $SUITE.tar This bug is about the first step. It would be really nice if debootstrap had an option called --cleanup-logs which would delete those logs. Step 2 (or rather it's first part) is tracked via #1018740: "debootstrap: better initialisation of /etc/machine-id". Step 3 would be another new feature for debootstrap, namely to create tar archives. Thanks for maintaining debootstrap! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "I know what you're thinking" used to be an idiom but now it's a business model. signature.asc Description: PGP signature
Bug#1019698: cdebootstrap: aid reproducible boostrapping by providing a --cleanup-logs option
Package: cdebootstrap Version: 0.7.8 Severity: wishlist X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, using cdebootstrap 0.7.8 it's possible to reproducible bootstrap Debian, provided one does three extra steps: 1. rm /var/log/dpkg.log /var/log/alternatives.log /var/log/bootstrap.log /var/log/apt/history.log /var/log/apt/term.log 2. rm /etc/machine-id /var/cache/ldconfig/aux-cache 3. SOURCE_DATE_EPOCH=$some_sane_value ; sudo tar --mtime="@$SOURCE_DATE_EPOCH" --clamp-mtime $SUITE -cf $SUITE.tar This bug is about the first step. It would be really nice if cdebootstrap had an option called --cleanup-logs which would delete those logs. Step 2 (or rather it's first part) is tracked via #1018741: "cdebootstrap: better initialisation of /etc/machine-id". Step 3 would be another new feature for cdebootstrap, namely to create tar archives. Thanks for maintaining cdebootstrap! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Homelessness exists not because the housing systemn is not working, but because this is the way it works. - Peter Marcuse. signature.asc Description: PGP signature
Bug#805646: Package using openssl functions does not find default certificates
On 2016-01-04 23:50:10 [+0100], Jan Dittberner wrote: > I don't know whether this will have negative side effects but from my point > of view it would be nice if the openssl package would do one of the > following to properly solve this issue: > > 1) properly load certificates from /etc/ssl/certs when >SSL_CTX_set_default_verify_paths is called so I guess this works but it does not provide what it should provide, right Kurt? > 2) change the default paths to /etc/ssl/certs and >/etc/ssl/certs/ca-certificates.crt instead of /usr/lib/ssl/certs and >/usr/lib/ssl/cert.pem > > 3) provide a symlink from /usr/lib/ssl/cert.pem to >/etc/ssl/certs/ca-certificates.crt Kurt, I tend to provide this symlink. Any objections? I'm kind of confused that it works for others, like curl. But I don't see anything wrong with what is done in this bug report. > Best regards > Jan Dittberner Sebastian
Bug#1019696: devscripts: uscan does not work with github anymore
Package: devscripts Version: 2.22.2 Severity: important Hello, github made some annoying changes to the release download pages (lazy loading?) All debian/watch files using github are failing now: version=4 https://github.com/liske/needrestart/releases \ /liske/needrestart/archive/refs/tags/v(.+)\.tar\.gz $ uscan -v --debug uscan info: uscan (version 2.22.2~bpo11+1) See uscan(1) for help uscan info: Scan watch files in . uscan info: Check debian/watch and debian/changelog in . uscan info: package="needrestart" version="3.6-2" (as seen in debian/changelog) uscan info: package="needrestart" version="3.6" (no epoch/revision) uscan info: ./debian/changelog sets package="needrestart" version="3.6" uscan info: Process watch file at: debian/watch package = needrestart version = 3.6 pkg_dir = . uscan info: Last orig.tar.* tarball version (from debian/changelog): 3.6 uscan info: Last orig.tar.* tarball version (dversionmangled): 3.6 uscan info: Requesting URL: https://github.com/liske/needrestart/releases uscan info: Matching pattern: (?:(?:https://github.com)?\/liske\/needrestart\/)?/liske/needrestart/archive/refs/tags/v(.+)\.tar\.gz uscan warn: In debian/watch no matching files for watch line https://github.com/liske/needrestart/releases /liske/needrestart/archive/refs/tags/v(.+)\.tar\.gz uscan info: Scan finished -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- export DGET_VERIFY=no -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-18-amd64 (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.20.12 ii fakeroot 1.25.3-1.1 ii file 1:5.39-3 ii gnupg 2.2.27-2+deb11u2 ii gnupg22.2.27-2+deb11u2 ii gpgv 2.2.27-2+deb11u2 ii libc6 2.31-13+deb11u4 ii libfile-dirlist-perl 0.05-2 ii libfile-homedir-perl 1.006-1 ii libfile-touch-perl0.11-1 ii libfile-which-perl1.23-1 ii libipc-run-perl 20200505.0-1 ii libmoo-perl 2.004004-1 ii libwww-perl 6.52-1 ii patchutils0.4.2-1 ii perl 5.32.1-4+deb11u2 ii python3 3.9.2-3 ii sensible-utils0.0.14 ii wdiff 1.2.2-2+b1 Versions of packages devscripts recommends: ii apt 2.2.4 ii curl7.74.0-1.3+deb11u3 ii dctrl-tools 2.24-3+b1 pn debian-keyring ii dput1.1.0 ii dupload 2.9.7 pn equivs ii libdistro-info-perl 1.0 ii libdpkg-perl1.20.12 ii libencode-locale-perl 1.05-1.1 pn libgit-wrapper-perl pn libgitlab-api-v4-perl ii liblist-compare-perl0.55-1 ii liblwp-protocol-https-perl 6.10-1 pn libsoap-lite-perl ii libstring-shellquote-perl 1.04-1 ii libtry-tiny-perl0.30-1 ii liburi-perl 5.08-1 ii licensecheck3.1.1-2 ii lintian 2.115.3 ii man-db 2.9.4-2 ii patch 2.7.6-7 pn pristine-tar ii python3-apt 2.2.1 ii python3-debian 0.1.39 pn python3-magic ii python3-requests2.25.1+dfsg-2 pn python3-unidiff pn python3-xdg ii strace 5.10-1 ii unzip 6.0-26+deb11u1 ii wget1.21-1+deb11u1 ii xz-utils5.2.5-2.1~deb11u1 Versions of packages devscripts suggests: pn adequate ii at 3.1.23-1.1 pn autopkgtest pn bls-standalone ii bsd-mailx [mailx]8.1.2-0.20180807cvs-2 ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper13.3.4 pn diffoscope pn disorderfs pn dose-extra pn duck pn elpa-devscripts pn faketime pn gnuplot pn how-can-i-help pn libauthen-sasl-perl pn libdbd-pg-perl pn libfile-desktopentry-perl pn libnet-smtps-perl pn libterm-size-perl ii libtimedate-perl 2.3300-2 pn libyaml-syck-perl pn mmdebstrap pn mozilla-devscripts ii mutt 2.0.5-4.1+deb11u1 ii openssh-client
Bug#908059: close
For some reason I never got email notification of the request for further information. (at Sun, 2 Dec 2018 13:42:19 +0100) I am no longer experiencing this issue and this can be closed. It's not clear to me how to do that. Thanks! -- Beautiful Sunny Winfield
Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines
Control: noowner -1 Control: retitle -1 O: cfengine3 -- configures network machines X-Debbugs-Cc: christoph.mar...@uni-mainz.de Now that there have been two NMUs since Fabio intended to adopt this package it is safe to assume that this will not happen anytime soon. We should give people a chance to actually adopt cfengine3. Christoph Martin is a member of https://salsa.debian.org/cfengine-team. Christoph, you would be the best candidate to take control over this package. Would you like to take on this responsibility and can you shine some light on why this is in a Gitlab team but not team-maintained?
Bug#1004308: smokeping: New upstream version 2.8.2 needs to be packaged
Hi Micheal, On 2022-09-13 01 h 50, Michael Prokop wrote: * Gabriel Filion [Mon Jan 24, 2022 at 10:53:27AM -0500]: Upstream has released a new version of smokeping, 2.8.2 and it would be helpful to upgrade the debian package to this version since it contains a number of fixes, some of which would remove patches in the package. I've received two emails directly requesting the new version so I'm creating this bug report to reflect their wish to have this version. Friendly ping, that v2.8.2 was released on 2021-08-13 and the freeze for Debian/bookworm is coming closer. :) Would be great to have the new smokeping version in the upcoming Debian stable release. Thanks for maintaining smokeping! thanks for the ping! I've been concentrated on another project recently but you're totally right, I should make the last efforts required to get that version into testing soon! The current state of things is that the new lib dependency to version 2.8.2, libobject-result-perl, is created and I've received some feedback from the perl team: https://lists.debian.org/debian-perl/2022/09/msg5.html I should fix the license text and maybe open a bug report upstream for the typo. In the mean time, I'm wondering if you're willing to help out a bit with reviewing my work on smokeping, that way we could move faster once the perl lib is in unstable. Upstream version 2.8.2 was merged onto the "master" branch. IIRC it's currently awaiting the dependency and then should be ready for review/sponsorship (but there might still be lintian issues that I haven't looked at because of the new library) https://salsa.debian.org/debian/smokeping cheers!
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
Hi, IIUC this is about fixing 2 non-security bugs, that were introduced prior to buster's initial release. I personally don't think this fits the LTS project scope. Maybe other LTS members will have a different opinion. Cheers! Sylvain Beucler Debian LTS Team On 13/09/2022 15:27, Santiago R.R. wrote: El 10/09/22 a las 19:11, Adam D. Barratt escribió: On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 I've uploaded a fixed version to unstable yesterday. It would be great to fix it also in buster. Please, consider the attached debdiff. Would it be OK for you to upload it? Apologies for apparently letting this sit unanswered. (FTR there was a reply from a non-SRM member 18 months ago.) And I am sorry I missed that answer. The final point release for buster has now happened, so any further updates to packages in buster will need to be handled via LTS. I'm therefore going to close this request now. [snip] I am forwarding this to the LTS folks, so they can decide about this change.
Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1
Hi Raphaël, I tried to reproduce this issue, but I did not succeed. Le jeu. 9 juin 2022 à 14:51, Raphaël Hertzog a écrit : > > When I had the issue, I tried to open "about:support", it also triggered > one of those freezes but in the end I was able to see that firefox was > using "alsa" as audio-backend. Installing wireplumber is (in theory) enough to make firefox using its pulse-rust audio backend. Thus having alsa as audio backend results probably from a conflict, don't know which one. Do you have a special audio configuration? > Now that I switched back to "pipewire-media-session" and that firefox is > now behaving correctly, I see that it uses the "pulse-rust" audio backend. > > So somehow, wireplumber + pipewire-pulse is not properly > detected as something that can be controlled with the "pulse-rust" audio > backend when it likely should be that way... > May I ask you to give wireplumber a second chance to check if you can reproduce this issue? Just install wireplumber, this will remove pipewire-media-session. No need to remove the "with-pulseaudio" file. After a reboot I hope everything will be fine. Best, Dylan
Bug#1019695: r-cran-qpdf: FTBFS with qpdf 11.0.0
Source: r-cran-qpdf Version: 1.2.0+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) https://buildd.debian.org/status/fetch.php?pkg=r-cran-qpdf=amd64=1.2.0%2Bdfsg-1%2Bb1=1663060773=0 g++ -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG -I/usr/include/qpdf/ -I'/usr/lib/R/site-library/Rcpp/include' -fvisibility=hidden -fpic -g -O2 -ffile-prefix-map=/build/r-base-J8F88F/r-base-4.2.1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c bindings.cpp -o bindings.o In file included from /usr/include/qpdf/Buffer.hh:26, from /usr/include/qpdf/QPDF.hh:37, from bindings.cpp:1: /usr/include/qpdf/PointerHolder.hh:31:3: warning: #warning "POINTERHOLDER_TRANSITION is not defined -- see qpdf/PointerHolder.hh" [-Wcpp] 31 | # warning "POINTERHOLDER_TRANSITION is not defined -- see qpdf/PointerHolder.hh" | ^~~ bindings.cpp: In function ‘QPDF read_pdf_with_password(const char*, const char*)’: bindings.cpp:27:10: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 27 | return pdf; | ^~~ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ bindings.cpp: In function ‘int cpp_pdf_length(const char*, const char*)’: bindings.cpp:32:53: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 32 | QPDF pdf = read_pdf_with_password(infile, password); | ^ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ bindings.cpp: In function ‘Rcpp::CharacterVector cpp_pdf_split(const char*, std::string, const char*)’: bindings.cpp:41:55: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 41 | QPDF inpdf = read_pdf_with_password(infile, password); | ^ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ bindings.cpp: In function ‘Rcpp::CharacterVector cpp_pdf_select(const char*, const char*, Rcpp::IntegerVector, const char*)’: bindings.cpp:61:55: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 61 | QPDF inpdf = read_pdf_with_password(infile, password); | ^ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ bindings.cpp: In function ‘Rcpp::CharacterVector cpp_pdf_combine(Rcpp::CharacterVector, const char*, const char*)’: bindings.cpp:82:64: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 82 | QPDF inpdf = read_pdf_with_password(infiles.at(i), password); |^ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ bindings.cpp: In function ‘Rcpp::CharacterVector cpp_pdf_compress(const char*, const char*, bool, const char*)’: bindings.cpp:98:55: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 98 | QPDF inpdf = read_pdf_with_password(infile, password); | ^ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ bindings.cpp: In function ‘Rcpp::CharacterVector cpp_pdf_rotate_pages(const char*, const char*, Rcpp::IntegerVector, int, bool, const char*)’: bindings.cpp:111:55: error: use of deleted function ‘QPDF::QPDF(const QPDF&)’ 111 | QPDF inpdf = read_pdf_with_password(infile, password); | ^ /usr/include/qpdf/QPDF.hh:941:5: note: declared here 941 | QPDF(QPDF const&) = delete; | ^~~~ make[1]: *** [/usr/lib/R/etc/Makeconf:177: bindings.o] Error 1 make[1]: Leaving directory '/<>/src' make[1]: Entering directory '/<>/src' make[1]: Leaving directory '/<>/src' ERROR: compilation failed for package ‘qpdf’ * removing ‘/<>/debian/r-cran-qpdf/usr/lib/R/site-library/qpdf’ dh_auto_install: error: R CMD INSTALL -l /<>/r-cran-qpdf-1.2.0\+dfsg/debian/r-cran-qpdf/usr/lib/R/site-library --clean . "--built-timestamp='Tue, 13 Sep 2022 09:19:17 +'" returned exit code 1 make: *** [debian/rules:4: binary-arch] Error 25 dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess returned exit status 2 Cheers -- Sebastian Ramacher
Bug#1019694: pikepdf: FTBFS with qpdf 11.0.0
Source: pikepdf
Version: 5.1.1+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
https://buildd.debian.org/status/fetch.php?pkg=pikepdf=amd64=5.1.1%2Bdfsg-1%2Bb2=1663060782=0
In file included from src/qpdf/object_convert.cpp:22:
/usr/include/qpdf/PointerHolder.hh:31:3: warning: #warning
"POINTERHOLDER_TRANSITION is not defined -- see qpdf/PointerHolder.hh" [-Wcpp]
31 | # warning "POINTERHOLDER_TRANSITION is not defined -- see
qpdf/PointerHolder.hh"
| ^~~
In file included from src/qpdf/object_convert.cpp:31:
src/qpdf/pikepdf.h: In static member function ‘static pybind11::handle
pybind11::detail::type_caster::cast(const QPDFObjectHandle*,
pybind11::return_value_policy, pybind11::handle)’:
src/qpdf/pikepdf.h:96:26: error: ‘QPDFObject::object_type_e’ has not been
declared
96 | case QPDFObject::object_type_e::ot_null:
| ^
src/qpdf/pikepdf.h:99:26: error: ‘QPDFObject::object_type_e’ has not been
declared
99 | case QPDFObject::object_type_e::ot_integer:
| ^
src/qpdf/pikepdf.h:102:26: error: ‘QPDFObject::object_type_e’ has not been
declared
102 | case QPDFObject::object_type_e::ot_boolean:
| ^
src/qpdf/pikepdf.h:105:26: error: ‘QPDFObject::object_type_e’ has not been
declared
105 | case QPDFObject::object_type_e::ot_real:
| ^
src/qpdf/object_convert.cpp: In function ‘pybind11::object
decimal_from_pdfobject(QPDFObjectHandle)’:
src/qpdf/object_convert.cpp:159:40: error: ‘QPDFObject::object_type_e’ has not
been declared
159 | if (h.getTypeCode() == QPDFObject::object_type_e::ot_integer) {
|^
src/qpdf/object_convert.cpp:162:47: error: ‘QPDFObject::object_type_e’ has not
been declared
162 | } else if (h.getTypeCode() == QPDFObject::object_type_e::ot_real) {
| ^
src/qpdf/object_convert.cpp:165:47: error: ‘QPDFObject::object_type_e’ has not
been declared
165 | } else if (h.getTypeCode() ==
QPDFObject::object_type_e::ot_boolean) {
| ^
Build finished at 2022-09-13T09:19:36Z
Cheers
--
Sebastian Ramacher
Bug#1019692: ITP: mathcomp-abel -- Abel-Galois and Abel-Ruffini theorems for Mathematical Components
Package: wnpp X-Debbugs-Cc: debian-de...@lists.debian.org Owner: Julien Puydt X-Debbugs-Cc: debian-ocaml-ma...@lists.debian.org Severity: wishlist * Package name: mathcomp-abel Version : 1.2.1 Upstream Author : Sophie Bernard, Cyril Cohen, Assia Mahboubi, Pierre-Yves Strub * URL : https://github.com/math-comp/Abel * License : CeCILL-B Programming Lang: Coq Description : Abel-Galois and Abel-Ruffini theorems for Mathematical Components This package provides proofs of the Abel-Galois (solvability by radicals and solvability of the Galois group) and of the Abel-Ruffini theorem (general unsolvability of the quintic equations) using the Mathematical Components library. . The Mathematical Components library is a coherent repository of general-purpose formalized mathematical theories for the Coq proof assistant. I plan to support it within the Debian Ocaml Maintainers team, alongside the other Coq-related packages we have. Cheers, J.Puydt
Bug#1019691: ftp.debian.org: [In]Release for experimental has Suite=Codename
Package: ftp.debian.org Severity: normal Hi! Thanks for bringing back the rc-buggy -> experimental symlink. Alas, it's not functional: W: Conflicting distribution: http://apt-rosy.angband.pl:3142/debian rc-buggy InRelease (expected rc-buggy but got experimental) And indeed, InRelease has: Suite: experimental Codename: experimental while any other release has them distinct: Suite: unstable Codename: sid Suite: testing Codename: bookworm Suite: oldoldstable Codename: stretch 14:52 < pabs> yeah, its only a symlink, not a proper codename 14:52 <+Unit193> 'devel' in Ubuntu does that too. 14:52 < pabs> also infuriating 14:52 <+kilobyte> sid has Suite: unstable Codename: sid 14:52 < pabs> yes, thats a proper codename rather than just a symlink 14:53 <+urbec> long ago there was some disagreement, if rc-buggy is a codename or a bad joke 14:53 < pabs> hmm, there isn't an open bug about the rc-buggy symlink, but there is one for Ubuntu devel IIRC 14:54 <+kilobyte> urbec: why not both? :p 14:54 <+urbec> the risk about opening a bug would be that someone just might delete it. A codename that's non-functional is of no use, thus I'm going to take the risk: could you please fill in the codename?
Bug#1019437: tiger: Annoying emails due to deprecated command
Hi, todays update of the grep-package seems to have temporarily solved the problem, the warning and the mails are gone. Best regards Günter -- --- Günter Frenz Börschgasse 16a, D-51143 Köln (h) gu...@guefz.de, gu...@freenet.de (w) g.frenz@gso.schule.koeln --- pgpo19vqWIZFR.pgp Description: Digitale Signatur von OpenPGP
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
Hi, El 10/09/22 a las 19:11, Adam D. Barratt escribió: > On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: > > Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 > > CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 > > > > I've uploaded a fixed version to unstable yesterday. It would be > > great > > to fix it also in buster. Please, consider the attached debdiff. > > Would it be OK for you to upload it? > > > > Apologies for apparently letting this sit unanswered. (FTR there was a > reply from a non-SRM member 18 months ago.) And I am sorry I missed that answer. > > The final point release for buster has now happened, so any further > updates to packages in buster will need to be handled via LTS. I'm > therefore going to close this request now. [snip] I am forwarding this to the LTS folks, so they can decide about this change. Cheers, -- S signature.asc Description: PGP signature
Bug#1019689: aptsources: comments in /usr/lib/os-release cause parsing crash
Package: aptsources
Version: python-apt
Severity: normal
Tags: patch
X-Debbugs-Cc: macda...@gmail.com
Dear Maintainer,
* What led up to the situation?
adding a commented line to /usr/lib/os-release
* What exactly did you do (or not do) that was effective (or
ineffective)?
ran `add-apt-repository` command
* What was the outcome of this action?
an error:
```
Traceback (most recent call last):
File "/usr/bin/add-apt-repository", line 11, in
from softwareproperties.SoftwareProperties import SoftwareProperties,
shortcut_handler
File "/usr/lib/python3/dist-
packages/softwareproperties/SoftwareProperties.py", line 57, in
from . import shortcuts
File "/usr/lib/python3/dist-packages/softwareproperties/shortcuts.py", line
23, in
_DEF_CODENAME = aptsources.distro.get_distro().codename
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 580, in
get_distro
os_release = _OSRelease()
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 526, in
__init__
self.parse()
File "/usr/lib/python3/dist-packages/aptsources/distro.py", line 551, in
parse
self.parse_entry(*line.split('=', 1))
TypeError: _OSRelease.parse_entry() missing 1 required positional argument:
'value'
```
* What outcome did you expect instead?
the program should continue without stopping
patch:
diff --git a/aptsources/distro.py b/aptsources/distro.py
index df9bc2f5..f38907fb 100644
--- a/aptsources/distro.py
+++ b/aptsources/distro.py
@@ -545,6 +545,8 @@ class _OSRelease:
line = line.strip()
if not line:
continue
+if line[0] == "#":
+continue
self.parse_entry(*line.split('=', 1))
f.close()
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (100,
'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/aptsources/distro.py b/aptsources/distro.py
index df9bc2f5..f38907fb 100644
--- a/aptsources/distro.py
+++ b/aptsources/distro.py
@@ -545,6 +545,8 @@ class _OSRelease:
line = line.strip()
if not line:
continue
+if line[0] == "#":
+continue
self.parse_entry(*line.split('=', 1))
f.close()
diff --git a/aptsources/distro.py b/aptsources/distro.py
index df9bc2f5..f38907fb 100644
--- a/aptsources/distro.py
+++ b/aptsources/distro.py
@@ -545,6 +545,8 @@ class _OSRelease:
line = line.strip()
if not line:
continue
+if line[0] == "#":
+continue
self.parse_entry(*line.split('=', 1))
f.close()
Bug#1017944: grub-xen-host: Old grub-x86_64-xen.bin works
Package: grub-xen-host Followup-For: Bug #1017944 Dear Maintainer, with the previous grub-x86_64-xen.bin file the PV start. Packgage Version: Version: 2.04-20 ... - System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-18-amd64 (SMP w/1 CPU thread) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grub-xen-host depends on: ii grub-xen-bin 2.06-3~deb11u1 grub-xen-host recommends no packages. grub-xen-host suggests no packages. -- no debconf information
Bug#1019445: shotcut: Shotcut crashes on startup with error: File already exists in database: opencv-caffe.proto
Hi Gürkan I checked the link you gave me and many others, but no one could lead me to a solution. The output of `locate opencv-caffe.proto` is empty. Thanks, Matteo Il 13/09/22 13:57, Gürkan Myczko ha scritto: Hi Matteo, [Debug ] begin [libprotobuf ERROR google/protobuf/descriptor_database.cc:120] File already exists in database: opencv-caffe.proto [libprotobuf FATAL google/protobuf/descriptor.cc:1382] CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): terminate called after throwing an instance of 'google::protobuf::FatalException' what(): CHECK failed: GeneratedDatabase()->Add(encoded_file_descriptor, size): Aborted I am not able to reproduce the problem on my system. However the error message leads me to: https://github.com/szagoruyko/torch-opencv-demos/issues/11 can you post the output of `locate opencv-caffe.proto` from your system? Best,
Bug#1019553: FTBFS: ts_file_io
On Tue, Sep 13, 2022 at 01:52:46PM +0200, Jean Baptiste Favre wrote: > Hello Adam, > Thanks for your report. > I've unable to reproduce the build failure as of now, using both a docker > image and sbuild on my laptop (amd64 only). > > The failing test simply tries to open /etc/hosts (which should be present > inside chroot), read it and look for the string localhost inside. Not sure why it's present on your sbuild but not in mine, but in bookworm netbase (which generates /etc/hosts if none has been providen from the outside) is no longer pulled in by build-essential. Thus, an explicit Build-Depends: netbase would ensure /etc/hosts is there. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line: ⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day." ⠈⠳⣄
Bug#1019549: fetchmail: can't accept options while a background fetchmail is running.
Hi, I encounterd the problem with the same origin perhaps. I used to run fetchmail in daemon mode with keep option every 10 minutes in a machine and call fetchmail manually late at night every day with nokeep option in another main machine. But recently, in main machine, I found that fetchmail was running already as "fetchmail --nodetach --daemon 300" just after booting. This is very inconvenient for me. It seems systemd makes fetchmail to start automatically, so please provide a clear explanation how to disable fetchmail(.service ?) Thanks for your maintenance. Best regards, 2022-9-13(Tue) -- ** Atsuhito Kohda atsuhito_k AT tokushima-u.ac.jp
Bug#1019688: unace FTCBFS: uses the build architecture compiler
Source: unace Version: 1.2b-21 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs Hi Guillem, your -21 upload broke cross building by adding CC=$(CC) without initializing $(CC) properly. As far as I understand it, you deliberately added it to override the upstream choice (e.g. for supporting clang builds). Unfortunately, you failed to add proper initialization. Possibly, you thought that buildtools.mk was part of default.mk so that was sufficient, but it is not as of today. Please either include it or change default.mk in dpkg. I'm attaching a patch for the former for your convenience. Helmut diff --minimal -Nru unace-1.2b/debian/changelog unace-1.2b/debian/changelog --- unace-1.2b/debian/changelog 2022-08-18 11:28:43.0 +0200 +++ unace-1.2b/debian/changelog 2022-09-11 12:22:32.0 +0200 @@ -1,3 +1,10 @@ +unace (1.2b-21.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Let dpkg's buildtools.mk initialize CC. (Closes: #-1) + + -- Helmut Grohne Sun, 11 Sep 2022 12:22:32 +0200 + unace (1.2b-21) unstable; urgency=medium * Fix out of bounds read for .ace header comment. (Closes: #785377) diff --minimal -Nru unace-1.2b/debian/rules unace-1.2b/debian/rules --- unace-1.2b/debian/rules 2022-08-18 11:25:31.0 +0200 +++ unace-1.2b/debian/rules 2022-09-11 12:22:31.0 +0200 @@ -8,6 +8,7 @@ export DEB_CFLAGS_MAINT_APPEND = -Wall include /usr/share/dpkg/default.mk +include /usr/share/dpkg/buildtools.mk ifeq ($(DEB_HOST_ARCH_ENDIAN),little) DEB_CPPFLAGS_MAINT_APPEND += -DLO_HI_BYTE_ORDER
Bug#1019687: raku-meta6: trying to overwrite '/usr/lib/perl6/vendor/precomp/A234FA60C249CF61DEFEC1FD7D434DF2D0D597D5/0F/0F5CCC81E3EDCF1EE7139F2E5E72A089F34C3091', which is also in package raku-license
Package: raku-meta6 Version: 0.0.29-1 Severity: serious Control: affects -1 raku-license-spdx https://piuparts.debian.org/sid/fail/raku-test-meta_0.0.17-1.log ... Unpacking raku-meta6 (0.0.29-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-lXdvbj/26-raku-meta6_0.0.29-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/perl6/vendor/precomp/A234FA60C249CF61DEFEC1FD7D434DF2D0D597D5/0F/0F5CCC81E3EDCF1EE7139F2E5E72A089F34C3091', which is also in package raku-license-spdx 3.17.0-1 ...
Bug#1019686: /usr/bin/pee: moreutils: manual pages: Add EXAMPLES section
Package: moreutils Version: 0.67-1 Severity: normal File: /usr/bin/pee Tags: upstream X-Debbugs-Cc: alx.manpa...@gmail.com Hi, I'd like to see an EXAMPLES section in the moreutils manual pages showing how you'd normally use them, possibly showing several common patterns. More or less, what tldr(1) pages show. The sponge(1) page for example, abuses the SYNOPSIS a little bit to show an example. It's not a crazy idea, but separating them into a proper synopsis, and a proper examples sections might be better. The pee(1) program (in which I am interested now), doesn't have any examples at all. And it doesn't have a "conventional" usage, so it's not trivial to know how to make it work. Cheers, Alex -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages moreutils depends on: ii libc6 2.34-7 ii libipc-run-perl20220807.0-1 ii libtime-duration-perl 1.21-1 ii libtimedate-perl 2.3300-2 ii perl 5.34.0-5 moreutils recommends no packages. moreutils suggests no packages. -- no debconf information
Bug#1019453: ibus: IBus doesn't work correctly in apps that don't support surrounding text
Attached is a patch that matches the upstream PR. When first introduced IBUS_CAP_SURROUNDING_TEXT was a runtime-flag that allowed ibus engines to detect whether or not a client application supports surrounding text. This was determined by the return value of the `retrieve-surrounding` signal. If the emit of the signal returned false the conclusion was that the client app doesn't support surrounding text and the IBUS_CAP_SURROUNDING_TEXT flag was cleared. Some time later it was discovered that Firefox (which implements surrounding text) sometimes returns `false` from the signal handler for the first character, but succeeds for subsequent calls. The workaround to fix this bug was that instead of clearing the IBUS_CAP_SURROUNDING_TEXT flag a warning was output. This makes the IBUS_CAP_SURROUNDING_TEXT flag basically a compile time flag. However, this workaround has the side effect that now it is impossible for engines to detect if the client implements surrounding text. This has the effect that apps that don't implement surrounding text no longer work properly, e.g. the backspace key no longer works properly. This change tries to undo the negative side effects while still keeping the workaround for Firefox. It does this by checking the name of the client application. If the name is "firefox" we output the warning and don't touch the IBUS_CAP_SURROUNDING_TEXT flag. For other apps we assume that they don't support surrounding text and clear the flag. The risk of this change is that there might be other apps besides Firefox that implement surrounding text but fail on first call; those would fail again. On the other side this change fixes things in apps that don't support surrounding text like Chromium, Gnome Terminal, and others. From db037f77f62b3510d04b08f5c0a771f9059e8076 Mon Sep 17 00:00:00 2001 From: Eberhard Beilharz Date: Tue, 16 Aug 2022 09:24:26 +0200 Subject: [PATCH] Fix surrounding text MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When first introduced IBUS_CAP_SURROUNDING_TEXT was a runtime-flag that allowed ibus engines to detect whether or not a client application supports surrounding text. This was determined by the return value of the `retrieve-surrounding` signal. If the emit of the signal returned false the conclusion was that the client app doesn't support surrounding text and the IBUS_CAP_SURROUNDING_TEXT flag was cleared. Some time later it was discovered that Firefox (which implements surrounding text) sometimes returns `false` from the signal handler for the first character, but succeeds for subsequent calls (https://github.com/ibus/ibus/issues/2054). The workaround to fix this bug was that instead of clearing the IBUS_CAP_SURROUNDING_TEXT flag a warning was output. This makes the IBUS_CAP_SURROUNDING_TEXT flag basically a compile time flag which tells whether or not ibus can deal with surrounding text. However, this workaround has the side effect that now it is impossible for engines to detect if the client implements surrounding text. This has the effect that apps that don't implement surrounding text no longer work properly, e.g. the backspace key no longer works. Having ibus support surrounding text is only half of what's needed because the application (e.g. Chrome) also needs to support surrounding text. Currently ibus engines have no way to detect if the application supports surrounding text because the capability is always set. See #2354 for a scenario that is affected by this behavior: the user types 'n', the engine outputs 'n'. Next the user types ';', the end result should be that 'n' gets replaced by 'ŋ'. If the application supports surrounding text (e.g. gedit) the engine can use `ibus_engine_delete_surrounding_text()` to delete 'n'. However, if the application doesn't support surrounding text (e.g. Chrome, gnome-terminal) then the engine has to use `ibus_engine_forward_key_event()` to send a backspace to delete the previous character. Which means the engine needs a way to detect whether or not the application supports surrounding text. An example where this behavior can be seen is in ibus-engine-keyman with the [IPA (SIL)](https://keyman.com/keyboards/sil_ipa) keyboard. This change tries to undo the negative side effects while still keeping the workaround for Firefox. It does this by checking the name of the client application. If the name is "firefox" we output the warning and don't touch the IBUS_CAP_SURROUNDING_TEXT flag. For other apps we assume that they don't support surrounding text and clear the flag. The risk of this change is that there might be other apps besides Firefox that implement surrounding text but fail on first call; those would fail again. On the other side this change fixes things in apps that don't support surrounding text like Chromium, Gnome Terminal, and others. It turns out that before commit https://github.com/ibus/ibus/commit/7b3b8c8 the IBUS_CAP_SURROUNDING_TEXT
Bug#885777: xournal: depends on deprecated libraries
What functionality is there in Xournal, that is not in Xournalpp? It's by no means "a lot", I would think. Maybe I'm not aware of everything, but in that case it would make sense to open a ticket at the Xournalpp github repository and/or update the info on the Xournalpp website, https://xournalpp.github.io/community/other-software/#features-available-in-xournal-but-not-in-xournal_1. On Sat, 11 Jun 2022 15:46:46 +0100 Stamatis Mavrogeorgis wrote: > On Mon, 30 May 2022 14:16:47 +0200 Bastian Germann wrote: > > Could xournal be removed in favour of xournalpp? > > > > > > Xournalpp still lacks a lot of functionality that exists in Xournal and > makes it such a useful tool, hence from my (user) perspective I suggest > that Xournal is left untouched.
Bug#877414: systemd: please include a /var/log/README like Fedora has
On Mon, Sep 12, 2022 at 05:29:08PM +0200, Michael Biebl wrote: > A "rm -f /var/log/README" in postrm is simple enough, or at least not more > complicated then creating the symlink (manually) via debian/systemd.links. right. > Question is, what's conceptually more desired. Marco mentioned on IRC that > shipping a static symlink in the package conflicts with the goal, that /var > should be empty by default (see factory-reset [1]). I don't understand, however /var/log/README is provided, it always means /var isn't empty? > Seems piuparts is happy with the status quo, so maybe we don't actually need > an explicit cleanup of /var/log/README and we can just close this bug > report? usually piuparts is rightfully unhappy, though exceptions exist. :) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ That morning, the young barista woman told me that a customer came in with a mask, but not wearing it. When she asked the customer to put on her mask please, the woman said: "Why? There's no-one in here." signature.asc Description: PGP signature
Bug#1019507: ITP: libquazip1-qt6 -- Qt/C++ wrapper over minizip - Version 1 (Qt6)
Greetings, On Tue, Sep 13, 2022 at 07:51:26AM +0200, Andreas Tille wrote: Hi, Am Mon, Sep 12, 2022 at 08:08:40PM +0200 schrieb Filippo Rusconi: > Thank you for the offer, but the package was just sponsored yesterday by > Adam Borowski (kilobyte) and is in the NEW queue. If you're interested > in QuaZip for Qt5, I could package that for you to review. Well, that is pretty cool. Yes. I'd support any attempt to move the current libquazip[1] away from Debian Med team where it is just by chance since it was a dependency of some of our packages. It does not make any sense to maintain it inside the Debian Med team and I would love to hand it over. All maintainers except me do not respond to pings any more and thus can be droped from the list of Uploaders. I understand that, let's take it away from Debian Med and put it in Debian at large. Ben, if you would do the update, then I'd go over it and upload it. That would be very good. Sincerely, Filippo -- ⢀⣴⠾⠻⢶⣦⠀ Filippo Rusconi, PhD ⣾⠁⢠⠒⠀⣿⡁ Research scientist at CNRS ⢿⡄⠘⠷⠚⠋⠀ Debian Developer ⠈⠳⣄ http://msxpertsuite.org http://www.debian.org book: http://www.lavoisier.fr/livre/notice.asp?id=3LKW2OAR2KROWZ http://books.google.fr/books?id=2NmguxmEI1sC=frontcover=rusconi+f+lavoisier=fr=X=nGGOUt2SH_Ly0gX0uIHoBQ=0CDUQ6AEwAA#v=onepage=false Institut Diversité, Écologie et Évolution du Vivant Unité Génétique Quantitative et Évolution Plateforme PAPPSO Université Paris-Saclay, INRAE, UMR CNRS 8120, AgroParisTech 12, route 128, Bâtiment 680 91272 Gif-sur-Yvette France http://moulon.inrae.fr/ & http://pappso.inrae.fr/ Tel : +33 (0)1 69 33 23 54 Fax : +33 (0)1 69 33 23 40
Bug#1019684: yard: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: require "gettext/mo"
Source: yard
Version: 0.9.27-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1
Hi,
We are about to start the ruby3.1 transition in unstable. While trying to
rebuild yard with ruby3.1 enabled, the build failed.
Relevant part of the build log (hopefully):
> Failure/Error: require "gettext/mo"
>
># received :exist? with unexpected arguments
> expected: ("foo/fr.po")
> got:
> ("/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0/extensions/x86_64-linux/3.1.0/RedCloth-4.3.2/gem.build_complete")
> # ./lib/yard/i18n/po_parser.rb:21:in `'
> # ./lib/yard/i18n/po_parser.rb:8:in `'
> # ./lib/yard/i18n/po_parser.rb:3:in `'
> # ./lib/yard/i18n/po_parser.rb:2:in `'
> # ./lib/yard/i18n/locale.rb:50:in `load'
> # ./spec/i18n/locale_spec.rb:62:in `block (3 levels) in '
> # ./spec/spec_helper.rb:121:in `block (2 levels) in '
> # --
> # --- Caused by: ---
> # LoadError:
> # cannot load such file -- prime
> # ./lib/yard/i18n/po_parser.rb:21:in `'
>
> Top 5 slowest examples (1.36 seconds, 29.1% of total time):
> YARD::RegistryStore#save never saves as single object db if
> single_object_db is false
> 1.02 seconds ./spec/registry_store_spec.rb:152
> YARD::Registry Thread local maintains two Registries in separate threads
> 0.10087 seconds ./spec/registry_spec.rb:396
> YARD::Registry Thread local allows setting of yardoc_file in separate
> threads
> 0.10043 seconds ./spec/registry_spec.rb:417
> YARD::Registry Thread local allows setting of po_dir in separate threads
> 0.10031 seconds ./spec/registry_spec.rb:442
> YARD::Server::Commands::LibraryCommand#call sets :rdoc as the default
> markup in regular mode
> 0.04345 seconds ./spec/server/commands/library_command_spec.rb:34
>
> Top 5 slowest example groups:
> YARD::Server::Commands::LibraryCommand
> 0.04285 seconds average (0.12856 seconds / 3 examples)
> ./spec/server/commands/library_command_spec.rb:4
> YARD::RegistryStore
> 0.03318 seconds average (1.09 seconds / 33 examples)
> ./spec/registry_store_spec.rb:3
> YARD::Parser::C::CParser
> 0.02566 seconds average (0.46193 seconds / 18 examples)
> ./spec/parser/c_parser_spec.rb:3
>
> YARD::Templates::Engine::Template__build_yard_Y2Z3fT_yard_0_9_27_templates_default_module
> 0.02072 seconds average (0.14503 seconds / 7 examples)
> ./spec/templates/module_spec.rb:4
> YARD::CLI::Display
> 0.01929 seconds average (0.05787 seconds / 3 examples)
> ./spec/cli/display_spec.rb:3
>
> Finished in 4.68 seconds (files took 0.61565 seconds to load)
> 1938 examples, 1 failure, 9 pending
>
> Failed examples:
>
> rspec ./spec/i18n/locale_spec.rb:43 # YARD::I18n::Locale#load returns true
> for existent PO
>
> /usr/bin/ruby3.1
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
> /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec
> --pattern ./spec/\*\*/\*_spec.rb --format documentation failed
> ERROR: Test "ruby3.1" failed:
The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/17/yard/yard_0.9.27-1+rebuild1663008419_amd64-2022-09-12T18:47:00Z.build
To reproduce this, you need to install ruby-all-dev >= 1:3.0+2. Depending on
when you try this, it might mean installing ruby-all-dev from experimental, or
if the transition has already started, a normal build on unstable will be
enough. If you fail to reproduce, please provide a build log and diff it with
mine so that we can identify if something relevant changed in the meantime.
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects
signature.asc
Description: PGP signature
Bug#1019683: test-kitchen: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: "#".
Source: test-kitchen
Version: 1.23.2-6
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1
Hi,
We are about to start the ruby3.1 transition in unstable. While trying to
rebuild test-kitchen with ruby3.1 enabled, the build failed.
Relevant part of the build log (hopefully):
> "#".
>
> 58) Failure:
> Kitchen::Loader::YAML::#diagnose::for yaml files::for combined on
> error#test_0003_uses an error hash with the exception message
> [/<>/spec/kitchen/loader/yaml_spec.rb:761]:
> Expected /Error parsing/ to match # encoding: ASCII-8BIT
> #valid: true
> "wrong number of arguments (given 4, expected 1)".
>
> 59) Failure:
> Kitchen::Loader::YAML::#diagnose::for yaml files#test_0004_project config
> contains raw data [/<>/spec/kitchen/loader/yaml_spec.rb:621]:
> No visible difference in the Hash#inspect output.
> You should look at the implementation of #== on Hash or its members.
> {"from_project"=>"project", "common"=>{"p"=>"pretty"}}
>
> 60) Failure:
> Kitchen::Loader::YAML::#diagnose::for yaml files#test_0006_local config
> contains raw data [/<>/spec/kitchen/loader/yaml_spec.rb:633]:
> No visible difference in the Hash#inspect output.
> You should look at the implementation of #== on Hash or its members.
> {"from_local"=>"local", "common"=>{"l"=>"looky"}}
>
> 61) Failure:
> Kitchen::Loader::YAML::#diagnose::for yaml files#test_0008_combined config
> contains raw data [/<>/spec/kitchen/loader/yaml_spec.rb:645]:
> No visible difference in the Hash#inspect output.
> You should look at the implementation of #== on Hash or its members.
> {"from_global"=>"global", "from_project"=>"project", "from_local"=>"local",
> "common"=>{"g"=>"goody", "p"=>"pretty", "l"=>"looky"}}
>
> 62) Failure:
> Kitchen::Loader::YAML::#diagnose::for yaml files#test_0002_global config
> contains raw data [/<>/spec/kitchen/loader/yaml_spec.rb:609]:
> No visible difference in the Hash#inspect output.
> You should look at the implementation of #== on Hash or its members.
> {"from_global"=>"global", "common"=>{"g"=>"goody"}}
>
> 2210 runs, 3375 assertions, 18 failures, 44 errors, 0 skips
> rake aborted!
> Command failed with status (1): [ruby -w
> /usr/lib/ruby/gems/3.1.0/gems/rake-13.0.6/lib/rake/rake_test_loader.rb
> "spec/kitchen/base64_stream_spec.rb" "spec/kitchen/cli_spec.rb"
> "spec/kitchen/collection_spec.rb" "spec/kitchen/color_spec.rb"
> "spec/kitchen/config_spec.rb" "spec/kitchen/configurable_spec.rb"
> "spec/kitchen/data_munger_spec.rb" "spec/kitchen/diagnostic_spec.rb"
> "spec/kitchen/driver/base_spec.rb" "spec/kitchen/driver/dummy_spec.rb"
> "spec/kitchen/driver/exec_spec.rb" "spec/kitchen/driver/proxy_spec.rb"
> "spec/kitchen/driver/ssh_base_spec.rb" "spec/kitchen/driver_spec.rb"
> "spec/kitchen/errors_spec.rb" "spec/kitchen/instance_spec.rb"
> "spec/kitchen/lazy_hash_spec.rb" "spec/kitchen/lifecycle_hooks_spec.rb"
> "spec/kitchen/loader/yaml_spec.rb" "spec/kitchen/logger_spec.rb"
> "spec/kitchen/logging_spec.rb" "spec/kitchen/login_command_spec.rb"
> "spec/kitchen/metadata_chopper_spec.rb" "spec/kitchen/platform_spec.rb"
> "spec/kitchen/provisioner/base_spec.rb"
> "spec/kitchen/provisioner/chef/policyfile_spec.rb"
> "spec/kitchen/provisioner/chef_apply_spec.rb"
> "spec/kitchen/provisioner/chef_base_spec.rb"
> "spec/kitchen/provisioner/chef_solo_spec.rb"
> "spec/kitchen/provisioner/chef_zero_spec.rb"
> "spec/kitchen/provisioner/dummy_spec.rb"
> "spec/kitchen/provisioner/shell_spec.rb" "spec/kitchen/provisioner_spec.rb"
> "spec/kitchen/shell_out_spec.rb" "spec/kitchen/ssh_spec.rb"
> "spec/kitchen/state_file_spec.rb" "spec/kitchen/suite_spec.rb"
> "spec/kitchen/transport/base_spec.rb" "spec/kitchen/transport/exec_spec.rb"
> "spec/kitchen/transport/ssh_spec.rb" "spec/kitchen/transport/winrm_spec.rb"
> "spec/kitchen/transport_spec.rb" "spec/kitchen/util_spec.rb"
> "spec/kitchen/verifier/base_spec.rb" "spec/kitchen/verifier/busser_spec.rb"
> "spec/kitchen/verifier/dummy_spec.rb" "spec/kitchen/verifier/shell_spec.rb"
> "spec/kitchen/verifier_spec.rb" "spec/kitchen_spec.rb"
> "spec/support/powershell_max_size_spec.rb" ]
>
> Tasks: TOP => default => unit
> (See full trace by running task with --trace)
> ERROR: Test "ruby3.1" failed:
The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/17/test-kitchen/test-kitchen_1.23.2-6+rebuild1663008366_amd64-2022-09-12T18:46:08Z.build
To reproduce this, you need to install ruby-all-dev >= 1:3.0+2. Depending on
when you try this, it might mean installing ruby-all-dev from experimental, or
if the transition has already started, a normal build on unstable will be
enough. If you fail to reproduce, please provide a build log and diff it with
mine so that we can identify if something relevant changed in the meantime.
A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to
Bug#1019681: samizdat: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed.
Source: samizdat
Version: 0.7.1-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1
Hi,
We are about to start the ruby3.1 transition in unstable. While trying to
rebuild samizdat with ruby3.1 enabled, the build failed.
Relevant part of the build log (hopefully):
> /usr/bin/ruby3.1 /usr/bin/gem2deb-test-runner
>
> ┌──┐
> │ Run tests for ruby3.1 from debian/ruby-test-files.yaml
> │
> └──┘
>
> RUBYLIB=/<>/debian/samizdat/usr/lib/ruby/vendor_ruby:.
> GEM_PATH=/<>/debian/samizdat/usr/share/rubygems-integration/all:/<>/debian/.debhelper/generated/_source/home/.local/share/gem/ruby/3.1.0:/var/lib/gems/3.1.0:/usr/local/lib/ruby/gems/3.1.0:/usr/lib/ruby/gems/3.1.0:/usr/lib/x86_64-linux-gnu/ruby/gems/3.1.0:/usr/share/rubygems-integration/3.1.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/3.1.0
> ruby3.1 -ryaml -e YAML.load_file\(\"debian/ruby-test-files.yaml\"\).each\
> \{\ \|f\|\ require\ f\ \}
> /usr/lib/ruby/vendor_ruby/whitewash.rb:125: warning: Object#untaint is
> deprecated and will be removed in Ruby 3.2
> /<>/debian/samizdat/usr/lib/ruby/vendor_ruby/samizdat/engine/globals.rb:21:
> warning: Object#untaint is deprecated and will be removed in Ruby 3.2
> Loaded suite -e
> Started
> E
> ===
> Error: test_box_with_title(TC_ApplicationHelper): Psych::DisallowedClass:
> Tried to load unspecified class: Regexp
> /usr/lib/ruby/3.1.0/psych/class_loader.rb:99:in `find'
> /usr/lib/ruby/3.1.0/psych/class_loader.rb:28:in `load'
> (eval):2:in `regexp'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:97:in `deserialize'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:128:in
> `visit_Psych_Nodes_Scalar'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:338:in `block in register_empty'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:338:in `each'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:338:in `register_empty'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:146:in
> `visit_Psych_Nodes_Sequence'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in
> `visit_Psych_Nodes_Mapping'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in
> `visit_Psych_Nodes_Mapping'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in
> `visit_Psych_Nodes_Mapping'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:345:in `block in revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `each_slice'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:343:in `revive_hash'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:167:in
> `visit_Psych_Nodes_Mapping'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in `visit'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:6:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:35:in `accept'
> /usr/lib/ruby/3.1.0/psych/visitors/to_ruby.rb:318:in
> `visit_Psych_Nodes_Document'
> /usr/lib/ruby/3.1.0/psych/visitors/visitor.rb:30:in
Bug#1019682: schleuder: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: Failure/Error: expect(error).to be_empty
Source: schleuder Version: 4.0.3-4 Severity: important Justification: FTBFS Tags: bookworm sid ftbfs User: debian-r...@lists.debian.org Usertags: ruby3.1 Hi, We are about to start the ruby3.1 transition in unstable. While trying to rebuild schleuder with ruby3.1 enabled, the build failed. Relevant part of the build log (hopefully): > Failure/Error: expect(error).to be_empty > expected > `":85:in > `require': cannot loa...or_ruby/rubygems/core_ext/kernel_require.rb>:85:in > `require'\n\tfrom bin/schleuder:12:in `'\n".empty?` to be truthy, got > false > # ./spec/schleuder/integration/filters_spec.rb:104:in `block (3 levels) > in ' > # ./spec/spec_helper.rb:64:in `block (3 levels) in ' > # ./spec/spec_helper.rb:63:in `block (2 levels) in ' > > Finished in 3 minutes 8.5 seconds (files took 0.86967 seconds to load) > 543 examples, 21 failures > > Failed examples: > > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:10]' > # user sends emails with different charsets works with simple_latin1 > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:1]' > # user sends emails with different charsets works with japanese > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:5]' > # user sends emails with different charsets works with japanese_shift_jis > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:3]' > # user sends emails with different charsets works with > japanese_attachment_long_name > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:11]' > # user sends emails with different charsets works with simple_utf8 > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:6]' > # user sends emails with different charsets works with ks_c_5601-1987 > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:12]' > # user sends emails with different charsets works with > thunderbird-multi-alt-html > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:9]' > # user sends emails with different charsets works with simple_jpiso2022 > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:2]' > # user sends emails with different charsets works with japanese_attachment > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:4]' > # user sends emails with different charsets works with japanese_iso_2022 > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:8]' > # user sends emails with different charsets works with simple_jis > rspec './spec/schleuder/integration/receive_different_charsets_spec.rb[1:7]' > # user sends emails with different charsets works with signed_utf8 > rspec './spec/schleuder/integration/send_encrypted_spec.rb[1:4]' # user sends > an encrypted message from thunderbird being encrypted+signed-mime > rspec './spec/schleuder/integration/send_encrypted_spec.rb[1:2]' # user sends > an encrypted message from thunderbird being encrypted-mime > rspec './spec/schleuder/integration/send_encrypted_spec.rb[1:1]' # user sends > an encrypted message from thunderbird being encrypted-inline > rspec './spec/schleuder/integration/send_encrypted_spec.rb[1:3]' # user sends > an encrypted message from thunderbird being encrypted+signed-inline > rspec ./spec/schleuder/integration/receive_bounce_spec.rb:4 # a bounce > message is received from bounce example > rspec ./spec/schleuder/integration/filters_spec.rb:55 # running filters > .fix_exchange_messages! accepts a valid plain-text message > rspec ./spec/schleuder/integration/filters_spec.rb:32 # running filters > .fix_exchange_messages! accepts an invalid pgp/mime Exchange message > rspec ./spec/schleuder/integration/filters_spec.rb:118 # running filters > .strip_html_from_alternative! does NOT strip HTML-part from > multipart/alternative-message that does NOT contain ascii-armored PGP-data > rspec ./spec/schleuder/integration/filters_spec.rb:81 # running filters > .strip_html_from_alternative! strips HTML-part from > multipart/alternative-message that contains ascii-armored PGP-data > > Randomized with seed 41721 > > /usr/bin/ruby3.1 > -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib > /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec > --format documentation failed > ERROR: Test "ruby3.1" failed: The full build log is available from: https://people.debian.org/~terceiro/ruby3.1/17/schleuder/schleuder_4.0.3-4+rebuild1663008348_amd64-2022-09-12T18:45:49Z.build To reproduce this, you need to install ruby-all-dev >= 1:3.0+2. Depending on when you try this, it might mean installing ruby-all-dev from experimental, or if the transition has already started, a normal build on unstable will be enough. If you fail to reproduce, please provide a build log and diff it with mine so that we can
Bug#1019661: Breaks monin and maybe other packages
Hi Mark, Am Di den 13. Sep 2022 um 12:43 schrieb Mark Hindley: > On Tue, Sep 13, 2022 at 12:16:33PM +0100, Klaus Ethgen wrote: > > Package: lsb-base > > Version: 11.3 > > Severity: critical > > > > The new package breaks monin as it does not provide > > /lib/lsb/init-functions anymore. > > This file has been moved to sysvinit-utils. Which version of that do you have > installed? 3.03-1devuan1 And there is no dependency for a versioned package in lsb-base as is must be in such a case. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C signature.asc Description: PGP signature
