Bug#1055670: fwknop-server: must Depends: apparmor-profiles-extra

[Ximin Luo]

Package: fwknop-server
Version: 2.6.10-18
Severity: serious
Tags: patch security
Justification: Policy 7.2
X-Debbugs-Cc: Debian Security Team 

Dear Maintainer,

The latest update breaks apparmor for the whole system.

/etc/apparmor.d/usr.sbin.fwknopd:
  include 

This must declare Depends: apparmor-profiles-extra.

Otherwise the apparmor service can't parse the file and will refuse to start.

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fwknop-server depends on:
ii  init-system-helpers  1.65.2
ii  iptables 1.8.9-2
ii  libc62.37-12
ii  libfko3  2.6.10-18
ii  libpcap0.8   1.10.4-4

fwknop-server recommends no packages.

fwknop-server suggests no packages.

-- Configuration Files:
/etc/fwknop/access.conf [Errno 13] Permission denied: '/etc/fwknop/access.conf'
/etc/fwknop/fwknopd.conf [Errno 13] Permission denied: 
'/etc/fwknop/fwknopd.conf'

-- no debconf information

Bug#1011975: [Pkg-rust-maintainers] Bug#1011975: rustc: missing dependency on lld-13 (shipps broken rustc-lld symlink)

[Ximin Luo]

Control: forcemerge 943859 -1
Control: notfound -1 1.59.0+dfsg1-1

Not a bug, see #943859

Pirate Praveen:
> Package: rustc
> Version: 1.59.0+dfsg1-1
> Severity: serious
> Justification: ships broken symbolic link to rustc-lld
> 
> 
> $ ls -l /usr/bin/rust-lld
> lrwxrwxrwx 1 root root 6 മേയ് 11 13:11 /usr/bin/rust-lld -> lld-13
> 
> I think lld-13 should be at least recommends instead of suggests since the 
> package ships a broken symlink otherwise.
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#998415: [Pkg-rust-maintainers] Bug#998415: With a recent upload of rust-serde the autopkgtest of rust-debcargo, fails in testing when that autopkgtest is run with the binary packages, of rust-serd

[Ximin Luo]

In other words, I don't see what value these bug reports are adding.

As long as the package is not in Debian Testing, there are very excellent 
status pages developed by the Debian Release team to make us aware of the 
problem. Additional bug reports informing us of what we already know 
(uninstallable, bd-uninstallable, blah blah blah) do not add extra value, in 
fact they reduce value by forcing us to close bug reports.

Best,
Ximin

Ximin Luo:
> Due to the nature of the Rust upstream ecosystem, bugs like this are expected 
> from time to time as we update dependent crates.
> 
> A reversion in terms of downgrading the version using +really-like schemes is 
> not feasible at the current time, see 
> https://salsa.debian.org/rust-team/debcargo/-/issues/31.
> 
> rust-cargo is blocked on various crates in NEW. rust-debcargo is likewise 
> blocked on rust-cargo.
> 
> In the meantime I am happy for these packages to be kept out of Debian 
> Testing as per britney's automated process; I performed the uploads of the 
> dependency packages well aware that this sort of breakage would result. It is 
> not against Debian Policy to have broken packages in Debian Unstable, that is 
> exactly what it is for.
> 
> Paul Gevers:
>> Control: reassign 998415 rust-cargo
>> Control: close 998415 0.57.0-1
>> Control: affects 998415 src:rust-serde src:rust-debcargo
>>
>> Hi Peter,
>>
>> On 04-11-2021 01:19, Peter Green wrote:
>>> Reassign 998415 rust-cargo
>>> Close 998415 0.57.0-1
>>> Thanks
>>
>> ^ Fixing this, the message wasn't sent to control@b.d.o
>>
>>> I can prepare a TPU upload if you would like. Or we can just wait it out
>>> and see what
>>> happens after the Packages pass new and Debcargo is updated.
>>
>> Depends on how long that's going to take and how the TPU would look
>> like. If this is taking long (the RC limit is 60 days), then please
>> contact the Release Team via an unblock request to discuss the potential
>> upload before uploading. An alternative (better from my RT perspective)
>> is to revert the new upstream version of rust-cargo, fix the issue in
>> unstable, have that migrate and then reupload the new upstream version
>> to unstable. That way the RT doesn't need to be further involved.
>>
>> Paul
>>
>>
>> ___
>> Pkg-rust-maintainers mailing list
>> pkg-rust-maintain...@alioth-lists.debian.net
>> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>>
> 
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#998415: With a recent upload of rust-serde the autopkgtest of rust-debcargo,fails in testing when that autopkgtest is run with the binary packages,of rust-serde from unstable. It passes when run w

[Ximin Luo]

Due to the nature of the Rust upstream ecosystem, bugs like this are expected 
from time to time as we update dependent crates.

A reversion in terms of downgrading the version using +really-like schemes is 
not feasible at the current time, see 
https://salsa.debian.org/rust-team/debcargo/-/issues/31.

rust-cargo is blocked on various crates in NEW. rust-debcargo is likewise 
blocked on rust-cargo.

In the meantime I am happy for these packages to be kept out of Debian Testing 
as per britney's automated process; I performed the uploads of the dependency 
packages well aware that this sort of breakage would result. It is not against 
Debian Policy to have broken packages in Debian Unstable, that is exactly what 
it is for.

Paul Gevers:
> Control: reassign 998415 rust-cargo
> Control: close 998415 0.57.0-1
> Control: affects 998415 src:rust-serde src:rust-debcargo
> 
> Hi Peter,
> 
> On 04-11-2021 01:19, Peter Green wrote:
>> Reassign 998415 rust-cargo
>> Close 998415 0.57.0-1
>> Thanks
> 
> ^ Fixing this, the message wasn't sent to control@b.d.o
> 
>> I can prepare a TPU upload if you would like. Or we can just wait it out
>> and see what
>> happens after the Packages pass new and Debcargo is updated.
> 
> Depends on how long that's going to take and how the TPU would look
> like. If this is taking long (the RC limit is 60 days), then please
> contact the Release Team via an unblock request to discuss the potential
> upload before uploading. An alternative (better from my RT perspective)
> is to revert the new upstream version of rust-cargo, fix the issue in
> unstable, have that migrate and then reupload the new upstream version
> to unstable. That way the RT doesn't need to be further involved.
> 
> Paul
> 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#998347: librust-bindgen+env-logger-dev: uninstallable - depends on non-existing package librust-env-logger-0.7+default-dev

[Ximin Luo]

Source: rust-bindgen
Followup-For: Bug #998347

That is not how rust Debian packaging works; your patch will get lost with the
next upload of the autogenerated package.

If you want your patch to not get lost, do it via the normal process:

https://salsa.debian.org/rust-team/debcargo-conf/

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#998345: librust-quickcheck+env-logger-dev: uninstallable - depends on non-existing package librust-env-logger-0.7-dev

[Ximin Luo]

Source: rust-quickcheck
Followup-For: Bug #998345
Control: close -1

> Correction: It is the binary package librust-quickcheck+env-logger-dev 
> which depends on librust-env-logger-0.7-dev.

env-logger-0.7 is sitting in NEW. There is no action to take on this package, 
therefore closing.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#998347: closing 998347

[Ximin Luo]

notfound 998347 0.59.1-1 
close 998347 
thanks

env-logger-0.7 is sitting in NEW. There is no action to take on this package, 
therefore closing.

Bug#998345: closing 998345

[Ximin Luo]

close 998345 
thanks

See my previous message.

Bug#998345: rust-quickcheck: invalid bug report

[Ximin Luo]

Source: rust-quickcheck
Followup-For: Bug #998345

Control: notfound -1 0.9.2-1
Control: close -1

Not sure how you came to this conclusion.

Package: librust-rand+std-dev
Provides:
 librust-rand-0.7+default-dev (= ${binary:Version}),

$ sudo aptitude install librust-quickcheck-dev
[sudo] password for infinity0: 
The following NEW packages will be installed:
  librust-aho-corasick+std-dev{a} librust-aho-corasick-dev{a} 
librust-atty-dev{a} librust-bitflags-dev{a} librust-cfg-if-0.1-dev{a} 
librust-cloudabi+default-dev{a} librust-cloudabi-dev{a} 
librust-env-logger+default-dev{a} 
  librust-env-logger+regex-dev{a} librust-env-logger-dev{a} 
librust-getrandom-dev{a} librust-humantime-dev{a} librust-libc-dev{a} 
librust-lock-api-dev{a} librust-log-dev{a} librust-memchr-dev{a} 
librust-once-cell-dev{a} 
  librust-parking-lot-core-dev{a} librust-parking-lot-dev{a} 
librust-ppv-lite86+default-dev{a} librust-ppv-lite86-dev{a} 
librust-quickcheck+default-dev{a} librust-quickcheck+regex-dev{a} 
librust-quickcheck+use-logging-dev{a} 
  librust-quickcheck-dev librust-rand+alloc-dev{a} 
librust-rand+getrandom-dev{a} librust-rand+std-dev{a} 
librust-rand-chacha+default-dev{a} librust-rand-chacha+std-dev{a} 
librust-rand-chacha-dev{a} 
  librust-rand-core+getrandom-dev{a} librust-rand-core+std-dev{a} 
librust-rand-core-dev{a} librust-rand-dev{a} librust-rand-hc-dev{a} 
librust-redox-syscall-dev{a} librust-regex+default-dev{a} 
librust-regex+perf-cache-dev{a} 
  librust-regex+perf-dev{a} librust-regex+perf-literal-dev{a} 
librust-regex+unicode-age-dev{a} librust-regex+unicode-bool-dev{a} 
librust-regex+unicode-case-dev{a} librust-regex+unicode-dev{a} 
librust-regex+unicode-gencat-dev{a} 
  librust-regex+unicode-perl-dev{a} librust-regex+unicode-script-dev{a} 
librust-regex+unicode-segment-dev{a} librust-regex-dev{a} 
librust-regex-syntax+unicode-dev{a} librust-regex-syntax-dev{a} 
librust-scopeguard-dev{a} 
  librust-smallvec-dev{a} librust-termcolor-dev{a} librust-thread-local-dev{a} 
librust-winapi-dev{a} librust-winapi-i686-pc-windows-gnu-dev{a} 
librust-winapi-util-dev{a} librust-winapi-x86-64-pc-windows-gnu-dev{a} 
0 packages upgraded, 60 newly installed, 0 to remove and 220 not upgraded.
Need to get 1,394 kB/2,216 kB of archives. After unpacking 16.8 MB will be used.
Do you want to continue? [Y/n/?] ^C
exit code 130

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#995339: [Pkg-rust-maintainers] Bug#995339: lalrpop: Incomplete license information

[Ximin Luo]

Bastian Germann:
>> In fact there is nowhere in the d/copyright file format to put this 
>> information; and it would not be efficient to do so since the information 
>> already exists in the d/copyright of those other packages.
> 
> Maybe there is nowhere in the DEP-5 format, which is not mandatory by now. 
> This inefficiency is why I suggested to contact FTP Master about it. I do not 
> think, there is a good mechanism for it in Debian right now. Maybe, there 
> should be a similar field to Built-Using that is not about source retaining 
> but about applicable licenses from other packages.
> 

(Note: the name "DEP-5" refers to when the format was just a proposal, but now 
it is the "official" format.)

The current mechanism is to look in the d/copyright of the other package. What 
do you think is bad or not good about it?

Taking a step back for some perspective, I also suggest you might want to spend 
your own time on other things that are more productive and have more real-world 
impact. Nobody is going to get sued over this, there is no legal basis for 
doing so as the license information is already in an easy-to-access place, 
namely the d/copyright of the other package.

This will be my last message in the thread because I also want to spend my time 
doing more constructive things.

Ximin

-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#997112: closing 997112

[Ximin Luo]

close 997112 0.57.0-1
thanks

Bug#995339: lalrpop: Incomplete license information

[Ximin Luo]

Source: rust-lalrpop
Followup-For: Bug #995339

The d/copyright file is about the source package not the binary package, you 
are misinterpreting policy.

In fact there is nowhere in the d/copyright file format to put this 
information; and it would not be efficient to do so since the information 
already exists in the d/copyright of those other packages.

Closing the bug report for this reason.

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (300, 'unstable'), (100, 
'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#986803: [Pkg-rust-maintainers] Bug#986803: CVE-2021-28875 CVE-2021-28876 CVE-2021-28877 CVE-2021-28878 CVE-2021-28879 CVE-2020-36317 CVE-2020-36318

[Ximin Luo]

It looks like these CVEs affect all versions up to 1.52 (which is not yet 
released).

Do you have links to patches fixing these bugs that can be backported to 1.48? 
We've had 1.48 for a while due to the migration freeze, and I've been informed 
that some rust packages in Debian break with newer versions of rustc and will 
need themselves to be updated - so I'd rather not force that during the freeze, 
I'd rather backport security fixes to 1.48.

Best,
Ximin

Moritz Muehlenhoff:
> Package: rustc
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#931003: [Pkg-rust-maintainers] Bug#931003: Removed package(s) from unstable

[Ximin Luo]

These packages are not installed by users, so leaving them as FTBFS is not a 
big deal. If you want to clean it up, please feel free. I can certainly 
understand if people (e.g. me) want to spend their time doing other things.

X

Santiago Vila:
> On Sun, 8 Sep 2019, Ximin Luo wrote:
> 
>> Santiago Vila:
>>> reopen 931003
>>> found 931003 0.2.4-1
>>> fixed 931003 0.2.4-1+rm
>>> thanks
>>>
>>> Hi.
>>>
>>> This was automatically closed by ftpmaster because the package was
>>> removed from unstable, but this still does not fix the FTBFS problem
>>> in stable.
>>>
>>> Thanks.
>>>
>>
>> Please be aware that the Debian Rust team today *does not make any
>> effort* towards bugs affecting Debian Stable. [...]
> 
> Not even FTBFS bugs, as it is the case here?
> 
> There are already 74 packages which FTBFS in stable (by my count), it
> would be much better if every mantainer cared about their own packages.
> I'm curious: does this really sound unreasonable for you?
> 
> Thanks.
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#976658: debcargo is broken (and the autopkgtest didn't catch it).

[Ximin Luo]

debcargo (and cargo) is out of date in Debian and needs to be updated. We had 
been blocked on the FTP binary-NEW policy but there is some progress in that 
area.

Alternatively you could use collapse_features to begin to update it, but I 
personally do not approve of it and haven't been spending time on it.

X

peter green:
> Package: debcargo
> Version: 2.4.3-2+bw
> Severity: grave
> 
> After the recent binnmu of debcargo. debcargo update
> (after deleting the cache) gives.
> 
>>
>>     Updating crates.io index
>> Something failed: failed to fetch 
>> `https://github.com/rust-lang/crates.io-index`
>>
>> Caused by:
>>     invalid version 0 on git_proxy_options; class=Invalid (3)
> 
> This issue was not caught by the autopkgtest.
> 
> In order to check this was indeed caused by the libgit2 update (and not by 
> one of the
> other updates that have happened since the last debcargo build in unstable) I 
> did a
> test build with libgit2-dev from testing but everything else from unstable. 
> That
> test build worked fine.
> 
> I suspect rust-git2/rust-libgit2-sys need to be updated to match the new 
> libgit2.
> 
> I've got to go now, but I'll try look into this issue some more later tonight.
> 


-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#974916: closing 974916

[Ximin Luo]

notfound 974916 3.8.1-1
close 974916 
notfound 974917 3.8.1-1
close 974917
notfound 974919 0.7.19-2
close 974919
notfound 974920 0.7.19-2
close 974920
thanks

Hi Ralf, these issues are a normal way on how Rust packaging works, due to the
fact that the Rust package manager does not pay any special attention to the
concept of "source package" and only cares about "binary package". This means
that a typical Rust Debian source package is in general expected to build
binary packages that depend on other Rust Debian binary packages that may be
uninstallable.

This situation as you rightly pointed out is RC for Debian Stable. However, the
Debian Testing migration script britney already prevents these packages from
migrating to Debian Testing. And the Debian Rust team have scripts that monitor
the reports output by britney. Therefore these extra bug reports are not
helpful, since their usual purpose of blocking Testing migration is already
performed automatically and in a fully-general way by britney. Therefore these
RC bugs you filed serve no purpose but actually slow down our Rust packaging
process, because the next maintainer who fixes the issue will have to hunt down
the bug report number in order to close it, in order to unblock Testing
migration. If you did not file this bug report, then this step would be
unnecessary - britney would unblock as soon as the fix has been uploaded.
Therefore, to save everyone's time, please do not file these types of bug
reports for Rust packages in the future. I am closing these bug reports now
because I noticed them, to save time for maintainers who have to dig them back
up in the future.

In fact there are very likely many more other Rust packages suffering from the
same issue, and perpetually there will always be some in Debian Unstable, as
explained above. Again, filing these bug reports provide no benefit, except add
to the amount of work that Rust Debian packagers have to do to actually
complete the Debian Testing migration process.

See https://github.com/kpcyrd/cargo-debstatus/issues/2 for details. In summary,
it is because the Rust dependency system encodes complex dependency
relationships in a more efficient way than the Debian dependency system,
meaning the typical Rust package expresses more complex dependencies than most
other Debian packages. (But you can get this type of situation with other
languages too, especially those with bootstrap loops. The only difference is
in Rust it's much more common.)

Best,
Ximin

Bug#969609: [Pkg-rust-maintainers] Bug#969609: Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe

[Ximin Luo]

Steve Langasek:
> Ximin,
> 
> On Tue, Sep 08, 2020 at 09:23:49PM +0100, Ximin Luo wrote:
>> You keep filing these same bugs.  I have told you this many times before
>> already: this is just how rust packaging works, Britney's migration policy
>> already prevents these packages from reaching Debian Testing, so there is
>> no problem, no users are affected.
> 
>> You filing these bug reports accomplishes nothing, except delay & annoy
>> other Rust packagers who forget to close these pointless bugs, thereby
>> unnecessarily blocking any fixed packages from actually reaching Debian
>> Testing.  Oftentimes the fix is also not to update the package itself, but
>> to upload another package.  Due to the idiosyncracies of the BTS, not
>> everyone knows how to close these bugs correctly (notfound -1 $version)
>> and it will result in further delays.
> 
>> Please stop filing these bug reports, they only create extra unnecessary
>> work for other people, and make Debian worse for users, by slowing down
>> the stream of fixes.  Britney already prevents Testing migration.
> 
> It is not credible to me that this is "just how rust packaging works".  The
> bugs I am filing are against packages that have been uninstallable in
> unstable for more than 4 months.  The missing dependencies are not in the
> NEW queue, and there are no ITP bugs filed for them.  There is no reason to
> believe, without filing these bugs, that anyone on the rust packaging team
> is doing anything about these missing dependencies.
> 

Why is it not credible? I am one of the main members of the team, and created 
about 80% of the current process. I am telling you it is simply how it works. 
If you want an in-depth description, see 
https://github.com/kpcyrd/cargo-debstatus/issues/2. In summary, it is because 
the Rust dependency system encodes complex dependency relationships in a more 
efficient way than the Debian dependency system, meaning the typical Rust 
package expresses more complex dependencies than most other Debian packages. 
But you can get this type of situation with other languages too, especially 
those with bootstrap loops. The only difference is in Rust it's much more 
common.

(The NEW queue is another unresolved issue that is blocking Rust packaging - we 
have a policy disagreement with the FTP team and nobody has had time to resolve 
it. That is why things might not be on the NEW queue.)

At the end of the day, it doesn't matter if people don't do anything about 
these missing dependencies, because *the britney migration script prevents 
migration to testing*. For the packages that matter, i.e. that need to be 
migrated to testing (& eventually stable), members of this team are forced to 
fix these issues anyway, and we have a documented process for doing this:

https://salsa.debian.org/rust-team/debcargo-conf/-/blob/master/RELEASE.rst

> And filing bug reports in the Debian BTS is the standard way in Debian to
> document bugs in packages.
> 
> And it is unacceptable that Debian maintainers don't know how to operate the
> Debian BTS.
> 

Most Debian Rust Team members are not regular Debian maintainers. And the 
Debian BTS user interface is really unintuitive. So I can't reasonably consider 
it "unacceptable", we have to be realistic regarding volunteer on-boarding.

> So no, I will not stop filing bugs against RC-buggy packages that the Rust
> maintainers are clearly not taking care of.  If you don't want bug reports,
> you have the option to stop uploading packages that are RC buggy from the
> moment they're accepted into the archive.
> 

I am explaining to you why the normal Debian process is inadequate and causes 
more work for everyone in this case. Please trust your fellow maintainers more 
on matters on which they have more expertise. After all of my explanations, 
what benefit do you suppose these bugs are giving?? You filing bug reports is 
not going to magically give people more free time to fix them; when they have 
the free time these problems are automatically and forcibly solved as part of 
our regular process. The bugs do not help this one bit.

Best
Ximin

-- 
GPG: ed25519/56034877E1F87C35
https://github.com/infinity0/pubkeys.git

Bug#969609: [Pkg-rust-maintainers] Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe

[Ximin Luo]

Steve,

You keep filing these same bugs. I have told you this many times before 
already: this is just how rust packaging works, Britney's migration policy 
already prevents these packages from reaching Debian Testing, so there is no 
problem, no users are affected.

You filing these bug reports accomplishes nothing, except delay & annoy other 
Rust packagers who forget to close these pointless bugs, thereby unnecessarily 
blocking any fixed packages from actually reaching Debian Testing. Oftentimes 
the fix is also not to update the package itself, but to upload another 
package. Due to the idiosyncracies of the BTS, not everyone knows how to close 
these bugs correctly (notfound -1 $version) and it will result in further 
delays.

Please stop filing these bug reports, they only create extra unnecessary work 
for other people, and make Debian worse for users, by slowing down the stream 
of fixes. Britney already prevents Testing migration.

Ximin

Steve Langasek:
> Source: rust-zstd
> Version: 0.5.1-1
> Severity: grave
> 
> The rust-zstd package has both a dependency and a build-dependency on
> librust-zstd-safe-2.0.3+experimental-dev, which does not exist anywhere in
> Debian.  Presumably it would be built by a rust-zstd-safe package, but no
> such package exists, including in the Debian NEW queue.
> 
> The binaries of rust-zstd that are in Debian were clearly not built on the
> autobuilders, and all other architectures besides amd64 are unable to build
> this package.
> 
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#922396: [Pkg-mozext-maintainers] Bug#922396: Updated package / patch and status information

[Ximin Luo]

I was the last person to upload noscript in 2018.

The reason why I haven't updated it since 2018 is because I've moved onto using 
umatrix personally and also maintaining it in debian.

umatrix gives you more fine-grained permissions including cookies, XHR, etc, so 
you don't need to install a 2nd extension to manage your cookies. It's written 
by the same author as ublock-origin.

>From what I remember noscript maintenance in terms of Debian packaging was 
>also a pain. umatrix maintenance is pretty simple.

I encourage everyone to move to umatrix and drop noscript.

Best,
Ximin

Helge Kreutzmann:
> tags 922396 + patch
> thanks
> 
> Hello,
> this is a central package, so I had a look at it. Unfortunately,
> README.source is outdated, the following recipe works:
> 
>  * apt-get source
>  * cd mozilla-noscript-10.1.9.6
>  * uscan
>  * create appropriate directory, cd into it and tar xJvf 
> ../mozilla-noscript_….orig.tar.xz
>  * copy over debian directory from 10.1.9.6
>  * export QUILT_PATCHES=debian/patches
>  * quilt new 0002b-remove-websites-from-default-white-list.patch
>  * quilt edit common/Policy.js
>  * quilt refresh
>  * comment out 0002 (original) patch in debian/patches/series
>  * dch -i und Changelog-Eintrag vorgenommen (Note: version number)
>  * debuild
> 
> for version 11.0.34 the (new/updated) patch is as follows:
> Author: Ximin Luo , Helge Kreutzmann 
> 
> Description: remove websites from default white list
>  Original patch by
>  From: arno 
>  Date: Tue, 25 Aug 2009 23:32:30 +0200
>  Subject: remove websites from default white list
> 
> Index: mozilla-noscript-11.0.34/common/Policy.js
> ===
> --- mozilla-noscript-11.0.34.orig/common/Policy.js
> +++ mozilla-noscript-11.0.34/common/Policy.js
> @@ -294,21 +294,7 @@ var {Permissions, Policy, Sites} = (() =
>function defaultOptions() {
>  return {
>sites:{
> -trusted: `addons.mozilla.org
> -  afx.ms ajax.aspnetcdn.com
> -  ajax.googleapis.com bootstrapcdn.com
> -  code.jquery.com firstdata.com firstdata.lv gfx.ms
> -  google.com googlevideo.com gstatic.com
> -  hotmail.com live.com live.net
> -  maps.googleapis.com mozilla.net
> -  netflix.com nflxext.com nflximg.com nflxvideo.net
> -  noscript.net
> -  outlook.com passport.com passport.net passportimages.com
> -  paypal.com paypalobjects.com
> -  securecode.com securesuite.net sfx.ms tinymce.cachefly.net
> -  wlxrs.com
> -  yahoo.com yahooapis.com
> -  yimg.com youtube.com 
> ytimg.com`.split(/\s+/).map(Sites.secureDomainKey),
> +trusted: ``.split(/\s+/).map(Sites.secureDomainKey),
>  untrusted: [],
>  custom: {},
>},
> 
> Now I have to check if this updated version works …
> 
> Btw., version 10.1.9.6. still seems to work in firefox 68.10.0esr-1.
> 
> Greetings
> 
>   Helge
> 
> P.S. If someone takes over mozilla-noscript, README.source should be 
>  updated as well
> 
> 
> ___
> Pkg-mozext-maintainers mailing list
> pkg-mozext-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-mozext-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#967224: closing 967224

[Ximin Luo]

close 967224 3.5.20-1
thanks

In fact I'm not sure why this bug was even filed, there is no python dependency.

Unless you mean transitively through mozilla-devscripts, which you fixed a 
short while ago. But then the bug report should only have been on that package, 
since it takes a single fix to fix it.

Bug#967230: closing 967230

[Ximin Luo]

close 967230 1.4.0+dfsg-1
thanks

In fact I'm not sure why this bug was even filed, there is no python dependency.

Unless you mean transitively through mozilla-devscripts, which you fixed a 
short while ago. But then the bug report should only have been on that package, 
since it takes a single fix to fix it.

Bug#963094: wine-development: FTBFS with libvulkan1 1.2.141.0-1

[Ximin Luo]

Package: wine-development
Version: 5.5-4
Followup-For: Bug #963094
Control: tags -1 + upstream patch

Looks like these patches fix the issue:

https://github.com/wine-mirror/wine/commit/4465ecfe0e3fa9fa14518abd1907193adb154957.patch
https://github.com/wine-mirror/wine/commit/727441cc24d54d9a6623d523788d4011c526ba94.patch

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

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

Versions of packages wine-development depends on:
ii  wine32-development  5.5-4
ii  wine64-development  5.5-4

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox0.74-3-1
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks0.0+20200412-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.2-2.2
ii  libc62.30-8
ii  libfaudio0   20.04-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s110.1.0-3
ii  libglib2.0-0 2.64.3-1
ii  libgphoto2-6 2.5.24-1
ii  libgphoto2-port122.5.24-1
ii  libgstreamer-plugins-base1.0-0   1.16.2-4
ii  libgstreamer1.0-01.16.2-2
ii  liblcms2-2   2.9-4+b1
ii  libldap-2.4-22.4.50+dfsg-1
ii  libmpg123-0  1.25.13-1
ii  libncurses6  6.2-1
ii  libopenal1   1:1.19.1-1+b1
ii  libpcap0.8   1.9.1-4
ii  libpulse013.0-5
ii  libtinfo66.2-1
ii  libudev1 245.6-1
ii  libunwind8   1.2.1-9
ii  libvkd3d11.1-4
ii  libx11-6 2:1.6.9-2+b1
ii  libxext6 2:1.3.3-1+b2
ii  libxml2  2.9.10+dfsg-5+b1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libwine-development recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 5.0-4
ii  gstreamer1.0-plugins-good  1.16.2-3
ii  libasound2-plugins 1.2.2-1
ii  libgl1-mesa-dri20.1.1-1

Versions of packages libwine-development suggests:
pn  cups-bsd   
ii  gstreamer1.0-libav 1.16.2-2
pn  gstreamer1.0-plugins-bad   
ii  gstreamer1.0-plugins-ugly  1.16.2-2+b1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

wine32-development recommends no packages.

Versions of packages wine32-development suggests:
pn  wine32-development-preloader  

Versions of packages wine64-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

Versions of packages wine64-development recommends:
ii  wine32-development  5.5-4

Versions of packages wine64-development suggests:
pn  wine64-development-preloader  

Versions of packages wine-development is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   5.0-4

-- no debconf information

Bug#963094: wine-development: FTBFS with libvulkan1 1.2.141.0-1

[Ximin Luo]

Package: wine-development
Version: 5.5-4
Severity: serious
Justification: FTBFS

Dear Maintainer,

Sadly, the latest update to "support vulkan 1.2" does not work with the latest
version, uploaded 1 day after the fix.

[..]
cd dlls/winevulkan && ./make_vulkan
Traceback (most recent call last):
  File "./make_vulkan", line 3081, in 
main()
  File "./make_vulkan", line 3059, in main
registry = VkRegistry(vk_xml)
  File "./make_vulkan", line 2581, in __init__
self._parse_types(root)
  File "./make_vulkan", line 2908, in _parse_types
_type = t.find("type").text
AttributeError: 'NoneType' object has no attribute 'text'
make[1]: *** [debian/rules:134: override_dh_auto_configure] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:122: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

X

-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

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

Versions of packages wine-development depends on:
ii  wine32-development  5.5-4
ii  wine64-development  5.5-4

wine-development recommends no packages.

Versions of packages wine-development suggests:
ii  dosbox0.74-3-1
pn  exe-thumbnailer | kio-extras  
pn  playonlinux   
pn  q4wine
pn  winbind   
pn  wine-binfmt   
ii  winetricks0.0+20200412-1

Versions of packages libwine-development depends on:
ii  libasound2   1.2.2-2.2
ii  libc62.30-8
ii  libfaudio0   20.04-2
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.1-2
ii  libgcc-s110.1.0-3
ii  libglib2.0-0 2.64.3-1
ii  libgphoto2-6 2.5.24-1
ii  libgphoto2-port122.5.24-1
ii  libgstreamer-plugins-base1.0-0   1.16.2-4
ii  libgstreamer1.0-01.16.2-2
ii  liblcms2-2   2.9-4+b1
ii  libldap-2.4-22.4.50+dfsg-1
ii  libmpg123-0  1.25.13-1
ii  libncurses6  6.2-1
ii  libopenal1   1:1.19.1-1+b1
ii  libpcap0.8   1.9.1-4
ii  libpulse013.0-5
ii  libtinfo66.2-1
ii  libudev1 245.6-1
ii  libunwind8   1.2.1-9
ii  libvkd3d11.1-4
ii  libx11-6 2:1.6.9-2+b1
ii  libxext6 2:1.3.3-1+b2
ii  libxml2  2.9.10+dfsg-5+b1
ii  ocl-icd-libopencl1 [libopencl1]  2.2.12-4
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages libwine-development recommends:
ii  fonts-liberation   1:1.07.4-11
ii  fonts-wine 5.0-4
ii  gstreamer1.0-plugins-good  1.16.2-3
ii  libasound2-plugins 1.2.2-1
ii  libgl1-mesa-dri20.1.1-1

Versions of packages libwine-development suggests:
pn  cups-bsd   
ii  gstreamer1.0-libav 1.16.2-2
pn  gstreamer1.0-plugins-bad   
ii  gstreamer1.0-plugins-ugly  1.16.2-2+b1
ii  ttf-mscorefonts-installer  3.8

Versions of packages wine32-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

wine32-development recommends no packages.

Versions of packages wine32-development suggests:
pn  wine32-development-preloader  

Versions of packages wine64-development depends on:
ii  libc62.30-8
ii  libwine-development  5.5-4

Versions of packages wine64-development recommends:
ii  wine32-development  5.5-4

Versions of packages wine64-development suggests:
pn  wine64-development-preloader  

Versions of packages wine-development is related to:
pn  dxvk 
pn  dxvk-wine32-development  
pn  dxvk-wine64-development  
ii  fonts-wine   5.0-4

-- no debconf information

Bug#958547: [Pkg-rust-maintainers] Bug#958547: closing 958547 ( rust-curl-sys autopkgtest failure, looks for crate in the wrong place. )

[Ximin Luo]

peter green:
> On 23/04/2020 17:07, Ximin Luo wrote:
>> close 958547
>> thanks
>>
>> See 
>> https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-January/009512.html
>>
>> Just be patient and wait a few days, the issue usually resolves itself.
> 
> I have read that thread and I am aware of the issue that testing migration 
> tests sometimes install the wrong version of the package and that when a 
> version mismatch happens it results in errors that look at first glance 
> similar to this one. In the case of such version mismatch errors I wait a bit 
> and if waiting doesn't seem to be helping follow up with the release team 
> and/or debci team.
> 
> But I am pretty sure that is not what is going on here for a couple of 
> reasons.
> 
> 1. I checked the test log and there was no version mismatch to be seen.
> 2. The failure is also happening in plain unstable tests. My understanding is 
> that the version mismatch issue is a quirk of the testing migration tests.
> 
> It seems that the issue is that the upstream version is "0.4.30+curl-7.69.1", 
> the Debian packaging seems to strip this down to 0.4.30 for the package 
> versions and for the name of the directory in /usr/share/ but the autpkgtest 
> uses the full version when looking for the source to test.
> 

You are right, I've fixed this in debcargo 
293fb88f2156d0db6262349aa4b1c4d3a3b1186a. Affected packages will be fixed after 
the next release & ./update.

> Looking at previous test logs I also have a nasty feeling that if/when this 
> is fixed the tests will fail for other reasons.

Why "nasty"? This, and 95% of recent similar bugs you and other people have 
filed, affects literally 0 users[*] and I guarantee you nobody else in the 
world cares about them existing. There are far worse things like the 
coronavirus to be worried about. It's not a big deal, at some point they will 
all be fixed, play a video game, read a book, play the guitar in the meantime, 
or something.

X

[*] obviously one can make the argument that indirectly users care, because 
they slow the migration progress to Debian Testing, but *we've set up these 
processes ourselves* so that is a circular argument. The fact that these 
processes are catching issues that no *users* care about is a bug about the 
process.

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#958547: closing 958547

[Ximin Luo]

close 958547 
thanks

See 
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2020-January/009512.html

Just be patient and wait a few days, the issue usually resolves itself.

Bug#955638: [Pkg-rust-maintainers] Bug#955638: Bug#955638: cargo: please package recent version

[Ximin Luo]

Sorry, I had a brain-fart here.

We have 2 cargo packages, 1 (rust-cargo) that is part of our rust crate 
packaging ecosystem with its web of dependencies, and 1 (cargo) that explicitly 
embeds its dependencies to avoid this type of issue.

The latter is what you want, and I've just uploaded it too, so there should be 
no need to wait for the below packages. I got confused earlier because we use 
rust-cargo to update cargo, and I temporarily forgot my own instructions on 
updating the packaging.

So Thunderbird should now be unblocked on this front.

Best,
Ximin

Ximin Luo:
> Hi Carsten, cargo 0.43.1 has been packaged and source-only uploaded, however 
> for it to be built, it will have to wait for the following packages to clear 
> NEW:
> 
> rust-bitmaps_2.1.0-1_amd64.ftp-master.upload
> rust-im-rc_14.3.0-1_amd64.ftp-master.upload
> rust-sized-chunks_0.6.1-1_amd64.ftp-master.upload
> 
> I will ping them to hopefully get a bit more priority.
> 
> Best,
> Ximin
> 
> Carsten Schoenert:
>> Hello Ximin,
>>
>> Am 04.04.20 um 02:17 schrieb Ximin Luo:
>>> Hi Carsten, it might be a couple of weeks until we get this done.
>>> Have you tried just deleting the version constraint and using the
>>> existing version in Debian sid?
>> I've tried to figure out the right place there this version check is
>> happen. In most cases this is file ./old-configure.in within the
>> Thunderbird sources. But I did have no luck on this until now. I will
>> look further into this part this weekend I guess, mostly the version
>> checks from the Firefox environment are to strict for Thunderbird, yes.
>> Most of the parts from the Firefox source are not built for Thunderbird
>> but the configure script is checking this.
>>
>> In the long term this is always just a workaround which, if I do this, I
>> need to proof deeply before uploading new packages even to experimental.
>> So if you ever find time to have a look into newer cargo versions please
>> keep an eye on this.
>>
>> It's currently really frustrating that I'm unable to build a recent
>> Thunderbird Beta version due every time new version dependencies around
>> Rust are popping up. This is not your fault, but shows me how complex
>> and fragile the Rust ecosystem currently is.
>>
>> The built is just the first problem I need to solve, Mozilla has again
>> changed some previously internally parts in Thunderbird and I need to
>> adopt the Debian built to this again.
>>
> 
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#955764: closing 955764

[Ximin Luo]

close 955764 
version 0.43.1-1
thanks

Bug#955638: [Pkg-rust-maintainers] Bug#955638: cargo: please package recent version

[Ximin Luo]

Hi Carsten, cargo 0.43.1 has been packaged and source-only uploaded, however 
for it to be built, it will have to wait for the following packages to clear 
NEW:

rust-bitmaps_2.1.0-1_amd64.ftp-master.upload
rust-im-rc_14.3.0-1_amd64.ftp-master.upload
rust-sized-chunks_0.6.1-1_amd64.ftp-master.upload

I will ping them to hopefully get a bit more priority.

Best,
Ximin

Carsten Schoenert:
> Hello Ximin,
> 
> Am 04.04.20 um 02:17 schrieb Ximin Luo:
>> Hi Carsten, it might be a couple of weeks until we get this done.
>> Have you tried just deleting the version constraint and using the
>> existing version in Debian sid?
> I've tried to figure out the right place there this version check is
> happen. In most cases this is file ./old-configure.in within the
> Thunderbird sources. But I did have no luck on this until now. I will
> look further into this part this weekend I guess, mostly the version
> checks from the Firefox environment are to strict for Thunderbird, yes.
> Most of the parts from the Firefox source are not built for Thunderbird
> but the configure script is checking this.
> 
> In the long term this is always just a workaround which, if I do this, I
> need to proof deeply before uploading new packages even to experimental.
> So if you ever find time to have a look into newer cargo versions please
> keep an eye on this.
> 
> It's currently really frustrating that I'm unable to build a recent
> Thunderbird Beta version due every time new version dependencies around
> Rust are popping up. This is not your fault, but shows me how complex
> and fragile the Rust ecosystem currently is.
> 
> The built is just the first problem I need to solve, Mozilla has again
> changed some previously internally parts in Thunderbird and I need to
> adopt the Debian built to this again.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#956266: closing 956266

[Ximin Luo]

close 956266 1.42.0+dfsg1-1
thanks

Bug#947710: closing 947710

[Ximin Luo]

close 947710 
thanks

Bug#948763: z3: cannot be built on buildds

[Ximin Luo]

Helmut Grohne:
> Control: retitle -1 cannot migrate to testing
> 
> Hi Fabian,
> 
> On Mon, Jan 13, 2020 at 04:27:15PM +0100, Fabian Wolff wrote:
>> On Mon, 13 Jan 2020 06:21:56 +0100 Helmut Grohne  wrote:
>>> Source: z3
>>> Version: 4.8.7-3
>>> Severity: serious
>>>
>>> z3 cannot be built on buildds, because its Build-Depends cannot be
>>> satisfied on buildds. Failing to build on buildds is a serious problem.
>>
>> It builds now on all but three architectures, including, in particular, all
>> release architectures.
> 
> Oh, I'm wrong here. It did build. But the dependency issue prevents it
> from migrating to testing. So you want to fix that anyway.
> 

Why is testing migration prevented, when the builds completed fine? Why is 
there a "dependency issue" when clearly the dependencies were satisfied?

>> Thanks for your suggestions, but I'm not very familiar with how Multi-Arch
>> annotations should be used; I just accepted a patch to make the z3 package
>> more cross-build friendly (see #948109).
> 
> That bug is not at all about cross building nor multi-arch. It seems you
> (and your contributors) are conflating multiple issues. Things become
> much easier once you start separating them.
> 
>> Can you give me a patch where you set the build dependency annotations in a
>> sound way that also works for cross-building? Otherwise, I would have to
>> simply remove all annotations again in order to fix this bug (but clearly,
>> that would not be the most desirable solution).
> 
> No. The expectation that every package can be cross built is misguided.
> z3 uses java stuff, which is an unsolved problem. Therefore you cannot
> make z3's dependencies cross-satisfiable at this time. If you want to do
> so anyway, be prepared to invest quite some work.
> 
> For this reason, reverting the annotations is not the worst of options.
> 

The sbuild command-line I gave near the end of #948109 works perfectly fine to 
cross-compile java bindings and the files have the correct binary format (for 
the foreign architecture).

Granted, I didn't actually run the bindings, but I don't see why they wouldn't 
work.

I can understand that, based on what your expectations are of the current tool 
chain you believe it shouldn't work, but *I actually tried it empirically and 
it works*.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#948763: z3: cannot be built on buildds

[Ximin Luo]

Fabian Wolff:
> On Mon, 13 Jan 2020 06:21:56 +0100 Helmut Grohne  wrote:
>> Source: z3
>> Version: 4.8.7-3
>> Severity: serious
>>
>> z3 cannot be built on buildds, because its Build-Depends cannot be
>> satisfied on buildds. Failing to build on buildds is a serious problem.
> 
> It builds now on all but three architectures, including, in particular, all
> release architectures.
> 
>> [...]
> 
> Thanks for your suggestions, but I'm not very familiar with how Multi-Arch
> annotations should be used; I just accepted a patch to make the z3 package
> more cross-build friendly (see #948109).
> 

I tested this myself and also it's now working on buildds, so I don't see what 
the problem is here. Can we just close this bug report and mark it as `notfound 
-1 $version`?

FWIW, when I tried things locally with sbuild, changing dh-python:all to simply 
dh-python whilst retaining the other annotations *did not work*, regardless of 
how it's "supposed" to work. That is why I added the extra :all.

> Can you give me a patch where you set the build dependency annotations in a
> sound way that also works for cross-building? Otherwise, I would have to
> simply remove all annotations again in order to fix this bug (but clearly,
> that would not be the most desirable solution).
> 
> I would also be happy to use the nojava build profile that you suggested,
> but again, I'm not familiar with this technique, and from what I've heard,
> there are still some problems e. g. with using "dh-sequence-javahelper
>  ". But if somebody gave me a patch, I'd be happy to apply it.
> 
> Thanks for your help!
> Fabian
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#948647: [Pkg-rust-maintainers] Bug#948647: rust-backtrace depends on non-existent librust-compiler-builtins

[Ximin Luo]

Steve Langasek:
> [..]
> 
> There is no rust-compiler-builtins package in the Debian archive or in the
> NEW queue.

It's in NEW.

We're aware of all of these issues you're filing bug reports for, and in fact 
there are many more than the ones you're filing for. These reports are not 
actually helpful, they just increase the amount of work we have to do fixing 
the packages.

Therefore, I'm going to close all of these bugs now to save time. All of them 
are getting fixed as part of the normal migration process.

They are also redundant, britney is already preventing these packages from 
migration, adding a "serious" bug therefore achieves nothing except extra 
paperwork for packagers in closing bug reports.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Bernhard R. Link:
> [..]
> 
> As the comment describes, accepting arbitrary long control data would
> open all kind of security issues and require quite some hard to properly
> test code. Most of the attacks enabled by having longer control chunks
> might be able to mitigated some way, but that would require all kind of
> different logic that can then have some new bugs.
> 

I don't see why this is the case, but nevertheless this is actually secondary 
to the below point:

> So allowing arbitrary absurdly long control data is not something I want
> to support.
> 

dpkg and all other debian tools support it right now. It is only reprepro with 
this artifical constraint, which makes it not work for packages that are 
processable by dpkg and other debian tools.

Are you suggesting that dpkg and other tools have a concrete security problem?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Control: reassign -1 reprepro 5.3.0-1
Control: retitle -1 reprepro imposes arbitrary limits on control files that are 
successfully parsed by other debian tools

Ximin Luo:
> [..]
> I'll take a look at reprepro in the next 2-3 weeks; arbitrary limits like 
> 256K should be pretty easy to fix (have you tried simply configuring the BDB 
> limits?).

The relevant code in reprepro is indexfile.c

line 66:f->size = 256*1024;

Change this to something like 4MB would be a short hacky fix to the current 
issue, I don't think even the extreme rust examples have a 4MB control field 
yet.

A long-term fix would be to fix this:

line 151-166:
if (f->size - f->ofs <= 2048) {
/* Adding code to enlarge the buffer in this case
 * is risky as hard to test properly.
 *
 * Also it is almost certainly caused by some
 * mis-representation of the file or perhaps
 * some attack. Requesting all existing memory in
 * those cases does not sound very useful. */

fprintf(stderr,
"Error parsing %s line %d: Ridiculous long (>= 256K) control chunk!\n",
f->filename,
f->startlinenumber);
f->failed = true;
return RET_ERROR;
}

One reasonable option would be to rip out this code and use whatever dpkg 
itself is using to parse the fields.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#946886: [Pkg-rust-maintainers] Bug#946886: rustc: FTBFS on mips/mipsel with test failures in sync::atomic::Atomic*

[Ximin Luo]

Hi YunQiang,

Debian rustc with LLVM 9 is ready to go in git 
https://salsa.debian.org/rust-team/rust/

Backporting that patch to Debian LLVM is underway in #946874.

X

YunQiang Su:
> Raphaël Hertzog  于2019年12月17日周二 下午5:39写道：
>>
>> Source: rustc
>> Version: 1.39.0+dfsg1-3
>> Severity: serious
>> Justification: FTBFS
>>
>> rustc is not migrating to testing (and thus holding up migration of the
>> latest thunderbird) because it fails to build on mipsel and mips64el with
>> too many test failures:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.39.0%2Bdfsg1-3=1575833439=0
> 
> It seems due to
>https://reviews.llvm.org/rGd7357c52a40a136f25c1cf5ae31a699d51885e49
> and llvm-9 seems containing this patch... (backported?
> I am trying to build rustc with llvm-9. Wish it workable.
> 
> Do we have any plan to migrate to llvm-9?
> 
>>  Debian rustc test report 
>> Specific test failures:
>> command did not execute successfully: 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/tidy"
>>  "/<>/src" "/usr/bin/cargo" "--verbose"
>> test [ui] ui/statics/static-function-pointer.rs ... FAILED
>> command did not execute successfully: 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
>>  "--compile-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
>> "--run-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
>>  "--rustc-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
>> "--src-base" "/<>/src/test/ui" "--build-base" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/test/ui" 
>> "--stage-id" "stage2-mips64el-unknown-linux-gnuabi64" "--mode" "ui" 
>> "--target" "mips64el-unknown-linux-gnuabi64" "--host" 
>> "mips64el-unknown-linux-gnuabi64" "--llvm-filecheck" 
>> "/usr/lib/llvm-8/bin/FileCheck" "--linker" "mips64el-linux-gnuabi64-gcc" 
>> "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
>> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" 
>> "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" 
>> "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" 
>> "--android-cross-path" ""
>> test [debuginfo-gdb+lldb] debuginfo/lexical-scope-in-unconditional-loop.rs 
>> ... FAILED
>> test [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs ... FAILED
>> command did not execute successfully: 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
>>  "--compile-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
>> "--run-lib-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
>>  "--rustc-path" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
>> "--src-base" "/<>/src/test/debuginfo" "--build-base" 
>> "/<>/build/mips64el-unknown-linux-gnuabi64/test/debuginfo" 
>> "--stage-id" "stage2-mips64el-unknown-linux-gnuabi64" "--mode" 
>> "debuginfo-gdb+lldb" "--target" "mips64el-unknown-linux-gnuabi64" "--host" 
>> "mips64el-unknown-linux-gnuabi64" "--llvm-filecheck" 
>> "/usr/lib/llvm-8/bin/FileCheck" "--linker" "mips64el-linux-gnuabi64-gcc" 
>> "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
>> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
>> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" 
>> "--system-llvm" "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" 
>> "--llvm-cxxflags" "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" 
>> "--android-cross-path" ""
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 60) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 62) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 60) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 62) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 49) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 60) ... FAILED
>> test num/mod.rs - sync::atomic::AtomicI64::fetch_min 

Bug#946886: [Pkg-rust-maintainers] Bug#946886: rustc: FTBFS on mips/mipsel with test failures in sync::atomic::Atomic*

[Ximin Luo]

Control: block -1 by 946874

see also https://github.com/rust-lang/rust/issues/67167

Raphaël Hertzog:
> Source: rustc
> Version: 1.39.0+dfsg1-3
> Severity: serious
> Justification: FTBFS
> 
> rustc is not migrating to testing (and thus holding up migration of the
> latest thunderbird) because it fails to build on mipsel and mips64el with
> too many test failures:
> 
> https://buildd.debian.org/status/fetch.php?pkg=rustc=mips64el=1.39.0%2Bdfsg1-3=1575833439=0
>  Debian rustc test report 
> Specific test failures:
> command did not execute successfully: 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/tidy"
>  "/<>/src" "/usr/bin/cargo" "--verbose"
> test [ui] ui/statics/static-function-pointer.rs ... FAILED
> command did not execute successfully: 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
>  "--compile-lib-path" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
> "--run-lib-path" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
>  "--rustc-path" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
> "--src-base" "/<>/src/test/ui" "--build-base" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/test/ui" "--stage-id" 
> "stage2-mips64el-unknown-linux-gnuabi64" "--mode" "ui" "--target" 
> "mips64el-unknown-linux-gnuabi64" "--host" "mips64el-unknown-linux-gnuabi64" 
> "--llvm-filecheck" "/usr/lib/llvm-8/bin/FileCheck" "--linker" 
> "mips64el-linux-gnuabi64-gcc" "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 
> -Zunstable-options  
> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" "--system-llvm" 
> "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" 
> "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" 
> "--android-cross-path" ""
> test [debuginfo-gdb+lldb] debuginfo/lexical-scope-in-unconditional-loop.rs 
> ... FAILED
> test [debuginfo-gdb+lldb] debuginfo/pretty-uninitialized-vec.rs ... FAILED
> command did not execute successfully: 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage0-tools-bin/compiletest"
>  "--compile-lib-path" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib" 
> "--run-lib-path" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/lib/rustlib/mips64el-unknown-linux-gnuabi64/lib"
>  "--rustc-path" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/stage2/bin/rustc" 
> "--src-base" "/<>/src/test/debuginfo" "--build-base" 
> "/<>/build/mips64el-unknown-linux-gnuabi64/test/debuginfo" 
> "--stage-id" "stage2-mips64el-unknown-linux-gnuabi64" "--mode" 
> "debuginfo-gdb+lldb" "--target" "mips64el-unknown-linux-gnuabi64" "--host" 
> "mips64el-unknown-linux-gnuabi64" "--llvm-filecheck" 
> "/usr/lib/llvm-8/bin/FileCheck" "--linker" "mips64el-linux-gnuabi64-gcc" 
> "--host-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>  "--target-rustcflags" "-Crpath -O -Cdebuginfo=0 -Zunstable-options  
> -Lnative=/<>/build/mips64el-unknown-linux-gnuabi64/native/rust-test-helpers"
>  "--docck-python" "/usr/bin/python2.7" "--lldb-python" "/usr/bin/python2.7" 
> "--gdb" "/usr/bin/gdb" "--verbose" "--llvm-version" "8.0.1\n" "--system-llvm" 
> "--cc" "" "--cxx" "" "--cflags" "" "--llvm-components" "" "--llvm-cxxflags" 
> "" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" 
> "--android-cross-path" ""
> test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI16::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI16::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI32::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI32::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI64::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI64::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI64::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI8::fetch_max (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI8::fetch_max (line 60) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI8::fetch_min (line 49) ... FAILED
> test num/mod.rs - sync::atomic::AtomicI8::fetch_min (line 62) ... FAILED
> test num/mod.rs - sync::atomic::AtomicIsize::fetch_max (line 

Bug#946415: rust-cargo Build-Depends on librust-crates-io-0.25+default-dev which doesn't exist

[Ximin Luo]

Hi,

This type of bug is a natural artifact of the way rust crates are structured 
and updated, and the Rust team is continually aware of these types of bugs. 
There is no need to file these types of bugs for packages in unstable as the 
testing migration script will prevent migrations anyway, rendering a RC bug 
report unbeneficial and contributing to more paperwork for the packaging team.

Best,
Ximin

Paul Gevers:
> Source: rust-cargo
> Version: 0.37.0-1
> Severity: serious
> Tags: ftbfs sid bullseye
> Justification: ftbfs
> 
> Dear maintainers,
> 
> Your package Build-Depends on librust-crates-io-0.25+default-dev but that
> package doesn't exist.
> 
> Paul
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-debug')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#945542: [Pkg-rust-maintainers] Bug#945542: debcargo -- Randomly adds and removes binary packages

[Ximin Luo]

Control: severity -1 normal
Control: tags -1 + wontfix unreproducible

Bastian Blank:
> Hi Ximin
> 
> On Tue, Nov 26, 2019 at 10:25:51PM +0000, Ximin Luo wrote:
>> Control: severity -1 normal
> 
> Please stop fiddling with severities.
> 

The maintainer of a package decides the severities and whether things are bugs 
or not. Neither have you provided a justification for "serious", it is not 
breaking anything.

>> The more precise reason, as I have explained many times already, is because 
>> the cargo package manager supports crates having optional dependencies. It 
>> is not feasible to automatically merge optional-dependency-sets together 
>> because it results in dependency loops that would not otherwise exist. It is 
>> not economically feasible to manually merge these sets together either, 
>> because it is boring and time-consuming work, error-prone (hard to manually 
>> tell if you did or did not introduce a cycle) and of questionable benefit.
> 
> Yes, I got that.  And it seems cargo does not support recursive
> dependencies.
> 
> However Debian does not use cargo, it uses dpkg and apt.  apt and dpkg
> actually support recursive dependencies.  Due to some downsides in
> regards of the handling of maintainer scripts they are discuraged.  But
> as long as you don't have any of those, which all those packages don't
> have, that's not much of a problem.
> 

Manual cost, nobody is going to want to do this work. Do you want to do this 
work?

>> I do not see any users complaining about this behaviour of our automatic 
>> tooling. We would be happy to work towards a patch on any Debian 
>> infrastructure to make these processes smoother. There is no reason why 
>> adding and removing empty metadata-only packages should require manual 
>> oversight, and if one is (and one should be) interested in automating the 
>> amount of manual work involved in maintaining Debian infrastructure, this is 
>> one obvious tedious task to automate away.
> 
> Sylvestre as rust team member asked the ftp team, which is responsible
> for the archive content, to change their handling of binary-NEW.  So you
> expect the ftp team to do the work you don't want to do.
> 
> This bug is about members of the ftp team asking you to change your
> solution to that problem.  Re-iterating why it's not possible does not
> help.
> 
>> We are all volunteers, there is no "job security" here, why are we manually 
>> reviewing empty packages and we are we trying to conserve a process that 
>> involves manually reviewing empty packages?
> 
> Because the ftp team is responsible for the content of the archive,
> including package names etc.
> 

Your proposed solution involves us doing more manual work, our suggested 
solution involves you doing less manual work. So, no thanks.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#945542: debcargo -- Randomly adds and removes binary packages

[Ximin Luo]

Control: severity -1 normal

Bastian Blank:
> Package: debcargo
> Severity: serious
> 
> Hi Sylvestre
> 
> I'm filling this as bug now.  Please discuss this issue there.
> 
> I'm setting it to serious as several ftp team members told you not to do
> that.
> 
> On Thu, Oct 17, 2019 at 06:57:33PM +0200, Sylvestre Ledru wrote:
>> Le 17/10/2019 à 18:52, Ansgar a écrit :
>>> Sylvestre Ledru writes:
 Moreover, the creation (or deletion) of new packages is automatically
 managed by debcargo (our tooling).
>>> Why do you need to automatically create/remove binary packages?
>> Because it is the way it is managed in Rust packages. This is done to
>> express what
>> the package provides. For now, it has been working very well.
>>
>> But this isn't an issue specific to Rust. Having to go through NEW when it
>> is the same
>> source isn't a good use of our time and introduces some unnecessary latency
>> and frustration.
>>

The more precise reason, as I have explained many times already, is because the 
cargo package manager supports crates having optional dependencies. It is not 
feasible to automatically merge optional-dependency-sets together because it 
results in dependency loops that would not otherwise exist. It is not 
economically feasible to manually merge these sets together either, because it 
is boring and time-consuming work, error-prone (hard to manually tell if you 
did or did not introduce a cycle) and of questionable benefit.

I do not see any users complaining about this behaviour of our automatic 
tooling. We would be happy to work towards a patch on any Debian infrastructure 
to make these processes smoother. There is no reason why adding and removing 
empty metadata-only packages should require manual oversight, and if one is 
(and one should be) interested in automating the amount of manual work involved 
in maintaining Debian infrastructure, this is one obvious tedious task to 
automate away.

We are all volunteers, there is no "job security" here, why are we manually 
reviewing empty packages and we are we trying to conserve a process that 
involves manually reviewing empty packages?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#944675: Bug#944838: xorg: after recent upgrade on two different machines, X no longer responds to kbd or mouse input

[Ximin Luo]

Control: affects -1 xorg
Control: severity -1 grave
Severity: grave
Justification: renders package unusable

Thanks, I also figured this out myself separately by running `libinput 
debug-events`, hopefully this helps someone else stumbling upon this strange 
behaviour in the future.

However I am still confused to on how I managed to fix it. On one machine (the 
AMDGPU one) `libinput debug-events --verbose` would complain about certain 
devices not being initialised by udev, including the keyboard device. Upgrading 
udev from version 243-5 to 243-7 and reloading udev by running `udevadm control 
--reload-rules && udevadm trigger` and then restarting lightdm worked. Perhaps 
this bug is related to #944586?

Then again, on the other machine (Intel graphics) it was sufficient to simply 
run `libinput debug-events --device $device`.

Oh and another thing for people wanting to play around with this, when you run 
`systemctl disable lightdm` and then fix the problem and then run `systemctl 
enable lightdm` the latter does not work for some stupid reason, even though 
the former command worked. You have to run `dpkg-reconfigure lightdm` to make 
it work again.

X

Sven Joachim:
> Control: reassign -1 udev 243-5
> Control: forcemerge 944675 -1
> 
> On 2019-11-16 03:45 +, Ximin Luo wrote:
> 
>> Package: xorg
>> Version: 1:7.7+20
>> Severity: important
>>
>> Dear Maintainer,
>>
>> After upgrading a bunch of packages on two very different machines, X no 
>> longer
>> responds to keyboard or mouse input.
>>
>> I am using lightdm with XFCE, the problem is present both in the lightdm 
>> login
>> menu and also in XFCE when using `startx` directly.
>>
>> Nothing obvious is in the kernel or system logs or Xorg.0.log.
> 
> That seems to be bug #944675 in udev.
> 
> Cheers,
>Sven
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

intrigeri:
> Hi,
> 
> Ximin Luo:
>> Who is using reprepro to archive Debian Rust packages? That's the
>> first time I've heard of this.
> 
> I'm happy to document one specific example, in the hope that it helps
> this discussion adopt a user-centric approach :)
> 

Users do not care about "Provides" lines (as long as everything else works), 
but volunteer workers do care about not having to perform 20x the amount of 
manual labour in order to achieve the same end result.

More generally I think we should stop throwing around the religious term 
"user-centric" to rhetorically virtue-signal during debates, it cheapens the 
meaning of the phrase and does not contribute much to the discussion.

> Tails is taking snapshots of the Debian archive 4 times a day, [..]
> This includes Rust packages and therefore, we're affected by this bug.
> 

I'll take a look at reprepro in the next 2-3 weeks; arbitrary limits like 256K 
should be pretty easy to fix (have you tried simply configuring the BDB 
limits?). In the meantime we can also easily temporarily patch away the 
features for web-sys right now, since it looks like nothing uses them yet. 
(`aptitude search '~Dlibrust-web-sys'` shows no other packages.)

A systematic change for debcargo to avoid this approach entirely is not 
feasible however, from a technical or worker-centric perspective.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Raphael Hertzog:
> [..]
> 
> It might not be as flexible as the current approach as it might require
> rebuilds when the package providing the interface changes, but that's
> quite usual in Debian.
> 

This isn't suitable for Rust, there will be too many rebuilds needed (basically 
half the ecosystem for every change, which happens 4-5 times a month) and I and 
I suspect everyone else will stop maintaining Rust packages if we are forced to 
do this.

> [..]
> 
> But reprepro is in wide use and your new package is the first one to
> trigger the limit. You can't just ignore the reality, you have to cope
> with the fact that we have reprepro users and that we can't deploy
> a package with 270K-long Provides header currently.
> 

Who is using reprepro to archive Debian Rust packages? That's the first time 
I've heard of this. I suspect this is a small number (its popcon [1] is less 
than that of rustc itself), and that they will be perfectly happy to upgrade to 
a fixed version of reprepro.

[1] https://qa.debian.org/developer.php?login=brl...@debian.org#reprepro

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Ansgar:
> Ximin Luo writes:
>> Raphael Hertzog:
>>> Don't abuse the "Provides" field when you have such a volume of
>>> interfaces to document.
>>
>> Can you please explain why 256 KB provides field is "abuse"?
> 
> The Packages index is a shared resource by all packages and every Debian
> user has to download and process the full packages index; adding
> excessive amounts of data should therefore be avoided.  (The 256 KB
> added to the Packages index are larger than the entire source
> (compressed) source package...)
> 

Only a few (<10) packages out of 600+ rust packages have very large Provides 
fields. The main Debian tools are coping with it fine. It's one derivative 
unofficial tool that's unable to cope.

I don't see why we should introduce artificial limits (and increase workload) 
in order to cater to one old tool.

>> Do you have some concrete suggestions on how to improve the tool to
>> reduce this "abuse"?
> 
> Don't generate virtual packages (Provides) for every feature; don't
> generate four virtual packages for every feature.
> 

Simply "not doing this" quite literally will break everything in the Debian 
Rust ecosystem of packages, and is quite directly analogous to asking dpkg to 
"ignore all Provides". Several alternatives were explored in the past and the 
current option was settled upon in #901827.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Raphael Hertzog:
> On Thu, 17 Oct 2019, Ximin Luo wrote:
>> Can you please explain why 256 KB provides field is "abuse"?
> 
> Because that's the amount of metadata required for 250 common packages.
> 

So? There are some Debian packages that have much more than 250 times the data 
of common packages. No tools break with that, nor are there suggestions that 
those big packages "suck".

>> Do you have some concrete suggestions on how to improve the tool to reduce 
>> this "abuse"?
> 
> Yes, I gave you one.
> 

It doesn't work.

>> BTW, the tool is run not at build time but to generate the source
>> package. So it can't use these "foo.cargo" files, because you don't need
>> to install all of the dependencies in order to use the tool.
> 
> If you run a tool to generate the source package, you can include
> whatever call you want during your source package build. i.e. you
> control debian/rules too. And you can process the source package
> and/or the binary package built to create those meta-information
> and also to use the existing meta-information on the system.
> 

This isn't a concrete suggestion, it's a generic vacuous statement about how 
package builds work, and is true for what already happens. The existing tool 
already "processes the source package [..] to create those meta-information", 
namely Provides fields corresponding to what's needed according to what's 
defined by upstream.

>> It is 2019. If a tool can't handle 256 KB of data, I'd say the tool is
>> at fault and not the 256 KB of data.
> 
> You are being arrogant. Replying in the same tone, I would say that the
> design of your tool suck.
> 

That's cool, and it really doesn't persuade me to have any sympathy towards 
your issue. Note that the next time this package is automatically regenerated, 
your "fixes" will be undone.

Please be a bit more self-critical about your own opinion. Have you considered 
the possibility that it is the reading tool (reprepro in this case) that 
"sucks" and not the writing tool?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Ximin Luo:
> Raphael Hertzog:
>> On Thu, 17 Oct 2019, Ximin Luo wrote:
>>> Control: tags -1 + wontfix
>>
>> This is clearly not acceptable. You can't ignore problems like this one.
>> I saw you already broke debian-installer once with the former packages
>> that overflowed the 16K limit of cdebootstrap. Now it's the turn of
>> reprepro and this one is harder to fix because there are real servers
>> running stable version of reprepro, etc.
>>
>>> The tool's algorithm was suggested by the maintainer of dpkg and has his
>>> blessing. It is partly due to limitations in dpkg, see #901827 for
>>> details.
>>
>> The algorithm is one thing... but the design of your tool is another
>> thing.
>>
>> dpkg has dpkg-shlibdeps to build dependencies based on exported
>> information by various package (through
>> /var/lib/dpkg/info/*.{shlibs,symbols}).
>>
>> cargo should build the same infrastructure, i.e. have a
>> /var/lib/dpkg/info/foo.cargo used by dh-cargo to build the correct
>> dependency.
>>
>> Don't abuse the "Provides" field when you have such a volume of
>> interfaces to document.
>>
> 
> Can you please explain why 256 KB provides field is "abuse"?
> 
> Do you have some concrete suggestions on how to improve the tool to reduce 
> this "abuse"?
> 

BTW, the tool is run not at build time but to generate the source package. So 
it can't use these "foo.cargo" files, because you don't need to install all of 
the dependencies in order to use the tool.

So yes, we need a concrete suggestion on improving the tool, rather than wild 
hyperbole that its output is "abuse".

It is 2019. If a tool can't handle 256 KB of data, I'd say the tool is at fault 
and not the 256 KB of data.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Raphael Hertzog:
> On Thu, 17 Oct 2019, Ximin Luo wrote:
>> Control: tags -1 + wontfix
> 
> This is clearly not acceptable. You can't ignore problems like this one.
> I saw you already broke debian-installer once with the former packages
> that overflowed the 16K limit of cdebootstrap. Now it's the turn of
> reprepro and this one is harder to fix because there are real servers
> running stable version of reprepro, etc.
> 
>> The tool's algorithm was suggested by the maintainer of dpkg and has his
>> blessing. It is partly due to limitations in dpkg, see #901827 for
>> details.
> 
> The algorithm is one thing... but the design of your tool is another
> thing.
> 
> dpkg has dpkg-shlibdeps to build dependencies based on exported
> information by various package (through
> /var/lib/dpkg/info/*.{shlibs,symbols}).
> 
> cargo should build the same infrastructure, i.e. have a
> /var/lib/dpkg/info/foo.cargo used by dh-cargo to build the correct
> dependency.
> 
> Don't abuse the "Provides" field when you have such a volume of
> interfaces to document.
> 

Can you please explain why 256 KB provides field is "abuse"?

Do you have some concrete suggestions on how to improve the tool to reduce this 
"abuse"?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#942487: [Pkg-rust-maintainers] Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

[Ximin Luo]

Control: tags -1 + wontfix

Ansgar:
> Sylvestre Ledru writes:
>> Le 17/10/2019 à 09:25, Ansgar a écrit :
>>> in addition a 256kB Provides field seems very hard on the total size of
>>> the Packages index.  Please don't do that...
>>>
>> To be clear, this isn't done by a human. This is a tool generating
>> this for us.
> 
> Then the tool has a problem.  It really seems excessive to add four
> Provides for every feature:
> 
>   librust-web-sys+abortcontroller-dev (= 0.3.28-1)
>   librust-web-sys-0+abortcontroller-dev (= 0.3.28-1)
>   librust-web-sys-0.3+abortcontroller-dev (= 0.3.28-1)
>   librust-web-sys-0.3.28+abortcontroller-dev (= 0.3.28-1)
> 
> Clearly the information is already available via the version
> information...  (I doubt even adding a Provides for every feature should
> be done.)
> 

The tool's algorithm was suggested by the maintainer of dpkg and has his 
blessing. It is partly due to limitations in dpkg, see #901827 for details.

This bug is only really fixable once the dpkg limitation is fixed, which can't 
happen (apparently) for a whole stable release cycle.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#931003: [Pkg-rust-maintainers] Bug#931003: Removed package(s) from unstable

[Ximin Luo]

Santiago Vila:
> reopen 931003
> found 931003 0.2.4-1
> fixed 931003 0.2.4-1+rm
> thanks
> 
> Hi.
> 
> This was automatically closed by ftpmaster because the package was
> removed from unstable, but this still does not fix the FTBFS problem
> in stable.
> 
> Thanks.
> 

Please be aware that the Debian Rust team today *does not make any effort* 
towards bugs affecting Debian Stable. If you want these bugs fixed, you will 
need to do it yourself.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#933693: rust-cargo: FTBFS due to missing/uninstallable build dependencies

[Ximin Luo]

We are blocked on FTP masters accepting rust-bstr and the new build 
dependencies of the new version of cargo.

Please check the debcargo-conf.git repo first, before filing bug reports for 
these types of FTBFS bugs. If there is a new version of the crate that is 
FTBFS, it means we the Rust team already know about it, and the bug report 
simply creates extra work to close it.

X

> Hi,
> 
> rust-cargo fails to rebuild from source (in a clean sbuild environment).
> 
> I ran into this while rebuilding all reverse dependencies of rust-openssl-sys
> prior to uploading an updated version.
> 
> Best,
> 
>   nicoo
> 
> ---
> 
> $ sbuild -d sid rust-cargo
> sbuild (Debian sbuild) 0.78.1 (09 February 2019) on localhost
> 
> +==+
> | rust-cargo (amd64)   Thu, 01 Aug 2019 23:34:16 
> + |
> +==+
> 
> Package: rust-cargo
> Distribution: sid
> Machine Architecture: amd64
> Host Architecture: amd64
> Build Architecture: amd64
> Build Type: full
> 
> [...]
> 
> +--+
> | Update chroot   
>  |
> +--+
> 
> [...]
> 
> +--+
> | Fetch source files  
>  |
> +--+
> 
> 
> Check APT
> -
> 
> Checking available source versions...
> 
> Download source files with APT
> --
> 
> Reading package lists...
> NOTICE: 'rust-cargo' packaging is maintained in the 'Git' version control 
> system at:
> https://salsa.debian.org/rust-team/debcargo-conf.git [src/cargo]
> Please use:
> git clone https://salsa.debian.org/rust-team/debcargo-conf.git [src/cargo]
> to retrieve the latest (possibly unreleased) updates to the package.
> Need to get 943 kB of source archives.
> Get:1 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (dsc) [5100 B]
> Get:2 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (tar) [934 kB]
> Get:3 http://localhost:3142/debian sid/main rust-cargo 0.35.0-1 (diff) [4304 
> B]
> Fetched 943 kB in 0s (11.2 MB/s)
> Download complete and in download only mode
> I: NOTICE: Log filtering will replace 
> 'build/rust-cargo-oCDNo8/rust-cargo-0.35.0' with '<>'
> I: NOTICE: Log filtering will replace 'build/rust-cargo-oCDNo8' with 
> '<>'
> 
> +--+
> | Install package build dependencies  
>  |
> +--+
> 
> 
> Setup apt archive
> -
> 
> Merged Build-Depends: debhelper (>= 11), dh-cargo (>= 15), cargo, rustc, 
> libstd-rust-dev, librust-atty-0.2+default-dev, 
> librust-byteorder-1+default-dev (>= 1.2-~~), librust-bytesize-1+default-dev, 
> librust-clap-2+default-dev (>= 2.31.2-~~), 
> librust-core-foundation-0.6+default-dev, 
> librust-core-foundation-0.6+mac-os-10-7-support-dev, 
> librust-crates-io-0.23+default-dev, librust-crossbeam-utils-0.6+default-dev, 
> librust-crypto-hash-0.3+default-dev (>= 0.3.1-~~), 
> librust-curl-0.4+default-dev (>= 0.4.19-~~), librust-curl-0.4+http2-dev (>= 
> 0.4.19-~~), librust-curl-sys-0.4+default-dev (>= 0.4.15-~~), 
> librust-env-logger-0.6+default-dev, librust-failure-0.1+default-dev (>= 
> 0.1.5-~~), librust-filetime-0.2+default-dev, librust-flate2-1+default-dev (>= 
> 1.0.3-~~), librust-flate2-1+zlib-dev (>= 1.0.3-~~), 
> librust-fs2-0.4+default-dev, librust-fwdansi-1+default-dev, 
> librust-git2-0.8+default-dev, librust-git2-curl-0.9+default-dev, 
> librust-glob-0.2+default-dev (>= 0.2.11-~~), librust-hex-0.3+default-dev, 
> librust-home-0.3+default-dev, librust-ignore-0.4+default-dev, 
> librust-im-rc-12+default-dev (>= 12.1.0-~~), 
> librust-jobserver-0.1+default-dev (>= 0.1.11-~~), 
> librust-lazy-static-1+default-dev (>= 1.2.0-~~), 
> librust-lazycell-1+default-dev (>= 1.2.0-~~), librust-libc-0.2+default-dev, 
> librust-libgit2-sys-0.7+default-dev (>= 0.7.9-~~), 
> librust-log-0.4+default-dev (>= 0.4.6-~~), librust-miow-0.3+default-dev (>= 
> 0.3.1-~~), librust-num-cpus-1+default-dev, librust-opener-0.3+default-dev, 
> librust-rustc-workspace-hack-1+default-dev, librust-rustfix-0.4+default-dev 
> (>= 0.4.4-~~), librust-same-file-1+default-dev, 
> librust-semver-0.9+default-dev, librust-semver-0.9+serde-dev, 
> librust-serde-1+default-dev (>= 1.0.82-~~), librust-serde-1+derive-dev (>= 
> 1.0.82-~~), librust-serde-ignored-0.0.4+default-dev, 
> librust-serde-json-1+default-dev (>= 1.0.30-~~), 
> librust-serde-json-1+raw-value-dev (>= 1.0.30-~~), 
> 

Bug#931002: Updating crates for Debian stable release

[Ximin Luo]

I am on vacation for the next two weeks, please can someone else deal with the 
following:

Due to Firefox we updated/unblocked rustc 1.34.2 for Debian Testing (and the 
next Debian Stable) release.

This causes two FTBFS bugs for crates which no longer build on rustc 1.34.2:

- #931002 coresimd https://crates.io/crates/coresimd
- #931003 simd https://crates.io/crates/simd

In fact these crates are deprecated and should be RMd. We also need to: 

- update encoding-rs so it doesn't depend on simd
- update packed-simd so it doesn't depend on coresimd
- package NEW core-arch package which is a new dependency of the updated 
packed-simd

and unblock these.

Otherwise {encoding-rs, packed-simd} and its reverse dependencies (including 
ripgrep) will have to be dropped from the next Debian Stable release.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#930218: [Pkg-rust-maintainers] Bug#930218: FTBFS on mips*

[Ximin Luo]

Mike Hommey:
> On Sat, Jun 08, 2019 at 10:27:15PM +0900, Mike Hommey wrote:
>> Package: cargo
>> Version: 0.35.0-1
>> Severity: serious
>>
>> https://buildd.debian.org/status/fetch.php?pkg=cargo=mips=0.35.0-1=1559294265=0
>> https://buildd.debian.org/status/fetch.php?pkg=cargo=mips64el=0.35.0-1=1559294794=0
>> https://buildd.debian.org/status/fetch.php?pkg=cargo=mipsel=0.35.0-1=1559297457=0
>>
>> For all of them, the failure looks like:
>>
>> failures:
>> freshness::changing_rustflags_is_cached
>> freshness::fingerprint_cleaner_does_not_rebuild
>> freshness::simple_deps_cleaner_does_not_rebuild
>>
>> test result: FAILED. 1513 passed; 3 failed; 1 ignored; 0 measured; 0 
>> filtered out
> 

The underlying issue is https://github.com/rust-lang/rust/issues/61440

I have a work-around for cargo in git, will upload it shortly.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#928422: [Pkg-rust-maintainers] Bug#928422: Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Ximin Luo]

Control: fixed -1 1.32.0+dfsg1-3
Control: fixed -1 1.25.0+dfsg1-1

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#928422: [Pkg-rust-maintainers] Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Ximin Luo]

Control: tags -1 + jessie
Control: notfound -1 1.32.0+dfsg1-3
Control: notfound -1 1.25.0+dfsg1-1

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#928422: [Pkg-rust-maintainers] Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Ximin Luo]

Control: tags + -1 jessie
Control: notfound -1 1.25

Please be a bit more careful filing bugs for old versions in future. Without 
the extra annotations I just added, this might have kicked rustc out of testing 
if nobody else was paying attention.

Judging from https://packages.debian.org/sid/fonts-open-sans all that's needed 
to fix this bug is to build and upload fonts-open-sans to jessie. Looks like 
whoever made the jessie upload of rustc failed to check this. Also it's funny 
that jessie contains rustc 1.24 but stretch contains 1.14. I was responsible 
for none of this stuff.

X

Andreas Beckmann:
> Package: rust-doc
> Version: 1.24.1+dfsg1-1~deb8u4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is not
> installable in jessie:
> 
> The following packages have unmet dependencies:
>  rust-doc : Depends: fonts-open-sans but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> 
> Cheers,
> 
> Andreas
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#926802: ipywidgets: FTBFS (TypeError: path.scope.getBindings(...).hasOwnProperty is not a function)

[Ximin Luo]

Sergio Durigan Junior:
> Control: block -1 by 928090
> On Saturday, April 27 2019, Ximin Luo wrote:
> 
>> Awesome, thanks! I was just getting around to this today. Do you want to do 
>> the NMU or shall I upload -4 as the "official maintainer"?
> 
> Heya, thanks for the quick reply :-).
> 
> I was actually going to write saying that I'm part of the Debian Python
> group, so I can just make a team upload.  But I've created the unblock
> bug with release.debian.org (#928090), so let's just wait on their
> reply.  Meanwhile, I'll push the changes to the git repo.
> 

We have to do an upload *as well as* unblock request, and we don't need to wait 
for the release team to do that. So we should do it ASAP when we're confident 
the bug is actually fixed, to avoid latency due to the asynchronity between 
teams here.

(The point of the unblock is to unblock *the package already in unstable* to be 
able to migrate to testing.)

As a team member you are free to take the -4 version, just put "Team upload" 
instead of "Non-maintainer upload" at the top line of your changelog, or use 
"dch --team" instead of "dch --nmu".

OK, I think I'll let you take care of the whole process :) Let me know if you 
need anything else.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#926802: ipywidgets: FTBFS (TypeError: path.scope.getBindings(...).hasOwnProperty is not a function)

[Ximin Luo]

Awesome, thanks! I was just getting around to this today. Do you want to do the 
NMU or shall I upload -4 as the "official maintainer"?

X

Sergio Durigan Junior:
> tags 926802 + patch
> usertags 926802 + bsp-2019-04-ca-toronto
> thanks
> 
> On Wednesday, April 10 2019, Santiago Vila wrote:
> 
>> Dear maintainer:
>>
>> I tried to build this package in buster but it failed:
> [...]
> 
> Heya from the Toronto BSP!
> 
> So, I've given it a try and managed to... hm...  fix the issue.  My
> JavaScript knowledge is rudimentary at best, but with the diff below
> makes the build complete without any apparent side effects (i.e., the
> testsuite still pass).
> 
> Kudos to Samuel Vale for helping verifying the code and making sure it
> looks OK.
> 
> I'll open an unblock request soon.
> 
> Thanks,
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#924206: control

[Ximin Luo]

Control: reassign -1 src:rust-failure 0.1.3-1
Control: fixed -1 0.1.5-1

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#924206: control

[Ximin Luo]

Control: reassign -1 rust-failure 0.1.3-1
Control: fixed -1 0.1.5-1

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#888935: node-xterm FTBFS: error TS2339: Property 'parentElement' does not exist on type 'never'

[Ximin Luo]

On Thu, 08 Mar 2018 17:53:27 + Ghislain Vaillant  wrote:
> > Source: node-xterm
> > Version: 2.7.0+ds1-1
> > Severity: serious
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/no
> > de-xterm.html
> > 
> > ...
> >debian/rules override_dh_auto_build
> > make[1]: Entering directory '/build/1st/node-xterm-2.7.0+ds1'
> > tsc --project .
> > src/utils/Mouse.ts(30,80): error TS2339: Property 'parentElement'
> > does not exist on type 'never'.
> > debian/rules:19: recipe for target 'override_dh_auto_build' failed
> > make[1]: *** [override_dh_auto_build] Error 2
> 
> No idea how to fix this. The package used to build fine.
> 
> Without further context, I am clueless about what to do about it.
> 

I had an attempt at this, but it is getting a bit hairy and I think it may be 
time to call it quits. My recommendation is for jupyter-notebook to patch out 
this functionality and not depend on node-xterm, and for this package to be RM 
from Debian.

Details:

The steps I am taking:

1. https://salsa.debian.org/js-team/typescript-types/tree/wip/node-xterm-fix

   - update typescript-types to include the missing modules
   - there is an issue with jsdom which can't use the newest parse5 so we have 
to forcibly use parse5 v4.0.0, which involves some extra tweaks to the 
typescript-types package.

2. apply this patch to node-xterm

diff --git a/debian/rules b/debian/rules
index a981410..eb56bcc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,7 +8,7 @@
 
 override_dh_auto_configure:
mkdir -p node_modules/@types
-   set -e; for i in chai jquery jsdom mocha node; do \
+   set -e; for i in chai glob jquery jsdom minimatch mocha node parse5 
sizzle tough-cookie; do \
ln -sf /usr/lib/nodejs/@types/$$i node_modules/@types/$$i; done
 
 COPY_AUX_FILES = \
@@ -16,7 +16,7 @@ COPY_AUX_FILES = \
cd $(1) && find -name *.css -exec cp --parents '{}' ../$(2) \; \
 
 override_dh_auto_build:
-   tsc --project .
+   tsc --moduleResolution Classic --project .
$(call COPY_AUX_FILES,src,lib)
 # Otherwise browserify-lite complains
touch lib/addons/index.js

The next error is:

src/Terminal.integration.ts:13:22 - error TS2307: Cannot find module 'node-pty'.

13 import * as pty from 'node-pty';
~~
which looks like this repo: https://github.com/Microsoft/node-pty

However, I really have no idea why this should be necessary, since we didn't 
need it in the previous version. Perhaps it used to be part of the standard 
nodejs distribution and then they split it off?

Anyways this is getting into the realms of JS crap that I wanted to leave 
behind forever.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#921836: ipywidgets: FTBFS (error TS2688: Cannot find type definition file for 'sizzle')

[Ximin Luo]

Control: reassign -1 src:typescript-types

This is a problem with the typescript-types package, I will upload a fix 
shortly.

X

Santiago Vila:
> Package: src:ipywidgets
> Version: 6.0.0-3
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --with python2,python3,sphinxdoc --buildsystem=pybuild
>dh_update_autotools_config -i -O--buildsystem=pybuild
>dh_autoreconf -i -O--buildsystem=pybuild
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> dh_auto_configure
> I: pybuild base:217: python2.7 setup.py config 
> running config
> I: pybuild base:217: python3.7 setup.py config 
> running config
> dh_auto_configure -- -d ./widgetsnbextension
> I: pybuild base:217: python2.7 setup.py config 
> INFO:root:setup.py entered
> INFO:root:$PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> running config
> I: pybuild base:217: python3.7 setup.py config 
> INFO:root:setup.py entered
> INFO:root:$PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
> running config
> make[1]: Leaving directory '/<>'
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> /usr/bin/make -C debian -f fakewebpack.mk all
> make[2]: Entering directory '/<>/debian'
> /usr/bin/make -f "fakewebpack-prep-unpacked.mk" all
> make[3]: Entering directory '/<>/debian'
> cd "fakewebpack-unpacked/phosphor/" && tsc --moduleResolution Classic 
> --project src
> mkdir -p "fakewebpack-unpacked/phosphor/styles/" && NODE_PATH=../.. 
> fakewebpack-helpers/css-loader-pack.py < 
> "fakewebpack-unpacked/phosphor/styles/base.css.real" > 
> "fakewebpack-unpacked/phosphor/styles/base.css"
> mkdir -p "fakewebpack-unpacked/phosphor/styles/" && m4 -DNODE_PATH=../.. 
> -DCSS_INPUT=./base.css "fakewebpack-helpers/style-loader.js.m4" > 
> "fakewebpack-unpacked/phosphor/styles/base.css?f74d"
> printf "module.exports = $(cat 
> "fakewebpack-unpacked/jupyter-js-widgets/package.json.real");" > 
> "fakewebpack-unpacked/jupyter-js-widgets/package.json"
> cd "fakewebpack-unpacked/jupyter-js-widgets/" && tsc --moduleResolution 
> Classic --project src
> ../../../../../../usr/lib/nodejs/@types/jquery/index.d.ts(28,23): error 
> TS2688: Cannot find type definition file for 'sizzle'.
> ../../../../../../usr/lib/nodejs/@types/jquery/misc.d.ts(27,33): error 
> TS2503: Cannot find namespace 'Sizzle'.
> ../../../../../../usr/lib/nodejs/@types/jquery/misc.d.ts(35,14): error 
> TS2503: Cannot find namespace 'Sizzle'.
> ../../../../../../usr/lib/nodejs/@types/jquery/misc.d.ts(43,17): error 
> TS2503: Cannot find namespace 'Sizzle'.
> make[3]: *** [fakewebpack-prep-unpacked.mk:33: 
> fakewebpack-unpacked/jupyter-js-widgets/lib.stamp] Error 1
> make[3]: Leaving directory '/<>/debian'
> make[2]: *** [fakewebpack.mk:73: 
> fakewebpack/widgetsnbextension-unpacked.stamp] Error 2
> make[2]: Leaving directory '/<>/debian'
> make[1]: *** [debian/rules:15: override_dh_auto_build] Error 2
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:7: build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> 
> 
> (The above is just how the build ends and not necessarily the most relevant 
> part)
> 
> The build was made in my autobuilder with "dpkg-buildpackage -A"
> and it also fails here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ipywidgets.html
> 
> where you can get a full build log if you need it.
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the BTS web page for this package.
> 
> Thanks.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#918426: control

[Ximin Luo]

Control: notfound -1 5.4.1-1

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#918854: [Pkg-rust-maintainers] Bug#918854: segfault updating crates.io index

[Ximin Luo]

Control: severity -1 important
Control: tag -1 + moreinfo unreproducible

I can't reproduce this, can you install cargo-dbgsym rustc-dbgsym rust-gdb 
libstd-rust-1.31-dbgsym libllvm7-dbgsym libc6-dbg and provide a backtrace?

X

Josh Triplett:
> Package: cargo
> Version: 0.31.1-1
> Severity: grave
> 
> Any time I try to update the crates.io index with the currently packaged
> version of cargo, I get a segfault:
> 
> $ cargo update
> Updating crates.io index
> Segmentation fault
> 
> I can reproduce this in a brand new project (`cargo new foo`) by adding
> any dependency to `Cargo.toml` (e.g. `strsim = "*"`) and then running
> `cargo update`.
> 
> libgit2 was just updated recently; that might potentially be related.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages cargo depends on:
> ii  binutils2.31.1-11
> ii  gcc 4:8.2.0-2
> ii  gcc-7 [c-compiler]  7.4.0-2
> ii  gcc-8 [c-compiler]  8.2.0-14
> ii  libc6   2.28-4
> ii  libcurl3-gnutls 7.62.0-1
> ii  libgcc1 1:8.2.0-14
> ii  libgit2-27  0.27.7+dfsg.1-0.1
> ii  libssh2-1   1.8.0-2
> ii  libssl1.1   1.1.1a-1
> ii  rustc   1.31.0+dfsg1-2
> ii  zlib1g  1:1.2.11.dfsg-1
> 
> cargo recommends no packages.
> 
> Versions of packages cargo suggests:
> pn  cargo-doc  
> ii  python33.7.1-3
> 
> -- no debconf information
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#913753: Processed: Re: Bug#913753: FTBFS: test-suite fails with ERROR: Rust compiler rustc can not compile programs.

[Ximin Luo]

Control: reassign -1 llvm-7
Control: forcemerge 913271 -1
Control: affects 913271 + src:meson src:rustc

Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> reassign 913753 rustc
> Bug #913753 [src:meson] FTBFS: test-suite fails with ERROR:  Rust compiler 
> rustc can not compile programs.
> Bug reassigned from package 'src:meson' to 'rustc'.
> No longer marked as found in versions meson/0.48.1-1.
> Ignoring request to alter fixed versions of bug #913753 to the same values 
> previously set
>> stop
> Stopping processing here.
> 
> Please contact me if you need assistance.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#913500: [Pkg-rust-maintainers] Bug#913500: cargo FTBFS: rustc segfaults

[Ximin Luo]

Control: reassign -1 llvm-7
Control: forcemerge 913271 -1

Helmut Grohne:
> Source: cargo
> Version: 0.31.0-3
> Severity: serious
> Tags: ftbfs
> 
> rustc segfauls while building cargo. For instance on amd64:
> 
> https://buildd.debian.org/status/fetch.php?pkg=cargo=amd64=0.31.0-3=1541763110=0
> 
> |  process didn't exit successfully: `rustc --crate-name build_script_build 
> /<>/vendor/serde/build.rs --color never --crate-type bin 
> --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 
> 'feature="std"' -C metadata=b12582fccfc6f2bd -C 
> extra-filename=-b12582fccfc6f2bd --out-dir 
> /<>/target/debug/build/serde-b12582fccfc6f2bd -L 
> dependency=/<>/target/debug/deps --cap-lints warn` (signal: 11, 
> SIGSEGV: invalid memory reference)
> 
> Helmut
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#913271: [Pkg-rust-maintainers] Bug#913271: segfault - broken rust compiling

[Ximin Luo]

Ximin Luo:
> [..]
> Thread 1 "rustc" received signal SIGSEGV, Segmentation fault.
> 0x71e273bc in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) 
> () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
> (gdb) bt
> #0  0x71e273bc in 
> llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) () from 
> /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
> #1  0x71f654c9 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
> #2  0x71f65491 in llvm::MDString::get(llvm::LLVMContext&, 
> llvm::StringRef) () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
> #3  0x71ee69cd in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1

Hopefully the stack trace is informative even though some stuff is missing. 
They are missing because the debug symbols are missing for this version of LLVM:

$ dpkg -S /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
libllvm7:amd64: /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
$ apt-cache policy libllvm7   
libllvm7:
  Installed: 1:7.0.1~+rc2-2
  Candidate: 1:7.0.1~+rc2-2
  Version table:
 *** 1:7.0.1~+rc2-2 500
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libllvm7-dbgsym
libllvm7-dbgsym:
  Installed: (none)
  Candidate: 1:7-8
  Version table:
 1:7-8 500
500 http://deb.debian.org/debian-debug unstable-debug/main amd64 
Packages

Would you be able to re-enable them Sylvestre?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#913271: segfault - broken rust compiling

[Ximin Luo]

The segfault is triggered by the presence of debuginfo=N where N != 0. You can 
avoid it by setting RUSTFLAGS or running "cargo rustc -- -C debuginfo=0" 
instead of "cargo build".

Together with the workaround for #913414, this means a temporary workaround for 
users could be to set RUSTFLAGS="-C debuginfo=0 -C relocation-model=default" in 
their environment. This works in some cases, unfortunately it doesn't work for 
packages that have a custom build.rs and use cc in it. (Perhaps the workaround 
can be extended to cover these cases too but I couldn't figure out how.)

Here is a backtrace of the segfault, would be good if someone else more 
familiar with LLVM than me could take a look:

hello_world$ gdb -q rustc
Reading symbols from rustc...Reading symbols from 
/usr/lib/debug/.build-id/e9/0dc62b102986d644f980ffeab6adab6f53625d.debug...done.
done.
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /usr/bin/rustc.
Use `info auto-load python-scripts [REGEXP]' to list them.
(gdb) run src/main.rs -C debuginfo=2
Starting program: /usr/bin/rustc src/main.rs -C debuginfo=2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee0ed700 (LWP 10750)]
[New Thread 0x7fffedeec700 (LWP 10751)]
[New Thread 0x7fffedceb700 (LWP 10752)]
[New Thread 0x7fffedae8700 (LWP 10753)]
[Thread 0x7fffedae8700 (LWP 10753) exited]
[Thread 0x7fffedceb700 (LWP 10752) exited]

Thread 1 "rustc" received signal SIGSEGV, Segmentation fault.
0x71e273bc in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) () 
from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
(gdb) bt
#0  0x71e273bc in llvm::StringMapImpl::LookupBucketFor(llvm::StringRef) 
() from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
#1  0x71f654c9 in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
#2  0x71f65491 in llvm::MDString::get(llvm::LLVMContext&, 
llvm::StringRef) () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
#3  0x71ee69cd in ?? () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
#4  0x71ee2d12 in llvm::DIBuilder::createFile(llvm::StringRef, 
llvm::StringRef, llvm::Optional >, 
llvm::Optional) () from 
/usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
#5  0x750a01f2 in LLVMRustDIBuilderCreateFile (Builder=0x555d4180, 
Filename=0x7ffeedd8 "src/main.rs", Directory=0x55b3dd10 
"$HOME/hello_world")
at /usr/lib/llvm-7/include/llvm/ADT/StringRef.h:85
#6  0x7501d39e in 
rustc_codegen_llvm::debuginfo::metadata::compile_unit_metadata (tcx=..., 
codegen_unit_name=..., debug_context=0x7ffeeeb0) at 
librustc_codegen_llvm/debuginfo/metadata.rs:859
#7  0x74f75946 in rustc_codegen_llvm::context::CodegenCx::new (tcx=..., 
codegen_unit=..., llvm_module=) at 
librustc_codegen_llvm/context.rs:272
#8  0x74ffad3e in 
rustc_codegen_llvm::base::compile_codegen_unit::module_codegen (tcx=..., 
cgu_name=...) at librustc_codegen_llvm/base.rs:1225
#9  0x7503e642 in rustc::dep_graph::graph::DepGraph::with_task_impl 
(self=0x7fff15d8, arg=..., no_tcx=false, task=0x800e8150, key=..., 
cx=..., create_task=, 
finish_task_and_alloc_depnode=) at 
librustc/dep_graph/graph.rs:342
#10 rustc::dep_graph::graph::DepGraph::with_task (self=0x7fff15d8, key=..., 
cx=..., arg=..., task=0x74ffac40 
) at 
librustc/dep_graph/graph.rs:208
#11 0x74ff8b8f in rustc_codegen_llvm::base::compile_codegen_unit 
(tcx=..., cgu_name=...) at librustc_codegen_llvm/base.rs:1199
#12 rustc_codegen_llvm::base::codegen_crate (tcx=..., rx=...) at 
librustc_codegen_llvm/base.rs:905
#13 0x7502df70 in ::codegen_crate 
(self=, tcx=..., rx=...) at librustc_codegen_llvm/lib.rs:215
#14 0x77deb832 in rustc_driver::driver::phase_4_codegen::{{closure}} () 
at librustc_driver/driver.rs:1369
#15 rustc::util::common::time_ext (do_it=, what=..., 
sess=, f=...) at librustc/util/common.rs:163
#16 rustc::util::common::time (sess=, what=..., f=...) at 
librustc/util/common.rs:157
#17 0x77e104ae in rustc_driver::driver::phase_4_codegen 
(codegen_backend=..., tcx=..., rx=...) at librustc_driver/driver.rs:1369
#18 0x77ebd614 in rustc_driver::driver::compile_input::{{closure}} 
(tcx=..., analysis=..., rx=..., result=...) at librustc_driver/driver.rs:328
#19 0x77eb7446 in 
rustc_driver::driver::phase_3_run_analysis_passes::{{closure}} (tcx=...) at 
librustc_driver/driver.rs:1352
#20 rustc::ty::context::tls::enter_global::{{closure}}::{{closure}} () at 
librustc/ty/context.rs:1986
#21 rustc::ty::context::tls::enter_context::{{closure}} () at 
librustc/ty/context.rs:1954
#22 rustc::ty::context::tls::set_tlv (value=, f=...) at 
librustc/ty/context.rs:1893
#23 rustc::ty::context::tls::enter_context (context=, f=...) at 
librustc/ty/context.rs:1953
#24 0x77e6e1cb in rustc::ty::context::tls::enter_global::{{closure}} () 
at librustc/ty/context.rs:1985
#25 

Bug#913408: Bug#901827: dpkg: Support two-sided version constraint ranges, required to properly translate Cargo dependencies

[Ximin Luo]

Control: severity 901827 important
Control: block 913408 by 901827

Ximin Luo:
> Guillem Jover:
>> [..]
>>
>> So you could have package slab-X.Y and then depend on just that, or if
>> for some reason you need to have coinstallability down to the minor
>> version, then slab-X.Y.Z, in which case that package would provide
>> slab-X.Y (= X.Y.Z). In addition, all of these would also provide
>> slab-X (= X.Y.Z) and slab (= X.Y.Z) and probably also slab, so that
>> you can represent all the range types.
>>
>>   Cargo deps (A) dpkg deps (A-X.Y || A-X.Y.Z)
>>   A  A
>>   A (>= 6)   A (>= 6)
>>   A (>= 6.1) A (>= 6.1)
>>   A (>= 6.1.3)   A (>= 6.1.3)
>>   A (>= 6, << 7) A-6
>>   A (>= 6.1, << 6.2) A-6.1
>>   A (= 6)A-6
>>   A (= 6.1)  A-6.1
>>
> 
> Thanks for being specific here. After thinking after it for a bit, I think 
> this might work. The key is to only generate a single item within in the 
> comma-separated list of AND-clauses in the dpkg dependency, where the item 
> itself is a "|"-separated OR-clause. It would be pretty ugly in some 
> circumstances:
> 
> Cargo deps  dpkg deps
> A (>= 6.1, << 9.5) >A-6 (>= 6.1) | A-7 | A-8 | A-9 (<< 9.5)
> 
> but I think I have a decently-simple way of achieving this in debcargo.
> 

This translation scheme works for Depends and Build-Depends, however it does 
not work for Replaces and Breaks, please see #913408 for an example of the 
problem.

In the abstract example above, since A-5 (= 5.1.1) replaces files from a 
previously-uploaded A (= 5.1.1), it must declare Replaces+Breaks: A (= 5). But 
in reality, there may be multiple Debian uploads of 5.1.1 including security 
uploads and backports. So we really need to declare:

Breaks: A (>= 5.1.1~~, << 5.1.2~~)
Replaces: A (>= 5.1.1~~, << 5.1.2~~)

but this is not possible in Debian today. Note that this:

Breaks: A (>= 5.1.1~~), A (<< 5.1.2~~)
Replaces: A (>= 5.1.1~~), A (<< 5.1.2~~)

won't work as it is equivalent to Breaks: A, Replaces: A which is not what we 
want.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#913266: [Pkg-rust-maintainers] Bug#913266: rustc fails to build many rust-* packages on arm64: LLVM ERROR: Only small and large code models are allowed on AArch64

[Ximin Luo]

Control: severity -1 important

Hi, please file these upstream.

As far as I can see these builds never worked in the first place, so this issue 
should not affect migration to Debian Testing.

X

Adrian Bunk:
> Package: rustc
> Version: 1.30.0+dfsg1-2
> Severity: serious
> 
> Example:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/rust-bytecount.html
> 
> ...
>dh_auto_test -O--buildsystem=cargo
> error: failed to run `rustc` to learn about target-specific information
> 
> Caused by:
>   process didn't exit successfully: `rustc - --crate-name ___ 
> --print=file-names --crate-type bin --crate-type rlib --crate-type dylib 
> --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit 
> code: 1)
> --- stderr
> LLVM ERROR: Only small and large code models are allowed on AArch64
> 
> dh_auto_test: cargo build --verbose --verbose -j8 --target 
> aarch64-unknown-linux-gnu -Zavoid-dev-deps returned exit code 101
> make: *** [debian/rules:3: build] Error 25
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#910885: not a bug

[Ximin Luo]

Control: notfound -1 0.7.0-1
Control: close -1

Hi, this is not a bug, it is due to how cargo dependencies work vs how dpkg 
dependencies work, for details see

https://github.com/kpcyrd/cargo-debstatus/issues/2

Furthermore there is also a bug in Britney where some packages might migrate 
too early, for details see

https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-September/002574.html

and the follow-ups.

See also #908364 #908366 #904485.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#910844: rust-phf-shared: unsatisifiable dependency

[Ximin Luo]

Control: reopen -1
Control: found -1 0.7.23-1

My apologies, you are correct there is indeed a problem. We uploaded unicase 
version 2 but we should have uploaded unicase version 1. Actually we can just 
patch phf_shared to accept both unicase version 1 >= 1.4 and version 2, I will 
do that imminently.

X

Ximin Luo:
> Control: notfound -1 0.7.23-1
> Control: close -1
> 
> Hi, this is not a bug, it is due to how cargo dependencies work vs how dpkg 
> dependencies work, for details see
> 
> https://github.com/kpcyrd/cargo-debstatus/issues/2
> 
> Furthermore there is also a bug in Britney where some packages might migrate 
> too early, for details see
> 
> https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-September/002574.html
> 
> and the follow-ups.
> 
> See also #908364 #908366 #904485.
> 
> X
> 
> Jeremy Bicha:
>> Source: rust-phf-shared
>> Version: 0.7.23-1
>> Severity: serious
>>
>> rust-phf-shared won't migrate to testing because
>> librust-phf-shared+unicase-dev depends on
>> librust-unicase-1+default-dev but that package is not available in
>> Debian.
>>
>> There is a librust-unicase-2+default-dev virtual package though.
>>
>> Thanks,
>> Jeremy Bicha
>>
> 
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#910844: rust-phf-shared: unsatisifiable dependency

[Ximin Luo]

Control: notfound -1 0.7.23-1
Control: close -1

Hi, this is not a bug, it is due to how cargo dependencies work vs how dpkg 
dependencies work, for details see

https://github.com/kpcyrd/cargo-debstatus/issues/2

Furthermore there is also a bug in Britney where some packages might migrate 
too early, for details see

https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-September/002574.html

and the follow-ups.

See also #908364 #908366 #904485.

X

Jeremy Bicha:
> Source: rust-phf-shared
> Version: 0.7.23-1
> Severity: serious
> 
> rust-phf-shared won't migrate to testing because
> librust-phf-shared+unicase-dev depends on
> librust-unicase-1+default-dev but that package is not available in
> Debian.
> 
> There is a librust-unicase-2+default-dev virtual package though.
> 
> Thanks,
> Jeremy Bicha
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57

[Ximin Luo]

Moritz Mühlenhoff:
> On Tue, Dec 05, 2017 at 01:46:00AM +0000, Ximin Luo wrote:
>> Control: severity -1 important
>> Control: tags -1 + upstream
>> Control: forwarded -1 
>> https://github.com/swick/mozilla-gnome-keyring/issues/48
>>
>> Mozilla are being slow.
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=309807
>> https://bugzilla.mozilla.org/show_bug.cgi?id=106400
> 
> Given the pushback in the bugs listed above this seems unlikely
> to be fixed in Firefox any time soon, so maybe let's drop
> the Firefox and restrict to Thunderbird (if that is confirmed
> to be still working fine with TB60)?
> 

Pretty sure it doesn't work with TB60, I just upgraded myself and am no longer 
using this extension.

I used "Password Exporter" (not in Debian, download it from AMO) to export my 
passwords, then disabled mozilla-gnome-keyring, then re-imported them using 
that same extension. So now everything is back in the Firefox/Thunderbird 
password managers.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#909482: [Pkg-rust-maintainers] Bug#909482: rustc: FTBFS on mips64el on buildds: timeout

[Ximin Luo]

Control: reassign -1 src:rustc
Control: forcemerge 881845 -1

Ximin Luo:
> Control: forcemerge 881845 -1
> 
> Yes, we're aware, see the discussion in #881845. The issue is some mips CPUs 
> are (allegedly) buggy and so a porter with access to the allegedly non-buggy 
> ones have been doing manual builds.
> 
> I let this situation continue but would also be happy to just RM rustc 
> mips64el for the time being, to avoid blocking migration to Debian Testing to 
> the other bugs.
> 
> If nobody builds mips64el in the next few days I will go ahead and request RM 
> by FTP masters.
> 
> X
> 
> Ivo De Decker:
>> package: rustc
>> version: 1.28.0+dfsg1-2
>> severity: serious
>> tags: ftbfs
>>
>> Hi,
>>
>> The builds of rustc in sid on mips64el consistently fail on the buildds:
>>
>> https://buildd.debian.org/status/logs.php?pkg=rustc=mips64el
>>
>> Most of the fail with
>>
>> "Build killed with signal TERM after 150 minutes of inactivity"
>>
>> If the build is actually still going at that point, it should produce output
>> to avoid being killed.
>>
>> The builds that are in the archive seem to be manual builds that were
>> uploaded.
>>
>> Cheers,
>>
>> Ivo
>>
-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#909482: [Pkg-rust-maintainers] Bug#909482: rustc: FTBFS on mips64el on buildds: timeout

[Ximin Luo]

Control: forcemerge 881845 -1

Yes, we're aware, see the discussion in #881845. The issue is some mips CPUs 
are (allegedly) buggy and so a porter with access to the allegedly non-buggy 
ones have been doing manual builds.

I let this situation continue but would also be happy to just RM rustc mips64el 
for the time being, to avoid blocking migration to Debian Testing to the other 
bugs.

If nobody builds mips64el in the next few days I will go ahead and request RM 
by FTP masters.

X

Ivo De Decker:
> package: rustc
> version: 1.28.0+dfsg1-2
> severity: serious
> tags: ftbfs
> 
> Hi,
> 
> The builds of rustc in sid on mips64el consistently fail on the buildds:
> 
> https://buildd.debian.org/status/logs.php?pkg=rustc=mips64el
> 
> Most of the fail with
> 
> "Build killed with signal TERM after 150 minutes of inactivity"
> 
> If the build is actually still going at that point, it should produce output
> to avoid being killed.
> 
> The builds that are in the archive seem to be manual builds that were
> uploaded.
> 
> Cheers,
> 
> Ivo
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#908364: [Pkg-rust-maintainers] Bug#908364: Bug#908366: librust-cc+parallel-dev: unsatisfiable dependency on librust-rayon-1+default-dev

[Ximin Luo]

Ximin Luo:
> Steve Langasek:
>> On Sun, Sep 09, 2018 at 05:14:00PM +0000, Ximin Luo wrote:
>>> Please see bug 904485 https://bugs.debian.org/904485
>>
>>> The bug is not in this package but in the speed of our packaging and the
>>> NEW queue.  If you help us package nodrop-union etc that will help the
>>> situation.
>>
>> On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
>>
>>> The bug is not in this package but in the speed of our packaging and the
>>> NEW queue.  If you help us package nodrop-union etc that will help the
>>> situation.
>>
>> I have no interest in working on the packaging for these packages, I am only
>> trying to work out why unreleasable packages are finding their way into
>> Ubuntu as part of package syncs.
>>
>> This is definitely not caused by issues of NEW queue processing speed as the
>> dependencies in question are not in the NEW queue at all.  This is a matter
>> of dependency stacks being uploaded out of order.  Why are rust packages
>> being uploaded to Debian out of dependency order?
>>
> 
> There are three types of dependencies, it is being uploaded in dependency 
> order of one type but not the other two types. This is inevitable due to 
> cargo's design, see https://github.com/kpcyrd/cargo-debstatus/issues/2 for 
> details.
> 

Furthermore there is also a bug in Britney which is why you might be seeing 
some issues in Ubuntu package sync, see 
https://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/2018-September/002574.html
 for details.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#908364: [Pkg-rust-maintainers] Bug#908364: Bug#908366: librust-cc+parallel-dev: unsatisfiable dependency on librust-rayon-1+default-dev

[Ximin Luo]

Steve Langasek:
> On Sun, Sep 09, 2018 at 05:14:00PM +0000, Ximin Luo wrote:
>> Please see bug 904485 https://bugs.debian.org/904485
> 
>> The bug is not in this package but in the speed of our packaging and the
>> NEW queue.  If you help us package nodrop-union etc that will help the
>> situation.
> 
> On Sun, Sep 09, 2018 at 05:14:00PM +, Ximin Luo wrote:
> 
>> The bug is not in this package but in the speed of our packaging and the
>> NEW queue.  If you help us package nodrop-union etc that will help the
>> situation.
> 
> I have no interest in working on the packaging for these packages, I am only
> trying to work out why unreleasable packages are finding their way into
> Ubuntu as part of package syncs.
> 
> This is definitely not caused by issues of NEW queue processing speed as the
> dependencies in question are not in the NEW queue at all.  This is a matter
> of dependency stacks being uploaded out of order.  Why are rust packages
> being uploaded to Debian out of dependency order?
> 

There are three types of dependencies, it is being uploaded in dependency order 
of one type but not the other two types. This is inevitable due to cargo's 
design, see https://github.com/kpcyrd/cargo-debstatus/issues/2 for details.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#908364: librust-nodrop+nodrop-union-dev: unsatisfiable dependency on librust-nodrop-union-0.1+default-dev

[Ximin Luo]

Control: notfound -1 0.1.12-1
Control: close -1

Please see bug 904485 https://bugs.debian.org/904485

The bug is not in this package but in the speed of our packaging and the NEW 
queue. If you help us package nodrop-union etc that will help the situation.

Steve Langasek:
> Package: librust-nodrop+nodrop-union-dev
> Version: 0.1.12-1
> Severity: grave
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic
> 
> The rust-nodrop source package creates a binary package
> librust-nodrop+nodrop-union-dev with a dependency on
> librust-nodrop-union-0.1+default-dev which does not exist as a real or
> virtual package in Debian.
> 
> There is no package called 'rust-nodrop-union' in either Debian or in the
> NEW queue, so it's not clear what is supposed to provide the package that
> satisfies this dependency.
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#908366: librust-cc+parallel-dev: unsatisfiable dependency on librust-rayon-1+default-dev

[Ximin Luo]

Control: notfound -1 1.0.17-2
Control: close -1

Please see bug 904485 https://bugs.debian.org/904485

The bug is not in this package but in the speed of our packaging and the NEW 
queue. If you help us package nodrop-union etc that will help the situation.

Steve Langasek:
> Package: librust-cc+parallel-dev
> Version: 1.0.17-2
> Severity: grave
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu cosmic
> 
> The rust-cc source package creates a binary package librust-cc+parallel-dev
> with a dependency on librust-rayon-1+default-dev which does not exist as a
> real or virtual package in Debian.
> 
> There is no package called 'rust-rayon' in either Debian or in the NEW
> queue, so it's not clear what is supposed to provide the package that
> satisfies this dependency.
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault

[Ximin Luo]

Control: reopen -1 

The patch I just uploaded fixed the problem on my x86-64 box and plummer the 
ppc64el porterbox.

However the same test still segfaults on armhf even with gcc-8.

I'll try to get another stacktrace and notify upstream.

X

Ximin Luo:
> Control: forwarded -1 https://github.com/libgit2/libgit2/issues/4753
> 
> The segfault happens on all architectures and we were just unlucky that it 
> happened on the ones that we saw.
> 
> I've filed an upstream issue with a stack trace, will continue debugging 
> later.
> 
> X
> 
> Pirate Praveen:
>> On 18/07/18 6:39 PM, John Paul Adrian Glaubitz wrote:
>>> I don't think your last upload was a good idea as you apparently
>>> didn't test your change on all affected architectures. The testsuite
>>> still fails on mips64el and ppc64el.
>>
>> The previous upload was failing only on amrhf so thought fixing that
>> would be enough.
>>
>>> Please take advantage of the porterboxes we have in Debian [1] rather
>>> than just uploading a new version over and over again to test new
>>> changes.
>>
>> ok.
>>


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904004: libgit2 FTBFS on armhf internal compil,er error: Segmentation fault

[Ximin Luo]

Control: forwarded -1 https://github.com/libgit2/libgit2/issues/4753

The segfault happens on all architectures and we were just unlucky that it 
happened on the ones that we saw.

I've filed an upstream issue with a stack trace, will continue debugging later.

X

Pirate Praveen:
> On 18/07/18 6:39 PM, John Paul Adrian Glaubitz wrote:
>> I don't think your last upload was a good idea as you apparently
>> didn't test your change on all affected architectures. The testsuite
>> still fails on mips64el and ppc64el.
> 
> The previous upload was failing only on amrhf so thought fixing that
> would be enough.
> 
>> Please take advantage of the porterboxes we have in Debian [1] rather
>> than just uploading a new version over and over again to test new
>> changes.
> 
> ok.
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904485: [Pkg-rust-maintainers] Bug#904485: Bug#904485: Bug#904485: Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev

[Ximin Luo]

John Paul Adrian Glaubitz:
> On 07/25/2018 12:32 AM, Ximin Luo wrote:
>> The testing migration scripts prevent the temporarily-problematic packages 
>> from reaching Debian testing
> 
> Yes, but the scripts don't prevent piuparts from throwing errors and unstable
> users from writing invalid bug reports. Been there, done that when I was on
> the MATE team.
> 
>> , e.g. [1] so I don't see an issue with uploading to unstable directly. 
>> Uploading
>>  to experimental then unstable again, causes extra unnecessary work for us.
> 
> It causes a minimal extra work, yes. But it avoids these bug reports and long
> discussions. We have received such bug reports not just once in the MATE
> team but many times since many unstable users don't understand the concept
> of the NEW queue.
> 
> Other teams like the KDE team usually take the experimental detour as well,
> it's common practice.
> 

I think the cost-benefit trade-off for rust weighs more in the "just upload to 
unstable" direction. Piuparts can be fixed to understand this situation, and 
unstable users can be educated to understand what "unstable" means. Discussions 
don't have to be long.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904485: [Pkg-rust-maintainers] Bug#904485: Bug#904485: Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev

[Ximin Luo]

John Paul Adrian Glaubitz:
> Hi Ximin!
> 
> On 07/25/2018 12:01 AM, Ximin Luo wrote:
>> Hi Andreas, this is not a bug, it's because FTP masters are slow with 
>> processing the NEW queue.
>>
>> We expect similar situations for other rust packages, for the time being.
>>
>> Please don't file such bugs for the next few months whilst we get the basic 
>> set of rust packages into Debian. If you see this situation again after 6 
>> months however, then that is a real bug and feel free to file one.
> 
> Maintainers normally go through experimental to avoid these issues, i.e.
> you first upload all packages into experimental and once they have passed
> NEW, you re-upload them to unstable.
> 

The testing migration scripts prevent the temporarily-problematic packages from 
reaching Debian testing, e.g. [1] so I don't see an issue with uploading to 
unstable directly. Uploading to experimental then unstable again, causes extra 
unnecessary work for us.

X

[1] https://qa.debian.org/excuses.php?package=rust-serde

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904485: [Pkg-rust-maintainers] Bug#904485: Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev

[Ximin Luo]

Andreas Beckmann:
> On 2018-07-25 00:01, Ximin Luo wrote:
>> Hi Andreas, this is not a bug, it's because FTP masters are slow with 
>> processing the NEW queue.
>>
>> We expect similar situations for other rust packages, for the time being.
> 
> OK. But I don't see the missing package in NEW...
> 

Not all of the build-dependencies of the missing packages (rust-derive, 
rust-serde-derive) are in Debian yet so we didn't upload them yet. Some of 
those are in NEw, some of those also have their own build-dependencies not yet 
in Debian.

For context, there's about 200 rust packages in the backlog currently, 89 are 
in Debian and 29 are in NEW.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904485: close

[Ximin Luo]

Control: close -1

Closing, not a bug.

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#904485: [Pkg-rust-maintainers] Bug#904485: librust-serde+{, serde-}derive-dev: unsatisfiable Depends: librust-serde-derive-1+default-dev

[Ximin Luo]

Control: notfound -1 1.0.70-1

Hi Andreas, this is not a bug, it's because FTP masters are slow with 
processing the NEW queue.

We expect similar situations for other rust packages, for the time being.

Please don't file such bugs for the next few months whilst we get the basic set 
of rust packages into Debian. If you see this situation again after 6 months 
however, then that is a real bug and feel free to file one.

Best,
Ximin

Andreas Beckmann:
> Package: librust-serde+serde-derive-dev,librust-serde+derive-dev
> Version: 1.0.70-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is not
> installable in sid:
> 
> librust-serde+derive-dev/amd64 unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/amd64 unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/i386 unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/i386 unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/arm64 unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/arm64 unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/armel unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/armel unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/armhf unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/armhf unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/mips64el unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/mips64el unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/ppc64el unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/ppc64el unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+derive-dev/s390x unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> librust-serde+serde-derive-dev/s390x unsatisfiable Depends: 
> librust-serde-derive-1+default-dev
> 
> 
> Cheers,
> 
> Andreas
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#903118: [Pkg-rust-maintainers] Bug#903118: rustc: FTBFS in stretch (no cargo executable found)

[Ximin Luo]

Santiago Vila:
> [..]
> Exception: no cargo executable found at `/usr/bin/cargo`
> debian/rules:216: recipe for target 'override_dh_auto_build-indep' failed
> make[1]: *** [override_dh_auto_build-indep] Error 1
> make[1]: Leaving directory '/<>/rustc-1.24.1+dfsg1'
> debian/rules:143: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 
> 
> I did "dpkg-buildpackage -A" but apparently it also fails with 
> "dpkg-buildpackage -B"
> in every other architecture:
> 

Moritz,

The easiest way to fix all of the above would be to re-introduce the 
cargo/rustc self-Build-Depends but add a [!amd64] architecture-specific 
annotation to it. Then an arch:all build and the other-architecture builds will 
simply be not performed due to "missing build-deps".

This is what `d/rules source_orig-dl` suggests and I should have been more 
strict about it when reviewing your earlier patch, sorry.

If you need to bootstrap other architectures you can cross-compile them using 
`sbuild --host=$foreign-arch` although this was broken in upstream 1.25 [1] but 
may work on 1.24.

X

[1] https://github.com/rust-lang/rust/issues/49677

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#900558: libssh2-1-dev: missing dependency on zlib1g-dev

[Ximin Luo]

Package: libssh2-1-dev
Version: 1.8.0-1
Severity: serious
Tags: patch
Justification: Policy 3.5

Dear Maintainer,

This library needs a dependency on zlib1g-dev, otherwise pkg-config fails:

$ pkg-config --libs --cflags libssh2
Package zlib was not found in the pkg-config search path.
Perhaps you should add the directory containing `zlib.pc'
to the PKG_CONFIG_PATH environment variable
Package 'zlib', required by 'libssh2', not found

This breaks the build process of some libraries.

X

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

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

Bug#892358: xul-ext-gnome-keyring: Don't depend on libgnome-keyring

[Ximin Luo]

Do you have some advice on how to migrate? Last time I checked there was no 
straightforward 1-1 correspondence between the libsecret vs the 
libgnome-keyring API and data models.

Forcing people to do extra work they don't know how to do, or else risk losing 
their most precious data, is extremely irresponsible software development.

X

Jeremy Bicha:
> Package: xul-ext-gnome-keyring
> Version: 0.12-1
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs libgnome-keyring-removal
> Tags: sid buster
> 
> As announced [1], we are working to remove libgnome-keyring from
> Debian. The libgnome-keyring library is deprecated and its usage is strongly
> discouraged [2].
> 
> Your package xul-ext-gnome-keyring depends on libgnome-keyring0.
> 
> Please update your application to use libsecret instead [3].
> Such a port should ideally happen with upstream being involved.
> 
> Otherwise, please consider requesting that your package be removed
> from Debian to
> help us complete this goal.
> 
> [1] https://lists.debian.org/debian-devel/2018/02/msg00169.html
> [2] https://git.gnome.org/browse/libgnome-keyring/commit/?id=6a5adea4aec93
> [3] https://wiki.gnome.org/Projects/Libsecret
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#890254: control

[Ximin Luo]

Control: fixed -1 1.2-3

Already fixed there, version in stretch still affected.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#888606: [Debian-science-sagemath] Fwd: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build target

[Ximin Luo]

I saw some issue, I forgot where, that pointed out both mpfr4 and mpfr6 were 
getting pulled into certain builds. You could check your sbuild logs to see if 
both are getting installed.

X

Tobias Hansen:
> Hi,
> 
> yes, I think you can update cysignals in unstable. I applied upstream patches 
> for new mpfr and matplotlib versions to sagemath and built it with both 
> versions of cysignals yesterday and got the same problems:
> 
> sage -t --long src/sage/rings/number_field/number_field.py  # Bad exit: 1
> sage -t --long src/sage/rings/polynomial/plural.pyx  # Killed due to 
> segmentation fault
> sage -t --long src/sage/structure/factorization_integer.py  # Killed due to 
> kill signal
> sage -t --long src/sage/structure/sage_object.pyx  # Killed due to abort
> 
> I have had the failure with number_field.py on my computer for a while, but 
> it doesn't happen on buildds. The others are new, but I don't even know if 
> the libmpfr6 transition is finished...
> 
> Best,
> Tobias
> 
> 
> On 01/28/2018 06:11 AM, Jerome BENOIT wrote:
>> Hello,
>>
>> this issue was fixed in 1.6.6+ds-2 which is current in experimental:
>> can we migrate cysingals 1.6.6+ds-2 to unstable ?
>>
>> Thanks,
>> Jerome
>>
>>
>>  Forwarded Message 
>> Subject: Bug#888606: cysignals: FTBFS with debhelper/11.1 due to empty build 
>> target
>> Resent-Date: Sat, 27 Jan 2018 17:51:02 +
>> Resent-From: Niels Thykier 
>> Resent-To: debian-bugs-d...@lists.debian.org
>> Resent-CC: Jerome Benoit 
>> Date: Sat, 27 Jan 2018 18:44:34 +0100
>> From: Niels Thykier 
>> Reply-To: Niels Thykier , 888...@bugs.debian.org
>> To: Debian Bug Tracking System 
>>
>> Source: cysignals
>> Version: 1.6.5+ds-2
>> Severity: serious
>> Tags: patch
>>
>> Hi,
>>
>> The cysignals package FTBFS with debhelper/11.1 as it has an empty
>> build target.  This is caused by debhelper had a bug in its handling
>> of "explicitly defined rules targets" that has now been fixed.
>>
>> Previously, this happened to work because dpkg-buildpackage would
>> invoke "debian/rules build" (which would be a no-op) followed by
>> "fakeroot debian/rules binary".  During the binary target, dh's
>> suboptimal handling would run the build commands.
>>
>>
>> The solution is trivial but less pretty; explicitly define "build"
>> with the same content as the "%:" target (or rename the "build" folder
>> and drop the ".PHONY" target).  I have attached a patch for this.
>>
>>
>> More details can be found in:
>>  * #886901 comment #35
>>  * #887688 comment #37
>>  * #880840
>>
>> Apologies for the inconvenience.
>>
>> Thanks,
>> ~Niels
>>
>>
>>
>> ___
>> Debian-science-sagemath mailing list
>> debian-science-sagem...@lists.alioth.debian.org
>> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
> 
> 
> 
> 
> 
> ___
> Debian-science-sagemath mailing list
> debian-science-sagem...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/debian-science-sagemath
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#881878: marked as pending

[Ximin Luo]

tag 881878 pending
thanks

Hello,

Bug #881878 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/fpylll.git/commit/?id=9307be8

---
commit 9307be893b783c97d91e65bec415e55c24f355e4
Author: Ximin Luo <infini...@debian.org>
Date:   Thu Dec 28 13:48:36 2017 +0100

Work around upstream #112 test failure on 32-bit arches

diff --git a/debian/changelog b/debian/changelog
index 6e5e377..59245cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+fpylll (0.3.0+ds-2) UNRELEASED; urgency=medium
+
+  * Work around upstream #112 test failure on 32-bit arches. (Closes: #881878)
+
+ -- Ximin Luo <infini...@debian.org>  Thu, 28 Dec 2017 13:24:43 +0100
+
 fpylll (0.3.0+ds-1) experimental; urgency=medium
 
   * Team upload to experimental.

Bug#881506: xul-ext-gnome-keyring doesn't work with firefox >=57

[Ximin Luo]

Control: severity -1 important
Control: tags -1 + upstream
Control: forwarded -1 https://github.com/swick/mozilla-gnome-keyring/issues/48

Mozilla are being slow.

https://bugzilla.mozilla.org/show_bug.cgi?id=309807
https://bugzilla.mozilla.org/show_bug.cgi?id=106400

In the meantime this still works for firefox-esr so I'm downgrading the 
severity to not be RC.

X

Laurent Bigonville:
> Package: xul-ext-gnome-keyring
> Version: 0.12-1
> Severity: serious
> Tags: sid buster
> 
> Hi,
> 
> xul-ext-gnome-keyring does not work with firefox 57 anymore due to the
> the switch webextension.
> 
> The package should probably be removed or fixed to support that.
> 
> Regards,
> 
> Laurent Bigonville
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
> 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.14.0-rc8+ (SMP w/8 CPU cores)
> Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#881236: flint-arb: tests fail on amd64 and i386

[Ximin Luo]

Control: reassign -1 src:flint
Control: retitle -1 flint: omits __volatile__ in assembly division, causing 
faulty optimisations
Control: affects -1 src:flint-arb

The bug is in flint not flint-arb, see:

https://gmplib.org/list-archives/gmp-bugs/2017-October/004231.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677
https://github.com/fredrik-johansson/arb/issues/194

We patched flint on amd64 in Debian as a minimal fix, but the proper fix is 
being discussed with GMP upstream, where flint copied its code from.

I will extend the patch to i386 later today, and close this bug with a new 
flint upload.

X

On Thu, 9 Nov 2017 08:19:27 +0100 Matthias Klose  wrote:
> Package: src:flint-arb
> Version: 2.11.1-1
> Severity: serious
> Tags: sid buster
> 
> The x86* builds fail with:
> 
> make[3]: Leaving directory '/<>/dlog'
> make[3]: Entering directory '/<>/arb_fmpz_poly'
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include test/t-evaluate_acb.c
> -o ../build/arb_fmpz_poly/test/t-evaluate_acb -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF ../build/arb_fmpz_poly/test/t-evaluate_acb.d -MT
> "../build/arb_fmpz_poly/test/t-evaluate_acb" -MT
> "../build/arb_fmpz_poly/test/t-evaluate_acb.d"
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include
> test/t-gauss_period_minpoly.c -o
> ../build/arb_fmpz_poly/test/t-gauss_period_minpoly -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF 
> ../build/arb_fmpz_poly/test/t-gauss_period_minpoly.d
> -MT "../build/arb_fmpz_poly/test/t-gauss_period_minpoly" -MT
> "../build/arb_fmpz_poly/test/t-gauss_period_minpoly.d"
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include 
> test/t-complex_roots.c
> -o ../build/arb_fmpz_poly/test/t-complex_roots -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF ../build/arb_fmpz_poly/test/t-complex_roots.d -MT
> "../build/arb_fmpz_poly/test/t-complex_roots" -MT
> "../build/arb_fmpz_poly/test/t-complex_roots.d"
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -I/<>
> -I/usr/local/include -I/usr/local/include -I/usr/include test/t-evaluate_arb.c
> -o ../build/arb_fmpz_poly/test/t-evaluate_arb -L/<>
> -L/usr/local/lib -L/usr/local/lib -L/usr/lib -lflint-arb -lflint -lmpfr -lgmp
> -lm -lpthread  -MMD -MP -MF ../build/arb_fmpz_poly/test/t-evaluate_arb.d -MT
> "../build/arb_fmpz_poly/test/t-evaluate_arb" -MT
> "../build/arb_fmpz_poly/test/t-evaluate_arb.d"
> evaluate_acbgauss_period_minpoly../Makefile.subdirs:84: recipe for
> target '../build/arb_fmpz_poly/test/t-gauss_period_minpoly_RUN' failed
> make[3]: *** [../build/arb_fmpz_poly/test/t-gauss_period_minpoly_RUN] Floating
> point exception
> make[3]: *** Waiting for unfinished jobs
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#880241: marked as pending

[Ximin Luo]

tag 880241 pending
thanks

Hello,

Bug #880241 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


https://anonscm.debian.org/cgit/python-modules/packages/testpath.git/commit/?id=ab9d454

---
commit ab9d454b584d6f702574db2ad61dee7b88eb942b
Author: Ximin Luo <infini...@debian.org>
Date:   Tue Nov 7 14:26:57 2017 +0100

Add an .egg-info file so pip recognises it

diff --git a/debian/changelog b/debian/changelog
index 6accb26..692bf25 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+testpath (0.3.1+dfsg-2) UNRELEASED; urgency=medium
+
+  * Team upload.
+  * Add an .egg-info file so pip recognises it. (Closes: #880241)
+
+ -- Ximin Luo <infini...@debian.org>  Tue, 07 Nov 2017 14:17:28 +0100
+
 testpath (0.3.1+dfsg-1) unstable; urgency=medium
 
   * New upstream release.

Bug#880241: sagenb-export: FTBFS: Test failures

[Ximin Luo]

Control: reassign -1 src:testpath
Control: retitle -1 testpath does not install .egg-info or .dist-info, making 
it invisible to pip
Control: affects -1 sagenb-export

The sagenb-export FTBFS is caused by the python "testpath" module not 
installing a .egg-info file (or .dist-info directory) which makes it invisible 
to pip. It then tries downloading testpath from the internet, causing the below 
error.

Upstream testpath uses their own custom tool "flit" to generate a .dist-info 
directory - which you can see the contents of by running `pip install testpath` 
then looking in ~/.local/lib/python2.7/site-packages/testpath-0.3.1.dist-info/.

An alternative to packaging flit and then modifying testpath to use flit, would 
be to simply add 
~/.local/lib/python2.7/site-packages/testpath-0.3.1.dist-info/METADATA to our 
Debian packaging and install it in 
/usr/lib/pythonX.Y/dist-packages/testpath-0.3.1.egg-info, etc

X

On Mon, 30 Oct 2017 20:32:00 +0100 Lucas Nussbaum  wrote:
> Source: sagenb-export
> Version: 3.2-3
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20171030 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > r = adapter.send(request, **kwargs)
> >   File 
> > "/<>/.tox/python3/share/python-wheels/CacheControl-0.11.7-py2.py3-none-any.whl/cachecontrol/adapter.py",
> >  line 47, in send
> > resp = super(CacheControlAdapter, self).send(request, **kw)
> >   File 
> > "/<>/.tox/python3/share/python-wheels/requests-2.12.4-py2.py3-none-any.whl/requests/adapters.py",
> >  line 423, in send
> > timeout=timeout
> >   File 
> > "/<>/.tox/python3/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/connectionpool.py",
> >  line 643, in urlopen
> > _stacktrace=sys.exc_info()[2])
> >   File 
> > "/<>/.tox/python3/share/python-wheels/urllib3-1.19.1-py2.py3-none-any.whl/urllib3/util/retry.py",
> >  line 315, in increment
> > total -= 1
> > TypeError: unsupported operand type(s) for -=: 'Retry' and 'int'
> > 
> > python3 installed: 
> > bleach==2.0.0,decorator==4.1.2,entrypoints==0.2.3.post1,html5lib==0.9,ipykernel==4.6.1,ipython==5.5.0,ipython-genutils==0.2.0,Jinja2==2.9.6,jsonschema==2.5.1,jupyter-client==5.1.0,jupyter-core==4.3.0,MarkupSafe==1.0,mistune==0.8,nbconvert==5.3.1,nbformat==4.4.0,notebook==4.2.3,pandocfilters==1.4.2,pexpect==4.2.1,pickleshare==0.7.4,pkg-resources==0.0.0,pluggy==0.4.0,prompt-toolkit==1.0.14,py==1.4.34,Pygments==2.2.0,python-dateutil==2.6.1,pyzmq==16.0.2,simplegeneric==0.8.1,six==1.11.0,terminado==0.6,tornado==4.5.1,tox==2.5.0,traitlets==4.3.2,virtualenv==15.1.0,wcwidth==0.1.7,webencodings==0.5
> > ___ summary 
> > 
> > ERROR:   python: InvocationError: /<>/.tox/python/bin/pip 
> > install /<>/.tox/dist/sagenb_export-3.2.zip (see 
> > /<>/.tox/python/log/python-1.log)
> > ERROR:   python3: InvocationError: /<>/.tox/python3/bin/pip 
> > install /<>/.tox/dist/sagenb_export-3.2.zip (see 
> > /<>/.tox/python3/log/python3-1.log)
> > debian/rules:30: recipe for target 'override_dh_auto_test' failed
> 
> The full build log is available from:
>http://aws-logs.debian.net/2017/10/30/sagenb-export_3.2-3_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#876533: hol-light FTBFS with OCaml 4.05.0

[Ximin Luo]

Hendrik Tews:
> 
>> Hi Hendrik, any progress on this? I notice in the ocaml transition tracker:
> 
> I really spend more than 4 weeks in discussions with upstream
> about license and copyright clarifications. Now it is finished. I
> uploaded a new hol-light version to DOM git yesterday. Please
> review and upload.
> 

Ouch, well here are some comments:

dpkg-gencontrol: warning: package hol-light: unused substitution variable 
${ocaml:Provides}
dpkg-gencontrol: warning: package hol-light: unused substitution variable 
${perl:Depends}

These are quite important, you should never ignore them. You need to add an 
extra Provides: ${ocaml:Provides}, and add ${perl: Depends} to the 
already-existing Depends field.

(I actually don't know why dpkg-gencontrol doesn't just fail the build instead 
of emitting a warning. Perhaps for backwards-compat or something.)

The rest of the package looks fine, except that I am not sure about installing 
everything in /usr/share/hol-light.

If hol-light allows itself to be used as an importable ocaml library for other 
programs and code, then it should be installed in /usr/lib/ocaml/hol-light - 
AFAIU extrapolating the (out-of-date) Debian Ocaml packaging policy. I am not 
sure our Debian ocaml toolchain will pick up libraries installed into 
/usr/share - and you will have to move it into /usr/lib anyway if the project 
eventually provides native shared libs, since /usr/share must only contain 
architecture-independent files.

It would be good if someone else from the team less new than me, could explain 
this issue properly and/or confirm what I'm suspecting here.

If there are good reasons for installing it in /usr/share/hol-light (which 
seems to be inconsistent with the packaging policy, as I mentioned) please 
describe them in debian/README.Debian. For example, I can see that upstream 
does not have a proper "make install" target for this stuff, and you specify 
/usr/share yourself in d/rules. So perhaps it is not supposed to be used by 
other ocaml code, and you include stuff in /usr/share merely "for reference". 
If that is correct, please add this explanation to the README.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#876533: hol-light FTBFS with OCaml 4.05.0

[Ximin Luo]

Hendrik Tews:
> Upstream does indeed fix this problem. However, it also contains
> a few files with unclear license and copyright, currently
> preventing to package it. I am trying to solve these license and
> copyright issues with upstream.
> 

Hi Hendrik, any progress on this? I notice in the ocaml transition tracker:

https://release.debian.org/transitions/html/ocaml.html

hol-light is one of the ones near the top, although marked (sid only) so it 
only affects other (sid only) stuff beneath it.

Let me know if I can help with anything.

Ximin

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#879905: glee: source for GLee.c and GLee.h is missing

[Ximin Luo]

Steve Cotton:
> Source: glee
> Severity: serious
> Justification: missing source (GLeeGen), missing source (GL ext specs)
> 
> GLee already has serious bug #879123, and the auto-removal email
> for dependencies was sent this morning. Most of the discussion in
> #879123 looks as if a .dsfg tarball would just need to remove the
> configure file, I'm logging a new bug so that this doesn't get
> missed:
> 
> On Thu, 19 Oct 2017 22:47:00, Ximin Luo wrote:
>> Unfortunately we have a bigger problem:
>>
>> -rwxrwxr-x   1,105,245   GLee.c
>> -rwxrwxr-x   955,258 GLee.h
>>
>> * [This file was automatically generated by GLeeGen 7.0
>>
>> These files are clearly not source code. But luckily it should
>> be possible to regenerate them from the git repo I mentioned:
>>
>>> [..] https://github.com/kallisti5/glee
> 
> It seems that repo is also not the complete source, the build
> steps in CMakeLists.txt download specs for the GL extensions from
> http://www.opengl.org/registry/
> 
> The Readme.txt mentions a graball.bat, which no longer exists,
> but seems likely to have grabbed from the same place.
> 
> Steve
> 

Thanks for reporting yes. Looks like the previous discussion went on for almost 
the length of another ./configure file, without CCing me in the process, and 
ignored this much more serious issue.

I'd also like to reiterate my earlier point:

> To re-iterate my first point though, if in the future this issue crops up
> again, you need to supply evidence that ./configure is "preferred source of
> modification" because that contradicts all other experience of autotools 
> files.
> A git history log of the author hand-editing the file *more times* than
> regenerating the file from configure.ac would suffice.

And likewise for other generated text code like this C source code here.

I see some pedantry in the other bug report about "can modify". Obviously you 
"can modify" any file that exists on your computer, you can also modify ELF 
binaries in dirty binary hacks and "I've done this before" as well. (See 
/home/groups/reproducible/htdocs/patched-libs/libapt-inst.so.1.5.0.patched-xz 
on alioth). Source code is "*preferred*-form-of-modification", not 
"form-of-modification".

If one says something like this:

> I have worked with even more configure scripts and I also prefer modifying
> something else.

one already acknowledges that the "something else" is the source code, not the 
configure script.

Agreed that bug reports should be filed to other packages if they have similar 
problems. The packages I am responsible for, do not have this issue.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#879123: glee: source for configure is missing

[Ximin Luo]

Ximin Luo:
> On Thu, 19 Oct 2017 22:52:41 +0200 Markus Koschany <a...@debian.org> wrote:
>> [..]  The configure file is human readable and the preferred
>> source of modification in this case. Please also note that the author of
>> glee licensed his work under the more liberal BSD-2-clause license. You
>> cannot compare two very distinct issues like minified JS files and
>> automake files and claim consensus has been reached already.
>>
> 
> With respect, can you point to any concrete evidence of this configure file 
> being "the preferred source of modification"? It is definitely *not* the case 
> for *most* configure files of this type, so you need to supply some evidence 
> if you're going to argue yours is special.
> 

Unfortunately we have a bigger problem:

-   rwxrwxr-x   1,105,245   GLee.c
-   rwxrwxr-x   955,258 GLee.h

* [This file was automatically generated by GLeeGen 7.0

These files are clearly not source code. But luckily it should be possible to 
regenerate them from the git repo I mentioned:

> [..] https://github.com/kallisti5/glee
> 

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git