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: apparmo
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:
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 cra
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
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/
-- Syst
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.
-- Syste
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.
close 998345
thanks
See my previous message.
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
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 mandator
close 997112 0.57.0-1
thanks
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
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 v
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 wr
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 t
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 a
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 the
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 ac
icy.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
>
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 fi
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
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/727441cc24d54d9a6623d52
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):
Fil
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
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.
ed 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
close 955764
version 0.43.1-1
thanks
-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 con
close 956266 1.42.0+dfsg1-1
thanks
close 947710
thanks
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 build
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 a
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 help
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 wou
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 eas
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
>> J
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 f
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, rend
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 de
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 +02
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 packag
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-ce
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 ecosyst
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 Packa
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 t
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 pac
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
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 genera
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 Deb
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 a
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 ht
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&arch=mips&ver=0.35.0-1&stamp=1559294265&raw=0
>> https://buildd.debian.org/status/fetch.php?pkg=cargo&ar
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
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
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/font
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, thank
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:
>
>> D
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
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
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]: En
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 f
Control: notfound -1 5.4.1-1
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
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
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 c
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&arch=amd64&ver=0.31.0-3&stamp=15
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::Stri
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 d
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
>> versio
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:/
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 earl
hat 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
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 ear
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 s
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 ha
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 mips
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
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 wi
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-nodro
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+pa
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://gi
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
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
> u
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 ti
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
Control: close -1
Closing, not a bug.
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
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 packag
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 tar
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 s
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
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
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
> fo
9307be893b783c97d91e65bec415e55c24f355e4
Author: Ximin Luo
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
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 wor
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/bugzill
ab9d454b584d6f702574db2ad61dee7b88eb942b
Author: Ximin Luo
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
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
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
> re
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 oca
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,24
Ximin Luo:
> On Thu, 19 Oct 2017 22:52:41 +0200 Markus Koschany 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 l
1 - 100 of 230 matches
Mail list logo
