Re: Freeipa-client in Debian11
On Sat, 4 Sep 2021 09:05:35 +0300, Timo Aaltonen wrote: >On 3.9.2021 19.02, Marc Haber wrote: >> On Fri, Sep 03, 2021 at 01:10:17PM +, Domagoj Bazina wrote: >>> This package is not available in Debian 11 distribution, and version from >>> older Debian 10 can't be installed. Is there any replacement for this >>> package, or are there any plans for implementation of that package in >>> Debian 11? >> >> Packages that didn't make it into a release before the release won't >> make it back into the release after the release. There might be a >> possibility via a backport, but for this to happen, freeipa would need >> to return to testing first. > >My plan was to backport a client-only package, like it was in Buster >(though not via backports). Is that not possible? You're of course free to roll your own, local package. It shold be possible. Just don't expect any official movement in Debian stable, testing or stable-backports until that RC bug is fixed or resolved in some other way. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#993652: ITP: golang-github-bep-gowebp -- C bindings and an API for encoding WebP images (Go library)
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-bep-gowebp Version : 0.1.0-1 Upstream Author : Bjørn Erik Pedersen * URL : https://github.com/bep/gowebp * License : Expat Programming Lang: Go Description : C bindings and an API for encoding WebP images (Go library) This library provides C bindings and an API for *encoding* WebP images using Google's libwebp (https://github.com/webmproject/libwebp) for Go. . It is based on github.com/kolesa-team/go-webp, but this includes and builds the libwebp C source from a versioned Git subtree. . Compiling C code isn't particulary fast; if you install libwebp-dev, you can link against that instead by adding the "dev" tag: . $ apt install libwebp-dev $ go test ./libwebp -tags dev Reason for packaging: Prerequisite for hugo (>= 0.83.0)
Bug#993666: ITP: golang-github-davecgh-go-xdr -- Implements the XDR standard as specified in RFC 4506 in pure Go (Golang)
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-github-davecgh-go-xdr Version : 0.0~git20161123.e6a2ba0-1 Upstream Author : Dave Collins * URL : https://github.com/davecgh/go-xdr * License : ISC Programming Lang: Go Description : Implements the XDR standard as specified in RFC 4506 in pure Go (Golang) go-xdr Build Status (https://travis-ci.org/davecgh/go-xdr) Coverage Status (https://coveralls.io/r/davecgh/go-xdr?branch=master) . Go-xdr implements the data representation portion of the External Data Representation (XDR) standard protocol as specified in RFC 4506 (obsoletes RFC 1832 and RFC 1014) in Pure Go (Golang). A comprehensive suite of tests are provided to ensure proper functionality. It is licensed under the liberal ISC license, so it may be used in open source or commercial projects. . NOTE: Version 1 of this package is still available via the github.com/davecgh/go-xdr/xdr import path to avoid breaking existing clients. However, it is highly recommended that all old clients upgrade to version 2 and all new clients use version 2. In addition to some speed optimizations, version 2 has been been updated to work with standard the io.Reader and io.Writer interfaces instead of raw byte slices. This allows it to be much more flexible and work directly with files, network connections, etc. Documentation GoDoc (http://godoc.org/github.com/davecgh/go-xdr/xdr2) . Full go doc style documentation for the project can be viewed online without installing this package by using the excellent GoDoc site here: http://godoc.org/github.com/davecgh/go-xdr/xdr2 . You can also view the documentation locally once the package is installed with the godoc tool by running godoc -http=":6060" and pointing your browser to http://localhost:6060/pkg/github.com/davecgh/go-xdr/xdr2/ Installation bash $ go get github.com/davecgh/go-xdr/xdr2 . Required for packaging NNCP
Bug#993667: ITP: libfile-treecreate-perl -- Perl module to recursively create and populate a directory tree
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libfile-treecreate-perl Version : 0.0.1 Upstream Author : Shlomi Fish * URL : https://metacpan.org/release/File-TreeCreate * License : Expat Programming Lang: Perl Description : Perl module to recursively create and populate a directory tree File::TreeCreate is a Perl module to quickly and easily create a directory tree and populate it with simple text files. It was extracted from several near-identical copies used in the tests of some of the author's CPAN distributions. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Re: Freeipa-client in Debian11
On 4.9.2021 11.58, Marc Haber wrote: On Sat, 4 Sep 2021 09:05:35 +0300, Timo Aaltonen wrote: On 3.9.2021 19.02, Marc Haber wrote: On Fri, Sep 03, 2021 at 01:10:17PM +, Domagoj Bazina wrote: This package is not available in Debian 11 distribution, and version from older Debian 10 can't be installed. Is there any replacement for this package, or are there any plans for implementation of that package in Debian 11? Packages that didn't make it into a release before the release won't make it back into the release after the release. There might be a possibility via a backport, but for this to happen, freeipa would need to return to testing first. My plan was to backport a client-only package, like it was in Buster (though not via backports). Is that not possible? You're of course free to roll your own, local package. It shold be possible. Just don't expect any official movement in Debian stable, testing or stable-backports until that RC bug is fixed or resolved in some other way. Why? The bug is about the server, doesn't involve the client in any way (other than they're built from the same source)... -- t
Bug#993672: ITP: hjson-go -- Hjson for Go
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: hjson-go Version : 3.1.0-1 Upstream Author : Hjson * URL : https://github.com/hjson/hjson-go * License : Expat Programming Lang: Go Description : Hjson for Go This package includes the hjson-cli command-line tool as well as the Go library for working with HJSON. HJSON is a derivative of JSON designed to be more easily editable by humans. This package is needed for the packaging of NNCP.
Re: Freeipa-client in Debian11
On Sat, 04 Sep 2021 at 17:02:50 +0300, Timo Aaltonen wrote: > On 4.9.2021 11.58, Marc Haber wrote: > > You're of course free to roll your own, local package. It shold be > > possible. Just don't expect any official movement in Debian stable, > > testing or stable-backports until that RC bug is fixed or resolved in > > some other way. > > Why? The bug is about the server, doesn't involve the client in any way > (other than they're built from the same source)... At the risk of stating the obvious: testing migration, release-critical bug monitoring, removals from testing, removals from unstable, etc. all operate at the level of source packages, not binary packages. A source package is either suitable for inclusion in stable or it isn't; it is not possible to include half a source package in stable. If the client is useful and usable, but the server is RC-buggy, one possible route would be to stop building the server-related binary packages until they can be fixed, so that every remaining binary package is non-RC-buggy. smcv
Re: Freeipa-client in Debian11
Simon McVittie kirjoitti 4.9.2021 klo 19.44: > On Sat, 04 Sep 2021 at 17:02:50 +0300, Timo Aaltonen wrote: >> On 4.9.2021 11.58, Marc Haber wrote: >>> You're of course free to roll your own, local package. It shold be >>> possible. Just don't expect any official movement in Debian stable, >>> testing or stable-backports until that RC bug is fixed or resolved in >>> some other way. >> >> Why? The bug is about the server, doesn't involve the client in any way >> (other than they're built from the same source)... > > At the risk of stating the obvious: testing migration, release-critical > bug monitoring, removals from testing, removals from unstable, etc. all > operate at the level of source packages, not binary packages. A source > package is either suitable for inclusion in stable or it isn't; it is > not possible to include half a source package in stable. > > If the client is useful and usable, but the server is RC-buggy, one > possible route would be to stop building the server-related binary > packages until they can be fixed, so that every remaining binary package > is non-RC-buggy. Yes, that's what I did before, kept the full build in experimental and only client in sid etc. But that's a pain to keep in sync and get tested etc.. What I'd backport is not the exact version of what's in sid, instead the server build would be disabled. If that's not possible then maybe I'll postpone the backport until the server works again... however long that'll take. t
Re: Ideas for a dh-privacy-helper
Quoting Bastien ROUCARIES (2021-09-04 19:52:50) > Le ven. 3 sept. 2021 à 01:03, Jonas Smedegaard a écrit : > > > > Quoting Bastien Roucariès (2021-09-02 23:45:30) > > > Perl is an option I implemented the privacy breach test in perl. The > > > problem is I prefer to drop a debian/package.privacy.xslt file in the > > > package instead of asking maintainer to code the removal of privacy > > > problems... > > > > > > Generic one could be coded in perl, but for the end side I need > > > something like xslt2 > > > > If you are asking how to sloppily parse HTML5 files from upstream source > > and XSLT2 files provided by package maintainers, then with perl you > > could use HTML::HTML5::Parser for the first and XML::Saxon::XSLT2 for > > the second. > > Unfortunatly HTML::HTML5::Parser is RC buggy since 4 years due to a > bug for handling UTF-8 (#750946) > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750946 Ouch! I keep forgetting which packages are affected by that annoying bug :-/ > Your suggestion will work fine but we need to get some solution for > this utf-8 problem... I have recently grown somewhat more familiar with UTF-8 and perl (in my work towards fixing bug#867305 in licensecheck), and will try take a fresh look at bug#750946... - 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
Re: Ideas for a dh-privacy-helper
Le ven. 3 sept. 2021 à 01:03, Jonas Smedegaard a écrit : > > Quoting Bastien Roucariès (2021-09-02 23:45:30) > > Perl is an option I implemented the privacy breach test in perl. The > > problem is I prefer to drop a debian/package.privacy.xslt file in the > > package instead of asking maintainer to code the removal of privacy > > problems... > > > > Generic one could be coded in perl, but for the end side I need > > something like xslt2 > > If you are asking how to sloppily parse HTML5 files from upstream source > and XSLT2 files provided by package maintainers, then with perl you > could use HTML::HTML5::Parser for the first and XML::Saxon::XSLT2 for > the second. Unfortunatly HTML::HTML5::Parser is RC buggy since 4 years due to a bug for handling UTF-8 (#750946) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750946 Your suggestion will work fine but we need to get some solution for this utf-8 problem... Bastien > > > > I am sure Python/Ruby/PHP/Haskell/Scheme/Rust/etc. folks will argue > > > that their pet language is the right for the task as well: I think > > > it will help the conversation if you clarify what you are open to > > > and what are constraints for you. > > > > > > E.g. do you mean that it *must* be JavaScript when you mention that? > > > Or are you perhaps asking if someone else wants to take over the > > > challenge from you, so it does not matter how it is done? > > > > No it must no be javascript, but using V8 or something like browser > > internal in order to fail to get a dom tree in case of broken html > > file, like a browser do. But may be I am overconcious > > If you are asking how to parse HTML5 files like a web browser, then with > perl you could use Gtk3::WebKit2 for that. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Re: Ideas for a dh-privacy-helper
Le sam. 4 sept. 2021 à 18:03, Jonas Smedegaard a écrit : > > Quoting Bastien ROUCARIES (2021-09-04 19:52:50) > > Le ven. 3 sept. 2021 à 01:03, Jonas Smedegaard a écrit : > > > > > > Quoting Bastien Roucariès (2021-09-02 23:45:30) > > > > Perl is an option I implemented the privacy breach test in perl. The > > > > problem is I prefer to drop a debian/package.privacy.xslt file in the > > > > package instead of asking maintainer to code the removal of privacy > > > > problems... > > > > > > > > Generic one could be coded in perl, but for the end side I need > > > > something like xslt2 > > > > > > If you are asking how to sloppily parse HTML5 files from upstream source > > > and XSLT2 files provided by package maintainers, then with perl you > > > could use HTML::HTML5::Parser for the first and XML::Saxon::XSLT2 for > > > the second. > > > > Unfortunatly HTML::HTML5::Parser is RC buggy since 4 years due to a > > bug for handling UTF-8 (#750946) > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750946 > > Ouch! > > I keep forgetting which packages are affected by that annoying bug :-/ > > > > Your suggestion will work fine but we need to get some solution for > > this utf-8 problem... > > I have recently grown somewhat more familiar with UTF-8 and perl (in my > work towards fixing bug#867305 in licensecheck), and will try take a > fresh look at bug#750946... The solution is straightforward just send you a mail. Use html5 sniffing and add an optional parameter to method to specify encoding. Bastien > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, 2 Sep 2021 21:26:11 +0200 Simon Richter wrote: > The TLS layer is not part of the security model, so we'd be teaching > users to look for the wrong thing, kind of like the "encrypted with SSL" > badges on web pages in the 90ies. Is there any strong reason to use HTTP than HTTPS now? Should we teach all our users (including non-tech) about "Secure APT" mechanism? And I said about only deb.debian.org and security.debian.org, and just "default" - it means it does provide http access too. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Re: Ideas for a dh-privacy-helper
Quoting Bastien ROUCARIES (2021-09-04 20:28:49) > Le sam. 4 sept. 2021 à 18:03, Jonas Smedegaard a écrit : > > > > Quoting Bastien ROUCARIES (2021-09-04 19:52:50) > > > Le ven. 3 sept. 2021 à 01:03, Jonas Smedegaard a écrit : > > > > > > > > Quoting Bastien Roucariès (2021-09-02 23:45:30) > > > > > Perl is an option I implemented the privacy breach test in perl. The > > > > > problem is I prefer to drop a debian/package.privacy.xslt file in the > > > > > package instead of asking maintainer to code the removal of privacy > > > > > problems... > > > > > > > > > > Generic one could be coded in perl, but for the end side I need > > > > > something like xslt2 > > > > > > > > If you are asking how to sloppily parse HTML5 files from upstream source > > > > and XSLT2 files provided by package maintainers, then with perl you > > > > could use HTML::HTML5::Parser for the first and XML::Saxon::XSLT2 for > > > > the second. > > > > > > Unfortunatly HTML::HTML5::Parser is RC buggy since 4 years due to a > > > bug for handling UTF-8 (#750946) > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750946 > > > > Ouch! > > > > I keep forgetting which packages are affected by that annoying bug :-/ > > > > > > > Your suggestion will work fine but we need to get some solution for > > > this utf-8 problem... > > > > I have recently grown somewhat more familiar with UTF-8 and perl (in my > > work towards fixing bug#867305 in licensecheck), and will try take a > > fresh look at bug#750946... > > The solution is straightforward just send you a mail. Use html5 > sniffing and add an optional parameter to method to specify encoding. Seems to me - and seems from your posts to upstream bugreport that you agree - that a "straightforward" solution breaks the API, whereas a solution which preserves the API is hard. It is my understanding that upstream would considers the API being tied to the API - i.e. if you want a different API then look for different module. Therefore: How do you think about instead using HTML5::DOM? It is not yet in Debian so will need a "sudo apt install cpanminus; cpanm HTML5::DOM". If useful then I can offer to package it for Debian. - 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
Re: Ideas for a dh-privacy-helper
Quoting Jonas Smedegaard (2021-09-04 22:51:40) > It is my understanding that upstream would considers the API being > tied to the API - i.e. if you want a different API then look for > different module. Seems the upstream author of HTML::HTML5::Parser even himself switched to HTML5::DOM for his newer work: https://metacpan.org/pod/Types::HTML5 - 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
Re: Ideas for a dh-privacy-helper
Le sam. 4 sept. 2021 à 20:54, Jonas Smedegaard a écrit : > > Quoting Jonas Smedegaard (2021-09-04 22:51:40) > > It is my understanding that upstream would considers the API being > > tied to the API - i.e. if you want a different API then look for > > different module. > > Seems the upstream author of HTML::HTML5::Parser even himself switched > to HTML5::DOM for his newer work: https://metacpan.org/pod/Types::HTML5 No I really need to ouptut xml and after pass to saxon... > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Re: Ideas for a dh-privacy-helper
Le sam. 4 sept. 2021 à 20:54, Jonas Smedegaard a écrit : > > Quoting Jonas Smedegaard (2021-09-04 22:51:40) > > It is my understanding that upstream would considers the API being > > tied to the API - i.e. if you want a different API then look for > > different module. > > Seems the upstream author of HTML::HTML5::Parser even himself switched > to HTML5::DOM for his newer work: https://metacpan.org/pod/Types::HTML5 Ok reading the source i need HTML5::DOM and Types::HTML5 Types::HTML5 seems to offer a html_to_xml method that I need. Bastien > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > > [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#993695: ITP: golang-lukechampine-blake3 -- A pure-Go implementation of the BLAKE3 cryptographic hash function
Package: wnpp Severity: wishlist Owner: John Goerzen * Package name: golang-lukechampine-blake3 Version : 1.1.5-1 Upstream Author : Luke Champine * URL : https://github.com/lukechampine/blake3 * License : Expat Programming Lang: Go Description : Pure-Go implementation of BLAKE3 cryptographic hash blake3 implements the BLAKE3 cryptographic hash function (https://github.com/BLAKE3-team/BLAKE3). This implementation aims to be performant without sacrificing (too much) readability, in the hopes of eventually landing in x/crypto. . In addition to the pure-Go implementation, this package also contains AVX-512 and AVX2 routines (generated by avo (https://github.com/mmcloughlin/avo)) that greatly increase performance for large inputs and outputs. Required for packaging NNCP
Bug#993704: ITP: balloon -- Balloon password hashing
Package: wnpp Severity: wishlist Owner: jgoerzen * Package name: balloon Version : 1.1.1-1 Upstream Author : Sergey Matveev * URL : http://www.git.cypherpunks.ru/?p=balloon.git;a=summary * License : LGPL3 Programming Lang: Go Description : Balloon password hashing in pure Go This is a pure Go implementation of Balloon password hashing. See https://crypto.stanford.edu/balloon/ for a description of balloon hashing. . This package provides both a Go library and a CLI too. This package is required to package NNCP.
Wine MinGW system libraries
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). There is currently some internal discussion about how these dependencies should be built and linked. There are essentially three questions I see that need to be resolved, and while these resolutions have a significant impact on the Wine building and development process, they also have an impact on distributions, and accordingly I'd like to get input from our packagers to ensure that their considerations are accurately taken into account. (1) Should we build via source import, or link statically, or dynamically? Source imports are dispreferred by Debian [1], on the grounds that they cause duplication of libraries on disk and in memory, and make it harder to handle security updates. They also make building and bisecting harder. Static libraries don't seem to be expressly discouraged, but share most of the same downsides (see also [2]). Note however that if they are linked dynamically, we need to make sure that we load our packages instead of MinGW builds of open-source libraries with applications ship with. There's some internal discussion about whether this is possible while using "stock" builds of MinGW libraries, but, due to the way the Win32 loader works, we will probably need to compile each library, and its dependencies, with a separate, wine-specific name, e.g. "libwinefreetype-6.dll" and "libwineharfbuzz.dll". For a detailed explantion see footnote [3]. Note that all we actually need to change is the name; we don't need to patch the source. 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. (2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately? This is mostly a question for packagers, although it also relates to (3). I expect that Debian will want to answer "packaged separately" here, on the grounds that this lets them update (say) Wine's libgnutls separately, and in sync with ELF libgnutls, if some security fix is needed. There is a snag, though: we need libraries to be copied into the prefix (there's some internal effort to allow using something like symlinks instead, but this hard and not done yet). Normally we perform this copy every time Wine is updated, but if Wine and its dependencies aren't updated on the same schedule, we may end up loading an old version of a dependency in the prefix. (3) If dependencies are packaged separately, should Wine build them as part of its build tree (e.g. using submodules), or find and link (statically or dynamically) to existing binaries? Linking to existing binaries is generally preferable: it avoids duplication on disk; it reduces compile times when compiling a single package from source (especially the first time). However, we aren't going to benefit from on-disk duplication. And, most importantly, unlike with ELF dependencies, there is no standardized way to locate MinGW libraries—especially if it comes to Wine-specific libraries. We would need a way for Wine's configure script to find these packages—and ideally find them automatically, or else fall back to a submodule-based approach. If we rely on distributions to provide our dependencies, the best idea I have here would be something like a x86_64-w64-mingw32-pkg-config (Fedora actually already ships this, but I think Fedora is the only one). And if we use shared libraries rather than static, things get worse: we need to know the exact path of each library and its dependencies at runtime so that we can copy (or symlink) them into a user's WINEPREFIX. For ELF this is the job of ld.so. For MinGW there is no standardized install location across distributions. For what it's worth, the cu
Bug#993706: ITP: golang-go.cypherpunks-recfile -- Pure Go implementation of GNU recutils/recfile databases
Package: wnpp Severity: wishlist Owner: jgoerzen * Package name: golang-go.cypherpunks-recfile Version : 0.4.3-1 Upstream Author : Sergey Matveev * URL : http://www.git.cypherpunks.ru/?p=gorecfile.git;a=summary * License : GPL3 Programming Lang: Go Description : Pure Go implementation of GNU recutils/recfile databases GNU recutils (see package recutils) databases are human-editable, text-based databases called recfiles. This package provides a Go interface to working with recfiles. Required for packaging NNCP
