Bug#986663: unblock: kdenlive/20.12.3-1

[Patrick Matthäi]

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

Please unblock package kdenlive

This is a KDE applications bugfix release. The changelog is here:
https://kdenlive.org/de/2021/03/kdenlive-20-12-3-ist-da/

There are many fixes, so I considered to upload the whole release, also if the
diff is a little bit bigger (if you exclude the .ui and .qml files it is much
smaller). There were also user requests asking me to include this release
in bullseye.

The filtered diffstat:

$ diff -Naur kdenlive-20.12.2 kdenlive-20.12.3 --exclude="*.po" 
--exclude="*.docbook" --exclude=.pc|diffstat
 CMakeLists.txt |2
 data/effects/CMakeLists.txt|1
 data/effects/typewriter.xml|   19 ++
 data/org.kde.kdenlive.appdata.xml  |2
 debian/changelog   |6
 debian/files   |1
 src/assets/keyframes/view/keyframeview.cpp |   14 +-
 src/assets/view/widgets/keyframewidget.cpp |   13 +
 src/bin/model/markerlistmodel.cpp  |2
 src/bin/model/subtitlemodel.cpp|   35 -
 src/bin/model/subtitlemodel.hpp|9 +
 src/core.cpp   |2
 src/dialogs/profilesdialog.cpp |   12 -
 src/dialogs/subtitleedit.cpp   |   52 ++-
 src/dialogs/titletemplatedialog.cpp|8 -
 src/doc/documentchecker.cpp|1
 src/doc/kdenlivedoc.cpp|4
 src/effects/effectstack/view/collapsibleeffectview.cpp |   11 -
 src/jobs/audiothumbjob.cpp |4
 src/jobs/loadjob.cpp   |4
 src/jobs/transcodeclipjob.cpp  |   11 -
 src/lib/audio/audioStreamInfo.cpp  |2
 src/main.cpp   |2
 src/mainwindow.cpp |7 -
 src/mltconnection.cpp  |5
 src/monitor/monitor.cpp|3
 src/monitor/view/SceneToolBar.qml  |1
 src/monitor/view/kdenliveclipmonitor.qml   |2
 src/profiles/profilemodel.cpp  |   12 -
 src/timecodedisplay.cpp|2
 src/timeline2/model/groupsmodel.cpp|2
 src/timeline2/model/timelinemodel.cpp  |   26 +++
 src/timeline2/model/timelinemodel.hpp  |6
 src/timeline2/view/qml/SubTitle.qml|   54 +++
 src/timeline2/view/qml/Timeline.js |2
 src/timeline2/view/qml/timeline.qml|   86 +---
 src/timeline2/view/qml/timelineitems.cpp   |3
 src/timeline2/view/timelinecontroller.cpp  |   21 ++-
 src/timeline2/view/timelinewidget.cpp  |8 +
 src/timeline2/view/timelinewidget.h|1
 src/titler/graphicsscenerectmove.cpp   |   20 ++
 src/titler/titlewidget.cpp |5
 src/ui/editsub_ui.ui   |  119 +
 src/ui/profiledialog_ui.ui |   24 +++
 src/ui/titlewidget_ui.ui   |   98 ++
 src/widgets/colorpickerwidget.cpp  |5
 46 files changed, 593 insertions(+), 136 deletions(-)

I have attached the diff.


unblock kdenlive/20.12.3-1

-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-16-amd64 (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


kdenlive.diff.gz
Description: application/gzip

Bug#986037: kdenlive: crashes on audio setup

[Patrick Matthäi]

severity #986037 important
thanks

Hi Norbert and Dan,

Am 28.03.21 um 14:11 schrieb Norbert Preining:

Package: kdenlive
Version: 20.12.3-1
Severity: grave



Since (for myself?) this issue does not affect Debian bullseye 
downgrading the severity, because this release could not migrate then..




Justification: renders package unusable

Hi

I am running kdenlive with the kde frameworks from experimental, but
that shouldn't be a problem I thought.

I see crashes/segfaults on every start of kdenlive. Backtrace is:
(gdb) bt
#0  0x7fff898862a0 in fftw_execute () from 
/usr/lib/x86_64-linux-gnu/libfftw3.so.3
#1  0x7fff894207f5 in ?? () from /usr/lib/x86_64-linux-gnu/mlt/libmltplus.so
#2  0x76d93b88 in mlt_frame_get_audio () from 
/usr/lib/x86_64-linux-gnu/libmlt.so.6
#3  0x76d722b8 in Mlt::Frame::get_audio(mlt_audio_format&, int&, int&, 
int&) () from /usr/lib/x86_64-linux-gnu/libmlt++.so.3
#4  0x558b8929 in ?? ()
#5  0x558b4aab in ?? ()
#6  0x556e25a5 in ?? ()
#7  0x752d6e72 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x752d3b81 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x74382ea7 in start_thread (arg=) at 
pthread_create.c:477
#10 0x74e2cdef in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

and when I enter "c" into gdb to continue another segfault happens:
(gdb) c
Continuing.
[Thread 0x7fff1a3fc700 (LWP 250120) exited]

Thread 1 "kdenlive" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7102d8c0 (LWP 250071)]
0x703ba570 in QXcbConnection::getSelectionOwner(unsigned int) const () 
from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
(gdb) bt
#0  0x703ba570 in QXcbConnection::getSelectionOwner(unsigned int) const 
() from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#1  0x703b4f88 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#2  0x7715c998 in QQuickTextInput::q_canPasteChanged() () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#3  0x771691e3 in QQuickTextInput::qt_metacall(QMetaObject::Call, int, 
void**) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#4  0x745bac76 in QQuickTextField::qt_metacall(QMetaObject::Call, int, 
void**) ()
from /usr/lib/x86_64-linux-gnu/libQt5QuickTemplates2.so.5
#5  0x754eb290 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x75ed0935 in QClipboard::emitChanged(QClipboard::Mode) () from 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#7  0x703b98a4 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) 
() from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#8  0x703bacd6 in 
QXcbConnection::processXcbEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#9  0x703dd7d3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#10 0x739bde6b in g_main_context_dispatch () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x739be118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x739be1cf in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7550c4bf in 
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x754b392b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x754bbba0 in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x556360d4 in ?? ()
#17 0x74d55d0a in __libc_start_main (main=0x55634c20, argc=1, 
argv=0x7fffd8a8, init=, fini=,
 rtld_fini=, stack_end=0x7fffd898) at 
../csu/libc-start.c:308
#18 0x5563d6ba in _start ()
(gdb)

and then a final continue
(gdb) c
Continuing.
QSocketNotifier: Invalid socket 7 and type 'Read', disabling...
QSocketNotifier: Invalid socket 13 and type 'Read', disabling...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
Invalid read from eventfd: Bad file descriptor
Code should not be reached at pulsecore/fdsem.c:157, function flush(). Aborting.
[Thread 0x7fffefee3700 (LWP 250075) exited]
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kdenlive path = /usr/bin pid = 250071
KCrash: Arguments: /usr/bin/kdenlive
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
Cannot find user-level thread for LWP 250102: generic error
(gdb) Cannot find user-level thread for LWP 250098: generic error


Not sure whether this is a pulseaudio, kdenlive, or one of the
frameworks problems, though.



This does not look like kdenlive for me, maybe from mlt, what do you say 
Dan?


Norbert: Can you confirm it works/not with 20.12.2 and with Debian 
bullseye without experimental packages?




Best

Norbert

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

Bug#985457: geoip-database update

[Patrick Matthäi]

Package: geoip-database
Severity: wishlist

Am 11.03.2021 um 00:02 schrieb Marco d'Itri:
> Did you consider packaging https://mailfud.org/geoip-legacy/, which is 
> derived from the current GeoLite2 database?
>

Bug#983876: unblock: otrs2/6.0.32-1

[Patrick Matthäi]

Hi

Am 16.03.21 um 20:28 schrieb Paul Gevers:

Control: tags -1 moreinfo

Hi Patrick,

On 15-03-2021 15:12, Patrick Matthäi wrote:

reopen #983876
thanks

Am 02.03.21 um 19:38 schrieb Paul Gevers:

Hi Patrick,

On 02-03-2021 16:58, Patrick Matthäi wrote:

I just uploaded the otrs2 6.0.32 package to experimental.  Could I have your 
ACK for bullseye? :-)

otrs2 is neither a key package [1], nor listed on the (build-)essential
list [1]. As long as you follow the soft freeze rules [3] and ensure
that the package migrates before the start of the hard freeze
(12-03-2021), there is nothing for us to unblock. I'm wondering if and
suspect that you are asking our permission to upload a new upstream
source. It's hardly doable for us to do that for all packages in Debian,
so we expect you honor the freeze rules and make the judgement yourself
if a new upstream version for your package is appropriate at this state.

Paul

[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
[2] https://release.debian.org/bullseye/essential-and-build-essential.txt
[3] https://release.debian.org/bullseye/freeze_policy.html#soft


Hi,

I uploaded the release to unstable just one hour after your mail and
there were still 10 days for the package to migrate. But the migration
process was not done before the freeze so now I need an unblock:

   * Migration status for otrs2 (6.0.30-2 to 6.0.32-2): BLOCKED: Needs an
 approval (either due to a freeze, the source suite or a manual hint)
   * Too young, only 12 of 20 days old

Now it needs also 10 days more, but in two days 6.0.30 should be
AUTORMed from testing :(


The diff is not reviewable:

  5637 files changed, 151250 insertions(+), 29937 deletions(-)

If you think you can provide a diff that can be reviewed, please provide
one, but please show how you filtered the diff too.

Paul


I have attached a filtered diff. Steps to reproduce:

1) find otrs2-6.0.32/ -type f -exec sed 's/Copyright (C) 2001-2021 OTRS 
AG/Copyright (C) 2001-2020 OTRS AG/g' -i {} \;
To filter out copyright changes on most files (a few small ones are 
still in the diff)


2) diff -Naur otrs2-6.0.30/ otrs2-6.0.32/ -x ckeditor-4.7.0 -x 
ckeditor-4.16.0 -x "*.png" -x "*.po" -x ARCHIVE -x development -x 
Selenium -x spec -x auto_build -x CHANGES.md -x .pc -x .gitignore -x 
.github -x AUTHORS.md -x CONTRIBUTING.md -x README.md -x RELEASE -x 
.mailmap -x .otrs-ci.yml -x database -x test -x .weblate


Many changes are not relevant for Debian (readme files, test, 
auto_build, spec, development, .github etc), many other changes are just 
product name changes, also in database. ckeditor is relevant for this 
release, but..


3) all other changes are mostly only removing the not working "OTRS 
Business" solution stuff and updating the ckeditor to 4.16.0, which is 
security relevant



This is the filtered diffstat:


 Kernel/Config/Defaults.pm |    2
 Kernel/Config/Files/XML/Calendar.xml |    2
 Kernel/Config/Files/XML/Framework.xml |   63 +++-
 Kernel/Config/Files/XML/Ticket.xml |   18 
 Kernel/Modules/AdminDynamicField.pm |   20 -
 Kernel/Modules/AgentTicketZoom.pm |   12 ---
 Kernel/Modules/PictureUpload.pm |    3
 Kernel/Output/HTML/Notification/AgentOTRSBusiness.pm |   16 
 Kernel/Output/HTML/Notification/PackageManagerCheckNotVerifiedPackages.pm |   
53 --
 Kernel/Output/HTML/Templates/Standard/AdminAppointmentNotificationEvent.tt |   
 8 --
 Kernel/Output/HTML/Templates/Standard/AdminCloudServices.tt |    8 --
 Kernel/Output/HTML/Templates/Standard/AdminDynamicField.tt |   32 
 Kernel/Output/HTML/Templates/Standard/AdminGenericInterfaceWebservice.tt |   
14 ---
 Kernel/Output/HTML/Templates/Standard/AdminNotificationEvent.tt |    8 --
 Kernel/Output/HTML/Templates/Standard/AdminPackageManager.tt |   47 
+---

 Kernel/Output/HTML/Templates/Standard/AdminProcessManagement.tt |   11 --
 Kernel/Output/HTML/Templates/Standard/AdminSystemConfiguration.tt |    2
 Kernel/Output/HTML/Templates/Standard/AdminSystemConfigurationDeployment.tt |  
  9 +-
 Kernel/Output/HTML/Templates/Standard/AgentAppointmentEdit.tt |    6 -
 Kernel/Output/HTML/Templates/Standard/Copyright.tt |    4 -
 Kernel/Output/HTML/Templates/Standard/CustomerFooter.tt |   13 ---
 Kernel/Output/HTML/Templates/Standard/Error.tt |   36 -
 Kernel/Output/HTML/Templates/Standard/Footer.tt |   13 ---
 Kernel/Output/HTML/Templates/Standard/Header.tt |    5 -
 Kernel/Output/HTML/Templates/Standard/Installer.tt |   75 
++--

 Kernel/Output/HTML/Templates/Standard/InstallerFinish.tt |    7 -
 Kernel/Output/HTML/Templates/Standard/SystemConfiguration/SettingsList.tt |    
4 -
 
Kernel/Output/HTML/Templates/Standard/SystemConfiguration/Sidebar/OTRSBusinessTeaser.tt
 |   19 -
 Kernel/Output/HTML/TicketMenu/TeaserAttachmentView.pm |   31 
 Kernel/Output/PDF/Ticket.pm |   33 +++-
 Kernel/System/CommunicationChannel.pm |    6 -
 Kernel/System/Conso

Bug#983876: unblock: otrs2/6.0.32-1

[Patrick Matthäi]

reopen #983876
thanks

Am 02.03.21 um 19:38 schrieb Paul Gevers:

Hi Patrick,

On 02-03-2021 16:58, Patrick Matthäi wrote:

I just uploaded the otrs2 6.0.32 package to experimental.  Could I have your 
ACK for bullseye? :-)

otrs2 is neither a key package [1], nor listed on the (build-)essential
list [1]. As long as you follow the soft freeze rules [3] and ensure
that the package migrates before the start of the hard freeze
(12-03-2021), there is nothing for us to unblock. I'm wondering if and
suspect that you are asking our permission to upload a new upstream
source. It's hardly doable for us to do that for all packages in Debian,
so we expect you honor the freeze rules and make the judgement yourself
if a new upstream version for your package is appropriate at this state.

Paul

[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
[2] https://release.debian.org/bullseye/essential-and-build-essential.txt
[3] https://release.debian.org/bullseye/freeze_policy.html#soft


Hi,

I uploaded the release to unstable just one hour after your mail and 
there were still 10 days for the package to migrate. But the migration 
process was not done before the freeze so now I need an unblock:


 * Migration status for otrs2 (6.0.30-2 to 6.0.32-2): BLOCKED: Needs an
   approval (either due to a freeze, the source suite or a manual hint)
 * Too young, only 12 of 20 days old

Now it needs also 10 days more, but in two days 6.0.30 should be 
AUTORMed from testing :(

Bug#983876: unblock: otrs2/6.0.32-1

[Patrick Matthäi]

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

Hello release team,

I try to citize from my mails to the security team:, it's about #982927:


Yesterday I had a videocall with the owner and lead developer of OTOBO. They
want to support me keeping the otrs2 source package in a good shape for
Bullseye, so that users of the package dont have to worry now.
Kicking the package out of Debian would not be optimal.
They also showed me https://github.com/znuny/Znuny (https://www.znuny.com/) - 
they
also forked OTRS CE 6 and fixing bugs and security bugs, also all known open 
bugs
in CVE/Debian atm. So the plan would be now:
* Switch the source of the otrs2 package to the znuny one, so that we have 
releases
  based on an open(source) maintained safe codebase => can I get the go from 
you for that?
* otrs packaging at all is obsolete for bullseye+1. I will package otobo, also 
with
  otobo support, and we will work on a easy way so that users later can migrate
  from otrs to otobo
We also spoke about the open security issues, there is indeed one in the 
CKEditor, but:
#980891:
They way otrs uses this library it should not be possible to attack the user, 
mostly only the attacker himself
#982586:
Thats a wrong information from the OTRS AG, because it does not affect otrs 6 
CE.
It depends on that you use an external interface, which is available in OTRS 7 
and 8
(not free) and maybe in the not-free otrs 6 package via addon, but not in the 
community edition, which is also packaged in Debian.

XX itself is not helpful at all anymore and just wrote me **
I hope switching as fast as possible to the znuny fork for the otrs2 source 
package is also an option for you, I dont want to release bullseye without it 


-

I just uploaded the otrs2 6.0.32 package to experimental.  Could I have your 
ACK for bullseye? :-)

-- System Information:
Debian Release: 10.8
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-14-amd64 (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

Bug#975695: please allow to use UUIDs for "paste numbers"

[Patrick Matthäi]

Hi

Am 25.11.20 um 09:54 schrieb Tomas Pospisek:

Source: pnopaste
Version: 1.7.4
Severity: wishlist

Having "pastes" with monotonically increasing numbers allows an
"attacker" to discover all pastes by simply counting through
them from 0 on.

Assigning UUIDs to pastes would make that computationally
impossible.

Something like http://nopaste.linux-dev.org/?jA7vBQ8927 or such.

*t

first thanks for your other patch. I support this idea and I will 
implement it with the next release, which also gets backports then.


But first I have release and uploaded today version 1.8 with a small 
adjustment for pnopaste-cli, so that this client supports in the future 
also UUID paste numbers.

Bug#979598: kdenlive: Language setting doesn't aeffect anything

[Patrick Matthäi]

Hi

Am 08.01.21 um 21:45 schrieb Grzesiek11:

Package: kdenlive
Version: 20.12.0-2
Severity: important
Tags: l10n


20.12.1 is also affected



Dear Maintainer,

I noticed that since one of recent KDE updates in Debian (these are happening 
really quickly now, good work, but because of that I don't really remember 
which one was it!) Kdenlive (and some other KDE programs like DrKonqi, I'm 
going to report this to every aeffected package) ignores the language setting 
in almost all menus.

The language setting is accessible from 'Settings' -> 'Configure Language...'. 
No matter which language it's set to, the interface remains in English, except for 
some buttons like 'Defaults', 'OK' and 'Cancel' in the 'Configure Language' dialog 
itself.

I tried reinstalling (with purge) 'kdenlive' and 'kdenlive-data', deleting my 
config files, running a brand-new user and checking on another Unstable system 
I own.

I also asked for confirming the problem on the #debian-next channel (OFTC): 2 
other users reported the same problem.

@JB:
Could you help here, why translations are not working at all? I see 
similar problems on google with appstream and other versions of 
kdenlive, but could not find the root cause of this

Bug#975632: please enable setting proxy via environment

[Patrick Matthäi]

tags 975632 + pending
thanks


Thanks for your patch, will be available in 2.0 :)


Am 24.11.20 um 11:56 schrieb Tomas Pospisek:

Package: pnopaste-cli
Version: 1.7-4
Severity: wishlist
Tags: patch

Hi Patrick,

could you please enable proxy settings detection?

After the line:

 my $Agent = LWP:UserAgent->new;

add the line:

 $Agent->env_proxy;

that's it. Now pnopaste-cli will recognize:

 http_proxy=...
 https_proxy=...

Environment variables and use them correctly.

Thanks a lot for pnopaste!
*t

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

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

Versions of packages pnopaste-cli depends on:
ii  libwww-perl  6.36-2
ii  perl 5.28.1-6+deb10u1

pnopaste-cli recommends no packages.

Versions of packages pnopaste-cli suggests:
pn  pnopaste  

Bug#973297: Conflicting file with fonts-noto-mono

[Patrick Matthäi]

Package: fonts-noto-core
Version: 20201027-1
Severity: serious

Hi,

just today:

root@gnu:~# LC_ALL=C apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  fonts-noto-core
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
43 not fully installed or removed.
Need to get 0 B/10.8 MB of archives.
After this operation, 63.5 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 192329 files and directories currently installed.)
Preparing to unpack .../fonts-noto-core_20201027-1_all.deb ...
Unpacking fonts-noto-core (20201027-1) over (20200323-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/fonts-noto-core_20201027-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/fonts/truetype/noto/NotoMono-Regular.ttf', which is also in 
package fonts-noto-mono 20201027-1

dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/fonts-noto-core_20201027-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@gnu:~#

Bug#962259: Creating Webhooks fails and returns error 500

[Patrick Matthäi]

Hi,

a temporary workaround is editing
/usr/lib/ruby/vendor_ruby/attr_encrypted/adapters/active_record.rb and
comment out line 84:
set_attribute_was(attr, __send__(attr)) if value != __send__(attr)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#967633: [Mlt-devel] Fwd: Bug#967633: mlt: depends on deprecated GTK 2

[Patrick Matthäi]

oh thank you. Then I will remove the dependencies :)

Am 04.08.20 um 18:14 schrieb Dan Dennedy:
> On Tue, Aug 4, 2020 at 9:12 AM Patrick Matthäi  <mailto:patr...@linux-dev.org>> wrote:
>
> Hi Dan,
>
> any doubts about deactivating gtk2? It is also marked as
> deprecated (src/modules/gtk2/deprecated)
>
>
> Deprecation is deactivation in the MLT configure script. For the
> latest release you must remove that file to activate that module.
>
>
>  Weitergeleitete Nachricht 
> Betreff:  Bug#967633: mlt: depends on deprecated GTK 2
> Weitersenden-Datum:   Tue, 04 Aug 2020 10:59:05 +
> Weitersenden-Von: s...@debian.org <mailto:s...@debian.org>
> Weitersenden-An:  Patrick Matthäi 
> <mailto:pmatth...@debian.org>
> Datum:Tue, 04 Aug 2020 11:55:15 +0100
> Von:  s...@debian.org <mailto:s...@debian.org>
> Antwort an:   s...@debian.org <mailto:s...@debian.org>,
> 967633-mainto...@bugs.debian.org
> <mailto:967633-mainto...@bugs.debian.org>
> An:   mainto...@bugs.debian.org <mailto:mainto...@bugs.debian.org>
>
>
>
> Source: mlt
> Severity: normal
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> <mailto:pkg-gnome-maintain...@lists.alioth.debian.org>
> Usertags: gtk2 oldlibs
> Control: block 947713 by -1
>
> This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
> binary packages with a Depends on GTK 2.
>
> GTK 2 was superseded by GTK 3 in 2011 (see
> <https://bugs.debian.org/947713>
> <https://bugs.debian.org/947713>). It no longer receives any
> significant
> upstream maintenance, and in particular does not get feature
> development
> for new features like UI scaling on high-pixel-density displays
> (HiDPI)
> and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
> approaching release, so it seems like a good time to be thinking about
> minimizing the amount of GTK 2 in the archive.
>
> GTK 2 is used by some important productivity applications like
> GIMP, and
> has also historically been a popular UI toolkit for proprietary
> software
> that we can't change, so perhaps removing GTK 2 from Debian will
> never be
> feasible. However, it has reached the point where a dependency on
> it is
> a bug - not a release-critical bug, and not a bug that can necessarily
> be fixed quickly, but a piece of technical debt that maintainers
> should
> be aware of.
>
> A porting guide is provided in the GTK 3 documentation:
> https://developer.gnome.org/gtk3/stable/migrating.html
>
> Some libraries (for example libgtkspell0) expose GTK as part of their
> API/ABI, in which case removing the deprecated dependency requires
> breaking API/ABI. For these libraries, in many cases there will
> already
> be a corresponding GTK 3 version (for example libgtkspell3-3-0),
> in which
> case the GTK 2-based library should probably be deprecated or removed
> itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
> maintainers should talk to the dependent library's upstream developers
> about whether the dependent library should break API/ABI and switch
> to GTK 3, or whether the dependent library should itself be deprecated
> or removed.
>
> A few packages extend GTK 2 by providing plugins (theme engines, input
> methods, etc.) or themes, for example ibus and mate-themes. If these
> packages deliberately support GTK 2 even though it is deprecated, and
> they also support GTK 3, then it is appropriate to mark this
> mass-filed
> bug as wontfix for now. I have tried to exclude these packages from
> the mass-bug-filing, but I probably missed some of them.
>
> Regards,
> smcv
>
> ___
> Mlt-devel mailing list
> mlt-de...@lists.sourceforge.net
> <mailto:mlt-de...@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/mlt-devel
>

Bug#967633: Fwd: Bug#967633: mlt: depends on deprecated GTK 2

[Patrick Matthäi]

Hi Dan,

any doubts about deactivating gtk2? It is also marked as deprecated
(src/modules/gtk2/deprecated)


 Weitergeleitete Nachricht 
Betreff:Bug#967633: mlt: depends on deprecated GTK 2
Weitersenden-Datum: Tue, 04 Aug 2020 10:59:05 +
Weitersenden-Von:   s...@debian.org
Weitersenden-An:Patrick Matthäi 
Datum:  Tue, 04 Aug 2020 11:55:15 +0100
Von:s...@debian.org
Antwort an: s...@debian.org, 967633-mainto...@bugs.debian.org
An: mainto...@bugs.debian.org



Source: mlt
Severity: normal
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gtk2 oldlibs
Control: block 947713 by -1

This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.

GTK 2 was superseded by GTK 3 in 2011 (see
<https://bugs.debian.org/947713>). It no longer receives any significant
upstream maintenance, and in particular does not get feature development
for new features like UI scaling on high-pixel-density displays (HiDPI)
and native Wayland support. GTK 3 is in maintenance mode and GTK 4 is
approaching release, so it seems like a good time to be thinking about
minimizing the amount of GTK 2 in the archive.

GTK 2 is used by some important productivity applications like GIMP, and
has also historically been a popular UI toolkit for proprietary software
that we can't change, so perhaps removing GTK 2 from Debian will never be
feasible. However, it has reached the point where a dependency on it is
a bug - not a release-critical bug, and not a bug that can necessarily
be fixed quickly, but a piece of technical debt that maintainers should
be aware of.

A porting guide is provided in the GTK 3 documentation:
https://developer.gnome.org/gtk3/stable/migrating.html

Some libraries (for example libgtkspell0) expose GTK as part of their
API/ABI, in which case removing the deprecated dependency requires
breaking API/ABI. For these libraries, in many cases there will already
be a corresponding GTK 3 version (for example libgtkspell3-3-0), in which
case the GTK 2-based library should probably be deprecated or removed
itself. If there is no GTK 3 equivalent, of a GTK 2-based library,
maintainers should talk to the dependent library's upstream developers
about whether the dependent library should break API/ABI and switch
to GTK 3, or whether the dependent library should itself be deprecated
or removed.

A few packages extend GTK 2 by providing plugins (theme engines, input
methods, etc.) or themes, for example ibus and mate-themes. If these
packages deliberately support GTK 2 even though it is deprecated, and
they also support GTK 3, then it is appropriate to mark this mass-filed
bug as wontfix for now. I have tried to exclude these packages from
the mass-bug-filing, but I probably missed some of them.

Regards,
smcv

Bug#966490: libpam-geoip does not work with /usr/share/GeoIP/GeoIPCity.dat

[Patrick Matthäi]

Hi

Am 29.07.2020 um 11:32 schrieb Joerg Dorchain:
> Package: libpam-geoip
> Version: 2.1.1-1
>
> Hello,
>
> I used to have a working setup with libpam-geoip as 
>
> account required pam_geoip.so debug system_file=/etc/security/geoip.conf 
> geoip_db=/usr/share/GeoIP/GeoIPCity.dat
>
> After upgrading to this version, I find in authlog
> PASSV: pam_geoip(dovecot:account): failed to open geoip db 
> (/usr/share/GeoIP/GeoIPCity.dat - The MaxMind DB file contains invalid 
> metadata)
>
> This renders the geoip line rather useless.
>
> Besides, there is no hint of any potentials incompatibilities
> during upgrade, neither an upgrade path mentioned.
>
> FYI, the /usr/share/GeoIP/GeoIPCity.dat on my system is provided
> by the package geoip-database-extra version 20181108-1

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

The old package is not maintained anymore, upstream is "dead" so I have
decided to switch to this fork, using the new maxmind geoip2 databases.
You have to get the files from maxmind.com, since there is no package
for the databases, yet.
Maybe packaging them is also not possible, because of license issues
(same with the v1 database now).

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#965042: kdenlive: Should suggest vlc or xine-ui

[Patrick Matthäi]

tag 965042 + pending
thanks

Am 14.07.2020 um 22:17 schrieb Jacob Kauffmann:
> vlc | xine-ui
I am d'accord with you, thank you :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#964542: kdenlive: Segmentation fault at startup

[Patrick Matthäi]

reassign #964542 libgl1-mesa-dri
thanks

Am 12.07.2020 um 19:06 schrieb christophe.l...@telecom-bretagne.eu:
>>> this looks like a bug in your video driver or Qt5.
> Hi,
>   May I propose the following workarround:   edit 
> /usr/share/applications/org.kde.kdenlive.desktop
> and change the "Exec" command by :
>     Exec=env MESA_LOADER_DRIVER_OVERRIDE=i965  kdenlive %F
>
> (this is definitely a Mesa issue ;-) )
>
> Best regards
> Christophe
Thanks for testing this. Indeed I were unable to reproduce this issue
with an older unstable version and an up-to-date version from yesterday
with my amdgpu notebook.
So I am reassigning this issue.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#964542: kdenlive: Segmentation fault at startup

[Patrick Matthäi]

res)
>> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>>
>> Versions of packages kdenlive depends on:
>> ii  ffmpeg 7:4.3-2
>> ii  gstreamer1.0-plugins-bad   1.16.2-2.1+b1
>> ii  kded5  5.70.0-1
>> ii  kdenlive-data  20.04.2-1
>> ii  kinit  5.70.0-1
>> ii  kio5.70.1-1
>> ii  libc6  2.30-8
>> ii  libkf5archive5 5.70.0-1
>> ii  libkf5bookmarks5   5.70.0-1
>> ii  libkf5completion5  5.70.0-1
>> ii  libkf5configcore5  5.70.0-1
>> ii  libkf5configgui5   5.70.0-1
>> ii  libkf5configwidgets5   5.70.0-1
>> ii  libkf5coreaddons5  5.70.0-1
>> ii  libkf5crash5   5.70.0-1
>> ii  libkf5dbusaddons5  5.70.0-1
>> ii  libkf5declarative5 5.70.0-1
>> ii  libkf5filemetadata35.70.0-1
>> ii  libkf5guiaddons5   5.70.0-2
>> ii  libkf5i18n55.70.0-1
>> ii  libkf5iconthemes5  5.70.0-1
>> ii  libkf5itemviews5   5.70.0-1
>> ii  libkf5jobwidgets5  5.70.0-1
>> ii  libkf5kiocore5 5.70.1-1
>> ii  libkf5kiofilewidgets5  5.70.1-1
>> ii  libkf5kiowidgets5  5.70.1-1
>> ii  libkf5newstuff55.70.0-1
>> ii  libkf5notifications5   5.70.0-1
>> ii  libkf5notifyconfig55.70.0-1
>> ii  libkf5purpose-bin  5.70.0-1
>> ii  libkf5purpose5 5.70.0-1
>> ii  libkf5service-bin  5.70.0-1
>> ii  libkf5service5 5.70.0-1
>> ii  libkf5solid5   5.70.0-1
>> ii  libkf5widgetsaddons5   5.70.0-1
>> ii  libkf5xmlgui5  5.70.0-1+b1
>> ii  libmlt++3  6.20.0-2+b1
>> ii  libmlt66.20.0-2+b1
>> ii  libqt5concurrent5  5.14.2+dfsg-4
>> ii  libqt5core5a   5.14.2+dfsg-4
>> ii  libqt5dbus55.14.2+dfsg-4
>> ii  libqt5gui5 5.14.2+dfsg-4
>> ii  libqt5multimedia5  5.14.2-2
>> ii  libqt5network5 5.14.2+dfsg-4
>> ii  libqt5qml5 5.14.2+dfsg-2
>> ii  libqt5quick5   5.14.2+dfsg-2
>> ii  libqt5quickcontrols2-5 5.14.2+dfsg-2
>> ii  libqt5quickwidgets55.14.2+dfsg-2
>> ii  libqt5svg5 5.14.2-2
>> ii  libqt5webkit5  5.212.0~alpha4-4
>> ii  libqt5widgets5 5.14.2+dfsg-4
>> ii  libqt5xml5 5.14.2+dfsg-4
>> ii  librttr-core0.9.6  0.9.6+dfsg1-3
>> ii  libstdc++6 10.1.0-4
>> ii  melt   6.20.0-2+b1
>> ii  qml-module-qtgraphicaleffects  5.14.2-2
>> ii  qml-module-qtqml-models2   5.14.2+dfsg-2
>> ii  qml-module-qtquick-controls5.14.2-2
>> ii  qml-module-qtquick-controls2   5.14.2+dfsg-2
>> ii  qml-module-qtquick-dialogs 5.14.2-2
>> ii  qml-module-qtquick-layouts 5.14.2+dfsg-2
>> ii  qml-module-qtquick-window2 5.14.2+dfsg-2
>> ii  qml-module-qtquick25.14.2+dfsg-2
>>
>> Versions of packages kdenlive recommends:
>> ii  breeze-icon-theme  4:5.70.0-1
>> ii  dvdauthor  0.7.2-1+b3
>> ii  dvgrab 3.5+git20160707.1.e46042e-1+b1
>> ii  frei0r-plugins 1.7.0-1
>> ii  genisoimage9:1.1.11-3.1
>> ii  oxygen-icon-theme  5:5.70.0-1
>> ii  recordmydesktop0.3.8.1+svn602-1.1
>> ii  swh-plugins0.4.17-2
>>
>> Versions of packages kdenlive suggests:
>> pn  khelpcenter  
>>
>> -- no debconf information

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#963706: kdenlive with ffmpeg version 7:4.3-2 can't Render Project to MP4

[Patrick Matthäi]

Hi

Am 25.06.2020 um 18:10 schrieb Thom:
> Package: kdenlive
> Version: 20.04.2-1
> Severity: normal
>
> Dear Maintainer,
>
> 1. launch kdenlive
> 2. add movie clip to the new project
> 3. move clip to timeline
> 4. Press Render
> 5. on the Render Project tab try to select "MP4 - the dominating format 
> (H264/AAC)" and get the message "Unsupported video codec: libx264"
>
> Rollback to ffmpeg 7:4.2.2-1 solves the problem for me.
>
>

What is your output from "ffmpeg -codecs|grep x264" with 7:4.3-2 and
7:4.2.2-1?

@Debian Multimedia team:
Has there changed something?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#962259: Creating Webhooks fails and returns error 500

[Patrick Matthäi]

 5.2.0-1~bpo10+1
ii  ruby-redis-namespace   1.6.0-1
ii  ruby-redis-rails   5.0.2-3
ii  ruby-request-store 1.5.0-2~bpo10+1
ii  ruby-responders    3.0.0-3~bpo10+1
ii  ruby-retriable 3.1.2-1~bpo10+1
ii  ruby-rouge 3.19.0-1~bpo10+1
ii  ruby-rqrcode-rails3    0.1.7-1
ii  ruby-ruby-parser   3.11.0-4~bpo10+1
ii  ruby-rugged    0.28.3.1+ds-1~bpo10+1
ii  ruby-sanitize  4.6.6-2
ii  ruby-sassc 2.0.1-2~bpo10+1
ii  ruby-sassc-rails   2.1.2-3~bpo10+1
ii  ruby-seed-fu   2.3.7-3~bpo10+1
ii  ruby-sentry-raven  2.9.0-1~bpo10+1
ii  ruby-settingslogic 2.0.9-3
ii  ruby-sidekiq   5.2.7+dfsg-1~bpo10+1
ii  ruby-sidekiq-cron  1.1.0-3
ii  ruby-slack-messenger   2.3.3-2~bpo10+1
ii  ruby-snowplow-tracker  0.6.1-2~bpo10+1
ii  ruby-sprockets 3.7.2-1
ii  ruby-sshkey    2.0.0-2~bpo10+1
ii  ruby-stackprof 0.2.15-2~bpo10+1
ii  ruby-state-machines-activemodel    0.7.1-2~bpo10+1
ii  ruby-state-machines-activerecord   0.6.0-2~bpo10+1
ii  ruby-sys-filesystem    1.1.7-2
ii  ruby-task-list [node-deckar01-task-list]   2.3.1-1~bpo10+1
ii  ruby-toml-rb   1.0.0-2
ii  ruby-truncato  0.7.11-1~bpo10+1
ii  ruby-u2f   0.2.1-2
ii  ruby-uglifier  2.7.2+dfsg-2
ii  ruby-unf   0.1.4-2
ii  ruby-unf-ext   0.0.7.5-1
ii  ruby-unicorn-worker-killer 0.4.4-1
ii  ruby-unleash   0.1.6-2~bpo10+1
ii  ruby-valid-email   0.1.3-2~bpo10+1
ii  ruby-validates-hostname    1.0.7-1
ii  ruby-version-sorter    2.2.4-1~bpo10+1
ii  ruby-virtus    1.0.5-3
ii  ruby-vmstat    2.3.0-2+b1
ii  ruby-webpack-rails 0.9.11+git-1
ii  ruby-wikicloth 0.8.1+dfsg-4
ii  ruby-zip   2.0.0-1~bpo10+1
ii  ucf    3.0038+nmu1
ii  unicorn    5.5.3-1~bpo10+1
ii  webpack    4.30.0-9~bpo10+1
ii  yarnpkg    1.22.4-2~bpo10+1

Versions of packages gitlab recommends:
pn  certbot  
ii  gitaly   13.0.0+dfsg-1~bpo10+1

gitlab suggests no packages.

-- debconf information:
  gitlab/password-confirm: (password omitted)
  gitlab/app-password-confirm: (password omitted)
  gitlab/pgsql/app-pass: (password omitted)
  gitlab/pgsql/admin-pass: (password omitted)
  gitlab/pgsql/admin-user: postgres
  gitlab/upgrade-backup: true
  gitlab/pgsql/method: TCP/IP
* gitlab/fqdn: gitlab.int.leonex.de
  gitlab/remove-error: abort
* gitlab/dbconfig-install: true
  gitlab/upgrade-error: abort
  gitlab/passwords-do-not-match:
  gitlab/internal/skip-preseed: false
* gitlab/database-type: pgsql
* gitlab/remote/host: localhost
  gitlab/pgsql/authmethod-user: password
  gitlab/missing-db-package-error: abort
  gitlab/dbconfig-reinstall: false
  gitlab/pgsql/authmethod-admin: ident
  gitlab/pgsql/manualconf:
  gitlab/remote/newhost: localhost
  gitlab/letsencrypt: false
  gitlab/dbconfig-upgrade: true
* gitlab/ssl: true
  gitlab/dbconfig-remove: true
  gitlab/letsencrypt_email:
  gitlab/install-error: abort
  gitlab/purge: false
  gitlab/internal/reconfiguring: false
  gitlab/db/app-user: gitlab@localhost
  gitlab/purge_data: true
  gitlab/remote/port:
  gitlab/pgsql/changeconf: false
  gitlab/pgsql/no-empty-passwords:
  gitlab/db/dbname: gitlab_production

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#962258: Error 500 on uploading project avatar

[Patrick Matthäi]

   0.4.10-1
ii  ruby-re2   1.2.0-1~bpo10+1
ii  ruby-recaptcha 4.11.1-2
ii  ruby-redcloth  4.3.2-3+b1
ii  ruby-redis 4.1.2-4~bpo10+1
ii  ruby-redis-actionpack  5.2.0-2~bpo10+1
ii  ruby-redis-activesupport   5.2.0-1~bpo10+1
ii  ruby-redis-namespace   1.6.0-1
ii  ruby-redis-rails   5.0.2-3
ii  ruby-request-store 1.5.0-2~bpo10+1
ii  ruby-responders    3.0.0-3~bpo10+1
ii  ruby-retriable 3.1.2-1~bpo10+1
ii  ruby-rouge 3.19.0-1~bpo10+1
ii  ruby-rqrcode-rails3    0.1.7-1
ii  ruby-ruby-parser   3.11.0-4~bpo10+1
ii  ruby-rugged    0.28.3.1+ds-1~bpo10+1
ii  ruby-sanitize  4.6.6-2
ii  ruby-sassc 2.0.1-2~bpo10+1
ii  ruby-sassc-rails   2.1.2-3~bpo10+1
ii  ruby-seed-fu   2.3.7-3~bpo10+1
ii  ruby-sentry-raven  2.9.0-1~bpo10+1
ii  ruby-settingslogic 2.0.9-3
ii  ruby-sidekiq   5.2.7+dfsg-1~bpo10+1
ii  ruby-sidekiq-cron  1.1.0-3
ii  ruby-slack-messenger   2.3.3-2~bpo10+1
ii  ruby-snowplow-tracker  0.6.1-2~bpo10+1
ii  ruby-sprockets 3.7.2-1
ii  ruby-sshkey    2.0.0-2~bpo10+1
ii  ruby-stackprof 0.2.15-2~bpo10+1
ii  ruby-state-machines-activemodel    0.7.1-2~bpo10+1
ii  ruby-state-machines-activerecord   0.6.0-2~bpo10+1
ii  ruby-sys-filesystem    1.1.7-2
ii  ruby-task-list [node-deckar01-task-list]   2.3.1-1~bpo10+1
ii  ruby-toml-rb   1.0.0-2
ii  ruby-truncato  0.7.11-1~bpo10+1
ii  ruby-u2f   0.2.1-2
ii  ruby-uglifier  2.7.2+dfsg-2
ii  ruby-unf   0.1.4-2
ii  ruby-unf-ext   0.0.7.5-1
ii  ruby-unicorn-worker-killer 0.4.4-1
ii  ruby-unleash   0.1.6-2~bpo10+1
ii  ruby-valid-email   0.1.3-2~bpo10+1
ii  ruby-validates-hostname    1.0.7-1
ii  ruby-version-sorter    2.2.4-1~bpo10+1
ii  ruby-virtus    1.0.5-3
ii  ruby-vmstat    2.3.0-2+b1
ii  ruby-webpack-rails 0.9.11+git-1
ii  ruby-wikicloth 0.8.1+dfsg-4
ii  ruby-zip   2.0.0-1~bpo10+1
ii  ucf    3.0038+nmu1
ii  unicorn    5.5.3-1~bpo10+1
ii  webpack    4.30.0-9~bpo10+1
ii  yarnpkg    1.22.4-2~bpo10+1

Versions of packages gitlab recommends:
pn  certbot  
ii  gitaly   13.0.0+dfsg-1~bpo10+1

gitlab suggests no packages.

-- debconf information:
  gitlab/password-confirm: (password omitted)
  gitlab/app-password-confirm: (password omitted)
  gitlab/pgsql/app-pass: (password omitted)
  gitlab/pgsql/admin-pass: (password omitted)
  gitlab/pgsql/admin-user: postgres
  gitlab/upgrade-backup: true
  gitlab/pgsql/method: TCP/IP
* gitlab/fqdn: gitlab.int.leonex.de
  gitlab/remove-error: abort
* gitlab/dbconfig-install: true
  gitlab/upgrade-error: abort
  gitlab/passwords-do-not-match:
  gitlab/internal/skip-preseed: false
* gitlab/database-type: pgsql
* gitlab/remote/host: localhost
  gitlab/pgsql/authmethod-user: password
  gitlab/missing-db-package-error: abort
  gitlab/dbconfig-reinstall: false
  gitlab/pgsql/authmethod-admin: ident
  gitlab/pgsql/manualconf:
  gitlab/remote/newhost: localhost
  gitlab/letsencrypt: false
  gitlab/dbconfig-upgrade: true
* gitlab/ssl: true
  gitlab/dbconfig-remove: true
  gitlab/letsencrypt_email:
  gitlab/install-error: abort
  gitlab/purge: false
  gitlab/internal/reconfiguring: false
  gitlab/db/app-user: gitlab@localhost
  gitlab/purge_data: true
  gitlab/remote/port:
  gitlab/pgsql/changeconf: false
  gitlab/pgsql/no-empty-passwords:
  gitlab/db/dbname: gitlab_production

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#958408: etherape: crashes with "critical: read_all() failed on control socket"

[Patrick Matthäi]

Hi,

Am 28.04.2020 um 00:08 schrieb Bernhard Übelacker:
> Dear Maintainer,
> I could reproduce the issue on i386 and tried to collect
> some more information.
>
> It crashes with the backtrace below.
>
> The crash seems to be caused by using the wrong data type
> in the calls to variadic functions goo_canvas_ellipse_new
> and goo_canvas_polyline_new.
>
> The modifications below made it work at i386 too.
> (Just changing integer to floating point values).
> Tested it just shortly.
>
>
>
> (gdb) bt
> #0  __strchr_sse2_bsf () at 
> ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:60
> #1  0xb73243ce in g_param_spec_pool_lookup (pool=0x136e260, param_name=0x1 
> , owner_type=26014064, 
> walk_ancestors=1) at ../../../gobject/gparam.c:1071
> #2  0xb731fbce in g_object_set_valist (object=, 
> first_property_name=, var_args=0xbfb6a0b4 "") at 
> ../../../gobject/gobject.c:2289
> #3  0xb7f6e4be in goo_canvas_ellipse_new (parent=0x1685848, center_x=0, 
> center_y=0, radius_x=0, radius_y=0) at goocanvasellipse.c:214
> #4  0x0044feea in check_new_node (canvas=0x1650380, node=0x14b1600) at 
> diagram.c:935
> #5  diagram_update_nodes (canvas=0x1650380) at diagram.c:541
> #6  update_diagram (canvas=0x1650380) at diagram.c:735
> #7  0x00450828 in update_diagram_callback (data=0x0) at diagram.c:1910
> #8  0xb7076a51 in g_timeout_dispatch (source=0x14793c0, callback=0x450810 
> , user_data=0x0) at ../../../glib/gmain.c:4667
> #9  0xb7075e65 in g_main_dispatch (context=0x13b1fd0) at 
> ../../../glib/gmain.c:3182
> #10 g_main_context_dispatch (context=0x13b1fd0) at ../../../glib/gmain.c:3847
> #11 0xb7076269 in g_main_context_iterate (context=0x13b1fd0, 
> block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
> ../../../glib/gmain.c:3920
> #12 0xb7076609 in g_main_loop_run (loop=0x1478ea0) at 
> ../../../glib/gmain.c:4116
> #13 0xb799139e in gtk_main () at ../../../../gtk/gtkmain.c:1323
> #14 0x0044049e in main (argc=, argv=) at 
> main.c:316
>
>
>
>
>
> --- etherape-0.9.18.orig/src/diagram.c
> +++ etherape-0.9.18/src/diagram.c
> @@ -939,7 +939,7 @@ static gint check_new_node(node_t * node
>  0.0,
>  "fill-color", "white",
>  "stroke-color", "black",
> -"line-width", 0,
> +"line-width", 0.0,
>   "visibility", GOO_CANVAS_ITEM_INVISIBLE,
>   NULL);
>addref_canvas_obj(G_OBJECT(new_canvas_node->node_item));
> @@ -1480,16 +1480,16 @@ static gint check_new_link(link_id_t * l
>/* set the lines position using groups positions */
>new_canvas_link->src_item =
>  goo_canvas_polyline_new(rootgroup, TRUE, 2,
> -0,0,
> -1,1,
> +0.0,0.0,
> +1.0,1.0,
>  "fill-color", "tan",
>  NULL);
>g_object_ref(G_OBJECT (new_canvas_link->src_item));
>  
>new_canvas_link->dst_item =
>  goo_canvas_polyline_new(rootgroup, TRUE, 2,
> -0,0,
> -1,1,
> +0.0,0.0,
> +1.0,1.0,
>  "fill-color", "tan",
>  NULL);
>g_object_ref(G_OBJECT (new_canvas_link->dst_item));
>
>
>
>
>
>
>
> PS.: Could not install etherape on a multiarch amd64/i386 system because
>  it tells it depends on non-existing etherape-data:i386.

Thanks for your patch. I have tested it on my amd64 machine, where I
didn't had problems. Anyway it also builds fine with your patch and I
have uploaded it.

@rghetta:
Do you want to merge it?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#931678: buster-pu: package qdirstat/1.5-1+deb10u1

[Patrick Matthäi]

Hi

Am 25.04.2020 um 21:31 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
>
> On Thu, 2019-08-08 at 11:23 +0200, Patrick Matthäi wrote:
>> Control: tags -1 - moreinfo
>>
>> Am 09.07.2019 um 10:41 schrieb Patrick Matthäi:
>>> Control: tags -1 - moreinfo
>>>
>>> Am 09.07.2019 um 10:30 schrieb Adam D. Barratt:
>>>> Control: tags -1 + moreinfo
>>>>
>>>> On 2019-07-09 09:22, Patrick Matthäi wrote:
>>>>> upstream just fixed a bug in qdirstat, where user configured
>>>>> MIME
>>>>> categories
>>>>> are not saved properly, as described here:
>>>>> https://github.com/shundhammer/qdirstat/issues/109
>>>> This doesn't appear to be fixed in unstable yet, which is (as
>>>> ever) a
>>>> prerequisite. Please let us know, and remove the moreinfo tag,
>>>> once it
>>>> is.
>>>>
>>>> Regards,
>>>>
>>>> Adam
>>> Heh, you were too fast ;) I were just building other packages, just
>>> uploaded the new upstream version right now:
>>> qdirstat_1.5.90-1_amd64.changes
>> Oh forgot to CC the bug.. ;)
>>
> Apologies for the long delay. Please go ahead.
>
> Regards,
>
> Adam
Uploaded now :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#955417: WPA2 enterprise wifi not working after a short time

[Patrick Matthäi]

Am 31.03.20 um 16:22 schrieb Patrick Matthäi:
> Am 31.03.20 um 15:59 schrieb Andrej Shadura:
>>  Hi Patrick,
>>
>> On Tue, 31 Mar 2020 at 15:12, Patrick Matthäi  wrote:
>>> I have got a problem with my Dell Inspiron 3585 wifi adapter:
>>> 03:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless
>>> Network Adapter (rev 31)
>> Could you please test and verify whether this also happens with
>> 2:2.9.0-11 (testing) and 2:2.9.0+git20200221+f65da0c-1 (experimental)?
>>
> I have just tested experimental and the same issue:
>
>
> Mar 31 16:18:50 gnu wpa_supplicant[718]: wlp3s0:
> CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-76 noise=-98 txrate=6000
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: SME: Trying to
> authenticate with 00:1a:8c:c7:63:a9 (SSID='LEO-WLAN-5G' freq=5180 MHz)
> Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3228]
> device (wlp3s0): supplicant interface state: completed -> authenticating
> Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3229]
> device (p2p-dev-wlp3s0): supplicant management interface state:
> completed -> authenticating
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
> CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
> Mar 31 16:18:57 gnu wpa_supplicant[718]: FT: Failed to set PTK to the driver
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: Trying to associate
> with 00:1a:8c:c7:63:a9 (SSID='LEO-WLAN-5G' freq=5180 MHz)
> Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3359]
> device (wlp3s0): supplicant interface state: authenticating -> associating
> Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3359]
> device (p2p-dev-wlp3s0): supplicant management interface state:
> authenticating -> associating
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: Associated with
> 00:1a:8c:c7:63:a9
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: WPA: Key negotiation
> completed with 00:1a:8c:c7:63:a9 [PTK=CCMP GTK=CCMP]
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: CTRL-EVENT-CONNECTED -
> Connection to 00:1a:8c:c7:63:a9 completed [id=0 id_str=]
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
> CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
> CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
> Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3524]
> device (wlp3s0): supplicant interface state: associating -> completed
> Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3527]
> device (p2p-dev-wlp3s0): supplicant management interface state:
> associating -> completed
> Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
> CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=-98 txrate=6000
>

I also made another test. While I was connected with the AP I have
disabled PoE for the AP on the switch (hard shutdown), wifi connects
with the other AP and everything still works. This is the daemon.log
from this test:


Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0: CTRL-EVENT-DISCONNECTED
bssid=00:1a:8c:c7:63:a9 reason=4 locally_generated=1
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0319]
sup-iface[0x5623b13a2100,wlp3s0]: connection disconnected (reason -4)
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0: SME: Trying to
authenticate with 00:1a:8c:c7:5f:7a (SSID='LEO-WLAN-5G' freq=5180 MHz)
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0818]
device (wlp3s0): supplicant interface state: completed -> authenticating
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0818]
device (p2p-dev-wlp3s0): supplicant management interface state:
completed -> authenticating
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0: Trying to associate
with 00:1a:8c:c7:5f:7a (SSID='LEO-WLAN-5G' freq=5180 MHz)
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0854]
device (wlp3s0): supplicant interface state: authenticating -> associating
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0855]
device (p2p-dev-wlp3s0): supplicant management interface state:
authenticating -> associating
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0: Associated with
00:1a:8c:c7:5f:7a
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0982]
device (wlp3s0): supplicant interface state: associating -> associated
Mar 31 16:26:00 gnu NetworkManager[707]:   [1585664760.0982]
device (p2p-dev-wlp3s0): supplicant management interface state:
associating -> associated
Mar 31 16:26:00 gnu wpa_supplicant[718]: wlp3s0: CTRL-EVENT-EAP-STARTED
EAP authentication started
Mar 31

Bug#955417: WPA2 enterprise wifi not working after a short time

[Patrick Matthäi]

Am 31.03.20 um 15:59 schrieb Andrej Shadura:
>  Hi Patrick,
>
> On Tue, 31 Mar 2020 at 15:12, Patrick Matthäi  wrote:
>> I have got a problem with my Dell Inspiron 3585 wifi adapter:
>> 03:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless
>> Network Adapter (rev 31)
> Could you please test and verify whether this also happens with
> 2:2.9.0-11 (testing) and 2:2.9.0+git20200221+f65da0c-1 (experimental)?
>

I have just tested experimental and the same issue:


Mar 31 16:18:50 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-76 noise=-98 txrate=6000
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: SME: Trying to
authenticate with 00:1a:8c:c7:63:a9 (SSID='LEO-WLAN-5G' freq=5180 MHz)
Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3228]
device (wlp3s0): supplicant interface state: completed -> authenticating
Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3229]
device (p2p-dev-wlp3s0): supplicant management interface state:
completed -> authenticating
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mar 31 16:18:57 gnu wpa_supplicant[718]: FT: Failed to set PTK to the driver
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: Trying to associate
with 00:1a:8c:c7:63:a9 (SSID='LEO-WLAN-5G' freq=5180 MHz)
Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3359]
device (wlp3s0): supplicant interface state: authenticating -> associating
Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3359]
device (p2p-dev-wlp3s0): supplicant management interface state:
authenticating -> associating
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: Associated with
00:1a:8c:c7:63:a9
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: WPA: Key negotiation
completed with 00:1a:8c:c7:63:a9 [PTK=CCMP GTK=CCMP]
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0: CTRL-EVENT-CONNECTED -
Connection to 00:1a:8c:c7:63:a9 completed [id=0 id_str=]
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3524]
device (wlp3s0): supplicant interface state: associating -> completed
Mar 31 16:18:57 gnu NetworkManager[707]:   [1585664337.3527]
device (p2p-dev-wlp3s0): supplicant management interface state:
associating -> completed
Mar 31 16:18:57 gnu wpa_supplicant[718]: wlp3s0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-67 noise=-98 txrate=6000

Bug#955417: WPA2 enterprise wifi not working after a short time

[Patrick Matthäi]

m
00:1a:8c:c7:5f:7a (capab=0x11 status=0 aid=2)

==> /var/log/daemon.log <==
Mar 31 14:39:43 gnu wpa_supplicant[719]: dbus:
wpa_dbus_property_changed: no property SessionLength in object
/fi/w1/wpa_supplicant1/Interfaces/0
Mar 31 14:39:43 gnu wpa_supplicant[719]: wlp3s0: Associated with
00:1a:8c:c7:5f:7a
Mar 31 14:39:43 gnu wpa_supplicant[719]: wlp3s0: WPA: Key negotiation
completed with 00:1a:8c:c7:5f:7a [PTK=CCMP GTK=CCMP]
Mar 31 14:39:43 gnu wpa_supplicant[719]: dbus:
wpa_dbus_property_changed: no property RoamTime in object
/fi/w1/wpa_supplicant1/Interfaces/0
Mar 31 14:39:43 gnu wpa_supplicant[719]: dbus:
wpa_dbus_property_changed: no property RoamComplete in object
/fi/w1/wpa_supplicant1/Interfaces/0
Mar 31 14:39:43 gnu wpa_supplicant[719]: wlp3s0: CTRL-EVENT-CONNECTED -
Connection to 00:1a:8c:c7:5f:7a completed [id=0 id_str=]

==> /var/log/kern.log <==
Mar 31 14:39:43 gnu kernel: [ 2577.865073] wlp3s0: associated
Mar 31 14:39:43 gnu kernel: [ 2577.865206] ath: EEPROM regdomain: 0x8114
Mar 31 14:39:43 gnu kernel: [ 2577.865207] ath: EEPROM indicates we
should expect a country code
Mar 31 14:39:43 gnu kernel: [ 2577.865208] ath: doing EEPROM
country->regdmn map search
Mar 31 14:39:43 gnu kernel: [ 2577.865209] ath: country maps to regdmn
code: 0x37
Mar 31 14:39:43 gnu kernel: [ 2577.865210] ath: Country alpha2 being
used: DE
Mar 31 14:39:43 gnu kernel: [ 2577.865211] ath: Regpair used: 0x37
Mar 31 14:39:43 gnu kernel: [ 2577.865212] ath: regdomain 0x8114
dynamically updated by country element

==> /var/log/daemon.log <==
Mar 31 14:39:43 gnu wpa_supplicant[719]: wlp3s0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar 31 14:39:43 gnu wpa_supplicant[719]: wlp3s0:
CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=DE
Mar 31 14:39:43 gnu NetworkManager[708]:   [1585658383.6180]
device (wlp3s0): supplicant interface state: associating -> completed
Mar 31 14:39:43 gnu NetworkManager[708]:   [1585658383.6186]
device (p2p-dev-wlp3s0): supplicant management interface state:
associating -> completed
Mar 31 14:39:43 gnu wpa_supplicant[719]: wlp3s0:
CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-70 noise=-98 txrate=6000


It only happens with wpa2 enterprise wifi, wpa2 personal is stable.

I also see, that it may happen if the adapter changes the association to
another access point (here are multiple access points for the same network).

Before:

wlp3s0: flags=4163  mtu 1500
    inet 192.168.222.119  netmask 255.255.255.0  broadcast
192.168.222.255
    inet6 fe80::78e1:65f9:5060:d27d  prefixlen 64  scopeid 0x20
    inet6 XX  prefixlen 128  scopeid 0x0
    ether e8:6f:38:92:ea:f1  txqueuelen 1000  (Ethernet)
    RX packets 8144  bytes 1167968 (1.1 MiB)
    RX errors 0  dropped 501  overruns 0  frame 0
    TX packets 2840  bytes 451973 (441.3 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp3s0    IEEE 802.11  ESSID:"LEO-WLAN-5G" 
  Mode:Managed  Frequency:5.18 GHz  Access Point:
00:1A:8C:C7:63:A9  
  Bit Rate=6 Mb/s   Tx-Power=30 dBm  
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:on
  Link Quality=37/70  Signal level=-73 dBm 
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:110   Missed beacon:0



After:

wlp3s0: flags=4163  mtu 1500
    inet 192.168.222.119  netmask 255.255.255.0  broadcast
192.168.222.255
    inet6 fe80::78e1:65f9:5060:d27d  prefixlen 64  scopeid 0x20
    inet6 X  prefixlen 128  scopeid
0x0
    ether e8:6f:38:92:ea:f1  txqueuelen 1000  (Ethernet)
    RX packets 15139  bytes 2149327 (2.0 MiB)
    RX errors 0  dropped 836  overruns 0  frame 0
    TX packets 6116  bytes 920251 (898.6 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp3s0    IEEE 802.11  ESSID:"LEO-WLAN-5G" 
  Mode:Managed  Frequency:5.18 GHz  Access Point:
00:1A:8C:C7:5F:7A  
  Bit Rate=6 Mb/s   Tx-Power=23 dBm  
  Retry short limit:7   RTS thr:off   Fragment thr:off
  Encryption key:off
  Power Management:on
  Link Quality=38/70  Signal level=-72 dBm 
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:52  Invalid misc:0   Missed beacon:0

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#950199: libguichan_allegro-0.8.1.so: needs to link with -lguichan

[Patrick Matthäi]

tag #950199 + help
thanks

Am 06.03.2020 um 11:51 schrieb Paul Wise:
> On Fri, 2020-03-06 at 11:30 +0100, Patrick Matthäi wrote:
>
>> same then :/
> Looking at libguichan-dev there are symlinks from the unversioned name
> to the versioned one so -lguichan should be the right option.
>
> Probably the next step is to strace the g++ command you mentioned and
> find out where it is trying to load -lguichan from and not finding it.
>
> BTW, this is an upstream issue if you'd prefer them to handle it.
>
guichan isn't developed anymore. Maybe someone with more autofoo magic
knowhow could provide a patch :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#950199: libguichan_allegro-0.8.1.so: needs to link with -lguichan

[Patrick Matthäi]

Am 06.03.2020 um 11:15 schrieb Paul Wise:
> On Fri, 2020-03-06 at 10:18 +0100, Patrick Matthäi wrote:
>
>> Ok. That is just my problem when I add -lguichan:
>> ...
>> /usr/bin/ld: cannot find -lguichan
> Looks like libguichan also includes the version in the soname, so you
> probably need -lguichan-0.8.1 instead.
>

same then :/

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#950199: libguichan_allegro-0.8.1.so: needs to link with -lguichan

[Patrick Matthäi]

Am 06.03.2020 um 10:09 schrieb Paul Wise:
> On Fri, 2020-03-06 at 09:59 +0100, Patrick Matthäi wrote:
>
>> Would it be enough to add a dependency from guichan-allegro to guichan?
>> The problem is if I add the library dependency, ld cant find the path,
>> since it is all in the build directory.
> I'm no expert and assuming you mean a package dependency rather than
> library dependency but I don't think so since an application linking
> guichan-allegro but not guichan would not get the guichan symbols
> loaded so guichan-allegro would not be able to use guichan symbols,
> even though both libraries would be installed on the system.
>
Ok. That is just my problem when I add -lguichan:

/bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O2
-fdebug-prefix-map=/build/guichan-0.8.2=. -fstack-protector-strong
-Wformat
-Werror=forma   
   
t-security -Wall -Wno-unused -DGUICHAN_BUILD -no-undefined -release
0.8.1 -version-info 2:0:1 -lalleg -lguichan -Wl,-z,relro -Wl,-z,now -o
libguichan_ 
 
allegro.la -rpath /usr/lib/x86_64-linux-gnu allegro.lo allegrofont.lo
allegrographics.lo allegroimage.lo allegroimageloader.lo allegroinput.lo
libtool: link: g++  -fPIC -DPIC -shared -nostdlib
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/9/crtbeginS.o  .libs/allegro.o
.libs/allegrofont.o .libs/allegrographics.o .libs/allegroimage.o
.libs/allegroimageloader.o .libs/allegroinput.o   -lalleg -lguichan
-L/usr/lib/gcc/x86_64-linux-gnu/9
-L/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/9/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/9/../../.. -lstdc++
-lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/9/crtendS.o
/usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/crtn.o  -g -O2
-fstack-protector-strong -Wl,-z -Wl,relro -Wl,-z -Wl,now   -Wl,-soname
-Wl,libguichan_allegro-0.8.1.so.1 -o .libs/libguichan_allegro-0.8.1.so.1.1.0
/usr/bin/ld: cannot find -lguichan
collect2: error: ld returned 1 exit status

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#950199: libguichan_allegro-0.8.1.so: needs to link with -lguichan

[Patrick Matthäi]

Hi

Am 30.01.2020 um 03:16 schrieb Paul Wise:
> Package: libguichan-allegro-0.8.1-1v5
> Version: 0.8.2-19
> Severity: normal
> File: /usr/lib/x86_64-linux-gnu/libguichan_allegro-0.8.1.so.1.1.0
> User: debian...@lists.debian.org
> Usertags: undefined-symbol adequate
>
> libguichan_allegro-0.8.1.so needs to link with -lguichan, see the
> output of adequate, symtree and objdump below. I detected this on amd64
> but the Debian build log scanner also detected dpkg-buildpackage
> complaining about it on most architectures, see the w3m/getbuildlog
> output below. I filed this bug at severity minor since I'm not sure
> if there are any programs using the libguichan_allegro-0.8.1.so lib and
> if they already use the libguichan-0.8.1.so symbols and link
> with the -lguichan-0.8.1.so.1.1.0 flag or not.

Would it be enough to add a dependency from guichan-allegro to guichan?
The problem is if I add the library dependency, ld cant find the path,
since it is all in the build directory.


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#950571: znc: ZNC is unable to connect to IRC with default oidentd configuration

[Patrick Matthäi]

Hi,

Am 13.02.2020 um 13:00 schrieb Richard:
> Sorry, this ended up in my spam folder. The following configuration would 
> work:
>
> user "_znc" {
> default {
> force reply "znc"
> }
> }
>
> This is the one I actually use with the identfile module to have the
> ident show as the actual user rather than "znc", but it probably
> should not be default:
>
> user "_znc" {
> default {
> allow spoof
> allow spoof_all
> }
> }
>
> I don't know what's the best way to fix this, as there doesn't seem to
> be an oidentd.d folder that would make it easier to add additional
> configuration, rather than modifying the main config file, but I
> believe the default configuration with oidentd should not prevent ZNC
> from connecting to IRC, even though in my case I knew what to do.
>
> Maybe patch oidentd to strip the leading underscore by default? I
> don't know if any other services making use of ident accept a leading
> underscore, if so it is possible (though probably not very likely)
> that such a change could break existing setups.
>
> On Fri, Feb 7, 2020 at 8:31 PM Patrick Matthäi  wrote:
>>
>> Am 03.02.2020 um 17:21 schrieb Richard:
>>> Package: znc
>>> Version: 1.7.5-1~bpo10+1
>>> Severity: important
>>>
>>> Dear Maintainer,
>>>
>>> The ZNC package now ships with a system user called `_znc`, rather than
>>> `znc`. This is causes an issue when oidentd is installed and the default
>>> configuration is not overridden. Most IRC networks will treat `_znc` as
>>> an invalid username, and refuse connection. For example, freenode:
>>>
>>> 17:16:59 <*status> Error from server: Closing Link: cadoth.net (Invalid 
>>> username [_znc])
>>>
>>>
>> Hi,
>>
>> I don't know if it is such a good idea (and Debian rules confirm) to
>> provide a default oidentd config (also you are free to use other identd
>> services?). So my first idea would be to provide a working oidentd
>> config as example file. The other pro would be, that the admin of the
>> system has to know, what he is doing :-)
>>
>> --
>>

I would suggest the following solution.
@Mattia: Do you also aggre with it?


Index: debian/README.Debian
===
--- debian/README.Debian    (Revision 9327)
+++ debian/README.Debian    (Arbeitskopie)
@@ -26,3 +26,17 @@
    # systemctl enable znc

 Now znc will run as a system daemon.
+
+=== oidentd configuration ===
+
+Especially if you use the systemd service, you are not able to connect
to many
+IRC networks, because you will use the default username (_znc), which is
+invalid.
+You can configure oidentd to allow identity spoofing or to reply with
"znc" as
+username. You will find an example here:
+   /usr/share/doc/znc/examples/oidentd.conf
+You have to copy it to the home directory of the znc user:
+   /var/lib/znc/.oidentd.conf
+
+You will find more information and configuration examples here:
+   https://wiki.znc.in/Identfile
Index: debian/changelog
===
--- debian/changelog    (Revision 9327)
+++ debian/changelog    (Arbeitskopie)
@@ -1,3 +1,10 @@
+znc (1.7.5-4) UNRELEASED; urgency=medium
+
+  * Add oidentd configuration example and explain it in README.Debian.
+    Closes: #950571
+
+ -- Patrick Matthäi   Tue, 03 Mar 2020 11:15:32 +0100
+
 znc (1.7.5-3) unstable; urgency=medium

   * Build-depend on the unversioned swig.  Closes: #952602
Index: debian/oidentd.conf
===
--- debian/oidentd.conf (nicht existent)
+++ debian/oidentd.conf (Arbeitskopie)
@@ -0,0 +1,5 @@
+user "_znc" {
+   default {
+   force reply "znc"
+   }
+}
Index: debian/znc.examples
===
--- debian/znc.examples (nicht existent)
+++ debian/znc.examples (Arbeitskopie)
@@ -0,0 +1 @@
+debian/oidentd.conf

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#950571: znc: ZNC is unable to connect to IRC with default oidentd configuration

[Patrick Matthäi]

Am 03.02.2020 um 17:21 schrieb Richard:
> Package: znc
> Version: 1.7.5-1~bpo10+1
> Severity: important
>
> Dear Maintainer,
>
> The ZNC package now ships with a system user called `_znc`, rather than
> `znc`. This is causes an issue when oidentd is installed and the default
> configuration is not overridden. Most IRC networks will treat `_znc` as
> an invalid username, and refuse connection. For example, freenode:
>
> 17:16:59 <*status> Error from server: Closing Link: cadoth.net (Invalid 
> username [_znc])
>
>
Hi,

I don't know if it is such a good idea (and Debian rules confirm) to
provide a default oidentd config (also you are free to use other identd
services?). So my first idea would be to provide a working oidentd
config as example file. The other pro would be, that the admin of the
system has to know, what he is doing :-)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#950302: libpam-geoip_1.1-4_amd64.deb does not work

[Patrick Matthäi]

tag #950302 + help
thanks

Am 01.02.20 um 08:08 schrieb Joerg Dorchain:
>> Hum, looks like there are missing links:
>>
>> @login:~/build$ ldd 4/lib/x86_64-linux-gnu/security/pam_geoip.so
>>     linux-vdso.so.1 (0x7ffd915d7000)
>>     libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0
>> (0x7f9fcd75b000)
>>     libGeoIP.so.1 => /usr/lib/x86_64-linux-gnu/libGeoIP.so.1
>> (0x7f9fcd526000)
>>     libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9fcd3a3000)
>>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9fcd1e2000)
>>     libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1
>> (0x7f9fcd1b7000)
>>     libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9fcd1b2000)
>>     /lib64/ld-linux-x86-64.so.2 (0x7f9fcd97f000)
>>     libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0
>> (0x7f9fcd1a8000)
>>
>> @login:~/build$ ldd 5/lib/x86_64-linux-gnu/security/pam_geoip.so
>>     linux-vdso.so.1 (0x7ffc74de5000)
>>     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f94a11c4000)
>>     /lib64/ld-linux-x86-64.so.2 (0x7f94a1399000)
> Indeed. Did the LDFLAGS change between the versions?
>
I have checked it, nothing changed. pam-geoip adds the libs on this way:


cc -Wall -lpam -lGeoIP -lm -shared -o pam_geoip.so pam_geoip.o parse.o
args.o check.o
...
cc -lpam -lGeoIP -lm -shared  check.o   -o check

If I rebuild the -4 source on testing/unstable again the flags are also
missing. So it has nothing to do with the changes between -4 and -5 but
on which environment it is built :/

Bug#950302: libpam-geoip_1.1-4_amd64.deb does not work

[Patrick Matthäi]

Am 31.01.2020 um 08:25 schrieb Joerg Dorchain:
> Package: libpam-geoip
> Version: 1.1-5
>
> Hello,
>
> since the update to version 1.1-5 of libpam-geoip I get error in the log and
> denied services.
>
> authlog contains (for dovecot):
>
> Jan 31 07:53:31 Redstar auth worker: PASSV: PAM unable to 
> dlopen(pam_geoip.so): /lib/security/pam_geoip.so: cannot open shared object 
> file: No such file or directory
> Jan 31 07:53:31 Redstar auth worker: PASSV: PAM unable to 
> dlopen(pam_geoip.so): /lib/security/pam_geoip.so: cannot open shared object 
> file: No such file or directory
> Jan 31 07:53:31 Redstar auth worker: PASSV: PAM adding faulty module: 
> pam_geoip.so
> Jan 31 07:53:31 Redstar auth worker: PASSV: PAM adding faulty module: 
> pam_geoip.so
Hum, looks like there are missing links:

@login:~/build$ ldd 4/lib/x86_64-linux-gnu/security/pam_geoip.so
    linux-vdso.so.1 (0x7ffd915d7000)
    libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0
(0x7f9fcd75b000)
    libGeoIP.so.1 => /usr/lib/x86_64-linux-gnu/libGeoIP.so.1
(0x7f9fcd526000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f9fcd3a3000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f9fcd1e2000)
    libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1
(0x7f9fcd1b7000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f9fcd1b2000)
    /lib64/ld-linux-x86-64.so.2 (0x7f9fcd97f000)
    libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0
(0x7f9fcd1a8000)

@login:~/build$ ldd 5/lib/x86_64-linux-gnu/security/pam_geoip.so
    linux-vdso.so.1 (0x7ffc74de5000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f94a11c4000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f94a1399000)


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#950016: RFP: rust-pnet -- libpnet provides a cross-platform API for low level networking using Rust

[Patrick Matthäi]

Package: wnpp
Severity: wishlist

* Package name: rust-pnet
  Version : 0.25.0
  Upstream Author : Robert Clipsham 
* URL : https://github.com/libpnet/libpnet
* License : MIT/Apache-2.0
  Programming Lang: Rust
  Description : libpnet provides a cross-platform API for low level 
networking using Rust

Bug#950014: RFP: rust-trust-dns-resolver -- library which implements the DNS resolver using the Trust-DNS Proto library

[Patrick Matthäi]

Package: wnpp
Severity: wishlist

* Package name: rust-trust-dns-resolver
  Version : 0.19.2
  Upstream Author : Benjamin Fry 
* URL : https://crates.io/crates/trust-dns-resolver
* License : MIT/Apache-2.0
  Programming Lang: Rust
  Description : library which implements the DNS resolver using the 
Trust-DNS Proto library

Bug#950013: RFP: rust-tokio-sync -- rust synchronization utilities

[Patrick Matthäi]

Package: wnpp
Severity: wishlist

* Package name: rust-tokio-sync
  Version : 0.1.7
  Upstream Author : Carl Lerche 
* URL : https://crates.io/crates/tokio-sync
* License : MIT
  Programming Lang: Rust
  Description : rust synchronization utilities

Maybe this is covered about the tokio+asnyc package? For bandwhich I explicit
need tokio+sync.

Bug#950012: RFP: rust-procfs -- Rust library for reading the Linux procfs filesystem

[Patrick Matthäi]

Package: wnpp
Severity: wishlist

* Package name: rust-procfs
  Version : 0.7.7
  Upstream Author : Andrew Chin 
* URL : https://github.com/eminence/procfs
* License : MIT OR Apache-2.0
  Programming Lang: Rust
  Description : Rust library for reading the Linux procfs filesystem

Bug#950011: RFP: rust-async-trait -- rust Async trait methods

[Patrick Matthäi]

Package: wnpp
Severity: wishlist

* Package name: rust-async-trait
  Version : 0.1.22
  Upstream Author : David Tolnay 
* URL : https://github.com/dtolnay/async-trait
* License : MIT OR Apache-2.0
  Programming Lang: Rust
  Description : rust Async trait methods

Bug#949695: thunderbird does not start anymore

[Patrick Matthäi]

Source: thunderbird
Version: 1:68.4.1-1+b1
Severity: serious

Hey,

one of the last days testing and or unstable updates let thunderbird stop 
starting.
I just get:

$ thunderbird
ExceptionHandler::GenerateDump cloned child 3482
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
me@gnu:~$ Exception ignored in: <_io.TextIOWrapper name='' mode='w' 
encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

Also with a new profile, also with the version from testing and unstable. So I 
think some dependecie
crashes thunderbird

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (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

Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL

[Patrick Matthäi]

Am 29.12.2019 um 13:24 schrieb John Paul Adrian Glaubitz:
> On 12/29/19 1:11 PM, John Paul Adrian Glaubitz wrote:
>> I think it's more related to recent changes in libglvnd, see:
>>
>>> https://packages.qa.debian.org/libg/libglvnd/news/20191220T191934Z.html
>> I'll try a give-back on one of the buildds.
> Yep, that helped. I have given back the package on all architectures now:
>
>> https://buildd.debian.org/status/package.php?p=mlt
> Adrian

Thanks for your work!

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL

[Patrick Matthäi]

Am 29.12.2019 um 10:51 schrieb John Paul Adrian Glaubitz:
> Hi!
>
> On 12/29/19 10:36 AM, Patrick Matthäi wrote:
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [Makefile:61: ../libmltopengl.so] Error 1
>>> make[3]: Leaving directory '/<>/src/modules/opengl'
>> Yes, I already asked for help here:
>> https://lists.debian.org/debian-arm/2019/12/msg00017.html
> Did you try adding libgl1-dev to Build-Depends in debian/control?
>
> It pretty much looks like the development files for OpenGL are missing
> and the linker is complaining it can't find libGL to link against.


I think this just happens because of the added -latomic flag. See the
build logs and the changelog from -1 to -3


>
> Adrian
>

Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL

[Patrick Matthäi]

Hi

Am 29.12.2019 um 01:58 schrieb Lisandro Damián Nicanor Pérez Meyer:
> Source: mlt
> Version: 6.18.0-3
> Severity: serious
> Justification: FTBFS on all archs
>
> Hi! Your package failed to build form source on all archs:
>
> 
>
> The error seems to be:
>
> g++ -shared -o ../libmltopengl.so factory.o consumer_xgl.o 
> filter_glsl_manager.o filter_movit_blur.o filter_movit_convert.o 
> filter_movit_crop.o filter_movit_deconvolution_sharpen.o 
> filter_movit_diffusion.o filter_movit_flip.o filter_movit_glow.o 
> filter_movit_lift_gamma_gain.o filter_movit_mirror.o filter_movit_opacity.o 
> filter_movit_rect.o filter_movit_resample.o filter_movit_resize.o 
> filter_movit_saturation.o filter_movit_vignette.o 
> filter_movit_white_balance.o mlt_movit_input.o transition_movit_luma.o 
> transition_movit_mix.o transition_movit_overlay.o -L../../framework -lmlt -lm 
> -Wl,-z,relro -Wl,-z,now -Wl,--no-undefined -Wl,--as-needed -Wl,--no-undefined 
> -Wl,--as-needed -Wl,--no-undefined -Wl,--as-needed -L../../mlt++ -lmlt++ 
> -lmovit -lepoxy -lpthread -lGL -lX11
> /usr/bin/ld: cannot find -lGL
> collect2: error: ld returned 1 exit status
> make[3]: *** [Makefile:61: ../libmltopengl.so] Error 1
> make[3]: Leaving directory '/<>/src/modules/opengl'

Yes, I already asked for help here:
https://lists.debian.org/debian-arm/2019/12/msg00017.html

Bug#947678: Processed: Tag

[Patrick Matthäi]

tag 947678 + help
thanks

Am 29.12.2019 um 02:18 schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
>
>> tag 947678 ftbfs
> Bug #947678 [src:mlt] FTBFS: /usr/bin/ld: cannot find -lGL
> Added tag(s) ftbfs.
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.

Bug#945251: otrs2: CVE-2019-18179 CVE-2019-18180

[Patrick Matthäi]

block #945251 by #945004
thanks

Am 21.11.2019 um 22:44 schrieb Salvatore Bonaccorso:
> Source: otrs2
> Version: 6.0.23-2
> Severity: grave
> Tags: security upstream
> Justification: user security hole
>
> Hi,
>
> The following vulnerabilities were published for otrs2
>
> CVE-2019-18179[0] and CVE-2019-18180[1].
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2019-18179
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18179
> 
> https://community.otrs.com/security-advisory-2019-14-security-update-for-otrs-framework/
> [1] https://security-tracker.debian.org/tracker/CVE-2019-18180
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18180
> 
> https://community.otrs.com/security-advisory-2019-15-security-update-for-otrs-framework/
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore

Hi,

current otrs releases require an additional module, where I filled a RFP
for.

You are free to do new uploads (upstream releases, nmu etc), since I am
on vac now

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#945004: RFP: libcpan-audit-perl -- Audit CPAN distributions for known vulnerabilities

[Patrick Matthäi]

Package: wnpp
Severity: wishlist

* Package name: libcpan-audit-perl
  Version : 0.15
  Upstream Author : Viacheslav Tykhanovskyi 
* URL : https://metacpan.org/pod/CPAN::Audit
* License : Perl
  Programming Lang: Perl
  Description : Audit CPAN distributions for known vulnerabilities

I require this package as a dependency for otrs2.

Bug#940581: Unrecognized country Kosovo

[Patrick Matthäi]

Am 17.09.2019 um 17:44 schrieb Pat Suwalski:
> On 2019-09-17 11:00 a.m., Patrick Matthäi wrote:
>> Could you test the patch below? It should restore the behaviour for
>> those IPs. then they are (again) listed as "serbia":
>
> That patch did not help. I looked into it further, and the error is
> triggered on the other "Unrecognized country code" circa line 1100.
>
> This very similar patch makes it work:
>
> --- geoip-csv-to-dat.cpp.orig    2019-09-17 07:31:42.0 -0400
> +++ geoip-csv-to-dat.cpp    2019-09-17 11:34:59.180224941 -0400
> @@ -1103,6 +1109,9 @@
>  if (csv_fields[CSV_FIELD_COUNTRY_CODE] == "AN") {
>  csv_fields[CSV_FIELD_COUNTRY_CODE] = "CW";
>  }
> +    else if (csv_fields[CSV_FIELD_COUNTRY_CODE] == "XK") {
> +    csv_fields[CSV_FIELD_COUNTRY_CODE] = "RS";
> +    }
>
>  const int countryid =
> GeoIP_id_by_code(csv_fields[CSV_FIELD_COUNTRY_CODE].c_str());
>  if (countryid == 0) {
>
>
> Note, the other patch circa line 873 is not needed. So, perhaps there
> is some nicer solution to fix this method, but the special case does
> work.

Thanks for testing, I have adopted your patch. I didnt had the time to
test it yesterday, but hmm for what I have got the code on the other
lines... ;-)


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#940591: python-mlt: mlt.py and _mlt.so installed in wrong location(/usr/lib/dist-packages/)

[Patrick Matthäi]

Am 17.09.2019 um 16:58 schrieb Jan Gerber:
> Package: python-mlt
> Version: 6.16.0-4
> Severity: important
>
> Dear Maintainer,
>
> mlt.py and _mlt.so are installed in the wrong location 
> (/usr/lib/dist-packages/)
> instead they must be installed in /usr/lib/python3/dist-packages/
> right now the package is not usable
>
> This happens because pyversions (for python2) is still used in
> debian/rules:
>
> PYTHON_DIR := usr/lib/$(shell pyversions -d)/dist-packages
>
> with python3 this should just be:
>
> PYTHON_DIR := usr/lib/python3/dist-packages

That is already fixed: https://ftp-master.debian.org/new/mlt_6.16.0-5.html

The fail was, that the packaging didn't died...
I replaced pyversions with py3versions


>
>
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages python-mlt depends on:
> ii  libc6 2.29-1
> ii  libgcc1   1:9.2.1-7
> ii  libmlt++3 6.16.0-4
> ii  libmlt6   6.16.0-4
> ii  libpython3.7  3.7.4-4
> ii  libstdc++69.2.1-7
>
> python-mlt recommends no packages.
>
> python-mlt suggests no packages.
>
> -- no debconf information

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#940581: Unrecognized country Kosovo

[Patrick Matthäi]

Am 17.09.2019 um 16:40 schrieb Pat Suwalski:
> Package: geoip-bin
> Version: 1.6.12-4
>
> I was trying out the fix for another issue, generating a fresh
> geoip-database package using the latest version of the tools (and lib
> and -dev).
sick, just uploaded a new version..
>
> It fails on interpreting the new (unofficial?) XK country code for
> Kosovo:
>
> # Building geoip v4 country database.
> /usr/lib/geoip/geoip-generator -v -4 \
> --info="$(date -u +'GEO-106FREE %Y%m%d Build' -d 'Tue Sep 17
> 10:14:06 EDT 2019')" \
> -o /tmp/geoip-database-20190917/tmp/GeoIP.dat GeoIPCountryWhois.csv
> /usr/lib/geoip/geoip-generator: Reading CSV and building the trie
> /usr/lib/geoip/geoip-generator:GeoIPCountryWhois.csv:30816:
> Unrecognized country code: XK
> make[1]: *** [debian/rules:16: override_dh_install] Error 65
> make[1]: Leaving directory '/tmp/geoip-database-20190917'
> make: *** [debian/rules:8: binary] Error 2
>
> This seems odd to me, as the "Country-Locations" files do have the entry:
>
> 831053,en,EU,Europe,XK,Kosovo,0
>
> /usr/share/geoip/countryInfo.txt from geoip-bin also contains the XK
> entry.

This is only for the v2 => v1 conversion

>
> I assume geoip-csv-to-dat.cpp uses some other source for the country
> data that does not include it.
Yes, the geoip API itself
>
> grepping out the handful of "831053" lines from
> GeoLite2-Country-Blocks-IPv4.csv allows the package to build.

Could you test the patch below? It should restore the behaviour for
those IPs. then they are (again) listed as "serbia":


Index: src/geoip-csv-to-dat.cpp
===
--- src/geoip-csv-to-dat.cpp    (Revision 8838)
+++ src/geoip-csv-to-dat.cpp    (Arbeitskopie)
@@ -873,11 +873,18 @@

    // Country ID
    int country_id;
-   if (info[1] != "AN")
+
+   if (info[1] == "AN") {
+   country_id = GeoIP_id_by_code("CW");
+   }
+   else if (info[1] == "XK") {
+   country_id = GeoIP_id_by_code("RS");
+   }
+   else {
    country_id = GeoIP_id_by_code(info[1].c_str());
-   else
-   country_id = GeoIP_id_by_code("CW");
+   }

+
    if (country_id == 0) {
        error(EX_DATAERR, 1, dat_file_name.c_str(),
input_line_number,
  "Unrecognized country code: %s", info[1].c_str());

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#934147: geoip-database: Please ship GeoLite2 databases in MMDB format

[Patrick Matthäi]

Am 29.08.2019 um 12:09 schrieb Faidon Liambotis:
> On Wed, Aug 28, 2019 at 03:05:07PM +0200, Patrick Matthäi wrote:
>>> I'd be happy to help with that. Is the package in git somewhere? I don't
>>> see Vcs-* headers - perhaps you could import it to salsa?
>> I have got my own subversion system for my packages. If you want to
>> co-maintain geoip{-database} I could grant you access to it
> I haven't used Subversion for about a decade, and I'd rather not do
> collaborative development on someone's private server. Could we just
> move this into salsa?
>
>> For me building them from source was a requirement all the time, so that
>> the package could be in main and not non-free or contrib. So it would be
>> great if the MMDBs also could be in main.
> We don't have any reason to believe CSV is the source and MMDB is not,
> so I don't think this should affect inclusion in main.
>
> Faidon
So why not leaving src:geoip-database for the legacy databases and
introduce a new src package for the new formats?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#934147: geoip-database: Please ship GeoLite2 databases in MMDB format

[Patrick Matthäi]

Am 27.08.2019 um 16:30 schrieb Faidon Liambotis:
> Hi there,
>
> Thanks Colin for re-raising this! My intention for #885442 was to
> include the GeoLite2 *databases* (i.e. MMDB), rather than their data
> converted to the legacy GeoIP format. I'll avoid making a mess out of
> the BTS though, given we have this bug now :)
>
> On Thu, Aug 08, 2019 at 09:33:27AM +0200, Patrick Matthäi wrote:
>> Dont know. Patches would be welcome :)
> I'd be happy to help with that. Is the package in git somewhere? I don't
> see Vcs-* headers - perhaps you could import it to salsa?

I have got my own subversion system for my packages. If you want to
co-maintain geoip{-database} I could grant you access to it

>> Then also everything which is required to build the MMDB format has to
>> be in buster-backports and stretch-backports-sloppy. It was enough work
>> now to get everything to work again on both releases
> Could you elaborate a little bit more on why do you think that's a
> requirement? As I mentioned repeatedly in #885442, I don't share that
> view; I think we should be shipping MMDBs as-is and not building them
> out of CSVs. We have no reason to believe that MMDBs are generated out
> of CSVs and the most likely scenario is that the opposite holds true.
> Moreover, MMDB is openly and freely documented and with reader and
> writer implementations in all kinds of languages -- more than what we
> can say for most file formats out there.

For me building them from source was a requirement all the time, so that
the package could be in main and not non-free or contrib. So it would be
great if the MMDBs also could be in main.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#935441: libphysfs-dev: No pkg-config support for physfs

[Patrick Matthäi]

Hi Ryan,

Am 22.08.2019 um 18:14 schrieb Dennis Payne:
> Package: libphysfs-dev
> Version: 3.0.1-3.1
> Severity: normal
>
> Dear Maintainer,
>
> As developer on Fedora I've been using pkg-config to setup cflags and libs for
> many libraries. Fedora has support for physfs but it is not included on 
> Debian.
> The file from Fedora should work on Debian. For now I've stopped using pkg-
> config for physfs in my makefiles and just hard-coded the link flag.
Maybe this is something which should be included in upstream sources?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#934038: ASSERT: "mImg == qImg->constBits()" in file common.cpp, line 63

[Patrick Matthäi]

Am 06.08.2019 um 12:57 schrieb Arturo Borrero Gonzalez:
> Package: kdenlive
> Version: 19.04.3-2
> Severity: important
> Tags: upstream
>
> Dear maintainer,
>
> thanks for your great work with this package, really appreciated.
> I use it a lot.
>
> I've found this issue when using kdenlive, The program crash after a while:
>
> ASSERT: "mImg == qImg->constBits()" in file common.cpp, line 63
>
> I couldn't find a pattern about how to trigger this assert, but is mostly
> composing a video and just the basic usage of the timeline (using the space 
> bar
> to start/stop the timeline preview).
>
> Perhaps this is something that should be reported upstream.
>
Hi,

can you please test 19.08.0-1 in unstable again (just uploaded right now)?

If it still appears please also use gdb for more information

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#917222: znc: please provide a znc-plugin-$version that external plugins can depend on

[Patrick Matthäi]

Am 10.08.2019 um 12:12 schrieb Mattia Rizzolo:
> On Mon, Dec 24, 2018 at 08:44:25AM -0300, Felipe Sateler wrote:
>>>> Perhaps znc could Provide: znc-plugin-$somenumber, which could be used by
>>>> out-of-tree plugins? Adding the znc maintainers to the loop for their
>>> input
>>>
>>> That's being used successfully by some packages ...
>>>
>> I'm creating a new bug for tracking this (better) solution.
> ivodd proposed the other day on #-relase to instead have these type of
> plugins embedded in src:znc.
>
> I'm also extremely interested in this as, following on the shoes of
> znc-backlog, I've packaged znc-push.
>
> znc-backlog is a single 253 lines file, whereas znc-push is ~2000 lines.
> Both change very rarely, so I think it would be feasible to just put
> both of them within src:znc's debian/ and build them from there.  Then
> put them in separate binary packages, with the description explicitly
> saying they are contrib modules.
> I'll also be happy to help out with the maintenance of these parts if
> you'd like to, not to mention provide a full patch.
If it is not a problem for you to work with svn then I would be happy to
get some help :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#934590: libmlt-data: The package became bloated

[Patrick Matthäi]

2819 2019-07-23 11:39
./usr/share/mlt/lumas/square/luma22.pgm

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#931678: buster-pu: package qdirstat/1.5-1+deb10u1

[Patrick Matthäi]

Control: tags -1 - moreinfo

Am 09.07.2019 um 10:41 schrieb Patrick Matthäi:
> Control: tags -1 - moreinfo
>
> Am 09.07.2019 um 10:30 schrieb Adam D. Barratt:
>> Control: tags -1 + moreinfo
>>
>> On 2019-07-09 09:22, Patrick Matthäi wrote:
>>> upstream just fixed a bug in qdirstat, where user configured MIME
>>> categories
>>> are not saved properly, as described here:
>>> https://github.com/shundhammer/qdirstat/issues/109
>> This doesn't appear to be fixed in unstable yet, which is (as ever) a
>> prerequisite. Please let us know, and remove the moreinfo tag, once it
>> is.
>>
>> Regards,
>>
>> Adam
> Heh, you were too fast ;) I were just building other packages, just
> uploaded the new upstream version right now:
> qdirstat_1.5.90-1_amd64.changes
Oh forgot to CC the bug.. ;)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#934147: geoip-database: Please ship GeoLite2 databases in MMDB format

[Patrick Matthäi]

>> Also if I have to use the new sources now (since geoip v1 sources are
>> not available anymore) it does not mean that src:geoip-database
>> fullfils the MMDB format.
> I don't understand that.  Please could you rephrase?  As far as I can
> see you're already using the new sources.  Is the difficulty just in
> building the MMDB files from the CSV files?
Dont know. Patches would be welcome :)
Then also everything which is required to build the MMDB format has to
be in buster-backports and stretch-backports-sloppy. It was enough work
now to get everything to work again on both releases

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#934147: geoip-database: Please ship GeoLite2 databases in MMDB format

[Patrick Matthäi]

Am 07.08.2019 um 15:41 schrieb Colin Watson:
> Package: geoip-database
> Version: 20181108-1
> Severity: wishlist
>
> Hi,
>
> Thanks for fixing #885442.  I see that you did so by converting the new
> databases into the old format.  Presumably this was in order to maximise
> compatibility, and I don't object to that.  However, it has a few
> problems:
>
>  * Only the country-level databases are shipped.  Regarding the others
>that used to be in geoip-database-extra, in your changelog you said
>"the sources are dropped from the homepage", which I don't quite
>understand because there seem to be CSV files for all of City,
>Country, and ASN on https://dev.maxmind.com/geoip/geoip2/geolite2/
>(notwithstanding Faidon's comment that the MMDB files may in fact be
>the preferred form for modification anyway).  But it means that some
>users may be out of luck.
>
>  * We're stuck using old client code to query them.  Ideally I'd much
>prefer to be using versions of client libraries that are still
>maintained upstream, and that generally means using the ones that
>expect MMDB input.
>
>  * As I understand it, the old format requires shipping separate files
>for IPv4 and IPv6 (at least that's how they're shipped in
>geoip-database at the moment).  It would be much more convenient to
>just open a single database and get results for both IPv4 and IPv6
>addresses.
>
> Could you please ship the MMDB files as well?  I don't mind whether
> they're in different binary packages, although long-term I would expect
> most people to want to use the modern format.
>
> Thanks,

Geoip2 with the MMDB format is a different package. Also if I have to
use the new sources now (since geoip v1 sources are not available
anymore) it does not mean that src:geoip-database fullfils the MMDB format.

IMO someone should start a new source package and provide all the new
MMDB databases. I also had to drop now the city and asn edition here.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#914783: fixed in znc 1.7.4-2

[Patrick Matthäi]

Thanks, that was already fixed in my svn for the next upload:

* Add VERSION_EXTRA string again.
* Add cmake dependency to znc-dev package.

Am 16.07.2019 um 11:34 schrieb Gianfranco Costamagna:
> control: reopen -1
> control: notfixed -1
> control: severity -1 serious
> control: tags -1 patch
> control: affects -1 znc-backlog
>
>>* Switch to the cmake build system.
>>  Closes: #914783
> thanks for doing it, but due to a missing runtime dependency on cmake, now 
> reverse dependencies are FTBFS because of missing cmake
>
>
> The attached patch should fix the issue.
>
> thanks for considering it
>
> Gianfranco
>
> +znc (1.7.4-2.11) unstable; urgency=medium
> +
> +  * Add cmake dependency also as runtime dependency for reverse-dependencies 
> (Closes: #914783)
> +
> + -- Gianfranco Costamagna   Tue, 16 Jul 2019 
> 11:30:29 +0200
> +
>  znc (1.7.4-2) unstable; urgency=medium
>  
>* Switch to the cmake build system.
> diff -Nru znc-1.7.4/debian/control znc-1.7.4/debian/control
> --- znc-1.7.4/debian/control  2019-07-11 12:03:16.0 +
> +++ znc-1.7.4/debian/control  2019-07-16 09:30:28.0 +
> @@ -49,6 +49,7 @@
>  Architecture: any
>  Depends: ${misc:Depends},
>   ${python3:Depends},
> + cmake,
>   znc (>= ${binary:Version}),
>   libicu-dev,
>   libssl-dev,

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#931678: buster-pu: package qdirstat/1.5-1+deb10u1

[Patrick Matthäi]

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

Hello,

upstream just fixed a bug in qdirstat, where user configured MIME categories
are not saved properly, as described here:
https://github.com/shundhammer/qdirstat/issues/109

Upstream patch: 
https://github.com/shundhammer/qdirstat/commit/7ce3d1ebe51e55951c7b6d318dc8870b6f1eea77

I have prepared this patch:


diff -Naur '--exclude=.svn' tags/1.5-1/debian/changelog 
branches/buster/debian/changelog
--- tags/1.5-1/debian/changelog 2018-11-08 12:20:05.069481981 +0100
+++ branches/buster/debian/changelog2019-07-09 10:18:06.341381029 +0200
@@ -1,3 +1,10 @@
+qdirstat (1.5-1+deb10u1) UNRELEASED; urgency=medium
+
+  * Add upstream patch 01-mime-categories-save to fix a bug where user
+configured MIME categories are not saved.
+
+ -- Patrick Matthäi   Tue, 09 Jul 2019 10:16:47 +0200
+
 qdirstat (1.5-1) unstable; urgency=medium

   * New upstream release.
diff -Naur '--exclude=.svn' 
tags/1.5-1/debian/patches/01-mime-categories-save.diff 
branches/buster/debian/patches/01-mime-categories-save.diff
--- tags/1.5-1/debian/patches/01-mime-categories-save.diff  1970-01-01 
01:00:00.0 +0100
+++ branches/buster/debian/patches/01-mime-categories-save.diff 2019-07-09 
10:15:19.878253032 +0200
@@ -0,0 +1,419 @@
+From 7ce3d1ebe51e55951c7b6d318dc8870b6f1eea77 Mon Sep 17 00:00:00 2001
+From: Stefan Hundhammer 
+Date: Mon, 1 Jul 2019 17:08:19 +0200
+Subject: [PATCH] Turned MimeCategorizer into a singleton to properly save
+ config (GitHub issue #109)
+
+---
+ src/FileDetailsView.cpp| 11 ++
+ src/FileDetailsView.h  |  2 --
+ src/FileTypeStats.cpp  |  4 ++--
+ src/MainWindow.cpp |  8 ++-
+ src/MainWindow.h   |  2 --
+ src/MimeCategorizer.cpp| 23 +--
+ src/MimeCategorizer.h  | 40 --
+ src/MimeCategoryConfigPage.cpp |  4 ++--
+ src/MimeCategoryConfigPage.h   | 12 --
+ src/TreemapView.cpp| 18 +--
+ src/TreemapView.h  | 15 -
+ 11 files changed, 59 insertions(+), 80 deletions(-)
+
+diff --git a/src/FileDetailsView.cpp b/src/FileDetailsView.cpp
+index 0b8f60a..93788c4 100644
+--- a/src/FileDetailsView.cpp
 b/src/FileDetailsView.cpp
+@@ -23,8 +23,7 @@ FileDetailsView::FileDetailsView( QWidget * parent ):
+ QStackedWidget( parent ),
+ _ui( new Ui::FileDetailsView ),
+ _pkgUpdateTimer( new AdaptiveTimer( this ) ),
+-_labelLimit( 40 ),
+-_mimeCategorizer( 0 )
++_labelLimit( 40 )
+ {
+ CHECK_NEW( _ui );
+ CHECK_NEW( _pkgUpdateTimer );
+@@ -423,13 +422,7 @@ QString FileDetailsView::limitText( const QString & 
longText )
+
+ QString FileDetailsView::mimeCategory( FileInfo * file )
+ {
+-if ( ! _mimeCategorizer )
+-{
+-_mimeCategorizer = new MimeCategorizer( this );
+-CHECK_NEW( _mimeCategorizer );
+-}
+-
+-MimeCategory * category = _mimeCategorizer->category( file );
++MimeCategory * category = MimeCategorizer::instance()->category( file );
+
+ return category ? category->name() : "";
+ }
+diff --git a/src/FileDetailsView.h b/src/FileDetailsView.h
+index e36792c..f677b92 100644
+--- a/src/FileDetailsView.h
 b/src/FileDetailsView.h
+@@ -16,7 +16,6 @@
+
+ namespace QDirStat
+ {
+-class MimeCategorizer;
+ class AdaptiveTimer;
+
+ /**
+@@ -153,7 +152,6 @@ namespace QDirStat
+ Ui::FileDetailsView * _ui;
+ AdaptiveTimer *   _pkgUpdateTimer;
+ int   _labelLimit;
+-MimeCategorizer * _mimeCategorizer;
+
+ };  // class FileDetailsView
+ } // namespace QDirStat
+diff --git a/src/FileTypeStats.cpp b/src/FileTypeStats.cpp
+index d50821f..f453776 100644
+--- a/src/FileTypeStats.cpp
 b/src/FileTypeStats.cpp
+@@ -21,8 +21,8 @@ FileTypeStats::FileTypeStats( QObject  * parent ):
+ QObject( parent ),
+ _totalSize( 0LL )
+ {
+-_mimeCategorizer = new MimeCategorizer( this );
+-CHECK_NEW( _mimeCategorizer );
++_mimeCategorizer = MimeCategorizer::instance();
++CHECK_PTR( _mimeCategorizer );
+
+ _otherCategory = new MimeCategory( tr( "Other" ) );
+ CHECK_NEW( _otherCategory );
+diff --git a/src/MainWindow.cpp b/src/MainWindow.cpp
+index fdce914..b405565 100644
+--- a/src/MainWindow.cpp
 b/src/MainWindow.cpp
+@@ -103,10 +103,7 @@ MainWindow::MainWindow():
+ _ui->dirTreeView->setCleanupCollection( _cleanupCollection );
+ _ui->treemapView->setCleanupCollection( _cleanupCollection );
+
+-_mimeCategorizer = new MimeCategorizer();
+-CHECK_NEW( _mimeCategorizer );
+-
+-_ui->treemapView->setMimeCategorizer( _mimeCategorizer );
++_ui->breadcrumbNavigator->clear();
+
+ #ifdef Q_OS_MACX
+ // This makes the application to look like more "native" on macOS
+@@ -132,6 +129,7 @@ Ma

Bug#918709: Is there anything new?

[Patrick Matthäi]

Am 27.06.2019 um 09:12 schrieb Dennis Well:
> Hey,
>
> would it be possible to implement the GeoLite2 format into
> geoip-generator? Or fork it to geoip2-generator or something?


If someone provides patches to convert the format of the v4+v6 database
to the old format then I would maintain it. Using geoip2 generator etc
is no option.


>
> Am Montag, den 27.05.2019, 09:52 +0200 schrieb Patrick Matthäi:
>> Am 27.05.2019 um 09:25 schrieb Dennis Well:
>> Hey guys,
>> is there anything new on this bug? Is it possible to debug?
>> Cheers
>> Dennis
>> Hey,
>> geoip-generator from geoip-bin is only for the legacy v1 database
>> format, not for the GeoLite2 format. So they are incompatible. Sadly
>> Maxmind does not provide the geoip v1 csv exports on their homepage..

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#930523: unblock: znc/1.7.2-3

[Patrick Matthäi]

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

Please unblock package znc

It fixes a critical security bug. Fix is also accepted for stable + testing
by the security team.
diff:

diff -Naur '--exclude=.svn' 1.7.2-2/debian/changelog 1.7.2-3/debian/changelog
--- 1.7.2-2/debian/changelog2019-03-26 12:58:06.264919659 +0100
+++ 1.7.2-3/debian/changelog2019-06-14 13:06:35.239889318 +0200
@@ -1,3 +1,10 @@
+znc (1.7.2-3) unstable; urgency=high
+
+  * Add upstream patch CVE-2019-12816 to fix a remote code execution by
+elevating privileges as described in CVE-2019-12816.
+
+ -- Patrick Matthäi   Fri, 14 Jun 2019 11:14:11 +0200
+
 znc (1.7.2-2) unstable; urgency=high

   * Add upstream patch 01-CVE-2019-9917 to fix a crash on invalid encoding,
diff -Naur '--exclude=.svn' 1.7.2-2/debian/patches/02-CVE-2019-12816.diff 
1.7.2-3/debian/patches/02-CVE-2019-12816.diff
--- 1.7.2-2/debian/patches/02-CVE-2019-12816.diff   1970-01-01 
01:00:00.0 +0100
+++ 1.7.2-3/debian/patches/02-CVE-2019-12816.diff   2019-06-14 
13:06:35.251889255 +0200
@@ -0,0 +1,88 @@
+# Fix security issue which causes elevating privileges by existing remote
+# non-admin user, and remote code execution.
+
+diff -Naur znc-1.7.2.orig/include/znc/Modules.h znc-1.7.2/include/znc/Modules.h
+--- znc-1.7.2.orig/include/znc/Modules.h   2019-06-13 11:13:33.035495175 
+0200
 znc-1.7.2/include/znc/Modules.h2019-06-13 11:16:33.966506967 +0200
+@@ -1600,6 +1600,7 @@
+   private:
+ static ModHandle OpenModule(const CString& sModule, const CString& 
sModPath,
+ CModInfo& Info, CString& sRetMsg);
++static bool VerifyModuleName(const CString& sModule, CString& sRetMsg);
+
+   protected:
+ CUser* m_pUser;
+diff -Naur znc-1.7.2.orig/src/Modules.cpp znc-1.7.2/src/Modules.cpp
+--- znc-1.7.2.orig/src/Modules.cpp 2019-06-13 11:13:32.979495481 +0200
 znc-1.7.2/src/Modules.cpp  2019-06-13 11:16:33.970506945 +0200
+@@ -1624,11 +1624,30 @@
+ return nullptr;
+ }
+
++bool CModules::VerifyModuleName(const CString& sModule, CString& sRetMsg) {
++for (unsigned int a = 0; a < sModule.length(); a++) {
++if (((sModule[a] < '0') || (sModule[a] > '9')) &&
++((sModule[a] < 'a') || (sModule[a] > 'z')) &&
++((sModule[a] < 'A') || (sModule[a] > 'Z')) && (sModule[a] != 
'_')) {
++sRetMsg =
++t_f("Module names can only contain letters, numbers and "
++"underscores, [{1}] is invalid")(sModule);
++return false;
++}
++}
++
++return true;
++}
++
+ bool CModules::LoadModule(const CString& sModule, const CString& sArgs,
+   CModInfo::EModuleType eType, CUser* pUser,
+   CIRCNetwork* pNetwork, CString& sRetMsg) {
+ sRetMsg = "";
+
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return false;
++}
++
+ if (FindModule(sModule) != nullptr) {
+ sRetMsg = t_f("Module {1} already loaded.")(sModule);
+ return false;
+@@ -1781,6 +1800,10 @@
+
+ bool CModules::GetModInfo(CModInfo& ModInfo, const CString& sModule,
+   CString& sRetMsg) {
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return false;
++}
++
+ CString sModPath, sTmp;
+
+ bool bSuccess;
+@@ -1799,6 +1822,10 @@
+
+ bool CModules::GetModPathInfo(CModInfo& ModInfo, const CString& sModule,
+   const CString& sModPath, CString& sRetMsg) {
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return false;
++}
++
+ ModInfo.SetName(sModule);
+ ModInfo.SetPath(sModPath);
+
+@@ -1911,15 +1938,8 @@
+ // Some sane defaults in case anything errors out below
+ sRetMsg.clear();
+
+-for (unsigned int a = 0; a < sModule.length(); a++) {
+-if (((sModule[a] < '0') || (sModule[a] > '9')) &&
+-((sModule[a] < 'a') || (sModule[a] > 'z')) &&
+-((sModule[a] < 'A') || (sModule[a] > 'Z')) && (sModule[a] != 
'_')) {
+-sRetMsg =
+-t_f("Module names can only contain letters, numbers and "
+-"underscores, [{1}] is invalid")(sModule);
+-return nullptr;
+-}
++if (!VerifyModuleName(sModule, sRetMsg)) {
++return nullptr;
+ }
+
+ // The second argument to dlopen() has a long history. It seems clear
diff -Naur '--exclude=.svn' 1.7.2-2/debian/patches/series 
1.7.2-3/debian/patches/series
--- 1.7.2-2/debian/patches/series   2019-03-26 12:58:06.280919560 +0100
+++ 1.7.2-3/debian/patches/series   2019-06-14 13:06:35.251889255 +0200
@@ -1 +1,2 @@
 01-CVE-2019-9917.diff
+02-CVE-2019-12816.diff

Bug#918709: Is there anything new?

[Patrick Matthäi]

Am 27.05.2019 um 09:25 schrieb Dennis Well:
> Hey guys,
>
> is there anything new on this bug? Is it possible to debug?
>
> Cheers
> Dennis

Hey,

geoip-generator from geoip-bin is only for the legacy v1 database
format, not for the GeoLite2 format. So they are incompatible. Sadly
Maxmind does not provide the geoip v1 csv exports on their homepage..

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#928967: unblock: needrestart/3.4-4

[Patrick Matthäi]

Am 14.05.2019 um 19:45 schrieb Jonathan Wiltshire:
> Control: tag -1 moreinfo
>
> On Tue, May 14, 2019 at 11:25:57AM +0200, Patrick Matthäi wrote:
>> +needrestart (3.4-3~bpo9+1) stretch-backports; urgency=medium
>> +
>> +  * Rebuild for stretch-backports.
>> +
>> + -- Patrick Matthäi   Wed, 24 Apr 2019 10:04:02 +0200
>> +
> This changelog entry should not be present; 3.4-3~bpo9+1 is not an
> ancestor of 3.4-4.
>
> Thanks,

Wow. For me it is important to have the whole history present in the
changelog. That this is a blocker...

So just for this I have uploaded now 3.4-5 which is more funnier, since
now the 3.4-3~bpo9+1 changelog entry is mentioned twice:

 needrestart (3.4-5) unstable; urgency=medium
 .
   * Remove 3.4-3~bpo9+1 changelog entry.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#928967: unblock: needrestart/3.4-4

[Patrick Matthäi]

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

Please unblock package needrestart

It fixes an upstream bug which leads to a false positive, see #928225



diff -Naur '--exclude=.svn' 3.4-3/debian/changelog 3.4-4/debian/changelog
--- 3.4-3/debian/changelog  2019-04-18 11:17:08.756032831 +0200
+++ 3.4-4/debian/changelog  2019-05-09 11:26:38.505949290 +0200
@@ -1,3 +1,18 @@
+needrestart (3.4-4) unstable; urgency=medium
+
+  * Add upstream patch 05-strip-leading-zeroes to remove leading zero before
+testing in map_files.
+Closes: #928225
+  * Merge 3.4-3~bpo9+1 changelog.
+
+ -- Patrick Matthäi   Thu, 09 May 2019 11:18:46 +0200
+
+needrestart (3.4-3~bpo9+1) stretch-backports; urgency=medium
+
+  * Rebuild for stretch-backports.
+
+ -- Patrick Matthäi   Wed, 24 Apr 2019 10:04:02 +0200
+
 needrestart (3.4-3) unstable; urgency=medium

   * Add upstream patch 04-restore-cwd to restore the cwd when skipping
diff -Naur '--exclude=.svn' 3.4-3/debian/patches/05-strip-leading-zeroes.diff 
3.4-4/debian/patches/05-strip-leading-zeroes.diff
--- 3.4-3/debian/patches/05-strip-leading-zeroes.diff   1970-01-01 
01:00:00.0 +0100
+++ 3.4-4/debian/patches/05-strip-leading-zeroes.diff   2019-05-09 
11:26:38.541949067 +0200
@@ -0,0 +1,23 @@
+From 017c9a11d9a3961477ed79200b2bce8963483575 Mon Sep 17 00:00:00 2001
+From: Thomas Liske 
+Date: Fri, 3 May 2019 22:28:21 +0200
+Subject: [PATCH] [Core] Remove leading zero before testing in map_files
+ (Debian Bug#928225 by Alexander Galanin ).
+
+---
+ needrestart | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/needrestart b/needrestart
+index 2fc3379..ed18920 100755
+--- a/needrestart
 b/needrestart
+@@ -504,6 +504,8 @@ if(defined($opt_l)) {
+
+   # check for outdated lib mappings
+   unless($nrconf{skip_mapfiles} == 1) {
++  $maddr =~ s/^0+([^-])/$1/;
++  $maddr =~ s/-0+(.)/-$1/;
+   my @paths = ("/proc/$pid/map_files/$maddr", 
"/proc/$pid/root/$path");
+   my ($testp) = grep { -e $_; } @paths;
+   unless($testp) {
diff -Naur '--exclude=.svn' 3.4-3/debian/patches/series 
3.4-4/debian/patches/series
--- 3.4-3/debian/patches/series 2019-04-18 11:17:08.756032831 +0200
+++ 3.4-4/debian/patches/series 2019-05-09 11:26:38.517949215 +0200
@@ -2,3 +2,4 @@
 02-ignore-networking.diff
 03-typo-env-var.diff
 04-restore-cwd.diff
+05-strip-leading-zeroes.diff



unblock needrestart/3.4-4

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

Kernel: Linux 4.19.0-4-amd64 (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

Bug#928223: unblock / pre approval: otrs2/6.0.16-2

[Patrick Matthäi]

tags -1 - moreinfo
thanks

Am 09.05.2019 um 10:31 schrieb Holger Levsen:
> control: tags -1 moreinfo
>
> On Thu, May 09, 2019 at 10:06:50AM +0200, Patrick Matthäi wrote:
>> Am 08.05.2019 um 15:50 schrieb Holger Levsen:
>>> control: tags -1 - moreinfo
>> Means this I should upload it now to buster/testing?
> well, sorry, I have misread your last emails to this bug and thought you
> had already uploaded. But yes, you can now upload to buster and then you
> remove the moreinfo tag again so that the RT team knows to look at this
> bug again.
>
> sorry for the noise.

No problem, uploaded now :)


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#928223: unblock / pre approval: otrs2/6.0.16-2

[Patrick Matthäi]

Am 08.05.2019 um 15:50 schrieb Holger Levsen:
> control: tags -1 - moreinfo
> thanks
Means this I should upload it now to buster/testing?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#928223: unblock / pre approval: otrs2/6.0.16-2

[Patrick Matthäi]

Am 05.05.2019 um 21:55 schrieb pmatth...@debian.org:
> Thanks but I have to upload it to testing, because in unstable is
> already a new upstream release which was declined for migration
>
> Thanks but I have to upload it to testing, because in unstable is already a 
> new upstream release which was declined for migration
>
>
> Am 05.05.2019 14:35 schrieb Ivo De Decker :
>> Control: tags -1 confirmed moreinfo 
>>
>> Hi, 
>>
>> On Tue, Apr 30, 2019 at 09:55:58AM +0200, Patrick Matthäi wrote: 
>>> I would like to upload the attached diff to fix several security issues in 
>>> the 
>>> buster otrs2 version. 
>> Please go ahead and remove the moreinfo tag from this bug once the package 
>> is 
>> in unstable. 
>>
>> Thanks, 
>>
>> Ivo 
>>

Seems like my smartphone missformated the message a little bit. But now
I see that my message didn't arrived the BTS, but the mail log says it
was accepted?:

May  5 21:56:03 srv1 postfix/smtp[27139]: 9BB041001F9:
to=<928...@bugs.debian.org>,
relay=buxtehude.debian.org[209.87.16.39]:25, delay=3.3,
delays=0.4/0.03/2/0.79, dsn=2.0.0, status=sent (250 OK id=1hNNEx-00081f-JX)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#928223: unblock / pre approval: otrs2/6.0.16-2

[Patrick Matthäi]

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

Hi,

I would like to upload the attached diff to fix several security issues in the
buster otrs2 version.

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

Kernel: Linux 4.19.0-4-amd64 (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


buster.diff.gz
Description: application/gzip

Bug#926708: unblock: otrs2/6.0.17-1

[Patrick Matthäi]

Am 09.04.2019 um 18:51 schrieb Ivo De Decker:
> Hi,
>
> On 4/9/19 2:59 PM, Patrick Matthäi wrote:
>> Am 09.04.2019 um 14:46 schrieb Ivo De Decker:
>
>>> Being in non-free doesn't give you an exception to the freeze.
>> Sorry you are right, I totaly forget it..
>> It was an exception for fglrx in the past-past, but because it was also
>> closed source, so no fixes could be adapted.
>>
>> I will prepare a diff along with other security fixes (I think there
>> will be one in the next time) if they are out
>
> OK. Do you have an idea about the timeframe of this future release?
>
>
I will prepare an upload for tomorrow and ask for a pre approval. Should
I open a new bug then or use this?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#928007: ITP: rttr -- C++ Reflection Library

[Patrick Matthäi]

Package: wnpp
Severity: wishlist
Owner: Patrick Matthäi 

* Package name: rttr
  Version : 0.9.6
  Upstream Author : Axel Menzel 
* URL : https://www.rttr.org
* License : MIT
  Programming Lang: C++
  Description : C++ Reflection Library

I require it for kdenlive packaging. It is a new dependency.

RTTR is a C++ library which enables the programmer to use reflection in its
application. That means the program can introspect an object at runtime of
what kind of properties, methods or constructors it consist. This is
extremely useful when a tight but also high dynamic coupling between software
modules is required. The main use cases are for example serialisation, UI
creation, binding to arbitrary programming languages (JavaScript, Lua
etc.) and network communication.

Bug#927121: unblock: glusterfs/5.5-3

[Patrick Matthäi]

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

Please unblock package glusterfs

It adds one upstream patch - which is now in the 5.6 release - to fix this 
critical
bug: https://bugzilla.redhat.com/show_bug.cgi?id=1673058
See also: https://review.gluster.org/#/c/glusterfs/+/22404/


diff -Naur '--exclude=.svn' 5.5-2/debian/changelog 5.5-3/debian/changelog
--- 5.5-2/debian/changelog  2019-04-09 13:47:11.558039914 +0200
+++ 5.5-3/debian/changelog  2019-04-15 10:23:28.871148221 +0200
@@ -1,3 +1,10 @@
+glusterfs (5.5-3) unstable; urgency=medium
+
+  * Add upstream patch 05-client-rpc-payload-wire to fix the payload being sent
+on the wire.
+
+ -- Patrick Matthäi   Mon, 15 Apr 2019 10:07:38 +0200
+
 glusterfs (5.5-2) unstable; urgency=medium

   * Uploading to unstable.
diff -Naur '--exclude=.svn' 
5.5-2/debian/patches/05-client-rpc-payload-wire.diff 
5.5-3/debian/patches/05-client-rpc-payload-wire.diff
--- 5.5-2/debian/patches/05-client-rpc-payload-wire.diff1970-01-01 
01:00:00.0 +0100
+++ 5.5-3/debian/patches/05-client-rpc-payload-wire.diff2019-04-15 
10:23:28.943147770 +0200
@@ -0,0 +1,1619 @@
+commit 1fba86169b0850c3fcd02e56d0ddbba3efe9ae78
+Author: Poornima G 
+Date:   Sun Mar 24 09:40:50 2019 +0530
+
+client-rpc: Fix the payload being sent on the wire
+
+The fops allocate 3 kind of payload(buffer) in the client xlator:
+- fop payload, this is the buffer allocated by the write and put fop
+- rsphdr paylod, this is the buffer required by the reply cbk of
+  some fops like lookup, readdir.
+- rsp_paylod, this is the buffer required by the reply cbk of fops like
+  readv etc.
+
+Currently, in the lookup and readdir fop the rsphdr is sent as payload,
+hence the allocated rsphdr buffer is also sent on the wire, increasing
+the bandwidth consumption on the wire.
+
+With this patch, the issue is fixed.
+
+Fixes: bz#1673058
+Change-Id: Ie8158921f4db319e60ad5f52d851fa5c9d4a269b
+Signed-off-by: Poornima G 
+
+diff --git a/xlators/protocol/client/src/client-handshake.c 
b/xlators/protocol/client/src/client-handshake.c
+index ed9d0a5d9..e1334f9e3 100644
+--- a/xlators/protocol/client/src/client-handshake.c
 b/xlators/protocol/client/src/client-handshake.c
+@@ -34,7 +34,6 @@ typedef struct client_fd_lk_local {
+ clnt_fd_ctx_t *fdctx;
+ } clnt_fd_lk_local_t;
+
+-
+ int32_t
+ client3_getspec(call_frame_t *frame, xlator_t *this, void *data)
+ {
+@@ -201,8 +200,8 @@ clnt_release_reopen_fd(xlator_t *this, clnt_fd_ctx_t 
*fdctx)
+ req.fd = fdctx->remote_fd;
+
+ ret = client_submit_request(this, , frame, conf->fops, 
GFS3_OP_RELEASE,
+-clnt_release_reopen_fd_cbk, NULL, NULL, 0, 
NULL,
+-0, NULL, (xdrproc_t)xdr_gfs3_releasedir_req);
++clnt_release_reopen_fd_cbk, NULL,
++(xdrproc_t)xdr_gfs3_releasedir_req);
+ out:
+ if (ret) {
+ clnt_fd_lk_reacquire_failed(this, fdctx, conf);
+@@ -486,8 +485,8 @@ protocol_client_reopendir(clnt_fd_ctx_t *fdctx, xlator_t 
*this)
+ frame->local = local;
+
+ ret = client_submit_request(this, , frame, conf->fops, 
GFS3_OP_OPENDIR,
+-client3_3_reopendir_cbk, NULL, NULL, 0, NULL, 
0,
+-NULL, (xdrproc_t)xdr_gfs3_opendir_req);
++client3_3_reopendir_cbk, NULL,
++(xdrproc_t)xdr_gfs3_opendir_req);
+ if (ret) {
+ gf_msg(this->name, GF_LOG_ERROR, 0, PC_MSG_DIR_OP_FAILED,
+"failed to send the re-opendir request");
+@@ -547,8 +546,8 @@ protocol_client_reopenfile(clnt_fd_ctx_t *fdctx, xlator_t 
*this)
+  local->loc.path);
+
+ ret = client_submit_request(this, , frame, conf->fops, GFS3_OP_OPEN,
+-client3_3_reopen_cbk, NULL, NULL, 0, NULL, 0,
+-NULL, (xdrproc_t)xdr_gfs3_open_req);
++client3_3_reopen_cbk, NULL,
++(xdrproc_t)xdr_gfs3_open_req);
+ if (ret) {
+ gf_msg(this->name, GF_LOG_ERROR, 0, PC_MSG_DIR_OP_FAILED,
+"failed to send the re-open request");
+@@ -745,8 +744,8 @@ protocol_client_reopendir_v2(clnt_fd_ctx_t *fdctx, 
xlator_t *this)
+ frame->local = local;
+
+ ret = client_submit_request(this, , frame, conf->fops, 
GFS3_OP_OPENDIR,
+-client4_0_reopendir_cbk, NULL, NULL, 0, NULL, 
0,
+-NULL, (xdrproc_t)xdr_gfx_opendir_req);
++client4_0_reopendir_cbk, NULL,
++(xdrproc_t)xdr_gfx_opendir_req);
+ if (ret) {
+ gf_msg(this->name, GF_LOG_ERROR, 0, PC_MSG_DIR_OP_FAILED,
+ 

Bug#927119: unblock: apt-dater/1.0.4-2

[Patrick Matthäi]

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

Please unblock package apt-dater. It adds missing README.* files and fixes a 
bug, where
you can not create new sessions, because of an old deprecated configuration for 
tmux.


diff -Naur '--exclude=.svn' 1.0.4-1/debian/apt-dater.docs 
1.0.4-2/debian/apt-dater.docs
--- 1.0.4-1/debian/apt-dater.docs   2019-02-11 10:58:30.644694694 +0100
+++ 1.0.4-2/debian/apt-dater.docs   2019-04-15 10:23:54.946984935 +0200
@@ -1,3 +1,2 @@
 README
-README.tclfilter
-README.xmlreport
+README.*
diff -Naur '--exclude=.svn' 1.0.4-1/debian/changelog 1.0.4-2/debian/changelog
--- 1.0.4-1/debian/changelog2019-02-11 10:58:30.624694772 +0100
+++ 1.0.4-2/debian/changelog2019-04-15 10:23:54.906985186 +0200
@@ -1,3 +1,12 @@
+apt-dater (1.0.4-2) unstable; urgency=medium
+
+  * Install missing docs.
+Closes: #924176
+  * Add patch 01-tmux-options to fix an error with tmux 2.4, because of an old
+invalid option.
+
+ -- Patrick Matthäi   Mon, 15 Apr 2019 10:07:25 +0200
+
 apt-dater (1.0.4-1) unstable; urgency=medium

   * New upstream release.
diff -Naur '--exclude=.svn' 1.0.4-1/debian/patches/01-tmux-options.diff 
1.0.4-2/debian/patches/01-tmux-options.diff
--- 1.0.4-1/debian/patches/01-tmux-options.diff 1970-01-01 01:00:00.0 
+0100
+++ 1.0.4-2/debian/patches/01-tmux-options.diff 2019-04-15 10:23:54.906985186 
+0200
@@ -0,0 +1,15 @@
+# tmux 2.4 changed this option, we need it for new created sessions
+# or tmux will fail with an unknown option error.
+
+diff -Naur apt-dater-1.0.4.orig/conf/tmux.conf apt-dater-1.0.4/conf/tmux.conf
+--- apt-dater-1.0.4.orig/conf/tmux.conf2019-02-10 22:16:03.0 
+0100
 apt-dater-1.0.4/conf/tmux.conf 2019-04-15 10:02:11.499131926 +0200
+@@ -11,7 +11,7 @@
+ set -g terminal-overrides 'xterm*:smcup@:rmcup@'
+
+ set-option -g history-limit 1
+-set-option -g set-remain-on-exit on
++set-hook -g session-created 'set remain-on-exit on'
+
+ # Make C-a q kill the pane (simular to GNU screen)
+ bind-key q confirm-before -p "kill-pane #P? (y/n)" kill-pane
diff -Naur '--exclude=.svn' 1.0.4-1/debian/patches/series 
1.0.4-2/debian/patches/series
--- 1.0.4-1/debian/patches/series   1970-01-01 01:00:00.0 +0100
+++ 1.0.4-2/debian/patches/series   2019-04-15 10:23:54.906985186 +0200
@@ -0,0 +1 @@
+01-tmux-options.diff


unblock apt-dater/1.0.4-2

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

Kernel: Linux 4.19.0-4-amd64 (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

Bug#919663: libvirt: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Am 11.04.2019 um 12:02 schrieb Guido Günther:
> Hi,
> On Fri, Jan 18, 2019 at 01:38:53PM +0100, Patrick Matthäi wrote:
>> Package: src:libvirt
>> Version: 5.0.0-1
>> Severity: normal
>>
>> Hello,
>>
>> with glusterfs 5.3-1 in unstable the libraries have been split out of
>> the glusterfs-common package, there is also now a libglusterfs-dev
>> package. Please build depend on libglusterfs-dev instead of
>> glusterfs-common. Until all packages have been migrated,
>> glusterfs-common will depend on libglusterfs-dev, but I try to remove
>> this for the buster release.
>>
>> Also have a look here:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643
> I missed that one. Is it o.k. to postpone this for bullseye?
> Cheers,
>  -- Guido

Yes, but if you are uploading to buster I dont think that the release
team will reject this change.
It will also make backports for buster easier.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#926605: webissues FTCBFS: uses the build architecture qmake

[Patrick Matthäi]

tag #926605 + pending
thanks

Am 07.04.2019 um 20:47 schrieb Helmut Grohne:
> Source: webissues
> Version: 1.1.5-3
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> webissues fails to cross build from source, because it uses the build
> architecture qmake. The attached patch passes a suitable qmake via
> -qmake to ./configure and makes webissues cross buildable. Plase
> consider applying it.
>
> Helmut
thanks for your patch!

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#926708: unblock: otrs2/6.0.17-1

[Patrick Matthäi]

Am 09.04.2019 um 14:46 schrieb Ivo De Decker:
> Hi,
>
> On Tue, Apr 09, 2019 at 01:41:44PM +0200, Patrick Matthäi wrote:
>> Please unblock package otrs2
>>
>> It fixes a security bug along with other upstream fixes:
>> https://community.otrs.com/security-advisory-2019-02-security-update-for-otrs-framework/
>>
>> This shouldn't be a problem, since it is non-free?
> No. And you know this. You tried the exact same thing for stretch:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858891
>
> Being in non-free doesn't give you an exception to the freeze.
Sorry you are right, I totaly forget it..
It was an exception for fglrx in the past-past, but because it was also
closed source, so no fixes could be adapted.

I will prepare a diff along with other security fixes (I think there
will be one in the next time) if they are out

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#926708: unblock: otrs2/6.0.17-1

[Patrick Matthäi]

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

Please unblock package otrs2

It fixes a security bug along with other upstream fixes:
https://community.otrs.com/security-advisory-2019-02-security-update-for-otrs-framework/

This shouldn't be a problem, since it is non-free?

unblock otrs2/6.0.17-1

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

Kernel: Linux 4.19.0-4-amd64 (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

Bug#925525: unblock: glusterfs/5.5-1

[Patrick Matthäi]

Am 06.04.2019 um 13:42 schrieb Ivo De Decker:
> Control: tags -1 moreinfo
>
> Hi,
>
> On Tue, Mar 26, 2019 at 11:33:20AM +0100, Patrick Matthäi wrote:
>> I would like to upload glusterfs 5.5-1 (currently in experimental) to sid and
>> target this release for buster. It is a bugfix only release, also for a
>> regression, and has got small changes:
> You didn't explain what changes are important enough to ask for an unblock.
> Please elaborate.
>
> The diff is small, so it might be suitable.
>
> Cheers,
>
> Ivo

Hi,

there are several fixes:
https://docs.gluster.org/en/latest/release-notes/5.5/

They also state, that 5.4 was never offical announced, because of the
regressions in it, which prevents rolling upgrades:
https://bugzilla.redhat.com/show_bug.cgi?id=1679968
https://bugzilla.redhat.com/show_bug.cgi?id=1684569
https://bugzilla.redhat.com/show_bug.cgi?id=1684385

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#925587: unblock: znc/1.7.2-2

[Patrick Matthäi]

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

Please unblock package znc

It fixes a security bug:


diff -Naur '--exclude=.svn' 1.7.2-1/debian/changelog 1.7.2-2/debian/changelog
--- 1.7.2-1/debian/changelog2019-01-28 10:58:47.648083837 +0100
+++ 1.7.2-2/debian/changelog2019-03-26 12:58:06.264919659 +0100
@@ -1,3 +1,11 @@
+znc (1.7.2-2) unstable; urgency=high
+
+  * Add upstream patch 01-CVE-2019-9917 to fix a crash on invalid encoding,
+which fixes CVE-2019-9917.
+Closes: #925285
+
+ -- Patrick Matthäi   Tue, 26 Mar 2019 12:46:42 +0100
+
 znc (1.7.2-1) unstable; urgency=medium

   * New upstream release.
diff -Naur '--exclude=.svn' 1.7.2-1/debian/patches/01-CVE-2019-9917.diff 
1.7.2-2/debian/patches/01-CVE-2019-9917.diff
--- 1.7.2-1/debian/patches/01-CVE-2019-9917.diff1970-01-01 
01:00:00.0 +0100
+++ 1.7.2-2/debian/patches/01-CVE-2019-9917.diff2019-03-26 
12:58:06.272919610 +0100
@@ -0,0 +1,108 @@
+# Don't crash if user specified invalid encoding.
+# References: CVE-2019-9917
+# Closes: #925285
+# URL: 
https://github.com/znc/znc/commit/64613bc8b6b4adf1e32231f9844d99cd512b8973
+
+diff -Naur znc-1.7.2.orig/modules/controlpanel.cpp 
znc-1.7.2/modules/controlpanel.cpp
+--- znc-1.7.2.orig/modules/controlpanel.cpp2019-01-27 10:20:05.0 
+0100
 znc-1.7.2/modules/controlpanel.cpp 2019-03-26 12:42:34.298707717 +0100
+@@ -495,7 +495,7 @@
+ #ifdef HAVE_ICU
+ else if (sVar == "clientencoding") {
+ pUser->SetClientEncoding(sValue);
+-PutModule("ClientEncoding = " + sValue);
++PutModule("ClientEncoding = " + pUser->GetClientEncoding());
+ }
+ #endif
+ else
+diff -Naur znc-1.7.2.orig/src/IRCNetwork.cpp znc-1.7.2/src/IRCNetwork.cpp
+--- znc-1.7.2.orig/src/IRCNetwork.cpp  2019-01-27 10:20:05.0 +0100
 znc-1.7.2/src/IRCNetwork.cpp   2019-03-26 12:42:34.302707692 +0100
+@@ -1482,9 +1482,9 @@
+ }
+
+ void CIRCNetwork::SetEncoding(const CString& s) {
+-m_sEncoding = s;
++m_sEncoding = CZNC::Get().FixupEncoding(s);
+ if (GetIRCSock()) {
+-GetIRCSock()->SetEncoding(s);
++GetIRCSock()->SetEncoding(m_sEncoding);
+ }
+ }
+
+diff -Naur znc-1.7.2.orig/src/User.cpp znc-1.7.2/src/User.cpp
+--- znc-1.7.2.orig/src/User.cpp2019-01-27 10:20:05.0 +0100
 znc-1.7.2/src/User.cpp 2019-03-26 12:42:34.302707692 +0100
+@@ -1253,9 +1253,9 @@
+ void CUser::SetDenySetBindHost(bool b) { m_bDenySetBindHost = b; }
+ void CUser::SetDefaultChanModes(const CString& s) { m_sDefaultChanModes = s; }
+ void CUser::SetClientEncoding(const CString& s) {
+-m_sClientEncoding = s;
++m_sClientEncoding = CZNC::Get().FixupEncoding(s);
+ for (CClient* pClient : GetAllClients()) {
+-pClient->SetEncoding(s);
++pClient->SetEncoding(m_sClientEncoding);
+ }
+ }
+ void CUser::SetQuitMsg(const CString& s) { m_sQuitMsg = s; }
+diff -Naur znc-1.7.2.orig/src/znc.cpp znc-1.7.2/src/znc.cpp
+--- znc-1.7.2.orig/src/znc.cpp 2019-01-27 10:20:05.0 +0100
 znc-1.7.2/src/znc.cpp  2019-03-26 12:42:34.302707692 +0100
+@@ -2092,18 +2092,36 @@
+ m_uiForceEncoding++;
+ #ifdef HAVE_ICU
+ for (Csock* pSock : GetManager()) {
+-if (pSock->GetEncoding().empty()) {
+-pSock->SetEncoding("UTF-8");
+-}
++pSock->SetEncoding(FixupEncoding(pSock->GetEncoding()));
+ }
+ #endif
+ }
+ void CZNC::UnforceEncoding() { m_uiForceEncoding--; }
+ bool CZNC::IsForcingEncoding() const { return m_uiForceEncoding; }
+ CString CZNC::FixupEncoding(const CString& sEncoding) const {
+-if (sEncoding.empty() && m_uiForceEncoding) {
++if (!m_uiForceEncoding) {
++return sEncoding;
++}
++if (sEncoding.empty()) {
+ return "UTF-8";
+ }
++const char* sRealEncoding = sEncoding.c_str();
++if (sEncoding[0] == '*' || sEncoding[0] == '^') {
++sRealEncoding++;
++}
++if (!*sRealEncoding) {
++return "UTF-8";
++}
++#ifdef HAVE_ICU
++UErrorCode e = U_ZERO_ERROR;
++UConverter* cnv = ucnv_open(sRealEncoding, );
++if (cnv) {
++ucnv_close(cnv);
++}
++if (U_FAILURE(e)) {
++return "UTF-8";
++}
++#endif
+ return sEncoding;
+ }
+
+diff -Naur znc-1.7.2.orig/test/integration/tests/scripting.cpp 
znc-1.7.2/test/integration/tests/scripting.cpp
+--- znc-1.7.2.orig/test/integration/tests/scripting.cpp2019-01-27 
10:20:05.0 +0100
 znc-1.7.2/test/integration/tests/scripting.cpp 2019-03-26 
12:42:34.302707692 +0100
+@@ -55,6 +55,13 @@
+ ircd.Write(":n!u@h PRIVMSG nick :Hi\xF0, github issue #1229");
+ // "replacement character"
+ client.ReadUntil("Hi\xEF\xBF\xBD, github issue");
++
++/

Bug#925525: unblock: glusterfs/5.5-1

[Patrick Matthäi]

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

Hello,

I would like to upload glusterfs 5.5-1 (currently in experimental) to sid and
target this release for buster. It is a bugfix only release, also for a
regression, and has got small changes:

$ diff -Naur glusterfs-5.4/ glusterfs-5.5/ --exclude=.pc --exclude=tests 
--exclude=ChangeLog --exclude=VERSION --exclude=debian --exclude=configure 
--exclude=Makefile --exclude=glusterfs.spec|diffstat
 events/src/peer_eventsapi.py   |8 +--
 extras/systemd/glusterd.service.in |5 +---
 extras/systemd/glustereventsd.service.in   |7 ++
 libglusterfs/src/common-utils.c|   15 -
 libglusterfs/src/common-utils.h|4 +--
 libglusterfs/src/globals.h |4 ++-
 rpc/xdr/src/glusterfs3.h   |2 +
 rpc/xdr/src/glusterfs4-xdr.x   |1
 xlators/cluster/afr/src/afr-self-heal-data.c   |   28 +++--
 xlators/mgmt/glusterd/src/glusterd-brick-ops.c |2 -
 xlators/mgmt/glusterd/src/glusterd-handshake.c |2 -
 xlators/mgmt/glusterd/src/glusterd-utils.c |   12 +++---
 12 files changed, 52 insertions(+), 38 deletions(-)

If you agree with it I would prepare a 5.5-2 for unstable.

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

Kernel: Linux 4.19.0-2-amd64 (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

Bug#924176: apt-dater: broken symlink: /usr/share/doc/apt-dater/README -> README.md

[Patrick Matthäi]

tag #924176 + pending
thanks

Am 10.03.2019 um 03:50 schrieb Andreas Beckmann:
> Package: apt-dater
> Version: 1.0.4-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
>
> From the attached log (scroll to the bottom...):
>
> 0m22.7s ERROR: FAIL: Broken symlinks:
>   /usr/share/doc/apt-dater/README -> README.md (apt-dater)
>
>
> cheers,
>
> Andreas

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#925449: unblock: kdenlive/18.12.3-1

[Patrick Matthäi]

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

Please unblock package kdenlive

Hello,

before my VAC I were a bit late with the upload. Please unblock kdenlive 
18.12.3-1,
it only contains updated translations:

$ diff -Naur kdenlive-18.12.2/ kdenlive-18.12.3/|diffstat
 CMakeLists.txt|2
 data/kdenlive_wipes.knsrc |2
 debian/changelog  |6
 po/ca/kdenlive.po |8 -
 po/ca@valencia/kdenlive.po|8 -
 po/da/kdenlive.po |  119 ---
 po/es/docs/kdenlive/index.docbook |  300 --
 po/gl/kdenlive.po |   59 +++
 po/id/kdenlive.po |  113 +-
 po/nl/kdenlive.po |   10 -
 po/pt_BR/kdenlive.po  |  122 +++
 po/uk/kdenlive.po |4
 po/zh_CN/kdenlive.po  |4
 13 files changed, 418 insertions(+), 339 deletions(-)

unblock kdenlive/18.12.3-1

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

Kernel: Linux 4.19.0-2-amd64 (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

Bug#923459: devscripts: uscan in buster could not check version and throws warnings

[Patrick Matthäi]

Am 28.02.2019 um 17:24 schrieb Dominique Dumont:
> On Thursday, 28 February 2019 15:49:53 CET Xavier wrote:
>> This looks like a bug in HTTP::Response: $response contains valid HTML
>> data in $response->{_content} but $response->decoded_content returns
>> "undef".
> Well, software.keep-cool.org http server sends back weird headers:
>
> $ mojo get -M HEAD -v http://software.keep-cool.org/dl/ckport/
> HEAD http://software.keep-cool.org/dl/ckport/ HTTP/1.1
> Host: software.keep-cool.org
> Accept-Encoding: gzip
> User-Agent: Mojolicious (Perl)
> Content-Length: 0
>
> HTTP/1.1 200 Ok
> Content-Length: 1731
> Date: Thu, 28 Feb 2019 16:20:28 GMT
> Last-Modified: Sat, 11 Aug 2012 15:38:03 GMT
> Server: mini_httpd/1.19 19dec2003
> Content-Type: text/html; charset=%s
>
> It's possible that "charset=%s" trips up HTTP::Response.
>
> On the other hand, the command "GET http://software.keep-cool.org/dl/ckport/; 
> (which uses HTTP::Response) works fine:
>
> $  GET http://software.keep-cool.org/dl/ckport/   
> 
> Index of software.keep-cool.org/dl/ckport/
> [snip]
>
> HTH
>
Maybe it helps: on the other side other watch files for the same
download site are working:

* roaraudio
* muroar
* muroard
* roarplaylistd

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#923459: devscripts: uscan in buster could not check version and throws warnings

[Patrick Matthäi]

Package: devscripts
Version: 2.19.3
Severity: normal


Hi,

with uscan on buster (instead of stretch) uscan fails to check two packages:

$ uscan --report --verbose
uscan info: uscan (version 2.19.3) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="ckport" version="0.1~rc1-8" (as seen in debian/changelog)
uscan info: package="ckport" version="0.1~rc1" (no epoch/revision)
uscan info: ./debian/changelog sets package="ckport" version="0.1~rc1"
uscan info: Found upstream signing keyring: debian/upstream/signing-key.asc
uscan info: Process watch file at: debian/watch
package = ckport
version = 0.1~rc1
pkg_dir = .
uscan info: opts: 
pgpsigurlmangle=s/$/.asc/,uversionmangle=s/~//;s/beta/~beta/;s/-pr/~pr/;s/rc/~rc/
uscan info: line: http://software.keep-cool.org/dl/ckport/ 
ckport-([^-]*)\.tar\.gz
uscan info: Parsing pgpsigurlmangle=s/$/.asc/
uscan info: Parsing uversionmangle=s/~//;s/beta/~beta/;s/-pr/~pr/;s/rc/~rc/
uscan info: line: http://software.keep-cool.org/dl/ckport/ 
ckport-([^-]*)\.tar\.gz
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.1~rc1
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.1~rc1
uscan info: Requesting URL:
   http://software.keep-cool.org/dl/ckport/
Use of uninitialized value $content in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 66.
Use of uninitialized value $content in pattern match (m//) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 325.
Use of uninitialized value in substitution (s///) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 305.
Use of uninitialized value in substitution (s///) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 308.
Use of uninitialized value $content in pattern match (m//) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 340.
Use of uninitialized value $content in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 350.
uscan info: Matching pattern:
   (?:(?:http://software.keep-cool.org)?\/dl\/ckport\/)?ckport-([^-]*)\.tar\.gz
Use of uninitialized value $content in pattern match (m//) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 359.
uscan warn: In debian/watch no matching files for watch line
  http://software.keep-cool.org/dl/ckport/ ckport-([^-]*)\.tar\.gz
uscan info: Scan finished


$ uscan --report --verbose
uscan info: uscan (version 2.19.3) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="aroarfw" version="0.1~beta5-5" (as seen in 
debian/changelog)
uscan info: package="aroarfw" version="0.1~beta5" (no epoch/revision)
uscan info: ./debian/changelog sets package="aroarfw" version="0.1~beta5"
uscan info: Found upstream signing keyring: debian/upstream/signing-key.asc
uscan info: Process watch file at: debian/watch
package = aroarfw
version = 0.1~beta5
pkg_dir = .
uscan info: opts: 
pgpsigurlmangle=s/$/.asc/,uversionmangle=s/~//;s/beta/~beta/;s/-pr/~pr/;s/rc/~rc/
uscan info: line: http://roaraudio.keep-cool.org/dl/aroarfw-(.*)\.tar\.gz
uscan info: Parsing pgpsigurlmangle=s/$/.asc/
uscan info: Parsing uversionmangle=s/~//;s/beta/~beta/;s/-pr/~pr/;s/rc/~rc/
uscan info: line: http://roaraudio.keep-cool.org/dl/aroarfw-(.*)\.tar\.gz
uscan info: Last orig.tar.* tarball version (from debian/changelog): 0.1~beta5
uscan info: Last orig.tar.* tarball version (dversionmangled): 0.1~beta5
uscan info: Requesting URL:
   http://roaraudio.keep-cool.org/dl/
Use of uninitialized value $content in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 66.
Use of uninitialized value $content in pattern match (m//) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 325.
Use of uninitialized value in substitution (s///) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 305.
Use of uninitialized value in substitution (s///) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 308.
Use of uninitialized value $content in pattern match (m//) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 340.
Use of uninitialized value $content in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 350.
uscan info: Matching pattern:
   (?:(?:http://roaraudio.keep-cool.org)?\/dl\/)?aroarfw-(.*)\.tar\.gz
Use of uninitialized value $content in pattern match (m//) at 
/usr/share/perl5/Devscripts/Uscan/http.pm line 359.
uscan warn: In debian/watch no matching files for watch line
  http://roaraudio.keep-cool.org/dl/aroarfw-(.*)\.tar\.gz
uscan info: Scan finished


aroarfw debian/watch:
version=3
opts=\
pgpsigurlmangle=s/$/.asc/,\
uversionmangle=s/~//;s/beta/~beta/;s/-pr/~pr/;s/rc/~rc/ \
http://roaraudio.keep-cool.org/dl/aroarfw-(.*)\.tar\.gz

ckport debian/watch:
version=3
opts=\
pgpsigurlmangle=s/$/.asc/,\
uversionmangle=s/~//;s/beta/~beta/;s/-pr/~pr/;s/rc/~rc/ \
http://software.keep-cool.org/dl/ckport/ ckport-([^-]*)\.tar\.gz


-- 

Bug#923441: devscripts: --no-verbose does not work anymore in uscan

[Patrick Matthäi]

Package: devscripts
Version: 2.19.3
Severity: normal

Hello,

with current buster the --no-verbose parameter for uscan does not work anymore,
but it is still listed @ --help:

$ uscan --report --no-verbose ; echo $?
Use of uninitialized value $msg in concatenation (.) or string at 
/usr/share/perl5/Devscripts/Config.pm line 324.
uscan error Bad value for verbose:
1


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

Kernel: Linux 4.19.0-2-amd64 (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 devscripts depends on:
ii  dpkg-dev  1.19.5
ii  fakeroot  1.23-1
ii  file  1:5.35-2
ii  gnupg 2.2.12-1
ii  gnupg22.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-7
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-4
ii  python3   3.7.2-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0~rc3
ii  at  3.1.23-1
ii  curl7.64.0-1
ii  dctrl-tools 2.24-3
pn  debian-keyring  
ii  dput1.0.3
ii  dupload 2.9.3
pn  equivs  
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.5
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.9.1~bpo9+1
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.3
ii  python3-debian  0.1.34
pn  python3-magic   
ii  python3-requests2.20.0-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  bsd-mailx [mailx]8.1.2-0.20180807cvs-1
ii  build-essential  12.5
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
pn  libfile-desktopentry-perl
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
pn  mozilla-devscripts   
ii  mutt 1.10.1-2
ii  openssh-client [ssh-client]  1:7.9p1-6
pn  piuparts 
pn  postgresql-client
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#915103: Apache2 HTTP/2 connection problems with Safari clients

[Patrick Matthäi]

Hi Stefan,

got the same issue with Safari clients when updating from
2.4.25-3+deb9u5 to 2.4.25-3+deb9u6.
Looking forward for a security regression update :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919670: fio: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:fio
Version: 3.12-1
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919669: nfs-ganesha: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:nfs-ganesha
Version: 2.7.1-1
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919664: bareos: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:bareos
Version: 16.2.6-4
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919663: libvirt: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:libvirt
Version: 5.0.0-1
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919667: samba: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:samba
Version: 2:4.9.4+dfsg-1
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919665: uwsgi: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:uwsgi
Version: 2.0.17.1-11
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919666: tgt: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:tgt
Version: 1:1.0.74-1
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919668: qemu: Change build dependency to libglusterfs-dev

[Patrick Matthäi]

Package: src:qemu
Version: 1:3.1+dfsg-2
Severity: normal

Hello,

with glusterfs 5.3-1 in unstable the libraries have been split out of
the glusterfs-common package, there is also now a libglusterfs-dev
package. Please build depend on libglusterfs-dev instead of
glusterfs-common. Until all packages have been migrated,
glusterfs-common will depend on libglusterfs-dev, but I try to remove
this for the buster release.

Also have a look here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919643

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919643: transition: glusterfs

[Patrick Matthäi]

Am 18.01.2019 um 10:20 schrieb Emilio Pozuelo Monfort:
> On 18/01/2019 09:33, Patrick Matthäi wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hello,
>>
>> glusterfs 5.2-2 has been accepted in experimental.
>> For closing #918503 and #881526, which makes life of other maintainers easier
>> and smaller dependencies on standard systems I would like to upload it to sid
>> along with the new bugfix release 5.3 and have the changes in buster.
>> There is no soname change, but now the libraries are seperated in single
>> packages and I also provide libglusterfs-dev again.
>>
>> The reverse dependencies just have to switch their build dependency from
>> glusterfs-common to libglusterfs-dev:
> Can't you make glusterfs-common depend on libglusterfs-dev (until the buster
> release) so that rdeps don't fail to build if you upload this? Then they can
> update their build-dep asynchronously.
>
> Just considering this because there's no real transition per se, particularly 
> if
> you address that concern.
>
> Cheers,
> Emili


So you mean:

* 5.3-1: upload to sid with glusterfs-common depending on libglusterfs-dev
* Let 5.3-1 migrate to buster and filling bugs against rdeps to change
their deps
* If all bugs are closed make a new upload removing the -commong -> -dev dep

If you mean this I would start with it

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#919643: transition: glusterfs

[Patrick Matthäi]

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

Hello,

glusterfs 5.2-2 has been accepted in experimental.
For closing #918503 and #881526, which makes life of other maintainers easier
and smaller dependencies on standard systems I would like to upload it to sid
along with the new bugfix release 5.3 and have the changes in buster.
There is no soname change, but now the libraries are seperated in single
packages and I also provide libglusterfs-dev again.

The reverse dependencies just have to switch their build dependency from
glusterfs-common to libglusterfs-dev:

uwsgi-plugin-glusterfs
samba-vfs-modules
qemu-block-extra
nfs-ganesha-gluster
libvirt-daemon-driver-storage-gluster
fio
gfio

Could I go ahead?



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

Kernel: Linux 4.9.0-8-amd64 (SMP w/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)

Bug#918503: glusterfs-common: support files not separated from shared library

[Patrick Matthäi]

tag #918503 + pending
thanks

Am 06.01.2019 um 20:46 schrieb Helmut Grohne:
> Package: glusterfs-common
> Version: 5.2-1
> Severity: serious
> Justification: 8.2
> Tags: patch
> Control: block 881526 by -1
>
> glusterfs-common combines shared libraries with a lot of other files and
> even a glusterfs user. Doing so violates the Debian policy section 8.2:
>
> | If your package contains files whose names do not change with each
> | change in the library shared object version, you must not put them in
> | the shared library package.
>
> It is quite evident that the python module, firewalld integration,
> logrotate.d snippet and many other files will not change with an soname
> bump. Given that other packages (e.g. fio) link libglusterfs0, it is
> evident that libglusterfs0 is not a private shared library. Therefore
> glusterfs-common violates a policy must.
>
> The attached patch fixes that. I'm filing it as a separate bug, because
> the policy violation is much narrower in scope than #881526 is.
>
> Helmut

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#915345: Remove roar support for now? (Fixes FTBFS)

[Patrick Matthäi]

Am 09.01.2019 um 16:03 schrieb Helge Kreutzmann:
> Hello Ryan,
> cmus is marked for autoremoval, the freeze is approaching (where no
> removed packages are allowed to reenter testing) and I see no activity
> from the cmus side.
>
> Also at least the mpd developers are not very confident in the code
> quality of libroar
> https://github.com/MusicPlayerDaemon/MPD/commit/06ca08ce555
>
> I just checked, with the following patch cmus builds just fine
> (although of course without roaraudio), so I suggest to apply it at
> least until roaraudio is fixed:
>
> root@samd:/tmp# diff -u cmus-2.7.1+git20160225/debian/control 
> cmus-2.7.1+git20160225.new/debian/control
> --- cmus-2.7.1+git20160225/debian/control   2018-05-17 11:10:59.0 
> +0200
> +++ cmus-2.7.1+git20160225.new/debian/control   2019-01-09 15:21:35.615201691 
> +0100
> @@ -25,7 +25,6 @@
>   libncursesw5-dev,
>   libopusfile-dev,
>   libpulse-dev (>= 0.9.19),
> - libroar-dev,
>   libsamplerate0-dev,
>   libvorbis-dev,
>   libwavpack-dev,
> root@samd:/tmp# diff -u cmus-2.7.1+git20160225/debian/rules 
> cmus-2.7.1+git20160225.new/debian/rules
> --- cmus-2.7.1+git20160225/debian/rules 2018-05-17 11:10:59.0 +0200
> +++ cmus-2.7.1+git20160225.new/debian/rules 2019-01-09 15:47:02.105477216 
> +0100
> @@ -4,7 +4,7 @@
>  LDFLAGS+=-Wl,--as-needed
>  CFLAGS+=-I/usr/include/ncursesw
>
> -suggested_deps = pulse roar jack
> +suggested_deps = pulse jack
>
>  EXTRA_CMUS_DIR_OP_PLUGINS = debian/cmus/usr/lib/cmus/op/
>  EXTRA_CMUS_PLUGINS := $(foreach plugin,$(suggested_deps),$(plugin).so)
>
> Greetings
>
> Helge


Hello,

we just work on a fix for roaraudio currently. I just were on vacation
the whole december and got a longer backlog.





signature.asc
Description: OpenPGP digital signature

Bug#916764: znc-backlog: overly strict dependency on znc?

[Patrick Matthäi]

Am 28.12.2018 um 15:02 schrieb Felipe Sateler:
>
>
> On Fri, Dec 28, 2018 at 10:33 AM Patrick Matthäi  <mailto:pmatth...@debian.org>> wrote:
>
> Hola,
>
> Am 24.12.2018 um 12:44 schrieb Felipe Sateler:
>> > Perhaps znc could Provide: znc-plugin-$somenumber, which could
>> be used by
>>
>> > out-of-tree plugins? Adding the znc maintainers to the loop
>> for their input
>>
>> That's being used successfully by some packages ...
>>
>>
>> I'm creating a new bug for tracking this (better) solution.
>
>
> I dont know how this would help now after the relaxed dependency
> from znc-backlog, because..:
>
> * on changes znc-backlog still needs a binNMU or code changes,
> like now
>
>
> Right. But the current solution is still suboptimal. For example, if
> you upload a new package changing only metadata (say, the Vcs-*
> fields), znc-backlog would need a binNMU. In the more general case, a
> new upstream version of znc might not break the plugin ABI.
>  
>
> * I can provide a znc-plugin-$foobar package, but who ensures at
> an non stable api, if a change is necessary or not? I think it
> will make it more complicated or is there a nice solution for it?
>
> Indeed, this implies a lot more work for you.
>
>
Where a binNMU would be more safe and less work

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#916764: znc-backlog: overly strict dependency on znc?

[Patrick Matthäi]

Hola,

Am 24.12.2018 um 12:44 schrieb Felipe Sateler:
> > Perhaps znc could Provide: znc-plugin-$somenumber, which could be
> used by
>
> > out-of-tree plugins? Adding the znc maintainers to the loop for
> their input
>
> That's being used successfully by some packages ...
>
>
> I'm creating a new bug for tracking this (better) solution.


I dont know how this would help now after the relaxed dependency from
znc-backlog, because..:

* on changes znc-backlog still needs a binNMU or code changes, like now

* I can provide a znc-plugin-$foobar package, but who ensures at an non
stable api, if a change is necessary or not? I think it will make it
more complicated or is there a nice solution for it?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#916845: needrestart: README.nagios.md refers to undistributed file ex/nagios/needrestart-nagios

[Patrick Matthäi]

tag #916845 + pending
thanks

Am 19.12.2018 um 13:06 schrieb Jean-Michel Vourgère:
> Package: needrestart
> Version: 3.3-2
> Severity: normal
>
> Dear Maintainer,
>
> Please distribute de ex/nagios/needrestart-nagios as documentation.
> It is missing.
>
> Alternatively, it would make sense to copy it directly in
> /etc/sudoers.d/ since it is only for user nagios and it include the -p
> parameter that prevent automatic restarts. Some people might disagree, though.
>
> Thank you :)

Hi,

I have added it as an example file

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/