Bug#911560: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Dieter]

Hi Jonas,


On 08/08/2020 14:48, Jonas Smedegaard wrote:

>> However: I was not able to force the other partner (my old lenovo T500)
>> of the connection to a certain mode.
>> I thought ethtool would allow me to force the T500s, but i could not
>> find the option.
> 
> Whoa, setting master/slave mode was implemented only since Linux v5.7: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649
> 
> Corresponding userspace support was introduced in ethtool v5.8: 
> https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d
> 
> Ethtool v5.8 is not yet in Debian - was released upstream only 4 days 
> ago.
> Sorry, I thought master/slave was same as MDI/MDI-X, but those are 
> independent: The former is which end provides clock source, then latter 
> is which wires are used: 
> https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T
> 
> According to 
> https://www.speedguide.net/articles/network-adapter-optimization-3449 
> when auto-negotiated "multi-port devices such as switches become the 
> master when connected to a single port device. If both ends are 
> multi-port devices, the one with higher seed bits becomes the master."
> 
> That seems to indicate that you should reliably put the device in slave 
> mode by simply plugging it into a gigabit switch.  Still not sure how to 
> force master mode (other than at the other end run Linux 5.7 and compile 
> and use ethtool 5.8), as the above does not tell which end "wins" when 
> both are single-port devices.

Thanks for the information.
Since ethtool 5.8 is now available, i can install debian unstable on the
laptop and test different combinations.



>> u-boot with FORCE_MASTER and TX-Delay 4:
>> Same as above.
>>
>>
>> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK
> 
> Ohhh, good point - I totally missed that detail!
> 
> Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.
> 
> Would be helpful if you could test...
> 
>   * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
>   * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
>   * above, with various values for TX-Delay

Yes, i can test that!

>> Good performance with TX-Delay = [3,4].
>> The results with TX-Delay = 2 could not be reproduced.
>>
>>
>> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
>> With TX-delay = 0, no connection was possible at all.
> 
> I would expect TX-delay = 0 to behave same as TX-delay not set at all - 
> is that your experience as well?

To be honest, i did not disable the configuration, as i always started
from A20-OLinuXino..._defconfig, and there the Delay is set to 0 by default.

But i just checked, if the line with GMAC_TX_DELAY is commented out in
the config, make will ask for a value, 0 being the default.
-> Yes, TX-Delay 0 is equal to this config not being set at all.

>> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK does? 
>> Is this possibly only used in u-boot, and therefore irrelevant as soon 
>> as linux boots?
> 
> those switches enable code chunks in u-boot.  My (vague!) understanding 
> is that some but not all such code chunks does some initialization of 
> hardware chips, and that Linux may or may not do its own 
> (re)initialization of same bits.
> 
> In other words: Possibly - it depends... :-)

I see, in that case i would suppose that network functionality in u-boot
might depend on the compiled in drivers.
Likely independent of network functionality when the OS is brought up.
I arrived at this conclusion, as u-boot without the MICREL Phy has
working ethernet in Linux with the TX-Delay being set.

>> As you mentioned this commit
>> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3aed3e2)
>> earlier in this thread, i would guess we should re-tests this with a
>> linux-image > 5.2?
> 
> Ideally we should test network quality from within u-boot, and if we 
> identify some u-boot setup that fails from within u-boot but works from 
> some Linux, then try identify what initialization the Linux code does 
> and try figure out how that could be done in u-boot as well.
> 
> ...because ideally we want u-boot to work reliably not only for 
> initializing what Linux misses, but also for netbooting Linux.

I agree, i would propose to test the values for TX_DELAY from within
Linux, as there measuring upload / download performance is easier.
As soon as we find a good configuration there, we can test the
netbooting from u-boot.

-> Configuring a tftp-server on the laptop to serve the netboot images
to the OLinuXino should help here.

> Another test that would be helpful is if you test your board with u-boot 
> built with A20-OLinuXino-Lime2-eMMC_defconfig (even if you do not have 
> and/or use eMMC): My suspicion is that the added options enabled for 
> that defconfig is harmless for non-eMMC boards, and knowing if in fact 
> they are harmless is helpful to figure out how many binaries we really 
> need to build in De

Bug#968295: additional content - what may of caused the issue

[Guilhem Moulin]

Control: reassign -1 cryptsetup-initramfs
Control: tag -1 moreinfo

Hi,

On Wed, 12 Aug 2020 at 21:24:10 -0700, Andrei Popescu wrote:
> The following additional pakcages will be installed:
> cryptsetup-bin
> The following NEW packages will be installed cryptsetup-bin
> 0 upgraded, 1 newly installed, 0 to remove and 46 not upgraded.

Is the ‘cryptsetup-initramfs’ installed?  As of Buster that's the
package responsible for unlocking drives at initramfs stage; as of
Stretch and earlier it used to be part of ‘cryptsetup’, and should be
automatically pulled on upgrade.

Which version of ‘cryptsetup*’ do you have, before and after  the
upgrade?  You can find that in /var/log/apt/history.log.

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#968374: transition: proftpd-dfsg

[Sebastian Ramacher]

On 2020-08-13 22:04:23 +0200, Hilmar Preusse wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> This transition was already started by the recent proftpd upload, but is
> not caught caught automatically since it is a virtual package name that
> has changed.

I've scheduled binNMUs for the reverse dependencies. Once
proftpd-mod-vroot is old enough, proftpd-dfsg should be able to
migrate.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#968382: element-desktop: /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied

[Hans-Christoph Steiner]

Package: firejail-profiles
Version: 0.9.62-4~bpo10+1
Severity: important

element-desktop as installed via the Debian package does not start with 
firejail.

 ~ $ firejail /opt/Element/element-desktop --no-sandbox
Reading profile /etc/firejail/element-desktop.profile
Reading profile /etc/firejail/riot-desktop.profile
Reading profile /etc/firejail/riot-web.profile
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-common.local
Reading profile /etc/firejail/electron.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc
Warning: networking feature is disabled in Firejail configuration file
Parent pid 16628, child pid 16629
Private /opt installed in 545.76 ms
Warning: An abstract unix socket for session D-BUS might still be available. 
Use --net or remove unix from --protocol set.
Post-exec seccomp protector enabled
Seccomp list in: !chroot, check list: @default-keep, prelist: unknown,
Child process initialized in 591.56 ms
/home/hans/.config/Element exists: no
/home/hans/.config/Riot exists: yes
Using legacy user data path: /home/hans/.config/Riot
(node:8) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security 
and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or 
Buffer.from() methods instead.

(element-desktop:8): dconf-WARNING **: 09:51:34.251: Unable to open 
/var/lib/flatpak/exports/share/dconf/profile/user: Permission denied
Starting auto update with base URL: https://packages.riot.im/desktop/update/
Auto update not supported on this platform
[50:0814/095134.384213:FATAL:platform_shared_memory_region_posix.cc(254)] This 
is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo chmod 
1777 /dev/shm' to fix.
^C
Parent received signal 2, shutting down the child process...

Child received signal 2, shutting down the sandbox...

Parent is shutting down, bye...
 ~ $ ls -ld /var/lib/flatpak/exports/share/dconf/profile/user
ls: cannot access '/var/lib/flatpak/exports/share/dconf/profile/user': No such 
file or directory
 ~ $ ls -ld /var/lib/flatpak/exports/share/dconf/profile/
ls: cannot access '/var/lib/flatpak/exports/share/dconf/profile/': No such file 
or directory
 ~ $ ls -ld /var/lib/flatpak/exports/share/dconf/
ls: cannot access '/var/lib/flatpak/exports/share/dconf/': No such file or 
directory
 ~ $ ls -ld /var/lib/flatpak/exports/share/
drwxr-xr-x 4 root root 4096 Apr 12  2019 /var/lib/flatpak/exports/share/


-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firejail-profiles depends on:
ii  firejail  0.9.62-4~bpo10+1

firejail-profiles recommends no packages.

firejail-profiles suggests no packages.

-- Configuration Files:
/etc/firejail/meld.profile changed [not included]

-- no debconf information

Bug#968383: interimap: fails to work with Dovecot v2.3.11: ERROR: 0 bytes read (got EOF)

[Jonas Smedegaard]

Package: interimap
Version: 0.5.2-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

All my 5 interimap profiles stopped working when security fix was applied
for my local Dovecot install was applied.

Example:

$ interimap --config=jones
jones_local: ERROR: 0 bytes read (got EOF)
jones_local: IMAP traffic (bytes): recv 0 sent 0


It seems there is no --verbose option (only --quiet) so I will ask you to
please guide me in how to provide more detailed data to work with.

I assume this is a general problem, and have set bug severity accordingly
- - please adjust if you disagree.


Kind regards,

 - Jonas


- -- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 
'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_DIE
Locale: LANG=da_DK.UTF-8, LC_CTYPE=da_DK.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 interimap depends on:
ii  init-system-helpers  1.58
ii  libdbd-sqlite3-perl  1.64-1+b1
ii  libinterimap 0.5.2-1
ii  perl 5.30.3-4

interimap recommends no packages.

Versions of packages interimap suggests:
ii  dovecot-imapd  1:2.3.11.3+dfsg1-1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl82RbAACgkQLHwxRsGg
ASHqRw//U/ectjAbGlRA059zwGb6Gl365NufkFscm8ItYblnE1kJcbvgpGAHmg4c
dEOrIzPPMmme6PV1hzk3HDbe9+KCjvwta/kecfvJJzYbohwYf++G+yDACMJlpB4B
PWalaRLFmwRhLp98M033zF+GAH5u6O0ujoIIwe6naVEk/dvEyrHZi/UjMNCcos4e
h4Gyj0cO6xtl6c37yqBf/jmd6zQu2LDFAgToS8mnoNogeB/XMw6UCI+ccAy2gcqm
Nhjw+sN7+alZpk0lyat1Gs8TWhXtSfukk3oRPXnCFjS3ZAbx7hdQexgBEuUMWn0q
eqEnoKeQ/gdEHzmsY4DqtMkM4z5jGO6LxdWb5XX9B2jbkkj1GqFlXQKdWnYiwQKX
/rq1dHkCi7cV+K9YnPZdgwkNVymuG+BKmmoSAuAFiRNt4EZvTmkaAxs10WXHCly3
eQLOYk5/M/JtdO9n1DJp1N22A2iqWPeowQu8LVtNPx3uN/IlBhvGsECIuzaUQIHx
te99i5+Vd9qpL0iJXyPjfimkNO5FeTkSmQ90mQ8jB87Dqrt/YE60BlSoKZ9dL7gB
iM/kME3wTKjGe+fY8ypWtAR6tXMyHgkmkimRdQJvDHRQvArmnleKpWk4ubs3jDTy
Y3g6+6SSwx7qkNTcAwe9Ragerow5yjM6yRia3E9OzNe0Bt/VWAE=
=nQRJ
-END PGP SIGNATURE-

Bug#968382: element-desktop: /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied

[Reiner Herrmann]

Hi Hans,

On Fri, Aug 14, 2020 at 09:56:53AM +0200, Hans-Christoph Steiner wrote:
> (node:8) [DEP0005] DeprecationWarning: Buffer() is deprecated due to security 
> and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or 
> Buffer.from() methods instead.
> 
> (element-desktop:8): dconf-WARNING **: 09:51:34.251: Unable to open 
> /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied
> Starting auto update with base URL: https://packages.riot.im/desktop/update/
> Auto update not supported on this platform
> [50:0814/095134.384213:FATAL:platform_shared_memory_region_posix.cc(254)] 
> This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo 
> chmod 1777 /dev/shm' to fix.

The error message looked a bit different for me:

> (node:12) [DEP0005] DeprecationWarning: Buffer() is deprecated due to 
> security and usability issues. Please use the Buffer.alloc(), 
> Buffer.allocUnsafe(), or Buffer.from() methods instead.
> Starting auto update with base URL: https://packages.riot.im/desktop/update/
> Auto update not supported on this platform
> 
> (element-desktop:12): libappindicator-WARNING **: 10:20:24.734: Unable to get 
> the session bus: Could not connect: No such file or directory
> 
> (element-desktop:12): LIBDBUSMENU-GLIB-WARNING **: 10:20:24.734: Unable to 
> get session bus: Could not connect: No such file or directory
> [66:0814/102024.817688:FATAL:platform_shared_memory_region_posix.cc(254)] 
> This is frequently caused by incorrect permissions on /dev/shm.  Try 'sudo 
> chmod 1777 /dev/shm' to fix.

It turned out that "nodbus" from electron.profile (which gets included) was the 
problem.
So I added "ignore nodbus" to element-desktop.profile and it was starting.
Does this also work for you?

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#968384: mdbtools: Consider switching to active fork (https://github.com/evanmiller/mdbtools)

[Bas Couwenberg]

Source: mdbtools
Version: 0.7.1-6
Severity: normal
Tags: patch

Dear Maintainer,

As reported by Even Rouault in GDAL PR#2856 [0]:

"
 I see in https://salsa.debian.org/debian/mdbtools/-/blob/master/debian/watch,
 Debian follows https://github.com/brianb/mdbtools whose last commit was in
 2017 whereas @nyalldawson suggests to follow
 https://github.com/evanmiller/mdbtools which has lately received a lot of
 fixes from what I can see
"

You can use the attached watch file to use the fork.

[0] https://github.com/OSGeo/gdal/pull/2856#issuecomment-673929071

Kind Regards,

Bas
version=3
opts=\
dversionmangle=s/\+(debian|dfsg|ds|deb)\d*$//,\
uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/,\
filenamemangle=s/(?:.*?)?(?:rel|v|mdbtools)?[\-\_]?(\d\S+)\.(tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))/mdbtools-$1.$2/
 \
https://github.com/evanmiller/mdbtools/releases \
(?:.*?/archive/)?(?:rel|v|mdbtools)?[\-\_]?(\d\S+)\.(?:tgz|tbz|txz|(?:tar\.(?:gz|bz2|xz)))

Bug#968386: lynkeos.app: No text is shown in the UI

[Jonas Andradas]

Package: lynkeos.app
Version: 3.3+dfsg1-2+b1
Severity: important

Dear Maintainer,

when launching the Lynkeos binary, no text is shown in the application UI:
there are no labels, no text in the menus or in the windows themselves.

Two screenshots are provided and the output with errors shown in the console
when launched from the command-line:

~~~
user@debian$ Lynkeos
2020-08-14 10:26:20.382 Lynkeos[21432:21432] File NSData.m: 287. In
readContentsOfFile Open ((null)) attempt failed - bad path
2020-08-14 10:26:20.384 Lynkeos[21432:21432] Could not convert cursor bitmap
data
2020-08-14 10:26:20.561 Lynkeos[21432:21432] Setting unknown encoding 1
jonas@darkstar:~/projects/MandA/pfSense-udp-1195-JonasA$ Lynkeos
2020-08-14 10:26:54.503 Lynkeos[21488:21488] File NSData.m: 287. In
readContentsOfFile Open ((null)) attempt failed - bad path
2020-08-14 10:26:54.503 Lynkeos[21488:21488] Could not convert cursor bitmap
data
2020-08-14 10:26:54.605 Lynkeos[21488:21488] Setting unknown encoding 1
2020-08-14 10:29:28.048 Lynkeos[21488:21488] WARNING: -drawGState called with a
NULL target context ((null)) or source context (0x55590331c1b0)
2020-08-14 10:29:28.156 Lynkeos[21488:21488] WARNING: -drawGState called with a
NULL target context ((null)) or source context (0x55590331c1b0)
2020-08-14 10:29:28.791 Lynkeos[21488:21488] WARNING: -drawGState called with a
NULL target context ((null)) or source context (0x55590331c1b0)
2020-08-14 10:29:28.918 Lynkeos[21488:21488] WARNING: -drawGState called with a
NULL target context ((null)) or source context (0x55590331c1b0)
~~~




-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages lynkeos.app depends on:
ii  dcraw  9.28-2
ii  gnustep-back0.28   0.28.0-2
ii  gnustep-base-runtime   1.27.0-3
ii  gnustep-gui-runtime0.28.0-3
ii  libatlas3-base [liblapack.so.3]3.10.3-10
ii  libavcodec58   7:4.3.1-1
ii  libavformat58  7:4.3.1-1
ii  libavutil567:4.3.1-1
ii  libc6  2.31-3
ii  libcfitsio83.470-4
ii  libfftw3-single3   3.3.8-2
ii  libgcc-s1  10.2.0-5
ii  libgnustep-base1.271.27.0-3
ii  libgnustep-gui0.28 0.28.0-3
ii  liblapack3 [liblapack.so.3]3.9.0-3
ii  libobjc4   10.2.0-5
ii  libopenblas0-pthread [liblapack.so.3]  0.3.10+ds-3
ii  libswscale57:4.3.1-1
ii  libtiff5   4.1.0+git191117-2
ii  lynkeos.app-common 3.3+dfsg1-2

lynkeos.app recommends no packages.

lynkeos.app suggests no packages.

-- no debconf information

Bug#968385: FTBFS on kfreebsd-*

[Laurent Bigonville]

Source: libgc
Version: 1:8.0.4-2
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian-...@lists.debian.org
Usertags: kfreebsd

Hello,

libgc FTBFS on kfreebsd-*

This is happening because some symbols are marked in the symbols file as
non-existant on these architectures while they are actually existing.

Shouldn't the symbols file be adjusted? Or are these symbols really not
supposed to be present?

Kind regards,
Laurent Bigonville

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#968364: pkg-perl-tools: mojibake in dpt-forward (forwarding Debian bugs as GitHub issues)

[Damyan Ivanov]

-=| gregor herrmann, 13.08.2020 17:20:32 +0200 |=-
> Package: pkg-perl-tools
> Version: 0.62
> Severity: minor
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> In #968362 I've used the ellipsis UTF-8 character to denote an elison
> like: '[…]'.
> 
> After running `dpt forward 968362' the nice 3 dots end up in the GitHub
> issue at https://github.com/maxmind/MaxMind-DB-Writer-perl/issues/112
> as: '[�]'
> 
> Looks like there's some (UTF-8 or other) encoding directive missing
> somewhere …

I think the problem is in giving Net::GitHub::V3 a binary string 
instead of unicode string. Here's why:

Net::GitHub::V3 uses JSON::MaybeXS to construct the HTTP request 
payload. JSON::MaybeXS prefers Cpanel::JSON::XS which encodes the 
input in UTF-8.

I have tried this is a terminal that works with UTF-8:

# working
$ perl -MCpanel::JSON::XS -MEncode \
  -wE'my $test="tæst"; say $test, encode_json({test=>decode_utf8($test)})'
tæst{"test":"tæst"}

# not working
$ perl -MCpanel::JSON::XS -MEncode \
  -wE'my $test="tæst"; say $test, encode_json({test=>$test})'
tæst{"test":"tæst"}

Note the STDOUT handle has no encoding layer and there is no 'use 
utf8' in effect -- the input string is binary.

The difference is that the not working case passes a binary string. My 
guess is that encode_json() tries to encode its arguments, basically 
invoking Encode's encode_utf8() on them, resulting in double encoding. 
Something like:

$ perl -MEncode -wE'my $test="tæst"; say $test, encode_utf8($test)'
tæsttæst

The working case works because encode_json() is given an unicode 
string, which produces an utf8-encoded binary string when given to 
encode_utf8().

So my proposal is to make sure that all github related methods decode 
message contents before giving them to Net::GitHub::V3. Perhaps 
handling that in Message::edit_message:93 would be enough, but that is 
also used with non-github backends and would need testing.


-- Damyan

Bug#968387: apparmor: Broken printing and printer autodiscovery

[user]

Package: apparmor
Severity: grave
Justification: renders package unusable



I installed lxc on a freshly installed debian 10 (standard iso + the tasks:
desktop, kde, print-server, laptop).

- The printer was not autodiscovered in the "Print" window of any program,
  and in the "Add printer" window of system-config-printer-settings.
- Even after setting the device URI, print jobs did not make it to the printer
  and there were no info about toner levels, printer availability, etc.

I did not touch apparmor, but aa-status said it was enforcing on a lot
of programs, including /usr/sbin/{cupsd,cups-browsed}, so I ran

aa-complain /usr/sbin/cupsd
aa-complain /usr/sbin/cups-browsed

Now, the printer was autodiscovered, but printing still did not work, so I did

apt-get autopurge apparmor

Now printing works fine, I have toner level info, etc.

Bug#967218: telepathy-rakia: Unversioned Python removal in sid/bullseye

[Simon McVittie]

Control: tags -1 + patch

On Tue, 04 Aug 2020 at 09:29:23 +, Matthias Klose wrote:
> We will keep some Python2 package as discussed in
> https://lists.debian.org/debian-python/2020/07/msg00039.html
> but removing the unversioned python packages python-minimal, python,
> python-dev, python-dbg, python-doc.

This is RC, and makes telepathy-rakia unbuildable in unstable, because
the python package has already been removed. It is now up for autoremoval
as a result.

When uploading (whether maintainer or NMU) to fix this, there are several
easy fixes that can be applied at the same time. I've sent a merge request
https://salsa.debian.org/telepathy-team/telepathy-rakia/-/merge_requests/1
(or see attached diff).

Note that I have only build-tested this, because I no longer use
Telepathy, so a -rakia user should test it before upload.

smcv
diff --git a/debian/changelog b/debian/changelog
index 9f354da..ca502d1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+telepathy-rakia (0.8.0-4) UNRELEASED; urgency=medium
+
+  [ Simon McVittie ]
+  * Remove myself from Uploaders
+  * Update Vcs-Git (Closes: #907463)
+  * Remove Dafydd Harries from uploaders.
+Thanks for your past work on this package, Daf! (Closes: #965399)
+  * Explicitly use python2 for build.
+The unversioned python executable is going away for Debian 11.
+(Closes: #967218)
+  * Remove telepathy-sofiasip transitional package (Closes: #878985)
+
+  [ Jonny Lamb ]
+  * Remove myself from Uploaders.
+
+ -- Simon McVittie   Fri, 14 Aug 2020 09:41:12 +0100
+
 telepathy-rakia (0.8.0-3) unstable; urgency=medium
 
   * debian/watch: only watch for 0.x stable branches
diff --git a/debian/control b/debian/control
index 0a6e31e..0f2b9c9 100644
--- a/debian/control
+++ b/debian/control
@@ -2,12 +2,9 @@ Source: telepathy-rakia
 Section: net
 Priority: optional
 Maintainer: Debian Telepathy maintainers 
-Uploaders: Dafydd Harries ,
-   Simon McVittie ,
-   Sjoerd Simons ,
+Uploaders: Sjoerd Simons ,
Laurent Bigonville ,
-   Loic Minier ,
-   Jonny Lamb 
+   Loic Minier 
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
libglib2.0-dev (>= 2.30),
@@ -16,11 +13,11 @@ Build-Depends: debhelper (>= 9),
libsofia-sip-ua-glib-dev (>= 1.12.11),
libtelepathy-glib-dev (>= 0.17.7),
libssl-dev,
-   xsltproc,
-   python
+   python2,
+   xsltproc
 Standards-Version: 3.9.5
-Vcs-Git: git://anonscm.debian.org/pkg-telepathy/telepathy-rakia.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-telepathy/telepathy-rakia.git
+Vcs-Git: https://salsa.debian.org/telepathy-team/telepathy-rakia.git
+Vcs-Browser: https://salsa.debian.org/telepathy-team/telepathy-rakia
 Homepage: http://telepathy.freedesktop.org/
 
 Package: telepathy-rakia
@@ -33,13 +30,3 @@ Provides: telepathy-connection-manager, telepathy-sofiasip
 Description: SIP connection manager for the Telepathy framework
  telepathy-rakia is a SIP connection manager for the Telepathy framework
  (http://telepathy.freedesktop.org) based on the SofiaSIP-stack.
-
-Package: telepathy-sofiasip
-Architecture: all
-Section: oldlibs
-Priority: extra
-Depends: telepathy-rakia,
- ${misc:Depends}
-Description: Transitional package for telepathy-rakia
- This is a transitional package to ease upgrades to the telepathy-rakia
- package. It can safely be removed.
diff --git a/debian/rules b/debian/rules
index 99cb3d3..62a60ca 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,11 +11,9 @@ override_dh_auto_configure:
 		--libdir="\$${prefix}/lib" \
 		--libexecdir="\$${libdir}/telepathy" \
 		--disable-static \
+		PYTHON=python2 \
 $(NULL)
 
-override_dh_install:
-	dh_install --list-missing
-
 # The regression tests are too prone to race conditions for the buildds,
 # and don't work when autoreconf'd with Automake 1.13.
 override_dh_auto_test:
diff --git a/debian/telepathy-rakia.install b/debian/telepathy-rakia.install
deleted file mode 100644
index 0148204..000
--- a/debian/telepathy-rakia.install
+++ /dev/null
@@ -1,5 +0,0 @@
-usr/include/
-usr/lib/telepathy/
-usr/share/dbus-1/services/
-usr/share/man/man8/
-usr/share/telepathy/managers/

Bug#967217: telepathy-idle: Unversioned Python removal in sid/bullseye

[Simon McVittie]

Control: tags -1 + patch

On Tue, 04 Aug 2020 at 09:29:22 +, Matthias Klose wrote:
> We will keep some Python2 package as discussed in
> https://lists.debian.org/debian-python/2020/07/msg00039.html
> but removing the unversioned python packages python-minimal, python,
> python-dev, python-dbg, python-doc.

This is RC, and makes telepathy-idle unbuildable in unstable, because
the python package has already been removed. It doesn't seem to be up for
autoremoval yet, perhaps because polari is relatively high-popcon, although
I suspect polari will decline rapidly now that the GNOME metapackages no
longer pull it in.

When uploading (whether maintainer or NMU) to fix this, there are several
easy fixes that can be applied at the same time. I've sent a merge request
https://salsa.debian.org/telepathy-team/telepathy-idle/-/merge_requests/2
(or see attached diff).

Note that I have only build-tested this, because I no longer use
Telepathy, so an -idle user should test it before upload.

smcv
diff --git a/debian/changelog b/debian/changelog
index 135fab6..b84c678 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+telepathy-idle (0.2.0-3) UNRELEASED; urgency=medium
+
+  [ Simon McVittie ]
+  * Remove myself from Uploaders
+  * Update Vcs-Git (Closes: #907465)
+  * Remove Dafydd Harries from Uploaders.
+Thanks for your past work on this package, Daf! (Closes: #965395)
+  * Explicitly use python2.
+The unversioned python executable is going away for Debian 11.
+(Closes: #967217)
+
+  [ Jonny Lamb ]
+  * Remove myself from Uploaders.
+
+ -- Simon McVittie   Fri, 14 Aug 2020 09:20:58 +0100
+
 telepathy-idle (0.2.0-2) unstable; urgency=medium
 
   * debian/watch: don't watch for development or 1.0-branch versions
diff --git a/debian/control b/debian/control
index 7c435a8..efe2c75 100644
--- a/debian/control
+++ b/debian/control
@@ -2,12 +2,9 @@ Source: telepathy-idle
 Section: net
 Priority: optional
 Maintainer: Debian Telepathy maintainers 
-Uploaders: Dafydd Harries ,
-   Riccardo Setti ,
-   Simon McVittie ,
+Uploaders: Riccardo Setti ,
Sjoerd Simons ,
-   Laurent Bigonville ,
-   Jonny Lamb 
+   Laurent Bigonville 
 Build-Depends: debhelper (>= 9),
dh-autoreconf,
dpkg-dev (>= 1.16.1),
@@ -15,11 +12,11 @@ Build-Depends: debhelper (>= 9),
libdbus-1-dev,
libdbus-glib-1-dev (>= 0.51),
libtelepathy-glib-dev (>= 0.22),
-   xsltproc,
-   python
+   python2,
+   xsltproc
 Standards-Version: 3.9.5
-Vcs-Git: git://anonscm.debian.org/pkg-telepathy/telepathy-idle.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=pkg-telepathy/telepathy-idle.git
+Vcs-Git: https://salsa.debian.org/telepathy-team/telepathy-idle.git
+Vcs-Browser: https://salsa.debian.org/telepathy-team/telepathy-idle
 Homepage: http://sourceforge.net/projects/telepathy-idle
 
 Package: telepathy-idle
diff --git a/debian/rules b/debian/rules
index 99456a0..8c440db 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,7 @@ override_dh_auto_configure:
 		--libdir="\$${prefix}/lib" \
 		--libexecdir="\$${libdir}/telepathy" \
 		--disable-static \
+		PYTHON=python2 \
 $(NULL)
 
 # The regression tests are too prone to race conditions for the buildds,

Bug#966087: libreoffice-writer: Cannot save file: General input/output error

[frydo bugdeb]

Hi,

I have the same exact error.
I am using a 32bit computer too.

I have no problem with my 64bit computer with the same configuration.

You don't even need to write anything in the document.
Only save file, and the error occurs, with those lu9017o81.tmp empty files 
created in the repertory you want to save the file in.

libreoffice calc saves files, but I have a file for which I got a message that 
some attributes could not be read (but I don't know how to find which ones).
This error does not appear on my 64bit computer.

Bug#968389: konsole: Cannot select left/right in nano

[user]

Package: konsole
Version: 4:18.04.0-1
Severity: normal


Open Konsole, open nano.

shift + up/down arrows works.
Same for shift + ctrl + up/down.

shift + left/right arrows does nothing.
Same for shift + ctrl + left/right.

Bug#968388: build-rdeps: with dose-extra, lists too many rdeps

[Christian Kastner]

Package: devscripts
Version: 2.20.4
Severity: normal

Given the command `build-rdeps python3-pygments`, without package dose-extra
installed, I get a warning

   WARNING: dose-extra >= 4.0 is not installed. Falling back to old unreliable 
behaviour.

and it produces a reasonable 73 packages as output.

With dose-extra installed, the same command produces 1,748(!) packages, which
cannot be true. I've randomly checked a few of their debian/control files and
neither had python3-pygments listed.


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.5
ii  fakeroot  1.24-1
ii  file  1:5.38-5
ii  gnupg 2.2.20-1
ii  gpgv  2.2.20-1
ii  libc6 2.31-3
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004000-1
ii  libwww-perl   6.46-1
ii  patchutils0.4.2-1
ii  perl  5.30.3-4
ii  python3   3.8.2-3
ii  sensible-utils0.0.12+nmu1
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.1.10
pn  at  
ii  curl7.68.0-1+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2020.06.24
ii  dput1.0.3
ii  dupload 2.9.5
ii  equivs  2.3.1
ii  libdistro-info-perl 0.23
ii  libdpkg-perl1.20.5
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.25-2
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.09-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-2
ii  licensecheck3.0.47-1
ii  lintian 2.89.0
ii  man-db  2.9.3-2
ii  patch   2.7.6-6
ii  pristine-tar1.49
ii  python3-apt 2.1.3
ii  python3-debian  0.1.37
ii  python3-magic   2:0.4.15-4
ii  python3-requests2.23.0+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.26-3
ii  strace  5.5-3
ii  unzip   6.0-25
ii  wget1.20.3-1+b3
ii  xz-utils5.2.4-1+b1

Versions of packages devscripts suggests:
pn  adequate 
ii  autopkgtest  5.13.1
pn  bls-standalone   
ii  build-essential  12.8
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.2
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
ii  dose-extra   5.0.1-15
pn  duck 
pn  faketime 
ii  gnuplot-nox [gnuplot]5.2.8+dfsg1-2
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-2
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-1
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.9-3.2
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:8.3p1-1
pn  piuparts 
pn  postgresql-client
ii  quilt0.66-2.1
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- debconf-show failed

Bug#968379: wireshark-common: versioned dependency on libsystemd0 breaks installability with elogind

[Mark Hindley]

Control: forwarded -1 https://github.com/elogind/elogind/issues/170

Balint and Thorsten,

On Fri, Aug 14, 2020 at 08:43:31AM +0200, Balint Reczey wrote:

[…]

> libelogind0 provides only libsystemd0 (= 243.7) which I understand
> since keeping up with systemd upstream is hard, but other packages
> will pick up versioned dependency on later libsystemd0 like wireshark
> so eventually moving the provided version will be needed. IMO the most
> forward-proof direction is providing newer libsystemd0 versions in
> libelogind0 thus I'm reassigning the bug.

Thanks for this. We currently package the latest version of elogind that is
available upstream.

I have enquired what plans there are for a newer version.

Mark

Bug#966270: [Help] Re: seqan autopkg test failures triggered by gcc-defaults

[Andreas Tille]

Hi Michael,

On Fri, Aug 14, 2020 at 09:01:19AM +0200, Michael Crusoe wrote:
> I've got a fixed version of a release candidate of seqan3 3.0.2 in salsa.
> However it needs an updated range-v3 which has yet to be uploaded: see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968053

If the new version you prepared would fix RC bug #966900 as well I'd
say go for an upload.
 
> I can upload the seqan3 3.0.2 release candidate with a code copy of the
> fixed range-v3, but as no packages build-depend on seqan3 I don't see the
> rush. Please feel free to correct my mis-understanding.

I agree that rush is not really needed.  However, our team has currently
lots of RC bugs and these create noise and developer time if the bug
report does not reflect the full story (specifically when different
people try to build this heavy package at the same time to check the
status.
 
Thanks a lot for your work on this

  Andreas.

-- 
http://fam-tille.de

Bug#968390: virtualbox-guest-x11: VBoxDRMClient missing

[Sam Morris]

Package: virtualbox-guest-x11
Version: 6.1.12-dfsg-9
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

VirtualBox guest additions now includes a VBoxDRMClient program that is
missing from the Debian package.

I believe this is used for 3d acceleration under Wayland. I've not had a
change to switch over to Wayland to confirm yet.

Note that upstream installs VBoxDRMClient setuid root and activates it
from VBoxClient --vmsvga; Fedora patch their package to drop the setuid
bit, launch VBoxDRMClient as a systemd service, and activate the service
by udev rules. These changes can be found at
.

- -- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (530, 'testing'), (520, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages virtualbox-guest-x11 depends on:
ii  libc6  2.31-3
ii  libnotify-bin  0.7.9-1
ii  libx11-6   2:1.6.10-3
ii  libxext6   2:1.3.3-1+b2
ii  libxmu62:1.1.2-2+b3
ii  libxt6 1:1.1.5-1+b3
ii  virtualbox-guest-utils 6.1.12-dfsg-9
ii  x11-xserver-utils  7.7+8
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.8-2

virtualbox-guest-x11 recommends no packages.

virtualbox-guest-x11 suggests no packages.

- -- Configuration Files:
/etc/X11/Xsession.d/98vboxadd-xclient changed [not included]

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEEyqqqGsppqDqJKxhV0gtCAlzaJ7kFAl82VF8SHHNhbUByb2Jv
dHMub3JnLnVrAAoJENILQgJc2ie5KBkP/RCmH8TOFHyNCqJtYSM3rf5iy6fHF/Bu
i8BVWf0RmHxI5TmYH48vXKz7WWkUnumMbP1BKehPCAmDVFiZ9cZt1adpkK9OCcrw
/cSFhvvikcFYWi0ywYCPQ9Dnzt+XwqBIk/q2gxkylorL2QxOYD5lyJ4I7W8aLkXh
m23APTwOkHXIdt81od5jS8E2RrbYRwrDmJSVrihuhJzMPuNp7pZ5REkSbcjwPhF6
l0V9YWmoy4mZjuccW4u0Ajh2e5OO8fj4mtVwCelP85wstuKVN4dE0je4RtuOHCTD
1LZ+w78r5HWlWMi/0lA9SnZ7S2jNCjdGr9njV2G8mDTrONhK97U7Kh512uXK+QKY
Wq8Pr15Dc1xfHtMv3EXHFIR9XAt92MOQSjdRadW3XWLqCKEqpGMVRU+JZ7mujhBx
tFMvMbObRdFcDDe4SeUHGTdJ+/WY6zwOJS6LzJSFMyyCRAs52SbvblO87RpvI9G2
U4UcjTWeqkXY7QS09IkxGAmXtjJfBGyb9xcnp44d+6dGpLqrM6MqPVr5yi3kZ83D
Gr0HIgFB2iJtieZ1XMw3EgY1W22d8U08lrlLceCwDipqrkCZ3zurkO1iydVC/va/
80VBqfAQXJqH/bCoGveAl8GIzJsLT9m+ToP/JoSVFbB8rq+flDHgJmrM4idO/hKi
YJW5m85VlLCK
=G6vI
-END PGP SIGNATURE-

Bug#965057: guile OOM test failures on ppc64el

[Matthias Klose]

I'm now NMUing both guile-2.2 and guile-3.0 to just ignore the test results on
ppc64el, without closing the bug reports.  It's blocking the gcc-10 migration to
testing.

Bug#968391: Please support the Librem 5

[Guido Günther]

Package: flash-kernel
Version: 3.102
Severity: wishlist
Tags: patch

To make it simpler to run plain Debian on the Librem 5 it would be great
to have flash-kernel support. The device tree is in the process of being
upstreamed:


https://lore.kernel.org/linux-arm-kernel/20200731082725.21878-1-martin.kepplin...@puri.sm/

Patch at:

https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/22

Remaining blockers for using plain Debian are uboot and atf support but
the uboot/atf shipped with the device is able to boot Debian kernels
just fine.

Cheers,
 -- Guido

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, arm64

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

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.74
pn  devio  
ii  initramfs-tools0.137
ii  linux-base 4.6
ii  mtd-utils  1:2.1.1-1
ii  ucf3.0042

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2020.04+dfsg-2

flash-kernel suggests no packages.

Bug#968392: interimap: please implement option --verbose and config setting null-stderr=MOSTLY

[Jonas Smedegaard]

Package: interimap
Version: 0.5.2-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In my use of interimap, I try to limit chatter to not miss real issues.

Therefore I use setting "null-stderr = YES" for local tunnel interfaces.

This works most of the time, but occationally is counter-productive,
and concretely in recent bug#968383 where my interimap "behaved oddly"
I intuitively looked for some --verbose option but did not think of
needing to tinker with my configuration.

Therefore I suggest to implement what I found more intuitive:

Setting "null-stderr = MOSTLY", treated same as YES by default,
and option --verbose which switches it to mean no.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl82XAkACgkQLHwxRsGg
ASE0ag/+P47b8OCeU4OF9QdKDdOn5OCV2VjSGFDiSuzIt7pwAXEMm3jelENjDDWP
b1+yqwv9p2Fh+M4aNs+fTSYgaw11uL3l3Jq+UOfYHwaPPGF6K35mBSQWW0TXybaX
JYwJOEbYgTRFWukcshgQ6180V8t1l+JYfwCX0hciNWG6FUV8/ziWbBwn6hk+z9yj
NN0Fst9QvH+w7NHqbyvi0AQsPUKZ9uOpDfllln2s0nwr6nKZEJF86/Gt21ON+xrf
az6p3JJujgXc9FLB83SznLcO2uP08xiz4ALlEaZfs5fDl8N+mQyl6bsLt/E1t38M
3A4cbkxlFeTnm8YgTrri1IfcYo2v1IOJw4+tZEHnR1h1Z1l6LysMASodVQ0zRFDU
0GtKdGbVKRgRFfmr66+n4vCG/0dFOhUH5TgUFF7WnMP9GJgi3LvQeX1xJMR50t4Q
AYgX+rdSCQz+iydHxN47ew5Zi8i2SKFUhgcNWUdtdbDdflmJ9viD8lSdvrHkvQUu
VKHRJQxaJzV4+tPESFI/3WlcS0C3TfltcwFGYvBwVNUtT2TQ8PWqWEKJ702jq0l7
+DqryGV3LXxMrEnVw1Xp1yK9l/C0fDixbN9r+EBlP+SK+K1XQi0aRGaeEDngGqnv
OsFAGHBLXJqV3TySp7NTQPpbaRPAsm9LjtL8PaN17vlsY3gtbWA=
=1vnI
-END PGP SIGNATURE-

Bug#963049: [Pkg-freeipa-devel] Bug#963049: pki-base: syntax error in /usr/share/pki/scripts/config

[Timo Aaltonen]

severity normal
thanks

On 18.6.2020 13.31, Laurent Bonnaud wrote:
> 
> Package: pki-base
> Version: 10.9.0~a2-2
> Severity: serious
> 
> 
> Dear Maintainer,
> 
> here is the problem:
> 
> # source /usr/share/pki/scripts/config
> -bash: break: only meaningful in a `for', `while', or `until' loop

This isn't a fatal error. This is caused by forcing the scripts to use
bash, and without that pki-tomcatd wouldn't even start. You may check
where the actual bashism is and fix that, then we'd be able to drop
forcing bash.

-- 
t

Bug#965308: jackd won't start

[Simon McVittie]

On Fri, 14 Aug 2020 at 10:51:46 +0200, Arnaldo Pirrone wrote:
> I would like to point out that the error is not showing up any more after the
> updates, now the error is different

It seems it's now failing to open the configured ALSA PCM devices (which
probably also shouldn't happen?). From the strace output, it seems the
configured ALSA devices doesn't exist in /dev/snd:

> strace -efile jackd -d alsa
...
> openat(AT_FDCWD, "/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 
> ENOENT (File o directory non esistente)
> stat("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=9623, ...}) 
> = 0
> openat(AT_FDCWD, "/dev/snd/controlC0", O_RDONLY|O_CLOEXEC) = 6
> openat(AT_FDCWD, "/dev/snd/controlC0", O_RDWR|O_CLOEXEC) = 6
> openat(AT_FDCWD, "/dev/snd/pcmC0D0c", O_RDWR|O_NONBLOCK|O_CLOEXEC) = -1 
> ENOENT (File o directory non esistente)
> ALSA: Cannot open PCM device alsa_pcm for playback. Falling back to 
> capture-only mode

That seems like a completely different failure mode.

smcv

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Chandra Sekar]

Package: gnome-shell
Version: 3.36.4-1
Severity: normal
X-Debbugs-Cc: chandru...@gmail.com

Dear Maintainer,

There is no option in the status menu to switch to another user on the
system. There is no option to login as another user on the lock screen
either.

There are multiple non-system user accounts on the machine and I'm
logged into the laptop locally (not a remote connection). In such a
scenario, I expect an option to switch between users without having to
log out of the current user's session.

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  evolution-data-server3.36.4-1
ii  gir1.2-accountsservice-1.0   0.6.55-2
ii  gir1.2-atspi-2.0 2.36.0-3
ii  gir1.2-freedesktop   1.64.1-1
ii  gir1.2-gcr-3 3.36.0-2
ii  gir1.2-gdesktopenums-3.0 3.36.1-1
ii  gir1.2-gdm-1.0   3.36.2-1
ii  gir1.2-geoclue-2.0   2.5.6-1
ii  gir1.2-glib-2.0  1.64.1-1
ii  gir1.2-gnomebluetooth-1.03.34.1-1
ii  gir1.2-gnomedesktop-3.0  3.36.4-1
ii  gir1.2-gtk-3.0   3.24.20-1
ii  gir1.2-gweather-3.0  3.36.0-1
ii  gir1.2-ibus-1.0  1.5.22-5
ii  gir1.2-mutter-6  3.36.4-1
ii  gir1.2-nm-1.01.26.0-1
ii  gir1.2-nma-1.0   1.8.30-1
ii  gir1.2-pango-1.0 1.44.7-4
ii  gir1.2-polkit-1.00.105-29
ii  gir1.2-rsvg-2.0  2.48.7-1
ii  gir1.2-soup-2.4  2.70.0-1
ii  gir1.2-upowerglib-1.00.99.11-2
ii  gjs  1.64.3-1
ii  gnome-backgrounds3.36.0-1
ii  gnome-settings-daemon3.36.1-1
ii  gnome-shell-common   3.36.4-1
ii  gsettings-desktop-schemas3.36.1-1
ii  libatk-bridge2.0-0   2.34.1-3
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-3
ii  libcairo21.16.0-4
ii  libecal-2.0-13.36.4-1
ii  libedataserver-1.2-243.36.4-1
ii  libgcr-base-3-1  3.36.0-2
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-5
ii  libgirepository-1.0-11.64.1-1
ii  libgjs0g 1.64.3-1
ii  libgles2 1.3.2-1
ii  libglib2.0-0 2.64.4-1
ii  libglib2.0-bin   2.64.4-1
ii  libgnome-autoar-0-0  0.2.4-2
ii  libgnome-desktop-3-193.36.4-1
ii  libgraphene-1.0-01.10.2-1
ii  libgstreamer1.0-01.16.2-2
ii  libgtk-3-0   3.24.20-1
ii  libical3 3.0.8-2
ii  libjson-glib-1.0-0   1.4.4-2
ii  libmutter-6-03.36.4-1
ii  libnm0   1.26.0-1
ii  libpango-1.0-0   1.44.7-4
ii  libpangocairo-1.0-0  1.44.7-4
ii  libpolkit-agent-1-0  0.105-29
ii  libpolkit-gobject-1-00.105-29
ii  libpulse-mainloop-glib0  13.0-5
ii  libpulse013.0-5
ii  libsecret-1-00.20.3-1
ii  libsystemd0  246-2
ii  libwayland-server0   1.18.0-1
ii  libx11-6 2:1.6.10-3
ii  libxfixes3   1:5.0.3-2
ii  mutter   3.36.4-1
ii  python3  3.8.2-3

Versions of packages gnome-shell recommends:
ii  bolt  0.9-1
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.36.2-1
ii  gkbd-capplet  3.26.1-1
ii  gnome-control-center  1:3.36.4-1
ii  gnome-menus   3.36.0-1
ii  gnome-user-docs   3.36.2-1
ii  ibus  1.5.22-5
ii  iio-sensor-proxy  3.0-1
ii  switcheroo-control2.1-1
ii  unzip 6.0-25

Versions of packag

Bug#968395: Stretch update of {{ package }}?

[Emilio Pozuelo Monfort]

Package: terminator
Severity: grave
Tags: security

Dear maintainer(s),

The Debian LTS team would like to fix the security issues which are
currently open in the Stretch version of {{ package }}:
{%- if cve -%}
{% for entry in cve %}
https://security-tracker.debian.org/tracker/{{ entry }}
{%- endfor -%}
{%- else %}
https://security-tracker.debian.org/tracker/source-package/{{ package }}
{%- endif %}

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-...@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of {{ package }} updates
for the LTS releases.

Thank you very much.

{{ sender }},
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/dla-needed.txt

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Simon McVittie]

On Fri, 14 Aug 2020 at 16:01:52 +0530, Chandra Sekar wrote:
> There is no option in the status menu to switch to another user on the
> system. There is no option to login as another user on the lock screen
> either.

Workaround, assuming you are using gdm3:

* lock your screen (Super+L, where Super is usually the Windows logo key)
* press Ctrl+Alt+F1 to get back to the gdm greeter
* log in as another user there

I was looking into this myself recently. The "Switch User" menu item (also
known as "fast user switching") is *meant* to show up in the system menu,
near "Log Out", when there is more than one local user available and
the OS can switch between sessions; but that information is getting lost
somewhere in the path systemd-logind -> accountsservice -> gnome-shell.

The "Switch User" menu item is more or less equivalent to locking the
screen, waiting for it to lock, and switching to the gdm greeter.

There is meant to be an equivalent item on the lock screen, but, again,
the information that says it should appear is getting lost somewhere.

smcv

Bug#911560: Tests for GMAC_TX_DELAY = ... with RevC A20 OLinuxino Lime 2

[Jonas Smedegaard]

Quoting Dieter (2020-08-14 09:03:22)
> On 08/08/2020 14:48, Jonas Smedegaard wrote:
> > Whoa, setting master/slave mode was implemented only since Linux 
> > v5.7: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdbdac7649
> > 
> > Corresponding userspace support was introduced in ethtool v5.8: 
> > https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/?id=558f7cc33d
> > 
> > Ethtool v5.8 is not yet in Debian - was released upstream only 4 
> > days ago. Sorry, I thought master/slave was same as MDI/MDI-X, but 
> > those are independent: The former is which end provides clock 
> > source, then latter is which wires are used: 
> > https://en.wikipedia.org/wiki/Gigabit_Ethernet#1000BASE-T
> > 
> > According to 
> > https://www.speedguide.net/articles/network-adapter-optimization-3449 
> > when auto-negotiated "multi-port devices such as switches become the 
> > master when connected to a single port device. If both ends are 
> > multi-port devices, the one with higher seed bits becomes the 
> > master."
> > 
> > That seems to indicate that you should reliably put the device in 
> > slave mode by simply plugging it into a gigabit switch.  Still not 
> > sure how to force master mode (other than at the other end run Linux 
> > 5.7 and compile and use ethtool 5.8), as the above does not tell 
> > which end "wins" when both are single-port devices.
> 
> Thanks for the information.
> Since ethtool 5.8 is now available, i can install debian unstable on the
> laptop and test different combinations.

Yes - I was excited too seeing that package update appear today

I filed a bugreport requesting an update which possibly helped speed 
this up, but maybe it would have been done by now regardless.


> >> u-boot with FORCE_MASTER and TX-Delay 4:
> >> Same as above.
> >>
> >>
> >> u-boot with CONFIG_PHY_MICREL instead of CONFIG_PHY_REALTEK
> > 
> > Ohhh, good point - I totally missed that detail!
> > 
> > Seems more optimal to enable CONFIG_PHY_MICREL_KSZ9031.
> > 
> > Would be helpful if you could test...
> > 
> >   * CONFIG_PHY_MICREL_KSZ9031 instead of CONFIG_PHY_MICREL
> >   * enabling both CONFIG_PHY_REALTEK and CONFIG_PHY_MICREL_KSZ9031
> >   * above, with various values for TX-Delay
> 
> Yes, i can test that!

Thanks!

To be honest, I could test this myself as well - I do have those boards 
lying around, but some of them are in active use, and I keep finding 
other things more important/exciting, so really appreciate your help 
here!

Another benefit of this being done between the two of us is that we get 
the details more carefully laid out and documented.  At least for me it 
has been an eye-opener in just how complex a seemingly simple "LIME2 is 
flaky at high speeds" turns out to be, if we wanna do better than "then 
just avoid those flaky modes".


> >> Good performance with TX-Delay = [3,4].
> >> The results with TX-Delay = 2 could not be reproduced.
> >>
> >>
> >> Summed up: TX-delay = 3/4 seems useful for the Micrel phy.
> >> With TX-delay = 0, no connection was possible at all.
> > 
> > I would expect TX-delay = 0 to behave same as TX-delay not set at 
> > all - is that your experience as well?
> 
> To be honest, i did not disable the configuration, as i always started 
> from A20-OLinuXino..._defconfig, and there the Delay is set to 0 by 
> default.
> 
> But i just checked, if the line with GMAC_TX_DELAY is commented out in
> the config, make will ask for a value, 0 being the default.
> -> Yes, TX-Delay 0 is equal to this config not being set at all.

Thanks for confirming!


> >> Do you know what the switch regarding PHY_MICREL or PHY_REALTEK 
> >> does?
> >> Is this possibly only used in u-boot, and therefore irrelevant as 
> >> soon as linux boots?
> > 
> > those switches enable code chunks in u-boot.  My (vague!) 
> > understanding is that some but not all such code chunks does some 
> > initialization of hardware chips, and that Linux may or may not do 
> > its own (re)initialization of same bits.
> > 
> > In other words: Possibly - it depends... :-)
> 
> I see, in that case i would suppose that network functionality in 
> u-boot might depend on the compiled in drivers.

Yeah - except it is not really "drivers" in u-boot.


> Likely independent of network functionality when the OS is brought up.

Cold-booting u-boot is certainly independent of Linux.

But Warm-booting u-boot after rebooting from a loaded Linux is *not* 
independent of Linux.

Neither is Linux loaded from u-boot independent of u-boot.


> I arrived at this conclusion, as u-boot without the MICREL Phy has 
> working ethernet in Linux with the TX-Delay being set.

Imagine Micrel PHY needs pins X and Y enabled to work well, and u-boot 
sets X and flips Y, and Linux flips X and sets Y.

Cold-booting u-boot would fail, but then loading Linux would work.

Rebooting into u-boot from working linux would fail.

Rebooting into u-boot from failing u-boot would work.

Cold-booting u-boot, rebooting u

Bug#966499: unicode-cldr-core: Please generate JSON data file also

[James Valleroy]

I found a git repository for converting the data to JSON [1], along with 
instructions on how to use it [2]. However, the cldr-localenames package is not 
available on npm, and I didn't figure out how to rebuild it yet.

But I found another repository [3], in which I can simply run "npm install", 
and it downloads the XML data and converts it to JSON. The resulting data is 
very close to what is shipped in php-getttext-languages, and should be fine for 
my purposes.

[1] https://github.com/unicode-cldr/cldr-json
[2] http://cldr.unicode.org/development/updating-codes/updating-json-data
[3] https://github.com/rxaviers/cldr-data-npm




signature.asc
Description: OpenPGP digital signature

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

[Janek Stolarek]

Hi guys,

I believe the fix for this bug introduced a security regression that I only 
noticed just now. 
Recall how I was able to test whether Secure Boot is enabled:

[root@skynet : ~] dmesg | grep secu
[0.00] secureboot: Secure boot enabled

Here's what I get now:

[root@skynet : ~]  dmesg | grep secu
[0.00] secureboot: Secure boot could not be determined (mode 0)

This happens both on kernel 5.6 (used when I reported the bug originally) and 
5.7. I wanted to 
double-check that this is due to the fix in grub but the old packages are no 
longer in the repo 
so I can't downgrade to test. Googling points me to similar past bug in GRUB:

https://bugzilla.redhat.com/show_bug.cgi?id=1418360

and the suggestion there is that "failure detect secure boot status causes the 
kernel to disable a 
number of security checks" which makes this a security issue. There'a also a 
lot of technical 
discussion that I don't follow but it probably will make more sense to you.

Should I file a separate bug report for this?

Janek

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

[Janek Stolarek]

Please disregard my last email completely - fault on my side. Secure Boot works 
as expected.

Janek

Bug#968383: marked as done (interimap: fails to work with Dovecot v2.3.11: ERROR: 0 bytes read (got EOF))

[Guilhem Moulin]

On Fri, 14 Aug 2020 at 09:33:03 +, Debian Bug Tracking System wrote:
>> All my 5 interimap profiles stopped working when security fix was applied
>> for my local Dovecot install was applied.
> 
> False alarm: Turned out to be a change in dovecot configuration files 
> incompatible with my accessing it via tunnel.
> 
> Revealed by manually running the underlying doveadm command.

Thanks for the update, Jonas!  Mind sharing what you had to change in
Dovecot?  1:2.3.11.3+dfsg1-1 doesn't break the test suite, so maybe you
have a setup it'd be worth having test covering for.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

[Steve McIntyre]

On Fri, Aug 14, 2020 at 12:08:59PM +0100, Janek Stolarek wrote:
>Please disregard my last email completely - fault on my side. Secure Boot 
>works as expected.

ACK, no worries.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#968395: Stretch update of {{ package }}?

[Markus Frosch]

Hi Emilio,

On Fri, 2020-08-14 at 12:40 +0200, Emilio Pozuelo Monfort wrote:
> The Debian LTS team would like to fix the security issues which are
> currently open in the Stretch version of {{ package }}:
> 

I'm not aware of any security issues with Terminator.

Not sure why went wrong here, apart from the template rendering.

Cheers
Markus
-- 
lazyfro...@debian.org
https://lazyfrosch.de

Bug#901612: ifupdown-extra: Patch confirmed

[Vincent van Adrighem]

Package: ifupdown-extra
Version: 0.27
Followup-For: Bug #901612

Dear Maintainer,

We are also impacted by this bug. On boot, static routes are not added.
After applying the patch mentioned in the previous comment,
this works fine.

We investigated the newer package in current stable (0.28) and did not find a 
fix for our
problem in there, so it still applies to 0.28 as well. We plan to upgrade in 
the next few weeks.

Is there any reason not to apply (a modified version of) the patch?

-- System Information:
Debian Release: 9.13
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-13-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ifupdown-extra depends on:
ii  bind9-host [host]1:9.10.3.dfsg.P4-12.3+deb9u6
ii  curl 7.52.1-5+deb9u11
ii  dpkg 1.18.25
ii  host 1:9.10.3.dfsg.P4-12.3+deb9u6
ii  iproute2 4.9.0-1+deb9u1
ii  iputils-arping   3:20161105-1
ii  iputils-ping [ping]  3:20161105-1
ii  net-tools1.60+git20161116.90da8a0-1
ii  netcat-traditional [netcat]  1.10-41+b1

Versions of packages ifupdown-extra recommends:
ii  ethtool  1:4.8-1+b1
ii  ndisc6   1.0.3-3

ifupdown-extra suggests no packages.

-- Configuration Files:
/etc/network/routes changed [not included]

-- no debconf information

-- 
*
*


This message may contain information that is not intended for you. If 
you are not the addressee or if this message was sent to you by mistake, 
you are requested to inform the sender and delete the message. Connectis 
accepts no liability for damage of any kind resulting from the risks 
inherent in the electronic transmission of messages.

Bug#968339: Accept

[Vasyl Gello]

Control: owner -1 !

Hi Gianfranco!

Thanks for reporting this! I will investigate the issue and file it upstream.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#960047: [Pkg-phototools-devel] Bug#960047: darktable: Superfluous dependencies

[David Bremner]

astian  writes:

> Control: found -1 3.2.1-2
>
> What's the problem with fixing this? It's a one-liner FFS.
>

The problem is a lack of time and motivation. You are not helping with
either by sending such messages.

d

Bug#952593: Debian RT - please install libgd-perl in wolkenstein.debian.org

[Laura Arjona Reina]

Hello DSA

Thanks for installing liblocale-codes-perl in wolkenstein.

Sorry to bother again, we're still facing build errors in www-master
with Debian 10 (error text below), it seems that the package libgd-perl
is also needed.

I'm attaching a patch for the debian.org-www-master.debian.org
dependencies including the new dependency.

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona


wml -q -D CUR_YEAR=2020 -o UNDEFuEN:devel-manuals.en.html@g+w
devel-manuals.wml
ePerl:Error: Perl parsing error (interpreter rc=2)

 Contents of STDERR channel: -
Can't locate GD.pm in @INC (you may need to install the GD module) (@INC
contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
/usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28
/usr/share/perl/5.28 /usr/local/lib/site_perl) at /tmp/wml.11796.tmp1
line 197.
BEGIN failed--compilation aborted at /tmp/wml.11796.tmp1 line 197.
--
From 3e2b75df84a1ff86118302000dbbef7faccaa177 Mon Sep 17 00:00:00 2001
From: Laura Arjona Reina 
Date: Fri, 14 Aug 2020 13:20:42 +0200
Subject: [PATCH] Install libgd-perl in www-master, needed to build
 /doc/devel-manuals in Debian 10 buster

---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 15561ab..ec13686 100644
--- a/debian/control
+++ b/debian/control
@@ -281,6 +281,7 @@ Depends: debiandoc-sgml,
 	latex-cjk-chinese,
 	ldap-utils,
 	libcgi-pm-perl,
+	libgd-perl,
 	libemail-address-perl,
 	libintl-perl,
 	liblocale-codes-perl,
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#968049: Failed to kill unit rsyslog.service: Input/output error

[Michael Biebl]

Control: reassign -1 lxc
Control: retitle -1 ghost service PIDs in LXC containers
Control: forwarded -1 https://github.com/lxc/lxc/issues/3520

Thanks for taking this issue upstream and getting to the bottom of it.
Given the feedback, this is apparently an LXC issue and Lennart does not
intend to change how this issue is handled (ignoring such cases or
changing the log message), so there doesn't remain anything to do on the
Debian systemd side.
I'm thus going to reassign the issue to lxc and marking the issue as
forwarded.

What follows is a verbatim copy of your lxc bug report (so the Debian
LXC maintainers have some context):






root@il08:~# cat /etc/debian_version
10.5
root@il08:~# lxc-start --version
4.0.4
root@il08:~# lxc-checkconfig
LXC version 4.0.4
Kernel configuration not found at /proc/config.gz; searching...
Kernel configuration found at /boot/config-5.6.0-0.bpo.2-amd64
--- Namespaces ---
Namespaces: enabled
Utsname namespace: enabled
Ipc namespace: enabled
Pid namespace: enabled
User namespace: enabled
newuidmap is not installed
newgidmap is not installed
Network namespace: enabled

--- Control groups ---
Cgroups: enabled

Cgroup v1 mount points:
/sys/fs/cgroup/cpuset
/sys/fs/cgroup/cpu
/sys/fs/cgroup/cpuacct
/sys/fs/cgroup/blkio
/sys/fs/cgroup/memory
/sys/fs/cgroup/devices
/sys/fs/cgroup/freezer
/sys/fs/cgroup/net_cls
/sys/fs/cgroup/perf_event
/sys/fs/cgroup/net_prio
/sys/fs/cgroup/pids
/sys/fs/cgroup/rdma

Cgroup v2 mount points:


Cgroup v1 systemd controller: missing
Cgroup v1 clone_children flag: enabled
Cgroup device: enabled
Cgroup sched: enabled
Cgroup cpu account: enabled
Cgroup memory controller: enabled
Cgroup cpuset: enabled

--- Misc ---
Veth pair device: enabled, loaded
Macvlan: enabled, not loaded
Vlan: enabled, not loaded
Bridges: enabled, loaded
Advanced netfilter: enabled, loaded
CONFIG_NF_NAT_IPV4: missing
CONFIG_NF_NAT_IPV6: missing
CONFIG_IP_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_IP6_NF_TARGET_MASQUERADE: enabled, not loaded
CONFIG_NETFILTER_XT_TARGET_CHECKSUM: enabled, loaded
CONFIG_NETFILTER_XT_MATCH_COMMENT: enabled, not loaded
FUSE (for use with lxcfs): enabled, not loaded

--- Checkpoint/Restore ---
checkpoint restore: enabled
CONFIG_FHANDLE: enabled
CONFIG_EVENTFD: enabled
CONFIG_EPOLL: enabled
CONFIG_UNIX_DIAG: enabled
CONFIG_INET_DIAG: enabled
CONFIG_PACKET_DIAG: enabled
CONFIG_NETLINK_DIAG: enabled
File capabilities:

Note : Before booting a new kernel, you can check its configuration
usage : CONFIG=/path/to/config /usr/bin/lxc-checkconfig

root@il08:~# uname -a
Linux il08.ac.aixigo.de 5.6.0-0.bpo.2-amd64 #1 SMP Debian
5.6.14-2~bpo10+1 (2020-06-09) x86_64 GNU/Linux
root@il08:~# cat /proc/self/cgroup
13:name=systemd:/
12:rdma:/
11:pids:/
10:perf_event:/
9:net_prio:/
8:net_cls:/
7:memory:/
6:freezer:/
5:devices:/
4:cpuset:/
3:cpuacct:/
2:cpu:/
1:blkio:/
0::/
root@il08:~# cat /proc/1/mounts
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs
rw,nosuid,relatime,size=8043192k,nr_inodes=2010798,mode=755 0 0
devpts /dev/pts devpts
rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=1612620k,mode=755 0 0
/dev/sda1 / ext4 rw,noatime 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
pstore /sys/fs/pstore pstore rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime,size=6580660k 0 0
/dev/sda4 /export ext4 rw,noatime 0 0
cgroup /sys/fs/cgroup tmpfs rw,relatime,size=12k,mode=755 0 0
cgroup /sys/fs/cgroup/cpuset cgroup
rw,relatime,cpuset,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuset,clone_children
0 0
cgroup /sys/fs/cgroup/cpu cgroup
rw,relatime,cpu,release_agent=/run/cgmanager/agents/cgm-release-agent.cpu 0
0
cgroup /sys/fs/cgroup/cpuacct cgroup
rw,relatime,cpuacct,release_agent=/run/cgmanager/agents/cgm-release-agent.cpuacct
0 0
cgroup /sys/fs/cgroup/blkio cgroup
rw,relatime,blkio,release_agent=/run/cgmanager/agents/cgm-release-agent.blkio
0 0
cgroup /sys/fs/cgroup/memory cgroup
rw,relatime,memory,release_agent=/run/cgmanager/agents/cgm-release-agent.memory
0 0
cgroup /sys/fs/cgroup/devices cgroup
rw,relatime,devices,release_agent=/run/cgmanager/agents/cgm-release-agent.devices
0 0
cgroup /sys/fs/cgroup/freezer cgroup
rw,relatime,freezer,release_agent=/run/cgmanager/agents/cgm-release-agent.freezer
0 0
cgroup /sys/fs/cgroup/net_cls cgroup
rw,relatime,net_cls,release_agent=/run/cgmanager/agents/cgm-release-agent.net_cls
0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,relatime,perf_event,release_agent=/run/cgmanager/agents/cgm-release-agent.perf_event
0 0
cgroup /sys/fs/cgroup/net_prio cgroup
rw,relatime,net_prio,release_agent=/run/cgmanager/agents/cgm-release-agent.net_prio
0 0
cgroup /sys/fs/cgroup/pids cgroup
rw,relatime,pids,release_agent=/run/cgmanager/agents/cgm-release-agent.pids
0 0
cgroup /sys/fs/cgroup/rdma cgroup
rw,relatime,rdma,release_agent=/run/cgmanager/agents/cgm-release-age

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[Nicholas D Steeves]

Hi,

Itaï BEN YAACOV  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Itaï BEN YAACOV 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: auctex-12
>   Version : 12.2
>   Upstream Author : GNU Project
> * URL : https://www.gnu.org/software/auctex/
> * License : GPL v3
>   Description : AUCTeX version 12, LaTeX environment for Emacs
>
> Hello,
>
> This is not truly an ITP but a request for guidance.
> auctex v11.91 already exists in Debian, and has not been updated since
> 2018 despite bug reports requesting that.  Specifically, the preview-latex
> feature no longer works due to changes in ghostscript, which is solved in
> upstream.
>

At this point the package is a candidate for salvaging.  Davide, are you
aware of this?

https://wiki.debian.org/PackageSalvaging

> The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll
> work on it" and nothing ever happened since, depite numerous follow-ups to
> the bug.  I tried to contact him directly in early 2020, getting no useful
> reply, except that he considers that he is still maintaining the package.
>

Good to hear, I guess he isn't complete MIA :-) Davide, please reply to
bugs, because it looks like you don't care about Auctex anymore.

> I am not a Debian developper, but am able to package (in fact I have packaged
> auctex v12 for personal use).
>
> What should / can be done in this case ?
>

The best case would be for Davide to resume maintenance of this
package.  Failing that it can be salvaged.

Itaï, please note that because none of the bugs are release critical
(RC), the objective is not to NMU (non maintainer upload) to fix bugs,
nor to package the latest upstream version; it is for the package to be
well-maintained.  Have you read all the new contributor documentation,
and is your intent to contribute to Auctex long-term?


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#937695: python-defaults: Python2 removal in sid/bullseye

[Matthias Klose]

Control: tags -1 + wontfix

2.7.18-2 did remove the unversioned python packages.  This version of the
package should ship with bullseye, once it migrates.

Bug#882145: asterisk: pjsip show history causes segmentation fault

[Benoit Panizzon]

Hi Bernie

> Benoit, are you using IPv6? If yes,
> https://issues.asterisk.org/jira/browse/ASTERISK-28854 could be the
> culprit.

Well, why should I use that old legacy phased out ipv4 protocol? :-)

Thank you for the update!

-Benoît-

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Simon McVittie]

Control: reassign -1 gnome-shell,libaccountsservice0
Control: found -1 gnome-shell/3.36.4-1
Control: found -1 accountsservice/0.6.55-1

On Fri, 14 Aug 2020 at 11:44:58 +0100, Simon McVittie wrote:
> I was looking into this myself recently. The "Switch User" menu item (also
> known as "fast user switching") is *meant* to show up in the system menu,
> near "Log Out", when there is more than one local user available and
> the OS can switch between sessions; but that information is getting lost
> somewhere in the path systemd-logind -> accountsservice -> gnome-shell.

At least part of the problem (possibly the whole problem, I'm not sure
yet) is that accountsservice since version 0.6.55 was accidentally
compiled without systemd-logind support, so it can't tell us that the
system can switch users, because it doesn't know. I'm trying to fix
that now.

smcv

Bug#880107: [RSVP] Re: Bug#880107: heimdall-flash: cannot flash RECOVERY on Samsung Note 3 (SM-N9005, hlte)

[Nicholas D Steeves]

Hi Thorsten!

On Tue, Aug 04, 2020 at 02:34:01PM +, Thorsten Glaser wrote:
> Hi Nicholas,
> 
> >Re-sending this bug update to your debian.org address, because
> >t...@mirbsd.de emitted the following during the last attempt
> 
> yes, this is an issue with Googlemail not honouring internet
> standards; nn-submitter@b.d.o is a generic fallback in case
> you can’t figure out a different eMail address.
>

Agreed, googlemail has plenty of issues, but the submitter for this
bug is t...@mirbsd.de (unreachable), while t...@debian.org (reachable).
So it looks to me like this bug fell through the cracks during the
process of changing submitter of your bugs from the former to the
latter.  I could be wrong of course; that's just what it looks like to
me :-)  P.S. This situation is also a good motivation for maintainers
who use self-hosted email to work towards DD: eg, then users who
aren't familiar with advanced BTS use can follow-up on bugs, and reach
the pkg's maintainer, because the debian.org address forwards it.

BTW, why did you use -quiet?  Was that an ideological decision?

> >Would you please test 1.4.2+dfsg-1 currently available in testing and
> >unstable?  I can provide a buster-backport for testing purposes if
> 
> I can do that, but it’ll probably take me some days, first I
> need to find that device… (and something to flash).
>

Thanks, much appreciated!  I'm guessing that by now your device could
use a TWRP upgrade, so maybe that?

> I use sid, so no backporting needed.
>

Wonderful :-)

> Thanks!
>

You're welcome!

> Stéphane, I actually don’t block Googlemail, they’re just too utterly
> stupid to successfully deliver to me (or anyone else using Greylisting
> and not whitelisting their ranges). Same for a few other providers such
> as Hotmail. Some spammers (Yahoo) I do block.

It sounds like your greylist could benefit from SPF Record
updates--either supervised, or automatic, as you prefer.


Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#968149: mysql-router-dbgsym,mysql-server-core-8.0-dbgsym: file conflict due to shared build-id

[Robie Basak]

Thank you for the report.

On Sun, Aug 09, 2020 at 09:48:13PM +0200, Andreas Beckmann wrote:
> This is likely caused by the corresponding binary packages shipping
> identical binaries (or librariesi, ...) with different names.

Looks like this is because this file is shipped in both mysql-router
and mysql-server-core:

/usr/lib/mysql/private/libprotobuf-lite.so.*
/usr/lib/mysql-router/libprotobuf-lite.so.*


signature.asc
Description: PGP signature

Bug#966087: libreoffice-writer: Cannot save file: General input/output error

[Rene Engelhard]

Hi,

so it might definitely be 32bit only. As I feared. Unfortunately
LibreOffice upstream does not support 32bit anymore, so anything bad can
sneak in there.

Am 14.08.20 um 10:56 schrieb frydo bugdeb:
> I have the same exact error.
> I am using a 32bit computer too.
>
> I have no problem with my 64bit computer with the same configuration.
>
I seriously believe your "32bit computer" is a 64bit-able computer where
one didn't install/maintain it properly by (re)installing it with  a 64
bit *operating system*.

> You don't even need to write anything in the document.
> Only save file, and the error occurs, with those lu9017o81.tmp empty
> files created in the repertory you want to save the file in.

And I already said in a i386 VM it just works for me. I actually tested
on 32 bits.

> libreoffice calc saves files, but I have a file for which I got a
> message that some attributes could not be read (but I don't know how
> to find which ones).

Any specialities? File System? If you know that you have a file there
you can probably give more information?

> This error does not appear on my 64bit computer.

Another reason to use something sensible.


Regards,


Rene

Bug#949003: Doesn't work on 64 bit architectures

[Stéphane Glondu]

For me, slirp:amd64 does not crash, but does not work either (with User
Mode Linux). Installing slirp:i386 on an amd64 system works.


Cheers,

-- 
Stéphane

Bug#964181: linux-image-4.19.0-9-amd64: Unable to get battery status

[Bernhard Übelacker]

Dear Maintainer,
this bug sounds similar to this one:
https://bugs.debian.org/927163

Kind regards,
Bernhard

Bug#968394: gnome-shell: No UI option to switch between users even when there are multiple non-system user accounts

[Simon McVittie]

Control: reassign -1 libaccountsservice 0.6.55-1
Control: affects -1 + gnome-shell
Control: severity -1 serious
Control: tags -1 + pending

On Fri, 14 Aug 2020 at 13:10:18 +0100, Simon McVittie wrote:
> At least part of the problem (possibly the whole problem, I'm not sure
> yet) is that accountsservice since version 0.6.55 was accidentally
> compiled without systemd-logind support, so it can't tell us that the
> system can switch users, because it doesn't know.

This seems to be the root cause of the gnome-shell issue. Fixing
accountsservice gives me a nice "Switch User..." option just below "Log
Out", and an icon in the lower right corner of the lock screen with the
same effect.

This is a small part of gnome-shell's functionality, but a large part
of what accountsservice is meant to do, so I'm considering this to be
release-critical for accountsservice.

Thanks for the reminder to look into this,
smcv

Bug#964908: tomcat9/9.0./37-3 in buster backports

[Adrian Heath]

Do you know when this fix will appear in the Buster backports repository?

Thank you in advance

Bug#966499: unicode-cldr-core: Please generate JSON data file also

[James Valleroy]

On Fri, 14 Aug 2020 06:59:05 -0400 James Valleroy  wrote:
> I found a git repository for converting the data to JSON [1], along with 
> instructions on how to use it [2]. However, the cldr-localenames package is 
> not available on npm, and I didn't figure out how to rebuild it yet.
> 
> But I found another repository [3], in which I can simply run "npm install", 
> and it downloads the XML data and converts it to JSON. The resulting data is 
> very close to what is shipped in php-getttext-languages, and should be fine 
> for my purposes.
> 
> [1] https://github.com/unicode-cldr/cldr-json
> [2] http://cldr.unicode.org/development/updating-codes/updating-json-data
> [3] https://github.com/rxaviers/cldr-data-npm

My bad, [3] is not converting the data. It is downloading the data already in 
JSON format from multiple repositories under https://github.com/unicode-cldr. 
The list of URLs that it downloads is here:
https://github.com/rxaviers/cldr-data-npm/blob/master/urls.json



signature.asc
Description: OpenPGP digital signature

Bug#968397: dpkg: package bug script exits with 256 on reportbug

[The Wanderer]

Package: dpkg
Version: 1.20.5
Severity: normal

Dear Maintainer,

When I attempt to file a bug report against dpkg with reportbug, I get
the following output:


The package bug script /usr/share/bug/dpkg exited with an error status
(return code = 256). Do you still want to file a report? [y|N|q|?]?


It is not clear whether this reflects a problem that will manifest
itself in the resulting bug report, but at the minimum, it is clearly
suboptimal UX. If it does reflect a real problem, that problem should be
fixed; if it does not, it should be streamlined so that this notice does
not appear in routine bug-report attempts.

As things stand, I have another bug report which I would like to file
(which might belong either to dpkg or to locales-all, or even somewhere
else I can't identify at a glance, but I think fits dpkg as the most
likely candidate) which is on hold because of this.

I'm not sure where to look on my system for anything that might be
contributing to the problem; I've already checked the script itself, and
tried running various commands and scripts based on what I find there,
without reproducing the 256 exit code as of yet. If there's anything I
can do to help track this down, don't hesitate to ask.


-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.8-4
ii  libc62.31-3
ii  liblzma5 5.2.4-1+b1
ii  libselinux1  3.1-2
ii  tar  1.30+dfsg-7
ii  zlib1g   1:1.2.11.dfsg-2

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt2.1.10
pn  debsig-verify  

-- no debconf information

Bug#965057: guile OOM test failures on ppc64el

[Matthias Klose]

On 8/14/20 11:33 AM, Matthias Klose wrote:
> I'm now NMUing both guile-2.2 and guile-3.0 to just ignore the test results on
> ppc64el, without closing the bug reports.  It's blocking the gcc-10 migration 
> to
> testing.

now, the NMUs fail with the same OOM error on armhf (3.0) and armhf/i386 (2.2)
as well... Maybe just don't run the OOM tests, instead of ignoring the test 
results?

Bug#968295: Resolution

[Andrew]

Downloaded Debian LiveCD image (debian-10.5.0-amd64-xfce-CD-1.iso from 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/)


Boot to Debian LiveCD -> (Advanced Mode) -> Graphical Rescue Mode

Skip network setup (I did not have drivers for my hardware, we'll be 
copying the files on USB stick needed to fix) -> proceed to mount 
partitions providing the LVM Passphrase for Full Disk Encryption.


Select the "acerv3-575t-vg/root" to mount a shell too, ensure to select 
"yes" to mount the "/boot" partition.


Successfully logged into my root file system /dev/acerv3-575t-vg/root 
via live CD in rescue mode & mounted the seperate /boot partition, am 
sitting on a shell with /dev/acerv3-575t-vg/root mounted on "/"




#checking packages

dpkg -l cryptsetup lvm2

#result:
#dpkg-query: error: failed to open package info file 
'/var/lib/dpkg/status' for reading: no such file or directory


#(my /var /tmp /home are seperate LV of the VG acerv3-575t-vg)

#had to issue "mount -a" to mount the other LV's (/var /tmp /home).


#now doing
dpkg -l cryptsetup lvm2
#returns results:
# rc cryptsetup 2:2.1.0-5+deb10u2 all
# ii lvm2 2.03.02-3 amd64

#(ii indicator for lvm2 indicates its  rc indicator for cryptsetup 
indicates !
#must seek to reinstall cyptsetup, but also cryptsetup-initramfs (both 
packages) since issue is on boot as well! with intrafamfs prompt at boot 
time.


#ok; so you're pulling the metapackage that pulls cryptsetup-initramfs
#the latter is what you need for initramfs support; if you missed it, no 
chances of booting!
#(the separation across packages is $debian_version-dependent, hence my 
suggesting install cryptsetup, which pulls what is required)


#get full URL to download package files from official source

apt-get download --print-uris cryptsetup
apt-get download --print-uris cryptsetup-initramfs

#above retrives (server, path, filename, including the relevant version 
and architecture, among other things)


apt-get -f install

#returns results:  0 upgraded, 0 newly installed, 0 to remove and 46 not 
upgraded


#Ready to move on to reinstall cryptsetup & cryptsetup-initramfs (both 
are necessary)
#copied the *.deb files to usb stick formatted as FAT, plugged it in 
then did "lsblk" to view its assignment (/dev/sdb1) and mounted "mount 
/dev/sdb1 /media/usb"


cd /media/usb
dpkg -i cryptsetup-initramfs_2.1.0-5+deb10u2_all.deb 
cryptsetup_2.1.0-5+deb10u2_all.deb

#results,
#dpkg: warning: 'start-stop-daemon' not found in PATH or not executable
#dpkg: error: 1 expected program not found in PATH or not executable

#echo $PATH    =    /sbin:/usr/sbin:/bin:/usr/bin
#checking dpkg
dpkg -V dpkg
#returns errors could not find 'start-stop-daemon'

#(issue) /sbin/ is missing file 'start-stop-daemon' obtained it with 
some online help and copied it with 755 permission, rebooted live CD



#After reboot, retried install cryptsetup and cryptsetup-initramfs

#after copying start-stop-daemon, and fixing its permission and reboot 
liveCD

dpkg -V dpkg
#returns to prompt, no error this time.

#re-attempt install again
dpkg -i cryptsetup-initramfs_2.1.0-5+deb10u2_all.deb 
cryptsetup_2.1.0-5+deb10u2_all.deb


#this time executed without failures (generating /boot/initrd.img-* ... )

#next
lsinitramfs /boot/initrd.img-4.19.0-9-amd64|grep cryptsetup

#returns valid result:
# /usr/lib/cryptsetup   /usr/lib/cryptsetup/askpass   /functions 
/usr/lib/x86_64-linux-gnu/libcryptsetup.so.12 *.so.12.4.0 and 
usr/sbin/cryptsetup


then ran 'update-initramfs -u -k a' then 'update-grub'

Rebooted after all this and all was well, the prompt for passphrase 
returned and was able to login, was told would not be a bad idea to 
install and run debsums so I took that advice and found some other items 
which FAILED which will pursue necessary fixing now...


MAJOR credit goes to the team at https://debamax.com/ as their 
assistance has provided me the knowledge and details required for above 
fixes and to find out that /sbin/start-stop-daemon was missing and 
causing my inability to reinstall or query the installation packages to 
begin with to check their status. Appreciate their help & patience with 
me, I am forever grateful!


The issue is resolved!

Bug#962668: same error

[Michael Meier]

I've got exactly the same error (the one with the surrogates not 
allowed) with way too many PDFs. Already since months, always using the 
newest calibre version in testing.

Now I've just installed the official version as described in
https://calibre-ebook.com/download_linux
and that version does the conversion without any problems. So the 
problem must be in the debian package.

Bug#966215: mystiq: Please also enable build on other architectures

[Boyuan Yang]

X-Debbugs-CC: pmdc...@gmail.com

On Tue, 28 Jul 2020 14:28:05 -0300 Pablo Mestre 
wrote:
> Hi,
> 
> I will check this and update the package.
> 
> Thanks for the notice.

Hi Pablo,

Is there any progress on it? I believe the fix would be just a one-
liner change by replacing "amd64" with "any".

Let me know if you need help applying this change. I can also provide a
non-maintainer upload if you find it okay.

-- 
Regards,
Boyuan Yang


> El 7/24/20 a las 4:15 PM, Boyuan Yang escribió:
> > Source: mystiq
> > Version: 20.03.23-1
> > Severity: minor
> >
> > Dear Debian mystiq maintainer,
> >
> > Thanks for maintaining package mystiq in Debian. I noticed that
this software
> > was instructed to only build on amd64 architecture. Ideally this
package
> > should be built on any architecture currently supported by Debian,
not only
> > limited to amd64. Is there any specific need in the package that
can only be
> > achieved on amd64?
> >
> > If the software can function well on other hardware architectures,
please
> > consider enabling build for them. This can be done by using
"Architecture:
> > any" instead of "Architecture: amd64" in debian/control file.
> >
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
>   ⣾⠁⢠⠒⠀⣿⡁  --
>   ⢿⡄⠘⠷⠚⠋   https://debian.org
>   ⠈⠳⣄  Debian, the universal operating system.
> 
> 


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

Bug#968398: ITP: stegcracker -- steganography brute-force tool

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, francisco.ruvi...@riseup.net

* Package name: stegcracker
  Version : 2.0.9
  Upstream Author : Luke Paris (Paradoxis) 
* URL : https://github.com/Paradoxis/StegCracker
* License : Expat
  Programming Lang: Python
  Description : steganography brute-force tool

StegCracker is steganography brute-force utility to uncover hidden data inside
files.

Bug#968399: pyxdg ftbfs, test failure

[Matthias Klose]

Package: src:pyxdg
Version: 0.26-3
Severity: serious
Tags: sid bullseye

seen in unstable, in the build, and in the autopkg tests:

[...]
==
ERROR: test_rule_from_node (test-menu-rules.RulesTest)
--
Traceback (most recent call last):
  File
"/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build/test/test-menu-rules.py",
line 166, in test_rule_from_node
rule = parser.parse_rule(root)
  File "/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build/xdg/Menu.py",
line 768, in parse_rule
return Rule(type, tree)
  File "/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build/xdg/Menu.py",
line 421, in __init__
self.code = compile(self.expression, '', 'eval')
ValueError: Name node can't be used with 'False' constant

--
Ran 55 tests in 2.178s

FAILED (errors=1)
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
/packages/tmp/pyxdg-0.26/.pybuild/cpython3_3.8_xdg/build; python3.8 -m nose -v 
test
dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8
returned exit code 13
make: *** [debian/rules:7: build] Error 25

Bug#934395:

[sylvia]

Beste, ik schreef je voordat het me verbaast dat je niet reageerde, schrijf
me nu alstublieft terug

Bug#968400: cockpit-ws: Warning on upgrades

[Cesare Leonardi]

Package: cockpit-ws
Version: 225-1
Severity: normal

Hello.
For several cockpit releases, on every package upgrade there are two
repeated messages:
--
Setting up cockpit-ws (225-1) ...
Warning: The home dir /nonexisting you specified can't be accessed: No such 
file or directory
The system user `cockpit-ws' already exists. Exiting.
Warning: The home dir /nonexisting you specified can't be accessed: No such 
file or directory
The system user `cockpit-wsinstance' already exists. Exiting.
--

Leaving behind the cockpit-ws user already exists message (I guess it
could be silenced with a test), the /nonexisting warning is what caught
my attention. Not because it doesn't exists but because Debian seems to
use a similar but different path for the same purpose. For example on
my system I see that:
--
# cat /etc/passwd | grep nonexist
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:118:65534::/nonexistent:/bin/false
debian-h2o:x:119:135::/nonexistent:/usr/sbin/nologin
tcpdump:x:121:140::/nonexistent:/usr/sbin/nologin
libvirtdbus:x:999:999::/nonexistent:/usr/sbin/nologin
cockpit-ws:x:117:131::/nonexisting:/usr/sbin/nologin
cockpit-wsinstance:x:125:142::/nonexisting:/usr/sbin/nologin
--

Look, here cockpit is the only one using /nonexisting as home path.
I don't know if there are any Debian policies talking about this path
and its usage but from what I see, cockpit seems to deviate from the
rest of the system.

Cesare.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cockpit-ws depends on:
ii  adduser 3.118
ii  glib-networking 2.64.3-2
ii  libc6   2.31-3
ii  libcrypt1   1:4.4.16-1
ii  libglib2.0-02.64.4-1
ii  libgnutls30 3.6.14-2+b1
ii  libgssapi-krb5-21.17-10
ii  libjson-glib-1.0-0  1.4.4-2
ii  libkrb5-3   1.17-10
ii  libpam0g1.3.1-5
ii  libsystemd0 246-2
ii  openssl 1.1.1g-1
ii  systemd 246-2

cockpit-ws recommends no packages.

Versions of packages cockpit-ws suggests:
pn  sssd-dbus  

-- no debconf information

Bug#968219: ITP: openpbs -- An HPC workload manager and job scheduler for desktops, clusters, and clouds.

[Wouter Verhelst]

On Tue, Aug 11, 2020 at 03:28:30AM +, Mo Zhou wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mo Zhou 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: openpbs
>   Version : 20.0.1
>   Upstream Author : Name 
> * URL : http://www.example.org/
> * License : AGPL-3
>   Programming Lang: C, python, shell
>   Description : An HPC workload manager and job scheduler for desktops, 
> clusters, and clouds.
> 
> I'm wondering why it is absent in debian.

My guess: slurm and gridengine exist in Debian and are "good enough",
whereas PBS has been going through some upstream switches/forks a few
times over the past few years?

Could be my misunderstanding though.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#709820: [dictd] Lacks IPv6 support

[Kevin Otte]

New upstream release now has support for IPv6.

https://sourceforge.net/projects/dict/files/dictd/dictd-1.13.0/

  dictd:
 * add support for IPv6 (the default is IPv4)
- Add global configuration option "address_family" and
   command line options --address-family
- Options "listen_to" and --listen-to accepts host name
   in addition to IP address, "*" means "bind to all interfaces".

  dict:
 * add support for IPv6.
- New command line options -4 and -6.
- dict + dict:// URL: add support for IPv6 address
   surrounded by [ and ] symbols

Bug#968375: scottfree: Crashes when restoring save file

[Bernhard Übelacker]

Dear Maintainer,
this fault is caused by a wrong format in a call to fscanf.

Attached a patch to fix this and remove two other warnings.

Kind regards,
Bernhard

# Bullseye/testing amd64 qemu VM 2020-08-14


apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox xterm unzip mc fakeroot 
quilt gdb rr scottfree scottfree-dbgsym
apt build-dep scottfree

echo 1 > /proc/sys/kernel/perf_event_paranoid



mkdir /home/benutzer/source/scottfree/orig -p
cd/home/benutzer/source/scottfree/orig
apt source scottfree
cd


wget 
http://www.ifarchive.org/if-archive/scott-adams/games/scottfree/AdamsGames.zip
unzip AdamsGames.zip -d AdamsGames
cd AdamsGames/



##


export DISPLAY=:0
scottfree adv01.dat


Tell me what to do ? SAVE GAME
OK
Filename: test.sav

Saved.

Tell me what to do ? QUIT
I've stored 0  treasures.  On a scale of 0 to 100, that rates 0 .
The game is now over.



##


$ scottfree adv01.dat test.sav
*** stack smashing detected ***:  terminated
 Abgebrochen (Speicherabzug 
geschrieben)




$ gdb -q --args scottfree adv01.dat test.sav
Reading symbols from scottfree...Reading symbols from 
/usr/lib/debug/.build-id/41/565267f3552c9b645ec125e201ac393874a90f.debug...done.
done.
(gdb) directory /home/benutzer/source/scottfree/orig/scottfree-1.14
Source directories searched: 
/home/benutzer/source/scottfree/orig/scottfree-1.14:$cdir:$cwd
(gdb) run
Starting program: /usr/games/scottfree adv01.dat test.sav
*** stack smashing detected ***:  terminated

 Program received signal 
SIGABRT, Aborted.

  __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
gefunden.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77dcd535 in __GI_abort () at abort.c:79
#2  0x77e24508 in __libc_message (action=, 
fmt=fmt@entry=0x77f2f07b "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:181
#3  0x77eb580d in __GI___fortify_fail_abort 
(need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x77f2f059 "stack 
smashing detected") at fortify_fail.c:28
#4  0x77eb57c2 in __stack_chk_fail () at stack_chk_fail.c:29
#5  0x73e3 in LoadGame (name=) at ScottCurses.c:708
#6  0x5812 in main (argc=3, argv=0x7fffe578) at 
ScottCurses.c:1393
(gdb) up
#1  0x77dcd535 in __GI_abort () at abort.c:79
79  abort.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#2  0x77e24508 in __libc_message (action=, 
fmt=fmt@entry=0x77f2f07b "*** %s ***: %s terminated\n") at 
../sysdeps/posix/libc_fatal.c:181
181 ../sysdeps/posix/libc_fatal.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#3  0x77eb580d in __GI___fortify_fail_abort 
(need_backtrace=need_backtrace@entry=false, msg=msg@entry=0x77f2f059 "stack 
smashing detected") at fortify_fail.c:28
28  fortify_fail.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#4  0x77eb57c2 in __stack_chk_fail () at stack_chk_fail.c:29
29  stack_chk_fail.c: Datei oder Verzeichnis nicht gefunden.
(gdb) 
#5  0x73e3 in LoadGame (name=) at ScottCurses.c:708
warning: Source file is more recent than executable.
708 }




##


$ rr scottfree adv01.dat test.sav
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/scottfree-0'.
*** stack smashing detected ***:  terminated
 Abgebrochen



$ rr replay /home/benutzer/.local/share/rr/scottfree-0
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/games/scottfree...Reading symbols from 
/usr/lib/debug/.build-id/41/565267f3552c9b645ec125e201ac393874a90f.debug...done.
done.
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Remote debugging using 127.0.0.1:4913
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from 
/usr/lib/debug/.build-id/f2/5dfd7b95be4ba386fd71080accae8c0732b711.debug...done.
done.
0x7f5521117090 in _start () from /li

Bug#948287: bash: *** stack smashing detected *** ( SIGABRT crash )

[Bernhard Übelacker]

Dear Maintainer,

encountered again such a crash of a bash that was started
while the old libc6 was installed, then installed a libc6 update,
and then the "old" bash crashed after a tab completion.

libc6:amd64 (2.30-8, 2.31-3)
bash:amd64 (5.0-6, 5.0-7)

Kind regards,
Bernhard


$ cp log*** stack smashing detected ***:  terminated
Connection to ... closed.

# coredumpctl gdb
   PID: 4738 (bash)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Fri 2020-08-14 17:50:14 CEST (37s ago)
  Command Line: -bash
Executable: /usr/bin/bash

Stack trace of thread 4738:
#0  0x7f4c0d38e781 n/a 
(/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x3b781)
#1  0x7f4c0d45fd7d n/a 
(/usr/lib/x86_64-linux-gnu/libc-2.30.so (deleted) + 0x10cd7d)

Bug#968401: partman-efi version 85: fstab/efi is missing the executable flag

[Pete Batard]

Package: partman-efi
Severity: important
Tags: d-i

Logging a bug against this, since it's a rather important issue.

https://salsa.debian.org/installer-team/partman-efi/-/commit/1a096e6ede94cce8e5272e31946a506ae7f611e7.patch 
had the rather unfortunate side effect of removing the +x attribute from 
fstab/efi.


Combined with finish.d/20mount_partitions using a loop that checks for 
the executable flag before running the scripts from fstab.d:


for i in /lib/partman/fstab.d/*; do
[ -x "$i" ] || continue
$i
done |

this effectively means that fstab/efi is no longer executed.

A patch has been submitted in:
https://salsa.debian.org/installer-team/partman-efi/-/merge_requests/2

Regards,

/Pete

Bug#968226: Build-Depends-If-Available

[Wouter Verhelst]

On Tue, Aug 11, 2020 at 10:05:42AM -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> 
> > -policy: this is a question that has come up before
> > (https://lists.debian.org/debian-devel/2016/12/msg00470.html is another
> > example that springs to mind, but I'm pretty sure there are more), so I
> > think we should document in Policy that a) buildd only looks at the
> > first dependency in alternative build-dependencies, and b) why this is
> > the case.
> 
> Policy already says:
> 
> While Build-Depends, Build-Depends-Indep and Build-Depends-Arch permit
> the use of alternative dependencies, these are not normally used by
> the Debian autobuilders. To avoid inconsistency between repeated
> builds of a package, the autobuilders will default to selecting the
> first alternative, after reducing any architecture-specific
> restrictions for the build architecture in question. While this may
> limit the usefulness of alternatives in a single release, they can
> still be used to provide flexibility in building the same package
> across multiple distributions or releases, where a particular
> dependency is met by differently named packages.
> 
> in 7.1.  However, it's hidden in a footnote.  Perhaps we should make it
> more prominant (and make it clear that it's normative), and tweak the
> wording.

Thanks, yeah, I missed that. I'll have a stab at a patch some time soon
(probably after debconf though)

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Bug#968396: wireguard-dkms: kernel module fails to build

[Thomas K.]

Package: wireguard-dkms
Version: 0.0.20200128-1
Severity: normal

root@rpi4:~# dpkg-reconfigure wireguard-dkms
--
Deleting module version: 0.0.20200128
completely from the DKMS tree.
--
Done.
Loading new wireguard-0.0.20200128 DKMS files...
It is likely that 5.4.51-v7l+ belongs to a chroot's host
Building for 5.4.51+, 5.4.51-v7+, 5.4.51-v7l+ and 5.4.51-v8+
Building initial module for 5.4.51+
Error! Bad return status for module build on kernel: 5.4.51+ (armv7l)
Consult /var/lib/dkms/wireguard/0.0.20200128/build/make.log for more
information.

root@rpi4:~# cat /var/lib/dkms/wireguard/0.0.20200128/build/make.log
DKMS make.log for wireguard-0.0.20200128 for kernel 5.4.51+ (armv7l)
Fri 14 Aug 2020 03:02:58 PM EEST
make: Entering directory '/usr/src/linux-headers-5.4.51+'
  AR  /var/lib/dkms/wireguard/0.0.20200128/build/built-in.a
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/main.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/device.o
  CC [M]  /var/lib/dkms/wireguard/0.0.20200128/build/peer.o
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/noise.c:10:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/device.c:6:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/peer.c:8:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
In file included from /var/lib/dkms/wireguard/0.0.20200128/build/main.c:9:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h: In function
‘wg_reset_packet’:
/var/lib/dkms/wireguard/0.0.20200128/build/queueing.h:100:2: error:
implicit declaration of function ‘skb_reset_tc’; did you mean
‘skb_reserve’? [-Werror=implicit-function-declaration]
  skb_reset_tc(skb);
  ^~~~
  skb_reserve
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/main.o] Error 1
make[1]: *** Waiting for unfinished jobs
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/peer.o] Error 1
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/device.o] Error 1
cc1: some warnings being treated as errors
make[1]: *** [scripts/Makefile.build:266:
/var/lib/dkms/wireguard/0.0.20200128/build/noise.o] Error 1
make: *** [Makefile:1709: /var/lib/dkms/wireguard/0.0.20200128/build]
Error 2
make: Leaving directory '/usr/src/linux-headers-5.4.51+'

root@rpi4:~# uname -a
Linux rpi4 5.4.51-v7l+ #1333 SMP Mon Aug 10 16:51:40 BST 2020 armv7l
GNU/Linux
root@rpi4:~# apt show libc6 | grep ^Version
Version: 2.28-10+rpi1

TBH, I'm not sure if it's right that I've submitted the bug here. Since
it's a "Raspbian" system.

-- 
Thomas K.
https://pebkac.gr

Bug#962972: firmware-realtek: missing files in 20200619-1

[Michał Mirosław]

Package: firmware-realtek
Version: 20200619-1

In newer source tar there are firmware files for more chips than what is
packed into deb. Eg rtl8153a-3.fw is missing.

$ dpkg -l firmware-realtek
[...]
ii  firmware-realtek 20200619-1   all  Binary firmware for Realtek 
wired/wifi/BT adapters

$ tar tJf firmware-nonfree_20200619.orig.tar.xz|grep rtl_nic/rtl|wc -l
28

$ ls /lib/firmware/rtl_nic/|wc -l
24

Best Regards
Michał Mirosław

Bug#966217: mystiq: Consider having package team-maintained in Debian Multimedia Team

[Pablo Mestre]

Hi Boyuan,

Sorry fo the late on the reply. I upate the repoitory and solve the bug.

Now im waiting for a DD upload the binary.

Regards,

Pablo

El 7/24/20 a las 4:21 PM, Boyuan Yang escribió:
> Source: mystiq
> Version: 20.03.23-1
> Severity: wishlist
>
> Dear Debian mystiq package maintainer,
>
> I believe mystiq is worthwhile to be team-maintained under Debian Multimedia
> Team (https://wiki.debian.org/DebianMultimedia). You may further read this
> Debian Wiki page on how the Multimedia Team works.
>
> If you are willing to have this package team-maintained in the multimedia-
> team, you are welcome to put "Debian Multimedia Maintainers <
> debian-multime...@lists.debian.org>" into the maintainer field or the
> uploaders field in your package. There is no need to further move the git
> packaging repo on Salsa GitLab since the current git repo can be made to be
> grant write permission to the multimedia-team members if necessary.
>
> Thanks,
> Boyuan Yang

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.




signature.asc
Description: OpenPGP digital signature

Bug#966087: libreoffice-writer: Cannot save file: General input/output error

[frydo bugdeb]

I seriously believe your "32bit computer" is a 64bit-able computer where
one didn't install/maintain it properly by (re)installing it with  a 64
bit *operating system*.

Definitely not.


> libreoffice calc saves files, but I have a file for which I got a
> message that some attributes could not be read (but I don't know how
> to find which ones).

Any specialities? File System? If you know that you have a file there
you can probably give more information?

I forgot to add that this error appears while loading file.

I have no idea if I can join a file with my message, but I try here to join one.
It is not minimal, but it's very small.


> This error does not appear on my 64bit computer.

Another reason to use something sensible.

Things begin to be hard for 32bit computers...


file.ods
Description: application/vnd.oasis.opendocument.spreadsheet

Bug#966215: mystiq: Please also enable build on other architectures

[Pablo Mestre]

Hi Boyuan,

Sorry fo the late on the reply. I upate the repoitory and solve the bug.

Now im waiting for a DD upload the binary.

Regards,

Pablo

El 8/14/20 a las 11:31 AM, Boyuan Yang escribió:
> X-Debbugs-CC: pmdc...@gmail.com
>
> On Tue, 28 Jul 2020 14:28:05 -0300 Pablo Mestre 
> wrote:
>> Hi,
>>
>> I will check this and update the package.
>>
>> Thanks for the notice.
> Hi Pablo,
>
> Is there any progress on it? I believe the fix would be just a one-
> liner change by replacing "amd64" with "any".
>
> Let me know if you need help applying this change. I can also provide a
> non-maintainer upload if you find it okay.
>
-- 
  ⢀⣴⠾⠻⢶⣦⠀  Pablo Mestre Drake
  ⣾⠁⢠⠒⠀⣿⡁  --
  ⢿⡄⠘⠷⠚⠋   https://debian.org
  ⠈⠳⣄  Debian, the universal operating system.




signature.asc
Description: OpenPGP digital signature

Bug#966020: Fixed in 3.9.0

[Daniel Leidert]

This has been fixed upstream by version 3.9.0
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966020

Uploading this will also fix #961194.

Regards, Daniel
-- 
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

If you like my work consider sponsoring me via
https://www.patreon.com/join/dleidert


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

Bug#968371: Info received (Bug#968371: Acknowledgement (mailman3: NNTP Gateway'ing fails and causes message to not go out via email either))

[Athanasius]

  It was only 3 commits necessary to fix this, but one of them needs
further adjustment.

  The upstream commits in question are:


59d8b47c432e43ce463cbb4a7aec649415d08702
e4d9e5202158f9b32bb985167d7dedd9e9edc263
05d608645cfa47f7150585663e9f2d6aa5688db2

But e4d9e5202158f9b32bb985167d7dedd9e9edc263 then runs into an extra
problem where the Debian INN2 doesn't like header wrapping when a post
is being made in READER mode.  This might itself be an INN2 bug.
RFC 3977 section A.1 does say that header wrapping should work over
NNTP, but perhaps READER mode counts as nn*r*p instead and follows
different rules?

So I've instead ended up using a tweaked patch that forces the
max_line_length to 'None' for no wrapping.

I've attached the three extra patch files that I'm now using.

-- 
- Athanasius = Athanasius(at)miggy.org / https://miggy.org/
  GPG/PGP Key: https://miggy.org/gpg-key
   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
commit 59d8b47c432e43ce463cbb4a7aec649415d08702
Author: Mark Sapiro 
Date:   Sun Jun 23 01:52:23 2019 +

Removed the last remnants of the mailing list attribute nntp_host.

diff --git a/src/mailman/core/tests/test_pipelines.py b/src/mailman/core/tests/test_pipelines.py
index 7c87c4877..7ce778134 100644
--- a/src/mailman/core/tests/test_pipelines.py
+++ b/src/mailman/core/tests/test_pipelines.py
@@ -180,7 +180,6 @@ testing
 # Set up NNTP.
 self._mlist.gateway_to_news = True
 self._mlist.linked_newsgroup = 'testing'
-self._mlist.nntp_host = 'news.example.com'
 # Process the email.
 process(self._mlist, self._msg, {},
 pipeline_name='default-posting-pipeline')
diff --git a/src/mailman/docs/NEWS.rst b/src/mailman/docs/NEWS.rst
index ba8d7cdf9..bace916c7 100644
--- a/src/mailman/docs/NEWS.rst
+++ b/src/mailman/docs/NEWS.rst
@@ -18,6 +18,12 @@
 =
 (2019-02-22)
 
+Debian Cherry-Pick
+--
+
+* The last remnants of the mailing list attribute ``nntp_host`` have been
+  removed.  (Closes #611)
+
 Command line
 
 * The ``mailman import21`` command properly converts all acceptable_aliases
diff --git a/src/mailman/handlers/docs/nntp.rst b/src/mailman/handlers/docs/nntp.rst
index 72bcb35f0..233bbd255 100644
--- a/src/mailman/handlers/docs/nntp.rst
+++ b/src/mailman/handlers/docs/nntp.rst
@@ -44,12 +44,11 @@ Neither are digests ever gated to the newsgroup.
 []
 
 However, other posted messages get gated to the newsgroup via the nntp queue.
-The list owner can set the linked newsgroup and the nntp host that its
-messages are gated to.
+The list owner can set the linked newsgroup.  The nntp host that messages are
+gated to is a global configuration.
 ::
 
 >>> mlist.linked_newsgroup = 'comp.lang.thing'
->>> mlist.nntp_host = 'news.example.com'
 >>> handler.process(mlist, msg, {})
 >>> messages = get_queue_messages('nntp')
 >>> len(messages)
diff --git a/src/mailman/handlers/to_usenet.py b/src/mailman/handlers/to_usenet.py
index 4e66b8e99..3dbf91bf1 100644
--- a/src/mailman/handlers/to_usenet.py
+++ b/src/mailman/handlers/to_usenet.py
@@ -50,8 +50,6 @@ class ToUsenet:
 error = []
 if not mlist.linked_newsgroup:
 error.append('no newsgroup')
-if not mlist.nntp_host:
-error.append('no NNTP host')
 if error:
 log.error('NNTP gateway improperly configured: %s',
   COMMASPACE.join(error))
diff --git a/src/mailman/styles/base.py b/src/mailman/styles/base.py
index 92168ed97..e95423484 100644
--- a/src/mailman/styles/base.py
+++ b/src/mailman/styles/base.py
@@ -92,7 +92,6 @@ class BasicOperation:
 mlist.dmarc_moderation_notice = ''
 mlist.dmarc_wrapped_message_text = ''
 # NNTP gateway
-mlist.nntp_host = ''
 mlist.linked_newsgroup = ''
 mlist.gateway_to_news = False
 mlist.gateway_to_mail = False
commit e4d9e5202158f9b32bb985167d7dedd9e9edc263
Author: Mark Sapiro 
Date:   Thu Jun 27 15:52:58 2019 +

Fixed nntp runner to use BytesIO rather than StringIO.

diff --git a/src/mailman/docs/NEWS.rst b/src/mailman/docs/NEWS.rst
index 33920ec8d..2f6f041a4 100644
--- a/src/mailman/docs/NEWS.rst
+++ b/src/mailman/docs/NEWS.rst
@@ -23,6 +23,8 @@
 
 * The last remnants of the mailing list attribute ``nntp_host`` have been
   removed.  (Closes #611)
+* Fixed the nntp runner which was calling the ``nntplib.NNTP.post()`` method
+  with a string object instead of bytes.  (Closes #613)
 
 Command line
 
diff --git a/src/mailman/runners/nntp.py b/src/mailman/runners/nntp.py
index 36ef2e3a1..580d22ff9 100644
--- a/src/mailman/runners/nntp.py
+++ b/src/mailman/runners/nntp.py
@@ -23,7 +23,7 @@ import socket
 import logging
 import nntplib
 
-from io import StringIO
+from io import BytesIO
 from mailman.config import config
 from mailman.core

Bug#968327: systemtap: FTBFS: uses %lu to print rlim_t which can be unsigned long long though

[Frank Ch. Eigler]

Hi -

> +  * debian/patches/rlim_t.patch: fix FTBFS: bad rlim_t assumptions
> +
> + -- Thorsten Glaser   Thu, 13 Aug 2020 04:03:51 +0200

We merged an embiggened version of your patch to upstream master, thanks!

- FChE

Bug#968372: sylpheed: crash on startup

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce it inside a i386 VM and found the crash
happens in [1], when it tries to dereference the "state".

This state is retrieved from the renderer of type _PangoRendererPrivate.


I tried to follow where this state is last set and found
this memory is last written in location [2].

But here this memory is used as _GdkPangoRendererPrivate,
which looks quite different.


Kind regards,
Bernhard



[1]
(rr) bt
#0  0xb7391ebf in handle_line_state_change 
(part=PANGO_RENDER_PART_OVERLINE, renderer=0x10470c0) at 
../pango/pango-renderer.c:315
#1  pango_renderer_part_changed (renderer=0x10470c0, 
part=PANGO_RENDER_PART_OVERLINE) at ../pango/pango-renderer.c:1414
#2  0xb7392194 in pango_renderer_set_alpha (renderer=0x10470c0, 
part=PANGO_RENDER_PART_OVERLINE, alpha=0) at ../pango/pango-renderer.c:1357
#3  0xb7392335 in pango_renderer_default_prepare_run (renderer=0x10470c0, 
run=0xf55a98) at ../pango/pango-renderer.c:1525
#4  0xb756b7cd in gdk_pango_renderer_prepare_run (renderer=0x10470c0, 
run=0xf55a98) at ../../../../gdk/gdkpango.c:456
#5  0xb73925f9 in pango_renderer_prepare_run (run=0xf55a98, 
renderer=0x10470c0) at ../pango/pango-renderer.c:1435
#6  pango_renderer_draw_layout_line (renderer=0x10470c0, line=0xf50e08, 
x=34816, y=51200) at ../pango/pango-renderer.c:611
...

(rr) list
296 handle_line_state_change (PangoRenderer  *renderer,
297   PangoRenderPart part)
298 {
299   LineState *state = renderer->priv->line_state;
...
314
315   if (part == PANGO_RENDER_PART_OVERLINE &&
316   state->overline != PANGO_OVERLINE_NONE)
317 {


https://sources.debian.org/src/pango1.0/1.46.0-1/pango/pango-renderer.c/#L315


[2]
(rr) bt
#0  gdk_pango_renderer_prepare_run (renderer=0x10470c0, run=0xf55a98) at 
../../../../gdk/gdkpango.c:443
#1  0xb73925f9 in pango_renderer_prepare_run (run=0xf55a98, 
renderer=0x10470c0) at ../pango/pango-renderer.c:1435
#2  pango_renderer_draw_layout_line (renderer=0x10470c0, line=0xf50e08, 
x=34816, y=51200) at ../pango/pango-renderer.c:611
#3  0xb739301d in pango_renderer_draw_layout (renderer=0x10470c0, 
layout=0xf379f0, x=34816, y=37888) at ../pango/pango-renderer.c:197
...

(rr) list
441   if (embossed != gdk_renderer->priv->embossed)
442 {
443   gdk_renderer->priv->embossed = embossed;
444   changed = TRUE;
445 }

https://sources.debian.org/src/gtk+2.0/2.24.32-4/gdk/gdkpango.c/#L443

# Unstable i386 qemu VM 2020-08-14

apt update
apt dist-uprade


apt install systemd-coredump sddm xserver-xorg openbox xterm gdb git sylpheed 
sylpheed-dbgsym libgtk2.0-0-dbgsym libglib2.0-0-dbgsym libpango-1.0-0-dbgsym
apt build-dep rr


echo 1 > /proc/sys/kernel/perf_event_paranoid




mkdir /home/benutzer/source/libpango-1.0-0/orig -p
cd/home/benutzer/source/libpango-1.0-0/orig
apt source libpango-1.0-0
cd

mkdir /home/benutzer/source/libgtk2.0-0/orig -p
cd/home/benutzer/source/libgtk2.0-0/orig
apt source libgtk2.0-0
cd





$ export DISPLAY=:0
$ sylpheed 
Speicherzugriffsfehler (Speicherabzug geschrieben)


# dmesg
...
[   29.789450] sylpheed[992]: segfault at 2d ip b73e0ebf sp bf890760 error 4 in 
libpango-1.0.so.0.4600.0[b73bd000+29000]
[   29.789458] Code: c4 10 83 c4 1c 5b 5e 5f 5d c3 90 8b 4e 18 85 c9 7e 79 8b 
46 20 8b 78 44 85 ff 74 4f 83 fd 02 74 7a 83 fd 04 0f 85 b1 00 00 00 <8b> 47 2c 
89 44 24 08 85 c0 74 36 8b 4f 40 8b 57 30 c7 47 2c 00 00


# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Fri 2020-08-14 18:33:29 CEST992  1000  1000  11 present   /usr/bin/sylpheed

# coredumpctl gdb 992
   PID: 992 (sylpheed)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Fri 2020-08-14 18:33:29 CEST (2min 10s ago)
  Command Line: sylpheed
Executable: /usr/bin/sylpheed
 Control Group: /user.slice/user-1000.slice/session-6.scope
  Unit: session-6.scope
 Slice: user-1000.slice
   Session: 6
 Owner UID: 1000 (benutzer)
   Boot ID: 4c238d8aaaba40d19b8c886c81502ce0
Machine ID: 45f49504b47f4e5690bc479adf67aa5b
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.sylpheed.1000.4c238d8aaaba40d19b8c886c81502ce0.992.1597422809.zst
   Message: Process 992 (sylpheed) of user 1000 dumped core.

Stack trace of thread 992:
#0  0xb73e0ebf pango_renderer_part_changed 
(libpango-1.0.so.0 + 0x2debf)
#1  0xb73e1194 pango_renderer_set_alpha 
(libpango-1.0.so.0 + 0x2e194)
#2  0xb73e1335 n/a (libpango-1.0.so.0 + 0x2e335)
#3  0xb75ba7cd n/a (libgdk-x11-2.0.so.0 + 0x247cd)
#4  0xb73e15f9 pango_renderer_draw_layout_line 
(libpango-1.0.so.0 + 0x2e5f9)

Bug#968403: numbers.test fails on i386

[Matthias Klose]

Package: src:guile-3.0
Version: 3.0.4-1
Severity: serious
Tags: sid bullseye

only seen on i386, not on other architectures.

[...]
Running numbers.test
FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: (130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: euclidean/: mixed types: (130.0
-10/7)
FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (130.0 10/7)
FAIL: numbers.test: Number-theoretic division: floor/: mixed types: (-130.0 
-10/7)
FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (130.0 
-10/7)
FAIL: numbers.test: Number-theoretic division: ceiling/: mixed types: (-130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (130.0 
-10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (-130.0 
10/7)
FAIL: numbers.test: Number-theoretic division: truncate/: mixed types: (-130.0
-10/7)

Bug#968382: element-desktop: /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied

[Hans-Christoph Steiner]

Adding this to element-desktop.profile made the Permission denied error
go away, but it still didn't start:

whitelist /var/lib/flatpak/exports/share/dconf/profile/user


So it seems the /dev/shm error is the notable one. I tried adding
"ignore nodbus" at the end of element-desktop.profile, at the beginning
of element-desktop.profile, and both. None of those changed the /dev/shm
error. And Element never started.

Bug#968397: dpkg: package bug script exits with 256 on reportbug

[Guillem Jover]

Control: found -1 1.20.1

Hi!

On Fri, 2020-08-14 at 10:00:23 -0400, The Wanderer wrote:
> Package: dpkg
> Version: 1.20.5
> Severity: normal

> When I attempt to file a bug report against dpkg with reportbug, I get
> the following output:
> 
> 
> The package bug script /usr/share/bug/dpkg exited with an error status
> (return code = 256). Do you still want to file a report? [y|N|q|?]?

Oh, so I guess this is due to you not having a tainted usr-merged system
and the readlink failing, due to some recent refactoring. I'll fix that.

> It is not clear whether this reflects a problem that will manifest
> itself in the resulting bug report, but at the minimum, it is clearly
> suboptimal UX. If it does reflect a real problem, that problem should be
> fixed; if it does not, it should be streamlined so that this notice does
> not appear in routine bug-report attempts.

This would be reportbug noticing that the bug script failed and
reporting that.

> As things stand, I have another bug report which I would like to file
> (which might belong either to dpkg or to locales-all, or even somewhere
> else I can't identify at a glance, but I think fits dpkg as the most
> likely candidate) which is on hold because of this.

I assume that until the problem has been fixed in the bug-script, just
replying 'y' would do.

> I'm not sure where to look on my system for anything that might be
> contributing to the problem; I've already checked the script itself, and
> tried running various commands and scripts based on what I find there,
> without reproducing the 256 exit code as of yet. If there's anything I
> can do to help track this down, don't hesitate to ask.

The 256 would usually come from the return code of something like a
system() call (originally from something like wait(2)), where the code
would need to mask the value to get the actual command's exit status.

Thanks,
Guillem

Bug#968382: element-desktop: /var/lib/flatpak/exports/share/dconf/profile/user: Permission denied

[Reiner Herrmann]

Control: forwarded -1 https://github.com/netblue30/firejail/issues/3586

On Fri, Aug 14, 2020 at 07:57:00PM +0200, Hans-Christoph Steiner wrote:
> Adding this to element-desktop.profile made the Permission denied error
> go away, but it still didn't start:
> 
> whitelist /var/lib/flatpak/exports/share/dconf/profile/user
> 
> 
> So it seems the /dev/shm error is the notable one. I tried adding
> "ignore nodbus" at the end of element-desktop.profile, at the beginning
> of element-desktop.profile, and both. None of those changed the /dev/shm
> error. And Element never started.

Hm, that is weird, as I also have the same error about /dev/shm, but for
me element is starting (at least it shows a tray icon, and I can open
the main window; though it stays white (probably for a different reason
as it behaves the same without firejail)).

I initially had the problem that the tray icon was not shown because of
nodbus, maybe due to some other reason your WM/DE does not show the tray
icon...

Otherwise I'm currently out of ideas where the problem could be.

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#911560: Testing Various delays

[Nicolas Dufresne]

As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.

- 2, 3, and 4 was good enough to succeed a DHCP handshake.

- 0 and 1 made the request to never be seen over the network.

An obvious next step would be to test again with large file transfer,
perhaps a kernel image. I will report back.

regards,
Nicolas

Bug#968404: liblxc1 is hardwired to systemd or cgroupv1

[Harald Dunkel]

Package: liblxc1
Version: 1:4.0.2-1

Apparently I have to install either systemd or cgroupfs-mount for
liblxc1. Since cgroupfs-mount doesn't support cgroupv2 (#959021, set
to wontfix), I am stuck. A line like

cgroup2 /sys/fs/cgroup  cgroup2 defaults

in /etc/fstab would do.

Do you think it would be possible to move "cgroupfs-mount | systemd"
to Recommends for liblxc1 (if it can't be dropped altogether)?


Regards
Harri

Bug#968237: ITP: auctex-12 -- AUCTeX version 12, LaTeX environment for Emacs

[Sudip Mukherjee]

Hi Itaï,

On Tue, Aug 11, 2020 at 1:54 PM Itaï BEN YAACOV  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Itaï BEN YAACOV 
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: auctex-12
>   Version : 12.2
>   Upstream Author : GNU Project
> * URL : https://www.gnu.org/software/auctex/
> * License : GPL v3
>   Description : AUCTeX version 12, LaTeX environment for Emacs
>
> Hello,
>
> This is not truly an ITP but a request for guidance.

ITP is truly not the right one for this. And this should be merged with #896844.

> auctex v11.91 already exists in Debian, and has not been updated since
> 2018 despite bug reports requesting that.  Specifically, the preview-latex
> feature no longer works due to changes in ghostscript, which is solved in
> upstream.

Looks like there are multiple users who are saying its unusable.

>
> The relevant bug #896844 was filed in Apr 2018, the maintainer said "I'll
> work on it" and nothing ever happened since, depite numerous follow-ups to
> the bug.  I tried to contact him directly in early 2020, getting no useful
> reply, except that he considers that he is still maintaining the package.
>
> I am not a Debian developper, but am able to package (in fact I have packaged
> auctex v12 for personal use).
>
> What should / can be done in this case ?

You have auctex/12.2-0.4 which doesn't make sense for Debian. So,
create a package for auctex/12.2-0.1, also add the fix for #951973 to
it. And then take a look at https://mentors.debian.net/ about how to
upload and find a sponsor.


-- 
Regards
Sudip

Bug#968327: systemtap: FTBFS: uses %lu to print rlim_t which can be unsigned long long though

[Thorsten Glaser]

Frank Ch. Eigler dixit:

>We merged an embiggened version of your patch to upstream master, thanks!

Thank you!

bye,
//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#968405: ITP: ruby-anima -- Initialize object attributes via attributes hash

[cocoa1231]

package: ruby-anima Severity: wishlist Owner: 'Cocoa'  
(mailto:cocoa1...@disroot.org) *Package Name : ruby-anima Version : 0.3.1-1 
Upstream Author : Markus Schirp mailto:m...@schirp-dso.com)> *URL : https://github.com/mbj/anima 
(https://github.com/mbj/anima) *License : MIT *Description : Simple library to 
declare read only attributes on value-objects that are initialized via 
attributes hash.

Bug#968406: ITP: ruby-anima -- Initialize object attributes via attributes hash

[Cocoa]

package: ruby-anima
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-anima
 Version   : 0.3.1-1
 Upstream Author   : Markus Schirp mailto:m...@schirp-dso.com>>
*URL   :https://github.com/mbj/anima  

*License   : MIT
*Description   : Simple library to declare read
 only attributes on value-objects that are initialized via 
attributes hash.

Bug#966215: mystiq: Please also enable build on other architectures

[Boyuan Yang]

Hi Pablo,

在 2020-08-14星期五的 13:35 -0300，Pablo Mestre写道：
> Hi Boyuan,
> 
> Sorry fo the late on the reply. I upate the repoitory and solve the
> bug.
> 
> Now im waiting for a DD upload the binary.

I just sponsored your package from the git packaging repository. Next
time if you are looking for a package sponsor other than me, please
consider opening a RFS bug as described at 
https://wiki.debian.org/DebianMentorsFaq since I may not always be
available for reviewing your package.

Also please let me know if you are willing to maintain package mystiq
in Debian's backports repository; you may find detailed information at 
https://backports.debian.org/ . If you prepare a proper packaging
branch in your packaging repo, I can help to sponsor this bpo upload so
that users of Debian 10 can make use of package mystiq as well.

Thanks,
Boyuan Yang


> El 8/14/20 a las 11:31 AM, Boyuan Yang escribió:
> > X-Debbugs-CC: pmdc...@gmail.com
> > 
> > On Tue, 28 Jul 2020 14:28:05 -0300 Pablo Mestre 
> > wrote:
> > > Hi,
> > > 
> > > I will check this and update the package.
> > > 
> > > Thanks for the notice.
> > Hi Pablo,
> > 
> > Is there any progress on it? I believe the fix would be just a one-
> > liner change by replacing "amd64" with "any".
> > 
> > Let me know if you need help applying this change. I can also
> > provide a
> > non-maintainer upload if you find it okay.
> > 

Bug#530604: checkrestart can use /run/reboot-required to check for a new kernel

[Kenyon Ralph]

This is even simpler to check for now. Kernel packages create
/run/reboot-required and add their package name to
/run/reboot-required.pkgs, so you can just check for those files. I
would welcome an enhancement to checkrestart that said something about
these files, so that you know from checkrestart's output when you're not
running the latest kernel that you have installed.



pEpkey.asc
Description: application/pgp-keys

Bug#968365: /usr/bin/freshclam: Ignores DatabaseCustomURL unless --update-db=custom is specified

[Sebastian Andrzej Siewior]

On 2020-08-13 17:21:04 [+0200], Stephan Jänecke wrote:
> starting with version 0.102.3 freshclam ignores DatebaseCustomURL
> options.

Are you sure about the versions? I've been looking at the changes
0.102.2..0.102.3 and there is nothing the freshclam area. That option
appears to be there. It might have happen earlier when they switched to
libcurl instead of doing their own http…

> As this option is used to specify custom paths to update databases on
> our local mirror, updates fail after upgrading from version 0.101.4.

okay. Then it is a 0.101 -> 0.102 kind of thing.

> Let me give you an example. Instead of downloading the database from
> `http://update.dfn-cert.de/av-sigs/clamav/db/main.cvd` freshclam will
> try `https://update.dfn-cert.de/main.cvd` and fail.
…
> Looking at the code I figured out that freshclam can be motivated to honour
> the values in DatabaseCustomURL options. Once I specified the executable
> parameter `--update-db=custom` freshclam happily updated the databases
> from the custom paths.
…
> Now I'm wondering: is my site incorrectly specifying custom database
> paths using `DatabaseCustomURL` and the breakage on update has been
> intentionally introduced by upstream? If so, what would be the correct
> way to introduce custom paths?

It sounds like you want to use PrivateMirror. But then you don't have
same path so it probably won't work. I don't know.

You have
DatabaseMirror = "update.dfn-cert.de"

set which means it will look for

   update.dfn-cert.de/main.cvd
   update.dfn-cert.de/daily.cvd

so it works as expected so far. You have also set DatabaseCustomURL so
it should look additionally for

   update.dfn-cert.de/av-sigs/clamav/db/main.cvd

Now the fact that it does not might have something to do with the part
that it fails while looking for update.dfn-cert.de/main.cvd. But from
looking at the code (in this heat) it should do so.

By using "--update-db=custom" then you limit the download to the custom
URL only which is what you specify with DatabaseCustomURL. This skips
the download of main/daily/bytecode.

> Or did I indeed find a bug?

Maybe something that was not planned. It might be possible that your
custom URL contained the 'main.cvd' file which then overwrote the
'main.cvd' from the official mirror. Now it does it no longer and would
in your case download the main.cvd twice.
If you could verify the part with PrivateMirror then I/you could open a
bug with upstream asking what the recommended way is to use a private
mirror with a different hierarchy. This is what you intend to do I
guess.

> Best regards,
> 
> Stephan Jänecke

Sebastian

Bug#968407: ITP: ruby-morpher -- Data transformation algebra with optional tracked evaluation.

[Cocoa]

package: ruby-morpher
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-morpher
 Version   : 0.2.6-1
 Upstream Author   : Markus Schirp mailto:m...@schirp-dso.com>>
*URL   :https://github.com/mbj/morpher  

*License   : MIT
*Description   : Morpher is a data transformation algebra with optional 
tracked evaluation.

Bug#911560: Testing Various delays

[Nicolas Dufresne]

Follow up:

I've tested download rate with a 125MB file over tftp. Even though tftp
code (or tftp itself?) is inefficient I could repeat the following:

Delay   | 2   | 3   | 4   |  5  |
---
Mb/s| 2.0 | 2.1 | 2.7 | 2.1 |
Timeouts| 5   | 4   | 1   | 4   |

The timeouts are the number of time u-boot pinted a T during the
transfer. I've also attempted some test form Linux side, and notice
some asymmetry, 9.7 MB/s download, and 7.8 MB/s upload. That was with
the same file with scp.

I've then set the RX delay too, to 4, and could notice a very minimal
improvement, 8.5 MB/s upload. Now the issue is that these are all
terrible results for a gigabit ethernet. There must be other issues
around. But a delay of 4 at least makes it usable (at around 100Mb/s).

Le vendredi 14 août 2020 à 14:26 -0400, Nicolas Dufresne a écrit :
> As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.
> 
> - 2, 3, and 4 was good enough to succeed a DHCP handshake.
> 
> - 0 and 1 made the request to never be seen over the network.
> 
> An obvious next step would be to test again with large file transfer,
> perhaps a kernel image. I will report back.
> 
> regards,
> Nicolas
> 

Bug#968408: ITP: ruby-unparser -- Generate equivalent source for parser gem AST nodes.

[Cocoa]

package: ruby-unparser
Severity: wishlist
Owner: 'Cocoa'

*Package Name  : ruby-unparser
 Version   : 0.4.7-1
 Upstream Author   : Markus Schirp mailto:m...@schirp-dso.com>>
*URL   :https://github.com/mbj/unparser  

*License   : MIT
*Description   : Generate equivalent source for parser gem AST nodes.

Bug#968409: simplescreenrecorder: Upstream Release 0.4.2 Available

[Barak A. Pearlmutter]

Package: simplescreenrecorder
Version: 0.3.11-1+b1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter 

Upstream version 0.4.2 has been released.  I've taken the liberty of
forking the maintenance repo on salsa

https://salsa.debian.org/bap/simplescreenrecorder

and pushed a trial packaging there, which seems to work.  I also filed
merge requests on salsa, because that's what kids do these days.

Cheers,

--Barak

Bug#907878: xrdp: gnome session asks permission for colord

[Marc Dunivan]

I confirm, this still exists in Debian 10 (Buster).  Debian Desktop 
GNOME3...xRDP package seems to be missing PolicyKit configuration files for 
GNOME3 shell.
I also wish to add that org.freedesktop.packagekit.system-sources-refresh 
should be added to this list.  There are also other PolicyKit configurations 
related to using GNOME Control Center.

Additionally,  GNOME Keyring isn't getting unlocked with PAM.

sudo bash -c "cat > /etc/pam.d/xrdp-sesman" <

Bug#968410: python3-setuptools: ModuleNotFoundError: No module named '_distutils_hack'

[Christian Kastner]

Package: python3-setuptools
Version: 49.3.1-1
Severity: grave
Justification: Package is unusable

The most recent upload broke something badly, setuptools can no longer
be imported:

$ python3 -c 'import setuptools'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 8, in 

import _distutils_hack.override  # noqa: F401
ModuleNotFoundError: No module named '_distutils_hack'


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 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

Versions of packages python3-setuptools depends on:
ii  python33.8.2-3
ii  python3-distutils  3.8.5-1
ii  python3-pkg-resources  49.3.1-1

python3-setuptools recommends no packages.

Versions of packages python3-setuptools suggests:
pn  python-setuptools-doc  

-- debconf-show failed

Bug#968402: Cannot connect in WPA3-sae mode, using WPA2-psk instead

[Jean-Michel Pouré]

Package: network-manager
Version: 1.26.0-1

wpasupplicant   2:2.9.0-13

Dear Maintainer,

When trying to connect to OpenWRT access point running in WPA2/WPA3
compatibility mode, I can only connect in WPA2-psk, not WPA3-sae. 

Connecting in WPA3 from Mac OS X works.

Using nmtui or Network-Manager I need to edit connection settings to
WPA/WPA2 mode. Then Network-Manager claims to connect in WPA3, but I
doubt it is WPA3 as my seeings are only for WPA/WPA2.

The problem was also described here on GITLAB Network-manager:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/172

It was fixed ten months ago in 1.20.2 but the problem remains.

Kind regards,

Bug#968412: photoflow FTBFS: incompatible compiler options

[Helmut Grohne]

Source: photoflow
Version: 0.2.8+git20200114-1
Severity: important
Tags: ftbfs patch

photoflow fails to build from source on !x86, because it passes
x86-specific compiler options. These should only be present on x86.
Please consider applying the attached patch to make it build elsewhere.

Helmut
--- photoflow-0.2.8+git20200114.orig/src/CMakeLists.txt
+++ photoflow-0.2.8+git20200114/src/CMakeLists.txt
@@ -1,12 +1,26 @@
+SET(GMIC_FLAGS "-Dgmic_build -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -fpermissive")
 IF(MINGW)
-  SET(GMIC_FLAGS "-std=gnu++14 -march=nocona -mno-sse3 -mtune=generic -Dgmic_build -Dcimg_use_vt100 -Dgmic_is_parallel -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -fno-ipa-sra -fpermissive")
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -std=gnu++14 -Dgmic_is_parallel -fno-ipa-sra")
 ELSEIF(APPLE)
   #SET(GMIC_FLAGS "-DPF_DISABLE_GMIC -std=c++11 -Wno-error=c++11-narrowing -Dgmic_build -W  -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -Dcimg_use_fftw3_singlethread -fpermissive")
-  SET(GMIC_FLAGS "-march=nocona -mno-sse3 -mtune=generic -Dgmic_build -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -Dcimg_use_fftw3_singlethread -fpermissive")
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -Dcimg_use_fftw3_singlethread")
   #SET(GMIC_FLAGS "-Wno-error=c++11-narrowing -Dgmic_build -Dcimg_use_vt100 -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -Dcimg_use_fftw3_singlethread -fpermissive")
 ELSE(MINGW)
-  SET(GMIC_FLAGS "-std=gnu++14 -march=nocona -mno-sse3 -mtune=generic -Wno-error=narrowing -Dgmic_build -Dcimg_use_vt100 -Dgmic_is_parallel -Dcimg_use_fftw3 -Dcimg_use_tiff -Dcimg_use_zlib -Dcimg_display=0 -fno-ipa-sra -fpermissive")
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -std=gnu++14 -Wno-error=narrowing -Dgmic_is_parallel -fno-ipa-sra")
 ENDIF(MINGW)
+include(CheckCCompilerFlag)
+check_c_compiler_flag(-no-sse3 HAVE_NO_SSE3)
+IF(HAVE_NO_SSE3)
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -no-sse3")
+ENDIF()
+check_c_compiler_flag(-march=nocona HAVE_MARCH_NOCONA)
+IF(HAVE_MARCH_NOCONA)
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -march=nocona")
+ENDIF()
+check_c_compiler_flag(-mtune=generic HAVE_MTUNE_GENERIC)
+IF(HAVE_MTUNE_GENERIC)
+  SET(GMIC_FLAGS "${GMIC_FLAGS} -mtune=generic")
+ENDIF()
 
 set(COMPILE_FLAGS " ${GMIC_FLAGS} -I${CMAKE_SOURCE_DIR}/src/dt -DLIBRAW_NODLL -DINSTALL_PREFIX='\"${INSTALL_PREFIX}\"' ")
 IF(APPLE)

Bug#968411: lvm2 FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: lvm2
Version: 2.03.09-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lvm2 fails to cross build from source, because it hard codes the build
architecture pkg-config in a few places. Please consider applying the
attached patch to always use the correctly detected host architecture
pkg-config. After applying it, lvm2 becomes cross buildable.

Helmut
--- lvm2-2.03.09.orig/configure.ac
+++ lvm2-2.03.09/configure.ac
@@ -1288,8 +1288,8 @@
 dnl -- Check for selinux
 if test "$SELINUX" = yes; then
 	AC_DEFINE([HAVE_SELINUX], 1, [Define to 1 to include support for selinux.])
-	SELINUX_LIBS="$(pkg-config --libs libselinux)"
-	SELINUX_LIBS_STATIC="$(pkg-config --libs --static libselinux)"
+	SELINUX_LIBS="$($PKG_CONFIG --libs libselinux)"
+	SELINUX_LIBS_STATIC="$($PKG_CONFIG --libs --static libselinux)"
 fi
 
 
@@ -1551,6 +1551,9 @@
 AC_MSG_RESULT($interface)
 
 
+PKG_CHECK_MODULES([LIBSYSTEMD],[libsystemd],[HAVE_LIBSYSTEMD=yes],[HAVE_LIBSYSTEMD=no])
+
+
 read DM_LIB_VERSION < "$srcdir"/VERSION_DM 2>/dev/null || DM_LIB_VERSION=Unknown
 AC_DEFINE_UNQUOTED(DM_LIB_VERSION, "$DM_LIB_VERSION", [Library version])
 
@@ -1625,6 +1628,7 @@
 AC_SUBST(FSADM_PATH)
 AC_SUBST(BLKDEACTIVATE)
 AC_SUBST(HAVE_LIBDL)
+AC_SUBST(HAVE_LIBSYSTEMD)
 AC_SUBST(HAVE_REALTIME)
 AC_SUBST(HAVE_VALGRIND)
 AC_SUBST(INTL)
--- lvm2-2.03.09.orig/daemons/lvmlockd/Makefile.in
+++ lvm2-2.03.09/daemons/lvmlockd/Makefile.in
@@ -15,8 +15,6 @@
 top_srcdir = @top_srcdir@
 top_builddir = @top_builddir@
 
-USE_SD_NOTIFY=yes
-
 SOURCES = lvmlockd-core.c
 
 ifeq ("@BUILD_LOCKDSANLOCK@", "yes")
@@ -44,9 +42,9 @@
 LIBS += $(RT_LIBS) $(DAEMON_LIBS) $(PTHREAD_LIBS)
 
 
-ifeq ($(USE_SD_NOTIFY),yes)
-	CFLAGS += $(shell pkg-config --cflags libsystemd) -DUSE_SD_NOTIFY
-	LIBS += $(shell pkg-config --libs libsystemd)
+ifeq ($(HAVE_LIBSYSTEMD),yes)
+	CFLAGS += $(LIBSYSTEMD_CFLAGS) -DUSE_SD_NOTIFY
+	LIBS += $(LIBSYSTEMD_LIBS)
 endif
 
 lvmlockd: $(OBJECTS) $(top_builddir)/libdaemon/client/libdaemonclient.a \
--- lvm2-2.03.09.orig/make.tmpl.in
+++ lvm2-2.03.09/make.tmpl.in
@@ -75,6 +75,8 @@
 BLKID_LIBS = @BLKID_LIBS@
 SYSTEMD_LIBS = @SYSTEMD_LIBS@
 VALGRIND_CFLAGS = @VALGRIND_CFLAGS@
+LIBSYSTEMD_CFLAGS = @LIBSYSTEMD_CFLAGS@
+LIBSYSTEMD_LIBS = @LIBSYSTEMD_LIBS@
 USE_TRACKING = @USE_TRACKING@
 
 # Setup directory variables

Bug#911560: Testing Various delays

[Jonas Smedegaard]

Quoting Nicolas Dufresne (2020-08-14 22:07:11)
> Follow up:
> 
> I've tested download rate with a 125MB file over tftp. Even though 
> tftp code (or tftp itself?) is inefficient I could repeat the 
> following:
> 
> Delay   | 2   | 3   | 4   |  5  |
> ---
> Mb/s| 2.0 | 2.1 | 2.7 | 2.1 |
> Timeouts| 5   | 4   | 1   | 4   |
> 
> The timeouts are the number of time u-boot pinted a T during the
> transfer. I've also attempted some test form Linux side, and notice
> some asymmetry, 9.7 MB/s download, and 7.8 MB/s upload. That was with
> the same file with scp.
> 
> I've then set the RX delay too, to 4, and could notice a very minimal
> improvement, 8.5 MB/s upload. Now the issue is that these are all
> terrible results for a gigabit ethernet. There must be other issues
> around. But a delay of 4 at least makes it usable (at around 100Mb/s).
> 
> Le vendredi 14 août 2020 à 14:26 -0400, Nicolas Dufresne a écrit :
> > As asked over IRC, I have tested various TX_DELAY on Lime2 rev K.
> > 
> > - 2, 3, and 4 was good enough to succeed a DHCP handshake.
> > 
> > - 0 and 1 made the request to never be seen over the network.
> > 
> > An obvious next step would be to test again with large file transfer,
> > perhaps a kernel image. I will report back.

Thanks a lot for these tests.  Really helpful!

There _are_ other limiting factors than ethernet speed involved - I do 
not know what maximum to expect on this kind of board, however.


 - 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#911560: Testing Various delays

[Jonas Smedegaard]

Quoting Nicolas Dufresne (2020-08-14 22:07:11)
> I've then set the RX delay too, to 4, and could notice a very minimal 
> improvement, 8.5 MB/s upload. Now the issue is that these are all 
> terrible results for a gigabit ethernet. There must be other issues 
> around. But a delay of 4 at least makes it usable (at around 100Mb/s).

Did you try setting RX delay to _other_ values?

Seems from adjustments of other hardware that don't need not be equal.


 - 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#966515: scons: Some upstream sources are missing

[Ben Hutchings]

On Thu, 2020-07-30 at 06:17 -0700, Bill Deegan wrote:
> Ok
> 
> Can you check the 4.0.1 tarballs and see if they provide in each what you
> need?
> We completely reimplemented packaging in 4.0.0

I can't find a scons-src tarball for 4.0.1.

Ben.

-- 
Ben Hutchings, Software Developer Codethink Ltd
https://www.codethink.co.uk/ Dale House, 35 Dale Street
 Manchester, M1 2HF, United Kingdom