Bug#1070465: nmu: libnginx-mod-http-modsecurity_1.0.3-2

[Ervin Hegedüs]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hello,

the ABI has changed in Nginx package, and the maintainer asked
all 3rd party modules need to rebuild.

See bug #1070321.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070321

Please rebuild libnginx-mod-http-modsecurity against nginx-abi-1.26.0-1

nmu libnginx-mod-http-modsecurity . ANY . unstable . -m "Rebuild with updated 
nginx"



Regards,


a.

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

[Ervin Hegedüs]

Hi Jan,

On Tue, Apr 23, 2024 at 07:29:37PM +0200, Jan Mojzis wrote:
> Hi,
> 
> 'https://wiki.debian.org/qa.debian.org/FTBFS'
> see:
> 2024-03-13 -Werror=implicit-function-declaration
> ... In dpkg version 1.22.6, the compiler flag 
> -Werror=implicit-function-declaration was enabled by default for all 
> architectures in build flags
> ...
> ...

oh, thanks, this is what I was looking for...

> You  need to patch libnginx-mod-http-modsecurity source code:
> 
> ~~~
> diff --git a/config b/config
> index c6e7467..3bf06a8 100644
> --- a/config
> +++ b/config
> @@ -10,7 +10,8 @@
>  
>  ngx_feature_name=
>  ngx_feature_run=no
> -ngx_feature_incs="#include "
> +ngx_feature_incs="#include 
> +#include "
>  ngx_feature_libs="-lmodsecurity"
>  ngx_feature_test='printf("hello");'
>  ngx_modsecurity_opt_I=
> ~~~

yes, this is how my patch looks like.

Perhaps I will add this to the upstream too.


Many thanks.


a.
 

Bug#1068797: modsecurity-crs: IncludeOptional in file owasp-crs.load is incompatible with nginx

[Ervin Hegedüs]

Hi Salil,

Thanks for reporting.

Unfortunately this is a known bug of libmodsecurity3 + Nginx: this
installation does not support the `IncludeOptional` directive.

The workaround is that you change it manually.

Note, that CRS team suggest (since CRS 4) to use the `Include` form in all
cases - see documentation:
https://coreruleset.org/docs/deployment/extended_install/#includes-for-nginx


Regards,

a.


On Thu, Apr 11, 2024 at 11:27 AM Salil Sayed  wrote:

> Package: modsecurity-crs
> Version: 3.3.4-1
> Severity: important
> Tags: newcomer
> X-Debbugs-Cc: salilsa...@gmail.com
>
> Dear Maintainer,
>
> I configured modsecurity for nginx using the available packages in the
> bookworm
> repository; namely, libmodsecurity3 and libnginx-mod-http-modsecurity. It
> worked like charm except with this package modsecuirty-crs. The two
> IncludeOptional directives in the file owasp-crs.load had to be changed to
> Include since nginx does not support IncludeOptional. This simply worked
> but by
> editing a file that the user is not supposed to edit and is likely to be
> overwritten on update.
>
> I believe there may be a way to make the whole modsecurity implementation
> to
> work out of the box for nginx as well by simply changing these two
> IncludeOptional directives to Include. Both of them include files that are
> already provided by the package hence IncludeOptional is redundant.
>
> Thanks,
> Salil
>
>
>
> -- System Information:
> Debian Release: 12.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable'), (100, 'bookworm-fasttrack'), (100, 'bookworm-backports-staging')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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
>
> modsecurity-crs depends on no packages.
>
> modsecurity-crs recommends no packages.
>
> Versions of packages modsecurity-crs suggests:
> pn  geoip-database-contrib
> pn  libapache2-mod-security2  
> pn  lua   
> pn  python
> pn  ruby  
>

Bug#1068207: Problem appeared in other architecture

[Ervin Hegedüs]

The mentioned problem has appeared in other architecture too:

https://buildd.debian.org/status/fetch.php?pkg=libnginx-mod-http-modsecurity=riscv64=1.0.3-1%2Bb1=1712870226=log


a.

Bug#1067364: Probably bug is elsewhere

[Ervin Hegedüs]

I made an investigation and maybe the problem is in another package:
libnginx-mod-http-ndk-dev 1:0.3.3-1.

The report is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068207

I'll inform you here about the result of the investigation.

Regards,


a.

Bug#1068207: Missing header from ngx_feature_test='printf("hello");'

[Ervin Hegedüs]

Package: libnginx-mod-http-ndk-dev
Version: 1:0.3.3-1

There is a module package for Nginx, which worked as well since
this FTBFS bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067364

The upstream contains this section in config:

https://github.com/owasp-modsecurity/ModSecurity-nginx/blob/master/config#L15

ngx_feature_test='printf("hello");'

The problem is when the buildpackage process starts, I got this
error:

hecking for ModSecurity library ... not found
checking for ModSecurity library in /usr/local/modsecurity ... not found
 ./configure: error: ngx_http_modsecurity_module requires the ModSecurity 
library.

see sbuild.log:

http://qa-logs.debian.net/2024/03/19/libnginx-mod-http-modsecurity_1.0.3-1_unstable.log

I investigated the root issue, and I found this message in
obj-x86_64-linux-gnu/autoconf.err:

/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 note: include '' or provide a declaration of 'printf'
cc1: some warnings being treated as errors
--

#include 
#include 
#include 

int main(void) {
printf("hello");;
return 0;
}
...
checking for ModSecurity library in /usr/local/modsecurity

/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:
 In function 'main':
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 error: implicit declaration of function 'printf' 
[-Werror=implicit-function-declaration]
7 | printf("hello");;
  | ^~
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:5:1:
 note: include '' or provide a declaration of 'printf'
4 | #include 
  +++ |+#include 
5 | 
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 warning: incompatible implicit declaration of built-in function 'printf' 
[-Wbuiltin-declaration-mismatch]
7 | printf("hello");;
  | ^~
/home/airween/src/libnginx-mod-http-modsecurity-1.0.3/obj-x86_64-linux-gnu/autotest.c:7:5:
 note: include '' or provide a declaration of 'printf'
cc1: some warnings being treated as errors
--

#include 
#include 
#include 

int main(void) {
printf("hello");;
return 0;
}

If I add a patch (via d/series) which adds this header correctly,
then everything is fine, the package builds as well.

The upstream isn't touched since 6 years (the mentioned file), so
I guess something is changed in libnginx-mod-http-ndk-dev (if it
is responsible to produce the test codes - I guess).

Note, that there isn't any user report in upstream regarding this
problem, actually I can reproduce this only in Debian.


Sorry if I'm wrong.


Thanks,


a.

Bug#1051157: Possible solution (?)

[Ervin Hegedüs]

The file /etc/apparmor.d/abstractions/apache2-common contains
these rules:

22# Apache
23network inet stream,
24network inet6 stream,

which (I guess) needs to enable the trafic.

Seems like the profiles need to include this file too, so the
added this line to the profile

^myvhost.mydomain {

  #include 
  ...

solved the problem. This was not necessary in previous Debian
versions.


It would be nice to know, is that the final solution? Should I
check any other thing? (Eg. in case of a version upgrade...)


a.

Bug#1051157: Apparmor blocks Apache's network trafic

[Ervin Hegedüs]

Package: apparmor
Version: 3.0.8-3

# dpkg -l "*apparmor*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion  Architecture Description
+++-===---
ii  apparmor3.0.8-3  amd64user-space parser 
utility for AppArmor
ii  apparmor-profiles   3.0.8-3  all  experimental 
profiles for AppArmor security policies
ii  apparmor-utils  3.0.8-3  all  utilities for 
controlling AppArmor
ii  libapache2-mod-apparmor 3.0.8-3  amd64changehat 
AppArmor library as an Apache module
ii  libapparmor1:amd64  3.0.8-3  amd64changehat 
AppArmor library
ii  python3-apparmor3.0.8-3  all  AppArmor Python3 
utility library
ii  python3-libapparmor 3.0.8-3  amd64AppArmor library 
Python3 bindings


I've configured Apparmor: enabled Apache and created a profile
for the virtual host. I've copied the working configuration files
from my previous systems (Debian 10 and Debian 11).

The Apache2 profile (usr.sbin.apache2) is untouched (except I
removed the complain flag, so it's in enforce mode). The profile
contains only the paths what I want to allow for Apache's VHOST.

When I send the HTTP request to Apache, I got this response:

* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

In this case I see the lines in syslog:

2023-09-03T17:51:48.864732+02:00 server kernel: [ 2028.475849] audit: type=1400 
audit(1693756308.859:335): apparmor="DENIED" operation="file_perm" 
profile="apache2//myvhost.mydomain" pid=1851 comm="apache2" laddr=192.168.0.246 
lport=80 faddr=192.168.100.140 fport=58896 family="inet" sock_type="stream" 
protocol=6 requested_mask="receive" denied_mask="receive"
2023-09-03T17:51:48.864735+02:00 server kernel: [ 2028.475859] audit: type=1400 
audit(1693756308.859:336): apparmor="DENIED" operation="file_perm" 
profile="apache2//myvhost.mydomain" pid=1851 comm="apache2" laddr=192.168.0.246 
lport=80 faddr=192.168.100.140 fport=58896 family="inet" sock_type="stream" 
protocol=6 requested_mask="send" denied_mask="send"


# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 12 (bookworm)
Release:12
Codename:   bookworm

# cat /etc/debian_version 
12.1



Thanks,


a.

Bug#1029838: src:modsecurity-apache: Please provide working default configuration

[Ervin Hegedüs]

Hi Tobias,

thanks for your report and other notes.

The mentioned configuration file (modsecurity.conf(.recommended))
is part of ModSecurity2. But the package itself
(modsecurity-apache) depends on modsecurity-crs, and this package
uses the same directory (/etc/modsecurity), so there is a strong
connection between these packages.

As I explained in bug #1029836[1], we have to review the package
modsecurity-crs, but I think based on your report (this issue) we
*MUST* review the whole structure in the future.


Thank you again.


a.


1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029836

Bug#949415: modsecurity-apache: Bugs fixed in version 2.9.7

[Ervin Hegedüs]

>> > Can/should this bug be closed?
> 
> Yes, I think it could be.

Uhhmm... sorry, now I reviewed the whole issue and realised that
the first and second posts are about different problems.

PCRE2 dependency (second post) has been solved, but I think the
first one is not about the package modsecurity-apache.

Since this bug is quite old and - I guess - the issue in package
libxml2 has been fixed too (because there isn't any similar issue
during the building), I think we can close the issue.

Sorry, I just wanted to clarify the situation.



a.

Bug#950075: modsecurity-apache FTCBFS: does not pass --host to ./configure

[Ervin Hegedüs]

Hi,

thanks for report and the patch. I've picked up your modification
and added it to package's Git repository. The next version of the
package will build with that method:

https://salsa.debian.org/modsecurity-packaging-team/modsecurity-apache/-/blob/master/debian/rules#L19


Thanks,



a.

Bug#851587: libapache2-modsecurity: prompting due to modified conffiles which were not modified by the user: /etc/apache2/mods-available/security2.conf

[Ervin Hegedüs]

> I guess this is fixed, isn't it?

Yes, I think we can close this.


a.

Bug#949415: modsecurity-apache: Bugs fixed in version 2.9.7

[Ervin Hegedüs]

> has this been fixed indeed?

yes:

https://salsa.debian.org/modsecurity-packaging-team/modsecurity-apache/-/blob/master/debian/rules#L19

modsecurity-apache is shipped with `--with-pcre2` since
2.9.7.

> Can/should this bug be closed?

Yes, I think it could be.


a.

Bug#1029836: Should reload apache2 in updates / package install

[Ervin Hegedüs]

Hi Tobias,

thanks for your patches.

As you know :) since Bookworm Nginx is also able to work as WAF with
libmodsecurity3, and can use modsecurity-crs.

This means the package modsecurity-crs does not need to depend on Apache in
the future. And this implies that after install/upgrade the package won't
know what should it reload: Apache or Nginx?

I think we have to review the whole package structure in the future, because
if the CRS 4.0 will be released, then we must change the structure, see
#1036353[1].

Thanks again to your report and for the patches.

a.

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036353

Bug#1036353: modsecurity-crs: also include the "plugins"

[Ervin Hegedüs]

Hi Mattia,

CRS plugins is a new feature and it will be available from version 4.0:

https://coreruleset.org/docs/concepts/plugins/#how-to-install-a-plugin

"CRS 4.x will come with a plugins folder next to the rules folder."

If you take a look at the existing plugins (
https://github.com/coreruleset/plugin-registry), you can see that most of
them are actually part of the current stable set (3.3.x).

The version 4.0 is coming soon (hope in this year), but the current version
(3.3.4 in stable) is not able to handle the plugins infrastructure yet.

When the 4.0 will be out, we can (must?) consider modifying the package.



Regards,

a.

Bug#1037226:

[Ervin Hegedüs]

Seems like this bug is fixed.

# apt install libnginx-mod-http-modsecurity --default-release bookworm
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  libnginx-mod-http-modsecurity
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 25.4 kB of archives.
After this operation, 196 kB of additional disk space will be used.
Get:1 http://ftp.hu.debian.org/debian bookworm/main amd64
libnginx-mod-http-modsecurity amd64 1.0.3-1+b2 [25.4 kB]
Fetched 25.4 kB in 0s (331 kB/s)
Selecting previously unselected package libnginx-mod-http-modsecurity.
(Reading database ... 57140 files and directories currently installed.)
Preparing to unpack .../libnginx-mod-http-modsecurity_1.0.3-1+b2_amd64.deb
...
Unpacking libnginx-mod-http-modsecurity (1.0.3-1+b2) ...
Setting up libnginx-mod-http-modsecurity (1.0.3-1+b2) ...
Processing triggers for nginx (1.22.1-9) ...
Triggering nginx reload ...

Jul 29 14:11:10 debian12 systemd[1]: Starting nginx.service - A high
performance web server and a reverse proxy server...
Jul 29 14:11:10 debian12 nginx[1600]: 2023/07/29 14:11:10 [notice]
1600#1600: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote:
0/921/0)

Can we close this issue?


a.

On Sat, Jul 15, 2023 at 2:51 PM Tobias Frost  wrote:

> Control: tags -1 pending
> Conrtol: block -1 by 1040799
>
> This bug has been fixed in unstable with the binNMU 1.0.3-1b3, see #1040858
>
> It is also scheduled to be fixed in the next stable-point-release, see
> #1040799
>
>
> --
> tobi
>

Bug#1040858: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Ervin Hegedüs]

On Tue, Jul 11, 2023 at 05:01:11PM +0200, Tobias Frost wrote:
> 
> The situation is explained in more details in #1040799, but the gist
> is that src:libnginx-mod-http-modsecurity is currently compiled against "old" 
> PCRE3 instead
> of "new" PCRE2, and thus is broken in unstable, testing and stable..
> 
> This were the events that lead to the issue:
> 
> - nginx uploaded with OLD PCRE
> - libnginx-mod-http-modsecurity entered NEW and had been accepted
> - it uses the OLD PCRE, as it is compiled against libmodsecurity3, which uses 
> PCRE at that time
> - nginx uploaded with NEW PCRE2
> - modsecurity uploaded with PCRE2
> 
> Situation:
> nginx -> PCRE2
> modsecurity -> PCRE2
> libnginx-mod-http-modsecurity -> OLD PCRE

thanks for clarification.
 
> --> a binnmu will rectify that.
> 
> As Adam said in #1040799, this needs to be fixed first in unstable, this is
> why I'm filing this bug. ("b3" is required to ensure that unstable is newr 
> than stable)

thanks again.

Now if the new (binNMU) package will be uploaded in the unstable (without
any modification), then we can apply the pending PR[1] and upload
it with a new version, eg. libnginx-mod-http-modsecurity_1.0.3-2?


a.



1: 
https://salsa.debian.org/modsecurity-packaging-team/libnginx-mod-http-modsecurity/-/merge_requests/1

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Ervin Hegedüs]

Hi,

> > The BTS metadata for #1037226 indicates that it also affects unstable
> > and testing. Is that correct?

sorry I forget to mention the testing - this package blocks the
migration of Nginx to testing:

https://qa.debian.org/excuses.php?package=nginx


I think we should fix this issue in stable (Bookworm) and SID
separately.

binNMU request will fix in stable, and the mentioned PR (and some
other staff) will fix in unstable. After that (as I wrote) that
will be migrated to testing.


Thanks.



a.

Bug#1040799: nmu: libnginx-mod-http-modsecurity_1.0.3-1+b1

[Ervin Hegedüs]

Package: release.debian.org
Control: affects -1 + src:libnginx-mod-http-modsecurity
X-Debbugs-Cc: libnginx-mod-http-modsecur...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

nmu libnginx-mod-http-modsecurity_1.0.3-1+b1 . ANY . bookworm . -m "Closes: 
1037226"

Bug#1037226:

[Ervin Hegedüs]

Hi,

as the previous message says ("Prepare a fixed package for the first point
release (after ensuring it's fixed in unstable)."), the next release will
contain the fix.

If you need the updated version, you can compile it manually, or you can
use the unofficial ModSecurity repository:
https://modsecurity.digitalwave.hu


a.


On Fri, Jun 23, 2023 at 12:03 PM Ronny Forberger <
ronnyforber...@ronnyforberger.de> wrote:

> Is there already a plan when it will be fixed?
>
> Best regards,
>
> Ronny Forberger
>
>
>
> Ronny Forberger
> E: ronnyforber...@ronnyforberger.de
> W: http://www.ronnyforberger.de
>
>

Bug#1037226: libnginx-mod-http-modsecurity dependency

[Ervin Hegedüs]

Hi,

On Thu, Jun 08, 2023 at 08:34:00PM +0200, Paul Gevers wrote:
> > 
> > sure, but the package itself has not changed. I think without
> > tests we could't have discovered this.
> 
> Sure. That's very common with c-libraries that change their ABI but not
> their API. The SONAME of the library gets bumped, the package maintainer
> ships a new binary package (which matches the SONAME), our tooling detects
> that and we can schedule rebuilds. You *seem* to be in a similar situation,
> except there was no SONAME bump involved, our tooling didn't detect it and
> everything went unnoticed until now.

I see,

> I guess
> https://www.debian.org/doc/debian-policy/ch-sharedlibs.html and maybe 
> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries
> can be good reads.

thanks, I'm going to review these.
 
> > libnginx-mod-http-modsecurity uses one of the PCRE packages: the
> > OLD PCRE, or the NEW, PCRE2 library.
> > 
> > This is decided when we compile the source.
> 
> Again sounds not uncommon. But apparently either nginx or libmodsecurity3
> changed it's ABI as a result of that, which broke the reverse dependencies
> that weren't rebuild.

I understand.
 
> > As I wrote above, libnginx-mod-http-modsecurity does not have any
> > control options to decide which PCRE version wants to use, but
> > during the compile time it sets the symbols. >
> > This is why it compiled to use the OLD PCRE, but not the Nginx,
> > neither the libmodsecurity3 don't use it.
> > 
> > Hope now it's clear - let me know if I can help you in this.
> 
> I'm not a library expert, but this really, really looks wrong to me.

do you have any opinion, how could be it fixed? I do not
participate in development of Nginx, but in libmodsecurity3. Is
there anything what we can do there?
 
> > > Raise the severity of the bug and document it in the release notes.
> > 
> > Sorry for the dumb question, but in which release notes do I need
> > to document?
> 
> https://www.debian.org/releases/bookworm/releasenotes which has its source
> here: https://salsa.debian.org/ddp-team/release-notes/

thanks,
 
> > uhm, that's a bad news.
> > 
> > How can we fix it in unstable?
> 
> Figure out what went wrong. I expect a new library package needs to be
> uploaded (please use experimental for that). Once that's done, a transition
> can be requested, see https://wiki.debian.org/Teams/ReleaseTeam/Transitions

many thanks.
 
> > Because it is decided at compile time.
> 
> One the transition is ACK'ed the rebuild will be scheduled by the release
> team.

okay.
 
> > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/CHANGES#L6
> > https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L41
> > 
> > The ABI isn't changed, but the code itself was aligned to
> > Nginx.
> 
> I a symbol is dropped, that means a break in the ABI.

ah, I think I see the point now.
 
> > I guess you remember my last e-mail in connection with
> > libapache2-mod-security issue:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037024
> > 
> > This situation is similar: there is a dependency (there: libapr1,
> > here: Nginx), which changed the version since the affected
> > package (there: modsecurity-apache, here:
> > libnginx-mod-http-modsecurity) but here the dependent package
> > changed the 3rd-party library, which has a hard effect for the
> > package in subject.
> 
> That situation was different (at least from the symptoms). The problem there
> was that it was emitting a *warning*, nothing broke. The warning is bad but
> not a real problem. Missing symbols is a problem.

sure, I got it.
 
> > I hope I could help to understand the situation.
> 
> I hope you can figure out more what's wrong. We can't really fix it properly
> otherwise.

yes, now I see - many thanks for your help.


a.

Bug#1037226: libnginx-mod-http-modsecurity fails to start after update libmodsecurity3 to v3.0.9

[Ervin Hegedüs]

Hi Daniel,

thanks for reporting.

On Thu, Jun 08, 2023 at 01:47:55PM +0200, Daniel Suchy wrote:
> Package: libnginx-mod-http-modsecurity
> Version: 1.0.3-1+b1
> 
> libmodsecurity3 was upgraded to version v3.0.9 and after that, nginx
> integration/module fails to start:
> 
> [emerg] 348194#348194: dlopen()
> "/usr/share/nginx/modules/ngx_http_modsecurity_module.so" failed
> (/usr/share/nginx/modules/ngx_http_modsecurity_module.so: undefined symbol:
> pcre_malloc) in /etc/nginx/modules-enabled/50-mod-http-modsecurity.conf:1
> 
> That happened on debian/bookworm with libmodsecurity3 (3.0.9-1) and
> libnginx-mod-http-modsecurity (1.0.3-1+b1) packages provided here.

I can confirm this behavior.

Unfortunately when the package was uploaded (2023-01-22) [1] and
migrated into testing, both Nginx and previous libmodsecurity3
(3.0.8) used the "old" PCRE library.

Meanwhile Nginx upgraded, and we bumped the PCRE version in the
libmodsecurity3 too.

This is the reason.
 
> Downgrade to 3.0.8-1 is working work-around. Between versions 3.0.8-1 and
> 3.0.9-1, there was removed debian-specific patch (patches/pcrem4.patch), as
> I noticed - maybe this is cause of this issue.

There is an other workaround too: re-compile the package.

Before the steps below you have to remove the currently installed
module:

sudo dpkg -r libnginx-mod-http-modsecurity

and upgrade libmodsecurity3

sudo apt install libmodsecurity3

Then try to rebuild the package from source:

sudo apt install libnginx-mod-http-ndk-dev nginx-dev
mkdir -f ~/tmp
cd ~/tmp
apt source libnginx-mod-http-modsecurity
cd libnginx-mod-http-modsecurity-1.0.3/
dpkg-buildpackage -us -uc
sudo dpkg -i libnginx-mod-http-modsecurity_1.0.3-1_amd64.deb

Now be sure that the module is enabled:

ls -1 /etc/nginx/modules-enabled/
10-mod-http-ndk.conf
50-mod-http-modsecurity.conf

and check that the WAF is "on" and the log level is "info"
at least:

nl -ba /etc/nginx/nginx.conf 

 1  user www-data;
 2  worker_processes auto;
 3  pid /run/nginx.pid;
 4  error_log /var/log/nginx/error.log info;
...
...
58  
59  modsecurity on;
60  
61  include /etc/nginx/conf.d/*.conf;
62  include /etc/nginx/sites-enabled/*;
...

Now after the restart you have to see that the engine is active:

sudo /etc/init.d/nginx restart
sudo systemctl status nginx.service
...
jún 08 14:59:16 debian-test nginx[4604]: 2023/06/08 14:59:16 [notice] 
4604#4604: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/0/0)
jún 08 14:59:16 debian-test nginx[4605]: 2023/06/08 14:59:16 [notice] 
4605#4605: ModSecurity-nginx v1.0.3 (rules loaded inline/local/remote: 0/0/0)
...


Please let me know if you can fix that with this workaround -
then I'm going top open a ticket for asking rebuild of the
module.


Thanks again.


a.


1: https://tracker.debian.org/pkg/libnginx-mod-http-modsecurity

Bug#1035748: unblock: modsecurity/3.0.9-1

[Ervin Hegedüs]

On Fri, Jun 02, 2023 at 09:46:19PM +0200, Paul Gevers wrote:
> Hi,
> 
> On 01-06-2023 22:39, Ervin Hegedüs wrote:
> 
> > On Thu, Jun 01, 2023 at 09:52:06PM +0200, Paul Gevers wrote:
> > I think there is absolutely no risk. Bot package (libmodsecurity3
> > and libnginx-mod-http-modsecurity) is totally new packages, we
> > won't introduce any "unknown" issues.
> 
> Huh? src:modsecurity as been part of stable for at least two times.

yes, but nothing uses it. There is not any package which depends
on it.
 
> > these files (which created the huge diff) are generated by Bison.
> 
> Now that is extremely relevant information. Why wasn't that shared before
> (and filtered from the debdiff for that reason)?

I don't know... :(

> Does the same hold for all
> that .m4 stuff? Are those files recreated during the build?

I don't think that .m4 files are re-generated during the build
process.

The vendor of ModSecurity provides the generated Bison related
files, but it does not matter, because the generated files are
also have a huge diff.
 
> > (A side note: not these files (above) have huge diff, but the
> > derived ones: seclang-parser.cc, seclang-parser.hh,
> > seclang-scanner.cc)
> 
> But I didn't know... So, please tell me. Which files are generated?

In the upstream directory, here is the line which generates these
lines:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/parser/Makefile.am#L33

And these are the generated lines:

https://github.com/SpiderLabs/ModSecurity/blob/v3/master/src/parser/Makefile.am#L36-L42



a.

Bug#1037024: nmu: modsecurity-apache_2.9.7-1

[Ervin Hegedüs]

Hi Paul,

On Fri, Jun 02, 2023 at 10:16:09PM +0200, Paul Gevers wrote:
> Hi Ervin,
> 
> On 01-06-2023 22:54, Ervin Hegedüs wrote:
> > Now the module complains during the startup process, and users
> > wondering why.
> 
> I wonder why too. 

because of this messages:

[Wed May 31 13:11:05.165477 2023] [security2:notice] [pid 8:tid 1996017088] 
ModSecurity: APR compiled version="1.7.0"; loaded version="1.7.2"
[Wed May 31 13:11:05.165508 2023] [security2:warn] [pid 8:tid 1996017088] 
ModSecurity: Loaded APR do not match with compiled!

> What issues would this rebuild be papering over? Do you
> have a bug report number?

not for Debian, but the user opened an issue on Github:

https://github.com/SpiderLabs/ModSecurity/issues/2910

Thanks,

a.

Bug#1037024: nmu: modsecurity-apache_2.9.7-1

[Ervin Hegedüs]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal

Hello,

we uploaded the package modsecurity_apache
(libapache2-mod-security2) after the new upstream release, but
meanwhile an other package on which this package depends has a
new version (libapr).

Now the module complains during the startup process, and users
wondering why.

Please rebuild modsecurity-apache against libbar1 1.7-2.

nmu libapache2-mod-security2 . ANY . unstable . -m "Rebuild with updated apr"



Regards,


a.

Bug#1035748: unblock: modsecurity/3.0.9-1

[Ervin Hegedüs]

Hi Salvatore,

On Thu, Jun 01, 2023 at 10:24:28PM +0200, Salvatore Bonaccorso wrote:
> Hi Paul,
> 
> > Yet there is a huge amount of white space changes and other changes that
> > look gratuitous. This is really not looking like a targeted fix. @Salvatore,
> > can we do a targeted security upload via security?
> 
> The targeted should be (Alberto, Ervin can you confirm)
> https://github.com/SpiderLabs/ModSecurity/commit/db84d8cf771d39db578707cd03ec2b60f74c9785
> . While it would have been nice to start with modsecurity without
> (known) security issues open in bookworm, I guess at this point of the
> release preparation and soon entering  the last week, skip it and the
> CVE can be fixed in the first bookworm point release.

yes, this is a critical bug, which leads to an unexpected
behavior (the attacker can DOS-ed the whole Nginx).

But - as I explained in my other e-mail - libmodsecurity3 has a
complex codebase, with a language (grammar) parser. This can
cause a huge diff's, unfortunately.

> Regards,
> Salvatore
> 
> p.s.: The PCRE to PCRE2 switch is one other aspect why it would have
>   been nice to have 3.0.9 in bookworm.

Exactly.

We upload this library earlier, but meanwhile Nginx bumped the
PCRE version (finally!) to PCRE2. We *MUST* to update this
package too to ingore the other unexpected behaviors.



Thanks,


a.

Bug#1035748: unblock: modsecurity/3.0.9-1

[Ervin Hegedüs]

hi there,

sorry to join this conversation :),

On Thu, Jun 01, 2023 at 09:52:06PM +0200, Paul Gevers wrote:
> control: tags -1 moreinfo
> 
> Hi,
> 
> On 28-05-2023 21:30, Alberto Gonzalez Iniesta wrote:
> > 2) The risks on the release quality are almost zero. Only
> > libnginx-mod-http-modsecurity depends on it (being modsecurity a
> > library).
> 
> That's not the only part that we mean here. We also mean, how big is the
> risk we introduce new *unknown* issues.

I think there is absolutely no risk. Bot package (libmodsecurity3
and libnginx-mod-http-modsecurity) is totally new packages, we
won't introduce any "unknown" issues.

Or - sorry to say - I don't see what issues do you think about.

> > 4) No idea
> 
> Then I don't think so. If your upstream would have a decent stable update
> policy, they wouldn't introduce so many gratuitous changes (e.g. white space
> only).

Unfortunately the vendor releases new versions randomly. :(
 
> > 6) Yes
> 
> I fail to spot it. Can you please point which version?

Hmmm... I don't think so (I mean the correct answer for the 6th
question is no). As I noted above, both packages are totally new.

(But the demand is very big)
 
> > 7) Its too long but mainly because of line numbers being updated in code
> > comments, like:
> > -#line 1459 "seclang-parser.yy"
> > +#line 1461 "seclang-parser.yy"
> > 8) Not that many code changes
> 
> Yet there is a huge amount of white space changes and other changes that
> look gratuitous. This is really not looking like a targeted fix. @Salvatore,
> can we do a targeted security upload via security?

these files (which created the huge diff) are generated by Bison.
These describe the grammar for the SecLang configuration syntax.

This is how a compiler works: if the developer adds a new token,
change a small behavior, then it can result a huge diff.

(A side note: not these files (above) have huge diff, but the
derived ones: seclang-parser.cc, seclang-parser.hh,
seclang-scanner.cc)

 
> > 9) Not that difficult :-)
> 
> Might be, but impossible to review between all the cruft.

The mentioned files have huge diff, but those diff's are because
of those files are compiled.

You can consider these like a .am file, which generated from a
.in file with help of autotools.

I'm not sure anyone wants to review a .am file :)


Sorry again,

and thanks for your time/help.



a.

 

Bug#1012495: [Pkg-nginx-maintainers] Bug#1012495: RFP: libnginx-mod-http-modsecurity - ModSecurity v3 Nginx Connector

[Ervin Hegedüs]

hi there,

On Wed, Jun 08, 2022 at 11:29:58AM +, Patrick Schleizer wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: pkg-nginx-maintain...@alioth-lists.debian.net
> 
> The maintainer of the custom libnginx-mod-http-modsecurity deb package
> is Ervin Hegedüs. He is a CRS developer [2], Debian Maintainer [3] and
> ModSecurity [4] code contributor.
> 
> Ervin, already a Debian Maintainer, would like to add the package to
> Debian too. [5]

additional note: I tried to add this package first time here:

https://alioth-lists.debian.net/pipermail/pkg-nginx-maintainers/2018q4/000710.html

Later I tried to contact with the package maintainer, with still
no luck.

I also prepared the package in Salsa:

https://salsa.debian.org/airween/nginx/-/tree/modsecurity

I know, this is very outdated, but I think this would be a good
start.

If anybody has any question, please let me know.




a.

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi there,

On Mon, Sep 13, 2021 at 06:32:02AM +0200, Ervin Hegedüs wrote:
> Hi Daniele,
> 
> On Sun, Sep 12, 2021 at 10:02:47PM +0200, Daniele Forsi wrote:
> > that lintian pages tells to remove the menu file
> > /usr/share/menu/twclock not the Exec line
> 
> thanks - that's what I also wrote here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994099#26
> 
> but first I have to check the behavior without menu file.

I've installed a Debian Testing into a VM with some desktop
environments.

For now I checked the .desktop file (with and without d/menu
file) that .desktop contained the 'Exec'.

I installed both versions, without any difference.

When I start to type in the search field of Start menu, then I
can find the twclock, and is starts when I click it.

But the installer does not put it under any existing menu.

I've made a counter-test: downloaded the grig package, created
d/menu file, built the package and installed it. The installer
put the package under the "Other" menu item.

Actually, no conclusion. I think I have to make more researches.


73, Ervin

 

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi Daniele,

On Sun, Sep 12, 2021 at 10:02:47PM +0200, Daniele Forsi wrote:
> Ervin Hegedüs wrote:
> 
> > this was the lintian tag why I removed the Exec:
> >
> > https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file
> 
> that lintian pages tells to remove the menu file
> /usr/share/menu/twclock not the Exec line

thanks - that's what I also wrote here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994099#26

but first I have to check the behavior without menu file.

73, Ervin

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi Christoph,

On Sat, Sep 11, 2021 at 10:54:44PM +0200, Christoph Berg wrote:
> 
> Exec was actually removed in the last upload.
> 
> Ervin, do you remember why that was done? Afaict without "Exec", the
> program won't be launched. (But I'm not a .desktop user)

this was the lintian tag why I removed the Exec:

https://lintian.debian.org/tags/command-in-menu-file-and-desktop-file

Now I remember when I prepared this package, I had a Debian SID
desktop (in a VM), and I played with that. First I tryed to
remove the d/menu as the lintian page proposes, but then the
installer didn't create any menu entry.

In next days, I'l install a Debian SID and a testing desktop
systems, and will try to play on them again.


73, Ervin
 

Bug#994099: twclock: improve .desktop file

[Ervin Hegedüs]

Hi folks,

On Sat, Sep 11, 2021 at 10:54:44PM +0200, Christoph Berg wrote:
> Re: Daniele Forsi
> 
> > --- twclock.desktop.orig2020-05-22 15:57:34.0 +0200
> > +++ twclock.desktop 2021-09-11 20:13:41.033571003 +0200
> > @@ -3,8 +3,10 @@
> >  Name[en_US]=twclock
> >  Comment=World Clock and CW ID for Ham Radio Operators
> >  Comment[en_US]=World Clock and CW ID for Ham Radio Operators
> > +Comment[it_IT]=Orologio mondiale e ID CW per radioamatori
> > +Exec=twclock


thanks for all - I will take a look it soon.

> Exec was actually removed in the last upload.
> 
> Ervin, do you remember why that was done? Afaict without "Exec", the
> program won't be launched. (But I'm not a .desktop user)

as I remember, that was some policy issue. I'm sure the lintian
reported that. But I have to check that too.


73, Ervin
 

Bug#939395: [Debian-ha-maintainers] Bug#939395: ocfs2-tools - FS can't mount at boot on drbd device

[Ervin Hegedüs]

Hi Valentin,

thanks for quick reply,

On Wed, Sep 04, 2019 at 07:42:46PM +0200, Valentin Vidić wrote:
> 
> You might want to try configuring systemd to start the
> services sequentially (Requires+After):
> 
> 1. drbd.service
> 2. o2cb.service
> 3. ocfs2.service or drbd.mount (they both try to mount).

1. drbd.service doesn't exists (there isn't any drbd*
service/device/other unit file)
2. o2cb doesn't depend on drbd
3. I tried to add the dev-drbd0.device earlier as Request/After,
but didn't solve the problem.

Now looks like this works:

# diff -ruN ocfs2.service /lib/systemd/system/ocfs2.service
--- ocfs2.service   2019-09-04 14:43:55.613155935 +0200
+++ /lib/systemd/system/ocfs2.service   2019-09-05 10:59:12.552486408 +0200
@@ -1,12 +1,13 @@
 [Unit]
 Description=Mount ocfs2 Filesystems
 Documentation=man:ocfs2(7) man:mount.ocfs2(8)
-Requires=o2cb.service
-After=o2cb.service
+Requires=dev-drbd0.device drbd.service o2cb.service
+After=dev-drbd0.device drbd.service o2cb.service
 
 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=/usr/lib/ocfs2-tools/ocfs2 start
 ExecStop=/usr/lib/ocfs2-tools/ocfs2 stop
 ExecReload=/usr/lib/ocfs2-tools/ocfs2 restart

so, the "dev-drbd0.device" and "drbd.service" dependencies added
to Requires and After fields solves my problem.

How can I help you to propagate this solution? I mean, should I
edit the Wiki (when I got my access :)) here?

https://wiki.debian.org/DrBd


Thanks,


a.

Bug#939395: ocfs2-tools - FS can't mount at boot on drbd device

[Ervin Hegedüs]

Package: ocfs2-tools
Version: 1.8.5-7
Severity: normal

Hi,

I have two up-to-date Debian systems, with drbd and ocfs2. There
is only one drbd device, which configured as Primary/Primary.

Everything works as well, except one thing: the system can't
mount the drbd device at boot, I have to do it by hand.

Relevant configs:

# cat /etc/drbd.d/r0.res 
resource r0 {
  meta-disk internal;
  device /dev/drbd0;
  syncer {
verify-alg sha1;
  }
  net {
allow-two-primaries;
  }
  startup {
become-primary-on both;
  }
  on t2app1 {
disk /dev/vg-t2app1/lvdrbd0;
address 192.168.72.21:7789;
  }
  on t2app2 {
disk /dev/vg-t2app2/lvdrbd0;
address 192.168.72.22:7789;
  }
}

# cat /etc/ocfs2/cluster.conf 
cluster:
node_count = 2
name = data

node:
ip_port = 
ip_address = 192.168.72.21
number = 1
name = t2app1
cluster = data

node:
ip_port = 
ip_address = 192.168.72.22
number = 2
name = t2app2
cluster = data

# grep drbd /etc/fstab 
/dev/drbd0  /drbd   ocfs2   _netdev,defaults0   0


With these settings (total equals...) on Debian 9, there the
mount works as well, without any interruption.



Additional infos:


Status of services after reboot:

# systemctl status drbd.mount
● drbd.mount - /drbd
   Loaded: loaded (/etc/fstab; generated)
   Active: failed (Result: exit-code) since Wed 2019-09-04 15:13:49 CEST; 16s 
ago
Where: /drbd
 What: /dev/drbd0
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)

Sep t 04 15:13:49 t2app1 systemd[1]: Mounting /drbd...
Sep t 04 15:13:49 t2app1 mount[720]: mount.ocfs2: I/O error on channel while 
opening device /dev/drbd0
Sep t 04 15:13:49 t2app1 systemd[1]: drbd.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep t 04 15:13:49 t2app1 systemd[1]: drbd.mount: Failed with result 'exit-code'.
Sep t 04 15:13:49 t2app1 systemd[1]: Failed to mount /drbd.

# systemctl status drbd.service
● drbd.service - LSB: Control DRBD resources.
   Loaded: loaded (/etc/init.d/drbd; generated)
   Active: active (exited) since Wed 2019-09-04 15:13:53 CEST; 41s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 686 ExecStart=/etc/init.d/drbd start (code=exited, status=0/SUCCESS)

Sep t 04 15:13:49 t2app1 systemd[1]: Starting LSB: Control DRBD resources
Sep t 04 15:13:49 t2app1 drbd[686]: Starting DRBD resources:[
Sep t 04 15:13:49 t2app1 drbd[686]:  create res: r0
Sep t 04 15:13:49 t2app1 drbd[686]:prepare disk: r0
Sep t 04 15:13:49 t2app1 drbd[686]: adjust disk: r0
Sep t 04 15:13:49 t2app1 drbd[686]:  adjust net: r0
Sep t 04 15:13:49 t2app1 drbd[686]: ]
Sep t 04 15:13:53 t2app1 drbd[686]: WARN: stdin/stdout is not a TTY; using 
/dev/console.
Sep t 04 15:13:53 t2app1 systemd[1]: Started LSB: Control DRBD resources..

# systemctl status ocfs2.service
● ocfs2.service - Mount ocfs2 Filesystems
   Loaded: loaded (/lib/systemd/system/ocfs2.service; enabled; vendor preset: 
enabled)
   Active: active (exited) since Wed 2019-09-04 15:13:49 CEST; 1min 40s ago
 Docs: man:ocfs2(7)
   man:mount.ocfs2(8)
  Process: 796 ExecStart=/usr/lib/ocfs2-tools/ocfs2 start (code=exited, 
status=0/SUCCESS)
 Main PID: 796 (code=exited, status=0/SUCCESS)

Sep t 04 15:13:49 t2app1 systemd[1]: Starting Mount ocfs2 Filesystems...
Sep t 04 15:13:49 t2app1 ocfs2[796]: Starting Oracle Cluster File System 
(OCFS2) mount.ocfs2: I/O error on channel while opening device /dev/drbd0
Sep t 04 15:13:49 t2app1 ocfs2[796]: Failed
Sep t 04 15:13:49 t2app1 systemd[1]: Started Mount ocfs2 Filesystems.

# grep drbd /var/log/syslog
Sep  4 15:13:29 t2app1 systemd[1]: dev-drbd0.device: Dependency 
Before=network-online.target ignored (.device units cannot be delayed)
Sep  4 15:13:29 t2app1 systemd[1]: dev-drbd0.device: Dependency 
Before=network.target ignored (.device units cannot be delayed)
Sep  4 15:13:31 t2app1 systemd[1]: Unmounting /drbd...
Sep  4 15:13:31 t2app1 systemd[1021]: drbd.mount: Succeeded.
Sep  4 15:13:49 t2app1 systemd-modules-load[373]: Inserted module 'drbd'
Sep  4 15:13:49 t2app1 kernel: [3.422172] drbd: initialized.  Version: 
8.4.10 (api:1/proto:86-101)
Sep  4 15:13:49 t2app1 kernel: [3.422173] drbd: srcversion: 
9B4D87C5E865DF526864868 
Sep  4 15:13:49 t2app1 kernel: [3.422174] drbd: registered as block device 
major 147
Sep  4 15:13:49 t2app1 drbd[686]: Starting DRBD resources:[
Sep  4 15:13:49 t2app1 drbd[686]:  create res: r0
Sep  4 15:13:49 t2app1 drbd[686]:prepare disk: r0
Sep  4 15:13:49 t2app1 systemd[1]: Found device /dev/drbd0.
Sep  4 15:13:49 t2app1 systemd[1]: Mounting /drbd...
Sep  4 15:13:49 t2app1 mount[720]: mount.ocfs2: I/O error on channel while 
opening device /dev/drbd0
Sep  4 15:13:49 t2app1 systemd[1]: drbd.mount: Mount process exited, 
code=exited, status=1/FAILURE
Sep  4 15:13:49 t2app1 systemd[1]: drbd.mount: Failed with result 'exit-code'.
Sep  4 15:13:49 t2app1 systemd[1]: Failed to mount /drbd.
Sep  4 15:13:49 t2app1 

Bug#934939: RFS: xlog/2.0.17-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: xlog
   Version : 2.0.17-1
   Upstream Author : Andy Stewart KB1OIQ 
 * URL : http://savannah.nongnu.org/projects/xlog
 * License : GPL
   Section : hamradio

It builds those binary packages:

  xlog - GTK+ Logging program for Hamradio Operators
  xlog-data - data for xlog, a GTK+ Logging program for Hamradio
  Operators

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/x/xlog/xlog_2.0.17-1.dsc

More information about xlog can be obtained from
http://savannah.nongnu.org/projects/xlog

Changes since the last upload:
  * Team upload.
  * New upstream release (Closes: #925864).
  * Bump Standards-Version to 4.4.0.


Regards,
 Ervin Hegedüs

Bug#916420: RFS: tlf/1.3.2-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tlf
   Version : 1.3.2-1
   Upstream Author : Thomas Beierlein 
 * URL : https://savannah.nongnu.org/projects/tlf
 * License : GPL
   Section : hamradio

It builds those binary packages:

  tlf   - console based ham radio contest logger

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/t/tlf/tlf_1.3.2-1.dsc

More information about tlf can be obtained from
https://savannah.nongnu.org/projects/tlf, https://tlf.github.io/
or https://github.com/Tlf/tlf.

Changes since the last upload:

  * Team upload.
  * New upstream release
  * Removed spelling-fixes.patch, all modifications had been
merged to upstream

Regards,
 Ervin Hegedüs

Bug#912313: RFS: tlf/1.3.1-1

[Ervin Hegedüs]

Hi Adam,

thanks for review,

On Tue, Oct 30, 2018 at 11:48:29PM +0100, Adam Borowski wrote:
> On Tue, Oct 30, 2018 at 09:09:27AM +0100, Ervin Hegedüs wrote:
> >  * Package name: tlf
> >Version : 1.3.1-1
> 
[...]
> 
> diff -Nru tlf-1.3.0/debian/source/include-binaries 
> tlf-1.3.1/debian/source/include-binaries
> --- tlf-1.3.0/debian/source/include-binaries1970-01-01 01:00:00.0 
> +0100
> +++ tlf-1.3.1/debian/source/include-binaries2018-10-29 22:38:06.0 
> +0100
> @@ -0,0 +1,145 @@
> +src/addarea.o
> +src/addcall.o
[...]
> +test/test_zone_nr.o
> 
> 
> I have a feeling you did not quite intend this...

you're a mind-reader! :)

Of course, I didn't wanted to do this.

Fixed, and pushed again.


Thanks again,


a.

Bug#912402: RFS: tlf/1.3.1-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tlf
   Version : 1.3.1-1
   Upstream Author : Thomas Beierlein 
 * URL : https://savannah.nongnu.org/projects/tlf
 * License : GPL
   Section : hamradio

It builds those binary packages:

  tlf   - console based ham radio contest logger

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/t/tlf/tlf_1.3.1-1.dsc

More information about tlf can be obtained from
https://savannah.nongnu.org/projects/tlf, https://tlf.github.io/
or https://github.com/Tlf/tlf.

Changes since the last upload:

  * Team upload.
  * New upstream release
  * Bump compat to 11
  * Bump Standards-Version to 4.2.1
  * Added DH_VERBOSE=1 in d/rules
  * Modified spelling-fixes.patch, some modifications had been
merged to upstream
  * Added libcmocka-dev to dependency list in d/control
  * Removed trailing whitespaces from d/control
  * Removed dh-autoreconf and autotools-dev packages
(not required since compat lev 10)
  * Replaced Priority from extra to optional
  * Changed upstream source in d/rules to https
  * Removed d/README.source - contained old reference


Regards,
 Ervin Hegedüs

Bug#912314: RFS: psk31lx/2.2-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

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

 * Package name: psk31lx
   Version : 2.2-1
   Upstream Author : TED J WILLIAMS 
 * URL : http://wa0eir.bcts.info/psk31lx.html
 * License : GPL v3
   Section : hamradio

It builds those binary packages:

  psk31lx- PSK31 terminal application with text-based user interface

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/psk31lx/psk31lx_2.2-1.dsc

More information about psk31lx can be obtained from
http://wa0eir.bcts.info/psk31lx.html

Changes since the last upload:

  * Team upload
  * New upstream version (Closes: #911780)
  * Removed desktop-category.patch - upstream contains it
  * Removed man-hyphen.patch - upstream contains it
  * Removed new-fsf-address.patch - upstream contains it
  * Removed typo.patch - upstream contains it
  * Aligned no-double-changelog.patch to new upstream
  * Bump Standards-Version to 4.2.1
  * Removed trailing whitespaces from d/control, d/rules,
d/copyright
  * Bump debhelper version to 11.0.0
  * Changed Debian copyright URL to https scheme


Regards,
 Ervin Hegedüs

Bug#912313: RFS: tlf/1.3.1-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: tlf
   Version : 1.3.1-1
   Upstream Author : Thomas Beierlein 
 * URL : https://savannah.nongnu.org/projects/tlf
 * License : GPL
   Section : hamradio

It builds those binary packages:

  tlf   - console based ham radio contest logger

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/t/tlf/tlf_1.3.1-1.dsc

More information about tlf can be obtained from
https://savannah.nongnu.org/projects/tlf, https://tlf.github.io/
or https://github.com/Tlf/tlf.

Changes since the last upload:

  * Team upload.
  * New upstream release
  * Bump compat to 11
  * Bump Standards-Version to 4.2.1
  * Added DH_VERBOSE=1 in d/rules
  * Modified spelling-fixes.patch, some modifications had been
merged to upstream
  * Added libcmocka-dev to dependency list in d/control
  * Removed trailing whitespaces from d/control
  * Removed dh-autoreconf and autotools-dev packages
(not required since compat lev 10)
  * Replaced Priority from extra to optional


Regards,
 Ervin Hegedüs

Bug#911780: psk31lx: version monotony violation: lenny had 2.1+2.2beta1-8

[Ervin Hegedüs]

Hi Andreas,

On Fri, Oct 26, 2018 at 10:00:34AM +0200, Andreas Beckmann wrote:
> On 2018-10-24 22:32, Ervin Hegedüs wrote:
> > $ apt-get source psk31lx
> 
> correct, this is the source you want

right,

> > So looks like the avaliable source and binary packages are
> > differs (just fyi).
> > 
> > (And I din't find the source of the current stable package - the package 
> > site
> > is this:
> > 
> > https://packages.debian.org/stretch/psk31lx
> > 
> > the source points to here:
> > http://http.debian.net/debian/pool/main/p/psk31lx/psk31lx_2.1-1.debian.tar.xz
> > 
> > which is what I got through apt-get source, not the released
> > binary source (2.1-1+b1). This package contains an "empty"
> > changelog, there isn't any version history - how could I fix this
> > what you described?)
> 
> The +b1 is a binNMU version, i.e. the package was rebuilt with no source
> changes against a newer library version. This resulted in a new binary
> package with updated dependencies, but this is not part of the history
> tracked in the source package. Sid has an even newer binNMU version of
> the same source package: +b2

thanks for the clarification.

Now if I interpret it as right way, I can use continuos the
source above.

Meantime Ted (maintainer of source) answered, and the new
version (2.2) is out - it contains the Debian patches eg...


Thanks again, I'll do it soon.


a.
 

Bug#911780: psk31lx: version monotony violation: lenny had 2.1+2.2beta1-8

[Ervin Hegedüs]

Hi Andreas,

On Wed, Oct 24, 2018 at 07:17:21PM +0200, Andreas Beckmann wrote:
> Package: psk31lx
> Version: 2.1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> lenny had the following binary package (from src:twpsk):

[...]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911780
 
> According to
> http://snapshot.debian.org/binary/psk31lx/
> there is quite a mess of version numbers.
> 
> Bumping the source package version to 2.1+really2.1-1 with no further
> changes should fix this. This is preferred over adding an epoch.
> 
> $ dpkg --compare-versions 2.1+2.2beta1-8 lt 2.1+really2.1-1 && echo lt
> lt

thanks for the info, I've contacted with Ted, the maintainer of
psk31lx, is there any avaliable new relase - hope he will answer
as soon.



Anyway, I've checked the source package of psk31lx on stretch:

$ lsb_release -id
Distributor ID: Debian
Description:Debian GNU/Linux 9.4 (stretch)

$ apt-get source psk31lx
...

$ cat psk31lx-2.1/debian/changelog 
psk31lx (2.1-1) unstable; urgency=low

  * Initial release. (Closes: #772087)

 -- Milan Kupcevic   Sat, 07 Nov 2015 19:51:41 -0500

$ cat psk31lx-2.1/debian/control 
Source: psk31lx
Section: hamradio
Priority: optional
Maintainer: Debian Hamradio Maintainers 
Uploaders: Milan Kupcevic 
Build-Depends: debhelper (>= 9.0.0), libncurses5-dev, libpulse-dev
Standards-Version: 3.9.6
Homepage: http://wa0eir.bcts.info/psk31lx.html

Package: psk31lx
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: PSK31 terminal application with text-based user
interface
 psk31lx is a simple text-based terminal program with a built-in phase scope 
 and spectrum analyzer to aid in signal tuning. It uses a sound card to receive 
 and transmit PSK31 tone.


So looks like the avaliable source and binary packages are
differs (just fyi).

(And I din't find the source of the current stable package - the package site
is this:

https://packages.debian.org/stretch/psk31lx

the source points to here:
http://http.debian.net/debian/pool/main/p/psk31lx/psk31lx_2.1-1.debian.tar.xz

which is what I got through apt-get source, not the released
binary source (2.1-1+b1). This package contains an "empty"
changelog, there isn't any version history - how could I fix this
what you described?)


thanks, regards,


a.

Bug#906899: wsjtx: Upstream 1.9.1 available

[Ervin Hegedüs]

Hi Paul,

On Thu, Aug 23, 2018 at 08:30:41AM -0400, Paul Stoetzer wrote:
> 1.9.1 should be the targeted version to package. Why spend any effort on
> packaging an outdated version that lacks features many stations need to use
> to communicate with other stations?

we've discussed it before, I've made a package from 1.9.1:

https://lists.debian.org/debian-hams/2018/07/msg00010.html

"I think the WSJTX is a bit old version (1.8). I've started to
work it on, sent a mail to here, but didn't get any relevant
answer.

Anyway, the WSJT-X current version is 1.9.1, I've made a package
from that upstream:

http://ha2os.ha5kkc.com/Wsjtx/;

It works with Hamlib 3.1.8 (Debian package), just would be good
to review and test the package, and I could upload to FTP. Now it
would be to wait the Hamlib 3.2 (Enrico working hard on it, I've
seen his works, congratulation for that), and re-build with that.


My big problem again: nobody listen on the list, and didn't get
any feedback... :(


73, Ervin
HA2OS

 
> On Thu, Aug 23, 2018 at 8:07 AM Enrico Rossi  wrote:
> 
> > Hi Paul,
> >
> > there is an ongoing effort to package the 1.8 version first, see
> >
> > https://salsa.debian.org/debian-hamradio-team/wsjtx
> >
> > as soon as #906775 got fixed.
> >
> > Thanks for reporting.
> > Bye
> > E.
> >
> > --
> > GPG key: 4096R/5E0195FAF2133176 2010-10-19 Enrico Rossi <
> > e.ro...@tecnobrain.com>
> >

Bug#906775: hamlib: FTBFS in buster/sid (makeinfo: command not found)

[Ervin Hegedüs]

Hi Santiago,

On Mon, Aug 20, 2018 at 10:50:13PM +, Santiago Vila wrote:
> Package: src:hamlib
> Version: 3.1-8
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> dh_testdir
> dh_autoreconf
> aclocal: overwriting 'macros/libtool.m4' with '/usr/share/aclocal/libtool.m4'
> aclocal: overwriting 'macros/ltoptions.m4' with 
> '/usr/share/aclocal/ltoptions.m4'
> 
> [... snipped ...]

[...]
 
> /<>/build-aux/missing: line 81: makeinfo: command not found
> WARNING: 'makeinfo' is missing on your system.
>  You should only need it if you modified a '.texi' file, or

this is a known problem - we don't know the reason exactly
(perhaps the texinfo package changed - but the problem came to
SID/Buster after an upgrade).

https://lists.debian.org/debian-hams/2018/07/msg1.html

The workaround is just install the texinfo package manually.

We're working on Hamlib 3.2, hope that it will released soon (see
the mail thread above).



73, Ervin
HA2OS

Bug#888682: hamlib uses deprecated Tcl 8.5

[Ervin Hegedüs]

Hi Sergei,

On Fri, Mar 16, 2018 at 02:27:18PM +0300, Sergei Golovan wrote:
> Hi Ervin,
> 
> On Mon, Jan 29, 2018 at 5:10 PM, Ervin Hegedüs <airw...@gmail.com> wrote:
> > Hi Sergei,
> >
> > thanks for your feedback,
> >
> > On Sun, Jan 28, 2018 at 07:12:26PM +0300, Sergei Golovan wrote:
> >> Source: hamlib
> >> Version: 3.1-7
> >> Severity: important
> >> Tags: patch
> >>
> >> Dear Maintainer,
> >>
> >> Since Tcl 8.5 has reached its end-of-life we are planning to remove
> >> it from Debian before the buster's release. So please, switch the
> >> libhamlib2-tcl package to a modern Tcl version which is 8.6 (or better
> >> to a default one which should work for future 8.7 as well).
> >
> > I've made the new package, hope that the upload and accept flow
> > will done soon.
> 
> Any update on that? If you have the package, I could do the upload for you.

yes - I've tried to upload, but I don't have permission to this
package.

You can find it here:

http://ha2os.ha5kkc.com/Hamlib/

> >
> > Note, that I didn't found 8.7 from Tcl in SID.
> 
> It's in experimental at the moment since there's only a beta release 
> available.

sure,
 
> >> I've attached a proposed NMU which 1) replaces tcl8.5-dev by tcl-dev
> >> in build dependencies and corrects the --with-tcl in debian/rules
> >> (/usr/lib/tclConfig.sh includes a DEB_HOST_MULTIARCH hack, so don't bother
> >> about deleting it from debian/rules configure call); 2) moves the
> >> Tcl package to /usr/lib/tcltk/hamlib3.1 as it can be loaded to different
> >> Tcl shells (I haven't tested it thoroughly). If you don't mind, I could do
> >> the upload.
> >
> > and many thanks for your help - I've replaced the affected
> > settings in files you sent, checked the results (after I built
> > and installed the packages). Everything has worked as well.
> 
> Good to know.


thanks,

73, Ervin
HA2OS

Bug#892472: please refer to nftables

[Ervin Hegedüs]

Hi,

Debian Policy allows to use the | (pipe) symbol in case of some fields:

https://www.debian.org/doc/debian-policy/#syntax-of-relationship-fields



a.

On Sat, Mar 10, 2018 at 2:04 PM, Yaroslav Halchenko 
wrote:

> There is no | for recommends afaik
>
> On March 10, 2018 7:54:01 AM EST, Arturo Borrero Gonzalez <
> art...@debian.org> wrote:
> >On 9 March 2018 at 16:26, Yaroslav Halchenko  wrote:
> >> THANKS!  but...
> >>
> >> On Fri, 09 Mar 2018, Arturo Borrero Gonzalez wrote:
> >>
> >>> Also, no need to `Recommends: iptables`, since is installed by
> >default in every
> >>> Debian system.
> >>
> >> indeed it is (triple checked with debootstrap)  but it could also as
> >> easily be uninstalled.  And that is what I guess is done by docker
> >and
> >> may be other environments removing it (so docker images come without
> >> iptables preinstalled since it is of no sense for them).  So I still
> >> wonder if we should retain iptables in Recommends since it doesn't
> >hurt.
> >>
> >> Also, until nftables is the strongly encouraged default we should
> >> not place it into Recommends but keep it in Suggests to not install
> >it
> >> when people who already have the "default" iptables, apt-get install
> >> fail2ban (and thus its recommends)
> >>
> >> what do you think?
> >
> >then perhaps we could Recommends: nftables | iptables
>
> --
> Sent from a phone which beats iPhone.
>
>

Bug#888682: hamlib uses deprecated Tcl 8.5

[Ervin Hegedüs]

Hi Sergei,

thanks for your feedback,

On Sun, Jan 28, 2018 at 07:12:26PM +0300, Sergei Golovan wrote:
> Source: hamlib
> Version: 3.1-7
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> Since Tcl 8.5 has reached its end-of-life we are planning to remove
> it from Debian before the buster's release. So please, switch the
> libhamlib2-tcl package to a modern Tcl version which is 8.6 (or better
> to a default one which should work for future 8.7 as well).

I've made the new package, hope that the upload and accept flow
will done soon.

Note, that I didn't found 8.7 from Tcl in SID.
 
> I've attached a proposed NMU which 1) replaces tcl8.5-dev by tcl-dev
> in build dependencies and corrects the --with-tcl in debian/rules
> (/usr/lib/tclConfig.sh includes a DEB_HOST_MULTIARCH hack, so don't bother
> about deleting it from debian/rules configure call); 2) moves the
> Tcl package to /usr/lib/tcltk/hamlib3.1 as it can be loaded to different
> Tcl shells (I haven't tested it thoroughly). If you don't mind, I could do
> the upload.

and many thanks for your help - I've replaced the affected
settings in files you sent, checked the results (after I built
and installed the packages). Everything has worked as well.


Many thanks,


73, Ervin
HA2OS
 

Bug#855171: closed by Adam Borowski <kilob...@angband.pl> (Re: Bug#855171: RFS: tlf/1.3.0-1)

[Ervin Hegedüs]

Hi Adam,


(I didn't get your mail from you, just through the bug
notification...)

On Fri, Feb 17, 2017 at 02:06:04AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
> 
> #855171: RFS: tlf/1.3.0-1
> 
> It has been closed by Adam Borowski <kilob...@angband.pl>.
> 
> 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 Adam Borowski 
> <kilob...@angband.pl> by
> replying to this email.

> Date: Fri, 17 Feb 2017 03:03:27 +0100
> From: Adam Borowski <kilob...@angband.pl>
> To: 855171-d...@bugs.debian.org
> Subject: Re: Bug#855171: RFS: tlf/1.3.0-1
> 
> On Thu, Feb 16, 2017 at 10:00:43AM +0100, Ervin Hegedüs wrote:
> > > experimental or wait until freeze end.
> > 
> > right - I'll do it.
> 
> And 'ere we go -- uploaded.

thanks for your help,
 
> > > > I can't change it. But I can make it for all systems: for stable,
> > > > testing and sid with same version number. Is that a solution?
> > > You can't update packages in stable or testing.
> 
> Other than targetted fixes for severity:important or higher bugs, that is,
> with a special procedure.

is that the reason, that it could't go to testing?
 
> > Anyway, now what will the next step with Tlf package?
> 
> It's in experimental now, where sadly it will see far less exposure than it
> would in unstable, but an user who wants the new version can still get it.
> 
> Packages don't migrate from experimental, so anywhen between stretch's
> release and buster's freeze you'll have to make an upload to unstable.
> Even a no-change bump will do, but looking at your release frequency, you'll
> have something new by then.

and what should I do for this package would part of the testing
release?

There is the Hamlib package (collection), it's more important to
users can get... And of course, I should make Tlf again.


Thanks,


a.
 

Bug#855171: RFS: tlf/1.3.0-1

[Ervin Hegedüs]

Hi,

On Thu, Feb 16, 2017 at 01:53:59PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 09:50:32AM +0100, Ervin Hegedüs wrote:
> > > > > > > > I'm working on another (hamradio related) package(s)... Also
> > > > > > > > should I wait with them?
> > > > > > > With all packages already existing in testing.
> > > > > > 
> > > > > > I'm sorry, but I don't understand this really...
> > > > > What part of it? The reasons written by Adam above apply to all 
> > > > > packages
> > > > > that exist both in testing and unstable.
> > > > 
> > > > * hamlib - it exists in stable, testing and unstable, but it
> > > >   released a new version with several new features
> > > > * grig   - also exists in all systems, but the package only has
> > > >   a small modification: it has a desktop file...
> > > It doesn't matter what changes will you put in sid. What matters is that
> > > when testing and sid contain different versions of a package it's
> > > impossible to update the package in testing by uploading the update to
> > > sid.
> > 
> > Ok, but what's the solution?
> experimental or wait until freeze end.

right - I'll do it.

> > The Hamlib has a new version number
> The upstream version doesn't matter. The full package version does.

I'ld like to follow the upstream versioning, so that will a new
package version.
 
> > I can't change it. But I can make it for all systems: for stable,
> > testing and sid with same version number. Is that a solution?
> You can't update packages in stable or testing.

ok, thanks.


Anyway, now what will the next step with Tlf package?


Thanks,

Ervin
 

Bug#855171: RFS: tlf/1.3.0-1

[Ervin Hegedüs]

Hi,

On Thu, Feb 16, 2017 at 01:47:23PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 09:41:13AM +0100, Ervin Hegedüs wrote:
> > > > > > I'm working on another (hamradio related) package(s)... Also
> > > > > > should I wait with them?
> > > > > With all packages already existing in testing.
> > > > 
> > > > I'm sorry, but I don't understand this really...
> > > What part of it? The reasons written by Adam above apply to all packages
> > > that exist both in testing and unstable.
> > 
> > * hamlib - it exists in stable, testing and unstable, but it
> >   released a new version with several new features
> > * grig   - also exists in all systems, but the package only has
> >   a small modification: it has a desktop file...
> It doesn't matter what changes will you put in sid. What matters is that
> when testing and sid contain different versions of a package it's
> impossible to update the package in testing by uploading the update to
> sid.

Ok, but what's the solution?

The Hamlib has a new version number, I can't change it. But I can
make it for all systems: for stable, testing and sid with same
version number. Is that a solution?


Regards,

Ervin

Bug#855171: RFS: tlf/1.3.0-1

[Ervin Hegedüs]

Hi Andrey,

On Thu, Feb 16, 2017 at 01:33:25PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 09:29:02AM +0100, Ervin Hegedüs wrote:
> > > > I'm working on another (hamradio related) package(s)... Also
> > > > should I wait with them?
> > > With all packages already existing in testing.
> > 
> > I'm sorry, but I don't understand this really...
> What part of it? The reasons written by Adam above apply to all packages
> that exist both in testing and unstable.

* hamlib - it exists in stable, testing and unstable, but it
  released a new version with several new features
* grig   - also exists in all systems, but the package only has
  a small modification: it has a desktop file...


Regards,

Ervin

Bug#855171: RFS: tlf/1.3.0-1

[Ervin Hegedüs]

Hi Andrey,

thanks for the helpful answer,

On Thu, Feb 16, 2017 at 12:30:23PM +0500, Andrey Rahmatullin wrote:
> On Thu, Feb 16, 2017 at 08:18:44AM +0100, Ervin Hegedüs wrote:
> > > However, are you sure you want this uploaded to unstable during freeze?  
> > > It
> > > will make it really unpleasant to fix anything targetted at stretch; and
> > > also make the Release Team unhappy.  You don't want them unhappy.
> > > 
> > > Thus, wouldn't experimental be better for now?
> > 
> > I'm really sorry, but I just could make it now... so... what
> > should I do now?
> > 
> > Delete the uploaded package, and wait till the end of the freeze?
> Change the distribution in the changelog, add a line "Upload to
> experimental" and reupload the package.

done - I've changed the distribution to "experimental", and put
the line what you wrote.


> > I'm working on another (hamradio related) package(s)... Also
> > should I wait with them?
> With all packages already existing in testing.

I'm sorry, but I don't understand this really...


Regards,

a.

Bug#855171: RFS: tlf/1.3.0-1

[Ervin Hegedüs]

Hi Adam,

On Thu, Feb 16, 2017 at 01:40:32AM +0100, Adam Borowski wrote:
> On Tue, Feb 14, 2017 at 11:17:46PM +0100, Ervin Hegedüs wrote:
> > I am looking for a sponsor for my package "tlf"
> > 
> > Package name: tlf
> > Version : 1.3.0-1
> 
> > Changes since the last upload:
> > 
> >   * New upstream version.
> >   * Added native Fldigi interface depend libs to control file.
> >   * Added new uploader to control file.
> >   * Added native Fldigi interface switch to rules file.
> >   * Changed upstream location in README.source file.
> >   * Removed watch file.
> >   * Removed previous patches/spelling-fixes.patch - all of them
> > were applied in upstream.
> >   * Added new patches/spelling-fixes.patch, based on the
> > lintian's messages.
> >   * Added all copyright owners from sources.
> 
> Looks good.

thanks,

> However, are you sure you want this uploaded to unstable during freeze?  It
> will make it really unpleasant to fix anything targetted at stretch; and
> also make the Release Team unhappy.  You don't want them unhappy.
> 
> Thus, wouldn't experimental be better for now?

I'm really sorry, but I just could make it now... so... what
should I do now?

Delete the uploaded package, and wait till the end of the freeze?

I'm working on another (hamradio related) package(s)... Also
should I wait with them?


Regards,


a. 

Bug#855171: RFS: tlf/1.3.0-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

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

Package name: tlf
Version : 1.3.0-1
Upstream Author : Ervin Hegedus <airw...@gmail.com>
URL : www.hs-mittweida.de/tb/tlf-1.3.0.tar.gz
License : GPL-2+
Section : hamradio

It builds those binary packages:

  tlf   - console based ham radio contest logger

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/t/tlf/tlf_1.3.0-1.dsc

More information about tlf can be obtained from
https://tlf.github.io.


Changes since the last upload:

  * New upstream version.
  * Added native Fldigi interface depend libs to control file.
  * Added new uploader to control file.
  * Added native Fldigi interface switch to rules file.
  * Changed upstream location in README.source file.
  * Removed watch file.
  * Removed previous patches/spelling-fixes.patch - all of them
were applied in upstream.
  * Added new patches/spelling-fixes.patch, based on the
lintian's messages.
  * Added all copyright owners from sources.



Regards,
Ervin Hegedüs

-- 
I � UTF-8

Bug#851799: RFS: hamlib/3.1.0-1

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name  : hamlib
 Version : 3.1.0-1
 Upstream Author : Kamal Mostafa <ka...@whence.com>, Colin Tuckley 
<col...@debian.org>
 * URL   : https://sourceforge.net/projects/hamlib/
 * License   : LGPLv2
 Section : hamradio

It builds those binary packages:

libhamlib++-dev - Development C++ library to control radio transceivers and 
receive
libhamlib-dev - Development library to control radio transceivers and receivers
libhamlib-doc - Documentation for the hamlib radio control library
libhamlib-utils - Utilities to support the hamlib radio control library
libhamlib2 - Run-time library to control radio transceivers and receivers
libhamlib2++c2 - Run-time C++ library to control radio transceivers and 
receivers
libhamlib2-perl - Run-time perl library to control radio transceivers and 
receivers
libhamlib2-tcl - Run-time Tcl library to control radio transceivers and 
receivers
lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers
python-libhamlib2 - Run-time Python library to control radio transceivers and 
receive

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1.dsc

More information about hello can be obtained from
https://sourceforge.net/projects/hamlib

Changes since the last upload:

 * Team upload
 * New upstream release
 * Changed manpages directory in manpage-hyphen-fixes.patch
 * Added Lua binding
 * Fixed broken libhamlib2-tcl package
 * Bump Standards-version to 3.9.8

Regards,
 Ervin Hegedüs

-- 
I � UTF-8

Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

[Ervin Hegedüs]

Hi Adrey,

On Wed, Jan 18, 2017 at 11:16:16PM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 18, 2017 at 04:57:44PM +0100, Ervin Hegedüs wrote:
> > I'm member of the team (as guest:
> > https://alioth.debian.org/users/airween-guest/). As I wrote, I
> > noticed the team through the list - no response.
> In that case this upload should be a team upload and not a NMU. See
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-team-upload

thanks a lot!


a.
 

-- 
I � UTF-8

Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

[Ervin Hegedüs]

Hi Adrey,

On Wed, Jan 18, 2017 at 08:35:50PM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 18, 2017 at 04:29:43PM +0100, Ervin Hegedüs wrote:
> > > Why are doing this NMU?
> > because lintian indicated that I must give NMU as version to that
> > package
> I've meant why are you doing this upload of someone else's package.

because there aren't any member, who did it. Anyway, I just would
like to help to maintain (I've made soma part of the upstream
version, I thought I can help...).

I'm member of the team (as guest:
https://alioth.debian.org/users/airween-guest/). As I wrote, I
noticed the team through the list - no response.
 
> > Okay, thanks for your feedback - what should I do now? 
> As this is a team-maintained package you should join the team and work on
> this package as a team member. 

see above.

> Note though that you have only a week to
> get this package uploaded to sid before the freeze.

I know that, that's why I uploades to mentors.debian.org.
 

a.

Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

[Ervin Hegedüs]

Hi,

On Wed, Jan 18, 2017 at 08:15:53PM +0500, Andrey Rahmatullin wrote:
> Control: tags -1 + moreinfo
> 
> Why are doing this NMU?

because lintian indicated that I must give NMU as version to that
package

> Does it fix any bugs?
yes, till I worked on the package, I've found a bug (a binary
package is empty), but I didn't reported that, just fixed it in new
version. I don't know that the Bump-Standard-Version modifaction
is fixup or not.

> Have you read about the NMU
> procedure at
> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu
> and followed it?


yes - post factum (now).

I've made the package about two weeks ago, and wrote a
notification to debian-hams@ list, but still didn't get any
answer.

> Besides, it even has a wrong version suffix.

Okay, thanks for your feedback - what should I do now? 


a.

Bug#851762: RFS: hamlib/3.1.0-1+nmu1 [NMU]

[Ervin Hegedüs]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

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

* Package name  : hamlib
Version : 3.1.0-1+nmu1
Upstream Author : Kamal Mostafa <ka...@whence.com>, Colin Tuckley 
<col...@debian.org>
* URL   : https://sourceforge.net/projects/hamlib/
* License   : LGPLv2
Section : hamradio

It builds those binary packages:

libhamlib++-dev - Development C++ library to control radio transceivers and 
receive
libhamlib-dev - Development library to control radio transceivers and receivers
libhamlib-doc - Documentation for the hamlib radio control library
libhamlib-utils - Utilities to support the hamlib radio control library
libhamlib2 - Run-time library to control radio transceivers and receivers
libhamlib2++c2 - Run-time C++ library to control radio transceivers and 
receivers
libhamlib2-perl - Run-time perl library to control radio transceivers and 
receivers
libhamlib2-tcl - Run-time Tcl library to control radio transceivers and 
receivers
lua-hamlib2 - Run-time Lua library to control radio transceivers and receivers
python-libhamlib2 - Run-time Python library to control radio transceivers and 
receive

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hamlib/hamlib_3.1.0-1+nmu1.dsc

More information about hamlib can be obtained from 
https://sourceforge.net/projects/hamlib/

Changes since the last upload:

 * NMU
 * New upstream release
 * Changed manpages directory in manpage-hyphen-fixes.patch
 * Added Lua binding
 * Fixed broken libhamlib2-tcl package
 * Bump Standards-version to 3.9.8



Regards,
 Ervin Hegedüs

Bug#574391: udev: same serial number on different disks

[Ervin Hegedüs]

Hello,

 When I plug one of them (it doesn't matter which) udev gives same serial 
 number.
 This looks wrong on multiple levels. Anyway, please try to reproduce
 this with udev from unstable.

unstable package depends for recent libc6, dpkg-buildpackage also...
(and another ones too)
I don't want to install from source, I don't want to get around
packaging system.

Is there any way to reproduce?


Thanks:

airween



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#574391: udev: same serial number on different disks

[Ervin Hegedüs]

Package: udev
Version: 0.105

There are two USB disks for back up the system, all disks has cryptfs.

When I plug one of them (it doesn't matter which) udev gives same serial number.
I have tested I plug all two disks at simultaneously, here is the output:

# udevinfo -a -p /sys/block/sdb | grep serial
ATTRS{serial}==31AF4D71B008
ATTRS{serial}==:00:1d.7
# udevinfo -a -p /sys/block/sdc | grep serial
ATTRS{serial}==31AF4D71B008
ATTRS{serial}==:00:1d.7

# cat /dev/.udev/db/blo...@sd[bc]
N:sdb
S:disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B008
S:disk/by-path/pci-:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
M:8:16
E:ID_VENDOR=SAMSUNG
E:ID_MODEL=HD642JJ
E:ID_REVISION=1112
E:ID_SERIAL=SAMSUNG_HD642JJ_31AF4D71B008
E:ID_TYPE=disk
E:ID_BUS=usb
E:ID_PATH=pci-:00:1d.7-usb-0:4:1.0-scsi-0:0:0:0
N:sdc
S:disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B008
S:disk/by-path/pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0
M:8:32
E:ID_VENDOR=SAMSUNG
E:ID_MODEL=HD642JJ
E:ID_REVISION=1112
E:ID_SERIAL=SAMSUNG_HD642JJ_31AF4D71B008
E:ID_TYPE=disk
E:ID_BUS=usb
E:ID_PATH=pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0

I would like to use two rules to identify disks when user
attach one of them, but system doesn't sense which disk
has attached.

The disk-by-id symlinks has created correctly:
# ls -l /dev/disk/by-id/usb*
lrwxrwxrwx 1 root root  9 2010-03-12 21:40
/dev/disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B000 - ../../sdb
lrwxrwxrwx 1 root root 10 2010-03-12 21:40
/dev/disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B000-part1 - ../../sdb1
lrwxrwxrwx 1 root root  9 2010-03-12 21:46
/dev/disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B008 - ../../sdc
lrwxrwxrwx 1 root root 10 2010-03-12 21:46
/dev/disk/by-id/usb-SAMSUNG_HD642JJ_31AF4D71B008-part1 - ../../sdc1

As you can see there are the correct serial numbers.



I am using Debian GNU/Linux 4.0, kernel 2.6.24-etchnhalf.1-686 and
libc6 2.3.6.ds1-13etch9+b1.

Thanks:


a.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org