Bug#1003085: small transition: libportal 0.5

[Simon McVittie]

Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libportal.html

On Tue, 04 Jan 2022 at 11:12:54 +0100, Emilio Pozuelo Monfort wrote:
> > I'd like to upgrade libportal from 0.4 (currently in testing) to 0.5
> > (in experimental).
>
> Go ahead.

libportal and gnome-builder uploaded to unstable and built on release
architectures. Please binNMU xdg-desktop-portal when convenient, I think
this might be correct:

nmu xdg-desktop-portal_1.12.1-1 . ANY . -m 'Rebuild with libportal 0.5 
(#1003085)'

Thanks,
smcv

Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle

[Marc Haber]

tags #1003154 moreinfo
thanks

On Tue, Jan 04, 2022 at 06:36:52PM -0800, H. S. Teoh wrote:
> PermissionError: [Errno 1] Operation not permitted
> c : fatal: ['/usr/bin/sudo', '-p', '[local sudo] Password: ', '/usr/bin/env', 
> 'PYTHONPATH=/usr/lib/python3/dist-packages', '/usr/bin/python3', 
> '/usr/bin/sshuttle', '-v', '--method', 'nft', '--firewall'] returned 1

Can you please verify whether this command also fails on the command
line, and then reduce the command line so that we can find out whatever
the current sudo doesn't like?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1003004: transition: capnproto

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-capnproto.html

On 2022-01-02 08:42:45 -0800, tony mancill wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi Release Team,
> 
> capnproto 0.8.0 has been in experimental for over a year now [1], so
> there is already an auto-transition page [2].
> 
> All of the reverse dependencies *except* for clickhouse should smoothly.
> clickhouse [3] is FTBFS against 0.8.0, but the package has already been
> removed from testing due to FTBFS against gcc 11 [4].  Given that
> clickhouse isn't receiving much attention and we have received requests
> to update captnproto, we would like to proceed with the transition.

Please go ahead

Cheers

> 
> Thank you,
> tony
> 
> [1] https://tracker.debian.org/pkg/capnproto
> [2] https://release.debian.org/transitions/html/auto-capnproto.html
> [3] https://tracker.debian.org/pkg/clickhouse
> [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996130
> 
> Ben file:
> 
> title = "capnproto";
> is_affected = .depends ~ "libcapnp-0.7.0" | .depends ~ "libcapnp-0.8.0";
> is_good = .depends ~ "libcapnp-0.8.0";
> is_bad = .depends ~ "libcapnp-0.7.0";



-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#1003130: ITP: luit in 2013.

[Timo Aaltonen]

On 4.1.2022 20.48, Thomas Dickey wrote:

On Tue, Jan 04, 2022 at 11:46:03AM -0500, Thomas Dickey wrote:

Package: x11-utils
Version: 7.7+5
Severity: normal

Dear Maintainer,

* x11-utils copy of luit was superseded by luit 2.0 in 2013.
* mentioned this several times to developers in X Strike Force
* developers did not reply to those comments
* developers could have suggested a way to address the issue

As a solution to that, I propose to create a new package "luit2",


Actually, the package should be named "luit", but the executable "luit2".



Hi, so are you going to maintain it?

If not, I don't see a point in creating a separate package for it. And I 
could only find a single message about luit from you (feb 15th 2021) on 
my local archive of debian-x messages since 2011..



--
t

Bug#1003161: 10check-duplicate-ip arping differences

[Matus UHLAR - fantomas]

Package: ifupdown-extra
Version: 0.32

Hello,

the 10check-duplicate-ip produces errors when used with iputils-arping:

Jan  5 12:56:12 uhlar-nb nm-dispatcher[46938]: 
/etc/network/if-up.d/10check-duplicate-ip: 86: cannot create /dev/stdout: No 
such device or address
Jan  5 12:56:12 uhlar-nb root[46948]: ERROR: Duplicate address 192.168.0.13 
assigned in the network where wlan0 is connected to.
Jan  5 12:56:12 uhlar-nb nm-dispatcher[46948]: <27>Jan  5 12:56:12 root[46948]: 
ERROR: Duplicate addres 192.168.0.13 assigned in the network where wlan0 is connected 
to.

1.

redirection to /dev/stdout fails, apparently there's no stdout when the
script is run, filedescriptor 1 (stdout) is closed and the redirection fails
because (/dev/stdout points to /proc/self/fd/1 which does not exist.

This issue is (partly) caused by fix for bug #632210, unfortunately this fix
causes an error.

2.

the duplicate address detection reports duplicity.
This seems to be caused by different behaviour of arping and iputils-arping:

- arping returns 0 when ping is successfull, 1 when it's not:

  -D
  Duplicate address detection mode (DAD). See RFC2131, 4.4.1. Returns
  0, if DAD succeeded i.e. no replies are received.


# /usr/sbin/arping -c 2 -w 3 -D -I wlan0 192.168.0.11
!!0% packet loss (0 extra)
# echo $?
0
# /usr/sbin/arping -c 2 -w 3 -D -I wlan0 192.168.0.12
..  100% packet loss (0 extra)
Exit 1

- iputils-arping returns 1 when ping is successful, 0 when it's not:

  -d Find duplicate replies. Exit with 1 if there  are  answers  from
 two different MAC addresses.


# /usr/bin/arping -c 2 -w 3 -D -I wlan0 192.168.0.11
ARPING 192.168.0.11 from 0.0.0.0 wlan0
Unicast reply from 192.168.0.11 [30:3A:64:aa:bb:cc]  85.519ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
Exit 1
# /usr/bin/arping -c 2 -w 3 -D -I wlan0 192.168.0.12
ARPING 192.168.0.12 from 0.0.0.0 wlan0
Sent 2 probes (2 broadcast(s))
Received 0 response(s)
# echo $?
0

so, the compared value has to be different for these two commands.


The good info is that arping now supports the "-q" option, so the
redirection is not needed:

# /usr/bin/arping -c 2 -w 3 -D -I wlan0 192.168.0.11 -q
Exit 1
# /usr/bin/arping -c 2 -w 3 -D -I wlan0 192.168.0.12 -q
# echo $?
0


I am attaching patch that:
- removes redirection
- adds -q option for either arping version
- defined return value to compare exit code

This error was also mentioned in bug 993826.

I have tested with both arping and iputils-arping, no duplicities detected
and no errors noticed.


Notes:
- "Exit 1" is produced by my shell when command returns non-zero status
- 192.168.0.11 is alive on my network, 192.168.0.12 is not

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I don't have lysdexia. The Dog wouldn't allow that.
--- 10check-duplicate-ip.orig	2021-06-03 08:13:30.0 +0200
+++ 10check-duplicate-ip	2022-01-05 13:39:15.087699050 +0100
@@ -83,8 +83,8 @@
 # Skip interface is address is IPv6, arping only works for IPv4
 if ! echo ${ADDR} | grep -q ":" ; then
 		[ "$VERBOSITY" -eq 1 ] && $OUTPUT "DEBUG: Sending arp pings through $real_iface (for $IFACE) to detect other systems using $ADDR"
-$ARPING -c $ARP_COUNT -w $ARP_TIMEOUT -D -I $real_iface $ADDR $ARPING_EXTRAOPTS >$ARPING_REDIR
-		if [ $? -ne 0 ] ; then
+$ARPING -c $ARP_COUNT -w $ARP_TIMEOUT -D -I $real_iface $ADDR -q
+		if [ $? -eq $ARPING_DUPLICITY ] ; then
 $OUTPUT "ERROR: Duplicate address $ADDR assigned in the network where $real_iface is connected to."
 		fi
 fi
@@ -118,15 +118,13 @@
 # We are going to use iputils-arping
 ARPING=/usr/bin/arping
 ARP_TIMEOUT=${ARP_TIMEOUT:-3} # Time here is measured in seconds
-ARPING_EXTRAOPTS="-q" # Use -q(uiet) in iputil's arping
-ARPING_REDIR="/dev/stdout"# Do not redirect output
+ARPING_DUPLICITY=1# iputils-arping returns 1 when duplicity is detected
 else
 if [ -x /usr/sbin/arping ] ; then
 ARPING=/usr/sbin/arping
 ARP_TIMEOUT=${ARP_TIMEOUT:-1500} # Time here is measures in milliseconds
  # experiments show anything less than 1500 is unreliable.
-ARPING_EXTRAOPTS=""  # No '-q' option in arping
-ARPING_REDIR="/dev/null"# Send output to /dev/null if using this program
+ARPING_DUPLICITY=0   # arping returns 0 when duplicity is detected
 else
 # Do not continue if ARPING is not available
 echo "WARNING: Cannot check for duplicate IP address in the network. The script cannot find the 'arping' program (tried /usr/bin/arping and /usr/sbin/arping. Please either install the iputils-arping or arping packages or disable this test by setting 

Bug#995350: Fix: enable mount flags (rw,rbind) in addition to (rw,bind)

[Pelzi]

The following patch seems to fix the problem.

--- /tmp/lxc-default-with-nesting.org 2022-01-05 13:25:18.920809830 +0100
+++ lxc-default-with-nesting 2022-01-05 13:22:35.019939076 +0100
@@ -10,6 +10,7 @@
mount fstype=proc -> /var/cache/lxc/**,
mount fstype=sysfs -> /var/cache/lxc/**,
mount options=(rw,bind),
+ mount options=(rw,rbind),
mount fstype=cgroup -> /sys/fs/cgroup/**,
mount fstype=cgroup2 -> /sys/fs/cgroup/**,
}

Bug#1003160: DisplayPort External Monitor no longer recognised after update to kernel 5.15

[Batwam]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.17-1
Severity: normal

Dear Maintainer,

   * Since Debian upgrade from Bullseye/Stable with kernel 5.10 to
Bookworm/Testing with 5.15 kernel, the external monitor connected with
DisplayPort on macbook 5.1 (late 2009) is no longer recognised and only
laptop screen is usable.
   * I checked xrandr and the screen is not listed (not even listed as
"Disconnected"). Note that I am using x11 (not Wayland). Note that I am
unable to test with the nvidia drivers as the legacy-340 drivers are no
longer available.
   * Restarted with 5.10 kernel and the screen is recognised again
   * Note that I am not sure if this is a nouveau issue or other
package (e.g. kernel) as it doesn't look like the port is recognised at
all.

See additional info attached as generated by reportbug

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Anthony 
To: Debian Bug Tracking System 
Subject: xserver-xorg-video-nouveau: none

Package: xserver-xorg-video-nouveau
Version: 1:1.0.17-1
Severity: normal
X-Debbugs-Cc: none

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation C79 [GeForce 
9400M] [10de:0863] (rev b1)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 232 Dec 22 10:33 00-keyboard.conf

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 5.15.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-13) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37) #1 SMP Debian 
5.15.5-2 (2021-12-18)

Xorg X server log files on system:
--
-rw-r--r-- 1 anthony anthony 56319 Jan  3 22:46 
/home/anthony/.local/share/xorg/Xorg.1.log
-rw-r--r-- 1 anthony anthony 62341 Jan  3 22:58 
/home/anthony/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 rootroot36426 Jan  5 09:34 /var/log/Xorg.0.log
-rw-r--r-- 1 rootroot42851 Jan  5 20:28 /var/log/Xorg.1.log

Contents of most recent Xorg X server log file (/var/log/Xorg.1.log):
-
[67.817] _XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() 
failed
[67.818] _XSERVTransMakeAllCOTSServerListeners: server already running
[67.821] (--) Log file renamed from "/var/log/Xorg.pid-4892.log" to 
"/var/log/Xorg.1.log"
[67.823] 
X.Org X Server 1.20.13
X Protocol Version 11, Revision 0
[67.825] Build Operating System: linux Debian
[67.825] Current Operating System: Linux debian 5.15.0-2-amd64 #1 SMP 
Debian 5.15.5-2 (2021-12-18) x86_64
[67.825] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-2-amd64 
root=UUID=b7c68bf3-b080-435b-a059-d9c9ad561146 ro quiet splash
[67.825] Build Date: 14 December 2021  01:38:21PM
[67.826] xorg-server 2:1.20.13-3 (https://www.debian.org/support) 
[67.826] Current version of pixman: 0.40.0
[67.826]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[67.826] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[67.828] (==) Log file: "/var/log/Xorg.1.log", Time: Wed Jan  5 09:34:21 
2022
[67.829] (==) Using config directory: "/etc/X11/xorg.conf.d"
[67.829] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[67.833] (==) No Layout section.  Using the first Screen section.
[67.834] (==) No screen section available. Using defaults.
[67.834] (**) |-->Screen "Default Screen Section" (0)
[67.834] (**) |   |-->Monitor ""
[67.841] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[67.841] (==) Automatically adding devices
[67.841] (==) Automatically enabling devices
[67.841] (==) Automatically adding GPU devices
[67.841] (==) Max clients allowed: 256, resource mask: 0x1f
[67.844] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[67.844]Entry deleted from font path.
[67.845] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,

Bug#1003134: grilo-plugins: FTBFS: ccache: error: Failed to create directory /sbuild-nonexistent/.cache/ccache/tmp: Permission denied

[Andrius Merkys]

Hi,

On 2022-01-05 14:01, Alberto Garcia wrote:
> On Tue, Jan 04, 2022 at 07:40:51PM +0200, Andrius Merkys wrote:
>> I attempted to rebuild grilo-plugins via sbuild on sid chroot and the
>> build failed with the following:
>   [...]
>> Comparing my build log with the one from buildd [1] I notice a bit newer
>> meson build system and 'ccache cc' being used:
> ccache is not a build dependency, doesn't it build without it
> installed?

Right, it should, but sbuild pulls in ccache. Not sure if it became a
transitive dependency or is this sbuild-specific.

> ccache creates a .cache directory in $HOME to store its data, so the
> options are:
> 
> 1. create that directory somewhere else (where?)

/tmp seems to be a good choice, 'mktemp -d' could be used to do so. I
recall employing this option in some package.

> 2. Add Build-Conflicts: ccache

This is my least-favorite option.

> 3. Make sure that Meson never uses ccache automatically.

Also a good option, if Meson has means to control this.

Andrius

Bug#1003153: [pkg-apparmor] Bug#1003153: /etc/apparmor.d/usr.sbin.apache2: Apache profile complains when ss -tnlp is run

[Christian Boltz]

Hello,

Am Mittwoch, 5. Januar 2022, 03:31:40 CET schrieb Craig Small:
> audit: type=1400 audit(1641349042.460:2559): apparmor="DENIED"
> operation="ptrace" profile="apache2//HANDLING_UNTRUSTED_INPUT"
> pid=2792993 comm="ss" requested_mask="readby" denied_mask="readby"
> peer="/bin/ss"
> 
> So ss is doing a ptrace on all the network listeners. The odd thing is
> that apache is the only one to complain about this even though other
> daemons listed have their own apparmor profiles.

That's not really odd ;-)

abstractions/base has
ptrace (readby),
ptrace (tracedby),

so all profiles that include abstractions/base can be ptraced.

However, what you see happens in the HANDLING_UNTRUSTED_INPUT hat (this 
hat is used when Apache processes are idle) - and Apache hats typically 
don't include abstractions/base.

(Nevertheless, the apache hats should allow to be ptraced. I'll leave 
that to the maintainer of the Apache profile in Debian - and would love 
to see the fix upstreamed.)


Regards,

Christian Boltz
-- 
 okay.  when can we have the next power outage,
for testing purposes ?
[from #opensuse-admin]


signature.asc
Description: This is a digitally signed message part.

Bug#1002496: perl6-readline: Strange files under /usr/lib/perl6/vendor/dist?

[Chris Lamb]

Hey Dominique,

> I don't really know why the pre-compilation is not reproducible.

First, thank you for the links and explanation: I thought they were
I accidentally-included files at first. Anyway, I've just spent a few
minutes looking into this issue and it seems like the pre-compiled
modules reference the absolute build path:

  $ strings EBC1B2DDA59A9D91D483BD81DAA416714D2D1276 | grep lamby
  
/home/lamby/temp/cdt.20220105114153.LbQvXzNPwU.repro.perl6-readline/build-a/perl6-readline-0.1.5

(There might be other 'nondeterminisms' as well, however.)

> As a matter of fact, neither rakudo, nqp or moarvm are reproducible. I've
> never found the time or energy to find why.

I assume you're referring to the build of the rakudo source package
itself. If so, that feels like an important yet distinct issue: let's
keep this particular bug to the reproducibility of the *output* of
rakudo… even if it turns out to be the same underlying problem.

Anyway, just thought I'd brain-dump the above for now.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#998553: RC bug in libdbi-drivers

[Thorsten Alteholz]

Hi Laszlo,

are you already working on an upload of libdbi-drivers? Or do you need 
some help?


Best regards
Thorsten

Bug#1003102: ITP: webrtc -- WebRTC provides real time voice and video processing functionality to enable the implementation of PeerConnection/MediaStream.

[Jonas Smedegaard]

Quoting 汤孟 (2022-01-05 08:01:48)
> In these projects, I found the release version in the owt-deps-webrtc 
> project, can I release libwebrtc based on owt-deps-webrtc?

Sounds like a good idea to me that you package the OWT fork of the 
WebRTC library collection.

I recommend to then choose a package name which indicates the fork 
packaged, to make room for eventual later packaging of other forks as 
well (e.g. it might make sense for the Mozilla fork to be packaged as 
regular packages reusable by others instead of only embedded with 
firefox and firefox-esr as it is today).

Concretely I propose the package name "libwebrtc-owt".


> In addition, because webrtc needs to use gclient sync to synchronize 
> some Google warehouse codes, considering the stability of the build, 
> can I synchronize other Google warehouse codes that webrtc rely on 
> based on the DEPS files in the owt-deps-webrtc project?

Sorry, I don't know about those details, so cannot sensibly advice you 
on them.  Maybe as such questions to debian-de...@lists.debian.org (and 
try expand the question to make sense also for people not already 
familiar with the details - or at least add links to places with more 
details).

It sounds like those are tracking mechanisms (or can be aboused as 
such), and I would recommend that you try make them optional in your 
packaging - e.g. if possible to build with or without such features then 
consider making 2 binary packages, so that users can choose to install 
packages _without_ such mechanisms baked in - even if maybe for your own 
needs those features are needed.

If you are interested in such privacy concerns, you might also want to 
look at https://wiki.debian.org/PrivacyIssues - and update that page 
with any additional information you may be aware of.


> Arun Raghavan who maintains webrtc-audio-processing has already 
> responded to this effort. So I think libwebrtc can be maintained 
> separately from webrtc-audio-processing.

Sounds good that you are in touch :-)

Good luck with the packaging and maintenance work,

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#999155: RC bug in mm and zlib

[Thorsten Alteholz]

Hi Mark,

are you already working on an update of mm and zlib? Or do you need some 
help?


Best regards
Thorsten

Bug#1003134: grilo-plugins: FTBFS: ccache: error: Failed to create directory /sbuild-nonexistent/.cache/ccache/tmp: Permission denied

[Alberto Garcia]

On Tue, Jan 04, 2022 at 07:40:51PM +0200, Andrius Merkys wrote:
> I attempted to rebuild grilo-plugins via sbuild on sid chroot and the
> build failed with the following:
  [...]
> Comparing my build log with the one from buildd [1] I notice a bit newer
> meson build system and 'ccache cc' being used:

ccache is not a build dependency, doesn't it build without it
installed?

ccache creates a .cache directory in $HOME to store its data, so the
options are:

1. create that directory somewhere else (where?)
2. Add Build-Conflicts: ccache
3. Make sure that Meson never uses ccache automatically.

Berto

Bug#1003157: mailman-suite | Mailman REST API not available. Please start Mailman core. (#22)

[Geert Stappers]

On Tue, Jan 04, 2022 at 11:13:54PM +, Mark Sapiro (@msapiro) wrote:
> Mark Sapiro commented:
> https://gitlab.com/mailman/mailman-suite/-/issues/22#note_801370201
> 
> I don't know what's responsible for the TLS request. What is your
> setting for `MAILMAN_REST_API_URL`? if it is `https`, you might try
> `http` instead

```
$ sudo grep REST_API_URL  /etc/mailman3/mailman-web.py
MAILMAN_REST_API_URL = 'http://localhost:8001'
```

And that `http` was there way before the network sniff was done.
( https://gitlab.com/mailman/mailman-suite/-/issues/22#note_801291946 )
 
> That said, issues with downstream packages should be reported to the
> downstream packager, Debian in this case, rather than here.

Done: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003157
And the Debian packagers are also recieving this email.


> Then if the problem is upstream, the packager can come here.

Current question:
What causes the "Mailman REST API not available."?
Is it mailman3-web not seeing the response to `GET 3.1/domains`?
Or is it the '400 Bad request' in response to TLS request?

Responses I hope to recieve are like
  * Enable extra logging of mailman-suite by ...
  * At  path/to/django/settings/file  somewhere line number ...
you find  foobar, comment that out to get  and try again.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1003159: dh-raku: please make the contents of "$pkg.dh-raku.list" files reproducible

[Chris Lamb]

Source: dh-raku
Version: 0.5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness toolchain
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
dh-raku generated $pkg.dh-raku.list files that were unreproducible.

This is related (but very much not the issue as) the reproducibility
of the precompiled Perl6 modules themselves. For that, see #1002496.

However, we can easily fix the dh-raku.list files. For that, please
see and apply the attached patch.

  [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/dh_raku_install b/dh_raku_install
index 6971e4a..252d553 100644
--- a/dh_raku_install
+++ b/dh_raku_install
@@ -94,7 +94,7 @@ foreach my $pkg (getpackages()) {
 push @to_do, sub {
 my $file_name = "$pkg.dh-raku.list";
 my $list = $precomp->child($file_name);
-$list->spew(map {"$_\n"} @installed);
+$list->spew(map {"$_\n"} sort @installed);
 nonquiet_print("Installing $file_name in $vendor");
 install_file ($list->stringify, $vendor->child($file_name)->stringify);
 };

Bug#679905: 2021.8+ds2-1 - Pending

[Neil Williams]

On Fri, 17 Dec 2021 12:57:48 +0200 Andrius Merkys 
wrote:
> Hi Neil,
> 
> On 2021-12-16 11:19, Neil Williams wrote:
> > README.source:
> > 
> > cctbx for Debian
> > 
> > 
> > CCTBX upstream does not manage SONAME versions, so a version is
> > added in the Debian patches. This means that new upstream releases
> > of cctbx should update the patch to cause a SONAME bump for all >100
> > cctbx libraries and a transition in the archive.
> 
> I see you have switched from having all libraries in cctbx/
> subdirectory [1] to public libs and libdevel locations. Personally I
> do think Debian as a downstream should be setting SONAMEs. This does
> not seem to be forbidden by the policy, but in case the upstream
> introduces SONAMEs, clashes may occur. Moreover, caring for ABI
> compatibility is a lot of work.

When trying to package libobjcryst, it became obvious that a SONAME had
to be applied to cctbx, just as libobjcryst itself needs to patch in a
SONAME. It is an extra amount of work but C++ symbols based on a
package using lots of templates are fuzzy at best and with so many
different modules in cctbx, the only practical way to handle it seems
to be a new SONAME each time. The header files are also problematic. We
might be able to restrict SONAME changes to upstream versions which
make changes to the header files included in libcctbx-dev rather than
every new upstream release. Until we've got cctbx through NEW, it is
going to be hard to tell.


> On a separate thread, I managed to package reduce [2] locally.
> However, as you have also noted it, the name of source, binary and
> executable is problematic. Maybe it is worth trying to talk to
> upstream about renaming it to avoid clashes.

Maybe package it as pdb-reduce or pdb-hydrogen-reduce ?

/usr/bin/reduce does not exist in Debian yet but it may be worth
packaging the script as pdb-reduce with a note in README.Debian -
anyone switching from using the upstream build to Debian packages will
need to make other changes anyway.

> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679905#98
> [2] https://github.com/rlabduke/reduce
> 
> Best,
> Andrius
> 
> 



-- 
Neil Williams
=
https://linux.codehelp.co.uk/


pgpLJ5je4aaT6.pgp
Description: OpenPGP digital signature

Bug#1003059: ITP: su-exec -- switch user and group id, setgroups and exec

[Matteo Chesi]

Thanks Ansgar,

I did not know setpriv, I will test if it can replace su-exec on my 
containers.


Probably the main reason could be binary size on certain small 
systems/containers:


$ du -sh /usr/sbin/gosu
2.3M/usr/sbin/gosu
$ du -sh /usr/bin/setpriv
52K /usr/bin/setpriv
$ du -sh /usr/bin/su-exec
16K /usr/bin/su-exec

Best Regards,
Matteo

Il 2022-01-05 12:09 Ansgar ha scritto:

On Mon, 03 Jan 2022 15:21:48 +0100 Matteo Chesi wrote:

* Package name : su-exec
    Description : switch user and group id, setgroups and exec

This is an alternative to gosu written in C.


In Debian the essential util-linux package already provides "setpriv".
Is there any reason to use su-exec instead of it?

Ansgar

Bug#1003158: apparmor: tunables/home seems to have wrong order of variables

[Karsten Hilbert]

Package: apparmor
Version: 2.13.6-10
Severity: important

Dear Maintainers,

there seems to be a order-logic bug in

/etc/apparmor.d/tunables/home

That profile defines @{HOME} first:

@{HOME}=@{HOMEDIRS}/*/ /root/

and *later* defines @{HOMEDIRS}:

@{HOMEDIRS}=/home/

It seems that either the order of definitions needs to be switched or
else the second definition should be

@{HOMEDIRS}+=/home/ #(note the + sign)

?  Or am I missing something.

Thanks,
Karsten


-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 5.15.0-2-686-pae (SMP w/2 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apparmor depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc6  2.33-1
ii  lsb-base   11.1.0

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
pn  apparmor-utils   

-- debconf information:
  apparmor/homedirs:

Bug#1003059: ITP: su-exec -- switch user and group id, setgroups and exec

[Ansgar]

On Mon, 03 Jan 2022 15:21:48 +0100 Matteo Chesi wrote:
> * Package name : su-exec
>    Description : switch user and group id, setgroups and exec
> 
> This is an alternative to gosu written in C.

In Debian the essential util-linux package already provides "setpriv".
Is there any reason to use su-exec instead of it?

Ansgar

Bug#557427: Good morning, happy new year

[israel barney]

Permit I talk with you please, is about Mrs. Anna.

Bug#984131: flmsg: ftbfs with GCC-11

[Christoph Berg]

> flmsg.cxx: In function ‘void rotate_log(std::string)’:
> flmsg.cxx:2848:24: error: ‘streampos’ is not a member of ‘std::ostringstream’ 
> {aka ‘std::__cxx11::basic_ostringstream’}
>  2848 | ostringstream::streampos p;
>   |^

For the record, the new upstream version 4.0.19 which I just pushed to
git probably works better with gcc-11, but has problems with xmlrpc:

g++ -DHAVE_CONFIG_H -I.  -I. -I./include -I/usr/include/flxmlrpc -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/cairo -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16  -I. 
-I./include   -pipe -Wall -fexceptions -O2 -ffast-math -finline-functions 
-fomit-frame-pointer   -DNDEBUG -I/usr/include/flxmlrpc -g -O2 
-ffile-prefix-map=/srv/projects/afu/flmsg/flmsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -c -o blank-dnd/flmsg-dnd_tab.o `test -f 
'blank-dnd/dnd_tab.cxx' || echo './'`blank-dnd/dnd_tab.cxx
flmsg.cxx: In function ‘int main(int, char**)’:
flmsg.cxx:1927:17: error: ‘set_pname’ is not a member of ‘XmlRpc’
 1927 | XmlRpc::set_pname(pname);
  | ^

(I have no plans to fix this since I don't use flmsg.)

Christoph

Bug#1003045: New information : problem seems to be xorg/wayland conflict.

[Vincent Lefevre]

On 2022-01-03 15:24:47 +0100, copropriete27ruemo...@gmail.com wrote:
> After this update, somme applications such as LibreOffice, but also
> Firefox, do not "work" in an xorg session but do in a Wayland session.

I don't have such issues in xorg (no GNOME on my machine), and
up-to-date sid packages.

> More precisely, these applications run (I can see them in `ps augwx`,
> their icons are marked with a white dot in the Activities panel), but
> do not display anything.

FYI, windows appear partly off-screen here (but this is not new).
Just in case, you should check that windows do not appear completely
off-screen (this has already happened to me in the past): this could
explain why you can see that these applications run, but nothing is
displayed.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003157: Mailman REST API not available. Please start Mailman core.

[Geert Stappers]

Package: mailman3-web
Version: 0+20180916-8
Severity: important
Justification: renders package unusable


Hello,


My installation of mailman3-web yields:

Mailman REST API not available. Please start Mailman core.


Further information will be provided in follow-up email.
(This submit message is for getting a bugreportnumber.)


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1002590: ITP: wayvnc -- VNC server for wlroots-based Wayland compositors

[Johannes Schauer Marin Rodrigues]

Hi Felix,

thanks for notifying me about this!

Quoting Moessbauer, Felix (2022-01-05 10:14:09)
> there is already a PR on the wayvnc project with a working debianzation [1].

I already packaged it at https://salsa.debian.org/debian/wayvnc and uploaded it
to NEW.

> The author of [1] also added debianizations for aml [2] and neatvnc [3] which 
> are dependencies.
> Don't know if we need dedicated ITPs for them as well.

Nope, aml is already in Debian and neatvnc is waiting in NEW. I left some
messages with the current status under the links you provided.

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1003038: mkfs.hfs does not respect the -v option when creating an HFS volume

[John Paul Adrian Glaubitz]

Hi Glenn!

On 1/3/22 03:21, Glenn Washburn wrote:
> Creating an HFS volume with a volume name other than the default of
> "untitled" is currently not possible. It does appear that it should be
> possible. Here is output exhibiting this issue:
> (...)
> Looking at the package source, I see that HFS volume creation is added
> as a debian package patch and not part of the upstream source in patch
> file 
> debian/patches/0005-Re-add-support-for-creating-legacy-HFS-filesystems.patch.

Yes, this patch was created by me since we need legacy HFS support for the Apple
PowerMacs that we support in Debian Ports for the powerpc and ppc64 ports.

> The issue appears to be that the volume name passed in as the -v option
> argument and being written to the hfs parameters struct is being
> unconditionally overritten in line 325 of the patch file with the
> default volume name. This can be fixed by swapping the first two
> aruments to bcopy on that line, however, the comment and the lines
> directly above it lead me to believe there's potentially more to it.
> 
> This is causing GRUB HFS tests to fail and it would be nice to get them
> passing again without disabling the failing test.

Thanks for debugging and reporting this. I will have a look at this bug and
fix it hopefully soon. Also, thanks for fixing so many issues in GRUB, I'm
on the GRUB mailing list as well and I'm seeing your regular influx of
patches there!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1003156: dnsmasq: SIGSEV when running as PROXYDHCP and target is not listed inn config file

[Georg Gast]

I may have wrote misleading:

It need these options to tag the architecture
dhcp-vendorclass=ARM32,PXEClient:Arch:00010
dhcp-vendorclass=ARM64,PXEClient:Arch:00011
and these options to send them the PROXYDHCP
dhcp-boot=tag:ARM32,default,192.168.160.19
dhcp-boot=tag:ARM64,default,192.168.160.19

Bug#1003156: dnsmasq: SIGSEV when running as PROXYDHCP and target is not listed inn config file

[Georg Gast]

Package: dnsmasq
Version: 2.85-1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
I try to boot various SBC computer to boot from NFS. I have a FRITZBox as dhcp
server and i compiled u boot to accept the serverip from the PROXYDHCP. dnsmasq
needs the
dhcp-boot=tag:ARM32,default,192.168.160.19
dhcp-boot=tag:ARM64,default,192.168.160.19
to tag the connections. When these option for the specified architecture is not
present, dnsmasq gets a SIGSEV when such a architecture boots.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to get a meaningful backtrace and followed
https://wiki.debian.org/HowToGetABacktrace but i just got

0x7f819e8b73c3 in __GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
Download failed: Das Argument ist ungültig.  Continuing without source file
./io/../sysdeps/unix/sysv/linux/poll.c.
29  ../sysdeps/unix/sysv/linux/poll.c: Datei oder Verzeichnis nicht
gefunden.
(gdb)
(gdb) bt
#0  0x7f819e8b73c3 in __GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x5642e7002473 in ?? ()
#2  0x7f819e7ead0a in __libc_start_main (main=0x5642e7000d60, argc=11,
argv=0x7ffc0cef7608, init=, fini=,
rtld_fini=, stack_end=0x7ffc0cef75f8)
at ../csu/libc-start.c:308
#3  0x5642e700337a in ?? ()
(gdb) info threadsa
Undefined info command: "threadsa".  Try "help info".
(gdb) info threads
  Id   Target IdFrame
* 1Thread 0x7f819e0dfcc0 (LWP 241194) "dnsmasq" 0x7f819e8b73c3 in
__GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1) at
../sysdeps/unix/sysv/linux/poll.c:29
(gdb) bt
#0  0x7f819e8b73c3 in __GI___poll (fds=0x5642e7458400, nfds=7, timeout=-1)
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x5642e7002473 in ?? ()
#2  0x7f819e7ead0a in __libc_start_main (main=0x5642e7000d60, argc=11,
argv=0x7ffc0cef7608, init=, fini=,
rtld_fini=, stack_end=0x7ffc0cef75f8)
at ../csu/libc-start.c:308
#3  0x5642e700337a in ?? ()


*** End of the template - remove these template lines ***

This could be a problem for users thar relay on dnsmasq to work properly even
if there comes a packet from an architekture they dont handle. dnsmasq would
stop working.

-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-
debug'), (500, 'proposed-updates-debug'), (500, 'proposed-updates'), (500,
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.85-1
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  runit-helper 2.10.3

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
ii  openresolv [resolvconf]  3.12.0-1

-- Configuration Files:
/etc/dnsmasq.conf changed:
port=0
log-dhcp
log-debug
log-queries
enable-tftp
tftp-root=/srv/netboot/
dhcp-vendorclass=BIOS,PXEClient:Arch:0
dhcp-vendorclass=UEFI32,PXEClient:Arch:6
dhcp-vendorclass=UEFI,PXEClient:Arch:7
dhcp-vendorclass=UEFI64,PXEClient:Arch:9
dhcp-vendorclass=ARM32,PXEClient:Arch:00010
dhcp-vendorclass=ARM64,PXEClient:Arch:00011
dhcp-boot=UEFI32,i386-efi/ipxe.efi,,192.168.160.19
dhcp-boot=UEFI,ipxe.efi,,192.168.160.19
dhcp-boot=UEFI64,ipxe.efi,,192.168.160.19
dhcp-boot=tag:ARM32,default,192.168.160.19
dhcp-boot=tag:ARM64,default,192.168.160.19
pxe-service=1, "Boot CSA 1", efi64/syslinux.efi
dhcp-range=192.168.160.1,proxy

Bug#921815: debootstrap: issue remains in version 1.0.123

[Matthias Roelandts]

Package: debootstrap
Version: 1.0.114
Followup-For: Bug #921815

Dear Maintainer,

Reproducable:
$ docker run --rm -it --privileged debian:bullseye bash
$ apt update && apt install debootstrap
$ apt policy debootstrap # shows version 1.0.123 is installed
$ debootstrap bullseye chroot

Output:
I: Target architecture can be executed
I: Retrieving InRelease
...
I: Extracting zlib1g...
W: Failure trying to run: chroot "//chroot" mount -t proc proc /proc
W: See //chroot/debootstrap/debootstrap.log for details
I: Installing core packages...
...
I: Base system installed successfully.

Checking output:
$ echo $? # return 0
$ ls /proc # its empty!

I have noticed when you use a debian stretch container, everything is ok.
This means the issue was not there in debootstrap 1.0.89


-- System Information:
Debian Release: 10.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages debootstrap depends on:
ii  wget  1.20.1-1.1

Versions of packages debootstrap recommends:
ii  arch-test   0.15-2+deb10u1
ii  debian-archive-keyring  2019.1+deb10u1
ii  gnupg   2.2.12-1+deb10u1

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Vincent Lefevre]

Control: found -1 1.13.1-1

Hi,

On 2022-01-05 09:56:26 +0100, Andrej Shadura wrote:
> In fact, unbound comes with resolvconf integration, so it should
> know about other nameservers coming from DHCP. It is likely that the
> fact you add 127.0.0.1 in front of them is preventing that
> integration from working properly. Or maybe it’s a bug.

The unbound(8) man page says

   To use a locally running Unbound for resolving put

 nameserver 127.0.0.1

   into resolv.conf(5).

Since resolv.conf is under the control of dhclient, I did that
via the dhclient configuration file.

I now see the /etc/resolvconf/update.d/unbound file (this was not
documented). It runs /lib/resolvconf/list-records, so I'll see
what I get. I'm no longer in the train, so I won't be able to
test hostname resolution, but I could see whether the knowledge
of other DHCP-provided nameservers gets in $FWD in this script.

If I understand how this should work with resolvconf + unbound:

* /etc/resolv.conf should contain only 127.0.0.1 (corresponding
  to unbound).

* /lib/resolvconf/list-records should output lines with 127.0.0.1
  and the DHCP-provided nameservers.

* /etc/resolvconf/update.d/unbound makes unbound aware of these
  DHCP-provided nameservers.

I'll see whether I get this (I don't have my laptop with me here).
If I do, then yes, this could be a bug in unbound. I'm not sure,
though, because the unbound-control(8) man page is not very detailed.
It says in particular:

  If off is passed, forwarding is disabled and the root nameservers
  are used. This can be used to avoid to avoid buggy or non-DNSSEC
  supporting nameservers returned from DHCP. But may not work in
  hotels or hotspots.

I'm precisely in the case of buggy nameservers returned from DHCP!
So it appears that what the /etc/resolvconf/update.d/unbound script
does may be wrong! What I want is to use the root nameservers by
default, and the nameservers returned from DHCP as a fallback
(e.g. for "hotels or hotspots", like in the train), as described
in the resolv.conf(5) man page: "If there are multiple servers,
the resolver library queries them in the order listed." But it is
also possible that the unbound-control(8) man page is inaccurate
and misleading.

BTW, in the train, it is also possible that this wasn't working
due to bad coincidence, since the network wasn't very good and
there could be failures due to that. But I had tried several
times, and this began to work only after I replaced resolv.conf
to have the DHCP-provided nameserver there (after 127.0.0.1).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1003003: libqalculate FTBFS on architectures where char is unsigned

[Rik Mills]

Reported here: https://github.com/Qalculate/libqalculate/issues/378

I note that these tests are entirely new in 3.22.0, so there is no
history of them previously passing.

Bug#1002590: ITP: wayvnc -- VNC server for wlroots-based Wayland compositors

[Moessbauer, Felix]

On Fri, 24 Dec 2021 22:00:47 +0100 Johannes Schauer Marin Rodrigues 
 wrote: 
> Package: wnpp 
> Severity: wishlist 
> Owner: Johannes Schauer Marin Rodrigues  
> X-Debbugs-Cc: debian-de...@lists.debian.org, jo...@debian.org 
> 
> * Package name    : wayvnc 
>   Version : 0.4.1 
>   Upstream Author : Andri Yngvason 
> * URL : https://github.com/any1/wayvnc 
> * License : ISC 
>   Programming Lang: C 
>   Description : VNC server for wlroots-based Wayland compositors 
> 
> This is a VNC server for wlroots-based Wayland compositors. It attaches 
> to a running Wayland session, creates virtual input devices, and exposes 
> a single display via the RFB protocol. The Wayland session may be a 
> headless one, so it is also possible to run wayvnc without a physical 
> display attached. 
> 
> 
Hi,

there is already a PR on the wayvnc project with a working debianzation [1].
The author of [1] also added debianizations for aml [2] and neatvnc [3] which 
are dependencies.
Don't know if we need dedicated ITPs for them as well.

Felix!

[1] https://github.com/any1/wayvnc/pull/116
[2] https://github.com/any1/aml/pull/7
[3] https://github.com/any1/neatvnc/pull/61

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Andrej Shadura]

Hi again,

On Wed, 5 Jan 2022, at 09:56, Andrej Shadura wrote:
> In fact, unbound comes with resolvconf integration, so it should know 
> about other nameservers coming from DHCP. It is likely that the fact 
> you add 127.0.0.1 in front of them is preventing that integration from 
> working properly. Or maybe it’s a bug.

I just wanted to clarify: unbound already puts itself (as 127.0.0.1) first in 
resolvconf configuration. You should not need to modify you DHCP client’s 
configuration to add it once more. Unbound’s resolvconf integration should 
theoretically filter 127.0.0.1 out and tell unbound to forward its requests to 
your network’s name servers, but for some reason it doesn’t. Or maybe you’ve 
modified unbound’s configuration to disallow that.

-- 
Cheers,
  Andrej

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Andrej Shadura]

On Wed, 5 Jan 2022, at 09:56, Andrej Shadura wrote:
> to work, I think it’s worth reassigning this package to unbound because 

I meant "reassigning this bug", of course 

-- 
Cheers,
  Andrej

Bug#1003135: resolvconf: prevents wifi.sncf from being resolved

[Andrej Shadura]

Control: reassign -1 src:unbound

Hi,

On Wed, 5 Jan 2022, at 00:26, Vincent Lefevre wrote:
>> > where 127.0.0.1 is added by dhclient thanks to
>> >
>> >   prepend domain-name-servers 127.0.0.1;
>> 
>> Why do you have this? This basically overrides the DHCP server by
>> directing queries to your localhost DNS.
>
> One reason is that because ISPs may block websites via DNS (for good
> or bad reasons). For instance: https://www.soundofscience.fr/1723
> (article in French). So I prefer to bypass the DNS servers of the ISP
> if this works, and use them only in case of failure (the issue with
> SNCF wifi, probably because it filters UDP[*], is an example).

<..>

> See above for the reason I use unbound. And I don't think that
> unbound can do anything, as it doesn't know the concept of
> servers provided by DHCP.

In fact, unbound comes with resolvconf integration, so it should know about 
other nameservers coming from DHCP. It is likely that the fact you add 
127.0.0.1 in front of them is preventing that integration from working 
properly. Or maybe it’s a bug.

In any case, even though I still think what you’re doing isn’t supposed to 
work, I think it’s worth reassigning this package to unbound because it’s 
possible that it can be fixed there.

-- 
Cheers,
  Andrej

Bug#1002857: Bug #995810: libgoogle-glog-dev: Dependency on libunwind-dev

[Michael Weghorn]

Hi,

On Thu, 30 Dec 2021 11:11:43 +0100 Marc Glisse 
 wrote:

Package: libgoogle-glog-dev
Version: 0.5.0+really0.4.0-2
Severity: normal

Dear Maintainer,

with the switch to llvm-13 in testing, installing libgoogle-glog-dev has
become problematic, it depends on libunwind-dev, but that conflicts with
libunwind-13-dev.
I couldn't find an official doc on what the LLVM
maintainers expect, but it looks like depending on libunwind-x.y-dev may
work. I didn't test it though, some libunwind files seem to have moved,
and I may have completely misunderstood the relation between the various
libunwind packages.


I have run into a similar problem with the libgstreamer1.0-dev package, 
which can no longer be installed in parallel with libc++-dev because


* libc++-dev depends on libc++-13-dev, which depends on 
libunwind-13-dev, which breaks libunwind-dev

* libgstreamer1.0-dev depends on libunwind-dev

As far as I can see, two relevant commits in the LLVM packaging git repo 
on the way to the current situation are:


* Commit c72a6c0e50e318c83e6bff901dd0e2e591f65145 [1], "Generate 
libunwind-12 & libunwind-12-dev packages", which added the 
libunwind--dev package with a "Breaks" on libunwind-dev
* Commit 103cb1357c55b508e283d329083119d2429029ca [2], "libc++-13-dev 
should depends on libunwind-13-dev (Closes: #995810)", which added the 
corresponding dependency


Can the LLVM packaging team possibly give a hint what is the intended 
way to deal with the situation?
(I would then open a bug report for libgstreamer1.0-dev with the 
relevant information as well if something has to be done there)?


Best regards,
Michael


[1] 
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/c72a6c0e50e318c83e6bff901dd0e2e591f65145
[2] 
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/103cb1357c55b508e283d329083119d2429029ca

Bug#1003155: opensbi: tar.xz is not supported by 'git archive'

[Heinrich Schuchardt]

Package: opensbi
Version: 1.0-1
Severity: normal

Dear Vagrant,

The opensbi package has a maintainer script debian/bin/git-snapshot with
commands

archive=tar.xz
git archive \
--format=${archive} \

tar.xz is not a valid archive format. 'git archive -l' gives this list:

* tar
* tgz
* tar.gz
* zip

Please, change the maintainer script to use --format=tar and issue a
separate command to compress with xz.

Best regards

Heinrich

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information