Bug#952826: [www.debian.org] partners: convert svg graphics into png to make tidy happy

[Carsten Schoenert]

Hi,

Am 01.03.20 um 02:02 schrieb Ricardo:
> Hello,
> images in svg are the source. Would be better to store in svg format
> and convert to png in build time. Are there only external companies
> logos in repository, or are there some images that we may change in
> the future? If we will not resize the images or change them in other
> way, then I think it would be viable to convert and store them to png
> format.

it's absolutely fine to use SVG graphics in recent days and if ever
possible we should use them natively. The world is using more and more
HTML5!
The Debian websites due mostly heavily lack on a mobile friendly face.
To get this working we will need graphics that scale smoothly and please
no special hacks within the HTML source to solve various demands. SVG
graphics are solving this specific need perfectly.

> If choose to convert them, as far as I know, we need to install a
> software in the build container and it takes some time. Maybe there is
> one container with the required software or the build process is made
> in other way. Store only the svg would make thinks more organized and
> easy to edit.

This turns more into a chicken egg problem in a longer view, or in my
eyes, we should solve problems on the ride side or more correctly.
Means, we need a strategy how the websites should evolve within the next
five years for example.
The Debian website is growing every day and by this the load and time to
build the whole website is also growing constantly. At one day we need
to think about this circumstance.

We currently using still DTD HTML 4.01 Strict for the websites and not
something more up to date, but this has of course some reason.

[snip]
> 2020-02-29 19:33 GMT-03:00, Holger Wansing :
>> Package: www.debian.org
>>
>> As tidy constantly complains about
>>
>> *** /srv/www.debian.org/www/partners/2018/index.en.html
>> line 159 column 3 - Warning:  attribute "width" has invalid value 
>> "height="
>> line 255 column 3 - Warning:  attribute "width" has invalid value 
>> "height="

...

>> which is all about width/height information in svg graphics:
>>
>> what about converting the relevant images (google.svg and
>> stackpack-logo-reversed.svg)
>> into some other format, like png?

This would be a workaround in my eyes instead of solving the root of the
problem.

How can I run this tidy thing locally so I can try to narrow down the issue?

>> Please excuse my ignorance, I have no detailed knowledge on vector
>> graphics:
>> maybe there is a reason why we should use svg there.
>> However, png is widely used in the partners section...

I'd like to see we do not convert SVG to PNG here because this is a step
back in my eyes, especially as we need to take the advantage of getting
all sites mobile ready one day and this shouldn't be done by graphics
and logos with some other formats than SVG as this will always result in
higher data rates to transfer.

-- 
Regards
Carsten Schoenert

Bug#952824: thunderbird: Line length is limited to 54 characters instead of 72

[Gregor Riepl]

> We have collected some steps you should mind within the Wiki.
> 
> https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

I disabled all addons and also tried safe mode: Doesn't make a
difference. I didn't try to create a fresh profile.

And I couldn't find any bugs on the Debian tracker or Bugzilla that
looked like this one.

> This isn't completely correct from a technical aspect.
> Thunderbird is still using the default line wrapping on 72 characters.
> This is easy to check if you send an email to yourself.

Unfortunately, this is not the case: The sent email has its text wrapped
at ~54 characters, when autowrap is enabled. It's not just a
presentation issue.

When I look at response mails from other people, I can see
that the quoted text was hard-wrapped by TB in the wrong places, while
the responder's text is fine.

> I do workaround around this temporally by adjusting the DPI scaling
> using the key combination 'Crtl +' or using the 'Crtl' key and the
> scroll wheel on the mouse.

That's a... very interesting workaround.
Even more interestingly, the text size doesn't even change when I "zoom"
using Ctrl-+, only the wrapping. Only at high zoom levels do I get a
change in font size. But that could very well be due to minimum font size.

Now that I look at it, that's a setting that I did customise a very long
time ago. Thunderbird has always had issues with font sizes and Hi-DPI
rendering on Linux. My Proportional font size is set to 16, while
Monospace is set to 12. Minimum font size is 16. Without this, text
would render way too small. I'll see if changing/resetting these makes
any difference.

>> This was not the case with Firefox 68.4.
> 
> You mean Thunderbird here for sure.

Yes of course. My bad.

>> As a workaround, it's possible to set mail.wrap_long_lines and
>> plain_text.wrap_long_ones to false, but this is undesirable.
> 
> By this you turn off the line wrapping totally, for plain text
> (plain_text.x) and HTML (mail.x).

Yes... That's why I think it's undesirable.

When I combine your zooming suggestion with disabling these two options,
wrapping isn't totally messed up any more. But the text still wraps.

> The issue you seeing is a upstream problem, it happen too with the
> provided upstream binaries from Mozilla so it should get reported on the
> bugzilla tracker of Mozilla. Would you take care of this and create a
> upstream bug report and provide the URL on this?

Yes, I can do that.
I wasn't sure if the issue was something in Debian or a general problem.
Thanks for the explanation.

Do you have any ideas what the root of the problem could be?
A bug in in GTK3? Incorrect usage of font metrics APIs?

Bug#952835: [live-build] redundant file scripts/build/chroot_live-packages

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: !

the scripts/build/chroot_live-packages file is redundant and needs
removing.

see the to-be submitted patch for details.

patch will follow shortly once I've updated it with the bug number.
look out for a salsa merge request...

Bug#952834: [live-build]

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: !

the scripts/build/source_debian-live file is redundant and needs
removing.

see the to-be submitted patch for details.

patch will follow shortly once I've updated it with the bug number.
look out for a salsa merge request...

Bug#952824: thunderbird: Line length is limited to 54 characters instead of 72

[Gregor Riepl]

>> I do workaround around this temporally by adjusting the DPI scaling
>> using the key combination 'Crtl +' or using the 'Crtl' key and the
>> scroll wheel on the mouse.
> 
> That's a... very interesting workaround.
> Even more interestingly, the text size doesn't even change when I "zoom"
> using Ctrl-+, only the wrapping. Only at high zoom levels do I get a
> change in font size. But that could very well be due to minimum font size.
> 
> Now that I look at it, that's a setting that I did customise a very long
> time ago. Thunderbird has always had issues with font sizes and Hi-DPI
> rendering on Linux. My Proportional font size is set to 16, while
> Monospace is set to 12. Minimum font size is 16. Without this, text
> would render way too small. I'll see if changing/resetting these makes
> any difference.

Looks like this is the root of the problem:
Thunderbird before 68.5 always calculates the wrapping position
correctly, no matter which font size is selected.

In 68.4, the (minimum) font size influences wrapping.

I changed all the font sizes back to 12, and now it wraps correctly at
72 characters, no matter which zoom level is chosen. Zooming in only
enlarges the text, as expected.

Is there any way to make Thunderbird honour the platform's DPI setting
and render all text in a readable size, so I don't have to fiddle with
the font sizes any more?

Bug#952836: bugs.debian.org: submit with 'owner: !'

[jnqnfe]

Package: bugs.debian.org

I just submitted a couple bugs for which I'm claiming ownership, and
having noted that control submissions allow '!' to be specified as the
owner which indicates _me_ the email sending this, I assumed that this
would work for submissions also but it seems not.

why not? submissions do process an owner property, so why not the
'owner: !' shortcut?

Bug#952837: [live-build] wrong action in chroot_archives usage

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the source stage uses the wrong parameter value for a call to
chroot_archives.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#790925: not fixed - pandas: HDF I/O crashes on armhf - bus error

[Rebecca N. Palmer]

Control: reopen -1
Control: found -1 0.25.3+dfsg-6
Control: retitle -1 pandas: HDF I/O crashes on armhf - bus error

test_append_frame_column_oriented does still exist - it was being 
silently skipped by -m "not single".  Having removed that, it again 
crashes on armhf, as do TestHDFStore.test_encoding and 
test_select_filter_corner (but not test_complex_across_dimensions).


These tests are now again skipped to avoid an FTBFS, but are still a 
bug.  I don't have a backtrace because they don't crash in qemu-armhf.

Bug#952838: [live-build] missing package list removal

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the chroot_archives script is missing a line to remove a package list.

(I know that this description is not very useful, I'm just submitting
this to get a bug number for an old patch that never got merged but
still applies).

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952839: [live-build] wrong usage strings

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

bootstrap_archives and chroot_archives both have incorrect usage
strings, missing the source|binary 'pass' param info.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952840: O: python-ssdeep

[Helmut Grohne]

Package: wnpp
Severity: normal

I don't use python-ssdeep anymore as it didn't solve my problem. I think
the package is in good shape if you ignore that it needs updating to a
new upstream release. It has very low popcon and a viable competitor
python3-tlsh. Possibly, removing the package is a good solution in case
it poses problems.

Helmut

Bug#952841: [live-build] validation of 'pass' param (archive handling) would be useful

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

bootstrap_archives and chroot_archives would benefit from having
validation of the 'pass' parameter which resulted in usage info being
printed and the script existing, as with some other scripts. this for
instance would have caught a bug I just reported (for which I have no
number for just yet to reference here) had it already been in place.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952842: [live-build] broken sed replacement in archive handling

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the bootstrap_archives and chroot_archives scripts are missing the '-i' 
option for sed when intending to perform inplace modifications and thus
achieve nothing.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952843: [live-build] grub2 uses the wrong directory in certain cases

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

as titled. this is a sibling to the fix that just recently landed on
master for syslinux. I actually submitted the fix for both back in 2015
as part of a larger path set that was never merged. this is a
resubmission of just the grub2 fix on its own.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952845: transition: proj

[Bas Couwenberg]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 https://release.debian.org/transitions/html/auto-proj.html
Control: block -1 by 951655 951656

For the Debian GIS team I'd like to transition to PROJ 7.

It's not such a major change as the previous transition to PROJ 6 (#931949).

There were a few FTBFS with the RCs in experimental, but all except r-cran-sf
have been fixed in the mean time. There is a patch in the BTS for r-cran-sf,
which also fixes the FTBFS of r-cran-lwgeom when r-cran-sf is rebuilt.


Transition: proj

 libproj15 (6.3.1-1) -> libproj19 (7.0.0-1~exp1)

The status of the most recent rebuilds is as follows.

 josm(0.0.svn15806+dfsg-2)  OK

 atlas-ecmwf (0.19.0-8) OK
 gammaray(2.11.0-2) OK
 libgeotiff  (1.5.1-2)  OK
 mshr(2019.1.0+dfsg1-7) OK
 octave-octproj  (1.1.5-6)  OK
 osm2pgsql   (1.2.1+ds-1)   OK
 pdl (1:2.020-3)OK
 proj-rdnap  (2008+2018-4)  OK
 python-cartopy  (0.17.0+dfsg-9)OK
 python-pyproj   (2.5.0+ds-1)   OK
 sosi2osm(1.0.0-6)  OK
 spatialite  (4.3.0a-6) OK
 survex  (1.2.42-1) OK
 therion (5.4.4ds1-5)   OK
 xygrib  (1.2.6-1)  OK

 gdal(3.0.4+dfsg-1) OK
 gnudatalanguage (0.9.9-12) OK
 magics++(4.2.6-1)  OK
 spatialite-gui  (2.1.0~beta0+really2.0.0~devel2-5) OK
 spatialite-tools(4.3.0-3)  OK
 xastir  (2.1.4+git20191127.bb66a77-2)  OK

 cdo (1.9.9~rc1-1)  OK
 mapnik  (3.0.22+ds1-1) OK
 mapserver   (7.4.3-1)  OK
 metview (5.7.5-1)  OK
 mysql-workbench (8.0.19+dfsg-1)OK
 ncl (6.6.2-1)  OK
 openorienteering-mapper (0.9.1-1)  OK
 pdal(2.0.1+ds-1)   OK
 postgis (3.0.1+dfsg-1) OK
 qmapshack   (1.14.0-1) OK
 r-cran-rgdal(1.4-8-1)  OK
 r-cran-sf   (0.8-1+dfsg-1) FTBFS (#951655) / 
OK [+]
 saga(7.3.0+dfsg-3) OK
 sumo(1.4.0+dfsg1-1)OK
 vtk7(7.1.1+dfsg2-2)OK

 freecad (0.18.4+dfsg2-1)   OK
 grass   (7.8.2-1)  OK
 r-cran-lwgeom   (0.2-1-1)  FTBFS (#951656) / OK

 qgis(3.4.15+dfsg-1)OK


Kind Regards,

Bas

Bug#952844: pybuild: fix _PYTHON_SYSCONFIGDATA_NAME for python3.8

[Helmut Grohne]

Source: dh-python
Version: 4.20191017
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:tlsh

When cross building python extensions, one is supposed to export a
_PYTHON_SYSCONFIGDATA_NAME. Unfortunately, it contains the abi and from
3.7 to 3.8 we changed the abi. Now the _PYTHON_SYSCONFIGDATA_NAME is
version-dependent. Please update pybuild to issue the correct
_PYTHON_SYSCONFIGDATA_NAME for 3.8.

This breaks any package that tries to cross build a python extension for
python 3.8 such as tlsh. Likely more.

Helmut
diff --minimal -Nru dh-python-4.20191017/debian/changelog 
dh-python-4.20191017+nmu1/debian/changelog
--- dh-python-4.20191017/debian/changelog   2019-10-17 22:26:10.0 
+0200
+++ dh-python-4.20191017+nmu1/debian/changelog  2020-03-01 07:28:11.0 
+0100
@@ -1,3 +1,10 @@
+dh-python (4.20191017+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix _PYTHON_SYSCONFIGDATA_NAME for 3.8. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 01 Mar 2020 07:28:11 +0100
+
 dh-python (4.20191017) unstable; urgency=medium
 
   * dh_python2: generate python2 dependencies instead of python ones
diff --minimal -Nru dh-python-4.20191017/dhpython/build/base.py 
dh-python-4.20191017+nmu1/dhpython/build/base.py
--- dh-python-4.20191017/dhpython/build/base.py 2018-09-26 00:20:40.0 
+0200
+++ dh-python-4.20191017+nmu1/dhpython/build/base.py2020-03-01 
07:28:11.0 +0100
@@ -209,11 +209,11 @@
 if log_file is False and self.cfg.really_quiet:
 log_file = None
 command = command.format(**args)
+env = dict(context['ENV'])
 if 'PYTHONPATH' in args:
-env = dict(context['ENV'])
 env['PYTHONPATH'] = args['PYTHONPATH']
-else:
-env = context['ENV']
+if '_PYTHON_SYSCONFIGDATA_NAME' in args:
+env.setdefault('_PYTHON_SYSCONFIGDATA_NAME', 
args['_PYTHON_SYSCONFIGDATA_NAME'])
 log.info(command)
 return execute(command, context['dir'], env, log_file)
 
diff --minimal -Nru dh-python-4.20191017/pybuild 
dh-python-4.20191017+nmu1/pybuild
--- dh-python-4.20191017/pybuild2019-03-07 21:51:51.0 +0100
+++ dh-python-4.20191017+nmu1/pybuild   2020-03-01 07:28:11.0 +0100
@@ -76,12 +76,6 @@
 '_PYTHON_HOST_PLATFORM',
 '{DEB_HOST_ARCH_OS}-{DEB_HOST_ARCH}'.format(**arch_data))
 
-if arch_data['DEB_BUILD_ARCH'] != arch_data['DEB_HOST_ARCH']:
-# support cross compiling Python 3.X extensions, see #892931
-env.setdefault('_PYTHON_SYSCONFIGDATA_NAME',
-   ('_sysconfigdata_m_{DEB_HOST_ARCH_OS}'
-'_{DEB_HOST_MULTIARCH}').format(**arch_data))
-
 if cfg.system:
 certainty = 99
 Plugin = build.plugins.get(cfg.system)
@@ -231,6 +225,13 @@
  ).format(version, arch_data))
 args['PYTHONPATH'] = ':'.join(pp)
 
+# support cross compiling Python 3.X extensions, see #892931
+if (version.major >= 3 and
+arch_data.get('DEB_BUILD_ARCH', ' ') != 
arch_data.get('DEB_HOST_ARCH')):
+abi = '' if (version.major, version.minor) >= (3, 8) else 'm'
+args['_PYTHON_SYSCONFIGDATA_NAME'] = \
+
'_sysconfigdata_{abi}_{DEB_HOST_ARCH_OS}_{DEB_HOST_MULTIARCH}'.format(abi=abi, 
**arch_data)
+
 if not exists(args['build_dir']):
 makedirs(args['build_dir'])
 
@@ -256,11 +257,11 @@
 def run(func, interpreter, version, context):
 step = func.__func__.__name__
 args = get_args(context, step, version, interpreter)
+env = dict(context['ENV'])
 if 'PYTHONPATH' in args:
-env = dict(context['ENV'])
 env['PYTHONPATH'] = args['PYTHONPATH']
-else:
-env = context['ENV']
+if '_PYTHON_SYSCONFIGDATA_NAME' in args:
+env.setdefault('_PYTHON_SYSCONFIGDATA_NAME', 
args['_PYTHON_SYSCONFIGDATA_NAME'])
 
 before_cmd = get_option('before_{}'.format(step), interpreter, version)
 if before_cmd:

Bug#952846: [live-build] disk scripts overlook netboot

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the binary_disk and source_disk scripts overlook netboot in case
statements.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952847: [live-build] obsolete debootstrap param support check

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the bootstrap_debootstrap script performs a check for whether or not
debootstrap supports the --no-check-gpg option. this option has been
present in deboostrap since 1.0.30 so this check is long overdue for
removal.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952848: [live-build] bootstrap-cache issues message at wrong time

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

a message output by bootstrap_cache needs moving such that it is only
output when actually relevant.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952849: [live-build] rootfs deletion of file from wrong location

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the binary_rootfs script incorrectly tries to delete
chroot/chroot/excludes instead of chroot/excludes.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952850: [live-build] rootfs chmod of file only done in one case not other

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the binary_rootfs script allies chmod 644 to the squashfs file in one
case but not another.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952851: [live-build] unquoted string in installer script

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the installer_debian-installer script contains an unquoted "true"
string.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952853: thunderbird: Account wizard fails to configure server settings using Mozilla's own autoconfig protocol, uses heuristic, fails

[Justus Winter]

Package: thunderbird
Version: 1:68.4.1-1~deb10u1
Severity: normal

Dear Maintainer,

I'm trying to improve the account creation for a mail server setup of
mine.  To this end, I setup and configured automx2 on the server, and
now I'm trying to get Thunderbird to use it.  automx2 implements
Mozilla's autoconfiguration protocol:

https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat

Sadly, Thunderbird's account creation wizard fails to use this
information.  I increased the log level on
mail.wizard.logging.{console,dump} to "All", and captured a log of
this interaction (see below).

The curious thing is that the autoconfiguration actually seems to
succeed:

2020-03-01 10:37:43 mail.setup  INFOfound config:
Incoming: imap, harrington.uberspace.de:993, SSL, auth: plain, username: 
(redacted), password: not set
Outgoing: smtp, harrington.uberspace.de:587, STARTTLS, auth: plain, username: 
(redacted), password: not set
2
2020-03-01 10:37:43 mail.setup  INFOCannot contact server
2

This is the right information, I don't understand why it says "Cannot
contact server":

% socat - tcp:harrington.uberspace.de:587
220 harrington.uberspace.de ESMTP
^C
% socat - openssl:harrington.uberspace.de:993
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
AUTH=PLAIN] Dovecot ready.
^C

This information is coming from the first source that Thunderbird
tries:

2020-03-01 10:37:42 mail.setup  INFORequesting 

2

% curl 
https://autoconfig.probier.email/mail/config-v1.1.xml?emailaddress=foobar@probier.email
probier.emailprobier.emailprobier.emailharrington.uberspace.de993SSL%EMAILADDRESS%plainharrington.uberspace.de587STARTTLS%EMAILADDRESS%plain

Thunderbird then goes on to try Microsoft's autodiscover protocol,
which should also be implemented by automx2, but that fails (haven't
looked into this deeper).  Finally, it tries some heuristic, which
mistakenly uses "probier.email" as the server name (which kinda works,
modulo TLS cert common name).

Manual configuration of the account works fine.


I expect autoconfiguration to work using Mozilla's own protocol.  If
anything goes wrong with that (maybe automx2 doesn't correctly
implement the protocol?), I'd like to see a more informative error
message in the log.

Feel free to test this with someaddress@probier.email.

*** bugs/thunderbird.all.log
2020-03-01 10:36:59 mail.setup  INFOInitializing setup wizard
2
2020-03-01 10:36:59 mail.setup  INFOEmail account setup dialog 
loaded.
2
2020-03-01 10:36:59 mail.setup  INFOswitching to UI mode start
2
2020-03-01 10:37:42 mail.setup  INFOfindConfig()
2
2020-03-01 10:37:42 mail.setup  INFOswitching to UI mode find-config
2
2020-03-01 10:37:42 mail.setup  WARNspinner start 
looking_up_settings
2
2020-03-01 10:37:42 mail.setup  INFOstatus msg: Looking up 
configuration…
2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFORequesting 

2
2020-03-01 10:37:42 mail.setup  INFOcall 0 took 19ms and failed 
with local file not found
2
2020-03-01 10:37:42 mail.setup  INFOgetmx took 74ms
2
2020-03-01 10:37:42 mail.setup  INFOcall 3 took 75ms and failed 
with [Exception... "Component returned failure code: 0x804b0050 
(NS_ERROR_INSUFFICIENT_DOMAIN_LEVELS) 
[nsIEffectiveTLDService.getBaseDomainFromHost]"  nsresult: "0x804b0050 
(NS_ERROR_INSUFFICIENT_DOMAIN_LEVELS)"  location: "JS frame :: 
chrome://messenger/content/accountcreation/fetchConfig.js :: 
fetchConfigForMX/sucAbortable.current< :: line 189"  data: no]
2
2020-03-01 10:37:43 mail.setup  INFOcall 1 took 135ms and failed 
with 404 Not Found at 

2
2020-03-01 10:37:43 mail.setup  INFOcall 3 took 136ms and failed 
with 404 Not Found at 

2
Exception { name: "NS_ERROR_INSUFFICIENT_DOMAIN_LEV

Bug#952854: [live-build] disks handling for netboot

[jnqnfe]

Package: live-build
Version: 1:20191221

this is an extension of #952846 which concerns netboot being missing in
case statements in binary_disk and source_disk.

i'm making a fresh bug report here because my intention with the former
bug number is to assign a bug number for my patches which just add in
the necessary case entries...

...there is still the matter of what should be done in the binary_disk
case besides creation of the disk info file, if anything. i.e. this bug
concerns addressing a fixme left in my #952846 patches.

I'm submitting this perhaps prematurely, perhaps review of #952846
before it is merged will demand addressing the fixme somehow, but I'm
not certain myself what is required to do so, and so I'm hoping that my
patches will close #952846 and this new report will remain regarding
the fixme.

Bug#936288: CFV progress of Python3 port: https://github.com/cfv-project/cfv/issues/8

[Mantas Baltix]

Upstream progress of Python3 port:
https://github.com/cfv-project/cfv/issues/8

Btw, it seems development of original cfv has stalled, see
https://sourceforge.net/p/cfv/bugs/19/ but there is active fork and
2.0 release since 2019:

https://github.com/cfv-project/cfv

New upstream plans to be included into Debian:
https://github.com/cfv-project/cfv/issues/4

-- 
Prekyba kompiuteriais su Linux OS - http://tinklas.eu/prekyba
Naudokite laisvą Linux operacinę sistemą savo kompiuteryje -
http://baltix.akl.lt
Use Baltix GNU/Linux OS !

Bug#952855: ITP: razercommander -- GTK contol center for managing Razer peripherals

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: razercommander
  Version : 1.2.1.1
  Upstream Author : Gabriele Musco 
* URL : https://github.com/GabMus/razerCommander
* License : GPL-3.0
  Programming Lang: Python-3
  Description : GTK contol center for managing Razer peripherals

 GTK control center for managing peripherals on Razer hardware.
 .
 Supported hardware:
 - Keyboards
 - Macro keypads (Tartarus, Orbweaver)
 - Mice
 - Laptops (keyboards only)
 - Headsets (possibly, untested)
 - Mousepads (Firefly)

There are many nearly-completed attempts to package this utility. This looks
like it should be quick and easy.

-- 
Michael Lustfield


pgpT2ELCAiWSj.pgp
Description: OpenPGP digital signature

Bug#950920: RFP: trimesh -- Trimesh is a Python library for loading and using triangular meshes with an emphasis on watertight surfaces

[Christoph Berg]

Control: retitle -1 ITP: trimesh -- Python triangular meshes with an emphasis 
on watertight surfaces
Control: owner -1 !
Control: tag -1 pending

Status: Waiting for https://github.com/mikedh/trimesh/issues/728

Christoph

Bug#952826: [www.debian.org] partners: convert svg graphics into png to make tidy happy

[Laura Arjona Reina]

Hi
The issue is due to a bug in wml which is solved in the buster package, so when 
we upgrade www-master.debian.org to buster, it will be fixed and we can use svg 
images without validation errors.

I'll try to review the possible blockers to the buster upgrade in the following 
days.

Kind regards

El 29 de febrero de 2020 23:33:51 CET, Holger Wansing  
escribió:
>Package: www.debian.org
>
>As tidy constantly complains about 
>
>*** /srv/www.debian.org/www/partners/2018/index.en.html
>line 159 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>line 255 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>*** /srv/www.debian.org/www/partners/2019/index.en.html
>line 75 column 3 - Warning:  attribute "width" has invalid value "height="
>line 159 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>line 255 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>*** /srv/www.debian.org/www/partners/2020/index.en.html
>line 75 column 3 - Warning:  attribute "width" has invalid value "height="
>line 159 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>line 255 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>*** /srv/www.debian.org/www/partners/index.en.html
>line 77 column 3 - Warning:  attribute "width" has invalid value "height="
>line 161 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>line 257 column 3 - Warning:  attribute "width" has invalid value 
>"height="
>
>which is all about width/height information in svg graphics:
>
>what about converting the relevant images (google.svg and 
>stackpack-logo-reversed.svg)
>into some other format, like png?
>
>Please excuse my ignorance, I have no detailed knowledge on vector graphics:
>maybe there is a reason why we should use svg there.
>However, png is widely used in the partners section...
>
>I have attached png variants of the relevant images.
>
>
>Holger
>

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#952826: [www.debian.org] partners: convert svg graphics into png to make tidy happy

[Holger Wansing]

Hi,

Carsten Schoenert  wrote:
> Hi,
> 
> Am 01.03.20 um 02:02 schrieb Ricardo:
> > Hello,
> > images in svg are the source. Would be better to store in svg format
> > and convert to png in build time. Are there only external companies
> > logos in repository, or are there some images that we may change in
> > the future? If we will not resize the images or change them in other
> > way, then I think it would be viable to convert and store them to png
> > format.
> 
> it's absolutely fine to use SVG graphics in recent days and if ever
> possible we should use them natively. The world is using more and more
> HTML5!
> The Debian websites due mostly heavily lack on a mobile friendly face.
> To get this working we will need graphics that scale smoothly and please
> no special hacks within the HTML source to solve various demands. SVG
> graphics are solving this specific need perfectly.
> 
> > If choose to convert them, as far as I know, we need to install a
> > software in the build container and it takes some time. Maybe there is
> > one container with the required software or the build process is made
> > in other way. Store only the svg would make thinks more organized and
> > easy to edit.
> 
> This turns more into a chicken egg problem in a longer view, or in my
> eyes, we should solve problems on the ride side or more correctly.
> Means, we need a strategy how the websites should evolve within the next
> five years for example.
> The Debian website is growing every day and by this the load and time to
> build the whole website is also growing constantly. At one day we need
> to think about this circumstance.
> 
> We currently using still DTD HTML 4.01 Strict for the websites and not
> something more up to date, but this has of course some reason.
> 
> [snip]
> > 2020-02-29 19:33 GMT-03:00, Holger Wansing :
> >> Package: www.debian.org
> >>
> >> As tidy constantly complains about
> >>
> >> *** /srv/www.debian.org/www/partners/2018/index.en.html
> >> line 159 column 3 - Warning:  attribute "width" has invalid value 
> >> "height="
> >> line 255 column 3 - Warning:  attribute "width" has invalid value 
> >> "height="
> 
> ...
> 
> >> which is all about width/height information in svg graphics:
> >>
> >> what about converting the relevant images (google.svg and
> >> stackpack-logo-reversed.svg)
> >> into some other format, like png?
> 
> This would be a workaround in my eyes instead of solving the root of the
> problem.
> 
> How can I run this tidy thing locally so I can try to narrow down the issue?
> 
> >> Please excuse my ignorance, I have no detailed knowledge on vector
> >> graphics:
> >> maybe there is a reason why we should use svg there.
> >> However, png is widely used in the partners section...
> 
> I'd like to see we do not convert SVG to PNG here because this is a step
> back in my eyes, especially as we need to take the advantage of getting
> all sites mobile ready one day and this shouldn't be done by graphics
> and logos with some other formats than SVG as this will always result in
> higher data rates to transfer.

In the long term, this sounds reasonable.
But currently there are 2 svg graphics, the other 29 are png.
So for now, the svgs could be moved in a subdir 'svg' to be accessible
for when the day comes.
And in the meantime we would at least be consistent on png - and tidy-happy.
(of course, fixing tidy would be the better way to go!)


Holger


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

Bug#952856: [live-build] manpage issues

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are various issues in the manpages to address
 - parent installer option not specifying that 'daily' is a possible
value
 - the list of component script descriptions is out of date
 - various typos
 - the mixing of primary (config,build,clean) and secondary build
component commands in the same list is confusing, they need separating
into two different lists.
 - acronyms need uppercasing
 - 'installer' missing in list of stages
 - 'build' config file missing in list of config files
 - obsolete ubuntu info
 - wrong description for --firmware-chroot
 - etc...

It's not worth it imo to create an individual bug report for each and
every issue here. I've got a patch set created or it all, and a single
bug number to reference should be more than sufficient.

patches to be submitted via salsa shortly

Bug#872615: policykit-1: There is no trace of the policyconfig.dtd?

[Laurent Bigonville]

On Sat, 19 Aug 2017 13:14:48 +0200 Guillem Jover  wrote:

> Hi!
>
> There's a proposal to add a pkexec action for update-alternatives.
> So when I went checking for the documentation of the file format, I
> noticed that the DTD is nowhere to be found?
>
> Without the DTD we cannot properly validate such entries. :)
>

FTR, https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/47

Bug#952857: [live-build] indentation issues

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

lots of indentation issues in the codebase, both in terms of spaces
instead of tabs and other forms of inconsistency.

i've a whole bunch of them (hopefully all of them) wrapped up i a
single commit to be submitted shortly. creating a single bug number to
reference...

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952858: [live-build] frontend help/usage fixme

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the 'lb' frontend has a fixme for its help/usage strings. 
 - `HELP` does not actually get used anywhere since the only place that
reads it - Help() - is never called.
 - `USAGE` does get called, for instance with `lb --usage`, where you
currently see "FIXME" appear. the top level commands applicable to this
usage string should at least specify the three top level commands and
thus be "lb {clean|config|build}"

alternatively we could consider something like "lb {clean|config|build}
[OPTIONS]", which is especially relevant to `lb config`, but "lb
{clean|config|build}" is at least a good start.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952860: [live-build] daily d-i is duplicated

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are two copies of the daily d-i URL in the code, which is not
ideal.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952861: [live-build] unnecessary string conversions of exit codes

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the codebase contains some unnecessary conversions of numeric exit
codes to strings.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952859: [live-build] Help() appears to be unused

[jnqnfe]

Package: live-build
Version: 1:20191221

Every script defines HELP which is made use of in Help(), but the lb
frontend redirects either to the manpage or Usage(), so Help() along
with all the HELP strings seems redundant and in need of removal.

Bug#952862: [live-build] source_iso performs append instead of replace

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

when writing to chroot/source.sh the source_iso script does so at one
point with an append write instead of replace.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952863: [live-build] missing shebangs

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

in multiple places of the scripts generating `.sh` files shebangs are
not written to those files.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952853: thunderbird: Account wizard fails to configure server settings using Mozilla's own autoconfig protocol, uses heuristic, fails

[Carsten Schoenert]

Control: tags -1 upstream

Hello Justus,

Am 01.03.20 um 11:27 schrieb Justus Winter:
> I'm trying to improve the account creation for a mail server setup of
> mine.  To this end, I setup and configured automx2 on the server, and
> now I'm trying to get Thunderbird to use it.  automx2 implements
> Mozilla's autoconfiguration protocol:
> 
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat
> 
> Sadly, Thunderbird's account creation wizard fails to use this
> information.

this all isn't a Debian packaging problem so I can't really help out here.

I can only suggest to report your problem against the Mozilla Bugzilla
bug tracking system and give back the URL of this report there to this
bug report here afterwards.

Thanks!

-- 
Regards
Carsten Schoenert

Bug#952864: [live-build] true|false are confusing values for --debian-installer

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the --debian-installer option accepts values of
true|cdrom|netinst|netboot|businesscard|live|false. Having 'true' and
'false' here is very confusing. the set of values needs replacing with
cdrom|netinst|netboot|businesscard|live|none.

note that `true` is being treated as an alias for `netinst`. in the new
set of values `none` would obviously be equivalent to the current
`false`.

a patch for this was previously submitted in a large patch set that was
never merged. I looked at it the other day to refresh my mind, though
do not recall the bug number and can't be bothered to dig it up, and I
remember a review comment specifically referring to my patch for this,
not liking the fact that the patch had no backwards compatibility. such
backwards compatibility has been reworked into this resubmission.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952865: [live-build] binary_disk refactor

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

the case block in binary_disk involves a lot of repetition and could do
with a refactor.

note, the patch to be submitted builds upon those for 952846 and
952864.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952866: [live-build] poor LB_MEMTEST=false handling

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the memtest option takes values of memtest86+|memtest86|none however
there are some parts of the codebase handling a value of "false",
presumably as an old backwards compatibility hack (I've not bothered to
go back in the history to find out why).

the way this value is handled is not ideal; it is done within
individual component scripts, whereas it should be handled within
Set_Defaults(), specifically by translating to "none".

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#905014: Bug#936391: Bug#905014: I'm adopting dhcpy6d

[Henri Wahl]

Hi,

I pushed to branch master on https://github.com/HenriWahl/dhcpy6d a
version which at least produced working .deb file. Might be still a
little bit rough but maybe it helps to get it running.

I renamed main.py to dhcpy6d.py by the way and copy it to
/usr/sbin/dhcpy6d as starter.

-- 
Henri Wahl

IT Department

Leibniz-Institut für Festkörper- und Werkstoffforschung Dresden e.V.
Helmholtzstr. 20, 01069 Dresden, Germany

tel: +49 (3 51) 46 59 - 797
email: h.w...@ifw-dresden.de
https://www.ifw-dresden.de

Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de

DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de

S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem
PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc




0xFAC1C12483E6CEC2.asc
Description: application/pgp-keys


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#952867: Please disable seccomp support on architecture where it's not supported (yet)

[Laurent Bigonville]

Source: flatpak
Version: 1.6.2-1
Severity: normal

Hello,

libseccomp is not available on all architectures but flatpak has an
inconditional build-dependency against it preventing it to build
everywhere.

Shouldn't flatpak package disable seccomp support on architectures where
it's not available?

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

[林上智]

Hi,

How did you reproduce this issue?
I cannot reproduce this issue on my side by using qemu+hppa, as shown below.

AFAICT, I don't think it's an endianness or 32/64 bit issue.

==


/usr/bin/make  check-TESTS
PASS: unit-tests.sh

Testsuite summary for libmodbus 3.1.6

# TOTAL: 1
# PASS:  1
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0

make[1]: Leaving directory '/build/libmodbus-3.1.6'
   create-stamp debian/debhelper-build-stamp
   dh_testroot -O--exclude=.la
   dh_prep -O--exclude=.la
   dh_auto_install -O--exclude=.la
make -j1 install DESTDIR=/build/libmodbus-3.1.6/debian/tmp
AM_UPDATE_INFO_DIR=no
make[1]: Entering directory '/build/libmodbus-3.1.6'
Making install in src
 /bin/mkdir -p '/build/libmodbus-3.1.6/debian/tmp/usr/lib/hppa-linux-gnu'


==

SZ

John David Anglin  於 2020年3月1日 週日 上午3:56寫道：
>
> On 2020-02-29 2:05 p.m., Martin wrote:
> > On 2020-02-29 09:42, John David Anglin wrote:
> >> Think the unit-test-server must die before it is looked for.
> > Too bad, it seems to be a different problem then.
> > Thanks for testing, John!
> I built package outside buildd.  Attached are log files.
>
> --
>
> John David Anglin  dave.ang...@bell.net
>

Bug#952868: OpenSSL linking without license exception

[Bastian Germann]

Package: wesnoth
Severity: serious

This GPL2 package links with OpenSSL. The OpenSSL license is
incompatible with the GPL (see
https://ftp-master.debian.org/REJECT-FAQ.html). This can be solved by
asking upstream to add a license exception or by linking with wolfSSL
instead. You can find a patch enclosed (untested).
From f15f10434ef5fbdc9cf2eeea15e7ca057c0f6e63 Mon Sep 17 00:00:00 2001
From: Bastian Germann 
Date: Sun, 1 Mar 2020 11:19:53 +0100
Subject: [PATCH] Replace OpenSSL with wolfSSL

---
 debian/control  |  2 +-
 debian/patches/01wolfssl-crypto | 14 ++
 debian/patches/series   |  1 +
 debian/rules|  2 +-
 4 files changed, 17 insertions(+), 2 deletions(-)
 create mode 100644 debian/patches/01wolfssl-crypto

diff --git a/debian/control b/debian/control
index 5e35ef9b..1d650a07 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Build-Depends: debhelper (>= 11~), libsdl2-image-dev (>= 2.0.0),
   libboost-iostreams-dev, libboost-test-dev, libboost-regex-dev,
   libboost-serialization-dev, libboost-system-dev, libboost-thread-dev,
   libboost-program-options-dev, libboost-filesystem-dev, libboost-locale-dev,
-  libboost-random-dev, libpng-dev, libreadline-dev, libssl-dev,
+  libboost-random-dev, libpng-dev, libreadline-dev, libwolfssl-dev,
   libpango1.0-dev, libvorbis-dev, cmake (>= 2.6)
 Standards-Version: 4.1.4
 Uploaders: Rhonda D'Vine ,
diff --git a/debian/patches/01wolfssl-crypto b/debian/patches/01wolfssl-crypto
new file mode 100644
index ..ad55d158
--- /dev/null
+++ b/debian/patches/01wolfssl-crypto
@@ -0,0 +1,14 @@
+Author: Bastian Germann   vim:ft=diff:
+Description: Link with wolfssl instead of libcrypto.
+
+--- a/cmake/FindCrypto.cmake
 b/cmake/FindCrypto.cmake
+@@ -2,7 +2,7 @@
+ 
+ find_path(CRYPTO_INCLUDE_DIR openssl/md5.h)
+ 
+-find_library(CRYPTO_LIBRARY crypto)
++find_library(CRYPTO_LIBRARY wolfssl)
+ 
+ # handle the QUIETLY and REQUIRED arguments and set XXX_FOUND to TRUE if all listed variables are TRUE
+ INCLUDE(FindPackageHandleStandardArgs)
diff --git a/debian/patches/series b/debian/patches/series
index 57b6465e..8014e9fd 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
+01wolfssl-crypto
 02wesnoth-nolog-desktop-file
 03wesnothd-name
diff --git a/debian/rules b/debian/rules
index 02ad4071..cbec12c1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -23,7 +23,7 @@ ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
 CXXFLAGSDBG = -g1
 endif
 
-export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS)
+export CPPFLAGS := $(shell dpkg-buildflags --get CPPFLAGS) -I/usr/include/wolfssl -DOPENSSL_ALL
 export CFLAGS   := $(shell dpkg-buildflags --get CFLAGS) $(CPPFLAGS) -std=c++11 -fopenmp
 export CXXFLAGS := $(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS) -std=c++11 -fopenmp  $(CXXFLAGSDBG)
 export LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
-- 
2.25.1

Bug#952869: synthv1 FTCBFS: hard codes the build architecture strip

[Helmut Grohne]

Source: synthv1
Version: 0.9.12-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

synthv1 fails to cross build from source, because two of the embedded
qmake project files hard code the build architecture strip instead of
using QMAKE_STRIP. The attached patch fixes that. Please consider
applying it.

In general, I'd recommend against such stripping during a Debian package
build as that tends to also break DEB_BUILD_OPTIONS=nostrip and
generation of -dbgsym packages.

Helmut
--- synthv1-0.9.12.orig/src/src_jack.pro
+++ synthv1-0.9.12/src/src_jack.pro
@@ -79,7 +79,7 @@
 	mimetypes_scalable.path = $${DATADIR}/icons/hicolor/scalable/mimetypes
 	mimetypes_scalable.files += mimetypes/application-x-$${NAME}-preset.svg
 
-	CONFIG(release, debug|release):QMAKE_POST_LINK += strip -v $(TARGET)
+	CONFIG(release, debug|release):QMAKE_POST_LINK += $${QMAKE_STRIP} -v $(TARGET)
 }
 
 QT += widgets xml
--- synthv1-0.9.12.orig/src/src_lv2.pro
+++ synthv1-0.9.12/src/src_lv2.pro
@@ -66,7 +66,7 @@
 		$${TARGET_LV2UI}.ttl \
 		$${NAME}.lv2/manifest.ttl
 
-	CONFIG(release, debug|release)::QMAKE_POST_LINK += strip -v $(TARGET);
+	CONFIG(release, debug|release)::QMAKE_POST_LINK += $${QMAKE_STRIP} -v $(TARGET);
 	QMAKE_POST_LINK += $${QMAKE_COPY} -vp $(TARGET) $${TARGET_LV2}.so
 
 	QMAKE_CLEAN += $${TARGET_LV2}.so

Bug#952870: radicale: Since 2.1.11-8 radicale cannot be started by non-root

[Itaï BEN YAACOV]

Package: radicale
Version: 2.1.11-8
Severity: important

Dear Maintainer,

Changes to the logging configuration in 2.1.11-8 make it impossible to start
by an ordinary user, who cannot write to /var/log/radicale (and probably
does not want to, either).

Cheers,
Itaï.


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

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

Versions of packages radicale depends on:
ii  adduser  3.118
ii  init-system-helpers  1.57
ii  lsb-base 11.1.0
ii  python3  3.7.5-3
ii  python3-radicale 2.1.11-7

Versions of packages radicale recommends:
ii  ssl-cert  1.0.39

Versions of packages radicale suggests:
pn  apache2 
pn  apache2-utils   
pn  libapache2-mod-proxy-uwsgi  
ii  python3-bcrypt  3.1.7-2
ii  python3-passlib 1.7.2-1
pn  uwsgi   
pn  uwsgi-plugin-python3

-- no debconf information

Bug#822726: dclock: blink/seconds issues

[Ricardo Mones]

control: tags -1 moreinfo

Hi J meritt,

On Thu, May 05, 2016 at 12:49:22AM -0400, J meritt wrote:
> Attached are patches for the changes described below.

Not sure which version of the code you used to generate it but
unfortunately the patches doesn't apply to current upstream branch¹
neither to master branch in package's git repo. Can you provide a
working patch against any of these branches? Preferably in unified
format, separated by the bug fixed on each patch.

> Features added:

Can you provide these as a separate per-feature patches? Mixing features
with fixes makes it harder to track problems if they arise.

Thanks in advance and best regards,

¹ https://salsa.debian.org/debian/dclock/-/tree/upstream
-- 
  Ricardo Mones 
  ~
  Never send a human to do a machine's job.   Agent Smith


signature.asc
Description: PGP signature

Bug#941900: version 3.3.0 builds

[Russell Coker]

I've attached the Debian file for a 3.3.0 build.  It's a little rough and you
might want to make some changes before putting it in Debian, but it compiles
and works for a basic game.


warzone2100_3.3.0-0.debian.tar.xz
Description: application/xz

Bug#952872: Please fix FTBFS on hurd-i386

[Laurent Bigonville]

Source: packagekit
Version: 1.1.11-1
Severity: important
Tags: patch ftbfs
Justification: fails to build from source

Hello,

It would be nice to fix the FTBFS on hurd-i386

The attached patch should fix this (not-tested)

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru packagekit-1.1.13/debian/rules packagekit-1.1.13/debian/rules
--- packagekit-1.1.13/debian/rules  2020-01-08 21:58:22.0 +0100
+++ packagekit-1.1.13/debian/rules  2020-03-01 14:38:59.0 +0100
@@ -29,8 +29,8 @@
dh $@ --with gir
 
 extrainstallfiles-stamp:
-   grep -E -v 
'lib/systemd|pk-offline-update|pk-trigger-offline-update|pk-clear-offline-update'
 debian/packagekit.install > debian/packagekit.install.kfreebsd
-   grep -E -v 
'lib/systemd|pk-offline-update|pk-trigger-offline-update|pk-clear-offline-update'
 debian/packagekit.install > debian/packagekit.install.hurd
+   grep -E -v 'lib/systemd|pk-offline-update|pk-debconf-helper' 
debian/packagekit.install > debian/packagekit.install.kfreebsd
+   grep -E -v 'lib/systemd|pk-offline-update|pk-debconf-helper' 
debian/packagekit.install > debian/packagekit.install.hurd
touch $@
 
 override_dh_auto_configure:

Bug#952867: Please disable seccomp support on architecture where it's not supported (yet)

[Simon McVittie]

On Sun, 01 Mar 2020 at 13:13:30 +0100, Laurent Bigonville wrote:
> libseccomp is not available on all architectures but flatpak has an
> inconditional build-dependency against it preventing it to build
> everywhere.
> 
> Shouldn't flatpak package disable seccomp support on architectures where
> it's not available?

IMO no. Flatpak relies on seccomp to provide its intended security model,
and if porters want Flatpak on architectures that currently lack seccomp,
the right way to go about it is to provide seccomp, not to provide an
insecure version of Flatpak.

smcv

Bug#877419: pandas: some I/O tests (hdf5, Stata) fail on non-x86

[Rebecca N. Palmer]

Re-enabling these tests found that this bug (which is probably actually 
multiple bugs) _does_ still exist, on big-endian systems and _possibly_ 
others.


pandas now (0.25.3+dfsg-7) warns the user when these are used on any 
non-x86 system.


** Stata format

- All big-endian (s390x, hppa, ppc64): 
tests/io/test_stata.py::TestStata::test_read_dta18, test_writer_117, 
test_convert_strl_name_swap, test_unicode_dta_118, test_strl_latin1 
fail.  Suggests a problem involving Unicode strings.


- ppc64el: Succeeds on the buildd, but 34 tests (mostly but not only 
involving nan/inf) fail in local qemu-ppc64el.


** HDF(5) format

- All big-endian: 
tests/io/pytables/test_pytables.py::TestHDFStore::test_legacy_table_fixed_format_read_py2, 
test_read_py2_hdf_file_in_py3, test_legacy_datetimetz_object fail. 
Suggests an issue with reading older files, possibly the same pytables 
bug (which doesn't appear to have a number) as 
https://sources.debian.org/src/pytables/3.6.1-2/debian/patches/0005-Skip-index-backcompat-tests-on-bingendian.patch/


- s390x + ppc64 but not hppa: test_flush fails.

- All big-endian: test_encoding is skipped (by upstream).

(armhf may _crash_ - see #790925 - but is not known to give wrong results.)

** Clipboard

- tests/io/test_clipboard.py::test_raw_roundtrip failed in 0.25.3+dfsg-5 
on s390x, but passed in -6 and -7 with no obvious fix in pandas. 
Possibly a bug outside pandas that has now been fixed.

Bug#935923: libmodbus: FTBFS on hppa - unit-test-server: no process found

[John David Anglin]

On 2020-03-01 7:13 a.m., SZ Lin (林上智) wrote:
> Hi,
>
> How did you reproduce this issue?
> I cannot reproduce this issue on my side by using qemu+hppa, as shown below.
It was on a 4-way rp3440.  Most hppa buildds run on PA 2.0 machines with 64-bit 
kernels.
I believe qemu only supports 32-bit PA 1.1 kernels.

I think Helge Deller would be interested in this since we appear to have 
different application
behavior with different kernels.

There is a porter box available for testing.
https://db.debian.org/machines.cgi?host=panama

It's a UP machine however.

Dave

-- 
John David Anglin  dave.ang...@bell.net

Bug#937009: mercurial: Python2 removal in sid/bullseye

[Andrej Shadura]

On Tue, 18 Feb 2020 18:31:50 +0100 Julien Cristau 
wrote:
> On Thu, Oct 31, 2019 at 02:25:22PM +0100, Matthias Klose wrote:
> > Julian, you added the py2keep tag. Reading the upstream mail for the 5.2
> > release, it looks like the release will happen next month.  So why keeping
> > it as Python2 version for the bullseye release?
> 
> Before switching in sid I'd want to:
> - be able to use the python3 version myself
> - give extensions some time to figure out their own switch
> - ideally not regress significant functionality; e.g. python-subversion
>   is still not available for python3
> 
> I don't know what that means in terms of timeframe, it may or may not
> happen in time for bullseye, but I'm also not in a rush and I'd rather
> not break stuff by switching too early.

I would be great if you could ship Mercurial as dual Python 2 + Python 3
package but with /usr/bin/hg being Python 2, so that users can try the
Python 3 version and extensions can be used with either. As it is now,
it’s not possible e.g. to ship TortoiseHg at all since it needs core
Mercurial modules in Python 3 (since Python 2 dependencies it might use
have already been removed).

-- 
Cheers,
  Andrej

Bug#952873: [live-build] *_archives have wrong comment placement ...

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

...for 'configure custom sources.list'

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952874: [live-build] error split into two that should not be so

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

...for consistency, no other errors are split like it.

specifically referring to the 'ntfs' related one in defaults.sh.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952875: [live-build] inconsistent capitalisation for start of messages

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

as titled; several instances of this

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952877: [live-build] unnecessary use of echo helpers in help/usage

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

the Help() and Usage() functions make unnecessary use of echo helpers
which makes them much messier than they need to be.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952878: [live-build] error printing problem

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the error echo printing helper explicitly sends the main part of the
message to stderr, but prints the 'E:' prefix normally meaning that in
some use cases things go wrong such as the prefix not appearing.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952876: [live-build] failure to use echo helpers

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there are some places where the echo helpers are not being used when
they should be.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952879: [live-build] lack of robustness in echo helper output

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the echo helpers almost entirely do not explicitly direct their output
to stdout/stderr, and failing to do so means that in some use cases
(specifically use in functions whose purpose is to return a string (by
echoing it)) things go wrong with log messages (after all these after
effectively all logging functions) not making it to the console as they
should.

this could perhaps have been merged with #952878 which is specifically
about the error echo helper sending part of its output to stderr but
not all...

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#946152: iptables-dev vs libiptc-dev dependency in collectd

[Antonio Russo]

I'm trying to address the changes in the iptables package for collectd.

I can avoid the dependency on the transitional iptables-dev package (see [1]), 
but I'm confused by the
statement:

> The src:iptables debian package (v1.8.4-1) dropped the libiptc-dev and 
> libiptc0 binary packages.

I see that libiptc0 is a transitional dummy package, but libiptc-dev is not 
indicated to be obsolete, and
in fact contains the pkg-config file

/usr/lib/x86_64-linux-gnu/pkgconfig/libiptc.pc

Is there another package that collectd should build-depend on for this file? 
(I.e., have I incorrectly
merged 946152 and 951088?) Or is the removal of the dependency on libiptc0 (by 
rebuilding) sufficient to
address your original bug report?

Thanks,
Antonio Russo

[1] https://salsa.debian.org/debian/pkg-collectd/-/merge_requests/2

Bug#952880: [live-build] some of the echo helpers are redundant

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

some of the echo helpers are completely unused and should be removed.
specifically:
 - Echo_status
 - Echo_done
 - Echo_debug_running
 - Echo_message_running
 - Echo_verbose_running

a couple of those functions are furthermore the only users of a couple
of the functions in cursors.sh, with all of the remaining cursor
functions being entirely unused, so this means that with the above echo
helpers gone, we can also entirely remove cursors.sh.

patches to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952881: [live-build] binary_iso using wrong echo helper

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

Echo_message() should be used instead of Echo() for "No EFI boot code
to include in the ISO".

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952882: [live-build] binary_onie lacks use of echo helpers

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

as titled.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952883: [live-build] binarie_onie lacks newline before errors

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

binary_onie takes the unusual (with respect to all other scripts) step
of outputting a series of dots as it progresses through various parts
of its script. these dots are all printed on the same line and finally
are terminated with 'done'. the problem is that if an error occurs, the
error should no doubt be placed upon a new line but is not.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952884: [live-build] wrong command in help/usage output

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

functions/common.sh holds a variable PROGRAM set to "live-build" which
is used in places where both "live-build" AND "lb" should appear.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952885: [live-build] redundant usage line

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

...in chroot_install-packages

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952888: nm.debian.org: Don't accept mails for NM mailboxes a while after processes are closed

[Judit Foglszinger]

Package: nm.debian.org
Severity: wishlist

Since at one point spammers start to target mailboxes,
it might make sense to not accept more emails a while after a
process has been closed, maybe one or two months.

comment from enrico:

"The mail processing script isn't very smart unfortunately at the moment, to 
avoid bringing up django every time a mail arrives, although it could 
just enqueue the mails, and the ping django for actually injecting them"


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

Bug#952887: [live-build] overly complex script description handling

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

every single script (those under scripts/build/) uses a subcmd to
inject a newline to the end of DESCRIPTION string which is used by
Help() or Usage() if called.

this is rediculous; the scripts can just hold a plain simple string
with these two functions outputting the wanted newline.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952886: mini-transition: okular

[Pino Toscano]

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

Hi,

this is a very small transition: the new version of okular bumps the
SONAME of the okular core library, and the only user of it is calligra.

calligra builds fine with the newer okular core library, and at the
moment it does not seem involved in other transitions.

Ben file:

title = "okular";
is_affected = .depends ~ "libokular5core8" | .depends ~ "libokular5core9";
is_good = .depends ~ "libokular5core9";
is_bad = .depends ~ "libokular5core8";

Thanks,
-- 
Pino

Bug#952889: [live-build] sources.list generation code duplication

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

there is a significant chunk of code for generating an apt sources.list
file that is duplicated in three different places in the codebase. in
two cases it is identical, in the third it only differs in the
variables used for mirrors and such.

this can very easily be extracted to a common function and would be a
notable improvement in terms of maintainability.

specifically bootstrap_archives holds one copy and chroot_archives the
other two.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952890: [live-build] bootloaders ignore LB_DEBIAN_INSTALLER_GUI

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com

the graphical installer is only bundled if LB_DEBIAN_INSTALLER_GUI
permits it, however the bootloaders ay no attention to this and the
corresponding menu entries end up in the image anyway which will
obviously be non-functional.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#948844: debmake: option for git maintained packages

[Osamu Aoki]

Hi

On Sat, Feb 29, 2020 at 09:43:55AM -0700, Sean Whitton wrote:
> Hello Matt,
>
> On Sat 25 Jan 2020 at 04:06PM -08, Matt Taggart wrote:
>
> > I am following the the "When upstream tags releases in git" section of
> > dgit-maint-merge(7) and when I get to the "Now go ahead and
> > Debianise..." section I'd like to be able to run debmake, but it's
> > expecting the source dir to have a particular name and the orig tarball
> > to exist.
>
> Ah, okay.  It seems that the problem with debmake you identify here is
> not specific to dgit-maint-merge(7), as most any git-based workflow will
> not have the source dir include the version number, and many of them
> won't have the orig.tar exist yet.
>
> >> s/debhelper/debmake/ right?
> >
> > Yes, sorry.
> >>> 1) don't create debian/patches/
> >>>
> >>> 2) don't create debian/source/local-options
> >>>
> >>> 3) I'm not sure if watch is needed
> >>>
> >>> 4) create debian/source/options containing:
> >>> single-debian-patch
> >>> auto-commit
> >>>
> >>> 5) create debian/source/patch-header with a description of how to get
> >>> changes to the upstream source. I guess this should be a template that
> >>> fills in package name and git repo?
> >>>
> >>> For #3 and #4 see the dgit-maint-merge(7) manpage for examples and
> >>> explanation.
> >>
> >> I think that debmake might not be the right place for (2), (4) and (5).
> >> Instead, I think a 'maintmerge' script in the dgit package should do
> >> that setup, so that non-debmake users can take advantage.  See #852226.
> >
> > debmake is already creating a template for (2).
> > I like the idea of putting these steps in a dgit script though and
> > having the dgit-maint-merge(7) manpage explain how to use it. Then maybe
> > debmake could add a basic mode to handle the other remaining things.
>
> I agree.

Please propose patch :-)

I want debmake to work smoothly with dgit work flow.
I really wish debmake to become really thin glue code.
Another action plan is replace license check code woth external utility

Osamu

Bug#952892: [live-build] rename --architectures to --architecture

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: minor

--architectures only takes a single architecture, so should be renamed
to no longer be plural to avoid user confusion.

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952891: [live-build] start-stop-daemon dpkg hack can be simplified with ln

[jnqnfe]

Package: live-build
Version: 1:20191221
Owner: jnq...@gmail.com
Severity: wishlist

...in the same way as for flash-kernel

patch to be submitted via salsa shortly (will amend commit with bug
number first)

Bug#952888: nm.debian.org: Don't accept mails for NM mailboxes a while after processes are closed

[Mattia Rizzolo]

On Sun, Mar 01, 2020 at 08:37:43PM +0600, Judit Foglszinger wrote:
> "The mail processing script isn't very smart unfortunately at the moment, to 
> avoid bringing up django every time a mail arrives, although it could 
> just enqueue the mails, and the ping django for actually injecting them"

That might be true, but doing that would prevent you from rejecting the
mails at smtp time, as doing so later could cause backscatter.

I think it's valuable to send a rejection message to people trying to
save a mail to an archived mailbox.

Would loading django be so expensive considering our relatively small
mail traffic?


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#951961: androguard: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p "3.8 3.7" returned exit code 13

[Diego M. Rodriguez]

Hi,

> > Failure: ModuleNotFoundError (No module named 'asn1crypto') ... ERROR
> > ...

I have attempted a fix as merge requests in salsa [1], as it seems to
be a dependencies issue.

[1] https://salsa.debian.org/python-team/modules/androguard/-/merge_requests/2

Best,
-- 
Diego M. Rodriguez



signature.asc
Description: OpenPGP digital signature

Bug#952655: debian-ports-archive-keyring: Expired Debian Ports Archive Automatic Signing Key (2020)

[Przemysław Buczkowski]

Thanks for your help!

The problem (much smaller) is that installing manually version 
2019.11.05 did not help on its own. I had to run wget -qO- 
https://www.ports.debian.org/archive_2020.key | apt-key -


Just thought I should let you know.

Best,
Prem

On 26/02/2020 22:06, Aurelien Jarno wrote:

control: found -1 2018.12.27
control: notfound -1 2019.11.05
control: fixed -1 2019.11.05

On 2020-02-26 22:33, Przemyslaw Buczkowski wrote:

Package: debian-ports-archive-keyring
Version: 2019.11.05
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Debian Ports Archive Automatic Signing Key (2020) seems to have expired on the 
31st of January,


This is correct there was an issue with this key, its expiration date
was off by one year in version 2018.12.27 of the package. This has
already been fixed in version 2019.11.05 of the package, the expiration
date has been extended by one year.


according to 
http://gozer.rediris.es:11371/pks/lookup?search=0x84C573CD4E1AFD6C&op=vindex


This is clearly out of date. OTOH most keyservers stopped propagating
keys due to all the issue with the protocol, so it's kind of expected.

Alternatively the key can be downloaded from there:
https://www.ports.debian.org/archive_2020.key

Regards,
Aurelien

Bug#929841: systemd-udevd: regulatory.0: Process '/sbin/crda' failed with exit code 255.

[Thorsten Glaser]

retitle 929841 systemd-udevd: regulatory.0: Process '/sbin/crda' failed with 
exit code 255.
thanks

Could this have to do with /lib/udev/rules.d/85-regulatory.rules ?

A quick search through the code shows it returns “-1” (i.e. 255) in
multiple places (the main function is written like kernel code, not
userspace…), and is called from two files in /lib/udev/rules.d/, one
indirectly via iw reg set (which we already established works for me)
and once directly via the aforementioned file.

That file contains this comment…

# For more information see:
# http://wireless.kernel.org/en/developers/Regulatory/CRDA

… but that URL is dead, but the Internet Archive has it under:
http://web.archive.org/web/20190825055504/https://wireless.wiki.kernel.org/en/developers/Regulatory/CRDA

Interestingly enough, the 85-regulatory.rules does not set $COUNTRY,
and calling crda without it set does result in exitting with -1.

Unfortunately, none of the printfs found in crda make it into syslog.

Retitling the bug so the actual issue, not a red herring, is used as title.

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

Bug#929405: ITP: pveclib -- power vector library

[Gabriel F. T. Gomes]

Sean Whitton, from FTP Master, reviewed the package and pointed out
that the file CODE_OF_CONDUCT.md is probably not suitable for
distribution in the main section.  I agreed and repackaged the project,
as can be seen in:

https://salsa.debian.org/debian/pveclib/-/commits/master
(look for dfsg)

However, I did not upload it to the NEW queue yet, because there is a
problem with the compiler, which causes pveclib to fail to build.  This
has been reported to GCC and fixed [1], but it still needs some time to
land at Debian Unstable.  When that happens, I'll submit the new
package.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93987

Cheers,
Gabriel

Bug#952893: pycollada: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: pycollada
Version: 0.6-1
Severity: serious
Justification: out-of-sync unstable-to-testing
X-Debbugs-CC: kkremit...@gmail.com kurt@kwk.systems ti...@debian.org

Dear package pycollada maintainers,

The latest upload of your package was not a source-only upload. As a result,
it did not migrate to Testing.

According to
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
packages that are out-of-sync between testing and unstable for more than 60
days are considered as having a Release Critical bug. Your package has been
out-of-sync for 140 days.

Please consider making another source-only upload to allow testing migration
according to https://wiki.debian.org/SourceOnlyUpload . Let me know if you
need any help. Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#952894: cups: Bad Request for FQDN without explicit ServerAlias

[Kevin Locke]

Package: cups
Version: 2.3.1-7
Severity: normal

Dear Maintainer,

Accessing CUPS via https://hostname:631 works while
https://hostname.example.com:631 fails with 400 Bad Request if
cupsd.conf does not contain either "HostNameLookups on" or
"ServerAlias printserver.example.com".  This is a divergence from
upstream, where the FQDN returned by gethostname(2) is automatically
added as a ServerAlias.

It appears to be an untended side-effect of
0026-Do-not-use-host-names-for-broadcasting-print-queues-.patch for
LP#449586.  Perhaps we could consider a different way to disable name
broadcasting without removing the ServerAlias for the FQDN which is used
for HTTP host checking?

Thanks,
Kevin

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

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

Versions of packages cups depends on:
ii  cups-client2.3.1-7
ii  cups-common2.3.1-7
ii  cups-core-drivers  2.3.1-7
ii  cups-daemon2.3.1-7
ii  cups-filters   1.27.1-1
ii  cups-ppdc  2.3.1-7
ii  cups-server-common 2.3.1-7
ii  debconf [debconf-2.0]  1.5.73
ii  ghostscript9.50~dfsg-5
ii  libavahi-client3   0.7-5
ii  libavahi-common3   0.7-5
ii  libc6  2.29-10
ii  libcups2   2.3.1-7
ii  libgcc-s1  10-20200222-1
ii  libstdc++6 10-20200222-1
ii  libusb-1.0-0   2:1.0.23-2
ii  poppler-utils  0.71.0-6
ii  procps 2:3.3.15-2+b1

Versions of packages cups recommends:
pn  avahi-daemon  
pn  colord

Versions of packages cups suggests:
pn  cups-bsd   
pn  cups-pdf   
ii  foomatic-db-compressed-ppds [foomatic-db]  20191126-1
ii  smbclient  2:4.11.5+dfsg-1
ii  udev   244.3-1

-- debconf information excluded

Bug#952871: itstool: Segmentation Fault when Merging French Translation

[François Mazen]

Additional information: 

I can't reproduce within buster/stable release, using 2.0.5-2 package
version.
Hence it may be a regression introduced by the 2.0.6-1 version.

Thanks,
François

Bug#952895: php7.3-fpm: Can't install/upgrade on system with elogind (forced init switch)

[Lorenzo Puliti]

Package: php7.3-fpm
Version: 7.3.15-4
Severity: normal
Tags: patch

Dear Maintainer,

with commit ccbb813a4268e79c8bb2ef24f468eec23b53e73a is no longer possible
to install php7.3-fmp package with alternative inits when elogind is installed.
For example for me it forces removal of elogind and switch to systemd (from 
runit-init):

# apt-get install php7.3-fpm
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  daemon libapache2-mod-php7.3 libnss-systemd libpam-systemd libsystemd0 
php7.3-cgi php7.3-cli php7.3-common
  php7.3-curl php7.3-gd php7.3-intl php7.3-json php7.3-mbstring php7.3-mysql 
php7.3-opcache php7.3-readline
  php7.3-soap php7.3-sqlite3 php7.3-xml php7.3-xmlrpc systemd systemd-sysv
Suggested packages:
  php-pear systemd-container
The following packages will be REMOVED:
  elogind elogind-run libelogind-dev libelogind0 libpam-elogind 
libpam-elogind-compat runit-init
The following NEW packages will be installed:
  daemon libnss-systemd libpam-systemd libsystemd0 systemd systemd-sysv
The following packages will be upgraded:
  libapache2-mod-php7.3 php7.3-cgi php7.3-cli php7.3-common php7.3-curl 
php7.3-fpm php7.3-gd php7.3-intl
  php7.3-json php7.3-mbstring php7.3-mysql php7.3-opcache php7.3-readline 
php7.3-soap php7.3-sqlite3 php7.3-xml
  php7.3-xmlrpc
17 upgraded, 6 newly installed, 7 to remove and 22 not upgraded.
Need to get 12.6 MB of archives.
After this operation, 13.0 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

Please consider to add support for alternative inits using opentmpfiles.
Note also that opentmpfiles will work on non-linux ports so this patch 
will probably help with #951803 too.
Patch is attached, I can make a MR on salsa if you prefer

Best Regards,
Lorenzo

-- Package-specific info:
 Additional PHP 7.3 information 

 PHP 7.3 SAPI (php7.3query -S): 

 PHP 7.3 Extensions (php7.3query -M -v): 

 Configuration files: 
[PHP]
engine = On
short_open_tag = Off
precision = 14
output_buffering = 4096
zlib.output_compression = Off
implicit_flush = Off
unserialize_callback_func =
serialize_precision = -1
disable_functions = 
pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,
disable_classes =
zend.enable_gc = On
expose_php = Off
max_execution_time = 30
max_input_time = 60
memory_limit = 128M
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off
display_startup_errors = Off
log_errors = On
log_errors_max_len = 1024
ignore_repeated_errors = Off
ignore_repeated_source = Off
report_memleaks = On
html_errors = On
variables_order = "GPCS"
request_order = "GP"
register_argc_argv = Off
auto_globals_jit = On
post_max_size = 8M
auto_prepend_file =
auto_append_file =
default_mimetype = "text/html"
default_charset = "UTF-8"
doc_root =
user_dir =
enable_dl = Off
file_uploads = On
upload_max_filesize = 2M
max_file_uploads = 20
allow_url_fopen = On
allow_url_include = Off
default_socket_timeout = 60
[CLI Server]
cli_server.color = On
[Date]
[filter]
[iconv]
[imap]
[intl]
[sqlite3]
[Pcre]
[Pdo]
[Pdo_mysql]
pdo_mysql.default_socket=
[Phar]
[mail function]
SMTP = localhost
smtp_port = 25
mail.add_x_header = Off
[ODBC]
odbc.allow_persistent = On
odbc.check_persistent = On
odbc.max_persistent = -1
odbc.max_links = -1
odbc.defaultlrl = 4096
odbc.defaultbinmode = 1
[Interbase]
ibase.allow_persistent = 1
ibase.max_persistent = -1
ibase.max_links = -1
ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
ibase.dateformat = "%Y-%m-%d"
ibase.timeformat = "%H:%M:%S"
[MySQLi]
mysqli.max_persistent = -1
mysqli.allow_persistent = On
mysqli.max_links = -1
mysqli.default_port = 3306
mysqli.default_socket =
mysqli.default_host =
mysqli.default_user =
mysqli.default_pw =
mysqli.reconnect = Off
[mysqlnd]
mysqlnd.collect_statistics = On
mysqlnd.collect_memory_statistics = Off
[OCI8]
[PostgreSQL]
pgsql.allow_persistent = On
pgsql.auto_reset_persistent = Off
pgsql.max_persistent = -1
pgsql.max_links = -1
pgsql.ignore_notice = 0
pgsql.log_notice = 0
[bcmath]
bcmath.scale = 0
[browscap]
[Session]
session.save_handler = files
session.use_strict_mode = 0
session.use_cookies = 1
session.use_only_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.cookie_httponly =
session.cookie_samesite =
session.serialize_handler = php
session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440
session.referer_check =
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 0
session.sid_length = 26
session.t

Bug#952895: php7.3-fpm: Can't install/upgrade on system with elogind (forced init switch)

[Ondřej Surý]

Control: severity -1 wishlist

Hi Lorenzo,

not until opentmpfiles provides unified interface. I am not adding more shell 
spaghetti anywhere if I can help it.

systemd does not enforce systemd-sysv package installation. Use 
--no-install-recommends with apt.

Ondrej.
--
Ondřej Surý 

> On 1 Mar 2020, at 16:51, Lorenzo Puliti  wrote:
> 
> Package: php7.3-fpm
> Version: 7.3.15-4
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> with commit ccbb813a4268e79c8bb2ef24f468eec23b53e73a is no longer possible
> to install php7.3-fmp package with alternative inits when elogind is 
> installed.
> For example for me it forces removal of elogind and switch to systemd (from 
> runit-init):
> 
> # apt-get install php7.3-fpm
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following additional packages will be installed:
>  daemon libapache2-mod-php7.3 libnss-systemd libpam-systemd libsystemd0 
> php7.3-cgi php7.3-cli php7.3-common
>  php7.3-curl php7.3-gd php7.3-intl php7.3-json php7.3-mbstring php7.3-mysql 
> php7.3-opcache php7.3-readline
>  php7.3-soap php7.3-sqlite3 php7.3-xml php7.3-xmlrpc systemd systemd-sysv
> Suggested packages:
>  php-pear systemd-container
> The following packages will be REMOVED:
>  elogind elogind-run libelogind-dev libelogind0 libpam-elogind 
> libpam-elogind-compat runit-init
> The following NEW packages will be installed:
>  daemon libnss-systemd libpam-systemd libsystemd0 systemd systemd-sysv
> The following packages will be upgraded:
>  libapache2-mod-php7.3 php7.3-cgi php7.3-cli php7.3-common php7.3-curl 
> php7.3-fpm php7.3-gd php7.3-intl
>  php7.3-json php7.3-mbstring php7.3-mysql php7.3-opcache php7.3-readline 
> php7.3-soap php7.3-sqlite3 php7.3-xml
>  php7.3-xmlrpc
> 17 upgraded, 6 newly installed, 7 to remove and 22 not upgraded.
> Need to get 12.6 MB of archives.
> After this operation, 13.0 MB of additional disk space will be used.
> Do you want to continue? [Y/n] 
> 
> Please consider to add support for alternative inits using opentmpfiles.
> Note also that opentmpfiles will work on non-linux ports so this patch 
> will probably help with #951803 too.
> Patch is attached, I can make a MR on salsa if you prefer
> 
> Best Regards,
> Lorenzo
> 
> -- Package-specific info:
>  Additional PHP 7.3 information 
> 
>  PHP 7.3 SAPI (php7.3query -S): 
> 
>  PHP 7.3 Extensions (php7.3query -M -v): 
> 
>  Configuration files: 
> [PHP]
> engine = On
> short_open_tag = Off
> precision = 14
> output_buffering = 4096
> zlib.output_compression = Off
> implicit_flush = Off
> unserialize_callback_func =
> serialize_precision = -1
> disable_functions = 
> pcntl_alarm,pcntl_fork,pcntl_waitpid,pcntl_wait,pcntl_wifexited,pcntl_wifstopped,pcntl_wifsignaled,pcntl_wifcontinued,pcntl_wexitstatus,pcntl_wtermsig,pcntl_wstopsig,pcntl_signal,pcntl_signal_get_handler,pcntl_signal_dispatch,pcntl_get_last_error,pcntl_strerror,pcntl_sigprocmask,pcntl_sigwaitinfo,pcntl_sigtimedwait,pcntl_exec,pcntl_getpriority,pcntl_setpriority,pcntl_async_signals,
> disable_classes =
> zend.enable_gc = On
> expose_php = Off
> max_execution_time = 30
> max_input_time = 60
> memory_limit = 128M
> error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
> display_errors = Off
> display_startup_errors = Off
> log_errors = On
> log_errors_max_len = 1024
> ignore_repeated_errors = Off
> ignore_repeated_source = Off
> report_memleaks = On
> html_errors = On
> variables_order = "GPCS"
> request_order = "GP"
> register_argc_argv = Off
> auto_globals_jit = On
> post_max_size = 8M
> auto_prepend_file =
> auto_append_file =
> default_mimetype = "text/html"
> default_charset = "UTF-8"
> doc_root =
> user_dir =
> enable_dl = Off
> file_uploads = On
> upload_max_filesize = 2M
> max_file_uploads = 20
> allow_url_fopen = On
> allow_url_include = Off
> default_socket_timeout = 60
> [CLI Server]
> cli_server.color = On
> [Date]
> [filter]
> [iconv]
> [imap]
> [intl]
> [sqlite3]
> [Pcre]
> [Pdo]
> [Pdo_mysql]
> pdo_mysql.default_socket=
> [Phar]
> [mail function]
> SMTP = localhost
> smtp_port = 25
> mail.add_x_header = Off
> [ODBC]
> odbc.allow_persistent = On
> odbc.check_persistent = On
> odbc.max_persistent = -1
> odbc.max_links = -1
> odbc.defaultlrl = 4096
> odbc.defaultbinmode = 1
> [Interbase]
> ibase.allow_persistent = 1
> ibase.max_persistent = -1
> ibase.max_links = -1
> ibase.timestampformat = "%Y-%m-%d %H:%M:%S"
> ibase.dateformat = "%Y-%m-%d"
> ibase.timeformat = "%H:%M:%S"
> [MySQLi]
> mysqli.max_persistent = -1
> mysqli.allow_persistent = On
> mysqli.max_links = -1
> mysqli.default_port = 3306
> mysqli.default_socket =
> mysqli.default_host =
> mysqli.default_user =
> mysqli.default_pw =
> mysqli.reconnect = Off
> [mysqlnd]
> mysqlnd.collect_statistics = On
> mysqlnd.collect_memory_statistics = Off
> [OCI8]
> [PostgreSQL]
> pgsql.allow_persistent = On
> pgsql.auto_reset_persistent = Off
> pgsql.max_persistent = -1
> pgsql.max_links = -1
>

Bug#952897: opentmpfiles: Please make opentmpfiles to be drop-in replacement to systemd-tmpfiles

[Ondřej Surý]

Package: opentmpfiles
Version: 0.2+2019.05.21.git.44a55796ba-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

to make opentmpfiles usable for package maintainers
it needs to be drop-in replacement in a sense that
I can rely on the interface to be available for my
packages.  Not by calling extra script, not by adding
extra shell spaghetti to decide whether systemd-tmpfiles
is available and if not try opentmpfiles and if not ...

As a packager I want to be able to freely use the
declaratife interfaces provided by systemd even when
writing sysv-rc scripts.  The other option would be
to just drop the init script and provide just the
service file, but I am not decided I want to go
this path.

Ondrej

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

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

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAl5b365fFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcKoEw//YrGedT2qe3TZ7S+2Cjm6F+oXHw96NfHGEhB6znFjhL50tHZtOBzktpf3
ijB42PuX+8Y5XXu+hUGfQ8tO4LKy3YupR0MJlZnSPftS1yFX2DD3aPZAKZdpXdMa
hGFFIpNRB4sLz1dgZz46UXZXydSjRBFF+tdipu3+jfoWcrMt0p4n4Ht/dH+LlwK0
HFjwGbPti2a0QFYcgwHPjsPVr31q0tmOZpzMX1VEKLbRlC9JQCMaBU69YbBLLKbI
GHtRoflvk0Pi+aRNboXs/HtPiiKq4Nl6AmqosLDKHFoO71/OyZ8JAhrBUDk+Q1+4
RsnDIuawC7Oa21cwWVCEa9wg2LnI1XSg52bnRiEcGC8OqWbq1KNW3Rag0QkZ3JTM
XHpyt79SKy0pKU6h9zOCSepoVBeSLWl3T1mASMd/TdyIp8Z3NkrryhL22HS7g2UY
m5uXbD+lgYyyhe4+sYQ1K8SAhWUafYz9FbLXJ7TvliCNR1oKjQ26yj1VXCM2FCXu
Nz3YVdaHHwjmsK1nKEiPicmLpeJMVS9Zk1MniWoia+/Ed7vC0VG2qjuECtf4Qk1x
p+0VkbQIdYszznNHtxMj90EhkTbl4I2raqB7JAHdLQxZh8YGsEJeKHlikCwMqNBE
Ye0JdcwfFx0qZZoDm8iMauPDlsH+vJb4igqDtRFv7pnmJhmRrus=
=lnpJ
-END PGP SIGNATURE-

Bug#952896: kmail: message body section of kmail flickers rapidly and displays no content

[Russell Coker]

Package: kmail
Version: 4:19.08.3-1
Severity: critical
Justification: breaks unrelated software

I tagged this critical and breaks unrelated software as there seems no better
tag for software that is dangerous for epileptic people to use.

Every time I launch kmail the message body section flickers black and white
rapidly and displays no content.  This makes the program impossible to use,
uses 100% CPU time on one core, and makes it dangerous for some people to use.

If I run "ssh -Y localhost" before running kmail I get the same result of no
content being displayed but the flickering is slower due to X/ssh delays.

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages kmail depends on:
ii  akonadi-server  4:19.08.3-1
ii  kdepim-runtime  4:19.08.3-2
ii  kio 5.62.1-2+b1
ii  libc6   2.29-10
ii  libgcc-s1 [libgcc1] 10-20200222-1
ii  libgcc1 1:10-20200222-1
ii  libgpgmepp6 1.13.1-6
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-19.08] 4:19.08.3-1
ii  libkf5akonadicontact5 [libkf5akonadicontact5-19.08] 4:19.08.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-19.08]   4:19.08.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-19.08]   4:19.08.3-1
ii  libkf5akonadisearch-bin 4:19.08.3-1
ii  libkf5akonadisearch-plugins 4:19.08.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-19.08  4:19.08.3-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-19.08] 4:19.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-19.08] 4:19.08.3-1
ii  libkf5bookmarks55.62.0-1+b1
ii  libkf5calendarcore5abi2 [libkf5calendarcore5-19.08] 4:19.08.3-2
ii  libkf5calendarutils5 [libkf5calendarutils5-19.08]   4:19.08.3-1
ii  libkf5codecs5   5.62.0-1
ii  libkf5completion5   5.62.0-1+b1
ii  libkf5configcore5   5.62.0-1+b1
ii  libkf5configgui55.62.0-1+b1
ii  libkf5configwidgets55.62.0-1+b1
ii  libkf5contacts5 [libkf5contacts5-19.08] 4:19.08.3-1
ii  libkf5coreaddons5   5.62.0-1
ii  libkf5crash55.62.0-1+b1
ii  libkf5dbusaddons5   5.62.0-1
ii  libkf5followupreminder5 [libkf5followupreminder5-19.08] 4:19.08.3-1
ii  libkf5grantleetheme-plugins 19.08.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-19.08] 4:19.08.3-1
ii  libkf5guiaddons55.62.0-2
ii  libkf5i18n5 5.62.0-1
ii  libkf5iconthemes5   5.62.0-1+b1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-19.08  19.08.3-1
ii  libkf5itemmodels5   5.62.0-1
ii  libkf5itemviews55.62.0-1+b1
ii  libkf5jobwidgets5   5.62.0-1+b1
ii  libkf5kcmutils5 5.62.0-1+b2
ii  libkf5kiocore5  5.62.1-2+b1
ii  libkf5kiofilewidgets5   5.62.1-2+b1
ii  libkf5kiowidgets5   5.62.1-2+b1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-19.08] 19.08.3-1
ii  libkf5ksieveui5 [libkf5ksieveui5-19.08] 4:19.08.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-19.08]   4:19.08.3-1
ii  libkf5libkdepimakonadi5 [libkf5libkdepimakonadi5-19.08] 4:19.08.3-1
ii  libkf5libkleo5 [libkf5libkleo5-19.08]   4:19.08.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-19.08] 4:19.08.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-19.08]   19.08.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-1  19.08.3-1
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-19.08]   4:19.08.3-1

Bug#906026: Switch to Ayatana Indicators

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 2020-02-13 at 13:11 +0100, Andreas Henriksson wrote:
> Control: severity -1 serious
> 
> Hello XFCE Maintainers,
> 
> I'm bumping the severity of this bug report because the libindicators
> package in RC buggy and likely not going to make it for bullseye,
> plus the fact that this bug report has been open with patch for >1.5
> years now! Apparently it needs some extra visibility or likely an NMU.
> 
> 
Hi Andreas and Mike,

rather than a patch on the bug, would you be able to provide a merge request
against the package on Salsa (
https://salsa.debian.org/xfce-extras-team/lightdm-gtk-greeter)? I think it'd
be easier for me to reply there.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5b4cMACgkQ3rYcyPpX
RFst1gf+N9iyTkOQk8ysyIM/GU6zZY/e7obw94TlXct1Uw0y39LUtPk7FLkr50tX
/fWRZ2wor3snFScrGpblSOf1nZqYYc7V8ueLWDY8xJzwmhFyi4xxf5Rklmw1veRS
PX0pdmGNU3h51XVDFF2fZfWoJjmXsyyGSOSo53ftQVV7K9x8sE8J8YruXWpau+wv
hdYUF83PXXLu9eoZXOp7rsZoTSJjIbNYkrvQiLUyt6W4rnSUBoGBtvImY8XXOSBq
zSTPND1UzhI3ONI/Aer80ZI6ouunc8i+RihEmUuGPeDGJh5CSB4HXvvWtGzFiKdy
jFwDX318vM9geoUcWP8cWa6BDv7mFA==
=aNeL
-END PGP SIGNATURE-

Bug#952898: apticron produces too long lines in mails

[Rainer Kupke]

Package: apticron
Version: 1.2.3+nmu1
Severity: normal

Dear Maintainer,

Normal usage of apticron.

Sometimes the mails generated by apticron bounce.
Looks like exim4 does not want to transport mails with lines longer than 998
characters.



I temporarily configured apticron to send mail to a local account to get the
mail before the bounce.

Found that the mail contains the following line with 1071 characters:
##
--- Changes for libreoffice (fonts-opensymbol gir1.2-lokdocview-0.1 libjuh-java
libjurt-java liblibreofficekitgtk libreoffice libreoffice-base libreoffice-
base-core libreoffice-base-drivers libreoffice-calc libreoffice-common
libreoffice-core libreoffice-draw libreoffice-gnome libreoffice-gtk3
libreoffice-help-common libreoffice-help-de libreoffice-help-en-us libreoffice-
impress libreoffice-java-common libreoffice-l10n-de libreoffice-librelogo
libreoffice-math libreoffice-nlpsolver libreoffice-report-builder libreoffice-
report-builder-bin libreoffice-script-provider-bsh libreoffice-script-provider-
js libreoffice-script-provider-python libreoffice-sdbc-firebird libreoffice-
sdbc-hsqldb libreoffice-sdbc-mysql libreoffice-sdbc-postgresql libreoffice-
style-colibre libreoffice-style-elementary libreoffice-style-tango libreoffice-
wiki-publisher libreoffice-writer libreofficekit-data libridl-java libuno-cppu3
libuno-cppuhelpergcc3-3 libuno-purpenvhelpergcc3-3 libuno-sal3 libuno-
salhelpergcc3-3 libunoil-java libunoloader-java python3-uno uno-libs-private
ure) ---
#


Probably apticron should wrap lines before sending mail.



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

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

Versions of packages apticron depends on:
ii  apt 1.8.4
ii  bsd-mailx [mailx]   8.1.2-0.20180807cvs-1+b1
ii  bzip2   1.0.8-2
ii  cron [cron-daemon]  3.0pl1-136
ii  dpkg1.19.7
ii  ucf 3.0038+nmu1

Versions of packages apticron recommends:
ii  apt-listchanges  3.22
ii  gpg  2.2.19-1
ii  iproute2 5.5.0-1

apticron suggests no packages.

-- debconf information:
  apticron/notification: root
From root@eris Sun Mar 01 16:31:42 2020
Return-path: 
Envelope-to: jknoll@eris
Delivery-date: Sun, 01 Mar 2020 16:31:42 +0100
Received: from root by eris.fritz.box with local (Exim 4.93)
(envelope-from )
id 1j8QZC-0015JA-6U; Sun, 01 Mar 2020 16:31:42 +0100
To: jknoll@eris, root@eris
Subject: 131 Debian package update(s) for eris
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8bit
Message-Id: 
From: root 
Date: Sun, 01 Mar 2020 16:31:42 +0100
Status: RO

apticron report [Sun, 01 Mar 2020 16:31:20 +0100]


apticron has detected that some packages need upgrading on:

eris 
[ 192.168.178.23 2003:cd:bbcd:b300:2268:9dff:fee8:3a6f ]

The following packages are currently pending an upgrade:

bash 5.0-6
binutils 2.34-4
binutils-common 2.34-4
binutils-x86-64-linux-gnu 2.34-4
cpp-9 9.2.1-30
curl 7.68.0-1
dirmngr 2.2.19-2
fonts-opensymbol 2:102.11+LibO6.4.1-1
g++-9 9.2.1-30
gcc-9 9.2.1-30
gcc-9-base 9.2.1-30
gfortran-9 9.2.1-30
gir1.2-cogl-1.0 1.22.4-4
gir1.2-coglpango-1.0 1.22.4-4
gir1.2-lokdocview-0.1 1:6.4.1-1
git 1:2.25.1-1
git-doc 1:2.25.1-1
git-man 1:2.25.1-1
gnome-font-viewer 3.34.0-2
gnupg 2.2.19-2
gnupg-l10n 2.2.19-2
gnupg-utils 2.2.19-2
gnupg2 2.2.19-2
gpg 2.2.19-2
gpg-agent 2.2.19-2
gpg-wks-client 2.2.19-2
gpg-wks-server 2.2.19-2
gpgconf 2.2.19-2
gpgsm 2.2.19-2
gpgv 2.2.19-2
libarchive-zip-perl 1.67-2
libasan5 9.2.1-30
libbcel-java 6.4.1-1
libbinutils 2.34-4
libcogl-common 1.22.4-4
libcogl-pango20 1.22.4-4
libcogl-path20 1.22.4-4
libcogl20 1.22.4-4
libctf-nobfd0 2.34-4
libctf0 2.34-4
libcurl3-gnutls 7.68.0-1
libcurl4 7.68.0-1
libcurl4-gnutls-dev 7.68.0-1
libgcc-9-dev 9.2.1-30
libgfortran-9-dev 9.2.1-30
libglib2.0-0 2.62.5-1
libglib2.0-bin 2.62.5-1
libglib2.0-data 2.62.5-1
libgmp10 2:6.2.0+dfsg-4
libhdf5-103 1.10.4+repack-11
libjuh-java 1:6.4.1-1
libjurt-java 1:6.4.1-1
liblibreofficekitgtk 1:6.4.1-1
libqt5location5 5.12.5+dfsg-5
libqt5positioningquick5 5.12.5+dfsg-5
libqt5quickwidgets5 5.12

Bug#929841: systemd-udevd: regulatory.0: Process '/sbin/crda' failed with exit code 255.

[Ben Hutchings]

On Sun, 2020-03-01 at 16:37 +0100, Thorsten Glaser wrote:
> retitle 929841 systemd-udevd: regulatory.0: Process '/sbin/crda' failed with 
> exit code 255.
> thanks
> 
> Could this have to do with /lib/udev/rules.d/85-regulatory.rules ?
> 
> A quick search through the code shows it returns “-1” (i.e. 255) in
> multiple places (the main function is written like kernel code, not
> userspace…), and is called from two files in /lib/udev/rules.d/, one
> indirectly via iw reg set (which we already established works for me)
> and once directly via the aforementioned file.
> 
> That file contains this comment…
> 
> # For more information see:
> # http://wireless.kernel.org/en/developers/Regulatory/CRDA
> 
> … but that URL is dead, but the Internet Archive has it under:
> http://web.archive.org/web/20190825055504/https://wireless.wiki.kernel.org/en/developers/Regulatory/CRDA
> 
> Interestingly enough, the 85-regulatory.rules does not set $COUNTRY,
> and calling crda without it set does result in exitting with -1.

The kernel sets COUNTRY in the uevent, which is copied into the device
properties.  Then udev copies the device properties into the
environment when running an external program.

Ben.

> Unfortunately, none of the printfs found in crda make it into syslog.
> 
> Retitling the bug so the actual issue, not a red herring, is used as title.
> 
> bye,
> //mirabilos
-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
  - Albert Einstein




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

Bug#192787: reassign

[Francesco Poli]

On Thu, 20 Feb 2020 13:26:44 +0530 Avinash Sonawane wrote:

> On Sat, 17 May 2003 15:36:53 -0400 Matt Zimmerman 
> wrote:
> > reassign 192787 apt-listbugs
> > thanks
> > 
> > This is impossible (see #80123), but in any case not apt's bug.
> 
> As per this comment
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=80123#68 on #80123
> now there are hooks which run before downloads. I would love to see
> apt-listbugs using them to show bug reports before downloading the
> packages.

Hello,
I am [waiting] for a reply from apt developers in order to clarify
whether there is a Pre-Download hook which works exactly as the
Pre-Install hook.

[waiting]: 

An alternative strategy could perhaps be the use of [json hooks], which
however seem to require a heavy redesign of all the interaction between
apt-listbugs and libapt-pkg. Frankly speaking, I do not know when I
will get around to doing such a redesign... Sorry about that!  :-(

[json hooks]: 



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp6Ij_IBLDeU.pgp
Description: PGP signature

Bug#952899: pillow: d/copyright issues

[Sean Whitton]

Source: pillow
Version: 6.2.1-2
Severity: serious
Justification: Policy 2.3, 4.5, 12.5

During review in binary-NEW, I found the following issues with
d/copyright.  Since the issues already exist in the archive I did not
REJECT, but they should be fixed.

Note that I am filing an identical list of problems against
src:pillow-python2 as the orig.tar is now in the archive twice.

- Needs "Alex Clark **and contributors**" from LICENSE

- Copyright information for Tests/fonts not in d/copyright.

- Google suggests that Tests/images/bmp is GPL-3 and also that the files
  are generated using C code.  If that's right, we would need to at
  least include that code for generating the images in
  debian/missing-sources/ (and ideally regenerate them).

- Tests/images/pillow3.icns looks like it contains a colour space
  copyright 1998 Hewlett-Packard Company; unclear how licensed.

- Tests/test_file_fli.py says that Tests/images/a.fli came from the web
  and I cannot see any free license; probably needs to be filtered out.

- Tests/test_file_mcidas.py says something similar for some other
  images; this should be accounted for.

- Several files matching {docs/example,src/PIL}/*ImagePlugin.py and
  src/libImaging/BcnDecode.c are public domain/CC0.

- Most files matching
  src/PIL/{ImageMorph,MspImagePlugin,SpiderImagePlugin,_binary}.py and
  src/libImaging/{Jpeg2K*,Quant*,SgiRleDecode.c,UnsharpMask.c} have
  different copyright holders.

- src/Tk/_tkmini.h has different copyright holders and license; possibly
  not DFSG-free due to "GOVERNMENT USE" section.

- src/libImaging/{QuantOctree.c,raqm.h,nmake.opt} have different
  licenses and copyright holders.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#929841: systemd-udevd: regulatory.0: Process '/sbin/crda' failed with exit code 255.

[Thorsten Glaser]

On Sun, 1 Mar 2020, Ben Hutchings wrote:

> The kernel sets COUNTRY in the uevent, which is copied into the device
> properties.  Then udev copies the device properties into the
> environment when running an external program.

OK. But where does stderr of crda go anyway? Trying to debug this…

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

Bug#946152: iptables-dev vs libiptc-dev dependency in collectd

[Antonio Russo]

Sorry for the noise here. I understand that these are two separate issues, and 
I believe
that upstream has addressed the libiptc -> libip4tc name change in their 5.10.0 
release.

My MR has been updated to only pull in libip4tc-dev and libip6tc-dev, and not 
libiptc-dev
in a third patch, so there is still a patch pending to fix this.

Antonio

Bug#952900: enchant-2: Please package new upstream version (2.2.8)

[Boyuan Yang]

Source: enchant-2
Version: 2.2.7+repack1-1
Severity: normal
X-Debbugs-CC: bi...@debian.org sjo...@debian.org

Dear enchant-2 maintainers,

Upstream has released v2.2.8 with new nuspell support. Please consider
packaging this new version in Debian.

-- 
Thanks,
Boyuan Yang


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

Bug#929841: systemd-udevd: regulatory.0: Process '/sbin/crda' failed with exit code 255.

[Ben Hutchings]

On Sun, 2020-03-01 at 18:28 +0100, Thorsten Glaser wrote:
> On Sun, 1 Mar 2020, Ben Hutchings wrote:
> 
> > The kernel sets COUNTRY in the uevent, which is copied into the device
> > properties.  Then udev copies the device properties into the
> > environment when running an external program.
> 
> OK. But where does stderr of crda go anyway? Trying to debug this…

It looks like systemd-udevd logs it at debug level.

Ben.

-- 
Ben Hutchings
It is a miracle that curiosity survives formal education.
  - Albert Einstein




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

Bug#952901: shotcut: Segmentation fault on 4K monitor

[Celelibi]

Package: shotcut
Version: 20.02.17-2
Severity: important

Dear Maintainer,

When I try to run shotcut on a 4K monitor I get the following logs:

$ LANG=C shotcut
[Info   ]  Starting Shotcut version 20.02.21 
[Info   ]  Linux version 
[Info   ]  number of logical cores = 8 
[Info   ]  locale = QLocale(C, Default, Default) 
[Info   ]  install dir = "/usr/bin" 
[Info   ]  device pixel ratio = 2 
[Debug  ]  language "C" 
[Debug  ]  deinterlacer "onefield" 
[Debug  ]  external monitor "" 
[Debug  ]  GPU processing true 
[Debug  ]  interpolation "bilinear" 
[Debug  ]  video mode "" 
[Debug  ]  realtime true 
[Debug  ]  audio channels 2 
No appenders associated with category qt.qpa.xcb
[Warning] <> xcb_shm_create_segment() can't be called for size 17178820624, 
maximumallowed size is 4294967295
zsh: segmentation fault  LANG=C shotcut


And here's an extract of a more verbose log:

$ QT_LOGGING_RULES='*.debug=true' shotcut
...
[Debug  ] <> [ QWidgetWindow(0x55c4be7b5c20, name="QSplashScreenClassWindow") ] 
creating shared memory 17178820624 bytes for QSize(65534, 65534) depth 32 bits 
32
No appenders associated with category qt.qpa.xcb
[Warning] <> xcb_shm_create_segment() can't be called for size 17178820624, 
maximumallowed size is 4294967295
No appenders associated with category qt.scaling
[Debug  ] <> QBackingStore::beginPaint new backingstore for 
QWidgetWindow(0x55c4be7b5c20, name="QSplashScreenClassWindow")
No appenders associated with category qt.scaling
[Debug  ] <>   source size QSize(65534, 65534) dpr 1
No appenders associated with category qt.scaling
[Debug  ] <>   destination size QSize(65534, 65534) dpr 2
...


And finally is an extract of the output of xrandr:

$ xrandr -q | head
Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
HDMI-0 disconnected primary (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
eDP-1-1 connected 3840x2160+0+0 (normal left inverted right x axis y axis) 
346mm x 194mm
   3840x2160 60.00*+  59.9848.0259.97  
   3200x1800 59.9659.94  
   2880x1620 59.9659.97  
   2560x1600 59.9959.97  
   2560x1440 59.9959.9959.9659.95  



It looks like Qt tries to allocate some memory for the splash screen,
but with a size that's so large it doesn't really make sens.

Note that the requested amount of memory is exactly 65534*65534*4. And
this size is exactly twice the maximum screen size: 32767*32767. The
screen size is not an exact power of two, so this would be an odd
coincidence.

I don't know if the bug is rather in shotcut or in Qt. Or maybe in the
way they interact. Feel free to reassign this bug report if needs be.


Best regards,
Celelibi

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

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

Versions of packages shotcut depends on:
ii  libc6  2.29-10
ii  libgcc-s1  10-20200222-1
ii  libjs-three111+dfsg1-1
ii  libmlt++3  6.20.0-1
ii  libmlt66.20.0-1
ii  libqt5core5a   5.12.5+dfsg-8
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5multimedia5  5.12.5-1+b1
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5opengl5  5.12.5+dfsg-8
ii  libqt5qml5 5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5webkit5  5.212.0~alpha3-7
ii  libqt5websockets5  5.12.5-2+b1
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200222-1
ii  melt   6.20.0-1
ii  qml-module-qtgraphicaleffects  5.12.5-2+b1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick-controls2   5.12.5+dfsg-2+b1
ii  qml-module-qtquick-dialogs 5.12.5-1+b1
ii  qml-module-qtquick-extras  5.12.5-1+b1
ii  qml-module-qtquick-layouts 5.12.5-5
ii  qml-module-qtquick-window2 5.12.5-5
ii  qml-module-qtquick25.12.5-5

shotcut recommends no packages.

shotcut suggests no packages.

-- no debconf information

Bug#951775: wpasupplicant: Wifi connection failure on upgrade to 2.9+git20200213

[robert]

Package: wpasupplicant
Version: 2:2.9.0-8
Followup-For: Bug #951775

Dear Maintainer,

   * What led up to the situation?

I follow Debian testing. Upgrading the system.

/var/log/aptitude
[UPGRADE] wpasupplicant:amd64 2:2.9+git20200213+877d9a0-1 -> 2:2.9.0-8

Inmediate effect. Just after package installation the computer hasn't been able
to establish a WiFi connection with the router due to an authentication issue.

$ egrep --binary-files=text --ignore-case "wlp2s0" /var/log/kern.log

Mar  1 16:40:12 debian kernel: [   29.565687] iwlwifi :02:00.0 wlp2s0:
renamed from wlan0
Mar  1 16:40:16 debian kernel: [   33.899255] wlp2s0: authenticate with MACid
Mar  1 16:40:16 debian kernel: [   33.903662] wlp2s0: send auth to MACid (try
1/3)
Mar  1 16:40:16 debian kernel: [   33.904422] wlp2s0: authenticated
Mar  1 16:40:16 debian kernel: [   33.906365] wlp2s0: associate with MACid (try
1/3)
Mar  1 16:40:16 debian kernel: [   33.908405] wlp2s0: RX AssocResp from MACid
(capab=0x1011 status=0 aid=1)
Mar  1 16:40:16 debian kernel: [   33.909534] wlp2s0: associated
Mar  1 16:40:16 debian kernel: [   33.921907] wlp2s0: Limiting TX power to 23
(23 - 0) dBm as advertised by MACid
Mar  1 16:40:16 debian kernel: [   33.957973] IPv6: ADDRCONF(NETDEV_CHANGE):
wlp2s0: link becomes ready
Mar  1 17:56:03 debian kernel: [ 4581.729289] wlp2s0: deauthenticating from
MACid by local choice (Reason: 3=DEAUTH_LEAVING)
Mar  1 17:56:15 debian kernel: [ 4593.383605] wlp2s0: authenticate with MACid
Mar  1 17:56:15 debian kernel: [ 4593.388166] wlp2s0: send auth to MACid (try
1/3)
Mar  1 17:56:15 debian kernel: [ 4593.389718] wlp2s0: MACid denied
authentication (status 1)
Mar  1 17:56:15 debian kernel: [ 4593.637502] wlp2s0: authenticate with MACid
Mar  1 17:56:15 debian kernel: [ 4593.642756] wlp2s0: send auth to MACid (try
1/3)
Mar  1 17:56:15 debian kernel: [ 4593.652866] wlp2s0: MACid denied
authentication (status 1)
Mar  1 17:56:16 debian kernel: [ 4594.825196] wlp2s0: authenticate with MACid
Mar  1 17:56:16 debian kernel: [ 4594.829740] wlp2s0: send auth to MACid (try
1/3)
Mar  1 17:56:16 debian kernel: [ 4594.833416] wlp2s0: MACid denied
authentication (status 1)
Mar  1 17:56:17 debian kernel: [ 4595.982983] wlp2s0: authenticate with MACid
Mar  1 17:56:17 debian kernel: [ 4595.987153] wlp2s0: send auth to MACid (try
1/3)
Mar  1 17:56:17 debian kernel: [ 4595.996401] wlp2s0: MACid denied
authentication (status 1)
Mar  1 17:56:21 debian kernel: [ 4599.631458] wlp2s0: authenticate with MACid
Mar  1 17:56:21 debian kernel: [ 4599.635950] wlp2s0: send auth to MACid (try
1/3)

I have been using the WiFi connection without any trouble for the last few
months. Currently, I'm using an Ethernet cable.

I'm reporting it here because for me the bug isn't solved. At least for me.
Should I create a new bug report because of being a different package version?

I haven't tried the package in "experimental" as reportbug suggested me because
I have no idea how to do it. Neither I know how to reuse/reinstall the previous
version (if it's still in the system).

Thanks in advance for looking into it. Regards.





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

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

Versions of packages wpasupplicant depends on:
ii  adduser3.118
ii  libc6  2.29-10
ii  libdbus-1-31.12.16-2
ii  libnl-3-2003.4.0-1+b1
ii  libnl-genl-3-200   3.4.0-1+b1
ii  libnl-route-3-200  3.4.0-1+b1
ii  libpcsclite1   1.8.26-3
ii  libreadline8   8.0-3
ii  libssl1.1  1.1.1d-2
ii  lsb-base   11.1.0

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information