Bug#1021678: [Pkg-rust-maintainers] Bug#1021678: Bug#1021678: rust-object: autopkgtest failure on s390x

[Wolfgang Silbermayr]

Am 13.10.22 um 01:23 schrieb Peter Green:


3. Apply the upstream fix as Debian packages, hope any resulting API breakage
    is manageable.


I did a quick regex search on https://codesearch.debian.not/ for
"\bshndx\b package:^rust*", and that only revealed two source packages, namely 
rust-object and rustc. rustc shows up because it has vendored its own copy of 
the rust object library crate. At least at a quick glance it looks as if no 
other package is using the function that gets its signature changed with the 
patch. Any new packages to come would fail building anyway, so don't think 
it's a problem to upload with the upstream patch applied.

Bug#1011962: rust-serde source package waiting in NEW queue

[Wolfgang Silbermayr]

Both packages were uploaded in sync by James McCoy, but the rust-serde 1.0.136
source package landed in the NEW queue (possibly due to new binary package[s]
built from it), so it's awaiting approval or rejection there.

Bug#1011717: Patch

[Wolfgang Silbermayr]

Tags: +patch

The problem appear to be two occurrences of uninitialized variables which gets
reported by `cppcheck` 2.8 during build. Older versions of `cppcheck` didn't
report that problem, this is why the package built without problems initially.

Reported upstream to https://github.com/vasi/pixz/issues/103
Submitted MR: https://github.com/vasi/pixz/pull/104

Attached the patch exported such that it can be added to the package with quilt.

Wolfgang.
>From 2f4db115586bd3d98c1f05eb64c125495bf0331a Mon Sep 17 00:00:00 2001
From: Wolfgang Silbermayr 
Date: Fri, 27 May 2022 09:19:02 +0200
Subject: [PATCH] Fix cppcheck 2.8 uninitialized variables warnings
Forwarded: https://github.com/vasi/pixz/pull/104
Author: Wolfgang Silbermayr 

---
 src/write.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/write.c b/src/write.c
index c84ec55..7ecfb19 100644
--- a/src/write.c
+++ b/src/write.c
@@ -448,7 +448,7 @@ static void write_block(pipeline_item_t *pi) {
 static void encode_index(void) {
 if (lzma_index_encoder(, gIndex) != LZMA_OK)
 die("Error creating index encoder");
-uint8_t obuf[CHUNKSIZE];
+uint8_t obuf[CHUNKSIZE] = {};
 lzma_ret err = LZMA_OK;
 while (err != LZMA_STREAM_END) {
 gStream.next_out = obuf;
@@ -513,7 +513,7 @@ static void write_file_index_bytes(size_t size, uint8_t *buf) {
 }
 
 static void write_file_index_buf(lzma_action action) {
-uint8_t obuf[CHUNKSIZE];
+uint8_t obuf[CHUNKSIZE] = {};
 gStream.avail_in = gFileIndexBufPos;
 gStream.next_in = gFileIndexBuf;
 lzma_ret err = LZMA_OK;
-- 
2.35.1

Bug#993633: [Pkg-rust-maintainers] Bug#993633: debcargo does not honour global summary/description

[Wolfgang Silbermayr]

On 9/4/21 12:58 AM, Ian Jackson wrote:

> Here is the fix.  This in the form of a git-formwat-patch.
> Obviously, I used git.  The vcs-git pointed to the debcargo-conf tree,
> so I just used the .dsc import that dgit gave me.

Thanks for the fix, gave it a test run and it looks good to me.

I imported the patchset into a MR on the debcargo project on Salsa.
https://salsa.debian.org/rust-team/debcargo/-/merge_requests/33

Bug#975191: [Pkg-rust-maintainers] Bug#975191: re: rust-js-sys: FTBFS: dh_auto_test: error: /usr/share/cargo/bin/cargo build returned exit code 101

[Wolfgang Silbermayr]

On 8/31/21 4:25 PM, Bastian Germann wrote:
> On Wed, 2 Dec 2020 02:46:36 + peter green  wrote:
>>  > This will impact quite some other modules.
>>
>> I agree that the current autoremoval list looks pretty scary, so I decided
>> to do some
>> dependency analysis. It seems there are 5 source packages with direct or
>> indirect hard
>> dependencies on rust-js-sys.
>>
>> rust-www-sys
>> rust-ring
>> rust-rustls
>> rust-sct
>> rust-webpki
> 
> Hey,
> 
> I would like to get rustls migrating to bookworm but this is a blocker for it.
> Can you please state if you want to fix this or would like help with it? I
> guess importing the current version will do it.

Hi Bastian,

I'd be happy to support getting rustls to migrate as well.

After taking a look, "just" updating rust-js-sys to the latest version also
requires an update of the wasm-bindgen related crates to the latest version
(which currently is 0.2.76 across all of them):

wasm-bindgen-shared
wasm-bindgen-backend
wasm-bindgen-macro-support
wasm-bindgen-macro
wasm-bindgen

I did a quick test run updating all of these, and it basically works, once
`syn` got updated. For `syn`, we have an RFS note indicating that autopkgtests
don't work yet with the updated version and need some other packages such as
`insta` uploaded before. I didn't dig too deeply into that part, but we might
need to invest some additional work here.

Within the wasm-bindgen* group, I also stumbled over a few autopkgtest problems:

wasm-bindgen-macro-support has a few features that fail their tests, but I
expect that these tests simply aren't intended to be run with only a single
feature enabled. Would require some investigation and either fixing or marking
them as broken. The rest of the tests succeeds.

wasm-bindgen-macro requires wasm-bindgen to be available for the autopkgtest,
but it should be possible to handle that. In addition, it requires
wasm-bindgen-futures 0.4, some more about that below.

wasm-bindgen requires js-sys 0.3 to be available for the autopkgtest, but
again that can be handled.

js-sys requires wasm-bindgen-futures 0.4 for the autopkgtest as well.

Regarding wasm-bindgen-futures, that one has a dev dependency on
futures-channel-preview in a 0.3 alpha version. We can basically handle that,
but that crate received its last update about two years ago. At a quick look,
it seems to be a bootstrapping crate that might be intended to be replaced by
futures-channel which is available by now, but that didn't happen yet for
whichever reason. Might be a topic to investigate upstream. That one pulls in
futures-core 0.3, and thus requires an update of the futures ecosystem from
0.1 to 0.3 which by itself is a topic that is much larger than the
wasm-bindgen topic that I describe here. There was already some preparation
done by another team member, but I'm not sure when it was the last time
somebody took a thorough look at what they prepared.

I'd love to work on untangling these issues, but once I start working on such
a group of problematic packages, I usually discover blockers which stop my
undertaking, and due to being a DM, I need a DD to either grant me upload
access for the affected crates, or sponsor the upload for me, so it's quite
tedious to finish such a group of packages, with all the inconveniences that
come from the delays, such as packages failing to migrate for some time or
autopkgtests failing until the required dependencies become available. If it
was for me, we could go forward and upload the updates, but in the past it
didn't take long until we collected many reports about failing or skipped
autopkgtests.

That's what I can tell upfront from my quick evaluation, but speaking from
experience, I'd expect some unforeseen roadblock to show up when working on it.

I hope this quick analysis gives you some insight into the overall state, and
some idea where and how you would like to proceed. In case you need some
support working on a specific crate, let me know.

Best regards,
Wolfgang.

Bug#987304: dgit-repos-server seems to have messed up version demangling from tag2upload git tag

[Wolfgang Silbermayr]

Package: dgit-infrastructure
Version: 9.13
Severity: important
X-Debbugs-Cc: wolfg...@silbermayr.at

Line 1109 of the dgit-repos-server script contains this code:

$version =~ y/_\%\#/:~/d;

When running into problems with version numbers containing '~' or ':' I
looked up the version mangling description of DEP-14, and it says for the
reverse transformation of the git tags:

* Each percent (%) is replaced with a colon (:)
* Each underscore (_) is replaced with a tilde (~)
* Each hash (#) is deleted

It seems to me that the mentioned line performs the first to replacements
exactly the other way round.

Using this line of code instead of the original fixes the problem for me:

$version =~ y/_\%\#/~:/d;

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

Kernel: Linux 5.10.0-6-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dgit-infrastructure depends on:
ii  chiark-utils-bin   6.1.2+nmu1
ii  git [git-core] 1:2.31.1-1
ii  gpgv   2.2.27-1
ii  libdbd-sqlite3-perl1.66-1+b1
ii  libdpkg-perl   1.20.9
ii  libjson-perl   4.03000-1
ii  liblocale-gettext-perl 1.07-4+b1
ii  perl [libdigest-sha-perl]  5.32.1-3
ii  sqlite33.34.1-3

Versions of packages dgit-infrastructure recommends:
ii  dgit  9.13

dgit-infrastructure suggests no packages.

-- no debconf information

Bug#946921: (rust-spin) Project abandoned

[Wolfgang Silbermayr]

It looks like the project returned form the hiatus half a year ago, so this
issue is no longer a problem for crates that use newer versions of `spin` so
it's rather a matter of upgrading those in unstable after bullseye has been
released.

Further information on the RustSec entry:

https://github.com/RustSec/advisory-db/issues/830
https://github.com/RustSec/advisory-db/pull/423

Bug#985087: [Pkg-rust-maintainers] Bug#985087: CVE-2021-27378

[Wolfgang Silbermayr]

On 3/12/21 7:54 PM, Moritz Muehlenhoff wrote:
> Source: rust-rand-core
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Please see:
> https://rustsec.org/advisories/RUSTSEC-2021-0023.html

Thank you for your report.

The commit [0] fixed the issue upstream in the `read_u32_into(…)` and the
`read_u64_into(…)` functions inside `src/le.rs`. This change was made between
the rand_core 0.6.1 and 0.6.2 release.

We have version 0.5.1 of the library in Debian, and the affected code [1] had
been refactored before the first 0.6 release.

It is not obvious to me whether the issue is present in that version of the
code due to it effectively being a reimplementation that removes the code
marked unsafe that was initially copied over from the byteorder crate
according to a comment. Inside the byteorder crate, the very same code still
exists unchanged in the latest release 1.4.3 from 2021-03-10.

At first sight it appears to me that version 0.5.1 does not have the issue,
but I'd prefer to have that checked by more eyes.

Wolfgang.

--

[0]
https://github.com/rust-random/rand/pull/1096/commits/390a7b1049fa5ba1d627feaef2a1629e0e7826b4
[1] https://sources.debian.org/src/rust-rand-core/0.5.1-1/src/le.rs/

Bug#954613: rust-process-viewer: FTBFS: unsatisfiable build-dependency: librust-sysinfo-0.9+default-dev

[Wolfgang Silbermayr]

On Sun, 8 Nov 2020 09:55:38 +0100 Sylvestre Ledru  wrote:
> Hello Wofgang,
> 
> Do you have the intention to fix process-viewer?
> 
> We have a RC bug from March on it.

Hi Sylvestre,

I updated the patch in the debcargo-conf repo on Salsa in a way that fixes the
problem.

My previous gpg subkey for signing uploads expired recently, and I uploaded
the newly generated subkey. Seems like I'll be able to perform the upload
early in December, after the new key got imported. If you'd like to see the
fix earlier, feel free to upload the update.

Best regards,
Wolfgang.

Bug#966088: debian-rust mailing list

[Wolfgang Silbermayr]

I support this request. People don't subscribe to the pkg-rust-maintainers
list due to the low signal-to-noise ratio if they just want to communicate
with the debian-rust team and not be informed about each and every package 
upload.

The pkg-rust-maintainers list is useful to the team itself and should be kept
available.

Wolfgang Silbermayr.

Bug#951166: ITP: shortwave -- Find and listen to internet radio stations

[Wolfgang Silbermayr]

On 2/11/20 9:40 PM, David Heidelberg wrote:
> Package: wnpp
> Severity: wishlist
> Owner: David Heidelberg 
> 
> * Package name: shortwave
[...]

Hi David,

I work in the debian-rust team on the general rust crates ecosystem.
Shortwave is one of the programs for which I have worked towards getting
it's dependencies into Debian. There's still some levels of dependencies
missing, and the tooling does not yet support packaging of crates that
are not published on crates.io which is the case for shortwave, but
that's in the works [0]. For this project however, it might also be
feasible to maintain it separately because it doesn't use cargo
directly, but instead uses meson which wraps the cargo procedure.

We coordinate our work in the #debian-rust irc.oftc.net channel, feel
free to drop by so we can coordinate the required steps.

Progress is currently blocked, mainly by what is described in a mailing
list thread [1]. Once that is unlocked, we hope to be able to update
many of the crates that have been stuck, among which are also the
gtk-related crates.

You can use the cargo-debstatus tool to take a look at the dependency
tree that needs work before the program can be uploaded.

I'm currently a Debian Maintainer, so I won't be able to sponsor package
uploads for now, but we have members on the team who can do so.

Best regards,
Wolfgang.

--

[0] https://salsa.debian.org/rust-team/debcargo/merge_requests/22
[1]
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-February/009828.html

Bug#950583: rustc: Float number min() and max() methods on mips[64]el behave different from other architectures

[Wolfgang Silbermayr]

Package: rustc
Version: 1.40.0+dfsg1-5
Severity: normal

Dear Maintainer,

When calling the f64 and f32 min() and max() methods on mips[64]el, with one of
the numbers being NAN, the returned value is also NAN. On all other
architectures we have, the non-NAN number gets returned.

The following test reproducibly yields an error on the mips* architectures
while succeeding on the others.

```rust
#[cfg(test)]
mod tests {
#[test]
fn min() {
assert_eq!(1f64.min(std::f64::NAN), 1f64);
}

#[test]
fn max() {
assert_eq!(1f64.max(std::f64::NAN), 1f64);
}
}
```



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

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

Versions of packages rustc depends on:
ii  binutils  2.33.90.20200122-2
ii  gcc   4:9.2.1-3.1
ii  libc6 2.29-9
ii  libc6-dev [libc-dev]  2.29-9
ii  libgcc-s1 [libgcc1]   10-20200117-2
ii  libgcc1   1:9.2.1-25
ii  libllvm9  1:9.0.1-8
ii  libstd-rust-dev   1.40.0+dfsg1-5
ii  libstdc++69.2.1-25

Versions of packages rustc recommends:
ii  cargo 0.40.0-3
ii  rust-gdb  1.40.0+dfsg1-5

Versions of packages rustc suggests:
pn  lld-9 
pn  rust-doc  
pn  rust-src  

-- no debconf information

Bug#950143: RM: rust-rdrand -- ROM; rust-rdrand is no longer in use

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

All packages that (build-)depended on packages built from src:rust-rdrand have
been updated to versions that removed this dependency.

Bug#947709: (no subject)

[Wolfgang Silbermayr]

A quick investigation reveals:

* We have the "@" test (currently called command1 in the quoted log)
  which enables all crate features. The clang-sys crate does not permit
  enabling both the "runtime" and the "static" features at the same
  time, so the build script intentionally aborts with a compiler error.
  We will mark this test as FLAKY with the test_is_broken debcargo
  config flag for the next rust-clang-sys release.
* The other tests fail because they attempt to run the `llvm-config`
  tool which isn't installed. I tested with the llvm and clang moved
  from the Recommends to the Depends field. This could be fixed by using
  the Depends field in the autopkgtests control. I don't know if
  debcargo is already able to output that field, maybe we have to
  implement it there first.

Bug#949812: RM: rust-rand-core-0.2 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.2 of the rust rand-core crate, suffixed with the version
number so it is co-installable with the latest version (currently 0.5) of the
same crate.

I already filed a ROM report for the single remaining reverse dependency rust-
rand-0.5 (#949798).

Bug#949811: RM: rust-rand-core-0.4 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.4 of the rust rand-core crate, suffixed with the version
number so it is co-installable with the latest version (currently 0.5) of the
same crate.

I filed ROM reports for all of the reverse (build-)dependencies of this
package:
rust-rand-jitter-0.1 (#949809)
rust-rand-pcg-0.1 (#949804)

Bug#949809: RM: rust-rand-jitter-0.1 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This package is no longer depended on by any other package. All usage of it has
been removed or migrated to other libraries.

Bug#949808: RM: rust-rand-xorshift-0.1 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.1 of the rust rand-xorshift crate, suffixed with the
version number so it is co-installable with the latest version (currently 0.2)
of the same crate. All packages which depended on this exact version have been
updated to the latest version, so this package is no longer needed.

Bug#949804: RM: rust-rand-pcg-0.1 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.1 of the rust rand-pcg crate, suffixed with the version
number so it is co-installable with the latest version (currently 0.2) of the
same crate. All packages which depended on this exact version have been updated
to the latest version, so this package is no longer needed.

Bug#949803: RM: rust-rand-isaac-0.1 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.1 of the rust rand-isaac crate, suffixed with the version
number so it is co-installable with the latest version (currently 0.2) of the
same crate. All packages which depended on this exact version have been updated
to the latest version, so this package is no longer needed.

Bug#949802: RM: rust-rand-hc-0.1 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.1 of the rust rand-hc crate, suffixed with the version
number so it is co-installable with the latest version (currently 0.2) of the
same crate. All packages which depended on this exact version have been updated
to the latest version, so this package is no longer needed.

Bug#949801: RM: rust-rand-chacha-0.1 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.1 of the rust rand-chacha crate, suffixed with the
version number so it is co-installable with the latest version (currently 0.2)
of the same crate. All packages which depended on this exact version have been
updated to the latest version, so this package is no longer needed.

Bug#949798: RM: rust-rand-0.5 -- ROM; No longer used by any other package

[Wolfgang Silbermayr]

Package: ftp.debian.org
Severity: normal

This is the version 0.5 of the rust rand crate, suffixed with the version
number so it is co-installable with the latest version (currently 0.7) of the
same crate. All packages which depended on this exact version have been updated
to the latest version, so this package is no longer needed.

Bug#946734: [Pkg-rust-maintainers] Bug#946734: rust-addr2line Build-Depends on librust-fallible-iterator-0.1+default-dev which isn't available

[Wolfgang Silbermayr]

On 12/14/19 10:49 PM, Paul Gevers wrote:
> Source: rust-addr2line
> Version: 0.7.0-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainers,
> 
> Your package was never build on a buildd, and was rescheduled 117 days
> ago. Since then, the status is BD-Uninstallable. Can you please make sure that
> we can actually build packages in Debian?

Hi Paul,

Thank you for your report.

We already have a new version of addr2line prepared, but it is still
waiting for rust-gimli to pass the NEW queue.

In my experience, the packages have been able to build in the past, but
became un-buildable due to the update of a dependency (in this case
rust-fallible-iterator).

I prepared an update of a set of packages, namely
rust-{object,fallible-iterator,gimli,addr2line,backtrace} with
consistent versions. However, the upload of rust-gimli landed in the NEW
queue due to having an additional bin package. The details on the
problems we currently have with that can be found in #945542. The whole
situation seems stuck and is somewhere between discouraging and
demotivating for the whole debian-rust team atm.

> Please check https://release.debian.org/transitions/html/rust.html, there is 
> at
> least one more packages like this one: rust-nitrokey-test. Can/should I
> reschedule all the red packages or will that fail anyways?

I take a look at this page at regular intervals, that was one of the
incentives to start working on the set of packages as described above.
Can't say for the other packages though. It is well possible that they
are in a similar situation.

Wolfgang.

Bug#946465: [Pkg-rust-maintainers] Bug#946465: librust-rand+alloc-dev: does not find upgrade path from buster to bullseye

[Wolfgang Silbermayr]

On 12/9/19 3:38 PM, Andreas Beckmann wrote:
> Package: librust-rand+alloc-dev
> Version: 0.6.4-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'buster'.
> It installed fine in 'buster', then the upgrade to 'bullseye' fails.

Hi Andreas,

Quick inspection:
packages built from rust-rand-core 0.5 need to migrate to testing.

We have the following situation here:
* buster:
  - librust-rand-core-dev (=0.3.0-1)
* bullseye (testing):
  - librust-rand-core-0.4-dev (= 0.4.2-1) with:
Provides: librust-rand-core-dev (= 0.4.2-1)
Breaks: librust-rand-core-dev (<< 0.4.3-~~)
* sid (unstable):
  - librust-rand-core-dev (= 0.5.1-1)

So librust-rand-core-dev collides with the Breaks requirement, while not
having an updated version available in testing.

Our packaging scripts check that the latest non-semver-suffixed version
is packaged (here: 0.5.1), which is the case, but of course it can't
control when packages migrate.

The whole compound covering the librust-rand-* packages has undergone
significant refactoring upstream which was a bit tedious to update in
Debian. The rust-rand-core 0.5.1 packages should be able to migrate by
now, don't know why they didn't.

Best regards,
Wolfgang.

Bug#945796: [Pkg-rust-maintainers] Bug#945796: rust-url-serde: (build-)depends on obsolete virtual package.

[Wolfgang Silbermayr]

On 11/28/19 9:04 PM, peter green wrote:
> Package: rust-url-serde
> Version: 0.2.0-1
> Severity: serious
> Tags: bullseye, sid
> 
> librust-url-serde-dev depends on and rust-url-serde build-depends on
> librust-url-1+default-dev which is no longer provided by rust-url. It
> seems to have been replaced by librust-url-2+default-dev

The url_serde crate has been updated the last time to 0.2.0 on April 30,
2017. It lived in the servo rust-url repository, where it got removed on
July 15, 2019. To me it seems to be obsolete. Nothing (build-)depends on
it yet. I assume it got packaged as a dependency for something else, but
either that something didn't get packaged yet, or it doesn't require
this crate any more.

@paride can you please check and file a ROM if no longer needed?

Thanks.

Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Wolfgang Silbermayr]

On 10/30/19 10:34 PM, Adam D. Barratt wrote:
> On Wed, 2019-10-30 at 21:16 +0100, Wolfgang Silbermayr wrote:
>> The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
>> dependencies either migrated to a non-semver-suffixed version of
>> rust-
>> crossbeam-utils or don't depend on it anymore at all.
>> The only remaining dependency as of now is rust-crossbeam-epoch-0.5
>> for which I
>> asked the maintainer to file a RM request as well.
> 
> Are you requesting removal from unstable?

Yes, that's correct.

I selected that in `reportbug`, seems it didn't get pre-filled or I
accidentially deleted it.

I initially attempted to report that bug against the `ftp.debian.org`
pseudo-package, selecting RoM from unstable as described in the
developers reference section 5.9.2, but it showed a final dialog telling
that I should report the bug against `release.debian.org`. Sorry if
that's the wrong pseudo-package.

Best regards,
Wolfgang.

Bug#943855: RM: rust-crossbeam-utils-0.5/0.5.2-2

[Wolfgang Silbermayr]

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

The rust-crossbeam-utils-0.5 package is no longer in use. All reverse
dependencies either migrated to a non-semver-suffixed version of rust-
crossbeam-utils or don't depend on it anymore at all.
The only remaining dependency as of now is rust-crossbeam-epoch-0.5 for which I
asked the maintainer to file a RM request as well.

Bug#941784: Make reason for preventing re-upload more clear

[Wolfgang Silbermayr]

Package: dput
Version: 1.0.3
Severity: minor

When re-uploading an unmodified .changes file (e.g. after upload permissions
got fixed), dput rejects the upload with this message:

> Trying to upload package to ftp-master (ftp.upload.debian.org)
> Package has already been uploaded to ftp-master on ftp.upload.debian.org
> Nothing more to do for .changes

This message made me think that the upload had been rejected server-side, but I
eventually got the hint that it is possible to force the re-upload with the
`-f` / `--force` parameter. A different wording would probably help to
understand this easier (or at least know that the `--force` parameter is
available).

A suggestion would be something like:

> Trying to upload package to ftp-master (ftp.upload.debian.org)
> Package has already been uploaded to ftp-master on ftp.upload.debian.org
> If you intend to re-upload the package, use `dput --force .changes`
> Nothing more to do for .changes

It does not tell explicitly that the upload is blocked by the local machine and
not the server, but at least it gives some hint where to continue.



-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /home/silwol/.dput.cf --

[DEFAULT]
login = *
method = ftp
hash = md5
allow_unsigned_uploads = 0
allow_dcut = 0
distributions = 

Bug#931534: ITP: viu -- Command-line application to view images from the terminal

[Wolfgang Silbermayr]

On 7/7/19 11:51 AM, Adam Borowski wrote:
> On Sun, Jul 07, 2019 at 11:25:47AM +0200, Wolfgang Silbermayr wrote:
>>Package name: viu
>> Upstream Author: Atanas Yankov 
>> URL: https://github.com/atanunq/viu
>> Description:
>> viu is a small command-line application to view images from the terminal
>> written in Rust. It uses unicode lower half blocks to fit 2 pixels into
>> a single cell by adjusting foreground and background colors accordingly.
> 
> Hi!
> This looks exactly as what "catimg" does -- is there are any reason to
> prefer viu over catimg?

[...]

> Thus: is there anything viu does better than the above tools?

In fact, catimg is new to me. I did a quick test, and it looks quite good.

I follow what is happening in the Rust crates ecosystem, so I stumbled
over viu when it got published, and thought it would be great to have
this tool packaged.

A quick test showed nearly identical output when scaled to the same size
(with minimal difference in colors, I assume due to downscaling).

What I find a bit inconvenient is that catimg defaults to the full
terminal width whereas viu takes both height and width of the terminal
into account.

Do you think it's a disadvantage to have some similar command-line tools
packaged where some people would prefer one and some the other?
Especially with the consideration that - at least in my experience -
rust packages require very low amount of work for packaging and maintenance?

Wolfgang.

Bug#931534: ITP: viu -- Command-line application to view images from the terminal

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

   Package name: viu
Version: 0.2.1
Upstream Author: Atanas Yankov 
URL: https://github.com/atanunq/viu
License: MIT
Description:
viu is a small command-line application to view images from the terminal
written in Rust. It uses unicode lower half blocks to fit 2 pixels into
a single cell by adjusting foreground and background colors accordingly.

Bug#927314: Reported upstream

[Wolfgang Silbermayr]

Thanks for your report.

Forwarded to upstream:
https://github.com/tomprogrammer/rust-ascii/issues/61

Bug#901148: Some analysis

[Wolfgang Silbermayr]

Having been hit by this on Buseter Testing before, I did some
investigation. Here are my findings:

Conditions for this bug to appear are:

   * timidity-daemon is installed
   * timidity service (from the timidity-daemon package) is enabled or
 timidity gets started by hand
   * No midi device is provided by the kernel

Only if all of these these conditions are fulfilled at the same time,
this comes into effect.

A quick test on Stretch with the timidity service enabled did not reveal
the bug. However, timidity was not running after boot, and I didn't find
the reason why. After starting it by hand, pulseaudio got unusable, just
like it does on Buster. So my guess is that the bug was actually present
in Stretch, it just did not show due to timidity not starting properly
at boot.

A removal of timidity-daemon on affected systems is sufficient. It is
set to "Suggests" instead of "Recommends" with timidity as of 2.14.0-8,
so the majority of people who install games or music programs that pull
in timidity will no longer be affected.

People who will be affected are those that got timidity-daemon installed
in Stretch by the "Recommends" dep, and then upgraded to Buster. Even an
apt autoremove will keep timidity-daemon installed.

One way to escape this bug is to have a midi device available in the
system, which can also be snd_virmidi. But I don't consider this a clean
solution, because it will probably interfere for people who have real
midi hardware.

What other options do we have? Simply keep it as-is and document it in
the the upgrade manual? Or do we have some mechanism available that
would remove timidity-daemon if it was installed automatically? Any
other ideas?

Bug#921058: Cannot release-build crate `sysinfo` on i386

[Wolfgang Silbermayr]

Package: rustc
Version: 1.32.0+dfsg1-1
Severity: normal

When using the debian package of rustc, an attempt to build the sysinfo 0.8.0
crate fails:

> LLVM ERROR: No support for lowering a copy into EFLAGS when used by this
> instruction!

I only got this on the i386 with the debian package of rustc, in both version
1.31.0 and 1.32.0. A rustc installed through rustup works fine. The debian
rustc only shows this behavior when compiling a release build of the crate, the
debug build works just fine.

It seems to be the cause for the process-viewer build failure on i386 [0].

LLVM weekly #240 [1] mentions a fix for a subtle bug in EFLAGS copy lowering
[2], but as far as I can see, the debian llvm 0.7 code has these changes
included already, so I assume this is not the cause.

The cause might be triggered by the way structures are defined and/or used in
the sysinfo crate's src/linux/processor.rs file. Even though I didn't directly
find something suspicious in the source code, for example replacing the
contents of the CpuValues::work_time() function with an unimplemented!()
call makes the crate compile, I assume because the relevant code gets optimized
out.

--

[0] https://buildd.debian.org/status/fetch.php?pkg=rust-process-
viewer=i386=0.2.0-1=1547395957=0
[1] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125111.html
[2] https://reviews.llvm.org/rL338481



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

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

Versions of packages rustc depends on:
ii  binutils  2.31.1-11
ii  gcc   4:8.2.0-2
ii  libc6 2.28-5
ii  libc6-dev [libc-dev]  2.28-5
ii  libgcc1   1:8.2.0-16
ii  libllvm7  1:7.0.1-4
ii  libstd-rust-dev   1.32.0+dfsg1-1
ii  libstdc++68.2.0-16

Versions of packages rustc recommends:
ii  cargo 0.32.0-1
ii  rust-gdb  1.32.0+dfsg1-1

Versions of packages rustc suggests:
pn  rust-doc  
pn  rust-src  

-- no debconf information
silwol@debian:~/Downloads/sysinfo$ cargo build --release --verbose
   Compiling arrayvec v0.4.10   

 
   Compiling nodrop v0.1.13 

 
 Running `rustc --crate-name build_script_build 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.4.10/build.rs
 --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C 
metadata=bfa3fe6e9c3844c9 -C extra-filename=-bfa3fe6e9c3844c9 --out-dir 
/home/silwol/Downloads/sysinfo/target/release/build/arrayvec-bfa3fe6e9c3844c9 
-L dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints 
allow`
 Running `rustc --crate-name nodrop 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/nodrop-0.1.13/src/lib.rs
 --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C 
metadata=23b87706b0f0a70a -C extra-filename=-23b87706b0f0a70a --out-dir 
/home/silwol/Downloads/sysinfo/target/release/deps -L 
dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints allow`
   Compiling libc v0.2.48   

 
 Running `rustc --crate-name build_script_build 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.48/build.rs
 --color always --crate-type bin --emit=dep-info,link -C opt-level=3 --cfg 
'feature="default"' --cfg 'feature="use_std"' -C metadata=b27fc7f09868766c -C 
extra-filename=-b27fc7f09868766c --out-dir 
/home/silwol/Downloads/sysinfo/target/release/build/libc-b27fc7f09868766c -L 
dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints allow`
   Compiling cfg-if v0.1.6  

 
 Running `rustc --crate-name cfg_if 
/home/silwol/.cargo/registry/src/github.com-1ecc6299db9ec823/cfg-if-0.1.6/src/lib.rs
 --color always --crate-type lib --emit=dep-info,link -C opt-level=3 -C 
metadata=8e9fdbf021b92c7d -C extra-filename=-8e9fdbf021b92c7d --out-dir 
/home/silwol/Downloads/sysinfo/target/release/deps -L 
dependency=/home/silwol/Downloads/sysinfo/target/release/deps --cap-lints allow`
   Compiling scopeguard v0.3.3  
  

Bug#916325: ITP: rustdoc-stripper -- Strip rustdoc comments from source code

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: 
debian-de...@lists.debian.org,pkg-rust-maintain...@alioth-lists.debian.net

   Package name: rustdoc-stripper
Version: 0.1.5
Upstream Author: Guillaume Gomez 
URL: https://github.com/GuillaumeGomez/rustdoc-stripper
License: Apache-2.0
Description: Strip rustdoc comments from source code

rustdoc-stripper is a tool used to remove rustdoc comments from your code and 
save them in a comments.cmts file if you want to regenerate them.

Bug#913783: ITP: hexyl -- Command-line hex viewer with colored output

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

   Package name: hexyl
Version: 0.2.0
Upstream Author: David Peter 
URL: https://github.com/sharkdp/hexyl
License: MIT/Apache-2.0
Description: hexyl is a simple hex viewer for the terminal. It uses
 colored output to distinguish different categories of
 bytes (NULL bytes, printable ASCII characters, ASCII
 whitespace characters, other ASCII characters and
 non-ASCII).

Bug#911452: [Pkg-rust-maintainers] Bug#911452: rust-pulldown-cmark: Please generate the manpages as part of the build process

[Wolfgang Silbermayr]

On 10/20/18 12:55 PM, Sylvestre Ledru wrote:
> Package: rust-pulldown-cmark
> Severity: normal
> 
> Hello
> 
> Currently, the manpage is in the VCS. It should be generated at build phase.
> This to avoid being out of sync.

I would love to generate it at build. I intentionally decided not to,
because for this the help2man run would have to call the newly built
binary, and if i remember correctly this is a problem when
cross-compiling a package. If we have a solution to this problem, or if
this is a misunderstanding from my side, we can generate the manpage at
package build time.

Wolfgang.

Bug#895355: ITP: rust-getopts-0.2 -- Rust library for option parsing for CLI utilities

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org


   Package name: rust-getopts-0.2
Version: 0.2.17
Upstream Author: The Rust Project Developers
URL: https://github.com/rust-lang/getopts
License: MIT, Apache-2.0
Description: Rust library for option parsing for CLI utilities

--

This is one of two dependencies for getting rust-pulldown-cmark-0.1
packaged (See: #895353).

Regards,
Wolfgang.

Bug#895356: ITP: rust-bitflags-0.9 -- Rust macro to generate structures which behave like a set of bitflags

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org


   Package name: rust-bitflags-0.9
Version: 0.9.1
Upstream Author: The Rust Project Developers
URL: https://github.com/rust-lang-nursery/bitflags
License: MIT, Apache-2.0
Description: Rust macro to generate structures which behave like a
 set of bitflags

A Rust macro to generate structures which behave like a set of bitflags

--

This is one of two dependencies for getting rust-pulldown-cmark-0.1
packaged (See: #895353).

Regards, Wolfgang.

Bug#895353: ITP: rust-pulldown-cmark-0.1 -- Pull parser for CommonMark

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org


   Package name: rust-pulldown-cmark-0.1
Version: 0.1.2
Upstream Author: Raph Levien 
URL: https://github.com/google/pulldown-cmark
License: MIT
Description: Pull parser for CommonMark, written in Rust.

Pulldown-cmark is a pull parser library for CommonMark, written in Rust.
It comes with a simple command-line tool, useful for rendering to HTML,
and is also designed to be easy to use from as a library.
It is designed to be:
* Fast; a bare minimum of allocation and copying
* Safe; written in pure Rust with no unsafe blocks
* Versatile; in particular source-maps are supported
* Correct; the goal is 100% compliance with the CommonMark spec

--

I suggest to use the source package name rust-pulldown-cmark-0.1 because
the main usage is as a library, e.g. in the mdbook tool or the cobalt
static site generator.

I intend to help maintaining rust-based packages in Debian, and
CommonMark seems to be a first low-hanging fruit, because it only
depends on only two other rust libraries (bitflags and getopts) which is
not common in the rust environment. It provides value as a stand-alone
command-line tool for generating HTML from CommonMark files.

Regards,
Wolfgang.

Bug#786970: [dh-systemd] dh-systemd leaves dangling symlinks after dpkg purge and remove

[Wolfgang Silbermayr]

Package: dh-systemd
Version: 1.22
Severity: normal

--- Please enter the report below this line. ---

I have a package which contains the following debian/package.service
file and uses dh-systemd:

 [Unit]
 Description=Package description
 
 [Service]
 Type=oneshot
 ExecStart=/usr/lib/package/bin/some-tool
 
 [Install]
 WantedBy=multi-user.target

When installing the package, then purging and removing it using dpkg, a
dangling symlink is left on the system:

/etc/systemd/system/multi-user.target.wants/package.service -
/lib/systemd/system/package.service

A snippet like this should basically do the work (similar to what can be
found in lxdm 0.5.1-1 postrm in current unstable):

 # Test if /etc/systemd/system/package.service is broken now
 SERVICE_FILE=/etc/systemd/system/service.service
 if [ -L $SERVICE_FILE ]  [ ! -e $SERVICE_FILE ]; then
   echo WARN: clearing dangling symlink $SERVICE_FILE 2
   rm -f $SERVICE_FILE
 fi

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.0
  500 stable-updates  ftp.cz.debian.org
  500 stable  security.debian.org
  500 stable  ftp.cz.debian.org
  100 jessie-backports ftp.cz.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.



signature.asc
Description: OpenPGP digital signature

Bug#786970: Further notice

[Wolfgang Silbermayr]

As a further notice, this problem occurred to me during a piuparts run
(piuparts 0.62 from jessie).



signature.asc
Description: OpenPGP digital signature

Bug#786970: [dh-systemd] dh-systemd leaves dangling symlinks after dpkg purge and remove

[Wolfgang Silbermayr]

On 05/27/2015 04:21 PM, Michael Biebl wrote:

 Is it possible, that you/piuparts removed the init-system-helpers
 package, before you purged your test package?
 
 The cleanup routine relies on init-system-helpers to be around.
 Since init-system-helpers is quasi-essential, it will never be uninstall
 on a real system, so this shouldn't be a problem in practice.

You are right, piuparts removed init-system-helpers.

It seems that #752256 is the cause of this problem. I'll verify that
this works properly when setting init-system-helpers quasi-essential in
piuparts.



signature.asc
Description: OpenPGP digital signature

Bug#764445: xserver-xorg: screen blanking when rotating with kernel 3.15 or newer with Atom Z36xxx/Z37xxx integrated graphics

[Wolfgang Silbermayr]

On Thu, 9 Oct 2014 01:11:46 +0200 Julien Cristau jcris...@debian.org
wrote:

 I suspect you're going to have to bisect.

Done that, the winner is:

commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1

Any hint on what next steps I can take in order to get this issue sorted
out? Maybe report the issue upstream?



signature.asc
Description: OpenPGP digital signature

Bug#764445: Upstream bug

[Wolfgang Silbermayr]

I reported the bug to upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=84974



signature.asc
Description: OpenPGP digital signature

Bug#764445: xserver-xorg: screen blanking when rotating with kernel 3.15 or newer with Atom Z36xxx/Z37xxx integrated graphics

[Wolfgang Silbermayr]

Package: xserver-xorg
Version: 1:7.7+7
Severity: normal

Dear Maintainers,

When rotating the screen to the left or right using e.g. xrandr -o left, it
goes blank.

I am no longer able to use Ctrl+Alt+Fn for switching to a console, but the
machine is still reachable over network. It also does not switch back when
calling a shell command like xrandr -o left; sleep 10; xrandr -o normal.

I tried the following kernels (partly from snapshots.debian.org and 
experimental):

3.14-2   = works
3.15-rc8 = fails
3.16-2   = fails
3.17-rc5 = fails

Please let me know if you need any further information.


-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Oct  7 07:22 /etc/X11/X - /usr/bin/Xorg
-rwxr-xr-x 1 root root 2397280 Sep 22 23:49 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
Z36xxx/Z37xxx Series Graphics  Display [8086:0f31] (rev 0c)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 3.16-2-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.3 
(Debian 4.8.3-11) ) #1 SMP Debian 3.16.3-2 (2014-09-20)

No Xorg X server log files found.
-- I guess this is due to the switch to journalctl. If you need further
information, I can extract this for you. So far the Xorg log looks the same from
either kernel.

udev information:
-
P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXPWRBN_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: KEY=10 0
E: MODALIAS=input:b0019vp0001e-e0,1,k74,ramlsfw
E: NAME=Power Button
E: PHYS=LNXPWRBN/button/input0
E: PRODUCT=19/0/1/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=13732

P: /devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event4
N: input/event4
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event4
E: DEVPATH=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input4/event4
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXPWRBN:00
E: ID_PATH_TAG=acpi-LNXPWRBN_00
E: MAJOR=13
E: MINOR=68
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=82922
E: XKBLAYOUT=us
E: XKBMODEL=pc105

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
E: EV=3
E: ID_FOR_SEAT=input-acpi-LNXVIDEO_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXVIDEO:00
E: ID_PATH_TAG=acpi-LNXVIDEO_00
E: KEY=3e000b 0 0 0
E: MODALIAS=input:b0019vp0006e-e0,1,kE0,E1,E3,F1,F2,F3,F4,F5,ramlsfw
E: NAME=Video Bus
E: PHYS=LNXVIDEO/video/input0
E: PRODUCT=19/0/6/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=77970

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10/event9
N: input/event9
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event9
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10/event9
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-LNXVIDEO:00
E: ID_PATH_TAG=acpi-LNXVIDEO_00
E: MAJOR=13
E: MINOR=73
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=79967
E: XKBLAYOUT=us
E: XKBMODEL=pc105

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0D:00/input/input0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0D:00/input/input0
E: EV=21
E: ID_FOR_SEAT=input-acpi-PNP0C0D_00
E: ID_INPUT=1
E: ID_PATH=acpi-PNP0C0D:00
E: ID_PATH_TAG=acpi-PNP0C0D_00
E: MODALIAS=input:b0019vp0005e-e0,5,kramlsfw0,
E: NAME=Lid Switch
E: PHYS=PNP0C0D/button/input0
E: PRODUCT=19/0/5/0
E: PROP=0
E: SUBSYSTEM=input
E: SW=1
E: TAGS=:seat:
E: USEC_INITIALIZED=6474

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0D:00/input/input0/event0
N: input/event0
E: DEVNAME=/dev/input/event0
E: 
DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0D:00/input/input0/event0
E: ID_INPUT=1
E: ID_PATH=acpi-PNP0C0D:00
E: ID_PATH_TAG=acpi-PNP0C0D_00
E: MAJOR=13
E: MINOR=64
E: SUBSYSTEM=input
E: TAGS=:power-switch:
E: USEC_INITIALIZED=78958

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0E:00/input/input1
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0E:00/input/input1
E: EV=3
E: ID_FOR_SEAT=input-acpi-PNP0C0E_00
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_PATH=acpi-PNP0C0E:00
E: ID_PATH_TAG=acpi-PNP0C0E_00
E: KEY=4000 0 0
E: MODALIAS=input:b0019vp0003e-e0,1,k8E,ramlsfw
E: NAME=Sleep Button
E: PHYS=PNP0C0E/button/input0
E: PRODUCT=19/0/3/0
E: PROP=0
E: SUBSYSTEM=input
E: TAGS=:seat:
E: USEC_INITIALIZED=9294

P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/PNP0C0E:00/input/input1/event1
N: input/event1
E: BACKSPACE=guess
E: DEVNAME=/dev/input/event1
E: 

Bug#764445: xserver-xorg: screen blanking when rotating with kernel 3.15 or newer with Atom Z36xxx/Z37xxx integrated graphics

[Wolfgang Silbermayr]

One thing I forgot:
xrandr -o inverted works as expected, but calling xrandr -o normal
afterwards also causes the screen to go blank.


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

Bug#764452: libqt5core5a: Please fix QTBUG-41100 Problems with UTF-8 in QJsonObject keys for 5.3.2

[Wolfgang Silbermayr]

Package: libqt5core5a
Version: 5.3.2+dfsg-3
Severity: normal

Dear Maintainer,

QTBUG-41100 fixes an issue with JSON which contains UTF-8 characters
in keys. A patch is available for 5.4.0, but as far as I know, Debian will
ship 5.3.2 with Jessie.

There seems to be no easy way to work around the issue other than
not using Qt for loading JSON. It would be very helpful to have the
fix included in Jessie.

QTBUG-41100: https://bugreports.qt-project.org/browse/QTBUG-41100
Patch: https://codereview.qt-project.org/94108


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

Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libqt5core5a depends on:
ii  libc6  2.19-11
ii  libgcc11:4.9.1-16
ii  libglib2.0-0   2.42.0-1
ii  libicu52   52.1-6
ii  libstdc++6 4.9.1-16
ii  multiarch-support  2.19-11
ii  zlib1g 1:1.2.8.dfsg-2

Versions of packages libqt5core5a recommends:
ii  qttranslations5-l10n  5.3.2-2

Versions of packages libqt5core5a suggests:
ii  libthai0  0.1.21-1

-- no debconf information


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

Bug#751084: qtbase5-doc-html: HTML documentation not exposed in /usr/share/doc directory

[Wolfgang Silbermayr]

Package: qtbase5-doc-html
Version: 5.3.0+dfsg-5
Severity: normal

Dear Maintainers,

In Jessie, the qtbase5-doc-html package installs the files in
/usr/share/qt5/doc. When exposing the doc directory or parts of it using
one of the doc-base , this leads to a situation where the API
documentation can not be accessed. A symlink in
/usr/share/doc/qtbase5-doc/html pointing to /usr/share/qt5/doc/ (or
maybe better: a series of specific symlinks, located at
/usr/share/doc/qtbase5-doc/html/qtmodule pointing to
/usr/share/qt5/doc/qtmodule) would solve the problem.



signature.asc
Description: OpenPGP digital signature

Bug#729224: ITP: gcovr -- Summarize code coverage results from gcov

[Wolfgang Silbermayr]

On 06/02/2014 06:36 PM, Sylvestre Ledru wrote:
 Hello
 
 Any progress on this? I can sponsor this package.

Have you tried the package from my repo? In my opinion it is in shape
for upload, we are using it in-house since we created it and had no
issues so far.

Maybe you could have a closer look at it, and if it's OK, I would be
very happy if you could sponsor it. Otherwise I am glad to take any
feedback you have and fix the issues you find.

Thanks, Wolfgang.



signature.asc
Description: OpenPGP digital signature

Bug#729224: ITP: gcovr -- Summarize code coverage results from gcov

[Wolfgang Silbermayr]

Dear Paolo,

I have done some packaging work adapting the 2.4 package from ubuntu and
making it work with the version 3.1 of gcovr.

I have it inside a git-buildpackage repo on
https://github.com/silwol/gcovr

Please let me know if there is any further work to be done on the package.

Regards,
Wolfgang.




signature.asc
Description: OpenPGP digital signature

Bug#494146: ITP: freenukum -- Clone of the Duke Nukem 1 Jump'n Run game

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist


* Package name : freenukum
Version: 0.2.10
Upstream Author : Wolfgang Silbermayr [EMAIL PROTECTED]
* URL : http://launchpad.net/freenukum
* License : GPLv3+
Description: Clone of the original Duke Nukum 1 Jump'n Run game
 The Freenukum Jump'n Run game is a clone of the old EGA graphics
 based 2D game Duke Nukem. It uses the original Duke Nukem level and
 graphics files.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#494150: ITP: freenukum -- Clone of the Duke Nukem 1 Jump'n Run game

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist


* Package name : freenukum
Version: 0.2.10
Upstream Author : Wolfgang Silbermayr [EMAIL PROTECTED]
* URL : http://launchpad.net/freenukum
* License : GPLv3+
Description: Clone of the original Duke Nukum 1 Jump'n Run game
 The Freenukum Jump'n Run game is a clone of the old EGA graphics
 based 2D game Duke Nukem. It uses the original Duke Nukem level and
 graphics files.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#494175: ITP: gypsy -- GPS multiplexing daemon

[Wolfgang Silbermayr]

Package: wnpp
Severity: wishlist


* Package name : gypsy
Version: 0.6
Upstream Author : Iain Holmes [EMAIL PROTECTED]
* URL : http://gypsy.freedesktop.org/
* License : GPLv2 for the daemon, LGPLv2 for the library
Description: GPS multiplexing daemon
 Gypsy is a GPS multiplexing daemon which allows multiple clients to
 access GPS data from multiple GPS sources concurrently.
 Gypsy hides the tricky details of parsing NMEA from the client
 applications, passing the data as simple values for the clients to use.
 It uses D-Bus to notify clients about location changes, sitting on the
 system bus, issuing signals as the GPS data changes.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]