Bug#912735: ITP: dnsperf -- DNS server and recursor performance testing tools
Package: wnpp Severity: wishlist Owner: Stefan Nachtnebel * Package name: dnsperf Version : 2.1.0.0 Upstream Author : Nominum, Inc. (now Akamai) * URL : https://www.akamai.com/uk/en/products/network-operator/measurement-tools.jsp * License : Apache License 2.0 Programming Lang: C, Python Description : DNS server and recursor performance testing tools dnsperf is a DNS server performance testing tool. It is primarily intended for measuring the performance of authoritative DNS servers, but it can also be used for measuring caching server performance in a closed laboratory environment. For testing caching servers resolving against the live Internet, the resperf program is preferred. Currently, there are no other packages providing dns performance testing tools. Co-maintainers are welcome, but not needed. I would need a sponsor. A RFP for this software has already been filed[1], but has been archived due to inactivity. References [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=692483
Re: Should libpam-elogind Provide libpam-systemd ?
On Sat, 03 Nov 2018 at 00:08:50 +0100, Adam Borowski wrote: > On Fri, Nov 02, 2018 at 10:22:58PM +, Simon McVittie wrote: > > libpam-elogind is very unlikely to be enough to satisfy > > dbus-user-session's dependency, for instance, unless elogind has taken > > an excursion into systemd-like service management while I wasn't looking. > > And for that reason dbus-user-session has Depends: systemd, which describes > this requirement just fine. It runs systemd's user parts. No, a dependency on systemd merely guarantees that /lib/systemd/systemd and .../systemd-logind binaries exist. It does not provide the system integration that dbus-user-session relies on, which is: whenever uid N has at least one login session open, there is an XDG_RUNTIME_DIR for uid N (created by systemd-logind), and a `systemd --user` process running as uid N (systemd system unit user@N.service, started by pid 1 on request from systemd-logind). You might be misinterpreting dbus-user-session as being the component that runs `systemd --user`? If so, it isn't - it's the other way around, `systemd --user` runs a dbus-daemon because dbus-user-session asks it to. To get `systemd --user`, you need a working systemd-logind (represented by a dependency on libpam-systemd, meaning you have the necessary pam_systemd PAM module to tell it about your login sessions), and you also need systemd as pid 1 (which is not something we can express in dependency relationships, but is approximated by Recommends: systemd-sysv). If you don't have `systemd --user` working, then dbus-user-session will not have the opportunity to start a dbus-daemon via socket activation, which means it doesn't provide its intended "API" either. If people who prefer elogind want to add appropriate glue to dbus-user-session to arrange for D-Bus clients to be able to connect to $XDG_RUNTIME_DIR/bus and find a working bus there even in the absence of `systemd --user`, I'm open to suggestions. Implementing this would probably require an additional PAM module that starts one dbus-daemon per XDG_RUNTIME_DIR, or that starts a helper process that uses the socket activation protocol to start the actual dbus-daemon on-demand, or something; I'm not going to maintain such a thing myself, but I wouldn't mind adding it as an alternative dependency. However, note that if you want multiple parallel dbus-daemons per uid, in particular one per X11 display, then dbus-user-session is not for you, and you should continue to use dbus-x11 or some third party implementation of the dbus-session-bus virtual package instead. Packages that use the session bus should depend on "default-dbus-session-bus | dbus-session-bus" so that you can continue to use dbus-x11 to satisfy their dependency, unless they specifically rely on the "one bus per XDG_RUNTIME_DIR" model. smcv
Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions
Package: wnpp
Severity: wishlist
Owner: Christoph Biedl
* Package name: libregexp-wildcards-perl
Version : 1.05
Upstream Author : Vincent Pit
* URL : https://metacpan.org/pod/Regexp::Wildcards
* License : Artistic or GPL-1+
Programming Lang: Perl
Description : converts wildcard expressions to Perl regular expressions
(as created by dh-make-perl)
In many situations, users may want to specify patterns to match but don't
need the full power of regexps. Wildcards make one of those sets of
simplified rules. Regexp::Wildcards converts wildcard expressions to Perl
regular expressions, so that you can use them for matching.
.
It handles the * and ? jokers, as well as Unix bracketed alternatives {,},
but also % and _ SQL wildcards. If required, it can also keep original (...)
groups or ^ and $ anchors. Backspace (\) is used as an escape character.
.
Typesets that mimic the behaviour of Windows and Unix shells are also
provided.
signature.asc
Description: PGP signature
Bug#912752: ITP: pyfuse3 -- Python 3 bindings for libfuse 3 using asynchronous I/O
Package: wnpp Severity: wishlist Owner: Nikolaus Rath * Package name: pyfuse3 Version : 1.1 Upstream Author : Nikolaus Rath * URL : https://github.com/libfuse/pyfuse3 * License : LGPL Programming Lang: Python Description : Python 3 bindings for libfuse 3 using asynchronous I/O pyfuse3 is a set of Python 3 bindings for libfuse 3. It provides an asynchronous API compatible with Trio. The package will be maintained inside the Python modules team. There are a number of Python bindings for libfuse, but most are not compatible with libfuse3 and none supports asynchronous I/O. I intend to upload the package as soon as someone decides to package Trio (https://github.com/python-trio/trio).
Re: Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions
* Christoph Biedl , 2018-11-03, 12:41: It handles the * and ? jokers, s/joker/wildcard/ ? Backspace (\) is used as an escape character. I like the idea of backspace as escape character, but you probably meant "backslash" here. :-) -- Jakub Wilk
Bug#912754: ITP: scdoc - Small man page generator
Package: wnpp Severity: wishlist Owner: Birger Schacht * Package name: scdoc Version : 1.5.2 Upstream Author : Drew DeVault * URL : https://git.sr.ht/~sircmpwn/scdoc * License : MIT Programming Lang: C Description : Small man page generator scdoc is a simple man page generator written for POSIX systems written in C99. It is used to build the manpages of swaywm.
Re: Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions
Jakub Wilk wrote... > * Christoph Biedl , 2018-11-03, 12:41: Thanks for proof-reading. Both issues you've reported are upstream, of course I'll bring them there. > > It handles the * and ? jokers, > > s/joker/wildcard/ ? Not sure here. Seems in English "joker" is unusual to describe a wildcard, unlike other languages. If some native English speaker could comment? > > Backspace (\) is used as an escape character. > > I like the idea of backspace as escape character, but you probably meant > "backslash" here. :-) Nice idea indeed ... Christoph signature.asc Description: PGP signature
Re: Bug#912745: ITP: libregexp-wildcards-perl -- converts wildcard expressions to Perl regular expressions
On Sat, Nov 03, 2018 at 04:25:15PM +0100, Christoph Biedl wrote: s/joker/wildcard/ ? Not sure here. Seems in English "joker" is unusual to describe a wildcard, unlike other languages. If some native English speaker could comment? In English, in the context of a deck of cards, Joker and Wildcard describe the same thing. Although the use of the term wildcard in globs etc. likely derives from the use in decks of cards, it's so far removed now that the original meaning doesn't come to mind, and Joker seems out of place.
Re: Confusing our users - who is supporting LTS?
On Fri, Nov 02, 2018 at 09:15:32AM -0300, Antonio Terceiro wrote: It was said in this same thread that Freexian is already not the only company paying people to do LTS work. See Thanks, that's a good point because it brings up something that's important to distinguish. Freexian as a business seeks money from customers/investors specifically to work on Debian LTS. The other LTS contributors that Ben mentioned may not work for a company that specifically seeks funding for that purpose, but who fund LTS work because it's considered valuable to their goals. In the context of Wouter's objection, I think the former category of company is what's important. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Bug#912761: ITP: octave-arduino -- Arduino Toolbox for Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-arduino Version : 0.2.0 Upstream Author : John Donoghue * URL : https://octave.sourceforge.io/arduino * License : GPL-3+ Programming Lang: Octave Description : Arduino Toolbox for Octave This package provides an Octave look-alike implementation of the Arduino extension for Matlab. It contains functions for setting up the Arduino hardware, making a connection to an Arduino device, and Performing basic and protocol based I/O. This package will be maintained in the realm of the Debian Octave Group. A This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the sources in the repository https://salsa.debian.org/pkg-octave-team/octave-arduino.git
Uncoordinated upload of the rustified librsvg
Hello! With this mail, I would like to protest the uncoordinated upload of the rustified version of libsrvg to unstable. The maintainer of the package knows very well that this particular package has a huge number of reverse dependencies and would cause a lot of problems with non-Rust targets now. He also knows very well that I am very much interested in Debian Ports and a lot of efforts have been invested there. I have puts efforts and time into making the Rust compiler available on more architectures because I also wanted to help with the Rust efforts and this was now directly used against me because my life in Debian Ports has been made harder with all the manual work required for maintaining librsvg on the non-Rust targets now. I'm really annoyed and disappointed by this move and feel really let down by this behavior. No heads up, no coordination, no nothing. Is that seriously the way we want to work together? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 03, 2018 at 10:53:12PM +0100, John Paul Adrian Glaubitz wrote: > With this mail, I would like to protest the uncoordinated upload of the > rustified > version of libsrvg to unstable. The maintainer of the package knows very well > that > this particular package has a huge number of reverse dependencies and would > cause > a lot of problems with non-Rust targets now. He also knows very well that I > am very > much interested in Debian Ports and a lot of efforts have been invested there. Perhaps we should quickly upload a revert, using the last good version of librsvg, before things degrade? Effectively removing librsvg on 11 archs (not counting non-official ones) stops any GUI there. Including proverbial fvwm. A regression of this scale shouldn't be done lightly. So what about reverting it now so things don't degrade, then having a flamewar what to do? Meow! -- A true bird-watcher waves his tail while doing so.
Re: Uncoordinated upload of the rustified librsvg
On Sat, 2018-11-03 at 23:46 +0100, Adam Borowski wrote: > On Sat, Nov 03, 2018 at 10:53:12PM +0100, John Paul Adrian Glaubitz wrote: > > With this mail, I would like to protest the uncoordinated upload of the > > rustified > > version of libsrvg to unstable. "Uncoordinated upload" is a term normally used for library ABI transitions that aren't coordinated with the release team. That is not what happened here. > > The maintainer of the package knows very well that > > this particular package has a huge number of reverse dependencies and would > > cause > > a lot of problems with non-Rust targets now. He also knows very well that I > > am very > > much interested in Debian Ports and a lot of efforts have been invested > > there. > > Perhaps we should quickly upload a revert, using the last good version of > librsvg, before things degrade? Effectively removing librsvg on 11 archs > (not counting non-official ones) stops any GUI there. Including proverbial > fvwm. librsvg doesn't appear to be a hard dependency for fvwm. > A regression of this scale shouldn't be done lightly. So what about > reverting it now so things don't degrade, then having a flamewar what to do? We already know what to do, which is to prioritise our upcoming release and the architectures that will be included in it. We do not allow Debian ports to hold back changes in unstable. Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
Re: Uncoordinated upload of the rustified librsvg
On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski wrote: > Perhaps we should quickly upload a revert, using the last good version of > librsvg, before things degrade? Effectively removing librsvg on 11 archs > (not counting non-official ones) stops any GUI there. Including proverbial > fvwm. It sounds to me like you're saying that to fix librsvg being out of date on 11 arches, we need to make it out of date on every architecture. What is the actual consequence of the latest librsvg being unbuildable on those arches? The old binaries won't automatically be removed there, right? As I mentioned in #debian-devel, librsvg is a security-sensitive library. The Debian GNOME team has long wanted a supported version of librsvg to be buildable on all release architectures in time for the Buster release to ease the maintainability burden on the Security team (as well as benefiting from some hardening improvements). I didn't and don't mean to upset you. It honestly didn't occur to me that I ought to talk to ports maintainers before uploading packages that won't build on ports. Instead of putting all the blame on the GNOME team, maybe you could have expressed your concerns during the months that librsvg was still in experimental? Or maybe you could have said "Rust is now available on all release architectures, but please talk to us before uploading a rustified library." While today's upload was apparently a surprise, I don't think it should have been a surprise that this upload was coming. Reference -- https://mail.gnome.org/archives/desktop-devel-list/2017-December/msg00072.html Thanks, Jeremy Bicha
Re: Uncoordinated upload of the rustified librsvg
Jeremy Bicha, le sam. 03 nov. 2018 21:04:49 -0400, a ecrit: > On Sat, Nov 3, 2018 at 6:47 PM Adam Borowski wrote: > > Perhaps we should quickly upload a revert, using the last good version of > > librsvg, before things degrade? Effectively removing librsvg on 11 archs > > (not counting non-official ones) stops any GUI there. Including proverbial > > fvwm. > > It sounds to me like you're saying that to fix librsvg being out of > date on 11 arches, we need to make it out of date on every > architecture. > > What is the actual consequence of the latest librsvg being unbuildable > on those arches? The old binaries won't automatically be removed > there, right? No, but various problems quickly arise: - no new arch can build it. - if a bug needs to be fixed in it for ports it can't be built. - if it is involved in a transition, it can't be rebuilt, thus holding the transition for those archs. - ftpmasters don't like lingering binaries. A temporary solution could be to upload the previous version under a different source package name, but that builds the same binary packages, and only on archs which don't have rust (yet). Such package won't get upstream updates etc. but it doesn't need to enter testing anyway. Samuel
