Re: Is an init required to obey policy-rc.d during boot ?
On 4/23/20 1:42 AM, Michael Biebl wrote: > Am 23.04.20 um 00:43 schrieb Thomas Goirand: >> On 4/22/20 4:11 PM, Sam Hartman wrote: > >>> And a native interface for a sysadmin overriding that (masking). >> >> Unless I'm mistaking, that's not useful if you want to disable starting >> the daemon before installing it (ie: before the .service exists in the >> system). > > Your assumption is wrong. You can mask a service before installing a package > - systemctl mask foo.service (will issue a warning that foo.service > doesn't exist but will proceed) > - apt install foo (shipping a foo.service) > → foo.service will not be started Good to know, thanks! Thomas
Re: Is an init required to obey policy-rc.d during boot ?
On Thu, 23 Apr 2020, Thomas Goirand wrote: doesn't exist but will proceed) - apt install foo (shipping a foo.service) → foo.service will not be started Good to know, thanks! Is https://www.freedesktop.org/software/systemd/man/systemd.preset.html perhaps something that could help here? -Timo
Bug#958510: ITP: neutron-tempest-plugin -- OpenStack Integration Test Suite - Neutron plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: neutron-tempest-plugin Version : 1.1.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/neutron-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Neutron plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Neutron plugin.
Bug#958516: ITP: asmjit -- Complete x86/x64 JIT and AOT Assembler for C++.
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: asmjit * URL : https://github.com/asmjit/asmjit * License : Zlib license Programming Lang: X++ Description : Complete x86/x64 JIT and AOT Assembler for C++. pytorch dependency. will be maintained under deep learning team.
Bug#958517: ITP: rabit -- Reliable Allreduce and Broadcast Interface for distributed machine learning
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: rabit * URL : https://github.com/dmlc/rabit/ * License : BSD-3 Programming Lang: C++ Description : Reliable Allreduce and Broadcast Interface for distributed machine learning xgboost dependency maintained under deep learning team
Bug#958543: ITP: watcher-tempest-plugin -- OpenStack Integration Test Suite - Watcher plugin
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: watcher-tempest-plugin Version : 2.0.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/watcher-tempest-plugin * License : Apache-2.0 Programming Lang: Python Description : OpenStack Integration Test Suite - Watcher plugin Tempest is a set of integration tests to be run against a live Openstack cluster in order to make sure that all components are working as expected. Tempest will start and stop virtual machine in order to check that your cloud is working as expected. . This package contains the Watcher plugin.
Re: Is an init required to obey policy-rc.d during boot ?
Hi, On Wed, Apr 22, 2020 at 03:09:13PM +0100, Simon McVittie wrote: > In a systemd-based system, I would achieve the equivalent of #950851 > by telling systemd to start a restricted target that only contains the > services I specifically want, instead of the default 'graphical.target' > (targets are analogous to sysvinit runlevels, but you can have any number > of them). Perhaps runit has, or could have, something similar? Can that be automated through a well-defined interface, to allow sysadmins overseeing larger installations to control this centrally through one of the automation frameworks? The policy-rc.d mechanism is used by invoke-rc.d, which is defined as the appropriate way to start an init script in Policy, so sysadmins have a reasonable expectation that all init scripts use that mechanism. We have two custom implementations in the archive (policy-rcd-declarative and policyrcd-script-zg2), and I'd expect that lots of others exist that are local to installations. As far as I can see, there is no similar mechanism in systemd that allows blanket refusal or logging of unknown services, only masking of known services by name. The method of using a custom target comes closest, is there a namespace of target names that can be used by sysadmins that will never conflict with upstream target names? Can maintainer scripts expect systemd services to be available (mainly thinking about tmpfilesd here, but there might be others that become relevant in the future)? Simon
Re: Is an init required to obey policy-rc.d during boot ?
Thanks everybody for your help :) On 4/22/20 4:09 PM, Simon McVittie wrote: > [ ... ] > In a systemd-based system, I would achieve the equivalent of #950851 > by telling systemd to start a restricted target that only contains the > services I specifically want, instead of the default 'graphical.target' > (targets are analogous to sysvinit runlevels, but you can have any number > of them). Perhaps runit has, or could have, something similar? > > smcv Yes, I think I will try something similar with a dedicated service directory that by default provides only one getty plus one getty on serial tty. Lorenzo
Re: Is an init required to obey policy-rc.d during boot ?
Am 23.04.2020 um 16:59 schrieb Simon Richter: > As far as I can see, there is no similar mechanism in systemd that allows > blanket refusal or logging of unknown services, only masking of known > services by name. The method of using a custom target comes closest, is > there a namespace of target names that can be used by sysadmins that will > never conflict with upstream target names? Just in case this is not obvious to everyone: deb-systemd-invoke (which is what's used in maintainer scripts of packages using dh_installsystemd) does respect policy-rc.d (although policy-rc.d is a rather horrible interface tbh). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#958555: ITP: authenticator -- A Two-Factor Authentication application
Package: wnpp Severity: wishlist Owner: Henry-Nicolas Tourneur * Package name: authenticator Version : 3.32.2 Upstream Author : Bilal Elmoussaoui * URL : https://gitlab.gnome.org/World/Authenticator * License : GPL-3 Programming Lang: Python Description : A Two-Factor Authentication application Two-Factor Authentication GTK based application. It provides the following features: - QR code scanner - Beautiful UI - Huge database of more than 560 supported services - Keep your PIN tokens secure by locking the application with a password - Automatically fetch an image for services using their favicon - The possibility to add new services
php-mailparse - new 3.1 upstream version - please build package for debian buster
Hi, I don't know is that good place to make an issue. Please dump up php-mailparse to newly released upstream version 3.1. That version is aware of segfaults. Regards, Jarosław Kłopotek
Re: Is an init required to obey policy-rc.d during boot ?
On Thu, 23 Apr 2020 at 16:59:43 +0200, Simon Richter wrote:
> The policy-rc.d mechanism is used by invoke-rc.d, which is defined as the
> appropriate way to start an init script in Policy, so sysadmins have a
> reasonable expectation that all init scripts use that mechanism.
It's documented in Policy as the appropriate way for *a maintainer
script* to start an init script. debhelper-generated maintainer-script
fragments in packages that have systemd services often don't actually
use invoke-rc.d any more, but they do use deb-systemd-invoke, a
Debian-specific program closely resembling invoke-rc.d; it does similar
checks, including policy-rc.d. Policy should ideally document those two
as being equally valid, if it doesn't already.
policy-rc.d and invoke-rc.d are not documented in Policy to be a way to
control what happens after you reboot, and neither sysv-rc nor systemd
runs invoke-rc.d or consults policy-rc.d during normal system boot.
Just to make sure I wasn't spreading misinformation, I tested this in
a VM, using sysvinit:
- apt install sysvinit-core (systemd is removed)
- reboot
- write "#!/bin/sh\nexit 101\n" into /usr/sbin/policy-rc.d
- apt install apache2
(prints "invoke-rc.d: policy-rc.d denied execution of start")
- pgrep apache (no output)
- reboot
- pgrep apache (now it is running)
> As far as I can see, there is no similar mechanism in systemd that allows
> blanket refusal or logging of unknown services, only masking of known
> services by name.
Taking a step back from policy.d specifically (since it is not a suitable
tool to control what happens during boot), I think your statement is
correct, but that's a bit like saying there's no mechanism in Unix
that allows blanket refusal or logging of unknown executable programs,
only deleting or `chmod -x` known programs by name.[1] Yes, it's true;
but if there was such a mechanism, a large part of its practical effect
would be to prevent the programs you do want, some of which probably
run unknown-to-you programs as an implementation detail, from working
correctly.
systemd.preset(5) (see below) is probably the closest. However, systemd
services can and do depend on other services (some of which might be an
implementation detail of how a larger, user-facing service is broken up
into modules, rather than something directly user- or network-facing). If
they do, both targets and presets will normally start the depended-on
service, in order to make the dependent service work.
If you have looked at everything that depends on a specific service
and decided that, even at the risk of breaking the dependent services,
you still don't want to run it, that's what masking services is for.
> On Wed, Apr 22, 2020 at 03:09:13PM +0100, Simon McVittie wrote:
> > In a systemd-based system, I would achieve the equivalent of #950851
> > by telling systemd to start a restricted target that only contains the
> > services I specifically want, instead of the default 'graphical.target'
> > (targets are analogous to sysvinit runlevels, but you can have any number
> > of them). Perhaps runit has, or could have, something similar?
>
> Can that be automated through a well-defined interface, to allow sysadmins
> overseeing larger installations to control this centrally through one of
> the automation frameworks?
The submitter of #950851 was talking about special-purpose, single-use
containers, rather than about full machines with sysadmins and a normal
init system, and my suggestion was specific to that use-case. (Containers
as a heavier-weight alternative to a chroot, rather than containers as
a lighter-weight alternative to a VM.)
systemd targets do have a well-defined interface, described in
systemd.target(5) and in the KERNEL COMMAND LINE section of systemd(1).
However, if you are setting up special-purpose targets, that's getting
into OS design rather than sysadmin territory (the line between the two
is of course very blurred, and the difference between a special-purpose OS
and an extensively configured instance of a general-purpose OS is mostly
a matter of point of view).
If (as it sounds like to me) your use-case is not the same as that of the
submitter of #950851, and you want to control what (high-level, user-
and/or network-facing) services are started on a full machine that has
a sysadmin and a normal init system and "mostly" boots in the normal
Debian way, I'd suggest looking into systemd.preset(5) instead.
Debian's normal policy is that "most" installed services get started on
boot ("enabled" in systemd terminology), on the assumption that if you
don't want the service, you wouldn't install it. Our systemd's default
behaviour is configured accordingly.
In systemd-using OSs that are more like the Red Hat family, where a
standard installation includes a lot more potentially-unwanted services
and as a result the policy is that "most" installed services *don't*
get started on boot (not "enabled"), the systemd.preset(5) mechanism is
how that policy is implem
Bug#958563: ITP: shellescape -- Escape arbitrary strings for use as command line arguments
Package: wnpp
Severity: wishlist
Owner: Bradford D. Boyle
* Package name: shellescape
Version : 1.2.2-1
Upstream Author : Alessio Treglia
* URL : https://github.com/alessio/shellescape
* License : Expat
Programming Lang: Go
Description : Escape arbitrary strings for use as command line arguments
GoDoc (https://godoc.org/github.com/alessio/shellescape) Travis-CI
Status (http://travis-ci.org/#!/alessio/shellescape) Coverage
(https://gocover.io/github.com/alessio/shellescape) Coverage Status
(https://coveralls.io/github/alessio/shellescape?branch=master)
shellescape Escape arbitrary strings for safe use as command
line arguments. Contents of the package This package provides the
shellescape.Quote() function that returns a shell-escaped copy of a
string. This functionality could be helpful in those cases where it is
known that the output of a Go program will be appended to/used in the
context of shell programs' command line arguments.
.
This work was inspired by the Python original package shellescape
(https://pypi.python.org/pypi/shellescape). Usage The following snippet
shows a typical unsafe idiom:
.
```go package main
.
import (
"fmt" "os"
)
.
func main() {
fmt.Printf("ls -l %s\n", os.Args[1])
} ``` [See in Go Playground](https://play.golang.org/p/Wj2WoUfHd)_
.
Especially when creating pipeline of commands which might end up being
executed by a shell interpreter, tt is particularly unsafe to not escape
arguments.
.
shellescape.Quote() comes in handy and to safely escape strings:
.
```go package main
.
import (
"fmt" "os"
"gopkg.in/alessio/shellescape.v1"
.
)
.
func main() {
fmt.Printf("ls -l %s\n", shellescape.Quote(os.Args[1]))
} ``` [See in Go Playground](https://play.golang.org/p/HJCXgSrmp)_ The
escargs utility escargs reads lines from the standard input and prints
shell-escaped versions. Unlinke xargs, blank lines on the standard input
are not discarded.
This package is needed for barnard
Bug#958567: ITP: barnard -- barnard is a terminal-based client for the Mumble voice chat software
Package: wnpp
Severity: wishlist
Owner: Bradford D. Boyle
* Package name: barnard
Version : 0.0~git20190930.c9876db-1
Upstream Author : Brandon McGinty-Carroll
* URL : https://github.com/bmmcginty/barnard
* License : GPL-2.0
Programming Lang: Go
Description : barnard is a terminal-based client for the Mumble voice
chat software
BarnardDocumentation Please feel free to give suggestions and corrections
for this file (as wellas Barnard propper). Find a sample notification
script in examples/. Audio boost If a user is too soft to hear,
you can boost their audio. The audio should drastically increase
once you have hit the VolumeUp key over 10 times (from the silent/0
position). The boost setting is saved per user, just like per user
volume. FIFO Control If you pass the --fifo option to Barnard, a FIFO
pipe will be created. You can control Barnard by sending commands
to this FIFO. Each command must end with a \n (0x0a) character.
Commands may be added at any time. Per the robustness principle,
be liberal in what you receive. Current Commands: * error: An error
has occured to prevent transmitting audio, or taking another action. *
micup: Start transmitting, just as when you hold down the talk key. Does
nothing if you are already transmiting. * micdown: Stop transmitting,
just like when you release your talk key. Does nothing if you are not
already transmitting. * toggle: Toggle your transmission state. * talk:
Synonym for toggle. * exit: Exit Barnard, just like when you press your
quit key. Event Notification You can use the notifycommand parameter
in your config file to run a program on certain events. Each event has
the following parameters: * event: the name of the event
- join: user has joined the channel you are in - leave: user has
left the channel you are in - micup: you have begun transmitting -
micdown: you have stopped transmitting - connect: you have connected
to a server - disconnect: you have disconnected from a server - msg:
the channel you are currently connected to has received a message -
pm: you have received a private message
* who: the person causing initiation of the event ("me" for self-generated
events) * what: the body of the event as applicable (message, channel
name, etc)
.
Warning: Keep in mind that Barnard opens an Alsa sound device when
starting. For this reason, any notification command used here will need
to be able to work while other sound is playing. It is recommended that
you test your notification command by hand, while Barnard is running,
before including it here.
.
You can create a command that will take any of these parameters as
desired, by prepending the name of the parameter in your command
with a % (percent) sign. As an example, to attempt to play
wave files for each event, you could set notifycommand to: aplay
/home/username/sounds/mumble/%event.wav When you begin transmitting,
aplay will attempt to play /home/username/sounds/mumble/micup.wav.
The same will be attempted for the other events, such as leave, join,
micdown, etc.
.
In order to process messages and the like, Barnard will parse your command
as a properly quoted shell command. For this reason, you should put
quotes around arguments that have spaces. If you want to do more complex
things, write a shell script (or c application, python script, etc)
to process the arguments passed into it. Connecting Via Text Interface
You can now manage your server lists in a text GUI. An Ncurses interface
has been created by members of the F123 Group (https://gitlab.com/f123).
Make sure the folder in which you store the barnard binary is in your
path. This should be the default for any f123 user. Then just run
./barnard-ui from this folder, and follow the instructions. You can
add barnard-ui to your path as well, and access it from anywhere.
Modifications This copy of Barnard and it's associated Gumble library have
been modified to support usage by blind users. Our thanks go out to Tim
Cooper for the massive amount of work put into this client, originally
found at github.com/layeh/barnard (https://github.com/layeh/barnard).
Config By default, the file $HOME/.barnard.yaml will hold the
configuration for Barnard. You can have barnard read another file
by using the -c option, like ./barnard -c ~/.anotherbarnard.yaml.
It will be created automatically if it doesn't exist. If you modify the
config file while Barnard is running, your changes may be overwritten.
Defaults You can set username and defaultserver in your config file,
and they will be used if none is specified when launching barnard.
(Note that the default username (an empty string) and the default server
name (localhost:64738) have been the defaults for barnard up to this
point, and have been left that way for compatibility.) Audio Devices You
can set the default input and output devices in the config
Bug#958570: ITP: python-edgegrid -- OPEN client authentication protocol for python-requests
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-edgegrid Version : 1.1.2 Upstream Author : Jonathan Landis * URL : https://github.com/akamai/AkamaiOPEN-edgegrid-python * License : Apache-2.0 Programming Lang: Python Description : OPEN client authentication protocol for python-requests This library implements an Authentication handler for requests that provides the Akamai open Edgegrid Authentication scheme. For more information visit the Akamai open Developer Community. This is a new dependency for OpenStack DNS as a Service, aka Designate.
Work-needing packages report for Apr 24, 2020
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: 1203 (new: 1) Total number of packages offered up for adoption: 219 (new: 0) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: djbdns (#958111), orphaned 5 days ago Description: dns debugging tools Reverse Depends: axfrdns ldap2dns Installations reported by Popcon: 6 Bug Report URL: https://bugs.debian.org/958111 1202 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 219 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 558 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web dms-wsgi doc-central (136 more omitted) Installations reported by Popcon: 96574 Bug Report URL: https://bugs.debian.org/910917 autopkgtest (#846328), requested 1240 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker Installations reported by Popcon: 1170 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3133 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 680 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 836 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1781 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 1108 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1649 Bug Report URL: https://bugs.debian.org/860116 clipit (#941081), requested 212 days ago Description: lightweight GTK+ clipboard manager Reverse Depends: lxqt Installations reported by Popcon: 10144 Bug Report URL: https://bugs.debian.org/941081 cyrus-imapd (#921717), requested 440 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: 441 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 1674 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: 201684 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1378 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: 31081 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2063 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 6321 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1668 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian buildd customdeb debci debian-builder debmake (33 more omitted) Installations reported by Popcon: 11761 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 586 days ago Description: Linux container runtime Reverse Depends: docker-clean golang-github-containers-buildah-dev golang-github-containers-image-dev golang-github-fsouza-go-dockerclient-dev golang-github-openshift-imagebuilder-dev golang-github-samalba-dockerclient-dev golang-github-tonistiigi-fsutil-dev kubernetes-node subuser whalebuilder Installations reported by Popcon: 3363 Bug Report URL: https://bugs.debian.org/908868 ebib (#952810), requested 54 days ago Description: BibTeX database manager for Emacs Installations reported by Popcon: 39 Bug Report URL: https://bugs.debian.org/9
Bug#958648: ITP: opensmtpd-filter-rspamd -- OpenSMTPD filter integration for the Rspamd daemon
Package: wnpp Severity: wishlist Owner: Ryan Kavanagh * Package name: opensmtpd-filter-rspamd Version : 0.1.6 Upstream Author : Gilles Chehade * URL : https://github.com/poolpOrg/filter-rspamd * License : ISC Programming Lang: Go Description : OpenSMTPD filter integration for the Rspamd daemon This filter implements the Rspamd protocol and allows OpenSMTPD to request an Rspamd analysis of an SMTP transaction before a message is committed to queue. The filter currently supports: * greylisting * adding X-Spam related headers to a message * rewriting Subject * DKIM-signing message * Rspamd-provided SMTP replies * Allow Rspamd to add and remove headers This package will be maintained under the umbrella of the pkg-go team. -- |)|/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Bug#958650: ITP: fp16 -- Conversion to/from half-precision floating point formats
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: fp16 * URL : https://github.com/Maratyszcza/FP16 * License : MIT Programming Lang: C++ Description : Conversion to/from half-precision floating point formats pytorch dependency debian deep learning team
Bug#958651: ITP: fxdiv -- C99/C++ header-only library for division via fixed-point multiplication by inverse
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: fxdiv * URL : https://github.com/Maratyszcza/FXDiv * License : MIT Programming Lang: C++ Description : C99/C++ header-only library for division via fixed-point multiplication by inverse pytorch dependency debian deep learning team
Bug#958652: ITP: foxi -- ONNXIFI with Facebook Extension
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: foxi * URL : https://github.com/houseroad/foxi/ * License : MIT Programming Lang: C Description : ONNXIFI with Facebook Extension pytorch(caffe2) dependency debian deep learning team
Bug#958653: ITP: ideep -- Chainer module providing numpy like API and DNN acceleration using MKL-DNN
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: ideep * URL : https://github.com/intel/ideep * License : MIT Programming Lang: C++ Description : Chainer module providing numpy like API and DNN acceleration using MKL-DNN pytorch(caffe2) dependency debian deep learning team
Bug#958654: ITP: psimd -- Portable 128-bit SIMD intrinsics
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: psimd * URL : https://github.com/Maratyszcza/psimd * License : MIT Programming Lang: C++ Description : Portable 128-bit SIMD intrinsics pytorch dependency debian deep learning team
Bug#958655: ITP: pthreadpool -- pthread-based thread pool for C/C++
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: pthreadpool * URL : https://github.com/Maratyszcza/pthreadpool * License : BSD-2 Programming Lang: C++/C Description : pthread-based thread pool for C/C++ pytorch dependency debian deep learning team
Videoconference today 2020-04-24 18:00 UTC (Was: For those who want to keep on contributing (Was: Debian @ COVID-19 Biohackathon (April 5-11, 2020)))
Hi, sorry, I missed to set a new poll for todays Debian Med meeting so I simply suggest to stick to 18:00 UTC which worked out nicely last week. Feel free to check https://www.timeanddate.com/worldclock/fixedtime.html?msg=Debian+CoViD-19+Biohackathon+Video+Conference&iso=20200424T20&p1=37&ah=1 for your time zone. The Jitsi channel will remain the one used in the official sprint period: https://meet.jit.si/DebianMedCovid19 See you later hopefully Andreas. PS: For those who are seriously interested and who can not make it at this time please let me know in private mail. I'll setup a new poll for next week then. > On Wed, Apr 15, 2020 at 09:22:54PM +0200, Andreas Tille wrote: > > Hi, > > > > there will be a formal summary of our sprint which I'd describe with the > > short summary that we have approached in one week more than in usual two > > monthes work. Thanks a lot to all who contributed - especially thanks > > for an enormous support from ftpmaster (we had huge batches of accepted > > packages in less than 24 hours!) > > > > Since the COVID-19 situation is by no means settled and as usual > > successful work tends to create even more work we want to continue our > > effort. So those who are interested to contribute the contact points > > below remain valid. We also want to continue with video meetings. As a > > first date we try an end-of-week meeting on Fridays (I'm open for better > > suggestions why Friday is not so good and a different day of week should > > be choosen). Here is a poll for the exact time for next Friday: > > > > http://whenisgood.net/hd53twx > > > > Looking forward to see you next Friday > > > > Andreas. > > > > On Fri, Mar 27, 2020 at 08:59:50PM +0100, Andreas Tille wrote: > > > Dear Debian Community, > > > > > > There will be an virtual (online) COVID-19 Biohackathon from April 5-11, > > > 2020 and the Debian Med team invite you help us improve biomedical FOSS > > > and the tools/libraries that support those projects. > > > > > > Most tasks do not require any knowledge of biology or medicine, and all > > > types of contributions are welcome: bug triage, testing, documentation, > > > CI, translations, packaging, and code contributions. > > > > > > 1. Debian related bugs are viewable at [covid19-bugs] > > > > > > 2. Software awaiting packaging is listed at [covid-19-packages], please > > > respond to the RFP with your intent so we don't duplicate work > > > > > > 3. You can also contribute directly to the upstream packages, linked > > > from the Debian Med COVID-19 task page at [covid-19-packages]. Note: > > > many biomedical software packages are quite resource limited, even > > > compared to a typical FOSS project. Please be kind to the upstream > > > author/maintainers and realize that they may have limited resources to > > > review your contribution. Triaging open issues and opening pull requests > > > to fix problems is likely to be more useful than nitpicking their coding > > > style. > > > > > > 4. Architectures/porting: Please focus on amd64, as it is the primary > > > architecture for biomedical software. A secondary tier would be arm64 / > > > ppc64el / s390x (but beware the endian-related issues on s390x). From a > > > free/open hardware perspective it would be great to see more riscv64 > > > support, but that is not a priority right now > > > > > > 5. The Debian Med team is also trying to improve the availability of > > > automated biomedical pipelines/workflows [robust-workflows] using the > > > Common Workflow Language open standard. The reference implementation of > > > CWL is written in Python and there are many open issues ready for work > > > that don't require any biomedical background [cwltool-issues] > > > > > > 6. It is very easy to contribute to Debian Med team. We have a lowNMU > > > policy for all our packages. Merge requests on Salsa are usually > > > processed quickly (but please ping some of the latest Uploaders of the > > > package to make sure it will be noticed). Even better if you ask for > > > membership to the team and push directly to the salsa repository. > > > > > > 7. The [debian-med-team-policy] should answer all questions how to > > > contribute. > > > > > > The main COVID-19 biohackathon is being organized at [covid-19-bh20] and > > > for Debian's participation we are using [salsa-covid-19-bh20] > > > > > > [covid-19-bugs] https://blends.debian.org/med/bugs/covid-19.html > > > > > > [covid-19-packages] https://blends.debian.org/med/tasks/covid-19 > > > > > > [covid-19-bh20] https://github.com/virtual-biohackathons/covid-19-bh20 > > > > > > [salsa-covid-19-bh20] > > > https://salsa.debian.org/med-team/community/2020-covid19-hackathon > > > > > > [robust-workflows] https://doi.org/10.1007/s41019-017-0050-4 > > > > > > [cwltool-issues] > > > https://github.com/common-workflow-language/cwltool/issues > > > > > > [COVID-19-advice] > > > https://www.who.int/emergencies
