Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?

2020-01-09 Thread Dominique Dumont
On Wednesday, 8 January 2020 20:42:45 CET Andreas Beckmann wrote:
> > I checked the piuparts documentation just then [2] and found out that
> > unlike ci.d.o or reproducible-build checks, the piuparts test will *not*
> > automatically be retried for the same package of the same version (same
> > upload).
> 
> Where is that written?

Boyuan Yang gave a link to debian wiki:

https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F

The answer mentions that package are not automatically retested. Whether this 
applies to package 
that passed or failed piupart test is not specified. I assumed the latter.

All the best




Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?

2020-01-09 Thread Paul Gevers
Hi Dod,

On 09-01-2020 09:17, Dominique Dumont wrote:
> https://wiki.debian.org/piuparts/FAQ#Q._Can_I_somehow_tell_piuparts_to_retest_my_package.3F
> 
> The answer mentions that package are not automatically retested. Whether this 
> applies to package 
> that passed or failed piupart test is not specified. I assumed the latter.

It says:
"""
Q. Can I somehow tell piuparts to retest my package?

A) Not automatically.
"""
I read that as: *you* can't tell it to retest. I don't read that as:
piuparts doesn't do retesting. It's a wiki though, you can improve the
text if it's unclear to you.

Paul




signature.asc
Description: OpenPGP digital signature


Re: [Piuparts-devel] Migration to testing blocked by broken piuparts?

2020-01-09 Thread Dominique Dumont
On Thursday, 9 January 2020 09:21:23 CET Paul Gevers wrote:
> It's a wiki though, you can improve the
> text if it's unclear to you.

:-) I was not sure to have the right answer.. 

Now that I've understood, I've updated the wiki. 

All the best





Bug#948483: RFP: broot -- an interactive CLI directory browser

2020-01-09 Thread Christian Kastner
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net

* Package name: broot
  Version : 0.11.2
  Upstream Author : Canop
* URL : https://dystroy.org/broot/
* License : MIT
  Programming Lang: Rust
  Description : an interactive CLI directory browser

broot is an interactive CLI directory browser that
 * can provide overviews of large directories
 * can navigate directories
 * enables shortcut operations

This package is similar to tree(1), with some helpful improvements.



Re: migration from cron.daily to systemd timers

2020-01-09 Thread Michael Stone

On Wed, Jan 08, 2020 at 07:12:17PM -0800, Russ Allbery wrote:

Michael Stone  writes:

On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:



This is the main reason I haven't switched to systemd timers for my
personal crontab, I have some jobs that generate output (diffs of
various things mostly) but don't fail. There doesn't appear to be any
tool to monitor a tool and send a mail if it generates output or fails,
in the way that cron does.



mail -E ?


Specifically:

   ExecStart=/bin/sh -c '/path/to/job | /usr/bin/mail -E'

in the service unit triggered by the timer unit should work, I think.
(I've not tested it.)


May need something like 

(job || echo Job failed) 2>&1 | mail -E 


or even

(job 2>&1 || echo Job failed) | tee /dev/stderr | mail -E

depending on the specific requirements, but in general this should be 
pretty straightforward




Re: migration from cron.daily to systemd timers

2020-01-09 Thread Michael Biebl
Am 09.01.20 um 13:08 schrieb Michael Stone:
> On Wed, Jan 08, 2020 at 07:12:17PM -0800, Russ Allbery wrote:
>> Michael Stone  writes:
>>> On Thu, Jan 09, 2020 at 02:09:12AM +, Paul Wise wrote:
>>
 This is the main reason I haven't switched to systemd timers for my
 personal crontab, I have some jobs that generate output (diffs of
 various things mostly) but don't fail. There doesn't appear to be any
 tool to monitor a tool and send a mail if it generates output or fails,
 in the way that cron does.
>>
>>> mail -E ?
>>
>> Specifically:
>>
>>    ExecStart=/bin/sh -c '/path/to/job | /usr/bin/mail -E'
>>
>> in the service unit triggered by the timer unit should work, I think.
>> (I've not tested it.)
> 
> May need something like
> (job || echo Job failed) 2>&1 | mail -E
> or even
> 
> (job 2>&1 || echo Job failed) | tee /dev/stderr | mail -E
> 
> depending on the specific requirements, but in general this should be
> pretty straightforward


You might want to use  OnFailure=

https://www.freedesktop.org/software/systemd/man/systemd.unit.html#OnFailure=

https://serverfault.com/questions/694818/get-notification-when-systemd-monitored-service-enters-failed-state

You can set the OnFailure= action via a drop-in for individual services
without having to touch the original .service file.


With v244 it's also possible to set this OnFailure= action globally for
all services. The relevant part from the NEWS file:

> * Unit files now support top level dropin directories of the form
>   .d/ (e.g. service.d/) that may be used to add 
> configuration
>   that affects all corresponding unit files.


Or you use something like
https://github.com/joonty/systemd_mon



HTH,
Michael



signature.asc
Description: OpenPGP digital signature


Bug#948525: ITP: mopidy-gmusic -- Mopidy extension for playing music from Google Play Music

2020-01-09 Thread Stein Magnus Jodal
Package: wnpp
Severity: wishlist
Owner: Stein Magnus Jodal 

* Package name: mopidy-gmusic
  Version : 4.0.0
  Upstream Author : Ronald Hecht 
* URL : https://github.com/mopidy/mopidy-gmusic
* License : Apache-2.0
  Programming Lang: Python
  Description : Mopidy extension for playing music from Google Play Music

Mopidy plays music from local disk, Spotify, SoundCloud, Google Play Music,
and more. You can edit the playlist from any phone, tablet, or computer using
a variety of MPD and web clients.

This package provides a Mopidy extension for playing music from Google Play
Music, either music you've uploaded to the library, or music available through
a paid subscription.


The package will be maintained in the mopidy-team group on Salsa.


signature.asc
Description: PGP signature


Bug#948526: ITP: genomethreader -- software tool to compute gene structure predictions

2020-01-09 Thread Sascha Steinbiss
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: genomethreader
  Version : 1.7.3
  Upstream Author : Gordon Gremme
* URL : http://genomethreader.org
* License : ISC
  Programming Lang: C
  Description : software tool to compute gene structure predictions

GenomeThreader is a software tool to compute gene structure predictions.
The gene structure predictions are calculated using a similarity-based
approach where additional cDNA/EST and/or protein sequences are used to
predict gene structures via spliced alignments. GenomeThreader was motivated
by disabling limitations in GeneSeqer, a popular gene prediction program
which is widely used for plant genome annotation.

The software has recently been liberated after being closed-source for a
while.



Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

2020-01-09 Thread Ulrike Uhlig
Hi!

On 06.01.20 19:56, Alexander Wirt wrote:
> On Mon, 06 Jan 2020, Ulrike Uhlig wrote:
>>> On 28.12.19 18:16, Alexander Wirt wrote:
>> >From your replies to emails in this thread I was wondering: do you mean
>> that the Salsa team does not need, or does not want, help? Or does not
>> need, or want, help outside of a sprint?
> That basically means: yes we probably need help. But it also means that
> getting help should be done in a coordinated way, like introducing one or two
> team members during a sprint. Getting someone new involved always means
> overhead and should happen when there is time for such overhead. In my
> experience sprints are ideal for it. I also talked to some people about
> getting them involved in salsa, but there will also be a call for help. 
> 
> I / we plan to add at least one global admin and maybe one or two assistants
> that help with "user" support. 
> 
> We just need some time to plan and coordinate those things (around christmas
> is really a bad timing for such discussions)

Sounds like a good plan! :)

 -- ulrike



Bug#948534: ITP: ignition-math6 -- A small, fast, and high performance math library (v6)

2020-01-09 Thread Jose Luis Rivero
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-math6
  Version : 6.4.0
  Upstream Author : Open Source Robotics Foundation
* URL : http://ignitionrobotics.org/libraries/math
* License : Apache
  Programming Lang: C++
  Description : A small, fast, and high performance math library (v6)

Small, fast, and high performance math library. This library is a
self-contained set of classes and functions suitable for robot
applications.

Designed to be co-installable with ignition-math4, already present
in Debian.



Bug#948537: ITP: ignition-common3 -- Ignition common classes and functions for robot apps (v3)

2020-01-09 Thread Jose Luis Rivero
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-common3
  Version : 3.3.0
  Upstream Author : jriv...@osrfoundation.org
* URL : https://bitbucket.org/ignitionrobotics/ign-common
* License : Apache2
  Programming Lang: C++
  Description : Ignition common classes and functions for robot apps (v3)

Ignition Common is a component in the ignition framework, a set of
libraries designed to rapidly develop robot applications.

Future version of Gazebo simulator and ignition transport (already in
debian) will use it as dependency.


Designed to be co-installable with ignition-common, already present
in Debian.



Bug#948539: ITP: ignition-transport8 -- Ignition Transport library v8

2020-01-09 Thread Jose Luis Rivero
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-transport8
  Version : 8.0.0
  Upstream Author : Open Source Robotics Foundation
* URL : http://ignitionrobotics.org/libraries/transport
* License : Apache
  Programming Lang: C++
  Description : Transport library which combines ZeroMQ and Protobuf

ignition transport library combines ZeroMQ with Protobufs to create a
fast and efficient message passing system. Asynchronous message
publication and subscription is provided along with service calls and
discovery.

The version 1 is already in Debian. Here is the version 8.



Work-needing packages report for Jan 10, 2020

2020-01-09 Thread wnpp
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1239 (new: 0)
Total number of packages offered up for adoption: 239 (new: 3)
Total number of packages requested help for: 61 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



No new packages have been orphaned, but a total of 1239 packages are
orphaned.  See https://www.debian.org/devel/wnpp/orphaned
for a complete list.



The following packages have been given up for adoption:

   cmark (#948229), offered 4 days ago
 Description: CommonMark parsing and rendering program
 Reverse Depends: libcmark-dev mkvtoolnix-gui nheko
 Installations reported by Popcon: 1397
 Bug Report URL: https://bugs.debian.org/948229

   i8kutils (#948521), offered today
 Description: Fan control for Dell laptops
 Installations reported by Popcon: 165
 Bug Report URL: https://bugs.debian.org/948521

   source-highlight (#948230), offered 4 days ago
 Description: convert source code to syntax highlighted document
 Reverse Depends: biosyntax-less libsource-highlight-dev
   libsource-highlight4v5 licenseutils ruby-mizuho source-highlight
 Installations reported by Popcon: 1622
 Bug Report URL: https://bugs.debian.org/948230

236 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 1135 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker
 Installations reported by Popcon: 1149
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3028 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 650
 Bug Report URL: https://bugs.debian.org/642906

   broadcom-sta (#886599), requested 731 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1689
 Bug Report URL: https://bugs.debian.org/886599

   cargo (#860116), requested 1003 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 1353
 Bug Report URL: https://bugs.debian.org/860116

   cyrus-imapd (#921717), requested 335 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 403
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 1569 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (78 more omitted)
 Installations reported by Popcon: 195719
 Bug Report URL: https://bugs.debian.org/799864

   dee (#831388), requested 1273 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core
 Installations reported by Popcon: 36835
 Bug Report URL: https://bugs.debian.org/831388

   developers-reference (#759995), requested 1958 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 7404
 Bug Report URL: https://bugs.debian.org/759995

   devscripts (#800413), requested 1563 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   brz-debian customdeb debci debian-builder debmake debpear (31 more
   omitted)
 Installations reported by Popcon: 11710
 Bug Report URL: https://bugs.debian.org/800413

   docker.io (#908868), requested 481 days ago
 Description: Linux container runtime
 Reverse Depends: golang-github-containers-buildah-dev
   golang-github-containers-image-dev
   golang-github-fsouza-go-dockerclient-dev
   golang-github-google-cadvisor-dev
   golang-github-openshift-imagebuilder-dev
   golang-github-samalba-dockerclient-dev kubernetes-node subuser
   whalebuilder
 Installations reported by Popcon: 2687
 Bug Report URL: https://bugs.debian.org/908868

   ed (#886643), requested 731 days ago
 Description: classic UNIX line editor
 Reverse Depends: apt-cacher libdebbugs-perl opensmtpd sn
 Installations reported by Popcon: 15604
 Bug Report URL: https://bugs.debia

Bug#948547: RFP: libmill -- Go-style concurrency library for C

2020-01-09 Thread Dmitry Smirnov
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: libmill
Version: 1.18
Upstream Author: Martin Sustrik
License: Expat
URL: Go-style concurrency library for C
Vcs-Browser: https://salsa.debian.org/debian/libmill
Description: Go-style concurrency library for C
 Libmill is a library that introduces Go-style concurrency to C.

--

Packaging is pretty much completed on Salsa.


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


Re: Bits from the Debian Community Team (Jan 2020)

2020-01-09 Thread Jean-Philippe MENGUAL




Jean-Philippe MENGUAL
Hi,



Last (but definitely not least!): We're continuing to look for more
volunteers to help in the Community Team. While we strongly believe
that making Debian a good and welcoming place for collaboration is a
responsibility of *all* members of our community, there's also a need
for dedicated people to assist when things are not working so well. If
you think you'd like to help, please contact us - we promise not to
bite! :-)


The process you follow to accept or not new contributors is not quite 
clear for me and/or not encouraging. When I proposed help, I had a 
further reply saying "if we accept, we contact you, otherwise no". But 
as there is not timing, impossible to know wether the application is 
accepted or rejected and why. I guess now my application was rejected, 
no problem, but it works like a job, strange. More communication would 
have helped. Furthermore, you should explain the process for anyone who 
would want to help to make people want to do so. And what are your 
criteria or whatever.


I dont remove my proposal if not yet rejected, but indeed I am less 
motivated, all the more I wonder what I would have done in recent 
difficult situations in Debian related to CoC.


Regards




Cheers,

Steve, for the Community Team