Bug#910966: RFS: 4pane/5.0-2

2018-10-15 Thread Herbert Fortes 

Hi,

My final comments so I can upload the package:

The history of debian/changelog is been changed. Please,
keep the history.

https://tracker.debian.org/media/packages/4/4pane/changelog-5.0-1

diff -Nru 4pane-5.0/debian/changelog 4pane-5.0/debian/changelog
--- 4pane-5.0/debian/changelog  2017-07-20 11:18:45.0 -0300
+++ 4pane-5.0/debian/changelog  2018-10-08 13:15:58.0 -0300
@@ -1,12 +1,19 @@
-4pane (5.0-1) unstable; urgency=medium
+4pane (5.0-2) unstable; urgency=medium
+
+  * Depend on the gtk+3 version of wxWidgets: see #894663
+  * Override testsuite-autopkgtest-missing
+  * Add an upstream/metadata file
+  * Move the appdata.xml file from appdata/ to metadata/
+  * Change some links from http: to https:
+  * Update to the latest debhelper and policy versions
+
+ -- David Hart   Mon, 08 Oct 2018 17:15:58 +0100
+
+4pane (5.0-1) testing; urgency=medium
 
   * New upstream version.

 All the previous patches are now redundant and a dfsg tarball is
 no longer needed.
-  * Bump std-version to 4.0.0, no changes needed
-  * Update copyright file.
-  * Add dependency on gettext, msgfmt is used by upstream build system
-  * Update watch file
 
  -- David Hart   Thu, 20 Jul 2017 15:18:45 +0100




 - debian/rules does not need these two lines:

diff -Nru 4pane-5.0/debian/rules 4pane-5.0/debian/rules
--- 4pane-5.0/debian/rules  2017-07-20 11:18:45.0 -0300
+++ 4pane-5.0/debian/rules  2018-10-08 13:15:58.0 -0300
@@ -3,8 +3,6 @@
 DH_VERBOSE = 1
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all

-DPKG_EXPORT_BUILDFLAGS = 1
-include /usr/share/dpkg/buildflags.mk



Regards,
Herbert

Bug#910591: ITA: logdata-anomaly-miner -- lightweight tool for log checking, log analysis

2018-10-15 Thread Wurzenberger Markus 
Dear Boyuan,

I fixed all bugs you mentioned and lintian shows no more errors. Hence, it 
should be possible to continue with your review.

Regards,
Markus Wurzenberger

-Original Message-
From: Boyuan Yang  
Sent: Samstag, 13. Oktober 2018 01:56
To: Wurzenberger Markus 
Cc: 910...@bugs.debian.org; 910...@bugs.debian.org; Tobias Frost 

Subject: Re: Bug#910591: ITA: logdata-anomaly-miner -- lightweight tool for log 
checking, log analysis

Control: tag -1 + moreinfo

Tobias Frost  于2018年10月12日周五 上午1:35写道：
> From my perspective (and I think this is also the opinion of the MIA 
> team), it is ok for Markus to take over the package in this case, as 
> he got the (verbal) ok from the former maintainer and we do not have 
> reasons to believe that this is not true. IMHO there is no need to 
> formally orphan it beforehand (and strictly it would not need an ITA either).
> (And still, if we find out that Roman would disagrees, he can easily 
> be re-instatniated as maintainer.)
>
> --
> tobi

Thanks tobi, that makes things easier.

Markus, I just reviewed your package and there are pretty many problems.
Have you taken a look at
https://mentors.debian.net/package/logdata-anomaly-miner ?
There are several errors and hints that you should solve first.
Please run lintian every time you prepare a upload and solve all errors and 
warnings.

* You should almost never convert a standard 3.0(quilt) package to
3.0(native) without
  proper explanation. Could you please revert packaging format back to
3.0 (quilt)
  or is there any reasons for converting package type?

* Please use Standards-Version 4.2.1. That corresponds to the latest version of 
debian-policy.

* dh-systemd is an obolete package. Please depends on latest dehelper (e.g., >= 
11) and remove
  dependency to dh-systemd. The debian/compat file also must be updated 
accordingly.

* You are using "dh --with python3" in debian/rules but not specifying any 
dependency or
  build-dependency on python3 (You are depending on python2 and
python2 libraries all around
  in debian/control instead). That is a big error and must be solved.

Please fix those bugs and notify me after all problems are solved. Thanks!

--
Regards,
Boyuan Yang


smime.p7s
Description: S/MIME cryptographic signature

Bug#910895: marked as done (RFS: lirc/0.10.1-1)

2018-10-15 Thread Debian Bug Tracking System 
Your message dated Mon, 15 Oct 2018 15:07:13 + (UTC)
with message-id <1984692926.15172362.1539616033...@mail.yahoo.com>
and subject line Re: Bug#910895: RFS: lirc/0.10.1-1
has caused the Debian Bug report #910895,
regarding RFS: lirc/0.10.1-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
910895: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910895
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: lirc
   Version : 0.10.1-1
   Upstream Author : Christoph Bartelmus l...@sf.net
 * URL : http://sf.net/p/lirc
 * License : GPL-2+
   Section : utils

It builds those binary packages:

 liblirc-client0 - infra-red remote control support - client library
 liblirc-dev - Infra-red remote control support - development files
 liblirc0   - Infra-red remote control support - Run-time libraries
 liblircclient-dev - Transitional placeholder for obsoleted
liblircclient-dev
 liblircclient0 - Transitional placeholder for obsoleted liblircclient0
 lirc  - Infra-red remote control support - daemons and utils
 lirc-doc   - Infra-red remote control support - website and manual docs
 lirc-x - infra-red remote control support - X utilities

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

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

Or, download the package with dget:

dget -x
https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.1-1.dsc

More information about lirc can be obtained from http://lirc.org.

Changes since the last upload:

- Updated to latest upstream bugfix release
- Fixed a crash when starting lirc-setup(1).
- Dropped an upstreamed build patch.
- Update to version 4.2.1, compat level 11 (systemd fixes).


Regards,
   Alec Leamas
--- End Message ---
--- Begin Message ---
Hello Alec!
>https://mentors.debian.net/debian/pool/main/l/lirc/lirc_0.10.1-1.dsc

happily sponsored!
G.

  --- End Message ---

Bug#911072: RFS: batctl/2018.3-1~bpo9+1 [BPO]

2018-10-15 Thread Sven Eckelmann 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my backport of package "batctl" for 
stretch-backports. It is required to use the netlink batadv commands 
which were introduced with newer kernel version. There were multiple members 
of the Freifunk community which observed this problem when they either used a 
newer backports kernel or when they've build the external batman-adv 
2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an 
example from yesterday:

 
https://zerobin.fff.community/?ae8511ae06bb09c0#0FvEHmbKsRIQhTsIfhs87iRSbJMtorJ+LRup0N2oz6o=
 can anyone help me, why i can't look in he dat table?
 ChristianD: is bat0 up ?
 and is also ichtostVPN up?
 yes and yews
 it works fine
 the complete mesh works fine, but i can't look into the dat 
table
 ChristianD: looks like you are using a batctl version which cannot 
talk via netlink to batman-adv
 (at least not to the dat cache)
 please update to at least batctl 2018.1
 or enable debugfs again in batman-adv

I am the current (with Simon) maintainer of batctl in Debian. And I also did 
the jessie-backports uploads in the past. But this upload must now go through 
NEW (tested this because I was not sure) and thus I need a sponsor for that.

 * Package name: batctl
   Version : 2018.3-1~bpo9+1
   Upstream Author : Marek Lindner 
 * URL : https://www.open-mesh.org/
 * License : GPL-2
   Section : net

It builds those binary packages:

  batctl - B.A.T.M.A.N. advanced control and management tool

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2018.3-1~bpo9+1.dsc

More information about batctl can be obtained from https://open-mesh.org/.

Changes since the last upload (stretch 2016.5-1):

 batctl (2018.3-1~bpo9+1) stretch-backports; urgency=medium
 .
   * Rebuild for stretch-backports.
 .
 batctl (2018.3-1) unstable; urgency=medium
 .
   * New Upstream Version
 .
 batctl (2018.2-1) unstable; urgency=medium
 .
   * New Upstream Version
 .
 batctl (2018.1-1) unstable; urgency=medium
 .
   * New Upstream Version
 .
 batctl (2018.0-1) unstable; urgency=medium
 .
   * New Upstream Version
   * debian/control
 - Change Vcs-Git and Vcs-Browser to salsa.debian.org
   * debian/copyright:
 - Update copyright years
 - Adjust license of batman_adv.h
 .
 batctl (2017.4-1) unstable; urgency=medium
 .
   * New Upstream Version
   * Upgraded to policy 4.1.2
 - Switch from priority extra to optional
   * Change documentation filename to README.rst
   * Change changelog filename to CHANGELOG.rst
 .
 batctl (2017.3-1) unstable; urgency=medium
 .
   * New Upstream Version
   * Upgraded to policy 4.0.1.0
 - Switch from priority extra to optional
   * debian/patches:
 - Remove upstream merged
   batctl-Fix-error-message-when-traceroute-packet-send-fail.patch
 .
 batctl (2017.2-2) unstable; urgency=medium
 .
   * Upload to unstable
   * debian/patches:
 - Add batctl-Fix-error-message-when-traceroute-packet-send-fail.patch,
   Fix error message when traceroute packet send failed
 .
 batctl (2017.2-1) experimental; urgency=medium
 .
   * New Upstream Version
   * debian/control:
 - update to debhelper 10
   * Upgraded to policy 4.0.0, no changes required
   * debian/rules
 - Remove ddeb migration conflict against pre-stretch package
 .
 batctl (2017.1-1) experimental; urgency=medium
 .
   * New Upstream Version
 .
 batctl (2017.0-1) experimental; urgency=medium
 .
   * New Upstream Version
   * debian/copyright:
 - Update copyright years

The full upstream changelog can be found at
https://git.open-mesh.org/batctl.git/blob/HEAD:/CHANGELOG.rst (or in the
package under /usr/share/doc/batctl/changelog.gz)

Regards,
Sven Eckelmann

signature.asc
Description: This is a digitally signed message part.

Bug#911071: RFS: batctl/2018.3-1~bpo8+1 [BPO]

2018-10-15 Thread Sven Eckelmann 
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my backport of package "batctl" for 
jessie-backports-sloppy. It is required to use the netlink batadv commands 
which were introduced with newer kernel version. There were multiple members 
of the Freifunk community which observed this problem when they either used a 
newer backports kernel or when they've build the external batman-adv 
2018.2/2018.3 module (which has DEBUGFS disabled by default). Here is an 
example from yesterday:

 
https://zerobin.fff.community/?ae8511ae06bb09c0#0FvEHmbKsRIQhTsIfhs87iRSbJMtorJ+LRup0N2oz6o=
 can anyone help me, why i can't look in he dat table?
 ChristianD: is bat0 up ?
 and is also ichtostVPN up?
 yes and yews
 it works fine
 the complete mesh works fine, but i can't look into the dat 
table
 ChristianD: looks like you are using a batctl version which cannot 
talk via netlink to batman-adv
 (at least not to the dat cache)
 please update to at least batctl 2018.1
 or enable debugfs again in batman-adv

I am the current maintainer (with Simon) of batctl in Debian. And I also did 
the jessie-backports uploads in the past. But this upload must now go through 
NEW (tested this because I was not sure) and thus I need a sponsor for that.

 * Package name: batctl
   Version : 2018.3-1~bpo8+1
   Upstream Author : Marek Lindner 
 * URL : https://www.open-mesh.org/
 * License : GPL-2
   Section : net

It builds those binary packages:

  batctl - B.A.T.M.A.N. advanced control and management tool

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

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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/b/batctl/batctl_2018.3-1~bpo8+1.dsc

More information about batctl can be obtained from https://open-mesh.org/.

Changes since the last upload (jessie-backports 2018.0-1~bpo8+1):

 batctl (2018.3-1~bpo8+1) jessie-backports-sloppy; urgency=medium
 .
   * Rebuild for jessie-backports-sloppy.
 .
 batctl (2018.3-1) unstable; urgency=medium
 .
   * New Upstream Version
 .
 batctl (2018.2-1) unstable; urgency=medium
 .
   * New Upstream Version
 .
 batctl (2018.1-1~bpo8+1) jessie-backports; urgency=medium
 .
   * Rebuild for jessie-backports.
 .
 batctl (2018.1-1) unstable; urgency=medium
 .
   * New Upstream Version

The full upstream changelog can be found at
https://git.open-mesh.org/batctl.git/blob/HEAD:/CHANGELOG.rst (or in the
package under /usr/share/doc/batctl/changelog.gz)

Regards,
Sven Eckelmann

signature.asc
Description: This is a digitally signed message part.

Re: Problem with pristine-tar (which tarball should I commit?)

2018-10-15 Thread Mattia Rizzolo 
On Mon, Oct 15, 2018 at 05:02:51AM -0300, Samuel Henrique wrote:
> * there's no pristine-tar commit of the upstream release 3.3.1
> * there was a NMU, so the last upload was 3.3.1-1.1
> * 3.3.1-1.1 was not committed on the packaging repository
> * we committed changes before making sure the git repo was up to date,
> for the release 3.3.4
> 
> If I clone the repository and do a gbp import-dsc of 3.3.1-1.1 it mess
> up the repository because it will create the commits after the 3.3.4-1
> ones in the master branch.

of course...

> My plan of action was:
> 1) commit 3.3.1 to pristine-tar

sure, and that's straightforward simple with no way it could clash...

> 2) commit the changes of 3.3.1-1.1 of master on the correct place,
> rewriting git history[1]

why do people think about rewriting that easily...
do this instead:
git checkout -b tmp debian/3.3.1-1
gbp import-dsc --debian-branch=tmp ../supervisor_3.3.1-1.1.dsc
git checkout master
git merge debian/3.3.1-1.1
# solve your merge conflicts.  I expect that you pretty much
# want to keep only the changelg if that patch is already
# upstream
git branch -d tmp
there.

> 3) confirm that both the tags debian/3.3.1-1 and debian/3.3.1-1.1
> builds correclty

well… not sure this is particularly useful tbh :)

> The main problem is on the first step, I described the whole plan in case
> anybody has a different suggestion on how to fix this but nonetheless I
> would like to at least understand what is going on with pristine-tar:
> 
> First plan was to import the github tarball of the 3.3.1 release:
> wget https://github.com/Supervisor/supervisor/archive/3.3.1.tar.gz -O \

that's wrong a different level:  you should strive to commit to the
debian git repository what is being uploaded to the debian archive,
which can easily be different than what upstream published.
(even if it might be same this time).

> All of this makes me think that I'm missing something very crucial
> here, the possibilities I can think are:
> * I should not assume that the contents of upstream and master branch
> should be the same (even when using 3.0 quilt sources format)

they should, but sometimes people get things wrong so they diverge…

> * I'm doing something wrong when generating the tarballs of the
> upstream and master branch, I highly believe this is one of the
> problems

regardless of anything, I think you should be using
http://debian.backend.mirrors.debian.org/debian/pool/main/s/supervisor/supervisor_3.3.1.orig.tar.gz

> * I should not assume that if the hash of a tarball being equal as the
> one which Pristine-tar expects to is the correct one, because I
> received that errors when committing the tarball from GH and it looks
> like it's the one which pristine-tar doesn't complain of hash
> mismatch.

probably that tarball was ok, but the master branch had changed files.
Have you looked at the temporary file created by dpkg-source that was
mentioned in the error?  That contains the list of diff that you should
check.  also look at the git history and see if anything was changed in
the upstream files but only in the master branch.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Problem with pristine-tar (which tarball should I commit?)

2018-10-15 Thread Andrey Rahmatullin 
On Mon, Oct 15, 2018 at 05:02:51AM -0300, Samuel Henrique wrote:
> Result:
> gbp:error: Pristine-tar couldn't verify
> "supervisor_3.3.1.orig.tar.gz": pristine-tar:
> /tmp/build-area/supervisor_3.3.1.orig.tar.gz does not match stored
> hash (expected 
> 85eda4f053d2ef6c19a4b33fbf5c9fe7d8dfc24fabf7bc4067707ec841d6d30c,
> got 454f532fae5a54363838fba42bc568f7b2fd0fd71d946b8c39d848a225d0da0f)
> 
> Ok, so this is strange, the sha256sum of the GH tarball is the second
> one showed on the error, so this means that I should have committed
> that tarball instead
No? It means you should delete the wrong tarball from /tmp/build-area.

> and the error says "expected" from a POV where
> it expects the upstream code[2] to be equal of the pristine-tar files
> (and not the other way around), 
No?

"${tarball} does not match stored hash (expected ${stored_hash}, got 
${tarball_hash})"

> let's at least check the sha256sum of
> the files on the master branch (excluding the debian dir):
> gbp clone g...@salsa.debian.org:debian/supervisor.git
> cd supervisor
> git checkout debian/3.3.1-1
> tar --exclude='debian' -zcvf ../supervisor_3.3.1.orig.tar.gz *
> sha256sum ../supervisor_3.3.1.orig.tar.gz
Here you are making a random tarball and checking its hash, I don't think
it's worth doing.

> Result:
> 74cc1931e2ab8c90a7ff980c71f408a2f43be3449f927b2f724f78ea1feabbd1
> ../supervisor_3.3.1.orig.tar.gz
> 
> Which is again different of the sha256sum of the tarball I created
> from the upstream/3.3.1 tag.
Which is expected. 

> All of this makes me think that I'm missing something very crucial
> here, the possibilities I can think are:
> * I should not assume that the contents of upstream and master branch
> should be the same (even when using 3.0 quilt sources format)
They should be the same after removing debian/ from both.

> * I'm doing something wrong when generating the tarballs of the
> upstream and master branch, I highly believe this is one of the
> problems
You shouldn't generate them manually...

> * I should not assume that if the hash of a tarball being equal as the
> one which Pristine-tar expects to is the correct one, because I
> received that errors when committing the tarball from GH and it looks
> like it's the one which pristine-tar doesn't complain of hash
> mismatch.
Umm.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Problem with pristine-tar (which tarball should I commit?)

2018-10-15 Thread Samuel Henrique 
Hello,

Me and Stéphane are taking over the maintenance of supervisor[0] and I
stumbled upon problems:

* there's no pristine-tar commit of the upstream release 3.3.1
* there was a NMU, so the last upload was 3.3.1-1.1
* 3.3.1-1.1 was not committed on the packaging repository
* we committed changes before making sure the git repo was up to date,
for the release 3.3.4

So I need to introduce the changes from 3.3.1-1.1 to the packaging
repository while keeping the commits we already made (for the 3.3.4-1
package that is being worked on).

If I clone the repository and do a gbp import-dsc of 3.3.1-1.1 it mess
up the repository because it will create the commits after the 3.3.4-1
ones in the master branch.

My plan of action was:
1) commit 3.3.1 to pristine-tar
2) commit the changes of 3.3.1-1.1 of master on the correct place,
rewriting git history[1]
3) confirm that both the tags debian/3.3.1-1 and debian/3.3.1-1.1
builds correclty

The main problem is on the first step, I described the whole plan in case
anybody has a different suggestion on how to fix this but nonetheless I
would like to at least understand what is going on with pristine-tar:

First plan was to import the github tarball of the 3.3.1 release:
wget https://github.com/Supervisor/supervisor/archive/3.3.1.tar.gz -O \
supervisor_3.3.1.orig.tar.gz
gbp clone g...@salsa.debian.org:debian/supervisor.git
cd supervisor
git checkout pristine-tar
pristine-tar commit ../supervisor_3.3.1.orig.tar.gz
c9265954ea25e0b23ada7f613989d3d41d85c93a
git checkout debian/3.3.1-1
gbp buildpackage --git-builder=sbuild -A -v -d unstable

And I end up with:
dpkg-source: error: aborting due to unexpected upstream changes
With a list of files that were modified.

So this leads me to think: Ok, that is not the correct tarball used by
the previous maintainer, so it must be either the files on the
upstream branch (since I'm passing the commit hash of upstream/3.3.1
to pristine-tar) or the ones on the master branch (excluding the
debian dir):
gbp clone g...@salsa.debian.org:debian/supervisor.git
cd supervisor
git checkout upstream/3.3.1
tar -zcvf ../supervisor_3.3.1.orig.tar.gz *
git checkout pristine-tar
pristine-tar commit ../supervisor_3.3.1.orig.tar.gz
c9265954ea25e0b23ada7f613989d3d41d85c93a
git checkout debian/3.3.1-1
gbp buildpackage --git-builder=sbuild -A -v -d unstable

Result:
gbp:error: Pristine-tar couldn't verify
"supervisor_3.3.1.orig.tar.gz": pristine-tar:
/tmp/build-area/supervisor_3.3.1.orig.tar.gz does not match stored
hash (expected 85eda4f053d2ef6c19a4b33fbf5c9fe7d8dfc24fabf7bc4067707ec841d6d30c,
got 454f532fae5a54363838fba42bc568f7b2fd0fd71d946b8c39d848a225d0da0f)

Ok, so this is strange, the sha256sum of the GH tarball is the second
one showed on the error, so this means that I should have committed
that tarball instead, and the error says "expected" from a POV where
it expects the upstream code[2] to be equal of the pristine-tar files
(and not the other way around), let's at least check the sha256sum of
the files on the master branch (excluding the debian dir):
gbp clone g...@salsa.debian.org:debian/supervisor.git
cd supervisor
git checkout debian/3.3.1-1
tar --exclude='debian' -zcvf ../supervisor_3.3.1.orig.tar.gz *
sha256sum ../supervisor_3.3.1.orig.tar.gz

Result:
74cc1931e2ab8c90a7ff980c71f408a2f43be3449f927b2f724f78ea1feabbd1
../supervisor_3.3.1.orig.tar.gz

Which is again different of the sha256sum of the tarball I created
from the upstream/3.3.1 tag.

All of this makes me think that I'm missing something very crucial
here, the possibilities I can think are:
* I should not assume that the contents of upstream and master branch
should be the same (even when using 3.0 quilt sources format)
* I'm doing something wrong when generating the tarballs of the
upstream and master branch, I highly believe this is one of the
problems
* I should not assume that if the hash of a tarball being equal as the
one which Pristine-tar expects to is the correct one, because I
received that errors when committing the tarball from GH and it looks
like it's the one which pristine-tar doesn't complain of hash
mismatch.

I know that this a very long email, so I appreciate your attention, I
hope I described this in an understandable way.
I would be glad to receive either explanations on what I'm missing
here on the way things should work, the list of commands I should run
in order to fix the repository, or any pointers towards documentations
I should read to understand what is happening.

[0]Previous maintainer ack'ed, the repo is:
https://salsa.debian.org/debian/supervisor
[1]This should not be a problem since this is gonna be the first
release of the package under salsa and AFAIK we are the only ones
working on it, also, the changes of 3.3.1-1.1 should not break the
next commits since it only introduces a new patch:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870187
[2]Since both the tarballs I generated from the upstream and master
branch does not have the second