Bug#924937: libpq5: OpenSSL license contamination of GPL reverse-dependencies

[Ansgar]

block 952399 by 924937
thanks

Ansgar writes:
> the OpenSSL ./. GPL problem (if one sees it as a problem) is larger
> than just libpq5: just looking at a small sample of the direct rdeps of
> libssl1.1, one can find the following GPL-licensed programs linking it:
>
>   cryptsetup, wesnoth, mydumper, mupdf, gatling, kopete
>
> Also amanda-client, validns as they contain patches in d/patches
> licensed under the GPL.
>
> There are probably lots more, especially when you start looking at
> libraries (and their whole dependency trees).

Or kmod (GPL-2+).

Ansgar

Bug#952506: Wired interface name maybe changed when reboot

[Michael Biebl]

Am 26.02.2020 um 05:26 schrieb wg...@china.com:
> When the wired interface was be named enp0s31f6:
> 

The journal logs as well please.

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



signature.asc
Description: OpenPGP digital signature

Bug#952570: tcpcopy: build-depends on removed package iptables-dev

[Juhani Numminen]

Package: tcpcopy
Version: 0.6.3-2.1
Severity: serious
X-debbugs-cc: peter green 

tcpcopy build-depends on removed iptables-dev. Please see Peter's message below
on how to handle the situation (from bug #951090).


On Tue, 11 Feb 2020 01:08:16 + peter green  wrote:
> Package: keepalived
> Version: 1:2.0.19-1
> Severity: serious
> 
> keepalived build-depends on iptables-dev, which is no longer built by the 
> iptables source package. It is still present in unstable as a cruft package, 
> but is completely gone from testing.
> 
> Before it's removal iptables-dev was a transitional dummy package depending 
> on a bunch of other dev packages, please determine which of those dev 
> packages your package needs and adjust your build-dependencies accordingly.

Bug#952568: RM: python-pyvcf/0.6.8+git20170215.476169c-2 -- RoQA; NVIU

[Andreas Tille]

Hi Juhani,

On Wed, Feb 26, 2020 at 08:28:54AM +0200, Juhani Numminen wrote:
> Package: ftp.debian.org
> Severity: normal
> x-debbugs-cc: debian-med-packag...@lists.alioth.debian.org
> 
> There are two versions of this package in unstable and I think the older one
> is not getting auto-crufted because the binary package python3-pyvcf has
> become a virtual package (provided by python3-vcf) in the newer one.

thanks for spotting this.  I confirm that python-pyvcf needs to be removed.

Kind regards

ANdreas.

-- 
http://fam-tille.de

Bug#902635: Closing due to lack of response.

[John Paul Adrian Glaubitz]

Control: reopen -1

On 2/26/20 1:09 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Hi! I'm closing this bug due to lack of response. Please feel free to
> reopen it or opening a new bug if you can provide us with more
> information as required.

The issue has not been fixed. Closing a bug without fixing the issue
behind it makes no sense. Bug reports are supposed to document issues,
closing reports means hiding issues.

The issue has not been properly addressed yet because it's fundamentally
difficult to fix. The bug is a result of an underlying design problem
which is a result of upstream ignoring that the upper 16 address bits
in a 64 bit physical address are reserved by Intel.

However, they have actually understood the problem now and they are
planning to address the problem in the near future since x86_64
and arm64 are expanding their virtual address spaces as well [1].

Thanks,
Adrian

> [1] https://bugreports.qt.io/browse/QTBUG-56264

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#952569: unattended-upgrades: 1.18 regression: new "Packages with upgradable origin but kept back" report section is way too verbose

[Paul Wise]

Package: unattended-upgrades
Version: 1.18
Severity: important
Usertags: verbose

The new "Packages with upgradable origin but kept back" report section
is way too verbose in 1.18. On a system with testing, unstable,
experimental (and *-debug and buildd-*), it appears that it lists every
package that has a new version in an another suite, even if the apt
pinning of that version is lower than the current version. Reporting
packages being kept back due to the local pinning isn't useful, because
that is normal and expected so it doesn't need to be reported.

As an example, here is part of mine:

Packages with upgradable origin but kept back:
 Debian unstable:
  readline-common ...
...
 Debian buildd-experimental:
  evolution ...
...
Package evolution is kept back because a related package is kept back
or due to local apt_preferences(5).
...
Package readline-common is kept back because a related package is kept
back or due to local apt_preferences(5).

$ apt policy evolution readline-common
evolution:
  Installed: 3.34.1-4
  Candidate: 3.34.1-4
  Version table:
 3.35.91-1 690
690 https://incoming.debian.org/debian-buildd buildd-
experimental/main amd64 Packages
 *** 3.34.1-4 900
900 https://deb.debian.org/debian testing/main amd64 Packages
800 https://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
readline-common:
  Installed: 8.0-3
  Candidate: 8.0-3
  Version table:
 8.0-4 800
800 https://deb.debian.org/debian unstable/main amd64 Packages
790 https://incoming.debian.org/debian-buildd buildd-
unstable/main amd64 Packages
 *** 8.0-3 900
900 https://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


-- System Information:
Debian Release: bullseye/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 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.7.5-3
ii  python3-apt1.9.7
ii  python3-dbus   1.2.16-1
ii  python3-distro-info0.23
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-136
ii  systemd-sysv244.3-1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1+b1
ii  exim4-daemon-light [mail-transport-agent]  4.93-11
ii  needrestart3.4-6
ii  powermgmt-base 1.36
ii  python3-gi 3.34.0-6

-- debconf information:
* unattended-upgrades/origins_pattern: "origin=Debian";
* unattended-upgrades/enable_auto_updates: true

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#952568: RM: python-pyvcf/0.6.8+git20170215.476169c-2 -- RoQA; NVIU

[Juhani Numminen]

Package: ftp.debian.org
Severity: normal
x-debbugs-cc: debian-med-packag...@lists.alioth.debian.org

There are two versions of this package in unstable and I think the older one
is not getting auto-crufted because the binary package python3-pyvcf has
become a virtual package (provided by python3-vcf) in the newer one.


Thanks,
Juhani

Bug#951117: libecore1: .xsession-errors eats all disk space

[Ross Vandegrift]

On Mon, Feb 24, 2020 at 01:59:31PM +0300, sergio wrote:
> On 24/02/2020 09:25, Ross Vandegrift wrote:
> Just tried, yes, I can trigger it on the clean user profile, with only
> one file left:
> 
> % cat .xsession
> enlightenment_start
> 
> Looks like you need to remove the shelf.
> 
> > If it does trigger, there might be something else different about your
> > system.
> 
> Have you exactly Maximize Fullscreen'ed? It's not just Fullscreen.

Now I can trigger the message, but not a nonstop stream.  E prints it while
opening and closing tilix, but not otherwise.  Moreover, I can only trigger it
in the same session where I do all of the config.  After logging out and back
in, the message is not printed.  Also, it doesn't happen under Xephyr at all.

Sorry but I don't think I can really help further.  Maybe the upstream folks
would be able to track something down.


For the record, the full sequence I came up with is:
0. Install tilix and E.
1. Start a fresh E profile, go through the first run wizard.
2. Delete the default shelf.
3. Open Settings
   a. Windows -> Window Geometry -> Maximization
  i. Set Policy to Fullscreen
 ii. Enable "Allow manipulation of maximized windows"
iii. Enable "Allow windows above fullscreen windows"
 iv. OK
   b. Input -> Key Bindings
  i. Add a binding for Window:State:Maximize Fullscreen
 ii. OK
4. Restart Enlightenment from the Enlightenment menu
5. Run tilix and maximize with the key binding from 3.b.i
6. Run tilix and close it immediately by exiting the terminal.

Repeat 6 a few times, eventually it logs this a few times:
ERR<2605>:eo ../src/lib/eo/eo.c:2192 efl_data_scope_get() Eo ID 
0x40098cfa is not a valid object. Current thread: main. This ID has 
probably been deleted or this was never a valid object ID. (domain=0, 
current_domain=0, local_domain=0, available_domains=[0 1], generation=fa, 
id=263, ref=1)

Ross

Bug#952312: [Pkg-javascript-devel] Bug#952312: Bug#952312: Bug#952312: node-eslint-scope: FTBFS: tests failed

[Xavier]

Le 25/02/2020 à 22:19, Jonas Smedegaard a écrit :
> Quoting Bastien ROUCARIES (2020-02-25 21:13:48)
>> Le mar. 25 févr. 2020 à 19:48, Jonas Smedegaard  a écrit :
>>
>>> control: reassign -1 node-espree
>>> control: affects -1 node-eslint-scope
>>>
>>> Quoting Xavier (2020-02-25 18:29:35)
 Le 23/02/2020 à 14:50, Lucas Nussbaum a écrit :
> During a rebuild of all packages in sid, your package failed to
> build on amd64.

 Some test are incompatible with node-espree-6. The fix could be
 simply:
>>>
>>> Certainly not a fix to disable tests.
>>>
>>> The package node-espree has exactly one reverse dependency which is
>>> node-eslint-scope, so this is a case of bad coordination.
>>>
>>> (yes, another fix would be to upgrade node-eslint-scope, but that is 
>>> more complex and less urgent, so let's roll back first and work on 
>>> going forward in experimental first
>>
>>
>>
>> Node-espree was upgraded due to not compatible with acorn6...
>>
>> So upgrade is safer
> 
> Please define "safer" in this context.
> 
>  - Jonas

Hi,



 * node-espree is a test dependency of node-eslint-scope in unstable
 * node-espree is a dependency of eslint (new package in experimental)
 * last eslint (6.8.0) depends on espree ≥ 6
 * eslint experimental version is 4.18.2
 * last eslint depends on babel 7
 * node-espree <6 is broken by acorn 6
 * acorn update is part of the difficult Node.js 12 upgrade (with
   rollup-1, gulp 4,...)

I think we should prioritize Node.js upgrade here (needs a transition),
then babel 7, then upgrade eslint to the last version

Bug#952169: libmodule-starter-plugin-cgiapp-perl: FTBFS: dh_auto_test: error: perl Build test --verbose 1 returned exit code 1

[Jaldhar H. Vyas]

On Sun, 23 Feb 2020, Lucas Nussbaum wrote:


Hi,

During a rebuild of all packages in sid, your package failed to build
on amd64.



Hi Lucas, because I have been long in responding, I just wanted to drop a 
quick note that I acknowledge your bug report.  I need to do an upstream 
release to fix all the issues and I will try and do this ASAP.


--
Jaldhar H. Vyas 

Bug#952567: libvips-dev: reduce excessive dependencies

[Helmut Grohne]

Package: libvips-dev
Version: 8.9.1-2
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:nip2

nip2 cannot be cross built from source, because its transitive
dependency on the host architecture python cannot be installed. The host
python is pulled via libvips-dev's dependency on python3-dev and
python3-all-dev. I looked into the package, but I couldn't find any
python mentioned anywhere. Why do you need these dependencies? The
changelog mentions that python bindings were recently removed. Is this a
left-over? Can you simply drop these dependencies from the libvips-dev
binary package?

Helmut

Bug#952506: Wired interface name maybe changed when reboot

[wglxy]

When the wired interface was be named enp0s31f6:


udevadm info /sys/class/net/enp0s31f6
P: /devices/pci:00/:00:1f.6/net/enp0s31f6
L: 0
E: DEVPATH=/devices/pci:00/:00:1f.6/net/enp0s31f6
E: INTERFACE=enp0s31f6
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=3512520
E: ID_NET_NAMING_SCHEME=v243
E: ID_NET_NAME_MAC=enx482ae3154ae1
E: ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd.
E: ID_NET_NAME_PATH=enp0s31f6
E: ID_BUS=pci
E: ID_VENDOR_ID=0x8086
E: ID_MODEL_ID=0x15bb
E: ID_PCI_CLASS_FROM_DATABASE=Network controller
E: ID_PCI_SUBCLASS_FROM_DATABASE=Ethernet controller
E: ID_VENDOR_FROM_DATABASE=Intel Corporation
E: ID_MODEL_FROM_DATABASE=Ethernet Connection (7) I219-LM
E: ID_MM_CANDIDATE=1
E: ID_PATH=pci-:00:1f.6
E: ID_PATH_TAG=pci-_00_1f_6
E: ID_NET_DRIVER=e1000e
E: ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link
E: ID_NET_NAME=enp0s31f6
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/enp0s31f6 
/sys/subsystem/net/devices/enp0s31f6
E: TAGS=:systemd:





When the wired interface was be named eth0:


udevadm info /sys/class/net/eth0
P: /devices/pci:00/:00:1f.6/net/eth0
L: 0
E: DEVPATH=/devices/pci:00/:00:1f.6/net/eth0
E: INTERFACE=eth0
E: IFINDEX=2

E: SUBSYSTEM=net






Best regards,
Gulfstream

Bug#952566: RFP: zsh-autosuggestions -- Fish-like fast/unobtrusive autosuggestions for zsh

[Franklin Yu]

Package: zsh-autosuggestions
Severity: normal

* Package name: zsh-autosuggestions
 Version : 0.6.4
 Upstream Author : Eric Freese (ericdfre...@gmail.com)
* URL : https://github.com/zsh-users/zsh-autosuggestions
* License : MIT
 Programming Lang: Zsh
 Description : Fish-like fast/unobtrusive autosuggestions for zsh

Note that Eric is the current maintainer; according to the license file,
previously it was maintained by Thiago de Arruda (tpadilh...@gmail.com).

Homebrew package definition might be helpful:
https://formulae.brew.sh/formula/zsh-autosuggestions

Bug#952555: azure-uamqp-python: please make the build reproducible

[Chris Lamb]

Hi Luca,

> The diffoscope html report is attached, but can't make head or tail of
> it - it shows differences in the shared object. Does it ring any bell?

At a glance I cannot. However, I might suggest running it again; do
you get the same differences, if you know what I mean?


Best wishes,

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

Bug#951302: timeshift: /mnt is used programmatically

[Steve Meliza]

The Timeshift author has informed me that he will fix this bug in an
upstream release before the end of March.

Bug#952501: slapd: README.Debian does not note that databases are created

[Karl O. Pinc]

On Tue, 25 Feb 2020 15:54:04 -0800
Ryan Tandy  wrote:

> Thanks a lot for this.

Your welcome.

> I have made an editorial change to capitalize "DN" everywhere

Great idea.  Much more clear.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#888675: nudging...

[Jonas Smedegaard]

Nudging this closed bug (again) to avoid auto-kicking from testing

-- 
 * 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#952565: Please depend on libkf5windowsystem

[Alf Gaida]

Package: liblxqt0-dev
Version: 0.14.2~71-g3aefce0-1
Severity: normal

Would really reduce surprises :P

Cheers Alf

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

Kernel: Linux 5.4.18-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages liblxqt0-dev depends on:
ii  liblxqt0 0.14.2~71-g3aefce0-1
ii  libqt5xdg-dev3.4.1~4-gfc98e31-1
ii  libqt5xdgiconloader-dev  3.4.1~4-gfc98e31-1
ii  lxqt-build-tools 0.7.0~7-g0fc5eeb-1

liblxqt0-dev recommends no packages.

liblxqt0-dev suggests no packages.

-- no debconf information

Bug#952414: buster-pu: package ncbi-blast+/2.8.1-1+deb10u1

[Aaron M. Ucko]

"Adam D. Barratt"  writes:

> Please go ahead.

Thanks!  Uploaded.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Norbert Preining]

Hi Karl,

> If all the hyperref deps are in c-latex (I just moved them), and the
> Debian c-latex is installed, why won't hyperref then work?

That of course works, thanks for moving.

> It would be nice to have some other kind of grouping in TL, too, so that
> XYZ packages can be somehow downloaded/installed together. That's part
> of why TL installation takes so long (per previous discussion), doing
> all the pkg overhead 3700 times.

Schemes could be used for that, but nobody has created more interesting
schemes. And the collections have the one big advantage that they are
non-overlapping.

> I can't think of any good solution to any of it :(.

There really isn't any but packaging each one separately for Debian.
This needs to be done fully automatic, of course.

Nothing I will take up, especially considering my current (non-)relation
with Debian.

Norbert

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

Bug#861907: scrot not supporting multiple displays

[Eriberto Mota]

Em ter., 25 de fev. de 2020 às 18:21, Stefan Pietsch
 escreveu:
>
> On 2017-05-05 15:47, Dale Harris wrote:
> > Package: scrot
> > Version: 0.8-18
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > Trying to use scrot -m or --multidisp doesn't appear to work. Man page
> > says it should grab a shot from each display and then merge the image,
> > however it only appears to be taking a shot from one. Is there something
> > else that has to be configured/installed to allow this to work?
> >
> >
> > -- System Information:
> > Debian Release: 9.0
> >APT prefers unstable
> >APT policy: (500, 'unstable'), (500, 'testing')
> > Architecture: amd64
> >   (x86_64)
> > Foreign Architectures: i386
> >
> > Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> > Shell: /bin/sh linked to /bin/dash
> > Init: systemd (via /run/systemd/system)
> >
> > Versions of packages scrot depends on:
> > ii  giblib11.2.4-11
> > ii  libc6  2.24-10
> > ii  libimlib2  1.4.8-1
> > ii  libx11-6   2:1.6.4-3
> >
> > scrot recommends no packages.
> >
> > scrot suggests no packages.
> >
> > -- no debconf information
>
>
> Dear bug reporter and maintainer,
>
> this is not reproducible with scrot version 1.2-2 from Debian unstable.
>
> Regards,
> Stefan

Thanks Stefan,

After several tests, this bugs seems fixed. So, I am closing this bug.

Regards,

Eriberto

Bug#952501: slapd: README.Debian does not note that databases are created

[Ryan Tandy]

Control: tag -1 pending

Hello Karl,

Thanks a lot for this.

I have made an editorial change to capitalize "DN" everywhere, but 
otherwise committed your v2 patch basically as is.


Thanks for your contribution, it will be included in Debian bullseye.

https://salsa.debian.org/openldap-team/openldap/-/commit/563cb8687d330b8cc72116c47f46ca8bcb8ffdbd

cheers,
Ryan

Bug#952501: slapd: README.Debian does not note that databases are created

[Karl O. Pinc]

Hi Ryan,

On Tue, 25 Feb 2020 11:07:57 -0800
Ryan Tandy  wrote:

> I made a few adjustments to your text, and noted a couple of other 
> things that tend to surprise new users.
> 
> I wonder if you have any feedback on this version (below).

I've attached a new patch, based on yours.

Mentioned that MDB is the default backend.

Tweaked various sentences, in various ways.  Tried to simplify
and shorten sentences.  This necessarily makes the document
a little longer, but friendlier.

Used the word "entry" and in general made more clear that
it's all about altering ldap entry/attributes in various
ldap databases.

Got rid of extra words.

Got rid of "will".  It is rarely useful in technical docs.

Made a practice of putting dn-s in double quotes, to set them
off from the other text.  What do you think?

Consistently use "configuration database" and "directory database" as
the identifiers for the 2 initial ldap dbs.  Use "directory
administrator" to identify the admin entry.

Tried to make a distinction between an administrator, a person,
and a the directory administrator LDAP entry in the DIT.
Let me know how well this worked.

Note that the dn of the entry in the configuration DIT
defaults to "olcDatabase={1}mdb,cn=config", but is not
_always_ this.  (It would be different if you chose a different
back-end.)  This is only mentioned and not elaborated on.

Made clear (hopefully) the options used by the Unix root user
to maintain the database.

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein
--- README.Debian	2020-02-24 21:24:25.635042167 -0600
+++ slapd.README.Debian	2020-02-25 17:27:55.126748802 -0600
@@ -11,15 +11,75 @@
   the OpenLDAP Admin Guide for more information, including configuration
   examples for common use cases. 
 
-The OpenLDAP configuration
+Initial slapd configuration
 
-  Since version 2.4.23-3 the configuration of OpenLDAP has been changed to
-  /etc/ldap/slapd.d by default.  The OpenLDAP packages in Debian provide an
+  Upon installation the slapd package performs a number of tasks.  It
+  initializes the configuration database, stored in LDAP and rooted at
+  the dn "cn=config".  It creates an initial directory database with a
+  dn rooted at a suffix derived from the DNS domain configured in
+  debconf (e.g.  "dc=example,dc=com").  The default backend for the
+  directory database is the MDB backend.  An administrative identity
+  LDAP entry, with a dn of "cn=admin,", is added to the
+  directory database.  This LDAP entry for the directory administrator
+  is given the password configured in debconf, or a randomly generated
+  password if none was set.
+
+  If desired, a new configuration and directory database can be
+  created by running, as root:
+
+dpkg-reconfigure slapd
+
+  Caution: this command completely resets the configuration and all
+  LDAP directory data (saving a backup in /var/backups), resetting
+  slapd to a new initial state.
+
+  The configuration database ("cn=config") and directory database
+  ("dc=,dc=") have different permissions. Upon
+  installation, the Unix root user has permission to manage the slapd
+  configuration ("cn=config") database.  The LDAP directory
+  administrator entry ("cn=admin,") has permission to manage
+  the directory database ("dc=,dc="). This policy is
+  specific to Debian.
+
+  The directory administrator's password is stored in two places. The
+  password is in the olcRootPW attribute of the LDAP configuration
+  database's LDAP entry describing the directory database; the default
+  dn of this configuration entry is "olcDatabase={1}mdb,cn=config".
+  And the password is also in the userPassword attribute of the
+  LDAP directory administrator entry itself; the default dn of the
+  directory administrator entry is "cn=admin,".
+
+  If the administrator password needs to be changed it should be
+  updated in both places.  The ldapmodify(1) and ldappasswd(1)
+  commands may be used, to update the "olcDatabase={1}mdb,cn=config"
+  entry and the "cn=admin," entry, respectively.  These
+  commands are found in the ldap-utils package.
+
+  Should you change the directory administrator's identity be sure to
+  update the database's configuration, the olcRootDN and olcRootPW
+  attributes of the "olcDatabase={1}mdb,cn=config" entry, as well as
+  add a directory administrator entry for the new administrator to the
+  "dc=,dc=" directory.
+
+Maintaining the slapd configuration
+
+  Since version 2.4.23-3 the default configuration of OpenLDAP has
+  been changed to "/etc/ldap/slapd.d"; configuration is stored in an
+  LDAP directory.  The OpenLDAP packages in Debian provide an
   automatic migration to the new configuration style. With the new
-  configuration style it is possible to change values on the fly without
-  restarting slapd.  Changes are made through the use of ldif files and
-  ldap{add,modify}.  In Debian you can use the 

Bug#947317: uscan: Please allow .gitattributes override

[Robin Gustafsson]

Control: tags -1 patch

Hi,

I've submitted a patch (merge request) for this on Salsa [1].

[1] https://salsa.debian.org/debian/devscripts/-/merge_requests/174

Regards,
Robin

Bug#951564: stretch-pu: package postfix/3.1.14-0+10debu1

[Scott Kitterman]

On Tuesday, February 25, 2020 4:18:26 PM EST Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2020-02-18 at 00:56 -0500, Scott Kitterman wrote:
> > This is the next in the series of postfix 3.1 updates.  It includes
> > the postfix 3.1 relevant fixes from 3.4.8 and 3.4.9 (as there was no
> > companion 3.1 release with 3.4.8).  The only other change is to add
> > the upstream signing key to make it easier for me to verify upstream
> > signatures when preparing future updates.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Uploaded.  Thanks,

Scott K


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

Bug#951563: buster-pu: package postfix/3.4.8-0+10debu1

[Scott Kitterman]

On Tuesday, February 25, 2020 4:19:42 PM EST Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Tue, 2020-02-18 at 00:50 -0500, Scott Kitterman wrote:
> > This is the latest in the series of postfix 3.4 maintenance updates
> > for buster.  The version is in bullseye already and I have it running
> > locally without issue.  In addition to the upstream bugfixes, there
> > are two Debian packaging fixes: a correction to the lmtp man page
> > redirect and a sysv init update that fixes a regression in the last
> > update (that solved the problem that it was intended to solve, but
> > caused problems with multiple postfix instances).  This update has
> > been tested by end users to work in both configurations.  Neither fix
> > has any regression risk for users of Debian's default init
> > system.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Uploaded. Thanks,

Scott K


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

Bug#952399: OpenSSL linking without license exception

[Bastian Germann]

Am 25.02.20 um 23:38 schrieb Marco d'Itri:
> Control: found 26+20191223-1
>
> On Feb 23, Bastian Germann  wrote:
>
>> All of the GPL-2+ licensed executables contained in the kmod
>> binary package link to libcrypto even though they do not have any
>> OpenSSL license exception. ftp-master considers this a serious
>> issue. So please remove this optional dependency or ask upstream
>> for a license exception.
> The large number of contributors to kmod obviously makes impossible
>  getting a license exception, also considering that only Debian
> cares about linking GPL'ed software with OpenSSL.
>
> Since only libkmod (which is LGPL'ed), and not the actual commands,
> is linked with OpenSSL, and the libkmod symbols do not change
> depending if OpenSSL support is enabled or not, and the patches
> which introduced OpenSSL support did not touch the commands, then I
> think that the commands are obviously not a derivative work of
> OpenSSL. You can also easily verify that the commands are not
> linked with OpenSSL by looking at the build logs of the package.

$ ldd /bin/*mod /sbin/*mod*

/bin/kmod:
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/bin/lsmod:
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/sbin/depmod
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/sbin/insmod:
libcrypto.so.1.1 =>
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1/sbin/lsmod:
libcrypto.so.1.1 =>
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1/sbin/modinfo:
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/sbin/modprobe:
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
/sbin/rmmod:
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

buster's amd64 binaries are actually directly linked with libcrypto;
readelf says "(NEEDED)  Shared library: [libcrypto.so.1.1]"

Even if they were linked with libcrypto via libkmod it would not make
any difference.

> Also, the next major release of OpenSSL will be relicensed with the
>  ASLv2 anyway, which is compatible with the GPLv3.

That will help for bullseye+ but not for buster.

> For these reasons I have no interest and no plans to do anything
> about this, and I am quite annoyed that I had to spend my time
> researching these details and then explaining them to you.

You don't care and I am fine with that since I am not the maintainer
of the package. But I wanted to report the issue anyway since the
legal team's comments on that matter are unanimous.

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Karl Berry]

STill, also this will not work for Debian, as here only collection <->
collection relations can be tracked.

If all the hyperref deps are in c-latex (I just moved them), and the
Debian c-latex is installed, why won't hyperref then work?

force me to package at the collection level was a failure 

The 3700+ packages that would result from packaging at the package level
doesn't seem so desirable either :(. I know Fedora does that, though I
don't know if they include everything in TL.

and just build **one** super-big packages ... probably the best idea.

Then people will complain it is too big and has tons of stuff "no one"
uses.

It would be nice to have some other kind of grouping in TL, too, so that
XYZ packages can be somehow downloaded/installed together. That's part
of why TL installation takes so long (per previous discussion), doing
all the pkg overhead 3700 times.

I can't think of any good solution to any of it :(.

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Norbert Preining]

Hi Karl,

> I think we should add all known hyperref deps to c-latex, anyway.

STill, also this will not work for Debian, as here only collection <->
collection relations can be tracked.

(I more and more think debian-devel's decision back 15 years ago to
force me to package at the collection level was a failure - the reason
given back then is that there are too many packages introduced, looking
at the r-* rust-* node-* proliferation, I can't disagree more)

> Because, why not. It's improbable that anyone would install latex and
> not use hyperref, nowadays. I'll do that.

Indeed, that is true.

I'm not sure what I will do on the Debian side. Maybe drop all the stuff
and just build **one** super-big packages ... probably the best idea.

Best

Norbert

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

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Karl Berry]

Subject: colletion-latexbase hyperref.sty depends on collection-latexextra
 letltxmacro.sty

Ok, but before I change anything: hyperref has a package-level
dependency on letltxmacro (and a bunch of others). Why doesn't that
suffice?

As far as I can see (per previous mail to the tex-live list), it is not
possible to make collections perfectly self-contained. However, in the
case of hyperref, if package-level dependencies aren't enough, presumably I
should add all its dependencies to c-latex, where hyperref itself is. -k

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Karl Berry]

Thanks for the explanation.

I think we should add all known hyperref deps to c-latex, anyway.
Because, why not. It's improbable that anyone would install latex and
not use hyperref, nowadays. I'll do that.

However, I think package-level deps are the only solution to some
(other) problems. -k

Bug#952418: /lib/systemd/system/smcroute-helper.service: /lib/systemd/system/smcroute-helper.service: Comma in "After" list of the smcroute-helper.service

[Joachim Nilsson]

Thank you for taking the time to report this!

The helper service is being slowly phased out in favor of the native
.conf support in SMCRoute.  It'll likely be removed in a future release
(nothing set in stone).  So migrating to that is recommended.  However,
until that day it should of course work as intended.

I've fixed the issue in the Debian Salsa GitLab, so any patch release we
push out will include a fix.  But I honesly don't think we'll push a new
release just for this little one unless more people chime in.

Best regards
 /Joachim

Bug#952460: colletion-latexbase hyperref.sty depends on collection-latexextra letltxmacro.sty

[Norbert Preining]

Hi Karl,

> Ok, but before I change anything: hyperref has a package-level
> dependency on letltxmacro (and a bunch of others). Why doesn't that
> suffice?

Ahhh, because it was a Debian report ... which does not support package
level deps.

I guess I will move (only in Debian) letltxmacro to collection-latexbase
or so (in Debian texlive-latex-base).

> case of hyperref, if package-level dependencies aren't enough, presumably I
> should add all its dependencies to c-latex, where hyperref itself is. -k

In TeX Live proper it works ... it is only with the more and more heavy
use of package level deps that on the Debian side we get problems.

Nothing to worry for you for now, sorry for the noise.

Best

Norbert

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

Bug#952399: OpenSSL linking without license exception

[Marco d'Itri]

Control: found 26+20191223-1

On Feb 23, Bastian Germann  wrote:

> All of the GPL-2+ licensed executables contained in the kmod binary
> package link to libcrypto even though they do not have any OpenSSL
> license exception. ftp-master considers this a serious issue. So please
> remove this optional dependency or ask upstream for a license exception.
The large number of contributors to kmod obviously makes impossible 
getting a license exception, also considering that only Debian cares 
about linking GPL'ed software with OpenSSL.

Since only libkmod (which is LGPL'ed), and not the actual commands, is
linked with OpenSSL, and the libkmod symbols do not change depending if 
OpenSSL support is enabled or not, and the patches which introduced 
OpenSSL support did not touch the commands, then I think that the 
commands are obviously not a derivative work of OpenSSL.
You can also easily verify that the commands are not linked with OpenSSL 
by looking at the build logs of the package.

Also, the next major release of OpenSSL will be relicensed with the 
ASLv2 anyway, which is compatible with the GPLv3.

For these reasons I have no interest and no plans to do anything about 
this, and I am quite annoyed that I had to spend my time researching 
these details and then explaining them to you.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#951276: default webinterface non-functional

[Bálint Réczey]

Hi,

Gilles Filippini  ezt írta (időpont: 2020. febr. 25.,
K, 23:12):
>
> Hi,
>
> On Thu, 13 Feb 2020 17:48:57 +0100 Roderich Schupp
>  wrote:
> > Package: kodi-data
> > Version: 2:18.5+dfsg1-1~exp0
> > Severity: normal
> >
> > The default webinterface shows just a header bar,
> > see attached screenshot.
> >
> > The webinterface.default included in the Debian package is
> > seriously outdated, the current Kodi v18 webinterface
> > is here: https://github.com/xbmc/chorus2/releases/tag/18.x-2.4.6
>
> d/README.source says:
> > Kodi replaced the default webinterface in 17.0 beta6 but the new interface 
> > contains
> > many generated files without providing the source for them. The web 
> > interface
> > is temporarily reverted to the one included in beta5 to restore GPL 
> > compliance.
>
> And Balint filed a related upstream issue:
> https://github.com/xbmc/chorus2/issues/179
>
> @Balint, from your last comment on this issue it seems the only
> litigious material left is the screenshots. Are these images requested
> for running the chorus2 web interface? Couldn't they be removed from the
> upstream source package until they are fixed?

The upstream source needs a new review to see which files should be dropped.
If those are just a few images like the screenshots I'm ready to
create a new +dfsg2 source and ship the new web interface.

Help is very welcome here, since I'm currently busy with other
packages, but otherwise the kodi 18 packages are close to ready for
upload to unstable.

Cheers,
Balint

Bug#952560: please package new upstream snapshot

[Sean Whitton]

Hello Antoine,

On Tue 25 Feb 2020 at 02:40PM -05, Antoine Beaupre wrote:

> magit is at version 2.90 in Debian, which is over a year old. upstream
> has worked a lot on refactoring a lot of things upstream, and a bunch
> of third-party libraries have adapted to follow that.
>
> for example, magit-todos doesn't work with the latest magit version in
> Debian...
>
> could we maybe package a snapshot version in experimental, so that
> people could start to sync up? i'm afraid of a "one big release"
> approach that we seem to be heading towards, and which might break a
> bunch of stuff...
>
> it feels like everyone is using magit from MELPA right now, which
> seems far from ideal, especially when packages like magit-todos are
> entering debian, *relying* on versions from MELPA instead of Debian!

Magit 3.0 is due for release quite soon, AIUI, so I'd suggest we just
wait for that.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#944420: Fixed in 5.5

[Philipp Klaus Krause]

The green screen lockup issue is fixed in 5.5.

I've tried 5.5rc5 from experimental. While it crashes a lot and shows
graphical corruption in XFCE, I don't not get the green screen lockup.

I've also compiled 5.5.6 myself. With that kernel, crashes are a lot
less common (though they still happen in games sometimes) and the
graphical corruption is gone too.

Bug#952545: irssi-scripts: Duplicate usercount.pl conflict with irssi

[Sebastian Ramacher]

Control: severity -1 grave

On 2020-02-25 16:22:31, Sven-Haegar Koch wrote:
> Package: irssi-scripts
> Version: 20200222
> Severity: important
> 
> Dear Maintainer,
> 
> On upgrading fails and collides with irssi package:
> 
> Preparing to unpack .../irssi-scripts_20200222_all.deb ...
> Unpacking irssi-scripts (20200222) over (20181120) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/irssi-scripts_20200222_all.deb (--unpack):
>  trying to overwrite '/usr/share/irssi/scripts/usercount.pl', which is also 
> in package irssi 1.2.2-1+b1
> Errors were encountered while processing:
>  /var/cache/apt/archives/irssi-scripts_20200222_all.deb

This issues renders the package unusable. I'm raising the severity
accordingly.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#951276: default webinterface non-functional

[Gilles Filippini]

Hi,

On Thu, 13 Feb 2020 17:48:57 +0100 Roderich Schupp
 wrote:
> Package: kodi-data
> Version: 2:18.5+dfsg1-1~exp0
> Severity: normal
> 
> The default webinterface shows just a header bar,
> see attached screenshot.
> 
> The webinterface.default included in the Debian package is
> seriously outdated, the current Kodi v18 webinterface
> is here: https://github.com/xbmc/chorus2/releases/tag/18.x-2.4.6

d/README.source says:
> Kodi replaced the default webinterface in 17.0 beta6 but the new interface 
> contains
> many generated files without providing the source for them. The web interface
> is temporarily reverted to the one included in beta5 to restore GPL 
> compliance.

And Balint filed a related upstream issue:
https://github.com/xbmc/chorus2/issues/179

@Balint, from your last comment on this issue it seems the only
litigious material left is the screenshots. Are these images requested
for running the chorus2 web interface? Couldn't they be removed from the
upstream source package until they are fixed?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#952564: please get the latest libaom v1.0.0-errata1-avif to archives, even if only to experimental.

[shirish शिरीष]

Package: libaom0
Version: 1.0.0.errata1-3
Severity: wishlist

Dear Maintainer,
Thank you for maintaining libaom0 . Could you please share the latest
version of the encoder and decoder along with the documentation. I did
look at the salsa repo. and am not sure if we have the latest version
of the codec which was released on 12th December. If it was, then the
naming convention should have followed what upstream is following,
isn't it ?

Looking forward to clarification if I'm in the wrong.

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages libaom0 depends on:
ii  libc6  2.29-10

libaom0 recommends no packages.

libaom0 suggests no packages.

-- no debconf information

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#902241: (no subject)

[Santiago Vila]

fixed 902241 2.6.0-2
thanks

(Marking the bug as fixed in buster)

Bug#952546: bootstrap.min.js in pydoctor

[Jonas Smedegaard]

Quoting Anthony Fok (2020-02-25 22:35:03)
> A fix to this bug is almost ready: I have expanded d/copyright to 
> include the missing epydoc and bootstrap.min.css copyright info, and 
> added debian/missing-sources/bootstrap.css (vanilla Bootstrap v3.3.4, 
> equivalent to the embedded minified version, from Bootstrap CDN).

If the package ships copy of bootstrap.min.css then I suggest to also 
strip that and symlink to the css in the libjs-bootstrap package.

 - 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#902241: [PKG-Openstack-devel] Bug#902241: python-proliantutils: FTBFS in stretch (AssertionError: IloConnectionError not raised)

[Santiago Vila]

On Fri, 29 Jun 2018, Thomas Goirand wrote:

> Replacing the IP by 198.51.100.1, which is reserved by IETF for
> documentation (according to
> https://en.wikipedia.org/wiki/Reserved_IP_addresses) fixes the issue.

Maybe I misread Debian Policy, but I believe packages are not allowed
to even *try* Internet during build, and that's why I propose
disabling the test entirely, that should be simple and effective.

Thanks.

Bug#932197: Request to join the Neurodebian group

[Andreas Tille]

Hi,

here is some update I'm also forwarding to NeuroDebian Team list to have
some public record of the current status.

On Thu, Feb 20, 2020 at 01:36:35AM +1100, Stuart Prescott wrote:
> 
> I also looked at nipype (but its source is very odd and I can't build what is 
> in the repo; I think that was .gitattributes related but end up fixing it)

I have updated nipype in the Git repository I moved to Debian Med team[1]
The latest upstream version needs a new dependency python3-etelemetry
which I packaged and uploaded to new (see #952558)
 
I've also tried to build heudiconv in Git[2].  It builds so far but tests
accessing remote locations to download data need to be disabled.  That's
where I'm stoping for now.

Kind regards

   Andreas.

[1] https://salsa.debian.org/med-team/nipype
[2] https://salsa.debian.org/med-team/heudiconv 

-- 
http://fam-tille.de

Bug#902241: python-proliantutils: FTBFS in stretch (AssertionError: IloConnectionError not raised)

[Santiago Vila]

reopen 902241
tags 902241 + patch
thanks

This bug was already diagnosed by you here:

https://bugs.launchpad.net/proliantutils/+bug/1779342

I suggest applying the patch below. I can take care of filing the bug
against release.debian.org if it helps.

(Remember that packages in stretch *must* build in stretch. Closing
bugs like this one does not help at all to comply with such promise).

Thanks.

--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+python-proliantutils (2.1.11-2+deb9u1) stretch; urgency=medium
+
+  * Disable test which fails when there is Internet connectivity.
+Closes: #902241.
+
+ -- Thomas Goirand   Tue, 25 Feb 2020 22:20:10 +0100
+
 python-proliantutils (2.1.11-2) unstable; urgency=medium
 
   * d/s/options: extend-diff-ignore of .gitreview
--- a/proliantutils/tests/ilo/test_firmware_controller.py
+++ b/proliantutils/tests/ilo/test_firmware_controller.py
@@ -554,6 +554,7 @@ class FirmwareImageUploaderTestCase(unittest.TestCase):
   ('1.1.1.1', exception.IloConnectionError),
   ('any_kind_of_address', exception.IloConnectionError),)
 @ddt.unpack
+@unittest.skip("Test fails when there is Internet connectivity")
 def test__get_socket_throws_exception_in_case_of_failed_connection(
 self, input_hostname, expected_exception_type):
 # | GIVEN |

Bug#950455: override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS should not be emitted for compat level >= 13

[Chris Lamb]

Hi,

> override_dh_auto_test-does-not-check-DEB_BUILD_OPTIONS should not be emitted 
> for compat level >= 13

Simple in theory, but the well-tested code to parse the compat level
from various places is in debhelper.pm but we are parsing the
override_dh_auto_test in rules.pm.

Making it "just" a library method is not that straightforward either
as the code in debhelper.pm also finds and reports on conflicting/
broken numbers, etc.


Regards,

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

Bug#952546: bootstrap.min.js in pydoctor

[Anthony Fok]

Control: tags -1 + pending

On Tue, Feb 25, 2020 at 12:06 PM Colin Watson  wrote:
>
> On Tue, Feb 25, 2020 at 05:40:47PM +, Ian Jackson wrote:
> > (The d/copyright problem with epydoc should be easy if tedious to fix;
> > I don't understand why it wants epydoc which I thought was obsolete
> > but this is far from my field of expertise.)
>
> epydoc has been unmaintained for a long time, but the API documentation
> of various projects (notably Twisted) still relies on its docstring
> format for automatically-generated HTML documentation in a way that
> would be extremely tedious to replace with something else.  As a result,
> the approach that the Twisted developers ended up taking for pydoctor
> was to take a copy of the bits of epydoc that they needed and port those
> bits to Python 3 themselves.
>
> (This is second-hand; I'm not on the Twisted team, but I contribute a
> fair bit there and generally keep an eye on what they're doing since we
> rely on Twisted at work.)

Thank you Sean for the heads-up, and thank you Ian, Jonas and Colin
for your valuable and helpful comments.

A fix to this bug is almost ready: I have expanded d/copyright to
include the missing epydoc and bootstrap.min.css copyright info, and
added debian/missing-sources/bootstrap.css (vanilla Bootstrap v3.3.4,
equivalent to the embedded minified version, from Bootstrap CDN).

... though I discovered I foolishly uploaded an essentially empty
pydoctor binary package, and I may end up renaming it
python3-pydoctor, similar to how it was named python-pydoctor for the
Python2 version.  That's most likely why Lintian did not pick up on
the "bootstrap.min.css" missing source issue.  Jonas, thanks for
letting me know about linking to bootstrap.min.css in libjs-bootstrap;
I'll do that.

Cheers,
Anthony

Bug#951450: ITP: magit-todos -- show source file TODOs in Magit

[Antoine Beaupre]

Control: tags -1 +pending

On Sun, Feb 16, 2020 at 11:14:57PM +0500, Lev Lamberov wrote:
> * Package name: magit-todos

Great! Thanks for packaging this!

I see the package has entered NEW (hence +pending above) and the package
source is also available here:

https://salsa.debian.org/emacsen-team/magit-todos

It doesn't seem to work, however, with the latest version of magit
available in Debian. In a magit buffer, running `magit-todos-list`
yields the error:

magit-todos-list-internal: Symbol’s function definition is void: 
magit-setup-buffer

This seems to be because our version of magit is too old in Debian:

https://github.com/alphapapa/magit-todos/issues/87

ivy-magit-todos also fails with:

Symbol’s function definition is void: magit-get-mode-buffer

and helm:

In ‘helm-magit-todos’ source: ‘magit-todos-candidates’
 (void-function magit-get-mode-buffer)
Mark set


-- 
Prolétaires de tous les pays, qui lave vos chaussettes?
- Audrey Lorde


signature.asc
Description: PGP signature

Bug#915846: porg: diff for NMU version 2:0.10-1.2

[Boyuan Yang]

Tags: patch  pending

Dear maintainer,

I've prepared an NMU for porg (versioned as 2:0.10-1.2) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru porg-0.10/debian/changelog porg-0.10/debian/changelog
--- porg-0.10/debian/changelog  2017-05-27 18:11:56.0 -0400
+++ porg-0.10/debian/changelog  2020-02-25 16:06:41.0 -0500
@@ -1,3 +1,16 @@
+porg (2:0.10-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control:
+- Drop transitional package paco. (Closes: #940759)
+- Drop transitional package gpaco. (Closes: #940758)
+  * debian/rules:
++ Explicitly pass sed path to configure. This fixes
+  reproducible build on merged-usr vs non-merged systems.
+  (Closes: #915846)
+
+ -- Boyuan Yang   Tue, 25 Feb 2020 16:06:41 -0500
+
 porg (2:0.10-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru porg-0.10/debian/control porg-0.10/debian/control
--- porg-0.10/debian/control2016-07-20 17:21:10.0 -0400
+++ porg-0.10/debian/control2020-02-25 16:03:33.0 -0500
@@ -38,25 +38,3 @@
  manipulating the installed packages in a more comfortable way.
  .
  This package is a complete replacement for the deprecated 'gpaco' package.
-
-Package: paco
-Architecture: all
-Depends: porg, ${misc:Depends}
-Section: oldlibs
-Description: Transitional package to pull in porg
- The paco program has been renamed to porg. This is the transitional dummy
- package to get upgrading systems to install porg.
- .
- You can safely remove this dummy package once nothing depends on it
- anymore.
-
-Package: gpaco
-Architecture: all
-Depends: grop, ${misc:Depends}
-Section: oldlibs
-Description: Transitional package to pull in grop
- The gpaco program has been renamed to grop. This is the transitional dummy
- package to get upgrading systems to intall grop.
- .
- You can safely remove this dummy package once nothing depends on it
- anymore. 
diff -Nru porg-0.10/debian/rules porg-0.10/debian/rules
--- porg-0.10/debian/rules  2017-05-27 18:11:56.0 -0400
+++ porg-0.10/debian/rules  2020-02-25 16:06:39.0 -0500
@@ -14,4 +14,9 @@
dh $@  --with autotools-dev
 
 override_dh_auto_configure:
-   dh_auto_configure -- --with-porg-logdir=/var/lib/porg --
libdir=/usr/lib/porg
+   # Set SED variable for reproducibility
+   # See https://bugs.debian.org/915846
+   dh_auto_configure -- \
+   SED=/bin/sed \
+   --with-porg-logdir=/var/lib/porg \
+   --libdir=/usr/lib/porg

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Pino Toscano]

In data martedì 25 febbraio 2020 22:05:21 CET, Paul Gevers ha scritto:
> On 25-02-2020 20:41, Pino Toscano wrote:
> > The test is not flaky.
> 
> I can see why you say that now, but from my PoV (the release team) it is.

As I wrote, the conditions for this test to fail in the way it was
reported in bug are not definitely how a release is:

| Putting all the pieces together: why the autopkgtest can fail?
| The answer is simple: the version of src:llvm-defaults in the
| environment of the test is different than the one used to build clazy.

This is either:
- temporary, like what happens with the src:llvm-defaults bump to a
  newer LLVM version with rebuilds related to that (including clazy)
- a big problem for the Debian release altogether, because it would mean
  that src:llvm-defaults is stuck in unstable for any reason, while
  things built with it migrate happily to testing

> > Although, as I said, the issue "fixed itself" until the next
> > src:llvm-defaults switch, this is slightly less problematic.
> 
> llvm-defaults and gcc-10 were blocked for some days by the clazy
> regression on arm64. Can you explain why gcc-10 wasn't blocked by this
> issue on amd64? Also, the failures on arm64 started before the
> llvm-defaults upload [1] blocking glibc for some days. Do you also
> understand that?
> 
> [1]
> https://ci.debian.net/data/autopkgtest/testing/arm64/c/clazy/4223149/log.gz

Let's check this:

[FAIL] old-style-connect (Failed to build test. Check 
old-style-connect/namespaces.cpp.out for details)
---
Contents of old-style-connect/namespaces.cpp.out:
In file included from old-style-connect/namespaces.cpp:2:
old-style-connect/namespaces.h:22:9: warning: Old Style Connect 
[-Wclazy-old-style-connect]
connect(obj, SIGNAL(signal1()), obj1, SIGNAL(signal1()));
^~~
 ::Bar::signal1   ::Bar::signal1
old-style-connect/namespaces.cpp:32:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o1, SLOT(slot1())); // Warning
^~  ~
 ::signal1::slot1
old-style-connect/namespaces.cpp:33:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o2, SLOT(separateNSSlot())); // 
Warning
^~  ~~
 ::signal1::separateNSSlot
old-style-connect/namespaces.cpp:42:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o1, SLOT(slot1())); // Warning
^~  ~
 ::MyObj::signal1   ::MyObj::slot1
old-style-connect/namespaces.cpp:43:5: warning: Old Style Connect 
[-Wclazy-old-style-connect]
QObject::connect(o1, SIGNAL(signal1()), o2, SLOT(separateNSSlot())); // 
Warning
^~  ~~
 ::MyObj::signal1   ::MyObj2::separateNSSlot
5 warnings generated.
/usr/bin/ld: cannot find -lgcc_s
clang: error: linker command failed with exit code 1 (use -v to see invocation)

This looks to me like bug #951086 of src:gcc-10, which was indeed a
legit bug in gcc-10. Also, this is a totally different case than the
build log posted when opening this bug.

-- 
Pino Toscano

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

Bug#952563: src:cloud-utils: ec2metadata does not speak EC2 IMDSv2

[Noah Meyerhans]

Package: src:cloud-utils
Version: 0.31-1
Severity: important

The ec2metadata command queries a well-known link-local endpoint
(169.254.169.254 in Amazon EC2) to obtain information about the instance
on which it runs.  Last year, AWS released "IMDSv2" in an effort to
protect customers against some potentially severe information leaks
related to accidentally proxying this local data to the network.  Details
at
https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/

IMDSv2 makes use of a session-based protocol, requiring clients to first
retrieve a time-limited session token, and then to include that token with
subsequent requests.

Because the intended purpose of IMDSv2 is to provide an additional layer
of defense against network abuses, customers utilizing it may choose to
disable IMDSv1.  It's important that we facilitate this use case by
supporting IMDSv2 wherever possible.  We should work to add this support
in both bullseye and buster (and potentially stretch if feasible)

noah

Bug#952312: [Pkg-javascript-devel] Bug#952312: Bug#952312: Bug#952312: node-eslint-scope: FTBFS: tests failed

[Jonas Smedegaard]

Quoting Bastien ROUCARIES (2020-02-25 21:13:48)
> Le mar. 25 févr. 2020 à 19:48, Jonas Smedegaard  a écrit :
> 
> > control: reassign -1 node-espree
> > control: affects -1 node-eslint-scope
> >
> > Quoting Xavier (2020-02-25 18:29:35)
> > > Le 23/02/2020 à 14:50, Lucas Nussbaum a écrit :
> > > > During a rebuild of all packages in sid, your package failed to
> > > > build on amd64.
> > >
> > > Some test are incompatible with node-espree-6. The fix could be
> > > simply:
> >
> > Certainly not a fix to disable tests.
> >
> > The package node-espree has exactly one reverse dependency which is
> > node-eslint-scope, so this is a case of bad coordination.
> >
> > (yes, another fix would be to upgrade node-eslint-scope, but that is 
> > more complex and less urgent, so let's roll back first and work on 
> > going forward in experimental first
> 
> 
> 
> Node-espree was upgraded due to not compatible with acorn6...
> 
> So upgrade is safer

Please define "safer" in this context.


 - 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#861907: scrot not supporting multiple displays

[Stefan Pietsch]

On 2017-05-05 15:47, Dale Harris wrote:

Package: scrot
Version: 0.8-18
Severity: normal

Dear Maintainer,

Trying to use scrot -m or --multidisp doesn't appear to work. Man page
says it should grab a shot from each display and then merge the image,
however it only appears to be taking a shot from one. Is there something
else that has to be configured/installed to allow this to work?


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

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

Versions of packages scrot depends on:
ii  giblib11.2.4-11
ii  libc6  2.24-10
ii  libimlib2  1.4.8-1
ii  libx11-6   2:1.6.4-3

scrot recommends no packages.

scrot suggests no packages.

-- no debconf information



Dear bug reporter and maintainer,

this is not reproducible with scrot version 1.2-2 from Debian unstable.

Regards,
Stefan

Bug#951563: buster-pu: package postfix/3.4.8-0+10debu1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-02-18 at 00:50 -0500, Scott Kitterman wrote:
> This is the latest in the series of postfix 3.4 maintenance updates
> for buster.  The version is in bullseye already and I have it running
> locally without issue.  In addition to the upstream bugfixes, there
> are two Debian packaging fixes: a correction to the lmtp man page
> redirect and a sysv init update that fixes a regression in the last
> update (that solved the problem that it was intended to solve, but
> caused problems with multiple postfix instances).  This update has
> been tested by end users to work in both configurations.  Neither fix
> has any regression risk for users of Debian's default init
> system.

Please go ahead.

Regards,

Adam

Bug#951564: stretch-pu: package postfix/3.1.14-0+10debu1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-02-18 at 00:56 -0500, Scott Kitterman wrote:
> This is the next in the series of postfix 3.1 updates.  It includes
> the postfix 3.1 relevant fixes from 3.4.8 and 3.4.9 (as there was no
> companion 3.1 release with 3.4.8).  The only other change is to add
> the upstream signing key to make it easier for me to verify upstream
> signatures when preparing future updates.
> 

Please go ahead.

Regards,

Adam

Bug#952335: [Pkg-javascript-devel] Bug#952335: uglify-js: FTBFS: ERROR: `m` is not a supported option

[Xavier]

Le 25/02/2020 à 19:15, Jonas Smedegaard a écrit :
> control: reassign -1 node-commander
> control: affects -1 uglify-js
> 
> Quoting Xavier (2020-02-25 18:43:53)
>> Le 23/02/2020 à 14:31, Lucas Nussbaum a écrit :
>>> During a rebuild of all packages in sid, your package failed to 
>>> build on amd64.
>>
>> At least uglify-js (https://salsa.debian.org/js-team/uglifyjs) is 
>> incompatible with node-commander 4
> 
> Then it seems node-commander upgrade (done by you, Xavier) was badly 
> coordinated and should be reverted.
> 
>  - Jonas

debci did not report this because package was already broken. Rolling
back does not fix all (that's why I wrote "at least").
Reverting node-commander update may break a lot of packages:

node-commander
Reverse Depends:
  mocha
  uglifyjs
  yarnpkg
  node-ws
  uglifyjs.terser
  node-d3-dsv
  node-jade
  node-express-generator
  node-babel-cli
  cleancss
mocha
Reverse Depends:
  node-type-check
uglifyjs
Reverse Depends:
  node-constantinople
node-uglify
yarnpkg
Reverse Depends:
  gitlab
node-ws
Reverse Depends:
  node-websocket-stream
  node-flashproxy
uglifyjs.terser
Reverse Depends:
node-d3-dsv
Reverse Depends:
  node-d3
  node-d3-request
  node-d3-fetch
node-jade
Reverse Depends:
node-express-generator
Reverse Depends:
node-babel-cli
Reverse Depends:
  node-grunt-babel
cleancss
Reverse Depends:
node-type-check
Reverse Depends:
  node-levn
  node-optionator
node-constantinople
Reverse Depends:
  node-jade
node-uglify
Reverse Depends:
  node-dryice
  lava-dev
  emscripten
  node-with
  node-transformers
gitlab
Reverse Depends:
node-websocket-stream
Reverse Depends:
node-flashproxy
Reverse Depends:
node-d3
Reverse Depends:
  node-dagre-d3-renderer
node-d3-request
Reverse Depends:
  node-d3
node-d3-fetch
Reverse Depends:
node-grunt-babel
Reverse Depends:
node-levn
Reverse Depends:
  node-optionator
node-optionator
Reverse Depends:
  livescript
  node-escodegen
node-dryice
Reverse Depends:
lava-dev
Reverse Depends:
  lava
emscripten
Reverse Depends:
node-with
Reverse Depends:
  node-jade
node-transformers
Reverse Depends:
  node-jade
node-dagre-d3-renderer
Reverse Depends:
livescript
Reverse Depends:
  node-type-check
node-escodegen
Reverse Depends:
  node-static-eval
  node-static-module
  jison
  node-istanbul
lava
Reverse Depends:
node-static-eval
Reverse Depends:
  node-static-module
node-static-module
Reverse Depends:
  node-brfs
jison
Reverse Depends:
node-istanbul
Reverse Depends:
  node-opencv
node-brfs
Reverse Depends:
node-opencv

Bug#951769: buster-pu: package sssd/1.16.3-3.1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Fri, 2020-02-21 at 14:55 +0100, Thorsten Glaser wrote:
> we’d like to fix #946847 in buster (which is where we found it in
> production and tested a fix locally, which was later discovered to
> be identical to a recent upstream fix) because it’s a denial of
> service kind of bug (bad network causes sssd to hang causes no
> logins and lots of other stuff not working on the machine).

+sssd (1.16.3-3.2) buster; urgency=medium

1.16.3-3.1+deb10u1 would be more conventional, please.

With that note, please go ahead.

Regards,

Adam

Bug#952414: buster-pu: package ncbi-blast+/2.8.1-1+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-02-23 at 20:23 -0500, Aaron M. Ucko wrote:
> Per #951280, x86 builds of ncbi-blast+ accidentally wound up
> requiring SSE 4.2, breaking execution on older processors.  I've
> prepared an update (patch attached, or at [SALSA]) adding a configure
> flag that eliminates this inappropriate requirement.  (The flag is a
> no-op on other architectures, and as such safe to supply
> unconditionally.)

Please go ahead.

Regards,

Adam

Bug#951572: buster-pu: package uml-utilities/20070815.2-1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2020-02-24 at 15:37 +0530, Ritesh Raj Sarraf wrote:
> So my changelog was incorrect as it set to 20070815.3-1+deb10u4,
> which actually should be 20070815.3-1+deb10u1, as this is uml-
> utilities package's first stable update proposed.

No. stable currently has 20070815.2-1, so this should either be .2-
1+deb10u1 (adding the patch on top of the stable package) or
-3.1~deb10u1 (backporting the newer upload).

Your diff appears to do the latter, while repeating (in different
words) the fix. That isn't actually what would have changed in the
stable upload (relative to the unstable one), which is simply the
backporting.

+  * Use standard path for libray installation. (Closes: #928924)

s/libray/library/

Regards,

Adam

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Paul Gevers]

Hi Pino,

Thanks for the well written response.

On 25-02-2020 20:41, Pino Toscano wrote:
> The test is not flaky.

I can see why you say that now, but from my PoV (the release team) it is.

>> With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
>> failed on arm64 in testing when that autopkgtest was run with the binary
>> packages of gcc-10 from unstable.
> 
> The failures have nothing to do with gcc-10.

Sorry if it wasn't more clear from the next line that I didn't imply that.

> Although, as I said, the issue "fixed itself" until the next
> src:llvm-defaults switch, this is slightly less problematic.

llvm-defaults and gcc-10 were blocked for some days by the clazy
regression on arm64. Can you explain why gcc-10 wasn't blocked by this
issue on amd64? Also, the failures on arm64 started before the
llvm-defaults upload [1] blocking glibc for some days. Do you also
understand that?

> In the meanwhile: because of what I said above, I'm demoting the
> severity of this bug to important. Also, Paul, please re-enable the
> autopkgtest of clazy on ci.debian.net, as they will pass now.

I didn't disable the autopkgtest on ci.d.n. I told our migration
software (britney) to ignore the regression on arm64. I have removed
that hint.

Paul

[1]
https://ci.debian.net/data/autopkgtest/testing/arm64/c/clazy/4223149/log.gz



signature.asc
Description: OpenPGP digital signature

Bug#952562: netsurf FTCBFS: many reasons

[Helmut Grohne]

Source: netsurf
Version: 3.6-3.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

netsurf fails to cross build from source for many different reasons. It
has an "interesting" build system. But lets start in order.

The libhtml-parser-perl dependency poses a problem to cross
satisfiability. It is interpreted as host architecture and results in a
conflict on perl-base. The package is being used (run) during build
though, so it is needed for the build architecture instead. It should be
annotated :native. Once doing so, apt is able to install Build-Depends.

Then cross building netsurf should be a matter of setting up variables
HOST and BUILD. Unfortunately, it's not that simple. It doesn't figure
out the right CC for building nsgenbind. The attached patch opts to
building it separately. Then it also fails using the correct ar and
pkg-config.

Much later, a build tool fails linking -lpng. This indicates a missing
dependency on libpng-dev:native.

After fixing all of the above, the build fails with #911600, which is
where I stopped looking. Please consider applying the attached patch
anyway. Please close this bug when doing so.

Helmut
diff --minimal -Nru netsurf-3.6/debian/changelog netsurf-3.6/debian/changelog
--- netsurf-3.6/debian/changelog2018-07-18 23:25:47.0 +0200
+++ netsurf-3.6/debian/changelog2020-02-25 08:35:27.0 +0100
@@ -1,3 +1,16 @@
+netsurf (3.6-3.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Improve cross building: (Closes: #-1)
++ Annotate libhtml-parser-perl dependency :native as it is being used
+  during build.
++ Build native tool nsgenbind separately as the build system figures
+  the wrong compiler.
++ Set up cross build variables in the way the build system needs.
++ Build-Depends: libpng-dev:native for another native tool.
+
+ -- Helmut Grohne   Tue, 25 Feb 2020 08:35:27 +0100
+
 netsurf (3.6-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --minimal -Nru netsurf-3.6/debian/control netsurf-3.6/debian/control
--- netsurf-3.6/debian/control  2017-02-08 21:10:34.0 +0100
+++ netsurf-3.6/debian/control  2020-02-25 08:35:27.0 +0100
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Vincent Sanders 
 Uploaders: Daniel Silverstone 
-Build-Depends: debhelper (>= 9~), libcurl3-dev, libpng-dev, libgtk2.0-dev, 
flex, bison, libhtml-parser-perl, librsvg2-dev, libjpeg-dev, imagemagick, 
libfreetype6-dev, libvncserver-dev, libsdl1.2-dev, libxcb1-dev, 
libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, libxcb-util0-dev, 
libssl-dev, gperf
+Build-Depends: debhelper (>= 9~), libcurl3-dev, libpng-dev, libpng-dev:native, 
libgtk2.0-dev, flex, bison, libhtml-parser-perl:native, librsvg2-dev, 
libjpeg-dev, imagemagick, libfreetype6-dev, libvncserver-dev, libsdl1.2-dev, 
libxcb1-dev, libxcb-icccm4-dev, libxcb-image0-dev, libxcb-keysyms1-dev, 
libxcb-util0-dev, libssl-dev, gperf
 Standards-Version: 3.9.8
 Homepage: http://www.netsurf-browser.org
 Vcs-Browser: http://source.netsurf-browser.org/packaging/debian.git/
diff --minimal -Nru netsurf-3.6/debian/rules netsurf-3.6/debian/rules
--- netsurf-3.6/debian/rules2016-11-20 15:27:36.0 +0100
+++ netsurf-3.6/debian/rules2020-02-25 08:35:27.0 +0100
@@ -8,12 +8,23 @@
 export DEB_CFLAGS_MAINT_APPEND = -Wno-error
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+include /usr/share/dpkg/architecture.mk
+include /usr/share/dpkg/buildtools.mk
+
+BUILD_VARS = V=1 PREFIX=/usr
+BUILD_ENV = PATH='$(CURDIR)/build-nsgenbind:$(PATH)'
+ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
+BUILD_VARS += PKGCONFIG='$(PKG_CONFIG)'
+BUILD_ENV += BUILD='$(DEB_BUILD_GNU_CPU)' HOST='$(DEB_HOST_GNU_CPU)' AR='$(AR)'
+endif
+
 %:
dh $@ 
 
 override_dh_auto_build:
-   dh_auto_build -- V=1 PREFIX=/usr TARGET=gtk
-   dh_auto_build -- V=1 PREFIX=/usr TARGET=framebuffer
+   dpkg-architecture -a$(DEB_BUILD_ARCH) -f -c dh_auto_build 
--sourcedirectory=nsgenbind -- V=1 NSSHARED=$(CURDIR)/buildsystem 
BUILDDIR=$(CURDIR)/build-nsgenbind
+   $(BUILD_ENV) dh_auto_build -- TARGET=gtk $(BUILD_VARS)
+   $(BUILD_ENV) dh_auto_build -- TARGET=framebuffer $(BUILD_VARS)
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr TARGET=gtk
@@ -27,6 +38,7 @@
ln -s /etc/ssl/certs/ca-certificates.crt 
debian/tmp/usr/share/netsurf/ca-bundle.txt
 
 override_dh_auto_clean:
+   rm -Rf build-nsgenbind
dh_auto_clean -- PREFIX=/usr TARGET=gtk
dh_auto_clean -- PREFIX=/usr TARGET=framebuffer
 

Bug#952561: gnumeric: unsatisfiable cross Build-Depends: libxml-parser-perl

[Helmut Grohne]

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

gnumeric cannot be cross built from source, because its Build-Depends
are not cross satisfiable. One of the reasons is its dependency on
libxml-parser-perl. The dependency is requested for the host
architecture and thus results in a conflict with perl, which is
(implicitly) requested for the build architecture. Since gnumeric uses
intltool, libxml-parser-perl has become an implementation detail of
intltool and the dependency is no longer necessary. It can simply be
dropped with no replacement. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru gnumeric-1.12.46/debian/changelog 
gnumeric-1.12.46/debian/changelog
--- gnumeric-1.12.46/debian/changelog   2019-11-13 07:13:47.0 +0100
+++ gnumeric-1.12.46/debian/changelog   2020-02-25 21:32:33.0 +0100
@@ -1,3 +1,10 @@
+gnumeric (1.12.46-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused build dependency on libxml-parser-perl. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 25 Feb 2020 21:32:33 +0100
+
 gnumeric (1.12.46-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru gnumeric-1.12.46/debian/control 
gnumeric-1.12.46/debian/control
--- gnumeric-1.12.46/debian/control 2019-11-13 07:13:47.0 +0100
+++ gnumeric-1.12.46/debian/control 2020-02-25 21:32:31.0 +0100
@@ -20,7 +20,6 @@
   ,libgtk-3-dev
   ,libpango1.0-dev
   ,libperl-dev
-  ,libxml-parser-perl
   ,libxml2-dev
   ,libxml2-utils
   ,python-dev

Bug#952441: buster-pu: package user-mode-linux/4.19-1um-1+b1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Mon, 2020-02-24 at 14:49 +0100, Santiago R.R. wrote:
> I would like to upload user-mode-linux to buster to fix this FTBFS:
> https://bugs.debian.org/951329. Ritesh Raj Sarraf (rrs) has already
> given his ACK.
> 

The metadata for that bug suggests that it affects the package in
unstable, and is not currently fixed there. Is that correct?

If it is, the issue should be fixed in unstable first. If not, the bug
report should have an appropriate "fixed" version added, indicating the
earliest upload that's unaffected.

Regards,

Adam

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Norbert Preining]

Hi Holger,

On Wed, 26 Feb 2020, Norbert Preining wrote:
> ~/DebInstaller/installation-guide/build] ./buildone.sh amd64 el pdf
> Info: creating temporary profiled .xml file...
> Info: creating .pdf file...
> xelatex failed
> install.el.profiled.tex:3389: Command \textBeta unavailable in encoding TU.

Actually, removing the -q, adding --debug to dblatex call, and not
removing the temp dir in buildone.sh, I can see the code now.

It compiles here without any problems on the first run, but the second
run brings the errors I mentioned, which come from
install.el.profiled.aux:\newlabel{preseed-bootparms}{{\MakeUppercase  
{\textbeta \anw@true  \anw@print  \relax }.2.2}{52}{Χρήση παραμέτρων εκκίνησης 
για την προρύθμιση ερωτήσεων}{subsection.alph1.Alph2.2.2}{}}
Which means that \textbeta is uppercased to \textBeta.
This seems to be some code that formats references.

But, the document is considerably broken, with lots of glyphs missing.

I see ***lots*** of warnings
Package Listings Warning: Text dropped after begin of listing on input 
line 403
9.
and also
No file LGRFreeMono(0).fd.

Has this all been working before, and was the output of the run actually
showing a proper document?

Anyway, as I said, I cannot reproduce the error you have, so something
is either missing, or strange. It would be great if you can somehow
inject the argument
-recorder
to the xelatex call, and then send me also the file
install.el.profiled.fls
I attach the one I generated my manually calling
xelatex -recorder install.el.profiled.tex
It gives the full list of files loaded during the TeX run (not the xdv
=> pdf conversion using dvipdfmx). There you see that
/usr/share/texlive/texmf-dist/fonts/tfm/jknappen/ec/tcrm1000.tfm
is loaded, and this is the only one, and that is available in
texlive-base
So if anything else is going on on your side, this is a serious
misconfiguration of either the build system, or the environment in which
dblatex calls xelatex.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
PWD 
/home/norbert/foo/DebInstaller/installation-guide/build/build.tmp/dblatex/tmp2ty6i_kc
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/local/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/xetex/xelatex.fmt
INPUT install.el.profiled.tex
OUTPUT install.el.profiled.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/report.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/report.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/ifthen.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifxetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/iftex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3packages/xparse/xparse.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3kernel/expl3.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xdvipdfmx.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-xdvipdfmx.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec-xetex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/tuenc.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/fontenc.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg
INPUT /usr/share/texlive/texmf-dist/tex/latex/fontspec/fontspec.cfg
INPUT /usr/share/texlive/texmf-dist/tex/xelatex/xltxtra/xltxtra.sty
INPUT /usr/share/texlive/texmf-dist/tex/xelatex/xltxtra/xltxtra.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifluatex.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/iftex/ifluatex.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/realscripts/realscripts.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/realscripts/realscripts.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/metalogo/metalogo.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/metalogo/metalogo.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty

Bug#952560: please package new upstream snapshot

[Antoine Beaupre]

Package: elpa-magit
Version: 2.90.1-2
Severity: wishlist
Tags: upstream

magit is at version 2.90 in Debian, which is over a year old. upstream
has worked a lot on refactoring a lot of things upstream, and a bunch
of third-party libraries have adapted to follow that.

for example, magit-todos doesn't work with the latest magit version in
Debian...

could we maybe package a snapshot version in experimental, so that
people could start to sync up? i'm afraid of a "one big release"
approach that we seem to be heading towards, and which might break a
bunch of stuff...

it feels like everyone is using magit from MELPA right now, which
seems far from ideal, especially when packages like magit-todos are
entering debian, *relying* on versions from MELPA instead of Debian!

thanks!

PS: upstream seems to have stopped making releases as well, which is
why i'm asking for a snapshot, see:

https://github.com/magit/magit/issues/3965

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

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

Versions of packages elpa-magit depends on:
ii  elpa-dash 2.14.1+dfsg-1
ii  elpa-ghub 3.2.0-1
ii  elpa-git-commit   2.90.1-2
ii  elpa-magit-popup  2.12.5-1
ii  elpa-with-editor  2.8.1-1
ii  emacsen-common3.0.4
ii  git   1:2.20.1-2+deb10u1

elpa-magit recommends no packages.

elpa-magit suggests no packages.

-- debconf-show failed

Bug#948996: freeradius: Consider including support for collectd when compiling freeradius.

[Bernhard Schmidt]

Control: block -1 by 933296

On Wed, Jan 15, 2020 at 01:59:54PM -0500, Munroe wrote:

Dear Munroe,

> Radsniff was introduced in the 3.x.x branch of code and when coupled
> with collectd can provide statistics collection.  Including this
> option does add a libcollectd dependency, but seeing that freeradius
> already has a dozen or so libraries it depends on, this shouldn't add
> too much bloat to the package.

The libcollectdclient dependency, with Recommends enabled (default)
installs 200 packages including Gtk, OpenJDK, ceph etc.

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

I don't think this is worth it.

Bernhard

Bug#927706: clojure: significant performance decrease in 1.10

[Leandro Doctors]

Hi, all

Given that clojure 1.10.1 is already in Debian...
Should this bug be closed?

Best,
Leandro

Bug#952538: libwolfssl-dev: user_settings.h missing

[Otto Kekäläinen]

Hello!

> I am also available to help if you provide your source package.

I was working on a variant of mariadb-10.4 that would use system
WolfSSL in 
https://salsa.debian.org/mariadb-team/mariadb-10.4/-/compare/master...feature%2Fsystem-wolfssl
Are you familiar with Salsa? At least the package WolfSSL does not
seem to be in version control at all.

Bug#952481: texlive: mktexpk fails to create tcrm1000

[Norbert Preining]

Hi Holger,

On Tue, 25 Feb 2020, Holger Wansing wrote:
> The TMPDIR variable is set to 'build.tmp' so it's strange that mktexpk tries 
> to
> use 'build.tmp.el.i386' which is in fact not existing...

Hmm, you could throw in a set -x into mktex.opt to see what is going on.

> generated, the process fails at another (later) step.

What was the error?

> I installed cm-super on the machine, but the build fails with the same error
> (with the same mktexph call).

Interesting.

> Why mktexpk is called to use that jknappen font from tcrm?

LaTeX kernel internals.

> PS: in case you need the original code of installation-guide, it's here:
> https://salsa.debian.org/installer-team/installation-guide/-/tree/master/build
> the PDF generation is in buildone.sh starting from line 186.

I tried to reproduce your problem here, by running the build process to
generate the LL directories, then running
./buildone.sh amd64 el pdf
This gave me an error, but it is different from yours, and quite sure a
failure in the TeX code:

~/DebInstaller/installation-guide/build] ./buildone.sh amd64 el pdf
Info: creating temporary profiled .xml file...
Info: creating .pdf file...
xelatex failed
install.el.profiled.tex:3389: Command \textBeta unavailable in encoding TU.
install.el.profiled.tex:3389: leading text: ...ην ενÏÏ
  ηÏ
 α Τμήμα 
\ref{preseed-bootparms}
install.el.profiled.tex:3389: Command \textdexiakeraia unavailable in encoding 
TU.
install.el.profiled.tex:3389: leading text: ...ην ενÏÏ
  ηÏ
 α Τμήμα 
\ref{preseed-bootparms}
install.el.profiled.tex:3391: Command \textBeta unavailable in encoding TU.
install.el.profiled.tex:3391: leading text: ...ίÏ
  ε Ï
  ην ενÏÏ
 ηÏ
α 
Τμήμα \ref{preseed-auto}
install.el.profiled.tex:3391: Command \textdexiakeraia unavailable in encoding 
TU.
install.el.profiled.tex:3391: leading text: ...ίÏ
  ε Ï
  ην ενÏÏ
 ηÏ
α 
Τμήμα \ref{preseed-auto}

A possible reason for transformation failure is invalid DocBook
(as reported by xmllint)

Error: xelatex compilation failed
Error: build of pdf failed with error code 1
Warning: The following formats failed to build: pdf
$


Could you please
- get the **generated** TeX code
- the log file from the failed run
- the output of `set` before xelatex is called
- the full list of texlive and font packages being installed
?

Thanks

Best

Norbert

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

Bug#952312: [Pkg-javascript-devel] Bug#952312: Bug#952312: Bug#952312: node-eslint-scope: FTBFS: tests failed

[Bastien ROUCARIES]

Le mar. 25 févr. 2020 à 19:48, Jonas Smedegaard  a écrit :

> control: reassign -1 node-espree
> control: affects -1 node-eslint-scope
>
> Quoting Xavier (2020-02-25 18:29:35)
> > Le 23/02/2020 à 14:50, Lucas Nussbaum a écrit :
> > > During a rebuild of all packages in sid, your package failed to
> > > build on amd64.
> >
> > Some test are incompatible with node-espree-6. The fix could be
> > simply:
>
> Certainly not a fix to disable tests.
>
> The package node-espree has exactly one reverse dependency which is
> node-eslint-scope, so this is a case of bad coordination.
>
> (yes, another fix would be to upgrade node-eslint-scope, but that is
> more complex and less urgent, so let's roll back first and work on going
> forward in experimental first



Node-espree was upgraded due to not compatible with acorn6...

So upgrade is safer

> )
>
>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private--
> Pkg-javascript-devel mailing list
> pkg-javascript-de...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

Bug#952559: RFS: telegram-desktop/1.9.14+ds-2 -- fast and secure messaging application

[Nicholas Guriev]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "telegram-desktop"

 * Package name: telegram-desktop
   Version : 1.9.14+ds-2
   Upstream Author : John Preston 
 * URL : https://desktop.telegram.org
 * License : GPL-3.0+ with OpenSSL exception
 * Vcs : https://salsa.debian.org/debian/telegram-desktop
   Section : net

It builds those binary packages:

  telegram-desktop - fast and secure messaging application

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

  https://mentors.debian.net/package/telegram-desktop

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/telegram-desktop/telegram-desktop_1.9.14+ds-2.dsc

Or you can review a merge request with this version:

  https://salsa.debian.org/debian/telegram-desktop/-/merge_requests/19

Changes since the last upload:

   [ Ilya Fedin ]
   * Add category property for StatusNotifierItem, this fixes tray icon in
 KDE Plasma 5 and Cinnamon. (Closes: #951810)
 .
   [ Nicholas Guriev ]
   * Mend a hack for non-Linux systems to fix build for GNU/Hurd or FreeBSD.

Regards,

--
  Nicholas Guriev

Bug#945567: new network-manager-strongswan package [and 1 more messages]

[Harald Dunkel]

Hi Ian,

On 2/24/20 5:14 PM, Ian Jackson wrote:


Fixed I think.  I have created this:
   https://salsa.debian.org/debian/network-manager-strongswan
and made you ("harri-guest") a maintainer of it.

I think you can do all the rest of the setup yourself.  Let me know if
you want anything else doing.



I have pushed n-m-s 1.4.5-1 to salsa, without touching the label.
Worked very well.

Next I created version 1.4.5-2 (no tag yet) to fix the issues you
mentioned (Vcs-git, git format-patch). Hopefully I didn't miss
anything. lintian is still happy. Pushed.

Maybe you could take a look?


Thanx in advance
Harri

Bug#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Pino Toscano]

severity 952464 important
thanks

In data lunedì 24 febbraio 2020 21:10:53 CET, Paul Gevers ha scritto:
> Source: clazy
> Version: 1.6-2
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: flaky

The test is not flaky.

> Dear maintainer(s),
> 
> With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
> failed on arm64 in testing when that autopkgtest was run with the binary
> packages of gcc-10 from unstable.

The failures have nothing to do with gcc-10.

> I looked into the history of your autopkgtest and it fails very often.

Err, not really, no need to exagerate things that are not like that.

The situation is more complex than that, and it needs a longer
explanation. No TL;DR is provided.

clazy is a clang plugin to detect more issues in Qt-based software,
and because of that it uses (and links to) the LLVM/clang libraries.
What is shipped is the following:

(1) /usr/bin/clazy
(2) /usr/bin/clazy-standalone
(3) /usr/lib/MULTI-ARCH/ClazyPlugin.so

(3) is the actual plugin, which is used like:
  $ clang -Xclang -load -Xclang ClazyPlugin.so -Xclang \
  -add-plugin -Xclang clazy [etc...]
This is links to the LLVM and clang libraries.

(2) is a similar version of (1), made as standalone executable rather
than a compiler plugin. It is used as compiler, so e.g.:
  $ clazy [...]

(1) is a shells script that wraps the usage of (3), with extra
parameters for version/help, and list the actual checks available.

clazy supports various LLVM versions (clazy 1.6 requires LLVM >= 5),
and it is generally updated whenever a new LLVM version is released.
For this reason, I let it built with the default LLVM version (that is
src:llvm-defaults), so using the unversioned llvm/clang -dev packages.
OTOH, (1) as shipped upstream calls the unversioned "clang++"
executable: because of this, we have local changes that record the path
to the clang++ tool of the clang version used during the built (i.e.
the Debian default one). It is easy to check this:

  $ dpkg -l | grep clazy
  ii  clazy   1.6-2+b1  amd64Clang 
plugin for additional warnings
  $ grep CLANGXX /usr/bin/clazy
  ${CLANGXX:-/usr/lib/llvm-9/bin/clang++} --version | head -1 | awk 
'{printf("clang version: %s\n",$3)}'
${CLANGXX:-/usr/lib/llvm-9/bin/clang++} -Qunused-arguments -Xclang -load 
-Xclang $ClazyPluginLib -Xclang -add-plugin -Xclang clazy $ExtraClangOptions 
"$@"

In addition to that, the clang-X package used is recorded as dependency:

  $ apt-cache show clazy | grep Depends
  Depends: libc6 (>= 2.14), libllvm9 (>= 1:9~svn298832-1~), libstdc++6 (>= 9), 
clang-9

So clazy pulls whichever version of clang it was built with, and thus
(1) works OOTB.

Now let's take a look at the autopkgtest structure:

  $ cat debian/tests/control 
  Tests: run-tests
  Depends: @, clang, clang-tools, python3, qtbase5-dev, qtdeclarative5-dev
  Restrictions: rw-build-tree, allow-stderr

  $ cat debian/tests/run-tests 
  #!/bin/sh
  
  set -e
  
  # show some facts about clang/clang++, so it is easier to debug issues
  clang -E -x c - -v < /dev/null
  clang++ -E -x c++ - -v < /dev/null
  
  cd tests
  ./run_tests.py --verbose

The upstream tests/run_tests.py executable executes the tests twice:
with (2) and (3). We can understand easily that the tests with (2) work
fine in all the cases, and indeed they pass flawlessy. The tests with
(3) use "clang++" as compiler name by default, and as such it is the
Debian default.

Putting all the pieces together: why the autopkgtest can fail?
The answer is simple: the version of src:llvm-defaults in the
environment of the test is different than the one used to build clazy.

In this particular case: clazy was rebuilt when src:llvm-defaults was
switched from 8 to 9, and because LLVM 9 was already in testing, the
binNMU migrated instantly to testing. However, src:llvm-defaults took
its 5 days to migrate to testing, so "clang" was still 8.
I see src:llvm-defaults migrated to testing today: this means that the
failures "disappear", since in both suites the versions of
(a) src:llvm-defaults used when building clazy
(b) src:llvm-defaults present
are the same.

What I will not do: switch away from the unversioned llvm version.
This means manually changing the used llvm version, which is a PITA,
and generally not needed for what clazy needs.

It seems like run_tests.py allows changing the "clang" executable used
with the CLANGXX environment variable. This seems a promising move,
however detecting what was the clang version used to build clazy only
by looking at the installed clazy seems hard. I will try to come up
with something in the next days to allow testing with the right
version. Although, as I said, the issue "fixed itself" until the next
src:llvm-defaults switch, this is slightly less problematic.

In the meanwhile: because of what I said above, I'm demoting the
severity of this bug to important. Also, 

Bug#952558: ITP: python-etelemetry -- lightweight Python3 client to communicate with the etelemetry server

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: python-etelemetry -- lightweight Python3 client to communicate 
with the etelemetry server
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: python-etelemetry
  Version : 0.1.2
  Upstream Author : , Senseable Intelligence Group
* URL : https://github.com/mgxd/etelemetry-client/
* License : Apache-2.0
  Programming Lang: Python
  Description : lightweight Python3 client to communicate with the 
etelemetry server
 This Python3 package provides a lightweight Python3 client interface to
 communicate with the etelemetry server.  It can be used for nipy or
 nipype.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/python-etelemetry

Bug#952557: proftpd-dfsg: Followup fix for CVE-2020-9273

[Salvatore Bonaccorso]

Source: proftpd-dfsg
Version: 1.3.6c-1
Severity: important
Tags: upstream

Hi

As per https://github.com/proftpd/proftpd/issues/903 there was a
follow-up fix for upstream issue #903, CVE-2020-9273.

See:

https://github.com/proftpd/proftpd/commit/f8047a1ed0e0eb15193f555c4cbbb281e705c5c3
(master)
https://github.com/proftpd/proftpd/commit/cd9036f4ef7a05c107f0ffcb19a018b20267c531
(1.3.6 branch)

Regards,
Salvatore

Bug#952506: Wired interface name maybe changed when reboot

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 25.02.20 um 07:42 schrieb gulfstream:
> Package: systemd
> Version: 244.3-1
> Severity: normal
> 
> 
> Hi, the wired interface name maybe changed when root. Sometimes the wired 
> interface's name is "enp0s31f6", sometimes it is "eth0". I think it should be 
> "enp0s31f6", and it made the Network Manager can not manage the wired 
> interface anymore.


Please provide a verbose debug log of a boot where the interface is
named eth0 and a second log of a boot where the interface is named
enp0s31f6. [1] has instructions how to do that.

Please also include the output of
udevadm info /sys/class/net/eth0
respectively
udevadm info /sys/class/net/enp0s31f6



[1] https://freedesktop.org/wiki/Software/systemd/Debugging/#index1h1 ->
If You Can Get a Shell



signature.asc
Description: OpenPGP digital signature

Bug#952549: one more patch

[Matthias Klose]

this patch is required too:
http://launchpadlibrarian.net/466557663/libgnatcoll-bindings_19-1ubuntu1_19-1ubuntu2.diff.gz

Bug#946449: I did file a wishlist bug for libtorrent-rasterbar 1.2.4 which would in turn get the new version built. #952447

[shirish शिरीष]

Dear all,

FWIW, I did file a wishlist bug for libtorrent-rasterbar 1.2.4 which
would in turn get the new version built. #952447 . I do hope the
maintainers/developers would take it in the consideration. I did have
upstream conversation with the developer as well and he had shared
that both qbittorrent and libtorrent-rasterbar9 had been python3 ready
since 1.11 itself. So let's just an eye on what the
developers/maintainers think about it, hopefully we will get the new
version soonish. Even if it is in experimental, that would be good
enough.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

Bug#952501: slapd: README.Debian does not note that databases are created

[Ryan Tandy]

Hello Karl,

Thank you for your feedback, and for providing a patch.

I made a few adjustments to your text, and noted a couple of other 
things that tend to surprise new users.


I wonder if you have any feedback on this version (below).

Thank you,
Ryan

--

diff --git a/debian/slapd.README.Debian b/debian/slapd.README.Debian
index a5e307f24..3afd57ca9 100644
--- a/debian/slapd.README.Debian
+++ b/debian/slapd.README.Debian
@@ -11,7 +11,39 @@ Notes about Debian's slapd package
  the OpenLDAP Admin Guide for more information, including configuration
  examples for common use cases. 

-The OpenLDAP configuration
+Initial slapd configuration
+
+  Upon installation, the slapd package initializes the configuration
+  database (cn=config) and creates an initial database with its suffix
+  derived from the DNS domain configured in debconf (e.g.
+  dc=example,dc=com). An administrative identity (cn=admin,) is
+  created to manage this database, using the password configured in
+  debconf, or a randomly generated password if none was set.
+
+  If desired, the configuration and database can be re-configured by
+  running, as root:
+
+dpkg-reconfigure slapd
+
+  Note that this command will completely reset the configuration and
+  data (saving a backup in /var/backups), restoring slapd to the default
+  initial state.
+
+  The permissions for the configuration database (cn=config) and
+  directory database (dc=,dc=) are different. Upon
+  installation, the Unix root user is granted access to manage the slapd
+  configuration (cn=config database) and the directory administrator
+  (cn=admin,) is granted access to manage the directory
+  (dc=,dc= database). This is a Debian-specific default.
+
+  The directory administrator's password is stored in two places: in the
+  olcRootPW attribute of the database configuration
+  (olcDatabase={1}mdb,cn=config) and in the userPassword attribute of
+  the administrator identity itself (cn=admin,). If the password
+  needs to be changed, both of those should be updated, using
+  ldapmodify(1) and ldappasswd(1) respectively.
+
+Maintaining the slapd configuration

  Since version 2.4.23-3 the configuration of OpenLDAP has been changed to
  /etc/ldap/slapd.d by default.  The OpenLDAP packages in Debian provide an

Bug#952546: bootstrap.min.js in pydoctor

[Colin Watson]

On Tue, Feb 25, 2020 at 05:40:47PM +, Ian Jackson wrote:
> (The d/copyright problem with epydoc should be easy if tedious to fix;
> I don't understand why it wants epydoc which I thought was obsolete
> but this is far from my field of expertise.)

epydoc has been unmaintained for a long time, but the API documentation
of various projects (notably Twisted) still relies on its docstring
format for automatically-generated HTML documentation in a way that
would be extremely tedious to replace with something else.  As a result,
the approach that the Twisted developers ended up taking for pydoctor
was to take a copy of the bits of epydoc that they needed and port those
bits to Python 3 themselves.

(This is second-hand; I'm not on the Twisted team, but I contribute a
fair bit there and generally keep an eye on what they're doing since we
rely on Twisted at work.)

-- 
Colin Watson   [cjwat...@debian.org]

Bug#952556: RM: zeitgeist-explorer -- RoQA; Affected by Python2 Removal; Upstream Inactive

[Boyuan Yang]

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

Dear FTP Masters,

Please remove package zeitgeist-explorer from Debian archive. It saw no
upstream activity in the past 10 years and is now affected by python2 removal.
Besides, there has been no maintainer activity in the last 7 years as well.

-- 
Thanks,
Boyuan Yang


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

Bug#939641: dnsrecon: Python2 removal in sid/bullseye

[Scott Kitterman]

On Sat, 7 Sep 2019 10:16:36 +0200 Andreas Henriksson  wrote:
> Package: dnsrecon
> Version: 0.8.14-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>   
>   This is the preferred option.

This is one of two packages still in Testing that needs the python2 version of 
dnspython.  It would be really nice to see it packaged to use python3 so we 
can make progress on getting rid of python2 (which no longer has upstream 
security support).

There is evidence in the upstream commit history [1] that this will work with 
either python2 or python3, so I sould appreciate it if you could see if 
switching to python3 works.  If you need help with the packaging changes for 
that, please let me know (cc me since I am not subscribed to the bug).  I 
don't, however, know how to test it since I don't use the package and there's 
no test suite.

Scott K

[1] https://github.com/darkoperator/dnsrecon/commit/
1a7a58332f99a3310847f506ff382b71e88d1837

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

Bug#952543: Using old libfmt breaks sopt and purify

[Michael R. Crusoe]

On Tue, 25 Feb 2020 19:01:02 +0100 "Michael R. Crusoe" 
 wrote:
> On Tue, 25 Feb 2020 15:22:10 +0100 Ole Streicher  
wrote:

>
> > Since spdlog uses the old (included) libfmt, the builds of purify and
> > sopt fail with linker errors like:
> >
> > undefined reference to `fmt::v6::internal::assert_fail(char const*, 
int,

> > char const*)
> >
> > See the merged bugs for the reports. Could you revert this change? Or
> > somehow make it work (I guess, the library itself would need to be
> > included).
>
> Thanks for the report. spdlog 1.5 requires a newer libfmt, otherwise the
> tests don't pass

Sorry, was a local issue with the tests not passing. A repacked spdlog 
has been made without its copy of libfmt and it is on its way to the archive

Bug#952312: [Pkg-javascript-devel] Bug#952312: Bug#952312: node-eslint-scope: FTBFS: tests failed

[Jonas Smedegaard]

control: reassign -1 node-espree
control: affects -1 node-eslint-scope

Quoting Xavier (2020-02-25 18:29:35)
> Le 23/02/2020 à 14:50, Lucas Nussbaum a écrit :
> > During a rebuild of all packages in sid, your package failed to 
> > build on amd64.
> 
> Some test are incompatible with node-espree-6. The fix could be 
> simply:

Certainly not a fix to disable tests.

The package node-espree has exactly one reverse dependency which is 
node-eslint-scope, so this is a case of bad coordination.

(yes, another fix would be to upgrade node-eslint-scope, but that is 
more complex and less urgent, so let's roll back first and work on going 
forward in experimental first)


 - 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#952555: azure-uamqp-python: please make the build reproducible

[Chris Lamb]

forwarded 952555 https://github.com/Azure/azure-uamqp-python/pull/144
thanks

Hi Luca,

> I need to check the CMake build for the vendored library (brr) - it
> might not be taking all the compiler flags from dpkg. IIRC we have a
> custom gcc patch to override the paths for __FUNCTION__ and friends,
> right?

Indeed, we have a patch for this sort of thing. And yep, vendored libraries with
ther own build systems not respecting CFLAGS (and thus -fdebug-prefix-
map & friends...) are a common reason for non-reproducibility in this
area.

Oh, whilst I "briandumping" I believe CMake has particular problems
with CFLAGS/CXXFLAGS too, but this may not apply here — linking the
below just on the off chance:

  https://wiki.debian.org/Hardening


Best wishes,

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

Bug#943423: troubles generating refman.pdf

[Aurelien Jarno]

Hi,

On 2020-02-05 15:04, Gordon, Craig A. (GSFC-660.1)[INNOVIM] wrote:
> Hi Paolo,
> 
> It was never intended for end users to have to generate the CCfits manual 
> themselves (nor is it intended to be compatible with all versions of 
> Doxygen).  That's why CCfits-2.5.pdf is included with the stand-alone 
> distribution.  Is there a special reason you're trying to run "make docs"?  
> Because otherwise I wouldn't recommend doing that.

In Debian we have a rule requiring that everything, including
documentation, is rebuild from sources.

I have finally been able to build the documentation with the attached
patch. It fixes two issues:
- Newer versions of doxygen now interpret "" in "KeyData" as an
  the underline HTML command. The patch escapes it so that it is not
  interpreted anymore.
- Newer versions of doxygen have markdown support enabled by default,
  causing indented lines to be interpreted as the verbatim code.

Best regards,
Aurelien Jarno

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- a/Doxyfile.in
+++ b/Doxyfile.in
@@ -1758,3 +1758,13 @@ GENERATE_LEGEND= YES
 # the various graphs.
 
 DOT_CLEANUP= YES
+
+# If the MARKDOWN_SUPPORT tag is enabled then doxygen pre-processes all comments
+# according to the Markdown format, which allows for more readable
+# documentation. See https://daringfireball.net/projects/markdown/ for details.
+# The output of markdown processing is further processed by doxygen, so you can
+# mix doxygen, HTML, and XML commands with Markdown formatting. Disable only in
+# case of backward compatibilities issues.
+
+MARKDOWN_SUPPORT   = NO
+
--- a/Keyword.h
+++ b/Keyword.h
@@ -155,7 +155,7 @@ namespace CCfits {
\param val (T) Will be filled with the keyword value, and is also the function return value.
 
Allowed T types: CCfits stores keyword values of type U in a templated subclass of
-   Keyword, KeyData.  Normally U is set when reading the Keyword in from the file, 
+   Keyword, KeyData\.  Normally U is set when reading the Keyword in from the file, 
and is limited to types int, double, string, bool, and complex.
(The exception is when the user has created and added a new Keyword using an
HDU::addKey function, in which case they might have specified other types for U.)  
@@ -180,7 +180,7 @@ namespace CCfits {
\param newValue (T) New value for the Keyword
 
Allowed T types: This must copy newValue to a data member of type U in the
-   Keyword subclass KeyData (see description for Keyword::value (T& val) for more
+   Keyword subclass KeyData\ (see description for Keyword::value (T& val) for more
details).  To avoid compilation errors, it is generally best to provide a newValue
of type T = type U, though the following type conversions will also be handled:
 


signature.asc
Description: PGP signature

Bug#952555: azure-uamqp-python: please make the build reproducible

[Luca Boccassi]

Control: tags -1 pending

On Tue, 2020-02-25 at 10:17 -0800, Chris Lamb wrote:
> Source: azure-uamqp-python
> Version: 1.2.6-1
> Severity: wishlist
> Tags: patch
> User: 
> reproducible-bui...@lists.alioth.debian.org
> 
> Usertags: filesystem buildpath
> X-Debbugs-Cc: 
> reproducible-b...@lists.alioth.debian.org
> 
> 
> Hi,
> 
> Whilst working on the Reproducible Builds effort [0] we noticed that
> azure-uamqp-python could not be built reproducibly.
> 
> This is because it generated a .pyx file with the "#include"
> directives in a nondeterminstic order as well as included metadata in
> a ".c" file that embeded the absolute buildpath. However, it still
> embeds the current build path in the binary via assert-like logging
> messages ("LogError" IIRC).
> 
> Patch attached for the former two issues.
> 
> 
>  [0] 
> https://reproducible-builds.org/

Hi,

Thanks! I sent a similar patch upstream a few days ago and was
intending to push it in the next upload:

https://github.com/Azure/azure-uamqp-python/pull/144

I need to check the CMake build for the vendored library (brr) - it
might not be taking all the compiler flags from dpkg. IIRC we have a
custom gcc patch to override the paths for __FUNCTION__ and friends,
right?

-- 
Kind regards,
Luca Boccassi


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

Bug#952543: Using old libfmt breaks sopt and purify

[Michael R. Crusoe]

On Tue, 25 Feb 2020 15:22:10 +0100 Ole Streicher  wrote:

> Since spdlog uses the old (included) libfmt, the builds of purify and
> sopt fail with linker errors like:
>
> undefined reference to `fmt::v6::internal::assert_fail(char const*, int,
> char const*)
>
> See the merged bugs for the reports. Could you revert this change? Or
> somehow make it work (I guess, the library itself would need to be
> included).

Thanks for the report. spdlog 1.5 requires a newer libfmt, otherwise the 
tests don't pass


libfmt 6.1.2 has been uploaded to experimental: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950857 and I just 
confirmed that it allows the spdlog tests to pass


So libfmt-dev >= 6.1.2 reaches sid we can rebuild its downstream packages.

Bug#952555: azure-uamqp-python: please make the build reproducible

[Chris Lamb]

Source: azure-uamqp-python
Version: 1.2.6-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: filesystem buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
azure-uamqp-python could not be built reproducibly.

This is because it generated a .pyx file with the "#include"
directives in a nondeterminstic order as well as included metadata in
a ".c" file that embeded the absolute buildpath. However, it still
embeds the current build path in the binary via assert-like logging
messages ("LogError" IIRC).

Patch attached for the former two issues.


 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1969-12-31 16:00:00.0 
-0800
--- b/debian/patches/reproducible-build.patch   2020-02-25 08:40:37.020019063 
-0800
@@ -0,0 +1,24 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2020-02-25
+
+--- azure-uamqp-python-1.2.6.orig/setup.py
 azure-uamqp-python-1.2.6/setup.py
+@@ -45,7 +45,7 @@ cwd = os.path.abspath('.')
+ 
+ # Headers
+ 
+-pxd_inc_dir = os.path.join(cwd, "src", "vendor", "inc")
++pxd_inc_dir = os.path.join(".", "src", "vendor", "inc")
+ sys.path.insert(0, pxd_inc_dir)
+ 
+ include_dirs = [
+@@ -68,7 +68,7 @@ else:
+ 
+ def create_cython_file():
+ content_includes = ""
+-for f in os.listdir("./src"):
++for f in sorted(os.listdir("./src")):
+ if f.endswith(".pyx"):
+ print("Adding {}".format(f))
+ content_includes += "include \"src/" + f + "\"\n"
--- a/debian/patches/series 1969-12-31 16:00:00.0 -0800
--- b/debian/patches/series 2020-02-25 08:29:13.434683576 -0800
@@ -0,0 +1 @@
+reproducible-build.patch
--- a/setup.py  2020-02-25 08:08:37.986925148 -0800
--- b/setup.py  2020-02-25 08:47:27.151166104 -0800
@@ -45,7 +45,7 @@
 
 # Headers
 
-pxd_inc_dir = os.path.join(cwd, "src", "vendor", "inc")
+pxd_inc_dir = os.path.join(".", "src", "vendor", "inc")
 sys.path.insert(0, pxd_inc_dir)
 
 include_dirs = [
@@ -68,7 +68,7 @@
 
 def create_cython_file():
 content_includes = ""
-for f in os.listdir("./src"):
+for f in sorted(os.listdir("./src")):
 if f.endswith(".pyx"):
 print("Adding {}".format(f))
 content_includes += "include \"src/" + f + "\"\n"

Bug#952554: gzip: Please package new upstream version (1.10)

[Boyuan Yang]

Source: gzip
Severity: normal
Version: 1.9-3
X-Debbugs-CC: bd...@debian.org cwo...@debian.org

Dear Debian gzip maintainers,

The gzip upstream has released new version v1.10. Please consider packaging it
in Debian. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952335: [Pkg-javascript-devel] Bug#952335: uglify-js: FTBFS: ERROR: `m` is not a supported option

[Jonas Smedegaard]

control: reassign -1 node-commander
control: affects -1 uglify-js

Quoting Xavier (2020-02-25 18:43:53)
> Le 23/02/2020 à 14:31, Lucas Nussbaum a écrit :
> > During a rebuild of all packages in sid, your package failed to 
> > build on amd64.
> 
> At least uglify-js (https://salsa.debian.org/js-team/uglifyjs) is 
> incompatible with node-commander 4

Then it seems node-commander upgrade (done by you, Xavier) was badly 
coordinated and should be reverted.


 - 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#952481: texlive: mktexpk fails to create tcrm1000

[Holger Wansing]

Hello Norbert,

Norbert Preining  wrote:
> Hi Holger,
> 
> On Mon, 24 Feb 2020, Holger Wansing wrote:
> > http://qa-logs.debian.net/2020/02/22/installation-guide_20191229_unstable.log
> 
> What is there is
>   Writing build.out.el.amd64/html/index.html for book
>   Info: creating .pdf file...
> 
>   kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+0/600 --dpi 600 
> tcrm1000
>   mkdir: cannot create directory 
> ‘build.tmp.el.i386/dblatex/mt7684.tmp’: No such file or directory
>   kpathsea: Appending font creation commands to missfont.log.
> 
> which means that something in the build process is hosed .. either write
> permissions or whatever, so this is strange.
> 
> Furthermore, by default these files are generated in /tmp, unless you
> set TEMPDIR to something else, see 
> /usr/share/texlive/texmf-dist/web2c/mktex.opt
>   if test -n "$TMPDIR"; then
> TEMPDIR="${TMPDIR}/mt$$.tmp"
>   else
> TEMPDIR="/tmp/mt$$.tmp"
>   fi
>   ...
>   (umask 077 && mkdir "$TEMPDIR") || exit 1
> So if $TMPDIR is not available, then there is something strange going
> on.

The TMPDIR variable is set to 'build.tmp' so it's strange that mktexpk tries to
use 'build.tmp.el.i386' which is in fact not existing...

> 
> Anyway, you **don't** want pk fonts (pixel fonts) in a PDF, so you
> **should** depend on the
>   cm-super
> fonts to get proper type1 fonts that are scalable (without pixelation).
> 
> My guess (wild guess) is the following:
> - before tcrm fonts were not necessary because they were not used by the
>   LaTeX kernel, and thus no extra build process (mktex*) was called
> - the new LaTeX kernel requires tc fonts (because textcomp is loaded)
> - your package *always* had some setup that prevented creating of
>   directories or similar
> - the recent changes made this obvious.
> 
> So as said, there are two things to be done:
> - either make the directory writable, then the fonts will be generated
>   and included into the pdf properly

Hmm, no, that does not work: if I create the 'build.tmp.el.i386' dir from 
above by hand, the mktexpk call does no longer fail, however the PDF is not 
generated, the process fails at another (later) step.

> - depend on cm-super
> or both.

I installed cm-super on the machine, but the build fails with the same error
(with the same mktexph call).



However, I wonder what's going on at all with fonts:
we call dblatex with

(TMPDIR=$tempdir/dblatex dblatex -q -V -T db2latex -b xetex -p 
./stylesheets/dblatex.xsl \
-o $tempdir/install.${language}.pdf \
$tempdir/install.${language}.profiled.xml --param=lingua=${language} )

and in the dblatex.xsl file we set the fonts to use, like this:


  
   

\usepackage{xeCJK}
\setCJKmainfont{VL-PGothic-Regular}
\setCJKsansfont{VL-PGothic-Regular}
\setCJKmonofont{VL-PGothic-Regular}
\setmainfont{VL-PGothic-Regular}
\setsansfont{VL-PGothic-Regular}
\setmonofont{VL-PGothic-Regular}


\usepackage{xeCJK}
\usepackage[hangul]{kotex}
\setCJKmainfont{Noto Serif CJK KR}
\setCJKsansfont{Noto Sans CJK KR}
\setCJKmonofont{Noto Sans Mono CJK KR}
\setmainfont{Noto Serif CJK KR}
\setsansfont{Noto Sans CJK KR}
\setmonofont{Noto Sans Mono CJK KR}


\usepackage{xeCJK}
\setCJKmainfont{WenQuanYi Micro Hei}
\setCJKsansfont{WenQuanYi Micro Hei}
\setCJKmonofont{WenQuanYi Micro Hei Mono}
\setmainfont{WenQuanYi Micro Hei}
\setsansfont{WenQuanYi Micro Hei}
\setmonofont{WenQuanYi Micro Hei Mono}


\setmainfont{FreeSerif}
\setsansfont{FreeSans}
\setmonofont{FreeMono}

   
  



So, for the failing Greek variant the 'otherwise' clause is matching, and
the Free-font fonts from the 'fonts-freefont-ttf' debian-package are used.

Why mktexpk is called to use that jknappen font from tcrm?

Am I missing something here?


Thanks
Holger


PS: in case you need the original code of installation-guide, it's here:
https://salsa.debian.org/installer-team/installation-guide/-/tree/master/build
the PDF generation is in buildone.sh starting from line 186.


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

Bug#952546: bootstrap.min.js in pydoctor

[Jonas Smedegaard]

Quoting Ian Jackson (2020-02-25 18:40:47)
> For -devel, context is that Anthony Fok just uploaded a new upstream 
> version of pydoctor (a tool for extracting API docs for python 
> modules) in order to fix a couple of upstream bugs.  Anthony, thank 
> you very much for your work to help fix one of our (mutual) indirect 
> dependencies.
> 
> Unfortunately the new pydoctor has some DFSG issues (#952546, CC'd).
> 
> I am hoping that -devel can advise what the conventional approach is 
> to the package containing a sourceless copy of bootstrap.min.js.
> 
> I'm guessing that the answer is to strip the sourceless file from the 
> package, and have the binary package contain a symlink into the file 
> tree of some other package which contains an appropriate bootstrap 
> file ?  But is this right, and if so which package ?
> 
> I vaguely remembered this having been discussed before but I couldn't 
> find the conclusions written down anywhere.  I looked in quite a few 
> places for answers to this: I searched the lintian tags for missing 
> source, but they all seemed quite generic.  I tried to search -devel 
> archives for "bootstrap" (too many hits) and "bootstrap.min.js" 
> (nothing relevant).  I tried various wiki searches too.

If you need Bootstrap 3.x, then add symlink to path 
/usr/share/javascript/bootstrap/js/bootstrap.min.js and depend on 
package libjs-bootstrap.

If instead you need Bootstrap 4.x, then you should do something similar 
but for some path below /usr/share/javascript/bootstrap4 and package 
libjs-bootstrap4 (I am vague here because that package apparently use a 
symlink internally requiring actually installing the package to know for 
certain which exact path it is - no, you should *not* link below 
/usr/share/nodejs as that path is not reliable).

 - 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#952464: clazy: flaky arm64 autopkgtest: unable to execute command: Segmentation fault

[Lisandro Damián Nicanor Pérez Meyer]

On 20/02/25 01:46, Lisandro Damián Nicanor Pérez Meyer wrote:
> On 20/02/24 09:10, Paul Gevers wrote:
> > Source: clazy
> > Version: 1.6-2
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: flaky
> > 
> > Dear maintainer(s),
> 
> Hi Paul, thanks for the bug report.
>  
> > With a recent upload of gcc-10 to unstable, the autopkgtest of clazy
> > failed on arm64 in testing when that autopkgtest was run with the binary
> > packages of gcc-10 from unstable. I looked into the history of your
> > autopkgtest and it fails very often.
> 
> I'm not the direct uploader of this package, but I'll try to fix this.
> This seems to be a failure in llvm/clang though.
> 
> Team members: I'm currently looming at 
> 

I *think* the bug is related to the clang/llvm version used, as I think they
mismatched in the autopkgtests. Maybe both debian/control and
debian/test/control should depend upon a specific clang version, and we should
try to rebuild clazy with each new version as possible, as we do with
qt creator.

Bug#952335: [Pkg-javascript-devel] Bug#952335: uglify-js: FTBFS: ERROR: `m` is not a supported option

[Xavier]

Le 23/02/2020 à 14:31, Lucas Nussbaum a écrit :
> Source: uglify-js
> Version: 3.6.3-1
> Severity: serious
> Justification: FTBFS on amd64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20200222 ftbfs-bullseye
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

At least uglify-js (https://salsa.debian.org/js-team/uglifyjs) is
incompatible with node-commander 4

Bug#952546: bootstrap.min.js in pydoctor

[Ian Jackson]

For -devel, context is that Anthony Fok just uploaded a new upstream
version of pydoctor (a tool for extracting API docs for python
modules) in order to fix a couple of upstream bugs.  Anthony, thank
you very much for your work to help fix one of our (mutual) indirect
dependencies.

Unfortunately the new pydoctor has some DFSG issues (#952546, CC'd).

I am hoping that -devel can advise what the conventional approach is
to the package containing a sourceless copy of bootstrap.min.js.

I'm guessing that the answer is to strip the sourceless file from the
package, and have the binary package contain a symlink into the file
tree of some other package which contains an appropriate bootstrap
file ?  But is this right, and if so which package ?

I vaguely remembered this having been discussed before but I couldn't
find the conclusions written down anywhere.  I looked in quite a few
places for answers to this: I searched the lintian tags for missing
source, but they all seemed quite generic.  I tried to search -devel
archives for "bootstrap" (too many hits) and "bootstrap.min.js"
(nothing relevant).  I tried various wiki searches too.

(The d/copyright problem with epydoc should be easy if tedious to fix;
I don't understand why it wants epydoc which I thought was obsolete
but this is far from my field of expertise.)

Regards,
Ian.

Bug#948940: Merge requests for FTBFS in Qt/KDE packages

[John Scott]

I have now prepared merge requests for fixing ktp-common-internals, 
ktp-accounts-kcm,
and kaccounts-providers respectively [1] [2] [3]. These issues are all fixed in
new upstream releases, but I am not comfortable with such an undertaking and
hope these fixes will suffice in the meantime.

[1] 
https://salsa.debian.org/qt-kde-team/kde/ktp-common-internals/-/merge_requests/1
[2] 
https://salsa.debian.org/qt-kde-team/kde/kaccounts-providers/-/merge_requests/2
[3] https://salsa.debian.org/qt-kde-team/kde/ktp-accounts-kcm/-/merge_requests/1

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

Bug#952553: RFS: diodon/1.9.0-1 [RC] -- GTK+ Clipboard manager

[Oliver Sauder]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: diodon
   Version : 1.9.0-1
   Upstream Author : Oliver Sauder 
 * URL : https://launchpad.net/diodon
 * License : GPL-2+
 * Vcs :
https://git.launchpad.net/~diodon-team/+git/debian-packaging/
   Section : utils

It builds those binary packages:

  diodon - GTK+ Clipboard manager
  libdiodon0 - GTK+ Clipboard manager (main library)
  gir1.2-diodon-1.0 - GTK+ Clipboard manager (GObject introspection data)
  diodon-dev - GTK+ Clipboard manager (development files)

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/d/diodon/diodon_1.9.0-1.dsc

Changes since the last upload:

   * New upstream release.
   * Add support for valac 0.46 (Closes: #951924)
   * Replace waf with meson as build system (Closes: #936399, #943038)
   * Change Vcs to git
   * Update minimum build dependency versions
   * Bump Standard Version to 4.4.0

Regards,

--
  Oliver Sauder



signature.asc
Description: OpenPGP digital signature

Bug#924099: RFP: click-man -- Automate generation of man pages for python click applications

[Ryan Pavlik]

I created a package for this as a part of packaging a Click-based tool
where, as you described, I didn't like the manual options for manpage
creation. (Started with py2dsp output but have made it better than
that.) I'd be happy to collaborate with you on it.


Ryan


On Sat, 09 Mar 2019 16:05:08 +0100 Nicolas Braud-Santoni
 wrote:

> Package: wnpp
> Severity: wishlist
>
> * Package name : click-man
> Version : 0.3.0
> Upstream Author : Timo Furrer 
> * URL : https://github.com/click-contrib/click-man
> * License : MIT
> Programming Lang: Python
> Description : Automate generation of man pages for python click
> applications
> 
> 
> click-man is a tool that can automatically generate manpages for
> application
> written with the click CLI framework. It provides setuptools
> integration and
> can easily be used during the build of a Debian package:
> 
> https://github.com/click-contrib/click-man#debian-packages
> 
> 
> As far as I know, current packaging practices involve either
> 1. writing a manpage by hand, which is a lot of work
> 2. generating it ahead-of-time with help2man or somesuch, and
> commiting it to
> the debian/ directory, where it might get out-of-sync with the actual
> program
> 3. not shipping manpages at all :(
> 
> Automatically generating a manpage during package build would
> definitely be
> preferable to (2) and (3), and possibly to (1) if the result is of
> sufficient
> quality.
> 
> 
> I cannot currently commit to packaging and maintaining this package,
> hence why I
> am filing a RFP, and in any case I would probably appreciate having a
> comaintainer. :)
> 
> 
> Best,
> 
> nicoo
> 
>



0xCBC55E3D986A54C7.asc
Description: application/pgp-keys

Bug#952552: network-manager: unable to connect to wired network

[Simon Bernard]

Package: network-manager
Version: 1.14.6-2+deb10u1
Severity: normal

Dear Maintainer,

I'm unable to connect to wired network using my thinkpad T430 at works.
I tested it at home and it works. WIFI works at home or works.
I have another laptop latitude dell 7480 with buster 10 installed too and it
works.
(I tested with the same cable/ethernet socket plug)

Sometime (pretty rare) connection is established but does really work (e.g.
unable to send http request)

My feeling is this looks like to :
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/166 (even
if
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/166#note_170215
does not match)


Here is some syslog :
Feb 25 18:00:51 octavesim octave: = Connect
manualy to my wired connection 1 ==
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4880]
active-connection[0x5644f9b46ba0]: creating
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4881]
active-connection[0x5644f9b46ba0]: set device "enp0s25" [0x5644f9b9afa0]
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4882]
device[0x5644f9b9afa0] (enp0s25): add_pending_action (1):
'activation-0x5644f9b46ba0'
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4891]
active-connection[0x5644f9b46ba0]: constructed (NMActRequest, version-id 6,
type managed)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4895] auth:
call[492]: CheckAuthorization(org.freedesktop.NetworkManager.network-control),
subject=unix-process[pid=1459, uid=1000, start=15517]
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4935] auth:
call[492]: completed: authorized=1, challenge=0
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4936] dbus-
object[0x5644f9b46ba0]: export:
"/org/freedesktop/NetworkManager/ActiveConnection/6"
Feb 25 18:00:57 octavesim NetworkManager[534]:   [1582650057.4939] device
(enp0s25): Activation: starting connection 'Wired connection 1'
(6fe8900f-29c2-4c71-8acd-ea9745c5ad5e)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4940]
device[0x5644f9b9afa0] (enp0s25): activation-stage: schedule
activate_stage1_device_prepare,v4 (id 944)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4940]
settings-connection[0x5644f9b442a0,6fe8900f-29c2-4c71-8acd-ea9745c5ad5e]:
autoconnect: blocked reason: none
Feb 25 18:00:57 octavesim NetworkManager[534]:   [1582650057.4941] audit:
op="connection-activate" uuid="6fe8900f-29c2-4c71-8acd-ea9745c5ad5e"
name="Wired connection 1" pid=1459 uid=1000 result="success"
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4942]
device[0x5644f9b9afa0] (enp0s25): activation-stage: invoke
activate_stage1_device_prepare,v4 (id 944)
Feb 25 18:00:57 octavesim NetworkManager[534]:   [1582650057.4944] device
(enp0s25): state change: disconnected -> prepare (reason 'none', sys-iface-
state: 'managed')
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4944]
device[0x5644f9b9afa0] (enp0s25): autoconnect-blocked: set "none" (was "manual-
disconnect")
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4953]
active-connection[0x5644f9b46ba0]: set state activating (was unknown)
Feb 25 18:00:57 octavesim NetworkManager[534]:   [1582650057.4957]
manager: NetworkManager state is now CONNECTING
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4960]
active-connection[0x5644f9b46ba0]: check-master-ready: not signalling (state
activating, no master)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4960]
manager: default-route-metric: ifindex 2 reserves metric 100 (aspired 100)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4961]
manager: ActivatingConnection now Wired connection 1
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4962]
device[0x5644f9b9afa0] (enp0s25): set-link: ignore link negotiation
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4963]
device[0x5644f9b9afa0] (enp0s25): activation-stage: schedule
activate_stage2_device_config,v4 (id 945)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4963]
device[0x5644f9b9afa0] (enp0s25): activation-stage: complete
activate_stage1_device_prepare,v4 (id 944)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4963]
device[0x5644f9b9afa0] (enp0s25): activation-stage: invoke
activate_stage2_device_config,v4 (id 945)
Feb 25 18:00:57 octavesim NetworkManager[534]:   [1582650057.4963] device
(enp0s25): state change: prepare -> config (reason 'none', sys-iface-state:
'managed')
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4967]
device[0x5644f9b9afa0] (enp0s25): bringing up device 2
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4968]
platform: link: setting up "enp0s25" (2)
Feb 25 18:00:57 octavesim NetworkManager[534]:  [1582650057.4968]
platform-linux: link: change 2: flags: set 0x1/0x1 ([up] / [up])
Feb 25 18:00:57 octavesim NetworkManager[534]: