Le 06/12/2020 à 02:14, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 21:19:48)
>> Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-12-03 18:42:17)
Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 17:33:18)
>> Le
Package: obsession
Version: 20140608-2+b1
Severity: normal
Tags: upstream
X-Debbugs-Cc: pitsior...@gmail.com
As it seems, the project is dead. The link to bitbucket leads to a 404. Plus
its developer* has probably moved to github and obsession is not among the
things he currently maintains.
So,
Control: severity -1 important
builds with 2.4.2-0.2, will be fixed in next openssl upload
Package: handbrake-cli
Version: 1.3.1+ds1-2+b3
Severity: important
When I have libdvdnav4 version 6.1.0-1 installed and run HandBrakeCLI, it
segfaults
When I have libdvdnav4 version 6.1.0-1+b1 installed, HandBrakeCLI runs fine.
The problem (or similar one) also occured with version 6.0.0-1 of
I've rebuilt the relevant reverse-build-dependencies from unstable
In addition to the packages mentioned here, it seems there is another
package involved: golang-gopkg-libgit2-git2go.v28 . It only builds
arch-all packages and does not directly depend on the library, but it
FTBFS and it's
Package: pulseeffects
Version: 4.8.0-1
Severity: important
X-Debbugs-Cc: g...@reaperworld.com
Dear Maintainer,
* What led up to the situation?
I installed the package and tried to run it.
* What exactly did you do (or not do) that was effective (or
ineffective)?
I
Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior
* Package name: python-build
Version : 0.1.0
Upstream Author : Filipe Laíns
* URL : https://github.com/pypa/build
* License : Expat
Programming Lang: Python
Description : Simple, correct
Package: sympa
Version: 6.2.58
Severity: wishlist
Tags: patch l10n
Please find the updated German debconf translation for sympa
attached.
Please place this file in debian/po/ as de.po for your next upload.
If you update your template, please use
'msgfmt --statistics '
to check the po-files for
Package: libcifpp
Version: 1.0.0-3
Severity: wishlist
Tags: patch l10n
Please find the initial German debconf translation for libcifpp
attached.
Please place this file in debian/po/ as de.po for your next upload.
If you update your template, please use
'msgfmt --statistics '
to check the
Lucas Nussbaum writes:
> There was a texlive update in the meantime. Here are the versions of
> packages that differ.
I explored this a bit today -- there's something quite amiss with the
docbook toolchain. I'm seeing a lot of this error:
! Undefined control sequence.
Package: python3-xlrd
Version: 1.2.0-1
Tags: patch
xlrd 1.2.0 started using defusedxml if available.
As defusedxml.cElementTree does not have a top-level ElementTree
attribute, Element_has_iter gets set to False
(https://sources.debian.org/src/python-xlrd/1.2.0-1/xlrd/xlsx.py/#L59).
However,
Package: xcb-proto
Severity: serious
Tags: patch upstream
Hello Maintainer,
Python 3.9 deprecated fractions.gcd in favor of math.gcd, this causes a
FTBFS in polybar #975795[0]. I believe this issue can cause FTBFS in other
packages and thus I picked the serious severity (same one applied to the
Hi,
I've done the QA changes to aqemu package for a version aqemu/0.9.2-3 instead
of a NMU.
I've checked that it actually runs fine and that I'm able to create a VM and
run it.
I encountered crashes which I've patches and forwarded all existing and new
patches to upstream.
About the 3 left
Package: godot3-server
Version: 3.2.3-stable-1+b1
Severity: wishlist
X-Debbugs-Cc: b...@transient.nz
Dear Maintainer,
the current godot3-server binary is what upstream refer to as a "headless
build" (built with "platform=server tools=yes target=release_debug"), and there
is no binary for what
Quoting Xavier (2020-12-03 21:19:48)
> Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit :
> > Quoting Xavier (2020-12-03 18:42:17)
> >> Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit :
> >>> Quoting Xavier (2020-12-03 17:33:18)
> Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit :
> >
"Debian Bug Tracking System" writes:
>* Mark build dependency on libfltk1.3-dev. (Closes: #974633)
Thanks! I'm happy to see that you also adjusted libace-flreactor-dev's
runtime dependencies accordingly.
--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
Hi
thanks for the digging through the errors.
> < texlive-base_2020.20200925-1
> ---
> > texlive-base_2020.20201203-2
> Also, I noticed a few new latex-related failures in this archive rebuild.
[...]
It seems that something in the interface with hyperref has changed.
Unfortunately the
Package: wnpp
Severity: wishlist
* Package name: python3-oscrypto
Version : 1.2.1
Upstream Author : Will Bond
* URL : https://github.com/wbond/oscrypto
* License : MIT
Programming Lang: Python
Description : cryptography library for Python
TLS (SSL)
Package: plocate
Version: 1.1.1-1
Tags: patch
Hi,
se...@debian.org (2020-12-05 at 0032.04 +0100):
> The cron script did the wrong thing from 1.1.0:
>
> - It depended on mlocate's database.
> - It would do double-work on top of the systemd timer.
As mlocate is also installed here, it went
On 05/12/2020 20:26, Andreas Tille wrote:
Control: tags -1 help
Hi,
I need to admit that I have no idea why this error occures on arm64.
According to reproducible builds, it's also happening on i386 and armhf,
it's showing a pass for amd64 but that could just be because it hasn't
been tested
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "libutempter":
* Package name: libutempter
Version : 1.2.1-2
Upstream Author : Dmitry V. Levin
* URL :
Control: tags 976476 pending
On 2020-12-05, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on arm64.
This was brought up in:
mes should be Architecture: amd64 armel armhf i386
https://bugs.debian.org/973644
And arm64 was removed from
Hi,
On 05/12/20 at 23:09 +0100, Markus Koschany wrote:
> Control: severity -1 normal
>
> Hello,
>
> The package builds fine on amd64. I don't think it is correct to use severity
> serious in this case because ufoai-maps is an arch:all package. The same is
> true for Java packages. If we want to
On Sat, Dec 05, 2020 at 12:45:42AM +0100, enno wrote:
> No change so gvfs doesn't seem to be responsible BUT 1 new finding: I had
> the meanwile usual procedure, starting enlightenment via my ~/.xsession, the
> aforementioned switching off of the screen/monitor/display (I mean it just
> turns
Package: mutt
Version: 2.0.2-1
Severity: normal
File: /usr/bin/mutt
Hi!
Mutt recently started to crash when the REPLYTO environment variable is
set, it used to work in the past.
#v+
% export REPLYTO='a b '
% mutt < /dev/null
zsh: segmentation fault mutt < /dev/null
{139}% export
Package: linux-image-5.9.0-0.bpo.2-amd64
Version: 5.9.6-1~bpo10+1
Wireless card was not behaving normally after upgrading to kernel 5.9 from the
backports (slow speeds, possibly repeatitive scannings).
I had to blacklist the two following modules (second module possibly optional).
dpkg -S
Package: ts-node
Version: 9.0.0-1
Severity: serious
Justification: Policy 3.5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
ts-node package lacks declaring its runtime dependencies:
node-arg
node-diff
node-make-error
node-source-map-support
node-yn
(yes, I notice that ts-node is only
Le 05/12/2020 à 22:48, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-05 22:34:06)
>> Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit :
>>> Package: node-cosmiconfig,jest
>>> Severity: normal
>>>
>>> Both node-cosmiconfig and jest embed Nodejs module callsites.
>>>
>>> jest provides it as
Control: severity -1 normal
Hello,
The package builds fine on amd64. I don't think it is correct to use severity
serious in this case because ufoai-maps is an arch:all package. The same is
true for Java packages. If we want to make this a release goal (making arch all
packages buildable on all
Control: tags -1 + pending fixed-upstream
On Sat, 05 Dec 2020 at 20:58:26 +0100, Lucas Nussbaum wrote:
> It also fails on amd64
This is caused by API changes in libgit2 (#971563). I'm part way through
packaging a new upstream version that will fix this.
smcv
On 05/12/20 at 17:19 +, peter green wrote:
> severity 976572 normal
> thanks
>
> > During a rebuild of all packages in sid, your package failed to build
> > on arm64 (I don't know if it also fails on amd64).
>
> It's cool that you have expanded your rebuild tests to include arm64, but it
>
A related discussion happened on
https://salsa.debian.org/raspi-team/image-specs/-/issues/37
Thanks to the hint by Axel Beckert, I've managed to consistently reproduce the
issue:
# update-initramfs -u
# aptitude reinstall raspi-firmware
I still don't know whether the issue is in
Le 05/12/2020 à 22:48, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-05 22:34:06)
>> Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit :
>>> Package: node-cosmiconfig,jest
>>> Severity: normal
>>>
>>> Both node-cosmiconfig and jest embed Nodejs module callsites.
>>>
>>> jest provides it as
Quoting Xavier (2020-12-05 22:34:06)
> Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit :
> > Package: node-cosmiconfig,jest
> > Severity: normal
> >
> > Both node-cosmiconfig and jest embed Nodejs module callsites.
> >
> > jest provides it as virtual package node-callsites,
> > but jest has a
Control: tags -1 +fixed-upstream
On 25 Sep 2020, I wrote:
> [...] out of all compressors shipping their own FOOgrep,
> your xzgrep can handle most of the rest. Thus, instead of adding a yet
> another set of binaries, I believe it would be nice to instead make
> xzgrep more universal -- and
Le 05/12/2020 à 22:22, Jonas Smedegaard a écrit :
> Package: node-cosmiconfig,jest
> Severity: normal
>
> Both node-cosmiconfig and jest embed Nodejs module callsites.
>
> jest provides it as virtual package node-callsites,
> but jest has a much larger (build-dependency tree.
>
> Please consider
Hi,
This package specifies Architecture: any (or a variant of it) but
currently FTBFS on arm64, while it is currently building fine on amd64.
If arm64 is not supposed to be supported by this package, it might be
better to specify a subset of architectures, see
Control: severity -1 minor
On 05/12/20 at 13:26 +0100, Lucas Nussbaum wrote:
> Source: plast
> Version: 2.3.2+dfsg-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuil
I had the same problem trying to upgrade from postgresql 11 to 13. I got
the same "ee key too small" error.
pg_upgradecluster exited without creating a working upgrade and without
giving an error message. It did not appear to fail.
I dropped the non-working pg 13 cluster and then ran:
sudo
Package: node-cosmiconfig,jest
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Both node-cosmiconfig and jest embed Nodejs module callsites.
jest provides it as virtual package node-callsites,
but jest has a much larger (build-dependency tree.
Please consider shifting to
Package: calamares
Version: 3.2.4-3
Severity: normal
Hi!
I've just done a test installation using a 10.7.0 live
image. Calamares will happily let me tell it I want my username on the
new system to be "root". The installation continues happily for a
while, then fails when useradd fails.
It would
Le 04/12/2020 à 14:47, Xavier a écrit :
> Le 13/11/2020 à 12:04, Xavier a écrit :
>> Le 13/11/2020 à 11:26, Julien Puydt a écrit :
>>> Package: jest
>>> Version: 26.6.3+ds+~cs64.27.30-1
>>>
>>> The file /usr/share/nodejs/package.json says the TypeScript definitions
>>> are available in
On 15973 March 1977, Sylvestre Ledru wrote:
So you are right, thanks for spotting my mistake, which is because
I
indeed only check if dak rm would cause any issues. I agree that we
thus likely cannot remove it for now from unstable.
It has been removed despite this comment. This causes a bunch
Hi Erik,
Erik Schanze wrote:
>Package: pdfarranger
>Version: 1.1.1-1
>Followup-For: Bug #976591
>
>Dear Maintainer,
>
>here is the file,
Two slides, one text about Radiomuseum and one diagram? No problem here
with preview (same version and release with own apparmor & firejail
profile)
--
> It seems pdfarranger could not deal with it. That's a pity.
Indeed. Even version 1.6.2 (the latest) cannot. May be 1.7.0 will (may be not).
In the meantime you have to decrypt the pdf file with another tool (ex: qpdf),
before importing it in pdfarranger.
> So the bug is a combination of
On 05/12/20 at 21:30 +0100, Geert Stappers wrote:
> Yes, that should also fail on amd64 ...
It does not fail on amd64 (build log attached).
Lucas
DC-Build-Header: rust-mach-o-sys 0.1.1-3 / 2020-12-05 18:07:02 +
DC-Task: type:rebuild-full source:rust-mach-o-sys version:0.1.1-3
Package: partman-crypto
This isn't really a bug in partman-crypto, but I'm reporting it here
for tracking purposes as requested by Steve McIntyre.
The symptom I first experienced was when doing an install on a Tiger
Lake laptop with a 1TB SSD. The step where we run blockdev-wipe was
going to
Control: severity 976588 minor
Control: severity 976576 minor
Control: retitle 976588 rapmap: FTBFS on arm64 (when trying to build arch:all)
Control: retitle 976576 spring: FTBFS on arm64 (when trying to build arch:all)
Hi,
This package builds Arch:all binary packages, but they cannot be built
I pushed a commit that works around the _mm_malloc / xmmintrin.h issue ,
but there is usage of the rdtsc assembly operand that I don't have an arm64
analogue for.
On Sat, 5 Dec 2020 at 21:07, Andreas Tille wrote:
> Hi Steve,
>
> On Sat, Dec 05, 2020 at 04:18:53PM +, Steve McIntyre wrote:
>
Package: src:linux
Version: 5.9.11-1
Followup-For: Bug #969179
X-Debbugs-Cc: j...@joshtriplett.org
I'm still experiencing this with current kernels:
Dec 04 22:53:26 s kernel: iwlwifi :04:00.0: Queue 11 is active on fifo 1
and stuck for 1 ms. SW [243, 117] HW [243, 117] FH
Hi,
This package only builds Arch:all binary packages. Unfortunately, I
don't think that we have a way to indicate that such binary packages
must be built on a specific architecture, and thus avoid a failure on
arm64.
In those cases, building those packages on amd64 works fine, so the bug
is
I'm still looking for help with the OpenLDAP packages. I'm not an
OpenLDAP user any more, and I would like to eventually hand off the
package to a new maintainer.
The current 2.4 package is in OK shape. It's up-to-date in unstable and
backports, and I'm able to handle the low volume of
Re: Gregor Riepl
> Please consider building pynest2d for all supported Python interpreters in
> unstable, not just the latest (3.9 at this point).
Right, I had noticed immediately after uploading, and wanted to fix
that once the package get accepted, but I guess I would have forgotten
in the
Control: retitle -1 rust-mach-o-sys: unsigned values cannot be negated
On Sat, Dec 05, 2020 at 02:28:20PM +0100, Lucas Nussbaum wrote:
> Source: rust-mach-o-sys
> Version: 0.1.1-3
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it
ation: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
>
> Relevant part (hopefully):
> > /bin/b
package: pdf.js
version: 2.6.347+dfsg-2
severity: wishlist
There is a node module pdfjs-dist
https://www.npmjs.com/package/pdfjs-dist which includes a prebuilt
version of pdf.js. gitlab needs this (currently it is pulled from
npmjs.com via yarn), so it would be good if pdfjs-dist can be
On 26 Dec 2019 Fabrice BAUZAC-STEHLY wrote:
Version 7.5.3 is really considered newer than 7.5.3~deb10u1 (beware, it
is a tilde, not a dash):
# ge = "greater or equal"
$ dpkg --compare-versions 7.5.3 ge "7.5.3~deb10u1"; echo $?
0 # means "true"
Indeed, according to the Debian Policy [1]:
[1]
Source: r-bioc-deseq2
Version: 1.30.0+dfsg-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: issue
Dear maintainer,
Your package has an autopkgtest, great. However, apparently you have
been waiting for a test dependency to become available
On Sat, Dec 05, 2020 at 07:45:29PM +, Debian Bug Tracking System wrote:
> Date: Sat, 5 Dec 2020 14:28:14 +0100
> From: Lucas Nussbaum
> To: sub...@bugs.debian.org
> Subject: rust-cpuid-bool: FTBFS: dh_auto_test: error:
> /usr/share/cargo/bin/cargo test --all returned exit code 101
> Source:
Package: python3-pynest2d
Version: 4.8.0-1
Severity: important
X-Debbugs-Cc: onit...@gmail.com
Dear Maintainer,
Please consider building pynest2d for all supported Python interpreters in
unstable, not just the latest (3.9 at this point).
When running Python software in a different interpreter,
On 05/12/20 at 14:28 +0100, Lucas Nussbaum wrote:
> Source: specutils
> Version: 1.1-2
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
Quoting Xavier (2020-12-05 20:42:23)
> Control: tags -1 + pending
>
> Le 05/12/2020 à 19:19, Jonas Smedegaard a écrit :
> > Please consider updating to 1.0rc3 (in preparation for 1.0rc4 which
> > might soon be released, judging from issue tracker chatter).
[...]
> You're absolutely right,
On 05/12/20 at 14:30 +0100, Lucas Nussbaum wrote:
> Source: zvmcloudconnector
> Version: 1.4.1-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 13:31 +0100, Lucas Nussbaum wrote:
> Source: strace
> Version: 5.5-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:32 +0100, Lucas Nussbaum wrote:
> Source: tuxmath
> Version: 2.0.3-6
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 14:28 +0100, Lucas Nussbaum wrote:
> Source: rust-packed-simd
> Version: 0.3.3-5
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 14:28 +0100, Lucas Nussbaum wrote:
> Source: rust-core-arch
> Version: 0.1.5-4
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 14:06 +0100, Lucas Nussbaum wrote:
> Source: librsvg
> Version: 2.50.2+dfsg-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:21 +0100, Lucas Nussbaum wrote:
> Source: libgsecuredelete
> Version: 0.3-2
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:25 +0100, Lucas Nussbaum wrote:
> Source: opencolorio
> Version: 1.1.1~dfsg0-6
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 13:47 +0100, Lucas Nussbaum wrote:
> Source: pandas
> Version: 1.1.4+dfsg-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:54 +0100, Lucas Nussbaum wrote:
> Source: bazel-bootstrap
> Version: 3.4.0+ds-2
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 13:49 +0100, Lucas Nussbaum wrote:
> Source: python-escript
> Version: 5.5-5
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:49 +0100, Lucas Nussbaum wrote:
> Source: python-x2go
> Version: 0.6.1.3-2
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:21 +0100, Lucas Nussbaum wrote:
> Source: libgit2-glib
> Version: 0.28.0.1-2
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 13:58 +0100, Lucas Nussbaum wrote:
> Source: elinks
> Version: 0.13.2-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:27 +0100, Lucas Nussbaum wrote:
> Source: pulseview
> Version: 0.4.2-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:49 +0100, Lucas Nussbaum wrote:
> Source: python-eventlet
> Version: 0.26.1-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 14:21 +0100, Lucas Nussbaum wrote:
> Source: dolphin-emu
> Version: 5.0+dfsg-6
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 14:28 +0100, Lucas Nussbaum wrote:
> Source: ring-clojure
> Version: 1.6.2-2
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:19 +0100, Lucas Nussbaum wrote:
> Source: golang-gopkg-libgit2-git2go.v28
> Version: 0.28.5-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuil
On 05/12/20 at 14:24 +0100, Lucas Nussbaum wrote:
> Source: gsound
> Version: 1.0.2-4
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:45 +0100, Lucas Nussbaum wrote:
> Source: lintian-brush
> Version: 0.87
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:47 +0100, Lucas Nussbaum wrote:
> Source: pyside2
> Version: 5.15.0-5
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:44 +0100, Lucas Nussbaum wrote:
> Source: conda-package-handling
> Version: 1.7.2-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 14:12 +0100, Lucas Nussbaum wrote:
> Source: ruby-psych
> Version: 3.1.0+really3.1.0-1
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packag
On 05/12/20 at 14:03 +0100, Lucas Nussbaum wrote:
> Source: jruby
> Version: 9.1.17.0-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
On 05/12/20 at 13:19 +0100, Lucas Nussbaum wrote:
> Source: grpc-java
> Version: 1.20.0+ds-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid
Hi Steve,
On Sat, Dec 05, 2020 at 04:18:53PM +, Steve McIntyre wrote:
>
> xmmintrin.h is fundamentally tied to x86-only SIMD intrinsics. Either
> the package doesn't support non-x86, or there's a bug and it's
> mis-detecting which platform you're on.
I guess the problem is that debian/rules
n Sat, Dec 05, 2020 at 01:21:26PM +0100, Lucas Nussbaum wrote:
> Source: libcereal
> Version: 1.3.0-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all pa
On Sat, 05 Dec 2020 at 13:55:04 +0100, Kai Juse wrote:
> bwrap: No permissions to creating new namespace, likely because the kernel
> does not allow non-privileged user namespaces. On e.g. debian this can be
> enabled with 'sysctl kernel.unprivileged_userns_clone=1'.
On standard Debian kernels,
Hi Lucas,
This is reproducible under amd64 machines. I think this issue
is related to a recent update of the dssp package; I'm having a
look to see if I can pinpoint the issue more precisely.
Thanks for reporting this!
--
Étienne Mollier
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e
It behaves different.
Now I see a error message:
"File ... is encrypted. Support for encrypted files has not been
implemented yet. File export failed."
and no saved file.
I inspect it:
$ pdfinfo Projekte/ziphona_tuerkis/schematic.pdf
Title: www.radiomuseum.org: Ziphona Türkis
I have observed this bug as fixed in Debian testing.
Package: abook
Version: 0.6.1-1+b3
Severity: normal
Dear Maintainer,
When running a command like this:
abook --convert --infile --outformat mutt
If the Abook includes entries where the email address has no local part,
such as "@example.com", this entry will be included as-is in the output
Am 05.12.2020 um 19:53 schrieb Ma Wo:
Package: systemd
Followup-For: Bug #971760
I just like to add a kind of workaround or solution.
I got 10 error messages per minute because of a check_mk ssh agent monitoring
the server.
That means you regurlarly (every minute?) run systemctl
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 976...@bugs.debian.org
Hi
as you can read in Steve McIntyre's comment in Bug#976481 libxenium-dev
was wrongly declared as Architecture all. Since this is not correct all
previously built packages for several architectures of libatomic-queue
Control: tags -1 + pending
Le 05/12/2020 à 19:19, Jonas Smedegaard a écrit :
> Package: node-cheerio
> Version: 0.22.0-2
> Severity: normal
>
> Hi,
>
> Thanks for packaging Cheerio.
>
> Currently packaged release is the latest upstream stable release,
> but was released 4 years ago . 1.0rc1 was
Control: severity -1 important
Control: retitle -1 helpful-el: FTBFS randomly on arm64
Hi,
On 05/12/20 at 14:24 +0100, Lucas Nussbaum wrote:
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
I tried again, and
[ Copying other bugs affected by new latex failures since my last
rebuild ]
Hi Paolo,
On 05/12/20 at 18:55 +0100, Paolo Greppi wrote:
> Hi Lucas (is it you, or a bot?),
I'm not a bot, but only noticed this message by chance. Remember that
bug submitters do not receive emails sent to
1 - 100 of 317 matches
Mail list logo
