Bug#821840: Bug#821897: golang-github-kotakanbe-logrus-prefixed-formatter: changing from RFP to ITP

[Nobuhiro Iwamatsu]

retitle 821840 ITP: golang-github-kotakanbe-logrus-prefixed-formatter
-- logrus prefix log formatter for Go
owner 821840 !
thanks

Hi,

I am intrested in this package, I am going to package this.

Best regards,
  Nobuhiro

Bug#875267: FTBFS: dpkg-source fails due to changes in upstream source

[Drew Parsons]

Package: nwchem
Version: 6.6+r27746-4
Severity: normal

nwchem cannot build on its own, since changes are made to some
upstream files outside of the debian/patches system.

This is caught during dh_clean in dh_auto_clean built on a pbuilder chroot
(pdebuild).

A build log reports:
  dh_auto_clean
  make[1]: Leaving directory '/home/drew/projects/scalapack-deps/build/nwchem'
 dh_autoreconf_clean
 dh_autotools-dev_restoreconfig
 dh_clean
  dpkg-source: info: using source format '3.0 (quilt)'
  dpkg-source: info: building nwchem using existing 
./nwchem_6.6+r27746.orig.tar.bz2
  dpkg-source: warning: ignoring deletion of file 
src/nwpw/nwpwlib/D3dB/hilbert.c.bak, use --include-removal to override
  dpkg-source: warning: ignoring deletion of file 
src/nwpw/nwpwlib/utilities/paw_utilities/nwpw_gaunt.F.bak, use 
--include-removal to override
  dpkg-source: warning: ignoring deletion of file 
src/nwpw/libraryps/HGH_LDA/C.bak, use --include-removal to override
  dpkg-source: warning: ignoring deletion of file 
src/nwpw/libraryps/paw_default/Al.bak, use --include-removal to override
  dpkg-source: warning: ignoring deletion of file src/atomscf/src.orig, use 
--include-removal to override
  dpkg-source: warning: ignoring deletion of file 
src/tools/ga-5-4/gfutex/examples/scf/twoel.C.orig, use --include-removal to 
override
  dpkg-source: warning: ignoring deletion of file 
src/tools/ga-5-4/comex/src-dmapp/dmapp.h.bak, use --include-removal to override
  dpkg-source: warning: ignoring deletion of file 
web/doc/user.4.6/user.html.bak, use --include-removal to override
  dpkg-source: info: local changes detected, the modified files are:
   nwchem/src/config/NWCHEM_CONFIG
   nwchem/src/config/nwchem_config.h
  dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/nwchem_6.6+r27746-4.1.diff.peJn2P
  dpkg-source: info: you can integrate the local changes with dpkg-source 
--commit

I tested after setting debian/compat to 10, so this new FTBFS may be a
consequence of debhelper 10.


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

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

Versions of packages nwchem depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-4
ii  libblas3 [libblas.so.3]3.7.1-3
ii  libc6  2.24-17
ii  libgcc11:7.2.0-4
ii  libgfortran3   6.4.0-5
ii  liblapack3 [liblapack.so.3]3.7.1-3
ii  libopenblas-base [liblapack.so.3]  0.2.20+ds-3
ii  libopenmpi22.1.1-6+b1
ii  libpython2.7   2.7.13-4
ii  libquadmath0   7.2.0-4
ii  mpi-default-bin1.9
ii  nwchem-data6.6+r27746-4
ii  zlib1g 1:1.2.8.dfsg-5

nwchem recommends no packages.

nwchem suggests no packages.

-- no debconf information

Bug#875265: RFS: rednotebook/2.2-2 [ITP] [ITA] -- A cross-platform journal

[Phil Wyett]

Package: sponsorship-requests
Severity: wishlist
Owner: Phil Wyett 

I am looking for a sponsor for my package "rednotebook":

* Package name: rednotebook
  Version : 2.2-2
  Upstream Author : Jendrik Seipp 
* URL : https://github.com/jendrikseipp/rednotebook
* License : GPL-2+
  Programming Lang: Python
  Description: A modern desktop journal. It lets you format, tag and
   search your entries. You can also add pictures, links
   and customizable templates, spell check your notes,
   and export to plain text, HTML, Latex or PDF.

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

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

Alternatively, one can download the package with dget using this command:
https://mentors.debian.net/debian/pool/main/r/rednotebook/rednotebook_2.2-2.ds
c

More information about rednotebook can be obtained from:

http://rednotebook.sourceforge.net
https://github.com/jendrikseipp/rednotebook

This package was removed from debian due to webkit issues. This is hopefully the
beginning of having it back in debian.

I am working with the upstream author and will continue to do so.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Github: https://github.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

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

Bug#869408: upstream patch is more complex

[Noah Meyerhans]

On Sun, Sep 10, 2017 at 01:14:53AM +0200, Francesco Potortì wrote:
> Apparently this warning was useful to discover a bug, corrected upstream:
> 
>  
>  
> 

This is the patch that's currently staged in the Debian spamassassin git
repo. See
https://anonscm.debian.org/cgit/collab-maint/spamassassin.git/commit/?id=067c70e43c65543602d5cab66ce1b9bd521271a7

(Note that tracker.debian.org still links to the svn repo, which doesn't
have that patch. The tracker links will be updated with the next upload,
which will happen when I've solved an annoying startup issue...)

noah



signature.asc
Description: PGP signature

Bug#875264: ITP: rednotebook -- -- A cross-platform journal

[Phil Wyett]

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

* Package name: rednotebook
  Version : 2.2
  Upstream Author : Jendrik Seipp 
* URL : https://github.com/jendrikseipp/rednotebook
* License : GPL-2+
  Programming Lang: Python
  Description: A modern desktop journal. It lets you format, tag and
   search your entries. You can also add pictures, links
   and customizable templates, spell check your notes,
   and export to plain text, HTML, Latex or PDF.

Notes:

This package was removed from debian due to webkit issues.

The package, major version 2, will be introduced as a new package.

I will also be taking maintainer responsibility of the package.

Regards

Phil

-- 
*** If this is a mailing list, I am subscribed, no need to CC me.***

Playing the game for the games sake.

Web: https://kathenas.org

Github: https://github.com/kathenas

Twitter: kathenasorg

Instagram: kathenasorg

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

Bug#864733: [Pkg-privacy-maintainers] Bug#864733: Error: "Download error: Download Error: 404 Not Found", Debian stable

[Roger Shimizu]

Control: notfound -1 0.2.8-1

On Sun, Sep 10, 2017 at 5:15 AM, Nikolas Nyby  wrote:
>
> Hi,
> I received this error in version 0.2.7-3 of this package. I'm using
> Debian testing. Here's the output of torbrowser-launcher:
>
> $ torbrowser-launcher
> Tor Browser Launcher
> By Micah Lee, licensed under MIT
> version 0.2.7
> https://github.com/micahflee/torbrowser-launcher
> Downloading and installing Tor Browser for the first time.
> Downloading
> https://dist.torproject.org/torbrowser/update_2/release/Linux_x86_64-gcc3/x/en-US
> Download Error: Download Error: 404 Not Found  'torbrowser_launcher.launcher.DownloadErrorException'>

Could you try the latest version 0.2.8-1, which was just migrated to buster?
Thanks!

-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#851324: python-debian: migrate to standard ‘unittest’ for test suite discovery

[Stuart Prescott]

Control: tags -1 - patch

> The test suite does not appear to use any ‘nose’ features that are not
> already in the standard library ‘unittest’ module as of Python 2.7.
> The dependency on ‘nose’ is evidently only to do automatic test suite
> discovery.

More relevant, I think, is that the nose module is essentially unmaintained 
and so it is wortwhile migrating to something that has a future.

> My proposed implementation for this is at
>  aintenance/unittest>, the ‘wip/maintenance/unittest’ branch.

As already noted on the mailing list, these changes completely break the test 
suite at build time and are additionally buggy in their invocation of the 
autopkgtests (hence removing the "patch" tag). Something similar in nature 
that is tested and works would be quite welcome.

regards
Stuart

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

Bug#874477: stretch-pu: package ruby-gnome2/3.1.0-1+deb9u1

[dai]

On Sat, Sep 09, 2017 at 05:19:42PM +0200, Julien Cristau wrote:
> Assuming this is tested in stretch to actually be the right
> dependencies, feel free to upload :)

Uploaded. Thanks.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#866519: ITP: pybitcointools -- library for cryptocurrency transactions — Python

[Ben Finney]

Control: tags -1 + pending

The packaging of ‘pybitcointools’ is now complete, release “1.1.42-1”
is in the Debian NEW queue
.

-- 
 \ “Geeks like to think that they can ignore politics. You can |
  `\leave politics alone, but politics won't leave you alone.” |
_o__) —Richard M. Stallman, 2002-07-26 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#821897: golang-github-rifflock-lfshook: changing from RFP to ITP

[Nobuhiro Iwamatsu]

retitle 821897 ITP: golang-github-rifflock-lfshook -- local filesystem
hook for logrus (Go library)

owner 821897 !
thanks

Hi,

I am intrested in this package, I am going to package this.

Best regards,
  Nobuhiro

Bug#875263: gcc-mingw-w64 package shouldn't recommend g++-mingw-w64, gfortran-mingw-w64, gnat-mingw-w64

[Buo-Ren, Lin]

Source: gcc-mingw-w64
Severity: wishlist

Dear Maintainer,

   * What led up to the situation?
 I'm installing gcc-mingw-w64 package for a C cross-compiler to Windows
AMD64 architecture
   * What exactly did you do (or not do) that was effective (or ineffective)?
   * `apt install gcc-mingw-w64`
   * Look for gcc-mingw-w64 in Muon package manager, and mark as to-be-
installed
   * What was the outcome of this action?
   * Either `apt` and Muon selects g++-mingw-w64, gfortran-mingw-w64, gnat-
mingw-w64 automatically, which is either a C++ compiler, Fortran compiler(?)
and a Ada(???) compiler
   * What outcome did you expect instead?
 Only C cross-compiler is installed as the others doesn't really complement
the package and should downgrade to Suggests: or even less.



-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports'), (99, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#831435: www.debian.org: Link to the patch tracker broken

[Tim Landscheidt]

AFAICT:

| diff --git a/templates/config.tmpl b/templates/config.tmpl
| index 3f64edf..f1f7c84 100644
| --- a/templates/config.tmpl
| +++ b/templates/config.tmpl
| @@ -22,7 +22,7 @@
| changelogs_url = 'http://ftp-master.metadata.debian.org/changelogs/'
| policy_url = 'https://www.debian.org/doc/debian-policy/'
| cn_help_url = project_homepage _ 'intro/cn'
| -   patch_tracking_url = 'http://sources.debian.net/patches/summary'
| +   patch_tracking_url = 'http://sources.debian.net/patches'
| screenshots_url = 'https://screenshots.debian.net/package/'
| screenshots_thumb_url = 
'https://screenshots.debian.net/thumbnail-with-version/'
| logo = {

should fix it.

Tim

Bug#869408: upstream patch is more complex

[Francesco Potortì]

Apparently this warning was useful to discover a bug, corrected upstream:

 
 


-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(entrance 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#873508: sparse test failures on ppc32le (and other not so common archs)

[Luc Van Oostenryck]

On Sat, Sep 9, 2017 at 11:02 PM, Uwe Kleine-König  
wrote:
>
> I tried this on ppc64le and it fixes 2 tests, so were at
>
> Out of 287 tests, 273 passed, 14 failed (10 of them are known to fail)
>
> The repaired tests are:
>
> backend/hello.c
> backend/sum.c
>
> unexpected failures are:
>
> backend/arithmetic-ops.c
> backend/cmp-ops.c
> backend/int-cond.c
> backend/logical-ops.c
>
> These are not about missing preprocessor tokens as there are no system
> includes used, but the error there is
>
> Error: unrecognized opcode: `...`
>
> . I didn't look into what the problem is there, but attached the test
> log.

It clearly looks as the code generated by LLVM  (the machine code/assembly
not LLVM's bytecode) is not understood by the assembler (or at least some
instructions). Probably a mismatch with the architecture version or something
like that.

> I did a build test on a few other Debian machines, arm64 was fine, mips
> and mipx64el had 15 failures, ppc64 (i.e. big endian) had 12. I didn't
> look in more detail and suggest to tackle one after the other :-)

I fully test on x86, x86-64, arm & ARM64 (with LLVM 3.9 or 4.0).
I also test on ppc64 but not the LLVM part because the machines I have
access to have not LLVM installed and I never bothered to install it myself.

Would it be possible to have access to a machine with the architectures
you care about?

Meanwhile, is it possible to have the build logs but with 'make V=1 ...' ?
It would also be useful to have:
- the output of 'uname -a'
- the details about the version of LLVM you're using

On the other hand, you/us should disable the sparse-llvm part since:
- it's something that is bundled and build by default but absolutely not
  needed (or even useful) to use sparse.
- it hasn't been written for anything else than x86/x86-64 (no 'layout'
  for anything else than those architectures.

Best regards,
-- Luc Van Ooostenryck

Bug#875262: ITP: golang-github-valyala-bytebufferpool -- Anti-memory-waste byte buffer pool

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: golang-github-valyala-bytebufferpool
  Version : 0.0~git20160817.0.e746df9-1
  Upstream Author : Aliaksandr Valialkin
* URL : https://github.com/valyala/bytebufferpool
* License : Expat
  Programming Lang: Go
  Description : Anti-memory-waste byte buffer pool for Go

 An implementation of a pool of byte buffers with anti-memory-waste
 protection.
 .
 The pool may waste limited amount of memory due to fragmentation.
 This amount equals to the maximum total size of the byte buffers in
 concurrent use.  Benchmark results Currently bytebufferpool is fastest
 and most effective buffer pool written in Go.

Bug#875173: [robocut] Future Qt4 removal from Buster

[Markus Schulz]

Hello Lisandro,
the latest version supports Qt5 now... but it looks like we need to change the 
upstream URL. Here is the new upstream:
https://github.com/Ti/robocut/blob/master/Readme.md
It's like 6 to 7 years that I submitted the package and I forgot a lot... 
please give me a hint how we can fix this.
Thanks!


On September 9, 2017 5:09:21 PM EDT, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>Source: robocut
>Version: 1.0.8-1
>Severity: wishlist
>User: debian-qt-...@lists.debian.org
>Usertags: qt4-removal
>
>
>Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
>as [announced] in:
>
>[announced]
>
>
>Currently Qt4 has been dead upstream and we are starting to have
>problems
>maintaining it, like for example in the [OpenSSL 1.1 support] case.
>
>[OpenSSL 1.1 support]
>
>
>In order to make this move, all packages directly or indirectly
>depending on
>the Qt4 libraries have to either get ported to Qt5 or eventually get
>removed from the Debian repositories.
>
>Therefore, please take the time and:
>- contact your upstream (if existing) and ask about the state of a Qt5
>port of your application
>- if there are no activities regarding porting, investigate whether
>there are
>suitable alternatives for your users
>- if there is a Qt5 port that is not yet packaged, consider packaging
>it
>- if both the Qt4 and the Qt5 versions already coexist in the Debian
>archives, consider removing the Qt4 version
>
>= Porting =
>
>Some of us where involved in various Qt4 to Qt5 migrations [migration]
>and we
>know for sure that porting stuff from Qt4 to Qt5 is much much easier
>and less
>painful than it was from Qt3 to Qt4.
>
>We also understand that there is still a lot of software still using
>Qt4.
>
>Don't forget to take a look at the C++ API changes page [apichanges]
>whenever
>you start porting your application.
>
>[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
>[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
>
>For any questions and issues, do not hesitate to contact the Debian
>Qt/KDE
>team at debian-qt-...@lists.debian.org
>
>The removal is being tracked in 
>
>Lisandro,
>on behalf of the Qt4 maintainers

Regards,
Markus Schulz

Bug#875260: yafc: Compile yafc binary against libreadline instead of libedit2

[Alberto Aparici]

Package: yafc
Version: 1.3.7-3
Severity: wishlist
Tags: patch

Dear Maintainer,
the yafc binary compiled against libedit2 no longer supports colored
prompts & outputs due to a libedit issue, as you can see in Debian bugs #819439
and #782043. Building against libreadline recovers this functionality
and is encouraged by the upstream developers of yafc.

To achieve this it is only needed to add libreadline7 as a dependency
for yafc and libreadline-dev as a build-dependency, as well as a
straightforward change in debian/rules for the yafc source. Sorry, I don't
really know how to implement the changes in the dependencies, ^_^',
but I attach a patch for the debian/rules file. In my system this
procedure works just fine and recovers the colored interface.

Cheers,

Al.


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

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

Versions of packages yafc depends on:
ii  libbsd0   0.8.3-1
ii  libc6 2.24-11+deb9u1
ii  libgssapi-krb5-2  1.15-1
ii  libreadline7  7.0-3
ii  libssh-4  0.7.3-2
ii  libssl1.0.2   1.0.2l-2

yafc recommends no packages.

yafc suggests no packages.

-- no debconf information
*** rules   2014-01-17 01:53:40.0 +0100
--- /usr/local/src/yafc/yafc-1.3.7/debian/rules 2017-09-04 23:29:57.868484017 
+0200
***
*** 8,14 
  
  override_dh_auto_configure:
dh_auto_configure -- \
!   --without-readline \
--with-bash-completion=/usr/share/bash-completion/completions
  
  override_dh_installchangelogs:
--- 8,15 
  
  override_dh_auto_configure:
dh_auto_configure -- \
!   --with-readline \
!   --without-editline \
--with-bash-completion=/usr/share/bash-completion/completions
  
  override_dh_installchangelogs:

Bug#875261: src:yasw: FTBFS on armhf, armel, sh4

[Adam Borowski]

Package: src:yasw
Version: 0.6-1
Severity: important
Tags: patch
Justification: fails to build from source

Hi!
As you already know, yasw fails to build on a few architectures:

filter/layoutfilter.cpp: In member function 'virtual QImage 
LayoutFilter::filter(QImage)':
filter/layoutfilter.cpp:197:60: error: no matching function for call to 
'qMax(qreal, double)'
 leftMargin = qMax((pageWidth - imageWidth) / 2, 0.0);
^

There's a patch in the original RFS bug, I'm filing it here so it doesn't
get lost.  As the last upstream release was in 2014, a timely update is
quite unlikely.


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.13.0-00222-g22e5e0f1edea (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Fix build failure on armhf and armel.

This is the result of QT's brain damage: they use inconsistent types on
these architectures: https://doc.qt.io/qt-4.8/qtglobal.html#qreal-typedef

As we don't know whether qreal is float or double, we can't use a suffix for
the literal and need a type cast.

--- yasw-0.6.orig/src/filter/layoutfilter.cpp
+++ yasw-0.6/src/filter/layoutfilter.cpp
@@ -194,10 +194,10 @@ QImage LayoutFilter::filter(QImage input
 leftMargin = 0;
 break;
 case Constants::CenterHAlignment:
-leftMargin = qMax((pageWidth - imageWidth) / 2, 0.0);
+leftMargin = qMax((pageWidth - imageWidth) / 2, (qreal)0.0);
 break;
 case Constants::RightHAlignment:
-leftMargin = qMax(pageWidth - imageWidth, 0.0);
+leftMargin = qMax(pageWidth - imageWidth, (qreal)0.0);
 break;
 }
 switch (Constants::verticalAlignment.indexOf(verticalAlignement)) {
@@ -205,10 +205,10 @@ QImage LayoutFilter::filter(QImage input
 topMargin = 0;
 break;
 case Constants::CenterVAlignment:
-topMargin = qMax((pageHeight - imageHeight) / 2, 0.0);
+topMargin = qMax((pageHeight - imageHeight) / 2, (qreal)0.0);
 break;
 case Constants::BottomVAlignment:
-topMargin = qMax(pageHeight - imageHeight, 0.0);
+topMargin = qMax(pageHeight - imageHeight, (qreal)0.0);
 break;
 }
 

Bug#867692: apparmor-profiles-extra: Totem can't open any video

[Elia Argentieri]

> Hi,
> 
> intrigeri:
> > Elia Argentieri:
> > OK. But the Totem you're running is Debian's, right?
> Ping?

Yes it is Debian's.

> > > Then I added this line to /etc/apparmor.d/local/usr.bin.totem:
> > > >   /var/lib/flatpak/exports/share/icons/** r,
> > > 
> > > and that solved all errors. I can now open videos on my home with
> > > a
> > > clean audit.log.
> > Is it *needed* for Totem to work fine for you, once you've granted
> > it
> > access to the video files you want to play?
> 
> Ping?

No, it's not needed. It works without that too.

Sorry, I forgot to reply.

Thanks again.

Bug#875259: kimageformat-plugins: Package needed for XCF thumbnails in Dolphin, nothing Recommends or Suggests it

[Ignacio R. Morelle]

Package: kimageformat-plugins
Version: 5.37.0-2
Severity: normal

According to `apt-cache rdepends kimageformat-plugins`, the only package that 
depends on this package as of this writing is libkf5archive5, and even that's 
only to introduce Breaks on older versions. The thing is, this package is 
actually quite useful to have as it provides (among other things) plugins to 
process XCF, PSD, Krita, and OpenRaster images.

I completely accidentally came across the existence of this package in sid this 
evening after a long time assuming that upstream had simply stopped providing 
support for XCF image previews in Dolphin for one reason or another -- 
especially since there is a separate unrelated thumbnailer for Krita and 
OpenRaster imagea, and I couldn't find any information pertaining to a GIMP 
thumbnailer or the lack thereof on Web. I found this issue particularly 
disappointing back when I first switched to stretch from jessie, since I use 
Dolphin and the great majority of the stuff I work with is in the GIMP XCF 
format.

Installing this package and ensuring the generic image thumbnailer ("Images 
(GIF, PNG, BMP, ...)" in Settings -> General -> Previews in Dolphin) is enabled 
allows Dolphin to generate thumbnails for XCF images as expected. Ideally, some 
other package (I don't know which one, unfortunately) should Recommend or 
Suggest this one.

I don't have access to a stretch system to test right now, but I believe this 
issue also applies there.

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

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

Versions of packages kimageformat-plugins depends on:
ii  libc62.24-17
ii  libgcc1  1:7.2.0-3
ii  libilmbase12 2.2.0-12
ii  libkf5archive5   5.37.0-2
ii  libopenexr22 2.2.0-11.1
ii  libqt5core5a 5.9.1+dfsg-9
ii  libqt5gui5   5.9.1+dfsg-9
ii  libqt5printsupport5  5.9.1+dfsg-9
ii  libstdc++6   7.2.0-3

kimageformat-plugins recommends no packages.

kimageformat-plugins suggests no packages.

-- no debconf information

Bug#822436: marked as done (nestopia closes when launching roms)

[Aaron Valdes]

Will this be available for Debian 9?

On Sat, Sep 9, 2017 at 7:06 AM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Your message dated Sat, 09 Sep 2017 11:04:58 +
> with message-id 
> and subject line Bug#822436: fixed in nestopia 1.48-1
> has caused the Debian Bug report #822436,
> regarding nestopia closes when launching roms
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 822436: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822436
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
> -- Forwarded message --
> From: diego 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sun, 24 Apr 2016 15:08:23 +0200
> Subject: nestopia closes when launching roms
> Package: nestopia
> Version: 1.47-1
> Severity: important
>
> Dear Maintainer,
>
> When launching a rom the program closes. I don't know how to retrieve more
> information about the bug, so if more information is needed you will have
> to
> say me how I should obtain it.
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.5.0-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages nestopia depends on:
> ii  libao4  1.1.0-3
> ii  libarchive133.1.2-11+b1
> ii  libc6   2.22-6
> ii  libepoxy0   1.3.1-1
> ii  libgcc1 1:5.3.1-14
> ii  libgdk-pixbuf2.0-0  2.34.0-1
> ii  libglib2.0-02.48.0-1
> ii  libgtk-3-0  3.18.9-1
> ii  libsdl2-2.0-0   2.0.4+dfsg1-2+b1
> ii  libstdc++6  5.3.1-14
> ii  zlib1g  1:1.2.8.dfsg-2+b1
>
> nestopia recommends no packages.
>
> nestopia suggests no packages.
>
> -- no debconf information
>
>
> -- Forwarded message --
> From: Stephen Kitt 
> To: 822436-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 09 Sep 2017 11:04:58 +
> Subject: Bug#822436: fixed in nestopia 1.48-1
> Source: nestopia
> Source-Version: 1.48-1
>
> We believe that the bug you reported is fixed in the latest version of
> nestopia, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 822...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Stephen Kitt  (supplier of updated nestopia package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Format: 1.8
> Date: Sat, 09 Sep 2017 12:01:44 +0200
> Source: nestopia
> Binary: nestopia libretro-nestopia
> Architecture: source
> Version: 1.48-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Games Team 
> Changed-By: Stephen Kitt 
> Description:
>  libretro-nestopia - libretro wrapper for Nestopia
>  nestopia   - Nintendo Entertainment System/Famicom emulator
> Closes: 822436 860427
> Changes:
>  nestopia (1.48-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Copy Appstream metadata from Ubuntu, thanks to Jeremy Bicha (Closes:
>  #860427).
>* Update watch file.
>* Document that Nestopia requires OpenGL 3.2 or later (Closes:
>  #822436).
>* Enable PIE.
>* Switch to https URL in debian/copyright.
>* Standards-Version 4.1.0, no further change required.
>* Preserve CPPFLAGS when building libretro (so the hardening options
>  are applied).
> Checksums-Sha1:
>  9c40f6ad3c662e51f72c1ff55b94fe859d556e9b 2093 nestopia_1.48-1.dsc
>  5e1938241cdac92bae05fb68ba950ba045b934aa 1263143
> nestopia_1.48.orig.tar.gz
>  800858eb2dd7d38cb6eb457a79da77c03777217b 10184
> nestopia_1.48-1.debian.tar.xz
>  88466a4085cf1ae7894a374dc9c6e67823987a90 14993 nestopia_1.48-1_source.
> buildinfo
> Checksums-Sha256:
>  945681dd6af6751ae36720d4e0f107dc112db6bf2ec364113c5efffc02e9db4c 2093
> nestopia_1.48-1.dsc
>  

Bug#807956: RFP: doctl -- official DigitalOcean services CLI tool

[Iain R. Learmonth]

retitle 807956 RFP: doctl -- official DigitalOcean services CLI tool
noowner 807956
kthxbye

Hi,

I'm not going to have the time for this.

There's a lot of dependencies as far as I've seen.

Thanks,
Iain.

Bug#868269: Regression from jessie to stretch in handling of %u, %U, %s, and %h

[Josh Triplett]

On Sun, Sep 10, 2017 at 01:43:09AM +0200, Michael Biebl wrote:
> On Thu, 13 Jul 2017 15:09:29 -0700 Josh Triplett 
> wrote:
> > Package: systemd
> > Version: 233-10
> > Severity: normal
> > 
> > I'm not suggesting a change here, but I do think this could use
> > documentation in the release notes and NEWS.Debian file.
> > 
> > Commit 79413b673b45adc98dfeaec882bbdda2343cb2f9 in systemd 228 (between
> > jessie and stretch) effectively broke/disabled the %u, %U, %s and %h
> > specifiers in units.  I ran into this with a local unit that used %u,
> > which went from expanding to the value of User to expanding to "root".
> > It took quite a bit of investigating to figure out the cause.
> > 
> > At a minimum, I would suggest adding something to the stretch release
> > notes about this, as well as a NEWS.Debian entry.
> > 
> > You might also consider, in your next stretch-proposed-updates upload,
> > including the same NEWS.Debian entry.
> 
> While I'm a bit wary of the inflationary use of NEWS.Debian, I'd be ok
> with adding a NEWS entry if one was provided in this case.
> Josh, would you be willing to write such a text?

Sure. How does this look?

systemd 228 changed the behavior of the %u, %U, %s, and %h specifiers.
They were previously documented as returning the user name, numeric user
ID, shell, and home directory of the user configured to run a unit.
However, PID 1 cannot safely perform lookups in the username database,
due to NSS; thus, these directives already did not work consistently for
non-root users. In particular, %u and %U would only resolve whichever of
a name or UID was configured via the User= directive.

In systemd 228 and later, these directives always return the information
for the user running systemd (root for the system instance), not the
unit's configured user. Units shipped by Debian do not use these
directives. Please update any local units that use these directives.

For instanced units that use the instance name as the user, substitute
that instance name for %u. For other units, substitute the appropriate
information directly, or run a script at launch time that looks up the
desired information.

Bug#875258: [scim] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: scim
Version: 1.4.18-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875257: [scidavis] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: scidavis
Version: 1.D13-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#871490: mention how to force listing of /var/lib/systemd/coredump

[Michael Biebl]

On Tue, 08 Aug 2017 18:55:06 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson
 wrote:
> Package: systemd-coredump
> Version: 234-2
> Severity: wishlist
> File: /usr/share/man/man1/coredumpctl.1.gz
> 
> Man page says
> 
>It's worth noting that different restrictions apply to data saved
>in the journal and core dump files saved in
>/var/lib/systemd/coredump, see overview in systemd-coredump(8).
>Thus it may very well happen that a particular core dump is still
>listed in the journal while its corresponding core dump file has
>already been removed.
> 
> 
> OK, but do mention how to make it list these three coredumps.
> 
> # coredumpctl
> No coredumps found.
> # coredumpctl -D /var/lib/systemd/coredump/ list
> No journal files were found.
> No coredumps found.
> # ls -l /var/lib/systemd/coredump/
> -rw-r-+ 1 root root 4286231 07-30 18:23 
> core.epiphany.1000.2ba5facaef5c407da86c3f02f72dd40f.1714.150141021600.lz4
> -rw-r-+ 1 root root 8430257 07-30 21:45 
> core.midori.1000.2ba5facaef5c407da86c3f02f72dd40f.13367.150142234700.lz4
> -rw-r-  1 root root  664045 07-30 18:34 
> core.udisksd.0.2ba5facaef5c407da86c3f02f72dd40f.363.150141089400.lz4

coredumpctl afaik uses the journal to look up coredump entries.
Do the coredumps show up in the journal?
Have you enabled persistent journal or not?


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



signature.asc
Description: OpenPGP digital signature

Bug#875256: RFS: klatexformula/4.0.0-1

[Tobias Winchen]

Package: sponsorship-requests
Severity: normal 

Dear mentors,

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

* Package name: klatexformula
   Version : 4.0.0-1
   Upstream Author : Philippe Faist 
* URL :  http://klatexformula.sourceforge.net/
* License : GPL-2+
   Section : tex

  It builds those binary packages:

klatexformula - GUI to easily get an image from a LaTeX formula or 
equation
 libklatexformula4 - Runtime libraries for klatexformula
 libklatexformula4-dev - Runtime libraries for klatexformula, development files

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/k/klatexformula/
klatexformula_4.0.0-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

   * New upstream release
   * Updated to standards version 4.0.0
   * Added dependency on libqt5sql5-sqlite (Closes: #872717)


  Regards,
   Tobias Winchen

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

Bug#739051: systemd: does not align the OK printouts

[Michael Biebl]

Control: tags -1 + unreproducible

On Thu, 22 Dec 2016 10:59:13 +0100 Salvo Tomaselli 
wrote:
> Still there, for a short while. Then it resets and looks normal. But it
> then shuts down so i don't know if they are the same lines or new ones.

I was never able to reproduce the issue. Can you provide steps how to
trigger that issue?

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



signature.asc
Description: OpenPGP digital signature

Bug#481678: just use python3 and all is well

[Adam Borowski]

Control: severity -1 normal

This bug makes eyed3 useless unless every single of tags in your files is
entirely in ASCII.  This might be the case for an American or such, but us
dirty foreigners are unhappy about it.

But, it turns out this bug goes away if you, as suggested by upstream, use
python3 instead of 2.  As our python team also wants python2 dead, this
sounds like an easy way.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#868269: Regression from jessie to stretch in handling of %u, %U, %s, and %h

[Michael Biebl]

On Thu, 13 Jul 2017 15:09:29 -0700 Josh Triplett 
wrote:
> Package: systemd
> Version: 233-10
> Severity: normal
> 
> I'm not suggesting a change here, but I do think this could use
> documentation in the release notes and NEWS.Debian file.
> 
> Commit 79413b673b45adc98dfeaec882bbdda2343cb2f9 in systemd 228 (between
> jessie and stretch) effectively broke/disabled the %u, %U, %s and %h
> specifiers in units.  I ran into this with a local unit that used %u,
> which went from expanding to the value of User to expanding to "root".
> It took quite a bit of investigating to figure out the cause.
> 
> At a minimum, I would suggest adding something to the stretch release
> notes about this, as well as a NEWS.Debian entry.
> 
> You might also consider, in your next stretch-proposed-updates upload,
> including the same NEWS.Debian entry.

While I'm a bit wary of the inflationary use of NEWS.Debian, I'd be ok
with adding a NEWS entry if one was provided in this case.
Josh, would you be willing to write such a text?

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



signature.asc
Description: OpenPGP digital signature

Bug#875255: [pelican] Provide version of packege under Python 3

[Vladislav]

Package: pelican
Version: 3.7.1
Severity: wishlist

--- Please enter the report below this line. ---
Hello.
I suggest to make, when there will be a time, a Python 3 version of Pelican.
Now it's installed into "/usr/local/lib/python2.7/dist-packages" (or the 
same, but "site-packages").


Reasons:
- Python 3 is the current branch of Python, using Python 2 has no 
benefits before 3;
- When writing custom building scripts, sometimes it's useful to import 
configuration / Pelican modules.
  To avoid possible problems, it would be better to use that version of 
python, on which they're written.
  (for example, by default, python2's dist-packages are not found by 
pyhon3, or errors with code )
- User could install Python 3 version via "sudo pip3 install pelican", 
pelican module and it's dependencies will be installed into
  "/usr/lib/python3/dist-packages", "pelican" and "pelican-quickstart" 
scripts will be located in "/usr/local/bin", all will work, but
  it can give errors to apt \ pip, when somebody will remove other's 
package.


Maybe it would be better to remove Python 2 Pelican package, I don't 
know. Anyway, all new projects is recommended to
start with Python 3, so I don't see many reasons to keep Python 2 
version of pelican.

Just for current his users, who wrote custom scripts, which use it.

Best regards,
Vladislav.

--- System information. ---
Architecture:
Kernel: Linux 4.12.0-1-amd64

Debian Release: buster/sid
500 unstable ftp.ua.debian.org
150 stable dl.google.com
150 betsy linux-mint.froonix.org
150 betsy extra.linuxmint.com
149 zesty ppa.launchpad.net
149 yakkety ppa.launchpad.net
149 xenial ppa.launchpad.net
149 trusty ppa.launchpad.net
149 stable kxstudio.linuxaudio.org
149 lucid ppa.launchpad.net
1 experimental ftp.ua.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#875153: [qtruby] Future Qt4 removal from Buster

[Scott Kitterman]

On Saturday, September 09, 2017 11:08:15 PM Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Source: qtruby
> Version: 4:4.14.3-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced]
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support]
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there
> are suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and
> we know for sure that porting stuff from Qt4 to Qt5 is much much easier and
> less painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges]
> whenever you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers

No rdepends, so went ahead and requested removal.

Scott K

Bug#874727: libcoin80v5: Program using libcoin80v5 and any other library that uses lebexpat1 segfaults.

[mlampert]

Hi,

it breaks FreeCAD, the current version in Debian testing (0.16) and the next 
version (0.17) which is currently under development.

Steps to reproduce in FreeCAD 0.16:
* open new file
* create a box (or some other part)
* switch to Path workbench and create a project
* edit tool table
* if you don't already have a tool table xml file add a tool and "Export" the 
tool table
* "Import" the tool table -> segfault

HTH,
Markus


On Sat, 9 Sep 2017 22:11:47 +0200
Anton Gladky  wrote:

> tags 874727 +moreinfo
> severity 874727 important
> thanks
> 
> Hi,
> 
> thank you for the bugreport. Please provide some more information,
> what packages in Debian are affected.
> 
> Thanks
> 
> Anton
> 
> 
> 2017-09-09 11:33 GMT+02:00 markus :
> > Package: libcoin80v5
> > Version: 3.1.4~abc9f50+dfsg1-2
> > Severity: critical
> > Justification: breaks unrelated software
> >
> > Dear Maintainer,
> >
> > Due to the change in libexpat1 (since 2.2.0, currently at 2.2.3)
> > the included copy of it in libcoin results in segfaults of any
> > program that uses libexpat1. Specifically any program that uses xml
> > from python and links against libcoin will segfault.
> >
> > The stacktrace looks like it is a problem with libexpat1 leading to
> > a segfault in XML_SetHashSalt - however looking at that function
> > there is no way it could possibly segfault - unless of course the
> > provided XMLParser pointer does not actually point to what expat
> > expects to be an XMLParser - which is indeed the case because the
> > XMLParser instance was created by a call into lobcoin which is
> > still on libexpat 2.2.0.  

Bug#875254: RM: qtruby -- ROM; Obsolete: depends on Qt4 which is being removed

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

See #875153.  Qt4 is going to go away and if there are Qt5 based Ruby bindings
in the future, they will be a totally different package, so this should just
be removed (no rdepends).

Scott K

Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

[Roberto Oliveira]

On Sat, 9 Sep 2017 00:00:30 +0500 Andrey Rahmatullin  wrote:
> On Fri, Sep 08, 2017 at 03:48:10PM -0300, Roberto Oliveira wrote:
> > > W: oprofile-jit: package-has-unnecessary-activation-of-ldconfig-trigger
> > oprofile-jit installs a file under /etc/ld.so.conf.d/ that allows
> > oprofile finds the jvmti_oprofile when profiling Jited codes.
> > So I think we need to activate the ldconfig trigger so ldconfig
> > reloads it cache.
> In that case please override this warning and write a comment describing
> the reason.
Fixed.

> libopagent1 should be Section: libs.
Fixed.

> --
> WBR, wRAR

Bug#874718: debchange doesn't allow empty changelog entry

[Adam D. Barratt]

Control: retitle -1 dch "" should not create maintainer header
Control: tags -1 + patch

On Sun, 2017-09-10 at 07:37 +0900, Osamu Aoki wrote:
> control: retitle -1 dch -u "" creates undesired changelog entry
> 
> Hi,
> 
> On Sat, Sep 09, 2017 at 10:22:14AM +0100, Adam D. Barratt wrote:
[...]
On Sat, 2017-09-09 at 15:08 +0900, Osamu Aoki wrote:
> > > If "" is the text to be added to the changelog, debchange skips
> > > making line
> > > with "*".  This seems to intentional design decision of debchange
> > > which I have
> > > no idea why.  (Code logic around it is a bit complicated.  So I
> > > may
> > > be wrong)
> > 
> > [...]
> > > If no objection, I will try to update debchange.
> > 
> > The changelog says why:
> > 
> > + Allow an explicit empty changelog entry to be passed on the
> > command line
> >   to allow non-interactive changes to the distribution and
> > urgency without
> >   adding a changelog entry (Closes: #442267)
> 
> Thanks for a pointer. 
> 
> > Is what you're looking for a valid changelog stanza that doesn't
> > contain an actual message? If so, would "dch ' '" suffice? (It
> > doesn't
> > add a space after the "*", and I can't remember if that's
> > intentional,
> > but it _does_ produce a changelog that dpkg-parsechangelog is happy
> > with.)
> 
> OK I didn't realize white space trick.  I was using null string.
> So now I know the solution for uupdate but still see issues with
> debchange.
> 
> This null string as argument is supposed to avoid interactive session
> like the case without text while not adding any extra line like space
> as
> text.
> 
>  $ dch -u high ""
> 
> This should simply update urgency.  But it doesn't do so.
[...]
> +  [ Osamu Aoki ]
> +

Right, yes, that looks like a bug indeed. I was about to suggest adding
--nomultimaint to your invocation in order to suppress it, but realised
that won't work - and is even documented as such. :-(

>From a quick test, I think this will work:

diff --git a/scripts/debchange.pl b/scripts/debchange.pl
index b44b9633..444bb399 100755
--- a/scripts/debchange.pl
+++ b/scripts/debchange.pl
@@ -1411,7 +1411,7 @@ if (($opt_r || $opt_a || $merge) && ! $opt_create) {
 
 if (! $opt_r) {
# Add a multi-maintainer header...
-   if ($multimaint) {
+   if ($multimaint and not $EMPTY_TEXT) {
# ...unless there already is one for this maintainer.
if (!defined $maintline) {
print O "\n  [ $MAINTAINER ]\n";

(an alternative would be having the preceding checks skip the block
that potentially sets $multimaint to 1 if $EMPTY_TEXT is set)

Regards,

Adam

Bug#874983: [konsole4] Future Qt4 removal from Buster

[Scott Kitterman]

On Sat, 9 Sep 2017 21:32:11 +0200 Lisandro 
=?iso-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer  wrote:
> Source: konsole4
> Version: 4:4.14.2-4
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there 
are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and 
we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and 
less
> painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges] 
whenever
> you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers

Can be removed one the new kile is released/packaged.

Scott K

Bug#874966: [kile] Future Qt4 removal from Buster

[Scott Kitterman]

On Sat, 9 Sep 2017 21:31:34 +0200 Lisandro 
=?iso-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer  wrote:
> Source: kile
> Version: 4:2.1.3-4
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there 
are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and 
we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and 
less
> painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges] 
whenever
> you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers

There is a beta Qt5 version available:

https://kile.sourceforge.io/download.php

This is the only pacakge that prevents removal of konsole4 (konsole4-kpart).

Scott K

Bug#874494: rebuilding libsambox-java generates unmet dependency on libsejda-io-java (>= 1.1.3.RELEASE)

[Emmanuel Bourg]

Control: reassign -1 libsejda-io-java
Control: affects -1 libsambox-java
Control: tags -1 + patch

Le 9/09/2017 à 19:53, Markus Koschany a écrit :

> thanks for the patch. However we can just remove the
> --has-package-version option in libsambox-java.poms which will have the
> same effect. This issue was caused by a recent change in
> maven-debian-helper and affects multiple packages.

The --has-package-version flag in libsambox-java is fine. It's the one
in libsejda-io-java that isn't consistent with the pom version, sorry if
this wasn't clear. The patch proposed is a good solution.

Bug#874718: debchange doesn't allow empty changelog entry

[Osamu Aoki]

control: retitle -1 dch -u "" creates undesired changelog entry

Hi,

On Sat, Sep 09, 2017 at 10:22:14AM +0100, Adam D. Barratt wrote:
> [You appear to have filed this bug 3 times. Maybe you want to close
> #874717 and #874716?]

I guess I need to fix my mailer set up.
(This mail may be tripled.)
I will close duplicates.
 
> On Sat, 2017-09-09 at 15:08 +0900, Osamu Aoki wrote:
> > If "" is the text to be added to the changelog, debchange skips
> > making line
> > with "*".  This seems to intentional design decision of debchange
> > which I have
> > no idea why.  (Code logic around it is a bit complicated.  So I may
> > be wrong)
> [...]
> > If no objection, I will try to update debchange.
> 
> The changelog says why:
> 
> + Allow an explicit empty changelog entry to be passed on the command line
>   to allow non-interactive changes to the distribution and urgency without
>   adding a changelog entry (Closes: #442267)

Thanks for a pointer. 

> Is what you're looking for a valid changelog stanza that doesn't
> contain an actual message? If so, would "dch ' '" suffice? (It doesn't
> add a space after the "*", and I can't remember if that's intentional,
> but it _does_ produce a changelog that dpkg-parsechangelog is happy
> with.)

OK I didn't realize white space trick.  I was using null string.
So now I know the solution for uupdate but still see issues with
debchange.

This null string as argument is supposed to avoid interactive session
like the case without text while not adding any extra line like space as
text.

 $ dch -u high ""

This should simply update urgency.  But it doesn't do so.

Please look into attached tared git repository with test case results.
Look at branch osamu-null-u.  All but test01 cases create bad changelog
entry.  The following type of addition should not happen.

+  [ Osamu Aoki ]
+

Regards,

Osamu



dch-tests.tar.xz
Description: application/xz

Bug#871664: Same issue here

[Jean-Francois Pirus]

I also use the CardBook plugin and found this fixed the issue:

> In CardBook preferences, first tab, check “Unique source for contacts”

This if from the CardBook support forums: 
https://cardbook.6660.eu/troubleshooting/

Bug#874394: [gul-info] Bug#874394: debian mirror ftp.gul.uc3m.es issues

[Axel Blanco]

Hello.

We have been facing several issues with our disks, but it looks that they
are fixed for now. The next scheduled execution of rsync has worked.

In any case, we keep an eye on it by the upcoming weeks.

(We have also updated our ftpsync script for now)

El vie., 8 sept. 2017 a las 17:13, Peter Palfrader ()
escribió:

> On Mon, 04 Sep 2017, Roberto Muñoz wrote:
>
> > Thanks for the report.
> > We are aware the the mirror is failing. We are migrating our servers to a
> > new datacenter so it should be up and running today or so.
>
> According to
> http://ftp.gul.uc3m.es/debian/project/trace/ftp.gul.uc3m.es
> your site hasn't successfully completed a mirror run in over a week.
> Do you know what's going on?
>
> (Also, that ftpsync version looks old, please update.)
>
> --
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/
> ___
> Info-list mailing list
> info-l...@gul.uc3m.es
> http://gul.uc3m.es/cgi-bin/mailman/listinfo/info-list
>
-- 
Axel Blanco.
Presidente del Grupo de Usuarios de Linux (GUL UC3M)
gul.es ||  i...@gul.uc3m.es

Bug#874858: [edfbrowser] Future Qt4 removal from Buster

[Teunis van Beelen]

Hi,

EDFbrowser compiles fine with both Qt 5.6.1 that comes with Opensuse Leap
42.2 as well
with the latest Qt 5.9.1 compiled from the official Qt vanilla source.

Some serious bugs are present in Qt 5, specially in the Qt 5.6.x series.
Qt 5.9.1 seems to be better but still not as good as Qt 4.8.7.

Qt5 is a "non-blocking" framework, it's released with lots of blocking P0
and P1 bugs:

https://bugreports.qt.io/browse/QTBUG-61717?filter=18388=project%20%3D%
20QTBUG%20AND%20priority%20in%20(%22P0%3A%20Blocker%22%2C%
20%22P1%3A%20Critical%22)%20AND%20resolution%20%3D%20Unresolved%20AND%
20affectedVersion%20in%20(releasedVersions()%2C%205.9.1)
%20ORDER%20BY%20key%20DESC

http://blog.qt.io/blog/2017/05/31/qt-5-9-released/

Have you seen any compile errors with EDFbrowser & Qt5 on Debian?
Let me know if there are any issues.

Kind Regards,

Teunis





On Sat, Sep 9, 2017 at 9:59 PM, Andreas Tille  wrote:

> control: forwarded -1 https://github.com/Teuniz/EDFbrowser/issues/30
> control: tags -1 upstream
>
> Hi Teunis,
>
> I added some comment to Github issue 30 about Qt5 migration.  It would be
> great if you could put some emphasis on it.
>
> Kind regards
>
>Andreas.
>
> On Sat, Sep 09, 2017 at 09:03:58PM +0200, Lisandro Damián Nicanor Pérez
> Meyer wrote:
> > Source: edfbrowser
> > Version: 1.58-1
> > Severity: wishlist
> > User: debian-qt-...@lists.debian.org
> > Usertags: qt4-removal
> >
> >
> > Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> > as [announced] in:
> >
> > [announced]  msg6.html>
> >
> > Currently Qt4 has been dead upstream and we are starting to have problems
> > maintaining it, like for example in the [OpenSSL 1.1 support] case.
> >
> > [OpenSSL 1.1 support]  bin/bugreport.cgi?bug=828522>
> >
> > In order to make this move, all packages directly or indirectly
> depending on
> > the Qt4 libraries have to either get ported to Qt5 or eventually get
> > removed from the Debian repositories.
> >
> > Therefore, please take the time and:
> > - contact your upstream (if existing) and ask about the state of a Qt5
> > port of your application
> > - if there are no activities regarding porting, investigate whether
> there are
> > suitable alternatives for your users
> > - if there is a Qt5 port that is not yet packaged, consider packaging it
> > - if both the Qt4 and the Qt5 versions already coexist in the Debian
> > archives, consider removing the Qt4 version
> >
> > = Porting =
> >
> > Some of us where involved in various Qt4 to Qt5 migrations [migration]
> and we
> > know for sure that porting stuff from Qt4 to Qt5 is much much easier and
> less
> > painful than it was from Qt3 to Qt4.
> >
> > We also understand that there is still a lot of software still using Qt4.
> >
> > Don't forget to take a look at the C++ API changes page [apichanges]
> whenever
> > you start porting your application.
> >
> > [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> > [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> >
> > For any questions and issues, do not hesitate to contact the Debian
> Qt/KDE
> > team at debian-qt-...@lists.debian.org
> >
> > The removal is being tracked in 
> >
> > Lisandro,
> > on behalf of the Qt4 maintainers
> >
> > ___
> > Debian-med-packaging mailing list
> > debian-med-packag...@lists.alioth.debian.org
> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/
> debian-med-packaging
> >
>
> --
> http://fam-tille.de
>



-- 
"C'è qualcosa nella nebbia! Qualcosa nella nebbia ha preso John Lee!"

Bug#872266: [pkg-apparmor] Bug#872266: apparmor-profiles-extra: Disable profiles before uninstalling them

[Christian Boltz]

Hello,

Am Samstag, 9. September 2017, 20:24:40 CEST schrieb intrigeri:
> Clément Hermann:
> > apparmor profiles should be removed with `apparmor_parser -R
> > ` before uninstallation (prerm).
> 
> Agreed, good catch. I'm not sure if we want to do that only when
> purging, or on "normal" removal as well. What do you think?
> 
> Ubuntu/OpenSUSE people, what do you think about 1. the general idea of
> unloading profiles when de-installing the package that ships them; 

TL;DR: I'd strongly recommend *not* to unload profiles when de-installing 
a package.

Both unloading and not unloading a profile can cause trouble, so let me 
describe both situations:

If you don't unload the profile on package uninstall, there's a risk that 
the profile gets accidently applied to a newly installed binary with the 
same path. An example might be /usr/sbin/sendmail when replacing 
sendmail with postfix. (Note that I didn't check if there's a profile for 
this binary, it's just one of the very few examples I can think of.)
An additional condition is that the new package doesn't include an 
AppArmor profile - otherwise the still-loaded profile would be replaced.
So all in all, this can happen, but is very unlikely IMHO.

OTOH, if you unload a profile, and a program from this package is still 
running, unloading the profile means to remove the confinement from the 
running program. In other words: the still-running program can now do 
whatever it wants.

I prefer to error out on the safe side, therefore I recommend not to 
unload profiles on package uninstallation. The security risks this 
prevents clearly outweight the (unlikely) problems with still-loaded 
profiles.


BTW: I assume there isn't a "killall -9" for every binary shipped in the 
package in prerm, right? ;-) Unloading the profiles wouldn't be too 
different to that IMHO.

> 2. unload on removal vs. on purge?

Sorry, EWRONGPACKAGEMANAGER ;-)


Regards,

Christian Boltz
-- 
Last I checked, developers were still human
[Bryen M Yunashko in opensuse-project]


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

Bug#875253: quassel-client: Sometimes acts as if mouse button is held down, when it is not

[James Valleroy]

Package: quassel-client
Version: 1:0.12.4-2
Severity: important

Dear Maintainer,

* What led up to the situation?

I am using Gnome. I started the quassel client. It connected to the
configured default core.

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

Using the touchpad, I moved the mouse pointer around inside the
quassel client window, without touching either touchpad button, and
without tapping the touchpad.

* What was the outcome of this action?

Quassel behaves as if the left mouse button is held down. It will
select rows of text in the chat history or channel list. This makes it
impossible to correctly navigate the interface while using a touchpad.

* What outcome did you expect instead?

Since left mouse button is not pressed, I should be able to freely
move the mouse pointer around inside the window, and Quassel should
not take any action.

I have not seen this issue in any other application. In particular, I
have been using Firefox, Emacs, Terminal, and Thunderbird, and only
saw this issue in Quassel.


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

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

Versions of packages quassel-client depends on:
ii  dbus-x11  1.10.18-1
ii  libc6 2.24-11+deb9u1
ii  libdbusmenu-qt5-2 0.9.3+16.04.20160218-1
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5notifications5  5.28.0-1
ii  libkf5notifyconfig5   5.28.0-1
ii  libkf5sonnetui5   5.28.0-2
ii  libkf5textwidgets55.28.0-1
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5xmlgui5 5.28.0-1
ii  libphonon4qt5-4   4:4.9.0-4
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5dbus5   5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5network55.7.1+dfsg-3+b1
ii  libqt5webkit5 5.7.1+dfsg-1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18
ii  phonon4qt54:4.9.0-4
ii  quassel-data  1:0.12.4-2
ii  zlib1g1:1.2.8.dfsg-5

quassel-client recommends no packages.

quassel-client suggests no packages.

-- no debconf information

Bug#869116: kcharselect segfaults

[Sakarah]

Hi Stuart,

A new version (4:16.08.0-1+b1) has been published recently and it solves 
the problem without touching at-spi2-core.


Thanks a lot,
Guillaume

Bug#875058: [mumble] Future Qt4 removal from Buster

[Chris Knadle]

Lisandro Damián Nicanor Pérez Meyer:
> Source: mumble
> Version: 1.2.18-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 

I'm aware.
I also got another bug on this a little while ago #874683 about the same
thing.

> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application

mumble 1.3.x that works with QT5 isn't released yet and they don't want
me to upload a package to Debian until it is. I was specifically
requested not to upload snapshots.

Also mumble 1.3.x source contains unreleasable files -- these get
stripped out by upstream's release scripts which need updating for the
new version, which hasn't been done because 1.3.x is not quite ready for
release.

I'll discuss this with upstream.

  -- Chris

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

Bug#723548: smstools link with -L/usr/lib

[Thorsten Alteholz]

Hi,

according to newer build logs[1] this package seems to build on mips64el 
now. So can this bug be closed?


  Thorsten


[1] https://buildd.debian.org/status/package.php?p=smstools=sid

Bug#875250: [scim] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: scim
Version: 1.4.18-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875249: (no subject)

[Francisco Vilmar Cardoso Ruviaro]

Subject: RFP: cpdf -- provide a wide range of facilities for modifying PDF files
Package: wnpp
Severity: wishlist

* Package name: cpdf
  Version : 2.2.1
  Upstream Author : John Whitington 
* URL : https://github.com/johnwhitington/cpdf-source
* License : Coherent Graphics Ltd Non-Commercial Use License
  Programming Lang: OCaml
  Description : provide a wide range of facilities for modifying PDF files

 The tool provide a wide range of facilities for modifying PDF files created by 
other means.
 There is a single command-line program cpdf.

Bug#875251: [scidavis] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: scidavis
Version: 1.D13-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#868154: reportbug: displays MIME type of attachment

[Nis Martensen]

control: tags -1 patch

On 12 Jul 2017 Thorsten Glaser wrote:
> I think the “application/x-xz; charset=binary” line should go
> elsewhere, perhaps into the eMail?

It is the output of a debug print() inserted while porting the code to
python 3. It can just be dropped. Patch attached.
>From bf3724a200d9db947c77c1d9ce0eb61536a0bade Mon Sep 17 00:00:00 2001
From: Nis Martensen 
Date: Sat, 9 Sep 2017 23:41:48 +0200
Subject: [PATCH 3/3] Drop leftover debug print()

---
 reportbug/submit.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/reportbug/submit.py b/reportbug/submit.py
index 4940538..1eb1b71 100644
--- a/reportbug/submit.py
+++ b/reportbug/submit.py
@@ -147,7 +147,6 @@ def mime_attach(body, attachments, charset, body_charset=None):
 cset = charset
 info = Popen(['file', '--mime', '--brief', attachment],
  stdout=PIPE, stderr=STDOUT).communicate()[0].decode('ascii')
-print(info)
 if info:
 match = re.match(r'([^;, ]*)(,[^;]+)?(?:; )?(.*)', info)
 if match:
-- 
2.11.0

Bug#874916: [imagevis3d] Future Qt4 removal from Buster

[Andreas Tille]

control: forwarded -1 https://github.com/SCIInstitute/ImageVis3D/issues/8
control: tags -1 upstream

Hi,

I have opened an issue on Github (#8) that a Qt5 port would be helpful
to keep the imagevis3d package inside Debian.  

Kind regards

 Andreas.

On Sat, Sep 09, 2017 at 09:06:38PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: imagevis3d
> Version: 3.1.0-5
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
> painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges] whenever
> you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#875248: gnome: severe graphical glitches

[Ramiro Lopes]

Package: gnome
Version: 1:3.22+3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I'm experiencing severe graphical glitches on Gnome and Gdm3 that render
the environment unusable. Borders of windows remain on screen, blinking, after
moving, and typing on terminals is a mess, full of glitches that make it
impossible to see the characters. Menus show highliting and blinking of
several items when hovering over them. Chromium works fine though.

Videos show this better than pictures, here are a couple:
https://photos.app.goo.gl/lgTsHKLZhBa3SaF83
https://photos.app.goo.gl/m2Dj4XYP79q0fSTJ2

I'm using Fluxbox for now which works perfectly, showing no glitches,
whatsoever.

I updated my system from Jessie to Stretch and I believe this started after
 an upgrade, but not the dist-upgrade though. I tried reverting all packages
but that did not help.

System running on current Stretch versions of all packages.
Xorg with no custom configurations.

Hardware: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, 
Inc. [AMD/ATI] Turks XT [Radeon HD 6670/7670] [1002:6758]
Driver: xserver-xorg-video-radeon 1:7.8.0-1+b1

I'm not sure if this is a Gnome, Xorg, Radeon bug...

Any help is appreciated.


PS.: I just would like to let you know that I'm an experienced Linux user, and
I have been using it for 20 years on several computers, servers, laptop etc.
I can provide you with any information you need and perform any tests you
suggest. I googled for similar problems but I haven't found any.



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

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

Versions of packages gnome depends on:
ii  avahi-daemon 0.6.32-2
ii  cheese   3.22.1-1+b1
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 9.0.2
ii  evolution3.22.6-1
ii  evolution-plugins3.22.6-1
ii  file-roller  3.22.3-1
ii  gedit-plugins3.22.0-1
ii  gimp 2.8.18-1
ii  gnome-calendar   3.22.4-2
ii  gnome-clocks 3.22.1-1
ii  gnome-color-manager  3.22.2-1
ii  gnome-core   1:3.22+3
ii  gnome-dictionary 3.20.0-3+b1
ii  gnome-documents  3.22.1-1
ii  gnome-getting-started-docs   3.22.0-1
ii  gnome-maps   3.22.2-1
ii  gnome-music  3.22.2-1
ii  gnome-orca   3.22.2-3
ii  gnome-photos 3.22.5-1
ii  gnome-screenshot 3.22.0-1+b1
ii  gnome-sound-recorder 3.21.92-2
ii  gnome-tweak-tool 3.22.0-1
ii  gnome-weather3.20.2-1
ii  gstreamer1.0-libav   1.10.4-1
ii  gstreamer1.0-plugins-ugly1.10.4-1
ii  inkscape 0.92.1-1
ii  libgsf-bin   1.14.41-1
ii  libgtk2-perl 2:1.2499-1
ii  libproxy1-plugin-networkmanager  0.4.14-2
ii  libreoffice-calc 1:5.2.7-1
ii  libreoffice-evolution1:5.2.7-1
ii  libreoffice-gnome1:5.2.7-1
ii  libreoffice-impress  1:5.2.7-1
ii  libreoffice-writer   1:5.2.7-1
ii  nautilus-sendto  3.8.4-2+b1
ii  network-manager-gnome1.4.4-1
ii  rhythmbox3.4.1-2+b1
ii  rhythmbox-plugin-cdrecorder  3.4.1-2+b1
ii  rhythmbox-plugins3.4.1-2+b1
ii  rygel-playbin0.32.1-3
ii  rygel-tracker0.32.1-3
ii  seahorse 3.20.0-3.1
ii  simple-scan  3.23.2-1
ii  totem-plugins3.22.1-1
ii  vinagre  3.22.0-1+b1
ii  xdg-user-dirs-gtk0.10-1+b1

Versions of packages gnome recommends:
ii  brasero   3.12.1-4
ii  gnome-games   1:3.22+3
ii  polari3.22.2-1
ii  transmission-gtk  2.92-2

Versions of packages gnome suggests:
ii  alacarte 3.11.91-2
ii  empathy  3.12.12-4
pn  firefox-esr-l10n-all | firefox-l10n-all  
ii  goobox   3.4.2-3
pn  xul-ext-gnome-keyring
pn  xul-ext-ublock-origin

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.22.0-1+deb9u1
ii  at-spi2-core  2.22.0-6
ii  baobab3.22.1-1
ii  caribou   0.4.21-1+b1
ii  chrome-gnome-shell8-4
ii  chromium  60.0.3112.78-1~deb9u1
ii  dconf-cli   

Bug#874851: [clustalx] Future Qt4 removal from Buster

[Andreas Tille]

control: forwarded -1 clust...@ucd.ie
control: tags -1 upstream

Hi,

as you can read below clustalx will be removed from the next Debian
release if it will not be upgraded from Qt4 to Qt5.  It would be a real
shame since it is one of the most frequently used packages in the scope
of bioinformatics.  It would be really great if you could do the upgrade
since its a reasonable assumption that it will be the same in other
linux distributions and users will have trouble to use your fine piece
of software.

Kind regards

 Andreas.

On Sat, Sep 09, 2017 at 09:03:14PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: clustalx
> Version: 2.1+lgpl-5
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
> painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges] whenever
> you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#874877: [freecad] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Hi Martin!


On 9 September 2017 at 18:18, W. Martin Borgert  wrote:
> On 2017-09-09 21:04, Lisandro Damián Nicanor Pérez Meyer wrote:
>> = Porting =
>>
>> Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
>> know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
>> painful than it was from Qt3 to Qt4.
>
> If I understand the various posts in the FreeCAD forums correct,
> they seem to go for PySide2. It would be very helpful, if the
> Debian Qt maintainers could package PySide2! Maybe before Qt4 is
> removed, because otherwise some packages have to be removed just
> to introduce them again. I don't think that packaging PySide2
> outside of the Qt team makes sense, because PySide2 will be the
> "official" Python API of Qt, if I'm not mistaken.
> --
> "Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder

So far no one in the team is interested in PySide2 and our current
manpower does not allows us to even take it as a pet package. I don't
know if asking upstream to use PyQt5 (which is kind of more official)
would be a good idea, else someone needs to step up to maintain
PySide2. Of course [s]he is welcomed in the team to do that!

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#874111: [pkg-gnupg-maint] Bug#874111: dirmngr: Please make dirmngr Multi-Arch: foreign

[Jarek Kamiński]

W dniu 06.09.2017 o 23:47, Daniel Kahn Gillmor pisze:
> Hi Jarek--

Hello Daniel,

> thanks for pointing this out, you're absolutely right.  gpgv-static
> should probably also be marked Multi-arch: foreign as well (though the
> dependencies aren't as much of an issue there, since it's basically a
> leaf package).
> 
> I'll make sure this happens in the next debian release.  sorry i missed
> it for the upload of 2.2.0-1!

Thanks for fixing and for a swift response! Have a nice rest of the
weekend :-)


-- 
pozdr(); // Jarek



signature.asc
Description: OpenPGP digital signature

Bug#875009: [libbpp-qt] Future Qt4 removal from Buster

[Andreas Tille]

control: forwarded -1 Julien Dutheil 
control: tags -1 upstream

Hi Julien,

could you please have a look.

Kind regards

  Andreas.

On Sat, Sep 09, 2017 at 10:08:55PM +0200, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> Source: libbpp-qt
> Version: 2.3.1-4
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced] 
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support] 
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there are
> suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
> painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges] whenever
> you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de

Bug#874873: [pkg-apparmor] Bug#874873: Pick the best AppArmor introduction docs and advertise them better

[Christian Boltz]

Hello,

AppArmor Adminstration Guide

http://www.novell.com/documentation/apparmor/apparmor201_sp10_admin/index.html?page=/documentation/apparmor/apparmor201_sp10_admin/data/book_apparmor_admin.html
looks like a very outdated version of what is the openSUSE Security 
Guide nowadays.

Please replace that link with
openSUSE Security Guide (AppArmor chapter)

https://doc.opensuse.org/documentation/leap/security/html/book.security/part.apparmor.html

I reviewed that chapter two years ago - and its author probably still
hates me for that ;-)

Since then, AppArmor didn't change too much, therefore I'd expect that 
it's still correct and up to date. It also includes a complete reference
to the profile language (as of two years ago, so the "new" rule types 
like dbus and ptrace are still missing).


Regards,

Christian Boltz
-- 
Hmm.. Good point Adrian. I should get used to that thing
close to my keyboard... how did you call it? Mouse? :-)
[Dominique Leuenberger in opensuse-factory]


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

Bug#874683: mumble: please package a QT5 version of mumble

[Chris Knadle]

Daniel Kahn Gillmor:
> Package: mumble
> Version: 1.2.18-1
> Severity: wishlist
> 
> Mumble upstream apparently supports qt5 (at least in the 1.3.0
> prerelease series, i don't know about earlier).
> 
> see for example mentions of a QT5-only patch here:
> 
>https://github.com/mumble-voip/mumble/issues/2728
> 
> and the build instructions here:
> 
>https://wiki.mumble.info/wiki/BuildingLinux#1.3.x
> 
> mumble is one of the few remaining tools that keep me from purging
> qt4.  it'd be great to have a version built against QT5.  maybe use in
> debian experimental since 1.3.x hasn't been released yet?
> 
>--dkg

Hello again, Daniel.

Here's where the mumble package stands:

  - mumble 1.2.x is not compilable with QT5.
  - mumble 1.3.x is compilable with QT4 and QT5
  - After the painful experience when Ron Lee was the maintainer of
the mumble package, upstream requested that I only release stable
releases, and not snapshots.
  - mumble 1.3.x is desirable because with QT5 it supports encryption
modes that provide perfect forward secrecy
  - I've had working packaging prepared for mumble 1.3.x for a long time
(> 1 year)
  - mumble 1.3.x has not yet been released
  - mumble 1.3.x source contains unreleasable files including IETF RFCs
such that building a -dfsg tarball would be needed to upload a
1.3.x version to experimental. I've discussed this problem with
upstream -- their tarball release scripts need to be updated to
strip these unreleasable files, but that work only needs to be done
once a release is ready...
  - I discussed the -dfsg issue with several people at DebConf17 and
some have mentioned using Files-Excluded in debian/copyright and
tweaks to debian/watch to get uscan to build a -dfsg tarball
automatically, which I'm looking into.

I'm aware QT4 needs to be removed from Debian. I can talk to upstream
about this, and see what I can do to create a mumble 1.3.x package that
could be uploaded to experimental. *shrug*

   -- Chris

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

Bug#875123: oce: set LD_LIBRARY_PATH for dh_auto_test

[Steve Langasek]

On Sat, Sep 09, 2017 at 01:38:17PM -0700, Steve Langasek wrote:
> diff -Nru oce-0.17.2/debian/rules oce-0.17.2/debian/rules
> --- oce-0.17.2/debian/rules   2016-06-16 14:02:43.0 -0700
> +++ oce-0.17.2/debian/rules   2017-09-09 12:53:53.0 -0700
> @@ -5,6 +5,9 @@
>  LDFLAGS  := $(shell dpkg-buildflags --get LDFLAGS)
>  
>  DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
> +DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
> +UNAME := $(shell uname -m)
> +DEBUG_PATH := 
> obj-$(DEB_HOST_MULTIARCH)/Unix/$(UNAME)-RelWithDebInfo-$(DEB_HOST_ARCH_BITS)

It appears this actually needs to be DEB_HOST_GNU_TYPE rather than
DEB_HOST_MULTIARCH here - which is generally the same thing, except on i386.

DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_HOST_ARCH_BITS ?= $(shell dpkg-architecture -qDEB_HOST_ARCH_BITS)
UNAME := $(shell uname -m)
DEBUG_PATH := 
obj-$(DEB_HOST_GNU_TYPE)/Unix/$(UNAME)-RelWithDebInfo-$(DEB_HOST_ARCH_BITS)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#875196: [starpu-contrib] Future Qt4 removal from Buster

[Samuel Thibault]

Control: tags -1 + pending

Hello,

For information, the work is already done, starpu-contrib is
just current non-buildable in sid because of CUDA vs gcc/clang.
starpu-contrib is not in testing currently anyway, so it won't block the
removal.

Samuel

Bug#875146: [qt-at-spi] Future Qt4 removal from Buster

[Samuel Thibault]

Hello,

For information, this package is only useful with Qt4 to make it
accessible, it's integrated in Qt5, so qt-at-spi shall just be kept
until all Debian packages have moved to Qt5, and then go away along with
Qt4.

Samuel

Bug#867692: apparmor-profiles-extra: Totem can't open any video

[intrigeri]

Control: tag -1 + pending
Control: tag -1 - moreinfo

Elia Argentieri:
>> > > Then I added this line to /etc/apparmor.d/local/usr.bin.totem:
>> > > >   /var/lib/flatpak/exports/share/icons/** r,
>> > > 
>> > > and that solved all errors. I can now open videos on my home with
>> > > a
>> > > clean audit.log.
>> > Is it *needed* for Totem to work fine for you, once you've granted
>> > it
>> > access to the video files you want to play?
>> 
>> Ping?

> No, it's not needed. It works without that too.

Thanks!

Summary:

 * mounting drives to one of the supported locations will solve the
   first problem;
 * my fix for the second problem was finally merged upstream:
   
https://code.launchpad.net/~intrigeri/apparmor-profiles/+git/apparmor-profiles/+merge/310120
   I've applied this change in Vcs-Git, will upload shortly.

Bug#874877: [freecad] Future Qt4 removal from Buster

[W. Martin Borgert]

On 2017-09-09 21:04, Lisandro Damián Nicanor Pérez Meyer wrote:
> = Porting =
>
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
> know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
> painful than it was from Qt3 to Qt4.

If I understand the various posts in the FreeCAD forums correct,
they seem to go for PySide2. It would be very helpful, if the
Debian Qt maintainers could package PySide2! Maybe before Qt4 is
removed, because otherwise some packages have to be removed just
to introduce them again. I don't think that packaging PySide2
outside of the Qt team makes sense, because PySide2 will be the
"official" Python API of Qt, if I'm not mistaken.
-- 
"Furthermore, I consider that PySide2 must be packaged" -- Qt the Elder

Bug#875244: [zeroconf-ioslave] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: zeroconf-ioslave
Version: 4:16.08.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875245: [xdrawchem] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: xdrawchem
Version: 2.0-6
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875246: [zbar] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: zbar
Version: 0.10+doc-10.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875239: [webkitkde] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: webkitkde
Version: 1.3.4-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875247: evolution-data-server: is a system reboot really required for every package update?

[Julian Gilbey]

Package: evolution-data-server
Version: 3.24.5-6
Severity: normal

Hello!

I was just informed that my system needs a reboot because the
evolution-data-server package has been updated.  Looking at the
postinst script, I see that the reboot notifier is called
on every package update.

Is it *really* the case that *every* update of the
evolution-data-server requires a full system reboot?  If not, then the
reboot notification should be made only on updates which actually
require it.

Best wishes,

   Julian

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

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution-data-server depends on:
ii  evolution-data-server-common  3.24.5-6
ii  gnome-keyring 3.20.1-1
ii  libc6 2.24-17
ii  libcamel-1.2-60   3.24.5-6
ii  libdb5.3  5.3.28-13.1
ii  libebackend-1.2-103.24.5-6
ii  libebook-1.2-19   3.24.5-6
ii  libebook-contacts-1.2-2   3.24.5-6
ii  libecal-1.2-193.24.5-6
ii  libedata-book-1.2-25  3.24.5-6
ii  libedata-cal-1.2-28   3.24.5-6
ii  libedataserver-1.2-22 3.24.5-6
ii  libgcr-base-3-1   3.20.0-5.1
ii  libgcr-ui-3-1 3.20.0-5.1
ii  libgdata220.17.9-1
ii  libglib2.0-0  2.53.6-1
ii  libgoa-1.0-0b 3.25.90-1
ii  libgtk-3-03.22.19-1
ii  libgweather-3-6   3.25.91-1
ii  libical2  2.0.0-0.5+b1
ii  libldap-2.4-2 2.4.45+dfsg-1
ii  libpango-1.0-01.40.11-1
ii  libsecret-1-0 0.18.5-3.1
ii  libsoup2.4-1  2.56.1-1
ii  libxml2   2.9.4+dfsg1-4

evolution-data-server recommends no packages.

Versions of packages evolution-data-server suggests:
ii  evolution  3.24.5-3

-- no debconf information

Bug#875242: [yabause] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: yabause
Version: 0.9.14-2.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875243: [yagf] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: yagf
Version: 0.9.3.2-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875240: [xflr5] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: xflr5
Version: 6.09.06-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875241: [xxdiff] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: xxdiff
Version: 1:4.0.1+dfsg-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875225: [virtualjaguar] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: virtualjaguar
Version: 2.1.2-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875234: [writetype] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: writetype
Version: 1.3.163-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875227: [voxbo] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: voxbo
Version: 1.8.5~svn1246-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875230: [witty] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: witty
Version: 3.3.6+dfsg-1.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875235: [wsjtx] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: wsjtx
Version: 1.1.r3496-3.2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875216: [uim] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: uim
Version: 1:1.8.6+gh20161003.0.d63dadd-4
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875229: [webkit-image] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: webkit-image
Version: 0.0.svn25399-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875237: [xca] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: xca
Version: 1.3.2-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875233: [wpa] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: wpa
Version: 2:2.4-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875238: [vmpk] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: vmpk
Version: 0.4.0-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875226: [viva] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: viva
Version: 1.2-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875236: [x2goclient] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: x2goclient
Version: 4.1.0.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875224: [videocut] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: videocut
Version: 0.2.0-17
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875228: [universalindentgui] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: universalindentgui
Version: 1.2.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875232: [veusz] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: veusz
Version: 1.21.1-1.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875222: [valkyrie] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: valkyrie
Version: 2.0.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875231: [woo] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: woo
Version: 1.0+dfsg1-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875223: [uicilibris] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: uicilibris
Version: 1.13-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875220: [usbguard] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: usbguard
Version: 0.7.0+ds1-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875208: [tora] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: tora
Version: 2.1.3-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875221: [v4l2ucp] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: v4l2ucp
Version: 2.0.2-4
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875213: [txtreader] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: txtreader
Version: 0.6.5-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875212: [swift-im] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: swift-im
Version: 3.0.4-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875214: [udj-desktop-client] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: udj-desktop-client
Version: 0.6.3-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875215: [syncevolution] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: syncevolution
Version: 1.5.2-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers

Bug#875210: [treeline] Future Qt4 removal from Buster

[Lisandro Damián Nicanor Pérez Meyer]

Source: treeline
Version: 1.4.1-1.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 


Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] 

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in 

Lisandro,
on behalf of the Qt4 maintainers