Re: Help to ship a better rsync on Buster

2019-01-02 Thread Boyuan Yang
Hi, Looks like the new rsync 3.1.3-1 was uploaded yesterday. Thank you all for the work (and we may have a better rsync in Buster)! -- Regards, Boyuan Yang 在 2018-12-24一的 09:14 +0100,Paul Slootman写道: > Hi Samuel, > (replying above the message as it's all quite relevant but I don't have > anythin

Re: Proposal: Repository for fast-paced package backports

2019-01-02 Thread Charles Plessy
Hi Dominik, happy new year to you and everybody. I read your proposal, and the whole discussion with great interest. In brief, I think that it would be wise to uncouple the fast-paced ("fast-forwards" ?) repository that you propose from the stable backports, and I hope that you will be able to g

Nix and non-standard-toplevel-dir

2019-01-02 Thread Kai Harries
Dear Debian Developers and Maintainers, I have filled an ITP for the Nix package-manager [1]. During packaging lintian pointed out [2] that Nix relies on a non-standard-toplevel-dir. The Nix package-manager keeps by default all packages in the path `/nix/store`. In principal this path can be chan

Re: Nix and non-standard-toplevel-dir

2019-01-02 Thread Andrey Rahmatullin
On Wed, Jan 02, 2019 at 07:10:06PM +0100, Kai Harries wrote: > [4] https://nixos.org/~eelco/pubs/phd-thesis.pdf This is an interesting text. It shows that the author has read the FHS but chose to ignore it. The only ref to FHS is in the following text: """ For instance, storing components in an es

Re: Nix and non-standard-toplevel-dir

2019-01-02 Thread Chris Lamb
Hi Kai, > I have filled an ITP for the Nix package-manager [1]. As it happens, I did some work on this in early 2017: https://salsa.debian.org/lamby/pkg-nix .. but I ran out of bandwidth to persue it. I believe others on this list took up the challenge too. Regards, -- ,''`. :

Re: Nix and non-standard-toplevel-dir

2019-01-02 Thread Russ Allbery
Kai Harries writes: > I have filled an ITP for the Nix package-manager [1]. During packaging > lintian pointed out [2] that Nix relies on a non-standard-toplevel-dir. > The Nix package-manager keeps by default all packages in the path > `/nix/store`. In principal this path can be changed, but it

autopkgtest coupled with sbuild different from what is run on buildd?

2019-01-02 Thread Joseph Herlant
Hi guys, With one of my package (cmph), when I added debci tests, locally running autopkgtests using --run-autopkgtests in gbh that uses sbuild, I have no problem but when it runs on debci, it seems to miss packages (gcc at fist, now stdlibs, etc) or my local schroot has too many. I recreate my sc

Re: autopkgtest coupled with sbuild different from what is run on buildd?

2019-01-02 Thread Nicholas D Steeves
Hi Joseph, On Wed, Jan 02, 2019 at 12:53:32PM -0800, Joseph Herlant wrote: > Hi guys, > > With one of my package (cmph), when I added debci tests, locally > running autopkgtests using --run-autopkgtests in gbh that uses sbuild, > I have no problem but when it runs on debci, it seems to miss packa

Bug#918069: ITP: nitrocli -- Command-line interface for Nitrokey devices

2019-01-02 Thread Robin Krahl
Package: wnpp Severity: wishlist Owner: Robin Krahl * Package name: nitrocli Version : 0.2.0 Upstream Author : Daniel Mueller * URL : https://github.com/d-e-s-o/nitrocli * License : GPLv3 Programming Lang: Rust Description : Command-line interface for

Re: autopkgtest coupled with sbuild different from what is run on buildd?

2019-01-02 Thread Joseph Herlant
Hi Nicholas, On Wed, Jan 2, 2019 at 2:11 PM Nicholas D Steeves wrote: > Have you tried an LXC autopkgtest instance? I've noticed that > sometimes packages whose tests pass 100% of the time with a schroot > (buildd profile) will fail on debci, and the only way I've been able > to reproduce the fa

Re: autopkgtest coupled with sbuild different from what is run on buildd?

2019-01-02 Thread Simon McVittie
On Wed, 02 Jan 2019 at 12:53:32 -0800, Joseph Herlant wrote: > With one of my package (cmph), when I added debci tests, locally > running autopkgtests using --run-autopkgtests in gbh that uses sbuild sbuild --run-autopkgtests is a sbuild feature, not a debci or autopkgtest feature. It does not nec