Bug#907492: pam: diff for NMU version 1.1.8-3.9

[Niels Thykier]

Steve Langasek:
> Hi Niels,
> 
> [...]
>> @@ -1,3 +1,20 @@
>> +pam (1.1.8-3.9) unstable; urgency=medium
>> +
>> +  * Non-maintainer upload.
>> +
>> +  [ Niels Thykier ]
>> +  * Enable dh_dwz to reduce the size of the dbgsym files.
> 
> What is the NMU rationale for this change?  There does not appear to be a
> corresponding bug report, and there is certainly not one referenced in the
> changelog.

The rationale is *exactly* what is says on the tin: Smaller dbgsym files
(including the debs).  Nothing more, nothing less.

> This looks likely to cause build failures in some circumstances,
> given the lack of corresponding build-dependency changes.
> 

The debhelper package pulls the relevant dependency (like it does for
autoreconf and autotools-dev for two other helpers)

> I am not enthusiastic about pam being opted in to non-default debhelper
> settings via NMU.
> 

FTR, it is the default in debhelper compat 12 (just as note that it is
becoming the default for packages that bump their compat)

>> [...]
> 
>> +  [ Helmut Grohne ]
>> +  * Convert DEB_BUILD_PROFILE=stage1 to DEB_BUILD_PROFILES=pkg.pam.noaudit.
>> +(Closes: #907492)
> 
> Though I had not followed up on the bug report, I disagree with this change
> and thus nack this NMU.  I do not agree that it is preferable to use an
> explicit 'pkg.pam.noaudit' profile name instead of 'stage1'.  The pam
> package was an early adopter of build profiles precisely for the purpose of
> archive bootstrapping, and for archive bootstrapping what is interesting is
> NOT that the package is built without audit, what is interesting is that it
> is a bootstrap build.  The fact that audit is the specific package being
> excluded is a point-in-time implementation detail that should NOT be
> exposed.
> 
> Please withdraw this NMU.
> 
>> [...]
> 
> Thanks,
> 

I have withdrawn my NMU as requested.

I kindly ask that you at least correct debian/rules to use the *correct*
variable in debian/rules for buster (or allow me to do so), so
bootstrapers do not have monkey patch the pam sources to perform the
bootstrap.  I.e. change DEB_BUILD_PROFILE -> DEB_BUILD_PROFILES (and
then we can leave the actual profile at "stage1" for now.

Thanks,
~Niels

Bug#918000: openmpi postinst failure due to missing space in script

[Mo Zhou]

Package: libopenmpi3
Version: 3.1.3-7
Severity: serious

Dear maintainer,

You missed a space in the script, which resulted in


The following packages will be upgraded:
  libopenmpi3 openmpi-common
2 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
210 not fully installed or removed.
Need to get 0 B/2338 kB of archives.
After this operation, 16.4 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 168982 files and directories currently installed.)
Preparing to unpack .../libopenmpi3_3.1.3-7_amd64.deb ...
Unpacking libopenmpi3:amd64 (3.1.3-7) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file 
or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old libopenmpi3:amd64 package post-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive 
/var/cache/apt/archives/libopenmpi3_3.1.3-7_amd64.deb (--unpack):
 there is no script in the new version of the package - giving up
Preparing to unpack .../openmpi-common_3.1.3-7_all.deb ...
Unpacking openmpi-common (3.1.3-7) over (3.1.3-5) ...
rm: cannot remove '/usr/lib/x86_64-linux-gnu/fortran/gfortran-8#': No such file 
or directory
rm: cannot remove 'End': No such file or directory
rm: cannot remove 'automatically': No such file or directory
rm: cannot remove 'added': No such file or directory
rm: cannot remove 'section': No such file or directory
dpkg: warning: old openmpi-common package post-removal script subprocess 
returned error exit status 1
dpkg: trying script from the new package instead ...
dpkg: error processing archive 
/var/cache/apt/archives/openmpi-common_3.1.3-7_all.deb (--unpack):


 cat /var/lib/dpkg/info/libopenmpi3:amd64.postrm | tail -n1
[ -d /usr/lib/$multiarch/fortran/$base ] && rm 
/usr/lib/$multiarch/fortran/$cmplr# End automatically added section

 ^missing space here

Bug#917613: Regression: Thunderbird dosen't open ("already running" error)

[Carsten Schoenert]

Hello Peter,

Am 01.01.19 um 16:13 schrieb Peter Tuharsky:
> Finally I found the culprit. It was apparmor!
> 
> I have never intentionally done anything with it, but upgrading kernel 
> version from 4.9 to 4.18 (due to some kernel 4.9 security upgrade 
> problem that freezes my computer), it must have enabled apparmor by 
> default or so.

the default of the Thunderbird package is to *not* enable the Apparmor
profile on first time installation and also on updating.
On exception on updates, if the user had activate the AA profile in the
past the package update does not deactivate it.

So I can just think of an active setting to use the AA profile of
Thunderbird which got really active again with the re-installation of
AppArmor.

> And since I have my home folder symlinked to other drive, and apparmor 
> does not support symlinks, it denied Thunderbird the access to its lock 
> file (and other files as well).

This makes your report a duplicate of #882218 [1].

> After I manually added the real drive path of my profile in 
> /etc/apparmor.d/usr.bin.thunderbird, it now works.

This will get overriden by the next update of the Thunderbird package,
head down to the bottom of the profile, you well see the following:

>   # Site-specific additions and overrides. See local/README for details.
>   #include 
> }

So this is the right place for needed modifications. Have a look at
/etc/apparmor.d/local/README for further information. If ypu have some
useful additions for the file
/usr/share//doc/thunderbird/README.apparmor then please try to write it
down and let us know, the READMEs can always get improvements.

> Should I encounter more problems with other apps, I may as well 
> completely disable apparmor in grub config.

Hmm, if you want to disable AppArmor completely why not remove the
package then?

I know it's not the answer you probably want to hear but reporting the
problems would be better. :)
The AppArmor people in Debian are a really responsive team.

[1] https://bugs.debian.org/882218

-- 
Regards
Carsten Schoenert

Bug#878678: [Reportbug-maint] Bug#878678: reportbug: [PATCH] Store SMTP password with libsecret if available

[Ville Skyttä]

control: tags +security

Oh, that's highly unfortunate, plaintext passwords in config files are not
good from security point of view. How about a slightly modified version
that uses libsecret only if available _and_ explicitly configured to do so?

Bug#917999: httraqt FTCBFS: uses TRY_RUN

[Helmut Grohne]

Source: httraqt
Version: 1.4.9-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

httraqt fails to cross build from source, because it uses TRY_RUN. In
this case, check_type_size can be used. It's much easier to use and
supports cross compilation. Please consider applying the attached patch.

Helmut

--- httraqt-1.4.9.orig/cmake/HTTRAQTWordSize.cmake
+++ httraqt-1.4.9/cmake/HTTRAQTWordSize.cmake
@@ -1,11 +1,10 @@
+include(CheckTypeSize)
+
 # Detect the word-size for the current platform ...
 MESSAGE(STATUS "checking the width of int* for this platform")
 
-TRY_RUN(
-HTTRAQT_PLATFORM_SIZE_TYPE
-HTTRAQT_PLATFORM_SIZE_TYPE_COMPILE
-${CMAKE_CURRENT_BINARY_DIR}
-${CMAKE_CURRENT_SOURCE_DIR}/configuration/size_type.cpp)
+check_type_size("int *" HTTRAQT_INT_PTR BUILTIN_TYPES_ONLY)
+MATH(EXPR HTTRAQT_PLATFORM_SIZE_TYPE "8*${HTTRAQT_INT_PTR}")
 
 MESSAGE(STATUS "  int* is ${HTTRAQT_PLATFORM_SIZE_TYPE} bits")
 
--- httraqt-1.4.9.orig/configuration/size_type.cpp
+++ /dev/null
@@ -1,7 +0,0 @@
-// #include 
-
-int main(int argc, char* argv[])
-{
-return sizeof(int*) * 8;
-}
-

Bug#917998: cdbs: qmake.mk should support cross building

[Helmut Grohne]

Package: cdbs
Version: 0.4.158
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:jacktrip

cdbs's qmake.mk defaults to using plain qmake. That's the right thing to
do for native builds, but for cross builds it should be prefixed (just
like gcc, binutils, pkg-config, etc.). The attached patch implements
that. Please consider applying it.

Helmut
diff --minimal -Nru cdbs-0.4.158/1/class/qmake.mk.in 
cdbs-0.4.158+nmu1/1/class/qmake.mk.in
--- cdbs-0.4.158/1/class/qmake.mk.in2016-06-10 12:36:00.0 +0200
+++ cdbs-0.4.158+nmu1/1/class/qmake.mk.in   2019-01-02 08:00:03.0 
+0100
@@ -31,7 +31,11 @@
 DEB_MAKE_INSTALL_TARGET = install INSTALL_ROOT=$(DEB_DESTDIR)
 DEB_MAKE_CLEAN_TARGET = distclean
 
+ifeq (,$(cdbs_crossbuild))
 QMAKE ?= qmake
+else
+QMAKE ?= $(DEB_HOST_GNU_TYPE)-qmake
+endif
 
 ifneq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
 DEB_QMAKE_CONFIG_VAL ?= nostrip
diff --minimal -Nru cdbs-0.4.158/debian/changelog 
cdbs-0.4.158+nmu1/debian/changelog
--- cdbs-0.4.158/debian/changelog   2018-09-23 14:17:02.0 +0200
+++ cdbs-0.4.158+nmu1/debian/changelog  2019-01-02 08:00:45.0 +0100
@@ -1,3 +1,10 @@
+cdbs (0.4.158+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use a cross qmake for cross building. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 02 Jan 2019 08:00:45 +0100
+
 cdbs (0.4.158) unstable; urgency=medium
 
   * Fix update Maintainer address.

Bug#916738: nvidia-alternative: Depends on a non-existent version of glx-alternative which breaks upgrade path.

[ewe2]

Thanks Joerg, I've upgraded successfully and everything seems to be
working fine, I'm happy for the bug to be closed now.

On Wed, 26 Dec 2018 at 19:54, Joerg Schuetter  wrote:
>
> Version 0.9.0 of glx-alternative-{nvidia,mesa} are available since a few 
> days. Installation of nvidia packages 410.78-2 went smooth.
>
>
> --
> Best Regards
>   Joerg Schuetter
> ___
> pkg-nvidia-devel mailing list
> pkg-nvidia-de...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-nvidia-devel



-- 

I love deadlines. I love the whooshing noise they make as they go by.

Bug#917997: worklog: Left bracket is allowed in description, but it isn't escaped, and so breaks the parser

[Jon Daley]

Package: worklog
Version: 1.8-7
Severity: normal

I guess I've never typed a "[" in all the years of using this package.

Today, I had a typo, and accidentally entered a left bracket, and the program
chokes on it, because it is trying to parse the time field, and as a result
ignores that line completely.  It does print an error on program exit.

I don't know if escaping the bracket, or simply not allowing brackets in
the descriptions is easier.  I don't know when I'll get around to looking
at the code, but I would probably aim at eliminating brackets from the
description field as the easiest solution.


-- System Information:
Debian Release: 6.0.10
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages worklog depends on:
ii  libc6   2.11.3-4+deb6u11 Embedded GNU C Library: Shared lib
ii  libncurses5 5.7+20100313-5   shared libraries for terminal hand

worklog recommends no packages.

worklog suggests no packages.

-- no debconf information

Bug#803197: SOGo isn't the only victim, cups breaks as well

[Ryan Tandy]

Hi Lukas, or anyone else interested,

I have pushed the patch to git master. It would be great if you could 
test it in your environment and confirm everything is OK.


https://salsa.debian.org/openldap-team/openldap/commit/2b2b26f4b52c10ceaa174a935370acdaf12fd952

I can compile packages for stretch or buster if that would help.

thanks,
Ryan

Bug#917995: debian-policy: drop section 1.6 Translations

[Sean Whitton]

Hello Ansgar,

On Wed 02 Jan 2019 at 12:29pm +0900, Ansgar Burchardt wrote:

> I hereby propose to drop section 1.6 Translations and the following
> sentence: "When translations of this document into languages other
> than English disagree with the English text, the English text takes
> precedence."

(Procedural note: while of course discussion of section 1.6 is welcome,
it's a matter for Policy Editor discretion exactly how translations are
handled.)

> If it is wrongly translated, then the English text probably isn't
> clear enough (otherwise the translation would have the same meaning)
> and would need to be clarified anyway to avoid being ambigious.  Even
> if not, the same process can be used to clarify the meaning of
> non-English versions.
>
> There should be no need to put one language over others.

The thought is that that English text receives much greater scrunity,
both because patches get reviewed by several people, and because more
people read it.  So it is much less likely to have mistakes that
something that a single person translated.

Any DD can commit a translation to the repo and it will get published,
basically.  Not so for changes to the English text.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#916034: marked as done (sl-modem-dkms: module FTBFS for 4.18.0-3-amd64, 4.9.0-8-amd64)

[أحمد المحمودي]

Hello Andreas,

On Wed, Jan 02, 2019 at 05:21:03AM +, Debian Bug Tracking System wrote:
> and subject line Bug#916034: fixed in sl-modem 2.9.11~20110321-14
> Changes:
>  sl-modem (2.9.11~20110321-14) unstable; urgency=medium
>  .
>[ Ondřej Nový ]
>* d/copyright: Change Format URL to correct one
>* d/changelog: Remove trailing whitespaces
>  .
>[ أحمد المحمودي (Ahmed El-Mahmoudy) ]
>* Remove old transitional sl-modem-source target
>* Modify support_linux3.diff patch to support linux >3.
>  Thanks to Ben Hutchings  (Closes: #916034)
>* Update standards version to 4.3.0, no changes needed
>* debian/control, debian/changelog: Remove empty lines
>* Bumped compat level to 12
---end quoted text---

Please build this package for i386 and upload.

Thanks.


-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#917656: libnet-server-mail-perl: FTBFS (failing tests)

[Xavier]

Le 02/01/2019 à 00:01, Dominic Hargreaves a écrit :
> On Tue, Jan 01, 2019 at 10:43:20PM +0100, Xavier wrote:
>> Control: reassign -1 perl-modules-5.28
>> Control: severity -1 normal
>>
>> Hi all,
>>
>> it seems that Net::SMTP->new() fails randomly when launched during
>> Net::server::Mail tests: $s is sometimes undefined after this:
>>
>>   my $s = Net::SMTP->new( $host, Port => $port, Hello => 'localhost' );
> 
> What does $@ contain when this happens?
> 
> I couldn't reproduce this myself using the attached, could you look
> at providing a reproducible test case?
> 
>> http://matrix.cpantesters.org/?dist=Net-Server-Mail+0.26 also shows that
>> this rarely happens since the release of 5.28.0 (1/22), never before.
>>
>> I added a workaround for now in libnet-server-mail-perl tests (warn and
>> return when $s is undefined).
> 
> (You probably want to log $@ in this case, too).
> 
> Cheers,
> Dominic.

Sadly I never succeed to reproduce this bug. I've only the FTBFS report
and one on CPAN:
 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917656
 *
http://www.cpantesters.org/cpan/report/19a89a8e-e1ee-11e8-afbf-aec3b07506ca

I'm going to upload a new patch with more logs

Bug#917909: [text-based installer] right-to-left writing direction broken

[Cyril Brulebois]

Hi,

And thanks for debugging this so quickly!

Samuel Thibault  (2018-12-31):
> Ah, it's 98fa157c758d ('bidi.patch: Look for libfribidi in multi-arch
> directory.'). In fribidi's udeb libfribidi.so.0 is in /lib, not
> /usr/lib/$MACH, is there really a reason for doing so?  I'd say we
> should move it there, i.e. the attached patch? 

I think we've mentioned in a few bug reports that shipping .so in m-a
paths wasn't needed/recommended, but the linker looks there so that
isn't an issue in the general case.

For packages with hardcoded paths like this one seems to have, updating
the udeb to match the paths used in the deb looks good to me.

> (which I could check as fixing the issue in the textual installer,
> without breaking the graphical installer). And we can probably
> backport it to Stretch.

That would be great, yes.

Thanks again.


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


signature.asc
Description: PGP signature

Bug#914607: Re-adding python-dfwinreg

[林上智]

Hi Hilko,

Hilko Bengen  於 2018年12月23日 週日 上午6:22寫道：
>
> Control: tag -1 pending
>
> I have just uploaded dfwinreg/20181214-2 to DELAYED/10 -- it will have
> to wait for python-dtfabric and python3-dtfabric to reach unstable.
>
> Cheers,
> -Hilko

Please feel free to add your name into the package maintainer if you want :)

SZ

Bug#917940: Reporting abuse (was: Bug#917940: installation-reports: Metztli Reiser4 Successful […])

[Cyril Brulebois]

Hi,

I'm now escalating this to the BTS administrators.

This person has been filing many bug reports against installation images
that aren't published or supported in any way by the Debian Installer
team. I've asked several times (#842382, #819470, #819484, #858849 at
least from a quick search in mutt) for such bug reports *not* to be
filed in the Debian BTS, but nothing changed…

Please advise how to deal with this situation, and/or take any actions
you think are needed.

Thanks for your time.


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


Jose R Rodriguez  (2019-01-01):
> Package: installation-reports
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- Package-specific info:
> 
> Boot method: ISO written to partition on Second SSD
> Image version: https://sourceforge.net/projects/metztli-reiser4/
> Date: December 26, 2018, 09:56.
> 
> Machine: Supermicro 8-core Intel® Xeon® Processor E3-1270 v6
> Partitions: 
> Filesystem Type 1K-blocksUsed Available Use% Mounted on
> udev   devtmpfs  16367576   0  16367576   0% /dev
> tmpfs  tmpfs  32763608928   3267432   1% /run
> /dev/sda5  reiser4  89636 6343376 215946260   3% /
> tmpfs  tmpfs 16381788   0  16381788   0% /dev/shm
> tmpfs  tmpfs 5120   0  5120   0% /run/lock
> tmpfs  tmpfs 16381788   0  16381788   0% /sys/fs/cgroup
> /dev/sda1  ext2472036   73322374343  17% /boot
> tmpfs  tmpfs  3276356   0   3276356   0% /run/user/1000
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [ ]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Install tasks:  [O]
> Install boot loader:[O]
> Overall install:[O]
> 
> Comments/Problems:
> 
> No CDROM available to customer, i.e., myself. Thus during acquisition of
> bare metal server I selected Debian 9 x64, which first SSD came
> formatted in ext4. I wanted Metztli Reiser4 but there was no provision
> for custom install image. 
> 
> I made a note of Address, Netmask, Gateway, and Nameserver. I noted, as
> well the disks had previously been initialized with MSDOS MBR.
> 
> On the second SSD I created a small 500MB initial partition which I
> formatted in ext2. I copied over Metztli Reiser4 onto that partition. I
> knew I had to install Metztli Reiser4 as expert, thus, following a hint
> from 'How to Boot Linux ISO Images Directly From Your Hard Drive' 
> < 
> https://www.howtogeek.com/196933/how-to-boot-linux-iso-images-directly-from-your-hard-drive/
>  >,
> by trial and error I wrote to /etc/grub.d/40_custom the following:
> 
> menuentry 'Metztli Reiser4 Expert install' {
> set isofile='metztli-reiser4.iso'
>   insmod gzio
>   insmod part_msdos
>   insmod ext2
>   insmod loopback
> loopback loop (hd1,msdos1)/ISOs/$isofile
> linux (loop)/linux priority=low vga=788 ---
> initrd (loop)/initrd.gz
> }
> 
> Executed with root privilege: update-grub
> Rebooted the remote server -- as I opened up an iKVM console. Booting
> proceeded until GRUB screen came about from which I selected my entry
> Metztli Reiser4 Expert install... i.e.,
> < https://metztli.it/blog/index.php/ixiptli/metztli-reiser4-sfrn-4-2 >
> the rest is history ;-)
> 
> I have since upgraded to Linux 4.18.0-3+reiser4.0.2-amd64
> -- 
> 
> Please make sure that the hardware-summary log file, and any other
> installation logs that you think would be useful are attached to this
> report. Please compress large files using gzip.
> 
> Once you have filled out this report, mail it to sub...@bugs.debian.org.
> 
> ==
> Installer lsb-release:
> ==
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="9 (stretch) - installer build 20181028-20:31"
> X_INSTALLATION_MEDIUM=netboot
> 
> ==
> Installer hardware-summary:
> ==
> uname -a: Linux tlaquimilolli 4.15.0-3+reiser4.0.2-amd64 #1 SMP Debian 
> 4.15.18-1+reiser4.0.2 (2018-04-21) x86_64 Metztli IT
> lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5918] 
> (rev 05)
> 

Bug#917941: Installation Buster on HP 17-by Notebook

[Cyril Brulebois]

Hi Bernhard,

And thanks for the report.

Bernhard  (2019-01-01):
> > 03:00.0 Network controller [0280]: Realtek Semiconductor Co., Ltd. 
> > RTL8821CE 802.11ac PCIe Wireless Network Adapter [10ec:c821]
> > Subsystem: Hewlett-Packard Company RTL8821CE 802.11ac PCIe Wireless 
> > Network Adapter [103c:831a]
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [O]
> Install boot loader:[O]
> Overall install:[O]
> 
> Comments/Problems:
> 
> During installation with Ethernet connection, everything was fine.
> Installation was done in Legacy-mode. Not in UEFI mode.
> 
> The current kernel don't support the WLAN interface.
> Please add support for the Realtek WLAN adapter RTL8821CE in kernel.

Wasn't that about a missing firmware? Could you please hit reply-all,
attaching the installer's syslog (stored under /var/log/installer/)?
Wild guess: This might be supported by the rtl8821ae module, which is
shipped in the nic-wireless-modules udeb.


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


signature.asc
Description: PGP signature

Bug#889125: comidi-clojure FTBFS: test failure

[Cyril Brulebois]

Control: tag -1 patch

Cyril Brulebois  (2018-12-31):
> Control: forwarded -1 https://github.com/puppetlabs/comidi/issues/36

Upstream patch available (attached), and MR opened upstream:
  https://github.com/puppetlabs/comidi/pull/37

I think I'll wait a few days until upstream has had a chance to comment,
then I'll consider adding the patch to the debian packaging, and submit
an MR against the debian packaging repository.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
From feed07ec54e9d68e3bf52dd1f1a56138d8fd0eab Mon Sep 17 00:00:00 2001
From: Cyril Brulebois 
Date: Wed, 2 Jan 2019 04:34:31 +0100
Subject: [PATCH] Fix test failure with Clojure 1.9+
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Quoting the Clojure documentation:

Use :require in the ns macro in preference to calling this directly.

As kindly pointed out by Alex Miller (@puredanger), the “require” syntax
happened to work accidentally in Clojure 1.8, but that's now rejected by
Clojure 1.9+ with:

Call to clojure.core/ns did not conform to spec: […] Extra input

Debian bug report: https://bugs.debian.org/889125
---
 test/puppetlabs/comidi_test.clj | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/puppetlabs/comidi_test.clj b/test/puppetlabs/comidi_test.clj
index 0b3a53a..4d0e064 100644
--- a/test/puppetlabs/comidi_test.clj
+++ b/test/puppetlabs/comidi_test.clj
@@ -1,5 +1,5 @@
 (ns puppetlabs.comidi-test
-  (require [clojure.test :refer :all]
+  (:require [clojure.test :refer :all]
[puppetlabs.comidi :as comidi :refer :all]
[schema.test :as schema-test]
[schema.core :as schema]
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#917420: python3-networkx: wrongly recommends optional libraries

[Sandro Tosi]

> I filed this bugreport because I believe the use of recommends is wrong
> here: As a library it cannot know if the various optional features are
> exotic or valuable - that is for its consumers to decide.

and this is where i disagree: part of being the maintainer is choosing
the right balance of Depends (core functionalities), Recommends
(important but library usable without) and Suggests (nice to have),
which is what i'm trying to do here.

after all, you're not a direct user of networkx so you may understand
why i'm reluctant to demote any of the current Recommends just because
you feel the dependencies chain of the tool you're actually using is
too wide.

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

Bug#917036: libswagger2-perl: dead upstream

[intrigeri]

gregor herrmann:
> Sounds like a removal candidate?

Agreed ⇒ usertagged as such :)

Bug#917996: pstricks --- undefined in --execute-- when using color.tex in plain tex. --- files quoted.

[P V Mathew]

The files referenced in the bug report is attached herewith.

Regards

P V Mathew

\input pstricks
\input color
\pscircle{1.5}
\bye
This is TeX, Version 3.14159265 (TeX Live 2019/dev/Debian) (preloaded format=tex 2019.1.2)  2 JAN 2019 09:35
**test.tex
(./test.tex (/usr/share/texlive/texmf-dist/tex/generic/pstricks/pstricks.tex
(/usr/share/texlive/texmf-dist/tex/generic/pstricks/pstricks-tex.def
\@unused=\write0

we are running tex and have to make it etex and latex compatible ...
\@unused=\write1
) (/usr/share/texlive/texmf-dist/tex/generic/xkeyval/pst-xkey.tex
2005/11/25 v1.6 PSTricks specialization of xkeyval (HA)
(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkeyval.tex
(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvutils.tex
\XKV@toks=\toks12
\XKV@tempa@toks=\toks13

(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/keyval.tex))
\XKV@depth=\count26

2014/12/03 v2.7a key=value parser (HA)
(/usr/share/texlive/texmf-dist/tex/generic/xkeyval/xkvtxhdr.tex
2005/02/22 v1.1 xkeyval TeX header (HA
(/usr/share/texlive/texmf-dist/tex/generic/pstricks/pst-fp.tex
`pst-fp' v0.05, 2010/01/17 (hv)
\pstFP@xs=\count61
\pstFP@xia=\count62
\pstFP@xib=\count63
\pstFP@xfa=\count64
\pstFP@xfb=\count65
\pstFP@rega=\count66
\pstFP@regb=\count67
\pstFP@regs=\count68
\pstFP@times=\count69
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common.tex
\pgfutil@everybye=\toks14
\pgfutil@tempdima=\dimen16
\pgfutil@tempdimb=\dimen17

(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfutil-common-lists.t
ex)) (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeys.code.tex
\pgfkeys@pathtoks=\toks15
\pgfkeys@temptoks=\toks16

(/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgfkeysfiltered.code.t
ex
\pgfkeys@tmptoks=\toks17
)) (/usr/share/texlive/texmf-dist/tex/generic/pgf/utilities/pgffor.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmath.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathcalc.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathutil.code.tex
\pgf@x=\dimen18
\pgf@xa=\dimen19
\pgf@xb=\dimen20
\pgf@xc=\dimen21
\pgf@y=\dimen22
\pgf@ya=\dimen23
\pgf@yb=\dimen24
\pgf@yc=\dimen25
\c@pgf@counta=\count70
\c@pgf@countb=\count71
\c@pgf@countc=\count72
\c@pgf@countd=\count73
\pgfutil@tempcnta=\count74
\pgfutil@tempcntb=\count75
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathparser.code.tex
\pgfmath@dimen=\dimen26
\pgfmath@count=\count76
\pgfmath@box=\box16
\pgfmath@toks=\toks18
\pgfmath@stack@operand=\toks19
\pgfmath@stack@operation=\toks20
)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.code.tex
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.basic.code
.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.trigonomet
ric.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.random.cod
e.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.comparison
.code.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.base.code.
tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.round.code
.tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.misc.code.
tex)
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfunctions.integerari
thmetics.code.tex)))
(/usr/share/texlive/texmf-dist/tex/generic/pgf/math/pgfmathfloat.code.tex
\c@pgfmathroundto@lastzeros=\count77
))
\pgffor@iter=\dimen27
\pgffor@skip=\dimen28
\pgffor@stack=\toks21
\pgffor@toks=\toks22
)
\psLoopIndex=\count78

`PSTricks' v2.88  <2018/12/13> (tvz,hv)
\pst@dima=\dimen29
\pst@dimb=\dimen30
\pst@dimc=\dimen31
\pst@dimd=\dimen32
\pst@dimg=\dimen33
\pst@dimh=\dimen34
\pst@dimm=\dimen35
\pst@dimn=\dimen36
\pst@dimo=\dimen37
\pst@dimp=\dimen38
\pst@hbox=\box17
\pst@ibox=\box18
\pst@boxg=\box19
\pst@cnta=\count79
\pst@cntb=\count80
\pst@cntc=\count81
\pst@cntd=\count82
\pst@cntg=\count83
\pst@cnth=\count84
\pst@cntm=\count85
\pst@cntn=\count86
\pst@cnto=\count87
\pst@cntp=\count88
\@zero=\count89
\pst@toks=\toks23
(/usr/share/texlive/texmf-dist/tex/generic/pstricks/pstricks.con)
\psunit=\dimen39
\psxunit=\dimen40
\psyunit=\dimen41
\pst@C@@rType=\count90
\pslinewidth=\dimen42
\psk@startLW=\dimen43
\psk@endLW=\dimen44
\pst@customdefs=\toks24
\pslinearc=\dimen45
\pst@symbolStep=\dimen46
\pst@symbolWidth=\dimen47
\pst@symbolLinewidth=\dimen48
\everypsbox=\toks25
\psframesep=\dimen49
\pslabelsep=\dimen50
\sh@wgridXunit=\dimen51
\sh@wgridYunit=\dimen52
\pst@shift=\dimen53
)
(/usr/share/texlive/texmf-dist/tex/plain/graphics-pln/color.tex
(/usr/share/texlive/texmf-dist/tex/plain/graphics-pln/miniltx.tex
\@tempcnta=\count91
\@tempcntb=\count92
\@tempdima=\dimen54
\@tempdimb=\dimen55
\@tempdimc=\dimen56
\@tempboxa=\box20
\@tempskipa=\skip18
\@tempskipb=\skip19
\@temptokena=\toks26
^^JDefining generic filename parser.^^J
\leftmarginv=\dimen57
\leftmarginvi=\dimen58
\@ovxx=\dimen59

Bug#917420: python3-networkx: wrongly recommends optional libraries

[Jonas Smedegaard]

Quoting Sandro Tosi (2019-01-02 05:12:42)
> On Tue, Jan 1, 2019 at 10:49 PM Jonas Smedegaard  wrote:
> >
> > Quoting Sandro Tosi (2019-01-02 04:36:39)
> > > > python3-networkx recommends these libraries:
> > > >
> > > > python3-gdal
> > > > python3-numpy
> > > > python3-scipy
> > > > python3-yaml
> > > >
> > > > Those are listed in upstream setup.py file as "extras_require" 
> > > > which I interpret as equivalent to "optional" i.e. translates to 
> > > > either "Suggests:" or "Recommends:" in Debian.
> > >
> > > not really, but mostly - what is the actual issue that made you 
> > > file this bug report?
> >
> > My use case is installing prov-tools and being quite surprised by 
> > the huge baggage it carries.
> 
> I see, but i'm afraid removing those Recommends will reduce the value 
> of networkx "out-of-the-box" (ie right after apt-get install).
> 
> if you prefer a lean machine, you can always disable Recommends 
> installation?

I filed this bugreport because I believe the use of recommends is wrong 
here: As a library it cannot know if the various optional features are 
exotic or valuable - that is for its consumers to decide.

 - 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#917996: texlive-pstricks: gs gives undefined in --execute-- when using color.tex with pstricks on plain tex.

[P V Mathew]

Package: texlive-pstricks
Version: 2018.20181214-1
Severity: normal

Dear Maintainer,


Inclusion of color.tex and calling \pscircle. plain tex compiled ok
with
  >tex test.tex 
and created test.dvi 
But running xdvi on generated test.dvi file results in gs error.
If we remove the \input color line, every thing works ok.



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file
/home/pvm/Documents/TeX/pstricks/test.tex

##
other files
/home/pvm/Documents/TeX/pstricks/test.log
/home/pvm/Documents/TeX/pstricks/test.dvi

##
 List of ls-R files

-rw-rw-r-- 1 root staff 4985 Apr 27  2018 /usr/local/share/texmf/ls-R
-rw-r--r-- 1 root root 1190 Jan  2 09:14 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Sep  2 18:02 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Dec 14 10:28 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Dec 14 10:28 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 1101 Sep 11 11:29 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Dec 14 10:28 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Dec 14 10:28 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3342 Jan  2 09:14 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root  283 Jun 27  2015 mktex.cnf
-rw-r--r-- 1 root root 1101 Sep 11 11:29 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
055e06548bac99958d8ab2dd1248f2b4  /etc/texmf/texmf.d/80tex4ht.cnf

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

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

Versions of packages texlive-pstricks depends on:
ii  tex-common 6.10
ii  texlive-base   2018.20181214-1
ii  texlive-binaries   2018.20181218.49446-1
ii  texlive-pictures   2018.20181214-1
ii  texlive-plain-generic  2018.20181214-1

Versions of packages texlive-pstricks recommends:
ii  ps2eps   1.68+binaryfree-2
ii  texlive-extra-utils  2018.20181214-1
ii  texlive-font-utils   2018.20181214-1

Versions of packages texlive-pstricks suggests:
ii  texlive-pstricks-doc  2018.20181214-1

Versions of packages tex-common depends on:
ii  dpkg  1.19.2
ii  ucf   3.0038+nmu1

Versions of packages tex-common suggests:
ii  debhelper  12

Versions of packages texlive-pstricks is related to:
ii  tex-common6.10
ii  texlive-binaries  2018.20181218.49446-1

-- no debconf information

Bug#917420: python3-networkx: wrongly recommends optional libraries

[Sandro Tosi]

On Tue, Jan 1, 2019 at 10:49 PM Jonas Smedegaard  wrote:
>
> Quoting Sandro Tosi (2019-01-02 04:36:39)
> > > python3-networkx recommends these libraries:
> > >
> > > python3-gdal
> > > python3-numpy
> > > python3-scipy
> > > python3-yaml
> > >
> > > Those are listed in upstream setup.py file as "extras_require"
> > > which I interpret as equivalent to "optional"
> > > i.e. translates to either "Suggests:" or "Recommends:" in Debian.
> >
> > not really, but mostly - what is the actual issue that made you file
> > this bug report?
>
> My use case is installing prov-tools and being quite surprised by the
> huge baggage it carries.

I see, but i'm afraid removing those Recommends will reduce the value
of networkx "out-of-the-box" (ie right after apt-get install).

if you prefer a lean machine, you can always disable Recommends installation?

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

Bug#917420: python3-networkx: wrongly recommends optional libraries

[Jonas Smedegaard]

Quoting Sandro Tosi (2019-01-02 04:36:39)
> > python3-networkx recommends these libraries:
> >
> > python3-gdal
> > python3-numpy
> > python3-scipy
> > python3-yaml
> >
> > Those are listed in upstream setup.py file as "extras_require"
> > which I interpret as equivalent to "optional"
> > i.e. translates to either "Suggests:" or "Recommends:" in Debian.
> 
> not really, but mostly - what is the actual issue that made you file
> this bug report?

My use case is installing prov-tools and being quite surprised by the 
huge baggage it carries.

 - 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#917420: python3-networkx: wrongly recommends optional libraries

[Sandro Tosi]

> python3-networkx recommends these libraries:
>
> python3-gdal
> python3-numpy
> python3-scipy
> python3-yaml
>
> Those are listed in upstream setup.py file as "extras_require"
> which I interpret as equivalent to "optional"
> i.e. translates to either "Suggests:" or "Recommends:" in Debian.

not really, but mostly - what is the actual issue that made you file
this bug report?

> In Debian, "Recommends:" is for all but unusual cases,
> but a library cannot know what cases are usual or unusual -
> that is for the consuming libraries/applications to decide.
>
> Therefore I believe these recommendations should be demoted to suggestions.

did you try to search for those modules in networkx source code? for
sure i'm not going to demote scipy or numpy, as they are important
part of the functionality of networkx (i can be convinced about gdal
and yaml).

> Also, while at it, it seems several more such "optionals" are listed
> which are relevant for the Debian package to suggest, including pandas.

pandas has been included in the most recent 2.2 version, so yes, i
would say we should add a Recommends on pandas too

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

Bug#917995: debian-policy: drop section 1.6 Translations

[Ansgar Burchardt]

Package: debian-policy
Version: 4.3.0.1
Severity: normal

Hi,

I hereby propose to drop section 1.6 Translations and the following
sentence: "When translations of this document into languages other
than English disagree with the English text, the English text takes
precedence."

If it is wrongly translated, then the English text probably isn't
clear enough (otherwise the translation would have the same meaning)
and would need to be clarified anyway to avoid being ambigious.  Even
if not, the same process can be used to clarify the meaning of
non-English versions.

There should be no need to put one language over others.

Ansgar

Bug#887150: reportbug: stable-pu request: don't ask whether the current version in stable is the correct one

[Sandro Tosi]

Hey Release Team, are you ok with the change described below? thanks!

On Tue, Jan 1, 2019 at 7:49 PM Andreas Beckmann  wrote:
>
> On 2019-01-02 01:29, Sandro Tosi wrote:
> >> when filing an (old)stable-pu request, reportbug asks whether the
> >
> > this is for `release.debian.org` correct?
>
> Yes.
>
> >> current version in (old)stable is the proper version. Obviously it never
> >> is, so this question is useless and should be omitted - or the most
> >> likely (old)stable increment version could be guessed and presented
> >> instead.
> >>
> >> If the version lookup is retained, it should also consider
> >> (old)stable-proposed-updates, which might already have an update queued.
> >
> > just to make it sure, do you want to remove `Latest version seems to
> > be XXX, is this the proper one ? [Y|n|?]?` question and make `Please
> > enter the version of the package: ` mandatory, correct?
>
> Exactly.
>
>
> Andreas



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

Bug#887045: 887045

[Nye Liu]

  

   


Not fixed in

  

   

Linux stupid 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 
GNU/Linux


  

  

[297269.085315] WARNING: CPU: 1 PID: 451 at 
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1431 
iwl_mvm_rx_tx_cmd+0x1e6/0x650 [iwlmvm]
[297269.085321] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs vfat 
msdos fat jfs xfs ext4 mbcache jbd2 fscrypto ecb dm_mod ctr ccm fuse 
xt_CHECKSUM tun ipt_REJECT nf_reject_ipv4 sctp ipt_MASQUERADE 
nf_conntrack_netlink xfr
m_user xfrm_algo xt_addrtype br_netfilter ebtable_filter devlink 
ebtables iptable_nat sit tunnel4 ip_tunnel sch_sfq cls_fw sch_htb 
nft_chain_route_ipv6 xt_conntrack ip6t_REJECT nf_reject_ipv6 
nft_chain_route_ipv4 xt_multiport x
t_dscp xt_mark nft_counter nft_chain_nat_ipv4 nf_nat_ipv4 xt_nat nf_nat 
nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_tcpudp nft_compat 
nf_tables nfnetlink binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_gene
ric bridge stp llc intel_rapl arc4 x86_pkg_temp_thermal intel_powerclamp 
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul iwlmvm
[297269.085414] btusb ghash_clmulni_intel btrtl btbcm btintel 
intel_cstate mac80211 intel_uncore bluetooth intel_rapl_perf sg pcspkr 
snd_hda_intel i915 iTCO_wdt iwlwifi iTCO_vendor_support snd_hda_codec 
jitterentropy_rng joyde
v snd_hda_core cfg80211 snd_hwdep snd_pcm_oss evdev snd_mixer_oss drbg 
usblp ansi_cprng drm_kms_helper ecdh_generic mei_me snd_pcm mei rfkill 
snd_timer crc16 drm snd soundcore video acpi_pad button pcc_cpufreq 
squashfs loop nct
6775 hwmon_vid coretemp parport_pc ppdev lp parport ip_tables x_tables 
autofs4 btrfs xor zstd_decompress zstd_compress xxhash raid6_pq 
libcrc32c crc32c_generic hid_generic usbhid hid sd_mod uas usb_storage 
crc32c_intel aesni_in
tel ahci xhci_pci nvme libahci xhci_hcd aes_x86_64 crypto_simd cryptd 
glue_helper libata i2c_i801 e1000e igb usbcore scsi_mod nvme_core

[297269.085518] i2c_algo_bit dca usb_common
[297269.085530] CPU: 1 PID: 451 Comm: irq/136-iwlwifi Tainted: G W 
4.19.0-1-amd64 #1 Debian 4.19.12-1
[297269.085535] Hardware name: To Be Filled By O.E.M. To Be Filled By 
O.E.M./H270M-ITX/ac, BIOS P2.00 03/29/2017

[297269.085554] RIP: 0010:iwl_mvm_rx_tx_cmd+0x1e6/0x650 [iwlmvm]
[297269.085560] Code: b6 6c 24 0a 48 8b 5c 24 28 c6 44 24 13 00 41 8d 45 
ff 66 89 44 24 10 48 8d 44 24 28 48 39 c3 0f 85 ef 00 00 00 e9 72 02 00 
00 <0f> 0b 81 4b 28 00 01 00 00 45 31 f6 49 8b 47 10 48 8b b0 d0 03 00

[297269.085565] RSP: 0018:af7b01e4fd38 EFLAGS: 00010246
[297269.085571] RAX: 8f03e68a8d01 RBX: 8f01981b5900 RCX: 
00173bcd
[297269.085576] RDX: 00173bcc RSI: 8f041eea6600 RDI: 
f603509a2a00
[297269.085580] RBP: 8f01983c5000 R08: 8f01981b5930 R09: 
c0efa022
[297269.085584] R10: 8f4f7240 R11: 00be R12: 
8f041a5ec866
[297269.085588] R13: 0088 R14: 05be R15: 
8f04194b9548
[297269.085594] FS: () GS:8f041ee8() 
knlGS:

[297269.085599] CS: 0010 DS:  ES:  CR0: 80050033
[297269.085603] CR2: 7f11fd302a70 CR3: 0003f500a006 CR4: 
003606e0
[297269.085607] DR0:  DR1:  DR2: 

[297269.085612] DR3:  DR6: fffe0ff0 DR7: 
0400

[297269.085615] Call Trace:
[297269.085636] iwl_pcie_rx_handle+0x239/0x860 [iwlwifi]
[297269.085654] iwl_pcie_irq_handler+0x183/0x6b0 [iwlwifi]
[297269.085662] ? irq_finalize_oneshot.part.43+0x100/0x100
[297269.085669] irq_thread_fn+0x1f/0x60
[297269.085675] irq_thread+0xe7/0x170
[297269.085682] ? irq_forced_thread_fn+0x70/0x70
[297269.085689] ? irq_thread_check_affinity+0xd0/0xd0
[297269.085694] kthread+0x112/0x130
[297269.085700] ? kthread_bind+0x30/0x30
[297269.085709] ret_from_fork+0x35/0x40
[297269.085715] ---[ end trace 46da582480566ecd ]---
[399944.920816] iwlwifi :03:00.0: Queue 8 is active on fifo 3 and 
stuck for 1 ms. SW [180, 181] HW [180, 181] FH TRB=0x080309067
[399944.920877] iwlwifi :03:00.0: Microcode SW error detected. 
Restarting 0x200.

[399944.921007] iwlwifi :03:00.0: Start IWL Error Log Dump:
[399944.921013] iwlwifi :03:00.0: Status: 0x0100, count: 6
[399944.921018] iwlwifi :03:00.0: Loaded firmware version: 
29.1044073957.0

[399944.921025] iwlwifi :03:00.0: 0x0084 | NMI_INTERRUPT_UNKNOWN
[399944.921030] iwlwifi :03:00.0: 0x02E0 | trm_hw_status0
[399944.921036] iwlwifi :03:00.0: 0x | trm_hw_status1
[399944.921041] iwlwifi :03:00.0: 0x00043D54 | branchlink2
[399944.921046] iwlwifi :03:00.0: 0x0004AFA6 | interruptlink1
[399944.921051] iwlwifi :03:00.0: 0x0004AFA6 | interruptlink2
[399944.921056] iwlwifi :03:00.0: 0x | data1
[399944.921061] iwlwifi :03:00.0: 0x0080 | data2
[399944.921066] iwlwifi :03:00.0: 0x0703 | data3
[399944.921071] iwlwifi :03:00.0: 0x | beacon time
[399944.921076] 

Bug#916670: cryptsetup: ERROR: Couldn't resolve device rootfs

[pavel piankov]

> update-initramfs: Generating /boot/initrd.img-4.18.0-3-amd64
> cryptsetup: ERROR: Couldn't resolve device rootfs
> ^^^

this is due 
rootfs / rootfs rw 0 0
line in /etc/mtab
remove it and the problem no more.

Bug#917994: RM: kbattleship [all] -- RoQA; arch:all transitional NBS package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: knavalbat...@packages.debian.org

kbattleship is a transitional arch:all package that is no longer built
from the knavalbattle source. I believe that arch:all packages are not
handled by the
auto-cruft tools.

Please remove this arch:all package only.

Thanks,
Jeremy Bicha

Bug#917717: pylint-django: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Joseph Herlant]

Note that I'm having trouble with the latest release right now (see
https://github.com/PyCQA/pylint-django/issues/215) so I won't upload
it today.
But I should be able to get that fixed shortly.

Bug#917993: wmbiff: gmail (and many other IMAP servers) now require SNI

[Nye Liu]

Package: wmbiff
Version: 0.4.31-2
Severity: important
Tags: upstream patch

wmbiff/gmail imap4: Need new connection to ***@gmail@imap.gmail.com
wmbiff/gmail comm: certificate passed time check.
wmbiff/gmail comm: server's certificate (OU=No SNI provided\; please fix your 
client.,CN=invalid2.invalid) does not match its hostname (imap.gmail.com).
wmbiff/gmail comm: server's certificate does not match its hostname.
wmbiff/gmail comm: to ignore this error, run wmbiff with the 
-skip-certificate-check option

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

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

Versions of packages wmbiff depends on:
ii  libc62.28-2
ii  libgcrypt20  1.8.4-4
ii  libgnutls30  3.6.5-2
ii  libx11-6 2:1.6.7-1
ii  libxext6 2:1.3.3-1+b2
ii  libxpm4  1:3.5.12-1

wmbiff recommends no packages.

Versions of packages wmbiff suggests:
ii  ruby 1:2.5.1
pn  ssh-askpass  

-- no debconf information
diff --git a/wmbiff/tlsComm.c b/wmbiff/tlsComm.c
index f37f3f5..bd6c7c4 100644
--- a/wmbiff/tlsComm.c
+++ b/wmbiff/tlsComm.c
@@ -599,6 +599,8 @@ struct connection_state *initialize_gnutls(intptr_t sd, 
char *name, Pop3 pc,
}
}
 
+   gnutls_server_name_set(scs->tls_state, GNUTLS_NAME_DNS,
+   remote_hostname, 
strnlen(remote_hostname, 256));
gnutls_cred_set(scs->tls_state, GNUTLS_CRD_CERTIFICATE,
scs->xcred);
gnutls_transport_set_ptr(scs->tls_state,

Bug#917992: python3-ryu: fails to upgrade from 'stable' to 'sid' - trying to overwrite /usr/bin/ryu

[Andreas Beckmann]

Package: python3-ryu
Version: 4.26+dfsg1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../python3-ryu_4.26+dfsg1-4_all.deb ...
  Unpacking python3-ryu (4.26+dfsg1-4) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-ryu_4.26+dfsg1-4_all.deb (--unpack):
   trying to overwrite '/usr/bin/ryu', which is also in package ryu-bin 
4.4+dfsg1-2
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-ryu_4.26+dfsg1-4_all.deb


cheers,

Andreas


ryu-bin=4.4+dfsg1-2_python3-ryu=4.26+dfsg1-4.log.gz
Description: application/gzip

Bug#917991: debian-keyring: debian-role-keys.gpg: contains obsolete, expired Debian Security Team key

[Paul Wise]

Package: debian-keyring
Version: 2018.11.25
Severity: normal
File: /usr/share/keyrings/debian-role-keys.gpg
Tags: security
X-Debbugs-CC: secur...@debian.org

I noticed that debian-role-keys.gpg contains two keys for the Debian
Security Team, one of which is expired and obsolete (based on the
security FAQ on the website). Presumably the obsolete key should be
removed from the Debian role keyring.

$ gpg --no-default-keyring --keyring /usr/share/keyrings/debian-role-keys.gpg 
--list-key secur...@debian.org
Keyring: /usr/share/keyrings/debian-role-keys.gpg
-
pub   rsa4096/0x2702CAEB90F8EEC5 2012-09-12 [SC] [expired: 2015-09-12]
  Key fingerprint = BACB 4B5C 30AC 38F3 19EE  961E 2702 CAEB 90F8 EEC5
uid   [ expired] Debian Security Team 
uid   [ expired] Debian Security Team 
uid   [ expired] Debian Security Team 

sub   rsa4096/0x2FDE22ACA225CF28 2012-09-12 [E] [expired: 2015-09-12]
  Key fingerprint = 8368 CE16 564D 83C7 5049  F9E4 2FDE 22AC A225 CF28

Keyring: /usr/share/keyrings/debian-role-keys.gpg
-
pub   rsa4096/0x6BAF400B05C3E651 2015-01-18 [SC] [expires: 2020-01-17]
  Key fingerprint = 0D59 D2B1 5144 766A 14D2  41C6 6BAF 400B 05C3 E651
uid   [ unknown] Debian Security Team 
uid   [ unknown] Debian Security Team 
sub   rsa4096/0x0DD8C0E40F39FB17 2015-01-18 [E] [expires: 2020-01-17]
  Key fingerprint = 0730 18F7 B3AF 12F8 D28A  7063 0DD8 C0E4 0F39 FB17

$ w3m -dump https://www.debian.org/security/faq#contact | grep -A2 'key ID'
If desired, email can be encrypted with the Debian Security Contact key (key ID
0x0D59D2B15144766A14D241C66BAF400B05C3E651). For the PGP/GPG keys of individual
team members, please refer to the keyring.debian.org keyserver.

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

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

debian-keyring depends on no packages.

Versions of packages debian-keyring recommends:
ii  gnupg  2.2.12-1

debian-keyring suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#917989: LD_DEBUG messages

[Troy Telford]

Below is the bottom stanza from LD_DEBUG, showing the linker error.  I hope 
it’s helpful.

7105:   
   
  7105: object=/lib64/ld-linux-x86-64.so.2 [0]  
 
  7105:  no scope   
 
  7105:   
  7105:  7105: calling init: /usr/lib/asterisk/modules/app_while.so 
   
  7105: 
 
  7105: opening file=/usr/lib/asterisk/modules/app_while.so [0]; 
direct_opencount=1   
  7105: 
 
  7105: 
 
  7105: file=/usr/lib/asterisk/modules/res_http_post.so [0];  
dynamically loaded by asterisk [0]  
 
  7105: file=/usr/lib/asterisk/modules/res_http_post.so [0];  
generating link map 
  7105:   dynamic: 0x7f70276e2be8  base: 0x7f70276dc000   size: 
0x7110
  7105: entry: 0x7f70276de3c0  phdr: 0x7f70276dc040  phnum: 
 9  7105:   

  7105: 
 
  7105: file=libgmime-3.0.so.0 [0];  needed by 
/usr/lib/asterisk/modules/res_http_post.so 
[0] 
 
  7105: find library=libgmime-3.0.so.0 [0]; searching   
  
  7105:  search cache=/etc/ld.so.cache  
  
  7105:   trying file=/lib/x86_64-linux-gnu/libgmime-3.0.so.0   
  
  7105: 
 
  7105: file=libgmime-3.0.so.0 [0];  generating link map
  
  7105:   dynamic: 0x7f70276c29f0  base: 0x7f7027657000   size: 
0x0007d540
  7105: entry: 0x7f702766f580  phdr: 0x7f7027657040  phnum: 
 9  7105:   

  7105: 
 
  7105: file=libnsl.so.1 [0];  needed by 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0 [0] 
  7105: find library=libnsl.so.1 [0]; searching 
 
  7105:  search cache=/etc/ld.so.cache  
  
  7105:   trying file=/lib/x86_64-linux-gnu/libnsl.so.1 
  
  7105: 
 
  7105: file=libnsl.so.1 [0];  generating link map  
  
  7105:   dynamic: 0x7f7027653d78  base: 0x7f702763e000   size: 
0x00018a58
  7105: entry: 0x7f70276426b0  phdr: 0x7f702763e040  phnum: 
 9  7105:   

  7105: 
 
  7105: file=libgpgme.so.11 [0];  needed by 
/lib/x86_64-linux-gnu/libgmime-3.0.so.0 [0]   
  7105: find library=libgpgme.so.11 [0]; searching  
  
  7105:  search cache=/etc/ld.so.cache  
  
  7105:   trying file=/lib/x86_64-linux-gnu/libgpgme.so.11  
  
  7105: 
 
  7105: file=libgpgme.so.11 [0];  generating link map   
  
Inconsistency detected by ld.so: ../elf/dl-tls.c: 73: _dl_next_tls_modid: 
Assertion `result <= GL(dl_tls_max_dtv_idx) + 1' failed! 

Bug#917990: libplplotada1-dev: fails to upgrade from 'testing' - trying to overwrite /usr/lib/x86_64-linux-gnu/ada/adalib/plplotada/plplot_auxiliary.ali

[Andreas Beckmann]

Package: libplplotada1-dev
Version: 5.14.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libplplotada1-dev_5.14.0+dfsg-1_amd64.deb ...
  Unpacking libplplotada1-dev (5.14.0+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libplplotada1-dev_5.14.0+dfsg-1_amd64.deb (--unpack):
   trying to overwrite 
'/usr/lib/x86_64-linux-gnu/ada/adalib/plplotada/plplot_auxiliary.ali', which is 
also in package libplplot-ada-dev:amd64 5.13.0+dfsg-9
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/libplplotada1-dev_5.14.0+dfsg-1_amd64.deb


cheers,

Andreas


libplplot-ada-dev=5.13.0+dfsg-9_libplplotada1-dev=5.14.0+dfsg-1.log.gz
Description: application/gzip

Bug#917989: asterisk: Upgrade of libgnutls30 causes Asterisk to fail to load: linker error

[angela . n . troy . telford]

Package: asterisk
Version: 1:13.23.1~dfsg-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
apt-get upgrade included libgnutls30
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Rolling back the filesystem snapshot allowed me to pinpoint the 
package with the linking error. I'm not sure if the bug should be filed against 
libgnutls30 or against asterisk.
   * What was the outcome of this action?
Upgrading libgnutls30 causes asterisk to fail to load, with 
little in terms of log messages by default.  Turning up verbosity and running 
asterisk in the foreground showed an ld linker error against an encryption 
library (judging from the symbol reported).

I then ran 'apt-mark hold' on libgnutls30, and upgraded again 
-- this time with success.

After this bug is finished getting filed, I'll get the full error message I'm 
seeing.

As I said -- I'm unsure if the problem is with libgnutls30, or if asterisk 
simply requires a recompile.

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


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

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

Versions of packages asterisk depends on:
ii  adduser  3.118
ii  asterisk-config  1:13.23.1~dfsg-1
ii  asterisk-core-sounds-en  1.6.1-1
ii  asterisk-modules 1:13.23.1~dfsg-1
ii  libc62.28-4
ii  libcap2  1:2.25-1.2
ii  libedit2 3.1-20181209-1
ii  libjansson4  2.12-1
ii  libpopt0 1.16-11
ii  libsqlite3-0 3.26.0+fossilbc891ac6b-1
ii  libssl1.11.1.1a-1
ii  libsystemd0  239-14
ii  liburiparser10.9.0-1
ii  libuuid1 2.33-0.2
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxslt1.1   1.1.32-2
ii  lsb-base 10.2018112800

Versions of packages asterisk recommends:
ii  asterisk-moh-opsound-gsm 2.03-1
ii  asterisk-voicemail [asterisk-voicemail-storage]  1:13.23.1~dfsg-1
ii  sox  14.4.2-3

Versions of packages asterisk suggests:
pn  asterisk-dahdi   
ii  asterisk-dev 1:13.23.1~dfsg-1
ii  asterisk-doc 1:13.23.1~dfsg-1
pn  asterisk-ooh323  
ii  asterisk-opus13.7+20171009-1
pn  asterisk-vpb 

-- no debconf information

Bug#917988: libodb-api-dev: file conflict with libodb-dev: /usr/lib/x86_64-linux-gnu/libodb.so

[Andreas Beckmann]

Package: libodb-api-dev
Version: 0.18.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libodb-api-dev:amd64.
  Preparing to unpack .../48-libodb-api-dev_0.18.1-1_amd64.deb ...
  Unpacking libodb-api-dev:amd64 (0.18.1-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-uOE0lB/48-libodb-api-dev_0.18.1-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libodb.so', which is also in 
package libodb-dev 2.4.0-1+b1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-uOE0lB/48-libodb-api-dev_0.18.1-1_amd64.deb


cheers,

Andreas


libodb-dev=2.4.0-1+b1_libodb-api-dev=0.18.1-1.log.gz
Description: application/gzip

Bug#908650: reportbug: replaces package with source package for ROM package removal

[Scott Kitterman]

As the FTP Team member doing most of the the removals work, I think that would 
be a helpful change.

Scott K

On January 1, 2019 11:07:50 PM UTC, Sandro Tosi  wrote:
>> Sometimes we need to report an RM bug against ftp.debian.org to
>remove
>> a binary package which is no longer built.
>>
>> reportbug deals with this in the interface for ftp.debian.org, asking
>> you for the name of the which package you want removed.
>>
>> But then after you specify the binary package that needs to be
>> removed, reportbug switches the Subject for the bug report to the
>> source package instead of the binary package.  This means the package
>> needing removal is misrepresented and there is a danger the ftp team
>> will remove the entire source package.  Not the outcome we want.
>>
>> A recent example is #907513 requesting to remove mshr-demos.
>> reportbug altered the Subject to mark mshr for removal instead of
>> mshr-demos. (Fortunately Adrian Bunk saw and corrected the mistake).
>
>I'd be ok to remove the implicit conversion from binary to source
>package when dealing with ftp.debian.org bugs
>(https://salsa.debian.org/reportbug-team/reportbug/blob/master/reportbug/debbugs.py#L267-271)
>but i need FTP masters to accept the change, here in CC
>
>Thanks,

Bug#887150: reportbug: stable-pu request: don't ask whether the current version in stable is the correct one

[Andreas Beckmann]

On 2019-01-02 01:29, Sandro Tosi wrote:
>> when filing an (old)stable-pu request, reportbug asks whether the
> 
> this is for `release.debian.org` correct?

Yes.

>> current version in (old)stable is the proper version. Obviously it never
>> is, so this question is useless and should be omitted - or the most
>> likely (old)stable increment version could be guessed and presented
>> instead.
>>
>> If the version lookup is retained, it should also consider
>> (old)stable-proposed-updates, which might already have an update queued.
> 
> just to make it sure, do you want to remove `Latest version seems to
> be XXX, is this the proper one ? [Y|n|?]?` question and make `Please
> enter the version of the package: ` mandatory, correct?

Exactly.


Andreas

Bug#917717: pylint-django: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Joseph Herlant]

Control: tags -1 + fixed-upstream

Reading through the changes of 2.0.1 to 2.0.5 of pylint-django, it
seems that this change has already been dealt with in the latest
version.
See: 
https://github.com/PyCQA/pylint-django/commit/c0408d7b844f46cf675986576ea2acaf4fd234cc#diff-caeb1acca0adc7ada7d03b9e07452774
So please don't get mad if I drop your patch. ;)

Thanks
Joseph

Bug#887150: reportbug: stable-pu request: don't ask whether the current version in stable is the correct one

[Sandro Tosi]

> when filing an (old)stable-pu request, reportbug asks whether the

this is for `release.debian.org` correct?

> current version in (old)stable is the proper version. Obviously it never
> is, so this question is useless and should be omitted - or the most
> likely (old)stable increment version could be guessed and presented
> instead.
>
> If the version lookup is retained, it should also consider
> (old)stable-proposed-updates, which might already have an update queued.

just to make it sure, do you want to remove `Latest version seems to
be XXX, is this the proper one ? [Y|n|?]?` question and make `Please
enter the version of the package: ` mandatory, correct?

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

Bug#917947: mpb-dev not built on mipsel.

[Peter Green]

On 01/01/19 16:00, Thorsten Alteholz wrote:



On Tue, 1 Jan 2019, Peter Michael Green wrote:

While checking why meep wasn't migrating to testing I discovered it had an 
unsatisfiable dependency on mpb-dev.


Yes, I am afraid the mipsel buildds have been to slow. Now mpb is available and I requested to give meep back ... 

mpb is available but mpb-dev is not, because it still has an architecture list 
that does not include mipsel (as does mpb-mpi, but that is not relavent here).

Bug#917987: libpillowfight: FTBFS (missing build-depends on cmake)

[Santiago Vila]

Package: src:libpillowfight
Version: 0.2.4-1
Severity: serious
Tags: ftbfs

Dear maintainer:

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


[...]
 debian/rules build-arch
dh build-arch -p python3-pypillowfight --with python3
   dh_testdir -a -O-ppython3-pypillowfight
   dh_update_autotools_config -a -O-ppython3-pypillowfight
   dh_autoreconf -a -O-ppython3-pypillowfight
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
sed 's,@DEB_VERSION_UPSTREAM@,0.2.4,g' debian/_version.h.in > 
src/pillowfight/_version.h
dh_auto_configure -p libpillowfight -p libpillowfight-dev -O--buildsystem=cmake 
-- -DLIBDIR=lib/x86_64-linux-gnu
install -d obj-x86_64-linux-gnu
cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DLIBDIR=lib/x86_64-linux-gnu ..
Can't exec "cmake": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 475.
dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DLIBDIR=lib/x86_64-linux-gnu .. 
failed to execute: No child processes
dh_auto_configure: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr 
-DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONFDIR=/etc 
-DCMAKE_INSTALL_LOCALSTATEDIR=/var -DCMAKE_EXPORT_NO_PACKAGE_REGISTRY=ON 
-DCMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY=ON -DCMAKE_INSTALL_RUNSTATEDIR=/run 
"-GUnix Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON 
-DCMAKE_INSTALL_LIBDIR=lib/x86_64-linux-gnu -DLIBDIR=lib/x86_64-linux-gnu .. 
returned exit code 2
make[1]: *** [debian/rules:29: override_dh_auto_configure] Error 2
make[1]: Leaving directory '/<>'
make: *** [debian/rules:15: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


The build was made in my autobuilder with "dpkg-buildpackage -B" on amd64
but it also fails here on other architectures:

https://buildd.debian.org/status/package.php?p=libpillowfight

[ Based on the error message, it seems there is a missing build-depends on 
cmake,
  but I'm not 100% sure ].

Thanks.

Bug#917904: tightvncserver does not ask for password set by vncpasswd

[Ola Lundqvist]

Hi Jan

Thank you for the report.
I have now tested this myself. I purged all vnc software installed,
installed tightvncserver, run tightvncserver and then run vncpasswd to set
a password.
I failed to reproduce the problem. I'm asked for a password.

So the question is what you did differently. Can it be so that you have
some other vncpasswd software as an alternative and that happen to not be
updating the same things?

Best regards

// Ola

On Mon, 31 Dec 2018 at 15:33, Jan Christoph Terasa 
wrote:

> Package: tightvncserver
> Version: 1:1.3.9-9
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Dear Maintainer,
>
> I installed tightvncserver on my VPS machine via apt. This did set up
> tightvncserver as an alternative for vncserver. Using a normal user
> account and
> starting vncserver for the first time asks for a 8-letter password. My
> assumption
> is this password will be used to authenticate users when connecting to the
> vnc
> server.
>
> After starting the vnc server via vncserver script, it is served on port
> 5901.
> On the client machine I use vinagre to connect to the server on port 5901.
> When
> connecting, I am not asked for a password, but rather directly taken to
> the X
> session. I would have expected the server to ask for the password I
> specified
> earlier.
>
> As a workaround, to ensure the integrity of the system, I set up iptable
> rules to
> not allow direct WAN connections to this port, but only allow local
> connections
> and use an SSH tunnel for connecting to the vnc server.
>
>
> kind regards,
> Christoph
>
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500,
> 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.14.17--std-ipv6-64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/bash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages tightvncserver depends on:
> ii  libc62.27-8
> ii  libjpeg62-turbo  1:1.5.2-2+b1
> ii  libx11-6 2:1.6.7-1
> ii  libxext6 2:1.3.3-1+b2
> ii  perl 5.28.0-3
> ii  x11-common   1:7.7+19
> ii  x11-utils7.7+4
> ii  xauth1:1.0.10-1
> ii  xserver-common   2:1.20.3-1
> ii  zlib1g   1:1.2.11.dfsg-1
>
> Versions of packages tightvncserver recommends:
> ii  x11-xserver-utils  7.7+8
> ii  xfonts-base1:1.0.4+nmu1
>
> Versions of packages tightvncserver suggests:
> pn  tightvnc-java  
>
> -- no debconf information
>


-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#917717: pylint-django: FTBFS: dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.7 returned exit code 13

[Joseph Herlant]

Control: tags -1 - fixed
Control: tags -1 + patch
Hi guys,

Thanks Lucas for the report. Sorry for the late reply, I was out of
the country with very limited internet access.

Thanks Emmanuel for the quick patch.
Notes for next time:
 * Please use meaningful commit messages, especially when committing
to the master branch of a package you don't maintain. Using commit
messages like "fix issue 917717" makes the commit history harder to
read and the use of tools like gbp dch impossible as well as rendering
the gitlab hooks in place for tagging the bugs as pending unusable.
(If you're not sure about your patches, please just create a MR and
the maintainer can help getting the patch to a better standard)
 * Please conform to the DEP-3 headers when you are writing a quilt
patch header. See https://dep-team.pages.debian.net/deps/dep3/
 * If you have a patch that you thing is good enough for Debian, it's
generally a good practice to propose it upstream as upstream is
generally aware of the potential negative impacts and this would avoid
having to maintain diverging patch hell, especially on packages you
don't maintain.
 * Please don't tag bugs as "fixed" as long as there's no NMU uploaded
(as long as the package is not in the archive). In your case the tag
"patch" seems more appropriate.

There is an upstream upgrade I need to do so I'll clean the previous
points and do the upload today or tomorrow.

Thanks,
Joseph

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Tue, Jan 01, 2019 at 06:59:59PM -0500, Thomas Dickey wrote:
> On Tue, Jan 01, 2019 at 12:28:38PM -0500, Thomas Dickey wrote:
> > On Mon, Dec 31, 2018 at 02:32:58PM -0500, Thomas Dickey wrote:
> > > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> > > > * Thomas Dickey  [2018-12-31 00:51]:
> > > > 
> > > > > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > > > > ...
> > > > >> This is the behaviour I get across xterm versions:
> > > > >> (everything with libfontconfig1 2.13.1-2)
> > > > >> 
> > > > >> fonts.conf enabled:
> > > > >> 337: works
> > > > >> 338: segfault
> > > > >> 340: segfault
> > > > >> 341: segfault
> > > > > 
> > > > > Can you make a backtrace for #341, please?
> > > > 
> > > > Here it is:
> > > 
> > > thanks.  I added some notes, but have not been able to reproduce the 
> > > problem.
> > 
> > Looking at this again, I saw (using XFT_DEBUG=3 and the -report-fonts 
> > option)
> > that the fallback was using unifont.  Removing that got it to break (I'll
> > see whether the bug lies in Xft or fontconfig, at least).
... 
> (The bug should be reassigned to the libfontconfig1 package).

fwiw, attaching a screenshot showing xterm working as designed for this
configuration, and the scripts used for running the test.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net
#!/bin/sh
make||exit
rm -vf *core*
export LD_LIBRARY_PATH=/usr/build/xterm/fontconfig-2.13.1/src/.libs
# libfontconfig.so.1.12.0
ldd xterm
FC_DEBUG=8191
XFT_DEBUG=3 ./xterm -xrm '*showMissingGlyphs:true' -report-fonts -fa 'Noto Mono'
#!/bin/bash
tput bold
printf '\U1f384!'
tput smul
printf '\U1f384!'
tput sgr0
printf '\U1f384!'
echo done

/usr/bin/printf "\U0001F384\tU+1F384 CHRISTMAS TREE\n"
/usr/bin/printf "\U0001F385\tU+1F385 FATHER CHRISTMAS\n"
/usr/bin/printf "\U0001F3E1\tU+1F3E1 HOUSE WITH GARDEN\n"
/usr/bin/printf "\U0001F644\tU+1F644 FACE WITH ROLLING EYES\n"
/usr/bin/printf "\U0001F601\tU+1F601 GRINNING FACE WITH SMILING EYES\n"
/usr/bin/printf "\U0001F604\tU+1F604 SMILING FACE WITH OPEN MOUTH AND SMILING 
EYES\n"


signature.asc
Description: Digital signature

Bug#836792: zip FTCBFS: uses the build architecture compiler

[Santiago Vila]

On Tue, Jan 01, 2019 at 12:08:00PM +, Niels Thykier wrote:
 
> Did you hear from upstream on this patch? :)

Sorry, not yet, but your email served as a reminder that I need to
recover my communication channels with upstream authors.

There used to be a phpBB forum linked from this page:

http://www.info-zip.org

but it's now gone.

(So, I've just contacted Hunder Goatley in the hope that either he can
do something about it, or know somebody who can do something about it).

Thanks.

Bug#907492: pam: diff for NMU version 1.1.8-3.9

[Steve Langasek]

Hi Niels,

On Tue, Jan 01, 2019 at 09:51:26PM +, Niels Thykier wrote:
> Dear maintainer,

> I've prepared an NMU for pam (versioned as 1.1.8-3.9) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

> Regards.

> diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
> --- pam-1.1.8/debian/changelog
> +++ pam-1.1.8/debian/changelog
> @@ -1,3 +1,20 @@
> +pam (1.1.8-3.9) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +
> +  [ Niels Thykier ]
> +  * Enable dh_dwz to reduce the size of the dbgsym files.

What is the NMU rationale for this change?  There does not appear to be a
corresponding bug report, and there is certainly not one referenced in the
changelog.  This looks likely to cause build failures in some circumstances,
given the lack of corresponding build-dependency changes.

I am not enthusiastic about pam being opted in to non-default debhelper
settings via NMU.

> +  * Remove Roger Leigh from uploaders as he has retired from
> +Debian.  (Was mentioned in the last upload but not actually
> +done).
> +  * Pass --parallel to dh to enable building pam with multiple cores.

> +  [ Helmut Grohne ]
> +  * Convert DEB_BUILD_PROFILE=stage1 to DEB_BUILD_PROFILES=pkg.pam.noaudit.
> +(Closes: #907492)

Though I had not followed up on the bug report, I disagree with this change
and thus nack this NMU.  I do not agree that it is preferable to use an
explicit 'pkg.pam.noaudit' profile name instead of 'stage1'.  The pam
package was an early adopter of build profiles precisely for the purpose of
archive bootstrapping, and for archive bootstrapping what is interesting is
NOT that the package is built without audit, what is interesting is that it
is a bootstrap build.  The fact that audit is the specific package being
excluded is a point-in-time implementation detail that should NOT be
exposed.

Please withdraw this NMU.

> + -- Niels Thykier   Tue, 01 Jan 2019 21:50:19 +
> +
>  pam (1.1.8-3.8) unstable; urgency=medium
>  
>* Non-maintainer upload.
> @@ -5,7 +22,7 @@
>  chgrp in debian/rules.
>* Update pam-auth-update to detect write errors and properly
>  fail when that happens.  (Closes: #880501)
> -  * Remove Roger Leigh from uploaders as he has restired from
> +  * Remove Roger Leigh from uploaders as he has retired from
>  Debian.  (Closes: #869348)
>* Reduce priority of libpam0g to optional.
>* Rebuild with a recent version of dpkg-source, which ensures
> diff -u pam-1.1.8/debian/control pam-1.1.8/debian/control
> --- pam-1.1.8/debian/control
> +++ pam-1.1.8/debian/control
> @@ -1,10 +1,10 @@
>  Source: pam
>  Section: libs
>  Priority: optional
> -Uploaders: Sam Hartman , Roger Leigh 
> +Uploaders: Sam Hartman 
>  Maintainer: Steve Langasek 
>  Standards-Version: 3.9.8
> -Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
> 0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
> dh-autoreconf, autopoint, libaudit-dev [linux-any], pkg-config, libfl-dev, 
> libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
> +Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
> 0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
> dh-autoreconf, autopoint, libaudit-dev [linux-any] , 
> pkg-config, libfl-dev, libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, 
> libxml2-utils, w3m
>  Build-Conflicts-Indep: fop
>  Build-Conflicts: libdb4.2-dev, libxcrypt-dev
>  Vcs-Bzr: https://alioth.debian.org/scm/loggerhead/pkg-pam/debian/sid
> diff -u pam-1.1.8/debian/rules pam-1.1.8/debian/rules
> --- pam-1.1.8/debian/rules
> +++ pam-1.1.8/debian/rules
> @@ -18,10 +18,10 @@
>  dl = $(d)/local
>  
>  %:
> - dh $@ --with quilt,autoreconf
> + dh $@ --with quilt,autoreconf,dwz --parallel
>  
>  # avoid libaudit-dev when bootstrapping
> -ifneq (,$(filter $(DEB_BUILD_PROFILE),stage1))
> +ifneq (,$(filter pkg.pam.noaudit,$(DEB_BUILD_PROFILES)))
>CONFIGURE_OPTS += --disable-audit
>  endif  
>  

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


signature.asc
Description: PGP signature

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Thomas Dickey]

On Tue, Jan 01, 2019 at 12:28:38PM -0500, Thomas Dickey wrote:
> On Mon, Dec 31, 2018 at 02:32:58PM -0500, Thomas Dickey wrote:
> > On Mon, Dec 31, 2018 at 06:11:23PM +0100, Alexander Meyer wrote:
> > > * Thomas Dickey  [2018-12-31 00:51]:
> > > 
> > > > On Sun, Dec 30, 2018 at 06:26:44PM +0100, Alexander Meyer wrote:
> > > > ...
> > > >> This is the behaviour I get across xterm versions:
> > > >> (everything with libfontconfig1 2.13.1-2)
> > > >> 
> > > >> fonts.conf enabled:
> > > >> 337: works
> > > >> 338: segfault
> > > >> 340: segfault
> > > >> 341: segfault
> > > > 
> > > > Can you make a backtrace for #341, please?
> > > 
> > > Here it is:
> > 
> > thanks.  I added some notes, but have not been able to reproduce the 
> > problem.
> 
> Looking at this again, I saw (using XFT_DEBUG=3 and the -report-fonts option)
> that the fallback was using unifont.  Removing that got it to break (I'll
> see whether the bug lies in Xft or fontconfig, at least).

The latter.   Here's a fix for fontconfig that eliminates this particular crash.

--- fontconfig-2.13.1/src/fccfg.c.orig  2019-01-01 17:05:49.0 -0500
+++ fontconfig-2.13.1/src/fccfg.c   2019-01-01 18:56:05.547070797 -0500
@@ -978,9 +978,14 @@
 FcValuev, vl, vr, vle, vre;
 FcMatrix   *m;
 FcChar8 *str;
-FcOp   op = FC_OP_GET_OP (e->op);
+FcOp   op;
 FcValuePromotionBuffer buf1, buf2;
 
+if (e == 0) {
+   op = FcOpNil;
+} else {
+   op = FC_OP_GET_OP (e->op);
+}
 switch ((int) op) {
 case FcOpInteger:
v.type = FcTypeInteger;

(The bug should be reassigned to the libfontconfig1 package).

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#917247: udev: Many modules are no longer automatically loaded at boot

[gregor herrmann]

On Tue, 01 Jan 2019 16:52:31 +0100, Michael Biebl wrote:

> Am 01.01.19 um 01:40 schrieb gregor herrmann:
> > [0] The initialization problems, with loads of:
> > WARNING: Device /dev/xxx not initialized in udev database even after 
> > waiting 1000 microseconds.
> 
> Is that the only error message from udev?
> Have you tried running udev with udev debug logging enabled (see
> /etc/udev/udev.conf).
> Maybe a debug log provides more hints what's going wrong.

Thanks for your quick reply and your debugging hints.

This afternoon I tried to reproduce the issues in a VM but
interestingly both didn't show up there (neither the missing modules
nor the lvm troubles). -- No idea which difference between the VM and
my real system is responsible here.


So I tried on my laptop now.

This is amd64 with the current 4.19 kernel from unstable, sysvinit,
luks+lvm on the internal SSD and an external (USB) disk.


Yesterday I downgraded udev to 239-15 and lvm2 to 2.02.176-4.1 to get
back a working system.


Now I first saved the ouptput of lsmod (attachment
lsmod.udev-239-15), updated udev to 240-2, turned on debugging
(udev_log=debug; hope that's correct?), and rebooted.


What I then found again was a massive amount of not loaded modules.
For comparison cf. attachment lsmod.udev-240-2.

No visible lvm troubles at that point.


Then I updated lvm2 to 240-2, and already at the installation I got:

#v+
Installing new version of config file /etc/lvm/lvm.conf ...

[] Setting up LVM Volume Groups...  WARNING: Device /dev/sda not 
initialized in udev database even after waiting 1000 microseconds.
  WARNING: Device /dev/dm-0 not initialized in udev database even after waiting
1000 microseconds.
  WARNING: Device /dev/sda1 not initialized in udev database even after waiting
1000 microseconds.
[etc.]
#v-


After a reboot I got the exakt same WARNINGS at "Setting up LVM
Volume Groups..." during startup, and also on everything related to
lvm, like plain `lvs' etc.


Lines related to udev in the syslog are rare:

with old lvm2:

Jan  1 23:29:56 jadzia kernel: <1055>[   18.202686] systemd-udevd[548]: Set 
children_max to 40
Jan  1 23:29:56 jadzia kernel: <1055>[   18.202749] systemd-udevd[548]: 
Dedicated cgroup not found: No medium found
Jan  1 23:30:02 jadzia kernel: <1055>[   32.006943] systemd-udevd[548]: 
Validate module index
Jan  1 23:30:02 jadzia kernel: <1055>[   32.006954] systemd-udevd[548]: Check 
if link configuration needs reloading.
Jan  1 23:30:08 jadzia kernel: <1055>[   38.494397] systemd-udevd[548]: Cleanup 
idle workers
Jan  1 23:30:08 jadzia kernel: <1055>[   38.494798] systemd-udevd[548]: Worker 
[4333] exited
Jan  1 23:37:05 jadzia kernel: <1055>[  455.708050] systemd-udevd[548]: 
Validate module index
Jan  1 23:37:05 jadzia kernel: <1055>[  455.708083] systemd-udevd[548]: Check 
if link configuration needs reloading.

with new lvm2:

Jan  1 23:53:40 jadzia kernel: <1055>[   18.268102] systemd-udevd[534]: Set 
children_max to 40
Jan  1 23:53:40 jadzia kernel: <1055>[   18.268162] systemd-udevd[534]: 
Dedicated cgroup not found: No medium found
Jan  1 23:53:40 jadzia kernel: <1055>[   24.055069] systemd-udevd[534]: Cleanup 
idle workers
Jan  1 23:53:40 jadzia kernel: <1055>[  181.898002] systemd-udevd[534]: 
Validate module index
Jan  1 23:53:40 jadzia kernel: <1055>[  181.898028] systemd-udevd[534]: Check 
if link configuration needs reloading.
Jan  1 23:53:42 jadzia kernel: <1055>[  189.054934] systemd-udevd[534]: Cleanup 
idle workers
Jan  1 23:57:06 jadzia kernel: <1055>[  392.914786] systemd-udevd[534]: Unload 
module index
Jan  1 23:57:06 jadzia kernel: <1055>[  392.914897] systemd-udevd[534]: 
Unloaded link configuration context.
Jan  1 23:57:06 jadzia kernel: [  392.915694] systemd-udevd: 2084 output lines 
suppressed due to ratelimiting
Jan  1 23:57:06 jadzia kernel: <1055>[  392.962294] systemd-udevd[7278]: Set 
children_max to 40
Jan  1 23:57:06 jadzia kernel: <1055>[  392.962371] systemd-udevd[7278]: 
Dedicated cgroup not found: No medium found
Jan  1 23:57:29 jadzia kernel: <1055>[  416.241338] systemd-udevd[7278]: 
Validate module index
Jan  1 23:57:29 jadzia kernel: <1055>[  416.241350] systemd-udevd[7278]: Check 
if link configuration needs reloading.
Jan  1 23:58:08 jadzia kernel: <1055>[  455.156872] systemd-udevd[7278]: 
Validate module index
Jan  1 23:58:08 jadzia kernel: <1055>[  455.156901] systemd-udevd[7278]: Check 
if link configuration needs reloading.


/var/log/dmesg* has not much more:

with old lvm2:

[   18.268085] systemd-udevd[534]: Unknown filesystem type 62656572 mounted on 
/sys/fs/cgroup.
[   18.268097] systemd-udevd[534]: Failed to determine root cgroup, ignoring 
cgroup memory limit: No medium found
[   18.268102] systemd-udevd[534]: Set children_max to 40
[   18.268122] systemd-udevd[534]: Failed to symlink /proc/kcore to /dev/core: 
File exists
[   18.268129] systemd-udevd[534]: Failed to symlink /proc/self/fd to /dev/fd: 
File exists
[   18.268136] 

Bug#820911: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

[Samuel Thibault]

Also, we need to document it in the installation manual and the
wiki.debian.org/accessibility page.

Samuel

Bug#757550: [Pkg-openldap-devel] pre-bug discussion: "Backup path (...) unknown (...). Giving up..."

[Ryan Tandy]

Hi,

The issue you are describing is tracked as bug #757550. CCing it now.

https://bugs.debian.org/757550

On Mon, Dec 31, 2018 at 09:34:16PM +0100, pedeb wrote:

Sorry if this bug is already documented. At least I want to do some
comments about what I have found.

I'm setting up my first slapd and I'm doing lots of

    dpkg-reconfigure slapd

(would be nice to see idempotent slapd querying style, but you have
different syntax for different moments; hence, you cannot "modify" if
the item is not created; buuh)

I see that I'm reaching this error

    Backup path /var/backups/unknown-2.4.44+dfsg-5+deb9u2.ldapdb exists.
Giving up...

and then database is not being reconfigured !


Correct.


Very easy to reproduce, change the organization name (myorg) and after
that you won't see it with:

    root@host:/etc/ldap# grep -ir myorg *

but if you delete the database

    rm -rf /var/backups/unknown-2.4.44+dfsg-5+deb9u2.ldapdb

and `dpkg-reconfigure slapd` again:

    root@host:/etc/ldap# grep -ir myorg *
    slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcSuffix: dc=myorg
    slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcRootDN: cn=admin,dc=myorg


Correct.

Other than having to manually delete the previous backup, did it do 
roughly what you would have expected?



I'm new to debconf stuff so I started looking at it [1]. I appreciate if
you point me to a reference to understand it better.


For debconf itself, see the debconf-devel(7) man page:

https://manpages.debian.org/stretch/debconf-doc/debconf-devel.7.en.html


It was a surprise to see the same function (that is related to this
bug), is in different files (is this in general for all debian
packages?). I thought that it should be just in one place and source it
to all this scripts - well, that's probably autogenerated and I would
like to know what is the official procedure of touching it.


This is a custom thing in the openldap source package. The inclusion is 
done because there isn't a good place to put a library that could be 
sourced; postinst could source things from /usr/share but that doesn't 
work for e.g. config or preinst.


The common part is in slapd.scripts-common:

https://sources.debian.org/src/openldap/2.4.47+dfsg-1/debian/slapd.scripts-common/

and the snippet that includes it into every maintainer script is here:

https://sources.debian.org/src/openldap/2.4.47+dfsg-1/debian/dh_installscripts-common/

That in turn is invoked from debian/rules:

https://sources.debian.org/src/openldap/2.4.47+dfsg-1/debian/rules/#L205

You can find all this by downloading the source package for the version 
you have installed (apt-get source openldap), or clone the git repo 
where the development happens:


https://salsa.debian.org/openldap-team/openldap

It would be nice to know what is the script executed when I install 
(apt install slapd) and when I dpkg-reconfigure it (ok, for 
dpkg-reconfigure it is /var/lib/dpkg/info/slapd.postinst)


The dpkg-reconfigure case is mentioned in debconf-devel(7). The others 
(installation etc) are in Policy:


https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called
https://www.debian.org/doc/debian-policy/ap-flowcharts.html


Well, inside that function, receive an argument that if is null then
"unknown" is set

    # Usage: move_old_database_away  []
    suffix="${2:-unknown}"

trace is:

    compute_backup_path
    move_old_database_away
    create_new_configuration

as you see in [1]

is called without a second argument (hence, it is unknown)

    move_old_database_away /var/lib/ldap

if it is not unknown (putting an argument to it), the procedure is still
failing because the procedure does not able to handle multiple backups
in case of dealing with the same database (myorg or unknown for example)
- a workaround is necessary to fix this


That is all correct, and thanks for detailing it.

We could try harder to guess a suffix instead of "unknown", but that 
might still be the best we can do in some cases, f.ex. if /var/lib/ldap 
just contains subdirectories such as dc=example,dc=com and cn=accesslog.


Dealing with multiple backups (reconfiguring the same version multiple 
times, or attempting a failed upgrade starting from the same version) 
still needs to be done, and I haven't settled on a solution for that 
yet, other than it likely involves a timestamp. There is existing code 
for that in compute_backup_path but it isn't used because OLD_VERSION is 
always set.



Sorry, I feel I'm not reporting this appropiately. But I started looking
at this without having time and I wanted to share my findings; but I
know this looks like incomplete thing.


This is fine, thanks for sharing your thoughts! Please CC the bug with 
any further comments or suggestions.


cheers,
Ryan

Bug#820911: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

[Samuel Thibault]

Hello,

Holger Wansing, le mar. 01 janv. 2019 23:40:29 +0100, a ecrit:
> I wonder why this shouldn't be possible to solve ...

Essentially because it somehow got out of my radar and nobody else seems
to have cared about it.

> And appending "theme=dark" instead of "speakup.synth=soft" should be all 
> that's
> needed to boot with high-contrast theme.

For that example, yes.  I'm a bit worried by a potential
proliferation of shortcuts in the boot menu.  In
https://lists.debian.org/debian-boot/2016/01/msg00346.html we discussed
having shortcuts within the installer itself to change colors (which can
be more useful than just having a "dark" theme).  Later on we discussed
how it could be made easier to append kernel parameters (pressing
tab was easy in syslinux, grub doesn't have such easy way yet) since
it's needed for various cases anyway.  We can also as well just add a
dark-theme shortcut indeed.  I guess 'c' as "contrast" could be a better
shortcut than 'v'? (speech and braille, using other shortcuts, are also
for visual impairement).

> I have played with the syslinux config for legacy BIOS mode, and as far as I
> can test, it works for the netboot-gtk image, see the patch attached plus 
> some 
> new files that need to be added (for debian-installer/build/boot/x86).

For syslinux it was relatively simple to get theme=dark appended to the
kernel line, it's more grub which needs to be given a shortcut.

> Like I said, other parts than netboot-gtk (for multi-arch CDs for example )
> are untested.

Yes, it takes some work to test all situations.

Samuel

Bug#917869: python-escript FTBFS on armhf, mips, mipsel and mips64el

[Adrian Bunk]

On Mon, Dec 31, 2018 at 06:51:12AM +, peter green wrote:
>... while the mips and mipsel builds ran out of virtual memory.
> 
> It may be worth playing with the settings, the first thing to try is probably 
> -Wl,-no-keep-memory , if that fails it may be worth trying optimising for 
> size ( -Os instead of -O2 )

I'd be surprised if -Os would help.

Most of the time the mips/mipsel build can be fixed by appending -g1 to 
the CXXFLAGS, overwriting the default -g (which is -g2).

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#917788: libmedc11: Overwrites a file from libmedc1v5

[Andreas Beckmann]

On Sun, 30 Dec 2018 09:21:03 -0600 Kurt Kremitzki  wrote:
> I was just about to open a bug on this same issue. It's actually present
> in both libmed11 and libmedc11. Instead of Conflicts, they both need
> Breaks + Replaces, see Policy 7.6 [1] or #906110 [2] for a similar

In this special case, you probably need to add
  Breaks+Replaces: libmed1v5 (>= 4)
respectively
  Breaks+Replaces: libmedc1v5 (>= 4)
since the versions before 4 should not have any file conflicts.


Andreas

Bug#917607: udev 240 Makes System Unbootable; rootfs Not Found

[Leo L. Schwab]

On Tue, Jan 01, 2019 at 04:50:51PM +0100, Michael Biebl wrote:
> Am 31.12.18 um 00:04 schrieb Leo L. Schwab:
> > 'lsmod' prints nothing.  /proc/modules is empty.
> > 
> >> ls -la /dev
> > 
> > No block devices appear to be listed.  (Screen photos available upon
> > request.)
> 
> Hm, this is very strange.
> Block devices such as /dev/sd? are directly created by the kernel and
> made available via devtmpfs. Mounting /proc and /dev is one of the first
> things done in
> /usr/share/initramfs-tools/init
> way before systemd-udevd is started.
> If you have no block devices at all, I'm at a loss what's going wrong.
> 
What's going wrong is that there are no kernel modules loaded,
including 'ahci' which runs the SATA bus.

Just for laughs, I re-installed udev 240-2 and rebooted.  As before,
the boot failed, leaving me at an initramfs prompt.  'lsmod' reported no
kernel modules loaded, and the directory /dev/disk did not exist.

I then ran 'modprobe ahci' at the command prompt, and immediately
heard some brief chattering from the disks.  I then found the /dev/sd*
devices had been created, and the /dev/disk tree had been populated,
including /dev/disk/by-uuid.  'lsmod' now reported sd_mod, sr_mod, cdrom,
ahci, libahci, libata, and scsi_mod as loaded.

So, something that used to trigger kernel module loading isn't
happening anymore.

BTW, my rootfs is not encrypted, so 'cryptsetup' isn't involved.

Schwab

Bug#917985: openfoam: Openfoam should not build (nor skip) dummy libraries

[littlejohn75]

Package: openfoam
Version: 4.1+dfsg1-2pre~6.gbpa01bff
Severity: normal

Dear Maintainer,

The libopenfoam package installs  some files with paths derived from upstream ::

Libraries in questionable paths

/usr/lib/openmpi-system/libPstream.so
/usr/lib/openmpi-system/libptscotchDecomp.so

Libraries which can be taken off the build in Debian

/usr/lib/dummy/libMGridGen.so
/usr/lib/dummy/libPstream.so
/usr/lib/dummy/libmetisDecomp.so
/usr/lib/dummy/libptscotchDecomp.so

A Debian system should not have specific directories such as openmpi-system
or dummy.

git repository g...@salsa.debian.org:littlejohn75-guest/openfoam.git contains
a number of patches ::
54_no_dummy_mpi.patch   (get rid of FOAM_MPI nonsense )
60_no_SCOTCH_ROOT.patch
61_no_metisDecomp.patch
62_no_dummy_decomposeMethod.patch
64_no_dummy_libdir.patch
  to get rid of dummy compatibility libraries with software not in Debian.

There are also some modifications of how to link the numerous programs and 
libraries
namely
 56_link_dl.patch  (get rid of zillions warnings about -ldl )
 58_simplify_LINK.patch  
 72_unused_lib_deps.patch  (do not link with a library if no symbols are used )


For the problem of potential name collisions with other packages, /usr/bin/noise
or /usr/bin/pdfPlot or /usr/lib/libsampling.so for instance, I wil open another
bug number.

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

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

Versions of packages openfoam depends on:
ii  libc62.24-11+deb9u3
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libopenfoam  4.1+dfsg1-2pre~6.gbpa01bff
ii  libreadline7 7.0-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  mpi-default-bin  1.8

Versions of packages openfoam recommends:
pn  openfoam-examples  

openfoam suggests no packages.

-- no debconf information

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع  تحياتي الخالصة  
---
F. Petitjean
Ingénieur civil du Génie Maritime.
littlejoh...@laposte.net

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. »  (R. Devos)

Bug#908650: reportbug: replaces package with source package for ROM package removal

[Sandro Tosi]

> Sometimes we need to report an RM bug against ftp.debian.org to remove
> a binary package which is no longer built.
>
> reportbug deals with this in the interface for ftp.debian.org, asking
> you for the name of the which package you want removed.
>
> But then after you specify the binary package that needs to be
> removed, reportbug switches the Subject for the bug report to the
> source package instead of the binary package.  This means the package
> needing removal is misrepresented and there is a danger the ftp team
> will remove the entire source package.  Not the outcome we want.
>
> A recent example is #907513 requesting to remove mshr-demos.
> reportbug altered the Subject to mark mshr for removal instead of
> mshr-demos. (Fortunately Adrian Bunk saw and corrected the mistake).

I'd be ok to remove the implicit conversion from binary to source
package when dealing with ftp.debian.org bugs
(https://salsa.debian.org/reportbug-team/reportbug/blob/master/reportbug/debbugs.py#L267-271)
but i need FTP masters to accept the change, here in CC

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

Bug#917656: libnet-server-mail-perl: FTBFS (failing tests)

[Dominic Hargreaves]

On Tue, Jan 01, 2019 at 10:43:20PM +0100, Xavier wrote:
> Control: reassign -1 perl-modules-5.28
> Control: severity -1 normal
> 
> Hi all,
> 
> it seems that Net::SMTP->new() fails randomly when launched during
> Net::server::Mail tests: $s is sometimes undefined after this:
> 
>   my $s = Net::SMTP->new( $host, Port => $port, Hello => 'localhost' );

What does $@ contain when this happens?

I couldn't reproduce this myself using the attached, could you look
at providing a reproducible test case?

> http://matrix.cpantesters.org/?dist=Net-Server-Mail+0.26 also shows that
> this rarely happens since the release of 5.28.0 (1/22), never before.
> 
> I added a workaround for now in libnet-server-mail-perl tests (warn and
> return when $s is undefined).

(You probably want to log $@ in this case, too).

Cheers,
Dominic.
#!/usr/bin/perl

use strict;
use warnings;
use Net::SMTP;

STDOUT->autoflush(1);

while (1) {
print ".";
my $s = Net::SMTP->new( 'localhost', Port => 25, Hello => 'localhost' );
defined $s || die $@;
}

Bug#820911: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

[Holger Wansing]

And here is a patch for grub-gencfg to add an entry to the EFI grub menu
with "theme=dark" for a graphical default install.


Holger

-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/build/util/grub-gencfg b/build/util/grub-gencfg
index aacce8285..837c51eb3 100755
--- a/build/util/grub-gencfg
+++ b/build/util/grub-gencfg
@@ -128,6 +128,7 @@ sub menuentry ($;%)
 $xattr{Auto} ||= 0;
 $xattr{Rescue} ||= 0;
 $xattr{Speech} ||= 0;
+$xattr{Dark} ||= 0;
 
 $xattr{Quiet} = !$xattr{Expert} unless defined $xattr{Quiet};
 
@@ -152,6 +153,7 @@ sub menuentry ($;%)
 push @cmdline, @OPTS;
 push @cmdline, "rescue/enable=true" if $xattr{Rescue};
 push @cmdline, "speakup.synth=soft" if $xattr{Speech};
+push @cmdline, "theme=dark" if $xattr{Dark};
 push @cmdline, "---";
 push @cmdline, "quiet" if $xattr{Quiet};
 
@@ -193,6 +195,7 @@ start_submenu("Advanced options ...", Hotkey => 'a'); {
 menuentry("... Expert install with speech synthesis", Expert => 1, Speech => 1, Hotkey => 'x');
 menuentry("... Rescue mode with speech synthesis", Rescue => 1, Speech => 1, Hotkey => 'r');
 menuentry("... Automated install with speech synthesis", Auto => 1, Speech => 1, Hotkey => 'a');
+menuentry("... Graphical install with dark theme for visual impaired", Graphical => 1, Dark => 1, Hotkey => 'v');
 
 start_submenu("... Desktop environment menu ..."); {
 

Bug#917687: [3dprinter-general] Bug#917687: cura-engine: FTBFS: ./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/./obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8: undefined reference to `pth

[Adrian Bunk]

Control: reassign -1 libpolyclipping-dev
Control: forcemerge 917057 -1

On Sun, Dec 30, 2018 at 10:12:34AM +0100, Gregor Riepl wrote:
> Thanks for the bug report.
> 
> Building the package used to work fine, so I'm suspecting the pthread
> detection scripts have started failing with glibc 2.28, which was updated
> recently.

There is no pthread detection issue, the problem is that blind pasting 
of the tail of the build log often only contains unrelated noise.

> I will look into the issue.
> If you have any idea why it might be occurring, please share.

The actual error is in #917057, which was already correctly marked as 
affecting src:cura-engine.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#917984: Can not link ODP with newer DPDK

[Dmitry Eremin-Solenikov]

Package: libdpdk-dev
Version: 18.11-3
Severity: important

Hello,

I've tried using migrated DPDK to build ODP. Unfortunately, ODP uses
libtool and libtool likes to rearrange linking options (see below). Thus
linked ODP library/app doesn't get all necessary PMDs.

Linking in an old way also doesn't seem possible because you've stopped
providing libdpdk.a script (which is still included in the DPDK
installation BTW, if build/install cycle is done using make).

$ pkg-config --libs libdpdk --static
-lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pipeline -lrte_table 
-lrte_port -lrte_vhost -lrte_security -lrte_sched -lrte_reorder -lrte_rawdev 
-lrte_pdump -lrte_power -lrte_meter -lrte_member -lrte_lpm -lrte_latencystats 
-lrte_kni -lrte_jobstats -lrte_ip_frag -lrte_gso -lrte_gro -lrte_eventdev 
-lrte_efd -lrte_distributor -lrte_cryptodev -lrte_compressdev -lrte_cfgfile 
-lrte_bitratestats -lrte_bbdev -lrte_acl -lrte_timer -lrte_hash -lrte_metrics 
-lrte_pci -lrte_ethdev -lrte_net -lrte_mbuf -lrte_mempool -lrte_ring -lrte_eal 
-lrte_kvargs -lrte_cmdline -lrte_kvargs -lrte_eal -lrte_ring -lrte_mempool 
-lrte_mbuf -lrte_pci -lrte_cryptodev -lrte_net -lrte_cmdline -lrte_ethdev 
-lrte_hash -lrte_timer -lrte_common_dpaax -lrte_eventdev -lrte_rawdev 
-lrte_bus_dpaa -lrte_bus_fslmc -lrte_bus_pci -lrte_common_octeontx 
-lrte_bus_vdev -lrte_meter -lrte_sched -lrte_ip_frag -lz -lrte_mempool_dpaa 
-lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni -lmnl -lmlx4 -libverbs 
-lmnl -lmlx5 -libverbs -lrte_bus_vmbus -lrte_mempool_octeontx -lpcap -lrte_port 
-lrte_lpm -lrte_acl -lrte_table -lrte_pipeline -lrte_gso -lIPSec_MB 
-lrte_common_cpt -lrte_reorder -lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 
-lrte_pmd_dpaa2_sec -lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga 
-Wl,--whole-archive -lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack 
-lrte_pmd_af_packet -lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf 
-lrte_pmd_avp -lrte_pmd_axgbe -lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt 
-lrte_pmd_cxgbe -lrte_pmd_e1000 -lrte_pmd_ena -lrte_pmd_enetc -lrte_pmd_enic 
-lrte_pmd_failsafe -lrte_pmd_fm10k -lrte_pmd_i40e -lrte_pmd_ifc -lrte_pmd_ixgbe 
-lrte_pmd_kni -lrte_pmd_liquidio -lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc 
-lrte_pmd_nfp -lrte_pmd_null -lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_ring 
-lrte_pmd_sfc -lrte_pmd_softnic -lrte_pmd_tap -lrte_pmd_thunderx 
-lrte_pmd_vdev_netvsc -lrte_pmd_vhost -lrte_pmd_virtio -lrte_pmd_vmxnet3 
-lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb -lrte_pmd_caam_jr -lrte_pmd_ccp 
-lrte_pmd_dpaa_sec -lrte_pmd_null_crypto -lrte_pmd_octeontx_crypto 
-lrte_pmd_openssl -lrte_pmd_crypto_scheduler -lrte_pmd_virtio_crypto 
-lrte_pmd_octeontx_compress -lrte_pmd_qat -lrte_pmd_zlib -lrte_pmd_dpaa_event 
-lrte_pmd_dpaa2_event -lrte_pmd_octeontx_event -lrte_pmd_opdl_event 
-lrte_pmd_skeleton_event -lrte_pmd_sw_event -lrte_pmd_dsw_event 
-lrte_pmd_bbdev_null -lrte_pmd_skeleton_rawdev -lrte_pmd_dpaa2_cmdif 
-lrte_pmd_dpaa2_qdma -lrte_pmd_ifpga_rawdev -Wl,--no-whole-archive 
-Wl,-Bdynamic -Wl,--no-as-needed -pthread -lm -ldl -lnuma -lbsd -lpcap -lcrypto 
-lz -lcrypto -ldl -pthread -lz

$ libtool --mode=link gcc /tmp/test.c -o /tmp/tes `pkg-config --libs libdpdk 
--static`
libtool: link: gcc /tmp/test.c -o /tmp/tes -Wl,--whole-archive 
-Wl,--no-whole-archive -Wl,-Bdynamic -Wl,--no-as-needed -pthread -pthread  
-lrte_telemetry -lrte_bpf -lrte_flow_classify -lrte_pdump -lrte_power 
-lrte_member -lrte_latencystats -lrte_jobstats -lrte_gro -lrte_efd 
-lrte_distributor -lrte_cfgfile -lrte_bitratestats -lrte_metrics -lrte_kvargs 
-lrte_eal -lrte_ring -lrte_mempool -lrte_mbuf -lrte_pci -lrte_cryptodev 
-lrte_net -lrte_cmdline -lrte_ethdev -lrte_hash -lrte_timer -lrte_common_dpaax 
-lrte_eventdev -lrte_rawdev -lrte_bus_dpaa -lrte_bus_fslmc -lrte_bus_pci 
-lrte_common_octeontx -lrte_bus_vdev -lrte_meter -lrte_sched -lrte_ip_frag 
-lrte_mempool_dpaa -lrte_mempool_dpaa2 -lrte_vhost -lrte_security -lrte_kni 
-lmlx4 -lmnl -lmlx5 -libverbs -lrte_bus_vmbus -lrte_mempool_octeontx -lrte_port 
-lrte_lpm -lrte_acl -lrte_table -lrte_pipeline -lrte_gso -lIPSec_MB 
-lrte_common_cpt -lrte_reorder -lrte_compressdev -lrte_pmd_dpaa -lrte_pmd_dpaa2 
-lrte_pmd_dpaa2_sec -lrte_pmd_octeontx -lrte_bbdev -lrte_bus_ifpga 
-lrte_mempool_bucket -lrte_mempool_ring -lrte_mempool_stack -lrte_pmd_af_packet 
-lrte_pmd_ark -lrte_pmd_atlantic -lrte_pmd_avf -lrte_pmd_avp -lrte_pmd_axgbe 
-lrte_pmd_bond -lrte_pmd_bnx2x -lrte_pmd_bnxt -lrte_pmd_cxgbe -lrte_pmd_e1000 
-lrte_pmd_ena -lrte_pmd_enetc -lrte_pmd_enic -lrte_pmd_failsafe -lrte_pmd_fm10k 
-lrte_pmd_i40e -lrte_pmd_ifc -lrte_pmd_ixgbe -lrte_pmd_kni -lrte_pmd_liquidio 
-lrte_pmd_mlx4 -lrte_pmd_mlx5 -lrte_pmd_netvsc -lrte_pmd_nfp -lrte_pmd_null 
-lrte_pmd_pcap -lrte_pmd_qede -lrte_pmd_ring -lrte_pmd_sfc -lrte_pmd_softnic 
-lrte_pmd_tap -lrte_pmd_thunderx -lrte_pmd_vdev_netvsc -lrte_pmd_vhost 
-lrte_pmd_virtio -lrte_pmd_vmxnet3 -lrte_pmd_aesni_gcm -lrte_pmd_aesni_mb 
-lrte_pmd_caam_jr 

Bug#820911: Accessibility for visual impaired is broken,, High-Contrast Theme is no longer activated by shortcut

[Holger Wansing]

Hi,

I wonder why this shouldn't be possible to solve ...
Nearly two years passed without progress here :-((

There were also boot entries added for speech synthesis not so long ago, for 
example.
And appending "theme=dark" instead of "speakup.synth=soft" should be all that's
needed to boot with high-contrast theme.

I have played with the syslinux config for legacy BIOS mode, and as far as I
can test, it works for the netboot-gtk image, see the patch attached plus some 
new files that need to be added (for debian-installer/build/boot/x86).

Like I said, other parts than netboot-gtk (for multi-arch CDs for example )
are untested.


Comments?
Holger



-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/build/boot/x86/menu.cfg b/build/boot/x86/menu.cfg
index 207934e8c..eaaa20967 100644
--- a/build/boot/x86/menu.cfg
+++ b/build/boot/x86/menu.cfg
@@ -16,6 +16,8 @@ menu begin advanced
 	include ${SYSDIR}adtxt.cfg
 	include ${SYSDIR}adspkgtk.cfg
 	include ${SYSDIR}adspk.cfg
+	include ${SYSDIR}addark.cfg
+	include ${SYSDIR}addarkgtk.cfg
 menu end
 include ${SYSDIR}x86menu.cfg
 label help
diff --git a/build/boot/x86/x86.cfg b/build/boot/x86/x86.cfg
index 8a2e19d3f..355e4ca9c 100644
--- a/build/boot/x86/x86.cfg
+++ b/build/boot/x86/x86.cfg
@@ -17,6 +17,8 @@ menu begin advanced
 include ${SYSDIR}x86adtxt.cfg
 include ${SYSDIR}x86asgtk.cfg
 include ${SYSDIR}x86adspk.cfg
+	include ${SYSDIR}x86addark.cfg
+	include ${SYSDIR}x86addarkgtk.cfg
 menu end
 label help
 menu label ^Help
diff --git a/build/util/syslinux-cfgs b/build/util/syslinux-cfgs
index 1041b2aa6..9d91cd4d4 100755
--- a/build/util/syslinux-cfgs
+++ b/build/util/syslinux-cfgs
@@ -38,8 +38,10 @@ create_standard_config() {
 	cp "$SRC"/syslinux.cfg "$SRC"/menu.cfg "$SRC"/stdmenu.cfg \
 	   "$SRC"/prompt.cfg "$SRC"/exithelp.cfg "$DST"/
 	cp "$SRC"/{,ad,rq}txt.cfg "$DST"/
+	cp "$SRC"/addark.cfg "$SRC"/rqdark.cfg "$DST"/
 	if [ -n "$INCLUDE_GTK" ]; then
 		cp "$SRC"/{ad,rq,}{,spk}gtk.cfg "$DST"/
+		cp "$SRC"/addarkgtk.cfg "$SRC"/rqdarkgtk.cfg "$DST"/
 	fi
 	if [ "$IS_PURE_GTK" = 1 ]; then
 		cp "$SRC"/{,ad,rq}spk.cfg "$DST"/
@@ -53,6 +55,7 @@ case $TYPE in
 		rm -f "$DST"/*gtk.cfg
 		rm -f "$DST"/*spkgtk.cfg
 		rm -f "$DST"/*spgtk.cfg
+		rm -f "$DST"/*darkgtk.cfg
 	fi
 	if [ "$IS_PURE_GTK" != 1 ]; then
 		rm -f "$DST"/*spk.cfg


addark.cfg
Description: Binary data


addarkgtk.cfg
Description: Binary data


rqdark.cfg
Description: Binary data


rqdarkgtk.cfg
Description: Binary data


x86addark.cfg
Description: Binary data


x86addarkgtk.cfg
Description: Binary data


x86rqdark.cfg
Description: Binary data


x86rqdarkgtk.cfg
Description: Binary data

Bug#749559: sysvinit: Can't power off jessie from gnome poweroff menu

[Dmitry Bogatov]

control: reassign -1 elogind

[2018-12-29 20:59] Simon McVittie 
> part   text/plain2360
> On Sat, 29 Dec 2018 at 18:34:50 +, Dmitry Bogatov wrote:
> > I have no knowledge about DE, but maybe gnome team could help?
> > 
> > Dear gnome maintainers, what command is actually invoked when power-off
> > button is pressed?
> 
> No command is invoked: it's done via IPC. gnome-shell asks gnome-session
> to power off, using the D-Bus session bus. I'm fairly sure gnome-session
> asks systemd-logind (or potentially a compatible replacement like elogind)
> to power off, using the D-Bus system bus, although I can't immediately
> find the specific code that does this. This will require a working
> logind implementation of some sort, a working polkit (policykit-1),

Thank you.

Reassigning to elogind, that, as I understand it should provide required
compatibility layer.

Bug#671589: bootlog does not work if the kernel boot command line is too long

[Dmitry Bogatov]

control: tags -1 +fixed-upstream

[2018-12-29 14:44] Jesse Smith 
> > Jesse, can you please take a look? While I believe that 4Kb for kernel
> > command line is enough, you might prefer to use getline(3).
> > 
> > As I can see bootlogd.c already uses stdio.h, but is malloc-free. Use of
> > getline(3) would break this wonderful propery :(
> 
> 
> I have accepted the patch to make the kernel command line buffer 4kB,
> with a small modification. The size of the buffer is defined as
> KERNEL_COMMAND_LENGTH so it'll be easy for distributions to patch it to
> be larger or smaller as required.

Thank you.


pgp4XrG6CNUXn.pgp
Description: PGP signature

Bug#504748: initscripts: mountall.sh must not mount ocfs2, gfs

[Dmitry Bogatov]

[2018-12-30 15:34] Adi Kriegisch 
> > sysvinit=2.93-2?
> find the refreshed patch attached. I noticed, ceph support was added.
> I've no idea if ceph also needs its own stack available before being

Thank you very much. Dear co-maintainers, any objections to applying
this patch?

> mounted. For now, I've left ceph's code path unchanged.
> > [2011-08-17 17:58] Adi Kriegisch 
> > > part 1 text/plain 769
> > > Tags: patch
> > > 
> > > Find a patch attached that really removes ocfs2 and gfs from
> > > /etc/init.d/mountnfs.sh
> > > /etc/init.d/umountnfs.sh and
> > > /etc/network/if-up.d/mountnfs
> part 1.2   text/x-patch  1773
> Index: sysvinit-2.93/debian/src/initscripts/etc/network/if-up.d/mountnfs
> ===
> --- sysvinit-2.93.orig/debian/src/initscripts/etc/network/if-up.d/mountnfs
> +++ sysvinit-2.93/debian/src/initscripts/etc/network/if-up.d/mountnfs
> @@ -84,7 +84,7 @@ set_env() {
>   # what the options are.
>   start_nfs=yes
>   ;;
> -   smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs|ceph)
> +   smbfs|cifs|coda|ncp|ncpfs|ceph)
>   ;;
> *)
>   FSTYPE=
> Index: sysvinit-2.93/debian/src/initscripts/etc/init.d/mountnfs.sh
> ===
> --- sysvinit-2.93.orig/debian/src/initscripts/etc/init.d/mountnfs.sh
> +++ sysvinit-2.93/debian/src/initscripts/etc/init.d/mountnfs.sh
> @@ -37,7 +37,7 @@ do_wait_async_mount() {
>   ;;
>   esac
>   case "$FSTYPE" in
> -   
> nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ocfs2|gfs|ceph)
> +   nfs|nfs4|smbfs|cifs|coda|ncp|ncpfs|ceph)
>   ;;
> *)
>   continue
> Index: sysvinit-2.93/debian/src/initscripts/etc/init.d/umountnfs.sh
> ===
> --- sysvinit-2.93.orig/debian/src/initscripts/etc/init.d/umountnfs.sh
> +++ sysvinit-2.93/debian/src/initscripts/etc/init.d/umountnfs.sh
> @@ -51,7 +51,7 @@ do_stop () {
>   ;;
>   esac
>   case "$FSTYPE" in
> -   nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|ceph)
> +   nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ceph)
>   DIRS="$MTPT $DIRS"
>   ;;
> proc|procfs|linprocfs|devpts|usbfs|usbdevfs|sysfs)
> @@ -60,7 +60,13 @@ do_stop () {
>   esac
>   case "$OPTS" in
> _netdev|*,_netdev|_netdev,*|*,_netdev,*)
> - DIRS="$MTPT $DIRS"
> + case "$FSTYPE" in
> +   ocfs2|gfs)
> + ;;
> +   *)
> + DIRS="$MTPT $DIRS"
> + ;;
> + esac
>   ;;
>   esac
>   done < /etc/mtab
> part 2 application/pgp-signatur   833 This is a digitally signed message p

Bug#573550: affects squeeze, package has only been updated in testing

[Dmitry Bogatov]

control: user sysvi...@packages.debian.org
control: usertags -1 sysvinit

[2018-12-29 19:51] Michael Biebl 
> Am 29.12.18 um 19:34 schrieb Dmitry Bogatov:
> > control: reassign -1 init-system-helpers
> 
> How should we handle bugs that are really sysvinit specific, even if
> they affect update-rc.d/invoke-rc.d (i.e. init-system-helpers)
> 
> No one of the current init-system-helpers is using sysvinit anymore, so
> bug reports like this one are bound to get forgotten/ignored.

Quite unfortunate situation. Okay, I will take a look at it myself.

> Should we usertag them somehow so those sysvinit specific issues are
> on the radar on the sysvinit maintainers?  This really needs a
> fix/patch from someone actively using sysvinit.

Just added usertag.

Bug#890339: gnuradio: ControlPort not usable because gnuradio was compiled without Thrift

[tony mancill]

tag -1 +upstream
forwarded -1 https://github.com/gnuradio/gnuradio/issues/2089
thanks

Package: gnuradio
Version: 3.7.13.4-2+b2
Followup-For: Bug #890339

Hi,

Debian now has Thrift 0.11 available but compilation of gnuradio fails
against versions newer than 0.10.0, so we couldn't enable now without a
patch/port to the newer Thrift release.

There is an upstream bug report of this issue:

   https://github.com/gnuradio/gnuradio/issues/2089

Cheers,
tony

Bug#917277: epstool: incorrect bounding box calculated

[Philip Rinn]

Hi David, hi Russell,

I think it is a problem of the input file - this might be linked to the
Ghostscript version used - see:


philip@debian:~$ epstool --test-eps input.eps
"gs"  -dNOEPS -dNOPAUSE -dBATCH -dNODISPLAY  "/tmp/gsview8BugKU"
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
EPSWARN FAIL: EPS file must not use /statusdict
EPSWARN WARNING: EPS file should be careful using /setmatrix
EPSWARN WARNING: EPS file should be careful using /setmatrix

EPSWARN FAIL

"gs"  -dNOPAUSE -dBATCH -sDEVICE=bbox   -c "<> setpagedevice" -f "/tmp/gsviewo4EEll"
GPL Ghostscript 9.26 (2018-11-20)
Copyright (C) 2018 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
%%BoundingBox: 589 3541 3172 3721
%%HiResBoundingBox: 589.805982 3541.013892 3171.982263 3720.131886

File has   %%BoundingBox: 71 540 176 721
Correct is %%BoundingBox: -2411 541 172 721
File bounding box needs to be larger
File used operators that sometimes cause problems in an EPS file.
File used PostScript operators that are prohibited in an EPS file.
File claims to be EPS.
FAIL: File does not comply with EPS specification.
Failed


Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Laurent Bigonville]

Le 1/01/19 à 21:35, Michael Tokarev a écrit :

01.01.2019 23:14, Laurent Bigonville wrote:
On Mon, 24 Dec 2018 09:34:16 +0300 Michael Tokarev  
wrote:



 > it doesn't really break the package in question. All these
 > packages will be of the same version anwyway, upgraded in
 > one go, at the very max there will be some docs missing
 > for a (short) while, until the next apt run.
 >
 > More, it's just one version which were like that during the
 > buster development cycle.
 >
 > Besides, *this* bug is fixed, it does declare a replacement :)

The usual way is to declare a Breaks/Replace when a file is moved 
between packages to prevent the file to be overwritten in case an 
older version of the package is installed.


I know the usual way, I just didn't think this is needed in this
particular case, as I explained before. At the very least, it is
a very minor issue, definitely not release critical.


 > I don't think this bug needs to be acted upon more. At least
 > I don't plan a new upload at least before it is migrated to
 > testing, as time is already too short and this very bug, a
 > stupid mistake, already took more time than necessary.

Well this bug has been reopened that mean that the package will never 
migrate


That's sort of unfortunate...


Indeed, it would be unfortunate to not have 3.1 in buster.

You could either close the bug if you are sure it will not cause an 
issue on upgrade, or maybe ask the release team?

Bug#917983: glib2.0: [experimental] FTBFS on arm64: tests/refcount/closures.c:298:main: assertion failed: (seen_thread2 != FALSE)

[Simon McVittie]

Source: glib2.0
Version: 2.58.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

A test fails on arm64:

START: /<>/debian/build/deb/tests/refcount/closures
init 0xfde2c210
.
.
.
.
c.
.
.
.
c.
.

stopping
stopped
**
GLib:ERROR:../../../tests/refcount/closures.c:298:main: assertion failed: 
(seen_thread2 != FALSE)

I've seen this before, in 2.54.2-3. If we run too many iterations, the
test times out; but if we run too few, the main thread starves the other
threads and the test gets through its intended number of iterations in
the main thread before the other threads have been scheduled at all, by
starving the other threads.

I'm very tempted to just knock out this particular test on arm*, at
least as a build-time test (it can stay as an autopkgtest, optionally
marked as flaky, if we want that).

smcv

Bug#917981: ITP: ruby-rails-assets-jquery.are-you-sure -- Light "dirty forms" JQuery Plugin

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-rails-assets-jquery.are-you-sure
   Version  : 1.9.0
   Upstream Author  : Chris Dance
* URL   : https://github.com/codedance/jquery.AreYouSure
* License   : Expat
   Programming Lang : Ruby
   Description  : Light "dirty forms" JQuery Plugin

Are-you-sure (jquery.are-you-sure.js) is simple light-weight "dirty form"
JQuery Plugin for modern browsers. It helps prevent users from losing
unsaved HTML Form changes by promoting the user to save/submit.

This is an unpackaged gem for diaspora and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#903448: closed by Josue Ortega (Bug#903448: fixed in asciinema 2.0.1-2)

[Andreas Beckmann]

Control: reopen -1

On 2018-12-29 17:21, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the ruby-websocket-parser,ruby-websocket package:
> 
> #903448: ruby-websocket-parser,ruby-websocket: error when trying to install 
> together

>  asciinema (2.0.1-2) unstable; urgency=medium>  .>* New maintainer 
> (Closes: #903448)
Wrong bug.


Andreas

Bug#917493: fenix: FTBFS when built with dpkg-buildpackage -A

[Adrian Bunk]

Control: clone -1 -2
Control: retitle -2 fenix FTBFS with glibc 2.28

On Fri, Dec 28, 2018 at 03:36:08PM +0100, Santiago Vila wrote:
> I wrote:
> 
> > but it also fails here:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fenix.html
> 
> Please disregard this part of my report.
> 
> Reproducible builds always do "dpkg-buildpackage", so whatever
> happens in reproducible-builds is irrelevant in this case, because we
> know no amd64 .deb will be generated.
> 
> This report is only about "dpkg-buildpackage -A", which in theory must
> still work and in practice should not be very difficult to achieve
> (well, I hope so).

The fmul issue is an unrelated second issue, I'm cloning a bug for that one.

> Tbanks.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#917980: glib2.0: [experimental] FTBFS on s390x: glib/gvariant-serialiser.c:174:g_variant_serialised_check: assertion failed (alignment & (gsize) serialised.data == 0): (4 == 0)

[Simon McVittie]

Source: glib2.0
Version: 2.58.2-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

A test fails on s390x. I think this is probably to do with either the
post-2.58.2 patches that I applied, or the GVariant fuzzing fixes in
2.58.2; it might be correlated with s390x being the only 64-bit big-endian
release architecture, or might be a quirk of s390x malloc, or might be
coincidence. (I'm glad I uploaded this to experimental first.)

It's reproducible on zelenka:

#0  0x03fffda3e66e in raise () from /lib/s390x-linux-gnu/libc.so.6
#1  0x03fffda23cec in abort () from /lib/s390x-linux-gnu/libc.so.6
#2  0x03fffde7da46 in g_assertion_message 
(domain=domain@entry=0x3fffdea47d6 "GLib",
file=file@entry=0x3fffdf063f6 "../../../glib/gvariant-serialiser.c", 
line=line@entry=174,
func=func@entry=0x3fffdf0674c <__FUNCTION__.6010> 
"g_variant_serialised_check",
message=message@entry=0x10054f190 "assertion failed (alignment & (gsize) 
serialised.data == 0): (4 == 0)")
at ../../../glib/gtestutils.c:2596
#3  0x03fffde7de20 in g_assertion_message_cmpnum (domain=0x3fffdea47d6 
"GLib",
file=0x3fffdf063f6 "../../../glib/gvariant-serialiser.c", line=,
func=0x3fffdf0674c <__FUNCTION__.6010> "g_variant_serialised_check", 
expr=,
arg1=, cmp=0x3fffdea9954 "==", arg2=, 
numtype=105 'i')
at ../../../glib/gtestutils.c:2652
#4  0x03fffde9ad4e in g_variant_serialised_check (serialised=...) at 
../../../glib/gvariant-serialiser.c:174
#5  0x03fffde9b12c in g_variant_serialised_n_children (serialised=...)
at ../../../glib/gvariant-serialiser.c:1359
#6  0x03fffde96090 in g_variant_n_children (value=value@entry=0x1009a32d0) 
at ../../../glib/gvariant-core.c:950
#7  0x03fffde916f4 in g_variant_iter_init (iter=iter@entry=0x3ffeca0, 
value=value@entry=0x1009a32d0)
at ../../../glib/gvariant.c:2976
#8  0x03fffde92a84 in g_variant_deep_copy (value=value@entry=0x1009a32d0) 
at ../../../glib/gvariant.c:5797
#9  0x03fffde95356 in g_variant_get_normal_form (value=0x1009a32d0) at 
../../../glib/gvariant.c:5891
#10 0x00018696 in test_normal_checking_tuple_offsets () at 
../../../glib/tests/gvariant.c:4941
#11 0x03fffde7d4ea in test_case_run (tc=0x10002b0d0) at 
../../../glib/gtestutils.c:2318
#12 g_test_run_suite_internal (suite=suite@entry=0x100028580, 
path=path@entry=0x0)
at ../../../glib/gtestutils.c:2403
#13 0x03fffde7d370 in g_test_run_suite_internal 
(suite=suite@entry=0x100028440, path=path@entry=0x0)
at ../../../glib/gtestutils.c:2415
#14 0x03fffde7d370 in g_test_run_suite_internal 
(suite=suite@entry=0x100028420, path=0x0)
at ../../../glib/gtestutils.c:2415
#15 0x03fffde7d7aa in g_test_run_suite (suite=0x100028420) at 
../../../glib/gtestutils.c:2490
#16 0x03fffde7d7e0 in g_test_run () at ../../../glib/gtestutils.c:1755
#17 0x00017f5c in main (argc=, argv=) at 
../../../glib/tests/gvariant.c:5055

(gdb) p *variant
$1 = {type_info = 0x3fffdf06b30 , size = 
20, contents = {serialised = {
  bytes = 0x1009a2a90, data = 0x3ffee74}, tree = {children = 
0x1009a2a90, n_children = 4398046506612}},
  state = 11, ref_count = 1, depth = 0}

smcv

Bug#907492: pam: diff for NMU version 1.1.8-3.9

[Niels Thykier]

Control: tags 907492 + pending


Dear maintainer,

I've prepared an NMU for pam (versioned as 1.1.8-3.9) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -u pam-1.1.8/debian/changelog pam-1.1.8/debian/changelog
--- pam-1.1.8/debian/changelog
+++ pam-1.1.8/debian/changelog
@@ -1,3 +1,20 @@
+pam (1.1.8-3.9) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Niels Thykier ]
+  * Enable dh_dwz to reduce the size of the dbgsym files.
+  * Remove Roger Leigh from uploaders as he has retired from
+Debian.  (Was mentioned in the last upload but not actually
+done).
+  * Pass --parallel to dh to enable building pam with multiple cores.
+
+  [ Helmut Grohne ]
+  * Convert DEB_BUILD_PROFILE=stage1 to DEB_BUILD_PROFILES=pkg.pam.noaudit.
+(Closes: #907492)
+
+ -- Niels Thykier   Tue, 01 Jan 2019 21:50:19 +
+
 pam (1.1.8-3.8) unstable; urgency=medium
 
   * Non-maintainer upload.
@@ -5,7 +22,7 @@
 chgrp in debian/rules.
   * Update pam-auth-update to detect write errors and properly
 fail when that happens.  (Closes: #880501)
-  * Remove Roger Leigh from uploaders as he has restired from
+  * Remove Roger Leigh from uploaders as he has retired from
 Debian.  (Closes: #869348)
   * Reduce priority of libpam0g to optional.
   * Rebuild with a recent version of dpkg-source, which ensures
diff -u pam-1.1.8/debian/control pam-1.1.8/debian/control
--- pam-1.1.8/debian/control
+++ pam-1.1.8/debian/control
@@ -1,10 +1,10 @@
 Source: pam
 Section: libs
 Priority: optional
-Uploaders: Sam Hartman , Roger Leigh 
+Uploaders: Sam Hartman 
 Maintainer: Steve Langasek 
 Standards-Version: 3.9.8
-Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
dh-autoreconf, autopoint, libaudit-dev [linux-any], pkg-config, libfl-dev, 
libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, libxml2-utils, w3m
+Build-Depends: libcrack2-dev (>= 2.8), bzip2, debhelper (>= 9), quilt (>= 
0.48-1), flex, libdb-dev, libselinux1-dev [linux-any], po-debconf, 
dh-autoreconf, autopoint, libaudit-dev [linux-any] , 
pkg-config, libfl-dev, libfl-dev:native, docbook-xsl, docbook-xml, xsltproc, 
libxml2-utils, w3m
 Build-Conflicts-Indep: fop
 Build-Conflicts: libdb4.2-dev, libxcrypt-dev
 Vcs-Bzr: https://alioth.debian.org/scm/loggerhead/pkg-pam/debian/sid
diff -u pam-1.1.8/debian/rules pam-1.1.8/debian/rules
--- pam-1.1.8/debian/rules
+++ pam-1.1.8/debian/rules
@@ -18,10 +18,10 @@
 dl = $(d)/local
 
 %:
-   dh $@ --with quilt,autoreconf
+   dh $@ --with quilt,autoreconf,dwz --parallel
 
 # avoid libaudit-dev when bootstrapping
-ifneq (,$(filter $(DEB_BUILD_PROFILE),stage1))
+ifneq (,$(filter pkg.pam.noaudit,$(DEB_BUILD_PROFILES)))
   CONFIGURE_OPTS += --disable-audit
 endif  
 

Bug#917656: libnet-server-mail-perl: FTBFS (failing tests)

[Xavier]

Control: reassign -1 perl-modules-5.28
Control: severity -1 normal

Hi all,

it seems that Net::SMTP->new() fails randomly when launched during
Net::server::Mail tests: $s is sometimes undefined after this:

  my $s = Net::SMTP->new( $host, Port => $port, Hello => 'localhost' );

http://matrix.cpantesters.org/?dist=Net-Server-Mail+0.26 also shows that
this rarely happens since the release of 5.28.0 (1/22), never before.

I added a workaround for now in libnet-server-mail-perl tests (warn and
return when $s is undefined).

Cheers,
Xavier

Bug#907632: [ppc64-el] Breaks building aspectc++

[Reinhard Tartler]

Hi Steve,

On 12/25/18 11:53 AM, Steve Langasek wrote:
> Package: aspectc++
> Version: 1:2.2+git20170823-7
> Followup-For: Bug #907632
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu disco ubuntu-patch
> 
> Hello,
> 
> Based on the bug history, I don't think this is a bug in gcc-8 but in
> aspectc++ (or in llvm), so I have reassigned.
> 
> I have also refined the patch provided by Frédéric, to avoid repetition in
> the code; please find it attached.
> 
> I have uploaded this patch to Ubuntu, where I confirm it fixes the build
> failure on ppc64el.
> 

I've already incorporated Frederic's patch in aspectc++ 1:2.2+git20181008-2,
which I've uploaded to unstable on Tue, 23 Oct 2018.

Maybe it would be appropriate to sync that version over to ubuntu?

Best,
Reinhard

Bug#917979: ITP: ruby-rails-assets-corejs-typeahead -- Fast and fully-featured autocomplete search library

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-rails-assets-corejs-typeahead
   Version  : 1.2.1
   Upstream Author  : Jake Harding
* URL   : https://github.com/corejavascript/typeahead.js
* License   : Expat
   Programming Lang : Ruby
   Description  : Fast and fully-featured autocomplete search library

The typeahead.js library consists of 2 components: the suggestion engine,
Bloodhound, and the UI view, Typeahead. The suggestion engine is
responsible for computing suggestions for a given query. The UI view is
responsible for rendering suggestions and handling DOM interactions.

This is an unpackaged gem for diaspora and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#917978: cyrus-common: tls_sessions.db missing, crashing startup

[George Daramouskas]

Package: cyrus-common
Version: 2.5.10-3
Severity: normal

Dear Maintainer,

   * What led up to the situation?
I wanted to install a SASL IMAP server to supplement Postfix
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
After installing the package, authentication attempts where failing, looking at
the logs I saw the following:

> Dec 31 21:19:28 bit cyrus/tls_prune[21430]: DBERROR: opening
/var/lib/cyrus/tls_sessio
ns.db: cyrusdb error
Dec 31 21:19:28 bit cyrus/master[21423]: process type:START name:tlsprune
path:/usr/sb
in/cyrus age:0.000s pid:21430 exited, status 1
Dec 31 21:19:28 bit cyrus/master[21423]: can't run startup

After creating an empty file with the correct name and ownership in the correct
place the issue was resolved



-- System Information:
Debian Release: 9.6
  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=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#908514: [rt.cpan.org #127094] possible duplicate, doubts about the patch and the original code

[Josip Rodin]

On Tue, Jan 01, 2019 at 01:42:23PM +0100, Roland Rosenfeld wrote:
> On Fr, 28 Dez 2018, Josip Rodin wrote:
> > Even if all those devices have not been RFC-compliant, I would still
> > say it's doubtful that the Net::SNMP approach of croaking with a
> > single opaque sentence -- and a code warning on top -- is the right
> > thing to do.
> 
> So what's your suggestion as a DD to handle this in Debian?
> Should I simply add Manuels patch from
> https://rt.cpan.org/Public/Bug/Display.html?id=75191#txn-1040627 to
> the Debian package and change the behavior of Debian Net::SNMP in a
> way that doesn't follow the upstream maintainer but will solve the
> problem of many people using non RFC compliant systems?
> 
> I personally tend to do it that way, but I do not really like the idea
> to ignore upstreams intention here...

I definitely wouldn't do that in the package right now. All those people we
know kludged it that way may have had their use case start working, yet they
probably didn't distribute their kludge to hundreds of thousands of other
places. If you do it, it will lead to having to support various other edge
cases that may well crop up.

Instead, I'd first have upstream speak up - is there a technical reason
why they didn't come up with any solution since 2012?

Note also my subsequent message in
https://rt.cpan.org/Public/Bug/Display.html?id=75191#txn-1826575 - I could
not reproduce the rationale for that original patch, so IMHO it's all on
pretty shaky ground.

-- 
 2. That which causes joy or happiness.

Bug#803675: [Reportbug-maint] Bug#803675: reportbug: unable to report bug on kernel

[Sandro Tosi]

I'm wondering if we should just not execute any bugscript when running
the GTK interface, adding a warning in the bugreport like "this bug
was reported running the GTK ui, thus bugscript XXX has not been
executed" (or something similar)

alternatively, we can force bugscript execution in an actual terminal,
when using GTK, it may not be visually pleasing to see a window pop
up, but it would be the safest way to gather all the information the
maintainer wants via bugscripts

what you think?

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

Bug#917977: freefem++ build depends on the no longer built libpetsc-{complex,real}3.9-dev

[Adrian Bunk]

Source: freefem++
Version: 3.61.1+dfsg1-3
Severity: serious
Tags: ftbfs

 libpetsc-{complex,real}3.9-dev have been replaced by
 libpetsc-{complex,real}3.10-dev.

Bug#915278: firetools FTCBFS: uses the wrong qmake

[Niels Thykier]

On Sun, 2 Dec 2018 12:31:17 +0100 Reiner Herrmann 
wrote:
> Control: forwarded -1 https://github.com/netblue30/firetools/commit/a9b14ef
> 
> Hi Helmut,
> 
> On Sun, Dec 02, 2018 at 12:12:18PM +0100, Helmut Grohne wrote:
> > firetools fails to cross build from source, because ./configure detects
> > the wrong qmake. It should prefer a host-prefixed one. That's achieved
> > using AC_PATH_TOOL. The attached patch implements that and makes
> > firetools cross buildable. Please consider applying it.
> 
> thanks for the patch.
> I have applied it upstream and will include it in the next upload.
> 
> Kind regards,
>Reiner

Hi Reiner,

Thanks for getting this fixed upstream. :)

Is there any chance of getting this fixed in unstable in time for buster? :)

If you need a sponsoring for a firetools/0.9.52-2 or so, please free to
ask me for a review.

Thanks,
~Niels



signature.asc
Description: OpenPGP digital signature

Bug#917976: ITP: ruby-rails-assets-fine-uploader -- Official bower build for FineUploader/fine-uploader

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name  : ruby-rails-assets-fine-uploader
   Version  : 5.13.0
   Upstream Author  : Fery Wardiyanto
* URL   : https://github.com/FineUploader/bower-dist
* License   : Expat
   Programming Lang : Ruby
   Description  : Official bower build for FineUploader/fine-uploader

An official bower build for FineUploader/fine-uploader. Fine Uploader is a
pure-JavaScript browser-based file upload library with a long list of
features that is unmatched by any other library. The power of Fine Uploader
comes from its comprehensive set of options, API methods, and
callbacks/events.

This is an unpackaged gem for diaspora and hence needs to be packaged.

Thanks,
Utkarsh Gupta

Bug#917975: libeclipse-jdt-debug-ui-java: Depends: libeclipse-debug-core-java (>= 3.15) but 3.13.100+eclipse4.10-1 is to be installed

[Adrian Bunk]

Package: libeclipse-jdt-debug-ui-java
Version: 3.10.100+eclipse4.10-1
Severity: serious

The following packages have unmet dependencies:
 libeclipse-jdt-debug-ui-java : Depends: libeclipse-debug-core-java (>= 3.15) 
but 3.13.100+eclipse4.10-1 is to be installed

Bug#917974: poppler: CVE-2018-20650: reachable abort in FileSpec::FileSpec in FileSpec.cc

[Salvatore Bonaccorso]

Source: poppler
Version: 0.69.0-2
Severity: important
Tags: patch security upstream
Forwarded: https://gitlab.freedesktop.org/poppler/poppler/issues/704

Hi,

The following vulnerability was published for poppler.

CVE-2018-20650[0]:
| A reachable Object::dictLookup assertion in Poppler 0.72.0 allows
| attackers to cause a denial of service due to the lack of a check for
| the dict data type, as demonstrated by use of the FileSpec class (in
| FileSpec.cc) in pdfdetach.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-20650
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-20650
[1] https://gitlab.freedesktop.org/poppler/poppler/issues/704

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#865792: reportbug: Allow an arbitrary MUA to be configured (patch)

[Sandro Tosi]

Hey David,

On Sat, Jun 24, 2017 at 4:15 PM David Steele  wrote:
> The "mua" option allowed a custom mua command to be defined, but it
> was only permitted for the list of 5 supported muas. This patch allows
> an arbitrary mua command string to be defined.
>
> The defined mua is set to default, and is added to the list of available
> MUAs.
>
> This also adds a 'mua-version' option, which specifies the mua
> command-line argument for 'no action', which is used in utils.mua_exists()
> as an 'are you there?" check. This only applies to custom muas. The option
> defaults to "--version".
>
> As a side effect, the overloaded definition of 'mua' in utils, where
> it could either be a string or a Mua object, depending on user options,
> is eliminated.
>
> This does not introduce any test failures.

I like your patch, but it doesnt apply anymore (apologies it took so
long to review) - would you please re-base it against the current
master? thanks!

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

Bug#904082: compiz-plugins: wallpaper plugin, the gradients are drawn with a light and a dark stripe in them

[Samuel Thibault]

Control: tags -1 + upstream help

boffi, le jeu. 19 juil. 2018 12:34:11 +0200, a ecrit:
> I indicated this as a minor issue, but compiz it's also about the looks,
> isn't it? :)

Upstream answered on https://gitlab.com/compiz/compiz-plugins-extra/issues/29

“
Yes this is the way it's programmed. I would be willing to accept a
patch to do the fullscreen gradient as an option but it might not be
easy to add, considering the state of the plugin.
”

Samuel

Bug#917973: openmsx-catapult: Depends: openmsx (< 0.14.1~) but 0.15.0-2+b1 is to be installed

[Adrian Bunk]

Package: openmsx-catapult
Version: 0.14.0-1
Severity: serious

The following packages have unmet dependencies:
 openmsx-catapult : Depends: openmsx (< 0.14.1~) but 0.15.0-2+b1 is to be 
installed

Bug#917972: transition: openexr

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: pkg-phototools-de...@lists.alioth.debian.org, ma...@debian.org

Dear Release Team,

I'm filing this bug for a new transition of openexr package.

On January 1st, 2019 a fixed testing-purpose package (2.3.0-4) has been
uploaded to experimental.

So, following a checklist obtained via 'reverse-depends', here is the
list of source packages depending on openexr and the results of the test
builds (honoring the dependency levels as reported in the checklist, as
relevant for the correct order):

### Dependency level 2 ###
 * aqsis_1.8.2-11 => OK
 * calligra_1:3.1.0+dfsg-4 => OK
 * darktable_2.6.0-1 => OK
 * enblend-enfuse_4.2-4 => FTBFS (Level 3)
 * exactimage_1.0.1-3 => OK
 * freeimage_3.17.0+ds1-5 => OK
 * gegl_0.4.12-2 => OK
 * gimp_2.10.8-2 => OK
 * imagemagick_8:6.9.10.14+dfsg-7 => OK
 * k3d_0.8.0.6-8 => OK
 * kde-runtime_4:17.08.3-2 => FTBFS (missing file)
 * kimageformats_5.51.0-1 => OK
 * kio-extras_4:18.08.3-1 => OK
 * krita_1:4.1.7+dfsg-1 => OK
 * libvigraimpex_1.10.0+git20160211.167be93+dfsg1-1 => OK
 * luminance-hdr_2.5.1+dfsg-3 => OK
 * mia_2.4.6-3 => OK
 * nvidia-texture-tools_2.0.8-1+dfsg-8.1 => OK
 * opencv_3.2.0+dfsg-5 => FTBFS (missing file)
 * openexr-viewers_1.0.1-6 => OK
 * openimageio_1.8.15~dfsg0-1 => FTBFS
 * openvdb_5.2.0-5 => OK
 * povray_1:3.7.0.8-1 => OK

### Dependency level 3 ###
 * gmic_2.4.2-2 => FTBFS (Level 2)
 * gst-plugins-bad1.0_1.14.4-1 => OK
 * hugin_2018.0.0+dfsg-3 => FTBFS (Level 2)
 * pfstools_2.1.0-3 => FTBFS (missing file)
 * synfig_1.2.1-0.1 => OK
 * vips_8.7.2-1 => FTBFS (build environment fail)

### Dependency level 4 ###
 * blender_2.79+dfsg0-5 => OK

'Level {2,3}' tags mean that the package fails because its build depends
on another package that is part of the transition and need to get
rebuilt before that same package, e.g. libvigraimpex.

I'll follow-up this bug report with any progress in fixing the packages
that are FTBFS.

Thanks for your time and patience.

mfv

Ben file:

title = "openexr";
is_affected = .depends ~ "libopenexr23" | .depends ~ "libopenexr24";
is_good = .depends ~ "libopenexr24";
is_bad = .depends ~ "libopenexr23";


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

Kernel: Linux 4.19.0-1-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


signature.asc
Description: PGP signature

Bug#917971: RM: fortune-zh [all] -- RoQA; arch:all transitional NBS package

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-CC: fortune...@packages.debian.org

fortune-zh is a transitional arch:all package that is no longer built
from source. I believe that arch:all packages are not handled by the
auto-cruft tools.

Please remove this arch:all package only.

The source and a similarly named fortunes-zh binary package should not
be removed.

Thanks,
Jeremy Bicha

Bug#915831: [Pkg-zfsonlinux-devel] Bug#915831: Bug#915831: Fwd: zfsutils-linux: Upgrading to 0.7.12 breaks during dpkg --configure

[Petter Reinholdtsen]

[Richard Laager]
> I don't think that's desirable. If this is actually required, then
> wouldn't every package trying to support systemd and sysvinit need to
> do that same?

I doubt it.  It would most likely only affect packages starting very
eary in the boot, (think rcS.d scripts), which are involved in file
system setup and file system initialization.  When I tracked this, it
was around 100 of around 100 packages with init.d scripts.

-- 
Happy hacking
Petter Reinholdtsen

Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Michael Tokarev]

01.01.2019 23:14, Laurent Bigonville wrote:

On Mon, 24 Dec 2018 09:34:16 +0300 Michael Tokarev  wrote:



 > it doesn't really break the package in question. All these
 > packages will be of the same version anwyway, upgraded in
 > one go, at the very max there will be some docs missing
 > for a (short) while, until the next apt run.
 >
 > More, it's just one version which were like that during the
 > buster development cycle.
 >
 > Besides, *this* bug is fixed, it does declare a replacement :)

The usual way is to declare a Breaks/Replace when a file is moved between 
packages to prevent the file to be overwritten in case an older version of the 
package is installed.


I know the usual way, I just didn't think this is needed in this
particular case, as I explained before. At the very least, it is
a very minor issue, definitely not release critical.


 > I don't think this bug needs to be acted upon more. At least
 > I don't plan a new upload at least before it is migrated to
 > testing, as time is already too short and this very bug, a
 > stupid mistake, already took more time than necessary.

Well this bug has been reopened that mean that the package will never migrate


That's sort of unfortunate...

Thanks,

/mjt

Bug#917822: "ValueError: Namespace Gtk not available" error in terminal while starting

[Leandro Penz]

Installing gir1.2-gtk-3.0 solved it, thanks!
I've had no other issues, the GUI is working properly.


On Tue, Jan 1, 2019 at 12:32 PM Bertrand Marc  wrote:

> Hi,
>
> Does the installation of either of the following packages solves the issue?
> |python3-gi python3-gi-cairo gir1.2-gtk-3.0|
>
> And by the way, do you get any GUI issues with GNUcash? Does it starts
> properly?
>
> Best,
> Bertrand
>

Bug#917970: libsnl: diff for NMU version 0.2.1.svn.18-1.1

[Niels Thykier]

Package: libsnl
Version: 0.2.1.svn.18-1
Severity: normal
Tags: patch  pending


Dear maintainer,

I've prepared an NMU for libsnl (versioned as 0.2.1.svn.18-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru libsnl-0.2.1.svn.18/debian/changelog 
libsnl-0.2.1.svn.18/debian/changelog
--- libsnl-0.2.1.svn.18/debian/changelog2015-05-01 17:40:16.0 
+
+++ libsnl-0.2.1.svn.18/debian/changelog2019-01-01 20:26:06.0 
+
@@ -1,3 +1,21 @@
+libsnl (0.2.1.svn.18-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Niels Thykier ]
+  * Set Rules-Requires-Root to no.
+  * Correct clean rule to delete $(INSTALL) instead of debian/%.install.
+  * Remove now redundant "Testsuite" field (dpkg-source inserts this
+automatically now).
+  * Bump debhelper compat to 12 - only difference is the version
+restriction in shlibs and smaller dbgsym packages due to dwz.
+
+  [ Helmut Grohne ]
+  * Remove wrong Multi-Arch: foreign from libsnl-dev. (Closes: #911040)
+  * Fix FTCBFS: Pass cross compiler as $(cname). (Closes: #906006)
+
+ -- Niels Thykier   Tue, 01 Jan 2019 20:26:06 +
+
 libsnl (0.2.1.svn.18-1) unstable; urgency=medium
 
   * Initial release (Closes: #783483)
diff -Nru libsnl-0.2.1.svn.18/debian/compat libsnl-0.2.1.svn.18/debian/compat
--- libsnl-0.2.1.svn.18/debian/compat   2015-05-01 17:40:16.0 +
+++ libsnl-0.2.1.svn.18/debian/compat   1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-9
diff -Nru libsnl-0.2.1.svn.18/debian/control libsnl-0.2.1.svn.18/debian/control
--- libsnl-0.2.1.svn.18/debian/control  2015-07-04 20:28:44.0 +
+++ libsnl-0.2.1.svn.18/debian/control  2019-01-01 20:26:06.0 +
@@ -1,9 +1,9 @@
 Source: libsnl
 Maintainer: Wolfgang Fuetterer 
 Section: libs
-Testsuite: autopkgtest
 Priority: optional
-Build-Depends: debhelper (>= 9)
+Build-Depends: debhelper-compat (= 12)
+Rules-Requires-Root: no
 Standards-Version: 3.9.6
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-science/packages/libsnl.git
 Vcs-Git: git://anonscm.debian.org/debian-science/packages/libsnl.git
@@ -14,9 +14,8 @@
 Section: libdevel
 Depends: libsnl0 (= ${binary:Version}),
  ${misc:Depends}
-Multi-Arch: foreign
 Description: Simple Nurbs Library (development files)
- libSNL is a library of routines used for the 
+ libSNL is a library of routines used for the
  manipulation of non-uniform rational B-Splines (NURBS).
  NURBS are widely used in programs  for computer-aided
  design (CAD), manufacturing (CAM) and engineerging (CAE)
@@ -28,13 +27,13 @@
 Architecture: any
 Depends: ${shlibs:Depends},
  ${misc:Depends}
-Multi-Arch: same 
-Pre-Depends: ${misc:Pre-Depends} 
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
 Description: Simple Nurbs Library
- libSNL is a library of routines used for the 
+ libSNL is a library of routines used for the
  manipulation of non-uniform rational B-Splines (NURBS).
  NURBS are widely used in programs  for computer-aided
  design (CAD), manufacturing (CAM) and engineerging (CAE)
- to model and representing curves and surfaces. 
+ to model and representing curves and surfaces.
  .
  This package contains the libsnl shared libraries.
diff -Nru libsnl-0.2.1.svn.18/debian/rules libsnl-0.2.1.svn.18/debian/rules
--- libsnl-0.2.1.svn.18/debian/rules2015-07-04 20:28:44.0 +
+++ libsnl-0.2.1.svn.18/debian/rules2019-01-01 20:23:44.0 +
@@ -15,19 +15,19 @@
 
 %:
dh $@ -Dsrc
-   
+
 override_dh_install: ${INSTALL}
dh_install
 
 override_dh_auto_build:
-   dh_auto_build -- CFLAGS="$(CFLAGS) $(CPPFLAGS) $(LDFLAGS)"
+   dh_auto_build -- CFLAGS="$(CFLAGS) $(CPPFLAGS) $(LDFLAGS)" 
'cname=$$(CXX)'
 
 override_dh_auto_clean:
rm -f src/*.o src/make.dep src/libSNL.so.0.2 src/snlTest
-   rm -f debian/%.install debian/%.install
+   rm -f $(INSTALL)
 
 debian/%.install: debian/%.install.in
sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' $< > $@
-   
+
 debian/%.links: debian/%.links.in
sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' $< > $@

Bug#917638: infnoise: Job dev-infnoise.device/start failed with result 'timeout'

[Stephen Kitt]

Hi Alexander,

On Sun, 30 Dec 2018 18:01:53 +0100, "Alexander Mader"  wrote:
> > Does the device itself work? With the package installed,
> > 
> > sudo infnoise --debug --no-output
> > 
> > should produce output similar to  
> 
> unfortunately, it just produces "Error:" like this:
> 
> 8< - >8 
>root@:~# infnoise --debug --no-output
>Error: 
>root@:~# 
> 8< - >8 

That suggests something wrong with the device :-(. Does it show up when you
run lsusb? Mine shows

Bus 001 Device 039: ID 0403:6015 Future Technology Devices International, Ltd 
Bridge(I2C/SPI/UART/FIFO)

dmesg might show more useful information; look around the time you plugged
the TRNG in.

Regards,

Stephen


pgp7xEtuTnYxB.pgp
Description: OpenPGP digital signature

Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Laurent Bigonville]

On Mon, 24 Dec 2018 09:34:16 +0300 Michael Tokarev  wrote:
> 24.12.2018 6:00, Andreas Beckmann wrote:
> > Followup-For: Bug #916279
> > Control: found -1 1:3.1+dfsg-2
> >
> > Hi,
> >
> > you are missing a
> > Breaks: qemu-system-data (<< 1:3.1+dfsg-1~)
> > to match the Replaces, otherwise you are permitting partial
> > upgrade/downgrade paths where files are disappearing whil
> > dpkg considers everything correctly installed.
>
> it doesn't really break the package in question. All these
> packages will be of the same version anwyway, upgraded in
> one go, at the very max there will be some docs missing
> for a (short) while, until the next apt run.
>
> More, it's just one version which were like that during the
> buster development cycle.
>
> Besides, *this* bug is fixed, it does declare a replacement :)

The usual way is to declare a Breaks/Replace when a file is moved 
between packages to prevent the file to be overwritten in case an older 
version of the package is installed.


> I don't think this bug needs to be acted upon more. At least
> I don't plan a new upload at least before it is migrated to
> testing, as time is already too short and this very bug, a
> stupid mistake, already took more time than necessary.
>

Well this bug has been reopened that mean that the package will never 
migrate

Bug#779190: SPEECH DISPATCHER FESTIVAL ERROR

[Samuel Thibault]

Control: tags -1 + moreinfo

Hello,

priyanka kaushal, le mer. 25 févr. 2015 15:56:56 +0530, a ecrit:
> now when i ran festival server  and orca festival server gives following
> error: 
> SIOD ERROR: could not open file speech-dispatcher.scm

I don't have this issue, things just work fine here, are you still
having the issue with a more recent version of Debian?

Samuel