Re: d/watch for Gitea's new dynamic pages
Hi Yadd, On Sun, Nov 7, 2021 at 1:08 PM Yadd wrote: > > Yes, but USCAN_SYMLINK is a local parameter I wondered about that, but in the interest of progress implemented the experimental and pedantic tag 'prefer-uscan-symlink'. [1] The description includes the disclaimer: "Please check with your team before making changes to sources you maintain together. There are circumstances when the 'filenamemangle' option is better." Will you and mapreri please hash it out, and instruct the Lintian maintainers? The compromise may be a better tag description. Alternatively, would it be better to set USCAN_SYMLINK in d/watch (instead of ~/.devscripts)? Thank you! Kind regards Felix Lechner [1] https://salsa.debian.org/lintian/lintian/-/commit/d336b6f732fb0059a522f19dbd1e322864c821a9
merged-/usr transition: debconf or not?
I have been asked to remove from the usrmerge package the debconf question which asks to confirm the conversion. Does anybody REALLY believe that it should not be removed? -- ciao, Marco signature.asc Description: PGP signature
Bug#998798: ITP: golang-github-juju-usso -- Ubuntu single sign-on library
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-juju-usso Version : 1.0.1-1 Upstream Author : Canonical Inc * URL : https://github.com/juju/usso * License : LGPL-3.0-with-exception Programming Lang: Go Description : Ubuntu single sign-on library Provides an interface to Ubuntu's single sign-on service. This package is a dependency of golang-github-canonical-candid (ITP #998752), which is needed for packaging LXD (ITP #768073). From a quick inspection of the Candid source, it looks like a non-trivial amount of work to patch out Candid's use of this library, so I'm going to package it, even though it's Ubuntu specific. This package will be team-maintained within the Debian Go Packaging Team. signature.asc Description: This is a digitally signed message part
Re: d/watch for Gitea's new dynamic pages
Le 07/11/2021 à 21:37, Felix Lechner a écrit :
> Hi
>
> On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
> wrote:
>>
>>> filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
>> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
>
> mapreri pointed out that 'USCAN_SYMLINK=rename' is superior to
> 'filenamemangle' in both of our cases.
>
> Lintian will also suggest it very soon (more generally).
>
> Kind regards
> Felix Lechner
Yes, but USCAN_SYMLINK is a local parameter, filenamemangle is better in
a team
Cheers,
Yadd
Re: d/watch for Gitea's new dynamic pages
On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
wrote:
>
>> filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
I think this is more generic:
filenamemangle=s/.*?(@ANY_VERSION@@ARCHIVE_EXT@)/@PACKAGE@-$1/
(not dependent to compression format)
Re: d/watch for Gitea's new dynamic pages
Hi
On Thu, Nov 4, 2021 at 12:48 PM Johannes Schauer Marin Rodrigues
wrote:
>
> > filenamemangle=s/.+\/tag\/(\d\S+)$/foot-$1\.tar\.gz/ \
> filenamemangle=s{.*/(.*)}{@PACKAGE@-$1.tar.gz} \
mapreri pointed out that 'USCAN_SYMLINK=rename' is superior to
'filenamemangle' in both of our cases.
Lintian will also suggest it very soon (more generally).
Kind regards
Felix Lechner
Bug#998796: ITP: pybeam -- Python module to parse Erlang BEAM files
Package: wnpp Severity: wishlist Owner: Boyuan Yang X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pybeam Version : 0.7 Upstream Author : Matwey V. Kornilov * URL : https://github.com/matwey/pybeam/ * License : MIT Programming Lang: Python Description : Python module to parse Erlang BEAM files This library provides functionality to parse Erlang BEAM files. . It is a build-dependency for new releases of rpmlint ( https://github.com/rpm-software-management/rpmlint ). I will maintain this package under Debian Python team umbrella ( https://salsa.debian.org/python-team/packages/pybeam ). Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#998795: ITP: mrcal -- Camera calibration toolkit
Package: wnpp Owner: Dima Kogan Severity: wishlist * Package name: mrcal Version : 2.0 Upstream Author : Dima Kogan * URL or Web page : http://mrcal.secretsauce.net * License : Apache 2.0 Description : Camera calibration toolkit
Bug#998761: ITP: golang-github-x448-float16 -- IEEE 754 half-precision format with correct conversions to/from float32
Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org
* Package name: golang-github-x448-float16
Version : 0.8.4-1
Upstream Author : Montgomery Edwards and Faye Amacker
* URL : https://github.com/x448/float16
* License : Expat
Programming Lang: Go
Description : IEEE 754 half-precision format with correct conversions
to/from float32
x448/float16 package provides IEEE 754 half-precision
floating-point format (binary16) with IEEE 754 default
rounding for conversions. IEEE 754-2008 refers to this
16-bit floating-point format as binary16.
.
IEEE 754 default rounding ("Round-to-Nearest
RoundTiesToEven") is considered the most accurate and
statistically unbiased estimate of the true result.
This package is a dependency of golang-github-fxamacker-cbor (ITP
#998760), which is needed by golang-github-duo-labs-webauthn (ITP
#998759).
This package will be team-maintained within the Debian Go Packaging
Team.
signature.asc
Description: This is a digitally signed message part
Bug#998760: ITP: golang-github-fxamacker-cbor -- CBOR codec implementing RFCs 7049 & 8949
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-fxamacker-cbor Version : 2.3.0-1 Upstream Author : Faye Amacker * URL : https://github.com/fxamacker/cbor * License : Expat Programming Lang: Go Description : CBOR codec implementing RFCs 7049 & 8949 CBOR is a concise binary data format inspired by JSON and MessagePack. CBOR is defined in RFC 8949 (December 2020) which obsoletes RFC 7049 (October 2013). . CBOR is an Internet Standard by IETF. It's used in other standards like WebAuthn by W3C, COSE (RFC 8152), CWT (RFC 8392), CDDL (RFC 8610) and more. This package is a dependency of golang-github-duo-labs-webauthn (ITP #998759), which is needed for packaging LXD (ITP #768073). This package will be team-maintained within the Debian Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#998759: ITP: golang-github-duo-labs-webauthn -- WebAuthn (FIDO2) server library
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-duo-labs-webauthn Version : 0.0~git20210727.9f1b88e-1 Upstream Author : Duo Security, Inc * URL : https://github.com/duo-labs/webauthn * License : BSD-3-clause Programming Lang: Go Description : WebAuthn (FIDO2) server library This library is meant to handle Web Authentication for Go apps that wish to implement a passwordless solution for users. While the specification is currently in Candidate Recommendation, this library conforms as much as possible to the guidelines and implementation procedures outlined by the document. This package is a dependency for packaging LXD (ITP #768073). This package will be team-maintained within the Debian Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#998752: ITP: golang-github-canonical-candid -- Identity Manager Service
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-canonical-candid Version : 1.11.0-1 Upstream Author : Canonical Ltd * URL : https://github.com/canonical/candid * License : AGPL-3 and LGPL-3.0-with-exception Programming Lang: Go Description : Identity Manager Service The Candid server provides a macaroon-based authentication service. This package is a dependency for packaging LXD (ITP #768073). This package will be team-maintained within the Debian Go Packaging Team. signature.asc Description: This is a digitally signed message part
Bug#998742: ITP: golang-github-flosch-pongo2.v4 -- Django-syntax like template-engine for Go
Package: wnpp Severity: wishlist Owner: Mathias Gibbens X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-flosch-pongo2.v4 Version : 4.0.2-1 Upstream Author : Florian Schlachter * URL : https://github.com/flosch/pongo2 * License : Expat Programming Lang: Go Description : Django-syntax like template-engine for Go pongo2 is a Django-syntax like templating-language. This offers a template renderer compatible with the Django syntax but for the Go language. golang-gopkg-flosch-pongo2.v3 currently exists in the archive, but is orphaned (#940030). This ITP will introduce version 4 of the library. This package is a dependency for packaging LXD (ITP #768073). This package will be team-maintained within the Debian Go Packaging Team. signature.asc Description: This is a digitally signed message part
Re: Multiple teams maintaining one package (proposal)
On 16310 March 1977, Jonas Smedegaard wrote: Salsa access rights include the option to grant access to Debian developers at large, which can be used to permit upload rights for secondary teams (as upload generally requires Debian membership anyway). Salsa lets one team grant rights to another team. (Group in salsa). Instead of inviting a member to your group, select the invite group part and add the team. It can even do "subgroups", so say if the python team would have different membership for python modules and python application, one could select to only allow the modules people access. May be a better selection than adding "all of the DDs". -- bye, Joerg
Re: Multiple teams maintaining one package (proposal)
Quoting Ole Streicher (2021-11-07 11:18:34) > during the discussion of the new Debian Math Blend/Team in the > debian-science mailing list, some people expressed their fear that > many packages cannot be simply maintained because they belong to a > different team. > > Specifically, we have teams within (at least) two dimenion: > > 1. Language (or so) oriented teams, like for Python, Java etc. > 2. Topical (or Blends) oriented teams, like Astro, Science, Med > > An astronomy related Python package would usually be maintained by the > Astronomy team. This has the disadvantage, that the Python team cannot > just "team upload" this package; which makes bulk updated more > complicated than necessary. > > One solution here could be to recognize multiple teams: the "primary > one" (by the maintainer's selection) goes into the "Maintainer:" field > in d/control, and all secondary would go into the "Uploaders:" field. > This would imply that the package is conform to all team policies, > except for the salsa location of the package (i.e. a package that has > the Debian Astro Team as primary team would live in the > salsa.d.o/debian-astro/team/). > > For team related tests/uploads, this would probably require to update > the scripts to find all team packages, and adjust the permissions (by > package) on Salsa to allow pushes from other teams. > > On the other hand, it would significantly improve the maintainance for > a number of packages. Salsa access rights include the option to grant access to Debian developers at large, which can be used to permit upload rights for secondary teams (as upload generally requires Debian membership anyway). At https://tracker.debian.org/teams/ arbitrary sets of packages can be monitored together, with email subscriptions to changes, which can be used as aid for "secondary" teams. If lintian warns about uploads about team uploads made by the "wrong" team then I would simply ignore that. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Multiple teams maintaining one package (proposal)
Dear fellow developers, during the discussion of the new Debian Math Blend/Team in the debian-science mailing list, some people expressed their fear that many packages cannot be simply maintained because they belong to a different team. Specifically, we have teams within (at least) two dimenion: 1. Language (or so) oriented teams, like for Python, Java etc. 2. Topical (or Blends) oriented teams, like Astro, Science, Med An astronomy related Python package would usually be maintained by the Astronomy team. This has the disadvantage, that the Python team cannot just "team upload" this package; which makes bulk updated more complicated than necessary. One solution here could be to recognize multiple teams: the "primary one" (by the maintainer's selection) goes into the "Maintainer:" field in d/control, and all secondary would go into the "Uploaders:" field. This would imply that the package is conform to all team policies, except for the salsa location of the package (i.e. a package that has the Debian Astro Team as primary team would live in the salsa.d.o/debian-astro/team/). For team related tests/uploads, this would probably require to update the scripts to find all team packages, and adjust the permissions (by package) on Salsa to allow pushes from other teams. On the other hand, it would significantly improve the maintainance for a number of packages. Best regards Ole
