Bug#931400: RFP: pcynlitx -- Innovative IDE for Multithreading

[Bagas Sanjaya]

Package: wnpp
Severity: wishlist

Package name: pcynlitx
Version: 0.0~git20190606
Upstream Author: Erkam Murat Bozkurt 
License: GPLv3
URL: http://www.pcynlitx.tech
Description: Innovative IDE for Multithreading

From project's homepage:

Pcynlitx is an outcome of a scientific research study that is carried out by 
Erkam Murat Bozkurt who is a research
engineer in Istanbul / Turkey. Pcynlitx platform has been developed based on a 
new idea. This idea is to develop a
software that can write codes in a collaboration with its user. By this way, 
Pcynlitx acts as a separate intelligent
actor simplifying the multi-threaded software development process. Basically, 
pcynlitx is a code generator which can be
programmed by the programmer. More specifically, It receives the requirements 
of the software to be developed from the
programmer by means of a descriptor file and then, writes a C++ class library ( 
a thread library ).

Why Pcynlitx?
- More control on threads : Give a certain number to each thread and control it 
with that numbers.
- Autonom thread management : on each operation, thread management tools record 
the numbers of the threads and provide
the execution of the threads according to programmer’s directives.
- Easy to use : there is no need to learn any new coding style. It is only C++.
- Coding Simplicity : Pcynlitx makes abstraction to C++ threads and many 
operation are performed on the inside of the
library constructed by
- Strong Documentation : You can find out many tutorial and technical documents 
on the web site
- Deterministic Multi Threading : Pcynlitx provides input-output determinisim

Features:
- Code editing : You can use pcynlitx as a code editor. However, it is more 
than a code editor. Pcynlitx interracts
with its user and it is a part of software development process.
- The interraction with the user : You can enter your preferences to the 
pcynlitx by means of its menus. In each step
of software development process, pcynlitx asists the programmers
- Directory Tree View : You can search over the directories by means of the 
directory tree view option.
- Project management : You can build and manage your multi-thread application 
directly with pcynlitx.
- Special Library Construction : You can build your multi-threading library 
according to your reqirements
- Compiler : Pcynlitx uses gcc compiler as its compiler tool chain and 
wxWidgets as its graphical user interface
toolkit.
- License : GNU GPLv3


Copyright Notice:
- An application to the US Copyright office has been performed for the modified 
version of the source code of the project
- A certificate of registration has been received from US Copyright office for 
the source code of the project
- A certificate of registration has been received from the copyright office of 
Turkey

Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool

[Mishra, Gaurav]

Hello,

Just writing in to ask if you get a chance to test the package again.

The debian/control file is updated according to Debian Sid (unstable) and the 
package was pushed to https://mentors.debian.net/package/fossology.

Please let me know if I am missing something in the package.

With best regards,
Gaurav Mishra

-Original Message-
From: [ext] Mishra, Gaurav  
Sent: 17 May 2019 14:20
To: Paul Wise ; 926...@bugs.debian.org
Cc: Adam Borowski 
Subject: Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool

Hello Paul,

> -Original Message-
> From: Paul Wise  
> Sent: 17 May 2019 08:30
> To: Mishra, Gaurav (IOT DS AA DTS CNP CT) ; 
> 926...@bugs.debian.org
> Cc: Adam Borowski 
> Subject: Re: Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license 
> compliance tool
>
> On Thu, Apr 25, 2019 at 5:18 PM Gaurav Mishra wrote:
>
> > I have updated the dependencies and made them specific to Debian Stretch.
>
> New and reintroduced packages enter Debian through unstable, so your initial 
> package should be built and tested on unstable. Once it reaches testing after 
> the buster freeze and release is done, then it can be added to the buster and 
> stretch backports.
>
> https://backports.debian.org/Contribute/

Sorry, I missed the point. I have updated the control file to match the package 
versions for Debian unstable and regenerated the source package (tested on 
debian:unstable docker image as I cannot find any CD to create a VM).

The same has been pushed to https://mentors.debian.net/package/fossology

> PS: in case you haven't read it yet, the extra procedures for reintroducing 
> packages are here:
>
> https://www.debian.org/doc/manuals/developers-reference/ch05.html#reintroducing-pkgs

As far as I know, I have followed all the steps mentioned in the guides. If I 
missed anything, please correct me.

> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise

With best regards,
Gaurav Mishra

Bug#931399: zram-setup@ ConditionPathExists= (only run when zram is configured by udisks2)

[Trent W. Buck]

Package: udisks2
Version: 2.8.1-4
Severity: minor
File: /lib/systemd/system/zram-setup@.service
Tags: patch

The core package (i.e. udisk2, not udisks2-zram) ships a udev rule and a 
systemd unit to configure zram.
These fire on "modprobe zram", even when udisks2-zram isn't installed, and 
udisks-specific config file doesn't exist.
Please add the following line to modules/zram/data/zram-setup@.service, so it 
will only fire when it should:

[Unit]
ConditionPathExists=/usr/local/lib/zram.conf.d/%i-env

You might also want to change this rule so it won't report an error when SWAP=n:

-ExecStart=-/bin/sh -c '[ "$SWAP" = "y" ] && mkswap /dev/%i && swapon 
/dev/%i'
+ExecStart=/bin/sh -c 'if [ "$SWAP" = "y" ]; then mkswap /dev/%i && swapon 
/dev/%i; fi'

You might also like the confinement suggestions of "systemd-analyze security 
zram-setup@".

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (500, 
'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages udisks2 depends on:
ii  dbus   1.12.16-1
ii  libacl12.2.53-4
ii  libatasmart4   0.19-5
ii  libblockdev-fs22.20-7
ii  libblockdev-loop2  2.20-7
ii  libblockdev-part2  2.20-7
ii  libblockdev-swap2  2.20-7
ii  libblockdev-utils2 2.20-7
ii  libblockdev2   2.20-7
ii  libc6  2.28-10
ii  libglib2.0-0   2.58.3-2
ii  libgudev-1.0-0 232-2
ii  libmount1  2.33.1-0.1
ii  libpam-systemd 241-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libsystemd0241-5
ii  libudisks2-0   2.8.1-4
ii  parted 3.2-25
ii  udev   241-5

Versions of packages udisks2 recommends:
ii  dosfstools   4.1-2
ii  e2fsprogs1.44.5-1
ii  eject2.1.5+deb1+cvs20081104-13.2
ii  exfat-utils  1.3.0-1
ii  libblockdev-crypto2  2.20-7
ii  ntfs-3g  1:2017.3.23AR.3-3
ii  policykit-1  0.105-25

Versions of packages udisks2 suggests:
ii  btrfs-progs  4.20.1-2
pn  f2fs-tools   
pn  libblockdev-mdraid2  
pn  mdadm
pn  nilfs-tools  
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-vdo  
pn  udisks2-zram 
pn  xfsprogs 

-- no debconf information
Demonstrating the initial problem:

bash5$ systemctl status | head -2
● goll
State: running
bash5$ dpkg-query -W udisks2 udisks2-zram
udisks2 2.8.1-4
udisks2-zram
bash5$ sudo modprobe zram
bash5$ systemctl status zram-setup@zram0
● zram-setup@zram0.service - Setup zram based device zram0
   Loaded: loaded (/lib/systemd/system/zram-setup@.service; static; vendor 
preset: enabled)
   Active: active (exited) since Thu 2019-07-04 11:20:11 AEST; 17s ago
  Process: 1023 ExecStart=/bin/sh -c echo $ZRAM_NUM_STR > 
/sys/class/block/zram0/max_comp_streams (code=exited, status=0/SUCCESS)
  Process: 1028 ExecStart=/bin/sh -c echo $ZRAM_DEV_SIZE > 
/sys/class/block/zram0/disksize (code=exited, status=1/FAILURE)
  Process: 1031 ExecStart=/bin/sh -c [ "$SWAP" = "y" ] && mkswap /dev/zram0 
&& swapon /dev/zram0 (code=exited, status=1/FAILURE)
 Main PID: 1031 (code=exited, status=1/FAILURE)

Jul 04 11:20:11 goll systemd[1]: Starting Setup zram based device zram0...
Jul 04 11:20:11 goll sh[1028]: /bin/sh: 1: echo: echo: I/O error
Jul 04 11:20:11 goll systemd[1]: Started Setup zram based device zram0.

Demonstrating the fix:

bash5$ sudo systemctl stop zram-setup@zram0
bash5$ sudo rmmod zram
bash5$ sudo SYSTEMD_EDITOR=ed systemctl edit zram-setup@
0
i
[Unit]
ConditionPathExists=/usr/local/lib/zram.conf.d/%i-env
.
w
61
q
bash5$ sudo modprobe zram
bash5$ systemctl status zram-setup@zram0 -l
● zram-setup@zram0.service - Setup zram based device zram0
   Loaded: loaded (/lib/systemd/system/zram-setup@.service; static; vendor 
preset: enabled)
  Drop-In: /etc/systemd/system/zram-setup@.service.d
   └─override.conf
   Active: inactive (dead)
Condition: start condition failed at Thu 2019-07-04 11:47:30 AEST; 40s ago
   └─ ConditionPathExists=/usr/local/lib/zram.conf.d/zram0-env was 
not met

[...]
Jul 04 11:47:30 goll systemd[1]: Condition check resulted in Setup zram 
based device zram0 being skipped.

Demonstrating the fix doesn't break things for existing users:

bash5$ sudo systemctl stop zram-setup@zram0
bash5$ sudo 

Bug#896184: conserver-server fails to restart on systemd reliably

[Matthew Gabeler-Lee]

Package: conserver-server
Followup-For: Bug #896184

This problem has gotten even worse.

Now the stop script has become completely ineffectual -- it will never stop
the server at all, systemd or not.  From the start-stop-daemon manpage, on 
--pidfile:

Warning:  using  this  match option with a world-writable pidfile or using
it alone with a daemon that writes the pidfile as an unprivileged (non-root)
user will be refused with an error (since version 1.19.3) as this is a
security risk

Thus, the stop script fails 100% of the time with:

Stopping conserver: start-stop-daemon: matching only on non-root pidfile 
/var/run/conserver.pid is insecure

On the upside, Bernhard's patch fixes this problem too :)

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable'), (500, 
'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.1.0-trunk-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages conserver-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libpam0g   1.3.1-5
ii  libssl1.1  1.1.1c-1
ii  libwrap0   7.6.q-28
ii  lsb-base   10.2019051400

conserver-server recommends no packages.

conserver-server suggests no packages.

-- Configuration Files:
/etc/conserver/conserver.cf changed [not included]

-- debconf information excluded

Bug#931398: Acknowledgement (owncloud-client: Dependency issue?)

[Chubb, Peter (Data61, Kensington NSW)]

Looks like this may have been a temporary glitch.  Installing on
another machine didn't show the issue; and I can no longer reproduce
it on the machine that originally showed the problem.  Maybe a mirror
was out of date somewhere?

Peter C
-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group Data61, CSIRO (formerly NICTA)

Bug#931398: owncloud-client: Dependency issue?

[Peter Chubb]

Package: owncloud-client
Version: 2.5.1.10973+dfsg-1
Severity: normal

Dear Maintainer,

 I did:
   apt-get update
   apt-get instal owncloud-client
   /usr/bin/owncloud

 and see:
   owncloud: error while loading shared libraries: libqt5keychain.so.0: 
cannot open shared object file: No such file or directory

 owncloud-client depends on libqt5keychain1 which installs
 /usr/lib/x86_64-linux-gnu/libqt5keychain.so.1


 Looks like it neeeds rebuilding against the current libraries.
 I did that and all was well.

Peter C  

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel, arm64

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

Versions of packages owncloud-client depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-7
ii  libowncloudsync0  2.5.1.10973+dfsg-1
ii  libqt5core5a  5.11.3+dfsg1-2
ii  libqt5dbus5   5.11.3+dfsg1-2
ii  libqt5gui55.11.3+dfsg1-2
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-2
ii  libqt5sql5-sqlite 5.11.3+dfsg1-2
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-2
ii  libqt5xml55.11.3+dfsg1-2
ii  libstdc++68.3.0-7
ii  owncloud-client-l10n  2.5.1.10973+dfsg-1

Versions of packages owncloud-client recommends:
ii  owncloud-client-doc  2.5.1.10973+dfsg-1

owncloud-client suggests no packages.

-- no debconf information

Bug#931397: arm-trusted-firmware: Please provide fiptool and cert_create

[Ying-Chun Liu (PaulLiu)]

Source: arm-trusted-firmware
Version: 2.1-2
Severity: wishlist


Dear Maintainer,

Can you provide fiptool and cert_create so that we can change
the fip image more easily?

These 2 tools are very important for using arm-trusted-firmware I think.
By using fiptool we can alter the images (BL31/32/33) in FIP. For example,
if we want to manually upgrade OPTEE or U-Boot, then we need to run
"fiptool update"

I mean maybe we can create a new package called arm-trusted-firmware-tools.
The arch should be any. And it should provides /usr/bin/fiptool and
/usr/bin/cert_create.

To make these two binaries, we can do these steps in arm-trusted-firmware
source directory:

 * fiptool: make fiptool
 * cert_create: make -C tools/cert_create

These tools are arch-dependent but ARM-platform-independent.
cert_create will introduce a Build-Depends to libssl-dev.

Yours,
Paul





signature.asc
Description: OpenPGP digital signature

Bug#931396: rkhunter: Need to SCRIPTWHITELIST /usr/bin/egrep to avoid false positives after usrmerge.

[Aaron Howell]

Package: rkhunter
Version: 1.4.6-5
Severity: normal

After usrmerge has been run against a Debian system, /usr/bin/egrep becomes a 
script, because it is moved from /bin/egrep.
There is a SCRIPTWHITELIST entry in the default rkhunter config for /bin/egrep 
but not /usr/bin/egrep which causes it to warn that /usr/bin/egrep has been 
replaced by a script each day during its daily run.
Since usrmerge is the default for Buster, this should probably be added to the 
default config.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.0-17-generic (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.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 rkhunter depends on:
ii  binutils   2.32.51.20190701-1
ii  debconf [debconf-2.0]  1.5.72
ii  file   1:5.35-4
ii  lsof   4.91+dfsg-1ubuntu1
ii  net-tools  1.60+git20180626.aebd88e-1ubuntu1
ii  perl   5.28.1-6
ii  ucf3.0038+nmu1

Versions of packages rkhunter recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20180807cvs-1
ii  curl   7.64.0-4ubuntu1
ii  e2fsprogs  1.45.2-1ubuntu1
ii  exim4-daemon-heavy [mail-transport-agent]  4.92-7ubuntu1
ii  iproute2   5.1.0-1
ii  s-nail 14.9.13-1
ii  unhide 20130526-3
pn  unhide.rb  
ii  wget   1.20.1-1.1ubuntu1

Versions of packages rkhunter suggests:
ii  liburi-perl 1.76-1
ii  libwww-perl 6.36-2
ii  powermgmt-base  1.34

-- debconf information:
* rkhunter/cron_db_update: true
* rkhunter/cron_daily_run: true
* rkhunter/apt_autogen: true

Bug#922072: linux-image-4.9.0-3-686-pae: A Hauppauge PVR-150 fails obtain any image when a camera is connected to the composite video input.

[peter]

From: Ben Hutchings 
Date: Mon, 11 Feb 2019 20:27:24 +
> The current kernel version in stable is 4.9.130-2, while you are
> running a much older version.  Please install the available updates and
> re-test.

Right oh. 
 
... 
...

peter@imager:~$ uname -a
Linux imager 4.9.0-9-686-pae #1 SMP Debian 4.9.168-1+deb9u3 (2019-06-16) i686 
GNU/Linux

> Note that "apt-get upgrade" does *not* install all available updates;
> you must use the --with-new-pkgs option.

apt-get --with-new-pkgs upgrade

Before trying the Hauppauge card again, I plugged a Logitech USB 
camera. On the target machine, imager, cheese gives a segfault. On my 
desktop workstation the same camera with cheese gives an image.
A seg fault strikes me as undesirable.

The target machine has a Hauppauge PVR-150 card with an old video 
camera connected to the yellow RCA by a coaxial cable.

peter@imager:~$ v4l2-ctl --list-devices
Hauppauge WinTV PVR-150 (PCI::01:04.0):
/dev/video1
/dev/video25
/dev/video33
/dev/radio1
/dev/vbi1

Failed to open /dev/video0: No such file or directory
peter@imager:~$

qv4l2 -d /dev/video1
and
qv4l2 -d /dev/video25
give black viewers.

qv4l2 -d /dev/video33
gives a viewer with low-density multi-colored snow.

qv4l2 -d /dev/vbi1
gives a horizontal ribbon with low-density multi-colored snow.

Any ideas appreciated.

Thanks,Peter E.


-- 
https://en.wikibooks.org/wiki/Oberon
Tel: +1 604 670 0140Bcc: peter at easthope. ca

Bug#921194: amarok: Amarok depends on libmariadbd18, which doesn't exist any longer

[Geoff]

Package: amarok
Version: 2.9.0-1+b1
Followup-For: Bug #921194

Seems to have lost support upstream, it's unfortunate as it's still the best 
linux music player.

Bug#922496: GCC 9: gnat ftbs on kfreebsd-*

[James Clarke]

Control: tags -1 patch upstream
Control: forwarded -1 https://gcc.gnu.org/ml/gcc-patches/2019-07/msg00309.html

On Sun, Feb 17, 2019 at 07:44:37AM +0100, Matthias Klose wrote:
> Package: src:gcc-9
> Version: 9-20190216-2
> Tags: important
> Severity: sid bullseye
>
> ftbfs, and we still have local, not forwarded patches for kfreebsd.
>
> s-tpopmo.adb:61:25: expected private type "System.Os_Interface.clockid_t"
> s-tpopmo.adb:61:25: found type universal integer
> s-tpopmo.adb:76:34: expected private type "System.Os_Interface.clockid_t"
> s-tpopmo.adb:76:34: found type universal integer
> ../gcc-interface/Makefile:299: recipe for target 'a-dispat.o' failed
> make[8]: *** [a-dispat.o] Error 1
> make[8]: Leaving directory '/<>/build/gcc/ada/rts'
> gcc-interface/Makefile:622: recipe for target 'gnatlib' failed
> make[7]: *** [gnatlib] Error 2
> make[7]: Leaving directory '/<>/build/gcc/ada'
> gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed
> make[6]: *** [gnatlib-shared-dual] Error 2
> make[6]: Leaving directory '/<>/build/gcc/ada'
> gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed
> make[5]: *** [gnatlib-shared] Error 2
> make[5]: Leaving directory '/<>/build/gcc/ada'
> Makefile:104: recipe for target 'gnatlib-shared' failed
> make[4]: *** [gnatlib-shared] Error 2

Hi Matthias,
Please add the above patch I've sent upstream, which should fix this.

Thanks,
James

Bug#931364: zabbix-agent: defaults to /var/run instead of /run for tmpfiles

[Richard Hector]

On 3/07/19 10:44 PM, Dmitry Smirnov wrote:
> Thanks for the report.
> 
> On Wednesday, 3 July 2019 4:02:54 PM AEST Richard Hector wrote:
>> Severity: important
> 
> How do you justify severity??

Sorry, I don't. I thought I'd picked minor :-(

Richard





signature.asc
Description: OpenPGP digital signature

Bug#889925: valac is unusable for cross-compilation

[Helmut Grohne]

Hi Simon,

On Wed, Jul 03, 2019 at 08:50:05AM +0100, Simon McVittie wrote:
> On Thu, 08 Feb 2018 at 21:26:14 +0100, Helmut Grohne wrote:
> > So we'd also need a
> > new binary package (probably called "valac-bin"), move /usr/bin/valac to
> > that new package, add a dependency from valac to the new package and
> > mark the new package Multi-Arch: foreign. That's not fully correct as
> > valac is still architecture-dependent, but anyone wanting a particular
> > architecture's behaviour can and should simply run
> > ${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
> > appears to work fairly well. Consumers need to add this prefix of course
> > and I sent a patch for AM_PROG_VALAC (#889920) already.
> 
> Would it work to move /usr/bin/valac to /usr/libexec/valac in the new,
> Multi-Arch: foreign valac-bin package, and have these scripts in valac?

Moving valac to a Multi-Arch: foreign valac-bin package is what I
proposed, no? Whether it resides in /usr/bin/valac or /usr/libexec/valac
is an interesting question though.

> 
> /usr/bin/valac:
> #!/bin/sh
> exec /usr/libexec/valac --cc="${CC:-cc}" 
> --pkg-config="${PKG_CONFIG:-pkg-config}" "$@"

I'm not sure about the utility of this wrapper in particular for three
reasons:
 1. As far as I understand it, a significant chunk of valac users don't
make it call cc or pkg-config. This is backed by the number of
recent bugs where Nguyen Hoang Tung proposed annotating valac with
:native.
 2. For those packages that do make valac call cc, I think it would be
better to replace valac with your second wrapper.
 3. pkg-config also ships /usr/bin/pkg-config as a "native" variant
where you don't know which arch it refers to, but you can assume
that the "native" variant produces runnable code.

> /usr/bin/@DEB_HOST_GNU_TYPE@-valac:
> #!/bin/sh
> exec /usr/libexec/valac --cc="${CC:-@DEB_HOST_GNU_TYPE@-gcc}" 
> --pkg-config="${PKG_CONFIG:-@DEB_HOST_GNU_TYPE@-pkg-config}" "$@"

I think this is roughly the wrapper I had in mind. I'm not sure about
whether interpolating CC and PKG_CONFIG is a good idea:
 * You can use ${DEB_BUILD_GNU_TYPE}-valac and
   ${DEB_HOST_GNU_TYPE}-valac in a single build. If export CC in any
   way, either of these valac wrappers will misbehave.
 * If you do need to use valac with a specific cc, you can still pass it
   explicitly. Multiple --cc are allowed afaiui.
 * You can (and should) use valac in a way that doesn't call cc.

> And then #889920 would still be helpful, but not a blocker, because
> in practice most packages that compile Vala code (and in particular
> those that use Autotools) will already export an appropriate $CC and
> $PKG_CONFIG?

I don't think autotools export CC or PKG_CONFIG. It's only a AC_SUBST
variable and a Makefile variable, but not usually an environment
variable. But then switching from AC_PATH_PROG to AC_PATH_TOOL is a
quite simple change.

> (In fact valac is just a symlink to valac-0.42, so we'd probably want to
> move this indirection down to valac-0.42, vapigen-0.42 etc., which would
> help to make it clearer that valac-bin is an implementation detail,
> because it wouldn't contain any command-line APIs that were stable
> between versions at all.)

I agree that valac-bin should be an implementation detail. I've added a
number of such detail packages now and wonder whether there should be
some section for them. Doing so could allow lintian to flag dependencies
on detail packages as errors maybe.

> However, this is not the only Multi-Arch issue with valac:
> 
> vapigen would also need checking for Multi-Arch suitability. It is used
> directly in many packages.

I somewhat agree, but I like to fix one issue at a time. So I'm in
favour of leaving vapigen broken for now and start with moving valac.
Once that works, we can look into vapigen.

> /usr/lib/*/vala-*/gen-introspect-* would also need checking for Multi-Arch
> suitability, and /usr/bin/vala-gen-introspect is a shell script wrapper
> around /usr/lib/*/vala-*/gen-introspect-* which hard-codes pkg-config. It
> should at least use ${PKG_CONFIG}. This is used directly in the geary and
> libdmapsharing packages.

If *-introsepct-* has anything to do with gobject, then we can give up,
because gobject introspection is not going to work at all in any way for
cross building. I've only seen one way to make it "work" thus far: qemu.

Let me try to summarize consensus:

 * There should be an implementation-detail package called valac-bin.
 * valac-bin should be Multi-Arch: foreign.
 * valac-bin should contain the (versioned) valac executable
 * valac should depend on valac-bin.
 * valac should ship a /usr/bin/${DEB_HOST_GNU_TYPE}-valac wrapper
   script.

Let me try to summarize non-consensus:

 * It is not clear where the valac executable should live. Options are
   /usr/bin/valac (like pkg-config) and /usr/libexec/valac. Possibly
   with a version suffix.
 * It is not clear whether the valac wrapper scripts shou

Bug#581960: tex4ht: wrong charset in htlatex output

[Hilmar Preuße]

On 17.05.10 13:54, jsb...@mimuw.edu.pl wrote:

Hi Janusz,

> Please have a look at the attached example.
> 
> This is a regression, it work correctly several years ago...
> 
Just to make we sure we understand you correctly: currently the char
encoding is set to iso-8859-1 and the web page looks OK. Is therefore
the bug solved? HTML page generated from your file is attached.

I just called "htlatex minimal_example_squeeze.tex" on the command line.

Thanks,
  Hilmar
-- 
sigfault
#206401 http://counter.li.org
  
 

Pójdź, kiń-że tę chmurność w głąb flaszy.

 



 
/* start css.sty */
p.noindent { text-indent: 0em }
td p.noindent { text-indent: 0em; margin-top:0em; }
p.nopar { text-indent: 0em; }
p.indent{ text-indent: 1.5em }
@media print {div.crosslinks {visibility:hidden;}}
a img { border-top: 0; border-left: 0; border-right: 0; }
center { margin-top:1em; margin-bottom:1em; }
td center { margin-top:0em; margin-bottom:0em; }
.Canvas { position:relative; }
img.math{vertical-align:middle;}
li p.indent { text-indent: 0em }
li p:first-child{ margin-top:0em; }
li p:last-child, li div:last-child { margin-bottom:0.5em; }
li p~ul:last-child, li p~ol:last-child{ margin-bottom:0.5em; }
.enumerate1 {list-style-type:decimal;}
.enumerate2 {list-style-type:lower-alpha;}
.enumerate3 {list-style-type:lower-roman;}
.enumerate4 {list-style-type:upper-alpha;}
div.newtheorem { margin-bottom: 2em; margin-top: 2em;}
.obeylines-h,.obeylines-v {white-space: nowrap; }
div.obeylines-v p { margin-top:0; margin-bottom:0; }
.overline{ text-decoration:overline; }
.overline img{ border-top: 1px solid black; }
td.displaylines {text-align:center; white-space:nowrap;}
.centerline {text-align:center;}
.rightline {text-align:right;}
div.verbatim {font-family: monospace; white-space: nowrap; text-align:left; clear:both; }
.fbox {padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
div.fbox {display:table}
div.center div.fbox {text-align:center; clear:both; padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
div.minipage{width:100%;}
div.center, div.center div.center {text-align: center; margin-left:1em; margin-right:1em;}
div.center div {text-align: left;}
div.flushright, div.flushright div.flushright {text-align: right;}
div.flushright div {text-align: left;}
div.flushleft {text-align: left;}
.underline{ text-decoration:underline; }
.underline img{ border-bottom: 1px solid black; margin-bottom:1pt; }
.framebox-c, .framebox-l, .framebox-r { padding-left:3.0pt; padding-right:3.0pt; text-indent:0pt; border:solid black 0.4pt; }
.framebox-c {text-align:center;}
.framebox-l {text-align:left;}
.framebox-r {text-align:right;}
span.thank-mark{ vertical-align: super }
span.footnote-mark sup.textsuperscript, span.footnote-mark a sup.textsuperscript{ font-size:80%; }
div.tabular, div.center div.tabular {text-align: center; margin-top:0.5em; margin-bottom:0.5em; }
table.tabular td p{margin-top:0em;}
table.tabular {margin-left: auto; margin-right: auto;}
td p:first-child{ margin-top:0em; }
td p:last-child{ margin-bottom:0em; }
div.td00{ margin-left:0pt; margin-right:0pt; }
div.td01{ margin-left:0pt; margin-right:5pt; }
div.td10{ margin-left:5pt; margin-right:0pt; }
div.td11{ margin-left:5pt; margin-right:5pt; }
table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; }
td.td00{ padding-left:0pt; padding-right:0pt; }
td.td01{ padding-left:0pt; padding-right:5pt; }
td.td10{ padding-left:5pt; padding-right:0pt; }
td.td11{ padding-left:5pt; padding-right:5pt; }
table[rules] {border-left:solid black 0.4pt; border-right:solid black 0.4pt; }
.hline hr, .cline hr{ height : 1px; margin:0px; }
.tabbing-right {text-align:right;}
span.TEX {letter-spacing: -0.125em; }
span.TEX span.E{ position:relative;top:0.5ex;left:-0.0417em;}
a span.TEX span.E {text-decoration: none; }
span.LATEX span.A{ position:relative; top:-0.5ex; left:-0.4em; font-size:85%;}
span.LATEX span.TEX{ position:relative; left: -0.4em; }
div.float, div.figure {margin-left: auto; margin-right: auto;}
div.float img {text-align:center;}
div.figure img {text-align:center;}
.marginpar {width:20%; float:right; text-align:left; margin-left:auto; margin-top:0.5em; font-size:85%; text-decoration:underline;}
.marginpar p{margin-top:0.4em; margin-bottom:0.4em;}
table.equation {width:100%;}
.equation td{text-align:center; }
td.equation { margin-top:1em; margin-bottom:1em; } 
td.equation-label { width:5%; text-align:center; }
td.eqnarray4 { width:5%; white-space: normal; }
td.eqnarray2 { width:5%; }
table.eqnarray-star, table.eqnarray {width:100%;}
div.eqnarray{text-align:center;}
div.array {text-align:center;}
div.pmatrix {text-align:center;}
table.pmatrix {width:100%;}
span.pmatrix img{vertical-align:middle;}
div.pmatrix {text-align:center;}
table.pmatrix {width:100%;}
span.bar-css {text-decoration:overline;}
img.cdots{vertical-align:middle;}
.partToc a, .partToc, .likepartToc a, .likepartToc {line-height: 200%; font-weight:

Bug#931395: RFS: gcc-doc-defaults/5:18 [RC]

[Dmitry Eremin-Solenikov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gcc-doc-defaults"

* Package name: gcc-doc-defaults
  Version : 5:18
* URL : http://gcc.gnu.org/
* License : GNU-meta-license
  Section : doc

It builds those binary packages:

gcc-doc - documentation for the GNU compilers (gcc, gobjc, g++)
cpp-doc - documentation for the GNU C preprocessor (cpp)
gfortran-doc - documentation for the GNU Fortran Compiler (gfortran)
gnat-doc - documentation for the GNU Ada Compiler (gnat)
gccgo-doc - documentation for the GNU Go compiler (gccgo)
gcc-doc-base - several GNU manual pages

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

https://mentors.debian.net/package/gcc-doc-defaults


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

dget -x 
https://mentors.debian.net/debian/pool/contrib/g/gcc-doc-defaults/gcc-doc-defaults_18.dsc

Changes since the last upload:

  * New uploader.
  * Thanks to Guo Yixuan for his work on this package.
  * Support proper NMU package versioning.
  * Build gcc-8 docs (Closes: #905022)
  * Bumped standard version to 4.3.0, no changes needed.
  * Point VCS-* tags to salsa.d.o

-- 
With best wishes
Dmitry Eremin-Solenikov

Bug#931394: ITP: r-bioc-rhtslib -- HTSlib high-throughput sequencing library as GNU R package

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-rhtslib -- HTSlib high-throughput sequencing library as 
GNU R package
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-rhtslib
  Version : 1.16.1
  Upstream Author : Nathaniel Hayden,
* URL : https://bioconductor.org/packages/Rhtslib/
* License : LGPL-2+
  Programming Lang: GNU R
  Description : HTSlib high-throughput sequencing library as GNU R package
 This package provides version 1.7 of the 'HTSlib' C
 library for high-throughput sequence analysis. The package is
 primarily useful to developers of other R packages who wish to
 make use of HTSlib. Motivation and instructions for use of this
 package are in the vignette, vignette(package="Rhtslib", "Rhtslib").

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-rhtslib

Bug#930539: [Pkg-utopia-maintainers] Bug#930539: upowerd cannot start due to searching the wrong libssl version

[Andreas von Heydwolff]

>> I did not compile anything from source
> Then why you have binaries in /usr/local?

Hm, seems that indeed I did try out someone else's non standard attempt
of connecting a recent iOS device to my machine many months ago. My bad.
It didn't work as expected and I left an instance of libimobiledevice6
in /usr/local/lib. Same thing is true with a program I did compile and
use last year. It was was dependent on libssl, worked well but only
until some new ssl version broke it and I stopped using it. Lesson
learned. Thanks to all once more for helping me sort this out.

Regards,
Andreas

Bug#931393: qtcreator: Missing dependencies to get working kit out of the box

[Philip Rinn]

Package: qtcreator
Version: 4.8.2-1
Severity: normal

Hi,

after installing qtcreator, I had to install two extra packages to get a
working kit:

- qt5-default: without this package no Qt Version was found
- qtdeclarative5-dev: without this package qmlscene was reported missing

Both are well known problems:

https://stackoverflow.com/questions/16607003/qmake-could-not-find-a-qt-
installation-of
https://stackoverflow.com/questions/34918115/getting-no-qmlscene-installed-
warning-in-qt-creator-on-ubuntu

Please consider adding these packages to "Recommends".

Thanks,
Philip



-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (600, 'testing'), (550, 'unstable'), (450, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages qtcreator depends on:
ii  libbotan-2-9   2.9.0-2
ii  libc6  2.28-10
ii  libclang1-71:7.0.1-8
ii  libgcc11:8.3.0-6
ii  libgl1 1.1.0-1
ii  libllvm7   1:7.0.1-8
ii  libqbscore1.12 1.12.2+dfsg-2
ii  libqbsqtprofilesetup1.12   1.12.2+dfsg-2
ii  libqt5concurrent5  5.11.3+dfsg1-1
ii  libqt5core5a [qtbase-abi-5-11-3]   5.11.3+dfsg1-1
ii  libqt5designer55.11.3-4
ii  libqt5designercomponents5  5.11.3-4
ii  libqt5gui5 5.11.3+dfsg1-1
ii  libqt5help55.11.3-4
ii  libqt5network5 5.11.3+dfsg1-1
ii  libqt5printsupport55.11.3+dfsg1-1
ii  libqt5qml5 [qtdeclarative-abi-5-11-2]  5.11.3-4
ii  libqt5quick5   5.11.3-4
ii  libqt5quickwidgets55.11.3-4
ii  libqt5script5  5.11.3+dfsg-3
ii  libqt5serialport5  5.11.3-2
ii  libqt5sql5 5.11.3+dfsg1-1
ii  libqt5sql5-sqlite  5.11.3+dfsg1-1
ii  libqt5widgets5 5.11.3+dfsg1-1
ii  libqt5xml5 5.11.3+dfsg1-1
ii  libstdc++6 8.3.0-6
ii  qml-module-qtqml-models2   5.11.3-4
ii  qml-module-qtquick-controls5.11.3-2
ii  qml-module-qtquick25.11.3-4
ii  qtchooser  66-2
ii  qtcreator-data 4.8.2-1

Versions of packages qtcreator recommends:
ii  clang 1:7.0-47
ii  gdb   8.2.1-2
ii  gnome-terminal [x-terminal-emulator]  3.30.2-2
ii  make  4.2.1-1.2
ii  qmlscene  5.11.3-4
ii  qt5-doc   5.11.3-1
ii  qt5-qmltooling-plugins5.11.3-4
ii  qtbase5-dev-tools 5.11.3+dfsg1-1
ii  qtcreator-doc 4.8.2-1
ii  qtdeclarative5-dev-tools  5.11.3-4
ii  qttools5-dev-tools5.11.3-4
ii  qttranslations5-l10n  5.11.3-2
ii  qtxmlpatterns5-dev-tools  5.11.3-2
ii  xterm [x-terminal-emulator]   344-1

Versions of packages qtcreator suggests:
pn  clazy   
ii  cmake   3.13.4-1
ii  g++ 4:8.3.0-1
ii  git 1:2.20.1-2
pn  kate-data   
pn  subversion  
pn  valgrind

-- no debconf information

Bug#930595: RFS: uacme/1.0.15-2 [ITP]

[Nicola Di Lieto]

On Wed, Jul 03, 2019 at 02:40:30AM +0200, Adam Borowski wrote:
One issue is the watch file being empty (save for comments).  If 
there's

nothing inside, it should be deleted.  But, for a Github project that does
sane release, it's too trivial to fill it instead:


Done, but since I use pristine-tar and import tarballs made by 'make 
dist', the orig tarball is not downloadable anywhere, and therefore it 
wasn't exactly trivial to get it to work.



Thus, unless there's a good reason, such changelog entries get squashed;
and, since there's no previous release, just a single "Initial release
(Closes: #123456)" is enough.  Also, both people and tools tend to get
confused when there's a -7 but no -1.


Done. I took the chance to include some minor changes in a new upstream 
too, so debian version is now 1.0.17-1


https://mentors.debian.net/debian/pool/main/u/uacme/uacme_1.0.17-1.dsc

Note: I will push debian/1.0.17 to github after you confirm you are 
happy with how it is.

Bug#927165: [pkg-cryptsetup-devel] Bug#927165: debian-installer: improve support for LUKS

[Holger Wansing]

Hi,

Am Mittwoch, 3. Juli 2019 schrieb Cyril Brulebois: 
> Don't worry about the delay, I'm very happy to merge this now, and have
> an opportunity to backport it in a point release later on. If I got the
> process right, having the changes in master should trigger an update of
> pot/po files by the l10n robot, and translators will be able to catch up
> in a couple of hours.

Yes, that  assumption is correct, the update of po files  will happen 
automatically this night.


Holger 


-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#931375: unblock: calamares-settings-debian/10.0.24-1

[Jonathan Carter]

On 2019/07/03 22:06, Paul Gevers wrote:
> Can you elaborate why not? I suggest you talk to the security team to
> get it uploaded to their archive, because I don't understand why that
> wouldn't work.

Because (for some reason that I only confirmed today and hope to be able
to change soon), live images don't build using a -security apt source,
so if this can make it into -security it won't be in the image that's
released this weekend.

> Sorry, too late. I agree that this isn't pretty, but we are in the hard
> freeze and your issue is not a we-can-release-otherwise problem. If you
> are right it can't be fixed via security, we can document it in the
> release notes as you say. The problem you are having is not new, see
> e.g. bug 578117.

This particular issue is a new issue since we haven't used full-disk
encryption from an installer before in Debian, so it didn't have this
kind of real-world impact back when #578117 (and similar bugs) were filed.

Will talk to Steve and get a release note prepared then.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Bug#922964: RFS: python-fingerprint/1.5 [ITP]

[Herbert Fortes]

Hi,

On Fri, 22 Feb 2019 11:59:04 +0100 Philipp Meisberger  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-fingerprint"
> 
>  * Package name: python-fingerprint
>Version : 1.5
>Upstream Author : Bastian Raschke 
>  * URL : https://github.com/bastianraschke/pyfingerprint
>  * License : D-FSL
>Section : python
>

The D-FSL[0] license used seems to be the same as the one
discussed in the past in debian-legal[1] - 2004.

[0] - 
https://www.hbz-nrw.de/produkte/open-access/lizenzen/dfsl/german-free-software-license
[1] - https://lists.debian.org/debian-legal/2004/12/msg00123.html

Project:
https://github.com/bastianraschke/pyfingerprint/blob/Development/LICENSE

There are some incompatible parts/snippets. Although GPL appears in
the text.



Regards,
Herbert

Bug#594506: konsole crashed (signal 11)

[David J. Ring]

Package: konsole
Version: 4:18.04.0-1
Followup-For: Bug #594506

Dear Maintainer,

Changed Debian version now on Sid.  konsole still hangs up and is unusable.

Regards,

djringjr


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages konsole depends on:
ii  kio   5.54.1-1
ii  konsole-kpart 4:18.04.0-1
ii  libc6 2.28-10
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1
ii  libkf5configgui5  5.54.0-1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5globalaccel55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5notifyconfig5   5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-2
ii  libqt5gui55.11.3+dfsg1-2
ii  libqt5widgets55.11.3+dfsg1-2
ii  libstdc++68.3.0-7

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#927165: [pkg-cryptsetup-devel] Bug#927165: debian-installer: improve support for LUKS

[Cyril Brulebois]

Control: tag -1 patch pending

Hi Guilhem,

Guilhem Moulin  (2019-07-03):
> On Mon, 01 Jul 2019 at 04:45:47 +0200, Guilhem Moulin wrote:
> > Sure, I even planned to do that when I heard about your post-mini-DebConf
> > “hiccup” ;-)  I remained on the road for another 3 weeks and unfortunately
> > didn't find time since the mini Debconf.  Thanks for the poke, I'll try to
> > tend to it this week.
> 
> It was less difficult than I imagined ;-)  Sorry for delaying it, I
> could have done that immediately after writing the document.
> 
> 
> https://salsa.debian.org/installer-team/installation-guide/merge_requests/9

Don't worry about the delay, I'm very happy to merge this now, and have
an opportunity to backport it in a point release later on. If I got the
process right, having the changes in master should trigger an update of
pot/po files by the l10n robot, and translators will be able to catch up
in a couple of hours.

Again: Many thanks!

> Do you still think it'd be a good idea to add a boot parameter
> ‘luks-version=’ or so (defaulting to ‘2’) so users can easily format
> to LUKS1, or do you agree documenting the “downgrade path” is enough?
> (I guess it's too late for Buster anyway, but maybe a later point
> release?)

As we discussed a couple of weeks ago, adding support for tweaking the
LUKS version was envisioned before buster; but with that documentation
now being available, and with buster being released real soon now, I'm
not convinced adding this option, even in a later point release, is
really a good use of everyone's time.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#931375: unblock: calamares-settings-debian/10.0.24-1

[Paul Gevers]

Control: tags -1 wontfix

Hi Jonathan,

On 03-07-2019 15:41, Jonathan Carter wrote:
> I realise it's 3 days before release weekend, this upload fixes a problem
> that we can't really fix in a security update.

Can you elaborate why not? I suggest you talk to the security team to
get it uploaded to their archive, because I don't understand why that
wouldn't work.

> Yesterday a user discovered
> that their encryption key for their hard disk in a full-disk-encryption
> setup is world-readable on debian-based systems using initramfs-tools.
>
> This affects Calamares users who can now install Debian on in an easy to
> use full-disk encryption setup. Upstream bug:
> https://github.com/calamares/calamares/issues/1191
> 
> CVE:
> https://nvd.nist.gov/vuln/detail/CVE-2019-13179
> 
> This upload updates the bootloader-config script with this additional snippet:
> """
> # Set secure permissions for the initramfs,
> # the initramfs is re-generated later in the installation process
> # so we only set the permissions without regenerating the initramfs now:
> echo "UMASK=0077" > $CHROOT/etc/initramfs-tools/conf.d/initramfs-permissions
> """
> 
> Which will cause "update-initramfs -u" that runs later in the script to write
> the initramfs with safe permissions.
> 
> Without this upload, users will have to write that file theirselves in order
> to have a setup safe from local users (or users on the system with filesystem
> access). In such a case we'll note it in the release notes, but I would urge
> the release team to consider it if there is still any possibility.

Sorry, too late. I agree that this isn't pretty, but we are in the hard
freeze and your issue is not a we-can-release-otherwise problem. If you
are right it can't be fixed via security, we can document it in the
release notes as you say. The problem you are having is not new, see
e.g. bug 578117.

Paul

Bug#931002: [Pkg-rust-maintainers] Updating crates for Debian stable release

[Ivo De Decker]

Hi Sylvestre,

On 7/3/19 9:23 PM, Sylvestre Ledru wrote:


Le 30/06/2019 à 19:48, Sylvestre Ledru a écrit :

Le 27/06/2019 à 17:43, Ivo De Decker a écrit :

Hi,

On Mon, Jun 24, 2019 at 06:03:00PM +, Ximin Luo wrote:
I am on vacation for the next two weeks, please can someone else 
deal with the following:


Due to Firefox we updated/unblocked rustc 1.34.2 for Debian Testing 
(and the next Debian Stable) release.


For future release, a better way of handling this will be needed. The 
fact

that these updates break random other packages isn't really acceptable.

Agreed.

I think we are in a good state now in unstable. We should have to 
accept the unblock.


Sorry for the last minute stress.

Give where we are (super close to the release date), maybe we should not 
do anything (unblock or removal).


This will be transparent for our users and won't be an actual issue. 
removal might have some unexpected side effects

with other rust-based packages.

I am happy to work to fix that in a dot release of buster.

Please let me know what you think!


I agree.

Given the timing and your commitment to find a solution via a point 
release, I'm willing to accept the situation as it is now.


Thanks,

Ivo

Bug#752709: Plan B - Debian Package antimicro

[Thorsten Glaser]

tags 752709 + fixed pending
outlook 752709 in NEW awaiting ftpmaster review
forwarded 752709 https://ftp-master.debian.org/new/antimicro_2.23-1.html
thanks

I’ve uploaded initial packaging.

Enjoy,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#931391: calamares: CVE-2019-13178

[Salvatore Bonaccorso]

Source: calamares
Version: 3.2.4-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/calamares/calamares/issues/1190
Control: found -1 3.2.4-3

Hi,

The following vulnerability was published for calamares.

CVE-2019-13178[0]:
| modules/luksbootkeyfile/main.py in Calamares through 3.2.4 has a race
| condition between the time when the LUKS encryption keyfile is created
| and when secure permissions are set.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13178
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13178
[1] https://github.com/calamares/calamares/issues/1190

Regards,
Salvatore

Bug#931392: calamares: CVE-2019-13179

[Salvatore Bonaccorso]

Source: calamares
Version: 3.2.4-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/calamares/calamares/issues/1191
Control: found -1 3.2.4-3


Hi,

The following vulnerability was published for calamares.

CVE-2019-13179[0]:
| Calamares through 3.2.4 copies a LUKS encryption keyfile from
| /crypto_keyfile.bin (mode 0600 owned by root) to /boot within a
| globally readable initramfs image with insecure permissions, which
| allows this originally protected file to be read by any user, thereby
| disclosing decryption keys for LUKS containers created with Full Disk
| Encryption.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-13179
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13179
[1] https://github.com/calamares/calamares/issues/1191

Regards,
Salvatore

Bug#931002: [Pkg-rust-maintainers] Updating crates for Debian stable release

[Sylvestre Ledru]

Le 30/06/2019 à 19:48, Sylvestre Ledru a écrit :

Le 27/06/2019 à 17:43, Ivo De Decker a écrit :

Hi,

On Mon, Jun 24, 2019 at 06:03:00PM +, Ximin Luo wrote:
I am on vacation for the next two weeks, please can someone else 
deal with the following:


Due to Firefox we updated/unblocked rustc 1.34.2 for Debian Testing 
(and the next Debian Stable) release.


For future release, a better way of handling this will be needed. The 
fact

that these updates break random other packages isn't really acceptable.

Agreed.

I think we are in a good state now in unstable. We should have to 
accept the unblock.


Sorry for the last minute stress.

Give where we are (super close to the release date), maybe we should not 
do anything (unblock or removal).


This will be transparent for our users and won't be an actual issue. 
removal might have some unexpected side effects

with other rust-based packages.

I am happy to work to fix that in a dot release of buster.

Please let me know what you think!

Cheers
S

Bug#931390: xfce4-places-plugin: manpage in wrong section

[Laurent Bonnaud]

Package: xfce4-places-plugin
Version: 1.7.0-4
Severity: normal


Dear Maintainer,

this manpage:

  /usr/share/man/man2/xfce4-popup-places.22.gz

is in section 22, which is most certainly a mistake.


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

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

--
Laurent.

Bug#931389: LXQt: SDDM does not start

[Kevin Williams]

Package: installation-reports

Boot method: ISO image
Image version: 
https://cdimage.debian.org/cdimage/buster_di_rc3/amd64/iso-cd/debian-buster-DI-rc3-amd64-netinst.iso
Date: 2019-07-03 1200 CDT

Machine: Hyper-V on Win10 1903
Processor: Intel Core i7-3770
Memory: 2 GB
Partitions:

udevdevtmpfs968968  0   968968  0%  /dev
tmpfs   tmpfs   197744  3268194476  2%  /run
/dev/sda1   ext449278612 42605344   9%  /
tmpfs   tmpfs   988708  7788980920  1%  /dev/shm
tmpfs   tmpfs   51200   51200%  /run/lock
tmpfs   tmpfs   988708  0   988708  0%  /sys/fs/cgroup
tmpfs   tmpfs   197740  8   197732  1%  /run/user/1000

Output of lspci -knn (or lspci -nn):

00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 
82443BX/ZX/DX Host bridge (AGP disabled) [8086:7192] (rev 03)
00:07.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA 
[8086:7110] (rev 01)
 Subsystem: Microsoft Corporation 82371AB/EB/MB PIIX4 ISA 
[1414:]
00:07.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE 
[8086:7111] (rev 01)
 Kernel driver in use: ata_piix
 Kernel modules: ata_piix, ata_generic
00:07.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI 
[8086:7113] (rev 02)
 Kernel modules: i2c_piix4
00:08.0 VGA compatible controller [0300]: Microsoft Corporation Hyper-V 
virtual VGA [1414:5353]
 Kernel driver in use: hyperv_fb
 Kernel modules: hyperv_fb

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

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

Comments/Problems:

If I tell tasksel to install the desktop environment + LXQt, sddm will 
not start, but startx will bring up the GUI.  If I instead have it 
install MATE or LXDE, a GUI login screen comes up.

I have not tried other DEs yet.

-- 
Kevin Williams ktwilli...@pittstate.edu w:620-235-4837
+--+
|-- SELF-ASSEMBLY MÖBIUS STRIP - SEE OTHER SIDE FOR INSTRUCTIONS --|
+--+
<>

Bug#931295: u-boot-sunxi: cannot stop autoboot with usb keyboard on cubietruck

[Phil Morrell]

Control: tags -1 patch
thanks

Looking through [configs/Cubietruck_defconfig], it seems highly likely
to me that commit [29d280c8] is the fix. I don't know if it's
backportable and I'm not sure how to rebuild this package, but I'm happy
to test any images built with:

CONFIG_USB_OHCI_HCD=y

I was also not sure if this should be important (because it only affects
some hardware) or grave because for the hardware it does affect, I'm
unable to install Buster.

[29d280c8]: 
https://gitlab.denx.de/u-boot/u-boot/commit/29d280c88a1ff331dce2d4c7a5aaf2402aa0fd8a#0eebb5a51fc5f88e9eddcca0b9a87309b0c07e0c
[configs/Cubietruck_defconfig]: 
https://gitlab.denx.de/u-boot/u-boot/commits/master/configs/Cubietruck_defconfig


signature.asc
Description: PGP signature

Bug#928893: Confirming gnome-disks problem

[Paul Gevers]

Control: clone -1 -2
Control: reassign -2 release-notes

On Wed, 3 Jul 2019 12:43:28 -0500 Marco Villegas  wrote:
> Starting from buster installer rc3, and installing minimal dependencies
> to run, I can confirm the problem exists.
> 
> While trying to change the passphrase from gnome-disks, i.e. the old
> and new passphrases were entered, I see the following error message:
> "Error changing passphrase: Invalid argument (udisks-error-quark, 0)",
> screenshot attached.
> 
> I have also tried to access again the disk from an external gparted
> after the attempt, and I could not unlock the partition with neither
> the old nor the new passphrase.

Let's document this in the release notes to warn people as this won't
get fixed in buster before the release.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#925081: Patch didn't add Global Protect to the -gnome packages drop down.

[Mike Miller]

Control: reopen -1
Control: notfixed -1 network-manager-openconnect/1.2.4-3

On Tue, Jul 02, 2019 at 15:55:13 -0600, Jason Fergus wrote:
> I now have the version installed from experimental, but the new
> protocol isn't in the drop down list.
[…]
> It only lists Cisco Anyconnect and Juniper/Pulse Network Connect.

Thanks.

I looked at the patches more closely, and the changes made so far do
seem to support Global Protect connections, if the connection file is
edited or created manually. I think you're right that the connection
editor dialog does not yet provide the GlobalProtect option.

I've just commented as much on the upstream issue tracker, where this is
still open

  https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/issues/1

-- 
mike

Bug#931295: u-boot-sunxi: cannot stop autoboot with usb keyboard on cubietruck

[Phil Morrell]

Control: fixed -1 2019.07~rc4+dfsg-1
Control: affects -1 debian-installer
thanks

Since it's a very fast test, I performed some bisecting. The last image
that works is 20180610, the first to fail being 20181206. I can also
confirm yesterdays new image has not fixed it.

Out of interest, I extracted the u-boot-sunxi-with-spl.bin from
u-boot-sunxi:armhf. Naturally, stretch works and buster does not, but
interestingly the version in experimental does work.

This is also affecting d-i buster, even when booted from u-boot stretch.


signature.asc
Description: PGP signature

Bug#928287: qutip debian packaging

[Drew Parsons]

On 2019-07-03 21:24, Gürkan Myczko wrote:

Hi Drew

very nice you've filed an ITP for qutip, how are you progressing with
the debian packaging?



It's been uploaded, waiting in the NEW queue.

Drew

Bug#554998: tex4ht: oolatex error with hyperref

[Hilmar Preuße]

retitle Glitches when using hyperref and math mode
reopen 554999
severity 554999 minor
found 554999 2018.20190227-2
stop

On 07.11.09 21:05, Luca Capello wrote:

> Given that AFAIK the code above is perfectly valid, I guess this is a
> TeX4ht-specific problem.
> 
> BTW, there is another independent problem with the code above: the
> '\\' command is not taken into account.
> 
I'm reopening this one too, as the report is partially still valid:

1. The \\ sign is ignored inside the \author statement
2. <, > signs are not correctly converted in math mode
   Workaround: use \textless & \textgreater in text mode.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931387: e2scrub invoked for non-LVM device

[Marc Haber]

Package: e2fsprogs
Version: 1.45.2-1
Severity: normal
File: /sbin/e2scrub

Hi,

once in a while, I get mail from one of my systems saying that e2scrub
for /, /boot and a bunch of other filesystems has failed. The log says,
for example:

Jul  3 19:18:51 fan systemd[1]: Starting Online ext4 Metadata Check for /...
Jul  3 19:18:51 fan e2scrub@-[24727]: /: Not connnected to an LVM logical 
volume.
Jul  3 19:18:51 fan e2scrub@-[24727]: Usage: /sbin/e2scrub [OPTIONS] mountpoint 
| device
Jul  3 19:18:51 fan e2scrub@-[24727]: mountpoint must be on an LVM-managed 
block device
Jul  3 19:18:51 fan e2scrub@-[24727]: -n: Show what commands e2scrub would 
execute.
Jul  3 19:18:51 fan e2scrub@-[24727]: -r: Remove e2scrub snapshot and exit, do 
not check anything.
Jul  3 19:18:51 fan e2scrub@-[24727]: -t: Run fstrim if successful.
Jul  3 19:18:51 fan e2scrub@-[24727]: -V: Print version information and exit.
Jul  3 19:18:53 fan systemd[1]: e2scrub@-.service: Main process exited, 
code=exited, status=1/FAILURE
Jul  3 19:18:53 fan systemd[1]: e2scrub@-.service: Failed with result 
'exit-code'.
Jul  3 19:18:53 fan systemd[1]: Failed to start Online ext4 Metadata Check for 
/.
Jul  3 19:18:53 fan systemd[1]: e2scrub@-.service: Triggering OnFailure= 
dependencies.
Jul  3 19:18:53 fan systemd[1]: Starting Online ext4 Metadata Check Failure 
Reporting for /...
Jul  3 19:18:54 fan systemd[1]: Starting Online ext4 Metadata Check for /boot...
Jul  3 19:18:54 fan systemd[1]: e2scrub_fail@-.service: Succeeded.

The problem is that the error message is fully correct: / is not an LVM
logical volume, it's a LUKS device stored on an LVM logical volume:

32 [5/4992]mh@fan:~ $ lsblk /dev/sdb
NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb   8:16   0 931,5G  0 disk  
├─sdb18:17   0  1007K  0 part  
├─sdb28:18   0 1M  0 part  
└─sdb38:19   0 931,5G  0 part  
  ├─fan-c_root  253:00 417,2G  0 lvm   
  │ └─root  253:28   0 417,2G  0 crypt /

To make things more complex, the whole thing seems to be invoked by
e2scrub_all.timer, which in turn calls e2scrub_all.service, which in
turn calls /sbin/e2scrub_all -C which runs just fine when invoked from
the shell:

|[8/4995]mh@fan:~ $ time sudo /sbin/e2scrub_all -C
|
|real0m9,014s
|user0m0,121s
|sys 0m0,069s
|[9/4996]mh@fan:~ $ 

... but ...

(additional issue #1)
the -C option is not mentioned in the e2scrub_all manual page,

... and ...

(additional issue #2)
e2scub_all -n reveals that it would actually invoke systemctl start
e2scrub@- which, manually invoked, gives some feedback about its
failure:

[11/4998]mh@fan:~ $ sudo systemctl start e2scrub@-
Job for e2scrub@-.service failed because the control process exited with error 
code.
See "systemctl status e2scrub@-.service" and "journalctl -xe" for details.
(exit code 1)

I think that this should be reported by e2scrub_all so that the user
isn't lured into "everything is fine".

I don't think that having an e2 file system on a LUKS device on an LVM
logical volume is such an exotic thing to have.

Please let me know if you want dedicated bug reports for the additional
issues #1 (minor) and additional issues #2 (normal).

Greetings
Marc

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

Kernel: Linux 5.1.15-zgws1 (SMP w/6 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libcom-err2  1.45.2-1
ii  libext2fs2   1.45.2-1
ii  libss2   1.45.2-1
ii  libuuid1 2.33.1-0.1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
pn  gpart  
ii  parted 3.2-25

-- no debconf information

Bug#928893: Confirming gnome-disks problem

[Marco Villegas]

Starting from buster installer rc3, and installing minimal dependencies
to run, I can confirm the problem exists.

While trying to change the passphrase from gnome-disks, i.e. the old
and new passphrases were entered, I see the following error message:
"Error changing passphrase: Invalid argument (udisks-error-quark, 0)",
screenshot attached.

I have also tried to access again the disk from an external gparted
after the attempt, and I could not unlock the partition with neither
the old nor the new passphrase.

Best,

Bug#931386: stretch-pu: package fribidi/0.19.7-1.1

[Samuel Thibault]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hello,

As reported on #917909, the text-based debian installer support for
right-to-left languages is completely broken, only due to a path
mismatch. This was fixed in Buster in January with the attached change,
which I have uploaded to stretch as 0.19.7-1.1, could you accept it?

Thanks,
Samuel

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
commit 8469bfead9515ab3644f1769a1ff51466ba8ffee
Author: Samuel Thibault 
Date:   Mon Jul 1 02:31:02 2019 +0200

Fix crash on XkbSetMap

Some devices may not have keyboard information.

Fixes #574

diff --git a/xkb/xkb.c b/xkb/xkb.c
index 764079506..9bd45a34a 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2383,6 +2383,9 @@ _XkbSetMapChecks(ClientPtr client, DeviceIntPtr dev, 
xkbSetMapReq * req,
 XkbSymMapPtr map;
 int i;
 
+if (!dev->key)
+return 0;
+
 xkbi = dev->key->xkbInfo;
 xkb = xkbi->desc;
 
@@ -2495,6 +2498,9 @@ _XkbSetMap(ClientPtr client, DeviceIntPtr dev, 
xkbSetMapReq * req, char *values)
 XkbSrvInfoPtr xkbi;
 XkbDescPtr xkb;
 
+if (!dev->key)
+return Success;
+
 xkbi = dev->key->xkbInfo;
 xkb = xkbi->desc;
 
commit fabc4219622f3c0b41b1cb897c46e092377059e3
Author: Samuel Thibault 
Date:   Mon Jul 1 02:33:26 2019 +0200

Fix crash on XkbSetMap

Since group_info and width are used for the key actions allocations,
when modifying them we need to take care of reallocation key actions if
needed.

diff --git a/xkb/xkb.c b/xkb/xkb.c
index 9bd45a34a..3162574a4 100644
--- a/xkb/xkb.c
+++ b/xkb/xkb.c
@@ -2110,6 +2110,9 @@ SetKeySyms(ClientPtr client,
 }
 }
 }
+if (XkbKeyHasActions(xkb, i + req->firstKeySym))
+XkbResizeKeyActions(xkb, i + req->firstKeySym,
+XkbNumGroups(wire->groupInfo) * wire->width);
 oldMap->kt_index[0] = wire->ktIndex[0];
 oldMap->kt_index[1] = wire->ktIndex[1];
 oldMap->kt_index[2] = wire->ktIndex[2];

Bug#931379: => operator becomes = > thus creating syntax errors

[Xavier]

Le 03/07/2019 à 17:13, 積丹尼 Dan Jacobson a écrit :
> X-Debbugs-Cc: fayl...@gmail.com
> Package: libjavascript-beautifier-perl
> Version: 0.25-1
> Severity: grave
> File: /usr/bin/js_beautify
> 
> js_beautify changes the => operator into = > thus creating syntax
> errors, making one's code unusable.
> 
> fetch('https://example.com/').then(resp = >resp.blob()).then(blob = >{
> const url = window.URL.createObjectURL(blob);
> const a = document.createElement('a');
> a.style.display = 'none';
> a.href = url;
> // the filename you want
> a.download = 'z.html';
> document.body.appendChild(a);
> a.click();
> window.URL.revokeObjectURL(url);
> alert('your file has downloaded!');
> }).
> catch(() = >alert('oh no!'));

Hello,

could you test my patch [1] ?

Cheers,
Xavier

[1]:
https://salsa.debian.org/perl-team/modules/packages/libjavascript-beautifier-perl/blob/master/debian/patches/missing-operator.patch

Bug#931377: RFS: gcc-8-doc/8.3.0-1 [put in ITP, ITA, RC, NMU if applicable]

[Adam Borowski]

On Wed, Jul 03, 2019 at 08:00:27PM +0300, Dmitry Eremin-Solenikov wrote:
> ср, 3 июл. 2019 г. в 18:52, Adam Borowski :
> > It's a pity neither Guo nor you managed to update the docs before Buster,
> > but 1. we can upload this to buster-backports soon,
> 
> Should I do anything manually to do this upload?

There's nothing we can do before this package passes NEW and migrates to
testing.

> > and 2. there's a nice
> > fresh Bullseye open for uploads within the migration delay.
> 
> For now they are waiting in NEW.

Right.

> > It'd be great if you could do gcc-9-doc as well.
> 
> Sure, I'll take a look within a month (or if gcc-9 is uploaded to unstable).

Heh, I'm way too eager here -- I believed gcc-9 is long since in unstable,
merely not in buster.

> For now my priority would be to push updated gcc-doc-defaults to unstable
> (packages are ready, you can check them on mentors.debian.net).

Right; let's wait for ftpfolks.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up.  This
⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project.
⠈⠳⣄ 

Bug#720096: rsyslog ignores rotated log file

[Harald Dunkel]

On 7/3/19 6:05 PM, Michael Biebl wrote:
> Am 03.07.19 um 17:45 schrieb Harald Dunkel:
>> I have commented out the delaycompress in all logrotate config files (>10)
>> on all my Debian hosts (>300) running squeeze and newer.
>>
>> No problem since then, AFAICT.
> 
> And with delaycompress you still encounter the problem?
> If so, does it affect recent versions of rsyslog as well?
> 

Sorry to say, but I don't have hosts in this configuration anymore.
These are production hosts. Its pretty painful if some logfiles
are overwritten.

In 2013 there was no systemd yet (AFAIR), but today I am using both
systemd and sysvinit (without delaycompress).


Regards
Harri



signature.asc
Description: OpenPGP digital signature

Bug#931005: exim4-config: Restricted characters in address ^.*x24 : ^.*0.44

[Marc Haber]

On Mon, Jun 24, 2019 at 02:15:17PM +0200, Brent Clark wrote:
> I would like to ask if the following two can be added to 
> CHECK_RCPT_LOCAL_LOCALPARTS and / or CHECK_RCPT_REMOTE_LOCALPARTS
> ^.*x24 : ^.*0.44
> 
> Please see.
> https://lists.exim.org/lurker/message/20190623.215213.c6070678.en.html

I must admit that I have for the most part lost the bad things that
should be on the block list. Somebody needs to read up on the upstream
list (which I haven't read in a long time) and probably to get consensus
about the change.

Upstream still hasn't changed the defaults in its git
(https://git.exim.org/exim.git/blob_plain/HEAD:/src/src/configure.default),
so my gut feeling is that we shouldn't either.

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#931385: migrate-pubring-from-classic-gpg fails partway through if any cert in pubring.gpg is > 5MiB

[Daniel Kahn Gillmor]

Package: gnupg-utils
Version: 2.2.16-2

migrate-pubring-from-classic-gpg fails partway through if any cert in
pubring.gpg is > 5MiB, because the keybox format has a 5MiB limit per
OpenPGP certificate, which was not enforced in the old pubring.gpg
format.

migrate-pubring-from-classic-gpg should be more clever about how it
handles such a situation.

--dkg


signature.asc
Description: PGP signature

Bug#720096: rsyslog ignores rotated log file

[Michael Biebl]

Am 03.07.19 um 17:45 schrieb Harald Dunkel:
> I have commented out the delaycompress in all logrotate config files (>10)
> on all my Debian hosts (>300) running squeeze and newer.
> 
> No problem since then, AFAICT.

And with delaycompress you still encounter the problem?
If so, does it affect recent versions of rsyslog as well?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#931383: Add man page

[Sébastien Delafond]

Hello,

upstream doesn't ship one, and I unfortunately do not have the time to
write it myself. If someone does, and also commits to keeping it
synchronized with upstream releases, I'll include it in the package.

Cheers,

-- 
Seb

Bug#931384: --end_with_newline wrongly documented

[積丹尼 Dan Jacobson]

Package: jsbeautifier
Version: 1.6.4-7
Severity: minor
File: /usr/bin/js-beautify

This is fixed upstream.

$ js-beautify --end_with_newline /dev/null 2>&1 |grep -- --end_with_newline
option --end_with_newline not recognized
 -n, --end_with_newlineEnd output with newline

Need:

$ js-beautify --end-with-newline /dev/null

Bug#931383: Add man page

[積丹尼 Dan Jacobson]

Package: jsbeautifier
Version: 1.6.4-7
Severity: wishlist

No man page.

Bug#720096: rsyslog ignores rotated log file

[Harald Dunkel]

I have commented out the delaycompress in all logrotate config files (>10)
on all my Debian hosts (>300) running squeeze and newer.

No problem since then, AFAICT.


Regards
Harri

Bug#931382: O: gevent-websocket

[Benjamin Drung]

Package: wnpp
Severity: normal

Hi,

I am not using gevent-websocket any more and lack enough time to
properly maintain the package. Feel free to take over the package and/or
move it to the Python group.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet

Bug#931381: dpkg-shlibdeps build warnings

[Sebastien Bacher]

Package: usbguard
Version: 0.7.4+ds-1

The current build triggers those warnings
https://buildd.debian.org/status/fetch.php?pkg=usbguard&arch=amd64&ver=0.7.4%2Bds-1%2Bb1&stamp=1546507610&raw=0

dpkg-shlibdeps: warning: 
debian/libusbguard0/usr/lib/x86_64-linux-gnu/usbguard/libusbguard.so.0.0.0 
contains an unresolvable reference to symbol pthread_create: it's probably a 
plugin
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/libusbguard0/usr/lib/x86_64-linux-gnu/usbguard/libusbguard.so.0.0.0 was 
not linked against libdl.so.2 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/usbguard/usr/sbin/usbguard-dbus was not linked against 
libdbus-glib-1.so.2 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/usbguard/usr/sbin/usbguard-dbus was not linked against 
libgobject-2.0.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if 
debian/usbguard/usr/sbin/usbguard-dbus was not linked against libdbus-1.so.3 
(it uses none of the library's symbols)

The unresolvable reference looks like it might be worth looking at?

Cheers,

Bug#931379: Arrow functions

[積丹尼 Dan Jacobson]

http://es6-features.org/#ExpressionBodies

Bug#931380: Doesn't include a .symbols file for the library

[Sebastien Bacher]

Package: usbguard
Version: 0.7.4+ds-1

It would be nice to include a .symbols file to protect the library from
accidental ABI brekages. Debdiff attached for that
(the issue was pointed out in an Ubuntu MIR review since it's a
requirement there for a package to be accepted to the main archive)

Cheers,



diff -Nru usbguard-0.7.4+ds/debian/changelog usbguard-0.7.4+ds/debian/changelog
--- usbguard-0.7.4+ds/debian/changelog  2018-09-12 16:41:46.0 +0200
+++ usbguard-0.7.4+ds/debian/changelog  2019-07-03 16:46:36.0 +0200
@@ -1,3 +1,10 @@
+usbguard (0.7.4+ds-2) unstable; urgency=medium
+
+  * debian/libusbguard0.symbols:
+- include a .symbols to protect from accidental ABI changes
+
+ -- Sebastien Bacher   Wed, 03 Jul 2019 16:37:18 +0200
+
 usbguard (0.7.4+ds-1) unstable; urgency=medium
 
   * New upstream version 0.7.4
diff -Nru usbguard-0.7.4+ds/debian/libusbguard0.symbols 
usbguard-0.7.4+ds/debian/libusbguard0.symbols
--- usbguard-0.7.4+ds/debian/libusbguard0.symbols   1970-01-01 
01:00:00.0 +0100
+++ usbguard-0.7.4+ds/debian/libusbguard0.symbols   2019-07-03 
16:58:51.0 +0200
@@ -0,0 +1,635 @@
+libusbguard.so.0 libusbguard0 #MINVER#
+ _ZN8usbguard10AuditEvent11setCommitedEb@Base 0.7.4+ds
+ 
_ZN8usbguard10AuditEvent6commitERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 0.7.4+ds
+ 
_ZN8usbguard10AuditEvent6setKeyERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_@Base
 0.7.4+ds
+ _ZN8usbguard10AuditEvent7failureEv@Base 0.7.4+ds
+ _ZN8usbguard10AuditEvent7successEv@Base 0.7.4+ds
+ _ZN8usbguard10AuditEventC1EOS0_@Base 0.7.4+ds
+ 
_ZN8usbguard10AuditEventC1ERKNS_13AuditIdentityERSt10shared_ptrINS_12AuditBackendEE@Base
 0.7.4+ds
+ _ZN8usbguard10AuditEventC2EOS0_@Base 0.7.4+ds
+ 
_ZN8usbguard10AuditEventC2ERKNS_13AuditIdentityERSt10shared_ptrINS_12AuditBackendEE@Base
 0.7.4+ds
+ _ZN8usbguard10AuditEventD1Ev@Base 0.7.4+ds
+ _ZN8usbguard10AuditEventD2Ev@Base 0.7.4+ds
+ 
_ZN8usbguard10ConfigFile15setSettingValueERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERS6_@Base
 0.7.4+ds
+ 
_ZN8usbguard10ConfigFile4openERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEb@Base
 0.7.4+ds
+ _ZN8usbguard10ConfigFile5closeEv@Base 0.7.4+ds
+ _ZN8usbguard10ConfigFile5writeEv@Base 0.7.4+ds
+ 
_ZN8usbguard10ConfigFileC1ERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 0.7.4+ds
+ 
_ZN8usbguard10ConfigFileC2ERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE@Base
 0.7.4+ds
+ _ZN8usbguard10ConfigFileD1Ev@Base 0.7.4+ds
+ _ZN8usbguard10ConfigFileD2Ev@Base 0.7.4+ds
+ _ZN8usbguard10Predicates10isSubsetOfINS_11USBDeviceIDEEEbRKT_S5_@Base 0.7.4+ds
+ _ZN8usbguard10Predicates10isSubsetOfINS_16USBInterfaceTypeEEEbRKT_S5_@Base 
0.7.4+ds
+ 
_ZN8usbguard10Predicates10isSubsetOfINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEbRKT_SA_@Base
 0.7.4+ds
+ 
_ZN8usbguard11USBDeviceID11setVendorIDERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 0.7.4+ds
+ 
_ZN8usbguard11USBDeviceID12setProductIDERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 0.7.4+ds
+ 
_ZN8usbguard11USBDeviceID13checkDeviceIDERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_@Base
 0.7.4+ds
+ 
_ZN8usbguard11USBDeviceIDC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_@Base
 0.7.4+ds
+ _ZN8usbguard11USBDeviceIDC1ERKS0_@Base 0.7.4+ds
+ _ZN8usbguard11USBDeviceIDC1Ev@Base 0.7.4+ds
+ 
_ZN8usbguard11USBDeviceIDC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_@Base
 0.7.4+ds
+ _ZN8usbguard11USBDeviceIDC2ERKS0_@Base 0.7.4+ds
+ _ZN8usbguard11USBDeviceIDC2Ev@Base 0.7.4+ds
+ _ZN8usbguard11USBDeviceIDD1Ev@Base 0.7.4+ds
+ _ZN8usbguard11USBDeviceIDD2Ev@Base 0.7.4+ds
+ _ZN8usbguard12AuditBackend6commitERKNS_10AuditEventE@Base 0.7.4+ds
+ _ZN8usbguard12AuditBackendC1Ev@Base 0.7.4+ds
+ _ZN8usbguard12AuditBackendC2Ev@Base 0.7.4+ds
+ _ZN8usbguard12AuditBackendD0Ev@Base 0.7.4+ds
+ _ZN8usbguard12AuditBackendD1Ev@Base 0.7.4+ds
+ _ZN8usbguard12AuditBackendD2Ev@Base 0.7.4+ds
+ 
_ZN8usbguard12toRuleStringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcES6_RKT_@Base
 0.7.4+ds
+ _ZN8usbguard13AuditIdentityC1Eji@Base 0.7.4+ds
+ _ZN8usbguard13AuditIdentityC1Ev@Base 0.7.4+ds
+ _ZN8usbguard13AuditIdentityC2Eji@Base 0.7.4+ds
+ _ZN8usbguard13AuditIdentityC2Ev@Base 0.7.4+ds
+ 
_ZN8usbguard13DeviceManager11DeviceEventENS0_9EventTypeESt10shared_ptrINS_6DeviceEE@Base
 0.7.4+ds
+ _ZN8usbguard13DeviceManager12insertDeviceESt10shared_ptrINS_6DeviceEE@Base 
0.7.4+ds
+ _ZN8usbguard13DeviceManager12removeDeviceEj@Base 0.7.4+ds
+ _ZN8usbguard13DeviceManager13getDeviceListERKNS_4RuleE@Base 0.7.4+ds
+ _ZN8usbguard13DeviceManager13getDeviceListEv@Base 0.7.4+ds
+ 
_ZN8usbguard13DeviceManager15DeviceExceptionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 0.7.4+ds
+ _ZN8usbguard13DeviceManager17eventTypeToStringB5cxx11ENS0_9EventTypeE@Base 
0.7.4+ds
+ _ZN8usbguard13DeviceManager18eventTypeToIntegerENS0_9EventTypeE@Base 0.7.4+ds
+ _ZN8u

Bug#931379: => operator becomes = > thus creating syntax errors

[積丹尼 Dan Jacobson]

X-Debbugs-Cc: fayl...@gmail.com
Package: libjavascript-beautifier-perl
Version: 0.25-1
Severity: grave
File: /usr/bin/js_beautify

js_beautify changes the => operator into = > thus creating syntax
errors, making one's code unusable.

fetch('https://example.com/').then(resp = >resp.blob()).then(blob = >{
const url = window.URL.createObjectURL(blob);
const a = document.createElement('a');
a.style.display = 'none';
a.href = url;
// the filename you want
a.download = 'z.html';
document.body.appendChild(a);
a.click();
window.URL.revokeObjectURL(url);
alert('your file has downloaded!');
}).
catch(() = >alert('oh no!'));

Bug#931361: ettercap: Please update to new version 0.8.3

[Gianfranco Costamagna]

 Hello, for people interested, it is 
herehttp://debomatic-i386.debian.net/distribution#unstable/ettercap/0.8.3-1/lintian
and 
http://debomatic-amd64.debian.net/distribution#unstable/ettercap/0.8.3-1/lintian
changelog: ettercap (1:0.8.3-1) unstable; urgency=medium
 .
   * New upstream release (Closes: #931361)
 - Default to gtk-3
   * Add geoip to the build dependencies
   * Enable full hardening
   * Maintain the package under pkg-security team.
   * Drop patches, addressed upstream
   * Drop dbg package, useless now
   * Remove menu file
   * Update watch file location.
   * Bump compat level to 12
 - Drop old dh --list-missing
   * Bump std-version to 4.3.0, no changes required.
   * Update copyright file
   * Drop newlines from changelog file



I plan do some testing before uploading and merging the git repo, most of the 
work was already done during development, but I still have to manually 
andcarefully review the 83k lines of code changed (most comes from one big 
contribution I did), to see if we lost some copyrights,
but testing the deb files from the repo above might help me in having the 
required confidence in one upload.
e.g. I already found that the library is still called 0.8.2 instead of 0.8.3, 
due to a missing ${VERSION} bump in cmakelist file.
please test if possible!
G.

Il mercoledì 3 luglio 2019, 12:33:13 CEST, Barak A. Pearlmutter 
 ha scritto:  
 
 Very good. I'll assume I don't need to do anything—my favorite assumption!
—Barak.  

Bug#931366: krb5-admin-server nor krb5-kdc service cannot write their log files

[Mike Gabriel]

Control: reassign -1 debian-edu-config
Control: tags -1 - wontfix
Control: found -1 2.10.65
Control: tags -1 patch

On  Mi 03 Jul 2019 16:11:19 CEST, Mike Gabriel wrote:


Control: reassing -1 debian-edu-config
Control: tags -1 - wontfix
Control: found -1 2.10.65
Control: tags -1 patch


Sorry for the noise, typo in debbugs control commands...

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpZhz3TGQtnv.pgp
Description: Digitale PGP-Signatur

Bug#931326: gnome-maps: Segfault when looking for a location

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this issue and received the below backtrace.

This seems the same issue as in following bugs:
https://bugs.debian.org/924499
https://bugs.debian.org/928264
(And a few other reported just against current testing.)

Kind regards,
Bernhard



(gdb) bt
#0  0x7f55dec48cf5 in __GI_strtol_l_internal (nptr=0x0, 
endptr=endptr@entry=0x0, base=base@entry=10, group=group@entry=0, 
loc=0x7f55defac400 <_nl_global_locale>) at ../stdlib/strtol_l.c:293
#1  0x7f55dec48c82 in __strtol (nptr=, 
endptr=endptr@entry=0x0, base=base@entry=10) at ../stdlib/strtol.c:106
#2  0x7f55cdb102b8 in atoi (__nptr=) at 
/usr/include/stdlib.h:241
#3  0x7f55cdb102b8 in get_place_type_from_attributes (ht=0x560686ab7640) at 
geocode-forward.c:750
#4  0x7f55cdb102b8 in _geocode_create_place_from_attributes 
(ht=ht@entry=0x560686ab7640) at geocode-forward.c:792
#5  0x7f55cdb10794 in insert_place_into_tree (ht=0x560686ab7640, 
place_tree=0x560686c89150) at geocode-forward.c:887
#6  0x7f55cdb10794 in _geocode_parse_search_json 
(contents=contents@entry=0x5606856496d0 
"[{\"place_id\":595794,\"licence\":\"Data © OpenStreetMap contributors, ODbL 
1.0. 
https://osm.org/copyright\",\"osm_type\":\"node\",\"osm_id\":240109189,\"boundingbox\":[\"52.3570365\",\"52.6770365\",\"13.2288599\",\"13.5";...,
 error=error@entry=0x7ffcc4223bc0) at geocode-forward.c:999
#7  0x7f55cdb10ae6 in on_query_data_loaded (session=, 
query=0x56068748ec80 [SoupMessage], user_data=) at 
geocode-forward.c:366
#8  0x7f55cd66f5be in soup_session_process_queue_item (session=, item=0x560686f14880, should_cleanup=, loop=) at soup-session.c:2025
#9  0x7f55cd66ff42 in async_run_queue (session=session@entry=0x560685530e80 
[SoupSession]) at soup-session.c:2065
#10 0x7f55cd66fff6 in idle_run_queue (user_data=) at 
soup-session.c:2092
#11 0x7f55dfd4d6aa in g_main_dispatch (context=0x56068552e130) at 
././glib/gmain.c:3203
#12 0x7f55dfd4d6aa in g_main_context_dispatch 
(context=context@entry=0x56068552e130) at ././glib/gmain.c:3856
#13 0x7f55dfd4da60 in g_main_context_iterate 
(context=context@entry=0x56068552e130, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929
#14 0x7f55dfd4db0c in g_main_context_iteration 
(context=context@entry=0x56068552e130, may_block=may_block@entry=1) at 
././glib/gmain.c:3990
#15 0x7f55dc55f72d in g_application_run (application=0x560685654150 
[Gjs_Application], argc=2, argv=0x560685608760) at ././gio/gapplication.c:2381
#16 0x7f55dea0f038 in ffi_call_unix64 () at ../src/x86/unix64.S:76
#17 0x7f55dea0ea9a in ffi_call (cif=cif@entry=0x5606859d5cd8, fn=, rvalue=, rvalue@entry=0x7ffcc4224110, 
avalue=avalue@entry=0x7ffcc4223fe0) at ../src/x86/ffi64.c:525
#18 0x7f55dfa9c301 in gjs_invoke_c_function(JSContext*, Function*, 
JSObject*, unsigned int, jsval*, jsval*, GArgument*) 
(context=context@entry=0x56068554e4f0, function=function@entry=0x5606859d5cc0, 
obj=obj@entry=0x7f55bce98250, js_argc=js_argc@entry=1, 
js_argv=js_argv@entry=0x56068558e8f8, js_rval=js_rval@entry=0x7ffcc4224320, 
r_value=) at gi/function.cpp:999
#19 0x7f55dfa9da7f in function_call(JSContext*, unsigned int, jsval*) 
(context=0x56068554e4f0, js_argc=1, vp=0x56068558e8e8) at gi/function.cpp:1323
#20 0x7f55dbdfe8fc in js::CallJSNative(JSContext*, int (*)(JSContext*, 
unsigned int, JS::Value*), JS::CallArgs const&) (args=..., native=, cx=0x56068554e4f0) at ./jscntxtinlines.h:321
#21 0x7f55dbdfe8fc in js::Invoke(JSContext*, JS::CallArgs, 
js::MaybeConstruct) (cx=cx@entry=0x56068554e4f0, args=..., 
construct=construct@entry=js::NO_CONSTRUCT) at ./js/src/vm/Interpreter.cpp:474
#22 0x7f55dbdff918 in Interpret(JSContext*, js::RunState&) 
(cx=cx@entry=0x56068554e4f0, state=...) at ./js/src/vm/Interpreter.cpp:2298
#23 0x7f55dbe07e78 in js::RunScript(JSContext*, js::RunState&) 
(cx=cx@entry=0x56068554e4f0, state=...) at ./js/src/vm/Interpreter.cpp:438
#24 0x7f55dbe08ffa in js::ExecuteKernel(JSContext*, JS::Handle, 
JSObject&, JS::Value const&, js::ExecuteType, js::AbstractFramePtr, JS::Value*) 
(result=0x7ffcc4224ca0, evalInFrame=..., type=js::EXECUTE_GLOBAL, 
thisv=..., scopeChainArg=..., script=..., cx=0x56068554e4f0) 
at ./js/src/vm/Interpreter.cpp:622
#25 0x7f55dbe08ffa in js::Execute(JSContext*, JS::Handle, 
JSObject&, JS::Value*) (cx=cx@entry=0x56068554e4f0, script=script@entry=..., 
scopeChainArg=..., rval=rval@entry=0x7ffcc4224ca0) at 
./js/src/vm/Interpreter.cpp:659
#26 0x7f55dbeb49ed in JS::Evaluate(JSContext*, JS::Handle, 
JS::CompileOptions, unsigned short const*, unsigned long, JS::Value*) 
(cx=cx@entry=0x56068554e4f0, obj=obj@entry=..., options=..., 
chars=chars@entry=0x5606855c2a50, length=, 
rval=rval@entry=0x7ffcc4224ca0) at ./js/src/jsapi.cpp:5439
#27 0x7f55dbeb4afe in JS::Evaluate(JSContext*, JS::Handle, 
JS::CompileOptions, char const*, unsigned long, JS::Value*) 
(cx=cx@entry=0x56068554e4f0, obj=ob

Bug#931378: otrs2: Incorrect evaluation of mime certificate date fields with missing leading zero (0)

[Robert Gladewitz]

Package: otrs2
Version: 6.0.16-2
Severity: important
Tags: a11y patch

Dear Maintainer,

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

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

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


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

Kernel: Linux 4.15.18-12-pve (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages otrs2 depends on:
ii  adduser 3.118
ii  apache2 [httpd-cgi] 2.4.38-3
ii  dbconfig-common 2.0.11
ii  debconf [debconf-2.0]   1.5.71
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-1
ii  libapache-dbi-perl  1.12-2
ii  libapache2-reload-perl  0.13-2
ii  libauthen-sasl-perl 2.1600-1
ii  libcgi-pm-perl  4.40-1
ii  libclass-accessor-lite-perl 0.08-1
ii  libcrypt-eksblowfish-perl   0.009-2+b5
ii  libcrypt-passwdmd5-perl 1.40-1
ii  libcrypt-ssleay-perl0.73.06-1+b1
ii  libcss-minifier-perl0.01-2
ii  libdate-pcalc-perl  6.1-6+b2
ii  libdatetime-perl2:1.50-1+b1
ii  libdbd-mysql-perl   4.050-2
ii  libdbd-pg-perl  3.7.4-3
ii  libdbi-perl 1.642-1+b1
pn  libdigest-sha-perl  
ii  libemail-valid-perl 1.202-1
ii  libencode-hanextra-perl 0.23-5+b1
ii  libexcel-writer-xlsx-perl   0.99-1
ii  libgd-graph-perl1.54~ds-2
ii  libgd-perl [libgd-gd2-perl] 2.71-2
ii  libgd-text-perl 0.86-9
ii  libhtml-parser-perl 3.72-3+b3
ii  libhtml-tagset-perl 3.20-3
ii  libhtml-truncate-perl   0.20-2
ii  libio-interactive-perl  1.022-1
ii  libio-stringy-perl  2.111-3
ii  libjavascript-minifier-perl 1.14-1
ii  libjson-perl4.02000-1
ii  libjson-xs-perl 3.040-1+b1
ii  liblingua-translit-perl 0.28-1
ii  liblinux-distribution-perl  0.23-1
ii  libmail-imapclient-perl 3.42-1
ii  libmail-pop3client-perl 2.19-1
ii  libmailtools-perl   2.18-1
ii  libmime-tools-perl  5.509-1
ii  libmodule-refresh-perl  0.17-1
ii  libnet-imap-simple-perl 1.2211-1
ii  libnet-imap-simple-ssl-perl 1.3-4
ii  libnet-ldap-perl1:0.6500+dfsg-1
ii  libnet-smtp-ssl-perl1.04-1
ii  libnet-smtp-tls-butmaintained-perl  0.24-2
ii  libnet-sslglue-perl 1.058-1
ii  libpdf-api2-perl2.033-1
ii  libpod-strip-perl   1.02-2
ii  libproc-daemon-perl 0.23-1
ii  libschedule-cron-events-perl1.95-1
ii  libsisimai-perl 4.24.1-1
ii  libsoap-lite-perl   1.27-1
ii  libsys-hostname-long-perl   1.5-1
ii  libtemplate-perl2.27-1+b1
ii  libtext-csv-perl1.99-1
ii  libtext-csv-xs-perl 1.38-1
ii  libtext-diff-perl   1.45-1
ii  libxml-feedpp-perl  0.95-1
ii  libxml-libxml-perl  2.0134+dfsg-1
ii  libxml-libxml-simple-perl   0.99-1
ii  libxml-libxslt-perl 1.96-1+b1
ii  libxml-parser-lite-perl 0.722-1
ii  libxml-parser-perl  2.44-4
ii  libxml-simple-perl  2.25-1
ii  libyaml-libyaml-perl0.76+repack-1
ii  libyaml-perl1.27-1
ii  perl5.28.1-6
ii  ttf-dejavu-core 2.37-1
ii  ttf-dejavu-extra2.37-1
ii  ucf 3.0038+nmu1

Versions of packages otrs2 recommends:
ii  aspell0.60.7~20110707-6
ii  postgresql-client 11+200+deb10u1
ii  postgresql-client-10 [postgresql-client]  10.5-1
ii  postgresql-client-11 [postgresql-client]  11.4-1
ii  procmail  3.22-26

Versions of packages otrs2 suggests:
ii  default-mysql-server  1.0.5

-- debconf information:
  otrs2/mysql/admin-pass: (password omitted)
  otrs2/pgsql/admin-pass: (password omitted)
  otrs2/password-confirm: (password omitted)
  otrs2/mysql/app-pass: (password omitted)
  otrs2/app-password-confirm: (password omitted)
  otrs2/pgsql/app-pass: (p

Bug#931377: RFS: gcc-8-doc/8.3.0-1 [put in ITP, ITA, RC, NMU if applicable]

[Dmitry Eremin-Solenikov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gcc-8-doc"

* Package name: gcc-8-doc
  Version : 8.3.0-1
  Upstream Author : FSF
* URL : http://gcc.gnu.org/
* License : GFDL-1.2+, GFDL-1.3+, GPL-2+, GPL-3+
  Section : doc

It builds those binary packages:

cpp-8-doc_8.3.0-1_all.deb non-free/doc optional
gcc-8-doc_8.3.0-1_all.deb non-free/doc optional
gcc-8-doc_8.3.0-1_amd64.buildinfo non-free/doc optional
gccgo-8-doc_8.3.0-1_all.deb non-free/doc optional
gfortran-8-doc_8.3.0-1_all.deb non-free/doc optional
gnat-8-doc_8.3.0-1_all.deb non-free/doc optional


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

https://mentors.debian.net/package/gcc-8-doc


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

dget -x 
https://mentors.debian.net/debian/pool/non-free/g/gcc-8-doc/gcc-8-doc_8.3.0-1.dsc

Changes since the last upload:

[Dmitry Eremin-Solenikov]
  * New maintainer.
  * Thanks to Guo Yixuan for his work on this package.
  * New upstream branch. (Closes: #908589)
  * Synced patches with gcc-8, 8.3.0-6
  * d/control: correct Vcs-* tags
[Guo Yixuan]
  * Mark the package as auto-buildable.
  * Bumped standards version to 4.1.0, no changes needed.
  * Synced patches with gcc-7, 7.2.0-3, no changes needed.

Regards,
Dmitry Eremin-Solenikov

Bug#594506: konsole crashed (signal 11)

[djringjr]

Package: konsole
Version: 4:18.04.0-1
Followup-For: Bug #594506

Dear Maintainer,


konsole crashes or freezes in Buster - have to use mate-terminal instead.



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

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

Versions of packages konsole depends on:
ii  kio   5.54.1-1
ii  konsole-kpart 4:18.04.0-1
ii  libc6 2.28-10
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-1
ii  libkf5configgui5  5.54.0-1
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5crash5  5.54.0-1
ii  libkf5dbusaddons5 5.54.0-1
ii  libkf5globalaccel55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5iconthemes5 5.54.0-1
ii  libkf5kiowidgets5 5.54.1-1
ii  libkf5notifyconfig5   5.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5windowsystem5   5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libstdc++68.3.0-6

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#931366: krb5-admin-server nor krb5-kdc service cannot write their log files

[Mike Gabriel]

Control: reassing -1 debian-edu-config
Control: tags -1 - wontfix
Control: found -1 2.10.65
Control: tags -1 patch

Hi Sam,

On  Mi 03 Jul 2019 15:07:22 CEST, Sam Hartman wrote:


control: tags -1 wontfix

So, the krb5 packages as installed log to syslogd/journald and do not
log to kdc.log.


Ah, ok. The logging is supposed to end up in syslogd/journald...


debian edu is doing something to change that, which is probably a debian
edu bug.  Also, it seems likely that if debian edu is messing with the
config files of krb5, it's a serious bug under policy because debian edu
is messing with the configuration of a package not its own.


... and, yes, Debian Edu messes programmatically with other packages'  
files (see #311188).



If you are going to change the logging, then you can also add a systemd
fragment that gives the kdc permission to write to that log.


The patch required for Debian Edu's krb5.conf is this:

```
--- /etc/krb5.conf.orig 2019-07-03 16:03:44.199642437 +0200
+++ /etc/krb5.conf  2019-07-03 16:03:40.023642539 +0200
@@ -19,11 +19,6 @@
 .intern = INTERN
 intern = INTERN

-[logging]
-kdc = FILE:/var/log/kdc.log
-kadmin = FILE:/var/log/kadmin.log
-default = FILE:/var/log/krb5.log
-
 [dbdefaults]
 ldap_kerberos_container_dn = cn=kerberos,dc=skole,dc=skolelinux,dc=no

```


But another package in Debian should not make this change and override
krb5's decisions about where its logs go.


In theory, well spoken.

However, as the Debian Edu deployment process needs to tweak the  
default settings of many Debian packages tremendously, issue #311188  
affects many many Debian packages.


The situation has improved greatly over the past years, but we have  
not reached a point where we can close #311188, yet.


Where we can, we use /etc/.conf.d/ directories and drop config  
snippets in there. Or we could convince package maintainers to make  
their packages configurable via debconf preseeding.


For /etc/krb5.conf, we currently replace the file and drop in a  
replacement that works on the Debian Edu network. On the other hand, I  
guess we have never asked for help for your side (with the krb5  
maintainer's hat on).


This bug has now been reassigned to debian-edu-config, let's see if  
that will end up in the next 10.1 point release or only in Debian  
(Edu) 11.


Greets,
Mike



--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpo8UlIHvcoA.pgp
Description: Digitale PGP-Signatur

Bug#930118: libconfig-model-dpkg-perl: adds debian/compat despite debhelper-compat

[Dominique Dumont]

On Wed, 12 Jun 2019 19:54:51 +0200 gregor herrmann  wrote:
> One might argue that forcing this change-of-style is a bit intrusive;
> but on the other hand it's supported by debhelper in buster and
> stretch-backports and is now the recommended way … So yes, I think a
> migration would be a good idea.

ok, it turns out that this migration is quite complicated. 

Here's what I plan to implement. I hope this 
takes into account most common mistakes. This list below details the checks 
that will be
run on debhelper or debherlper-compat dependencies. (this doc looks better with 
a monospace font).

Please tell me if I missed something (or if it's too much)..

Both check can be applied on a dependency if the dependency is changed
from debhelper to debhelper-compat:

** debhelper dependency check

Depending on ~debian/compat~ content and ~debhelper~ depencency value,
the check and fix steps will behave this way:

| compat | debhelper version  | check| fix  
 |
|++--+---|
| undef  | undef  | error| error
 |
| undef  | defined| warn missing compat  | set compat to dh 
version  |
| < 9| consistent with compat | warn about old compat| update compat 
and dh version  |
| < 9| inconsistent   | warn about old compat| update compat 
and dh version  |
| >=9| ignored| warn no debhelper-compat | change 
dependency to debhelper_compat = $compat_value |

Note that all check are tried one by one. More than one fix can be
applied. For instance, during a fix, a ~compat~ set to 8 is changed to
12, then the ~debhelper~ dependency is changed to ~debhelper-compat =
12~ and ~compat~ is deleted by the rules shown below.

** debhelper-compat dependency check

Depending on ~debian/compat~ content and ~debhelper-compat~ depencency
value, the check and fix steps will behave this way:

| compat| debhelper-compat version | check | fix   |
|---+--+---+---|
| defined   | defined  | warn extra compat | delete compat |
| undefined | < current dh compat - 1  | warn too old  | update dependency |


** global check

need to check in Buid-Depends that debhelper and debhelper-compat do not coexist

Bug#554999: tex4ht: oolatex should fails when it encounters errors

[Hilmar Preuße]

reopen 554999
found 554999 2018.20190227-2
stop

On 07.11.09 21:23, Luca Capello wrote:

> I found that in two occasions oolatex exits with error code 0 even if
> the OpenDocument Format file produced is not correct, because previous
> errors occurred:
> 
>   http://bugs.debian.org/554995 (JRE not installed)
>   http://bugs.debian.org/554998 (problems with math mode)
> 
> IMHO this behavior is a bug, since there is no way to know if the
> resulting ODF is OK without opening it.  Instead, oolatex should stop as
> soon as it encounters the first error.
> 
This bug is still valid for mk4ht at least in oolatex mode. Reopening.

hille@amd64-sid:~/devel/TeXLive/open_bugs/571061$ mk4ht oolatex 571061.tex



System return: 0
System call: java -classpath
/usr/share/texlive/texmf-dist/tex4ht/bin/tex4ht.jar xtpipes -i
/usr/share/texlive/texmf-dist/tex4ht/xtpipes/ -o 571061.4oo 571061.tmp
sh: 1: java: not found
--- Warning --- System return: 32512



System return: 0
System call: mvsxw-571061.dir/571061.odt .
mv: cannot stat 'sxw-571061.dir/571061.odt': No such file or directory
--- Warning --- System return: 256
hille@amd64-sid:~/devel/TeXLive/open_bugs/571061$ echo $?
0
hille@amd64-sid:~/devel/TeXLive/open_bugs/571061$ dpkg -l
texlive-plain-generic
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture Description
+++-=-===--=
ii  texlive-plain-generic 2018.20190227-2 all  TeX Live: Plain
(La)TeX packages
hille@amd64-sid:~/devel/TeXLive/open_bugs/571061$

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931376: debian-security-support: mention nodejs is not for untrusted content

[Holger Levsen]

package: debian-security-support
x-debbugs-cc: debian-...@lists.debian.org

On Wed, Jul 03, 2019 at 02:59:39PM +0200, Sylvain Beucler wrote:
> I just discovered this while triaging node-fstream:
> https://www.debian.org/releases/oldstable/amd64/release-notes/ch-information.en.html#libv8
> https://www.debian.org/releases/stable/amd64/release-notes/ch-information.en.html#libv8
> 
> "Unfortunately, this means that libv8-3.14, nodejs, and the associated
> node-* package ecosystem should not currently be used with untrusted
> content, such as unsanitized data from the Internet.
> In addition, these packages will not receive any security updates during
> the lifetime of the Jessie release."

ouch.

> I'm surprised that `grep -ir node` doesn't find any match in the
> 'debian-security-support' repo.
> Did I miss something or is it something we should do?

see above & thanks! :)


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#931375: unblock: calamares-settings-debian/10.0.24-1

[Jonathan Carter]

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

Please unblock package calamares-settings-debian

I realise it's 3 days before release weekend, this upload fixes a problem
that we can't really fix in a security update. Yesterday a user discovered
that their encryption key for their hard disk in a full-disk-encryption
setup is world-readable on debian-based systems using initramfs-tools.

This affects Calamares users who can now install Debian on in an easy to
use full-disk encryption setup. Upstream bug:
https://github.com/calamares/calamares/issues/1191

CVE:
https://nvd.nist.gov/vuln/detail/CVE-2019-13179

This upload updates the bootloader-config script with this additional snippet:
"""
# Set secure permissions for the initramfs,
# the initramfs is re-generated later in the installation process
# so we only set the permissions without regenerating the initramfs now:
echo "UMASK=0077" > $CHROOT/etc/initramfs-tools/conf.d/initramfs-permissions
"""

Which will cause "update-initramfs -u" that runs later in the script to write
the initramfs with safe permissions.

Without this upload, users will have to write that file theirselves in order
to have a setup safe from local users (or users on the system with filesystem
access). In such a case we'll note it in the release notes, but I would urge
the release team to consider it if there is still any possibility.

Bug#928287: qutip debian packaging

[Gürkan Myczko]

Hi Drew

very nice you've filed an ITP for qutip, how are you progressing with 
the debian packaging?


Best,

Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements

[Alex Riesen]

Charles Plessy, Wed, Jul 03, 2019 14:59:42 +0200:
> Le Mon, Jul 01, 2019 at 03:52:47PM +0200, Alex Riesen a écrit :
> > 
> > diff --git a/update-mime b/update-mime
> 
> Thanks a lot.  I suppose you do not mind your name and email appearing
> in the commit or in the package's changelog ? ...

I don't. Glad I could help!

Regards,
Alex

Bug#931366: krb5-admin-server nor krb5-kdc service cannot write their log files

[Sam Hartman]

control: tags -1 wontfix

So, the krb5 packages as installed log to syslogd/journald and do not
log to kdc.log.

debian edu is doing something to change that, which is probably a debian
edu bug.  Also, it seems likely that if debian edu is messing with the
config files of krb5, it's a serious bug under policy because debian edu
is messing with the configuration of a package not its own.

If you are going to change the logging, then you can also add a systemd
fragment that gives the kdc permission to write to that log.
But another package in Debian should not make this change and override
krb5's decisions about where its logs go.

--Sam

Bug#931300: mime-support: update-mime incorrectly handles MimeType containing empty elements

[Charles Plessy]

Le Mon, Jul 01, 2019 at 03:52:47PM +0200, Alex Riesen a écrit :
> 
> diff --git a/update-mime b/update-mime
> index d27b8a9..55495ee 100755
> --- a/update-mime
> +++ b/update-mime
> @@ -157,7 +157,10 @@ sub ReadDesktopEntries
>   $exec .= " %s" if ($exec !~ m/%s/);
>   }
>   elsif (m/MimeType=(.*)/i) {
> - push @types, split(/;/, $1);
> + my $err = 0;
> + push @types, grep { if (length>0) {1} 
> else {++$err;0} }
> +  split(/\s*;\s*/, $1);
> + print STDERR "Warning: $file:$.: 
> ignoring empty entries in MimeType\n" if $err;
>   }
>   }
>   if (!defined($exec) || !scalar(@

Thanks a lot.  I suppose you do not mind your name and email appearing
in the commit or in the package's changelog ?  The commit would be as
follows:

commit 21035f879b53416df6c7f74720c6ff4da3e1f94a
Author: Alex Riesen 
Date:   Wed Jul 3 21:54:55 2019 +0900

update-mime: softly reject empty media types

Closes: #931300
Signed-off-by: Charles Plessy 

I will only upload the package after the end of the Freeze, hopefully soon :)

Have a nice day,

Charles

-- 
Charles Plessy
Akano, Uruma, Okinawa, Japan

Bug#931374: linux: enable nx-crypto on ppc64 (power7+ cpus)

[anatoly pugachev]

Source: linux
Severity: wishlist

Hello!

Can you please enable nx-crypto module on ppc64 arch for Power7+ cpus,
to enable crypto accelerators included with mentioned cpu.

Linux kernel config options:

CONFIG_CRYPTO_DEV_NX
CONFIG_CRYPTO_DEV_NX_ENCRYPT
CONFIG_CRYPTO_DEV_NX_COMPRESS
CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES
CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV

(probably as modules)

Thanks.


-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unreleased')
Architecture: ppc64

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

Bug#931363: Fails to create output PDF (permission denied)

[Martin-Éric Racine]

ke 3. heinäk. 2019 klo 14.51 martin f krafft (madd...@debian.org) kirjoitti:
>
> I straced gs run directly (as user "nobody"), as well as gs run from
> cupsd. After replacing all hex addresses with 0xdeadbeef, the two
> traces are nigh identical, except cupsd seems to close FDs 0–2, so
> that when run from cupsd, the first FD used is 0, whereas it's 3
> otherwise.
>
> Apart from that, I see absolutely no difference in the syscalls
> until one of the fails to write the output file.
>
> Straces attached. Go ahead load them in vimdiff!

Thanks. Let's see if we can figure out what causes this.

Volker: please see the whole thread at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931363

Thanks!
Martin-Éric

Bug#931373: calamares-settings-debian: default permissions on initramfs is insecure for full-disk encryption

[Jonathan Carter]

Package: calamares-settings-debian
Version: 10.0.20-1
Severity: normal

calamares supports full disk encryption using luks and grub.

It installs an encryption key in the initramfs, the problem is
that in Debian, the initramfs is world readable by default, which
means that a user on an unlocked system could retrieve the unlock
key.

Creating a file called /etc/initramfs-tools/conf.d/initramfs-permissions
containing UMASK=0077 will result in a more secure configuration, and
can be done from the calamares-settings-debian package.

Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7? -7~deb10+1?

[Thorsten Glaser]

retitle 931358 buster-pu (pre-approval): musescore/2.3.2+dfsg2-7~deb10u1
thanks

Hi again,

now, with sensible amounts of coffee input, the debdiff as
prepared in git and of an actual .dsc/.changes ready for
uploading, attached.

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)diff -Nru musescore-2.3.2+dfsg2/debian/changelog 
musescore-2.3.2+dfsg2/debian/changelog
--- musescore-2.3.2+dfsg2/debian/changelog  2019-04-19 21:02:11.0 
+0200
+++ musescore-2.3.2+dfsg2/debian/changelog  2019-07-03 14:22:57.0 
+0200
@@ -1,3 +1,15 @@
+musescore (2.3.2+dfsg2-7~deb10u1) buster; urgency=high
+
+  * Rebuild 2.3.2+dfsg2-7 for buster-updates (cf. #931040)
+
+ -- Thorsten Glaser   Wed, 03 Jul 2019 14:22:57 +0200
+
+musescore (2.3.2+dfsg2-7) unstable; urgency=high
+
+  * Disable webkit functionality (Closes: #931021)
+
+ -- Thorsten Glaser   Mon, 24 Jun 2019 18:07:46 +0200
+
 musescore (2.3.2+dfsg2-6) unstable; urgency=medium
 
   * Workaround for DEP 5 syntax in a complex case
diff -Nru musescore-2.3.2+dfsg2/debian/control 
musescore-2.3.2+dfsg2/debian/control
--- musescore-2.3.2+dfsg2/debian/control2019-04-18 15:56:57.0 
+0200
+++ musescore-2.3.2+dfsg2/debian/control2019-07-03 14:22:23.0 
+0200
@@ -28,7 +28,6 @@
libpulse-dev,
libqt5opengl5-dev,
libqt5svg5-dev,
-   libqt5webkit5-dev,
libqt5xmlpatterns5-dev,
libsndfile1-dev (>= 1.0.25),
portaudio19-dev,
diff -Nru musescore-2.3.2+dfsg2/debian/rules musescore-2.3.2+dfsg2/debian/rules
--- musescore-2.3.2+dfsg2/debian/rules  2019-04-18 14:35:38.0 +0200
+++ musescore-2.3.2+dfsg2/debian/rules  2019-07-03 14:22:23.0 +0200
@@ -37,6 +37,9 @@
 CMAKE_DEFS+=   -DBUILD_PORTMIDI=OFF
 endif
 
+# disable phoning home
+CMAKE_DEFS+=   -DBUILD_WEBKIT=OFF
+
 override_dh_auto_configure:
dh_auto_configure -- ${CMAKE_DEFS}
 

Bug#930485: A patch for LIRC with kernel 4.19 and gpio-ir

[Takashi Kanamaru]

Dear Gianfranco and Alec,

Thank you for accepting the patch.

If possible, please accept also the patch for lirc 0.10.1-5.2
because the release of Debian Buster is approaching.

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

Sincerely,

Takashi Kanamaru

Bug#931367: texlive-plain-generic: Need to Suggest Java runtime engine?

[Hilmar Preuße]

retitle 931367 texlive-plain-generic: Need to Suggest Java RE!
stop

On 03.07.19 11:58, Hilmar Preusse wrote:

> Just a quick reminder: the package provides a file called
> 
> /usr/share/texlive/texmf-dist/tex4ht/bin/tex4ht.jar
> 
> ..i.e. a jar file, which needs a JRE to be executed. In former times,
> when tex4ht was still packaged, as Suggest relationship was defined
> (#486482).
> 
> We need to double check if that jar file is still used and if yes
> re-add the suggests entry.
> 
As learned in #571061:

System call: java -classpath
/usr/share/texlive/texmf-dist/tex4ht/bin/tex4ht.jar xtpipes -i
/usr/share/texlive/texmf-dist/tex4ht/xtpipes/ -o 571061-m2.4om 571061-m2.tmp
sh: 1: java: not found
--- Warning --- System return: 32512

So we need java and it needs to be added to suggests!

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#931372: RFS: dunst/1.4.1-1 [ITA] -- dmenu-ish notification-daemon

[Nikos Tsipinakis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dunst"

 Package name: dunst
 Version : 1.4.1-1
 Upstream Author : Sascha Kruse 
 URL : https://dunst-project.org/
 License : BSD 3-clause
 Section : x11

It builds those binary packages:

  dunst - dmenu-ish notification-daemon

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

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


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

  dget -x https://mentors.debian.net/debian/pool/main/d/dunst/dunst_1.4.1-1.dsc

Changes since the last upload:

  [ Francois Marier ]
  * Use sensible-browser instead of Firefox in /etc/xdg/dunst/dunstrc
  (Closes: #929456)

  [ Nikos Tsipinakis ]
  * Update maintainer (Closes: #930310)
  * New upstream version 1.4.1
  * Remove cross.patch (applied upstream)
  * Refresh patches
  * Update Build-Depends
  * Bump standards version
  * Install release notes in docs
  * Bump debhelper compat to 12
  * Update copyright file

Regards,
 Nikos Tsipinakis

Bug#931363: Fails to create output PDF (permission denied)

[martin f krafft]

I straced gs run directly (as user "nobody"), as well as gs run from 
cupsd. After replacing all hex addresses with 0xdeadbeef, the two 
traces are nigh identical, except cupsd seems to close FDs 0–2, so 
that when run from cupsd, the first FD used is 0, whereas it's 3 
otherwise.


Apart from that, I see absolutely no difference in the syscalls 
until one of the fails to write the output file.


Straces attached. Go ahead load them in vimdiff!

--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

"it takes more keystrokes to enter a windows license key
than it takes to do a complete debian desktop install!"
   -- joey hess


gs-run-from-cupsd.strace.xz
Description: application/xz


gs-run-from-shell.strace.xz
Description: application/xz


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#896119: still a problem on buster

[Nrbrtx]

ATOMS is still broken on buster:

 dpkg -l | grep scilab
ii  cantor-backend-scilab
4:18.12.0-2 amd64Scilab backend for Cantor
ii  scilab
6.0.1-10all  Scientific software
package for numerical computations
ii  scilab-cli
6.0.1-10all  Scientific software
package - Command Line Interpreter
ii  scilab-data
6.0.1-10all  Scientific software
package for numerical computations (data files)
ii  scilab-doc
6.0.1-10all  Scientific software
package (English documentations)
ii  scilab-full-bin
6.0.1-10amd64Scientific software
package for numerical computations (all binary files)
ii  scilab-include
6.0.1-10amd64Scientific software
package for numerical computations (include files)
ii  scilab-minimal-bin
6.0.1-10amd64Scientific software
package for numerical computations (minimal binary files)
ii  scilab-test
6.0.1-10all  Scientific software
package for numerical computations (test files)


--


Scilab 6.0.1 console:

Startup execution:
  loading initial environment

--> atomsSystemUpdate
Scanning repository http://atoms.scilab.org/6.0 ... Done

at line   265 of function atomsDESCRIPTIONget (
/usr/share/scilab/modules/atoms/macros/atoms_internals/atomsDESCRIPTIONget.sci
line 284 )
at line16 of function atomsSystemUpdate   (
/usr/share/scilab/modules/atoms/macros/atomsSystemUpdate.sci line 33 )

atomsDESCRIPTIONget: save
('/home/debian/.Scilab/scilab-6.0.1/.atoms/packages') has failed.



Terminal output:

HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140621311393408:
  #000: ../../../src/H5G.c line 548 in H5Gget_info(): invalid argument
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140621311393408:
  #000: ../../../src/H5G.c line 299 in H5Gcreate2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 246 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140621311393408:
  #000: ../../../src/H5A.c line 263 in H5Acreate2(): not a location
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 246 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140621311393408:
  #000: ../../../src/H5D.c line 119 in H5Dcreate2(): not a location ID
major: Invalid arguments to routine
minor: Inappropriate type
  #001: ../../../src/H5Gloc.c line 246 in H5G_loc(): invalid object ID
major: Invalid arguments to routine
minor: Bad value
HDF5-DIAG: Error detected in HDF5 (1.10.4) thread 140621311393408:
  #000: ../../../src/H5F.c line 664 in H5Fclose(): not a file ID
major: File accessibilty
minor: Inappropriate type
failed to close file



Please fix this bug before Debian buster release!!!

Bug#931371: release-notes: Advice as to migration from legacy network interface names

[Brian Potkin]

Package: release-notes
Severity: normal



I have upgraded two systems having 70-persistent-net.rules. In both
cases the ethernet interfaces remained at eth0. It appears to me that
warning of losing networking after the upgrade to buster is a little
over the top.

Does #919390 offer any relevant guidance?

Regards,

Brian.

Bug#931363: Fails to create output PDF (permission denied)

[martin f krafft]

Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 14:13 Uhr +0300:
I just tried on my stable host.  This used to work until a few weeks 
ago, but it no longer does.


Can you reproduce the problem?

CUPS-PDF has not been updated, but Ghostscript has received 
security updates twice in recent times. I'm thus extremely tempted 
to reassign to Ghostscript.


I cannot reproduce the problem with Ghostscript. I used

 cd /var/spool/cups-pdf/SPOOL
 while :; do sudo ln * saved && break; done

to capture the temporary file, and then ran:

 /usr/bin/gs -q -dCompatibilityLevel=1.5 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite 
-sOutputFile="/home/ssd/madduck/PDF/stdin___madduck_PDF.pdf" 
-dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false 
-dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /tmp/saved

as gleaned from the log. This created the PDF file just fine though.

If I use "sudo -u nobody" to run the process, then gs obviously 
fails, *unless* I make the target directory 1777, in which case it 
works and writes the PDF file.


However, gs, as called by cups-pdf, still fails to write the file in 
exactly the same setting.


What else could be different?

--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

"if java had true garbage collection,
most programs would delete themselves upon execution."
   -- robert sewell


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#854978: CVE-2017-2581 reproducer

[Sylvain Beucler]

Attached.

I cannot reproduce the segfault with netpbm-10.47.63 on Jessie nor with
our netpbm-free.
This looks like a random crash so compiler hardening might be mitigating.
I asked the reporter for more info.

Source:
https://bugzilla.suse.com/show_bug.cgi?id=1024287
https://bugzilla.suse.com/attachment.cgi?id=716295

Bug#931358: release.debian.org: buster-pu (pre-approval): musescore/2.3.2+dfsg2-7? -7~deb10+1?

[Thorsten Glaser]

Hi,

>> It would need to be a new upload, indeed. The version seems sensible,
>> and target would indeed be "buster". Please attach a debdiff of the
>> proposed upload to this report (but do not upload it at this stage).

thanks, will do.

>Actually, as Salvatore pointed out on IRC, that should be -7~deb10u1,
>to follow the usual convention. I should not try and be useful pre-
>coffee...

Oh, indeed... same about coffee here ;) and I'm doing lots of
backports and few stable updates.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#931363: Fails to create output PDF (permission denied)

[Martin-Éric Racine]

ke 3. heinäk. 2019 klo 14.08 martin f krafft (madd...@debian.org) kirjoitti:
>
> Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 13:06 Uhr +0300:
> >My best guess is that you bumped into a symptom of upgrading from
> >cups-pdf 2 to cups-pdf 3.  The back-end has changed and maintainer
> >scripts make no attempt to upgrade the backend used by any existing
> >PDF queue. If you purge and re-install the package, does file creation
> >still fail?
>
> Yes. I purged and reinstalled, and the problem persists. I even
> removed the printer and reinstalled it. The same problem seems to be
> the case: the gs process is failing to write to the output
> directory, even if the directory is set to 777.

I just tried on my stable host.  This used to work until a few weeks
ago, but it no longer does. CUPS-PDF has not been updated, but
Ghostscript has received security updates twice in recent times. I'm
thus extremely tempted to reassign to Ghostscript.

Martin-Éric

Bug#930485: A patch for LIRC with kernel 4.19 and gpio-ir

[Alec Leamas]

On 03/07/2019 11:52, Gianfranco Costamagna wrote:

Hello Takashi,
I'm happy to upload if Alec (upstream) is willing to accept the patch!

thanks for the nice contribution!



I'm on holidays. When back, I think this patch belongs to upstream. I 
see no problem making a temporary upload with the patch applied.



--alec

Bug#931363: Fails to create output PDF (permission denied)

[martin f krafft]

Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 13:06 Uhr +0300:
My best guess is that you bumped into a symptom of upgrading from 
cups-pdf 2 to cups-pdf 3.  The back-end has changed and maintainer 
scripts make no attempt to upgrade the backend used by any existing 
PDF queue. If you purge and re-install the package, does file creation 
still fail?


Yes. I purged and reinstalled, and the problem persists. I even 
removed the printer and reinstalled it. The same problem seems to be 
the case: the gs process is failing to write to the output 
directory, even if the directory is set to 777.


--
.''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
 `-  Debian - when you have better things to do than fixing systems

fitter, healthier, more productive
like a pig, in a cage, on antibiotics
   -- radiohead


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#931370: RFS: cryptodev-linux/1.10-1 [ITP] kernel module for accessing Linux kernel cryptographic drivers

[Dmitry Eremin-Solenikov]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cryptodev-linux"

* Package name: cryptodev-linux
  Version : 1.10-1
  Upstream Author : Michal Ludvig and the rest of authors
* URL : http://cryptodev-linux.org/
* License : GPL-v2+
  Section : kernel

It builds those binary packages:

cryptodev-linux-dkms - kernel module for accessing Linux kernel cryptographic 
drivers
cryptodev-linux-dev - kernel module for accessing Linux kernel cryptographic 
drivers - header file

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

https://mentors.debian.net/package/cryptodev-linux

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

dget -x 
https://mentors.debian.net/debian/pool/main/c/cryptodev-linux/cryptodev-linux_1.10-1.dsc

More information about cryptodev-linux can be obtained from
https://cryptodev-linux.org.

-- 
With best wishes
Dmitry Eremin-Solenikov

Bug#931364: zabbix-agent: defaults to /var/run instead of /run for tmpfiles

[Dmitry Smirnov]

Thanks for the report.

On Wednesday, 3 July 2019 4:02:54 PM AEST Richard Hector wrote:
> Severity: important

How do you justify severity??

-- 
Best wishes,
 Dmitry Smirnov.

---

Our difficulties and our dangers will not be removed by closing our eyes on
them.
-- Winston Churchill


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

Bug#926712: evolution-ews: CVE-2019-3890

[Luca Boccassi]

On Mon, 17 Jun 2019 11:39:13 +0100 Luca Boccassi <
bl...@debian.org
> wrote:
> On Tue, 9 Apr 2019 15:52:52 +0200 Sylvain Beucler <
> 
b...@beuc.net

> > wrote:
> > Package: evolution-ews
> > Version: 3.30.5-1
> > X-Debbugs-CC: 
> 
t...@security.debian.org

> 
> > Severity: grave
> > Tags: security
> > 
> > Hi,
> > 
> > The following vulnerability was published for evolution-ews.
> > 
> > CVE-2019-3890[0]:
> > No description was found (try on a search engine)
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog
entry.
> > 
> > For further information see:
> > 
> > [0] 
> 
https://security-tracker.debian.org/tracker/CVE-2019-3890

> 
> > 
> 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-3890

> 
> > 
> 
https://gitlab.gnome.org/GNOME/evolution-ews/issues/27

> 
> > 
> 
https://gitlab.gnome.org/GNOME/evolution-ews/issues/36

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

> 
> > Note: depends on evolution-data-server patch
> > 
> > Cheers!
> > Sylvain Beucler / Debian LTS
> 
> Dear Maintainers,
> 
> I have backported the required patches and tested them on Buster,
they
> seem to work fine.
> 
> I have opened PRs against the 2 repos on Salsa, but they both require
a
> new debian/buster branch to be created as debian/master has moved on
to
> new releases:
> 
> 
https://salsa.debian.org/gnome-team/evolution-data-server/merge_requests/1

> 
https://salsa.debian.org/gnome-team/evolution-ews/merge_requests/2

> 
> It would be great if we could have evolution-ews in Buster, as it's
the
> only way to use exchange/o365 for Debian users.
> 
> Thanks!

Dear Maintainers,

As things stand, Buster users will have no way to use a GUI email
client with an Exchange/OWA/O365 email server. They will have to stay
on Stretch and completely skip Buster, or move to a different
distribution. If they were to upgrade from Stretch to Buster, their
email accounts would simply disappear from their evolution instances,
without any explanation nor warning.

I'd like to propose to upload the changes mentioned above to unstable,
let them migrate to Bullseye and then upload to buster-backports, so
that users on Buster have at least that path to avoid breaking this
functionality. This needs to be done before 3.32 moved from
experimental to unstable of course.

I'd be more than happy to do all of the above work via NMUs. The
evolution-data-server change is backward compatible and does not
require a rebuild of reverse dependencies. Are there any objections to
this idea?

Thank you!

-- 
Kind regards,
Luca Boccassi


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

Bug#931369: thunderbird not translated in French

[Laurent Bigonville]

Package: thunderbird
Version: 1:68.0~b1-1
Severity: normal

Hi,

On my system, I've thunderbird and the thunderbird-l10n-fr packages
installed, but thunderbird is not translated in French as I would expect.

This was working as expected with the version from unstable.

Kind regards,
Laurent Bigonville

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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-7
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-2
ii  libgtk-3-03.24.5-1
ii  libgtk2.0-0   2.24.32-3
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.21-1
ii  libnss3   2:3.44.0-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.27.2-3
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-7
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.4.1-1
ii  lightning1:68.0~b1-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.2-10
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.17-3

-- no debconf information

Bug#931361: ettercap: Please update to new version 0.8.3

[Barak A. Pearlmutter]

Very good. I'll assume I don't need to do anything—my favorite assumption!

—Barak.

Bug#931317: debian-installer: A feature to "secure erase" SSDs would be nice

[Philipp Kern]

On 2019-07-02 00:33, Ben Hutchings wrote:

On Mon, 2019-07-01 at 22:09 +0200, Philip Hands wrote:
I think it's probably rather hard to do safely, as IIRC one often 
needs

to try hdparm, then in order to cause the drive not to be locked do
something like suspend and resume the system, then set an admin
password, and only then do the secure erase ... which then takes
quite a while.

I believe that modern drives (both HD and SSD) often have their own
encryption layer, and secure erase is implemented by erasing the
encryption key and (on an SSD) marking all blocks free in the flash
translation layer.


Unfortunately the locking bit is still true for many machines, so even 
if it is quick, it can be hard to get the drive into the state where the 
BIOS did not have an opportunity to block the user from triggering the 
erase operation.


Kind regards
Philipp Kern

Bug#931361: ettercap: Please update to new version 0.8.3

[Gianfranco Costamagna]

 Hello, I plan to do the update later
G.

Il mercoledì 3 luglio 2019, 09:24:09 CEST, Raphael Hertzog 
 ha scritto:  
 
 Hi,

On mer., 03 juil. 2019, Sophie Brun wrote:
> I would like to propose you to join the pkg-security-team
> to maintain this package. If you are interested:
> https://wiki.debian.org/Teams/pkg-security

Barak, if you are interested, we can help you to move/setup the packaging
repository and to prepare the update for 0.8.3. Just let us know.

BTW, Gianfranco Costamagna who is among the Uploaders is already part of
the pkg-security team.

Regards,
-- 
Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer

  

Bug#915841: newsbeuter FTBFS with json-c 0.13.1

[Gianfranco Costamagna]

 Hello Nikos,you might want to first upload the fork in new queue, providing 
the same binary, so the removal becomes a cruft later
I mean, to not disrupt our userbase:
with moving src:a providing a to src:b providing b

create a new src:b with new fork, but provide a and provide b, since it should 
be a drop-in replacement, right?wait for it to go in testing
ask to remove only src:a because the binary is taken over by another package
does this make sense?
in case the fork is not a drop-in replacement, probably providing the old 
binary name is not worth the effort, in this caseyou can do whatever you prefer 
:)
G.

Il lunedì 1 luglio 2019, 13:46:28 CEST, Nikos Tsipinakis 
 ha scritto:  
 
 On 01/07, Gianfranco Costamagna wrote:
> there is an upstream fix in a fork called newsboat
> 
> I'm attaching both patches to this bug report, please apply them!

I apologise for ignoring this issue earlier. I initially intended to convert
newsbeuter to a stub package pointing to newsboat but missed the buster 
deadline.

Given that upstream is abandoned and there is a functionally identical fork I
intend to remove newsbeuter from the archive. It doesn't make sense to become a
pseudo-upstream to keep it in Debian.

I'll file a removal request for it next week after the Buster release.
  

Bug#931363: Fails to create output PDF (permission denied)

[Martin-Éric Racine]

ke 3. heinäk. 2019 klo 12.40 martin f krafft (madd...@debian.org) kirjoitti:
>
> Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 11:18 Uhr +0300:
> >Is the host where this fails running a cups-pdf that was upgraded from 
> >previous
> >releases?
>
> Yes, just like the other host too. These are ancient systems,
> probably pre-sarge ;)

My best guess is that you bumped into a symptom of upgrading from
cups-pdf 2 to cups-pdf 3.  The back-end has changed and maintainer
scripts make no attempt to upgrade the backend used by any existing
PDF queue. If you purge and re-install the package, does file creation
still fail?

Martin-Éric

Bug#931366: krb5-admin-server nor krb5-kdc service cannot write their log files

[hoxp18]

Dear maintainer and Mike Gabriel,

> Package: src:krb5
> Severity: important
> Version: 1.17-3
> User: debian-...@lists.debian.org
> Usertags: debian-edu
> X-Debbugs-Cc: debian-...@lists.debian.org
> 
> Hi Sam et al,
> 
> When restarting krb5-kdc or krb5-admin-server on a fresh Debian Edu  
> buster main server, I see the following logs lines in syslog:
> 
> Jul  3 11:08:16 tjener krb5kdc[22684]: Couldn't open log file  
> /var/log/kdc.log: Das Dateisystem ist nur lesbar
> [...]
> Jul  3 11:10:06 tjener kadmind[23272]: Couldn't open log file  
> /var/log/krb5.log: Das Dateisystem ist nur lesbar
> 
> (Translation: Das Dateisystem ist nur lesbar: The file system is read-only)

How about add /run/log for a final resort?
/run/log can be used "always writable" log area, though it is volatile.

$ man file-hierarchy # and find "/run/log"

> As expected by the error message, not log output gets produced.
> 
> The following two systemd service file patches fix the issue  
> (appending /var/log to ReadWriteDirectories= key):
> 
> ```
> root@tjener:~/fixes-buster# diff -u krb5-admin-server.service.orig  
> krb5-admin-server.service
> --- krb5-admin-server.service.orig2019-07-03 11:26:51.607417138 +0200
> +++ krb5-admin-server.service 2019-07-03 11:25:37.843418670 +0200
> @@ -8,7 +8,7 @@
>   EnvironmentFile=-/etc/default/krb5-admin-server
>   InaccessibleDirectories=-/etc/ssh -/etc/ssl/private  /root
>   ReadOnlyDirectories=/
> -ReadWriteDirectories=-/var/tmp /tmp /var/lib/krb5kdc -/var/run /run
> +ReadWriteDirectories=-/var/tmp /tmp /var/lib/krb5kdc -/var/run /run /var/log

say,
ReadWriteDirectories=-/var/tmp /tmp /var/lib/krb5kdc -/var/run /run /var/log 
/run/log

This would make the system can log the issue even on "/var mount point hardware 
failure".

# BTW I'm not familiar with Kerberos; just a comment.

Regards,

Bug#931368: Can't set hungarian keyboard layout with preseeded installer

[Mayer Károly]

Package: debian-installer
Severity: normal

Hi,

I added my preseed configuration to initrd on a Debian 9.9.0 installer 
media and installed the OS. I set the localization as I saw in the 
example configuration of Stretch installer:


 Contents of the preconfiguration file (for stretch)
### Localization
# Preseeding only locale sets language, country and locale.
d-i debian-installer/locale string hu_HU

# The values can also be preseeded individually for greater flexibility.
d-i debian-installer/language string hu
d-i debian-installer/country string HU
d-i debian-installer/locale string hu_HU.UTF-8
# Optionally specify additional locales to be generated.
#d-i localechooser/supported-locales multiselect hu_HU.UTF-8

# Keyboard selection.
d-i keyboard-configuration/xkb-keymap select hu
# d-i keyboard-configuration/toggle select No toggling

When I boot the installed OS I have the expected locales set but the 
keyboard layout is "us" on the console. I have no 
"/etc/default/keyboard" file where it should be set because the 
installer isn't installed the "console-setup" and the 
"keyboard-configuration" packages. If I write "console-setup" into the 
"d-i pkgsel/include string" option it installs it and the result will be 
hungarian layout, but there's a popup when installing the package and I 
have to choose(just press an enter) the keyboard layout. It's unwanted 
interaction while preseeding. If I install Debian with the newt 
interactive installer the keymap and the locales are set correctly, so 
everything available in the installer to use hungarian layout.


I tried also to set anything else the keymap, e.g. "de" or "cz". The 
result was the same: no "console-setup" and "keyboard-configuration" 
packages were installed and I got "us" layout.


How should I set the expected keyboard layout with preseeding? Is it a 
bug? Is there any solution or workaround?


I found a similar bugreport in the past: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721460


Thanks!

Bug#931092: libirman FTCBFS: Makefile.am hard codes pkg-config

[Gianfranco Costamagna]

 Hello Alec, can you please include this patch and give me something to sponsor?
thanks!
G.

Il mercoledì 26 giugno 2019, 06:48:12 CEST, Helmut Grohne 
 ha scritto:  
 
 Source: libirman
Version: 0.5.2-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libirman fails to cross build from source, because the upstream
Makefile.am hard codes the build architecture pkg-config. After making
it substitutable, libirman cross builds successfully. Please consider
applying the attached patch.

Helmut
  --- libirman-0.5.2.orig/Makefile.am
+++ libirman-0.5.2/Makefile.am
@@ -16,9 +16,9 @@
 uninstall-hook:
 	rm -f $(DESTDIR)$(plugindir)/irman.so
 
-plugindir   = $(shell pkg-config --variable=plugindir lirc-driver)
-configdir   = $(shell pkg-config --variable=configdir lirc-driver)
-plugindocsdir   = $(shell pkg-config --variable=plugindocs lirc-driver)
+plugindir   = $(shell $(PKG_CONFIG) --variable=plugindir lirc-driver)
+configdir   = $(shell $(PKG_CONFIG) --variable=configdir lirc-driver)
+plugindocsdir   = $(shell $(PKG_CONFIG) --variable=plugindocs lirc-driver)
 
 plugin_LTLIBRARIES  = irman.la
 irman_la_SOURCES= lirc-plugin/irman.c

Bug#570623: reprepro: please add multiple version management

[Michael Prokop]

Hi,

* Benjamin Drung [Wed Apr 03, 2019 at 12:11:55PM +0200]:

> I refreshed the patches on top of version 5.3.0 and pushed it to 
> https://salsa.debian.org/bdrung/reprepro/ and 
> https://github.com/profitbricks/reprepro

Thanks for your efforts, Benjamin, highly appreciated.

Bernhard, is there any specific reason why you didn't respond here
any longer? Is there anything which would help to increase chances
to get this feature merged in the near future?

regards
-mika-


signature.asc
Description: Digital signature