Bug#794799:

[Sylvia Medina]

Bug#953014: grep-dctrl -w without -F misses the last package of each field

[Rebecca N. Palmer]

Package: dctrl-tools
Version: 2.24-3
Control: tags -1 patch

Example:
grep-dctrl -w -s Package "python3-pandas" 
/var/lib/apt/lists/*_debian_dists_sid_main_source_Sources
doesn't find influxdb-python, jsonpickle, poretools and tqdm, while the 
same without the -w does.  (This caused me to be unaware of #950063.) 
All these packages have their python3-pandas build-dependency listed last.


This happens when searching a whole entry, but not when searching 
particular fields (-F).


Fix (also adding support for build profiles <> without a preceding 
space, though I'm not sure if those are actually allowed):


--- dctrl-tools-2.24.orig/lib/atom.c
+++ dctrl-tools-2.24/lib/atom.c
@@ -23,7 +23,7 @@
 #include "version.h"

 #define RE_PKG_BEGIN   "(^| )"
-#define RE_PKG_END "([, \\(]|$)"
+#define RE_PKG_END "([, \\(\n<]|$)"

 void atom_finish(struct atom * atom)
 {

Bug#953013: pyyaml: CVE-2020-1747: arbitrary command execution through python/object/new when FullLoader is used

[Salvatore Bonaccorso]

Source: pyyaml
Version: 5.3-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/yaml/pyyaml/pull/386

Hi,

The following vulnerability was published for pyyaml.

CVE-2020-1747[0]:
|arbitrary command execution through python/object/new when FullLoader
|is used

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-1747
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1747
[1] https://github.com/yaml/pyyaml/pull/386

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#644174: Twoje konto skrzynki e-mail musi zostać teraz zweryfikowane

[Jane Magoola Yoyeta]

WAŻNE POWIADOMIENIE MICROSOFT

Twoje konto skrzynki pocztowej musi zostać natychmiast 
zweryfikowane, w przeciwnym razie 
konto skrzynki pocztowej zostanie zawieszone, jeśli nie zostanie teraz 
zweryfikowane.


Dziękuję za Twoje zrozumienie


Zespół weryfikacyjny Microsoft

?




This e-mail and its attachments contain confidential information from UBOS, 
which is intended only for the person or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not 
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is prohibited. If you receive this 
e-mail in error, please notify the sender by phone or email immediately and 
completely delete it!

Bug#952886: mini-transition: okular

[Pino Toscano]

In data lunedì 2 marzo 2020 11:50:24 CET, Emilio Pozuelo Monfort ha scritto:
> On 01/03/2020 15:36, Pino Toscano wrote:
> > 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.
> 
> Go ahead.

Uploaded yesterday, and built everywhere. Feel free to schedule the
calligra binNMU at your convenience.

Thanks,
-- 
Pino Toscano

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

Bug#952755: adminer: missing configuration files in stable

[Leonardo Canducci]

Il mar 3 mar 2020, 02:57 Chris Lamb  ha scritto:

> Hi Leonardo et al.,
>
> > Maybe it would make sense to just add the missing config files from the
> > one in backports without bumping up the version. Does this respect
> > stable policies?
>
> Do you mean backports policies here?


No, I meant stable. As I said the package from backports works as expected
(but has a different version) and needs no fixes.


>

Bug#952913: biglybt: Side Bar rapidly flickers on mouse hoover

[elde]

After restarting BBT many times I found a case where the Side Bar doesn't 
flicker.

It happened when I restarted BBT after turning Side Bar hidden, and BBT started 
without side bar visible. When turning side bar visible after it started, it 
didn't flicker.

Restarting BBT with side bar visible caused side bar to flicker again.

The above behaviour is reproducible for me.

So the workaround is to turn off BBT with Side Bar hidden, so that after 
starting it again it doesn't flicker.

Bug#953012: RFS: freelan/2.2-3 [QA] [RC] -- Peer-to-peer virtual private network daemon

[Håvard Flaget Aasen]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: freelan
   Version : 2.2-3
   Upstream Author :
 * URL : https://www.freelan.org
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/freelan
   Section : net

It builds those binary packages:

  freelan - Peer-to-peer virtual private network daemon

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/freelan/freelan_2.2-3.dsc


Changes since the last upload:

   * QA Upload.
   * Update Standards-Version to 4.5.0
   * Add Rules-Requires-Root: no
   * Add folder to d/clean
   * Set upstream metadata fields: Bug-Database, Repository,
 Repository-Browse, Bug-Submit.
   * Add upstream commit as 0007-Move-to-Python-3.patch
   * Add upstream commit as 0006-Fix-build-outside-git.patch closes: 
#952306


Regards,

Bug#952108: Cloud variant: please enable CONFIG_VHOST_SCSI

[Josh Triplett]

On Mon, Mar 02, 2020 at 10:26:35PM -0800, Noah Meyerhans wrote:
> On Sun, Feb 23, 2020 at 12:28:53AM -0800, Josh Triplett wrote:
> > The normal Debian kernel configuration has CONFIG_VHOST_SCSI enabled,
> > but the cloud configuration does not seem to have it enabled. Please
> > enable CONFIG_VHOST_SCSI=m on the cloud configuration as well.
> 
> Out of curiosity, where is this actually needed?

Nested virtualization; vhost-scsi is needed on the host to serve disks
to a nested guest.

Bug#952108: Cloud variant: please enable CONFIG_VHOST_SCSI

[Noah Meyerhans]

On Sun, Feb 23, 2020 at 12:28:53AM -0800, Josh Triplett wrote:
> The normal Debian kernel configuration has CONFIG_VHOST_SCSI enabled,
> but the cloud configuration does not seem to have it enabled. Please
> enable CONFIG_VHOST_SCSI=m on the cloud configuration as well.

Out of curiosity, where is this actually needed?

Bug#953011: xandikos: Update to 0.1.0

[Diane Trout]

Package: xandikos
Severity: wishlist

Dear Maintainer,

I was trying to enable all of python-caldav's tests and it uses xandikos as a
CalDAV server to test against.

Unfortunately a number of tests fail with a traceback like the one below. I
suspect caldav's tests are implemented against the 0.1.0 version of xandikos
available on pypi while Debian is still on 0.0.11.

Thank you,
Diane

127.0.0.1 - - [03/Mar/2020 06:07:27] "DELETE
/sometestuser/calendars/pythoncaldav-test HTTP/1.1" 404 78
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 947, in
get_property_from_element
get_value_ext = prop.get_value_ext
AttributeError: 'PrincipalAddressProperty' object has no attribute
'get_value_ext'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 1791, in
__call__
return do.handle(environ, start_response, self)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 273, in
wrapper
responses = req_fn(self, environ, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 1570, in
handle
ret.append(Status(href, '200 OK', propstat=list(propstat)))
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 1000, in
get_all_properties
ps = get_property_from_name(href, resource, properties, name, environ)
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 919, in
get_property_from_name
return get_property_from_element(
  File "/usr/lib/python3/dist-packages/xandikos/webdav.py", line 949, in
get_property_from_element
prop.get_value(href, resource, ret, environ)
  File "/usr/lib/python3/dist-packages/xandikos/carddav.py", line 163, in
get_value
resource.get_principal_address(), href))
AttributeError: 'PrincipalBare' object has no attribute 'get_principal_address'



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

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

Versions of packages xandikos depends on:
ii  python3 3.7.5-3
ii  python3-defusedxml  0.6.0-2
ii  python3-dulwich 0.19.15-1
ii  python3-icalendar   4.0.3-3
ii  python3-jinja2  2.10.1-1

xandikos recommends no packages.

xandikos suggests no packages.

Bug#953010: glade: Upgrade to 3.22.2 ( to work with libglib2 >= 2.63.2 )

[crvi]

Package: glade
Version: 3.22.1-4
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

https://gitlab.gnome.org/GNOME/glade/issues/407

caused by glib >= 2.63.2

This is not an issue yet in Debian unstable / sid as the libglib2.0-0 version
is only 2.62.5-1. But, in experimental it is already 2.64.0-1. glade 3.22.1
breaks 100% if glib >= 2.63.2. Thanks.

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

Full details in upstream bug. Please refer
https://gitlab.gnome.org/GNOME/glade/issues/407

   * What was the outcome of this action?

Full details in upstream bug. Please refer
https://gitlab.gnome.org/GNOME/glade/issues/407

   * What outcome did you expect instead?

Full details in upstream bug. Please refer
https://gitlab.gnome.org/GNOME/glade/issues/407



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

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

Versions of packages glade depends on:
ii  libc6   2.29-10
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-2
ii  libgladeui-2-6  3.22.1-4
ii  libglib2.0-02.62.5-1
ii  libgtk-3-0  3.24.14-1
ii  libpango-1.0-0  1.42.4-8

Versions of packages glade recommends:
ii  devhelp   3.34.0-1
ii  libgtk-3-dev  3.24.14-1

glade suggests no packages.

-- no debconf information

Bug#953009: duck: Bad regexp: /moved to/

[Xavier Guimard]

Package: duck
Version: 0.13
Severity: normal

Hi,

duck search for /moved to/ but should search for /\bmoved to\b/. An
example: https://github.com/thejoshwolfe/yauzl contains a 'Removed
tools' sentence which match even if this is not the good expression.

Cheers,
Xavier

Bug#952951: botan: Replace PKCS11 headers provided by OASIS

[Sean Whitton]

Hello László,

On Mon 02 Mar 2020 at 10:41PM +01, László Böszörményi (GCS) wrote:

> On Mon, Mar 2, 2020 at 7:54 PM Sean Whitton  wrote:
>> On Mon 02 Mar 2020 at 06:39PM +01, László Böszörményi (GCS) wrote:
>> > On Mon, Mar 2, 2020 at 10:27 AM Alvin Chen  wrote:
>> >> https://sources.debian.org/src/botan/2.12.1-2/src/lib/prov/pkcs11/pkcs11.h/
>> >  It's up to Jack, who develops Botan. I'm still not sure this text
>> > snippet makes the code non-modifiable. But let me ask our FTP Masters
>> > and Jack himself how to interpret it.
>>
>> Can you give a link to the file in question please?
>  It's on the link yourself also included in your reply. Currently on
> the top of the text. But if you mean link to the upstream file which
> is in the latest release[1] and/or the license text[2] (link is in the
> file) of OASIS Open then here you go (under the 'Notices' paragraph).
> The actual text snippet in question is (if I read Alvin correctly):
> "However, this document itself may not be modified in any way,
> including by removing the copyright notice or references to OASIS,
> [...]". But please read the whole copyright text in all. Does the 'may
> not be modified in any way' refers the code (header file this time) or
> only the copyright text itself?
> In short, OASIS Open is a DFSG compliant license or not?

Thanks.  It looks like the license which does not permit modification
applies to the specification, so the specification is not DFSG-free.

As for pkcs11.h, I can't see any statement that it is under any license
at all, never mind a DFSG-free license.

So the bug severity would seem to be correct.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952974: [Pkg-nagios-devel] Bug#952974: Typo /etc/icingweb2 in a lot of module packages

[Sebastiaan Couwenberg]

On 3/2/20 10:52 PM, Christoph Berg wrote:
> Re: Sebastiaan Couwenberg 2020-03-02 
> <58cea4eb-d7a5-7cca-aea8-0c4238c3f...@xs4all.nl>
>>> The typo "/etc/icingweb2" seems to be in a lot of icingweb2 module
>>> packages:
>>
>> Those are separate source packages from icingaweb2, and not maintained
>> within this team. Reassigning.
> 
> Fwiw, I suspect that there's some template at fault from which this
> was copied.

The icingaweb2 package doesn't provide such a template.

I suspect David Kunz made the typo in the first module he packaged, and
subsequently copied that to all the other packages.

If the packages were maintained in the team I'd fix them, but he chose
not to.

Kind Regards,

Bas

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

Bug#952060: libsignon-glib FTBFS: a few non-trivial ways to fix

[John Scott]

This is caused by GLib => 2.58 which was uploaded in September 2018 long ago.

Likewise, libsignon-glib 1.12 lags behind upstream substantially.
It's 2.1 and the disparity causes the patch to not apply.

A cheap workaround might be to add a -Wno-error like is already done for
some other deprecated functions. (That has since been fixed upstream proper.)

But in version 1.13, the NEWS file says
* Build: don't emit a build error on deprecations
so perhaps to fix this "cleanly" without such a leap, this avenue may be
most suitable (perhaps 1.15).

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

Bug#953008: talloc: ftbfs with python3.8

[[kernel/mips*] enable O32_FP64 support on Buster]

Source: talloc
Version: 2.3.0-3
Severity: grave

python3.8 is now default python3 in unstable,
while talloc is unable to build with it.

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

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

Bug#952507: dunst cannot be disabled and steals notifications

[Norbert Preining]

Hi Nikos,

sorry for the late reply, and thanks for the detailed explanations. I
just rebooted my system, and realized that dunst is back there ;-)

> The autostart part of dunst is managed by dbus, specifically the 
> auto-activation
> feature. Unfortunately dbus is not as powerful of a service manager as systemd
> and it doesn't have a way to prioritise one service over another, or a way to
> disable one while still keeping it installed.
> 
> So what can be done now?

Is there a way to claim that interface/service somehow? I am thinking of
other cinnamon users (since I am one of the maintainers of Cinnamon in
Debian), and how Cinnamon could stop dbus from starting another
notification daemon, when the one from cinnamon is already running.
Is there a way for this? 
Or is it anyway too late, because the notification service is started
already before the cinnamon session is started? (during xsession
somewhere)?

> I don't see a way to solve this other than removing the dbus service file
> entirely, but for this to work and not break a lot of other systems we have to
> auto-enable dunst for all desktop users on install

Mumumu, not a nice solution, indeed.

> started. So it leaves the only option of having an auto-restart on failure 
> every
> X seconds (pretty ugly approach IMO, and it's going to spam the error logs if 
> no
> graphical session is started for a while).

No, that is even worse.

> Any other suggestions?

Not really anything better than learning how to claim the dbus faster
than dunst?

> From your side you can remove the service file at
> /usr/share/dbus-1/services/org.knopwob.dunst.service and have the i3 users
> enable dunst via systemd or enable it globally and disable it for yourself.

Removing the file is a bit bad an idea, because the next upload will
again bring it in.

Is there a way to "shadow"/disable it, similar to shadowing of systemd
units?

Best

Norbert

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

Bug#952762: openstack-pkg-tools: please make the build reproducible

[Chris Lamb]

Hi Thomas,

> The problem is, some package may need to customize dh_python3 calls even
> further. For example:
> 
> override_dh_python3:
> dh_python3 --shebang=/usr/bin/python3
> dh_python3 /usr/share/foo
> 
> if there's some Python files in /usr/share/foo
> 
> So there's no "one fit all" solution.

May I suggest we keep this bug (ie. #952762) strictly on the non-
determistic nature of the utility methods in openstack-pkg-tools which
exist regardless of the above difficulties. These are two highly
related yet separate issues at work here and I would not feel
comfortable if they got lost, confused with or got blocked by each
other.

Unfortunately, I'm not familar with the ramifications on your quoted
code so I'll have to leave any suggestions on the above to yourself
and/or anybody else involved in maintaining OpenStack in any case.
Thanks for understanding.


Regards,

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

Bug#952755: adminer: missing configuration files in stable

[Chris Lamb]

Hi Leonardo et al.,

> Maybe it would make sense to just add the missing config files from the 
> one in backports without bumping up the version. Does this respect
> stable policies? 
  
Do you mean backports policies here? It is an almost entirely-
separate team and policies that manage and govern backports compared
to the main stable repository. If you did indeed mean this, then yes,
adding the config files to the backports repo would be just fine and,
indeed, what backports is "for" in some way. 

This is, as I'm sure you're all assuming, unless I amm missing
something very special about these config files and/or they would
cause regressions in deployed systems, etc. etc.


Regards,

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

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

[Kevin Locke]

On Mon, 2020-03-02 at 08:48 +0100, Didier 'OdyX' Raboud wrote:
> Le dimanche, 1 mars 2020, 16.43:56 h CET Kevin Locke a écrit :
>> 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.

One additional caveat: CUPS accepts FQDN with .local TLD as a special
case, with or without the patch.

>> 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?
> 
> Have you tried building and testing without this patch?

I hadn't, but did just now.  I can confirm CUPS now responds 200 OK to
requests with FQDN Host.  However, I'm not familiar with mDNS and
don't have cups-browsed installed, so I can't confirm whether the
patch would cause the FQDN to be broadcast and what effects that might
have, as in LP#449586.

> After 4+ years, it seems realistic to try without this patch again but: a) 
> only if we're sure it helps, b) only after 2.3.1-11 is migrated to testing.

I don't feel qualified to weigh the trade-off between requiring
explicit ServerAlias for valid FQDN and causing mDNS issues due to
invalid FQDN.  At least the current behavior was relatively easy to
debug.  Feel free to hold off until someone with mDNS experience, or
with a stronger rationale for either side weighs in.

Thanks,
Kevin

Bug#938518: soupsieve: Python2 removal in sid/bullseye

[Stefano Rivera]

Control: tags -1 - pending

And there's a new upstream release, 2.0, that drops Python 2.7 support.

I'll hold back on that, for now.

But I'm somewhat tempted to fork the source package for it. But I'll
wait a couple of months, and see if we get nearer being able to drop the
2.7 package.

Ignore the pending tag. It's me pushing 2.0 into a branch.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#953007: featherpad looses the title-bar and I cannot use the minimize, maximize, resize and close buttons

[shirish शिरीष]

Package: featherpad
Version: 0.12.1-1
Severity: normal

Dear Maintainer,
With featherpad I loose the title-bar and I cannot use the minimize,
maximize, resize and close buttons. Please let me know if you need
more info.

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

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

Versions of packages featherpad depends on:
ii  libc62.29-10
ii  libgcc-s1 [libgcc1]  10-20200222-1
ii  libgcc1  1:10-20200222-1
ii  libhunspell-1.7-01.7.0-2+b1
ii  libqt5core5a 5.12.5+dfsg-8
ii  libqt5gui5   5.12.5+dfsg-8
ii  libqt5network5   5.12.5+dfsg-8
ii  libqt5printsupport5  5.12.5+dfsg-8
ii  libqt5svg5   5.12.5-2
ii  libqt5widgets5   5.12.5+dfsg-8
ii  libqt5x11extras5 5.12.5-1
ii  libstdc++6   10-20200222-1
ii  libx11-6 2:1.6.8-1

Versions of packages featherpad recommends:
ii  featherpad-l10n  0.12.1-1
ii  libglib2.0-bin   2.62.5-1

featherpad suggests no packages.

-- no debconf information

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

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

Bug#953006: Switch to current libreadline

[Bastian Germann]

Package: dbacl
Severity: normal

The package is not bound by license to build against the old
libreadline5. It can also use the current GPL-3 libreadline.

Bug#934597: ITP python-loompy

[Diane Trout]

Hi,

are you still planning on packaging loompy?

I had packaged a version personally but hadn't gotten around to
submitting the ITP.

Diane


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

Bug#937302: playonlinux: Python2 removal in sid/bullseye

[Scott Talbert]

On Tue, 3 Mar 2020, Markus Koschany wrote:


Because it is preventing Python 2 removal work.  Python 2 removal is a
long process, involving nearly 3500 packages [1].  It is not happening
in one instant, but gradually over time.  At the moment, playonlinux is
a leaf package from a Python 2 perspective and is thus blocking its
Python 2 rdeps from being removed.

Scott

[1] http://sandrotosi.me/debian/py2removal/index.html


Right, and that's the completely wrong approach. You can't just remove
important packages because of your goal. You have to actively help
people who have contributed to Debian for several years now. Just asking
them to remove their packages is disrespectful and a poor way to
contribute to Debian.


Sorry, I do not mean any disrespect.  What can I do to help?

Scott

Bug#953005: buster-pu: package serverspec-runner/1.2.2-1+deb10u1

[Daniel Leidert]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

This update is to fix #939645 [1]. The debdiff is attached. The issue has
already been fixed in unstable.

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

Regards, Daniel

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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5dnhoACgkQS80FZ8KW
0F2jYhAApx/qthfa1gElUjn/xmLStJBYuuuIa2S0/0HL3EnYcj2VUmJsn9aQ7H84
Ch8n88J7fxxt1KCAZ1m3wS8EsrCdFKKFRXTGN9xOGBoBBBWrz6Rjab7j/L1CbVDS
4U8Atlegb4SBsnALm5QsB4nmjJ+zsXV0aCNC8Y9itSIpDCtkx5sWtAKcaS/CyUdy
spjiYvsBmp4bbZZEFagXVpOyeploZ8T635gXsdSzQsguk/bZm1rVX0jspPhLWjfS
s1HU/m54CjhT204AWBRv358scBl0wzsM3RivFPffOPBXYkfady0susZMf6N2asXz
M3TPPkpkWptUWZvS6NTXWo/c0OWSaVY1/Irth6T5c5XE2PBS+ki5d8fdCsR2Itb1
h70kZOwksXyIer7QfqrE1nJgrSmxAgRlKCTnszNE9VZRpYgl/g+fjsNa4rEbzYTO
AzfqXHTekLc7rRbrHKVOEUyBXZRwBgxQw5R0lZ+7LneC+2cYF6rypBFRyE+JStjl
bsF34TBDppIpYJjlcn/hE97c9vcPwG61EFXSVCkp0qRxtzRv4kHnpXT4/raOl9GE
JLYok4jdZ0+Wxp7y7vqLhV68VWm/aG7DsY3u4pdgsOyQzl4+w1nusB4wnWBaV10n
wdGBQHHA0SF7cxOF2kT7qZx5n6WuMoeOh4UNzF47bLX1mSujupw=
=uJcm
-END PGP SIGNATURE-

Bug#937229: pacparser: Python2 removal in sid/bullseye

[Scott Kitterman]

NMU diff attached.  Since this is such a well aged RC bug, I'm not going to 
upload to delayed.

Scott Kdiff -Nru pacparser-1.3.6/debian/changelog pacparser-1.3.6/debian/changelog
--- pacparser-1.3.6/debian/changelog	2016-01-11 14:07:55.0 -0500
+++ pacparser-1.3.6/debian/changelog	2020-03-02 00:22:40.0 -0500
@@ -1,3 +1,10 @@
+pacparser (1.3.6-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drup python-pacparser - obsolete, no rdepends (Closes: #937229)
+
+ -- Scott Kitterman   Mon, 02 Mar 2020 00:22:40 -0500
+
 pacparser (1.3.6-1.1) unstable; urgency=medium
 
   * Non-maintainer upload. (Closes: #809466)
diff -Nru pacparser-1.3.6/debian/control pacparser-1.3.6/debian/control
--- pacparser-1.3.6/debian/control	2016-01-11 14:12:18.0 -0500
+++ pacparser-1.3.6/debian/control	2020-03-02 00:22:40.0 -0500
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: Manu Garg 
 Uploaders: Andrew Pollock 
-Build-Depends: debhelper (>= 5), python-dev, python3-all-dev, dh-python
+Build-Depends: debhelper (>= 5), python3-all-dev, dh-python
 Standards-Version: 3.9.6
 
 Package: libpacparser1
@@ -51,27 +51,6 @@
  .
  This package contains the header files to build against the shared library.
 
-Package: python-pacparser
-Section: python
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}
-Architecture: any
-Description: Python module to parse proxy auto-config files
- a library to parse proxy auto-config (PAC) files. Proxy auto-config files are
- a vastly used proxy configuration method these days. Web browsers can use a PAC
- file to determine which proxy server to use or whether to go direct for a given
- URL. PAC files are written in JavaScript and can be programmed to return
- different proxy methods (e.g. "PROXY proxy1:port; DIRECT") depending upon URL,
- source IP address, protocol, time of the day etc. PAC files introduce a lot of
- possibilities.
- .
- Needless to say, PAC files are now a widely accepted method for proxy
- configuration management and companies all over are using them in corporate
- environments. Almost all popular web browsers support PAC files. The idea
- behind pacparser is to make it easy to add this PAC file parsing capability to
- any program (C and Python supported right now).
- .
- This package contains the Python bindings for the shared library
-
 Package: python3-pacparser
 Section: python
 Depends: ${python3:Depends}, ${shlibs:Depends}, ${misc:Depends}
diff -Nru pacparser-1.3.6/debian/patches/py3only.patch pacparser-1.3.6/debian/patches/py3only.patch
--- pacparser-1.3.6/debian/patches/py3only.patch	1969-12-31 19:00:00.0 -0500
+++ pacparser-1.3.6/debian/patches/py3only.patch	2020-03-02 00:22:40.0 -0500
@@ -0,0 +1,28 @@
+Description: Use python3 instead of python
+   * Drup python-pacparser - obsolete, no rdepends (Closes: #937229)
+Author: Scott Kitterman 
+Bug-Debian: https://bugs.debian.org/937229
+Origin: vendor
+Forwarded: not-needed
+Last-Update: 2020-03-02
+
+Index: pacparser-1.3.6/src/Makefile
+===
+--- pacparser-1.3.6.orig/src/Makefile
 pacparser-1.3.6/src/Makefile
+@@ -58,7 +58,7 @@ endif
+ CFLAGS = -g -DXP_UNIX -Wall -DVERSION=$(VERSION)
+ 
+ ifndef PYTHON
+-  PYTHON = python
++  PYTHON = python3
+ endif
+ 
+ # Spidermonkey library.
+@@ -134,5 +134,5 @@ install-pymod: pymod
+ 
+ clean:
+ 	rm -f $(LIBRARY_LINK) $(LIBRARY) libjs.a pacparser.o pactester pymod/pacparser_o_buildstamp jsapi_buildstamp
+-	cd pymod && python setup.py clean --all
++	cd pymod && $(PYTHON) setup.py clean --all
+ 	cd spidermonkey && $(MAKE) clean
diff -Nru pacparser-1.3.6/debian/patches/series pacparser-1.3.6/debian/patches/series
--- pacparser-1.3.6/debian/patches/series	1969-12-31 19:00:00.0 -0500
+++ pacparser-1.3.6/debian/patches/series	2020-03-02 00:22:40.0 -0500
@@ -0,0 +1 @@
+py3only.patch
diff -Nru pacparser-1.3.6/debian/python3-pacparser.examples pacparser-1.3.6/debian/python3-pacparser.examples
--- pacparser-1.3.6/debian/python3-pacparser.examples	1969-12-31 19:00:00.0 -0500
+++ pacparser-1.3.6/debian/python3-pacparser.examples	2015-09-04 16:06:41.0 -0400
@@ -0,0 +1,2 @@
+examples/*.py
+examples/wpad.dat
diff -Nru pacparser-1.3.6/debian/python-pacparser.examples pacparser-1.3.6/debian/python-pacparser.examples
--- pacparser-1.3.6/debian/python-pacparser.examples	2015-09-04 16:06:41.0 -0400
+++ pacparser-1.3.6/debian/python-pacparser.examples	1969-12-31 19:00:00.0 -0500
@@ -1,2 +0,0 @@
-examples/*.py
-examples/wpad.dat
diff -Nru pacparser-1.3.6/debian/python-pacparser.install pacparser-1.3.6/debian/python-pacparser.install
--- pacparser-1.3.6/debian/python-pacparser.install	2015-09-04 16:06:41.0 -0400
+++ pacparser-1.3.6/debian/python-pacparser.install	1969-12-31 19:00:00.0 -0500
@@ -1 +0,0 @@
-debian/tmp/usr/lib/python2*/*
diff -Nru pacparser-1.3.6/debian/rules pacparser-1.3.6/debian/rules
--- pacparser-

Bug#937302: playonlinux: Python2 removal in sid/bullseye

[Markus Koschany]

Am 02.03.20 um 23:46 schrieb Scott Talbert:
[...]
> Because it is preventing Python 2 removal work.  Python 2 removal is a
> long process, involving nearly 3500 packages [1].  It is not happening
> in one instant, but gradually over time.  At the moment, playonlinux is
> a leaf package from a Python 2 perspective and is thus blocking its
> Python 2 rdeps from being removed.
> 
> Scott
> 
> [1] http://sandrotosi.me/debian/py2removal/index.html

Right, and that's the completely wrong approach. You can't just remove
important packages because of your goal. You have to actively help
people who have contributed to Debian for several years now. Just asking
them to remove their packages is disrespectful and a poor way to
contribute to Debian.



signature.asc
Description: OpenPGP digital signature

Bug#952972: cinnamon: windows (desklets?) at the back capturing clicks from front windows

[Norbert Preining]

forwarded 952972 https://github.com/linuxmint/cinnamon/issues/9190
thanks

On Mon, 02 Mar 2020, cacat...@tuxfamily.org wrote:
> Several users seem to experience weirdness with mouse clicks with
> Cinnamon, this problem may have been around for years[1]. I'm still
> unsure of the origin, I suspect the culprit may be related to the
> «Desklets» feature. I kinda manage to reproduce it.

Thanks for the detailed report. I have seen similar behavior with other
desklets, too.

I have forwarded it upstream - let us hope for the best!

Thanks

Norbert

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

Bug#937302: playonlinux: Python2 removal in sid/bullseye

[Scott Talbert]

On Mon, 2 Mar 2020, Markus Koschany wrote:


What is the games team plan for Python 3 support in playonlinux?  Do
you plan to port it to Python 3?  Or remove?


I don't plan to port playonlinux to Python 3. However, a new version
of playonlinux is currently developped under Java [1]. There is no
release date for now, but I will
package it when a stable version is available.

Best,
Bertrand

[1] https://github.com/PhoenicisOrg/phoenicis


Should we then RM playonlinux from Debian?

Scott


Why should we remove playonlinux from Debian? There is a Java port that
just needs to be packaged. Python 2 has not been removed from Debian
yet. All that is needed is someone who works on it. It is completely
reasonable to have a package in unstable and not in testing for a while,
especially when it has a popcon inst value of more than 4700.


Because it is preventing Python 2 removal work.  Python 2 removal is a 
long process, involving nearly 3500 packages [1].  It is not happening in 
one instant, but gradually over time.  At the moment, playonlinux is a 
leaf package from a Python 2 perspective and is thus blocking its Python 2 
rdeps from being removed.


Scott

[1] http://sandrotosi.me/debian/py2removal/index.html

Bug#953004: gpaste: please drop unnecessary build-dep on mutter

[Jérémy Lal]

Le lun. 2 mars 2020 à 23:12, Steve Langasek 
a écrit :

> Package: gpaste
> Version: 3.34.1-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu focal ubuntu-patch
>
> Hi Jérémy,
>
> In Ubuntu we have recently completed the transition from libmutter-5-0 to
> libmutter-6-0.  In the process, I have noticed that gpaste has a
> build-dependency on libmutter-5-dev, despite having no runtime dependency.
>
> The attached patch fixes the gpaste upstream configure and the
> build-dependencies to not reference mutter, since it is unused at runtime.
>
> libmutter-6-dev is currently in the Debian NEW queue, so this transition
> will be starting in Debian soon, and just like in Ubuntu, the
> build-dependency will not block mutter from transitioning to testing - at
> which point gpaste will be unbuildable in testing.
>
> Thanks for considering,
>

Applied, but right now
- cannot build in debian (unsatisfiable dep, probably python 3 transition
gone bad)
- salsa does not reply
- neither tagpending

Jérémy

Bug#952997: debian-edu-config: pacparser being removed, please drop from debian-edu-config

[Scott Kitterman]

On March 2, 2020 9:28:29 PM UTC, Dominik George  wrote:
>Hi,
>
>> Please let me know your preference.  At some point we'll probably
>need
>> to go ahead with the rm of pacparser to keep the python2-rm process
>> moving.
>
>Why should it be necessary to remove the whole package, instead of just
>removing the Python 2 build, like for all other Python libraries in
>Debian?
>
>-nik

It's not, but it didn't seem worthwhile to spend time on the NMU if no one 
cared about the rest of the package.  Clearly debian-edu cares, so I'll do the 
NMU.

Scott K

Bug#952749: texlive-extra-utils: bibtexu segfault

[Hilmar Preuße]

Control: reassign -1 libicu63

On 2/28/20 3:04 PM, Philipp Klaus Krause wrote:

Hi all,

> bibtexu segfaults for me (bibtex works for the same files):
> 
> (gdb) run
> Starting program: /usr/bin/bibtexu zshg
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> The top-level auxiliary file: zshg.aux
> The style file: plain.bst
> Database file #1: zshg.bib
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77b54942 in ucnv_fromUnicode_UTF8_63 () from /usr/lib/x86_64-linux-
> gnu/libicuuc.so.63
> 
> .aux and .bib files to reproduce the issue:
> 
> http://colecovision.eu/stuff/zshg.aux
> http://colecovision.eu/stuff/zshg.bib
> 
The backtrace suggests that we segfault in a function provided by
libicu. Reassigning for now. bibtex is not linked w/ libicu63 and hence
can't be affected by its bugs.

hille@amd64-sid:~$ gdb /usr/bin/bibtexu
/var/crash/core.bibtexu.1356.amd64-sid.1583187279
GNU gdb (Debian 9.1-1) 9.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/bibtexu...
(No debugging symbols found in /usr/bin/bibtexu)
[New LWP 1356]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `bibtexu zshg.aux'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f748aa72942 in ucnv_fromUnicode_UTF8_63 (
--Type  for more, q to quit, c to continue without paging--
args=args@entry=0x7fffead899d0, err=err@entry=0x7fffead89ee4)
at ucnv_u8.cpp:323
323 ucnv_u8.cpp: No such file or directory.
(gdb) bt
#0  0x7f748aa72942 in ucnv_fromUnicode_UTF8_63 (
args=args@entry=0x7fffead899d0, err=err@entry=0x7fffead89ee4)
at ucnv_u8.cpp:323
#1  0x7f748aa6780d in _fromUnicodeWithCallback (
pArgs=pArgs@entry=0x7fffead899d0, err=err@entry=0x7fffead89ee4)
at ucnv.cpp:904
#2  0x7f748aa6856b in ucnv_fromUnicode_63
(cnv=cnv@entry=0x55da64a7e790,
target=target@entry=0x7fffead89a88,
targetLimit=targetLimit@entry=0x7fffead89e90 "",
source=source@entry=0x7fffead89a80,
sourceLimit=sourceLimit@entry=0x7fffeadeb9b4 , offsets=,
offsets@entry=0x0,
flush=1 '\001', err=0x7fffead89ee4) at ucnv.cpp:1262
#3  0x7f748aa689cc in ucnv_fromUChars_63 (cnv=0x55da64a7e790,
dest=, destCapacity=20001, src=,
srcLength=, pErrorCode=0x7fffead89ee4) at ucnv.cpp:1761
#4  0x55da62cd81a5 in ?? ()
#5  0x55da62ce383b in ?? ()
#6  0x55da62cda1db in ?? ()
#7  0x55da62cd9f54 in ?? ()
#8  0x55da62cda31c in ?? ()
#9  0x55da62cd9f54 in ?? ()
#10 0x55da62cd9f54 in ?? ()
#11 0x55da62cd9f54 in ?? ()
#12 0x55da62cd4a95 in ?? ()
#13 0x55da62ccf919 in ?? ()
#14 0x7f748a85 in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#15 0x55da62ccfb7a in ?? ()
(gdb)

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



signature.asc
Description: OpenPGP digital signature

Bug#937302: playonlinux: Python2 removal in sid/bullseye

[Markus Koschany]

Am 02.03.20 um 03:03 schrieb Scott Talbert:
> On Sat, 29 Feb 2020, Bertrand Marc wrote:
> 
>>> On Thu, 30 Jan 2020, Scott Talbert wrote:

 What is the games team plan for Python 3 support in playonlinux?  Do
 you plan to port it to Python 3?  Or remove?
>>
>> I don't plan to port playonlinux to Python 3. However, a new version
>> of playonlinux is currently developped under Java [1]. There is no
>> release date for now, but I will
>> package it when a stable version is available.
>>
>> Best,
>> Bertrand
>>
>> [1] https://github.com/PhoenicisOrg/phoenicis
> 
> Should we then RM playonlinux from Debian?
> 
> Scott

Why should we remove playonlinux from Debian? There is a Java port that
just needs to be packaged. Python 2 has not been removed from Debian
yet. All that is needed is someone who works on it. It is completely
reasonable to have a package in unstable and not in testing for a while,
especially when it has a popcon inst value of more than 4700.



signature.asc
Description: OpenPGP digital signature

Bug#953004: gpaste: please drop unnecessary build-dep on mutter

[Steve Langasek]

Package: gpaste
Version: 3.34.1-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Jérémy,

In Ubuntu we have recently completed the transition from libmutter-5-0 to
libmutter-6-0.  In the process, I have noticed that gpaste has a
build-dependency on libmutter-5-dev, despite having no runtime dependency.

The attached patch fixes the gpaste upstream configure and the
build-dependencies to not reference mutter, since it is unused at runtime.

libmutter-6-dev is currently in the Debian NEW queue, so this transition
will be starting in Debian soon, and just like in Ubuntu, the
build-dependency will not block mutter from transitioning to testing - at
which point gpaste will be unbuildable in testing.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gpaste-3.34.1/debian/control gpaste-3.34.1/debian/control
--- gpaste-3.34.1/debian/control2019-09-13 00:47:39.0 -0700
+++ gpaste-3.34.1/debian/control2020-03-02 13:57:46.0 -0800
@@ -21,7 +21,6 @@
  libdbus-1-dev,
  libxtst-dev,
  libclutter-1.0-dev,
- libmutter-5-dev,
  valac (>= 0.32)
 Build-Depends-Indep:
  libgjs-dev (>= 1.54.0)
diff -Nru gpaste-3.34.1/debian/patches/dont-use-mutter.patch 
gpaste-3.34.1/debian/patches/dont-use-mutter.patch
--- gpaste-3.34.1/debian/patches/dont-use-mutter.patch  1969-12-31 
16:00:00.0 -0800
+++ gpaste-3.34.1/debian/patches/dont-use-mutter.patch  2020-03-02 
13:57:46.0 -0800
@@ -0,0 +1,19 @@
+Description: don't look for mutter .pc file
+ This is unused by anything in the code and just causes an unneeded
+ build-dependency.
+Author: Steve Langasek 
+Last-Update: 2020-03-02
+
+Index: gpaste-3.34.1/configure.ac
+===
+--- gpaste-3.34.1.orig/configure.ac
 gpaste-3.34.1/configure.ac
+@@ -157,7 +157,7 @@
+ 
+ AS_IF([test x${enable_gnome_shell_extension} = xyes], [
+ AS_IF([test x${enable_introspection} != xyes], [AC_MSG_ERROR([*** 
Introspection support is required to run the gnome-shell extension])])
+-PKG_CHECK_MODULES(JS_EXTENSION, [mutter-clutter-5 gjs-1.0 >= 
gjs_required])
++PKG_CHECK_MODULES(JS_EXTENSION, [gjs-1.0 >= gjs_required])
+ ])
+ 
+ AS_IF([test x${enable_x_keybinder} = xyes], [
diff -Nru gpaste-3.34.1/debian/patches/series 
gpaste-3.34.1/debian/patches/series
--- gpaste-3.34.1/debian/patches/series 1969-12-31 16:00:00.0 -0800
+++ gpaste-3.34.1/debian/patches/series 2020-03-02 13:57:46.0 -0800
@@ -0,0 +1 @@
+dont-use-mutter.patch

Bug#952963: Bug#952997: debian-edu-config: pacparser being removed, please drop from debian-edu-config

[Mike Gabriel]

Hi Scott,

On  Mo 02 Mär 2020 21:53:35 CET, Scott Kitterman wrote:


On Monday, March 2, 2020 3:15:34 PM EST Mike Gabriel wrote:

Hi Scott,

On  Mo 02 Mär 2020 20:20:01 CET, Scott Kitterman wrote:
> Package: debian-edu-config
> Version: 2.11.14
> Severity: important
>
> Dear Maintainer,
>
> The pacparser source package is unmaintained and RC buggy.  As a result,
> I have asked to have it removed from Debian (Bug #952963).
> debian-edu-config depends on libpacparser1.  It is the only rdepend.
>
> If libpacparser1 is not important to debian-edu, please drop the depends
> to the removal can proceed.  If it is important to debian-edu, please
> take over maintenance of the package.
>
> I can provide a debdiff to drop the python2 bits from the package.  I
> was preparing an NMU to do so when I realized how hopelessly out of date
> the packaging is (compat = 5).  It won't be long before it either has to
> be removed anyway due to the package breaking or someone will have to
> re-invest the time in seriously modernizing it.
>
> If no one is interested (and there's no sign of it so far), I think it's
> better to just remove it.
>
> Please let me know your preference.  At some point we'll probably need
> to go ahead with the rm of pacparser to keep the python2-rm process
> moving.
>
> Scott K

We definitely need libpacparser1 (rather "pactester") in Debian Edu.
Or something similar.

Please put your removal request on hold or drop it entirely. I am
happy to invest some time in this.

Or do you know of an alternative way to analyze wpad files?


Thanks for getting back to me so quickly.  The removal is already on hold due
to there being a reverse depends.  I don't know about other ways to anyalze
wpad files.  My interest in this is strictly related to archive hygiene and
moving the python2-rm process along.

I'm marking the rm bug as done based on this feedback.  I'll go ahead with my
NMU to drop python2 support.  Since debian-edu is interested in the  
package, I
strongly recommend you consider adopting it because it's clearly  
unmaintained.

I'll leave the bug against debian-edu open as a reminder (feel free to close
it if that's not useful).

Scott K


Thanks for doing the NMU for now. I will add this thing to my list,  
but will not get to it before the next month or so.


Currently, it seems that pacparser has not been orphaned, yet. There  
was this salvage procedure discussed earlier. I'll check if that is  
common practice these days and start the process of friendly take over.


Greets,
Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

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



pgpInygHhBWtP.pgp
Description: Digitale PGP-Signatur

Bug#953003: ceph: FTBFS on riscv64: undefined reference to `__atomic_exchange_1'

[Aurelien Jarno]

Source: ceph
Version: 14.2.7-1
Severity: normal
Tags: patch upstream

Dear maintainer,

ceph fails to build on riscv64 with the following error:

| /usr/bin/ld: ../../../lib/librbd.so.1.12.0: undefined reference to 
`__atomic_exchange_1'
| collect2: error: ld returned 1 exit status
| make[3]: *** [src/tools/rbd/CMakeFiles/rbd.dir/build.make:790: bin/rbd] Error 
1

The full build log is available there:
https://buildd.debian.org/status/fetch.php?pkg=ceph&arch=riscv64&ver=14.2.7-1&stamp=1580666087&raw=0

riscv64 only has native support for 4-byte and 8-byte atomics. Other
sizes, and in that case 1-byte atomic, have to be emulated through
libatomic. This library is automatically added at link time by GCC when
thread support is enabled. Unfortunately cmake defaults to use -lpthread
instead of using -pthread, which doesn't fully enable thread support.

Therefore the attached patch fixes the FTBFS issue on riscv64. Would it
be possible to include it in the next upload?

Thanks,
Aurelien

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: Link with -pthread instead of -lpthread to fix FTBFS on riscv64
Forwarded: no
Last-Update: 2020-03-01

--- ceph-14.2.7.orig/CMakeLists.txt
+++ ceph-14.2.7/CMakeLists.txt
@@ -28,6 +28,7 @@ list(APPEND CMAKE_MODULE_PATH "${CMAKE_S
 
 if(CMAKE_SYSTEM_NAME MATCHES "Linux")
   set(LINUX ON)
+  set(THREADS_PREFER_PTHREAD_FLAG ON)
   FIND_PACKAGE(Threads)
 elseif(CMAKE_SYSTEM_NAME MATCHES "FreeBSD")
   set(FREEBSD ON)

Bug#952954: ITP: fonts-jetbrains-mono -- free and open-source typeface for developers

[Romain Porte]

Hello again,

Le 02/03/2020 à 14:54, Romain Porte a écrit :
> I propose to start the review using the following files that I host on
> a personal server:
> https://microjoe.org/fonts-jetbrains-mono_1.0.3.tar.xz
> https://microjoe.org/fonts-jetbrains-mono_1.0.3.orig.tar.gz

Some updates:

1) I have reworked the package to use compat "3.0 (quilt)" instead of
"3.0 (native)".

2) The package now has a revision, making it version 1.0.3-1

3) The new sources have been uploaded using dput to the following URL:
https://perso.microjoe.org/debian/dput/

I hope this simplifies the review process. All the files should be
present, and this revision was absolutely necessary in case we want to
change files in the debian/ directory keeping the same upstream version.

Thanks in advance for review.

Romain.

Bug#952974: [Pkg-nagios-devel] Bug#952974: Typo /etc/icingweb2 in a lot of module packages

[Christoph Berg]

Re: Sebastiaan Couwenberg 2020-03-02 
<58cea4eb-d7a5-7cca-aea8-0c4238c3f...@xs4all.nl>
> > The typo "/etc/icingweb2" seems to be in a lot of icingweb2 module
> > packages:
> 
> Those are separate source packages from icingaweb2, and not maintained
> within this team. Reassigning.

Fwiw, I suspect that there's some template at fault from which this
was copied. But I didn't look closer than noticing the bad directory
on my box, and then seeing all these hits on codesearch.

Thanks,
Christoph

Bug#952951: botan: Replace PKCS11 headers provided by OASIS

[GCS]

On Mon, Mar 2, 2020 at 7:54 PM Sean Whitton  wrote:
> On Mon 02 Mar 2020 at 06:39PM +01, László Böszörményi (GCS) wrote:
> > On Mon, Mar 2, 2020 at 10:27 AM Alvin Chen  wrote:
> >> https://sources.debian.org/src/botan/2.12.1-2/src/lib/prov/pkcs11/pkcs11.h/
> >  It's up to Jack, who develops Botan. I'm still not sure this text
> > snippet makes the code non-modifiable. But let me ask our FTP Masters
> > and Jack himself how to interpret it.
>
> Can you give a link to the file in question please?
 It's on the link yourself also included in your reply. Currently on
the top of the text. But if you mean link to the upstream file which
is in the latest release[1] and/or the license text[2] (link is in the
file) of OASIS Open then here you go (under the 'Notices' paragraph).
The actual text snippet in question is (if I read Alvin correctly):
"However, this document itself may not be modified in any way,
including by removing the copyright notice or references to OASIS,
[...]". But please read the whole copyright text in all. Does the 'may
not be modified in any way' refers the code (header file this time) or
only the copyright text itself?
In short, OASIS Open is a DFSG compliant license or not?

Thanks,
Laszlo/GCS
[1] https://github.com/randombit/botan/blob/2.13.0/src/lib/prov/pkcs11/pkcs11.h
[2] http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html

Bug#952963: Bug#952997: debian-edu-config: pacparser being removed, please drop from debian-edu-config

[Dominik George]

Hi,

> Please let me know your preference.  At some point we'll probably need
> to go ahead with the rm of pacparser to keep the python2-rm process
> moving.

Why should it be necessary to remove the whole package, instead of just
removing the Python 2 build, like for all other Python libraries in
Debian?

-nik

-- 
Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
Teckids e.V. — Digitale Freiheit mit Jugend und Bildung
https://www.teckids.org/

Bug#738548: systemd support

[Brian May]

Andreas Henriksson  writes:

> I'm happy to help if you can provide the testing and review (as I don't
> personally use amavisd-new myself). I'm quite sure we can also get
> additional help from pkg-systemd-maintainers if they're asked to
> comment.

I hardly use it myself.

How does the following (attached) look?

I am wondering if I should just drop amavis-mc. It looks like it is just
a supervisor for amavisd-new, which systemd provides anyway. Also it
looks like a required dependency may not be in buster (libzeromq-perl
AFAIK).

Actually, I accidentally included the security hardening settings you
said I should not include. So wonder if I should drop these.
-- 
Brian May 
commit 2d8c8fec1ed103caafb9925658788e308420cbcf
Author: Brian May 
Date:   Tue Feb 4 08:04:01 2020 +1100

Add systemd service files.

Closes: #738548.

diff --git a/debian/amavisd-new.amavis-mc.service b/debian/amavisd-new.amavis-mc.service
new file mode 100644
index 000..91da47c
--- /dev/null
+++ b/debian/amavisd-new.amavis-mc.service
@@ -0,0 +1,19 @@
+[Unit]
+Description=Amavisd Master Supervisor
+Documentation=http://www.ijs.si/software/amavisd/#doc
+After=network.target
+
+[Service]
+User=amavis
+Group=amavis
+ExecStart=/usr/sbin/amavis-mc -f
+ExecStartPre=-/usr/bin/find /var/lib/amavis -maxdepth 1 -name 'amavis-*' -type d -exec rm -rf "{}" \;
+ExecStartPre=-/usr/bin/find /var/lib/amavis/tmp -maxdepth 1 -name 'amavis-*' -type d -exec rm -rf "{}" \;
+Restart=on-failure
+PrivateTmp=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/amavisd-new.amavis.service b/debian/amavisd-new.amavis.service
new file mode 100644
index 000..8ec7ef3
--- /dev/null
+++ b/debian/amavisd-new.amavis.service
@@ -0,0 +1,20 @@
+[Unit]
+Description=Interface between MTA and virus scanner/content filters
+Documentation=http://www.ijs.si/software/amavisd/#doc
+After=network.target
+
+[Service]
+User=amavis
+Group=amavis
+ExecStart=/usr/sbin/amavisd-new foreground
+ExecReload=/usr/sbin/amavisd-new reload
+ExecStartPre=-/usr/bin/find /var/lib/amavis -maxdepth 1 -name 'amavis-*' -type d -exec rm -rf "{}" \;
+ExecStartPre=-/usr/bin/find /var/lib/amavis/tmp -maxdepth 1 -name 'amavis-*' -type d -exec rm -rf "{}" \;
+Restart=on-failure
+PrivateTmp=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/amavisd-new.amavisd-snmp-subagent.service b/debian/amavisd-new.amavisd-snmp-subagent.service
new file mode 100644
index 000..6c32537
--- /dev/null
+++ b/debian/amavisd-new.amavisd-snmp-subagent.service
@@ -0,0 +1,17 @@
+[Unit]
+Description=Exports amavis SNMP data
+Documentation=http://www.ijs.si/software/amavisd/#doc
+After=network.target amavis.service
+
+[Service]
+User=amavis
+Group=amavis
+ExecStart=/usr/sbin/amavisd-snmp-subagent -f
+Restart=on-failure
+PrivateTmp=true
+CapabilityBoundingSet=
+ProtectSystem=full
+ProtectHome=true
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/changelog b/debian/changelog
index ec28175..2ec262f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+amavisd-new (1:2.11.0-7) unstable; urgency=medium
+
+  * Add systemd service file. Closes: #738548.
+
+ -- Brian May   Tue, 04 Feb 2020 07:58:33 +1100
+
 amavisd-new (1:2.11.0-6.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/rules b/debian/rules
index 1919a8d..9ad9568 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,9 +7,13 @@
 	dh  $@
 
 override_dh_installinit:
+	dh_systemd_enable -pamavisd-new --name amavis
+	dh_systemd_enable -pamavisd-new --name amavis-mc --no-enable
+	dh_systemd_enable -pamavisd-new --name amavisd-snmp-subagent --no-enable
 	dh_installinit --name=amavis
 	dh_installinit --name=amavisd-snmp-subagent --no-enable
 	dh_installinit --name=amavis-mc --no-enable
+	dh_systemd_start -pamavisd-new --name amavis
 
 override_dh_installchangelogs:
 	dh_installchangelogs -k RELEASE_NOTES

Bug#953002: corsix-th: FTBFS with libsdl2 2.0.10+dfsg1-2

[Andreas Beckmann]

Source: corsix-th
Version: 0.63-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

libsdl2 2.0.10+dfsg1-2 changed the installation layout and that broke
SDL detection in corsix-th:

-- Could NOT find SDL (missing: SDL_INCLUDE_DIR)
CMake Error at CorsixTH/CMakeLists.txt:110 (message):
  Error: SDL library not found, it is required to build.  Make sure the path
  is correctly defined or set the environment variable SDLDIR to the correct
  location


Andreas


corsix-th_0.63-1.log.gz
Description: application/gzip

Bug#952961: RFS: netsend/0.0~svnr250-1.3 [NMU, RC] -- a speedy filetransfer and network diagnostic program

[Sudip Mukherjee]

On Mon, Mar 2, 2020 at 9:14 PM Hilmar Preuße  wrote:
>
> On 3/2/20 1:05 PM, Sudip Mukherjee wrote:
>
> > I am looking for a sponsor for my package "netsend"
> >
> >  * Package name: netsend
> >Version : 0.0~svnr250-1.3
> >Upstream Author : Hagen Paul Pfeifer, Florian Westphal
> >  * URL : http://netsend.berlios.de/
> >
> I have doubt, that this URL is correct.

This url is mentioned in d/copyright and I think I am not allowed to
fix anything else in a NMU. :(


-- 
Regards
Sudip

Bug#952947: peewee: Package latest upstream (3.13.1)

[Adrian Vondendriesch]

Hi Mike,

Am 02.03.20 um 08:42 schrieb Mike Gabriel:
> Package: src:peewee
> Severity: wishlist
> X-Debbugs-Cc: adrian.vondendrie...@credativ.de
> 
> Hi Adrian,
> 
> for packaging GWE (GreenWithEnvy), a GPU (mostly NVidia) tweaking tool,
> I need an updated version of peewee in Debian unstable.
> 
> Would you be available for updating the package the coming days?

I've prepared a new upload. However, I need to have a close look at the
build log. The testsuite prints some warnings and I would like to verify
it doesn't include serious errors.

> Otherwise, would you be ok with me doing a team upload?

I'm always ok with team uploads ;)

Cheers,
 - Adrian



signature.asc
Description: OpenPGP digital signature

Bug#952961: RFS: netsend/0.0~svnr250-1.3 [NMU, RC] -- a speedy filetransfer and network diagnostic program

[Hilmar Preuße]

On 3/2/20 1:05 PM, Sudip Mukherjee wrote:

> I am looking for a sponsor for my package "netsend"
> 
>  * Package name: netsend
>Version : 0.0~svnr250-1.3
>Upstream Author : Hagen Paul Pfeifer, Florian Westphal
>  * URL : http://netsend.berlios.de/
> 
I have doubt, that this URL is correct.

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



signature.asc
Description: OpenPGP digital signature

Bug#953001: doomsday: Please strip the embedded font (Source Sans Pro)

[Boyuan Yang]

Source: doomsday
Version: 2.2.2+ds1-1~exp2
Severity: important

The new doomsday 2.x is embedding fonts of the Source Sans Pro family. With my
Debian Fonts Team member hat on, they are free fonts licensed under OFL-1.1
license thus this is not a critical problem. However, we should package Source
Sans Pro fonts separately or use other font alternatives.

-- 
Thanks,
Boyuan Yang


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

Bug#738548: systemd support

[Brian May]

Andreas Henriksson  writes:

> The best would be if upstream could provide a set of recommended
> service files (including security hardening settings).

For the record, this has been raised before:

https://groups.google.com/forum/#!msg/mailing.unix.amavis-user/gX_e87BOJfk/UxueACiuCQAJ
-- 
Brian May 

Bug#952997: debian-edu-config: pacparser being removed, please drop from debian-edu-config

[Scott Kitterman]

On Monday, March 2, 2020 3:15:34 PM EST Mike Gabriel wrote:
> Hi Scott,
> 
> On  Mo 02 Mär 2020 20:20:01 CET, Scott Kitterman wrote:
> > Package: debian-edu-config
> > Version: 2.11.14
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > The pacparser source package is unmaintained and RC buggy.  As a result,
> > I have asked to have it removed from Debian (Bug #952963).
> > debian-edu-config depends on libpacparser1.  It is the only rdepend.
> > 
> > If libpacparser1 is not important to debian-edu, please drop the depends
> > to the removal can proceed.  If it is important to debian-edu, please
> > take over maintenance of the package.
> > 
> > I can provide a debdiff to drop the python2 bits from the package.  I
> > was preparing an NMU to do so when I realized how hopelessly out of date
> > the packaging is (compat = 5).  It won't be long before it either has to
> > be removed anyway due to the package breaking or someone will have to
> > re-invest the time in seriously modernizing it.
> > 
> > If no one is interested (and there's no sign of it so far), I think it's
> > better to just remove it.
> > 
> > Please let me know your preference.  At some point we'll probably need
> > to go ahead with the rm of pacparser to keep the python2-rm process
> > moving.
> > 
> > Scott K
> 
> We definitely need libpacparser1 (rather "pactester") in Debian Edu.
> Or something similar.
> 
> Please put your removal request on hold or drop it entirely. I am
> happy to invest some time in this.
> 
> Or do you know of an alternative way to analyze wpad files?

Thanks for getting back to me so quickly.  The removal is already on hold due 
to there being a reverse depends.  I don't know about other ways to anyalze 
wpad files.  My interest in this is strictly related to archive hygiene and 
moving the python2-rm process along.

I'm marking the rm bug as done based on this feedback.  I'll go ahead with my 
NMU to drop python2 support.  Since debian-edu is interested in the package, I 
strongly recommend you consider adopting it because it's clearly unmaintained.  
I'll leave the bug against debian-edu open as a reminder (feel free to close 
it if that's not useful).

Scott K

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

Bug#940951: Upstream version (and ideally commit) which fixed CVE-2018-7587?

[Salvatore Bonaccorso]

Hi Andreas,

On Mon, Mar 02, 2020 at 06:29:40PM +0100, Andreas Tille wrote:
> On Mon, Mar 02, 2020 at 03:43:16PM +0100, Salvatore Bonaccorso wrote:
> > Hi Andreas,
> > 
> > On Mon, Mar 02, 2020 at 01:45:04PM +, Debian Bug Tracking System wrote:
> > > Hello Andreas,
> > > 
> > > I think I've fixed these bugs indeed, a few months ago.
> > > 
> > > Regards,
> > > 
> > > David.
> > > 
> > > PS : I'm sorry but I don't write Changelog for CImg anymore. Not
> > > that I don't maintain it, but it write my changes directly in the
> > > Changelog of the G'MIC project.
> > 
> > So this means 2.8.4 upstream contains the fix for CVE-2018-7587, any
> > pointers to the upstream commit which fixed the issue, was it fixed
> > before 2.8.4?
> > 
> > Many thanks in advance,
> 
> I understood David that this was fixed even before.  He has not pointed
> to any specific commit.

Then we need some help to track this down. We would like from security
point of view try to track the issues as exact as possible and
confirmed. The CVE-2018-7587 assignment itself is not very transparent
on it's own  unfortunately. The only reference I found was that it
relates to https://github.com/dtschump/CImg/issues/185 (as some others
CVE around that time). But now there were 5 testcases, and 5 other
CVEs relate to upstream commit
10af1e8c1ad2a58a0a3342a856bae63e8f257abb. CVE-2018-7587 itself say it
is for the "DoS occurs when loading a crafted bmp image that triggers
an allocation failure in load_bmp in CImg.h".

David, is this association correct?

Regards,
Salvatore

Bug#952963: Bug#952997: debian-edu-config: pacparser being removed, please drop from debian-edu-config

[Mike Gabriel]

Hi Scott,

On  Mo 02 Mär 2020 20:20:01 CET, Scott Kitterman wrote:


Package: debian-edu-config
Version: 2.11.14
Severity: important

Dear Maintainer,

The pacparser source package is unmaintained and RC buggy.  As a result,
I have asked to have it removed from Debian (Bug #952963).
debian-edu-config depends on libpacparser1.  It is the only rdepend.

If libpacparser1 is not important to debian-edu, please drop the depends
to the removal can proceed.  If it is important to debian-edu, please
take over maintenance of the package.

I can provide a debdiff to drop the python2 bits from the package.  I
was preparing an NMU to do so when I realized how hopelessly out of date
the packaging is (compat = 5).  It won't be long before it either has to
be removed anyway due to the package breaking or someone will have to
re-invest the time in seriously modernizing it.

If no one is interested (and there's no sign of it so far), I think it's
better to just remove it.

Please let me know your preference.  At some point we'll probably need
to go ahead with the rm of pacparser to keep the python2-rm process
moving.

Scott K


We definitely need libpacparser1 (rather "pactester") in Debian Edu.  
Or something similar.


Please put your removal request on hold or drop it entirely. I am  
happy to invest some time in this.


Or do you know of an alternative way to analyze wpad files?

Greets,
Mike


--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

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



pgpOlHhxW056c.pgp
Description: Digitale PGP-Signatur

Bug#953000: RM: arora -- RoM; FTBFS; Dead Upstream

[Boyuan Yang]

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

Dear FTP Masters,

Please remove package arora from Sid. According to 
https://bugs.debian.org/950401 , this package has missed stable release and
FTBFS for 3 years. The maintainer agreed to have it removed in the previous
bug report.

-- 
Thanks,
Boyuan Yang


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

Bug#797979:

[Corrin Campbell]

Hello Dear,
My name is Corrin, I am a United States and a military woman never
married no kids yet. I came across your profile, and I personally took
interest in being your friend. For confidential matters, please
contact me back through my private email corrinc...@gmail.com to
enable me send you my pictures and give you more details about me.
Hoping to hear from you soon.
Regards
Corrin.

Bug#952999: RFS: logrotate/3.16.0-1 -- Log rotation utility

[Christian Göttsche]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: logrotate
   Version : 3.16.0-1
   Upstream Author : https://github.com/logrotate/logrotate/issues
 * URL : https://github.com/logrotate/logrotate
 * License : GPL-2
 * Vcs : https://salsa.debian.org/debian/logrotate
   Section : admin

It builds those binary packages:

  logrotate - Log rotation utility

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/l/logrotate/logrotate_3.16.0-1.dsc

Changes since the last upload:

   [ Debian Janitor ]
   * Drop no longer supported add-log-mailing-address setting from
 debian/changelog.
   * Add missing colon in closes line.
   * Remove obsolete fields Name from debian/upstream/metadata.
 .
   [ Christian Göttsche ]
   * New upstream version 3.16.0 (Closes: #915301)
 .
   * d/patches: rebase and drop upstream applied ones
 - add new directive ProtectKernelLogs
 - drop NoNewPrivileges, which is actually not implied and
   might be needed for third party rotate scripts
   * d/copyright: add extra sections
 - add section for queue.h licensed under BSD-3-Clause
 - add section for build-aux/git-version-gen licensed under GPL-3+
   * d/control: bump to std version 4.5.0 (no further changes)
   * d/rules: fail on compiler warnings

Regards,

--
  Christian Göttsche

p.s.: the Lintian check package-does-not-install-examples is somewhat unstable,
when the override is removed it shows back up

Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Antoine Beaupré]

On 2020-02-18 22:30:59, Samuel Henrique wrote:
> Control: owner -1 !
>
> On Mon, 27 Jan 2020 at 13:41, Jason Pleau  wrote:
>>
>> I pushed what I had here: https://gitlab.com/jpleau/polybar/
>>
>> It's not targetting debian (simply because I'm using ubuntu these
>> days). Feel free to take whatever you find useful
>
> Thanks for that Jason, I pushed the current state of the packaging to salsa.
>
> I will be doing the upload the the NEW queue soon, I just want to do some
> extra checks and tests to confirm everything is ok.

I tried the package available here:

https://salsa.debian.org/debian/polybar

It works well! One unfortunate problem I have found, however, is that it
requires the siji font to work in its default configuration. That font
is not available in Debian right now (#894413) but worse, even if it
would be, it's a bitmap font which requires enabling those across the
board (`rm /etc/fonts/conf.d/70-no-bitmaps.conf`) which, in turns, means
that bitmap fonts *will* be used everywhere.

This is most notable when browsing GitHub in Firefox, as it will now
decide to use "Helvetica" which is shipped by the xfonts-75dpi package
(a dependency of xorg and task-desktop, of all things). This makes
things generally horrible for me, and I don't think it's a reasonable
expectation.

Note that there is a truetype version of the font in

https://github.com/fauno/siji/blob/master/ttf/siji.ttf

... but it doesn't display as well..

Also note that I previously mentioned the problems with that font in
this bug report...

a.

-- 
The most prudent course for any society is to start from the
assumption that the Internet should be fundamentally outside the
domain of capital.
- The Internet's Unholy Marriage to Capitalism

Bug#824649: ostree: document how to prepare and update a .deb-based system root

[Dan Nicholson]

On Mon, 5 Nov 2018 11:13:06 + Simon McVittie  wrote:
> On Sat, 03 Nov 2018 at 12:44:16 +0100, Felix Krull wrote:
> > what's the status on this? Is there anything else I can do or did you
just not
> > get around to it yet?
>
> Reviewing this is on my list, but it's a somewhat long list :-)
>
> (Because this involves new package names and the NEW queue, there's a
> strong incentive to get it right first time, rather than having more
> than one attempt.)

ostree-boot got in a while ago and it looks like you added the
documentation Felix started in
https://salsa.debian.org/debian/ostree/-/commits/debian/master/debian/ostree-boot-examples.
So, I think this can be closed now?

--
Dan

Bug#952958: rrdtool crashes after the DLA-2131-1 security update

[Utkarsh Gupta]

Hi all,

Thank you for reporting this.
This, indeed, was a regression and has been fixed in +deb8u2 now.

The announcement for the same could be found here[1].


Best,
Utkarsh
---
[1]: https://lists.debian.org/debian-lts-announce/2020/03/msg3.html

Bug#952792: closed by Ivo De Decker (remove chef)

[Antonio Terceiro]

Control: reopen -1

> Date: Sat, 29 Feb 2020 13:25:33 +
> From: Ivo De Decker 
> To: 952792-d...@bugs.debian.org
> Subject: remove chef
> Message-Id: 
> 
> Added removal hint for chef.

Hello,

I just noticed that I failed to check for reverse (build) dependencies.
So please also remove the following packages from testing:

foodcritic
ohai
ruby-cheffish
ruby-knife-acl
ruby-ridley

These are all part of the chef ecosystem, so we are not breaking
unrelated software.


signature.asc
Description: PGP signature

Bug#952998: weston: change dependency to libegl1-mesa by libegl1?

[Patrice Duroux]

Package: weston
Version: 8.0.0-1
Severity: wishlist

Dear Maintainer,

I think that libegl1-mesa is a transitional dummy package for some time. May be
it could be replaced by a non transitional one now which should be libegl1,
isn't it?

Thanks,
Patrice



-- 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)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: 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)
LSM: AppArmor: enabled

Versions of packages weston depends on:
ii  adduser 3.118
ii  libc6   2.29-10
ii  libcairo2   1.16.0-4
ii  libcolord2  1.4.4-1
ii  libdrm2 2.4.100-4
ii  libegl1 1.3.1-1
pn  libegl1-mesa | libegl1-x11  
ii  libevdev2   1.8.901+dfsg-1
ii  libgbm1 19.3.3-1
ii  libgles21.3.1-1
ii  libglib2.0-02.62.5-1
ii  libinput10  1.15.2-1
ii  libjpeg62-turbo 1:1.5.2-2+b1
ii  liblcms2-2  2.9-4
ii  libpam0g1.3.1-5
ii  libpango-1.0-0  1.42.4-8
ii  libpangocairo-1.0-0 1.42.4-8
ii  libpixman-1-0   0.36.0-1
ii  libpng16-16 1.6.37-2
ii  libsystemd0 244.3-1
ii  libwayland-client0  1.18.0-1
ii  libwayland-cursor0  1.18.0-1
ii  libwayland-egl1 1.18.0-1
ii  libwayland-server0  1.18.0-1
ii  libwebp60.6.1-2+b1
ii  libweston-8-0   8.0.0-1
ii  libxkbcommon0   0.10.0-1

Versions of packages weston recommends:
ii  libgl1-mesa-dri  19.3.3-1

weston suggests no packages.

-- no debconf information

Bug#950847: python-icecream needs new upstream for Python 3.8 support

[Inaki Malerba]

El 7/2/20 a las 12:37, Matthias Klose escribió:
> Package: src:python-icecream
> Version: 1.3.1-1
> Severity: serious
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: python3.8
> 
> python-icecream needs new upstream for Python 3.8 support. The tests fail.
> 
> upstream changelog:
> 
> 
>  v2.0.0
> 
> Added: Support for Python 3.8.
> Removed: Support for Python 3.4.
> Changed: Switched core AST parsing engine to Alex Hall's executing
>   (https://github.com/alexmojaki/executing). Huge thank you to Alex Hall.
> Changed: Whitespace in arguments is no longer collapsed. Indentation in
>   multiline arguments is now preserved.
> 
> 
> from https://github.com/gruns/icecream/archive/v2.0.0.tar.gz
> 

Hi !

I'm waiting for #951438 to get accepted in order to be able to package
the new version.

Abrazos

-- 
- ina



signature.asc
Description: OpenPGP digital signature

Bug#952952: RM: src:ipykernel-py2 -- RoM for Python 2 removal

[Gordon Ball]

On Mon, Mar 02, 2020 at 09:14:52AM -0500, Sandro Tosi wrote:
> > The src:ipykernel-py2 package provides python-ipykernel, which is to be
> > removed for the Python 2 removal transition.
> 
> Cc-ing Gordon explicitly: the last time we spoke, Gordon wanted to
> keep the python2 stack of ipython/ikernel/jupyther for people to still
> have a py2 infrastructure to run their notebooks. Is this changed? are
> we ready to remove them all?

Hi, and thanks for pinging me on this.

I had originally wanted to hang onto ipykernel-py2 on the basis that it
didn't add much to the dependency tree not in any case blocked by
ipython [0] and is _probably_ useful for a certain amount of legacy
analysis code.

However, keeping support for python2 stuff around when it's blocking the
wider py2removal transition is not really a hill I want to die on. Given
that this bug has been filed, and I'm not actually now using the python2
version myself, I'm inclined to just let the RM happen.

Gordon

[0]: ipykernel -> jupyter-client -> jupyter-core -> pyzmq can be dropped
together, I think all other dependencies are blocked on at least
something else.


> 
> Regards,
> -- 
> Sandro "morph" Tosi
> My website: http://sandrotosi.me/
> Me at Debian: http://wiki.debian.org/SandroTosi
> Twitter: https://twitter.com/sandrotosi

Bug#952952: RM: src:ipykernel-py2 -- RoM for Python 2 removal

[Scott Kitterman]

On Monday, March 2, 2020 9:14:52 AM EST Sandro Tosi wrote:
> > The src:ipykernel-py2 package provides python-ipykernel, which is to be
> > removed for the Python 2 removal transition.
> 
> Cc-ing Gordon explicitly: the last time we spoke, Gordon wanted to
> keep the python2 stack of ipython/ikernel/jupyther for people to still
> have a py2 infrastructure to run their notebooks. Is this changed? are
> we ready to remove them all?
> 
> Regards,

Personally, I think it should go, but I agree that's what Gordon said he 
wanted.  I've tagged the bug moreinfo so it won't be processed by the FTP Team 
while this is being sorted out.

Scott K

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

Bug#952996: RM: gle-graphics -- RoQA; Depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove gle-graphics. It depends on Qt4, which is now being removed. It 
can be reintroduced
when/if ported to Qt5.

Cheers,
Moritz

Bug#952997: debian-edu-config: pacparser being removed, please drop from debian-edu-config

[Scott Kitterman]

Package: debian-edu-config
Version: 2.11.14
Severity: important

Dear Maintainer,

The pacparser source package is unmaintained and RC buggy.  As a result,
I have asked to have it removed from Debian (Bug #952963).
debian-edu-config depends on libpacparser1.  It is the only rdepend.

If libpacparser1 is not important to debian-edu, please drop the depends
to the removal can proceed.  If it is important to debian-edu, please
take over maintenance of the package.

I can provide a debdiff to drop the python2 bits from the package.  I
was preparing an NMU to do so when I realized how hopelessly out of date
the packaging is (compat = 5).  It won't be long before it either has to
be removed anyway due to the package breaking or someone will have to
re-invest the time in seriously modernizing it.

If no one is interested (and there's no sign of it so far), I think it's
better to just remove it.

Please let me know your preference.  At some point we'll probably need
to go ahead with the rm of pacparser to keep the python2-rm process
moving.

Scott K

Bug#874901: [GLE-devel] Probable fix for qgle seg faults with latest ghostscript versions

[Moritz Mühlenhoff]

On Mon, Jan 20, 2020 at 08:29:16PM +0100, Moritz Mühlenhoff wrote:
> On Fri, Oct 11, 2019 at 11:12:31PM +0200, Moritz Mühlenhoff wrote:
> > On Fri, Sep 13, 2019 at 07:54:04PM +0200, Francesco Poli wrote:
> > > > Right now I see three possible "fixes" for the libgs problem:
> > > [...]
> > > > - fix the code, link to libgs during the build, as is done with all the
> > > >   other libraries qgle depends on. I do not understand why libgs is 
> > > > treated
> > > >   differently, there may be a reason, I just don't know. I think 
> > > > Laurence is
> > > >   working on that, but maybe somebody else working on gle can comment.
> > > 
> > > I think this is probably the best strategy, but, as I said, let's hear
> > > what upstream developers have to say on this.
> > > 
> > > In the meanwhile, I would like to suggest once more that you upload the
> > > fixes for the serious bug (Qt5 porting) and for the other bug (qgle
> > > segfault)!
> > 
> > Agreed, it would be good if we could move forward with the Qt5 change,
> > we've closing in on the Qt4 removal and this is one of the ~ three dozen
> > packages left.
> 
> Status update: Qt4 has now been droppped from testing, qt4 will be removed
> from unstable by end of February (along with the remaining rdeps (currently 
> 15)).

I've now filed a removal bug for gle-graphics. It can be re-introduced when
a stable Qt5 port is available, there's plenty of time until the next freeze.

Cheers,
Moritz

Bug#940093: radicale 1.1.1: --export-storage option missing

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, 2020-03-02 at 11:49 -0700, Sean Whitton wrote:
> > Hi Jonas, I got that issue earlier, and to be honest I kind of side with
> > Fabrice here, and I find it bit sad Buster was released with that kind of
> > behavior.
> 
> It's definitely undesirable, but unfortunately no-one submitted a patch
> in time for the buster release.

Yeah, I can definitely understand that, and we're all a bit overwhelmed. But
having the severity raised before the update could have helped on this by
raising awareness. Maybe it would have been possible to backport the --export-
storage option to a point release or something.

> IMO it's better to have the ability to do this manual upgrade than not
> to have radicale in buster/bullseye at all -- or do you have a third
> option in mind?

Maybe it's pointless at that point, but as above: provide a way to do the
export from Stretch, or maybe ship an --export-storage stuff in the Buster
package.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5dW8AACgkQ3rYcyPpX
RFvm1AgAgYGbNrrcMH5S21GRH22F7NTMKK3uf7j+JGo+8pOJE3r0i9xFErAusp5K
UY1TgkjXFlxyTJfLb2cZjDrgi8V9/6R4pJ2fDAZNMLwnEwNckUg34mYOh+cxBKri
hGGQcK8SjwNNkiDbx8c3IqKa6hmyRJZmal21sAH/NYVUZz565t3CplgP44aIkf4H
o3OxgT3Kv2o4yAG7gSh+q/KJ76yn4Nf4gjSIPjK0VDjDqYY6E5PDC03CGp8xH5hp
ZIEq2ZsBirH63Ay18ZhHnGZcAcKAV8k+Q3j1Pnz0qNA6qiO4eMSsWBW5v9napmOp
6XV/Xlzc7WVZNB7q5rpg/j/Klw/sVA==
=Smdv
-END PGP SIGNATURE-

Bug#875177: [scap-workbench] Future Qt4 removal from Buster

[Moritz Mühlenhoff]

On Mon, Jan 20, 2020 at 08:37:21PM +0100, Moritz Mühlenhoff wrote:
> On Fri, Nov 22, 2019 at 11:49:29PM +0100, Moritz Mühlenhoff wrote:
> > On Thu, Aug 22, 2019 at 09:04:07AM +0200, Frank Lin Piat wrote:
> > > Il will upgrade that package.
> > > 
> > > Thank you Moritz
> > 
> > Any progress? :-)
> 
> Status update: Qt4 has now been droppped from testing, qt4 will be removed
> from unstable by end of February (along with the remaining rdeps (currently 
> 15)).

I've now filed an RM bug. scap-workbench can be re-introduced with
Qt5-compatible version, there's plenty of time till the bullseye freeze.

Cheers,
Moritz

Bug#952993: [Pkg-javascript-devel] Bug#952993: Uninstallable: node-acorn (<< 6.0~) not available in unstable anymore (breaks e.g. jekyll builds)

[Pirate Praveen]

On 2020, മാർച്ച് 3 12:01:08 AM IST, Daniel Leidert  wrote:
>Package: webpack
>Version: 4.7.0-3
>Severity: grave
>
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA512
>
>I received a report about jekyll having unsatisfiable build
>dependencies.
>webpack in unstable requires node-acorn >=5, <<6. But the package
>actually
>is not available anymore in unstable. I guess this is the result of
>acorn
>having been updated to version 6.2.1 and now being some kind of a
>bundle.
>
>Please have a look.

Yes, acorn 6 broke webpack. Hopefully this will be fixed when webpack 4.30 can 
be uploaded to unstable. I'd have preferred acorn 6 upload waited for webpack 
4.30 and I had documented it and communicated it in js-team many times, but 
acorn 6 was uploaded to unstable anyway.

>Regards, Daniel
>
>
>- -- System Information:
>Debian Release: bullseye/sid
>  APT prefers unstable
>APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
>'experimental')
>Architecture: amd64 (x86_64)
>
>Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
>Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
>LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
>Shell: /bin/sh linked to /usr/bin/dash
>Init: systemd (via /run/systemd/system)
>
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5dUOwACgkQS80FZ8KW
>0F3Jaw//ZRNwZGXCWncX0m1FPaHWTQbXI6Lo6NRGT13QPKITrHBEB94jyNbTj4AB
>+M0SKVRL1HbYoyD390hURKvCkFa0OlctMeCb0uN0Al7/TLZOaxuoyhFP7tOgK8oD
>7zPAiTslNPa5WTs3J6jPkM8EG+WzA6RvmUhRYDSVe7GcrVZNtwDsjmEfpbiCFc93
>xbfAUWfQhipLDvu0ySZri7IVAT0n9PZzwuDgb8eUZ9FbUMnj6bOMAJIri4qQJkPe
>DSM7uwPNKBLX9rnr9BSK4pX2yssZLt+LYE/dS6qyn0eOToa5JbVOa6hWyawtfxTc
>9pai4FwUiFABfrDNYcw+0CNrBF+Pf5LH6YViiWNmARAY4J4oohISpZDX62OC9S/N
>zzfWchekKiSWwL1u/RTB6NTLZCAN289xJtAztUhl6bfAKlRcQnFQiZX5tktvCsLT
>ewKoiO2IfiLF+ES0R1DTu0cBYwfasBDQTTLbx+Vjuhly+TDqpU4+N4PmF8JfOk7L
>FNeZj2dQcrxKrGS9ef9fVhg9ZMkAYRLSMbhrdQ4dJDUXrNrmmVibdolll4HcDKOQ
>oQrGHzN162lXon4tV83dYEE+yBrhGjw/OUi299/SPF+zY/1rebtKVlqqjqbpZYiL
>DEIN2/icKtg1AML4+1e7Si7SNb7pdgMwLjFU+091bn8St6TIoSI=
>=eXe+
>-END PGP SIGNATURE-
>
>-- 
>Pkg-javascript-devel mailing list
>pkg-javascript-de...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#952995: RM: scap-workbench -- RoQA; Depends on Qt4

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove scap-workbench. It depends on Qt4, which is now being removed. It 
can be reintroduced
when/if ported to Qt5.

Cheers,
Moritz

Bug#935455: [Python-modules-team] Bug#935455: Updated version of dask

[Emmanuel Arias]

El lun., 2 de mar. de 2020 a la(s) 15:27, Diane Trout (di...@ghic.org) escribió:
>
> On Sun, 2020-03-01 at 23:03 -0300, Emmanuel Arias wrote:
> > Hi Diane,
> >
> > On 01/03/2020 22:31, Diane Trout wrote:
> > > Hi,
> > >
> > > I updated the version of dask to 2.11.0 does that help with this
> > > bug?
> > You should run autopkgtest to know if that fix the bug :)
>
> I made ci.debian.org run the tests and I don't see any dask failures
> now. However there's still two failures but they seem related to HTTPS
> and not dask.
>
> https://ci.debian.net/data/autopkgtest/unstable/amd64/p/python-xarray/4425021/log.gz
>
> Do you want to close this ticket or transfer it back to xarray?

Seems that now the problem is on xarray. IMO that est tha try to make
a request must be skipped

Bug#947070: maven: jgitver-maven-plugin doesn't work anymore

[Vincent Smeets]

fixed 947070 3.6.3-1
stop

As already noted, this bug was already fixed in the upstream version 3.6.3

Op vr 20 dec. 2019 om 13:42 schreef Vincent Smeets <
vincent.vsme...@gmail.com>:

> Package: maven
> Version: 3.6.2-1
> Severity: normal
> Tags: upstream
>
> The jgitver-maven-plugin doesn't work anymore with the maven version
> 3.6.2. It did work with the version 3.6.0. It also should work again
> with maven version 3.6.3.
>
> I have added an attachement that includes a minimal maven project with
> the jgitver-maven-plugin. You can use it to test the different maven
> versions.
>
> The problem was already tracked by
> https://github.com/jgitver/jgitver-maven-plugin/issues/119 There you can
> read that this issue is solved by maven version 3.6.3.
>
> Regards,
> Vincent
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.3.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=nl_NL.utf8, LC_CTYPE=nl_NL.utf8 (charmap=UTF-8),
> LANGUAGE=nl_NL.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages maven depends on:
> ii  default-jre-headless [java7-runtime-headless] 2:1.11-72
> ii  libjansi-java 1.18-1
> ii  libmaven3-core-java   3.6.2-1
> ii  libwagon-file-java3.3.3-1
> ii  libwagon-http-shaded-java 3.3.3-1
> ii  openjdk-11-jre-headless [java7-runtime-headless]  11.0.6+7-1
>
> maven recommends no packages.
>
> maven suggests no packages.
>
> -- no debconf information
>

Bug#952994: cups-browsed: An extra *cupsFilter2 line generated in the PPD

[Brian Potkin]

Package: cups-browsed
Version: 1.27.2-1
Severity: normal
Tags: upstream



I have an IPP ENVY 4500 on the network, I thought cups-browsed would
generate a PPD identical to that produced by

  lpadmin -p 4500 -v  -E -m driverless:

But, when the computer is rebooted or cups-browsed restarted, at the
end of the file there is an extra line:

  *cupsFilter2: "application/vnd.cups-pdf application/pdf 0 -"

PDF is not a PDL for the ENVY.

Regards,

Brian.

Bug#940093: radicale 1.1.1: --export-storage option missing

[Sean Whitton]

Hello Yves-Alexis,

On Mon 02 Mar 2020 at 07:37PM +01, Yves-Alexis Perez wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> control: severity -1 grave
> On Thu, 12 Sep 2019 12:47:57 +0200 Jonas Smedegaard  wrote:
>>
>> Sorry, which _Debian_ issues are left here which I missed?
>>
>> If you tried b) and it failed, then please provide more details what
>> exactly you did and how it failed.
>>
>>
> Hi Jonas, I got that issue earlier, and to be honest I kind of side with
> Fabrice here, and I find it bit sad Buster was released with that kind of
> behavior.

It's definitely undesirable, but unfortunately no-one submitted a patch
in time for the buster release.

IMO it's better to have the ability to do this manual upgrade than not
to have radicale in buster/bullseye at all -- or do you have a third
option in mind?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952951: botan: Replace PKCS11 headers provided by OASIS

[Sean Whitton]

Hello,

On Mon 02 Mar 2020 at 06:39PM +01, László Böszörményi (GCS) wrote:

> Control: tags -1 +moreinfo
>
> On Mon, Mar 2, 2020 at 10:27 AM Alvin Chen  wrote:
>> Since headers provided by OASIS PKCS11 are not-exactly free license
>> (they do not allow modification),
>  Do you mention the " However, this document itself may not be
> modified in any way, including by
>  removing the copyright notice or references to OASIS, [...]" part? As
> I read it that references the copyright text itself and _not_ the
> actual code.
>
>> You can use an alternative header like p11-kit which is licensed under
>> a more liberal license.
>>
>> https://sources.debian.org/src/botan/2.12.1-2/src/lib/prov/pkcs11/pkcs11.h/
>  It's up to Jack, who develops Botan. I'm still not sure this text
> snippet makes the code non-modifiable. But let me ask our FTP Masters
> and Jack himself how to interpret it.

Can you give a link to the file in question please?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Marvin Renich]

[P.S. I'm subscribed to the bug; you may drop me from explicit To or CC.]

* Joerg Dorchain  [200302 12:18]:
> Then please include
> https://github.com/neomutt/neomutt/commit/f197ab93c8436a39fc511f396acde24f90389f20?diff=unified
> 
> in a new package, maybe with a Debian-specific change of the abort_backspace
> default to false.

I'm not a DD or DM and have no upload rights, and don't have the time at
the moment to prepare and test an upload properly (which is more than
just applying the patch and building a package).  I do appreciate the
people who have in the past and are currently working on the Debian
packaging of neomutt.

Looking at the github issue, it looks like backspace is supposed to
cancel the command, and the behavior that the bug reporter wants is to
remain on the empty command line and ignore the backspace.  But neither
is the behavior I am seeing.

First, the behavior in the github issue is specific to editing email
headers while composing a message.  For me, that specific case seems to
abort the edit, and it seems to be an intentional change.  I don't have
a strong opinion about the github issue, but it is definitely not the
issue in this Debian bug, although the code that implemented the
intentional change may be the cause of this Debian bug.

The situation that I feel is a grave bug is when in the message index,
using certain commands that require more information (save-message is
one such command), pressing backspace when the prompt is empty (only the
":" showing) causes the _default action_ to occur (e.g. save to the
folder specified by the save-hook for that message) rather than aborting
the command.

As long as backspace does not have a binding after the prompt is
aborted (e.g. in the index), I can probably live with either the abort
or ignore behavior, but activating the default action is highly broken.

I cannot tell whether the patch referenced in the previous message will
fix this Debian bug.  If the cause of the Debian bug has to do with
mutt_enter_string_full being called for both completing a command in the
index and for editing message headers, but the result of the function is
being handled differently in the two cases, then perhaps the patch will
allow the bug to be masked by unsetting the option, but with the option
set the bug will still be present.  I can't tell without looking at the
rest of the code.

I don't have a github account, and do not wish to get one for this.
Will someone (Debian maintainer for neomutt, or someone else interested
in this bug) please file this with upstream as a separate bug, pointing
out that the other github issue is not the same as this bug, even though
some of the same code may be involved.

Thanks...Marvin

Bug#940093: radicale 1.1.1: --export-storage option missing

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: severity -1 grave
On Thu, 12 Sep 2019 12:47:57 +0200 Jonas Smedegaard  wrote:
> 
> Sorry, which _Debian_ issues are left here which I missed?
> 
> If you tried b) and it failed, then please provide more details what 
> exactly you did and how it failed.
> 
> 
Hi Jonas, I got that issue earlier, and to be honest I kind of side with
Fabrice here, and I find it bit sad Buster was released with that kind of
behavior.

NEWS.Debian says (you really need to have apt-listchanges installed to see
that before installing, but it won't save you anyway):

>   * Radicale 2.x has several incompatible changes from Radicale 1.x.
> 
> Most importantly, data stored with Radicale 1.x is unreadable,
> and need to be exported using Radicale 1.1.6 before switching to
> Radicale 2.x.
> A suitable debian package can be temporarily installed from
> ;,
> which tries backup to 
> for manual restore to .
> More information at ;.
> 
>  -- Jonas Smedegaard   Thu, 07 Feb 2019 02:28:00 +0100

So the advice here is to actually install a *snapshot* package, downgrading
from the 2.x package you're about to install, in order to actually export the
package, before upgrading again and somehow (by, I assume, following the 1to2
page) importing it again.

I know you're a volunteer and you do a lot of work, so it's not really against
you Jonas. But I consider this kind of bug RC (and thus raising the severity).
We ought to have a migration path *in Debian*.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5dUnAACgkQ3rYcyPpX
RFu1pQf/boQlejO8Yi8WLHpZcNOFZWAKqsrW0HnZTKAnqwej/IDEobte2Tk6puwc
pHT1qqGqQiOvACKWW5Ubh2z7XAOerFmibN9e4IDt2vBa2JWbGFH+wX1F+fwM/XPz
f2GgovCUuwxsjB/u5MFhYyCqSnBmpTPbhz3qV3Id9LpFxX0uH/rBPO1gaT9Jvvhe
BrpONqearfiCn/eEnOGSNClCVNjo+dhlrOGNSHoASep/sgfl61QeBwe6XcvXEI55
UIfb8B++0HeW9wVL278U7UrcOVyLDUwzKD0DmFmsB/MPPDrKvX3aZrCHsFOtHogR
w6cLi7tARApYNAwQZPX92dreWKTi3Q==
=5kjA
-END PGP SIGNATURE-

Bug#952993: Uninstallable: node-acorn (<< 6.0~) not available in unstable anymore (breaks e.g. jekyll builds)

[Daniel Leidert]

Package: webpack
Version: 4.7.0-3
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I received a report about jekyll having unsatisfiable build dependencies.
webpack in unstable requires node-acorn >=5, <<6. But the package actually
is not available anymore in unstable. I guess this is the result of acorn
having been updated to version 6.2.1 and now being some kind of a bundle.

Please have a look.

Regards, Daniel


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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5dUOwACgkQS80FZ8KW
0F3Jaw//ZRNwZGXCWncX0m1FPaHWTQbXI6Lo6NRGT13QPKITrHBEB94jyNbTj4AB
+M0SKVRL1HbYoyD390hURKvCkFa0OlctMeCb0uN0Al7/TLZOaxuoyhFP7tOgK8oD
7zPAiTslNPa5WTs3J6jPkM8EG+WzA6RvmUhRYDSVe7GcrVZNtwDsjmEfpbiCFc93
xbfAUWfQhipLDvu0ySZri7IVAT0n9PZzwuDgb8eUZ9FbUMnj6bOMAJIri4qQJkPe
DSM7uwPNKBLX9rnr9BSK4pX2yssZLt+LYE/dS6qyn0eOToa5JbVOa6hWyawtfxTc
9pai4FwUiFABfrDNYcw+0CNrBF+Pf5LH6YViiWNmARAY4J4oohISpZDX62OC9S/N
zzfWchekKiSWwL1u/RTB6NTLZCAN289xJtAztUhl6bfAKlRcQnFQiZX5tktvCsLT
ewKoiO2IfiLF+ES0R1DTu0cBYwfasBDQTTLbx+Vjuhly+TDqpU4+N4PmF8JfOk7L
FNeZj2dQcrxKrGS9ef9fVhg9ZMkAYRLSMbhrdQ4dJDUXrNrmmVibdolll4HcDKOQ
oQrGHzN162lXon4tV83dYEE+yBrhGjw/OUi299/SPF+zY/1rebtKVlqqjqbpZYiL
DEIN2/icKtg1AML4+1e7Si7SNb7pdgMwLjFU+091bn8St6TIoSI=
=eXe+
-END PGP SIGNATURE-

Bug#952960: buster-pu: package ruby-factory-girl-rails/4.7.0-1+deb10u1

[Daniel Leidert]

Package: release.debian.org
Followup-For: Bug #952960

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've uploaded the fix to unstable and updated the diff (Vcs* fields changed,
see attached).

Regards, Daniel


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

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl5dSZsACgkQS80FZ8KW
0F3fYxAA2PgNkbxWxv2bw6QuNzm6Jowr/D/NLxqhHaW0gfrd0OhhisGgV1UU6v4i
AcIQIOlnAv/KB0EBXZ8wv52drv7SMeZ4MQ2z/gj1r9quSDFLEyBMBexIa5EiiLDN
g5Ci5QzLWialsit+r4LPQ54wJNd3jVTcNqMhbsMvUKSEaqL+7ltzqWKAKq5LVTVY
Ktp1CTePW0OyGfEmJn0uTiCx8tnHjNHlR+ZaRHO3YSFIhmRLq2LEXqNiJ4d6HIq9
dvwlHNx9HuRq96+Gidm/7/f0iQi0VqNbkwHBA0Irb/9BjVp2/aVtIzymFsMRlaub
AH9MgM6V0LWdSKhKs6MrMndJjS4C+xXSzwpPnT2LdjWngdZ5SziNYOu4giSGrIl8
SsAeEpX+mgZ4iOHG9BKP59br730icIkwi/quC/5dnkVKQB6iM2OlMQvFU800E7Ji
O5SEGTk2w2yuPkpZEF4bNqg5TebwOyzHdu8/gc20LBfg0dy3Fi8PsohXMLCJNk3E
9dMK29Su/1JCHn6G1Ie+a8nSlFGEPcRiOYEKXTW0HKvilIUqHMGQS+H17j43Ww3w
6SlCsZ7cnUbq56u1ISz8aUoVti86DtfGGDxl9aAsAJMAeIWPcMgzf108vOMxRqws
sRk09P73N8Y328xlJpKRlqS8g9ACcZDYemTV4EP6FCkFjSejV7Y=
=OeyB
-END PGP SIGNATURE-
diff -Nru ruby-factory-girl-rails-4.7.0/debian/changelog 
ruby-factory-girl-rails-4.7.0/debian/changelog
--- ruby-factory-girl-rails-4.7.0/debian/changelog  2016-09-15 
12:38:40.0 +0200
+++ ruby-factory-girl-rails-4.7.0/debian/changelog  2020-03-02 
18:54:34.0 +0100
@@ -1,3 +1,11 @@
+ruby-factory-girl-rails (4.7.0-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * d/control (Vcs-Browser, Vcs-Git): Use salsa.d.o.
+  * d/rules: Don't install/ship generic files in /usr/bin/ (closes: #910930).
+
+ -- Daniel Leidert   Mon, 02 Mar 2020 18:54:34 +0100
+
 ruby-factory-girl-rails (4.7.0-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru ruby-factory-girl-rails-4.7.0/debian/control 
ruby-factory-girl-rails-4.7.0/debian/control
--- ruby-factory-girl-rails-4.7.0/debian/control2016-09-15 
12:37:46.0 +0200
+++ ruby-factory-girl-rails-4.7.0/debian/control2020-03-02 
18:54:34.0 +0100
@@ -8,8 +8,8 @@
ruby-factory-girl (>= 4.7~),
ruby-railties (>= 3.0~),
 Standards-Version: 3.9.8
-Vcs-Git: 
https://anonscm.debian.org/git/pkg-ruby-extras/ruby-factory-girl-rails.git
-Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-factory-girl-rails.git
+Vcs-Git: https://salsa.debian.org/ruby-team/ruby-factory-girl-rails.git -b 
debian/buster
+Vcs-Browser: https://salsa.debian.org/ruby-team/ruby-factory-girl-rails
 Homepage: http://github.com/thoughtbot/factory_girl_rails
 XS-Ruby-Versions: all
 
diff -Nru ruby-factory-girl-rails-4.7.0/debian/rules 
ruby-factory-girl-rails-4.7.0/debian/rules
--- ruby-factory-girl-rails-4.7.0/debian/rules  2016-09-15 12:32:19.0 
+0200
+++ ruby-factory-girl-rails-4.7.0/debian/rules  2020-03-02 18:54:34.0 
+0100
@@ -4,3 +4,7 @@
 
 %:
dh $@ --buildsystem=ruby --with ruby
+
+override_dh_install:
+   dh_install
+   $(RM) -rf $(CURDIR)/debian/ruby-factory-girl-rails/usr/bin/

Bug#950716: transition: ruby2.7

[Lucas Kanashiro]

Hi Graham,

On 02/03/2020 08:35, Graham Inggs wrote:
> Hi Lucas
>
> I notice kamailio and klayout still appear red in the Debian tracker
> [1], but went green in Ubuntu [2].
>
> Do you have any ideas?  Do we miss something in Debian?

Since we basically have the same version in Debian and Ubuntu I believe
the only difference is that in Ubuntu we already have Ruby 2.7 as the
only default, in Debian it is just in experimental. So when we upload
version 1:2.7~0 to unstable they should get green as in Ubuntu.

-- 
Lucas Kanashiro

Bug#952991: i3: New upstream 4.18 version

[Daniel Cordeiro]

Package: i3
Version: 4.17.1-1
Severity: wishlist

Dear Maintainer,

There is a new stable release of i3 (4.18) released 2020-02-17.
The release notes can be found at 
[https://i3wm.org/downloads/RELEASE-NOTES-4.18.txt].


Please package the new version. :)


Cheers,
Daniel


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
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=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages i3 depends on:
ii  i3-wm  4.17.1-1

Versions of packages i3 recommends:
ii  dunst   1.4.1-1
ii  i3lock  2.11.1-1
ii  i3status2.13-2
ii  suckless-tools  44-1

i3 suggests no packages.

-- no debconf information

Bug#952992: linux-image-4.19.0-8-amd64: X not starting after upgrade (failed to initialize surface manager)

[lenscas]

Package: src:linux
Version: 4.19.98-1
Severity: important

Dear Maintainer,

After running apt update;apt upgrade; and rebooting, X didn't start anymore.
Selecting the previous kernel using advanced options during boot allows me to 
get X working again, but only for that kernel. 


-- Package-specific info:
** Version:
Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1 (2020-01-26)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 
root=UUID=b6137531-28e4-4162-abb0-bfd9516ff67f ro quiet

** Not tainted

** Kernel log:
[4.914874] EDAC sbridge: Seeking for: PCI ID 8086:0ea0
[4.914885] EDAC sbridge: Seeking for: PCI ID 8086:0ea0
[4.914890] EDAC sbridge: Seeking for: PCI ID 8086:0e60
[4.914896] EDAC sbridge: Seeking for: PCI ID 8086:0ea8
[4.914901] EDAC sbridge: Seeking for: PCI ID 8086:0ea8
[4.914903] EDAC sbridge: Seeking for: PCI ID 8086:0e71
[4.914908] EDAC sbridge: Seeking for: PCI ID 8086:0e71
[4.914910] EDAC sbridge: Seeking for: PCI ID 8086:0eaa
[4.914915] EDAC sbridge: Seeking for: PCI ID 8086:0eaa
[4.914917] EDAC sbridge: Seeking for: PCI ID 8086:0eab
[4.914922] EDAC sbridge: Seeking for: PCI ID 8086:0eab
[4.914924] EDAC sbridge: Seeking for: PCI ID 8086:0eac
[4.914929] EDAC sbridge: Seeking for: PCI ID 8086:0eac
[4.914931] EDAC sbridge: Seeking for: PCI ID 8086:0ead
[4.914936] EDAC sbridge: Seeking for: PCI ID 8086:0ead
[4.914938] EDAC sbridge: Seeking for: PCI ID 8086:0e68
[4.914943] EDAC sbridge: Seeking for: PCI ID 8086:0e79
[4.914949] EDAC sbridge: Seeking for: PCI ID 8086:0e6a
[4.914955] EDAC sbridge: Seeking for: PCI ID 8086:0e6b
[4.914961] EDAC sbridge: Seeking for: PCI ID 8086:0e6c
[4.914967] EDAC sbridge: Seeking for: PCI ID 8086:0e6d
[4.914973] EDAC sbridge: Seeking for: PCI ID 8086:0eb8
[4.914979] EDAC sbridge: Seeking for: PCI ID 8086:0ebc
[4.914985] EDAC sbridge: Seeking for: PCI ID 8086:0ec8
[4.914990] EDAC sbridge: Seeking for: PCI ID 8086:0ec8
[4.914991] EDAC sbridge: Seeking for: PCI ID 8086:0ec9
[4.914998] EDAC sbridge: Seeking for: PCI ID 8086:0ec9
[4.914998] EDAC sbridge: Seeking for: PCI ID 8086:0eca
[4.915005] EDAC sbridge: Seeking for: PCI ID 8086:0eca
[4.915026] EDAC sbridge: CPU SrcID #0, Ha #0, Channel #0 has DIMMs, but ECC 
is disabled
[4.915076] EDAC sbridge: Couldn't find mci handler
[4.915105] EDAC sbridge: Failed to register device with error -19.
[4.983003] EDAC sbridge: Seeking for: PCI ID 8086:0ea0
[4.983025] EDAC sbridge: Seeking for: PCI ID 8086:0ea0
[4.983034] EDAC sbridge: Seeking for: PCI ID 8086:0e60
[4.983048] EDAC sbridge: Seeking for: PCI ID 8086:0ea8
[4.983055] EDAC sbridge: Seeking for: PCI ID 8086:0ea8
[4.983058] EDAC sbridge: Seeking for: PCI ID 8086:0e71
[4.983065] EDAC sbridge: Seeking for: PCI ID 8086:0e71
[4.983068] EDAC sbridge: Seeking for: PCI ID 8086:0eaa
[4.983075] EDAC sbridge: Seeking for: PCI ID 8086:0eaa
[4.983078] EDAC sbridge: Seeking for: PCI ID 8086:0eab
[4.983085] EDAC sbridge: Seeking for: PCI ID 8086:0eab
[4.983088] EDAC sbridge: Seeking for: PCI ID 8086:0eac
[4.983095] EDAC sbridge: Seeking for: PCI ID 8086:0eac
[4.983100] EDAC sbridge: Seeking for: PCI ID 8086:0ead
[4.983107] EDAC sbridge: Seeking for: PCI ID 8086:0ead
[4.983110] EDAC sbridge: Seeking for: PCI ID 8086:0e68
[4.983119] EDAC sbridge: Seeking for: PCI ID 8086:0e79
[4.983127] EDAC sbridge: Seeking for: PCI ID 8086:0e6a
[4.983136] EDAC sbridge: Seeking for: PCI ID 8086:0e6b
[4.983145] EDAC sbridge: Seeking for: PCI ID 8086:0e6c
[4.983153] EDAC sbridge: Seeking for: PCI ID 8086:0e6d
[4.983162] EDAC sbridge: Seeking for: PCI ID 8086:0eb8
[4.983170] EDAC sbridge: Seeking for: PCI ID 8086:0ebc
[4.983179] EDAC sbridge: Seeking for: PCI ID 8086:0ec8
[4.983187] EDAC sbridge: Seeking for: PCI ID 8086:0ec8
[4.983189] EDAC sbridge: Seeking for: PCI ID 8086:0ec9
[4.983198] EDAC sbridge: Seeking for: PCI ID 8086:0ec9
[4.983199] EDAC sbridge: Seeking for: PCI ID 8086:0eca
[4.983208] EDAC sbridge: Seeking for: PCI ID 8086:0eca
[4.983238] EDAC sbridge: CPU SrcID #0, Ha #0, Channel #0 has DIMMs, but ECC 
is disabled
[4.983310] EDAC sbridge: Couldn't find mci handler
[4.983351] EDAC sbridge: Failed to register device with error -19.
[5.042723] EDAC sbridge: Seeking for: PCI ID 8086:0ea0
[5.042728] EDAC sbridge: Seeking for: PCI ID 8086:0ea0
[5.042730] EDAC sbridge: Seeking for: PCI ID 8086:0e60
[5.042734] EDAC sbridge: Seeking for: PCI ID 8086:0ea8
[5.042736] EDAC sbridge: Seeking for: PCI ID 8086:0ea8
[5.042738] EDAC sbridge: Seeking for: PCI ID 8086:0e71
[5.042741] EDAC sbridge: Seeking for: PCI ID 8086:0e71
[5.042742] EDAC sbridge: Seeking for: PCI ID 8086:0eaa
[5.042745] EDAC sbridge: Seeking for: PCI ID 8086:0eaa
[  

Bug#952951: botan: Replace PKCS11 headers provided by OASIS

[GCS]

Control: tags -1 +moreinfo

On Mon, Mar 2, 2020 at 10:27 AM Alvin Chen  wrote:
> Since headers provided by OASIS PKCS11 are not-exactly free license
> (they do not allow modification),
 Do you mention the " However, this document itself may not be
modified in any way, including by
 removing the copyright notice or references to OASIS, [...]" part? As
I read it that references the copyright text itself and _not_ the
actual code.

> You can use an alternative header like p11-kit which is licensed under
> a more liberal license.
>
> https://sources.debian.org/src/botan/2.12.1-2/src/lib/prov/pkcs11/pkcs11.h/
 It's up to Jack, who develops Botan. I'm still not sure this text
snippet makes the code non-modifiable. But let me ask our FTP Masters
and Jack himself how to interpret it.

Thanks,
Laszlo/GCS

Bug#952954: ITP: fonts-jetbrains-mono -- free and open-source typeface for developers

[Romain Porte]

Hi,

Le 02/03/2020 à 11:31, Adam Borowski a écrit :
>> This is my very first debian package, I am looking for a sponsor to get
>> through this first interaction with the Debian project. In the medium
>> term, I am interrested in becoming a Debian packager so that there is no
>> need to go on the sponsorship way each time I want to contribute.
> The Debian Fonts Team would be glad to have you among us.

Not that I am especially font-centric, but I see this as an easy entry
to the Debian packaging system without having to deal with compilation
or architectures. Just installing files may be a nice first step.

>> I will try to put this package on mentors.debian.net in the coming days
>> when it is finalized.
> I'd be happy to review it.  I for one especially enjoy new monospaced fonts.

So, I have published the package to mentors.debian.net but it has not
sent me a feedback email yet. The file
fonts-jetbrains-mono_1.0.3_amd64.mentors.upload contains the following
output repeated multiple times:

Successfully uploaded fonts-jetbrains-mono_1.0.3.dsc to
mentors.debian.net for mentors.
Successfully uploaded fonts-jetbrains-mono_1.0.3.tar.xz to
mentors.debian.net for mentors.
Successfully uploaded fonts-jetbrains-mono_1.0.3_all.deb to
mentors.debian.net for mentors.
Successfully uploaded fonts-jetbrains-mono_1.0.3_amd64.buildinfo to
mentors.debian.net for mentors.
Successfully uploaded fonts-jetbrains-mono_1.0.3_amd64.changes to
mentors.debian.net for mentors.

As it is not clear to me why the package does not appear in "My pakages"
nor the global package list, I propose to start the review using the
following files that I host on a personal server:

https://microjoe.org/fonts-jetbrains-mono_1.0.3.tar.xz
https://microjoe.org/fonts-jetbrains-mono_1.0.3.orig.tar.gz

These were manually scp'ed to the server, so many files are missing;
probably the signature stuff, I have reworked my OpenPGP key to include
my current From: address in a new uid). Maybe I can send you the
fonts-jetbrains-mono_1.0.3.dsc as well if you can import my just-updated
key from SKS servers that should contain the correct identities.

Please let me know if anything is missing (should we add mentors list in
CC? stop using this bug for exchanging?), as I am quite new to all of
this despite trying hard to comply to the wiki guides.

Ciao,

Romain.

Bug#940951: Upstream version (and ideally commit) which fixed CVE-2018-7587?

[Andreas Tille]

On Mon, Mar 02, 2020 at 03:43:16PM +0100, Salvatore Bonaccorso wrote:
> Hi Andreas,
> 
> On Mon, Mar 02, 2020 at 01:45:04PM +, Debian Bug Tracking System wrote:
> > Hello Andreas,
> > 
> > I think I've fixed these bugs indeed, a few months ago.
> > 
> > Regards,
> > 
> > David.
> > 
> > PS : I'm sorry but I don't write Changelog for CImg anymore. Not
> > that I don't maintain it, but it write my changes directly in the
> > Changelog of the G'MIC project.
> 
> So this means 2.8.4 upstream contains the fix for CVE-2018-7587, any
> pointers to the upstream commit which fixed the issue, was it fixed
> before 2.8.4?
> 
> Many thanks in advance,

I understood David that this was fixed even before.  He has not pointed
to any specific commit.

Kind regards

 Andreas. 

-- 
http://fam-tille.de

Bug#952989: libpam-mount: Attempting to mount an SSHFS folder as home havgs forever

[Michel Le Bihan]

Source: libpam-mount
Version: 2.16-10
Severity: important

With pam-mount configuerd to:
```


```
login hangs forever.



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (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_WARN
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#952990: pmemkv: please make the build reproducible

[Chris Lamb]

forwarded 952990 https://github.com/pmem/pmemkv/pull/615
thanks

I've forwarded this upstream here:

  https://github.com/pmem/pmemkv/pull/615


Regards,

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

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Joerg Dorchain]

On Mon, Mar 02, 2020 at 11:40:47AM -0500, Marvin Renich wrote:
[...]
> 
> Here is my rationale for severity grave:
[...]

Then please include
https://github.com/neomutt/neomutt/commit/f197ab93c8436a39fc511f396acde24f90389f20?diff=unified

in a new package, maybe with a Debian-specific change of the abort_backspace
default to false.

Bye,

Joe "ceterum censeo" rg


signature.asc
Description: PGP signature

Bug#952990: pmemkv: please make the build reproducible

[Chris Lamb]

Source: pmemkv
Version: 1.1-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
pmemkv could not be built reproducibly.

This is because, whilst it used the date in manpages from
SOURCE_DATE_EPOCH [1] (ie. the `dt` variable), it used the current
build year when templating the `year` variable.

Patch attached.

 [0] https://reproducible-builds.org/
 [1] https://reproducible-builds.org/docs/source-date-epoch/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/utils/md2man/md2man.sh2020-03-02 08:33:26.468163145 -0800
--- b/utils/md2man/md2man.sh2020-03-02 09:05:23.560324541 -0800
@@ -56,6 +56,7 @@
 secondary_title=`sed -n 's/^secondary_title:\ *\(.*\)$/\1/p' $filename`
 
 dt="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" +%F)"
+year="$(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" +%Y)"
 # since genereted docs are not kept in the repo the output dir may not exist
 out_dir=`echo $outfile | sed 's/\(.*\)\/.*/\1/'`
 mkdir -p $out_dir
@@ -64,7 +65,7 @@
pandoc -s -t man -o $outfile --template=$template \
-V title=$title -V section=$section \
-V date="$dt" -V version="$version" \
-   -V year=$(date +"%Y") -V secondary_title="$secondary_title" |
+   -V year="$year" -V secondary_title="$secondary_title" |
 sed '/^\.IP/{
 N
 /\n\.nf/{

Bug#944769: python3-h5py fails to import if offline due to apparent MPI failure

[Drew Parsons]

On 2020-03-02 23:58, Thibaut Paumard wrote:

Hi Drew,

I see, so you effectively copy all symbols from _h5py except those that
look like __foo__ which is Python internal stuff, *and* you give them 
an

entry under h5py in sys.modules. Nice, that should be pretty stable.


Thanks for reviewing, Thibaut.  Actually it was more or less trial & 
error, adding these various elements until (a) import h5py worked, and 
(b) the tests loaded and ran.


I tried "from h5py_serial import *", but that misses the _weak_private 
elements. importlib wouldn't get them either, even when explicitly 
requested. setattr/getattr loaded them, so I figured might as well do 
the same with public api for consistency, instead of "import *".


I also tried the original idea of testing "if MPI_ACTIVE" in the code 
where mpi4py is being loaded.  I could get it to work but it didn't 
provide the serial start time speed up that our Bug Submitter is asking 
for.


Actually, you don't treat public_api differently from weak_privates, 
and

you could be missing some symbols (if introduced later) of the form
_foo_, _foo__ or __foo_. You could simplify the code and cope with this
possibility with something like:

api=[ k for k in _h5py.__dict__.keys() if not (k.startswith('__') and
k.endswith('__')) ]


I see, with double underscore __ instead of single _. I'll do that.


Like you, I would keep h5py_serial and h5py_mpi separate rather than
submodules of h5py. Mostly because the h5py folks could in the future
want to use those two names and do it in an incompatible manner.


Fair enough, I'll keep them separate. (actually, I'll file an Issue 
upstream and let them know what we've done. They may want to adapt for 
themselves).


Thanks again for the review.

Drew

Bug#952974: [Pkg-nagios-devel] Bug#952974: Typo /etc/icingweb2 in a lot of module packages

[Sebastiaan Couwenberg]

clone 952974 -1 -2 -3 -4 -5 -6 -7 -8 -9 -10 -11 -12 -13
reassign -1 src:icingaweb2-module-audit
found -1 icingaweb2-module-audit/1.0.0-1
reassign -2 src:icingaweb2-module-boxydash
found -2 icingaweb2-module-boxydash/0.0.1+20160321-1
reassign -3 src:icingaweb2-module-businessprocess
found -3 icingaweb2-module-businessprocess/2.1.0-1
reassign -4 src:icingaweb2-module-cube
found -4 icingaweb2-module-cube/1.0.1-1
reassign -5 src:icingaweb2-module-director
found -5 icingaweb2-module-director/1.6.0-1
reassign -6 src:icingaweb2-module-eventdb
found -6 icingaweb2-module-eventdb/1.3.0-1
reassign -7 src:icingaweb2-module-graphite
found -7 icingaweb2-module-graphite/1.1.0-1
reassign -8 src:icingaweb2-module-ipl
found -8 icingaweb2-module-ipl/0.1.1-1
reassign -9 src:icingaweb2-module-map
found -9 icingaweb2-module-map/1.1.0-1
reassign -10 src:icingaweb2-module-nagvis
found -10 icingaweb2-module-nagvis/1.1.1-1
reassign -11 src:icingaweb2-module-pnp
found -11 icingaweb2-module-pnp/1.1.0-1.1
reassign -12 src:icingaweb2-module-statusmap
found -12 icingaweb2-module-statusmap/20160720-1
reassign -13 src:icingaweb2-module-x509
found -13 icingaweb2-module-x509/20190125-1
notfound 952974 icingaweb2/2.7.3-1
done 952974

On 3/2/20 5:30 PM, Christoph Berg wrote:
> Package: icingaweb2
> Version: 2.7.3-1
> 
> The typo "/etc/icingweb2" seems to be in a lot of icingweb2 module
> packages:

Those are separate source packages from icingaweb2, and not maintained
within this team. Reassigning.

Kind Regards,

Bas

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

Bug#929024: [RPKI] Bug#929024: ITP: routinator -- An RPKI Validator

[Martin Hoffmann]

Marco d'Itri via RPKI wrote:
> On Dec 30, Marco d'Itri via RPKI  wrote:
> 
> > > Building a real package will still require a few more crates to
> > > be   
> > Right now I am stuck on rpki depending on a very old version of
> > ring. The verification API has changed since then and I do not know
> > enough Rust to update rpki.  
> routinator packaging is still stuck on this.
> Do you have plans to update the dependencies?

Yes. Work towards the last missing pieces for Routinator 1.0 is
starting right now. Part of that is to sort out dependencies.

Kind regards,
Martin

Bug#952975: Subject: debian-i18n: gtk-3 in bullseye does not seem to support XIM input.

[chiaki-ishikawa-thunderbird-account]

Package: debian-i18n
Severity: grave
Justification: renders package unusable
Tags: l10n

Dear Maintainer,

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


   * What led up to the situation?

I performed get-apt dist-upgrade by including testing repository.
Now my /etc/debian_version is
cat /etc/debian_version
bullseye/sid

Then I could no longer perform Japanese input using XIM protocol.



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

    I found that mozilla thunderbird mailer and firefox browser did not 
accept
Japanese input using XIM protocol at all (I used kinput2-wnn frontend). 
gedit

also did not accept Japanese input either.

Meanwhile, other programs continued to receive Japanese input.: 
tkremind, and a

few others.

So I suspect only gtk-3 linked programs suffered from the issue.

   * What was the outcome of this action?


Gtk-3 linked programs failed to do accept Japanese input using XIM 
protocol any

more (with kinput2-wnn forntend).
I could no longer trigger Japanese input mode by hitting control-Space 
(as set

by my configuration.)

Other programs (non gtk-3 linked programs) continued to accept Japanese 
input

using XIM protocol with kinput2-wnn frontend.



   * What outcome did you expect instead?

I should be able to input Japanese characters as I could before the "apt-get
dist-upgrade" using XIM protocol with kinput2-wnn as frontend.


To wit: im-xim.so was missing.
    $mlocate im-xim.so
/new-hd1/extra/ishikawa/download/repos/gtk+/modules/input/.libs/im-xim.so
/new-hd1/extra/ishikawa/download/repos/gtk+/modules/input/.libs/im-xim.soT
    /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/immodules/im-xim.so
    /usr/lib/i386-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
    /usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-xim.so
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-xim.so.SAVED
*   /usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-xim.so.saved
    /usr/local/lib/gtk-2.0/2.10.0/immodules/im-xim.so

The file marked with * above was missing after apt-get dist-upgrade.
I had to copy it back from im-xim.so.saved.
(See the last post in the following thread:
https://groups.google.com/forum/#!topic/mozilla.dev.apps.thunderbird/91QnO047Sl8
)

-- System Information:
Debian Release: bullseye/sid
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'testing'), (500, 
'oldstable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Marvin Renich]

* Andreas Henriksson  [200302 08:27]:
> On Fri, Feb 14, 2020 at 11:31:53AM -0500, Marvin Renich wrote:
> > Control: -1 severity grave
> > 
> > I'm increasing the severity of this bug, as it can cause unintended
> [...]
> 
> I just NMUed a new upstream version of neomutt, 20191207+dfsg.1-1,
> which fixes the two other outstanding RC bugs.
> It seems I can still reproduce this issue however (with the first prompt
> I get which is the imap password prompt for me).

Thanks for this!

> This seems somewhat like a possible UX design fail.

Possibly, but I suspect not.  This is a regression from previous
versions, and it would not make sense at all as an intentional design
change.

> This is done
> upstream and not in debian. Do you know if there's already been any
> discussion regarding this upstream? If not could you please file an
> upstream bug report about this?

Unfortunately, I don't have time to do this at the moment.  I have no
clue where upstream's bug system (or mailing list) is, and can't spend
the time to do this right away.  If you (or the maintainer; I assume you
are not the maintainer since you did an NMU) would be so kind as to
point upstream to this bug, I would appreciate it.

> The behaviour hasn't really bothered me and I probably wouldn't even
> have noticed it if it wasn't for this bug showing up on the RC bug radar
> while doing my NMU, so I'm quite tempted to downgrade severity again.
> Please work this out with upstream if this issue is important to you.
> Please give feedback on this bug report about upstream discussions or
> relevant commits and I'm happy to look into cherry-picking and NMUing
> those as needed.

Please don't downgrade this bug.  Here is a very plausible expanded
example based on my original scenario:

The user is unaware of this bug, so is not being careful to watch out
when backspacing (I am now aware of this bug, and still find myself
accidentally backspacing too far).

The user has tagged a large number of messages, intending to save them
all to a different folder.  The user types «;s=soon-but-not-immediate»
out of habit, without watching the command line, and doesn't notice what
folder was originally placed on the command line based on the save-hook
for the first tagged message.  The first message happens to match the
save-hook for "=spam" (it received a marginally-positive spam score from
spamassassin, but was a false positive).

Before hitting enter on the ;s=soon-but-not-immediate command, the user
changes his mind and decides to save them to the =handle-now folder, so
he presses and holds the backspace key.

Oops!  Now all those messages are moved to the spam folder, which
triggers a daemon on the IMAP server to tell spamassassin to learn all
those messages as spam and moves the messages into a quarantine folder
(inaccessible to the user).

Meanwhile, the poor user, who has never seen this neomutt bug before,
has no clue where his messages went, and all those messages have been
learned as spam without the user's knowledge.

Here is my rationale for severity grave:

* This is a regression from a previous version.

* The behavior makes no sense as an intentional UI change.

* The bug can cause behaviour of which the user is unaware.

* The unintended behavior caused by this bug can have significantly
  detrimental effects that are difficult discover and difficult to undo.

Users of neomutt (and mutt) are typically a different kind of user than
those who stick with Thunderbird or the Gmail web interface.  They are
likely to take full advantage of save-hooks and other advanced neomutt
features.  They are also more likely to type sequences of commands
quickly and by habit, only looking at the command line at certain
pauses.

The above scenario is not based on a hypothetical setup.  I run the
renich.org mail server, which uses spamassassin to score incoming
messages.  Messages with scores above a certain threshold are rejected
during the SMTP dialog, but messages with low-positive scores are
accepted.  I have a save-hook that uses =spam as the default folder for
messages that spamassassin marks with a low-but-positive spam score.  I
do have a spam folder, with behavior similar to what is stated above,
except that the auto-learning happens from a cron job overnight.

While I have not had the above happen to me where the messages were
saved to the spam folder and learned as spam before I caught it, it
could have happened.  The way I discovered this bug was, however, very
similar.  The actual (but unintended) save target was a different
folder.  It took several hours of investigation to determine what the
bug was, where the messages actually went (which was not at all obvious
even after I understood the bug), and to restore the messages to the
intended destination.

Debian Policy does not mention "severity" or "grave" anywhere.  The
Developers Reference lists the severities that are considered RC, but
does not define them.  The only definitions I can find are at [1]
wh

Bug#932815: snapd: "snap remove" broken with AppArmor 2.13.2+

[Алексей Шилин]

On Tue, 23 Jul 2019 14:09:52 -0500 Jamie Strandboge <
ja...@canonical.com> wrote:
> The 'core' snap is one such runtime that is on all systems with snaps
> installed and the 'core' snap contains 'snapd'.
>
> [...]
>
> Since snapd is not installed by default, apt-getting it and then
> installing a snap will pull in the latest core snap so in practice no
> new snaps users of Buster should be affected.

This doesn't seem to always be the case:

aleksej@debian-geary:~$ snap version 
snap2.37.4-1+b1
snapd   2.37.4-1+b1
series  16
debian  10
kernel  4.19.0-8-amd64
aleksej@debian-geary:~$ sudo snap install acestreamplayer 
2020-03-02T18:10:57+03:00 INFO snap "acestreamplayer" has bad plugs or
slots:
audio-playback (unknown interface "audio-playback")
acestreamplayer 3.1.49-snap2 from vasilisc (vs) installed
aleksej@debian-geary:~$ snap list
Name Version   Rev   Tracking  Publisher   Notes
acestreamplayer  3.1.49-snap2  10stablevs  -
core18   20200124  1668  stablecanonical✓  base
aleksej@debian-geary:~$ snap version 
snap2.37.4-1+b1
snapd   2.37.4-1+b1
series  16
debian  10
kernel  4.19.0-8-amd64
aleksej@debian-geary:~$ sudo snap remove acestreamplayer 
error: cannot perform the following tasks:
- Remove security profile for snap "acestreamplayer" (10) (cannot setup
apparmor for snap "acestreamplayer": cannot unload apparmor profile:
exit status 2
apparmor_parser output:
File snap-update-ns.acestreamplayer not found, skipping...
File snap.acestreamplayer.acestreamplayer not found, skipping...
File snap.acestreamplayer.engine not found, skipping...
File snap.acestreamplayer.mpv not found, skipping...
)
- Remove security profile for snap "acestreamplayer" (10) (cannot
unload apparmor profile: exit status 2
apparmor_parser output:
File snap-update-ns.acestreamplayer not found, skipping...
File snap.acestreamplayer.acestreamplayer not found, skipping...
File snap.acestreamplayer.engine not found, skipping...
File snap.acestreamplayer.mpv not found, skipping...
)
aleksej@debian-geary:~$ 

I had to install 'core' explicitly (after finding this bug report).

Bug#915386: Request to Join Debian Multimedia Team

[GMiller]

Hello:

Yes I was aware of the non-GPL license of fdk-aac and the non-free 
implications that you mentioned.


I had a short paragraph on that point in my original join request, but 
ironically the email got lost during 'save'!  When I retyped the 
request I forgot to include it (and maybe some other intended points I 
do not remember).


Anyway, thank you for covering this in detail. And also thank you for 
granting Multimedia Maintainer access.


I will attempt to do the work in the Salsa git repo and follow your 
other suggestions. This is the first time I have worked on line like 
this. We shall see how it goes.


Thank you,

Garie Miller
--
Take back your privacy. Switch to www.StartMail.com

Bug#952968: debuild breaks build by interpolating environment variable into Changed-By field.

[Maximilian Philipps]

and the -e option is probably new with the version from buster and given
that the parallel build option isn't critical we never noticed that it
wasn't working.

Makes sense. Can you close this please? I am not familiar with this bug
tracker software. Thank you very much.

On 3/2/20 5:01 PM, Adam D. Barratt wrote:
> On 2020-03-02 14:53, Maximilian Philipps wrote:
>> When calling debuild with the -e parameter the arguments gets
>> interpolated into the Changed-By field of the .changes file.
>>
>> From our build job:
>>
>> debuild -b -us -uc -eDEB_BUILD_OPTIONS=parallel=2 -ai386
>>
>>
>> grep 'Changed-By:' *.changes
>>
>> Changed-By: DEB_BUILD_OPTIONS=parallel=2
>>
>>
>> Followed by lintian complaining:
>>
>> changes: changed-by-address-missing DEB_BUILD_OPTIONS=parallel=2
>
> This is actually behaving as per the documentation, although it's
> possibly not immediately obvious.
>
> debuild(1) says:
>
> "Note the order of options here: the debuild options come first, then
> the dpkg-buildpackage ones, then finally the checker options"
>
> In this case, neither -us nor -uc is a debuild option, so they are
> being assumed to be dpkg-buildpackage options. As a result, -e is also
> being passed to dpkg-buildpackage, where:
>
>
> -e, --build-by=maintainer-address
>     Passed unchanged to dpkg-genchanges. See its manual page.
>
>
> Rearranging your option list so that the debuild-specific options are
> listed first should resolve this.
>
> Regards,
>
> Adam

Bug#945442: Possible to backspace past beginning of string, which appears to be identical to having pressed Enter immediately, without any backspace

[Joerg Dorchain]

On Mon, 2 Mar 2020 15:18:54 +0100 Andreas Henriksson 
wrote:
> On Mon, Mar 02, 2020 at 02:57:02PM +0100, Andras Korn wrote:
> > 
> > https://github.com/neomutt/neomutt/issues/2002
> 
> Thanks for the feedback.
> 
There is meanwhile a fix in the github issue; Would it be possible add
that patch to the debian package even before a new upstream version is
released?

Thanks for considering.

Bye,

Joerg

Bug#952974: Typo /etc/icingweb2 in a lot of module packages

[Christoph Berg]

Package: icingaweb2
Version: 2.7.3-1
Severity: normal

The typo "/etc/icingweb2" seems to be in a lot of icingweb2 module
packages:

https://codesearch.debian.net/search?q=icingweb&literal=1



icingaweb2-module-ipl_0.1.1-1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)

icingaweb2-module-director_1.6.0-1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)

icingaweb2-module-nagvis_1.1.1-1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)

icingaweb2-module-pnp_1.1.0-1.1/debian/rules

# enable module
mkdir -p $(DEBDIR)/etc/icingweb2/enabledModules
ln -s /usr/share/icingaweb2/modules/$(MODULE) 
$(DEBDIR)/etc/icingweb2/enabledModules/$(MODULE)


...


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

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 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:en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages icingaweb2 depends on:
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra2.37-1
ii  icingaweb2-common 2.7.3-1
ii  php-xml   2:7.3+69
ii  php7.3-xml [php-xml]  7.3.15-3

Versions of packages icingaweb2 recommends:
ii  apache2 [httpd]   2.4.41-4
ii  icingacli 2.7.3-1
pn  icingaweb2-module-doc 
ii  icingaweb2-module-monitoring  2.7.3-1
ii  php   2:7.3+69
ii  php-cli   2:7.3+69
ii  php-curl  2:7.3+69
pn  php-gd
pn  php-imagick   
pn  php-intl  
pn  php-ldap  
ii  php7.3 [php]  7.3.15-3
ii  php7.3-cli [php-cli]  7.3.15-3
ii  php7.3-curl [php-curl]7.3.15-3
ii  php7.3-json [php-json]7.3.15-3

icingaweb2 suggests no packages.

-- no debconf information

Christoph

Bug#950747: projectl: Projectl fails to run with current libgphobos76

[Ludovic Brenta]

severity 951294 important
severity 951423 important
merge 950747 951294 951423
thanks

Hi Matthias,

I thought you were going to make gcc-9 (and gnat-9, for Ada) the
default in the medium term and migrate to gcc-10 only later.
Maybe I misunderstood?  Can you please clarify?

Are binNMUs planned for all other packages affected?

--
Ludovic Brenta.