Bug#944039: ITP: docker-systemctl-replacement -- daemonless "systemctl" command to manage services without SystemD

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
Owner: Dmitry Smirnov 

   Package name: docker-systemctl-replacement
Version: 1.4.3424
Upstream Author: Guido U. Draheim
License: EUPL-1.2
URL: https://github.com/gdraheim/docker-systemctl-replacement
Vcs-Browser: https://salsa.debian.org/debian/docker-systemctl-replacement
Description: daemonless "systemctl" command to manage services without 
SystemD
 "systemctl" is a replacement command to control system daemons without
 SystemD. "systemctl" is useful in application containers where SystemD is
 not available to start/stop services.
 .
 This script can also be run as init of an application container (i.e. the
 main "CMD" on PID 1) where it will automatically bring up all enabled
 services in the "multi-user.target" and where it will reap all zombies
 from background processes in the container. When stopping such a container
 it will also bring down all configured services correctly before exit.


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

Re: Debian testing daily build - no kernel modules..!!!

[Geert Stappers]

On Sun, Nov 03, 2019 at 03:56:11AM +0100, André Verwijs wrote:
> 
> 
> 
> Debian testing daily build has no kernel modules..!!!


Reason is having booted kernel version Y
and in archive available kernel modules are for version X.

This does happen  during development.
 

> daily build: 10-21-2019 still good


Mmm, that is more then a week ago.

In that week there was another report about simular inconvinence.
That was concluded with "so you just caught a bad moment"
( https://lists.debian.org/debian-boot/2019/10/msg00273.html )
 
I'm not aware if did work in the time inbetween the reports.
(The Lonnie Cumberland report and the André Verwijs report)


Please see this message as an invention for either reporting
"works for me" or "next day retry also failed".


> Dank U - Thank You

U bedankt voor het melden - Thanking you for reporting


Groeten
Geert Stappers
-- 
Leven en laten leven

archive test rebuilds and reports for bullseye?

[Matthias Klose]

As part of general QA we did some test rebuilds during the last release cycle, 
and filing the ftbfs reports as RC issues.  Afaics there were no such test 
rebuilds and RC filing for bullseye after the release of buster.  People only 
have a limited amount of time, however it would be nice if these rebuilds would 
start again, maybe having that work done by more people than before.  I know I 
am a consumer of those test rebuilds as well, asking for comparative test 
rebuilds with new compiler versions, and lacking time to commit on regular test 
builds, otoh the lack of those is hurting.


Matthias

Bug#944057: ITP: libtest-randomresult-perl -- module to test that results of a running code look random

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtest-randomresult-perl
  Version : 0.001
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Test-RandomResult
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to test that results of a running code look random

Test::RandomResult is a test module that checks that the results of some code
look random.

Currently it does not check the distribution of the random results.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#944058: ITP: libcolor-rgb-util-perl -- set of utilities related to RGB colors

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libcolor-rgb-util-perl
  Version : 0.599
  Upstream Author : perlancar 
* URL : https://metacpan.org/release/Color-RGB-Util
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : set of utilities related to RGB colors

Color::RGB::Util provides routines for dealing with RGB colors.

Among others, functions are available to convert between strings and RGB
values, or integers and RGB values, to convert from RGB to other color
schemes, or to calculate color differences and distances.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: archive test rebuilds and reports for bullseye?

[Holger Levsen]

On Sun, Nov 03, 2019 at 03:14:38PM +0100, Matthias Klose wrote:
> As part of general QA we did some test rebuilds during the last release
> cycle, and filing the ftbfs reports as RC issues.  Afaics there were no such
> test rebuilds and RC filing for bullseye after the release of buster.

FWIW (and I mean that very literally), reproducible.debian.net does
continous rebuilds of experimental, sid and bullseye. And some people
even file bugs based on this.

(Contrary to some people's outdated beliefs) there are also no modified
packages involved. (We just test with usrmerge installed in one build
and not the other. And with the other (legit) variations described in
https://tests.reproducible-builds.org/debian/index_variations.html )


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C



signature.asc
Description: PGP signature

Re: Integration with systemd

[Sam Hartman]

> "Svante" == Svante Signell  writes:
Svante> Marco, I think your information about elogind is not
Svante> up-to-date: https://tracker.debian.org/pkg/elogind

Svante> testing migrations: excuses: Migration status for elogind
Svante> (239.3+20190131-1+debian1 to 241.3-1+debian1): Will attempt
Svante> migration (Any information below is purely informational)
Svante> Additional info: Updating elogind fixes old bugs: #939101
Svante> Piuparts tested OK -
Svante> https://piuparts.debian.org/sid/source/e/elogind.html 115
Svante> days old (needed 5 days)

Svante> Yes, 115 days old...

So, that's a bit misleading.
The last RC bug was closed the last week in October.
Yes, the process took longer than several of us wish it did.
However, the 105 days is definitely misleadingly long.

Mark has looked into why elogind still hasn't migrated.

Re: RFC: How about using MRs to communicate the diffs for NMUs with an MR

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Thu 31 Oct 2019 at 12:00PM +01, Gert Wollny wrote:

>> "Then, you either prepare the NMU in a fork of the original
>> packaging repository and submit a merge request referencing the
>> bug you are fixing, or send a patch containing the differences
>> between the current package and your proposed NMU to the BTS."

Sean> I'd like to suggest that the nmudiff in the BTS remain the
Sean> method mentioned first, and then you could append "... or if
Sean> the maintainer has enabled MRs for their repo and your changes
Sean> are based on that repo, you can submit a MR instead."

What sean proposes is consistent with our consensus in Git Packaging
Round 1.
In particular, in that discussion round, we concluded that when
maintainers have enabled MRs on their repository, that's a reasonable
way to communicate changes to them.
The BTS always remains a reasonable way to communicate changes as well.

I guess you're expanding that slightly by expanding to cover NMUs
specifically.
However, NMUs are such a common class of change, I think we were all
considering that as a possibility when we had that discussion.

I think it would be great to get this documented.

--Sam

Re: Facilitating external repositories

[Wouter Verhelst]

So, in 2015 I wrote:

> Hi,
> 
> At $DAYJOB, I'm maintaining a few repositories with ready-to-install
> packages for a number of distributions[1]
> 
> Currently, the instructions[2] say to do the following:
> - Download and install an "eid-archive" package, which contains the GPG
>   keys and generates a sources.list.d file for the repository;
> - Run "apt-get update";
> - Install the "eid-mw" and/or "eid-viewer" packages.
> 
> This works, but it has a number of downsides:
> - The second step, "run apt-get update", is often overlooked; this seems
>   to be the case especially for users of Ubuntu, where the default
>   handler for installing packages is the "Software Center", a GUI
>   software management tool that doesn't have any UI element for doing
>   (the equivalent of) apt-get update
> - There is no trust path from your already-installed distribution to the
>   "archive" package (yes, I did sign the gpg keys; no, I don't consider
>   that enough).
> - It still requires users to manually install packages.
> 
> I note that other third-party developers often provide a single debian
> package that can be installed, where the binary package itself already
> contains repository configuration that gets installed. This method
> works for application software, but (as in my case) if the intent is to
> provide a library that wants to support multiarch, this approach doesn't
> work.
> 
> There is add-apt-repository, which presumably works, but:
> - It doesn't solve the "trust path" issue for third-party repositories,
>   (except, *maybe*, for PPA's, but that's Ubuntu, not Debian, so doesn't
>   solve my problem)
> - It doesn't remove the "manually install" requirement
> - I don't believe it solves the "user didn't do the apt-get update"
>   step, although I haven't checked in detail.
> 
> Do we have anything better, or should I try to come up with something
> myself?
> 
> [1] specifically, https://files.eid.belgum.be/
> [2] http://eid.belgium.be/en/using_your_eid/installing_the_eid_software/linux/

This caused a bit of discussion at the time, but no real implementation. Until
now.

I spent some time earlier this week to write, as a proof-of-concept,
, which contains two repositories:

- The first contains an "extrepo" package, that hasn't been uploaded yet
  (and will probably need some more work before that can happen)
- The "extrepo-data" repository contains some YAML files that can be
  consumed by the first package.

The idea would be that maintainers of third-party repositories (or other
interested parties) can file a merge request to add metadata for their
repository to the index file. When, after proper vetting of the
repository in question, the MR is accepted, that metadata then gets
slightly mangled and signed with a GPG key, then published on
pages.debian.net (or somewhere else, if necessary).

The software from the package downloads the metadata index and validates
the GPG signature; and if everything checks out, adds configuration to
/etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
repository.

(I could also update the "add-apt-repository" program from the
software-properties-common package, and I might do so if this turns out
to be a success; but for a proof-of-concept that seems premature).

Does this seem like a particularly bad idea to anyone?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: archive test rebuilds and reports for bullseye?

[Matthias Klose]

On 03.11.19 16:24, Holger Levsen wrote:

On Sun, Nov 03, 2019 at 03:14:38PM +0100, Matthias Klose wrote:

As part of general QA we did some test rebuilds during the last release
cycle, and filing the ftbfs reports as RC issues.  Afaics there were no such
test rebuilds and RC filing for bullseye after the release of buster.


FWIW (and I mean that very literally), reproducible.debian.net does
continous rebuilds of experimental, sid and bullseye. And some people
even file bugs based on this.

(Contrary to some people's outdated beliefs) there are also no modified
packages involved. (We just test with usrmerge installed in one build
and not the other. And with the other (legit) variations described in
https://tests.reproducible-builds.org/debian/index_variations.html )


it would be nice to make this information more exposed, especially because you 
are covering four architectures, and not just one which is usually rebuilt for a 
test rebuild in Debian.


Now looking at

  https://tracker.debian.org/pkg/linbox
  https://tracker.debian.org/pkg/python-xarray

I have difficulties finding a build log showing the build failure. The link to 
the tracker leads to a page with (for me) non-obvious information.  For the 
purpose of tracking build failures I'd like to see a direct link to a build log 
of a failing build on tracker.debian.org, however even looking at


https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/linbox.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-xarray.html

I have difficulties finding the log of the failed build. Also please note that 
the linbox ftbfs is non-amd64, so the tracker link is misleading.


It would also be nice to generate a list of

 

for builds that ftbfs and don't have any RC issues yet in the BTS, so that could 
be used for QA people to file not-yet-filed ftbfs issues.


For comparative test rebuilds, would it be possible to add another configuration 
(you already have experimental, sid, ...) to use a new GCC version?  I assume 
the LLVM maintainers also would be interested to test the LLVM toolchain the 
same way.


Matthias

Re: Bug#944039: ITP: docker-systemctl-replacement -- daemonless "systemctl" command to manage services without SystemD

[Andrei POPESCU]

On Du, 03 nov 19, 19:33:59, Dmitry Smirnov wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> Owner: Dmitry Smirnov 
> 
>Package name: docker-systemctl-replacement
> Version: 1.4.3424
> Upstream Author: Guido U. Draheim
> License: EUPL-1.2
> URL: https://github.com/gdraheim/docker-systemctl-replacement
> Vcs-Browser: https://salsa.debian.org/debian/docker-systemctl-replacement
> Description: daemonless "systemctl" command to manage services without 
> SystemD
>  "systemctl" is a replacement command to control system daemons without
>  SystemD. "systemctl" is useful in application containers where SystemD is
>  not available to start/stop services.
>  .
>  This script can also be run as init of an application container (i.e. the
>  main "CMD" on PID 1) where it will automatically bring up all enabled
>  services in the "multi-user.target" and where it will reap all zombies
>  from background processes in the container. When stopping such a container
>  it will also bring down all configured services correctly before exit.

s/SystemD/systemd :)

See https://www.freedesktop.org/wiki/Software/systemd (currently down 
for me).

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Facilitating external repositories

[Timo Weingärtner]

Hallo Wouter Verhelst,

03.11.19 18:35 Wouter Verhelst:
> The software from the package downloads the metadata index and validates
> the GPG signature; and if everything checks out, adds configuration to
> /etc/apt/sources.list.d and /etc/apt/trusted.gpg.d to enable the
> repository.

Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key is in 
there its owner can impersonate the official debian repos for default setups.¹ 
Please use some other path (such as /var/lib/extrepo/keyrings/) for the 
keyrings and connect it with "Signed-By:" [1].

I just changed my /etc/apt/sources.list.d/debian.sources to have:
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg


Grüße
Timo

¹ there are still other attack vectors as soon as you install a package from 
such a repo
[1] sources.list(5)

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

Re: Facilitating external repositories

[Russ Allbery]

Timo Weingärtner  writes:

> Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key
> is in there its owner can impersonate the official debian repos for
> default setups.¹ Please use some other path (such as
> /var/lib/extrepo/keyrings/) for the keyrings and connect it with
> "Signed-By:" [1].

> I just changed my /etc/apt/sources.list.d/debian.sources to have:
> Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

I have a personal repository and a corresponding eyrie-archive-keyring
package to install the trusted keys.  Is there a best practice document
somewhere for how I should set this up?  I'm currently installing keyrings
in /etc/apt/trusted.gpg.d because I thought that was how *-archive-keyring
packages were supposed to work, but this area seems a bit underdocumented
(or at least I've not found the right documentation).

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

Re: Integration with systemd

[Wouter Verhelst]

On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> http://www.islinuxaboutchoice.com/

https://grep.be/blog/en/computer/cluebat/Systemd__Devuan__and_Debian/

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

RFA: several packages around Kodi

[Bálint Réczey]

Hi All,

These packages are maintained officially by the Multimedia Team, but
I'm the only uploader for them:

crystalhd
forked-daapd
kodi-pvr-argustv
kodi-pvr-dvbviewer
kodi-pvr-hdhomerun
kodi-pvr-iptvsimple
kodi-pvr-mediaportal-tvserver
kodi-pvr-mythtv
kodi-pvr-nextpvr
kodi-pvr-njoy
kodi-pvr-vuplus
kodi-pvr-wmc
libshairport

The Kodi plugins will need to be updated for the new Kodi release, but
despite the kodi package being ready for upload since March I could
not upload it because build dependencies are not available yet in the
archive. (While I pushed them as far as I could as a DD.)

In general the packages are in a good shape and I'd like to find
people who would step up as uploaders replacing me. I have already
written an RFA email [1] to the team mailing list but got no response,
maybe there are people in this wider audience who are interested in
the packages listed above.

Cheers,
Balint

PS: I added a comment to #895917 before sending this email to
debian-devel, see [2].

[1] https://lists.debian.org/debian-multimedia/2019/01/msg00013.html
[2] https://balintreczey.hu/blog/my-debian-devel-pledge

Perhaps we're rehashed enough of the systemd discussions?

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
>> http://www.islinuxaboutchoice.com/

Wouter> 
https://grep.be/blog/en/computer/cluebat/Systemd__Devuan__and_Debian/

Wouter> -- To the thief who stole my anti-depressants: I hope you're
Wouter> happy

Hi.  We've received a lot of feedback about the negative costs of long
threads here.
I think that some aspects of the discussion were necessary and
inevitable.
It sounds like the discussion has helped some people understand why a GR
might be a good idea.
It has helped me sanity check whether I was including issues important
to the project.

I think that we'll need to discuss a few other things once again when
draft GR text comes out (although that will be on debian-vote).

But as someone charged with helping try to facilitate discussions within
the project, I think this particular set of related threads have reached
the point of diminishing returns on debian-devel for now.
If there's some last message you absolutely have to send, get that *one
last message* out of your system.
But let's be almost done, out of respect for everyone who has had this
discussion before and out of the many people who have talked about the
costs of relatively long threads like this.

Thanks for considering,

--Sam

Re: Facilitating external repositories

[Guillem Jover]

On Sun, 2019-11-03 at 11:04:01 -0800, Russ Allbery wrote:
> Timo Weingärtner  writes:
> > Please don't use /etc/apt/trusted* for 3rd-party repositories. If a key
> > is in there its owner can impersonate the official debian repos for
> > default setups.¹ Please use some other path (such as
> > /var/lib/extrepo/keyrings/) for the keyrings and connect it with
> > "Signed-By:" [1].
> 
> > I just changed my /etc/apt/sources.list.d/debian.sources to have:
> > Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
> 
> I have a personal repository and a corresponding eyrie-archive-keyring
> package to install the trusted keys.  Is there a best practice document
> somewhere for how I should set this up?

I don't think there is. The closest seems to be
, which is not
covering acrhive-keyring packages. Personally I think I've been
picking up this things from following closely apt's development and
having to deal with a couple of these archive-keyring packages.

> I'm currently installing keyrings
> in /etc/apt/trusted.gpg.d because I thought that was how *-archive-keyring
> packages were supposed to work, but this area seems a bit underdocumented
> (or at least I've not found the right documentation).

The official archive-keyring packages that use these, I think it's mostly
for backwards compatibility reasons.

I'd say best practice is to ship keyrings under /usr/share/keyrings/,
and not under /etc/apt/trusted.gpg.d/. Split the keys into keyrings
that will not give more access than necessary. Use «Signed-By:» if you
ship source list files. And personally I ship those in deb822 format,
because they are easier to read and deal with automatically, and make
it easy to disable them after the fact, or even ship them disabled by
default with the «Enabled: no» field.

Thanks,
Guillem

Bug#944085: ITP: ocaml-uchar -- Compatibility library for OCaml's Uchar module

[Andy Li]

Package: wnpp
Severity: wishlist
Owner: Andy Li 

* Package name: ocaml-uchar
  Version : 0.0.2
  Upstream Author : Daniel Bünzli 
* URL : https://github.com/ocaml/uchar
* License : LGPL with OCaml-linking exception
  Programming Lang: OCaml
  Description : Compatibility library for OCaml's Uchar module

The uchar package provides a compatibility library for the Uchar module
introduced in OCaml 4.03.

It is effectively an empty package with only metadata for ocamlfind to resolve 
"uchar", which is used by sedlex 2.1.

Re: Facilitating external repositories

[Paul Wise]

On Mon, Nov 4, 2019 at 4:52 AM Guillem Jover  wrote:

> The official archive-keyring packages that use these, I think it's mostly
> for backwards compatibility reasons.

I wonder if it is feasible to and how the debian-archive-keyring could
migrate from /etc/apt/trusted.gpg.d/ to /usr/share/keyrings/ +
signed-by. Right now it ships keyrings in both places.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#944087: RFP: crun -- lightweight OCI runtime for running containers

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org d...@fragfest.com.au
Owner: Dmitry Smirnov 

   Package name: crun
Version: 0.10.4
Upstream Author: Giuseppe Scrivano 
License: (L)GPL-3+
URL: https://github.com/containers/crun
Vcs-Browser: https://salsa.debian.org/debian/crun
Description: lightweight OCI runtime for running containers
 Fast and low-memory footprint OCI Container Runtime fully written in C.


Finally, an app container runtime not written in Golang. :)


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

Re: Perhaps we're rehashed enough of the systemd discussions?

[Wouter Verhelst]

On Sun, Nov 03, 2019 at 03:26:40PM -0500, Sam Hartman wrote:
> > "Wouter" == Wouter Verhelst  writes:
> 
> Wouter> On Thu, Oct 31, 2019 at 03:45:47PM +0100, Marco d'Itri wrote:
> >> http://www.islinuxaboutchoice.com/
> 
> Wouter> 
> https://grep.be/blog/en/computer/cluebat/Systemd__Devuan__and_Debian/
> 
> Wouter> -- To the thief who stole my anti-depressants: I hope you're
> Wouter> happy
> 
> Hi.  We've received a lot of feedback about the negative costs of long
> threads here.

Yes.

[...]
> But as someone charged with helping try to facilitate discussions within
> the project, I think this particular set of related threads have reached
> the point of diminishing returns on debian-devel for now.
> If there's some last message you absolutely have to send, get that *one
> last message* out of your system.
> But let's be almost done, out of respect for everyone who has had this
> discussion before and out of the many people who have talked about the
> costs of relatively long threads like this.

I wasn't going to reply to this at first, but...

I'm not sure if you replying to my particular email has any
significance. But if it does, I think that's pretty terribly bad of you.

I replied exactly twice to this whole thread: once to ask you to *not*
prepare a GR proposal in private, *precicely because* announcing you're
going to propose a GR but not actually (yet) doing so has in the past
led to long and very much not productive threads about the general
subject the almost-proposed GR is about. You declined, for reasons that
I didn't agree with (but didn't feel strongly enough about to argue to
death). A second reply was the above one, to point out a particularly
bad style of "argument", of pointing to a URL that kindof okayishly
defends the way one of our competing distributions works, but doesn't
(at least in my opinion) match up with Debian's traditions very well. I
happen to believe that using a bad style of argument in an already-long
thread is not very productive, and I wanted to point that out in a short
and simple way.

So now that you've seen that your actions have caused a huge and
inproductive thread, rather than owning up to that and just doing the
right thing, you're pointing fingers and telling *me* that I'm making a
bad situation worse?

Srsly. Yes, the DPL is supposed to "lead discussion", but no, you do
*not* do that by telling people to shut up when they're just reacting to
*your* mistakes.

Thanks for considering.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard