Bug#1066929: Package outdated, crippled, unfit for release

[Faidon Liambotis]

Source: bcachefs-tools
Version: 24+really1.3.4-2
Severity: serious

I don't think bcachefs-tools in its current state is fit for release.

* The package is severely behind: Debian is currently at 1.3.4. Upstream
  is at 1.6.4.

* Chronologically speaking, 1.3.4 was released in November 2023, so in
  theory, it's not that old.

  In practice, however, bcachefs is a fast-moving project, and in
  particular the past few months have been critical both in terms of
  pace, and in terms of stabilization: bcachefs was merged in the
  upstream Linux kernel, starting with v6.7, released in January 2024.
  Linux 6.8 was released this week as well, with even more fixes,
  including the ability to use the in-kernel fsck.

* Linux v6.7 entered unstable this week, which opens up the user base
  for this package quite a bit. Especially with the recent hype, others
  may be inclined to try it, and be surprised by back-and-forth metadata
  migrations between kernel and userspace, as a concrete example of a
  problem.

* Moreover, even the outdated version that we have in Debian is
  crippled, because large parts of its functionality are missing: all
  the Rust functionality included in this software, which is ever
  increasing (up to being required, in newer upstream releases). This
  has been reported previously as #1060256.

* I'd also argue that the package lacks attentive maintainership, and
  would recommend to orphan and/or find one or more comaintainers:
  - There are various packaging issues: wrong version number, branches
not pushed into git etc. etc. (most reported as #1054620)

  - There hasn't been any coordination/two-way street with upstream; I
contributed a bunch of PRs to help with the Rust integration bits in
Debian, and I know Steinar was in touch with them as well, but none
of this was done by the package maintainer or in coordination with
them.
 
  - No serious effort was made to package the Rust bits before. I worked
on it and made it happen with only a few hours of work, as
documented in that bug report above.

  - There hasn't been any coordinated system integration effort with
other Debian packages like grub/initramfs-tools/etc. #1061525
describes issues that are across projects and up for us, the
distributor, to really triage and coordinate fixes for.
  
  - Finally, while a bunch of work happened by others, like myself
paving the road for the Rust bits to be enabled, and by Steinar to
prepare fixed packages (and even an NMU), there hasn't been an
appropriate level of response to our contributions IMHO, that would
have included in an upload that includes all of these fixes. We are
basically blocked.

Now, I realize that the maintainer may be quite busy with other tasks,
including what I can only image is a busy Debian workload due to some
other, erm, duties (for which I'm thankful!). In an effort to be more
collegial, I've even reached out in private, twice. But, I think we are
at the point where weeks pass while the state of this package is simply
not OK, a disservice to our users, and unfit for release, hence this RC
bug. This is a filesystem we're talking about, so outdated/buggy
software can even mean broader system-wide issues including data
corruption.

In terms of a path forward: I would recommend to upload the package as
prepared by Steinar ASAP, and/or submit an RFH/O for the long-term
maintainership of the package.

Best,
Faidon

Bug#1060440: llvm-toolchain-17: 1:17.0.6-4 FTBFS on i386, armel

[Faidon Liambotis]

On Thu, Jan 11, 2024 at 01:02:47PM +, Simon McVittie wrote:
> It looks as though these are already known and already fixed in the
> packaging git repo.

Correct. I introduced these breakages with a couple of recent MRs, and
hopefully fixed them with #130. I asked Sylvestre to hold off until we
have build logs from all (official) architectures, so that's why these
aren't fixed in unstable yet. (mips64el and risv64 are still building,
although mips64el has never built LLVM 17, and my changes are not
expected to fix that.)

Faidon

Bug#1058090: marked as pending in oscrypto

[Faidon Liambotis]

Control: tag -1 pending

Hello,

Bug #1058090 in oscrypto reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/oscrypto/-/commit/d0be684e1101c03b62f2cf413305c73053d1fe8d


Release 1.3.0-5, with imp -> importlib backport

* Team upload.
* Backport patch from upstream git to replace the use of the "imp" module,
  which has been removed from Python, by "importlib".

Closes: #1058090


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1058090

Bug#1058090: oscrypto: FTBFS: ModuleNotFoundError: No module named 'imp'

[Faidon Liambotis]

Control: tags -1 + fixed-upstream

Dear maintainer,

On Tue, Dec 12, 2023 at 08:58:48AM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
> 
>
> >   File "/<>/tests/__init__.py", line 4, in 
> > import imp
> > ModuleNotFoundError: No module named 'imp'
> > 

This seems to have been fixed upstream by
https://github.com/wbond/oscrypto/commit/3865f5d528740aa1205d16ddbee84c5b48aeb078

("imp" was replaced by "importlib" in upstream Python.)

So hopefully it's just a matter of a simple backport. Do you have the
time to handle it, or would you like someone else from the Python team
(such as myself) to handle it instead?

Thanks,
Faidon

Bug#1036697: asterisk: CVE-2023-27585

[Faidon Liambotis]

Dear Jonas,

On Mon, Aug 07, 2023 at 03:51:51PM +0300, Faidon Liambotis wrote:
> Dear maintainer, security team,
> 
> (See #1032092 for a similar bug with an almost equivalent response)

I've seen that you've uploaded a couple new upstream releases of
Asterisk in the time since my last response.

Given these are severity: grave bugs, and I believe are most likely
resolved, would it be possible for you to have a look here?

Thanks,
Faidon

Bug#1042609: sphinxcontrib-mermaid: FTBFS with Sphinx 7.1, docutils 0.20: Could not import sphinx.util.SphinxParallelError (exception: No module named 'sphinx.util.SphinxParallelError')

[Faidon Liambotis]

Hi,

This is now RC, which means sphinxcontrib-mermaid has been marked for
autoremoval, including its reverse dependencies (one of which I
maintain).

On Sun, Jul 30, 2023 at 08:30:07PM +0200, Lucas Nussbaum wrote:
> sphinxcontrib-mermaid fails to build with Sphinx 7.1 and docutils 0.20, both 
> of which
> are currently available in experimental.
> 
> Relevant part (hopefully):
> [...]
> > reading sources... [ 50%] index
> > 
> > Mermaid error:
> > Could not import sphinx.util.SphinxParallelError (exception: No module 
> > named 'sphinx.util.SphinxParallelError')

Upstream commit 6f8de39¹, the only commit since 0.9.2, replaces
sphinx.util.SphinxParallelError by sphinx.util.DownloadFiles. 

I've verified that backporting this commit makes the package build
successfully in unstable, with Sphinx 7.2.6-2.

However, the very same commit changes requirements.txt from
"Sphinx>=3.2.1" to "Sphinx<7".

I'm not sure why. I'm not using, nor am I familiar with this plugin, so
I was hoping someone else that is could perhaps validate whether besides
being able to be built, the package actually works.

Hope this helps,
Faidon

1: 
https://github.com/mgaitan/sphinxcontrib-mermaid/commit/6f8de39a84fddc398542e9d4dc74ba55101e7d5e

Bug#1055392: wasmedge: autopkgtest regression: 'cstdint' file not found

[Faidon Liambotis]

Control: affects 1052002 - wasmedge
Control: affects 1052002 + src:wasmedge

On Thu, Nov 09, 2023 at 09:52:04AM +0100, Paul Gevers wrote:
> > Hi Paul,
> > Thank you for your report. This is caused #1052002, which I had marked
> > as affects: wasmedge previously.
> 
> Sorry for not checking that, but because you marked it as affecting the
> *binary* package wasmedge, it doesn't show up looking for bugs in the source
> package wasmedge (that may be a bts bug). Because this is a FTBFS issue, I
> recommend you to mark it affects src:wasmedge instead of wasmedge.

Alright, fair enough. Hopefully fixed above?

> > Also, I'm not sure I understand how clang migrated to testing when it
> > introduced an autopkgtest regression in another package. Isn't
> > autopkgtest integration in britney supposed to prevent this kind of
> > thing from happening?
> 
> britney prevents this kind of things currently only for *direct* reverse
> (test) dependencies. In this case we have:
> 
> test/Depends: clang (from src:llvm-defaults) -> (Depends) clang-16
> 
> As I'm pretty sure you meant not clang, but one of the versioned clang
> packages, britney didn't see the breakage. There are multiple ways to
> improve this:
> * britney should look at all transitive dependencies (we lack the resources
> and also not environmentally friendly)
> * britney could be taught to translate (automatically or via configuration)
> "-defaults" packages to their real packages. This would be good for multiple
> ecosystems, patches welcome.
> * Individual packages that are sensitive could use the
> `hint-testsuite-triggers` trick from the autopkgtest spec [1] and add the
> current real packages. That's a PITA to maintain though, and adding versions
> that you don't really test is wrong.

Hrm, that's useful context and in hindsight makes a lot of sense. Thanks
so much for spending the time to explain this to me!

In the meantime, I'll mark the embed-cxx test as flaky in the next
WasmEdge upload until the clang-16 bug gets fixed.

Best,
Faidon

Bug#1055392: wasmedge: autopkgtest regression: 'cstdint' file not found

[Faidon Liambotis]

Hi Paul,

On Sun, Nov 05, 2023 at 01:45:34PM +0100, Paul Gevers wrote:
> Source: wasmedge
> Version: 0.13.4+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
> 
> Dear maintainer(s),
> 
> Your package has an autopkgtest, great. However, it fails. Can you please
> investigate the situation and fix it? I copied some of the output at the
> bottom of this report.
> 
> The release team has announced [1] that failing autopkgtest on amd64 and
> arm64 are considered RC in testing.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> [...]
>
> 140s #   `clang++ --target=wasm32-wasi -o fibonacci.wasm
> -mexec-model=reactor script/fibonacci.cpp' failed
> 140s # In file included from script/fibonacci.cpp:1:
> 140s # script/fibonacci.h:3:10: fatal error: 'cstdint' file not found

Thank you for your report. This is caused #1052002, which I had marked
as affects: wasmedge previously.

Basically, the autopkgtest compiles a piece of code (with Clang) and
tries to run it (with WasmEdge). The Clang++ regression means the code
cannot be built.

I don't know how you'd like ot handle this w.r.t. the BTS, and testing
migrations. I'm inclined to just reassign/merge it to the bug above, but
I'll wait for your opinion first.

Also, I'm not sure I understand how clang migrated to testing when it
introduced an autopkgtest regression in another package. Isn't
autopkgtest integration in britney supposed to prevent this kind of
thing from happening?

Looking for your guidance,
Faidon

Bug#1052002: firefox: FTBFS: ERROR: Cannot find wasi headers or problem with the wasm compiler. Please fix the problem. Or build with --without-wasm-sandboxed-libraries

[Faidon Liambotis]

Control: reopen -1
Control: found -1 1:16.0.6-17

This is still not fixed :( Mike's findings still stand:

On Sat, Sep 16, 2023 at 05:53:55AM +0900, Mike Hommey wrote:
> This is a regression from the upgrade to clang 16.
> 
> with clang 14:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/include/wasm32-wasi/c++/v1
>  /usr/lib/llvm-14/lib/clang/14.0.6/include
>  /usr/local/include
>  /usr/include/wasm32-wasi
>  /usr/include
> End of search list.
> 
> with clang 16:
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/llvm-16/lib/clang/16/include
>  /usr/local/include
>  /usr/include/wasm32-wasi
>  /usr/include
> End of search list.
> 
> Note how /usr/include/wasm32-wasi/c++/v1 is missing.

Test case:
  $ apt install clang lld libclang-rt-dev-wasm32 libc++-dev-wasm32
  $ cat > hello.cpp <
  
  int main() {
std::cout << "hello world" << std::endl;
return 0;
  }
  EOF
  $ /usr/bin/clang++ -v --target=wasm32-wasi hello.cpp

Only C++ include paths are affected, not C. This almost certainly has to
do with the patch we carry for wasm include paths, that I have
contributed to. Unfortunately I have no time to look into it right now
:( I may find some time in a couple of weeks, but hoping someone else
can take care of it in the meantime :/

Best,
Faidon

Bug#1051815: wasmedge - autopkgtest failure with rustc 1.68

[Faidon Liambotis]

Control: reassign -1 rustc 1.68.2+dfsg1-1
Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)

On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:
> The autopkgtests for wasmedge fail with rustc 1.68, I have observed this with
> both testing and unstable's versions of wasmedge, and with both testing and
> unstable's versions of wasi-lib.

Thanks for the report. Actually, I think the WasmEdge autopkgtests are
catching a rustc 1.68 regression, whereas rustc compiles wasm32 binaries
that do not work with neither WasmEdge, nor Wasmtime (the latter is not
in Debian).

Very simple test case:

$ podman run --rm -it debian:sid  # or bookworm to test with rustc 1.67

root@ad697f1c195f:~# apt install rustc libstd-rust-dev-wasm32
[...]
root@ad697f1c195f:~# rustc -V
rustc 1.68.2
root@ad697f1c195f:~# cat > hello.rs 

Bug#1050439: Requires Sphinx >= v6.0 while unstable has v5.3

[Faidon Liambotis]

Source: furo
Version: 2023.08.19+dfsg-1
Severity: grave

furo 2023.08.19+dfsg-1 requires Sphinx v6.0:
  $ grep -r 'require_sphinx(' /usr/lib/python3/dist-packages/furo
  /usr/lib/python3/dist-packages/furo/__init__.py:app.require_sphinx("6.0")

However:
  $ rmadison -s unstable python3-sphinx
  python3-sphinx | 5.3.0-7   | unstable   | all

This makes furo unusable:
  $ python3 -m sphinx -N -bhtml docs/ build/html
  Running Sphinx v5.3.0
  making output directory... done
  
  Sphinx version error:
  The furo extension used by this project needs at least Sphinx v6.0; it 
therefore cannot be built with this version.

...and breaks unrelated packages build-depending on it. I encountered
this while trying to upload a new version of tox. I'd expect the same
for the 29 packages Build-Depending on furo.

I don't know what to do at this point -- it's perhaps worth checking
with the Sphinx maintainer to see if they intend to upload a newer
version of Sphinx in the coming (very few) days, as 7.1 is already
staged in experimental.

Otherwise, backing out the commits that require the version bump, or the
version altogether, ASAP seems necessary given the impact crater.

In any case, I'd strongly suggest adding some kind of test (either at
build-time, or autopkgtests, ideally both) to avoid this kind of thing
from accidentally happening again. We're humans and bound to miss
something like that over time, so adding safeguards seems prudent :)

Regards,
Faidon

Bug#1032092: asterisk: CVE-2022-23537 CVE-2022-23547 CVE-2022-39269

[Faidon Liambotis]

Dear maintainer, security team,

(See #1036697 for a similar bug with an almost equivalent response)

The changelog for the asterisk 1:20.4.0~dfsg+~cs6.13.40431414-1 upload
dated 2023-08-04, currently in unstable, mentions:
>+ fixate component pjproject at upstream release 2.13.1

The sources seem to indeed indicate that the version shipped for
pjproject (aka PJSIP) is 2.13.1, which seems to have resolved the
vulnerabilities listed below. 

Specifically:

On Mon, Feb 27, 2023 at 08:48:36PM +0100, Moritz Mühlenhoff wrote:
> CVE-2022-23537[0]:
> | PJSIP is a free and open source multimedia communication library
> | written in C language implementing standard based protocols such as
> | SIP, SDP, RTP, STUN, TURN, and ICE. Buffer overread is possible when
> | parsing a specially crafted STUN message with unknown attribute. The
> | vulnerability affects applications that uses STUN including PJNATH and
> | PJSUA-LIB. The patch is available as a commit in the master branch
> | (2.13.1).
> 
> https://github.com/pjsip/pjproject/security/advisories/GHSA-9pfh-r8x4-w26w
> https://github.com/pjsip/pjproject/commit/d8440f4d711a654b511f50f79c0445b26f9dd1e1

Upstream says "Patched versions: 2.13.1" in the GitHub GHSA URL above.

> CVE-2022-23547[1]:
> | PJSIP is a free and open source multimedia communication library
> | written in C language implementing standard based protocols such as
> | SIP, SDP, RTP, STUN, TURN, and ICE. This issue is similar to
> | GHSA-9pfh-r8x4-w26w. Possible buffer overread when parsing a certain
> | STUN message. The vulnerability affects applications that uses STUN
> | including PJNATH and PJSUA-LIB. The patch is available as commit in
> | the master branch.
> 
> https://github.com/pjsip/pjproject/security/advisories/GHSA-cxwq-5g9x-x7fr
> https://github.com/pjsip/pjproject/commit/bc4812d31a67d5e2f973fbfaf950d6118226cf36

Upstream says "Patched versions: 2.13.1" in the GitHub GHSA URL above.

> CVE-2022-39269[2]:
> | PJSIP is a free and open source multimedia communication library
> | written in C. When processing certain packets, PJSIP may incorrectly
> | switch from using SRTP media transport to using basic RTP upon SRTP
> | restart, causing the media to be sent insecurely. The vulnerability
> | impacts all PJSIP users that use SRTP. The patch is available as
> | commit d2acb9a in the master branch of the project and will be
> | included in version 2.13. Users are advised to manually patch or to
> | upgrade. There are no known workarounds for this vulnerability.
> 
> https://github.com/pjsip/pjproject/security/advisories/GHSA-wx5m-cj97-4wwg
> https://github.com/pjsip/pjproject/commit/d2acb9af4e27b5ba75d658690406cec9c274c5cc

Upstream says "Patched versions: 2.13" in the GitHub GHSA URL above.

> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> [...]
>
> Please adjust the affected versions in the BTS as needed.

As I'm neither the maintainer nor in the security team, I'm leaving
these actions to you. Hopefully simple enough, once you confirm my
findings :)

Regards,
Faidon

Bug#1036697: asterisk: CVE-2023-27585

[Faidon Liambotis]

Dear maintainer, security team,

(See #1032092 for a similar bug with an almost equivalent response)

The changelog for the asterisk 1:20.4.0~dfsg+~cs6.13.40431414-1 upload
dated 2023-08-04, currently in unstable, mentions:
>+ fixate component pjproject at upstream release 2.13.1

The sources seem to indeed indicate that the version shipped for
pjproject (aka PJSIP) is 2.13.1, which seems to have resolved the
vulnerabilities listed below.

Specifically:

On Wed, May 24, 2023 at 02:51:41PM +0200, Moritz Mühlenhoff wrote:
> CVE-2023-27585[0]:
> | PJSIP is a free and open source multimedia communication library
> | written in C. A buffer overflow vulnerability in versions 2.13 and
> | prior affects applications that use PJSIP DNS resolver. It doesn't
> | affect PJSIP users who do not utilise PJSIP DNS resolver. This
> | vulnerability is related to CVE-2022-24793. The difference is that
> | this issue is in parsing the query record `parse_query()`, while the
> | issue in CVE-2022-24793 is in `parse_rr()`. A patch is available as
> | commit `d1c5e4d` in the `master` branch. A workaround is to disable
> | DNS resolution in PJSIP config (by setting `nameserver_count` to zero)
> | or use an external resolver implementation instead.
> 
> https://github.com/pjsip/pjproject/security/advisories/GHSA-q9cp-8wcq-7pfr
> https://github.com/pjsip/pjproject/security/advisories/GHSA-p6g5-v97c-w5q4
> https://github.com/pjsip/pjproject/commit/d1c5e4da5bae7f220bc30719888bb389c905c0c5

Upstream says "Patched versions: 2.13.1" in the first GitHub GHSA URL
above (for CVE-2023-27585), and "Patched versions: 2.12.1 or later" for
the second one (for CVE-2022-24793).

> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> [...]
> 
> Please adjust the affected versions in the BTS as needed.

As I'm neither the maintainer nor in the security team, I'm leaving
these actions to you. Hopefully simple enough, once you confirm my
findings :)

Regards,
Faidon

Bug#1042193: wasmedge: FTBFS: ld: ../../lib/api/libwasmedge.so.0.0.3: undefined reference to `WasmEdge::Fault::emitFault(WasmEdge::ErrCode)'

[Faidon Liambotis]

Control: forwarded -1 https://github.com/WasmEdge/WasmEdge/issues/2695
Control: tags -1 + patch

On Wed, Jul 26, 2023 at 09:50:12PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> 
> Relevant part (hopefully):
> > /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now -Wl,--export-dynamic -rdynamic 
> > CMakeFiles/wasmedge.dir/wasmedge.cpp.o -o wasmedge  
> > -Wl,-rpath,"\$ORIGIN/../../lib/api::" 
> > ../../lib/api/libwasmedge.so.0.0.3 
> > /usr/lib/x86_64-linux-gnu/libspdlog.so.1.10.0 
> > /usr/lib/x86_64-linux-gnu/libfmt.so.9.1.0 
> > /usr/bin/ld: ../../lib/api/libwasmedge.so.0.0.3: undefined reference to 
> > `WasmEdge::Fault::emitFault(WasmEdge::ErrCode)'
> > collect2: error: ld returned 1 exit status

Thanks Lucas, that's super helpful!

I tracked down the trigger to the gcc-12 -> gcc-13 migration. I think
I've tracked down the root cause as well, and reported a one-line fix to
the upstream issue above. I'll give upstream a couple of days to
validate my assumptions before I make an upload.

Regards,
Faidon

Bug#1042337: gdnsd: FTBFS: dh_auto_test: error: make -j8 test "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Faidon Liambotis]

Control: forwarded -1 https://github.com/gdnsd/gdnsd/issues/236

On Wed, Jul 26, 2023 at 10:20:11PM +0200, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks Lucas. I had noticed that already and have been trying to figure
out a fix for it, as seen by the upstream issue above.

FTR, this is caused by a recent upload of Net::DNS, which I had al
Net::DNS minor releases breaking gdnsd's test suite has been a bit of a
pattern. https://github.com/gdnsd/gdnsd/pull/229 was a similar issue
that happened during the bookworm lifecycle.

I'll give it another go; if I'm unable to track it down, I may just turn
off "make check" entirely :(

Thanks,
Faidon

Bug#1031716: python3-protobuf: Do reverse dependencies need stricter version constraints?

[Faidon Liambotis]

On Tue, Feb 21, 2023 at 02:23:34PM +0200, Adrian Bunk wrote:
> Looking at #1028371, should generated dependencies on python3-protobuf be
>   python3-protobuf (>= 3.21), python3-protobuf (<< 3.22)
> to ensure that the binary package is used with the same version
> as the protobuf-compiler used during the build?

I'm not the maintainer, but a drive-by contributor. I looked a bit into
this, given its RC severity. 

With my still somewhat limited understanding, a strict version alignment
between protobuf-compiler and python3-protobuf would probably resolve
this particular symptom, but the issues here seem to run deeper.

Specifically:
  * The protobuf project provides three different versions of Python
bindings: pure Python, C++, and libupb-based[1]. These are
selectable using the PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION
environment variable.

  * Debian's python3-protobuf, from src:protobuf, ships the pure Python
version, as well as the C++ bindings. The default implementation in
Debian is "cpp".

  * The upb implementation is not included in src:protobuf, but in the
upb upstream source[2], i.e. what is src:upb in Debian, even though
the snapshot we have in Debian does not contain sources to Python
bindings.

  * Upstream has switched the default implementation to "upb", and
deprecated the "cpp" implementation. There is, in fact, no way for
one to fetch the "cpp" version from PyPI. This is documented
extensively in their May 2022 release notes[3]. However, Debian
still ships, and defaults to, cpp, a major departure from upstream. 

  * Relatedly, when they made that switch, they also made changes to
their versioning scheme, disconnecting the Python library's version
from the source version. As a result, the Python API (both upb, as
well as pure Python), is now versioned at "4.21", rather than
"3.21". The Debian binary package python3-protobuf is versioned as
"3.21.12-1", which is not a version that exists, or will ever exist,
upstream. That binary package in fact, is shipping an egg named
protobuf-4.21.12.egg-info. (This is all also well documented in their
release notes[3]).

  * Finally, in the same release notes document[3], they also state:
"Python upb requires generated code that has been generated from
protoc 3.19.0 or newer.". 

Indeed, if one fetches protobuf 4.21 from PyPI, and runs:
  python3 -c 'import bernhard'
or
  PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=upb python3 -c 'import bernhard'

...a traceback message is emitted, but a much more informative one:
> TypeError: Descriptors cannot not be created directly.
>
> If this call came from a _pb2.py file, your generated code is out of
> date and must be regenerated with protoc >= 3.19.0.
>
> If you cannot immediately regenerate your protos, some other possible 
workarounds are:
> 1. Downgrade the protobuf package to 3.20.x or lower.
> 2. Set PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python (but this will
> use pure-Python parsing and will be much slower).
>
> More information: 
https://developers.google.com/protocol-buffers/docs/news/2022-05-06#python-updates
  
  * The release notes specifically mention "upb" requiring protoc
(protobuf-compiler) >= 3.19, but not "cpp". However, as established
above, "cpp" is deprecated and not used by anyone (but Debian), and
therefore they either meant "the non-Pure-Python implementation"
there, or did not pay as much attention to forward- and
backwards-compatibility, or informative error messages for their
deprecated backend. It's likely, but not entirely clear, that the
protoc dependency requirement is >= 3.19 here as well.

  * Finally note that the 3.21.12-1+b2 Python implementation still works
with python3-bernhard, Built-Using:  protobuf-compiler (= 3.12.4-1+b3):
  PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python python3 -c 'import bernhard'

All in all: it's almost certainly necessary to make the dependency
tighter, to something like >= 3.19, if not tight to = 3.21.

I still feel uneasy about Debian shipping a version of python3-protobuf
that includes, and defaults to, an implementation that is deprecated
upstream (and on top of it, is misversioned). I'm not sure what to make
of this so late in the release cycle, though.

For trixie the path forward is probably something along the lines of
updating src:upb to a newer upstream, building the upb-based extension
as python3-protobuf-upb, and then changing src:protobuf to not build the
cpp extension, make python3-protobuf Arch: all, and then Recommend (or
Depend) on python3-protobuf-upb as the native/fast implementation.

Faidon

1: https://github.com/protocolbuffers/protobuf/tree/main/python
2: https://github.com/protocolbuffers/upb/tree/main/python
3: https://protobuf.dev/news/2022-05-06/

Bug#983719: esptool: Version 3.0 fixes critical bugs

[Faidon Liambotis]

On Thu, Feb 23, 2023 at 12:16:41PM +0200, Faidon Liambotis wrote:
> I also have changes underway for 4.5, but currently looking into what it
> would take dependency-wise to accomplish this, as there are 1-2 new
> Python module dependencies that are not present in Debian yet. I'll
> follow up once I have something; I expect this to be in the next week or
> so.

I packaged the two new dependencies mentioned above:
 * python-reedsolo, which entered unstable this week; and 
 * python-pkcs11 (used only conditionally, for espsecure's HSM bits),
   which is waiting in NEW for about a week now.

I moved the repository to the DEP-14 layout, rebased the
feature/2.8-update branch, and then built on top of it in the new
debian/experimental branch. This now has 4.5.1, with lots of other fixes
and flasher stubs! I'd consider this a release candidate for an
experimental upload once pkcs11 passes through NEW.

Faidon

Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Faidon Liambotis]

On Wed, Mar 08, 2023 at 09:41:21AM +, Simon McVittie wrote:
> > there is a metapackage, libc++-dev-wasm32, which Depends on the
> > default implementation, which is libc++-14-dev-wasm32 right now. That
> > metapackage has at least one notable reverse B-D, firefox, using it to
> > build certain security/sandboxing features (RLBox[1], AIUI). That is to
> > say, this feature works (w/ 14) and does very useful things today. it
> > (seemingly) broke when it was ported to llvm-toolchain-15, which
> > src:firefox does not depend on directly.
> 
> If I understand correctly, that doesn't *necessarily* have to be RC for
> bookworm, because llvm-toolchain-15 is not (yet!) the default version
> of LLVM provided by the metapackage, and is only used by Mesa? But it
> would be a blocker for either moving the default forward from 14 to 15
> (as has already been done in experimental), or making Firefox use the
> non-default 15 toolchain like Mesa does, presumably to get some new
> feature or optimization that isn't in 14?

At least as I also understand it, that's right. 

I think it'd be a pity to revert this for 15 and we should aim for
feature parity between the two branches, but disabling it is, and can
remain an option as a plan B given where we are in the bookworm release
cycle. That's IMHO, with a biased view, as the wasm patches author, but
ultimately up to the maintainer (which is definitely not me ;).

I'm hopeful we can address the underlying issue quickly though, and I
propose to put a hold to this conversation for the time being and see
where we get with a proper resolution first. I just posted a patch in
the other bug report. Fingers crossed.

Faidon

Bug#1029010: llvm-toolchain-15: autopkgtest regression

[Faidon Liambotis]

On Fri, Mar 03, 2023 at 05:46:15PM +, Simon McVittie wrote:
> I've cut down what I think is the root cause of this compile failure to
> a more minimal bug report: see #1032317.

That's super helpful, thanks :) Spoiler alert: I have a suspicion on the
root cause, I'll follow up there.

> I don't think this is *really* a regression, because in the version in
> bookworm, the autopkgtest didn't exercise compilation of C++ into
> WebAssembly at all.

This statement strictly speaking is true, but applies only if you look
at LLVM 15 in isolation. It *is* a regression, in the sense that this
works with llvm-toolchain-14, where the WebAssembly work was first
pushed, today, in both bookworm and sid. For example, retracing your
steps in #1032317 with s/15/14/ does not result into a failure.

> If I understand correctly, when compared with bookworm, the version in
> sid adds a new feature (the necessary -dev packages for compiling C++ into
> WebAssembly) and also adds a smoke-test for that feature, but the feature
> doesn't yet work as intended. Is that accurate?

Kind of -- again, strictly speaking, true for libc++-15-dev-wasm32.
However, there is a metapackage, libc++-dev-wasm32, which Depends on the
default implementation, which is libc++-14-dev-wasm32 right now. That
metapackage has at least one notable reverse B-D, firefox, using it to
build certain security/sandboxing features (RLBox[1], AIUI). That is to
say, this feature works (w/ 14) and does very useful things today. it
(seemingly) broke when it was ported to llvm-toolchain-15, which
src:firefox does not depend on directly.

1: https://rlbox.dev/

Regards,
Faidon

Bug#983719: esptool: Version 3.0 fixes critical bugs

[Faidon Liambotis]

On Tue, Feb 21, 2023 at 02:16:40PM +0200, Faidon Liambotis wrote:
> I should note that while the package seems to meet the criteria for
> Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
> it properly in the long run either. I'm happy to do a one-off NMU to
> bring it to a more decent shape, however.

Update: I pushed a branch into the main repo, feature/2.8-update, that
just brings up the packaging to modern standards and switches to using
pybuild -- a step necessary given new upstream releases are now using
Python modules etc.

This is still tagged as a 2.8+dfsg-1.1 release that builds the package
as-is with enhancements and no regressions.

I also have changes underway for 4.5, but currently looking into what it
would take dependency-wise to accomplish this, as there are 1-2 new
Python module dependencies that are not present in Debian yet. I'll
follow up once I have something; I expect this to be in the next week or
so.

Regards,
Faidon

Bug#1026858: Dependency on debconf dropped prematurely

[Faidon Liambotis]

Hi!

On Thu, Dec 22, 2022 at 11:06:05PM +0100, Cyril Brulebois wrote:
> Faidon Liambotis  (2022-12-22):
> > Going forward there are a few options:
> >   * Revert the change and depend on debconf again. This is the safest
> > option, as this has been the status quo since 2007.
> 
> That would look good to me.

Great -- thanks to the both of you for the quick response!

> I'll admit outright that I didn't try and figure out the whole cdebconf
> vs. debconf situation, what we would be trying to fix, and what the
> benefits would be. But at least [1] reinforced my “should we be touching
> that? right now??” gut feeling.
> 
>  1. https://lists.debian.org/debian-boot/2022/11/msg00044.html

Ah, thank you for this pointer. I wasn't aware of this thread, and that
seems like very useful context.

Best,
Faidon

Bug#1026858: Dependency on debconf dropped prematurely

[Faidon Liambotis]

Source: cdebconf
Version: 0.265
Severity: critical

cdebconf 0.265 dropped the "debconf" dependency, that Joey Hess
"temporarily" added in 2007 with cdebconf 0.123[1]. This was added to
"avoid anyone breaking their systems by removing debconf, which
dependencies now allow".

Unfortunately, that removal was premature, and indeed, it is now
possible for someone to install cdebconf 0.265, remove debconf from
their system (which apt will happily do), and for hundreds of unrelated
random packages to break, in the same way that was reported back then
with #443627.

Example steps to reproduce:
  # on a clean chroot or container, e.g. podman run -it --rm debian:sid
  apt install -y cdebconf
  apt purge -y debconf# this was not previously possible, but now is
  # pick a random package that uses debconf, in this case tzdata
  apt purge -y tzdata # in case this was already installed
  apt install tzdata  # kaboom

I believe the reporter of #1006492 misunderstood the original change and
therefore that bug is invalid. Additionally, I believe the resolution of
#328498 to be premature, given that cdebconf is clearly not the default :)

The underlying cause is that cdebconf Provides: debconf-2.0, to indicate
that it provides the debconf 2.0 protocol, because that was its original
intention. However, it does not do so; it only did transitively, because
of the debconf dependency. Packages in the archive depend on some
variation of "debconf | debconf-2.0" expecting certain facilities
(binaries, shell libraries, etc.). However, cdebconf does NOT currently
provide any of these.

At least these differences exist:
  * cdebconf provides its binaries under /usr/lib/cdebconf, not /usr/bin
(presumably to avoid a Conflict with debconf), and thus standard
binaries that maintainer scripts (and administrators) expect, cannot
be found.
 
For example, /usr/bin/debconf-set-selections,
/usr/sbin/dpkg-preconfigure or /usr/sbin/dpkg-reconfigure.
 
  * cdebconf does not ship /usr/share/debconf/confmodule. Many
maintainer scripts expect this. tzdata, mentioned above, is one of
them.
 
  * cdebconf does not ship the Perl implementation of
Debconf::Client::ConfModule, but the debconf package does. There are
packages that expect that a "debconf-2.0" dependency will make this
available to them. For example /usr/sbin/pam-auth-update from the
libpam-runtime package uses it, but the package depends "just" on
"debconf (>= 0.5) | debconf-2.0, debconf (>= 1.5.19) | cdebconf".
 
  * Finally, cdebconf does not include a debconf-apt-progress
implementation. See #537523 for an old bug describing this, as well
as a request for the passthrough frontend.

Going forward there are a few options:
  * Revert the change and depend on debconf again. This is the safest
option, as this has been the status quo since 2007.
  
  * Remove the debconf-2.0 Provides from cdebconf. This is, arguably,
the option that would maximize correctness, given cdebconf is not
really providing the facilities expected by debconf-2.0. It's
unclear to me what this could break, though.
  
  * Longer-term... actually create feature parity between cdebconf and
debconf, potentially even switching to cdebconf by default, as Joey
originally intended. This will likely include _at least_ the
following:
- Resolving the items in #537523 (debconf-apt-progress).
- Splitting Debconf::Client::ConfModule from debconf to a
  libdebconf-client-confmodule-perl package, and either have
  cdebconf depend on it, or perform an MBF to ask downstream users
  to add this dependency explicitly. (Which of the two depends on
  whether one considers this Perl API part of the "debconf-2.0"
  protocol or not.)
- Shipping /usr/share/debconf/confmodule by cdebconf, moving
  cdebconf's binaries to /usr/bin and /usr/sbin, adding a Conflict
  again, and deprecating DEBCONF_USE_CDEBCONF.

Regards,
Faidon

1: 
https://salsa.debian.org/installer-team/cdebconf/-/commit/b4dfa070d676917f12f58cc52fe46fe2f4094fc3

Bug#1022449: python-maxminddb: diff for NMU version 2.0.3-1.1

[Faidon Liambotis]

On Sat, Nov 12, 2022 at 08:06:56AM +, stefa...@debian.org wrote:
> Hi Faidon (2022.11.11_22:25:52_+)
> > I don't mind having an NMU, though, whether targeted or for the new
> > upstream version itself.
> 
> Sure, happy to NMU a new upstream version, too. I'll 0-day NMU that.
>
> [...]
>
> > I have one small request, which would be to push the changes to the
> > git repo if you can (it's under the "debian" salsa project).
> 
> Done!
> 
\o/ That's amazing, thank you so much!

Best,
Faidon

Bug#1022449: python-maxminddb: diff for NMU version 2.0.3-1.1

[Faidon Liambotis]

On Fri, Nov 11, 2022 at 11:56:18PM +0200, Stefano Rivera wrote:
> I've prepared an NMU for python-maxminddb (versioned as 2.0.3-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Thank you so much Stefano! I've been meaning to update to the latest
upstream release for a while (alongside libmaxminddb itself), but life
has gotten busy -- I'm slowly getting there though for the past couple
of weeks :)

This is currently in the top-3 of my list, and I expect to work on this
in the next week at the latest. I don't mind having an NMU, though,
whether targeted or for the new upstream version itself. If you do make
an upload, I have one small request, which would be to push the changes
to the git repo if you can (it's under the "debian" salsa project). If
you're interested in doing further work in this package, you are also
more than welcome to add yourself to Uploaders and make this a
maintainer upload. If not, totally understandable :)

Best,
Faidon

Bug#1014306: crun - seriously out of date

[Faidon Liambotis]

On Sun, Jul 03, 2022 at 09:20:37PM +0200, Bastian Blank wrote:
> crun was not uploaded since before the release of Debian 11.  It is now
> seriously out of date and even fails hard as root, see #1012053.

I built 1.4.5 using the existing Debian packaging and with no changes
other than dropping all d/patches as they are now merged upstream. The
package is fully functional with my testing.

1.5 was released 2 days ago as well, but I haven't tried to build that
yet.

Dmitry, are you still working on this package? I noticed that it's under
the debian group in Salsa -- would you be OK if someone else made an
upload?

Thanks!
Faidon

Bug#990859: Memory leak making desktop unusable after few weeks of uptime

[Faidon Liambotis]

Package: marco
Version: 1.24.1-2
Severity: grave
Tags: patch

marco >= 1.23.2 has a memory/pixmap leak in the workspace switcher OSD,
that makes the desktop slower over time, and after a few weeks of
uptime, downright unusable. The effects can be observed using "xrestop",
where the Pxms column rises on every workspace switch.

I experienced this bug, and had to run "marco --replace" every 2-3 weeks
to mitigate. I started digging and found someone else also reported it
upstream[1], with the same symptoms.

I tracked down the root cause, and provided a fix that can be found as
PR #688[2]. This went through code review and some amendements, with the
final version merged into master a few minutes ago[3].

The commit in question applies cleanly on top of 1.24.1-2. It's pretty
small and fairly obvious.

IMHO this should be backported, and we should not release bullseye
without this fix in place.

Thanks!
Faidon

1: https://github.com/mate-desktop/marco/issues/685
2: https://github.com/mate-desktop/marco/issues/688
3: 
https://github.com/mate-desktop/marco/commit/8f204678be6d888ad1d2904e28af1aa9f2ad8e11

Bug#982740: pulseaudio: FTBFS on ppc64el

[Faidon Liambotis]

Control: tags -1 patch

On Sat, Feb 13, 2021 at 02:53:58PM -0500, Andres Salomon wrote:
> Pulseaudio is failing to build on ppc64el. The version of pulseaudio in
> bullseye suffers from a pretty serious usability bug (see #980836)
> which should arguably be a higher severity, but let's focus on getting
> 14.2-1 built properly.
> 
> https://buildd.debian.org/status/logs.php?pkg=pulseaudio=ppc64el
> 
> Here's where the ppc64el build fails:
> 
> 
> FAIL: cpu-volume-test
> =
> 
> Running suite(s): CPU
> 0%: Checks: 1, Failures: 1, Errors: 0
> tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed
> FAIL cpu-volume-test (exit status: 1)

The output of the check (src/cpu-volume-test) is:
  Running suite(s): CPU
  Initialising ORC optimized volume functions.
  Checking Orc svolume
  Correctness test failed: align=1, channels=2
  1: 3303 != d317 (a1ed * 7a36)
  0%: Checks: 1, Failures: 1, Errors: 0
  tests/cpu-volume-test.c:81:F:svolume:svolume_orc_test:0: Failed

Looking at the code of the test, that seems... not the intention:
pa_cpu_info cpu_info;
[...]
#if defined (__i386__) || defined (__amd64__)
pa_zero(cpu_info);
cpu_info.cpu_type = PA_CPU_X86;
pa_cpu_get_x86_flags(_info.flags.x86);
#endif
[...]
if (!pa_cpu_init_orc(cpu_info)) {
pa_log_info("Orc not supported. Skipping");
return;
}
[...]
pa_log_debug("Checking Orc svolume");

pa_cpu_init_orc() returns true only if cpu_info.cpu_type == PA_CPU_X86.
This should not be the case here, but cpu_info is being passed to the
function uninitialized, and... as luck would have it,
cpu_info.cpu_type's "random" contents are set to PA_CPU_X86.

So at minimum, the test is broken; initializing cpu_info as is done on
other tests is enough to fix this:

--- pulseaudio-14.2.orig/src/tests/cpu-volume-test.c
+++ pulseaudio-14.2/src/tests/cpu-volume-test.c
@@ -187,7 +187,7 @@ END_TEST

 START_TEST (svolume_orc_test) {
 pa_do_volume_func_t orig_func, orc_func;
-pa_cpu_info cpu_info;
+pa_cpu_info cpu_info = { PA_CPU_UNDEFINED, {}, false };
 int i, j;

 #if defined (__i386__) || defined (__amd64__)

I've tested this fix on plummer, and it seems to work as expected.

src/pulsecore/cpu.c has the only other invocation of pa_cpu_init_orc(),
and this seems to be initializing cpu_info properly, so this failure is
limited to the test suite and does not affect any runtime operation.

(This of course does not explain why the Orc code is broken on ppc64el.
It does not look to have been written with anything but i386/amd64 in
mind and the codepath is not meant to be running anywhere else, so
that's probably more in the "feature request" category.)

HTH!
Faidon

Bug#982632: 0.1.0 release is outdated and incompatible with podman 3.0

[Faidon Liambotis]

Package: nomad-driver-podman
Version: 0.1.0-2
Severity: grave

As discussed recently in debian-devel, nomad-driver-podman 0.1.0 works
with the podman Varlink API, which does not exist anymore in podman 3.0,
making this package unusable for all users (at least AIUI).

A new upstream release of nomad-driver-podman, 0.2.0, however, was
released with its main feature being support for the HTTP API.

Dmitry, I know you know this, but just filing this RC bug to avoid us
collectively forgetting about this and releasing bullseye with a package
combination that isn't functional for users. Hope this is helpful!

Best,
Faidon

Bug#979590: libx11-xcb1: Updating to 1.7.0-1 from 1.6.12-1 breaks chromium and google chrome

[Faidon Liambotis]

On Fri, Jan 08, 2021 at 07:30:03PM +0100, Michel Le Bihan wrote:
> After updating libx11-xcb1 chromium and google chrome UI is not
> responding to any input and clicking anywhere on the app window causes
> the GNOME app is not responding dialog to appear. The app actually is
> not frozen because if you pass a URL with dynamic web content as a
> parameter, it will be constantly updated. I didn't notice any other
> affected app, but I didn't test much.

I was experiencing the same. Both Chromium (87.0.4280.88-0.4) and Google
Chrome (87.0.4280.141-1) were entirely unusable for me.

It turned out that for me, the cause was a disparity between libx11-xcb1
and libx11-6 -- the former was at 2:1.7.0-1, while the latter was at
2:1.6.12-1 (don't ask why...). Any of the following are addressing the
issue for me:
  * Upgrading libx11-xcb1 + libx11-6 to 2:1.7.0-1 (duh)
  * Downgrading libx11-xcb1 (+ libx11-6) to 2:1.6.12-1
  * Reverting to an older version of Chromium (83.0.4103.116)
  * Google Chrome Beta (88.0.4324.79-1)

Before I realized that the issue was a version disparity, I bisected
libx11, and found that commit dbb55e1 ("Fix poll_for_response race
condition") to be the "bad" commit. Reverting that commit on top of
1.7.0-1, made the issue disappear as well.

At minimum, it looks like libx11-xcb1 and libx11-6 need to be at the
same version, so perhaps libx11-xcb1 should have a versioned depends on
libx11-6 (= ${binary:Version}). On that note, libx11-xcb1 doesn't seem
to even Depend on libc6, with libX11-xcb.so.1 being statically linked;
perhaps that's an issue of its own?

#979443 may or may not be a related bug here.

Faidon

Bug#977926: Missing required dependencies

[Faidon Liambotis]

Package: mitmproxy
Version: 5.3.0-1
Severity: grave

Installing mitmproxy in a clean sid chroot, and running it (with no arguments)
results into a large backtrace that ends with...
  pkg_resources.DistributionNotFound: The 'hyperframe>=6.0' distribution was 
not found and is required by mitmproxy

After installing the package python3-hyperframe, the error becomes:
  pkg_resources.DistributionNotFound: The 'h2>=4.0' distribution was not found 
and is required by mitmproxy
...in turn fixed by installing the package python3-h2.

It looks like at least those two dependencies are missing, preventing
the package from working out of the box in any configuration. Both of
these were in the Depends for the 4.0.4-5 version (buster's).

I did not check whether other features require more dependencies, as I'm
not too familiar with all of mitmproxy's operation modes.

Regards,
Faidon

Bug#953832: cannot allocate memory in static TLS block

[Faidon Liambotis]

Hi Andreas,

Thanks for reaching out. It sounds like this is already reported as
#951704 (Cc'ed now). I'll need to give this a closer look, but I hope I
can have an update within the next couple of weeks. Does this work?

Thanks!
Faidon

On Sun, Mar 15, 2020 at 10:33:20AM +0100, Andreas Tille wrote:
> Hi Faidon,
> 
> could you imagine to build jemalloc with --disable-initial-exec-tls
> as Sergio suggests below to fix the issue in drmaa (and possibly other
> packages)?
> 
> Should I open a separate bug report against jemalloc to request this?
> 
> Kind regards
> 
>   Andreas.
> 
> On Sat, Mar 14, 2020 at 05:18:49PM -0400, Sergio Durigan Junior wrote:
> > > $ python3
> > > Python 3.7.6 (default, Jan 19 2020, 22:34:52) 
> > > [GCC 9.2.1 20200117] on linux
> > > Type "help", "copyright", "credits" or "license" for more information.
> >  import drmaa
> > > Traceback (most recent call last):
> > >   File "", line 1, in 
> > >   File 
> > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/__init__.py",
> > >  line 65, in 
> > > from .session import JobInfo, JobTemplate, Session
> > >   File 
> > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/session.py",
> > >  line 39, in 
> > > from drmaa.helpers import (adapt_rusage, Attribute, 
> > > attribute_names_iterator,
> > >   File 
> > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/helpers.py",
> > >  line 36, in 
> > > from drmaa.wrappers import (drmaa_attr_names_t, drmaa_attr_values_t,
> > >   File 
> > > "/home/andreas/debian-maintain/salsa/med-team/python-drmaa/drmaa/wrappers.py",
> > >  line 58, in 
> > > _lib = CDLL(libpath, mode=RTLD_GLOBAL)
> > >   File "/usr/lib/python3.7/ctypes/__init__.py", line 364, in __init__
> > > self._handle = _dlopen(self._name, mode)
> > > OSError: /usr/lib/x86_64-linux-gnu/libjemalloc.so.2: cannot allocate 
> > > memory in static TLS block
> > 
> > This is an issue with jemalloc's handling of the TLS model when being
> > dlopened..  See:
> > 
> >   https://github.com/jemalloc/jemalloc/issues/1237
> > 
> > The recommended way to build a libjemalloc that is suitable for being
> > dlopened is to use '--disable-initial-exec-tls' when building it.  Take
> > a look at the INSTALL.md file, and look for this option:
> > 
> >   https://github.com/jemalloc/jemalloc/blob/dev/INSTALL.md
> > 
> > There is a way to workaround this bug by doing an LD_PRELOAD of
> > libjemalloc when invoking python, but this will only mask the problem
> > and we can't expect users to do/know this.
> > 
> > The way I see it, you can try to convince jemalloc's maintainer to
> > enable that flag.
> > 
> > BTW, the reason 'find_library' can't find drmaa's library is because the
> > .so is being installed in a non-standard directory.  I don't know why
> > the package was made like this, though.
> > 
> > Thanks,
> > 
> > -- 
> > Sergio
> > GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
> > Please send encrypted e-mail if possible
> > http://sergiodj.net/
> 
> 
> 
> -- 
> http://fam-tille.de
> 

Bug#947816: GeoLite2 databases are now non-free

[Faidon Liambotis]

On Mon, Dec 30, 2019 at 11:37:52PM -0500, Harlan Lieberman-Berg wrote:
> 
>
> Based on this license change, it seems to me that geoipupdate can no
> longer be in main.  Contrib may be a suitable home, however?

geoipupdate is already in contrib (it has always been that way). Did you
perhaps miss that, or did I misunderstood your question?

Regards,
Faidon

Bug#922449: autopkgtest with tox fails (and is ineffective)

[Faidon Liambotis]

Package: src:python-static3
Version: 0.7.0-5
Severity: serious

Hi there,

tox's (new) maintainer here. python-static3 uses "tox" as an
autopkgtest, which is currently broken and that holds a newer version of
tox from migrating to testing. (Hence setting the severity to serious)

The use of tox here as an autopkgtest doesn't make a lot of sense to me
for the following reasons:
* This currently relies on the network to work, as it fetches
  dependencies over from pypi. That could be addressed with
  --sitepackages, however.

* This also means that the tests are against dependencies from pypi, not
  the versions in Debian. That's not really a Debian package test then,
  just an upstream test, and I'm not sure what the point of that is --
  presumably upstream is already doing that given they ship a tox.ini?

* In turn, this also means that those tests may fail at any point in
  time, because of changes outside of Debian. I think this is the case
  right now while I was trying to reproduce the debci failure (I get an
  unrelated backtrace from the pypi package "kid").

* Even more to it, this tests against Python versions set by upstream,
  which are currently set to:
envlist = py26, py27, py33, py34, pypy
  The package doesn't build Python 2 binaries, so these are out; it does
  not Build-Depend on pypy so that's out too; and the Python 3 versions
  are not versions that exist in sid/testing. So these tests are really
  not for any of the Python versions shipped in Debian...

* At the end of the day, the upstream tox just has a
commands=python setup.py test []
  ...which could be the command that autopkgtest runs. However, it may
  make more sense to just run that as part of the dh_auto_test step, as
  it runs the upstream tests and not any kind of Debian integration
  tests.

TL;DR: I'd remove the autopkgtest altogether, and make sure that
"python3 setup.py" when the package builds e.g. as part of dh_auto_test.
YMMV :)

Regards,
Faidon

Bug#918742: Initialization loop/deadlock when used with jemalloc

[Faidon Liambotis]

On Wed, Jan 09, 2019 at 10:42:06PM +0100, Johannes Schauer wrote:
> Quoting Faidon Liambotis (2019-01-09 16:16:40)
> > > Until it is properly fixed upstream we can just temporarily disable
> > > --enable-prof, right?
> > We could, yes. This is a useful piece of functionality that I'd like to
> > enable, though...
> 
> but does it matter if proot disables it in its tests?
> 
> I tried this in debian/rules:
> 
> export MALLOC_CONF=prof:false
> 
> according to what I read on http://jemalloc.net/jemalloc.3.html this should
> disable --enable-prof at runtime, no?
>
> Unfortunately, the effect is the same and the testsuite never finishes but 
> gets
> stuck on the jemalloc test.

Unfortunately, the initialization code runs regardless of whether prof
was enabled or not, and from the code it seems like this is
intentional...

See here:
https://github.com/jemalloc/jemalloc/blob/5.1.0/src/prof.c#L2392
...where the relevant call to _Unwind_Backtrace is outside the "if
(opt_prof) { }" block. (The code is similar in the dev branch)

Regards,
Faidon

Bug#918742: Initialization loop/deadlock when used with jemalloc

[Faidon Liambotis]

On Wed, Jan 09, 2019 at 11:23:19AM +0100, Johannes Schauer wrote:
> Maybe you can report this directly to upstream?

I thought of that, but then I saw that upstream is Piotr, who is also
listed as a Maintainer of this package. Is that not the case?

> Until it is properly fixed upstream we can just temporarily disable
> --enable-prof, right?

We could, yes. This is a useful piece of functionality that I'd like to
enable, though...

Regards,
Faidon

Bug#918742: Initialization loop/deadlock when used with jemalloc

[Faidon Liambotis]

Package: src:fakechroot
Version: 2.19-3
Severity: serious

Hi again,

So jemalloc 5.1.0-2 was recently uploaded to unstable. The build
currently fails due to the explicit dependency on libjemalloc1 (cf.
#918741), but as soon as this gets fixed, another issue is uncovered:

While building this package, the jemalloc test deadlocks, and the build
hangs. This can be easily reproduced as follows:
  apt install libfakechroot libjemalloc2
  LD_PRELOAD="libjemalloc.so.2 libfakechroot.so" /bin/true
  

The test isn't spurious but an actual issue. One could do:
  fakechroot 
...and still hit this bug.

The bug is effectively the same as #872669, which I had previously
resolved by disabling jemalloc's --enable-prof. This option was
re-enabled in 5.x (I forgot about that bug :/) and...  I'd like to keep
it that way, so I tried to troubleshoot this further.

It looks like there's a preloading loop between those libraries that
results in deadlocking. Effectively, during its initialization
(malloc_init) jemalloc tries to initialize libgcc's unwind code
(_Unwind_Backtrace), which in turn calls dl_iterate_phdr, which is
captured by libfakechroot, which calls dlsym()/dlerror(), which tries to
allocate memory back again, which deadlocks jemalloc.

The backtrace is (note how #6 and #20 are the same):
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:103
#1  0x7fd764008704 in __GI___pthread_mutex_lock (mutex=0x7fd7647a0500 
) at ../nptl/pthread_mutex_lock.c:80
#2  0x7fd76475f0dc in malloc_mutex_lock_final (mutex=0x7fd7647a04c0 
) at include/jemalloc/internal/mutex.h:141
#3  je_malloc_mutex_lock_slow (mutex=mutex@entry=0x7fd7647a04c0 ) at 
src/mutex.c:84
#4  0x7fd76470e244 in malloc_mutex_lock (mutex=0x7fd7647a04c0 , 
tsdn=0x0) at include/jemalloc/internal/mutex.h:205
#5  malloc_init_hard () at src/jemalloc.c:1506
#6  0x7fd76471524d in malloc_init () at src/jemalloc.c:217
#7  imalloc (dopts=, sopts=) at 
src/jemalloc.c:1986
#8  calloc (num=num@entry=1, size=size@entry=32) at src/jemalloc.c:2138
#9  0x7fd763ff8a25 in _dlerror_run (operate=operate@entry=0x7fd763ff8390 
, args=args@entry=0x7ffdd14ddfa0) at dlerror.c:141
#10 0x7fd763ff840f in __dlsym (handle=, name=) at dlsym.c:70
#11 0x7fd7644f49b4 in ?? () from 
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so
#12 0x7fd7644edffc in dl_iterate_phdr () from 
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so
#13 0x7fd763ff02a1 in _Unwind_Find_FDE (pc=0x7fd763fee867 
<_Unwind_Backtrace+55>, bases=bases@entry=0x7ffdd14de368) at 
../../../src/libgcc/unwind-dw2-fde-dip.c:469
#14 0x7fd763fec983 in uw_frame_state_for 
(context=context@entry=0x7ffdd14de2c0, fs=fs@entry=0x7ffdd14de110) at 
../../../src/libgcc/unwind-dw2.c:1257
#15 0x7fd763fedb60 in uw_init_context_1 (context=0x7ffdd14de2c0, 
outer_cfa=0x7ffdd14de570, outer_ra=0x7fd76476a878 )
at ../../../src/libgcc/unwind-dw2.c:1586
#16 0x7fd763fee868 in _Unwind_Backtrace (trace=trace@entry=0x7fd76475fdb0 
, trace_argument=trace_argument@entry=0x0)
at ../../../src/libgcc/unwind.inc:295
#17 0x7fd76476a878 in je_prof_boot2 (tsd=tsd@entry=0x7fd763fd7740) at 
src/prof.c:2392
#18 0x7fd76470e308 in malloc_init_hard () at src/jemalloc.c:1538
#19 malloc_init_hard () at src/jemalloc.c:1500
#20 0x7fd764710a85 in malloc_init () at src/jemalloc.c:217

I don't think it's a bug on either library per se. I was wondering if
you had any insight on how we could address this in fakechroot somehow
rather than in jemalloc, as that doesn't look to be easy without
disabling the profiling feature.

Regards,
Faidon

Bug#918741: Build-Depends on deprecated libjemalloc SONAME directly

[Faidon Liambotis]

Package: src:fakechroot
Version: 2.19-3
Severity: serious

Hi,

I uploaded jemalloc 5.1.0-2 to unstable the other day. It involves a new
ABI and SONAME and thus a transition from libjemalloc1 -> libjemalloc2.

I noticed that your package Build-Depends directly on libjemalloc1, and
thus this package will start FTBFSing once libjemalloc1 gets removed
from the archive.

It seems like the B-D is there because the test suite includes a test
for jemalloc (which is great!), and specifically the binary library
which it's LD_PRELOADing, hence the dependency on the binary package.

Rather than s/libjemalloc1/libjemalloc2/, I would recommend to B-D on
"libjemalloc-dev" like a regular source package, and then modify the
test suite to search for the symlink "libjemalloc.so" (e.g.
/usr/lib/x86_64-linux-gnu/libjemalloc.so). This would make it future
proof for future ABI/SONAME bumps.

Apologies for filing this after the transition has already started -- as
a B-D on the binary package is unsual, it didn't occur to me to
grep-dctrl for that beforehand.

Regards,
Faidon

Bug#859675: radsecproxy: Please migrate to openssl1.1 in Buster

[Faidon Liambotis]

On Fri, Aug 10, 2018 at 11:13:56PM +0200, Moritz Mühlenhoff wrote:
> > Please migrate to libssl-dev in the Buster cycle. The bug report about
> > the FTBFS is #828527. The log of the FTBFS can be found at
> > 
> > https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/radsecproxy_1.6.7-1_amd64-20160529-1530
> 
> I've been going through the remaining OpenSSL 1.1 bugs and radsecproxy
> appears to have been fixed in the latest 1.7.1 upstream release.

Yup, 1.7 has been in the works for a while for various reasons (incl. a
change of upstream maintainer). It was finally released upstream about a
month ago and I've been working on updating the package, and have been
working with upstream on some issues (upstream #12, #13, etc.). We'll
have it in Debian soon I hope :)

Regards,
Faidon

Bug#902755: Python 3 version broken, throws exception immediately after connecting

[Faidon Liambotis]

On Sat, Jul 07, 2018 at 04:03:39PM +0300, Ilias Tsitsimpis wrote:
> On Sat, Jun 30, 2018 at 03:59PM, Faidon Liambotis wrote:
> > I went to upstream's GitHub in order to see if anyone else had reported
> > this or to submit a PR, but to my surprise, it seems like upstream's
> > repository has two different versions of imaplib2, one of them
> > designated as "py3" and reporting itself as v3.05. That version does not
> > exhibit any of these two issues above.
> 
> You are right, upstream ships two different versions of imaplib2 (with
> different version numbers), one for Python 2 and one for Python 3.
> The problem here is that the python3-imaplib2 package wrongly ships the
> Python 2 version. I will fix that with the next upload.

Thanks Ilia! The compression issue seems to be present in stretch as
well, so it might be worth hot-patching it and making an s-p-u upload.

Regards,
Faidon

Bug#902755: Python 3 version broken, throws exception immediately after connecting

[Faidon Liambotis]

Package: python3-imaplib2
Version: 2.57-2
Severity: grave

Hi,

Using this test program and Gmail as the IMAP server:
M = imaplib2.IMAP4_SSL(host=IMAP_SERVER, debug=IMAP_DEBUG)
M.login(IMAP_USERNAME, IMAP_PASSWORD)
if (compress):
M.enable_compression()

M.SELECT(mailbox=IMAP_MAILBOX, readonly=True)
M.FETCH('1:10', '(UID FLAGS)')
M.LOGOUT()

...the Python3 version of this package immediately throws an exception
after connecting and thus seems entirely broken:
  imaplib2.error: IMAP4 protocol error: program error:  - 
cannot use a bytes pattern on a string-like object

Even after fixing this, there is an additional issue that shows up only
when enabling compression:
  imaplib2.abort: command: EXAMINE => socket error:  - a 
bytes-like object is required, not 'str'

Note that even stretch's 2.55 presents the latter issue, but not the
former.

The attached patch fixes both of those issues and makes the above simple
test case work, although I haven't tried this any more complicated cases or
with different IMAP servers.

I went to upstream's GitHub in order to see if anyone else had reported
this or to submit a PR, but to my surprise, it seems like upstream's
repository has two different versions of imaplib2, one of them
designated as "py3" and reporting itself as v3.05. That version does not
exhibit any of these two issues above.

Regards,
Faidon
--- x/usr/lib/python3/dist-packages/imaplib2.py	2017-03-05 03:23:58.0 +0200
+++ /usr/lib/python3/dist-packages/imaplib2.py	2018-06-30 15:36:18.645224464 +0300
@@ -302,8 +302,8 @@
 
 
 # These must be encoded according to utf8 setting in _mode_xxx():
-_literal = br'.*{(?P\d+)}$'
-_untagged_status = br'\* (?P\d+) (?P[A-Z-]+)( (?P.*))?'
+_literal = r'.*{(?P\d+)}$'
+_untagged_status = r'\* (?P\d+) (?P[A-Z-]+)( (?P.*))?'
 
 continuation_cre = re.compile(r'\+( (?P.*))?')
 mapCRLF_cre = re.compile(r'\r\n|\r|\n')
@@ -2215,13 +2215,13 @@
 """send(data)
 Send 'data' to remote."""
 
+if bytes != str:
+data = bytes(data, 'utf8')
+
 if self.compressor is not None:
 data = self.compressor.compress(data)
 data += self.compressor.flush(zlib.Z_SYNC_FLUSH)
 
-if bytes != str:
-data = bytes(data, 'utf8')
-
 if hasattr(self.sock, "sendall"):
 self.sock.sendall(data)
 else:

Bug#825501: CVE-2016-4434

[Faidon Liambotis]

On Thu, Jan 18, 2018 at 10:36:24PM +0100, Salvatore Bonaccorso wrote:
> > > That link says:
> > >   Versions Affected: 
> > >   Apache Tika 0.10 to 1.12
> > > 
> > > So perhaps 1.5 isn't affected after all? I tried to find the relevant
> > > commit in the upstream git but failed :(
> > 
> > Commit 
> > https://github.com/apache/tika/commit/f444fd784b99b181cd7bd54cdec9fbd132b4ef93
> > in 1.17 added a test case, so this might be related to changes in Xerces/J
> > which are possibly bundled by Tika downloads? Might be worth clarifying with
> > Tim Allison .
> 
> Above, you said "so perhaps 1.5 isn't affected after all?". But why
> this conclusion? 1.5 as currently in unstable and oldstable present
> falls within the affected range of 0.15 and 1.12.

s/0.15/0.10/ in what you said just above, but yes, you're obviously
right and I misread the range. Apologies for the confusion -- I guess I
was too enthusiastic in trying to figure out an easy way out of this :)

> So yes, maybe Tim Allison can help identify which are the required
> commits, but best course might just to try to update to the newest
> upstream version for unstable.

Indeed! (but note that I'm not the maintainer)

Thanks,
Faidon

Bug#825501: CVE-2016-4434

[Faidon Liambotis]

On Fri, May 27, 2016 at 11:58:33AM +0200, Moritz Muehlenhoff wrote:
> please see http://seclists.org/oss-sec/2016/q2/413  for details.

That link says:
  Versions Affected: 
  Apache Tika 0.10 to 1.12

So perhaps 1.5 isn't affected after all? I tried to find the relevant
commit in the upstream git but failed :(

Regards,
Faidon

Bug#843926: jemalloc hard codes page size during build

[Faidon Liambotis]

On Tue, Nov 07, 2017 at 05:07:42PM +, James Cowgill wrote:
> Ah nevermind - I see it FTBFS in experimental on lots of arches.

Yeah, I've fixed some in git already and been working with upstream on a
lot of those (upstream #761, #979, #985, #999). They've been extremely
collaborative (and even trying to make sure breakages on non-x86 won't
happen again, #1044).

I'm currently waiting for either a backport of one of the fixes or a
release, the latter being blocked on them figuring out their release
strategy (#1049).

Regards,
Faidon

Bug#877896: certspotter: FTBFS on mips{,el}

[Faidon Liambotis]

Hi Julien!

On Fri, Oct 06, 2017 at 10:13:11PM +0200, Julien Cristau wrote:
> certspotter FTBFS on the mips and mipsel buildds with no useful error message:
> 
> > dh_auto_build: go install 
> > -gcflags=\"-trimpath=/<>/obj-mips-linux-gnu/src\" 
> > -asmflags=\"-trimpath=/<>/obj-mips-linux-gnu/src\" -v -p 4 
> > software.sslmate.com/src/certspotter 
> > software.sslmate.com/src/certspotter/cmd 
> > software.sslmate.com/src/certspotter/cmd/certspotter 
> > software.sslmate.com/src/certspotter/cmd/ctparsewatch 
> > software.sslmate.com/src/certspotter/cmd/submitct 
> > software.sslmate.com/src/certspotter/ct 
> > software.sslmate.com/src/certspotter/ct/client returned exit code 1
> > debian/rules:4: recipe for target 'build-arch' failed
> > make: *** [build-arch] Error 1

The error message is one line above from the paste above:
  go build golang.org/x/text/unicode/norm: /usr/bin/mips-linux-gnu-gccgo-7: 
waitid: bad address

…and this points to #867358, which seems to be a kernel bug affecting Go
packages. It's apparently fixed in 4.13 and queued up for (but not yet
in) stretch. I've known of this FTBFS and been tracking this bug for a
while, it's been moving slowly :/

Once that fix reaches stretch and runs in the buildds, I'll ask for a
give-back. We can keep this bug open until then.

Regards,
Faidon

Bug#877261: jemalloc: FTBFS on 32-bit archs: operator new/delete symbols have changed

[Faidon Liambotis]

Hi Andreas,

Thanks for the bug report.

On Fri, Sep 29, 2017 at 10:55:59PM +0200, Andreas Beckmann wrote:
> jemalloc 5 FTBFS on all 32-bit architectures since the signatures for
> operator new/delete have changed with GCC 7:

I don't think it's a GCC 7 issue. I think it was just a packaging error
on my side, where I used "unsigned long" as the argument,
unconditionally, while it's (obviously, in hindsight) "unsigned int" on
32-bit architectures.  (Note that jemalloc 5.0.1-1 is the first one with
C++ ABI, so this is all new)

I've fixed this in git a while ago[1] but haven't uploaded because that
version has a bunch of FTBFSes in other architectures, that I've been
engaging with upstream about[2][3]. It's taking longer than I originally
expected, but still, it's in experimental, so I didn't think there was
much point in making a new upload that builds in a few more
architectures but still fails on many.

Regards,
Faidon

1: 
https://anonscm.debian.org/cgit/collab-maint/jemalloc.git/commit/?h=experimental=4dc71357fd2a3f77ab63476d0da4f0d5581463d9
2: https://github.com/jemalloc/jemalloc/issues/979
3: https://github.com/jemalloc/jemalloc/issues/999

Bug#854842: diamond takes a while to stop, errors out, slows down shutdown

[Faidon Liambotis]

On Fri, Feb 10, 2017 at 08:18:42PM -0500, Sandro Tosi wrote:
> is this really a serious bug which `is a severe violation of Debian
> policy (roughly, it violates a must or required directive), or, in the
> package maintainer's or release manager's opinion, makes the package
> unsuitable for release.` ?

Well, you're the package maintainer, so… that's ultimately up to you :)

As a user, what I can say is that slowing reboots down for a minute
(systemd showing the red error bar and says that's waiting for it), as
well as taking a minute to restart e.g. every time puppet pushes a new
config, is not an acceptable behavior for this kind of package. We have
diamond installed in ~1200 servers or so (currently v3.0) and this kind
of behavior would get annoying real quick.

> i will forward this upstream

Thanks!

Regards,
Faidon

Bug#854842: diamond takes a while to stop, errors out, slows down shutdown

[Faidon Liambotis]

Source: diamond
Version: 4.0.515-3
Severity: serious

In my setup, diamond takes a long time to stop after getting a SIGTERM
from systemd, thus slowing down the overall shutdown of the system by
about a minute (and also making it slow to perform restarts). When it
finally does stop, an error message about QueueHandler is emitted. The
issue is reproducible without systemd too -- run diamond in one terminal
with --log-stdout --foreground and then run kill from another terminal
(Ctrl+C i.e. SIGINT won't reproduce it). This happens even with a
relatively minimal config, e.g. without any Collectors defined and only
with a single GraphiteHandler.

What I see here is:
root@d-i-test:/etc/diamond# diamond --log-stdout --foreground
1486775151.66   [MainProcess:9336:INFO] Changed UID: 0 () GID: 0 ().
1486775152.06   [MainProcess:9336:DEBUG]metric_queue_size: 16384
1486775152.06   [MainProcess:9336:DEBUG]Loading Handler 
diamond.handler.graphite.GraphiteHandler
1486775152.1[MainProcess:9336:DEBUG]GraphiteHandler: Established 
connection to graphite server 10.192.16.33:2003.
1486775152.11   [Handlers:9347:DEBUG]   Starting process Handlers
1486775153.12   [TCPCollector:9350:DEBUG]   Starting
1486775153.12   [TCPCollector:9350:DEBUG]   Interval: 60.0 seconds
1486775153.13   [TCPCollector:9350:DEBUG]   Max collection time: 28 seconds
1486775153.16   [TCPCollector:9350:DEBUG]   Collection took 32 ms
1486775154.14   [NetworkCollector:9353:DEBUG]   Starting
1486775154.14   [NetworkCollector:9353:DEBUG]   Interval: 60.0 seconds
1486775154.14   [NetworkCollector:9353:DEBUG]   Max collection time: 19 seconds
1486775154.16   [NetworkCollector:9353:DEBUG]   Collection took 16 ms
1486775155.15   [DiskUsageCollector:9356:DEBUG] Starting
1486775155.15   [DiskUsageCollector:9356:DEBUG] Interval: 60.0 seconds
1486775155.15   [DiskUsageCollector:9356:DEBUG] Max collection time: 48 seconds
1486775155.15   [DiskUsageCollector:9356:DEBUG] Collection took 1 ms
1486775156.16   [CPUCollector:9359:DEBUG]   Starting
1486775156.16   [CPUCollector:9359:DEBUG]   Interval: 60.0 seconds
1486775156.16   [CPUCollector:9359:DEBUG]   Max collection time: 43 seconds
1486775156.17   [CPUCollector:9359:DEBUG]   Collection took 7 ms

1486775186.96   [MainProcess:9336:INFO] Signal Received: 15
1486775186.96   [NetworkCollector:9353:INFO]Signal Received: 15
1486775186.96   [Handlers:9347:INFO]Signal Received: 15
1486775186.96   [DiskUsageCollector:9356:INFO]  Signal Received: 15
1486775186.96   [TCPCollector:9350:INFO]Signal Received: 15
1486775186.96   [CPUCollector:9359:INFO]Signal Received: 15
1486775186.97   [NetworkCollector:9353:INFO]Signal Received: 15
1486775186.97   [CPUCollector:9359:INFO]Signal Received: 15

Exception socket.error: error(111, 'Connection refused') in > ignored

While this long wait is happening, strace shows diamond is busylooping
running this over and over (apparently python multiprocessing related):
connect(4, {sa_family=AF_UNIX, sun_path="/tmp/pymp-xq1DKs/listener-8_h02F"}, 
34) = -1 ECONNREFUSED (Connection refused)
close(4)= 0
select(0, NULL, NULL, NULL, {tv_sec=0, tv_usec=1}) = 0 (Timeout)
socket(AF_UNIX, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR)   = 0

Let me know if I can help in any way.

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Bug#826636: The screensaver fails to hide the second screen in dual screen configuration

[Faidon Liambotis]

On Tue, Jan 24, 2017 at 03:57:08PM +, Mike Gabriel wrote:
> I just spoke to the developer who worked on PR #110 for mate-screensaver. He
> said that one of the two commits was for beautifications, the one that made
> it into 1.16.1 is the actual fix-up commit.

That's great :)

> Saying this, is the issue now solved, since mate-screensaver 1.16.1-1 has
> landed in Debian stretch?

I'm confused -- I don't see 1.16.1-1 in neither stretch nor sid. They
seem to both have 1.16.0-1.

Regards,
Faidon

Bug#828527: radsecproxy: FTBFS with openssl 1.1.0

[Faidon Liambotis]

forwarded 828527 https://project.nordu.net/browse/RADSECPROXY-66
tags 828527 + pending
thanks

On Sun, Jun 26, 2016 at 12:23:56PM +0200, Kurt Roeckx wrote:
> OpenSSL 1.1.0 is about to released.  During a rebuild of all packages using
> OpenSSL this package fail to build.  A log of that build can be found at:
> https://breakpoint.cc/openssl-1.1-rebuild-2016-05-29/Attempted/radsecproxy_1.6.7-1_amd64-20160529-1530

I've been in contact for a while with upstream regarding this.  This was
filed as https://project.nordu.net/browse/RADSECPROXY-66 and has been
fixed in the meantime.

The fixes are unfortunately quite invasive (a series of commits) and
can't be easily backported. Linus has stated that he will release these
as part of 1.7.1, but he's tracking down some OpenSSL 1.0
incompatibilities at the moment.

I'll upload 1.7.1 as soon as it gets released.

Regards,
Faidon

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Faidon Liambotis]

reopen 831529
reassign 831529 libavcodec57 7:3.1.1-2
forcemerge 831909 831529
thanks

Hi,

On Sun, Jul 24, 2016 at 02:53:57PM +0200, Sebastian Ramacher wrote:
> On 2016-07-24 14:19:36, Sebastian Ramacher wrote:
> > On 2016-07-22 13:27:09, Faidon Liambotis wrote:
> > > On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> > > > Unfortunately I am unable to reproduce the issue. Since there are some 
> > > > accounts
> > > > of random crashes when building ffmpeg with tree vectorization enabled, 
> > > > I've
> > > > uploaded 7:3.1.1-3 with vectorization disabled. Could you please check 
> > > > if the
> > > > issue disappears with -3?
> > > 
> > > I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
> > > crashes.

I followed what the reporter of #831529 suggested: I first tried to "apt
install --reinstall gstreamer1.0-libav", which had no effect. I then
upgraded to the version from experimental, ran gst-launch again, then
downgraded to the version from unstable, which also seem to not crash
now(!).

I'm not very familiar with the gstreamer/libav/libva stack and thus
would like some help to get to the bottom of this. Frankly, I still
don't understand why x264 and VA-API is even at play here, when it's
just a pipeline of parsing a wav into a fakesink.

Regardless, I'm keeping this as an ffmpeg bug though (and at grave), as
the crashes started with the recent ffmpeg upgrade and the backtraces
seem to suggest that the abort() is coming from ffmpeg.

Thanks,
Faidon

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Faidon Liambotis]

On Sun, Jul 24, 2016 at 02:53:57PM +0200, Sebastian Ramacher wrote:
> On 2016-07-24 14:19:36, Sebastian Ramacher wrote:
> > Thank you for the info. Could you please let us know the version of libva1 
> > and
> > i965-va-driver that you have installed?
> 
> … and the versions of all other libva1-* packages.

All of the above[1] are at 1.7.1-1. I run a pretty standard up-to-date
testing -- with the exception of all ffmpeg packages from sid, as
previously requested.

Faidon

1:
ii  i965-va-driver:amd64 1.7.1-1 amd64 VAAPI driver for Intel G45 & HD Graphics 
fami
ii  libva-drm1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
DRM 
ii  libva-glx1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
GLX 
ii  libva-wayland1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
Wayl
ii  libva-x11-1:amd641.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
X11 
ii  libva1:amd64 1.7.1-1 amd64 Video Acceleration (VA) API for Linux -- 
runt

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Faidon Liambotis]

On Fri, Jul 22, 2016 at 10:21:05AM +0200, Sebastian Ramacher wrote:
> Unfortunately I am unable to reproduce the issue. Since there are some 
> accounts
> of random crashes when building ffmpeg with tree vectorization enabled, I've
> uploaded 7:3.1.1-3 with vectorization disabled. Could you please check if the
> issue disappears with -3?

I upgraded all ffmpeg packages to 7:3.1.1-3 but I'm still experiencing
crashes.

I then installed libavcodec57-dbgsym, libgstreamer1.0-0-dbg,
gstreamer1.0-libav-dbg and gstreamer1.0-plugins-good-dbg. The full
backtrace is below. The "codec = " seems
relevant, since this is on an Intel Broadwell, which may not be the case
for you. This looks a lot like #831529, doesn't it?

I still don't exactly understand how H.264/VA-API are related when playing
just a .wav file, though... This was with the same gstreamer pipeline,
  gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  !
  wavparse ! audioconvert ! fakesink


#0  0x76fc01c8 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x76fc164a in __GI_abort () at abort.c:89
#2  0x7fffeda6260b in init_context_defaults (s=s@entry=0x70095720, 
codec=codec@entry=0x7fffee3a8900 )
at src/libavcodec/options.c:142
#3  0x7fffeda626d6 in avcodec_alloc_context3 (codec=0x7fffee3a8900 
) at src/libavcodec/options.c:163
#4  0x7fffef360540 in gst_ffmpeg_cfg_install_property 
(klass=0x70095200, base=8) at gstavcfg.c:732
#5  0x7fffef356e53 in gst_ffmpegvidenc_class_init (klass=0x70095200)
at gstavvidenc.c:225
#6  0x7788c22d in g_type_class_ref (pclass=0x70094690, 
node=0x70094500) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
#7  0x7788c22d in g_type_class_ref (type=type@entry=140737220527360)
at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
#8  0x77b09da4 in gst_element_register (plugin=plugin@entry=0x69bbf0 
[GstPlugin], name=name@entry=0x7006d110 "avenc_h264_vaapi", 
rank=rank@entry=128, type=type@entry=140737220527360) at gstelementfactory.c:243
#9  0x7fffef3575b3 in gst_ffmpegvidenc_register 
(plugin=plugin@entry=0x69bbf0 [GstPlugin]) at gstavvidenc.c:1009
#10 0x7fffef349e20 in plugin_init (plugin=0x69bbf0 [GstPlugin])
at gstav.c:158
#11 0x77b2b537 in gst_plugin_register_func (plugin=0x69bbf0 
[GstPlugin], desc=0x7fffef578180 , user_data=0x0) at 
gstplugin.c:523
#12 0x77b2d425 in _priv_gst_plugin_load_file_for_registry 
(filename=0x6c2e20 "/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so", 
registry=0x61c150 [GstRegistry], registry@entry=0x0, 
error=error@entry=0x74de7bf0)
at gstplugin.c:826
#13 0x77b2dcea in gst_plugin_load_file (filename=, 
error=error@entry=0x74de7bf0) at gstplugin.c:680
#14 0x77b2e12c in gst_plugin_load_by_name (name=0x6c218d "libav")
at gstplugin.c:1265
#15 0x77b2ea8d in gst_plugin_feature_load 
(feature=feature@entry=0x6e58a0 [GstTypeFindFactory]) at gstpluginfeature.c:111
#16 0x77b547e3 in gst_type_find_factory_call_function (factory=0x6e58a0 
[GstTypeFindFactory], find=0x74de7c90) at gsttypefindfactory.c:210
#17 0x75d89421 in gst_type_find_helper_for_data (obj=obj@entry=0x812070 
[GstWavParse], data=, size=, 
prob=prob@entry=0x74de7db4) at gsttypefindhelper.c:535
#18 0x75d895a4 in gst_type_find_helper_for_buffer 
(obj=obj@entry=0x812070 [GstWavParse], buf=buf@entry=0x70003450, 
prob=prob@entry=0x74de7db4)
at gsttypefindhelper.c:591
#19 0x75b3546a in gst_wavparse_add_src_pad (wav=wav@entry=0x812070 
[GstWavParse], buf=0x70003450) at gstwavparse.c:1908
#20 0x75b35b47 in gst_wavparse_stream_data (wav=wav@entry=0x812070 
[GstWavParse]) at gstwavparse.c:2061
#21 0x75b3bbb1 in gst_wavparse_loop (pad=0x8042a0 [GstPad])
at gstwavparse.c:2202
#22 0x77b4fe71 in gst_task_func (task=0x81c050 [GstTask])
at gsttask.c:332
#23 0x775bc55e in g_thread_pool_thread_proxy (data=) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthreadpool.c:307
#24 0x775bbbc5 in g_thread_proxy (data=0x81a800) at 
/build/glib2.0-vjfO_h/glib2.0-2.48.1/./glib/gthread.c:780
#25 0x77335464 in start_thread (arg=0x74de8700) at 
pthread_create.c:333
#26 0x7707430d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109


Thanks,
Faidon

Bug#831909: gstreamer coredumps when playing wavs since the libavcodec upgrade

[Faidon Liambotis]

Package: libavcodec57
Version: 7:3.1.1-2
Severity: grave

I ran Debian testing on my desktop. Since about a day ago, pidgin
started crashing unexpectedly. After a little bit of debugging, I found
that it reproducibly crashes when trying to play sounds. Going a step
further, I made the test case as simple as:

$ gst-launch-1.0 filesrc location=/usr/share/sounds/purple/alert.wav  ! 
wavparse ! audioconvert !  fakesink
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Aborted (core dumped)

My dpkg.log has a bunch of ffmpeg-related package upgrades, including
libavcodec57, being installed on 2016-07-18, approximately when those
crashes started. Because of this and the backtrace below, I'm filing
this against libavcodec57 -- feel free to reassign if that's wrong.

The backtrace seems to be:
   PID: 4121 (gst-launch-1.0)
   UID: 1000 (paravoid)
   GID: 1000 (paravoid)
Signal: 6 (ABRT)
 Timestamp: Τετ 2016-07-20 21:55:59 EEST (5min ago)
  Command Line: gst-launch-1.0 filesrc 
location=/usr/share/sounds/purple/alert.wav ! wavparse ! audioconvert ! fakesink
Executable: /usr/bin/gst-launch-1.0
 Control Group: /
 Slice: -.slice
   Boot ID: fc3d59275e1042c491633f9a920c10e5
Machine ID: ddb673bb6861472487a0edbc40f6f1fc
  Hostname: donald
  Coredump: 
/var/lib/systemd/coredump/core.gst-launch-1\x2e0.1000.fc3d59275e1042c491633f9a920c10e5.4121.1469040959.xz
   Message: Process 4121 (gst-launch-1.0) of user 1000 dumped core.

Stack trace of thread 4122:
#0  0x7fa47ae7f1c8 raise (libc.so.6)
#1  0x7fa47ae8064a abort (libc.so.6)
#2  0x7fa4719b8f5b n/a (libavcodec.so.57)
#3  0x7fa4719b9026 avcodec_alloc_context3 (libavcodec.so.57)
#4  0x7fa473360540 n/a (libgstlibav.so)
#5  0x7fa473356e53 n/a (libgstlibav.so)
#6  0x7fa47b74b22d g_type_class_ref (libgobject-2.0.so.0)
#7  0x7fa47b9c8da4 gst_element_register 
(libgstreamer-1.0.so.0)
#8  0x7fa4733575b3 n/a (libgstlibav.so)
#9  0x7fa473349e20 n/a (libgstlibav.so)
#10 0x7fa47b9ea537 n/a (libgstreamer-1.0.so.0)
#11 0x7fa47b9ec425 n/a (libgstreamer-1.0.so.0)
#12 0x7fa47b9ed12c gst_plugin_load_by_name 
(libgstreamer-1.0.so.0)
#13 0x7fa47b9eda8d gst_plugin_feature_load 
(libgstreamer-1.0.so.0)
#14 0x7fa47ba137e3 gst_type_find_factory_call_function 
(libgstreamer-1.0.so.0)
#15 0x7fa479c48421 gst_type_find_helper_for_data 
(libgstbase-1.0.so.0)
#16 0x7fa479c485a4 gst_type_find_helper_for_buffer 
(libgstbase-1.0.so.0)
#17 0x7fa4799f446a n/a (libgstwavparse.so)
#18 0x7fa4799f4b47 n/a (libgstwavparse.so)
#19 0x7fa4799fabb1 n/a (libgstwavparse.so)
#20 0x7fa47ba0ee71 n/a (libgstreamer-1.0.so.0)
#21 0x7fa47b47b55e n/a (libglib-2.0.so.0)
#22 0x7fa47b47abc5 n/a (libglib-2.0.so.0)
#23 0x7fa47b1f4464 start_thread (libpthread.so.0)
#24 0x7fa47af3330d __clone (libc.so.6)

Stack trace of thread 4121:
#0  0x7fa47af2a19d poll (libc.so.6)
#1  0x7fa47b45439c n/a (libglib-2.0.so.0)
#2  0x7fa47b454722 g_main_loop_run (libglib-2.0.so.0)
#3  0x7fa47b9af8e9 gst_bus_poll (libgstreamer-1.0.so.0)
#4  0x004046f8 n/a (gst-launch-1.0)
#5  0x004036e9 n/a (gst-launch-1.0)
#6  0x7fa47ae6c730 __libc_start_main (libc.so.6)
#7  0x00403d19 n/a (gst-launch-1.0)

Stack trace of thread 4123:
#0  0x7fa47af2a19d poll (libc.so.6)
#1  0x7fa47b45439c n/a (libglib-2.0.so.0)
#2  0x7fa47b4544ac g_main_context_iteration 
(libglib-2.0.so.0)
#3  0x7fa47b4544e9 n/a (libglib-2.0.so.0)
#4  0x7fa47b47abc5 n/a (libglib-2.0.so.0)
#5  0x7fa47b1f4464 start_thread (libpthread.so.0)
#6  0x7fa47af3330d __clone (libc.so.6)

Finally, note that running "mpv /usr/share/sounds/purple/receive.wav"
seems to work without crashing (and produces sound), however, there is a
big yellow warning at the top that reads: "Warning: mpv was compiled
against a different version of ffmpeg than the shared library it is
linked against. This is most likely a broken build and misbehavior and
crashes are to be expected."

Thanks,
Faidon

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable'), (1, 
'experimental')

Bug#829701: mediawiki: nōn-DFSG-free files in package

[Faidon Liambotis]

severity 829701 minor
thanks

On Wed, Jul 06, 2016 at 12:21:36PM +0200, Thorsten Glaser wrote:
> > Are there any other discussions about this where others agree with your
> > interpretation about this? #760306 is still waiting for a comment from
> > the ftp masters.
> 
> Barring a comment from ftpmasters you should err on the safe side.

So in the case of doubt and without any comment from ftp-masters, one
should ignore the opinion of their upstream, which includes the opinions
of a fully-staffed trained legal team of a free-software minded
organization such as the Wikimedia Foundation -- or, for that matter,
the intentions of the trademark holder which in this case is also a
free-culture minded organization (Creative Commons)? I wholeheartedly
disagree with that statement.

Don't get me wrong -- I think it's good to raise those questions and
clarify licenses and challengfe the status quo, but I think it would
demonstrate arrogance to start stripping files like that or claim that
the CC logos are unfree.

> Let me quote:
>You are authorized to use our trademarks subject to this Trademark Policy, 
> and only on the further
>condition that you download images of the trademarks directly from our 
> [35]website. You are not
> 
> Your packaging of Mediawiki does not do that. Users of your packaging
> do not do that. That alone is grounds for unfreeness.

Well, first of all, "freeness" and "free software" are terms that apply
to copyright law and licenses, as is the DFSG for that matter. There is
no such thing as a "free" or "non-free" trademark license — neither
Debian nor the FL/OSS community at large have made any such definitions.

You /could/ argue that because of a trademark policy (e.g. that clause
above), Debian does not have the right to distribute the work and thus
violates trademark law by doing so. That would apply to other entities
distributing those particular logos, such as, I dunno, everyone on the
Internet, including Debian via a bunch of other packages in the archive
;) My understanding is that such an interperation of the license
combined with this widespread use would weakens the trademark to the
point where it could get unenforceable (trademark law is very different
than copyright law).

I don't interpret that clause like you do, but I'd be happy regardless
to raise this with Wikimedia's legal team. (I am a Wikimedia Foundation
staff member, although my comments here are not on behalf of the
Foundation and are done on my personal capacity as a Debian Developer
and interested user).

On the other bug report you mentioned that you were in contact with
someone from the Foundation's legal team. Could you perhaps let us know
who you were previously in contact with so that we can continue that
conversation rather than start it from the beginning?

Thanks,
Faidon

Bug#823106: fretsonfire: Depends on fonts-mgopen which has been requested to be removed

[Faidon Liambotis]

Markus,

On Sat, Apr 30, 2016 at 11:28:53PM +0200, Markus Koschany wrote:
> > fretsonfire depends on the fonts-mgopen font which has been requested to
> > eb removed. (#819026). Please switch to a different font.
> 
> providing patches or filing bug reports before requesting package
> removals are always appreciated. Thanks for your consideration next time.

You're absolutely right. I didn't think anyone would be using
fonts-mgopen but it was sloppy of me to not check beforehand. My
apologies.

Best,
Faidon

Bug#819205: Broken with current gccxml

[Faidon Liambotis]

Package: python-ctypeslib
Version: 0.0.0+svn20100125-5
Severity: grave

Hi,

gccxml since 0.9.0+git20140716-5 (dated Aug 7th, 2015) has been replaced
with a wrapper against CastXML. The wrapper is not fully compatible with
gccxml, which breaks most common invocations of h2xml (e.g. it's missing
the --preprocessor argument).

The gccxml package is apparently also shipping "gccxml.real" which is
the old gccxml that ctypeslib is relying on. Replacing the three
"gccxml" strings under cparser.py with "gccxml.real" seems to make this
package working again.

Regards,
Faidon

Bug#765577: (no subject)

[Faidon Liambotis]

reopen 765577 !
found 765577 215-14
thanks

On Mon, Mar 30, 2015 at 06:06:47AM +0200, Marco d'Itri wrote:
 I see that we have independently devised the same fix, I am attaching 
 a test case and a more refined version of your patch.

I tried Jessie RC3 today and immediately found that the fix is,
unfortunately, buggy. Your patch constructs a regexp and takes care to
escape metacharacters ? and * with a sed but does not escape { and
} that are also metacharacters in the extended set of POSIX regexps.
These are always found in the string-to-be-matched here with
'ATTR{dev_id}==0x0' and 'ATTR{type}==1', so the if always fails.

This was likely not caught by your test case (and was harder to debug
and figure out!) because GNU grep's -E mode handles { as both a literal
and a metacharacter heuristically for historic reasons (consult grep's
manpage for that) but busybox grep does not:
  $ echo 'foo{bar}'  test
  $ egrep 'foo{bar}' test 
  foo{bar}
  $ busybox egrep 'foo{bar}' test 
  egrep: bad regex 'foo{bar}'
  $ egrep 'fo{1,2}' test 
  foo{bar}
  $ busybox egrep 'fo{1,2}' test 
  foo{bar}
Note that this is NOT a bug in busybox; foo{bar} is indeed an invalid
extended POSIX regexp and busybox is right to complain and error out.

The very minimal last-minute fix below did the trick for me but I have
to say... constructing regexps in shell is tricky and the whole
escaping-with-sed logic feels like a hack. I think a literal grep (i.e.
-F) would be better here, especially since I don't see the point of an
exact match (even if the file was modified by the sysadmin, the right
thing would to not write a new rule anyway). This is probably something
to be considered post-jessie.

Thanks,
Faidon

diff --git a/debian/extra/write_net_rules b/debian/extra/write_net_rules
index 38a3ca0..fedc0f1 100644
--- a/debian/extra/write_net_rules
+++ b/debian/extra/write_net_rules
@@ -118,7 +118,7 @@ basename=${INTERFACE%%[0-9]*}
 match=$match, KERNEL==\$basename*\
 
 # build a regular expression that matches the new rule that we want to write
-new_rule_pattern=$(echo ^SUBSYSTEM==\net\, ACTION==\add\$match | sed -re 
's/([\?\*])/\\\1/g')
+new_rule_pattern=$(echo ^SUBSYSTEM==\net\, ACTION==\add\$match | sed -re 
's/([\?\*\{\}])/\\\1/g')
 
 # Double check if the new rule has already been written. This happens if
 # multiple add events are generated before the script returns and udevd


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

Bug#781210: systemd asserts on function cg_is_empty_recursive, crashes

[Faidon Liambotis]

Hi Martin,

On Fri, Mar 27, 2015 at 04:40:25PM +0100, Martin Pitt wrote:
  If so, a mere ipsec stop after that should be able to crash
  systemd.
 
 Not that, it just marks the unit as stopped but keeps the processes
 running. But killing the two daemons manually makes the cgroup empty
 and I get that very exception.

I *think* you read systemctl stop ipsec while I really meant ipsec
stop (ipsec being /usr/sbin/ipsec, and stop being an action that
sends SIGTERM to the daemons, among other things).

By get that very exception you mean that systemd crashes for you as
well? If so, that's great :) Anything more I can do to help then? You
seem to be in a better position to reproduce than me at the moment.

On a side note, I've noticed that if I put the system under stress
--cpu 8 the behavior changes and systemctl restart strongswan works
properly. This definitely points to some kind of race.

Thanks!
Faidon


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

Bug#781209: postinst execution order bug confuses systemd

[Faidon Liambotis]

Package: strongswan-starter
Version: 5.2.1-5
Severity: grave

strongswan-starter currently ships:
 - /etc/init.d/ipsec
 - /lib/systemd/system/strongswan.service

With the latter containing Alias=ipsec.service and also calling the
ipsec binary with --nofork as an (implicit) Type=simple unit. This is
all a bit confusing at start but pretty sane in general and the
strongswan rename is a nice move (and also consistent with Ubuntu).

The package's postinst, however, is buggy: it does not use
dh_installinit but calls invoke-rc.d ipsec manually. That would have been
fine, but invoke-rc.d ipsec is called *before* the
dh_systemd_enable/deb-systemd-helper bits.

This means that invoke-rc.d ipsec start runs before the systemd unit
is properly installed, which in turn confuses the hell out of systemd
(as, among others, it expects a Type=simple unit), as evidenced by the
following commands run in sequence:

# apt-get install strongswan
[...]
# systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/lib/systemd/system/strongswan.service; enabled)
   Active: active (running) since Thu 2015-03-26 00:50:42 UTC; 6min ago
   CGroup: /system.slice/ipsec.service
   ├─5150 /usr/lib/ipsec/starter --daemon charon
   └─5151 /usr/lib/ipsec/charon --use-syslog

[note how starter has been called without --nofork and there is a CGroup called
ipsec.service, despite the unit called strongswan.service]

# systemctl restart strongswan
# systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/lib/systemd/system/strongswan.service; enabled)
   Active: inactive (dead) since Thu 2015-03-26 01:00:59 UTC; 2s ago
  Process: 5783 ExecStart=/usr/sbin/ipsec start --nofork (code=exited, 
status=0/SUCCESS)
 Main PID: 5783 (code=exited, status=0/SUCCESS)

Mar 26 01:00:59 curium systemd[1]: Started strongSwan IPsec IKEv1/IKEv2 daemon 
using ipsec.conf.
Mar 26 01:00:59 curium ipsec_starter[5783]: Starting strongSwan 5.2.1 IPsec 
[starter]...
Mar 26 01:00:59 curium ipsec_starter[5783]: charon is already running 
(/var/run/charon.pid exists) -- skipping daemon start
Mar 26 01:00:59 curium ipsec[5783]: Starting strongSwan 5.2.1 IPsec [starter]...
Mar 26 01:00:59 curium ipsec[5783]: charon is already running 
(/var/run/charon.pid exists) -- skipping daemon start
Mar 26 01:00:59 curium ipsec[5783]: starter is already running 
(/var/run/starter.charon.pid exists) -- no fork done

[note the inactive/dead after a restart!]

# ps aux |grep ipsec
root  5150  0.0  0.0  17144   968 ?Ss   00:50   0:00 
/usr/lib/ipsec/starter --daemon charon
root  5151  0.0  0.0 1275680 5416 ?Ssl  00:50   0:00 
/usr/lib/ipsec/charon --use-syslog

Those are lingering/orphan processes, unmanaged by systemd. This won't
happen every time -- it's a race but reproducible, I've managed to
recreate it 5 times here already on two different servers. 19 times out
of 20, no process will stay behind; ipsec won't be running at all, which
is also a bug.

The remaining 1 time, though, the service stays out of systemd's control
and remains unmanageable; systemd thinks it's dead but it really is
running. This is a) confusing to the sysadmin b) means that reloads will
fail, c) means that a package removal won't actually stop the daemons,
d) that tools such as puppet will try to restart it again and again but
failing to do so.

More importantly, though, it triggers a secondary bug in systemd itself.
Continuing right from the execution path above:

# ipsec stop
Stopping strongSwan IPsec...
# grep systemd /var/log/syslog | tail -3
Mar 26 01:02:15 curium systemd[1]: Assertion 'path' failed at 
../src/shared/cgroup-util.c:913, function cg_is_empty_recursive().  Aborting.
Mar 26 01:02:15 curium systemd[1]: Caught ABRT, dumped core as pid 6916.
Mar 26 01:02:15 curium systemd[1]: Freezing execution.
# systemctl status
^C

At that point, the system barely works; systemctl etc. are not
responding.

I'll be filing the latter separately against systemd. However, the
strongswan's postinst is buggy nevertheless and creates a situation
uncommon enough to trigger this cascaded failure.

Regards,
Faidon


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

Bug#781210: systemd asserts on function cg_is_empty_recursive, crashes

[Faidon Liambotis]

Package: systemd
Version: 215-12
Severity: critical

I've managed to reproducibly crash systemd:

# grep systemd /var/log/syslog | tail -3
Mar 26 01:02:15 curium systemd[1]: Assertion 'path' failed at 
../src/shared/cgroup-util.c:913, function cg_is_empty_recursive().  Aborting.
Mar 26 01:02:15 curium systemd[1]: Caught ABRT, dumped core as pid 6916.
Mar 26 01:02:15 curium systemd[1]: Freezing execution.

After that, the system remains functioning (i.e. pid1 stays alive and
the kernel does not panic) but systemctl etc. do not respond (Failed to
list units: Connection timed out) and the system as a whole is pretty
useless until a reboot.

This is hard to trigger as it happens under very specific conditions
plus a race, but I've managed to reproduce it five times already on two
different servers.

The gory details and steps to reproduce are over at #781209, but in
short:

- strongswan-starter ships an init script /etc/init.d/ipsec and a system
  unit file named strongswan.service but containing Alias=ipsec.service.

- strongswan-starter's postinst is buggy and calls invoke-rc.d ipsec
  start manually before the systemd unit is fully set up.

- This results into the ipsec daemons actually starting up in an
  ipsec.service cgroup, as evidenced by e.g. a systemctl status.

- A subsequent systemctl restart strongswan almost always results into
  the service becoming inactive and the processes under the
  ipsec.service cgroup being killed.

  Sometimes, though, the service gets into an inactive (dead) state
  but the processes from the (wrong) cgroup stay up. This possibly
  happens because systemd tries to set up a strongswan.service cgroup?

- At that point, the processes are orphaned and lost from systemd's
  control and are completely unmanageable by systemctl.
  
- Killing them by hand (e.g. via kill or ipsec stop) crashes systemd.

A gdb bt full is attached.

Faidon
(gdb) bt full
#0  0x7f8fb8b0d79b in raise (sig=6) at 
../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
resultvar = 0
pid = optimized out
#1  0x7f8fb8f633d8 in crash.lto_priv.234 (sig=6) at ../src/core/main.c:158
rl = {rlim_cur = 18446744073709551615, rlim_max = 18446744073709551615}
sa = {__sigaction_handler = {sa_handler = 0x0, sa_sigaction = 0x0}, 
sa_mask = {__val = {0 repeats 16 times}}, sa_flags = 0, sa_restorer = 0x0}
__func__ = crash
__PRETTY_FUNCTION__ = crash
#2  signal handler called
No locals.
#3  0x7f8fb878a107 in __GI_raise (sig=sig@entry=6) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 1
selftid = 1
#4  0x7f8fb878b4e8 in __GI_abort () at abort.c:89
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7ffd56ee0ae4, sa_sigaction 
= 0x7ffd56ee0ae4}, sa_mask = {__val = {140255286606672, 140255286672192, 
  140726061894624, 140255287343296, 5990105739957488896, 
140255286672192, 140255260941991, 140255260944944, 2, 1, 140255287343248, 913, 
  140255260573900, 140255263445632, 140255287195268, 
140255286635808}}, sa_flags = -1165411504, sa_restorer = 0x7f8fba8a3b40}
sigs = {__val = {32, 0 repeats 15 times}}
#5  0x7f8fb8f9aed2 in log_assert_failed (text=text@entry=0x7f8fb901c736 
path, file=file@entry=0x7f8fb9019ea7 ../src/shared/cgroup-util.c, 
line=line@entry=913, func=func@entry=0x7f8fb901aa30 
__PRETTY_FUNCTION__.8851 cg_is_empty_recursive) at ../src/shared/log.c:709
No locals.
#6  0x7f8fb8f6cc8f in cg_is_empty_recursive.constprop.53 (path=0x0, 
ignore_self=ignore_self@entry=true, controller=synthetic pointer)
at ../src/shared/cgroup-util.c:913
d = 0x0
fn = 0x7f8fba8a4d90 \001
r = optimized out
#7  0x7f8fb8ff21c3 in manager_notify_cgroup_empty (cgroup=optimized out, 
m=0x7f8fba893b50) at ../src/core/cgroup.c:978
u = 0x7f8fba894d30
r = optimized out
#8  signal_agent_released (bus=optimized out, message=0x7f8fba8a3b40, 
userdata=0x7f8fba893b50, error=optimized out) at ../src/core/dbus.c:90
m = 0x7f8fba893b50
cgroup = 0x7f8fba923684 /system.slice/ipsec.service
r = optimized out
__PRETTY_FUNCTION__ = signal_agent_released
__func__ = signal_agent_released
#9  0x7f8fb9009137 in bus_match_run (bus=0x7f8fba8c2970, 
node=0x7f8fba90f260, m=0x7f8fba8a3b40) at 
../src/libsystemd/sd-bus/bus-match.c:299
error_buffer = {name = 0x0, message = 0x0, _need_free = 0}
slot = 0x7f8fba947890
test_str = optimized out
test_u8 = optimized out
r = optimized out
m = 0x7f8fba8a3b40
node = 0x7f8fba90f260
bus = optimized out
__PRETTY_FUNCTION__ = bus_match_run
#10 0x7f8fb9008dae in bus_match_run (bus=0x7f8fba8c2970, 
node=0x7f8fba9242c0, m=0x7f8fba8a3b40) at 
../src/libsystemd/sd-bus/bus-match.c:391
test_str = optimized out
test_u8 = optimized out
r = optimized out
m = 0x7f8fba8a3b40
node = 

Bug#765577: (no subject)

[Faidon Liambotis]

On Wed, Mar 18, 2015 at 06:52:14PM +0100, Michael Biebl wrote:
 I'm with Marco here. Before adding any workarounds, we need to
 understand what the underlying problem is. Otherwise we are adding cruft
 which nobody understands anymore a few years from now.
 
 Since I can't reproduce the issue and already have trouble keeping up
 with other bug reports, further investigation needs to be done by
 someone else.

Well, the root cause IMO is that 75-persistent-net-generator.rules is
inherently susceptible to races. It's my understanding that it's valid
for events to be triggered multiple times -- there are multiple places
in d-i that udevadm trigger is called, including start-udev (as
shipped by udev-udeb) which would trigger another set of add events
beyond the original hotplug one.

This is why write_net_rules operates under a lockfile too (again, AIUI).
It's just that this doesn't fix the race, just limits the race window
significantly but not entirely (as it makes write_net_rules idempotent,
but not 75-persistent-net-generator.rules).

The reason this is found in current jessie might just be that udev got
faster, or more udevadm triggers were added in other parts of the
installer etc.

In any case, if you need more input from a buggy system, feel free to
let me know and I'll try my best to get back to you with more details.

Oh, my original patch was buggy for many reasons, here's the updated
version:

diff --git a/debian/extra/write_net_rules b/debian/extra/write_net_rules
index 4379792..95939b8 100644
--- a/debian/extra/write_net_rules
+++ b/debian/extra/write_net_rules
@@ -117,6 +117,12 @@ fi
 basename=${INTERFACE%%[0-9]*}
 match=$match, KERNEL==\$basename*\
 
+# detect a race and abort, cf. #765577
+if [ -f $RULES_FILE ]  grep -q -F $match $RULES_FILE; then
+   unlock_rules_file
+   exit 0
+fi
+
 if [ $INTERFACE_NAME ]; then
# external tools may request a custom name
COMMENT=$COMMENT (custom name provided by external tool)

Regards,
Faidon


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

Bug#775795: Patch to use /usr/sbin/service in Debian service provider

[Faidon Liambotis]

reopen 775795
thanks

On 02/01/15 01:03, Gaudenz Steinlin wrote:

I created a patch to use /usr/sbin/service as suggested earlier in this
report to start/stop/status/restart services on Debian. I'm a bit
reluctant to just NMU puppet and would prefer if one of the maintainers
and/or Faidon could have a look at my patch first. If you approve I can
then do the NMU if you are short on time.

I tested the patch locally and as far as I can see it works fine with
systemd and does call the right command. I don't have a system with
system V handy to test on.


Apologies, it seems like I didn't review this on time...

This seems like a nice approach for status/start/stop/restart but 
unfortunately doesn't address enabled?/enable/disable at all. For 
starters, puppet seems to call update-rc.d with defaults, not 
enable. Even enable, though, does not seem to be sufficient for 
systemd-only service files :(


Try this:
# cp /etc/systemd/system/ssh.service  /etc/systemd/system/test.service
# systemctl daemon-reload
# update-rc.d -f test defaults
update-rc.d: error: initscript does not exist: /etc/init.d/test
# update-rc.d -f test enable
update-rc.d: error: cannot find a LSB script for test

enabled? is similarly broken: it calls invoke-rc.d --query, which 
returns 105 for test.service and puppet handles 105 by proceeding to 
check for symlinks under /etc/rc*.d/...


Finally, self.instances is also broken, as it just lists /etc/init.d 
init files. The systemd provider calls systemctl list-unit-files --type 
service --full --all instead.


Honestly, I'd just switch the default provider for Debian 8+ to systemd 
and let users who use a non-default init system handle it in their 
manifest by supplying provider = debian or provider = upstart.


Faidon


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

Bug#775795: puppet: Service's debian provider assumes SysV init

[Faidon Liambotis]

Package: puppet
Version: 3.7.2-1
Severity: serious

Hi,

Puppet has an abstraction concept called provider for its types.  The
Service type, one of puppet's basic types, is implemented by multiple
different providers, depending on the underlying init system.  There is
the init provider, which implements SysV init semantics, systemd 
upstart which implement systemd and upstart semantics respectively,
etc. The default provider on each system is assigned using facter rules,
apparently relying on operatingsystem and osfamily facts.

On Debian systems (i.e. on $::operatingsystem == debian), the default
provider is debian; this is a separate provider that inherits the
init provider but overrides a few methods to add invoke-rc.d support.
The systemd provider, on the other hand, is default only for osfamily
archlinux and for osfamily redhat  operatingsystemmajrelease 7.

This is obviously broken behavior -- puppet shouldn't make assumptions
about the init system a system runs purely from its OS version. That is
mostly tracked upstream with PUP-2023[1].

This is especially broken for jessie default installs, which are systemd
now. Service definitions -probably amongst the most used ones- are
assuming init.d semantics, unless provider = systemd is supplied as
an argument. The only reason puppet is not completely broken on jessie
is that most packages still ship an init.d script alongside a system
service file and LSB init-functions make sure those init.d scripts call
systemctl instead.

However, this means that Service (without an explicit provider) is
broken for at least those two use cases:
- enable = false/true doesn't work for packages that ship a systemd
  unit file,
- Service doesn't work at all with user-supplied systemd units or for
  (custom, mostly) packages that do not ship init.d scripts.

This is borderline important  serious in my mind, but it is a
regression for Wheezy and it should probably be fixed in time for
jessie, so I'm setting this to an RC severity.

This could be potentially worked around by setting systemd as the
default provider for kernel == Linux  operatingsystem == Debian 
operatingsystemmajrelease = 8. This would be a hack, of course, as
jessie optionally supports booting with SysV as well so a more
dynamic/runtime check will be a better but more complicated fix.

Regards,
Faidon

1: https://tickets.puppetlabs.com/browse/PUP-2023


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

Bug#775638: gdnsd: FTBFS in jessie: dh_auto_test: make -j1 test returned exit code 2

[Faidon Liambotis]

reassign 775638 geoip-database 20141027-1
retitle 775638 IPv6 database is corrupt
severity 775638 grave
thanks

Hi,
thanks

On Sun, Jan 18, 2015 at 01:44:44AM +0100, Lucas Nussbaum wrote:
 During a rebuild of all packages in jessie (in a jessie chroot, not a
 sid chroot), your package failed to build on amd64.
 
 Relevant part (hopefully):
 snip
  Checking basic database load on file /usr/share/GeoIP/GeoIP.dat ... OK
  Checking basic database load on file /usr/share/GeoIP/GeoIPv6.dat ... 
  Load-only test on file '/usr/share/GeoIP/GeoIPv6.dat' failed w/ exit status 
  134; Test Output:
  info: Loading configuration from 
  '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/config'
  info: plugin_geoip: map 'my_prod_map': Processing GeoIP database 
  '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat'
  error: plugin_geoip: map 'my_prod_map': Error traversing GeoIP database, 
  corrupt?
  error: plugin_geoip: map 'my_prod_map': (Re-)loading geoip database 
  '/«PKGBUILDDIR»/plugins/meta/libgdmaps/t/testroot/etc/geoip/loadonly.dat' 
  failed!
  fatal: plugin_geoip: map 'my_prod_map': cannot continue initial load

This is a test suite failure, reporting that geoip-database's
GeoIPv6.dat is corrupt. It looks like something's fishy there, after
checking with MaxMind's own geoiplookup6 tools:

$ dpkg-query -W geoip-database
geoip-database  20141009-1
$ geoiplookup6 www.maxmind.com
GeoIP Country V6 Edition: HK, Hong Kong
$ geoiplookup6 2001::1
GeoIP Country V6 Edition: IP Address not found

$ dpkg-query -W geoip-database
geoip-database  20141027-1
$ geoiplookup6 www.maxmind.com
$ geoiplookup6 2001::1
$

I've verified that gdnsd builds fine with geoip-database 20141009-1,
which corresponds with the above output.

it seems that geoip-database 20141027-1 ships a corrupt, IPv6 database.
Reassigning  bumping severity.

Best regards,
Faidon


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

Bug#775189: mate-session spawns gnome-keyring unconditionally

[Faidon Liambotis]

Package: mate-session-manager
Version: 1.8.1-5
Severity: serious

Hi,

Since upstream commit[1] 8a20baf39f781184d6126e0947e9fd4d9a115fab,
mate-session-manager spawns gnome-keyring-daemon, with no option to turn
it off, or pass arguments to it (such as --components).

While this is bad in itself, it gets worse: keyring is spawned *after*
the regular user-configured autostart programs are run. gnome-keyring's
default set of components includes a GPG  a SSH agent and rightfully
exports SSH_AUTH_SOCK and GPG_AGENT_INFO.

Therefore, even if the user has configured their desktop to spawn the
(more featureful and arguably more secure OpenSSH) ssh-agent or
gpg-agent, it is impossible to use it, as gnome-keyring-daemon clobbers
the these two environmental variables.

In other words, mate-session indirectly  unconditionally clobbers
environmental variables that in no way belong to it and actively
preventing programs that own the namespace from using them. This is a
severity: serious issue, IMO.

Note that e.g. gdm3's default PAM configuration uses pam_gnome_keyring
which calls gnome-keyring-daemon with the --daemonize --login options.
This starts the daemon but does not initialize it; mate-sessions's
execution with --start is what initializes it and exports these
variables into the session's environment.

Finally, note that MATE's default session autostart includes multiple
GNOME Keyring entries, a different one for each keyring component, that
can be individually be turned off and on. This is what GNOME used to do
(maybe still does?) as well. I've yet to understand why mate-session
also spawns it from its code as well.

Regards,
Faidon

1: 
https://github.com/mate-desktop/mate-session-manager/commit/8a20baf39f781184d6126e0947e9fd4d9a115fab


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

Bug#772641: apt: E: Setting TIOCSCTTY for slave fd fd failed when run as a session leader

[Faidon Liambotis]

Dear apt maintainers,

On Thu, Dec 11, 2014 at 01:35:27AM +0100, David Kalnischkies wrote:
 Attached is a patch which hopefully does exactly this. It is against
 experimental, but that shouldn't matter (expect for the testcase
 I think). I have run it on Linux amd64 (and armel) hardware as well
 as on a kfreebsd kvm, so I have some hope that it isn't regessing, but
 it would be nice if you could try it with puppet just to be sure that we
 are really fixing the problem completely or if I have justed resolved
 the problem in the setsid testcase.

Since David's patch works and this is an severity: serious/RC bug that
affects multiple people, how would you like to proceed? I see that while
David is not listed as an Uploader, he has a track record of
contributing to apt and has even signed off the latest upload.

I'd be happy to either sponsor an upload by David or NMU with his patch.
David, what do you think?

Let me know.

Thanks,
Faidon


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

Bug#773026: screen does not lock on suspend (jessie regression)

[Faidon Liambotis]

Package: gnome-screensaver
Version: 3.6.1-2
Severity: grave
Tags: security patch

Dear maintainer,

After upgrading my desktop from wheezy to jessie (w/ GNOME Flashback
mode), I was surprised to find that closing the lid of my laptop
suspended the system, but upon resume the screen was not locked and no
password prompt was needed to actually resume working on my screen.

Suffice to say, I think that's a security issue and thus, release
critical.

I investigated this quite a bit; it looks like with jessie's version,
GNOME doesn't use ConsoleKit anymore, but the alternative codepath for
this, namely handling systemd-login events, has been turned off by
passing --without-systemd to configure, over two years ago, with no
justification in the changelog.

Even with systemd support, though, it seems that in the (very old)
upstream version only Lock events are being processed, not suspend
(PrepareForSleep) ones (like gnome-shell does).  gnome-screensaver is
abandoned upstream, so I assume the API plans changed along the way over
the past two and a half years.

Fortunately, Ubuntu has prepared a patch for this and a) is trivial
enough, b) has been released with several Ubuntu versions and hence is
tested in the wild. While at it, I also ported another couple of Ubuntu
patches that while not strictly needed, help considerably in this use
case (namely, a) adding support for non-systemd Linux systems and b) not
leaking screen contents on resume).

Attached you will find a patch for the package to address this. The
total debdiff is:
  configure.ac   |2 +-
  src/gs-listener-dbus.c |   33 +++--
  src/gs-listener-dbus.h |1 +
  src/gs-manager.c   |2 +-
  src/gs-monitor.c   |   16 
  5 files changed, 50 insertions(+), 4 deletions(-)
...and is easily readable and understood, as well as widely tested. I
would definitely recommend including this in jessie.

Best,
Faidon
diff -Nurp gnome-screensaver-3.6.1/debian/changelog gnome-screensaver-3.6.1-suspendlock/debian/changelog
--- gnome-screensaver-3.6.1/debian/changelog	2014-09-11 23:26:14.0 +0300
+++ gnome-screensaver-3.6.1-suspendlock/debian/changelog	2014-12-13 13:03:22.112670213 +0200
@@ -1,3 +1,20 @@
+gnome-screensaver (3.6.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reenable support for locking the screen on suspend.
+- Build with systemd support by passing --with-systemd=auto to configure
+  and build-depending on libsystemd-login-dev. Use auto and a
+  [linux-any] dependency to keep compatibility with non-Linux systems.
+- 00git_logind_check.patch from Ubuntu/upstream, to make this dependent on
+  just logind, not systemd-as-pid1, as recommended by systemd upstream 
+  Debian systemd maintainers. Drops libsystemd-daemon-dev build-dep.
+- 31_lock_screen_on_suspend.patch from Ubuntu, to listen for logind's
+  PrepareForSleep signal, similarly to gnome-shell's behavior.
+- 14_no_fade_on_user_switch.patch from Ubuntu, as to not fade on screen
+  lock. Prevents leaking of the screen contents on resume from suspend.
+
+ -- Faidon Liambotis parav...@debian.org  Sat, 13 Dec 2014 11:32:25 +0200
+
 gnome-screensaver (3.6.1-2) unstable; urgency=medium
 
   * Team upload
diff -Nurp gnome-screensaver-3.6.1/debian/control gnome-screensaver-3.6.1-suspendlock/debian/control
--- gnome-screensaver-3.6.1/debian/control	2014-12-13 12:36:01.941262458 +0200
+++ gnome-screensaver-3.6.1-suspendlock/debian/control	2014-12-13 13:02:25.484828745 +0200
@@ -19,8 +19,7 @@ Build-Depends: cdbs,
libgtk-3-dev (= 3.0.0),
libgnome-desktop-3-dev (= 3.1.91),
libgnomekbd-dev (= 2.91.91),
-#   libsystemd-login-dev [linux-any],
-#   libsystemd-daemon-dev [linux-any],
+   libsystemd-login-dev [linux-any],
libxklavier-dev,
libx11-dev,
libxt-dev,
diff -Nurp gnome-screensaver-3.6.1/debian/control.in gnome-screensaver-3.6.1-suspendlock/debian/control.in
--- gnome-screensaver-3.6.1/debian/control.in	2014-09-11 23:21:50.0 +0300
+++ gnome-screensaver-3.6.1-suspendlock/debian/control.in	2014-12-13 13:02:17.124852278 +0200
@@ -15,8 +15,7 @@ Build-Depends: cdbs,
libgtk-3-dev (= 3.0.0),
libgnome-desktop-3-dev (= 3.1.91),
libgnomekbd-dev (= 2.91.91),
-#   libsystemd-login-dev [linux-any],
-#   libsystemd-daemon-dev [linux-any],
+   libsystemd-login-dev [linux-any],
libxklavier-dev,
libx11-dev,
libxt-dev,
diff -Nurp gnome-screensaver-3.6.1/debian/patches/00git_logind_check.patch gnome-screensaver-3.6.1-suspendlock/debian/patches/00git_logind_check.patch
--- gnome-screensaver-3.6.1/debian/patches/00git_logind_check.patch	1970-01-01 02:00:00.0 +0200
+++ gnome-screensaver-3.6.1-suspendlock/debian/patches

Bug#771922: keyboard handling broken with jessie's gnome-settings-daemon

[Faidon Liambotis]

Package: gnome-flashback
Version: 3.8.1-7
Severity: grave

Hi,

First of all, there's a number of severity: normal/important bugs
reported against the gnome-ssession-fallback package that mention
keyboard shortcuts issues (#727047, #730831, #731245, #731418, #727046,
#730096). My investigation shows that are partly related to each other
but in aggregate indicative of a more serious issue, hence this new
severity: grave super-bug. Apologies for the extra spam, feel free to
merge if you think that's better.

Second, I'm far from a GNOME developer or expert and the information
below is just the result of a day's investigation into GNOME's code, bug
tracking system and git history. Take everything I say with a grain of
salt and please double-check :)

So: the following things are broken in GNOME Flashback mode in today's jessie:
1) Keyboard layout switching
2) Non-metacity (i.e. g-s-d) keyboard shortcuts (e.g. Ctrl+Alt+L to lock screen)
3) Custom keybindings as configured by the control center
4) Power keys
5) Media keys (volume, play/pause)

I think that at least (1)  (2), as well as the combination of all these
(plus the unrelated #734822, which is fixed by gnome-flashback 3.14 as
found in experimental) makes the package unusable for most users and
hence unsuitable for a release with jessie.

The cause for this seems to be a general upstream trend of moving off
functionality from gnome-settings-daemon and into gnome-shell. This
became an issue in Debian with the inclusion of GNOME 3.14 in jessie.

Upstream g-s-d commit b0cee1df30b4945f524611f354ff164d4a383262
(media-keys: Refer key grabbing to the shell, BZ #693016) removed
media keys support, 326ee9f9a102a58941473e08fbe6221e70369f7f (keyboard:
Remove input sources handling, BZ #736436) removed input source
switching support and finally 66c975cd90736e32f20ffd36846301d68e7a08e7
(common: Remove unused keygrab code) removed the keygrab code
entirely. There's a number of other commits that touch e.g. media-keys
code too.

This is deliberate, as GNOME proper doesn't really care about
Flashback at this point. gnome-flashback's upstream is aware and trying
to fix those issues in Flashback it self. Current master has
cfce8742780e8be335cf19dd49a993cc0ea63b13 (libkey-grabber: initial
version)  the very hackish 670c310e8eaf89e895da96e62edc2a724c4ec068
(own org.gnome.Shell, see BZ #739534[1] for why this is very hackish
and also indicative of GNOME proper's attitude to Flashback :/).

I backported both of the aforementioned two commits to both jessie's and
experimental's gnome-flashback (the former needed a bit of a porting
work, the latter applies cleanly). Media keys  custom keybindings
functionality was restored, albeit without an OSD; keyboard layout
switching was not, however.

All in all, I'm not sure what the proper solution would be -- I'm hoping
that you, as maintainers, may have a really bright solution :)

As I see it, deviating significantly from upstream and reverting big
g-s-d commits doesn't sound like a great strategy to me, especially this
late in the jessie cycle. I think the most sensible approach at this
point would be to get in touch with Flashback upstream and figure out
the remaining bits (input sources, media keys, OSD). Then, stack patches
against Flashback 3.14 (not 3.8) and beg the release team to make a big
freeze exception on the basis that the alternative of removing Flashback
from jessie entirely would be a big regression from Wheezy. Doesn't
sound to me like something that has many chances of success, but
Flashback is fairly self-contained and might be considered important
enough.

Let me know if you need any further clarifications or help from me. I'm
pretty bummed at this point. This sucks :(

Regards,
Faidon

1: https://bugzilla.gnome.org/show_bug.cgi?id=739534


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

Bug#734822: gnome-session-flashback: NM, Power and Volume applets don't start anymore

[Faidon Liambotis]

reassign 734822 gnome-flashback 3.10.0-1
severity 734822 serious
thanks

On Fri, Jan 10, 2014 at 03:51:56AM +0100, Christoph Anton Mitterer wrote:
 A while since ago, NM applet didn't anymore start with GNOME classic
 (this was already before 3.8 and gnome-session-flashback)... but since
 then, neither the volume, nor the battery/power applet show's up anymore.

At least the sound applet is fixed with experimental's
gnome-flashback/gnome-session-flashback (3.14.0-3).

I don't think that a desktop session with no (option for) volume,
battery/power or network management control is very useful for the
majority of users and I don't think it would reasonable to release
jessie with Flashback in this state, so I'm bumping this to serious/RC.

Thanks,
Faidon


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

Bug#734822: gnome-session-flashback: NM, Power and Volume applets don't start anymore

[Faidon Liambotis]

On Wed, Dec 03, 2014 at 04:28:33PM -, Dmitry Shachnev wrote:
 Control: tags -1 +moreinfo
 
 On Wed, 3 Dec 2014 16:46:40 +0200, Faidon Liambotis wrote:
  I don't think that a desktop session with no (option for) volume,
  battery/power or network management control is very useful for the
  majority of users and I don't think it would reasonable to release
  jessie with Flashback in this state, so I'm bumping this to serious/RC.
 
 * NM-applet works fine for me. Its autostart file (nm-applet.desktop)
   was fixed some time ago, so it is now correctly autostarted.
 * For volume management use mixer applet from gnome-applets package.
 * For power control use battstat applet from gnome-applets package.
 
 What actually does not work for you?

I've been running Flashback from jessie, experimental and my own patched
version (see #771922) so forgive me for mixed feedback :(

The way I see it on *stock* jessie versions now:

* NM-applet shows up but crashes every now and then when I click on it.
  I guess this an NM bug regardless; I'll debug further and file it
  against NM when I have more information.

* There is a sound icon on my notification area that has no icon, though
  (it's just gray). There are two trivial commits in upstream
  gnome-flashback that I suspect fix this
  (a7a54573453ac5d600f2988f58003a0177e7ba40 
  d8679b7ccff2dd3452c59e30ce2c421f333a19f6). The sound applet from
  gnome-applets works but I haven't found a way to remove the other,
  ghost icon from the notification area.

* Yes, the battery applet from gnome-applets works. This isn't the old
  native GNOME 2.x notification area battery icon, but works just fine
  so I guess it's a non-issue.

Thanks for the quick response,
Faidon


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

Bug#771922: keyboard handling broken with jessie's gnome-settings-daemon

[Faidon Liambotis]

On Wed, Dec 03, 2014 at 06:18:45PM -, Dmitry Shachnev wrote:
 Please do not forget that the whole gnome-flashback (source) package fixes
 a lot of problems with gnome-panel. If we remove src:gnome-flashback from
 testing, that will leave gnome-panel users without:
 
 - Wallpaper;
 - Mouse cursor;
 - End Session dialogs.
 
 You may say that gnome-panel should be removed as well, but please do not
 forget that there are 8 other source packages depending on it, so they should
 get removed as well in that case.

Yeah, that's a good point. This affects the Flashback mode as a whole...

 I think the best solution will be to leave things as-is. But if you convince
 the Release Team that removing 10 packages (or backporting 800 lines of code
 to add keyboard grabber) is a good idea, I will be fine with that.

I don't think this is fit for release as-is.

Are you referring to the two patches I posted? If so, I wish it was that
simple; those a) are a hack, since they provide org.gnome.Shell, b) only
fix media keys  custom keybindings, not layout switching/input sources,
c) even for media keys, there is no OSD, for e.g. volume.

In any case, though, let's agree on the problem first. This is currently
a severity: grave bug, i.e. release critical.

Faidon


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

Bug#714210: DRBD 8.3 userland incompatible with 8.4 kernel modules

[Faidon Liambotis]

On Wed, Jun 26, 2013 at 10:50:20PM +0200, Jonas Meurer wrote:

as the subject already mentions, DRBD 8.3 userland in jessie/testing is
incompatible with DRBD 8.4 kernel modules from the 3.9 linux package.
DRBD kernel modules are at 8.4 branch in upstream linux kernel since
kernel release 3.8.

Ubuntu already ships DRBD 8.4 userland for this reason within Raring
(13.04).

Please consider to upgrade DRBD userland to 8.4. For now DRBD is
unusable in Debian sid/unstable and jessie/testing.


Is DRBD maintained at all or should it be orphaned? It's broken in 
unstable for a while, with no maintainer reply whatsoever in this 
(severity: grave) bug which exists since June or any of the other bugs, 
including a severity: serious one.


Please either act on it or orphan it, this situtation isn't doing our 
users any service at all.


Regards,
Faidon


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

Bug#725210: embeds multiple libraries, at least two of which undistributable

[Faidon Liambotis]

Package: asterisk
Version: 1:11.5.1~dfsg-2
Severity: serious

I was surprised and initially happy to see Asterisk 11 uploaded into
sid. My happiness quickly diminished when I saw that the upload contains
the embedded pjproject as-is, despite this issue having been flagged for
months now and being the sole blocker for an upload since the release of
Asterisk 11 eleven months ago.

There are several policy violations here:
 - Contains a convenience copy of pjproject under res/pjproject (§4.13)
 - pjproject itself contains convenience copies of several libraries
   under res/pjproject/third_party/ some of which already packaged in
   Debian (§4.13)
 - All of the above are completely undocumented in d/copyright (§12.5)
 - Not only they are undocumented, but it looks like no audit has
   happened on them whatsoever. From a very cursory look, at least
   res/pjproject/third_party/milenage/  res/pjproject/third_party/g7221/
   seem to completely lack license information other than the occasional
   All right reserved, which makes them undistributable by Debian or
   anyone else. (§2.3)

I'm baffled on how a DD could ever upload this into the archive, esp.
since these issues were widely known and discussed beforehand. Please
refrain from making such uploads in the future, as it's both a disgrace
to Debian's standards and a legal risk.

Regards,
Faidon


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

Bug#720392: package hardcodes database information

[Faidon Liambotis]

Package: rddmarc
Version: 1.1.3-1
Severity: grave

$ grep connect /usr/bin/dmarcfail
db = MySQLdb.connect(user='dmarc',passwd='xxx',db='dmarc', use_unicode=True)

$ grep -A 1 connect /usr/bin/rddmarc
my $dbh = DBI-connect(DBI:mysql:database=dmarc,
xxx, xxx)
or die Cannot connect to database\n;

No, xxx wasn't added by me. Yes, there are no configuration options
whatsoever.

Additionally, contrary to the package's description, mkdmarc is not shipped,
neither is the schema in e.g. examples.

Seriously?

Regards,
Faidon


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

Bug#711872: as root, build succeeds but tests do not - no 'gdnsd' user

[Faidon Liambotis]

severity 711872 minor
thanks

On Mon, Jun 10, 2013 at 03:43:37PM +0100, Alexander Clouter wrote:
The tests fail to start as the 'gdnsd' user does not exist on a fresh 
system at build time (might be worth changing the tests to use the 
'nobody' user?  patch enclosed):


This is actually the case only if you run the build as root. The package 
builds fine if you build it from an unprivileged users' environment, 
including nobody. That's also the case with Debian's autobuild network, 
which is why the package has built successfully on all releaseable 
architectures[1].


You should never build packages as root as this is dangerous for your 
system. Nevertheless, this is indeed a minor bug that should be fixed. 


Thanks,
Faidon

1: https://buildd.debian.org/status/package.php?p=gdnsd


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

Bug#710390: git-overlay mode is broken due to internal API changes

[Faidon Liambotis]

Package: git-buildpackage
Version: 0.6.0~git20130506
Severity: serious

Hi,

Building a package with overlay=True fails with the following backtrace:
   Traceback (most recent call last):
 File /usr/bin/git-buildpackage, line 5, in module
   sys.exit(main(sys.argv))
 File /usr/lib/python2.7/dist-packages/gbp/scripts/buildpackage.py, line 
524, in main
   export_source(repo, tree, source.changelog, options, tmp_dir, output_dir)
 File /usr/lib/python2.7/dist-packages/gbp/scripts/buildpackage.py, line 
148, in export_source
   if source.is_native():
   AttributeError: 'ChangeLog' object has no attribute 'is_native'

Commit 45c2346 seems to have removed the is_native() method from the 
ChangeLog object to avoid accidental usage.

It seems that the overlay mode triggers a codepath which wasn't updated, 
probably because of the ambiguity of the argument: the argument is 
called source but export_source passes source.changelog, as you can 
see from the above backtrace.

Regards,
Faidon


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

Bug#688779: liburcu1: shlibs too weak

[Faidon Liambotis]

On Fri, May 10, 2013 at 10:23:04AM -0400, Jon Bernard wrote:

This is a bug report against liburcu/0.7.4-1 but you seem to have closed
it in an ltt-control upload. If it wasn't a liburcu bug in the first
place, you should have reassigned the bug before closing it; if it is a
liburcu bug OTOH, you shouldn't Close it from a different package.

From what I can see, the bug is still considered by britney for
migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 
found ltt-control/$brokenversion as to fix this inconsistency.


I don't completely follow, can you give some clarification?  Also, can you
include a link to where I can see the britney information you're 
referencing?


This bug report was originally found on liburcu/0.7.4-1. The
ltt-control upload send a mail to 688779-close@ and this marked the bug
as fixed in ltt-control/2.1.0~rc4-2. But it wasn't found on that
package in the first place, so this was essentially no-op. You can see
this on the top of this bug report:
  Found in version liburcu/0.7.4-1
  Fixed in version ltt-control/2.1.0~rc4-2

Since the bug was found in a version of liburcu and wasn't fixed (or
unfound) in subsequent liburcu version, the BTS considers the bug as
still present in the most recent version of liburcu. You can
clearly see this on the dot graph in the top right side of the bug page.

You can also see how this will prevent the migration of liburcu to
testing (britney's excuses):
http://qa.debian.org/excuses.php?package=liburcu

The solution is to either mark the bug as fixed in a newer version of
liburcu (by mailing -done@ with e.g. Version: 0.7.6-1) or to inform
control@:
  notfound liburcu/0.7.4-1
  found ltt-control/2.1.0~rc4-1
  thanks

Cheers,
Faidon


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

Bug#705037: FTBFS on sparc

[Faidon Liambotis]

On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote:
  Additionally, since upstream is clearly supporting selected
  architectures and falling back to #error for unsupported ones, your
  package should properly mark those supported ones in the Architecture
  field instead of relying on porters noticing and marking as Not-For-Us.
 
 Yes, you raise an excellent point here.  I will make this change.

BTW, it also looks like upstream has a generic implementation (gcc.h)
for barriers and atomic operations. They seem to be using this only for
ia64 and not on unknown architectures (probably to be on the safe side),
but it might just be okay on the rest of the architectures as well. If
that's the case there's probably no need to actually disable liburcu
everywhere else. 

But you should confirm this on a per-architecture basis with your
upstream :-)

Regards,
Faidon


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

Bug#705037: FTBFS on sparc

[Faidon Liambotis]

On Thu, Apr 11, 2013 at 03:47:19PM -0400, Jon Bernard wrote:
 
 I suspect the buildd (schroeder in this case) has a 32bit userland and thus 
 has
 a HOSTTYPE of sparc instead of sparc64.  I should be a one-line patch, but
 the only available sparc test machine (smetana) is sparc64 and so I don't have
 the ability to test this.  It bothers me to make an upload simply to see if 
 the
 sparc build machine will succeed.  How would you handle this situation?

The sparc Debian port is 32-bit userland, this has nothing to do with
the buildd. The (upcoming) sparc64 port will be a separate, 64-bit
userland port. It's currently residing on debian-ports.org and buildds
are already building new uploads; it seems liburcu 0.7.6-1 built fine
there:
http://buildd.debian-ports.org/status/package.php?p=liburcusuite=sid

Both schroeder and smetana have a 64-bit kernel, in fact I don't think
the sparc port has a 32-bit kernel at all anymore. smetana has all the
build dependencies to build liburcu on the sid chroot, if you want to
experiment.

Note that this isn't something that has recently changed, so this
doesn't explain why sparc used to work with previous liburcu versions
but stopped working. This probably has something to do with a liburcu
upstream change, you should track this down.

  Additionally, since upstream is clearly supporting selected
  architectures and falling back to #error for unsupported ones, your
  package should properly mark those supported ones in the Architecture
  field instead of relying on porters noticing and marking as Not-For-Us.
 
 Yes, you raise an excellent point here.  I will make this change.
 
  It would also help reverse deps (I maintain one of them) to actually
  know in which architectures they should limit the b-d on, since clearly
  an unrestricted one would just result into more build failures.
 
 Also a good point, thank you for the suggestions.

Great, thanks, looking forward to these changes.

Regards,
Faidon


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

Bug#705037: FTBFS on sparc

[Faidon Liambotis]

On Mon, Apr 15, 2013 at 01:15:38PM -0400, Jon Bernard wrote:
 On the buildd machines that I cannot test on, autoconf sets $host_cpu to 
 'sparc'
 instead of 'sparc64'.  This caused me to assume they had a 32bit kernel.  On 
 the
 machine that I can test on (smetana), autoconf sets $host_cpu correctly to
 'sparc64' - and so liburcu builds and runs fine there.
 
 The buildd machines are distinctly different from smetana.

I think this is because the buildds set the personality to be 32-bit as
to always build for 32-bit sparc ports, no matter the running kernel of
the buildd. This is just an interpretation of the effect I'm seeing, I
can't back this up with a pointer to the code :)

I think using $host_cpu for what liburcu uses it is flawed in this sense
(also, host? why not target?). I could be wrong though, I don't claim to
be an expert on such things. I'd suggest contacting the porter people
and in particular the sparc porters.

 I had previously mapped 'sparc' to 'sparc64' to fix this, which caused
 everything to build successfully.  But without testing, I didn't feel it was 
 the
 correct thing to do, so I removed the patch.  This is why the build stopped
 working - not due to upstream changes.

Yeah, I think this is the wrong way to go. The current sparc port only
support 64-bit kernels, so it'd probably work on all cases, but it's not
right to use 64-bit asm on a 32-bit userland port.

 Without access to one of those machines to test on, I have two options:

I have access to schroeder and can assure you that there's no difference
whatsoever between the two. But try running linux32 dpkg-buildpackage
if you want to emulate this.

BTW, configure.ac seems to make some assumptions about ARM optimization
falgs; I'm unsure if these are correct for Debian, you should
double-check if you haven't already.

Regards,
Faidon


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

Bug#705037: FTBFS on sparc

[Faidon Liambotis]

Package: liburcu
Version: 0.7.6-1
Severity: serious

Hi,

Your package seems to be marked Architecture: any but seems to FTBFS on
multiple architectures, some of them even release architectures. mipsel
has already been marked as Not-For-Us.

One of them is sparc which built for 0.6.7-1 but has failed on 0.7.6-1
since Jan 20th with:
  In file included from urcu/static/wfqueue.h:33:0, from wfqueue.c:25:
  ./urcu/uatomic.h:23:2: error: #error Cannot build: unrecognized architecture 
detected.

This would prevent your package from entering testing, should the
release happen and testing unfroze.

From what I see, fixing sparc shouldn't be a big deal. kfreebsd-* which
also FTBFS could be a bit less trivial to fix but still doable as a
maintainer's job.

Additionally, since upstream is clearly supporting selected
architectures and falling back to #error for unsupported ones, your
package should properly mark those supported ones in the Architecture
field instead of relying on porters noticing and marking as Not-For-Us.

It would also help reverse deps (I maintain one of them) to actually
know in which architectures they should limit the b-d on, since clearly
an unrestricted one would just result into more build failures.

Regards,
Faidon


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

Bug#688779: liburcu1: shlibs too weak

[Faidon Liambotis]

On Tue, Sep 25, 2012 at 12:04:59PM -0400, Aaron M. Ucko wrote:
 Package: liburcu1
 Version: 0.7.4-1
 Severity: serious
 Justification: Policy 8.6

This is a bug report against liburcu/0.7.4-1 but you seem to have closed
it in an ltt-control upload. If it wasn't a liburcu bug in the first
place, you should have reassigned the bug before closing it; if it is a
liburcu bug OTOH, you shouldn't Close it from a different package.

From what I can see, the bug is still considered by britney for
migrations. You should either fix it, or mark notfound liburcu/0.7.4-1 
found ltt-control/$brokenversion as to fix this inconsistency.

Regards,
Faidon


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

Bug#683555: subversion: not working at all SASL context error

[Faidon Liambotis]

reassign 683555 libsasl2-2
forcemerge 636534 683555
forwarded 636534 https://bugzilla.cyrusimap.org/show_bug.cgi?id=3589
tags 636534 + fixed-upstream
severity 636534 important
thanks

On Thu, Aug 02, 2012 at 01:59:36AM +0900, Norbert Preining wrote:
 due to a broken laptop I had to switch to an old one. After upgrading
 from a about 2 year old system, suddenly my svn is completely
 broken wrt to svn:// URLs. ALl trials (co, up, ...) terminate with
 the same error:
 
 $ svn up
 Updating '.':
 svn: E170001: Unable to connect to a repository at URL 
 'svn://u...@server.org/some/path'
 svn: E170001: Could not create SASL context: generic failure: No such file or 
 directory
 $
 
 The same happens with svn+ssh://... on svn.debian.org

So, I was bitten by this as well. It seems that this bug is breaking
Subversion on upgrades on systems that don't have a correct hostname.

Having a broken hostname is of course bad, but this shouldn't stop
Subversion from working, esp. since it's a regression from squeeze.

It appears that it's not that uncommon: we had two separate bug reports
with multiple reporters in Debian, there's a similar openSUSE¹ bug, a
similar MacPorts bug² etc. It also affects more than Subversion; KMail 
Kontact have been explictly mentioned.

So, I'm bumping the severity to important -- I also considered serious/RC,
but I'll leave that up to the maintainer.

The issue seems to have been fixed upstream with commit
8fc14fd702897e652a38384af2f55e51752e8c15, as mentioned in the upstream
bug report³, so I think it'd be great if this ended up backported into
wheezy.

Thanks,
Faidon

¹: https://bugzilla.novell.com/show_bug.cgi?id=771983
²: https://trac.macports.org/ticket/34861
³: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3589


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

Bug#669427: apt segfaults on s390x

[Faidon Liambotis]

Package: apt
Version: 0.9.1
Severity: serious

apt 0.9.1 currently segfaults on the zelenka (our s390/s390x porterbox)
sid_s390x chroot. Downgrading apt to 0.8.15.10 makes it work again.

Backtrace follows, even though it probably isn't that helpful, since apt
doesn't have a debugging symbols package from what I could see.

For your convienience, I went on and installed apt's build-deps on
sid_s390x so that you rebuild and debug. Let me know if you need
anything else.

Thanks,
Faidon

#0  0x0229f386 in std::basic_stringchar, std::char_traitschar, 
std::allocatorchar ::basic_string(char const*, std::allocatorchar const) 
() from /usr/lib/s390x-linux-gnu/libstdc++.so.6
#1  0x020fa17a in IsDuplicateDescription(pkgCache::DescIterator, 
HashSumValue128 const, std::string const) () from 
/usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#2  0x020ff8b4 in 
pkgCacheGenerator::MergeListVersion(pkgCacheGenerator::ListParser, 
pkgCache::PkgIterator, std::string const, pkgCache::VerIterator*) () from 
/usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#3  0x02100034 in 
pkgCacheGenerator::MergeList(pkgCacheGenerator::ListParser, 
pkgCache::VerIterator*) () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#4  0x021664ec in debPackagesIndex::Merge(pkgCacheGenerator, 
OpProgress*) const ()
   from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#5  0x020f7390 in ?? () from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#6  0x020fae6a in pkgCacheGenerator::MakeStatusCache(pkgSourceList, 
OpProgress*, MMap**, bool) ()
   from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#7  0x020ee74e in pkgCacheFile::BuildCaches(OpProgress*, bool) ()
   from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#8  0x020eec02 in pkgCacheFile::Open(OpProgress*, bool) ()
   from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#9  0x8001f03e in ?? ()
#10 0x02096b22 in CommandLine::DispatchArg(CommandLine::Dispatch*, 
bool) ()
   from /usr/lib/s390x-linux-gnu/libapt-pkg.so.4.12
#11 0x8000cc4e in ?? ()
#12 0x023bea40 in __libc_start_main (main=optimized out, 
argc=optimized out, 
ubp_av=optimized out, init=0x80029440, fini=0x8002943c, 
rtld_fini=0x2010778, 
stack_end=0x3da2630) at libc-start.c:228
#13 0x8000cf82 in ?? ()



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

Bug#669427: apt segfaults on s390x

[Faidon Liambotis]

severity 669427 important
thanks

On Thu, Apr 19, 2012 at 09:12:09PM +0200, Mehdi Dogguy wrote:
 apt 0.9.1 currently segfaults on the zelenka (our s390/s390x porterbox)
 sid_s390x chroot. Downgrading apt to 0.8.15.10 makes it work again.
 
 Does it also segfault on s390? (s390x is not a release arch yet so
 it doesn't warrant an RC severity, unless the maintainer thinks so).

Good point, didn't think much about that at the time, sorry.
It seems to work on s390, downgrading.

Thanks,
Faidon



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

Bug#664606: additional information

[Faidon Liambotis]

On 03/19/12 13:28, Simon Josefsson wrote:
 Some even further information, as I seen that others have identified the
 problem, see for example:
 
 http://yate.null.ro/mantis/view.php?id=295
 
 There exists a libilbc library with a clear license here:
 
  https://github.com/dekkers/libilbc
 
 It is labeled as a drop-in replacement for the non-free code in RFC
 3591.

The iLBC code in RFC 3591 was freed when the company that original
authored it (GIPS) was acquired by Google. See e.g.
   https://datatracker.ietf.org/ipr/1649/

There are multiple people who have extracted this code from the RFC and
either included it as-is in their source trees or created libraries out
of it. I didn't check the one you pointed at, but I'm fairly sure it'll
be the exact same code.

The best solution (but I'm not speaking as a maintainer, since I haven't
been doing that for the VoIP team for quite some time) would be to
package one of these libraries and port all the software the uses it
to use that. Licensing-wise it won't make a big difference (besides a
proper debian/copyright), but it'll help to reduce code duplication and
security response.

Best regards,
Faidon



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

Bug#653332: thin is unmaintained

[Faidon Liambotis]

On Mon, Dec 26, 2011 at 10:04:32PM -0800, Ryan Niebur wrote:
 On Tue, Dec 27, 2011 at 04:44:31AM +0200, Faidon Liambotis wrote:
  The package in its current version works for me. However, I believe it
  is unsuitable for a release (and hence inclusion in testing) as it's
  clearly lacking a maintainer. I'd suggest either to start working on it,
  or O/RFH it.
 
 okay, I will do this.

Do what? I haven't seen a move to either direction.

Regards,
Faidon



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

Bug#653332: thin is unmaintained

[Faidon Liambotis]

Package: thin
Version: 1.2.4-1.1
Severity: serious

Hi,

I noticed that the package thin hasn't been maintained properly.

It hasn't had a maintainer upload since September 2009 when 1.2.4-1 was
uploaded; during that time, upstream released 1.2.6 (Feb 2010), 1.2.7
(March 2010), 1.2.8 (February 2011)  1.3.0 (November 2011); it had an
NMU (by yours truly) in January 2011 just to keep in the squeeze
release; it has a bug (+patch) open to update it to newer Ruby packaging
rules (#652090) with no maintainer reply.

The package in its current version works for me. However, I believe it
is unsuitable for a release (and hence inclusion in testing) as it's
clearly lacking a maintainer. I'd suggest either to start working on it,
or O/RFH it.

Regards,
Faidon



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

Bug#549054: raised severity: asterisk: Still uses gmime2.2

[Faidon Liambotis]

On Mon, Mar 14, 2011 at 12:02:31PM +0100, Jonas Smedegaard wrote:
 On Mon, Mar 14, 2011 at 09:12:00AM +0100, Ralf Treinen wrote:
 Hello, I have raised again the severity of this bug because
 gmime2.2 has been removed from sid on February 20, with the result
 that asterisk is no longer installable in sid.
 
 My [offer] to take lead in the asterisk maintainance still stand.
 
 [offer]: 
 http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/2011-February/018275.html

I guess you can start by providing a patch for gmime2.2 then?

Regards,
Faidon



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

Bug#610487: asterisk: AST-2011-001: buffer overflow in caller ID URI encoding

[Faidon Liambotis]

Faidon Liambotis wrote:

I can do the uploads (lenny hasn't been uploaded either, right?) but I'm
afraid it'll be with minimal testing. Moritz, is that acceptable?
Certainly better than having a remote exploitable hole...

I'm pondering whether I should remove my name from maintainer as well.
Tzafrir, perhaps you should do an RFH (or even O!) in e.g. debian-devel?


Since Tzafrir seems to be MIA(?), I've prepared updates for both lenny 
and squeeze. These are with minimal testing but changes are small and 
backported from upstream.


Should I upload to security-master?

Regards,
Faidon



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

Bug#610487: asterisk: AST-2011-001: buffer overflow in caller ID URI encoding

[Faidon Liambotis]

On 02/11/11 00:01, Moritz Mühlenhoff wrote:

Should I upload to security-master?


Excellent, thanks for taking care. Please upload (remember that stable-security
needs to be build with -sa, since it's new in Squeeze)


Done for both oldstable-security and stable-security (and thanks for the 
warning :)


Regards,
Faidon



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

Bug#610487: asterisk: AST-2011-001: buffer overflow in caller ID URI encoding

[Faidon Liambotis]

Tzafrir, ping?

I can do the uploads (lenny hasn't been uploaded either, right?) but I'm 
afraid it'll be with minimal testing. Moritz, is that acceptable? 
Certainly better than having a remote exploitable hole...


I'm pondering whether I should remove my name from maintainer as well. 
Tzafrir, perhaps you should do an RFH (or even O!) in e.g. debian-devel?


Regards,
Faidon



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

Bug#610288: thin: ActiveRecord session store doesn't work with Rails

[Faidon Liambotis]

On Tue, Jan 18, 2011 at 01:02:06PM +0100, Julien Cristau wrote:
 Tagging as candidate for removal from squeeze.  Somebody needs to get a
 fix in soon if they want this package in squeeze.

I NMUed 1.2.4-1.1 to DELAYED/2 with urgency=high to apply the following (full
debdiff is attached):

diff --git a/lib/rack/adapter/rails.rb b/lib/rack/adapter/rails.rb
index 8e5fd81..34196d8 100644
--- a/lib/rack/adapter/rails.rb
+++ b/lib/rack/adapter/rails.rb
@@ -32,9 +32,8 @@ module Rack
   end
   
   def rack_based?
-ActionController.const_defined?(:Dispatcher) 
-  (ActionController::Dispatcher.instance_methods.include?(:call) ||
-   ActionController::Dispatcher.instance_methods.include?(call))
+rails_version = ::Rails::VERSION
+rails_version::MAJOR = 2  rails_version::MINOR = 2  
rails_version::TINY = 3
   end
   
   def load_application

Regards,
Faidon
diff -u thin-1.2.4/debian/changelog thin-1.2.4/debian/changelog
--- thin-1.2.4/debian/changelog
+++ thin-1.2.4/debian/changelog
@@ -1,3 +1,13 @@
+thin (1.2.4-1.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * urgency=high because of an RC tiny bugfix.
+  * Backport a patch from v1.2.6 in Rails adapter to properly detect Rack.
+Among other things, this fixes the ActiveRecord session store (when
+configured) on Rails. (Closes: #610288)
+
+ -- Faidon Liambotis parav...@debian.org  Tue, 18 Jan 2011 14:31:07 +0200
+
 thin (1.2.4-1) unstable; urgency=low
 
   * New upstream release
diff -u thin-1.2.4/debian/patches/series thin-1.2.4/debian/patches/series
--- thin-1.2.4/debian/patches/series
+++ thin-1.2.4/debian/patches/series
@@ -4,0 +5 @@
+fix-rack-detection
only in patch2:
unchanged:
--- thin-1.2.4.orig/debian/patches/fix-rack-detection
+++ thin-1.2.4/debian/patches/fix-rack-detection
@@ -0,0 +1,16 @@
+diff --git a/lib/rack/adapter/rails.rb b/lib/rack/adapter/rails.rb
+index 8e5fd81..34196d8 100644
+--- a/lib/rack/adapter/rails.rb
 b/lib/rack/adapter/rails.rb
+@@ -32,9 +32,8 @@ module Rack
+   end
+   
+   def rack_based?
+-ActionController.const_defined?(:Dispatcher) 
+-  (ActionController::Dispatcher.instance_methods.include?(:call) ||
+-   ActionController::Dispatcher.instance_methods.include?(call))
++rails_version = ::Rails::VERSION
++rails_version::MAJOR = 2  rails_version::MINOR = 2  
rails_version::TINY = 3
+   end
+   
+   def load_application

Bug#610288: thin: ActiveRecord session store doesn't work with Rails

[Faidon Liambotis]

Package: thin
Version: 1.2.4-1
Severity: grave
Tags: patch
Justification: renders package unusable

When using Rails, thin ignores the configuration directive of picking
ActiveRecord for a session store and falls back to a CookieStore instead
(which is limited to 4K among other things).

The bug is reported upstream[1] and the trivial one-line fix made it to
1.2.5. I've patched thin locally with the fix there and I confirm that
it fixes the issue.

The problem appears only with Rails = 2.3.5 but this is the version
that is present in the archive right now and will be released with
squeeze.

I presume that the biggest use case of thin is hosting Rails
applications, and hence I'm marking this as grave; feel free to
downgrade if you feel differently.

Regards,
Faidon

1: 
https://thin.lighthouseapp.com/projects/7212/tickets/111-activerecord-session-store-not-creating-new-records-with-thin-124-and-rails-222



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

Bug#601506: boxbackup-server: bbstored-certs root CA expiration so far in the future it becomes the past

[Faidon Liambotis]

clone 601506 -1
retitle -1 Documentation errors regarding bbstored-certs
severity -1 minor
thanks

On Tue, Oct 26, 2010 at 07:42:18PM +, Clint Adams wrote:
 $root_sign_period is set to 1 days, so when a new CA pair
 is initialized, gnutls thinks the expiration is in 1969 and
 openssl thinks the expiration is in 1902.

So, I can confirm this. Amazingly, this seems to be a Y2038 bug...  The
fix is trivial (one-liner) if one chooses to cut the days e.g. into half
(resulting in certificates expiring in 2024 instead of 2038), which is a
fair compromise. The bug is quite recent, so I'll leave the maintainer
(who tends to be responsive) to handle it.

Another reason for not NMU'ing is that in the progress of confirming this
I encountered other minor problems with the package that should be dealt
with, preferrably by the maintainer:
  * The debconf template suggests installing the package boxbackup-utils,
which doesn't exist (this would need another round of translation
fixes)
  * bbstored-certs' manpage is totally broken, with nroff commands
appearing in the output.
The combination of the two resulted in puzzling me on how to properly
use the CA part of the package while trying to reproduce this. 



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

Bug#594777: varnish NMU for powerpc FTBFS

[Faidon Liambotis]

tags 594777 + patch pending
thanks

Hi,

After investigating this, I came to the conclusion that the test case
that produced this FTBFS is prone to race conditions, unrelated to
powerpc. After playing with it for a while, I could reliably (100%)
reproduce the problem under certain conditions.

Among others, pescetti.debian.org (the PowerPC porterbox) had the
problem but only if varnishtest was called with -v (but not -vv!) on the
case. The build-deps are still there and the source is in my home
directory, if you want to see for yourself.

Since this is RC, I've uploaded an NMU fixing this to DELAYED/2.

The gory details are in the diff. I'm attaching both the actual patch
that fixes this (from debian/patches) and the whole NMU debdiff.

As indicated at the patch headers, I haven't forwarded the patch to
upstream; I presume you are in a better position to do so. I included a
fairly good description plus comments in the test case itself, but if
you or upstream need me to clarify, I'd be happy to do so.

Note that upstream's SVN history showed that this has been a PITA
race-wise for quite some time but, unfortunately, all of their attempts
weren't good enough.

Regards,
Faidon
diff -Nru varnish-2.1.3/debian/changelog varnish-2.1.3/debian/changelog
--- varnish-2.1.3/debian/changelog  2010-08-28 01:44:04.0 +0300
+++ varnish-2.1.3/debian/changelog  2010-09-08 01:35:53.0 +0300
@@ -1,3 +1,14 @@
+varnish (2.1.3-6.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Urgency high because of a squeeze-targeted RC bugfix.
+  * Fix powerpc FTBFS caused by a race condition in a test suite case.
+(Closes: #594777)
+  * Rename patch debian-changes-2.1.3-6 to fix-changelog-typo and fix
+its documentation.
+
+ -- Faidon Liambotis parav...@debian.org  Wed, 08 Sep 2010 01:23:28 +0300
+
 varnish (2.1.3-6) unstable; urgency=low
 
   * Install only libvarnishapi.so (Closes: #592244)
diff -Nru varnish-2.1.3/debian/patches/debian-changes-2.1.3-6 
varnish-2.1.3/debian/patches/debian-changes-2.1.3-6
--- varnish-2.1.3/debian/patches/debian-changes-2.1.3-6 2010-08-28 
01:48:39.0 +0300
+++ varnish-2.1.3/debian/patches/debian-changes-2.1.3-6 1970-01-01 
02:00:00.0 +0200
@@ -1,48 +0,0 @@
-Description: Upstream changes introduced in version 2.1.3-6
- This patch has been created by dpkg-source during the package build.
- Here's the last changelog entry, hopefully it gives details on why
- those changes were made:
- .
- varnish (2.1.3-6) unstable; urgency=low
- .
-   * Install only libvarnishapi.so (Closes: #592244)
- .
- The person named in the Author field signed this changelog entry.
-Author: Stig Sandbeck Mathisen s...@debian.org
-Bug-Debian: http://bugs.debian.org/592244
-

-The information above should follow the Patch Tagging Guidelines, please
-checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
-are templates for supplementary fields that you might want to add:
-
-Origin: vendor|upstream|other, url of original patch
-Bug: url in upstream bugtracker
-Bug-Debian: http://bugs.debian.org/bugnumber
-Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
-Forwarded: no|not-needed|url proving that it has been forwarded
-Reviewed-By: name and email of someone who approved the patch
-Last-Update: -MM-DD
-
 varnish-2.1.3.orig/doc/changes-2.1.1.html
-+++ varnish-2.1.3/doc/changes-2.1.1.html
-@@ -74,7 +74,7 @@
- ul
-   li
- pspan class=codevarnishsizes/span, which is
--  like span class=codevarnishhost/span, but for the length of 
objects,
-+  like span class=codevarnishhist/span, but for the length of 
objects,
-   has been added../p
-   /li
- /ul
 varnish-2.1.3.orig/doc/changes-2.1.0-2.1.1.xml
-+++ varnish-2.1.3/doc/changes-2.1.0-2.1.1.xml
-@@ -86,7 +86,7 @@
- 
- change type=enh
-   paracodevarnishsizes/code, which is
--  like codevarnishhost/code, but for the length of objects,
-+  like codevarnishhist/code, but for the length of objects,
-   has been added../para
- /change
-   /subsystem
diff -Nru varnish-2.1.3/debian/patches/fix-changelog-typo 
varnish-2.1.3/debian/patches/fix-changelog-typo
--- varnish-2.1.3/debian/patches/fix-changelog-typo 1970-01-01 
02:00:00.0 +0200
+++ varnish-2.1.3/debian/patches/fix-changelog-typo 2010-09-07 
22:55:34.0 +0300
@@ -0,0 +1,25 @@
+Author: Stig Sandbeck Mathisen s...@debian.org
+Origin: vendor
+
+--- varnish-2.1.3.orig/doc/changes-2.1.1.html
 varnish-2.1.3/doc/changes-2.1.1.html
+@@ -74,7 +74,7 @@
+ ul
+   li
+ pspan class=codevarnishsizes/span, which is
+-  like span class=codevarnishhost/span, but for the length of 
objects,
++  like span class=codevarnishhist/span, but for the length of 
objects,
+   has been added../p
+   /li
+ /ul
+--- varnish-2.1.3.orig/doc/changes-2.1.0-2.1.1.xml
 varnish-2.1.3/doc/changes-2.1.0-2.1.1.xml
+@@ -86,7 +86,7 @@
+ 
+ change type=enh

Bug#535968: asterisk: Recording speed too fast with BRI cards

[Faidon Liambotis]

Rhonda, hi,

Gerfried Fuchs wrote:
 * Tzafrir Cohen tzafrir.co...@xorcom.com [2009-09-12 23:00:55 CEST]:
 fixed 535968 1:1.6.1.0~dfsg~rc3-1
 tag 535968 +lenny
 thanks

 This issue has already been fixed upstream. Thus it is Lenny-specific.
 
  So far, so good. Now, what to do about it in lenny? Can you please
 coordinate an update for stable with the release team to get this fixed
 in stable? This is still affecting lenny which is a supported release.
We do have a fix for this, along with several important other ones, in a
SPU upload that we've been preparing for a while:

http://svn.debian.org/wsvn/pkg-voip/asterisk/branches/lenny

Unfortunately, lack of time and of a test setup has prevented me from
asking from proposing it to RMs. Perhaps you could help?

Thanks,
Faidon



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

Bug#418975: affects stable

[Faidon Liambotis]

Hi,

Sorry for the late reply.

Stefanos Harhalakis wrote:
 Does the attached patch work?
Νο,

0x7f7b17504c82 in libnet_do_checksum (l=0x604010, buf=0xb8 Address
0xb8 out of bounds, protocol=1, len=32) at libnet_checksum.c:129
129 if (iph_p  iph_p-ip_v == 6)

(gdb) bt
#0  0x7f7b17504c82 in libnet_do_checksum (l=0x604010, buf=0xb8
Address 0xb8 out of bounds, protocol=1, len=32) at libnet_checksum.c:129
#1  0x7f7b17507283 in libnet_pblock_coalesce (l=0x604010,
packet=0x7fffbd28, size=0x7fffbd34) at libnet_pblock.c:393
#2  0x7f7b17508738 in libnet_write (l=0x604010) at libnet_write.c:59

Attached is a patch I made that fixes the problem (and also includes
your diff).

Not sure if libnet_pblock_record_ip_offset() is part of the ABI though.
It seems like it is (and hence the patch would be inappropriate for a
stable upload and a internal-only implementation of the function should
be made esp. for this bug) but OTOH, you didn't bump the SONAME with
1.1.4. Perhaps that's a bug of its own?

 If not I'd like to have a test case (either a sample program or step-by-step 
 instructions) in order to reproduce the bug. Just installing heartbeat isn't 
 enough since IPv6Addr gives:
 
 # ./IPv6addr 2000::1 start
 IPv6addr[16323]: ERROR:  Generic error
 ERROR:  Generic error
 
 (even with 1.1.4-2)
You should probably configure an interface with e.g. 2000::1/64 address
and then try IPv6addr with 2000:10/64.

Thanks,
Faidon
--- a/src/libnet_build_ip.c
+++ b/src/libnet_build_ip.c
@@ -238,7 +238,7 @@ u_int8_t *payload, u_int32_t payload_s, 
  * FREDRAYNAL: as we insert a new IP header, all checksums for headers
  * placed after this one will refer to here.
  */
-libnet_pblock_record_ip_offset(l, l-total_size);
+libnet_pblock_record_ip_offset(l, p);
 
 return (ptag);
 bad:
@@ -323,7 +323,7 @@ libnet_autobuild_ipv4(u_int16_t len, u_i
  * FREDRAYNAL: as we insert a new IP header, all checksums for headers
  * placed after this one will refer to here.
  */
-libnet_pblock_record_ip_offset(l, l-total_size);
+libnet_pblock_record_ip_offset(l, p);
 return (ptag);
 
 bad:
@@ -520,8 +520,12 @@ u_int8_t *payload, u_int32_t payload_s, 
 }
 
 /* no checksum for IPv6 */
-return (ptag ? ptag : libnet_pblock_update(l, p, LIBNET_IPV6_H,
-LIBNET_PBLOCK_IPV6_H));
+ptag = ptag ? ptag : libnet_pblock_update(l, p, LIBNET_IPV6_H,
+	LIBNET_PBLOCK_IPV6_H);
+
+libnet_pblock_record_ip_offset(l, p);
+
+return(ptag);
 bad:
 libnet_pblock_delete(l, p);
 return (-1);
--- a/src/libnet_pblock.c
+++ b/src/libnet_pblock.c
@@ -38,6 +38,7 @@
 #else
 #include ../include/win32/libnet.h
 #endif
+#include assert.h
 
 libnet_pblock_t *
 libnet_pblock_probe(libnet_t *l, libnet_ptag_t ptag, u_int32_t n, u_int8_t type)
@@ -496,15 +497,18 @@ libnet_pblock_p2p(u_int8_t type)
 }
 
 void
-libnet_pblock_record_ip_offset(libnet_t *l, u_int32_t offset)
+libnet_pblock_record_ip_offset(libnet_t *l, libnet_pblock_t *p)
 {
-libnet_pblock_t *p = l-pblock_end;
+libnet_pblock_t *c;
+u_int32_t ip_offset = 0;
 
-do
-{
-p-ip_offset = offset;
-p = p-prev;
-} while (p  p-type != LIBNET_PBLOCK_IPV4_H);
+assert(p-type == LIBNET_PBLOCK_IPV4_H || p-type == LIBNET_PBLOCK_IPV6_H);
+
+for(c = p; c; c = c-prev)
+ip_offset += c-b_len;
+
+for(c = p; c; c = c-prev)
+c-ip_offset = ip_offset;
 }
 
 
--- a/include/libnet/libnet-functions.h
+++ b/include/libnet/libnet-functions.h
@@ -2077,7 +2077,7 @@ u_int8_t type);
   * It updates the ip_pos field (referer) of each subsequent pblock.
   */
 void
-libnet_pblock_record_ip_offset(libnet_t *l, u_int32_t offset);
+libnet_pblock_record_ip_offset(libnet_t *l, libnet_pblock_t *p);
 
 /*
  * [Internal] 

Bug#418975: #418975 affects stable

[Faidon Liambotis]

Faidon Liambotis wrote:
 Faidon Liambotis wrote:
 Does the patch of message #77 fix your problem?
 Unfortunately, the patch doesn't apply cleanly on 1.1.2.1-2 and I'm not
 very comfortable with modifying the patch myself, especially considering
 that it's going to be for an SPU upload.
 Any progress wit that? Can I do something to help?
Ping?

Regards,
Faidon



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

Bug#555540: any news on tokyocabinet's FTBFS?

[Faidon Liambotis]

On Fri, May 14, 2010 at 09:43:27PM +0200, Pierre Habouzit wrote:
 On Tue, May 11, 2010 at 10:52:09PM +0200, Serafeim Zanikolas wrote:
  Here's a ping for #40, which is blocking the transition of bogofilter 
  (for
  quite a while now). It'd be sad to have to drop bogofilter support for
  tokyocabinet.
 
 This ftbfs is random and only on s390, you're welcome to track it down,
 I've not been able to.
It seems that on consecutive runs of the test case[1] in question, it aborts
at different points each time and even succeeds in one in five runs or so.
Moreover, while the combined assert() condition fails, separate assert() calls
for each of the condition succeed while their combination still fail(!)

All in all, the whole thing sounds like a miscompilation/toolchain bug. I
tried compiling (on zelenka, b-d installed there) with -O0 and indeed the
whole test suite succeeds.

BTW, compiling with -O0 was more tricky than just exporting DEB_BUILD_OPTS;
upstream's configure script is doing something fishy with its own CFLAGS
variable (called MYCFLAGS) with the goal of redefining optimization levels
depending on configure options; you should probably fix this.

Finally, while you mentioned that the bug is in linux-2.6, I couldn't find any
indication about that on this bug report, which is still assigned to
tokyocabinet. If there is another bug on Linux that's affecting this bug, I
couldn't find it; in any case, you should probably mark this on the BTS.

Regards,
Faidon

1: LD_LIBRARY_PATH=.  ./tcbmttest read -df 5 casket 5



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