Bug#896658: qtbase-opensource-src FTBFS on alpha: ambiguous call of atime()

[Michael Cree]

On Tue, May 01, 2018 at 10:21:11AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> > qtbase-opensource-src FTBFS on Alpha [1] due to an ambiguous
> 
> Thanks for the very clear explanation! There are two possible ways out here:
> 
> 1) Preferred by us Qt maintainers: file a bug in bugreports.qt.io and send us 
> the link so we can follow it. 

I've tired making an account there to report the bug. What a painful
experience: it tried to solicit information off me for commercial
advertising purposes (which is totally unacceptable), and after many
more painful and unclear steps I finally got to the bug web pages.

But I don't know what to do.  I can't work out the products or
components (none match the Debian source package names or seem
to bear much relationship to them) so I am totally lost.

I now regret attempting to make an account there and wish I could
just completely delete it.

Please, would you file the bug upstream, I'm not having anything
more to do with that obnoxious web site.

Cheers
Michael.

Bug#898320: kdeconnect: 1.3.0 does not work with 1.8.2 android version

[Eric Valette]

Le 11 mai 2018 20:37:06 GMT+02:00, Diederik de Haas  a 
écrit :
>On vrijdag 11 mei 2018 10:18:06 CEST Eric Valette wrote:
>> It can be on the client side (android both and 1.8.2 android version
>> both) but I have two differents. It could be network but no firewall
>and
>> both machines do see each other using ssh, upnp, ...
>
>With me it also fails from time to time and I have not found a pattern
>which 
>would explain it.
>What very often helps, is starting kdeconnect explicitly on my phone
>and that 
>either fixes it or gives me a clue why it fails, which often means
>re-pairing 
>the devices.

Thanks for the hint. I started KDE connect  explicitly, no help. I even added 
pc device by Name or ip without result. I'm good for a Wireshark session.

-- eric
-- 
Eric Valette

Bug#898447: [kwin-x11] Windows with Client-Side Decorations look badly and not resizeable

[Alexander Kernozhitsky]

Package: kwin-x11
Version: 4:5.12.4-1+b1
Severity: normal

I tried some apps with CSD (e. g. GNOME apps) on KDE. Their windows cannot be 
resized by dragging the borders and their decorations don't respect the KWin 
theme.

I know that there is a KWin script that fixes such issues. It's installed and 
enabled for me. But it doesn't give any effect. Disabling it doesn't change 
anything.

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

Debian Release: buster/sid
  990 testing ftp.by.debian.org 
  500 unstableftp.by.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-
==
kwin-common   (= 4:5.12.4-1+b1) | 4:5.12.4-1+b1
libkwinglutils11  (= 4:5.12.4-1+b1) | 4:5.12.4-1+b1
libkwinxrenderutils11 (= 4:5.12.4-1+b1) | 4:5.12.4-1+b1
libc6 (>= 2.14) | 
libepoxy0  (>= 1.0) | 
libgcc1  (>= 1:3.4) | 
libkf5configcore5   (>= 4.97.0) | 
libkf5coreaddons5   (>= 5.11.0) | 
libkf5crash5(>= 4.96.0) | 
libkf5i18n5 (>= 4.97.0) | 
libkf5quickaddons5  (>= 5.26.0) | 
libkf5waylandserver5  (>= 4:5.22.0) | 
libkf5windowsystem5 (>= 4.96.0) | 
libkwineffects11  (>= 4:5.1.95+git20150122) | 
libqt5core5a(>= 5.10.0) | 
libqt5gui5  (>= 5.9.0~) | 
libqt5widgets5  (>= 5.9.0~) | 
libqt5x11extras5 (>= 5.6.0) | 
libstdc++6   (>= 5) | 
libx11-6| 
libxcb-composite0   | 
libxcb-cursor0  (>= 0.0.99) | 
libxcb-keysyms1  (>= 0.4.0) | 
libxcb-randr0  (>= 1.3) | 
libxcb-render0  | 
libxcb-shape0   | 
libxcb-xfixes0  | 
libxcb1(>= 1.6) | 
libxi6  (>= 2:1.5.99.2) | 


Package's Recommends field is empty.

Package's Suggests field is empty.
-- 
-
Alexander Kernozhitsky

Bug#898320: kdeconnect: 1.3.0 does not work with 1.8.2 android version

[Diederik de Haas]

On vrijdag 11 mei 2018 10:18:06 CEST Eric Valette wrote:
> It can be on the client side (android both and 1.8.2 android version
> both) but I have two differents. It could be network but no firewall and
> both machines do see each other using ssh, upnp, ...

With me it also fails from time to time and I have not found a pattern which 
would explain it.
What very often helps, is starting kdeconnect explicitly on my phone and that 
either fixes it or gives me a clue why it fails, which often means re-pairing 
the devices.


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

Bug#898443: kpackage: flaky autopkgtest

[Paul Gevers]

Source: kpackage
Version: 5.42.0-2
Severity: important
User: debian...@lists.debian.org
Usertags: flaky

While inspecting regressions in autopkgtest results¹, I noticed that
your package kpackage fails regularly (5.45.0-1 hasn't even passed once
yet), without obvious changes. As far as I checked, the error is nearly
always the same (copied below).

Could you please investigate and make your autopkgtest more robust?
Please contact me if you need help and you think I can provide that (I
am not subscribed to this bug).

Recent discussion of gating migration by autopkgtests on debian-devel²
noted that if this is going to work, and in particular if we are going
to *block* migration when it causes autopkgtest regressions rather than
merely delaying it, intermittent autopkgtest failures are likely to have
to be considered RC due to their impact on the tested package's
dependencies; for now I've filed it as important.

Simon McVittie has previously proposed³ a way to mark autopkgtests as
unsuitable for gating CI, while still having them available for
convenient manual testing (and optionally run, but with their results
disregarded, on the real CI infrastructure so that their reliability can
be assessed), but this isn't currently possible. If the autopkgtest
can't be made reliable then it would make sense to disable it for the
moment.

Paul

¹ https://ci.debian.net/packages/k/kpackage/unstable/amd64/
² https://lists.debian.org/debian-devel/2018/05/msg00061.html
³ https://bugs.debian.org/851558

autopkgtest [13:54:56]: test testsuite: [---
cd obj-x86_64-linux-gnu && make -j8 test ARGS\+=-j8
Running tests...
/usr/bin/ctest --force-new-ctest-process -j8
Test project
/tmp/autopkgtest-lxc.m3zi8kbh/downtmp/build.JS4/src/obj-x86_64-linux-gnu
  Start  1: plasma-fallbackpackagetest
  Start  2: plasma-packagestructuretest
  Start  3: plasma-plasmoidpackagetest
  Start  4: plasma-rccpackagetest
  Start  6: testfallbackpackage-appstream
  Start  7: testpackage-appstream
  Start  8: testpackage-nodisplay-appstream
  Start  9: testjsonmetadatapackage-appstream
 1/11 Test  #7: testpackage-appstream ...   Passed0.11 sec
 2/11 Test  #8: testpackage-nodisplay-appstream .   Passed0.11 sec
 3/11 Test  #3: plasma-plasmoidpackagetest ..***Failed0.11 sec
* Start testing of PlasmoidPackageTest *
Config: Using QtTest library 5.9.2, Qt 5.9.2 (x86_64-little_endian-lp64
shared (dynamic) release build; by GCC 7.3.0)
PASS   : PlasmoidPackageTest::initTestCase()
QDEBUG : PlasmoidPackageTest::createAndInstallPackage()
PlasmoidPackage::init()
QDEBUG : PlasmoidPackageTest::createAndInstallPackage() cleaning up
QDEBUG : PlasmoidPackageTest::createAndInstallPackage()
QDEBUG : PlasmoidPackageTest::createAndInstallPackage()CreateAndInstall
QDEBUG : PlasmoidPackageTest::createAndInstallPackage() Create test
package "/home/debci/.qttest/share/packageRoot"
QDEBUG : PlasmoidPackageTest::createAndInstallPackage() Created
"/home/debci/.qttest/share/packageRoot/plasmoid_to_package"
QDEBUG : PlasmoidPackageTest::createAndInstallPackage() OUT:
"plasmoid_to_package"
QDEBUG : PlasmoidPackageTest::createAndInstallPackage() THIS IS A
PLASMOID SCRIPT THING
FAIL!  : PlasmoidPackageTest::createAndInstallPackage()
'QFile::exists(packagePath)' returned FALSE. ()
   Loc:
[/tmp/autopkgtest-lxc.m3zi8kbh/downtmp/build.JS4/src/autotests/plasmoidpackagetest.cpp(277)]
QDEBUG : PlasmoidPackageTest::createAndInstallPackage() cleaning up
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage()
PlasmoidPackage::init()
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() cleaning up
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage()
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage()CreateAndUpdate
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() Create test
package "/home/debci/.qttest/share/packageRoot"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() Created
"/home/debci/.qttest/share/packageRoot/plasmoid_to_package"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() OUT:
"plasmoid_to_package"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() THIS IS A
PLASMOID SCRIPT THING
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() Installing
"/home/debci/.qttest/share/packageRoot/testpackage.plasmoid"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage()
 package installed true ""
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() "Not installing
version 1.1 of plasmoid_to_package. Version 1.1 already installed."
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() Create test
package "/home/debci/.qttest/share/packageRoot"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() Created
"/home/debci/.qttest/share/packageRoot/plasmoid_to_package"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() OUT:
"plasmoid_to_package"
QDEBUG : PlasmoidPackageTest::createAndUpdatePackage() THIS IS A
PLASMOID SCRIPT THING

Re: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

Hi,

On Fri, 11 May 2018, Maximiliano Curia wrote:
> > Sophie and me are working to bring pyside2 into Debian. We would like to
> > put it in pkg-kde-extras. I requested access to the salsa group for this.
> 
> Welcome to the team!

Thank you. Note that you granted me "developer" access which doesn't let
me create new repositories, so I will need one of you to create the
repository and also to add sophie (sbrun-guest) as member of the
pyside2 repository.

> Right, but please take into account that the packages maintained under the
> qt tree use a debian directory only packaging branch, and in general, they
> use all the same packaging structure (no dpm, no upstream branches or tags
> in the public repos, etc). This set of rules is more relaxed in qt-extras
> and kde-extras.

Are the rules documented somewhere?

At this point, there are no (versioned) upstream tarball releases so it
might be better to be able to have full sources in the git repository and
generate the .orig.tar.gz out of it.

> Also, I don't see in the bug log any comment about the current pyside
> maintenance, are the pyside maintainers ok with moving the new version of
> the project to a different repository in a different team?

There are no Uploaders left in debian/control both for pyside and
shiboken:
https://salsa.debian.org/python-team/modules/shiboken/blob/master/debian/control
https://salsa.debian.org/python-team/modules/pyside/blob/master/debian/control

On Fri, 11 May 2018, Dmitry Shachnev wrote:
> It looks like pyside2 will use the same release cycle as Qt uses, so we
> will most likely have to update it together with the other Qt modules.

And at least the version embedded in the code matches the Qt version, yes.

> As far as I know, there are no current pyside 1.x maintainers. So there is
> nobody who can complain about this move.

Indeed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#898419: Fixed by installing okular-extra-backends

[Johannes Ranke]

When reading my own bug report I noticed that okular suggests okular-extra-
backends. After installing this, I can correctly view multipage tiff files 
again.

I am not sure if the packaging could be improved so that the user opening such 
a file would get a hint about the availability of this package.

Re: Bug#877871: RFP: pyside2 -- Python bindings for Qt5

[Dmitry Shachnev]

Hi all,

First of all, thanks Raphaël and Sophie for working on PySide2 packaging!

On Fri, May 11, 2018 at 10:25:57AM +0200, Maximiliano Curia wrote:
> > Should it go in "Qt" or "Qt extras"? It's going to be something official by
> > the upstream Qt project so I think that "Qt" might be good.
>
> Right, but please take into account that the packages maintained under the
> qt tree use a debian directory only packaging branch, and in general, they
> use all the same packaging structure (no dpm, no upstream branches or tags
> in the public repos, etc). This set of rules is more relaxed in qt-extras
> and kde-extras.

It looks like pyside2 will use the same release cycle as Qt uses, so we
will most likely have to update it together with the other Qt modules.

It would be a bit easier for us if you put it into the Qt namespace and
followed our packaging scheme (debian/ only repository), but Qt extras and
whatever repo structure should work too.

> Also, I don't see in the bug log any comment about the current pyside
> maintenance, are the pyside maintainers ok with moving the new version of
> the project to a different repository in a different team?

As far as I know, there are no current pyside 1.x maintainers. So there is
nobody who can complain about this move.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Re: RFP: pyside2 -- Python bindings for Qt5

[Maximiliano Curia]

¡Hola Raphael!

El 2018-05-11 a las 09:46 +0200, Raphael Hertzog escribió:

Control: retitle -1 ITP: pyside2 -- Qt for Python
Control: owner -1 sop...@freexian.com



On Sat, 14 Apr 2018 10:09:38 +0200 Francesco Poli  
wrote:

Moreover, if I read the [announcement] correctly, it seems that PySide2
is going to be renamed as "Qt for Python" and adopted as official Qt
bindings for Python...



[announcement]: 




I really hope someone with good Python Debian packaging skills will
soon package pyside2 for inclusion in Debian!



Sophie and me are working to bring pyside2 into Debian. We would like to
put it in pkg-kde-extras. I requested access to the salsa group for this.


Welcome to the team!


Should it go in "Qt" or "Qt extras"? It's going to be something official by
the upstream Qt project so I think that "Qt" might be good.


Right, but please take into account that the packages maintained under the qt 
tree use a debian directory only packaging branch, and in general, they use 
all the same packaging structure (no dpm, no upstream branches or tags in the 
public repos, etc). This set of rules is more relaxed in qt-extras 
and kde-extras.


Also, I don't see in the bug log any comment about the current pyside 
maintenance, are the pyside maintainers ok with moving the new version of the 
project to a different repository in a different team?


Happy hacking,
--
"If a million people believe a foolish thing, it is still a foolish thing."
-- France's Rule of Folly
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#898320: kdeconnect: 1.3.0 does not work with 1.8.2 android version

[Eric Valette]

On 5/11/18 12:42 AM, Lisandro Damián Nicanor Pérez Meyer wrote:

Control: severity -1 important

Hi Eric!


Hi,



Works perfectly for me, no changes whatsoever. Maybe you have a
problem in your network?


Well. I'm currently on vacation testing on my laptop (instead of desktop 
at home where it first started to fail) and have two differents clients 
(mobile and tablet) and nothing works on either devices.


It can be on the client side (android both and 1.8.2 android version 
both) but I have two differents. It could be network but no firewall and 
both machines do see each other using ssh, upnp, ...


Tried to debug with kdeconnect_cli but have no meaningfull printing. I'm 
using IPV4 only network.


Nevertheless thanks for checking and passing the info.

--eric

Re: RFP: pyside2 -- Python bindings for Qt5

[Raphael Hertzog]

Control: retitle -1 ITP: pyside2 -- Qt for Python
Control: owner -1 sop...@freexian.com

On Sat, 14 Apr 2018 10:09:38 +0200 Francesco Poli  
wrote:
> Moreover, if I read the [announcement] correctly, it seems that PySide2
> is going to be renamed as "Qt for Python" and adopted as official Qt
> bindings for Python...
> 
> [announcement]: 
> 
> 
> I really hope someone with good Python Debian packaging skills will
> soon package pyside2 for inclusion in Debian!

Sophie and me are working to bring pyside2 into Debian. We would like to
put it in pkg-kde-extras. I requested access to the salsa group for this.

Should it go in "Qt" or "Qt extras"? It's going to be something official by
the upstream Qt project so I think that "Qt" might be good.

Currently the code is split among two git repositories upstream:
https://code.qt.io/cgit/pyside/pyside-setup.git/
https://code.qt.io/cgit/pyside/pyside-tools.git/

pyside-setup contains PySide2 and Shiboken2 (and pyside2-tools as
submodule).

I think we will want to name the source package and the git repository
"pyside2" anyway. And we possibly want to integrate pyside-tools
in the .orig.tar.gz as well.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/