Bug#994118: RFP: ocrodjvu3 -- Python 3 port of ocrodjvu (removed from bullseye)
Package: wnpp Severity: wishlist * Package name: ocrodjvu3 Version : Upstream Author : Jakub Wilk and Bastien Roucari`es * URL or Web page : https://github.com/bastien-roucaries/ocrodjvu * License : GNU General Public License v2.0 Description : Python 3 port of ocrodjvu -- , Janusz S. Bien emeryt (emeritus) https://sites.google.com/view/jsbien
Re: Bug#992692: general: Use https for {deb,security}.debian.org by default
On Fri, Sep 10, 2021 at 6:03 PM David Kalnischkies wrote: > Because this thread started with the idea to switch the default of d-i > and co to another URI. If you target only apt then you still need > a solution for d-i and a way to convert whatever d-i had into what apt > gets in the end (of the installation). ISTR the future of creating new Debian installations is to move from debootstrap to dpkg/apt. As an interim step, debootstrap could move from doing its own downloads to passing the appropriate APT_CONFIG/DPKG_ROOT/etc to `apt download`. https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap -- bye, pabs https://wiki.debian.org/PaulWise
Bug#994115: ITP: golang-github-thoj-go-ircevent -- Event based IRC Client library in Go
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-devel@lists.debian.org, francisco.ruvi...@riseup.net * Package name: golang-github-thoj-go-ircevent Version : 0.2-1 Upstream Author : Thomas Jager * URL : https://github.com/thoj/go-ircevent * License : BSD-3-Clause Programming Lang: Golang Description : Event based IRC Client library in Go Event based IRC Client library. . Features: * Event based. Register Callbacks for the events you need to handle. * Handles basic IRC demands for you: - Standard CTCP. - Reconnections on errors. - Detect stoned servers. I intend to maintain it with the Go Packaging Team. golang-github-thoj-go-ircevent-dev is a build-dep for bettercap.
Re: Epoch bump request for ksh
On Sat, Sep 11, 2021 at 07:50:52PM +0200, Timo Röhling wrote: > * Anuradha Weeraman [2021-09-11 21:37]: > https://wiki.debian.org/RenamingPackages has a few good suggestions. > Maybe the transition package method would be appropriate here? > You could probably put the transitional package into the new source > package and use "dh_gencontrol --package=ksh -v20210511" in d/rules > to make it supersede the old binary package and ensure a clean > upgrade path. Thank you for this pointer. The transition package method does seem like a good way forward in this case and I will look into this approach. I think this addresses the original question on the epoch bump. Thank you all for your inputs. Anuradha
Re: Wine MinGW system libraries
Le sam. 11 sept. 2021 à 17:30, Adrian Bunk a écrit : > On Sat, Sep 04, 2021 at 08:17:53PM -0500, Zebediah Figura wrote: > > Hello all, > > > > I'm a contributor to the Wine project. To summarize the following mail, > Wine > > needs special versions of some of its normal dependencies, such as > > libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm > > sending out a mail to major distributions in order to get some feedback > from > > our packagers on how these should be built and packaged. > > > > For a long time Wine has built all of its Win32 libraries (DLLs and > EXEs) as > > ELF binaries. For various reasons related to application compatibility, > we > > have started building our binaries as PE instead, using the MinGW > > cross-compiler. It is our intent to expand this to some of our > dependencies > > as well. The list of dependencies that we intend to build using MinGW is > not > > quite fixed yet, but we expect it to include and be mostly limited to the > > following: > > > > * libvkd3d > > * libFAudio > > * libgnutls > > * zlib (currently included via manual source import) > > * libmpg123 > > * libgsm > > * libpng > > * libjpeg-turbo > > * libtiff > > * libfreetype > > * liblcms2 > > * jxrlib > > > > and dependencies of the above packages (not including CRT dependencies, > > which Wine provides). > >... > > Accordingly, although static linking and source imports are generally > > disprefered, it may quite likely be preferable in our case. We don't get > the > > benefits of on-disk deduplication, since Wine is essentially the only > piece > > of software which needs these libraries. > >... > > How are distributions supposed to provide security support for Wine? > > As an example, Debian 10 that is security supported by Debian > until next summer ships Wine 4.0. > > The libgnutls in Debian 10 has already been patched several times > by Debian for CVE fixes. > > Having to patch several different versions of the same library > in different packages multiplies the effort required to provide > security support for a library. > Yes what why Paul and myself ask for partial arch. No static linking no embeded lib but we need answer from upstream. Note that windows application that use old library are not a concern from the debian si de Bastien > > cu > Adrian > >
Re: Epoch bump request for ksh
* Anuradha Weeraman [2021-09-11 21:37]: However, I feel that given ksh93u+ is unmaintained upstream, existing users of src:ksh stands to gain from the defect fixes and improvements made without having to switch to a new package given that ksh93u+m is maintaining the same code base that would have been otherwise unmaintained. This would avoid having to maintain two packages, one which is unmaintained upstream and one that is. Open to your suggestions on the way forward. https://wiki.debian.org/RenamingPackages has a few good suggestions. Maybe the transition package method would be appropriate here? You could probably put the transitional package into the new source package and use "dh_gencontrol --package=ksh -v20210511" in d/rules to make it supersede the old binary package and ensure a clean upgrade path. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Bug#994089: ITP: node-rollup-plugin-strip -- Rollup plugin to remove debugger statements and functions
Package: wnpp Severity: wishlist Owner: Vivek K J X-Debbugs-Cc: debian-devel@lists.debian.org, vive...@protonmail.com * Package name: node-rollup-plugin-strip Version : 2.1.0 Upstream Author : 2021, Rich Harris * URL : https://github.com/rollup/plugins/tree/master/packages/strip#readme * License : Expat Programming Lang: Javascript Description : Rollup plugin to remove debugger statements and functions This is a plugin for rollup module bundler to remove debugger statements and functions like assert.equal and console.log from your code. This package will be maintained by javascript maintainers.
Re: Epoch bump request for ksh
On Sat, Sep 11, 2021 at 10:16:00AM -0400, Michael Stone wrote: > Hmm. If the project refers to itself as 93u+m does it make sense to package > it as ksh instead of something like ksh93u+m? This reminds me of when debian > first packaged openssh as "ssh" because that's what the predecessor package > and the binary were called but in the long run renamed it to "openssh". (And > with a new name the version/epoch question is moot.) That's certainly an option and I agree it would simplify things from a versioning standpoint. However, I feel that given ksh93u+ is unmaintained upstream, existing users of src:ksh stands to gain from the defect fixes and improvements made without having to switch to a new package given that ksh93u+m is maintaining the same code base that would have been otherwise unmaintained. This would avoid having to maintain two packages, one which is unmaintained upstream and one that is. Open to your suggestions on the way forward. Anuradha
Re: Wine MinGW system libraries
On Sat, Sep 04, 2021 at 08:17:53PM -0500, Zebediah Figura wrote: > Hello all, > > I'm a contributor to the Wine project. To summarize the following mail, Wine > needs special versions of some of its normal dependencies, such as > libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm > sending out a mail to major distributions in order to get some feedback from > our packagers on how these should be built and packaged. > > For a long time Wine has built all of its Win32 libraries (DLLs and EXEs) as > ELF binaries. For various reasons related to application compatibility, we > have started building our binaries as PE instead, using the MinGW > cross-compiler. It is our intent to expand this to some of our dependencies > as well. The list of dependencies that we intend to build using MinGW is not > quite fixed yet, but we expect it to include and be mostly limited to the > following: > > * libvkd3d > * libFAudio > * libgnutls > * zlib (currently included via manual source import) > * libmpg123 > * libgsm > * libpng > * libjpeg-turbo > * libtiff > * libfreetype > * liblcms2 > * jxrlib > > and dependencies of the above packages (not including CRT dependencies, > which Wine provides). >... > Accordingly, although static linking and source imports are generally > disprefered, it may quite likely be preferable in our case. We don't get the > benefits of on-disk deduplication, since Wine is essentially the only piece > of software which needs these libraries. >... How are distributions supposed to provide security support for Wine? As an example, Debian 10 that is security supported by Debian until next summer ships Wine 4.0. The libgnutls in Debian 10 has already been patched several times by Debian for CVE fixes. Having to patch several different versions of the same library in different packages multiplies the effort required to provide security support for a library. cu Adrian
Re: Epoch bump request for ksh
On Fri, Sep 10, 2021 at 10:04:08PM +0530, Anuradha Weeraman wrote: > 2) If you do go ahead with switching to the community distribution, then > "93u+m" is part of the name, not the version number, so I'd suggest: [...] Correction: rushed the last email, I meant to say that I agree that 93u+m is not part of the version per se. I just thought that it would be good to include, just for specificity. However, amending the proposed version as suggested since it makes sense: 1:1.0.0~beta.1-1 Hmm. If the project refers to itself as 93u+m does it make sense to package it as ksh instead of something like ksh93u+m? This reminds me of when debian first packaged openssh as "ssh" because that's what the predecessor package and the binary were called but in the long run renamed it to "openssh". (And with a new name the version/epoch question is moot.)
Bug#994090: ITP: gnome-connections -- Simple GNOME app to access remote computers
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: jer...@bicha.net Package Name: gnome-connections Version: 41~rc Upstream Author: Red Hat, Inc. License: GPL-3+ Programming Lang: Vala Description: Simple GNOME app to access remote computers GNOME Connections is a desktop client to view or use remote computers using VNC or RDP. GNOME Connections is intentionally simple and easy to use. . GNOME Connections replaces the remote desktop functionality that was previously found in GNOME Boxes. Other Info -- GNOME 41 introduces a new default app for GNOME: GNOME Connections. This app will be maintained by the Debian GNOME team. Packaging is at https://salsa.debian.org/gnome-team/gnome-connections Thanks, Jeremy Bicha
Bug#994084: ITP: golang-github-uber-go-tally -- A Go metrics interface with fast buffered metrics and third party reporters
Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: golang-github-uber-go-tally Version : 4.0.0-1 Upstream Author : Uber Go * URL : https://github.com/uber-go/tally * License : MIT Programming Lang: Go Description : A Go metrics interface with fast buffered metrics and third party reporters This package is needed for Traefik. Cheers,
Bug#994083: ITP: golang-github-uber-jaeger-client-go -- Jaeger Bindings for Go OpenTracing API.
Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: golang-github-uber-jaeger-client-go Version : 2.29.1-1 Upstream Author : Jaeger - Distributed Tracing Platform * URL : https://github.com/uber/jaeger-client-go * License : Apache-2.0 Programming Lang: Go Description : Jaeger Bindings for Go OpenTracing API. This library is needed for Traefik. Cheers,
Bug#994082: ITP: golang-github-uber-jaeger-lib -- A collection of shared infrastructure libraries used by different components of Jaeger.
Package: wnpp Severity: wishlist Owner: Aloïs Micard * Package name: golang-github-uber-jaeger-lib Version : 2.4.1-1 Upstream Author : Jaeger - Distributed Tracing Platform * URL : https://github.com/uber/jaeger-lib * License : Apache-2.0 Programming Lang: Go Description : A collection of shared infrastructure libraries used by different components of Jaeger. This library is needed for Traefik. Cheers,
