Bug#916715: toulbar2: What will happen if testing migration takes longer than removal from testing

[Andreas Tille]

Hi,

toulbar2 is

   Marked for autoremoval on 22 February: #916715

However, this bug was closed in


toulbar2 (1.0.0+dfsg3-1.1) unstable; urgency=medium

  * Non-maintainer upload.
  * Add the missing build dependency on zlib1g-dev. (Closes: #916715)

 -- Adrian Bunk   Fri, 11 Jan 2019 13:47:51 +0200


The problem is that the package did not migrated due to #920459 (doxygen
currently breaks lots of packages and I wonder in general what will
happen with those packages).  I now uploaded


toulbar2 (1.0.0+dfsg3-2) unstable; urgency=medium
...
  * Prevent generation of PDF documentation since otherwise toulbar2 does
not build (see bug #920459).  This means should be reverted once doxygen
is fixed.
...
 -- Andreas Tille   Mon, 18 Feb 2019 22:17:10 +0100


Which enabled the build on all release architectures.

I'm simply wondering what will happen with toulbar2 (and other packages
- I'm actually not that much involved in this, it is just a random
Debian Science package) once it was removed from testing.  As far as I
understood there will be no migrations from unstable to testing any more
if there is no version of that package in testing.  Does that mean that
the doxygen issues will kick several packages out of Buster or is there
any way to prevent this?

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#922636: dpkg-genchanges: Please do not exclude packages from the Binary field

[Mattia Rizzolo]

On Mon, Feb 18, 2019 at 06:16:43PM +0100, Thorsten Glaser wrote:
> And/or talk to the Launchpad developers…

FYI, I filed a bug in launchpad the very same day…
https://bugs.launchpad.net/launchpad/+bug/1813037

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#922447: lighttpd: autopkgtest regression

[Helmut Grohne]

Hi Antonio,

Thank you for correcting my analysis. It would have taken me quite a
while to figure that out without your explanation.

On Mon, Feb 18, 2019 at 10:01:00PM +0100, Antonio Terceiro wrote:
> I have downloaded the lighttpd source here, and read all the tests. All
> of them to start lighttpd directly, and at least the first test requires
> being run as root; Tests that need to run as root need to say so in the
> control file; salsa-ci runs stuff as root already, and that's why it
> doesn't fail there.

Indeed, the idea was to not run them as root where avoidable to make it
easier to run tests on developer systems.

> In fact, just adding `Restrictions: needs-root` makes the test pass again.
> Just tested this here.

After your explanation, that makes very much sense and we will change
that. Again thank you for going in depth.

> By the way, since all the tests are starting lighttpd directly means
> that the service definitions and the init integration is not being
> tested being "the service starts" (because the package installation, and
> therefore autopkgtest, would fail if that fails). Also, note that when
> you start lighttpd directly in your script, there will be another
> instance -- the one started by the init system -- running in the
> background.

Oh, testing the system-wide lighttpd service is a good idea. We should
fix that indeed.

As for conflicts with other instances, that part has been avoided:
* The invocations with -tt only check the configuration and do not open
  a port.
* The invocations without -tt deliberately use a different port to avoid
  the situation you describe.

Therefore I'm inclined to only add needs-root to the failing defconfig
tests. I do expect the others to pass unprivileged. And now I'm
confident that ci.d.n will tell me when they don't.

Thank you for the awesome service. Even the very limited autopktests
that lighttpd has now have revealed quite a number of problems. The
"just works" experience is great.

Helmut

Bug#919928: htslib breaks python-pysam autopkgtest

[Andreas Tille]

Hi Michael,

guessing from the timing I think this failure is caused by


htslib (1.9-10) unstable; urgency=medium

  * Bring the libdeflate, GCS, and S3 updates back to unstable.

 -- Michael R. Crusoe   Wed, 16 Jan 2019 05:23:22 
-0800


Since I have no idea about your latest changes I'm tempted to simply
revert to

   htslib (1.9-9) unstable; urgency=medium

(or if test keps on failing

   htslib (1.9-8) unstable; urgency=medium

I'll do so if I will not hear from you in 24hours since lots of our packages
now got a testing removal warning.

Kind regards

 Andreas.

On Mon, Feb 18, 2019 at 08:13:40PM +0100, Paul Gevers wrote:
> Control: severity -1 serious
> 
> On Sun, 20 Jan 2019 19:49:38 +0100 Paul Gevers  wrote:
> > With a recent upload of htslib the autopkgtest of python-pysam fails in
> > testing when that autopkgtest is run with the binary packages of htslib
> > from unstable. It passes when run with only packages from testing. In
> > tabular form:
> >passfail
> > htslib from testing1.9-10
> > python-pysam   from testing0.15.1+ds-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 of htslib 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.
> 
> Since February 12, this is now officially blocking htslib from
> migrating. This bug should be fixed either direction: or htslib fixes
> the regression it causes in python-pysam, or python-pysam fixes its
> autopkgtest to adapt to the new situation. Please agree which package
> should be fixed and reassign it to that package, keeping the version
> information.
> 
> Paul
> 




> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Bug#922501: ERROR: No runner implements step with keys grub, root-part, device, console, root-fs

[Martin Pitt]

Hello Antonio,

Antonio Terceiro [2019-02-18 22:44 -0300]:
> The vmdb2 usage changed brutally, and broke the specification file
> produced by autopkgtest-build-qemu. I don't think this can't really be
> fixed in vmdb2 at this point, not only because this makes the
> specification format a lot better.
> 
> I have just fixed this in the autopkgtest side, so I am taking the
> liberty of reassigning this to autopkgtest.

Thanks! Indeed the build works now, but the image still doesn't boot. But I'll
file a new bug for that.

Martin


signature.asc
Description: PGP signature

Bug#922671: autopkgtest-build-qemu image does not boot due to wrong root device

[Martin Pitt]

Package: autopkgtest
Version: 5.9

Even after fixing #916407 and #922501, these images still don't work:

  # autopkgtest-build-qemu stretch /tmp/s.img http://ftp.de.debian.org/debian

This succeeds, and gives me an image. But trying to boot it fails:

|   Booting a command list
| 
| Loading Linux 4.9.0-8-amd64 ...
| Loading initial ramdisk ...
| Loading, please wait...
| starting version 232
| Begin: Loading essential drivers ... done.
| Begin: Running /scripts/init-premount ... done.
| Begin: Mounting root file system ... Begin: Running /scripts/local-top ... 
done.
| Begin: Running /scripts/local-premount ... done.
| Begin: Waiting for root file system ... Begin: Running /scripts/local-block 
... done.
| Begin: Running /scripts/local-block ... done.
|  [ same line two dozen times ... ]
| done.
| Gave up waiting for root file system device.  Common problems:
|  - Boot args (cat /proc/cmdline)
|- Check rootdelay= (did the system wait long enough?)
|  - Missing modules (cat /proc/modules; ls /dev)
| ALERT!  /dev/mapper/loop0p1 does not exist.  Dropping to a shell!
| 
| 
| BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
| Enter 'help' for a list of built-in commands.
| 
| (initramfs)

Indeed the root device is wrong, it looks like it's the one from the image 
construction:

| (initramfs) cat /proc/cmdline
| BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-amd64 root=/dev/mapper/loop0p1 ro 
biosdevname=0 net.ifnames=0 consoleblank=0 systemd.show_status=true rw 
systemd.show_status=fals0

It should instead be this one:

| (initramfs) blkid
| /dev/vda1: UUID="3d31e165-ebd4-4237-8991-d0c39245c0f8" TYPE="ext4" 
PARTUUID="530a85ca-01"

If I change root= in the Grub boot menu, it boots fine. However, fstab is also
wrong:

| # cat /etc/fstab
| /dev/sda1 / ext4 errors=remount-ro 0 1

There is no sda1, this is virtio and thus it's vda1. It really should not rely
on a device name, but use an UUID.

Not sure if that's a bug in vmdb2 or our control file, though?

Thanks,

Martin

Bug#915407: what's with logind?

[Martin Pitt]

Control: tag -1 pending

Hello Adam,

Adam Borowski [2019-02-18 22:50 +0100]:
> You just made an upload of src:systemd, without the fix for libpam-systemd
> alternative.

Right, sorry  for the bad timing. This was an urgent embargoed security fix.

Last time I looked at this, the new package names weren't yet acked by policy.
But I just saw that this did happen last Friday, so this can now go ahead.

Pushed: https://salsa.debian.org/systemd-team/systemd/commit/aeb2083932812

Thanks,

Martin

Bug#922670: RM: libssreflect-ocaml -- NBS; no longer build by source ssreflect

[Ralf Treinen]

Package: ftp.debian.org
Severity: normal

Hi,

please remove binary packages

libssreflect-ocaml
libssreflect-ocaml-dev 

from all arches as these two are no longer built from source ssreflect 
since 1.7.0+dfsg-1. This blocks migration of the cluster coq, why3, 
ssreflect and aac-tactics.

Thanks -Ralf.

Bug#921913: locales: character map file `C' not found: No such file or directory

[Harald Dunkel]

Metoo.

Hopefully this is not too difficult to fix before Buster?


Regards
Harri

Bug#922662: xboxdrv: does not create a systemd service

[Andrey Rahmatullin]

On Mon, Feb 18, 2019 at 11:45:22PM -0300, Nacho wrote:
> After installing xboxdrv, there is no 'xboxdrv.service' file created and I 
> can't pair my wireless X360 controller to the receiver.
FYI you don't need xboxdrv to use the controller.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ansgar]

Steve McIntyre writes:
> There is a deeper worry about builds that may be done against the
> "weak" background. Although buildd chroots are easily fixed up,
> there's going to be a (small, but unknown) set of maintainers who
> might be uploading binaries from merged systems. I think we're making
> good progress on source-only uploads and building in clean chroots
> etc., but...  It's also likely not easy to pick up on "wrong" binary
> packages built this way.

That is not a new problem: maintainers can already upload packages that
refer to binaries in /usr/local/bin when they have locally installed
binaries and autodetection using $PATH is used?  /usr/local/bin is
usually before /usr/bin and /bin after all.

dpkg could add a "not-built-in-a-clean-chroot" flag to detect those.

Ansgar

Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548

[Salvatore Bonaccorso]

Source: sqlalchemy
Version: 1.2.15+ds1-1
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for sqlalchemy.

CVE-2019-7164[0]:
| SQL Injection when the order_by parameter can be controlled

CVE-2019-7548[1]:
| SQLAlchemy 1.2.17 has SQL Injection when the group_by parameter can be
| controlled.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-7164
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7164
[1] https://security-tracker.debian.org/tracker/CVE-2019-7548
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7548

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#896468: [Pkg-javascript-devel] Bug#896468: Bug#896468: Bug#896468: libjs-chartjs: Please upload newer versions

[Pirate Praveen]

On Tue, Feb 19, 2019 at 1:55 AM, Paul Gevers  wrote:

Hi Pirate,

On 17-02-2019 11:51, Pirate Praveen wrote:

 Thanks Paul for testing. The missing dependencies were treated as
 external dependencies by rollup (webpack would give an error), would
 have worked in node, but not in browser. I embedded the missing
 dependencies and also used rollup-plugin-node-resolve to include all
 dependencies in the bundle. So please test 2.7.3+dfsg-2 and confirm 
if
 it is working as expected (for gitlab, I still don't use the 
packaged

 version, so can't really test now).

 I can now see 'function getRgba(string) {' in the built bundle.

 Also the file looks quite different, but I guess that is to be 
expected

 due to build system differences.


 As long as it is working as expected, the exact match is not 
required.

 Each build tool has their on signature styles for bundling.


I went ahead and uploaded your version to my PPA for Ubuntu/Cosmic as
there are multiple people tracking Cacti from there (so it could be
tested). However, it FTBFS with the message below. I expect this is a
versioned dependency issue. Do you happen to know which one or how to
debug it?



rollup itself is an older revision there with unfixed bugs (rollup 
0.50.0-1build1 vs 0.50.0-6). And possibly all rollup plugins are older 
too.



Paul

https://launchpadlibrarian.net/411721887/buildlog_ubuntu-cosmic-amd64.node-chart.js_2.7.3+dfsg-2~ppa1c_BUILDING.txt.gz

rollup  -c debian/rollup.config.js
[!] TypeError: Cannot read property 'declarations' of undefined
TypeError: Cannot read property 'declarations' of undefined
at loop (/usr/lib/nodejs/rollup/dist/rollup.js:2532:26)
at Node.render (/usr/lib/nodejs/rollup/dist/rollup.js:2583:59)
at Module.render (/usr/lib/nodejs/rollup/dist/rollup.js:3187:9)
at orderedModules.forEach.module
(/usr/lib/nodejs/rollup/dist/rollup.js:4883:25)
at Array.forEach ()
at Promise.resolve.then 
(/usr/lib/nodejs/rollup/dist/rollup.js:4882:24)

at 
at process._tickCallback (internal/process/next_tick.js:188:7)
at Function.Module.runMain (module.js:695:11)
at startup (bootstrap_node.js:191:16)

make[1]: *** [debian/rules:8: override_dh_auto_build] Error 1

--
Pkg-javascript-devel mailing list
pkg-javascript-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#922608: Info received (Bug#922608: Acknowledgement (modem-manager-gui aborts to start after modemmanager is upgraded to 1.10.0-1))

[Persmule]

This bug has already been reported to upstream via
https://linuxonly.ru/forum/modem-manager-gui/57/cannot-load-modem-manager-gui-arch-linux-lts-i3wm/#post-241

Bug#922668: tests-control: Missing restrictions superficial and skippable

[Xavier Guimard]

Package: libconfig-model-dpkg-perl
Version: 2.121
Severity: minor
Tags: patch

Hello,

2 restrictions are missing in
lib/Config/Model/models/Dpkg/Tests/Control.pl:
 - superficial
 - skippable

I fixed that in salsa repo.

Cheers,
Xavier

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

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

Versions of packages libconfig-model-dpkg-perl depends on:
ii  libapt-pkg-perl0.1.34+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
pn  libmodule-corelist-perl
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-1
ii  libyaml-perl   1.27-1
ii  licensecheck   3.0.31-3
ii  lintian2.7.0
ii  perl   5.28.1-4

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file 
/usr/share/perl5/Config/Model/models/Dpkg/Tests/Control.pl (from 
libconfig-model-dpkg-perl package)

Bug#922499: spamassassin: sa-update fails with error "Cannot open file ..."

[Noah Meyerhans]

Control: tags -1 + upstream fixed-upstream
Control: forwarded -1 https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7418

> After the latest Debian upgrade yesterday evening, sa-update fails
> with error:
> 
> Cannot open file 
> /var/lib/spamassassin/3.004002/updates_spamassassin_org/1853687.tar.gz.asc: 
> No such file or directory at /usr/bin/sa-update line 1600.
> 
> I've attached the cron output.

It sounds like this is a regression introduced upstream in 3.4.2. The
fix was committed very soon after 3.4.2 was released, but there hasn't
been a subsequent release. The issue appears to be that sa-update's
retry mechanism is completely broken in 3.4.2, and if an update mirror
is unreachable or does not properly publish the update content, then the
update fails completely. The expected behavior is that sa-update retries
the download from a different update server until it finds one that
isn't broken. (Of course, if they're all broken, then the update still
fails, but that's another story.)

I believe that the fix from
https://svn.apache.org/viewvc/spamassassin/branches/3.4/sa-update.raw?r1=1842326=1842325=1842326
should be sufficient and easily backportable.

noah



signature.asc
Description: PGP signature

Bug#922667: beep: Error: could not open any device

[jim_p]

Package: beep
Version: 1.4.3-1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

After today's upgrade to version 1.4.x, beep no longer works and pops the above
error. After checking its man page, I found out that it tries to access these
devices, in that specific order

/dev/input/by-path/platform-pcspkr-event-spkr
/dev/tty0
/dev/vc/0

and although I have the 1st one (the pc speaker), beep does not seem to be able
to access it.
If I am correct. from the new developer's page in github, I found out that
there is this udev rule that needs to be present.

https://github.com/spkr-beep/beep/blob/master/90-pcspkr-beep.rules

If so, please add the above udev rule to your package.



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

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

Versions of packages beep depends on:
ii  libc6  2.28-6

beep recommends no packages.

beep suggests no packages.

-- no debconf information

Bug#922666: linux-image-4.19.0-2-amd64: Trackpad and trackpoint stop working after suspend

[Tollef Fog Heen]

Package: src:linux
Version: 4.19.16-1
Severity: normal

After resuming from a suspend, the trackpoint and trackpad on my
Thinkpad X1 carbon stops working.  If I poke the touchpad, I get a
series of:

[ 7192.255201] psmouse serio1: synaptics: queried max coordinates: x [..5678], 
y [..4758]
[ 7192.291304] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1094..]
[ 7192.938759] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[ 7192.943708] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[ 7192.944854] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[ 7192.952492] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[ 7192.955009] psmouse serio1: TouchPad at isa0060/serio1/input0 lost sync at 
byte 1
[ 7192.955011] psmouse serio1: issuing reconnect request

in the kernel log, and it eventually recovers, but only the trackpad.

When it recovers, the X log also looks like it sees the trackpoint, but
fails to enable it:

kernel: psmouse serio2: Failed to reset mouse on synaptics-pt/serio0: -5
kernel: psmouse serio2: trackpoint: Elan TrackPoint firmware: 0x06, buttons: 3/3
kernel: input: TPPS/2 Elan TrackPoint as 
/devices/platform/i8042/serio1/serio2/input/input39
/usr/lib/gdm3/gdm-x-session[1912]: (II) config/udev: Adding input device TPPS/2 
Elan TrackPoint (/dev/input/mouse1)
/usr/lib/gdm3/gdm-x-session[1912]: (II) No input driver specified, ignoring 
this device.
/usr/lib/gdm3/gdm-x-session[1912]: (II) This device may have been added with 
another device file.
/usr/lib/gdm3/gdm-x-session[1912]: (II) config/udev: Adding input device TPPS/2 
Elan TrackPoint (/dev/input/event6)
/usr/lib/gdm3/gdm-x-session[1912]: (**) TPPS/2 Elan TrackPoint: Applying 
InputClass "libinput pointer catchall"
/usr/lib/gdm3/gdm-x-session[1912]: (II) Using input driver 'libinput' for 
'TPPS/2 Elan TrackPoint'
/usr/lib/gdm3/gdm-x-session[1912]: (II) systemd-logind: got fd for 
/dev/input/event6 13:70 fd 65 paused 0
/usr/lib/gdm3/gdm-x-session[1912]: (**) TPPS/2 Elan TrackPoint: always reports 
core events
/usr/lib/gdm3/gdm-x-session[1912]: (**) Option "Device" "/dev/input/event6"
/usr/lib/gdm3/gdm-x-session[1912]: (**) Option "_source" "server/udev"
/usr/lib/gdm3/gdm-x-session[1912]: (II) event6  - TPPS/2 Elan TrackPoint: is 
tagged by udev as: Mouse Pointingstick
/usr/lib/gdm3/gdm-x-session[1912]: (II) event6  - TPPS/2 Elan TrackPoint: 
device is a pointer
/usr/lib/gdm3/gdm-x-session[1912]: (II) event6  - TPPS/2 Elan TrackPoint: 
device removed
/usr/lib/gdm3/gdm-x-session[1912]: (**) Option "config_info" 
"udev:/sys/devices/platform/i8042/serio1/serio2/input/input39/event6"
/usr/lib/gdm3/gdm-x-session[1912]: (II) XINPUT: Adding extended input device 
"TPPS/2 Elan TrackPoint" (type: MOUSE, id 12)
/usr/lib/gdm3/gdm-x-session[1912]: (**) Option "AccelerationScheme" "none"
/usr/lib/gdm3/gdm-x-session[1912]: (**) TPPS/2 Elan TrackPoint: (accel) 
selected scheme none/0
/usr/lib/gdm3/gdm-x-session[1912]: (**) TPPS/2 Elan TrackPoint: (accel) 
acceleration factor: 2.000
/usr/lib/gdm3/gdm-x-session[1912]: (**) TPPS/2 Elan TrackPoint: (accel) 
acceleration threshold: 4
/usr/lib/gdm3/gdm-x-session[1912]: (II) event6  - TPPS/2 Elan TrackPoint: is 
tagged by udev as: Mouse Pointingstick
/usr/lib/gdm3/gdm-x-session[1912]: (II) event6  - TPPS/2 Elan TrackPoint: 
device is a pointer
kernel: psmouse serio2: Failed to enable mouse on synaptics-pt/serio0

-- Package-specific info:
** Version:
Linux version 4.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-2-amd64 root=XX ro quiet

** Not tainted

** Kernel log:
[ 7165.484129] ACPI: EC: event unblocked
[ 7165.493854] usb 2-3: Disable of device-initiated U1 failed.
[ 7165.497423] usb 2-3: Disable of device-initiated U2 failed.
[ 7165.693314] usb 2-3: reset SuperSpeed Gen 1 USB device number 2 using 
xhci_hcd
[ 7165.704255] nvme nvme0: Shutdown timeout set to 8 seconds
[ 7165.840839] usb 1-7: reset full-speed USB device number 2 using xhci_hcd
[ 7166.116898] usb 1-8: reset high-speed USB device number 3 using xhci_hcd
[ 7166.265875] psmouse serio1: synaptics: queried max coordinates: x [..5678], 
y [..4758]
[ 7166.298361] psmouse serio1: synaptics: queried min coordinates: x [1266..], 
y [1094..]
[ 7166.392922] usb 1-9: reset full-speed USB device number 4 using xhci_hcd
[ 7166.545366] thunderbolt :07:00.0: control channel starting...
[ 7166.545370] thunderbolt :07:00.0: starting TX ring 0
[ 7166.545380] thunderbolt :07:00.0: enabling interrupt at register 0x38200 
bit 0 (0x0 -> 0x1)
[ 7166.545383] thunderbolt :07:00.0: starting RX ring 0
[ 7166.545393] thunderbolt :07:00.0: enabling interrupt at register 0x38200 
bit 12 (0x1 -> 0x1001)
[ 7166.554457] acpi LNXPOWER:01: Turning OFF
[ 7166.554907] OOM killer enabled.
[ 7166.554908] Restarting tasks ... 
[ 7166.555332] 

Bug#922645: netcdf-fortran: Please change build-depends to gfortran | fortran-compiler

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 2/18/19 9:14 PM, Alastair McKinstry wrote:
> Please change the build-depends from "gfortran" to "gfortran | 
> fortran-compiler".

Committed in git.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#922665: general: Intel 8265 wifi failed to be work and be recognised after update and reboot

[DebianUserSKC]

Package: general
Severity: important

Dear Maintainer,

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

   * After these updates: Start-Date: 2019-02-18  12:20:28
Commandline: apt-get dist-upgrade
Upgrade: ca-certificates-java:amd64 (20170531+nmu1, 20170929~deb9u1),
libcups2:amd64 (2.2.1-8+deb9u2, 2.2.1-8+deb9u3), python-samba:amd64
(2:4.5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1), linux-libc-dev:amd64 (4.9.130-2,
4.9.144-3), gnupg-agent:
amd64 (2.1.18-8~deb9u3, 2.1.18-8~deb9u4), libxapian30:amd64 (1.4.3-2+deb9u2,
1.4.3-2+deb9u3), libc6-dev:amd64 (2.24-11+deb9u3, 2.24-11+deb9u4),
libwbclient0:amd64 (2:4.5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1), python-
dnspython:amd64 (1.15.0-1
, 1.15.0-1+deb9u1), rtkit:amd64 (0.11-4+b1, 0.11-4+deb9u1), samba:amd64
(2:4.5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1), samba-dsdb-modules:amd64
(2:4.5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1), libsox2:amd64 (14.4.1-5+b2,
14.4.1-5+deb9u1), libc6:amd
64 (2.24-11+deb9u3, 2.24-11+deb9u4), locales:amd64 (2.24-11+deb9u3,
2.24-11+deb9u4), cups-server-common:amd64 (2.2.1-8+deb9u2, 2.2.1-8+deb9u3),
linux-compiler-gcc-6-x86:amd64 (4.9.130-2, 4.9.144-3), cups-common:amd64
(2.2.1-8+deb9u2, 2.2.
1-8+deb9u3), libsox-fmt-alsa:amd64 (14.4.1-5+b2, 14.4.1-5+deb9u1), libpq5:amd64
(9.6.10-0+deb9u1, 9.6.11-0+deb9u1), libgpod4:amd64 (0.8.3-8.2,
0.8.3-8.2+deb9u1), libwayland-client0:amd64 (1.12.0-1, 1.12.0-1+deb9u1), samba-
libs:amd64 (2:4.
5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1), libc-l10n:amd64 (2.24-11+deb9u3,
2.24-11+deb9u4), libc-bin:amd64 (2.24-11+deb9u3, 2.24-11+deb9u4), cups-
ppdc:amd64 (2.2.1-8+deb9u2, 2.2.1-8+deb9u3), libcupsmime1:amd64
(2.2.1-8+deb9u2, 2.2.1-8+deb9u3)
, sox:amd64 (14.4.1-5+b2, 14.4.1-5+deb9u1), libgpod-common:amd64 (0.8.3-8.2,
0.8.3-8.2+deb9u1), samba-common:amd64 (2:4.5.12+dfsg-2+deb9u4,
2:4.5.16+dfsg-1), linux-headers-4.9.0-8-amd64:amd64 (4.9.130-2, 4.9.144-3),
gpgv:amd64 (2.1.18-8~d
eb9u3, 2.1.18-8~deb9u4), samba-vfs-modules:amd64 (2:4.5.12+dfsg-2+deb9u4,
2:4.5.16+dfsg-1), linux-kbuild-4.9:amd64 (4.9.130-2, 4.9.144-3), linux-
headers-4.9.0-8-common:amd64 (4.9.130-2, 4.9.144-3), libssh-gcrypt-4:amd64
(0.7.3-2+deb9u1, 0
.7.3-2+deb9u2), libsmbclient:amd64 (2:4.5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1),
samba-common-bin:amd64 (2:4.5.12+dfsg-2+deb9u4, 2:4.5.16+dfsg-1), libc-dev-
bin:amd64 (2.24-11+deb9u3, 2.24-11+deb9u4), libcupsppdc1:amd64 (2.2.1-8+deb9u2,
2.2.1
-8+deb9u3), multiarch-support:amd64 (2.24-11+deb9u3, 2.24-11+deb9u4), firefox-
esr-l10n-zh-tw:amd64 (60.5.0esr-1~deb9u1, 60.5.1esr-1~deb9u1),
libibus-1.0-5:amd64 (1.5.14-3, 1.5.14-3+deb9u1), cups-bsd:amd64
(2.2.1-8+deb9u2, 2.2.1-8+deb9u3), cups-core-drivers:amd64 (2.2.1-8+deb9u2,
2.2.1-8+deb9u3), cups-daemon:amd64 (2.2.1-8+deb9u2, 2.2.1-8+deb9u3), libsox-
fmt-base:amd64 (14.4.1-5+b2, 14.4.1-5+deb9u1), gnupg:amd64 (2.1.18-8~deb9u3,
2.1.18-8~deb9u4), linux-image-4.9.0-8-amd64:amd64 (4.9.130-2, 4.9.144-3),
libcupsimage2:amd64 (2.2.1-8+deb9u2, 2.2.1-8+deb9u3), cups:amd64
(2.2.1-8+deb9u2, 2.2.1-8+deb9u3), libcupscgi1:amd64 (2.2.1-8+deb9u2,
2.2.1-8+deb9u3), cups-client:amd64 (2.2.1-8+deb9u2, 2.2.1-8+deb9u3),
libwayland-server0:amd64 (1.12.0-1, 1.12.0-1+deb9u1), firefox-esr:amd64
(60.5.0esr-1~deb9u1, 60.5.1esr-1~deb9u1), base-files:amd64 (9.9+deb9u7,
9.9+deb9u8), libwayland-cursor0:amd64 (1.12.0-1, 1.12.0-1+deb9u1)
End-Date: 2019-02-18  12:22:10

and reboot, wifi failed.  Wifi module is intel 8265.  lshw failed to recognize
the wifi module.  However bluetooth(bundled with the wifi) worked well.

 *Unplugged and pluged wifi module again - didn't work
 *update wifi firmware to firmware-iwlwifi_20190114-1_all.deb - didn't work
 *update this firmware to firmware-intel-sound_20190114-1_all.deb - OK wifi
works again.  However, I don't know why. This is FYI in case other users face
the same issue.

Thanx

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



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores)
Locale: LANG=zh_HK.utf8, LC_CTYPE=zh_HK.utf8 (charmap=UTF-8), 
LANGUAGE=zh_HK:zh_TW:zh (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#922500: luatex and broken locales

[Norbert Preining]

Hi Luigi,

here on Debian we got a bug report that luatex cannot build formats
under a broken locale. I can reproduce this on standard TeX Live, too:
$ LC_TIME=en_DE.UTF-8 luatex -ini   -jobname=luatex -progname=luatex 
luatex.ini
Unable to read environment locale: exit now.
$
(same on dev version)

It comes from the code of luainit
env_locale = setlocale (LC_ALL, "");
if (!env_locale && !lua_only) {
fprintf(stderr,"Unable to read environment locale: exit now.\n");
exit(1);
}

I agree that the locale is completely broken, and the system does not
support this locale.

BUT it would be nice if luatex would not crash on such a setup, at least
during format build?

WDYT?

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#922664: unixcw FTCBFS: moc: could not find a Qt installation of ''

[Helmut Grohne]

Source: unixcw
Version: 3.5.1-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

unixcw fails to cross build from source:

moc: could not find a Qt installation of ''

This is due to unixcw not selecting a qt version. The relevant moc
invocation lacks a version, QT_SELECT is not exported and qt5-default is
not in Build-Depends. Thus moc doesn't know which moc to use. I'm not
sure why this isn't a problem for native builds.

Since packages must not depend on qt5-default, the attached patch opts
for exporting QT_SELECT, which fixes the build. Please consider applying
the attached patch.

Helmut
diff --minimal -Nru unixcw-3.5.1/debian/changelog unixcw-3.5.1/debian/changelog
--- unixcw-3.5.1/debian/changelog   2017-07-24 14:15:48.0 +0200
+++ unixcw-3.5.1/debian/changelog   2019-02-19 05:41:42.0 +0100
@@ -1,3 +1,10 @@
+unixcw (3.5.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Select a qt version. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 19 Feb 2019 05:41:42 +0100
+
 unixcw (3.5.1-2) unstable; urgency=medium
 
   * Fix watch file
diff --minimal -Nru unixcw-3.5.1/debian/rules unixcw-3.5.1/debian/rules
--- unixcw-3.5.1/debian/rules   2014-06-25 11:42:26.0 +0200
+++ unixcw-3.5.1/debian/rules   2019-02-19 05:41:42.0 +0100
@@ -15,6 +15,7 @@
 
 # This has to be exported to make some magic below work.
 export DH_OPTIONS
+export QT_SELECT=qt5
 
 # These are used for cross-compiling and for saving the configure script
 # from having to guess our platform (since we know it already)

Bug#575204: initscripts: grep complains about invalid back reference in umountfs

[Pierre Ynard]

> Probably we could just pass -F option to grep?

grep -F would seem a lot safer in many places, yes.

> By the way, could someone please explain what does this sed command
> mean?

> sed -n ':a;/^[^ ]* \/ /!{H;n;ba};{H;s/.*//;x;s/\n//;p}'

It is my understanding that it copies into sed's clipboard every mount
line that isn't mounted on "/", until it finds one that is, and then it
pastes from the clipboard and outputs all those previous lines and the
current one. In effect, that would only remove all the lines after the
last line mounted on "/".

-- 
Pierre Ynard

Bug#922660: vmdb2: minimal specification file does not really work

[Gunnar Wolf]

tags 922660 + upstream pending
thanks

Bug#922660: vmdb2: minimal specification file does not really work

[Gunnar Wolf]

Antonio Terceiro dijo [Mon, Feb 18, 2019 at 10:40:45PM -0300]:
> Package: vmdb2
> Version: 0.13.2+git20190215-1
> Severity: normal
> Tags: patch
> 
> The minimal example provided in the documentation doesn't really work.
> The attached changes it to something that does (still, you can't login
> to the VM, but that's another story).

Thanks Terceiro!

I have forwarded this bug+patch to Lars, I am quite certain he will
incorporate your fixes upstream.

Thanks!


signature.asc
Description: PGP signature

Bug#922501: ERROR: No runner implements step with keys grub, root-part, device, console, root-fs

[Gunnar Wolf]

Antonio Terceiro dijo [Mon, Feb 18, 2019 at 10:44:39PM -0300]:
> The vmdb2 usage changed brutally, and broke the specification file
> produced by autopkgtest-build-qemu. I don't think this can't really be
> fixed in vmdb2 at this point, not only because this makes the
> specification format a lot better.
> 
> I have just fixed this in the autopkgtest side, so I am taking the
> liberty of reassigning this to autopkgtest.

Thanks for following up with this so quickly!


signature.asc
Description: PGP signature

Bug#922663: [libdbus-glib-1-2] glib sends unexpected SIGTERM to hexchat

[Synthea]

Package: libdbus-glib-1-2
Version: 0.108-2
Severity: important

Hexchat seems to receive an unexpected sigterm from glib, according to
the dev who has overseen the bugreport at https://bugs.debian.org/cgi-b
in/bugreport.cgi?bug=922273
This is what dbus-monitor printed during the event:
signal time=1550549244.381990 sender=org.freedesktop.DBus ->
destination=:1.107 serial=5 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameLost
   string ":1.107"
signal time=1550549244.382427 sender=org.freedesktop.DBus ->
destination=(null destination) serial=9 path=/org/freedesktop/DBus;
interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.107"
   string ":1.107"
   string ""

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-5-amd64

Debian Release: 9.8
  500 stable-updates  deb.debian.org 
  500 stable  security.debian.org 
  500 stable  repo.skype.com 
  500 stable  dl.google.com 
  500 stable  deb.debian.org 
  500 newstable   deb.i2p2.de 
  100 stretch-backports deb.debian.org 

--- Package information. ---
Depends(Version) | Installed
-+-
libc6  (>= 2.14) | 
libdbus-1-3  (>= 1.9.14) | 
libglib2.0-0 (>= 2.31.8) | 


Package's Recommends field is empty.

Package's Suggests field is empty.




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

Bug#727022: Debian Wheezy didn't shut down. Had to use hard shut down.

[Pierre Ynard]

> Debian wheezy didn't shut down, when I shut it down. It got stuck in
> some dhcprelease process. I had to use hard reset to shut it down. I
> have seen this problem more than once. I have attached a screenshot.
> Please see, if it is a know issue.

I would tend to think that it's the responsibility of the
/etc/init.d/networking script to make sure it doesn't hang. Should this
be reassigned to ifupdown so they get a chance to look at it?

-- 
Pierre Ynard

Bug#761511: misleading message about mount points in /etc/fstab

[Pierre Ynard]

> Seems so. This string is still present. I will take a look why it is
> there, and under what circumstances this suggestion is printed.

This message can be wrongly printed because of at least #818442
(read-only /dev). In fact it gets printed only if `rm -fr /dev/shm`
fails, and there aren't too many possible causes for that apart from
genuine mount mishaps and #818442, so it might just be a variation of
it, involving some NFS code path apparently.

-- 
Pierre Ynard

Bug#922608: Acknowledgement (modem-manager-gui aborts to start after modemmanager is upgraded to 1.10.0-1)

[persmule]

With further examination, I notice that this bug only occurs when a
modem with 3gpp location capability is installed, and locate the bug at
src/modules/mm07.c (the same bug also exist in mm06.c). If (the context
could be located with the attached patch) the modem has 3gpp location
capability (otherwise, locationstring is NULL and the bug is not
triggered), locationstring will be a g_free()able pointer returned by
g_strdep(), but strsep() modifies its value, effectively making
locationstring never a g_free()able pointer anymore, and g_free()ing it
causes the program aborted.

This bug should be fixed with the attached patch.

diff -Nrup modem-manager-gui-0.0.19.1/src/modules/mm06.c modem-manager-gui-0.0.19.1.fix/src/modules/mm06.c
--- modem-manager-gui-0.0.19.1/src/modules/mm06.c	2018-04-06 22:43:09.0 +0800
+++ modem-manager-gui-0.0.19.1.fix/src/modules/mm06.c	2019-02-19 10:56:32.419076874 +0800
@@ -1581,10 +1581,11 @@ static gboolean mmgui_module_devices_upd
 //3GPP location
 strlength = 256;
 locationstring = g_strdup(g_variant_get_string(locationdata, ));
-device->loc3gppdata[0] = (guint)strtol(strsep(, ","), NULL, 10);
-device->loc3gppdata[1] = (guint)strtol(strsep(, ","), NULL, 10);
-device->loc3gppdata[2] = (guint)strtol(strsep(, ","), NULL, 16);
-device->loc3gppdata[3] = (guint)strtol(strsep(, ","), NULL, 16);
+gchar* finger = locationstring;
+device->loc3gppdata[0] = (guint)strtol(strsep(, ","), NULL, 10);
+device->loc3gppdata[1] = (guint)strtol(strsep(, ","), NULL, 10);
+device->loc3gppdata[2] = (guint)strtol(strsep(, ","), NULL, 16);
+device->loc3gppdata[3] = (guint)strtol(strsep(, ","), NULL, 16);
 g_free(locationstring);
 g_variant_unref(locationdata);
 g_debug("3GPP location: %u, %u, %4x, %4x", device->loc3gppdata[0], device->loc3gppdata[1], device->loc3gppdata[2], device->loc3gppdata[3]);
diff -Nrup modem-manager-gui-0.0.19.1/src/modules/mm07.c modem-manager-gui-0.0.19.1.fix/src/modules/mm07.c
--- modem-manager-gui-0.0.19.1/src/modules/mm07.c	2018-04-06 22:43:09.0 +0800
+++ modem-manager-gui-0.0.19.1.fix/src/modules/mm07.c	2019-02-19 10:56:32.419076874 +0800
@@ -1685,10 +1685,11 @@ static gboolean mmgui_module_devices_upd
 /*3GPP location*/
 strlength = 256;
 locationstring = g_strdup(g_variant_get_string(locationdata, ));
-device->loc3gppdata[0] = (guint)strtol(strsep(, ","), NULL, 10);
-device->loc3gppdata[1] = (guint)strtol(strsep(, ","), NULL, 10);
-device->loc3gppdata[2] = (guint)strtol(strsep(, ","), NULL, 16);
-device->loc3gppdata[3] = (guint)strtol(strsep(, ","), NULL, 16);
+gchar *finger = locationstring;
+device->loc3gppdata[0] = (guint)strtol(strsep(, ","), NULL, 10);
+device->loc3gppdata[1] = (guint)strtol(strsep(, ","), NULL, 10);
+device->loc3gppdata[2] = (guint)strtol(strsep(, ","), NULL, 16);
+device->loc3gppdata[3] = (guint)strtol(strsep(, ","), NULL, 16);
 g_free(locationstring);
 g_variant_unref(locationdata);
 g_debug("3GPP location: %u, %u, %4x, %4x\n", device->loc3gppdata[0], device->loc3gppdata[1], device->loc3gppdata[2], device->loc3gppdata[3]);

Bug#922628: ITP: dt -- DNS tool - display information about your domain

[Antoine Beaupré]

[re-adding debian-devel to avoid further duplicates...]

On 2019-02-19 03:11:47, Ben Hutchings wrote:
> This command name is very short, and in fact we already have a dt
> command (in the ditrack package).  I suggest you try to convince
> upstream to pick a unique command name.

... so for the third time today: now, I know about ditrack, thanks! :)

There were options proposed in the bug, I'm hesitating between asking
upstream to change its name (generally not well received) or renaming
ditrack, which has a low popcon and no upstream release in a decade.

A.

-- 
We must learn to live together as brothers or perish together as fools.
- Martin Luther King, Jr.

Bug#922628: ITP: dt -- DNS tool - display information about your domain

[Ben Hutchings]

On Mon, 2019-02-18 at 10:52 -0500, Antoine Beaupré wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Antoine Beaupré 
> 
> * Package name: dt
>   Version : 0.0.9
>   Upstream Author : Wim
> * URL : https://github.com/42wim/dt
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : DNS tool - display information about your domain
> 
>  dt a DNS tool that displays information about your domain.
>  .
>  Features
>  • common records scanning (use -scan)
>  • validate DNSSEC chain (use -debug to see more info)
>  • change query speed for scanning (default 10 queries per second)
>  * diagnostic of your domain (similar to intodns.com, dnsspy.io)
>  
> 
> 
> This is a great tool. I worked on packaging a similar tool (dnsdiag,
> #824670) for Debian, but it stopped where dt begun:
> 
> https://github.com/farrokhi/dnsdiag/issues/16
> 
> So I would love to see this in Debian. As usual, I would co-maintain
> this in the golang team.

This command name is very short, and in fact we already have a dt
command (in the ditrack package).  I suggest you try to convince
upstream to pick a unique command name.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
   - Bill Gates




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

Bug#816717: E: Failed to fetch file:/home/tglase/Projekte/DebTarent/dists/sid/tarent/binary-all/Packages.gz Could not open file /home/tglase/Projekte/DebTarent/dists/sid/tarent/binary-all/Packages -

[Thorsten Glaser]

found 816717 1.8.0~rc3
thanks

My home directory is 0710, but this has never prevented
a *sudo* apt-get update from accessing those files.

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

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*

Bug#870396: *sigh*…

[Thorsten Glaser]

found 870396 1.1.8-1
thanks

And again, an updated patch…

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

*

**!!! NEU !!!** Mit der **tarent Academy** bieten wir ab sofort auch Trainings
und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und
Zukunftstechnologien an. Besuchen Sie uns
auf [www.tarent.de/academy](http://www.tarent.de/academy). Wir freuen uns auf
Ihren Kontakt.

*diff -Nru alsa-lib-1.1.8/debian/changelog alsa-lib-1.1.8/debian/changelog
--- alsa-lib-1.1.8/debian/changelog 2019-01-27 20:02:43.0 +0100
+++ alsa-lib-1.1.8/debian/changelog 2019-02-18 16:53:20.0 +0100
@@ -1,3 +1,10 @@
+alsa-lib (1.1.8-1+x32.1) unreleased; urgency=high
+
+  * Non-maintainer upload.
+  * Add patches fixing sound on x32. (Closes: #870396)
+
+ -- Thorsten Glaser   Mon, 18 Feb 2019 16:53:20 +0100
+
 alsa-lib (1.1.8-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru alsa-lib-1.1.8/debian/patches/0009-fix-format-strings.patch 
alsa-lib-1.1.8/debian/patches/0009-fix-format-strings.patch
--- alsa-lib-1.1.8/debian/patches/0009-fix-format-strings.patch 1970-01-01 
01:00:00.0 +0100
+++ alsa-lib-1.1.8/debian/patches/0009-fix-format-strings.patch 2019-02-18 
16:52:26.0 +0100
@@ -0,0 +1,73 @@
+# DP: fix long vs. long long confusion when there is a 64-bit time_t
+# DP: on a 32-bit long system, such as all newer 32-bit architectures
+
+--- a/src/pcm/pcm.c
 b/src/pcm/pcm.c
+@@ -2257,11 +2257,11 @@ int snd_pcm_status_dump(snd_pcm_status_t
+ {
+   assert(status);
+   snd_output_printf(out, "  state   : %s\n", 
snd_pcm_state_name((snd_pcm_state_t) status->state));
+-  snd_output_printf(out, "  trigger_time: %ld.%06ld\n",
+-status->trigger_tstamp.tv_sec,
+-status->trigger_tstamp.tv_nsec / 1000);
+-  snd_output_printf(out, "  tstamp  : %ld.%06ld\n",
+-  status->tstamp.tv_sec, status->tstamp.tv_nsec / 1000);
++  snd_output_printf(out, "  trigger_time: %lld.%06ld\n",
++(long long)status->trigger_tstamp.tv_sec,
++(long)status->trigger_tstamp.tv_nsec / 1000L);
++  snd_output_printf(out, "  tstamp  : %lld.%06ld\n",
++  (long long)status->tstamp.tv_sec, (long)status->tstamp.tv_nsec 
/ 1000L);
+   snd_output_printf(out, "  delay   : %ld\n", (long)status->delay);
+   snd_output_printf(out, "  avail   : %ld\n", (long)status->avail);
+   snd_output_printf(out, "  avail_max   : %ld\n", 
(long)status->avail_max);
+--- a/test/latency.c
 b/test/latency.c
+@@ -325,12 +325,12 @@ void setscheduler(void)
+   printf("!!!Scheduler set to Round Robin with priority %i FAILED!!!\n", 
sched_param.sched_priority);
+ }
+ 
+-long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
++long long timediff(snd_timestamp_t t1, snd_timestamp_t t2)
+ {
+-  signed long l;
++  signed long long l;
+ 
+   t1.tv_sec -= t2.tv_sec;
+-  l = (signed long) t1.tv_usec - (signed long) t2.tv_usec;
++  l = (signed long long) t1.tv_usec - (signed long long) t2.tv_usec;
+   if (l < 0) {
+   t1.tv_sec--;
+   l = 100 + l;
+@@ -682,10 +682,10 @@ int main(int argc, char *argv[])
+   snd_pcm_nonblock(phandle, !block ? 1 : 0);
+   if (ok) {
+ #if 1
+-  printf("Playback time = %li.%i, Record time = %li.%i, 
diff = %li\n",
+- p_tstamp.tv_sec,
++  printf("Playback time = %lli.%i, Record time = %lli.%i, 
diff = %lli\n",
++ (long long)p_tstamp.tv_sec,
+  (int)p_tstamp.tv_usec,
+- c_tstamp.tv_sec,
++ (long long)c_tstamp.tv_sec,
+  (int)c_tstamp.tv_usec,
+  timediff(p_tstamp, c_tstamp));
+ #endif
+--- a/test/queue_timer.c
 b/test/queue_timer.c
+@@ -99,11 +99,11 @@ main(int argc ATTRIBUTE_UNUSED, char **a
+   normalize();
+   prevdiff = diff;
+ 
+-  fprintf(stderr, " real time: %12ld sec %8ld usec\nqueue time: %12ld sec 
%8ld usec\n  diff: %12ld sec %8ld usec\n  diffdiff: %12ld sec %8ld usec\n",
+-  tv.tv_sec, tv.tv_usec,
+-  (long)rtime->tv_sec, (long)rtime->tv_nsec / 1000,
+-  diff.tv_sec, diff.tv_usec,
+-  (long)diffdiff.tv_sec, (long)diffdiff.tv_usec);
++  fprintf(stderr, " real time: %12lld sec %8ld usec\nqueue time: %12lld 
sec %8ld usec\n  diff: %12lld sec %8ld usec\n  diffdiff: %12lld sec %8ld 
usec\n",
++  (long long)tv.tv_sec, 

Bug#922662: xboxdrv: does not create a systemd service

[Nacho]

Package: xboxdrv
Version: 0.8.8-1
Severity: normal

Dear Maintainer,

After installing xboxdrv, there is no 'xboxdrv.service' file created and I 
can't pair my wireless X360 controller to the receiver.
I don't know if this should be reported as a bug or as a wish. Both Fedora and 
Arch already provide this file when installed. (Fedora places it in 
/usr/lib/systemd/system/xboxdrv.service)
I've tried creating a systemd service but couldn't make it work.

The receiver is detected as this xboxdrv -L output shows:

 id | wid | idVendor | idProduct | Name
+-+--+---+--
  0 |   0 |   0x045e |0x0291 | Xbox 360 Wireless Receiver (XBOX) (Port: 0)
  0 |   1 |   0x045e |0x0291 | Xbox 360 Wireless Receiver (XBOX) (Port: 1)
  0 |   2 |   0x045e |0x0291 | Xbox 360 Wireless Receiver (XBOX) (Port: 2)
  0 |   3 |   0x045e |0x0291 | Xbox 360 Wireless Receiver (XBOX) (Port: 3)

If you have the time, please check it.
Thank you!!

- Nacho

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

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

Versions of packages xboxdrv depends on:
ii  libc6 2.24-11+deb9u4
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libglib2.0-0  2.50.3-2
ii  libstdc++66.3.0-18+deb9u1
ii  libudev1  232-25+deb9u9
ii  libusb-1.0-0  2:1.0.21-1
ii  libx11-6  2:1.6.4-3+deb9u1

Versions of packages xboxdrv recommends:
ii  python   2.7.13-2
ii  python-dbus  1.2.4-1+b1

xboxdrv suggests no packages.

-- no debconf information

Bug#922661: ITP: sandboxfs -- A virtual file system for sandboxing

[Julio Merino]

Package: wnpp
Severity: wishlist
Owner: Julio Merino 

* Package name: sandboxfs
  Version : 0.1.0
  Upstream Author : Julio Merino 
* URL : https://github.com/bazelbuild/sandboxfs
* License : Apache 2.0
  Programming Lang: Rust
  Description : A virtual file system for sandboxing

sandboxfs is a FUSE file system that exposes a combination of multiple
files and directories from the host's file system in the form of a virtual
tree with an arbitrary layout.  You can think of a sandbox as an arbitrary
view into the host's file system with different access privileges per
directory.

sandboxfs is designed to allow running commands with limited access to
the file system by using the virtual tree as their new root, and to do so
consistently across a variety of platforms.

--

Why is a package beneficial?

sandboxfs' primary user is Bazel which is not included in Debian.
However, I see sandboxfs as a primitive tool that should be available
with minimal fuss and therefore I think a Debian package would be very
beneficial for all Bazel users.  Being able to tell someone "just run
apt install sandboxfs" before running Bazel is much, much easier than
having to tell them how to set up the Rust toolchain, build the project,
and install it.  Plus sandboxfs has other users outside of Bazel as it
is a pretty generic FUSE file system.

How will this be maintained?

This package should be maintained as part of rust-team.  I am not yet
a Debian developer.

I am the primary developer of this software and have experience in
packaging for pkgsrc (NetBSD) and Fedora.

Bug#921953: apacheds: Further analysis

[tony mancill]

On Sun, Feb 10, 2019 at 09:25:30PM +0100, Johan Grip wrote:
> Hi.
> 
> Looked at it a bit more and found the following things.
> 
> ApacheDS have moved it's configuration to a dynamic schema based setup, like
> OpenLDAP.
> As part of the startup it tries to migrate the config.ldif to a folder based
> setup
> in ou=config. Since the user it runs as doesn't have write permission for
> /etc/apacheds
> it fails and then gives up starting.
> 
> Additionally, once the permission issue is sorted the current systemd unit
> checks for the
> existance of the config.ldif file which will be renamed as part of the
> migration so it will
> not start the server.
> 
> The patch below fixes both but I'm not sure if services are supposed to
> write in /etc.

Hi Johan,

Thank you for the analysis and the patch.  I adjusted the permissions
slightly based on [1].  I'm not completely sure that the directory
shouldn't also be world-readable given that the configuration created by
apacheds when it does start correctly is world readable anyway, but I
didn't change that.  Also, as I interpret Debian Policy 10.7.2 [2], the
files are in the desired location.

Since I'm not normally an uploader of apacheds, I'm going to give the
normal uploaders a couple days to comment before proceeding.  I am keen
on getting this RC bug addressed, since it will remove several other
packages from Debian, including zookeeper.

Cheers,
tony

[1] 
https://www.debian.org/doc/debian-policy/ch-files.html#permissions-and-owners
[2] https://www.debian.org/doc/debian-policy/ch-files.html#location


signature.asc
Description: PGP signature

Bug#922501: ERROR: No runner implements step with keys grub, root-part, device, console, root-fs

[Antonio Terceiro]

Control: reassign -1 autopkgtest

On Sun, 17 Feb 2019 09:49:41 +0100 Martin Pitt  wrote:
> Package: vmdb2
> Version: 0.13.2+git20190215-1
> 
> I'm trying to build a stretch VM image using autopkgtest's tool:
> 
>autopkgtest-build-qemu  stretch /tmp/autopkgtest-stretch-amd64.qcow2
> 
> which under the hood calls
> 
>vmdb2 --verbose --image=/tmp/autopkgtest-stretch-amd64.qcow2.raw 
> /tmp/config
> 
> I'm attaching /tmp/config here for reference (in reality it's a temporary
> random file name, of course).
> 
> This immediately fails with
> 
>   Load spec file /tmp/config
>   ERROR: No runner implements step with keys grub, root-part, device, 
> console, root-fs
> 
> This happens in a relatively small sid schroot, so there are no packages like
> grub etc. installed. I did try to install grub2, but it doesn't make a
> difference.
> 
> Apparently there are some missing dependencies/recommends here?

The vmdb2 usage changed brutally, and broke the specification file
produced by autopkgtest-build-qemu. I don't think this can't really be
fixed in vmdb2 at this point, not only because this makes the
specification format a lot better.

I have just fixed this in the autopkgtest side, so I am taking the
liberty of reassigning this to autopkgtest.


signature.asc
Description: PGP signature

Bug#922660: vmdb2: minimal specification file does not really work

[Antonio Terceiro]

Package: vmdb2
Version: 0.13.2+git20190215-1
Severity: normal
Tags: patch

The minimal example provided in the documentation doesn't really work.
The attached changes it to something that does (still, you can't login
to the VM, but that's another story).

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

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

Versions of packages vmdb2 depends on:
ii  cmdtest 0.32-3
ii  debootstrap 1.0.114
ii  kpartx  0.7.9-2
ii  parted  3.2-24
ii  python3 3.7.2-1
ii  python3-cliapp  1.20180812.1-2
ii  python3-jinja2  2.10-1
ii  python3-yaml3.13-2
ii  qemu-utils  1:3.1+dfsg-4

Versions of packages vmdb2 recommends:
ii  ansible  2.7.6+dfsg-1

vmdb2 suggests no packages.

-- no debconf information
From c0e2b8ceda068522dc29111e754d485abadb0c71 Mon Sep 17 00:00:00 2001
From: Antonio Terceiro 
Date: Mon, 18 Feb 2019 22:39:56 -0300
Subject: [PATCH] Change: make "getting started" example work

This makes the minimal example presented in the "Getting started"
section of the documentation actually produce a working VM image.
---
 vmdb2.mdwn | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/vmdb2.mdwn b/vmdb2.mdwn
index 62326b1..0deaee5 100644
--- a/vmdb2.mdwn
+++ b/vmdb2.mdwn
@@ -81,6 +81,8 @@ instructions. A minimal specification file example:
 end: 100%
 tag: root
 
+  - kpartx: "{{ output }}"
+
   - mkfs: ext4
 partition: root
 
@@ -93,10 +95,11 @@ instructions. A minimal specification file example:
   - apt: install
 packages:
   - linux-image-amd64
-tag: root-fs
+tag: root
 
   - grub: bios
 tag: root
+console: serial
 
 The above creates a four gigabyte file, creates a GPT partition table,
 a single partition, with a filesystem, and installs Debian release
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#922659: emacs-lucid: wanderlust with ssl fails without gnutls-log-level non-zero

[peterc]

Package: emacs-lucid
Version: 1:26.1+1-3.2
Severity: normal

Dear Maintainer,

Since the last apt-get upgrade, reading email with wanderlust under
emacs has become difficult.  After the initial login to the dovecot
imaps server, I see 'Cannot open: elmo-network-initialize-session' and
can't get any new email, nor can I send email.

If I do
  (setq gnutls-log-level 1)
to try to debug the problem, the connection works perfectly, and I can
read and send email.

FWIW my mail server's connection is signed with a cacert.org
certificate; the root certificates for cacert are installed locally
with
  apt-get install ca-cacert

Peter C

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

Kernel: Linux 5.0.0-rc4-1-g4aa9fc2a435a (SMP w/8 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs-lucid depends on:
ii  emacs-bin-common   1:26.1+1-3.2
ii  emacs-common   1:26.1+1-3.2
ii  libacl12.2.52-3+b1
ii  libasound2 1.1.7-2
ii  libc6  2.28-7
ii  libcairo2  1.16.0-2
ii  libdbus-1-31.12.12-1
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libgif75.1.4-3
ii  libglib2.0-0   2.58.3-1
ii  libgnutls303.6.6-2
ii  libgomp1   8.2.0-20
ii  libgpm21.20.7-5
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  liblcms2-2 2.9-3
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.10.23+dfsg-2
ii  libmagickwand-6.q16-6  8:6.9.10.23+dfsg-2
ii  libotf00.9.13-4
ii  libpng16-161.6.36-5
ii  librsvg2-2 2.44.10-1
ii  libselinux12.8-1+b1
ii  libsm6 2:1.2.3-1
ii  libsystemd0240-5
ii  libtiff5   4.0.10-4
ii  libtinfo6  6.1+20181013-1
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxft22.3.2-2
ii  libxinerama1   2:1.1.4-2
ii  libxml22.9.4+dfsg1-7+b3
ii  libxmu62:1.1.2-2
ii  libxpm41:3.5.12-1
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxt6 1:1.1.5-1
ii  xaw3dg 1.5+E-18.3
ii  zlib1g 1:1.2.11.dfsg-1

emacs-lucid recommends no packages.

Versions of packages emacs-lucid suggests:
pn  emacs-common-non-dfsg  

-- no debconf information

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Marco d'Itri]

On Feb 18, Didier 'OdyX' Raboud  wrote:

> * another use-case is to be able to share an identical `/usr` over a network
>   link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
>   over the network. It seems that an initramfs with everything needed to mount
>   a filesystem over a network link directly actually has a smaller footprint.
A MAJOR use case is to share /usr among different containers so that 
they use the same software (which then can be updated centrally) but 
different data and configurations.
It is a longer term goal of some projects to support booting new 
a system with empty /etc and /var directories, i.e. basically an empty 
/ partition and software coming from the (possibly read only, possibly 
snapshotted, etc) /usr partition.

> * booting with `/` only is not systematically tested in Debian anymore;
Nowadays this will surely to not work at all, at least in a default 
install. E.g. libkmod2 is in /usr/lib/.
I think that it can be safely said that Debian does not support booting 
systems with a standalone /usr/ and no initramfs.

> In Debian buster, the current testing suite, "merged `/usr`" is only 
> considered
> for implementation with symlinks (there are no proposals for simply dropping
> `/{bin,sbin,lib*}`) and is implemented in two main ways:
For clarity: I am not aware of anybody anywhere proposing to drop the 
/{bin,sbin,lib*} links, for Debian or any other distribution.

Thank you for this excellent summary.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Steve McIntyre]

Hi Didier,

While I'm not necessarily disagreeing with the overall point(s) here,
some of the points in this list of arguments seem dubious at
best. Maybe you could expand?

>* having separate `/` and `/usr` filesystems has been useful in the past for
>  booting without initramfs onto a minimal root filesystem that carried just
>  enough to mount the `/usr` filesystem later in the boot process. Given the
>  evolution of physical hosts' capabilities, initramfs'es have been default in
>  Debian (and elsewhere) for a long time, and most systems no longer have an
>  intermediate state during boot in which they have only `/`, but not `/usr`,
>  mounted.
>* another use-case is to be able to share an identical `/usr` over a network
>  link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
>  over the network. It seems that an initramfs with everything needed to mount
>  a filesystem over a network link directly actually has a smaller footprint.
>* booting with `/` only is not systematically tested in Debian anymore;

I'm assuming you mean "/ without /usr" here?

>* the packaging infrastructure to install files outside of `/usr` is not
>  standard and represents technical debt:

I have no idea what you're suggesting here.

>* given its status as remnant "folklore", the distinction between what _needs_
>  to be shipped in `/` and what can stay in `/usr` is often interpreted
>  arbitrarily;
>* allowing shipment of identically-named libraries or binaries in different
>  paths can confuse common understanding of paths precedence.

...

>Various valid long-term desireable situations coexist, and while discussing
>immediate countermeasures, it is useful to keep the long-term outcome that
>those are most likely to produce.
>
>These are the five possible situations at the time of bullseye (buster + 1):
>
>* `none`: "merged `/usr`" has been reverted
>* `weak`: both directory schemes are allowed, packages only built on classical
>  hosts
>* `middle`: both directory schemes are allowed, packages can be built anywhere
>* `hard`: both directory schemes are allowed, packages only built on
>  "merged `/usr`" hosts
>* `all`: only "merged `/usr`" directory schemes are allowed, packages only
>  built on "merged `/usr`" hosts
>
>It can be summarized by the following table:
>
>```
>|  | Host types that are allowed   | Are merged `/usr` | 
>Official packages are built on| Packages built on … can break on the other 
>|
>| Codename | classical hosts | merged `/usr` hosts | symlinks allowed  | 
>classical hosts | merged `/usr` hosts |   classical hosts   |  merged `/usr` 
>hosts |
>|--|-|-|---|—|-|-|--|
>| none |   yes   |  no | no|   
>yes   |  no | yes |  yes |
>| weak |   yes   | yes |yes|   
>yes   |  no |  no |  yes |
>|   middle |   yes   | yes |yes|   
>yes   | yes |  no |   no |
>| hard |   yes   | yes |yes|   
> no   | yes |  no |   no |
>|  all |   no| yes |yes|   
> no   | yes | yes |   no |
>```
>
>The current state of buster is `weak`.
>
>=== DRAFT Resolution ===
>
>The Technical Committee resolves to:
>
>* Option A: Ask the debootstrap maintainers to disable "merged `/usr`" by
>  default
>  (Using its §6.1.4 "Overrule a Developer" power; requires a 3:1 majority)
>
>  Given that:
>  * hosts with both directory schemes already exist,
>  * the "merged `/usr`" directory scheme ought to be reserved for special
>use-cases,
>  * official packages ought to only be built on classical directory schemes,
>
>  … the Technical Committee considers that the desireable solution at the time
>  of bullseye is `weak`; and asks the debootstrap maintainers to disable
>  "merged `/usr`" by default.

There is a deeper worry about builds that may be done against the
"weak" background. Although buildd chroots are easily fixed up,
there's going to be a (small, but unknown) set of maintainers who
might be uploading binaries from merged systems. I think we're making
good progress on source-only uploads and building in clean chroots
etc., but...  It's also likely not easy to pick up on "wrong" binary
packages built this way.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen

Bug#867623: heirloom-mailx is not an alternative for /usr/bin/mailx

[Adrian Zaugg]

On Thu, 20 Jul 2017 15:41:50 +0200 Steffen Nurpmeso 
wrote:
>  |Oy.  I gather, then, that s-nail cannot be an alternative unless some
>  |sort of political settlement is brokered, which may never happen.  Alas.
> 
> That was my impression at least.  Of course this MUA is still very
> restricted, so in parts i can even understand the trouble.  We are

...so why isn't heirlom-mailx not just added with a lower priority than
BSD mail? It would not disturb anyone and those who dislike mailx from
BSD mail or wherever could easily change it to heirlom-mailx. No one
ever said that an alternative must be switch compatible, I think. See
the Debian Wiki [1] where a discussion on debian-user is linked, which
talks about vim, nvi and elvis, which do not support the same key
strokes and are nevertheless alternatives.

Actually I could just state that I've used to use a dot to end the
interacive mail command since the very early nineties, which doesn't
work any more today. So what's that reasoning about a missing -a switch
compared? The same level of unimportance

Please just add it as an alternative with lower priority. If anyone
feels distracted even by such a non-invasive method, (s)he could open a
bug, I suggest and the discussion could start over.

Regards, Adrian.


[1] https://wiki.debian.org/DebianAlternatives

Bug#922597: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Hi Andreas,

Thanks for confirming. I just had no enough energy to check status for
20+ packages that FTBFS against opencv 4.0.1

As for this package ... so be it ... Unlike the pkg-config file
deprecation, the complete deprecation of opencv/cv.h header
is not what Debian maintainers can workaround. And actually I'm
very happy to see that opencv/cv.h (historical burden?) has gone.

On Mon, Feb 18, 2019 at 10:55:03AM +0100, Andreas Tille wrote:
> On Mon, Feb 18, 2019 at 06:58:13AM +, Mo Zhou wrote:
> > Source: sitplus
> > Version: 1.0.3-5.1
> > Severity: important
> > 
> > sitplus asks for a header file cv.h that has been deprecated since opencv4
> 
> Sitplus is in a very bad state anyway.  It needs packaging of libsitplus
> (which was more tricky than I intended to spent time into this for my
> personal use totally out of scope task).  So it will not be part of
> stable release anyway and may be cv.h is not needed in the new upstream
> version.  May be it would be better to remove it from Debian at all and
> see if somebody else will re-introduce it later ,..
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de

Bug#922589: FTBFS against opencv 4.0.1 (exp)

[Mo Zhou]

Hi Andreas,

Not only this package was broken by opencv4.0 due to the deprecation of
pkg-config file. If possibe, it's recommended to detect opencv using
cmake. Or maybe we can still enable this "deprecated" feature?

>  473 OCV_OPTION(OPENCV_GENERATE_PKGCONFIG  "Generate .pc file for pkg-config 
> build tool (deprecated)" OFF)

Let's wait and see how the upstreams of broken packages response...
If they still need the .pc file anyway, I think we'd better add it
back...

On Mon, Feb 18, 2019 at 10:45:59AM +0100, Andreas Tille wrote:
> Control: tags -1 help
> 
> Hi Lumin,
> 
> On Mon, Feb 18, 2019 at 06:45:55AM +, Mo Zhou wrote:
> > Source: opencfu
> > Version: 3.9.0-3
> > Severity: important
> > 
> > pkg-config file has been marked deprecated by upstream.
> 
> I admit I have no idea what to do now.  Any hint?
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de

Bug#922563: FTBFS on ppc64el

[Mo Zhou]

control: retitle -1 please disable unsupported architectures in control
control: severity -1 normal

Thanks for confirming. I didn't check the status for every package
because I have to file 20+ bugs for FTBFS against opencv 4.0.1

It seems that the SSE* requirement is mandatory, so only these
architectures make sense in control:
 
 amd64 i386 kfreebsd-amd64 kfreebsd-i386 hurd-i386 x32

On Mon, Feb 18, 2019 at 10:27:49AM +0100, Petter Reinholdtsen wrote:
> [Mo Zhou]
> > ppc64el doesn't have any SIMD instruction set named SSE
> 
> As far as I know, casparcg-server is only ported to amd64, and I did not
> intend to port it to any new platforms.  If you want or need it to work
> on other architectures, you should talk to upstream to get them to
> accept patches.
> 
> Sadly there are no autobuilders for contrib packages, so I do not know
> if it build on anything but amd64.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Cyril Brulebois]

Hi,

Didier 'OdyX' Raboud  (2019-02-18):
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

Thanks, Didier.

While I haven't dived into it as deep as you did (e.g. I didn't proofread
the big table at the end), that seems like a reasonable characterization
of the current situation; many thanks for your highly detailed summary.


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


signature.asc
Description: PGP signature

Bug#922658: linux-image-4.19.0-0.bpo.2-amd64: NETDEV WATCHDOG: enp1s0f1 (r8169): transmit queue 0 timed out

[NG]

Package: src:linux
Version: 4.19.16-1~bpo9+1
Severity: normal

Dear Maintainer,

When enp1s0f1 is under heavy download stress (downloading large files, watching
a stream, or even when installing debian packages) it tends to hang. Depending
on which download activity it's being ran, downloads will remain active but
with 0Kbpps, some others will just get canceled.
Best thing to do it's to run 'sudo modprobe -r r8169 && sudo modprobe r8169',
restarting networkmanager does nothing.  But sometimes it doesn't solve the
problem, not even rebooting does the trick network manager applet will say that
the network it's being connected but it never reaches connected state. So the
best thing to do it's to power off the computer completely and then power on
again freshly.

I've been experiencing this since kernel 4.19 bpo.1 but it got worse with bpo.2
(I tested Fedora with kernel 4.20.8 and it's even worse, same with debian's
testing and unstable branch)




-- Package-specific info:
** Version:
Linux version 4.19.0-0.bpo.2-amd64 (debian-ker...@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.19.16-1~bpo9+1
(2019-02-07)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-0.bpo.2-amd64 root=/dev/mapper/firebolt-root ro
amdgpu.dpm=0 amdgpu.dc=0 quiet

** Tainted: OE (12288)
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Acer
product_name: Aspire A515-41G
product_version: V1.09
chassis_vendor: Acer
chassis_version: V1.09
bios_vendor: Insyde Corp.
bios_version: V1.09
board_vendor: BR
board_name: Wartortle_BS
board_version: V1.09

** Loaded modules:
rfcomm
pci_stub
vboxpci(OE)
vboxnetadp(OE)
vboxnetflt(OE)
vboxdrv(OE)
ctr
ccm
fuse
bnep
btusb
arc4
btrtl
btbcm
btintel
bluetooth
amdkfd
amdgpu
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
drbg
ansi_cprng
ecdh_generic
media
rtsx_pci_ms
joydev
memstick
rtsx_pci_sdmmc
mmc_core
edac_mce_amd
kvm_amd
dcdbas
dell_wmi_descriptor
wmi
ccp
rng_core
ath10k_pci
ath10k_core
kvm
ath
chash
mac80211
snd_hda_codec_realtek
gpu_sched
snd_hda_codec_generic
ttm
snd_hda_codec_hdmi
irqbypass
xhci_pci
snd_hda_intel
snd_hda_codec
xhci_hcd
snd_hda_core
r8169
crct10dif_pclmul
snd_hwdep
rtsx_pci
cfg80211
snd_pcm
libphy
drm_kms_helper
ehci_pci
crc32_pclmul
ehci_hcd
usbcore
snd_timer
i2c_piix4
rfkill
ghash_clmulni_intel
snd
drm
sg
soundcore
psmouse
usb_common
k10temp
fam15h_power
video
i2c_algo_bit
battery
ac
button
pcc_cpufreq
acpi_cpufreq
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
dm_crypt
dm_mod
sd_mod
crc32c_intel
ahci
libahci
libata
aesni_intel
aes_x86_64
crypto_simd
cryptd
glue_helper
evdev
scsi_mod
serio_raw

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:1576]
Subsystem: Acer Incorporated [ALI] Device [1025:1201]
Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Carrizo [1002:9874] (rev c8) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Carrizo [1025:1201]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: amdgpu
Kernel modules: amdgpu

00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Kabini
HDMI/DP Audio [1002:9840]
Subsystem: Acer Incorporated [ALI] Kabini HDMI/DP Audio [1025:1201]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Device
[1022:157b]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device
[1022:157c] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:03.0 Host bridge 

Bug#922657: Misfires when variable is put in a string

[積丹尼 Dan Jacobson]

Package: bash-completion
Version: 1:2.8-5

$ set apt-show-versions
$ zless /usr/share/doc/$@/ch
$ zless /usr/share/doc/$@/ch
chromium  chromium-common   chromium-sandbox  chromium-shell
$ zless /usr/share/doc/\$@/chromium

Huh?

OK, now shortening the last string sitting on my terminal, and hitting
TAB again
$ zless /usr/share/doc/\$@/ch
it just beeps, proving that adding the \ was nonsense in the first
place.

Anyway
$ echo zless /usr/share/doc/$@/ch*
zless /usr/share/doc/apt-show-versions/changelog.gz

shows what I was trying to match.

I'm not saying you need to deal with $@ (for now yet, maybe in a few
years), but at least don't insert \ .

Bug#922656: RM: mopidy-youtube -- ROM; Package has never worked

[Stein Magnus Jodal]

Package: ftp.debian.org
Severity: normal

The package was uploaded 3+ years ago, but it has never worked, as the
dependency python-pafy didn't and wouldn't ship a python2
version.

Upstream is currently not in good shape, so a working Python 3 version
does not seem realistic in the near future.

As the maintainer, I suggest to remove the package. This would close RC
bug #795007.

-jodal


signature.asc
Description: PGP signature

Bug#922655: systemd: some user units are not enabled according to the vendor presets

[Norbert Lange]

Package: systemd
Version: 240-5
Severity: normal

Dear Maintainer,

I tried adding a user-specific file to
~/.config/user-tmpfiles.d/chromium-cache.conf,
expecting this to be used when logging in.

The user systemd-tmpfiles-setup is disabled by default (couple weeks
old buster installation).

I was able to remedy the issue with executing "systemctl --user preset-all",
but this normally should not be required. There are further differnces
in enabled units.

 The distro defaults are these:
# ls /usr/lib/systemd/user/*.wants
/usr/lib/systemd/user/graphical-session-pre.target.wants:
ssh-agent.service

/usr/lib/systemd/user/sockets.target.wants:
dbus.socket  dirmngr.socket  gpg-agent-browser.socket
gpg-agent-extra.socket  gpg-agent.socket  gpg-agent-ssh.socket
pulseaudio.socket



 The user config after preset-all is this:
# ls ~/.config/systemd/user/*.wants
/home/noppl/.config/systemd/user/basic.target.wants:
systemd-tmpfiles-setup.service

/home/noppl/.config/systemd/user/default.target.wants:
pulseaudio.service  rygel.service

/home/noppl/.config/systemd/user/sockets.target.wants:
dirmngr.socket gpg-agent-browser.socket  gpg-agent-extra.socket
gpg-agent.socket  gpg-agent-ssh.socket  pulseaudio.socket

/home/noppl/.config/systemd/user/timers.target.wants:
systemd-tmpfiles-clean.timer



Kind regards, Norbert


-- Package-specific info:

-- 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/8 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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.2-7
ii  libaudit11:2.8.4-2
ii  libblkid12.33.1-0.1
ii  libc62.28-6
ii  libcap2  1:2.25-2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-5
ii  libgnutls30  3.6.6-2
ii  libgpg-error01.35-1
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.4-1
ii  libmount12.33.1-0.1
ii  libpam0g 1.1.8-4
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  240-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  240-5

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 240-5

-- no debconf information

Bug#922653: irqbalance: restart loop when running under runit and with a single CPU

[Mathieu Mirmont]

Package: irqbalance
Version: 1.5.0-3
Severity: normal
Tags: patch

Hi,

While testing something else in a virtual machine I noticed that
irqbalance exits if it detects a single CPU. When running under runit
the service is continuously restarted.

I would suggest detecting this case directly from the run script and
stopping the service with sv, something like this:


#!/bin/sh
if test $(nproc) = 1; then
   echo "Not starting irqbalance: only one CPU detected"
   sv stop .
   exit 0
fi
exec /usr/sbin/irqbalance --foreground


Cheers,

Mat.


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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages irqbalance depends on:
ii  debconf [debconf-2.0]  1.5.70
ii  libc6  2.28-6
ii  libcap-ng0 0.7.9-2
ii  libglib2.0-0   2.58.3-1
ii  libncursesw6   6.1+20181013-1
ii  libnuma1   2.0.12-1
ii  libsystemd0240-5
ii  libtinfo6  6.1+20181013-1
ii  lsb-base   10.2018112800
ii  runit-helper   2.8.4

irqbalance recommends no packages.

irqbalance suggests no packages.

-- debconf information:
  irqbalance/oneshot: false
  irqbalance/enable: true

Bug#922654: debian-policy: Section 9.1.2 points to a wrong FHS section?

[Linda Lapinlampi]

Source: debian-policy
Version: 4.3.0.2
Severity: normal

The policy says in section § 9.1.2. "Site-specific programs":

> Packages must not create sub-directories in the directory /usr/local
> itself, except those listed in FHS, section 4.5. However, you may
> create directories below them as you wish. You must not remove any of
> the directories listed in 4.5, even if you created them.

FHS 3.0's section 4.5 is about a completely irrelevant /usr/include
directory, not about /usr/local. I think this should point to section
4.9 in the FHS?

In FHS 2.3, this "section 4.5" might have been right. But as said in
policy 9.1.1:

> The location of all files and directories must comply with the Filesystem
> Hierarchy Standard (FHS), version 3.0, [...].

No other exception is noted below that.

Bug#922586: FTBFS against opencv 4.0.1 (exp)

[José Luis Blanco-Claraco]

Thanks!

This problem is already solved upstream in the forthcoming mrpt-2.0.0
version. I'm marking this as "fixed-upstream" in the meanwhile.

Best,

On Mon, Feb 18, 2019 at 7:42 AM Mo Zhou  wrote:
>
> Source: mrpt
> Version: 1.5.6-1
> Severity: important
>
> headers have been moved to /usr/include/opencv4/opencv2/* since opencv4



-- 

/**
 * Jose Luis Blanco-Claraco
 * Universidad de Almería - Departamento de Ingeniería
 * [Homepage]( https://w3.ual.es/~jlblanco/ )
 * [GH profile]( https://github.com/jlblancoc )
 */

Bug#913467: nvidia-graphics-drivers: CVE‑2018‑6260: access to application data processed on the GPU through a side channel exposed by the GPU performance counters

[Luca Boccassi]

On Mon, 2019-02-18 at 22:57 +0100, Moritz Mühlenhoff wrote:
> On Mon, Nov 12, 2018 at 02:36:23PM +, Luca Boccassi wrote:
> > On Mon, 2018-11-12 at 13:47 +0100, Andreas Beckmann wrote:
> > > On 2018-11-11 13:54, Luca Boccassi wrote:
> > > > https://nvidia.custhelp.com/app/answers/detail/a_id/4738
> > > 
> > > So we expect new releases soon. There is already 415.* ...
> > > 
> > > Please refrain from any uploads for now while I'm preparing
> > > infrastructure changes. I'll do a 390.87-3 upload soon,
> > > thereafter
> > > you
> > > could update that in sid. If there are some pkern commits in the
> > > repository, use them, if not, they will come with -2.
> > > 
> > > (Procedure in 390:
> > > do all commits incl. finalization of changelog in 390
> > > merge into master
> > > upload from master
> > > )
> > > 
> > > Andreas
> > 
> > Ok, I see -3 is now in unstable (thanks!) so if something comes out
> > for
> > the 390 branch I'll follow that procedure and upload to unstable
> > from
> > master.
> > 
> > What about -legacy-390xx?
> > 
> > > PS: finally a reason to push 390 to stretch, lets do it soon at
> > > the
> > > beginning of the new point release cycle
> > 
> > Yes, sounds good, 384 is not maintained anymore.
> 
> I'm confused by all the branches in buster. Can you please confirm
> which are fixed for CVE-2018-6260 and which are not? (And if so,
> which
> version in sid fixed it):
> 
> nvidia-graphics-drivers: 390.87-8 (sid: 410.93-2)
> nvidia-graphics-drivers-legacy-390xx: 390.87-6 (sid the same)
> nvidia-graphics-drivers-legacy-340xx: 340.107-3 (sid the same)
> nvidia-graphics-drivers-legacy-304xx: not in testing

Unfortunately we have no idea - NVIDIA's security tracker was never
updated after the initial mention of the CVE:

https://nvidia.custhelp.com/app/answers/detail/a_id/4738

-- 
Kind regards,
Luca Boccassi

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

Bug#922652: Strange bug tracker error maybe related to lone dot

[btstest-pDlQ32lUbWwM]

Test update with plain dot on single line and different mail
address to trigger similar messages. Also forcing
Content-Transfer-Encoding: quoted-printable

LAST-LINE-BEFORE-DOT
.
FIRST-LINE-AFTER-DOT

===

LAST-LINE-BEFORE-DOT
> - There is a lintian override for a legitimate mistake (unindented list).

FIRST-LINE-AFTER-DOT

Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Handle transition from MAT to MAT2

[Georg Faerber]

Hi all,

(Cc:ing all the people who took part in this issue, and also Julien as
the upstream author.)

On 19-02-12 14:39:32, Georg Faerber wrote:
> That is: option one of the second proposal ("quickly patch together a
> Python 2 Nautilus extension that wraps mat2's CLI").

Unfortunately, and sorry again for my delay working on this, there was
no feedback. I've poked Jonas today on IRC privately, asking if he had a
comment, he said "sounds good, go ahead", and so I did.

Initially, I wanted to do what I wrote above, but in the end I just
patched the current Nautilus extension to make it work with
python-nautilus build against Python 2.7, as it will be shipped in
Debian buster.

The changes I needed to make weren't that intrusive:

- I've changed the interpreter and added "coding: utf-8" to overcome
  utf-8 errors.
- Changed some imports to make these work with Python 2.7.
- Removed type hints. (Were this backported to 2.7?)
- Removed internal calls to libmat2, replaced by two funtions to call
  the cli of mat2 (and to check the output) and to guess the mtype of a
  given file.
- Furthermore, I've removed line 5 in the following code

class Mat2Extension(GObject.GObject, Nautilus.MenuProvider, 
Nautilus.LocationWidgetProvider):
""" This class adds an item to the right-clic menu in Nautilus. """

def __init__(self):
super().__init__()  <-
self.infobar_hbox = None
self.infobar = None
self.failed_items = list()

  as otherwise I was running into

  TypeError: super() takes at least 1 argument (0 given)

  and I was unsure what's the cause and how to fix this.

I've tested the changes quickly with some files of different types, it
seems to be working. 

I would be very happy if someone of you could review this.

I've prepared 0.7.0-2 and pushed to the branch d/0.7.0-2. The repo is
available via [1].

To ease consumption and testing, I've attached the .deb to this mail as
well, it's signed by my key. If you take this route, please note: AFAIK,
dpkg -i doesn't install recommend packages, so please install
python-nautilus manually.

Thanks in advance,
cheers,
Georg


[1] https://salsa.debian.org/pkg-privacy-team/mat2/


mat2_0.7.0-2_all.deb
Description: application/vnd.debian.binary-package


signature.asc
Description: Digital signature

Bug#921983: gnome-chemistry-utils 0.14.15-1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gnome-chemistry-utils
Version: 0.14.15-1+deb9u1

Explanation: drop the obsolete gcu-plugin package

Bug#922652: Strange bug tracker error maybe related to lone dot

[halfdog]

Package: bugs.debian.org

Running a data deduplication tool on all sent and received messages
detected an anomaly regarding a message from bugs.debian.org
dating back to 2018-01-22.

The exact cause is unknown but might be related to a lone "."
in a message truncating it. It is also unclear which component
caused the error - the bug tracker or some other component involved.

This bug is for documentation and to attempt reproducing the
issue. Otherwise this bug can be closed.

LAST-LINE-BEFORE-DOT
.
FIRST-LINE-AFTER-DOT

Bug#848579: calibre: Archos Tablet (101b oxygen) not recognised (android 6)

[Florian Gruel]

Hello,  i have just make a test. Tablet ok (read write)with nemo and nautilus.

From calibre , there is now way to "send to device", but "save as" is working 
as workaround

I can make more tests if you want


Envoyé depuis mon smartphone.

 Message d'origine 
De : Nicholas D Steeves 
Date : 15/02/2019 23:31 (GMT+01:00)
À : r...@debian.org, 848...@bugs.debian.org
Cc : Florian Gruel 
Objet : Re: Bug#848579: calibre: Archos Tablet (101b oxygen) not recognised 
(android 6)

Control: owner -1 !
Control: tag +1 moreinfo

Hi Florian,

On Wed, Dec 21, 2016 at 06:32:30PM +0530, Ritesh Raj Sarraf wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Tue, 2016-12-20 at 19:09 +, Florian Gruel wrote:
> > When I plug the tablet , it appears in nemo and nautilus as a MTP device, it
> > seams to be OK.
>
> Showing up is one part. Are you able to perform I/O on it ?

I also believe that this bug is probably a libmtp one.  This bug has
been waiting two years for a reply, so I'm thinking about
closing it as invalid when buster is released, if there as not been a
follow-up by that time.  I'm guessing that will be August or
September.

Debian 9 (stretch) shipped with libmtp_1.1.13-1, which is newer than
what existed when you submitted this bug (1.1.12).  Would you please confirm if
I/O can be performed on your Archos Tablet through the file-manager?

In buster we now have 1.1.16-1, and in sid 1.1.16-2.  Testing if your
tablet works with one of these would also be appreciated.


Thanks!
Nicholas

Bug#922651: cacti: typo in debian/debian.php.dist

[Linda Lapinlampi]

Package: cacti
Version: 1.2.1+ds1-2
Severity: minor

Dear Maintainer,

debian/debian.php.dist has a typo on line 4. It says "normaly", while it
should say "normally".

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

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

Bug#922650: opensc-pkcs11: fails to work with dual CAC PIV cards

[A. Maitland Bottoms]

Package: opensc-pkcs11
Version: 0.19.0-1
Severity: important
Tags: patch

Dear Maintainer,

Recent PIV enabled CAC cards are not handled by the opensc 0.19.0
release. Yet all current CAC cards are scheduled to enable PIV
authentication by March 31, 2019.

For users of these cards, this bug is of grave severity.

This problem has been solved recently upstream
https://github.com/OpenSC/OpenSC
although the fixes have not yet been included in an upstream release.

I have cherry-picked from upstream commits a small set that provides
working card support. It works for me using
pkcs11-tool --module /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so -l -t
ssh-keygen -D /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
ssh -I /usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
and Firefox browser smart card token support.

Attached is a debdiff of my test package.

I think Buster will be much better if we can release it with support
for this use case.

Thanks,
-Maitland

enc: opensc-pkcs11-Dual-CAC-PIV-and-PIVK-support.debdiff


opensc-pkcs11-Dual-CAC-PIV-and-PIVK-support.debdiff
Description: Binary data

Bug#844452: ITA: json-c -- JSON manipulation library

[Cameron Norman]

Control: retitle -1 ITA: json-c -- JSON manipulation library

I intend to adopt this package.

--
Cameron Nemo

On Wed, 25 Jul 2018 14:47:50 +0800 Nicolas Braud-Santoni <
nico...@braud-santoni.eu> wrote:
> Control: reopen -1
> Control: reassign -1 wnpp
> Control: retitle -1 O: json-c -- JSON manipulation library
> Control: severity -1 normal
>
> Hi,
>
> Tobias pointed out that the package now needs a WNPP bug.
> I am transmuting the old bug so as to preserve the context.
>
> Best,
>
>   nicoo
>
> On Tue, Jul 24, 2018 at 12:00:10AM +, Nicolas Braud-Santoni wrote:
> > Source: json-c
> > Source-Version: 0.13.1+dfsg-1
> >
> > We believe that the bug you reported is fixed in the latest version of
> > json-c, which is due to be installed in the Debian FTP archive.
> > [...]
> >* QA upload.
> >* Orphan the package (Closes: 844452)
> >* New upstream version (2018-03-05)
> >  - Remove obsolete patches
> >  - Bump library SONAME & update symbols file

Bug#922649: xserver-xorg-video-intel: Xorg terminates with "modeset(0): failed to set mode: No such file or directory"

[Alexander GQ Gerasiov]

Package: xserver-xorg-video-intel
Version: 2:2.99.917+git20180925-2
Severity: normal


Dear Maintainer,

I have Lenovo Carbox X1 Gen6 with dockstation and current version of 
xserver-xorg-video-intel is not stable at all:

Often one (or both) extrernal monitor goes blank and could not be turned on 
with xrand until I
switch to vt1 and back to vt7.

But there is another problem: after switching back to vt7 Xserver often dies 
with the message
"modeset(0): failed to set mode: No such file or directory"

There is similar bugreport in redhat's tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=1662057

Then I rebuild the package with two patches from upstream git added:

>From e5ff8e1828f97891c819c919d7115c6e18b2eb1f Mon Sep 17 00:00:00 2001
From: Chris Wilson 
Date: Mon, 3 Dec 2018 08:58:39 +
Subject: [PATCH] sna: Skip restoring a mode for link-status=bad if the crtc
 was idle

>From c37c7ee0748ba828ec5d2c7304cd2a17af2c8109 Mon Sep 17 00:00:00 2001
From: Chris Wilson 
Date: Fri, 30 Nov 2018 14:11:04 +
Subject: [PATCH] sna: Switch off old outputs on topology changes

this helps a lot:
I do not see crashed for a week and looks like stability is improved.



Please consider packaging new upstream "release" until Buster freeze.


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

The lspci command was not found; not including PCI data.

Xorg X server configuration file status:

-rw-r--r-- 1 root root 65 Jan 16 14:45 /etc/X11/xorg.conf

Contents of /etc/X11/xorg.conf:
---
Section "ServerFlags"
Option "DontZap" "true"
EndSection

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 226 Dec  3 06:02 90-xpra-virtual.conf

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

Kernel version (/proc/version):
---
Linux version 4.19.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.2.0 (Debian 8.2.0-14)) #1 SMP Debian 4.19.16-1 (2019-01-17)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 48678 Feb 19 00:01 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[119967.604] 
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[119967.604] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[119967.604] Current Operating System: Linux fran 4.19.0-2-amd64 #1 SMP Debian 
4.19.16-1 (2019-01-17) x86_64
[119967.604] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-2-amd64 
root=/dev/mapper/fran-root ro quiet
[119967.604] Build Date: 25 October 2018  06:15:23PM
[119967.604] xorg-server 2:1.20.3-1 (https://www.debian.org/support) 
[119967.604] Current version of pixman: 0.36.0
[119967.604]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[119967.604] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[119967.604] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Feb 16 18:23:33 
2019
[119967.605] (==) Using config file: "/etc/X11/xorg.conf"
[119967.605] (==) Using config directory: "/etc/X11/xorg.conf.d"
[119967.605] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[119967.605] (==) No Layout section.  Using the first Screen section.
[119967.605] (==) No screen section available. Using defaults.
[119967.605] (**) |-->Screen "Default Screen Section" (0)
[119967.605] (**) |   |-->Monitor ""
[119967.605] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[119967.605] (**) Option "DontZap" "true"
[119967.605] (==) Automatically adding devices
[119967.605] (==) Automatically enabling devices
[119967.605] (==) Automatically adding GPU devices
[119967.605] (==) Max clients allowed: 256, resource mask: 0x1f
[119967.605] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[119967.605]Entry deleted from font path.
[119967.606] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[119967.606] (==) ModulePath set to "/usr/lib/xorg/modules"
[119967.606] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[119967.606] (II) Loader magic: 0x55b78a8efe20
[119967.606] (II) Module ABI versions:
[119967.606]X.Org ANSI C Emulation: 0.4
[119967.606]X.Org Video Driver: 24.0
[119967.606]X.Org XInput driver : 24.1
[119967.606]

Bug#918590: WARNING: Device /dev/md0 not initialized in udev database even after waiting 10000000 microseconds

[Thorsten Glaser]

Hi,

we’re also hit by this (for a while already, but now on more systems).

I discovered the following things:

During boot, when the “even after waiting 1000 microseconds”
message comes, hitting ^C allows the boot to continue, although
several things (such as the framebugger console) are missing/not
initialised.

Logging in and doing
sudo /etc/init.d/udev stop
sudo /etc/init.d/udev start
fixes it.

Or, letting it boot, and getting the “sudo lvs” to hang. The
same commands (udev stop/start) fix it, until the next reboot.

All with sysvinit.

On one system, I did not get it any more after today’s dist-
upgrade (in sid), although that was the one on which I got it
only late.

On my own X61 work laptop, I don’t get it.

Axel, do you still get it on your laptop after dist-upgrading
to latest sid?

bye,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D

Bug#918578: gosa: GOsa web interface missing password field

[Wolfgang Schweer]

On Sun, Feb 17, 2019 at 04:41:57PM +0100, Wolfgang Schweer wrote:
> On Mon, Jan 14, 2019 at 03:43:26PM +, Holger Levsen wrote:
> > On Mon, Jan 14, 2019 at 05:15:59PM +0200, Eliza Ralph wrote:
> > > So are you saying it's not possible to fix GOsa in this case?
> > 
> > it's not gosa that is broken but your php setup.
> 
> After upgrading a Debian Edu main server (Stretch 9.8 -> Buster) the 
> password entry field is missing just like reported.
> Further investigation needed...
 
It seems to be enough to adjust the Apache configuration like this:

a2dismod php7.0
a2enmod php7.3
a2enconf php7.3-cgi
service apache2 restart

Most probably the gosa package should ship some information (NEWS).

Wolfgang


signature.asc
Description: PGP signature

Bug#918632: simplejson breaks json-schema-validator autopkgtest

[Neil Williams]

On Mon, 18 Feb 2019 20:05:41 +0100 Paul Gevers 
wrote:
> Control: severity -1 serious
> 
> Hi,
> 
> On Mon, 7 Jan 2019 21:49:01 +0100 Paul Gevers 
> wrote:
> > With a recent upload of simplejson the autopkgtest of
> > json-schema-validator fails in testing when that autopkgtest is run
> > with the binary packages of simplejson from unstable. It passes
> > when run with only packages from testing. In tabular form:
> >passfail
> > simplejson from testing3.16.0-1
> > json-schema-validator  from testing2.3.1-3
> > all others from testingfrom testing
> > 
> > I copied some of the output at the bottom of this report.
> > 
> > Currently this regression is contributing to the delay of the
> > migration of simplejson 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.
> 
> Since February 12, this is now blocking simplejson from migrating.
> This bug should be fixed either direction: or simplejson fixes the
> regression it causes in json-schema-validator, or
> json-schema-validator fixes its autopkgtest to adapt to the new
> situation. Please agree which package should be fixed and reassign it
> to that package, keeping the version information.

My guess is that json-schema-validator is the package at fault but I
orphaned it precisely because I don't have time to investigate bugs in
the package. There are no reverse dependencies that affect buster or
unstable and no Python3 package in Debian. Nobody else has taken any
interest in the package since it was orphaned over a year ago.

Unless there are any relevant bug reports filed against simplejson or
some other confirmation of the bug as being caused by simplejson within
say a week to 10 days, I'll assign this just to json-schema-validator
and seek removal of json-schema-validator from Debian as orphaned, out
of date & RC buggy. There are better ways to validate Python data
structures than exporting & validating in JSON.

-- 

Neil Williams
h...@codehelp.co.uk



pgp7RB3VmH4OA.pgp
Description: OpenPGP digital signature

Bug#826286: ITA: libnih -- NIH Utility Library

[Cameron Norman]

Control: retitle -1 ITA: libnih -- NIH Utility Library

I intend to adopt this package.

--

Cameron Nemo

Bug#922648: CVE-2019-6988

[Moritz Muehlenhoff]

Source: openjpeg2
Severity: important
Tags: security

This was assigned CVE-2019-6988:
https://github.com/uclouvain/openjpeg/issues/1178

Cheers,
Moritz
 

Bug#921653: texlive-latex-extra: docindex.sty relies on unavailable xhj.sty, galley2.sty

[Hilmar Preuße]

notforwarded 921653
tags 921653 - fixed-upstream
stop

On 15.02.19 19:02, Braun Gábor wrote:

Hi,

> I have problems finding contact information for the author.
> I would welcome any ideas what else to try.
> 
> I have looked at the documentation for packages authored by
> Lars Hellström, and only found the email address 
> lars.hellst...@math.umu.se (in e.g. xdoc2.pdf)
> but I have received an 550 Address rejected answer for my email sent 
> there.
> 
> An Internet search finds many people named Lars Hellström.
> 
So, how to got from here? My suggestion: we put the package on the black
list and close the bug.
If you're really interested in the package and found a way to fix it
(either you found that Lars Hellström or you fix the package on CTAN)
you open a wishlist bug and we re-include the package.

OK for you?

Hilmar

>> My impression is that this xdoc package is rather an academic
>> experiment, which was never meant to be used by real end users. The
>> Debian solution would be easy: put it on the blacklist.
> 
> Yes, the package looks abandoned.
> 


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



signature.asc
Description: OpenPGP digital signature

Bug#913467: nvidia-graphics-drivers: CVE‑2018‑6260: access to application data processed on the GPU through a side channel exposed by the GPU performance counters

[Moritz Mühlenhoff]

On Mon, Nov 12, 2018 at 02:36:23PM +, Luca Boccassi wrote:
> On Mon, 2018-11-12 at 13:47 +0100, Andreas Beckmann wrote:
> > On 2018-11-11 13:54, Luca Boccassi wrote:
> > > https://nvidia.custhelp.com/app/answers/detail/a_id/4738
> > 
> > So we expect new releases soon. There is already 415.* ...
> > 
> > Please refrain from any uploads for now while I'm preparing
> > infrastructure changes. I'll do a 390.87-3 upload soon, thereafter
> > you
> > could update that in sid. If there are some pkern commits in the
> > repository, use them, if not, they will come with -2.
> > 
> > (Procedure in 390:
> > do all commits incl. finalization of changelog in 390
> > merge into master
> > upload from master
> > )
> > 
> > Andreas
> 
> Ok, I see -3 is now in unstable (thanks!) so if something comes out for
> the 390 branch I'll follow that procedure and upload to unstable from
> master.
> 
> What about -legacy-390xx?
> 
> > PS: finally a reason to push 390 to stretch, lets do it soon at the
> > beginning of the new point release cycle
> 
> Yes, sounds good, 384 is not maintained anymore.

I'm confused by all the branches in buster. Can you please confirm
which are fixed for CVE-2018-6260 and which are not? (And if so, which
version in sid fixed it):

nvidia-graphics-drivers: 390.87-8 (sid: 410.93-2)
nvidia-graphics-drivers-legacy-390xx: 390.87-6 (sid the same)
nvidia-graphics-drivers-legacy-340xx: 340.107-3 (sid the same)
nvidia-graphics-drivers-legacy-304xx: not in testing

Cheers,
Moritz

Bug#900787: nvidia-graphics-drivers-legacy-304xx: does not support Xorg Xserver 1.20

[Moritz Mühlenhoff]

On Mon, Jun 04, 2018 at 11:47:35PM +0200, Andreas Beckmann wrote:
> Source: nvidia-graphics-drivers-legacy-304xx
> Version: 304.137-5
> Severity: serious
> Tags: sid buster upstream wontfix
> 
> The 304.xx legacy series is EoL upstream and won't be updated for the
> latest Xorg.
> 
> Let's get it out of buster ... but keep it in sid for now.

Out of interest, why is this kept in sid? Unstable also has 1.20 since
May of last year.

Cheers,
Moritz

Bug#830303: mmc0: Unexpected interrupt 0x04000000.

[Alexandros Kosiaris]

Hi,

For what it's worth, it seems on this specific hardware:

Broadcom Limited BCM57765/57785 SDXC/MMC Card Reader [14e4:16bc]

the problem can be resolved by passing:

debug_quirks2=0x4 to sdhci kernel module.

Note that there is also the debug_quirks param. I did set some values
for it but the working one is the default, namely 0

For more information have a look at
https://bugzilla.kernel.org/show_bug.cgi?id=73241#c55

I just tested it on a Macmini7,1Debian having Stretch with
4.19+101~bpo9+1 kernel. I 'll be using it for the next few days, I am
hoping everything will work out ok and I won't have to report more
stuff

Bug#915407: what's with logind?

[Adam Borowski]

Hi!
You just made an upload of src:systemd, without the fix for libpam-systemd
alternative.  There's very little time before the freeze, and due to the
still unfixed dependency regression most GUI packages remain non-installable
without systemd.  Could you please apply this one-line fix (#915407) pretty
much immediately?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄

Bug#922305: latexindent: please add dependency with liblog-log4perl-perl

[Hilmar Preuße]

On 18.02.19 08:36, Yukiharu YABUKI wrote:

Hello,

> It is hard question for me. I had resolved this problem.
> I reported this issue for feature user.
> 
Yes, and we're thankful for this report!

> It seems for me that texlive-extra-utils should be separate
> packages. Is this too difficult? If it is true, I agree with you.
> 
Sorry, I don't understand your suggestion?

My proposal is to make texlive-latex-extra recommend
liblog-log4perl-perl instead of depend. The advantage would be, that apt
installs liblog-log4perl-perl by default, but people would have a chance
to remove that package if they don't need it as they are not aware of
latexindent

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



signature.asc
Description: OpenPGP digital signature

Bug#922647: systemd --user no longer running

[Felipe Sateler]

Control: tags -1 moreinfo

On Mon, Feb 18, 2019 at 5:36 PM Eduard Bloch  wrote:

> Package: libpam-systemd
> Version: 240-5
> Severity: normal
>
> Hi,
>
> a few days ago some user services started failed - I mainly noticed that
> pulseaudio was no longer available.
> This looked very strange, and while checking other systems, I saw that
> "systemd --user" is not launched, which would have started pa and some
> other user-session daemons.
>

Please get the logs of user@$youruid.service. It is possible a user unit is
timing out, and thus failing the user manager.


-- 

Saludos,
Felipe Sateler

Bug#917812: gnome-software: update broke gnome software

[Andrew Hayzen]

FYI, I've been discussing this issue with upstream gnome-software 
https://gitlab.gnome.org/GNOME/gnome-software/issues/589 and
packagekit https://github.com/hughsie/PackageKit/issues/314 .

I've not been able to capture a trace of packagekit crashing yet, so
any additional info would be appreciated.

Bug#922236: gnome-software: Gnome software stucked in endless startup loop

[Andrew Hayzen]

This looks like a duplicate of 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917812 ?

Bug#922551: RM: oclgrind [armel] -- ROP; FTBFS with clang 7

[Andreas Beckmann]

On 2019-02-18 11:25, John Paul Adrian Glaubitz wrote:
> Hi Andreas!
> 
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to 
>> `__atomic_fetch_add_4'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to 
>> `__atomic_exchange_4'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to 
>> `__atomic_fetch_sub_4'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_load_1'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_store_4'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_load_4'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to `__atomic_store_1'
>> /usr/bin/ld: liboclgrind-18.3.so: undefined reference to 
>> `__atomic_compare_exchange_4'
>> collect2: error: ld returned 1 exit status
>>
>> and I don't have time to debug this.
> 
> This is most likely caused by a missing -latomic in the linker options,
> see [1]. armel doesn't have these atomics built-in in hardware, so you
> need to use an external helper library for that.
> 
> Adrian
> 
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915046

Thanks for the pointer, will look into it.


Andreas

Bug#859123: heads up: DLA should now be published on the website

[Antoine Beaupré]

On 2019-02-01 20:58:28, Holger Levsen wrote:
> On Fri, Feb 01, 2019 at 01:58:04PM -0500, Antoine Beaupré wrote:

[...]

> can you please put that on wiki.d.o/LTS/Development?!

This is now done. I added a new section to the wiki

https://wiki.debian.org/LTS/Development#Publishing_updates_on_the_website

The TL;DR: is that you now need to clone the main website and issue a
merge request when you publish a DLA. Once you have a clone, it should
be as simple as:

parse-dla.pl 
git checkout -b DLA--Y
git add 2019
git commit -m'DLA-XXX-Y'
git push -u origin
salsa mr

I've done one more mass import, hopefully the last:

https://salsa.debian.org/webmaster-team/webwml/merge_requests/58

But my little finger tells me there are many DLAs still missing from the
website. So even if/when the above MR does get merged, more entries will
be missing. So someone will need to make sure to run the check script to
make sure no entries are missing regularly, see also:

https://salsa.debian.org/webmaster-team/cron/merge_requests/1

Obviously, this workflow is not optimal and could be automated, see also
#859123 (in CC).

Thank you for your time.

A.

-- 
Omnis enim ex infirmitate feritas est.
All cruelty springs from weakness.
 - Lucius Annaeus Seneca (58 AD)

Bug#922447: lighttpd: autopkgtest regression

[Antonio Terceiro]

On Mon, Feb 18, 2019 at 07:38:49PM +0100, Paul Gevers wrote:
> Hi Helmut,
> 
> [Adding the debian-ci team into the discussion]
> 
> On 18-02-2019 08:06, Helmut Grohne wrote:
> >> autopkgtest [00:11:07]: test defconfig: [---
> >> 2019-02-16 00:11:07: (configfile.c.1599) server.upload-dirs doesn't
> >> exist: /var/cache/lighttpd/uploads
> >> 2019-02-16 00:11:07: (mod_compress.c.275) can't stat compress.cache-dir
> >> /var/cache/lighttpd/compress/ Permission denied
> > 
> > What happens here is that /var/cache/lighttpd/compress is not created
> > during installation. That actually is a problem, but the question is
> > whether the test environment is "sane".
> 
> The ci.d.n runs its tests in a standard LXC. So depending on what you
> think you should support, that is where delta's from bare metal
> configurations come from.
> 
> > The very same autopkgtest does not fail on salsa-ci:
> > https://salsa.debian.org/debian/lighttpd/-/jobs/126948
> 
> I don't know how salsa-ci runs it's pipelines.
> 
> > Upon closer inspection the difference becomes apparent. salsa-ci is
> > performing a regular package installation.
> 
> As does ci.d.n, except in an LXC.
> 
> > lighttpd's init script
> > ensures the presence of said directory as does the tmpfile.d config.
> > However ci.debian.net runs neither (because it seems to come without an
> > init system).
> 
> Didn't know about that. Does anybody know if that is normal for LXCs?

That is not the case; it's the other way around: salsa-ci runs stuff on
docker containers -- and so have no init system. LXC is designed to run
system containers, and it does have a full init system.

> > We can of course create these locations in the package itself. Indeed we
> > already do that for e.g. /var/log/lighttpd (and that makes us require
> > root for build).
> > 
> > It turns out that ci.debian.net's environment is a bit artificial in
> > this regard. Should we weaken the test here or should we ensure presence
> > of those locations through non-init means?

Again, this argument does not hold. LXC (and ci.debian.net) boots an
actual init system inside the container, and it has *always* been like
this.

I have downloaded the lighttpd source here, and read all the tests. All
of them to start lighttpd directly, and at least the first test requires
being run as root; Tests that need to run as root need to say so in the
control file; salsa-ci runs stuff as root already, and that's why it
doesn't fail there.

In fact, just adding `Restrictions: needs-root` makes the test pass again.
Just tested this here.

By the way, since all the tests are starting lighttpd directly means
that the service definitions and the init integration is not being
tested being "the service starts" (because the package installation, and
therefore autopkgtest, would fail if that fails). Also, note that when
you start lighttpd directly in your script, there will be another
instance -- the one started by the init system -- running in the
background.


signature.asc
Description: PGP signature

Bug#878299: libvirt: Live migration with qemu not working with copy-storage-xx on stretch

[Bernhard Turmann]

Dear Maintainer,

it seems this bug is related to: #878299
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873012

After fixing qemu (by removing two CVE-2017-9524 patches), libvirt
3.0.0-4+deb9u3 is successfully able to migrate including storage.

Regards
Berni

Bug#900805: openvpn: No PIN prompt with PKCS11 when systemd is enabled (OpenVPN bug #538)

[Bernhard Schmidt]

On Tue, Jun 05, 2018 at 10:22:09AM +0200, Robert Haist wrote:

Dear Robert,

> users of yubikey or other PKCS11 based authetication are not able to use this
> feature with the current package.
> 
> Upstream reference: https://community.openvpn.net/openvpn/ticket/538
> 
> I was able to fix this problem by building the current debian package with the
> patch provided upstream:
> 
> https://community.openvpn.net/openvpn/attachment/ticket/538/openvpn-2.4.5_bug-538.patch
> 
> Please consider including this patch in your package.

Unfortunately I don't have any PKCS11 available and I cannot immediately
test it, but a message on openvpn-devel today suggests a simple one-line
patch would fix it, which is a lot less intrusive than the patch linked
to the OpenVPN trac above.

https://sourceforge.net/p/openvpn/mailman/message/36590286/

Are you able to test this?

Thanks,
Bernhard

Bug#873012: not working live migration in qemu / libvirt

[Bernhard Turmann]

Dear Maintainer,
during the last days I did some testing around this bug and hope that my
findings help to fix it.

Root Cause
===
It looks like the bug is caused by 2 patches in order to fix CVE-2017-9524:

- nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
-
nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch

Both patches were already included in version 2.8+dfsg-6+deb9u1, but not
activated yet. This happened in version 2.8+dfsg-6+deb9u2.

Versions affected by this bug (broken)
===
- 2.8+dfsg-6+deb9u2
- 2.8+dfsg-6+deb9u3
- 2.8+dfsg-6+deb9u4
- 2.8+dfsg-6+deb9u5
... (only the listed versions were tested)

Versions not affected (OK):

- 2.8+dfsg-6+deb9u1
... (older versions were not tested)

Remark:
In the following tests the live migration was executed several times in
both directions.

Test 1:

- git clone https://salsa.debian.org/qemu-team/qemu
- checkout tag 2.8+dfsg-6+deb9u1
- rebuild packages without any change
- install packages on two Debian Stretch Servers together with libvirt
3.0.0-4+deb9u3
- execute a live migration including storage with following command:
# time sudo virsh migrate --live --desturi qemu+ssh://destserver/system
--copy-storage-all --persistent --verbose --undefinesource --domain pxe1
=> Success

Test 2:

- checkout tag 2.8+dfsg-6+deb9u2
- disable both CVE-2017-9524 patches
- rebuild packages
- install packages on two Debian Stretch Servers together with libvirt
3.0.0-4+deb9u3
- execute a live migration including storage with following command:
# time sudo virsh migrate --live --desturi qemu+ssh://destserver/system
--copy-storage-all --persistent --verbose --undefinesource --domain pxe1
=> Success

Test 3:

- checkout tag 2.8+dfsg-6+deb9u5
- disable both CVE-2017-9524 patches
- rebuild packages
- install packages on two Debian Stretch Servers together with libvirt
3.0.0-4+deb9u3
- execute a live migration including storage with following command:
# time sudo virsh migrate --live --desturi qemu+ssh://destserver/system
--copy-storage-all --persistent --verbose --undefinesource --domain pxe1
=> Success

Conclusion
===
Obviously, reverting the CVE-2017-9524 patches would just be a quick fix
re-opening security issues. I can help testing. Unfortunately, anything
else is beyond my capabilities.

Regards
Berni

Bug#922643: ITP: build-alternative -- helper to build Debian package with diet libc

[Adam D. Barratt]

On Mon, 2019-02-18 at 19:37 +, Dmitry Bogatov wrote:
> * Package name : build-alternative
>   Version  : 0.0.1
>   Upstream Author  : Dmitry Bogatov 
> * Url  : https://salsa.debian.org/kaction/build-alternati
> ve
> 

How well tested is the package? From a quick look at the Debianization:


Package: build-alternative
Architecture: all
Depends:
 ${misc:Depends},
 dietlibc-dev (>= 0.34~cvs20160606-3) [alpha amd64 arm64 armeb armel armhf hppa 
i386 mips mipsel mips64el powerpc powerpcspe ppc64 ppc64el s390x sparc64 x32],


That combination is explicitly forbidden by Policy, and will not
produce a useful result. (See https://www.debian.org/doc/debian-policy/
ch-relationships.html#syntax-of-relationship-fields , specifically the
paragraph beginning "[f]or binary relationship fields".)

Regards,

Adam

Bug#696634: Replace %m by %M?

[Mathieu Parent]

Hi,

smb.conf manpage has:

%m
the NetBIOS name of the client machine (very useful). This parameter
is not available when Samba listens on port 445, as clients no longer
send this information. If you use this macro in an include statement
on a domain that has a Samba domain controller be sure to set in the
[global] section smb ports = 139. This will cause Samba to not listen
on port 445 and will permit include functionality to function as it
did with Samba 2.x.

%M
the Internet name of the client machine.

So maybe replace %m by %M? (Once buster is released).

Also smb.conf proposes:
Example: log file = /usr/local/samba/var/log.%m

So, what is the correct answer?

Regards

-- 
Mathieu Parent

Bug#888202: stretch->buster: reminder that kernel should be >= 3.2 before upgrade

[Justin B Rye]

Paul Gevers wrote:
> I have started to go through reports against the release-notes, to be
> ready when we release.

That's good.  I've done my own initial trial-run upgrade and found
absolutely nothing to report.

> diff --git a/en/issues.dbk b/en/issues.dbk
> index 20122d3e..706266bf 100644
> --- a/en/issues.dbk
> +++ b/en/issues.dbk
> @@ -219,6 +219,20 @@ information mentioned in .
>  
>
>  
> +  
> +
> +glibc requires linux kernel 3.2 or higher

That should definitely be "Linux" with a capital L; and at the start
of a title I'd also expect to see "Glibc".
   Glibc requires Linux kernel 3.2 or higher

> +
> +  Starting with glibc 2.26, Linux
> +  kernel 3.2 or later is required. The  +  role="package">libc6 preinst has a check and aborts the
> +  installation if it is not the case to avoid completely breaking the
> +  system. That said it will leave the upgrade unfinished. Please update 
> the
> +  kernel before starting the system upgrade if the system still runs a
> +  kernel before 3.2.

The wording could be better.  I would suggest

 Starting with glibc 2.26, Linux
 kernel 3.2 or later is required. The preinst for libc6 performs a check, and if this fails
 then to avoid completely breaking the system it will abort the package
 installation, which will leave the upgrade unfinished. If the system
 is running a kernel older than 3.2, please update it before starting
 the distribution upgrade.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#922647: systemd --user no longer running

[Eduard Bloch]

Package: libpam-systemd
Version: 240-5
Severity: normal

Hi,

a few days ago some user services started failed - I mainly noticed that 
pulseaudio was no longer available.
This looked very strange, and while checking other systems, I saw that
"systemd --user" is not launched, which would have started pa and some
other user-session daemons.

So I started looking around, what "systemd --user" doing and how it is
started? Here, the first issue emerges. The manual explains --user but
a) does not tell you who/what is supposed to run this
b) in case you run systemd --user manually, it aborts with 
"Trying to run as user instance, but $XDG_RUNTIME_DIR is not set."
This does not help me at all - how shall a user guess where it's coming
from and how this is required for --user? There is NO explanation or
hint in the manpage.

Ok, so I guess that it must be some special thing triggered by login.
Which probably means pam. So I found libpam-systemd by looking through
the package list. And the manpage is interesting. But nothing tells me
what might be going wrong when the thing is NOT spawning systemd--user.
So I checked a few hints in the "SEE ALSO" section, like logind.conf(5),
and still nothing tells me how to debug a problem where systemd --user
is not run.

I checked the journal, and still cannot find much about/from PAM there.
And the only matches for /login/ are:

| Feb 18 19:54:58 zombie systemd[1]: Condition check resulted in getty on 
tty2-tty6 if dbus and logind are not available being skipped.

This phrase I not understand. Missing a comma somewhere? Missing some 
background explanation for regular users? Is this my problem and if yes, what 
to do about it?

The rest looks harmless:

| Feb 18 19:54:58 zombie systemd-logind[996]: New seat seat0.
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event9 (Power Button)
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event8 (Power Button)
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event0 (Microsoft Natural® Ergonomic Keyboard 4000)
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event1 (Microsoft Natural® Ergonomic Keyboard 4000)
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event2 (A4TECH USB Device Keyboard)
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event3 (A4TECH USB Device System Control)
| Feb 18 19:54:58 zombie systemd-logind[996]: Watching system buttons on 
/dev/input/event4 (A4TECH USB Device Consumer Control)
| Feb 18 19:55:00 zombie systemd-logind[996]: New session c1 of user lightdm.
| Feb 18 19:55:09 zombie systemd-logind[996]: Removed session c1.

Still does not tell me much if I don't know what to look for. There are
no exceptions/error/hints which would look somehow linked to login
sequence problems.

Any ideas?

NOTE: this issue might be related to #921687 because it started at
approximately the same time.

Best regards,
Eduard.

-- 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.7 (SMP w/12 CPU cores)
Kernel taint flags: 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/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libpam-systemd depends on:
ii  dbus1.12.12-1
ii  libc6   2.28-7
ii  libpam-runtime  1.3.1-5
ii  libpam0g1.3.1-5
ii  systemd 240-5
ii  systemd-sysv240-5

libpam-systemd recommends no packages.

libpam-systemd suggests no packages.

-- no debconf information

Bug#896468: [Pkg-javascript-devel] Bug#896468: Bug#896468: libjs-chartjs: Please upload newer versions

[Paul Gevers]

Hi Pirate,

On 17-02-2019 11:51, Pirate Praveen wrote:
> Thanks Paul for testing. The missing dependencies were treated as
> external dependencies by rollup (webpack would give an error), would
> have worked in node, but not in browser. I embedded the missing
> dependencies and also used rollup-plugin-node-resolve to include all
> dependencies in the bundle. So please test 2.7.3+dfsg-2 and confirm if
> it is working as expected (for gitlab, I still don't use the packaged
> version, so can't really test now).
> 
> I can now see 'function getRgba(string) {' in the built bundle.
> 
>> Also the file looks quite different, but I guess that is to be expected
>> due to build system differences.
> 
> As long as it is working as expected, the exact match is not required.
> Each build tool has their on signature styles for bundling.

I went ahead and uploaded your version to my PPA for Ubuntu/Cosmic as
there are multiple people tracking Cacti from there (so it could be
tested). However, it FTBFS with the message below. I expect this is a
versioned dependency issue. Do you happen to know which one or how to
debug it?

Paul

https://launchpadlibrarian.net/411721887/buildlog_ubuntu-cosmic-amd64.node-chart.js_2.7.3+dfsg-2~ppa1c_BUILDING.txt.gz

rollup  -c debian/rollup.config.js
[!] TypeError: Cannot read property 'declarations' of undefined
TypeError: Cannot read property 'declarations' of undefined
at loop (/usr/lib/nodejs/rollup/dist/rollup.js:2532:26)
at Node.render (/usr/lib/nodejs/rollup/dist/rollup.js:2583:59)
at Module.render (/usr/lib/nodejs/rollup/dist/rollup.js:3187:9)
at orderedModules.forEach.module
(/usr/lib/nodejs/rollup/dist/rollup.js:4883:25)
at Array.forEach ()
at Promise.resolve.then (/usr/lib/nodejs/rollup/dist/rollup.js:4882:24)
at 
at process._tickCallback (internal/process/next_tick.js:188:7)
at Function.Module.runMain (module.js:695:11)
at startup (bootstrap_node.js:191:16)

make[1]: *** [debian/rules:8: override_dh_auto_build] Error 1



signature.asc
Description: OpenPGP digital signature

Bug#922646: cadabra FTCBFS: wrong pkg-config/strip

[Helmut Grohne]

Source: cadabra
Version: 1.46-6
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

cadabra fails to cross build from source. For some reason, it calls
pkg-config from Makefile.in. Specifically, the wrong pkg-config after
./configure detected the right one and thus it uses the wrong flags
after ./configure detected the right ones. Instead, the values detected
by ./configure should be propagated to the relevant Makefiles. It also
runs the wrong strip. Stripping is generally a bad idea, because it
breaks DEB_BUILD_OPTIONS=nostrip as well as generating -dbgsym packages
beyond breaking cross compilation. The attached patch fixes both and
should be upstreamable. Please consider applying it.

Helmut
--- cadabra-1.46.orig/src/Makefile.in
+++ cadabra-1.46/src/Makefile.in
@@ -1,5 +1,9 @@
 
 MACTEST= @MAC_OS_X@
+modglue_CFLAGS = @modglue_CFLAGS@
+modglue_LIBS = @modglue_LIBS@
+sigc_CFLAGS = @sigc_CFLAGS@
+sigc_LIBS = @sigc_LIBS@
 
 .PHONY: all tests modules
 
@@ -21,7 +25,7 @@
 #modules/xperm_no_nests.o 
 
 SRCS  = `find . -name "*.cc"`
-MCFLAGS   = @CFLAGS@ --std=c++11 -I. -I@top_srcdir@/src `pkg-config modglue --cflags` $(CPPFLAGS)
+MCFLAGS   = @CFLAGS@ --std=c++11 -I. -I@top_srcdir@/src $(modglue_CFLAGS) $(CPPFLAGS)
 TIMESTAMP = -D"RELEASE=\"${RELEASE}\"" -D"DATETIME=\"`dpkg-parsechangelog -l../debian/changelog -SDate`\"" -DHOSTNAME=\"debian\"
 
 
@@ -42,10 +46,10 @@
 
 ifeq ($(strip $(MACTEST)),)
 cadabra: $(OBJS) $(MOBJS)
-	@CXX@ -o cadabra ${LDFLAGS} -Wl,--as-needed $+ `pkg-config modglue --libs` -lgmpxx -lpcrecpp -lgmp
+	@CXX@ -o cadabra ${LDFLAGS} -Wl,--as-needed $+ $(modglue_LIBS) -lgmpxx -lpcrecpp -lgmp
 else
 cadabra: $(OBJS) $(MOBJS)
-	@CXX@ -o cadabra ${LDFLAGS} -Wl,-dead_strip_dylibs $+ `pkg-config modglue --libs` -lgmpxx -lpcrecpp -lgmp
+	@CXX@ -o cadabra ${LDFLAGS} -Wl,-dead_strip_dylibs $+ $(modglue_LIBS) -lgmpxx -lpcrecpp -lgmp
 endif
 
 #`pkg-config glib-2.0 --libs` 
@@ -55,13 +59,13 @@
 	rm -f main.o
 	@CXX@ -Wall -g ${MCFLAGS} ${TIMESTAMP} -DSTATICBUILD -c -o main.o main.cc
 ifeq ($(strip $(MACTEST)),)
-	@CXX@ -o cadabra -static $+ ${LDFLAGS} `pkg-config modglue --libs` -lmodglue \
+	@CXX@ -o cadabra -static $+ ${LDFLAGS} $(modglue_LIBS) \
  -lgmpxx -lgmp -lpcrecpp -lpcre \
- `pkg-config sigc++-2.0 --libs` -lsigc-2.0 -lutil
+ $(sigc_LIBS) -lutil
 
 else
 	export MACOSX_DEPLOYMENT_TARGET=10.3
-	@CXX@ -o cadabra $+ ${LDFLAGS} `pkg-config modglue --libs` \
+	@CXX@ -o cadabra $+ ${LDFLAGS} $(modglue_LIBS) \
   -lgmp -lgmpxx -lpcre++ -lpcre -lexpect
 endif
 
@@ -81,9 +85,9 @@
 
 test_lie: test_lie.o modules/lie.o
 ifeq ($(strip $(MACTEST)),)
-	@CXX@ -o test_lie test_lie.o modules/lie.o `pkg-config --libs modglue`
+	@CXX@ -o test_lie test_lie.o modules/lie.o $(modglue_LIBS)
 else
-	@CXX@ -o test_lie test_lie.o modules/lie.o `pkg-config --libs modglue`
+	@CXX@ -o test_lie test_lie.o modules/lie.o $(modglue_LIBS)
 endif
 
 tree_regression_tests: tree_regression_tests.o 
@@ -146,9 +150,6 @@
 # Installation and cleanup.
 
 install:
-ifeq ($(strip $(MACTEST)),)
-	strip cadabra
-endif
 #	strip -S cadabra
 #endif
 	@INSTALL@ -m 0755 -d ${DESTDIR}@prefix@/bin
--- cadabra-1.46.orig/gui/Makefile.in
+++ cadabra-1.46/gui/Makefile.in
@@ -2,14 +2,20 @@
 .PHONY: all 
 
 MACTEST= @MAC_OS_X@
+modglue_CFLAGS = @modglue_CFLAGS@
+modglue_LIBS = @modglue_LIBS@
+gtkmm_CFLAGS = @gtkmm_CFLAGS@
+gtkmm_LIBS = @gtkmm_LIBS@
+pango_CFLAGS = @pango_CFLAGS@
+xmlpp_LIBS = @xmlpp_LIBS@
 
 all: xcadabra 
 
 static: xcadabra_static
 
 OBJS   = help.o widgets.o window.o main.o ../src/stopwatch.o
-CFLAGS = -O2 -I. -I@top_srcdir@/include `pkg-config modglue --cflags` `pkg-config --cflags gtkmm-2.4` \
- `pkg-config --cflags pango` $(CPPFLAGS)
+CFLAGS = -O2 -I. -I@top_srcdir@/include $(modglue_CFLAGS) $(gtkmm_CFLAGS) \
+ $(pango_CFLAGS) $(CPPFLAGS)
 SRCS   = `find . -name "*.cc"`
 TIMESTAMP = -D"RELEASE=\"${RELEASE}\"" -D"DATETIME=\"`date | sed -e 's/  / /'`\"" -DHOSTNAME=\"`hostname`\"
 
@@ -19,20 +25,17 @@
 main.o: $(OBJS) Makefile
 
 xcadabra: $(OBJS)
-	@CXX@ -o xcadabra $+ `pkg-config modglue --libs` `pkg-config --libs gtkmm-2.4` -lpcrecpp $(LDFLAGS) $(CPPFLAGS)
+	@CXX@ -o xcadabra $+ $(modglue_LIBS) $(gtkmm_LIBS) -lpcrecpp $(LDFLAGS) $(CPPFLAGS)
 
 xcadabra_static: $(OBJS)
-	@CXX@ -o xcadabra -static $+  -L@prefix@/lib `pkg-config modglue --libs` \
-`pkg-config --libs gtkmm-2.4` `pkg-config libxml++-2.6` \
+	@CXX@ -o xcadabra -static $+  -L@prefix@/lib $(modglue_LIBS) \
+$(gtkmm_LIBS) $(xmlpp_LIBS) \
 -lpthread -lexpat $(LDFLAGS)
 
 test_texit: texit.o test_texit.o
-	@CXX@ -o test_texit `pkg-config modglue --libs` `pkg-config --libs gtkmm-2.4` $+ 
+	@CXX@ -o test_texit $(modglue_LIBS) $(gtkmm_LIBS) $+ 
 
 install:
-ifeq ($(strip $(MACTEST)),)
-	strip xcadabra
-endif
 	install -d ${DESTDIR}@prefix@/bin
 	install -m 0755 xcadabra 

Bug#922645: netcdf-fortran: Please change build-depends to gfortran | fortran-compiler

[Alastair McKinstry]

Source: netcdf-fortran
Severity: wishlist

Dear Maintainer,

Please change the build-depends from "gfortran" to "gfortran | 
fortran-compiler".
This enables netcdf-fortan to be built with flang.

Thanks
Alastair McKinstry

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

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

Bug#695137: Reproducing " samba4-common-bin: failed drs replication"

[Mathieu Parent]

Hello,

Are you able to reproduce this bug on latest jessie
(2:4.2.14+dfsg-0+deb8u11) or latest stretch (2:4.5.16+dfsg-1)? This
would be good if you tested it on latest buster (2:4.9.4+dfsg-3, -2 is ok).

Regards

-- 
Mathieu Parent

Bug#906696: flash-kernel: Please add an entry for the Rock64

[Vagrant Cascadian]

On 2019-02-18, Josua Mayer wrote:
> Am 27.08.18 um 19:03 schrieb Vagrant Cascadian:
>> All arm64 linux dtbs are in sub-dirs, flash-kernel supports them in
>> sub-dirs, and u-boot should generally just append the value of fdtfile
>> to whatever search path and look for it there.
>
> How does flash-kernel support creating those sub directories?
> It seems to me that it will search for dtbs in sub directories, but then
> install them at the root level :(
...
> I didn't look any further - but it seems to me we need a way to have
> those sub-directories.

It's been a while since I've looked, but recent flash-kernel versions
should create both the sub-dir and symlink in the non-subdir location,
as long as you pass the subdir in the flash-kernel database.


live well,
  vagrant

Bug#803941: Reproducing " samba: cp and cat return an endless stream of 0s when reading a file on a samba share"

[Ian Munsie]

This looks to be fixed :)

Server running Debian Stretch with Samba 2:4.5.16+dfsg-1 and client
running Debian Stretch with cifs-utils 2:6.7-1:

[N] ian@draal~> mount /mnt/nas
[I] ian@draal~> cd /mnt/nas/
[I] ian@draal/m/nas> echo foo > bar
[I] ian@draal/m/nas> cat bar | hexdump -Cv
  66 6f 6f 0a   |foo.|
0004

Cheers,
-Ian

Bug#692642: Reproducible?

[Mathieu Parent]

Hello,

Are you able to reproduce this bug on latest jessie
(2:4.2.14+dfsg-0+deb8u11) or latest stretch (2:4.5.16+dfsg-1)? This
would be good if you tested it on latest buster (2:4.9.4+dfsg-3, -2 is ok).

Regards

-- 
Mathieu Parent

Bug#888202: stretch->buster: reminder that kernel should be >= 3.2 before upgrade

[Paul Gevers]

Dear debian-l10n-english,

I have started to go through reports against the release-notes, to be
ready when we release.

On 18-02-2019 13:17, Baptiste Jammet wrote:
> Dixit Paul Gevers, le 16/02/2019 :
>> I have prepared the attached patch that I intend to commit if nobody
>> objects to the wording in a couple of days. It adds this description to
>> the issues list.
> Don't hesitate to Cc debian-l10n-english if you need reviews.

Doing so now. My new patch is attached for the list.

Paul
From d1e59824d8bc8adc6f477449a9111de4f06ef69f Mon Sep 17 00:00:00 2001
From: Paul Gevers 
Date: Mon, 18 Feb 2019 20:54:28 +0100
Subject: [PATCH] Add note about glibc requiring Linux >= 3.2

Closes: 888202
---
 en/issues.dbk | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/en/issues.dbk b/en/issues.dbk
index 20122d3e..706266bf 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -219,6 +219,20 @@ information mentioned in .
 
   
 
+  
+
+glibc requires linux kernel 3.2 or higher
+
+  Starting with glibc 2.26, Linux
+  kernel 3.2 or later is required. The libc6 preinst has a check and aborts the
+  installation if it is not the case to avoid completely breaking the
+  system. That said it will leave the upgrade unfinished. Please update the
+  kernel before starting the system upgrade if the system still runs a
+  kernel before 3.2.
+
+  
+
 
 
 
-- 
2.20.1



signature.asc
Description: OpenPGP digital signature

Bug#919373: kannel: FTBFS with mariadb-10.3: gwlib/utils.c:602:14:

[Jonas Smedegaard]

Quoting Faustin Lammler (2019-01-17 22:17:07)
> Control: forwarded -1 https://redmine.kannel.org/issues/795
> 
> Hi,
> This seems to be a bug (see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919395#36):
> 
> > error: 'MYSQL_SERVER_VERSION' undeclared
> > 
> > this looks like a bug. MYSQL_SERVER_VERSION is documented here:
> > https://dev.mysql.com/doc/refman/5.5/en/c-api-server-client-versions.html

Thanks, Andreas and Faustin.

In case others get confused same as me: This seems to be a but not in 
kannel but in mariadb, in that it fails to implement the MySQL spec.


 - Jonas

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

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


signature.asc
Description: signature

Bug#922644: mariadb-server-10.3: Unable to reinstall

[Janusz S. Bień]

Package: mariadb-server-10.3
Version: 1:10.3.12-2
Severity: important

Dear Maintainer,

When I try to reinstall the package, I get

--8<---cut here---start->8---
Setting up mariadb-server-10.3 (1:10.3.12-2) ...
dpkg: error processing package mariadb-server-10.3 (--configure):
 installed mariadb-server-10.3 package post-installation script subprocess 
returned error exit status 7
--8<---cut here---end--->8---

I don't use the MySQL directly, I'm just a user of MythTV which depends
on MariaDB. The recent change of the Internet provider resulted in the
change of the IP of my home computer which hosts the server and MythTV
clients stopped working. Not long ago a superficially similar problem
was solved by reinstalling the package, so I wanted to try this again.

BTW, I'm unable to login directly to the database, but the reason may be
independent of the problem described above (last time I have done it was
several years ago when diagnosing a different problem with MythTV).

Best regards

Janusz


-- 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)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-10.3 depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.70
ii  galera-3  25.3.25-1
ii  gawk  1:4.2.1+dfsg-1
ii  iproute2  4.20.0-2
ii  libc6 2.28-6
ii  libdbi-perl   1.642-1+b1
ii  libpam0g  1.1.8-4
ii  libssl1.1 1.1.1a-1
ii  libstdc++68.2.0-20
ii  lsb-base  10.2018112800
ii  lsof  4.91+dfsg-1
ii  mariadb-client-10.3   1:10.3.12-2
ii  mariadb-common1:10.3.12-2
ii  mariadb-server-core-10.3  1:10.3.12-2
ii  passwd1:4.5-1.1
ii  perl  5.28.1-4
ii  psmisc23.2-1
ii  rsync 3.1.3-5
ii  socat 1.7.3.2-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages mariadb-server-10.3 recommends:
ii  libhtml-template-perl  2.97-1

Versions of packages mariadb-server-10.3 suggests:
ii  mailutils [mailx]  1:3.5-2
pn  mariadb-test   
pn  netcat-openbsd 
pn  tinyca 

-- Configuration Files:
/etc/mysql/mariadb.conf.d/50-server.cnf changed:
[server]
[mysqld]
user= mysql
pid-file= /var/run/mysqld/mysqld.pid
socket  = /var/run/mysqld/mysqld.sock
port= 3306
basedir = /usr
datadir = /var/lib/mysql
tmpdir  = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
% bind-address  = 192.168.1.11
bind-address= 192.168.0.10
key_buffer_size = 16M
max_allowed_packet  = 16M
thread_stack= 192K
thread_cache_size   = 8
myisam_recover_options  = BACKUP
query_cache_limit   = 1M
query_cache_size= 16M
log_error = /var/log/mysql/error.log
expire_logs_days= 10
max_binlog_size   = 100M
character-set-server  = utf8mb4
collation-server  = utf8mb4_general_ci
[embedded]
[mariadb]
[mariadb-10.1]


-- debconf information:
  mariadb-server-10.3/nis_warning:
  mariadb-server-10.3/old_data_directory_saved:
  mariadb-server-10.3/postrm_remove_databases: false

-- 
 ,   
Janusz S. Bien
emeryt (emeritus)
https://sites.google.com/view/jsbien

Bug#921704: tortoisehg: uninstallable with mercurial 4.9

[Ludovico Cavedon]

On Mon, Feb 18, 2019 at 11:39 AM Julien Cristau  wrote:

> Well it's going to be delayed by virtue of making tortoisehg and hg-git
> uninstallable anyway, for now.  Is there an ETA on a tortoise 4.9
> release?
>
>
Let me check with upstream.

Thanks,
Ludovico

Bug#921704: tortoisehg: uninstallable with mercurial 4.9

[Julien Cristau]

On Mon, Feb 18, 2019 at 11:07:59 -0800, Ludovico Cavedon wrote:

> On Mon, Feb 18, 2019 at 10:58 AM Julien Cristau  wrote:
> 
> > > Thank you for the bug report. TortoiseHg 4.9 has not been released yet.
> > >
> > There's no need for the tags, and this will affect buster when mercurial
> > migrates so they're wrong anyway.
> >
> 
> I see.
> Would it make sense to delay the migration of mercurial until an updated
> tortoisehg is migrated, so we avoid removing tortoisehg from testing, given
> the upcoming release?
> 
Well it's going to be delayed by virtue of making tortoisehg and hg-git
uninstallable anyway, for now.  Is there an ETA on a tortoise 4.9
release?

Cheers,
Julien