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
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: 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
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
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
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
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
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
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
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
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: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
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
Package: grub-pc-bin
Version: 2.02~beta3-4
Followup-For: Bug #741464
Hi, I have just been hit by this on a new computer, Intel z170 chipset with
i5-6600K processor. I am using a custom GRUB config, however none of that
matters since it is the first line "terminal_input at_keyboard" that is causi
Package: rollup
Version: 0.38.0-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
Thanks for packaging rollup. However, it doesn't work at the moment:
$ rollup -c
[TypeError: Cannot read property 'id' of undefined]
However this works:
$ NODE_PATH=xxx/rollup/node_module
James McCoy:
> On Mon, Mar 06, 2017 at 11:45:20PM -0500, James McCoy wrote:
>> On Thu, Feb 16, 2017 at 05:23:00PM +0000, Ximin Luo wrote:
>>> I've done an initial implementation here:
>>>
>>> https://anonscm.debian.org/cgit/collab-maint/devscripts.git/l
Mattia Rizzolo:
> On Fri, Mar 18, 2016 at 10:49:31PM +0100, Ximin Luo wrote:
>> Hi, looks like upstream is active again after several years and is
>> planning a new 0.8.0 release. This issue has already been filed as
>> a bug report,
>
> This bug has been fixed upstr
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
Control: close -1
Closing, not a bug.
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
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
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
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
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
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: 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: notfound -1 5.4.1-1
--
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
Control: fixed 0.10-1
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
Control: fixed -1 0.10-1
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
Subject: jessie-pu: package mozilla-gnome-keyring/0.6.11-3
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: jessie
Severity: normal
Hi release team,
I just uploaded a rebuild of the version of mozilla-gnome-keyring currently in
testing (0.10-1~deb8u1)
Looks like I sent this to the wrong place, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797179
for the corrected location.
--
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git
Control: tags -1 + pending
Control: fixed -1 1.14.0+dfsg1-3
Hi, this is already fixed in git. I'm just waiting for a sponsored upload
because my key expired and I forgot to push the updated version to Debian's
keyring last month.
X
Emilio Pozuelo Monfort:
> Source: rustc
> Version: 1.14.0+dfsg
Control: reassign -1 python-sphinx 1.4.9-1
Control: affects -1 checkbox-ng dhcpcanon ipywidgets nbsphinx pylibmc
Control: close -1 python-sphinx 1.4.9-2
On Tue, 03 Jan 2017 22:09:00 + ju wrote:
> Niko Tyni:
> >
> > Seems to be https://github.com/sphinx-doc/sphinx/issues/3212
> > which should
close 849216 1.4.9-2
thanks
close 850333
thanks
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
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
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
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
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
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
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
Package: r-cran-randomfields
Version: 3.1.36-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
This package FTBFS against r-base 3.4.0-1 which was uploaded to unstable
recently.
[..]
make[1]: Leaving directory '/<>/src'
make[1]: E
Control: reassign -1 r-base
Control: forcemerge 861333 -1
Hey Andreas, I was told that this is a r-base issue, not an issue with
r-cran-randomfields, and it is already being discussed in 861333.
Ximin
Andreas Tille:
> tags 861684 sid
> thanks
>
> I'm tagging this sid since it is not relevant f
Hey all,
Indeed, jmol in unstable is still version 12. If biojava4-live 4.2.4 is
supposed to work with 14, that would be the problem.
I will upload jmol 14 to unstable in the next 2-3 hours, you can try it again
with that. Perhaps it would already solve this FTBFS.
X
olivier sallou:
> Le mar.
I still haven't managed to reproduce this myself but I'll just note for the
record we have seen this on jenkins before:
https://jenkins.debian.net/job/reproducible_diffoscope_from_git_master/63/console
Santiago Vila:
> Package: src:diffoscope
> Version: 63
> Severity: serious
>
> Hello folks.
>
Control: reassign -1 jupyter-notebook 4.2.3-2
Control: severity -1 normal
Control: close -1 4.2.3-3
Control: merge -1 847917
Hi Norbert, this is due to a bug in jupyter-notebook 4.2.3-2. You can fix it
locally by removing any empty files matching /etc/jupyter/nbconfig/*.json, then
reinstalling/r
Chris Lamb:
> Ximin Luo wrote:
>
>> I still haven't managed to reproduce this myself but I'll just note
>> for the record we have seen this on jenkins before
>
> My guess is that one of the third-party Python extension modules that
> we import does not corre
Hi, the attached patch fixes *some* of the issues.
- sqlparse 0.2 changed is_whitespace into a property
- token_next now returns a (idx, token) tuple instead of just the token
However I am now getting these errors:
# journalctl _SYSTEMD_UNIT=calendarserver.service | tail
Jan 03 17:25:31 pdeb1 c
Hi Chris, I can't reproduce this, even when setting the locale to various
non-UTF values. How are you building this?
X
Chris Lamb:
> Source: sagenb-export
> Version: 2.0-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Userta
I think I narrowed it down, could you try the build again with
LC_CTYPE="C.UTF-8" and see how it works?
X
Chris Lamb:
> Ximin Luo wrote:
>
>> I can't reproduce this, even when setting the locale to various non-UTF
>> values
>
> Not sure why you we
will wait for the upstreams to pick the solutions I proposed.
In the meantime, I will work around this FTBFS by overriding LC_CTYPE specially
for the tests.
X
Ximin Luo:
> I think I narrowed it down, could you try the build again with
> LC_CTYPE="C.UTF-8" and see how it works?
&
Package: glibc
Version: 2.24-7
Severity: serious
Tags: patch
Justification: fails to build from source (but built successfully in the past)
Dear Maintainer,
whilst trying to build glibc:
/usr/bin/install -c -m 644
/tmp/debrepro.uGH5xEsmL1/build/source/build-tree/amd64-libc/gnu/lib-names-64.h
/
Hello jquery maintainer,
This was partially my "fault", I asked requirejs to fix bug #845158 and they
did, but of course other packages in Debian would still be using the old name.
Upstream says require('requirejs')
http://requirejs.org/docs/node.html
Here is the new file list:
https://packages
Package: tachyon-bin-nox
Version: 0.99~b6+dsx-6
Severity: grave
Tags: patch
Justification: renders package unusable
Dear Maintainer,
This package is missing either a direct or indirect dependency libmpich12:
(unstable-amd64-sbuild)infinity0:/build/sagemath-fBCYuv/sagemath-7.4$
tachyon-nox
tachy
Control: reassign -1 libtachyon-mpich-0
Control: affects -1 tachyon-bin-nox
Control: affects -1 tachyon-bin-ogl
Note that the problem occurs only when you install libtachyon-mpich-0. (For
some reason, that is what sbuild chose to satisfy sage's "tachyon" dependency.
Probably I should remove my w
Stéphane Glondu:
> On 22/07/2017 19:48, Ximin Luo wrote:
>> Sadly we now have one new failure, on arm64:
>>
>> https://buildd.debian.org/status/fetch.php?pkg=ocaml&arch=arm64&ver=4.05.0-5&stamp=1500739972&raw=0
>>
>> E: Build killed with signa
Package: diffoscope
Version: 67
Severity: grave
Tags: patch security
Justification: user security hole
Dear Maintainer,
5fdfe91e71f1c520d902350b18f793b8c69d9118 introduced a security hole where
diffoscope may write to arbitrary locations on disk depending on the contents
of an untrusted archive.
Chris Lamb:
> tags 854723 + pending
> thanks
>
>> diffoscope may write to arbitrary locations on disk depending on the contents
>> of an untrusted archive
>
> We can actually avoid all edge-cases of sanitisation by simply not using
> the supplied filename and maintaining our own mapping.
>
> Giv
Ximin Luo:
> Chris Lamb:
>> tags 854723 + pending
>> thanks
>>
>>> diffoscope may write to arbitrary locations on disk depending on the
>>> contents
>>> of an untrusted archive
>>
>> We can actually avoid all edge-cases of sanitisation
Adrian Bunk:
> ... testing 'quicksort2':/usr/bin/ld: quicksort2.o: relocation
> R_ARM_THM_MOVW_ABS_NC against `cmp' can not be used when making a shared
> object; recompile with -fPIC
> quicksort2.o: error adding symbols: Bad value
> collect2: error: ld returned 1 exit status
> => failed
> ...
Ximin Luo:
> Adrian Bunk:
>> ... testing 'quicksort2':/usr/bin/ld: quicksort2.o: relocation
>> R_ARM_THM_MOVW_ABS_NC against `cmp' can not be used when making a shared
>> object; recompile with -fPIC
>> quicksort2.o: error adding symbols: Bad value
>
Ximin Luo:
> Ximin Luo:
>>
>> It's possible OCaml itself is to blame:
>>
>> asmcomp/arm/emit.mlp:
>> if nh = 0l then begin
>> ` movw{emit_reg dst}, #{emit_int32 nl}\n`; 1
>> end else if Int32.logand nl 0xffl = n
Riku Voipio:
> Package: ocamlbuild
> Version: 0.9.3-3
> Severity: grave
> Tags: experimental
>
> ocamlbuild is failing to build since ocaml-best-compilers is a virtual
> package:
>
> https://buildd.debian.org/status/package.php?p=ocamlbuild&suite=experimental
>
Hey Riku, see the discussion sta
Tobias Hansen:
> [..]>
>
> Hi,
>
> good work on finding the fpylll issue! Now the main holdup for sage 8.0
> is still cypari2 being stuck in NEW. I wrote on June 21 to
> ftpmas...@debian.org and August 2 directly to the ftpmaster who helped
> us get sagemath through NEW in time for stretch. Let'
Control: block 870688 by 869778
Control: affects 869778 + sagemath
Ximin Luo:
> Tobias Hansen:
>> [..]
>>
>> The accidental upload of cysignals 1.6.5 to unstable is now a RC bug
>> (#870688). Not sure if we should fix it by downgrading cysignals,
>> patching sage
-#869778
Ximin Luo:
> [..]
>
> Hi, I see that libgsl23 was uploaded but who is taking care of the library
> transition? It seems that this process was not followed:
> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>
> The transition tracker detected the li
Ximin Luo:
> -#869778
>
> Ximin Luo:
>> [..]
>>
>> Hi, I see that libgsl23 was uploaded but who is taking care of the library
>> transition? It seems that this process was not followed:
>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions
>>
&
a9ea22e23a8036d24274ec6fffd2e2386d3937a6
Author: Ximin Luo
Date: Wed Aug 9 14:40:06 2017 +0200
Prepare for uploading to unstable
diff --git a/debian/changelog b/debian/changelog
index 305bcec..f300629 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,13 @@
ipywidgets (6.0.0-2) UNRELEASED
Ralf Treinen:
> Hi Chris,
>
> On Sun, Oct 23, 2016 at 09:00:09AM +0100, Chris Lamb wrote:
>
>> ocamldsort fails to build from source in unstable/amd64:
>
> it compiles with ocaml 4.03.0 from experimental.
>
Hi all,
I have been trying to transition ocaml before the Nov 5 deadline but atm it is
Control: reassign -1 src:node-d3-format
Hi, I am the maintainer of the first d3-format package which does not use npm
as Build-Depends. It also provides a libjs-d3-format package separate from
node. I have just taken back this binary package name, so re-assigning this bug
report to the proper s
Pirate Praveen:
> On ചൊവ്വ 10 ഒക്ടോബര് 2017 06:08 വൈകു, Ximin Luo wrote:
>> I will also file a RM request later to remove node-d3-format, since it
>> shouldn't have been accepted into Debian in the first place. Please do your
>> research properly next time before fi
Pirate Praveen:
> On Tue, 10 Oct 2017 15:23:00 +0000 Ximin Luo wrote:
>> I was following https://wiki.debian.org/Javascript/Policy
>
> The top of the page says "This document is still work in progress.'
>
> Anyway, I have started a thread in pkg-javascript-devel
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 license. You
> cannot compare two very di
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
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
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
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
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
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
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: 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
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
close 998345
thanks
See my previous message.
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.
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
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
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
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
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: 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 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: 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
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: 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
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
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:
>> 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
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:
> [..]
>
> 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
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
1 - 100 of 230 matches
Mail list logo
