Bug#1076900:

[Thomas Ward]

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 it 
produces an empty string.

Replacing this with DEB_VERSION_UPSTREAM fixes this issue and properly only 
uses the upstream version part minus the Debian epochs.

I'll get a fix pushed into Salsa and get it sponsored from there.



Thomas

Bug#1076671: RFS: uriparser/0.9.8+dfsg-2 -- documentation files for uriparser

[Thomas Ward]

Not a mentor but who's the upstream author / contact?  (It isnt filled in in 
your request)



Sent from my Galaxy



 Original message 
From: Jörg Frings-Fürst 
Date: 7/21/24 14:09 (GMT-05:00)
To: sub...@bugs.debian.org
Subject: Bug#1076671: RFS: uriparser/0.9.8+dfsg-2 -- documentation files for 
uriparser

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "uriparser":

   Package name : uriparser
   Version  : 0.9.8+dfsg-2
   Upstream contact : [fill in name and email of upstream]
   URL  : http://uriparser.sourceforge.net
   License  : LGPL-2.1+, BSD-3-clause
   Vcs  : https://git.jff.email/cgit/uriparser.git
   Section  : libs

The source builds the following binary packages:

  liburiparser1 - URI parsing library compliant with RFC 3986
  liburiparser-dev - development files for uriparser
  liburiparser-doc - documentation files for uriparser

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/uriparser/

Alternatively, you can download the package with 'dget' using this command:

 dget -x 
https://mentors.debian.net/debian/pool/main/u/uriparser/uriparser_0.9.8+dfsg-2.dsc

or from

 git 
https://git.jff.email/cgit/uriparser.git?h=release%2Fdebian%2F0.9.8%2Bdfsg-2




Changes since the last upload:

 uriparser (0.9.8+dfsg-2) unstable; urgency=medium
 .
   * debian/control:
 - Fix Vcs-Git URL.

CU
Jörg

--
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56


Jörg Frings-Fürst
D-54470 Lieser


git:  https://git.jff.email/cgit/

Skype:jff-skype@jff.email
Jami: joergfringsfuerst
Telegram: @joergfringsfuerst
Matrix:   @joergff:matrix.snct-gmbh.de

My wish list:
 - Please send me a picture from the nature at your home.

Bug#1045831:

[Thomas Ward]

Control: tags -1 + pending

This is a leftover from the change from upstream to CMake among other things.

A fix has been added to debian/clean in Salsa for 2.6.0-2 (currently 
unreleased) that will fix double-building and properly clean things.

Refer to 
https://salsa.debian.org/debian/xca/-/commit/10134fbe6e7ee7f250fe473fddc06ce438d68e25
 for the pending commit.



Thomas

Bug#1074383: Use qtbase5-dev instead of specific Qt5 SQL libraries in build-deps

[Thomas Ward]

Source: xca
Severity: minor
Control: submitter -1 tew...@ubuntu.com

It was suggested by Mattia Rizzolo that XCA may build successfully against 
qtbase5-dev instead of the specific Qt SQL library.

This is a bug that will remain open while this is investigated as to whether 
this change works or not in the packaging.  (Tests will be done offline before 
being put into Salsa or Debian directly)



Thomas

Bug#1068676: New Upstream Release, Package Problems, vcswatch issues.

[Thomas Ward]

Source: edb-debugger
Severity: normal

Hello.

The edb-debugger software is out of date. Upstream has version 1.5.0 as 
of two weeks ago. [1] The version in the repositories is from December 
13, 2020, and is SEVERELY out of date.  Note that 1.4.0 was released in 
July 2023.


Additional observations:

d/watch: Broken, needs updated to reflect updated GitHub d/watch 
requirements. [2]


d/control: OUTDATED build depends. Replace pkg-config with pkgconf. Per 
Lintian tags.  [3]



If this package needs assistance being maintained, I can assist, but for 
now I will be providing Salsa pull reqs/patches to address the d/watch 
and d/control issues, however I am not going to handle the outdated 
software problem.




Thomas Ward


[1]: https://github.com/eteran/edb-debugger/releases

[2]: https://wiki.debian.org/debian/watch#GitHub

[3]: https://udd.debian.org/lintian/?packages=edb-debugger

Bug#1067697: Update Build-Depends for the time64 library renames

[Thomas Ward]

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 behind my @ubuntu.com address)

Bug#1067697: Update Build-Depends for the time64 library renames

[Thomas Ward]

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.



Thomas

-Original Message-
From: Andrey Rakhmatullin  
Sent: Monday, March 25, 2024 14:00
To: Debian Bug Tracking System 
Subject: Bug#1067697: Update Build-Depends for the time64 library renames

Source: xca
Version: 2.5.0-1
Severity: serious

The package explicitly Build-Depends: libqt5sql5, libqt5help5, this needs to be 
changed to the new names if it's needed at all.


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: 
TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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

Bug#1053757: (no subject)

[Thomas Ward]

Harald, check and see if the latest version uploaded (2.5.0) fixes the 
issue.  Note that I have been without a signing key for a bit due to 
unforseen circumstances, so it took a bit longer to get it to land and 
tested.

Bug#1053907: RFS: xca/2.5.0-1 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal
Control: submitter -1 tew...@ubuntu.com


Dear mentors,

*Note: While I have DM status and can upload, there is a situation where 
my signing key privkey is irrecoverable, due to computer death and the 
destruction of my yubikey holding the privkey as well in a car accident. 
This is why this is being filed with a Sponsorship request until I can 
find 2 DDs willing to sign my replacement key.*



I am looking for a sponsor for my package "xca":

* Package name : xca
Version : 2.5.0-1
Upstream contact : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

The source builds the following binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/xca/

Alternatively, you can download the package with 'dget' using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.5.0-1.dsc

Changes since the last upload:

xca (2.5.0-1) unstable; urgency=medium
.
* New upstream release (2.5.0)
* Upstream now uses CMake for builds, which invalidates multiple quilt
patches.
* Dropped patches from d/patches:
- xca-240-ossl3.patch: Already included in 2.5.0
- 0001-Remove-misc-Info.plist-in-clean-target.patch: Obsolete due
to CMake move.
- 0002-pkg-config-remove-hardcoding.patch: Obsolete due to
CMake move.
* d/control: Update build dependencies because we use CMake; use XCA
upstream git home for build-dependencies list.
* d/rules: Numerous changes to adapt for CMake build environment
as changed by Upstream.

Regards,


Thomas

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Thomas Ward]

I apoligize I was thinking Lua deps not PCRE.

However, I did more digging. OpenResty has been on NGINX cofe version 1.21.4 
for the longest time.  They do not have PCRE2 support in their system.  As this 
is an OpenResty-originating module the 4th requirement as stated in the linked 
GitHub issue is not met.

I would not be so sure that "next update" will have a fix if OpenResty core 
does not support PRCE2 (1.21.5 nginx introduced PCRE2 core requirement/build 
fixes, OpenResty never inccuded that).  The reason PCRE3 is still used here in 
the Lua module is the custom workaround of mixing PCRE2 nginx and PCRE3 Lua 
which use different build flags at compile time with the linking options.

Therefore, we need to not make assumptions and watch this closely.  If there is 
not movement in a reasonable time period, then we may have to drop this module 
from Debian due to PCRE3 being obsolete.

Note also GH issue https://github.com/openresty/lua-nginx-module/issues/1984 
which has been asking for PCRE2 support for *years* now with no movement - this 
seems to be related and explains the 1.21.4 nginx lock on the OpenResty fork as 
one hurdle (a major one).


Thomas



Sent 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 2023 à 19:09, Thomas Ward 
mailto:tew...@thomas-ward.net>> a écrit :
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 PCRE3 build dependency here, but because
OpenResty has refused to change the Lua library to be any Lua support
other than 5.1, it requires LuaJIT in order to provide 'continued
support' for Lua 5.1 bytecode.

These comments have no relation with this bug report.

It is my understanding that the pcre2/pcre3 dependency may not be
needed, but I have not deep dived into the Lua packaging recently.  I'm
running a test build from the tagged data in Salsa locally to see if it
builds without the pcre2/pcre3 devel libraries in build-deps.

pcre3 is *needed* by libnginx-mod-http-lua, which doesn't support pcre2 yet.
However someone involved worked on it a few days ago:
https://github.com/openresty/lua-nginx-module/pull/2221

so hopefully the situation will resolve itself in next update.

Jérémy

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Thomas Ward]

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 PCRE3 build dependency here, but because 
OpenResty has refused to change the Lua library to be any Lua support 
other than 5.1, it requires LuaJIT in order to provide 'continued 
support' for Lua 5.1 bytecode.


It is my understanding that the pcre2/pcre3 dependency may not be 
needed, but I have not deep dived into the Lua packaging recently.  I'm 
running a test build from the tagged data in Salsa locally to see if it 
builds without the pcre2/pcre3 devel libraries in build-deps.



Thomas


On 8/21/23 12:58, Bastian Germann wrote:
Thomas, can you please explain why this package still builds when 
nginx has moved to pcre2? I do not get it.

Bug#1050186: [Pkg-nginx-maintainers] Bug#1050186: libnginx-mod-http-lua: depends on obsolete pcre3 library

[Thomas Ward]

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 that there are no 
major updates and that a MAJOR update would be needed in Open Resty 
(1.21.4 has been Open Resty's version for eons) in order for PCRE2 
support to really make it, despite nginx core moving to PCRE2.


Given this situation, and the fact this is still not being moved on 
Upstream, this may be a case where we have to decide whether to actually 
*keep* Lua module around at all, especially if we consider PCRE3 
obsolete and a security flaw.  (In which case, this should be also 
tagged as a Security bug).



Thomas



On 8/21/23 11:24, Bastian Germann wrote:

Source: libnginx-mod-http-lua
Severity: serious
Version: 1:0.10.25-1
User: matthew-pcre...@debian.org
Usertags: obsolete-pcre3

Dear maintainer,

When the pcre3 -> pcre2 mass bug was filed, this package was left out.
I am filing this (edited copy) after the fact:

Your package still depends on the old, obsolete PCRE3 libraries
(i.e. libpcre3-dev). This has been end of life for a while now, and
upstream do not intend to fix any further bugs in it. Accordingly, we
would like to remove the pcre3 libraries from Debian.

The newer PCRE2 library was first released in 2015, and has been in
Debian since stretch. Upstream's documentation for PCRE2 is available
here: https://pcre.org/current/doc/html/

Many large projects that use PCRE have made the switch now (e.g. git,
php); it does involve some work, but we are now at the stage where
PCRE3 should not be used, particularly if it might ever be exposed to
untrusted input.

This mass bug filing was discussed on debian-devel@ in
https://lists.debian.org/debian-devel/2021/11/msg00176.html

Thanks,
Bastian

___
Pkg-nginx-maintainers mailing list
pkg-nginx-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nginx-maintainers 

Bug#1032517: [Pkg-nginx-maintainers] Bug#1032517: Bug#1032517:

[Thomas Ward]

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 apache2-bin containing 
the binaries and apache2-common which has the config defaults as an 
example) and I would NOT merge both the NGINX executable provider and 
the config provider binaries together at the moment.



Thomas

On 3/13/23 10:51, Jan Mojzis wrote:

Unless we find a better solution,
then we will need to rollback the configuration back to nginx-common package.

___
Pkg-nginx-maintainers mailing list
pkg-nginx-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nginx-maintainers

Bug#796295: Happy to Help

[Thomas Ward]

I'm looking after this package a bit downstream in Ubuntu, and have 
multiple packages here in Debian that I'm DM for.


I'd be happy to comaintain the package with the team and everyone else, 
in fact I have an upload prepared for the latest torbrowser-launcher and 
would be happy to work with the team to get this done.  Especially since 
we have a critical-level bug that seems to affect all the 
torbrowser-launcher packages with "no more locales".




Thomas

Bug#1025763: [Pkg-nginx-maintainers] Bug#1025763: nginx: do nginx-extras nginx-full nginx-core nginx-light still make sense ?

[Thomas Ward]

Unless we have confirmed that these 'flavors' don't rely on non-dynamic modules 
that need compiled in at compile time I generally am in agreement.  There were 
options enabled at some flavors that are not invseparately packaged modules 
because they needed to be in the executable at compile time.

Which means we need to validate that all modules still in the flavors are 
actually compiled into plain nginx.  We also need to make sure the path of 
upgrade works still too.  (nginx-extras to just nginx and stuff)



Sent from my Galaxy



 Original message 
From: Jérémy Lal 
Date: 12/8/22 13:33 (GMT-05:00)
To: Debian Bug Tracking System 
Subject: [Pkg-nginx-maintainers] Bug#1025763: nginx: do nginx-extras nginx-full 
nginx-core nginx-light still make sense ?

Source: nginx
Version: 1.22.1-3
Severity: wishlist

With all modules being built in their own separate packages,
it would be less confusing to have just a "nginx" package,
and let users install the modules they need.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

___
Pkg-nginx-maintainers mailing list
pkg-nginx-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nginx-maintainers

Bug#1024612: (no subject)

[Thomas Ward]

Response from upstream:


The pastebinit -P option seems to now require an argument even
though the option didn't require one before...

Yes, because 1.) this allows one to both enable and disable private 
pasting via command-line option which wasn't possible before, and 2.) 
there are pastebins that offer multiple levels on private pastes.


...and the docs mention a default.

Yes, like there are defaults on other options that require an argument 
when specified on the command line. So in this case, if you just want 
to make a private paste (and the bin only got one level of privacy), 
since the default is indeed |1| now whereas before private pasting was 
disabled by default, you'd not need to pass the option at all.


Basically, you don't need to specify `-P` at all - it defaults to 
'hidden' by default and does NOT need `-P` specified unless you want to 
change the default privacy level of 1.



This could be better specified in documentation and help output, or with 
a better mechanism to handle options (currently pastebinit is using 
getopt which is considered deprecated and undeveloped, so add this to 
the devel tasks for us upstream to modify this and use argparse or 
similar to better refine options).



Thomas

Bug#1025035: pastebinit not returning proper URL for pastes going to paste.debian.net

[Thomas Ward]

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 paste.


This is a Serious issue in the package and warrants removal from Testing 
until this is dug into and resolved.



Thomas

Bug#1021393: closed by Thomas Ward ()

[Thomas Ward]

Stuart,

With my Ubuntu Core Dev hat on and Ubuntu Server Team hat on, the Ubuntu 
team decided that disabling IPv6 on a server is an administrator 
decision that is "not the defaults" and the default installation 
configuration is designed as that - the 'default' that functions in a 
standard-expected installation.  Full disabling of IPv6 was considered 
"atypical default configuration".  This was discussed at length in 
multiple bugs on this nature.


With my Debian Maintainer hat on:

I've discussed this in the #debian-devel channel on IRC, and the 
responses I have are: "IPv6 is always enabled, you should use it in the 
default config", and "if you disable ipv[46] totaly, I don't think one 
can expect the system to work without bugs."


The consensus is identical among multiple users and Debian Developers, 
as the configuration you have chosen *diverges* from the defaults and is 
a "user/admin decision" that the user/admin will have to accept 
consequences for.


As such, this echoes the Ubuntu Server Team's decision but at the Debian 
level, and we're not changing this for Bullseye or any of the other 
supported Debian releases.


You need to configure your deployment scripts to ignore the first 
package installation failure, replace your configuration entirely, and 
*then* `apt install -f` or similar in your deploy script to *replace* 
the configuration.


---

(TL;DR, The default configuration file is made to adapt to *default* 
Debian environments, and it's non-standard to disable ipv[46] entirely 
at a sysctl and similar level, so you can *expect* multiple packages to 
have bugs when these nonstandard setups are being used.  ALTERNATIVELY, 
your deployment script should install nginx first, change the 
configuration, disable IPv6, then reboot.  That's how you *should* do 
things with an autodeploy script).




Thomas Ward

Ubuntu Core Developer (https://launchpad.net/~teward)

Debian Maintainer (for nginx package among others)

On 10/7/22 14:37, Stuart Culligan wrote:


Ok I guess I should have been more clear. This is a debian package 
issue in that the debian package is linking the default site default 
-> /etc/nginx/sites-available/default Which contains 2 listen lines as 
I listed before


listen 80 default_server; listen [::]:80 default_server; After digging 
further into this I discovered it was IPv6 line that was causing the 
issue. listen [::]:80 default_server; We disable IPv6 on our servers. 
I did not run into this on Ubuntu 18.04. It appears there was a lot of 
changes to how debian packaged nginx between the 2 OS releases. With 
these changes there appears to be a lot of changes to the default. I 
suggest not trying to link the default and not attempting to do a 
restart. Just a suggestion though.


Now I am trying to find a way to get passed this issue as we build an 
entire server via debian packages. I can not have a package error out 
in my build process.


On 10/7/2022 11:45 AM, Debian Bug Tracking System wrote:

This is an automatic notification regarding your Bug report
which was filed against the nginx-common package:

#1021393: error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 
22.04 with default enabled site.

It has been closed by Thomas Ward.

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Thomas 
Ward  by
replying to this email.

Bug#1011935: QtChooser is dead by choice upstream, no Qt6 Support

[Thomas Ward]

Source: qtchooser
Severity: wishlist

It was determined from 
https://salsa.debian.org/qt-kde-team/qt/qtchooser/-/merge_requests/2 and 
a downstream Ubuntu bug on Qt6 not working that QtChooser is dead 
upstream on purpose.


If it is dead upstream on purpose and should NOT work with Qt6, could we 
add a Breaks on qt6 and higher, since it is only kept around for Qt5 
support and not breaking Qt5 applications that rely on it?  Therefore 
indicating that Qt6 is not and *will* not be supported on the 
now-dead-upstream project?


(I'm only caring because this bug ended up on the Ubuntu lists that I'm 
on and I'd rather see a hard "Nope not supporting later Qt!" in the 
packaging controls than not if there's no intention for this to support 
future Qt)



Thomas

Bug#1010938: Please update package to latest upstream versions

[Thomas Ward]

Source: mitmproxy
Severity: important

MITM Proxy version 8.0 has been available for some time now, and is not 
packaged.  Updating the package will fix the two CVE bugs that are 
present in MITM Proxy here in the packaging.


The version of MITM Proxy that is packaged was last updated in December 
2020.  There have been 6 releases since then.


(Severity: important, because of existing security vulnerabilities and 
the fact this package has not been kept up to date and should be updated 
sooner than later to address these vulnerabilities and other issues)




Thomas

Bug#1010798: nginx-common: duplicate extension "woff" in /etc/nginx/mime.types

[Thomas Ward]

Control: tags -1 + pending

This was a typo introduced in the fixing of the QA state in the 
packaging when myself and Jan were given maintainer status.


My bad!  I've got a fix pending in Salsa, but I don't think it will get 
uploaded on its own until we have other things ready to go as well 
(because it's a Minor issue).


For everyone else, the workaround is to edit /etc/nginx/mime.types and 
on the "font/woff2" line make it say 'woff2' instead.  This was a typo I 
missed the first time around, but this will fix the issue on your 
endpoint systems end.




Thomas


On Tue, 10 May 2022 10:54:15 +0200 =?UTF-8?Q?J=c3=b6rg-Volker_Peetz?= 
 wrote:

> Package: nginx-common
> Version: 1.20.2-2
> Severity: minor
> X-Debbugs-Cc: none, J-V Peetz 
>
> Dear Nginx Maintainers,
>
> currently the warning
>
> duplicate extension "woff", content type: "font/woff2", previous content
> type: "font/woff" in /etc/nginx/mime.types:29
>
> appears during start-up of nginx. It's nginx-light, actually.
> Should it be fixed?
>
> Regards,
> Jörg.
>
>

Bug#1008858: [pkg-lua-devel] Bug#1008858: Please support s390x

[Thomas Ward]

This may sound annoying or a counterintuitive argument, but have we 
considered that this has sat for years without ANY activity from LuaJIT 
upstream that they may not care to?  Could we do any kind of testing on 
our side in terms of a 'distribution-level' patch to support S390X?  
Because it does make sense that this hasn't been handled for 4+ years 
that upstream has no intention to support this.



Thomas


On Sun, 3 Apr 2022 00:49:53 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= 
 wrote:
> On Sun, Apr 3, 2022 at 12:21 AM Thomas Ward  
wrote:

>
> > Source: luajit
> > Severity: wishlist
> >
> > Please support s390x if possible. NGINX's Lua module support depends on
> > libluajit exclusively now, and would need s390x support for proper 
support.

> >
>
> There is a PR for that
> https://github.com/LuaJIT/LuaJIT/pull/395
>
> however it still requires to be tested and reviewed.

Bug#1010584: ITS: rlwrap

[Thomas Ward]

Source: rlwrap
Severity: important

Hello.

The rlwrap package has a seriously outdated version of rlwrap and 
multiple bugs open against it indicating it needs to be updated to a 
newer version of rlwrap in order to fix those.


The last activity by the sole listed maintainer, Mike Miller 
, shows that no activity has been done on the 
package since 2018 when they uploaded 0.43-1 to the repositories [1].


There has been no activity on the Salsa repository since two years ago 
(which did some packaging cleanup, rules changes, some Salsa CI changes, 
etc. back in April of 2020) and no release updates since 0.43-1.  [2]  
There were staged 0.43-2 packaging changes (debhelper changes, 
misspellings, cleanup of metadata fields, etc.) done by Janitor but 
nothing ever landed (and remains in UNRELEASED).


Upstream between 2017 and 2021 did not have any activity, however 
upstream began rereleasing versions starting with 0.44 in 2021.  [3]


Further, according to the contributions pages of the sole maintainer 
Mike Miller [4], there has been no activity since December 2020 by the 
individual.  This may not reflect all activity, but is a pretty good 
indicator there's been "limited activity" from the DD in question, so I 
have CC'd the MIA team on this as well.


I emailed the Maintainer over a week ago as well, asking if they needed 
assistance or would like me to help comaintain the package - I have not 
received any response to that inquiry.



---

According to the rules for Package Salvaging [5] [6] a package is 
eligible for salvaging based on certain criterion.


The criterion that this package meets are, in my belief, as follows:

 1. There are open bugs AND missing upstream releases of the rlwrap 
software, including bugs where there are substantially large issues that 
are acknowledged but not updated/fixed,
 2. A new package upload of a newer version of rlwrap is needed to fix 
these issues, and

 3. The following additional criterion:
    - There has been no activity regarding the package for 6 months 
other than bugs and a response from over 2 years ago on it, and
    - Bugs exist for more than one major missing upstream version in 
that 0.44 is needed to be packaged (or later) to fix the readline bugs 
that're happening and have been persistent for over 2 years.


Under these eligibility criterion, the package is eligible for salvaging.

If the original maintainer can be reached, and would prefer to simply 
add me as a co-maintainer, I would be willing to accept that.  However, 
if the original maintainer would like to relinquish management, or 
cannot be reached, I would accept taking over the package and its 
maintenance in Debian.



Thomas



[1]: https://tracker.debian.org/pkg/rlwrap
[2]: https://salsa.debian.org/debian/rlwrap/-/commits/master
[3]: https://github.com/hanslub42/rlwrap/tags
[4]: https://contributors.debian.org/contributor/mtmiller/
[5]: 
https://wiki.debian.org/PackageSalvaging#Eligibility_requirements_for_a_package
[6]: 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-a-package-is-eligible-for-package-salvaging


OpenPGP_0x5B8AD6F4C26A.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#991328: NGINX patch for CVE pending in Salsa

[Thomas Ward]

Control: tags -1 + pending

Looks like, at first glance the patchset applies properly in 1.20.2 
(3-line offset but no fuzz) as is.  I've pushed this into Salsa so it's 
pending in UNRELEASED 1.20.2-2 at the moment in Salsa.



Thomas


On 5/4/22 15:44, Salvatore Bonaccorso wrote:

Hi Thomas,

On Wed, May 04, 2022 at 07:22:22PM +, Thomas Ward wrote:

You are correct - bage@ saying this was fixed and should've been
included in changelogs in the RFS threw me off.  The fix requires
new commands and essentially 'functionality' added which is probably
why it wasn't added in upstream.  I could've sworn I included this
patch pre-upload but that might've been my fault that it didn't get
included, which is also my fault.

I can either backport this, or we can wait for the next nginx stable
release 1.22 which should be coming "sometime soon" unless F5 has
changed the development/release schedule.  In which case unmarking
this as fixed and keeping it open is going to be necessary.  I
believe we only track nginx stable (the even number releases) not
mainline, which may have led to this.

I'll prep a backported patch, if it imports cleanly.  If it doesn't,
we'll have to wait for 1.22 release of NGINX OSS.

Many thanks for your quick confirmation! I do not think it's
particularly pressing, if the fix does not apply or is not
backportable to 1.20.x then when ready moving to 1.22 is fine. Ideally
the fix is applied for bookworm.

Thanks for working on those updates!

Regards,
Salvatore

Bug#991328: closed by Thomas Ward ()

[Thomas Ward]

You are correct - bage@ saying this was fixed and should've been included in 
changelogs in the RFS threw me off.  The fix requires new commands and 
essentially 'functionality' added which is probably why it wasn't added in 
upstream.  I could've sworn I included this patch pre-upload but that might've 
been my fault that it didn't get included, which is also my fault.

I can either backport this, or we can wait for the next nginx stable release 
1.22 which should be coming "sometime soon" unless F5 has changed the 
development/release schedule.  In which case unmarking this as fixed and 
keeping it open is going to be necessary.  I believe we only track nginx stable 
(the even number releases) not mainline, which may have led to this.

I'll prep a backported patch, if it imports cleanly.  If it doesn't, we'll have 
to wait for 1.22 release of NGINX OSS.



Thomas


-Original Message-
From: Salvatore Bonaccorso  On Behalf Of 
Salvatore Bonaccorso
Sent: Wednesday, May 4, 2022 15:16
To: 991...@bugs.debian.org; Thomas Ward 
Cc: Moritz Mühlenhoff 
Subject: Re: Bug#991328 closed by Thomas Ward  ()

Control: reopen -1

Hi Thomas,

On Wed, May 04, 2022 at 04:45:03PM +, Debian Bug Tracking System wrote:
> Control: fixed -1 1.20.2-1
> 
> This is fixed in the 1.20.2 upload.  I forgot to add it to the 
> changelog before uploading to ftp-master though, whoops.  It's in the 
> process of building now in Unstable.

Are you sure about that? The commit
http://hg.nginx.org/nginx/rev/ec1071830799 does not seem to have landed in 
upstream 1.20.2 but only in 1.21.0 is implementing the mitigations?

Regards,
Salvatore

Bug#1009976: RFS: nginx/1.20.2-1 [Team] -- small, powerful, scalable web/proxy server

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nginx":

* Package name : nginx
Version : 1.20.2-1
Upstream Author : Igor Sysoev
* URL : https://nginx.org
* License : BSD-4-clause, Expat, BSD-2-clause, BSD-3-clause
* Vcs : https://salsa.debian.org/nginx-team/nginx
Section : httpd

The source builds the following binary packages:

nginx - small, powerful, scalable web/proxy server
nginx-doc - small, powerful, scalable web/proxy server - documentation
nginx-common - small, powerful, scalable web/proxy server - common files
nginx-core - nginx web/proxy server (standard version)
nginx-full - nginx web/proxy server (standard version with 3rd parties)
nginx-light - nginx web/proxy server (basic version)
nginx-extras - nginx web/proxy server (extended version)
libnginx-mod-http-geoip - GeoIP HTTP module for Nginx
libnginx-mod-http-geoip2 - GeoIP2 HTTP module for Nginx
libnginx-mod-http-image-filter - HTTP image filter module for Nginx
libnginx-mod-http-xslt-filter - XSLT Transformation module for Nginx
libnginx-mod-mail - Mail module for Nginx
libnginx-mod-stream - Stream module for Nginx
libnginx-mod-stream-geoip - GeoIP Stream module for Nginx
libnginx-mod-stream-geoip2 - GeoIP2 Stream module for Nginx
libnginx-mod-http-perl - Perl module for Nginx
libnginx-mod-http-auth-pam - PAM authentication module for Nginx
libnginx-mod-http-lua - Lua module for Nginx
libnginx-mod-http-ndk - Nginx Development Kit module
libnginx-mod-nchan - Fast, flexible pub/sub server for Nginx
libnginx-mod-http-echo - Bring echo and more shell style goodies to Nginx
libnginx-mod-http-upstream-fair - Nginx Upstream Fair Proxy Load Balancer
libnginx-mod-http-headers-more-filter - Set and clear input and output 
headers for Nginx

libnginx-mod-http-cache-purge - Purge content from Nginx caches
libnginx-mod-http-fancyindex - Fancy indexes module for the Nginx
libnginx-mod-http-uploadprogress - Upload progress system for Nginx
libnginx-mod-http-subs-filter - Substitution filter module for Nginx
libnginx-mod-http-dav-ext - WebDAV missing commands support for Nginx
libnginx-mod-rtmp - RTMP support for Nginx

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/nginx/

Alternatively, you can download the package with 'dget' using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/n/nginx/nginx_1.20.2-1.dsc


Changes since the last upload:

nginx (1.20.2-1) unstable; urgency=medium
.
* This is an NGINX Maintainer Team upload.
* Update to latest upstream Stable version (1.20.2) (Closes: #1008855)
* d/patches/Resolver-fixed-off-by-one-write-in-ngx_resolver
_copy.patch: Drop CVE-2021-23017 patch, as this is fixed in 1.20.1
and we are now using 1.20.2 which already contains the patch.
* Refreshed d/patches/0002-Make-sure-signature-stays-the-same-
in-all-nginx-buil.patch (fuzz thanks to 1.20.2)
* d/conf/mime.types: Update mime.types to more match upstream mime.types
and include upstream changes with mime.types from 1.21.x via nginx.org
mercurial repository versions.
* d/control: Remove self from Uploaders per other Debian devs, who want
that commit to be done by someone on the current uploaders/maintainers
group instead.

Regards,


Thomas

Bug#1009709: RFS: nginx/1.0-2 [RC] -- small, powerful, scalable web/proxy server

[Thomas Ward]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "nginx":

 * Package name    : nginx
   Version : 1.18.0-9
   Upstream Author : Igor Sysoev
 * URL : https://nginx.org
 * License : BSD-4-clause, Expat, BSD-2-clause, BSD-3-clause
 * Vcs : https://salsa.debian.org/nginx-team/nginx
   Section : httpd

The source builds the following binary packages:

  nginx - small, powerful, scalable web/proxy server
  nginx-doc - small, powerful, scalable web/proxy server - documentation
  nginx-common - small, powerful, scalable web/proxy server - common files
  nginx-core - nginx web/proxy server (standard version)
  nginx-full - nginx web/proxy server (standard version with 3rd parties)
  nginx-light - nginx web/proxy server (basic version)
  nginx-extras - nginx web/proxy server (extended version)
  libnginx-mod-http-geoip - GeoIP HTTP module for Nginx
  libnginx-mod-http-geoip2 - GeoIP2 HTTP module for Nginx
  libnginx-mod-http-image-filter - HTTP image filter module for Nginx
  libnginx-mod-http-xslt-filter - XSLT Transformation module for Nginx
  libnginx-mod-mail - Mail module for Nginx
  libnginx-mod-stream - Stream module for Nginx
  libnginx-mod-stream-geoip - GeoIP Stream module for Nginx
  libnginx-mod-stream-geoip2 - GeoIP2 Stream module for Nginx
  libnginx-mod-http-perl - Perl module for Nginx
  libnginx-mod-http-auth-pam - PAM authentication module for Nginx
  libnginx-mod-http-lua - Lua module for Nginx
  libnginx-mod-http-ndk - Nginx Development Kit module
  libnginx-mod-nchan - Fast, flexible pub/sub server for Nginx
  libnginx-mod-http-echo - Bring echo and more shell style goodies to Nginx
  libnginx-mod-http-upstream-fair - Nginx Upstream Fair Proxy Load Balancer
  libnginx-mod-http-headers-more-filter - Set and clear input and 
output headers for Nginx

  libnginx-mod-http-cache-purge - Purge content from Nginx caches
  libnginx-mod-http-fancyindex - Fancy indexes module for the Nginx
  libnginx-mod-http-uploadprogress - Upload progress system for Nginx
  libnginx-mod-http-subs-filter - Substitution filter module for Nginx
  libnginx-mod-http-dav-ext - WebDAV missing commands support for Nginx
  libnginx-mod-rtmp - RTMP support for Nginx

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/nginx/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nginx/nginx_1.18.0-9.dsc


While we are at it, can a sponsor or DD please push a dak command to 
ftp-master so that I can use my Debian Maintainer status to push nginx 
directly to ftp-master without needing sponsorship?



Changes since the last upload:


 nginx (1.18.0-9) unstable; urgency=medium
 .
   [ Jan Mojžíš ]
   * http-lua: Downgrade to 0.10.13 (Closes: #1008787).
   * http-lua: Backport upstream bugfix for segfault in nginx core >= 
1.15.0

 when libnginx-mod-http-lua is loaded and init_worker_by_lua* is used.
   * d/control: Add mips64el,ppc64,kfreebsd-amd64 to list of luajit 
platforms.

   * d/control: fix Homepage nginx.net -> nginx.org (Closes: #976158)
 .
   [ Thomas Ward ]
   * d/watch: Update watch syntax to match all even versions of NGINX 
releases

 rather than use a watch syntax that is static to one specific version.
 This will fix the untracked "New upstream stable versions" problem.
   * d/control: Update 'uploaders' as Thomas Ward is now a maintainer in
 the Salsa repository.


Regards,
--
  Thomas Ward

Bug#1008787: (no subject)

[Thomas Ward]

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 liblua 
libraries still being usable for that version.  Later versions of the 
Lua module at some point as indicated earlier in this bug will need 
libluajit as that is the ONLY supported way for the Lua module in nginx 
to work; this will break s390x unless LuaJIT adds s390x support.



Thomas

[1]: https://salsa.debian.org/nginx-team/nginx/-/merge_requests/16

Bug#1009313: (no subject)

[Thomas Ward]

Can I suggest that this be rejected as it has no review from the Debian 
Maintainers Team (on git or otherwise)? (I've recently been added as a 
maintainer on the Git side of this for the Salsa repo, though not an 
uploader *yet* with my DM rights, but as we manage this on Git VCS... 
this should be a merge into the existing repo.  And as long as I get no 
objections, I'm going to be working on getting 1.18.0-9 uploaded soon 
because it fixes the pending serious FTBFS bug thanks to a merged pull 
request on Salsa which I went through, tested, and approved for the 
master branch.)


There has been zero review of any such split requests, and this really 
should go via Git and merge requests and stuff.



Question to the original poster of the RFS: *why*?  NGINX packaging has 
not yet adapted to things.



And to MIA/mentors: the package is not yet 'abandoned', I'm going to get 
mentors sponsoring until a DD adds nginx to my uploads. (see my commits 
on https://salsa.debian.org/nginx-team/nginx - i'm rapidly working on an 
RC fix for the RC bug that prevents nginx from migrating to testing as 
of now, since we have a rollback of the Lua module version now in Salsa)



Thomas

Bug#1008858: Please support s390x

[Thomas Ward]

Source: luajit
Severity: wishlist

Please support s390x if possible.  NGINX's Lua module support depends on 
libluajit exclusively now, and would need s390x support for proper support.


Thomas

Bug#1008787: Deep dive discovered partial fix

[Thomas Ward]

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 LONGER use lua-nginx on any Debian release that has 
no libluajit because Upstream has changed dependencies. As such, we 
cannot package the Lua module for s390x, which makes this package still 
unsuitable for s390x as a result of nginx-extras depending on the Lua 
module.  Per upstream on that module:


> Since version |v0.10.16| of this module, the standard Lua interpreter 
(also known as "PUC-Rio Lua") is not supported anymore. [1]


This means that s390x support for NGINX will need to be dropped, or the 
Lua module will need to be dropped, or the Lua module will need 
*downgraded* to v0.10.15 which was the last version of the module to 
support liblua as a dependency.


If it is chosen to drop s390x support in nginx here, then the liblua 
dependency can be dropped entirely from build depends.  If it is chosen 
to downgrade the module to v0.10.15 then liblua will still work and the 
build dependencies will not need changed.


(Note that downstream in Ubuntu, the Lua module was dropped because of 
the problem with it later now requiring resty-core as a dependency, 
which the Ubuntu Server Team downstream no longer wishes to include just 
to get Lua working, and is pushing people who need Lua module to just 
use Open Resty.)




Thomas

[1]: https://github.com/openresty/lua-nginx-module#description

Bug#1008855: Please package newer NGINX Stable version 1.20.0

[Thomas Ward]

Source: nginx
Severity: wishlist

NGINX 1.18 was released back in 2020. This is substantially older than 
Upstream versions, which released 1.20 in April of 2021 (nearly a year ago).


Please upgrade the package version in Debian to 1.20 as soon as 
possible, and then when NGINX 1.22.0 releases this year (within the 
month!) please include that version as well in your updates.


It should never have gotten to the point that this is so neglected - 
historically the package has ALWAYS been kept up to date, hasn't had 
FTBFSes, and has always tracked the yearly Stable branch from upstream.



Thomas

Bug#1008787: NGINX FTBFS: Lua dependencies missing

[Thomas Ward]

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 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 
-DNDK_SET_VAR -I src/core -I src/event -I src/event/modules -I 
src/os/unix -I src/http/modules/perl -I 
/<>/debian/modules/http-ndk/objs -I objs/addon/ndk -I 
/<>/debian/modules/http-ndk/src -I 
/<>/debian/modules/http-ndk/objs -I objs/addon/ndk -I 
/<>/debian/modules/nchan/src -I 
/<>/debian/modules/http-lua/src/api -I /usr/include/lua5.1 
-I /<>/debian/modules/rtmp -I /usr/include/libxml2 -I objs 
-I src/http -I src/http/modules -I src/http/v2 -I 
/<>/debian/modules/http-ndk/src -I src/mail -I src/stream \

    -o objs/addon/src/ngx_http_lua_log.o \
 /<>/debian/modules/http-lua/src/ngx_http_lua_log.c
In file included from 
/<>/debian/modules/http-lua/src/ngx_http_lua_script.h:11,
 from 
/<>/debian/modules/http-lua/src/ngx_http_lua_script.c:13:
/<>/debian/modules/http-lua/src/ngx_http_lua_common.h:20:10: 
fatal error: luajit.h: No such file or directory

   20 | #include 
  |  ^~
compilation terminated.
make[3]: *** [objs/Makefile:2683: objs/addon/src/ngx_http_lua_script.o] 
Error 1

make[3]: *** Waiting for unfinished jobs
In file included from 
/<>/debian/modules/http-lua/src/ngx_http_lua_log.h:12,
 from 
/<>/debian/modules/http-lua/src/ngx_http_lua_log.c:14:
/<>/debian/modules/http-lua/src/ngx_http_lua_common.h:20:10: 
fatal error: luajit.h: No such file or directory

   20 | #include 
  |  ^~


This needs fixed ASAP or it's going to end up with NGINX removed from 
testing because the 'fixed' versions don't build.  This is why it hasn't 
migrated yet.



Thomas

Bug#1005360: RFS: xca/2.4.0-2 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca":

* Package name : xca
Version : 2.4.0-2
Upstream Author : Christian Hohnstaedt
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/xca/

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.4.0-2.dsc

Changes since the last upload:

xca (2.4.0-2) unstable; urgency=medium
.
* New patches added:
- d/patches/xca-240-ossl3.patch: Upstream OpenSSL 3.0 compatibility
patches to allow builds and compat with OpenSSL 3.0.

While I forgot to put this in the changelog, this fixes the FTBFS that 
is addressed in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001498 - these 
changes are also reverse compat with OpenSSL older versions that are 
present in Unstable and there are no FTBFS errors present there during 
this build.  It also appears to run and work fine from the tests I've 
done locally in an Unstable VM.



Regards,


Thomas Ward

Bug#1003072: RFS: xca/2.4.0-1 -- x509 Certification Authority management tool based on Qt

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca":

 * Package name: xca
   Version : 2.4.0-1
   Upstream Author : Christian Hohnstaedt 
 * URL : https://hohnstaedt.de/xca/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/xca
   Section : x11

It builds those binary packages:

  xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xca/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.4.0-1.dsc

Changes since the last upload:

 xca (2.4.0-1) unstable; urgency=medium
 .
   * New upstream release (2.4.0)
   * Additional changes:
 - Drop d/patches/0003-fix-autoheader.patch - this is already fixed
   in 2.4.0.
 - d/control: Add qttools5-dev package to build dependencies.
 - d/xca-dbgsym.lintian-overrides: Suppress a warning about ELF
   decoder in Lintian - seen in sbuild tests against Unstable.

Regards,
--
  Thomas Ward

Bug#1001552: Improper detection of tag satisfaction cases in missing-build-dependency-for-dh-addon tag

[Thomas Ward]

Package: lintian
Version: 2.111.0~bpo11+1, 2.114.0

I discovered during compilation of a (slightly) older package that still uses a 
debhelper (>= 12)
compatibility with a debian/compat file stating 12 that the tag 
missing-build-dependency-for-dh-addon
is unable to detect the fact that dh-autoreconf is needed when debhelper >= 10 
is specified in the
control file or in debian/compat.  This resulted in the erroneous errors on 
missing dh-autoreconf
in xca, where it's not needed by debhelper >= 12 with a compat file stating 12.

This does not trigger when using "debhelper-compat (= 12)" in debian/control 
without the debian/compat
file, however the tag information and description I saw was this when triggered 
on mentors.debian.org:

autoreconf => dh-autoreconf | debhelper (>= 9.20160403~) | debhelper-compat

This suggests that if in debian/control you have a "debhelper (>= 9.20160403~)" 
line (which
"debhelper (>= 12)" qualifies), OR you have debhelper-compat, that this should 
not trigger.

HOWEVER, this triggers unless debhelper-compat is present in the build-depends, 
suggesting the tag is
NOT being correctly matched during Lintian runs if multi-level compatibility or 
experimental debhelper
compatibility (hence "debian/compat" and "debhelper >= 12" being present in a 
given package) based on
what I've read in manpages.

This looks like erroneous tag detection.  Note that if you put in dh-autoreconf 
into build-deps it
triggers the as-expected useless-autoreconf-build-depends tag.

This currently triggers on the XCA package as uploaded to mentors.debian.net 
yesterday - both versions
of the package (the one with dh-autoreconf in build-deps and the verison with 
debian/compat and
"debhelper (>= 12)" in debian/control) exist to show this distinction, and both 
packages in sid sbuild
chroots reproduce this behavior.

Bug#1001498: No OpenSSL 3.0 support in XCA 2.3.0 and later

[Thomas Ward]

Source: xca

Version: 2.3.0-1

Severity: grave

Tags: ftbfs experimental upstream

XCA 2.3.0 and 2.4.0 do NOT support OpenSSL 3.0 and fails to build when 
put against the OpenSSL 3.0 libraries.  Git has 2.4.0 staged in 
UNRELEASED form for now, however there is no OpenSSL 3.0 support available.


This is an identical FTBFS downstream in Ubuntu. [1].

This has been sent upstream to XCA developers to get OpenSSL support in. [2]


Bug Meta Notes:  This bug has been tagged 'experimental' because the 
auto-openssl transition is currently only being looked at in 
Experimental, and currently FTBFS only in Experimental.  This builds 
fine in Unstable currently, including the git staged version.



[1]: https://bugs.launchpad.net/ubuntu/+source/xca/+bug/1954544

[2]: https://github.com/chris2511/xca/issues/320

Bug#1000406: nginx-common: Nginx starts before DNS is ready

[Thomas Ward]

We had similar discussions on this type of issue downstream in Ubuntu 
[1] and after extensive discussions it was suggested that if someone 
wants to use network-online.target for this they do an override in their 
SystemD.


Given that network-online.target is not well defined, it was determined 
by the Ubuntu Server Team that it made more sense to leave it alone and 
let people 'customize' their configuration that way independently.


Also, keep in mind NGINX Pitfalls such as those that *rely* on DNS - you 
cannot guarantee that DNS is going to be reliable or work at boot time 
or auto startup unless you schedule the startup until long after 
networking would be configured and online.  [2]


While I do not have direct access to control the status quo on things 
for NGINX in Debian, the justification was based on this quote from the 
definition of network targets [3]:


network-online.target is a target that actively waits until the 
network is "up", where the definition of "up" is defined by the 
network management software. ... **It is strongly recommended not to 
pull in this target too liberally: for example network server software 
should generally not pull this in (since server software generally is 
happy to accept local connections even before any routable network 
interface is up), its primary purpose is network client software that 
cannot operate without network.**


(emphasis with asterisks or bold is mine)

Given that freedesktop definitions for SystemD here say "network server 
software should generally not pull this in" and NGINX is no different 
(see pitfalls [2] as I said), I think the 'network.target' vs. 
'network-online.target' argument should remain as "If you want to verify 
it works with DNS then alter your SystemD on a per system level, rather 
than having the entire packaging system for NGINX to be rewritten for 
these cases given the SystemD guidance."



Thomas


[1]: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1666368

[2]: 
https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/#using-a-hostname-to-resolve-addresses


[3]: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

On 11/22/21 12:45, Jeremy Ouellet wrote:

Package: nginx-common
Severity: normal

Dear Maintainer,

I was messing with nginx remote proxy and found that it would crash on 
startup.
I looked into the service file and it depended on network.target. I 
changed it

to network-online.target so that it would work.

I beleive that nginx should wait for the network to be online before 
starting
as this makes it so you can use domain names in proxy_pass. I googled 
for this
issue and most people just give workarounds and I feel like the use 
cases for

using just nework.target are minimal.

-- System Information:
Debian Release: 11.1
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads)
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 nginx-common depends on:
ii debconf [debconf-2.0] 1.5.77
ii lsb-base 11.1.0

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
pn fcgiwrap 

Bug#986787: (no subject)

[Thomas Ward]

Just for awareness: the canonical upstream repository *is* the OpenResty 
lua-nginx-module repository you've linked.


However, keep in mind that there is a new dependency that the Lua module 
will need going forward for Debian - `resty-core` which pulls in a ton 
of extra OpenResty code which is necessary for the Lua module to work in 
the latest versions.


While this is a security bug, and the upstream repository is properly 
identified, you should keep in mind that any Lua module beyond version 
0.10.15 will no longer work without the lua-resty-core library, which is 
not currently packaged. Downstream in Ubuntu, we decided that having to 
pull in the resty core libraries just to use Lua module was 'too much 
additional dependencies' for Ubuntu to maintain, so we yanked it from 
Hirsute (the currently in development release that will be 21.04) going 
forward and are pointing users who still need the Lua module to use 
OpenResty's NGINX variant instead.


In order for this to be fixed, unless you nitpick the specific patch, 
you will need to pull in lua-resty-core as an additional package and 
dependency for the Lua module in order for this to work.



Thomas

Bug#921034: Depends on MaxMind GeoIP Legacy databases - superseded by GeoIP2

[Thomas Ward]

You're right, Upstream hasn't issued a response.  At least, not on that 
thread.  I reached out to NGINX directly and got a "We're not adjusting 
the GeoIP module" answer.


TO THAT END, however, downstream in Ubuntu we packaged the third party 
geoip2 module as its own independent of the core GeoIP module.


This was later absorbed at some point into the Debian packages and 
applied there, so there IS a libnginx-mod-http-geoip2 available in later 
versions of the packaging, at least in Unstable.



Thomas


On Thu, 29 Aug 2019 15:41:56 +0300 Faidon Liambotis wrote:

> On Thu, Jan 31, 2019 at 04:36:45PM -0500, Thomas Ward wrote:
> > The GeoIP module is a core module in NGINX upstream. Keeping this in
> > mind, it's just packaged here as a dynamic module.
> >
> > For reference purposes, I have forwarded this bug report to nginx
> > upstream's nginx-devel mailing list [1] for their response.
> >
> > (Note that this is just me adding information, not adding anything 
'new'
> > to this discussion, as it is ultimately up to the maintainers to 
include

> > a third party module or not here in Debian)
>
> Thanks Thomas! Looking at that thread, upstream doesn't seem to have
> issued a response.
>
> That said, Debian is already shipping third-party modules in src:nginx,
> under debian/modules. Would it perhaps be acceptable to the nginx
> maintainers to include github:leev/ngx_http_geoip2_module in the source
> package and include it as a separate binary package?
>
> Whether we should continue to ship the geoip (legacy) module is
> orthogonal in a way -- both can be shipped at the same time, although
> I'd argue that this is no longer very useful.
>
> Regards,
> Faidon
>
>

Bug#969610: RFS: xca/2.3.0-1 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca":

 * Package name    : xca
   Version : 2.3.0-1
   Upstream Author : Christian Hohnstaedt 
 * URL : https://hohnstaedt.de/xca/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/xca
   Section : x11

It builds those binary packages:

  xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/xca/

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.3.0-1.dsc

Changes since the last upload:

 xca (2.3.0-1) unstable; urgency=medium
 .
   * New upstream release (2.3.0)
   * This upload will also fix the following Debian BTS Bugs:
 - "xca: OLD LN differs warning popups at startup" (Closes: #958886)
 - "xca: New upstream version 2.3.0 available" (Closes: #960580)
   * Additional changes:
 - d/patches/0003-fix-autoheader.patch: Apply upstream (pending) fixes
   to handle issue with autoheader changes and build failures.
 - debian/control: Replace Recommends postgresql dependency to
   libqt5sql5-psql

Regards,
--
  Thomas Ward

Bug#964203: libnginx-mod-nchan distributes old/incompatible module

[Thomas Ward]

Package: libnginx-mod-nchan

Severity: serious

Version: 1.18.0-3

Copied from Downstream bug in Ubuntu on Launchpad
(https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1874831)
post-merge (where we merged from Debian into Ubuntu):

---

The libnginx-mod-nchan package which is built from the nginx source
package distributes an old nchan module. The nginx source package has
bundled nchan 1.0.8 which has known issues when running with nginx >=
1.13.10

The upstream issue documents that nginx has had some changes that break
nchan < v1.2.0
https://github.com/slact/nchan/issues/460


Suggestion, update nchan to >= v1.2.0 (best v1.2.7).

this is the error I get when using the
`nchan_publisher_upstream_request` directive:

2020/04/24 01:00:35 [error] 9#9: *6 nchan: unexpected publisher message
request body buffer location. please report this to the nchan
developers. while sending to client, client: 127.0.0.1, server: _,
request: "POST /publish?topic=one HTTP/1.1", subrequest:
"/authorize_pub", upstream: "http://127.0.0.1:5000/authorize_pub
", host: "127.0.0.1"

---

You may want to include the latest stable version of nchan in the
package.  As is, nchan is broken.

Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Thomas Ward]

Notes: rejected downstream in Ubuntu for Security concerns (BREACH, etc.)Sent 
from my Sprint Samsung Galaxy Note10+.
 Original message From: Jérémy Lal  Date: 
6/30/20  15:36  (GMT-05:00) To: Debian Bug Tracking System 
<919...@bugs.debian.org> Subject: Bug#919320: nginx-extras: Would you please 
consider replacing Gzip module with Brotli for compression? Package: 
nginx-extrasVersion: 1.18.0-3Followup-For: Bug #919320Just to 
mentionhttps://github.com/google/ngx_brotlihas been forked then merged back and 
revived.The current 1.0.0rc seems to be working.Jérémy-- System 
Information:Debian Release: bullseye/sid  APT prefers unstable  APT policy: 
(500, 'unstable'), (500, 'testing')Architecture: amd64 (x86_64)Kernel: Linux 
5.7.0-1-amd64 (SMP w/4 CPU cores)Kernel taint flags: TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULELocale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 
(charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8)Shell: /bin/sh linked to 
/usr/bin/dashInit: systemd (via /run/systemd/system)LSM: AppArmor: 
enabledVersions of packages nginx-extras depends on:ii  iproute2
   5.7.0-1ii  libc6  2.30-8ii  
libcrypt1  1:4.4.16-1pn  libnginx-mod-http-auth-pam 
    pn  libnginx-mod-http-cache-purge  pn  
libnginx-mod-http-dav-ext  ii  libnginx-mod-http-echo 
    1.18.0-a3pn  libnginx-mod-http-fancyindex   pn  
libnginx-mod-http-geoip    pn  libnginx-mod-http-geoip2   
    ii  libnginx-mod-http-headers-more-filter  1.18.0-a3pn  
libnginx-mod-http-image-filter ii  libnginx-mod-http-lua  
    1.18.0-a3pn  libnginx-mod-http-perl pn  
libnginx-mod-http-subs-filter  pn  
libnginx-mod-http-uploadprogress   pn  
libnginx-mod-http-upstream-fair    pn  libnginx-mod-http-xslt-filter  
    pn  libnginx-mod-mail  pn  
libnginx-mod-nchan pn  libnginx-mod-stream
    pn  libnginx-mod-stream-geoip  pn  
libnginx-mod-stream-geoip2 ii  libpcre3   
    2:8.39-13ii  libssl1.1  1.1.1g-1ii  
nginx-common   1.18.0-a3ii  zlib1g  
   1:1.2.11.dfsg-2nginx-extras recommends no packages.Versions of 
packages nginx-extras suggests:ii  nginx-doc  1.18.0-a3

Bug#963860: nginx-full: circular dependency hell

[Thomas Ward]

Downstream in Ubuntu where nvinx-core originated it is its own binary - not 
depended upon nginx-core.  The nginx dynamic modules are also "OR" depended - 
such that it needs one of the flavors installed not all of them.  Consider 
doing that to make the modules not have circular depends.Sent from my Sprint 
Samsung Galaxy Note10+.
 Original message From: Bill Allombert  
Date: 6/28/20  08:27  (GMT-05:00) To: sub...@bugs.debian.org Subject: 
Bug#963860: nginx-full: circular dependency hell Package: nginx-fullVersion: 
1.18.0-3Severity: importantHello Debian Nginx Maintainers,There is a circular 
dependency between nginx-full, libnginx-mod-http-auth-pam, 
libnginx-mod-http-cache-purge, libnginx-mod-http-dav-ext, 
libnginx-mod-http-echo, libnginx-mod-http-fancyindex, libnginx-mod-http-geoip, 
libnginx-mod-http-geoip2, libnginx-mod-http-headers-more-filter, 
libnginx-mod-http-image-filter, libnginx-mod-http-lua, libnginx-mod-http-ndk, 
libnginx-mod-http-perl, libnginx-mod-http-subs-filter, 
libnginx-mod-http-uploadprogress, libnginx-mod-http-upstream-fair, 
libnginx-mod-http-xslt-filter, libnginx-mod-mail, libnginx-mod-nchan, 
libnginx-mod-stream, libnginx-mod-stream-geoip, libnginx-mod-stream-geoip2, 
nginx-core, nginx-extras and nginx-light:nginx-full:Depends: 
libnginx-mod-http-auth-pam, libnginx-mod-http-dav-ext, libnginx-mod-http-echo, 
libnginx-mod-http-geoip2, libnginx-mod-http-subs-filter, 
libnginx-mod-http-upstream-fair, libnginx-mod-stream-geoip2, nginx-core (>= 
1.18.0-3), nginx-core (<< 1.18.0-3.1~)libnginx-mod-http-auth-pam  :Depends: 
nginx-core (= 1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), 
nginx-extras (= 1.18.0-3)libnginx-mod-http-cache-purge:Depends: nginx-core 
(= 1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras 
(= 1.18.0-3)libnginx-mod-http-dav-ext:Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-echo   :Depends: nginx-core (= 1.18.0-3), nginx-full 
(= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-fancyindex :Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-geoip  :Depends: nginx-core (= 1.18.0-3), nginx-full 
(= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-geoip2 :Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-headers-more-filter:Depends: nginx-core (= 
1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-image-filter   :Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-lua:Depends: libnginx-mod-http-ndk (= 1.18.0-3), 
nginx-core (= 1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), 
nginx-extras (= 1.18.0-3)libnginx-mod-http-ndk:Depends: nginx-core (= 
1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-perl   :Depends: nginx-core (= 1.18.0-3), nginx-full 
(= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-subs-filter:Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-uploadprogress :Depends: nginx-core (= 
1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-upstream-fair  :Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-http-xslt-filter:Depends: nginx-core (= 1.18.0-3), 
nginx-full (= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-mail:Depends: nginx-core (= 1.18.0-3), nginx-full 
(= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-nchan   :Depends: nginx-core (= 1.18.0-3), nginx-full 
(= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-stream  :Depends: nginx-core (= 1.18.0-3), nginx-full 
(= 1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 
1.18.0-3)libnginx-mod-stream-geoip:Depends: libnginx-mod-stream (= 
1.18.0-3), nginx-core (= 1.18.0-3), nginx-full (= 1.18.0-3), nginx-light (= 
1.18.0-3), nginx-extras (= 1.18.0-3)libnginx-mod-stream-geoip2 :Depends: 
libnginx-mod-stream (= 1.18.0-3), nginx-core (= 1.18.0-3), nginx-full (= 
1.18.0-3), nginx-light (= 1.18.0-3), nginx-extras (= 1.18.0-3)nginx-core 
:Depends: libnginx-mod-http-geoip (= 1.18.0-3), libnginx-mod-http-image-filter 
(= 1.18.0-3), libnginx-mod-http-xslt-filter (= 1.18.0-3), libnginx-mod-mail (= 
1.18.0-3), libnginx-mod-stream (= 1.18.0-3), libnginx-mod-stream-geoip (= 
1.18.0-3)nginx-extras   :Depends: libnginx-mod-http-auth-pam (= 

Bug#960580: (no subject)

[Thomas Ward]

Tags: -1 + pending

Updated in VCS, but I have other things on my radar so at the moment I
can't push an update (E:OtherObligations).

Marking this as in-progress/pending regardless for now.

Bug#958886: (no subject)

[Thomas Ward]

Upstream has incorporated a fix to this themselves. Upstream git commit
located
at:https://github.com/chris2511/xca/commit/76e3f86783b5b472c5601750d2ddca615570fffd

Will be incorporating this into the Salsa VCS packaging later today, and
will incorporate this fix into the next package release.


Thomas

Bug#958886: (no subject)

[Thomas Ward]

Looks like OpenSSL is at fault, refer to 
https://github.com/openssl/openssl/pull/10029Sent from my Sprint Samsung Galaxy 
Note10+.

Bug#958886:

[Thomas Ward]

This was subsequently fixed in OpenSSL 1.1.1e - possibly this fix needs 
included in OpenSSL in Unstable in order to fix the mismatches as this looks to 
be fully OpenSSL at fault.(Info obtained from upstream bug)
null

Bug#958886: xca: OID LN differs warning popups at startup

[Thomas Ward]

Forwarded upstream:
https://github.com/chris2511/xca/issues/191

On 4/26/20 5:36 AM, Sander van Grieken wrote:
> Package: xca
> Version: 2.2.1-1
> Severity: normal
>
> XCA shipped oids.txt mismatches against openssl defined OIDs, causing two
> popups to appear at application startup.
>
> Warnings are also output on console:
>
>0.00 Warning: OID:  "1.3.6.1.4.1.311.20.2.3" LN differs:  "Microsoft
> Universal Principal Name"   Microsoft User Principal Name
>2.02 Warning: OID:  "1.3.6.1.4.1.311.20.2.2" LN differs:  "Microsoft
> Smartcardlogin"   Microsoft Smartcard Login
>
>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (750, 'testing'), (700, 'stable'), (600, 'unstable'), (500, 
> 'testing-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.5.10+ (SMP w/12 CPU cores)
> 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=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages xca depends on:
> ii  libc6  2.30-4
> ii  libgcc-s1  10-20200418-1
> ii  libltdl7   2.4.6-14
> ii  libqt5core5a   5.12.5+dfsg-10
> ii  libqt5gui5 5.12.5+dfsg-10
> ii  libqt5sql5 5.12.5+dfsg-10
> ii  libqt5sql5-sqlite  5.12.5+dfsg-10
> ii  libqt5widgets5 5.12.5+dfsg-10
> ii  libssl1.1  1.1.1g-1
> ii  libstdc++6 10-20200418-1
>
> Versions of packages xca recommends:
> ii  libqt5sql5-mysql   5.12.5+dfsg-10
> pn  libqt5sql5-postgresql  
>
> xca suggests no packages.
>
> -- no debconf information
>
>

Bug#955191: Fwd: bubblemail

[Thomas Ward]

Hello.

This was OK'd by the original upstream developer.  ITP 947922 was
closed, and 955188 (mine) remains open.

Please consider sponsoring of the software packaging on Mentors to the
NEW queue.  Thank you!


Thomas



 Forwarded Message 
Subject:Re: bubblemail
Resent-Date:Sat, 28 Mar 2020 07:33:09 +0100
Resent-From:Bart Martens 
Resent-To:  Thomas Ward 
Date:   Sat, 28 Mar 2020 07:22:58 +0100
From:   Razer raz 
To: Bart Martens 



For sure, I'm waiting for it since a while. Thanks for your interest !

Just for the record, I work intensively on the code right now, a lot of bugs
have already been corrected with support of some testers using servers with
weird behavior. It should be ready for a new release (0.6) in a couple
of days

Regards

On Sat, 2020-03-28 at 07:12 +0100, Bart Martens wrote:
> Hello Razer raz,
>
> Is it okay for you that Thomas Ward proceeds with packaging bubblemail for
> Debian?
>
> Hello Thomas,
>
> If Razor raz answers "yes" then please close ITP 947922 and reopen ITP
> 955188.
> Otherwise, close RFS 955191 and remove your package from mentors.
>
> Cheers,
>
> Bart
>

Bug#955191: RFS: bubblemail/0.5-1 [ITP] -- Extensible mail notification service

[Thomas Ward]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "bubblemail"

 * Package name: bubblemail
   Version : 0.5-1
   Upstream Author : Razer 
 * URL : https://framagit.org/razer/bubblemail
 * License : GPL-2.0+
 * Vcs : https://git.launchpad.net/bubblemail
   Section : mail

It builds those binary packages:

  bubblemail - Extensible mail notification service

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/bubblemail

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/b/bubblemail/bubblemail_0.5-1.dsc

Changes since the last upload:

   * Initial release. (Closes: #955188)
   * original source package automatically created by stdeb 0.8.5

Comaintainer in Uploaders is CC'd on this message; they do not have upload 
rights either and any uploads from them will also go through Sponsors, however 
I'm taking lead on the Debian package.

Regards,

--
  Thomas Ward

Bug#955188: ITP: bubblemail -- An extensible mail notification service

[Thomas Ward]

Package: wnpp
Severity: wishlist
Owner: Thomas Ward 

  Package name    : bubblemail
  Version : 0.5
  Upstream Author : Razer 
  URL : https://bubblemail.free.fr/
  License : GPL-2
  Programming Lang: Python
  Description : An extensible mail notification service

Bubblemail is a D-Bus service providing a list of the new and unread user's
mail from local mailboxes, pop, imap, and gnome online accounts. It
includes a
libnotify frontend to create notifications and can be used by other
frontends
as well.

Please also include as much relevant information as possible.
For example, consider answering the following questions:
 - why is this package useful/relevant? is it a dependency for
   another package? do you use it? if there are other packages
   providing similar functionality, how does it compare?

It provides email notifications without the need to have a whole mail
application open, and it replaces `mailnag` in functionality. This is also
a logical replacement for `mailnag` due to mailnag being 'dead' upstream.

I, Thomas Ward, do not use this, but multiple others do, and this has the
support of the co-maintainer in this matter.


 - how do you plan to maintain it?

Myself and the co-maintainer (Erich Eickmeyer ) on
this package will both maintain the package.  We will also cordinate with
Mentors to get uploads put into the repository as well as needed.

Packaging will be kept in VCS on Launchpad -
https://git.launchpad.net/bubblemail - which we will specify in the VCS
field
in the package as well.  Debian packaging begins in the debian/ branch
for now.

Bug#954744: RFS: xca/2.2.1-1~bpo10+1 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca"

 * Package name: xca
   Version : 2.2.1-1~bpo10+1
   Upstream Author : Christian Hohnstaedt 
 * URL : https://hohnstaedt.de/xca/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/xca
   Section : x11

It builds those binary packages:

  xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xca

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xca/xca_2.2.1-1~bpo10+1.dsc

Changes since the last upload:

   * Rebuild for buster-backports.

This is a Backports targeted package.  This has been requested by others to me 
on Freenode IRC.


Regards,

--
  Thomas Ward

Bug#950599: RFS: xca/2.2.1-1 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca".  This is a new upstream
version release.

* Package name : xca
Version : 2.2.1-1
Upstream Author : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/xca

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.2.1-1.dsc

Changes since the last upload:

* New upstream release (2.2.1).
* d/control: Update Standards-Version to 4.5.0.
* d/patches/0001-Remove-misc-Info.plist-in-clean-target.patch: Refresh patch
* d/patches/0002-pkg-config-remove-hardcoding.patch: Refresh patch

Regards,

Bug#947777: RFS: vmfs6-tools/0.1.0-3 -- Tools to access VMFS6 filesystems

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "vmfs6-tools"

 * Package name: vmfs6-tools
   Version : 0.1.0-3
   Upstream Author : Upstream Author : Thomas Ward  and 
others
 * URL : https://salsa.debian.org/debian/vmfs6-tools
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/vmfs6-tools
   Section : otherosfs

It builds those binary packages:

  vmfs6-tools - Tools to access VMFS6 filesystems

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/vmfs6-tools

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/v/vmfs6-tools/vmfs6-tools_0.1.0-3.dsc

Changes since the last upload (we now have a VCS for the package using a 
gitbuildpackage workflow, and a 'homepage' for it now on Salsa, so only the 
packaging has been updated per requests from the #debian-devel IRC channel):

   * d/control:
 - Add Homepage and Vcs-{Browser,Git} fields, now that we're on Salsa and
   the package is using a git-buildpackage workflow.

Regards,

--
  Thomas Ward

Bug#947328: (no subject)

[Thomas Ward]

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 mark this as tags: pending, as this is now waiting on the 
rebuilds on buildd.

Bug#947485: RFS: xca/2.1.2-3 [RC]-- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca"

 * Package name: xca
   Version : 2.1.2-3
   Upstream Author : Christian Hohnstaedt 
 * URL : https://hohnstaedt.de/xca/
 * License : BSD-3-clause
 * Vcs : https://salsa.debian.org/debian/xca
   Section : x11

It builds those binary packages:

  xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/xca

Alternatively, one can download the package with dget using this command:

  dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.1.2-3.dsc

Changes since the last upload:

   * Fix FTCBFS: Export QT_SELECT. (Closes: #947481)
 Thanks to Helmut Grohne for patch.

Regards,

--
  Thomas Ward

Bug#947481: Patch Acceptance

[Thomas Ward]

Hello, and thank you for the patch!

I'm making sure this builds before uploading for sponsoring, and have 
given you credit in the changelogs.  Thanks!

Bug#947328: FTBFS Not Reproducible in multiple build test envs (sbuild, pbuilder, etc.)

[Thomas Ward]

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 against, in what environment?  (Because 
this doesn't FTBFS from anything I can tell thus far.)



Thomas

Bug#944260: lintian: Add a detection/tag for when compat is >> 10 and cdbs in build-depends

[Thomas Ward]

Possibly.  Perhaps I should go the Policy route and inquire whether we 
should consider CDBS obsolete by later versions of Debian policy...


Thanks for the response though!  :)


Thomas


On 11/6/19 6:03 PM, Chris Lamb wrote:

Hi Thomas,


Nope, all CDBS packages compat >> 10 FTBFS if using the cdbs debhelper
rulesets with a straight cdbs include in debian/rules.

… then I'm afraid I don't see any value in a Lintian check; package
maintainers will surely see this FBTFS first.


Regards,

Bug#944260: lintian: Add a detection/tag for when compat is >> 10 and cdbs in build-depends

[Thomas Ward]

Nope, all CDBS packages compat >> 10 FTBFS if using the cdbs debhelper rulesets 
with a straight cdbs include in debian/rules. Refer to the linked bug for 
details cause that affects all CDBS built packages which try and use a compat 
>> 10.

Sent from my iPhone

> On Nov 6, 2019, at 17:33, Chris Lamb  wrote:
> 
> severity 944260 wishlist
> tags 944260 + moreinfo
> thanks
> 
> Hi Thomas,
> 
>> Since Debhelper >= 10.9.2 and higher (and therefore compat >= 11), 
>> there is a known issue in CDBS (refer to bug #885407 [1]) with the use 
>> of dh_systemd_enable instead of dh_installsystemd.
> 
> So, I'm a little hesitant — we should spend our limited energy fixing
> the aforementioned bug rather than also spending our time here in
> Lintian warning about it; we will have to do the former *anyway*,
> after all.
> 
> (Does this affect all packages or only ones using systemd? I assume
> the package does not FTBFS, merely fails to work properly at runtime?)
> 
> 
> Best wishes,
> 
> -- 
>  ,''`.
> : :'  : Chris Lamb
> `. `'`  la...@debian.org  chris-lamb.co.uk
>   `-
> 

Bug#944260: lintian: Add a detection/tag for when compat is >> 10 and cdbs in build-depends

[Thomas Ward]

package: lintian

Since Debhelper >= 10.9.2 and higher (and therefore compat >= 11), there 
is a known issue in CDBS (refer to bug #885407 [1]) with the use of 
dh_systemd_enable instead of dh_installsystemd.  This has been on the 
record since 2017 with the last activity on the bug over a year ago 
without a fix for this.  As such, any packages with DH compat >> 10 will 
fail to work when CDBS is the system in use (and in the 
build-dependencies with its rules included in debian/rules).


Therefore, I propose that a Warning indicator be added to Lintian 
checking source packages, etc. for any cases where the compat level is 
defined as >> 10, and where CDBS is in the build dependencies, defining 
something similar to the following:


"The use of CDBS with compat levels higher than 10 is not permitted.  
CDBS is not compatible with Debhelper compatibility higher than 10 due 
to the deprecation of dh_systemd_enable in favor of dh_installsystemd 
and CDBS not being updated with this change (refer to Debian Bug 
#885407).  Source packages should not define cdbs as a build dependency 
if using a compat level higher than 10."


This may also require a policy decision/change in the future, but in my 
opinion for now Lintian should throw a warning (or at least an 
Informational level notice) about CDBS not working with later compat.



Thomas


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885407

Bug#944006: nginx-extras missing TLS1.3

[Thomas Ward]

Can you include the output of `nginx -V` please as well?  Part of TLS 
support is having a version of NGINX that is compiled against an OpenSSL 
in the repositories for the version of Debian you're using which 
supports TLS1.3, but that may not be the case in all releases of Debian.



Thomas


On 11/2/19 1:15 PM, Florent CARRÉ wrote:

Package: nginx-extras
Version: 1.14.2-2+deb10u1

When I modify to have exclusively TLS1.2 and TLS1.3, just TLS1.2 is available.

Steps to reproduce :
- switch to ssl_protocols TLSv1.2 TLSv1.3
- restart nginx
- curl -v --tlsv1.3 mydomain.com

I obtain :
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, protocol version (582):
* error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version

And it's available in openssl : openssl ciphers -v | grep " TLSv1\.3 "
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD

Regards

Bug#942817: Additional Data

[Thomas Ward]

Identical/Similar reports in Ubuntu:

https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1712696

https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592


Downstream, discussion on this in the Ubuntu Server Team indicated that 
removing IPv6 support entirely on a system is what we consider an edge 
case for setups, and probably not something we need to worry about on a 
larger scale because most environments aren't set up without IPv6 
support being completely disabled on the system (so you could still get 
a local v6 bind, even if it's localhost).


We haven't made any movement on this because we considered it a very 
edge-case setup and an issue with the end-user systems.  This being 
said, you can fix this *easily* by editing the default config then doing 
`apt install -f` or `apt-get install -f` to fix the environment and 
finish install/configuration.  For autodeployed systems this might be 
harder, but for the average case there's workarounds.



Thomas

Bug#697030: Unreproducible

[Thomas Ward]

tags -1 + unreproducible

I have been unable to reproduce this since 2012, that said, the original 
system this was on was a VERY low-spec VPS, in recent years I've run my 
own infrastructure so it's not really an issue anymore.


Whether this is up for closure or not is the Maintainer's decision, 
however I have not been able to replicate this in any setup since.

Bug#939624: RFS: vmfs6-tools/0.1.0-1 [ITP] -- Tools to access VMFS6 filesystems

[Thomas Ward]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "vmfs6-tools" for the ITP bug 
I opened earlier (#939600).


* Package name : vmfs6-tools
Version : 0.1.0-1
Upstream Author : Thomas Ward  and others (see ITP bug)
* URL : https://github.com/teward/vmfs6-tools
* License : GPL-2+
* Vcs : None
Section : otherosfs

It builds those binary packages:

vmfs6-tools - Tools to access VMFS6 filesystems

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/vmfs6-tools

Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/v/vmfs6-tools/vmfs6-tools_0.1.0-1.dsc


Changes since the last upload:

* Initial release. (Closes: #939600)
* Initial packaging based on packaging from vmfs-tools 0.2.5-1.

Regards,

Bug#939600: ITP: vmfs6-tools -- Tools to access VMFS6 filesystems

[Thomas Ward]

Package: wnpp
Severity: wishlist
Owner: Thomas Ward 

* Package name: vmfs6-tools
  Version : 0.1.0
  Upstream Author : Multiple (details below)
* URL : https://github.com/teward/vmfs6-tools
* License : GPL-2+
  Programming Lang: C
  Description : Tools to access VMFS6 filesystems

VMFS6 is a clustered filesystem designed to store virtual machine disks for
VMware ESX or ESXi Server hosts. This set of tools allows to access these
filesystems from some other non ESX/ESXi host for e.g. maintenance tasks.

Only read access is available at the moment, but write access is under
works. Multiple extents are supported.

The VMFS can be accessed with a command line tool or mounted through a
userspace filesystem (FUSE-based).

This version of VMFS Tools is designed to work with VMFS6, it is not
guaranteed to support VMFS5; if you need VMFS5 support, then use the
vmfs-tools package instead.

--

Multiple 'authors' have had their ways in this package.  The complete
authors list is:

- Christophe Fillot   (Original VMFS, which Mike Hommey based this
on)
- Mike Hommey   (Original vmfs-tools packager)
- Weafon Tsao  (Created the vmfs6-tools fork for
VMFS6)
- Thomas Ward  (Myself, as I made some changes to the fork
for coinstallability with vmfs-tools)

Note that as vmfs6-tools was never actually given a stable release number, I
made a release number of 0.1.0 on my own fork of Weafon's repository, which is
the basis of this packaging. That forked repository can be found on GitHub
(https://github.com/teward/vmfs6-tools).

The closest package in similarity to this one is vmfs-tools. However, the vmfs-
tools package only has VMFS support up to version 5. VMware ESXi 6 and later
use VMFS version 6 formatted file systems, which have substantial changes from
version 5. Because VMware ESXi 6 and later use vmfs6, we need to have VMFS6
compatible tools in the repository. However, while vmfs6-tools has VMFS6
support, it is not guaranteed to support vmfs5 well, which makes it infeasible
to switch to the forked package in place of vmfs-tools, which is guaranteed to
support VMFS5.

Because the fork of vmfs-tools to create vmfs6-tools by Weafon Tsao was not
designed with reverse compatibility in mind, it makes sense to package
vmfs6-tools separately alongside the vmfs-tools package to provide vmfs6
support.

This package will be maintained by me, and updated for packaging policy as
needed. However, there has been no movement at either vmfs-tools or vmfs6-tools
for some time, and therefore there may not ever be actual version bumps to the
software.

Bug#939433: RFS: xca/2.1.2-2 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca" as I do not yet have 
'unsponsored' upload privileges for this package even though I am the 
maintainer.


* Package name : xca
Version : 2.1.2-2
Upstream Author : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the 
following URL:


https://mentors.debian.net/package/xca

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.1.2-2.dsc

Changes since the last upload:

* d/patches/0002-pkg-config-remove-hardcoding.patch: Remove hard-coded
pkg-config in configure.ac, and replace it with $PKG_CONFIG references
instead.
Thanks to Helmut Grohne for the 1.4.1-1 patch, which is the basis
for this patch.
(Closes: #896891)

Regards,

Thomas

Bug#896891: (no subject)

[Thomas Ward]

Hello.

Can you verify that cross-building is still broken in the version 
available now in Unstable and Testing, as 1.4.1-1 has been superseded 
for some time now?  If it is still broken, please also update the patch, 
however keep in mind configure.ac has changed so it's possible the issue 
is now resolved.



Thomas

Bug#935462: RFS: xca/2.1.2-1 [ITS] -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca"

* Package name : xca
 Version : 2.1.2-1
 Upstream Author : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
 Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/xca

Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.1.2-1.dsc

Changes since the last upload:

* New upstream version. (Closes: #927233)
* d/watch: Update watch file to track upstream xca repository on Github.
* d/compat: Update Debhelper compatibility to latest (12)
* d/control:
- New maintainer (Closes #931806)
- Update Standards-Version to 4.4.0
- Update Homepage to proper Upstream URL
- Update Vcs-Git to point at Debian Salsa. Package now uses a
git-buildpackage (gbp) workflow.
- Add Vcs-Browser field.
- Reorganize Build-Depends to be more readable.
- Remove dh-autoreconf build depends.
- Update debhelper build depends (compat is 12, so use debhelper >= 12)
- Make requisite changes to adjust xca built by the packages to enable
Remote DB support in xca: (Closes: #928678)
- Add libqt5sql5 Build-Depends for Remote DB support.
- Add Recommends on libqt5sql5-{mysql,postgresql} to xca package.
* d/patches/0001-Remove-misc-Info.plist-in-clean-target.patch: Refresh
patch to remove fuzz.
* d/copyright: Update copyright file to be Machine-readable per
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Regards,


Thomas

Bug#931806: your mail

[Thomas Ward]

Tobias, et. al:

On 7/13/19 2:17 PM, Thomas Ward wrote:
> On 7/13/19 1:26 PM, Tobias Frost wrote:
>> Ok, seems indeed a bumpy ride, glad that you were able to fix it.
>> Said that, I can also create a repository for you e.g in the Debian
>> namspace, (I see it is in your own namespace, this is OK but a Team's or
>> the Debian namespace would be better). Let me know and I'll set you up.
>
> Would be glad if you can, then I can do a merge request directly
> against that.  And it'd make my life a little easier heh
>
After my message was sent, I was informed by Salsa afterwards at 4:18PM
my time (Eastern US, currently UTC-4) that the repository was made in
Debian's namespace for Debian/xca, and my access was provided to the
repository as Maintainer.  Thank you to the Debian teams in question for
this, as well as for providing me that access.  It definitely will
assist in moving this forward, as well as making Vcs-Git maintenance of
this much easier.

Using the provided gbp command from Tobias in the prior emails (thanks
for the command, I"m still getting the full hang of gbp, so every bit of
helpful information you can provide is appreciated), and that provided
access on Salsa, I have populated the repository with the data from the
dscs, which includes the pristine-tar and the upstream branches.  This
data, based from what I can tell on 2.0.1 in Unstable, as well as all
the tags, has been uploaded to the repository to get us a 'baseline'
from what's in Debian.  I have not made any efforts as of yet to apply
updated packaging changes, nor to address the bugs that I've identified
in Unstable need changes (including the version bumps).

Note that these changes and this repository, as well as my use of the
gbp workflow thus far, I am going to be basing the remainder of my ITS
and the packaging I will be uploading to Mentors for sponsoring to
here.  At that time, the ITS will be 'waiting' for further movement.

Only two remaining questions for this before I move forward with
updating the Salsa repository with further changes (or the preferred way
I would be doing to get a second set of eyes on the changes, a pull
request from my own namespace in for all three branches). As I am
currently not the specified maintainer for this package, and given that
I have filed this ITS:

(1) should I write the changelog entries from the perspective of an NMU
or as if I am the maintainer/co-maintainer of the repository?

(2) Should the Uploaders field be updated in the process as well to
include myself as well, or should I let that be handled at a later point
in time by the MIA team or by another DD?


Thomas



signature.asc
Description: OpenPGP digital signature

Bug#931806: your mail

[Thomas Ward]

On 7/13/19 1:26 PM, Tobias Frost wrote:
> Ok, seems indeed a bumpy ride, glad that you were able to fix it.
> Said that, I can also create a repository for you e.g in the Debian
> namspace, (I see it is in your own namespace, this is OK but a Team's or
> the Debian namespace would be better). Let me know and I'll set you up.


Would be glad if you can, then I can do a merge request directly against
that.  And it'd make my life a little easier heh.


>> Finally, note that I am not a DM or a DD yet - I do not have direct
>> upload rights to Debian, and on Salsa I am only a 'guest' user at the
>> moment.
> It's not only, you can use salsa as everyone else, with the caveat that
> you might have not all those permissions a project member (aka Debian
> Developer, DD for short) has, but if you're lacking something you can
> always ask a DD for what can be done…
> (The suffix "-guest" is to avoid name-clashes with for project members,
> see https://wiki.debian.org/Salsa/Doc)


As soon as I get the repo locally I'll poke it more.  Thanks for the
help.  This said, if you create the repository in Debian's namespace
first, that'd be even better.  Then I can make the MR and poke Mentors
or Sponsors for that.


> Once you're ready, please feel free to ping me, I might review your
> package! (I'll likely do, but I cant promise right now due to time
> constraints)

Thanks for the offer.  If we start with the repo on Salsa in Debian's
namespace first, I can merge request against that and then bug people to
sponsor it, and adjust the packaging accordingly for that repository. 
(Though it'd end up forked for the pull request).

I've already got a few DDs who may be willing to look at it, but as
normal with Mentors I'll make the sponsor request as normal, and if my
friendly DDs don't assist, I'll ask you for some review if you have
time, unless some other person on Mentors beats you to the punch.


>>> (Appologizes if I tell you something you know already: gitbuildpacakge
>>> has an import feature for all previous Debian versions from snapshot.d.o
>>> .. If you make a git repo, would be nice if you could include all
>>> previpous versions)
>> This is where some help would be nice - I'm still learning gbp as it
>> isn't part of my USUAL downstream process in Ubuntu for the packages I
>> work with (nginx primarily, with countless drive-by fixes and uploads
>> I've done in other packages).  Is this automatic, or is this a flag in
>> gbp that I have to provide to gbp?
>   gbp import-dscs --debsnap --pristine-tar xca 
>
> There is no need to base your complete workflow on gbp, there are
> alternatives as well or you can use partly gbp and do the rest manaully
> … For alternatives: eg. dgit; however I'm not fluent in dgit)

gbp works fine!  I prefer that, actually.  Makes things kinder :P



Thomas




signature.asc
Description: OpenPGP digital signature

Bug#931806: your mail

[Thomas Ward]

Tobias,

Thanks for the response by the way - I appreciate more than just me
taking a look at this, and I definitely appreciate everyone being
willing to read

On 7/13/19 7:41 AM, Tobias Frost wrote:
> Hi Thomas,
>
> thanks for this ITS!
>
> On Wed, Jul 10, 2019 at 12:37:30PM -0400, Thomas Ward wrote:
>> Also note that because of the package being out of date, and no response
>> from maintainer yet, downstream in Ubuntu the packages have diverged so
>> that this can be updated downstream from Debian.  This is visible at
>> https://launchpad.net/ubuntu/+source/xca/2.1.2-0ubuntu1 if you wish to
>> see the package properly.
Just as an FYI, https://launchpad.net/ubuntu/+source/xca/2.1.2-0ubuntu2
was recently uploaded to Ubuntu, and move the PostgreSQL and MySQL bits
over to a Recommends instead of a full dependency (though the sqlite
bits are still a requisite for it to 'just function normally' for local
operation).  This was in recommendation from another MOTU downstream. 
(But has no impact on the fact we are diverged downstream until we come
up with a solution here in Debian for this package).
>> NOTE: there is no 'source' package Vcs store anymore that can be
>> publicly used, so this package drops the Vcs-Git line in control. 
>> Eventually I'd like to include this in Salsa, but that's not yet doable.
> Yes, it is unfortunate that the repo is gone…
> Can you elaborate why salsa is not doable? Can we help?

Help would definitely be nice, the main reason I said 'salsa is not
doable' is because I'm still figuring out some quirks of
git-buildpackage (gbp from hereon out in this email).  But I think I
figured out the headache I was running into here regarding Salsa.

The Salsa specific headaches I was running into was because of a
combination of problems, actually. Firstly, I was trying to create a
local Git repo on a system that was APPARENTLY set up to use Linux home
dirs on a Samba share that was being stupid.  This was at work.

Secondly, my Internet decided to consider Salsa unreachable for some
reason on my residential class network.

Thirdly, when I used the business static connection I have at my home,
IDS triggered.  Which is annoying.  Finally can get to Salsa's "Create
Repository" function now.

Finally, note that I am not a DM or a DD yet - I do not have direct
upload rights to Debian, and on Salsa I am only a 'guest' user at the
moment.

Also note that downstream from Debian, in Ubuntu, I have Core Developer
rights, which give me full upload to all pockets (Main, Universe,
Multiverse, etc.) in Ubuntu, if this gives any impact on whether my keys
need to be included in Debian's keyrings or not or whether this can be
utilized as a mechanism to assist me in getting a standard developer
account on Salsa rather than the guest account I am currently using,
that'd be great.

> (Appologizes if I tell you something you know already: gitbuildpacakge
> has an import feature for all previous Debian versions from snapshot.d.o
> .. If you make a git repo, would be nice if you could include all
> previpous versions)

This is where some help would be nice - I'm still learning gbp as it
isn't part of my USUAL downstream process in Ubuntu for the packages I
work with (nginx primarily, with countless drive-by fixes and uploads
I've done in other packages).  Is this automatic, or is this a flag in
gbp that I have to provide to gbp?

> --
> tobi

Bug#931806: (no subject)

[Thomas Ward]

Also note that because of the package being out of date, and no response
from maintainer yet, downstream in Ubuntu the packages have diverged so
that this can be updated downstream from Debian.  This is visible at
https://launchpad.net/ubuntu/+source/xca/2.1.2-0ubuntu1 if you wish to
see the package properly.


NOTE: there is no 'source' package Vcs store anymore that can be
publicly used, so this package drops the Vcs-Git line in control. 
Eventually I'd like to include this in Salsa, but that's not yet doable.


Thomas

Bug#931806: ITS: xca

[Thomas Ward]

Source: xca

Severity: important

X-Debbugs-CC: m...@qa.debian.org

The xca source package has not been updated in some time, and more
recent bugs have NOT received a reply from the maintainer on the BTS nor
any activity on the maintainer's behalf.  This is evidenced by the
following items to be used as justification:

---

=== BUG HANDLING ===

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863412 - as stated in
here, RFC 5280 is not precise about UTF8 or PRINTABLESTRING and
therefore the statement of "sorry for the noise" by the bug submitter
suggests that this is no longer an issue - this should've been closed by
maintainer, back in 2017.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928678 - my bug from
May indicating two additional packages needing added to enable Remote DB
support has received no reply from the Maintainer, though via direct
email they indicated "I will reply to your bug" and never did.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927233 - also my bug
but back in April, regardless of Debian being in freeze, the maintainer
never acknowledged this bug.  Nor has there been any movement on the
package since November of 2018 generally.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896891 from April 2018
received no responses or acknowledgement from the Maintainer.  It also
contains a patch which was never acted on to fix a
cross-build-from-source problem which resulted in an FTBFS due to
hardcoded pkg-config in configure.ac.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815548 from 2016 never
received a response either from the maintainer, and Maintainer was
'active' during that time.  This also includes a *patch* for the old
version with this problem and that was NEVER addressed.


=== Upstream Versions Not Uploaded in Debian ===

The last actual upload of XCA to the Debian repositories of Unstable was
done in July of 2018.  It then migrated two weeks later to Testing,
however there was later an upstream release in November of 2018 that was
never updated to.


=== Packaging Problems Unresolved ===

As shown in packages.qa.debian.org and tracker.debian.org, vcswatch
can't reach the 'git' repository in use by Tino.  This 404s perpetually
and suggests that Tino is not updating the packaging to reflect changes
in their Git repository functionalities.

DUCK confirms this, that Vcs-Git is bad and the repository is
nonexistent.  This has been failing since at least June.  This package
may also be a prime candidate to be included in Salsa as well.

Further, this VCS repository is NOT the proper Upstream VCS repository -
Upstream has a VCS repository on GitHub that should be used here:
https://github.com/chris2511/xca/

The package as-is is also using an out of date Homepage entry.  XCA
upstream has indicated that https://hohnstaedt.de/xca/ is the proper
Home Page now.


=== Minimal or No Response to Inquiries ===

A couple of months ago, I reached out to the MIA team and Tino.  From my
initial inqurity on May 8, 2019, it took a *second* email that was CC'd
to the MIA team to get Tino to reply to me on May 20th, when they
promised to address the bugs I indicated.  It is now July 10th, almost 2
months later, without any acknowledgement on bugs, nor any follow-up
contacts.

---

Given this list of problems identified in the xca source package AND the
nonresponsiveness of Tino in this matter, I would like to propose that
this package is in need of Salvaging, and would like to take over
maintainership of this package, or if Tino still desires to maintain
this package, to become co-maintainer of this package if possible. (I
have included the MIA team in the CC because I believe Tino is not
active enough to continue maintainership of this package)

Please note that downstream in a PPA I have also updated the XCA
packaging [1] and source from upstream and it works without issues, if
you need evidence that I am alive, active, and indeed can maintain the
package myself.

My keys are not yet in Debian's keyrings; therefore I would be having
any uploads I utilize sponsored initially.  If necessary, I can find a
sponsor for this.  I can also get this NMU'd and sponsored if needed,
containing the newer upstream revisions and also the proper packaging
changes to make this package 'clean' and to address some of the other
warnings.

(NOTE: This email has been SIGNED with my Public PGP Key ending in
C26A and that can be obtained from the SKS Key Servers shortly as it
has just been uploaded to the keyservers, or from the Ubuntu Key Server
[2].)


Thomas Ward


[1]: https://launchpad.net/~teward/+archive/ubuntu/xca

[2]:
https://keyserver.ubuntu.com/pks/lookup?fingerprint=on=index=0x5792F66164D057EFC6D06FAF5B8AD6F4C26A




signature.asc
Description: OpenPGP digital signature

Bug#928678: Enable Remote DB Support

[Thomas Ward]

Source: xca
Severity: wishlist

Hello.

The default package as-is does not allow for the use of Remote DB for
the Certificates storage.  This means we only can use XCA Database 'flat
files'.

This differs from the Windows and Mac executables built upstream which
include that support.

This can be solved by adding the following runtime dependencies on the
xca package:

libqt5sql5-mysql, libqt5sql5-psql


Please add these packages to the runtime dependencies for the built XCA
binaries.


Thomas

Bug#927233: XCA: Outdated, please provide newer XCA

[Thomas Ward]

Source: xca
Severity: wishlist

Hello.

The XCA package in the Repository is a little bit out of date, as we are
on 2.1.2 which was released in November 2018.

Can you please update the packages to 2.1.2 from upstream?


Thomas

Bug#921020: RFS: python-imaplibext/0.7.6-1 [ITP]

[Thomas Ward]

To all whom it concerns:

Following Dmitry's notes about source package name being incorrect, I
have uploaded a renamed source-package to Mentors.

You can download the package with dget and this command (with -ux
because you don't have my keys):

dget -ux
https://mentors.debian.net/debian/pool/main/p/python-imaplibext/python-imaplibext_0.7.6-1.dsc

The ITP bug title I had attempted to set was too long it seems for a
command to control@ but the source package name in the ITP title has
been updated. The RFS has been retitled accordingly as well. (this was
suggested in #debian-mentors via IRC)

Bug#921020: RFS: imaplibext/0.7.6-1 [ITP]

[Thomas Ward]

Hello.

On 2/1/19 9:27 AM, Dmitry Bogatov wrote:
> [2019-01-31 12:49] Thomas Ward 
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "imaplibext"
>>
>>  * Package name: imaplibext
>>Version : 0.7.6-1
>>Upstream Author : Thomas Ward 
>>  * URL : https://gitlab.com/teward/imaplibext
>>  * License : AGPL-3+
>>Section : python
>>
>> It builds those binary packages:
>>
>>   python3-imaplibext - imaplib extension library for UID-based commands (Pyth
>> on 3)
> Shouldn't source package name be python-imaplibext?

Ahh, see that's not documented anywhere in the packaging manuals
reliably.  However, you are probably right.  I can reupload to mentors
accordingly, and then put an update to this RFS and the ITP, if you wish.

>
>> Alternatively, one can download the package with dget using this command:
>>
>>   dget -x https://mentors.debian.net/debian/pool/main/i/imaplibext/imaplibext
>> _0.7.6-1.dsc
> There seems some reproducible source of confusion. I do not have your
> (or any other sponsoree) key. Write `dget -ux', please.

That part's straight from the template on mentors' site and its RFS
template.  If that template is wrong, it probably needs adjusted there. 
But I will adjust it accordingly, and I"ll update the RFS accordingly.


Thomas

Bug#921034: Depends on MaxMind GeoIP Legacy databases - superseded by GeoIP2

[Thomas Ward]

Hi.

The GeoIP module is a core module in NGINX upstream.  Keeping this in
mind, it's just packaged here as a dynamic module.

For reference purposes, I have forwarded this bug report to nginx
upstream's nginx-devel mailing list [1] for their response.

(Note that this is just me adding information, not adding anything 'new'
to this discussion, as it is ultimately up to the maintainers to include
a third party module or not here in Debian)


Thomas

[1]: http://mailman.nginx.org/pipermail/nginx-devel/2019-January/011852.html

Bug#921020: RFS: imaplibext/0.7.6-1 [ITP]

[Thomas Ward]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "imaplibext"

 * Package name: imaplibext
   Version : 0.7.6-1
   Upstream Author : Thomas Ward 
 * URL : https://gitlab.com/teward/imaplibext
 * License : AGPL-3+
   Section : python

It builds those binary packages:

  python3-imaplibext - imaplib extension library for UID-based commands (Python 
3)

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/imaplibext


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/i/imaplibext/imaplibext_0.7.6-1.dsc

More information about imaplibext can be obtained from 
https://gitlab.com/teward/imaplibext.

This is a new package, so there is no prior changelog entry.  The latest 
changes to the package in PyPI were done to fix a few stragglers in the source 
package regarding caches files that needed purged.



Thomas Ward

Bug#920952: ITP: imaplibext -- Python imaplib extension library providing UID-based commands

[Thomas Ward]

Package: wnpp
Severity: wishlist

* Package name    : imaplibext
  Version : 0.7.6
  Upstream Author : Thomas Ward 
* URL : https://gitlab.com/teward/imaplibext
* License : AGPL-3+
  Programming Lang: Python
  Description : Python imaplib extension library providing UID-based
commands

imaplibext is a Python library compatible with Python 2 and Python 3 which
extends the existing imaplib library to provide commands which utilize UID-
based commands instead of the way the imaplib currently does commands. This
allows for better interaction with individual messages, including when
manipulating flags, etc. in a way that won't affect other messages.

A long time ago, I started working on a ListServ product internally with a
company and we couldn't manipulate messages to mark them as unread easily
because we were not using UID-based commands.  This led to some
StackOverflow
questions on best approach to fixing this, which was to make all calls
via UID
calls (imaplib.IMAP4(...).uid(...)). These UID commands ended up being
lengthy
when directly called, and I realized this was going to cause problems, so I
created imaplibext as a wrapper around imaplib to utilize all commands
as UID
command calls instead of the command calls as they were in pure imaplib.
This
permitted easier modifications to email messages and to make sure that the
message we're working with was actually the message we were manipulating.

I personally use this in all my Python projects which relate to using IMAP
email, and this is in use in several projects at the workplace by several
developers. There are more and more projects created as well that are
Python 3
in origin which are using this at work, including on several private
listserv
deployments I have with customized ListServ software; this software utilizes
imaplibext, and if it was possible to have this included in Debian it'd make
things a lot easier and have one less thing that has to be pulled in through
PyPI.

Currently, the only way to get this functionality is with imaplib's
uid() calls
to an IMAP connection.  This can get very lengthy when you have to rewrite
commands to be properly interact with UID commands.  This library
overrides the
in-built IMAP commands to utilize UID calls and behaves identically to
the in-
built imaplib commands that it overrides.

I plan to maintain this myself, as I actively support the library in PyPI
itself as well as in its git repository, and I use it regularly and can fix
bugs on it regularly.  I am also active regularly downstream in Ubuntu, and
because of my levels of activity there, I have no intention of
"disappearing"
or going away and orphaning the package.  I am also regularly reachable via
Email and IRC, and can actively commit to keeping this package updated and
maintained.

Bug#919254: (no subject)

[Thomas Ward]

Just as an FYI, Upstream responded to an email I sent to them indicating
they are aware of this bug and have a fix in the works to be included in
a future version of chkrootkit.

There is no timeline on that from them, however; but we can indicate
that this has been forwarded upstream for them to do a more permanent fix.


Thomas

Bug#919805: ruby-mail is "too new" for this

[Thomas Ward]

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 this information for the purposes of making sure this bit
is known here)

Bug#920214: httpie: out of date, please update to 1.0.2

[Thomas Ward]

Package: httpie
Severity: wishlist

Dear Maintainer,

httpie is significantly out of date.  The version in Debian at present -
0.9.8-2 - was last updated in 2017.  Since then, there have been four
newer versions of HTTPie, the latest being 1.0.2.  This includes major
changes from HTTPie 1.0.0 which includes true/false values, style
values, default headers being incorrectly case-sensitive, TLS 1.3
support, etc.

As such, it would be beneficial to have httpie updated to 1.0.2 in Debian.


Thomas

Bug#919320: nginx-extras: Would you please consider replacing Gzip module with Brotli for compression?

[Thomas Ward]

FYI if I remember right BREACH is a risk in Brotli as well.

Also Brotli has a few code level concerns that the Ubuntu Security Team saw
in a cursory review that could lead to crashes which made it judged 'not
suitable for inclusion'.

Just wanted to share this info.

On Mon, Jan 14, 2019, 17:46 Abigaile Johannesburg  Package: nginx-extras
> Version: 1.14.2-2
> Severity: wishlist
>
>
> Hello nginx maintainers,
>
> At the moment, nginx-extra package includes gzip module as one of the
> optional http modules. However it seems Gzip compression is vulnerable to
> BREACH [1] attack and the vulnerability researchers' recommendation is to
> disable Gzip compression. There are also discussions on stackexchange [2].
>
> Instead of disabling compression over TLS/SSL completely, Google seems to
> be using a different compression scheme Brotli [3]. Would you consider
> replacing nginx Gzip module with Brotli?
>
> Thanks,
> Abi,
>
> ---
> [1] http://breachattack.com/#mitigations
> [2]
> https://security.stackexchange.com/questions/65625/current-state-of-breach-gzip-ssl-attack
> [3] https://github.com/google/ngx_brotli
>

Bug#915499: nginx: ship a snippet for strong SSL options

[Thomas Ward]

 If we intend to go down this route, then we need to actually ship *two*
snippets - to use Mozilla's TLS guide phrasing, one for 'modern', and one
for 'intermediate'.  The number of 'legacy' devices still out there
requires that we not just go for the strongest options by default.

This being said... this would require regular updates as ciphers and
standards change.  Which means frequently updating the snippet.

On Fri, Dec 28, 2018, 08:14 Sampo Sorsa  Hello,
>
> No deeper research on my part. I just noticed the mailman3 snippet, and
> figured it's probably not a good idea to ship different SSL harderning
> snippets in various packages. Maintainers of apache2/nginx are probably in
> the best position to determine SSL options that are compatible with Debian,
> and maintaining their relevancy.
>
> --
> Sampo Sorsa
>
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, December 4, 2018 9:55 PM, Thomas Ward 
> wrote:
>
> I should point out that "strong" options are typically only for the most
> modern grades of interactivity of SSL compatibility.  Therefore
> Cipherli.st's recommendations are not altogether the most same approach to
> this even if it's a non-default config snippet.
>
> Permit me to ask this, but what basis is being used by you to determine
> "strong" options here?  Purely cipherli.st or other sources of research
> as well to support the "strong" definition in this case?
>
>
> Thomas
>
> On Tue, Dec 4, 2018, 01:42 Sampo Sorsa 
>> Source: nginx
>> Severity: wishlist
>>
>> nginx could ship with /etc/nginx/snippets/ssl-strong.conf that contains
>> strong SSL options that can be included easily.
>>
>> Currently at least mailman3 ships with /etc/mailman3/nginx.conf
>> containing SSL options. It would be a good idea to provide these in one
>> place and just include in other packages.
>>
>>
>> Perhaps consider relevant parts of https://cipherli.st/
>>
>>
>

Bug#915499: nginx: ship a snippet for strong SSL options

[Thomas Ward]

I should point out that "strong" options are typically only for the most
modern grades of interactivity of SSL compatibility.  Therefore
Cipherli.st's recommendations are not altogether the most same approach to
this even if it's a non-default config snippet.

Permit me to ask this, but what basis is being used by you to determine
"strong" options here?  Purely cipherli.st or other sources of research as
well to support the "strong" definition in this case?


Thomas

On Tue, Dec 4, 2018, 01:42 Sampo Sorsa  Source: nginx
> Severity: wishlist
>
> nginx could ship with /etc/nginx/snippets/ssl-strong.conf that contains
> strong SSL options that can be included easily.
>
> Currently at least mailman3 ships with /etc/mailman3/nginx.conf containing
> SSL options. It would be a good idea to provide these in one place and just
> include in other packages.
>
>
> Perhaps consider relevant parts of https://cipherli.st/
>
>

Bug#900068: searx cannot run in uWSGI; CI fails as well

[Thomas Ward]

Package: searx
Version: 0.14.0+dfsg1-2
Severity: important

During testing of observed downstream autopkgtest failures in Ubuntu,
the `searx` package fails to run under uWSGI, which its upstream
documentation says to utilize.  The crash error is absorbed by uWSGI and
processed as a segmentation fault in uWSGI.

While `searx` can be run directly, it complains saying you should run
production deployments of searx via WSGI.  When attempting to run it in
uWSGI (which the CI tests and downstream autopkgtests do), it causes a
segmentation fault in uWSGI during CI tests, and a continual "Failed to
load application" loop in uWSGI when uwsgi is run directly by superuser.

Looking at the Debian CI logs, this has been failing since April 29th. 
This was noticed downstream due to the failures in the autopkgtests
blocking uwsgi and nginx from migrating (because the CI test for searx
uses nginx).

Please either fix the autopkgtests and uwsgi integration, or try
switching your tests to an Apache-based WSGI-module execution to avoid
package failures.


Thomas

Bug#897926: Enable --with-compat configure argument

[Thomas Ward]

Source: nginx
Severity: wishlist

I have received multiple requests in downstream PPAs and repositories to
enable the `--with-compat` configuration option.

This would allow for users to build additional dynamic modules with
binary module compatibility.

It was stated in an October 12, 2016 email on the nginx mailing
list/forums by Maxim Dounin that from a package maintenance point of
view, it would be a good idea to add this option to NGINX builds.

I don't see this being done in the current rules.  Would it be possible
to add --with-compat to the debian/rules file for future package versions?

Bug#856530: fPIE not enabled for Jessie Backports

[Thomas Ward]

Source: nginx
Severity: wishlist
Version: 1.10.3-1~bpo8+1

As part of a discussion with the NGINX maintainers on IRC chat in the
#debian-nginx channel on OFTC, we established fPIE/fPIC is enabled
proper in Debian Unstable and Debian Experimental.  We also established
there were build issues when trying to get the packages to build for
Jessie backports.  Coincidentally, the same fix that I introduced
downstream in Ubuntu back in 2014, and again as part of merging from
Debian to Ubuntu for the Ubuntu 17.04 cycle with a few changes, seem to
address the build issues for Jessie Backports, and the changes to the
packaging to fix the build problems observed by me are now part of the
packaging in Experimental as well [1], in an effort to reduce the merge
delta in the future.  These changes were necessary downstream to get
fPIE part of hardening flags enabled and working with the binaries and
libraries.

All this said, backporting of the packaging from Stretch to Jessie
introduced a build failure [2] when trying to use PIE hardening flags.
Upon further investigation of the core issue myself, it seems to be an
issue similar to the toolchain problems I've observed downstream in
Ubuntu.  Inclusion of the original diff which was put into Experimental
[1] will fix the build issues and produce usable binaries and builds, as
seen in build logs from a second build run for backports which included
these changes to the flags [3].

As the backport to Jessie Backports is disabling fPIE, I'd like to
request that the original diff submitted to Experimental my Michael
Lustfield to address this issue from a downstream perspective be
introduced at least for Jessie Backports, in order to resolve the build
failures that have been observed with a 'pure from stretch' packaging set.

(NOTE: *.dark-net.io is owned by me, I needed a place to dump my build
logs and data, so I thought I'd leverage my datanet.dark-net.io space on
my servers to hold the data)


--
Thomas


[1]:
https://anonscm.debian.org/cgit/pkg-nginx/nginx.git/commit/?id=f4307ddb1478c4ed9717c7a954f7192541d1cf95

[2]:
https://datanet.dark-net.io/nginx-debian/stretch-pure_jessie/nginx_1.10.3-1~bpo8%2B0%2Btest0_amd64-20170228-1520.build

[3]:
https://datanet.dark-net.io/nginx-debian/jessie-backports_teward/nginx_1.10.3-1~bpo8%2B1%2Btest0_amd64-20170228-1520.build

Bug#842276: nginx-common.config dpkg --compare-versions will mishandle return codes should the check fail

[Thomas Ward]

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_symlinks_check() {
# Skip new installations
[ -z "$1" ] && return

# Skip unaffected installations
dpkg --compare-versions "$1" lt-nl "1.6.2-5+deb8u3" || return

# Check for unsecure symlinks
linked_logfiles="` find "$logdir" -type l -user www-data -name
'*.log' `"

# Skip if nothing is found
[ -z "$linked_logfiles" ] && return

db_subst nginx/log-symlinks logfiles $linked_logfiles
db_input high nginx/log-symlinks || true
db_go || true
}


This line will break all future version upgrades:

dpkg --compare-versions "$1" lt-nl "1.6.2-5+deb8u3" || return



What happens here is, say that the package is updated, and we have
+deb8u4 then.  Let's examine the error code we get from this:

teward@debian:~$ dpkg --compare-versions 1.6.2-5+deb8u4 lt-nl
1.6.2-5+deb8u3; echo $?
1


This error code is caught by `dpkg` and will ultimately die off with a
failure code, like this (NOTE: +deb8u4 was a 'fake' package created by
me from the nginx source code that has no changes between +deb8u3, it
was just used to test the version bump issue):

teward@debian:~$ sudo dpkg -i ./nginx-common_1.6.2-5+deb8u4_all.deb
(Reading database ... 29849 files and directories currently installed.)
Preparing to unpack .../nginx-common_1.6.2-5+deb8u4_all.deb ...
Unpacking nginx-common (1.6.2-5+deb8u4) over (1.6.2-5+deb8u3) ...
Setting up nginx-common (1.6.2-5+deb8u4) ...
dpkg: error processing package nginx-common (--install):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (215-17+deb8u5) ...
Processing triggers for man-db (2.7.0.2-5) ...
Errors were encountered while processing:
 nginx-common


This prevents clean package updates.

The fix implemented downstream, considered a Security Regression update
in Ubuntu, was to change the line referenced above to the following:

dpkg --compare-versions "$1" lt-nl "1.6.2-5+deb8u3" || return 0


This will force an "OK" status code when the version check fails, and
permit updating.


Please update this ASAP, *long before* we have to deal with this as a
core problem in the package.



--
Thomas

Bug#834747: nginx-extras: Feature request: Add 3rd party module graphite-nginx-module.

[Thomas Ward (Dark-Net)]

Please note that there is currently a "Won't Fix" for "No New Modules
or Flavors", which may still apply here.  This is bug #790623
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790623)

--
Thomas

On Thu, Aug 18, 2016 at 10:39 AM, Roman V. Nikolaev  wrote:
> Package: nginx-extras
> Version: 1.10.1-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Please add new module to nginx-extras:
> graphite-nginx-module - an nginx module for collecting location stats into 
> Graphite.
>
> Url: https://github.com/mailru/graphite-nginx-module
> License: BSD
> Depends: lua-nginx-module
>
> -- System Information:
> Debian Release: 8.4
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'testing-updates'), (500, 
> 'testing-proposed-updates'), (500, 'stable-updates'), (500, 
> 'proposed-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), 
> (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages nginx-extras depends on:
> ii  libc6   2.23-2
> ii  libexpat1   2.1.0-6+deb8u2
> ii  libgd3  2.2.1-1
> ii  libgeoip1   1.6.2-4
> ii  liblua5.1-0 5.1.5-7.1
> ii  libpam0g1.1.8-3.1+deb8u1+b1
> ii  libpcre32:8.35-3.3+deb8u4
> pn  libperl5.18 
> ii  libssl1.0.0 1.0.1k-3+deb8u5
> ii  libxml2 2.9.3+dfsg1-1
> ii  libxslt1.1  1.1.28-2+b2
> ii  nginx-common1.6.2-5+deb8u2
> ii  perl5.20.2-3+deb8u5
> pn  perlapi-5.18.1  
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> nginx-extras recommends no packages.
>
> Versions of packages nginx-extras suggests:
> pn  nginx-doc  
>

Bug#826475: pymssql fetch functions return nothing, traces back to freetdx and 1.0.x incompatibility

[Thomas Ward]

Package: python-pymssql
Version: 1.0.2+dfsg-1
Severity: important
Tags: fixed-upstream

It has been observed by myself and others that pymssql version 1.0.2 has
some type of incompatibility with freetdx 0.91, such that in 1.0.x of
pymssql when you attempt to fetchone() from a cursor after query
execution, you get an object of None back.

This means that fetchone and fetchall are both broken and *anything*
relying on getting results will be unusable.  I've chosen an Important
severity, but it's much more likely this needs 'grave' severity.

--

Looking around on the internet for this issue, it was found [1] that
getting an upgraded version of pymssql solves the problem completely,
and then returns results for fetchone or fetchall.

Please, as such, provide an updated version of python-pymssql, using at
least version 2.0.1 of the pymssql Python package, which includes fixes
for this problem.


End-user workaround is to remove the python-pymssql package, and use
'easy_install --upgrade pymssql' or similar to install and compile the
pymssql library from source (this necessitates installation of
freetdx-dev though).


--
Thomas

[1]:
http://stackoverflow.com/questions/18760286/pymssql-not-returning-result-data

Bug#823608: nginx-common: Move nginx.vim to a separate package?

[Thomas Ward]

In my opinion, creating a package for a single file (with the exception
of the Dynamic Modules), is a little overkill to do.

While I can understand that this is something desirable to some, I can
see this as an 'extra annoyance' for packaging teams, here and downstream.

I'm of the opinion that Michael has - that this is not something done
frequently or commonly, and that unless there's a really good driving
reason to implement this change, that this is something that can be
wontfix.  We can reevaluate this in the future, but for now I don't
think this is a positive change, no matter how trivial.


--
Thomas

Bug#815095: nginx-extras: Feature request: Add 3rd party module nginx-sticky-module-ng

[Thomas Ward]

Refer to this Debian bug for this (the "master sticky" bug - all New
Addon requests are no longer being processed or accepted -
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790623


Thomas

On 02/18/2016 12:54 PM, Hannes Hoerl wrote:
> Package: nginx-extras
> Severity: wishlist
>
> Dear Maintainer,
>
> I'd like to ask, if it is possible to add another 3rd party module to
> the nginx-extras (or nginx-full?). Specifically I'd like to see nginx
> built with nginx-sticky-module-ng[1].
>
> We may also be able to help with that or with maintaining nginx in
> general (e.g. via the mentors program).
>
> Thanks & Bye,
> Hannes
>
> [1] https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng
>

Bug#813228: Cert Validation Wasn't In 1.4

[Thomas Ward]

ZNC 1.4 never had certificate validation.  That feature was added in ZNC 1.6.  
Therefore you are asking for a new feature or item to be added, so the bug is a 
Wishlist type bug.

I would be extremely wary of incorporating this change into 1.4's packaging if 
only due to the fact that you haven't tested if it cleanly applies.  It may in 
fact be dependent on CSocket changes or others so I would hesitate to add this 
functionality to a version that wasn't designed with that feature in mind.

(Patrick gets the final say in the matter, though if you want 1.6 features in 
Jessie I would consider compiling yourself, or use an available third party 
repository as referred to on ZNC upstream's Installation documentation - 
http://wiki.znc.in/Installation#Debian )

Bug#806340: Please update display-dhammapada to latest upstream release

[Thomas Ward]

Source: display-dhammapada
Severity: wishlist

Hello.  It was requested (to a downstream location where I keep an eye
on) to have display-dhammapada updated to version 1.2 which includes bug
fixes and improvements.

Currently, 1.0 is packaged in Debian, which is at least two years out of
date... it'd be great to have this updated so that downstreams based off
Debian can also get the updated software, as well as making this
software available in Debian.

Bug#796094: Include spnego nignx module in the builds

[Thomas Ward]

Responses in line



*Sent from my iPhone.  Please excuse any typos, as they are likely to happen by 
accident.*

 On Aug 20, 2015, at 09:19, Sean Noonan stnoo...@obsolescence.net wrote:
 
 Howdy!  I happen to be the maintainer of the module in question.  I'll
 answer inline...
 
 On 08/19/2015 08:09 AM, Thomas Ward wrote:
 Control: submitter -1 sorin.sbar...@gmail.com
 
 ...
 
 I think that it would be extremely helpful to include the spnego module
 in nginx builds.
 
 Source https://github.com/stnoonan/spnego-http-auth-nginx-module
 
 Risk considerations: this module is not enabled by default, which means
 that it should not affect nginx stability.
 
 This says that it should not affect stability, but you say that the
 module is not enabled.  That's a given, that it's not 'enabled' by
 default, but the question here, in my opinion is not Is it enabled by
 default but these:
 
 (1) Does this compile correctly?
 I'd certainly hope so.  I periodically test against the current
 release of nginx, ensure -Wall -Werror is fine, and run things through
 the clang-analyzer.
 
 (2) When compiled but not enabled, does it break any other functions
 elsewhere?
 No.
 
 (3) When compiled and enabled, does it work?
 If your configuration is correct, yes.
 
 (4) When compiled and enabled, does it break any other functionality
 elsewhere?
 No.
 
 (5) How 'stable' is it when enabled and being used?  Does it cause
 memory leaks?  Crashes?  etc.
 Very.  Not to my knowledge.  No crashes have been reported.
 
 Another big question: Is this updated regularly to address bugs, and
 other issues that may crop up in it?  Or is it mostly unmaintained now?
 Yes, it is updated as necessary, though I may not tag a release
 anywhere near as often as I should.  What makes you think it is
 unmaintained?

I see multiple requests over time.  I don't check if they're maintained myself, 
hence the question.  Doesn't mean I think it isn't, it means I'm checking by 
asking rather than checking myself since I have a lot of things to do.  That's 
all.

 
 
 
 Thomas
 

Bug#796240: nginx: jessie-backports package should be based on stable branch

[Thomas Ward]

My thoughts are in line below

On 08/20/2015 12:42 PM, Jonh Wendell wrote:
 Source: nginx
 Severity: normal

 I think we should offer as part of backport the stable version of
 upstream package.

 In nginx case, stable branch is 1.8.

 1.9 is the development version (called by upstream 'mainline') which
 will eventually become stable at 1.10 branch/series.

 So, 1.9 series should go to unstable/testing and 1.8 to jessie-backports.

 What do you think?

I think this introduces a logistics problem.  Here's why:

If we backport the newer nginx, the `nginx` source package is a higher
version than 1.8.

If we backport the stable version of nginx, it probably needs to exist
in newer Debian (don't quote me on this, but a 'backport' implies that
it exists in a later version).

If we want separate versions of the same software, we'd need
`nginx-stable` and `nginx-mainline` source packages or similar setups to
set up the differing versions simultaneously, so their versions can be
handled separately and we don't run into dpkg/apt conflicts, I think. 
This would be a logistics headache because we now need to maintain two
separate packages, and versions, and make sure that the packaging lines
up in both packages as we make changes.

It's just a logistical headache/nightmare to manage two separate
versions of the same software, in my opinion...



Thomas