Bug#908117: RFP: yq -- yq is a lightweight and portable command-line YAML processor The aim of the project is to be the jq or sed of yaml files.
I have created a repository on salsa: https://salsa.debian.org/python-team/packages/yq I am not shure, what is the best way to create a python package. Is there a template for python packages? Am 16.01.23 um 12:14 schrieb Christoph Martin: I had a try with the Go variant, because this is used in a project, that we use. But a lot of Go dependencies are missing in Debian. So, I also vote for the python variant. Who is interested in packaging it? OpenPGP_signature Description: OpenPGP digital signature
Processed: ITP: python-cgelib -- Python3 code to be utilized across the CGE tools
Processing commands for cont...@bugs.debian.org: > owner 1029094 Andreas Tille Bug #1029094 [wnpp] ITP: python-cgelib -- Python3 code to be utilized across the CGE tools Owner recorded as Andreas Tille . > End of message, stopping processing here. Please contact me if you need assistance. -- 1029094: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029094 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1029094: ITP: python-cgelib -- Python3 code to be utilized across the CGE tools
Package: wnpp Severity: wishlist Subject: ITP: python-cgelib -- Python3 code to be utilized across the CGE tools Package: wnpp Owner: Andreas Tille Severity: wishlist * Package name: python-cgelib Version : 0.7.3 Upstream Author : Frank Møller Aarestrup, Technical University of Denmark * URL : https://bitbucket.org/genomicepidemiology/cgelib * License : Apache-2.0 Programming Lang: Python Description : Python3 code to be utilized across the CGE tools This package will in time replace the cgecore package. The package contains classes and functions intended to be utilized across the tools provide by the Center for Genomic Epidemiology. It is for instance needed by resfinder package. Remark: This package is maintained by Debian Med Packaging Team at https://salsa.debian.org/med-team/python-cgelib
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
Control: tags 1029085 + wontfix Control: close 1029085 Hi Scott, On Tue, Jan 17, 2023 at 02:52:49PM +, Scott Kitterman wrote: > It's not policy compliant, which may be okay in this instance, but it > certainly isn't ideal. I looked into this and figured that indeed the Debian Policy has a section 6 on this matter. Interestingly, this policy says little about how compatible programs actaully need to be. It merely states that packages need to cooperate. It also mentions vim vs nvi as an example. If you've ever used either and then gotten onto a system that selected the other or even just vim-tiny, you notice significant differences in their usage and abilities. To me, the differences between borg 1.x and borg 2.x are similar, so I consider the vi example a supporting argument for using alternatives. I happen to had to look into whether update-alternatives are appropriate as part of the CTTE decision on the rename implementation. There, the CTTE ruled that they should not use update-alternatives, because you couldn't actually use them in a compatible way. This does not apply to the borg transition where a number of invocations continue to work. > Here's another approach: Let me call this the python approach, because python pioneered it with python-is-python2 and python-is-python3. From a user point of view, this practically is an implementation detail with three differences to update-alternatives: * You may choose not to have the unversioned instance (by not installing a *-is-* package). * You can depend on the unversioned instance being a particular version using a package dependency. * The incantation for changing the unversioned instance is a different command. Other than this, little changes from a user's point of view. So is any of these differences relevant here? I think lacking an unversioned instance is not an important feature. The difference in incantation is not something I care about either. However, being able to depend on a particular version is something I didn't really consider in sufficient depth thus far. Indeed, borg does have reverse dependencies: * backupninja * borgmatic * fbx-all * freedombox * vorta * And maybe some ITPs for other frontends as well. Moving forward with my update-alternatives plan could mean breaking any of these. For instance, * backupninja uses borg init https://sources.debian.org/src/backupninja/1.2.1-1/handlers/borg.in/#L129 * borgmatic adapts to the borg version dynamically and can handle either * fbx-all is a metapackage and happens to Recommend borgbackup among other things * freedombox uses borg init https://sources.debian.org/src/freedombox/23.2/plinth/modules/backups/privileged.py/?hl=183#L119 * vorta uses borg init https://sources.debian.org/src/vorta/0.8.9-1/src/vorta/borg/init.py/#L31 My update-alternatives approach would break three of them, so that's a big argument against using update-alternatives. The python approach has a different downside. > Borg 1 gets a new binary, borg-is-borg1 that provides usr/bin/borg symlinked > to borg1. The existing package depends on it for Bookworm, so it's > guaranteed to be installed. If borg depends on borg-is-borg1, then of course you cannot coinstall borg 1.x with borg-is-borg2. I'm not sure whether this is relevant. In any case, we can simplify the matter here by making borgbackup Provides: borg-is-borg1 and do away with one package. We can actually do away with the whole borg -> borg1 rename dance as you can never have borg1 installed without borg being borg1. So, we can just skip this entirely. That laves borgbackup2 shipping borg2 and borg-is-borg2 shipping symlinks and Conflicts: borgbackup. The benefit here is that installing borg-is-borg2 will kick all of the reverse dependencies. borgmatic should update its own to borg-is-borg2 | borgbackup. So thank you for your persistence on this. The fact that update-alternatives do break rdeps is a really convincing argument, that only came across relatively implicitly. Helmut
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
On January 17, 2023 2:39:32 PM UTC, Helmut Grohne wrote: >Hi Jonathan, > >Thanks for your review. > >On Tue, Jan 17, 2023 at 02:12:10PM +, Jonathan Dowland wrote: >> I'm not sure that alternatives is appropriate, if the commands are not >> interchangeable. And they are not: if you have 1 & 2 installed on a >> host, and have used one to create some backups, trying to use the other >> could be disastrous, and mixing them up a very real possibility if >> either could concretely own "borg". IMHO, borg1 got that name and should >> keep it, and borg2 should exclusively use a different command name, even >> though that makes us significantly divergent from upstream. > >I agree that alternatives are not 100% appropriate for this situation, >but I think that it is a good trade-off. > >The chances or destroying your backups are fairly minimal. Practically, >things will mostly stop working due to unknown options and commands. > >I think that before too long, people want to get rid of borg 1.x and >forget about it. Keeping the 2 suffix is just making it painful down the >road. As such, I want a way that allows us to drop it eventually. > >>From my point of view, there are three relevant scenarios: > >1. A borg server. Such a system wants both borg 1.x and borg 2.x > available to allow users to transitions their repositories when > they're ready. Users should be advised to set BORG_REMOTE_PATH to > something other than "borg" in this case. > >2. New users installing borg 2.x for the first time. We really want them > not to experience the transition cost. They should be able to use > borg as if there never was borg 1.x. > >3. Users upgrading from borg 1.x. Here, we want to decouple the borg > upgrade from the dist-upgrade. To do this, users will have to install > borg 2.x (not necessarily concurrently), transfer their repositories > and adapt a few command lines. > >Only in scenario 1 where the suffix is unavoidable and also being used >by major borg providers such as rsync.net, borgbase or hetzner, we don't >want to deal with suffixes. > >And with that I arrive at update-alternatives being the best available >compromise. Do more people disagree with this plan? It's not policy compliant, which may be okay in this instance, but it certainly isn't ideal. Here's another approach: Borg 1 gets a new binary, borg-is-borg1 that provides usr/bin/borg symlinked to borg1. The existing package depends on it for Bookworm, so it's guaranteed to be installed. The new borg2 package has a borg-is-borg2 binary which provides usr/bin/borg pointing to borg2. These two packages conflict, so that only one usr/bin/borg provider can be installed. After Bookworm is released, borg1/borg2 can recommend their usr/bin/borg provider and the user can pick. Once borg1 is removed, the extra packages can be dropped too. This might be a little more work and needs a trip through new, but I think it's policy compliant and a little lower risk. Scott K
Bug#1028467: ITP: borgbackup2 -- version 2.x of a deduplicating and compressing backup program
Hi Jonathan, Thanks for your review. On Tue, Jan 17, 2023 at 02:12:10PM +, Jonathan Dowland wrote: > I'm not sure that alternatives is appropriate, if the commands are not > interchangeable. And they are not: if you have 1 & 2 installed on a > host, and have used one to create some backups, trying to use the other > could be disastrous, and mixing them up a very real possibility if > either could concretely own "borg". IMHO, borg1 got that name and should > keep it, and borg2 should exclusively use a different command name, even > though that makes us significantly divergent from upstream. I agree that alternatives are not 100% appropriate for this situation, but I think that it is a good trade-off. The chances or destroying your backups are fairly minimal. Practically, things will mostly stop working due to unknown options and commands. I think that before too long, people want to get rid of borg 1.x and forget about it. Keeping the 2 suffix is just making it painful down the road. As such, I want a way that allows us to drop it eventually. >From my point of view, there are three relevant scenarios: 1. A borg server. Such a system wants both borg 1.x and borg 2.x available to allow users to transitions their repositories when they're ready. Users should be advised to set BORG_REMOTE_PATH to something other than "borg" in this case. 2. New users installing borg 2.x for the first time. We really want them not to experience the transition cost. They should be able to use borg as if there never was borg 1.x. 3. Users upgrading from borg 1.x. Here, we want to decouple the borg upgrade from the dist-upgrade. To do this, users will have to install borg 2.x (not necessarily concurrently), transfer their repositories and adapt a few command lines. Only in scenario 1 where the suffix is unavoidable and also being used by major borg providers such as rsync.net, borgbase or hetzner, we don't want to deal with suffixes. And with that I arrive at update-alternatives being the best available compromise. Do more people disagree with this plan? Helmut
Bug#1029078: ITP: depix -- recovers passwords from pixelized screenshots
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-de...@lists.debian.org, guilherme@gmail.com, debian-security-to...@lists.debian.org, si...@factosec.nl * Package name: depix Version : 0.0~git20220716 Upstream Contact: Sipke Mellema * URL : https://github.com/beurtschipper/Depix * License : CC-BY-4.0 Programming Lang: Python Description : recovers passwords from pixelized screenshots Depix is a tool for recovering passwords from pixelized screenshots. . Pixelization describes the process of partially lowering the resolution of an image to censor information. The implementation of this algorithm attacks the common linear box filter. A linear box filter takes a box of pixels, and overwrites the pixels with the average value of all pixels in the box. Its implementation is simple and its workings fast, for it can process multiple blocks in parallel. . This implementation works on pixelized images that were created with a linear box filter.
Bug#1023608: RFP: pytomlpp
Control: retitle -1 ITP: python-pytomlpp -- Python wrapper for toml++ Please make sure that your draft package's source package name matches the ITP name.
Processed: Re: RFP: pytomlpp
Processing control commands: > retitle -1 ITP: python-pytomlpp -- Python wrapper for toml++ Bug #1023608 [wnpp] ITP: pytomlpp -- Python wrapper for toml++ Changed Bug title to 'ITP: python-pytomlpp -- Python wrapper for toml++' from 'ITP: pytomlpp -- Python wrapper for toml++'. -- 1023608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023608 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1025206: Rescission of ITP
I rescind my intent to package as it is already packaged here ( https://build.opensuse.org/package/show/home:bespokesynth/bespokesynth-current) and I'm not sure I'll have time to maintain this.
Bug#1029062: ITP: gosa-plugins-ldapmanager -- ldapmanager plugin for GOsa
Package: wnpp Severity: wishlist Owner: Mike Gabriel X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gosa-plugins-ldapmanager Version : 2.8~ Upstream Author : GONICUS GmbH * URL : https://github.com/gosa-project/gosa-plugins-ldapmanager * License : GPL-2+ Programming Lang: PHP Description : ldapmanager plugin for GOsa LDAP import and export management plugin . GOsa² is a combination of system-administrator and end-user web interface, designed to handle LDAP based setups. . This package will be maintained by the Debian Edu Packaging Team.
