Bug#933539: /bin/bzgrep: 97: test: -eq: unexpected operator
Control: tags -1 confirmed It seems I wrongly forwarded the bzgrep patch, sorry! I will try to fix this soon. Thanks, -- Santiago El 31/07/19 a las 19:47, 積丹尼 Dan Jacobson escribió: > Package: bzip2 > Version: 1.0.8-1 > File: /bin/bzgrep > > $ bzgrep x b.bz2 > /bin/bzgrep: line 97: test: -eq: unary operator expected > /bin/bzgrep: line 100: test: too many arguments > > sh -x reveals: > + test -eq 1 > /bin/bzgrep: 97: test: -eq: unexpected operator > + test 1 -eq 1 -o -eq 1 > /bin/bzgrep: 100: test: -eq: unexpected operator > signature.asc Description: PGP signature
Bug#941599: ITP: altair -- Declarative Visualization in Python
Package: wnpp Severity: wishlist Owner: "Santiago Ruano Rincón" * Package name: altair Version : 3.2.0 Upstream Author : Jake Vanderplas, Brian Granger, the UW Interactive Data Lab, et al. * URL : https://altair-viz.github.io/ * License : BSD-3-Clause Programming Lang: Python Description : Declarative Visualization in Python Altair is a declarative statistical visualization library for Python, based on Vega [1] (A Visualization Grammar) and Vega-Lite [2]. [1] https://vega.github.io/vega/ [2] https://vega.github.io/vega-lite/ It would be great to maintain altair inside the Python Modules Team. signature.asc Description: PGP signature
Bug#944557: bzip2: built without LFS support
Control: tags -1 + pending El 11/11/19 a las 20:59, Sven Joachim escribió: > Package: bzip2 > Version: 1.0.6-9 > Severity: important > Tags: lfs > > On 32-bit systems bzip2 cannot handle files over 2 GiB, as seen here in > an i386 chroot: > > , > | $ dd if=/dev/zero of=bigfile bs=1 count=0 seek=2049M > | [...] > | $ bzip2 bigfile > | bzip2: Can't open input file bigfile: Value too large for defined data type. > ` > > The upstream Makefile sets -D_FILE_OFFSET_BITS=64 in CFLAGS (should > actually be in CPPFLAGS, but it does not really matter), but > debian/rules overwrites that setting since commit 8e1481f96b9[1]. Thanks for spotting this. I've pushed a commit to fix it: https://salsa.debian.org/debian/bzip2/commit/0aabaa7687a997be3a61a076fc9933a5e82a8ecf I'll be part of the next release. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#928462: new upstream (4.0)
Control: block -1 by 933692 Control: retitle -1 New upstream (4.2.2) Current latest upstream version is 4.2.2. Please note that knot (authoritative server) 2.8.0+ is required to build knot-resolver 4.x: https://knot-resolver.readthedocs.io/en/v4.2.2/build.html Cheers, -- Santiago signature.asc Description: PGP signature
Bug#940464: grep --and -eX -eY -eZ (X∩Y∩Z intersection, not X∪Y∪Z union)
Hi, El 16/09/19 a las 12:09, Trent W. Buck escribió: > Package: grep > Version: 3.3-1 > Severity: wishlist > > (Surely someone has already asked for this, but I can't see where. > I may have already reported this myself, and forgotten. > If so, sorry!) > > Right now if you do > > grep -eX -eY -eZ > > You'll get lines that match *any of* X, Y, or Z. > Quite often I want to search for lines that match *all of* X, Y, and Z — but > in any order. > For example, > > # all 4TB 2.5-inch SATA products > grep -Fwi -eSATA -e2TB -e2.5in products.csv > > Below is a short discussion of the workarounds I know about. > > Is "grep --and" something that has already been discussed and rejected? > I looked through debbugs.gnu.org and the source tarball, but > I couldn't find anything about this. > … Could you please forward your request to the upstream developers at bug-g...@gnu.org? I know I could do it by myself, but I'd prefer to keep you in the loop directly. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#940464: grep --and -eX -eY -eZ (X∩Y∩Z intersection, not X∪Y∪Z union)
Control: tags -1 + upstream El 16/09/19 a las 12:09, Trent W. Buck escribió: > Package: grep > Version: 3.3-1 > Severity: wishlist > > (Surely someone has already asked for this, but I can't see where. > I may have already reported this myself, and forgotten. > If so, sorry!) > > Right now if you do > > grep -eX -eY -eZ > > You'll get lines that match *any of* X, Y, or Z. > Quite often I want to search for lines that match *all of* X, Y, and Z — but > in any order. > For example, > > # all 4TB 2.5-inch SATA products > grep -Fwi -eSATA -e2TB -e2.5in products.csv > > Below is a short discussion of the workarounds I know about. > > Is "grep --and" something that has already been discussed and rejected? > I looked through debbugs.gnu.org and the source tarball, but > I couldn't find anything about this. > > > PS: grep -v --and would intuitively mean "not all", > i.e. "grep -v --and -eX -eY" would return lines matching X *or* Y, but > omit lines matching *both* X and Y. > > PS: I can't decide if "--and" or "--intersection" is a better name. > I put both in the bug subject so people searching for either will find this > ticket. > I think "--all" is probably too confusing. > > > > Workaround #1 > = > I can work around this by listing every possible order, but 1) this > scales poorly with the number of patterns; and 2) it can't be used > with -F. For example, > > grep --and -eX -eY -eZ input*.txt # becomes > > grep -eZ.*Y.*X \ > -eZ.*X.*Y \ > -eY.*Z.*X \ > -eY.*X.*Z \ > -eX.*Z.*Y \ > -eX.*Y.*Z \ > input*.txt > > > Workaround #2 > = > I can pipe greps together. This is what I currently do. > This is more convenient and feels faster than workaround #1, but > I suspect the inter-process overhead is significant. > > If grep implemented this internally, it could zero-copy. > Being able to "grep -rnH --and" would also be convenient. > > For example, > > grep --and -F -eX -eY -eZ input*.txt # becomes > > cat input*.txt | > grep -F -eX | > grep -F -eY | > grep -F -eZ signature.asc Description: PGP signature
Bug#938581: sugar: Python2 removal in sid/bullseye
Control: tags -1 + fixed-upstream pending Upstream has moved to Python 3 now. 0.116 version has been imported into salsa: https://salsa.debian.org/pkg-sugar-team/sugar/commit/b1f607f26702bc8b868ea994009533c6b27d2c88 On Fri, 30 Aug 2019 07:54:18 + Matthias Klose wrote: > Package: src:sugar > Version: 0.112-6 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal ... signature.asc Description: PGP signature
Bug#938581: [Pkg-sugar-devel] Bug#938581: sugar: Python2 removal in sid/bullseye
Control: tags -1 - fixed-upstream pending El 07/10/19 a las 15:38, Jonas Smedegaard escribió: > Quoting Santiago Ruano Rincón (2019-10-07 15:03:55) > > Control: tags -1 + fixed-upstream pending > > > > Upstream has moved to Python 3 now. 0.116 version has been imported > > into salsa: > > https://salsa.debian.org/pkg-sugar-team/sugar/commit/b1f607f26702bc8b868ea994009533c6b27d2c88 > > Beware that while the library specifically _can_ be built without > Python2, upstream nor Debian packaging in git has fully migrated to > Python3 across the board, and until that is done the library needs to be > built for both Pthon2 and Pyhon3. > > It therefore seems premature for us to set those two flags. OK. You're right. It was premature so I am reverting it. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#942041: lp --help should list -d (destination) option
Package: cups-client Version: 2.3.0-5 Severity: wishlist Tags: upstream Dear maintainer, lp --help lacks describing the -d destination option: Usage: lp [options] [--] [file(s)] lp [options] -i id Opciones: -c Make a copy of the print file(s) -E Encrypt the connection to the server -h server[:port]Connect to the named server and port … It woule be nice/useful to include the same description from the man page: -d destination Prints files to the named printer. Cheers, -- Santiago -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE=es_CO.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-client depends on: ii adduser 3.118 ii cups-common 2.3.0-5 ii libc62.29-2 ii libcups2 2.3.0-5 cups-client recommends no packages. Versions of packages cups-client suggests: ii cups 2.3.0-5 ii cups-bsd 2.3.0-5 pn smbclient -- no debconf information signature.asc Description: PGP signature
Bug#941666: ITP: vega-datasets -- Collection of datasets used in Vega and Vega-Lite examples
Package: wnpp Severity: wishlist Owner: "Santiago Ruano Rincón" * Package name: vega-datasets Version : 0.7 Upstream Author : Jake Vanderplas * URL : https://github.com/altair-viz/vega_datasets * License : MIT and others. Programming Lang: Python Description : Python package for offline access to vega datasets This is a collection of datasets used in vega examples. This is required to build altair (See ITP bug https://bugs.debian.org/941599), especially to run the test suite. Similar to altair, it would be great to maintain it within the Python Modules Team. signature.asc Description: PGP signature
Bug#936832: ldns: Python2 removal in sid/bullseye
Control: tags -1 + pending On Fri, 30 Aug 2019 07:22:47 + Matthias Klose wrote: > Package: src:ldns > Version: 1.7.0-4 > Severity: normal > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: py2removal > > Python2 becomes end-of-live upstream, and Debian aims to remove > Python2 from the distribution, as discussed in > https://lists.debian.org/debian-python/2019/07/msg00080.html … I've prepared the required changes to drop the python-ldns package in this branch https://salsa.debian.org/dns-team/ldns/-/tree/936832-stop-building-python-ldns and the corresponding MR: https://salsa.debian.org/dns-team/ldns/-/merge_requests/1 Unless Ondřej (or someone else) objects, I will apply them along with the package for the latest upstream release (1.7.1). Cheers, -- Santiago signature.asc Description: PGP signature
Bug#941599: ITP: altair -- Declarative Visualization in Python
Control: retitle: -1 ITP: python-altair -- Declarative Visualization in Python On Wed, 2 Oct 2019 17:21:26 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= wrote: > Package: wnpp > Severity: wishlist > Owner: "Santiago Ruano Rincón" > > * Package name: altair > Version : 3.2.0 > Upstream Author : Jake Vanderplas, Brian Granger, the UW Interactive Data > Lab, et al. > * URL : https://altair-viz.github.io/ > * License : BSD-3-Clause > Programming Lang: Python > Description : Declarative Visualization in Python > > Altair is a declarative statistical visualization library for Python, > based on Vega [1] (A Visualization Grammar) and Vega-Lite [2]. > > [1] https://vega.github.io/vega/ > [2] https://vega.github.io/vega-lite/ > > It would be great to maintain altair inside the Python Modules Team. I am changing the name to python-altair. I think it is more appropriate since it is a python module. packaging is taking place in: https://salsa.debian.org/python-team/modules/python-altair signature.asc Description: PGP signature
Bug#954239: RFP: python-b4 -- helper utility to work with patches made available via a public-inbox archive
El 19/03/20 a las 07:15, Salvatore Bonaccorso escribió: > Package: wnpp > Severity: wishlist > > * Package name: python-b4 > Version : v0.3.3 (or later) > Upstream Author : Konstantin Ryabitsev > * URL : https://git.kernel.org/pub/scm/utils/b4/b4.git > * License : GPL > Programming Lang: Python > Description : helper utility to work with patches made available via a > public-inbox archive > > This is a helper utility to work with patches made available via a > public-inbox archive like lore.kernel.org. It is written to make it > easier to participate in a patch-based workflows, like those used in > the Linux kernel development. > > For the package name, not sure if python-b4 or b4 is more appropriate. IMHO, if it's an application, b4 would be more appropriate. If it's a python module, then python-b4. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#941666: ITP: vega-datasets -- Collection of datasets used in Vega and Vega-Lite examples
Control: retitle -1 ITP: python-vega-datasets -- Collection of datasets used in Vega and Vega-Lite examples On Thu, 3 Oct 2019 16:48:20 +0200 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= wrote: > Package: wnpp > Severity: wishlist > Owner: "Santiago Ruano Rincón" > > * Package name: vega-datasets > Version : 0.7 > Upstream Author : Jake Vanderplas > * URL : https://github.com/altair-viz/vega_datasets > * License : MIT and others. > Programming Lang: Python > Description : Python package for offline access to vega datasets > > This is a collection of datasets used in vega examples. > > This is required to build altair (See ITP bug https://bugs.debian.org/941599), > especially to run the test suite. > > Similar to altair, it would be great to maintain it within the Python > Modules Team. Changing title to python-vega-datasets, since it's a python-module. Packaging is taking place at https://salsa.debian.org/python-team/modules/python-vega-datasets/ signature.asc Description: PGP signature
Bug#965074: Patches to make multicast proccesing on CDC NCM drivers
El 30/07/20 a las 16:07, Oliver Neukum escribió: > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano > Rincón: > > Hi, > > > > Miguel Rodríguez sent this set of patches two years ago to fix the lack > > of multicast processing on CDC NCM driver: > > > > https://www.spinics.net/lists/linux-usb/msg170611.html > > https://www.spinics.net/lists/linux-usb/msg170603.html > > https://www.spinics.net/lists/linux-usb/msg170567.html > > https://www.spinics.net/lists/linux-usb/msg170568.html > > > > I've using a DKMS version of them, available in > > https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches > > since more than a year ago, and they are working fine with my Dell D6000 > > docking station. IPv6 connectivity is broken without them. > > > > Is there any chance to consider those patches (or what would be needed > > to make it happen)? > > It would be great to have them upstream! > > Hi, > > they have been merged on Wednesday. … Great, thanks! It would be possible to apply/backport Miguel's patches (along with 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please? FWIW, in the context of Debian, I'm personally interested in 4.19.y. Best regards, -- Santiago signature.asc Description: PGP signature
Bug#965074: Patches to make multicast proccesing on CDC NCM drivers
El 02/09/20 a las 14:05, Greg KH escribió: > On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote: > > El 30/07/20 a las 16:07, Oliver Neukum escribió: > > > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano > > > Rincón: > > > > Hi, > > > > > > > > Miguel Rodríguez sent this set of patches two years ago to fix the lack > > > > of multicast processing on CDC NCM driver: > > > > > > > > https://www.spinics.net/lists/linux-usb/msg170611.html > > > > https://www.spinics.net/lists/linux-usb/msg170603.html > > > > https://www.spinics.net/lists/linux-usb/msg170567.html > > > > https://www.spinics.net/lists/linux-usb/msg170568.html > > > > > > > > I've using a DKMS version of them, available in > > > > https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches > > > > since more than a year ago, and they are working fine with my Dell D6000 > > > > docking station. IPv6 connectivity is broken without them. > > > > > > > > Is there any chance to consider those patches (or what would be needed > > > > to make it happen)? > > > > It would be great to have them upstream! > > > > > > Hi, > > > > > > they have been merged on Wednesday. > > … > > > > Great, thanks! > > > > It would be possible to apply/backport Miguel's patches (along with > > 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please? > > I don't see that git commit id in Linus's tree, are you sure it is > correct? I should had mention it is found in linux-next, sorry. Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969365#10 > > FWIW, in the context of Debian, I'm personally interested in 4.19.y. > > What specific list of commits are you wanting to see backported? This: 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6 e10dcb1b6ba714243ad5a35a11b91cc14103a9a9 e506addeff844237d60545ef4f6141de21471caf 0226009ce0f6089f9b31211f7a2703cf9a327a01 Thanks, -- santiago signature.asc Description: PGP signature
Bug#943616: devscripts: debuild does not realise --build=source means .changes will be named _source.changes
On Sun, 27 Oct 2019 21:11:27 +1000 Russell Stuart
wrote:
> Package: devscripts
> Version: 2.19.5+deb10u1
> Severity: minor
>
> Running this:
>
>debuild --preserve-env --preserve-envvar=PATH -k0xF5231C62E7843A8C
> '-mRussell Stuart ' -sa --build=source
> --lintian-opts --info --display-info --display-experimental
>
> gets me the error:
>
>debuild: fatal error at line 1062:
>can't open pam-python_1.0.6-1.1+deb9u1_amd64.changes for reading: No such
> file or directory
>
> If you replace --build=source with -S it works.
I can confirm this. And I'd say it deserves a more important Severity,
the behaviour doesn't match what it's documented.
I can also confirm dpkg-buildpackage {--build=source,-S} work both as
expected.
Cheers,
-- Santiago
signature.asc
Description: PGP signature
Bug#969341: knot-resolver: [INTL:nl] Dutch translation of debconf messages
Control: tags -1 + pending El 31/08/20 a las 20:33, Frans Spiesschaert escribió: > > > Package: knot-resolver > Severity: wishlist > Tags: l10n patch > > > > Dear Maintainer, > > > Please find attached the Dutch translation of knot-resolver debconf > messages. > It has been submitted for review to the debian-l10n-dutch mailing list. > Please add it to your next package revision. > It should be put as debian/po/nl.po in your package build tree. Thanks for the translation! I have just pushed it to the git repo. Thanks, -- Santiago signature.asc Description: PGP signature
Bug#969478: knot-resolver: [INTL:fr] French debconf templates translation
Control: tags -1 + pending El 03/09/20 a las 18:24, Jean-Pierre Giraud escribió: > Package: knot-resolver > Severity: wishlist > Tags: patch l10n > > Hi! > > Please find attached the french debconf templates translation, proofread > by the debian-l10n-french mailing list contributors. > > This file should be put as debian/po/fr.po in your package build tree. Thanks for the translation! I have just pushed it to the git repo. Thanks, -- Santiago signature.asc Description: PGP signature
Bug#969234: knot-resolver: [INTL:de] initial German debconf translation
Control: tag -1 + pending El 29/08/20 a las 20:37, Helge Kreutzmann escribió: > Package: knot-resolver > Version: 5.1.2-3 > Severity: wishlist > Tags: patch l10n > > Please find the initial German debconf translation for knot-resolver > attached. > > Please place this file in debian/po/ as de.po for your next upload. Thanks for the translation! I have just pushed it to the git repo. Thanks, -- Santiago signature.asc Description: PGP signature
Bug#965074: Patches to make multicast proccesing on CDC NCM drivers
El 02/09/20 a las 17:45, Greg KH escribió: > On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote: > > El 02/09/20 a las 14:05, Greg KH escribió: > > > On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote: > > > > El 30/07/20 a las 16:07, Oliver Neukum escribió: > > > > > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano > > > > > Rincón: … > > > > > > > > It would be possible to apply/backport Miguel's patches (along with > > > > 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please? > > > > > > I don't see that git commit id in Linus's tree, are you sure it is > > > correct? > > > > I should had mention it is found in linux-next, sorry. Please see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969365#10 > > Ah, nothing I can do with patches that are not yet in Linus's tree. > ACK. > > > > FWIW, in the context of Debian, I'm personally interested in 4.19.y. > > > > > > What specific list of commits are you wanting to see backported? > > > > This: > > > > 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6 > > e10dcb1b6ba714243ad5a35a11b91cc14103a9a9 > > e506addeff844237d60545ef4f6141de21471caf > > 0226009ce0f6089f9b31211f7a2703cf9a327a01 > > These do not look like bugfixes, but a new feature being added for this > driver. So why not just use a newer kernel version for this feature? From my point of view as user these are bugfixes, since IPv6 NDP or any other protocol relying on multicast do not work without them. In other words, my computer's networking is broken. I want to have them in linux stable releases because that would make easier to include them in Debian stable release. Thanks! -- Santiago signature.asc Description: PGP signature
Bug#961076: NXNS Attack (CVE-2020-12667)
El 14/10/20 a las 10:12, Andrew Savchenko escribió: > Dear Maintainers, > > Is there still a plan to backport a fix for CVE-2020-12667 into Buster? > > Looking at the changelog [1], there is nothing that indicates it is already > fixed. > > [1] > https://metadata.ftp-master.debian.org/changelogs//main/k/knot-resolver/knot-resolver_3.2.1-3_changelog Hi, It is up to the security-team (in CC) to accept or not the proposed backport. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#838871: ifupdown: attempts to bring up allow-hotplug interfaces at boot ignoring link state
Control: tags -1 + pending On Sun, 25 Sep 2016 17:31:23 -0400 manul wrote: > Package: ifupdown > Version: 0.8.16 > Severity: normal > > Dear Maintainer, > > My laptops cable interface eth0 is listed in /etc/network/interfaces, using > the following stanza: > > >> allow-hotplug eth0 > >> iface eth0 inet dhcp > > The reason I use allow-hotplug is: > > As per man interfaces 5, I want my eth0 interface to be brought up (and > dchp-initialized) only when the link gets up (cable gets connected). > So in a typical situation when I reboot with eth0 cable unplugged, waiting > for link initialization does not block the bootup process until timeout. > > However since recent update, ifupdown sysvinit script seems to have started > ignoring this stanza and attempts to bring up interfaces listed as > allow-hotplug in /etc/network/interfaces at boot, even if they are unplugged > (cable not connected). > > > Outcome: > > When I boot with eth0 cable unplugged in the bootup log sequence I get: > >> Configuring network interfaces... > >> ifup: waiting for lock on /run/network/interfaces/ifstate.eth0 > > At this point the boot is stuck for about 1 min until the message "ifup: > interface eth0 already configured" comes up, and bootup continues. > > > Expected outcome: > > Upon boot with cable unplugged (link state down), interfaces listed as > allow-hotplug should not be brought up/ initialized. ... This commit already in the master branch addresses the issue: https://salsa.debian.org/debian/ifupdown/-/commit/c25a05a79da5bb4f8fdc81c830f5b9624b462a06 -- Santiago signature.asc Description: PGP signature
Bug#952455: ifupdown-wait-online.service ping check logic issue
Control: tags -1 + pending On Mon, 24 Feb 2020 18:26:11 +0100 Martin Weinelt wrote: > Package: ifupdown > Version: 0.8.35 > Severity: important > > Dear Maintainer, > > the ping/ping6 check in ifupdown-wait-online.service terminates early > because ping won't honor the wait time if it cannot find a route. > > -- Logs begin at Mon 2020-02-24 18:09:46 CET, end at Mon 2020-02-24 18:23:48 > CET. -- > Feb 24 18:09:46 elsa wait-online.sh[313]: + WAIT_ONLINE_METHOD=ifup > Feb 24 18:09:46 elsa wait-online.sh[313]: + WAIT_ONLINE_IFACE= > Feb 24 18:09:46 elsa wait-online.sh[313]: + WAIT_ONLINE_ADDRESS= > Feb 24 18:09:46 elsa wait-online.sh[313]: + WAIT_ONLINE_TIMEOUT=300 > Feb 24 18:09:46 elsa wait-online.sh[313]: + [ -f /etc/default/networking ] > Feb 24 18:09:46 elsa wait-online.sh[313]: + . /etc/default/networking > Feb 24 18:09:46 elsa wait-online.sh[313]: + WAIT_ONLINE_METHOD=ping6 > Feb 24 18:09:46 elsa wait-online.sh[313]: + > WAIT_ONLINE_ADDRESS=2001:67c:2ed8::1 > Feb 24 18:09:46 elsa wait-online.sh[313]: + /bin/ping6 -q -c 1 -w 300 > 2001:67c:2ed8::1 > Feb 24 18:09:46 elsa wait-online.sh[313]: connect: Network is unreachable > > This makes the service fail early. … This commit, already present in the master branch, addresses the issue: https://salsa.debian.org/debian/ifupdown/-/commit/161a1714774861717e242bb11626c3d7daebb742 -- Santiago signature.asc Description: PGP signature
Bug#923640: "ifupdown" 0.8.35 breaks DHCP and DNS resolving.
Control: tags -1 + pending
On Sun, 03 Mar 2019 09:37:17 + "Gong S." wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Package: ifupdown
> Version: 0.8.35
> Severity: important
>
> Since I upgraded "ifupdown" from 0.8.34 to 0.8.35, I cannot get an IP address
> from DHCP at boot.
> Also, despite that I can still use "dhclient eth0" to get an IP, every domain
> fails to resolve.
> (I can still "ping" an address to get an IP, but anything else ("apt update",
> web browsing etc) will not work).
> The network in question is IPv4-only requires me to access a login page.
> However, if I booted up System Rescue CD, login and "chroot", there is still
> no resolving inside chroot despite that the host has no problem.
> I am not using a network manager because of Poetterware. I am using
> "sysvinit-core" and "sysv-rc".
> I have read the changelog and I believe the DHCP problem is caused by the
> suggestion in #906894. No idea about the resolving problem.
...
This commit, already present in the master branch, addresses the issue:
https://salsa.debian.org/debian/ifupdown/-/commit/40eb51499fe71e4fb20c27beea23045c62e9ba07
-- Santiago
signature.asc
Description: PGP signature
Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)
Hi peb, On Sat, 5 Sep 2020 00:23:17 +0200 Pierre-Elliott =?utf-8?B?QsOpY3Vl?= wrote: > Control: tags -1 +moreinfo > > Hey Santiago, > > Thanks for the bugreport! > > Le jeudi 09 juillet 2020 à 22:28:06+0200, Santiago R.R. a écrit : > > Package: lxc > > Version: 1:3.1.0+really3.0.3-8 > > Severity: important > > > > Dear Maintainer, > > > > After creating an lxc container, I've manually set a MAC address for it. > > The container fails to start, giving this output in the logs: > > > > lxc-start container-name 20200709195149.256 ERRORnetwork - > > network.c:setup_hw_addr:2762 - Cannot assign requested address - Failed to > > perform ioctl > > lxc-start container-name 20200709195149.256 ERRORnetwork - > > network.c:lxc_setup_netdev_in_child_namespaces:2907 - Failed to setup hw > > address for network device "eth0" > > lxc-start container-name 20200709195149.256 ERRORnetwork - > > network.c:lxc_setup_network_in_child_namespaces:3047 - failed to setup > > netdev > > lxc-start container-name 20200709195149.256 ERRORconf - > > conf.c:lxc_setup:3540 - Failed to setup network > > lxc-start container-name 20200709195149.257 ERRORstart - > > start.c:do_start:1275 - Failed to setup container "container-name" > > lxc-start container-name 20200709195149.257 ERRORsync - > > sync.c:__sync_wait:62 - An error occurred in another process (expected > > sequence number 5) > > lxc-start container-name 20200709195149.258 ERRORlxccontainer - > > lxccontainer.c:wait_on_daemonized_start:842 - Received container state > > "ABORTING" instead of "RUNNING" > > lxc-start container-name 20200709195149.258 ERRORlxc_start - > > tools/lxc_start.c:main:330 - The container failed to start > > lxc-start container-name 20200709195149.259 ERRORlxc_start - > > tools/lxc_start.c:main:333 - To get more details, run the container in > > foreground mode > > lxc-start container-name 20200709195149.259 ERRORlxc_start - > > tools/lxc_start.c:main:336 - Additional information can be obtained by > > setting the --logfile and --logpriority options > > lxc-start container-name 20200709195149.275 ERRORstart - > > start.c:__lxc_start:1951 - Failed to spawn container "container-name" > > > > In the host I can see this: > > > > ... > > Jul 09 19:53:42 olimicro audit[4788]: AVC apparmor="STATUS" > > operation="profile_load" profile="/usr/bin/lxc-start" > > name="lxc-container-name_" pid=4788 comm="apparmor_parser" > > Jul 09 19:53:42 olimicro kernel: audit: type=1400 > > audit(1594324422.794:57): apparmor="STATUS" operation="profile_load" > > profile="/usr/bin/lxc-start" name="lxc-container-name_" > > pid=4788 comm="apparmor_parser" > > Jul 09 19:53:42 olimicro kernel: br0: port 4(vethETHNAME) entered > > blocking state > > Jul 09 19:53:42 olimicro kernel: br0: port 4(vethETHNAME) entered > > disabled state > > Jul 09 19:53:42 olimicro systemd-udevd[4789]: link_config: > > autonegotiation is unset or enabled, the speed and duplex are not writable. > > Jul 09 19:53:42 olimicro kernel: device vethETHNAME entered promiscuous > > mode > > Jul 09 19:53:42 olimicro kernel: IPv6: ADDRCONF(NETDEV_UP): > > vethETHNAME: link is not ready > > Jul 09 19:53:42 olimicro systemd-udevd[4789]: Using default interface > > naming scheme 'v240'. > > Jul 09 19:53:42 olimicro systemd-udevd[4789]: Could not generate > > persistent MAC address for vethHP689N: No such file or directory > > This is weird, first the interface is vethETHNAME and then vethHP689N… > are you sure there isn't a quirk in your config or your bridge config? I don't think so. It's a simple bridge managed by nm. > > I use hardcoded macs in configurations on buster since the release > without any issue, but I'm under amd64 arch... > > > Jul 09 19:53:42 olimicro NetworkManager[935]: [1594324422.8520] > > manager: (vethHP689N): new Veth device > > (/org/freedesktop/NetworkManager/Devices/37) > > Jul 09 19:53:42 olimicro systemd-udevd[4790]: link_config: > > autonegotiation is unset or enabled, the speed and duplex are not writable. > > Jul 09 19:53:42 olimicro kernel: eth0: renamed from vethHP689N > > Jul 09 19:53:42 olimicro systemd-udevd[4790]: Using default interface > > naming scheme 'v240'. > > Jul 09 19:53:42 olimicro sudo[4781]: pam_unix(sudo:session): session > > closed for user root > > Jul 09 19:53:42 olimicro NetworkManager[935]: [1594324422.9294] > > manager: (vethETHNAME): new Veth device > > (/org/freedesktop/NetworkManager/Devices/38) > > Jul 09 19:53:43 olimicro audit[4795]: AVC apparmor="STATUS" > > operation="profile_remove" profile="/usr/bin/lxc-start" > > name="lxc-container-name_" pid=4795 comm="apparmor_parser" > > Jul 09 19:53:43 olimicro kernel: audit: type=1400 > > audit(1594324423.898:58): apparmor="STATUS" operation="profile_remove" > > profile="/usr/bin/lxc-start"
Bug#908137: luajit: lightuserdata problem with > 47 bit address space on arm64
Control: tags -1 fixed-upstream On Thu, 06 Sep 2018 16:54:30 +0300 Adrian Bunk wrote: > Source: luajit > Version: 2.0.4+dfsg-1 > Severity: serious > Forwarded: https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-260205661 > > This is an RFC regarding what to do for avoiding runtime > problems on arm64 like e.g. #907729. > > The big hammer would be to drop luajit on arm64, > reverse dependencies are already able to cope > with luajit not available on s390x. > > From the latest comment by upstream on the same PR https://github.com/LuaJIT/LuaJIT/pull/230#issuecomment-701054121 it seems this has been fixed now. This is the relevant commit: https://github.com/LuaJIT/LuaJIT/commit/e9af1abec542e6f9851ff2368e7f196b6382a44c signature.asc Description: PGP signature
Bug#965938: dnssec-trigger-script: add new trust-ad option to /etc/resolv.conf when using local unbound resolver
Control: forwarded -1 https://github.com/NLnetLabs/dnssec-trigger/issues/5 Control: tags -1 fixed-upstream On Tue, 21 Jul 2020 09:59:23 +0800 Paul Wise wrote: > Package: dnssec-trigger > Version: 0.17+repack-3+b1 > Severity: important > File: /usr/lib/dnssec-trigger/dnssec-trigger-script > > It looks like the dnssec-trigger-script will need to be adapted to this > change in glibc in order to keep working: … Fixed by this commit: https://github.com/NLnetLabs/dnssec-trigger/commit/c1fe2e64c9fa0ac5099e67429de2860746d5a0a1 signature.asc Description: PGP signature
Bug#837920: user-mode-linux should be built directly by src:linux
On Tue, 20 Sep 2016 06:31:46 -0700 Mattia Dongili wrote: > On Tue, Sep 20, 2016 at 03:14:13PM +0300, Adrian Bunk wrote: > > On Fri, Sep 16, 2016 at 06:20:34AM -0700, Mattia Dongili wrote: > > >... > > > Let's see where I get to in integrating the UML build with src:linux, > > >... … I am taking a look at this. But before going any further, Ritesh, would you be willing to taking care of UML within src:linux ? If yes, I hope* to send a MR the next week. Cheers, -- Santiago * But considering current conditions, this could take a little bit longer. signature.asc Description: PGP signature
Bug#952673: does not start automatically anymore on fresh installs
Hi Daniel, On Sun, 1 Mar 2020 21:00:20 +0100 Daniel Baumann wrote: > severity 952673 serious > thanks > > bumping severity as this breaks all our systems atm. it can be > reproduced on a clean install, and then installing knot-resolver, which > will not start any kresd instances. > > a manual "systemctl start kresd@1" after every boot workarounds it. … I'd rather downgrade severity to important. IMHO, the fact that the service is not automagically started after package installation doesn't mean it is broken. Please, correct me if I'm wrong, but I am not aware of anything in Debian Policy stating the opposite. The behaviour is different from the version in buster, but I am not sure that's enough for RC severity. Ondřej, dkg, any thoughts? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#963599: transition: ldns
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, ldns 1.7.1-1 is now available in experimental. It includes a soname bump libldns2 -> libldns3, that concerns these reverse dependencies: dnssec-trigger dnstap-ldns libnet-ldns-perl libreswan nordugrid-arc opendnssec python-libtrace I've successfully built all of them against ldns 1.7.1-1 on amd64. If I am not wrong, this should be the Ben file: title = "ldns"; is_affected = .depends ~ /\b(libldns2|python\-ldns)\b/ | .depends ~ /\b(libldns3)\b/; is_good = .depends ~ /\b(libldns3)\b/; is_bad = .depends ~ /\b(libldns2|python\-ldns)\b/; Please, schedule the transition and binNMUs for the above mentioned reverse dependencies. Thanks! -- Santiago signature.asc Description: PGP signature
Bug#961076: NXNS Attack (CVE-2020-12667)
Control: tags -1 + pending On Tue, 19 May 2020 22:16:06 +0200 Daniel Baumann wrote: > Package: knot > Severity: serious > Tag: security > > Hi, > > it would be nice if you could upgrade to the current upstream version of > knot-resolver (5.1.1) which mitigates CVE-2020-12667 aka NXNS Attack. … I am preparing a branch for this release: https://salsa.debian.org/dns-team/knot-resolver/-/merge_requests/4 signature.asc Description: PGP signature
Bug#952673: does not start automatically anymore on fresh installs
El 10/07/20 a las 18:50, Daniel Baumann escribió: > On 7/10/20 3:13 PM, Santiago Ruano Rincón wrote: > > I'd rather downgrade severity to important. > > i'd rather not - either it's a bug and then it should be fixed, or, if > the new behaviour is on purpose, then it needs to be documented and > handled for upgrades. > > in either way, upgrading buster->bullseye leaves systems without working > DNS, which deserves severity serious. Ah, you're right. I thought kresd continued to be enabled when upgrading to 5.x. I leave this as a note: kresd upstream removed systemd sockets support since 5.0: https://gitlab.nic.cz/knot/knot-resolver/-/issues/485 From NEWS: Knot Resolver 5.0.0 (2020-01-27) Incompatible changes - see upgrading guide: https://knot-resolver.readthedocs.io/en/stable/upgrading.html - systemd sockets are no longer supported (#485) ... Also, upstream includes maintainer scripts to handle changes during upgrading. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
On Wed, 27 May 2020 11:56:07 +0200 "Santiago R.R." wrote: > Package: release.debian.org > Severity: normal > Tags: buster > User: release.debian@packages.debian.org > Usertags: pu > > Dear Release Managers, > > Since 1.0.6-9, bzip2 was built without the -D_FILE_OFFSET_BITS=64 > CPPFLAG, and so it's not able to handle > 2GB files in 32-bit archs. > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944557 > > I've uploaded a fixed version to unstable yesterday. It would be great > to fix it also in buster. Please, consider the attached debdiff. > Would it be OK for you to upload it? > > I've confirmed the issue is solved in an armhf machine running buster. … Dear RM, I would like to include another important bug fix in this upload. Attached you can find a refreshed debdiff that also address #965309 in buster: https://bugs.debian.org/965309 Would it be OK to upload it? Thanks, -- Santiago diff -Nru bzip2-1.0.6/debian/changelog bzip2-1.0.6/debian/changelog --- bzip2-1.0.6/debian/changelog2019-07-10 21:17:52.0 +0200 +++ bzip2-1.0.6/debian/changelog2020-07-21 10:36:47.0 +0200 @@ -1,3 +1,13 @@ +bzip2 (1.0.6-9.2~deb10u2) buster; urgency=medium + + * Append -D_FILE_OFFSET_BITS=64 variable to buildflags, to renable handling +big files in 32-bit archs (Closes: #944557) + * debian/patches/40-bzdiff-l.patch: Fix bzdiff does not work when comparing +two bzip2 compressed files. Thanks to Joey Schulze . +(Closes: #965309) + + -- Santiago Ruano Rincón Tue, 21 Jul 2020 10:36:47 +0200 + bzip2 (1.0.6-9.2~deb10u1) buster; urgency=medium * Rebuild for buster diff -Nru bzip2-1.0.6/debian/patches/40-bzdiff-l.patch bzip2-1.0.6/debian/patches/40-bzdiff-l.patch --- bzip2-1.0.6/debian/patches/40-bzdiff-l.patch2019-06-24 22:16:40.0 +0200 +++ bzip2-1.0.6/debian/patches/40-bzdiff-l.patch2020-07-21 10:32:51.0 +0200 @@ -2,10 +2,14 @@ This patch is far from sufficient. See the bug log for details. Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/bzip2/+bug/735675 Origin: ubuntu, https://bugs.launchpad.net/ubuntu/+source/bzip2/+bug/735675 +Reviewed-by: Santiago Ruano Rincón +Last-Update: 2020-07-20 a/bzdiff -+++ b/bzdiff -@@ -24,7 +24,11 @@ +Index: bzip2/bzdiff +=== +--- bzip2.orig/bzdiff bzip2/bzdiff +@@ -24,7 +24,11 @@ FILES= for ARG do case "$ARG" in @@ -18,12 +22,3 @@ *) if test -f "$ARG"; then FILES="$FILES $ARG" else -@@ -54,7 +58,7 @@ - exit 1 - } - bzip2 -cdfq "$2" > "$tmp" --bzip2 -cdfq "$1" | $comp $OPTIONS - "$tmp" -+bzip2 -cdfq "$1" | $comp "$OPTIONS" - "$tmp" - STAT="$?" - /bin/rm -f "$tmp";; - diff -Nru bzip2-1.0.6/debian/rules bzip2-1.0.6/debian/rules --- bzip2-1.0.6/debian/rules2019-06-24 22:16:40.0 +0200 +++ bzip2-1.0.6/debian/rules2020-07-21 10:31:21.0 +0200 @@ -14,6 +14,9 @@ DEB_BUILD_MAINT_OPTIONS := hardening=+all DEB_CFLAGS_MAINT_APPEND := -Wall -Winline DEB_CPPFLAGS_MAINT_APPEND := -D_REENTRANT +# This -D_FILE_OFFSET_BITS=64 is needed to make bzip2 able to handle > 2GB-size +# files in 32-bit archs. See #944557 +DEB_CPPFLAGS_MAINT_APPEND += -D_FILE_OFFSET_BITS=64 include /usr/share/dpkg/buildflags.mk include /usr/share/dpkg/pkg-info.mk signature.asc Description: PGP signature
Bug#976737: Wrong result of maintainer-script-supports-ancient-package-version
Package: lintian Version: 2.104.0 Severity: minor Dear lintian maintainers, While preparing the knot 3.0.2-2 release, `lintian -i -EvIL -pedantic ../knot_3.0.2-2_amd64.changes` reports: ... X: knot: maintainer-script-supports-ancient-package-version postinst:14 2.5.0-1 (2017-06-07 < 2017-06-18) N: I: maintainer-script-supports-ancient-package-version N: N: The maintainer script appears to detect the specified version which N: was prepared prior to the release of oldstable. N: N: Please remove the code/check for this version as such upgrades (etc.) N: are unsupported. N: N: Severity: info N: N: Check: scripts N: N: This tag is experimental. 2.5.0-1 is indeed an ancient package version. But in contrast to the information from lintian, it was released after oldstable (currently stretch), that includes 2.4.0-3+deb9u1: knot | 1.6.0-1+deb8u1 | oldoldstable| source, amd64, armel, armhf, i386 knot | 2.4.0-3+deb9u1 | oldstable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x knot | 2.4.0-3+deb9u1 | oldstable-debug | source knot | 2.7.6-2~bpo9+1 | stretch-backports | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x knot | 2.7.6-2~bpo9+1 | stretch-backports-debug | source knot | 2.7.6-2| stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x knot | 2.9.6-1| testing | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x knot | 2.9.6-1| unstable| source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x knot | 2.9.6-1| unstable-debug | source knot | 3.0.2-1| experimental| source, amd64, arm64, armhf, i386, mips64el, mipsel, ppc64el, s390x knot | 3.0.2-1| experimental-debug | source Cheers, -- Santiago -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.35.1-3 ii bzip2 1.0.8-4 ii diffstat1.63-1 ii dpkg1.20.5 ii dpkg-dev1.20.5 ii file1:5.39-3 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b4 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b6 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.24-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1 ii libdevel-size-perl 0.83-1+b2 ii libdpkg-perl1.20.5 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1 ii libhtml-html5-entities-perl 0.004-1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.416-1+b6 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.114-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-1 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012000-1 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.05-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.21-8 ii lzop1.04-2 ii man-db
Bug#976827: knot-resolver: please make the build reproducible
Control: tag -1 + pending, upstream El 08/12/20 a las 11:00, Chris Lamb escribió: > Source: knot-resolver > Version: 5.2.0-2 > Severity: wishlist > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: timestamps > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org > > Hi, > > Whilst working on the Reproducible Builds effort [0] we noticed that > knot-resolver could not be built reproducibly. Patch attached that uses > SOURCE_DATE_EPOCH to populate its manpages. > > [0] https://reproducible-builds.org/ ... Thanks Chris! Patch applied, it will be part of the next release. -- Santiago P.S. 5.2.0-2 passed the reprotest Salsa CI job: https://salsa.debian.org/dns-team/knot-resolver/-/jobs/1221184 I wonder what can be done to match the reproducible-builds.org behaviour. signature.asc Description: PGP signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
El 19/11/20 a las 16:45, Jakub Ružička escribió: > On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote: > > El 09/11/20 a las 13:31, Jakub Ružička escribió: > >> Package: wnpp > >> Severity: wishlist > >> Owner: Jakub Ružička > >> > >> * Package name: lua-binaryheap > >> Version : 0.4 > >> Upstream Author : Thijs Schreijer > >> * URL : https://github.com/Tieske/binaryheap.lua > >> * License : MIT > >> Programming Lang: lua > >> Description : binary heap implementation in lua > >> > >> binaryheap.lua is a binary heap (binary tree) implementaion in lua. > >> > > ... > > > > Jakub, thanks for packaging lua-binaryheap. > Thanks for fast respone, Santiago :) > > > > Two lintian "major" comments from your current repo: > > > > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released > > 2016-04-06) (current is 4.5.0) > > W: lua-binaryheap source: package-uses-deprecated-debhelper-compat-version 9 > > > > Do you have any reason for that standards-version and > > debhelper-compat-version? > Upstream packages support older distros including ubuntu xenial so it's > just a leftover - I've updated these to current. > > > > These other lintian minor warnings could be easily fixed: > > > > I: lua-binaryheap: capitalization-error-in-description lua Lua > > I: lua-binaryheap source: debian-watch-file-is-missing > > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git > > > > Could you please consider them? > I've fixed all of them except debian-watch-file-is-missing because > upstream is using one the weirdest version tag scheme I've witnessed > (version_0v4) and I'm not familiar with watch files enough to solve this > efficiently. Great, thanks! I'll upload it later this evening. > > I've pushed fixed debian/master and you can see lintian output in CI: > > https://salsa.debian.org/jruzicka/lua-binaryheap/-/jobs/1176088#L27 > > Thank you for Salsa CI suggestion and help with enabling it. I like it > and I'll probably use it for other packages too. :-) Cheers, -- Santiago signature.asc Description: PGP signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
El 19/11/20 a las 17:56, Santiago Ruano Rincón escribió: > El 19/11/20 a las 16:45, Jakub Ružička escribió: > > On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote: > > > El 09/11/20 a las 13:31, Jakub Ružička escribió: > > >> Package: wnpp > > >> Severity: wishlist > > >> Owner: Jakub Ružička > > >> > > >> * Package name: lua-binaryheap > > >> Version : 0.4 > > >> Upstream Author : Thijs Schreijer > > >> * URL : https://github.com/Tieske/binaryheap.lua > > >> * License : MIT > > >> Programming Lang: lua > > >> Description : binary heap implementation in lua > > >> > > >> binaryheap.lua is a binary heap (binary tree) implementaion in lua. > > >> > > > ... > > > > > > Jakub, thanks for packaging lua-binaryheap. > > Thanks for fast respone, Santiago :) > > > > > > Two lintian "major" comments from your current repo: > > > > > > W: lua-binaryheap source: ancient-standards-version 3.9.8 (released > > > 2016-04-06) (current is 4.5.0) > > > W: lua-binaryheap source: > > > package-uses-deprecated-debhelper-compat-version 9 > > > > > > Do you have any reason for that standards-version and > > > debhelper-compat-version? > > Upstream packages support older distros including ubuntu xenial so it's > > just a leftover - I've updated these to current. > > > > > > These other lintian minor warnings could be easily fixed: > > > > > > I: lua-binaryheap: capitalization-error-in-description lua Lua > > > I: lua-binaryheap source: debian-watch-file-is-missing > > > I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git > > > > > > Could you please consider them? > > I've fixed all of them except debian-watch-file-is-missing because > > upstream is using one the weirdest version tag scheme I've witnessed > > (version_0v4) and I'm not familiar with watch files enough to solve this > > efficiently. > > Great, thanks! > I'll upload it later this evening. ... Before uploading a wanted to take a look at the debian/watch file. Attached you can find a work-in-progress version. I cannot work more on it today. There is still an error after downloading the file. Would you like to fix it? (c.f. man uscan) Cheers, -- S version=4 opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1\.tar\.gz/,uversionmangle=s/v/./" \ https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz signature.asc Description: PGP signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
El 19/11/20 a las 22:04, Santiago Ruano Rincón escribió: > El 19/11/20 a las 17:56, Santiago Ruano Rincón escribió: > > El 19/11/20 a las 16:45, Jakub Ružička escribió: > > > On 11/17/20 4:41 PM, Santiago Ruano Rincón wrote: > > > > El 09/11/20 a las 13:31, Jakub Ružička escribió: > > Before uploading a wanted to take a look at the debian/watch file. > Attached you can find a work-in-progress version. I cannot work more on > it today. There is still an error after downloading the file. Would you > like to fix it? (c.f. man uscan) > > Cheers, > > -- S > version=4 > opts="filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1\.tar\.gz/,uversionmangle=s/v/./" > \ > https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz Somehow I messed up my working files (*). The attached (simpler) d/watch seems to work. Could you please test it? Cheers, -- Santiago (*) I need to stop working late. version=4 opts="uversionmangle=s/v/./" \ https://github.com/Tieske/binaryheap.lua/tags .*/version_?(\d\S*)\.tar\.gz signature.asc Description: PGP signature
Bug#937051: mininet: Python2 removal in sid/bullseye
On Sat, 25 Apr 2020 14:08:39 +0200 Tomasz Buchert wrote: > Thanks, > upstream claims that mininet is python3-compatible in master [1]. > > I'll try to make the package stop using python2. > > [1] https://github.com/mininet/mininet/issues/898 Hi Tomasz, Any news about removing python2 from mininet? Cheers! -- Santiago signature.asc Description: PGP signature
Bug#974080: ITP: lua-binaryheap -- Binary heap implementation in lua
El 09/11/20 a las 13:31, Jakub Ružička escribió: > Package: wnpp > Severity: wishlist > Owner: Jakub Ružička > > * Package name: lua-binaryheap > Version : 0.4 > Upstream Author : Thijs Schreijer > * URL : https://github.com/Tieske/binaryheap.lua > * License : MIT > Programming Lang: lua > Description : binary heap implementation in lua > > binaryheap.lua is a binary heap (binary tree) implementaion in lua. > ... Jakub, thanks for packaging lua-binaryheap. Two lintian "major" comments from your current repo: W: lua-binaryheap source: ancient-standards-version 3.9.8 (released 2016-04-06) (current is 4.5.0) W: lua-binaryheap source: package-uses-deprecated-debhelper-compat-version 9 Do you have any reason for that standards-version and debhelper-compat-version? These other lintian minor warnings could be easily fixed: I: lua-binaryheap: capitalization-error-in-description lua Lua I: lua-binaryheap source: debian-watch-file-is-missing I: lua-binaryheap source: vcs-field-not-canonical Vcs-Git Could you please consider them? Thanks, -- Santiago signature.asc Description: PGP signature
Bug#958665: lua-http is missing lua-binaryheap dependency
Control: block -1 by 974080 On Fri, 24 Apr 2020 10:57:40 +0200 Tomas Krizek wrote: > Package: lua-http > Version: 0.3-1 > > Upstream lua-http has a dependency on binaryheap >= 0.3. > See https://github.com/daurnimator/lua-http#dependencies > > The debian package lua-http is missing this dependency, resulting in > error such as: > error: /usr/share/lua/5.1/http/cookie.lua:7: module 'binaryheap' not found > > signature.asc Description: PGP signature
Bug#958665: lua-http is missing lua-binaryheap dependency
Control: tag -1 pending On Fri, 24 Apr 2020 10:57:40 +0200 Tomas Krizek wrote: > Package: lua-http > Version: 0.3-1 > > Upstream lua-http has a dependency on binaryheap >= 0.3. > See https://github.com/daurnimator/lua-http#dependencies > > The debian package lua-http is missing this dependency, resulting in > error such as: > error: /usr/share/lua/5.1/http/cookie.lua:7: module 'binaryheap' not found > > Tomas, Thanks for reporting this. Sorry for the late answer, somehow I cannot find any trace on my emails… And thanks to Jakub Ružička who has packaged lua-binaryheap. Since lua-binaryheap has reached the archive, I plan to release today. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#937051: mininet: Python2 removal in sid/bullseye
On Wed, 18 Nov 2020 16:09:22 +0100 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= wrote: > On Sat, 25 Apr 2020 14:08:39 +0200 Tomasz Buchert wrote: > > Thanks, > > upstream claims that mininet is python3-compatible in master [1]. > > > > I'll try to make the package stop using python2. > > > > [1] https://github.com/mininet/mininet/issues/898 > > Hi Tomasz, > > Any news about removing python2 from mininet? > I had prepared a package based on 2.3d6 here: https://salsa.debian.org/santiago/mininet/-/tree/debian/pre-2.3.0d6 It runs by python3, and a simple pingall works. If nobody objects, I'm willing to NMU it soon. -- Santiago signature.asc Description: PGP signature
Bug#977101: knot: duplicate zones, segfault when generating new DNSSEC keys
On Thu, 21 Jan 2021 13:28:58 +0800 Gedalya wrote: > Hi Jan, > > For some reason I didn't get your message via email, but saw it when looking > at the Debian bug. A message sent to n...@bugs.debian.org is forwarded to the maintainer, but not to the submitter. For a message to be forwarded to the submitter, the author needs to use the address nnn-submit...@bugs.debian.org, or CC the submitter. See "Followup messages" in https://www.debian.org/Bugs/Developer > > I see a fix for this in 3.0.4 (89c9a233). When that's packaged I'll try to > confirm that this is fixed. > > Thank you! 3.0.4 is now in NEW. I've also uploaded a release to https://people.debian.org/~santiago/debian/santiago-unstable/ Could you try it please? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#989370: Reassinging #989370 to ifenslave: In bonding network configuration, hwaddress crashes networking service, fails to restart
Control: reassign 989370 ifenslave El 04/06/21 a las 14:55, Chris Hofstaedtler escribió: > Control: reopen 989370 > Control: reassign 989370 ifupdown > > Reassigning to ifupdown, which is the package having the > /etc/network/interfaces conffile. > > Chris The bonding functionality is handled by the ifenslave package. Reassinging it accordingly. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#990407: Acknowledgement (RFS: nftfw/0.9.4-1 [ITP] -- nftables firewall builder for Debian)
Hello Peter, El 01/07/21 a las 08:41, Peter Collinson escribió: > I’ve revised the uploaded package because it failed to build on sbuild. > > It needed a dependency on netbase, and a change to a test script which just > happened to work on Python 3.7 but failed on Python3.9. > > > Regards > -- > Peter Collinson Thanks for your work developing nftfw and packaging it for debian! Here you have some comments: * you have a master branch (that includes the debian/ dir). It is a common practice to have the debian packaging branch separated from the upstream code (including the tarball). See the candidate DEP-14. https://dep-team.pages.debian.net/deps/dep14/ * the watch file stores the downloaded upstream tarball as: nftfw_0.9.4.orig.tar.gz -> '-0.9.4.tar.gz' '-0.9.4.tar.gz' you can try with `uscan --verbose --download --download-current-version` Also, the .orig.tar.gz I can download with your .dsc is different from the .orig.tar.gz I download using uscan. It seems you have removed the debian/ dir. * do you have any reason for not using salsa? (it is not mandatory, I am just curious). Keep in mind that using Salsa would make it easier to make use of common Debian tools, such as Salsa CI: https://salsa.debian.org/salsa-ci-team/pipeline/ * building the package modifies debian/postinst (by the make_etc_lists). Could you please explain what is the goal of make_etc_lists? Why do you need it? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#987594: [INTL:es] Spanish translation of the debconf template
Control: tags -1 + pending El 26/04/21 a las 09:48, Camaleón escribió: > Package: knot-resolver > Severity: wishlist > Tags: patch l10n > > Hello, > > You can find enclosed the Spanish translation template to be uploaded > with the latest package build. > > Greetings, Thanks, I've pushed it to salsa. -- S signature.asc Description: PGP signature
Bug#987724: RFS: opendnssec/1:2.1.7-2 -- OpenDNSSEC suite
El 29/04/21 a las 11:07, Mathieu Mirmont escribió: > On Thu, Apr 29, 2021 at 12:44:39AM +0200, Santiago R.R. wrote: > > > > I'll take a look at and upload it, unless someone is faster than me. > > Someone else did already, but thanks anyway! No problem. I was not able to handle it until late this morning. It's nice that you found another sponsor :-) > > > > opendnssec (1:2.1.7-2) unstable; urgency=medium > > > . > > > * po/pt_BR.po: Add Brazilian translation (Closes: #986890) > > > > Isn't Brazilian Portuguese a more accurate name? > > Hmm yeah indeed that is the actual name. It's already uploaded though :/ Yeah. Without telling you to do that, you could "fix" that changelog entry in a future release. signature.asc Description: PGP signature
Bug#981949: offlineimap3: broken when handling passwd input
El 06/02/21 a las 16:46, Sudip Mukherjee escribió: > On Sat, Feb 6, 2021 at 4:11 PM Sudip Mukherjee > wrote: > > > > Hi Santiago, > > > > On Fri, Feb 05, 2021 at 11:27:46AM +0100, Santiago Ruano Rincón wrote: > > > Package: offlineimap3 > > > Version: 0.0~git20210105.00d395b+dfsg-2 > > > Severity: important > > > > > > Dear offlineimap3 maintainer, > > > > > > After the recent upgrade, I cannot input my password to sync mail. > > > offlineimap3 fails with: > > > > > > sequence item 2: expected str instance, bytes found > > > > Thanks for both the report, however I am unable to reproduce the issues in > > my setup. Can you please paste your offlineimaprc file after removing the > > sensitive information. > > I spoke too soon. ;( > From your trace it seems you are using Curses and I do see problems if > I mention 'blinkenlights' while running offlineimap. > Your offlineimaprc will help, but also can you please comment the "ui > = " in your offlineimaprc and check if you still get both these > issues. Indeed, I can input my password if I comment out ui = Blinkenlights. offlineimaprc attached. Thanks! However, I am unable to reproduce #981960. I have an account that I still cannot sync, even when the password doesn't have any dot anymore. I'll try to dig further. Cheers, -- Santiago [general] accounts = Example ui = Blinkenlights metadata = ~/.var/offlineimap ignore-readonly = no maxsyncaccounts = 3 [mbnames] enabled = yes filename = ~/.var/offlineimap/mailboxes header = "mailboxes " peritem = "+%(accountname)s/%(foldername)s" #sep = '\n' sep = ' ' footer = '\n' [Account Example] localrepository = Example-Local remoterepository = Example-Remote autorefresh = 15 quick = 16 [Repository Example-Local] type = Maildir localfolders = ~/Mail/Example/ [Repository Example-Remote] type = IMAP ssl=yes sslcacertfile = /etc/ssl/certs/ca-certificates.crt remotehost = imap.example.net remoteport = 993 remoteuser = myuser signature.asc Description: PGP signature
Bug#981949: offlineimap3: broken when handling passwd input
Package: offlineimap3
Version: 0.0~git20210105.00d395b+dfsg-2
Severity: important
Dear offlineimap3 maintainer,
After the recent upgrade, I cannot input my password to sync mail.
offlineimap3 fails with:
sequence item 2: expected str instance, bytes found
This is a full log using a dummy account I created just to reproduce the
bug:
2021-02-05 11:14:15 INFO: OfflineImap 7.3.0 starting...
Python: 3.9.1 Platform: linux
Args: /usr/bin/offlineimap -a Example -d ALL -l /tmp/offlineimap.log
2021-02-05 11:14:15 INFO: OfflineIMAP 7.3.0
Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)
2021-02-05 11:14:15 INFO: imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i 8 Dec
2020
2021-02-05 11:14:15 DEBUG: Now debugging for imap: IMAP protocol debugging
2021-02-05 11:14:15 DEBUG: Now debugging for maildir: Maildir repository
debugging
2021-02-05 11:14:15 DEBUG: Now debugging for thread: Threading debugging
2021-02-05 11:14:15 DEBUG: Now debugging for : Other offlineimap related sync
messages
2021-02-05 11:14:15 DEBUG: [thread]: Register new thread 'Account sync Example'
(account 'Example')
2021-02-05 11:14:15 DEBUG: [imap]: Using authentication mechanisms ['GSSAPI',
'XOAUTH2', 'CRAM-MD5', 'PLAIN', 'LOGIN']
2021-02-05 11:14:15 DEBUG: [maildir]: MaildirRepository initialized, sep is '.'
2021-02-05 11:14:15 INFO: *** Processing account Example
2021-02-05 11:14:15 INFO: Establishing connection to imap.example.net:993
(LPB-Remote)
2021-02-05 11:14:15 DEBUG: [imap]: LPB-Remote: level 'tls_compat', version
'None'
2021-02-05 11:14:15 DEBUG: [imap]: 14:15.82 Account sync Example imaplib2
version 3.05
2021-02-05 11:14:15 DEBUG: [imap]: 14:15.82 Account sync Example imaplib2
debug level 5, buffer level 3
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.05 Account sync Example connected to
imap.example.net on port 993
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.05 imap.example.net writer starting
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.05 imap.example.net reader starting
using poll
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.06 Account sync Example
_request_push(continuation, welcome, {}) = b'CJOD0'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.06 Account sync Example
welcome:b'CJOD0'.ready.wait
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.09 imap.example.net reader poll =>
[(5, 1)]
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.10 imap.example.net reader rcvd 18
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.10 imap.example.net reader < b'* OK
IMAP4 ready\r\n'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.15 imap.example.net handler starting
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 imap.example.net handler
_put_response(b'* OK IMAP4 ready')
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 imap.example.net handler
untagged_responses[OK] 0 += ["b'IMAP4 ready'"]
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 imap.example.net handler
_request_pop(continuation, (False, b'* OK IMAP4 ready')) [0] = b'CJOD0'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 imap.example.net handler
welcome:b'CJOD0'.ready.set
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example
_get_untagged_response(OK) => [b'IMAP4 ready']
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example state =>
NONAUTH
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example [async]
CAPABILITY ()
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example
state_change_pending.acquire
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example
state_change_pending.release
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 imap.example.net handler
state_change_free.set
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example
_request_push(b'CJOD1', CAPABILITY, {}) = b'CJOD1'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example data=b'CJOD1
CAPABILITY'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 Account sync Example
CAPABILITY:b'CJOD1'.ready.wait
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.16 imap.example.net writer > b'CJOD1
CAPABILITY\r\n'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.21 imap.example.net reader poll =>
[(5, 1)]
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.21 imap.example.net reader rcvd 63
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.21 imap.example.net reader < b'*
CAPABILITY IMAP4rev1 UIDPLUS AUTH=PLAIN\r\n'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.21 imap.example.net reader < b'CJOD1
OK completed\r\n'
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.22 imap.example.net handler
_put_response(b'* CAPABILITY IMAP4rev1 UIDPLUS AUTH=PLAIN')
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.22 imap.example.net handler
untagged_responses[CAPABILITY] 0 += ["b'IMAP4rev1 UIDPLUS AUTH=PLAIN'"]
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.22 imap.example.net handler
_put_response(b'CJOD1 OK completed')
2021-02-05 11:14:16 DEBUG: [imap]: 14:16.22 imap.example.net handler
_request_pop(b'CJOD1', ('OK', [b'completed'])) [0] = b'CJOD1'
2021-02-05 11:14:16 DEBUG: [imap]:
Bug#981960: offlineimap3: doesn't like passwords with dots
Package: offlineimap3
Version: 0.0~git20210105.00d395b+dfsg-2
Severity: important
Dear offlineimap3 maintainer,
unintentionally I suppose, offlineimap3 doesn't like passwords that
include dots. This is a log of syncing attempt:
2021-02-05 12:02:10 INFO: OfflineImap 7.3.0 starting...
Python: 3.9.1 Platform: linux
Args: /usr/bin/offlineimap -a Example -d ALL -l /tmp/offlineimap-dot.log
2021-02-05 12:02:10 INFO: OfflineIMAP 7.3.0
Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception)
2021-02-05 12:02:10 INFO: imaplib2 v3.05, Python v3.9.1+, OpenSSL 1.1.1i 8 Dec
2020
2021-02-05 12:02:10 DEBUG: Now debugging for imap: IMAP protocol debugging
2021-02-05 12:02:10 DEBUG: Now debugging for maildir: Maildir repository
debugging
2021-02-05 12:02:10 DEBUG: Now debugging for thread: Threading debugging
2021-02-05 12:02:10 DEBUG: Now debugging for : Other offlineimap related sync
messages
2021-02-05 12:02:10 DEBUG: [thread]: Register new thread 'Account sync Example'
(account 'Example')
2021-02-05 12:02:10 DEBUG: [imap]: Using authentication mechanisms ['GSSAPI',
'XOAUTH2', 'CRAM-MD5', 'PLAIN', 'LOGIN']
2021-02-05 12:02:10 DEBUG: [maildir]: MaildirRepository initialized, sep is '.'
2021-02-05 12:02:10 INFO: *** Processing account Example
2021-02-05 12:02:10 INFO: Establishing connection to imap.example.net:993
(LPB-Remote)
2021-02-05 12:02:10 DEBUG: [imap]: LPB-Remote: level 'tls_compat', version
'None'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.32 Account sync Example imaplib2
version 3.05
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.32 Account sync Example imaplib2
debug level 5, buffer level 3
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.55 Account sync Example connected to
imap.example.net on port 993
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.55 imap.example.net writer starting
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.56 imap.example.net reader starting
using poll
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.56 Account sync Example
_request_push(continuation, welcome, {}) = b'LPPG0'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.56 Account sync Example
welcome:b'LPPG0'.ready.wait
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.60 imap.example.net reader poll =>
[(5, 1)]
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.60 imap.example.net reader rcvd 18
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.60 imap.example.net reader < b'* OK
IMAP4 ready\r\n'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 imap.example.net handler starting
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 imap.example.net handler
_put_response(b'* OK IMAP4 ready')
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 imap.example.net handler
untagged_responses[OK] 0 += ["b'IMAP4 ready'"]
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 imap.example.net handler
_request_pop(continuation, (False, b'* OK IMAP4 ready')) [0] = b'LPPG0'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 imap.example.net handler
welcome:b'LPPG0'.ready.set
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example
_get_untagged_response(OK) => [b'IMAP4 ready']
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example state =>
NONAUTH
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 imap.example.net handler
state_change_free.set
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example [async]
CAPABILITY ()
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example
state_change_pending.acquire
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example
state_change_pending.release
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example
_request_push(b'LPPG1', CAPABILITY, {}) = b'LPPG1'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.66 Account sync Example data=b'LPPG1
CAPABILITY'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.67 Account sync Example
CAPABILITY:b'LPPG1'.ready.wait
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.67 imap.example.net writer > b'LPPG1
CAPABILITY\r\n'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.71 imap.example.net reader poll =>
[(5, 1)]
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net reader rcvd 63
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net reader < b'*
CAPABILITY IMAP4rev1 UIDPLUS AUTH=PLAIN\r\n'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net reader < b'LPPG1
OK completed\r\n'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net handler
_put_response(b'* CAPABILITY IMAP4rev1 UIDPLUS AUTH=PLAIN')
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net handler
untagged_responses[CAPABILITY] 0 += ["b'IMAP4rev1 UIDPLUS AUTH=PLAIN'"]
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net handler
_put_response(b'LPPG1 OK completed')
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net handler
_request_pop(b'LPPG1', ('OK', [b'completed'])) [0] = b'LPPG1'
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72 imap.example.net handler
CAPABILITY:b'LPPG1'.ready.set
2021-02-05 12:02:10 DEBUG: [imap]: 02:10.72
Bug#982329: knot-resolver: [INTL:pt] Portuguese translation - debconf messages
Control: tags -1 + pending El 08/02/21 a las 22:02, Américo Monteiro escribió: > Package: knot-resolver > Version: 5.2.1-1 > Tags: l10n, patch > Severity: wishlist > > Updated Portuguese translation for knot-resolver's debconf messages > Translator: Américo Monteiro > Feel free to use it. ... Thanks for your translation, just pushed it into the salsa repo. -- Santiago signature.asc Description: PGP signature
Bug#984800: cgroup-tools: does not work in cgroup2 / unified hierarchy
Control: severity -1 important Control: forwarded -1 https://github.com/mininet/mininet/issues/1051 Lowering the severity, #959022 has been "downgraded" to important. signature.asc Description: PGP signature
Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy
Dear Release Team, Could you please take a look at https://bugs.debian.org/959022 Would you agree to tag it bullseye-ignore, as pointed out by zigo here below (and proposed also by mbiebl on irc)? On Tue, 23 Mar 2021 14:15:41 +0100 Thomas Goirand wrote: > Hi, > > I would agree to do nothing and tag this bug as bullseye-ignore, and > document the fact that users need to manually configure/mount cgroup1 > stuff. It's IMO perfectly fine to require some level of configuration to > use a piece of software. > > Though in no way, removing cgroup-tools from bullseye is a good idea. > Some software (like cinder) need it to configure I/O bandwidth. > > Cheers, > > Thomas Goirand (zigo) > > Thanks, -- Santiago signature.asc Description: PGP signature
Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy
Control: forwarded -1 https://github.com/libcgroup/libcgroup/issues/12 Control: tags -1 + upstream On Tue, 28 Apr 2020 15:22:35 +0900 Ryutaroh Matsumoto wrote: > Package: cgroup-tools > Version: 0.41-10 > Severity: normal > Tags: wontfix > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: cgroupv2 > > Dear Maintainer, > > It does not work in the cgroup2 / unified hierarchy. It gives > > # lssubsys > # lscgroup > cgroups can't be listed: Cgroup is not mounted > > Best regards, Ryutaroh Matsumoto > > > -- Package-specific info: > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), > LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages cgroup-tools depends on: > ii libc6 2.30-4 > ii libcgroup1 0.41-10 > > cgroup-tools recommends no packages. > > cgroup-tools suggests no packages. > > -- no debconf information > > signature.asc Description: PGP signature
Bug#892058: Your Debian key is expiring
Hello Felix, El 23/03/21 a las 12:47, Felix Lechner escribió: ... > Please keep in mind that the Debian folks in charge of the keyring > update it only once a month. That usually happens on the 24th of each > month. It it just a few days away. > > If you like this service, please leave a favorable comment here [2]. > Thank you! Extending my key's expiring date was in my ToDo list (this time). I indeed like this service. I think gpg key should have expiring dates, but that implies that Debian contributors should remember to renew them on time. This service helps to avoid being blocked to make our debian duties. Thanks, -- S signature.asc Description: PGP signature
Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy
On Wed, 10 Mar 2021 17:11:49 +0100 Santiago Ruano =?iso-8859-1?Q?Rinc=F3n?= wrote: > On Tue, 28 Apr 2020 15:22:35 +0900 Ryutaroh Matsumoto > wrote: > > Package: cgroup-tools > > Version: 0.41-10 > > Severity: normal > > Tags: wontfix > > User: pkg-systemd-maintain...@lists.alioth.debian.org > > Usertags: cgroupv2 > > > > Dear Maintainer, > > > > It does not work in the cgroup2 / unified hierarchy. It gives > > > > # lssubsys > > # lscgroup > > cgroups can't be listed: Cgroup is not mounted > > > > Best regards, Ryutaroh Matsumoto > > Hi there, > > In this other upstream repo, there is some progress relating > cgroupv2-support: > https://github.com/libcgroup/libcgroup > > i.e.: > https://github.com/libcgroup/libcgroup/issues/12 > > On my Debian sid machine, I can run these simple tests from compile source > (commit 6f387cbc5f4fb8d43371a317356648d1c561efda): > > sudo ./src/tools/cgcreate -g io:a/b/c/d > sudo ./src/tools/cgget -g io:a/b/c/d > a/b/c/d: > io.pressure: some avg10=0.00 avg60=0.00 avg300=0.00 total=0 > full avg10=0.00 avg60=0.00 avg300=0.00 total=0 > io.max: > io.weight: default 100 > io.stat: > > sudo ./src/tools/lscgroup > cpuset,cpu,io,memory,hugetlb,pids,rdma:/ > cpuset,cpu,io,memory,hugetlb,pids,rdma:/sys-fs-fuse-connections.mount > cpuset,cpu,io,memory,hugetlb,pids,rdma:/sys-kernel-config.mount > cpuset,cpu,io,memory,hugetlb,pids,rdma:/sys-kernel-debug.mount > cpuset,cpu,io,memory,hugetlb,pids,rdma:/a > ... > > As of today, there are 9 of 12 applications supporting cgroup2. > > I'll take a look if I could package it. … Dear maintainers of the packages that would be removed by the removal of libcgroup, I am taking a look at the above mentioned new version of libcgroup, that partially supports cgroup2. Would it make sense for your packages to have in Debian that version of libcgroup (the current git HEAD)? You can find a *draft* package here: https://people.debian.org/~santiago/debian/santiago-unstable/ or using the repo: deb https://people.debian.org/~santiago/debian santiago-unstable/ deb-src https://people.debian.org/~santiago/debian santiago-unstable/ Cheers, -- S signature.asc Description: PGP signature
Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy
Hi Michael, El 17/03/21 a las 15:01, Michael Biebl escribió: > Hi Santiago > > On Fri, 12 Mar 2021 21:33:05 +0100 Santiago Ruano =?iso-8859- > 1?Q?Rinc=F3n?= wrote: > > > Dear maintainers of the packages that would be removed by the removal > of > > libcgroup, > > > Checking reverse dependencies... > # Broken Depends: > cinder: cinder-common → cgroup-tools > clsync: clsync → libcgroup1 > condor: htcondor → libcgroup1 > mininet: mininet → cgroup-tools > nova: nova-compute → cgroup-tools > vzctl: vzctl [amd64 i386] → libcgroup1 > > # Broken Build-Depends: > clsync: libcgroup-dev > condor: libcgroup-dev > vzctl: libcgroup-dev > > > > > I am taking a look at the above mentioned new version of libcgroup, > that > > partially supports cgroup2. Would it make sense for your packages to > > have in Debian that version of libcgroup (the current git HEAD)? > > While I appreciate the effort, I feel a bit uneasy about shipping > something half-baked like this. Does such an updated libcgroup package > actually ensure, that rdeps continue to work? Yeah, answering that was actually the main purpose of my question! > > Maybe the packages above need to check, whether they actually need the > libcgroup / cgroup-tools dependency. Yes, indeed. I have been only able to take a look at mininet, that I use personally a little bit. In a basic use as mine, mininet works (so I could drop the dependency). But it is broken if you need to do stuff that relies on cgroups: e.g. running `python3 /usr/share/doc/mininet/examples/limit.py` fails: Traceback (most recent call last): File "/usr/share/doc/mininet/examples/limit.py", line 61, in limit() File "/usr/share/doc/mininet/examples/limit.py", line 37, in limit net = Mininet( topo=myTopo, intf=intf, host=host, waitConnected=True ) File "/usr/lib/python3/dist-packages/mininet/net.py", line 178, in __init__ self.build() File "/usr/lib/python3/dist-packages/mininet/net.py", line 508, in build self.buildFromTopo( self.topo ) File "/usr/lib/python3/dist-packages/mininet/net.py", line 479, in buildFromTopo self.addHost( hostName, **topo.nodeInfo( hostName ) ) File "/usr/lib/python3/dist-packages/mininet/net.py", line 232, in addHost h = cls( name, **defaults ) File "/usr/lib/python3/dist-packages/mininet/util.py", line 587, in customized return cls( *args, **kwargs ) File "/usr/lib/python3/dist-packages/mininet/node.py", line 692, in __init__ CPULimitedHost.init() File "/usr/lib/python3/dist-packages/mininet/node.py", line 871, in init mountCgroups() File "/usr/lib/python3/dist-packages/mininet/util.py", line 548, in mountCgroups raise Exception( "cgroups not mounted on " + cgdir ) Exception: cgroups not mounted on /sys/fs/cgroup mininet code that relies on cgroupv1, e.g.: https://sources.debian.org/src/mininet/2.3.0-1/mininet/node.py/#L695 https://sources.debian.org/src/mininet/2.3.0-1/mininet/util.py/#L541 should have to be patched to be able to run with cgroupv2. A priori, the upgraded cgroup-tools would make that easier. I have no idea about cinder and nova, I let the maintainers give their input. > > If this was broken for such a long time with noone noticing, maybe > dropping that dependency is the better alternative. At least the > cgroup-tools dependency looks like something that could be dropped. Maybe. It is maybe difficult to notice since some tools don't have a significant number of users that run testing or unstable (that's my case with mininet). Cheers, -- Santiago signature.asc Description: PGP signature
Bug#959022: cgroup-tools: does not work in cgroup2 / unified hierarchy
On Tue, 28 Apr 2020 15:22:35 +0900 Ryutaroh Matsumoto wrote: > Package: cgroup-tools > Version: 0.41-10 > Severity: normal > Tags: wontfix > User: pkg-systemd-maintain...@lists.alioth.debian.org > Usertags: cgroupv2 > > Dear Maintainer, > > It does not work in the cgroup2 / unified hierarchy. It gives > > # lssubsys > # lscgroup > cgroups can't be listed: Cgroup is not mounted > > Best regards, Ryutaroh Matsumoto Hi there, In this other upstream repo, there is some progress relating cgroupv2-support: https://github.com/libcgroup/libcgroup i.e.: https://github.com/libcgroup/libcgroup/issues/12 On my Debian sid machine, I can run these simple tests from compile source (commit 6f387cbc5f4fb8d43371a317356648d1c561efda): sudo ./src/tools/cgcreate -g io:a/b/c/d sudo ./src/tools/cgget -g io:a/b/c/d a/b/c/d: io.pressure: some avg10=0.00 avg60=0.00 avg300=0.00 total=0 full avg10=0.00 avg60=0.00 avg300=0.00 total=0 io.max: io.weight: default 100 io.stat: sudo ./src/tools/lscgroup cpuset,cpu,io,memory,hugetlb,pids,rdma:/ cpuset,cpu,io,memory,hugetlb,pids,rdma:/sys-fs-fuse-connections.mount cpuset,cpu,io,memory,hugetlb,pids,rdma:/sys-kernel-config.mount cpuset,cpu,io,memory,hugetlb,pids,rdma:/sys-kernel-debug.mount cpuset,cpu,io,memory,hugetlb,pids,rdma:/a ... As of today, there are 9 of 12 applications supporting cgroup2. I'll take a look if I could package it. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#984800: Remove dependency on cgroup-tools
Source: mininet Version: 2.3.0-1 Severity: serious Tags: upstream Hi Tomasz, cgroup-tools (src:libcgroup) is now tagged to be autoremoved from testing due to https://bugs.debian.org/959022 mininet should have to get rid of any cgroup-tools/cgroup1-related stuff. Cheers, -- Santiago -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information signature.asc Description: PGP signature
Bug#823161: RFA: libcgroup -- library and utilities for using the Linux Control Group mechanism
Control: retitle -1 ITA: libcgroup -- library and utilities for using the Linux Control Group mechanism Control: owner -1 ! On Sun, 1 May 2016 18:35:00 +0200 Christian Kastner wrote: > Package: wnpp > Severity: normal > > I request an adopter for the libcgroup package. > > It provides a library, a PAM module, and executables, all used for > manipulating, controlling, administering, and monitoring of the Control > Groups mechanism of the Linux kernel. > > Apart from the 3 open bugs, the package is in good shape overall. > > The plan which originally motivated me to take over this package never > materialized, and hence I have lost interest in this package. > > I can take care of libcgroup, at least while I continue using mininet (which is a reverse dependency). -- S signature.asc Description: PGP signature
Bug#982970: offlineimap3: broken folderincludes config option
El 17/02/21 a las 18:51, Sudip Mukherjee escribió: > Hi Santiago, > > On Wed, Feb 17, 2021 at 2:30 PM Santiago Ruano Rincón > wrote: > > > > Package: offlineimap3 > > Version: 0.0~git20210105.00d395b+dfsg-3 > > Severity: normal > > Tags: upstream > > > > Dear Sudip, > > > > offlineimap3 is not able to handle the folderincludes config, that > > worked with offlineimap. I got this when trying to sync (tested with two > > different accounts): > > > > 'str' object has no attribute 'decode' > > Can you please test with the PR at > https://github.com/OfflineIMAP/offlineimap3/pull/47/ and check if it > fixes your issue.. > I could reproduce the problem in my setup and the above PR fixes the > problem for me. I have not tested enough to know if it breaks > something else. It seems to work, thanks! -- Santiago signature.asc Description: PGP signature
Bug#981949: offlineimap3: broken when handling passwd input
Control: retitle 981949 offlineimap3: broken passwd input via Curses and Blinkenlights Hi Sudip, El 16/02/21 a las 23:33, Sudip Mukherjee escribió: > On Mon, Feb 8, 2021 at 3:27 PM Sudip Mukherjee > wrote: > > > > On Mon, Feb 8, 2021 at 3:12 PM Santiago Ruano Rincón > > wrote: > > > > > > El 06/02/21 a las 16:46, Sudip Mukherjee escribió: > > > > On Sat, Feb 6, 2021 at 4:11 PM Sudip Mukherjee > > > > wrote: > > > > > > > > > > > > From your trace it seems you are using Curses and I do see problems if > > > > I mention 'blinkenlights' while running offlineimap. > > > > Your offlineimaprc will help, but also can you please comment the "ui > > > > = " in your offlineimaprc and check if you still get both these > > > > issues. > > > > > > Indeed, I can input my password if I comment out ui = Blinkenlights. > > > offlineimaprc attached. Thanks! > > Can you please try the attached patch and confirm if it fixes both > your issues with blinkenlights.. Thanks, it fixes #981949! #981960 is still present, but the dots in the password are not in fault. I'll try to send you a new log. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#982970: offlineimap3: broken folderincludes config option
Package: offlineimap3
Version: 0.0~git20210105.00d395b+dfsg-3
Severity: normal
Tags: upstream
Dear Sudip,
offlineimap3 is not able to handle the folderincludes config, that
worked with offlineimap. I got this when trying to sync (tested with two
different accounts):
'str' object has no attribute 'decode'
Traceback:
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 298, in
syncrunner
self.__sync()
File "/usr/share/offlineimap3/offlineimap/accounts.py", line 374, in __sync
remoterepos.getfolders()
File "/usr/share/offlineimap3/offlineimap/repository/IMAP.py", line 695, in
getfolders
imapobj.select(imaputil.utf8_IMAP(foldername),
File "/usr/share/offlineimap3/offlineimap/imaputil.py", line 360, in utf8_IMAP
return foldername.decode('utf-8').encode('imap4-utf-7')
Attached a sample config. Tell me if you need a full log.
Cheers,
-- Santiago
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages offlineimap3 depends on:
ii python3 3.9.1-1
ii python3-distro1.5.0-1
ii python3-imaplib2 2.57-5.2
offlineimap3 recommends no packages.
offlineimap3 suggests no packages.
-- no debconf information
[general]
accounts = Example
ui = Blinkenlights
metadata = ~/.var/offlineimap
ignore-readonly = no
maxsyncaccounts = 3
[mbnames]
enabled = yes
filename = ~/.var/offlineimap/mailboxes
header = "mailboxes "
peritem = "+%(accountname)s/%(foldername)s"
#sep = '\n'
sep = ' '
footer = '\n'
[Account Example]
localrepository = Example-Local
remoterepository = Example-Remote
autorefresh = 15
quick = 16
[Repository Example-Local]
type = Maildir
localfolders = ~/Mail/Example/
[Repository Example-Remote]
type = IMAP
ssl=yes
sslcacertfile = /etc/ssl/certs/ca-certificates.crt
remotehost = imap.example.net
remoteport = 993
remoteuser = myuser
folderincludes = ['debian']
signature.asc
Description: PGP signature
Bug#992401: debianutils: warning message: /usr/bin/which: this version of 'which' is deprecated and should not be used.
On Wed, 18 Aug 2021 09:34:17 +0200 Salman Mohammadi wrote: > > Package: debianutils > Version: 5.0.1-1 > Severity: normal > X-Debbugs-Cc: none, sal...@smoha.org, Salman Mohammadi > > Dear Maintainer(s), > > Running `which` in the commandline throws the following warning message: > > > /usr/bin/which: this version of 'which' is deprecated and should > not be used. > > > Could it be due to this commit? (which: punctuation fix) > > https://salsa.debian.org/debian/debianutils/-/commit/a92d15b24071cf2105c85daf4d27326dd6443732 > ... Rather to this one (Deprecate which): https://salsa.debian.org/debian/debianutils/-/commit/3a8dd10b4502f7bae8fc6973c13ce23fc9da7efb IMHO, it's a pity to deprecate it, and I am sure this change will break quite some scripts. E.g.: https://salsa.debian.org/dns-team/knot-dns/-/jobs/1828299#L625 Is it really mandatory to remove which? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#975729: isc-dhcp: Please upgrade to latest upstream release 4.4.2
Control: retitle -1 isc-dhcp: Please upgrade to latest upstream release 4.4.2-P1 On Wed, 25 Nov 2020 18:31:41 +0100 Fabio Pedretti wrote: > Source: isc-dhcp > Version: 4.4.1-2.1 > Severity: wishlist > X-Debbugs-Cc: pedretti.fa...@gmail.com > > Dear Maintainer, > > please upgrade to latest upstream release 4.4.2, which fixes some issues > and add some minor features. Release notes: > https://downloads.isc.org/isc/dhcp/4.4.2/dhcp-4.4.2-RELNOTES > > Thanks. Hi, 4.4.2 was released on 22 January 2020, followed by a security release (4.4.2-P1) last May: http://ftp.isc.org/isc/dhcp/4.4.2-P1/dhcp-4.4.2-P1-RELNOTES Do you have any news about upgrading the package to the latest release? Do you need any help? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#991463: fixed in knot-resolver 5.4.1-1
El 26/08/21 a las 14:45, Jakub Ružička escribió: > > - Includes fix for CVE-2021-40083 (Closes: #991463) > > I've used this magic syntax found throughout the changelog and it closed > the bug upon experimental upload, which isn't what I expected. Please > reopen as needed, I'm not yet familiar with handling bugs wrt different > Debian branches. > Why would you like to reopen the bug? The BTS knows it is still to be fixed in unstable. Take a look at the image at the top right of the bug report page: https://bugs.debian.org/cgi-bin/version.cgi?absolute=0;found=knot-resolver%2F5.3.1-1;info=1;fixed=knot-resolver%2F5.4.1-1;collapse=1;package=knot-resolver > Regardless, experimental knot-resolver-5.4.1-1 built against > experimental knot-3.1.1-3 so I'll try to proceed with the transition > which should fix the bug for sid. Awesome, thanks! > After that I plan to cherry-pick the fix for next bullseye-point release. Did you have any feedback from the security team? , -- S signature.asc Description: PGP signature
Bug#984800: Remove dependency on cgroup-tools
Control: title -1 mininet: support for cgroup v2 El 08/03/21 a las 15:30, Santiago Ruano Rincón escribió: > Source: mininet > Version: 2.3.0-1 > Severity: serious > Tags: upstream > > Hi Tomasz, > > cgroup-tools (src:libcgroup) is now tagged to be autoremoved from > testing due to https://bugs.debian.org/959022 > > mininet should have to get rid of any cgroup-tools/cgroup1-related > stuff. Now that libcgroup 2.0 has landed in unstable, mininet could use it to support cgroup2. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#993371: Support for cgroups v2
Source: ansible-runner Version: 1.4.6-1 Severity: normal Tags: upstream User: pkg-systemd-maintain...@lists.alioth.debian.org Usertags: cgroupv2 Dear maintainer, Since bullseye, the cgroups v1 filesystem is not mounted by default, and then ansible-runner needs to adapt some code to support cgroups v2. It includes a least this call to cgcreate (from the cgroup-tools package) https://sources.debian.org/src/ansible-runner/1.4.6-1/ansible_runner/runner.py/?hl=157#L157 to make use of the cgroups v1's cpuacct controller, that has been replaced in cgroups v2 by cpu. ansible-runner needs to call cgcreate with the correct arguments, according to the cgroup version mounted in the system. See cgroups(7) or the kernel admin-guide: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html Cheers, -- Santiago -- System Information: Debian Release: bookworm/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#993311: Support for cgroup v2 via cgroup-tools
El 31/08/21 a las 14:45, Thomas Goirand escribió: > Hi Santiago, > > Thanks for this bug report, I'll be working on it. Thanks! > > On 8/30/21 5:19 PM, Santiago Ruano Rincón wrote: > > To know if cgroup v2 is supported, one way is to > > `grep cgroup2 /proc/mounts` > > I am really unsure about this. On Bullseye, for example, we do have > cgroup2 mounted just like in Sid, though the new syntax wont work. What > we need here is a way to tell what version of the cgset/cgcreate > userland binary is there, preferably with something distribution agnostic... Mmm, you need to make sure of two things: 1) the version of cgroup fs available in the system, and 2) the version of cgroup-tools (which is independent of 1)). You can install cgroup-tools without mounting any cgroup file system, so I don't think knowing the version of cgset/cgcreate is a fully reliable solution. For 2), I'd prefer a versioned Depends on cgroup-tools (>= 2.0-2). > Maybe the only way is to just attempt the old style cgset, see if it > fails, and if it does, do v2 style cgset? For 1), I'd chose to test v2 first, and then v1. Remember that v1 is not mounted by default. > I'd prefer a better way to detect the cgroup version if available. ... If you can propose a better way, I am all ears. Cheers, -- S signature.asc Description: PGP signature
Bug#991463: fixed in knot-resolver 5.4.1-1
El 31/08/21 a las 19:01, Jakub Ružička escribió: > > I've opened transition bug #993027 > > Got ack from RT, I've uploaded knot-3.1.1-4 into unstable to start the > transition. > > Do I need to wait until the new knot built on all archs before uploading > depending knot-resolver-5.4.1-2 or is there a smart mechanism ensuring > build against correct/latest version? Well, I am not sure of that. I'd wait to have it built on all archs (and ping debian-buildd if needed), as it is the case right now. But I think also that such smart mechanism exists if you don't want to wait. > > Yes, that I should fix the issue with the next (first) bullseye-point > > release after it's been fixed in unstable. ACK. > > I've prepared knot-resolver-5.3.1-2+deb11u1 with the backport of > upstream fix in new debian/bullseye salsa branch: > > https://salsa.debian.org/dns-team/knot-resolver/-/commits/debian/bullseye > > Please review my changes before I attempt the bullseye upload as I'm new > to this process. > diff --git a/debian/changelog b/debian/changelog index a38aa258..0cf5bc71 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +knot-resolver (5.3.1-2+deb11u1) bullseye; urgency=medium Version in stable is 5.3.1-1, so it would be 5.3.1-1+deb11u1. You shouldn't bump the debian revision number. It will be longer the case for kresd, but suppose you upload a more recent revision to testing or unstable. If you 5.3.1-2 would be < 5.3.1-2+deb11u1, and user would have a problem to upgrade it. > > , > Jakub , -- S signature.asc Description: PGP signature
Bug#991463: fixed in knot-resolver 5.4.1-1
El 01/09/21 a las 10:49, Santiago Ruano Rincón escribió: > El 31/08/21 a las 19:01, Jakub Ružička escribió: > > > I've opened transition bug #993027 Forgot to say a couple of things: it's really good that you know how to handle transitions now. For the case of knot, being kresd its only reverse dependency, I think you can move to unstable when you are sure they build OK (release team has always the final word, you can ask them). > > > > Got ack from RT, I've uploaded knot-3.1.1-4 into unstable to start the > > transition. > > > > Do I need to wait until the new knot built on all archs before uploading > > depending knot-resolver-5.4.1-2 or is there a smart mechanism ensuring > > build against correct/latest version? > > Well, I am not sure of that. I'd wait to have it built on all archs (and > ping debian-buildd if needed), as it is the case right now. But I think > also that such smart mechanism exists if you don't want to wait. > > > > Yes, that I should fix the issue with the next (first) bullseye-point > > > release after it's been fixed in unstable. > > ACK. > > > > > I've prepared knot-resolver-5.3.1-2+deb11u1 with the backport of > > upstream fix in new debian/bullseye salsa branch: > > > > https://salsa.debian.org/dns-team/knot-resolver/-/commits/debian/bullseye > > > > Please review my changes before I attempt the bullseye upload as I'm new > > to this process. > > > > diff --git a/debian/changelog b/debian/changelog > index a38aa258..0cf5bc71 100644 > --- a/debian/changelog > +++ b/debian/changelog > @@ -1,3 +1,10 @@ > +knot-resolver (5.3.1-2+deb11u1) bullseye; urgency=medium > > Version in stable is 5.3.1-1, so it would be 5.3.1-1+deb11u1. You shouldn't > bump the debian revision number. It will be longer the case for kresd, but > suppose you upload a more recent revision to testing or unstable. If you > 5.3.1-2 would be < 5.3.1-2+deb11u1, and user would have a problem to upgrade > it. > Also, you may correct the RELEASE in debian/salsa-ci.yml https://salsa.debian.org/salsa-ci-team/pipeline/#changing-the-debian-release > > , > > Jakub > > , > > -- S , -- S signature.asc Description: PGP signature
Bug#991463: new upstream (5.3.2) with nsec3 (potential DoS) fixes
Hi, El 21/08/21 a las 21:29, Daniel Baumann escribió: > Hi, > > in the meanwhile, there's 5.4.1 out. do you need help getting the > package updated or uploaded? ... Jakub is handling this. Kresd 5.4.x builds on the new knot 3.1.x, that needed to pass through NEW and just entered into experimental. BTW, do you have upload rights? Cheers, -- S signature.asc Description: PGP signature
Bug#993371: Support for cgroups v2
Control: forwarded -1 https://github.com/ansible/ansible-runner/issues/810 El 01/09/21 a las 21:17, Sakirnth Nagarasa escribió: > Hello > > Thank you for your bug report. > > I have opened a bug in upstream: > https://github.com/ansible/ansible-runner/issues/810 > > As soon as they adapt the code I will upload the new version to debian. > > Cheers, > Saki Thanks Saki. I'm letting know the BTS that the bugs has been forwarded upstream. Cheers, -- S signature.asc Description: PGP signature
Bug#992442: bzip2: Use tempfile in /usr/bin/bzexe, which is no longer available
Control: tags -1 + pending On Wed, 18 Aug 2021 12:34:23 -0400 Boyuan Yang wrote: > Package: bzip2 > Severity: grave > Version: 1.0.8-4 > Control: tags -1 sid > X-Debbugs-CC: santi...@debian.org santi...@debian.org > > Dear Debian bzip2 package maintainers, > > As discussed in https://bugs.debian.org/992396 , the tempfile command has been > removed from debianutils package. However, it looks like the bzexe command > provided by Debian still uses it: > > https://sources.debian.org/src/bzip2/1.0.8-4/debian/bzexe/#L123 > > > set -C > umask=`umask` > umask 77 > tmpfile=`tempfile -p gztmp -d /tmp` || exit 1 > > > Please consider switching to mktemp(1) provided by GNU coreutils. > > Thanks, > Boyuan Yang Fixed in git. signature.asc Description: PGP signature
Bug#979755: ITA: coyim
On Sun, 5 Sep 2021 03:28:50 +0530 Kushagra Karira wrote: > To become a sponsored maintainer, i'd like to take up the coyim, > The package seems good enough that people will actually use, it is under > active development according to its github page and small enough to work > with any errors. > > Regards > Kushagra Karira Hi, Thanks for your interest on adopting coyim. You use the Subject of your mail to express your ITA. However, you need to change the title and owner. You can see an example here: https://www.debian.org/Bugs/Reporting#control (The Subject sets the bug's title only for new bugs) Cheers, -- Santiago P.S. If your ITA still stands, don't forget to sign your future mail, as I suggested you in your DM application. signature.asc Description: PGP signature
Bug#947233: ifupdown: Please include restart-ms option in can config
Hi, On Mon, 23 Dec 2019 11:03:33 +0100 Joerg Dorchain wrote: > Package: ifupdown > Version: 0.8.35 > Tags: Patch > Severity: wishlist > > Hi, > > please include the restart-ms option in the can static method, e.g as per > attached patch. > > Thanks for considering. > > Bye, > > Joerg > > > --- ifupdown-0.8.35.orig/can.defn 2018-10-29 22:29:33.0 +0100 > +++ ifupdown-0.8.35/can.defn 2019-12-23 11:00:03.421389325 +0100 > @@ -14,6 +14,7 @@ > triple triple-- activate triple sampling (on|off) > oneshot oneshot -- one shot mode (on|off) > berr berr-- activate berr reporting (on|off) > +restart-ms restart-ms-- restart-ms (0..) > >up > ip link set %iface% type can bitrate %bitrate% > @@ -22,6 +23,7 @@ > [[ ip link set %iface% type can triple-sampling %triple% ]] > [[ ip link set %iface% type can one-shot %oneshot% ]] > [[ ip link set %iface% type can berr-reporting %berr% ]] > +[[ ip link set %iface% type can restart-ms %restart-ms% ]] > ip link set %iface% up > >down > Thanks for your patch. I cannot test it by myself but I suppose it is OK to include it. However, could you please document this option in your patch? You may include it in interfaces(5) Thanks, -- Santiago
Bug#947233: ifupdown: Please include restart-ms option in can config
Control: tags -1 + pending El 11/10/21 a las 17:44, Joerg Dorchain escribió: > On Mon, Oct 11, 2021 at 05:14:15PM +0200, Santiago Ruano Rincón wrote: > > > > Hi, > > > > On Mon, 23 Dec 2019 11:03:33 +0100 Joerg Dorchain > > wrote: > > > Package: ifupdown > > > Version: 0.8.35 > > > Tags: Patch > > > Severity: wishlist > > > > > > Hi, > > > > > > please include the restart-ms option in the can static method, e.g as per > > > attached patch. > > > > > > Thanks for considering. > > > > > > Bye, > > > > > > Joerg > > > > > > > > > --- ifupdown-0.8.35.orig/can.defn 2018-10-29 22:29:33.0 +0100 > > > +++ ifupdown-0.8.35/can.defn 2019-12-23 11:00:03.421389325 +0100 > > > @@ -14,6 +14,7 @@ > > > triple triple-- activate triple sampling (on|off) > > > oneshot oneshot -- one shot mode (on|off) > > > berr berr-- activate berr reporting (on|off) > > > +restart-ms restart-ms-- restart-ms (0..) > > > > > >up > > > ip link set %iface% type can bitrate %bitrate% > > > @@ -22,6 +23,7 @@ > > > [[ ip link set %iface% type can triple-sampling %triple% ]] > > > [[ ip link set %iface% type can one-shot %oneshot% ]] > > > [[ ip link set %iface% type can berr-reporting %berr% ]] > > > +[[ ip link set %iface% type can restart-ms %restart-ms% ]] > > > ip link set %iface% up > > > > > >down > > > > > > > Thanks for your patch. I cannot test it by myself but I suppose it is OK > > to include it. However, could you please document this option in your > > patch? You may include it in interfaces(5) > > Here you are: > --- interfaces.5.orig 2021-10-11 17:39:09.417498419 +0200 > +++ interfaces.52021-10-11 17:42:08.263610653 +0200 > @@ -889,6 +889,9 @@ > .TP > .BI berr " berr" > activate berr reporting (on|off) > +.TP > +.BI restart-ms " restart-ms" > +set restart-ms value (0..) > .RE > .SH KNOWN BUGS/LIMITATIONS > The Thanks! And sorry, the man patch was not really needed. I belatedly realised realised that section was generated from the definition. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#982959: ifupdown: regex not workig as expected
El 08/10/21 a las 10:32, Martin-Éric Racine escribió: > ke 6. lokak. 2021 klo 15.19 Santiago Ruano Rincón > (santiag...@riseup.net) kirjoitti: > > > > El 06/10/21 a las 12:28, Martin-Éric Racine escribió: > > > ke 6. lokak. 2021 klo 12.20 Santiago Ruano Rincón > > > (santiag...@riseup.net) kirjoitti: > > > > > > > > El 06/10/21 a las 09:24, Martin-Éric Racine escribió: > > > > > la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) > > > > > kirjoitti: > > > > > > > > > > > > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine: > > > > > > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón > > > > > > > (santiag...@riseup.net) kirjoitti: > > > > > > >> > > > > > > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió: > > > > > > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón > > > > > > >>> (santiag...@riseup.net) kirjoitti: > > > > > > >>>> On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine > > > > > > >>>> wrote: > > > > > > >>>>> Package: ifupdown > > > > > > >>>>> Version: 0.8.36 > > > > > > >>>>> Severity: normal > > > > > > >>>>> > > > > > > >>>>> -BEGIN PGP SIGNED MESSAGE- > > > > > > >>>>> Hash: SHA256 > > > > > > >>>>> > > > > > > >>>>> The regex recipe below does not work as expected. I've tried > > > > > > >>>>> both > > > > > > >>>>> > > > > > > >>>>> allow-hotplug /en*=en /wl*=wl > > > > > > >>>>> > > > > > > >>>>> and > > > > > > >>>>> > > > > > > >>>>> allow-hotplug /en*/=en /wl*/=wl > > > > > > >>>>> > > > > > > >>>>> but ifup still doesn't raise whatever interface match the > > > > > > >>>>> regex. Have I misunderstood the examples or am I missing > > > > > > >>>>> something else? > > > > > > >>>>> > > > > > > >>>>> Thanks! > > > > > > >>>>> > > > > > > >>>>> - -- Package-specific info: > > > > > > >>>>> - --- /etc/network/interfaces: > > > > > > >>>>> allow-hotplug /en*=en /wl*=wl > > > > > > >>>>> > > > > > > >>>>> iface en inet dhcp > > > > > > >>>>> iface en inet6 auto > > > > > > >>>>> privext 2 > > > > > > >>>>> #dhcp 1 > > > > > > >>>>> > > > > > > >>>>> iface wl inet dhcp > > > > > > >>>>> wpa-ssid AccessPoint > > > > > > >>>>> wpa-psk mypassword > > > > > > >>>>> iface wl inet6 auto > > > > > > >>>>> privext 2 > > > > > > >>>>> #dhcp 1 > > > > > > >>> > > > > > > >>> [...] > > > > > > >>> > > > > > > >>>> I get both interfaces configured. Could you please run ifup > > > > > > >>>> with -v? > > > > > > >>> > > > > > > >>> I just tried. Here's an interesting difference: > > > > > > >>> > > > > > > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped > > > > > > >>> interfaces. > > > > > > >> > > > > > > >> ifup doesn't process them since they are not configured with > > > > > > >> `auto` > > > > > > > > > > > > > > OK, what processes interfaces with allow-hotplug then, if not > > > > > > > ifupdown? > > > > > > > > > > > > > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work. > > > > > > >
Bug#996884: Ambiguous licenses for files in debian/patches/ folders
El 20/10/21 a las 14:46, Dylan Aïssi escribió: > Hi Santiago, > > Le mer. 20 oct. 2021 à 14:03, Santiago Ruano Rincón > a écrit : > > > > Thanks for pointing this out. Hopefully, this change solves the > > ambiguity: > > https://salsa.debian.org/debian/libcgroup/-/blob/8476aa90da599fe59ad33d6a9911b931291b84f4/debian/copyright#L17 > > > > Indeed, thanks :) > > The copyright holders are probably wrong, you should add the patches authors. … Mmmm, I am not a license-nerd, and I am not sure about that. Could you please provide documentation about the copyright holders of patches? Do you have examples in debian packages that give that level of detail in d/copyright about debian/patches/*? Best, -- S signature.asc Description: PGP signature
Bug#996884: Ambiguous licenses for files in debian/patches/ folder
Control: tags -1 + pending El 20/10/21 a las 11:02, Dylan Aïssi escribió: > Package: libcgroup > Severity: important > > Dear Maintainer, > > The license of debian/patches/* files is ambiguous as defined in the > debian/copyright file. > libcg is under LGPL-2.1 license whereas all files into the debian/ > folder are under GPL-3 including all patches. > That means either the whole package is relicensed under GPL-3 (which > seems wrong) or better all patches are under the same license of the > targeted files. > > Could you clarify the license of these patches in d/copyright? > > Thanks > > Best, > Dylan Hi Dylan, Thanks for pointing this out. Hopefully, this change solves the ambiguity: https://salsa.debian.org/debian/libcgroup/-/blob/8476aa90da599fe59ad33d6a9911b931291b84f4/debian/copyright#L17 Best, -- S signature.asc Description: PGP signature
Bug#996901: ifupdown: When booting a thin client over the network (NFS-Root) ifup fails
Hi, El 20/10/21 a las 15:31, Ralf Schlatterbeck escribió: > > Package: ifupdown > Version: 0.8.36 > Severity: important > X-Debbugs-Cc: r...@runtux.com > > Dear Maintainer, > > I'm trying to network-boot a thin client (orange-pi zero) with debian > bullseye and a custom kernel. NFS mount works fine but ifup fails > spectacularly. This works fine on debian buster (but may be kernel > specific, the debian buster setup has an older 5.9 kernel). What are you network mount points? > > When booting with the 'auto eth0' in /etc/network/interfaces I'm getting > a 5 Minute wait and then > > [FAILED] Failed to start Raise network interfaces. > > And issuing the command 'ip addr ls' will reveal that a lot of IP > addresses have been reserved for the eth0 interface (see below). > > When removing the 'auto eth0' line and starting up the interface manually > when the system is up (it already *has* an IP-Address at that point due > to the NFS-Root) I'm getting: > > root@sun7i:~# ifup eth0 > Internet Systems Consortium DHCP Client 4.4.1 > Copyright 2004-2018 Internet Systems Consortium. > All rights reserved. > For info, please visit https://www.isc.org/software/dhcp/ > > Listening on LPF/eth0/02:42:b3:f0:2d:3e > Sending on LPF/eth0/02:42:b3:f0:2d:3e > Sending on Socket/fallback > Created duid "\000\001\000\001)\002\266\310\002B\263\360->". > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 > DHCPOFFER of 10.23.5.173 from 10.23.5.254 > DHCPREQUEST for 10.23.5.173 on eth0 to 255.255.255.255 port 67 > DHCPACK of 10.23.5.173 from 10.23.5.254 > RTNETLINK answers: File exists > DHCPDECLINE of 10.23.5.173 on eth0 to 255.255.255.255 port 67 > DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6 > DHCPOFFER of 10.23.5.205 from 10.23.5.254 > DHCPREQUEST for 10.23.5.205 on eth0 to 255.255.255.255 port 67 > DHCPACK of 10.23.5.205 from 10.23.5.254 > DHCPDECLINE of 10.23.5.205 on eth0 to 255.255.255.255 port 67 ... Your dhclient is declining all of the offered IPs… Are you sure they are available? Cheers, -- S signature.asc Description: PGP signature
Bug#982959: ifupdown: regex not workig as expected
Control: tags -1 + moreinfo Control: title -1 pattern not working as expected Hello there, Sorry for the late answer. Just to avoid confusion, I prefer to retitle the bug: patterns are more accurate than regex here. On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine wrote: > Package: ifupdown > Version: 0.8.36 > Severity: normal > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > The regex recipe below does not work as expected. I've tried both > > allow-hotplug /en*=en /wl*=wl > > and > > allow-hotplug /en*/=en /wl*/=wl > > but ifup still doesn't raise whatever interface match the regex. Have I > misunderstood the examples or am I missing something else? > > Thanks! > > - -- Package-specific info: > - --- /etc/network/interfaces: > allow-hotplug /en*=en /wl*=wl > > iface en inet dhcp > iface en inet6 auto > privext 2 > #dhcp 1 > > iface wl inet dhcp > wpa-ssid AccessPoint > wpa-psk mypassword > iface wl inet6 auto > privext 2 > #dhcp 1 > with this /e/n/interfaces inside an lxc container (so no udev) with two interfaces (eth0 and eth1): auto lo iface lo inet loopback allow-hotplug /eth*=lan iface lan inet dhcp patterns seem to match: ifdown /eth* Killed old client process Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/d6:ca:92:4e:8b:ef Sending on LPF/eth0/d6:ca:92:4e:8b:ef Sending on Socket/fallback DHCPRELEASE of 10.0.3.48 on eth0 to 10.0.3.1 port 67 Killed old client process Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth1/72:73:72:06:14:7c Sending on LPF/eth1/72:73:72:06:14:7c Sending on Socket/fallback DHCPRELEASE of 10.0.3.222 on eth1 to 10.0.3.1 port 67 ifup --allow hotplug -a -v run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge ifup: configuring interface eth0=lan (inet) run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge CLIENT="-i"; /sbin/dhclient -4 -v $CLIENT -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth0/d6:ca:92:4e:8b:ef Sending on LPF/eth0/d6:ca:92:4e:8b:ef Sending on Socket/fallback DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 DHCPOFFER of 10.0.3.48 from 10.0.3.1 DHCPREQUEST for 10.0.3.48 on eth0 to 255.255.255.255 port 67 DHCPACK of 10.0.3.48 from 10.0.3.1 bound to 10.0.3.48 -- renewal in 1672 seconds. run-parts --exit-on-error --verbose /etc/network/if-up.d ifup: configuring interface eth1=lan (inet) run-parts --exit-on-error --verbose /etc/network/if-pre-up.d run-parts: executing /etc/network/if-pre-up.d/bridge CLIENT="-i"; /sbin/dhclient -4 -v $CLIENT -pf /run/dhclient.eth1.pid -lf /var/lib/dhcp/dhclient.eth1.leases -I -df /var/lib/dhcp/dhclient6.eth1.leases eth1 Internet Systems Consortium DHCP Client 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/eth1/72:73:72:06:14:7c Sending on LPF/eth1/72:73:72:06:14:7c Sending on Socket/fallback DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 5 DHCPOFFER of 10.0.3.222 from 10.0.3.1 DHCPREQUEST for 10.0.3.222 on eth1 to 255.255.255.255 port 67 I get both interfaces configured. Could you please run ifup with -v? Cheers, -- Santiago signature.asc Description: PGP signature
Bug#982959: ifupdown: regex not workig as expected
El 06/10/21 a las 12:28, Martin-Éric Racine escribió: > ke 6. lokak. 2021 klo 12.20 Santiago Ruano Rincón > (santiag...@riseup.net) kirjoitti: > > > > El 06/10/21 a las 09:24, Martin-Éric Racine escribió: > > > la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) kirjoitti: > > > > > > > > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine: > > > > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón > > > > > (santiag...@riseup.net) kirjoitti: > > > > >> > > > > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió: > > > > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón > > > > >>> (santiag...@riseup.net) kirjoitti: > > > > >>>> On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine > > > > >>>> wrote: > > > > >>>>> Package: ifupdown > > > > >>>>> Version: 0.8.36 > > > > >>>>> Severity: normal > > > > >>>>> > > > > >>>>> -BEGIN PGP SIGNED MESSAGE- > > > > >>>>> Hash: SHA256 > > > > >>>>> > > > > >>>>> The regex recipe below does not work as expected. I've tried both > > > > >>>>> > > > > >>>>> allow-hotplug /en*=en /wl*=wl > > > > >>>>> > > > > >>>>> and > > > > >>>>> > > > > >>>>> allow-hotplug /en*/=en /wl*/=wl > > > > >>>>> > > > > >>>>> but ifup still doesn't raise whatever interface match the regex. > > > > >>>>> Have I misunderstood the examples or am I missing something else? > > > > >>>>> > > > > >>>>> Thanks! > > > > >>>>> > > > > >>>>> - -- Package-specific info: > > > > >>>>> - --- /etc/network/interfaces: > > > > >>>>> allow-hotplug /en*=en /wl*=wl > > > > >>>>> > > > > >>>>> iface en inet dhcp > > > > >>>>> iface en inet6 auto > > > > >>>>> privext 2 > > > > >>>>> #dhcp 1 > > > > >>>>> > > > > >>>>> iface wl inet dhcp > > > > >>>>> wpa-ssid AccessPoint > > > > >>>>> wpa-psk mypassword > > > > >>>>> iface wl inet6 auto > > > > >>>>> privext 2 > > > > >>>>> #dhcp 1 > > > > >>> > > > > >>> [...] > > > > >>> > > > > >>>> I get both interfaces configured. Could you please run ifup with > > > > >>>> -v? > > > > >>> > > > > >>> I just tried. Here's an interesting difference: > > > > >>> > > > > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces. > > > > >> > > > > >> ifup doesn't process them since they are not configured with `auto` > > > > > > > > > > OK, what processes interfaces with allow-hotplug then, if not > > > > > ifupdown? > > > > > > > > > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work. > > > > >>> > > > > >>> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and > > > > >>> maps the wireless interfaces. > > > > >>> > > > > >> > > > > >> I wonder if there is a problem related with udev instead. > > > > > > > > > > Added udev (systemd) maintainers in CC. > > > > > > > > If you are referring to > > > > /lib/udev/ifupdown-hotplug and /lib/udev/rules.d/80-ifupdown.rules, > > > > those files are maintained by the ifupdown package. > > > > > > > > The systemd package is not involved here. > > > > > > Michael, I suspected as much. Thanks for confirming this. > > > > > > Santiago, all evidences point to ifupdown pattern matching only > > > working for auto interfaces, but not hotplug interfaces. > > > > Not exactly, I think. 'sudo ifup --allow hotplug -a -v' works for you. > > I should not have to type that manually to have ifupdown find and > raise the interfaces. > > > > Basically, > > > hotplug works for named interfaces, but not for pattern matched > > > interfaces. > > > > ifupdown-hotplug receives as argument the name of the real > > interface, so it execs ifup --allow=hotplug $INTERFACE > > https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/ifupdown-hotplug#L73 > > and it wouldn't find it in your configuration. > > Which is precisely the problem. The mapping fails. > > > Maybe your use case matches better templates and inherits (See INTERFACE > > TEMPLATES) in interfaces(5). > > It doesn't. Templates rely upon explicitly defining interfaces. OK, I see. So the problem is not explicitly related to ifupdown. With the same config from above, this does not work: $ sudo ifup eth1 ifup: unknown interface eth1 You expect that ifupdown matches an interface given as argument to the lists of interfaces in auto, allow-hotplug, etc, even without defining them, as long as they are known by the kernel. signature.asc Description: PGP signature
Bug#947234: ifupdown: Do not wait forever for ipv6 stateless dhcp
Control: tags -1 + pending On Mon, 23 Dec 2019 10:56:04 +0100 Joerg Dorchain wrote: > Package: ifupdown > Version: 0.8.35 > Tags: Patch > > Hi, > > I have a Box that I want to connect to several network which do (or don't) IP > autoconfiguration. > For IPv4, this works fine. Even when there is no IPv4 dhcp server, the > machine continues to boot after a timeout. > > For IPv6, when ausing SLAAC autoconfiguration for the address, and trying to > get the rest (resolver, ntp,...) via stateless dhcp, if currently hangs > forever trying to get this information on booted on a network which does not > have a IPv6 dhcp. > > Which this patch, the call to dhclient has an option to timeout, so at least > the machine continues to boot. > > Thanks for including it. ... Applied. Thank you for the patch. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#994745: ifupdown: "ifup --read-environment" does not honor $EXCLUDE_INTERFACES
Control: tags -1 + pending El 20/09/21 a las 12:04, Adam Stephens escribió: > Package: ifupdown > Version: 0.8.36+nmu1 > Severity: normal > Tags: patch > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > ifdown does not correctly handle excluded interfaces passed in > $EXCLUDE_INTERFACES: > # EXCLUDE_INTERFACES="lo" /sbin/ifdown lo --read-environment -n > run-parts /etc/network/if-down.d > ip link set dev lo down > run-parts /etc/network/if-post-down.d > > This appears to be caused by an issue copying the value of the > environment variable into excludint … Thanks. Patch applied in the 994745 git branch. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#982959: ifupdown: regex not workig as expected
El 01/10/21 a las 17:05, Martin-Éric Racine escribió: > pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón > (santiag...@riseup.net) kirjoitti: > > On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine > > wrote: > > > Package: ifupdown > > > Version: 0.8.36 > > > Severity: normal > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > The regex recipe below does not work as expected. I've tried both > > > > > > allow-hotplug /en*=en /wl*=wl > > > > > > and > > > > > > allow-hotplug /en*/=en /wl*/=wl > > > > > > but ifup still doesn't raise whatever interface match the regex. Have I > > > misunderstood the examples or am I missing something else? > > > > > > Thanks! > > > > > > - -- Package-specific info: > > > - --- /etc/network/interfaces: > > > allow-hotplug /en*=en /wl*=wl > > > > > > iface en inet dhcp > > > iface en inet6 auto > > > privext 2 > > > #dhcp 1 > > > > > > iface wl inet dhcp > > > wpa-ssid AccessPoint > > > wpa-psk mypassword > > > iface wl inet6 auto > > > privext 2 > > > #dhcp 1 > > [...] > > > I get both interfaces configured. Could you please run ifup with -v? > > I just tried. Here's an interesting difference: > > If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces. ifup doesn't process them since they are not configured with `auto` s/allow-hotplug/auto/ in my /e/n/interfaces makes this work. > > If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and > maps the wireless interfaces. > I wonder if there is a problem related with udev instead. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#947234: ifupdown: Do not wait forever for ipv6 stateless dhcp
Control: merge -1 752672 If I am not wrong, these are the same dhcp6 stateful issue. El 22/09/21 a las 10:18, Santiago Ruano Rincón escribió: > Control: tags -1 + pending > > On Mon, 23 Dec 2019 10:56:04 +0100 Joerg Dorchain wrote: > > Package: ifupdown > > Version: 0.8.35 > > Tags: Patch > > > > Hi, > > > > I have a Box that I want to connect to several network which do (or don't) > > IP > > autoconfiguration. > > For IPv4, this works fine. Even when there is no IPv4 dhcp server, the > > machine continues to boot after a timeout. > > > > For IPv6, when ausing SLAAC autoconfiguration for the address, and trying to > > get the rest (resolver, ntp,...) via stateless dhcp, if currently hangs > > forever trying to get this information on booted on a network which does not > > have a IPv6 dhcp. > > > > Which this patch, the call to dhclient has an option to timeout, so at least > > the machine continues to boot. > > > > Thanks for including it. > ... > > Applied. Thank you for the patch. > > Cheers, > > -- Santiago signature.asc Description: PGP signature
Bug#982959: ifupdown: regex not workig as expected
El 06/10/21 a las 09:24, Martin-Éric Racine escribió: > la 2. lokak. 2021 klo 11.13 Michael Biebl (bi...@debian.org) kirjoitti: > > > > Am 02.10.21 um 09:05 schrieb Martin-Éric Racine: > > > pe 1. lokak. 2021 klo 23.39 Santiago Ruano Rincón > > > (santiag...@riseup.net) kirjoitti: > > >> > > >> El 01/10/21 a las 17:05, Martin-Éric Racine escribió: > > >>> pe 1. lokak. 2021 klo 16.21 Santiago Ruano Rincón > > >>> (santiag...@riseup.net) kirjoitti: > > >>>> On Wed, 17 Feb 2021 14:32:24 +0200 Martin-Éric_Racine > > >>>> wrote: > > >>>>> Package: ifupdown > > >>>>> Version: 0.8.36 > > >>>>> Severity: normal > > >>>>> > > >>>>> -BEGIN PGP SIGNED MESSAGE- > > >>>>> Hash: SHA256 > > >>>>> > > >>>>> The regex recipe below does not work as expected. I've tried both > > >>>>> > > >>>>> allow-hotplug /en*=en /wl*=wl > > >>>>> > > >>>>> and > > >>>>> > > >>>>> allow-hotplug /en*/=en /wl*/=wl > > >>>>> > > >>>>> but ifup still doesn't raise whatever interface match the regex. Have > > >>>>> I misunderstood the examples or am I missing something else? > > >>>>> > > >>>>> Thanks! > > >>>>> > > >>>>> - -- Package-specific info: > > >>>>> - --- /etc/network/interfaces: > > >>>>> allow-hotplug /en*=en /wl*=wl > > >>>>> > > >>>>> iface en inet dhcp > > >>>>> iface en inet6 auto > > >>>>> privext 2 > > >>>>> #dhcp 1 > > >>>>> > > >>>>> iface wl inet dhcp > > >>>>> wpa-ssid AccessPoint > > >>>>> wpa-psk mypassword > > >>>>> iface wl inet6 auto > > >>>>> privext 2 > > >>>>> #dhcp 1 > > >>> > > >>> [...] > > >>> > > >>>> I get both interfaces configured. Could you please run ifup with -v? > > >>> > > >>> I just tried. Here's an interesting difference: > > >>> > > >>> If I use 'sudo ifup -a -v' ifup won't find the mapped interfaces. > > >> > > >> ifup doesn't process them since they are not configured with `auto` > > > > > > OK, what processes interfaces with allow-hotplug then, if not ifupdown? > > > > > >> s/allow-hotplug/auto/ in my /e/n/interfaces makes this work. > > >>> > > >>> If I use 'sudo ifup --allow hotplug -a -v' ifup correctly finds and > > >>> maps the wireless interfaces. > > >>> > > >> > > >> I wonder if there is a problem related with udev instead. > > > > > > Added udev (systemd) maintainers in CC. > > > > If you are referring to > > /lib/udev/ifupdown-hotplug and /lib/udev/rules.d/80-ifupdown.rules, > > those files are maintained by the ifupdown package. > > > > The systemd package is not involved here. > > Michael, I suspected as much. Thanks for confirming this. > > Santiago, all evidences point to ifupdown pattern matching only > working for auto interfaces, but not hotplug interfaces. Not exactly, I think. 'sudo ifup --allow hotplug -a -v' works for you. > Basically, > hotplug works for named interfaces, but not for pattern matched > interfaces. ifupdown-hotplug receives as argument the name of the real interface, so it execs ifup --allow=hotplug $INTERFACE https://salsa.debian.org/debian/ifupdown/-/blob/master/debian/ifupdown-hotplug#L73 and it wouldn't find it in your configuration. Maybe your use case matches better templates and inherits (See INTERFACE TEMPLATES) in interfaces(5). HTH, -- S signature.asc Description: PGP signature
Bug#995189: RFH: isc-dhcp
El 27/09/21 a las 20:25, Martin-Éric Racine escribió: > Package: wnpp > Severity: normal > X-Debbugs-Cc: debian-de...@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. Indeed. I am willing to spend some cycles to help maintaining it. I requested access to the ISC DHCP packaging team in salsa ~a couple of weeks ago, but I hasn't been answered yet (mgilbert is its only member). It was on my ToDo list to ping the maintainers (in CC). Cheers, -- Santiago signature.asc Description: PGP signature
Bug#993311: Support for cgroup v2 via cgroup-tools
Source: cinder Version: 2:18.0.0-2 Severity: important Tags: upstream Hello Zigo, As discussed privately, cinder needs to support cgroup v2. Now that that a version of cgroup-tools supporing cgroup v2 (2.0) has landed into unstable, cinder can still use it, but it needs to adapt the controllers path, since some resources are not longer available. It means that instead of using blkio, as in https://sources.debian.org/src/cinder/2:18.0.0-2/cinder/privsep/cgroup.py/#L28 cinder has to use the io controller (If I am not wrong). You can refer to the kernel documentation about cgroups v2: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#io Cinder would have to call `cgset` and `cgcreate` with paths according to the cgroup version supported by the running system. To know if cgroup v2 is supported, one way is to `grep cgroup2 /proc/mounts` HTH, -- Santiago -- System Information: Debian Release: bookworm/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#995189: RFH: isc-dhcp
El 07/11/21 a las 13:54, Martin-Éric Racine escribió: > Howdy! Hi! > > ma 27. syysk. 2021 klo 21.44 Santiago Ruano Rincón > (santiag...@riseup.net) kirjoitti: > > El 27/09/21 a las 20:25, Martin-Éric Racine escribió: > > > Package: wnpp > > > Severity: normal > > > X-Debbugs-Cc: debian-de...@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. > > > > Indeed. I am willing to spend some cycles to help maintaining it. I > > requested access to the ISC DHCP packaging team in salsa ~a couple of > > weeks ago, but I hasn't been answered yet (mgilbert is its only member). > > It was on my ToDo list to ping the maintainers (in CC). > > Has any progress taken place on this? > > Martin-Éric I've started doing some work at https://salsa.debian.org/santiago/isc-dhcp/ I still didn't get any answer from current maintainers (keeping them in CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no later than next Friday. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#1000662: ITS: isc-dhcp
Source: isc-dhcp Version: 4.3.5-3+deb9u1 Severity: important X-Debbugs-Cc: mgilb...@debian.org, apoll...@debian.org, m...@qa.debian.org Dear ISC-DHCP maintainers, As stated in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995189#12, I am planing to salvage isc-dchp, placing myself as Uploader. Even if it's in upstream maintenance mode, I think is still useful (or at least, I need it). I am filing this ITS accoring to the 5.12 section of the developers reference [1] and following this criteria: * There is no visible activity regarding the package for six months * Previous NMUs were not acknowledged * The last upload was an NMU and there was no maintainer upload within one year * Bugs exist for more than one major missing upstream version Please, let me know if you are stilling willing to maintain isc-dhcp. According to the procedure described in [2], I will wait at least 21 days before uploading to DELAYED/7. [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging [2] https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#how-to-salvage-a-package Cheers, -- Santiago -- System Information: Debian Release: bookworm/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#1000127: grep: depends on obsolete pcre3 library
Control: merge -1 907652 El 18/11/21 a las 11:49, Matthew Vernon escribió: > Source: grep > Severity: important > User: matthew-pcre...@debian.org > Usertags: obsolete-pcre3 > > Dear maintainer, > > Your package still depends on the old, obsolete PCRE3[0] libraries > (i.e. libpcre3-dev). This has been end of life for a while now, and > upstream do not intend to fix any further bugs in it. Accordingly, I > would like to remove the pcre3 libraries from Debian, preferably in > time for the release of Bookworm. > ... This has been fixed upstream: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47264#47 -- Santiago signature.asc Description: PGP signature
Bug#983541: RFE: Please support pointopoint in the INET6 address family
Hi, On Thu, 25 Feb 2021 21:58:45 +0100 gustavo panizzo wrote: > Package: ifupdown > Version: 0.8.36 > Severity: wishlist > Tags: ipv6 > > > Hello > > currently the manual method for ipv6 does not support pointopoint > configurations > > config > > ``` > iface wg3 inet static > pre-up ip link add $IFACE type wireguard > pre-up wg setconf $IFACE /etc/wireguard/$IFACE.conf > post-down ip link del $IFACE > post-up wg set $IFACE fwmark 51097 > address 172.21.68.1 > netmask 255.255.255.255 > pointopoint 172.21.68.9 > > iface wg3 inet6 static > address fe80::1:100/128 > pointopoint fdc5:30f7:af0a:1000::1 > ``` > > resulting config > > ``` > # ip -6 a s dev wg3 > 69: wg3: mtu 1420 state UNKNOWN qlen 1000 > inet6 fe80::1:100/128 scope link >valid_lft forever preferred_lft forever > > ``` > > while this configuration is supported by ip without problems > > (removing ipv6 config for wg3 in /etc/network/interfaces) > > ``` > ip -6 addr add fe80::1:100 peer fdc5:30f7:af0a:1000::1 dev wg3 > > # ip -6 a s dev wg3 > 68: wg3: mtu 1420 state UNKNOWN qlen 1000 > inet6 fe80::1:100 peer fdc5:30f7:af0a:1000::1/128 scope link >valid_lft forever preferred_lft forever > ``` > > thanks! Don't hesitate to propose a patch :-) Cheers, -- Santiago signature.asc Description: PGP signature
Bug#990990: unblock: libcgroup/2.0
El 20/07/21 a las 20:57, Thomas Goirand escribió: > On 7/19/21 3:07 PM, Santiago Ruano Rincón wrote: > > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers wrote: > >> Hi, > >> > >> On 12-07-2021 18:45, Michael Biebl wrote: > >>> This was already discussed in > >>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > >>> > >>> My takeaway from that discussion was, that rdeps of cgroup-tools, would > >>> itself have to be made cgroupv2 aware, especially OpenStack and its > >>> components. > >> > >> That resembles my understanding of that discussion too. > > > > Mine too. > > > > zigo, are there any news from openstack about this? > > There is no way that Cinder and Nova produce a patch for OpenStack > Victoria (the release in Bullseye), which was released 9 months ago. > They are *planning* to use Cgroups v2 right now, but I'm not even sure > it's going to be ready for next version in October. > > >>> Have those rdeps been tested successfully with libcgroup/cgroup-tools > >>> from experimental? > >> > >> I'm not in favor of doing this transition now. > >> > > > > Please, keep in mind this comment, made before the release of 2.0: > > "we are planning something for next week. The version number will > > probably be 2.0 - with expectation that the v2 cycle will have > > continously breaking ABI. When we are happy where it is, we will push > > out v3 which will then maintain ABI through its lifetime." > > https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328 > > This means that probably, it's best that Bullseye continues to support > Cgroups v1 (which isn't the case currently if we don't allow libcgroup > 2.0 in). I don't understand your sentences between parenthesis, sorry. What do you mean? > On 7/19/21 11:48 PM, Adrian Bunk wrote: > > Based on soname and package name, the libcgroup1 in experimental > > claims to be ABI compatible with the library in buster. > > Changes in bookworm would be a normal library transition. > > > > OpenStack uses cgroup-tools, which is the only reason why libcgroup > > stayed in bullseye at all. > > My suggestion was basically asking whether 2.0 would be better for > > using with the version of OpenStack in bullseye, this is similar to > > your question to Thomas above. > > > > If cgroup-tools in *bookworm* would be incompatible with OpenStack in > > bullseye, this could be resolved with Breaks on the bullseye versions > > of cinder-common/nova-compute - this is irrelevant for discussing > > which version of libcgroup to ship in bullseye. > > Maybe I'm not understanding fully, though what I think I've read in this > discussion, is that libcgroup in experimental makes it possible to use > cgcreate / cgset without any additional kernel command line parameters > (please let me know if I'm mistaking). That is partially true. Those kernel command lines parameters you are referring too enable cgroupv1 (from systemd, if I am not wrong) > On the OpenStack side, that's the > only thing which is needed. Not exactly. The file structure (and resources) differ between cgroupv1 and cgroupv2. One has a separate hierarchy of resources, the other has a unified hierarchy. See https://chrisdown.name/talks/cgroupv2/cgroupv2-fosdem.pdf I don't have my irc log here, but I think I already gave you an example of the changes needed. https://sources.debian.org/src/cinder/2:17.0.1-1/cinder/privsep/cgroup.py/?hl=28#L28 That blkio resource path from cgroupv1 is not supported in cgroupv2 and you have to replace it. For io.max, if I am not wrong. So your code also needs to know what version of control group is enabled to use the correct resource path. It shouldn't be a difficult patch, but someone has to do it, and test it. > Cinder isn't using any library directly, > they just use the cgroup userland binaries. As for Nova, I'm not even > sure it's doing anything but using features from Qemu/Libvirt (this > would have to be checked). At least, doing a "grep -r cgcreate" in the > Nova source code returns nothing. > > Cheers, > > Thomas Goirand (zigo)
Bug#990990: unblock: libcgroup/2.0
El 20/07/21 a las 00:48, Adrian Bunk escribió: > On Mon, Jul 19, 2021 at 03:07:49PM +0200, Santiago Ruano Rincón wrote: > > On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers wrote: > > > Hi, > > > > > > On 12-07-2021 18:45, Michael Biebl wrote: > > > > This was already discussed in > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > > > > > > > > My takeaway from that discussion was, that rdeps of cgroup-tools, would > > > > itself have to be made cgroupv2 aware, especially OpenStack and its > > > > components. > > > > > > That resembles my understanding of that discussion too. > > > > Mine too. > > > > zigo, are there any news from openstack about this? > > > > > > > > > Have those rdeps been tested successfully with libcgroup/cgroup-tools > > > > from experimental? > > > > > > I'm not in favor of doing this transition now. > > > > > > > Please, keep in mind this comment, made before the release of 2.0: > > "we are planning something for next week. The version number will > > probably be 2.0 - with expectation that the v2 cycle will have > > continously breaking ABI. When we are happy where it is, we will push > > out v3 which will then maintain ABI through its lifetime." > > https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328 > > What kind of ABI is this referring to? I am afraid I haven't found any details about this, or asked for them (yet). Sorry for my quick answer. I intended to say that we can't expect the v2 cycle to be stable. But that doesn't necessarily mean it couldn't get into a debian stable release. Sorry if this was just noise. > > Based on soname and package name, the libcgroup1 in experimental > claims to be ABI compatible with the library in buster. > Changes in bookworm would be a normal library transition. Indeed. > > OpenStack uses cgroup-tools, which is the only reason why libcgroup > stayed in bullseye at all. > My suggestion was basically asking whether 2.0 would be better for > using with the version of OpenStack in bullseye, this is similar to > your question to Thomas above. > > If cgroup-tools in *bookworm* would be incompatible with OpenStack in > bullseye, this could be resolved with Breaks on the bullseye versions > of cinder-common/nova-compute - this is irrelevant for discussing which > version of libcgroup to ship in bullseye. Yes. Again, sorry for introducing noise. Just for the record, cgroup-tools (e.g. cgcreate or any other tool) in bookworm won't (or shouldn't) be incompatible with OpenStack in bullseye, since those cgroup-tools support cgroupv1 and cgroupv2. But the rdeps *also need to support cgroupv2* to make use of the correct resource paths. It is useless to have libcgroup supporting cgroupv2 in bullseye if the rdeps are not aware of it. I'll give more details in my answer to Thomas. Cheers, -- Santiago
Bug#990990: unblock: libcgroup/2.0
On Thu, 15 Jul 2021 12:27:35 +0200 Paul Gevers wrote: > Hi, > > On 12-07-2021 18:45, Michael Biebl wrote: > > This was already discussed in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959022 > > > > My takeaway from that discussion was, that rdeps of cgroup-tools, would > > itself have to be made cgroupv2 aware, especially OpenStack and its > > components. > > That resembles my understanding of that discussion too. Mine too. zigo, are there any news from openstack about this? > > > Have those rdeps been tested successfully with libcgroup/cgroup-tools > > from experimental? > > I'm not in favor of doing this transition now. > Please, keep in mind this comment, made before the release of 2.0: "we are planning something for next week. The version number will probably be 2.0 - with expectation that the v2 cycle will have continously breaking ABI. When we are happy where it is, we will push out v3 which will then maintain ABI through its lifetime." https://github.com/libcgroup/libcgroup/issues/12#issuecomment-825816328 Cheers, -- Santiago signature.asc Description: PGP signature
Bug#991463: new upstream (5.3.2) with nsec3 (potential DoS) fixes
Hi Daniel, El 24/07/21 a las 19:20, Daniel Baumann escribió: > Package: knot-resolver > Version: 5.3.1-1 > > Hi, > > it would be nice if you could upload the current upstream release to > experimental and cherry-pick the necessary fixes for bullseye. ... Just to be sure: the related changes are these? https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1169/diffs Is there any CVE or bug report filed for that potential DoS ? Cheers, -- Santiago signature.asc Description: PGP signature
