Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
ma 11. maalisk. 2024 klo 7.02 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: > > ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti: > > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote: > > > I hereby propose bin:dhcpcd-base: > > > > > > 1) already supported by ifupdown. > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > separation. > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > configure both stacks. > > > > > > > why not switch to systemd-networkd + networkmanager for gui installs? > > NM already is pulled by most desktop environments. > > Meanwhile a bare minimal system needs a non-GUI solution and swaping > which DHCP client gets pulled by ifupdown is the simplest, least > disruptive way of accomplishing this. This bug is almost one year old. Are we going ahead with this or not? Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
ma 11. maalisk. 2024 klo 1.29 Bernd Zeimetz (be...@bzed.de) kirjoitti: > On Mon, 2023-06-19 at 13:54 +0300, Martin-Éric Racine wrote: > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > > > why not switch to systemd-networkd + networkmanager for gui installs? NM already is pulled by most desktop environments. Meanwhile a bare minimal system needs a non-GUI solution and swaping which DHCP client gets pulled by ifupdown is the simplest, least disruptive way of accomplishing this. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
su 10. maalisk. 2024 klo 18.54 Santiago Ruano Rincón (santiag...@riseup.net) kirjoitti: > > Hi there, > > El 20/11/23 a las 19:44, Martin-Éric Racine escribió: > > (non-subscriber - please keep me in CC) > > On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine > > wrote: > > > > > > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine > > > wrote: > > > > > > > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > > > > wrote: > > > > > > > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > > > > wrote: > > > > > > > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > > > > wrote: > > > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > > > > Greetings, > > > > > > > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now > > > > > > > > > > might be a > > > > > > > > > > good time to re-visit Debian's choice of standard DHCP > > > > > > > > > > client shipping > > > > > > > > > > with priority:important. > > > > > > > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > > > > privilege separation. > > > > > > > > > > 3) writes both IPv4 and IPv6 name servers to > > > > > > > > > > /etc/resolv.conf > > > > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > > > > 5) a mere inet line in /etc/network/interfaces is > > > > > > > > > > sufficient to > > > > > > > > > > configure both stacks. > > > > > > > > > ... > > > > > > > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to > > > > > > > > > isc-dhcp-client for > > > > > > > > > the moment, and I'll make the relevant changes in ifupdown as > > > > > > > > > soon as I > > > > > > > > > can. Josué, any thoughts? > > > > > > > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > > > > isc-dhcp-client had priority:important probably was to ensure > > > > > > > > that > > > > > > > > debootstrap would pull it, since debootstrap ignores Recommends > > > > > > > > and > > > > > > > > packages with a priority lower than standard. > > > > > > > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, > > > > > > > > it can > > > > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap > > > > > > > > would > > > > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" > > > > > > > > instead. > > > > > > > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority > > > > > > > > of both > > > > > > > > could, in principle, be optional, just as long as ifupdown > > > > > > > > explicitly > > > > > > > > Depends on a DHCP client, and the first alternative is a real > > > > > > > > package. > > > > > > > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > >
Re: Run Debian packaging tasks remotely with debusine.debian.net
Dear Colin, thank you for this project, it looks very interesting. Would you also support running ratt there? For some packages ratt often fails on my local machines due to RAM constraints. Best regards, Martin signature.asc Description: PGP signature
Bug#1063940: ITP: python-term-image -- Display images in the terminal with Python
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Package Name: python-term-image Version: v0.7.1 Upstream Author: Toluwaleke Ogundipe License: MIT Programming Lang: Python 3 Homepage: https://github.com/AnonymouX47/term-image Description: Display images in the terminal with Python term-image is a library and program to display images on compatible terminals. . Features: - Multiple image formats (basically all formats supported by PIL.Image.open() - Multiple image source types: PIL image instance, local file, URL - Multiple image render styles (with automatic support detection) - Support for multiple terminal graphics protocols: Kitty, iTerm2 - Exposes various features of the protocols - Transparency support (with multiple options) - Animated image support (including transparent ones) - Multiple formats: GIF, WEBP, APNG (and possibly more) - Fully controllable iteration over rendered frames of animated images - Image animation with multiple parameters - Integration into various TUI / terminal-based output libraries. - Terminal size awareness - Automatic and manual image sizing - Horizontal and vertical alignment - Automatic and manual font ratio adjustment (to preserve image aspect ratio) This is a new, optional dependency (Recommends) of libervia-backend.
Bug#1063815: ITP: vapid -- Simple VAPID header generation library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Package Name: vapid / python3-py-vapid Version: 1.8.2 Upstream Author: JR Conlin License: MPL2 Programming Lang: Python 3 Homepage: https://github.com/web-push-libs/vapid Description: Simple VAPID header generation library This minimal library contains the minimal set of functions you need to generate a VAPID key set and get the headers you'll need to sign a WebPush subscription update.
Bug#1063814: ITP: encrypted-content-encoding -- Encrypted Content-Encoding for HTTP
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Package Name: encrypted-content-encoding / python3-http-ece Version: v1.2.0 Upstream Author: Martin Thomson License: MIT Programming Lang: Python 3 Homepage: https://github.com/web-push-libs/encrypted-content-encoding Description: Encrypted Content-Encoding for HTTP This library implements HTTP ECE in accordance with RFC 8188. It is needed e.g. for WebPush.
Bug#1062463: ITP: xsf-xmpp-xeps -- XMPP Extension Protocols (XEPs)
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package Name: xsf-xmpp-xeps Version: (git master) Upstream Author: XMPP Standards Foundation License: XSF License (https://github.com/xsf/xeps/blob/master/LICENSE.txt) Programming Lang: XML Homepage: https://github.com/xsf/xeps Description: XMPP Extension Protocols (XEPs) This package contains the specifications produced by the XMPP Standards Foundation (XSF). See http://xmpp.org/ for details. Note, that the core specifications for XMPP are developed at the Internet Engineering Task Force (IETF) and can be found in the (non-free) package doc-rfc-std-proposed.
Bug#1057377: ITP: slidge-matridge -- Feature-rich Matrix to XMPP puppeteering gateway
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package Name: slidge-matridge Version: 0.0.0-dev0 Upstream Author: Nicolas Cedilnik License: ALGPL-3 Programming Lang: Python 3 Homepage: https://git.sr.ht/~nicoco/matridge Description: Feature-rich Matrix to XMPP puppeteering gateway, based on slidge and nio.
Bug#1057361: ITP: pickle-secure -- wrapper around pickle that creates encrypted pickles
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org Control: blocks 1019277 by -1 Package Name: pickle-secure Version: 0.99.9 Upstream Author: Stephanos Kuma License: LGPL-3 Programming Lang: Python 3 Description: wrapper around pickle that creates encrypted pickles pickle-secure offers a similar API as the built-in pickle. This is a (build) dependency for Slidge.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
(non-subscriber - please keep me in CC) On Sat, Nov 18, 2023 at 4:26 PM Martin-Éric Racine wrote: > > On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine > wrote: > > > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > > wrote: > > > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > > wrote: > > > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > > wrote: > > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > > Greetings, > > > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now > > > > > > > > might be a > > > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > > > shipping > > > > > > > > with priority:important. > > > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > > privilege separation. > > > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > > > > configure both stacks. > > > > > > > ... > > > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client > > > > > > > for > > > > > > > the moment, and I'll make the relevant changes in ifupdown as > > > > > > > soon as I > > > > > > > can. Josué, any thoughts? > > > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > > > > packages with a priority lower than standard. > > > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, it > > > > > > can > > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" > > > > > > instead. > > > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of > > > > > > both > > > > > > could, in principle, be optional, just as long as ifupdown > > > > > > explicitly > > > > > > Depends on a DHCP client, and the first alternative is a real > > > > > > package. > > > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > > > > client installed, where all the ipv4 is handled statically, and ipv6 > > > > > is > > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base > > > > > the > > > > > next upgrade. > > > > > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > > > Unless there is a strong objection, I'll file the override bug report. > > > > > > > > (sorry for taking so long to come back to this) > > > > > > > > For the moment, ifupdown is still installed by the debian-installer as > > > > default network interfaces manager. And after sleeping over it, and > > > > discussing with debian fellows, I would like to call for consensus to > > > > r
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Sat, Jul 22, 2023 at 2:55 PM Martin-Éric Racine wrote: > > On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine > wrote: > > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > > wrote: > > > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > > wrote: > > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > > Greetings, > > > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might > > > > > > > be a > > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > > shipping > > > > > > > with priority:important. > > > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with > > > > > > > privilege separation. > > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > > > configure both stacks. > > > > > > ... > > > > > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client > > > > > > for > > > > > > the moment, and I'll make the relevant changes in ifupdown as soon > > > > > > as I > > > > > > can. Josué, any thoughts? > > > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > > > packages with a priority lower than standard. > > > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > > > could, in principle, be optional, just as long as ifupdown explicitly > > > > > Depends on a DHCP client, and the first alternative is a real package. > > > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > > > client installed, where all the ipv4 is handled statically, and ipv6 is > > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > > > next upgrade. > > > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > > Unless there is a strong objection, I'll file the override bug report. > > > > > > (sorry for taking so long to come back to this) > > > > > > For the moment, ifupdown is still installed by the debian-installer as > > > default network interfaces manager. And after sleeping over it, and > > > discussing with debian fellows, I would like to call for consensus to > > > rise Priority: Important to dhcpcd-base (as initially requested in > > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > > > This addresses two scenarios: keep some systems as small as possible > > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > > > client available after installing/bootstrapping. > > > > > > So I would like to retitle #1038882 back as originally reported. (Sorry > > > for going back and forth) Objections? > > > > > > The situation regarding the default network interfaces manager could > > > change, even in the short term. But that could be discussed in another > > > thread. > > > > No objection. Raising the priority of dhcpcd-base to important works for me. > > Have we reached a conclusion? Are we moving ahead with this or not? What is the current situation? Martin-Éric
[BTS#1055272] po-debconf://ocsinventory-agent/sv.po
Forwarded Message Subject: Bug#1055272: Acknowledgement ([INTL:sv] Swedish strings for ocsinventory-agent debconf) Date: Fri, 03 Nov 2023 11:45:04 + Thank you for filing a new Bug report with Debian.
Bug#1055209: RFP: python-langid -- Language Identification (LangID) tool
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-xmpp-de...@lists.alioth.debian.org * Package name: python-langid Version : 1.1.6 Upstream Author : Marco Lui * URL or Web page : https://github.com/saffsd/langid.py * License : BSD-2-Clause Programming Lang: Python Description : Language Identification (LangID) tool This is an optional dependency of libervia-backend >= 0.9.
hardening flags
Hi all, are there any plans to add -fstack-clash-protection to the hardening flags? Martin
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine wrote: > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón > wrote: > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > > wrote: > > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > > Greetings, > > > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might > > > > > > be a > > > > > > good time to re-visit Debian's choice of standard DHCP client > > > > > > shipping > > > > > > with priority:important. > > > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > > > 1) already supported by ifupdown. > > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > > > separation. > > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > > configure both stacks. > > > > > ... > > > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > > > the moment, and I'll make the relevant changes in ifupdown as soon as > > > > > I > > > > > can. Josué, any thoughts? > > > > > > > > 1) As someone pointed out in the thread, the reason why > > > > isc-dhcp-client had priority:important probably was to ensure that > > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > > packages with a priority lower than standard. > > > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > > also pull dependencies with a lower priority. Right now ifupdown > > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > > could, in principle, be optional, just as long as ifupdown explicitly > > > > Depends on a DHCP client, and the first alternative is a real package. > > > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > > client installed, where all the ipv4 is handled statically, and ipv6 is > > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > > next upgrade. > > > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > > Unless there is a strong objection, I'll file the override bug report. > > > > (sorry for taking so long to come back to this) > > > > For the moment, ifupdown is still installed by the debian-installer as > > default network interfaces manager. And after sleeping over it, and > > discussing with debian fellows, I would like to call for consensus to > > rise Priority: Important to dhcpcd-base (as initially requested in > > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > > > This addresses two scenarios: keep some systems as small as possible > > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > > client available after installing/bootstrapping. > > > > So I would like to retitle #1038882 back as originally reported. (Sorry > > for going back and forth) Objections? > > > > The situation regarding the default network interfaces manager could > > change, even in the short term. But that could be discussed in another > > thread. > > No objection. Raising the priority of dhcpcd-base to important works for me. Have we reached a conclusion? Are we moving ahead with this or not? Martin-Éric
Re: HFS/HFS+ are insecure
how many specialized USB drivers are there that are compiled as modules on Debian kernels that may not be maintained as well? Disable all of them by default? Risk assessment is very challenging here, if you ask me. [1] After a long time finally some RDB partitioning overflow fixes went into the kernel. The overflow bug could have caused overwriting of data at a different place of the disk on a different partition than intended which could mean a two-way data loss of both the written data and the data that was accidentally overwritten. While this theoretically could have been used for an exploit by deliberately causing the kernel to overwrite data at a certain location of the disk, I am not aware of any existing exploit for this. Such an exploit would only target a quite low amount of users I bet. See: Partitions: Amiga RDB partition on 2 TB disk way too big, while OK in AmigaOS 4.1 https://bugzilla.kernel.org/show_bug.cgi?id=43511 Plus a ton of discussions on various mailing lists, hopefully all linked in above bug report. Thanks, -- Martin
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón wrote: > > El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió: > > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > > wrote: > > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > > Greetings, > > > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > > > with priority:important. > > > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > > > 1) already supported by ifupdown. > > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > > separation. > > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > > configure both stacks. > > > > ... > > > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > > > can. Josué, any thoughts? > > > > > > 1) As someone pointed out in the thread, the reason why > > > isc-dhcp-client had priority:important probably was to ensure that > > > debootstrap would pull it, since debootstrap ignores Recommends and > > > packages with a priority lower than standard. > > > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > > also pull dependencies with a lower priority. Right now ifupdown > > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > > could, in principle, be optional, just as long as ifupdown explicitly > > > Depends on a DHCP client, and the first alternative is a real package. > > > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > > isc-client-dhcp is a Recommends, is because not all users want a dhcp > > client installed, where all the ipv4 is handled statically, and ipv6 is > > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > > next upgrade. > > > > So I'd prefer to go forward with the steps proposed by Simon, and > > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > > Unless there is a strong objection, I'll file the override bug report. > > (sorry for taking so long to come back to this) > > For the moment, ifupdown is still installed by the debian-installer as > default network interfaces manager. And after sleeping over it, and > discussing with debian fellows, I would like to call for consensus to > rise Priority: Important to dhcpcd-base (as initially requested in > #1038882), and switch to Recommends: dhcpcd-base | dhcp-client. > > This addresses two scenarios: keep some systems as small as possible > (ifupdown users can remove dhcpcd if they want) and having a useful dhcp > client available after installing/bootstrapping. > > So I would like to retitle #1038882 back as originally reported. (Sorry > for going back and forth) Objections? > > The situation regarding the default network interfaces manager could > change, even in the short term. But that could be discussed in another > thread. No objection. Raising the priority of dhcpcd-base to important works for me. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Thu, Jun 22, 2023 at 3:58 PM Santiago Ruano Rincón wrote: > El 20/06/23 a las 08:29, Martin-Éric Racine escribió: > > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón > > wrote: > > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > > > Greetings, > > > > > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > > > good time to re-visit Debian's choice of standard DHCP client shipping > > > > with priority:important. > > > > > > > > I hereby propose bin:dhcpcd-base: > > > > > > > > 1) already supported by ifupdown. > > > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > > > separation. > > > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > > > configure both stacks. > > > ... > > > > > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > > > the moment, and I'll make the relevant changes in ifupdown as soon as I > > > can. Josué, any thoughts? > > > > 1) As someone pointed out in the thread, the reason why > > isc-dhcp-client had priority:important probably was to ensure that > > debootstrap would pull it, since debootstrap ignores Recommends and > > packages with a priority lower than standard. > > > > 2) However, as long as ifupdown explictly depends on a package, it can > > also pull dependencies with a lower priority. Right now ifupdown > > Recommends "isc-dhcp-client | dhcp-client" which debootstrap would > > ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. > > > > 3) At that point, swapping the priority of isc-dhcp-client and > > dhcpcd-base merely becomes "nice to have". Heck, the priority of both > > could, in principle, be optional, just as long as ifupdown explicitly > > Depends on a DHCP client, and the first alternative is a real package. > > I was about to bump dhcpcd-base as ifupdown dependency, but... if > isc-client-dhcp is a Recommends, is because not all users want a dhcp > client installed, where all the ipv4 is handled statically, and ipv6 is > done via SLAAC. As a user, I don't want/need to pull in dhcpcd-base the > next upgrade. > > So I'd prefer to go forward with the steps proposed by Simon, and > s/isc-dhcp-client/dhcpcd-base in ifupdown's Recommends: > Unless there is a strong objection, I'll file the override bug report. The point has always been to ship some ifupdown-supported DHCP client by default. This can be done either by keeping the default client's priority to important or by making ifupdown Depends on one. I prefer the later. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón wrote: > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > Greetings, > > > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > ... > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > the moment, and I'll make the relevant changes in ifupdown as soon as I > can. Josué, any thoughts? 1) As someone pointed out in the thread, the reason why isc-dhcp-client had priority:important probably was to ensure that debootstrap would pull it, since debootstrap ignores Recommends and packages with a priority lower than standard. 2) However, as long as ifupdown explictly depends on a package, it can also pull dependencies with a lower priority. Right now ifupdown Recommends "isc-dhcp-client | dhcp-client" which debootstrap would ignore. It would have to Depends "dhcpcd-base | dhcp-client" instead. 3) At that point, swapping the priority of isc-dhcp-client and dhcpcd-base merely becomes "nice to have". Heck, the priority of both could, in principle, be optional, just as long as ifupdown explicitly Depends on a DHCP client, and the first alternative is a real package. Martin-Éric
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón wrote: > El 19/06/23 a las 13:54, Martin-Éric Racine escribió: > > Seeing how the ISC DHCP suite has reached EOL upstream, now might be a > > good time to re-visit Debian's choice of standard DHCP client shipping > > with priority:important. > > > > I hereby propose bin:dhcpcd-base: > > > > 1) already supported by ifupdown. > > 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege > > separation. > > 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf > > 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail > > 5) a mere inet line in /etc/network/interfaces is sufficient to > > configure both stacks. > > I agree that dhcpcd seems the best alternative to isc-dhcp-client for > the moment, and I'll make the relevant changes in ifupdown as soon as I > can. Josué, any thoughts? I've never had to do this before, so I wonder if moving packages to severity: standard or higher (in this case, important) requires any decision from the CTTE or a similar authority, before we proceed? Martin-Éric
proposal: dhcpcd-base as standard DHCP client starting with Trixie
Greetings, Seeing how the ISC DHCP suite has reached EOL upstream, now might be a good time to re-visit Debian's choice of standard DHCP client shipping with priority:important. I hereby propose bin:dhcpcd-base: 1) already supported by ifupdown. 2) dual stack (DHCPv4, Bonjour, RA, DHCPv6 with PD) with privilege separation. 3) writes both IPv4 and IPv6 name servers to /etc/resolv.conf 4) supports /etc/resolv.conf.head and /etc/resolv.conf.tail 5) a mere inet line in /etc/network/interfaces is sufficient to configure both stacks. While dhcpcd development became somewhat erratic last year due to upstream's health issues, things are seemingly back to normal. Additionally, a new developer has joined and is willing to take over the development should upstream's health deteriorate again. Martin-Éric
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 11:44 PM Andreas Beckmann wrote:
>
> On 17/06/2023 20.30, Martin-Éric Racine wrote:
> > This is what I would do if the archive policy demands it. Won't affect
> > transitional dhcpcd5 or dhcpcd-base.
>
> Ack.
>
> I'm not sure whether the transitional dhcpcd5 package should have a
> versioned dependency on the "right" dhcpcd, either
> (= 1:${binary:Version}) or (>= 1:9). IIRC you need to add the epoch
> manually in the former case.
Merely re-introducing the epoch for bin:dhcpcd ought to be enough.
dhcpcd5 depends on a versionless dhcpcd. Thus:
override_dh_gencontrol:
dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION)
dh_gencontrol --remaining-packages
Would probably be enough to make this policy-compliant again.
Martin-Éric
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 6:39 PM Guillem Jover wrote: > By reading #594672 and a quick skim over #551034, these seem to have > been the same project, but the version introduced later as dhcpcd5 was > a new major version with an incompatible redesign, which would break > on upgrade, that's why it was not packaged at the time using the same > source package. So to me it makes sense to avoid adding the epoch to > avoid automatic upgrades like it was avoided in the past, otherwise > people might expect a smooth upgrade path. Also for reference the old > dhcpcd was removed from Debian in 2014: > > https://packages.qa.debian.org/d/dhcpcd.html 2016. > Unfortunately, even though this was long ago, there seems to still be > a short tail of such package installed on systems: > > https://qa.debian.org/popcon.php?package=dhcpcd5 Most of these are likely the result of transitional dhcpcd5 pulling in dhcpcd. > > The bug seems to only affect your binary package dhcpcd, so > > maybe a possible option could be to move ressources provided by > > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > > would avoid you the epoch bump and the hassle to handle the > > version bump from the old fork, but it also might confuse people > > using the package. What do you think? > > The only problem I see with leaving things as is, is that some users > might not notice they need to upgrade. It would be nice if we had some > way to notify of these kind of obsolete packages or upgrades. > > But if you end up deciding on adding the epoch, then yeah please, just > add it to the affected binary package (even though in this case that > matches the source package, so it's going to be sticking forever I guess > anyway :/). # Wheezy had (1:3.2.3-11+deb7u1) so reintroduce the epoch for one target. override_dh_gencontrol: dh_gencontrol --package=dhcpcd -- -v1:$(DEB_VERSION_UPSTREAM_REVISION) dh_gencontrol --remaining-packages This is what I would do if the archive policy demands it. Won't affect transitional dhcpcd5 or dhcpcd-base. Martin-Éric
Re: re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
On Sat, Jun 17, 2023 at 12:40 PM Étienne Mollier wrote: > Martin-Éric Racine, on 2023-06-16: > > Someone filed a bug asking to re-introduce an epoch. > > > > An older fork of the same package back in Wheezy last featured the epoch. > > > > Personally, I'm fine with either marking the bug as WONTFIX or > > re-introducing the epoch for one specific binary target whose name > > matches what was last seen in Wheezy. I simply want to hear what is > > the mailing list's concensus. > > The bug seems to only affect your binary package dhcpcd, so > maybe a possible option could be to move ressources provided by > the dhcpcd package to dhcpcd5 and remove the dhcpcd package. It > would avoid you the epoch bump and the hassle to handle the > version bump from the old fork, but it also might confuse people > using the package. What do you think? If you look at the other open bug, the point precisely was to get rid of the 5 completely. I found a simple override that would re-introduce the epoch only for bin:dhcpcd (but not for bin:dhcpcd-base or the transitional bin:dhcpcd5). I however wonder whether this is worth the trouble, given how far back the last occurrence of bin:dhcpcd goes. This being said, archive policy might mandate doing this even if the last occurrence of bin:dhcpcd dates back from 2016. Martin-Éric
re-introduction of epoch? #1037190 dhcpcd: version is lower than in wheezy
(non-subscriber, please keep me in CC) Someone filed a bug asking to re-introduce an epoch. An older fork of the same package back in Wheezy last featured the epoch. Personally, I'm fine with either marking the bug as WONTFIX or re-introducing the epoch for one specific binary target whose name matches what was last seen in Wheezy. I simply want to hear what is the mailing list's concensus. Martin-Éric
Bug#1035570: ITP: omemo-dr -- OMEMO double ratchet for Python
Package: wnpp Owner: deba...@debian.org Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, pkg-xmpp-de...@lists.alioth.debian.org * Package name: omemo-dr Version : 0.99.1 Upstream Author : Philipp Hörist * URL or Web page : https://dev.gajim.org/gajim/omemo-dr/ * License : GPL3 Programming Lang: Python Description : OMEMO double ratchet for Python Initial codebase was forked from python-axolotl, which is a Python 3 port of libaxolotol-android. The library is defined as a ratcheting forward secrecy protocol that works in synchronous and asynchronous messaging environments. This is a new dependency of Gajim >= 1.8.
Bug#1035482: ITP: webext-svg-screenshots -- SVG screenshots browser extension
Package: wnpp Owner: deba...@debian.org Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: webext-svg-screenshots Version : 0.11.6 Upstream Author : Felix Becker * URL or Web page : https://github.com/felixfbecker/svg-screenshots/ * License : MIT Programming Lang: JavaScript Description : SVG screenshots browser extension Browser extension to take semantic, scalable, accessible screenshots of websites, as SVG - as simple as taking a PNG screenshot.
Bug#1032926: ITP: bpftrace-mode -- simple major mode for bpftrace scripts
Package: wnpp Owner: deba...@debian.org Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: bpftrace-mode Version : 0.1.0 Upstream Author : Jay Kamat * URL or Web page : https://gitlab.com/jgkamat/bpftrace-mode * License : GPL3 Programming Lang: Elisp Description : simple major mode for bpftrace scripts bpftrace-mode is a simple mode for editing bpftrace files. It builds atop of cc-mode for indentation and syntax highlighting.
Re: Updating python3-xlrd for pandas 1.5 compatibility
On 2023-02-22 23:12, Diane Trout wrote: > | visidata | none | Build-Depends | There seems to be no versioned depends or similar in the code. Should be safe, but in doubt ask Anja (upstream). Cheers
Bug#1027445: ITP: mpv.el -- control a mpv via its IPC interface from Emacs
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: mpv.el Version : 0.2.0 Upstream Author : Johann Klähn * URL or Web page : https://github.com/kljohann/mpv.el/ * License : GPL3+ Programming Lang: Elisp Description : control a mpv via its IPC interface from Emacs This package is a potpourri of helper functions to control a mpv process via its IPC interface. To start playback, have a look at mpv-play (for single files) and mpv-start (for passing arbitrary arguments to mpv, e.g., URLs). Among others, mpv.el provides - mpv-pause - mpv-kill - mpv-seek-forward / mpv-seek-backward - mpv-speed-increase / mpv-speed-decrease - mpv-volume-increase / mpv-volume-decrease - mpv-insert-playback-position - mpv-seek-to-position-at-point - mpv-playlist-next / mpv-playlist-prev
Bug#1027005: ITP: emacs-debase -- D-Bus convenience layer for Emacs
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: emacs-debase Version : (no release yet) Upstream Author : Ian Eure * URL or Web page : https://codeberg.org/emacs-weirdware/debase * License : GPL3+ Programming Lang: Elisp Description : D-Bus convenience layer for Emacs Dependency for emacs-discomfort (ITP #1027004)
Bug#1027004: ITP: emacs-discomfort -- UDisks2 UI for Emacs, to mount & unmount disks
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: emacs-discomfort Version : (no release yet) Upstream Author : Ian Eure * URL or Web page : https://codeberg.org/emacs-weirdware/discomfort * License : GPL3+ Programming Lang: Elisp Description : UDisks2 UI for Emacs, to mount & unmount disks This is an Emacs major mode for interacting with UDisks2.
Bug#1024665: ITP: python-scpi -- Pure-python SCPI interface
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: python-scpi Version : 2.4.0 Upstream Author : Eero af Heurlin * URL or Web page : https://github.com/rambo/python-scpi/ * License : LGPL2.1+ Programming Lang: Python Description : Pure-python SCPI interface Basic idea here is to make transport-independent command sender/parser and a device baseclass that implements the common SCPI (Standard Commands for Programmable Instruments) commands.
Bug#1023539: ITP: SourceXtractorPlusPlus-- Access HMI, AIA and MDI data
Package: wnpp Owner: Martin Kuemmel Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org,debian-as...@lists.debian.org * Package name: SourceXtractorPlusPlus Version : 0.19 Upstream Author : Marc Schefer * URL : https://github.com/astrorama/SourceXtractorPlusPlus * License : LGPL v3 license: Programming Lang: C++ Description : Access HMI, AIA and MDI data SourceXtractor++ (Source-Extractor ++) is a program that extracts a catalog of sources from astronomical images. It is the successor to the original SExtractor package at: https://www.astromatic.net/software/sextractor/ It will maintained within the Debian Astronomy Working Group. A git repository will be created on salsa: https://salsa.debian.org/debian-astro-team/SourceXtractorPlusPlus.git There are two packages which are necessary to build SourceXtractorPlusPlus, the build framework Elements: https://github.com/astrorama/Elements and the library (I/O, threading etc.) Alexandria: https://github.com/astrorama/Alexandria These will be packaged separately. Best regards, Martin Kuemmel -- +--+ | Martin Kuemmel E-mail: mkuem...@usm.lmu.de | | LMU Faculty of Physics Skype: martin.kuemmel | | Scheinerstr. 1 Google: martin.kuem...@gmail.com | | D-81679 Muenchen Room: Container P06 | | Germany Phone: +49 89 2180-75976 | |__o | | _ \<._ | +_(_)/_(_)_+
Bug#1023295: ITP: python-twomemo -- python-omemo backend for OMEMO 2
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: python-twomemo Version : (no release yet) Upstream Author : Tim Henkes (Syndace) * URL or Web page : https://github.com/Syndace/python-twomemo * License : MIT Programming Lang: Python Description : python-omemo backend for OMEMO 2 Backend implementation for python-omemo, equipping python-omemo with support for OMEMO under the namespace urn:xmpp:omemo:2 (casually/jokingly referred to as "twomemo").
Bug#1023293: ITP: libxeddsa -- toolkit around Curve25519 and Ed25519 key pairs
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: libxeddsa Version : v2.0.0 (2022-04-02) Upstream Author : Tim Henkes (Syndace) * URL or Web page : https://github.com/Syndace/libxeddsa * License : MIT Programming Lang: C Description : toolkit around Curve25519 and Ed25519 key pairs A toolkit around Curve25519 and Ed25519 key pairs, with a focus on conversion between the two. Offers: - Conversion between Curve25519 and Ed25519 public keys - Extraction of private keys from seeds - Ed25519 digital signing using seeds or private keys - Ed25519 digital signature verification - X25519 Diffie-Hellman key agreement
Bug#1023102: ITP: golang-github-caarlos0-sshmarshal -- easily marshal SSH private keys
Package: wnpp Severity: wishlist Owner: Martin Dosch * Package name: golang-github-caarlos0-sshmarshal Version : 0.1.0-1 Upstream Author : The Go Authors * URL : https://github.com/caarlos0/sshmarshal * License : BSD-3-Clause Programming Lang: Go Description : Code copied from x/crypto and golang/go#37132 Library containing code copied from x/crypto (https://github.com/golang/crypto) and this patch (https://go- review.googlesource.com/c/crypto/+/218620/) so we can more easily marshal SSH private keys. Build-depend for newer versions of golang-github-charmbracelet-keygen. signature.asc Description: PGP signature
Bug#1023100: ITP: cancelreader -- A cancelable reader for Go
Package: wnpp Severity: wishlist Owner: Martin Dosch * Package name: cancelreader Version : 0.2.2-1 Upstream Author : Christian Muehlhaeuser * URL : https://github.com/muesli/cancelreader * License : Expat Programming Lang: Go Description : A cancelable reader for Go CancelReader . Latest Release (https://github.com/muesli/cancelreader/releases) Go Doc (https://pkg.go.dev/github.com/muesli/cancelreader) Software License (/LICENSE) Build Status (https://github.com/muesli/cancelreader/actions) Go ReportCard (https://goreportcard.com/report/muesli/cancelreader) . A cancelable reader for Go . This package is based on the fantastic work of Erik Geiser (https://github.com/erikgeiser) in Charm's Bubble Tea (https://github.com/charmbracelet/bubbletea) framework. This is a build-depend for newer versions of golang-github-charmbracelet-bubbletea. signature.asc Description: PGP signature
Bug#1023099: ITP: golang-github-mattn-go-localereader -- CodePage decoder for Windows
Package: wnpp Severity: wishlist Owner: Martin Dosch * Package name: golang-github-mattn-go-localereader Version : 0.0.1-1 Upstream Author : mattn * URL : https://github.com/mattn/go-localereader * License : Expat Programming Lang: Go Description : go-localereader . CodePage decoder for Windows This is a build dependency of newer golang-github-charmbracelet-bubbletea versions. signature.asc Description: PGP signature
Bug#1021759: ITP: py-rnp -- Python bindings for librnp
Package: wnpp Owner: deba...@debian.org Severity: wishlist * Package name: py-rnp Version : 0.1.0 Upstream Author : Daniel Wyatt * URL or Web page : https://github.com/rnpgp/py-rnp * License : (under investigation) Description : Intent to Package [ITP] Python bindings for librnp. RNP is a set of cross-platform tools implementing OpenPGP (RFC 4880) and related standards.
Re: Bits from the DAMs
Regarding the following, written by "Joerg Jaspert" on 2022-10-08 at 16:12 Uhr +0200: 3. Thresholds for DAM action In various recent discussions we have noticed people mention that they "cannot say this, or DAM may expel them". This is not backed by facts (we've only had to go through with 8 expulsions since 2006) and it originates from wrong assumptions. DAM action is the last step in a long process, with others involved first. This is not an accurate representation. There have been cases where DAM have threatened to expel (though the expulsion didn't happen, so didn't count in the statistics), and there was *no* long process with others involved first. In my case, you didn't even tell me details about the allegations (just the threat), nor heard my side of the story before wielding the big hammer. Not interested in relitigating the past. But I cannot let you get away with claiming that DAM has always been impartial. Good if this has since changed, and you guys have put in place protocols to ensure your own accountability. -- .''`. martin f. krafft @martinkrafft : :' : proud Debian developer `. `'` http://people.debian.org/~madduck `- Debian - when you have better things to do than fixing systems "i sometimes think that god in creating man somewhat overestimated his ability." -- oscar wilde digital_signature_gpg.asc Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Bug#1020762: ITP: mastodon.el -- Emacs client for the Mastodon and Pleroma social networks
Package: wnpp Owner: Martin Severity: wishlist * Package name: mastodon.el Version : 1.0.0 Upstream Author : Marty Hiatt and others * URL or Web page : https://codeberg.org/martianh/mastodon.el * License : GPL-3+ Description : Emacs client for the Mastodon and Pleroma social networks mastodon.el is an Emacs client for the Mastodon and Pleroma social networks. For info see https://joinmastodon.org/. Type M-x mastodon to start.
Changing the epoch of widelands package
Hello, as per policy 5.6.12, I'm seeking for a consensus for upgrading the epoch of the widelands package. The version currently in Debian is 1:21-2, corresponding to the upstream build21. Last year, upstream released their v1.0 after maybe two decades of developemnt, but our watch file didn't detect it because 1.0 < 21. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005370 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992626 I thus think that we should package the new version as 2:1.0-1. Do you people agree? Thanks, Mt. signature.asc Description: This is a digitally signed message part
Bug#1016022: ITP: actions-for-nautilus -- A Gnome Files (Nautilus) extension for creating selection context menu entries that can execute arbitrary commands
Package: wnpp Severity: wishlist Owner: Martin Bartlett X-Debbugs-Cc: debian-devel@lists.debian.org, martin.j.bartl...@gmail.com * Package name: actions-for-nautilus Version : 1.0.0 Upstream Author : Martin Bartlett * URL : https://github.com/bassmanitram/actions-for-nautilus * License : Apache-2.0 license Programming Lang: Python, Javascript, HTML Description : A Gnome Files (Nautilus) extension for creating selection context menu entries that can execute arbitrary commands A "replacement" for the now-defunct filemanager/nautilus-actions project. The extension supports many of the most commonly used features of the defunct project, including: * structuring context menu items for Nautilus File Manager selections including nested sub menus filtering the displayed items based on: * number of files in the selection, * mimetypes of the selected files (matching and non-matching conditions supported, as well as mimetype globs) * basic filetypes of the selected files - e.g. 'file', 'directory', 'symbolic- link' ... - (matching and non-matching conditions supported) * execution of an arbitrary command/script when a menu item is activated A configuration application by the name "Actions For Nautilus Configurator" is installed into the desktop applications collection. On first use of the configurator, if no existing configuration file is found, the delivered sample configuration will be installed. Maintenance should be trivial (it's a tiny extension) and I intend to provide that myself (though collaborators are always welcome). Translation is an issue - this is entirely in English at the moment. I am looking for a sponsor, of course.
Help needed with a dh_shlibs failure on non amd64 platforms
Hello all, I come to you because I'm puzzled with a bug I have in one of my package, and I'm seeking for help. Please CC me when answering as I'm not on this list. The package is ns3, a scientific simulator of computer networks. This package is huge, I seem to be the only active maintainer, but upstream is very collaborative. Upstream just moved from a build system called waf to cmake, which is an nice move. They introduced a small python script saving the waf interface to their users that don't like changes, and unfortunately the raw cmake interface is not usable yet (cmake checks on files created by the script), so I cannot use the plain classical cmake build in debian/rules. I did my best to mimick the behavior of `dh --buildsystem=cmake` but I have a strange failure on non-amd64 platforms: https://buildd.debian.org/status/package.php?p=ns3 The build, tests and install targets go well, until dh_shlibdeps. At that step, I get a huge bunch of errors like the following: ``` dh_shlibdeps -a dpkg-shlibdeps -Tdebian/libns3.36.substvars debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wimax.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wifi.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-wave.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-visualizer.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-virtual-net-device.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-uan.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-traffic-control.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-topology-read.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-tap-bridge.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-stats.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-spectrum.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-sixlowpan.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-propagation.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-point-to-point-layout.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-olsr.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-nix-vector-routing.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-network.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-netanim.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mobility.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-mesh.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lte.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-lr-wpan.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet-apps.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-flow-monitor.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-fd-net-device.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-energy.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsr.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-dsdv.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-csma-layout.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-core.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-config-store.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-buildings.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-bridge.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-applications.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-aodv.so.36.1 debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-antenna.so.36.1 dpkg-shlibdeps: error: cannot find library libns3-bridge.so.36.1 needed by debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 (ELF format: 'elf64-littleaarch64' abi: '020100b7'; RPATH: '') dpkg-shlibdeps: error: cannot find library libns3-traffic-control.so.36.1 needed by debian/libns3.36/usr/lib/x86_64-linux-gnu/libns3-internet.so.36.1 (ELF format: 'elf64-littleaarch64' abi: '020100b7'; RPATH: '') ``` This specific one is for arm64, but I get exactly the same problem for all platforms but amd64. https://buildd.debian.org/status/fetch.php?pkg=ns3=arm64=3.36.1%2Bdfsg-2=1656893780=0 All libraries (eg libns3-bridge.so.36.1) that it cannot find are part of the package. They are added to the debian/libns3.36/DEBIAN/shlibs a few lines above in the build log, and dh_strip found them further above in the log. What really puzzles me is that the package builds fine on amd64 and i386. The package is uptodate on salsa, in case someone wants to test something directly on the package. Fear not to do so, this package only takes one hour to build on my machine :) If you wonder, the cmake macro to define and build a library is in ns-3.36.1/build-support/custom-modules/ns3-module-macros.cmake I already had to patch it to support Debian:
Re: enabling link time optimizations in package builds
Adrian Bunk: > On Fri, Jun 17, 2022 at 10:18:43AM +0200, Matthias Klose wrote: ... > > >... > > Link time > > optimizations are also at least turned on in other distros like Fedora, > > OpenSuse (two years) and Ubuntu (one year). > >... > > The idea is to file wishlist bug reports for those 373 packages and then see > > how far we get, and if it's feasible to already turn on LTO for bookworm. > > If not, it should be turned on by default for the following release. > > I assume these 373 packages have already been fixed/workarounded in Ubuntu? > Submitting 373 bugs with patches should settle the feasibility question. > For my software (bart), it triggers a compiler bug where the compiler crashes. Martin > A bigger worry is the schedule of such a change. > A major toolchain change shortly before the freeze means the vast > majority of packages will be shipped with non-LTO builds in the release, > with security updates or point release updates triggering a change to > an LTO built package. > This means few packages actually benefitting from LTO, but a higher > regression risk when fixing bugs in stable. > The best timing for such a change would be immediately after the release > of bookworm. >
Re: cups-pdf is marked for autoremoval from testing
Dev list, Someone apparently made a commit to the autoremoval hinter that makes it mark packages unrelated to an RC-bug package getting marked for autoremoval. Could someone please look into this? Thanks! Martin-Éric On Thu, May 26, 2022 at 10:38 AM Debian testing autoremoval watch wrote: > > cups-pdf 3.0.1-14 is marked for autoremoval from testing on 2022-06-30 > > It (build-)depends on packages with these RC bugs: > 1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183, > CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192 > https://bugs.debian.org/1011146 > > > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Bug#1009373: ITP: xmppconsole -- tool for XMPP hackers
Package: wnpp Owner: Martin Severity: wishlist * Package name: xmppconsole Version : git master 2020-10-18 Upstream Author : Dmytro Podgornyi * URL or Web page : https://github.com/pasis/xmppconsole * License : GPL-3+ Description : tool for XMPP hackers This tool sends raw XMPP stanzas over an XMPP connection and displays the XMPP stream. Main purpose is to study XEPs and debug implementation of XMPP entities. xmppconsole has multiple options which you can review with --help argument. It allows you to connect to a server with misconfigured TLS and/or DNS record. Also, you can connect to a server anonymously if the server supports this. Or you can even start working with XMPP connection before authentication and debug in-band registration or authentication mechanisms. The package will be maintained here: https://salsa.debian.org/xmpp-team/xmppconsole
ITP: golang-github-protonmail-go-mime -- Go Mime Wrapper Library
Package: wnpp Severity: wishlist Owner: Martin Dosch * Package name: golang-github-protonmail-go-mime Version : 0.0~git20220302.303f85f-1 Upstream Author : Proton Technologies AG * URL : https://github.com/ProtonMail/go-mime * License : Expat Programming Lang: Go Description : Go Mime Wrapper Library Go Mime Wrapper Library . Download/Install . Run go get -u github.com/ProtonMail/go-mime, or manually git clone the repository into $GOPATH/src/github.com/ProtonMail/go-mime. Build dependency for golang-github-protonmail-gopenpgp which will be needed for the upcoming Ox (OpenPGP for XMPP) support in go-sendxmpp. signature.asc Description: PGP signature
Re: Debian Project Leader election 2022: Second call for votes
> -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > 8802d270-eac5-4cbe-b2f4-1c4e4bba968f > [ 3] Choice 1: Felix Lechner > [1 ] Choice 2: Jonathan Carter > [ 3] Choice 3: Hideki Yamane > [ 2] Choice 4: None Of The Above > - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > - -- > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEF+8H5vWenz4W4MCiWexD1lJGUIsFAmJRocgACgkQWexD1lJG > UIux7Q/7BPhGtHy1VBHHKQ9RTzBPHh3BNLBGleqjX00ErEqwn+UDua+xcDVeSZTj > Ejuj1G5SMqqyL3wTevy4YqnaxKOOuggNXpF/LmARtVNUQ/jinTlOW6njsUk5dPFg > itKBedWvMMZRFqF/BZFLIpE9HYParC8dKfXP/c2MXVkO+OZAb8iAcxcgZiC4fMp0 > 5mEQ3SFkItCkALcUU2pBQmtOPFrsvOiqJojuqOPcP8BWsi1/alVBONzSWzf54rjl > 9sPwqG7xmM3t3TwcZ0hXgBr+2UDUa+Mtj4A/0/0jsIM2fesSNQPIn+FdwoFWLEPn > l5brV50lWT2KJkXEeAwFCmxCdTZoXh+WmSi7YiDENAkb8ofQZsFFd9gm+CGftVmC > YW5w3LvafrU/rZAd1PRptlIp43urddhquqquE4ZE9LUjC5EZol8SJ1210wMOs0I1 > Y8LHqpRRXae/pkCFb3K0ep3lIERnmxVJVK41nvWPf0Z/XP52/1IxsVFotEeK0UXu > 9TfaxeFYU2GA+/hbjpPEWtwkh58tXsxiX0tIJF4ps9PjmMcdNkNbTnzO59TFd3YP > /DbMDxShBaUp2vpkYC/pZWu4OcHUMipL5TaOxQtUgD8u+NdXJOLleeAlaLrh57Zi > 2VrKkuAhKjvoM2TUiKHFhqj3LamP9FRgTaKurgRFtA/n4+vk+28= > =H5z8 > -END PGP SIGNATURE-
Bug#1009142: ITP: org-appear -- auto-toggle visibility of org mode elements
Package: wnpp Owner: Martin Severity: wishlist * Package name: org-appear Version : 0.3.0 Upstream Author : Alice Istleyeva * URL or Web page : https://github.com/awth13/org-appear * License : MIT Description : auto-toggle visibility of org mode elements Org mode provides a way to toggle visibility of hidden elements such as emphasis markers, links, etc. by customising specific variables, e.g., org-hide-emphasis-markers. This package, inspired by org-fragtog, enables automatic visibility toggling depending on cursor position. Hidden element parts appear when the cursor enters an element and disappear when it leaves. https://raw.githubusercontent.com/awth13/org-appear/master/demo.gif (Very useful, should be part of org-mode itself.)
Bug#1008738: ITP: python-cobs -- Consistent Overhead Byte Stuffing for Python
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-cobs Version : v1.2.0 Upstream Author : Craig McQueen * URL : https://github.com/cmcqueen/cobs-python/ * License : MIT Programming Lang: Python Description : Consistent Overhead Byte Stuffing for Python The cobs package is provided, which contains modules containing functions for encoding and decoding according to COBS methods. I intent to maintain this package under the umbrella of the Debian Python Team.
Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Control: affects -1 src:dhcpcd5 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Given how upstream ISC will stop development of its DHCP suite by the end of 2022 [1], Debian will need to select a new stock DHCP client to ship with Priority:Important. dhcpcd5 seems like the most potential replacement. It covers most IPv4 and IPv6 usage cases, and upstream regularly updates the code. However, the Debian package hasn't been updated in ages. A bug was filed asking for the latest upstream release to be packaged was filed [2] but remains unanswered nearly 2 years later. A recent comment by Michael Biebl suggests that current versions of Network-Manager ship with support for this, but it would require a MUCH more recent version than what Debian currently ships. I therefore think that dhcpcd5 deserves plenty of maintainance help, perhaps even a new maintainer. Martin-Éric The package description is: dhcpcd is a one stop network management daemon which includes * RFC compliant DHCPv4 and DHCPv6 clients * DHCPv6 Prefix Delegation support * IPv4LL (aka ZeroConf) support * ARP address conflict resolution * Link carrier detection * Wireless SSID profiles * ARP ping profiles 1. <https://www.isc.org/blogs/dhcp-client-relay-eom/> 2. <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964947> -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIUqzkACgkQrh+Cd8S0 17ZAwg/+Oy+N3Hw15+5MJ/VtdhZotqzROhyRjVp9JRVs9ql/43jea4LZFQjwvmfx he/KZlN/iYPR8Ky8PWD5U02ywN+wtlfxC39DLwtsPhylT70hNMydAh1+IHQKgope IbYIfDG2V90nat42GNU7v0+PPHey8OXnvgmXuffhm2I8q43qMd1CJ/Q8HYlILtu6 ApbNAeo8i/q17BhqqKoT6YfS0o83MgMvSdSCZQhBLg/r1tZUMeONbkc2fNeC8sif AdZEBDiiXN2blRAwDEHj6uCOEuucxfCWdp3zZEiw7konCilYuCejB479B+UiJtlY rgdBvrrffb/E38S0q/04PlOG40R9BfJ79ksvvYvo0uzNwg6X+7u102Vy/ZXAxAIW x0myHLmg3npaq9bFP/w8hK12Vsi+BfDZ7aZCH3VIu72scaFgjxIYWSdd9MGDDhP1 prs91poRDFAvlS5cuolz4wHntexkG4VB14fDaHmmTY9g+IiF5CGFmcLxdtmiJwNN oQanaK9K8EU4uaF5VT8IYymSeO0HsSqZre9dIaF9d3HOUWYTtopRpAxhmbH6F0UO 2YUAJ/PO22ygprwubz+AfhFJwp1o6kLd+0ui0Kca3t8GwEHw+y3NBvTCnIfayXxp jbSRipyvtkRK1+n8uK97sty7B+HMG9T5D4vQjrdynmNUcDYx69I= =hiw9 -END PGP SIGNATURE-
golang-debian-mdosch-xmppsrv -- Lookup xmpp srv records
Package: wnpp Severity: wishlist Owner: Debian Go Packaging Team * Package name: golang-debian-mdosch-xmppsrv Version : 0.1.0-1 Upstream Author : "Martin Dosch" * URL : https://salsa.debian.org/mdosch/xmppsrv * License : BSD 2-Clause Programming Lang: Go Description : Lookup XMPP SRV records Build requirement for go-sendxmpp signature.asc Description: PGP signature
Bug#995189: RFH: isc-dhcp
Package: wnpp Severity: normal X-Debbugs-Cc: debian-devel@lists.debian.org Control: affects -1 src:isc-dhcp -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The ISC DHCP suite has a lenghty list of bug reports that have been left unattended. Some bugs date back to DHCP 3 or even earlier. Additionally, recent upstream releases are still unpackaged. One release came out well ahead of the Bullseye freeze, a bug report requesting its packaging was filed, but it remains unanswered. Leaving a package with a priority Important in such utter state of neglect is unacceptable. At this point, it has become clear that, at the very least, its maintainers need help, hence why I filed this WNPP bug. - -- Martin-Éric -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmFR/noACgkQrh+Cd8S0 17apRA/9EnsfZnMsWBz07360Z8fqdoZWteKo3Weqfa7lhfVXqHaaWKR1k83uY3gO DEP+NGdDqMs5LVhQ4eDvEeMze2utCx52C2GFHebksI1QyaGruj9PSEu0j5CIBlKu v/fXdk9BXk3oQ4bJoKM8HBifNVx/ICb1X/4wdr78dy4ZYQLB+XLkbQ5DGn/UJ4mr VQctq/uxjFFY1zD+C5Mu7jG/X8eEbSXcshtMkxcoO3GW0c/Bmmy7Rm2exs1zHOkX fAiULeThKPJkpYgbiw6+iPZiJqWeeoDtXo8gInuw8riP3sua9PxhEwKnZBEcACJ3 BAT5ethXxAhC5Ecd+pzuqzlTrP9FYDqPyie3If0A9XK1sDPsnnn5yERWeuAn8L2E 7tZ5BAuBCEskQ+Z9Q1MqgK8/yeabzZRzmd2VCy+FXMfENjhDeGm1YefPSD80mebG UGVbN1MC9274pv6oomPkM6fQidIcbUIZDlBj2qJOxFWgXuv3jcnzWs4+XV9VssiD s/B5+YC9XvItCpZKjAUBaXDUX/hzPqFoseRygRPChxgrzyvP7ChWSz1JY9G73EYg ITe7KHQ9wqAMPJYmUp0ZmcACn9tCWH/xSt99KLrnYURPxNHcYpG8+Pwr5r9swJ50 fjkEyEZWCNUu6u8uUvSx5sPrc29aIpuk+QXeBJIsAB24roy8ONo= =5hUD -END PGP SIGNATURE-
Bug#991607: ITP: emacs-bash-completion -- add programmable bash completion to Emacs shell-mode
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: emacs-bash-completion Version : 3.1.0 (2020-08-06) Upstream Author : Stephane Zermatten * URL : https://github.com/szermatt/emacs-bash-completion * License : GPL-2+ Programming Lang: Emacs-Lisp Description : add programmable bash completion to Emacs shell-mode bash-completion.el defines dynamic completion hooks for shell-mode and shell-command prompts that is based on bash completion. Bash completion for Emacs: * is aware of bash builtins, aliases and functions * does file expansion inside of colon-separated variables and after redirections (> or <) * escapes special characters when expanding file names * is configurable through programmable bash completion * works on remote shells, through TRAMP.
Bug#990926: ITP: elpa-ace-window -- Quickly switch windows in Emacs
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org Control: block 990909 by -1 * Package name: elpa-ace-window Version : 0.10.0 Upstream Author : Oleh Krehel * URL : https://github.com/abo-abo/ace-window * License : GPL-3+ Programming Lang: Emacs-Lisp Description : Quickly switch windows in Emacs Ace Window (or ace-window) is an Emacs command which is designed to improve on and replace Emacs’ built-in other-window command (which by default is bound to C-x o) for switching between Emacs Windows. This is a dependency of treemacs, but useful on its own.
Bug#990925: ITP: elpa-pfuture -- set of functions wrapping Emacs' process creation capabilities
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org Control: block 990909 by -1 * Package name: elpa-pfuture Version : 1.9 Upstream Author : Alexander Miller * URL : https://github.com/Alexander-Miller/pfuture * License : GPL-3+ Programming Lang: Emacs-Lisp Description : set of functions wrapping Emacs' process creation capabilities pfuture.el offers a set of simple functions wrapping Emacs’ existing process creation capabilities. It allows to conveniently deal with external processes in an asynchronous manner without having to worry about stdout buffers and filter- & sentinel-functions. This is a dependency of treemacs.
Bug#990811: ITP: elpa-emacs-dashboard -- extensible emacs startup screen showing you what's most important
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: elpa-emacs-dashboard Version : 1.7.0 Upstream Author : Rakan Al-Hneiti * URL : https://github.com/emacs-dashboard/emacs-dashboard * License : GPL-3 Programming Lang: Emacs-Lisp Description : extensible emacs startup screen showing you what's most important Features 1. Displays an Emacs banner 2. Recent files 3. Bookmarks list 4. Recent projects list (Depends on `projectile` or `project.el` package) 5. Org mode agenda 6. Register list
Bug#986830: ITP: sscg -- simple SSL certificate generator
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: sscg Version : 2.6.2 Upstream Author : Stephen Gallagher * URL : https://github.com/sgallagher/sscg/ * License : GPL-3+ with OpenSSL exception Description : sscg is a utility to aid in the creation of more secure "self-signed" certificates. The certificates created by this tool are generated in a way so as to create a CA certificate that can be safely imported into a client machine to trust the service certificate without needing to set up a full PKI environment and without exposing the machine to a risk of false signatures from the service certificate. See this blog post for details: https://sgallagh.wordpress.com/2016/05/02/self-signed-ssltls-certificates-why-they-are-terrible-and-a-better-alternative/ Cockpit's web server makes use of sscg if it is available, as a slightly better alternative than direct self-signed certificates. CC'ing upstream author Stephen for questions about the functionality. I recently sent the Debian packaging to the upstream project, where it will run in CI for each PR: https://github.com/sgallagher/sscg/pull/22 Thanks, Martin signature.asc Description: PGP signature
Re: Realtek RTL8723DE, RTL8821CE, RTL8822BE and RTL8822CE chipsets
El dom, 4 abr 2021 a las 12:28, Devops PK Carlisle LLC () escribió: > > This is interesting. > > First, I must ask... Are either Ralink or Atheros more quickly adopted > into Linux support before Realtek? Are they more stable, etc.? (In my > original post, I noted that I pulled a Realtek based 5ghz dongle from an > extreme end user system, in no small part due to stability/reliability)? I do not think so, I guess this mostly depends on how many people are involved with each driver and how well tested is the code. In the particular case of rtw88 driver (the one supporting chipsets in the subject), it is maintained by Realtek folks with additional contributions from the community. Some chipsets are supported, some not yet. For the case I know (rtl8821ce), original chipset is supported, but support for other variants (e.g., rfe 2) was late for 5.11 (Realtek tests took longer than expected), but will be present in 5.12 kernel, requiring new firmware (https://lkml.org/lkml/2021/2/2/76). I think the best option is to wait for that kernel and firmware to reach debian-backports. For other variants of other chipsets things may be fifferent. Regards, -- Agustin
Bug#985909: ITP: open62541 -- implementation of OPC UA (IEC 62541)
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: open62541 Version : 1.2 Upstream Author : various (*) * URL : http://open62541.org * License : MPL-2.0 Programming Lang: C Description : implementation of OPC UA (IEC 62541) open62541 is an implementation of OPC UA (OPC Unified Architecture) written in the common subset of the C99 and C++98 languages. The library is usable with all major compilers and provides the necessary tools to implement dedicated OPC UA clients and servers, or to integrate OPC UA-based communication into existing applications. (*) https://github.com/open62541/open62541/blob/master/AUTHORS
Bug#985768: ITP: cockpit-machines -- Cockpit user interface for virtual machines (source splitout from cockpit)
Package: wnpp Severity: wishlist Owner: Martin Pitt * Package name: cockpit-machines Version : 241 Upstream Author : Cockpit development team * URL : https://github.com/cockpit-project/cockpit-machines/ * License : LGPL-2.1+ Description : The Cockpit Web Console enables users to administer GNU/Linux servers using a web browser. . This package adds an user interface for managing virtual machines. . If the "virtinst" package is installed, you can also create new virtual machines. This has existed as a binary package [1] built from the cockpit source [2] for quite some time already. For various reasons split out this component into a separate project [3], and will remove it from cockpit.git soon. This is similar to cockpit-podman [4]. The first upstream release 241 [5] is a clean code copy. This provides a clean upgrade path from the last official cockpit release 240 which still built -machines. As such I hope to get it into experimental relatively soon, so that uploading new cockpit releases don't get blocked for too long. Thanks, Martin [1] https://packages.debian.org/sid/cockpit-machines [2] https://tracker.debian.org/pkg/cockpit [3] https://github.com/cockpit-project/cockpit-machines/ [4] https://tracker.debian.org/pkg/cockpit-podman [5] https://github.com/cockpit-project/cockpit-machines/releases/tag/241 signature.asc Description: PGP signature
Bug#985113: ITP: libqrtr-glib -- library to manage and access the QRTR (Qualcomm IPC Router) bus
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libqrtr-glib Version : 1.0.0 Upstream Author : Eric Caruso , Andrew Lassalle , Aleksander Morgado * URL : https://gitlab.freedesktop.org/mobile-broadband/libqrtr-glib * License : LGPLv2+ Programming Lang: C Description : library to manage and access the QRTR (Qualcomm IPC Router) bus libqrtr-glib is a glib-based library to use and manage the QRTR (Qualcomm IPC Router) bus. This is a new optional dependency of libqmi >= 1.28.x.
Bug#984898: ITP: elpa-docbook -- Info-like viewer for DocBook
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: elpa-docbook Version : 0.1 Upstream Author : Chong Yidong * URL : https://elpa.gnu.org/packages/docbook.html * License : GPL3+ Programming Lang: Emacs-Lisp Description : Info-like viewer for DocBook A simple, Info-like viewer for DocBook files. Entry point: M-x docbook-find-file
Bug#984640: ITP: elpa-subed -- Emacs mode for editing subtitles while playing the corresponding video
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: elpa-subed Version : git master 49ddccc Upstream Author : Random User * URL : https://github.com/rndusr/subed * License : GPL3+ Programming Lang: Emacs-Lisp Description : Emacs mode for editing subtitles while playing the corresponding video subed is an Emacs major mode for editing subtitles while playing the corresponding video with mpv. At the moment, the only supported formats are SubRip (.srt) and WebVTT (.vtt).
Bug#983062: ITP: python-emoji -- Emoji for Python
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, team+pyt...@tracker.debian.org * Package name: python-emoji Version : 1.2.0 Upstream Author : Taehoon Kim and Kevin Wurster * URL : https://pypi.org/project/emoji/ * License : BSD Programming Lang: Python Description : Emoji for Python The entire set of Emoji codes as defined by the unicode consortium is supported in addition to a bunch of aliases. By default, only the official list is enabled but doing emoji.emojize(use_aliases=True) enables both the full list and aliases.
Bug#982659: ITP: elpa-darkroom -- remove visual distractions and focus on writing
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: elpa-darkroom Version : 0.3 Upstream Author : João Távora * URL : http://elpa.gnu.org/packages/darkroom.html * License : GPL3+ Programming Lang: Emacs-Lisp Description : remove visual distractions and focus on writing darkroom-mode makes visual distractions disappear: the mode-line is temporarily elided, text is enlarged and margins are adjusted so that it's centered on the window.
Bug#982658: ITP: org-tree-slide -- presentation tool for org-mode
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-emac...@lists.debian.org * Package name: org-tree-slide Version : 2.8.16 Upstream Author : Takaaki ISHIKAWA * URL : https://github.com/takaxp/org-tree-slide * License : GPL3+ Programming Lang: Emacs-Lisp Description : presentation tool for org-mode The main purpose of this elisp is to handle each tree in an org buffer as a slide by simple narrowing. This emacs lisp is a minor mode for Emacs Org-mode. Main features: - Live editable presentation - Fast switching of narrowing/widen - TODO pursuit with narrowing - Displaying the current number of slides in mode line - CONTENT view during a presentation - Slide-in effect - Slide header from org file’s header - Countdown timer
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
Hi. Any progress here? Or any way to help? Am 01.09.20 um 19:17 schrieb Moritz Muehlenhoff: >> It may be more future-proof, in case we need it for a future >> rustc for the next ESR bump. > > My gut feeling is the next ESR thing will need LLVM 11 or so, but happy to > be proven wrong :-) So maybe let's directly move to 10 directly. > > Once uploaded and acked threw NEW, I'll upload wasi-lib rebuilt against > LLVM, then. >
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
Hi, I am not shure if I can help, but I can try and have a look at it. Yes please upload your LLVM9 and wasi-libc backports. Regards Christoph Am 31.08.20 um 20:26 schrieb Moritz Mühlenhoff: > >> I think we can reuse the same approach as before, by staging uploads >> in -proposed-updates (or on stretch-security respectively) and then >> configure the security chroots to use -proposed-updates until 10.6 >> is eventually released. > > I can upload my backports of LLVM and wasi-libc, but this still needs a > volunteer for > the remaining parts (rustc/cargo) if we want to have firefox-esr / thunderbird > in Buster after the end of ESR68. > Christoph signature.asc Description: OpenPGP digital signature
Bug#961685: ITP: python-aiohttp-proxy -- full-featured proxy connector for aiohttp
Package: wnpp Severity: wishlist Owner: Martin * Package name: python-aiohttp-proxy Version : 0.1.1 Upstream Author : Skactor * URL : https://github.com/Skactor/aiohttp-proxy * License : Apache-2.0 Programming Lang: Python Description : full-featured proxy connector for aiohttp This library provides a SOCKS proxy connector for aiohttp. HTTP, HTTPS, SOCKS4(a) and SOCKS5(h) proxies are supported.
Bug#956705: ITP: python-pydiscourse -- Python library for working with Discourse
Package: wnpp Severity: wishlist Owner: Martin * Package name: python-pydiscourse Version : v1.0.0 Upstream Author : Marc Sibson and contributors * URL : https://github.com/bennylope/pydiscourse * License : MIT Programming Lang: Python Description : Python library for working with Discourse >From the README: > A Python library for working with Discourse. > > This is a fork of the original Tindie version. It was forked > to include fixes, additional functionality, and to distribute > a package on PyPI. > > Goals > > * Exceptional documentation > * Support all supported Python versions > * Provide functional parity with the Discourse API, for the > currently supported version of Discourse (something of a > moving target) > > The order here is important. The Discourse API is itself > poorly documented so the level of documentation in the Python > client is critical.
go-sendxmpp debian package preparations
Dear all, I prepared a debian package for go-sendxmpp [1] as well as for the dependencies getopt [2] and mattn/go-xmpp [3]. It would be nice if someone could check them and add them to debian if all is well. If not I'd appreciate any feedback. Best regards, Martin [1] https://salsa.debian.org/mdosch-guest/go-sendxmpp/-/tree/debian/master [2] https://salsa.debian.org/mdosch-guest/golang-github-pborman-getopt [3] https://salsa.debian.org/mdosch-guest/golang-github-mattn-go-xmpp signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On 2020-03-14 13:37, Sean Whitton wrote: > (packages in NEW must not be downloaded from ftp-master.d.o to your > local machine) Just curious: Why is that the case? > - cope well with flames in response to your decisions Flames equal emotional expression of frustration or flames equal inappropriate swearing at volunteers?
Re: Heads up: persistent journal has been enabled in systemd
Sam Hartman - 06.02.20, 17:11:20 CET: > >>>>> "Martin" == Martin Steigerwald writes: > Martin> Well, that is *exactly* why I thought the GR is not going > to Martin> be helpful. > > Martin> Cause in *no way* it appeared to have *solved* the > conflict Martin> underneath it. > > No the GR did not somehow magically cause people to agree. > It did decide what Debian is going to do. > That's already had significant positive impacts even on this thread. I replied in private. This is the public part of my reply – I apologize for anything in there that someone may receive as other than non- violent, I tried the best to write from my point of view, but this is going to be emotional: Your reply exactly shows the kind of toxic way to communicate that the GR invited to the project. A way to communicate that lacks empathy and compassion which is necessary for splits in communities to heal. From what I can see you are doing a huge disservice to the Debian community with an reply like this – deepening the split that is already there and has never been healed so far –, but there is no point in bringing that up in detail here at this moment. I continue to stay unsubscribed as I unsubscribed for a reason. I can let go putting up with the toxic way to communicate that I have seen and even experienced on this list more than once and that in that way I never ever saw or experienced on mailing lists of communities like KDE or Devuan. I love myself and I am not putting up with that kind of toxic communication anymore. Please refrain from answering to me and (!) to the mailing list like you did in your reply. I unsubscribed from this list for a reason and at least for now do not intend to read what people write after I left. You can rant all the way you want about what I wrote, but please leave me out of it. So this is the public part of it. Again, I respectfully ask you to leave me alone if you have nothing constructive or supportive to tell me – and what you wrote me, Sam, clearly was neither supportive nor constructive for me. At the very least, do reply privately to me if you feel you must do that. I my delete any further mail on this without notification. I just replied to this one in public as well as you wrote it to the mailing list *and* to me, even tough I told I am going to unsubscribe, and I did not want to let it sit there without an reply. Best, -- Martin signature.asc Description: This is a digitally signed message part.
Re: Heads up: persistent journal has been enabled in systemd
Martin Steigerwald - 06.02.20, 14:32:57 CET: > Ansgar - 06.02.20, 13:25:06 CET: > > On Thu, 2020-02-06 at 12:30 +0100, Martin Steigerwald wrote: > > > Especially as I found that I did not use journalctl in my daily > > > practice anyway. > > > > Given you wrote earlier that you moved all but one of your machines > > away from Debian, whatever Debian installs by default doesn't affect > > you anyway. > > > > I don't write on mailing lists of distributions I don't use (or only > > use a bit) arguing about what is included in their default > > installation, though one could argue that emacs should be installed > > everywhere by default. > > That I do not use Debian anymore on all except one of my system does > not mean that I still feel bonds with the project, especially some > teams of it, like the Debian Qt KDE team. > > Also it does not (yet) mean that I abandoned my packaging efforts for > it. > > But of course, if you like to get rid of contributors, feel free to > pursue this kind of "go away already!" attitude. > > To be very clear: After your comment I feel *unwelcome* here. Okay, it is time to draw a conclusion out of this: I choose not to repeat the same pattern as with previous discussions. I have seen how people have been made unwelcome on debian-devel just for *sharing* their concerns and points of view quite some times here. So I leave, for now at least. I feel unwelcome here. Now I welcome and accept that feeling. If you have nothing constructive or supportive about this please refrain from contacting me. I may just delete any non-supportive mail without any notification. I am at a loss how Debian can resolve the underlying conflict at the moment. I see how the GR certainly did not achieve this. Whether I will leave Debian altogether and/or abandon my packaging work is not up for decision today for me. I do not make such a decision lightly, especially after the personal bonds and relationships I have with some of the contributors to this project. But for now participating in discussions on debian-devel does not appear to be a healthy use of my time. So I stop doing that. For now at least. Best of success for moving through to a better outcome for everyone involved. For now, I am out. Best, -- Martin signature.asc Description: This is a digitally signed message part.
Re: Heads up: persistent journal has been enabled in systemd
Ansgar - 06.02.20, 13:25:06 CET: > On Thu, 2020-02-06 at 12:30 +0100, Martin Steigerwald wrote: > > Especially as I found that I did not use journalctl in my daily > > practice anyway. > > Given you wrote earlier that you moved all but one of your machines > away from Debian, whatever Debian installs by default doesn't affect > you anyway. > > I don't write on mailing lists of distributions I don't use (or only > use a bit) arguing about what is included in their default > installation, though one could argue that emacs should be installed > everywhere by default. That I do not use Debian anymore on all except one of my system does not mean that I still feel bonds with the project, especially some teams of it, like the Debian Qt KDE team. Also it does not (yet) mean that I abandoned my packaging efforts for it. But of course, if you like to get rid of contributors, feel free to pursue this kind of "go away already!" attitude. To be very clear: After your comment I feel *unwelcome* here. If Debian is to become a Systemd only distribution, by all means, then I bet it is time for me to leave. *sigh* If there is still willingness to resolve the underlying conflict in a way that everyone can win, I still like to be in and help to move that along as best as I can. > > So why would removing rsyslog from the default install the only > > viable approach to solve duplicate logging? > > If the rsyslog maintainer is also fine with this (which I'll assume he > is), I think there's no real problem if that would be done. I might Can we for starters agree on not *assuming* things? Especially when it comes to issues people feel strongly about? > install rsyslog by hand on a few systems then, but that's not a real > problem given I already have to install other packages anyway... > > I have no problem installing a different MTA than Debian's default > (exim), my preferred shell, my preferred editor and so on either. I usually install Postfix everywhere, but… does that somehow remove my right to voice my concern about removing rsyslog from the default install of Debian here? Is this mailing list a place where people are not allowed to state their concern and their preferences anymore? Where they receive "shut up" messages when they try to do so? I have been contacted off list in a supportive way already. From someone who apparently does not like to raise his voice on this list anymore. Ciao, -- Martin
Re: Heads up: persistent journal has been enabled in systemd
Martin Steigerwald - 06.02.20, 12:26:32 CET: > Vincent Bernat - 06.02.20, 07:58:32 CET: > > ❦ 6 février 2020 09:50 +11, Dmitry Smirnov : > > >> and 2) continuing to use rsyslog isn't an option if the default > > >> changes.> > > > > > > No. I just don't want default to change. IMHO rationale for this > > > is > > > weak but everybody keeps arguing that it would not be a big deal. > > > In time we will see how that goes (what could possibly go wrong?) > > > but why do the change in first place? > > > > To not have logs duplicated in two places. > > I solved this by removing Systemd from my systems. > > And now what? And before that I had Systemd only log to /run. Especially as I found that I did not use journalctl in my daily practice anyway. So why would removing rsyslog from the default install the only viable approach to solve duplicate logging? -- Martin
Re: Heads up: persistent journal has been enabled in systemd
Vincent Bernat - 06.02.20, 07:58:32 CET: > ❦ 6 février 2020 09:50 +11, Dmitry Smirnov : > >> and 2) continuing to use rsyslog isn't an option if the default > >> changes.> > > No. I just don't want default to change. IMHO rationale for this is > > weak but everybody keeps arguing that it would not be a big deal. > > In time we will see how that goes (what could possibly go wrong?) > > but why do the change in first place? > > To not have logs duplicated in two places. I solved this by removing Systemd from my systems. And now what? -- Martin
Re: Heads up: persistent journal has been enabled in systemd
Scott Kitterman - 06.02.20, 06:27:44 CET: > >Are you suggesting that voters fully understood the implications? > >Is this OK now to replace everything with systemd counterparts? > > > >I certainly voted with considerations for _init_ system. > > > >If I recall correctly, no GR option suggested to "use as much systemd > >components as possible" or I think the outcome of GR could have been > >different... > > > >Anyway the big disadvantage of changing default is that now random > >Debian > >systems will have no traditional logging interface (rsyslog) and > >we're all > >will be forced to adapt to the new interface in the absence of old > >one on > >some systems... > > I think you need to go reread the option that won. > > I make no claims about what others understood or didn't, but to me > this is exactly the kind of thing that the winning option makes > likely. That doesn't mean I like it, but we had a GR, now we're > stuck with it. Well, that is *exactly* why I thought the GR is not going to be helpful. Cause in *no way* it appeared to have *solved* the conflict underneath it. I'd still love to see otherwise. But right now I see the same "I am right and you are wrong" pattern arise in this discussion as before. And also the same meta discussion as in "you are not discussing it in the right way or proper way" code of conduct related thing. As if the GR did not even have concluded. The GR was still within a win-loose setting and here it shows. The GR did *not* change any of the involved people and their behavior. And my bet is, that it won't do that in the future anyway. That written: I do not care at all whether Systemd by default stores the journal persistently or not. Especially as I am not even using it on my own systems anymore. But I do not like rsyslog to be removed from the default install. It might be a nice idea to improve its default configuration here and there, but only with good justification. So for example SUSE has stopped using those insufficient time stamps with SLE 12 already. I know there is a compatibility bug somewhere… but if log reading software has not yet adapted to modern standard conform timestamps, I'd not let that hold back progress. I am considering to comment out that RSYSLOG_TraditionalFileFormat line, cause really let that old insufficient time stamps be gone already. I say this with my log analysis trainer hat on. With the same hat on I say… I still like to use rsyslog. I can process that with standard tools I can use with any other text file instead of having to learn a ton of options of journalctl. Simplicity as a goal. I love to see that come back to software development! And neither Logstash nor Fluentd or Graylog have issues dealing with those text files and manage to dig out the relevant information out of them just fine. Mind you, as far as I am aware neither SUSE nor Red Hat dared to remove rsyslog from their enterprise offerings so far. Just imagine the uproar this would cause! I know Fedora has it removed, but CentOS 7 certainly has not and neither SLE 12 and 15. I am not completely sure about CentOS 8 cause I did not consciously check, but I believe I have seen rsyslog running there as well. Best, -- Martin
Re: Heads up: persistent journal has been enabled in systemd
Andrey Rahmatullin - 05.02.20, 22:17:14 CET: > On Thu, Feb 06, 2020 at 07:44:43AM +1100, Dmitry Smirnov wrote: > > > We just had a GR where the project voted it was just fine to > > > systemd all the things, so this sort of thing is to be expected. > > > > Are you suggesting that voters fully understood the implications? > > Is this OK now to replace everything with systemd counterparts? > > Yes. > > > I certainly voted with considerations for _init_ system. > > > > If I recall correctly, no GR option suggested to "use as much > > systemd > > components as possible" or I think the outcome of GR could have been > > different... > > The winning option says "Packages may use any systemd facility at the > package maintainer's discretion, provided that this is consistent with > other Policy requirements and the normal expectation that packages > shouldn't depend on experimental or unsupported (in Debian) features > of other packages". > You can read it at https://www.debian.org/vote/2019/vote_002#textb Hmmm, for me this still reads different than: "Ok, let's change the default logging system." Cause if I understood above wording correctly, then it means a package may use a Systemd feature. But this would only affect this one package. However here a system wide default of the system is changed. Thanks, -- Martin
Bug#950119: ITP: gajim-syntaxhighlight -- highlights source code blocks in chat window
Package: wnpp Severity: wishlist Owner: Martin * Package name: gajim-syntaxhighlight Version : 1.2.5 Upstream Author : Florian Muenchbach * URL : https://dev.gajim.org/gajim/gajim-plugins/-/wikis/syntaxhighlightplugin * License : GPL3 Programming Lang: Python Description : highlights source code blocks in chat window It uses markdown-style syntax, i.e. text in-between `single backticks` is rendered as inline code, ```language selection is possible in multi-line code snippets in between triple-backticks Note the newlines in this case… ```
Bug#950085: ITP: mbpoll -- command line utility to communicate with ModBus slave (RTU or TCP)
Package: wnpp Severity: wishlist Owner: Martin * Package name: mbpoll Version : 1.4.11 Upstream Author : Pascal JEAN * URL : https://github.com/epsilonrt/mbpoll * License : GPL-3+ Programming Lang: C Description : command line utility to communicate with ModBus slave (RTU or TCP) mbpoll is a command line utility to communicate with ModBus slave (RTU or TCP). It uses libmodbus (http://libmodbus.org/). Although the syntax of these options is very close modpoll proconX program, it is a completely independent project. . mbpoll can: . - read discrete inputs - read and write binary outputs (coil) - read input registers - read and write output registers (holding register) . The reading and writing registers may be in decimal, hexadecimal or floating single precision. I'm will maintain this in an appropriate team. Science team seems to fit.
Accepted hunspell-ca 3.0.4+repack1-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 27 Jan 2020 12:35:46 +0100 Source: hunspell-ca Architecture: source Version: 3.0.4+repack1-1 Distribution: unstable Urgency: medium Maintainer: Jordi Mallach Changed-By: Agustin Martin Domingo Changes: hunspell-ca (3.0.4+repack1-1) unstable; urgency=medium . * New upstream release. * debian/repack: Modify for xz compression. * debian/control: - Build-Depend on the debhelper-compat virtual package. - Bump Standards-Version. Checksums-Sha1: 5cf47cef4b4d62d115212a46f40e52d50b657e23 2025 hunspell-ca_3.0.4+repack1-1.dsc e9b05b2b6232f4c974ce4138f71c862d873a5000 593736 hunspell-ca_3.0.4+repack1.orig.tar.xz 458403180a22e6419d66b737ac94d82d76054ee2 3628 hunspell-ca_3.0.4+repack1-1.debian.tar.xz 0678697703a16c381d63fe483ab7740ec7b1f9f7 6256 hunspell-ca_3.0.4+repack1-1_amd64.buildinfo Checksums-Sha256: 89930f9bf7e46b50345aa5dd7eb7a33b96328467ae2443fa3c627e2772dca11c 2025 hunspell-ca_3.0.4+repack1-1.dsc 03494e9191df47a36c3b5be01cb4a1cea32cdff01c4f8bb6b0e2f940bff46c0c 593736 hunspell-ca_3.0.4+repack1.orig.tar.xz bb82902b99024c4f96f28cff1970accf7053c6d8a35cfbd9e7386c2caf6462bb 3628 hunspell-ca_3.0.4+repack1-1.debian.tar.xz 9a36054beaaa34bc7ac1df6d754ebdf963cc991eecdbb0adf9644be51a9cadc2 6256 hunspell-ca_3.0.4+repack1-1_amd64.buildinfo Files: 4fd32307133fbb43ddffd539bfd76a80 2025 text optional hunspell-ca_3.0.4+repack1-1.dsc 5a0b9bda76fe73ff83b85863219e7800 593736 text optional hunspell-ca_3.0.4+repack1.orig.tar.xz 323629b1b63947c4795134303ca50573 3628 text optional hunspell-ca_3.0.4+repack1-1.debian.tar.xz 4da5b342ba265777d75f7eabc66c4072 6256 text optional hunspell-ca_3.0.4+repack1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEEehey7p+gYd346SEFJrCLeiggvwFAl4uzs0ACgkQFJrCLeig gvyrng/+NzpTW4hR7vEHNItU3MIFftvlrnI/4Gc/59rD19ByukUmO25byxhqJFei XvajSLL3kPX9BZG67JY7RaYVR5lGdFdPmUBn/9dLB8bdiIo+YuC+OYe27jFFvLvP OO8y9uWoUEgTrzaH8hNmx1vDxrEscdfXCTnTIzwfJALnvxZ+LWSyOYprddVy8qMz fdO/ekBj2xHNg9I//pFYFeEeeq2JCDUqD2rTm853sl6Jj0zNiZNh8rVAyF+x5r+s gltHQX2g6P4wD/t2gvbx5j5KzLgWVc0fagF7nYVOjJg/P6ByeegKgOKlIZk/F7EW LLHWpjPg15T0n6RUEo3MpIQuUoXZ5wL/3f8y2nC9/ghdytsf6+GSYh6vo7owhdia WoFLPg7AoH/6xQY5MLr68twy/YkmGav/LvABbEGMlgjxCxeWAnXu82trv6IDJbdo dpNLN2Aotkjgve20YDkKVfubpueyyygrF2arTuyhpsxNU4VuvP+WIumBN2JT4ptf 62yuPx7mykBuurSs2j0efgpp7GgakgS2dZadGlG6rFsjkX4JkwaZBohyfigt7Eiu 86OrRcHYx6vkqymKlC+JYOui8f1iEKZaQiPRzB74F5dyiX9zJaVOPZ9k4nxbos+p 7BqTikf6HMa7IhqcAceY5Ug+WftT/iNUQH3qv9S2eyuTTLmjoFg= =VNEf -END PGP SIGNATURE-
Accepted simgrid 3.24+dfsg-6 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 24 Jan 2020 22:50:12 +0100 Source: simgrid Architecture: source Version: 3.24+dfsg-6 Distribution: unstable Urgency: medium Maintainer: Martin Quinson Changed-By: Martin Quinson Closes: 949775 Changes: simgrid (3.24+dfsg-6) unstable; urgency=medium . * libsimgrid-java breaks+replace simgrid-java (Closes: #949775). * Disable java in cmake on non-official architectures, too. Checksums-Sha1: a8568657fde6906bb53ad8a37454c8ad8c1473c2 2456 simgrid_3.24+dfsg-6.dsc 198ae8a187ffca2b4d16f84512fb5e23d1e01584 16032 simgrid_3.24+dfsg-6.debian.tar.xz 984a84b58d013a6b9ad41ecbb7223f6574590d9c 12619 simgrid_3.24+dfsg-6_amd64.buildinfo Checksums-Sha256: de7e700dfc9cf4be9b26e428a7f877e95144fe36c321200258d39e00ce3e6dee 2456 simgrid_3.24+dfsg-6.dsc 7f88ea9e5674bf775be7fbb239288575aff5eac8be9707503220de8d800192da 16032 simgrid_3.24+dfsg-6.debian.tar.xz 9d460c09bcb9ce51b604b7bc96c779351a217e69372ed0590741ea43247e5311 12619 simgrid_3.24+dfsg-6_amd64.buildinfo Files: c191ab60ce6d3fd4c42e30e823980aeb 2456 science optional simgrid_3.24+dfsg-6.dsc 60818e99ecf55548e3c604c9c8e07435 16032 science optional simgrid_3.24+dfsg-6.debian.tar.xz 11b76dcec11e064d74c76cb9f9b8c103 12619 science optional simgrid_3.24+dfsg-6_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEET76cTupS7xPVQWYSmL2XJE9zvqcFAl4raNwUHG1xdWluc29u QGRlYmlhbi5vcmcACgkQmL2XJE9zvqfOPQ/+NRDGuqxzgaYS/VNRHerEpjph3lEj t3b5/CTh7vt9Cz/JqcvabPepSThmJwIiU6MOxBkXRClljhnmbTLf9TCm5TjtUqmI Sg0STNljzqHmDesmTsrO2vFhSvzpgdGYsjPoHNS4496S35y2/7rpwhaatPcNUB43 9tzn1w0/HDpyIJTBARIVfg7zE8lljoB6YRD9FeV9z4QPG8riBK4ETX8GRaw1sial SHZNCwB6OjINOJM5wzjiYb1WBcFOFOoqZSPDiB4NCjZHb8ghfRP3gumdyr+G2D1y GI2L1Wt/g2bP+3hGLE70OVwmkhHHLjBgnNNreeis3oxMi5Mjf+rgURFDyPTb4ZDw v1P0TIseV4u4WiebZFB/7l5iRs43xpCkMnHfIbTTl0c5UEho3OCKRTVR10ZO/fQ6 X+d/f6D1pSZ48ST6n8IRmX/o6xSgJ8ApO4HiEmKD11mhcq8/HDyKLjRZqNYUSGxU SbVyZfheK+NhyFtOI8SeJFQoB8L29qBIbeZQj61TNV65ZB+2Vi64hya6AC6GbSiR k7sFokbk8+A1d2Y4MxSpUivJ9V8Q4d2kdTmGgwBFExJhvbsYa8QTZxOR/AnjimkD HV4dnUQvThqsAEmuKEOCq53lzySqRImxOK9wNIbWQKOlzaL6YuN8aLIDei9wSg3Z fknnVmgHqR8arjA= =Pl0x -END PGP SIGNATURE-
Accepted simgrid 3.24+dfsg-5 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 23 Jan 2020 21:17:44 +0100 Source: simgrid Architecture: source Version: 3.24+dfsg-5 Distribution: unstable Urgency: medium Maintainer: Martin Quinson Changed-By: Martin Quinson Changes: simgrid (3.24+dfsg-5) unstable; urgency=medium . * Don't try to build libsimgrid-java pkg on non-official architectures. * The valgrind package does not exist on armel. Checksums-Sha1: b9865bd08dad5a391ae0ecc263c46bd032735904 2456 simgrid_3.24+dfsg-5.dsc 58f87115d5855c2c9c8cdbba8668ae0f29838f32 15872 simgrid_3.24+dfsg-5.debian.tar.xz 0fd71fccf07028e882a95d97aae63ed1444f5e43 12597 simgrid_3.24+dfsg-5_amd64.buildinfo Checksums-Sha256: efa6c04da2b45265b9ba0befde7de3bcca171690c8b05a4325d2e2a1535f 2456 simgrid_3.24+dfsg-5.dsc d5e7db9a7c5d1ca45d0a67a78063bc78f9de11eeed0b68db761f4ed0f8526fe0 15872 simgrid_3.24+dfsg-5.debian.tar.xz b442466f9037d107f55ab830b70d6f6554f73b458f422f4b6880cf4005e203cf 12597 simgrid_3.24+dfsg-5_amd64.buildinfo Files: f3190ac43c080721dddf2e0df102d09e 2456 science optional simgrid_3.24+dfsg-5.dsc eddcb85ee11498f22006fc1f8b07e97c 15872 science optional simgrid_3.24+dfsg-5.debian.tar.xz 9faec7c4f215922b8f1362c281d96979 12597 science optional simgrid_3.24+dfsg-5_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEET76cTupS7xPVQWYSmL2XJE9zvqcFAl4qAfwUHG1xdWluc29u QGRlYmlhbi5vcmcACgkQmL2XJE9zvqdaqxAAjn57GfybDeaBLy+OXiY5Dwx9aWiZ okRapwJkg84CAPboQj0HdAWmnUkCVPe1jaErjtrf/Ere3wQhGkRwKNpCGi3+0a6a l4rmF/dKvgR5v16LzqU+tLQARZXZO4I96IpkBmb7zz58t7C2kgSKpIeR2um+HG82 v59wQtHucXzxYT8YyTzT02DtbUjZ4hElTnSyFe9PuCpw36EXVnWhapnUcFCt0HBH oRtqg0xU+8YqffvZZiAeUmFCq0/81YJtZPmOolGKskcNzZyWwVNS/w/0woMeMKm9 ZTbP7JNs5l3r8w+VX/G16JpabdIjTwxoB1ZDBXmsqc7zbCa9WobyUSnef0L16awX c1QvlX4qR0vXypZBG+xbIAAYfK9cf4JOFBYIMSGDhFEpdigh8Y/fSfIcxIR92m55 LVedKsj7G8diDNaDcjvKERMof1gedZA/zzKl+dUpdvMS+6s1rtNQ5ncqiDHK1O2V 81ffVh+FI4QRFJUjZhkg6YPj8B8TsNp3ydPVavbMvJkJvafRY/HO6M4/nn9W1U13 HqF5GENaQLXVs/lhuO4Dzic+yM695k0WFNF5Fmgi8jDX/u/eSib01PS0xnhc7lyO FVXN+eCk+lCHQb7qNGP5dnYL9B5iNdUw9FjYqMtv9O1ZqnNvKknMcnBrAWhsas1G t+6Go0S6DViG/Vk= =4+y6 -END PGP SIGNATURE-
Accepted simgrid 3.24+dfsg-4 (source amd64) into unstable, unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 20 Jan 2020 10:52:40 +0100 Source: simgrid Binary: libsimgrid-dev libsimgrid-dev-dbgsym libsimgrid-java libsimgrid-java-dbgsym libsimgrid3.24 libsimgrid3.24-dbgsym python3-simgrid python3-simgrid-dbgsym Architecture: source amd64 Version: 3.24+dfsg-4 Distribution: unstable Urgency: medium Maintainer: Martin Quinson Changed-By: Martin Quinson Description: libsimgrid-dev - Development files for the SimGrid Toolkit libsimgrid-java - Java bindings for the SimGrid Toolkit libsimgrid3.24 - Toolkit for scalable simulation of distributed applications python3-simgrid - Python3 bindings for the SimGrid Toolkit Changes: simgrid (3.24+dfsg-4) unstable; urgency=medium . * java: rename the package libsimgrid-java to stick to the policy * Don't suggest the non-existent package java-virtual-machine * Cherry-pick another patch from upstream, this one to help DLHC. * Drop the now unneeded hack where -funwind-tables is added on ARM. * Plus various lintian-induced cleanups to the packaging. Checksums-Sha1: 966e4ce0aef000e188c4ed89078e112f07f5999d 2407 simgrid_3.24+dfsg-4.dsc 3f0922752993c3420ffb285a4f3f55de7730ffee 15828 simgrid_3.24+dfsg-4.debian.tar.xz 78ac10faf995eea76831fe9ba8a10d29e5f48738 274608 libsimgrid-dev-dbgsym_3.24+dfsg-4_amd64.deb ea1fb5a046abe155d1bbc7f5f969b33eef218bb2 222368 libsimgrid-dev_3.24+dfsg-4_amd64.deb 248021ca237adc26d8025afbf3d0bbdbfe53d4f3 1037064 libsimgrid-java-dbgsym_3.24+dfsg-4_amd64.deb b788b8445fb07c49c24b08eb4b086e02ff2c73ed 153940 libsimgrid-java_3.24+dfsg-4_amd64.deb 0aa02c3028b492e44b8b5fad16dae3b16973fa03 17041188 libsimgrid3.24-dbgsym_3.24+dfsg-4_amd64.deb 2cdf5f640fd29f1f2d8b93594f37398c9749c785 1416760 libsimgrid3.24_3.24+dfsg-4_amd64.deb 6a2c2ba166a6bd6419b2e1e180c06a22d8d3a233 1687892 python3-simgrid-dbgsym_3.24+dfsg-4_amd64.deb e1934d1101f479425f25d3f3e30fc36a06360214 180104 python3-simgrid_3.24+dfsg-4_amd64.deb 9d650961f1571914c7aebf78c1b3e6814f41a67d 12627 simgrid_3.24+dfsg-4_amd64.buildinfo Checksums-Sha256: 0c0a5fed2a29e05af6da0130b74139a1559a44c1edec7c734a8fee09e12fba1c 2407 simgrid_3.24+dfsg-4.dsc 1d751b3dba7b47f5ef6ea4d46895484aa850df1197053dfd9d8d690dfad799b5 15828 simgrid_3.24+dfsg-4.debian.tar.xz 96b078e2a5def557e376c2892d8a33a779a26e87fd2b1eee267ae4d6fd14d646 274608 libsimgrid-dev-dbgsym_3.24+dfsg-4_amd64.deb c725f36807af7ea17da08036ecfe9294d69c48f88856287f3531af2c7c62b872 222368 libsimgrid-dev_3.24+dfsg-4_amd64.deb cffa68143a073f882eede74a461f82bba6573c2fb983d6ef54f5f0e389b07bd5 1037064 libsimgrid-java-dbgsym_3.24+dfsg-4_amd64.deb 414b2589e982dc3c51e037d597d61309e4a850225b8a0f7f158ff365a9898799 153940 libsimgrid-java_3.24+dfsg-4_amd64.deb d5a5096d9379ef8cb3996d77eefba920935c67f5f0beb764cf04f268bfc2ed8a 17041188 libsimgrid3.24-dbgsym_3.24+dfsg-4_amd64.deb 87b809c20a0bb1cb46b093adfd0a653f8f5bee7e84b17c84d2e1c34c809e11a7 1416760 libsimgrid3.24_3.24+dfsg-4_amd64.deb ba84d43c4bd7c4cbe82d6fe6b8a54fad278a5c734bcaef15b516360bb955da71 1687892 python3-simgrid-dbgsym_3.24+dfsg-4_amd64.deb 297f363e7f0aff65480e8f471d41e8ee9138ac50cba84adf6b615b7cbb316f8f 180104 python3-simgrid_3.24+dfsg-4_amd64.deb 8231d4463e95d70e99c5c6aa77acfb3eea7e70b4bed6c240f7719b491008c432 12627 simgrid_3.24+dfsg-4_amd64.buildinfo Files: 4162c05976d92b4ffd39a5fda6996c91 2407 science optional simgrid_3.24+dfsg-4.dsc 3f9237ea356e2634c8cb219df8ca040a 15828 science optional simgrid_3.24+dfsg-4.debian.tar.xz 5b93eccb86284df8b8182e5b96c81999 274608 debug optional libsimgrid-dev-dbgsym_3.24+dfsg-4_amd64.deb 122f1a59edb635d15d5bb1f4d81e8608 222368 libdevel optional libsimgrid-dev_3.24+dfsg-4_amd64.deb a44327dbba5355d690320cb6fe9fea9a 1037064 debug optional libsimgrid-java-dbgsym_3.24+dfsg-4_amd64.deb 458a586f2fa74e870c0b226ccb553f17 153940 java optional libsimgrid-java_3.24+dfsg-4_amd64.deb 429efc4121f4d25aa958a0ae34f04761 17041188 debug optional libsimgrid3.24-dbgsym_3.24+dfsg-4_amd64.deb f26627a3fd1e9230b8de581cb2175d1d 1416760 libs optional libsimgrid3.24_3.24+dfsg-4_amd64.deb 094d764b7d323b680c227997c64e0d2d 1687892 debug optional python3-simgrid-dbgsym_3.24+dfsg-4_amd64.deb 892c70895366e93939495cf63df82fe7 180104 python optional python3-simgrid_3.24+dfsg-4_amd64.deb 9369be9102fca8da2ef35fd4b721d365 12627 science optional simgrid_3.24+dfsg-4_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEET76cTupS7xPVQWYSmL2XJE9zvqcFAl4mUKAUHG1xdWluc29u QGRlYmlhbi5vcmcACgkQmL2XJE9zvqflHw//QZ1oBSxjynBS4A5HboKTXU/M46y4 PqtevCiMkbtGq3wqItpu2kmgRYpwDGDPam348la55RH6qS7GJeqVK25pisS+bj44 OE+Xh1BU2ido306Rlnbw3UhxZv6+TS1G1nx0G9e+OKqFegRIrgKaFxTYKO9YjsZc MGR5d1XsZtFH/5WJYpmWUtixB3WVjn0YqnU3VvsPsmZbgaGbx/GaOeEFGVGvLc8B n6wFxRN43gwx6zruPNfB9mRRMtvMbeWbOA9vtSZNUSRqlo0KZiJ8Y4cFT6dYXP1N eF+ioJwhJA6JmJcQ42ZW3hvvqKg3TVTn0/WkwZCpbzkTgWQloOQVF+b6JfRfWIgF zJhOjThuhzg+nnNKxoztg4g9+kHXA0WUM7hYb/xHG0oqLkbFpxtlUlP/09Y5C5MI
Accepted cockpit 211-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 22 Jan 2020 21:45:31 + Source: cockpit Architecture: source Version: 211-1 Distribution: unstable Urgency: medium Maintainer: Utopia Maintenance Team Changed-By: Martin Pitt Changes: cockpit (211-1) unstable; urgency=medium . * New upstream release: - Better support for various TLS certificate formats - Switch from Zanata to Weblate - Overview layout optimizations Checksums-Sha1: 3371db64b1068be24aac500ebee52c4d28dddccd 3100 cockpit_211-1.dsc 3af19324000b050478c0b39b83279758bef21c97 12815096 cockpit_211.orig.tar.xz 6f73e01faa3a649a9ed09ee052823173fc89fd24 16268 cockpit_211-1.debian.tar.xz 427d8162e5107547d6ac9dfce537295da394e9f2 9675 cockpit_211-1_source.buildinfo Checksums-Sha256: 22c8d4f8d850de0cdf7f1edcc71816eee926af598183b67a679b56470b42cf21 3100 cockpit_211-1.dsc bd9f23608f14f8a2d5e5f4dd08b433bcb6b54e6740a0cc5cf27a1c6ef28d0612 12815096 cockpit_211.orig.tar.xz 9b86f73f8e8fe65c3c1e49c55626d928ef8b30c661fc23f4e843d0995f4d7513 16268 cockpit_211-1.debian.tar.xz bc78f739491d24e90e2fa56834f7b14bdedc2041caf0e4c0171b1110f479b26c 9675 cockpit_211-1_source.buildinfo Files: 31359eb25e7c5d0aa93d5332d7daf032 3100 admin optional cockpit_211-1.dsc 9b39aa2ced2fa692da17fefdfa9e32a7 12815096 admin optional cockpit_211.orig.tar.xz 50a4373fdc292e9b29e768e25827e798 16268 admin optional cockpit_211-1.debian.tar.xz bc34dffee62dd29c99fc010e2e606469 9675 admin optional cockpit_211-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEPbRrVe+lnUDmIyFI0U7xXa/hE0cFAl4owvIACgkQ0U7xXa/h E0frAA//c0jeqXxvW6UTl9TmCwT20MJ34C6Zz2RaVp3ZGTScDu1jrGHmxW/OPjkR MAH8cTCGbQSqyKDJ+caEejbSo5pWCRSa5DXV+m/DjCl6LmIziFT/XBeZfIkpdG5s 8MRv4Unxjl85zTVLpCSyjBQKPx4MrWzDeAf34Fnj6ndgji9wvJqp7AicmEESZH6K PqsqV7Ibq2+pAMlRh9Cy8mzm4MXgQFlse5uB3/bS776CV5AaKqUfiAQdkQe0cIhC A1uNGaNDQRFqgFVDV2EKdogIS2pxpJ2gJHk/UZ3XjI3IaKPPSfc3AwBbgMNrrNc9 9Ykmd3tX/gUOtfX5FmLHAW7ToigOSR25DqU5M10IdwC/6r9NGvMfh2FFTFcMAeST 2+aOwCr48u4oAJRPgseQzMv4XLHbTvTY/BMECFml0wvNecnK/mg7pmnmyR+UhtwS WB/aXL5S9ZIO8orjaH3pA2yftBgnSx+ljCxxS+dOOFWhS3RH5danzkivHggemD0t 8v+T2e/RfqPv7rOu+mcVJan3fPqGKMC8VIM27B/ifN5DX6/5Bn0LrWQ/PjH9OsVo vmfxu4rvxcWsLNT9eOenURP7zk3bWDXAsmvqGxDaZ0cFMl+NL6MWnVU+VUzLOoaI oOBlQZgSDRRzNKl/EcOyNVUpvXSsUyleRrcW/LghObvxuuoiZ1k= =FsYD -END PGP SIGNATURE-
Accepted pajeng 1.3.5-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 20 Jan 2020 21:55:20 +0100 Source: pajeng Architecture: source Version: 1.3.5-1 Distribution: unstable Urgency: medium Maintainer: Martin Quinson Changed-By: Martin Quinson Changes: pajeng (1.3.5-1) unstable; urgency=medium . * New upstream release. - Drop d/p/perl-5.26 and d/p/typo-lintian: integrated upstream. * Update VCS fields to point to Salsa. * Change priority from extra to optional to obey the policy. * Rely on pre-initialized dpkg-architecture variables. * Drop the -dbg package as they are now automatically generated. * d/rules: drop now obsolete the 'get-orig-source' target. * d/rules: Harden the build. * Bump Standards-Version: 4.4.1 (induced changes documented above) * Bump debhelper compat level to 12 (some cleanups were needed). * d/copyright: prefer secure URIs. * d/p/no-latex: new patch to not rebuild the Paje reference guide, as it require a tex->dvi installation for something we don't install. This was not built before, that patch is only needed because we now build the manpages. Checksums-Sha1: 6b123a3205cf52307269ecd174709b62c64979f3 2099 pajeng_1.3.5-1.dsc a087d1f3243de61eb7fe5856f7fd69fcc116b8ca 697895 pajeng_1.3.5.orig.tar.gz 2f856fd2097076dbeb49d218b75b7dc2d7f1098b 5132 pajeng_1.3.5-1.debian.tar.xz e919315577144afb7ec313c5d4c2e05716db53e3 8293 pajeng_1.3.5-1_amd64.buildinfo Checksums-Sha256: 46ff60ba154ab7bdcccba188ae4af5b66dfa557caae528bcca9b1a1e66b80de3 2099 pajeng_1.3.5-1.dsc ea8ca02484de4091dcf57289724876ec17dd98e3a032dc609b7ea020ca2629eb 697895 pajeng_1.3.5.orig.tar.gz 5d3aa12b335c84608881cfb1bf69ed8cfe62dc5a59f214fca38de96026dacdfd 5132 pajeng_1.3.5-1.debian.tar.xz eb8f64f3465a36fefd19df4d1d68407faa6f7525d7e89fff5928f87f529be1a1 8293 pajeng_1.3.5-1_amd64.buildinfo Files: f187443bed0e1b7d9e7cf14b3ba8a076 2099 libs optional pajeng_1.3.5-1.dsc 69e2bb17e9a85d46496d25e578e56766 697895 libs optional pajeng_1.3.5.orig.tar.gz d9c436d52a48a56aa6e9760663396553 5132 libs optional pajeng_1.3.5-1.debian.tar.xz 0ad87a28165c0a585f4e9a112a6eaf57 8293 libs optional pajeng_1.3.5-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQJIBAEBCAAyFiEET76cTupS7xPVQWYSmL2XJE9zvqcFAl4mFbkUHG1xdWluc29u QGRlYmlhbi5vcmcACgkQmL2XJE9zvqeTZw//Q4V/gZShDYmm6c/UdGUFY0Vt5fnN 3VocA7UuW5SM9BqL0v/BUoIqM6ooP9EEcbFwiYF/aiAHqt/PsfPXHlGeqtlPuzIP HJjD/jKXiWj3P2aj/O865vgKKR+161EqfZXv3LSkRvCmY9QOZjbFbCE4XsD3D8xj RZStiJngAlKNqSaIrpFw/4KtNIlfvx3a3KFb4u6nPgXlrgodm47YjnusBoT20zGP Fp+ibvldFHJR3/JW2Wgt9aiw8L5ZsBcFO6ityFy8hocwRhx7mR2lKr6Np68+9fL9 tjupujnTTHlgyF50rKLqrrgBLhBt+OFnxA31IlAKcL66SxFS8CHhoZQBr/urMgzF gjgNJ52XhMdip/7mv6NCilI1/QnRh4edHnHeAI1SWq8MKND/Mt8L+I29ynnhOIXB oC5jbX+rpRSHezcx8QYrCMGVrnIFsNOVlP7iEMVon/q/uCQnhuXDPEzFLo8a94oj 4ecGTtZlF+FVhsZ3tILjH6hIEqoJskFBENl1gLpKMpsD0No3wZYnM4GgzjO+JqQQ 3RLPmE+OL8jBAw+0v1NL4Du7oyTgYuuSYA6K1c0zbOAWBWSEs8EHkXnl2RbcXU/J TluLcTE3DQ9L2SirNR1HiUA0PQIgRQEFfq2uZ6HKEP3e1rCQ35NX/p6qXl9D7qth +7L6Uygg4BvFoK0= =8YjV -END PGP SIGNATURE-
Accepted sms4you 0.0.1-1 (source all) into experimental, experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 05 Jan 2020 22:49:42 + Source: sms4you Binary: sms4you sms4you-doc sms4you-email sms4you-xmpp Architecture: source all Version: 0.0.1-1 Distribution: experimental Urgency: medium Maintainer: Debian XMPP Maintainers Changed-By: Martin Description: sms4you- Personal gateway connecting SMS to XMPP or email sms4you-doc - Personal gateway connecting SMS to XMPP or email - documentation sms4you-email - Personal gateway connecting SMS to email sms4you-xmpp - Personal gateway connecting SMS to XMPP Closes: 945191 Changes: sms4you (0.0.1-1) experimental; urgency=medium . * Initial package (Closes: #945191) Checksums-Sha1: 6b653be52b68e27202daba8ffee5cef86cf64c83 2103 sms4you_0.0.1-1.dsc 8448f821055afa62fb04db569cbeb9b52153f3f8 116022 sms4you_0.0.1.orig.tar.gz 4b993380041c0f57c974343ee748b40f79f88a12 13408 sms4you_0.0.1-1.debian.tar.xz 079929c6ca467b6f5028d236cbacb49f18a065c5 103660 sms4you-doc_0.0.1-1_all.deb 073d16c902a5f49c4bb04392da332570146cc89f 16760 sms4you-email_0.0.1-1_all.deb bbc9d0cd08b92f206deb77b77d24062c1a53dd71 16856 sms4you-xmpp_0.0.1-1_all.deb 8173424a38d4e84c8b9b0c343b9a63d5705ed945 12688 sms4you_0.0.1-1_all.deb 70c89c463fcc1a7e1bfb5f94785c1e9f2afa648d 6925 sms4you_0.0.1-1_amd64.buildinfo Checksums-Sha256: 6cb66f832ed02b880cfc27456af93331f6044b934272396f8ac90318ad0ada3f 2103 sms4you_0.0.1-1.dsc dda02fafd3809fdf20cdc4a91af118320b8686441ced37206fd5afc99cfb72e4 116022 sms4you_0.0.1.orig.tar.gz d840c0d512c444818d0beb02e3709f1fa0f055d0dfd03f3e2ccfc8f6b89ffb2d 13408 sms4you_0.0.1-1.debian.tar.xz b87f1ecb511fca08cf5aa3c401adc3ebb72de1c18934e86de138fbe02cd19cc9 103660 sms4you-doc_0.0.1-1_all.deb 4af62b0c3fa4129303e6d51d7ed163c249395ab8a45d42c40765ce0f6acec4eb 16760 sms4you-email_0.0.1-1_all.deb cff6a3c22a367ea8e053bb3d8d967511b49cabbbed73d5b4f516bdacd86a4f4c 16856 sms4you-xmpp_0.0.1-1_all.deb e3137901ec04797cf16b841cbd457e390e99dd8c35cc8523be540d4774b9b6a1 12688 sms4you_0.0.1-1_all.deb 26b4f968006d3d69e45b94c3e6f25d3f03708fe2346e8a0c8f15c0499ffc652b 6925 sms4you_0.0.1-1_amd64.buildinfo Files: 9f8c7aae56d7fb8bac5cf9dc863840f2 2103 comm optional sms4you_0.0.1-1.dsc 9ac93071f40007b8de84249ca032b64e 116022 comm optional sms4you_0.0.1.orig.tar.gz 7e7cca294778d3d3247b8ea235acb47f 13408 comm optional sms4you_0.0.1-1.debian.tar.xz 51632a82b8d0bdcdab3df947be049580 103660 doc optional sms4you-doc_0.0.1-1_all.deb 3e9b75e392d3fa4969124d6658840291 16760 comm optional sms4you-email_0.0.1-1_all.deb 7275b9a97e757dae752e4bc762c448ef 16856 comm optional sms4you-xmpp_0.0.1-1_all.deb 2c249265996325a383d3987bb86319df 12688 comm optional sms4you_0.0.1-1_all.deb 65aa4bedd173e92356cbb31621d0d90c 6925 comm optional sms4you_0.0.1-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEftHeo0XZoKEY1KdA4+Chwoa5Y+oFAl4ScroACgkQ4+Chwoa5 Y+qX3hAAod+y0Vd7DmBn1UPWcgmFAHWAZo1naIznY8XbXqHCZJEDdDXqXQMryU/8 eyfEEPQiJMsTPAJige0/KohNM4RS6UXI6CO2Z0qdMzWSCqumC2g2Y12Fz21vA7VN 1vzaSs4Ereyote0VT1Y98sr2oim9y97kJ86HiIprKLg+NH/UZorKlGhT6yBX9QCb wDxsOypczJDUswICFD4R4r9Iks1jeCURghZXbWjfbM/KGoA7VuyxqWSQbdj+GDCE TcdAhqAqNFYE3H0Id87/Bpaq8FlMvtB5Zl8MjGYWr6DkanRLKSVKw2KWVSscU+DA PqTAxCgRpLLTQnFqSqk6ACxBvv+IleythxevK5LqvN8rveFKHKNNbP051GOfLdXe qEqYKxrX7YzLGVbxaxIN4Q0mfQALbIrPtAegq3xUnxIRenhI9tYQhibQzevyNrZR kbG+vqAzFt/7NnyLr1ZF/1TpkeVCUlLLb9yDI+QT5st1B7ozRK6+3gESNStkdpbC 8UzAk8vOP2NjEvGLMAj8huNa9s6EMKn9Uz2+zXLo23RiwSaa5frpEe+R1SytiT/G frGX/Ys9dqKB2ESLVnLJL3ScJpK12gY9wfuzqgMgt2f6e+/1NYFtuKBNv+Lic5Ei UB+oWHQst5E5ny1vm+le/IfqXRQX6W5YV/LJOt7fPyjaTsssHjI= =SmUi -END PGP SIGNATURE-
Accepted dino-im 0.0.git20200109.3fc9bda-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 10 Jan 2020 23:09:55 + Source: dino-im Architecture: source Version: 0.0.git20200109.3fc9bda-1 Distribution: unstable Urgency: medium Maintainer: Debian XMPP Maintainers Changed-By: W. Martin Borgert Changes: dino-im (0.0.git20200109.3fc9bda-1) unstable; urgency=medium . * New upstream git snapshot (mainly bug fixes) Checksums-Sha1: 64a11c99da567a81758dafa3d9fc2e69ff07de89 2329 dino-im_0.0.git20200109.3fc9bda-1.dsc ef20af77cf722d308d6409dcdfe188b696bae20f 435587 dino-im_0.0.git20200109.3fc9bda.orig.tar.gz 99ce18a85585d8007e7228f3442f1e88866ac17f 5044 dino-im_0.0.git20200109.3fc9bda-1.debian.tar.xz 00a430ce32692f3c018f7e4fc9c25afa535fcbe9 16213 dino-im_0.0.git20200109.3fc9bda-1_amd64.buildinfo Checksums-Sha256: e15f67d8d2f6f9bf340aad4969236b796b036d6877789820a49bc35547ea9968 2329 dino-im_0.0.git20200109.3fc9bda-1.dsc 1636f3f42a9f2a2a4a11c1625c8c08108ac2445e6977ea12aec3380c3be29864 435587 dino-im_0.0.git20200109.3fc9bda.orig.tar.gz 9a55b7846955eab35ac53743565ea27b1dfeee377999289fd41c51147c1f3ae2 5044 dino-im_0.0.git20200109.3fc9bda-1.debian.tar.xz 7792be6744ecdb6e254818e90b2fcd1b3d01eb91c97df7319bbc52d5319fe1c1 16213 dino-im_0.0.git20200109.3fc9bda-1_amd64.buildinfo Files: 57d6c45f582639ebf9bd8848c4f5df50 2329 net optional dino-im_0.0.git20200109.3fc9bda-1.dsc 3163bb8e52e4bef374083c0f73ad7924 435587 net optional dino-im_0.0.git20200109.3fc9bda.orig.tar.gz ecf5df2b7e5e49a272342bcf6476831c 5044 net optional dino-im_0.0.git20200109.3fc9bda-1.debian.tar.xz 3c0ccd8879f78ffc840ce82eed2c1825 16213 net optional dino-im_0.0.git20200109.3fc9bda-1_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEftHeo0XZoKEY1KdA4+Chwoa5Y+oFAl4ZBlgACgkQ4+Chwoa5 Y+ovQg/9FVNnxlPR2Oflst6ZDaz6iEq5XBGqsB1sXrqPGGCRea6FDM+5zagdk6x8 BwvbWDICPEDmz+7T3oTHSktrHvLYJ5idb1cwyLZ+455LGIjjjNBEV3jtIQgoysH2 aGl/febvG8EjN3EdEE0qC5jouJSN4OkjIXttvL47fwZfwu25JrTFG5vLWL/Csjae jo7/SLA9rqthH7urBdidycGMWRjYa1FdpGHqp0nQCyRxqlaB6MV/HMceJz14Wu54 wu8UySB0a+mEVZThu229CqPa7OtLWnTauTSgZQwU4QwmtCO5aecPOLCiD//SR8xO D3gszZHz1YB6V3hU60Gim2HCAOVJ8iSZSleojQORHLwSbDK73X20I5J9F3P5heXN 0kOYUeKBVXFr8C4Hwpl2MIJaJZ5uFAP+b/ee5n3fTBbtIruoAM2Z3S4SYwYR1Hzm PqLXNKG3XPvY0izEqTwPoGVwJKm69mk1RtbGthw6lq3ONNvK26Cu29Dldr1gKZAI 9jIq1qIKNebIXYB4j8mDsHUdbmbP8HRQgUCVsaDo6coIuvOpVEQ4hKIc13W9ONOI gWr54Iq6f7IklPKKpOZDoW9tB2h0yR3zNDSgvep7TISfS29guRrc3YuU2ArK8oZT AlxB8/zdhV/VSlR1V7uWZHKosMdpFhy3YjfxhFePpKB4M1oNdu8= =RJ17 -END PGP SIGNATURE-
Accepted python-dbusmock 0.19-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 09 Jan 2020 20:36:10 + Source: python-dbusmock Architecture: source Version: 0.19-1 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Martin Pitt Closes: 946098 947712 Changes: python-dbusmock (0.19-1) unstable; urgency=medium . [ Ondřej Nový ] * Use debhelper-compat instead of debian/compat . [ Martin Pitt ] * Move packaging VCS to python-team repository. Update Vcs-* tags accordingly. (Closes: #946098) * New upstream version 0.19: - NetworkManager template: Add "StateReason" property and active connection ID (Closes: #947712) - Add low-memory-monitor template Checksums-Sha1: 9a8e09b6bcc95b3196a4dd031e57a2e3dcb5f1c7 2318 python-dbusmock_0.19-1.dsc da7d34bc481bde3925dcf813af9cac2a9d869157 72567 python-dbusmock_0.19.orig.tar.gz 6885843f36caf5894dab0d1047956887b99113bd 4640 python-dbusmock_0.19-1.debian.tar.xz 2f049ce9a2e77db6c8402a4be970463c49fc4102 5455 python-dbusmock_0.19-1_source.buildinfo Checksums-Sha256: b0c88077b064310c614fe46b85517afc4354c8ad9f9b0a9a99c5feb050769188 2318 python-dbusmock_0.19-1.dsc 497f30eed2fcd5deaa2633b9622e4e99af4bdfba4e972b350ba630bac6fc86c2 72567 python-dbusmock_0.19.orig.tar.gz 7213b2a4417400984dec03f684091d008051d0eb04b8d26386a50cb8fe089bbc 4640 python-dbusmock_0.19-1.debian.tar.xz 6047758d48120dfa37bf6d68abaf9855cc7077e1927b79f0f0ab3c3aeff09b49 5455 python-dbusmock_0.19-1_source.buildinfo Files: 4cfe473787590345f67c4e92c6971496 2318 python optional python-dbusmock_0.19-1.dsc 565aaae672e065c9c17e7fafd1843701 72567 python optional python-dbusmock_0.19.orig.tar.gz 8b6ff67b14b98e17f55f03bae2ef2658 4640 python optional python-dbusmock_0.19-1.debian.tar.xz a7d09a9c7533eae2d540315df9f602d4 5455 python optional python-dbusmock_0.19-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEPbRrVe+lnUDmIyFI0U7xXa/hE0cFAl4XjsoACgkQ0U7xXa/h E0c4DhAAln+eRB1CTNDX+HDGq5388JOjh1YSJE8aQ0m3U1tV5MjRIw0XHmDCWj7m I7ru5Z1gsKzRkeaNS7g0xumPd6PFXYtirGmYk2Lk2JXzX3Xlo3a+9a+4jV0eFZUg uwMP5LiZC9GY/eMu9goaabt4rw8Gc/mXzBdTwWnRcRvQx+H30GvoPmMlMV6ky9uF X3ABbu7tnbzpg1AcMi6kWZrYKfgkDgMnW5vFLmN6H0FTsriOk/YFy8X958xA2Y5J WSvE8uu5JSsCQyGetX875wnmS2GykxqR0vJg+rX4jaanoh9Do1odnOMXaoI9DvYm EZ86WVqJtyUd26AU9ZAmsFcMZuCzPWSwQkeodmNPOiVbhQK+kcJY8OfEFRkk1s7q yR48TYvCB94BT7on52lZ50TX2NtpYOno4q68iz6pVLMxMzaIvzCWBoUZ3mdCjNTn Jolplh2A0aJd8Rim6OkNxNlflt8Urxz8nwiHi9hT92pIlzkQGnXxKXHHoJ1cwRlH Y4bdM2QPuCC7nRzl4mXdk+C/c8vilfPU/LsfjfWFATyL3TtjpditVGUFdsw9RzA0 Mi5ufKdIVJW5ipsozAkk7AvEi1yd/XCXTzSL8hPJpMXMWgF6aO5A7lke9h0uNzob K6XzH1+9ffYBiXSNO+PwDp36ij9rxO6P7NL0fj6A5x5EJp7xmg4= =sqUa -END PGP SIGNATURE-
Accepted cockpit 210-1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 08 Jan 2020 22:30:01 + Source: cockpit Architecture: source Version: 210-1 Distribution: unstable Urgency: medium Maintainer: Utopia Maintenance Team Changed-By: Martin Pitt Changes: cockpit (210-1) unstable; urgency=medium . * New upstream release 209: - New overview design - Session timeouts - Banners on login screen - Client certificate authentication - Support for Fedora CoreOS - Dropped support for pam_rhost * New upstream release 210: - Overview: Add CPU utilization to usage card - Dashboard: Support SSH identity unlocking when adding new machines - SElinux: Introduce an Ansible automation script - Machines: Support bridge type network interfaces - Machines: Support bus type disk configuration Checksums-Sha1: 8aaa80e5752e5d5983d16bb7e7099ef8e210621c 3100 cockpit_210-1.dsc 19a2eee759e33a892ed3658d5388267e3945f02e 12890556 cockpit_210.orig.tar.xz 4431537075114e60fe17c1ba53210641aec2c86c 16232 cockpit_210-1.debian.tar.xz 33fa109df1014f25f59474dcac62d494cc07b228 6174 cockpit_210-1_source.buildinfo Checksums-Sha256: 21439c297e19015fc29f032f40cb6ecf1fb680412b901250a0b3e6bd9a610fa0 3100 cockpit_210-1.dsc 6bee572c39f453812b5224e7f07d94aabded5954d5efcf0ec9d1ed03adc6b8f5 12890556 cockpit_210.orig.tar.xz 53a4c5136ca76b3c3aea444e3387eac3497fc356206686ea1ce026212d773c9c 16232 cockpit_210-1.debian.tar.xz 59341abfadef6102b0994f1342bc61bd344e55283aa2be9ff135852d314ace0d 6174 cockpit_210-1_source.buildinfo Files: 646faecf20bb46e5f799b555cb247d40 3100 admin optional cockpit_210-1.dsc 5a2d34d4f1af3e652dde99ff14a9474a 12890556 admin optional cockpit_210.orig.tar.xz db0a37a04c860fdf82112ac66d1a3403 16232 admin optional cockpit_210-1.debian.tar.xz 0e6631bd2e53ee2c2133f32f09efdc6f 6174 admin optional cockpit_210-1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEPbRrVe+lnUDmIyFI0U7xXa/hE0cFAl4WWi4ACgkQ0U7xXa/h E0exGhAAxrXdKWaN2CTuH79BHg7azcqmxqtTnQUDo5DVWK/Ljo4Xw8S8sAg135Qr 01V7PM1VQm4HXBnbI98ASfqnnojfbjkLfBq8qADw8BTVaoUnJaKijnnuoh/0y+ed E4NO6b+rXtVRCmqApm3cCT/HsuZ7qEc6IUfSqVlwHbxsHRdG7n+ws31gpA853PW8 0GwNJ3MpVtZcSEPCOA9ic+e3Sjxro/nvuc78tl+yKPE2ZF4Ewb7cas84fLw4zF/7 1efJ/agNhnOc9n2z/2aVD9fbTp95wewtloo0aSEPWFZUeVap1a8cQzTkqw9zgdmN iovcMOccycZXKos6zDBPWk3ww9KHzzUJS7U5MJR/1icKXvNk5ynbM97L3fIZvUaQ 4CTOBpyDSYwjWzYenYUOAvPFOJ48e4ZuGx5S78xGxooFYASQ3tj0J8iutCS7ph/u wmbe29f1Vkn/qz3KfpBxX5KS4stKxN4GYhtgyQ7CjhP354waO4PdW7gTwgXEsvJF vZ/1nSPOx5qfJWX+/9Q8duCvxMRsO+E92wxfHkZKl8Z1i9m7HK+JJuPEaq3PkhsZ oUcBiXa59vBOg58iK3f4kMUYXVKiQ2tbCUHZ0kyPt1gbTcStvqrfddbAj+cKYq1T 3VBlDAHQj36ZqJZEIJJq+ZswGmeYe+V1RFRaHiCGXuWLKHlAGvA= =DjoH -END PGP SIGNATURE-
Accepted pcp 5.0.2-1.1 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sat, 04 Jan 2020 09:58:40 + Source: pcp Architecture: source Version: 5.0.2-1.1 Distribution: unstable Urgency: medium Maintainer: PCP Development Team Changed-By: Martin Pitt Closes: 947916 Changes: pcp (5.0.2-1.1) unstable; urgency=medium . * Non-maintainer upload. * Drop remaining python2 build commands (closes: #947916) * Build-depend on python3-all-dev for the py3 extension build. Checksums-Sha1: d84b6e24d4d27b5d1be754f335f8e8f6a612cab8 4431 pcp_5.0.2-1.1.dsc 9ecc9331d3b2f39b9740a634e031d37059662f4c 23880 pcp_5.0.2-1.1.debian.tar.xz 511c1c1dfe15e63af86c72ce113291935ffdfd46 13405 pcp_5.0.2-1.1_source.buildinfo Checksums-Sha256: 27cb9c4988f08a58334641f9934653c2981dfd25af60a4f5c81e32bd84100441 4431 pcp_5.0.2-1.1.dsc 6461d2d46ca17dafccb619071797cfa181685ce95f7177844d0e8de644add209 23880 pcp_5.0.2-1.1.debian.tar.xz d52c1d56099eed66f2b6c455405630992476ea915a2c9d442c93e9a038ecdbd4 13405 pcp_5.0.2-1.1_source.buildinfo Files: e3b4b19a5b6a2f0dfe80c58720af1192 4431 utils extra pcp_5.0.2-1.1.dsc 23c9a11e11cbacef1329e41898c07dc8 23880 utils extra pcp_5.0.2-1.1.debian.tar.xz a0a60e47a8fed4b730c1609620fa4028 13405 utils extra pcp_5.0.2-1.1_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEPbRrVe+lnUDmIyFI0U7xXa/hE0cFAl4QZ6EACgkQ0U7xXa/h E0erOhAAh1pr2lco/d607zLf+donMDePQm11psc//QVXYEg9JkX86rQEvG23H3vt 5zeVTca3UtAXlrmwJBRylhIvTskF/fU+XBbQNYRAS/HLFD+4zEXdGHNbWvgI/QDy 7Nfo8synW5DgbppLcmgWdTmHtHeMDc7KYHwX7FvWLQ5v+EBcvhqnbLCq/JSy3Smx LjDu7nIYDKEM4voEyHfKEgEXofJvdL8r/RnO77v++YEtHWyi38RgGOUFHt2wZr4H O8l1r4Q1OGb733SFneCaLz2lY2p0a77ub+qB/3TffHvavq8qmEl3zC4NeKfHucj7 Qhoy+IhPBrt3Y6EASWGKKjnxS7sR59cPQXhJUiBrEc0elCAkq1ZIXnEk3Sx06sGo hQ8/jy5Zs0qWsv238hmGjfpAkIYcUSGDH47LReT4uBCZAvW8z5tp0YdStIovxr8n hoqwuNYU9S6yN+Pw1sMpfRkH6q38vYSddMLMWHGRCMxCcBSSsOeG4ce17pdw5QFD YAdVjbKpYhOgnjVm3QzfQGPVWw7Tvbsj7DEJG6ZXpvYB4chJhyVcu/KA81Ylqhdm zqclmZnn2HpNywNOHRETeIft0fH8hVAl0CE5kphxxrB6YIGyagno60w1Su3Plj0q LJtb7MCZ2bj89yVAQGhEYnH552QSXS3qpWuHF48ylQOScfN4Dwk= =VyGq -END PGP SIGNATURE-
Migration to testing blocked by broken piuparts?
Hi, two packages[¹, ²] I uploaded are "Rejected due to piuparts regression". I learned, that this is due to a bug in piuparts. Any solution on its way? Would I need to re-upload later? TIA & Cheers PS: Many thanks for running piuparts anyway. Such bugs happen, but the extra safety net it provides in the normal case is appreciated! ¹ https://tracker.debian.org/pkg/python-aiohttp-session ² https://tracker.debian.org/pkg/python-aiohttp-security
Re: Be nice to your fellow Debian colleagues
Dear Andrej, dear Andrew, Andrej Shadura - 01.01.20, 13:02:00 CET: > On Wed, 1 Jan 2020 at 12:40, Andrew McGlashan > > wrote: > > reasonable stakeholders, it is very limited to a small group of > > Debian users known collectively as DDs .. the current "gods" of > > Debian whom have ultimate power to do good or do bad with or for > > the project. [Such] Power corrupts and absolute power corrupts > > absolutely. > You’re most obviously trolling. You clearly understand there has to be > a way to limit the number of people taking the decision and the > period of voting to prevent vote manipulations. I don’t believe you > don’t understand everyone can become a DD, but it’s the DDs who do > the majority of meaningful work in Debian. > > I’d like to ask everyone to stop feeding this troll, and if they > continue posting this, report them to the listmasters. Although I do not agree with the wording of the paragraph you quoted, I did not see it as trolling. Especially in the first paragraph that you did not quote, Andrej, I see a reasonable critique of the process. Swinging the "troll" hammer can be a form of violence, too. However both Andrew and you, Andrej: I recommend to both of you as you have now stated your point of view tough, to let it be as it is. Agree to disagree for me means letting the other point of view to be there *as it is*. And I believe it would not get better by elaborating it, at least not for now. Note that this recommendation in my eyes is different than the other two recommendations: By all means state your point of view, share your emotions in a respectful and harmless manner, but when you are done, let it be as it is, and see where this takes you. Additionally to Andrew: Regarding your wording in the last paragraph I strongly recommend to you to open up to the possibility at everyone here may act with the *best intentions*. I am sure that both Ondřej and Sam acted with the best intentions. So I would not assume them to somehow act in a "corrupted" way. In my eyes this part of your message has not been helpful. I believe it may have been harmful or hurtful to some. *Assume best intention* really goes a long way! I now apply the recommendation to let it sit for a while to myself as well. I have expressed my point of view as well – and I do not believe that there is much to gain by elaborating on it, as I think what I wrote has been clear. Luckily I am off to some other activity now. So I will not see this list for a while. Again: Have a Happy New Year, everyone! Best, -- Martin signature.asc Description: This is a digitally signed message part.
Re: Be nice to your fellow Debian colleagues
Dear Ondřej, Ondřej Surý - 01.01.20, 09:39:35 CET: > Andrew, > > look at the subject, then look at what you wrote. If you can’t find > enough kindness in the situation and you are angry then it might be > better to not write anything at all. If one outcome of the GR is to ask people to shut up… then… again as I wrote in the other mail, I think it does not serve Debian's highest good. I agree with Andrew that at least some of the options in the GR were not about diversity or inclusion, but about exclusion and the opposite of diversity. I pointed it out *clearly* before hand, but that was all I could do. And I feel that Andrew has every right on this Earth to state this in a public mailing list on Debian. He did not say anything offensive or anything intended to hurt anyone or otherwise violating the Code of Conduct. So herewith I speak up for Andrew's right to voice his disappointment here as long as he does so within the Code of Conduct. "Being nice" is still something different than "shutting up". And asking someone to shut up in my point of view is not "being nice" to this person. That said, from the topic of your mail, it is about being "nice to your fellow Debian colleagues"… however we all know that your mail is related to the outcome of the GR and you even wrote so. Best, -- Martin
Accepted python-aiohttp-security 0.4.0-2 (source) into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 27 Dec 2019 09:56:39 + Source: python-aiohttp-security Architecture: source Version: 0.4.0-2 Distribution: unstable Urgency: medium Maintainer: Debian Python Modules Team Changed-By: Martin Changes: python-aiohttp-security (0.4.0-2) unstable; urgency=medium . * Fix architecture (any -> all) * Add demo files to -doc Checksums-Sha1: 0921b8740c86191e2ef0b5cf8ff5af667bda5300 2494 python-aiohttp-security_0.4.0-2.dsc 8c02737874a597f60c3f063611bea56c8c83ca04 2188 python-aiohttp-security_0.4.0-2.debian.tar.xz 8684f91952bc659f638ae585b3e01ac351115672 8908 python-aiohttp-security_0.4.0-2_amd64.buildinfo Checksums-Sha256: 5d90177c4d67ccb95708c9867bee60fcaf0a4ed0c8eaa5c4eda6e1ba7467270b 2494 python-aiohttp-security_0.4.0-2.dsc 09f0014810cbcdf60f8ca6e09a565dcaaa7eeae8044b0768b57938c251ec2a83 2188 python-aiohttp-security_0.4.0-2.debian.tar.xz dc7c123031453f8218402b315344fcfef595b84ced94750b9919848b1bdbf2a7 8908 python-aiohttp-security_0.4.0-2_amd64.buildinfo Files: 5714449a60539f9363285b3366fdca2e 2494 python optional python-aiohttp-security_0.4.0-2.dsc d9a043c0ac2fe2171de39c57d1fe75bd 2188 python optional python-aiohttp-security_0.4.0-2.debian.tar.xz da065914627d690b5292da1d4732433c 8908 python optional python-aiohttp-security_0.4.0-2_amd64.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEftHeo0XZoKEY1KdA4+Chwoa5Y+oFAl4F3RQACgkQ4+Chwoa5 Y+qOHg//RhhA0qblQe2sjTWs1AgXnO9gODCOzK0MOz1bFVukSREWPMbm1ZMeK0wA X4vDHgZ3ymwrjWULwxhw6RNde07ZYBasWpUvQVrbOo4Upq0Gh2sUp9hZcu4Moh7b QVxXmdDuyXoMricwvpg6zQDTj3ollvyUmP7/24p0XcpDsyWga73i8V4TMveg8D84 kq5EoiW0E+QRoZQphxvx/ald8Gjn35BHIPyYnBPx9akc1sG/c4ibQVFX0tXnYJQi xPMp/RYU0bgNJBft+Slre33d+JOHTr3v/UjDbIwOvd7+uA2WS+Jjhigg3iNY9jXd 2kcj2IiqZG9Ik2NnIy16E4/D5tAhx4SGe7YCLvc+nRAH7RPjSwe8j6Kmp4cCOBkj 5uaDsX9frBjTuMMjJpPQmhCCZplUyCkg/7lQVykJovNGLf9T9cSCDzIiCWSvIHYO u+qsEmFeVi32AVChslrpHagZPELEP2GYvRDr2OIzn+QKtJ4/IaY9z/v/23qbRNlu lbYSsATSS7dtaDfD//yjHM9/xMFxxYAeCk0b6LaEo0OJ2cNr7FdyCJvyWlL3Ksre Pqwy4l2+iL0tzflrqY4CAz66rOC2LTZJtpg/dxoitar8ol14T9gGW5mjEbFSc4RJ g+UyjH6bX9UuarohaDVPxEoIRVy/ww9aOhOZmE085g2sJ5Bp3A8= =Xzci -END PGP SIGNATURE-
