Re: Be nice to your fellow Debian colleagues
Ondřej Surý wrote: > the init systemd GR is over and we have reached the results in a > democratic way by following Debian Constitution. However following the > process is orthogonal to our opinions, positions we took, and our > feelings. Now, more than ever, it’s important to be nice to each > other, have a lot of compassion and not be condescending, whatever > group you belong to. Well said. And for any worried by the result, or any who might be looking for signs of what future collaboration might look like, here's a bit of hope: gnome-session 3.34.2-1 and gnome-settings-daemon 3.34.2-1 were just uploaded today, adding support for elogind. I have hopes that Debian's vaunted and venerable development processes will continue to produce good results, and I hope that the new decade sees developers healing and recovering from the last. - Josh Triplett
Bug#947818: ITP: exec-path-from-shell-el -- get environment variables such as $PATH from the shell
Package: wnpp Owner: Lev Lamberov Severity: wishlist * Package name: exec-path-from-shell-el Version : 1.12 Upstream Author : Steve Purcell * URL or Web page : https://github.com/purcell/exec-path-from-shell * License : GPL-3+ Programming Lang: Emacs Lisp Description : get environment variables such as $PATH from the shell This library allows the user to set Emacs' `exec-path' and $PATH from the shell path, so that `shell-command', `compile' and the like work as expected. It also allows other environment variables to be retrieved from the shell, so that Emacs will see the same values you get in a terminal.
Bug#947817: ITP: kaldi -- Kaldi Speech Recognition Toolkit
Package: wnpp Severity: wishlist Owner: Mo Zhou * Package name: kaldi * URL : https://github.com/kaldi-asr/kaldi * URL : http://kaldi-asr.org/ * License : Apache-2 Programming Lang: C++, python, etc. Description : Kaldi Speech Recognition Toolkit This is a widely used Automatic Speech Recognition (ASR) toolkit. It provides me more experience for developing ML-Policy.
Bug#947815: ITP: rust-spotify-tui -- Spotify for the terminal written in Rust
Package: wnpp Severity: wishlist Owner: Ximin Luo * Package name: rust-spotify-tui Version : 0.11.0 Upstream Author : Alexander Keliris * URL : https://github.com/Rigellute/spotify-tui * License : MIT or Apache-2.0 Programming Lang: Rust Description : Spotify for the terminal written in Rust spotify-tui needs to connect to Spotify’s API in order to find music by name, play tracks etc. Instructions on how to set this up will be shown when you first run the app. This app uses the Web API from Spotify, which doesn't handle streaming itself. So you'll need either an official Spotify client open or a lighter weight alternative such as spotifyd. If you want to play tracks, Spotify requires that you have a Premium account.
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
On 12/30/19 11:29 AM, Raphael Hertzog wrote: > I don't think that salsa-ci is particularly problematic in terms of > "efficiency". With the exception of the LXC usage, there's not much > that can be "cut" to save resources. Also, if resources are an issue: I've offered several times to see if I can get some k8s resources for gitlab runners, but never got a reply. Not even a no. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Bug#947782: ITP: go-containerregistry -- Go library and CLIs for working with container registries
Package: wnpp Severity: wishlist Owner: James Montgomery * Package name: go-containerregistry Version : 0.0~git20191218.34fb8ff-1 Upstream Author : Google * URL : https://github.com/google/go-containerregistry * License : Apache-2.0 Programming Lang: Go Description : Go library and CLIs for working with container registries go-containerregistry Build Status (https://travis-ci.org/google/go-containerregistry) GoDoc (https://godoc.org/github.com/google/go-containerregistry) Go Report Card (https://goreportcard.com/report/google/go-containerregistry) Code Coverage (https://codecov.io/gh/google/go-containerregistry) Introduction This is a golang library for working with container registries. It's largely based on the Python library of the same name (https://github.com/google/containerregistry). . The following diagram shows the main types that this library handles. OCI image representation Tools This repo hosts some tools built on top of the library. crane crane (cmd/crane/doc/crane.md) is a tool for interacting with remote images and registries. Installation . GO111MODULE=on go get -u github.com/google/go-containerregistry/cmd/crane . Images You can also use crane as docker image . ```sh $ docker run --rm gcr.io/go-containerregistry/crane ls ubuntu . 2019/12/03 09:33:01 No matching credentials were found, falling back on anonymous 10.04 12.04.5 12.04 12.10 ``` . And it's also available with a shell, which uses the debug tag . sh docker run --rm -it --entrypoint "/busybox/sh" gcr.io/go-containerregistry/crane:debug . gcrane gcrane (cmd/gcrane/README.md) is a GCR-specific variant of crane that has richer output for the ls subcommand and some basic garbage collection support. Installation . GO111MODULE=on go get -u github.com/google/go-containerregistry/cmd/gcrane . Images You can also use gcrane as docker image . ```sh $ docker run --rm gcr.io/go-containerregistry/gcrane ls ubuntu . 2019/12/03 09:33:01 No matching credentials were found, falling back on anonymous 10.04 12.04.5 12.04 12.10 ``` . And it's also available with a shell, which uses the debug tag . sh docker run --rm -it --entrypoint "/busybox/sh" gcr.io/go-containerregistry/gcrane:debug . k8schain k8schain (pkg/authn/k8schain/README.md) implements the authentication semantics use by kubelets in a way that is easily consumable by this library. . k8schain is not a standalone tool, but it's linked here for visibility. Debug images for crane and gcrane crane and gcrane also provide a debug image (containing a shell), which can be found at • gcr.io/go-containerregistry/crane:debug• gcr.io/go-containerregistry/gcrane:debug Inside these images, crane and gcrane can be used like this: . sh /ko-app/crane cp ... . Emeritus: ko (https://github.com/google/ko) This tool was originally developed in this repo but has since been moved to its own repo. Reasoning: go-containerregistry is a dependency for container-diff (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945524)
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
On Mon, 30 Dec 2019, Raphael Hertzog wrote: > On Sat, 28 Dec 2019, Alexander Wirt wrote: > > On Thu, 26 Dec 2019, Otto Kekäläinen wrote: > > > > > Hello! > > > > > > I've seen many times before statements like these so I'd like to raise > > > some discussion around the topic: > > > > > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti: > > > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote: > > > > > The Salsa CA pipeline is recommended. > > > > > > > > For this I need to use my veto as Salsa admin. With the CI people we > > > > have to work through too much problems first. > > The salsa ci pipeline itself has some problematic implementation details > > waldi lined out in the past. Afaik nothing changed, we had several reports > > This is not really true: > https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all&utf8=%E2%9C%93&state=opened&author_username=waldi > > Out of 12 issues reported by waldi, 8 have been fixed/closed. > > Among the remaining ones: > > - https://salsa.debian.org/salsa-ci-team/pipeline/issues/93 > (usage of LXC for autopkgtest) > is likely the most problematic one even though you never explained > what's the real issue... yeah it's virtualization over virtualization > and it downloads a root tarball to do its work, but is this worth than > downloading a docker image? It uses more resources than direct execution > of autopkgtest but it hasn't broken anything so far? that second level of virtualisation caused problems where people told us they are not able to do things in their ci jobs. *snip* > > where people telling us things are not possible on our runners. In the end > > most of them turned out to be limitations of salsa ci. Salsa ci is also > > not very efficent, therefore the veto. > > Claims like "salsa ci is not very efficient" are not actionable. Bugs like > those above are more useful but you should at least take the time to > respond to queries of people, otherwise no progress can be made. > > I don't think that salsa-ci is particularly problematic in terms of > "efficiency". With the exception of the LXC usage, there's not much > that can be "cut" to save resources. Thats probably true, but if it is inefficent and may cause problems on our current architecture / ressources - that can't get fixed easily - a veto is the only thing we have. > > We are working on it and after my holidays are over I will plan another > > sprint for improving salsa. > > \o/ Alex - forgive the shortness, I am on vacation signature.asc Description: PGP signature
Bug#947775: ITP: biglybt -- BiglyBT BitTorrent client
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: biglybt Version : 2.2.0.2 Upstream Author : Bigly Software, Inc * URL : http://www.biglybt.com * License : GPL-2+ Programming Lang: Java Description : BiglyBT BitTorrent client BiglyBT is a feature filled, open source, ad-free, BitTorrent client used to transfer files via the BitTorrent protocol. BiglyBT is the continuation of the Vuze/Azureus project first created in 2003, and is being actively developed by the original coders. This package will be maintained by the Java team.
Re: https://tracker.debian.org/pkg/dballe
On Mon, Dec 30, 2019 at 01:39:14PM +0100, Mattia Rizzolo wrote: > On Mon, Dec 30, 2019 at 11:29:52AM +0100, Kurt Roeckx wrote: > > Note that the name of the .changes file by the maintainer and the > > buildd will be the same, and dak will reject it if that .changes > > file already exists. > > That's true only in case of policy queues nowadays. What is a policy queue? All the recent rejects I get seems to be stable/security uploads. Kurt
Re: https://tracker.debian.org/pkg/dballe
On Mon, 2019-12-30 at 11:29 +0100, Kurt Roeckx wrote: > Is it .deb and .changes file that you would move? That would be the idea yeah. > Note that the name of the .changes file by the maintainer and the > buildd will be the same, and dak will reject it if that .changes > file already exists. I expect that could be dealt with easily in the dak patches, for e.g. by renaming the .changes to include the fingerprint of the signing key or by naming the morgue directory after the signing key fingerprint. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: https://tracker.debian.org/pkg/dballe
On Mon, Dec 30, 2019 at 11:29:52AM +0100, Kurt Roeckx wrote: > Note that the name of the .changes file by the maintainer and the > buildd will be the same, and dak will reject it if that .changes > file already exists. That's true only in case of policy queues nowadays. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: NEW processing time (Was: https://tracker.debian.org/pkg/dballe)
On 12/29/19 10:51 PM, Sebastiaan Couwenberg wrote: > On 12/29/19 3:53 PM, Theodore Y. Ts'o wrote: >> On Sun, Dec 29, 2019 at 09:52:44AM +0100, Enrico Zini wrote: >>> some time ago I uploaded a new version of dballe, which went through NEW >>> because of a change in binary package names (SONAME bump, IIRC). It took >>> two weeks to go through NEW and I turned my energy towards other things >>> since then. >> >> Wow, two weeks? I uploaded a new version of f2fs-tools back in July, >> with the same issue (SONAME bump), and it's still not gotten through >> NEW. >> >> I had assumed everyone was waiting 5-6+ months to get through NEW > > It seems to differ depending on the package. Every month the qgis > package has to go through NEW due to SONAME bumps as well, and this is > usually processed within a week or two. Possibly because the changes > since the last time it was in NEW is limited. > > In March netcdf will be in NEW for a year, a number of subsequent > upstream releases have accumulated there. I suspect this may be another > case where the package got stuck an needs an intervention to get it > acceptable again. > > Asking for explicit review of a package via email or IRC tends to work > reasonably well. +1 Especially when explaining to the FTP masters that the approval is needed to fix an ongoing Python2 removal process (which was the case with Ceph recently for example). Cheers, Thomas Goirand (zigo)
Re: https://tracker.debian.org/pkg/dballe
On Mon, Dec 30, 2019 at 02:52:54AM +, Paul Wise wrote: > On Sun, Dec 29, 2019 at 1:29 PM Roberto C. Sánchez wrote: > > > Would it not be possible to eliminate the need for the second > > unnecessary upload by requiring two signed .changes files to go into > > NEW? A signed binary changes which would form the basis of the FTP > > master review and a signed source changes to enter the archive if the > > package is approved? > > Another approach is to simply have dak discard binaries from all > sourceful uploads (in dak parlance that means .changes files that have > a .dsc) (and save them to an audit directory). The buildds currently > only produce non-sourceful uploads so all their binaries get accepted > fine. For bootstrap scenarios, maintainers can just do an additional > binary-only upload. See the patches myself/ivodd posted recently for a > work in progress on this. Is it .deb and .changes file that you would move? Note that the name of the .changes file by the maintainer and the buildd will be the same, and dak will reject it if that .changes file already exists. Kurt
Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)
On Sat, 28 Dec 2019, Alexander Wirt wrote: > On Thu, 26 Dec 2019, Otto Kekäläinen wrote: > > > Hello! > > > > I've seen many times before statements like these so I'd like to raise > > some discussion around the topic: > > > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti: > > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote: > > > > The Salsa CA pipeline is recommended. > > > > > > For this I need to use my veto as Salsa admin. With the CI people we > > > have to work through too much problems first. > The salsa ci pipeline itself has some problematic implementation details > waldi lined out in the past. Afaik nothing changed, we had several reports This is not really true: https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all&utf8=%E2%9C%93&state=opened&author_username=waldi Out of 12 issues reported by waldi, 8 have been fixed/closed. Among the remaining ones: - https://salsa.debian.org/salsa-ci-team/pipeline/issues/93 (usage of LXC for autopkgtest) is likely the most problematic one even though you never explained what's the real issue... yeah it's virtualization over virtualization and it downloads a root tarball to do its work, but is this worth than downloading a docker image? It uses more resources than direct execution of autopkgtest but it hasn't broken anything so far? - https://salsa.debian.org/salsa-ci-team/pipeline/issues/94 (docker images accumulating in forks) this one should have improved a lot AFAIK as GitLab now supports what's required to remove images from the CI environment too and there's WIP on that front (it might even be live without anyone updating that bug, I'm not sure) - https://salsa.debian.org/salsa-ci-team/pipeline/issues/116 This one is not clear to me. What jobs are using "docker-in-docker" without any legitimate use ? - https://salsa.debian.org/salsa-ci-team/pipeline/issues/121 (split into source and build) This one seems like wishlist and has no real impact on resources as long as we build for a single architecture... > where people telling us things are not possible on our runners. In the end > most of them turned out to be limitations of salsa ci. Salsa ci is also > not very efficent, therefore the veto. Claims like "salsa ci is not very efficient" are not actionable. Bugs like those above are more useful but you should at least take the time to respond to queries of people, otherwise no progress can be made. I don't think that salsa-ci is particularly problematic in terms of "efficiency". With the exception of the LXC usage, there's not much that can be "cut" to save resources. > We are working on it and after my holidays are over I will plan another > sprint for improving salsa. \o/ Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
