Source: node-react-hot-loader
Version: 4.13.1+~cs12.12.4-1
Severity: serious
On 2023-05-12 05:48, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package node-global, version 4.4.0~4.13.1+~cs=
> 12.12.4-1, for all,
> however unstable already has version 4.13.1+~
Hi,
On 2023-02-09 09:41, Amin Bandali wrote:
> Hello,
>
> Aurelien Jarno writes:
>
> > Source: ring
> > Version: 20230206.0~ds1-2
> > Severity: serious
> >
> > On 2023-02-08 08:40, Debian FTP Masters wrote:
> >> jami_20230206.0~ds1-2_amd64.deb:
Source: ring
Version: 20230206.0~ds1-2
Severity: serious
On 2023-02-08 08:40, Debian FTP Masters wrote:
> jami_20230206.0~ds1-2_amd64.deb: has 5 file(s) with a timestamp too far in th=
> e past:
> usr/share/applications/jami.desktop (Thu Jan 1 00:00:01 1970) usr/share/i=
> cons/hicolor/scalabl
Hi Axel,
On 2023-01-05 03:25, Axel Beckert wrote:
> Hi Aurelien,
>
> Axel Beckert wrote:
> > Aurelien Jarno wrote:
> > > An alternative is to not try to support all systems and reinvent the
> > > wheel, and instead assume a POSIX system.
> >
> > I&
control: reassign -1 screen
control: retitle -1 GNU Screen does not support Unicode 14
control: affects -1 libc6
Hi,
On 2023-01-03 02:28, Vincent Lefevre wrote:
> On 2023-01-02 23:08:39 +0100, Aurelien Jarno wrote:
> > This U+1FAF6 character is new in Unicode 14, which is supported
ter.
Now I am not sure it is a bug in glibc, it rather seems an issue with
screen. I can reproduce the shifts in both, stable and unstable, by
putting this char in a file and just running cat on the file.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Source: openjfx
Version: 11.0.11+0-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
openjfx tries to build with -j64 on zani.debian.org, which only has 2
processors and 8GB of RAM:
buildd 3853047 0.0 0.0 67668 4 ?S
Package: xournal
Version: 1:0.4.8.2016-7+b1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Dear maintainer(s),
Your package fails to build with:
|dh_auto_build
| make -j8
| make[1]: Entering directory '/build/1st/xournal-0.4
Source: rust-xmlparser
Version: 0.11.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
Your package fails to build with:
| running 6 tests
| test src/lib.rs - map_err_at (line 396) - compile ... FAILED
| test src/stream.rs - stre
Source: runawk
Version: 1.6.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
Your package fails to build with:
| dh build-arch --buildsystem=mkcmake
| dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
|
Source: glosstex
Version: 0.4.dfsg.1-4
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
Your package fails to build with:
|Writing index file glosstex.idx
|(/usr/share/texlive/texmf-dist/tex/latex/hypdoc/hypdoc.sty
|(/usr/share/texl
Source: rust-lalrpop
Version: 0.19.8-3
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky
Dear maintainer(s),
I looked at the results of the autopkgtest of rust-lalrpop as it was
blocking glibc. I noticed that it sometimes fails on s390x with the
following error:
thread 'lr1::bui
Source: pacman-package-manager
Version: 6.0.2-2
Severity: serious
On 2022-11-20 00:06, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package libalpm-dev, version 13.0.2-1, for
> mips64el,
> however testing already has version 13.0.2-1.
> Uploads to unstable m
On 2022-11-10 08:37, Paul Gevers wrote:
> Hi,
>
> On 09-11-2022 23:02, Aurelien Jarno wrote:
> > Unfortunately I am not sure we want to do that, as we don't know if this
> > GCC version incompatibility (that seems specific to s390x, at least in
> > the utox contex
Hi,
On 2022-11-09 22:24, Paul Gevers wrote:
> Control: affects -1 utox
>
> Hi Aurelien, Christian,
>
> On 09-11-2022 21:25, Aurelien Jarno wrote:
> > It happens that emalloc is provided by libcheck_pic.a (from the check
> > package) and that ASAN trips when li
control: reassign -1 check
On 2022-11-06 17:21, Aurelien Jarno wrote:
> On 2022-11-06 08:12, Paul Gevers wrote:
> > Source: utox
> > Version: 0.18.1-1
> > Severity: serious
> > User: debian...@lists.debian.org
> > Usertags: regression
> >
> > Dea
t_chrono.c:71:E:chrono_callback:test_chrono_callback:0:
(after this point) Early exit with return value 1
Test time = 0.06 sec
--
Test Failed.
"test_chrono" end time: Nov 06 10:53 UTC
"test_chrono" time elapsed: 00:00:00
--
Control: tag -1 pending
Hello,
Bug #1022991 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/ce84023382625e960fa6e975d24893d51
Source: ksh93u+m
Version: 1.0.4-1
Severity: serious
On 2022-10-29 12:35, Debian FTP Masters wrote:
>
>
> Version check failed:
> Your upload included the binary package ksh, version 20220829, for all,
> however testing already has version 20220829.
> Uploads to unstable must have a higher versio
control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=29730
On 2022-10-28 20:35, Aurelien Jarno wrote:
> Package: libc6
> Version: 2.35-1
> Severity: critical
> Tags: upstream
> Justification: breaks unrelated software
>
> On mips64el the fstat/fstatat/l
Package: libc6
Version: 2.35-1
Severity: critical
Tags: upstream
Justification: breaks unrelated software
On mips64el the fstat/fstatat/lstat functions return EOVERFLOW when they
are called on files with a mtime, atime or ctime that can't be
represented within a 32-bit time_t. This should not happ
>LC_ALL/LANG/LC_CTYPE can cause the shell to crash. Closes: #1021062.
This is the wrong bug number, the problem might be fixed in bash, but is
still present in libreadline8. Reopening.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Hi Paul,
A small update on this bug. Now that glibc 2.35-3 migrated to testing,
the only unsolved issue is that one:
On 2022-10-07 21:14, Paul Gevers wrote:
> On 07-10-2022 20:55, Aurelien Jarno wrote:
> > > https://ci.debian.net/data/autopkgtest/testing/armel/g/glibc/235
control: forwarded -1 https://github.com/endrazine/wcc/pull/39
control: tag -1 + patch
On 2022-07-12 12:46, Michael Hudson-Doyle wrote:
> On Tue, 12 Jul 2022 at 04:30, Aurelien Jarno wrote:
>
> > On 2022-07-11 10:06, Michael Hudson-Doyle wrote:
> > > It looks like a no-chan
e/testdata/XT5.tmp
> /bin/bash: line 1:
> /tmp/autopkgtest-lxc.pjd0aipn/downtmp/build.Ui1/src/build-tree/armel-libc/timezone/testdata/XT5.tmp:
> No such file or directory
This has been fixed in glibc 2.35 that is now in testing:
https://sourceware.org/git/?p=glibc.git;a=commit;h=62db87ab24f9ca483f97f5e52ea92445f6a63c6f
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
Source: golang-github-anacrolix-missinggo
Version: 2.1.0-6
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 on armhf while testing if other packages can
migrate. A r
Hi,
On 2022-10-04 08:51, Aurelien Jarno wrote:
> Hi
>
> On 2022-09-25 13:43, Aurelien Jarno wrote:
> > > Running a quick diff against old procinfo reveals that "flags" has the
> > > following new entries now:
> > >
> > > tsc_deadline_
ne through a
BIOS/firmware update if available.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Hi
On 2022-09-25 13:43, Aurelien Jarno wrote:
> > Running a quick diff against old procinfo reveals that "flags" has the
> > following new entries now:
> >
> > tsc_deadline_timer ssbd ibrs ibpb stibp bmi1 bmi2 md_clear flush_l1d
> >
> > > it lo
control: clone 1021062 -1
control: reassign -1 bash
control: found -1 bash/5.2-1
Hi,
On 2022-10-02 07:27, Kan-Ru Chen wrote:
> reassign 1021062 libreadline8
> found 1021062 libreadline8/8.2-1
> thanks
>
> On Sun, Oct 2, 2022, at 1:56 AM, Aurelien Jarno wrote:
> > cont
; Downgrade to 2.34-8 seems also don't fix the issue, probably some locale
> state was invalidated when upgrading.
This is because you upgraded other packages than glibc (here bash), and the bug
is not in glibc. Downgrading bash fixes the issue. Reassigning the bug.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
BMI2
> > instructions support has been added in a microcode update
>
> As such it does appear that indeed this is the case.
Thanks for the confirmation, it seems that the microcode update is also
useful for security reasons in order to mitigate the speculative
execution side channel issues
ckage.
Now that we understood the bug, I actually find strange that the
microcode update is fixing this, it looks like that the BMI2
instructions support has been added in a microcode update. Would it be
possible to give the output of /proc/cpuinfo with and without the
microcode updat
Control: tag -1 pending
Hello,
Bug #926699 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/cf50a0b40745966ab86ece3afe7c6baa56
Hi,
Have you been able to progress on that? Do you need some help for a
specific step?
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Control: tag -1 pending
Hello,
Bug #926699 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/cf50a0b40745966ab86ece3afe7c6baa56
ess of the illegal instruction would help a
lot to understand the issue.
> This machine, in case it matters, is a Lenovo G510 laptop. There is some
> update available for the BIOS, but it requires booting up Windows to perform
> it. Should I attempt that? I found some ancient thread on some forum that
> mentioned BIOS update fixes some issues with "freezes" on
As said above, I find strange that the problem has not been noticed yet
given it affects at least two distributions, and that it dates from a
few months in sid. You might want to install the intel-microcode package
and reboot to see if it helps, it should have the same effects than
updating the BIOS for the point of view of the current bug.
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
e corresponding flags from the kernel point of view, but
the cpuid instruction will just continue to behave the same. The way to
do disable that features at the glibc level is to set the GLIBC_TUNABLES
environment variable to "glibc.cpu.hwcaps=-AVX2_Usable".
Regards
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Control: tag -1 pending
Hello,
Bug #1018071 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/3be5901cc714b11df775d92a4997d573e
Package: libpmix2
Version: 4.2.0~rc1-2
Severity: grave
Justification: renders package unusable
Starting with version 4.2.0~rc1-1, the mca_pmix_ext3x.so library lost
the pmix_value_load symbols. This causes issues on depending packages:
https://buildd.debian.org/status/fetch.php?pkg=dolfin&arch=a
Package: libpmix2
Version: 4.2.0~rc1-1
Severity: critical
Justification: breaks unrelated software
Hi,
The upload of pmix version 4.2.0~rc1-1 introduced a dangling symlink,
/usr/lib/x86_64-linux-gnu/libpmix.so.2 points to
pmix2/lib/libpmix.so.2.5.2 which doesn't exist anymore as it has been
renam
control: tag -1 + pending
On 2022-08-09 15:12, Aurelien Jarno wrote:
> control: tag -1 + patch
>
> Hi,
>
> On 2022-08-08 01:34, Sebastian Ramacher wrote:
> > Source: libspf2
> > Version: 1.2.10-7.1
> > Severity: serious
> > Tags: ftbfs sid bookworm
> &
control: tag -1 + pending
On 2022-08-09 13:21, Aurelien Jarno wrote:
> Source: dolfin
> Version: 2019.2.0~git20220407.d29e24d-5
> Severity: serious
>
> Dear maintainer,
>
> glibc 2.34 has merged a few libraries (libpthread, libdl, libutil,
> libanl) into lib
control: tag -1 +pending
On 2022-08-09 09:31, Aurelien Jarno wrote:
> control: severity 1016560 serious
>
> On 2022-08-03 00:01, Aurelien Jarno wrote:
> > Source: scalpel
> > Version: 1.60-9
> > Severity: important
> > Tags: upstream patch
> > User: deb
raries that contain (working) copies.".
In that case it takes care to rename dn_expand into __dn_expand and
dn_skipname into __dn_skipname. It appears that with the changes done in
glibc 2.34, libspf2 does not need to use libreplace anymore. Therefore
the following patch from Ubunt
On 2022-08-09 13:21, Aurelien Jarno wrote:
> Source: dolfin
> Version: 2019.2.0~git20220407.d29e24d-5
> Severity: serious
FYI, I filled this bug with severity serious as it currently makes this
package uninstallable in sid, given breaks have been added to libc6-dev
against the affected v
Source: dolfin
Version: 2019.2.0~git20220407.d29e24d-5
Severity: serious
Dear maintainer,
glibc 2.34 has merged a few libraries (libpthread, libdl, libutil,
libanl) into libc. While this is handled transparently at runtime, there
are a few corner cases at build time. In the case of dolfin, the fi
Control: tag -1 pending
Hello,
Bug #1016868 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/5a55ada45e43a6591dc0e8def944fadf6
tep will be running a full-sid setup for a test network, but I don't
> see any reason why the working NIS maps could be broken, my guess is that
> the problem is connected to some inner libnss/libc issue.
This was actually a bug in libc6, which affected the compat module,
while
Control: tag -1 pending
Hello,
Bug #1014735 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/009d0a10e3e0c818e6b722addcef073dc
Source: ksh93u+m
Version: 1.0.1-1
Severity: serious
On 2022-08-07 16:04, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package ksh, version 20211217, for all,
> however unstable already has version 20211217.
> Uploads to unstable must have a higher version tha
Source: rust-cbindgen
Version: 0.23.0-1~deb10u1
Severity: serious
X-Debbugs-Cc: po...@debian.org
On 2022-07-16 15:34, Debian FTP Masters wrote:
>
>
> cbindgen_0.23.0-1~deb10u1_s390x.deb: has 1 file(s) with a timestamp too far
> in the past:
> usr/share/doc/cbindgen/changelog.gz (Thu Nov 29 21
Hi,
On 2022-07-11 22:18, Magnus Danielson wrote:
> Hi,
>
> On 7/11/22 18:30, Aurelien Jarno wrote:
> > control: tag -1 + moreinfo
> >
> > Hi,
> >
> > On 2022-07-11 02:46, Magnus Danielson wrote:
> > > Package: rpcsvc-proto
> > > V
ication that generates
> through rpcgen and then compiles it successfully. Then this error would be
> caught. Another approach would be to check that the same header files gets
> installed from previous packaging and new packaging. Both methods would be
> recommended to create fail-safes and qui
Control: tag -1 pending
Hello,
Bug #1014109 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/e8182ba6eb72b72dda6fefd0f3649233e
Source: haskell-bimap_
Version: 0.4.0-2
Severity: serious
On 2022-06-29 21:25, Debian FTP Masters wrote:
> libghc-bimap-dev_0.4.0-2_mips64el.deb: has 1 file(s) with a timestamp too far
> in the past:
> usr/share/doc/libghc-bimap-dev/changelog.gz (Thu Jan 1 00:00:00 1970)
>
>
>
> ===
>
> Pl
Source: haskell-wl-pprint-text
Version: 1.2.0.1-1
Severity: serious
On 2022-06-22 16:08, Debian FTP Masters wrote:
> libghc-wl-pprint-text-dev_1.2.0.1-1+b2_mips64el.deb: has 1 file(s) with a
> timestamp too far in the past:
> usr/share/doc/libghc-wl-pprint-text-dev/changelog.gz (Thu Jan 1 00:0
Source: haskell-hslua-module-text
Severity: serious
Version: 0.2.1-2.1
On 2022-05-30 15:34, Debian FTP Masters wrote:
> libghc-hslua-module-text-dev_0.2.1-2.1_mips64el.deb: has 1 file(s) with a
> timestamp too far in the past:
> usr/share/doc/libghc-hslua-module-text-dev/changelog.gz (Thu Jan
Source: haskell-hslua-module-system
Severity: serious
Version: 0.2.1-2.1
On 2022-05-28 15:18, Debian FTP Masters wrote:
> libghc-hslua-module-system-dev_0.2.1-2.1_mips64el.deb: has 1 file(s) with a
> timestamp too far in the past:
> usr/share/doc/libghc-hslua-module-system-dev/changelog.gz (Thu
e the rv-osuosl-02[0] machines has different with the real
> hardware?
>
> Yes, maybe. CC-ing riscv64 porters about that.
rv-rr44-01 and rv-mullvad-0x are Unleashed boards
rv-osuosl-0x are Unmatched boards
Other are QEMU VMs.
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
Source: android-platform-tools
Version: 29.0.6-8
Severity: serious
On 2022-04-18 14:49, Debian FTP Masters wrote:
>
>
> Version check failed:
> Your upload included the binary package android-sdk-libsparse-utils, version
> 29.0.6-8, for s390x,
> however testing already has version 1:10.0.0+r36-
Source: libnfsidmap
Version: 0.25-6
Severity: serious
On 2022-03-13 15:58, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package libnfsidmap-dev, version 0.25-6+b1,
> for mips64el,
> however testing already has version 1:2.6.1-1.
> Uploads to unstable must ha
Source: mutter
Version: 41.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
mutter fails to build from source:
| Got pkgconfig variable girdir : /usr/share/gir-1.0
| Program msgfmt found: YES (/usr/bin/msgfmt)
| Configuring org.gnome.
On 2022-02-01 16:02, Tulio Magno Quites Machado Filho wrote:
> Aurelien Jarno writes:
>
> > On 2022-01-19 22:08, John Paul Adrian Glaubitz wrote:
> >> Hi Aurelien!
> >>
> >> Unfortunately, glibc no longer builds with this change on powerpc and ppc64
>
Source: nanoc
Version: 4.12.5-2
Severity: serious
On 2022-01-29 16:19, Debian FTP Masters wrote:
>
>
> Version check failed:
> Your upload included the binary package ruby-nanoc-deploying, version
> 1.0.1-2, for all,
> however testing already has version 1.0.1-2.
> Uploads to unstable must have
On 2022-01-25 19:04, Vagrant Cascadian wrote:
> On 2022-01-25, Vagrant Cascadian wrote:
> > On 2022-01-15, Aurelien Jarno wrote:
> >> On 2022-01-11 16:40, Vagrant Cascadian wrote:
> >>> On 2022-01-11, Lennart Sorensen wrote:
> >>> > On Mon, Jan 10, 2022
42579068&raw=0
> > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=ppc64&ver=5.15.15-1&stamp=1642578946&raw=0
Those failures are completely unrelated to do with glibc. A porter need
to fix the kernel code to make it compatible with the new binutils.
Cheers
Aurelie
Control: tag -1 pending
Hello,
Bug #1003610 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/41086a4c85e828a019b1ab3adbf20f0d6
Control: tag -1 pending
Hello,
Bug #1003574 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/41086a4c85e828a019b1ab3adbf20f0d6
Control: tag -1 pending
Hello,
Bug #1003610 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/41086a4c85e828a019b1ab3adbf20f0d6
Control: tag -1 pending
Hello,
Bug #1003574 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/41086a4c85e828a019b1ab3adbf20f0d6
nd glibc source packages. Can you please
> investigate the situation and reassign the bug to the right package?
Recent versions of binutils changed the way the .machine directive works
on PowerPC. I have already backported a fix to our git.
--
Aurelien Jarno GPG: 4096R/
Source: tmpreaper
Version: 1.6.15
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
tmpreaper fails to build from source:
| checking for sys/wait.h that is POSIX.1 compatible... yes
| checking for errno.h... yes
| checking for limits.h...
binutils also dropped support or have kept it around.
>
> The binutils versions appear to be:
>
> succeeding, bookworm 2.37-10.1
> failing, sid 2.37.50.20220106-2
>
Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on
the binutils side [1], which changes the b
Source: userv
Version: 1.2.1~beta2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
userv fails to build from source:
| dh_auto_configure
| ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir
Source: openttd
Version: 12.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
openttd fails to build from source:
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
|dh_cmake_install -a -O--buildsystem=cmake
| -- Install confi
Control: tag -1 pending
Hello,
Bug #1001967 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/b3dd10b17644ce30af0e95f1b202ca209
On 2021-12-19 19:27, Aurelien Jarno wrote:
> control: tag -1 - upstream
>
> On 2021-12-19 18:49, d deb wrote:
> > When performing "apt upgrade" or "apt upgrade -t experimental", this
> > dependecies error occorurs: libc6 : Rompe: libc6:i386 (!=
> &g
: Rompe: libc6 (!= 2.33-1) ma la versione 2.34-0experimental1 è
> installata
Your system have i386 as a foreign architecture. It requires that both
amd64 and i386 versions are in sync. How did you initially install
libc6:amd64 version 2.34-0experimental1?
Regards,
Aurelien
--
Aurelien Jarno
Source: aribas
Version: 1.64-6
Severity: serious
Tags: patch upstream
Dear maintainer,
The aribas autopkgtests fails when run on an i386 system with glibc 2.33
installed. Here is the relevant part of the tests:
| Preparing to unpack .../aribas_1.64-6_i386.deb ...
| Unpacking aribas (1.64-6) ...
Control: tag -1 pending
Hello,
Bug #903514 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/c569ea274923387e8448be3021649c7bdf
On 2021-12-09 18:03, Ondřej Surý wrote:
> MIssed the issue, RM now fillled as #1001404
>
Thanks!
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
at src:bind be
> removed from Debian experimental since it is a duplicate.
>
> https://sources.debian.org/src/bind/experimental/debian/watch
> https://sources.debian.org/src/bind9/unstable/debian/watch
Any news on that? This is annoying as it causes unrelated autopkgtest
failures.
Control: tag -1 pending
Hello,
Bug #998008 in glibc reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/glibc-team/glibc/-/commit/f0b32b609c442083a8af7099ca58fbd74b
On 2021-12-04 16:15, Anuradha Weeraman wrote:
> Hi Aruelien
>
> On Sat, Dec 04, 2021 at 10:39:58AM +0100, Aurelien Jarno wrote:
> > Source: ksh93u+m
> > Version: 1.0.0~beta.1-2
> > Severity: serious
> >
> > On 2021-12-03 18:48, Debian FTP Masters wrote:
Source: ksh93u+m
Version: 1.0.0~beta.1-2
Severity: serious
On 2021-12-03 18:48, Debian FTP Masters wrote:
>
>
> Version check failed:
> Your upload included the binary package ksh, version 20210511, for all,
> however unstable already has version 20210511.
> Uploads to unstable must have a highe
Source: python-python-docx
Version: 0.8.11+dfsg1-2
Severity: serious
On 2021-11-19 17:49, Debian FTP Masters wrote:
>
> python3-python-docx_0.8.11+dfsg1-2_all.deb: Does not match binary in database.
>
>
> Mapping sid to unstable.
>
> ===
>
> Please feel free to respond to this email if you do
Source: python3.10
Version: 3.10.0-5
Severity: serious
python3.10 testsuite regularly gets stuck in a loop on buildds with the
following kind of output:
| 186:53:00 load avg: 0.28 running: test_multiprocessing_fork (186 hour 45 min)
Full builds logs are available there:
https://buildd.debian.org
control: severity -1 important
On 2021-11-17 10:52, Andrius Merkys wrote:
> Hi Aurelien,
>
> Thanks for the report.
>
> On 2021-11-17 09:09, Aurelien Jarno wrote:
> > Source: liboqs
> > Version: 0.7.0.15.g9be13d21+dfsg-1
> > Severity: serious
> > Tags:
Source: liboqs
Version: 0.7.0.15.g9be13d21+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
liboqs fails to build from source:
| /usr/bin/cc -I/<>/obj-aarch64-linux-gnu/include
-I/<>/src/kem/ntru/pqclean_ntruhrss701_clean
-I/<>/
Source: netopeer2
Version: 1.1.39-1+b1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
netopeer2 fails to build from source:
| | ^~
| [ 55%] Building C object
cli/CMakeFiles/netopeer2-cli.dir/linenoise/linenoi
Source: fftw
Version: 2.1.5-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
fftw fails to build from source:
|debian/rules override_dh_install-arch
| make[1]: Entering directory '/<>'
| mkdir -p /<>/debian/tmp-single/usr/share/doc/
Source: rdkit
Version: 202103.5-1
Severity: serious
Tags: ftbfs
Justification: Policy 4.9
According to Debian Policy 4.9:
| For packages in the main archive, required targets must not attempt
| network access, except, via the loopback interface, to services on the
| build host that have been star
Source: libayatana-indicator
Version: 0.8.4-2
Severity: serious
On 2021-11-10 13:49, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package ayatana-indicator-common, version
> 0.8.4-3, for all,
> however testing already has version 0.9.5-1.
> Uploads to unstab
Source: glibmm2.4
Version: 2.66.2-1
Severity: serious
Tags: upstream ftbfs
Justification: Debian Policy 4.9
According to Debian Policy 4.9:
| For packages in the main archive, required targets must not attempt
| network access, except, via the loopback interface, to services on the
| build host
lly a copy of an old
libcrypt.so.1. It's something you can check with:
readelf --dynamic /lib/x86_64-linux-gnu/libpthread.so.1 | grep SONAME
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
n you confirm it's libpthread.so.1 and not libpthread.so.0? If so can
you please tell how did you install that file?
Thanks,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
> > I tried this out, and it worked: the effect disappeared completely,
> > reinstallation binds the links to proper files. Thank you and sorry for
> > bothering!
>
> --
> ciao,
> Marco
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
old to check if the wrong
link is recreated? That's needed to confirm if ldconfig is the culprit
here.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
; Closes: 992914
> Changes:
> libassa (3.5.1-8) unstable; urgency=medium
> .
>* Fix FTBFS due to RPC removal from glibc.
> Thanks to Aurelien Jarno, for both the bug report and the
> initial cut at a patch (Closes: #992914)
I have just noticed that you used a sligh
201 - 300 of 1769 matches
Mail list logo
