Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage

[Tomasz Buchert]

On 04/04/24 21:36, Salvatore Bonaccorso wrote:
> Source: nghttp2
> Version: 1.60.0-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for nghttp2.
> 
> CVE-2024-28182[0]:
> | nghttp2 is an implementation of the Hypertext Transfer Protocol
> | version 2 in C. The nghttp2 library prior to version 1.61.0 keeps
> | reading the unbounded number of HTTP/2 CONTINUATION frames even
> | after a stream is reset to keep HPACK context in sync.  This causes
> | excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0
> | mitigates this vulnerability by limiting the number of CONTINUATION
> | frames it accepts per stream. There is no workaround for this
> | vulnerability.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2024-28182
> https://www.cve.org/CVERecord?id=CVE-2024-28182
> [1] https://github.com/nghttp2/nghttp2/security/advisories/GHSA-x6x3-gv8h-m57q
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore

As the first measure I uploaded 1.61.0-1 to unstable with urgency=high.

Looking into older versions and appropriately patching them will take more time.

Tomasz

Bug#1068177: lintian: unpack-message-for-orig due to readelf failing on python-pyelftools 0.31

[Tomasz Buchert]

Package: lintian
Version: 2.117.0
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 I'm packaging python-pyelftools 0.31 and lintian fails due to files
 used for testing, because of non-utf8 characters.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

 I followed the usual process of importing a new upstream version.
 I uploaded the packaging state to https://salsa.debian.org/debian/python-
pyelftools.

   * What was the outcome of this action?

 The build succeeds, but the subsequent lintian run fails with:

 E: python-pyelftools source: unpack-message-for-orig python-
pyelftools_0.31.orig.tar.gz . Output from 'readelf --all --wide
pyelftools-0.31/test/testfiles_for_unittests/dwarf_phantombytes.elf' is not
valid UTF-8

   * What outcome did you expect instead?

 I'm not sure: either lintian wouldn't care whether output is utf-8
 or perhaps readelf shouldn't emit 8-bit characters.


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

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.42-4
ii  bzip2   1.0.8-5.1
ii  diffstat1.66-1
ii  dpkg1.22.4
ii  dpkg-dev1.22.4
ii  file1:5.45-2+b1
ii  gettext 0.21-14+b1
ii  gpg 2.2.40-1.1+b1
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b3
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b2
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b2
ii  libclone-perl   0.46-1+b1
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.37-1+b1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.83-2+b2
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.4
ii  libemail-address-xs-perl1.05-1+b2
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.144-1
ii  libperlio-gzip-perl 0.20-1+b2
ii  libperlio-utf8-strict-perl  0.010-1+b1
ii  libproc-processtable-perl   0.636-1+b1
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b1
ii  libsereal-encoder-perl  5.004+ds-1+b1
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-1+b1
ii  libterm-readkey-perl2.38-2+b2
ii  libtext-levenshteinxs-perl  0.03-5+b2
ii  libtext-markdown-discount-perl  0.16-1+b1
ii  libtext-xslate-perl 3.5.9-1+b3
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b2
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b1
ii  liburi-perl 5.27-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.77-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1+b2
ii  libyaml-libyaml-perl0.89+ds-1
ii  lzip [lzip-decompressor]1.24.1-1
ii  lzop1.04-2
ii  man-db  2.12.0-3
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-3
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.6.1+really5.4.5-1

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.61-1

-- no debconf information

Bug#1042837: Acknowledgement (signify-openbsd: Embedding signature in gz header does not work)

[Tomasz Buchert]

On 05/11/23 14:46, Nikolaus Rath wrote:
> Hi Thomas,
> 
> On Sun, 5 Nov 2023, at 14:19, Tomasz Buchert wrote:
> > On 01/08/23 17:15, Nikolaus Rath wrote:
> >> Using -x instead of -m when verifying gives "interesting" output:
> >> 
> >> $ signify-openbsd -Vz -p s3ql-5.0.pub -x signed.gz
> >> untrusted comment: verify with s3ql-5.0.pub
> >> RWSKPEtoJRYfrolP1xcoVCAxdIGvBp+I600+z5r4Ckcknx45J4pGrYvhlrWn6WTtwom7mTyjT7epM/oQyhfn/UbuKTR7pjN+0g0=
> >> date=2023-08-01T16:10:04Z
> >> key=s3ql-5.0.sec
> >> algorithm=SHA512/256
> >> blocksize=65536
> >> 
> >> 05b894ec8534324eda46e2c71b2e9cd8c3e6f89432d222d06949076bc5236998
> >> Ke2~⏎  
> >>  
> >> 
> >> This terminates with exit code 0... but somehow I'm not convinced that 
> >> signify did the right thing here.
> >> 
> >
> > I checked that signify puts the FCOMMENT section (from RFC) with 
> > the signature and a bunch of other things at the preamble of the
> > signed gz file. The comment ends just after what looks like SHA256,
> > which is then followed by the binary data. The binary data is
> > identical to the main compressed data of the original file.
> >
> > In fact, it seems that the verification of gz files actually just
> > passes through the whole file. The man page implies that:
> >
> >   Verify a gzip pipeline:
> >  $ ftp url | signify-openbsd -Vz -t arc | tar ztf -
> >
> > The behavior seems then intended, but maybe it's not documented enough?
> 
> Sorry, I don't quite follow. The behavior of printing binary garbage to 
> stdout is intended?
> 
> 
> Best,
> -Niko

Hey,

the "binary garbage" you see is actually the exact contents of the gz file for 
which you verify. See:

[ ~/test ] $ cat out.gz | signify-openbsd -Vz -p ~/.ssh/signify.pub | cat > x
[ ~/test ] $ diff x out.gz 

(i.e., out.gz and the output of signify are exactly the same)

This allows to use it cleanly in the shell pipelines as is shown in the manpage.

I think the request in this bug could be to have an option to verify the
signify-signed gz file WITHOUT printing out the gz file to stdout?

Does it make sense?

Tomasz


signature.asc
Description: PGP signature

Bug#1042837: Acknowledgement (signify-openbsd: Embedding signature in gz header does not work)

[Tomasz Buchert]

On 01/08/23 17:15, Nikolaus Rath wrote:
> Using -x instead of -m when verifying gives "interesting" output:
> 
> $ signify-openbsd -Vz -p s3ql-5.0.pub -x signed.gz
> untrusted comment: verify with s3ql-5.0.pub
> RWSKPEtoJRYfrolP1xcoVCAxdIGvBp+I600+z5r4Ckcknx45J4pGrYvhlrWn6WTtwom7mTyjT7epM/oQyhfn/UbuKTR7pjN+0g0=
> date=2023-08-01T16:10:04Z
> key=s3ql-5.0.sec
> algorithm=SHA512/256
> blocksize=65536
> 
> 05b894ec8534324eda46e2c71b2e9cd8c3e6f89432d222d06949076bc5236998
> Ke2~⏎ 
>   
> 
> This terminates with exit code 0... but somehow I'm not convinced that 
> signify did the right thing here.
> 
> Best,
> -Nikolaus
> 

Hey Nikolaus,

I checked that signify puts the FCOMMENT section (from RFC) with 
the signature and a bunch of other things at the preamble of the
signed gz file. The comment ends just after what looks like SHA256,
which is then followed by the binary data. The binary data is
identical to the main compressed data of the original file.

In fact, it seems that the verification of gz files actually just
passes through the whole file. The man page implies that:

  Verify a gzip pipeline:
 $ ftp url | signify-openbsd -Vz -t arc | tar ztf -

The behavior seems then intended, but maybe it's not documented enough?

Cheers,
Tomasz

Bug#1022093: git repo

[Tomasz Buchert]

The package is packaged under https://salsa.debian.org/debian/libqt5qxlsx.


signature.asc
Description: PGP signature

Bug#1022093: ITP: libqt5qxlsx -- Excel file (*.xlsx) reader/writer library for Qt5.

[Tomasz Buchert]

Package: wnpp
Severity: wishlist
Owner: Tomasz Buchert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libqt5qxlsx
  Version : 1.4.4
  Upstream Author : Daniel Nicoletti
* URL : https://github.com/dantti/QXlsx
* License : Expat/MIT
  Programming Lang: C++
  Description : Excel file (*.xlsx) reader/writer library for Qt5.

QXlsx is excel file (*.xlsx) reader/writer library.

We need this package as a new dependency of stellarium, see
https://salsa.debian.org/debian-astro-team/stellarium.

Bug#982882: stellarium FTBFS on armel and mipsel

[Tomasz Buchert]

On 15/02/21 20:54, Paul Gevers wrote:
> Source: stellarium
> Version: 0.20.4-1
> Severity: serious
> Tags: ftbfs
>
> [...]

Seems like it is
https://github.com/Stellarium/stellarium/issues/1131. This has been
solved with https://bugreports.qt.io/browse/QTBUG-87010.

Surprisingly, the fix is not in qtbase-opensource-src-5.15.2+dfsg. I'm
not sure why, it seems like the fix was intended to land there.

I think I can work around this by probably removing parallelism in the
build process. I'll see if that works.


signature.asc
Description: PGP signature

Bug#977782: buster-pu: package postsrsd/1.5-2

[Tomasz Buchert]

On 31/01/21 11:08, Salvatore Bonaccorso wrote:
> Hi Oxan,
>
> On Sat, Jan 30, 2021 at 09:58:23PM +0100, Oxan van Leeuwen wrote:
> > Hi,
> >
> > On 30-01-2021 21:27, Salvatore Bonaccorso wrote:
> > > I noticed that today there was an upload to security-master for it.
> > > Given our previous discussion, was this an oversight? I just have
> > > rejected the package, could you please upload it for the upcoming
> > > point release instead to ftp-master?
> >
> > Ah, that wasn't the intention.
> >
> > @Tomasz: it seems you accidentally uploaded to the security archive tonight.
> > The last commit in the buster branch on Salsa should be for an upload the
> > regular archive, maybe you forgot to pull? In any case, can you please
> > upload that one? Thanks!
>
> Thanks for clarification! If possible please do upload this weekend,
> because the uploading window for packages to enter the 10.8 point
> release would end tonight.
>
> Many thanks for your work!
>
> Regards,
> Salvatore

Oh, as usual, I messed it up. :|
Ok, now uploaded directly to buster (and with a proper e-mail of Oxan).

Let me know if that's better!
Tomasz


signature.asc
Description: PGP signature

Bug#918938: fasm: source contains executables fasm.x64 and fasm

[Tomasz Buchert]

On 11/01/19 10:07, Santiago Vila wrote:
> On Fri, Jan 11, 2019 at 09:48:44AM +0100, Tomasz Buchert wrote:
>
> > they are there, because upstream uses this to also release new versions.
> > An unfortunately, in the past my upstream wasn't very responsive.
> >
> > I used the fasm binary in the first upload to bootstrap everything.  I
> > can repack the source, but since I never use these binaries, I don't
> > think it is such a big deal (and I dislike repackaging in general as
> > this replaces one problem (binary files) with with a different
> > security problem (original tarballs are tampered with)).
> >
> > Let me know what you think.
>
> I could understand the small benefit of being able to verify more
> easily that the source is the original from upstream, but I also
> believe they should not be there as a matter of principles, i.e.
> source is source and binaries are binaries.
>
> So, as a compromise, I would suggest at least forwarding the bug
> upstream and keeping it open until upstream removes the binaries
> himself.
>
> Thanks.

Putting aside lack of upstream bug tracking and general lack of
responsiveness, mind you that fasm is an assembler which needs
bootstrapping. Even if Debian has the fasm package prebuilt (after me
bootstrapping it in the first two uploads), it would be a bit
unreasonable to expect upstream to cater to such scenario given that
there are way more linux distributions around and fasm is not as
commonly available as a C compiler, for example.

https://lintian.debian.org/tags/source-contains-prebuilt-binary.html
mentions that "You may want to report this as an upstream bug, in case
there is no sign that this was intended.", but this is intended.

Given above I'm going to tentatively close it. Feel free to reopen if
you disagree.


signature.asc
Description: PGP signature

Bug#947716: RFH: terminator -- multiple GNOME terminals in one window

[Tomasz Buchert]

On 30/12/19 01:49, Lucas Nussbaum wrote:
> Hi Markus,
>
> On 29/12/19 at 13:59 +0100, Markus Frosch wrote:
> > I request assistance with maintaining the terminator package. [1]
> >
> > The upstream seems pretty much dead, though I'd like the keep the
> > package available. Popcon [2] is not too bad, and I think usage on
> > Ubuntu is also pretty stable (I know a lot of people).
>
> I'm a happy user of terminator, and I'm surprised to learn that it's
> dead upstream. What do people use instead?
>
> (I'm unlikely to have time to help, unfortunately)
>
> Lucas

Hi Lucas,

I've recently switched to kitty [1]. It has everything that terminator
has and more :).

Tomasz

[1] https://packages.debian.org/sid/kitty


signature.asc
Description: PGP signature

Bug#872960: Actualy...

[Tomasz Buchert]

I once again cannot reproduce this.


signature.asc
Description: PGP signature

Bug#937051: mininet: Python2 removal in sid/bullseye

[Tomasz Buchert]

Thanks,
upstream claims that mininet is python3-compatible in master [1].

I'll try to make the package stop using python2.

[1] https://github.com/mininet/mininet/issues/898


signature.asc
Description: PGP signature

Bug#958794: lintian: runtime-test-file-uses-supported-python-versions-without-python-all-build-depends fires with

[Tomasz Buchert]

Package: lintian
Version: 2.66.0
Severity: normal

Dear Maintainer,

when preparing upload of brotli, lintian issues a warning runtime-test-file-
uses-supported-python-versions-without-python-all-build-depends.

I've tried to fix it by adding python-all:any, but in the end I believe the
issue is caused by  in the control file [1].

Cheers,
Tomasz

[1] https://salsa.debian.org/debian/brotli/-/blob/84db8c2d/debian/control#L11



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

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils 2.34-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-4
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  libjson-maybexs-perl 1.004000-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3200-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.81+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.0-10
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
ii  binutils-multiarch 2.34-5
ii  libtext-template-perl  1.58-1

-- no debconf information

Bug#940986: duplicity: sh_pexpect_backend.py fails to byte-compile during installation

[Tomasz Buchert]

Package: duplicity
Version: 0.8.04-1
Severity: normal

Dear Maintainer,
the version 0.8.04-1 of duplicity fails to pypy3compile ssh_pexpect_backend.py
during installation with the following message:

Setting up duplicity (0.8.04-1) ...
-V is ignored in pypy3compile
Failed to byte-compile /usr/lib/python3/dist-
packages/duplicity/backends/ssh_pexpect_backend.py:   File "/usr/lib/pyth
on3/dist-packages/duplicity/backends/ssh_pexpect_backend.py", line 52
global pexpect
^
SyntaxError: name 'pexpect' is assigned to before global declaration

==

AFAICT, this does not break duplicity in general, but I'd expect that the
pexpect backend may be broken.



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

Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages duplicity depends on:
ii  gnupg  2.2.17-3
ii  libc6  2.29-1
ii  librsync2  2.0.2-1
ii  python33.7.3-1
ii  python3-fasteners  0.12.0-5
ii  python3-future 0.16.0-1
ii  python3-lockfile   1:0.12.2-2

Versions of packages duplicity recommends:
ii  python3-oauthlib  2.1.0-1
ii  python3-paramiko  2.6.0-1
ii  python3-pexpect   4.6.0-1
ii  python3-urllib3   1.24.1-1
ii  rsync 3.1.3-6+b1

Versions of packages duplicity suggests:
pn  lftp 
pn  ncftp
pn  par2 
ii  python3-boto 2.49.0-2
ii  python3-pip  18.1-5
pn  python3-swiftclient  
pn  tahoe-lafs   

-- no debconf information

Bug#934762: new upstream (1.39.2)

[Tomasz Buchert]

On 14/08/19 16:46, Daniel Baumann wrote:
> Package: nghttp2
> Severity: normal
>
> Hi,
>
> 1.39.2 was released with some DoS fixed. It would be nice if you could
> upload it to unstable.
>
> Regards,
> Daniel

Oh, sorry, I forgot to reupload to unstable.
Working on this.

Tomasz


signature.asc
Description: PGP signature

Bug#933400: signify-openbsd FTCBFS: uses the build architecture pkg-config

[Tomasz Buchert]

On 30/07/19 13:15, Helmut Grohne wrote:
> [...]

Thanks, Helmut!

I adapted your patch and uploaded a new version just now.  I'll just
mention that all my packages are hosted on salsa, so it may be easier,
workflow-wise, to do a pull request there :).


signature.asc
Description: PGP signature

Bug#933182: python-boto: upadting to 2.49.0-2 causes CERTIFICATE_VERIFY_FAILED with duplicity

[Tomasz Buchert]

Package: python-boto
Version: 2.44.0-1.1
Severity: important

Dear Maintainer,
calling duplicity (with google cloud as the backend) with 2.49.0-2 hangs for a
moment and fails with CERTIFICATE_VERIFY_FAILED (similarly too
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909545).

Downgrading to 2.44.0-1.1 fixes the issue.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-boto depends on:
ii  python   2.7.16-1
ii  python-requests  2.21.0-1
ii  python-six   1.12.0-1

python-boto recommends no packages.

python-boto suggests no packages.

-- no debconf information

Bug#920988: please consider dropping SPDY support

[Tomasz Buchert]

On 31/01/19 12:23, Andrej Shadura wrote:
> Package: nghttp2
> Severity: wishlist
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Dear Maintainer,
>
> With HTTP/2 having been finalised, SPDY has been deprecated three years
> ago, and none of the modern browsers support it anymore. On the other
> hand, the spdylay package, which provides SPDY support in nghttp2, has
> been orphaned both upstream and in Debian.
>
> Please consider disabling SPDY support and removing the build dependency
> om libspdylay-dev.
>
> Thanks.
>
> --
> Cheers,
> Andrej

Hey Andrej,
do you think it should be resolved before buster?

Tomasz


signature.asc
Description: PGP signature

Bug#902115: Fails to handle file names containing '\x2'

[Tomasz Buchert]

On 23/01/19 14:54, Chris Lamb wrote:
> retitle 902115 Fails to handle file names containing '\x2'
> tags 902115 + patch
> thanks
>
> Hi,
>
> > Fails to handle file names containing '\x2'
>
> Patch attached with (minimised) testcase. I can confirm this
> successfully re-generates:
>
>   8803baa484cbe36680463c8c5e6febeff074b8e7  
> /tmp/buildd/systemd_239.orig.tar.gz
>
>
> Regards,

Thanks Chris!
Uploading a new release just now!


signature.asc
Description: PGP signature

Bug#918931: fasm: FTBFS because it build-depends on itself and the current version lacks /usr/bin/fasm

[Tomasz Buchert]

On 10/01/19 22:00, Santiago Vila wrote:
> tags 918931 + patch
> thanks
>
> Hi. This is a hack but I think it should work.
> (Rebootstrapping anything is always hacky after all).
>
> [...]

I've just sent a version reboostrapping itself. After that I will make
sure to upload it again.

Thanks,
Tomasz


signature.asc
Description: PGP signature

Bug#918936: fasm: Does not trap for errors in debian/rules

[Tomasz Buchert]

On 10/01/19 18:05, Santiago Vila wrote:
> ...

Oh, and fasm cannot be built by anything else than fasm as it is its
own dialect of assembler.


signature.asc
Description: PGP signature

Bug#918936: fasm: Does not trap for errors in debian/rules

[Tomasz Buchert]

On 10/01/19 18:05, Santiago Vila wrote:
> Package: src:fasm
> Version: 1.73.06-1
> Severity: serious
> Tags: patch
>
> Dear maintainer:
>
> Commands in a Makefile should be chained with "&&" so that the first
> thing which fails makes the whole process to stop.
>
> This is Policy 4.6, "error trapping in makefiles", and it's usually considered
> a serious issue:
>
> https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles
>
> Proposed patch below.
>
> Unfortunately, the patch will not make the package to build again and
> it needs to be "bootstrapped" again (my theory is that the package was 
> misbuilt
> the last time because of this, but I'm not completely sure).
>
> Would not be possible to build the program using the standard assembler?
> I would do that if possible, that way we could eliminate the
> build-dependency on itself.
>
> Thanks.
>
> --- a/debian/rules
> +++ b/debian/rules
> @@ -8,7 +8,7 @@ include /usr/share/dpkg/default.mk
>
>  override_dh_install:
>   mkdir -p debian/tmp
> - (cd source/libc; fasm fasm.asm; gcc $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) 
> -m32 fasm.o -o fasm)
> + cd source/libc && fasm fasm.asm && gcc $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) 
> -m32 fasm.o -o fasm
>
>  override_dh_clean:
>   dh_clean

Oh... I removed dh_install from the override in
https://salsa.debian.org/debian/fasm/commit/390c9ea515e788c5bf422fa3b5ba99a64f3caf5f.
Stupid me!

Ok, let's reboostrap the whole thing.


signature.asc
Description: PGP signature

Bug#918938: fasm: source contains executables fasm.x64 and fasm

[Tomasz Buchert]

On 10/01/19 18:10, Santiago Vila wrote:
> Package: src:fasm
> Version: 1.73.06-1
> Tags: upstream
>
> Dear maintainer:
>
> The source for this package contains two ELF binaries that should
> probably not be there. It is usual and customary to repack the source
> and exclude them. (If you could convince upstream to do so, even better).
>
> Thanks.

Hey Santiago,
they are there, because upstream uses this to also release new versions.
An unfortunately, in the past my upstream wasn't very responsive.

I used the fasm binary in the first upload to bootstrap everything.  I
can repack the source, but since I never use these binaries, I don't
think it is such a big deal (and I dislike repackaging in general as
this replaces one problem (binary files) with with a different
security problem (original tarballs are tampered with)).

Let me know what you think.
Tomasz


signature.asc
Description: PGP signature

Bug#907524: Support for python 2.7

[Tomasz Buchert]

On 28/08/18 21:55, Luciano Bello wrote:
> Source: python-guess-language
> Version: 0.5.2-4
> Severity: normal
> Tags: patch upstream
>
> In an attempt to put w3af back into sid, we need support for Python 2 in
> guess-language. I opened a PR into upstream with it. Please, take a look
> https://bitbucket.org/spirit/guess_language/pull-requests/3/python-27-support/diff
>
> It would be great if you can add it.
>
> Cheers, luciano

Thanks Luciano,

would it be possible to create an official release/download on
bitbucket so that I can pull it? Otherwise I will have to import a
semi-random git hash.

Tomasz


signature.asc
Description: PGP signature

Bug#905290: verbiste-el: fix emacsen-common-without-dh-elpa

[Tomasz Buchert]

On 24/08/18 16:36, Nicholas D Steeves wrote:
> Dear Tomasz,
>
> On Thu, Aug 02, 2018 at 11:34:31PM +0800, Tomasz Buchert wrote:
> > Package: verbiste-el
> > Severity: normal
> >
> > Dear Maintainer,
> > lintian reports emacsen-common-without-dh-elpa on the verbiste-el package.
> > Please fix it.
>
> I've taken care of this bug.  Please merge the following PR:
>   https://salsa.debian.org/debian/verbiste/merge_requests/1/
>
> Piuparts look good and I believe that a "dch -r" will add the correct
> header above my changes.
>
> Cheers,
> Nicholas

Awesome job, Nicholas!

I've uploaded the package to unstable. It will hit NEW due to the new
elpa package, but otherwise I don't expect any problems.

Thanks again,
Tomasz


signature.asc
Description: PGP signature

Bug#877711: Latest upstream firmware resolves this issue

[Tomasz Buchert]

On 24/10/17 14:41, Andrew McMillan wrote:
> Hi,
>
> I can confirm that Brian Tarricone's solution also works for me, and
> the latest firmware resolves the issue:
>
>
> I.e. this commit from the 9th October:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware
> .git/commit/ath10k/QCA6174/hw3.0?id=96a7402d4172f4786ee93dd9f7cb3f76e1a
> 8025e
>
> "Update from a new firmware branch. This also fixes a regression with
> ath10k frequently disconnecting."
>
>
> Thanks,
> Andrew McMillan.

If you don't want to do manual changes to your firmware files,
consider installing firmware-atheros from buster [1].

Tomasz

[1] https://packages.debian.org/buster/firmware-atheros


signature.asc
Description: PGP signature

Bug#868409: verbiste: Please drop the (build-)dependency against gnome-vfs

[Tomasz Buchert]

On 27/07/18 13:04, Nicholas D Steeves wrote:
> [...]

Hey all,
sorry for extremely long lag in fixing this...

Anyway, I went with Nicholas' suggestion and added verbiste-gtk,
whereas verbiste-gnome is now transitional. Feel free to review it:
https://salsa.debian.org/debian/verbiste

As for verbiste-el, I've created https://bugs.debian.org/905290. I'd
actually ask for help with this, I'm pretty bad at emacs
packaging. Pull requests are welcome! :D

Tomasz


signature.asc
Description: PGP signature

Bug#905290: verbiste-el: fix emacsen-common-without-dh-elpa

[Tomasz Buchert]

Package: verbiste-el
Severity: normal

Dear Maintainer,
lintian reports emacsen-common-without-dh-elpa on the verbiste-el package.
Please fix it.



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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages verbiste-el depends on:
ii  emacsen-common  2.0.8
ii  verbiste0.1.45-2

Versions of packages verbiste-el recommends:
ii  emacs24 [emacsen]  24.5+1-11
ii  emacs25 [emacsen]  25.2+1-6+b3

verbiste-el suggests no packages.

Bug#905097: signing-party: gpglist crashes for (some?) signature revocations

[Tomasz Buchert]

On 31/07/18 17:44, Guilhem Moulin wrote:
> Control: tag -1 pending
>
> On Tue, 31 Jul 2018 at 16:42:36 +0800, Tomasz Buchert wrote:
> > I already committed a fix in 
> > https://salsa.debian.org/debian/signing-party/commit/c62477e3086c33af14493337227ec219f151d5b4.
>
> I pushed a fix to upstream/latest last week
> https://salsa.debian.org/debian/signing-party/commit/ea3e3b52e308f36e9691c993c24b9100e8455811
> Just merged upstream/latest to debian/master and force-pushed the latter :-P

Oh, sorry for that.

> Unfortunately it's not the first time people push changes to the default
> (debian/master) branch, while I want the non-debian specific bits to
> live on upstream/latest.  I thus changed the permissions so non project
> owners are not allowed to push to these two branches. :-P  Patches are
> still welcome, though!
>
> > I should also propose to use the colon format correctly, not with regexpes. 
> > :)
>
> AFAICT we were parsing it correctly.  GnuPG <2.2.9 colon format for
> field 11 was:
>
> | Signature class as per RFC-4880.  This is a 2 digit hexnumber
> | followed by either the letter 'x' for an exportable signature or
> | the letter 'l' for a local-only signature.  The class byte of an
> | revocation key is also given here, 'x' and 'l' is used the same
> | way.  This field if not used for X.509.
>
> Since 2.2.9 (released on July 12) the following was added:
>
> | "rev" and "rvs" may be followed by a comma and a 2 digit hexnumber
> | with the revocation reason.
>
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blobdiff;f=doc/DETAILS;h=eb6d7dd4b622027b30b3aecb94ce147c84fc9125;hp=1bfc04dd573ce46df21a1bfd36ff42d4badf5e1a;hb=b7cd2c2093ae1b47645be50fa1d431a028187cad;hpb=386b9c4f25b28fd769d7563f2d86ac3a19cc3011
>
> That change breaks strict parsers.
> --
> Guilhem.

The DETAILS file also mentions to ignore fields that are not used. The
current regexp based approach should be replaced with
splitting-by-colon-and-fetching-necessary-index.

Just saying :).
Tomasz


signature.asc
Description: PGP signature

Bug#905097: signing-party: gpglist crashes for (some?) signature revocations

[Tomasz Buchert]

Package: signing-party
Version: 2.7-2
Severity: normal

Dear Maintainer,
'rev' packet parsing is incorrect and may result in:

  hi, i'm a bug. please report me to my owner
  input: rev:::1:HASH:1533019781User Example
:30x,00::HASH:::10:, key: user@example at /usr/bin/gpglist line
165, <$fh> line 5.

The problem is with ',00' just after '30x' which is not accounted for.

I already committed a fix in https://salsa.debian.org/debian/signing-
party/commit/c62477e3086c33af14493337227ec219f151d5b4.

I should also propose to use the colon format correctly, not with regexpes. :)

Tomasz



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

Kernel: Linux 4.17.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages signing-party depends on:
ii  gnupg  2.2.9-1
ii  libc6  2.27-5
ii  libclass-methodmaker-perl  2.24-1+b4
ii  libgnupg-interface-perl0.52-10
ii  libmailtools-perl  2.18-1
ii  libmd0 1.0.0-1
ii  libmime-tools-perl 5.509-1
ii  libnet-idn-encode-perl 2.400-1+b2
ii  libterm-readkey-perl   2.37-1+b2
ii  libtext-template-perl  1.53-1
ii  perl   5.26.2-6
ii  python 2.7.15-3
ii  qprint 1.1.dfsg.2-2+b1

Versions of packages signing-party recommends:
ii  dialog  1.3-20171209-1+b1
ii  libgd-perl [libgd-gd2-perl] 2.66-1+b2
ii  libpaper-utils  1.1.24+nmu5
ii  postfix [mail-transport-agent]  3.3.0-1+b1
ii  whiptail0.52.20-5

Versions of packages signing-party suggests:
pn  fonts-noto-cjk   
ii  fonts-noto-mono  20171026-2
ii  imagemagick  8:6.9.10.2+dfsg-3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.2+dfsg-3
ii  mutt 1.10.1-1
ii  qrencode 3.4.4-1+b2
pn  texlive-font-utils   
ii  texlive-latex-extra  2018.20180505-1
ii  texlive-latex-recommended2018.20180505-1
ii  texlive-xetex2018.20180505-1
pn  wipe 

-- no debconf information

Bug#901952: new info

[Tomasz Buchert]

Control: reassign 901952 tar 1.30+dfsg-1

On 26/06/18 20:23, Tomasz Buchert wrote:
> On 20/06/18 21:18, Hans-Christoph Steiner wrote:
> >
> > [...]
>
> This seems to be a regression caused by tar.
>
> I can successfully checkout the tarball, but with the version tar_1.29b-2.
> When I install tar_1.30+dfsg-1, I cannot checkout anymore.
>
> I guess we'll need to find the real cause in tar then.

I believe I have a repro case extracted from this bug report showing
that #897653 was not actually fixed. It can be downloaded from:
http://ivyzdokx5queplps.onion/repro.tar.xz

It has a number of files generated with tar 1.30, with all
combinations of reproducibility related flags and none of them
reproduces the tarball produced by the version 1.29.

I'm reassigning this to tar.


signature.asc
Description: PGP signature

Bug#901952: new info

[Tomasz Buchert]

On 20/06/18 21:18, Hans-Christoph Steiner wrote:
>
> [...]

This seems to be a regression caused by tar.

I can successfully checkout the tarball, but with the version tar_1.29b-2.
When I install tar_1.30+dfsg-1, I cannot checkout anymore.

I guess we'll need to find the real cause in tar then.


signature.asc
Description: PGP signature

Bug#889700: mininet: Missing test dependency on openvswitch-switch

[Tomasz Buchert]

On 05/02/18 23:34, Steve Langasek wrote:
> [...]

Oh, sorry for that. I wasn't happy in the past that ci.debian does not
support machine-isolation and now it strikes back.

Thanks for the patch, I'll upload the new release soon.

Tomasz


signature.asc
Description: PGP signature

Bug#812810: fill-paragraph: Leaves a space at the end of the paragraph

[Tomasz Buchert]

On 12/04/16 06:27, Mark Lumsden wrote:
> Hi, I just committed a fix for 812810 in the OpenBSD source tree in
> version 1.43 of paragraph.c.

(Very late) thanks!

I'm closing this bug, since this was probably solved many releases
ago.  Specifically, I think it was solved with 20160421-1.


signature.asc
Description: PGP signature

Bug#885411: python-pyelftools: Please mark python*-pyelftools as Multi-Arch: foreign

[Tomasz Buchert]

On 26/12/17 12:37, Vagrant Cascadian wrote:
> Package: python-pyelftools
> Version: 0.24-3
> Severity: normal
> Tags: patch
>
> Please mark python-pyelftools and python3-pyelftools as "Multi-Arch:
> foreign", so that it can be used to satisfy build-dependencies when
> cross-building packages.
>
>   
> https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages
>
>
> live well,
>   vagrant

Thanks Vagrant,
I wonder why I've changed Architecture to 'all' from 'any' at some point [1].
Would you happen to know and/or maybe we would switch back to any?

Cheers,
Tomasz

[1] 
https://salsa.debian.org/debian/python-pyelftools/commit/f3808d3069e14a1f0dc54acead4b89a34e15cc8c

signature.asc
Description: PGP signature

Bug#888950: brotli: Use dh_missing --fail-missing

[Tomasz Buchert]

On 31/01/18 21:37, Jeremy Bicha wrote:
> On Wed, Jan 31, 2018 at 5:56 PM, Tomasz Buchert <tom...@debian.org> wrote:
> > Both bugs you reported will be fixed in the next upload.
>
> Thanks.
>
> By the way, your debian/changelog says you bumped the debhelper compat
> to 11, but that didn't happen in your git repo.
>
> Jeremy Bicha

Yeah, sorry.

I first bumped the compat level and update the changelog, but then
thought that maybe you actually really on the version 10.3 of
debhelper, so I reverted my change ... without reverting the
changelog.

Tomasz


signature.asc
Description: PGP signature

Bug#888950: brotli: Use dh_missing --fail-missing

[Tomasz Buchert]

On 31/01/18 09:30, Jeremy Bicha wrote:
>  [...]

Thanks Jeremy!
Both bugs you reported will be fixed in the next upload.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#886108: debhelper: dh_installdocs -A at compat=11 installs docs in wrong place

[Tomasz Buchert]

On 02/01/18 12:28, Tomasz Buchert wrote:
> [...]

For repro case, see:

   
https://anonscm.debian.org/cgit/collab-maint/nghttp2.git/commit/?id=3980b752463f2ab67a3fcd0712d9f060b721999f

I worked around the problem by not installing the docs in libnghttp2-doc:

   
https://anonscm.debian.org/cgit/collab-maint/nghttp2.git/commit/?id=2e9b83fc808b905041d7ed68b5069d7788caa43d

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#886108: debhelper: dh_installdocs -A at compat=11 installs docs in wrong place

[Tomasz Buchert]

Package: debhelper
Version: 11
Severity: normal

Dear Maintainer,

I wanted to switch nghttp2 to compat=11, but this causes binaries-have-file-
conflict:

W: nghttp2 source: binaries-have-file-conflict libnghttp2-dev libnghttp2-doc
usr/share/doc/libnghttp2-dev/AUTHORS
W: nghttp2 source: binaries-have-file-conflict libnghttp2-dev libnghttp2-doc
usr/share/doc/libnghttp2-dev/README.rst.gz

The conflicting files are installed in /usr/share/doc/libnghttp2-dev, although
the package is libnghttp2-doc.

What happens is that "dh_installdocs -A" (which I have in debian/rules) does
autodetection magic which decides to put the docs of libnghttp2-dev in
libnghttp2-doc. The culprit is the code in compute_doc_main_package which
special-cases lib/doc packages, I believe

This can be worked around by using --doc-main-package, but I think there is
something wrong happening here.



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

Kernel: Linux 4.14.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debhelper depends on:
ii  autotools-dev20171216.1
ii  binutils 2.29.1-12
ii  dh-autoreconf15
ii  dh-strip-nondeterminism  0.040-1
ii  dpkg 1.19.0.4
ii  dpkg-dev 1.19.0.4
ii  file 1:5.32-1
ii  libdpkg-perl 1.19.0.4
ii  man-db   2.7.6.1-4
ii  perl 5.26.1-3
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201701
pn  dwz  

-- no debconf information

Bug#865523: Build C library from src:brotli sources

[Tomasz Buchert]

On 07/12/17 16:34, Jeremy Bicha wrote:
> On Thu, Dec 7, 2017 at 3:34 PM, Tomasz Buchert <tom...@debian.org> wrote:
> > The new brotli with c library is in unstable. Enjoy!
>
> Thanks! By the way, I upstreamed your patch (since I had the same
> issue with my woff2 packaging).
>
> https://github.com/google/brotli/commit/63e15bb
>
> Jeremy Bicha

Oh, cool :).

Tomasz


signature.asc
Description: PGP signature

Bug#882205: Please make openvswitch-switch recommended instead hard dependency

[Tomasz Buchert]

On 20/11/17 09:48, Piotr Jurkiewicz wrote:
> Package: mininet
>
> Open vSwitch is not necessary to run Mininet. There are many use cases for
> Mininet without Open vSwitch. For example we are using it to orchestrate
> nodes running Click Modular Router or in-kernel IP forwarding (like in
> examples/linuxrouter.py).
>
> Changing openvswitch-switch to Recommends instead Depends would allow us to
> build smaller VM images and avoid manual disabling of ovs daemons after
> installation. It would still be installed by default for most users who do
> not use additional --no-install-recommends flag.
>

Yeah, you are right. It's not strictly necessary, for example one can run:

   # sudo mn --topo tree,depth=2,fanout=3 --switch=lxbr

Makes sense to me, I will upload an updated version soon.

Thanks!
Tomasz

Bug#881328: mininet requires missing ovs-controller

[Tomasz Buchert]

On 30/11/17 09:26, Santiago R.R. wrote:
> Control: tags -1 + patch fixed-upstream
>
> On Fri, 10 Nov 2017 12:15:39 +0100 "Santiago R.R."  
> wrote:
>
> It seems I am wrong about this.

The bug was only happening if you would have
openvswitch-testcontroller installed. The reason is that mininet fails
to detect the path of the test controller. The patch you provided fixes
the issue.
>
> Cheers,
>
>   -- Santiago
>
> P.S. Question for openvswitch maintainers: does it make sense to include
> back /usr/bin/ovs-testcontroller in the -testcontroller package?

Thanks, I've added the patch and will upload the package later today.

Cheers,
Tomasz

Bug#865523: Build C library from src:brotli sources

[Tomasz Buchert]

On 17/11/17 20:31, Jeremy Bicha wrote:
> Hi,
>
> I need libbrotli in order to build woff2 which will be needed for the
> next major release of webkit2gtk. Could you do this upload soon?
>
> Thanks,
> Jeremy Bicha

I was informed that the version 1.0.2 will be uploaded soon, which
will introduce a different library numbering scheme. I will upload it
asap, but it will take some time to go through experimental, though.

Tomasz


signature.asc
Description: PGP signature

Bug#870831: Broken symbols file creates broken dependencies

[Tomasz Buchert]

On 05/08/17 18:04, Stefan Fritsch wrote:
> Package: libbrotli0.6.0
> Version: 0.6.0-2~exp0
> Severity: serious
>
> I have tried to build apache2's mod_brotli with libbrotli0.6.0 /
> libbrotli-dev from experimental  But the resulting packages gets a
> dependency on the non-existing libbrotli0 (>= 0.6.0). I think the reason
> for this is that /var/lib/dpkg/info/libbrotli0.6.0:amd64.symbols
> contains
>
> libbrotlidec.so.0.6.0 libbrotli0 #MINVER#
>
> This should be libbrotli0.6.0 instead of libbrotli0.

Thank you, Stefan, I've upload a new experimental package at version
1.0.0, and with you fix. I think it is correct now, however I think
that the upstream SOVERSION is too granular and asked them to rethink
this. I'm relatively confident that polished brotli packages will
enter unstable in 2-3 weeks.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#872960: Actualy...

[Tomasz Buchert]

On 19/09/17 01:14, Tomasz Buchert wrote:
> [...]

I'm downgrading the priority once again. I fixed the FTBFS for now,
this bug will addressed soon (or if it cannot be addressed, synapse
will be dropped from Debian).

Tomasz


signature.asc
Description: PGP signature

Bug#871806: uscan: (dpkg, git-buildpackage) accept/mangle/store signed git tags in cases where upstream does not publish detached sigs on tarballs

[Tomasz Buchert]

On 16/08/17 21:01, Daniel Kahn Gillmor wrote:
> Hi Guillem--
>
> On Thu 2017-08-17 01:05:46 +0200, Guillem Jover wrote:
> > It seems to me like you are perhaps trying to reimplement dpkg source
> > format «3.0 (git)» (described in man dpkg-source)? :)
>
> Thanks for that pointer, it does seem similar.
>
> I was hoping that we could produce an actual orig.tar.gz (so that the
> rest of the tools could use it as they have traditionally) and then some
> extra thing outside of the orig.tar.gz that, combined with the tarball,
> could be used to recreate the .git/ repository well enough to be able to
> (a) recreate the tarball, and (b) cryptographically verify the tag.
>
> this would solve my use case (being able to record and ship upstream's
> cryptographic signatures, when upstream "releases" with signed tags)
> without requiring the rest of the debian infrastructure to cope with git
> bundles as "orig.tar.gz-equivalent" blobs.
>
> But if there's a plan for "3.0 (git)" to become acceptable in debian,
> then it does seem like that might be the simplest way to move forward.
>
> i'll play around with git-bundle to try to understand it better.  from a
> scan of dpkg-source(1) and the various git manpages that i'm used to
> reading, i don't understand what .gitshallow or .git/shallow are
> supposed to do.  Does it get shipped alongside the .git?  does
> .git/shallow have meaning for other tools that i should be aware of?
>
>  --dkg

Hey all,

one of pristine-tar maintainers here. Daniel's ideas made me think a
lot about this stuff recently. I've just found
https://github.com/cgwalters/git-evtag: it does not solve the problem
at hand, but the idea of solving the problem "upstream", i.e., in git,
seems reasonable to me.

So let's assume that git-archive can produce a reproducible,
uncompressed tarball, given a particular githash. Why not ask
interested upstream developers to do something like that:

  git tag -s TAGNAME -m "$(git archive --format tar HEAD | sha512sum)"

The tag proves:
  (1) the history in the git repository, as always
  (2) but also that a tar generated from this tag should have a particular 
sha512 hash

You can see how this works end-to-end: if we want to take a particular
git tag and release it in Debian, we just generate the tarball and
extract the associated tag as a crypto-proof.

Such tagging may be prohibitive for every commit, though, since it's
rather expensive to compute (or not, I just run the above command in a
fresh clone of linux kernel source and it took 9s with fs caches, and
interestingly the same with caches dropped, weird). But it should be
totally fine at least for "release tags". The cool thing is that it
could be upstreamed in git, as a flag to git-tag, or at least provided
as an extension, such as git-atag (aka git-archive-tag, you get the
idea).

What do you think?

Tomasz


signature.asc
Description: PGP signature

Bug#872960: Actualy...

[Tomasz Buchert]

severity -1 grave
thanks

... actually I can reproduce this even on x11. I also get:

[INFO 01:12:29.004106] [synapse-main:266] Starting up...
[INFO 01:12:29.097393] [synapse-main:208] Binding activation to space
[1]23236 segmentation fault  synapse


signature.asc
Description: PGP signature

Bug#872960: Re

[Tomasz Buchert]

As this is somewhat non-standard setup, I downgraded the severity to
"important".


signature.asc
Description: PGP signature

Bug#871809: Please allow to store detached tarball signatures as well

[Tomasz Buchert]

On 20/08/17 17:40, Chris Lamb wrote:
>
> (I accidentally left a debugging statement in; please use the attached file)
>

Thanks, merged in the git repo. It will be released in the new
release, before we sort out #871938 which I consider to be a blocking
bug.

Thanks a lot,
Tomasz


signature.asc
Description: PGP signature

Bug#867545: Fails with cryptic message when given non-existing paths

[Tomasz Buchert]

On 20/08/17 15:54, Chris Lamb wrote:
> reopen 867545
> found 867545 1.40
> tags 867545 + patch
> thanks
>
> There's something funky with the logic committed in:
>
>   
> https://anonscm.debian.org/git/collab-maint/pristine-tar.git/commit/?id=9265d0c0eea1620370a7261e0a6ee20eb86426fd
>
> ... so that it doesn't actually catch missing files.
>
> I think you want:
>
>sub check_file_exists {
>  my $filename = shift;
>   -  if (!$filename eq "-" and !-f $filename) {
>   +  if ($filename ne "-" and !-f $filename) {
> error "The file $filename does not exist.";
>  }
>}
>
>
> Regards,
>

Logic is hard, especially in Perl. :) Thanks, committed in
https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=392a80ac9fdea8dbe41c438b9a310549981b3c33.

Tomasz


signature.asc
Description: PGP signature

Bug#871809: Please allow to store detached tarball signatures as well

[Tomasz Buchert]

On 20/08/17 16:42, Chris Lamb wrote:
> tags 871809 + patch
> thanks
>
> Hi,
>
> > I will implement this soon, this doesn't seem to be too hard
> > to do.
>
> Beat you to it, I think! I've attached:
>
>   commit 24549c61be4c0eea1495e3508377bf46d162230f
>   Author: Chris Lamb 
>   Date:   Sun Aug 20 16:25:45 2017 -0700
>
>   Support storing and retrieval of upstream signatures. (Closes: #871809)
>
>   This commit adds support for optionally storing and regenerating an
>   upstream signature with the tarball so that it can be verified by,
>   for example, dpkg-source(1).
>
>   Regardless of the original signature filename provided, it is always
>   stored alongside the .delta and .id files as .sig for deterministic
>   retrieval.
>
>   The existing behaviour of pristine-tar is unchanged unless you specify
>   the `-s` option; in particular, extraction of signatures is not 
> performed
>   by default - one must specify the filename. This is to prevent breaking
>   existing behaviour.
>
>README |  3 +++
>debian/control |  3 +++
>pristine-tar   | 59 
> +++---
>3 files changed, 54 insertions(+), 11 deletions(-)
>
>
> Best wishes,

Thanks, the amount of love pristine-tar is getting these days must
make it blush.

A quick glimpse tells me that it should be ok. Would you mind adding a
test to cover this functionality?

Tomasz


signature.asc
Description: PGP signature

Bug#871938: .delta file

[Tomasz Buchert]

On 21/08/17 00:59, Tomasz Buchert wrote:
> On 21/08/17 00:27, Tomasz Buchert wrote:
> > [...]
>
> That's a regression in the version 1.40 of pristine-tar (during the
> commit).  It's almost surely due to
> https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=0743dd36ed90c18982a5a861f4978080c1c4a2e3.
>
> Here is what 1.39 executes during commit:
>
> zgz -9 --original-name dist/planetfilter-0.7.4.tar --osflag 255 -T 
> 1501972711 -c
>
> And here is what 1.40 does:
>
> zgz --gnu -9 -T 1501972711
>
> (these can obtained if you use -v switch to pristine-tar).
> Extraction works fine in both cases, assuming the file was committed using 
> 1.39.
>
> CCing Lennart. Lennart, could you investigate?
>
> Tomasz

I did some more investigation into this and committed a workaround
which avoids the problematic case [1]. I didn't have time to dig
really into the main problem, though. I'd prefer to understand the zgz
problem before uploading this.

Tomasz

[1] 
https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=f7783d4096be24d235b77b9e8f4e3476faf8cd5d


signature.asc
Description: PGP signature

Bug#871938: .delta file

[Tomasz Buchert]

On 21/08/17 00:27, Tomasz Buchert wrote:
> [...]

That's a regression in the version 1.40 of pristine-tar (during the
commit).  It's almost surely due to
https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=0743dd36ed90c18982a5a861f4978080c1c4a2e3.

Here is what 1.39 executes during commit:

zgz -9 --original-name dist/planetfilter-0.7.4.tar --osflag 255 -T 
1501972711 -c

And here is what 1.40 does:

zgz --gnu -9 -T 1501972711

(these can obtained if you use -v switch to pristine-tar).
Extraction works fine in both cases, assuming the file was committed using 1.39.

CCing Lennart. Lennart, could you investigate?

Tomasz


signature.asc
Description: PGP signature

Bug#871938: .delta file

[Tomasz Buchert]

On 12/08/17 12:00, Francois Marier wrote:
> Here's the .delta file I forgot to include.

I confirm the issue. At first, I thought it's due to the new delta
format, but then verified it reproduces with the previous format as well.

The problem seems to lay in the "zgz" utility which incorrectly
rebuilds the file, e.g., the file size does not match. It seems harder
than I expected, will have to investigate more.

Tomasz


signature.asc
Description: PGP signature

Bug#865272: pristine-tar: fails to reproduce mingw-w64-v5.0.2.tar.bz2

[Tomasz Buchert]

On 20/06/17 09:17, Stephen Kitt wrote:
>
> [...]
>
> Steps to reproduce:
>
>   wget 
> http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v5.0.2.tar.bz2
>   mkdir mingw-w64 && cd mingw-w64
>   git init
>   gbp import-orig --pristine-tar ../mingw-w64-v5.0.2.tar.bz2
>

Thank you Stephen,
I confirm the problem.

Some background: bz2 and xz are the formats in pristine-tar that will
fail to be committed if an exact match for a program cannot be
found. The gz format has a fallback and will generate a binary delta
that may be big, but will let you at least commit the tarball.

It seems that a new way of bz2 compressing is in the wild. I'll
investigate what that is and if that fails, I'll take a look if a
binary delta approach is applicable to bz2 too.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#869645: ssss: Please add simple autopkgtest

[Tomasz Buchert]

On 25/07/17 11:00, Chris Lamb wrote:
> Hi,
>
> > Patch attached.
>
> Somehow this got dropped initially. Attaching now.
>
>
> Regards,
>

Thank you Chris and late congrats for becoming our DPL. :)
I'm about to upload a new version of  with your patch.

Tomasz


signature.asc
Description: PGP signature

Bug#871809: Please allow to store detached tarball signatures as well

[Tomasz Buchert]

On 11/08/17 16:36, Guido Günther wrote:
> Package: pristine-tar
> Version: 1.40
> Severity: wishlist
>
> Hi,
> as proposed by maxy on debian-devel it would be great if pristine-tar
> would store the tarball signtures as well:
>
> 
> https://lists.debian.org/msgid-search/20170731145720.6jccnhgmyr4gc...@neoptolemo.gnuservers.com.ar
>
> pristine-tar could commit the orig.tar.{$ext}.{asc,pgp} right away by
> default if present or we'd extend the command line to
>
> pristine-tar [-vdk] [-m message] [-s signaturefile] commit tarball 
> [upstream]
>
> Cheers and thanks for this very useful tool!
>  -- Guido

Hi Guido,
I think the most backwards compatible flow is to explicitly specify
"signaturefile", both during the commit into the pristine-tar branch
and during checkout. Will this work for you?

I will implement this soon, this doesn't seem to be too hard to do.

Tomasz

signature.asc
Description: PGP signature

Bug#868409: verbiste: Please drop the (build-)dependency against gnome-vfs

[Tomasz Buchert]

On 15/07/17 13:40, bi...@debian.org wrote:
> Source: verbiste
> Version: 0.1.44-1
> Severity: wishlist
> Tags: sid buster
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: gnome-vfs-removal oldlibs
>
> Dear maintainer,
>
> Your package is {build-}depending against gnome-vfs which is
> deprecated for quite some times now and has been replaced by gvfs.
>
> We are thinking about removing gnome-vfs for Buster if possible.
>
> Could you please verify that this dependency is mandatory and if it's
> not the case, could you please remove it?
>
> Don't hesitate to contact me if you have any questions.
>
> Kind regards,
>
> Laurent Bigonville

Hi Laurent,
verbiste depends on libgnomeui-2.0 which then depends on gnome-vfs. The package 
does not build
anymore if I remove the libgnomeui dependency, but if in the process of your 
transition you are
going to fix deps of libgnomeui, then this package will profit too.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#805488: [Patch] Fix (including for a lot of other failing tarballs)

[Tomasz Buchert]

On 10/07/17 11:45, Lennart Sorensen wrote:
> On Fri, Jul 07, 2017 at 10:10:04PM +0200, Tomasz Buchert wrote:
> > Wow, this is nice. Would you mind adding some tests to cover this?
> > Ideally, we would have coverage for all rsyncable "dialects" we
> > support.  Can you commit to collab-maint?
>
> Something like this perhaps:
>
> diff --git a/test/test_roundtrip.sh b/test/test_roundtrip.sh
> index 5465ed4..b82620d 100644
> --- a/test/test_roundtrip.sh
> +++ b/test/test_roundtrip.sh
> @@ -19,6 +19,18 @@ test_bz2() {
>assertWorksWithTarball $SAMPLES/tarballs/foo-1.0.tar.bz2
>  }
>
> +test_gz_135_rsyncable() {
> +  assertWorksWithTarball 
> $SAMPLES/tarballs/libinotify-kqueue-1.3.5rsyncable_20120419.orig.tar.gz
> +}
> +
> +test_gz_14_rsyncable() {
> +  assertWorksWithTarball 
> $SAMPLES/tarballs/libinotify-kqueue-1.4rsyncable_20120419.orig.tar.gz
> +}
> +
> +test_gz_16_rsyncable() {
> +  assertWorksWithTarball 
> $SAMPLES/tarballs/libinotify-kqueue-1.6rsyncable_20120419.orig.tar.gz
> +}
> +
>  test_gz() {
>assertWorksWithTarball $SAMPLES/tarballs/foo-1.0.tar.gz
>  }
>
> I tried with a smaller tar file first, but you need to be at least 4 or
> 8KB depending on gzip version to trigger the rsyncable window size thing
> so I used the other sample which resulted in different files for each
> gzip version.
>
> --
> Len Sorensen

Thanks a lot! I've imported this and prepared a new release [1].
I will upload it soon.

Cheers,
Tomasz

[1] 
https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=383071b4978c1d548d4b6d22fa19db57d59ca046


signature.asc
Description: PGP signature

Bug#867545: Fails with confusing message when tarball target is a unresolved symlink

[Tomasz Buchert]

retitle 867545 Fails with cryptic message when given paths do not exist
thanks

On 07/07/17 09:57, Guido Günther wrote:
> Package: pristine-tar
> Version: 1.39
> Severity: minor
>
> pristine-tar fails when the target it want's to reproduce is a symlink
> that points nowhere. That by itself is o.k. but the error message is
> confusing:
>
> $ /usr/bin/pristine-tar checkout 
> /var/scratch/src/krb5-auth-dialog/krb5-auth-dialog_3.20.0.orig.tar.xz
> Use of uninitialized value $tarball in -e at /usr/bin/pristine-tar line 
> 454.
> Use of uninitialized value $_[0] in substitution (s///) at 
> /usr/share/perl/5.24/File/Basename.pm line 180.
> fileparse(): need a valid pathname at /usr/bin/pristine-tar line 469.
> pristine-tar: failed to generate tarball
>
> Steps to reproduce:
>
> ln -s /doesnotexist krb5-auth-dialog_3.20.0.orig.tar.xz
> gbp clone vcsgit:krb5-auth-dialog
> /usr/bin/pristine-tar checkout 
> /var/scratch/src/krb5-auth-dialog/krb5-auth-dialog_3.20.0.orig.tar.xz
>

Hey Guido,
thanks for this info, but I think the issue has nothing to do with the
symbolic link, but rather with the fact that the destination directory
does not exist (also in steps above you have to 'cd' into the cloned
repo).

I've committed a change [1] that will verify better what is given from
the command line to all pristine-tar commands.

Thanks,
Tomasz

[1] 
https://anonscm.debian.org/cgit/collab-maint/pristine-tar.git/commit/?id=9265d0c0eea1620370a7261e0a6ee20eb86426fd


signature.asc
Description: PGP signature

Bug#805488: [Patch] Fix (including for a lot of other failing tarballs)

[Tomasz Buchert]

On 07/07/17 10:34, Lennart Sorensen wrote:
> I managed to fix almost half the failures in knownproblems by making
> --gnu always be tried rather than only when GZIP_OS_UNIX is found.
> Doing the same for --rsyncable and --new-rsyncable probably makes sense
> too.
>
> The --new-rsyncable was written for gzip 1.4, while gzip 1.6 does things
> a bit different (it's a bit of a hybrid between the original rsyncable
> and the 1.4 rsyncable).  I have added a new --16-rsyncable option to
> zgz that matches the new behaviour, which fixes this bug.
>
> I have tested both gzip 1.4 and gzip 1.6 with --rsyncable and pristine-tar
> now handles both.
>
> --
> Len Sorensen

Wow, this is nice. Would you mind adding some tests to cover this?
Ideally, we would have coverage for all rsyncable "dialects" we
support.  Can you commit to collab-maint?

Thanks!
Tomasz


signature.asc
Description: PGP signature

Bug#867499: tiptop: Fix parallel bison FTBFS

[Tomasz Buchert]

On 07/07/17 00:56, Adrian Bunk wrote:
> [...]

This is amazing, thanks!
Just uploaded 2.3-3 with your fix.

Tomasz


signature.asc
Description: PGP signature

Bug#865523: Build C library from src:brotli sources

[Tomasz Buchert]

On 22/06/17 13:57, Ondřej Surý wrote:
> [...]

I did some work on the version in git now builds the shared libraries.
I've packaged all shared libs inside libbrotli, but probably should
split it more into 3 more libs (common, enc and dec). I'm however
surprised at the architecture: it would be much easier to just have a
one shared library for brotli in general.

Let me know what you think.

Tomasz


signature.asc
Description: PGP signature

Bug#865523: Build C library from src:brotli sources

[Tomasz Buchert]

On 22/06/17 13:57, Ondřej Surý wrote:
> Package: src:brotli
> Version: 0.6.0-1
> Severity: normal
>
> Dear maintainer,
>
> according to the brotli 0.6.0 changelog, the "C API is expected to be
> final", so it might be a good time to start building the C libraries
> from the sources.
>
> I got a request to package Apache2 and Nginx modules, and I would
> prefer to use a shared system library as a dependency.

Hey Ondřej,
thank you for letting me know. I'll try to figure out how this works.

> (Also I would be happy to offer you a co-maintainship of brotli and
> nghttp2 packages, as I use those in my apache2 and php PPA and DPA
> repositories...)

No problem, happy to co-maintain. I've just added you to the
debian/control in both packages. This will make it official after the
next upload (but feel free to improve things already :) ).

> Thanks,
> Ondrej

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#862461: tiptop: requires root to run

[Tomasz Buchert]

On 14/05/17 20:58, Ben Hutchings wrote:
> On Sun, 2017-05-14 at 10:43 +0200, Tomasz Buchert wrote:
> > On 12/05/17 18:54, Nathaniel Beaver wrote:
> > > [...]
> >
> > Thank you, Nathaniel.
> >
> > I confirm the problem. A safe bet is that
> > https://lkml.org/lkml/2016/1/11/587 is the cause.  You can verify that
> > /proc/sys/kernel/perf_event_paranoid contains "3". By running
> >
> > echo 2 | sudo tee /proc/sys/kernel/perf_event_paranoid
> >
> > you should be able to use tiptop as a normal user again.
> >
> > I doubt that we can switch the default value in Debian kernels to "2",
> > so I have to say that simply the tiptop website is not up-to-date, at
> > least with respect to the Debian kernels (but also likely to other
> > distributions as well). I'm CCing Ben to let him comment on this.
>
> The Debian kernel default is not going to be changed in the short term.
>  In the long term it's conceivable that performance events will
> eventually become sufficiently robust that it would be reasonable to
> change the default.
>
> Ben.
>
> --
> Ben Hutchings - Debian developer, member of kernel, installer and LTS teams

Thank you!

Nathaniel, I'll keep this bug open till possibly the perf events will
become available for normal users. Till then I require you to use the
workaround above if you feel like it.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#862461: tiptop: requires root to run

[Tomasz Buchert]

On 12/05/17 18:54, Nathaniel Beaver wrote:
> [...]

Thank you, Nathaniel.

I confirm the problem. A safe bet is that
https://lkml.org/lkml/2016/1/11/587 is the cause.  You can verify that
/proc/sys/kernel/perf_event_paranoid contains "3". By running

echo 2 | sudo tee /proc/sys/kernel/perf_event_paranoid

you should be able to use tiptop as a normal user again.

I doubt that we can switch the default value in Debian kernels to "2",
so I have to say that simply the tiptop website is not up-to-date, at
least with respect to the Debian kernels (but also likely to other
distributions as well). I'm CCing Ben to let him comment on this.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

Hey,

On 06/05/17 14:43, Dirk Eddelbuettel wrote:
>
> On 6 May 2017 at 20:43, Tomasz Buchert wrote:
> | On 06/05/17 19:23, Tomasz Buchert wrote:
> | > [...]
> |
> | Ok, I confirm that dlopen() is required to properly resolve some
> | symbols later: I can only assume that openmpi does some magic
> | there. Here are 2 solutions I came up with:
> |
> |   1. Just like in #741297: add another dlopen() call to the chain (see
> |  attached simple-but-wrong.debdiff)
>
> Right. That is the obvious one.
>
> |   2. Figure out what is the libmpi to load. I attach a proof-of-concept 
> that uses dl_iterate_phdr
> |  to find this out (see attached findlibmpi.debdiff).
>
> That's for upstream. I would encourage you to send that to Hao Yu explaining
> the issue. Other distro may end up with the same sonames.

But there is also the issue at hand: this RC bug. It should be fine to
patch it temporarily at least to let the package be in stable, no?

> | I've tested both approaches and they work for me.
> |
> | Btw, it would be good to add a smoke test to verify that loading from
> | R works, so that we can detect it just after build.
>
> It already does. At the end of each 'R CMD INSTALL foo' run (which what we do
> here to) the new library is loaded.
>
> But as we build, the libopenmpi-dev package is present, and then it passes
> (see my earlier messages based on poking around in a Debian unstable session
> in a Docker container).

Right, makes sense. What about https://ci.debian.net/?

> Thanks much for the patch, this really help. And I do appreciate that you
> tested it. This matters.
>
> Now, if I may: Going forward, you may want to think keeping a little bit of
> the attitude out of your posts.  Nobody asked about your personal opinions
> regarding the build system, or judgement about certain patches (which, after
> all, were also initially wrong on your end).

Nothing I wrote was intended as a personal opinion (isn't format 1.0
objectively worse than 3.0? wasn't the add-another-dlopen fix bound to
fail in the future?), but I understand that it could be read like
that. I'm sorry if I offended you.

And my patch was wrong, you caught me red-handed and I stand corrected.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

On 06/05/17 19:23, Tomasz Buchert wrote:
> [...]

Ok, I confirm that dlopen() is required to properly resolve some
symbols later: I can only assume that openmpi does some magic
there. Here are 2 solutions I came up with:

  1. Just like in #741297: add another dlopen() call to the chain (see
 attached simple-but-wrong.debdiff)

  2. Figure out what is the libmpi to load. I attach a proof-of-concept that 
uses dl_iterate_phdr
 to find this out (see attached findlibmpi.debdiff).

I've tested both approaches and they work for me.

Btw, it would be good to add a smoke test to verify that loading from
R works, so that we can detect it just after build.

Let me know what you think.
Tomasz
only in patch2:
unchanged:
--- rmpi-0.6-6.orig/src/Rmpi.c
+++ rmpi-0.6-6/src/Rmpi.c
@@ -74,7 +74,8 @@
 
 #ifndef __APPLE__
 #ifdef OPENMPI
-if (!dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
+   if (!dlopen("libmpi.so.20", RTLD_GLOBAL | RTLD_LAZY) 
+&& !dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
&& !dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
&& !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)) {
 Rprintf("%s\n",dlerror());
only in patch2:
unchanged:
--- rmpi-0.6-6.orig/src/Rmpi.c
+++ rmpi-0.6-6/src/Rmpi.c
@@ -15,10 +15,13 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#define _GNU_SOURCE 
 #include "Rmpi.h"
 
 #ifdef OPENMPI
 #include 
+#include 
+#include 
 #endif
 
 static MPI_Comm*comm;
@@ -57,6 +60,15 @@
return AsInt(i);
 }
 
+static int 
  
+dl_iter_cb(struct dl_phdr_info *info, size_t size, void *data) 

+{  
  
+  if (strstr(info->dlpi_name, "libmpi.so") != NULL) {  
  
+*((char**)data) = strdup(info->dlpi_name); 
  
+  }
  
+  return 0;
  
+}
+
 SEXP mpi_initialize(){
int i,flag;
MPI_Initialized();
@@ -74,12 +86,19 @@
 
 #ifndef __APPLE__
 #ifdef OPENMPI
-if (!dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
-   && !dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
-   && !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)) {
+   char* mpiso = NULL;
+   dl_iterate_phdr(dl_iter_cb, );
+   if (mpiso == NULL) {
+   Rprintf("No openmpi linked.\n");
+   return AsInt(0);
+   }
+
+if (!dlopen(mpiso, RTLD_GLOBAL | RTLD_LAZY)) {
+   free(mpiso);
 Rprintf("%s\n",dlerror());
 return AsInt(0);
 }
+   free(mpiso);
 #endif
 #endif
 


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

On 06/05/17 11:58, Dirk Eddelbuettel wrote:
>
> Hi Tomasz,
>
> [...]
>
> While true for us, it is not always true for Rmpi on other system so upstream
> for Rmpi added this.  I haven't heard from him a while.
>
> But I do recall that we needed this for some other braindeadness with the
> multiple shared library -- I distinctly remember fighting this for many
> months.  The problem, really, is the need for RTLD_GLOBAL | RTLD_LAZY in
> order follow symbols into the other libraries which OpenMPI decides to split
> this over.
>
>dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY)
>

Although I don't get it, I'll try to verify that it does not break anything.

> What version 1.0?  There never was one for Rmpi.

Version 1.0 of the packaging system (orig + diff => 
https://manpages.debian.org/jessie/dpkg-dev/dpkg-source.1.en.html#SOURCE_PACKAGE_FORMATS).

>
> Dirk
>

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

On 03/05/17 17:54, Ralf Stubner wrote:
> [...]

Hi all,
this is really another iteration of #741297.


Honestly, I believe that the whole test of openmpi "existence" using
dlopen is unnecessary. This code is only executed if we have compiled
against openmpi, so why do we have to double-check that it is in the
system?  I propose to completely drop the dlopen test.

I attach a patch that does exactly that. I tried to prepare NMU, but
had a hard time with version 1.0 of this package :(.

Cheers,
Tomasz
From d4d39b7f09cfc0d2746702b417bebf0bf421b947 Mon Sep 17 00:00:00 2001
From: Tomasz Buchert <tom...@buchert.pl>
Date: Sat, 6 May 2017 17:13:41 +0200
Subject: [PATCH] Fix for #861748.

---
 ...ent-the-use-of-dlopen-for-libmpi.so-files.patch | 36 ++
 debian/patches/series  |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch b/debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
new file mode 100644
index 000..3630980
--- /dev/null
+++ b/debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
@@ -0,0 +1,36 @@
+From: Tomasz Buchert <tom...@buchert.pl>
+Date: Sat, 6 May 2017 17:08:38 +0200
+Subject: Comment the use of dlopen() for libmpi.so files.
+
+dlopen is used only to runtime check that rmpi is running against
+openmpi. But this code is only compiled in when openmpi is the mpi
+runtime in the system. Hence, the test is useless.
+
+The reason why it causes the import to fail is that the version of
+openmpi in stretch has changed the .so file numbering from "so.1" to
+"so.20". The previous "fix" in https://bugs.debian.org/741297 clearly
+just pushes the problem only in the future.
+---
+ src/Rmpi.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/Rmpi.c b/src/Rmpi.c
+index ce9a718..91c9145 100644
+--- a/src/Rmpi.c
 b/src/Rmpi.c
+@@ -74,12 +74,15 @@ if (flag)
+ 
+ #ifndef __APPLE__
+ #ifdef OPENMPI
++	/*
++	// This test is not necessary in Debian.
+ if (!dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
+ 	&& !dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
+ 	&& !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)) {
+ Rprintf("%s\n",dlerror());
+ return AsInt(0);
+ }
++	*/
+ #endif
+ #endif
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..560da9e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#861870: Requesting unblock

[Tomasz Buchert]

On 06/05/17 11:12, Balasankar C wrote:
> Hi Tomasz,
>
> GitLab package co-maintainer here. We will be uploading the fix to unstable 
> and
> requesting an unblock, hopefully by Monday. In the mean time, there is already
> an unblock request open[0] for the latest version in unstable, 
> 8.13.11+dfsg1-5.
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861293
>
> Regards,
> Balasankar C

Hi,
in this case I'm going to close my request in #861914, and let you
take care of it.

Tomasz


signature.asc
Description: PGP signature

Bug#851877: fails every time

[Tomasz Buchert]

On 04/05/17 04:47, Adam Borowski wrote:
> [...]

I cannot reproduce these failures. I've built in my stretch sbuild
around 15 times, and succedeed every time.

I use:
gbp buildpackage --git-builder='sbuild --source-only-changes -v -As 
--build-dep-resolver=apt --dist=stretch -j4' "$@"

Tomasz


signature.asc
Description: PGP signature

Bug#861914: unblock: gitlab/8.13.11+dfsg1-4

[Tomasz Buchert]

On 05/05/17 21:36, Tomasz Buchert wrote:
> [...]

Let me add that the bug in question is https://bugs.debian.org/861870.


signature.asc
Description: PGP signature

Bug#861914: unblock: gitlab/8.13.11+dfsg1-4

[Tomasz Buchert]

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

Please unblock package gitlab

The attached debdiff fixes CVE-2017-8778.

unblock gitlab/8.13.11+dfsg1-4

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Bug#861870: gitlab: CVE-2017-8778

[Tomasz Buchert]

On 05/05/17 20:46, Tomasz Buchert wrote:
> On 05/05/17 06:19, Salvatore Bonaccorso wrote:
> > [...]
>
> Hi Salvatore,
> the fix for this issue seems to be here:
> https://gitlab.com/winniehell/gitlab-ce/commit/dd944bf14f4a0fd555db32d5833325fa459d9565
>
> I'll try to apply it to stretch's gitlab.
> Tomasz

Interestingly, the CVE has been fixed for unstable just an hour ago or so:
https://anonscm.debian.org/cgit/pkg-ruby-extras/gitlab.git/commit/?id=7241318db49ec356f31dac96345a4ff730d313f0

I've reapplied this for the stretch version and I attach the
debdiff. I'm going to request an unblock for this.

For some reason I couldn't push my branch to 
ssh://git.debian.org/git/pkg-ruby-extras/gitlab.git.
Probably I should become ruby-extras team member or something. For this reason 
I also attach
the commits from my branch.

Cheers,
Tomasz
diff -Nru gitlab-8.13.11+dfsg1/debian/changelog gitlab-8.13.11+dfsg1/debian/changelog
--- gitlab-8.13.11+dfsg1/debian/changelog	2017-04-21 12:32:25.0 +0200
+++ gitlab-8.13.11+dfsg1/debian/changelog	2017-05-05 21:23:50.0 +0200
@@ -1,3 +1,9 @@
+gitlab (8.13.11+dfsg1-4) testing-proposed-updates; urgency=medium
+
+  * Fix CVE-2017-8778
+
+ -- Tomasz Buchert <tom...@debian.org>  Fri, 05 May 2017 21:23:50 +0200
+
 gitlab (8.13.11+dfsg1-3) unstable; urgency=medium
 
   * Quote variable in test -n (Thanks to Benjamin Drung)
diff -Nru gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch
--- gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch	1970-01-01 01:00:00.0 +0100
+++ gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch	2017-05-05 21:14:50.0 +0200
@@ -0,0 +1,99 @@
+From: Debian Ruby Extras Maintainers
+ <pkg-ruby-extras-maintain...@lists.alioth.debian.org>
+Date: Fri, 5 May 2017 21:00:42 +0200
+Subject: cve-2017-8778
+
+---
+ app/uploaders/file_uploader.rb  |  2 +-
+ app/uploaders/uploader_helper.rb|  8 
+ spec/controllers/uploads_controller_spec.rb | 22 ++
+ spec/factories/notes.rb |  6 +-
+ 4 files changed, 36 insertions(+), 2 deletions(-)
+
+diff --git a/app/uploaders/file_uploader.rb b/app/uploaders/file_uploader.rb
+index 3ac6030..407606a 100644
+--- a/app/uploaders/file_uploader.rb
 b/app/uploaders/file_uploader.rb
+@@ -36,7 +36,7 @@ class FileUploader < CarrierWave::Uploader::Base
+ escaped_filename = filename.gsub("]", "\\]")
+ 
+ markdown = "[#{escaped_filename}](#{self.secure_url})"
+-markdown.prepend("!") if image_or_video?
++markdown.prepend("!") if image_or_video? || dangerous?
+ 
+ {
+   alt:  filename,
+diff --git a/app/uploaders/uploader_helper.rb b/app/uploaders/uploader_helper.rb
+index b10ad71..5a9c0b7 100644
+--- a/app/uploaders/uploader_helper.rb
 b/app/uploaders/uploader_helper.rb
+@@ -7,11 +7,19 @@ module UploaderHelper
+   # on IE >= 9.
+   # http://archive.sublimevideo.info/20150912/docs.sublimevideo.net/troubleshooting.html
+   VIDEO_EXT = %w[mp4 m4v mov webm ogv]
++  # These extension types can contain dangerous code and should only be embedded inline with
++  # proper filtering. They should always be tagged as "Content-Disposition: attachment", not "inline".
++  DANGEROUS_EXT = %w[svg]
++
+ 
+   def image?
+ extension_match?(IMAGE_EXT)
+   end
+ 
++  def dangerous?
++extension_match?(DANGEROUS_EXT)
++  end
++
+   def video?
+ extension_match?(VIDEO_EXT)
+   end
+diff --git a/spec/controllers/uploads_controller_spec.rb b/spec/controllers/uploads_controller_spec.rb
+index 69124ab..8ea9c71 100644
+--- a/spec/controllers/uploads_controller_spec.rb
 b/spec/controllers/uploads_controller_spec.rb
+@@ -4,6 +4,28 @@ describe UploadsController do
+   let!(:user) { create(:user, avatar: fixture_file_upload(Rails.root + "spec/fixtures/dk.png", "image/png")) }
+ 
+   describe "GET show" do
++context 'Content-Disposition security measures' do
++  let(:project) { create(:empty_project, :public) }
++
++  context 'for PNG files' do
++it 'returns Content-Disposition: inline' do
++  note = create(:note, :with_attachment, project: project)
++  get :show, model: 'note', mounted_as: 'attachment', id: note.id, filename: 'image.png'
++
++  expect(response['Content-Disposition']).to start_with('inline;')
++end
++  end
++
++  context 'for SVG files' do
++it 'returns Content-Disposition: attachment' do
++  note = create(:note, :with_svg_attachment, project: project)
++  get :show, model: 'note', mounted_as: 'attachment', id: note.id, filename: 'image.svg'
++
++  expect(response['Content-Disposition']).to start_with('attachment;')
++end
++  end
++end
++
+ context "when viewing a user avatar&q

Bug#861870: gitlab: CVE-2017-8778

[Tomasz Buchert]

On 05/05/17 06:19, Salvatore Bonaccorso wrote:
> [...]

Hi Salvatore,
the fix for this issue seems to be here:
https://gitlab.com/winniehell/gitlab-ce/commit/dd944bf14f4a0fd555db32d5833325fa459d9565

I'll try to apply it to stretch's gitlab.
Tomasz


signature.asc
Description: PGP signature

Bug#861630: stellarium: Stellarium does not start at all

[Tomasz Buchert]

On 02/05/17 05:26, Pascal Gervais wrote:
> On Tue, 2 May 2017 09:43:57 +0200
> Tomasz Buchert <tom...@debian.org> wrote:
>
> > The message seems pretty clear to me. Do you indeed have an old GPU?
>
> Seriously, a 5 years old computer is now considered outdated? I used
> such sky observer software on an old Pentium MMX 166 MHz 20 years ago,
> but I can't with an Intel Core 2 G33 chipset? Are you serious?

Hello Pascal,
I tend to be serious when I reply in bug reports, yes.

Thank you for mentioning the GPU in question. It seems that the GPU is
then https://en.wikipedia.org/wiki/Intel_GMA#GMA_3100. Alex, can you
confirm that this GPU would not support necessary OpenGL stuff
(possibly relevant docs:
http://www.intel.com/assets/pdf/prodbrief/317311.pdf)?

>
> > Can you try the options provided in the message?
>
> You mean "--mesa-mode" and "--safe-mode"? Sorry, but there is no such
> options with the Stellarium package provided by Debian.

You're right, they are only available on windows, my apologies.
However, you can still run:

   LIBGL_ALWAYS_SOFTWARE=1 stellarium

to see if the software rendering works at least.

> > Cheers,
> > Tomasz

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861630: stellarium: Stellarium does not start at all

[Tomasz Buchert]

On 01/05/17 20:59, Pascal Gervais wrote:
> The output of Stellarium in a terminal show a segmentation fault.
>
> --
> Pascal  ><©>

> pascal@debianx:~$ stellarium
>  ---
> [ This is Stellarium 0.15.2 - http://www.stellarium.org ]
> [ Copyright (C) 2000-2017 Fabien Chereau et al. ]
>  ---
> Writing log file to: "/home/pascal/.stellarium/log.txt"
> File search paths:
>   0 .  "/home/pascal/.stellarium"
>   1 .  "/usr/share/stellarium"
> Config file is:  "/home/pascal/.stellarium/config.ini"
> Default surface format:  QSurfaceFormat(version 2.0, options QFlags(), 
> depthBufferSize -1, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, 
> alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior 0, 
> swapInterval 1, profile  0)
> Desired surface format:  QSurfaceFormat(version 2.1, options QFlags(), 
> depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, 
> alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 0, 
> swapInterval 1, profile  0)
> StelGLWidget constructor
> StelGraphicsScene constructor
> initializeGL
> OpenGL supported version:  "2.1 Mesa 13.0.6"
> Current Format:  QSurfaceFormat(version 2.1, options QFlags(0x4), 
> depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, 
> alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior 0, 
> swapInterval 1, profile  0)
> StelMainView::init
> Detected: OpenGL "2.1"
> Driver version string: "2.1 Mesa 13.0.6"
> GL vendor is "Intel Open Source Technology Center"
> GL renderer is "Mesa DRI Intel(R) G33 "
> GL Shading Language version is "1.20"
> MESA Version Number detected:  13
> Mesa version is fine, we should not see a graphics problem.
> GLSL Version Number detected:  1.2
> This is not enough: we need GLSL1.30 or later.
> You should update graphics drivers, graphics hardware, or use the --mesa-mode 
> option.
> Else, please try to use an older version like 0.12.5, and try there with 
> --safe-mode
> You can try to run in an unsupported degraded mode by ignoring the warning 
> and continuing.
> But more than likely problems will persist.
> Segmentation fault

The message seems pretty clear to me. Do you indeed have an old GPU? Can you 
try the options
provided in the message?

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861014: unblock: python-pyelftools/0.24-2

[Tomasz Buchert]

On 29/04/17 12:26, Niels Thykier wrote:
> [...]
>
> Yes please.  Upload a -3 to unstable reverting just the debhelper compat
> bump from -2.
>
> Thanks,
> ~Niels

Yep, I've just uploaded -3.

Tomasz


signature.asc
Description: PGP signature

Bug#861014: unblock: python-pyelftools/0.24-2

[Tomasz Buchert]

On 29/04/17 07:55, Niels Thykier wrote:
> Tomasz Buchert:
> > On 23/04/17 23:04, Ivo De Decker wrote:
> >> Control: tags -1 moreinfo
> >>
> >> Hi,
> >>
> >> On Sun, Apr 23, 2017 at 07:51:24PM +0200, Tomasz Buchert wrote:
> >>> Please unblock package python-pyelftools
> >>>
> >>> The package FTBFSes on i386. The version in unstable fixes it.
> >>>
> >>> unblock python-pyelftools/0.24-2
> >>
> >> You changed the debhelper compat version from 9 to 10. That is not 
> >> appropriate
> >> during the freeze. Please revert this.
> >>
> >> Cheers,
> >>
> >> Ivo
> >
> > Hi Ivo,
> > here is a simpler debdiff with upload to testing-proposed-updates.
> >
> > Tomasz
> >
>
> Hi Tomasz,
>
> I would strongly prefer having the debhelper compat bump reveted and let
> (the rest of)  python-pyelftools/0.24-2 migrate via unstable.  The
> remaining changes are beign and by going through unstable, we get more
> QA checks.
>
> Thanks,
> ~Niels

Hi Niels,
I should revert these changes then and upload them as 0.24-3 (since
0.24-2 is already in)?

Tomasz


signature.asc
Description: PGP signature

Bug#861014: unblock: python-pyelftools/0.24-2

[Tomasz Buchert]

On 23/04/17 23:04, Ivo De Decker wrote:
> Control: tags -1 moreinfo
>
> Hi,
>
> On Sun, Apr 23, 2017 at 07:51:24PM +0200, Tomasz Buchert wrote:
> > Please unblock package python-pyelftools
> >
> > The package FTBFSes on i386. The version in unstable fixes it.
> >
> > unblock python-pyelftools/0.24-2
>
> You changed the debhelper compat version from 9 to 10. That is not appropriate
> during the freeze. Please revert this.
>
> Cheers,
>
> Ivo

Hi Ivo,
here is a simpler debdiff with upload to testing-proposed-updates.

Tomasz
diff -Nru python-pyelftools-0.24/debian/changelog 
python-pyelftools-0.24/debian/changelog
--- python-pyelftools-0.24/debian/changelog 2016-08-09 00:29:51.0 
+0200
+++ python-pyelftools-0.24/debian/changelog 2017-04-29 09:42:48.0 
+0200
@@ -1,3 +1,9 @@
+python-pyelftools (0.24-2) testing-proposed-updates; urgency=medium
+
+  * d/patches: disable readelf tests, solves #860630
+
+ -- Tomasz Buchert <tom...@debian.org>  Sat, 29 Apr 2017 09:42:48 +0200
+
 python-pyelftools (0.24-1) unstable; urgency=medium
 
   * Imported Upstream version 0.24
diff -Nru 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
--- 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
   1970-01-01 01:00:00.0 +0100
+++ 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
   2017-04-29 09:42:48.0 +0200
@@ -0,0 +1,21 @@
+From: Tomasz Buchert <tom...@debian.org>
+Date: Sun, 23 Apr 2017 19:40:32 +0200
+Subject: Don't run readelf tests, because they are fragile and arch-specific.
+
+---
+ test/all_tests.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/all_tests.py b/test/all_tests.py
+index 4cb8e3c..6467af8 100755
+--- a/test/all_tests.py
 b/test/all_tests.py
+@@ -22,7 +22,7 @@ def main():
+ return 1
+ run_test_script('test/run_all_unittests.py')
+ run_test_script('test/run_examples_test.py')
+-run_test_script('test/run_readelf_tests.py')
++# run_test_script('test/run_readelf_tests.py')
+ 
+ if __name__ == '__main__':
+ sys.exit(main())
diff -Nru python-pyelftools-0.24/debian/patches/series 
python-pyelftools-0.24/debian/patches/series
--- python-pyelftools-0.24/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ python-pyelftools-0.24/debian/patches/series2017-04-29 
09:42:48.0 +0200
@@ -0,0 +1 @@
+0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch


signature.asc
Description: PGP signature

Bug#861014: unblock: python-pyelftools/0.24-2

[Tomasz Buchert]

On 28/04/17 21:16, IOhannes m zmölnig (Debian/GNU) wrote:
> hi tomasz,
>
> On Sun, 23 Apr 2017 23:04:08 +0200 Ivo De Decker <iv...@debian.org> wrote:
> > Control: tags -1 moreinfo
> >
> > Hi,
> >
> > On Sun, Apr 23, 2017 at 07:51:24PM +0200, Tomasz Buchert wrote:
> > > Please unblock package python-pyelftools
> > >
> > > The package FTBFSes on i386. The version in unstable fixes it.
> > >
> > > unblock python-pyelftools/0.24-2
> >
> > You changed the debhelper compat version from 9 to 10. That is not 
> > appropriate
> > during the freeze. Please revert this.
> >
>
> since once of my packages is threatened by autoremoval due to this bug,
> i wonder whether i can do something to help with the issue at hand.
>
> gfmadr
> IOhannes
>

Hey,
I'll prepare a new upload today, sorry for troubles.

Tomasz


signature.asc
Description: PGP signature

Bug#861014: unblock: python-pyelftools/0.24-2

[Tomasz Buchert]

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

Please unblock package python-pyelftools

The package FTBFSes on i386. The version in unstable fixes it.

unblock python-pyelftools/0.24-2

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
diff -Nru python-pyelftools-0.24/debian/changelog 
python-pyelftools-0.24/debian/changelog
--- python-pyelftools-0.24/debian/changelog 2016-08-09 00:29:51.0 
+0200
+++ python-pyelftools-0.24/debian/changelog 2017-04-23 19:43:10.0 
+0200
@@ -1,3 +1,11 @@
+python-pyelftools (0.24-2) unstable; urgency=medium
+
+  * d/control: use debhelper 10
+  * d/watch: use watch version 4
+  * d/patches: disable readelf tests (Closes: #860630)
+
+ -- Tomasz Buchert <tom...@debian.org>  Sun, 23 Apr 2017 19:43:10 +0200
+
 python-pyelftools (0.24-1) unstable; urgency=medium
 
   * Imported Upstream version 0.24
diff -Nru python-pyelftools-0.24/debian/compat 
python-pyelftools-0.24/debian/compat
--- python-pyelftools-0.24/debian/compat2016-08-09 00:29:51.0 
+0200
+++ python-pyelftools-0.24/debian/compat2017-04-23 19:43:10.0 
+0200
@@ -1 +1 @@
-9
+10
diff -Nru python-pyelftools-0.24/debian/control 
python-pyelftools-0.24/debian/control
--- python-pyelftools-0.24/debian/control   2016-08-09 00:29:51.0 
+0200
+++ python-pyelftools-0.24/debian/control   2017-04-23 19:43:10.0 
+0200
@@ -2,7 +2,7 @@
 Section: python
 Priority: extra
 Maintainer: Tomasz Buchert <tom...@debian.org>
-Build-Depends: debhelper (>= 9), dh-python, python, python3
+Build-Depends: debhelper (>= 10), dh-python, python, python3
 Standards-Version: 3.9.8
 Homepage: https://github.com/eliben/pyelftools
 Vcs-Git: git://anonscm.debian.org/collab-maint/python-pyelftools.git
diff -Nru 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
--- 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
   1970-01-01 01:00:00.0 +0100
+++ 
python-pyelftools-0.24/debian/patches/0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
   2017-04-23 19:43:10.0 +0200
@@ -0,0 +1,21 @@
+From: Tomasz Buchert <tom...@debian.org>
+Date: Sun, 23 Apr 2017 19:40:32 +0200
+Subject: Don't run readelf tests, because they are fragile and arch-specific.
+
+---
+ test/all_tests.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/all_tests.py b/test/all_tests.py
+index 4cb8e3c..6467af8 100755
+--- a/test/all_tests.py
 b/test/all_tests.py
+@@ -22,7 +22,7 @@ def main():
+ return 1
+ run_test_script('test/run_all_unittests.py')
+ run_test_script('test/run_examples_test.py')
+-run_test_script('test/run_readelf_tests.py')
++# run_test_script('test/run_readelf_tests.py')
+ 
+ if __name__ == '__main__':
+ sys.exit(main())
diff -Nru python-pyelftools-0.24/debian/patches/series 
python-pyelftools-0.24/debian/patches/series
--- python-pyelftools-0.24/debian/patches/series1970-01-01 
01:00:00.0 +0100
+++ python-pyelftools-0.24/debian/patches/series2017-04-23 
19:43:10.0 +0200
@@ -0,0 +1 @@
+0001-Don-t-run-readelf-tests-because-they-are-fragile-and.patch
diff -Nru python-pyelftools-0.24/debian/watch 
python-pyelftools-0.24/debian/watch
--- python-pyelftools-0.24/debian/watch 2016-08-09 00:29:51.0 +0200
+++ python-pyelftools-0.24/debian/watch 2017-04-23 19:43:10.0 +0200
@@ -1,3 +1,3 @@
-version=3
+version=4
 opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/python-pyelftools-$1\.tar\.gz/ \
   https://github.com/eliben/pyelftools/tags .*/v?(\d\S*)\.tar\.gz

Bug#860446: gravit segmentation violation

[Tomasz Buchert]

tags 860446 + reproducible
severity 860446 normal
thanks

On 21/04/17 01:16, Tim Retout wrote:
> retitle 860446 gravit: Segmentation violation on start (on i386?)
> tags 860446 moreinfo
> thanks
>
> For what it's worth, gravit starts for me on amd64, with intel graphics.
>
> The last call in the ltrace output is glClear... my guess is that this
> may be related to graphics drivers, if it's not architecture specific?
>
> Nils: can I check which graphics drivers you are using, in case it is
> relevant?  Meanwhile someone should try running gravit on another i386
> system...
>
> --
> Tim Retout 

I cannot reproduce this in a i386 chroot. I managed to pass my Intel GPU
inside with systemd-nspawn and everything seems to work.

I'm marking this as unreproducible and lower priority.

Tomasz


signature.asc
Description: PGP signature

Bug#858806: gbp-buildpackage: reset all time-stamps to last changelog entry

[Tomasz Buchert]

On 31/03/17 13:17, Dominique Dumont wrote:
> On Wednesday, 29 March 2017 19:17:26 CEST Guido Günther wrote:
> > What about reassigning to pristine-tar? I
> > wonder why it doesn' try to preserve timestamps.
>
> Good idea
>
> --
>  https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
> http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Hello,
I fail to see that pristine-tar is (or even can be) at fault here.
Pristine-tar knows nothing about debian/changelog file so it cannot
set modification times to last changelog entry. In fact, the only
thing that pristine-tar cares about is recreating tarballs that were
fed into it.

It is true that pristine-tar sets times to zero on checked in files,
but if you investigate further you will find that it also generates a
binary delta between this "adjusted tarball" and the original tarball
to fix such things.

Maybe I'm missing something, but I really think the problem lays
somewhere else.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#858744: nghttp2-proxy: nghttpx fails to start at boot due to missing dns resolver

[Tomasz Buchert]

Package: nghttp2-proxy
Version: 1.20.0-1
Severity: normal

Dear Maintainer,
when nghttpx starts at boot, the dns resolver may not be available and then the
start fails. More surprisingly, this also happens for explicit ip addresses and
port addresses such as 127.0.0.1:80.

The upstream bug is https://github.com/nghttp2/nghttp2/issues/857

Cheers.



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nghttp2-proxy depends on:
ii  init-system-helpers  1.47
ii  libc-ares2   1.12.0-1
ii  libc62.24-9
ii  libev4   1:4.22-1
ii  libgcc1  1:6.3.0-10
ii  libjansson4  2.9-1
ii  libjemalloc1 3.6.0-9.1
ii  libnghttp2-141.20.0-1
ii  libspdylay7  1.3.2-2.1
ii  libssl1.11.1.0e-1
ii  libstdc++6   6.3.0-10
ii  libsystemd0  232-19
ii  libxml2  2.9.4+dfsg1-2.2
ii  lsb-base 9.20161125
ii  openssl  1.1.0e-1
ii  python   2.7.13-2
ii  zlib1g   1:1.2.8.dfsg-5

nghttp2-proxy recommends no packages.

nghttp2-proxy suggests no packages.

-- Configuration Files:
/etc/nghttpx/nghttpx.conf changed [not included]

-- no debconf information

Bug#857546: profanity: Server certificates are not verified

[Tomasz Buchert]

On 12/03/17 13:53, Wolfgang Wiedmeyer wrote:
> Package: profanity
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Dear Maintainer,
>
> Profanity is not built against libmesode[1]. Libmesode is a fork of
> libstrophe that allows to validate the certificate chain. Upstream bug
> #280 provides more information[2]. Libmesode doesn't seem to be packaged
> yet in Debian.
>
> If Profanity does not verify the xmpp server's certificate using
> Debian's store of known CA certificates, users' passwords, text messages
> and other sensitive information can be intercepted.
>
> Best regards,
> Wolfgang
>

Hi Wolfgang,

it seems unlikely that we will be able to fix this for stretch. This
would require a new package upload and this is already a
no-go. Personally I think that forking libstrophe in the first place
was not a great idea, but I may lack some context.

I don't know what will be the best to proceed. Maybe we can clearly
specify in the manpage/--help/during-the-first-run that profanity does
not verify cert chains and the user is responsible for providing a safe
channel, via SSH tunnel or similar, for example?

Tomasz


signature.asc
Description: PGP signature

Bug#856223: unblock: profanity/0.4.7-1.1

[Tomasz Buchert]

Control: tags -1 -moreinfo

On 12/03/17 10:55, Ivo De Decker wrote:
> Control: tags -1 moreinfo
>
> Hi,
>
> On Tue, Feb 28, 2017 at 11:43:02PM +0100, Tomasz Buchert wrote:
>
> [...]
>
> > > > On 26/02/17 18:51, Jonathan Wiltshire wrote:
> > > > > Control: tag -1 confirmed moreinfo
> > > > >
> > > > > [...]
> > > > >
> > > > > You should close the bug in your changelog, and you do not mention the
> > > > > metadata changes in patch fix_spelling_error. With those corrections,
> > > > > please go ahead and remove the moreinfo tag from this bug.
>
> [...]
>
> > > Doesn't seem to have been uploaded?
>
> > Hi Jonathan,
> > I read here [1], that:
> > "Prepare an upload targeting testing-proposed-updates but do not
> > upload it, and then contact us through an unblock bug."
> >
> > I'm a bit confused.
>
> When Jonathan wrote 'please go ahead' above, that was your approval to do the
> upload to testing-proposed-updates. To avoid any further confusion: you can go
> ahead and upload the package based on your debdiff. After the upload, please
> remove the moreinfo tag from this bug report.
>
> Cheers,
>
> Ivo

That makes sense :). Done!

Tomasz


signature.asc
Description: PGP signature

Bug#856223: unblock: profanity/0.4.7-1.1

[Tomasz Buchert]

On 28/02/17 18:04, Jonathan Wiltshire wrote:
> On 2017-02-26 19:16, Tomasz Buchert wrote:
> > Control: tag -1 -moreinfo
> >
> > On 26/02/17 18:51, Jonathan Wiltshire wrote:
> > > Control: tag -1 confirmed moreinfo
> > >
> > > [...]
> > >
> > > You should close the bug in your changelog, and you do not mention the
> > > metadata changes in patch fix_spelling_error. With those corrections,
> > > please go ahead and remove the moreinfo tag from this bug.
> > >
> > > Thanks,
> >
> > Done. I attach a new debdiff as well.
> >
> > Tomasz
>
> Doesn't seem to have been uploaded?
>
> Thanks,

Hi Jonathan,
I read here [1], that:
"Prepare an upload targeting testing-proposed-updates but do not
upload it, and then contact us through an unblock bug."

I'm a bit confused.

Tomasz

[1] https://release.debian.org/stretch/freeze_policy.html


signature.asc
Description: PGP signature

Bug#855930: Bug#853119: Request to take a look at #855930

[Tomasz Buchert]

On 26/02/17 23:49, Vincent Danjean wrote:
> [...]
>
> And, for more info:
> $ mkdir p
> $ HOME=p lualatex lualatex-example.tex
> This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
> [...]
> luaotfload | db : Font names database not found, generating new one.
> luaotfload | db : This can take several minutes; please be patient.(compiling 
> luc: /var/li
> b/texmf/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(compiling luc: 
> p/
> .texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(sa
> ve: 
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.l
> ua)(save: 
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-reg
> ular.luc)))
> [...]
> $ find p
> p
> p/.texlive2016
> p/.texlive2016/texmf-var
> p/.texlive2016/texmf-var/luatex-cache
> p/.texlive2016/texmf-var/luatex-cache/generic
> p/.texlive2016/texmf-var/luatex-cache/generic/names
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.luc
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-names.lua.gz
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-names.luc
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.lua
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.lua
> $
>
> So lulaatex seems to really use the HOME directory.
>
>   Regards,
> Vincent
>

Wow, a really nice find!

Tomasz


signature.asc
Description: PGP signature

Bug#841526: pristine-tar: please use natural ordering when listing

[Tomasz Buchert]

On 23/10/16 19:24, Mattia Rizzolo wrote:
> On Sun, Oct 23, 2016 at 09:09:53PM +0200, Tomasz Buchert wrote:
> > What about piping "pristine-tar list" to "sort -V"?
>
> Sure, that works, but IMHO this should be done by pristine-tar itself.
> Actually I've never been so bothered to pipe it through `sort -V`, and I
> filed this bug just to ease a itch, but I do think it would be an
> improvement :)
>

After having some reservations about this, I decided to introduce it
in the next release of pristine-tar (to be released after the release
of stretch). However, this is "unofficial" in a sense that, yes, it's
going to sort using "sort -Vr", but you should not rely on this in
scripts, for example. Hope this works for you. :)

Tomasz


signature.asc
Description: PGP signature

Bug#856223: unblock: profanity/0.4.7-1.1

[Tomasz Buchert]

Control: tag -1 -moreinfo

On 26/02/17 18:51, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed moreinfo
>
> [...]
>
> You should close the bug in your changelog, and you do not mention the
> metadata changes in patch fix_spelling_error. With those corrections,
> please go ahead and remove the moreinfo tag from this bug.
>
> Thanks,

Done. I attach a new debdiff as well.

Tomasz
diff -Nru profanity-0.4.7/debian/changelog profanity-0.4.7/debian/changelog
--- profanity-0.4.7/debian/changelog	2015-09-26 16:47:33.0 +0200
+++ profanity-0.4.7/debian/changelog	2017-02-25 18:29:37.0 +0100
@@ -1,3 +1,11 @@
+profanity (0.4.7-1.1) testing-proposed-updates; urgency=medium
+
+  * Non-maintainer upload
+  * Fix CVE-2017-5592 (Closes: #854735)
+  * Update debian/patches with gbp import/export (side effect of the above fix)
+
+ -- Tomasz Buchert <tom...@debian.org>  Sat, 25 Feb 2017 18:29:37 +0100
+
 profanity (0.4.7-1) unstable; urgency=medium
 
   * Imported Upstream version 0.4.7
@@ -43,4 +51,3 @@
   * Initial release (Closes: #745872)
 
  -- Dariusz Dwornikowski <dariusz.dwornikow...@cs.put.poznan.pl>  Wed, 27 Aug 2014 12:34:59 +0200
-
diff -Nru profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch
--- profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch	1970-01-01 01:00:00.0 +0100
+++ profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch	2017-02-25 18:29:37.00000 +0100
@@ -0,0 +1,41 @@
+From: Tomasz Buchert <tom...@buchert.pl>
+Date: Sat, 25 Feb 2017 17:01:33 +0100
+Subject: Import the patch fixing CVE-2017-5592.
+
+The patch was provided by the upstream author.
+---
+ src/xmpp/message.c   | 7 +++
+ tests/functionaltests/test_carbons.c | 2 +-
+ 2 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/src/xmpp/message.c b/src/xmpp/message.c
+index 5581521..f6bb864 100644
+--- a/src/xmpp/message.c
 b/src/xmpp/message.c
+@@ -687,6 +687,13 @@ _handle_carbons(xmpp_stanza_t * const stanza)
+ return FALSE;
+ }
+ 
++Jid *my_jid = jid_create(jabber_get_fulljid());
++const char *const stanza_from = xmpp_stanza_get_attribute(stanza, STANZA_ATTR_FROM);
++if (g_strcmp0(my_jid->barejid, stanza_from) != 0) {
++log_warning("Invalid carbon received, from: %s", stanza_from);
++return TRUE;
++}
++
+ char *name = xmpp_stanza_get_name(carbons);
+ if ((g_strcmp0(name, "received") == 0) || (g_strcmp0(name, "sent")) == 0) {
+ xmpp_stanza_t *forwarded = xmpp_stanza_get_child_by_ns(carbons, STANZA_NS_FORWARD);
+diff --git a/tests/functionaltests/test_carbons.c b/tests/functionaltests/test_carbons.c
+index 96639d6..3bbe65d 100644
+--- a/tests/functionaltests/test_carbons.c
 b/tests/functionaltests/test_carbons.c
+@@ -70,7 +70,7 @@ receive_carbon(void **state)
+ prof_output_exact("unencrypted");
+ 
+ stbbr_send(
+-""
++""
+ ""
+ ""
+ ""
diff -Nru profanity-0.4.7/debian/patches/fix_spelling_error profanity-0.4.7/debian/patches/fix_spelling_error
--- profanity-0.4.7/debian/patches/fix_spelling_error	2015-09-26 16:47:33.0 +0200
+++ profanity-0.4.7/debian/patches/fix_spelling_error	2017-02-25 18:29:37.0 +0100
@@ -1,10 +1,16 @@
-Author: Dariusz Dwornikowski <dariusz.dwornikow...@cs.put.poznan.pl> 
-Subject: Fix spelling errors
-Last-Update: 2015-09-25
-Forwarded: not-needed
+From: Dariusz Dwornikowski <dariusz.dwornikow...@cs.put.poznan.pl>
+Date: Sat, 25 Feb 2017 17:03:17 +0100
+Subject: Fix spelling errors.
+
+---
+ src/xmpp/iq.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/xmpp/iq.c b/src/xmpp/iq.c
+index 496e9ca..6466eb5 100644
 --- a/src/xmpp/iq.c
 +++ b/src/xmpp/iq.c
-@@ -861,13 +861,13 @@
+@@ -861,13 +861,13 @@ _version_result_handler(xmpp_conn_t * const conn, xmpp_stanza_t * const stanza,
  
  xmpp_stanza_t *query = xmpp_stanza_get_child_by_name(stanza, STANZA_NAME_QUERY);
  if (query == NULL) {
diff -Nru profanity-0.4.7/debian/patches/series profanity-0.4.7/debian/patches/series
--- profanity-0.4.7/debian/patches/series	2015-09-26 16:47:33.0 +0200
+++ profanity-0.4.7/debian/patches/series	2017-02-25 18:29:37.0 +0100
@@ -1 +1,2 @@
 fix_spelling_error
+0002-Import-the-patch-fixing-CVE-2017-5592.patch


signature.asc
Description: PGP signature

Bug#856225: unblock: sugar-irc-activity/8-1.3

[Tomasz Buchert]

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

Please unblock package sugar-irc-activity

It fixes the RC bug #855925. I've already uploaded the package to the unstable
DELAYED/3 queue.

The debdiff: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=855925;filename=sugar-irc-activity-8-1.3-nmu.diff;msg=10

unblock sugar-irc-activity/8-1.3

Bug#856223: unblock: profanity/0.4.7-1.1

[Tomasz Buchert]

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

Please unblock package profanity

It fixes the RC bug #854735. Note that this unblock request is for an upload
targeting testing-proposed-updates.

Debdiff: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=854735;filename=profanity-0.4.7-1.1-nmu.diff;msg=15

unblock profanity/0.4.7-1.1

Bug#856222: unblock: sugar-physics-activity/7+dfsg-1.3

[Tomasz Buchert]

Here is the unwrapped debdiff link:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=855932;filename=sugar-physics-activity-7%2Bdfsg-1.3-nmu.diff;msg=20


signature.asc
Description: PGP signature

Bug#856222: unblock: sugar-physics-activity/7+dfsg-1.3

[Tomasz Buchert]

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

Please unblock package sugar-physics-activity

The attached change fixes #855932.
I've already uploaded the package to DELAYED/3 (unstable).

Here is the relevant debdiff:
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=855932;filename=sugar-
physics-activity-7%2Bdfsg-1.3-nmu.diff;msg=20

unblock sugar-physics-activity/7+dfsg-1.3

Bug#855925: sugar-irc-activity: diff for NMU version 8-1.3

[Tomasz Buchert]

My mistake again! I included a wrong e-mail in the last upload
changelog.  Here is the right debdiff. Will upload to DELAYED/3
as soon as dcut does its job.diff -Nru sugar-irc-activity-8/debian/changelog sugar-irc-activity-8/debian/changelog
--- sugar-irc-activity-8/debian/changelog	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/changelog	2017-02-26 18:09:56.0 +0100
@@ -1,3 +1,10 @@
+sugar-irc-activity (8-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove broken deps (Closes: #855925)
+
+ -- Tomasz Buchert <tom...@debian.org>  Sun, 26 Feb 2017 18:09:56 +0100
+
 sugar-irc-activity (8-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sugar-irc-activity-8/debian/control sugar-irc-activity-8/debian/control
--- sugar-irc-activity-8/debian/control	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/control	2017-02-26 18:09:56.0 +0100
@@ -11,8 +11,8 @@
  debhelper (>= 6),
  cdbs (>= 0.4.67~),
  python (>= 2.6.6-3~),
- python-sugar-0.88 | python-sugar,
- python-sugar-toolkit-0.88 | python-sugar-toolkit,
+ python-sugar,
+ python-sugar-toolkit,
  unzip
 Standards-Version: 3.9.1.0
 Vcs-Git: git://git.debian.org/collab-maint/sugar-irc-activity.git
@@ -31,9 +31,9 @@
  Sugar has since grown into a more widely usable low-resource desktop
  environment for kids.
  .
- This Activity allows you to contact other Sugar users and enthusiasts 
- on the internet and chat with them. It uses a system called Internet 
+ This Activity allows you to contact other Sugar users and enthusiasts
+ on the internet and chat with them. It uses a system called Internet
  Relay Chat, or IRC for short. There are several IRC channels for Sugar
- users and developers. It defaults to a "room" called #sugar, but you 
- can also enter other rooms by typing /join #room where room is the  
+ users and developers. It defaults to a "room" called #sugar, but you
+ can also enter other rooms by typing /join #room where room is the
  name of the room you wish to join.

Bug#855925: sugar-irc-activity: diff for NMU version 8-1.3

[Tomasz Buchert]

Control: tags 855925 + patch
Control: tags 855925 + pending

Dear maintainer,

I've prepared an NMU for sugar-irc-activity (versioned as 8-1.3) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

For the context of the fix, please see https://bugs.debian.org/855932.

Regards,
Tomasz
diff -Nru sugar-irc-activity-8/debian/changelog sugar-irc-activity-8/debian/changelog
--- sugar-irc-activity-8/debian/changelog	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/changelog	2017-02-26 18:09:56.0 +0100
@@ -1,3 +1,10 @@
+sugar-irc-activity (8-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove broken deps (Closes: #855925)
+
+ -- Tomasz Buchert <tom...@buchert.pl>  Sun, 26 Feb 2017 18:09:56 +0100
+
 sugar-irc-activity (8-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sugar-irc-activity-8/debian/control sugar-irc-activity-8/debian/control
--- sugar-irc-activity-8/debian/control	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/control	2017-02-26 18:09:56.0 +0100
@@ -11,8 +11,8 @@
  debhelper (>= 6),
  cdbs (>= 0.4.67~),
  python (>= 2.6.6-3~),
- python-sugar-0.88 | python-sugar,
- python-sugar-toolkit-0.88 | python-sugar-toolkit,
+ python-sugar,
+ python-sugar-toolkit,
  unzip
 Standards-Version: 3.9.1.0
 Vcs-Git: git://git.debian.org/collab-maint/sugar-irc-activity.git
@@ -31,9 +31,9 @@
  Sugar has since grown into a more widely usable low-resource desktop
  environment for kids.
  .
- This Activity allows you to contact other Sugar users and enthusiasts 
- on the internet and chat with them. It uses a system called Internet 
+ This Activity allows you to contact other Sugar users and enthusiasts
+ on the internet and chat with them. It uses a system called Internet
  Relay Chat, or IRC for short. There are several IRC channels for Sugar
- users and developers. It defaults to a "room" called #sugar, but you 
- can also enter other rooms by typing /join #room where room is the  
+ users and developers. It defaults to a "room" called #sugar, but you
+ can also enter other rooms by typing /join #room where room is the
  name of the room you wish to join.

Bug#855932: sugar-physics-activity: diff for NMU version 7+dfsg-1.3

[Tomasz Buchert]

Oh my, actually due to me building the package in stretch sbuild, it
got rejected during the upload. So now I've uploaded it to the
unstable, DELAYED/3. \o/

Tomasz


signature.asc
Description: PGP signature

Bug#855932: sugar-physics-activity: diff for NMU version 7+dfsg-1.3

[Tomasz Buchert]

Control: tags 855932 + patch
Control: tags 855932 + pending

Dear maintainer,

I've prepared an NMU for sugar-physics-activity (versioned as 7+dfsg-1.3) and
*wanted* to upload it to DELAYED/3, but since I've put it after the .changes 
file,
it got uploaded immediately. Sorry for that...

I'll ask the release team to unblock this.

Regards,
Tomasz
diff -Nru sugar-physics-activity-7+dfsg/debian/changelog sugar-physics-activity-7+dfsg/debian/changelog
--- sugar-physics-activity-7+dfsg/debian/changelog	2013-07-09 20:21:10.0 +0200
+++ sugar-physics-activity-7+dfsg/debian/changelog	2017-02-26 17:27:37.0 +0100
@@ -1,3 +1,10 @@
+sugar-physics-activity (7+dfsg-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/control: remove non-existing alternatives (Closes: #855932)
+
+ -- Tomasz Buchert <tom...@debian.org>  Sun, 26 Feb 2017 17:27:37 +0100
+
 sugar-physics-activity (7+dfsg-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sugar-physics-activity-7+dfsg/debian/control sugar-physics-activity-7+dfsg/debian/control
--- sugar-physics-activity-7+dfsg/debian/control	2013-07-09 20:21:10.0 +0200
+++ sugar-physics-activity-7+dfsg/debian/control	2017-02-26 17:26:45.0 +0100
@@ -8,8 +8,8 @@
  debhelper (>= 7.0.1),
  cdbs (>= 0.4.90~),
  python (>= 2.6.6-3~),
- python-sugar-0.88 | python-sugar,
- python-sugar-toolkit-0.88 | python-sugar-toolkit,
+ python-sugar,
+ python-sugar-toolkit,
  unzip
 Standards-Version: 3.9.1
 Homepage: http://wiki.sugarlabs.org/go/Activities/Physics