Bug#886012: cgminer: New upstream version available

[Daniel Baumann]

retitle 886012 new upstream (4.11)
thanks

It would be nice if you could upgrade to the current upstream version
(4.11) from August 2018.

Regards,
Daniel

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

[Carsten Schoenert]

Tags: upstream

Hello  Gregor,

please keep in mind that some AddOns do not add only some new
functionality but also can change some general settings within
Thunderbird. So before sending bug reports it's important that you have
checked some things before firing a new bug report.

We have collected some steps you should mind within the Wiki.

https://wiki.debian.org/Thunderbird#Bug_Reporting_.2F_Issues

Am 29.02.20 um 22:47 schrieb Gregor Riepl:
...
> After upgrading Thunderbird to version 68.5, the new mail dialogue wraps lines
> after 54 characters instead of the commonly used 72.

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

On the other side your (visible) impression isn't fooling you, it looks
like Thunderbird is wrapping lines within plain text mail now not on 72
characters anymore.
But it's only a graphical thing and this means it's based somehow on the
DPI settings and how Thunderbird is using this. I see this behavior
since the first version 68.x I guess.
I do workaround around this temporally by adjusting the DPI scaling
using the key combination 'Crtl +' or using the 'Crtl' key and the
scroll wheel on the mouse.

But I agree this isn't nice.

> Changing the value of mailnews.wraplength has no effect.

This can't get any effect as inside is technically all working correct,
as I tried to explain above.

> This was not the case with Firefox 68.4.

You mean Thunderbird here for sure.

> As a workaround, it's possible to set mail.wrap_long_lines and
> plain_text.wrap_long_ones to false, but this is undesirable.

By this you turn off the line wrapping totally, for plain text
(plain_text.x) and HTML (mail.x).

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

-- 
Regards
Carsten Schoenert

Bug#943280: sprai: Python2 removal in sid/bullseye

[Stuart Prescott]

The only use of python is in the waf build system. It's likely easier to just 
rip that build system out and replace it with a simple Makefile for this 
package.

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#669334: ascii2uni -a U byte injection

[Bill Poser]

Hmm, thanks for letting me know. I will have a look.

Bill


On Wed, Feb 5, 2020 at 8:42 AM Will Huang  wrote:

> There is a bug here:
>
> echo -n 'const t.\u0275fac=1;' | ascii2uni -a U
> const t.=1;
> 1 token converted
>
> The "fac" is been stripped.
>

Bug#944920: Revise terminology used to specify requirements

[Russ Allbery]

Sean Whitton  writes:

> One issue with using uppercased words is that people might think the
> words have the same meaning as they do in RFCs, which they don't.

> Your idea of marking keywords in bold wouldn't have this problem, and
> maybe it would actually make it /easier/ to write patches because you
> can see more clearly which of your words mean what.

It does have the drawback of being either less obvious or a bit noisy in
the text output format, though, which I suspect is reasonably heavily
used.

I'm not sure our definitions are that far off from the RFC terms.  We're
not defining a protocol, so it's inherently a little different, but there
are some clear equivalents.  And it would avoid reinventing a new
typographic convention.

A long time ago, Manoj proposed a deeper, more comprehensive fix: stop
writing Policy as English prose and instead explicitly state normative
requirements in some sort of numbered, clear fashion, and then add a prose
informative explanation if warranted.  But I'm a bit dubious of that.  Not
only would it be a ton of work, but the more formal phrasing will require
repeating ourself a lot more.

Personally, I think I'm leaning mildly towards the all-caps keywords
because of familiarity and compatibility with a pure text format, although
I could be convinced otherwise.

I do think making this change is a good idea.

> Thinking more, I believe that the issue you're raising here is separate
> from what Russ is trying to achieve in this bug.  The problem you're
> identifying here already exists in Policy, before Russ's change is
> applied.  So maybe we should discuss it separately.

Yes, I'm behind but that was the thing I wanted to say: I'd like to merge
this change (I haven't looked at more recent reviews, since I've been
distracted with work, so I don't know off-hand if it's ready for merging
otherwise) and then tackle this issue separately.  But I do think it's
time to tackle it.

>> BTW I guess the instances of «might» and «shall» need to be converted,
>> or added to the keyword list? What about «may not», or «can», «can't»,
>> «cannot» and «could»? And I'm probably missing other words. :)

> I don't think we need to convert words that don't explicitly appear in
> the keywords list -- "may not" would inherit its meaning from "may"
> being a keyword, wouldn't it?

I think that if the word doesn't appear in the keyword list, it shouldn't
have any normative meaning.  I have intentionally used the words can and
cannot in Policy text precisely because they don't have normative meaning
and don't state Policy requirements.  For example, in:

If punctuation is desired between the date components, remember that
hyphen (``-``) cannot be used in native package versions.

the "cannot" is not a normative Policy requirement, just a description of
a logical consequence of a definition stated earlier.

-- 
Russ Allbery (r...@debian.org)  

Bug#952833: RM: smalr -- ROM; Python 2-only, dead upstream

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

The smalr package is Python 2 only and appears to be dead upstream, with
no visible upstream activity in almost 2 years. There are no rdeps so it
can be removed from Debian.

https://github.com/fanglab/SMALR/issues/16
https://github.com/fanglab/SMALR/commits/master

Bug#952832: RM: cfflib -- RoQA; Python 2-only, orphaned, dead upstream

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

cfflib is Python 2 only and is no longer supported upstream. It is also
orphaned in Debian and can be removed from the archive.

https://github.com/LTS5/cfflib/issues/7

Bug#942962: chromium: Python2 removal in sid/bullseye

[Michael Gilbert]

user debian-pyt...@lists.debian.org
usertags 942962 py2keep
usertags 942962 py3noport
thanks

Bug#940944: nm.debian.org: activity ping should mention what's missing

[Judit Foglszinger]

Hi,

added a patch to make the ping messages for stuck processes more informative.
- list missing requirements
- for the case of a missing advocate mention, that a process can be reopened
- for the case of keychecks, mention in the first ping, 
  that this isn't taken in account for the ping.

The messages would look like the below, depending on what exactly is missing.

First ping:

Hello,

the process at https://example.com/process/40 looks stuck.

This message was triggered because the following requirements aren't 
fulfilled:

- Advocate
- Declaration of intent
- SC/DFSG/DMUP agreement

If nothing happens, the process will be automatically closed a week from now.
-> Don't worry about Key consistency checks -
   it's not taken into regard here, because it needs manual approval.
-> If you have an advocate that just needs some more time to react,
   the process can be reopened.

If you need help with anything, please mail n...@debian.org.

Housekeeping Robot for Front Desk
--
second ping:

Hello,

the process at https://example.com/process/40 looks stuck.

This message was triggered because the following requirements aren't 
fulfilled:

- Advocate
- Declaration of intent
- SC/DFSG/DMUP agreement

A week has passed from the last ping with no action, I'll now close the
process. Feel free to reapply in the future.
-> If you have an advocate that just needs some more time to react,
   the process can be reopened.

If you need help with anything, please mail n...@debian.org.

Housekeeping Robot for Front Desk>From 9fbabb4e9e16b2f1d7161bbcdd7b5e53353eb6e0 Mon Sep 17 00:00:00 2001
From: Judit Foglszinger 
Date: Sun, 1 Mar 2020 11:04:37 +0600
Subject: [PATCH] make ping messages more informative.

---
 process/maintenance.py | 58 +++---
 1 file changed, 54 insertions(+), 4 deletions(-)

diff --git a/process/maintenance.py b/process/maintenance.py
index 6e0821e..206ddc7 100644
--- a/process/maintenance.py
+++ b/process/maintenance.py
@@ -15,21 +15,71 @@ def ping_stuck_processes(stuck_cutoff, audit_author, logdate=None):
 if entry.logdate > stuck_cutoff:
 continue
 
+# get missing requirements for process in order
+# to be able to issue a more meaningful ping message
+
+missing_requirements = []
+# additional information appended to ping mail -
+# keycheck does not count as missing requirement here, but is often misinterpreted,
+# so append a message, if it is not approved yet.
+keycheck_message = ""
+# an advocate might take longer than one week to react
+# and the applicant might not be able to influence that,
+# so append a message, that a closed process can be reopened.
+advocate_message = ""
+
+for r in process.requirements.all():
+if r.type == "advocate" or r.type == "intent" or r.type == "sc_dmup":
+if r.approved_by == None:
+missing_requirements.append(r)
+# add additional messages for missing advocate and keycheck
+if r.type ==  "keycheck" and r.approved_by == None:
+keycheck_message = "-> Don't worry about "+str(r)+\
+""" -
+   it's not taken into regard here, because it needs manual approval.
+"""
+if r.type ==  "advocate" and r.approved_by == None:
+advocate_message = \
+"""-> If you have an advocate that just needs some more time to react,
+   the process can be reopened.
+"""
+# not having any missing requirements here would be an error,
+# but let's don't have it look weird in the mail and omit the additional text
+if len(missing_requirements) <= 0:
+msg_str = ""
+else:
+# differentiating singular/plural
+s = "" if len(missing_requirements) < 2 else "s"
+be_form = "is" if len(missing_requirements) < 2 else "are"
+msg_str = \
+"""
+This message was triggered because the following requirement"""+s+" "+be_form+"n't"+\
+""" fulfilled:
+
+"""
+for r in missing_requirements:
+msg_str = msg_str + "- "+str(r)+"\n"
+
 if not already_pinged:
 # Detect first instance of processes stuck early: X days from
 # last log, no previous ping message
-ping_process(audit_author, process, message="""
+msg_str = msg_str +\
+"""
 If nothing happens, the process will be automatically closed a week from now.
-""")
+"""+keycheck_message+advocate_message
+
+ping_process(audit_author, process, message=msg_str)
 process.add_log(audit_author, "looks stuck, pinged",
 action="ping", logdate=logdate)
 else:
 # Detect second instance: X days from last log, no
 # intent/advocate/sc_dmup, a previous ping message
-ping_process(audit_author, process, message="""
+msg_str = msg_str +\
+"""
 

Bug#951088: Merge request 2

[Antonio Russo]

Control: forcemerge -1 946152
Control: tag -1 patch

Please see my MR on salsa [1].  With that patch, collectd builds locally 
without the obsolete build-dep.

Antonio

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

Bug#952831: golang-go: Update to 1.14 and/or support update-alternatives

[Nye Liu]

Package: golang-go
Version: 2:1.13~1
Severity: normal

Go 1.14 is out.

Update this package accordingly.

Also, please add /etc/alternatives support.

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

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

Versions of packages golang-go depends on:
ii  golang-1.13-go  1.13.8-1
ii  golang-src  2:1.13~1

golang-go recommends no packages.

Versions of packages golang-go suggests:
ii  git  1:2.24.0-2

-- no debconf information

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

[Chris Lamb]

Hi Thomas,

 > Do I understand well that you saw this in redfishtool? In such case,
> that's where the bug should be filled, IMO.

I think have two issues here. This one (ie. the timing problem) in
openstack-pkg-tools is still something that should be fixed,
regardless of what other packages do IMHO.

> This is very nice, but in fact, having python3.8 or python3.7, can be
> considered as a bug in the packages I maintain. Indeed, what it means is
> that the package is missing:
> 
> override_dh_python3:
> dh_python3 --shebang=/usr/bin/python3

This sounds logical. However, would this not be better fixed centrally
for *all* packages that use /usr/share/openstack-pkg-tools/pkgos.make
rather than add the following snippet to redfishtool? I don't see this
package doing anything particularly special, and making this change in
every leaf package doesn't seem very elegant to me.


Regards,

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

Bug#952742: mumble: start locks sound for all application (even the client itself)

[Chris Knadle]

Greetings, lemmel.


lemmel:
> Package: mumble
> Version: 1.3.0+dfsg-1+b1
> Severity: grave1.3.0+dfsg-1
> Tags: upstream
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> fresh dist-upgrade (this day 02/28/20) brought up a mumble that lock all sound
> on the host, the mumble client itself producing no sound.
> 
> I did all kind of setup with the mumble client (OSS, ALSA, etc), but it did
> nothing.
> 
> Don't really know the reason as pulseaudo is kind of a magic thing to me, but 
> I
> did retrieve several versions of the mumble client and saw that the current 
> git
> code work correctly.
> 
> Here is the summary of my builds (all extracted from the Git repository) and
> tests :
> - git clone https://github.com/mumble-voip/mumble.git mumble
>   cd mumble
>   git checkout tags/1.3.0
>   git submodule init
>   git submodule update
>   ===> FAILED
> 
> - git clone --single-branch --branch 1.3.x  https://github.com/mumble-
> voip/mumble.git
>   cd mumble
>   git submodule init
>   git submodule update
>   ===> FAILED
> 
> - git clone https://github.com/mumble-voip/mumble.git
>   cd mumble
>   git submodule init
>   git submodule update
>   ===> SUCCESS
> 
> So it may suggest that the current devel version fixes something about its
> sound management.

I normally upload mumble when there's a release snapshot available; I don't
upload development versions from Git unless upstream specifically directs doing
that.  (Which only happened once because there was no 1.3.0 snapshot available
for release at the time.)  I don't know why upstream is taking so long to make
another release snapshot.  :-/

> PS : system informations
> - 5.4.0-4-amd64 #1 SMP Debian 5.4.19-1 (2020-02-13) x86_64 GNU/Linux
> - libc6  : amd64 2.29-10
> - mumble : 1.3.0+dfsg-1+b1
> - gcc -v : gcc version 9.2.1 20200224 (Debian 9.2.1-30)
> - Qt : 5.12.5
> - pulseaudio : 13.0-5

I'm glad this specific section was added because I had tested Mumble in a Sid VM
and the audio worked fine, but the version of pulseaudio in that VM ended up
being held back to 12.2-4+deb10u1 and can't be upgraded due to package
conflicts.  I would like to test this with a more "pure" Sid VM to see what I 
find.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#950039: Fixed in pyglet 1.4.9+

[Benjamin Moran]

This is caused by a change in the recent point releases of Python, and has
been fixed in pyglet 1.4.9+

Bug#950762: ksh,ksh93: both ship /etc/skel/.kshrc with insufficient Conflicts/Breaks/Replaces

[Anuradha Weeraman]

On Thu, Feb 06, 2020 at 03:44:51PM +, Thorsten Glaser wrote:
> I had considered that, but creating a ksh-common package for just
> one file, which in addition to that is a skeleton file that is not
> used during normal operation, just adduser, seems overkill. The
> sequence of installing both then removing one is also expected to
> occur only rarely, most users would either install one, or both,
> and then keep that. I had thought that that with the Replaces on
> the other packages would be sufficient.
> 
> Is it possible to make an exception here, considering the file in
> question and that it is documented?

Hi Andreas

I would agree on Thorsten's point above that it would be somewhat
overkill in this given scenario.

Please suggest if you would be okay with an exception in this regard, or
if you still feel that this needs to be addressed?

thanks,
Anuradha

Bug#952830: gedit: Ctrl + l doesn't bring up goto line entry box

[Keyikedalube Ndang]

Package: gedit
Version: 3.35.90-1
Severity: normal

Dear Maintainer,

Ctrl + l is supposed to bring up Goto line entry box at the top right

Instead, the cursor moves forward by a character every time I press the
key combination

For now I access Goto line menu manually through gedit's menu option


-- Package-specific info:

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

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 gedit depends on:
ii  gedit-common   3.35.90-1
ii  gir1.2-glib-2.01.62.0-5
ii  gir1.2-gtk-3.0 3.24.13-1
ii  gir1.2-gtksource-4 4.4.0-1
ii  gir1.2-pango-1.0   1.42.4-8
ii  gir1.2-peas-1.01.22.0-5
ii  gsettings-desktop-schemas  3.34.0-2
ii  iso-codes  4.4-1
ii  libamtk-5-05.0.0-3
ii  libatk1.0-02.34.1-1
ii  libc6  2.29-10
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libgirepository-1.0-1  1.62.0-5
ii  libglib2.0-0   2.62.5-1
ii  libgspell-1-2  1.8.3-1
ii  libgtk-3-0 3.24.13-1
ii  libgtksourceview-4-0   4.4.0-1
ii  libpango-1.0-0 1.42.4-8
ii  libpeas-1.0-0  1.22.0-5
ii  libtepl-4-04.3.1-1
ii  libx11-6   2:1.6.9-2
ii  python33.7.5-3
ii  python3-gi 3.34.0-6
ii  python3-gi-cairo   3.34.0-6
ii  python3.7  3.7.6-1+b1

Versions of packages gedit recommends:
ii  yelp3.34.0-1
ii  zenity  3.32.0-4

Versions of packages gedit suggests:
ii  gedit-plugins  3.34.0-3

-- no debconf information

Bug#952829: gedit: Ctrl + f9 doesn't show bottom panel

[Keyikedalube Ndang]

Package: gedit
Version: 3.35.90-1
Severity: normal

Dear Maintainer,

I noticed the keyboard shortcut for showing bottom panel on gedit is
Ctrl + f9 from its keyboard shortcuts help window.

I hit the keyboard combination and noticed gedit showing the
side panel

The expected outcome is to show the bottom panel


-- Package-specific info:

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

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 gedit depends on:
ii  gedit-common   3.35.90-1
ii  gir1.2-glib-2.01.62.0-5
ii  gir1.2-gtk-3.0 3.24.13-1
ii  gir1.2-gtksource-4 4.4.0-1
ii  gir1.2-pango-1.0   1.42.4-8
ii  gir1.2-peas-1.01.22.0-5
ii  gsettings-desktop-schemas  3.34.0-2
ii  iso-codes  4.4-1
ii  libamtk-5-05.0.0-3
ii  libatk1.0-02.34.1-1
ii  libc6  2.29-10
ii  libcairo2  1.16.0-4
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libgirepository-1.0-1  1.62.0-5
ii  libglib2.0-0   2.62.5-1
ii  libgspell-1-2  1.8.3-1
ii  libgtk-3-0 3.24.13-1
ii  libgtksourceview-4-0   4.4.0-1
ii  libpango-1.0-0 1.42.4-8
ii  libpeas-1.0-0  1.22.0-5
ii  libtepl-4-04.3.1-1
ii  libx11-6   2:1.6.9-2
ii  python33.7.5-3
ii  python3-gi 3.34.0-6
ii  python3-gi-cairo   3.34.0-6
ii  python3.7  3.7.6-1+b1

Versions of packages gedit recommends:
ii  yelp3.34.0-1
ii  zenity  3.32.0-4

Versions of packages gedit suggests:
ii  gedit-plugins  3.34.0-3

-- no debconf information

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

[Ricardo]

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

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

Ricardo.

2020-02-29 19:33 GMT-03:00, Holger Wansing :
> Package: www.debian.org
>
> As tidy constantly complains about
>
> *** /srv/www.debian.org/www/partners/2018/index.en.html
> line 159 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 255 column 3 - Warning:  attribute "width" has invalid value
> "height="
> *** /srv/www.debian.org/www/partners/2019/index.en.html
> line 75 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 159 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 255 column 3 - Warning:  attribute "width" has invalid value
> "height="
> *** /srv/www.debian.org/www/partners/2020/index.en.html
> line 75 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 159 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 255 column 3 - Warning:  attribute "width" has invalid value
> "height="
> *** /srv/www.debian.org/www/partners/index.en.html
> line 77 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 161 column 3 - Warning:  attribute "width" has invalid value
> "height="
> line 257 column 3 - Warning:  attribute "width" has invalid value
> "height="
>
> which is all about width/height information in svg graphics:
>
> what about converting the relevant images (google.svg and
> stackpack-logo-reversed.svg)
> into some other format, like png?
>
> Please excuse my ignorance, I have no detailed knowledge on vector
> graphics:
> maybe there is a reason why we should use svg there.
> However, png is widely used in the partners section...
>
> I have attached png variants of the relevant images.
>
>
> Holger
>
> --
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
>

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

[Ross Vandegrift]

Control: forwarded -1 https://phab.enlightenment.org/T8621
Control: tags -1 upstream

On Thu, Feb 27, 2020 at 02:14:52AM +0300, sergio wrote:
> > Sorry but I don't think I can really help further.  Maybe the upstream
> folks
> > would be able to track something down.
> 
> OK, I'll report this bug on phab.enlightenment.org but really I so tired
> of E bugs, that I'm thinking to switch to another WM (possibly tiling
> with good float mode support). The only thing stopping me is time I need
> for choice and configuration.

Thanks for that.  Sorry that you've had issues with your use-cases.

I still can't seem to trigger this like you can, but I was able to get some
backtraces today.  I'll post these to the phab as well.

ERR<36232>:eo ../src/lib/eo/eo.c:2192 efl_data_scope_get() Eo ID 0x403d1edf 
is not a valid object. Current thread: main. This ID has probably been deleted 
or this was never a valid object ID. (domain=0, current_domain=0, 
local_domain=0, available_domains=[0 1], generation=2df, id=f47, ref=1)

/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2054 @ 
eina_log_print_cb_stderr.part.0()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 1456 @ 
eina_log_print_unlocked()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2259 @ eina_log_print()
/usr/lib/x86_64-linux-gnu/libeo.so.1   |
??/?? : 2259 @ _eo_obj_pointer_get()
/usr/lib/x86_64-linux-gnu/libeo.so.1   | 
../src/lib/eo/eo.c   : 2192 @ efl_data_scope_get()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_exe.c:  218 @ 
ecore_exe_pid_get()
 /usr/bin/enlightenment|
../src/bin/e_exec.c   :  814 @ _e_exec_startup_id_pid_find()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_iterator.c:  150 @ 
eina_iterator_foreach()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_hash.c: 1241 @ 
eina_hash_foreach()
 /usr/bin/enlightenment|
../src/bin/e_exec.c   :  298 @ e_exec_startup_id_pid_instance_find()
 /usr/bin/enlightenment|
../src/bin/e_client.c : 2202 @ _e_client_eval()
 /usr/bin/enlightenment|
../src/bin/e_client.c : 2540 @ e_client_idler_before()
 /usr/bin/enlightenment|
../src/bin/e_main.c   : 1810 @ _e_main_cb_idle_before()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_idler.c  :   35 @ 
_ecore_factorized_idle_process()
/usr/lib/x86_64-linux-gnu/libeo.so.1   |
??/?? :   35 @ _event_callback_call()
/usr/lib/x86_64-linux-gnu/libeo.so.1   |
??/?? :   35 @ efl_event_callback_call()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_main.c   : 2413 @ 
_ecore_main_loop_iterate_internal()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_main.c   : 1198 @ 
_ecore_main_loop_begin()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/efl_loop.c :   58 @ 
_efl_loop_begin()
/usr/lib/x86_64-linux-gnu/libecore.so.1|  
./obj-x86_64-linux-gnu/src/lib/ecore/efl_loop.eo.c  :   28 @ efl_loop_begin()
/usr/lib/x86_64-linux-gnu/libecore.so.1|   
./obj-x86_64-linux-gnu/../src/lib/ecore/ecore_main.c   : 1285 @ 
ecore_main_loop_begin()
 /usr/bin/enlightenment|
../src/bin/e_main.c   : 1100 @ main()
/lib/x86_64-linux-gnu/libc.so.6| 
/build/glibc-TrjWJf/glibc-2.29/csu/../csu/libc-start.c   :  342 @ 
__libc_start_main()
 /usr/bin/enlightenment|
??/?? :  342 @ _start()



ERR<36232>:eo ../src/lib/eo/eo.c:1814 efl_isa() Eo ID 0x403d1edf is not a 
valid object. Current thread: main. This ID has probably been deleted or this 
was never a valid object ID. (domain=0, current_domain=0, local_domain=0, 
available_domains=[0 1], generation=2df, id=f47, ref=1)

/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2054 @ 
eina_log_print_cb_stderr.part.0()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 1456 @ 
eina_log_print_unlocked()
/usr/lib/x86_64-linux-gnu/libeina.so.1 |
./obj-x86_64-linux-gnu/../src/lib/eina/eina_log.c : 2259 @ 

Bug#952827: calibre: Kindle not detected unless udisks2 package is installed; please add to Depends

[Norbert Preining]

tags 952827 + pending
thanks

On Sat, 29 Feb 2020, Eric Cooper wrote:
> I think udisks2 (or an underlying library?) should be a Depends, or at
> least Recommended.

Thanks for your email, indeed, added a Recommends!

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#952827: calibre: Kindle not detected unless udisks2 package is installed; please add to Depends

[Eric Cooper]

Package: calibre
Version: 4.99.4+dfsg+really4.10.0+py3-2
Severity: normal

I have calibre installed on two Debian systems. My Kindle Paperwhite
was only being detected on one of them. I used calibre's "debug device
detection" to discover that it was trying to use a Python udisks
function and failing. The system where it worked already had udisks2
installed. Once I installed udisks2 on the other system, it worked
too.

I think udisks2 (or an underlying library?) should be a Depends, or at
least Recommended.

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

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

Versions of packages calibre depends on:
ii  calibre-bin  4.99.4+dfsg+really4.10.0+py3-2
ii  dpkg 1.19.7
ii  fonts-liberation 1:1.07.4-11
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  libjpeg-turbo-progs  1:1.5.2-2+b1
ii  libjs-mathjax2.7.4+dfsg-1
ii  libjxr-tools 1.1-6+b1
ii  optipng  0.7.7-1+b1
ii  poppler-utils0.71.0-6
ii  python3  3.7.5-3
ii  python3-apsw 3.30.1-r1-1.1
ii  python3-bs4  4.8.2-1
ii  python3-chardet  3.0.4-4
ii  python3-chm  0.8.6-2
ii  python3-css-parser   1.0.4-2
ii  python3-cssselect1.1.0-2
ii  python3-cssutils 1.0.2-3
ii  python3-dateutil 2.7.3-3
ii  python3-dbus 1.2.16-1
ii  python3-feedparser   5.2.1-2
ii  python3-html2text2020.1.16-1
ii  python3-html5-parser 0.4.9-3
ii  python3-html5lib 1.0.1-2
ii  python3-lxml 4.5.0-1
ii  python3-markdown 3.1.1-2
ii  python3-mechanize1:0.4.5-2
ii  python3-msgpack  0.5.6-3
ii  python3-netifaces0.10.9-0.2
ii  python3-pil  6.2.1-2+b1
ii  python3-pkg-resources44.0.0-1
ii  python3-pygments 2.3.1+dfsg-1
ii  python3-pyparsing2.4.6-1
ii  python3-pyqt55.14.1+dfsg-3
ii  python3-pyqt5.qtsvg  5.14.1+dfsg-3
ii  python3-pyqt5.qtwebengine5.14.0-2
ii  python3-regex0.1.20190819-2
ii  python3-routes   2.4.1-2
ii  python3-zeroconf 0.23.0-1
ii  xdg-utils1.1.3-1

Versions of packages calibre recommends:
pn  python3-dnspython  

Versions of packages calibre suggests:
pn  python3-unrardll  

-- no debconf information

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

[Holger Wansing]

Package: www.debian.org

As tidy constantly complains about 

*** /srv/www.debian.org/www/partners/2018/index.en.html
line 159 column 3 - Warning:  attribute "width" has invalid value "height="
line 255 column 3 - Warning:  attribute "width" has invalid value "height="
*** /srv/www.debian.org/www/partners/2019/index.en.html
line 75 column 3 - Warning:  attribute "width" has invalid value "height="
line 159 column 3 - Warning:  attribute "width" has invalid value "height="
line 255 column 3 - Warning:  attribute "width" has invalid value "height="
*** /srv/www.debian.org/www/partners/2020/index.en.html
line 75 column 3 - Warning:  attribute "width" has invalid value "height="
line 159 column 3 - Warning:  attribute "width" has invalid value "height="
line 255 column 3 - Warning:  attribute "width" has invalid value "height="
*** /srv/www.debian.org/www/partners/index.en.html
line 77 column 3 - Warning:  attribute "width" has invalid value "height="
line 161 column 3 - Warning:  attribute "width" has invalid value "height="
line 257 column 3 - Warning:  attribute "width" has invalid value "height="

which is all about width/height information in svg graphics:

what about converting the relevant images (google.svg and 
stackpack-logo-reversed.svg)
into some other format, like png?

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

I have attached png variants of the relevant images.


Holger

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

Bug#951935: ufw: FTBFS: ERROR: test_get_iptables_version (tests.unit.test_util.UtilTestCase)

[Jamie Strandboge]

On Wed, 26 Feb 2020, Jamie Strandboge wrote:

> Thanks for the report! Yes, this is known and the fix queued. I was
> recently approved for Debian Maintainer and will do this as soon as I'm
> given upload permissions (key added, in process of getting someone to
> run dcut for me).

I uploaded 0.36-3 but forgot to add Closes: 951935. This should be
resolved in 0.36-3; please report back if this is not the case.

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#942108: ufw: enabling ufw is breaking the INPUT chain

[Jamie Strandboge]

On Fri, 13 Dec 2019, Jamie Strandboge wrote:

> On Thu, 10 Oct 2019, Jonathan Dowland wrote:
> 
> > Package: ufw
> > Version: 0.36-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Post-buster upgrade, and ufw is no longer functioning correctly. I'm using
> > ip(6)tables-legacy, rather than the newer xtables stuff, for 
> > interoperability
> > with docker. My ufw ruleset has several ALLOWs, e.g.
> > 
> > # ufw status | grep 22
> > 22 ALLOW   Anywhere
> > 
> > (taken when ufw is "running").
> > 
> > However upon first starting ufw ("ufw enable"), all incoming traffic to the
> > host is dropped. Via the console I can see that this is because the INPUT
> > chain policy has been set to DENY, and the ufw tables are not hooked in
> > properly. Excerpts from "iptables-save" after "ufw enable":
> > 
> > *filter
> > :INPUT DROP [2943:317505]
> > :FORWARD DROP [0:0]
> > :OUTPUT ACCEPT [80:9298]
> > …
> > -A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
> > …
> > 
> > So great, my rules are encoded into the ufw-user-input table fine, but that
> > table is not hooked into INPUT : iptables-save | grep "^-A INPUT" is empty.
> > 
> 
> I cannot reproduce on an up to date buster system:
> 
> $ sudo update-alternatives --config iptables
> There are 2 choices for the alternative iptables (providing
> /usr/sbin/iptables).
> 
>   SelectionPath   Priority   Status
> 
> * 0/usr/sbin/iptables-nft  20auto mode
>   1/usr/sbin/iptables-legacy   10manual mode
>   2/usr/sbin/iptables-nft  20manual mode
> 
> Press  to keep the current choice[*], or type selection number: 1
> update-alternatives: using /usr/sbin/iptables-legacy to provide
> /usr/sbin/iptables (iptables) in manual mode
> 
> 
> $ sudo ufw allow 22
> $ sudo ufw enable
> Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
> Firewall is active and enabled on system startup
> 
> $ sudo iptables-save |grep '\-A INPUT'
> -A INPUT -j ufw-before-logging-input
> -A INPUT -j ufw-before-input
> -A INPUT -j ufw-after-input
> -A INPUT -j ufw-after-logging-input
> -A INPUT -j ufw-reject-input
> -A INPUT -j ufw-track-input
> 
> (note the user chains are added to the end of the before chains with '-A
> ufw-before-input -j ufw-user-input')
> 
> So everything is working ok. Do you have other firewall software
> installed? Eg, iptables-persistent or similar?
> 
> Is it possible that you have software that is using the nft backend and
> not legacy? Is something calling iptables-legacy* directly but
> alternatives aren't setup correctly?

I'm closing this bug due to it being unreproducible locally and not
receiving the requested information. Please feel free to respond with
more info and we can reopen the bug.

-- 
Email: ja...@strandboge.com
IRC:   jdstrand

Bug#939292: related RFP closed

[Gabriel Filion]

FYI I saw that there was an RFP open for puppet-development-kit, which I
had missed earlier: #879271

I've closed this other bug report since this one aims to fulfill it.



signature.asc
Description: OpenPGP digital signature

Bug#952825: rust-whoami: d/copyright issues

[Sean Whitton]

Source: rust-whoami
Version: 0.7.0-1

Hello,

During review in NEW I noticed that CODEOFCONDUCT.md is under a
different license and has different copyright holders.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952821: Acknowledgement (Regression: T420 not accepting inputs - usb device not accepting address, pci=noacpi)

[Carli]

As bts forwarded seems not to work.
Here is the link to the upstream bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=206723

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

[Gregor Riepl]

Package: thunderbird
Version: 1:68.5.0-1+b1
Severity: normal

Dear Maintainer,

After upgrading Thunderbird to version 68.5, the new mail dialogue wraps lines
after 54 characters instead of the commonly used 72.

Changing the value of mailnews.wraplength has no effect.

This was not the case with Firefox 68.4.

As a workaround, it's possible to set mail.wrap_long_lines and
plain_text.wrap_long_ones to false, but this is undesirable.



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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-2+b1
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-3
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200222-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-2
ii  libglib2.0-0  2.62.4-2
ii  libgtk-3-03.24.13-1
ii  libgtk2.0-0   2.24.32-4
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.24-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.42.4-8
ii  libsqlite3-0  3.31.1-3
ii  libstartup-notification0  0.12-6
ii  libstdc++610-20200222-1
ii  libvpx6   1.8.2-1
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-5
ii  libxcb1   1.13.1-5
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.3-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1.2

Versions of packages thunderbird recommends:
ii  hunspell-de-ch [hunspell-dictionary] 20161207-7
ii  hunspell-de-de [hunspell-dictionary] 20161207-7
ii  hunspell-en-gb [hunspell-dictionary] 1:6.4.0~rc2-1
ii  hunspell-en-us [hunspell-dictionary] 1:2018.04.16-1
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.4.1-1
ii  lightning1:68.5.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.3-7
ii  fonts-lyx 2.3.4.2-2
ii  libgssapi-krb5-2  1.17-6

-- no debconf information

Bug#920878: provide QMAKE in buildtools.mk [Was: Re: Bug#920878: provide a package name for lrelease-pro]

[Helmut Grohne]

Control: retitle -1 provide QMAKE from dpkg's buildtools.mk
Control: reassign -1 dpkg-dev

Hi Guillem,

On Sun, Mar 01, 2020 at 12:33:36AM +0300, Dmitry Shachnev wrote:
> On Sat, Feb 29, 2020 at 10:17:23PM +0100, Helmut Grohne wrote:
> > I'm left wondering whether we should ask Guillem to include QMAKE in
> > /usr/share/dpkg/buildtools.mk. Once doing so, exporting QMAKE can be as
> > simple as:
> >
> > DPKG_EXPORT_BUILDTOOLS=1
> > include /usr/share/dpkg/buildtools.mk
> >
> > or
> >
> > include /usr/share/dpkg/buildtools.mk
> > export QMAKE
> >
> > If you agree, I propose repurposing this bug report for asking Guillem
> > to extend buildtools.mk.
> 
> I don't mind at all.

It turned out that having something set up the QMAKE variable to point
at ${DEB_HOST_GNU_TYPE}-qmake is something we need in a few places. Can
you carry that in buildtools.mk? I think it's as simple as

$(eval $(call dpkg_buildtool_setvar,QMAKE,qmake))

Helmut

Bug#920878: provide a package name for lrelease-pro

[Dmitry Shachnev]

On Sat, Feb 29, 2020 at 10:17:23PM +0100, Helmut Grohne wrote:
> I'm left wondering whether we should ask Guillem to include QMAKE in
> /usr/share/dpkg/buildtools.mk. Once doing so, exporting QMAKE can be as
> simple as:
>
> DPKG_EXPORT_BUILDTOOLS=1
> include /usr/share/dpkg/buildtools.mk
>
> or
>
> include /usr/share/dpkg/buildtools.mk
> export QMAKE
>
> If you agree, I propose repurposing this bug report for asking Guillem
> to extend buildtools.mk.

I don't mind at all.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#952823: ITP: jgrep -- Compare a list of json documents to a simple logical language and returns matches as output

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: jgrep
  Version : 1.5.2
  Upstream Author : Pieter Loubser , Dominic Cleal 
, R.I. Pienaar 
* URL : https://github.com/ploubser/JSON-Grep
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Compare a list of json documents to a simple logical 
language and returns matches as output

JGrep is a command line tool and API for parsing JSON documents based on
logical expressions. It returns a JSON datastructure that contains all of the
matches from the original JSON document. Used as a library, you can filter
results in a similar fashion from within your Ruby code.

This tool is very similar in functionality to jq, but uses a matching syntax
that is a lot simpler.


This tool/library can be very useful on its own either directly on the
command line or as a tool for building complex programs that need to filter
JSON. It's also used as a dependency by facterdb, which itself is required for
puppet-development-kit.

I plan to maintain this package from within the ruby team. I will ask for
sponsorship from the team.

Bug#952821: Regression: T420 not accepting inputs - usb device not accepting address, pci=noacpi

[Carli Freudenberg]

Package: src:linux
Version: 4.19.87-1
Severity: important
Tags: upstream

Dear maintainer,

I found a regression bug.
With kernel starting from version linux-image-4.19.0-7-amd64 (4.19.87-1) my
Thinkpad T420 "freezes" on boot (no inputs taken, can't enter the decryption
password, so can't boot my device). The kernel version linux-
image-4.19.0-6-amd64 (4.19.67-2+deb10u2) just works fine.

Even so I can enter anything it continues to show (with changing n):
usb 1-1: device not accepting address n, error -110
usb 2-1: new high-speed USB device number n using ehci-pci
usb usb2-port1: attempt power cycle

It shows this errors even so no [external] USB devices are connected.

With Kernel <4.19.76 I can boot normally with kernel settings:
pci=noacpi.
Without this setting the screen stays black, so I have to use it.

I made a git bisect (stable branch) and found:
b40c15c20e42491303202ae1368841704be0c3b9 is the first bad commit
commit b40c15c20e42491303202ae1368841704be0c3b9
Author: Thomas Gleixner 
Date:   Mon Jul 22 20:47:08 2019 +0200

x86/apic: Soft disable APIC before initializing it

[ Upstream commit 2640da4cccf5cc613bf26f0998b9e340f4b5f69c ]

If the APIC was already enabled on entry of setup_local_APIC() then
disabling it soft via the SPIV register makes a lot of sense.

That masks all LVT entries and brings it into a well defined state.

Otherwise previously enabled LVTs which are not touched in the setup
function stay unmasked and might surprise the just booting kernel.

Signed-off-by: Thomas Gleixner 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20190722105219.068290...@linutronix.de
Signed-off-by: Sasha Levin 

:04 04 db502796eb6fdf24be8a4b6442531cd027b4d459
8a9beff72957993cab7366eaa36c2d25700e1676 M  arch

This is why I sorted this bug into ACPI bugs.

I can't use any newer kernel version if this bug remains as either my system
"freezes" (don't accepts inputs) with pci=noacpi set or doesn't display
anything.

In older kernel / debian versions (3.xx, Jessie) everything worked fine out of
the box.
How can I contribute to get to this state again?



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 4236BD5
product_version: ThinkPad T420
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: 83ET82WW (1.52 )
board_vendor: LENOVO
board_name: 4236BD5
board_version: Not Available

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0104] (rev 09)
Subsystem: Lenovo 2nd Generation Core Processor Family DRAM Controller 
[17aa:21ce]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0126] (rev 09) (prog-if 
00 [VGA controller])
Subsystem: Lenovo 2nd Generation Core Processor Family Integrated 
Graphics Controller [17aa:21ce]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: Lenovo 6 Series/C200 Series Chipset Family MEI Controller 
[17aa:21ce]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
Connection [8086:1502] (rev 04)
Subsystem: Lenovo 82579LM Gigabit Network Connection (Lewisville) 
(ThinkPad T520) [17aa:21ce]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo 6 Series/C200 Series Chipset Family USB Enhanced Host 
Controller [17aa:21ce]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel 

Bug#952822: /etc/zfs/zed.d configuration is clobbered on upgrade

[Antonio Russo]

Package: zfs-zed
Version: 0.8.3-1
Severity: serious
Tags: patch
Justification: Policy 10.7.3

Please see my MR on salsa [1], which should address this policy violation.  In 
short: the symlinks shipped
by zfs-zed in /etc/zfs/zed.d are not tracked as conffiles by dpkg, so they 
re-appear even after being
deleted.

Antonio


[1] https://salsa.debian.org/zfsonlinux-team/zfs/-/merge_requests/21

Bug#920365: [debian-mysql] Bug#920365: mariadb_config: improve cross compilation support

[Helmut Grohne]

Hi Otto,

On Tue, Aug 27, 2019 at 11:47:17AM +0200, Otto Kekäläinen wrote:
> Hello!

Apparently, I missed your reply. Sorry for the delay.

> I am happy to do these changes for you in the Debian package, but I
> wasn't quite able to follow what script do you mean is the
> replacement?

The bug submission has a shell script attached.

$ ./mysql_config_generator.sh debian/libmariadb-dev/usr/bin/mariadb_config > 
debian/mariadb_config.new
$ chmod +x debian/mariadb_config.new
$ mv debian/mariadb_config.new debian/libmariadb-dev/usr/bin/mariadb_config
$

Of course, doing so breaks cross building mariadb itself. However that's
known to be broken due to #707750, which hasn't shown any progress in 6
years and likely won't show any progress in the next 6 years.

Helmut

Bug#952820: dracut: Doesn't recognise swap files for resuming

[nabijaczleweli]

Package: dracut
Version: 048+80-2
Severity: normal
Tags: patch

Dear Maintainer,


Dracut, in host-only mode will, by default, only install the resume
module if it detects a swap partition.
This has a major problem of not detecting, and therefore not resuming
from, swap files.

This problem has been known upstream for a long time (2017, comment on
https://github.com/dracutdevs/dracut/commit/34b56de12aad622d602d6e3bd434e02c840f1cd0)
and an issue has been open since 2018
(https://github.com/dracutdevs/dracut/issues/496), to no avail so far.
I've recently opened a PR
(https://github.com/dracutdevs/dracut/pull/715), to a similar response.

In hopes I can spare another soul a few hours of debugging,
I have attached this patch here as well, having verified that it builds
with the 048+80-2 source and applies to the current HEAD at Salsa
(ebb0748) without problems; it simply replaces the partition detection
with a check against /sys/power/resume, and includes the module if it's
not 0:0, i.e. hibernation is enabled.

Another solution would be to add something like
  awk '{if($2 == "file") exit 1}' /proc/swaps || return 0
before the "return 255" line, but I feel that that's just moving the
problem.

Regards,
nabijaczleweli


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dracut depends on:
ii  dracut-core  048+80-2

dracut recommends no packages.

Versions of packages dracut suggests:
pn  dracut-network  

-- no debconf information
From: nabijaczleweli 
Date: Fri, 13 Dec 2019 07:59:59 +0100
Subject: [PATCH] Enable resume module if hibernation's enabled on the host

Ref: https://github.com/dracutdevs/dracut/commit/34b56de12aad622d602d6e3bd434e02c840f1cd0
Fixes https://github.com/dracutdevs/dracut/issues/496
---
 modules.d/95resume/module-setup.sh | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/modules.d/95resume/module-setup.sh b/modules.d/95resume/module-setup.sh
index 6ddc725..cb06b56 100755
--- a/modules.d/95resume/module-setup.sh
+++ b/modules.d/95resume/module-setup.sh
@@ -2,12 +2,9 @@
 
 # called by dracut
 check() {
-# No point trying to support resume, if no swap partition exist
+# Only support resume if hibernation is currently on
 [[ $hostonly ]] || [[ $mount_needs ]] && {
-for fs in "${host_fs_types[@]}"; do
-[[ $fs =~ ^(swap|swsuspend|swsupend)$ ]] && return 0
-done
-return 255
+[[ "$(cat /sys/power/resume)" == "0:0" ]] && return 255
 }
 
 return 0


signature.asc
Description: PGP signature

Bug#920878: provide a package name for lrelease-pro

[Helmut Grohne]

Hi Dmitry,

On Sat, Feb 29, 2020 at 11:48:47PM +0300, Dmitry Shachnev wrote:
> As we discussed on IRC, a separate package won't help much, as it cannot
> declare a dependency on qt5-qmake:native anyway. The :native qualifier only
> makes sense in Build-Depends.

Details. It's technically possible, but we don't want it here:

> Also, I figured out that lrelease (lrelease-pro in new Qt) does not
> actually need *native* qmake, the cross qmake works as well. We just need
> to specify QMAKE environment variable that it honors:
> 
> https://code.qt.io/cgit/qt/qttools.git/tree/src/linguist/lprodump/main.cpp?h=v5.14.1#n439
> 
> As I just demonstrated in https://bugs.debian.org/889752#10, this approach
> works. So I propose to close this bug and export QMAKE to qmake cross
> wrapper in the affected packages instead.

The approach is much better. Thank you.

I'm left wondering whether we should ask Guillem to include QMAKE in
/usr/share/dpkg/buildtools.mk. Once doing so, exporting QMAKE can be as
simple as:

DPKG_EXPORT_BUILDTOOLS=1
include /usr/share/dpkg/buildtools.mk

or

include /usr/share/dpkg/buildtools.mk
export QMAKE

If you agree, I propose repurposing this bug report for asking Guillem
to extend buildtools.mk.

Helmut

Bug#952819: ITP: facterdb -- Database of facts from many Facter versions on many Operating Systems

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: facterdb
  Version : 1.2.0
  Upstream Author : Mickaël Canévet 
* URL : https://github.com/camptocamp/facterdb
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Database of facts from many Facter versions on many 
Operating Systems

The facterdb command can lookup its database with a set of versions of Facter
and a set of Operating System distributions and versions and output the list
of facts corresponding to those to the terminal. The output is formatted in
JSON so it can be parsed by other scripts and programs.

When used as a library, the same lookups can be done in a programmatic way.
This means that you can use the facts in any Ruby program.

Having access to lists of facts that mimic different setups is useful for
running tests and making sure that features for those different setups are
doing what's expected.


This command and library is generally useful for Puppet module development and
creating CI environments for running module unit tests. It's also used by the
puppet-development-kit, so it is a dependency for this tool.

I plan on maintaining this package from within the ruby team. I will ask for
sponsorship from the team.

Bug#874812: [amora-server] Qt4 removal from Debian

[Axel Beckert]

Hi,

Adenilson Cavalcanti wrote:
> Long story short, I support removing it from Debian as I lack the time to
> do the re-write and the devices that could run the client are long gone.

Thanks for your comment — and the nice flashback. :-)

I've just requested removal of amora-server from Debian Unstable in
https://bugs.debian.org/952818

Lisandro: Feel free to add some "block by" relation between this bug
report and the removal request if that helps you to keep track of the
Qt4 removal progress.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#920878: provide a package name for lrelease-pro

[Dmitry Shachnev]

Hi Helmut!

Now I am working on packaging Qt 5.14, so I am returning to this bug.

On Thu, Feb 07, 2019 at 04:52:53PM +0100, Helmut Grohne wrote:
> Control: retitle -1 provide a package name for lrelease-pro
> Control: reassign -1 qttools5-dev-tools
> Control: tags -1 =
>
> On Thu, Feb 07, 2019 at 12:54:08PM +0300, Dmitry Shachnev wrote:
> > Maybe when we package Qt 5.13, I can split lrelease-pro into a separate
> > package that will depend on qt5-qmake.
>
> That's a good idea. Let's repurpose this bug then. Notably: The package
> doesn't have to be real. Virtual packages work as well for this purpose.

As we discussed on IRC, a separate package won't help much, as it cannot
declare a dependency on qt5-qmake:native anyway. The :native qualifier only
makes sense in Build-Depends.

Also, I figured out that lrelease (lrelease-pro in new Qt) does not
actually need *native* qmake, the cross qmake works as well. We just need
to specify QMAKE environment variable that it honors:

https://code.qt.io/cgit/qt/qttools.git/tree/src/linguist/lprodump/main.cpp?h=v5.14.1#n439

As I just demonstrated in https://bugs.debian.org/889752#10, this approach
works. So I propose to close this bug and export QMAKE to qmake cross
wrapper in the affected packages instead.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#952818: RM: amora-server -- ROM; not ported to Qt5, interfaces with obsolete hardware

[Axel Beckert]

Package: ftp.debian.org
Severity: normal

Hi,

please remove amora-server from Debian Unstable:

(Reasons taken from my posting on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874812#42)

* Upstream (Cc'ed) tried to migrate to Qt5 about two years ago.
  Compiling and running with Qt5 was not the big issue, but getting
  Bluetooh working again — and hence core functionality:
  https://github.com/amora/amora/issues/86#issuecomment-432001824

* Another point is that the main client platform are Nokia Symbian
  phones — which are nearly nowhere in use anymore. I still do have
  such a phone, but for years the only reason to power it on was to
  test amora before uploading. Haven't powered it on since the last
  upload...

* There's code for a Qt client (Qt 4 or even older) which AFAIK never
  was published in any app store though. If I remember correctly I
  once got it running on my OpenMoko (i.e. ages ago). Or was it on the
  Nokia N900? Can't remeber anymore...

We still can bring it back when the Qt5 port is working properly and
there's a client for modern mobile phones (even if only for less
popular OS like KaiOS/GerdaOS or SailfishOS).

Upstream commented that mail in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874812#57 as
follows:

> I wrote Amora server/client way back in 2007 (13 years ago) and for
> a little while it was a pretty successful project. We had a PyS60
> (Nokia S60), J2ME client (never released) and a PythonEFL (Nokia
> tablets) client.
> 
> Around 2012, I expected that Linux would move to Wayland (so it
> would require a new amora-server) and Nokia smartphone sales were
> going down. So I planned to re-write the server (did some
> experiments with QtWayland in 2012) and the client (2015 Qt was
> fully functional on both Android and iOS) but never finished the
> task to port the server to Qt5.
> 
> Long story short, I support removing it from Debian as I lack the time to
> do the re-write and the devices that could run the client are long
> gone.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#952817: ITP: u2f-tomu - u2f token firmware for EFM32HG Tomu Board

[Louis-Philippe Véronneau]

Package: wnpp
Severity: wishlist
Owner: Louis-Philippe Véronneau 

* Package name: u2f-tomu
  Version : 1.0
  Upstream Author : Sergei Glushchenko 
* URL : https://github.com/gl-sergei/u2f-token
* License : GPLv3
  Programming Lang: C, Python
  Description : u2f token firmware for EFM32HG Tomu Board

This package provides the U2F binary firmware for the tomu EFM32HG
board. With it, you can flash your tomu and use it as a full-fledged u2f
second factor authentication (2FA) hardware token.

I want to package it to be able to create tomu U2F tokens 100% from
Debian packages. I've already packaged the bootloader (firmware-tomu)
and eventually plan to write a simple UI tool to help flash the boards.

I plan to maintain this package by myself.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Bug#936630: gnumed-client: fixed upstream

[Karsten Hilbert]

Package: gnumed-client
Version: 1.7.8+dfsg-1
Followup-For: Bug #936630

Upstream has released 1.8.0 which supports python3 (and needs wxpython4).

Please make python3-psycopg2 a 2.7 versioned dependency as
python3-psycopg2 2.8 seems to have some problems.

Karsten

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnumed-client depends on:
ii  aspell   0.60.7~20110707-6
ii  file 1:5.35-4+deb10u1
ii  gnumed-common1.7.8+dfsg-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  ispell   3.4.00-6+b1
ii  python   2.7.16-1
ii  python-egenix-mxdatetime 3.2.9-1
ii  python-enchant   2.0.0-1
ii  python-gnuplot   1.8-6
ii  python-hl7   0.3.4-3
ii  python-httplib2  0.11.3-2
ii  python-pip   18.1-5
ii  python-wxgtk3.0  3.0.2.0+dfsg-8
ii  python3-hl7 [python-hl7] 0.3.4-3
ii  texlive-latex-base   2018.20190227-2

Versions of packages gnumed-client recommends:
ii  aeskulap0.2.2-beta2+git20180219.8787e95-2
ii  amide   1.0.5-12+b1
ii  audiofile-tools 0.3.6-5
ii  chktex  1.7.6-2+b1
ii  dcmtk   3.6.4-2.1
ii  elinks [www-browser]0.13~20190125-3
ii  extract 1:1.8-2
ii  firefox [www-browser]   69.0-1
ii  freediams   0.9.4-2
ii  ginkgocadx  3.8.8-1
ii  gnumed-doc  1.7.8+dfsg-1
ii  gtklp   1.3.1-0.1+b1
ii  konqueror [www-browser] 4:18.12.0-1
ii  lacheck 1.26-17
ii  libimage-exiftool-perl  11.16-1
ii  libreoffice-writer  1:6.1.5-3+deb10u5
ii  ntp 1:4.2.8p12+dfsg-4
pn  pdftk   
ii  poppler-utils   0.71.0-5
ii  printer-driver-cups-pdf [cups-pdf]  3.0.1-5
ii  python-faulthandler 3.0-1
ii  python-pyqrcode 1.2.1-2
ii  python-vobject  0.9.6.1-0.1
ii  qpdf8.4.0-2
ii  texlive-latex-extra 2018.20190227-2
ii  texlive-latex-recommended   2018.20190227-2
ii  w3m [www-browser]   0.5.3-37
ii  wgerman-medical 20160103-3
ii  xdg-utils   1.1.3-1
ii  xmedcon 0.16.1+dfsg-1
ii  xsane   0.999-6+b1

Versions of packages gnumed-client suggests:
pn  autokey-qt | autokey-gtk
ii  edfbrowser  1.67+dfsg-1
ii  entangle2.0-1
pn  gimp | kolourpaint4 
ii  gnumed-server   22.8-1
ii  incron  0.5.12-1
pn  konsolekalendar 
pn  korganizer  
ii  libchipcard-tools   5.1.0beta-3
ii  nvram-wakeup1.1-4+b1
ii  pgadmin31.22.2-5
pn  python-uno  
ii  qrisk2  0.1.20150729-4
pn  shutdown-at-night   
pn  wakeonlan | etherwake | gwakeonlan  

-- no debconf information

Bug#936631: gnumed-server: fixed upstream

[Karsten Hilbert]

Package: gnumed-server
Version: 22.8-1
Followup-For: Bug #936631

Upstream has released 1.8.0/22.11 which supports python3.

Please make python:any -> python3:any.

(note that it has only be tested with py3.7, not py3.8, so maybe versioned ?)

Please make python3-psycopg2 a 2.7 versioned dependency as
python3-psycopg2 2.8 seems to have some problems.

Thanks,
Karsten

-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 
'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 5.4.0-4-686-pae (SMP w/2 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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnumed-server depends on:
ii  anacron   2.3-28
ii  bsd-mailx [mail-reader]   8.1.2-0.20180807cvs-1
ii  bzip2 1.0.6-9.2~deb10u1
ii  cron  3.0pl1-134+deb10u1
ii  debconf   1.5.71
ii  gnupg 2.2.19-1
ii  gnupg22.2.12-1+deb10u1
ii  kmail [mail-reader]   4:18.08.3-1
ii  mutt [mail-reader]1.10.1-2.1
ii  openssl   1.1.1d-0+deb10u2
ii  postgresql11+200+deb10u3
ii  postgresql-client 11+200+deb10u3
ii  postgresql-client-11 [postgresql-client]  11.7-0+deb10u1
ii  python2.7.16-1
ii  python-egenix-mxdatetime  3.2.9-1
ii  python-psycopg2   2.7.7-1
ii  rsync 3.1.3-6
ii  sudo  1.8.27-1+deb10u2

Versions of packages gnumed-server recommends:
pn  barman  

Versions of packages gnumed-server suggests:
pn  bacula-console   
ii  orthanc  1.5.6+dfsg-1
ii  orthanc-postgresql   3.2-1
ii  orthanc-webviewer2.5-1
ii  postgresql-contrib   11+200+deb10u3
ii  postgresql-filedump  11.0-1
pn  postgresql-plr   

-- no debconf information

Bug#952683: snakeyaml: CVE-2017-18640

[Salvatore Bonaccorso]

Hi Tony,

On Sat, Feb 29, 2020 at 09:51:32AM -0800, tony mancill wrote:
> On Thu, Feb 27, 2020 at 03:16:00PM +0100, Salvatore Bonaccorso wrote:
> > Source: snakeyaml
> > Version: 1.25+ds-2
> > Severity: important
> > Tags: security upstream
> > Forwarded: https://bitbucket.org/asomov/snakeyaml/issues/377
> > Control: found -1 1.23-1
> > Control: found -1 1.17-1
> > 
> > Hi,
> > 
> > The following vulnerability was published for snakeyaml.
> > 
> > CVE-2017-18640[0]:
> > | The Alias feature in SnakeYAML 1.18 allows entity expansion during a
> > | load operation, a related issue to CVE-2003-1564.
> > 
> > 
> > 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-2017-18640
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18640
> > [1] https://bitbucket.org/asomov/snakeyaml/issues/377
> > [2] 
> > https://bitbucket.org/asomov/snakeyaml/commits/b680ce64971d943083012c04690c0ffa9fea6da4
> 
> The upstream issue has been marked as resolved and the links to the
> proposed resolution returns a 404.  I agree that we should have an issue
> open in the tracker, but I don't see how this is actionable at this
> time.

*sigh*. When I filled the bug I'm pretty sure the referenced commit
*was* not resulting in a 404 :(

Please have a look at

https://bitbucket.org/asomov/snakeyaml/commits/da11ddbd91c1f8392ea932b37fa48110fa54ed8c

That is again the respective commit. Looks upstream did convert the
reposiitory.

Regards,
Salvatore

Bug#874812: [amora-server] Qt4 removal from Debian

[Adenilson Cavalcanti]

Gentlemen

Thanks for adding me in the thread, I really appreciate it.

I wrote Amora server/client way back in 2007 (13 years ago) and for a
little while it was a pretty successful project. We had a PyS60 (Nokia
S60), J2ME client (never released) and a PythonEFL (Nokia tablets) client.

Around 2012, I expected that Linux would move to Wayland (so it would
require a new amora-server) and Nokia smartphone sales were going down. So
I planned to re-write the server (did some experiments with QtWayland in
2012) and the client (2015 Qt was fully functional on both Android and iOS)
but never finished the task to port the server to Qt5.

Long story short, I support removing it from Debian as I lack the time to
do the re-write and the devices that could run the client are long gone.

Best regards

Adenilson Cavalcanti
BSc. Msc.
Principal Engineer - ARM
Chromium zlib maintainer


On Sat, Feb 29, 2020 at 2:19 AM Moritz Mühlenhoff  wrote:

> On Sat, Feb 29, 2020 at 01:47:20AM +0100, Axel Beckert wrote:
> > Hi Moritz,
> >
> > Moritz Mühlenhoff wrote:
> > > Attached is a quick-and-dirty patch to drop the amora-applet binary
> > > package, qt4 will soon be removed from unstable.
> >
> > Thanks for the effort, but in the meanwhile I'm rather think we should
> > remove amora completely from Debian, at least for now.
> >
> > Upstream (Cc'ed) tried to migrate to Qt5 about two years ago.
> > Compiling and running with Qt5 was not the big issue, but getting
> > Bluetooh working again — and hence core functionality:
> > https://github.com/amora/amora/issues/86#issuecomment-432001824
> >
> > Another point is that the main client platform are Nokia Symbian
> > phones — which are nearly nowhere in use anymore. I still do have such
> > a phone, but for years the only reason to power it on was to test
> > amora before uploading. Haven't powered it on since the last upload...
> >
> > There's IIRC code for a Qt client (Qt 4 I assume, maybe even older)
> > which AFAIK never was published in any app store though. If I remember
> > correctly I once got it running on my OpenMoko (i.e. ages ago). Or was
> > it on the Nokia N900? Can't remeber anymore...
> >
> > We still can bring it back when the Qt5 port is working properly and
> > there's a client for modern mobile phones (even if only for less
> > popular OS like KaiOS/GerdaOS or SailfishOS).
>
> Sounds good, removing it entirely is fair enough. Are you filing an RM
> bug? Otherwise I can do it as well.
>
> Cheers,
> Moritz
>

Bug#952816: ITP: metadata-json-lint -- Utility to verify Puppet metadata.json files

[Gabriel Filion]

Package: wnpp
Severity: wishlist
Owner: Gabriel Filion 

* Package name: metadata-json-lint
  Version : 2.2.0
  Upstream Author : Vox Pupuli 
* URL : https://github.com/voxpupuli/metadata-json-lint
* License : Apache-2.0
  Programming Lang: Ruby
  Description : Utility to verify Puppet metadata.json files

The metadata-json-lint tool validates and lints metadata.json files in Puppet
modules against style guidelines from the Puppet Forge module metadata
recommendations.

metadata.json files are, as implied by the extension in the name, using a JSON
syntax but a specific schema is expected to be used to format information in
the data structure. They are helpful for specifying dependencies to Puppet
modules and for making license and other such metadata parseable by a machine.
This file is expected to be present when a module is published to the Puppet
forge.


This package is generally useful for Puppet module developers. It is also a
dependency of puppet-development-kit, since it uses it directly to run
verifications on modules.

I plan to maintain this package within the ruby team and will ask for
sponsorship from the team.

Bug#951916: proftpd-mod-vroot: proftpd cannot load mod_vroot

[Hilmar Preuße]

On 2/29/20 8:58 AM, Nikolai Lusan wrote:

Hi,

> Sorry I haven't gotten back to you yet. I have a number of projects
> on the go, and since this is only impacting a small number of users
> on my home system it has fallen lower on my priority list - I was
> also trying to find solutions myself.
>The reason why I ask is that we have a security issue in the proftp
1.3.6b in Debian testing, which has been solved in unstable. Therefore
I'd like to migrate that version ASAP. However I need to know if that
causes other issues, like incompatibility w/ mod-vroot, which needs to
be addressed by upstream.

> Apparently there are people that have the code from the upstream git 
> repository working with current proftpd, but I haven't had time to 
> dig into the differences in compilation methods.
> 
I've provided two possible solutions (downgrade proftpd and upgrade to
proftp-mod-vroot compiled w/ proftp v1.3.6c). Please try both and report
back if one of both solves the issue.

Many thanks!

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



signature.asc
Description: OpenPGP digital signature

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

[John David Anglin]

On 2020-02-29 2:05 p.m., Martin wrote:
> On 2020-02-29 09:42, John David Anglin wrote:
>> Think the unit-test-server must die before it is looked for.
> Too bad, it seems to be a different problem then.
> Thanks for testing, John!
I built package outside buildd.  Attached are log files.

-- 

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

===
   libmodbus 3.1.6: tests/test-suite.log
===

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

.. contents:: :depth: 2

FAIL: ./unit-tests.sh
=

Starting server
Starting client
unit-test-server: no process found
FAIL unit-tests.sh (exit status: 255)

ERROR Connection timed out: select
ERROR Illegal data address
ERROR Illegal data address
ERROR Illegal data address
ERROR Illegal data address
ERROR Illegal data address
ERROR Illegal data address
ERROR Illegal data address
ERROR Illegal data address
Connecting to 127.0.0.1:1502
** UNIT TESTING **
1/1 No response timeout modification on connect: OK

TEST WRITE/READ:
[00][01][00][00][00][06][FF][05][01][30][FF][00]
Waiting for a confirmation...
<00><01><00><00><00><06><05><01><30><00>
1/2 modbus_write_bit: OK
[00][02][00][00][00][06][FF][01][01][30][00][01]
Waiting for a confirmation...
<00><02><00><00><00><04><01><01><01>
2/2 modbus_read_bits: OK
OK
[00][03][00][00][00][0C][FF][0F][01][30][00][25][05][CD][6B][B2][0E][1B]
Waiting for a confirmation...
<00><03><00><00><00><06><0F><01><30><00><25>
1/2 modbus_write_bits: OK
[00][04][00][00][00][06][FF][01][01][30][00][25]
Waiting for a confirmation...
<00><04><00><00><00><08><01><05><6B><0E><1B>
2/2 modbus_read_bits: OK
OK
OK
OK
OK
OK
OK
[00][05][00][00][00][06][FF][02][01][C4][00][16]
Waiting for a confirmation...
<00><05><00><00><00><06><02><03><35>
1/1 modbus_read_input_bits: OK
OK
OK
OK
OK
[00][06][00][00][00][06][FF][06][01][60][12][34]
Waiting for a confirmation...
<00><06><00><00><00><06><06><01><60><12><34>
1/2 modbus_write_register: OK
[00][07][00][00][00][06][FF][03][01][60][00][01]
Waiting for a confirmation...
<00><07><00><00><00><05><03><02><12><34>
2/2 modbus_read_registers: OK
OK
[00][08][00][00][00][0D][FF][10][01][60][00][03][06][02][2B][00][01][00][64]
Waiting for a confirmation...
<00><08><00><00><00><06><10><01><60><00><03>
1/5 modbus_write_registers: OK
[00][09][00][00][00][06][FF][03][01][60][00][03]
Waiting for a confirmation...
<00><09><00><00><00><09><03><06><02><2B><00><01><00><64>
2/5 modbus_read_registers: OK
OK
OK
OK
[00][0A][00][00][00][06][FF][03][01][60][00][00]
Waiting for a confirmation...
Bytes flushed (9)
3/5 modbus_read_registers (0): OK
[00][0B][00][00][00][0F][FF][17][01][60][00][03][01][61][00][02][04][00][00][00][00]
Waiting for a confirmation...
<00><0B><00><00><00><09><17><06><02><2B><00><00><00><00>
4/5 modbus_write_and_read_registers: OK
OK
OK
OK
[00][0C][00][00][00][06][FF][04][01][08][00][01]
Waiting for a confirmation...
<00><0C><00><00><00><05><04><02><00><0A>
1/1 modbus_read_input_registers: OK
OK
1/1 Write mask: [00][0D][00][00][00][06][FF][06][01][60][00][12]
Waiting for a confirmation...
<00><0D><00><00><00><06><06><01><60><00><12>
[00][0E][00][00][00][08][FF][16][01][60][00][F2][00][25]
Waiting for a confirmation...
<00><0E><00><00><00><08><16><01><60><00><00><25>
OK
[00][0F][00][00][00][06][FF][03][01][60][00][01]
Waiting for a confirmation...
<00><0F><00><00><00><05><03><02><00><17>
OK

TEST FLOATS
1/4 Set/get float ABCD: OK
OK
2/4 Set/get float DCBA: OK
OK
3/4 Set/get float BADC: OK
OK
4/4 Set/get float CDAB: OK
OK

At this point, error messages doesn't mean the test has failed

TEST ILLEGAL DATA ADDRESS:
[00][10][00][00][00][06][FF][01][00][00][00][01]
Waiting for a confirmation...
<00><10><00><00><00><03><81><02>
* modbus_read_bits (0): OK
[00][11][00][00][00][06][FF][01][01][30][00][26]
Waiting for a confirmation...
<00><11><00><00><00><03><81><02>
* modbus_read_bits (max): OK
[00][12][00][00][00][06][FF][02][00][00][00][01]
Waiting for a confirmation...
<00><12><00><00><00><03><82><02>
* modbus_read_input_bits (0): OK
[00][13][00][00][00][06][FF][02][01][C4][00][17]
Waiting for a confirmation...
<00><13><00><00><00><03><82><02>
* modbus_read_input_bits (max): OK
[00][14][00][00][00][06][FF][03][00][00][00][01]
Waiting for a confirmation...
<00><14><00><00><00><03><83><02>
* modbus_read_registers (0): OK
[00][15][00][00][00][06][FF][03][01][60][00][21]
Waiting for a confirmation...
<00><15><00><00><00><03><83><02>
* modbus_read_registers (max): OK
[00][16][00][00][00][06][FF][04][00][00][00][01]
Waiting for a confirmation...
<00><16><00><00><00><03><84><02>
* modbus_read_input_registers (0): OK
[00][17][00][00][00][06][FF][04][01][08][00][02]
Waiting for a confirmation...
<00><17><00><00><00><03><84><02>
* modbus_read_input_registers (max): OK
[00][18][00][00][00][06][FF][05][00][00][FF][00]
Waiting for a confirmation...
<00><18><00><00><00><03><85ERROR Illegal data address
ERROR Illegal data 

Bug#943481: Please update Pdfarranger to latest version 1.4.1

[Xavier Guillot]

Hi,

Pdfarranger is now on version 1.4.1.

There has been many improvements since fork and version 1.1.1 from 
December 2018, it would be very great to see the Debian package updated !


Thanks in advance and best regards.

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

[Martin]

On 2020-02-29 09:42, John David Anglin wrote:
> Think the unit-test-server must die before it is looked for.

Too bad, it seems to be a different problem then.
Thanks for testing, John!

Bug#952815: grub2: Please drop TARGET_CCASFLAGS from debian/rules for 2.06 release

[John Paul Adrian Glaubitz]

Source: grub2
Version: 2.04-5
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

The upcoming 2.06 release contains a fix to set -no-PIE in TARGET_CCASFLAGS [1]
such that the current workaround in debian/rules will no longer be necessary.

The following patch should be applied to debian/rules once 2.06-1 is uploaded
to the archive:

--- debian/rules.orig   2019-12-16 16:48:45.0 +0100
+++ debian/rules2020-02-29 19:40:17.759252139 +0100
@@ -23,10 +23,6 @@
 export TARGET_CPPFLAGS := -Wno-unused-but-set-variable
 export TARGET_LDFLAGS := -no-pie
 
-ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU)))
-export TARGET_CCASFLAGS := -fno-PIE
-endif
-
 # Ensure that debhelper doesn't try to set these; we need to be careful
 # about HOST_* vs. TARGET_*.
 export CPPFLAGS :=

Before 2.06, the workaround in debian/rules needs to be kept.

Thanks,
Adrian

> [1] 
> http://git.savannah.gnu.org/cgit/grub.git/commit/?id=c71be831f159ab5b8913132143bdb783a8b4b2a3

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

Bug#952814: libfaudio0: request for package to be available from buster-backports

[Tomi Juntunen]

Package: libfaudio0
Severity: wishlist

Dear Maintainer,

Wine 5.0+ requires libfaudio0 as a dependency. WineHQ instructions guide 
to install the deb package
as mentioned in the wiki page https://wiki.winehq.org/Debian. libfaudio0 
is also available
in Debian unstable and testing 
https://packages.debian.org/search?keywords=libfaudio0.


Would it be possible to have the package available in buster-backports 
as well?


On the eligibility considerations from the Debian backports contribution 
guidelines:


* Package would be useful for all Debian stable users who wish to 
install and run latest

  versions of Wine from the official WineHQ repositories.
* Backports could guarantee an upgrade channel for package updates and 
the next stable release from

  the distribution's own official package repository.

Kind regards,

Tomi Juntunen


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

Kernel: Linux 4.19.0-8-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE= (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#952813: ITP: pymap3d -- https://github.com/geospace-code/pymap3d

[Antonio Valentino]

Package: wnpp
Severity: wishlist
Owner: Antonio Valentino 

* Package name: pymap3d
  Version : 2.3.0
  Upstream Author : Michael Hirsch, Ph.D.

* URL : https://github.com/geospace-code/pymap3d
* License :   Programming Lang: Python
  Description : pure-Python 3D coordinate conversions for geospace

Binary package names: python3-pymap3d pypy-pymap3d

 Pure Python (no prerequistes beyond Python itself) 3-D geographic
 coordinate conversions and geodesy.
 API similar to popular $1000 Matlab Mapping Toolbox routines for
 Python.
 .
 PyMap3D is intended for non-interactive use on massively parallel (HPC)
 and embedded systems.
 Includes some relevant Vallado algorithms.
 .
 The package provides conversion functions between the following
 coordinate systens:
 aer, ecef, eci, enu, geodetic, geocentric, ned, azel, radec.

Bug#952785: buster-pu: package dojo/1.15.0+dfsg1-1+deb10u1

[Xavier]

Le 29/02/2020 à 14:48, Salvatore Bonaccorso a écrit :
> Hi Xavier,
> 
> On Sat, Feb 29, 2020 at 09:10:51AM +0100, Xavier Guimard wrote:
>> Package: release.debian.org
>> Severity: normal
>> Tags: buster
>> User: release.debian@packages.debian.org
>> Usertags: pu
>>
>> Hi,
>>
>> dojo is vulnerable to Cross-site Scripting. This is due to
>> dojox.xmpp.util.xmlEncode only encoding the first occurrence of each
>> character, not all of them.
>>
>> This upstream patch fixes this issue
>>
>> Cheers,
>> Xavier
> 
>> diff --git a/debian/changelog b/debian/changelog
>> index 14447b52..0e5dc462 100644
>> --- a/debian/changelog
>> +++ b/debian/changelog
>> @@ -1,3 +1,10 @@
>> +dojo (1.15.0+dfsg1-1+deb10u1) buster; urgency=medium
>> +
>> +  * Team upload
>> +  * Cleanup improper regex usage (Closes: #952771, 2019, 10785)
>   ^^^
> Did you mean CVE-2019-10785 here?
> 
> Regards,
> Salvatore

Oups sorry, Gbp-Dch mis-interpret my commit. Yes this closes CVE-2019-10785.

Bug#952812: libvirt-daemon: virt-manager and vagrant create non sparse disks

[Tomas Kuliavas]

Package: libvirt-daemon
Version: 5.0.0-4+deb10u1
Severity: normal

Dear Maintainer,


   * What led up to the situation?
images created by vagrant (libvirt provider) and virt-manager used up too
much space

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

virt-sparsify --in-place /var/lib/libvirt/images/debian10.qcow2
image converted to sparse format.

"virt-install --virt-type kvm --name buster-amd64 --cdrom
~/Downloads/debian-10.3.0-amd64-netinst.iso --os-variant debian10 --disk
size=10 --memory 1000" created sparse image

   * What was the outcome of this action?

space saved on /var/lib/libvirt

   * What outcome did you expect instead?

I expected to see sparse disk as default or as option in virt-manager.



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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.53-4
ii  libapparmor12.13.2-10
ii  libaudit1   1:2.8.4-3
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-10
ii  libcap-ng0  0.7.9-2
ii  libcurl3-gnutls 7.64.0-4+deb10u1
ii  libdbus-1-3 1.12.16-1
ii  libdevmapper1.02.1  2:1.02.155-3
ii  libfuse22.9.9-1
ii  libgcc1 1:8.3.0-6
ii  libgnutls30 3.6.7-4+deb10u2
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-25
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27+dfsg-1+deb10u1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2.1
ii  libudev1241-7~deb10u3
ii  libvirt05.0.0-4+deb10u1
ii  libxenmisc4.11  4.11.3+24-g14b62ab3e5-1~deb10u1
ii  libxenstore3.0  4.11.3+24-g14b62ab3e5-1~deb10u1
ii  libxentoollog1  4.11.3+24-g14b62ab3e5-1~deb10u1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.195-2
ii  qemu-kvm1:3.1+dfsg-8+deb10u4

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.0.0-4+deb10u1
pn  numad  

-- no debconf information

Bug#940879: Link with libedit instead of readline5

[Bastian Germann]

https://salsa.debian.org/mariadb-team/mariadb-10.4/-/merge_requests/3

Bug#952683: snakeyaml: CVE-2017-18640

[tony mancill]

On Thu, Feb 27, 2020 at 03:16:00PM +0100, Salvatore Bonaccorso wrote:
> Source: snakeyaml
> Version: 1.25+ds-2
> Severity: important
> Tags: security upstream
> Forwarded: https://bitbucket.org/asomov/snakeyaml/issues/377
> Control: found -1 1.23-1
> Control: found -1 1.17-1
> 
> Hi,
> 
> The following vulnerability was published for snakeyaml.
> 
> CVE-2017-18640[0]:
> | The Alias feature in SnakeYAML 1.18 allows entity expansion during a
> | load operation, a related issue to CVE-2003-1564.
> 
> 
> 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-2017-18640
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-18640
> [1] https://bitbucket.org/asomov/snakeyaml/issues/377
> [2] 
> https://bitbucket.org/asomov/snakeyaml/commits/b680ce64971d943083012c04690c0ffa9fea6da4

The upstream issue has been marked as resolved and the links to the
proposed resolution returns a 404.  I agree that we should have an issue
open in the tracker, but I don't see how this is actionable at this
time.

Cheers,
tony

Bug#952806: [Pkg-rust-maintainers] Bug#952806: cbindgen: please package recent version 0.13.1 into experimental

[Sylvestre Ledru]

Hello

Will do! :)

I didn't upload it to prevent more issues in the long overdue migration 
but I guess exp doesn't hurt!


S


Le 29/02/2020 à 15:33, Carsten Schoenert a écrit :

Package: cbindgen
Version: 0.12.1-1
Severity: wishlist

Dear Maintainers of cbindgen,

please consider packaging of cbindgen version >= 0.13 for experiemntal.

I'm trying to work on the current most recent Thunderbird beta version
74.0~b2 and this is requiring cbindgen >= 0.13. So providing cbindgen
within experimental would help me much.

Thanks
Carsten

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/6 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)
LSM: AppArmor: enabled

___
Pkg-rust-maintainers mailing list
pkg-rust-maintain...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers

Bug#583958: pam_umask --enable-usergroups compile-time option

[Andreas Henriksson]

Hello,

On Fri, Jan 10, 2020 at 01:34:20PM +0100, Andreas Henriksson wrote:
[...]
> Please let me know if the above is satisfactory and if you'd like me to
> send a merge-request for an updated packaging!

I assume you've already noticed, but for the record
https://salsa.debian.org/vorlon/pam/-/merge_requests/3
was opened shortly after sending the above quoted mail.

> If you happen to see any other outstanding issues you think are blockers
> for this please also let me know about those!

Given almost 2 months has passed without a comment I assume it's
up to me to NMU the changes, which I'll be doing if I don't
hear anything in the next couple of weeks.

Regards,
Andreas Henriksson

Bug#937508: pyptlib: Python2 removal in sid/bullseye

[Chris Lamb]

Hi,

> pyptlib: Python2 removal in sid/bullseye

I would suggest we remove this package rather than update for Python
3; the last update was in April 2014, it has no reverse-dependencies,
etc.

(We can always re-upload if needed...)


Best wishes,

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

Bug#952780: hplip: Strange dpkg-statoverride usage

[Didier 'OdyX' Raboud]

Hello Guillem, and thanks for your bugreport,

Le samedi, 29 février 2020, 00.39:56 h CET Guillem Jover a écrit :
> This package is making incorrect use of dpkg-statoverride for a
> volatile pathname under /run that is not managed by dpkg.

This code predates my time and is in hplip since at least 2005. But now is a
 good time to fix it.

> In addition the recent migration from /var/run to /run does not include
> cleanup of /var/run.

My understanding is that as /var/run is a symlink to /run, there's no cleanup
to be done. Or are you talking about cleaning up the dpkg-statoverride's
database? In that case, both the /var/run/hplip _and_ the /run/hplip entries
now would need to be removed from that database, right?

> statoverrides are intended to be used on pathnames shipped by a
> package that dpkg will unpack, otherwise this will have no effect if
> the path did not exist at --update time. While there are plans to
> add support for volatile/ghost files to dpkg, this is not the case
> right now, so you need to manage this in some other way for /run,
> and cleanup the statoverride for /run and /var/run to avoid leaving
> cruft behind.

This seems to confirm my understanding from above.

I have checked the hplip code and it seems that the rundir is not in use at
all, so just removing this code (and the statoverride entries) should just
work.

So would this be an appropriate patch?

--- a/debian/hplip.postinst
+++ b/debian/hplip.postinst
@@ -20,10 +20,11 @@ case "$1" in
  exit 1
}
 
-   for i in /run/hplip
+# Statoverrides in ephemeral directories don't work. They should be 
removed (#952580)
+   for i in /run/hplip /var/run/hplip
do
if ! dpkg-statoverride --list $i > /dev/null; then
-   dpkg-statoverride --update --add hplip root 755 $i
+   dpkg-statoverride --remove $i
fi
done

Thanks for your input!

Cheers,
OdyX

Bug#944920: Revise terminology used to specify requirements

[Sean Whitton]

Hello Guillem,

On Thu 30 Jan 2020 at 01:16AM +01, Guillem Jover wrote:

> Some of the words chosen to convey normative meaning are glue words
> used to build pretty mundane sentences, so having them appear around
> while they might not convey normative meaning seems rather confusing,
> and is a mental overhead when reading or drafting new text. Probably
> more for non-native speakers.

Thank you, I hadn't thought of it in terms of increasing the effort
required to draft new text, which holds even if we fix all existing
instances.

> For example in ch-scope.rst in the entry describing the *may* keyword
> the following sentence uses also «may». :) The ch-archive.rst contains
> several «may» instances that do not feel like the normative *may*, at
> least the ones in the DFSG?
>
> Perhaps instead of the potentially ugly uppercased keywords, marking
> them as *keyword* like in the definition of the terms would go a long
> way?

One issue with using uppercased words is that people might think the
words have the same meaning as they do in RFCs, which they don't.

Your idea of marking keywords in bold wouldn't have this problem, and
maybe it would actually make it /easier/ to write patches because you
can see more clearly which of your words mean what.

Thinking more, I believe that the issue you're raising here is separate
from what Russ is trying to achieve in this bug.  The problem you're
identifying here already exists in Policy, before Russ's change is
applied.  So maybe we should discuss it separately.

> BTW I guess the instances of «might» and «shall» need to be converted,
> or added to the keyword list? What about «may not», or «can», «can't»,
> «cannot» and «could»? And I'm probably missing other words. :)

I don't think we need to convert words that don't explicitly appear in
the keywords list -- "may not" would inherit its meaning from "may"
being a keyword, wouldn't it?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#948844: debmake: option for git maintained packages

[Sean Whitton]

Hello Matt,

On Sat 25 Jan 2020 at 04:06PM -08, Matt Taggart wrote:

> I am following the the "When upstream tags releases in git" section of
> dgit-maint-merge(7) and when I get to the "Now go ahead and
> Debianise..." section I'd like to be able to run debmake, but it's
> expecting the source dir to have a particular name and the orig tarball
> to exist.

Ah, okay.  It seems that the problem with debmake you identify here is
not specific to dgit-maint-merge(7), as most any git-based workflow will
not have the source dir include the version number, and many of them
won't have the orig.tar exist yet.

>> s/debhelper/debmake/ right?
>
> Yes, sorry.
>>> 1) don't create debian/patches/
>>>
>>> 2) don't create debian/source/local-options
>>>
>>> 3) I'm not sure if watch is needed
>>>
>>> 4) create debian/source/options containing:
>>> single-debian-patch
>>> auto-commit
>>>
>>> 5) create debian/source/patch-header with a description of how to get
>>> changes to the upstream source. I guess this should be a template that
>>> fills in package name and git repo?
>>>
>>> For #3 and #4 see the dgit-maint-merge(7) manpage for examples and
>>> explanation.
>>
>> I think that debmake might not be the right place for (2), (4) and (5).
>> Instead, I think a 'maintmerge' script in the dgit package should do
>> that setup, so that non-debmake users can take advantage.  See #852226.
>
> debmake is already creating a template for (2).
> I like the idea of putting these steps in a dgit script though and
> having the dgit-maint-merge(7) manpage explain how to use it. Then maybe
> debmake could add a basic mode to handle the other remaining things.

I agree.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952811: [apt-cacher-ng] 500 Bad redirection (path)

[Jean-Marc LACROIX]

Package: apt-cacher-ng
Version: 3.2-2
Severity: grave

Dear maintainers,

It seems there is a cache or DNS issue (?) sometimes when trying
to access from my internal local network to public Internet.

My clients targets are either armhf, either arm64 or amd64 running
Debian Buster 10.3

Apt-cacher-ng is running on armhf target

With following file : /etc/apt/apt.conf.d/apt_conf_proxy_http_https

ansible@pinebook:~$  grep -i Acqui 
/etc/apt/apt.conf.d/apt_conf_proxy_http_https

Acquire::http::proxy "http://srv-apt-cacher-110-service:3142;;
Acquire::https::proxy "http://srv-apt-cacher-110-service:3142;;

ansible@pinebook:~$ grep -iR ^Deb /etc/apt/
/etc/apt/sources.list.d/debian_apt_v_10_buster_current.list:deb 
http://ftp.debian.org/debian/ buster main contrib non-free
/etc/apt/sources.list.d/debian_apt_v_10_buster_updates.list:deb 
http://ftp.fr.debian.org/debian buster-updates main contrib non-free
/etc/apt/sources.list.d/armbian_apt_v_10_buster.list:deb 
http://apt.armbian.com buster main buster-utils buster-desktop
/etc/apt/sources.list.d/debian_apt_v_10_buster_previous.list:deb 
http://ftp.debian.org/debian/ stretch main contrib non-free
/etc/apt/sources.list.d/debian_apt_v_10_buster_update_security.list:deb 
http://security.debian.org buster/updates main contrib non-free
/etc/apt/sources.list.d/debian_apt_v_10_buster_backports.list:deb 
http://ftp.fr.debian.org/debian buster-backports main contrib non-free



test 1: The issue ...
-

ansible@pinebook:~$ sudo apt update
Hit:1 http://ftp.fr.debian.org/debian buster-backports InRelease
Err:2 http://apt.armbian.com buster InRelease
  500  Bad redirection (path) [IP: 192.168.54.79 3142]
Hit:3 http://ftp.debian.org/debian buster InRelease
Hit:4 http://security.debian.org buster/updates InRelease
Hit:5 http://ftp.fr.debian.org/debian buster-updates InRelease
Ign:6 http://ftp.debian.org/debian stretch InRelease
Hit:7 http://ftp.debian.org/debian stretch Release
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch http://apt.armbian.com/dists/buster/InRelease  500 
Bad redirection (path) [IP: 192.168.54.79 3142]
W: Some index files failed to download. They have been ignored, or old 
ones used instead.

ansible@pinebook:~$

ansible@pinebook:~$ host 192.168.54.79
79.54.168.192.in-addr.arpa domain name pointer 
srv-apt-cacher-110-service.noip.jml.



test 2: no more issue (!)
-

ansible@pinebook:~$ sudo sed -i -e 's/Acquire/#Acquire/g' 
/etc/apt/apt.conf.d/apt_conf_proxy_http_https


ansible@pinebook:~$ sudo apt update
Hit:1 http://ftp.fr.debian.org/debian buster-backports InRelease
Hit:2 http://ftp.fr.debian.org/debian buster-updates InRelease 

Hit:3 http://ftp.debian.org/debian buster InRelease 

Ign:4 http://ftp.debian.org/debian stretch InRelease 

Hit:5 http://security.debian.org buster/updates InRelease 

Hit:6 http://ftp.debian.org/debian stretch Release 


Hit:7 https://apt.armbian.com buster InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
ansible@pinebook:~$


Thanks in advance for your help
Best regards

Bug#952810: RFH: ebib -- BibTeX database manager for Emacs

[Sean Whitton]

Package: wnpp
Severity: normal

I request assistance with maintaining the ebib package.  Upstream makes
a lot of releases and I haven't been able to keep up for a while.

A current blocker for updating to a more recent release is that upstream
changed how their documentation is built.  Fixing this might be an
interesting project for one of our newer Emacsen Team members; I can
sponsor uploads.

I still rely on ebib for work and so would like to stay involved in
maintainance.

The package description is:
 Ebib is a BibTeX database manager that runs in Emacs.  With Ebib, you
 can create and manage .bib-files, all within Emacs.  It supports @string
 and @preamble definitions, multi-line field values, searching, and
 integration with Emacs' (La)TeX mode.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#952809: ITP: minilla -- CPAN module authoring tool

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: minilla
  Version : 3.1.9
  Upstream Author : Tokuhiro Matsuno 
* URL : https://metacpan.org/release/Minilla
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : CPAN module authoring tool

Minilla is a CPAN module authoring tool. Minilla provides the minil command
for creating, testing, releasing, installing, and uploading CPAN
distributions.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Bug#879755: tries to install apt-transport-https even if doesn't exist

[Hideki Yamane]

Hi,

 Just simply checking codename patch for debootstrap is here, comments
 are welcome.

 https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/41/diffs


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#948656: firejail-profiles: firefox-esr running under firejail does not load correct preferences

[/dev/fra]

On 23/01/20 20:48:07 CET, Reiner Herrmann wrote:
> On Thu, Jan 23, 2020 at 08:25:10PM +0100, /dev/fra wrote:
> > Just a quick update, upgrading to firejail-profiles 0.9.62-3 does not fix
> > the issue while downgrading to version 0.9.60-2 does it. So it seems that
> > this issue is definitely caused by a change introduced after 0.9.60-2.
> [...]
> The changes between these two version were not so big.
> In firefox.profile these two lines are new:
> 
> whitelist /usr/share/mozilla
> include whitelist-usr-share-common.inc

This is it, commenting out the lines above prevents the issue to happen.

For sake of completeness, the lines added in firefox.profile between 0.9.60-2 
and 0.9.62-3 are these:

whitelist /usr/share/mozilla
whitelist /usr/share/webext
include whitelist-usr-share-common.inc

However by commenting them out we get the issue reported in #948558, and maybe 
something more. I noted in fact that also something else gets out of place 
(with this version of firejail), but I couldn't test it further.

Now, the two whitelist entries are clear, I have also quickly skimmed 
whitelist-usr-share-common.inc but I really couldn't say what is causing this 
odd behaviour. I am starting to wonder if the problem might lie in firefox 
itself, because it is like part of the user preferences are set to certain 
defaults should some conditions change.

For example, try this other test:

1. Create a new firefox test profile, change these preferences
a. General, Always check if Firefox is your default browser --> Unset
b. Home, Homepage and new windows --> debian.org
c. Privacy & Security, Content Blocking --> Strict
d. Privacy & Security, Allow Firefox to send technical... --> Unset
  and quit firefox.
2. Run such profile with firejail (firejail firefox -P test), note that
- firefox asks to be set as default browser;
- indeed preferences a. and d. have been enabled;
3. While running the test profile with firejail, change preferences a. and d. so
  that they are unset, quit firefox;
4. Run again the test profile with firejail, preferences set in step 3 have been
  retained, quit firefox;
5. Run the test profile this time without firejail, note that preferences set in
  step 1 (and 3) remained unchanged, quit firefox;
6. Run one more time the test profile with firejail, and note that preferences
  a. and d. have been enabled once again (like in step 2).

So, most of the user preferences are retained but some are altered when firefox 
is ran with firejail. But I do not understand how and why this happens, given 
that user preferences should be just saved in ~/.mozilla/firefox//, a 
path that does should be accessible by firefox without so much restriction from 
firejail.

Cheers

Bug#952807: RFA: cider

[Sean Whitton]

Package: wnpp
Severity: normal

I request an adoptor for CIDER.

Updating CIDER to new upstream releases is more work than typical Emacs
addons, because it is tightly coupled to Clojure.  The current upstream
release, in particular, requires a lot of work to get the -doc packages
to include the new docs.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

The package description is:
 CIDER is the Clojure(Script) Interactive Development Environment that Rocks
 .
 While clojure-mode provides Emacs support for editing Clojure source files,
 CIDER's cider-mode provides support for interacting with a running Clojure
 process for compilation, debugging, looking up definitions and more.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Ritesh Raj Sarraf]

Dear Adam,

On Tue, 2020-02-25 at 21:10 +, Adam D. Barratt wrote:
> On Mon, 2020-02-24 at 15:37 +0530, Ritesh Raj Sarraf wrote:
> > So my changelog was incorrect as it set to 20070815.3-1+deb10u4,
> > which actually should be 20070815.3-1+deb10u1, as this is uml-
> > utilities package's first stable update proposed.
> 
> No. stable currently has 20070815.2-1, so this should either be .2-
> 1+deb10u1 (adding the patch on top of the stable package) or
> -3.1~deb10u1 (backporting the newer upload).
> 

Do you mean the latter (i.e. a new upstream release) can go into Debian
Stable as a update package ?


> Your diff appears to do the latter, while repeating (in different
> words) the fix. That isn't actually what would have changed in the
> stable upload (relative to the unstable one), which is simply the
> backporting.
> 
> +  * Use standard path for libray installation. (Closes: #928924)

I would really appreciate if I could get some of your help here.

To keep things simple, I chose to redo the update and just carry a
patch on top of 20070815.2-1.

To do so, I fetched and unpacked the current Buster uml-utilities
package.

rrs@priyasi:/var/tmp/Debian-Build/temp/uml-utilities-20070815.2$ ls -a
./   Changelog  CVS/ gdb/ honeypot/  jail/  lib/  mconsole/  
patches/  port-helper/  umlfs/   uml_net/ uml_util.spec.in
../  COPYINGdebian/  gdbbot/  humfsify/  jailtest/  Makefile  moo/   
.pc/  tunctl/   umlgdb/  uml_switch/  watchdog/
20:44 ♒ ॐ  ☺ 


It looks to be that I may have messed up the packaging for the package
in the upload to Buster. This source package already contains a .pc/
folder, which in my understanding, it should not. But this is now
already part of Debian Buster.

If I try to add a quilt patch for the actual issue, I run into other
packaging related problems.

dh_clean
 dpkg-source -i.git -I.git -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building uml-utilities using existing 
./uml-utilities_20070815.2.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: local changes detected, the modified files are:
 uml-utilities-20070815.2/Makefile
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/uml-utilities_20070815.2-1+deb10u1.diff.WPat51
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -i.git -I.git -b . subprocess returned 
exit status 2
I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: cleaning the build env 
I: removing directory /var/tmp/Debian-Build/Build//278087 and its subdirectories
gbp:error: '/home/rrs/bin/gbp-pbuilder' failed: it exited with 1


I think the problem is that the orig tarball already had a patch
applied on top of it and with a new patch introduced, the conflicts
arise.



I spent a couple of hours this Friday but couldn't fix this. Is this
something you can help me with? Ultimately, I want the attached patch
in this email, to be carried for Debian Buster.

If the mess is too much and fixing it is not possible, would it be okay
from a Stable checkpoint perspective, if:
* I did a new upstream release (fixing the orig tarball mess)
* Pushed it to Debian Unstable first
* And then, pushed the same to Debian Buster

Thanks,
Ritesh

-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System
From 17c533b18845cb262656b404138474115d592d7e Mon Sep 17 00:00:00 2001
From: Ritesh Raj Sarraf 
Date: Mon, 6 Jan 2020 22:32:02 +0530
Subject: [PATCH] Use standard path for libray installation.

/usr/lib64 isn't really a thing and is empty on my amd64 Debian system.

Closes: #928924
---
 Makefile | 5 -
 1 file changed, 5 deletions(-)

diff --git a/Makefile b/Makefile
index 74d3632..c0acd3f 100644
--- a/Makefile
+++ b/Makefile
@@ -5,12 +5,7 @@ SUBDIRS = lib jail jailtest humfsify mconsole moo port-helper $(TUNCTL) \
 UMLVER = $(shell date +%Y%m%d)
 TARBALL = uml_utilities_$(UMLVER).tar.bz2
 BIN_DIR = /usr/bin
-
-ifeq ($(shell uname -m),x86_64)
-LIB_DIR = /usr/lib64/uml
-else
 LIB_DIR = /usr/lib/uml
-endif
 
 CFLAGS = -g -Wall
 #CFLAGS = -g -O2 -Wall
-- 
2.25.0



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

Bug#952808: RFA: clojure-mode

[Sean Whitton]

Package: wnpp
Severity: normal

I request an adoptor for the clojure-mode package.

This is a team-maintained package, so the adoptor should either replace
me in Uploaders:, or alternatively take the package out of the team's
hands.

The package description is:
 Provides font-lock (syntax highlighting), indentation, navigation and basic
 refactoring for the Clojure programming language (http://clojure.org).
 .
 Also provides clojurescript-mode, clojurec-mode (for .cljc files) and
 clojurex-mode (for .cljx files).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941900: Build problem with 3.3.0

[Markus Koschany]

Hi Russell,

Am 29.02.20 um 11:42 schrieb Russell Coker:
> I'm just trying to get 3.3.0 to build and I'm stuck on the micro-ECC part.  
> The latest version of Warzone2100 in Unstable has patches to remove use of 
> the 
> 3rdparty directory.  But it seems that we don't have Micro ECC (uECC.h) by 
> Kenneth MacKay in Debian.
> 
> Should I keep the 3rdparty version of that or should I package Micro ECC 
> which 
> is licensed under the BSD 2-clause license?

Thank you for working on Warzone2100. I believe you don't need to
package Micro ECC. The upstream project doesn't seem to be active
anymore and h2o is the only other source package in Debian (according to
codesearch.debian.net) that makes use of it.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#952399: OpenSSL linking without license exception

[Bastian Germann]

A side note: The OpenSSL related kmod feature was implemented by Yauheni
Kaliuta. Yauheni also posted a version based on GnuTLS (LGPL):
https://patchwork.kernel.org/patch/10688685/

Having this available as a variant and using it instead would solve this
problem.

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

[John David Anglin]

On 2020-02-29 6:26 a.m., Martin wrote:
> John, could you try this one:
>
> https://salsa.debian.org/debian/libmodbus/-/blob/debian/buster-backports/debian/patches/Wait-for-unit-test-server.patch
>
> It worked for me, but it could be accidental.
It still fails with the same error:

FAIL: ./unit-tests.sh
=

Starting server
Starting client
unit-test-server: no process found
FAIL unit-tests.sh (exit status: 255)

https://buildd.debian.org/status/fetch.php?pkg=libmodbus=hppa=3.1.6-2=1582986840=0

Think the unit-test-server must die before it is looked for.

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

Bug#952806: cbindgen: please package recent version 0.13.1 into experimental

[Carsten Schoenert]

Package: cbindgen
Version: 0.12.1-1
Severity: wishlist

Dear Maintainers of cbindgen,

please consider packaging of cbindgen version >= 0.13 for experiemntal.

I'm trying to work on the current most recent Thunderbird beta version
74.0~b2 and this is requiring cbindgen >= 0.13. So providing cbindgen
within experimental would help me much.

Thanks
Carsten

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

Kernel: Linux 5.4.0-4-amd64 (SMP w/6 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)
LSM: AppArmor: enabled

Bug#952697: free(): double free detected in tcache 2 - packaging problem

[GCS]

Hi Graham,

On Thu, Feb 27, 2020 at 8:27 PM Graham Cobb  wrote:
> I had dar 2.6.6-1 installed on my system. I decided to upgrade to dar 2.6.8 
> so I did:
>
>  apt install dar
 I do wonder, why you didn't upgrade your whole system doing apt upgrade ?
What's the reason of partial upgrades?

> This installed dar 2.6.8-1, gcc-10-base 10-20200222-1 and libgcc-s1 
> 10-20200222-1.
> However, it did NOT upgrade libdar (which I did not notice).
 Indeed, these are not tightened together as dar should work with the
previous libraries with the same soname.

> Subsequent backups failed with dar crashing with error:
>
>  free(): double free detected in tcache 2
>
> backtrace showed libdar::etage::etage had called std::deque which had called 
> free. This was reproducible.
> After a while I realised that libdar had NOT been upgraded. So, I did:
>
>  apt install libdar64-6000
>
> This upgraded libdar64-6000 from 2.6.6-1 to 2.6.8-1 and fixed the problem.
 I see the point, I'm going to tighten these together.

> There has been a discussion about this on the upstream mailing list and the 
> author
> believes there is no reason why libdar 2.6.6 should not work with dar 2.6.8.
> Maybe the problem is that the two debian packages have been built with 
> different
> versions of gcc?
 Can be, I don't have time now to test it to details. Sorry for the
trouble this caused to you.

> In any case, it appears that this dar package needs to have a dependency
> on the same version of libdar.
 While it should work with older libdar64 versions, I do agree. This
is the best to do and I'm going to upload a fix for this.

Thanks,
Laszlo/GCS

Bug#894158: libogg: diff for NMU version 1.3.4-0.1

[Aurelien Jarno]

control: tags 894158 - pending
control: tags 894207 - pending

On 2020-02-05 21:46, Adrian Bunk wrote:
> Control: tags 894158 + patch
> Control: tags 894158 + pending
> Control: tags 894207 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for libogg (versioned as 1.3.4-0.1) and uploaded
> it to DELAYED/15. Please feel free to tell me if I should cancel it.
> 

The package has been rejected:

| libogg source: lintian output: 'license-problem-non-free-RFC 
doc/rfc3533.txt', automatically rejected package.
| libogg source: If you have a good reason, you may override this lintian

Removing the pending tags accordingly.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#952805: Document OpenSSL linking exception

[Bastian Germann]

Package: kopete
Severity: normal

This package has an OpenSSL linking exception in COPYING. This
is not documented in debian/copyright. Please document it there.

Bug#874812: [amora-server] Qt4 removal from Debian

[Axel Beckert]

Hi Moritz,

Moritz Mühlenhoff wrote:
> Sounds good, removing it entirely is fair enough. Are you filing an RM
> bug? Otherwise I can do it as well.

Will do, but want to wait at least a few days to allow upstream to
comment. Otherwise I'd probably already done it.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

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

[Bertrand Marc]

Hi Scott,

> 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

Bug#952804: diaspora-installer: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: diaspora-installer
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of diaspora-installer
debconf messages


Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of diaspora-installer's debconf messages
# Copyright (C) 2015, diaspora-installer copyright holder
# This file is distributed under the same license as the diaspora-installer 
package.
# Beatrice Torracca , 2015, 2017, 2020.
msgid ""
msgstr ""
"Project-Id-Version: diaspora-installer\n"
"Report-Msgid-Bugs-To: diaspora-instal...@packages.debian.org\n"
"POT-Creation-Date: 2017-04-27 12:48+0530\n"
"PO-Revision-Date: 2020-02-29 14:33+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid "Host name for this instance of Diaspora:"
msgstr "Nome host per questa istanza di Diaspora:"

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"Please choose the host name which should be used to access this instance of "
"Diaspora."
msgstr ""
"Scegliere il nome host che deve essere usato per accedere a questa istanza "
"di Diaspora."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This should be the fully qualified name as seen from the Internet, with the "
"domain name that will be used to access the pod."
msgstr ""
"Deve essere il nome pienamente qualificato come visto da Internet, con il "
"nome di dominio che verrà usato per accedere al pod."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"If a reverse proxy is used, give the hostname that the proxy server responds "
"to."
msgstr ""
"Se viene usato un proxy inverso fornire il nome host a cui risponde il "
"server proxy."

#. Type: string
#. Description
#: ../diaspora-common.templates:1001
msgid ""
"This host name should not be modified after the initial setup because it is "
"hard-coded in the database."
msgstr ""
"Questo nome host non deve essere modificato dopo la configurazione iniziale "
"perché è impostato in maniera fissa nel database."

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid "PostgreSQL application password"
msgstr "Password dell'applicazione PostgreSQL"

#. Type: note
#. Description
#: ../diaspora-common.templates:2001
msgid ""
"You can leave the PostgreSQL application password blank, as the \"ident\" "
"authentication method is used, allowing the diaspora user on the system to "
"connect to the Diaspora database without a password."
msgstr ""
"Si può lasciare la password dell'applicazione PostgreSQL vuota, dato che "
"viene usato il metodo di autenticazione «ident», permettendo all'utente "
"«diaspora» nel sistema di connettersi al database di Diaspora senza una "
"password."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid "Enable https?"
msgstr "Abilitare https?"

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Enabling https means that an SSL/TLS certificate is required to access this "
"Diaspora instance (as Nginx will be configured to respond only to https "
"requests). A self-signed certificate is enough for local testing (and can be "
"generated using, for instance, the package easy-rsa), but will not be "
"accepted for federation with other Diaspora pods."
msgstr ""
"Se si abilita l'https è necessario un certificato SSL/TLS per accedere a "
"questa istanza Diaspora (dato che Nginx verrà configurato per rispondere "
"solo a richieste https). È sufficiente un certificato auto-firmato per fare "
"test in locale (e può essere generato usando, ad esempio, il pacchetto easy-"
"rsa), ma non verrà accettato per confederarsi con altri pod Diaspora."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Some certificate authorities like Let's Encrypt (letsencrypt.org), StartSSL "
"(startssl.com) offer free SSL/TLS certificates that work with Diaspora; "
"however, certificates provided by CAcert will not work with Diaspora."
msgstr ""
"Alcune autorità di certificati come Let's Encrypt (letsencrypt.org) o "
"StartSSL (startssl.com) offrono certificati SSL/TLS gratis che funzionano "
"con Diaspora; tuttavia i certificati forniti da CAcert non funzionano con "
"Diaspora."

#. Type: boolean
#. Description
#: ../diaspora-common.templates:3001
msgid ""
"Nginx must be reloaded after the certificate and key files are made "
"available at /etc/diaspora/ssl. letsencrypt package may be used to automate "
"interaction with Let's Encrypt to obtain a certificate."
msgstr ""
"Dopo che il certificato e i file chiave sono resi disponibili in /etc/"
"diaspora/ssl è necessario ricaricare Nginx. Il pacchetto letsencrypt può "
"essere usato per automatizzare 

Bug#952785: buster-pu: package dojo/1.15.0+dfsg1-1+deb10u1

[Salvatore Bonaccorso]

Hi Xavier,

On Sat, Feb 29, 2020 at 09:10:51AM +0100, Xavier Guimard wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> Hi,
> 
> dojo is vulnerable to Cross-site Scripting. This is due to
> dojox.xmpp.util.xmlEncode only encoding the first occurrence of each
> character, not all of them.
> 
> This upstream patch fixes this issue
> 
> Cheers,
> Xavier

> diff --git a/debian/changelog b/debian/changelog
> index 14447b52..0e5dc462 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +dojo (1.15.0+dfsg1-1+deb10u1) buster; urgency=medium
> +
> +  * Team upload
> +  * Cleanup improper regex usage (Closes: #952771, 2019, 10785)
  ^^^
Did you mean CVE-2019-10785 here?

Regards,
Salvatore

Bug#952803: qpsmtpd: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: qpsmtpd
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of qpsmtpd debconf messages

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of qpsmtpd debconf messages.
# Copyright (C) 2012, qpsmtpd package copyright holder
# This file is distributed under the same license as the qpsmtpd package.
# Beatrice Torracca , 2012, 2020.
msgid ""
msgstr ""
"Project-Id-Version: qpsmtpd\n"
"Report-Msgid-Bugs-To: qpsm...@packages.debian.org\n"
"POT-Creation-Date: 2019-01-11 10:02+0100\n"
"PO-Revision-Date: 2020-02-29 14:28+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: boolean
#. Description
#: ../qpsmtpd.templates:1001
msgid "Enable qpsmtpd startup at boot time?"
msgstr "Abilitare l'esecuzione di qpsmtpd all'avvio?"

#. Type: boolean
#. Description
#: ../qpsmtpd.templates:1001
msgid ""
"Because most MTAs in Debian listen on one or all network interfaces by "
"default, when first installed qpsmtpd cannot normally be started."
msgstr ""
"Dato che la maggior parte degli MTA in Debian resta in ascolto in modo "
"predefinito su una o tutte le interfacce di rete, normalmente non è "
"possibile avviare qpsmtpd appena installato."

#. Type: boolean
#. Description
#: ../qpsmtpd.templates:1001
msgid ""
"Before enabling qpsmtpd, you must first configure your local MTA not to bind "
"to the SMTP TCP port on at least one interface.  The most common approach is "
"to leave your MTA listening on the loopback interface (127.0.0.1), with "
"qpsmtpd listening on the external interface.  Instructions for configuring "
"common MTAs to work with qpsmtpd can be found after installation in /usr/"
"share/doc/qpsmtpd/README.Debian."
msgstr ""
"Prima di abilitare qpsmtpd, è necessario configurare il proprio MTA locale "
"in modo che non faccia il bind alla porta TCP SMTP di almeno un'interfaccia. "
"La soluzione più comune è lasciare il proprio MTA in ascolto "
"sull'interfaccia di loopback (127.0.0.1), con qpsmtpd in ascolto "
"sull'interfaccia esterna. Le istruzioni per configurare gli MTA comuni in "
"modo da funzionare insieme a qpsmtpd possono essere trovate, dopo "
"l'installazione, in /usr/share/doc/qpsmtpd/README.Debian."

#. Type: boolean
#. Description
#: ../qpsmtpd.templates:1001
msgid ""
"Once you have adjusted your MTA configuration, you can enable qpsmtpd by "
"restarting this configuration, by running 'dpkg-reconfigure qpsmtpd'."
msgstr ""
"Una volta corretta la configurazione del proprio MTA, si può abilitare "
"qpsmtpd riavviando questa configurazione, eseguendo «dpkg-reconfigure "
"qpsmtpd»."

#. Type: select
#. Description
#: ../qpsmtpd.templates:2001
msgid "Qpsmtpd server type:"
msgstr "Tipo di server qpsmtpd:"

#. Type: select
#. Description
#: ../qpsmtpd.templates:2001
msgid ""
"Qpsmtpd supports two process models for handling connections.  The "
"'forkserver' model uses a single process when idle, and forks new processes "
"to handle connections.  This uses less memory but slightly reduces server "
"throughput.  The 'prefork' model keeps a pool of idle processes available to "
"handle new connections, offering slightly better performance at the cost of "
"more memory."
msgstr ""
"qpsmtpd gestisce due modelli per i processi per gestire le connessioni. Il "
"modello \"forkserver\" usa un unico processo quando inattivo e fa il fork di "
"nuovi processi per gestire le connessioni; usa meno memoria ma riduce "
"leggermente il flusso dati del server. Il modello \"prefork\" mantiene un "
"pool di processi inattivi disponibili per gestire le nuove connessioni, "
"offrendo prestazioni leggermente migliori a spese di un maggior uso di "
"memoria."

#. Type: string
#. Description
#: ../qpsmtpd.templates:3001
msgid "Addresses on which to listen for incoming SMTP connections:"
msgstr "Indirizzi su cui rimanere in ascolto per connessioni SMTP in entrata:"

#. Type: string
#. Description
#: ../qpsmtpd.templates:3001
msgid ""
"Enter one or more of your local IP addresses, separated by spaces, on which "
"qpsmtpd should listen for incoming SMTP connections.  If you leave this "
"setting empty, qpsmtpd will listen on all interfaces available at startup "
"time."
msgstr ""
"Inserire uno o più indirizzi IP locali, separati da spazi, su cui qpsmtpd "
"deve rimanere in ascolto per connessioni SMTP in entrata. Se si lascia "
"vuoto, qpsmtpd resterà in ascolto su tutte le interfacce disponibili "
"all'avvio."

#. Type: string
#. Description
#: ../qpsmtpd.templates:3001
msgid ""
"If you intend to use qpsmtpd to spool deliveries from remote hosts into a "
"local MTA, you may wish to have qpsmtpd listen on all external interfaces, "
"while leaving your local MTA listening on the loopback device (127.0.0.1)."
msgstr ""
"Se si pensa di usare 

Bug#952802: miniupnpd: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: miniupnpd
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of miniupnpd debconf messages


Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of miniupnpd debconf messages
# Copyright (C) 2013, miniupnpd package copyright holder
# This file is distributed under the same license as the miniupnpd package.
# Beatrice Torracca , 2013, 2020.
msgid ""
msgstr ""
"Project-Id-Version: miniupnpd\n"
"Report-Msgid-Bugs-To: miniup...@packages.debian.org\n"
"POT-Creation-Date: 2019-01-06 21:56+0800\n"
"PO-Revision-Date: 2020-02-29 14:23+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:2001
msgid "Start the MiniUPnP daemon automatically?"
msgstr "Avviare il demone MiniUPnP automaticamente?"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:2001
msgid ""
"Choose this option if the MiniUPnP daemon should start automatically, now "
"and at boot time."
msgstr ""
"Scegliere questa opzione se il demone MiniUPnP deve essere avviato "
"automaticamente, adesso e all'avvio."

#. Type: string
#. Description
#: ../miniupnpd.templates:3001
msgid "Interfaces to listen on for UPnP queries:"
msgstr "Interfacce sulle quali restare in ascolto per richieste UPnP:"

#. Type: string
#. Description
#: ../miniupnpd.templates:3001
msgid ""
"The MiniUPnP daemon will listen for requests on the local network. Please "
"enter the interfaces or IP addresses it should listen on, separated by space."
msgstr ""
"Il demone MiniUPnP resterà in ascolto per le richieste sulla rete locale. "
"Inserire, separati da spazi, le interfacce o gli indirizzi IP su cui deve "
"restare in ascolto."

#. Type: string
#. Description
#: ../miniupnpd.templates:3001
msgid ""
"Interface names are preferred, and required if you plan to enable IPv6 port "
"forwarding."
msgstr ""
"I nomi di interfacce sono preferiti e sono richiesti se si ha intenzione di "
"abilitare il forwarding delle porte IPv6."

#. Type: string
#. Description
#: ../miniupnpd.templates:4001
msgid "External WAN network interface to open ports on:"
msgstr "Interfaccia di rete WAN esterna su cui aprire le porte:"

#  N.d.T. indecisa se tradurre con parafrasi inoltro verso le porte
#. Type: string
#. Description
#: ../miniupnpd.templates:4001
msgid ""
"The MiniUPnP daemon will listen on a specific IP address on the local "
"network, then open ports on the WAN interface. Please enter the name of the "
"WAN network interface on which the MiniUPnP daemon should perform port "
"forwarding."
msgstr ""
"Il demone MiniUPnP resterà in ascolto su un indirizzo IP specifico sulla "
"rete locale, poi aprirà porte sull'interfaccia WAN. Inserire il nome "
"dell'interfaccia di rete WAN verso la quale il demone MiniUPnP deve fare il "
"ridirezionamento delle porte."

#. Type: boolean
#. Description
#: ../miniupnpd.templates:5001
msgid "Enable IPv6 firewall chain?"
msgstr "Abilitare una catena IPv6 nel firewall?"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:5001
msgid ""
"Please specify whether the MiniUPnP daemon should run its ip6tables script "
"on startup to initialize the IPv6 firewall chain."
msgstr ""
"Specificare se il demone MiniUPnP debba eseguire il suo script ip6tables "
"all'avvio per inizializzare la catena IPv6 nel firewall."

#. Type: boolean
#. Description
#: ../miniupnpd.templates:5001
msgid ""
"Note: This option is useless if you don't block any IPv6 forwarded traffic."
msgstr ""
"Nota bene: questa opzione è inutile se non si blocca alcun traffico IPv6 con "
"forwarding."

#. Type: boolean
#. Description
#: ../miniupnpd.templates:6001
msgid "Force reporting IGDv1 in rootDesc?"
msgstr "Forzare la segnalazione come IGDv1 in rootDesc?"

#. Type: boolean
#. Description
#: ../miniupnpd.templates:6001
msgid ""
"Some IGD clients (most notably Microsoft® Windows® BITS) look for IGDv1 and "
"do not recognize IGDv2 as a valid IGD service. This option will fool them by "
"pretending itself to be IGDv1."
msgstr ""
"Alcuni client IGD (in particolare Microsoft® Windows® BITS) cercano IGDv1 e "
"non riconoscono IGDv2 come servizio IGD valido. Questa opzione li ingannerà "
"facendo finta di essere IGDv1."

#. Type: boolean
#. Description
#: ../miniupnpd.templates:6001
msgid ""
"Of course you will lose IGDv2 functions (notably IPv6 support) by enabling "
"this."
msgstr ""
"Abilitando ciò, naturalmente verranno perse le funzioni IGDv2 (e, in modo "
"degno di nota, il supporto per IPv6)."

Bug#952799: openafs: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: openafs
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of openafs debconf messages


Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of openafs debconf messages
# Copyright (C) 2012 openafs package copyright holder
# This file is distributed under the same license as the openafs package.
# Beatrice Torracca , 2012, 2013, 2020.
msgid ""
msgstr ""
"Project-Id-Version: openafs\n"
"Report-Msgid-Bugs-To: open...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-10 15:27-0500\n"
"PO-Revision-Date: 2020-02-29 14:16+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: string
#. Description
#: ../openafs-client.templates:1001
msgid "DB server host names for your home cell:"
msgstr "Nomi host dei server DB per la propria cella:"

#. Type: string
#. Description
#: ../openafs-client.templates:1001
msgid ""
"AFS uses the file /etc/openafs/CellServDB to hold the list of servers that "
"should be contacted to find parts of a cell.  The cell you claim this "
"workstation belongs to is not in that file.  Enter the host names of the "
"database servers separated by spaces. IMPORTANT: If you are creating a new "
"cell and this machine is to be a database server in that cell, only enter "
"this machine's name; add the other servers later after they are functioning. "
"Also, do not enable the AFS client to start at boot on this server until the "
"cell is configured.  When you are ready you can edit /etc/openafs/afs.conf."
"client to enable the client."
msgstr ""
"AFS usa il file /etc/openafs/CellServDB per memorizzare l'elenco dei server "
"che devono essere contattati per trovare le parti di una cella. Si è "
"indicato che questa macchina appartiene ad una cella che però non è in tale "
"file. Inserire i nomi host dei server di database separati da spazi. "
"IMPORTANTE: se si sta creando una nuova cella e questa macchina deve essere "
"un server di database per tale cella, inserire solamente il nome di questa "
"macchina; aggiungere gli altri server successivamente quando saranno in "
"funzione. Inoltre non abilitare l'esecuzione del client AFS all'avvio su "
"questo server fino a che la cella non è configurata. Quando si è pronti, si "
"può modificare /etc/openafs/afs.conf.client per abilitare il client."

#. Type: string
#. Description
#: ../openafs-client.templates:2001
msgid "AFS cell this workstation belongs to:"
msgstr "Cella AFS a cui appartiene questa macchina:"

#. Type: string
#. Description
#: ../openafs-client.templates:2001
msgid ""
"AFS filespace is organized into cells or administrative domains. Each "
"workstation belongs to one cell.  Usually the cell is the DNS domain name of "
"the site."
msgstr ""
"Lo spazio dei file AFS è organizzato in celle o domini amministrativi. Ogni "
"macchina appartiene ad una cella. Solitamente la cella è il nome di dominio "
"DNS del sito."

#. Type: string
#. Description
#: ../openafs-client.templates:3001
msgid "Size of AFS cache in kB:"
msgstr "Dimensione della cache AFS in kB:"

#. Type: string
#. Description
#: ../openafs-client.templates:3001
msgid ""
"AFS uses an area of the disk to cache remote files for faster access.  This "
"cache will be mounted on /var/cache/openafs.  It is important that the cache "
"not overfill the partition it is located on.  Often, people find it useful "
"to dedicate a partition to their AFS cache."
msgstr ""
"AFS usa un'area del disco per mantenere una cache dei file remoti per un "
"accesso più veloce. Questa cache viene montata in /var/cache/openafs. È "
"importante che la cache non riempia troppo la partizione in cui è contenuta. "
"Spesso viene considerato utile dedicare una partizione alla cache AFS."

#. Type: boolean
#. Description
#: ../openafs-client.templates:4001
msgid "Run Openafs client now and at boot?"
msgstr "Eseguire il client Openafs ora e all'avvio?"

#. Type: boolean
#. Description
#: ../openafs-client.templates:4001
msgid ""
"Normally, most users who install the openafs-client package expect AFS to be "
"mounted automatically at boot.  However, if you are planning on setting up a "
"new cell or are on a laptop, you may not want it started at boot time.  If "
"you choose not to start AFS at boot, run service openafs-client force-start "
"to start the client when you wish to run it."
msgstr ""
"Normalmente, la maggior parte degli utenti che installa il pacchetto openafs-"
"client si aspetta che AFS venga automaticamente montato all'avvio. Tuttavia, "
"se si ha intenzione di impostare una nuova cella o se si usa un portatile, "
"si potrebbe non volerlo eseguire all'avvio. Se si sceglie di non eseguire "
"AFS all'avvio, eseguire \"service openafs-client force-start\" per avviare "
"il client al momento desiderato."

#. 

Bug#952798: horizon: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: horizon
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of horizon debconf messages


Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of horizon's debconf messages.
# Copyright (C) 2016, horizon package copyright holder
# This file is distributed under the same license as the horizon package.
# Beatrice Torracca , 2013, 2016, 2020.
msgid ""
msgstr ""
"Project-Id-Version: horizon\n"
"Report-Msgid-Bugs-To: hori...@packages.debian.org\n"
"POT-Creation-Date: 2018-08-30 11:59+0200\n"
"PO-Revision-Date: 2020-02-29 14:12+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid "Activate Dashboard and disable default VirtualHost?"
msgstr "Attivare Dashboard e disabilitare il VirtualHost predefinito?"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"The Apache package sets up a default web site and a default page, configured "
"in /etc/apache2/sites-available/000-default.conf."
msgstr ""
"Il pacchetto Apache imposta un sito web e una pagina predefiniti, "
"configurati in /etc/apache2/sites-available/000-default.conf."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"If this option is not selected, Horizon will be installed using /horizon "
"instead of the webroot."
msgstr ""
"Se questa opzione non viene selezionata Horizon verrà installato usando /"
"horizon invece di webroot."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:2001
msgid ""
"Choose this option to replace that default with the OpenStack Dashboard "
"configuration."
msgstr ""
"Scegliere questa opzione per sostituire il valore predefinito con la "
"configurazione di Dashboard di OpenStack."

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:3001
msgid "Should the Dashboard use HTTPS?"
msgstr "Dashboard deve usare HTTPS?"

#. Type: boolean
#. Description
#: ../openstack-dashboard-apache.templates:3001
msgid ""
"Select this option if you would like Horizon to be served over HTTPS only, "
"with a redirection to HTTPS if HTTP is in use."
msgstr ""
"Scegliere questa opzione se si desidera che Horizon venga servito solamente "
"su HTTPS, con una ridirezione verso HTTPS se viene usato HTTP."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid "Allowed hostname(s):"
msgstr "Nomi host permessi:"

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Please enter the list of hostnames that can be used to reach your OpenStack "
"Dashboard server. This is a security measure to prevent HTTP Host header "
"attacks, which are possible even under many seemingly-safe web server "
"configurations."
msgstr ""
"Inserire l'elenco dei nomi host che possono essere usati per contattare il "
"proprio server OpenStack Dashboard. Questa è una misura di sicurezza per "
"prevenire attacchi con header HTTP Host, che sono possibili anche sotto "
"molte configurazioni di server web apparentemente sicure."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Enter values separated by commas. Any space will be removed, so you can add "
"some to make it more readable."
msgstr ""
"Inserire i valori separati da virgole. Ogni spazio verrà rimosso, perciò "
"possono essere utilizzati per renderlo più leggibile."

#. Type: string
#. Description
#: ../openstack-dashboard.templates:2001
msgid ""
"Values in this list can be fully qualified names like \"www.example.com\", "
"in which case they will be matched against the request's Host header exactly "
"(case-insensitive, not including port). A value beginning with a period can "
"be used as a subdomain wildcard: \".example.com\" will match example.com, "
"www.example.com, and any other subdomain of example.com. A value of \"*\" "
"will match anything; in this case you are responsible for providing your own "
"validation of the Host header (perhaps in middleware; if so this middleware "
"must be listed first in MIDDLEWARE)."
msgstr ""
"I valori in questo elenco possono essere nomi pienamente qualificati, come "
"\"www.example.com\", nel qual caso faranno corrispondenza esatta con "
"l'header Host della richiesta (non sensibile a maiuscole/minuscole, porta "
"non inclusa). Un valore che inizia con un punto può essere usato come "
"carattere jolly: \".example.com\" farà corrispondenza con example.com, www."
"example.com e ogni altro sottodominio di example.com. Un valore \"*\" farà "
"corrispondenza con tutto; in questo caso è responsabilità propria fornire "
"una propria validazione dell'header Host (eventualmente in middleware; se "
"così il middleware 

Bug#952800: ITP: ruby-rubocop-performance -- Automatic performance checking tool for Ruby code

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

https://rubygems.org/gems/rubocop-performance for rubocop update to 0.69

Bug#952801: libeigen3-dev headers have deprecated-copy warnings on GCC 9

[Mike Purvis]

Package: libeigen3-dev
Version: 3.3.7-1
X-Debbugs-CC: gin...@debian.org

I'm seeing this problem when attempting to build my company's ROS-based
robotics software on the not-yet-released Ubuntu Focal.

Upstream had patched this issue on their master branch (targeting Eigen
3.4), and was gracious enough to cherry-pick the changes over to their 3.3
support branch, see:

https://gitlab.com/libeigen/eigen/-/merge_requests/29
https://gitlab.com/libeigen/eigen/-/commits/3.3

Thanks very much to Christoph Hertzberg for the quick turnaround on that.

I have in turn imported these patches as-is to the current 3.3.7-1 package
and released it to PPA here:

https://launchpad.net/~mikepurvis/+archive/ubuntu/eigen/

I have installed that version into my environment and confirmed that it
corrects the issues with my build. I proposed that the Ubuntu maintainer
take the patches, but they suggested sending them upstream to Debian:

https://bugs.launchpad.net/ubuntu/+source/eigen3/+bug/1865225

Am hopeful that this can be fixed ahead of the Focal release so that we
don't have to silence that new warning in all of the build configs where we
use -Werror!

I am using Ubuntu Focal 20.04 in a chroot with kernel 4.15.0-72-generic,
and libc 5.4.0-14.17.

Bug#952796: go-mtpfs: rmdir issues rm -fr

[Matteo Cypriani]

Package: go-mtpfs
Version: 0.0~git20180209.d6f8f3c-1+b1
Severity: important

Dear Maintainer,

Issuing "rmdir" on a directories of the mounted filesystem is the
equivalent of recursively removing the directory (i.e. "rm -rf"), which
is obviously not the expected behaviour. This just led me to lose a lot
of data on the internal partition of my phone.

Steps to reproduce:

go-mtpfs ~/myphone
cd ~/myphone
mkdir -p foo/bar
rmdir foo

Outcome: foo is removed.

Expected outcome: rmdir complaining that foo is not empty and not
removing it.

Cheers,
  Matteo

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

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

Versions of packages go-mtpfs depends on:
ii  libc6 2.29-10
ii  libusb-1.0-0  2:1.0.23-2

go-mtpfs recommends no packages.

go-mtpfs suggests no packages.

-- no debconf information

Bug#952797: gpgme1.0 FTCBFS: python3.8 changed interface again

[Helmut Grohne]

Source: gpgme1.0
Version: 1.13.1-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gpgme1.0 fails to cross build from source, because with python3.8 the
interface was changed again. I do see that this is frustrating as it has
already resulted in a native ftbfs on gpgme1.0. However, I'm not the
Python maintainer and even Matthias' attempts at filing this issue
upstream was unsuccessful thus far. As far as I understand the current
situation, the "m" is dropped for good and not about to come back
anytime soon. So hope is that this is a one-time migration. Could you
just adapt it with your next maintainer upload? gpgme1.0 only uses the
most recent Python version, so we don't have to port <=3.7 here.

Helmut
diff --minimal -Nru gpgme1.0-1.13.1/debian/changelog 
gpgme1.0-1.13.1/debian/changelog
--- gpgme1.0-1.13.1/debian/changelog2020-01-30 17:37:08.0 +0100
+++ gpgme1.0-1.13.1/debian/changelog2020-02-29 12:50:58.0 +0100
@@ -1,3 +1,10 @@
+gpgme1.0 (1.13.1-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Adapt cross building for python3.8. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 29 Feb 2020 12:50:58 +0100
+
 gpgme1.0 (1.13.1-6) unstable; urgency=medium
 
   * brown paper bag bugfix to debian/tests :(
diff --minimal -Nru gpgme1.0-1.13.1/debian/rules gpgme1.0-1.13.1/debian/rules
--- gpgme1.0-1.13.1/debian/rules2020-01-29 19:15:07.0 +0100
+++ gpgme1.0-1.13.1/debian/rules2020-02-29 12:50:55.0 +0100
@@ -8,9 +8,7 @@
 # python3.X, see pybuild for their meaning.
 export _PYTHON_HOST_PLATFORM:=${DEB_HOST_ARCH_OS}-${DEB_HOST_ARCH}
 ifneq ($(DEB_BUILD_ARCH),$(DEB_HOST_ARCH))
-# this is likely to break for python3.8, which uses sysconfigdata__
-# instead of sysconfigdata_m_:
-   export 
_PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata_m_${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}
+   export 
_PYTHON_SYSCONFIGDATA_NAME:=_sysconfigdata__${DEB_HOST_ARCH_OS}_${DEB_HOST_MULTIARCH}
 endif
 
 %:

Bug#940124: closed by Debian FTP Masters (reply to Luigi Gangitano ) (Bug#940124: fixed in sarg 2.4.0-1)

[Helmut Grohne]

Control: reopen -1
Control: found -1 2.4.0-1

On Mon, Feb 24, 2020 at 12:51:05AM +, Debian Bug Tracking System wrote:
>* debian/patches/0003-Fix-FTCBFS.patch
>  - Fix FTCBFS, thanks to Helmut Grohne (Closes: #940124)

Thank you for applying the patch. Unfortunately, the package build does
not build configure from source and you did not rebuild it at upload
time. Therefore, sarg uses an old configure that still has the bug.

Helmut

Bug#952795: keystone: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: keystone
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of keystone debconf messages


Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of keystone debconf messages.
# Copyright (C) 2012, Beatrice Torracca 
# This file is distributed under the same license as the keystone package.
# Beatrice Torracca , 2012, 2013, 2020.
msgid ""
msgstr ""
"Project-Id-Version: keystone\n"
"Report-Msgid-Bugs-To: keyst...@packages.debian.org\n"
"POT-Creation-Date: 2018-03-22 14:59+\n"
"PO-Revision-Date: 2020-02-29 13:53+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: boolean
#. Description
#: ../keystone.templates:2001
msgid "Set up a database for Keystone?"
msgstr "Impostare un database per Keystone?"

#. Type: boolean
#. Description
#: ../keystone.templates:2001
msgid ""
"No database has been set up for Keystone to use. Before continuing, you "
"should make sure you have the following information:"
msgstr ""
"Non è stato impostato alcun database per l'uso da parte di Keystone. Prima "
"di continuare assicurarsi di avere le seguenti informazioni:"

#. Type: boolean
#. Description
#: ../keystone.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server host name (that server must allow TCP connections "
"from this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * il tipo di database che si desidera usare;\n"
" * il nome host del server di database (che deve permettere le\n"
"   connessioni TCP da questa macchina);\n"
" * un nome utente e una password per accedere al database."

#. Type: boolean
#. Description
#: ../keystone.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se non si ha uno o più di questi requisiti, non scegliere questa opzione ed "
"eseguire con il regolare supporto per SQLite."

#. Type: boolean
#. Description
#: ../keystone.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"keystone\"."
msgstr ""
"È possibile cambiare questa impostazione successivamente eseguendo \"dpkg-"
"reconfigure -plow keystone\"."

#. Type: boolean
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it parenthezised. Example for French:
#. locataire ("tenant")
#: ../keystone.templates:3001
msgid "Register administration tenants?"
msgstr "Registrare i locatari (\"tenant\") di amministrazione?"

#. Type: boolean
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it parenthezised. Example for French:
#. locataire ("tenant")
#: ../keystone.templates:3001
msgid ""
"For OpenStack to work, you need a basic tenant configuration. The creation "
"of these administration tenants can be done automatically."
msgstr ""
"Affinché OpenStack funzioni, è necessaria una configurazione di base dei "
"locatari (\"tenant\"); la creazione di questi tenant di amministrazione può "
"essere fatta automaticamente."

#. Type: string
#. Description
#: ../keystone.templates:4001
msgid "Username of the administrative user:"
msgstr "Nome utente per l'utente di amministrazione:"

#. Type: string
#. Description
#: ../keystone.templates:4001
msgid "Please enter a username for the administrative user."
msgstr "Inserire un nome utente per l'utente amministrazione."

#. Type: string
#. Description
#: ../keystone.templates:5001
msgid "Email address of the administrative user:"
msgstr "Indirizzo di posta elettronica dell'utente di amministrazione:"

#. Type: string
#. Description
#: ../keystone.templates:5001
msgid "Please enter the email address of the administrative user."
msgstr ""
"Inserire l'indirizzo di posta elettronica dell'utente di amministrazione."

#. Type: password
#. Description
#: ../keystone.templates:6001
msgid "Password of the administrative user:"
msgstr "Password dell'utente di amministrazione:"

#. Type: password
#. Description
#: ../keystone.templates:6001
msgid "Please enter a password for the administrative user."
msgstr "Inserire la password per l'utente di amministrazione."

#. Type: password
#. Description
#: 

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Jean-Luc Coulon (f5ibh)]

Le 28/02/2020 à 20:50, Timo Aaltonen a écrit :
> 
> I'm pretty sure the reason for the failure is that our xkbcomp is too
> old, the newer versions ignore errors caused by having keycodes above
> 255.. and launching Xwayland in weston clearly shows a bunch of errors
> from xkbcomp. Our version (1.4.0) is almost 2y old and this was fixed
> upstream in 1.4.1 in June 2018.
> 
> So I'll update x11-xkb-utils, thanks for the patience..
>
I've updated x11-xkb-utils and xkb-data (to 2.29-2) together with other
related packages with the update of debien sid today.

This fixes the problem [for me].

Thanks and regards

Jean-Luc

Bug#952794: clamsmtp: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: clamsmtp
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of clamsmtp debconf messages.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of clamsmtp debconf messages.
# Copyright (C) 2012, Beatrice Torracca
# This file is distributed under the same license as the clamsmtp package.
# Beatrice Torracca , 2012, 2020.
msgid ""
msgstr ""
"Project-Id-Version: clamsmtp\n"
"Report-Msgid-Bugs-To: clams...@packages.debian.org\n"
"POT-Creation-Date: 2018-02-19 18:35+0100\n"
"PO-Revision-Date: 2020-02-29 13:46+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

#. Type: boolean
#. Description
#: ../templates:1001
msgid "Add a clamsmtp system user and group?"
msgstr "Aggiungere un utente e un gruppo di sistema per clamsmtp?"

#. Type: boolean
#. Description
#: ../templates:1001
msgid ""
"New installations of clamsmtp install with a system user and group of "
"\"clamsmtp\".  The \"clamav\" user is added to the clamsmtp group to allow "
"the clamav-daemon process to view the quarantine directory.  If this option "
"is set, the installation process will also update the ownership and "
"permissions of the quarantine and run directories."
msgstr ""
"Le nuove installazioni di clamsmtp vengono create con un utente e un gruppo "
"di sistema chiamati «clamsmtp». L'utente «clamav» viene aggiunto al gruppo "
"clamsmtp per permettere al processo clamav-daemon di visualizzare la "
"directory di quarantena. Se questa opzione viene impostata, il processo di "
"installazione aggiornerà anche la proprietà e i permessi delle directory di "
"quarantena e di esecuzione."

#. Type: boolean
#. Description
#: ../templates:2001
msgid "Fix directory permissions?"
msgstr "Correggere i permessi delle directory?"

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"clamsmtpd needs read and write permissions to the virus spool directory, and "
"the run directory in which its PID file is created.  Additionally, the Clam "
"AV daemon must have read access to the spool directory to scan for viruses."
msgstr ""
"clamsmtpd deve avere i permessi di lettura e scrittura per la directory "
"dello spool dei virus e per la directory di esecuzione in cui viene creato "
"il suo file PID. In aggiunta, il demone Clam AV deve avere accesso in "
"lettura alla directory di spool per la ricerca anti-virus."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"The post-installation script can fix the permissions and ownership of these "
"two directories.  It will consult the /etc/clamsmtpd.conf file for the "
"administratively assigned TempDirectory, PidFile, User, and Group variables, "
"and then update the two directories appropriately."
msgstr ""
"Lo script di post-installazione può correggere i permessi e la proprietà di "
"queste due directory. Consulterà il file /etc/clamsmtpd.conf per le "
"variabili TempDirectory, PidFile, User e Group assegnate dall'amministratore "
"e poi aggiornerà le due directory in modo appropriato."

#. Type: boolean
#. Description
#: ../templates:2001
msgid ""
"Be sure to check directory permissions after running the init script with "
"the parameters 'start' or 'restart'."
msgstr ""
"Assicurarsi di controllare i permessi delle directory dopo aver eseguito lo "
"script init con i parametri «start» o «restart»."

#. Type: boolean
#. Description
#: ../templates:3001
msgid "Purge spool directory on --purge?"
msgstr "Svuotare la directory di spool quando viene usato --purge?"

#. Type: boolean
#. Description
#: ../templates:3001
msgid ""
"The virus spool directory may contain quarantined viruses that can be "
"removed automatically when purging the package."
msgstr ""
"La directory di spool dei virus può contenere virus in quarantena che "
"possono essere rimossi automaticamente quando viene eliminato completamente "
"il pacchetto."

Bug#952793: ejabberd: [INTL:it] Italian translation of debconf messages

[Beatrice Torracca]

Package: ejabberd
Severity: wishlist
Tags: patch l10n

Hi.

Please find attached the Italian translation of ejabberd debconf messages.

Please include it in your next upload.

Thanks,
Beatrice
# Italian translation of ejabberd debconf messages.
# Copyright (C) 2012, ejabberd package copyright holder.
# This file is distributed under the same license as the ejabberd package.
# Beatrice Torracca , 2012, 2015, 2017, 2020.
msgid ""
msgstr ""
"Project-Id-Version: ejabberd\n"
"Report-Msgid-Bugs-To: ejabb...@packages.debian.org\n"
"POT-Creation-Date: 2017-11-21 23:34-0500\n"
"PO-Revision-Date: 2020-02-29 13:36+0100\n"
"Last-Translator: Beatrice Torracca \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 2.2.4\n"

# Note to translators:
# Please do not translate the variables ${hostname}, ${user}, ${preseed}, and
# any other which may appear in the future. Changes to these variables will
# break the scripts. Thank you!
#. Type: string
#. Description
#: ../templates:2001
msgid "Hostname for this Jabber server:"
msgstr "Nome host per questo server Jabber:"

#. Type: string
#. Description
#: ../templates:2001
msgid "Please enter a hostname for this Jabber server."
msgstr "Inserire il nome host di questo server Jabber."

#. Type: string
#. Description
#: ../templates:2001
msgid ""
"If you would like to configure multiple hostnames for this server, you will "
"have to do so manually in /etc/ejabberd/ejabberd.yml after installation."
msgstr ""
"Se si desidera configurare più nomi host per questo server, è necessario "
"farlo manualmente in /etc/ejabberd/ejabberd.yml dopo l'installazione."

#. Type: string
#. Description
#: ../templates:3001
msgid "Jabber server administrator username:"
msgstr "Nome utente dell'amministratore del server Jabber:"

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Please provide the name of an account to administrate the ejabberd server. "
"After the installation of ejabberd, you can log in to this account using "
"either any Jabber client or a web browser pointed at the administrative "
"https://${hostname}:5280/admin/ interface."
msgstr ""
"Inserire il nome di un account per amministrare il server ejabberd. Dopo "
"l'installazione di ejabberd sarà possibile fare il login in questo account "
"usando un qualsiasi client Jabber o un browser web puntato all'interfaccia "
"di amministrazione https://${hostname}:5280/admin/ ."

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"You only need to enter the username part here (such as ${user}), but the "
"full Jabber ID (such as ${user}@${hostname}) is required to access the "
"ejabberd web interface."
msgstr ""
"È necessario inserire solo la parte del nome utente (ad esempio ${user}), ma "
"è richiesto l'ID Jabber completo (ad esempio ${user}@${hostname}) per "
"accedere all'interfaccia web di ejabberd."

#. Type: string
#. Description
#: ../templates:3001
msgid ""
"Please leave this field empty if you don't want to create an administrator "
"account automatically."
msgstr ""
"Lasciare vuoto se non si desidera creare automaticamente un account di "
"amministrazione."

#. Type: password
#. Description
#: ../templates:4001
msgid "Jabber server administrator password:"
msgstr "Password dell'amministratore del server Jabber:"

#. Type: password
#. Description
#: ../templates:4001
msgid "Please enter the password for the administrative user."
msgstr "Inserire la password dell'utente amministratore."

#. Type: password
#. Description
#: ../templates:5001
msgid "Re-enter password to verify:"
msgstr "Inserire nuovamente la password per verifica:"

#. Type: password
#. Description
#: ../templates:5001
msgid ""
"Please enter the same administrator password again to verify that you have "
"typed it correctly."
msgstr ""
"Inserire nuovamente la stessa password dell'amministratore per verificare di "
"averla digitata correttamente."

#. Type: error
#. Description
#: ../templates:6001
msgid "Password input error"
msgstr "Errore nell'inserimento della password"

#. Type: error
#. Description
#: ../templates:6001
msgid ""
"The two passwords you entered did not match or were empty. Please try again."
msgstr "Le due password inserite non erano identiche o erano vuote. Riprovare."

#. Type: error
#. Description
#: ../templates:7001
msgid "Invalid administrator account username"
msgstr "Nome utente per l'account amministratore non valido"

#. Type: error
#. Description
#: ../templates:7001
msgid ""
"The username previously specified contains forbidden characters. Please "
"respect the JID syntax (https://tools.ietf.org/html/rfc6122#appendix-A.5). "
"If you used a full JID (e.g. user@hostname), the hostname needs to match the "
"one previously specified."
msgstr ""
"Il nome utente precedentemente specificato contiene caratteri non permessi. "
"Rispettare la sintassi JID 

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

[sergio]

https://phab.enlightenment.org/T8621

-- 
sergio.

Bug#952792: RM: chef/13.8.7-6

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-CC: stefa...@debian.org, debian-r...@lists.debian.org

Please remove chef from testing. It's marked for autoremoval due to a RC
bug; fixing the RC bug will take a while (needs a new upstream release
which needs a few new dependencies to be packaged), it's blocking other
stuff from migrating to testing.

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

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


signature.asc
Description: PGP signature

Bug#952791: crack FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: crack
Version: 5.0a-12
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

crack fails to cross build from source, because it hard codes the build
architecture compiler. Please consider applying the attached patch to
pick up a cross compiler and make crack cross buildable.

Helmut
diff --minimal -Nru crack-5.0a/debian/Crack.make crack-5.0a/debian/Crack.make
--- crack-5.0a/debian/Crack.make2018-06-05 04:19:49.0 +0200
+++ crack-5.0a/debian/Crack.make2020-02-29 07:48:07.0 +0100
@@ -54,7 +54,7 @@
 #LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD 
MD5
 
 # gcc 2.7.2
-CC=gcc
+: "${CC:=gcc}"
 CFLAGS="-g -O2 -Wall $C5FLAGS"
 LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD 
MD5
 
diff --minimal -Nru crack-5.0a/debian/changelog crack-5.0a/debian/changelog
--- crack-5.0a/debian/changelog 2018-06-05 21:28:16.0 +0200
+++ crack-5.0a/debian/changelog 2020-02-29 07:48:37.0 +0100
@@ -1,3 +1,10 @@
+crack (5.0a-12.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dpkg's buildtools.mk seed CC. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 29 Feb 2020 07:48:37 +0100
+
 crack (5.0a-12) unstable; urgency=medium
 
   [ Raphaël Hertzog ]
diff --minimal -Nru crack-5.0a/debian/rules crack-5.0a/debian/rules
--- crack-5.0a/debian/rules 2018-06-05 04:19:49.0 +0200
+++ crack-5.0a/debian/rules 2020-02-29 07:48:36.0 +0100
@@ -2,6 +2,8 @@
 #export DH_VERBOSE=1
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+DPKG_EXPORT_BUILDTOOLS=1
+include /usr/share/dpkg/buildtools.mk
 
 %:
dh $@

Bug#952790: ITP: ruby-test-prof -- Ruby applications tests profiling tools

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 

https://rubygems.org/gems/test-prof for gitlab autopkgtest

Bug#952789: Please update tracker to 2.3.2

[Amr Ibrahim]

Package: tracker

2.3.2 is a small bug-fix release.

https://gitlab.gnome.org/GNOME/tracker/-/blob/tracker-2.3/NEWS

NEW in 2.3.2 - 2020-02-18
=

  * Location info for photos is now inserted into the DB. It didn't work before 
as we failed to process SPARQL "blank nodes" correctly.
  * Fix for oversensitive FTS5 index corruption detection

Translations: ms