Bug#973248: Deprecation warning in Ruby 2.7: $SAFE will become a normal global variable in Ruby 3.0

[intrigeri]

Control: tag -1 + patch
Control: severity -1 important

Hi,

Miquel van Smoorenburg (2020-10-27):
> I get this warning on a puppet run:
>
> /usr/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:126: warning: 
> $SAFE will become a normal global variable in Ruby 3.0

Confirmed here.

I'm bumping the severity to "important" because with typical Puppet
deployments, this bug will yield tons of noise in whatever monitoring
system is used, which makes it pretty much unusable as-is.

> So I tried another minimal approach. This fixes it for me, and it should 
> also fix those other deprecation warnings from #955532, so that patch 
> can be dropped if you want.

The way #955532 was fixed (by backporting an upstream commit) seems
cleaner to me so personally, I'd rather see the big-hammer approach
proposed here used as little as possible.

Below, I'll share the version of the patch that I'm now using.
It only tackles the problem this bug is about,
and I believe the code style is a bit more canonical Ruby
(guard clause instead of "if" + unspecified else).

Dear maintainers, I would like this bug to be fixed in Bullseye, to
avoid having to maintain a local workaround on the Tails infra for the
next 2-5 years. If it may help, I could negotiate a freeze exception
with the release team, and if they agree, upload a NMU.

What do you think?


--- /a/puppet 2020-10-25 17:04:24.0 +
+++ /b/puppet 2021-03-08 07:39:16.294675668 +
@@ -1,5 +1,12 @@
 #!/usr/bin/ruby

+
+def Warning.warn(w)
+  return if w =~ /warning: \$SAFE will become a normal global variable/
+
+  super w
+end
+
 begin
   require 'puppet/util/command_line'
   Puppet::Util::CommandLine.new.execute

Bug#983662: openvpn: autopkgtest always fails on qemu testbed

[Bernhard Schmidt]

Am 08.03.21 um 01:48 schrieb Ryutaroh Matsumoto:

Hi,

>> one of the easyrsa commands fails, and since we redirect stderr to
>> /dev/null we are not seeing any error message. Could you drop the
>> redirects and check the output?
> 
> The stderr is recoreded to "test name"-stderr by autopkgtest.
> But that file is empty...

Yes, that only lists non-redirected stderr. Since output on stderr
causes the autopkgtest to fail by default the output of most commands is
already redirected to /dev/null

./easyrsa build-ca nopass 2>/dev/null
./easyrsa build-server-full server nopass 2>/dev/null
./easyrsa gen-dh 2>/dev/null

Bernhard

Bug#984439: netgen: FTBFS on armhf (unaligned access on arm64 kernel)

[Vagrant Cascadian]

On 2021-03-03, Gianfranco Costamagna wrote:
> Hello, looks like the package FTBFS on armhf with an arm64 kernel.
> See e.g. builds from reproducible-builds.org
> https://tests.reproducible-builds.org/debian/logs/unstable/armhf/netgen_6.2.2006+really6.2.1905+dfsg-2.build2.log.gz

If this can be built in a similar environment with the personality set
with linux32, the severity should be downgraded.

The tests.reproducible-builds.org infrastructure does not use linux32
(which finds corner-case bugs like this one), but I believe
buildd.debian.org does use linux32 to set the personality where
appropriate.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#984766: dh-virtualenv: Update dependencies to python3.9-venv

[Johann Queuniet]

Package: dh-virtualenv
Version: 1.2.2-1
Severity: important

Dear Maintainer,

Currently, dh-virtualenv tries to pull python3.8-venv. However, this
package has been replaced in the archive by python3.9-venv. As is, using
this package with only the built-in venv is currently impossible without
breaking the APT dependencies tree.


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

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

Versions of packages dh-virtualenv depends on:
ii  libjs-sphinxdoc  3.4.3-1
ii  perl 5.32.1-3
ii  python3  3.9.2-2
ii  python3-virtualenv   20.4.0+ds-1
ii  sphinx-rtd-theme-common  0.5.1+dfsg-1
ii  virtualenv   20.4.0+ds-1

dh-virtualenv recommends no packages.

dh-virtualenv suggests no packages.

-- no debconf information

Bug#980364: sudo: segfault when /var/lib/sudo/lectured not writable

[Marc Haber]

Hi Frank,

thanks for your asnwer!

On Mon, Mar 08, 2021 at 01:04:36AM +0100, Frank Heckenbach wrote:
> Unfortunately, I can't easily try to reproduce it, either. (It was a
> server, so we had to quickly reboot it to get it running again and
> replace the defective disk soon after; when it happened, I didn't
> have much time to do further tests, and without gdb or strace
> available for a suid program, my options were very limited, anyway.)
> So I guess we have to leave it at that.

Is it ok for you if I close this bug?

> Most likely unrelated, but one thing I did notice when checking the
> code is that sudo_mkdir_parents might UB if path is an empty string,
> since it first does "char *slash = path; strchr (slash + 1, '/');".
> 
> Now I don't know if it's actually possible that it's called with an
> empty string, so it might not be an actual bug, but since I see it's
> coded very defensively overall, an empty string check here might not
> hurt.

Would it be ok for you to file an issue in upstream's bugzilla? Or would
it be more comforable for you if I took this issue upstream? It is
generally more useful when the bug reporter has a direct communications
link to upstream in such cases.

Greetings
Marc

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

Bug#984764: RFP: up -- a tool for writing pipes interactively, with live preview of results

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: up
  Version : 0.4
  Upstream Author : Mateusz Czapliński 
* URL : https://github.com/akavel/up
* License : Apache-2.0
  Programming Lang: Go
  Description : a tool for writing pipes interactively, with live preview 
of results

up is the Ultimate Plumber, a tool for writing Linux pipes in a
terminal-based UI interactively, with instant live preview of command
results.
.
The main goal of the Ultimate Plumber is to help interactively and
incrementally explore textual data in Linux, by making it easier to quickly
build complex pipelines, thanks to a fast feedback loop. This is achieved by
boosting any typical Linux text-processing utils such as grep, sort, cut,
paste, awk, wc, perl, etc., etc., by providing a quick, interactive,
scrollable preview of their results.

Bug#973053: I get the same

[Russell Coker]

After a fresh install of this package on a system with no errors I get the 
following immediately after starting the daemon.  I've tried deleting the 
sqlite database and restarting the daemon and then I get the same result.

# ras-mc-ctl --errors
No Memory errors.

No PCIe AER errors.

No Extlog errors.

DBD::SQLite::db prepare failed: no such table: devlink_event at /usr/sbin/ras-
mc-ctl line 1306.
Can't call method "execute" on an undefined value at /usr/sbin/ras-mc-ctl line 
1307.
# ras-mc-ctl --summary
No Memory errors.

No PCIe AER errors.

No Extlog errors.

DBD::SQLite::db prepare failed: no such table: devlink_event at /usr/sbin/ras-
mc-ctl line 1183.
Can't call method "execute" on an undefined value at /usr/sbin/ras-mc-ctl line 
1184.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#984763: systemd: Please include configurable systemd prefixes in Debian 11's systemd (fixed upstream)

[Diego Escalante Urrelo]

Package: systemd
Version: 246.6-5
Severity: important
Tags: patch
X-Debbugs-Cc: die...@gnome.org

Dear Maintainer,

In systemd-247.*, the `systemd.pc` file was modified to hard-code
`/usr/lib` as the prefix of a bunch of systemd paths. This broke build
tools like `jhbuild`, that configure and install into a custom prefix
for development and testing purposes.

The above issue was fixed usptream in:
https://github.com/systemd/systemd/commit/60bce7c6d9606185114df1bdcd5ea100407688b8#diff-3dce99316f44198c53d8147020aaca9c8931b5248587c64c098fdcef8ed4da03

However the above has not been backported by upstream to v247-stable:
https://github.com/systemd/systemd-stable/blob/v247-stable/src/core/systemd.pc.in

I'm filling against Debian, and not upstream, since I don't know if
Debian plans to keep updating to the following 247.n versions, or if
247.3 will be frozen for all of Debian 11. If it's the second case, then
it would be really helpful to cherry-pick the above fix so that the
`systemd.pc` file is fully functional.

Thanks!

-- Package-specific info:

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-9
ii  libapparmor1 2.13.6-3
ii  libaudit11:3.0-1
ii  libblkid12.36.1-7
ii  libc62.31-6
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.17-1
ii  libcryptsetup12  2:2.3.4-1
ii  libgcrypt20  1.8.7-2
ii  libgnutls30  3.7.0-5
ii  libgpg-error01.38-2
ii  libidn2-02.3.0-4
ii  libip4tc21.8.7-1
ii  libkmod2 28-1
ii  liblz4-1 1.9.3-1
ii  liblzma5 5.2.5-1.0
ii  libmount12.36.1-7
ii  libpam0g 1.4.0-2
ii  libpcre2-8-0 10.36-2
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-2+b2
ii  libsystemd0  246.6-5
ii  libzstd1 1.4.8+dfsg-1
ii  mount2.36.1-4
ii  systemd-timesyncd [time-daemon]  246.6-5
ii  util-linux   2.36.1-4

Versions of packages systemd recommends:
ii  dbus  1.12.20-1

Versions of packages systemd suggests:
ii  policykit-10.118-1
pn  systemd-container  

Versions of packages systemd is related to:
ii  dracut   051-1
pn  initramfs-tools  
ii  libnss-systemd   246.6-5
ii  libpam-systemd   246.6-5
hi  udev 246.6-5

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/logind.conf changed [not included]

-- no debconf information

Bug#984762: /usr/bin/setterm: Setterm, Please Add an Option to Increase PC-Speaker Volume

[Chime Hart]

Package: util-linux
Version: 2.36.1-7
Severity: wishlist
File: /usr/bin/setterm

Dear Maintainer,
Setterm is quite good at altering the frequency-and-length of a beep, however, 
a volume option would be `most appreciated.
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
I run in tcsh with a screen-reader
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages util-linux depends on:
ii  libaudit1  1:3.0-2
ii  libblkid1  2.36.1-7
ii  libc6  2.31-9
ii  libcap-ng0 0.7.9-2.2+b1
ii  libcrypt1  1:4.4.17-1
ii  libmount1  2.36.1-7
ii  libpam0g   1.4.0-6
ii  libselinux13.1-3
ii  libsmartcols1  2.36.1-7
ii  libsystemd0247.3-2
ii  libtinfo6  6.2+20201114-2
ii  libudev1   247.3-2
ii  libuuid1   2.36.1-7
ii  login  1:4.8.1-1
ii  zlib1g 1:1.2.11.dfsg-2

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn  dosfstools  
ii  kbd 2.3.0-3
ii  util-linux-locales  2.36.1-7

-- no debconf information
Thanks so much in advance

Bug#984754: towncrier: Include an install-time (autopkgtest) test suite

[Ben Finney]

Control: owner -1 Sérgio Cipriano 

On 08-Mar-2021, Ben Finney wrote:

> The Debian package should include an install-time test suite to be
> run by ‘autopkgtest’.

There might be a set of useful examples for the ‘towncrier’ command,
which could be converted to an autopkgtest suite for this Debian
package.

Otherwise we may need to compose those tests using, I guess, example
files from the project documentation?

-- 
 \   “A ‘No’ uttered from deepest conviction is better and greater |
  `\   than a ‘Yes’ merely uttered to please, or what is worse, to |
_o__)  avoid trouble.” —Mohandas K. Gandhi |
Ben Finney 


signature.asc
Description: PGP signature

Bug#984753: towncrier: Manual page needed for 'towncrier(1)'

[Ben Finney]

On 08-Mar-2021, Ben Finney wrote:

> We need to obtain (or write) a manual page to install as ‘towncrier(1)’.

The absence of a proper Unix manual page for ‘towncrier(1)’ is a bug
upstream. We will likely need to write the manual page ourselves.

The content will contain much of the same information from the
command's help output, but needs to also properly populate all the
typical sections of a Unix manual page; see the manual page ‘man(1)’.

-- 
 \“The priesthood have, in all ancient nations, nearly |
  `\ monopolized learning.” —John Adams, _Letters to John Taylor_, |
_o__) 1814 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#984753: Writing a manual page in ‘roff’ markup (was: Bug#984753: towncrier: Manual page needed for 'towncrier(1)')

[Ben Finney]

Control: owner -1 Sérgio Cipriano 

Thanks to Sergio for accepting ownership of this bug report.

On 08-Mar-2021, Ben Finney wrote:

> We need to obtain (or write) a manual page to install as ‘towncrier(1)’.

For writing a manual page, I recommend reading about the archaic
markup language “roff” and how to write it effectively.

https://linuxconfig.org/writing-manual-pages-on-linux>

This markup language has significant downsides: It is comparatively
old and there are much better markup languages today; and it is used
for almost nothing else but Unix manual pages.

So it is often tempting to write a manual page in some other markup
language and convert that to roff. I advise against that, though, for
two reasons.

One: The Unix manual system is very well integrated with the specifics
of roff markup. No modern popular markup language has these specific
quirks, and it can be very annoying to write well-formatted manual
pages in any other markup language.

Two: Though roff is quirky and has questionable design choices, it is
quite easy to learn and use, within the limitations of a Unix manual
page.

Bonus third reason: There are good examples of manual pages written
directly in roff, that you can crib from when writing a new one.

I offer as an example, the three manual pages included in the Debian
‘dput’ package. Get their source code, see the ‘doc/man/’ directory
for the manual page source files.

-- 
 \   “Don't worry about what anybody else is going to do. The best |
  `\ way to predict the future is to invent it.” —Alan Kay |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#984760: grub-efi-amd64: upgrade works, boot fails (error: symbol `grub_is_lockdown` not found)

[Anand Kumria]

Package: grub-efi-amd64
Version: 2.04-16
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: akum...@gmail.com

Dear Maintainer,

   * What led up to the situation?

A Toshiba laptop with a single disk, with GPT partitions, a few days ago 
performed a normal upgrade:

...
2021-03-03 16:21:30 status installed man-db:amd64 2.9.4-2
2021-03-04 06:44:34 startup archives unpack
2021-03-04 06:44:34 upgrade grub2-common:amd64 2.04-15 2.04-16
2021-03-04 06:44:34 status half-configured grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status unpacked grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status half-installed grub2-common:amd64 2.04-15
2021-03-04 06:44:34 status triggers-pending man-db:amd64 2.9.4-2
2021-03-04 06:44:34 status unpacked grub2-common:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-efi-amd64:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-efi-amd64:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-efi-amd64-bin:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-efi-amd64-bin:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:35 upgrade grub-common:amd64 2.04-15 2.04-16
2021-03-04 06:44:35 status half-configured grub-common:amd64 2.04-15
2021-03-04 06:44:35 status unpacked grub-common:amd64 2.04-15
2021-03-04 06:44:35 status half-installed grub-common:amd64 2.04-15
2021-03-04 06:44:36 status unpacked grub-common:amd64 2.04-16
2021-03-04 06:44:36 startup packages configure
2021-03-04 06:44:36 configure grub-common:amd64 2.04-16 
2021-03-04 06:44:36 status unpacked grub-common:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-common:amd64 2.04-16
2021-03-04 06:44:36 status installed grub-common:amd64 2.04-16
2021-03-04 06:44:36 configure grub-efi-amd64-bin:amd64 2.04-16 
2021-03-04 06:44:36 status unpacked grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 status installed grub-efi-amd64-bin:amd64 2.04-16
2021-03-04 06:44:36 configure grub2-common:amd64 2.04-16 
2021-03-04 06:44:36 status unpacked grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub2-common:amd64 2.04-16
2021-03-04 06:44:36 status installed grub2-common:amd64 2.04-16
2021-03-04 06:44:36 configure grub-efi-amd64:amd64 2.04-16 
2021-03-04 06:44:36 status unpacked grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:36 status half-configured grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:49 status installed grub-efi-amd64:amd64 2.04-16
2021-03-04 06:44:49 trigproc man-db:amd64 2.9.4-2 
2021-03-04 06:44:49 status half-configured man-db:amd64 2.9.4-2
2021-03-04 06:44:50 status installed man-db:amd64 2.9.4-2
...

During the course of this upgrade, I was prompted to run:

$ /usr/share/debconf/fix_db.pl

Do to some debconf database corrupt (I believe the package which prompted this 
was either mysql-common or mariadb-common)

I recall some questions / answers related to linux (and potentially grub) being 
removed due to there being no corresponding question (or similiar)

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Rebooted on 7 Mar

   * What was the outcome of this action?

grub went into grub rescue mode and displayed:

error: symbol `grub_is_lockdown` not found

   * What outcome did you expect instead?

A reboot into a functioning system.


Currently, I am booting using a rescue CD and then entering commands to 
manually start the laptop

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/sda6 /home ext4 rw,relatime 0 0
/dev/sda2 /boot/efi vfat 
rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-TOSHIBA_THNSNS128GCSP_922S10RGT2JY
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  

Bug#983435: confirmed reproducible

[bugsgrid+deb]

Control: reassign -1 src:grub2
Control: found -1 2.04-10
Control: notfound -1 2.04-9
Control: found -1 2.02+dfsg1-20+deb10u3
Control: notfound -1 2.02+dfsg1-20+deb10u2

Turned out that the symptom was not specific to grub-efi.
It does reproduce on grub-pc too.

Short steps to test:
1) rename /bin/udevadm to something else
2) run grub-install {/dev/sda}
3) make sure no error has happened
4) look, all modules are gone!

thanks very much.

Bug#984759: grub2-common: grub-install/2.02+dfsg1-20+deb10u4 ignores --bootloader-id=xxx parm; sets grubx64.efi's prefix to /EFI/debian -- prevents system boot

[YW]

Package: grub2-common
Version: 2.02+dfsg1-20+deb10u4
Severity: important

Dear Maintainer,

Upgrading to grub 2.02+dfsg1-20+deb10u4 caused  grub-install
--target=x86_64-efi  to be executed. It failed (as expected) so I ran
   grub-install --bootloader-id=debian1buster
            --efi-directory=/boot/efi1  /dev/sda
   grub-install --bootloader-id=debian2buster
            --efi-directory=/boot/efi2  /dev/sdb
because I'm running two drives under software RAID1 and I wanted boot
redundancy. In order to get there I have two entries in the EFI as
(sda1)/boot/efi1/EFI/debian1buster  and 
(sdb1)/boot/efi2/EFI/debian2buster  giving  efibootmgr -v  of
        Boot* debian1buster  
 
HD(1,GPT,----,0x800,0x10)/File(\EFI\debian1buster\shimx64.efi)
        Boot0002* debian2buster  
 
HD(1,GPT,----,0x800,0x10)/File(\EFI\debian2buster\shimx64.efi)
Where sda2/sdb2 are the RAID1 set.

Upon boot I'd get 'grub>'.
  
Entering 'set' (under 'grub>') showed 'prefix' as '/EFI/debian'.
Running  grep -l '/EFI/debian' /boot/efi1/EFI/debian1buster/* 
returned 'grubx64.efi'.
Leading me to believe that grub-install is not honoring the
--bootloader-id parameter when grubx64.efi is built.
 
 
My temporary solution was to copy
   /boot/efi1/EFI/debian1buster  to  /boot/efi1/EFI/debian
and
   /boot/efi2/EFI/debian2buster  to  /boot/efi2/EFI/debian
and now the system will boot properly.


Without knowing the particulars of Grub, it was a little surprising
that grub-install sets prefix in the first place; before it read
the grub.cfg file in current directory (/boot/efi1/EFI/debian1buster/).

I wonder if BOOTX64.CSV should be effected to prevent both of
the efi1/efi2 entries to be "shimx64.efi,debian,,This is the boot entry
for debian"; such that the ',debian,' should be the --bootloader-id
value as well.


I also wish that my 'debian1buster' entry would stop getting deleted
from EFI. I haven't figured out who to blame yet.


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/vg1bus-lv01 / ext4 rw,relatime,errors=remount-ro 0 0
/dev/mapper/vg1bus-lv09 /usr ext4 rw,relatime 0 0
/dev/sda1 /boot/efi1 vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/sdb1 /boot/efi2 vfat
rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro
0 0
/dev/mapper/vg1bus-lv04 /srv ext4 rw,relatime,stripe=4 0 0
/dev/mapper/vg1bus-lv08 /tmp ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv03 /opt ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv10 /var ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv02 /home ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv11 /var/log ext4 rw,relatime,stripe=4 0 0
/dev/mapper/vg1bus-lv07 /var/mail ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv12 /var/spool ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv13 /var/tmp ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv06 /srv/backup ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv15 /srv/tmp ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv14 /srv/vm ext4 rw,relatime 0 0
/dev/mapper/vg1bus-lv05 /srv/docs ext4 rw,relatime 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)    /dev/disk/by-id/ata-CT500MX500SSD1_x
(hd1)    /dev/disk/by-id/ata-CT500MX500SSD1_x
*** END /boot/grub/device.map

*** BEGIN /proc/mdstat
Personalities : [raid1]
md127 : active raid1 sda2[0] sdb2[1]
  487525376 blocks super 1.2 [2/2] [UU]
  bitmap: 1/4 pages [4KB], 65536KB chunk

unused devices: 
*** END /proc/mdstat


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

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

Versions of packages grub2-common depends on:
ii  dpkg    1.19.7
ii  grub-common 2.02+dfsg1-20+deb10u4
ii  install-info    6.5.0.dfsg.1-4+b1
ii  libc6   2.28-10
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libefiboot1 37-2+deb10u1
ii  libefivar1  37-2+deb10u1
ii  liblzma5    5.2.4-1

grub2-common recommends no packages.

grub2-common suggests no packages.

-- no debconf information

Bug#984495: systemd segfault soon after daemon-reload

[Benjamin Poirier]

On 2021-03-05 10:59 +0100, Michael Biebl wrote:
[...]
> 
> Is Scott the user who initially encountered this issue on Cumulus Linux 4?
> 

Scott is another Cumulus employee working on this issue.

I asked about involving the original reporter here but no success,
unfortunately.

Bug#962926: Images of aptitude screens are illegible due to being scaled to browser width

[Norman Rasmussen]

Package: aptitude-doc-en
Version: 0.8.13-3
Followup-For: Bug #962926

With respect to asciinema: I found two asciicast to svg converters:
 - https://github.com/marionebl/svg-term-cli (MIT)
 - https://github.com/nbedos/termtosvg (BSD-3-Clause)

Both generated an animated svg by default, but have an option to extract
a single frame (svg-term-cli), or all frames (termtosvg). I found that
termtosvg rendered aptitude better than svg-term-cli.

I also tried the Secure Shell chrome extension (which uses hterm
internally, both nassh and hterm as BSD-3-Clause), and while it's
possible to capture a decent screenshot with it, the output is html and
not svg.

I'm not sure how much switching to svg would help overall. Removing the
100% width would probably help the most. Refreshing the images at a
higher resolution wouldn't hurt either. Both are easier than trying to
change the image format.

Regards

Norman

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

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

aptitude-doc-en depends on no packages.

aptitude-doc-en recommends no packages.

Versions of packages aptitude-doc-en suggests:
ii  aptitude  0.8.13-3

-- no debconf information

Bug#831274: fwsnort 1.6.8-1 and dependency to fwsnort

[Arthur Barrett]

I see that on 2020-12-27, Leandro Cunha submitted an unstable build of 1.6.8-1 
and it was signed by: Adam Borowski 

Then on 2021-01-01 fwsnort 1.6.8-1 MIGRATED to testing (Debian testing watch)

However FWSNORT has a dependency on PSAD which really needs an upgrade from 
2.4.3 to 2.4.6

I’m happy to help out, but I don’t want to duplicate work on this.

Bug#984758: hash.h: fix declarations: add types to empty parentheses

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From e2b5669457f782c884d9c8ae69e7ede8c0365dfc Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 8 Mar 2021 01:56:59 +
>Subject: [PATCH] hash.h: fix declarations: add types to empty parentheses

Signed-off-by: Bjarni Ingi Gislason 
---
 hash.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hash.h b/hash.h
index ce57a8b..e318f17 100644
--- a/hash.h
+++ b/hash.h
@@ -58,9 +58,9 @@ typedef char   *HASHDATUM;/* #define won't do due to * */
 #define HASHTABLE struct hashtable
 #endif
 
-HASHTABLE  *hashcreate(unsigned, unsigned (*) ());
+HASHTABLE  *hashcreate(unsigned, unsigned (*) (void));
 voidhashdestroy(register HASHTABLE *);
 int hashstore(HASHTABLE *, register HASHDATUM, register HASHDATUM);
 HASHDATUM   hashfetch(HASHTABLE *, register HASHDATUM);
 int hashdelete(HASHTABLE *, register HASHDATUM);
-voidhashwalk(HASHTABLE *, int (*) (), char *);
+voidhashwalk(HASHTABLE *, int (*) (char *, char *, char *), char 
*);
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984757: ITP: cornus -- A fast file browser for Linux

[clay stan]

Package: wnpp
Severity: wishlist
Owner: clay stan 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: cornus
  Version : 0.0.1
  Upstream Author : f35f22fan
* URL : https://github.com/f35f22fan/Cornus
  License : GPL-3
  Programming Lang:  C++
  Description : A fast file browser for Linux.

A fast file browser for Linux written in C++17/Qt5.

Bug#984594: gpgme always emits --with-keygrip, breaking its use with gpg1

[Daniel Kahn Gillmor]

On Fri 2021-03-05 10:21:37 -0500, Daniel Kahn Gillmor wrote:
> It's not clear to me that the proposed upstream API is particularly easy
> to use, but maybe it's better to drop the remaining patch and align with
> upstream expectations, because:
>
>  - the test suite already has dropped coverage of the relevant parts,
>so the test suite won't fail.
>
>  - in T4820, upstream appears concerned about additional compute cost of
>generating keygrips (though i haven't seen any attempt to
>characterize the total compute cost)
>
>  - alignment with upstream is good in itself
>
> One possible consequence of doing this this is that gpgme-dependent
> tools that expect the keygrip field to be populated (as it indeed was by
> default when gpgme was backed with older versions of gpg) may break
> until they learn to apply GPGME_KEYLIST_MODE_WITH_KEYGRIP (which in turn
> would oblige them to depend on gpgme >= 1.14.0).
>
> Another alternative would be to make
> debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch
> conditional on the version -- only do that when the backend is known to
> be version 2.2.x or higher.
>
> I'm leaning toward just dropping the patch.

So i've dropped the patch in debian experimental, but i haven't done
anything for the version currently in unstable/testing.  I'd be curious
to hear other people's thoughts about whether it's right to make the
change before the freeze for Debian bullseye as well.

Arguments for trying to make the change for bullseye  are described above.

arguments for not making the change for bullseye include:

 - this seems to introduce gratuitous breakage for some tools that use
   gpgme, expect the keygrip, but don't know about
   GPGME_KEYLIST_MODE_WITH_KEYGRIP

 - it seems to be trying to support gpg1, which we are otherwise already
   trying to figure out how to phase out

I'm unsure of the right tradeoff here, but i welcome input on it.

   --dkg


signature.asc
Description: PGP signature

Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Paul Wise]

Control: found -1 0.6.75-1

On Sun, 2021-03-07 at 17:42 +, Surla, Sai Kalyan wrote:

> Already tried with version 0.6.75-1.

Thanks, marking the bug as found in that version.

> Also compiled the latest code available and tried with it, still the
> same results.

Thanks for testing this too.

> Please find the changes in the attached file. (readpst.c line no. : 1238)

It is traditional to provide changes in the patch format by using the
`diff -u` command or the corresponding commands from the version
control system that the upstream project is using.

Below is the output from the Mercurial diff for your change.

   $ hg diff
   diff -r 7200790e46ac src/readpst.c
   --- a/src/readpst.c Tue Jun 16 17:18:28 2020 -0700
   +++ b/src/readpst.c Mon Mar 08 09:20:50 2021 +0800
   @@ -1235,7 +1235,7 @@

int  header_match(char *header, char*field) {
int n = strlen(field);
   -if (strncasecmp(header, field, n) == 0) return 1;   // tag:{space}
   +if (strstr(header,field) != NULL || strncasecmp(header, field, n) == 0) 
return 1;   // tag:{space}
if ((field[n-1] == ' ') && (strncasecmp(header, field, n-1) == 0)) {
char *crlftab = "\r\n\t";
DEBUG_INFO(("Possible wrapped header = %s\n", header));


I am fairly certain that this is not the correct fix for this issue.

> ARC headers are kind of email authentication headers.

Thanks for the info.

> For some security reasons we cannot share the original

Understood.

> if possible we will try to share the inhouse sample pst.

That would be necessary to be able to fix the issue.

> Meanwhile our observation is if the headers start with the following
> headers (...) it is treated as bogus, this email is starting with
> some header which is not one of the listed.

That does look like what the code does indeed, probably the right fix
is to scan through all of the headers instead of just the first one.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#984756: beep: Trying to Increase Volume of PC-Speaker with "beep"

[Chime Hart]

Package: beep
Version: 1.4.9-1+b1
Severity: wishlist

Dear Maintainer,
Whether I use "beep" or "setterm" neither have a way
of increasing the volume of the PC-Speaker.
Supposedly xset has such an option, but that may not work in a console only 
setup.
-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
I run in tcsh with a screen-reader
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages beep depends on:
ii  libc6  2.31-9

beep recommends no packages.

beep suggests no packages.

-- no debconf information
Thanks so much in advance for considering an addition.

Bug#983074: task-gnome-desktop: Please consider recommending synaptic again

[Holger Wansing]

Control: tags -1 + pending

Holger Wansing  wrote (Fri, 19 Feb 2021 20:42:53 +0100):
> > Shipping synaptic by default in Debian Bullseye with GNOME, XFCE, LXDE,
> > Mate and Cinnamon would be a great (re)improvement in user experience,
> > giving users more control without the need of mastering terminal usage.
> 
> Adding debian-gtk-gnome to the loop:
> What do Gnome people prefer?
> Synaptic or gnome-packagekit?

Gnome people seem to have no preference here, so adding synaptic again.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#984755: master.c: remove declaration of the unused array "delayed_msg[]"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 1f7132067db1adcd87c9ec11c0c91c1bd48e5953 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Mon, 8 Mar 2021 01:07:27 +
>Subject: [PATCH] master.c: remove declaration of the unused array
> "delayed_msg[]"

  The array "delayed_msg[]" and its size "ndelayed_msg" were declared
although they are not used.

Signed-off-by: Bjarni Ingi Gislason 
---
 master.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/master.c b/master.c
index 2369688..8d1815b 100644
--- a/master.c
+++ b/master.c
@@ -989,11 +989,6 @@ write_error(void)
  * dummy routines - should never be called by master
  */
 
-/* extern chardelayed_msg[]; */
-
-const size_tndelayed_msg = 100; /* size of array "delayed_msg[]" */
-chardelayed_msg[100] = "";
-
 FILE   *
 open_purpose_file(void)
 {
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984754: towncrier: Include an install-time (autopkgtest) test suite

[Ben Finney]

Package: src:towncrier
Version: 19.2.0-1
Severity: wishlist
Tags: newcomer

The Debian package should include an install-time test suite to be run
by ‘autopkgtest’.

See https://wiki.debian.org/ContinuousIntegration/autopkgtest>
for information about Debian's use of autopkgtest.

-- 
 \  “Courage is not the absence of fear, but the decision that |
  `\ something else is more important than fear.” —Ambrose Redmoon |
_o__)  |
Ben Finney

Bug#984719: lintian: add check for incomplete XS-Go-Import-Path

[Alexandre Viau]

On 2021-03-07 1:28 p.m., Felix Lechner wrote:
> Hi Alexandre,
>
> On Sun, Mar 7, 2021 at 8:54 AM Alexandre Viau  wrote:
>> XS-Go-Import-Path: gopkg.in/asn1-ber.v1,
>>github.com/go-asn1-ber/asn1-ber
>>
>> And it installs files at both
>> `/usr/share/gocode/src/gopkg.in/asn1-ber.v1` and
>> `/usr/share/gocode/src/github.com/go-asn1-ber`
> Should the second path be
> /usr/share/gocode/src/github.com/go-asn1-ber/asn1-ber instead? (Please
> note the extra final component in the file list at the very bottom of
> this message.) 

Ideally yes, but both paths are technically correct. I don't think
Lintian should go so far as it will probably be hard (or impossible) to
get right.


> Also, why is it a symbolic link, please? 

In this case the package changed name, so both folders point to the same
source for backwards-compatibility. When the Go compiler imports both
paths it will find the same source code.


> Should Lintian
> merely verify that the path is present so we catch when there is a
> link and not a folder?


I don't think Lintian should distinguish between links and folders.


> in order to take a look at it. I tried examining the paths on
> packages.d.o [1] but only saw "No such package in this suite on this
> architecture." Do you know why that might be happening? Thanks!

No, sorry.


Cheers :)


-- 

Aleaxandre Viau
av...@debian.org

Bug#984753: towncrier: Manual page needed for 'towncrier(1)'

[Ben Finney]

Package: towncrier
Version: 19.2.0-1
Severity: minor
Tags: newcomer upstream

The package installs a command ‘towncrier’ without a corresponding manual page.

We need to obtain (or write) a manual page to install as ‘towncrier(1)’.

-- 
 \“The Bermuda Triangle got tired of warm weather. It moved to |
  `\   Alaska. Now Santa Claus is missing.” —Steven Wright |
_o__)  |
Ben Finney

Bug#933946: ITP: libtest-fitesque-rdf-perl -- Formulate Test::FITesque fixture tables in RDF

[Ken Ibbotson]

Thanks for the offer Kjetil.

I had to wait for the dependency 'libtest-fitesque-perl' to make it through
the process, but am now processing this library.

Regards
--
Ken

On Fri, 23 Oct 2020 at 16:22, Ken Ibbotson  wrote:

> As per proces, indicating my intent to package.
> --
> Ken
>
>

Bug#983662: openvpn: autopkgtest always fails on qemu testbed

[Ryutaroh Matsumoto]

Hi Bernhard,

>one of the easyrsa commands fails, and since we redirect stderr to
>/dev/null we are not seeing any error message. Could you drop the
>redirects and check the output?

The stderr is recoreded to "test name"-stderr by autopkgtest.
But that file is empty...

Best regards, Ryutaroh

Bug#980364: sudo: segfault when /var/lib/sudo/lectured not writable

[Frank Heckenbach]

> > On a system with disk errors, which had therefore remounted its
> > file systems read-only, I tried to sudo in order to do further
> > diagnostics as root, but sudo crashed with a segfault.
> 
> I tried reproducing this with sudo 1.8.27-1+deb10u3, on a clean file
> system, mounted read-only, on /var/lib/sudo:
> and then tried to become root from a normal user account:
>
> The timestamp, in this case, gets written to /run/sudo, which is a tmpfs
> on Debian systems. After sudo -k, another try to invoke sudo will result
> in the lecture being repeated. I don't see a segfault in any of these
> cases, and root privileges were obtained, making repair work possible.
> 
> Could it be possible that the filesystem was not only mounted read-only,
> but also broken or wrongfully mounted? Please note that you received an
> Input/Output error, while my tests ended with "Read-only file system".

Probably. I had misinterpreted the segfault as a consequence of the
reported write error because it was shown right after it.

I've now checked the code and see that sudo does continue properly
after this particular error, which is good, though it means that the
segfault could be from any code run afterwards -- or it could be a
consequence of sudo itself or one of its libraries corrupted on
loading.

Unfortunately, I can't easily try to reproduce it, either. (It was a
server, so we had to quickly reboot it to get it running again and
replace the defective disk soon after; when it happened, I didn't
have much time to do further tests, and without gdb or strace
available for a suid program, my options were very limited, anyway.)
So I guess we have to leave it at that.

Most likely unrelated, but one thing I did notice when checking the
code is that sudo_mkdir_parents might UB if path is an empty string,
since it first does "char *slash = path; strchr (slash + 1, '/');".

Now I don't know if it's actually possible that it's called with an
empty string, so it might not be an actual bug, but since I see it's
coded very defensively overall, an empty string check here might not
hurt.

Bug#971621: closed by Jeremy Sowden (Closing Bug #971621)

[riveravaldez]

Hi, Jeremy. Thanks a lot for your answer and sorry that I couldn't
respond in time. The bug is fixed indeed. Thanks again and kind
regards!

On 3/7/21, Debian Bug Tracking System  wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the wmmixer package:
>
> #971621: wmmixer : Unable to open mixer device /dev/mixer'.
>
> It has been closed by Jeremy Sowden .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Jeremy Sowden
>  by
> replying to this email.
>
>
> --
> 971621: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971621
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#803329: pulseaudio: Bash completion files provided by wrong package

[Kevin Locke]

On Fri, 2015-10-30 at 08:55 +0100, Francois Gouget wrote:
> On Wed, 28 Oct 2015, Felipe Sateler wrote:
>> What problem does this cause? Or what benefits does it cause to use
>> the correct package? I don't really want to complicate the packaging.
> 
> Anyway, here's another reason: it's possible to install pulseaudio-utils 
> without installing pulseaudio.

I just ran into this issue as you described.  I have pulseaudio-utils
installed, but not pulseaudio (because I am using PipeWire as a
PulseAudio substitute[1]).

I sympathize with your desire to avoid complicating the packaging.
Splitting the completion file looks non-trivial.  Might I suggest
shipping a copy of the completion file in the pulseaudio package as
/usr/share/bash-completion/completions/pulseaudio and a copy in the
pulseaudio-utils package as /usr/share/bash-completion/completions/pacmd
with symlinks for the other commands provided by that package?  This way
a completion for each command is shipped in the same package.  The 15kB
of duplicated data seems reasonable, if not ideal, to avoid divergence
from upstream, or the packaging work of creating a -common package just
for completions.

Thanks for considering,
Kevin

[1]: 
https://wiki.debian.org/PipeWire#Using_as_a_substitute_for_PulseAudio.2FJACK.2FALSA

Bug#984752: ITP: debian-codesearch-cli -- Debian Code Search CLI tool

[Federico Ceratto]

Package: wnpp
Severity: wishlist
Owner: Federico Ceratto 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: debian-codesearch-cli
  Version : 0.0.1
  Upstream Author : Federico Ceratto 
* URL : https://salsa.debian.org/debian/codesearch-cli
* License : GPLv3
  Programming Lang: Python
  Description : Debian Code Search CLI tool

CLI client for https://codesearch.debian.net/
Written in Python.

Bug#984751: pack_date.c: fix a typo "FALLTRHOUGH" instead of "FALLTHROUGH"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From a965b4359c0bf425ff71b515690fec1f8fad9276 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 7 Mar 2021 23:35:43 +
>Subject: [PATCH] pack_date.c: fix a typo "FALLTRHOUGH" instead of
> "FALLTHROUGH"

Signed-off-by: Bjarni Ingi Gislason 
---
 pack_date.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pack_date.c b/pack_date.c
index aa405dd..434474a 100644
--- a/pack_date.c
+++ b/pack_date.c
@@ -304,7 +304,7 @@ numeric_zone(register char *date)
break;
case '+':
date++;
-   /* FALLTRHOUGH */
+   /* FALLTHROUGH */
default:/* FALLTHROUGH */
sign = 1;
break;
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984750: decode.c: add missing header file "data.h"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 5eeaef7beab911c03b7c0b6211f734b93e8b9665 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 7 Mar 2021 23:09:28 +
>Subject: [PATCH] decode.c: add missing header file "data.h"

  Header file "global.h" must be before "data.h".

  The header file "data.h" is for the "article_header" structure.

Signed-off-by: Bjarni Ingi Gislason 
---
 decode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/decode.c b/decode.c
index 2fba7c0..3047e42 100644
--- a/decode.c
+++ b/decode.c
@@ -12,8 +12,10 @@
 #include 
 #include 
 #include "config.h"
+#include "global.h" /* must be before "data.h" */
+/* "data.h" is for structure "article_header" in "decode.h" */
+#include "data.h"
 #include "decode.h"
-#include "global.h"
 #include "save.h"
 #include "nn_term.h"
 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

[Sean Whitton]

Hello,

On Sun 07 Mar 2021 at 03:50PM -07, Sean Whitton wrote:

> This is not much good if your network is weak or you're offline, or you
> don't want information on your debugging to go out to a web service.

What I mean is: debuginfod is great in many scenarios, but we should
probably care about those who can't or won't use it too.  Sorry if the
above is a bit blunt.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

[Sean Whitton]

Hello,

On Fri 05 Mar 2021 at 06:22PM +01, Matthias Klose wrote:

> yes, the rationale for uncompressed debug sections is that any tool can access
> them.  On disk as deb/dbgsym package, there is no big difference in
> size.

The data elsewhere in this bug would suggest otherwise!

> Also a debuginfod server can be configured to send the debuginfo
> compressed on the fly.  The "only" downside is to have the uncomressed
> debuginfo on the disk when doing the debugging.

This is not much good if your network is weak or you're offline, or you
don't want information on your debugging to go out to a web service.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

[Aurelien Jarno]

On 2021-03-07 22:56, Sven Joachim wrote:
> On 2021-03-05 14:41 +0100, Aurelien Jarno wrote:
> 
> > control: notfound -1 libc6/2.28-10
> > control: found -1 libc6/2.31-9
> > control: severity -1 grave
> >
> > On 2021-03-04 19:26, Thomas Hahn wrote:
> >> Package: libc6
> >> Version: 2.28-10
> >> Severity: normal
> >> X-Debbugs-Cc: thah...@t-online.de
> >>
> >> Dear Maintainer,
> >>
> >> installed buster, then apt upgrade  was also fine,
> >> but the following dist-upgrade put the system in a broken state.
> >>
> >> Preparing to unpack .../62-locales_2.31-9_all.deb ...
> >> Unpacking locales (2.31-9) over (2.28-10) ...
> >> Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ...
> >> Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ...
> >> Preparing to unpack .../64-libc6_2.31-9_amd64.deb ...
> >> whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not
> >> found (required by /lib/x86_64-linux-gnu/libslang.so.2)
> >
> > This seems to show that libslang2 has been wrongly unpacked before
> > libc6. Do you happen to have the beginning of the log? You can find it
> > in /var/log/apt/term.log.*
> >
> >> debconf: whiptail output the above errors, giving up!
> >> Checking for services that may need to be restarted...dpkg: error
> >> processing archive
> >> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb (--unpack):
> >>  new libc6:amd64 package pre-installation script subprocess returned error 
> >> exit status 255
> >> Selecting previously unselected package libcrypt1:amd64.
> >> dpkg: considering deconfiguration of libc6:amd64, which would be broken by 
> >> installation of libcrypt1:amd64 ...
> >> dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
> >> Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
> >> De-configuring libc6:amd64 (2.28-10) ...
> >> Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
> >> Errors were encountered while processing:
> >>  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
> >> Error: Timeout was reached
> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
> >
> > To unbreak your system the best would be to unpack libc6 manually using
> > the following command:
> >   dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb /
> 
> No, never do that!  This command actually runs "dpkg-deb -x" which,
> unlike "dpkg -i", will silently overwrite symlinks to directories on the
> filesystem with directories contained in the package.  This is very bad
> if /lib is a symlink to /usr/lib (the "usrmerge" layout).

Oh I wasn't aware of that, I have fixed broken systems that way, I
wasn't aware that it doesn't work for usrmerge systems. Yet another
design issue of usrmerge...

I guess running the usrmerge script again should fix the system.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#984749: RFS: fnt/1.2-1 [ITP] -- Font downloader/manager

[Gürkan Myczko]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fnt":

 * Package name: fnt
   Version : 1.2-1
   Upstream Author : Alex Myczko 
 * URL : https://github.com/alexmyczko/fnt
 * License : MIT
 * Vcs : https://salsa.debian.org/fonts-team/fnt
   Section : fonts

It builds those binary packages:

  fnt - Font downloader/manager

To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/fnt/

Alternatively, one can download the package with dget using this 
command:


  dget -x 
https://mentors.debian.net/debian/pool/main/f/fnt/fnt_1.2-1.dsc


Changes for the initial release:

 fnt (1.2-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #984461)

Regards,
--
  Gürkan Myczko

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Sam Hartman]

> "Martin" == Martin Schurz  writes:

Martin> I have added pam_tally to common-auth and the upgrade did
Martin> not stop when installing the new libpam-modules. I believe
Martin> the regex is missing these files, since it does not contain
Martin> a "-" in the permitted characters.

Will fix.

Martin> While testing I also noticed, that pam-auth-update gives
Martin> some errors on my system. These come from line 710-714 of
Martin> the script. Upon further checking I found, that the script
Martin> does not handle commented lines. We use "# ..." comments at
Martin> the start of our pam-configs.  Is that an intented use-case
Martin> or should we add an exception to pam-auth-update to filter
Martin> comment lines?

Not part of this bug; too late for bullseye.

Martin> And some final nitpick: It seems I mistyped a capital T
Martin> (line 21) into the text templates and this got copied over.


Nod, a translator caught this; will fix.

Thanks for all your help.

Bug#982530: libpam-modules: unable to login when using pam_tally2 after upgrade to libpam-modules >1.4.0

[Martin Schurz]

Hi Sam,

that looks mostly good. Now I had some time to test your changes, and I
have some things, that may need another check.

I have added pam_tally to common-auth and the upgrade did not stop when
installing the new libpam-modules. I believe the regex is missing these
files, since it does not contain a "-" in the permitted characters.

Currently it chatches these files:
# ls -1d /etc/pam.d/* | grep -e '^/etc/pam.d/[0-9a-zA-Z/]*$'
/etc/pam.d/chfn
/etc/pam.d/chpasswd
/etc/pam.d/chsh
/etc/pam.d/login
/etc/pam.d/newusers
/etc/pam.d/other
/etc/pam.d/passwd
/etc/pam.d/runuser
/etc/pam.d/su

With a modified search it will also find the common-* files:
# ls -1d /etc/pam.d/* | grep -e '^/etc/pam.d/[0-9a-zA-Z/-]*$'
/etc/pam.d/chfn
/etc/pam.d/chpasswd
/etc/pam.d/chsh
/etc/pam.d/common-account
/etc/pam.d/common-auth
/etc/pam.d/common-password
/etc/pam.d/common-session
/etc/pam.d/common-session-noninteractive
/etc/pam.d/login
/etc/pam.d/newusers
/etc/pam.d/other
/etc/pam.d/passwd
/etc/pam.d/runuser
/etc/pam.d/runuser-l
/etc/pam.d/su
/etc/pam.d/su-l

While testing I also noticed, that pam-auth-update gives some errors
on my system. These come from line 710-714 of the script. Upon
further checking I found, that the script does not handle commented
lines. We use "# ..." comments at the start of our pam-configs.
Is that an intented use-case or should we add an exception to
pam-auth-update to filter comment lines?

And some final nitpick: It seems I mistyped a capital T (line 21)
into the text templates and this got copied over.

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

Hi again,

Am 07.03.21 um 23:08 schrieb Rene Engelhard:
> Am 07.03.21 um 22:45 schrieb Milko Krachounov:
>> After some additional testing, checking my environment and inspecting pyuno/
>> source/loader/pyuno_loader.cxx, I want to amend the report, particularly 
>> about 
>> 7.0.4 which is not affected (kind of).
> 
> Interestingly, in discussion on #debian-devel it is said that it does :/
> 
> See below.
[...]

OK, some more discussion sheds some more light on it and would explain
it. From #debian-devel again:

23:10 < _jwilk> OK, I kinda reproduced in buster without setting
PYTHONPATH myself. It doesn't crash for me, but it can't open the CSV file.
23:11 < _jwilk> I had to install libreoffice-lightproof-pt-br to trigger
the bug.
23:13 < _jwilk> So, yay, mystery solved?
23:14 < _rene_> on sid?
23:14 < _rene_> ah, on buster. yes, probably.
23:15 < _rene_> but according to the submitter and the upstream bug it
does not happen on 7.0.x
23:15 < _rene_> guess I need to fire up a buster vm
23:15 < _rene_> (and probably backport the upstream fix to buster. *sigh*)
23:16 < _rene_> yeah, libreoffice-lightproof-* is python. but I have
libreoffice-lightproof-en installed, too
23:16 < bunk> libreoffice-lightproof-en makes it reproducible for me on
buster
23:17 < _rene_> gah. even on my testing, indeed
23:17 < _rene_> no idea what I tested  before, probably I didn't do
PYTHONPATH=.
23:17 < _rene_> ok, so it boils down to
23:18 < _rene_> a) buster is affected without interaction (-> bad)
23:18 < _rene_> b) testing/sid is when setting PYTHONPATH=. (-> not
ideal,  but one shouldn't do so(tm))
23:21 < _rene_> thus this is something one needs to fix for buster, for
testing/sid it's "user error"
23:21  * _jwilk nods.
23:22 < bunk> I see some similarities between a) and
https://security-tracker.debian.org/tracker/CVE-2016-1238
23:22 < _rene_> indeed

@Salvatore: Want it done via DSA?

Regards,


Rene

Bug#984748: gettext is wrongly marked Multi-Arch: foreign

[Helmut Grohne]

Package: gettext
Version: 0.21-4
Severity: important

The gettext package includes
/usr/lib/x86_64-linux-gnu/preloadable_libintl.so. This is a shared
library on a public library search path. I looked whether it can be
considered private, but it is documented at
https://www.gnu.org/software/gettext/manual/html_node/Prioritizing-messages.html
and thus must be considered part of the interface. This interface is of
course architecture-dependent and that means that gettext must not be
marked Multi-Arch: foreign as is.

The stupid solution is removing Multi-Arch: foreign. Doing so is
correct, but not useful. A lot of packages will fail to cross build from
source once doing so. The /usr/bin/gettext binary needs to continue
residing in a Multi-Arch: foreign binary package.

The obvious consequence is that preloadable_libintl.so and the gettext
binary must reside in different binary packages. The former should be
located in a Multi-Arch: same marked package. The latter should continue
to reside in a Multi-Arch: foreign marked package.

Of course such a change is entirely inappropriate for inclusion in
bullseye, so the fix will have to wait.

Helmut

Bug#984747: sane-backends FTCBFS: python3-minimal dependency not installable

[Helmut Grohne]

Source: sane-backends
Version: 1.0.31-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

sane-backends cannot be cross built from source, because its build
dependency on python3-minimal cannot be installed for the host
architecture. It really wants a build architecture python to run
backend/pixma/scripts/pixma_gen_options.py during build. Therefore the
dependency should be annotated :any. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru sane-backends-1.0.31/debian/changelog 
sane-backends-1.0.31/debian/changelog
--- sane-backends-1.0.31/debian/changelog   2020-12-04 17:08:57.0 
+0100
+++ sane-backends-1.0.31/debian/changelog   2021-03-07 22:22:42.0 
+0100
@@ -1,3 +1,10 @@
+sane-backends (1.0.31-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Annotate python3-minimal dependency :any. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Mar 2021 22:22:42 +0100
+
 sane-backends (1.0.31-4) unstable; urgency=medium
 
   * debian/rules: 
diff --minimal -Nru sane-backends-1.0.31/debian/control 
sane-backends-1.0.31/debian/control
--- sane-backends-1.0.31/debian/control 2020-09-29 07:28:37.0 +0200
+++ sane-backends-1.0.31/debian/control 2021-03-07 22:22:41.0 +0100
@@ -26,7 +26,7 @@
  pkg-config,
  po-debconf,
  xutils-dev,
- python3-minimal
+ python3-minimal:any
 Homepage: http://www.sane-project.org
 Vcs-Git: git://jff.email/opt/git/sane-backends.git
 Vcs-Browser: https://jff.email/cgit/sane-backends.git

Bug#984746: libsndfile FTBFS with DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libsndfile
Version: 1.0.31-1
Severity: important
Tags: ftfbs patch

libsndfile fails to build from source when build with
DEB_BUILD_OPTIONS=nocheck, because dh_install is missing files including
src/test_main. This file is built during dh_auto_test only. Please
consier applying the attached patch to force building it even when not
running tests.

Helmut
diff --minimal -Nru libsndfile-1.0.31/debian/changelog 
libsndfile-1.0.31/debian/changelog
--- libsndfile-1.0.31/debian/changelog  2021-01-29 23:05:07.0 +0100
+++ libsndfile-1.0.31/debian/changelog  2021-03-07 22:09:47.0 +0100
@@ -1,3 +1,10 @@
+libsndfile (1.0.31-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with DEB_BUILD_OPTIONS=nocheck. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Mar 2021 22:09:47 +0100
+
 libsndfile (1.0.31-1) unstable; urgency=medium
 
   * New upstream version 1.0.31
diff --minimal -Nru libsndfile-1.0.31/debian/rules 
libsndfile-1.0.31/debian/rules
--- libsndfile-1.0.31/debian/rules  2021-01-29 23:05:07.0 +0100
+++ libsndfile-1.0.31/debian/rules  2021-03-07 22:09:47.0 +0100
@@ -7,6 +7,9 @@
 %:
dh $@
 
+execute_after_dh_auto_build:
+   dh_auto_build -- checkprograms
+
 override_dh_clean:
dh_clean
-find man/ -type l -delete

Bug#984745: snowball: reduce Build-Depends

[Helmut Grohne]

Source: snowball
Version: 2.1.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

snowball cannot be cross built from source, because its Build-Depends
are not satisfiable. Instead of looking into such a difficult problem, I
looked into easily droppable dependencies and noticed that the python
module resides in an Arch:all package. The relevant build instruction
can easily be conditionalized to an indep build and all of the python
dependencies can thus be moved to Build-Depends-Indep. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru snowball-2.1.0/debian/changelog 
snowball-2.1.0/debian/changelog
--- snowball-2.1.0/debian/changelog 2021-01-25 08:13:13.0 +0100
+++ snowball-2.1.0/debian/changelog 2021-03-07 22:37:12.0 +0100
@@ -1,3 +1,13 @@
+snowball (2.1.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Declaratively request dh addon python3.
++ Skip python build during arch-only.
++ Move python dependencies to Build-Depends-Indep.
+
+ -- Helmut Grohne   Sun, 07 Mar 2021 22:37:12 +0100
+
 snowball (2.1.0-1) unstable; urgency=low
 
   [ Stefano Rivera ]
diff --minimal -Nru snowball-2.1.0/debian/control snowball-2.1.0/debian/control
--- snowball-2.1.0/debian/control   2021-01-25 08:13:13.0 +0100
+++ snowball-2.1.0/debian/control   2021-03-07 22:37:09.0 +0100
@@ -4,10 +4,11 @@
 Maintainer: Stefano Rivera 
 Build-Depends:
  debhelper-compat (= 13),
- dh-python,
+ snowball-data (>= 0+20210120)
+Build-Depends-Indep:
+ dh-sequence-python3,
  python3-all,
  python3-setuptools,
- snowball-data (>= 0+20210120)
 Standards-Version: 4.5.1
 Homepage: https://snowballstem.org/
 Vcs-Git: https://salsa.debian.org/debian/snowball.git
diff --minimal -Nru snowball-2.1.0/debian/rules snowball-2.1.0/debian/rules
--- snowball-2.1.0/debian/rules 2021-01-25 08:13:13.0 +0100
+++ snowball-2.1.0/debian/rules 2021-03-07 22:36:55.0 +0100
@@ -3,12 +3,14 @@
 include /usr/share/dpkg/pkg-info.mk
 
 %:
-   dh $@ --with python3
+   dh $@
 
 override_dh_auto_build:
dh_auto_build -- $(shell dpkg-buildflags --export=configure)
+ifneq (,$(filter python3-snowballstemmer,$(shell dh_listpackages)))
$(MAKE) dist_libstemmer_python
dh_auto_build --buildsystem=pybuild -- --dir 
dist/snowballstemmer-$(DEB_VERSION_UPSTREAM) --name snowballstemmer
+endif
 
 override_dh_auto_install-indep:
dh_auto_install --buildsystem=pybuild -- --dir 
dist/snowballstemmer-$(DEB_VERSION_UPSTREAM) --name snowballstemmer

Bug#984744: gmp: update symbols for mips64r6el

[Helmut Grohne]

Source: gmp
Version: 2:6.2.1+dfgs-1
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

gmp would fail to build from source on mips64r6el if we had bootstrapped
this port due to symbol issues. It lacks any symbol that is also missing
on mips64el. Please update the symbol file:

sed -i -e 's/!mips64el/& !mips64r6el/' debian/libgmp10.symbols

Helmut

Bug#984743: execute.c: define _POSIX_C_SOURCE for "kill(2)"

[Bjarni Ingi Gislason]

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 14f86301cfd258d8a909fc38e22976235a6b59d6 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sun, 7 Mar 2021 22:16:35 +
>Subject: [PATCH] execute.c: define _POSIX_C_SOURCE for "kill(2)"

Signed-off-by: Bjarni Ingi Gislason 
---
 execute.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/execute.c b/execute.c
index 04c6afc..738683a 100644
--- a/execute.c
+++ b/execute.c
@@ -5,6 +5,11 @@
  * UNIX command execution.
  */
 
+/* define for "kill(2)" */
+#ifndef _POSIX_C_SOURCE
+#def _POSIX_C_SOURCE 200809L
+#endif
+
 #include 
 #include 
 #include 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#977857: libreoffice-common: On Wayland, it doesn't work without the xwayland pkg but installation does not pull xwayland as a dependency

[jman]

Arnoud Dekker  writes:


Thanks to https://wiki.duckcorp.org/index.php/Using_Wayland :

Installing libreoffice-gtk3 made libreoffice work for me on a bullseye install
running sway and not having xwayland installed.


Thank you for the heads-up, I will check that.

Bug#984742: rust-sha-1: several B-D are no longer available

[Andreas Beckmann]

Source: rust-sha-1
Version: 0.8.1-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + librust-sha-1-dev librust-sha-1+std-dev 

The following packages have unmet dependencies:
 builddeps:rust-sha-1 : Depends: librust-block-buffer-0.7+default-dev but it is 
not installable
Depends: librust-digest-0.8+default-dev but it is not 
installable
Depends: librust-digest-0.8+std-dev but it is not 
installable
Depends: librust-opaque-debug-0.2+default-dev but it is 
not installable


Andreas

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

forwarded 984703 https://bugs.documentfoundation.org/show_bug.cgi?id=121384

thanks


Hi,

Am 07.03.21 um 22:45 schrieb Milko Krachounov:
> After some additional testing, checking my environment and inspecting pyuno/
> source/loader/pyuno_loader.cxx, I want to amend the report, particularly 
> about 
> 7.0.4 which is not affected (kind of).

Interestingly, in discussion on #debian-devel it is said that it does :/

See below.


> First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody 
> does, I may whip up a VM to exclude other factors next Sunday).
Can try, too. My normal system is normally a stable but was already
upgraded to bullseye, though ("eat your own dogfood") due to the freeze.
> Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at 
> least with the given steps, see below), and was only happening entirely due 
> to 
> a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That 
> causes Python 3 to crash with that error. My deepest apologies for polluting 
> the report with the wrong information about 7.0.4.
> However, I can still reproduce this on 6.1.5, and changing absolutely nothing 
> in the environment, including deletion of ~/.config/libreoffice does not seem 
> to stop it, and there is no PYTHONPATH set in any form. I also noticed that 

Yeah, LO does itself.

$ grep -r PYTHONPATH /usr/lib/libreoffice/*
/usr/lib/libreoffice/program/unopkg:export
PYTHONPATH="/usr/lib/libreoffice/program"
grep: /usr/lib/libreoffice/program/libpythonloaderlo.so:
Übereinstimmungen in Binärdatei
/usr/lib/libreoffice/program/pythonloader.unorc:PYUNO_LOADER_PYTHONPATH=$ORIGIN
/usr/lib/libreoffice/program/pythonloader.unorc:PYTHONPATH=$PYTHONHOME
$PYTHONHOME/site-packages $PYTHONHOME/lib-dynload $PYTHONHOME/lib-tk $ORIGIN

$

The latter is for scripts via python3-uno though.

> pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly 
> such trailing colon (an issue that has been explicitly fixed in 7.0.4, so 
> only 
> Buster is affected):
>
> bufPYTHONPATH.append( systemPath );
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );
>
> I see the code for buster-backports (and presumably bullseye) has been 
> modified to not leave either trailing colons or colons surrounding an empty 
> string by adding three explicit checks (except for one case, which threw off 
> my testing):
>
> if (!systemPath.isEmpty())
> {
> if (bAppendSep)
> 
> bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
> bufPYTHONPATH.append(systemPath);
> bAppendSep = true;
> }
> 
> const char * oldEnv = getenv( "PYTHONPATH");
> if( oldEnv )
> {
> if (bAppendSep)
> bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) 
> );
> bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv), 
> osl_getThreadTextEncoding()) );
> }

Yes, this looks like
https://cgit.freedesktop.org/libreoffice/core/commit/?id=327153471ae38abe90463f6272e00aaa996c5ba3
and thus https://bugs.documentfoundation.org/show_bug.cgi?id=121384
(which is filed for writer and not calc, but...)

> P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by 
> Python during initialisation as it tries to determine the locale encoding, so 
> it happens before any external Python code is executed, and only happens if 
> something injects the local directory or an empty string in PYTHONPATH.

Yeah,  that was told to me on #debian-devel, too:

22:14 < olly[m]1> seems potentially problematic if PYTHONPATH is
honoured here (since it could find an entirely unrelated encodings.py on
PYTHONPATH),
  though not really RC or a security bug AFAICS
22:16 < _rene_> the question also is what calls encodings.py at all
22:17 < _rene_> since LO itself definitely does not

22:22 < _jwilk> Python itself loads it: https://paste.debian.net/1188328


[ content:

$ echo boom > encodings.py
$ export PYTHONPATH=/opt/moo:$PYTHONPATH   # oops, if PYTHONPATH is
empty, this adds cwd
$ python3
Fatal Python error: initfsencoding: Unable to get the locale encoding
Traceback (most recent call last):
  File "/home/jwilk/encodings.py", line 1, in 
NameError: name 'boom' is not defined
Aborted ]


which would support your report. Though I still don't see it.


22:33 < _rene_> and when?
22:34 < _rene_> since PYTHONPATH=. localc test.csv still doesn't load it
22:34 < _rene_> Fatal Python error: initfsencoding: Unable to get the
locale encoding
22:34 < _rene_> only then?
22:34 < _rene_> whatever that means
22:36 < _rene_> Hmm, OK, I do get an error with LANG=en_US PYTHONPATH=.
localc test.csv
22:36 < _rene_> but nothing on the console, though
22:37 < _rene_> ah, LANG=en_US in ~/äöü is not a good idea
22:37 < _rene_> still nothing pythonish, though

22:39 < _jwilk> It does crash here: https://paste.debian.net/1188332

[ content:

$echoboom > encodings.py $echo> foo.csv 

Bug#984741: ITP: pagure-messages -- A schema package for messages sent by pagure

[Sergio de Almeida Cipriano Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio de Almeida Cipriano Junior 
X-Debbugs-Cc: debian-de...@lists.debian.org, sergios...@hotmail.com.br

* Package name: pagure-messages
  Version : 0.0.6
  Upstream Author : Pierre-Yves Chibon 
* URL : https://pagure.io/pagure-messages
* License : GPLv2+
  Programming Lang: Python
  Description : A schema package for messages sent by pagure

  Pagure-messages is a schema package for messages sent by pagure, created using
  Fedora Messaging.

  A schema is important for several reasons:

   - it will help you (the developer) ensure you don’t accidentally change your
   message’s format. When messages are being generated from, say, a database 
object,
   it’s easy to make a schema change to the database and unintentionally alter 
your
   message, which breaks consumers of your message. Without a schema, you might 
not
   catch this until you deploy your application and consumers start crashing. 
With
   a schema, you’ll get an error as you develop!

   - it allows you to change your message format in a controlled fashion by 
versioning
   your schema. You can then choose to implement methods one way or another 
based on
   the version of the schema used by a message.

  For more information about message schemas see:

https://fedora-messaging.readthedocs.io/en/latest/messages.html

  The latest version of pagure (5.13.2) needs pagure-messages, my goal is to 
help
  package the new dependencies of pagure.

--
Cheers,
  Sérgio Cipriano

Bug#984740: nmu: cnrun_2.1.0-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu cnrun_2.1.0-1 . ANY . experimental . -m "Rebuild against libgsl25."

Depends on libgsl23 which is cruft.

Andreas

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

[Sven Joachim]

On 2021-03-05 14:41 +0100, Aurelien Jarno wrote:

> control: notfound -1 libc6/2.28-10
> control: found -1 libc6/2.31-9
> control: severity -1 grave
>
> On 2021-03-04 19:26, Thomas Hahn wrote:
>> Package: libc6
>> Version: 2.28-10
>> Severity: normal
>> X-Debbugs-Cc: thah...@t-online.de
>>
>> Dear Maintainer,
>>
>> installed buster, then apt upgrade  was also fine,
>> but the following dist-upgrade put the system in a broken state.
>>
>> Preparing to unpack .../62-locales_2.31-9_all.deb ...
>> Unpacking locales (2.31-9) over (2.28-10) ...
>> Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ...
>> Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ...
>> Preparing to unpack .../64-libc6_2.31-9_amd64.deb ...
>> whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not
>> found (required by /lib/x86_64-linux-gnu/libslang.so.2)
>
> This seems to show that libslang2 has been wrongly unpacked before
> libc6. Do you happen to have the beginning of the log? You can find it
> in /var/log/apt/term.log.*
>
>> debconf: whiptail output the above errors, giving up!
>> Checking for services that may need to be restarted...dpkg: error
>> processing archive
>> /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb (--unpack):
>>  new libc6:amd64 package pre-installation script subprocess returned error 
>> exit status 255
>> Selecting previously unselected package libcrypt1:amd64.
>> dpkg: considering deconfiguration of libc6:amd64, which would be broken by 
>> installation of libcrypt1:amd64 ...
>> dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
>> Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
>> De-configuring libc6:amd64 (2.28-10) ...
>> Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
>> Errors were encountered while processing:
>>  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
>> Error: Timeout was reached
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
> To unbreak your system the best would be to unpack libc6 manually using
> the following command:
>   dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb /

No, never do that!  This command actually runs "dpkg-deb -x" which,
unlike "dpkg -i", will silently overwrite symlinks to directories on the
filesystem with directories contained in the package.  This is very bad
if /lib is a symlink to /usr/lib (the "usrmerge" layout).

Cheers,
   Sven

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Milko Krachounov]

Hello,

After some additional testing, checking my environment and inspecting pyuno/
source/loader/pyuno_loader.cxx, I want to amend the report, particularly about 
7.0.4 which is not affected (kind of).

First, I wonder if someone reproduces this on 1:6.1.5-3+deb10u6 (if nobody 
does, I may whip up a VM to exclude other factors next Sunday).

Indeed, however, on 1:7.0.4~rc2-1~bpo10+2 the issue is *NOT* reproducible (at 
least with the given steps, see below), and was only happening entirely due to 
a local misconfiguration, as I had a trailing colon inside PYTHONPATH. That 
causes Python 3 to crash with that error. My deepest apologies for polluting 
the report with the wrong information about 7.0.4.

However, I can still reproduce this on 6.1.5, and changing absolutely nothing 
in the environment, including deletion of ~/.config/libreoffice does not seem 
to stop it, and there is no PYTHONPATH set in any form. I also noticed that 
pyuno/source/loader/pyuno_loader.cxx from the buster source does add exactly 
such trailing colon (an issue that has been explicitly fixed in 7.0.4, so only 
Buster is affected):

bufPYTHONPATH.append( systemPath );
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) );

I see the code for buster-backports (and presumably bullseye) has been 
modified to not leave either trailing colons or colons surrounding an empty 
string by adding three explicit checks (except for one case, which threw off 
my testing):

if (!systemPath.isEmpty())
{
if (bAppendSep)

bufPYTHONPATH.append(static_cast(SAL_PATHSEPARATOR));
bufPYTHONPATH.append(systemPath);
bAppendSep = true;
}

const char * oldEnv = getenv( "PYTHONPATH");
if( oldEnv )
{
if (bAppendSep)
bufPYTHONPATH.append( static_cast(SAL_PATHSEPARATOR) 
);
bufPYTHONPATH.append( OUString(oldEnv, strlen(oldEnv), 
osl_getThreadTextEncoding()) );
}

However, in spite of this fix, I was still able to reproduce a *similar* 
(though significantly less impactful) issue on 7.0.4. Since the code checks if 
PYTHONPATH is set (as opposed to empty), passing an empty PYTHONPATH causes 
LibreOffice to crash in the same manner (while Python 3 itself does not).

With unset PYTHONPATH:
* 1:6.1.5-3+deb10u6 from Buster crashes
* 7.0.4 from Buster Backports and Bullseye DOES NOT crash

With *empty* PYTHONPATH both crash.

$ PYTHONPATH= localc ./test.csv # this triggers it on 7.0.4
$ localc ./test.csv # this triggers it on 6.1.5

Best wishes, and I again apologize for the missing report, and for reporting 
an issue that is fixed (-ish) in bullseye and sid.

P.S. Yeah, LibreOffice doesn't touch encodings.py. The error is produced by 
Python during initialisation as it tries to determine the locale encoding, so 
it happens before any external Python code is executed, and only happens if 
something injects the local directory or an empty string in PYTHONPATH.


On неделя, 7 март 2021 г. 22:14:02 EET Rene Engelhard wrote:
> tag 984703 + moreinfo
> 
> tag 984703 + unreproducible
> 
> thanks
> 
> 
> Hi,
> 
> Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> > When opening any CSV file with LibreOffice Calc, Calc opens and executes
> > encodings.py from the current working directory.
> 
> Demonstrably wrong, see below.
> 
> >  That presumably happens because
> > 
> > Some file managers, including Krusader and mc, would launch localc in the
> > current directory, as would running it from the command line (such as
> > `localc file.csv'), thereby running encodings.py from the directory
> > containing the file.
> > 
> > The issue is not present when LibreOffice is launched through the
> > application launcher, and the file is opened later through whatever
> > means (neither Open file, nor through a file manager or the command
> > line, since localc already operates in one's $HOME in that instance)
> > To reproduce the issue, one needs to:
> > 1. Close LibreOffice *completely*
> > 2. In an empty directory, create "encodings.py" which raises an exception
> 
> Created a encodings.py which contains "foo", which surely is not valid
> python.
> 
> > 3. In the same directory (for simplicity), create "file.csv" with some
> > 
> >rows.
> 
> Did.
> 
> 1,2
> 
> ö,ä
> 
> 
> (last line to be sure there is some encoding in there)
> 
> > 4. Open "file.csv" with `localc ./file.csv' using the directory containing
> > 
> >"encodings.py" (double clicking in krusader and mc leads to the same
> >result)
> 
> Done that.
> 
> > The result is that LibreOffice crashes with the Python exception raised
> > by the rogue encodings.py, and then exits with an error that reads:
> > Fatal Python error: initfsencoding: Unable to get the locale encoding
> 
> Just works here. Opens the .csv as is.
> 
> > The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> > Buster Backports (1:7.0.4~rc2-1~bpo10+2).
> 
> Tried with 7.0.4-3 on bullseye (which 

Bug#984739: nmu: singular_1:4.1.2-p1+ds-2

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu singular_1:4.1.2-p1+ds-2 . ANY . experimental . -m "Rebuild against 
libflint-2.6.1."

libflint-2.5.2 is gone ...

Andreas

Bug#838055: 0ad: Embedded libsquish library now available in debian

[Ludovic Rousseau]

On Mon, 24 Aug 2020 15:22:06 +0200 Fabio Pedretti  
wrote:

Hi, I closed this issue years ago because actually 0ad doesn't use the
squish library which is in the 0ad source.

It's a problem strictly related to the nvidia-texture-tools package.
Actually 0ad source could also be repackaged to remove squish and nvtt
directory, which are not used. Since there is already bug #838056 for
nvidia-texture-tools there is nothing to be done here and this one
could actually be closed. But I'll leave that up to you.

Related:
https://github.com/castano/nvidia-texture-tools/pull/244


0ad alpha 24 now uses the embedded nvtt library because it needs nvtt 2.1 and 
Debian only has 2.0.8 in stable.
So 0ad also uses the embedded squish library in 
https://salsa.debian.org/games-team/0ad/-/tree/master/libraries/source/nvtt/src/src/nvtt/squish

Bye

--
Dr. Ludovic Rousseau

Bug#980885: manpages-es-extra: Suitable for Bullseye?

[Javier Fernandez-Sanguino]

On Fri, 5 Feb 2021 at 23:51, Mario Blättermann 
wrote:

> Hello Javier,
>
> as Helge already wrote, manpages-es-extra is far too outdated to worth
> shipping it in Bullseye. It is *now* the time to get rid of this
> package.
>

Indeed, this is the case I have opened Bug #984734 today to request this.
Sorry for the delay as this should have been done a long time ago already.


> Tomorrow we will release a new version of manpages-l10n, which will
> contain Spanish translations for the first time, after manpages-es
> vanished from Debian (for good reasons). I'm almost finished with the
> import of the plain text translations from manpages-es-extra, so I
> think the .po files will be available for translators a few days after
> the upcoming release. This means in return: Because manpages-l10n
> doesn't distinguish between »es« and »es-extra« files, the release in
> march will include the newly imported .po files – and raise file
> conflicts. I think you agree with me that it's better to have 100 .po
> files (at least 80% translated) which are up-to-date than 200 terribly
> outdated plain text translations which nobody benefits of.
>

I fully agree with this approach and would suggest you. To fix the file
conflicts I guess you could add a Conflicts with older versions of
manpages-es-extra.

Would it make sense to have a transitioning (dummy) package to have users
migrate from manpages-es-extra to manpages-l10n? That way users with the
manpages-es-extra package installed (for whatever reason, but maybe because
it was at some point pulled in because 'manpages-es' was in the Spanish
task selection) would pull in automatically manpages-l10n.

Best regards

Javier

Bug#794562: nvtt 2.1 now required

[Ludovic Rousseau]

On Mon, 24 Aug 2020 09:25:24 +0200 Fabio Pedretti  
wrote:

SVN version of 0ad now includes nvtt 2.1.1:
https://trac.wildfiregames.com/changeset/23305

And also require a new version to properly build:
https://trac.wildfiregames.com/changeset/23974


0ad alpha 24 depends on nvtt 2.1.
nvtt 2.1 is still only in Debian experimental since May 2016. The package was 
not updated since then.

I don't know if nvtt 2.1 will ever be moved to unstable one day.
For now the 0ad alpha 24 build uses the embedded nvtt.

Maybe we can close this bug?

Bye

--
Dr. Ludovic Rousseau

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

[Aurelien Jarno]

On 2021-03-07 18:26, Thomas Hahn wrote:
> On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno  wrote:
> > control: notfound -1 libc6/2.28-10
> > control: found -1 libc6/2.31-9
> > control: severity -1 grave
> > 
> > On 2021-03-04 19:26, Thomas Hahn wrote:
> > > Package: libc6
> > > Version: 2.28-10
> > > Severity: normal
> > > X-Debbugs-Cc: thah...@t-online.de
> > > 
> > > Dear Maintainer,
> > > 
> > > installed buster, then apt upgrade  was also fine,
> > > but the following dist-upgrade put the system in a broken state.
> > > 
> > > Preparing to unpack .../62-locales_2.31-9_all.deb ...
> > > Unpacking locales (2.31-9) over (2.28-10) ...
> > > Preparing to unpack .../63-openssh-server_1%3a8.4p1-4_amd64.deb ...
> > > Unpacking openssh-server (1:8.4p1-4) over (1:7.9p1-10+deb10u2) ...
> > > Preparing to unpack .../64-libc6_2.31-9_amd64.deb ...
> > > whiptail: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found 
> > > (required by /lib/x86_64-linux-gnu/libslang.so.2)
> > 
> > This seems to show that libslang2 has been wrongly unpacked before
> > libc6. Do you happen to have the beginning of the log? You can find it
> > in /var/log/apt/term.log.*
> > 
> 
> Attached the section starting with the ill-fated dist-upgrade.

Thanks, that confirms the fact that libslang2 is unpacked before. We
have to find a solution for this.

> > > debconf: whiptail output the above errors, giving up!
> > > Checking for services that may need to be restarted...dpkg: error 
> > > processing archive /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb 
> > > (--unpack):
> > >  new libc6:amd64 package pre-installation script subprocess returned 
> > > error exit status 255
> > > Selecting previously unselected package libcrypt1:amd64.
> > > dpkg: considering deconfiguration of libc6:amd64, which would be broken 
> > > by installation of libcrypt1:amd64 ...
> > > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
> > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
> > > De-configuring libc6:amd64 (2.28-10) ...
> > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
> > > Errors were encountered while processing:
> > >  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
> > > Error: Timeout was reached
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > 
> > To unbreak your system the best would be to unpack libc6 manually using
> > the following command:
> >   dpkg -x /var/cache/apt/libc6_2.31-9_amd64.deb /
> > 
> > Then you should be able to run apt again to fix you system.
> 
> It looked like that did the trick. But then update-initramfs failed.
> /lib/modules was EMPTY!

Hmm, I fail to see how that's linked to manually unpacking the libc6
package. Do you have a log of the failure?

> The same story for 2 machines.
> So, for me it looks like the scripts in the control file do some magic
> which make it bad right now.
> 
> Thought I would get an automatic reply on all messages, but maybe I 
> need to subscribe.

Your email address was in the To:, but your mail server refused my
email. I tried from two non-dialup IPs multiple time, but all my
tentative fails:

  thah...@t-online.de
host mx02.t-online.de [194.25.134.9]
SMTP error from remote mail server after initial connection:
554 IP=193.70.89.123 - A problem occurred. (Ask your postmaster for help or 
to contact t...@rx.t-online.de to clarify.)

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#984738: nmu: eeshow_0.git20170731-2

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu eeshow_0.git20170731-2 . ANY . experimental . -m "Rebuild against libgit2 
1.1"

That package still depends on no longer available libgit2-27

Andreas

Bug#873019: [PATCH] Re: shellinabox: ssh unsupported option after username input

[Ángel]

Followup-For: Bug #873019
Package: shellinabox
Version: 2.21
Tags: patch

When using the built-in SSH service description, that produces
command-line line 0: Unsupported option "rhostsrsaauthentication"
command-line line 0: Unsupported option "rsaauthentication"

this is because SSH is mapped (initService function) to running ssh(1)
with a bunch of options which include
 -oRhostsRSAAuthentication=no -oRSAAuthentication=no

However, these options were removed in OpenSSH 7.4 along SSH 1 support,
as documented by Colin in 
https://salsa.debian.org/ssh-team/openssh/-/commit/fb87db8aa47d3508be8e5bb1d21897fa1f2eca90
(debian bug #851573)

The attached patch solves it.

Upstream bug: https://github.com/shellinabox/shellinabox/issues/458

--- shellinabox/service.c1	2016-11-09 18:40:20.0 +0100
+++ shellinabox/service.c	2021-03-07 00:47:20.727795214 +0100
@@ -175,8 +175,7 @@
   "-oHostbasedAuthentication=no -oIdentitiesOnly=yes "
   "-oKbdInteractiveAuthentication=yes -oPasswordAuthentication=yes "
   "-oPreferredAuthentications=keyboard-interactive,password "
-  "-oPubkeyAuthentication=no -oRhostsRSAAuthentication=no "
-  "-oRSAAuthentication=no -oStrictHostKeyChecking=no -oTunnel=no "
+  "-oPubkeyAuthentication=no -oStrictHostKeyChecking=no -oTunnel=no "
   "-oUserKnownHostsFile=/dev/null -oVerifyHostKeyDNS=no "
 // beewoolie-2012.03.30: while it would be nice to disable this
 //  feature, we cannot be sure that it is available on the

Bug#984737: nmu: mupen64plus-video-glide64mk2_2.5.9-1

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu mupen64plus-video-glide64mk2_2.5.9-1 . ANY . experimental . -m "Rebuild 
against Boost 1.74"

That package still depends on Boost 1.67 packages.


Andreas

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

[Aurelien Jarno]

On 2021-03-07 22:14, Paul Gevers wrote:
> Hi,
> 
> On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno 
> wrote:
> > > Selecting previously unselected package libcrypt1:amd64.
> > > dpkg: considering deconfiguration of libc6:amd64, which would be broken 
> > > by installation of libcrypt1:amd64 ...
> > > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
> > > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
> > > De-configuring libc6:amd64 (2.28-10) ...
> > > Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
> > > Errors were encountered while processing:
> > >  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
> > > Error: Timeout was reached
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> 
> Could this be the same problem as in bug #974552?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974552

Nope, that's a different issue. libcrypt appears there as a consequence
of a the first failure.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#984736: RFH: cron -- new maintainer need

[Javier Fernández-Sanguino Peña]

Package: wnpp
Version: N/A; reported 2021-07-03
Severity: wishlist

A new an active maintainer is required for the cron package. Cron is a basic
system utility that runs programs periodically in the system, it is used by
multitude of packages and is part of the core OS debian tools.

The package is maintained in Salsa (https://salsa.debian.org/debian/cron).

I picked up the package in 2005 and have been trying to maintain it and fix
bugs in it and keep it more or less current. In 2014, Christian Kastner
joined as co-maintainer and has been done the bulk of the job in mantaining /
improving it. He recently did a fantastic job in converting the package to
3.0 (quilt).  

He also provided its replacement, cronie, in experimental (package available
at https://salsa.debian.org/debian/cronie, upstream available at
https://github.com/cronie-crond/cronie)

Cron has been dead for years upstream, Debian still uses it instead of Cronie
as over the years the package has received many changes that are
Debian-specific.

Ideally a maintainer willing to help cron move forward would support the next
major task to be done: moving the Debian-specific patches into cronie and 
providing an updated package for cronie replacement that can eventually
replace cron.

Please contact the current maintainer if you can help in maintaining and
improving cron.

Best regards,

Javier Fernández-Sanguino


signature.asc
Description: PGP signature

Bug#984533: libc6: upgrade from 2.28-10 to 2.31-9 breaks system

[Paul Gevers]

Hi,

On Fri, 5 Mar 2021 14:41:23 +0100 Aurelien Jarno 
wrote:
> > Selecting previously unselected package libcrypt1:amd64.
> > dpkg: considering deconfiguration of libc6:amd64, which would be broken by 
> > installation of libcrypt1:amd64 ...
> > dpkg: yes, will deconfigure libc6:amd64 (broken by libcrypt1:amd64)
> > Preparing to unpack .../65-libcrypt1_1%3a4.4.17-1_amd64.deb ...
> > De-configuring libc6:amd64 (2.28-10) ...
> > Unpacking libcrypt1:amd64 (1:4.4.17-1) ...
> > Errors were encountered while processing:
> >  /tmp/apt-dpkg-install-I51xYx/64-libc6_2.31-9_amd64.deb
> > Error: Timeout was reached
> > E: Sub-process /usr/bin/dpkg returned an error code (1)

Could this be the same problem as in bug #974552?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974552

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Paul Gevers]

Hi,

On Fri, 20 Nov 2020 13:44:50 +0100 Alois Wohlschlager
 wrote:
> > > > Another option might be to have the new libc6 Conflict with old
> > > > versions
> > > > of Essential:yes packages that need libcrypt1, forcing those
> > > > Essential:yes
> > > > packages to get upgraded first. A quick check based on libcrypt1
> > > > reverse
> > > > dependencies in sid shows perl-base, login and util-linux. I'm
> > > > not sure
> > > > if this list is exhaustive, though.
> 
> Having libc6 Conflict with one of those packages should be enough,
> right?

Shouldn't this bug be reassigned to libc6?

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#984735: composer: fails on installed.json format used in Composer v2

[Imre Jonk]

Package: composer
Version: 1.8.4-1
Severity: normal
Tags: patch

Dear Maintainer,

(resubmitting this as my previous report seems to have vanished)

Composer 1.8.4-1 in Debian 10 fails on the installed.json format of
Composer v2. This can be a problem for Debian 10 users who want to use
software packaged for Composer 2.0.0 and up. One example of such
software is SimpleSAMLphp 1.19.0. This problem has of course been fixed
in the composer 2.0.9-1 package in Debian Testing, but you might want
to
address this in buster-proposed-updates as well.

A minimal patch that enables forward compatibility with the v2 format
can be found upstream:
https://github.com/composer/composer/commit/ba346ef04d7cc6fdbf9423b06f51e48485d20b77

The full transcript of my Composer session can be found here:
https://gist.github.com/imrejonk/07e29358c00578386783621c2f08d8ef

Here is the exception trace from the transcript above:

Exception trace:
 () at /usr/share/php/Composer/Package/Loader/ArrayLoader.php:44
 Composer\Package\Loader\ArrayLoader->load() at
/usr/share/php/Composer/Repository/FilesystemRepository.php:63
 Composer\Repository\FilesystemRepository->initialize() at
/usr/share/php/Composer/Repository/ArrayRepository.php:185
 Composer\Repository\ArrayRepository->getPackages() at
/usr/share/php/Composer/Plugin/PluginManager.php:256
 Composer\Plugin\PluginManager->loadRepository() at
/usr/share/php/Composer/Plugin/PluginManager.php:76
 Composer\Plugin\PluginManager->loadInstalledPlugins() at
/usr/share/php/Composer/Factory.php:384
 Composer\Factory->createComposer() at
/usr/share/php/Composer/Factory.php:576
 Composer\Factory::create() at
/usr/share/php/Composer/Console/Application.php:345
 Composer\Console\Application->getComposer() at
/usr/share/php/Composer/Console/Application.php:458
 Composer\Console\Application->getPluginCommands() at
/usr/share/php/Composer/Console/Application.php:156
 Composer\Console\Application->doRun() at
/usr/share/php/Symfony/Component/Console/Application.php:148
 Symfony\Component\Console\Application->run() at
/usr/share/php/Composer/Console/Application.php:104
 Composer\Console\Application->run() at /usr/bin/composer:57


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-14-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.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 composer depends on:
ii  jsonlint 1.7.1-1
ii  php-common   2:69
ii  php-composer-ca-bundle   1.1.4-1
ii  php-composer-semver  1.4.2-1
ii  php-composer-spdx-licenses   1.5.0-1
ii  php-composer-xdebug-handler  1.3.2-1
ii  php-json-schema  5.2.8-1
ii  php-psr-log  1.1.0-1
ii  php-symfony-console  3.4.22+dfsg-2+deb10u1
ii  php-symfony-filesystem   3.4.22+dfsg-2+deb10u1
ii  php-symfony-finder   3.4.22+dfsg-2+deb10u1
ii  php-symfony-process  3.4.22+dfsg-2+deb10u1
ii  php7.3-cli [php-cli] 7.3.19-1~deb10u1

Versions of packages composer recommends:
ii  git1:2.20.1-2+deb10u3
ii  unzip  6.0-23+deb10u1

Versions of packages composer suggests:
pn  fossil  
pn  mercurial   
pn  php-zip 
ii  subversion  1.10.4-1+deb10u1

-- no debconf information


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

Bug#984733: ITS: libuser

[Ghe Rivero]

+1. I no longer can contribute to it

Ghe Rivero

On Sun, Mar 7, 2021, 8:12 PM Boyuan Yang  wrote:

> Source: libuser
> Version:  1:0.62~dfsg-0.4
> Severity: important
> X-Debbugs-CC: tzaf...@debian.org g...@debian.org
>
> Dear package libuser maintainers in Debian,
>
> After looking into the package you maintain (libuser,
> https://tracker.debian.org/pkg/libuser), I found that this package
> received no maintainer updates in the past 6 years. As a result, I am
> filing an ITS (Intent to Salvage) request against your package
> according to section 5.12 in Debian's Developers' Reference [1].
>
> My current plan is to package the latest upstream release (0.63),
> clean up packaging and orphan this package to allow possible external
> contribution.
>
> Please let me know whether you are still willing to maintain this
> package. According to the criteria listed at [2], I will upload a Non-
> maintainer Upload (NMU) of this package onto experimental with
> DELAYED/7 after 21 days (Mar 28, 2021) to continue with the package
> salvaging. If you find it necessary to pause the ITS process, please
> let me know immediately by replying this bug report.
>
> [1]
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [2] https://wiki.debian.org/PackageSalvaging
>
> --
> Regards,
> Boyuan Yang
>

Bug#983862: PVH -- cannot remove vm with pci passthrough

[Hans van Kranenburg]

reassign 983862 src:xen 4.11.4+57-g41a822c392-2
tags 983862 + upstream
thanks

Hi Adi!

On 3/2/21 12:46 PM, Adi Kriegisch wrote:
> Package: xen-utils-4.11
> Version: 4.11.4+57-g41a822c392-2
> Severity: minor
> 
> Dear maintainers,
> 
> we, by accident, added a pci passthrough device config to a pvh vm and were
> able to boot that machine. But shutdown did not work with the following
> error message:
>   | xl: libxl_pci.c:1427: do_pci_remove: Assertion `type == 
> LIBXL_DOMAIN_TYPE_PV' failed.
> To remove the virtual machine and free its resources a reboot of Dom0 was
> necessary. A corresponding assert when creating the machine seems to be
> missing.
> We consider this to be a bug, because we should not have been able to 'xl
> create' that machine in the first place (or would have needed a way to
> dispose the vm).

Aha. Interesting. I just had a look at libxl_pci.c in the latest
upstream code, and I think the same bug still exists.

PCI passthrough is still not supported for PVH, so it should refuse, a
bit higher up in the call stack. Probably not with an assert, but with a
nice error message. :)

I think I'm going to have a closer look at it somewhere in the next week.

Note that the bug fix will not reach Xen 4.11 (or our package) any more.

Regards,
Hans van Kranenburg

Bug#973922: new signing key known

[Geert Stappers]

In 
https://github.com/archlinux/svntogit-community/commit/33ee8cb5215ab425e21c5911af8b895529d5b88ao
and 
https://github.com/archlinux/svntogit-community/commit/6f3dbf5530f046f0fba08f467796c42aa94ef800
is said that '7D0B3CEBE9B85B1F825BCECFEE05E6F6A48F6136' # Robin Hugh Johnson
is the new signing key.

This is the plan:
* Update the Debian directory with the new information
* Check it with 2.19
* Upload the 2.19 release to expiremental
* Be ready for the next upstream release



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#984734: RM: manpages-es-extra -- ROM;abandoned upstream

[Javier Fernández-Sanguino Peña]

Package: ftp.debian.org
Severity: normal

The manpages-es-extra package only contains outdated manpages as the upstream
project (PAMELI) has been dead now for many, many years (since 2005). 
It does not make any more sense to distribute this package as there is no
real way to identify which manpages are still valid


Please remove this package so the extra manpages for the Spanish language can
be provided by the manpages-l10n package (which already provides
'manpages-es'). This new package introduces a gettext (PO-based) system which
will make it possible to provide manpages in Spanish highlighting which
content is not up to date.

Thank you for your help,

Javier Fernández-Sanguino


signature.asc
Description: PGP signature

Bug#984479: is this a proper fix?

[Thomas Lange]

Do you think that this is a proper fix?


diff --git a/debian/fai-nfsroot.preinst b/debian/fai-nfsroot.preinst
index a2b5d45e..47402800 100755
--- a/debian/fai-nfsroot.preinst
+++ b/debian/fai-nfsroot.preinst
@@ -5,7 +5,11 @@ if [ ! -f /.THIS_IS_THE_FAI_NFSROOT ]; then
 exit 1
 fi
 
-dpkg-divert --package fai-nfsroot --add --divert /etc/init.d/rcS.orig --rename 
/etc/init.d/rcS
+case $1 in
+install)
+   dpkg-divert --package fai-nfsroot --add --divert /etc/init.d/rcS.orig 
--rename /etc/init.d/rcS
+   ;;
+esac

Bug#982043: Please consider reverting (i.e. re-adding dependency)

[Holger Wansing]

Hi,

Helge Kreutzmann  wrote (Fri, 5 Mar 2021 16:58:34 +0100):
> On Thu, Mar 04, 2021 at 11:59:43PM +0100, Holger Wansing wrote:
> > Missing in tasksel are currently:
> > manpages-es
> > manpages-mk
> > manpages-nl
> > manpages-bt-BR
> > manpages-ro
> > 
> > Are these in a good condition for stable?
> 
> Yes. Both upstream and myself only ship (enable) languages we have
> some confidence in. 
> 
> > Should they be added to the respective language tasks?
> 
> This would be a very good idea.

Just changed in git.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

tag 984703 + moreinfo

tag 984703 + unreproducible

thanks


Hi,

Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> When opening any CSV file with LibreOffice Calc, Calc opens and executes
> encodings.py from the current working directory.

Demonstrably wrong, see below.

>  That presumably happens because 
>
> Some file managers, including Krusader and mc, would launch localc in the 
> current directory, as would running it from the command line (such as
> `localc file.csv'), thereby running encodings.py from the directory
> containing the file.
>
> The issue is not present when LibreOffice is launched through the 
> application launcher, and the file is opened later through whatever 
> means (neither Open file, nor through a file manager or the command 
> line, since localc already operates in one's $HOME in that instance)
> To reproduce the issue, one needs to:
> 1. Close LibreOffice *completely*
> 2. In an empty directory, create "encodings.py" which raises an exception
Created a encodings.py which contains "foo", which surely is not valid
python.
> 3. In the same directory (for simplicity), create "file.csv" with some 
>rows.

Did.

1,2

ö,ä


(last line to be sure there is some encoding in there)


> 4. Open "file.csv" with `localc ./file.csv' using the directory containing
>"encodings.py" (double clicking in krusader and mc leads to the same
>result)

Done that.


> The result is that LibreOffice crashes with the Python exception raised
> by the rogue encodings.py, and then exits with an error that reads:
> Fatal Python error: initfsencoding: Unable to get the locale encoding

Just works here. Opens the .csv as is.


> The problem is present in both Debian Stable (1:6.1.5-3+deb10u6), and
> Buster Backports (1:7.0.4~rc2-1~bpo10+2).

Tried with 7.0.4-3 on bullseye (which should be identical to the
backport you use in this regard)


> No extensions not installed
> by apt are present on either machine (on the one with 6.1.5 I never
> installed any, and on the 7.0.4 I'm trusting what the LO extension 
> manager is telling me, since I cannot recall for sure)

Something else you did?

> Here's the console chatter:
>
> # Test on the host with 1:7.0.4~rc2-1~bpo10+2 - hostname is censored
> milko@host2 ~/Временна/LOSecurity $ cat > encodings.py

Maybe it is because of the *dir* this is in? I am so sure not creating a
cyrillic directory to check.

But even in a ~/öäü I just created, no crash and just an open of the .csv


> raise NotImplementedError("Darth Vader, Obi-Wan and Ahsoka walk into a bar")
> milko@host2 ~/Временна/LOSecurity $ cat > test.csv
> Column 1;Column 2;Column 3
> текст;ຂໍ້ຄວາມ;text
> milko@host2 ~/Временна/LOSecurity $ localc test.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
>   File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in 
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
>   File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in 
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> milko@host2 ~/Временна/LOSecurity $ cat > test2.csv
> Column 1;Column 2;Column 3
> text1;text2;text3
> milko@host2 ~/Временна/LOSecurity $ localc test2.csv
> Fatal Python error: initfsencoding: Unable to get the locale encoding
> Traceback (most recent call last):
>   File "/home/milko/Временна/LOSecurity/encodings.py", line 1, in 
> NotImplementedError: Darth Vader, Obi-Wan and Ahsoka walk into a bar
> Application Error
> milko@host2 ~/Временна/LOSecurity $

Even this doesn't produce any error. (in my ~/aöü)



>> Can yu pleas make this directly a public report in the Debian BTS?

Are you serious? For something unreproducible? Or were you able to
reproduce it?


Regards,


Rene

Bug#984703: libreoffice-calc: LibreOffice Calc executes code from current dir (encodings.py) when opening a .csv

[Rene Engelhard]

Hi again,

Am 07.03.21 um 13:34 schrieb Milko Krachounov:
> When opening any CSV file with LibreOffice Calc, Calc opens and executes
> encodings.py from the current working directory. That presumably happens
> because

There also is no  mention of any "encodings.py" in anything in
LibreOffice itself:

rene@frodo:~/LibreOffice/git/libreoffice-7-0-4$ git grep encodings
config_host/config_locales.h.in: * support all the locales and character
encodings that it has code
configure.ac:  tables for encodings mainly
targeted for a
cui/source/tabpages/tpline.cxx:// Convert URL encodings to
UI characters (e.g. %20 for spaces)

[ internal python3 (which we don't use) encoding stuff stripped ]

filter/qa/complex/filter/detection/typeDetection/TypeDetection.java:
 * is used as source for several encodings.
filter/source/graphicfilter/idxf/dxfreprd.cxx:// Its
Windows variant, and later releases used ANSI encodings for
filter/source/graphicfilter/idxf/dxfreprd.cxx://
encodings for storing to corresponding formats, but there's
filter/source/graphicfilter/idxf/dxfreprd.cxx://
$DWGCODEPAGE to encodings mappings
filter/source/msfilter/util.cxx:// in last-ditch broken-file-format
cases to guess the right 8bit encodings
framework/qa/complex/loadAllDocuments/CheckXComponentLoader.java: *
is used as source for several encodings.
include/filter/msfilter/util.hxx:/// i.e. useful when dealing with
legacy formats which use legacy text encodings without recording
include/rtl/string.h:for double-byte encodings, UTF-7, UTF-8).
include/rtl/tencinfo.h:Can be rather meaningless for encodings
that encode global state along
include/rtl/tencinfo.h:with the characters (e.g., ISO-2022
encodings).
include/rtl/tencinfo.h:Can be rather meaningless for encodings
that encode global state along
include/rtl/tencinfo.h:with the characters (e.g., ISO-2022
encodings).
include/rtl/tencinfo.h:characters (SS2 and SS3) used by some of
the EUC encodings (to denote
include/rtl/tencinfo.h:repertoire) do not imply that encodings
making use of these characters
include/rtl/tencinfo.h:have the CONTEXT property.  Examples of
encodings that do have the
include/rtl/tencinfo.h:CONTEXT property are the ISO-2022
encodings and UTF-7.
include/rtl/tencinfo.h:special purposes in some encodings.
include/rtl/textenc.h:/** The various supported text encodings.
include/rtl/textenc.h:Possible values include a wide range of
single- and multi-byte encodings
include/rtl/textenc.h:the ISO 10646 (Unicode) specific encodings
RTL_TEXTENCODING_UCS4 and
include/rtl/textenc.h:These encodings are not used for text encodings,
only used for
include/rtl/textenc.h:font-/textoutput encodings.
include/rtl/uri.h:converted to eCharset because it contains
(encodings of) unmappable
include/rtl/ustring.h:for double-byte encodings, UTF-7, UTF-8).
include/rtl/ustring.hxx:encodings, UTF-7, UTF-8).
include/rtl/ustring.hxx:encodings, UTF-7, UTF-8).
include/svx/txencbox.hxx:/** Fill with all known encodings but
exclude those matching one or more
include/svx/txencbox.hxx:  If nButIncludeInfoFlags is given,
encodings are included even if they
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/svx/txencbox.hxx:/** Fill with all encodings known to the
dbtools::OCharsetMap but exclude
include/svx/txencbox.hxx:  If nButIncludeInfoFlags is given,
encodings are included even if they
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/svx/txencbox.hxx:/** Fill with all known MIME encodings and
select the best according to
include/svx/txencbox.hxx:/** Fill with all known encodings but
exclude those matching one or more
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/svx/txencbox.hxx:/** Fill with all encodings known to the
dbtools::OCharsetMap but exclude
include/svx/txencbox.hxx:If , some specific encodings
are not listed, as they are a
include/tools/tenccvt.hxx:/// encoding. The encodings could be different.
sal/osl/unx/nlsupport.cxx: * _nl_language_list[] is an array list of
supported encodings. Because
sal/osl/unx/nlsupport.cxx: * We are comparing the encodings case
insensitive, so the list has
sal/qa/rtl/uri/rtl_testuri.cxx:// Check encode with unusual text
encodings:
sal/rtl/ustring.cxx:   code here. Could be the case for
apple encodings */
sal/textenc/tcvtbyte.hxx:/** For those encodings only with unicode range
of 0x80 to 0xFF. */
sal/textenc/tcvtmb.cxx:/* then share many tables for different charset
encodings. */
sal/textenc/tcvtmb.cxx:/* so that extensions
that don't consider encodings */
sal/textenc/tcvtmb.cxx:/* so that extensions that don't
consider 

Bug#955549: [f2fs-dev] Bug#955549: f2fs-tools: fsck.f2fs segfaults

[Diederik de Haas]

Control: fixed -1 1.14.0-1

On zondag 7 maart 2021 20:17:39 CET Adam Borowski wrote:
> > This patch is included in the version of f2fs-tools that's currently in
> > testing and unstable (and stable backports).
> > Can you confirm the issue is resolved?
> 
> Aye, fsck no longer segfaults.  Thanks!

Thanks for getting back. 
Updating metadata with the fixed version.

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

Bug#984733: ITS: libuser

[Boyuan Yang]

Source: libuser
Version:  1:0.62~dfsg-0.4
Severity: important
X-Debbugs-CC: tzaf...@debian.org g...@debian.org

Dear package libuser maintainers in Debian,

After looking into the package you maintain (libuser, 
https://tracker.debian.org/pkg/libuser), I found that this package
received no maintainer updates in the past 6 years. As a result, I am
filing an ITS (Intent to Salvage) request against your package
according to section 5.12 in Debian's Developers' Reference [1].

My current plan is to package the latest upstream release (0.63),
clean up packaging and orphan this package to allow possible external
contribution.

Please let me know whether you are still willing to maintain this
package. According to the criteria listed at [2], I will upload a Non-
maintainer Upload (NMU) of this package onto experimental with
DELAYED/7 after 21 days (Mar 28, 2021) to continue with the package
salvaging. If you find it necessary to pause the ITS process, please
let me know immediately by replying this bug report.

[1] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
[2] https://wiki.debian.org/PackageSalvaging

-- 
Regards,
Boyuan Yang


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

Bug#984732: libuser: Please package new upstream release (0.63)

[Boyuan Yang]

Source: libuser
Version: 1:0.62~dfsg-0.4
Severity: normal
X-Debbugs-CC: tzaf...@debian.org g...@debian.org

Dear Debian libuser package maintainers,

The upstream of libuser has released a new version v0.63. Please
consider packaging it in Debian.

Thanks,
Boyuan Yang


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

Bug#982661: mame: Crash on startup

[Bernhard Übelacker]

Hello Celelibi,
does this happen with current version
in testing 0.228+dfsg.1-1, too?

Kind regards,
Bernhard

Bug#984689: ruby-vcr: DFSG violation (Hippocratic license)

[Antonio Terceiro]

On Sun, Mar 07, 2021 at 11:01:16PM +0530, Pirate Praveen wrote:
> [adding release team]
> 
> On Sun, Mar 7, 2021 at 10:49 pm, Utkarsh Gupta  wrote:
> > Hi Praveen,
> > 
> > On Sun, Mar 7, 2021 at 10:15 PM Pirate Praveen
> >  wrote:
> > >  It looks like we will have to remove ruby-vcr and we will have to
> > >  disable tests for the following packages. I don't think there is
> > >  another way, thoughts?
> > 
> > Maybe worth opening an issue upstream and discuss the cons of this
> > change or something? Or if that doesn't work out
> > and we need this
> 
> I doubt discussing with upstream will yield any possitive outcome as this is
> a specific philosophical movement.
> 
> See https://github.com/vcr/vcr/pull/792
> and
> https://github.com/vcr/vcr/issues/804
> 
> > package or something, would forking be an option?
> 
> https://github.com/vcr/vcr/blob/master/CHANGELOG.md#510-feb-5-2020
> 
> We will have to go back to 5.0 and someone will have to maintain it
> independently.
> 
> Hi Release team,
> 
> Do you think this needs to be fixed before bullseye? If yes, do you agree to
> change the reverse dependencies listed in my previous message to this bug?

I don't think that will be needed. I reverted to 5.0.0 locally, added a
few patches, and at least all of our reverse dependencies seem to pass
their tests with it:


=  Testing reverse (build) dependencies


rebuild  nanoc   ... PASS
rebuild  ruby-coveralls  ... PASS
autopkgtest  ruby-faraday... PASS
rebuild  ruby-graphlient ... PASS
rebuild  ruby-mixlib-install ... PASS
rebuild  ruby-octokit... PASS

So in principle we could fix this issue without touching anything else.


signature.asc
Description: PGP signature

Bug#984731: zfs-linux: [INTL:de] updated German debconf translation

[Helge Kreutzmann]

Package: zfs-linux
Version: 2.0.3-2
Severity: wishlist
Tags: patch l10n

Please find the updated German debconf translation for zfs-linux
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use 
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the 
German translation.

Greetings
Helge
# Translation of zfs-linux debconf templates to German
# Copyright (C) Helge Kreutzmann , 2013, 2017, 2021.
# This file is distributed under the same license as the zfs-linux package.
#
msgid ""
msgstr ""
"Project-Id-Version: zfs-linux 2.0.3-2\n"
"Report-Msgid-Bugs-To: zfs-li...@packages.debian.org\n"
"POT-Creation-Date: 2021-03-05 02:27+0800\n"
"PO-Revision-Date: 2021-03-07 20:51+0100\n"
"Last-Translator: Helge Kreutzmann \n"
"Language-Team: de \n"
"Language: de\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:1001
msgid "Abort building OpenZFS on a 32-bit kernel?"
msgstr "Bau von OpenZFS auf einem 32-Bit-Kernel abbrechen?"

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:1001
msgid "You are attempting to build OpenZFS against a 32-bit running kernel."
msgstr "Sie versuchen, OpenZFS mit einem laufenden 32-Bit-Kernel zu bauen."

#. Type: boolean
#. Description
#. Type: boolean
#. Description
#: ../zfs-dkms.templates:1001 ../zfs-dkms.templates:2001
msgid ""
"Although possible, building in a 32-bit environment is unsupported and "
"likely to cause instability leading to possible data corruption. You are "
"strongly advised to use a 64-bit kernel; if you do decide to proceed with "
"using OpenZFS on this kernel then keep in mind that it is at your own risk."
msgstr ""
"Dies ist zwar möglich, allerdings wird der Bau in einer 32-Bit-Umgebung "
"nicht unterstützt und wahrscheinlich Instabilitäten verursachen, die "
"möglicherweise Daten beschädigen. Es wird Ihnen nachdrücklich empfohlen, "
"einen 64-Bit-Kernel zu verwenden; falls Sie sich entscheiden, mit der "
"Verwendung von OpenZFS unter diesem Kernel fortzufahren, denken Sie daran, "
"dass dies auf eigenes Risiko passiert."

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:2001
msgid "Abort building OpenZFS on an unknown kernel?"
msgstr "Bau von OpenZFS auf einem unbekannten Kernel abbrechen?"

#. Type: boolean
#. Description
#: ../zfs-dkms.templates:2001
msgid ""
"You are attempting to build OpenZFS against a running kernel that could not "
"be identified as 32-bit or 64-bit. If you are not completely sure that the "
"running kernel is a 64-bit one, you should probably stop the build."
msgstr ""
"Sie versuchen, OpenZFS mit einem Kernel zu bauen, der weder als 32-Bit noch "
"als 64-Bit identifiziert werden konnte. Falls Sie sich nicht absolut sicher "
"sind, dass es sich beim laufende Kernel um einen 64-Bit-Kernel handelt, "
"sollten Sie eventuell den Bau abbrechen."

#. Type: note
#. Description
#: ../zfs-dkms.templates:3001
msgid "Licenses of OpenZFS and Linux are incompatible"
msgstr "Lizenzen von OpenZFS und Linux sind inkompatibel"

#. Type: note
#. Description
#: ../zfs-dkms.templates:3001
msgid ""
"OpenZFS is licensed under the Common Development and Distribution License "
"(CDDL), and the Linux kernel is licensed under the GNU General Public "
"License Version 2 (GPL-2). While both are free open source licenses they are "
"restrictive licenses. The combination of them causes problems because it "
"prevents using pieces of code exclusively available under one license with "
"pieces of code exclusively available under the other in the same binary."
msgstr ""
"OpenZFS ist unter der »Common Development and Distribution License (CDDL), "
"der Kernel unter der GNU General Public License Version 2 (GPL-2) "
"lizenziert. Obwohl beide freie Open-Source-Lizenzen sind, sind sie "
"restriktiv. Die Kombination beider führt zu Problemen, da sie verhindern, "
"das Programmcode, der exklusiv unter einer Lizenz steht, mit Code im "
"gleichen Programm zusammen verwandt wird, der exklusiv unter der anderen "
"Lizenz steht."

#. Type: note
#. Description
#: ../zfs-dkms.templates:3001
msgid ""
"You are going to build OpenZFS using DKMS in such a way that they are not "
"going to be built into one monolithic binary. Please be aware that "
"distributing both of the binaries in the same media (disk images, virtual "
"appliances, etc) may lead to infringing."
msgstr ""
"Sie werden OpenZFS mittels DKMS derart bauen, dass sie nicht zusammen in ein "
"monolithisches Programm gebaut werden. Bitte berücksichtigen Sie, dass der "
"Vertrieb beider Programme auf dem gleichen Medium (Plattenabbild, virtuelles "
"Gerät usw.) zu Urheberrechtsverletzungen führen kann."

#. Type: boolean
#. Description
#: ../zfsutils-linux.templates:1001
msgid "Scrub OpenZFS pools periodically?"
msgstr "Periodisch „scrub“ bei 

Bug#984730: rust-sequoia-autocrypt: autopkgtest needs update for new version of rust-sequoia-openpgp: output changed

[Paul Gevers]

Source: rust-sequoia-autocrypt
Version: 0.23.0-2
Severity: serious
Tags: sid bullseye
User: debian...@lists.debian.org
Usertags: needs-update
Control: affects -1 src:rust-sequoia-openpgp

[X-Debbugs-CC: debian...@lists.debian.org,
rust-sequoia-open...@packages.debian.org]

Dear maintainer(s),

With a recent upload of rust-sequoia-openpgp the autopkgtest of
rust-sequoia-autocrypt fails in testing when that autopkgtest is run
with the binary packages of rust-sequoia-openpgp from unstable. It
passes when run with only packages from testing. In tabular form:

   passfail
rust-sequoia-openpgp   from testing1.1.0-1
rust-sequoia-autocrypt from testing0.23.0-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of
rust-sequoia-openpgp to testing [1]. Of course, rust-sequoia-openpgp
shouldn't just break your autopkgtest (or even worse, your package), but
it seems to me that the change in rust-sequoia-openpgp was intended and
your package needs to update to the new situation.

If this is a real problem in your package (and not only in your
autopkgtest), the right binary package(s) from rust-sequoia-openpgp
should really add a versioned Breaks on the unfixed version of (one of
your) package(s). Note: the Breaks is nice even if the issue is only in
the autopkgtest as it helps the migration software to figure out the
right versions to combine in the tests.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rust-sequoia-openpgp

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-sequoia-autocrypt/10911145/log.gz

failures:

 test::autocrypt_header_new stdout 
thread 'test::autocrypt_header_new' panicked at 'assertion failed:
`(left == right)`
  left: `"3E8877C877274692975189F5D03F6F865226FE8B"`,
 right: `"3E88 77C8 7727 4692 9751  89F5 D03F 6F86 5226 FE8B"`',
src/lib.rs:1058:9
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.48.0/library/std/src/panicking.rs:483
   1: std::panicking::begin_panic_fmt
 at /usr/src/rustc-1.48.0/library/std/src/panicking.rs:437
   2: sequoia_autocrypt::test::autocrypt_header_new
 at ./src/lib.rs:1058
   3: sequoia_autocrypt::test::autocrypt_header_new::{{closure}}
 at ./src/lib.rs:1034
   4: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.48.0/library/core/src/ops/function.rs:227
   5: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.48.0/library/core/src/ops/function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a
verbose backtrace.


failures:
test::autocrypt_header_new

test result: FAILED. 6 passed; 1 failed; 0 ignored; 0 measured; 0
filtered out



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983662: openvpn: autopkgtest always fails on qemu testbed

[Bernhard Schmidt]

Hi,
> Dear Bernhard,
> Thank you for sending a patch.
> It was cleanly applied to openvpn/sid (2.5.1-1), and the test results were
> 
> server-setup-with-ca FAIL non-zero exit status 1
> server-setup-with-static-key PASS
> 
> Full test log is attached.
> Best regards, Ryutaroh

Hrm, so it seems to happen here

info "Setup the CA and the server keys"
./easyrsa init-pki
./easyrsa build-ca nopass 2>/dev/null
./easyrsa build-server-full server nopass 2>/dev/null
./easyrsa gen-dh 2>/dev/null

info "Create the OpenVPN server config file"

one of the easyrsa commands fails, and since we redirect stderr to
/dev/null we are not seeing any error message. Could you drop the
redirects and check the output?

I will try to find some time myself, but I will be moving next week, so
I might be away from the computer.

Bernhard

Bug#984728: ttyd: Invalid Vcs-Browser and Vcs-Git links

[Daniel Baumann]

close 984728
thanks

On 3/7/21 8:14 PM, Boyuan Yang wrote:
> When accessing the Vcs-* links for package ttyd in Debian
> (https://git.progress-linux.org/users/daniel.baumann/debian/packages/ttyd
> ), I get the error message "No repositories found".

over the weekend I've re-generated my git server with bullseye and
syncing & reviewing the repos as we speak.. it will be "back" shortly.

Regards,
Daniel

Bug#984650: update-initramfs fails when /etc/systemd/network/99-default.link is symlink to /dev/null

[Ben Hutchings]

Control: tag -1 - moreinfo
Control: retitle -1 update-initramfs fails if there is a symlink to /dev/zero 
in /etc/systemd/network
Control: reassign -1 udev
Control: severity -1 minor

Frederik Lindenaar  wrote:
> Thanks for the quick reply. I am not sure how I could have mixed
> these two up but did a quick test with cp just now and the problem
> indeed looks like mixing up /dev/zero and /dev/null (I have no way to
> check that anymore though).
> 
> Nevertheless the result was very confusing (a full disk) so might
> still be good to check somehow

So I'm updating the status.  Also reassigning this to udev, as that is
the package that actually does the copying of /etc/systemd/network.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.


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

Bug#983153: calendar: Segmentation fault

[Bernhard Übelacker]

Dear Maintainer,
this crash happens because this executable is expecting
at command line a parameter month and year.
Doing so produces a calendar at stdout in postscript format.

Kind regards,
Bernhard

(gdb) bt
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1  0x5629626651b4 in atoi (__nptr=) at 
/usr/include/stdlib.h:363
#2  main (argc=1, argv=0x7ffe5c59e508) at calendar.cpp:621

https://sources.debian.org/src/pluto-lunar/0.0~git20180825.e34c1d1-1/calendar.cpp/#L621

# Bullseye/testing amd64 qemu VM 2021-03-07


apt update
apt dist-upgrade


apt install systemd-coredump gdb pluto-lunar pluto-lunar-dbgsym



benutzer@debian:~$ /usr/lib/pluto/lunar/calendar
Speicherzugriffsfehler (Speicherabzug geschrieben)



root@debian:~# journalctl -e
Mär 07 16:05:51 debian kernel: calendar[1010]: segfault at 0 ip 
7f3181c41518 sp 7ffe5c59e380 error 4 in 
libc-2.31.so[7f3181c26000+14b000]
Mär 07 16:05:51 debian kernel: Code: 41 54 45 31 e4 55 53 48 83 ec 28 48 89 74 
24 08 85 c9 0f 85 c2 02 00 00 83 ff 01 0f 84 81 01 00 00 83 ff 24 0f 87 78 01 
00 00 <49> 0f be 55 00 49 8b 48 68 4c 89 eb 48 89 d0 f6 44 51 01 20 74 15
Mär 07 16:05:51 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Mär 07 16:05:51 debian systemd[1]: Started Process Core Dump (PID 1011/UID 0).
Mär 07 16:05:51 debian systemd-coredump[1012]: Process 1010 (calendar) of user 
1000 dumped core.

Stack trace of thread 1010:
#0  0x7f3181c41518 n/a 
(libc.so.6 + 0x40518)
#1  0x5629626651b4 n/a 
(calendar + 0x21b4)
#2  0x7f3181c27d0a 
__libc_start_main (libc.so.6 + 0x26d0a)
#3  0x56296266541a n/a 
(calendar + 0x241a)





root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Sun 2021-03-07 16:05:51 CET1010  1000  1000  11 present   
/usr/lib/pluto/lunar/calendar

root@debian:~# coredumpctl gdb 1010
...
Core was generated by `/usr/lib/pluto/lunar/calendar'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
292 ../stdlib/strtol_l.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1  0x5629626651b4 in ?? ()
#2  0x7f3181c27d0a in __libc_start_main (main=0x562962665190, argc=1, 
argv=0x7ffe5c59e508, init=, fini=, 
rtld_fini=, stack_end=0x7ffe5c59e4f8) at ../csu/libc-start.c:308
#3  0x56296266541a in ?? ()


root@debian:~# export DEBUGINFOD_URLS="https://debuginfod.debian.net;
root@debian:~# coredumpctl gdb 1010

(gdb) bt
#0  __GI_strtol_l_internal (nptr=0x0, endptr=0x0, base=10, group=0, 
loc=0x7f3181dc04a0 <_nl_global_locale>) at ../stdlib/strtol_l.c:292
#1  0x5629626651b4 in atoi (__nptr=) at 
/usr/include/stdlib.h:363
#2  main (argc=1, argv=0x7ffe5c59e508) at calendar.cpp:621

https://sources.debian.org/src/pluto-lunar/0.0~git20180825.e34c1d1-1/calendar.cpp/#L621



/usr/lib/pluto/lunar/calendar 03 2021 > test.ps

Bug#982171: libint breaks psi4 autopkgtest: 'str' object is not callable; perhaps you missed a comma?

[Graham Inggs]

psi4 1:1.3.2+dfsg-2 and libint 1.2.1-5 uploaded which should be able
to migrate together.

Bug#984728: ttyd: Invalid Vcs-Browser and Vcs-Git links

[Boyuan Yang]

Source: ttyd
Severity: normal
Version: 1.6.3-3
X-Debbugs-CC: dan...@debian.org

Dear Debian ttyd maintainer,

When accessing the Vcs-* links for package ttyd in Debian
(https://git.progress-linux.org/users/daniel.baumann/debian/packages/ttyd
), I get the error message "No repositories found". This indicates that
the git package repo either does not exist or cannot be accessed.
Please consider fixing it.

Thanks,
Boyuan Yang


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

Bug#984727: installation-reports: just an installation report

[Joseph Livesey]

Package: installation-reports
Severity: wishlist

-- Package-specific info:

Boot method: USB
Image version: debian-mac-10.8.0-amd64-netinst.iso 
https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/ 2021-02-06
Date: 

Machine: MacBook3,1 (Nov 2007)
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [ ]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]

Comments/Problems:




-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190702+deb10u8"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 
PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 
GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: 00:02.1 Display controller [0380]: Intel Corporation Mobile 
GM965/GL960 Integrated Graphics Controller (secondary) [8086:2a03] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #4 [8086:2834] (rev 03)
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #5 [8086:2835] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1a.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB2 EHCI Controller #2 [8086:283a] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) 
HD Audio Controller [8086:284b] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 1 [8086:283f] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 5 [8086:2847] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.5 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) 
PCI Express Port 6 [8086:2849] (rev 03)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #1 [8086:2830] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.1 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #2 [8086:2831] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.2 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB UHCI Controller #3 [8086:2832] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: Kernel driver in use: uhci_hcd
lspci -knn: Kernel modules: uhci_hcd
lspci -knn: 00:1d.7 USB controller [0c03]: Intel Corporation 82801H (ICH8 
Family) USB2 EHCI Controller #1 [8086:2836] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI 
Bridge [8086:2448] (rev f3)
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801HM (ICH8M) LPC 
Interface Controller [8086:2815] (rev 03)
lspci -knn: Subsystem: Apple Inc. Device [106b:00a1]
lspci -knn: 00:1f.1 IDE interface [0101]: Intel Corporation 

Bug#983242: wine-development recent upgrade (5.6-1?) broke levelator.exe

[Bernhard Übelacker]

Dear Maintainer,
this issue might be following upstream bug [1].

Because of that winepath "emits DOS-style instead of
UNIX-style line endings".

Therefore the carriage return character got part of
the filename and could therefore not be found.

This got fixed already in upstream wine-5.7.

Kind regards,
Bernhard

[1] https://bugs.winehq.org/show_bug.cgi?id=48937

# Bullseye/testing amd64 qemu VM 2021-03-07


dpkg --add-architecture i386
apt update
apt dist-upgrade


apt install systemd-coredump sddm xserver-xorg openbox mc ffmpeg sshfs dos2unix



http://www.conversationsnetwork.org/levelator
wget http://cdn.conversationsnetwork.org/LevelatorSetup-2.1.1.exe
md5sum LevelatorSetup-2.1.1.exe 
55b968fc015c11b210be6c1395796d26  LevelatorSetup-2.1.1.exe




apt install wine




export DISPLAY=:0
wine --version
# 5.0.3-3
wine wineboot
wineserver -k

wine LevelatorSetup-2.1.1.exe
wineserver -k


ffmpeg -f lavfi -i "sine=frequency=1000:duration=20" test.wav

WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
# wine c:/Program Files (x86)/Levelator/levelator.exe Z:\home\benutzer\test.wav
wineserver -k




dpkg --purge wine libwine:amd64 libwine:i386 fonts-wine wine32:i386 wine64
# activate unstable in sources.list
apt update
apt install wine-development






wine --version
wine-5.6 (Debian 5.6-1)
wine wineboot
wineserver -k

WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
# wine c:/Program Files (x86)/Levelator/levelator.exe Z:\home\benutzer\test.wav

Message Box:
The Conversati...twork Levelator
Can't open the source file: Z:\home\benutzer\test.wav

wineserver -k

winepath --windows /home/benutzer/test.wav | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0d 0a |\test.wav..|
001b






dpkg --purge fonts-wine libwine-development:amd64 libwine-development:i386 
wine-development wine32-development:i386 wine64-development





# Cached packages from upstream wine: 
https://dl.winehq.org/wine-builds/debian/dists/buster
mkdir /wine-bin
sshfs -o allow_other,uid=1000,gid=1000 bernhard@...:/wine-bin /wine-bin

mkdir -p /home/bernhard/data/entwicklung/2021/wine
ln -s /wine-bin/wine-git /home/bernhard/data/entwicklung/2021/wine/wine-git


ln -s /wine-bin $HOME/
export PATH_ORIG=$PATH



export 
PATH="$HOME/wine-bin/winehq-devel/winehq-devel_5.5~buster_amd64/opt/wine-devel/bin:$PATH_ORIG"
wine --version
wine-5.5
wine wineboot
wineserver -k
WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
--> seems to work



export 
PATH="$HOME/wine-bin/winehq-devel/winehq-devel_5.6~buster_amd64/opt/wine-devel/bin:$PATH_ORIG"
wine --version
wine-5.6
wine wineboot
wineserver -k
WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
--> Can't open the source file: Z:\home\benutzer\test.wav

winepath --windows /home/benutzer/test.wav | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0d 0a |\test.wav..|
001b
winepath --windows /home/benutzer/test.wav | dos2unix | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0a|\test.wav.|
001a



export 
PATH="$HOME/wine-bin/winehq-devel/winehq-devel_5.7~buster_amd64/opt/wine-devel/bin:$PATH_ORIG"
wine --version
wine-5.7
wine wineboot
wineserver -k
WINEPATH=$(winepath --windows /home/benutzer/test.wav)
wine "c:/Program Files (x86)/Levelator/levelator.exe" $WINEPATH
--> seems to work

winepath --windows /home/benutzer/test.wav | hexdump -C
  5a 3a 5c 68 6f 6d 65 5c  62 65 6e 75 74 7a 65 72  |Z:\home\benutzer|
0010  5c 74 65 73 74 2e 77 61  76 0a|\test.wav.|
001a


https://bugs.winehq.org/show_bug.cgi?id=48937

Bug#984726: qemu: Please compile with JACK support

[Michael Tokarev]

07.03.2021 21:42, Sander van Grieken wrote:

Package: qemu
Version: 1:5.2+dfsg-6
Severity: wishlist
Tags: patch
X-Debbugs-Cc: san...@outrightsolutions.nl

Dear Maintainer,

Please enable JACK support for QEMU.
This feature is present in QEMU since 5.1 and pretty much the only good option
for low-latency audio


How well does it actually work? QEMU itself has quite large latency in audio 
path,
or at least had in the past, and generally situation with audio was problematic.

I don't disagree with your decision, just trying to understand.

Dunno if it's a good idea to perform this change now for bullseye,
while we're in a freeze. To me this does not look right, maybe next
debian release (and backports, ofcourse) will do.

BTW, your patch is incomplete, - before enabling jack in audio-drv-list,
you have to add libjack-dev to Build-Depends. I'll take care of that.

Thanks!

/mjt

Bug#984602: fix

[Thomas Lange]

This is the fix
https://github.com/faiproject/fai/commit/d4a1e53b6290b450a38749c5a2b7d5ff0b4f8676
-- 
viele Grüße Thomas

Bug#984726: qemu: Please compile with JACK support

[Sander van Grieken]

Package: qemu
Version: 1:5.2+dfsg-6
Severity: wishlist
Tags: patch
X-Debbugs-Cc: san...@outrightsolutions.nl

Dear Maintainer,

Please enable JACK support for QEMU.
This feature is present in QEMU since 5.1 and pretty much the only good option
for low-latency audio


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

Kernel: Linux 5.11.4+ (SMP w/12 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- c/debian/control-in 2021-03-07 19:37:10.492072355 +0100
+++ a/debian/control-in 2021-03-03 11:43:39.467417451 +0100
@@ -22,7 +22,7 @@
  libcapstone-dev (>> 4.0.2~),
 # --enable-linux-aio   linux-*
  libaio-dev [linux-any],
-# --audio-drv-list=pa,alsa,oss linux-*
+# --audio-drv-list=pa,alsa,oss,jacklinux-*
 # --audio-drv-list=pa,oss  kfreebsd-*
  libpulse-dev,
  libasound2-dev [linux-any],

Bug#984719: lintian: add check for incomplete XS-Go-Import-Path

[Felix Lechner]

Hi Alexandre,

On Sun, Mar 7, 2021 at 8:54 AM Alexandre Viau  wrote:
>
> XS-Go-Import-Path: gopkg.in/asn1-ber.v1,
>github.com/go-asn1-ber/asn1-ber
>
> And it installs files at both
> `/usr/share/gocode/src/gopkg.in/asn1-ber.v1` and
> `/usr/share/gocode/src/github.com/go-asn1-ber`

Should the second path be
/usr/share/gocode/src/github.com/go-asn1-ber/asn1-ber instead? (Please
note the extra final component in the file list at the very bottom of
this message.) Also, why is it a symbolic link, please? Should Lintian
merely verify that the path is present so we catch when there is a
link and not a folder?

As a side note, I had to download the installable package

golang-gopkg-asn1-ber.v1-dev_1.5.1-1_all.deb

in order to take a look at it. I tried examining the paths on
packages.d.o [1] but only saw "No such package in this suite on this
architecture." Do you know why that might be happening? Thanks!

Kind regards
Felix Lechner

[1] https://packages.debian.org/sid/all/golang-gopkg-asn1-ber.v1-dev/filelist

* * *

➤ dpkg -c /tmp/golang-gopkg-asn1-ber.v1-dev_1.5.1-1_all.deb
drwxr-xr-x root/root 0 2020-08-29 13:08 ./
drwxr-xr-x root/root 0 2020-08-29 13:08 ./usr/
drwxr-xr-x root/root 0 2020-08-29 13:08 ./usr/share/
drwxr-xr-x root/root 0 2020-08-29 13:08 ./usr/share/doc/
drwxr-xr-x root/root 0 2020-08-29 13:08
./usr/share/doc/golang-gopkg-asn1-ber.v1-dev/
-rw-r--r-- root/root   769 2020-08-29 13:08
./usr/share/doc/golang-gopkg-asn1-ber.v1-dev/changelog.Debian.gz
-rw-r--r-- root/root  1494 2020-08-29 13:08
./usr/share/doc/golang-gopkg-asn1-ber.v1-dev/copyright
drwxr-xr-x root/root 0 2020-08-29 13:08 ./usr/share/gocode/
drwxr-xr-x root/root 0 2020-08-29 13:08 ./usr/share/gocode/src/
drwxr-xr-x root/root 0 2020-08-29 13:08
./usr/share/gocode/src/github.com/
drwxr-xr-x root/root 0 2020-08-29 13:08
./usr/share/gocode/src/github.com/go-asn1-ber/
drwxr-xr-x root/root 0 2020-08-29 13:08 ./usr/share/gocode/src/gopkg.in/
drwxr-xr-x root/root 0 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/
-rw-r--r-- root/root 14751 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/ber.go
-rw-r--r-- root/root  4856 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/ber_test.go
-rw-r--r-- root/root   310 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/content_int.go
-rw-r--r-- root/root  2505 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/generalizedTime.go
-rw-r--r-- root/root  1819 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/generalizedTime_test.go
-rw-r--r-- root/root48 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/go.mod
-rw-r--r-- root/root   793 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/header.go
-rw-r--r-- root/root  3477 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/header_test.go
-rw-r--r-- root/root  2603 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/identifier.go
-rw-r--r-- root/root 10997 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/identifier_test.go
-rw-r--r-- root/root  2026 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/length.go
-rw-r--r-- root/root  4174 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/length_test.go
-rw-r--r-- root/root  3150 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/real.go
-rw-r--r-- root/root   536 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/real_test.go
-rw-r--r-- root/root  2151 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/string_test.go
-rw-r--r-- root/root  7574 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/suite_test.go
drwxr-xr-x root/root 0 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/
-rw-r--r-- root/root13 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc1.ber
-rw-r--r-- root/root 9 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc10.ber
-rw-r--r-- root/root11 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc11.ber
-rw-r--r-- root/root 3 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc12.ber
-rw-r--r-- root/root11 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc13.ber
-rw-r--r-- root/root 7 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc14.ber
-rw-r--r-- root/root14 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc15.ber
-rw-r--r-- root/root14 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc16.ber
-rw-r--r-- root/root22 2020-08-29 13:08
./usr/share/gocode/src/gopkg.in/asn1-ber.v1/tests/tc17.ber
-rw-r--r-- root/root 5 2020-08-29 13:08

Bug#984710: hamlib: tcl-hamlib.install hardcodes Tcl version 8.6

[Christoph Berg]

Re: Adrian Bunk
> $ cat debian/tcl-hamlib.install
> debian/tmp/usr/lib/*/tcl8.6/Hamlib/hamlibtcl-4.*.so
> debian/tmp/usr/lib/*/tcl8.6/Hamlib/hamlibtcl.so
> debian/tmp/usr/lib/*/tcl8.6/Hamlib/pkgIndex.tcl

That is incidentally already fixed in git, will upload now.

Christoph

Bug#984725: openjdk-11-jre-dcevm: incompatible with newest openjdk-11-jre 11.0.11+4-1

[Michael Meier]

Package: openjdk-11-jre-dcevm
Version: 11.0.10+1-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: schissdra...@rmm.li

After the last update of openjdk-11-jre from 11.0.10+9-1 to 11.0.11+4-1 dcevm
can't be used anymore. The error is:
java -dcevm
:(
[0.040s][error][class] Name nativeParkEventPointer should be in the SymbolTable
since its class is loaded
Error occurred during initialization of VM
Invalid layout of well-known class: java.lang.Thread





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

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

Versions of packages openjdk-11-jre-dcevm depends on:
ii  libc62.31-9
ii  openjdk-11-jre-headless  11.0.11+4-1

openjdk-11-jre-dcevm recommends no packages.

openjdk-11-jre-dcevm suggests no packages.

Bug#846950: Merge request for nfs-utils to fix bugs #846950, #849942, #849608

[Felix Lechner]

Control: unmerge 846950
Control: severity 846950 grave

Hi Salvatore,

On Sat, Mar 6, 2021 at 11:40 PM Salvatore Bonaccorso  wrote:
>
> Can you check which ones the release team accepts

I prepared a minimal merge request [1] for the typo in
debian/nfs-utils_env.sh. Among the many issues addressed in Joachim's
MR [2], that one is the hardest part to track down. My MR corrects
only the typo and, being two lines, should be fixed in bullseye.

The release team would not discuss the matter on IRC and asked for a
bug. I therefore unmerged the bug that addressed the typo and,
assuming your consent, raised the severity to 'grave'. The bug was at
that level before an administrative downgrade. Thanks for looking into
this!

Kind regards
Felix Lechner

[1] https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/6
[2] https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/5

Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

[Surla, Sai Kalyan]

Hi Paul,

We already tried with version 0.6.75-1. Also compiled the latest code available 
and tried with it, still the same results.

Please find the changes in the attached file. (readpst.c line no. : 1238)

ARC headers are kind of email authentication headers. Authenticated Received 
Chain (ARC) creates a mechanism for individual Internet Mail Handlers to add 
their authentication assessment to a message's ordered set of handling results. 
For more details please refer the following rfc 
https://tools.ietf.org/html/rfc8617.

For some security reasons we cannot share the original , we will once discuss 
and let you know, if possible we will try to share the inhouse sample pst. We 
will let you know about the PST in the next couple of days
Meanwhile our observation is if the headers start with the following headers 
(Date, From, To, Content-Type, MIME-Version, Microsoft Mail Internet Headers, 
Received, Subject and some other headers) it is treated as bogus, this email is 
starting with some header which is not one of the listed.

Thank you
Sai Kalyan


From: Paul Wise 
Sent: 06 March 2021 08:12 AM
To: Surla, Sai Kalyan ; 984...@bugs.debian.org
Subject: Re: Bug#984581: pst-utils: Fails to extract email addresses for emails 
having ARC headers from PST file

Control: tags -1 + moreinfo

On Fri, 2021-03-05 at 23:06 +0530, sai kalyan wrote:

> Version: 0.6.71-0.1

Could you test version 0.6.75-1 from Debian bullseye?

> Tags: patch

Could you attach your patch to the bug report?

> for some mails where the transport headers contain ARC headers

Could you provide some information about what ARC headers are?

> the email addresses are not extracted from the PST and only usernames
> are available in the MIME content of emails that are extracted.

Please supply an example PST file that this problem occurs with.

--
bye,
pabs

https://wiki.debian.org/PaulWise
/***
 * readpst.c
 * Part of the LibPST project
 * Written by David Smith
 *dav...@earthcorp.com
 */

#include "define.h"
#include "lzfu.h"
#include "msg.h"

#define OUTPUT_TEMPLATE "%s.%s"
#define OUTPUT_KMAIL_DIR_TEMPLATE ".%s.directory"
#define KMAIL_INDEX "../.%s.index"
#define SEP_MAIL_FILE_TEMPLATE "%i%s"

// max size of the c_time char*. It will store the date of the email
#define C_TIME_SIZE 500

struct file_ll {
char *name[PST_TYPE_MAX];
char *dname;
FILE * output[PST_TYPE_MAX];
int32_t stored_count;
int32_t item_count;
int32_t skip_count;
};

int   grim_reaper();
pid_t try_fork(char* folder);
void  process(pst_item *outeritem, pst_desc_tree *d_ptr);
void  write_email_body(FILE *f, char *body);
void  removeCR(char *c);
void  usage();
void  version();
void  mk_kmail_dir(char* fname);
int   close_kmail_dir();
void  mk_recurse_dir(char* dir);
int   close_recurse_dir();
void  mk_separate_dir(char *dir);
int   close_separate_dir();
void  mk_separate_file(struct file_ll *f, int32_t t, char *extension, int 
openit);
void  close_separate_file(struct file_ll *f);
char* my_stristr(char *haystack, char *needle);
void  check_filename(char *fname);
int   acceptable_ext(pst_item_attach* attach);
void  write_separate_attachment(char f_name[], pst_item_attach* attach, int 
attach_num, pst_file* pst);
void  write_embedded_message(FILE* f_output, pst_item_attach* attach, char 
*boundary, pst_file* pf, int save_rtf, char** extra_mime_headers);
void  write_inline_attachment(FILE* f_output, pst_item_attach* attach, char 
*boundary, pst_file* pst);
int   valid_headers(char *header);
void  header_has_field(char *header, char *field, int *flag);
void  header_get_subfield(char *field, const char *subfield, char 
*body_subfield, size_t size_subfield);
char* header_get_field(char *header, char *field);
char* header_end_field(char *field);
void  header_strip_field(char *header, char *field);
int   test_base64(char *body, size_t len);
void  find_html_charset(char *html, char *charset, size_t charsetlen);
void  find_rfc822_headers(char** extra_mime_headers);
void  write_body_part(FILE* f_output, pst_string *body, char *mime, char 
*charset, char *boundary, pst_file* pst);
void  write_schedule_part_data(FILE* f_output, pst_item* item, const char* 
sender, const char* method);
void  write_schedule_part(FILE* f_output, pst_item* item, const char* 
sender, const char* boundary);
void  write_normal_email(FILE* f_output, char f_name[], pst_item* item, int 
mode, int mode_MH, pst_file* pst, int save_rtf, int embedding, char** 
extra_mime_headers);
void  write_vcard(FILE* f_output, pst_item *item, pst_item_contact* 
contact, char comment[]);
int   write_extra_categories(FILE* f_output, pst_item* item);
void  write_journal(FILE* f_output, pst_item* item);
void  write_appointment(FILE* f_output, pst_item *item);
void  create_enter_dir(struct file_ll* f, pst_item