On Tue, Jun 19, 2018 at 04:08:00AM +, Ximin Luo wrote:
> Josh Triplett:
> > While I *would* like to see support for version intervals, this
> > particular issue is a bug introduced through changes to debcargo. The
> > original debcargo intentionally generated versioned dependencies on
> >
+pkg-rust-maintainers, -901827 bug report
Josh Triplett:
>> I wrote:
>>> In the Debian Rust team, we previously experimented with e.g. converting:
>>>
>>> - Cargo dependencies X (>= 6, << 7) into dpkg dependencies X-6 | X-7
>>> - Cargo dependencies X (>= 6) into dpkg dependencies X-6 | X-7
Josh Triplett:
> [..]
>
> While I *would* like to see support for version intervals, this
> particular issue is a bug introduced through changes to debcargo. The
> original debcargo intentionally generated versioned dependencies on
> packages like librust-slab-0.3+default-dev rather than
>
On Mon, Jun 18, 2018 at 07:55:31PM -0700, Ximin Luo wrote:
> Package: dpkg
> Version: 1.19.0.5+b1
> Severity: wishlist
>
> Dear Maintainer,
>
> The Rust package manager Cargo, makes it possible to declare two-sided version
> constraint ranges such as X (>= 6, << 7). In dpkg, historically this
Ximin Luo:
> [..]
>
> librust-slab-0.1-dev_0.1.3-1_amd64.deb Provides: librust-slab+default-dev (=
> 0.1.3-1), librust-slab-0.1+default-dev (= 0.1.3-1), librust-slab-dev (=
> 0.1.3-1)
> librust-slab-0.3-dev_0.3.0-1_amd64.deb Provides: librust-slab+default-dev (=
> 0.3.0-1),
Package: dpkg
Version: 1.19.0.5+b1
Severity: wishlist
Dear Maintainer,
The Rust package manager Cargo, makes it possible to declare two-sided version
constraint ranges such as X (>= 6, << 7). In dpkg, historically this has been
expressed by declaring two one-sided version constraint ranges for
On Mon, Jun 18, 2018 at 08:19:17PM +0200, Julian Andres Klode wrote:
> Hi folks,
>
> With frontend locking in dpkg git, I think it's time I clear up
> some potential confusion as to how this is supposed to work in the
> APT world.
>
> The idea is that the current _system->Lock() /
Hi folks,
With frontend locking in dpkg git, I think it's time I clear up
some potential confusion as to how this is supposed to work in the
APT world.
The idea is that the current _system->Lock() / apt_pkg.SystemLock
/ apt_pkg.pkgsystem_lock() will start to manage _both_ lock-frontend
and lock,
Guillem Jover writes ("Re: Repository switch over to Salsa?"):
> Hey, so the migration is almost done, I need an account name and ssh
> public keys from both of you. I'll send another mail announcing the
> new setup.
On a tangent: I recently had cause to `dgit clone dpkg' and I was
disappointed
Hi!
On Sat, 2018-06-02 at 18:59:22 +0200, Sven Joachim wrote:
> On 2018-06-01 03:27 +0200, Guillem Jover wrote:
> > On Thu, 2018-05-31 at 18:20:35 +0200, Helge Kreutzmann wrote:
> >> On Fri, Feb 09, 2018 at 03:31:00AM +0100, Guillem Jover wrote:
> >> > On Sat, 2018-02-03 at 19:11:42 +0100, Helge
10 matches
Mail list logo
