Re: Help to ship a better rsync on Buster

[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
> anything specific to comment on)
> It's true that I have a lot less time nowadays than a couple of years
> ago to spend on Debian, unfortunately. This is becoming more and more
> obvious.
> Feel free to upload a new release with your changes. I'd like to still
> be to "official" maintainer, so I would like to review your stuff first.
> 
> Thanks for your work!
> 
> Paul
> 
> On Sun 23 Dec 2018, Samuel Henrique wrote:
> > It got to my attention the rsync is a little behind our standards wrt to
> > packaging and it looks like the maintainer doesn't have time to deal with
> > that at the moment.
> > 
> > Basically what I want to do is to upload the new release (along with some
> > packaging fixes), adding new Uploaders while keeping the original
> > Maintainer, or maybe moving it to a team while also keeping the original
> > maintainer.
> > 
> > The few changes that I already made:
> >  - Package the last release (which fixes a good amount of bugs and
> > security
> > issues)
> >  - Create a git repo on Salsa and use git for packaging [0]
> >  - Fix d/watch in order to be able to use uscan to download new releases
> > 
> > Things that I would like to have fixed, either for Buster or later:
> >  - Use debhelper with quilt instead of a complex d/rules that manually
> > apply patches
> >  - Use autopkgtests
> >  - Bug triage
> > 
> > I understand that as I'm not familiar with the rsync packaging, some of
> > the
> > things may have been a explicit maintainer choice with a rational behind
> > it, and that could be either spotted by a more experienced Debian
> > Developer, explained by Paul, or discovered when changing it.
> > 
> > Here are the points which leads me to think the maintainer might need help
> > with rsync:
> >  - Last upload of rsync from maintainer was almost 2 years ago
> >  - Last upload of maintainer (any package) was in March 2017
> >  - There were two NMUs after that
> >  - There is an open bug (#906895) since January asking for packaging of
> > the
> > new release, without replies from maintainer[1]
> >  - A lot of open bugs, 74 as of now.
> > 
> > On a side note, I can see that there was recent (August 2018) email
> > activity from Paul, so hopefully he may reply something about this.
> > 
> > Overall, I can see that rsync is not a simple package to deal with, Paul
> > having made a great job for many years all by himself, I would like to
> > receive help with that so we all can ship a better rsync on Buster :)
> > 
> > The transition freeze is for 12th January of 2019, so we would need to
> > upload this new release asap, in order to account for time to fix any RC
> > bug that may show up before the new release enters Testing. We can also
> > pick which changes we want to ship for Buster and which ones we want to
> > upload to experimental because we don't wanna risk introducing bugs that
> > close to the freeze.
> > 
> > Thanks,
> > 
> > [0]https://salsa.debian.org/debian/rsync
> > [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906895
> > 
> > 
> >  --
> > Samuel Henrique 


signature.asc
Description: This is a digitally signed message part

Re: Proposal: Repository for fast-paced package backports

[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 get support from the Debian
infrastructure for making it happen.

Thomas sent the link to the 2013 proposal on "Developer repositories for
Debian" (https://lists.debian.org/debian-devel/2013/05/msg00131.html),
which has a great potential.  If you have the resources for doing so,
how about sending a patch to the FTP team that would implement a
solution in line with this proposal ?  Debian support for this endeavor
might be possible though sposored developments such as the Google Summer
of Code or the Outreachy programs, for instance.  If the resulting work
is integrated, you would get an easy way to use the Debian
infrastructure for your goals, and if it is rejected, well, at least you
will be able to run it on your side, and it may be an asset for
experimenting or for operating through stable releases in the long run.

Regarding the details of your proposal, I have not seen keywords
regarding regression checks and reproducible builds.  These are powerful
tools that did not exist when the Debian Backports were invented.  Have
you considered utilising them ?  Perhaps it is too naive, but on my
side, for the leaf packages I maintain, I have always been dreaming of a
repository where I can just migrate a package from unstable (instead of
rebuilding) if there is sufficient evidence that it works flawlessly on
a Stable background.  Which may be why I am trying to convince you to
implemente "Developer repositories" (aka "PPAs" or "Bikesheds") for
solving your own problem :)

Have a nice day,

Charles

-- 
Charles Plessy  Tsurumi, Kanagawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Nix and non-standard-toplevel-dir

[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 changed, but it would make
it impossible to use pre-build binaries from the standard Nixpkgs
channels [3].

The problem are retained dependencies. A package keeps references to
a package it depends on. And this references contain the absolute
path (including `/nix/store`).

Section 5.5.3 and 6.1 of the PHD thesis "The Purely Functional
Software Deployment Model" [4] on which Nix is based gives some more
insight.

I would like your advise on how to proceed.

Thanks in advance.

Regards

Kai Harries

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877019
[2] https://github.com/KaiHa/nix-debian/issues/20
[3] https://nixos.org/nix/manual/#sec-building-source
[4] https://nixos.org/~eelco/pubs/phd-thesis.pdf

Re: Nix and non-standard-toplevel-dir

[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 essentially flat, rigid
“address space” of components is very different from the way software is 
typically stored
in most operating systems1

1
Indeed, no Linux distribution based on Nix will ever be compliant with the 
Linux Standards Base [82, 81]!
"""


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Nix and non-standard-toplevel-dir

[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,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: Nix and non-standard-toplevel-dir

[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 would make
> it impossible to use pre-build binaries from the standard Nixpkgs
> channels [3].

> The problem are retained dependencies. A package keeps references to
> a package it depends on. And this references contain the absolute
> path (including `/nix/store`).

> Section 5.5.3 and 6.1 of the PHD thesis "The Purely Functional
> Software Deployment Model" [4] on which Nix is based gives some more
> insight.

> I would like your advise on how to proceed.

I think this is a case where we should waive FHS for this package, due to
the unique nature of this package.

The top-level purpose of FHS is consistency on the system, partly for
other packages but primarily for the local systems administrator.  All
namespaces that aren't covered in FHS are implicitly reserved for the
local administrator, and they know that the distribution will use the FHS
directories for specific purposes and can set disk allocations, remote
mounts, and so forth accordingly.

Nix is effectively a completely different model and concept for how to lay
out software packages.  It's therefore not surprising that it doesn't
comply with the FHS, since it's not even trying to be the same sort of
system that the FHS anticipates.  It's an experiment with something new.

I think including the package manager in Debian, if possible, is a great
way to let Debian users experiment with some interesting concepts, and is
very much in line with our goals to be a universal operating system and to
provide a common basis for people to experiment and do interesting things.
Thank you for working on this!

I also don't think that anyone who installs and then uses the Nix package
manager is going to be surprised that it doesn't follow the FHS.  This is
pretty experimental stuff, and I doubt anyone is going to use it without
expecting it to be a bit weird.  If anything, they probably already know
how Nix works and are expecting it to use those paths.  There doesn't seem
to be much drawback in this carefully-chosen lack of compliance with the
FHS.

I don't think it's worth writing an explicit Policy exception for this,
since it's a single edge case.  Instead, I think it's a good use of a
Lintian override documenting what's going on.  Obviously, if Nix becomes
really popular in the long run, we can then go back and write this into
Policy.

-- 
Russ Allbery (r...@debian.org)   

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

[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 schroot but stil can't reproduce the issue locally.

So my question is:
* Is it expected to have build-essential installed on the sbuild
schroot but not on the deci one? (I'm guessing that's my problem but
I'd like to know if that's a known issue)
* do you know of any other dependencies differences that could occur
between running autopkgtests through sbuild and the autopkgtest
running on the debci servers?

My use case is that the package provides some short example programs
on how to use the library and I'm compiling and running them to check
that it runs fine.

Note: I apologize if that's already documented somewhere I didn't find.

Thanks for your help,
Joseph

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

[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 packages
> (gcc at fist, now stdlibs, etc) or my local schroot has too many. I
> recreate my schroot but stil can't reproduce the issue locally.
> 
> So my question is:
> * Is it expected to have build-essential installed on the sbuild
> schroot but not on the deci one? (I'm guessing that's my problem but
> I'd like to know if that's a known issue)
> * do you know of any other dependencies differences that could occur
> between running autopkgtests through sbuild and the autopkgtest
> running on the debci servers?
> 
> My use case is that the package provides some short example programs
> on how to use the library and I'm compiling and running them to check
> that it runs fine.
> 
> Note: I apologize if that's already documented somewhere I didn't find.
> 
> Thanks for your help,
> Joseph
> 

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 failure is with an LXC autopkgtest.

I will confess to not knowing why this is the case...but I've had
success with resolving failing tests in debci by debugging
LXC+autopkgtest failures.

Good luck, and I look forward to following this thread!
Happy New year,
Nicholas


signature.asc
Description: PGP signature

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

[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 Nitrokey devices

nitrocli provides a command-line interface for Nitrokey devices.
The Nitrokey Pro provides an OpenPGP smart card, one-time password
generation (HOTP and TOTP) and a password safe.  The Nitrokey Storage
additionally provides hardware-encrypted storage.

nitrocli’s functionality is similar to that of nitrokey-app, which is
already packaged for Debian.  Yet nitrokey-app has a Qt-based user
inface while nitrocli has a command-line interface.  nitrocli and
nitrokey-app are both based on libnitrokey.

I intend to package nitrocli within the Rust packaging team.


signature.asc
Description: PGP signature

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

[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 failure is with an LXC autopkgtest.
>
> I will confess to not knowing why this is the case...but I've had
> success with resolving failing tests in debci by debugging
> LXC+autopkgtest failures.

It indeed solved my issue. Thanks a lot!

I added a note in the sbuild documentation so that other people can
avoid loosing too much time it:
https://wiki.debian.org/sbuild?action=diff&rev2=159&rev1=158 . Feel
free to update it if you have more information.

In sbuild it makes sense that build-essential and fakeroot are always
present (explicitly added in
https://salsa.debian.org/debian/sbuild/blob/master/bin/sbuild-createchroot#L249)
as they are at the core of sbuild's primary usage and would have to be
reinstalled 99.9% of the time I'm guessing if we did omit them.

I didn't realize that debci was not relying on sbuild like buildd
does. I can see in the logs now that it's using lxc and if I think
about it, it's primary usage is to run tests, not to build packages so
it makes sense that it can do that without build-essential and
fakeroot always installed.
I just thought for some weird reason that debci was running along with
buildd which is not the case! :)

Anyway, thanks again for pointing me to the right direction! :)

Cheers,
Joseph

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

[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 necessarily match the autopkgtest backend or
configuration used in any other instance of autopkgtest.

> * Is it expected to have build-essential installed on the sbuild
> schroot but not on the deci one?

Yes. The production instance of debci on ci.debian.net uses lxc containers
and does not install build-essential in them unless asked to do so by
debian/tests/control.

(In principle it could also use qemu VMs or schroot containers, but
there's no reason to prefer schroot over lxc when lxc has already been
set up, and there haven't been enough resources so far to run qemu
for tests that declare the isolation-machine restriction: these are
currently skipped. For example, see the test results for nss-mdns or
systemd.)

> My use case is that the package provides some short example programs
> on how to use the library and I'm compiling and running them to check
> that it runs fine.

This is a good test to have, but it should depend on either build-essential
or the individual packages that it needs (gcc or g++, libc-dev, make).

smcv