Bug#1065247: new lighttpd servers mangled file names
FYI, I submitted a patch to Debian on 19 March, over two months ago. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067126 It has taken Debian developers (volunteers) over 10 weeks (!!!) to pick up a simple patch that I packaged for them and signed on salsa.debian.org. :(
Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server
Gianfranco, thank you for sponsoring this upload. > Please some nitpicks for a future upload > 1) wait for the sponsor upload before tagging, >many of your entries were never uploaded ack. Still, this seems like unnecessary latency between humans once a Debian developer volunteer picks up the sponsorship-request. This sponsorship-request bug was filed March 19 and as I write this, today is May 29, over two months later. > 2) don't create new entries if the previous ones are not yet in the archive Should the now-incorrect tags in the repository be deleted and re-tagged? I prefer not to move tags once the tag matches code on the master branch, hence why I created new entries in the changelog and new tags. Also, this sounds like a fragile limitation for which a bug should be filed. When uploading, it should be possible to programmatically query the current version in the archive, find that changelog entry, and then process the newer entries with versions between the current version in the archive and the new version being submitted. Cheers, Glenn
Bug#1067126: RFS: lighttpd/1.4.76-3 -- light, fast, functional web server
lighttpd-1.4.76-3 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-3 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-3) unstable; urgency=medium * Patch to fix graceful shutdown timeout
Bug#1067126: RFS: lighttpd/1.4.76-2 -- light, fast, functional web server
lighttpd-1.4.76-2 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-2 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-2) unstable; urgency=medium * Fix FTBFS Linux on SPARC * Declare compliance with policy 4.7.0 - no changes needed.
Bug#1067126: RFS: lighttpd/1.4.76-1 -- light, fast, functional web server
lighttpd-1.4.76-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.76-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 lighttpd (1.4.76-1) unstable; urgency=medium * New upstream version 1.4.76 * Detect VU#421644 HTTP/2 CONTINUATION Flood * Avoid CVE-2024-3094 xz supply chain attack
Bug#1067126: RFS: lighttpd/1.4.75-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.75-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.75-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Thank you. Glenn P.S. There is a regression in lighttpd 1.4.74 that is fixed with a patch in tag lighttpd-1.4.74-3 on salsa.d.o. Does that need to go through the release process for the changelog entries to automatically close bugs? If so, please upload 1.4.74-3 to Unstable, and in a few days 1.4.75-1. With the time64 migration, everything is stuck in Unstable, anyway. Note: with lighttpd 1.4.74-3, lighttpd is time64 agnostic and so this package could safely go to Testing, and will work properly (with 64-bit time_t) on 32-bit platforms even without the rest of the time64 libs.
Bug#1064572: RFS: lighttpd/1.4.74-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.74-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.74-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Thank you. Glenn
Bug#1057385: lighttpd FTCBFS: host CFLAGS leak into build compiler invocation
On Mon, Dec 04, 2023 at 11:49:30AM +0100, Emanuele Rocca wrote: > With the attached patch lighttpd cleanly cross-builds from source. Thanks, Emanuele. A slightly different patch: https://salsa.debian.org/debian/lighttpd/-/commit/a7d695d59c9a8bffe154aae29e335102beaaf3f2 was committed a few weeks ago to salsa.debian.org, which I based off comments in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021292? Is your suggested approach (above) preferred to this patch (below)? @@ -50,9 +50,9 @@ override_dh_auto_configure: --with-xxhash \ --with-zstd \ $(if $(filter pkg.lighttpd.libunwind,$(DEB_BUILD_PROFILES)),--with-libunwind) \ - CFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CFLAGS)" \ - LDFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get LDFLAGS)" \ - CPPFLAGS_FOR_BUILD="$(shell dpkg-buildflags --get CPPFLAGS)" \ + CFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CFLAGS)" \ + LDFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get LDFLAGS)" \ + CPPFLAGS_FOR_BUILD="$$(dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dpkg-buildflags --get CPPFLAGS)" \ override_dh_install: cp NEWS debian/tmp/changelog
Bug#1055131: RFS: lighttpd/1.4.73-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.73-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.73-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Important changes in lighttpd 1.4.73: * HTTP/2 detect and log rapid reset attack While lighttpd is not affected by HTTP/2 rapid reset attacks any more than by other DoS attacks, changes have been made to lighttpd to detect and log when a rapid reset attack occurs, and to close the HTTP/2 connection. Log watchers might subsequently use the trace to block IPs. The goal is to make lightpd 1.4.73 available in unstable, testing, and then backports (or sloppy-backports) to maintained Debian versions. Please advise next steps. Thank you. Glenn P.S. The version of lighttpd in Debian Experimental is 1.4.71-1+exp1 and can be retired.
Bug#1040525: Lighttpd disregards ssl.dh-file setting
Repeating: lighttpd TLS configuration recommendations supercede the issue reported here. (https://wiki.lighttpd.net/Docs_SSL) > I now removed that cipher list (falling back to the default), and this > disabled the 2 remaining ciphers (DHE-RSA-AES256-GCM-SHA384 and > DHE-RSA-AES128-GCM-SHA256) that used Diffie Hellman :-) As you noticed, using the lighttpd TLS configuration recommendations does not include the ciphers using the finite field Diffie-Hellman parameters which caused Nexpose to generate warnings. --- Regarding the DH parameters used by default by lighttpd when finite field Diffie-Hellman parameters are used: > > Please clarify why you think this is insecure. > I trust Nexpose on this one. The theory goes that any "standard" > parameter is insecure, as a would be attacker would only need to "crack" > it once, and then be able to use it against a huge number of sites. I trust the published RFCs by experts more than I trust Nexpose. > I'm not really sure that it is a good idea to rely on *any* standard > Diffie-Hellman parameters :-( I'm not familiar with your expertise in this security area. What are your credentials that would give weight to your opinion? On the contrary: While there is the theoretical possibility of the well-known standard parameters being cracked, there are different potential pitfalls for generating custom parameters and then not cryptographically analyzing those custom parameters for weaknesses. It does not appear that you are performing that analysis on your custom parameters, and so my recommendation is to use the standard parameters which have been analyzed by experts for weaknesses. That does not guarantee safety, but does add more confidence to safety of the standard parameters when compared to custom parameters lacking expert analysis for weaknesses. As you have outsourced your security analysis to Nexpose, I recommend you follow up with Nexpose for more detailed guidance. I suggest that removing those ciphers is best practices at this point, unless you must support older clients which do not support more modern ciphers. If you still trust Nexpose more than other experts, I urge you to reconsider. Do you think Nexpose knows better than the OpenSSL developers? `man SSL_CTX_set_dh_auto` ``` Typically applications should use well know DH parameters that have built-in support in OpenSSL. The macros SSL_CTX_set_dh_auto() and SSL_set_dh_auto() configure OpenSSL to use the default built-in DH parameters for the SSL_CTX and SSL objects respectively. Passing a value of 1 in the onoff parameter switches the feature on, and passing a value of 0 switches it off. The default setting is off. If "auto" DH parameters are switched on then the parameters will be selected to be consistent with the size of the key associated with the server's certificate. If there is no certificate (e.g. for PSK ciphersuites), then it it will be consistent with the size of the negotiated symmetric cipher key. Applications may supply their own DH parameters instead of using the built-in values. This approach is discouraged and applications should in preference use the built-in parameter support described above. ``` Note: other TLS libraries such as GnuTLS use the expert-recommended standard parameters and no longer provide an option to set custom DH parameters. ``` Prior to GnuTLS 3.6.0 for the ephemeral or anonymous Diffie-Hellman (DH) TLS ciphersuites the application was required to generate or provide DH parameters. That is no longer necessary as GnuTLS utilizes DH parameters and negotiation from [RFC7919]. ``` --- Issue resolution: Since lighttpd 1.4.60, lighttpd switches on SSL_CTX_set_dh_auto() in lighttpd mod_openssl, and this causes openssl to ignore "DHParameters" even when explicitly set. This will be fixed in lighttpd 1.4.72. In lighttpd 1.4.72, if you explicitly set "DHParameters", lighttpd will switch off SSL_CTX_set_dh_auto() so that openssl will honor the user-supplied parameters. Even so, the expert recommendation is to allow openssl 3.0.0 and later to select the DH parameters (which lighttpd does by enabling SSL_CTX_set_dh_auto()).
Bug#1034586: always reports inactive/expired certificate on armhf
Marco, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1040525: Lighttpd disregards ssl.dh-file setting
On Fri, Jul 07, 2023 at 09:28:24AM +, Alain Knaff wrote: > Package: lighttpd > Version: 1.4.69-1 > > Since our upgrade to Debian 12, lighttpd now uses insecure > Diffie-Hellman parameters > c90fdaa22168c234c4c6628b80dc1cd129024e088a67cc74020bbea63 > b139b22514a08798e3404ddef9519b3cd3a431b302b0a6df25f14374fe1356d6d5 > 1c245e485b576625e7ec6f44c42e9a637ed6b0bff5cb6f406b7edee386bfb5a899f > a5ae9f24117c4b1fe649286651ece45b3dc2007cb8a163bf0598da48361c55d39 > a69163fa8fd24cf5f83655d23dca3ad961c62f356208552bb9ed529077096966d6 > 70c354e4abc9804f1746c08ca18217c32905e462e36ce3be39e772c180e86039b > 2783a2ec07a28fb5c55df06f4c52c9de2bcbf6955817183995497cea956ae515d2 > 261898fa051015728e5a8aaac42dad33170d04507a33a85521abdf1cba64ecfb8 > 50458dbef0a8aea71575d060c7db3970f85a6e1e4c7abf5ae8cdb0933d71e8c94 > e04a25619dcee3d2261ad2ee6bf12ffa06d98a0864d87602733ec86a64521f2b18 > 177b200cbbe117577a615d6c770988c0bad946e208e24fa074e5ab3143db5bfce > 0fd108e4b82d120a92108011a723c12a787e6d788719a10bdba5b2699c327186 > af4e23c1a946834b6150bda2583e9ca2ad44ce8dbbbc2db04de8ef92e8efc141fb > ecaa6287c59474e6bc05d99b2964fa090c3a2233ba186515be7ed1f612970cee2 > d7afb81bdd762170481cd0069127d5b05aa993b4ea988d8fddc186ffb7dc90a6c0 > 8f4df435c934063199 What are you sharing? What command did you use to obtain this info? Please clarify why you think this is insecure. This does not look like lighttpd mod_openssl default DH parameters used since lighttpd 1.4.56. Since lighttpd 1.4.56, lighttpd mod_openssl configures default DH parameters to use RFC 7919 FFDHE2048 2048-bit group https://git.lighttpd.net/lighttpd/lighttpd1.4/commit/10c65e88f773d361db48e0135e1f4be3a932bf83 RFC 7919: https://datatracker.ietf.org/doc/html/rfc7919#appendix-A.1 Nowadays, FFDHE3072 is preferred, and a future version of lighttpd may change lighttpd mod_openssl to use FFDHE3072 by default in the future. Please note: if using GnuTLS (with lighttpd mod_gnutls) or using mbedTLS (with lighttpd mod_mbedtls), the Diffie-Hellman group is chosen to be secure according to RFC7919 DH parameter negotiation, and there is no default set by lighttpd. > And this despite having pointed ssl.dh-file to a self generated dh param > file, as described in https://weakdh.org/sysadmin.html That page is out-dated, at least for lighttpd. Since lighttpd 1.4.68, if you are using ssl.cipher-list specified in https://weakdh.org/sysadmin.html, then you are WEAKENING the cipher list now used by default since lighttpd 1.4.68. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 > In Debian 11, an identical configuration was using our locally generated > secure dh parameters. Since lighttpd 1.4.65 (released Jun 2022), lighttpd has been announcing the future scheduled removal of ssl.dh-file. https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_65 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_66 https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_67 The removal of ssl.dh-file occurred in lighttpd 1.4.68 (Jan 2023) https://redmine.lighttpd.net/projects/lighttpd/wiki/release-1_4_68 As linked in the lighttpd release notes: See https://wiki.lighttpd.net/Docs_SSL for replacements with `ssl.openssl.ssl-conf-cmd`, but prefer lighttpd defaults instead. Since lighttpd 1.4.68, use ssl.openssl.ssl-conf-cmd "DHParameters" to specify your own DH parameters file, as ssl.dh-file has been removed. If you have custom DH parameters, then please review RFC7919 and modern security papers to make sure what you think is secure is still considered secure by experts, as the use of parameters derived from "safe" primes is strongly recommended. It is my understanding that FFDHE3072 is the current recommendation if you are going to set explicit DH parameters. Cheers, Glenn
Bug#1037099: RFS: lighttpd/1.4.71-1 -- light, fast, functional web server
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: gs-bugs.debian@gluelogic.com Dear mentors, I am looking for a DD sponsor for my package "lighttpd": https://salsa.debian.org/debian/lighttpd/ I am an upstream lighttpd developer and have participated in maintaining lighttpd on Debian for a number of years. I am listed as an uploader on https://tracker.debian.org/pkg/lighttpd lighttpd-1.4.71-1 passes autopkgtests and expected CI tests, and is tagged. (This is a non-DD maintainer upload.) * Package name : lighttpd Version : 1.4.71-1 Upstream contact : team+light...@tracker.debian.org * URL : https://lighttpd.net/ * License : BSD-3-Clause * Vcs : https://git.lighttpd.net/lighttpd/lighttpd1.4 Similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036020 for lighttpd 1.4.70, this currently targets experimental, though I would like to get this into testing and into Bookworm in due time. Please advise. Thank you. Glenn
Bug#1034586: always reports inactive/expired certificate on armhf
Macro, please review my previous messages and try to help provide additional information. Thank you. Glenn
Bug#1035926: lighttpd conf-enabled files cannot override IPV6 port number
On Thu, May 11, 2023 at 11:49:21AM +0200, Michael Moore wrote: ... > Issue and suggested fix: > === > In lighttpd.conf the includes for conf-enabled/*.conf happens after passing > server.port to the use-ipv6.pl script. Re-ordering these lines so that the > conf files are included first allows the server.port value to be > overridden. > > include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port > include_shell "/usr/share/lighttpd/create-mime.conf.pl" > include "/etc/lighttpd/conf-enabled/*.conf" Thank you for the thorough description. Yes, I agree with your suggestion. use-ipv6.pl is simple and its output can be placed anywhere in lighttpd.conf. Therefore, it should be safe to move to follow conf-enabled/*.conf I'll mark this fixed once the change is included in a release. Cheers, Glenn
Bug#979308: This Bug is already fixed in Ubuntu
Ubuntu fixed this bug with jq (1.6-2.1ubuntu1) hirsute; urgency=medium [ Alex Murray ] * Fix fromdate when local time is during daylight savings (LP: #1910162) - d/p/fix-ftbfs-when-localtime-is-dst.patch: Backport upstream patch which ensures fromdate uses the correct time during daylight savings -- Christian Ehrhardt Tue, 05 Jan 2021 08:03:50 +0100
Bug#1023697: can wolfssl bug be closed?
Can this be closed? Are there any action items remaining for this bug? I am still getting messages that packages depending on wolfssl are "marked for autoremoval from testing on 2023-01-27" Thank you. Glenn
Bug#1021021: wolfssl: CVE-2022-38152 CVE-2022-38153 CVE-2022-39173
> I plan to upload version 5.5.1 in the near future. Felix, a month has passed and we are still waiting for an upload. Failure to upload a version with security fixes within the next few days will result in wolfssl and packages which depend on wolfssl to be removed from Debian Testing. Please act accordingly and please look to engage others to help you to maintain wolfssl in Debian. Security fixes should not be unduly delayed. Thank you. Glenn
Bug#938987: Overly restrictive CapabilityBoundingSet
Thank you very much! Adding CAP_DAC_OVERRIDE solved it for me as well. Not sure how many hours it would have taken for me to figure it out. Does systemd or the linux kernel log capability violations somewhere? (is it even possible) smime.p7s Description: S/MIME Cryptographic Signature
Bug#592834: grub-efi-amd64: File descriptor leaked on lvs invocation
Hey there, got this warning, dunno why, never read this before. Here's what I did before I got this warning. Be aware that I use parrot 4.6, which is based on debian but is a rolling distribution. The not upgraded (helt back) packages are some nvidia packages, not needed on my system (no nvidia card installed). They has nothing to do with grub. Maybe this helps you to recreate this issue. grub-efi-amd64 2.04-1parrot1 ┌─[anonymous@parrot]─[~] └──╼$ apt search grub | grep installed WARNING: apt does not have a stable CLI interface. Use with caution in scripts. grub-common/rolling,now 2.04-1parrot1 amd64 [installed] grub-efi-amd64/rolling,now 2.04-1parrot1 amd64 [installed] grub-efi-amd64-bin/rolling,now 2.04-1parrot1 amd64 [installed,automatic] grub-imageboot/rolling,rolling,now 0.6 all [installed] grub2-common/rolling,now 2.04-1parrot1 amd64 [installed,automatic] hashcat/rolling,now 5.1.0+ds1-1 amd64 [installed,automatic] ┌─[anonymous@parrot]─[~] └──╼$ sudo apt install grub-imageboot [sudo] password for anonymous: Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: syslinux-common The following NEW packages will be installed: grub-imageboot syslinux-common 0 upgraded, 2 newly installed, 0 to remove and 16 not upgraded. Need to get 1,242 kB of archives. After this operation, 3,619 kB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 https://ftp.halifax.rwth-aachen.de/parrotsec rolling/main amd64 syslinux-common all 3:6.04~git20190206.bf6db5b4+dfsg1-1 [1,237 kB] Get:2 https://ftp.halifax.rwth-aachen.de/parrotsec rolling/main amd64 grub-imageboot all 0.6 [4,354 B] Fetched 1,242 kB in 2s (710 kB/s) Selecting previously unselected package syslinux-common. (Reading database ... 333752 files and directories currently installed.) Preparing to unpack .../syslinux-common_3%3a6.04~git20190206.bf6db5b4+dfsg1-1_all.deb ... Unpacking syslinux-common (3:6.04~git20190206.bf6db5b4+dfsg1-1) ... Selecting previously unselected package grub-imageboot. Preparing to unpack .../grub-imageboot_0.6_all.deb ... Unpacking grub-imageboot (0.6) ... Setting up syslinux-common (3:6.04~git20190206.bf6db5b4+dfsg1-1) ... Setting up grub-imageboot (0.6) ... Copy syslinux memdisk to /boot/memdisk Scanning application launchers Updating active launchers Done ┌─[anonymous@parrot]─[~] └──╼$ sudo apt purge memtest86+ Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be REMOVED: memtest86+* 0 upgraded, 0 newly installed, 1 to remove and 16 not upgraded. After this operation, 2,449 kB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 333972 files and directories currently installed.) Removing memtest86+ (5.01-3+b1) ... Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64 Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64 Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64 Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64 Adding boot menu entry for EFI firmware configuration Found memdisk: /memdisk Imagepath /boot/images not found done (Reading database ... 333955 files and directories currently installed.) Purging configuration files for memtest86+ (5.01-3+b1) ... Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64 Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64 Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64 Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64 Adding boot menu entry for EFI firmware configuration Found memdisk: /memdisk Imagepath /boot/images not found done Generating grub configuration file ... Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-5.1.0-parrot1-3t-amd64 Found initrd image: /boot/initrd.img-5.1.0-parrot1-3t-amd64 Found linux image: /boot/vmlinuz-4.19.37-6parrot2-amd64 Found initrd image: /boot/initrd.img-4.19.37-6parrot2-amd64 Adding boot menu entry for EFI firmware configuration Found memdisk: /memdisk Imagepath /boot/images not found done Scanning application launchers Updating active launchers Done ┌─[✗]─[anonymous@parrot]─[~] └──╼$ sudo apt install memtest86+ Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: hwtools memtester kernel-patch-badram memtest86 grub-pc | grub-legacy The following NEW packages will be installed: memtest86+ 0 upgraded, 1 newly installed, 0 to remove and 16 not upgraded. Need to get 78.1 kB of archives. After this operation, 2,449 kB of additional disk space will be used. Get:1 https://mirror.yandex.ru/mirrors/parrot rolling/main amd64 memtest86+ amd64 5.01-3+b1 [78.1 kB]
Bug#825748: (no subject)
Additionnal informations:
python
Python 2.7.11+ (default, May 9 2016, 15:54:33)
[GCC 5.3.1 20160429] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests; requests.__version__.split('.')
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.7/dist-packages/requests/__init__.py", line
61, in
from .packages.urllib3.exceptions import DependencyWarning
ImportError: cannot import name DependencyWarning
Bug#323032: Same problem two years later with the last upgrade
Hello, right after this morning last upgrade, my proftp server and my webmin stopped to work throwing out these errors : /var/log/webmin/miniserv.error:/usr/bin/perl: relocation error: /lib/libresolv.so.2: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference And (accepting connections): relocation error: /lib/libresolv.so.2: symbol __res_iclose, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference I just had to restart those services then everything worked well... Perhaps the upgrade script for libc6 should look which running services are using libc6 and restart them ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
