Bug#895115: Package does not seem to migrate to testing due to missing build on arm64

[Andreas Tille]

Hi Rhonda,

I'm just pinging both RC bugs to reset the autoremoval from testing
counter.  I just realised that the package might not migrate to testing
due to a missing arm64 build.  I leave it to you to decide about the
action to take but just wanted to prevent that you will be hit by an
autoremoval which might have escaped your attention.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#921363: Package does not migrate to testing

[Andreas Tille]

Hi Utkarsh,

I realised that you intend to take over this package but for a reason I
do not understand myself it does not migrate to testing (see testing
excuses at the tracker page:

   https://tracker.debian.org/pkg/ejs.js

).

I admit I have no idea why but if you really want to save this package
for Buster some action seems to be needed.  Please do not ask me
personally about it since I do not have the slightest interest in this
package at all but simply realised that it has the autoremoval from
testing flag set despite your upload.

Thank you for your contribution

Andreas.

-- 
http://fam-tille.de

Bug#919956: libssh-4: cockpit failing tests on hppa - crypto_scalarmult_curve25519_ref segv

[Laurent Bigonville]

On Sun, 20 Jan 2019 18:37:45 -0500 John David Anglin 
 wrote:

>

> Dear Maintainer,

Hello,

[...]
>
> The fault in frame 5 occurs in a long branch stub. It is caused because
> the PIC register, $r19, has been corrupted. When I disabled
> crypto_scalarmult_curve25519_ref (), it appears that it was not compiled
> as PIC code, yet the stub assumes it has been called from PIC code. This
> causes the segmentation fault.
>
> So far, I haven't figured out how crypto_scalarmult_curve25519_ref and

> crypto_scalarmult_curve25519_ref_base are built.

nacl was not built with -fPIC, this is now done in unstable.

libssh is currently being rebuild against that, could you please retry 
with libssh version 0.8.6-3+b1 when it hits the archive?


Thanks

Laurent Bigonville

Bug#923377: zfsutils-linux: Updating zfsutils-linux fails with "filesystem already mounted"

[Thomas Herrmann]

Package: zfsutils-linux
Version: 0.7.12-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Since some zfs updates a while ago, apt cannot set up zfsutils-linux properly:

apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up zfsutils-linux (0.7.12-2) ...
zfs-import-cache.service is a disabled or a static unit, not starting it.
zfs-import-scan.service is a disabled or a static unit, not starting it.
A dependency job for zfs.target failed. See 'journalctl -xe' for details.
insserv: script ups-monitor: service ups-monitor already provided!
insserv: script ups-monitor: service ups-monitor already provided!
Job for zfs-mount.service failed because the control process exited with error
code.
See "systemctl status zfs-mount.service" and "journalctl -xe" for details.
invoke-rc.d: initscript zfs-mount, action "restart" failed.
● zfs-mount.service - Mount ZFS filesystems
   Loaded: loaded (/etc/systemd/system/zfs-mount.service; static; vendor
preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-02-27 08:22:33 CET; 6ms
ago
  Process: 5237 ExecStart=/sbin/zfs mount tank860 (code=exited,
status=1/FAILURE)
 Main PID: 5237 (code=exited, status=1/FAILURE)

Feb 27 08:22:33 pc-tb-debian systemd[1]: Starting Mount ZFS filesystems...
Feb 27 08:22:33 pc-tb-debian systemd[1]: zfs-mount.service: Main process
exited, code=exited, status=1/FAILURE
Feb 27 08:22:33 pc-tb-debian systemd[1]: zfs-mount.service: Failed with result
'exit-code'.
Feb 27 08:22:33 pc-tb-debian systemd[1]: Failed to start Mount ZFS filesystems.
dpkg: error processing package zfsutils-linux (--configure):
 installed zfsutils-linux package post-installation script subprocess returned
error exit status 1
dpkg: dependency problems prevent configuration of zfs-initramfs:
 zfs-initramfs depends on zfsutils-linux (>= 0.7.12-2); however:
  Package zfsutils-linux is not configured yet.

dpkg: error processing package zfs-initramfs (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of zfs-zed:
 zfs-zed depends on zfsutils-linux (>= 0.7.12-2); however:
  Package zfsutils-linux is not configured yet.

dpkg: error processing package zfs-zed (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 zfsutils-linux
 zfs-initramfs
 zfs-zed
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

I am receiving this message for quite a while, I cannot tell when it occurred
first. Maybe in mid-january?

I have a ext4 boot partition, but the main root is on zfs (on tank860).

I have two different zpools:

zpool list
NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAGCAP  DEDUP  HEALTH  ALTROOT
harddisk  2.72T   816G  1.92T - 0%29%  1.00x  ONLINE  -
tank860928G   706G   222G -47%76%  1.00x  ONLINE  -



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-3-amd64 (SMP w/8 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 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages zfsutils-linux depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-7
ii  libnvpair1linux  0.7.12-2
ii  libuuid1 2.33.1-0.1
ii  libuutil1linux   0.7.12-2
ii  libzfs2linux 0.7.12-2
ii  libzpool2linux   0.7.12-2
ii  python3  3.7.2-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages zfsutils-linux recommends:
ii  lsb-base10.2018112800
ii  zfs-dkms [zfs-modules]  0.7.12-2
iu  zfs-zed 0.7.12-2

Versions of packages zfsutils-linux suggests:
ii  nfs-kernel-server  1:1.3.4-2.4
ii  samba-common-bin   2:4.9.4+dfsg-3
iu  zfs-initramfs  0.7.12-2

-- Configuration Files:
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'

-- no debconf information

Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear

[Daniel Kahn Gillmor]

Control: reassign 923068 gpg-agent 2.2.12-1

On Wed 2019-02-27 07:30:39 +0100, fulvio ciriaco wrote:

> the delay does not happen when getpin is called directly as in
> echo getpin | pinentry-gtk2

ok, so that means that the issue isn't in pinentry itself.  It's
probably in gpg-agent or elsewhere.

So the next diagnostic step is to get other things out of the loop, like
gpg itself, and just try to debug the agent and how it interoperates
with pinentry.

For example, this command should cause an immediate popup confirmation
dialog box:

gpg-connect-agent 'get_confirmation abc123' /bye


does it have a delay on the system in question?

> I read the thread for bug 800032 you pointed me to and noticed that on 
> another machine
> I have there is no delay. I noticed that on the other machine, my wm awesome 
> is launched
> directly, on the machine where the delay happens it is called through:
> exec dbus-launch awesome
> so I guess dbus-launch has to do with the problem.

do you have dbus-user-session installed on both of these systems?  how
does "exec dbus-launch awesome" itself get executed?  from a VT, or from
some other automated process?

 --dkg


signature.asc
Description: PGP signature

Bug#920692: [PATCH] Packages must not install files or directories into /var/cache

[Ansgar]

Josh Triplett writes:
> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index 48410be..1cdcb18 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -722,6 +722,15 @@ The name of the files and directories installed by 
> binary packages
>  outside the system PATH must be encoded in UTF-8 and should be
>  restricted to ASCII when it is possible to do so.
>  
> +.. _s-cache:
> +
> +Cache
> +-
> +
> +Packages must not install files or directories into ``/var/cache``. The
> +system administrator may delete any or all files from this directory at
> +any time, or may choose to put it on an ephemeral filesystem.
> +

If you allow directories to be removed at any time, it breaks non-root
programs using /var/cache: they cannot recreate them.  The FHS only
allows removing files.

Creating the directories in maintainer scripts instead of shipping them
in the package makes no difference: if you care about ephemeral
filesystems for /var/cache, you have to require something like tmpfiles
or CacheDirectory= in .service files to be used (depending on the
requirements of the package).

So I think we should require such solutions to be used over just
forbidding to ship the directory as part of the package.

Ansgar

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Guus Sliepen]

On Tue, Feb 26, 2019 at 10:37:28PM +0100, Michael Biebl wrote:

> >> Andrej, I'm fine with dropping ifupdown from the default NM
> >> configuration if the ifupdown package is going to ship such a config
> >> snippet for NM.
> > 
> > Are we talking about /etc/NetworkManager/dispatcher.d/01-ifupdown here?
> > It seems like a hack to avoid having to update some packages to directly
> > support NetworkManager. For the long run, it's probably better if we
> > don't have this dependence on scripts written for ifupdown.
> 
> No, we are talking about the ifupdown plugin in NM, i.e.
> /usr/lib/*/NetworkManager/1.14.6/libnm-settings-plugin-ifupdown.so
> 
> which is responsible for parsing /etc/network/interfaces (and depending
> on whether managed=true or false, simply ignores interfaces configured
> in /e/n/i or tries to apply the configuration set there)

Ah, OK.

> ifupdown could ship the file as /etc/NetworkManager/conf.d/ifupdown.conf
> This would have the downside, that the ifupdown plugin would still be
> active if the ifupdown package is removed, but not purged.

But it could just check for /sbin/ifup being executable before
continuing, just like init scripts do. Even better, the plugin could
just call system("/sbin/ifquery ") to check whether an
interface is managed by ifupdown or not. If the return value is 0, it
means it's managed. If it's anything else, either ifupdown is not
installed or it is but that interface is not known to ifupdown.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#923068: [pkg-gnupg-maint] Bug#923068: pinentry-gtk2 takes more than twenty seconds to appear

[fulvio ciriaco]

Dear Daniel,
the delay does not happen when getpin is called directly as in
echo getpin | pinentry-gtk2
but it happens when for example I invoke 
pass show something

I read the thread for bug 800032 you pointed me to and noticed that on another 
machine
I have there is no delay. I noticed that on the other machine, my wm awesome is 
launched
directly, on the machine where the delay happens it is called through:
exec dbus-launch awesome
so I guess dbus-launch has to do with the problem.

Best regards
Fulvio

On 2/26/19 8:49 AM, Daniel Kahn Gillmor wrote:
> Control: tags 923068 + moreinfo
> 
> Hi fc--
> 
> On Sat 2019-02-23 20:16:03 +0100, fc wrote:
>> When pinentry-gtk2 is started, the input window appears after more
>> than twenty seconds. For comparison pinentry-gnome3 and pinentry-qt
>> appear in less than two seconds for the same request.
> 
> Can you take a look at https://bugs.debian.org/800032 to see whether
> anything there looks like it might be a functioning workaround for you?
> 
> also, it's not clear to me whether you've tried pinentry-gtk2 directly,
> or whether you're measuring a delay from the use of (for example) gpg or
> gpgsm, via gpg-agent.
> 
> to test pinentry-gtk2 on its own, i'd recommend doing the following from
> a terminal:
> 
> echo getpin | pinentry-gtk-2
> 
> This should prompt you (immediately!) for a passphrase, and then echo
> that passphrase to stdout.  for example:
> 
> 0 dkg@alice:~$ echo getpin | pinentry-gtk-2 
> OK Pleased to meet you
> D abvc
> OK
> 0 dkg@alice:~$
> 
> Does that cause the delay for you?  If not, what steps *do* cause the
> delay?
> 
> Regards,
> 
>  --dkg
> 

Bug#923375: brltty breaks usb serial devices; sends potentially harmful data to unknown devices

[Samuel Thibault]

Hello,

fluffywolf, le mar. 26 févr. 2019 20:41:54 -0800, a ecrit:
> brltty's default behavior seems to to not just claim all usb serial devices,

No, only of serial devices which have generic USB ids for which there
are known Braille devices using it.

> Some possible suggestions:
>   1) Don't grab any device, or attempt to probe any device, that does not
>   have an id that explicitly and unambiguously identifies it as a 
>   compatible terminal.  Users of other devices would need to manually
>   configure.

Which means they will just not be able to use their hardware. The
Braille device is the *only* way for these users to be able to access
their computer. They can not configure brltty if they can not access
their computer already.

>   2) During install, prompt for whether brltty should be started on boot.

During install, brltty is never installed by default unless such a
device was plugged-in during installation. For the same reason, we do
want to detect those devices with generic USB ids. Otherwise all people
owning these devices will just *not* be able to install Debian.

>   3) During install, prompt the user for their device's port.  If nothing
>   is specified, do not access any ports.

If brltty does not access the port, the user will not get any output,
and thus not be able to ask the user whether he wants to access the
port.

>   4) Don't send data to any unknown device.

Back to square one: some Braille manufacturers do set a generic id only.
And we want to allow users who have them to be able to install and use
Debian.

> Two other open bugs, #667616 and #721763, contain statements that none of
> the above would be acceptable, and the actual bug is that it got installed
> in the first place.

And I still stand by it.

> However, no progress seems to have been made on eliminating any
> dependencies on brltty.

No progress has been made merely because AFAIK there is *no* package
which depends on brltty except brltty drivers, i.e. there is nothing to
fix. If there is, please point me to it and we'll drop the dependency.

> Since brltty is still being installed unexpectedly on some systems,

That's what needs to be debugged.

> My suggestion would be that if brltty is not being used during the
> installation, the user should be prompted whether to enable it on boot,

AFAIK, if brltty is not being used during the installation, it is *not*
getting installed at all.

The only case I am aware of is if you have the serial device with
generic USB id plugged in during installation. Then d-i will start
brltty. But if we disable that, again, a lot of blind users will just
not be able to install Debian.

> Even if the user intentionally installs it, the assumption probably shouldn't
> be that every usb serial device the user may have attached is a compatible 
> terminal,

Again, brltty does *not* assume every usb serial device to be a Braille
device, it only probes serial devices with a generic USB id.

> I think the default as- installed behavior potentially causing harm,
> especially hardware or other physical damage, is itself a critical
> bug that must be addressed.  Installing a package by accident, with
> no further action, should not be harmful to other software or to the
> user's hardware.

Ask modemmanager about this. That one does really probe all serial usb
devices, not only those with a generic USB id.

Samuel

Bug#923376: Should only be in unstable

[Arnaud Fontaine]

Source: slapos.core
Severity: serious

As per upstream request, this package should not be available in testing and
hence in stable release so filling this bug report.

Regards,
Arnaud Fontaine

Bug#755434: abandoned?

[Vincent.Mcintyre]

Hi,

this package never got migrated to salsa, I think it is dead upstream.

The archived git is here
https://alioth-archive.debian.org/git/pmount/pmount.git.tar.xz
https://alioth-archive.debian.org/git/pmount/pmount-debian.git.tar.xz

I've attached a debdiff of what I had to do with the stretch package
source to get it working.

Cheers
Vince
diff -Nru pmount-0.9.23/debian/changelog pmount-0.9.23/debian/changelog
--- pmount-0.9.23/debian/changelog  2014-05-18 18:13:54.0 +1000
+++ pmount-0.9.23/debian/changelog  2019-02-27 15:03:07.0 +1100
@@ -1,3 +1,10 @@
+pmount (0.9.23-4) stretch; urgency=medium
+
+  * Add patch for exfat from ubuntu bug 1524523
+  * Add second patch from debian bug 755434
+
+ -- Vincent McIntyre   Wed, 27 Feb 2019 15:03:07 
+1100
+
 pmount (0.9.23-3) unstable; urgency=low
 
   * Use dh-autoreconf at build time (closes: #727943, #744493)
diff -Nru pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff 
pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff
--- pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff 1970-01-01 
10:00:00.0 +1000
+++ pmount-0.9.23/debian/patches/02-exfat-launchpad1524523.diff 2019-02-27 
15:02:11.0 +1100
@@ -0,0 +1,10 @@
+--- a/src/fs.c
 b/src/fs.c
+@@ -23,6 +23,7 @@ static struct FS supported_fs[] = {
+ { "iso9660", "nosuid,nodev,user", 1, NULL, ",iocharset=%s" },
+ { "vfat", "nosuid,nodev,user,quiet,shortname=mixed", 1, "077", 
+   ",iocharset=%s",",fmask=%04o,dmask=%04o"},
++{ "exfat", "nosuid,nodev,user,quiet,nonempty", 1, "077", 
",iocharset=%s",",fmask=%04o,dmask=%04o"},
+ { "hfsplus", "nosuid,nodev,user", 1, NULL, 0 },
+ { "hfs", "nosuid,nodev,user", 1, "077", NULL, 
+   ",file_umask=%04o,dir_umask=%04o"},
diff -Nru pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch 
pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch
--- pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch   1970-01-01 
10:00:00.0 +1000
+++ pmount-0.9.23/debian/patches/03-exfat-debian_755434.patch   2019-02-27 
15:03:07.0 +1100
@@ -0,0 +1,11 @@
+--- a/src/pmount.c
 b/src/pmount.c
+@@ -362,7 +362,7 @@ do_mount( const char* device, const char
+ fs->iocharset_format, iocharset );
+   }
+ }
+-else if(! strcmp(fsname, "vfat") && fs->iocharset_format) {
++else if((! strcmp(fsname, "vfat") || ! strcmp(fsname, "exfat")) && 
fs->iocharset_format) {
+   /* We still make a special case for vfat, as in certain cases,
+mount will mount it with iocharset=utf8, some times without
+warning. So, in the absence of a specified charset, we
diff -Nru pmount-0.9.23/debian/patches/series 
pmount-0.9.23/debian/patches/series
--- pmount-0.9.23/debian/patches/series 2014-05-18 18:13:54.0 +1000
+++ pmount-0.9.23/debian/patches/series 2019-02-27 15:03:07.0 +1100
@@ -1 +1,3 @@
 01-man-plugdev.diff
+02-exfat-launchpad1524523.diff
+03-exfat-debian_755434.patch

Bug#923375: brltty breaks usb serial devices; sends potentially harmful data to unknown devices

[fluffywolf]

Package: brltty
Version: 5.4-7+deb9u1
Severity: critical

brltty's default behavior seems to to not just claim all usb serial devices,
but to send random data to them, potentially causing harm to the connected
device.  

Grabbing all usb serial devices breaks every single other package related to
serial communications, qualifying it as a critical bug.  Default behavior
that sends data to unknown devices that is capable of causing damage to the
user's hardware is also a critical bug.

In my specific example, the autoprobing behavior caused an 8kW inverter to 
hard shut down, interrupting power to multiple residences.  This only caused
minor harm, and the system was able to be restarted once the serial connection
was disconnected, but could easily have caused severe harm, especially if I
hadn't noticed the issue promptly.  Default behavior with the potential to 
cause costly real-world damage is absolutely unacceptable, and this is a 
critical issue that needs to be fixed.  Web searches also found people 
complaining about all sorts of other problems caused by this behavior, such as
the popular Arduino device malfunctioning, as well as problems for 3d 
printers, industrial systems, and other devices.  Unknown devices absolutely 
should not be sent random data as a default behavior.

As a less-harmful behavior, that's still highly annoying, brltty prevents
the functioning of all usb serial devices, by default, with the default 
configuration.  "Breaks everything" should not be the default behavior of any
package.

This annoying behavior has been mentioned in other bugs, but the potential
to cause damage to devices has not, so I am filing a new bug, and marking
it critical.

Some possible suggestions:
  1) Don't grab any device, or attempt to probe any device, that does not
  have an id that explicitly and unambiguously identifies it as a 
  compatible terminal.  Users of other devices would need to manually
  configure.

  2) During install, prompt for whether brltty should be started on boot.
  If the user does not opt to start brltty, the default behavior would be
  a non-issue.  A warning should also be shown that starting brltty will
  break any other usb serial devices until it is manually configured.
  This is also mentioned in bug #598906.

  3) During install, prompt the user for their device's port.  If nothing
  is specified, do not access any ports.

  4) Don't send data to any unknown device.  This would reduce the issue to
  the annoying process of figuring out why a usb serial device unexpectedly
  doesn't work, which is better than potentially causing harm.

Two other open bugs, #667616 and #721763, contain statements that none of
the above would be acceptable, and the actual bug is that it got installed
in the first place.  However, no progress seems to have been made on 
eliminating any dependencies on brltty.  Since brltty is still being installed
unexpectedly on some systems, the default behavior needs to not be harmful.

My suggestion would be that if brltty is not being used during the
installation, the user should be prompted whether to enable it on boot, with
a warning that it may interfere with other devices.  This would cause no 
issues at all for people known to need it, and would prevent it from being
an unexpected problem for any users.  If brltty is being used during the
installation, then it should be enabled without asking.  You could also
check to see whether brltty is marked as being manually installed, and if
so, not prompt and enable by default, so that anyone who explicitly apt-get
installs it is assumed to want it, along with any issues it may cause.

Even if the user intentionally installs it, the assumption probably shouldn't
be that every usb serial device the user may have attached is a compatible 
terminal, and even users with compatible terminals may wish to use other usb 
serial devices, and expect that potentially harmful data will not be sent to
them.

I will also be filing bug reports against the dependency that got it installed
on my system, which I agree is also a bug, but I think the default as-
installed behavior potentially causing harm, especially hardware or other
physical damage, is itself a critical bug that must be addressed.  Installing
a package by accident, with no further action, should not be harmful to other
software or to the user's hardware.

Thanks,
--Fluffy




-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

Kernel: Linux 4.14.0-0.bpo.3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages brltty depends on:
ii  init-system-helpers1.48+devuan2.0
ii  libasound2 1.1.3-5
ii  libbluetooth3  5.43-2+deb9u1
ii  libbrlapi0.6   5.4-7+deb9u1
ii  libc6  2.24-11+deb9u4
ii  libglib2.0-0   2.50.3-2
ii  libgpm21.20.4-6.2+b1
ii  libicu57  

Bug#923347: No sensible security support due to Oracle's policies

[Sandro Tosi]

Hello Moritz,
i'm not sure what kind of input you're expecting from (if at all, and
this RC is mostly for the RT), but i'll reply

> mysql-connector-python is affected by Oracle's policy of not disclosing
> what security fixes they fix.
>
> CVE-2019-2435 is labeled with a CVSS 8.1/10 score and only fixed in
> 8.x, while the version in stretch (2.1.x) is marked as vulnerable,
> but no 2.1.9 release is available, i.e. we cannot effectively provide
> a fix within stable only 20 months after stretch was released.
>
> This renders mysql-connector-python unsuitable for inclusion in a stable
> release with security support.

what kind of security support do Debian provide to the mysql server packages?

> This leaves us with the following options for buster:
> - There are no reverse dependencies in buster, remove it from testing
>   and hope that someone less hostile to the FLOSS community creates a
>   fork

from a quick look (on unstable):

$ apt-cache rdepends python-mysql.connector
python-mysql.connector
Reverse Depends:
 mysql-utilities
 mysql-workbench
$ apt-cache rdepends python3-mysql.connector
python3-mysql.connector
Reverse Depends:
 openlp
 python3-sql

so some packages, not many, didnt verity if they are in buster atm

> - Aside from the packaged software and given that this is the only Python
>   binding for mysql/mariadb, there's most definitely a sizable number of
>   inhouse code using that module. Update src:debian-security-support to
>   mark mysql-connector-python as unsupported and add a README.Debian.security
>   which also documents this status within the package itself.

i think this is up to the security team to decide, no?

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#900895: kmail: KMail malfunctioning: Red email folders, no emails can be viewed; "Unable to fetch item from backend (collection-1): Unable to contact resource"

[Jens Radloff]

I recorded another occurrence of this behaviour with the debugger in the 
Akonadi Console. This time, below the output field on the "All" tab, the 
following additional error messages gets displayed:

--- Quote Beginning ---

AgentBase(akonadi_maildir_resource_0): Verbindung zum Akonadi-Dienst kann 
nicht hergestellt werden. => Can be translated as "Cannot establish connection 
to Akonadi service"
NotificationManager::notify ( { Type: "Items" Operation: "Modify" Items: { { 
ID: "32532" RemoteID: "1551182744.R329.punk" Remote Revision: "" Mime Type: 
"message/rfc822" } } Session: "akonadi_maildir_resource_0" Resource: 
"akonadi_maildir_resource_0" Destination Resource: "" Parent Collection: "9" 
Parent Destination Collection: "-1" Parts: "QSet(PLD:HEAD, PLD:RFC822, 
PLD:ENVELOPE)" Added Flags: "QSet()" Removed Flags: "QSet()" Added Tags: 
"QSet()" Removed Tags: "QSet()" } )
NotificationManager::notify ( { Type: "Items" Operation: "Modify" Items: { { 
ID: "32536" RemoteID: "1551196645.R430.punk:2,S" Remote Revision: "" Mime 
Type: "message/rfc822" } } Session: "akonadi_maildir_resource_0" Resource: 
"akonadi_maildir_resource_0" Destination Resource: "" Parent Collection: "7" 
Parent Destination Collection: "-1" Parts: "QSet(PLD:HEAD, PLD:RFC822, 
PLD:ENVELOPE)" Added Flags: "QSet()" Removed Flags: "QSet()" Added Tags: 
"QSet()" Removed Tags: "QSet()" } 

-- Quote End 

Then I restarted Akonadi with "akonadictl restart" in a command shell window 
and did not close this window, but provoked the behavior again. The console 
window returned the following debugging information about the time when the 
behaviour occurred again:

--- Quote Beginning ---

akonadicore_log: Invalid command, the world is going to end!
QIODevice::read (QLocalSocket): device not open
akonadi_maildir_resource: /build/akonadi-EKz4jf/akonadi-16.04.3/src/private/
protocol.cpp:1590: Akonadi::Protocol::HelloResponse::HelloResponse(const 
Akonadi::Protocol::Command&): Zusicherung »d_func()->commandType == 
Command::Invalid || d_func()->commandType == (Command::Hello | 
Command::_ResponseBit)« nicht erfüllt.
void Akonadi::Server::NotificationSource::serviceUnregistered(const QString&) 
Notification source "akonadi_maildir_resource_0_4955_mdI52n" now serving: ()
ProcessControl: Application /usr/bin/akonadi_maildir_resource stopped 
unexpectedly ( "Der Prozess ist abgestürzt" ) => Can be translated as "The 
process has crashed"
Application '/usr/bin/akonadi_maildir_resource' crashed too often. Giving up!
Shutting down "/subscriber/akonadi_maildir_resource_0_4955_mdI52n" ...
Lost connection to resource 
"org.freedesktop.Akonadi.Resource.akonadi_maildir_resource_0" , discarding 
cached interface
Shutting down "akonadi_maildir_resource_0" ...
Shutting down "0x55b505adb7b0" ...

--- Quote End ---

This bug issue is a duplicate of 

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

Bug#923374: root mode doesn't work anymore?

[Daniel Baumann]

Package: mmdebstrap
Version: 0.4.0-1

Hi,

with previous version of mmdebstrap, I used to do:

  sudo mmdebstrap sid sid http://deb.debian.org/debian

which then automatically uses 'root mode'.

Now I get this instead:

---snip---
I: automatically chosen mode: root
I: chroot architecture amd64 is equal to the host's architecture
I: running apt-get update...
done
Get:1 http://deb.debian.org/debian sid InRelease [242 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8366 kB]
Fetched 8608 kB in 2s (4984 kB/s)
Reading package lists...
W: Download is performed unsandboxed as root as file
'/root/sid/var/lib/apt/lists/partial/deb.debian.org_debian_dists_sid_InRelease'
couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission
denied)
apt-get update failed at /usr/bin/mmdebstrap line 569.
---snap---

Looking at the manpage I coudn't find anything obvious that I'm doing
wrong. If there is, maybe the default behaviour could be made more
user-friendly to 'just work'[tm]? Or is there a bug in 'root mode'?

Regards,
Daniel

Bug#923369: asymptote: split noX package

[Norbert Preining]

On Wed, 27 Feb 2019, Dmitry Bogatov wrote:
> please introduce asymptote-nox package or something like this.

Seems like a good idea to have an asymptote-extra or so package.
But this will not work before buster since no new packages are accepted.
I will tackle it after buster release.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#918480: squashfs-tools: Please move to "squashfskit" fork

[Alexander Couzens]

Hi Laszlo,

I've released squashfskit v4.14.
v4.14, so it's .10 minor version ahead of squashfs-tools. It should be
more clear if it's a bug in squashfs-tools or squashfskit.

Moving to squashfskit would reduce the debian patches from 17 to 3
patches:

0005-add-fstime.patch
0013-use-macros-not-raw-octal-with-chmod.patch
0014-also-set-stickybit-as-non-root.patch

Best Regards,
lynxis
-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpq9gSc3lizq.pgp
Description: OpenPGP digital signature

Bug#923373: devscripts: unshare as root-gaining program

[Dmitry Bogatov]

Package: devscripts
Version: 2.19.3
Severity: wishlist

Dear Maintainer,

as far as I know, `unshare -r' can provide functionality, equal to
fakeroot. Please consider making it one of root-gaining option, and
probably downgrade dependency on fakeroot.

-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpRt8_z0WsEU.pgp
Description: PGP signature

Bug#922815: insserv FATAL while updating as mountkernfs has to be enabled to use service udev

[Dmitry Bogatov]

[2019-02-25 05:45] shirish शिरीष 
> On 24/02/2019, Dmitry Bogatov  wrote:
>
> 
>
> > Interesting, you seems somehow got mountkernfs.sh script removed from
> > runlevel S.
> >
> > Can you please invoke as root
> >
> > # update-rc.d mountkernfs.sh enable S
> >
> > and then retry your upgrade.
>
> When I try the command you shared, it says -
>
> root@debian:~# update-rc.d mountkernfs.sh enable S
> update-rc.d: error: cannot find a LSB script for mountkernfs.sh

Seems there is no /etc/init.d/mountkernfs.sh on your system.

Since your init system is systemd, I question, why do you need insserv
in first place. Do you have bin:initscripts installed?

My guess is that update-initramfs invokes insserv /if/ it is available,
and since you have insserv installed, but no initscripts, we get this
bug.

Adding initramfs-tools maintainer into loop. If my guess is correct,
this issue should be resolved on initramfs side, since making insserv
depending on initscripts is not nice to user.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923370: kconfig-frontends: split noX package

[Dmitry Bogatov]

Package: kconfig-frontends
Version: 4.11.0.1+dfsg-2
Severity: wishlist

Dear Maintainer,

please introduce kconfig-frontends-nox or something like this.

I am very happy, that menuconfig is available as general-purpose tool,
but pulling Qt together is major inconvenience.

Probably, it also worth separating GTK and Qt frontends, but it would
not affect me.

-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpMj97ZXt4C0.pgp
Description: PGP signature

Bug#923371: sysvinit: new upstream release

[Dmitry Bogatov]

Source: sysvinit
Severity: wishlist

Dear Maintainer,

sysvinit=2.94 is released. Please consider packaging it.

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)


pgp9SV_fmnul0.pgp
Description: PGP signature

Bug#843419: init-d-script: please provide a way to not use the --name option of start-stop-daemon

[Dmitry Bogatov]

control: tags -1 +patch

[2019-02-24 13:24] wf...@niif.hu
> > Dmitry Bogatov  writes:
> > Sorry, I do not understand. You, as init script writer, choose value of
> > argument to $NAME. Why can't you limit it to required length?
> [...]
>
> I imagine that having an optional COMM_NAME (pick any name) variable
> would solve this nicely, if it was used in preference to NAME for the
> --name option of start-stop-daemon if it was set, like

What about this patch? Would it satisfy your need? Can you please review
wording -- I am very bad at writing manpages.

From 4eaaa037824b708476bb677061e36b4c19cff089 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Mon, 25 Feb 2019 10:49:27 +
Subject: [PATCH] Add new parameter COMMAND_NAME to init-d-script

Introduce new parameter COMMAND_NAME that can be used in `init-d-script'
based initscripts. Value of that parameter is used as argument to --name
option in start-stop-daemon invocations. (Closes: #834419)
---
 debian/init-d-script   |  7 ---
 debian/init-d-script.5 | 14 ++
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/debian/init-d-script b/debian/init-d-script
index 131dbd65..b5ef04d5 100755
--- a/debian/init-d-script
+++ b/debian/init-d-script
@@ -50,11 +50,11 @@ call() {
 do_start_cmd() {
start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
$START_ARGS \
-   --startas $DAEMON --name $NAME --exec $DAEMON --test > /dev/null \
+   --startas $DAEMON --name ${COMMAND_NAME} --exec $DAEMON --test > 
/dev/null \
|| return 1
start-stop-daemon --start --quiet ${PIDFILE:+--pidfile ${PIDFILE}} \
$START_ARGS \
-   --startas $DAEMON --name $NAME --exec $DAEMON -- $DAEMON_ARGS \
+   --startas $DAEMON --name ${COMMAND_NAME} --exec $DAEMON -- 
$DAEMON_ARGS \
|| return 2
# Add code here, if necessary, that waits for the process to be ready
# to handle requests from services started subsequently which depend
@@ -89,7 +89,7 @@ do_start()
 do_stop_cmd() {
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 \
$STOP_ARGS \
-   ${PIDFILE:+--pidfile ${PIDFILE}} --name $NAME --exec $DAEMON
+   ${PIDFILE:+--pidfile ${PIDFILE}} --name ${COMMAND_NAME} --exec 
$DAEMON
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
@@ -182,6 +182,7 @@ fi
 
 NAME=${NAME:=$(basename $DAEMON)}
 DESC=${DESC:=$NAME}
+: ${COMMAND_NAME:=${NAME}}
 
 # Do not use pid file if $PIDFILE is 'none'.  Otherwise, generate from
 # $NAME or use the value provided by the init.d script.
diff --git a/debian/init-d-script.5 b/debian/init-d-script.5
index ee645c58..05a03f6b 100644
--- a/debian/init-d-script.5
+++ b/debian/init-d-script.5
@@ -44,12 +44,18 @@ DAEMON=/usr/sbin/atd
 .EE
 .P
 In addition to the DAEMON setting, one can specify DESC, NAME,
-PIDFILE (`none' means no PID file), or implement override functions
-do_force_reload_override, do_reload_override, do_restart_override,
-do_start_override, do_start_cmd_override, do_start_prepare,
-do_start_cleanup do_status_override, do_stop_override,
+COMMAND_NAME, PIDFILE (`none' means no PID file), or implement
+override functions do_force_reload_override, do_reload_override,
+do_restart_override, do_start_override, do_start_cmd_override,
+do_start_prepare, do_start_cleanup do_status_override, do_stop_override,
 do_stop_prepare, do_stop_cleanup and do_stop_cmd_override.
 .P
+Argument to
+.I --name
+option of
+.B start-stop-daemon
+program is  COMMAND_NAME variable, if it is set, or NAME otherwise.
+.P
 If the daemon support reloading, implement the do_reload function to
 make the init.d script recognize the reload operation as well as use
 it for the force-reload operation.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923168: initscripts: Old cruft in initscripts postinst

[Dmitry Bogatov]

[2019-02-24 18:48] Pierre Ynard 
> Package: initscripts
> Version: 2.93-8
> Severity: minor
> Tags: patch
>
> Hello,
>
> initscripts.postinst still contains old cruft, unused now as far as I
> can see, left over from the /run/shm migration. The code making use of
> it was already removed in:
>
> https://salsa.debian.org/debian/sysvinit/commit/e58f3742cc303fd1563e6cf046661e892b97181a
>
> > debian: Clean up legacy migration logic in maintainer and init scripts 
>
> One is a stray, write-only $devshm variable introduced as a workaround
> in:
>
> https://salsa.debian.org/debian/sysvinit/commit/82a6316cbaa982d5887c2bec25a903f4a64843c6
>
> > initscripts.postinst: hide from lintian the fact that we're removing
> > /dev/shm, since otherwise a buggy lintian check prevents us from
> > uploading legitimate code to the archive.
>
> The other is a compat_link() helper function doing the kind of things
> also handled in /lib/init/mount-functions.sh
>
> I think they're safe to remove now.

Thank you very much for your research and patches. Can you please
re-submit your patches in format, generated by `git format-patch'?

What you included is `git show` output, which is not possible to apply
directly. Thank you again.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923372: e2fsprogs: sharing of /sbin/logsave

[Dmitry Bogatov]

Package: e2fsprogs
Version: 1.44.5-1
Severity: normal

Dear Maintainer,

for long time e2fsprogs were essential, and bin:initscripts used
/sbin/logsave from e2fsprogs. Nowdays, e2fsprogs are not essential,
so initscripts switched to using /sbin/logsave on best-effort basis (use
if present), which is suboptimal.

Upstream maintainer of sysvinit imported sources of logsave from
e2fsprogs into sysvinit, and now initscripts can again be sure, that
logsave is present, if we settle question, who will provide
/sbin/logsave.

So here I propose, that e2fsprogs no longer installs logsave, and it
switch owner to bin:sysvinit-utils. Not the best solution, given there
is desire (but not much of action) of dropping essential flag from
bin:sysvinit-utils.

Alternatively, one of us could build bin:logsave.

Best regards, one of sysvinit Debian maintainers.

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=eo.utf8, LC_CTYPE=eo.utf8 (charmap=UTF-8), LANGUAGE=eo.utf8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages e2fsprogs depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-7
ii  libcom-err2  1.44.5-1
ii  libext2fs2   1.44.5-1
ii  libss2   1.44.5-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-24

-- no debconf information


pgpLS9tx1uOAE.pgp
Description: PGP signature

Bug#923369: asymptote: split noX package

[Dmitry Bogatov]

Package: asymptote
Version: 2.47-2
Severity: wishlist

Dear Maintainer,

please introduce asymptote-nox package or something like this.
Asymptote, at least at my usage pattern, is just a compiler from .asy to
.eps; dependency on pyqt feels unwarranted.

-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpiNyWKB8wW8.pgp
Description: PGP signature

Bug#922300: unblock: chef/13.8.7-3, ohai/13.8.0-1

[Antonio Terceiro]

On Thu, Feb 14, 2019 at 09:42:42AM -0200, Antonio Terceiro wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hello,
> 
> Please unblock package chef
> 
> Hi,
> 
> The ci.debian.net nodes are managed with chef, and during the weekend I
> realized that it was not in testing. There was an RC bug against chef (FTBFS, 
> 3
> tests broken by an update to the test framework, package just worked
> nevertheless) and ruby-cheffish (broken by openssl 1.1.1). I fixed both, and
> they were ACCEPTED in unstable Sunday morning within less than one hour of 
> each
> other (ruby-cheffish at 11:53:21 + and chef at 12:34:15 +)
> 
> https://tracker.debian.org/news/1029431/accepted-chef-1387-3-source-into-unstable/
> https://tracker.debian.org/news/1029425/accepted-ruby-cheffish-1310-2-source-into-unstable/

FWIW today I noticed a new item in the chef migration excuses that was
not there when I opened this bug, a piuparts regression. I made a new
upload with a trivial patch fixing only that.


signature.asc
Description: PGP signature

Bug#854643: fix for this bug

[Andriy Grytsenko]

I believe the mentioned file is appropriate for libnotify-bin and isn't
appropriate for lxpanel package since lxpanel does not interact with the
daemon directly.

And thank you for a notice about dependencies. Both libnotify-bin and
notification-daemon are added as Recommended by lxpanel now.

The original issue is probably related to #84, so if current is
missing from data then alarm will never go out. Fix for such case also
pushed. Please, reopen this bug if issue still persists. Thank you very
much.

Bug#923362: libpam-runtime: dpkg-reconfigure libpam-runtime disables systemd profile

[Matthew Foulkes]

Hi again,

On Tue, Feb 26, 2019 at 05:00:47PM -0800, Steve Langasek wrote:
Is the debconf prompt shown when you run dpkg-reconfigure?  Is the 
systemd option shown in the list of options?  (Will be listed as: 
"Register user sessions in the systemd control group hierarchy")  If 
presented, is it selected or unselected when the list is shown?  Did 
you select it or not?


The debconf prompt is shown and the systemd option is shown too, with 
the wording you gave above and a "[*]" to indicate that it is currently 
selected. Even when I go straight to the "Ok" prompt to complete the 
reconfiguration process without making any changes to the list of 
selected options, the systemd pam module is disabled. Next time I start 
dpkg-reconfigure, the systemd option is shown as "[ ]" instead of "[*]". 
I can select it and hit space to add a star, but this has no practical 
effect; it is still disabled next time I start dpkg-reconfigure. To 
re-enable the systemd pam module I have to run 'pam-auth-update --enable 
systemd'.


Regards, Matthew


--
**
 email: m.foul...@blueyonder.co.uk
 phone: 07905 505676
**

Bug#923362: libpam-runtime: dpkg-reconfigure libpam-runtime disables systemd profile

[Steve Langasek]

On Tue, Feb 26, 2019 at 04:22:04PM -0800, Matthew Foulkes wrote:
> Thanks for your help.

> Tar archives of the contents of /var/lib/pam before and after running
> 'dpkg-reconfigure libpam-runtime' are attached as pam.before.tar and
> pam.after.tar.

> Before running 'dpkg-reconfigure libpam-runtime', the output of
> 'debconf-show libpam-runtime' is:

>  libpam-runtime/title:
>  libpam-runtime/conflicts:
>  libpam-runtime/no_profiles_chosen:
>  libpam-runtime/override: false
> * libpam-runtime/profiles: unix, systemd, gnome-keyring

> After running 'dpkg-reconfigure libpam-runtime' but making no changes, the
> output changes to:

>  libpam-runtime/override: false
>  libpam-runtime/no_profiles_chosen:
>  libpam-runtime/conflicts:
> * libpam-runtime/profiles: unix, gnome-keyring
>  libpam-runtime/title:

> Running 'pam-auth-update --enable systemd' restores the original debconf
> output.

> The computer was installed only this weekend using the latest Debian Buster
> alpha installer. The 'debsums -ce' command says that all configuration files
> are in their default states.

Is the debconf prompt shown when you run dpkg-reconfigure?  Is the systemd
option shown in the list of options?  (Will be listed as: "Register user
sessions in the systemd control group hierarchy")  If presented, is it
selected or unselected when the list is shown?  Did you select it or not?

> On Tue, Feb 26, 2019 at 03:34:53PM -0800, Steve Langasek wrote:
> > Control: tags -1 moreinfo unreproducible
> > 
> > On Tue, Feb 26, 2019 at 02:01:42PM -0800, Matthew Foulkes wrote:
> > > Package: libpam-runtime
> > > Version: 1.3.1-5
> > > Severity: normal
> > 
> > > Dear Maintainer,
> > 
> > > Running the
> > 
> > >   dpkg-reconfigure libpam-runtime
> > 
> > > command offers the user a list of pam profiles to enable or
> > > disable. Whether or not the user decides to make any changes,
> > > dpkg-reconfigure always silently disables the systemd profile,
> > > breaking a lot of desktop functionality. Attempts to use
> > > dpkg-reconfigure to re-enable the systemd profile fail
> > > silently.
> > 
> > > The problem can be fixed by running
> > 
> > >   pam-auth-update --enable systemd
> > 
> > > but reappears whenever dpkg-reconfigure is used again.
> > 
> > I cannot reproduce this problem locally.  Please attach the contents of your
> > /var/lib/pam directory and the output of the command 'debconf-show
> > libpam-runtime'.
> > 
> > -- 
> > Steve Langasek   Give me a lever long enough and a Free OS
> > Debian Developer   to set it on, and I can move the world.
> > Ubuntu Developer   https://www.debian.org/
> > slanga...@ubuntu.com vor...@debian.org
> 
> 
> 
> -- 
> **
>  email: m.foul...@blueyonder.co.uk
>  phone: 07905 505676
> **

> drwxr-xr-x root/root 0 2019-02-26 16:14 pam/
> -rw-r--r-- root/root68 2019-02-26 16:14 pam/auth
> -rw-r--r-- root/root   115 2019-02-26 16:14 pam/session
> -rw-r--r-- root/root75 2019-02-26 16:14 pam/session-noninteractive
> -rw-r--r-- root/root76 2019-02-26 16:14 pam/account
> -rw-r--r-- root/root37 2019-02-26 16:14 pam/seen
> -rw-r--r-- root/root   121 2019-02-26 16:14 pam/password

> drwxr-xr-x root/root 0 2019-02-26 16:11 pam/
> -rw-r--r-- root/root68 2019-02-26 16:11 pam/auth
> -rw-r--r-- root/root75 2019-02-26 16:11 pam/session
> -rw-r--r-- root/root75 2019-02-26 16:11 pam/session-noninteractive
> -rw-r--r-- root/root76 2019-02-26 16:11 pam/account
> -rw-r--r-- root/root37 2019-02-26 16:11 pam/seen
> -rw-r--r-- root/root   121 2019-02-26 16:11 pam/password


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#923368: dnssec-trigger: unbound configuration is not done by default and not done properly when done

[Paul Wise]

Package: dnssec-trigger
Version: 0.17+repack-3
Severity: normal

I get errors like the ones below in my systemd journal until I enable
the unbound remote-control option using the dnssec-trigger script for
that, but the script does that in the wrong way.

Instead, the added line should be in a snippet dropped into the unbound
configuration directory so that the config file change doesn't cause
dpkg conffile prompts when upgrading unbound. Also the postinst needs
to run the script with the -i option so that it installs the unbound
config file changes and can thus control unbound by default.

$ grep -C2 setup /var/lib/dpkg/info/dnssec-trigger.postinst
case "$1" in
configure)
dnssec-trigger-control-setup
;;
$ grep -r remote-control /etc/unbound/unbound.conf*
$ sudo dnssec-trigger-control-setup -i
$ tail -n 1 /etc/unbound/unbound.conf
remote-control: control-enable: yes # linetag-dnssec-trigger
$ tail -n1 /etc/unbound/unbound.conf | sudo tee 
/etc/unbound/unbound.conf.d/dnssec-trigger.conf
$ sudo sed -i '/linetag-dnssec-trigger/d' /etc/unbound/unbound.conf

Feb 27 08:09:29 dnssec-triggerd[24647]: [1551226169] unbound-control[24859:0] 
warning: control-enable is 'no' in the config file.
Feb 27 08:09:29 dnssec-triggerd[24647]: [1551226169] unbound-control[24859:0] 
error: connect: Connection refused for 127.0.0.1 port 8953
Feb 27 08:09:29 dnssec-triggerd[24647]: [24647] warning: unbound-control exited 
with status 256, cmd: /usr/sbin/unbound-control forward fd57:944b:77d7::1 
192.168.1.1
Feb 27 08:09:31 dnssec-triggerd[24647]: Traceback (most recent call last):
Feb 27 08:09:31 dnssec-triggerd[24647]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 774, in 
Feb 27 08:09:31 dnssec-triggerd[24647]: main()
Feb 27 08:09:31 dnssec-triggerd[24647]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 761, in main
Feb 27 08:09:31 dnssec-triggerd[24647]: Application(sys.argv).run()
Feb 27 08:09:31 dnssec-triggerd[24647]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 472, in run
Feb 27 08:09:31 dnssec-triggerd[24647]: self.method()
Feb 27 08:09:31 dnssec-triggerd[24647]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 556, in run_setup
Feb 27 08:09:31 dnssec-triggerd[24647]: 
self._unbound_set_negative_cache_ttl(UNBOUND_MAX_NEG_CACHE_TTL)
Feb 27 08:09:31 dnssec-triggerd[24647]:   File 
"/usr/lib/dnssec-trigger/dnssec-trigger-script", line 641, in 
_unbound_set_negative_cache_ttl
Feb 27 08:09:31 dnssec-triggerd[24647]: subprocess.check_call(CMD, 
stdout=DEVNULL, stderr=DEVNULL)
Feb 27 08:09:31 dnssec-triggerd[24647]:   File 
"/usr/lib/python3.7/subprocess.py", line 347, in check_call
Feb 27 08:09:31 dnssec-triggerd[24647]: raise CalledProcessError(retcode, 
cmd)
Feb 27 08:09:31 dnssec-triggerd[24647]: subprocess.CalledProcessError: Command 
'['unbound-control', 'set_option', 'cache-max-negative-ttl:', '5']' returned 
non-zero exit status 1.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dnssec-trigger depends on:
ii  gir1.2-nm-1.0   1.14.4-4
ii  libc6   2.28-7
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.3-1
ii  libgtk2.0-0 2.24.32-3
ii  libldns21.7.0-3.1+b1
ii  libssl1.1   1.1.1a-1
ii  python3 3.7.2-1
ii  python3-gi  3.30.4-1
ii  python3-lockfile1:0.12.2-2
ii  sensible-utils  0.0.12
ii  unbound 1.9.0-2

dnssec-trigger recommends no packages.

dnssec-trigger suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#923090: reportbug: Please add information about systems tainted due to merged-usr-via-symlinks

[Sandro Tosi]

control: tag -1 +moreinfo

On Sat, Feb 23, 2019 at 9:03 PM Guillem Jover  wrote:
> The merged-/usr deployment method of using directory symlinks, instead
> of properly moving the files or symlinking the contents of these
> directories is broken by design.
>
> Please see .
>
> I'd appreciate if you could add information on filed bugs about such
> tainted systems.

i dont believe this is something *every* bug report should have, as it
looks like it's a very small percentage of hosts could be in this
configuration, and let's be honest, the impact is only limited to a
handful of packages (i understand you're coming from the dpkg POV)

> For dpkg I added the following bug-script:
>
>   ,---
>   #!/bin/sh
>
>   set -e
>
>   for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
> if [ "$(readlink $d)" = "usr$d" ]; then
>   echo "System tainted due to merged-usr-via-symlinks." >&3
>   break
> fi
>   done
>   `---

this indeed looks like a more sensible approach: every package that
actually cares about the merged-/usr status, should add its own bug
script to inspect the system status

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#923362: libpam-runtime: dpkg-reconfigure libpam-runtime disables systemd profile

[Matthew Foulkes]

Hi Steve,

Thanks for your help.

Tar archives of the contents of /var/lib/pam before and after running 
'dpkg-reconfigure libpam-runtime' are attached as pam.before.tar and 
pam.after.tar.


Before running 'dpkg-reconfigure libpam-runtime', the output of 
'debconf-show libpam-runtime' is:


 libpam-runtime/title:
 libpam-runtime/conflicts:
 libpam-runtime/no_profiles_chosen:
 libpam-runtime/override: false
* libpam-runtime/profiles: unix, systemd, gnome-keyring

After running 'dpkg-reconfigure libpam-runtime' but making no changes, 
the output changes to:


 libpam-runtime/override: false
 libpam-runtime/no_profiles_chosen:
 libpam-runtime/conflicts:
* libpam-runtime/profiles: unix, gnome-keyring
 libpam-runtime/title:

Running 'pam-auth-update --enable systemd' restores the original debconf 
output.


The computer was installed only this weekend using the latest Debian 
Buster alpha installer. The 'debsums -ce' command says that all 
configuration files are in their default states.


Best wishes, Matthew



On Tue, Feb 26, 2019 at 03:34:53PM -0800, Steve Langasek wrote:

Control: tags -1 moreinfo unreproducible

On Tue, Feb 26, 2019 at 02:01:42PM -0800, Matthew Foulkes wrote:

Package: libpam-runtime
Version: 1.3.1-5
Severity: normal



Dear Maintainer,



Running the



  dpkg-reconfigure libpam-runtime



command offers the user a list of pam profiles to enable or
disable. Whether or not the user decides to make any changes,
dpkg-reconfigure always silently disables the systemd profile,
breaking a lot of desktop functionality. Attempts to use
dpkg-reconfigure to re-enable the systemd profile fail
silently.



The problem can be fixed by running



  pam-auth-update --enable systemd



but reappears whenever dpkg-reconfigure is used again.


I cannot reproduce this problem locally.  Please attach the contents of your
/var/lib/pam directory and the output of the command 'debconf-show
libpam-runtime'.

--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org




--
**
 email: m.foul...@blueyonder.co.uk
 phone: 07905 505676
**


pam.before.tar
Description: Unix tar archive


pam.after.tar
Description: Unix tar archive

Bug#923209: RFS: heaptrack/1.1.0+20180922.gitf752536-3.1 [NMU]

[Nicholas D Steeves]

On Tue, Feb 26, 2019 at 06:16:29PM -0500, Chris Lamb wrote:
> Hi Nicholas,
> 
> > Well, I packaged memleax because I couldn't find heaptrack, and when
> > memleax was abandoned upstream I discovered heaptrack via memleax'
> > issue tracker. 
> 
> I certainly would agree that this is a bug. That is not the question here.
> 
> > So are NMUs only justified for fixing RC bugs
>  
> Yes, or least something of "Severity: important" (or similar in
> spirit). Our difference, if any, is that I don't feel that is
> warranted here. :)
> 

That's fair ;-)  Also, I just realised that I've collaborated with some
Debian Science Team members before, and have reached out to them.
'should have investigated that avenue before requesting an NMU.

Maybe it's obvious, but perhaps the developer's reference and
wiki/PackageSalvaging would benefit the addition of "Things to do
before NMUing…for a team maintained package, try to find someone you
know on the team to do a Team Upload (link to page that has Team IRC
channels, and suggest examining Team members list on Salsa).  It's a
trivial bit of work I'd be happy to do...


Thanks again!
Nicholas


signature.asc
Description: PGP signature

Bug#922554: network-manager: NetworkManager continuously spinning, probably while checking for connectivity

[Jiri Palecek]

Hello,

On 26. 02. 19 19:26, Michael Biebl wrote:

Control: tags -1 + moreinfo

Do you have network-manager-config-connectivity-debian installed

oh yeah

Is the server reachable for the connectivity check reachable?


I think so. At least I can't see any connectivity problems.


Regards

    Jiri Palecek

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Dragan Milenkovic]

On 2/26/19 10:11 PM, Cesare Leonardi wrote:
Hello Dragan, do you know if the patch was eventually included upstream 
and possibly in which version?


Hello, Cesare. It was included in 4.20.11 and 4.19.24.

Dragan

Bug#900299: leiningen-clojure: depends on openjdk-8

[Sean Whitton]

Hello,

On Sun 24 Feb 2019 at 11:26PM -05, Elana Hashman wrote:

> Note that Leiningen is still a lot slower and has different behaviour on
> jdk11, and users will likely prefer to run it on jdk8, but they can
> override the default Java by exporting JAVA_CMD fwiw. I might include a
> note of this in release news.

This sounds like a really good idea, assuming you mean NEWS.Debian.

Thank you for your efforts.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#915241: heaptrack -- resolve poor discoverability

[Nicholas D Steeves]

Hi Mattia,

On Sun, Feb 24, 2019 at 07:54:52PM -0700, Nicholas D Steeves wrote:
> On Sun, Feb 24, 2019 at 07:38:12PM -0700, Nicholas D Steeves wrote:
> > Control: retitle -1 heaptrack -- resolve poor discoverability
> > 
> > On Sat, Dec 01, 2018 at 07:38:05PM -0500, Nicholas D Steeves wrote:
> > > Package: src:heaptrack
> > > Severity: normal
> > > 
> > > https://salsa.debian.org/science-team/heaptrack/merge_requests/1
> > > 
> > > This MR merges Anton's work from experimental and enhances the
> > > description to make heaptrack discoverable via keyword search, plus
> > > adds a couple of extremely brief comparisons with Valgrind.
> > > 
> > > When I was debugging a dbus+kde memory ballooning/memleak issue, I was
> > > not able to find heaptrack with a keyword search, so packaged
> > > memleax. Having now discovered heaptrack via the memleax bugtracker
> > > (yes, really!) I believe the best path forward is to make heaptrack
> > > discoverable and scrap my work on memleax.
> > > 
> > > Thank you for considering this MR,
> > > Nicholas
> > 
> > It has been almost three months without a reply, so to address
> > Heaptrack's discoverability issue I plan an NMU delayed + x days to
> > 2019-03-01 of the proposed updates to the description, without merging
> > the commits from experimental.  I will file a new MR to make
> > integrating the NMU easier.
> > 
> > Memleax has been abandoned upstream and I have filed a RoM NPOASR at
> > #923206, and Heaptrack now appears to be the only software in Debian
> > that can debug memleaks in an already-running process.
> > 
> > Respectfully,
> > Nicholas
> 
> New MR filed here:
> 
>   https://salsa.debian.org/science-team/heaptrack/merge_requests/2

Chris Lamb tells me an NMU is not justified.  Since you're part of the
Debian Science Team would you please merge
https://salsa.debian.org/science-team/heaptrack/merge_requests/2 and
re-finalise it as a team upload?

Further info about why I believe this upload is justified (eg: it's
impossible to find and causes ecosystem issues) is available at
#923209


Cheers,
Nicholas

P.S. Thanks again for helping out with the yapf RC bug!  If someone
decides to sponsor my NMU the Team Upload version will win, and I've
only CCed Anton Gladsky about this issue (he hasn't replied in 2.5
months), and have discussed it in #debian-science at ~17h UTC -7.


signature.asc
Description: PGP signature

Bug#629902: dh_installinit: should support LSB compliant scripts

[Felipe Sateler]

Hi,

Sorry for the delayed answer

On Sat, Jan 19, 2019 at 4:36 PM Dmitry Bogatov  wrote:

> [2019-01-16 06:32] Niels Thykier 
> > Felipe Sateler:
> > > Bringing in the debhelper maintainers into the loop again.
> > >
> > > [...]
> > >> Should  an init script be executed, invoke-rc.d always returns the
> status
> > > code returned by the init script.
> > >
> > > So it looks like this would be quite the change in behavior.
> > >
> > > I wonder what the best approach it. OTOneH, I sympathize with Joey's
> > > argument that these checks should be centralized. OTOtherH, I'm not
> sure we
> > > can consider invoke-rc.d a debhelper implementation detail and change
> > > behaviour like this.
> > >
> > > Maybe a new flag to invoke-rc.d could be used for this? I'm not sure.
> >
> > I am fine with using a new flag in a new compat level provided it is
> > available in stable at the time.  I.e. it would help a lot that the flag
> > is available in buster, so we can add it in the first compat level
> > released in bullseye.
>
> Wonderful. What about this patch:
>
> From 6c856e13dfd496b25652a202f210177dd0f86c19 Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Thu, 10 Jan 2019 16:31:32 +
> Subject: [PATCH] invoke-rc.d: exit value 6 from init script is fine
>
> Add new option `--lsb' to `invoke-rc.d' script. When this option is
> specified, exit value 6 from init script (service not configured) is
> considered successful invocation (Closes: #629902)
> ---
>  man8/invoke-rc.d.rst |  3 +++
>  script/invoke-rc.d   | 11 ++-
>  2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/man8/invoke-rc.d.rst b/man8/invoke-rc.d.rst
> index e5aaeee..53dd435 100644
> --- a/man8/invoke-rc.d.rst
> +++ b/man8/invoke-rc.d.rst
> @@ -88,6 +88,9 @@ OPTIONS
>  Return status code 101 instead of status code 0 if
>  the init script action is denied by the policy layer.
>
> +*--lsb*
> + Consider exit status 6 (not configured) of init script as success.
> +
>  *--query*
>  Returns one of the status codes 100-106. Does not
>  run the init script, and implies *--disclose-deny*
>

This should also be documented in the STATUS CODES section.


> diff --git a/script/invoke-rc.d b/script/invoke-rc.d
> index 27c045e..6b11fdf 100755
> --- a/script/invoke-rc.d
> +++ b/script/invoke-rc.d
> @@ -34,6 +34,7 @@ ACTION=
>  FALLBACK=
>  NOFALLBACK=
>  FORCE=
> +LSB=
>  RETRY=
>  RETURNFAILURE=
>  RC=
> @@ -77,6 +78,8 @@ Options:
>   Return status code 101 instead of status code 0 if
>   initscript action is denied by local policy rules or
>   runlevel constrains.
> +  --lsb
> + Consider exit status 6 (not configured) of init script as success.
>--query
>   Returns one of status codes 100-106, does not run
>   the initscript. Implies --disclose-deny and --no-fallback.
> @@ -238,6 +241,9 @@ while test $# -gt 0 && test ${state} != III ; do
>--try-anyway)
> RETRY=yes
> ;;
> +   --lsb)
> +   LSB=yes
> +   ;;
>--disclose-deny)
> RETURNFAILURE=yes
> ;;
> @@ -550,9 +556,12 @@ if test x${FORCE} != x || test ${RC} -eq 104 ; then
> elif [ -n "$is_openrc" ]; then
> rc-service "${INITSCRIPTID}" "${saction}" && exit 0
> else
> -   "${INITDPREFIX}${INITSCRIPTID}" "${saction}" "$@" && exit 0
> +   "${INITDPREFIX}${INITSCRIPTID}" "${saction}" "$@"
> fi
> RC=$?
> +   [ "${RC}" = 0 ] && exit 0
> +   # service not configured. See #629902
> +   [ x"${LSB}" != x ] && [ "${RC}" = 6 ] && exit 0
>

Lets go the other way around: [ x${LSB} = xyes ] , I find that easier to
read. Also, we should probably also allow exit code 5
http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

This only works if invoking the init scripts directly. systemctl will hide
the exit status of the init script (the default behavior of systemd is to
accept exit code 5 and 6 for LSB scripts though). No idea what rc-service
does. This should probably be documented in the manpage.

-- 

Saludos,
Felipe Sateler

Bug#870428: libverto1: Upstream has moved

[Robbie Harwood]

Sam Hartman  writes:

> I apologize for dropping the ball on this so long.
> It looks like there is a 0.3.0 release of verto, which was folded into
> krb5.
> However, It looks like there's not an upstream tarball on github for
> anything past 0.2.6.

I'm confused by this comment.  I've definitely been cutting relesese,
with tarballs, for 0.2.7, 0.3.0, and (today) 0.3.1 - you can see them
here: https://github.com/latchset/libverto/releases

I don't see anything different about those, but please let me know if
I've missed something.

> Because I dropped the ball so much I'm under tight time pressure to get
> an update into Debian buster.  I'm going to package 0.2.6, but if you
> either get me an official 0.3.0 tarball by Thursday or alternatively let
> me know that the changes between 0.2.6 and 0.3.0 are so critical I
> should go generate my own make dist even though I'm not upstream, I'll
> try to get 0.3.0 in.

Hopefully 0.3.1 addresses these concerns (and the bug you filed
upstream).

Thanks,
--Robbie


signature.asc
Description: PGP signature

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Markus Koschany]

Am 26.02.19 um 21:34 schrieb Markus Koschany:

> Thanks for reporting and the hint how to fix this problem. I'll take a
> closer look soon.

Unfortunately there is another issue that prevents jajuk from starting.
This appears to be the same one which affects triplea as well.

https://bugs.debian.org/911078



Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at
org.pushingpixels.substance.internal.utils.SubstanceColorUtilities.getDefaultBackgroundColor(SubstanceColorUtilities.java:759)
at
org.pushingpixels.substance.internal.utils.SubstanceColorUtilities.getBackgroundFillColor(SubstanceColorUtilities.java:661)
at
org.pushingpixels.substance.internal.ui.SubstancePanelUI.__org__pushingpixels__substance__internal__ui__SubstancePanelUI__installDefaults(SubstancePanelUI.java:74)
at
org.pushingpixels.substance.internal.ui.SubstancePanelUI.installDefaults(SubstancePanelUI.java)
at
java.desktop/javax.swing.plaf.basic.BasicPanelUI.installUI(BasicPanelUI.java:62)
at
org.pushingpixels.substance.internal.ui.SubstancePanelUI.__org__pushingpixels__substance__internal__ui__SubstancePanelUI__installUI(SubstancePanelUI.java)
at
org.pushingpixels.substance.internal.ui.SubstancePanelUI.installUI(SubstancePanelUI.java)
at java.desktop/javax.swing.JComponent.setUI(JComponent.java:685)
at java.desktop/javax.swing.JPanel.setUI(JPanel.java:150)
at java.desktop/javax.swing.JPanel.updateUI(JPanel.java:126)
at java.desktop/javax.swing.JPanel.(JPanel.java:86)
at java.desktop/javax.swing.JPanel.(JPanel.java:109)
at java.desktop/javax.swing.JPanel.(JPanel.java:117)
at 
java.desktop/javax.swing.JRootPane.createGlassPane(JRootPane.java:521)
at java.desktop/javax.swing.JRootPane.(JRootPane.java:348)
at java.desktop/javax.swing.JFrame.createRootPane(JFrame.java:279)
at java.desktop/javax.swing.JFrame.frameInit(JFrame.java:258)
at java.desktop/javax.swing.JFrame.(JFrame.java:181)
at org.jajuk.ui.wizard.FirstTimeWizard.(Unknown Source)
at org.jajuk.services.core.SessionService$1.run(Unknown Source)
at
java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:313)
at 
java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:770)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:721)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:715)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:85)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:740)
at
java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
at
java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
at
java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)




signature.asc
Description: OpenPGP digital signature

Bug#923367: AppArmor: Profile for journald

[Jörg Sommer]

Package: apparmor-profiles
Version: 2.13.2-9
Severity: normal

Hi,

I've created a profile for journald to restrict the possible capabilities
the process has. But journald starts before the AppArmor profiles get
loaded. I've created a service to run after apparmor.service to restart
all unconfined services having a profile. What do you think about this?
Would you include this in the package?

Bye Jörg

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

Kernel: Linux 4.20.0-trunk-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 apparmor-profiles depends on:
ii  apparmor  2.13.2-9

apparmor-profiles recommends no packages.

apparmor-profiles suggests no packages.

-- no debconf information

-- 
Das Recht, seine Meinung zu wechseln, ist eines der wichtigsten
menschlichen Privilegien.
(Robert Peel)
include 

profile /lib/systemd/systemd-journald {
  include 

  /dev/kmsg rw,
  /etc/machine-id r,
  /proc/cmdline r,
  /proc/sys/kernel/hostname r,
  /proc/sys/kernel/random/boot_id r,
  /proc/*/{cgroup,cmdline,comm,loginuid,sessionid} r,
  /proc/*/attr/current r,
  /proc/1/{environ,sched} r,
  owner /proc/@{pid}/stat r,

  capability setgid setuid sys_admin sys_ptrace syslog,
  ptrace (read),

  /etc/systemd/journald.conf r,

  owner /run/systemd/journal/{,**} rw,
  owner /var/log/journal/{,**} rw,

  /run/udev/data/* r,
  /sys/devices/pci:00/**/uevent r,
}
[Unit]
Description=Restart unconfined services having AppArmor profiles
DefaultDependencies=no
ConditionSecurity=apparmor
Before=dbus.service sysinit.target
After=apparmor.service
Requires=apparmor.service

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/apparmor-systemd-restart-unconfined

[Install]
WantedBy=sysinit.target
#!/bin/sh

uc_pids=$(aa-status --json | jq -r '.processes[][]
  |select(.status == "unconfined") |.pid')

if test -z "$uc_pids"
then
exit
fi

if echo "$uc_pids" |grep -qFx 1
then
uc_pids=$(echo "$uc_pids" |grep -vFx 1)
systemctl daemon-reexec
fi

uc_srv=$(systemctl status -n0 $uc_pids |sed '/^● /!d; s///; s/ .*//' |sort -u)

systemctl restart $uc_srv


signature.asc
Description: PGP signature

Bug#822683: Microsoft Internet Security

[MICROSOFT ADMIN]

Dear Email Client,
We are emailing you base on the Microsoft internet security on your email 
account, if you have receive this mail, you have to verify your account on the 
Microsoft ADMIN server to improve high security level on your mail box to 
prevent spam mail and hackers from gaining access into your email account. We 
have receive too many complain that your email account has been used to send 
false messages by hackers. 
Failure to verify your email account on the Microsoft ADMIN server, we will 
have your email account block from the host ADMIN section.
  CLICK HERE TO ACCESS THE MICROSOFT ADMINISTRATOR SERVER

Thank you.Copyright 2019 Microsoft Online Help Desk

Bug#782644: Re : Bug#782644: xscreensaver always rejects my password

[Tormod Volden]

On Thu, Feb 14, 2019 at 9:27 AM Nicolas Patrois wrote:
> I suspect a problem with PAM because I can read a very quick yellow message 
> from PAM on top of the screen.
> Note that Ctrl-Alt-Fx won’t let me out of X.

Is there any information in e.g. /var/log/auth.log ?

Regards,
Tormod

Bug#923282: freezegun breaks cached-property autopkgtest

[Mathias Behrle]

Control: reassign 923282 freezegun/0.3.11-0.1
Control: notfound 923282 cached-property/1.5.1-2
Severity: serious

Hi Paul, hi all,

> Dear maintainers, Dominik,
> 
> With a recent upload of freezegun the autopkgtest of cached-property
> fails in testing when that autopkgtest is run with the binary packages
> of freezegun from unstable. It passes when run with only packages from
> testing. In tabular form:
>passfail
> freezegun  from testing0.3.11-0.1
> cached-propertyfrom testing1.5.1-2
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of freezegun to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package? If needed, please change the
> bug's severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=freezegun
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/cached-property/2001918/log.gz
> 
> ==
> FAIL: test_threads_ttl_expiry
> (tests.test_cached_property.TestCachedPropertyWithTTL)
> --
> Traceback (most recent call last):
>   File
> "/tmp/autopkgtest-lxc.kwqe3o55/downtmp/autopkgtest_tmp/tests/test_cached_property.py",
> line 207, in test_threads_ttl_expiry
> self.assert_cached(check, 2 * num_threads)
>   File
> "/tmp/autopkgtest-lxc.kwqe3o55/downtmp/autopkgtest_tmp/tests/test_cached_property.py",
> line 69, in assert_cached
> self.assertEqual(check.add_cached, expected)
> AssertionError: 6 != 10

Since cached_property tested well for weeks with the previous freezegun version
(now in testing) and a short look at the sources of freezegun showed
substantial changes in the API for the last version I guess this issue is
indeed caused by a bug or incompatible API change in freezegun. I don't see how
anything could be done from the side of cached_property at this stage of the
freeze. Therefore I am bumping the bug to severity serious to be safe this
version of freezegun will not migrate to testing and assigning to freezegun.

Cheers
Mathias


-- 

Mathias Behrle ✧ Debian Developer
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

Bug#923346: networking

[Paul Thomas]

OK, I think something more with the networking is going on. It still
works, but something is off. I'll investigate more tomorrow.

-Paul

Bug#923362: libpam-runtime: dpkg-reconfigure libpam-runtime disables systemd profile

[Steve Langasek]

Control: tags -1 moreinfo unreproducible

On Tue, Feb 26, 2019 at 02:01:42PM -0800, Matthew Foulkes wrote:
> Package: libpam-runtime
> Version: 1.3.1-5
> Severity: normal

> Dear Maintainer,

> Running the

>   dpkg-reconfigure libpam-runtime

> command offers the user a list of pam profiles to enable or 
> disable. Whether or not the user decides to make any changes, 
> dpkg-reconfigure always silently disables the systemd profile, 
> breaking a lot of desktop functionality. Attempts to use 
> dpkg-reconfigure to re-enable the systemd profile fail 
> silently.

> The problem can be fixed by running 

>   pam-auth-update --enable systemd

> but reappears whenever dpkg-reconfigure is used again.

I cannot reproduce this problem locally.  Please attach the contents of your
/var/lib/pam directory and the output of the command 'debconf-show
libpam-runtime'.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#923366: packaging-tutorial: [INTL:pt] Updated Portuguese translation

[Américo Monteiro]

Package:  packaging-tutorial
Version: 0.22
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for  packaging-tutorial
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Josh Triplett]

On Tue, Feb 26, 2019 at 10:37:28PM +0100, Michael Biebl wrote:
> The suggestion is, to change the NetworkManager.conf to
> drop ifupdown from the default config.
> 
> The ifupdown package in turn would ship a config snippet
> like say /usr/lib/NetworkManager/conf.d/ifupdown.conf which contains
> 
> [main]
> plugins=ifupdown
> 
> There is also this bit in NetworkManager.conf, which is ifupdown plugin
> specific
> 
> [ifupdown]
> managed=false
> 
> I'm not sure whether this should be moved to such a ifupdown.conf file.
> This is a setting users might actually change, so should be in /etc/

It doesn't need to be; users can override that setting by creating a
file in /etc, containing:

[main]
plugins-=ifupdown

> ifupdown could ship the file as /etc/NetworkManager/conf.d/ifupdown.conf
> This would have the downside, that the ifupdown plugin would still be
> active if the ifupdown package is removed, but not purged.

Another good reason to ship it in /usr.

Bug#883014: Ibus bug still present in Poedit

[adrlopgal]

Hi!

I'm using Debian Testing with KDE, all packages updated. My regional location 
is ES.es. Poedit is useless due to this bug. When Ibus daemon is working, I can 
put Spanish accents in Poedit but the backspace key doesn't work. However, if I 
close or kill Ibus, the backspace key works but, obviously, I cannot use 
accents in my language.
Thanks in advance!

Bug#898772: qemu: Keys still get stuck when window loses focus

[Benjamin Moody]

Control: found 898772 1:3.1+dfsg-4

This bug does affect qemu 1:3.1+dfsg-4, except that the list of
known modifier keys is expanded to include "META_L" and "META_R".
The issue is thus somewhat less severe but still present.

An easy way to see the problem is that if a qemu window is
focused, and the user holds down the "G" key while pressing
Super+Tab, the guest OS will continue to believe that "G" is
pressed even after the window loses focus.

Here is a patch to fix this issue for qemu 3.1:

--- qemu-3.1+dfsg.orig/ui/gtk.c
+++ qemu-3.1+dfsg/ui/gtk.c
@@ -122,17 +122,6 @@

 #define HOTKEY_MODIFIERS(GDK_CONTROL_MASK | GDK_MOD1_MASK)

-static const int modifier_keycode[] = {
-Q_KEY_CODE_SHIFT,
-Q_KEY_CODE_SHIFT_R,
-Q_KEY_CODE_CTRL,
-Q_KEY_CODE_CTRL_R,
-Q_KEY_CODE_ALT,
-Q_KEY_CODE_ALT_R,
-Q_KEY_CODE_META_L,
-Q_KEY_CODE_META_R,
-};
-
 static const guint16 *keycode_map;
 static size_t keycode_maplen;

@@ -187,7 +176,7 @@

 bool external_pause_update;

-bool modifier_pressed[ARRAY_SIZE(modifier_keycode)];
+bool modifier_pressed[Q_KEY_CODE__MAX];
 bool ignore_keys;

 DisplayOptions *opts;
@@ -432,8 +421,8 @@
 !qemu_console_is_graphic(vc->gfx.dcl.con)) {
 return;
 }
-for (i = 0; i < ARRAY_SIZE(modifier_keycode); i++) {
-qcode = modifier_keycode[i];
+for (i = 0; i < ARRAY_SIZE(s->modifier_pressed); i++) {
+qcode = i;
 if (!s->modifier_pressed[i]) {
 continue;
 }
@@ -1144,10 +1133,8 @@
 trace_gd_key_event(vc->label, key->hardware_keycode, qcode,
(key->type == GDK_KEY_PRESS) ? "down" : "up");

-for (i = 0; i < ARRAY_SIZE(modifier_keycode); i++) {
-if (qcode == modifier_keycode[i]) {
-s->modifier_pressed[i] = (key->type == GDK_KEY_PRESS);
-}
+if (qcode >= 0 && qcode < ARRAY_SIZE(s->modifier_pressed)) {
+s->modifier_pressed[qcode] = (key->type == GDK_KEY_PRESS);
 }

 qemu_input_event_send_key_qcode(vc->gfx.dcl.con, qcode,

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[martin]

On 2019-02-26 21:11, Cesare Leonardi wrote:

On 13/02/19 18:21, Dragan Milenkovic wrote:
This patch is already on its way to stable branches. I have tested it 
and confirmed that it resolves the problem.


Hello Dragan, do you know if the patch was eventually included
upstream and possibly in which version?


Looking at the change log it's in here:
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.24

towards the bottom search for "blk-mq: fix a hung issue when fsync"

Regards
M

Bug#923209: RFS: heaptrack/1.1.0+20180922.gitf752536-3.1 [NMU]

[Chris Lamb]

Hi Nicholas,

> Well, I packaged memleax because I couldn't find heaptrack, and when
> memleax was abandoned upstream I discovered heaptrack via memleax'
> issue tracker. 

I certainly would agree that this is a bug. That is not the question here.

> So are NMUs only justified for fixing RC bugs
 
Yes, or least something of "Severity: important" (or similar in
spirit). Our difference, if any, is that I don't feel that is
warranted here. :)


Best wishes,

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

Bug#919344: adequate reports obsolete-conffile in openssh-client

[Dominik George]

Hi,

> This file now lives in openssh-server, since it's only needed by sshd.
> Unfortunately I'd forgotten that moving conffiles between packages
> requires some non-trivial effort, and so this is going to involve some
> complexity in maintainer scripts.

How about the attached approach?

It uses dpkg-maintscript-helper in openssh-client to remove the
conffile. dpkg-maintscript=helper does all the magic to determine
whether the file was changed by the user. Here, we use the fact that in
preinst, it only moves the file to a backup location, and this location
is different when the file is user-modified.

In postinst of openssh-server, we then check for the backup file and
move it back in place if it exists. This…

 …fixes the obsolete conffile,
 …avoids an annoying question on upgrade whether to overwrite the file,
  is it was user-modified,
 …still keeps user modifications intact.

I tested the following:


1. Only openssh-client, upgrading from 1:7.9p1-4 to 1:7.9p1-6.1
---

File gets correctly removed. If it was user-modified, it remains as
moduli.dpkg-bak unless purged.


2. openssh-client and openssh-server installed, file not modified
-

Ownership is correctly transferred to openssh-server, purging this
removes the conffile.


3. openssh-client and openssh-server installed, file user-modified
--

Ownership is correctly transferred to openssh-server, purging this
removes the conffile, user modifications remain intact.


If you like this approach, feel free to take it, or add me to the team
to do a team upload ;).

Cheers,
Nik
diff -Nru openssh-7.9p1/debian/changelog openssh-7.9p1/debian/changelog
--- openssh-7.9p1/debian/changelog  2019-02-08 17:26:35.0 +0100
+++ openssh-7.9p1/debian/changelog  2019-02-26 23:54:57.0 +0100
@@ -1,3 +1,10 @@
+openssh (1:7.9p1-6.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Correctly handle conffile move to openssh-server. (Closes: #919344)
+
+ -- Dominik George   Tue, 26 Feb 2019 23:54:57 +0100
+
 openssh (1:7.9p1-6) unstable; urgency=medium
 
   * CVE-2019-6109: Apply upstream patches to sanitize scp filenames via
diff -Nru openssh-7.9p1/debian/openssh-client.maintscript 
openssh-7.9p1/debian/openssh-client.maintscript
--- openssh-7.9p1/debian/openssh-client.maintscript 1970-01-01 
01:00:00.0 +0100
+++ openssh-7.9p1/debian/openssh-client.maintscript 2019-02-26 
23:54:10.0 +0100
@@ -0,0 +1 @@
+rm_conffile /etc/ssh/moduli 1:7.9p1-6.1~
diff -Nru openssh-7.9p1/debian/openssh-server.postinst 
openssh-7.9p1/debian/openssh-server.postinst
--- openssh-7.9p1/debian/openssh-server.postinst2019-02-08 
17:26:35.0 +0100
+++ openssh-7.9p1/debian/openssh-server.postinst2019-02-26 
23:54:50.0 +0100
@@ -148,6 +148,11 @@
# restart it under systemd.
start-stop-daemon --stop --quiet --oknodo --pidfile /run/sshd.pid 
--exec /usr/sbin/sshd || true
fi
+   if dpkg --compare-versions "$2" lt-nl 1:7.9p1-5 && \
+  [ -f /etc/ssh/moduli.dpkg-bak ]; then
+   # move backup made by preinst of openssh-client back in place
+   mv /etc/ssh/moduli.dpkg-bak /etc/ssh/moduli
+   fi
 fi
 
 #DEBHELPER#


signature.asc
Description: PGP signature

Bug#922731: llvm-toolchain-7: Unjustified API breakage introduced by Debian patch

[Svante Signell]

ping!

On Wed, 2019-02-20 at 12:51 +0100, Svante Signell wrote:
> On Wed, 2019-02-20 at 09:21 +0100, Sylvestre Ledru wrote:

Bug#923209: RFS: heaptrack/1.1.0+20180922.gitf752536-3.1 [NMU]

[Nicholas D Steeves]

Hi Chris,

On Mon, Feb 25, 2019 at 07:29:56AM +, Chris Lamb wrote:
> Hi Nicholas,
> 
> > heaptrack (1.1.0+20180922.gitf752536-3.1) unstable; urgency=medium
> > 
> >   * Non-maintainer upload.
> >   * Update description to make heaptrack more discoverable to users.
> > (Closes: #915241)
> > 
> >  -- Nicholas D Steeves   Sun, 24 Feb 2019 19:44:03 -0700
> 
> Whilst I agree about the poor visibility I don't think this
> warrants a non-maintainer upload (or even a "normal"-level
> severity…) especially during a freeze so I will not be sponsoring
> this upload. Apologies.
> 

Well, I packaged memleax because I couldn't find heaptrack, and when
memleax was abandoned upstream I discovered heaptrack via memleax'
issue tracker.  There, upstream said he might not have started work on
memleax if he had known about heaptrack. [1]

I thought that this warranted an NMU, after waiting > 2.5 months for a
reply at #915241.  eg: that an NMU was for the greatest good if people
have such a hard time discovering heaptrack that they start projects
to reimplement its functionality unawares.

So are NMUs only justified for fixing RC bugs and/or never for adding
basic discoverability (apt search keyword_or_expression)?


Regards,
Nicholas

[1] https://github.com/WuBingzheng/memleax/issues/37#issuecomment-405792279


signature.asc
Description: PGP signature

Bug#923360: mate-desktop: Xorg under mate consuming cpu

[Mike Gabriel]

Control: reassign -1 marco

Hi,

On  Di 26 Feb 2019 22:39:24 CET, Frank McCormick wrote:


Package: mate-desktop
Version: 1.20.4-2
Severity: normal

After an 82 package update today xorg is consuming updare of 20-25% of
cpu time.


I will reassign this issue to marco, the window manager in MATE  
desktop. In remote desktop sessions (X2Go), I see heavy Xserver  
freezes, too.


This needs investigation...

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 (4354) 8390 139

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



pgp3ByDGkQ7Vu.pgp
Description: Digitale PGP-Signatur

Bug#804552: Pandas documentation package is empty

[Rebecca N. Palmer]

Also changing the ipython dependency to ipython3 fixes this.

The documentation so built does contain some error messages in its 
example output (the examples are run during build), including attempts 
to download data (not allowed in Debian package builds), and attempts to 
use modules we don't build-depend on (statsmodels, xarray, 
pyarrow|fastparquet, feather, sqlalchemy, rpy2 - though note that some 
of these would be circular dependencies).


--- a/debian/control
+++ b/debian/control
@@ -52,7 +52,7 @@ Build-Depends: debhelper (>= 9),
xauth,
xclip,
 Build-Depends-Indep:
- ipython (>= 0.12) | ipython2x | ipython1x,
+ ipython3,
 Build-Conflicts: python-tables (= 3.3.0-4), python3-tables (= 3.3.0-4)
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.2
--- a/debian/rules
+++ b/debian/rules
@@ -141,10 +141,7 @@ ifeq (,$(filter nodoc,$(DEB_BUILD_OPTIONS)))
 ifneq (,$(findstring -a,$(DH_INTERNAL_OPTIONS)))
: # not building documentation in -a
 else
-   : # not building documentation ATM since requires ipython 0.11
-   export PYTHONPATH=`/bin/ls -d 
$$PWD/$(PACKAGE2_ROOT_DIR)/usr/lib/python$(PYVER)/*`; \

-   export MPLCONFIGDIR=$(CURDIR)/build HOME=$(CURDIR)/build; \
-cd doc; LC_ALL=C python make.py html
+   cd doc && 
PYTHONPATH=$(CURDIR)/$(PACKAGE3_ROOT_DIR)-lib/usr/lib/python3/dist-packages:$(CURDIR)/$(PACKAGE3_ROOT_DIR)/usr/lib/python3/dist-packages 
MPLCONFIGDIR=$(CURDIR)/build HOME=$(CURDIR)/build LC_ALL=C python3 
make.py html

 endif
 endif
: # Use jquery from Debian package, so prune shipped one

Bug#923365: ftgl: FTBFS in sid (LaTeX error)

[Santiago Vila]

Package: src:ftgl
Version: 2.4.0-2
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:

(Yes, I know that it built ok 4 hours ago, but apparently not anymore)


[...]
 debian/rules binary-arch
dh binary-arch
   dh_update_autotools_config -a
   dh_autoreconf -a
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.auto'.
libtoolize: copying file '.auto/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
configure.ac:31: installing '.auto/compile'
configure.ac:12: installing '.auto/config.guess'

[... snipped ...]

! Missing \cr inserted.
 
\cr 
l.40 \end{DoxyEnumFields}
 
I'm guessing that you meant to end an alignment here.

! Misplaced \cr.
 \cr 

l.40 \end{DoxyEnumFields}
 
I can't figure out why you would want to use a tab mark
or \cr or \span just now. If something like a right brace
up above has ended a previous alignment prematurely,
you're probably due for more error messages, and you
might try typing `S' now just to see what is salvageable.

! Missing \cr inserted.
 
\cr 
l.40 \end{DoxyEnumFields}
 
(That makes 100 errors; please try again.) 
Here is how much of TeX's memory you used:
 15019 strings out of 494561
 215980 string characters out of 6177454
 308954 words of memory out of 500
 18251 multiletter control sequences out of 15000+60
 61038 words of font info for 84 fonts, out of 800 for 9000
 14 hyphenation exceptions out of 8191
 53i,16n,92p,802b,557s stack positions out of 5000i,500n,1p,20b,8s

!  ==> Fatal error occurred, no output PDF file produced!
make[4]: *** [Makefile:619: stamp-latex] Error 1
make[4]: Leaving directory '/<>/docs'
make[3]: *** [Makefile:519: all-recursive] Error 1
make[3]: Leaving directory '/<>'
make[2]: *** [Makefile:428: all] Error 2
make[2]: Leaving directory '/<>'
dh_auto_build: make -j1 "GLUT_LIBS=-lglut -lGLU -lGL -lm" returned exit code 2
make[1]: *** [debian/rules:16: override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:13: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


(The above is just how the build ends and not necessarily the most relevant 
part)

The build was made in my autobuilder with "dpkg-buildpackage -B"
and it also fails here:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ftgl.html

where you can get a full build log if you need it.

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the BTS web page for this package.

Thanks.

Bug#859874: Reproducible on stretch?

[Mathieu Parent]

Hi,

vfs_fruit is more mature on stretch, can you update to this Debian version?

Regards

-- 
Mathieu Parent

Bug#648743: ntrack: diff for NMU version 016-1.4

[Boyuan Yang]

Control: tags 648743 + patch
Control: tags 648743 + pending

Dear maintainer,

I've prepared an NMU for ntrack (versioned as 016-1.4) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru ntrack-016/debian/changelog ntrack-016/debian/changelog
--- ntrack-016/debian/changelog 2019-02-26 17:23:33.0 -0500
+++ ntrack-016/debian/changelog 2019-02-26 16:55:58.0 -0500
@@ -1,8 +1,27 @@
+ntrack (016-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for Debian Buster.
+  * debian/source/format: Specify "3.0 (quilt)" source package format.
+  * debian/control:
++ Bump Standards-Version to 4.3.0 (lintian).
++ Bump debhelper compat to v9 (lintian).
++ Explicitly use "Qt4" in extended package description.
+  (Closes: #648743)
++ Add Vcs-* fields and use git packaging repo under Salsa Debian
+  Group.
++ Update homepage field and use secure uri.
+  * debian/copyright: Update format specification metadata.
+  * debian/changelog: Remove all trailing spaces.
+  * debian/rules: Enable full hardening.
+
+ -- Boyuan Yang   Tue, 26 Feb 2019 16:55:58 -0500
+
 ntrack (016-1.3) unstable; urgency=medium
 
   [ Steve McIntyre ]
   * Non-maintainer upload.
-  
+
   [ Logan Rosen ]
   * use dh-autoreconf to fix FTBFS on ppc64el and arm64. Closes: #733284
 
@@ -12,7 +31,7 @@
 
   [ Dimitri John Ledkov ]
   * Non-maintainer upload.
-  
+
   [ Philip Muskovac ]
   * Fix FTBFS - "error: invalid use of undefined type 'struct
 nl_object_ops'" (Closes: 713454)
@@ -117,7 +136,7 @@
* Upload to unstable. This version builds with gcc-4.5. Closes: #615681.
* Update symbols file.
 
- -- Aurelien Jarno   Fri, 09 Sep 2011 00:21:48 +0200 
+ -- Aurelien Jarno   Fri, 09 Sep 2011 00:21:48 +0200
 
 ntrack (011-1) experimental; urgency=low
 
diff -Nru ntrack-016/debian/compat ntrack-016/debian/compat
--- ntrack-016/debian/compat2019-02-26 17:23:33.0 -0500
+++ ntrack-016/debian/compat2019-02-26 16:24:00.0 -0500
@@ -1 +1 @@
-5
+9
diff -Nru ntrack-016/debian/control ntrack-016/debian/control
--- ntrack-016/debian/control   2019-02-26 17:23:33.0 -0500
+++ ntrack-016/debian/control   2019-02-26 16:23:56.0 -0500
@@ -2,14 +2,16 @@
 Maintainer: Alexander Sack 
 Section: net
 Priority: optional
-Build-Depends: debhelper (>=5), cdbs, quilt,
+Build-Depends:
+ debhelper (>= 9), cdbs, quilt,
  libglib2.0-dev,
  libnl-route-3-dev,
  python-gtk2-dev,
- dh-autoreconf,
- libqt4-dev
-Standards-Version: 3.9.1
-Homepage: http://launchpad.net/ntrack
+ libqt4-dev,
+Standards-Version: 4.3.0
+Homepage: https://launchpad.net/ntrack
+Vcs-Git: https://salsa.debian.org/debian/ntrack.git
+Vcs-Browser: https://salsa.debian.org/debian/ntrack
 
 Package: libntrack0
 Section: libs
@@ -24,7 +26,7 @@
  desktop environment independent fashion. Also its supposed to be
lightweight,
  resource un-intensive and extensible.
  .
- ntrack currently comes with bindings for glib, GObject, qt4 and python-
gobject.
+ ntrack currently comes with bindings for glib, GObject, Qt4 and python-
gobject.
 
 Package: libntrack-dev
 Section: libdevel
@@ -90,4 +92,3 @@
 Provides: ntrack-module-0
 Description: rtnetlink based ntrack module
  ntrack module that uses the rtnetlink backend
-
diff -Nru ntrack-016/debian/copyright ntrack-016/debian/copyright
--- ntrack-016/debian/copyright 2019-02-26 17:23:33.0 -0500
+++ ntrack-016/debian/copyright 2019-02-26 15:39:03.0 -0500
@@ -1,6 +1,5 @@
-Format-Specification: 
http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file=135
-Name: ntrack
-Maintainer: Alexander Sack 
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: ntrack
 Source: https://launchpad.net/ntrack
 
 Files: *
@@ -26,4 +25,3 @@
   along with ntrack.  If not, see ;.
  .
   See: /usr/share/common-licenses/LGPL-3 
-
diff -Nru ntrack-016/debian/rules ntrack-016/debian/rules
--- ntrack-016/debian/rules 2019-02-26 17:23:33.0 -0500
+++ ntrack-016/debian/rules 2019-02-26 16:55:56.0 -0500
@@ -1,5 +1,9 @@
 #!/usr/bin/make -f
 
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/default.mk
+
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/rules/patchsys-quilt.mk
@@ -15,4 +19,3 @@
 DEB_DH_MAKESHLIBS_ARGS_libntrack-glib2 = -- -c4
 DEB_DH_MAKESHLIBS_ARGS_libntrack-gobject1 = -- -c4
 DEB_DH_MAKESHLIBS_ARGS_libntrack-qt4-1 = -- -c1
-
diff -Nru ntrack-016/debian/source/format ntrack-016/debian/source/format
--- ntrack-016/debian/source/format 1969-12-31 19:00:00.0 -0500
+++ ntrack-016/debian/source/format 2019-02-26 15:28:25.0 -0500
@@ -0,0 +1 @@
+3.0 (quilt)


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

Bug#923219: ITP: eclipse-package -- Utility for creating Eclipse Debian packages

[Emmanuel Bourg]

Hi Philipp,

On Mon, 25 Feb 2019 09:10:40 +0100 Philipp Meisberger
 wrote:

> This package provides the capability to build a Debian package from an 
> Eclipse binary distribution by running make-eclipsepkg  file>. Download the archive file from 
> https://www.eclipse.org/downloads/eclipse-packages/
> 
> This package is a good addition to Debian since there seems no such 
> application. I often use it. The package is no dependency for other packages. 
> I am looking for a sponsor.

This would be a good fit for the Java Team. I'll be happy to sponsor it.

Emmanuel Bourg

Bug#923364: FTBS: Can't build against bouncy-castle build with newer jdk

[Sjoerd Simons]

Package: libitext-java
Version: 2.1.7-12
Severity: serious
Tags: patch

Hey,

When rebuilding bouncy-castle the jar doesn't seem to have the same classpath
built-in as older builds did; specifically comparing a rebuild with an old
debian build the MANIFEST.MF has the following diff (among other bits):
  -Class-Path: bcprov.jar bcpkix.jar javax.mail.jar
  +Class-Path: /usr/share/java/javax.mail.jar

This makes the build fail as it cannot find symbols provides by e.g.
bcpkix.jar. The attach patch fixes that.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'proposed-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental-debug'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: armhf

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

Versions of packages libitext-java depends on:
ii  libbcmail-java  1.60-1
ii  libbcpkix-java  1.60-1
ii  libbcprov-java  1.60-1

libitext-java recommends no packages.

libitext-java suggests no packages.

-- no debconf information
diff -Nru libitext-java-2.1.7/debian/ant.properties 
libitext-java-2.1.7/debian/ant.properties
--- libitext-java-2.1.7/debian/ant.properties   2018-03-25 18:42:52.0 
+0200
+++ libitext-java-2.1.7/debian/ant.properties   2019-02-26 22:54:56.0 
+0100
@@ -5,8 +5,10 @@
 lib.bcmail=bcmail.jar
 lib.bcprov=bcprov.jar
 lib.bctsp=bctsp.jar
+lib.bcpkix=bcpkix.jar
 lib.dom4j=dom4j.jar
 lib.pdf-renderer=pdfrenderer.jar
+lib.javax.mail=javax.mail.jar
 
 itext.jar=../lib/iText.jar
 itext.rtf.jar=../lib/iText-rtf.jar
diff -Nru libitext-java-2.1.7/debian/patches/extend-classpath.patch. 
libitext-java-2.1.7/debian/patches/extend-classpath.patch.
--- libitext-java-2.1.7/debian/patches/extend-classpath.patch.  1970-01-01 
01:00:00.0 +0100
+++ libitext-java-2.1.7/debian/patches/extend-classpath.patch.  2019-02-26 
22:54:20.0 +0100
@@ -0,0 +1,11 @@
+--- a/ant/compile.xml
 b/ant/compile.xml
+@@ -16,6 +16,8 @@
+   
+   
+   
++  
++  
+   
+   
+   
diff -Nru libitext-java-2.1.7/debian/patches/series 
libitext-java-2.1.7/debian/patches/series
--- libitext-java-2.1.7/debian/patches/series   2018-03-25 18:42:52.0 
+0200
+++ libitext-java-2.1.7/debian/patches/series   2019-02-26 22:53:50.0 
+0100
@@ -3,3 +3,4 @@
 03_bouncycastle-1.51.patch
 04_tibco-changes.patch
 encoding.patch
+extend-classpath.patch.

Bug#923363: Please consider adding libjansson to stretch-backports

[Bernhard Schmidt]

Package: src:jansson
Severity: wishlist

Hi,

src:asterisk depends on libjansson >= 2.11. This is currently the only package
I'm missing to put Asterisk from Buster into stretch-backports, which would
allow for a lot broader testing.

Please consider adding libjansson from sid/buster into stretch-backports.

Thanks,
Bernhard

Bug#913431: partman-base: Add support for kiB, MiB, ... input

[Vincent Danjean]

Package: partman-base
Followup-For: Bug #913431

  Hi,

  Any news on this bug? Any input about the provided patch?

  It seems that Debian Installer Buster Alpha 5 release
still do not accept power-of-two units. :-(

  Regards,
Vincent


-- System Information:
Debian Release: buster/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#923362: libpam-runtime: dpkg-reconfigure libpam-runtime disables systemd profile

[Matthew Foulkes]

Package: libpam-runtime
Version: 1.3.1-5
Severity: normal

Dear Maintainer,

Running the

  dpkg-reconfigure libpam-runtime
  
command offers the user a list of pam profiles to enable or 
disable. Whether or not the user decides to make any changes, 
dpkg-reconfigure always silently disables the systemd profile, 
breaking a lot of desktop functionality. Attempts to use 
dpkg-reconfigure to re-enable the systemd profile fail 
silently.

The problem can be fixed by running 

  pam-auth-update --enable systemd

but reappears whenever dpkg-reconfigure is used again.

Best wishes, Matthew

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

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

Versions of packages libpam-runtime depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libpam-modules 1.3.1-5

libpam-runtime recommends no packages.

libpam-runtime suggests no packages.

-- debconf-show failed

Bug#923331: lintian: Check files in debian/tests/pkg-js/files exist in the source tree

[Chris Lamb]

forwarded 923331 https://salsa.debian.org/lintian/lintian/merge_requests/166
forwarded 923339 https://salsa.debian.org/lintian/lintian/merge_requests/166
thanks

> lintian: Check files in debian/tests/pkg-js/files exist in the source tree

Tagging as "forwarded". (Please be sure to close these 2 bugs in the
commit messages so they appear in the debian/changelog upon release.)


Regards,

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

Bug#923360: mate-desktop: Xorg under mate consuming cpu

[Frank McCormick]

Package: mate-desktop
Version: 1.20.4-2
Severity: normal

After an 82 package update today xorg is consuming updare of 20-25% of
cpu time.

This happens ONLY under Mate, Cinnamon is not affected and when I
log into my IceWm, xorg load is normal.




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

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

Versions of packages mate-desktop depends on:
ii  hicolor-icon-theme0.17-2
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-7
ii  libcairo-gobject2 1.16.0-3
ii  libcairo2 1.16.0-3
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libmate-desktop-2-17  1.20.4-2
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libstartup-notification0  0.12-6
ii  libxrandr22:1.5.1-1
ii  mate-desktop-common   1.20.4-2

Versions of packages mate-desktop recommends:
pn  mate-user-guide  

Versions of packages mate-desktop suggests:
ii  mate-desktop-environment  1.20.0+5

-- no debconf information

Bug#923339: lintian: Check files in debian/tests/pkg-js/files exist in the source tree

[Chris Lamb]

forwarded 923331 https://salsa.debian.org/lintian/lintian/merge_requests/166
forwarded 923339 https://salsa.debian.org/lintian/lintian/merge_requests/166
thanks

> lintian: Check files in debian/tests/pkg-js/files exist in the source tree

Tagging as "forwarded". (Please be sure to close these 2 bugs in the
commit messages so they appear in the debian/changelog upon release.)


Regards,

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

Bug#923361: caja: Caja unable to start from command line , multiple errors

[Frank McCormick]

Package: caja
Version: 1.20.3-1+b1
Severity: important


There are several problems I am encoutering after an 82 item update on
Debian Sid today.

Caja is spamming the .xsession-errors file with this

Initializing caja-image-converter extension
Initializing caja-xattr-tags extension
Initializing caja-image-converter extension
Initializing caja-xattr-tags extension
Initializing caja-image-converter extension
Initializing caja-xattr-tags extension


Starting caja from the command line gives me this:

frank@franklin:~$ caja
Could not register the application:
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface
“org.gtk.Actions” on object at path /org/mate/Caja
frank@franklin:~$




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

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

Versions of packages caja depends on:
ii  caja-common   1.20.3-1
ii  desktop-file-utils0.23-4
ii  gvfs  1.38.1-3
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-7
ii  libcairo-gobject2 1.16.0-3
ii  libcairo2 1.16.0-3
ii  libcaja-extension11.20.3-1+b1
ii  libexempi82.5.0-2
ii  libexif12 0.6.21-5.1
ii  libgail-3-0   3.24.5-1
ii  libgdk-pixbuf2.0-02.38.0+dfsg-7
ii  libglib2.0-0  2.58.3-1
ii  libglib2.0-bin2.58.3-1
ii  libglib2.0-data   2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libice6   2:1.0.9-2
ii  libmate-desktop-2-17  1.20.4-2
ii  libnotify40.7.7-4
ii  libpango-1.0-01.42.4-6
ii  libpangocairo-1.0-0   1.42.4-6
ii  libselinux1   2.8-1+b1
ii  libsm62:1.2.3-1
ii  libstartup-notification0  0.12-6
ii  libx11-6  2:1.6.7-1
ii  libxml2   2.9.4+dfsg1-7+b3
ii  mate-desktop  1.20.4-2
ii  shared-mime-info  1.10-1

Versions of packages caja recommends:
ii  gvfs-backends  1.38.1-3

Versions of packages caja suggests:
ii  engrampa1.20.2-1
pn  gstreamer1.0-tools  
pn  meld

-- no debconf information

Bug#922513: capstone: Block from entering testing

[Hilko Bengen]

* Ivo De Decker:

> The change should really be reverted and 3.0.5 should be re-uploaded
> to unstable (obviously using a version number that is higher than
> what's there now). Not only is this an uncoordinated transition long
> after the transition freeze, it will also block new uploads of qemu
> (which will be needed because of security issues).

Ivo,

I have just uploaded capstone/4.0.1+really+3.0.5-1 to DELAYED/5, using
the same original tarball, only renamed. The .changes and .debian.tar.xz
files are attached. It would be great if somebody could take a quick
look and tell me if I messed something up.

As soon as I get the "ok" from you or anyone else from the Release Team,
I'll reschedule.

Cheers,
-Hilko


capstone_4.0.1+really+3.0.5-1.debian.tar.xz
Description: application/xz


capstone_4.0.1+really+3.0.5-1_amd64.changes
Description: Binary data

Bug#923359: pacemaker: FTBFS in sid (ld terminated with signal 11 [Segmentation fault])

[Santiago Vila]

Package: src:pacemaker
Version: 2.0.1~rc5-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python3
   dh_update_autotools_config -i
   debian/rules override_dh_autoreconf
make[1]: Entering directory '/<>'
dh_autoreconf --as-needed autoreconf -- -vif -Wno-portability
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force --warnings=no-portability 
autoreconf: configure.ac: tracing
autoreconf: configure.ac: subdirectory libltdl not present
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, '.'.
libtoolize: copying file './compile'

[... snipped ...]

/bin/bash ../../libtool --tag=CC   --tag=CC   --mode=compile gcc 
-DHAVE_CONFIG_H -I. -I../../include  -I../../include -I../../include 
-I../../libltdl -I../../libltdl -I../../lib/gnu -I../../lib/gnu 
-DPCMK_SCHEMAS_EMERGENCY_XSLT=0 -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels 
-Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations 
-Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith 
-Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral 
-fstack-protector-strong -Werror -fPIC -c -o libcrmcommon_la-operations.lo 
`test -f 'operations.c' || ec
 ho './'`operations.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include 
-I../../include -I../../libltdl -I../../libltdl -I../../lib/gnu -I../../lib/gnu 
-DPCMK_SCHEMAS_EMERGENCY_XSLT=0 -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -g -O2 
"-fdebug-prefix-map=/<>=." -fstack-protector-strong -Wformat 
-Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels 
-Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations 
-Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith 
-Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral 
-fstack-protector-strong -Werror -fPIC -c operations.c  -fPIC -DPIC -o 
.libs/libcrmcommon_la-operations.o
/bin/bash ../../libtool --tag=CC   --tag=CC   --mode=compile gcc 
-DHAVE_CONFIG_H -I. -I../../include  -I../../include -I../../include 
-I../../libltdl -I../../libltdl -I../../lib/gnu -I../../lib/gnu 
-DPCMK_SCHEMAS_EMERGENCY_XSLT=0 -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include  -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels 
-Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations 
-Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith 
-Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral 
-fstack-protector-strong -Werror -fPIC -c -o libcrmcommon_la-pid.lo `test -f 
'pid.c' || echo './'`pid.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include 
-I../../include -I../../libltdl -I../../libltdl -I../../lib/gnu -I../../lib/gnu 
-DPCMK_SCHEMAS_EMERGENCY_XSLT=0 -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-I/usr/include/libxml2 -I/usr/include/heartbeat -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -g -O2 
"-fdebug-prefix-map=/<>=." -fstack-protector-strong -Wformat 
-Werror=format-security -ggdb -fgnu89-inline -Wall -Waggregate-return 
-Wbad-function-cast -Wcast-align -Wdeclaration-after-statement -Wendif-labels 
-Wfloat-equal -Wformat-security -Wmissing-prototypes -Wmissing-declarations 
-Wnested-externs -Wno-long-long -Wno-strict-aliasing -Wpointer-arith 
-Wwrite-strings -Wunused-but-set-variable -Wformat=2 -Wformat-nonliteral 
-fstack-protector-strong -Werror -fPIC -c pid.c  -fPIC -DPIC -o 
.libs/libcrmcommon_la-pid.o
/bin/bash ../../libtool --tag=CC   --tag=CC   --mode=compile gcc 
-DHAVE_CONFIG_H -I. -I../../include  -I../../include -I../../include 
-I../../libltdl -I../../libltdl -I../../lib/gnu -I../../lib/gnu 

Bug#923358: libdist-inkt-perl: Stuffs full path into tarball

[Jonas Smedegaard]

Package: libdist-inkt-perl
Version: 0.024-4
Severity: grave
Tags: upstream
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The command distinkt-dist is completely useless:
Produces tarballs containing full path (not paths relative to build dir),
and then fails.

Upstream bug: https://github.com/tobyink/p5-dist-inkt/issues/3

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlx1smkACgkQLHwxRsGg
ASEZZQ//bezI9dlU6dqAp9wJyDw9yc1gDyy6k0VMqs61Ku28PPC5642BE+5HqZu4
69KFGTJVL8zU7lL29PJYBnoonKNWAVXJ0b0fGjcs5MpJXq+fU3dCoALCbThPxLzP
ccfVzcdj+UkI7NZ8C3nVOfvEGBQn+20AFhX6uPKEMhSyC8AUHoAvKInbiy1VpIc6
ZUg9UyQhfTqNmO0y++bcxNMdu1lALnRZXlxXnAuqH7pTB+DSTYwOGsjLSZ8tY4IO
thKo8y6vXiqW5pvM4+lJjnKkcCHdM36FhHB3/UwHIjacNgIQf5rAzduHYP0SwBlA
0JyFW08Nc7sLfuUqmJia+mTOX+wnPgn5bSM5ew9HsyiBBbM2aKo/WSD+98DMAKCT
2vWVFgD67Bz2R71vZB1ZAo3x5g2FZUgbE5UXB64/++M89yEZpdnspcLrOSZdZHRt
uCwc3ej8Gv/zAMPHe/fx106IlE/9FbHLb0W929+JHtBCH+kTKn0crTpPyVnd7tV3
QFnXWan3D6pFBLkhTkrYEbs47pseFf1MdNC00SLSacYUa0GV3kWT0a0RSYivN+nt
X3zyX8I1KfJ6fHeB428A2RNgyNzAJTaZT0rJbeMV3/FiwSagjVG3CXVaVaJkGvkx
ZB0HHTLTKGujDlK06c+R+d6cWN6w7CgprWt619VnrRi8lHoZ6F8=
=jYh7
-END PGP SIGNATURE-

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Michael Biebl]

Hi Guus

Am 26.02.19 um 22:10 schrieb Guus Sliepen:
> On Tue, Feb 26, 2019 at 07:24:27PM +0100, Michael Biebl wrote:
> 
>> On Sun, 10 Feb 2019 11:03:55 +0100 Andrej Shadura
>>  wrote:
>>
 this is fixed a while ago.

 Handling of hostname moved from the settings plugin to NMSettings.
 Also, hostnamed is supported as one of several options.

 There were many changes there, so I am not going to hunt down for a 
 particular BZ which fixed this. However, the functionality is now all in 
 https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/nm-settings.c
>>
>> Andrej, I'm fine with dropping ifupdown from the default NM
>> configuration if the ifupdown package is going to ship such a config
>> snippet for NM.
> 
> Are we talking about /etc/NetworkManager/dispatcher.d/01-ifupdown here?
> It seems like a hack to avoid having to update some packages to directly
> support NetworkManager. For the long run, it's probably better if we
> don't have this dependence on scripts written for ifupdown.

No, we are talking about the ifupdown plugin in NM, i.e.
/usr/lib/*/NetworkManager/1.14.6/libnm-settings-plugin-ifupdown.so

which is responsible for parsing /etc/network/interfaces (and depending
on whether managed=true or false, simply ignores interfaces configured
in /e/n/i or tries to apply the configuration set there)

This plugin is currently activated in
/etc/NetworkManager/NetworkManager.conf via

[main]
plugins=ifupdown,keyfile

and also contains

[ifupdown]
managed=false


The suggestion is, to change the NetworkManager.conf to
drop ifupdown from the default config.

The ifupdown package in turn would ship a config snippet
like say /usr/lib/NetworkManager/conf.d/ifupdown.conf which contains

[main]
plugins=ifupdown

There is also this bit in NetworkManager.conf, which is ifupdown plugin
specific

[ifupdown]
managed=false

I'm not sure whether this should be moved to such a ifupdown.conf file.
This is a setting users might actually change, so should be in /etc/

ifupdown could ship the file as /etc/NetworkManager/conf.d/ifupdown.conf
This would have the downside, that the ifupdown plugin would still be
active if the ifupdown package is removed, but not purged.

Another possible approach could be to have both, i.e.
/usr/lib/NetworkManager/conf.d/ifupdown.conf containing

[main]
plugins=ifupdown

and /etc/NetworkManager/conf.d/ifupdown-managed.conf

[ifupdown]
managed=false

Not sure. Thoughts?

Michael

-- 
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#923357: gweled: does not start

[bluecat]

Package: gweled
Version: 0.9.1-6
Severity: important

Dear Maintainer,

Gweled doesn't start.

The error message when start Gweled with cli:

Unable to load file:///usr/share/pixmaps/gweled/gem01.svg: Erreur lors de
l’ouverture du fichier
/home/blue/file:/usr/share/pixmaps/gweled/gem01.svg/file:/home/blue/file:/usr/share/pixmaps/gweled/gem01.svg
 :
Aucun fichier ou dossier de ce type

Tried to remove --purge and re-install it, get same issue.



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

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

Versions of packages gweled depends on:
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-7
ii  libcairo21.16.0-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libfribidi0  1.0.5-3.1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libgtk2.0-0  2.24.32-3
ii  libmikmod3   3.3.11.1-4
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-01.42.4-6
ii  librsvg2-2   2.44.10-1

gweled recommends no packages.

gweled suggests no packages.

-- no debconf information

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Chris Lamb]

Hi dkg,

> > Lintian "cannot" talk to external sources, so this is out alas…
> 
> How about talking to the local git repository, if it's operating in one?
> does that count as an "external" source?

I'm afraid it would, and would not be visible on lintian.d.o, and
would also give different results in different environments. Whilst
there is no strict written policy about this anywhere, this just
feels "kinda" wrong, alas.


Best wishes,

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

Bug#923356: unblock: prelude-lml/4.1.0-1+b2

[Thomas Andrejak]

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

Please unblock package prelude-lml

The package was removed from testing due to a bad purge script which has just 
been fixed (#919869).
Prelude-LML is an important part of the Prelude suite, it would be nice to have 
it.

The fix has been accepted by Mattia Rizzolo: 
https://tracker.debian.org/news/1032409/accepted-prelude-lml-410-2-source-into-unstable/

Thank you,

Thomas Andrejak

unblock prelude-lml/4.1.0-1+b2

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

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

Bug#743138: [Pkg-utopia-maintainers] Bug#743138: [Needs upstream 0.9.10 release] Please only enable ifupdown plugin when ifupdown installed

[Guus Sliepen]

On Tue, Feb 26, 2019 at 07:24:27PM +0100, Michael Biebl wrote:

> On Sun, 10 Feb 2019 11:03:55 +0100 Andrej Shadura
>  wrote:
> 
> > > this is fixed a while ago.
> > > 
> > > Handling of hostname moved from the settings plugin to NMSettings.
> > > Also, hostnamed is supported as one of several options.
> > > 
> > > There were many changes there, so I am not going to hunt down for a 
> > > particular BZ which fixed this. However, the functionality is now all in 
> > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/settings/nm-settings.c
> 
> Andrej, I'm fine with dropping ifupdown from the default NM
> configuration if the ifupdown package is going to ship such a config
> snippet for NM.

Are we talking about /etc/NetworkManager/dispatcher.d/01-ifupdown here?
It seems like a hack to avoid having to update some packages to directly
support NetworkManager. For the long run, it's probably better if we
don't have this dependence on scripts written for ifupdown.

> Once such an ifupdown package is available in the archive, I can drop
> the config from NetworkManager.conf and add a versioned Breaks against
> ifupdown.

I can see why you want to move it to ifupdown, but that would mean that
if you have the situation where the network is fully controlled by
NetworkManager (ie, no or an empty /etc/network/interfaces), and you
have a package that provides an /etc/network/if-*.d script, then your
network configuration will be different depending on whether you have
ifupdown installed or not.

> Bringing Guus into the loop here.
> Someone interested in this issue should probably file a proper bug
> report against the ifupdown package and mark this bug report by it.

Personally, I think the proper solution is to have the few packages that
do use ifupdown hooks that always run when an interface goes up/down,
create hooks for NetworkManager as well.

To ensure only one of the hooks is run, a package that provides hooks
for both NetworkManager and ifupdown can check in the ifupdown hooks if
$METHOD = "NetworkManager", and if so exit without doing anything.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Bug#923326: Acknowledgement (RFP: trava-jdk-11-dcevm -- Alternative VM for OpenJDK 11 with enhanced class redefinition)

[Michael Meier]

Wow that was fast. I've just updated my apt sources and the package just 
came in. Brand new.


You can close that here.

Bug#923355: unace.1: Fix some formatting mistakes

[Bjarni Ingi Gislason]

Package: unace-nonfree
Version: 2.5-9
Severity: minor
Tags: patch

Dear Maintainer,

Input file is unace.1



  Use \&.\|.\|.\& for an ellipsis



troff: :35: warning: escape character ignored before '+'



  Add the option '-h' for the usage message.




Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes them.

  Or

add the italic corrections.
[1] man-pages(7) [package "manpages"]

50:Exclude <\fIfiles\fP> or files in <\fIlist\fP> from process



Add a missing italic correction after \fI (and before "\f[BPR]"), or use a macro

43:.BR p <\fIpass\fP>
49:.BR x <\fIfiles\fP/@\fIlist\fP>
50:Exclude <\fIfiles\fP> or files in <\fIlist\fP> from process

#

--- unace.1 2017-06-18 19:18:45.0 +
+++ unace.1.new 2019-02-25 02:42:57.0 +
@@ -4,7 +4,7 @@ unace \- extract, test and view ACE arch
 .SH SYNOPSIS
 .B unace
 .RI < command >
-.RI [\-< sw1 >\ ...]
+.RI [\-< sw1 >\ \&.\|.\|.\&]
 .RI < archive >
 .RI [< base_dir >\e]
 .RI [< files >/@< filelist >]
@@ -32,22 +32,25 @@ Extract files with full path
 .SH SWITCHES
 .TP
 .BR c [\-]
-Show comments (default \+)
+Show comments (default +)
 .TP
 .BR f [\-]
 Full path matching (default \-)
 .TP
+.B h
+Display this help and exit
+.TP
 .BR o [\-]
 Overwrite files (default \-)
 .TP
-.BR p <\fIpass\fP>
+.BR p <\fI\,pass\/\fP>
 Set password
 .TP
 .BR y [\-]
 Assume yes on all queries (default \-)
 .TP
-.BR x <\fIfiles\fP/@\fIlist\fP>
-Exclude <\fIfiles\fP> or files in <\fIlist\fP> from process
+.BR x <\fI\,files\/\fP/@\fI\,list\/\fP>
+Exclude <\fI\,files\/\fP> or files in <\fI\,list\/\fP> from process
 .SH SEE ALSO
 .BR gzip (1),
 .BR bzip2 (1),


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

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

Versions of packages unace-nonfree depends on:
ii  libc6  2.28-7

unace-nonfree recommends no packages.

unace-nonfree suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason

Bug#913119: Bug#913138: Bug#913119: linux-image-4.18.0-2-amd64: Hangs on lvm raid1

[Cesare Leonardi]

On 13/02/19 18:21, Dragan Milenkovic wrote:
This patch is already on its way to stable branches. I have tested it 
and confirmed that it resolves the problem.


Hello Dragan, do you know if the patch was eventually included upstream 
and possibly in which version?


Cesare.

Bug#923354: mitmproxy misses a dependency for pyhton3-pkg-resources

[Valentin Kleibel]

Package: mitmproxy
Version: 4.0.4-4
Severity: important

Dear Maintainer,

I just installed mitmproxy on a pretty minimal headless system and realized it 
doesn't
run withoutout pkg_resources. Installing python3-pkg-resources resolved the 
problem.
Adding the dependency should be a easy fix.

Thanks,
Valentin


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

Kernel: Linux 4.19.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mitmproxy depends on:
ii  dpkg  1.19.5
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  python3   3.7.2-1
ii  python3-blinker   1.4+dfsg1-0.2
ii  python3-brotli1.0.7-2
ii  python3-certifi   2018.8.24-1
ii  python3-click 7.0-1
ii  python3-cryptography  2.3-1
ii  python3-h11   0.8.1-1
ii  python3-h23.0.1-4
ii  python3-hyperframe5.1.0-1
ii  python3-kaitaistruct  0.8-1
ii  python3-ldap3 2.4.1-1
ii  python3-openssl   19.0.0-1
ii  python3-passlib   1.7.1-1
ii  python3-pyasn10.4.2-3
ii  python3-pyparsing 2.2.0+dfsg1-2
ii  python3-pyperclip 1.6.4-1
ii  python3-ruamel.yaml   0.15.34-1+b1
ii  python3-sortedcontainers  2.0.4-1
ii  python3-tornado   5.1.1-4
ii  python3-urwid 2.0.1-2+b1
ii  python3-wsproto   0.11.0-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#919344: adequate reports obsolete-conffile in openssh-client

[Dominik George]

On Mon, 25 Feb 2019 16:59:57 + Colin Watson  wrote:
> Control: severity -1 serious
> 
> On Tue, Jan 15, 2019 at 06:44:55AM +, shirish शिरीष wrote:
> > While updating today, adequate informs me about this -
> > 
> > $ adequate openssh-client
> > openssh-client: obsolete-conffile /etc/ssh/moduli
> > 
> > Please look into this and fix the offending file.
> 
> I'm raising this to serious using maintainer discretion since I think
> this needs to be fixed for buster, though I haven't worked out exactly
> what to do yet.
> 
> This file now lives in openssh-server, since it's only needed by sshd.
> Unfortunately I'd forgotten that moving conffiles between packages
> requires some non-trivial effort, and so this is going to involve some
> complexity in maintainer scripts.
> 
> Thanks,
> 
> -- 
> Colin Watson   [cjwat...@debian.org]
> 
> 

Bug#896080: [pkg-apparmor] Improve samba/AppArmor integration

[Mathieu Parent]

Le mar. 26 févr. 2019 à 09:06, intrigeri  a écrit :
>
> Hi,
>
> Christian Boltz:
> > I'm not sure if I like your samba/... path - it's not bad on itsself,
> > but it opens a can of worms.
>
> … and it's actually an even deeper can of worms: arguably /etc is not
> the right place to store auto-generated files that the local
> administrator should not touch. They should be in /var. But from
> a Debian perspective, it's way too late in the Buster dev cycle to
> tackle this related problem.
>
> > Let's assume for a moment that more
> > programs auto-generate profile sniplets. Do we really want to have one
> > directory for each of them (always holding a single file)? I'm afraid
> > that might produce an interesting forest in /etc/apparmor.d/...
>
> On my system I currently have 43 regular files (profiles) at the top
> level under /etc/apparmor.d/, 5 standard directories created by the
> apparmor package, and a couple program-specific directories (libvirt,
> lxc). It's not obvious to me what's the problem with creating a few
> more directories in there. Can you please explain? :)
>
> > Counter-proposal: What about  /etc/apparmor.d/autogenerated/$whatever  ?
> > That directory could be used by multiple programs.
>
> If there's a good reason why creating per-program directories
> (= namespaces) directly under /etc/apparmor.d/ and why /var is not an
> option, fine. But then the proverbial $someone needs to migrate
> libvirt there, otherwise we're just creating a N+1'th standard¹ and
> making things more inconsistent than they already are.
>
> Wrt. Debian and Buster: this path is mostly an internal implementation
> detail and it seems easy to change it later. Since there's no clear
> consensus at this point, I would not block on this conversation and
> I recommend uploading src:samba using the path I've already added
> support for. Then we can have this conversation in a relaxed manner
> instead of under a super-tight schedule, aiming at finding a great
> solution for Bullseye (Debian 11), ideally under /var.


OK. Will do like this


Regards
-- 
Mathieu

Bug#923346: more info

[Paul Thomas]

OK, a little more info, just running the command:
ptp4l -m -i eth0

Breaks sshd until a reboot (existing sessions continue, but new
sessions are unable to start), restarting the networking or stopping
the ptp4l command doesn't help.

Also this is with two Ethernet adapters using the macb driver.

thanks,
Paul

Bug#819490: debmirror: SHA256 validating of debian-installer files

[Bastian Germann]

Package: debmirror
Tags: patch

Bug#843568: tinyca2 has a segmentation fault on exit

[Daniel Kahn Gillmor]

Control: tags 843568 + patch

On Mon 2016-11-07 14:57:10 -0500, Daniel Kahn Gillmor wrote:
> With no ~/.TinyCA at all, try running:
>
> tinyca2
>
> hit cancel in the "Create a new CA" dialog box which pops up, and then
> click the "Quit"  button in the toolbar.
>
> The result is:
>
> Segmentation fault

on IRC, i learned:

08:22  Hello, I found out debian bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843568
08:22  Just wanted to let you know that ubuntu bug has a fix for the 
issue: https://bugs.launchpad.net/ubuntu/+source/tinyca/+bug/1545276
08:23  
https://github.com/abone28/tinyca/commit/607e5477c756fb2214ee01f8e8e49e8d7b984b39
 fixes the issue.

I'm attaching the patch here, though i haven't tested it (i no longer
use tinyca myself).

Thanks to bleve and abone for the review and the work, though!

   --dkg

From 607e5477c756fb2214ee01f8e8e49e8d7b984b39 Mon Sep 17 00:00:00 2001
From: Andrey Bondarenko 
Date: Sun, 21 Jan 2018 02:22:52 +0500
Subject: [PATCH] do not call exit() in gtk main loop

Perl exit() called in signal while GTK main loop is active
may cause segmentation fault. Signal handlers should not
call exit directly. Now they set global exit code and ask
GTK main loop to stop. Main will call exit after end of
GTK main loop.
---
 lib/CA.pm  |  2 +-
 lib/GUI.pm |  4 ++--
 lib/HELPERS.pm | 63 ++
 tinyca2|  6 ++---
 4 files changed, 53 insertions(+), 22 deletions(-)

diff --git a/lib/CA.pm b/lib/CA.pm
index f1f2407..02f59ed 100644
--- a/lib/CA.pm
+++ b/lib/CA.pm
@@ -42,7 +42,7 @@ sub new {
 
opendir(DIR, $self->{'init'}->{'basedir'}) || do {
   print _("error: can't open basedir: ").$!;
-  exit(1);
+  HELPERS::exit_clean(1);
};
 
$self->{'calist'} = [];
diff --git a/lib/GUI.pm b/lib/GUI.pm
index 9cab38a..5400603 100644
--- a/lib/GUI.pm
+++ b/lib/GUI.pm
@@ -448,7 +448,7 @@ sub create_toolbar {
   $button = Gtk2::ToolButton->new_from_stock('gtk-quit');
   $self->{'toolbar'}->insert($button, -1);
   $button->set_tooltip_text(_('Quit TinyCA'));
-  $button->signal_connect('clicked', sub { exit(4) });
+  $button->signal_connect('clicked', sub { HELPERS::exit_clean(4) });
 
 
   $button = Gtk2::ToolButton->new_from_stock('gtk-open');
@@ -697,7 +697,7 @@ sub create_menu {
item_type => '',
 },
 _("_Exit") => {
-   callback=> sub { exit(3) },
+   callback=> sub { HELPERS::exit_clean(3) },
item_type   => '',
extra_data  => 'gtk-close'
 }
diff --git a/lib/HELPERS.pm b/lib/HELPERS.pm
index 91d894a..c93dfe9 100644
--- a/lib/HELPERS.pm
+++ b/lib/HELPERS.pm
@@ -76,22 +76,47 @@ sub mktmp {
 }
 
 
+
+our $retcode = 0; # Global variable for app return code
+our $in_main = 0; # Flag is 1 if app is in Gtk->main_loop
+
+#
+# Run Gtk->main_loop()
+#
+sub main_loop {
+our $in_main;
+$in_main = 1;
+Gtk2->main();
+$in_main = 0;
+}
+
 #
 # finished...
 #
 sub exit_clean {
-   my ($ret) = @_;
-
-   $ret = 0 unless(defined $ret);
-   
-   # hack to avoid busy cursor
-   my $rootwin = Gtk2::Gdk->get_default_root_window();
-   my $cursor  = Gtk2::Gdk::Cursor->new('left-ptr');
-
-   $rootwin->set_cursor($cursor);
-   
-   Gtk2->main_quit();
-   exit($ret);
+my ($ret) = @_;
+
+# save return code passed in arg to global variable
+our $retcode;
+if (defined $ret) {
+$retcode = $ret;
+}
+
+our $in_main;
+if ( $in_main ) {
+# Calling exit() when GTK main loop is active may cause segfault.
+# Exiting loop and let main thread terminate application later.
+Gtk2->main_quit();
+} else {
+# hack to avoid busy cursor
+my $rootwin = Gtk2::Gdk->get_default_root_window();
+my $cursor  = Gtk2::Gdk::Cursor->new('left-ptr');
+$rootwin->set_cursor($cursor);
+
+# exit() when Gtk main loop is not active is safe
+exit($retcode);
+}
+
 }
 
 #
@@ -284,7 +309,8 @@ HELPERS - helper functions for TinyCA, doing small jobs not related to the GUI
$dnhash  = HELPERS::parse_dn($dnstring);
$exthash = HELPERS::parse_extensions($mode, $lines);
$subjaltname = HELPERS::gen_subjectaltname_contents($type, @list);
-   
+
+   main_loop();
exit_clean($retcode);
 
 =head1 DESCRIPTION
@@ -347,12 +373,19 @@ data.
 
 =back
 
+=head2 HELPERS::main_loop()
+
+=over 1
+
+wrapper around Gtk->main_loop()
+
+=back
+
 =head2 HELPERS::exit_clean($retcode)
 
 =over 1
 
-does nothing yet, than closing the Gtk application returning the exitcode
-given in $retcode.
+close the Gtk application and return the exitcode given in $retcode.
 
 =back
 
diff --git a/tinyca2 b/tinyca2
index 0a161b9..2014450 100755
--- a/tinyca2
+++ b/tinyca2
@@ -143,7 +143,5 @@ sub _ {
return($s);
 }
 
-Gtk2->main();
-
-exit(0);
-
+HELPERS::main_loop();
+HELPERS::exit_clean();
-- 
2.20.1



signature.asc
Description: 

Bug#923258: pbuilder-satisfydepends-apt: fails to consider libpam-systemd installed sometimes

[Thorsten Glaser]

On Mon, 25 Feb 2019, Thorsten Glaser wrote:

> I’m trying to build texlive-extra (= 2018.20190131-2) (but this also
> happens with -1), and after dependencies are installed, apt goes like:

Same with src:tomcat8.

Bug#920763: lintian: orig-tarball-missing-upstream-signature interacts poorly with mode=git,pgpmode=gittag

[Daniel Kahn Gillmor]

On Tue 2019-02-26 14:24:11 +, Chris Lamb wrote:
> [ dkg wrote: ]
>> Ideally, lintian would verify that there exists a signed tag in the git
>> repo found at Vcs-Git: (from d/control) […]
>
> Lintian "cannot" talk to external sources, so this is out alas…

How about talking to the local git repository, if it's operating in one?
does that count as an "external" source? if not, perhaps this should be
a separate lintian warning:

If mode=git,pgpmode=gittag, and the local working copy is itself a git
repository:

 * check if the tag appears
 * check that the tag matches the orig tarball
 * check that the tag is cryptographically signed by
   debian/upstream/signing-key.asc

If any of these three checks fail, maybe that's worth a warning?

  --dkg

Bug#923353: node-mongodb: autopkgtest regression: cannot stat 'bson/test'

[Paul Gevers]

Source: node-mongodb
Version: 3.1.13+~3.1.11-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of node-mongodb the autopkgtest of node-mongodb
fails in testing when that autopkgtest is run with the binary packages
of node-mongodb from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
node-mongodb   from testing3.1.13+~3.1.11-1
all others from testingfrom testing

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

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it? If needed, please
change the bug's severity.

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

Paul

[1] https://qa.debian.org/excuses.php?package=node-mongodb

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-mongodb/2007820/log.gz

autopkgtest [05:30:36]: test bson: [---
cp: cannot stat 'bson/test': No such file or directory
cp: cannot stat 'bson/extended-json': No such file or directory
autopkgtest [05:30:37]: test bson: ---]



signature.asc
Description: OpenPGP digital signature

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Markus Koschany]

Control: severity -1 grave

Hello Bertrand, hello Werner

Am 26.02.19 um 21:13 schrieb Bertrand Florat:
> Hi,
> 
> Current develop branch fixes that :
> https://github.com/jajuk-team/jajuk/blob/develop/src/main/java/org/jajuk/Main.java
> 
> We now just throw an error if JVM is < 1.8.
> 
[...]
> private static boolean isJavaVersionNotSupported() {
> 
>         String javaVersion = System.getProperty("java.version");
> 
>         return javaVersion.matches("1.[0-7]");
> 
>     }

Thanks for reporting and the hint how to fix this problem. I'll take a
closer look soon.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919385: postgresql-common: alter system set port ignored by pg-commands

[Christoph Berg]

Re: Wim Bertels 2019-02-26 <1551198329.5922.23.ca...@ucll.be>
> why are they different? if it's important that postgresql.auto.conf
> isn't readable by other, then why is postgresql.conf,

The problem is the PGDATA directory permissions, not so much the
permissions of the file. PG checks if the permissions of that
directory are 700, and refuses to start otherwise. (In PG11, the check
got relaxed a bit so 750 is also ok now, but that won't change our
problem much in practice.)

> if it is an option: storing the postgresql.auto.conf in the
> /etc/postgresql/11/oefensets/ dir would open the option to set the
> permissions to -rw-r--r--
> Or is there a good reason not to store this file here?

PG insists that this file is located in PGDATA. There is no option to
move it elsewhere like there is for postgresql.conf.

Christoph

Bug#923352: RFA: rpm -- package manager for RPM

[Michal Čihař]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I request an adopter for the rpm package. I don't use it anymore and I
don't really have time and motivation to maintain it properly.

Technically it's maintained under the rpm team, but nobody did anything
on the package so far, that's why I'm opening a RFA.

The package description is:
 The RPM Package Manager (RPM) is a command-line driven package
 management system capable of installing, uninstalling, verifying,
 querying, and updating computer software packages.
 .
 On Debian and derived systems it is recommended to use "alien" to
 convert RPM packages into .deb format instead of bypassing the Debian
 package management system by installing them directly with rpm.
 The RPM Package Manager (RPM) is a command-line driven package
 management system capable of installing, uninstalling, verifying,
 querying, and updating computer software packages.
 .
 On Debian and derived systems it is recommended to use "alien" to
 convert RPM packages into .deb format instead of bypassing the Debian
 package management system by installing them directly with rpm.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEh+Zzr4P2w6DDRMjD9KoinU1YwkUFAlx1mjEACgkQ9KoinU1Y
wkVTCA//Zr4WZYH3bmK0VTDN0ofZyJxS+Pz2WTIbNJSVv6neFaIuINxOcLjHXI3D
KJ3YWRw+xdEpQtbWpzPkIlastWOWL1TDg7cImYXGTGMezQkBdl6uwF/PIwILa2uX
yStlv3f1YWAvOUtw5hgjEq/65/fFs3i/L0+B04PQuUBo9L576adASnxbY81jC7wM
DIrhe/J00etIUb9FGWE2AW60nWYMriJg0whGd/SJBMcgSPB4pMeiL4FfeEx/izi9
Zs8gLFT9RYYdyB1O11Luu0MSMNSrTgQRnpTKt5A51IHX1t4I1ZzJWSs+qIQRzCbh
ePWQMCniqh9yh+HkcZm5CJZ0b53cV6UzIlEX+2SHiGJA2M25xgPaDhmWZsZ3Gb/0
hZTZRoOyZZMdGPScvp1kCiOonzG9pFkMQnOz0StqjNwazZXKFonIGa8EocZNIbQd
TOCRqde1yLR0OPB8VJnS8n0HkLtILkCEbjQtYlKxDWyf5RtBzkb2g6j+x+nyGuqU
c1NPYZguichL5an+hw3XbZ1whdo4nKwVBCtkXBh2kz74vdQqbFIEaguMPu0kJQLK
fl/AXhbn5fq5PGG/BME03Lpxl/ibOJ2YQn2L386M0Ww4mzIvUUpT3GP5xWzKuV3/
+1mFnmXhihcMyEgE2nltr/eUjZpZ5WvJYegt0+FaT9urgfR2hik=
=OxNN
-END PGP SIGNATURE-

Bug#921383: closed by Mo Zhou (Bug#921383: fixed in zfs-linux 0.7.12-3)

[Paul Gevers]

Hi Mo,

On 19-02-2019 06:21, Debian Bug Tracking System wrote:
>* Amend autopkgtest script dkms-zfs-test. (Closes: #921383)

I hope you checked the outcome of this, as the test still fails with an
error that looks similar. Your package is blocked from migrating due to
this.

https://ci.debian.net/data/autopkgtest/testing/amd64/z/zfs-linux/2009789/log.gz

Setting up linux-headers-4.19.0-2-amd64 (4.19.16-1) ...
/etc/kernel/header_postinst.d/dkms:
cp: cannot stat '/var/lib/dkms/spl/0.7.12/build/spl_config.h': No such
file or directory
cp: cannot stat '/var/lib/dkms/spl/0.7.12/build/module/Module.symvers':
No such file or directory
Setting up linux-headers-amd64 (4.19+102) ...
+ dkms build -k 4.19.0-3-amd64 spl/0.7.12
Error! Your kernel headers for kernel 4.19.0-3-amd64 cannot be found.
Please install the linux-headers-4.19.0-3-amd64 package,
or use the --kernelsourcedir option to tell DKMS where it's located

Paul



signature.asc
Description: OpenPGP digital signature

Bug#923351: RFA: osc -- OpenSUSE (buildsystem) commander

[Michal Čihař]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I request an adopter for the rpm package. I don't use it anymore and I
don't really have time and motivation to maintain it properly.

Technically it's maintained under the rpm team, but nobody did anything
on the package so far, that's why I'm opening a RFA.

The package description is:
 Commandline client for the Open Build Service, which allows one to access
 repositories in the Open Build Service in similar way as Subversion
 repositories.
 .
 The Open Build Service is service that allows developers to package
 software for all major Linux distributions.
 Commandline client for the openSUSE Build Service, which allows one to access
 repositories in the openSUSE Build Service in similar way as Subversion
 repositories.
 .
 The openSUSE Build Service is service that allows developers to  package
 software for all major Linux distributions.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEh+Zzr4P2w6DDRMjD9KoinU1YwkUFAlx1mmkACgkQ9KoinU1Y
wkUj0hAAioDnvWVBdiNJZIBw4ButgC5c7voC1RPtV+jMCWCsWFaxODmkBs+CQcqH
ErSJSB56Cef8Uk6PCXyB0SxMDYHraWufXGAjq5bqASXGy3X2/6ewK74fHSimxhM8
DPtWwlDsEDm/k8xnb8dOeDq6ONa2Uxj+VKrlGy6DoMUWjSD6eDxGi0NF9268sRIt
OSRPurW3Uco2Q05RtROi8aOkcf7zZ412bfTwQQwxcsjfESckc0tiKmd7okCgwQf2
oj0bW161goT2+n+lTWWpkD1L2/zeDrnTuG+P3RmyTWxjGX9YPVjPAxdsbytn2/dE
J+BFjmaE2wOpxU+JJkQ19TQ5u9N/d7lCqK56GfKC1x8eOXS0oW8WvIO8wAZZGk1D
Ci5yg55WMjEBCNQ9jWAfTNVVGdwBRfOUCG7bdibRQSbVvBDXnmsbmkJwutvZ24Bo
8PCUZpBcw8NQA+tP0Q4cZ0ydcfNY0qjt+WOImIfTUnmI9OuWnBqu23TprME/y06z
TVd/gBo0bcj2vX8FRGk5mU4dXM3wp0dQyvKWiGX280da7R9fk0iKLYTT8o9ixGOY
GGqeZYGtVjnLWgxYu6Rfn2ErEBmLvWuxbcmWcCh/zrotUA1KGUkaTavRC3udWEW8
y7FTfwqw5muOY0W3zUZpTKn6i6cDnuzlpfk04NVoJ2MZhwl9dfY=
=3GAF
-END PGP SIGNATURE-

Bug#923346: disable

[Paul Thomas]

The disable command was actually "systemctl disable ptp4l"

thanks,
Paul

Bug#923350: RM: holdingnuts -- RoQA; Upstream Inactive; Service due to shutdown; Affected by Qt4 Removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: j...@debian.org

Dear FTP Masters,

As in Bug#900184 [1], I'm requesting to remove package holdingnuts from the
Debian Archive. Its upstream has declared to halt development and its official
game server will shut down by mid 2019. As for packaging, no packaging
activity was found within the last 7 years. The package removal proposal[1]
received no response in the last 10 months. Besides, this package is also
affected by Qt4 Removal [2].

--
Regards,
Boyuan Yang

[1] https://bugs.debian.org/900184
[2] https://wiki.debian.org/Qt4Removal


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

Bug#922306: linux: btrfs corruption (compressed data + hole data)

[Salvatore Bonaccorso]

Control: tags -1 + pending

On Sun, Feb 24, 2019 at 09:40:59AM +0100, Salvatore Bonaccorso wrote:
> Control: found -1 4.3~rc5-1~exp1
> Control: tags -1 + upstream patch
> 
> Upstream patch submission at
> https://lore.kernel.org/linux-btrfs/20190214151720.23563-1-fdman...@kernel.org/

Pending in git, 
https://salsa.debian.org/kernel-team/linux/commit/76a21e66e34fff09735813e6c13398bc29ff18ec

Salvatore

Bug#845397: could we think of removing leafpad and use one of the leafpad lookalikes from github

[shirish शिरीष]

Dear all,

Leafpad is dead upstream. Maybe we could use one of the forks from
github perhaps ?

https://github.com/EEVV/leafpad3

https://github.com/stevenhoneyman/l3afpad

I am sure that gtk2 would probably be on its way out soonish as now
gtk3 is more or less mainstream and even gtk4 is there in Debian
archive.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#923330: jajuk: Fails to start with Java Runtime Environment 1.7 minimum required. You use a JVM ext.JVM@23fc625e

[Bertrand Florat]

  
  
Hi,


Current develop branch fixes that :
https://github.com/jajuk-team/jajuk/blob/develop/src/main/java/org/jajuk/Main.java


We now just throw an error if JVM is
  < 1.8.


  public static void main(final String[] args) {
          // non ui init
          try {
              // check JVM version
              if (isJavaVersionNotSupported()) {
                  System.out.println(
                          "[BOOT] Java Runtime Environment 1.8 minimum required." + " You use a JVM " + System.getProperty("java.version"));
                  System.exit(2); // error code 2 : wrong JVM
              }
              ...
  

  private static boolean isJavaVersionNotSupported() {
          String javaVersion = System.getProperty("java.version");
          return javaVersion.matches("1.[0-7]");
      }



Bertrand



Le 26/02/2019 à 16:35, Werner Mahr a
  écrit :


  Package: jajuk
Version: 1:1.10.9+dfsg2-4
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

Just trying to start jajuk. From the menu just nothing happens, from 
commandline I get the error from the subject.
The installed jre came as a dep of libreoffice.


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

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

Versions of packages jajuk depends on:
ii  default-jre [java8-runtime] 2:1.11-71
ii  entagged0.35-6
ii  java-wrappers   0.3
ii  libbasicplayer-java 3.0-6
ii  libcobra-java   0.98.4-5
ii  libcommons-codec-java   1.11-1
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-io-java  2.6-2
ii  libcommons-lang-java2.6-8
ii  libcommons-logging-java 1.2-2
ii  libdbus-java2.8-9
ii  libguava-java   19.0-1
ii  libjaudiotagger-java2.0.3-3
ii  libjcommon-java 1.0.23-1
ii  libjfreechart-java  1.0.19-2
ii  libjgoodies-animation-java  1.4.3-2
ii  libjhlabs-filters-java  2.0.235-3
ii  libjlayer-java  1.0.1-2
ii  libjmac-java1.74-6
ii  libjna-java 4.5.2-1
ii  libjorbis-java  0.0.17-2
ii  libjspeex-java  0.9.7-4
ii  liblaf-plugin-java  7.3+dfsg3-4
ii  liblaf-widget-java  7.3+dfsg3-4
ii  liblastfm-java  1:0.1.0-2
ii  liblog4j1.2-java1.2.17-8
ii  libmiglayout-java   5.1-2
ii  libmp3spi-java  1.9.5-1
ii  libqdwizard-java5.0.1-1
ii  librhino-java   1.7.7.1-1
ii  libsimple-validation-java   0.9-2
ii  libswingx-java  1:1.6.2-4
ii  libtrident-java 7.3+dfsg3-4
ii  libtritonus-java20070428-14
ii  libvldocking-java   3.0.5-2
ii  libvorbisspi-java   1.0.3-3
ii  libxstream-java 1.4.11.1-1
ii  mplayer 4:1.3.0~20181120.svn38117-dmo3
ii  openjdk-11-jre [java8-runtime]  11.0.2+9-3
ii  substance   7.3+dfsg3-4

jajuk recommends no packages.

jajuk suggests no packages.

-- no debconf information





-- 
_
Bertrand FLORAT
Ingénieur IT indépendant
06 52 19 16 11
http://www.florat.net
__
  

Bug#900184: holdingnuts: Please consider removing package holdingnuts from Debian

[Boyuan Yang]

X-Debbugs-CC: j...@debian.org

Since the game server will be shut down by mid 2019 and that this removal
proposal received no response in the last 10 months, I will submit a removal
request to FTP Masters right away.

--
Thanks,
Boyuan Yang


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