Processed: closing 1028557
Processing commands for cont...@bugs.debian.org: > close 1028557 Bug #1028557 [general] general: The Debian Social Contract (DSC) is meaningless Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1028557: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028557 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1065823: ITP: lenovolegionlinux -- CLI and GUI for Lenovo Legion laptops fan and power control
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lenovolegionlinux Version : 0.0.9 Upstream Contact: johnfanv2 * URL : https://github.com/johnfanv2/LenovoLegionLinux/ * License : GPL-2 Programming Lang: C, Python Description : CLI and GUI for Lenovo Legion laptops fan and power control This package provides a command line interface and a graphical user interface for controlling many power and fan behavior for Lenovo Legion Laptops. It is implemented in Python. . This package also sets fan curve on startup for Lenovo Legion laptops, and apply different profiles if the battery charge is plugged or not.
Bug#1065846: ITP: golang-github-magisterquis-connectproxy -- Connectproxy implements a proxy.Dialer which uses HTTP(s) CONNECT requests.
Package: wnpp Severity: wishlist Owner: Guilherme Puida Moreira * Package name: golang-github-magisterquis-connectproxy Version : 0.0~git20200725.3582e84-1 Upstream Author : Stuart * URL : https://github.com/magisterquis/connectproxy * License : Zlib Programming Lang: Go Description : Connectproxy implements a proxy.Dialer which uses HTTP(s) CONNECT requests. Small Go library to use CONNECT-speaking proxies standalone or with the proxy library. This is a dependency of croc, which I'm also working on packaging.
Re: Run Debian packaging tasks remotely with debusine.debian.net
On Sat, Mar 09, 2024 at 01:43:18PM +, Stefano Rivera wrote: > Hi Martin (2024.03.09_11:43:54_+) > > 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. > > We are building out the pieces that will lead to being able to > reimplement ratt within Debusine. > > Running ratt as a single debusine job wouldn't make as much sense as > running a single build for each changed reverse dependency. Indeed. The high-level goal for our second STF milestone is to add generic support for this sort of automatic orchestration of QA tasks across many packages, and we're currently working on the essential building blocks for this. https://salsa.debian.org/freexian-team/debusine/-/milestones/9 has details, especially anything to do with "collections" or "workflows". ratt as such isn't explicitly one of the funded developers' goals, and we'll probably probably start with automating runs of lintian and autopkgtest. However, I expect in a couple of months we'll have enough pieces to make it possible for Debian developers to build something like ratt using debusine - probably in a "some assembly required" kind of way at first. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
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 > > > > > > 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? > > Michael replied that an upgrade would result in both remaining > installed. That is precisely the situation that I previously t
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 > > > > > > > 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 > > >
Bug#1065924: ITP: lfanew -- tool to manipulate MZ stubs in NE/PE binaries
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lfanew Version : 0~20230825 Upstream Author : TK Chia * URL : https://codeberg.org/tkchia/lfanew * License : MPL-2.0 Programming Lang: C Description : tool to manipulate MZ stubs in NE/PE binaries lfanew is a tool manipulating the e_lfanew header field in MZ (DOS) binaries. It can - add a .e_lfanew field to an MZ binary, allowing it to be used as a DOS loader stub for a NE or PE binary; - stubify a NE/PE binary by combining it with an MZ stub; - extract a NE/PE binary from a stubified MZ/NE/PE binary pair. This is required to build dosemu2.
Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie
Hi, 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? I'm not sure how well NM is integrated with systemd-networkd now, but I would rather spend time on supporting such a combination and getting rid of all the old ways of configuring networking stuff than implementing yet another "client" solution. Bernd -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Rebuilding old packages to get rid of overalignment on amd64 which reduces ASLR
On Thu, 2024-03-07 at 11:48 +0100, Mathias Krause wrote: > > To get rid of the over-alignment, a rebuild with a linker that > doesn't enforce > the overly huge alignment any more is sufficient. In Debian terms > that would be > anything starting with buster. > > I, thereby, request to rebuild affected packages. So as I understand it: this will be fixed by itself as soon as somebody uploads or binNMUs the package? Then I would wait for some point near the release. And packages that haven't been touched since buster might need some qa love anyway!? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
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
