Bug#890752: ITP: ctdopts -- Gives your Python tools a CTD-compatible interface
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: ctdopts Version : 1.2 Upstream Author : Andras Szolek et al. * URL : https://github.com/WorkflowConversion/CTDopts * License : GPL-3+ Programming Lang: Python Description : Gives your Python tools a CTD-compatible interface Common Tool Descriptors (CTDs) are XML documents that represent the inputs, outputs, parameters of command line tools in a platform-independent way. CTDopts is a module for enabling tools with CTD reading/writing, argument parsing, validating and manipulating capabilities. Needed for CTDConverter to convert CTD to CWL (and Galaxy) as part of including CWL descriptions in the seqan-apps, openms/topp, flexbar, and lambda-align packages Will be team-maintained by Debian Med
Re: What can Debian do to provide complex applications to its users?
On Sat, Feb 17, 2018 at 11:14:51PM +, Colin Watson wrote: > * Constrained to the sort of server-side applications that might >reasonably be run in a container on their own, just to keep the >problem size down a bit. why this contraint, there are more and more desktop application written in node... -- cheers, Holger signature.asc Description: PGP signature
Bug#890755: ITP: ctdconverter -- Convert CTD files into Galaxy tool and CWL CommandLineTool files
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: ctdconverter Version : 2.0 Upstream Author : WorkflowConversion * URL : https://github.com/WorkflowConversion/CTDConverter/ * License : GPL-3 / Apache-2.0 Programming Lang: Python Description : Convert CTD files into Galaxy tool and CWL CommandLineTool files Common Tool Descriptors (CTDs) are XML documents that represent the inputs, outputs, parameters of command line tools in a platform-independent way. CTDConverter, given one or more Common Tool Descriptors (CTD) XML files, generates Galaxy tool wrappers and Common Workflow Language (CWL) Command Line Tool v1.0 standard descriptions from CTD files. Will assist in including CWL descriptions in the seqan-apps, openms/topp, flexbar, and lambda-align packages Will be team-maintained by Debian Med
Re: Suddenly U2F doesn't work on sid
On Sun, Feb 18, 2018 at 10:08:39AM +0900, Hideki Yamane wrote: > On Sat, 17 Feb 2018 19:32:09 +0100 > Bastian Blank wrote: > > And chromium does not recommends that at all. > Really? What's wrong with it, I'm curious. Well, if you need something, in this case some udev rules to actually be able to access the hardware, then you should recommend it. And as chromium does not pull in the library, then somehow it needs to get the udev rules. Bastian -- Knowledge, sir, should be free to all! -- Harry Mudd, "I, Mudd", stardate 4513.3
Bug#890773: ITP: python-dracclient -- library for managing machines with Dell iDRAC cards
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-dracclient Version : 1.3.1 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/python-dracclient * License : Apache-2.0 Programming Lang: Python Description : library for managing machines with Dell iDRAC cards This package is a library for managing machines with Dell iDRAC cards. Besides normal IPMI stuff, it has BIOS settings list, set, RAID management, CPU list, and more. Note: This is yet another driver for OpenStack BareMetal as a Service (aka Ironic).
Re: Suddenly U2F doesn't work on sid
* Hideki Yamane [2018-02-18 10:08:39 +0900]: > Hi, > > On Sat, 17 Feb 2018 13:10:50 -0500 > Robert Edmonds wrote: > > I ran into the same problem. It looks like it was due to #889665 being > > fixed and not having the libu2f-udev package installed. > > This fixes the problem, thanks Robert! > > > On Sat, 17 Feb 2018 19:32:09 +0100 > Bastian Blank wrote: > > And chromium does not recommends that at all. > > Really? What's wrong with it, I'm curious. > And hope Firefox also supports U2F in the future. Hi, Recent versions of Firefox (Firefox Quantum, i.e. 57+) support u2f if you turn the right knob on in about:config. More details: https://www.yubico.com/2017/11/how-to-navigate-fido-u2f-in-firefox-quantum/ IME it works fine at least on salsa.d.o and on GitHub. Cheers, -- Nicolas Dandrimont BOFH excuse #176: vapors from evaporating sticky-note adhesives signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
On Sun, Feb 18, 2018 at 12:48:49PM +, Holger Levsen wrote: > On Sat, Feb 17, 2018 at 11:14:51PM +, Colin Watson wrote: > > * Constrained to the sort of server-side applications that might > >reasonably be run in a container on their own, just to keep the > >problem size down a bit. > > why this contraint, there are more and more desktop application written in > node... I did say it was a strawman. I picked it mostly because trying to solve every problem at once seems like a recipe for failure, though; better to start small and expand once it's working. -- Colin Watson [cjwat...@debian.org]
Re: What can Debian do to provide complex applications to its users?
On Fri, Feb 16, 2018 at 06:12:04PM +0100, Michael Meskes wrote: > On Fri, Feb 16, 2018 at 11:12:51AM -0500, Michael Stone wrote: > > On Fri, Feb 16, 2018 at 04:58:04PM +0100, Michael Meskes wrote: > > > I know that this does create some problems for us, e.g. on the security > > > side, but the alternative is, as you mentioned, manually installed > > > software and that surely is worse. > > > > No, I think it's better if people know they're on their own for maintaining > > something. What's surely worse is when we ship stuff that we know we can't > > properly maintain in the long term. Better to be out of the archive than in > > without the expected level of quality. > > Who said we cannot properly maintain this stuff? And where do you think our > expected level of quality (whatever that is) will not be reached? In the year 2018, any kind of "properly maintain" includes security support. Please elaborate how Debian can provide security support for packages like gitlab and all their dependencies in buster until mid-2022. If Debian cannot provide security support for the lifetime of a stable Debian release, it is better for our users when they are installing the software from upstream with the security support provided by upstream. > Michael cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: What can Debian do to provide complex applications to its users?
❦ 18 février 2018 23:53 +0200, Adrian Bunk : >> Who said we cannot properly maintain this stuff? And where do you >> think our expected level of quality (whatever that is) will not be >> reached? > > In the year 2018, any kind of "properly maintain" includes security support. > > Please elaborate how Debian can provide security support for packages > like gitlab and all their dependencies in buster until mid-2022. > > If Debian cannot provide security support for the lifetime of a stable > Debian release, it is better for our users when they are installing the > software from upstream with the security support provided by upstream. Debian is not only about security support. We provide packages without security support. We also have backports that come without security support either. This is still better than installing random packages made by random people which may or may not integrate properly into Debian. -- Watch out for off-by-one errors. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: What can Debian do to provide complex applications to its users?
On 18 February 2018 at 12:14, Colin Watson wrote: ... > * Maybe truncate the frozen dependency tree at C extensions, in order >that we can make sure those are built for all architectures, so you'd >still have to care about compatibility with those. It'd be a much >smaller problem, though. One case where this truncation would be a challenge is the Numpy and scipy ecosystem, where the extensions are tightly coupled to blas library used and the numpy ABI - because extensions built on top of numpy depend on that ABI. pip has had difficulty shipping binaries of these stacks because it doesn't represent the ABI - it assumed that anything with a matching version number was compatible, which isn't the case. Arguably numpy should do something different there, but it doesn't :) > * Every frozen dependency must be installed in a particular defined >path based on (application name, dependency name, dependency >version), and must be installed using blessed tools that generate >appropriate packaging metadata that can be scanned centrally without >having to download lots of source packages. > > * Updating a single frozen dependency (assuming no API changes to the >application's source code) must be no harder than updating a single >line in a single file and bumping the Debian package version. > > * Where applicable, deprecation warnings must be configured as >warnings, not errors, to maximise compatibility. Perahps its worth adding 'deprecations should be enabled if off by default - at least during build-time' - I'm thinking of Python where we (upstream) disabled deprecation warnings and many folk get surprised as a result. > * Dependencies with a non-trivial CVE history would have an acceptable >range of versions, so we could drop applications that persistently >cause trouble while still allowing a bit of slack. For some >dependencies it might not be a problem at all; e.g. we probably don't >care what version of python-testtools something uses. :P -Rob
Bug#890807: ITP: golang-github-containerd-cgroups -- cgroups package for Go
Package: wnpp Severity: wishlist Owner: Arnaud Rebillout * Package name: golang-github-containerd-cgroups Version : 0.0~git20180201.c0710c9-1 Upstream Author : containerd * URL : https://github.com/containerd/cgroups * License : Apache-2.0 Programming Lang: Go Description : cgroups package for Go Go package for creating, managing, inspecting, and destroying cgroups. The resources format for settings on the cgroup uses the OCI runtime-spec found here (https://github.com/opencontainers/runtime-spec). - why is this package useful/relevant? It is a dependency of containerd. - how do you plan to maintain it? I plan to maintain it within the golang packaging team.
Re: Suddenly U2F doesn't work on sid
On Sun, Feb 18, 2018 at 8:49 PM, Bastian Blank wrote: > Well, if you need something, in this case some udev rules to actually > be able to access the hardware, then you should recommend it. And as > chromium does not pull in the library, then somehow it needs to get the > udev rules. Alternately, you plugin the hardware and your desktop software installer notices and prompts you to install the required packages. If the relevant packages have the relevant metadata this can work: https://lists.debian.org/debian-devel-announce/2016/11/msg8.html Announcing supported hardware via AppStream --- If you are maintaining a package that supports a specific set of hardware, it would be great if you could add[15] some metadata about which hardware is supported. By doing so, you will enable users to discover your package when they plug in a new device supported by your package. Users can use the isenkram[16] package to discover packages related to their hardware. If your package contains udev rules, it probably needs some AppStream metadata. -- Paul Wise & Petter Reinholdtsen [15] https://wiki.debian.org/AppStream/Guidelines#Announcing_supported_hardware [16] http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html -- bye, pabs https://wiki.debian.org/PaulWise
