I've prepared a patch that allows additional syscalls on some
architectures and pushed it to a branch in the debcargo-conf repo.
Rust-sniffglue is not a key package, so as I see it you have two
possible ways forward here.
The first is to upload the package as-is and file an unblock
request just
Package: rust-libnotcurses-sys
Version: 2.1.8-1
Severity: serious
After spotting a FTBFS on my ddpo page, I also decided to check the ddpo page
for the rust team.
A number of packages were marked as FTBFS, most appeared to be false positives
either resource
exhaustion on the reproducible builds
package: rust-compiler-builtins
version: 0.1.26-2
severity: serious
While looking through my ddpo page I noticed it was listing
rust-compiler-builtins as FTBFS,
following the link through to reproducible builds showed it had been failing to
build on
armhf for some time.
Rust upstream have rena
Tags 985775 +sid
thanks
Git changed the gitexecdir directory. Said change is currently blocked from
migrating to testing by bug 985416 which was cloned from bug 985351, ongoing
discussion of the issue seems to be in bug 985351.
Given where we are in the release process, that there still seems to
> The package 'libpigpiod-if-dev' should contain all the header files and object
No, it contains the header files and shared library symlinks for building
against the libpigpio-if and libpigpio-if2 libraries.
The server and direct access GPIO libraries are not packaged in Debian
because they a
On 07/03/2021 02:30, plugwash-urgent wrote:
my tentative conclusion is that the insert_many
operation in rust-arrayvec does not seem to actually be used.
While I can't find any applications that uses the broken function
in rust-smallvec (saying arrayvec above was a brainfart), I
still think we
I would thus propose simply dropping the build-dependency, a debdiff doing that
is
attached, I may or may not NMU it later.
I have gone ahead with the NMU, final debdiff is attatched.
diff -Nru xscorch-0.2.1/debian/changelog xscorch-0.2.1/debian/changelog
--- xscorch-0.2.1/debian/changelog
On 16/02/2021 18:29, Peter Green wrote:
Any ideas what the problem might be?
Update: in my test environment uninstalling git solved the failure
to generate, but looking at the logs on reproducible builds,
that doesn't seem to explain the failures over there
Package: consul
Version: 1.8.7+dfsg1-1
Tags: FTBFS
(not filing as rc because none of the build failures I noticed were on official
debian buildds)
I noticed that consul was failing to build in raspbian bullseye with a
testsuite failure. So I tried to do a build locally
with the testsuite disab
Package: ehcache
Version: 2.6.11-4
Severity: serious
ehcache build-depends on libgeronimo-jta-1.0.1b-spec-java which is no longer
available in testing. The physical package was removed back in september
but it remained available as a virtual package provided by
libgeronimo-jta-1.1-spec-java until
Package: openms
Version: 2.6.0+cleaned1-2
Severity: serious
openms build-depends on seqan-dev which was built by the sequan source
package, which was removed from unstable and testing recently. The person
requesting the removal stated that "There are no other users of seqan 1.x
in Debian." but it
tags 982559 +patch
thanks
Taking a poke through the source it seems there is a bunch of logic in the
build system to
detect if readline is available, but I can't find any evidence of any code
actually
using readline. After removing the build-dependency I can successfully build
xscorch
in an en
Package: kodiplatform
Version: 20180302-1
Severity: serious
kodiplatform build-depends on kodi-addons-dev which is not currently available
on mips64el, mipsel or s390x. However it appears that in the past
kodi-addons-dev
was an arch all package and hence available on these architectures allowing
Package: ftp.debian.org
Traditionally when I want to know why a binary package that was no longer
built by the coresponding source package was still in unstable I would
look at the cruft report at
https://ftp-master.debian.org/cruft-report-daily.txt
However in recent times (can't remember how l
This test has never passed, it failed back in December 2019, then was
neutral for some time, before returning to failure recently/
Unfortunately debci doesn't keep logs long-term, but I suspect that
the test was neutral due to unsatisfiable test dependencies.
The first error in the log is
[cro
tags 977248 +patch
thanks
The issue is a change in opencv4.pc, 4.2 has
includedir_old=${prefix}/include/opencv4/opencv
includedir_new=${prefix}/include/opencv4
But 4.5 has
includedir=${prefix}/include/opencv4
I whipped up a patch for this, soon after doing so I noticed that upstream
had also
Version: 0.3.3-6
Sorry forgot to close this bug in the changelog.
librust-cfg-if-0.1+default-dev (>= 0.1.9-~~) ,
(And a matching, hard-coded Depends line on the binary package)
However, this version of rust-cfg-if is now gone and replaced by 1.0
A new source package "rust-cfg-if-0.1" has been introduced which builds
the binary package librust-cfg-if-0.1-dev
ely because of these rules, no
other reason.
- Craig
On Wed, 16 Dec 2020 at 10:21, peter green mailto:plugw...@p10link.net>> wrote:
Package: wordpress
Version: 5.5.3+dfsg1-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer
migrate
On 16/12/2020 21:48, Thorsten Alteholz wrote:
Hi Peter,
are you sure about your bug report?
The control file of osmo-bsc/1.6.1+dfsg1-3 contains:
Build-Depends: debhelper-compat (= 12),
pkg-config,
libosmocore-dev (>= 1.4.0),
libosmo-sccp-dev
notfound 976420 1:12.1.4-1
found 976420 1:2.1.4-1
close 976420 1:2.1.5-1
retitle 976420 mrpt: ftbfs with libjsoncpp 1.9.4
severity 976420 serious
thanks
The new version of libjsoncpp is now in testing/unstable, so this bug is now rc.
It is fixed in unstable, but the fix is blocked from migration
Package: wordpress
Version: 5.5.3+dfsg1-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer
migrate to testing, please make a source-only upload so your package
can migrate.
Source: osmo-bsc
Version: 1.6.1+dfsg1-3
Severity: serious
Tags: ftbfs
osmo-bsc build-depends on libosmo-legacy-mgcp-dev, which has been dropped by
the osmo-mgw
source package. It is still present in unstable as a cruft package, but is
completely
gone from testing, meaning it is no longer possib
Package: golang-github-containers-buildah
Version: 1.16.6+dfsg1-1
Severity: serious
golang-github-containers-buildah fails to build with the latest version of
golang-github-containers-image-dev.
I initially saw this in raspbian, but it's also happening on the reproducible
builds test infrastruc
package: ruby-licensee
Version: 8.9.2-1
Severity: serious
Tags: bullseye, sid
The autopkgtest for ruby-licensee is failing with ruby-rugged 1.1.0.
GEM_PATH= ruby2.7 -e gem\ \"licensee\"
/usr/lib/ruby/vendor_ruby/rubygems/specification.rb:1398:in `rescue in block in
activate_dependencies': Coul
package: ruby-gollum-rugged-apapter
Version: 0.4.4.2-2
Severity: serious
The autopkgtest for ruby-gollum-rugged-adapter is failing with ruby-rugged
1.1.0.
┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
Package: debcargo
Version: 2.4.3-2+bw
Severity: grave
After the recent binnmu of debcargo. debcargo update
(after deleting the cache) gives.
Updating crates.io index
Something failed: failed to fetch `https://github.com/rust-lang/crates.io-index`
Caused by:
invalid version 0 on git_pr
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 autopkg
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
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
seems
your test workflow needs some work. arm64 is not on the arc
Package: rust-sha2
Version: 0.9.2-1
Severity: serious
The new version of rust-sha2 picked up a build-dependency on rust-cpuid-bool,
unfortunately that package is only available on i386 and amd64. Either the
dependency needs to become arch-specific (not sure if cargo/debcargo can support
that thou
> This will impact quite some other modules.
I agree that the current autoremoval list looks pretty scary, so I decided to
do some
dependency analysis. It seems there are 5 source packages with direct or
indirect hard
dependencies on rust-js-sys.
rust-www-sys
rust-ring
rust-rustls
rust-sct
rus
On 26/11/2020 13:20, peter green wrote:
On 25/11/2020 08:11, Sylvestre Ledru wrote:
Le 25/11/2020 à 01:55, peter green a écrit :
Unfortunately it seems that there have been API changes in semver-parser that
actually effect debcargo
Do you need help to fix that?
"help" is pr
On 25/11/2020 08:11, Sylvestre Ledru wrote:
Le 25/11/2020 à 01:55, peter green a écrit :
Unfortunately it seems that there have been API changes in semver-parser that
actually effect debcargo
Do you need help to fix that?
"help" is probablly an understatement. I have no clu
On 25/11/2020 00:55, peter green wrote:
and a bunch more similar errors, I really have no idea where to start on fixing
this.
Forgot to mention in a previous mail I have pushed my work in process to a
branch
"debcargo-minimalfixes" in case anyone else wants to pick it up.
On 24/11/2020 19:04, Sylvestre Ledru wrote:
Hello,
Le 24/11/2020 à 19:06, Calum McConnell a écrit :
> Package: debcargo
> Severity: important
> X-Debbugs-Cc: calumlikesapple...@gmail.com
>
As the freeze approaches, it becomes more important to make sure that every
package desired for the n
merge 972908 957079
tags 972908 +patch
tags 972908 +fixed-upstream
thanks
Matthias Klose wrote in bug 957079:
The full build log can be found at:
http://people.debian.org/~doko/logs/gcc10-20200225/ceph_14.2.7-1_unstable_gcc10.log
The last lines of the build log are at the end of this report.
U
Package: fprint-demo
Version: 20080303git-7
Severity: serious
fprint-demo build-depends on libfprint-dev and depends on libfprint0 which are
no longer built by the libfprint
source package.
(I know that there is a removal request filed with the ftpmasters, but there
still needs to be a rc bug
Package: pam-python
Version: 1.0.9-1
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing.
Please make a source-only upload so your package can migrate.
Source: pam-python
Version: 1.0.8-1
Severity: serious
The autopkgtest for pam-python is broken, it tries to install a binary package
that does not exist.
Investigating (0) autopkgtest-satdep:amd64 < 0 @iU mK Nb Ib >
Broken autopkgtest-satdep:amd64 Depends on python-pam:amd64 < none @un H >
Re
On 11/11/2020 15:42, Norbert Preining wrote:
Hi Peter,
again, thanks a lot
I did some digging and was able to find an upstream commit fixing this issue.
https://github.com/JuliaLang/julia/commit/master?diff=unified&short_path=30dfa74
Are you sure this is the correct commit? This does some do
retitle 928131 julia: FTBFS on armhf
thanks
Since version 1.4.0+dfsg-1 once again builds on arm64. On the other hand on
armhf is still failing.
/<>/src/debuginfo.cpp: In member function ‘virtual void
JuliaJITEventListener::_NotifyObjectEmitted(const llvm::object::ObjectFile&, const
llvm::Run
reassign 973298 rust-failure
retitle 973298 rust-failure: Should rust-failure be removed from unstable?
thanks
As there was no objection (although admittely 2 weeks might be short),
but the upstream is officially end-of-life. So just reassigned the
bug to ftp.d.o for removal.
I've just spotted
With a recent update, it broke bat:
The error is:
missing:
pkg:
package: librust-syntect+parsing-dev
version: 3.3.0-3
architecture: amd64
unsat-dependency: librust-onig-5+default-dev:amd64
depchains:
-
depchain:
-
package: sbui
On 05/11/2020 17:32, peter green wrote:
I have whipped up a patch which changes the dependency generation in sdpa and
bumps the
build-dependency (so the new depedency generation won't be used with old mumps
packages).
I have built it and uploaded it to raspbian, no intent to NMU in D
source: sdpa
Version: 7.3.14+dfsg-1
Severity: serious
sdpa was recently rebuilt for the mumps transition, unfortunately the resulting
binary packages
depend on libmumps-seq-5.3.5 which does not exist. The package is now named
libmumps-seq-5.3.
It appears the versioning scheme for the mumps bina
severity 972478 serious
thanks
sorry forgot the severity when filing this bug.
Firstly https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972432 needs to be
actioned by the ftpmasters.
This has been done, however checking the britney logs afterwards has revealed
another issue, for which
I hav
Package: cantor-backend-scilab
Version: 4:20.04.3-1
Severity: serious
As a result of swt dropping support for 32-bit targets, libjogl2-java can no
longer be built on i386 and armhf and the
existing binaries have been removed in unstable. This in turn has lead to the
removal of scilab on those a
Package: rust-onig
Version: 5.0.0-3
Severity: serious
The autopkgtest for rust-onig fails with memory errors on i386 and armhf.
https://ci.debian.net/data/autopkgtest/testing/armhf/r/rust-onig/7843624/log.gz
Caused by:
process didn't exit successfully:
`/tmp/tmp.p7bE9eMN2s/target/armv7-unkn
Severity 973387 normal
Retitle 973387 rust-bindgen cannot be built with "static" feature.
On 29/10/2020 19:44, Sylvestre Ledru wrote:
Hello,
Le 29/10/2020 à 20:39, peter green a écrit :
I was looking at an autopkgtest failure in rust-bindgen. The failure happened when when
testin
I was looking at an autopkgtest failure in rust-bindgen. The failure happened when when
testing with the "static"
feature. It appears the failure was caused by a lack of libclang.a
When looking at the file list of libclang-9-dev I noticed that there was no
libclang.a but there were a number of
Package: rust-bindgen
Version: 0.55.1-1
Severity: serious
rust-bindgen 0.55.1 introduced two new featuresets. The autopkgtests for these
featuresets are failing
For the "runtime" feature we have.
> test::commandline_multiple_headers stdout
> bindgen tests/headers/16-byte-alignment.h -
do actually already do work in dpkg. You represent them as:
Build-Depends:
librust-foo-dev (>= 0.4),
librust-foo-dev (<< 0.6)
><--snip->
> Provides: librust-foo-dev = 0.4.2-1
>
> then the conjunctive, versioned Depends would be able to figure out how
> to satisfy it.
The problem is tha
Package: celery
Version: 4.4.6-1
Severity: serious
The autopkgtest for celery 4.4.6-1 is failing with the new python3-defaults.
https://ci.debian.net/data/autopkgtest/testing/amd64/c/celery/7741503/log.gz
=== FAILURES ===
severity 948105 serious
thanks
In #917104 uhttpmock has been filed for removal, but libgdata still
uses it.
uhttpmock has now been removed from testing/unstable, so libgdata's
build-dependencies are no longer satisfiable.
Package: rust-lldb
Version: 1.41.1+dfsg1-1~deb10u1
Severity: serious
rust-lldb in buster now depends on python3-lldb-7, however it does not appear
that this package has ever existed in Debian.
Tags 972478 -sid
thanks
On 19/10/2020 04:15, peter green wrote:
Package: libjogl2-java
Version: 2.3.2+dfsg-9
Tags: bullseye, sid
x-debbugs-cc: sci...@packages.debian.org
x-debbugs-cc: k...@packages.debian.org
Justification: rc policy: packages must be buildable in the same release.
libjogl2
Package: libjogl2-java
Version: 2.3.2+dfsg-9
Tags: bullseye, sid
x-debbugs-cc: sci...@packages.debian.org
x-debbugs-cc: k...@packages.debian.org
Justification: rc policy: packages must be buildable in the same release.
libjogl2-java can no longer be built on 32-bit architectures, specifically
a
Package: geoalchemy2
Version: 0.7.0-1
Severity: serious
geoalchemy2 build-depends on postgresql-12-postgis-3 and
postgresql-12-postgis-3-scripts,
which have been replaced by postgresql-13-postgis-3
postgresql-13-postgis-3-scripts, the
old packages are still present in unstable as cruft packages
I just looked at this issue.
rust-ncurses is a thin wrapper around ncurses. It exposes unsafe (in the rust
sense) C
APIs to safe rust code. The rust security team consider this to be a
vulnerability.
There is more discussion of this issue at
https://github.com/jeaye/ncurses-rs/issues/188
the
Package: libtickit-perl
Version: 0.71-1
Severity: serious
The libtickit-perl autopkgtest is failing on the unstable->testing migration
tests (the plain unstable tests are not
up to date enough to be useful). On i386 and amd64 this failure is a regression
(on the other architectures where
autopk
Package: vt
Version: 0.57721+ds-2
Severity: serious
Justification: rc policy: packages must be buildable within the same release.
vt build-depends on libcurl4-openssl-dev and libhts-dev. Libhts-dev recently
added a dependency on libcurl4-gnutls-dev.
Since libcurl4-openssl-dev and libcurl4-gnutls
Package: augustus
Version: 3.3.3+dfsg-3
Severity: serious
Justification: rc policy: packages must be buildable within the same release.
Augustus build-depends on libcurl4-nss-dev and libhts-dev. Libhts-dev recently
added a dependency on libcurl4-gnutls-dev.
Since libcurl4-nss-dev and libcurl4-gn
reopen 912941
thanks
On 24/09/2020 06:25, Andreas Metzler wrote:
On 2020-08-28 peter green wrote:
Tags 966904 +patch
thanks
The issue is that Magick++.h (indirectly) includes assert.h inside a namespace.
[...]
I would argue that is a bug in imagemagick and have filed bugs in both Debian
and upstream as
https
Source: rhythmbox
Version: 3.4.4-2
Severity: serious
rhythmbox build-depends on gstreamer1.0-doc which is no longer built by the
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely
gone from testing.
Source: farstream-0.2
Version: 0.2.8-5
Severity: serious
farstream-0.2 build-depends on gstreamer1.0-doc which is no longer built by the
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely
gone from testing.
Source: clutter-gst-3.0
Version: 3.0.27-1
Severity: serious
clutter-gst-3.0 build-depends on gstreamer1.0-doc which is no longer built by
the gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely
gone from testing.
Source: spice-gtk
Version: 0.38-2
Severity: serious
spice-gtk build-depends on gstreamer1.0-doc which is no longer built by the
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely
gone from testing.
Source: python-magcode-core
Version: 1.5.4-2
Severity: serious
The release team have decreed that non-buildd binaries can no longer migrate to
testing, please make a source-only
upload so your package can migrate.
tags 925781 +patch +pending
tags 967177 +patch +pending
thanks
I have decided to take the Ubuntu fixes for mozjs52 and turn them into a NMU. I
also ran into some issues
with the clean target while preparing the NMU so I fixed those too.
mozjs52 has only one reverse-dependency: cjs which in turn
The debian python maintainers are trying to phase out python 2.
python 2 has been granted a stay of execution as some important software
requires it to build. However we should still
be attempting to get rid of use at runtime if at all possible. Also the "unversioned
python" packages have been
The libaccounts-glib package does not seem to be getting maintained in Debian,
it has had a rc bug (deprecated declarations
and -Werror) for 8 months with no maintainer response and has recently picked
up a second one (unversioned python removal).
It has not had an upload for 3 years.
Both of t
On 17/09/2020 15:06, Emilio Pozuelo Monfort wrote:
On 12/09/2020 11:09, Emilio Pozuelo Monfort wrote:
This updates buster's rustc to 1.41, as needed by the new firefox 78 ESR.
The bootstrap happens with the upstream binaries as we've done in the past.
I have also avoided the bump to LLVM 9/10, w
severity 942915 serious
thanks
The "python" binary package is no longer available in testing or unstable (in
unstable it's present as a cruft package
but uninstallable, in testing it's completely gone)
Source: aseba
Version: 1.6.0-5
Severity: serious
Tags: bullseye, sid
aseba build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to strictly versione
Source: flowcanvas
Version: 0.7.1+dfsg0-0.5
Severity: serious
Tags: bullseye, sid
flowcanvas build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to
severity 942960 serious
thanks
The "python" binary package has now been removed from testing, hence this bug
is now serious.
If there is still no maintainer response I may well NMU this later.
Source: avw.lv2
Version: 0.1.6~dfsg0-1
Severity: serious
Tags: bullseye, sid
avw.lv2 build-depends on the "python" binary package which is no longer built by the
"python-defaults" source package.
In unstable it is present as a cruft package but said cruft package is
uninstallable due to strictl
Source: pdf2djvu
Version: 0.9.17-1
Severity: serious
Tags: ftbfs, fixed-upstream
pdf2djvu's configure script fails to parse the poppler version with the newly
released poppler 20.
This results in a bunch of errors.
This is fixed upstream in version 0.9.17.1
It seems the recent upload of poppler 20 introduced further breakage.
Poppler changed the return type of Catalog::getDestNameTreeDest and
Catalog::getDestsDest
from LinkDest * to std::unique_ptr
If I am following the code correctly, it seems that extractpdfmark had a memory
leak,
previously, g
Package: gnome-builder
Version: 3.36.0-3
Severity: serious
Tags: patch
The gnome-builder source package build-depends on libenchant-dev (source
package enchant)
which was recently removed from testing (see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956881 ).
However the gnome-builder b
Package: python3-azure-cli
Version: 2.10.1-1
Severity: serious
python3-azure-cli depends on python3-cryptography << 3.0.0 . In unstable this
dependency is unsatisfiable
because python3-cryptography is now at version 3.1-1 .
In testing the dependency is strictly-speaking satisfiable because test
:03PM +0100, peter green wrote:
tags 942965 +patch
tags 961839 +pending
The attached debdiff fixes bugs 942965 and 961839, the former by changing
the build-dependency from python-docutils to python3-docutils and the latter
by adding "ant.build.javac.source=8" and "ant.build.javac.targ
tags 942965 +patch
tags 961839 +pending
The attached debdiff fixes bugs 942965 and 961839, the former by changing
the build-dependency from python-docutils to python3-docutils and the latter
by adding "ant.build.javac.source=8" and "ant.build.javac.target=8" to
debian/ant.properties.
If I do not
Lucas Nussbaum wrote:
> The following packages have unmet dependencies:
> sbuild-build-depends-main-dummy : Depends: libopencc2-data but it is not
installable
> E: Unable to correct problems, you have held broken packages.
> apt-get failed.
Fixed in git.
Tagging this bug as pending
This bu
Package: sleef
Version: 3.4.1-4
Severity: serious
The most recent upload of sleef fixed the build on amd64, armhf, i386 and
ppc64el. Unfortunately
it is still failing on arm64, with the following error.
In file included from /<>/src/libm/sleefsimdsp.c:209:
/<>/src/arch/helpersve.h:94:27: error
(note: this mail represents my opinions as an ordinary dd, I am not a member of
the release team)
due to the fact that it is supposed to (build-)depend on binutils-avr, which
FTBFS.
As I understand it "(build-)depends" should be interpreted as
"depends or build-depends"
The source package e
Tags 957069 +patch
thanks
gcc-10 changed the behaviour around global variables defined in multiple
compilation units. Defined a variable in
multiple compilation units with the default compiler flags will now result in a
link failure.
However in this particular case the variable doesn't appear
Tags 966904 +patch
thanks
The issue is that Magick++.h (indirectly) includes assert.h inside a namespace.
Note that generally only the first include of a header actually does anything
due to the presense of include gaurds.
Therefore if assert.h is included before Magick++.h then everything is f
Package: libmagick++-6.q16-dev
Version: 8:6.9.11.24+dfsg-1+b1
This bug is based on testing related to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966904
Compiling the following simple test program fails.
#include
#include
int main() {
assert(1==2);
}
g++ `pkg-config --cflags ImageM
tags 963290 +patch
thanks
I just took a look at this issue.
First I did some digging in the upstream git repo. Once I figured out their branch
structure (the "master0" branch is
apparently where current releases are made from) I was able to find two
relavent commits.
10ed02f429f75a418ee41814af
tags 968637 +patch
thanks
On 26/08/2020 06:04, peter green wrote:
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
I was able to succesfully apply the upstream change to the
Debian package and built it in Raspbian bullseye-staging .
I also bumped the build
Upstream seem to have a fix for this.
https://sourceforge.net/p/freeimage/svn/1842/
I have prepared a patch for chromium addressing bugs 965960 and 967124
Bug 965960 (crash on 32-bit) was caused by lack of support in the sandbox for
the 64-bit time syscalls that
have recently been added to Linux/glibc. I added __NR_clock_gettime64,
__NR_clock_nanosleep_time64
and __NR_utimens
tags 957816 +patch
thanks
The build failures are caused by a change to default behaviour in gcc-10,
previous versions of gcc defaulted to
-fcommon which allows a variable to be definined in multiple compilation units.
gcc-10 on the other hand defaults
to -fno-common.
There seem to be two seper
On 13/08/2020 19:53, peter green wrote:
thank you for packaging chromium.
after upgrading libc to 2.31, all available chromium: 80 and 83 are cashing.
the bug has been treated at redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=1773289
and has been confirmed by upstream:
https
Package: mailutils
Version: 1:3.9-3.2
Tags: patch
I run a derivative called raspbian and I noticed that mailutils was getting
repeatedly
binnmu'd by our autobinnmuer because the binary packages were not installable.
I don't know what exactly triggered the first binnmu (our autobinnmuer does
su
Package: diffoscope
Version: 156
Severity: serious
Diffoscope has been removed from testing and cannot re-enter because it
build-depends on
gnumeric, which has been kicked out of testing due to a python2 dependency.
Since this build-dependency only appears to be used for testing I would suggest
On 20/08/2020 06:50, Graham Inggs wrote:
For what it's worth, I tried building fpc including your debdiff and
running the autopkgtests in an Ubuntu PPA.
They passed on amd64,
Thanks for confirming (my local setup is far from the same as the test
infrastructure)
and failed on arm64 [1] and
501 - 600 of 2797 matches
Mail list logo
