Bug#1032166: do not release in bookworm

[Ana Guerrero Lopez]

On Fri, Mar 03, 2023 at 12:17:28AM +0100, Petter Reinholdtsen wrote:
> [Ana Guerrero Lopez]
> > Please, keep debian-timeline out of bookworm, the installed HTML doesn't
> > show the timeline like it should so the package is useless.
> 
> Are you talking about the issue in #655664?

Yes, that's one of the issues.

Ana

Bug#1032166: do not release in bookworm

[Ana Guerrero Lopez]

Source: debian-timeline
Version: 45
Severity: serious
X-Debbugs-Cc: debian-public...@lists.debian.org

Please, keep debian-timeline out of bookworm, the installed HTML doesn't
show the timeline like it should so the package is useless.

Bug#1032162: RM: debian-timeline/45

[Ana Guerrero Lopez]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: debian-timel...@packages.debian.org, 
debian-public...@lists.debian.org
Control: affects -1 + src:debian-timeline

Please, keep debian-timeline out of bookworm, the installed HTML doesn't
show the timeline like it should so the package is useless.

Thank you,
Ana

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Ana Guerrero Lopez]

On Sat, Oct 09, 2021 at 04:43:37PM +0200, Guillem Jover wrote:
> 
> I think the attached patch is the correct fix. I think I can push to
> the repo, so if no one has any concerns I might do that during the
> weekend.

Thanks Guillem!
The issue seems fixed now, I'm closing this bug.

Ana

Bug#992493: remind: please update to latest version

[Ana Guerrero Lopez]

Hi Jochen,

On Tue, Feb 08, 2022 at 09:56:34PM +0100, Jochen Sprickerhof wrote:
> Hi Ana,
> 
> * Ana Guerrero Lopez  [2021-08-19 13:32]:
> > On Thu, Aug 19, 2021 at 12:37:30PM +0200, Wolfgang Kroener wrote:
> > > Package: remind
> > > Version: 03.03.01-1
> > > Severity: wishlist
> > > 
> > > Hello everyone,
> > > 
> > > please update remind. The latest version is at the moment 3.3.7.
> > > The changelog is at
> > > https://git.skoll.ca/Skollsoft-Public/Remind/src/branch/master/docs/WHATSNEW
> > > Thank you.
> > 
> > Thanks, this has been blocked for long time due to the freeze.
> > Will take care after the summer holidays!
> 
> Did you find time to look into this already?
> 
> I'm maintaining a number of remind related tools upstream and in Debian
> (wyrd) and would be happy to help maintain Remind. Would you be ok if I add
> myself as an uploader?

Thanks for your offer, I'm happy to have you as a co-maintainer. The
pandemy has stolen all my free time :(

Ana

Bug#1002593: imdbpy: please package new upstream release

[Ana Guerrero Lopez]

On Sat, Dec 25, 2021 at 04:16:08PM -0500, Sandro Tosi wrote:
> > Feel free to update it if you need a new version.
> 
> the git repo is under your namespace, so i cannot push updates to it:

Repository access is not limited by namespace, you can change it in
salsa.

> would you be interested in moving it under DPT
> https://salsa.debian.org/python-team/packages/ ?

No need to move it. Everyone in the Debian group should have access to:
https://salsa.debian.org/ana/imdbpy/


Ana

Bug#1002593: imdbpy: please package new upstream release

[Ana Guerrero Lopez]

Hi,

On Fri, Dec 24, 2021 at 05:45:18PM -0500, Sandro Tosi wrote:
> Source: imdbpy
> Severity: normal
> X-Debbugs-Cc: mo...@debian.org
> 
> Hello,
> upstream released a new version several months ago: 2021.04.18
> 
> Please update the debian package.

Feel free to update it if you need a new version.

Cheers,
Ana

Bug#992493: remind: please update to latest version

[Ana Guerrero Lopez]

Hi Wolfgang,

On Thu, Aug 19, 2021 at 12:37:30PM +0200, Wolfgang Kroener wrote:
> Package: remind
> Version: 03.03.01-1
> Severity: wishlist
> 
> Hello everyone,
> 
> please update remind. The latest version is at the moment 3.3.7.
> The changelog is at
> https://git.skoll.ca/Skollsoft-Public/Remind/src/branch/master/docs/WHATSNEW
> Thank you.

Thanks, this has been blocked for long time due to the freeze.
Will take care after the summer holidays!

Ana

Bug#939181: cycle: should it be RM'd ?

[Ana Guerrero Lopez]

On Tue, Jan 28, 2020 at 06:06:59PM +0100, Andreas Tille wrote:
> On Tue, Jan 28, 2020 at 10:56:23AM -0500, Scott Talbert wrote:
> > Is there any hope for a Python 3 port of cycle, or should it just be RM'd?
> 
> Ana, could you please have a last word about this?
>
Thanks Andreas.

I haven't given up yet in a Python 3 port, but if cycle must be removed for the
sake of removing Python 2, just do it. It's always possible to re-introduce
the package later.

Cheers,
Ana

Bug#950972: press: Broken/mangled space characters in 10.3 and 9.12 point release announcements

[Ana Guerrero Lopez]

On Sat, Feb 08, 2020 at 10:41:47PM +0100, Salvatore Bonaccorso wrote:
> Package: press
> Severity: normal
> 
> Hi
> 
> Just noticed that in the release announcement for the 10.3[0] and
> 9.12[1] announcements, there seem to be broken spaces in the generated
> table between the source package names and the reference markers.
> 
> Many thanks for your work!
> 
> Regards,
> Salvatore
> 
> [0] https://lists.debian.org/debian-announce/2020/msg0.html
> [1] https://lists.debian.org/debian-announce/2020/msg1.html

These mails are generated from the website using this script:
https://salsa.debian.org/publicity-team/publicity/blob/master/dpn/scripts/DPNhtml2mail.pl

That is adding an extra unicode character.

A perl coder help would be very appreciated :-)

Cheers,
Ana

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

On Tue, Oct 01, 2019 at 06:12:56AM +0200, Andreas Tille wrote:
> On Mon, Sep 30, 2019 at 11:47:14PM +0200, Ana Guerrero Lopez wrote:
> > > Thanks to you.  I'd be happy if you could check master[1] and confirm
> > > that it is OK.  I can even give you commit permissions so you can change
> > > anything you feel sensible and do the team upload yourself.
> > 
> > Please, add me to the group, I'll take care of the testing and upload.
> 
> Welcome to the team, Andreas. 

Thanks!
Good news, I've tested and it works fine. I'm doing a team upload right now.

I think we shouldn't give up in getting this ported to python3, but I think a
re-write keeping the possibility to read the all data is the best way to go.

Cheers,
Ana

Bug#934516: Feature local DB setup more prominently?

[Ana Guerrero Lopez]

Hi Moritz,

Thanks for this suggestion.

On Sun, Aug 11, 2019 at 10:54:58PM +0200, Moritz Muehlenhoff wrote:
> Source: imdbpy
> Severity: wishlist
> 
> Hi Ana,
> one of IMHO the coolest features of imdbpy (the possibility to create a local 
> DB using
> the data dumps provided on https://datasets.imdbws.com) is currently quite 
> hidden.
> 
> How about updating the package description to something like
> 
> ---
> IMDbPY is a Python package useful to retrieve and manage the data of
> the IMDb movie database about both movies and people.
> It can be very easily used by programmers and developers to provide
> access to the IMDb's data to their programs, both by fetching data from
> the IMDB website and by building a local SQL database using the datasets
> provided for download by IMDb.
> ---
> 
> and installing s32imdbpy.py to /usr/bin (IMHO it's a little more than a mere
> example).

This sounds good to me.

> It doesn't seem adequate to depend on all the Python modules needed
> to create a local DB, but if you're interested I'd be happy to write up
> something like README.Debian.local-DB which describes the steps/dependencies
> for a local DB installation.

I'm pretty OK with all this, but it's not something I'll add in the top
of my TODO list.
I have given you commit rights to https://salsa.debian.org/ana/imdbpy/
so feel free to commit directly there or send a patch, as you prefer!

Cheers,

Ana

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

Hi,

On Mon, Sep 23, 2019 at 10:18:51AM +0200, Andreas Tille wrote:
> 
...
> On Sun, Sep 22, 2019 at 11:11:47PM +0200, Ana Guerrero Lopez wrote:
...

> > Your current python3 porting is not helping here since many people will 
> > start
> > the application, will be prompted for a new user, will create it and erase
> > all their data. So please, revert your changes and if that means the package
> > will be removed from the archive, let it be. At least people will be able to
> > continue using it while they move to something else (or not), but won't lose
> > their data as it'll happen now.
> 
> I've now pushed a change to salsa[1] where I deactivated the whole 2to3
> port and replaced the warning about the port by some other warning that
> a port will be needed or the package will vanish.  Hopefully this might
> attract some coders.  BTW, I fully agree with you that the code quality
> might not be a good start.
> 
> I tried to start the build here but I get:
> 
> $ cycle 
> Traceback (most recent call last):
>   File "/usr/bin/cycle", line 213, in 
> app = MyApp(0)
>   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/_core.py", line 8628, 
> in __init__
> self._BootstrapApp()
>   File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/_core.py", line 8196, 
> in _BootstrapApp
> return _core_.PyApp__BootstrapApp(*args, **kwargs)
>   File "/usr/bin/cycle", line 193, in OnInit
> ret=first_login()
>   File "/usr/share/cycle/dialogs.py", line 304, in first_login
> users = get_users()
>   File "/usr/share/cycle/dialogs.py", line 192, in get_users
> users.append((cPickle.loads(tmp[:n]), f))
> ValueError: unsupported pickle protocol: 3
> 
> 
> So I reverted to the Python2 version 0.3.1-14 (from testing) but I get
> absolutely the same error.  I wonder whether my package is fine in terms
> of "works as broken as before" or whether I messed up something else.
> 
> > Thanks for caring.
> 
> Thanks to you.  I'd be happy if you could check master[1] and confirm
> that it is OK.  I can even give you commit permissions so you can change
> anything you feel sensible and do the team upload yourself.

Please, add me to the group, I'll take care of the testing and upload.

Cheers,

Ana

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

Hi Andreas,

On Sat, Sep 21, 2019 at 06:39:51PM +0200, Andreas Tille wrote:
> Control: tags -1 help
> 
> Dear Ana,
> 
> On Sat, Sep 21, 2019 at 05:41:27PM +0200, Ana Guerrero Lopez wrote:
> > This new version of cycle, ported to python3, doesn't read the data file
> > ( under .cycle) and prompts to create a new user.
> > 
> > Not creating a new user and downgrading to the version in buster (-14), 
> > allows
> > to continue using the application with the previous data.
> 
> thanks a lot for thorough testing the package!
> 
> The situation is as follows:  Upstream is dead so we probably become
> upstream in Debian.  I has done my best to port it to Python3 with the
> help of Debian Python team.  I personally can not do more.  I can just
> hope that someone who is using the program will try to fix it.  If you
> feel able to do this it would be great.  If you know somebody who could
> do it great as well.  I'd be really happy if we could keep the package
> inside Debian and if someone could fix it.

I used to maintain this package, so I'm well aware of the problems, check
the changelog ;)

The package should be removed from the archive, the base code is very poor to
start with, and the patching for python3 isn't going to fix this, just add
more problems...
Your current python3 porting is not helping here since many people will start
the application, will be prompted for a new user, will create it and erase
all their data. So please, revert your changes and if that means the package
will be removed from the archive, let it be. At least people will be able to
continue using it while they move to something else (or not), but won't lose
their data as it'll happen now.

Thanks for caring.

cheers,
Ana

Bug#940902: doesn't read the data

[Ana Guerrero Lopez]

Package: cycle
Version: 0.3.1-16
Severity: grave

Hi,

This new version of cycle, ported to python3, doesn't read the data file
( under .cycle) and prompts to create a new user.

Not creating a new user and downgrading to the version in buster (-14), allows
to continue using the application with the previous data.

Cheers,
Ana

Bug#926131: footer: replace identi.ca with micronews

[Ana Guerrero Lopez]

Package: www.debian.org

Hi,

I'd say it's about time we drop identi.ca/debian from the footer 
and add instead a link to micronews.debian.org

Thoughts?

Cheers,
Ana

Bug#807666: reopen 807666, it should be fixed properly

[Ana Guerrero Lopez]

unarchive 807666
reopen 807666
notfixed 807666 mpich/3.2-1~exp1
found 807666 3.3-2
forwarded 807666 
https://lists.mpich.org/pipermail/discuss/2019-March/011160.html
kthxbye

Hi,

This bug wasn't closed properly. While a rebuild of the package with
the new upload fixed the problem temporarily, this is a problem
that must be solved in mpich as Matthias and Emilio pointed out.

I have sent a patch to upstream that should fix the issue:
https://lists.mpich.org/pipermail/discuss/2019-March/011160.html

Cheers,
Ana

Bug#922920: RM: imdbpy -- python-imdbpy package removed

[Ana Guerrero Lopez]

Package: ftp.debian.org
Severity: normal

Hi,

In the last upload, imdbpy dropped the python-imdbpy package and
it's now only shipping python3-imdbpy.
Could you please remove the python-imdbpy binaries?

Thanks!

Ana

Bug#896111: ITP: servo-hdctools -- Chrome OS Hardware Debug & Control Tools

[Ana Guerrero Lopez]

Package: wnpp
Owner: Ana Guerrero Lopez <a...@collabora.com>
Severity: wishlist

* Package name : servo-hdctools
Version : 20180401
Upstream Author : The Chromium OS Authors <chromium-os-...@chromium.org>
* URL : https://chromium.googlesource.com/chromiumos/third_party/hdctools
* License : BSD-3-clause
Programming Language: Python, C
Description : Chrome OS Hardware Debug & Control Tools

Servo is a debug board used for Chromium OS test and development.
This code contains:
* the backend server that talks to servo boards
* a binary allowing to control the server
* usbkm232, an RS232 (uart) to USB keyboard emulator

Bug#896103: ITP: servod-tools -- manage multiple servo control boards automatically

[Ana Guerrero Lopez]

Package: wnpp
Owner: Ana Guerrero Lopez <a...@collabora.com>
Severity: wishlist

* Package name : servod-tools
Version : 20180201
Upstream Author : Daniel Stone <dani...@collabora.com> and others
* URL : https://gitlab.collabora.com/gtucker/servod-tools
* License : MIT
Programming Python
Description : manage multiple servo control boards automatically

servod-tools lets you use one or many Servo control board for 
Chromebooks in some
kind of vaguely automated fashion. After installing these and 
configuring for

your local boards, you should have access to the CPU UART as
/dev/google-servo/$devicename/cpu-uart, and the EC as
/dev/google-servo/$devicename/ec-uart, as well as having servod itself
listening for more complex commands on a predictable port.

Bug#881868: O: ibsim -- InfiniBand fabric simulator utilities

[Ana Guerrero Lopez]

Package: wnpp
Severity: normal

I was the only maintainer left from the pkg-ofed team 
,
maintaining ibsim. I'm orphaning this package now.

I considered asking its removal directly, but I've finally decided to orphan
it and asking for removal if by 30 June 2018 nobody has adopted it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: ibsim
Binary: ibsim-utils, libumad2sim0
Version: 0.7-1
Maintainer: OFED and Debian Development and Discussion 

Uploaders: Ana Beatriz Guerrero Lopez 
Build-Depends: debhelper (>= 9), dpkg-dev (>= 1.16.1~), libibumad-dev (>= 
1.3.8), libibmad-dev (>= 1.3.9)
Architecture: i386 ia64 amd64 powerpc
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 8a3e544d5e5e0782a2103e11732e0dae 2098 ibsim_0.7-1.dsc
 7ff8756f222799d042f7309777cc711d 64660 ibsim_0.7.orig.tar.gz
 f5db3dd669f18189dc08e4072c2bbf2c 3196 ibsim_0.7-1.debian.tar.xz
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-ofed/ibsim.git
Vcs-Git: https://anonscm.debian.org/git/pkg-ofed/ibsim.git
Checksums-Sha256:
 39f2ace04ebec080f859efa65ec808d4845524218e404247f8057713bc73340a 2098 
ibsim_0.7-1.dsc
 66908257f0de6866589b6f4b99e9cfd2805d4d3ed61631e09d15eae876202e24 64660 
ibsim_0.7.orig.tar.gz
 245a96abe04e1b9f8b3453878ca0a854ca962713827abc1701e2712f3936b47e 3196 
ibsim_0.7-1.debian.tar.xz
Homepage: https://www.openfabrics.org/downloads/management/
Package-List: 
 ibsim-utils deb net extra arch=i386,ia64,amd64,powerpc
 libumad2sim0 deb net extra arch=i386,ia64,amd64,powerpc
Directory: pool/main/i/ibsim
Priority: source
Section: net

Package: ibsim-utils
Source: ibsim
Version: 0.7-1
Installed-Size: 126
Maintainer: OFED and Debian Development and Discussion 

Architecture: amd64
Depends: libc6 (>= 2.15), libibmad5, libibumad3 (>= 1.3.9), libumad2sim0 (= 
0.7-1)
Description-en: InfiniBand fabric simulator utilities
 ibsim provides a simulation of an InfiniBand fabric,
 which can be used by the opensm subnet manager and
 infiniband diagnostics and management tools.
 .
 This package provides utilities for use with the
 simulator.
Description-md5: 213cfc3282bdc0c42f1565a0696d728b
Homepage: https://www.openfabrics.org/downloads/management/
Tag: role::program
Section: net
Priority: optional
Filename: pool/main/i/ibsim/ibsim-utils_0.7-1_amd64.deb
Size: 41314
MD5sum: 8f0dc82774c645523e1e53cf16a783ab
SHA256: 537689f4c89484c5e19c49f28668e26f5fe69c006e6f6fb1365ebcef7e5e2b79

Package: libumad2sim0
Source: ibsim
Version: 0.7-1
Installed-Size: 35
Maintainer: OFED and Debian Development and Discussion 

Architecture: amd64
Depends: libc6 (>= 2.14), libibmad5, libibumad3 (>= 1.3.9)
Description-en: InfiniBand fabric simulator
 ibsim provides a simulation of an InfiniBand fabric,
 which can be used by the opensm subnet manager and
 infiniband diagnostics and management tools.
 .
 This package provides an LD_PRELOADable library which
 will make applications use the simulated fabric.
Description-md5: f353e396e02cc90660f28f13a719acd4
Homepage: https://www.openfabrics.org/downloads/management/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/i/ibsim/libumad2sim0_0.7-1_amd64.deb
Size: 12404
MD5sum: 7af39ba09f6df0c80110a90d1871c6fb
SHA256: 566a248df7b2b5b8eefdd71dc2833f6f53fdb1dbbf783e72badf6cf81e241450

Bug#881867: O: dapl -- development files for the DAPL libraries

[Ana Guerrero Lopez]

Package: wnpp
Severity: normal

I was the only maintainer left from the pkg-ofed team 
,
maintaining dapl. I'm orphaning this package now.

I considered asking its removal directly, but I've finally decided to orphan
it and asking for removal if by 30 June 2018 nobody has adopted it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: dapl
Binary: libdapl-dev, libdapl2, dapl2-utils
Version: 2.1.9-1
Maintainer: OFED and Debian Development and Discussion 

Uploaders: Ana Beatriz Guerrero Lopez 
Build-Depends: debhelper (>= 9), librdmacm-dev, libibverbs-dev (>= 1.1.2), 
autotools-dev, dh-autoreconf
Architecture: i386 ia64 amd64 powerpc ppc64el s390x
Standards-Version: 3.9.8
Format: 3.0 (quilt)
Files:
 bb569826585fc8e595ecfea41f6e 2235 dapl_2.1.9-1.dsc
 800359e1a9508a2b3005327de654fcc6 1075725 dapl_2.1.9.orig.tar.gz
 e226f8d9e0a1bf4e111facb406ea7f16 9076 dapl_2.1.9-1.debian.tar.xz
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-ofed/dapl.git
Vcs-Git: https://anonscm.debian.org/git/pkg-ofed/infiniband-dapl.git
Checksums-Sha256:
 f1c05431cbd0bcb0f694f22b49203f35f01b176fe7953817abcd9a6353bb10a4 2235 
dapl_2.1.9-1.dsc
 40982b43c5e2f1d5b007add9917bc461fdffb95bd52f589de95b15aa59a9d0b6 1075725 
dapl_2.1.9.orig.tar.gz
 ea3241b3ee440664187b1aefd000bce10b05bfeb4dbaaac399725fbe2b313098 9076 
dapl_2.1.9-1.debian.tar.xz
Homepage: https://www.openfabrics.org/downloads/dapl/
Package-List: 
 dapl2-utils deb net extra arch=i386,ia64,amd64,powerpc,ppc64el,s390x
 libdapl-dev deb libdevel extra arch=i386,ia64,amd64,powerpc,ppc64el,s390x
 libdapl2 deb libs extra arch=i386,ia64,amd64,powerpc,ppc64el,s390x
Directory: pool/main/d/dapl
Priority: optional
Section: misc

Package: libdapl-dev
Source: dapl
Version: 2.1.9-1
Installed-Size: 1855
Maintainer: OFED and Debian Development and Discussion 

Architecture: amd64
Depends: libdapl2 (= 2.1.9-1)
Description-en: development files for the DAPL libraries
 The Direct Access Programming Library (DAPL) is a transport-independent,
 platform-independent API that supports Remote Direct Memory Access (RDMA)
 devices such as Infiniband and iWARP .
 .
 This package contains the header files and shared libraries for building
 applications against libdapl.
Description-md5: f2bcded91991be98939d4ef77d9cd821
Homepage: https://www.openfabrics.org/downloads/dapl/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/d/dapl/libdapl-dev_2.1.9-1_amd64.deb
Size: 288596
MD5sum: fceff3bf32da7320ef1673d85a835be7
SHA256: aeea2ef74b016e00dd5b2a954d6addde63b19d359ae3ebd5df57d0e89ea8e7d3

Package: libdapl2
Source: dapl
Version: 2.1.9-1
Installed-Size: 631
Maintainer: OFED and Debian Development and Discussion 

Architecture: amd64
Depends: libc6 (>= 2.16), libibverbs1 (>= 1.1.6), librdmacm1 (>= 1.0.19)
Description-en: Direct Access Programming Library (DAPL)
 The Direct Access Programming Library (DAPL) is a transport-independent,
 platform-independent API that supports Remote Direct Memory Access (RDMA)
 devices such as Infiniband and iWARP .
  .
 This package contains the libdapl shared library.
Description-md5: 4a6df895a815aa44aba379abd136a872
Homepage: https://www.openfabrics.org/downloads/dapl/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/d/dapl/libdapl2_2.1.9-1_amd64.deb
Size: 209168
MD5sum: 0d642f87d771a7931d2e9d556dca8559
SHA256: af99ab8314d4ea8849f235bfa450b04c6b8e8a8dafa64e5ebd2037b789c19d12

Package: dapl2-utils
Source: dapl
Version: 2.1.9-1
Installed-Size: 426
Maintainer: OFED and Debian Development and Discussion 

Architecture: amd64
Depends: libc6 (>= 2.14), libdapl2
Description-en: utilities for use with the DAPL libraries
 The Direct Access Programming Library (DAPL) is a transport-independent,
 platform-independent API that supports Remote Direct Memory Access (RDMA)
 devices such as Infiniband and iWARP .
 .
 This package contains example utilities that use the DAPL API.
Description-md5: 1001db4d106665ebf40971bc1d6648d8
Homepage: https://www.openfabrics.org/downloads/dapl/
Tag: role::program
Section: net
Priority: optional
Filename: pool/main/d/dapl/dapl2-utils_2.1.9-1_amd64.deb
Size: 204602
MD5sum: 50d50e7e39832243e55362f1a11c48a3
SHA256: d88e761a029d60d2e889a1f65414321fce7fe3de142cafedaf4fcbf318621311

Bug#877874: RM: qlvnictools -- ROM; dead upstream, low popcorn, no maintainers

[Ana Guerrero Lopez]

Package: ftp.debian.org
Severity: normal

Please, remove qlvnictools from the archive.

Thank you,
Ana

Bug#715085: closed by Ana Beatriz Guerrero Lopez <a...@debian.org> (Bug#715085: fixed in ibutils 1.5.7-5)

[Ana Guerrero Lopez]

On Wed, May 17, 2017 at 10:54:22PM +0300, Adrian Bunk wrote:
> On Sun, Mar 12, 2017 at 09:21:06PM +, Debian Bug Tracking System wrote:
> >...
> >  ibutils (1.5.7-5) unstable; urgency=medium
> >  .
> >* Fix Depends lines:
> >  - libibdm-dev: add depends on libibdm1 (= ${binary:Version}) (Closes: 
> > #715085)
> >...
> 
> Hi Ana,
> 
> thanks a lot for fixing this bug for stretch.
> 
> It is still present in jessie, could you also fix it there?
> Alternatively, I can fix it for jessie if you don't object.

Please, go ahead with the fix.

Thanks
Ana

Bug#740945: [Pkg-ofed-devel] Bug#740945: Reverting this change

[Ana Guerrero Lopez]

On Thu, May 11, 2017 at 10:11:14PM +, Bart Van Assche wrote:
> Hello Ana,
> 
> Thank you for the quick follow-up. The entire e-mail thread is available at
> http://www.spinics.net/lists/linux-rdma/msg49668.html. Please let me know if 
> you
> need more information than what is available in that e-mail thread.

Thank you Bart. I have read the thread and exchanged privately with Benjamin
and I'm going to revert the upload.

Ana

Bug#740945: [Pkg-ofed-devel] Bug#740945: Reverting this change

[Ana Guerrero Lopez]

Hi Bart,

On Thu, May 11, 2017 at 02:26:02PM -0700, Bart Van Assche wrote:
> The conclusion of a discussion on the linux-rdma mailing list is that
> the "Don't activate any targets per default" change should be reverted.
> Whom should be contacted to perform that revert?

Thanks for pointing this out.

I don't know why Roland has done this change, specially because Debian is in
deep freeze and this kind of changes are not welcome at this stage.
I don't follow linux-rdma, could you please give me a pointer to the
discussion?

Thank you,
Ana

Bug#862313: ITP: libpsm2 -- PSM2 runtime, dev and compatibility libraries for Intel Omni-Path

[Ana Guerrero Lopez]

On Wed, May 10, 2017 at 11:02:34PM -0500, Brian T. Smith wrote:
> Package: wnpp
> Severity: wishlist
> Owner: "Brian T. Smith" 
> 
> * Package name: libpsm2
>   Version : 4.0
>   Upstream Author : 01org 
> * URL : https://github.com/01org
> * License : GPL, BSD
>   Programming Lang: C
>   Description : PSM2 runtime, dev and compatibility libraries for Intel 
> Omni-Path


Hi Brian,

Please, consider maintaining all the RDMA related packages inside
the relevant team in Debian, pkg-ofed: http://pkg-ofed.alioth.debian.org/
(yes, the name isn't the most fitting, but it's there because historical
reasons).
Join in alioth and subscribe to the mailing list, the list is closed
for people who are not subscribed to avoid spam. The list archives
are public.

I've also packaged libpsm2 amongs other packages but I have failed
to have them in production but I have failed to push it to Debian.
However I'm more than happy if it's maintained by somebody else.

I have seen your Debian packages, contact me privately if you want
feedback about them.

Ana

Bug#835210: grafana: new upstream version 3.1.1 available

[Ana Guerrero Lopez]

Hi,

Grafana is going to be stuck in 2.6 for stretch. :/
I needed a newer version and while upstream provide packages I wanted
something I was able to adapt. My packaging in case is useful
to somebody is at:

https://github.com/edf-hpc/grafana-deb/

Ana

Bug#793355: lmod: diff for NMU version 6.6-0.1

[Ana Guerrero Lopez]

Hi,

On Mon, Nov 21, 2016 at 04:41:54AM +0100, Aaron Zauner wrote:
> BTW: In production HPC environments similar configurations are deployed,
> I've done so in a few different installations (plus a few other neat hacks
> for usability).
> 
> I don't see why someone that installs lmod by choice wouldn't want them.
> I've just been conservative w.r.t. automatically setting lmod up for the
> user.


> On Mon, Nov 21, 2016 at 4:39 AM, Aaron Zauner  wrote:
> 
> > Sorry for the late reply.
> >
> > Thanks for working on this. I'm fine with the changes you've made. Haven't
> > tested to be honest as I had limited time since you've worked on these
> > changes to do so.

Thank you for your reply Aaron, I've pushed the upload to be uploaded today
instead of Wednesday.
I have been testing lmod 6.6 with all these changes in production (a recently
installed HPC system) and I haven't found any problem so far.

Ana

Bug#793355: lmod: diff for NMU version 6.6-0.1

[Ana Guerrero Lopez]

line containing a single path will be added to the MODULEPATH
+#  environment variable.
+#
+/etc/lmod/modules
+/usr/share/lmod/lmod/modulefiles/
diff -Nru lmod-5.8/debian/patches/change_paths lmod-6.6/debian/patches/change_paths
--- lmod-5.8/debian/patches/change_paths	2014-11-04 23:46:05.0 +0100
+++ lmod-6.6/debian/patches/change_paths	2016-11-11 16:55:56.0 +0100
@@ -1,11 +1,9 @@
-diff --git a/Makefile.in b/Makefile.in
-index 8938ca6..160fe7b 100644
 --- a/Makefile.in
 +++ b/Makefile.in
-@@ -41,15 +41,15 @@ GIT_VERSION   := $(shell if [ -n "$(GIT_PROG)" -a -d .git ]; then lm
+@@ -60,15 +60,15 @@
  prefix		  	  := @prefix@
  package		  	  := lmod
- version		  	  := $(shell cd $(PATH_TO_SRC)/src; $(PATH_TO_LUA)/lua -e "V=require('Version'); print(V.tag())")
+ version		  	  := $(shell cd $(srcdir)/src; $(PATH_TO_LUA)/lua -e "V=require('Version'); print(V.tag())")
 -PKGV		  	  := $(prefix)/$(package)/$(version)
 -PKG		  	  := $(prefix)/$(package)/$(package)
 -LIBEXEC		  	  := $(prefix)/$(package)/$(version)/libexec
@@ -23,7 +21,7 @@
 +SETTARG   := $(prefix)/share/$(package)/$(version)/settarg
 +INIT		  	  := $(prefix)/share/$(package)/$(version)/init
 +LMOD_MF 	  	  := $(prefix)/share/$(package)/$(version)/modulefiles/Core
-+MAN_PAGES := $(prefix)/share/$(package)/$(version)/share/man/cat1
- LMOD_MF_SOURCE:= MF/*.version.lua
- SETTARG_SOURCE:= settarg/*.lua  settarg/targ.in
++MAN_PAGES := $(prefix)/share/man/man1
+ LMOD_MF_SOURCE:= $(patsubst %, $(srcdir)/%, MF/*.version.lua)
+ SETTARG_SOURCE:= $(patsubst %, $(srcdir)/%, settarg/*.lua  settarg/targ.in)
  
diff -Nru lmod-5.8/debian/patches/series lmod-6.6/debian/patches/series
--- lmod-5.8/debian/patches/series	2014-05-21 00:52:41.0 +0200
+++ lmod-6.6/debian/patches/series	2016-11-11 23:29:58.0 +0100
@@ -1 +1,2 @@
 change_paths
+set_modulespath
diff -Nru lmod-5.8/debian/patches/set_modulespath lmod-6.6/debian/patches/set_modulespath
--- lmod-5.8/debian/patches/set_modulespath	1970-01-01 01:00:00.0 +0100
+++ lmod-6.6/debian/patches/set_modulespath	2016-11-11 23:29:50.0 +0100
@@ -0,0 +1,18 @@
+This patch makes MODULEPATH to be set with the contents of the file
+/etc/lmod/modulespath
+
+Date: 2016-11-10
+Author: Ana Guerrero López <a...@debian.org>
+--- a/init/profile.in
 b/init/profile.in
+@@ -23,8 +23,8 @@
+ export LMOD_FULL_SETTARG_SUPPORT=@lmod_full_settarg_support@
+ export LMOD_COLORIZE=@colorize@
+ export LMOD_PREPEND_BLOCK=@prepend_block@
+-export MODULEPATH=$(@PKG@/libexec/addto --append MODULEPATH $MODULEPATH_ROOT/$LMOD_sys $MODULEPATH_ROOT/Core)
+-export MODULEPATH=$(@PKG@/libexec/addto --append MODULEPATH @PKG@/modulefiles/Core)
++	MODULEPATH=`sed -n 's/[   #].*$//; /./H; $ { x; s/^\n//; s/\n/:/g; p; }' /etc/lmod/modulespath`
++export MODULEPATH
+ export MODULESHOME=@PKG@
+ 
+ export BASH_ENV=$MODULESHOME/init/bash
diff -Nru lmod-5.8/debian/rules lmod-6.6/debian/rules
--- lmod-5.8/debian/rules	2014-05-21 00:44:01.0 +0200
+++ lmod-6.6/debian/rules	2016-11-11 23:24:57.0 +0100
@@ -4,6 +4,9 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+TDIR=debian/lmod
+
+
 %:
 	dh $@  --with autotools-dev
 
@@ -11,3 +14,7 @@
 
 override_dh_pysupport:
 
+override_dh_auto_install:
+	dh_auto_install
+	cp ${TDIR}/usr/share/lmod/lmod/init/profile ${TDIR}/etc/profile.d/lmod.sh
+	cp debian/modulespath ${TDIR}/etc/lmod/

Bug#826222: [Pkg-ofed-devel] Bug#826222: [PATCH] Install pkgconfig file.

[Ana Guerrero Lopez]

On Thu, Oct 06, 2016 at 11:41:48AM +0200, Marcin Ślusarz wrote:
> 2016-09-04 22:17 GMT+02:00 Marcin Ślusarz :
> > From: =?UTF-8?q?Marcin=20=C5=9Alusarz?= 
> > Date: Sun, 4 Sep 2016 22:05:18 +0200
> > Subject: [PATCH] Install pkgconfig file.
> >
> > ---
> >  debian/libfabric-dev.install | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/debian/libfabric-dev.install b/debian/libfabric-dev.install
> > index dcf96dd..99550ed 100644
> > --- a/debian/libfabric-dev.install
> > +++ b/debian/libfabric-dev.install
> > @@ -1,3 +1,4 @@
> >  usr/include/*
> >  usr/lib/*/lib*.so
> > +usr/lib/*/pkgconfig/libfabric.pc
> >  usr/share/man/man3
> > --
> 
> Dear Maintainer,
> 
> You misapplied my patch. Pkg-config files belong to "dev" packages,
> *not* the main ones.
> Just look at other packages. Right now with just libfabric1 package
> installed, pkg-config
> returns infromation(s) that cannot be resolved without libfabric-dev.

*sigh* The problems of doing things in a hurry late a night, I'll look at it
when I really have time.

Bug#826222: [PATCH] Install pkgconfig file.

[Ana Guerrero Lopez]

On Sun, Sep 04, 2016 at 10:17:36PM +0200, Marcin Ślusarz wrote:
> From: =?UTF-8?q?Marcin=20=C5=9Alusarz?= 
> Date: Sun, 4 Sep 2016 22:05:18 +0200
> Subject: [PATCH] Install pkgconfig file.
> 
> ---
>  debian/libfabric-dev.install | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/debian/libfabric-dev.install b/debian/libfabric-dev.install
> index dcf96dd..99550ed 100644
> --- a/debian/libfabric-dev.install
> +++ b/debian/libfabric-dev.install
> @@ -1,3 +1,4 @@
>  usr/include/*
>  usr/lib/*/lib*.so
> +usr/lib/*/pkgconfig/libfabric.pc
>  usr/share/man/man3
> -- 
> 2.9.3

Thank you Marcin!
I am not planning to do an upload of libfabric soon unless there is a
severe bug or a new version. Is the missing pkgconfig file blocking you?

Ana

Bug#805238: debian-timeline: Add script for automatic update of the bug events database

[Ana Guerrero Lopez]

On Tue, Aug 16, 2016 at 12:01:27PM +0200, Rafael Laboissière wrote:
> 
> * Paul Wise  [2016-08-16 10:57]:
> 
> > On Sun, 15 Nov 2015 23:04:31 +0100 Rafael Laboissiere wrote:
> > 
> > > ## Copyright (C) 2015 Rafael Laboissiere ## ## This program is in
> > > the public domain
> > 
> > Is this script under copyright or in the public domain?
> > 
> > It can't be both at the same time.
> > 
> > Personally I would suggest using CC0 or a permissive license instead.
> 
> You are right, I have overseen that.  As regards the licensing conditions, I
> followed what is specified in the COPYING [1] and d/copyright [2] files.
> 
> @Ana: This reply should create a new bug report.  Could you please fix the
> header of the update-bug-list.py script by applying the patch attached to
> this message?


Thank you for you quick reply Rafael.
The Debian publicity repository are writable by all DD, so you can commit
yourself directly if you want to :)


Ana

Bug#811695: FTBFS with GCC 6: invalid suffix on literal

[Ana Guerrero Lopez]

On Tue, Jan 19, 2016 at 05:03:55PM -0800, Martin Michlmayr wrote:
> Package: mstflint
> Version: 4.1.0+1.46.gb1cdaf7-1
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-literal-suffix
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> [...]

For NMUers and interested people: upstream is aware of this issue and planning
to fix this around september.

Ana

Bug#807149: infinipath-psm: FTBFS: Unsupported architecture i686

[Ana Guerrero Lopez]

tags 807149 pending
thanks

On Sat, Dec 05, 2015 at 10:27:05PM -0500, Aaron M. Ucko wrote:
> Source: infinipath-psm
> Version: 3.3+7.g05f6f14.open-1
> Severity: important
> Justification: fails to build from source
> 
> infinipath-psm's debian/control file claims
> 
> Architecture: amd64 i386
> 
> but the i386 build fails:
> 
> make[1]: Entering directory '/«BUILDDIR»/infinipath-psm-3.3+7.g05f6f14.open'
> /usr/bin/make INSTALL_PREFIX=/usr libdir=/usr/lib/i386-linux-gnu 
> PSM_HAVE_SCIF=0 USE_PSM_UUID=0 arch=i686  distclean
> make[2]: Entering directory '/«BUILDDIR»/infinipath-psm-3.3+7.g05f6f14.open'
> Makefile:97: *** Unsupported architecture i686.  Stop.
> 
> Please address this discrepancy one way or another.

Fixed in:
http://anonscm.debian.org/cgit/pkg-ofed/infinipath-psm.git/commit/?id=3f5642435bf1e0eeb7c84d95e63845baddfe4d21

Bug#811940: infinipath-psm: FTBFS with GCC 6: defined but not used

[Ana Guerrero Lopez]

On Tue, Jan 19, 2016 at 07:50:44PM -0800, Martin Michlmayr wrote:
> Package: infinipath-psm
> Version: 3.3+7.gec1d6d2-3
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-unused-const-variable
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
>

With the version 3.3+19.g67c0807.open-1, the package still FTBFS with GCC 6
with the following error:

psm_diags.c: In function 'memcpy_check_size':
psm_diags.c:286:7: error: statement is indented as if it were guarded by... 
[-Werror=misleading-indentation]
   if (dst) psmi_free(dst);
   ^~
psm_diags.c:284:5: note: ...this 'if' clause, but it is not
 if (src == NULL || dst == NULL)
 ^~
cc1: all warnings being treated as errors

I'll send a path to upstream.

Ana

Bug#818973: python-imdbpy: Retrieval of top250 listing returns empty list

[Ana Guerrero Lopez]

On Tue, Mar 22, 2016 at 12:28:31PM +, Jonathan McDowell wrote:
> Package: python-imdbpy
> Version: 5.0-1
> Severity: normal
> Tags: patch upstream
> 
> The get_top250_movies() function is returning an empty list for me. This
> is upstream issue BB #46 (I can't find a link to this report though) and
> is fixed in commit 9fe25d701ddeef51cc00de4fd900193f8bb97134 - as seen
> at:
> 
> https://github.com/alberanid/imdbpy/commit/9fe25d701ddeef51cc00de4fd900193f8bb97134
> 
> I've confirmed applying this patch to the Debian package makes the
> function work for me.

Thank you Jonathan. I'm going to check with upstream if he plans to do
a new release soon. 5.1 is long due!

Ana

Bug#808760: kdbg: FTBFS: Unknown CMake command "check_include_files".

[Ana Guerrero Lopez]

Thanks a lot Eriberto!
I'm going to upload this orphaning the package.


On Wed, Mar 16, 2016 at 02:40:24PM -0300, Eriberto Mota wrote:
> Control: tags 808760 patch
> Control: tags 808760 upstream
> 
> Hi,
> 
> The attached patch will fix this issue.
> 
> Regards,
> 
> Eriberto

> Description: fix an error in CMake sequence, avoiding a FTBFS. (Closes: 
> #808760)
> Author: Joao Eriberto Mota Filho 
> Last-Update: 2016-03-18
> Index: kdbg-2.5.4/CMakeLists.txt
> ===
> --- kdbg-2.5.4.orig/CMakeLists.txt
> +++ kdbg-2.5.4/CMakeLists.txt
> @@ -4,7 +4,7 @@ set(KDBG_VERSION 2.5.4)
>  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/kdbg/version.h.cmake 
> ${CMAKE_CURRENT_BINARY_DIR}/kdbg/version.h)
>  
>  find_package(KDE4 REQUIRED)
> -
> +include(CheckIncludeFiles)
>  add_definitions(${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
>  
>  include(KDE4Defaults)

Bug#814677: packages.debian.org: file is found in wrong suite(s)

[Ana Guerrero Lopez]

Package: www.debian.org
Severity: important


Hi,

When I search "ibchecknet" in the "Search the content of packages" available at
https://www.debian.org/distrib/packages with the options:
- paths ending with the keyword
- Distribution: stable
- Architecture: any

I get:

---
You have searched for paths that end with ibchecknet in suite jessie, all
sections, and all architectures. Found 1 results.

FilePackages
/usr/sbin/ibchecknetinfiniband-diags
---

However, the package infiniband-diags from jessie doesn't provide this file as
can be seen at 
https://packages.debian.org/jessie/amd64/infiniband-diags/filelist

I have the same problem if I search in unstable and it works fine (this is,
the file is not found) when searching in testing, and experimental

The binary /usr/sbin/ibchecknet is only provided in the infiniband-diags package
available in oldstable.

Ana

Bug#782143: pu: package stunnel4/3:5.06-2+deb8u1

[Ana Guerrero Lopez]

On Sun, Apr 26, 2015 at 01:45:11AM +0300, Peter Pentchev wrote:
> Control: retitle -1 pu: package stunnel4/3:5.06-2+deb8u1
> 
> On Thu, Apr 23, 2015 at 10:35:28PM +0100, Jonathan Wiltshire wrote:
> > Control: retitle -1 pu: package stunnel4/3:5.06-3
> > Control: tag -1 jessie
> > 
> > On Wed, Apr 08, 2015 at 02:32:49PM +0300, Peter Pentchev wrote:
> > > This is a pre-approval request for unblocking a RC bugfix upload of
> > > stunnel4 that will fix two RC bugs:
> > > - #771421 - makes stunnel unusable for some users in certain
> > >   configurations; not for everyone, but still, it happens too often to
> > >   be ignored
> > > - #782030 - makes stunnel start and stop properly, checking whether
> > >   the action has actually succeeded
> > 
> > Deferring to a point release; SRM will confirm after release.
> 
> OK, here's an updated debdiff that retargets the upload towards
> stable-proposed-updates; the only change is the header and the footer
> of the changelog entry itself.
> 

Ping!
Are you still interested in this update? It only needs to be rebased
on top of 3:5.06-2+deb8u1.

Ana

Bug#804851: please add a slurm-llnl-emulator package

[Ana Guerrero Lopez]

Hi,

On Thu, Nov 12, 2015 at 11:36:08AM +0100, Ana Guerrero Lopez wrote:
> Please consider adding a -emulator package to allow run slurm
> in emulation mode as described at [1].
> Your git repo [2] doesn't seem to be up to date, so I made a patch
> against the current package in unstable.
> 
> [1] http://slurm.schedmd.com/faq.html#multi_slurmd
> [2] http://anonscm.debian.org/cgit/collab-maint/slurm-llnl.git

Here is an updated patch. This patch adds a new binary slurm-client-emulator
with the binaries rebuilt with the emulator build options.

I prefered adding a new binary with the binaries renamed. There
are another possibilities such as adding the binaries from
slurm-client-emulator directly in the binary slurm-wlm-emulator
and/or renaming the binaries from slurm-client and using alternatives
here too. I found the solution I chose the simplest one.

Ana
>From da4d2cc11246f7e09ff4ab9d0acbb63ac46f25a3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ana=20Guerrero=20L=C3=B3pez?= <a...@ekaia.org>
Date: Wed, 2 Dec 2015 00:00:50 +0100
Subject: [PATCH] Update packaging to add the slurm emulator.

This commit add two new packages slurm-wlm-emulator and
slurm-client-emulator to run slurm in emulator mode as described at
http://slurm.schedmd.com/faq.html#multi_slurmd
---
 debian/changelog | 15 ++
 debian/control   | 21 +++
 debian/rules | 40 
 debian/slurm-client-emulator.install | 18 
 debian/slurm-wlm-emulator.install|  3 +++
 debian/slurm-wlm-emulator.postinst   | 15 ++
 debian/slurm-wlm-emulator.prerm  | 14 +
 debian/slurmctld.install |  2 +-
 debian/slurmctld.postinst|  1 +
 debian/slurmctld.prerm   |  1 +
 debian/slurmd.install|  4 ++--
 debian/slurmd.postinst   |  2 ++
 debian/slurmd.prerm  | 13 
 13 files changed, 146 insertions(+), 3 deletions(-)
 create mode 100644 debian/slurm-client-emulator.install
 create mode 100644 debian/slurm-wlm-emulator.install
 create mode 100644 debian/slurm-wlm-emulator.postinst
 create mode 100644 debian/slurm-wlm-emulator.prerm
 create mode 100644 debian/slurmd.prerm

diff --git a/debian/changelog b/debian/changelog
index 7b6f186..ca7e131 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+slurm-llnl (15.08.4-2) UNRELEASED; urgency=medium
+
+  * Add package slurm-wlm-emulator. This package provides binaries that are
+already in the slurmd and slurmctld package. These packages binaries
+have now the suffix -wlm and the binaries in slurm-wln-emulator got
+the suffix -wlm-emulator.
+The binaries are handled with alternatives, having the emulator package
+a higher priority value.
+  * Add slurm-client-emulator with all the same binaries from slurm-client
+built in emulator mode, these are the binaries to use when running thr
+daemons from slurm-wlm-emulator.
+Binaries have appended suffix -emulator to avoid conflicts.
+
+ -- Ana Guerrero Lopez <a...@debian.org>  Tue, 01 Dec 2015 23:09:08 +0100
+
 slurm-llnl (15.08.4-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index 527f995..26fa986 100644
--- a/debian/control
+++ b/debian/control
@@ -435,3 +435,24 @@ Description: transitional dummy package for slurmdbd
  This is a transitional dummy package for slurmdbd
  It can safely be removed.
 
+Package: slurm-wlm-emulator
+Architecture: any
+Depends: ${misc:Depends},
+ slurmctld (= ${binary:Version}),
+ slurmd (= ${binary:Version})
+Description: SLURM emulator
+ SLURM, the Simple Linux Utility for Resource Management,
+ is an open-source cluster resource management and job scheduling.
+ .
+ This package installs the emulator binaries: slurmd, slurmctld
+ and slurmstepd.
+
+Package: slurm-client-emulator
+Architecture: any
+Depends: ${shlibs:Depends}, ${misc:Depends},
+Description: SLURM client side commands for the emulator
+ SLURM stands for Simple Linux Utility for Resource Management, it
+ is an open-source cluster resource management and job scheduling system
+ that strives to be simple, scalable, portable, fault-tolerant, and
+ interconnect agnostic.
+ This package contains all client side commands for the emulator.
diff --git a/debian/rules b/debian/rules
index c66b6a9..f46dbce 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,12 +11,22 @@ include /usr/share/dpkg/architecture.mk
 %:
 	dh $@ --builddirectory --parallel --with systemd
 
+override_dh_auto_clean:
+	dh_auto_clean
+	dh_auto_clean --builddirectory build-emulator
+	rm -rf $(CURDIR)/debian/tmp-emulator
+
 # We run configure with --disable-debug to avoid the default use of -O0 and
 # consequent unprotected source functions, causing lintian report
 # hardening-no-fortify-functions
 # Notice that -g in CFLAGS 

Bug#806320: New list: debian-...@lists.debian.org

[Ana Guerrero Lopez]

Package: lists.debian.org
Severity: wishlist

Hi,

There is a Debian HPC community scattered mostly around the upstream projects
and we include in Debian plenty of specific HPC software (slurm, ofed stack,...
see more at [1]).
It's about time we try to gather all the folks in the same place and
I would like to request the creation of a debian-hpc mailing list for this.

[1] https://wiki.debian.org/HighPerformanceComputing

Name: debian-hpc
Rationale: (see above)
Short description: Debian in High Performance Computing (HPC)
Long description:  If you are using Debian or a Debian derivative in HPC 
systems, you are welcome on this list.
Category: developers
Subscription Policy: open
Post Policy: open
Web Archive: yes

Thank you!
Ana

Bug#804851: please add a slurm-llnl-emulator package

[Ana Guerrero Lopez]

Source: slurm-llnl
Version: 15.08.3-1
Severity: wishlist

Dear maintainers,

Please consider adding a -emulator package to allow run slurm
in emulation mode as described at [1].
Your git repo [2] doesn't seem to be up to date, so I made a patch
against the current package in unstable.

Ana


[1] http://slurm.schedmd.com/faq.html#multi_slurmd
[2] http://anonscm.debian.org/cgit/collab-maint/slurm-llnl.git
>From 1d9a2db9e2f855a8b11a912dbe35fb6815540a22 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ana=20Guerrero=20L=C3=B3pez?= <a...@ekaia.org>
Date: Mon, 9 Nov 2015 19:44:57 +0100
Subject: [PATCH] Add package slurm-wlm-emulator. This package provides
 binaries that are already in the slurmd and slurmctld package. These packages
 binaries have now the suffix -wlm and the binaries in slurm-wln-emulator got
 the suffix -wlm-emulator. The binaries are handled with alternatives, having
 the emulator package a higher priority value.

---
 debian/changelog   | 11 +++
 debian/control | 11 +++
 debian/rules   | 21 +
 debian/slurm-wlm-emulator.install  |  3 +++
 debian/slurm-wlm-emulator.postinst | 15 +++
 debian/slurm-wlm-emulator.prerm| 14 ++
 debian/slurmctld.install   |  2 +-
 debian/slurmctld.postinst  |  1 +
 debian/slurmctld.prerm |  1 +
 debian/slurmd.install  |  4 ++--
 debian/slurmd.postinst |  2 ++
 debian/slurmd.prerm| 13 +
 12 files changed, 95 insertions(+), 3 deletions(-)
 create mode 100644 debian/slurm-wlm-emulator.install
 create mode 100644 debian/slurm-wlm-emulator.postinst
 create mode 100644 debian/slurm-wlm-emulator.prerm
 create mode 100644 debian/slurmd.prerm

diff --git a/debian/changelog b/debian/changelog
index d6acbfe..18612e4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+slurm-llnl (15.08.3-2) unstable; urgency=medium
+
+  * Add package slurm-wlm-emulator. This package provides binaries that are
+already in the slurmd and slurmctld package. These packages binaries
+have now the suffix -wlm and the binaries in slurm-wln-emulator got
+the suffix -wlm-emulator.
+The binaries are handled with alternatives, having the emulator package
+a higher priority value.
+
+ -- Ana Guerrero Lopez <a...@debian.org>  Mon, 09 Nov 2015 19:29:05 +0100
+
 slurm-llnl (15.08.3-1) unstable; urgency=medium
 
   * New upstream release 
diff --git a/debian/control b/debian/control
index 527f995..da76366 100644
--- a/debian/control
+++ b/debian/control
@@ -435,3 +435,14 @@ Description: transitional dummy package for slurmdbd
  This is a transitional dummy package for slurmdbd
  It can safely be removed.
 
+Package: slurm-wlm-emulator
+Architecture: any
+Depends: ${misc:Depends},
+ slurmctld (= ${binary:Version}),
+ slurmd (= ${binary:Version})
+Description: SLURM emulator
+ SLURM, the Simple Linux Utility for Resource Management,
+ is an open-source cluster resource management and job scheduling.
+ .
+ This package installs the emulator binaries: slurmd, slurmctld
+ and slurmstepd.
diff --git a/debian/rules b/debian/rules
index c66b6a9..8ce8cc1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,12 +11,22 @@ include /usr/share/dpkg/architecture.mk
 %:
 	dh $@ --builddirectory --parallel --with systemd
 
+override_dh_auto_clean:
+	dh_auto_clean
+	dh_auto_clean --builddirectory build-emulator
+	rm -rf $(CURDIR)/debian/tmp-emulator
+
 # We run configure with --disable-debug to avoid the default use of -O0 and
 # consequent unprotected source functions, causing lintian report
 # hardening-no-fortify-functions
 # Notice that -g in CFLAGS is still provided by dpkg-buildflags
 override_dh_auto_configure:
 	dh_auto_configure -- --sysconfdir=/etc/slurm-llnl --localstatedir=/var/run/slurm-llnl --with-munge --without-blcr --enable-pam --without-rpath --disable-debug
+	dh_auto_configure --builddirectory build-emulator -- --sysconfdir=/etc/slurm-llnl --localstatedir=/var/run/slurm-llnl --with-munge --without-blcr --enable-pam --without-rpath --disable-debug --enable-front-end --enable-multiple-slurmd
+
+override_dh_auto_build:
+	dh_auto_build
+	dh_auto_build --builddirectory build-emulator
 
 override_dh_auto_install:
 	dh_auto_install
@@ -42,6 +52,17 @@ override_dh_auto_install:
 		pod2man $$i > debian/tmp/usr/share/man/man1/$$(basename $$i).1; \
 	done
 
+	# Rename binaries that are also in the slurm-wlm-emulator
+	mv debian/tmp/usr/sbin/slurmctld debian/tmp/usr/sbin/slurmctld-wlm
+	mv debian/tmp/usr/sbin/slurmd debian/tmp/usr/sbin/slurmd-wlm
+	mv debian/tmp/usr/sbin/slurmstepd debian/tmp/usr/sbin/slurmstepd-wlm
+
+	dh_auto_install --builddirectory build-emulator  --destdir=$(CURDIR)/debian/tmp-emulator
+	# Rename binaries in the emulator package
+	mv debian/tmp-emulator/usr/sbin/slurmctld debian/tmp-emulator/usr/sbin/slurmctld-wlm-emulator
+	mv debian/tmp-emulator/usr/sbin

Bug#803878: O: kdbg -- graphical debugger interface

[Ana Guerrero Lopez]

Package: wnpp
Severity: normal

I would like to orpha kdbg.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: kdbg
Binary: kdbg
Version: 2.5.4-1
Maintainer: Ana Beatriz Guerrero Lopez 
Build-Depends: debhelper (>= 7.0.50~), cmake, kdelibs5-dev (>= 4:4.4.0)
Architecture: any
Standards-Version: 3.9.4
Format: 3.0 (quilt)
Files:
 77cae3264666a52a53430feb09f2325f 1737 kdbg_2.5.4-1.dsc
 715219a810f39e02b493cab9c4a845a1 408683 kdbg_2.5.4.orig.tar.gz
 531e4eb3bc8461c289991a846e51d973 6854 kdbg_2.5.4-1.debian.tar.gz
Checksums-Sha1:
 cd5ed73b90e046e165c489c581d6a4f8febbbdd4 1737 kdbg_2.5.4-1.dsc
 b3f94b7d83c563f28fba090877ae2cd64ea3dfac 408683 kdbg_2.5.4.orig.tar.gz
 0c16698b395766528fc5e55cf9bfd88e454ad2d7 6854 kdbg_2.5.4-1.debian.tar.gz
Checksums-Sha256:
 b8ca3ce5f7e42c16d09adc950830a2f2095fd5f5f4930618057d241e402f 1737 
kdbg_2.5.4-1.dsc
 82a9ac163311319ae83002b7f250eac02fd4be176d037519adc38e107caaa6e5 408683 
kdbg_2.5.4.orig.tar.gz
 78eb1467de47fea165f190371bea4c07a0b88d6a9f163b17932f87dc6b46d9c8 6854 
kdbg_2.5.4-1.debian.tar.gz
Homepage: http://www.kdbg.org/
Package-List: 
 kdbg deb devel optional
Directory: pool/main/k/kdbg
Priority: source
Section: devel

Package: kdbg
Version: 2.5.4-1
Installed-Size: 1153
Maintainer: Ana Beatriz Guerrero Lopez 
Architecture: amd64
Depends: kde-runtime (>> 4:4.10), libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), 
libkdecore5 (>= 4:4.4.0), libkdeui5 (>= 4:4.4.0), libkio5 (>= 4:4.4.0), 
libqt4-dbus (>= 4:4.5.3), libqt4-network (>= 4:4.5.3), libqt4-svg (>= 4:4.5.3), 
libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.8.0), 
libstdc++6 (>= 4.6)
Recommends: gdb (>= 5.0)
Description-en: graphical debugger interface
 KDbg is a graphical user interface to gdb, the GNU debugger.  It provides
 an intuitive interface for setting breakpoints, inspecting variables,
 stepping through code and much more.  KDbg requires KDE but you can of
 course debug any program.
 .
 KDbg can also debug XSLT (XML stylesheet translation) scripts by
 interfacing with xsldbg.  For this the package kxsldbg must be installed.
 .
 Features include the following:
  * Inspection of variable values in a tree structure.
  * Direct member: For certain compound data types the most important
member values are displayed next to the variable name, so that it is
not necessary to expand the subtree of that variable in order to see
the member value.  KDbg can also display Qt's QString values, which
are Unicode strings.
  * Debugger at your finger tips: The basic debugger functions (step,
next, run, finish, until, set/clear/enable/disable breakpoint) are
bound to function keys F5 through F10.  Quick and easy.
  * View source code, search text, set program arguments and environment
variables, display arbitrary expressions.
  * Debugging of core dumps, attaching to running processes is possible.
  * Conditional breakpoints.
Description-md5: 9ca644d0f21e4de1516bdaa4f9f17c9d
Homepage: http://www.kdbg.org/
Tag: devel::debugger, devel::lang:c, interface::x11, role::program,
 suite::kde, uitoolkit::qt, x11::application
Section: devel
Priority: optional
Filename: pool/main/k/kdbg/kdbg_2.5.4-1_amd64.deb
Size: 263136
MD5sum: 82d7a6e574b144b79586b1e0cc22ad0e
SHA1: eef298648541f340b268aaad7e5511ae5a62e8a1
SHA256: 53802415810d183fca60a64d082217c9d3065cb11e413709c749ced98fe33f29



signature.asc
Description: Digital signature

Bug#802173: remind: please ship ical2rem.pl and possibly other contrib scripts

[Ana Guerrero Lopez]

On Sun, Oct 18, 2015 at 02:40:36AM +0200, Per Andersson wrote:
> Package: remind
> Version: 03.01.15-1
> Severity: wishlist
> 
> Hi!
> 
> Please include ical2rem.pl, and possibly other scripts, from contrib in
> the remind Debian package.
> 
> Use case is that I have been looking for something that can parse iCal
> files sent to me via mail and record it in remind, via the command line
> from my mail user agent.
> 
> Maybe it can be included in examples?

Thanks Per. I'll add the scripts with the next upstream release.

Ana

Bug#797593: ITA: fabric -- Simple Pythonic remote deployment tool

[Ana Guerrero Lopez]

On Tue, Sep 08, 2015 at 10:46:50AM -0400, Andrew Starr-Bochicchio wrote:
> retitle 797593 ITA: fabric -- Simple Pythonic remote deployment tool
> owner 797593 a...@debian.org
> thanks
> 
> I had offered to co-maintain this in #760152, so I'm glad to pick it
> up. Might potentially move it to the PAPT.

Hi Andrew,
Thanks for adopting the package.
I replied you in #760152 and accepted the co-maintenance, see:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760152#15

I guess you missed that email or I wasn't clear enough.

Ana

Bug#799220: O: tintin++ -- classic text-based MUD client

[Ana Guerrero Lopez]

On Thu, Sep 17, 2015 at 01:05:29AM +0200, Adam Borowski wrote:
> On Thu, Sep 17, 2015 at 12:48:40AM +0200, Ana Guerrero Lopez wrote:
> > Adam Borowski has done some development in upstream so if he's interested
> > in adopting the package, he should have priority.
> 
> I have never interacted with tintin++'s upstream in any way.  I am guilty of
> a fork, but the code has seriously diverged, both in implementation and
> design.
>

Ok, I misread the changelog mention:
ssl.c  Added SSL support based on KBTin code by Adam Borowski.

I was surprised because I expected you to use KBTin :) Thanks for the
clarification Adam.

Ana

Bug#799220: O: tintin++ -- classic text-based MUD client

[Ana Guerrero Lopez]

Package: wnpp
Severity: normal

I have stopped playing MUDs, therefore I'm orphaning this package.
Adam Borowski has done some development in upstream so if he's interested
in adopting the package, he should have priority.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Description-en: classic text-based MUD client
 Tintin++ is telnet client specialized to play MUDs (Multi-User Dungeons).
 It has scripting support, tab-completion, internal chat, and takes
 advantage of the GNU readline library.
 .
 You can find a complete set of commands and features in the Tintin++ manual,
 in /usr/share/doc/tintin++.

Ana

Bug#797593: O: fabric -- Simple Pythonic remote deployment tool

[Ana Guerrero Lopez]

Package: wnpp
Severity: normal

I would like to orphan the package fabric.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: fabric
Binary: fabric
Version: 1.10.0-1
Maintainer: Ana Beatriz Guerrero Lopez 
Build-Depends: debhelper (>= 7.0.50~), python-all (>= 2.6.6-3~)
Build-Depends-Indep: python-setuptools, python-sphinx, python-paramiko, 
python-fudge, python-alabaster
Architecture: all
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 83517d517f5ed23afd826e42d200cdba 1968 fabric_1.10.0-1.dsc
 2cb96473387f0e7aa035210892352f4a 208969 fabric_1.10.0.orig.tar.gz
 b465f70df91a954505e88a3c9c1a4af2 4036 fabric_1.10.0-1.debian.tar.xz
Vcs-Browser: http://anonscm.debian.org/cgit/collab-maint/fabric.git
Vcs-Git: git://anonscm.debian.org/collab-maint/fabric.git
Checksums-Sha1:
 b4670aaa904ea2b2e59d2ead102d3dbc029ef54e 1968 fabric_1.10.0-1.dsc
 24c0819904f751d179f8a01a84bc2c46f1339df5 208969 fabric_1.10.0.orig.tar.gz
 b4ca045ba0c9390c953a1d957442deab288cb90e 4036 fabric_1.10.0-1.debian.tar.xz
Checksums-Sha256:
 c7cf00ea5b809137442d0253a514bf5b8122055b26b66862cef2949277470f9e 1968 
fabric_1.10.0-1.dsc
 edb2702b4655600f0a49a97e654c79f5b21490ce30f77d1313dd851f0b60335a 208969 
fabric_1.10.0.orig.tar.gz
 5ba81a53112de50ba6997dd92f2faef4c8d8222db0efa4c84b4309bfa37b3b9c 4036 
fabric_1.10.0-1.debian.tar.xz
Homepage: http://fabfile.org/
Package-List: 
 fabric deb net optional arch=all
Directory: pool/main/f/fabric
Priority: source
Section: net

Package: fabric
Version: 1.10.0-1
Installed-Size: 1387
Maintainer: Ana Beatriz Guerrero Lopez 
Architecture: all
Depends: python (>= 2.7), python (<< 2.8), python-paramiko (>= 1.10), 
python-pkg-resources, python-nose
Suggests: libjs-jquery
Description-en: Simple Pythonic remote deployment tool
 Fabric is designed to upload files and run shell commands on a number of
 servers in parallel or serially. These commands are grouped in tasks (which
 are regular Python functions) and specified in a 'fabfile.'
 .
 It is similar to Capistrano, except it's implemented in Python and doesn't
 expect you to be deploying Rails applications.
Description-md5: c14df4c925efbb493f2617dfc04bc4c2
Homepage: http://fabfile.org/
Section: net
Priority: optional
Filename: pool/main/f/fabric/fabric_1.10.0-1_all.deb
Size: 215798
MD5sum: 3ac0e98ad4ae86821c5e288a2e81a601
SHA1: 186bf1f0a63e70d64020997291a70b13ccb5423c
SHA256: d643d45b5762c93b2c329e72e840c49fe1c97aa56dd03dc7a13338228275f54c

Bug#797248: [Pkg-ofed-devel] Bug#797248: mstflint: FTBFS: error: ‘curr_toc’ ... [-Werror=maybe-uninitialized]

[Ana Guerrero Lopez]

On Fri, Aug 28, 2015 at 10:30:43PM +0100, Chris West (Faux) wrote:
 Source: mstflint
 Version: 4.0.1+1.43.g97d7275-1
 Severity: serious
 Justification: fails to build from source
 Tags: sid stretch
 User: reproducible-bui...@lists.alioth.debian.org
 Usertags: ftbfs
 X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
 
 Dear Maintainer,
 
 The package fails to build, probably due to gcc upgrades:

I can confirm. Thank you for reporting!

Ana

Bug#793212: yakuake: Yakuake don't detect newer version of konsole

[Ana Guerrero Lopez]

On Wed, Jul 22, 2015 at 02:53:18PM +0200, rollopack wrote:
 Package: yakuake
 Version: 2.9.9-1
 Severity: grave
 Justification: renders package unusable
 
 Dear Maintainer,
 
 with konsole 4:14.12.3-1 yakuake on opening a tab report the error: Yakuake
 was unable to load the Konsole component.
 A Konsole installation is required to use Yakuake.

Have you restarted your KDE session after the upgrade?

Ana


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778016: NMU guide

[Ana Guerrero Lopez]

Hi doko,

I think it would be a useful time investement for you to read:

https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu

Ana


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778016: NMU guide

[Ana Guerrero Lopez]

Hi Matthias,

On Wed, Jul 08, 2015 at 08:23:13PM +0200, Matthias Klose wrote:
 On 07/08/2015 08:15 PM, Ana Guerrero Lopez wrote:
  
  Hi doko,
 
 Matthias
 
  
  I think it would be a useful time investement for you to read:
  
  https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu
 
 Upload fixing only release-critical bugs older than 7 days, with no maintainer
 activity on the bug for 7 days and no indication that a fix is in progress: 0 
 days
 
 so what is wrong about it?

The part where you skip other bits mentioned there like sending the nmudiff
to the bug report?  :)
 
 I remember you reacted the same way in the past, instead of addressing the
 issue. The issue is open since February, the severity was raised eight days 
 ago.

When? Care to give me a link please?

What I remember is you quite often NMUing packages without following the 
mentioned 
guidelines and people angry at you. You're NMUing plenty of packaes that if you
would have care to ping people before, it would have been doing for 
maintainer(s),
saving you plenty of time.

Ana


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784854: MIA for Karolina Kalic karol...@resenje.org

[Ana Guerrero Lopez]

On Mon, May 18, 2015 at 10:58:08AM +0200, Karolina Kalic wrote:
 Hi everybody,
 
 As I can remember, MIA team contacted me a while ago. And I explained
 that I can not continue my work for Debian at the moment. The packages
 should have been orphaned properly after that. I don't know what
 happened. I'm glad that someone wants to continue the work on unico. I
 don't have any objections.

Thanks for the reply Karolina.
There was a misunderstanding here, somebody decided to orphan the package
in their own and later when Ricardo Mones from the MIA team orphaned it
properly, he kept the first bug and merged it with his own orphaning but
from the  MIA team. Vincent probably overlooked the second orphaning bug
and therefore his, understandable, request about following the MIA procedure.

So please James Lu, feel free to adopt the package. Vincent or Dmitry
feel free to sponsor it and Karolina, I hope you'll be able to be back
in the project in the future!

Ana
on behalf of the MIA team


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784448: [amarok] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: amarok
Version: 2.8.0-2.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784455: [cb2bib] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: cb2bib
Version: 1.4.9-4
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784456: [cantata] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: cantata
Version: 1.5.2.ds2-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Multimedia Maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784459: [cutycapt] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: cutycapt
Version: 0.0~svn6-3.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear David Paleino da...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784461: [fatrat] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: fatrat
Version: 1.1.3-5
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Cristian Greco crist...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784468: [goldendict] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: goldendict
Version: 1.5.0~git20131003-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Dmitry E. Oboukhov un...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784460: [digikam] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: digikam
Version: 4:4.4.0-1.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784466: [gammaray] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: gammaray
Version: 2.1.0-3.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784465: [gambas3] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: gambas3
Version: 3.5.4-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Gambas Debian Maintainers pkg-gambas-de...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784472: [kadu] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: kadu
Version: 1.3-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Patryk Cisek pat...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784464: [freecad] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: freecad
Version: 0.14.3702+dfsg-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784462: [fcitx-libpinyin] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: fcitx-libpinyin
Version: 0.3.1-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear IME Packaging Team pkg-ime-de...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784473: [kadu-mime-tex] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: kadu-mime-tex
Version: 1.0-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Patryk Cisek pat...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784467: [goldencheetah] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: goldencheetah
Version: 3.1.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear KURASHIKI Satoru lur...@gmail.com,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784463: [fontmatrix] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: fontmatrix
Version: 0.6.0+svn20110930-1.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Oleksandr Moskalenko ma...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784470: [hotot] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: hotot
Version: 1:0.9.8.14-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian QA Group packa...@qa.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784471: [k3b] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: k3b
Version: 2.0.2-8
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784477: [kde-runtime] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: kde-runtime
Version: 4:4.14.2-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784475: [kbibtex] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: kbibtex
Version: 0.4-4
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784474: [kalgebra] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: kalgebra
Version: 4:4.14.2-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784494: [merkaartor] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: merkaartor
Version: 0.18.1-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Bernd Zeimetz b...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784490: [kvirc] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: kvirc
Version: 4:4.2.0-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784493: [libqt4pas] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: libqt4pas
Version: 2.5-12
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Matthias Klumpp m...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784488: [ktp-auth-handler] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: ktp-auth-handler
Version: 0.8.1-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784496: [mixxx] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: mixxx
Version: 1.11.0~dfsg-4
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Multimedia Maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784495: [mathgl] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: mathgl
Version: 2.2.2.1-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Science Maintainers 
debian-science-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784497: [metview] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: metview
Version: 4.4.8+dfsg.1-8
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Alastair McKinstry mckins...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784500: [navit] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: navit
Version: 0.5.0~svn5900+dfsg.1-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Gilles Filippini p...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784506: [phantomjs] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: phantomjs
Version: 1.9.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear TANIGUCHI Takaki tak...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784499: [musescore] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: musescore
Version: 1.3+dfsg1-0.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Toby Smithe tsmi...@ubuntu.com,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784503: [openwalnut] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: openwalnut
Version: 1.4.0~rc1+hg3a3147463ee2-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Sebastian Eichelbaum eichelb...@informatik.uni-leipzig.de
Sebastian Eichelbaum openwal...@nemtics.com,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784502: [openms] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: openms
Version: 1.11.1-5
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear The Debichem Group debichem-de...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784501: [nmapsi4] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: nmapsi4
Version: 0.3.1-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Giuseppe Iuculano iucul...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784507: [plasma-widget-adjustableclock] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: plasma-widget-adjustableclock
Version: 4.1.4-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Davi Leal d...@gnu.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784504: [owncloud-client] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: owncloud-client
Version: 1.7.0~beta1+really1.6.4+dfsg-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear ownCloud for Debian maintainers 
pkg-owncloud-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784505: [paraview] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: paraview
Version: 4.1.0+dfsg+1-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Science Team debian-science-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784498: [monkeystudio] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: monkeystudio
Version: 1.9.0.4-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Evgeni Golov evg...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784534: [ugene] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: ugene
Version: 1.12.3+dfsg-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784450: [arc-gui-clients] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: arc-gui-clients
Version: 0.4.6-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Mattias Ellert mattias.ell...@fysast.uu.se,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784457: [clam-networkeditor] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: clam-networkeditor
Version: 1.4.0-3.1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Multimedia Maintainers 
pkg-multimedia-maintain...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784453: [brewtarget] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: brewtarget
Version: 2.1.0-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Philip G. Lee rocketman...@gmail.com,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784458: [connectome-workbench] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: connectome-workbench
Version: 1.0-3
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear NeuroDebian Team t...@neuro.debian.net,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784449: [acetoneiso] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: acetoneiso
Version: 2.4-2
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Nick Andrik nick.and...@gmail.com,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784454: [calligra] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: calligra
Version: 1:2.8.5+dfsg-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784452: [basic256] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: basic256
Version: 0.9.6.69a-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Ryan Kavanagh r...@debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784451: [ball] Qt4's WebKit removal

[Ana Guerrero Lopez]

Source: ball
Version: 1.4.2+20140406-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4webkit-removal

Dear Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org,

As you might know we the Qt/KDE team are preparing to remove Qt4's WebKit
as announced in [announce].

[announce] 
https://lists.debian.org/debian-devel-announce/2015/05/msg1.html

Basically we are about to get the latest Qt4 point release and upstream is
migrating from WebKit to Bing in the Qt5 series, so we won't have much upstream
support for maintaining Qt4's WebKit.

In order to make this move, all packages directly or indirectly depending on
the Qt4's WebKit library 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. In
order to ease the transition time we have provided Wheezy backports for Qt5.

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/packagingqtstuff.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

Ana,
on behalf of the Qt4 maintainers


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org