Bug#1034566: unblock: isc-dhcp/4.4.3-P1-1.1

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

(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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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)

[Santiago R.R.]

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)

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

Package: ftp.debian.org
Severity: normal

On Wed, 11 Apr 2018 15:30:06 +0200 Yves-Alexis Perez  wrote:
…
> 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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

On Thu, 22 Feb 2018 22:26:13 -0800 Jeff Breidenbach  wrote:
> 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

[Santiago R.R.]

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.

[Santiago R.R.]

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.

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

On Tue, 23 Jan 2018 10:14:05 +0100 Moritz Muehlenhoff  wrote:
...
> 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

[Santiago R.R.]

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

[Santiago R.R.]

On Mon, 16 Jan 2017 17:50:15 +0100 intrigeri  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).

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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)

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

On Fri, 08 Sep 2017 08:17:34 +0200 alarig  wrote:
> 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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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 Lefevre  wrote:
…
> 
> 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)

[Santiago R.R.]

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)

[Santiago R.R.]

(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:]

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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.

[Santiago R.R.]

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

[Santiago R.R.]

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

[Santiago R.R.]

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