On Tue, Apr 23, 2024 at 07:51:36AM +0200, Helmut Grohne wrote:
> Hi Matthias,
>
> On Mon, Apr 22, 2024 at 10:34:11PM +0200, Matthias Geiger wrote:
> > This is the same situation as in #1040477. This is an issue wrt how we
> > generate the semvers. I image rust-proc-macro-crate-1 would pose the
On Thu, Dec 07, 2023 at 01:02:58AM +, Peter Green wrote:
> On the one hand I'm not at all convinced this bug is rc, on the other
> hand I don't think shipping a four year old version of env-logger
> in the next release of Debian is a great idea.
>
> So I decided to look at the reverse
On Fri, Oct 27, 2023 at 07:55:07PM +0300, Adrian Bunk wrote:
> On Fri, Oct 27, 2023 at 05:07:12PM +0200, Fabian Grünbichler wrote:
> > On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote:
> > > Package: librust-env-logger-0.7+default-dev
> > > Severity:
On Wed, Oct 18, 2023 at 02:06:48PM +0300, Adrian Bunk wrote:
> Package: librust-env-logger-0.7+default-dev
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=mdevctl=arm64=1.2.0-4%2Bb3=1697626199=0
>
> ...
> Merged Build-Depends: ..., librust-env-logger+default-dev,
> ...
>
> Peter Green hat am 13.09.2023 05:24 CEST geschrieben:
> On 12/09/2023 23:30, Faidon Liambotis wrote:
> > Control: reassign -1 rustc 1.68.2+dfsg1-1
> > Control: retitle -1 Builds invalid wasm32 binaries (1.67->1.68 regression)
> >
> > On Tue, Sep 12, 2023 at 10:56:57PM +0100, Peter Green wrote:
On Sat, Jul 15, 2023 at 05:07:25PM +0200, Jonas Smedegaard wrote:
> Quoting Jonas Smedegaard (2023-07-15 09:55:04)
> > Quoting Fabian Grünbichler (2023-07-12 19:53:08)
> > > The feature in question is probably not a good candidate for packaging
> > > though, given the l
ebian/changelog
b/rust-async-std-1.12.0-patched/debian/changelog
index dfa43a8..5d6258f 100644
--- a/rust-async-std-1.12.0/debian/changelog
+++ b/rust-async-std-1.12.0-patched/debian/changelog
@@ -1,3 +1,9 @@
+rust-async-std (1.12.0-12.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ --
On Thu, Jul 06, 2023 at 04:39:08PM +0100, Peter Green wrote:
> > I'd be very interested in knowing what this self-conflict is supposed to
> > achieve.
>
> It is common upstream for there to be multiple semver-incompatible versions
> of each rust crate in use at a given time. Incompatibilities can
On Fri, Apr 28, 2023 at 08:42:07PM +0100, Peter Green wrote:
> On 28/04/2023 18:58, Fabian Grünbichler wrote:
> > I see no practical issue with 2 meaning we can't have multiple semver
> > suffix packages variants of a single crate installed - having the
> > unversioned
On Fri, Apr 28, 2023 at 07:58:35PM +0200, Fabian Grünbichler wrote:
> 2) if the "fork point" corresponds to the version in the soon-to-be-old
> stable release, and the semver suffix package is still in testing when
> that becomes the stable release (as then the unversioned packa
as reference, the (simplified) problematic combination:
rust-foobar in version X.Y.Z-A
ships librust-foobar-dev which provides librust-foobar-X-dev,
librust-foobar-X.Y-dev and librust-foobar-X.Y.Z-dev (all in version
X.Y.Z-A)
is what I call the "unversioned" package in the rest of this mail (it
Hi!
I extracted one of the failing tests and the corresponding gdb commands
so that you can more easily (and quicker) reproduce the issue:
https://salsa.debian.org/fg/rustc-gdb-1031745
instructions are contained within as well. changing the triggering
function (multiple_arguments) to either
Package: gdb
Version: 13.1-1
Severity: serious
Control: affects -1 src:rustc
Justification: breaks unrelated software
While preparing an update to rustc 1.65 for experimental, we noticed
that the recent gdb update in sid makes rustc FTBFS by causing 5 of its
gdb-integration test cases fail.
test
On May 1, 2022 7:28 pm, Peter Michael Green wrote:
>
> On 01/05/2022 14:00, Fabian Grünbichler wrote:
>> currently progress is blocked on
>> - itoa/serde_json transition (anybody working actively on that?)
>
> I just uploaded the new itoa to experimental and took
On April 20, 2022 11:39 am, Fabian Grünbichler wrote:
> On April 20, 2022 12:33 am, Peter Michael Green wrote:
>> Package: rust-h2
>> Version: 0.1.26-1
>> X-debbugs-cc: d...@jones.dk
>>
>> I noticed that Jonas had set a number of bugs about broken rust packag
On November 12, 2021 1:11 pm, Henry-Nicolas Tourneur wrote:
>
>
> Le ven 12 nov 2021 à 10:18, Fabian Grünbichler
> a écrit :
>> On November 12, 2021 6:38 am, Peter Green wrote:
>>> Package: rust-tokio-signal
>>> Version: 0.2.7-2
>>> Severit
On November 12, 2021 6:38 am, Peter Green wrote:
> Package: rust-tokio-signal
> Version: 0.2.7-2
> Severity: serious
>
> rust-tokio-signal (build-)depends on version 0.1 of rust-futures. Upstream
> seems to
> have abandoned the project, there was an alpha release supporting futures
> 0.2, but
>
On November 12, 2021 6:47 am, peter green wrote:
> In addition to the (build-)dependency on an old version of
> rust-crossbeam-queue,
> rust-tokio-process (build-)depends on version 0.1 of rust-futures. Upstream
> seems to
> have abandoned the crate, there was an alpha release supporting futures
On August 31, 2021 9:16 pm, Wolfgang Silbermayr wrote:
> On 8/31/21 4:25 PM, Bastian Germann wrote:
>> On Wed, 2 Dec 2020 02:46:36 + peter green wrote:
>>> > This will impact quite some other modules.
>>>
>>> I agree that the current autoremoval list looks pretty scary, so I decided
>>> to
On May 18, 2021 8:42 pm, Moritz Muehlenhoff wrote:
> Source: rust-hyper
> Severity: grave
> Tags: security
> X-Debbugs-Cc: Debian Security Team
>
> CVE-2021-21299:
> https://github.com/hyperium/hyper/security/advisories/GHSA-6hfq-h8hq-87mf
> https://rustsec.org/advisories/RUSTSEC-2021-0020.html
FWIW, this was reported upstream[0], and fixed[1], and released as part
of 1.5.0a. Either backporting the relevant changes from PR 434 or
updating to 1.5.0(a) seems like a good idea.
0: https://github.com/tmux-python/tmuxp/issues/433
1: https://github.com/tmux-python/tmuxp/pull/434
2:
Package: tmuxinator
Version: 0.12.0-1
Severity: serious
Justification: Policy 3.5
any tmuxinator command prints the following trace:
/usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require': cannot
load such file -- xdg (LoadError)
from
Package: zfs-test
Version: 0.7.9-2
Severity: serious
commit 2c29cd95fd0e5fccc035bf7dead27a4b73708f12 moved the following
files from zfsutils-linux to zfs-test, without updating zfs-test's
versioned Breaks+Replaces relation accordingly:
/sbin/ztest
the following files are now also installed in
On Mon, Dec 18, 2017 at 02:49:48PM +0100, Andreas Beckmann wrote:
> Source: zfs-linux
> Version: 0.7.3-3
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Hi,
>
> zfs-linux fails to build twice in a row. The first build succeeds, the
>
On Sun, Nov 05, 2017 at 03:18:57PM +0100, Andreas Beckmann wrote:
> Package: zfs-test
> Version: 0.7.3-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed
Package: openssh-server
Version: 1:7.4p1-1
Severity: critical
Tags: patch upstream
Commit b737e4d7433577403a31cff6614f6a1b0b5e22f4 disabled unix domain
socket forwarding when privsep is disabled. Unfortunately, privsep is
always "disabled" for the root user, so this completely broke unix
socket
On Wed, Nov 16, 2016 at 12:30:52PM +0100, Emmanuel Kasper wrote:
> On 11/15/2016 06:25 PM, Ben Hutchings wrote:
> > On Tue, 2016-11-15 at 15:33 +0100, Emmanuel Kasper wrote:
> >> The included patch disables read_only mounts when grub-mount is available.
> >
> > Why not require that grub-mount is
27 matches
Mail list logo
