Bug#1022163: ITP: video-downloader -- Download videos from websites with an easy-to-use interface
Package: wnpp Severity: wishlist Owner: Jérémy Lal X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: video-downloader Version : 0.10.9 Upstream Author : Unrud * URL : https://github.com/Unrud/video-downloader * License : GPL-3+ Programming Lang: Python Description : Download videos from websites with an easy-to-use interface This package is an easy-to-use user interface based on yt-dlp. It provides the following features: - Convert videos to MP3 - Supports password-protected and private videos - Download single videos or whole playlists - Automatically selects a video format based on your quality demands . yt-dlp is a command-line program to download videos from a variety of supported websites. I've been using this software for a while, it has a nice and simple Gnome-styled UI, nicer than current alternatives in Debian. It is actively maintained. It will be python-team maintained.
Re: Submitting Patches
On Fri, 2022-10-21 at 16:28 +1100, Phillip Smith wrote: > Where/How do I submit patches for Debian packages? It completely depends on the preferences of the team or person who will be reviewing the patches. Most teams and package maintainers accept changes via Salsa merge requests, but, as mentioned by Julien, patches attached to bug reports are usually also acceptable. > I have a small improvement for the iptables-persistent package; > I cloned the repo and made a patch (attached) on a branch, but it > appears the public aren't welcome to create accounts on > salsa.debian.org in order to create merge requests? The public are welcome to create accounts on Salsa, but due to large numbers of spammers signing up for accounts and due to the Salsa admins being part-time volunteers, there may be some delay in the account approval process, so patience is helpful. > Are patches even welcome? Debian always welcomes patches, although usually it is a better idea to submit patches upstream first, so that they benefit all users instead of just Debian users. When upstream isn't responsive the Debian maintainer can be a patch recipient of last resort though. Of course since iptables-persistent is a native Debian package, the upstream in this case is the package Debian itself. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Transition: pkg-config to pkgconf: next steps
On 2022-10-20 Johannes Schauer Marin Rodrigues wrote: > Quoting Andrej Shadura (2022-10-20 12:25:13) > > I’ve been rebuilding packages with pkgconf for the past couple of weeks, and > > it looks very good so far: > > > > http://pkgconf-migration.debian.net/ > Thank you! Attached is a dd-list of those packages listed in the "Failures > only" page in case somebody wants to have a quick glance whether their package > is affected. > Thanks! > cheers, josch [...] > Andreas Metzler >enblend-enfuse (U) Works for me. - It is now also marked with SUCCESS on your webpage, I guess you retried? cu Andreas
Re: Transition: pkg-config to pkgconf: next steps
Hi, On Fri, 21 Oct 2022, at 18:38, Andreas Metzler wrote: >> Andreas Metzler >>enblend-enfuse (U) > > Works for me. - It is now also marked with SUCCESS on your webpage, I > guess you retried? I guess so :) -- Cheers, Andrej
RFH: Packaging Intel's userspace tools for Data Streaming Accelerator
Hi all, I was recently approached by Intel engineers Miguel and Jair (Cc:ed on this mail). They asked for my help in getting Debian Bookworm and higher to support the Data Streaming Accelerator, and we have exchanged a couple of messages about this. I'm reproducing next part of our conversation. The purpose of this mail is to help find interested people in Debian that can help review and sponsor uploads of the userspace tools; the kernel-side modules have been enabled as of bug #1021337 (thanks for the quick reply!) It is quite probable Miguel and Jair can be the package maintainers, and I'd be more than happy to welcome them in Debian, but they will surely need some guidance to get the package (for which the work is already started¹) in a state that can be uploaded to Debian. I've been meaning to start helping them, but am quite time-strained and have been unable to do so, so... anybody interested in getting this technology supported in our distribution will be a good candidate to help! ¹ The proposed debian/control file can be found at https://github.com/intel/idxd-config/blob/stable/debian/control I asked them for a description of Intel DSA. They say that: The driver enables the Data Streaming Accelerator or DSA capability for the 4th generation of the Intel Scalable Xeon processor family, with code name Sapphire Rapids, and for future Intel processors. As stated in the DSA specification (which can be found at https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification ): Intel DSA is a high-performance data copy and transformation accelerator that will be integrated in future Intel® processors, targeted for optimizing streaming data movement and transformation operations common with applications for high-performance storage, networking, persistent memory, and various data processing applications. Intel DSA replaces Intel® QuickData Technology, which is a part of Intel® I/O Acceleration Technology. I was also pointed at this very clear blog post in Intel Open Source's space: https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator The userspace software is already available in Fedora / CentOS / RHEL under the name "accel-config" and "libaccel-config". They propose the following description: Utility for configuring the DSA subsystem Intel Accelerator Utilities (accel-config) provides a user interface to the Intel Data Streaming Accelerator (DSA). DSA is a high-performance data copy and transformation accelerator integrated into Intel Xeon processors. . This package contains a utility for configuring the DSA (Data Stream Accelerator) subsystem in the Linux kernel. The first processor family to support the capability is Intel's fourth generation of Scalable Xeon server processors, code-named Sapphire Rapids. Currently some SPR products are planned to be launched on 2022 calendar week 42 and 2022 calendar week 45. High volume SPR processors have a planned launch window on 2023 calendar week 6 to 9 (Feb. 6, 2023 to March 3, 2023). The document at https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator is a good introduction to the accelerator feature. From it, we can extract additional details about the accel-config tool's architecture and features: accel-config is a utility that allows system administrators to configure groups, work queues and engines. The utility parses the topology and capabilities exposed via sysfs and provides a command line interface to configure resources. Some of the capabilities of the accel-config are listed below: > Display the device hierarchy. > Configure attributes and provide access for kernel or applications. > Use API library (libaccel) that applications can link to to perform > operations through a standard ‘C’ library. > Control devices to stop, start interfaces. > Create VFIO mediated devices to expose virtual Intel® DSA instances > to Guest OSes. So... Is anybody among debian-devel readers interested in helping Debian support this hardware feature? Extra points for people that _have_ the suitable hardware! (I don't) Greetings, signature.asc Description: PGP signature
Re: epoch for tss2 package
Quoting Philipp Kern (2022-10-20 14:29:13) > On 20.10.22 13:40, Johannes Schauer Marin Rodrigues wrote: > > Quoting Andreas Henriksson (2022-10-20 12:13:24) > >> Cannot be used for packages that are used in build dependencies, as several > >> build tools (like sbuild) do not support virtual packages in those > >> dependencies by design, to guarantee deterministic builds. > > Wait what? If sbuild doesn't support virtual packages I'd like to hear about > > that. Can I just remove this reason from the wiki page? It is obviously > > wrong. > > If it is not, please file a bug against sbuild. > > The correct statement here is that you ought to pick a default choice > first[1] before a virtual alternative. We don't want to leave it up to > the resolver to pick an arbitrary available build-dependency. So this is > more of a policy rather than a technical question. Behavior for > experimental might currently differ due to a different resolver choice > that's more flexible by design - to get newer versions from experimental > if necessary. > > Kind regards > Philipp Kern > > [1] This might require an overall agreement across Debian at times. But that > seems to be more relevant for dependencies than build-dependencies. Is that really the correct statement? Even after excluding all virtual packages with a single provider, there are literally thousands of source packages for which their first alternative is a virtual package. Is this "policy" documented somewhere? Because if it is, then it either should change or the archive has to be changed to match that policy. In any case, this was not my original question. Andreas presented a way to use a transitional package to rename a package which will work fine I guess except that we have to carry an empty package for a release and that empty package has to be cleaned up at some point, for example by deborphan. My original question was why using a virtual package for the same purpose is a bad idea. The wiki page https://wiki.debian.org/RenamingPackages lists reasons against it that are incorrect. So why is it really a bad idea? Is there any reason not to delete the first reason (the sbuild one) completely? And either I misunderstand the second reason or I implemented my POC incorrectly or apt (as of 2022-10-21) is perfectly capable of replacing the old with the new one. Can somebody shed some light on this? Thanks! cheers, josch signature.asc Description: signature
Re: epoch for tss2 package
On Thu, 20 Oct 2022 at 13:40:56 +0200, Johannes Schauer Marin Rodrigues wrote: > > Most package managers (including APT, as of 2011-02-21) do not know to > > replace the old with the new one and will only use the new package if it is > > installed for some other reason. > > That is a rather old timestamp. And I also do not understand what the author > tries to say here. Isn't using the new package exactly what we want here? I think you might be parsing the sentence as: apt will (only use the new package) etc. and thinking "great, apt will exclusively use the new package, my work here is done!", but the intended parsing is: apt will only (use the new package) if ([the new package] is [going to be] installed for some other reason) In other words, if the state of the system is: oldname version 20200102 is installed newname version 2.0 is available newname Provides, Breaks, Replaces: oldname some-related-package is installed some-related-package Depends: oldname then the assertion (which I haven't verified) is that `apt upgrade` has no particular reason to want to install newname, and will therefore keep oldname instead, unless there happens to be an additional dependency that specifically pulls in newname: oldname version 20200102 is installed newname version 2.0 is available newname Provides, Breaks, Replaces: oldname some-related-package version 1 is installed some-related-package version 2 is available some-related-package version 2 Depends: newname at which point upgrading some-related-package to version 2 should make apt realise that newname is needed, at which point the Breaks/Replaces will clean up oldname, and the Provides will avoid breaking anyone else's dependencies. With a transitional package, it's obvious (both to apt and to a developer trying to understand what is going on) that the intention is for an upgrade from oldname 20200102 to oldname 1:2.0 (or 20221021+really2.0 or however you prefer to spell it) to force newname to be installed, even if nothing else on the system refers to the library by its new name yet. I think there were examples during the bullseye cycle of maintainers trying to avoid needing a transitional package, doing what you're now advocating, finding that it didn't actually upgrade systems correctly, and having to add a transitional package anyway - but I can't remember specific package names and versions, sorry. smcv
Re: RFH: Packaging Intel's userspace tools for Data Streaming Accelerator
Gunnar Wolf left as an exercise for the reader: > So... Is anybody among debian-devel readers interested in helping > Debian support this hardware feature? Extra points for people that > _have_ the suitable hardware! (I don't) my current professional plans include evaluating DSA and integrating it into my product if it proves itself, and this kind of thing is directly up my alley besides. i'm one of the newest DDs, but i'd be very happy to work with Jair and Miguel. -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: epoch for tss2 package
On 21.10.22 20:06, Johannes Schauer Marin Rodrigues wrote: Is that really the correct statement? Even after excluding all virtual packages with a single provider, there are literally thousands of source packages for which their first alternative is a virtual package. Is this "policy" documented somewhere? Because if it is, then it either should change or the archive has to be changed to match that policy. Hm, good point. I thought it was documented in a way stronger way than it actually is. In [1] it says: To specify which of a set of real packages should be the default to satisfy a particular dependency on a virtual package, list the real package as an alternative before the virtual one. Which does not say that you have to, only what you should do if you want to specify a real package. In any case, this was not my original question. Andreas presented a way to use a transitional package to rename a package which will work fine I guess except that we have to carry an empty package for a release and that empty package has to be cleaned up at some point, for example by deborphan. My original question was why using a virtual package for the same purpose is a bad idea. The wiki page https://wiki.debian.org/RenamingPackages lists reasons against it that are incorrect. So why is it really a bad idea? Is there any reason not to delete the first reason (the sbuild one) completely? And either I misunderstand the second reason or I implemented my POC incorrectly or apt (as of 2022-10-21) is perfectly capable of replacing the old with the new one. Can somebody shed some light on this? Yeah, I think that line should be deleted as it might never have been true. I checked the first code in git from 2004 and it doesn't reject virtual packages either. It does pick a winner manually in the resolver and it looks random (or rather in "apt showpkg" order). But it's not like it didn't work. Kind regards Philipp Kern [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
Bug#1022207: ITP: pysocks -- Lets you send traffic through SOCKS proxy servers
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-devel@lists.debian.org, nilsonfsi...@hotmail.com It is a modern fork of SocksiPy with bug fixes and extra features. Acts as a drop-in replacement to the socket module. Seamlessly configure SOCKS proxies for any socket object by calling socket_object.set_proxy(). . Features: - SOCKS proxy client for Python 2.7 and 3.4+ - TCP supported, UDP mostly supported (issues may occur in some edge cases). - HTTP proxy client included but not supported or recommended (you should use requests', or your HTTP client's, own HTTP proxy interface). * Package name: pysocks Version : 1.7.0 Upstream Author : Anorov * URL : https://github.com/Anorov/PySocks * License : BSD-3-clause Programming Lang: Python Description : Lets you send traffic through SOCKS proxy servers Note: package is a required dependency for packaging from https://github.com/sherlock-project/sherlock
Re: RFH: Packaging Intel's userspace tools for Data Streaming Accelerator
Thank you very much for your help Gunnar and Nick. I'd like to also use this opportunity to let you know and thank Colin (https://qa.debian.org/developer.php?login=colin.king%40canonical.com), also a Debian Developer, and Ramesh (https://github.com/ramesh-thomas), the main developer of the accel-config tool, as Colin has helped us with an initial review of the Debian packaging configuration and both have worked to solve the issues and warnings found by the lintian tool in the latest accel-config-v3.5.0 tag (https://github.com/intel/idxd-config/releases/tag/accel-config-v3.5.0) . I'm also adding patrick.mcca...@intel.com to the conversation as together with Miguel and I, we are part of a team specially interested in contributing and maintaining different feature enabling tools, starting with this one. I'd also be very happy to work with you Nick, so please let me know any doubts or comments you may have. --Jair On Fri, 2022-10-21 at 16:36 -0400, nick black wrote: > Gunnar Wolf left as an exercise for the reader: > > So... Is anybody among debian-devel readers interested in helping > > Debian support this hardware feature? Extra points for people that > > _have_ the suitable hardware! (I don't) > > my current professional plans include evaluating DSA and > integrating it into my product if it proves itself, and this > kind of thing is directly up my alley besides. i'm one of the > newest DDs, but i'd be very happy to work with Jair and Miguel. >
Re: RFH: Packaging Intel's userspace tools for Data Streaming Accelerator
On Fri, 2022-10-21 at 12:48 -0500, Gunnar Wolf wrote: > The purpose of this mail is to help find interested people in Debian > that can help review and sponsor uploads of the userspace tools; the > kernel-side modules have been enabled as of bug #1021337 (thanks for > the quick reply!) PS: once the userspace tools reach Debian, please add them here: https://wiki.debian.org/DebianKernel/UserspaceTools > It is quite probable Miguel and Jair can be the package maintainers, > and I'd be more than happy to welcome them in Debian, but they will > surely need some guidance to get the package (for which the work is > already started¹) in a state that can be uploaded to Debian. I think it is excellent that Intel employees are considering getting involved in Debian. Our usual docs for new maintainers are here: https://mentors.debian.net/intro-maintainers/ The basic procedure is to make a new package, polish it up with lintian, piuparts, autopkgtest and other automated checking tools, upload it to the mentors site and file a request for sponsor (RFS). https://mentors.debian.net/sponsors/rfs-howto/ The Debian glossary may help with any unfamiliar jargon: https://wiki.debian.org/Glossary In case Intel are interested in supporting Debian more generally we have some info on our website, inc about partnerships and sponsorship. https://www.debian.org/intro/help#organizations https://www.debconf.org/sponsors/ https://www.debian.org/partners/ -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#1022213: ITP: golang-github-kr-pretty -- Pretty printing for Go values
Package: wnpp Severity: wishlist Owner: sunmin X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-kr-pretty Version : 0.3.1-1 Upstream Author : * URL : https://github.com/kr/pretty * License : MIT Programming Lang: Go Description : Pretty printing for Go values This package is a depedency of https://github.com/kubernetes-sigs/kustomize/tree/master/kyaml kustomize is currently not available witin debian official repo. It's necessary to porting its depedencies first. This package is forked by another package called golang-github-niemeyer-pretty ref : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021398 niemeyer-pretty is seldomly contributed and this origin repo provide more features and is maintained well. package pretty . import "github.com/kr/pretty" . Package pretty provides pretty-printing for Go values. . Documentation . http://godoc.org/github.com/kr/pretty
