I can confirm this happens during a rebuild in my own sbuild chroots.
The core issue appears to be that when the make rules call help2man, the
version string provided is an empty string. Digging into d/rules, it looks
like DEB_VERSION_UPSTREAM_REVISION is unset during the process, which is why
For everyone's awareness: this same t64 transition is going on downstream in
Ubuntu, and I'm also tracing rebuilds, etc. with changed dependencies there as
well which are being done by other core devs there, so those changes may
trickle back up into Debian here.
Thomas
(this email is the one
The only package that has a changed name that I can see is `libqt5sql5` to
`libqt5sql5t64`. I have already put this in the revisions in Salsa at the
moment.
If `libqt5help5` has a rename pending to `libqt5help5t64` and that's not yet in
Unstable, then I can't make that revision safely.
Thom
nt from my Galaxy
Original message
From: Jérémy Lal
Date: 8/29/23 05:16 (GMT-05:00)
To: Thomas Ward , 1050...@bugs.debian.org
Cc: Bastian Germann
Subject: Re: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186:
libnginx-mod-http-lua: depends on obsolete pcre3 library
Le lun. 21 août
Bastian:
As I understand the module, for over a year now the latest Lua module
from OpenResty requires LuaJIT to actually compile. See
https://salsa.debian.org/nginx-team/libnginx-mod-http-lua/-/blob/main/debian/control#L8
where this is in the build deps.
I have not tested removing the PCRE
All:
See the Lua NGINX module issue here in upstream:
https://github.com/openresty/lua-nginx-module/issues/1984
This has been an open issue since December 2021, and there has *NOT*
been massive movement yet upstream towards PCRE2 support.
The last info on that bug from July 13th indicates t
I would suggest that we move the configuration files out of `nginx` main
and keep it as a separate binary package, whether we call it
`nginx-common` or `nginx-config` or whatever.
In either case, there are benefits to having the configuration file
*separate* from the binaries (see Apache where
Package: pastebinit
Severity: serious
Version: 1.6.2-1
(Serious severity selected by Package Maintainer - unfit for release in
current state)
When using pastebinit to post to the Debian pastebin (default), the
system returns a plain "https://paste.debian.net"; link and NO link to an
actual p
Control: tags -1 pending
This will be fixed in -9 when updated packaging is uploaded.
A merge request [1] included a downgrade of the Lua module to the last
known functional version, which solves the FTBFS problem as that version
of the Lua module can still build on s390x due to the older libl
So, it seems that this problem leads to a deeper problem, one with a
fix, and one that leaves the s390x support at an impasse.
Firstly, mips64el has libluajit available. We can fix the mips64el
builds by adding libluajit-5.1-dev as an explicit dependency for mips64el.
However, we can NO LONG
source: nginx
found: 1.18.0-8
severity: serious
The builds for mips64el and s390x are failing to build and thus failing
to allow 1.18.0-8 to migrate.
Both error with luajit not found errors.
cc -c -fPIC -g -O2 -ffile-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security
https://bugs.debian.org/943705 has been reported as the core cause.
The builds are being give-backed now, as we are fairly sure that the
issue reported in the FTBFS bug here was due to debhelper issues which
were fixed on the 7th, five days after the autobuilds were triggered.
I'm going to ma
I ran this exact package through a rebuild in an sbuild environment just
now, and cannot reproduce your FTBFS. Automated build(s) failed to
reproduce this in a pbuilder environment as well.
Did you do anything to the package to make it trigger this FTBFS? What
Arch and Distro did you build a
3.4.6 Redmine doesn't support ruby-mail beyond 2.6.4. Neither does the
latest 3.4.x release.
This package would need to be updated to Redmine 4.0.1 and track the
4.0.x series to get the proper ruby-mail support.
(Looking into this downstream in Ubuntu, this was discovered. I am
simply sharing t
Source: nginx
Severity: serious
Version: 1.6.2-5+deb8u3
This was originally identified as a result of my own failure downstream
in Ubuntu when applying the patches from Debian for CVE-2016-1247.
One of the things added was nginx-common.config. In this, the following
set of code exists:
log_syml
On 08/03/2015 10:41 AM, Tristan Seligmann wrote:
> Unfortunately there are some significant challenges with 2.0+. The
> primary issue is the dependency on tlslite, which was removed from
> Debian previously due to being insecure and unmaintained. In addition,
> quite a bit of the certificate handli
1.9.8 is a year old. In addition, 2.4 is the current version.
Failing to update breaks recovery of wallets from newer versions, and
there are quite a lot of improvements in 2.4 over 1.9.8 that should be
reviewed and included.
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.d
the crash seems to be caused by the AMD fglrx driver and
/usr/lib/libamdocl64.so
apt-get purge amd-opencl-icd
solves the problem for code-aster
I didn't check to see if anything else needed amd-opencl-icd
is there anyway to force code aster and associated libraries to not use
amd-opencl-icd ?
Source: nginx
Version: 1.6.2-5
Severity: grave
Tags: security
Originally filed by myself downstream in Ubuntu at
https://bugs.launchpad.net/nginx/+bug/1403283
Originally identified in 1.6.2-5, but it likely affects other versions
as well, if `gzip on;` is defined in the default configs.
(Severit
Assuming it follows similar build rules in its Debian packaging in
Experimental, then I'm assuming it also is covered.
On Tue, Mar 18, 2014 at 7:06 PM, James Cloos wrote:
>> "y" == yatiohi writes:
>
> y> we are not vulnerable since nginx is compiled with the --with-debug
> y> configure opti
20 matches
Mail list logo
