Bug#918295: sddm: deactivating Wi-Fi from SDDM login page deactivates trackpad

[Cédric Boutillier]

Package: sddm
Version: 0.18.0-1
Severity: normal

Dear Maintainer,

I have an HP EliteBook 820 Laptop with a separate button to switch
on/off Wi-Fi (xev reports: keycode 255 (keysym 0x0, NoSymbol)
When trying to switch on/off wifi from the sddm login screen, the
trackpad gets disabled (the on-screen logo is displayed). Pushing the
same button a second time doesn't switch back on the trackpad.

Once logged in inside KDE, I can switch on again the trackpad from KDE
(I set up even a keyboard shortcut for that), and the Wifi button
doesn't alter its state anymore, and fulfills only its function.

Sddm is somehow messing with the mapping for this special key.

Thanks in advance. Let me know if you need more information.

Cédric


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

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

Versions of packages sddm depends on:
ii  adduser 3.118
ii  debconf [debconf-2.0]   1.5.69
ii  libc6   2.28-4
ii  libgcc1 1:8.2.0-13
ii  libpam0g1.1.8-3.8
ii  libqt5core5a5.11.2+dfsg-7
ii  libqt5dbus5 5.11.2+dfsg-7
ii  libqt5gui5  5.11.2+dfsg-7
ii  libqt5network5  5.11.2+dfsg-7
ii  libqt5qml5  5.11.2-3
ii  libqt5quick55.11.2-3
ii  libstdc++6  8.2.0-13
ii  libsystemd0 240-2
ii  libxcb-xkb1 1.13.1-2
ii  libxcb1 1.13.1-2
ii  qml-module-qtquick2 5.11.3-2
ii  x11-common  1:7.7+19
ii  xserver-xorg [xserver]  1:7.7+19
ii  xvfb [xserver]  2:1.20.3-1

Versions of packages sddm recommends:
ii  haveged 1.9.1-6
ii  libpam-systemd  240-2
ii  sddm-theme-breeze [sddm-theme]  4:5.14.3-1+b1

Versions of packages sddm suggests:
ii  libpam-kwallet5   5.14.3-1
ii  qtvirtualkeyboard-plugin  5.11.2+dfsg-2+b1

-- debconf information:
* shared/default-x-display-manager: sddm
  sddm/daemon_name: /usr/bin/sddm

Bug#858720: A colord-kde Color profiles not loading on startup

[Christian Kanzian]

Dear Maintainer,

Package: colord-kde
Version: 0.5.0-2

> I was able to load the profile, however on restart the color correction was  
> not applied. Going back into colord-kde, the selector was on the correct 
> profile, but only moving the selector to default, then back to the profile, 
> loads the profile again. At the moment I'm manually doing this on startup as
> a workaround.

I can't confirm this issue after using colord-kde for more than one year on 
Debian 9. Installed screen profiles load fine after every startup. 

The color management test routine of darktable confirms that the profile is 
installed correctly:

$ darktable-cmstest 
darktable-cmstest version 2.7.0+145~gfe2ee31fb
this executable was built with colord support enabled
darktable itself was built with colord support enabled

primary CRTC is at CRTC 0
CRTC for screen 0 CRTC 1 has no mode or no output, skipping
CRTC for screen 0 CRTC 2 has no mode or no output, skipping
CRTC for screen 0 CRTC 3 has no mode or no output, skipping

DVI-D-0 the X atom and colord returned the same profile
X atom: _ICC_PROFILE (23224 bytes)
description: EV2436W 2019-01-01 D6500 2.2 S 3xCurve+MTX
colord: "/home/chri/.local/share/icc/EV2436W 2019-01-01 D6500 2.2 S 
3xCurve+MTX.icc"
description: EV2436W 2019-01-01 D6500 2.2 S 3xCurve+MTX

Your system seems to be correctly configured

So I think this issue could be closed?

All the best,
Christian

qttools-opensource-src_5.11.3-3_amd64.changes is NEW

[Debian FTP Masters]

binary:qdoc-qt5 is NEW.
binary:qdoc-qt5 is NEW.

Your package has been put into the NEW queue, which requires manual action
from the ftpteam to process. The upload was otherwise valid (it had a good
OpenPGP signature and file hashes are valid), so please be patient.

Packages are routinely processed through to the archive, and do feel
free to browse the NEW queue[1].

If there is an issue with the upload, you will receive an email from a
member of the ftpteam.

If you have any questions, you may reply to this email.

[1]: https://ftp-master.debian.org/new.html
 or https://ftp-master.debian.org/backports-new.html for *-backports

Processing of qttools-opensource-src_5.11.3-3_amd64.changes

[Debian FTP Masters]

qttools-opensource-src_5.11.3-3_amd64.changes uploaded successfully to localhost
along with the files:
  qttools-opensource-src_5.11.3-3.dsc
  qttools-opensource-src_5.11.3-3.debian.tar.xz
  libqt5designer5-dbgsym_5.11.3-3_amd64.deb
  libqt5designer5_5.11.3-3_amd64.deb
  libqt5designercomponents5-dbgsym_5.11.3-3_amd64.deb
  libqt5designercomponents5_5.11.3-3_amd64.deb
  libqt5help5-dbgsym_5.11.3-3_amd64.deb
  libqt5help5_5.11.3-3_amd64.deb
  qdbus-qt5-dbgsym_5.11.3-3_amd64.deb
  qdbus-qt5_5.11.3-3_amd64.deb
  qdoc-qt5-dbgsym_5.11.3-3_amd64.deb
  qdoc-qt5_5.11.3-3_amd64.deb
  qt5-assistant-dbgsym_5.11.3-3_amd64.deb
  qt5-assistant_5.11.3-3_amd64.deb
  qttools-opensource-src_5.11.3-3_amd64.buildinfo
  qttools5-dev-tools-dbgsym_5.11.3-3_amd64.deb
  qttools5-dev-tools_5.11.3-3_amd64.deb
  qttools5-dev_5.11.3-3_amd64.deb
  qttools5-doc-html_5.11.3-3_all.deb
  qttools5-doc_5.11.3-3_all.deb
  qttools5-examples-dbgsym_5.11.3-3_amd64.deb
  qttools5-examples_5.11.3-3_amd64.deb
  qttools5-private-dev_5.11.3-3_amd64.deb

Greetings,

Your Debian queue daemon (running on host usper.debian.org)

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Dmitry Shachnev]

On Wed, Jan 02, 2019 at 06:36:45PM +0100, John Paul Adrian Glaubitz wrote:
> > What do you think of splitting qdoc into a separate package?
> >
> > This way the packages that need it might explicitly build-depend on that
> > package and dep-wait instead of getting build failures on some 
> > architectures.
>
> That would be awesome. Thanks a lot for that.
>
> [...]
>
> I'm fine waiting for the qttools upload taking longer if it has to go
> through NEW. If I know the issue is being worked on, I can continue
> applying the temporary fix in Debian Ports.

Thanks Adrian, James and Lisandro for your feedback!

I have just uploaded the fix, it will land in the binNEW queue soon.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Test

[Lisandro Damián Nicanor Pérez Meyer]

Exactly that

Re: Jessie update of qtbase-opensource-src?

[Dmitry Shachnev]

Hi Ola!

On Fri, Dec 28, 2018 at 10:35:00PM +0100, Ola Lundqvist wrote:
> Hi
>
> I started to look at excluding the uploaders and just include the
> maintainer but it turned out to be problematic. At least to make it a
> general thing. I can make a dirty hack but I do not think that would be
> very useful since we do not contact you that often.
>
> The problem is that the uploaders and maintainers are reported the same in
> https://packages.qa.debian.org/q/qtbase-opensource-src.rdf
> or more generally
> https://packages.qa.debian.org/$section/$package.rdf
>
> Do anyone know why this is so, and whether we have any other source of data
> to conclude this? Without actually parsing html content...

Why not just send a mail to $pack...@packages.debian.org?

This way the maintainer and all interested/subscribed people will get
your mail.

This is documented in .

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#918080: breeze-gtk: symlink /usr/share/themes/Breeze/{gtk-3.20,gtk-3.0}/

[Maximiliano Curia]

¡Hola Simon!

El 2019-01-02 a las 21:25 -0600, Simon Quigley escribió:

Package: breeze-gtk
Severity: normal
Version: 5.14.3-1



It was raised to my attention from LXQt users that the Breeze GTK theme
cannot be used under LXQt as packaged. This is because the theme exists
in /usr/share/themes/Breeze/gtk-3.18/ and
/usr/share/themes/Breeze/gtk-3.20/ but doesn't exist in
/usr/share/themes/Breeze/gtk-3.0/ which is inconsistent to other GTK
themes in the archive. For example, the arc-theme package just installs
in gtk-3.0.



This raises a few questions for me. Is this just a hidden use of the
standard, or something Plasma-specific? Are the themes meant to only be
used on those minor versions of GTK?



Simply symlinking gtk-3.20 to gtk-3.0 solves the problem under LXQt. Is
it rational to ship this as default?


The theme was adapted to gtk 3.20 (which includes some incompatible changes 
with themes designed for previous gtk versions) and the adapted version is 
shipped in the gtk-3.20 folder, sadly the older version was moved to the 
gtk-3.18 folder. The folder name implies $GTK_VERSION >= 3.20, 
thus it would be wrong to rename it to gtk-3.0 . The gtk-3.18 folder, on the 
other hand, could be renamed, but we don't have a gtk-3 versions older than 
3.18, or even older than 3.20, so that's not really necessary.


I would suspect that lxqt is filtering the themes that that have a gtk-3.0 
folder in them, while a filter for themes that have a gtk-3.* folder would 
yield better results.


Happy hacking,
--
"Politicians and diapers have one thing in common. They should both be changed 
regularly, and for the same reason."

-- José Maria de Eça de Queiroz
Saludos /\/\ /\ >< `/



signature.asc
Description: PGP signature

Re: latte-dock_0.7.4-1_amd64.changes REJECTED

[Bastian Blank]

Hi

On Fri, Jan 04, 2019 at 08:28:34AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> El viernes, 4 de enero de 2019 07:10:09 -03 Bastian Blank escribió:
> > Please don't re-use versions.
> I understand that by: "if you uploaded 1.2.3-1 don't reupload 1.2.3-1, bu 
> better 1.2.3-2" Is that right? If it is: what's the problem? The package has 
> never reached the archive, so it virtually never existed. Except some tool 
> requires it :-/

We index our notes on packages by name+version, but we don't keep a full
history.  So while cleaning up my own notes I found a matching package
and only a deep look showed that this is not longer the same.

> > po/ca/* and others are LGPL 2.1 or 3, without generic or later clause,
> > so "LGPL-2.1+ or LGPL-3+" is incorrect.
> Fair, but does it *really* deserves a reject? The license is still dfsg 
> compliant and there is only one tiny little fix which can be fixed on the 
> next 
> upload. An accept + RC bug could also work here.

For attributions we now tend to do that, but not for listing too broad
licenses.

Regards,
Bastian

-- 
Respect is a rational process
-- McCoy, "The Galileo Seven", stardate 2822.3

Re: latte-dock_0.7.4-1_amd64.changes REJECTED

[Lisandro Damián Nicanor Pérez Meyer]

Hi Bastian!

El viernes, 4 de enero de 2019 08:52:14 -03 Bastian Blank escribió:
> Hi
> 
> On Fri, Jan 04, 2019 at 08:28:34AM -0300, Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > El viernes, 4 de enero de 2019 07:10:09 -03 Bastian Blank escribió:
> > > Please don't re-use versions.
> > 
> > I understand that by: "if you uploaded 1.2.3-1 don't reupload 1.2.3-1, bu
> > better 1.2.3-2" Is that right? If it is: what's the problem? The package
> > has never reached the archive, so it virtually never existed. Except some
> > tool requires it :-/
> 
> We index our notes on packages by name+version, but we don't keep a full
> history.  So while cleaning up my own notes I found a matching package
> and only a deep look showed that this is not longer the same.

I see, fair point. Is this preference published somewhere (doc, wiki, 
whatever)?

> > > po/ca/* and others are LGPL 2.1 or 3, without generic or later clause,
> > > so "LGPL-2.1+ or LGPL-3+" is incorrect.
> > 
> > Fair, but does it *really* deserves a reject? The license is still dfsg
> > compliant and there is only one tiny little fix which can be fixed on the
> > next upload. An accept + RC bug could also work here.
> 
> For attributions we now tend to do that, but not for listing too broad
> licenses.

There might be some logic behind that I guess. That's also fair.

Not to "bang you" (sorry, english vocabulary missing for this one) with this 
to you specifically, but it would be really *awesome* if all this details 
could be read somewhere.

Thanks for your replies!

-- 
Super cow powers | bbq > /dev/stomach
  Traveler1, seen on #debian-ar, irc.oftc.net

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


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

Re: latte-dock_0.7.4-1_amd64.changes REJECTED

[Lisandro Damián Nicanor Pérez Meyer]

Hi Thorsten!

El viernes, 4 de enero de 2019 08:44:04 -03 Thorsten Alteholz escribió:
> Hi Lisandro,
> 
> On Fri, 4 Jan 2019, Lisandro Damián Nicanor Pérez Meyer wrote:
> >> po/ca/* and others are LGPL 2.1 or 3, without generic or later clause,
> >> so "LGPL-2.1+ or LGPL-3+" is incorrect.
> > 
> > Fair, but does it *really* deserves a reject? The license is still dfsg
> > compliant and there is only one tiny little fix which can be fixed on the
> > next upload. An accept + RC bug could also work here.
> 
> what would be the difference on your side? You still have to do a second
> upload. If you even tell us about that upload, odds for a short time in
> NEW are high.

Well, that's exactly what did not happen with this upload. Fair, it was a 
second upload and it still contained a bug (my bad), but I've uploaded it and 
replied to the REJECT mail. It took yet one more month to get to this reject.

> In case of a bug we have to check whether you took care of the bug or just
> lowered the severity. Unfortunately this has happened in the past, so to
> reduce our workload, yes, this deserves a reject.

That's a fair point. I do wonder if a technical solution could be found for 
this, at very least to reduce time in NEW queue (latte-dock already has almost 
8 months in the queue in it's history).

Thanks for the reply!

-- 
En los momentos de crisis, la imaginación es mas importante que el
conocimiento.
 Albert Einstein

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


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

Re: latte-dock_0.7.4-1_amd64.changes REJECTED

[Thorsten Alteholz]

Hi Lisandro,

On Fri, 4 Jan 2019, Lisandro Damián Nicanor Pérez Meyer wrote:

po/ca/* and others are LGPL 2.1 or 3, without generic or later clause,
so "LGPL-2.1+ or LGPL-3+" is incorrect.


Fair, but does it *really* deserves a reject? The license is still dfsg
compliant and there is only one tiny little fix which can be fixed on the next
upload. An accept + RC bug could also work here.


what would be the difference on your side? You still have to do a second 
upload. If you even tell us about that upload, odds for a short time in 
NEW are high.
In case of a bug we have to check whether you took care of the bug or just 
lowered the severity. Unfortunately this has happened in the past, so to 
reduce our workload, yes, this deserves a reject.


  Thorsten

Re: latte-dock_0.7.4-1_amd64.changes REJECTED

[Lisandro Damián Nicanor Pérez Meyer]

Hi Bastien! This observations did create me some doubts, so:

El viernes, 4 de enero de 2019 07:10:09 -03 Bastian Blank escribió:
> Please don't re-use versions.

I understand that by: "if you uploaded 1.2.3-1 don't reupload 1.2.3-1, bu 
better 1.2.3-2" Is that right? If it is: what's the problem? The package has 
never reached the archive, so it virtually never existed. Except some tool 
requires it :-/

> Also you still did not provide the correct license of several files:
> 
> po/ca/* and others are LGPL 2.1 or 3, without generic or later clause,
> so "LGPL-2.1+ or LGPL-3+" is incorrect.

Fair, but does it *really* deserves a reject? The license is still dfsg 
compliant and there is only one tiny little fix which can be fixed on the next 
upload. An accept + RC bug could also work here.

This is actually the exact example of what I have been discussing with DPL not 
so long ago :-/

Thanks for your work, Lisandro.

-- 
10: El procesador de textos es:
* Un programa que le da vida a una computadora haciendo que
intente dominar el mundo (ver pregunta 1)
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

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


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

Bug#898696: Similar problem with version 4:18.08.1

[Pedro Celestino dos Reis Rodrigues]

For me this behavior starts after upgrading to 4:18.08.1

Thanks for any help

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

latte-dock_0.7.4-1_amd64.changes REJECTED

[Bastian Blank]

Please don't re-use versions.

Also you still did not provide the correct license of several files:

po/ca/* and others are LGPL 2.1 or 3, without generic or later clause,
so "LGPL-2.1+ or LGPL-3+" is incorrect.




===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.