Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1
El 07/05/23 a las 10:53, Paul Gevers escribió: > Hi, > > On 18-04-2023 14:11, Santiago R.R. wrote: > > unblock isc-dhcp/4.4.3-P1-1.1 > > done and aged. Thanks. Thanks to you! -- Santiago signature.asc Description: PGP signature
Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1
El 27/04/23 a las 07:36, Paul Gevers escribió: > Control: tags -1 confirmed moreinfo > Control: retitle -1 unblock: isc-dhcp/4.4.3-P1-2 > > On 18-04-2023 14:11, Santiago R.R. wrote: > > 2. This is the autopkgtest included in this request applied to the > > current version in testing: > > Minor question: I *think* you are configuring the test to use the internet > (nameserver 8.8.8.8). If that's true, please add the `needs-internet` > restriction. (Or maybe it doesn't need to be configured like that. Not really. The test just tests if the namespace's resolv.conf is finally (over)written with the nameserver provided by the dhcp server. No DNS queries are done during the test, even less querying any resolver on internet. I don't see the need to add the `needs-internet` restriction, but please let me know if you think otherwise. > > > unblock isc-dhcp/4.4.3-P1-1.1 > > That version is already in testing. I have fixed the title too (which, for > next time, could have done with the word `pre-approval` or similar). Thanks. I just let reportbug fill that version. And I always forgot the unblock semantics. > > Anyways, please go ahead. > Thank you. I'll just wait your opinion about the above mentioned restriction. > Paul Cheers, -- S
Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: isc-d...@packages.debian.org Control: affects -1 + src:isc-dhcp Dear Release Team, Please unblock package isc-dhcp [ Reason ] Two main reasons: 1. Include a NEWS entry to help users to be aware ISC DHCP Server has been EOL'ed by upstream. 2. Solve https://bugs.debian.org/1034502 so dhclient can handle resolv.conf inside network namespaces. The proposed changes include an autopkgtest to test this. [ Impact ] 1. Less chances for the users to be aware of the end of upstream support for a very important software. 2. Users or application using dhclient inside a network namespace would continue to have issues with the DNS resolution. See: https://stackoverflow.com/questions/38102481/how-can-dhclient-be-made-namespace-aware [ Tests ] 1. Doesn't really need a test. The NEWS entry would be displayed during upgrading if apt-listchanges is available. 2. This is the autopkgtest included in this request applied to the current version in testing: https://salsa.debian.org/santiago/isc-dhcp/-/jobs/4144234#L324 And this is for the proposed version: https://salsa.debian.org/santiago/isc-dhcp/-/jobs/4144350 [ Risks ] 1. There is no risk. 2. Code is trivial. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] There is minor (and harmless) change: [ Bastian Germann ] * d/copyright Format: Add trailing slash that I include since it was part of the default git branch. I keep it to make it easier to handle changes in the future. Also, I've uploaded these changes to experimental. Thanks! -- Santiago unblock isc-dhcp/4.4.3-P1-1.1 diff -Nru isc-dhcp-4.4.3-P1/debian/changelog isc-dhcp-4.4.3-P1/debian/changelog --- isc-dhcp-4.4.3-P1/debian/changelog 2023-01-09 10:15:41.0 +0100 +++ isc-dhcp-4.4.3-P1/debian/changelog 2023-04-17 14:20:02.0 +0200 @@ -1,3 +1,17 @@ +isc-dhcp (4.4.3-P1-2) unstable; urgency=medium + + [ Gabriel Potter ] + * Support bound /etc/resolv.conf (Closes: #1034502) + + [ Bastian Germann ] + * d/copyright Format: Add trailing slash + + [ Santiago Ruano Rincón ] + * Add NEWS about isc-dhcp-server EOL'ed and its apparmor profile + * Test debian/tests/client-server + + -- Santiago Ruano Rincón Mon, 17 Apr 2023 14:20:02 +0200 + isc-dhcp (4.4.3-P1-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru isc-dhcp-4.4.3-P1/debian/copyright isc-dhcp-4.4.3-P1/debian/copyright --- isc-dhcp-4.4.3-P1/debian/copyright 2023-01-09 09:25:59.0 +0100 +++ isc-dhcp-4.4.3-P1/debian/copyright 2023-04-17 13:50:46.0 +0200 @@ -1,4 +1,4 @@ -Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0 +Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Source: https://www.isc.org/downloads/dhcp Files: * diff -Nru isc-dhcp-4.4.3-P1/debian/dhclient-script.linux isc-dhcp-4.4.3-P1/debian/dhclient-script.linux --- isc-dhcp-4.4.3-P1/debian/dhclient-script.linux 2023-01-09 09:27:37.0 +0100 +++ isc-dhcp-4.4.3-P1/debian/dhclient-script.linux 2023-04-17 13:50:46.0 +0200 @@ -84,7 +84,9 @@ chown --reference=$resolv_conf $new_resolv_conf chmod --reference=$resolv_conf $new_resolv_conf fi -mv -f $new_resolv_conf $resolv_conf + # cat then rm to handle binds (e.g. ip netns exec) + cat $new_resolv_conf > $resolv_conf + rm -f $new_resolv_conf # DHCPv6 elif [ -n "$new_dhcp6_domain_search" ] || [ -n "$new_dhcp6_name_servers" ]; then resolv_conf=$(readlink -f "/etc/resolv.conf" 2>/dev/null) || @@ -115,7 +117,8 @@ chown --reference=$resolv_conf $new_resolv_conf chmod --reference=$resolv_conf $new_resolv_conf fi -mv -f $new_resolv_conf $resolv_conf + cat $new_resolv_conf > $resolv_conf + rm -f $new_resolv_conf fi } diff -Nru isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS --- isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS 2023-01-09 09:25:59.0 +0100 +++ isc-dhcp-4.4.3-P1/debian/isc-dhcp-server.NEWS 2023-04-17 13:50:46.0 +0200 @@ -1,3 +1,24 @@ +isc-dhcp-server (4.4.3-P1-2) unstable; urgency=medium + + # ISC DHCP completely EOL + + ISC has stopped maintaining the server component of isc-dhcp since October + 2022. A similar decision was made for the client and relay parts earlier the + same year. ISC DHCP Server users are strongly encouraged to look for an + alternative. + + More information can be found in these official announcements: + https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html + https://www.isc.org/blogs/isc-dhcp-eol/ + + # AppArmor support + + Since 4.4.3-P1-1.1, isc-dhcp-server includes an apparmor profile (thanks +
Bug#1034502: dhclient-script doesn't handle resolv.conf in network namespaces
Package: isc-dhcp-client Version: 4.4.3-P1-1.1 Severity: important Tags: patch pending As described in this merged MR [0], dhclient-script fails to handle the resolv.conf when an dhclient is called inside a network namespace. [0] https://salsa.debian.org/debian/isc-dhcp/-/merge_requests/8 This is an example from an autopkgetst [1] (to be merged): ip netns exec client dhclient ptp-veth-client mv: cannot move '/etc/resolv.conf.dhclient-new.1207' to '/etc/resolv.conf': Device or resource busy [1] https://salsa.debian.org/santiago/isc-dhcp/-/jobs/4139012#L323 Cheers, -- Santiago -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-0-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_UNSIGNED_MODULE, TAINT_LIVEPATCH 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 isc-dhcp-client depends on: ii debianutils 5.7-0.4 ii iproute2 6.1.0-2 ii libc62.36-8 Versions of packages isc-dhcp-client recommends: ii isc-dhcp-common 4.4.3-P1-1.1 Versions of packages isc-dhcp-client suggests: ii avahi-autoipd 0.8-9 pn isc-dhcp-client-ddns pn resolvconf -- Configuration Files: /etc/apparmor.d/sbin.dhclient changed [not included] -- no debconf information signature.asc Description: PGP signature
Bug#1033235: torbrowser launcher fails to start due to an non-empty directory
Package: torbrowser-launcher Version: 0.3.6-2 Severity: important Hi! When trying to launch torbrowser, I am getting this: santiago@bartik ~> torbrowser-launcher Tor Browser Launcher By Micah Lee, licensed under MIT version 0.3.6 https://github.com/micahflee/torbrowser-launcher Traceback (most recent call last): File "/usr/bin/torbrowser-launcher", line 30, in torbrowser_launcher.main() File "/usr/lib/python3/dist-packages/torbrowser_launcher/__init__.py", line 76, in main common = Common(tor_browser_launcher_version) File "/usr/lib/python3/dist-packages/torbrowser_launcher/common.py", line 62, in __init__ self.torbrowser12_rename_old_tbb() File "/usr/lib/python3/dist-packages/torbrowser_launcher/common.py", line 185, in torbrowser12_rename_old_tbb os.rename(abs_filename, self.paths["tbb"]["dir_tbb"]) OSError: [Errno 39] Directory not empty: '/home/santiago/.local/share/torbrowser/tbb/x86_64/tor-browser_es-AR' -> '/home/santiago/.local/share/torbrowser/tbb/x86_64/tor-browser' I get a similar error with torbrowser-launcher --settings The workaround is to remove .local/share/torbrowser/ I may suppose this is just me, and it works for others. Cheers, -- Santiago -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-0-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE 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 torbrowser-launcher depends on: ii ca-certificates20211016 ii gnupg 2.2.40-1 ii libdbus-glib-1-2 0.112-3 ii libgtk-3-0 3.24.36-4 ii python33.11.2-1 ii python3-gpg1.18.0-3+b1 ii python3-packaging 23.0-1 ii python3-pyqt5 5.15.9+dfsg-1 ii python3-requests 2.28.1+dfsg-1 ii python3-socks 1.7.1+dfsg-1 Versions of packages torbrowser-launcher recommends: ii tor 0.4.7.13-1 Versions of packages torbrowser-launcher suggests: ii apparmor 3.0.8-3 -- no debconf information
Bug#1024328: closed by Debian FTP Masters (reply to Salvatore Bonaccorso ) (Bug#1024328: fixed in linux 6.0.10-1)
Dear Salvatore, FWIW, the patch has been added to the 6.0-stable tree. It is now in the queue-6.0: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-6.0/net-cdc_ncm-fix-multicast-rx-support-for-cdc-ncm-dev.patch Cheers, -- Santiago signature.asc Description: PGP signature
Bug#1024328: IPv6 connectivity broken with 6.0.x. RAs seem to be dropped for the CDC_NCM interface
Package: src:linux Version: 6.0.8-1 Severity: important Tags: ipv6 Control: Found -1 6.1~rc3-1~exp1 Dear linux maintainers, The related machine to this bug is connected to the network via a Dell D6000 USB-C docking station. Since a recent linux-image-amd64 update, it cannot reach external networks on IPv6. It is able to autoconfigure an IPv6 address, but it doesn't get any answer to the router sollicitations messages, so it is not able to configure any default route. A WiFi interface successfully configures its ip6 route, running on the same kernel. The problem didn't exist on 5.x, since 5.9 (when IP6 multicast support for cdc_ncm was fixed). I've just checked with linux-image-5.10.0-12-amd64. And the problem is also present in linux-image-6.1.0-0-amd64 6.1~rc3-1~exp1. Concerned devices is: *-network description: Ethernet interface physical id: 14 bus info: usb@2:1.1 logical name: enxabcdef123456 serial: ab:cd:ef:12:34:56 size: 100Mbit/s capabilities: ethernet physical configuration: autonegotiation=off broadcast=yes driver=cdc_ncm driverversion=6.0.0-4-amd64 duplex=half firmware=CDC NCM (SEND ZLP) ip=x.x.x.x link=yes multicast=yes port=twisted pair speed=100Mbit/s Cheers, -- S -- Package-specific info: ** Version: Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11) ** Command line: BOOT_IMAGE=/vmlinuz-6.0.0-4-amd64 root=/dev/mapper/bartik--vg-root ro quiet ** Not tainted ** Kernel log: [ 12.633673] iwlwifi :02:00.0: firmware: direct-loading firmware iwlwifi-8265-36.ucode [ 12.634019] iwlwifi :02:00.0: loaded firmware version 36.ca7b901d.0 8265-36.ucode op_mode iwlmvm [ 12.672303] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3246: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 12.672306] snd_hda_codec_realtek hdaudioC1D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 12.672308] snd_hda_codec_realtek hdaudioC1D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 12.672310] snd_hda_codec_realtek hdaudioC1D0:mono: mono_out=0x0 [ 12.672311] snd_hda_codec_realtek hdaudioC1D0:inputs: [ 12.672312] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x19 [ 12.672313] snd_hda_codec_realtek hdaudioC1D0: Headphone Mic=0x1a [ 12.672314] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 [ 12.704042] intel_rapl_common: Found RAPL domain package [ 12.704045] intel_rapl_common: Found RAPL domain core [ 12.704046] intel_rapl_common: Found RAPL domain uncore [ 12.704048] intel_rapl_common: Found RAPL domain dram [ 12.704049] intel_rapl_common: Found RAPL domain psys [ 12.771464] mei_hdcp :00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound :00:02.0 (ops i915_hdcp_component_ops [i915]) [ 12.802604] Bluetooth: Core ver 2.22 [ 12.802625] NET: Registered PF_BLUETOOTH protocol family [ 12.802626] Bluetooth: HCI device and connection manager initialized [ 12.802629] Bluetooth: HCI socket layer initialized [ 12.802630] Bluetooth: L2CAP socket layer initialized [ 12.802633] Bluetooth: SCO socket layer initialized [ 12.897269] dell_laptop: Using i8042 filter function for receiving events [ 12.919215] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230 [ 12.919268] thermal thermal_zone8: failed to read out thermal zone (-61) [ 12.982819] iwlwifi :02:00.0: base HW address: 18:1d:ea:6d:5f:56, OTP minor version: 0x0 [ 13.061505] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [ 13.081186] usbcore: registered new interface driver btusb [ 13.082374] Bluetooth: hci0: Firmware revision 0.1 build 19 week 44 2021 [ 13.085593] iwlwifi :02:00.0 wlp2s0: renamed from wlan0 [ 13.138032] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 subsystem [ 13.138813] EXT4-fs (nvme0n1p2): mounted filesystem without journal. Quota mode: none. [ 13.138822] ext2 filesystem being mounted at /boot supports timestamps until 2038 (0x7fff) [ 13.142725] EXT4-fs (dm-2): mounted filesystem with ordered data mode. Quota mode: none. [ 13.298521] audit: type=1400 audit(1668698064.713:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="firejail-default" pid=686 comm="apparmor_parser" [ 13.300258] audit: type=1400 audit(1668698064.717:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=688 comm="apparmor_parser" [ 13.301053] audit: type=1400 audit(1668698064.717:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=690 comm="apparmor_parser" [ 13.301058] audit: type=1400 audit(1668698064.717:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=690 comm="apparmor_parser" [ 13.303175] audit: type=1400 audit(1668698064.717:6):
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
El 16/09/22 a las 09:39, Emilio Pozuelo Monfort escribió: > Hi Santiago, > > On 15/09/2022 09:52, Emilio Pozuelo Monfort wrote: > > On 14/09/2022 15:42, Santiago R.R. wrote: > > > El 14/09/22 a las 13:58, Emilio Pozuelo Monfort escribió: > > > > On 13/09/2022 16:46, Sylvain Beucler wrote: > > > > > Hi, > > > > > > > > > > IIUC this is about fixing 2 non-security bugs, that were introduced > > > > > prior to buster's initial release. > > > > > > > > > > I personally don't think this fits the LTS project scope. > > > > > Maybe other LTS members will have a different opinion. > > > > > > > > We've had bugfix updates from time to time. They are rare, but not > > > > forbidden. This should go in a buster suite rather than > > > > buster-security, but > > > > since there's no such suite for LTS, having it in buster-security is the > > > > lesser evil. Of course we shouldn't flood -security with bug fixes, if > > > > that > > > > was necessary we should consider keeping $stable open and handled by > > > > the LTS > > > > team (but that doesn't seem necessary at this point). > > > > > > > > In this case, since the update has been prepared and looks sensible, > > > > I'll go > > > > ahead with the upload if nobody objects. > > > > > > > > > > Thanks, Emilio. Also consider > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961654#15 > > > > > > Haven't tested yet myself. But I suppose I should apply it in unstable. > > > > For buster I'd rather use what was proposed for buster-pu, as that's > > also what is in bullseye. > > I have uploaded that, with a s/buster/&-security/ in d/changelog, and fixing > your name to be UTF-8. Thanks! , -- Santiago signature.asc Description: PGP signature
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
El 14/09/22 a las 13:58, Emilio Pozuelo Monfort escribió: > On 13/09/2022 16:46, Sylvain Beucler wrote: > > Hi, > > > > IIUC this is about fixing 2 non-security bugs, that were introduced > > prior to buster's initial release. > > > > I personally don't think this fits the LTS project scope. > > Maybe other LTS members will have a different opinion. > > We've had bugfix updates from time to time. They are rare, but not > forbidden. This should go in a buster suite rather than buster-security, but > since there's no such suite for LTS, having it in buster-security is the > lesser evil. Of course we shouldn't flood -security with bug fixes, if that > was necessary we should consider keeping $stable open and handled by the LTS > team (but that doesn't seem necessary at this point). > > In this case, since the update has been prepared and looks sensible, I'll go > ahead with the upload if nobody objects. > Thanks, Emilio. Also consider https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961654#15 Haven't tested yet myself. But I suppose I should apply it in unstable. Cheers, -- S signature.asc Description: PGP signature
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
Hi, El 10/09/22 a las 19:11, Adam D. Barratt escribió: > On Wed, 2020-05-27 at 11:56 +0200, Santiago R.R. wrote: > > 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? > > > > Apologies for apparently letting this sit unanswered. (FTR there was a > reply from a non-SRM member 18 months ago.) And I am sorry I missed that answer. > > The final point release for buster has now happened, so any further > updates to packages in buster will need to be handled via LTS. I'm > therefore going to close this request now. [snip] I am forwarding this to the LTS folks, so they can decide about this change. Cheers, -- S signature.asc Description: PGP signature
Bug#1009107: node-npm-run-path tries to write file packaged by node-execa
Package: node-npm-run-path Version: 5.1.0+~4.0.0-5 Severity: serious Dear maintainer, I got this error when upgrading my system: Preparing to unpack .../node-npm-run-path_5.1.0+~4.0.0-5_all.deb ... Unpacking node-npm-run-path (5.1.0+~4.0.0-5) over (4.0.1-1) ... dpkg: error processing archive /var/cache/apt/archives/node-npm-run-path_5.1.0+~4.0.0-5_all.deb (--unpack): trying to overwrite '/usr/share/nodejs/path-key/index.d.ts', which is also in package node-execa 5.1.1+repack+~cs17.3.6-1 Errors were encountered while processing: /var/cache/apt/archives/node-npm-run-path_5.1.0+~4.0.0-5_all.deb You can reproduce it by trying to install both packages at the same time. Could you please take a look at it? Cheers, -- S -- 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.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) 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 node-npm-run-path depends on: iu node-execa [node-path-key] 5.1.1+repack+~cs17.3.6-1 node-npm-run-path recommends no packages. node-npm-run-path suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
Sorry for the delayed answer! El 05/03/22 a las 07:09, Martin-Éric Racine escribió: > On Sat, Mar 5, 2022 at 1:21 AM Santiago R.R. wrote: > > > > El 02/03/22 a las 19:10, Martin-Éric Racine escribió: > > > On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine > > > wrote: [...] > > > Please note that I have re-uploaded the package to Mentors. The log > > > file is more explicit about cosmetic changes and about ./configure > > > caveats. > > > > * Are you sure about this in debian/rules? > > > > + --libdir=/usr/lib/i386-linux-gnu \ > > > > At a first glance, I suppose that would break multiarch support. > > Without it, the udev backend goes in /lib, instead of /usr/lib like > the rest of the package. It's in the changelog: --prefix somehow > doesn't propagate as it should for --libdir and --mandir. > > > * I still don't feel fully comfortable with the cosmetic changes, > > specially with wrap-and-sort, for *this* NMU. According to my > > interpretation of developers-references, we should avoid that. > > Scott is still listed as Maintainer, even if the package hasn't been > > updated for a long time (hello MIA Team!). At the same time, I > > appreciate your work and I think the changes you are making should > > arrive into the debian archive sooner or later. > > > > Since I doubt, may I ask the MIA Team if it is OK to include cosmetic > > changes in an NMU for package that hasn't been orphaned? > > I definitely went a step beyond NMU because, asides from not having > tracked upstream, the package is seriously outdated and not up to > current best practices. As a ground rule, a package that hasn't > changed since oldstable definitely is up for a brush-up of its > packaging to bring it up to current Policy, even if no new upstream > has come. None of that has happened for this and a number of other > packages. If you want to go even further, it would be great if you think about an ITS ;-) > > I feel that this (and several more) packages should be investigated by > the MIA Team. The sheer amount of packages in the Debian archive that > haven't been updated since oldstable (or that barely received a random > cherry-picked patch from upstream Git applied by the security team) is > alarming. Debian's archive is rotting, and that's not a good sign, > considering how many distributions build their UI on top of Debian > packages. > I cannot talk for the MIA Team, but I am sure they do as best as they can. And maybe they need some help to spot those packages that urgently need love. > > * Your entry in d/copyright still doesn't follow the same (weird) > > indentation than previous contributors': > > > > Files: * > > Copyright: 2006-2018 Roy Marples > > @@ -61,6 +62,7 @@ > >2013 Christoph Egger > >2014 Salvatore Bonaccorso > >2015 Daniel Echeverry > > + 2022 Martin-Éric Racine > > License: BSD-2 > > I used wrap-and-sort for that. > So maybe wrap-and-sort is not clever enough. Expanding the tabs, this is how I see it on my machine: Files: debian/* Copyright: 2010-2013 Roy Marples 2013 Christoph Egger 2014 Salvatore Bonaccorso 2015 Daniel Echeverry 2022 Martin-Éric Racine License: BSD-2 Cheers, -- Santiago signature.asc Description: PGP signature
Bug#1006923: Add a method to append something to reprotest's build-command
Control: tags -1 + patch El 10/03/22 a las 12:30, Holger Levsen escribió: > Hi Santiago, > > On Tue, Mar 08, 2022 at 11:06:32AM +0100, Santiago R.R. wrote: > > Could reprotest have an --append-build-command option please? > > yes, please. patches most welcome, too! ;) Done :-) (Hoping it is OK) https://salsa.debian.org/reproducible-builds/reprotest/-/merge_requests/18 Cheers, -- Santiago signature.asc Description: PGP signature
Bug#1006923: Add a method to append something to reprotest's build-command
Package: reprotest Version: 0.7.19 Severity: wishlist X-Debbugs-Cc: debian-salsa...@alioth-lists.debian.net Hi there! Let's suppose that someone wants to pass some arguments to dpkg-buildpackage called by reprotest, as reported here: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/245 AFAICS, we could hack --build-command, but I would like to avoid hard-coding how reprotest calls dpkg-buildpackage. We could also use --auto-preset-expr, but is not something straightforward (e.g. you have to make sure the shell correctly interprets characters spaces in the PYTHON_EXPRESSION). Could reprotest have an --append-build-command option please? -- 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.15.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 reprotest depends on: ii apt-utils 2.4.0 ii libdpkg-perl 1.21.1 ii procps 2:3.3.17-6 ii python33.9.8-1 ii python3-debian 0.1.43 ii python3-distro 1.7.0-1 ii python3-pkg-resources 59.6.0-1.2 ii python3-rstr 2.2.6-3 Versions of packages reprotest recommends: ii diffoscope-minimal 206 ii disorderfs 0.5.11-2 ii faketime0.9.8-9 ii locales-all 2.33-7 ii sudo1.9.9-1 Versions of packages reprotest suggests: ii autodep8 0.25 pn qemu-system ii qemu-utils 1:6.2+dfsg-3 ii schroot 1.6.10-12 -- no debconf information signature.asc Description: PGP signature
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
El 02/03/22 a las 19:10, Martin-Éric Racine escribió: > On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine > wrote: > > > > On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R. wrote: > > > > > > El 28/02/22 a las 16:52, Martin-Éric Racine escribió: > > > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine > > > > wrote: > > > > > > > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine > > > > > wrote: > > > > > > > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. > > > > > > wrote: > > > > > > > * Could you please fix the indentation of the your new entry in > > > > > > > d/copyright? > > > > > > > > > > > > IMHO, the whole file's indentation needs to be fixed. I had troubles > > > > > > aligning my addition, because the file currently uses TAB+2SPACES. > > > > > > There really should be a linting tool for that. > > > > > > > > > > Actually, it seems that wrap-and-sort can be used for d/copyright too. > > > > > I somehow was under the impression that it's only used for d/control. > > > > > I'm extremely tempted to run it on the whole package. > > > > > > > > Reading back on Bug #964947, I notice that the request was for both > > > > packaging current upstream and dropping the 5 out of the package name. > > > > I would tend to agree. The 5 really only was meant as an upstream > > > > branch tag. The source and binary really should be called 'dhcpcd' > > > > since it essentially is a fork of the abandoned source of the same > > > > name. > > > > > > Changing the source name means creating (or reintroducing) a different > > > debian package. Just in case: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218 > > > > > > Changing the binary name only means it would have to pass by NEW… > > > > Merely changing the binary name sounds perfectly reasonable to me. > > Please note that I have re-uploaded the package to Mentors. The log > file is more explicit about cosmetic changes and about ./configure > caveats. * Are you sure about this in debian/rules? + --libdir=/usr/lib/i386-linux-gnu \ At a first glance, I suppose that would break multiarch support. * I still don't feel fully comfortable with the cosmetic changes, specially with wrap-and-sort, for *this* NMU. According to my interpretation of developers-references, we should avoid that. Scott is still listed as Maintainer, even if the package hasn't been updated for a long time (hello MIA Team!). At the same time, I appreciate your work and I think the changes you are making should arrive into the debian archive sooner or later. Since I doubt, may I ask the MIA Team if it is OK to include cosmetic changes in an NMU for package that hasn't been orphaned? * Your entry in d/copyright still doesn't follow the same (weird) indentation than previous contributors': Files: * Copyright: 2006-2018 Roy Marples @@ -61,6 +62,7 @@ 2013 Christoph Egger 2014 Salvatore Bonaccorso 2015 Daniel Echeverry + 2022 Martin-Éric Racine License: BSD-2 Cheers, -- Santiago signature.asc Description: PGP signature
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
On March 2, 2022 6:10:32 PM GMT+01:00, "Martin-Éric Racine" wrote: >On Mon, Feb 28, 2022 at 6:55 PM Martin-Éric Racine > wrote: >> >> On Mon, Feb 28, 2022 at 5:52 PM Santiago R.R. wrote: >> > >> > El 28/02/22 a las 16:52, Martin-Éric Racine escribió: >> > > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine >> > > wrote: >> > > > >> > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine >> > > > wrote: >> > > > > >> > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. >> > > > > wrote: >> > > > > > * Could you please fix the indentation of the your new entry in >> > > > > > d/copyright? >> > > > > >> > > > > IMHO, the whole file's indentation needs to be fixed. I had troubles >> > > > > aligning my addition, because the file currently uses TAB+2SPACES. >> > > > > There really should be a linting tool for that. >> > > > >> > > > Actually, it seems that wrap-and-sort can be used for d/copyright too. >> > > > I somehow was under the impression that it's only used for d/control. >> > > > I'm extremely tempted to run it on the whole package. >> > > >> > > Reading back on Bug #964947, I notice that the request was for both >> > > packaging current upstream and dropping the 5 out of the package name. >> > > I would tend to agree. The 5 really only was meant as an upstream >> > > branch tag. The source and binary really should be called 'dhcpcd' >> > > since it essentially is a fork of the abandoned source of the same >> > > name. >> > >> > Changing the source name means creating (or reintroducing) a different >> > debian package. Just in case: >> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218 >> > >> > Changing the binary name only means it would have to pass by NEW… >> >> Merely changing the binary name sounds perfectly reasonable to me. > >Please note that I have re-uploaded the package to Mentors. The log >file is more explicit about cosmetic changes and about ./configure >caveats. > Thank you. And sorry for the radio silence, I got busier than expected the last couple of days. I hope I can process it by Friday. Cheers, Santiago -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
El 28/02/22 a las 16:52, Martin-Éric Racine escribió: > On Mon, Feb 28, 2022 at 4:42 PM Martin-Éric Racine > wrote: > > > > On Mon, Feb 28, 2022 at 4:26 PM Martin-Éric Racine > > wrote: > > > > > > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. > > > wrote: > > > > * Could you please fix the indentation of the your new entry in > > > > d/copyright? > > > > > > IMHO, the whole file's indentation needs to be fixed. I had troubles > > > aligning my addition, because the file currently uses TAB+2SPACES. > > > There really should be a linting tool for that. > > > > Actually, it seems that wrap-and-sort can be used for d/copyright too. > > I somehow was under the impression that it's only used for d/control. > > I'm extremely tempted to run it on the whole package. > > Reading back on Bug #964947, I notice that the request was for both > packaging current upstream and dropping the 5 out of the package name. > I would tend to agree. The 5 really only was meant as an upstream > branch tag. The source and binary really should be called 'dhcpcd' > since it essentially is a fork of the abandoned source of the same > name. Changing the source name means creating (or reintroducing) a different debian package. Just in case: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743218 Changing the binary name only means it would have to pass by NEW… -- Santiago signature.asc Description: PGP signature
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
El 28/02/22 a las 16:26, Martin-Éric Racine escribió: > On Mon, Feb 28, 2022 at 12:45 PM Santiago R.R. wrote: > > > > (Removing some people from CC to avoid polluting their mailboxes) > > > > El 25/02/22 a las 11:25, Martin-Éric Racine escribió: > > > On Fri, Feb 25, 2022 at 10:31 AM Roy Marples wrote: > > > > > > > > On 24/02/2022 21:31, Santiago R.R. wrote: > > > > > > > > > > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R." > > > > wrote: > > > > >> > > > > >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine" > > > > wrote: > > > > >>> Package: dhcpcd5 > > > > >>> Followup-For: Bug #964947 > > > > >>> X-Debbugs-Cc: > > > > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org > > > > >>> > > > > > I have an NMU waiting on Mentors. > > > > > > > > > > <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc> > > > > > > > > > >> Thanks for your work! I do not have too much free cycles, but I will > > > > >> do my best to review and upload it soon. > > ... > > > > I forgot to say I hope Scott is doing well. I hope his lack of activity > > is just a lack of available time. > > The last upload was made in May 2019 i.e. oldstable. > > Bug #964947 requesting the packaging of current version was filed in > July 2020. That's nearly 2 years ago. It remains unanswered by Scott > despite recent activity on the bug. My packaging therefore assumes > that Scott is MIA and focuses on bringing the package closer to what's > expected for contemporary usage. > > > * You are moving stuff to /usr. Do you have any reason for making this > > change in this NMU? > > While I think it is a good thing, this is not documented in > > d/changelog, and I think an NMU should focus on the reason for doing it > > (the newest upstream release in this case). > > From the developers reference (5.11.1.): "...Fixing cosmetic issues or > > changing the packaging style in NMUs is discouraged." > > I try to keep the delta with upstream defaults as small as possible. > Upstream uses /usr. The only thing that doesn't work as expected is > that upstream's configure script fails at putting the prefix for > manual pages. > > As a side-issue, Lintian incorrectly reports the upstream default for > its lease database (/var/db) as non-standard. See Bug#1006482. Because > of this, I've kept the directory unchanged for now. Sorry, just to be sure of understanding, are you reverting the move to /usr? If yes, please tell me when you have a new version to review. Otherwise, please document it in d/changelog. > > If Debian followed FHS by the book, we would probably want the DHCP > client to sit in /sbin since it's needed to bring up the network and > /usr may be mounted later during bootup. Since Debian doesn't mount > /usr separately, using upstream defaults works as-is. > > > This also concerns the minor bump version number in d/watch. > > It was a low-hanging fruit and verified to work. Yes, I can acknowledge that. But again, I have some doubts that's the changes that should be expected in an NMU. > > > * Could you please fix the indentation of the your new entry in d/copyright? > > IMHO, the whole file's indentation needs to be fixed. I had troubles > aligning my addition, because the file currently uses TAB+2SPACES. > There really should be a linting tool for that. Idem. > > > * Part of the changes you are including had already been done in the VCS > > by Scott. There is no rule about this, but *I* would give credit to > > him. Maybe I would have cherry-picked the relevant changes needed for > > packaging this new upstream release, and use `gdp dch`. This is up to > > you. > > I have not checked what's in VCS since no upload has taken place since > 2019 and no reaction to bugs has take place since then either. > > > * Could you please tell me how have you tested it? > > For the past week, it's been the DHCP client on an host that matches > upstream assumptions: hotpluggable Ethernet or USB WiFi dongles. The > host in question has Ethernet, and I've randomly used a variety of USB > dongles to test WiFi support. Configuring wpa_supplicant manually > via/etc/wpa_supplicant/wpa_supplicant.conf rather than passing the > SSID and PSK key via /etc/network/interfaces required a lot of > googling but works as expected. This initially didn't work as > expected, because the package was not compiled with libudev and > upstream's BUILDING.md makes no mention of what libraries may be used > to enable some features. That's how I ended up adding the Build-Dep. Great, thank you! -- Santiago signature.asc Description: PGP signature
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
(Removing some people from CC to avoid polluting their mailboxes) El 25/02/22 a las 11:25, Martin-Éric Racine escribió: > On Fri, Feb 25, 2022 at 10:31 AM Roy Marples wrote: > > > > On 24/02/2022 21:31, Santiago R.R. wrote: > > > > > > On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R." > > wrote: > > >> > > >> On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine" > > wrote: > > >>> Package: dhcpcd5 > > >>> Followup-For: Bug #964947 > > >>> X-Debbugs-Cc: > > sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org > > >>> > > > I have an NMU waiting on Mentors. > > > > > > <https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc> > > > > > >> Thanks for your work! I do not have too much free cycles, but I will do > > >> my best to review and upload it soon. ... I forgot to say I hope Scott is doing well. I hope his lack of activity is just a lack of available time. Martin-Éric, thank you again for preparing this NMU. Here you have some comments/questions: * You are moving stuff to /usr. Do you have any reason for making this change in this NMU? While I think it is a good thing, this is not documented in d/changelog, and I think an NMU should focus on the reason for doing it (the newest upstream release in this case). From the developers reference (5.11.1.): "...Fixing cosmetic issues or changing the packaging style in NMUs is discouraged." This also concerns the minor bump version number in d/watch. * Could you please fix the indentation of the your new entry in d/copyright? * Part of the changes you are including had already been done in the VCS by Scott. There is no rule about this, but *I* would give credit to him. Maybe I would have cherry-picked the relevant changes needed for packaging this new upstream release, and use `gdp dch`. This is up to you. * Could you please tell me how have you tested it? (I will answer Roy's messages in another mail) Cheers! -- Santiago signature.asc Description: PGP signature
Bug#964947: dhcpcd5: New upstream version available: 9.1.4
On February 24, 2022 10:21:38 PM GMT+01:00, "Santiago R.R." wrote: > > >On February 24, 2022 9:38:36 AM GMT+01:00, "Martin-Éric Racine" > wrote: >>Package: dhcpcd5 >>Followup-For: Bug #964947 >>X-Debbugs-Cc: >>sc...@sl.id.au,r...@marples.name,santiag...@riseup.net,mp...@debian.org >> >>-BEGIN PGP SIGNED MESSAGE- >>Hash: SHA512 >> >>I have an NMU waiting on Mentors. >> >><https://mentors.debian.net/debian/pool/main/d/dhcpcd5/dhcpcd5_9.4.1-0.1.dsc> >> Thanks for your work! I do not have too much free cycles, but I will do my best to review and upload it soon. After that, I will take a look at its integration with ifupdown. >>All patches from the previous upload have been dropped since they were >>cherry-picked from upstream Git. >> >>A patch against manual pages was created and forwarded upstream. It's already >>been acknowledged and merged in Git. >> >>Configure's upstream default paths make Lintian bark, so I've kept the >>overrides in debian/rules for now. It might be worth working with upstream on >>making the defaults do what FHS and current packaging practices want. >> >>It's also worth noting that the maintainer and upstream both have unpublished >>VCS commits on Salsa (most recent: Fri May 15 22:11:32 2020). >> Thank you for paying attention to that. Is there anything you can cherry-pick from them? (Haven't taken a look at your NMU yet, so maybe it is a silly question) Cheers, -- S >>Best Regards, >>Martin-Éric >> >>-BEGIN PGP SIGNATURE- >> >>iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmIXRAwACgkQrh+Cd8S0 >>17ZfWA//S70dCme79AVQCSN4piDEFSU2qT+6ZjBh2B49PhQJ6yx4xvDL5DBat3bh >>mKI9j9SV+YfcQ8gvXxyN3uowoP9JAfKWpF3DTKO613uwLm2ytN39vWma9K0JmMu3 >>hTys0fDaVPx/M7rswRP8vP2OJAMHOij/zqbSH+vTw2LtYyS93r5RCxTmre6cVrZ5 >>wKfZboZKSnTgsb0CF6HrPez8PA2ZHMH2rLbuGGdbi1VwEFayQdXV4Ssope4NxzIG >>Pqcu6EAElYzvkZ02vbZkKbHe8Bh85XhD/RWjRz4sX2mdQRxVdqViOiqzZtsj2Ttl >>Mh4o//jY/esVkzslz4b7efVFNIMlSONHXOGabMaVyQ14WoOP+GVy5Gc7dmsz8FLR >>dK1TAOLJDBjkeeM/hCRvNsI+q/Cp5WLrY7udolKHE1dnufdne9qnx/I55ZCLcS8q >>IPb5INka1V9QUf8QETsScWHE/SVOIoo30S18u1x7nuq86eV+c26heP52sxmSUsHt >>uUjlUybsGla6j574B7gTqBbipL8uF6p2E6o/yQJYdDQ5zpEHMv5TugNUBq9pefVN >>2YvOUh+fzUL/hcLvQ/MdvjB+XxhrAONSRB127Cx4kU5xuCP1c5G9aZS83k0cXe1z >>elr8cUFMJNHCD5TUQmZorgSg5azmsD7oFqEbQIsTBq0YdagoLT4= >>=sVj9 >>-END PGP SIGNATURE- -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Bug#995189: RFH: isc-dhcp
El 22/02/22 a las 10:09, Martin-Éric Racine escribió: > On Tue, Feb 22, 2022 at 5:31 AM Martin-Éric Racine > wrote: ... > > > > Please note that there are now 2 upstream repos, if you wanna cherry > > pick CVE fixes: > > > > https://github.com/isc-projects/dhcp > > https://gitlab.isc.org/isc-projects/dhcp > > > > GitHub seems to be abandoned, while GitLab regularly sees commits and > > is where I found the 4.4.3 beta. > > > > Tarballs are still here: > > > > https://downloads.isc.org/isc/dhcp/ > > To top it all, upstream has decided to retire this codebase by the end > of this year: > > https://www.isc.org/blogs/dhcp-client-relay-eom/ > > This will have 2 impacts for Debian: > > 1) Whatever outstanding bugs Debian has will have to be solved and > applicable patches pushed upstream ASAP or closed as won't fix. > > 2) Debian will have to either agree with other distros on a common > fork to maintain or find a new DHCP client to replace the ISC client. > Indeed. And a minor degree, the DHCP relay. Thanks for pointing this out! This impact especially concerns ifupdown, for which an alternative Recommended dhcp client has to be found. Cheers, -- Santiago P.S. BTW, co-maintainers are welcome ;-) signature.asc Description: PGP signature
Bug#1000662: Bug#995189: RFH: isc-dhcp
El 21/02/22 a las 15:19, Martin-Éric Racine escribió: > On Mon, Feb 21, 2022 at 2:18 PM Martin-Éric Racine > wrote: > > > > On Thu, Jan 6, 2022 at 8:40 PM Santiago R.R. wrote: > > > On January 6, 2022 4:49:49 AM GMT-05:00, "Martin-Éric Racine" > > > wrote: > > > >Hello again, > > > > > > > >ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón > > > >(santiag...@riseup.net) kirjoitti: > > > >> El 07/11/21 a las 13:54, Martin-Éric Racine escribió: > > > >> > 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? > > > >> > > > >> 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. > > > > > > > >Has the ITA taken place? > > > > > > > > > > Not an ITA, but an ITS (CCed). I was unable close according to the ITS > > > schedule, and I will have to resume the work after then end of my VAC > > > (mid-January) > > > > This was nearly 2 months ago. At this point, I think that apollock > > and mgilbert might as well be considered MIA. > > Sure enough, upstream already is up to version 4.4.3b1, 26 January > 2022, and recent commits include CVE fixes. OK. I am resuming the work on this, and I'll upload it ASAP. I have just requested to move the isc-dhcp packaging repo to the debian/ namespace. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#1000662: Bug#995189: RFH: isc-dhcp
On January 6, 2022 4:49:49 AM GMT-05:00, "Martin-Éric Racine" wrote: >Hello again, > >ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón >(santiag...@riseup.net) kirjoitti: >> El 07/11/21 a las 13:54, Martin-Éric Racine escribió: >> > 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? >> >> 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. > >Has the ITA taken place? > Not an ITA, but an ITS (CCed). I was unable close according to the ITS schedule, and I will have to resume the work after then end of my VAC (mid-January) Cheers, -- S -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Bug#992873: dhcrelay -6 does not work if there are interface aliases up in the system
Package: isc-dhcp-relay Version: 4.3.5-3+deb9u1 Severity: important Tags: ipv6, upstream Forwarded: https://gitlab.isc.org/isc-projects/dhcp/-/issues/204 Hi there, I've been hitted by this bug on a machine running stretch, but it is also present in the current version on sid (4.4.1-3). dchrelay -6 doesn't start if there are interface aliases up in the system: # /usr/sbin/dhcrelay -6 -pf /var/run/dhcrelay6.pid -l vlan.881 -u 2001:db8:cafe::2%vlan.880 Internet Systems Consortium DHCP Relay Agent 4.4.1 Copyright 2004-2018 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Bound to *:547 Listening on Socket/vlan.881:0 Sending on Socket/vlan.881:0 Listening on Socket/vlan.880:0 Sending on Socket/vlan.880:0 Listening on Socket/vlan Sending on Socket/vlan setsockopt: IPV6_JOIN_GROUP: Address already in use If you think you have received this message due to a bug rather than a configuration issue please read the section on submitting bugs on either our web page at www.isc.org or in the README file before submitting a bug. These pages explain the proper process and the information we find helpful for debugging. exiting. The above error can be reproduced with inside a container with the following /etc/network/interfaces: auto lo iface lo inet loopback auto vlan iface vlan inet dhcp auto vlan.880 auto vlan.880:0 iface vlan.880 inet static address 192.168.133.1/24 iface vlan.880 inet6 static address 2001:db8:cafe::1/64 iface vlan.880:0 inet static address 10.0.133.1/16 auto vlan.881 auto vlan.881:0 iface vlan.881 inet static address 192.168.131.1/24 iface vlan.881 inet6 static address 2001:db8:cafe:1::1/64 iface vlan.881:0 inet static address 10.1.131.1/16 Just removing (or commenting out) the interface aliases entries makes dchrelay -6 happy again. Please note the -l and -u filters do not work. But that's another bug. Cheers, -- Santiago -- System Information: Debian Release: 11.0 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-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 Versions of packages isc-dhcp-relay depends on: ii debconf [debconf-2.0] 1.5.77 ii debianutils4.11.2 ii libc6 2.31-13 ii libdns-export1104 1:9.11.5.P4+dfsg-5.1+deb10u5 ii libdns-export1110 1:9.11.19+dfsg-2.1 pn libdns-export162 pn libirs-export141 ii libirs-export161 1:9.11.19+dfsg-2.1 ii libisc-export1100 1:9.11.5.P4+dfsg-5.1+deb10u5 ii libisc-export1105 1:9.11.19+dfsg-2.1 pn libisc-export160 ii lsb-base 11.1.0 Versions of packages isc-dhcp-relay recommends: ii isc-dhcp-common 4.4.1-2.3 isc-dhcp-relay suggests no packages. signature.asc Description: PGP signature
Bug#987724: RFS: opendnssec/1:2.1.7-2 -- OpenDNSSEC suite
Hi, El 28 de abril de 2021 4:40:45 p. m. GMT+02:00, Mathieu Mirmont escribió: >Package: sponsorship-requests >Severity: normal > >Dear mentors, > >I am looking for a sponsor for my package "opendnssec". The only >changes from the version currently in testing are the addition of >translation files, which I'm hoping will land in bullseye. I'll wait >for bullseye's release to push the packaging of the new upstream >release (2.1.8). I'll take a look at and upload it, unless someone is faster than me. > > * Package name: opendnssec > Version : 1:2.1.7-2 > * URL : https://www.opendnssec.org/ > * License : BSD-IBM-ISC, GPL-2, OLD-BSD, BSD-2-clause > * Vcs : https://salsa.debian.org/debian/opendnssec > Section : admin > >It builds those binary packages: > > libhsm-bin - library for interfacing PKCS#11 Hardware Security Modules > opendnssec-signer - daemon to sign DNS zone files periodically >opendnssec-enforcer-sqlite3 - tool to prepare DNSSEC keys (sqlite3 >backend) >opendnssec-enforcer-mysql - tool to prepare DNSSEC keys (MySQL backend) > opendnssec-enforcer - tool to prepare DNSSEC keys (common package) > opendnssec-doc - documentation for OpenDNSSEC suite > opendnssec - dependency package to install full OpenDNSSEC suite > opendnssec-common - common configuration files for OpenDNSSEC suite > >To access further information about this package, please visit the >following URL: > > https://mentors.debian.net/package/opendnssec/ > >Alternatively, one can download the package with dget using this >command: > >dget -x >https://mentors.debian.net/debian/pool/main/o/opendnssec/opendnssec_2.1.7-2.dsc > >Changes since the last upload: > > 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? > * po/es.po: Add Spanish translation (Closes: #987518) > >Regards, -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Bug#986928: autopkgtest-virt-qemu fails with stderr: Generating grub configuration file
Control: notfound -1 0.42.2-1 El 14/04/21 a las 16:18, Simon McVittie escribió: > Control: reassign -1 src:libcgroup 0.42.2-1 > > On Wed, 14 Apr 2021 at 15:43:42 +0200, Santiago R.R. wrote: > > autopkgtest [15:15:46]: test tools-cgroupv1: - - - - - - - - - - results - > > - - - - - - - - - > > tools-cgroupv1 FAIL stderr: Generating grub configuration file ... > > Part of the autopkgtest specification[1] is that by default, a test > is considered to have failed if it either exits with a nonzero status, > *or prints anything to stderr*. Your test is exiting 0, but it prints > (harmless) messages to stderr, so the specification says it has > failed. autopkgtest is reporting this correctly. > > I believe the intention was that checking stderr like this would make > warnings and other suspicious things fatal by default. With hindsight, > this was probably not the right default, but we're stuck with it now. > > If this is not what you want, either mark the test with > "Restrictions: needs-root, isolation-machine, allow-stderr", or run > update-grub like "update-grub 2>&1" so that its diagnostic messages go to > stdout. ... Mmm, thanks. I think I misunderstood the behaviour of the qemu virt. I wrongly thought it was something related with grub and autopkgtest. Thank you, and sorry for the noise, -- Santiago signature.asc Description: PGP signature
Bug#986139: offlineimap3 crashes with encoding error
Source: offlineimap3 Version: 0.0~git20210225.1e7ef9e+dfsg-3 Severity: important Dear Sudip, My offlineimap3 crashes when trying to retrieve some messages: ... Last 11 debug messages logged for Copy message from Riseup-Remote:origin-mail-dir prior to exception: thread: Register new thread 'Copy message from Riseup-Remote:origin-mail-dir' (account 'Riseup') imap: 15:26.95 Copy message from Riseup-Remote:origin-mail-dir [async] UID ('FETCH', '1981', '(BODY.PEEK[])') imap: 15:26.95 Copy message from Riseup-Remote:origin-mail-dir state_change_pending.acquire imap: 15:26.95 Copy message from Riseup-Remote:origin-mail-dir state_change_pending.release imap: 15:26.95 Copy message from Riseup-Remote:origin-mail-dir _request_push(b'EPBL24', UID, {}) = b'EPBL24' imap: 15:26.95 Copy message from Riseup-Remote:origin-mail-dir data=b'EPBL24 UID FETCH 1981 (BODY.PEEK[])' imap: 15:26.96 Copy message from Riseup-Remote:origin-mail-dir UID:b'EPBL24'.ready.wait imap: 15:27.44 Copy message from Riseup-Remote:origin-mail-dir _get_untagged_response(FETCH) => [(b'184 (UID 1981 BODY[] {6664}', b'Return-Path: [(b'184 (UID 1981 BODY[] {6664}', b'Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on towhee.riseup.net X-Spam-Level: X... v2.0 * ' maildir: Write mail 'origin-mail-dir:1981' with flags set() 2021-03-30 10:15:27 INFO: OfflineIMAP 7.3.0 Licensed under the GNU GPL v2 or any later version (with an OpenSSL exception) 2021-03-30 10:15:27 WARNING: ERROR: Exceptions occurred during the run! 2021-03-30 10:15:27 WARNING: ERROR: Copying message 1981 [acc: Riseup] 'ascii' codec can't encode characters in position 3523-3525: ordinal not in range(128) 2021-03-30 10:15:27 WARNING: Traceback: File "/usr/share/offlineimap3/offlineimap/folder/Base.py", line 807, in copymessageto new_uid = dstfolder.savemessage(uid, message, flags, rtime) File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 380, in savemessage tmpname = self.save_to_tmp_file(messagename, msg) File "/usr/share/offlineimap3/offlineimap/folder/Maildir.py", line 330, in save_to_tmp_file fd.write(msg.as_bytes(policy=output_policy)) File "/usr/lib/python3.9/email/message.py", line 178, in as_bytes g.flatten(self, unixfrom=unixfrom) File "/usr/lib/python3.9/email/generator.py", line 116, in flatten self._write(msg) File "/usr/lib/python3.9/email/generator.py", line 181, in _write self._dispatch(msg) File "/usr/lib/python3.9/email/generator.py", line 218, in _dispatch meth(msg) File "/usr/lib/python3.9/email/generator.py", line 268, in _handle_multipart self.write(subparts) File "/usr/lib/python3.9/email/generator.py", line 410, in write self._fp.write(s.encode('ascii', 'surrogateescape')) Tell me if more debug information is needed. Cheers, -- S -- 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-4-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#969453: RFS: solo-python/0.0.26-1 [ITP] -- command line interface for SoloKeys 2FA security keys
El 21 de diciembre de 2020 8:39:44 a. m. GMT-03:00, Philip Rinn escribió: >Hi, > >anyone willing to sponsor this package I think having tools around for >more >security keys in Bullseye would be very nice. > I could, if nobody else can respond earlier. given the holidays, I'd have some delay. Cheers Santiago >Thanks & happy hacking > >Philip > >On Thu, 2020-09-03 at 10:03 +0200, Philip Rinn wrote: >> Dear mentors, >> >> I am looking for a sponsor for my package "solo-python": >> >> * Package name: solo-python >>Version : 0.0.26-1 >>Upstream Author : SoloKeys >> * URL : https://github.com/solokeys/solo-python >> * License : Apache-2.0 or Expat >> * Vcs : https://salsa.debian.org/rinni/solo-python >>Section : utils >> >> It builds those binary packages: >> >> solo-python - command line interface for SoloKeys >> >> To access further information about this package, please visit the >following URL: >> >> https://mentors.debian.net/package/solo-python/ >> >> Alternatively, one can download the package with dget using this >command: >> >> dget -x >> >https://mentors.debian.net/debian/pool/main/s/solo-python/solo-python_0.0.26-1.dsc >> >> Changes for the initial release: >> >> solo-python (0.0.26-1) unstable; urgency=low >> . >>* Initial release (closes: #958565). >> >> >> My main driver to package this is to have more support for 2FA >security keys >> available in Debian. >> >> I own two of those keys and they are very nice devices for general >2FA but they >> can actually do much more e.g. they will gain OpenPGP functionality >in the >> future. >> >> I'm aware that the package will not build reproducible at the moment >due to >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969352 - I hope we >will be able >> to solve this issue before the freeze. >> >> I also asked upstream to sign their releases and will ask them to >include a manpage. >> >> >> Best, >> Philip -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Bug#964745: lxc-start fails when specifying a custom lxc.net.0.hwaddr (on armv7l)
Salut Pierre, El 05/09/20 a las 00:23, Pierre-Elliott Bécue escribió: > 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: > > … > > To make the container work, I had to remove the lxc.net.0.hwaddr entry, > > start the container and only then copy the autogenerated MAC address in > > the config. > > > > This happens on armv7l running buster. I haven't test a similar case on > > other architecture nor testing/sid. > > Could you give me your container config? I'll do once I regain access to that machine. It has some issues after a blackout … :-s Cheers, -- Santiago signature.asc Description: PGP signature
Bug#970674: cqueues unusable on arm64 under LuaJIT
Source: lua-cqueues Version: 20200726-1 Severity: important Tags: upstream Forwarded: https://github.com/wahern/cqueues/issues/241 As described in the forwarded URL, queues is broken under luajit on arm64: santiago@amdahl ~ % /usr/bin/luajit -l cqueues -e 'os.exit(0)' /usr/bin/luajit: bad light userdata pointer stack traceback: [C]: at 0x81385120 [C]: in function 'require' /usr/share/lua/5.1/cqueues.lua:2: in function [C]: at 0xcdacbd08 [C]: at 0xcda7e4c0 -- 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.5.0-2-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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#969952: provide a way to export the source tree (without building)
El 09/09/20 a las 13:25, Guido Günther escribió: > Hi, > On Wed, Sep 09, 2020 at 01:14:07PM +0200, Santiago R.R. wrote: > > El 09/09/20 a las 11:11, Guido Günther escribió: > > > Hi, > > > On Wed, Sep 09, 2020 at 10:49:27AM +0200, Santiago R.R. wrote: ... > > ACK. Sadly I don't have currently enough free cycles, so I cannot > > promise I'll be able to do it myself. > > Same here but maybe this helps a little > > > https://git.sigxcpu.org/cgit/git-buildpackage/commit/?id=c02938fd87042429d6d6102ba55e2b7eee9712f8 Great, thanks! Forgot to say that would be also useful to have an argument to name the directory where the debianized source would be extracted, other than package-name-version. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#969952: provide a way to export the source tree (without building)
El 09/09/20 a las 11:11, Guido Günther escribió: > Hi, > On Wed, Sep 09, 2020 at 10:49:27AM +0200, Santiago R.R. wrote: > > Source: git-buildpackage > > Version: 0.9.20 > > Severity: wishlist > > > > Dear Guido, > > > > If I am not wrong, gbp doesn't have a simple method to just export the > > source tree (upstream orig + debian/), without building the packcage. > > > > It would be nice to have something like: > > > > gbp export-source-tree DIR > > > > The simplest hack that I've found is (thanks folks in #debian-devel) > > somthing like this: > > > > gbp buildpackage \ > > --git-ignore-branch \ > > --git-ignore-new \ > > --git-export-dir=${SOURCE_DIR} \ > > --git-no-purge \ > > --git-builder="dpkg-buildpackage" \ > > -S -d -nc -us -uc > > > > but it needs to build the source package. > > > > Could you please consider this new feature? > > As noted on irc you can just use `/bin/true/` as builder: > > gbp buildpackage --git-export-dir=/tmp/foo --git-builder=/bin/true > --git-no-pbuilder --git-no-hooks For completeness: gbp buildpackage --git-export-dir=/tmp/foo --git-builder=/bin/true --git-no-pbuilder --git-no-hooks --git-no-purge Thanks! I've already tried `--git-builder=/bin/true`, but I was missing `--git-no-pbuilder --git-no-hooks`. > > but if somebody comes up with a patch that moves that common code into a > `export_source` command (including manpage) that would be nice too. ACK. Sadly I don't have currently enough free cycles, so I cannot promise I'll be able to do it myself. Thanks, -- Santiago signature.asc Description: PGP signature
Bug#969952: provide a way to export the source tree (without building)
Source: git-buildpackage Version: 0.9.20 Severity: wishlist Dear Guido, If I am not wrong, gbp doesn't have a simple method to just export the source tree (upstream orig + debian/), without building the packcage. It would be nice to have something like: gbp export-source-tree DIR The simplest hack that I've found is (thanks folks in #debian-devel) somthing like this: gbp buildpackage \ --git-ignore-branch \ --git-ignore-new \ --git-export-dir=${SOURCE_DIR} \ --git-no-purge \ --git-builder="dpkg-buildpackage" \ -S -d -nc -us -uc but it needs to build the source package. Could you please consider this new feature? 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.5.0-2-amd64 (SMP w/8 CPU threads) 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 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#969365: USB-C dock lacks multicast Ethernet functionality (so IPv6 is broken)
Source: linux Version: 4.19.118-2 Severity: important Tags: ipv6 upstream fixed-upstream IPv6 connectivity (and other network protocols relying on multicast) are broken when using a Dell D6000 USB-C dock. Quoting Miguel Rodríguez that filed the equivalent bug in ubuntu: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779173: "Dell D6000 exposes a CDC_NCM device for Ethernet traffic. However, multicast Ethernet traffic is not processed making IPv6 not functional. Other services, like mDNS used for LAN service discovery are also hindered. The actual reason is that CDC_NCM driver was not processing requests to filter (admit) multicast traffic. I provide two patches to the linux kernel that admit all Ethernet multicast traffic whenever a multicast group is being joined. The solution is not optimal, as it makes the system receive more traffic than that strictly needed, but otherwise this only happens when the computer is connected to a dock and thus is running on AC power. I believe it is not worth the hassle to join only the requested groups. This is the same that is done in the CDN_ETHER driver." The patches proposed by Miguel Rodríguez have been merged upstream, and are part of 5.9-rc1 now. C.f. commits: 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6 e10dcb1b6ba714243ad5a35a11b91cc14103a9a9 e506addeff844237d60545ef4f6141de21471caf 0226009ce0f6089f9b31211f7a2703cf9a327a01 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.5.0-2-amd64 (SMP w/8 CPU threads) 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 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#964744: test
Package: lxc Version: 1:4.0.2-1 Severity: important ./reportbug-lxc-20200709-4158-b5ttbb8r -- 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.5.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 lxc depends on: ii debconf [debconf-2.0] 1.5.74 ii libc6 2.30-8 ii libgcc-s1 10.1.0-4 ii liblxc11:4.0.2-1 ii lsb-base 11.1.0 Versions of packages lxc recommends: ii apparmor 2.13.4-3 ii bridge-utils 1.6-3 ii debootstrap 1.0.123 ii dirmngr 2.2.20-1 ii dnsmasq-base [dnsmasq-base] 2.81-4 ii gnupg2.2.20-1 ii iproute2 5.7.0-1 ii iptables 1.8.5-2 ii libpam-cgfs 1:4.0.2-1 ii lxc-templates3.0.4-3 ii lxcfs4.0.3-1 ii nftables 0.9.6-1 ii openssl 1.1.1g-1 ii rsync3.2.2-1 ii uidmap 1:4.8.1-1 Versions of packages lxc suggests: pn btrfs-progs ii lvm2 2.03.07-1+b1 pn python3-lxc -- debconf information excluded
Bug#962583: lintian: doesn't follow optional convention to organise d/missing-sources
Source: lintian Severity: normal Dear lintian maintainers: The current debian-policy (4.5.0.2) states in Section 4.16. Missing sources: There is an optional convention to organise the contents of "debian /missing-sources" in the following way. For a sourceless file "foo" in the subdirectory "bar" of the upstream tarball, where the source of "foo" has extension "baz", the source is to be located at "debian /missing-sources/bar/foo.baz". For example, according to this convention, the C source code of an executable "checksum/util" is to be located at "debian/missing-sources/checksum/util.c". knot-resolver 5.1.1 includes the minified modules/http/static/dygraph.min.js, and I placed then its source file in: debian/missing-sources/modules/http/static/dygraph.js as you can see in https://salsa.debian.org/dns-team/knot-resolver/-/commit/52ca961e3c3e5eacc4c85a65fe66919c0eed56ca but lintian complains about this very source file: E: knot-resolver source: source-is-missing debian/missing-sources/modules/http/static/dygraph.js line length is 847 characters (>512) c.f. https://salsa.debian.org/dns-team/knot-resolver/-/jobs/797179 moving dygraph.js to debian/missing-sources/dygraph.js makes lintian happier: https://salsa.debian.org/dns-team/knot-resolver/-/commit/0085ab75be975a2bd478743fe14ba181509e0e80 https://salsa.debian.org/dns-team/knot-resolver/-/jobs/797196 Please, tell me if my interpretation of the optional convention is wrong. Cheers, -- 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.6.0-2-amd64 (SMP w/8 CPU cores) 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 -- no debconf information signature.asc Description: PGP signature
Bug#961654: buster-pu: package bzip2/1.0.6-9.2~deb10u1
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. Cheers, -- 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-05-27 10:18:11.0 +0200 @@ -1,3 +1,10 @@ +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) + + -- Santiago Ruano Rincón Wed, 27 May 2020 10:18:11 +0200 + bzip2 (1.0.6-9.2~deb10u1) buster; urgency=medium * Rebuild for buster 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-05-27 09:58:14.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#959388: [Pkg-privacy-maintainers] Bug#959388: torbrowser fails to start due to lacking fonts/* entry in apparmor
El 07/05/20 a las 22:30, Roger Shimizu escribió: > On Thu, May 7, 2020 at 9:41 PM Santiago R.R. wrote: > > > > I have unsuccessfully tried to reproduce the bug in the same machine, > > even removing my .local/share/torbrowser/ directory. I still see the > > apparmor DENIED message in the logs, but torbrowser starts without > > issues. > > If you see the DENIED log in dmesg, the problem still exists. > And if after the apparmor patch, the DENIED log gets gone, that tells > us the patch is valid. > > > So sorry if this bug is just noise. > > Just double confirm my question above. and we'll decide whether to > move forward to the pull-request. > Thank you! I can confirm I see the DENIED without the patch, if .local/share/torbrowser/ is clean. No messages with the patch. Cheers! -- S signature.asc Description: PGP signature
Bug#959388: [Pkg-privacy-maintainers] Bug#959388: torbrowser fails to start due to lacking fonts/* entry in apparmor
El 05/05/20 a las 20:27, Roger Shimizu escribió: > control: tags -1 +pending > control: forwarded -1 > https://github.com/micahflee/torbrowser-launcher/pull/468 > > Dear Santiago, > > Thanks for your report and patch! > > On Sat, May 2, 2020 at 4:51 AM Santiago R.R. wrote: > > > > Package: torbrowser-launcher > > Version: 0.3.2-10 > > > > The attached patch seems to have fixed here the issue. > > I guess you meet this issue because I fixed the language locale issue > in previous upload. > However I didn't reproduce this in my buster-bpo system. Maybe this > only occurs in sid? I have unsuccessfully tried to reproduce the bug in the same machine, even removing my .local/share/torbrowser/ directory. I still see the apparmor DENIED message in the logs, but torbrowser starts without issues. So sorry if this bug is just noise. > > Anyway, I upstreamed your patch: > - https://github.com/micahflee/torbrowser-launcher/pull/468 … Thanks! Cheers, -- S signature.asc Description: PGP signature
Bug#959388: torbrowser fails to start due to lacking fonts/* entry in apparmor
Package: torbrowser-launcher Version: 0.3.2-10 Severity: important Tags: patch When trying to launch torbrowser, I got this: type=1400 audit(1588360736.602:285): apparmor="DENIED" operation="link" profile="torbrowser_firefox" name="/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_es-ES/Browser/fonts/.uuid.LCK" pid=368816 comm="firefox.real" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 target="/home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_es-ES/Browser/fonts/.uuid.TMP-8RQs3m" The attached patch seems to have fixed here the issue. Thanks for maintaining torbrowser-launcher! -- S -- 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.5.0-1-amd64 (SMP w/8 CPU cores) 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 torbrowser-launcher depends on: ii ca-certificates 20190110 ii libdbus-glib-1-2 0.110-5 ii python3 3.8.2-3 ii python3-gpg 1.13.1-7+b1 ii python3-pyqt5 5.14.2+dfsg-1+b1 ii python3-requests 2.23.0+dfsg-2 ii python3-socks 1.6.8+dfsg-1 Versions of packages torbrowser-launcher recommends: ii tor 0.4.2.7-1 Versions of packages torbrowser-launcher suggests: ii apparmor 2.13.4-1+b1 -- Configuration Files: /etc/apparmor.d/torbrowser.Browser.firefox changed [not included] -- no debconf information --- torbrowser.Browser.firefox.orig 2020-05-01 21:38:49.701044777 +0200 +++ torbrowser.Browser.firefox 2020-05-01 21:38:39.40119 +0200 @@ -68,6 +68,7 @@ owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profiles.ini r, owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/{,**} rwk, owner @{torbrowser_home_dir}/TorBrowser/Data/fontconfig/fonts.conf r, + owner @{torbrowser_home_dir}/fonts/* l, owner @{torbrowser_home_dir}/TorBrowser/Tor/tor px, owner @{torbrowser_home_dir}/TorBrowser/Tor/ r, owner @{torbrowser_home_dir}/TorBrowser/Tor/*.so mr, signature.asc Description: PGP signature
Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1
El 26/02/20 a las 11:10, Santiago R.R. escribió: > Hi Ritesh, > > I've just made another MR to modify the changelog entry. > > Also, please, remember to create a tag for the release once it get > approved (and uploaded). Hi Ritesh, When trying to upload I realized the format of the package is that of a native package, but the version has a revision at the same time. Which I think it is unusual. I don't understand how the package is built (at least using gbp). Could you please tell me how to do you build the package? And even, fell free to upload it yourself, to avoid duplicating work. Thanks, -- Santiago signature.asc Description: PGP signature
Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1
Hi Ritesh, I've just made another MR to modify the changelog entry. Also, please, remember to create a tag for the release once it get approved (and uploaded). Cheers, -- Santiago signature.asc Description: PGP signature
Bug#951329: Bug#952441: buster-pu: package user-mode-linux/4.19-1um-1+b1
Control: fixed 951329 user-mode-linux/5.4-1um-2 El 25/02/20 a las 21:05, Adam D. Barratt escribió: > Control: tags -1 + moreinfo > > On Mon, 2020-02-24 at 14:49 +0100, Santiago R.R. wrote: > > I would like to upload user-mode-linux to buster to fix this FTBFS: > > https://bugs.debian.org/951329. Ritesh Raj Sarraf (rrs) has already > > given his ACK. > > > > The metadata for that bug suggests that it affects the package in > unstable, and is not currently fixed there. Is that correct? > > If it is, the issue should be fixed in unstable first. If not, the bug > report should have an appropriate "fixed" version added, indicating the > earliest upload that's unaffected. Hi Adam, Thanks! I forgot clarifying that this didn't affect unstable. Hopefully the above control command fix that. Also, I realised the changelog did not describe how the bug was fixed. So please, consider the new debdiff. Cheers, -- S diff -Nru user-mode-linux-4.19-1um/debian/changelog user-mode-linux-4.19-1um/debian/changelog --- user-mode-linux-4.19-1um/debian/changelog 2018-12-27 08:46:23.0 +0100 +++ user-mode-linux-4.19-1um/debian/changelog 2020-02-26 10:53:51.0 +0100 @@ -1,3 +1,11 @@ +user-mode-linux (4.19-1um-1+deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * [00f54af] Fix FTBFS in buster with linux-source-4.19 4.19.98-1. +Remove fix-port-helper-path.patch (Closes: #951329). + + -- Santiago Ruano Rincón Wed, 26 Feb 2020 10:32:01 +0100 + user-mode-linux (4.19-1um-1) unstable; urgency=medium * [a505b8d] Update to Linux 4.19 (Closes: #916958) diff -Nru user-mode-linux-4.19-1um/debian/patches/series user-mode-linux-4.19-1um/debian/patches/series --- user-mode-linux-4.19-1um/debian/patches/series 2018-12-27 08:46:23.0 +0100 +++ user-mode-linux-4.19-1um/debian/patches/series 2020-02-26 10:53:51.0 +0100 @@ -3,4 +3,3 @@ 05_fix_static_build.patch 06-fix-linkage-on-386-arch.patch 07-remove-rpath.patch -fix-port-helper-path.patch signature.asc Description: PGP signature
Bug#952520: lxc-net: native nftables support
Source: lxc Version: 1:3.1.0+really3.0.4-2 Severity: wishlist Tags: upstream Since 0.9.1-3 [1], nftables' priority has been bumped up to important, remplacing iptables as default netfilter admin tool. [1] https://tracker.debian.org/news/1054941/accepted-nftables-091-3-source-into-unstable/ Currently, /usr/libexec/lxc/lxc-net relies on iptables, and it would be nice if it could natively manage the rules using nft. Cheers, -- S -- 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.4.0-3-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 signature.asc Description: PGP signature
Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1
El 24/02/20 a las 15:29, Ritesh Raj Sarraf escribió: > Sorry. I hadn't realized that you already had MRs on Salsa. But I > wasn't aware of the extra configuration needed for notifications. Mmm, maybe I had to continue using the BTS, instead of the MR. At least for communicating with you. > > Please go ahead with the upload. Thanks! I've just filed a bug report against release.d.o to ask for an OK from the RMs. ... > On Mon, 2020-02-24 at 15:16 +0530, Ritesh Raj Sarraf wrote: > > Hi Santiago, > > > > Do you have the MR ready ? > > > > Your bug report against the package in Buster has caused a trigger to > > auto-remove UML from Debian Testing. I don't know how removing the > > package from testing solves any problem with the package in Buster. ... Good question. But anyway, I hope I will be able to upload before the automatic auto-removal deadline. Cheers, - srr signature.asc Description: PGP signature
Bug#952441: buster-pu: package user-mode-linux/4.19-1um-1+b1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu Dear Release Managers, I would like to upload user-mode-linux to buster to fix this FTBFS: https://bugs.debian.org/951329. Ritesh Raj Sarraf (rrs) has already given his ACK. Debdiff attached. 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.4.0-3-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 diff -Nru user-mode-linux-4.19-1um/debian/changelog user-mode-linux-4.19-1um/debian/changelog --- user-mode-linux-4.19-1um/debian/changelog 2018-12-27 08:46:23.0 +0100 +++ user-mode-linux-4.19-1um/debian/changelog 2020-02-24 14:30:26.0 +0100 @@ -1,3 +1,11 @@ +user-mode-linux (4.19-1um-1+deb10u1) buster; urgency=medium + + * Non-maintainer upload. + * [00f54af] Fix FTBFS in buster with linux-source-4.19 4.19.98-1 +(Closes: #951329) + + -- Santiago Ruano Rincón Fri, 14 Feb 2020 16:11:11 +0100 + user-mode-linux (4.19-1um-1) unstable; urgency=medium * [a505b8d] Update to Linux 4.19 (Closes: #916958) diff -Nru user-mode-linux-4.19-1um/debian/patches/series user-mode-linux-4.19-1um/debian/patches/series --- user-mode-linux-4.19-1um/debian/patches/series 2018-12-27 08:46:23.0 +0100 +++ user-mode-linux-4.19-1um/debian/patches/series 2020-02-24 14:30:26.0 +0100 @@ -3,4 +3,3 @@ 05_fix_static_build.patch 06-fix-linkage-on-386-arch.patch 07-remove-rpath.patch -fix-port-helper-path.patch signature.asc Description: PGP signature
Bug#952378: spamassassin: Example config needs a way of whitelisting GPG signed mail (EG from DDs)
On Mon, 24 Feb 2020 01:56:59 +1100 Russell Coker wrote: > Package: spamassassin > Severity: wishlist > > It would be good if the example configuration included a way of whitelisting > mail from known good GPG keys. An example configuration that would be useful > in real use would be the Debian developer keylist. I don't know it this helps: https://metacpan.org/pod/Mail::SpamAssassin::Plugin::OpenPGP Note: I am a SA illiterate, and haven't test the plugin. signature.asc Description: PGP signature
Bug#951329: FTBFS in buster with linux-source-4.19 4.19.98-1
Package: user-mode-linux Version: 4.19-1um-1 Severity: serious Tags: patch Dear maintainer, The current user-mode-linux package in buster fails to build the latest linux kernel in buster due to the fix-port-helper-path.patch: Applying patch /build/user-mode-linux-4.19-1um/debian/patches/fix-port-helper-path.patch patching file arch/um/drivers/port_user.c Hunk #1 FAILED at 168. 1 out of 1 hunk FAILED -- rejects in file arch/um/drivers/port_user.c Patch /build/user-mode-linux-4.19-1um/debian/patches/fix-port-helper-path.patch can be reverse-applied make: *** [debian/rules:54: patch-stamp] Error 1 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 I: copying local configuration E: Failed autobuilding of package Removing it solves the issue: diff --git a/debian/patches/series b/debian/patches/series index 5f98481..29faa0f 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -3,4 +3,3 @@ 05_fix_static_build.patch 06-fix-linkage-on-386-arch.patch 07-remove-rpath.patch -fix-port-helper-path.patch BTW, I will prepare a git branch in my personal salsa namespace. But I am not sure against which branch should I propose a MR. 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.4.0-3-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 user-mode-linux depends on: ii libc6 2.29-10 Versions of packages user-mode-linux recommends: ii uml-utilities 20070815.3-1 Versions of packages user-mode-linux suggests: ii rootstrap 0.3.25-1 ii rxvt-unicode [x-terminal-emulator]9.22-6+b2 pn slirp ii terminator [x-terminal-emulator] 1.91-4 ii user-mode-linux-doc 20060501-3 pn vde2 ii xfce4-terminal [x-terminal-emulator] 0.8.9.1-1 ii xterm [x-terminal-emulator] 353-1 -- no debconf information
Bug#948898: stretch-pu: package libidn/1.33-1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: stretch Severity: normal El 13/12/19 a las 23:39, Salvatore Bonaccorso escribió: > Hi Santiago, > > On Mon, Jul 09, 2018 at 07:54:39PM +0200, Santiago R.R. wrote: > > El 27/06/18 a las 00:01, Santiago R.R. escribió: > > > El 10/06/18 a las 14:49, Moritz Mühlenhoff escribió: > > > > On Sun, Jun 10, 2018 at 10:24:29AM +0200, Santiago R.R. wrote: > > > > > El 30/04/18 a las 12:20, Santiago escribió: > > > > > > On Tue, 12 Sep 2017 10:05:25 + =?utf-8?b?T25kxZllaiBTdXLDvQ==?= > > > > > > wrote: > > > > > … > > > > > > > > > > > > Hi Ondřey, security team, > > > > > > > > > > > > CVE-2017-14062 has been fixed in wheezy, but still open in jessie > > > > > > and > > > > > > stretch. Are you willing to fix it? Would you like some help? > > > > > > > > > > Dear security-team, > > > > > > > > > > Please, find attached the debdiffs (s/santiago-//) for both jessie and > > > > > stretch. Could you please review it and let me know if it's OK to be > > > > > uploaded? > > > > > > > > debdiffs per se are not really saving us any work. What's more important > > > > is a description of all the tests you made with a build of your patches > > > > in oldstable and stable. > > > ... > > > AFAIU, the decode_digit function, modified by the patch, is used by > > > punycode_decode, and in turn, by idna.c's idna_to_unicode_internal, and > > > this by different public functions. > > > > > > I am not aware of any PoC to test the issue. So to test the patch I > > > tried the libidn idn tool, and queried encoded/decoded internationalized > > > qnames against local resolvers. > > > > > > idn can encode to and decode from punycode: > > > > > > santiago@stretch:~$ idn -e árbol > > > rbol-4na > > > > > > And to confirm the encoded punycode is reversible: > > > > > > santiago@stretch:~$ idn -e árbol | idn -d > > > árbol > > > > > > I tested two local resolvers that depend on libidn11: dnsmasq in jessie, > > > and getdns in stretch. I have accessed via elinks (that also depends on > > > libidn11) to different internationalized qnames, in both UTF-8 and > > > ACE (ASCII Compatible Encoding) encoded form, e.g. xn--j1ay.xn--p1ai. > > > Just to be sure, I rebuild those three packages: dnsmasq, getdns and > > > elinks. > > > > > > Should that be OK? > > > > > > Please, tell me if you think any further testing is needed, or if you > > > have any other concern. > > ... > > While reviewing some older issues I re-encoutered CVE-2017-14062. > > Could you fix this via upcoming stretch point release? > > Regards, > Salvatore Dear release team, as suggested by Salvatore, I would like to propose fixing CVE-2017-14062 (#873903) in libidn via an update to stretch. Please find the debdiff attached. The tests I have made are described above. Please, let me know if it's OK to upload it. Cheers, -- Santiago diff -Nru libidn-1.33/debian/changelog libidn-1.33/debian/changelog --- libidn-1.33/debian/changelog2016-07-21 10:25:59.0 +0200 +++ libidn-1.33/debian/changelog2020-01-14 15:42:19.0 +0100 @@ -1,3 +1,15 @@ +libidn (1.33-1+deb9u1) stretch; urgency=medium + + * Non-maintainer upload. + * Fix CVE-2017-14062: An integer overflow vulnerability in libidn's Punycode +handling (an encoding used to convert Unicode characters to ASCII) which +would have allowed remote attackers to cause a denial of service. + * Import 0004-Update-Makefile.gdoc-to-use-GDOC_BIN-instead-of-hard.patch +from unstable to avoid a FTBFS. +- Add textinfo to Build-Deps. + + -- Santiago R.R. Tue, 14 Jan 2020 15:42:19 +0100 + libidn (1.33-1) unstable; urgency=low * New upstream release. diff -Nru libidn-1.33/debian/control libidn-1.33/debian/control --- libidn-1.33/debian/control 2016-07-21 10:22:20.0 +0200 +++ libidn-1.33/debian/control 2020-01-14 15:28:51.0 +0100 @@ -4,7 +4,7 @@ Maintainer: Debian Libidn Team Uploaders: Anibal Monsalve Salazar , Simon Josefsson Standards-Version: 3.9.8 -Build-Depends: debhelper (>= 9), gcj-jdk [!arm !hppa !hurd-i386 !mips64el], fastjar [!arm !hppa !hurd-i386 !mips64el], dh-autoreconf, autopoint (>= 0.19.3) +Build-Depends: debhelper (>= 9), gcj-jdk [!arm !hppa !hurd-i386 !mips64el], fastjar [!ar
Bug#943834: 404 error on https://piuparts.d.o/doc/ files
Package: piuparts.debian.org Severity: normal Different doc-related links seem to be broken: https://piuparts.debian.org/doc/README.html https://piuparts.debian.org/doc/piuparts.1.html http://piuparts.debian.org/doc/README_server.html Referer to those URLs are https://piuparts.debian.org/ and https://wiki.debian.org/piuparts/piuparts.debian.org I cannot say if the solution would be to fix those links to point somewhere else, or to provide piuparts.d.o/doc/ Cheers, -- Santiago
Bug#940723: java-package requires libgtk-3-0 and libcairo-gobject2 to build java8 221
Package: java-package Version: 0.62 Severity: serious Dear java-package maintainers, When trying to build the deb package of jdk-8u221-linux-x64.tar.gz on a clean sid pbuilder, I got the following errors: … dpkg-shlibdeps: error: cannot find library libgtk-3.so.0 needed by debian/oracle-java8-jdk/usr/lib/jvm/oracle-java8-jdk-amd64/jre/lib/amd64/libglassgtk3.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: error: cannot find library libgdk-3.so.0 needed by debian/oracle-java8-jdk/usr/lib/jvm/oracle-java8-jdk-amd64/jre/lib/amd64/libglassgtk3.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') dpkg-shlibdeps: error: cannot find library libcairo-gobject.so.2 needed by debian/oracle-java8-jdk/usr/lib/jvm/oracle-java8-jdk-amd64/jre/lib/amd64/libglassgtk3.so (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '') … dpkg-shlibdeps: error: cannot continue due to the errors listed above Note: libraries are not searched in other binary packages that do not have any shlibs or symbols file. To help dpkg-shlibdeps find private libraries, you might need to use -l. … dh_shlibdeps: Aborting due to earlier error make[1]: *** [debian/rules:17: override_dh_shlibdeps] Error 255 make: *** [debian/rules:11: binary] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 Installing libcairo-gobject2 and libgtk-3-0 makes make-jpkg happy. Cheers, -- Santiago -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (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 java-package depends on: ii build-essential 12.8 ii debhelper12.6.1 ii dpkg-dev 1.19.7 ii fakeroot 1.24-1 ii libasound2 1.1.8-1 ii libfontconfig1 2.13.1-2+b1 ii libgl1-mesa-glx 19.1.6-1 ii libgtk2.0-0 2.24.32-4 ii libx11-6 2:1.6.7-1 ii libxslt1.1 1.1.32-2.1 ii libxtst6 2:1.2.3-1 ii libxxf86vm1 1:1.1.4-1+b2 ii unzip6.0-25 java-package recommends no packages. Versions of packages java-package suggests: pn openjdk-7-jre signature.asc Description: PGP signature
Bug#933225: Request for a debian-latinoamerica mailing list
El 12/08/19 a las 21:19, Alexander Wirt escribió: > On Sat, 27 Jul 2019, Santiago R.R. wrote: > > > Package: lists.debian.org > > Severity: wishlist > > > > I am filing this bug on behalf of the people that participated in the > > Debian Latin America y Caribe Meeting during DC19 [0,1]. > > > > [0] https://debconf19.debconf.org/talks/162-latin-america-y-caribe-meeting/ > > [1] https://pad.riseup.net/p/dc19latin-keep > > > > Name: debian-latinoamerica > I create your list as debian-dug-latinoamer...@lists.debian.org \O/ thanks! -- Santiago signature.asc Description: PGP signature
Bug#933225: Request for a debian-latinoamerica mailing list
Package: lists.debian.org Severity: wishlist I am filing this bug on behalf of the people that participated in the Debian Latin America y Caribe Meeting during DC19 [0,1]. [0] https://debconf19.debconf.org/talks/162-latin-america-y-caribe-meeting/ [1] https://pad.riseup.net/p/dc19latin-keep Name: debian-latinoamerica Rationale The Debian communities in the different Latin American countries have their own mailing list/communication media. We think that a common and multilingual mailing list would be very useful to coordinate activities and strenght links among the different countries. Short Description: Debian in Latin America Long description Multi-lingual mailing list to discuss different topics relating to Debian the Latin America countries. Category: users Subscription Policy: open Post Policy: open Web Archive: yes Please, create a mailing list for the Latin American Debian community. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#927179: RM: hippo-canvas -- ROM; obsolete
Package: ftp.debian.org Severity: normal Dear FTPmasters, Please remove hippo-canvas from unstable. This code is unmaintained upstream, I haven't gave any love to it for a long time ago, and its last reverse dependencies have been removed (see https://bugs.debian.org/906800). Cheers, -- Santiago signature.asc Description: PGP signature
Bug#910754: dnsruby: warning: constant ::TimeoutError is deprecated
Source: dnsruby Severity: normal Tags: upstream patch Dear maintainer, dnsruby uses TimeoutError that was deprecated in ruby2.3. Just requiring dnsruby produces this warning in stretch (ruby2.3) and sid (ruby2.5): irb(main):001:0> require "dnsruby" /usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is deprecate This was fixed upstream: https://github.com/alexdalitz/dnsruby/commit/31a2a6b4b533f056c6e18ec9439ba0f65bc6b638 Cheers, -- Santiago signature.asc Description: PGP signature
Bug#909021: monero: include latest DNS trust anchor (KSK-2017)
Source: monero Severity: important Tags: upstream Hi, The DNS Root Key Signing Key (KSK) Rollover is scheduled for 11 October 2018 [1]. After this date, DNS query resolution will need to have the new key (KSK-2017) to perform DNSSEC validation. [1] https://www.icann.org/news/announcement-2018-08-22-en AFAICS, monero implements its own DNS resolver, and has the KSK-2010 built-in [2]: [2] https://sources.debian.org/src/monero/0.12.3.0%7Edfsg-1/src/common/dns_utils.cpp/#L104 Without the new key, monero users may encounter problems once the rollover occurs. Please, consider including the KSK-2017, already found in upstream source code [3]: [3] https://github.com/monero-project/monero/commit/5083614ffa84109fccd754ee5509b25030bec9a6 Best regards, -- Santiago signature.asc Description: PGP signature
Bug#908903: zonecheck unusable in buster/sid
Package: zonecheck Version: 3.0.5-3 Severity: grave Dear Sebastien, zonecheck in my sid environment is unusable. It ends up in ERROR when e.g. checking debian.org: /usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is deprecated /usr/lib/ruby/vendor_ruby/Dnsruby/code_mapper.rb:110: warning: constant ::Fixnum is deprecated [… removing duplicated warnings] ZONE : debian.org NS <= : dnsnode.debian.org [194.146.106.126, 2001:67C:1010:32::53] NS: sec2.rcode0.net [176.97.158.100, 2001:67C:10B8::100] NS: sec1.rcode0.net [192.174.68.100, 2001:67C:1BC::100] /usr/share/zonecheck/test/connectivity.rb:128: warning: Object#timeout is deprecated, use Timeout.timeout instead. [… removing duplicated warnings] # terminated with exception (report_on_exception is true): /usr/lib/ruby/vendor_ruby/Dnsruby/dnssec.rb:260:in `try_validation': comparison of Integer with Dnsruby::Message::SecurityLevel failed (ArgumentError) from /usr/lib/ruby/vendor_ruby/Dnsruby/dnssec.rb:229:in `validate_with_query' from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:108:in `validate' from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:60:in `do_validate' from /usr/lib/ruby/vendor_ruby/Dnsruby/validator_thread.rb:37:in `block in run' ERROR: comparison of Integer with Dnsruby::Message::SecurityLevel failed In stretch, I am getting the same Object#timeout warnings, but at least it returns no error, and debian.org gets a SUCCESS :) /usr/lib/ruby/vendor_ruby/dnsruby.rb:413: warning: constant ::TimeoutError is deprecated ZONE : debian.org NS <= : dnsnode.debian.org [194.146.106.126, 2001:67C:1010:32::53] NS: sec1.rcode0.net [192.174.68.100, 2001:67C:1BC::100] NS: sec2.rcode0.net [176.97.158.100, 2001:67C:10B8::100] /usr/share/zonecheck/test/connectivity.rb:128:in `chk_udp': Object#timeout is deprecated, use Timeout.timeout instead. [… removing duplicated warnings] ___ ,---.| |warning|| ~ `---' w> The 'refresh' period should be between 1H and 2D | Adv: default registry policy | The registry requires the SOA fields to be inside a defined range: | the 'expire' should be between 1W and 6W, the 'minimum' between 3M and | 1W, the 'refresh' between 1H and 2D, and at last the 'retry' between | 15M and 1D. `- -- -- - - - : The refresh value is 30M and should be between 1H and 2D. `. .. .. . . . => dnsnode.debian.org/2001:67C:1010:32::53 => dnsnode.debian.org/194.146.106.126 => sec1.rcode0.net/192.174.68.100 => sec2.rcode0.net/176.97.158.100 => sec2.rcode0.net/2001:67C:10B8::100 => sec1.rcode0.net/2001:67C:1BC::100 w> The 'retry' period should be between 15M and 1D | Adv: default registry policy | The registry requires the SOA fields to be inside a defined range: | the 'expire' should be between 1W and 6W, the 'minimum' between 3M and | 1W, the 'refresh' between 1H and 2D, and at last the 'retry' between | 15M and 1D. `- -- -- - - - : The retry value is 10M and should be between 15M and 1D. `. .. .. . . . => dnsnode.debian.org/2001:67C:1010:32::53 => dnsnode.debian.org/194.146.106.126 => sec1.rcode0.net/192.174.68.100 => sec2.rcode0.net/176.97.158.100 => sec2.rcode0.net/2001:67C:10B8::100 => sec1.rcode0.net/2001:67C:1BC::100 ==> SUCCESS (but 12 warning(s)) JFTR, according to https://www.nic.cz/public_media/IT15/prezentace/Patrik_Wallstrom.pdf (slide 3), zonecheck (in ruby) is considered as old code. It has been deprecated in favor of zonemaster (in perl), currently RFP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780184 Cheers, -- Santiago -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_CO.utf8, LC_CTYPE=es_CO.utf8 (charmap=UTF-8), LANGUAGE=es_CO:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages zonecheck depends on: ii iputils-ping 3:20180629-2 ii ruby 1:2.5.1 ii ruby-dnsruby 1.54-2 Versions of packages zonecheck recommends: pn libopenssl-ruby zonecheck suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#908888: Please update the upstream version (1.61.2)
Source: dnsruby Version: 1.54-2 Severity: normal Tags: upstream Hi Ondřej, Please, consider packaging a more recent version of dnsruby. The newest as of today is 1.61.2: https://rubygems.org/gems/dnsruby/versions/1.61.2 Cheers, and thanks for your work, -- Santiago signature.asc Description: PGP signature
Bug#908887: dnsruby: include latest DNS trust anchor (KSK-2017)
Source: dnsruby Severity: important Tags: upstream patch Hi Ondřej, The DNS Root Key Signing Key (KSK) Rollover is scheduled for 11 October 2018 [1]. After this date, DNS resolvers will need to have the new key (KSK-2017) to perform DNSSEC validation. [1] https://www.icann.org/news/announcement-2018-08-22-en AFAICS, dnsruby has the KSK-2010 built-in [2], and enables dnssec by default. Users or software relying on dnsruby may encounter problems once the rollover occurs. [2] https://sources.debian.org/src/dnsruby/1.54-2/lib/Dnsruby/dnssec.rb/#L82 Unless #760469 got fixed (dnsruby: Please use root zone hints, key or anchor from dns-root-data package), dnsruby should also include the KSK-2017 key. Upstream has added it in the current master branch: https://github.com/alexdalitz/dnsruby/commit/55edc31a2150e4617edb6664d440e6141f535e6a Best regards, -- Santiago P.S. Since dnssec seems to be enabled by default, the bug severity could be maybe higher. But I let Ondřej decide :) signature.asc Description: PGP signature
Bug#908652: openssh: Regression from DLA-1500-1: DISPLAY "(null)" invalid; disabling X11 forwarding
Control: tags -1 confirmed El 12/09/18 a las 10:36, Salvatore Bonaccorso escribió: > Source: openssh > Version: 1:6.7p1-5+deb8u6 > Severity: normal > > Hi > > DLA-1500-1 introduced the following regression: In cases where > ForwardX11 is enabled, say globally for all via ssh_config, or via > command line switch, but no DISPLAY is set (e.g. in cronjob), then newly > a > > > DISPLAY "(null)" invalid; disabling X11 forwarding > > is issued. > > root@jessie-amd64:~# unset DISPLAY > root@jessie-amd64:~# ssh -X root@localhost uname -a > DISPLAY "(null)" invalid; disabling X11 forwarding > Linux jessie-amd64 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 > GNU/Linux > root@jessie-amd64:~# > > Downgrading to 1:6.7p1-5+deb8u5 fixes the problem: > > root@jessie-amd64:~# unset DISPLAY > root@jessie-amd64:~# ssh -X root@localhost uname -a > Linux jessie-amd64 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 > GNU/Linux > root@jessie-amd64:~# > > This seem to be a specific regression in 1:6.7p1-5+deb8u6, the behaviour is > not seen on > either unstable (1:7.8p1-1) or stretch (1:7.4p1-10+deb9u4), so maybe > one of the adressed issues misses a prerequisite commit? Taking a quick look at it, I suppose the bug relates to the CVE-2016-1908 fix. For the record, the bug is also present in ubuntu 14.04 (trusty), where I took the relevant patches from: root@ubuntu-trusty:/# unset DISPLAY ; ssh -X ubuntu@localhost uname -a DISPLAY "(null)" invalid; disabling X11 forwarding Linux ubuntu-trusty 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 x86_64 x86_64 GNU/Linux root@ubuntu-trusty:/# unset DISPLAY ; ssh ubuntu@localhost uname -a Linux ubuntu-trusty 4.17.0-3-amd64 #1 SMP Debian 4.17.17-1 (2018-08-18) x86_64 x86_64 x86_64 GNU/Linux Thanks for your report! I will fix it ASAP. cheers, -- S signature.asc Description: PGP signature
Bug#907887: dnsmasq: Update root DNSSEC trust anchor in stretch and jessie
Source: dnsmasq Version: 2.72-3+deb8u2 Severity: important Tags: patch Hi Simon, The DNS Root Key Signing Key (KSK) Rollover is scheduled for 11 October 2018 [1]. After this date, DNS resolvers will need to have the new key (KSK-2017) to perform DNSSEC validation. [1] https://www.icann.org/news/announcement-2018-08-22-en AFAICS, dnsmasq in stretch and jessie [2] currently lacks the new key, and unless the dns-root-data package is additionally installed, users relying on dnsmasq for DNS resolution may encounter problems once the rollover occurs. [2] https://sources.debian.org/src/dnsmasq/2.76-5+deb9u1/trust-anchors.conf/ https://sources.debian.org/src/dnsmasq/2.72-3+deb8u2/trust-anchors.conf/ I think cherry-picking the commit [3] should prevent this in both suites. [3] http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=05da782f8f45933915af0ef3cc1ba35e31d20c59 Would you agree on this change, and, would you like to prepare the uploads by yourself? I am CCing the security team to have their opinion, whether this should be handled via a security or a stable upload in stretch. Concerning jessie, following the LTS workflow is required: https://wiki.debian.org/LTS/Development If that LTS workflow is a burden for you, a member of the LTS team could take care of it. Best regards, -- Santiago P.S. The hypothetical upload could also fix CVE-2017-15107 [3] ? [3] https://security-tracker.debian.org/tracker/CVE-2017-15107 signature.asc Description: PGP signature
Bug#906158: intel-microcode: Update intel-microcode to 20180807
Hi, I cannot talk for the maintainer either, but AFAIU the new license doesn't make it possible for Debian to distribute the binaries. Gentoo has concluded that also, and that the files cannot be mirrored. El 19/08/18 a las 09:36, Markus Schade escribió: … > could you please clarify what concerns Debian has with the license? AFAICS, there are different points that Debian would be concerned about. Starting with: DO NOT DOWNLOAD, INSTALL, ACCESS, COPY, OR USE ANY PORTION OF THE SOFTWARE UNTIL YOU HAVE READ AND ACCEPTED THE TERMS AND CONDITIONS OF THIS AGREEMENT. (I didn't have to read the agreement to download, install…) And then: 2. LIMITED LICENSE. Conditioned on Your compliance with the terms and conditions of this Agreement, Intel grants to You … to (iii) distribute an object code representation of the Software, provided by Intel, through multiple levels of distribution, solely as embedded in or for execution on an Intel-based product and subject to these license terms, and if to an end user, pursuant to a license agreement with terms and conditions at least as restrictive as those contained in the Intel End User Software License Agreement in Appendix A hereto. Distribution to derivatives is problematic: 3. LICENSE RESTRICTIONS. … Unless expressly permitted under the Agreement, You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; … (iii) use or make the Software available for the use or benefit of third parties; And then, there are some restrictions, for which I am not sure we (Debian) would be concerned, such as 13. export, directly or indirectly", to some countries, or 14. "You will not provide the Software to the U.S. Government." Maybe it would be needed to change the package to provide a download helper from the intel servers? The user should have to be asked to accept or not the license and its appendix A. Cheers, -- S signature.asc Description: PGP signature
Bug#898694: FTBFS with cowbuilder when network access is disabled
Source: ruby2.3 Version: 2.3.3-1+deb9u2 Severity: serious Other than the Failures in #889117, current ruby2.3 package fails to build due to Rinda TestRingFinger and TestRingServer trying to access network ressources: … 6) Error: Rinda::TestRingFinger#test_make_socket_ipv4_multicast: Errno::ENETUNREACH: Network is unreachable - connect(2) for 239.0.0.1:7647 /build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `connect' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `make_socket' /build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:782:in `test_make_socket_ipv4_multicast' 7) Error: Rinda::TestRingFinger#test_make_socket_ipv4_multicast_hops: Errno::ENETUNREACH: Network is unreachable - connect(2) for 239.0.0.1:7647 /build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `connect' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:431:in `make_socket' /build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:809:in `test_make_socket_ipv4_multicast_hops' 8) Error: Rinda::TestRingServer#test_make_socket_ipv4_multicast: Errno::ENODEV: No such device - setsockopt(2) /build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `setsockopt' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `make_socket' /build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:626:in `test_make_socket_ipv4_multicast' 9) Error: Rinda::TestRingServer#test_ring_server_ipv4_multicast: Errno::ENODEV: No such device - setsockopt(2) /build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `setsockopt' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:154:in `make_socket' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:108:in `block in initialize' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:106:in `each' /build/ruby2.3-2.3.3/lib/rinda/ring.rb:106:in `initialize' /build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:667:in `new' /build/ruby2.3-2.3.3/test/rinda/test_rinda.rb:667:in `test_ring_server_ipv4_multicast' 15919 tests, 2236057 assertions, 5 failures, 4 errors, 82 skips … I am preparing a commit to solve this in the stretch git branch. cheers, Santiago -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.UTF-8 (charmap=UTF-8), LANGUAGE=es_CO:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled signature.asc Description: PGP signature
Bug#895436: RM: paxrat -- ROM; useless without grsecurity/PaX
Package: ftp.debian.org Severity: normal On Wed, 11 Apr 2018 15:30:06 +0200 Yves-Alexis Perezwrote: … > since there is no publically available version of grsecurity anymore, > and it's not possible to forward-port the latest public version due to > KAISER inclusion, I'm requesting the removal of linux-grsec from > unstable. There is not point in keeping paxrat if linux-grsec is removed from unstable. So I hereby request its removal. Thanks, Santiago signature.asc Description: PGP signature
Bug#893318: grep.1: Some fixes in the manual
Hi Bjarni, El 17/03/18 a las 23:15, Bjarni Ingi Gislason escribió: > Package: grep > Version: 3.1-2 > Severity: minor > Tags: patch > > Dear Maintainer, > > Input file is grep.in.1 > > Test nr. 2: > > Enable and fix warnings from 'test-groff'. > … Thanks for you bug report. could you provide details about how to reproduce those tests (and confirm the patch solves the warnings)? Cheers, S signature.asc Description: PGP signature
Bug#891932: CVE-2018-7440 gplotMakeOutput() command injection vulnerability
Source: leptonlib Version: 1.75.3-2 Severity: grave Tags: security patch Hi, the following vulnerability was published for leptonlib. CVE-2018-7440[0]: | An issue was discovered in Leptonica through 1.75.3. The | gplotMakeOutput function allows command injection via a $(command) | approach in the gplot rootname argument. This issue exists because of | an incomplete fix for CVE-2018-3836. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-7440 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7440 An upstream patch is available at: https://github.com/DanBloomberg/leptonica/pull/313/commits/49ecb6c2dfd6ed5078c62f4a8eeff03e3beced3b Please adjust the affected versions in the BTS as needed. signature.asc Description: PGP signature
Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs
On Thu, 22 Feb 2018 22:26:13 -0800 Jeff Breidenbachwrote: > This is the patch I used for Leptonica 1.74. It should work fine for > earlier versions. > Upstream used a different approach for addressing the problem in version > 1.75. Hi Jeff, I have been unable to reproduce the issue in earlier versions. Do you have any clue about other conditions to reproduce it: TMPDIR=/var/tmp tesseract /tmp/ANY/PATH/XFig-LaTeX-together.jpg - - Error in pixGenerateHalftoneMask: pix too small: w = 71, h = 100 Oveyloyxng Text Ovevluymg Text Ovenaywng Tex‘ Thanks, -- Santiago signature.asc Description: PGP signature
Bug#891596: CVE-2018-7409
Source: unixodbc Version: 2.3.4-1.1 Severity: grave Tags: security Hi, the following vulnerability was published for unixodbc. CVE-2018-7409[0]: | In unixODBC before 2.3.5, there is a buffer overflow in the | unicode_to_ansi_copy() function in DriverManager/__info.c. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2018-7409 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7409 Please adjust the affected versions in the BTS as needed. signature.asc Description: PGP signature
Bug#891086: grep: Previous versios took -a as default if files where binary or part binary.
El 23/02/18 a las 08:42, Caronte Estigia escribió: > I have a text file, identified as a html document by "file" command which only > contains (from what I can see on the file) text characters. In that file there could you share that file (privately if you prefer)? > are numerous strings containing "2018", but when I use grep to find that > string > I get: > > Calendario > > anterior > > siguiente > Sumario BOE-S-2018-47: > title > ="BOE-S-2018-47 en formato PDF firmado " onclick="javascript: > pageTracker._trackPageview('/boe/dias/2018/02/22/pdfs/BOE-S-2018-47.pdf');">PDF > > "Sumario jueves 22 de febrero de 2018 como documento XML">XML > Notificaciones > --->Coincidencia en el fichero binario ayer.html< Could you try to grep the file previously setting LC_ALL='C'? (and without the -a option) What is the output of `locale -a` > Using previous grep version all strings were found, but now if I want grep to > work as before I need to use "grep -a". > > I guess the previous version of grep took "-a" behaviour as the default one, That is not exact. Take a look at /usr/share/doc/grep/NEWS.gz, to changes made in 2.21 and 2.23 versions. You would find some explanations there. > which treated all files as text unless specified otherwise (which in my > opinion > is the right way to go), I can't happen to see the security issues in this > behaviour and how those security issues dissapear if I specify the "-a" > parameter. Looks to me (without reviewing grep's code) that it is trying to > identify what kind of file it is checking while searching the file (a couple > of > lines are found before the binary message), and I guess it shouldn't do that. > I > think it just have to treat files as text unless specified otherwise with the > --binary-files parameter. signature.asc Description: PGP signature
Bug#891086: grep: Previous versios took -a as default if files where binary or part binary.
El 22/02/18 a las 11:18, rodrifra escribió: > Package: grep > Version: 2.27-2 > Severity: normal > > Dear Maintainer, > > >* What led up to the situation? > >Scripts working with grep stopped working after the update. No patterns > where detected ant the message informing of coincidences in the binary file > was displayed. The file is a downloaded html and "file" command returns: > >selecc.html: HTML document, ISO-8859 text, with CRLF, LF line terminators > >* What exactly did you do (or not do) that was effective (or > ineffective)? > >Explicitly indicating grep to treat the file as text solved the problem: > "grep -a " > > -- System Information: > Debian Release: 9.3 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core) > Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), > LANGUAGE=es_ES.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > I suppose you upgraded from jessie to stretch. I am not sure of fully understanding your message. Could you please clarify what version of grep didn't detect the patterns? Anyway, as far as I understand from upstream's comments, grep's previous behaviour when detecting "binary files" was not suitable. The change was made to avoid security issues, or undetermined behaviours, that could be related to invalid characters. In your case, the .html file could include invalid chars at the beginning, or the encoding is maybe wrong. This is probably not a bug. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#890862: debian-security-support: Please change from su to runuser
El 20/02/18 a las 00:31, Jakobus Schürz escribió: … > in /usr/share/debian-security-support/check-support-status.hook is su > used. This is a problem, because su starts a full pam-session. Since > many years there is "runuser" in util-linux, built from the source of > su. runuser does the same as su, but without starting a session in pam. > > runuser is the equivalent for su in daemons. Using su causes for example > xdg-user-dirs which installs the directories Desktop, Downloads and so > on in /var/lib/debian-security-support. Using runuser instead, all is > working the same as before, but no user-specific xdg-programs are > running. > > I have a problem with su, because i have a user-configuration, which > mounts a special fuse-filesystem, and this throws me an error on every > "apt install", which calls debian-security-support und it creates the > xdg-user-dirs. … Thanks for reporting this. However, it seems that runuser is available since stretch, and an alternative supported by wheezy and jessie would be needed. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#886733: regression in poppler (was: [SECURITY] [DSA 4079-1] poppler security update)
On Tue, 23 Jan 2018 10:14:05 +0100 Moritz Muehlenhoffwrote: ... > Updated packages are in preparation, you can the stretch builds at > https://people.debian.org/~jmm/poppler/, let me know if you still run > into problems with those. Oups! Sorry, I failed to detect that when I backported the patch. Thanks Moritz for have fixed it. -- Santiago
Bug#849864: Bug#883170: Bug#849864: paxrat: Please run paxrat during (early) boot
El 13/12/17 a las 06:43, intrigeri escribió: > Santiago R.R.: > > On Mon, 16 Jan 2017 17:50:15 +0100 intrigeri <intrig...@debian.org> wrote: > >> santiag...@riseup.net: > >> > I am not expert on writing systemd units, and I am unable to play with > >> > this soon. So it would be great if you could propose a patch :-) > >> > >> Sure. I might do it once I start using paxrat on systems without > >> live-config (but paxrat is less needed on those systems, so perhaps > >> I'll go with one of the other options instead). > > > Something like the attached would do the trick? > > Sorry, my interest in paxrat went down to zero since the grsec > patchset is not available as freely as it used to. I understand. Mine was (somehow) renewed after corsac recently uploaded the minipli's grsec. We'll see how this evolves. Cheers, -- Santiago
Bug#849864: paxrat: Please run paxrat during (early) boot
On Mon, 16 Jan 2017 17:50:15 +0100 intrigeriwrote: > santiag...@riseup.net: > > I am not expert on writing systemd units, and I am unable to play with > > this soon. So it would be great if you could propose a patch :-) > > Sure. I might do it once I start using paxrat on systems without > live-config (but paxrat is less needed on those systems, so perhaps > I'll go with one of the other options instead). Hi, Something like the attached would do the trick? It should run paxrat in watcher mode at early boot. It works on my machine. Although, paxrat seems to run twice: … paxrat[570]: 2017/12/12 13:56:13 Setting 'E' PaX flags via xattr on /usr/sbin/grub-bios-setup paxrat[570]: 2017/12/12 13:56:13 Starting paxrat watcher paxrat[570]: 2017/12/12 13:56:13 Setting 'E' PaX flags via xattr on /usr/sbin/grub-bios-setup paxrat[570]: 2017/12/12 13:56:13 Starting paxrat watcher … I wonder if this also be useful to solve #883170. paxrat in watcher mode should set the flags once /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java has been installed. Emmanuel, could you give it a try? Cheers, -- Santiago [Unit] Description=Paxrat watcher mode After=local-fs.target DefaultDependencies=no AssertPathExists=/sbin/paxrat Documentation=man:paxrat(8) [Service] Type=simple ExecStart=/sbin/paxrat -w RemainAfterExit=yes [Install] WantedBy=sysinit.target
Bug#883733: Wrong results with regex backreferences
Control: clone -1 -2 Control: reassign -2 glibc Control: retitle -2 glibc: Wrong results with regex backreferences Control: forwarded -2 https://sourceware.org/bugzilla/show_bug.cgi?id=11053 Control: block -1 by -2 El 08/12/17 a las 10:34, Paul Eggert escribió: > On 12/08/2017 03:11 AM, Santiago R.R. wrote: > > $ echo 1 | grep -E '^(11+)\1+$|^1?$' ; echo $? > > 1 > > 0 > > > > Shouldn't the last grep command exit 1 too? > > Yes it should. This appears to be due to a longstanding bug in the glibc > regular expression matcher. See: > > https://sourceware.org/bugzilla/show_bug.cgi?id=11053 > Hi, Thanks for the info. I am reassigning this bug to glibc (and keeping a copy of it for grep, in case possible future users will notice the issue). Cheers, -- Santiago
Bug#883733: Debian Bug#883733: grep returns 0 even if there is no match
Dear grep developers, I would like to forward the report below, filed by Mathias Pietsch to Debian. I don't want to introduce other noise than this: $ echo 1 | grep -E '^1?$' ; echo $? 1 $ echo 1 | grep -E '^(11+)\1+$' ; echo $? 1 $ echo 1 | grep -E '^(11+)\1+$|^1?$' ; echo $? 1 0 Shouldn't the last grep command exit 1 too? Cheers, -- Santiago - Forwarded message from Mathias Pietsch- Date: Wed, 6 Dec 2017 23:51:52 +0100 From: Mathias Pietsch To: Debian Bug Tracking System Subject: Bug#883733: grep returns 0 even if there is no match X-Mailer: reportbug 7.1.7 Package: grep Version: 2.27-2 Severity: normal Tags: upstream when trying to test this famous regexp for matching non-prime numbers (^1?$|^(11+?)\1+$) which works fine with 'grep -P', i wondered if it also would work without the non-greedy quantifier so egrep or even plain grep could use it, and found the following problem e.g., with the prime number 13: $ echo "1" | grep -E '^(11+)\1+$|^1?$' || echo prime 1 the expected output would have been 'prime' because '1' doesn't match '^1?$' and is also no concatanation of two or more '11', two or more '111', ... opposite to the orignal perl-style non-greedy version, here the substrings should be tested for a match beginning with the longest (13 x '1') down to the shortest ('11'). next i removed the empty line term from the regexp (i.e., the '?' from the '^1?$' term): $ echo "1" | grep -E '^(11+)\1+$|^1$' || echo prime prime now the result is correct. but since the input in not an empty line, using '^(11+)\1+$|^1?$' or '^(11+)\1+$|^1$' should not make any difference. (making the empty line term a separate term '^(11+)\1+$|^1$|^$' doesn't change anything. the same is true with using plain grep and '^\(11\+\)\1\+$\|^1\?$' or '^\(11\+\)\1\+$\|^1$\|^$'.) this bug also appears in the original upstream version 3.1 (http://ftp.gnu.org/gnu/grep/grep-3.1.tar.xz) -- System Information: Debian Release: 9.3 APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages grep depends on: ii dpkg 1.18.24 ii install-info 6.3.0.dfsg.1-1+b2 ii libc6 2.24-11+deb9u2 ii libpcre3 2:8.39-3 grep recommends no packages. Versions of packages grep suggests: ii libpcre3 2:8.39-3 -- no debconf information ━━━ Universitätsklinikum Hamburg-Eppendorf; Körperschaft des öffentlichen Rechts; Gerichtsstand: Hamburg | www.uke.de Vorstandsmitglieder: Prof. Dr. Burkhard Göke (Vorsitzender), Prof. Dr. Dr. Uwe Koch-Gromus, Joachim Prölß, Martina Saurin (komm.) ━━━ SAVE PAPER - THINK BEFORE PRINTING - End forwarded message -
Bug#881328: mininet requires missing ovs-controller
El 03/12/17 a las 14:38, Tomasz Buchert escribió: > On 30/11/17 09:26, Santiago R.R. wrote: > > Control: tags -1 + patch fixed-upstream > > > > On Fri, 10 Nov 2017 12:15:39 +0100 "Santiago R.R." <santiag...@riseup.net> > > wrote: > > > > It seems I am wrong about this. > > The bug was only happening if you would have > openvswitch-testcontroller installed. The reason is that mininet fails > to detect the path of the test controller. The patch you provided fixes > the issue. Just for the record: If you are talking about package names, it happened in unstable if you had openvswith-common installed: dpkg -S /usr/bin/ovs-testcontroller openvswitch-common: /usr/bin/ovs-testcontroller LANG=C.UTF-8 dpkg -l openvswitch-common ii openvswitch-common 2.8.1+dfsg1-3 amd64 Open vSwitch common components ... > > P.S. Question for openvswitch maintainers: does it make sense to include > > back /usr/bin/ovs-testcontroller in the -testcontroller package? > > Thanks, I've added the patch and will upload the package later today. Thanks for uploading it! Cheers, -- Santiago
Bug#883213: Please package new 2.x version (now named nyx)
Package: tor-arm Severity: wishlist Dear Ulises, A new arm version, now renamed Nyx, has been released. Please, consider packaging it: https://nyx.torproject.org/changelog/index.html#version-2-0 Cheers, -- Santiago
Bug#883170: java is paxctl-ed too late
El 30/11/17 a las 11:56, Emmanuel Seyman escribió: > Package: paxrat > Version: 1.0-3+b1 > > When I install openjdk-8-jre-headless, it installs ca-certificates-java as > a dependency. ca-certificates-java's postinst is called and killed by grsec > because it calls "java -Xmx64m -jar [...]". > > Once that happens, paxrat is then executed and paxctl is run on > /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java. A "apt-get install -f" will > then run ca-certificates-java's postinst again which will complete. Quick answer: I wonder if the solution would be rather in ca-certificates-java. If a user running a grsec kernel and no paxrat installed would get the same problem. ca-certificates-java's postinst would call paxrat or paxctl, if available. Opinions? -- Santiago
Bug#881328: mininet requires missing ovs-controller
Control: tags -1 + patch fixed-upstream On Fri, 10 Nov 2017 12:15:39 +0100 "Santiago R.R." <santiag...@riseup.net> wrote: … > mn tries to run ovs-controller, which has been renamed to > /usr/bin/ovs-testcontroller according to > https://github.com/openvswitch/ovs/blob/9a180f2c002adf73951e0ee9990c44e5e5cd4a0f/NEWS#L600 ovs-controller -> test-controller -> ovs-testcontroller https://github.com/openvswitch/ovs/blob/9a180f2c002adf73951e0ee9990c44e5e5cd4a0f/NEWS#L471 > mininet should Depends or Recomends on openvswitch-testcontroller It seems I am wrong about this. > > $ sudo mn --topo tree,depth=2,fanout=3 > *** Creating network > *** Adding controller > *** Adding hosts: > h1 h2 h3 h4 h5 h6 h7 h8 h9 > *** Adding switches: > s1 s2 s3 s4 > *** Adding links: > (s1, s2) (s1, s3) (s1, s4) (s2, h1) (s2, h2) (s2, h3) (s3, h4) (s3, h5) (s3, > h6) (s4, h7) (s4, h8) (s4, h9) > *** Configuring hosts > h1 h2 h3 h4 h5 h6 h7 h8 h9 > *** Starting controller > c0 Cannot find required executable ovs-controller. > Please make sure that it is installed and available in your $PATH: > (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) … > Versions of packages mininet depends on: > ii cgroup-bin0.41-8 > ii iperf 2.0.10+dfsg1-1 > ii libc6 2.24-17 > ii net-tools 1.60+git20161116.90da8a0-1 > ii openvswitch-switch2.8.1+dfsg1-3 > ii python2.7.14-1 > ii python-pkg-resources 36.6.0-1 > ii socat 1.7.3.2-1 > ii telnet0.17-41 (I am new on this, and I am trying to understand how mininet relies on openvswitch, so sorry if what I say doesn't make any sense.) Actually, the issue doesn't happen in stretch or buster, or more precisely, with openvswitch-switch 2.6.2~pre+git20161223-3. As far as I understand, the reason why mininet complains against openvswtich is because openvswith-common includes /usr/bin/ovs-testcontroller since 2.8.1+dfsg1-1. Binary that was part of openvswitch-testcontroller before. Installing -testcontroller in stretch or buster makes that mininet also complains. And it also seems that it was already fixed by upstream in commit 57abd9baef8b3ec3ce3c349829b37022cfef724a. Patch attached to this mail. Cheers, -- Santiago P.S. Question for openvswitch maintainers: does it make sense to include back /usr/bin/ovs-testcontroller in the -testcontroller package? From a5a3485edbb15d2442eb42d776fb9ba370526e7a Mon Sep 17 00:00:00 2001 From: Santiago <santiago.ruano-rin...@telecom-bretagne.eu> Date: Wed, 29 Nov 2017 18:30:12 +0100 Subject: [PATCH] Add debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch to take into account the three possible names of ovs-testcontroller Signed-off-by: Santiago <santiago.ruano-rin...@telecom-bretagne.eu> --- debian/patches/series | 1 + ...Use-correct-command-name-in-OVSController.patch | 38 ++ 2 files changed, 39 insertions(+) create mode 100644 debian/patches/series create mode 100644 debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch diff --git a/debian/patches/series b/debian/patches/series new file mode 100644 index 000..54f122c --- /dev/null +++ b/debian/patches/series @@ -0,0 +1 @@ +upstream_0001-Use-correct-command-name-in-OVSController.patch diff --git a/debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch b/debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch new file mode 100644 index 000..e91ea01 --- /dev/null +++ b/debian/patches/upstream_0001-Use-correct-command-name-in-OVSController.patch @@ -0,0 +1,38 @@ +From 57abd9baef8b3ec3ce3c349829b37022cfef724a Mon Sep 17 00:00:00 2001 +From: Bob Lantz <rla...@cs.stanford.edu> +Date: Tue, 24 May 2016 17:40:00 -0700 +Subject: [PATCH] Use correct command name in OVSController + +--- + mininet/node.py | 10 +- + 1 file changed, 5 insertions(+), 5 deletions(-) + +diff --git a/mininet/node.py b/mininet/node.py +index ea7851b..1e50b51 100644 +--- a/mininet/node.py b/mininet/node.py +@@ -1423,16 +1423,16 @@ def isAvailable( cls ): + + class OVSController( Controller ): + "Open vSwitch controller" +-def __init__( self, name, command='ovs-controller', **kwargs ): +-if quietRun( 'which test-controller' ): +-command = 'test-controller' +-Controller.__init__( self, name, command=command, **kwargs ) ++def __init__( self, name, **kwargs ): ++kwargs.setdefault( 'command', self.isAvailable() or ++ 'ovs-controller' ) ++Controller.__init__( self, name, **kwargs ) + + @classmethod + def isAvailable( cls ): + return ( quietRun( 'which ovs-controller' ) or + quietRun( 'which test-controller' ) or
Bug#882480: [Pkg-dpdk-devel] Bug#882480: Bug#882480: Bug#882480: Bug#882480: dpdk: autopkgtest dependencies are bad on s390x / any non-supported arch
El 23/11/17 a las 17:31, Luca Boccassi escribió: > On Thu, 2017-11-23 at 17:28 +0100, Santiago R.R. wrote: > > El 23/11/17 a las 13:29, Christian Ehrhardt escribió: > > > Submitted to deb_dpdk as [1], thank Dimitri. > > > I don't expect pushback on this, so this will likely be in Debian > > > (and > > > the Ubuntu sync) on 17.11.x > > > > Do you know what will be the next LTS version, that it would be > > possible/suitable to upload to unstable? > > > > I'd be happy to push this changes to the current version in unstable. > > Hi, > > 17.11 is an LTS. We just talked about it today, and the plan is to > upload it to experimental first (will do that shortly) to clear the > binary-NEW queue, and then to unstable and start a transition for the > reverse depends (collectd). Great! Thanks for your work.
Bug#882480: [Pkg-dpdk-devel] Bug#882480: Bug#882480: dpdk: autopkgtest dependencies are bad on s390x / any non-supported arch
El 23/11/17 a las 13:29, Christian Ehrhardt escribió: > Submitted to deb_dpdk as [1], thank Dimitri. > I don't expect pushback on this, so this will likely be in Debian (and > the Ubuntu sync) on 17.11.x Do you know what will be the next LTS version, that it would be possible/suitable to upload to unstable? I'd be happy to push this changes to the current version in unstable.
Bug#881328: mininet requires missing ovs-controller
Package: mininet Version: 2.2.2-1 Severity: grave Hi, mn tries to run ovs-controller, which has been renamed to /usr/bin/ovs-testcontroller according to https://github.com/openvswitch/ovs/blob/9a180f2c002adf73951e0ee9990c44e5e5cd4a0f/NEWS#L600 mininet should Depends or Recomends on openvswitch-testcontroller $ sudo mn --topo tree,depth=2,fanout=3 *** Creating network *** Adding controller *** Adding hosts: h1 h2 h3 h4 h5 h6 h7 h8 h9 *** Adding switches: s1 s2 s3 s4 *** Adding links: (s1, s2) (s1, s3) (s1, s4) (s2, h1) (s2, h2) (s2, h3) (s3, h4) (s3, h5) (s3, h6) (s4, h7) (s4, h8) (s4, h9) *** Configuring hosts h1 h2 h3 h4 h5 h6 h7 h8 h9 *** Starting controller c0 Cannot find required executable ovs-controller. Please make sure that it is installed and available in your $PATH: (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin) cheers, Santiago -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=es_CO.utf8, LC_CTYPE=es_CO.utf8 (charmap=UTF-8), LANGUAGE=es_CO:es (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages mininet depends on: ii cgroup-bin0.41-8 ii iperf 2.0.10+dfsg1-1 ii libc6 2.24-17 ii net-tools 1.60+git20161116.90da8a0-1 ii openvswitch-switch2.8.1+dfsg1-3 ii python2.7.14-1 ii python-pkg-resources 36.6.0-1 ii socat 1.7.3.2-1 ii telnet0.17-41 mininet recommends no packages. mininet suggests no packages. -- no debconf information
Bug#880974: ITP: lua-ljsyscall -- Unix system calls for LuaJIT
Package: wnpp Severity: wishlist Owner: "Santiago R.R." <santiag...@riseup.net> * Package name: lua-ljsyscall Version : 0.12 Upstream Author : Justin Cormack <jus...@specialbusservice.com> * URL : http://myriabit.com/ljsyscall/ * License : MIT/X Programming Lang: Lua Description : Unix system calls for LuaJIT A foreign function interface (FFI) implementation of the Linux, NetBSD, FreeBSD and OSX kernel ABIs for LuaJIT. This means you will be able to program all the functionality the Unix kernel provides to userspace directly in Lua. You can view it as a high level language equivalent of the Busybox project in a way, although the functionality it provides is somewhat different, and the interface very different. This is a dependency for https://github.com/vavrusa/ljdns Comaintaining it with the help of Lua packaging team would be great.
Bug#880975: ITP: lua-ljdns -- DNS library for LuaJIT
Package: wnpp Severity: wishlist Owner: "Santiago R.R." <santiag...@riseup.net> * Package name: lua-ljdns Version : 2.4 Upstream Author : Marek Vavruša <ma...@vavrusa.com> * URL : https://github.com/vavrusa/ljdns * License : BSD-2-clause Programming Lang: Lua Description : DNS library for LuaJIT A contemporary DNS library using LuaJIT FFI focused on performance, and a lightning-fast zone file parser. It supports all widely used DNS records (DNSSEC included) with a lean and mean API, including DNS primitives, messages and asynchronous I/O (including coroutines, TCP Fast Open and SO_REUSEPORT), and DNS over TLS. Co-maintaining it with the Lua packaging team would be great
Bug#874620: pppd: Doesn’t handle RADIUS IPv6 attributes
On Fri, 08 Sep 2017 08:17:34 +0200 alarigwrote: > Package: ppp > Version: 2.4.6-3.1+grif1 > Severity: important > Tags: upstream patch ipv6 … >* What exactly did you do (or not do) that was effective (or > ineffective)? > I patched pppd > https://marc.info/?l=linux-ppp=145226335014356=2 Alarig's patch found in that url was malformed by the width size of the text. Attached you can find a raw version, that I was able to use to build 2.4.7-1+4. I cannot test it by myself, though. HTH, -- Santiago >From 5c0cac0eeecc32e5023d353a8420633827800e8e Mon Sep 17 00:00:00 2001 From: Benjamin Cama Date: Sun, 11 Oct 2015 18:08:11 +0200 Subject: [PATCH] Handle IPv6 RADIUS attributes --- pppd/plugins/radius/avpair.c | 26 +- pppd/plugins/radius/dict.c | 12 pppd/plugins/radius/radiusclient.h | 11 +++ 3 files changed, 48 insertions(+), 1 deletion(-) diff --git a/pppd/plugins/radius/avpair.c b/pppd/plugins/radius/avpair.c index 716d23f..7536941 100644 --- a/pppd/plugins/radius/avpair.c +++ b/pppd/plugins/radius/avpair.c @@ -222,6 +222,9 @@ VALUE_PAIR *rc_avpair_gen (AUTH_HDR *auth) { case PW_TYPE_STRING: + case PW_TYPE_IFID: + case PW_TYPE_IPV6ADDR: + case PW_TYPE_IPV6PREFIX: memcpy (pair->strvalue, (char *) ptr, (size_t) attrlen); pair->strvalue[attrlen] = '\0'; pair->lvalue = attrlen; @@ -692,9 +695,10 @@ int rc_avpair_parse (char *buffer, VALUE_PAIR **first_pair) int rc_avpair_tostr (VALUE_PAIR *pair, char *name, int ln, char *value, int lv) { DICT_VALUE *dval; - charbuffer[32]; + charbuffer[INET6_ADDRSTRLEN + 4]; // for a prefix: addr + '/' + prefixlen struct in_addr inad; unsigned char *ptr; + char *str; *name = *value = '\0'; @@ -753,6 +757,26 @@ int rc_avpair_tostr (VALUE_PAIR *pair, char *name, int ln, char *value, int lv) strncpy(value, buffer, lv-1); break; + case PW_TYPE_IFID: + ptr = pair->strvalue; + snprintf(buffer, sizeof (buffer), "%x:%x:%x:%x", + (ptr[0] << 8) + ptr[1], (ptr[2] << 8) + ptr[3], + (ptr[4] << 8) + ptr[5], (ptr[6] << 8) + ptr[7]); + strncpy(value, buffer, lv-1); + break; + + case PW_TYPE_IPV6ADDR: + inet_ntop(AF_INET6, pair->strvalue, buffer, sizeof (buffer)); + strncpy(value, buffer, lv-1); + break; + + case PW_TYPE_IPV6PREFIX: + inet_ntop(AF_INET6, pair->strvalue + 2, buffer, sizeof (buffer)); + str = buffer + strlen(buffer); + snprintf(str, sizeof (buffer) - (str - buffer), "/%d", *(pair->strvalue + 1)); + strncpy(value, buffer, lv-1); + break; + default: error("rc_avpair_tostr: unknown attribute type %d", pair->type); return (-1); diff --git a/pppd/plugins/radius/dict.c b/pppd/plugins/radius/dict.c index 72b3e70..3b2add2 100644 --- a/pppd/plugins/radius/dict.c +++ b/pppd/plugins/radius/dict.c @@ -158,6 +158,18 @@ int rc_read_dictionary (char *filename) { type = PW_TYPE_DATE; } + else if (strcmp (typestr, "ifid") == 0) + { +type = PW_TYPE_IFID; + } + else if (strcmp (typestr, "ipv6addr") == 0) + { +type = PW_TYPE_IPV6ADDR; + } + else if (strcmp (typestr, "ipv6prefix") == 0) + { +type = PW_TYPE_IPV6PREFIX; + } else { error("rc_read_dictionary: invalid type on line %d of dictionary %s", diff --git a/pppd/plugins/radius/radiusclient.h b/pppd/plugins/radius/radiusclient.h index 51b959a..ab4ef2d 100644 --- a/pppd/plugins/radius/radiusclient.h +++ b/pppd/plugins/radius/radiusclient.h @@ -77,6 +77,17 @@ typedef struct pw_auth_hdr #define PW_TYPE_INTEGER 1 #define PW_TYPE_IPADDR 2 #define PW_TYPE_DATE 3 +#define PW_TYPE_ABINARY 4 +#define PW_TYPE_OCTETS 5 +#define PW_TYPE_IFID 6 +#define PW_TYPE_IPV6ADDR 7 +#define PW_TYPE_IPV6PREFIX 8 +#define PW_TYPE_BYTE 9 +#define PW_TYPE_SHORT 10 +#define PW_TYPE_ETHERNET 11 +#define PW_TYPE_SIGNED 12 +#define PW_TYPE_COMBO_IP 13 +#define PW_TYPE_TLV 14 /* standard RADIUS codes */ -- 2.1.4
Bug#876968: gnupg: Improve error message when changing passwd on an "empty" card
Package: gnupg Version: 2.2.1-1 Severity: normal Dear GnuPG Maintainers, I have no idea if this concerns Gnuk only, so sorry it cannot be improved in gnupg: When trying to change the passwd of my new gnuk token (v1.2.5), I got this error message: gpg/card> passwd gpg: OpenPGP card no. D276000124010200FFFE87062054 detected Error changing the PIN: Conditions of use not satisfied As told by gniibe-san, the "Conditions of use not satisfied" were the lack of private key installed in the token. After importing it, I was able to change the pass-phrase. It would be easier to figure out the problem if the error message said the private key was needed. Cheers, -- Santiago -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.45-21.pvops.qubes.x86_64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnupg depends on: ii dirmngr 2.2.1-1 ii gnupg-l10n 2.2.1-1 ii gnupg-utils 2.2.1-1 ii gpg 2.2.1-1 ii gpg-agent 2.2.1-1 ii gpg-wks-client 2.2.1-1 ii gpg-wks-server 2.2.1-1 ii gpgsm 2.2.1-1 ii gpgv2.2.1-1 gnupg recommends no packages. Versions of packages gnupg suggests: pn parcimonie pn xloadimage -- no debconf information
Bug#876137: bzip2: Please build udeb package
Hi Laurent, El 18/09/17 a las 23:14, Laurent Bigonville escribió: > Source: bzip2 > Version: 1.0.6-8.1 > Severity: wishlist > > Hi, > > It would be nice to build an udeb package. > > At least one package (freetype) could benefit of it as freetype can > optionally link against bzip to used bzipped compressed fonts. I haven't any experience on building udeb packages, and I don't know when I will have some free time to do it. But please, fell free to propose the required changes to build it. Cheers, -- Santiago
Bug#498336: grep: option to filter non-printable characters from contents
Dear grep upstream authors, I'd like to forward this bug reported to debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498336 On Tue, 9 Sep 2008 11:07:33 +0200 Vincent Lefevrewrote: … > > grep should have an option to filter non-printable characters from > the contents (file contents, but also filenames -- see bug #42630) > *before coloring*. The values could be "never", "always" and "auto", > like with --color. > > Such an option would be useful because: > > 1. The option --binary-files is a heuristic only; the user may want >to have more information on binary files anyway. > > 2. It is not even possible to write a wrapper script when coloring is >used, because after coloring, it is not possible (or at least very >difficult) to do the difference between escape sequences from grep >and those from the original contents. > > Such non-printable characters could be either replaced by some > locale-specific replacement character or transcoded. > > I wonder whether filtering should be the default when the output > is connected to a terminal (and when POSIXLY_CORRECT is not set). > It would not be worse than the default --binary-files=binary. … This option could be also useful to filter undesirable behaviors, such as ringing the bell terminal (from stdin in this case): printf '\a'x | grep x What's your position on this? Thanks, -- Santiago PS. As Vincent Lefevre says, this bug relates to filtering non-printable characters from filenames: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=42630
Bug#532541: bug#27931: grep -o fails to count empty lines (Debain Bug #532541)
El 03/08/17 a las 13:16, Paul Eggert escribió: > On 08/03/2017 06:28 AM, Santiago R.R. wrote: > > the -o option, which is supposed to return only the matching > > parts of the search, fails: > > It's not failing. It's behaving as documented: -o outputs only nonempty > matches. Otherwise, commands like 'grep -o "a*"' would output a separate > line for each byte in the input. Although this behavior for -o is > longstanding and is documented in the manual, it's not in the grep --help > output so that's an oversight. I installed the attached to fix grep --help, > and am closing the bug report on the GNU side. > > Users who want to match empty lines can use 'grep "^$"', which is what I'd > expect them to do anyway (-o would be superfluous there even if it included > empty matches). > Thanks for clarifying. I'll include the patch in Debian and close the bug accordingly. Santiago
Bug#532541: grep -o fails to count empty lines (Debain Bug #532541)
(Sorry if it's already filed, but I am unable to find it in the bug archives) Hi, I'd like to forward this bug reported to Debian some years ago. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532541 It still happens in 3.1. Quoting the original report: When grepping for empty lines in a text file, grep works correctly in most cases: ~$ grep ^$ myfile.txt ~$ grep -n ^$ myfile.txt 11: 15: 19: 21: 22: However the -o option, which is supposed to return only the matching parts of the search, fails: ~$ grep -o ^$ myfile.txt ~$ grep -no ^$ myfile.txt ~$ Thanks, Santiago
Bug#868654: Combining Unicode Mark-Nonspacing are classified as [:punct:]
Source: glibc Version: 2.24-12 Severity: minor Control: block 662629 by -1 Hi, There is an issue on how glibc classifies the Unicode Mark-nonspacing category, that should be maybe [[:alpha:]] instead of [[:punct:]]. This was identified by the bug reported to grep: https://bugs.debian.org/662629 You can test it using the U+0301 acute accent: $ echo árbol | grep -o '[[:alpha:]]*' a rbol This is also the opinion by grep's upstream about it: "Surely this is a glibc bug, not a grep bug. Grep is just following the character classification of glibc. I can reproduce the problem by compiling and running the attached program, which uses only glibc (not grep). This program exits with status 1, whereas you want it to exit with status 0. So I suggest filing a glibc bug report." combining.c is attached to this mail. Cheers, -- Santiago
Bug#868133: grep: please make the build reproducible
Control: tags -1 + pending El 12/07/17 a las 11:36, Chris Lamb escribió: > Source: grep > Version: 3.1-1 > 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 grep could not be built reproducibly. > > Patch attached. Note that it modifies a file that is already modified > by an existing patch; I'll leave it up to you how you wish to merge > these. Hi Chris, and thanks for the heads-up. A patch of mine introduced the unreproducibility issue. I'll upload a new version replacing it with an upstream patch that should be OK. Cheers, Santiago
Bug#863002: grep missing path
Thanks for your report. However, I'm not sure it is a bug. El 19/05/17 a las 22:04, john mullee escribió: > Package: grep > Version: 2.20-4.1 > > cat /bin/egrep > #!/bin/sh > exec grep -E "$@" > > should replace with > > exec /bin/grep -E "$@" > > to reproduce: > > root@debian-512mb-fra1-01:/opt/firewall# bash > root@debian-512mb-fra1-01:/opt/firewall# PATH=/usr/local egrep "any" /etc/* > bash: egrep: command not found > I am afraid the behaviour of that command is not what you meant. You shell was looking for egrep at your modified path, it was not even able to read egrep's content. Try this: PATH=/usr/local grep a /etc/* zsh: command not found: grep PATH=/usr/local /usr/bin/which grep (empty) Or even: PATH=/usr/local ls zsh: command not found: ls Note also that the use of egrep, fgrep and rgrep variants is deprecated. You should use -E, -F or -r instead. Cheers, Santiago P.S. I will close this bug "soon" unless you are able to argue why it is actually a bug.
Bug#861837: libxen, libxen-dev: install libxenvchan library
Source: xen Version: 4.4.1-9+deb8u3 Severity: wishlist Hi, Qubes-OS related software requires libxenvchan from xen [0]. AFAIU, it is built by default (as found in buildd.d.o), but the Debian package doesn't install it. Could you please include it? [0] https://github.com/QubesOS/qubes-issues/issues/2739 Thanks! Santiago
Bug#851292: grep: finalize_input sometimes fails on stdin
El 13/01/17 a las 11:31, Akkana Peck escribió: > Package: grep > Version: 2.27-1 > Severity: normal > > Dear Maintainer, > > I have a procmail filter that runs: > > * ? (echo "$FROM" | /bin/egrep -i -f $SPASTDIR/fromAllow) > > and similar filters for toAllow, fromRejects etc. Sometimes -- only > with one file, fromAllow -- this fails on lines that actually match, > and in the procmail verbose log, it says: > > procmail: Executing " (echo "$FROM" | $GREP -i -f $SPASTDIR/fromAllow)" > grep: (standard input): Invalid argument > > This only started happening recently, and it appears to be a change > in grep. If I replace /bin/grep with the version from Debian stable, > everything works again and I never see that Invalid argument message. > On the other end I replace /bin/grep with the latest from > git://git.savannah.gnu.org/grep.git, that also works. > So I'm guessing this is a bug that was briefly introduced upstream, > but has since been fixed upstream and Debian hasn't yet included > the upstream fix. > […] Hi, Thanks for reporting this. Could you please test this package: https://people.debian.org/~santiago/debian/santiago-unstable/grep_2.27-2~1_amd64.deb It includes the upstream patches that I think concern this bug. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#831434: bzip2 not working with symbolic links: bzip2: Input file b.bz2 is not a normal file.
Dear Julian, Please find below a bug report filed against bzip2 in Debian. Is it expected that bzip2 does not follow symlinks? Best regards, Santiago El 15/07/16 a las 23:30, drcnjio908 escribió: > Package: bzip2 > Version: 1.0.6-8 > Severity: normal > > Dear Maintainer, > > Steps to reproduce: > echo test > a > bzip2 --compress --keep a > ln -s a.bz2 b.bz2 > bzip2 -d b.bz2 > bzip2: Input file b.bz2 is not a normal file. > > What I think it should do: > Extract the file the symbolic link points to. > > Related Bug: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=41217 > > -- System Information: > Debian Release: stretch/sid > APT prefers testing > APT policy: (950, 'testing'), (54, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages bzip2 depends on: > ii libbz2-1.0 1.0.6-8 > ii libc6 2.22-10 > > bzip2 recommends no packages. > > Versions of packages bzip2 suggests: > pn bzip2-doc > > -- debconf-show failed > signature.asc Description: PGP signature
Bug#824864: debian-security-support [INTL:po] Polish debconf template translation
Package: debian-security-support Severity: wishlist Tags: l10n patch pending El 19/05/16 a las 18:46, Łukasz escribió: > 12.05.2016 10:47, Santiago R.R. wrote: > > Please send the updated file to me, or submit it as a wishlist bug > > against debian-security-support. > I have translated it. I hope that my translation is correct. > > Best regards, > Łukasz Dulny Thank you, Łukasz To keep the record, I am filling a bug that will be closed with the next upload. Note: I have realised my translation request was not complete. As the comment in the pot file says, there are additional messages to translate, but I didn't aware the i18n teams about them. I need to ask to update/translate the very debian-security-support messages, found in po/. I will figure out if there is a way how to do this properly. Cheers, Santiago
Bug#816601: squid3: After last LTS upgrade, squid crash with 'assertion failed: forward.cc:298: "fd == server_fd"' error
El 03/03/16 a las 12:50, Marco Gaiarin escribió: > Package: squid3 > Version: 3.1.6-1.2+squeeze6 > Severity: important > > > After applying the last 'squeeze-lts' update, eg upgrading to, > 3.1.6-1.2+squeeze6, squid3 start to complain about the error on subject: > > 'assertion failed: forward.cc:298: "fd == server_fd" > > in cache.log; normally squid ''resume'' from that error (probably, > restarting), but sooner or later die. > > No other error happen on cache.log, nor there's change in configuration > before and after the upgrade. > > > Thanks. > Thanks for your report. I'm working on this and I'm waiting for feedback from upstream to confirm the fix is safe. Anyway, please consider upgrading to wheezy. Santiago