Bug#1069546: ktorrent: FTBFS on armel: dh_install: error: missing files, aborting

[Aurélien COUDERC]

Control: severity -1 wishlist

Bug#1069546: ktorrent: FTBFS on armel: dh_install: error: missing files, aborting

[Aurélien COUDERC]

Control: retitle -1 ktorrent: FTBFS on arches without QtWebEngine
Control: severity -1 whishlist
Control: tags -1 + wontfix

Le 20 avril 2024 15:23:30 GMT+02:00, Lucas Nussbaum  a écrit :
>Source: ktorrent
>Version: 22.12.3-2
>Severity: serious
>Justification: FTBFS
>Tags: trixie sid ftbfs
>User: lu...@debian.org
>Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel
>
>Hi,

Dear Lucas,

>During a rebuild of all packages in sid, your package failed to build
>on armel.

what happens is that on arches that don't have QtWebEngine, the ktorrent build 
succeeds but doesn't produce some of the files expected by dh_install for the 
arch:all ktorrent-data package.

The issue doesn't happen on buildds where arch:all packages are built on amd64 
and other arches run dh_install -a.

There is no easy way to split the generation of the arch:all files for ktorrent 
in a separate build-indep target so I'm marking this bug as whishlist+wontfix.


Happy hacking,
--
Aurélien

Bug#1069408: kwin: FTBFS on arm64: present.h:20:10: fatal error: dri3.h: No such file or directory

[Aurélien COUDERC]

Control: reassign -1 libxcb
Control: found -1 1.17.0-1
Control: retitle -1 libxcb-present-dev 1.17 misses dependency on libxcb-dri3-dev
Control: affects -1 + kwin

Le samedi 20 avril 2024, 14:16:27 CEST Lucas Nussbaum a écrit :
> Source: kwin
> Version: 4:5.27.10-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build
> on arm64.

Dear X Team,

it seems to me that libxcb-present-dev 1.17 misses dependency on 
libxcb-dri3-dev which was added as a private dependency between 1.15 and 1.17.
This is causing kwin to FTBFS.

If that’s correct you’ll find an MR against the libxcb repo adding that 
dependency at [1].


[1] https://salsa.debian.org/xorg-team/lib/libxcb/-/merge_requests/3


Happy hacking,
--
Aurélien

Bug#1053830: marked as pending in kimageformats

[Aurélien Couderc]

Control: tag -1 pending

Hello,

Bug #1053830 in kimageformats reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/qt-kde-team/kde/kimageformats/-/commit/6af4c440a4f8f796f8411baf8ceeaf03bfca7356


debian/rules: Specify -fexcess-precision=fast for i386 to avoid FTBFS due to 
GCC 13 changing its default behavior. (Closes: #1053830)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1053830

Bug#1034951: ktexteditor: diff for NMU version 5.103.0-1.1

[Aurélien COUDERC]

Le jeudi 18 mai 2023, 18:29:49 CEST Andreas Metzler a écrit :
> Control: tags 1034951 + patch
> Control: tags 1034951 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for ktexteditor (versioned as 5.103.0-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Applied to git.

Thanks for the fix !

--
Aurélien

Bug#1034215: drkonqi: dh_installsystemd doesn't handle files in /usr/lib/systemd/system

[Aurélien COUDERC]

Hi !

Le mercredi 12 avril 2023, 13:25:06 CEST Andreas Henriksson a écrit :
> Hello again,
> 
> On Wed, Apr 12, 2023 at 01:19:52PM +0200, Andreas Henriksson wrote:
> > On Tue, Apr 11, 2023 at 09:37:27AM +0200, bi...@debian.org wrote:
> >
> > > It seems that your package drkonqi is shipping files (.service, .socket or
> > > .timer) in /usr/lib/systemd/system.
> > [...]
> > 
> > ```
> > $ apt-file show drkonqi | grep systemd/system
> > drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service
> > ```
> 
> I forgot to mention that since this is a template unit (@.service)
> maybe the severity should not be RC.
> As far as I know debhelper will not enable any instance of a template
> unit by default anyway, so the consequences that bigon warned about
> probably doesn't apply here?

@Laurent would you mind commenting on this ?
As per my understanding what we would miss (the service not being activated on 
installation) doesn’t apply here because the only service file we ship is a 
systemd template.

With a simple tweak to your search command, drkonqi disappears from the list. :)

apt-file search -x 
'^/usr/lib/systemd/system/.*[^@]\.(service|timer|socket)$'|cut -d: -f1|sort -u


So may I simply close this bug ?


Thanks,
--
Aurélien

Bug#1032258: plasma-welcome: contains unintended patches providing a nonsensical welcome screen

[Aurélien COUDERC]

Oops.

Will fix that right away.


Le 2 mars 2023 14:09:46 GMT+01:00, Simon McVittie  a écrit :
>Package: plasma-welcome
>Version: 5.27.0-1
>Severity: serious
>Justification: not suitable for inclusion in a stable release in this form
>Control: fixed -1 5.27.2-1
>

Bug#1031900: marked as pending in kimageformats

[Aurélien Couderc]

Control: tag -1 pending

Hello,

Bug #1031900 in kimageformats reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/qt-kde-team/kde/kimageformats/-/commit/016796dd935a5580a698af5d9a9f1b1d9ba81651


Build with -ffloat-store on i386. (Closes: #1031900)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1031900

Bug#1031900: kimageformats FTBFS on i386

[Aurélien COUDERC]

Le vendredi 24 février 2023, 21:17:38 CET Adrian Bunk a écrit :
> 1031900

Thanks for the patch !

Applied and uploaded.


Happy hacking,
--
Aurélien

Bug#1029613: ukui-settings-daemon FTBFS: Unexpected libkscreen transition

[Aurélien COUDERC]

With the help of Sune Vuorela I was able to patch some workarounds into
libkscreen 4:5.26.90-3 and the compilation made some more progress but still
fails:

https://people.debian.org/~coucouf/ukui-settings-daemon_3.1.1.1-1_amd64-2023-01-25T15:02:13Z.build

xrandr-manager.cpp: In member function ‘void XrandrManager::monitorsInit()’:
xrandr-manager.cpp:1200:50: error: ‘isPrimaryChanged’ is not a member of 
‘KScreen::Output’
 1200 | connect(output.data(), ::Output::isPrimaryChanged, 
this, [this](){
  |  ^~~~
xrandr-manager.cpp:1292:47: error: ‘primaryOutputChanged’ is not a member of 
‘KScreen::Config’
 1292 | connect(mConfig.data(), ::Config::primaryOutputChanged,
  |   ^~~~

Bug#1029612: ukui-control-center: FTBFS: Unexpected libkscreen transition

[Aurélien COUDERC]

With the help of Sune Vuorela I was able to patch some workarounds into
libkscreen 4:5.26.90-3 and the compilation made some more progress but still
fails:

https://people.debian.org/~coucouf/ukui-control-center_3.0.5.1-1_amd64-2023-01-25T14:51:50Z.build

widget.cpp: In member function ‘void Widget::setConfig(const 
KScreen::ConfigPtr&, bool)’:
widget.cpp:222:47: error: ‘primaryOutputChanged’ is not a member of 
‘KScreen::Config’
  222 | connect(mConfig.data(), ::Config::primaryOutputChanged,
  |   ^~~~
widget.cpp: In member function ‘bool Widget::isBacklight()’:
widget.cpp:767:18: warning: ‘void QProcess::start(const QString&, 
QIODevice::OpenMode)’ is deprecated: Use QProcess::start(const QString 
, const QStringList ,OpenMode mode = ReadWrite) instead 
[-Wdeprecated-declarations]
  767 | process.start(cmd);
  | ~^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qprocess.h:168:10: note: declared here
  168 | void start(const QString , OpenMode mode = ReadWrite);
  |  ^
mv -f libshortcut.so ../../libshortcut.so
widget.cpp: In member function ‘void Widget::setActiveScreen(QString)’:
widget.cpp:1221:21: warning: operation on ‘enableCount’ may be undefined 
[-Wsequence-point]
 1221 | enableCount = (output->isEnabled() ? (++enableCount) : 
enableCount);
  | 
^~~

Bug#1029613: ukui-settings-daemon FTBFS: Unexpected libkscreen transition

[Aurélien COUDERC]

Source: ukui-settings-daemon
X-Debbugs-Cc: Debian Qt/KDE Maintainers 
Version: 3.1.1.1-1
Severity: serious
Tags: ftbfs

Dear Kylin packaging team,

I has been raised to my attention that ukui-settings-daemon depends on
libkscreen, which I thought was used only by Plasma components.
So it turns out I have started an unplanned transition with my recent   
   
upload of Plasma 5.26.90 (5.27 beta).

I’ll discuss with the release team how to sort the issue in a separate  
bug report but in the meantime I’ve started rebuilding rdeps with the   
new libkscreen, and unfortunately ukui-settings-daemon fail to build.   
  

You’ll find a amd64 sbuild log at [0].

I’d appreciate if you could investigate the matter quickly so we can
find a fix.

Please accept my apology for this, and we will handle future libkscreen
and Plasma libs soname bumps as proper transitions obviously…


[0] 
https://people.debian.org/~coucouf/ukui-settings-daemon_3.1.1.1-1_amd64-2023-01-25T10:42:56Z.build


Thanks for your help.
--
Aurélien

Bug#1029612: ukui-control-center: FTBFS: Unexpected libkscreen transition

[Aurélien COUDERC]

Source: ukui-control-center
X-Debbugs-Cc: Debian Qt/KDE Maintainers 
Version: 3.0.5.1-1
Severity: serious
Tags: ftbfs

Dear Kylin packaging team,

I has been raised to my attention that ukui-control-center depends on
libkscreen, which I thought was used only by Plasma components.
So it turns out I have started an unplanned transition with my recent   
   
upload of Plasma 5.26.90 (5.27 beta).

I’ll discuss with the release team how to sort the issue in a separate  
bug report but in the meantime I’ve started rebuilding rdeps with the   
new libkscreen, and unfortunately ukui-control-center fail to build.
 

You’ll find a amd64 sbuild log at [0].

I’d appreciate if you could investigate the matter quickly so we can
find a fix.

Please accept my apology for this, and we will handle future libkscreen
and Plasma libs soname bumps as proper transitions obviously…


[0] 
https://people.debian.org/~coucouf/ukui-control-center_3.0.5.1-1_amd64-2023-01-25T10:34:30Z.build


Thanks for your help.
--
Aurélien

Bug#1029611: lxqt-config: FTBFS: Unexpected libkscreen transition

[Aurélien COUDERC]

Source: lxqt-config
X-Debbugs-Cc: Debian Qt/KDE Maintainers 
Version: 1.2.0-1
Severity: serious
Tags: ftbfs

Dear LXQt packaging team,

I has been raised to my attention that lxqt-config depends on
libkscreen, which I thought was used only by Plasma components.
So it turns out I have started an unplanned transition with my recent
upload of Plasma 5.26.90 (5.27 beta).

I’ll discuss with the release team how to sort the issue in a separate  
bug report but in the meantime I’ve started rebuilding rdeps with the
new libkscreen and unfortunately lxqt-config fails to build.

You’ll find a amd64 sbuild log at [0].

I’d appreciate if you could investigate the matter quickly so we can
find a fix.


Please accept my apology for this, and we will handle future libkscreen
and Plasma libs soname bumps as proper transitions obviously…


[0] 
https://people.debian.org/~coucouf/lxqt-config_1.2.0-1_amd64-2023-01-25T10:31:32Z.build


Thanks for your help.
--
Aurélien

Bug#1026159: okular: Bogus memory allocation size error - some pages not displayed

[Aurélien COUDERC]

control: severity -1 normal


Le 25 décembre 2022 18:27:26 GMT+01:00, Marco Mattiolo 
 a écrit :

>I am not the package's maintainer and maybe I am not so much into the topic, 
>but this bug report is barely understandable: what is being reported?
>
>Is this package failing to build from source? How is it being built? What's 
>the error message?
>
>Or is this about okular failing to display some pages of a specific PDF 
>document? On which okular version? Does this deserve a serious severity?
>
>If you are facing two issues, please file two separate bug reports...

Yes agreed, please provide more detailed information and file different big 
reports for different issues.


Happy hacking,
--
Aurélien

Bug#1022149: Link to upstream bug

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=460701

Bug#1025943: dolphin: copy/move files: only the first item is copied to the clipboard

[Aurélien COUDERC]

Le lundi 12 décembre 2022 12:01:16 CET, vous avez écrit :
> Control: severity -1 serious
> 
> Le lundi 12 décembre 2022, 11:45:56 CET antonio a écrit :
> > Dear Maintainer,
> 
> Dear Antonio,
> 
> > there is a kde bug that makes it problematic to copy/move files, see link
> > https://bugs.kde.org/show_bug.cgi?id=462928
> > 
> > I went back to the previous version 4:22.08.1-1
> 
> thank you for your bug report.
> 
> I’m keeping 22.12.0 in unstable, but raising the severity of this bug report 
> so the new version doesn’t migrate to testing.

FYI I just uploaded 4:22.12.0-2 including the upstream-revert of the commit 
that broke this.


Happy hacking,
--
Aurélien

Bug#1025947: kdegraphics-thumbnailers: missing Breaks+Replaces: kdegraphics-mobipocket (<< 4:22.12.0)

[Aurélien COUDERC]

Dear Andreas,

Le lundi 12 décembre 2022, 12:54:36 CET Andreas Beckmann a écrit :
> Package: kdegraphics-thumbnailers
> Version: 4:22.12.0-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.
[…]
> The existing
>   Breaks+Replaces: kdegraphics-mobipocket (<< 4:21.12.3)
> are insufficiently versioned.

thank you for your bug report, I’ve uploaded the fix.


Happy hacking,
--
Aurélien

Bug#1025943: dolphin: copy/move files: only the first item is copied to the clipboard

[Aurélien COUDERC]

Control: severity -1 serious

Le lundi 12 décembre 2022, 11:45:56 CET antonio a écrit :
> Dear Maintainer,

Dear Antonio,

> there is a kde bug that makes it problematic to copy/move files, see link
> https://bugs.kde.org/show_bug.cgi?id=462928
> 
> I went back to the previous version 4:22.08.1-1

thank you for your bug report.

I’m keeping 22.12.0 in unstable, but raising the severity of this bug report so 
the new version doesn’t migrate to testing.


Happy hacking,
--
Aurélien

Bug#1025878: libkeduvocdocument-data: missing Breaks+Replaces: libkeduvocdocument5 (<< 4:22.11.90-2)

[Aurélien COUDERC]

Le dimanche 11 décembre 2022, 04:41:25 CET Andreas Beckmann a écrit :

> There are already
>   Breaks+Replaces: libkeduvocdocument5 (<< 4:21.12.3)
> but that versioning is insufficient to catch all package versions 
> predating the package split.

Ah yes, thank you Andreas.

Fix uploaded.


Happy hacking,
--
Aurélien

Bug#1024417: kgpg FTBFS: Did not find GPGME

[Aurélien COUDERC]

Le 26 novembre 2022 06:48:56 GMT+01:00, Andreas Metzler  a 
écrit :
>On 2022-11-25 Aurélien COUDERC  wrote:
>[...]
>> I tried applying the patch on top of upstream 22.08.3 and the build still 
>> fails. [0]
>
>> Ideas welcome, I won't have the time to analyse the issue any further.
>
>Good morning,
>
>adding pkg-config to Build-Depends works for me.

Obviously…


Thank you. 

Bug#1024417: kgpg FTBFS: Did not find GPGME

[Aurélien COUDERC]

Le 25 novembre 2022 18:36:49 GMT+01:00, Andreas Metzler  a 
écrit :
>On 2022-11-23 Daniel Kahn Gillmor  wrote:
>> On Wed 2022-11-23 16:27:43 +0100, Andreas Metzler wrote:
>>> Unless kgpg maintainers/upstream has a strong opinion against using
>>> pkg-config the obvious choice would be to drop cmake/FindGpgme.cmake
>>> and simply use FindPkgConfig. - Attached patch seems to work for me,
>>> i.e. build including dh_auto_test works.
>
>> Thanks for this, Andreas.
>
>> I've proposed this change upstream as well at
>> https://invent.kde.org/utilities/kgpg/-/merge_requests/18
>
>Great, with a little bit of luck we should be able to work out a fix
>that is acceptable for all/most cmake-cases.

I tried applying the patch on top of upstream 22.08.3 and the build still 
fails. [0]

Ideas welcome, I won't have the time to analyse the issue any further.

[0] https://salsa.debian.org/qt-kde-team/kde/kgpg/-/jobs/3571722


Haply hacking,
--
Aurélien

Bug#1008694: Recent upstream activity

[Aurélien COUDERC]

There was recent upstream activity on the topic.

Bug :
https://bugs.kde.org/show_bug.cgi?id=438206

Merge Request :
https://invent.kde.org/kdevelop/kdev-python/-/merge_requests/16

Hopefully we can get kdevelop-python back for version 22.12 and into bookworm.


--
Aurélien

Bug#1017136: ksirk: diff for NMU version 4:21.08.0-1.1

[Aurélien COUDERC]

Dear Reiner,

Le 15 octobre 2022 18:27:35 GMT+02:00, Reiner Herrmann  a 
écrit :
>Control: tags 1017136 + patch
>Control: tags 1017136 + pending
>
>Dear maintainer,
>
>I've prepared an NMU for ksirk (versioned as 4:21.08.0-1.1) and
>uploaded it to DELAYED/2. Please feel free to tell me if I
>should delay it longer.

thanks for that, appreciated.

Would you go as far as posting the change as an MR against the salsa repo ? 
https://salsa.debian.org/qt-kde-team/kde/ksirk

Also if you're interested in KDE apps/gear in general, help is welcome on their 
maintenance.


Happy hacking,
--
Aurélien

Bug#1011624: kdesu: kdesu fails to authenticate with sudo from testing/unstable

[Aurélien COUDERC]

Dear Marc,

Le 26/05/2022 à 16:09, Marc Haber a écrit :

On Wed, May 25, 2022 at 01:58:58PM +0100, Rik Mills wrote:

The issue can be worked around by adding /etc/sudoers.d/kdesu with the
contents

Defaults!/usr/lib/*/libexec/kf5/kdesu_stub !use_pty


kdesu is cordially invited to ship that file in the package, fixing the
issue for everybody. Please add a comment with the reference to this bug
report and remove the file once kdesu was fixed upstream.


kdesu is now cordially shipping the file in the package. :-)

Would you mind to comment why this is OK from a security perspective ?

I’m no security expert at all but if I read the CVE description 
correctly, the issue is with the su'ed command being able to escape the 
su user session.
Is it OK in this case because kdesu is used to gain root from non-root 
and so escaping the su session only gives you back the original non-root 
user rights ?



Thanks,
--
Aurélien

Bug#1008377: zanshin: FTBFS: unsatisfiable build-dependencies: libkf5akonadi-dev (>= 4:21.08.40~), libkf5akonadicalendar-dev (>= 4:21.08.40~), libkf5kontactinterface-dev (>= 21.08.40~)

[Aurélien COUDERC]

Le 26 mars 2022 21:52:54 GMT+01:00, Lucas Nussbaum  a écrit :
>
>Hi,

Dear Lucas,

>During a rebuild of all packages in sid, your package failed to build
>on amd64.

Thanks for your bug report.
I uploaded zanshin to unstable instead of experimental by mistake.

This will be fixed once KDE PIM transitions to unstable and zanshin is rebuilt.


Happy hacking !
--
Aurélien

Bug#972306: analitza: FTBFS with DEB_BUILD_OPTIONS=reproducible=+fixfilepath

[Aurélien COUDERC]

Dear Vagrant,

On Thu, 15 Oct 2020 17:10:39 -0700 Vagrant Cascadian  wrote:
> Package: analitza
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: fixfilepath ftbfs
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> When the reproducible=+fixfilepath feature is enabled (either through
> DEB_BUILD_OPTIONS, or using a dpkg that enables this by default),
> analitza fails to build from source:

[…]

> I have not identified the exact cause of this issue, but a common
> trigger is test suites expecting __FILE__ to resolve to an absolute
> path.

The topic has now been discussed in more details on d-devel and elsewhere and 
is due to the fact that some build-time tests use the QTESTDATA Qt macro which 
relies on __FILE__ expanding to the full path of the source file where it’s 
used.

> The attached patch works around this issue by disabling the fixfilepath
> feature in debian/rules using DEB_BUILD_MAINT_OPTIONS=-fixfilepath.

We (the maintainers)’d prefer that kind of change be discussed and resolved 
upstream instead of having to revert it in every package that fails, but, oh 
well…

Thanks for the patch.
Applied and uploaded.


Happy hacking !
--
Aurélien

Bug#979420: nautilus-kdeconnect: missing Breaks+Replaces: kdeconnect (<< 20.12)

[Aurélien COUDERC]

Le 06/01/2021 à 14:53, Andreas Beckmann a écrit :

Hi,


Dear Andreas,


during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces


Thank you for your bug report.
It’s now fixed and uploaded.


Happy hacking !
--
Aurélien

Bug#979420: marked as pending in kdeconnect

[Aurélien Couderc]

Control: tag -1 pending

Hello,

Bug #979420 in kdeconnect reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/qt-kde-team/kde/kdeconnect/-/commit/bf649675bbbf69a23a3bf01404164c81074266df


Add Breaks+Replaces: kdeconnect (<< 20.12) (Closes: #979420).


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/979420

Bug#974538: libkscreenlocker5: kwin cannot start due to missing libkscreenunlocker5 symbols

[Aurélien COUDERC]

Le 13 novembre 2020 00:26:16 GMT+01:00, Norbert Preining 
 a écrit :
>Hi Scarlett, hi all,

Hi !

>> However, it seems that because of the ABI break in libkscreenlocker5
>> there may need to be more specific dependency requirements (like
>
>I suggest the following change in kscreenlocker debian/control, Scarlett, wdyt?
>diff --git a/debian/control b/debian/control
>index b961e0d..b2ba44d 100644
>--- a/debian/control
>+++ b/debian/control
>@@ -86,6 +86,7 @@ Package: libkscreenlocker5
> Architecture: any
> Pre-Depends: psmisc
> Depends: ${misc:Depends}, ${shlibs:Depends}
>+Breaks: kwin-common (<< 4:5.19), kwin-common (>> 4:5.19.90~)
> Recommends: kde-config-screenlocker
> Multi-Arch: same
> Description: Secure lock screen architecture

Could I suggest using (>> 4:5.19.70~)
I know we generally don't package these but upstream does publish prereleases 
starting at .70 AFAICR.


Happy hacking !
--
Aurélien

Bug#952060: libsignon-glib: diff for NMU version 1.12-2.1

[Aurélien COUDERC]

Le 07/04/2020 à 09:52, Adrian Bunk a écrit :
> Control: tags 952060 + patch
> Control: tags 952060 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for libsignon-glib (versioned as 1.12-2.1) and 
> uploaded it to DELAYED/15. Please feel free to tell me if I should 
> cancel it.

Applied in git [1], thanks !

[1] https://salsa.debian.org/qt-kde-team/3rdparty/libsignon-glib


Happy hacking,
--
Aurélien

Bug#952060: marked as pending in libsignon-glib

[Aurélien Couderc]

Control: tag -1 pending

Hello,

Bug #952060 in libsignon-glib reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/qt-kde-team/3rdparty/libsignon-glib/-/commit/4b03ce137b10f1663e944e758ff7e6ec8986d7f3


NMU: Don't build with -Werror. (Closes: #952060) Thanks Adrian Bunk


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/952060

Bug#948940: Merge requests for FTBFS in Qt/KDE packages

[Aurélien COUDERC]

Dear John,

Le mardi 25 février 2020, 18:35:54 CET John Scott a écrit :
> I have now prepared merge requests for fixing ktp-common-internals,
> ktp-accounts-kcm, and kaccounts-providers respectively [1] [2] [3]. These
> issues are all fixed in new upstream releases, but I am not comfortable
> with such an undertaking and hope these fixes will suffice in the meantime.

Thanks *a lot* for hunting down the required fixes for these various KTp 
components.
I’ll be merging your fixes and uploading the packages as time permits.

Indeed the upgrade to the newer upstream version is not an easy one, with 
upstream breaking the backward compatibility of their libraries and not 
bumping the somames.
It’s still on my TODO for when I can find some time and motivation to tackle 
that.

Anyway, every contribution is very much welcome so thanks again. :-)


Happy hacking,
--
Aurélien

Bug#949083: krfb FTBFS fixed upstream?

[Aurélien COUDERC]

Le 13 février 2020 03:57:06 GMT+01:00, Debian Bug Tracking System 
 a écrit :
>Processing commands for cont...@bugs.debian.org:
>
>> forwarded 949083 https://phabricator.kde.org/D23059
>Bug #949083 [src:krfb] krfb FTBFS: error: field 'm_clientActions' has 
>incomplete type 'QHash'
>Set Bug forwarded-to-address to 'https://phabricator.kde.org/D23059'.
>> tags 949083 patch fixed-upstream
>Bug #949083 [src:krfb] krfb FTBFS: error: field 'm_clientActions' has 
>incomplete type 'QHash'
>Added tag(s) fixed-upstream and patch.
>> thanks
>Stopping processing here.
>
>Please contact me if you need assistance.

Dear John,

thanks for your research on this.
The new upstream version *does* fix the FTBFS.

I need to tidy up a couple more things on the package and I'll upload version 
19.12.2, hopefully today.


Happy hacking !
-- 
Aurélien

Bug#949334: marked as done (src:plasma-desktop: missing multiple Breaks+Replaces)

[Aurélien COUDERC]

Hi Pino,

quick feedback to confirm the fix.
I did an upgrade before the fix on one machine which failed, and a second 
upgrade after the fix on another machine that went fine.

And thanks for all the Plasma 5.17.5 packaging. :-)


Happy hacking !
--
Aurélien

Bug#946401: gnome-boxes crashes with g_variant_get_child_value: assertion 'index_ < g_variant_n_children (value)' failed

[Aurélien COUDERC]

Package: gnome-boxes
Version: 3.34.1-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading to 3.34.1-1, gnome-boxes crashes on load with SIGSEGV every
time I launch it.
It opens an empty main window, and seemingly crashes while trying to load the
list of existing VMs.
Downgrading to 3.30.3-2 fixes the issue.

Please find the stack trace in attachment.


Best,
--
Aurélien



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

Kernel: Linux 5.3.0-2-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-boxes depends on:
ii  dconf-gsettings-backend [gsettings-ba  0.34.0-1
ii  genisoimage9:1.1.11-3+b2
ii  libarchive13   3.4.0-1+b1
ii  libc6  2.29-5
ii  libcairo2  1.16.0-4
ii  libfreerdp2-2  2.0.0~git20190204.1.2693389a+dfsg1-1
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-1
ii  libglib2.0-0   2.62.3-2
ii  libgtk-3-0 3.24.13-1
ii  libgtk-vnc-2.0-0   1.0.0-1
ii  libgudev-1.0-0 233-1
ii  libosinfo-1.0-01.6.0-1
ii  libosinfo-bin  1.6.0-1
ii  libpango-1.0-0 1.42.4-7
ii  libsecret-1-0  0.19.1-1
ii  libsoup2.4-1   2.68.2-1
ii  libspice-client-glib-2.0-8 0.37-1
ii  libspice-client-gtk-3.0-5  0.37-1
ii  libtracker-sparql-2.0-02.3.1-1
ii  libusb-1.0-0   2:1.0.23-1
ii  libvirt-daemon 5.6.0-3
ii  libvirt-glib-1.0-0 2.0.0-2
ii  libvte-2.91-0  0.58.2-1
ii  libwebkit2gtk-4.0-37   2.27.3-1
ii  libwinpr2-22.0.0~git20190204.1.2693389a+dfsg1-1
ii  libxml22.9.10+dfsg-1
ii  tracker2.3.1-1

Versions of packages gnome-boxes recommends:
ii  qemu-system-x86  1:4.1-3

gnome-boxes suggests no packages.

-- no debconf information
#0  0x77d57240 in g_bit_lock (address=address@entry=0x20, 
lock_bit=lock_bit@entry=0) at ../../../glib/gbitlock.c:214
#1  0x77dc2399 in g_variant_lock (value=0x0, value@entry=0x20) at 
../../../glib/gvariant-core.c:991
#2  0x77dc2399 in g_variant_n_children (value=value@entry=0x0) at 
../../../glib/gvariant-core.c:991
#3  0x77dc2424 in g_variant_get_child_value (value=value@entry=0x0, 
index_=index_@entry=1) at ../../../glib/gvariant-core.c:1043
#4  0x555eb164 in boxes_unattended_installer_get_preferred_keyboard 
(lang=0x567e9f20 "fr_FR", self=0x55f9f2c0 [BoxesUnattendedInstaller])
at src/25a6634@@gnome-boxes@exe/unattended-installer.c:4423
#5  0x555eb164 in boxes_unattended_installer_construct_from_media
(object_type=, media=media@entry=0x56665460 
[BoxesInstallerMedia], scripts=scripts@entry=0x5653ddb0 
[OsinfoInstallScriptList], error=error@entry=0x7fffdbf0)
at src/25a6634@@gnome-boxes@exe/unattended-installer.c:1420
#6  0x555ebe49 in boxes_unattended_installer_new_from_media
(media=media@entry=0x56665460 [BoxesInstallerMedia], 
scripts=scripts@entry=0x5653ddb0 [OsinfoInstallScriptList], 
error=error@entry=0x7fffdbf0)
at src/25a6634@@gnome-boxes@exe/unattended-installer.c:1444
#7  0x555cc0d0 in boxes_media_manager_create_unattended_installer 
(error=0x7fffdbe8, media=0x56665460 [BoxesInstallerMedia]) at 
src/25a6634@@gnome-boxes@exe/media-manager.c:1733
#8  0x555cc0d0 in boxes_media_manager_create_installer_media_from_media 
(self=, media=0x56665460 [BoxesInstallerMedia], 
error=error@entry=0x5609f578)
at src/25a6634@@gnome-boxes@exe/media-manager.c:1803
#9  0x555cda2e in 
boxes_media_manager_create_installer_media_from_iso_info_co 
(_data_=0x5609f3d0) at src/25a6634@@gnome-boxes@exe/media-manager.c:2237
#10 0x7727ef69 in g_task_return_now (task=0x56142bf0 [GTask]) at 
../../../gio/gtask.c:1212
#11 0x7727fa8d in g_task_return (task=0x56142bf0 [GTask], 
type=) at ../../../gio/gtask.c:1281
#12 0x772800ac in g_task_return (type=G_TASK_RETURN_SUCCESS, 
task=) at ../../../gio/gtask.c:1684
#13 0x772800ac in g_task_return_pointer (task=, 
result=, result_destroy=) at 
../../../gio/gtask.c:1689
#14 0x555d21d5 in boxes_os_database_get_os_by_id_co 
(_data_=0x5665ed80) at src/25a6634@@gnome-boxes@exe/os-database.c:1083
#15 

Bug#925967: Solved

[Aurélien COUDERC]

On Wed, 24 Apr 2019 14:12:51 -0300 leandroe...@gmail.com wrote:
> I solved the problem by copying the file /usr/share/doc/xserver-xorg-
> video-intel/xorg.conf to the directory /etc/X11/

I confirm this workaround does work.

Bug#925555: linux-image-4.19.0-4-amd64: Display manager fails to start or display anything on IvyBridge with linux-image-4.19.0-4-amd64

[Aurélien COUDERC]

Package: src:linux
Version: 4.19.28-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after upgrading the kernel to 4.19.0-4 or later (5.0.0-trunk), my IvyBridge
laptop fails to start the display manager.
I end up with a black screen and a non blinking _ character in the top left
corner of the screen.

I tested with sddm, lightdm on X and GDM on wayland and have the same
behaviour everytime.
After advice from #debian-kernel I compared lspci for both kernels and it
gives the same output.

Switching to a text VT works (I'm reportbugging from there).
Reverting to 4.19.0-3 returns to the normal behaviour and the graphical
session starts normally.


Cheers,
--
Coucouf

-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 
root=UUID=9fccd33e-ceb6-48d4-8a47-f46fded95997 ro quiet splash

** Not tainted

** Kernel log:
[   16.220937] L1TF CPU bug present and SMT on, data leak possible. See 
CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html 
for details.
[   16.374742] media: Linux media interface: v0.10
[   16.391761] videodev: Linux video capture interface: v2.00
[   16.448128] uvcvideo: Found UVC 1.00 device Laptop_Integrated_Webcam_1.3M 
(0c45:644d)
[   16.578804] uvcvideo 1-1.5:1.0: Entity type for entity Extension 4 was not 
initialized!
[   16.578808] uvcvideo 1-1.5:1.0: Entity type for entity Extension 3 was not 
initialized!
[   16.578810] uvcvideo 1-1.5:1.0: Entity type for entity Processing 2 was not 
initialized!
[   16.578812] uvcvideo 1-1.5:1.0: Entity type for entity Camera 1 was not 
initialized!
[   16.579413] input: Laptop_Integrated_Webcam_1.3M:  as 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.5/1-1.5:1.0/input/input14
[   16.579870] usbcore: registered new interface driver uvcvideo
[   16.579871] USB Video Class driver (1.1.1)
[   17.229059] BTRFS warning (device dm-0): excessive commit interval 600
[   17.229062] BTRFS info (device dm-0): disk space caching is enabled
[   17.455312] BTRFS warning (device sda2): excessive commit interval 600
[   17.455315] BTRFS info (device sda2): disk space caching is enabled
[   17.857618] BTRFS warning (device dm-0): excessive commit interval 600
[   17.857621] BTRFS info (device dm-0): disk space caching is enabled
[   18.152918] BTRFS warning (device dm-0): excessive commit interval 600
[   18.152920] BTRFS info (device dm-0): disk space caching is enabled
[   18.288277] BTRFS warning (device dm-0): excessive commit interval 600
[   18.288280] BTRFS info (device dm-0): disk space caching is enabled
[   18.366993] BTRFS warning (device dm-0): excessive commit interval 600
[   18.366995] BTRFS info (device dm-0): disk space caching is enabled
[   18.427687] BTRFS warning (device dm-0): excessive commit interval 600
[   18.427690] BTRFS info (device dm-0): disk space caching is enabled
[   18.531462] BTRFS warning (device dm-0): excessive commit interval 600
[   18.531464] BTRFS info (device dm-0): disk space caching is enabled
[   20.823734] BTRFS warning (device dm-0): excessive commit interval 600
[   20.823737] BTRFS info (device dm-0): disk space caching is enabled
[   20.877491] BTRFS warning (device sda2): excessive commit interval 600
[   20.877494] BTRFS info (device sda2): disk space caching is enabled
[   20.950215] BTRFS warning (device dm-0): excessive commit interval 600
[   20.950217] BTRFS info (device dm-0): disk space caching is enabled
[   21.008972] BTRFS warning (device dm-0): excessive commit interval 600
[   21.008975] BTRFS info (device dm-0): disk space caching is enabled
[   21.083457] BTRFS warning (device dm-0): excessive commit interval 600
[   21.083459] BTRFS info (device dm-0): disk space caching is enabled
[   21.150589] BTRFS warning (device dm-0): excessive commit interval 600
[   21.150591] BTRFS info (device dm-0): disk space caching is enabled
[   21.206446] BTRFS warning (device dm-0): excessive commit interval 600
[   21.206449] BTRFS info (device dm-0): disk space caching is enabled
[   21.265467] BTRFS warning (device dm-0): excessive commit interval 600
[   21.265469] BTRFS info (device dm-0): disk space caching is enabled
[   22.850814] BTRFS warning (device dm-0): excessive commit interval 600
[   22.850817] BTRFS info (device dm-0): disk space caching is enabled
[   22.885809] BTRFS warning (device sda2): excessive commit interval 600
[   22.885811] BTRFS info (device sda2): disk space caching is enabled
[   22.949103] BTRFS warning (device dm-0): excessive commit interval 600
[   22.949105] BTRFS info (device dm-0): disk space caching is enabled
[   23.008419] BTRFS warning (device dm-0): excessive commit interval 600
[   23.008422] BTRFS info (device dm-0): disk space caching is enabled
[   23.066638] BTRFS warning (device dm-0): excessive commit interval 600
[   23.066641] BTRFS 

Bug#897549: desktop-base: FTBFS: /bin/sh: 6: Syntax error: word unexpected (expecting "done")

[Aurélien COUDERC]

control: tag -1 + pending
Le 02/05/2018 à 22:57, Lucas Nussbaum a écrit :
> Hi,

Hi Lucas,

thanks for the bug report.

> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>>  fakeroot debian/rules clean
>> dh clean
>>dh_auto_clean
>>  make -j8 -Oline clean
>> /bin/sh: 6: Syntax error: word unexpected (expecting "done")
>> make[1]: *** [Makefile:13: clean-grub] Error 2

This was caused by a typo (trailing $) in the Makefile that former versions of
make would simply ignore and make >= 4.2 refuses to parse.

It’s fixed in git and will be in the next upload.


Cheers,
--
Aurélien

Bug#858643: retitle for real

[Aurélien COUDERC]

control: retitle -1 An incomplete active theme can cause post-inst to fail on 
upgrade/reinstall

Bug#858643: retitle

[Aurélien COUDERC]

control: retitle -1 An incomplete active theme can cause post-inst to fail on
upgrade/reinstall

Bug#858643: Bug#864911: stretch-pu: package desktop-base/9.0.3+deb9u1

[Aurélien COUDERC]

control: retitle -1 stretch-pu: package desktop-base/9.0.2+deb9u1
Le 17/06/2017 à 11:03, Aurélien COUDERC a écrit :
> Le 17/06/2017 à 09:35, Adam D. Barratt a écrit :
>> Control: tags -1 + moreinfo
>>
>> On Sat, 2017-06-17 at 00:53 +0200, Aurélien COUDERC wrote:
>>> I’d like to push a fix for desktop-base bug #862228 that makes some 
>>> wallpapers
>>> unavailable by default due to a syntax error in their XML descriptor.
>>>
>>> This fix is made of 2 trivial oneliners.
>>>
>>> I’m proposing a patch based on desktop-base 9.0.3 that was sitting in 
>>> unstable
>>> since March 23rd without any other new bug being raised.
>>> The diff from stretch’s 9.0.2 to 9.0.3 is a bit bigger and cleans some 
>>> not-so-
>>> nice scripting in maintainer scripts in the hope of making them more
>>> understandable and maintenable.
>>>
>>> As I understand you may not want these additional changes, I’m attaching the
>>> two debdiffs separately.
>>> If the bigger diff isn’t suitable I’ll prepare an upload with the fix to
>>> #862228 alone.
>> What you actually appear to have attached for the smaller diff is one
>> that builds on top of 9.0.3 - i.e. the version in unstable - rather than
>> 9.0.2, which is in stretch. Could we have a diff for a package with the
>> smaller change that's built on top of stretch, please? :-)
>>
>> Regards,
>>
>> Adam
>>
> Sure, here you go.

Dear release team.

I’ve added a second bugfix that I’d like to release for stable desktop-base.
Here’s the updated changelog :

desktop-base (9.0.2+deb9u1) stretch; urgency=medium

  * Ensure postinst doesn’t fails on upgrade even when an incomplete theme pack
is active. (Closes: #858643)
  * Fix XML syntax errors in gnome wallpaper description files making Joy
wallpapers unavailable by default. (Closes: #862228)

 -- Aurélien COUDERC <zecou...@free.fr>  Sun, 20 Aug 2017 20:03:02 +0200

The first could probably be qualified RC as attempting a reinstall will fail at
postinst if debian-edu-artwork-spacefun is installed on the system.
Both fixes have been in testing for weeks now.

The full diff is attached.
This would be my first pu so explicit advice is welcome to get it right
(distribution to target, queue…).


Cheers,
--Aurélien

diff -ur '--exclude=.svn' desktop-base_9.0.2/debian/changelog desktop-base_9.0.2+deb9u1/debian/changelog
--- desktop-base_9.0.2/debian/changelog	2017-08-20 19:50:11.179609603 +0200
+++ desktop-base_9.0.2+deb9u1/debian/changelog	2017-08-20 20:03:12.962459842 +0200
@@ -1,3 +1,12 @@
+desktop-base (9.0.2+deb9u1) stretch; urgency=medium
+
+  * Ensure postinst doesn’t fails on upgrade even when an incomplete theme pack
+is active. (Closes: #858643)
+  * Fix XML syntax errors in gnome wallpaper description files making Joy
+wallpapers unavailable by default. (Closes: #862228)
+
+ -- Aurélien COUDERC <zecou...@free.fr>  Sun, 20 Aug 2017 20:03:02 +0200
+
 desktop-base (9.0.2) unstable; urgency=medium
 
   [ Aurélien COUDERC ]
diff -ur '--exclude=.svn' desktop-base_9.0.2/debian/postinst desktop-base_9.0.2+deb9u1/debian/postinst
--- desktop-base_9.0.2/debian/postinst	2017-08-20 19:50:11.179609603 +0200
+++ desktop-base_9.0.2+deb9u1/debian/postinst	2017-08-09 22:20:11.357657845 +0200
@@ -32,10 +32,12 @@
 EOF
 
 # Use active theme as highest priority for background
-update-alternatives --install \
-/usr/share/images/desktop-base/desktop-background \
-desktop-background \
-/usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg 70
+active_background=/usr/share/desktop-base/active-theme/wallpaper/contents/images/1920x1080.svg
+if [ -e ${active_background} ]; then
+update-alternatives --install \
+/usr/share/images/desktop-base/desktop-background \
+desktop-background ${active_background} 70
+fi
 # Alternatives for the background in theme packages
 while read theme filename priority; do
 update-alternatives --install \
@@ -76,10 +78,12 @@
 # Set up an alternative for the XML version of the background
 # (for GNOME)
 # Highest priority for active theme
-update-alternatives --install \
-/usr/share/images/desktop-base/desktop-background.xml \
-desktop-background.xml \
-/usr/share/desktop-base/active-theme/wallpaper/gnome-background.xml 50
+active_background_xml=/usr/share/desktop-base/active-theme/wallpaper/gnome-background.xml
+if [ -e ${active_background_xml} ]; then
+update-alternatives --install \
+/usr/share/images/desktop-base/desktop-background.xml \
+desktop-background.xml ${active_background_xml} 50
+fi
 # Alternatives for theme packages
 while read theme priority; do
 

Bug#871609: dput fails to start with ImportError: cannot import name 'tofu'

[Aurélien COUDERC]

Package: dput
Version: 1.0.0
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After upgrading to 1.0.0 form experimental, dput fails to start with the
following stack trace:

Traceback (most recent call last):
  File "/usr/bin/dput", line 11, in 
load_entry_point('dput==1.0.0', 'console_scripts', 'execute-dput')()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 561, in
load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2649,
in load_entry_point
return ep.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2303,
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2309,
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/share/dput/dput/dput.py", line 28, in 
from . import crypto
  File "/usr/share/dput/dput/crypto.py", line 14, in 
import gpg
  File "/usr/lib/python3/dist-packages/gpg/__init__.py", line 101, in 
from . import core
  File "/usr/lib/python3/dist-packages/gpg/core.py", line 36, in 
from . import constants
  File "/usr/lib/python3/dist-packages/gpg/constants/__init__.py", line 28, in

from . import data, keylist, sig, tofu # The subdirs.
ImportError: cannot import name 'tofu'



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

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

Versions of packages dput depends on:
ii  python33.5.3-3
ii  python3-debian 0.1.30
ii  python3-gpg1.9.0-2
ii  python3-pkg-resources  36.0.1-1

dput recommends no packages.

Versions of packages dput suggests:
ii  lintian 2.5.52
pn  mini-dinstall   
ii  openssh-client  1:7.5p1-5
ii  rsync   3.1.2-2

-- no debconf information

Bug#858643: Also triggered in stretch by reinstalling

[Aurélien COUDERC]

control: found -1 9.0.0

I noticed the bug can also be triggered in stretch by:
- installing debian-edu-artwork and debian-edu-artwork-spacefun
  apt install debian-edu-artwork debian-edu-artwork-spacefun
- reinstalling desktop-base
  apt install --reinstall desktop-base

Admittedly it’s less likely to be triggered but still not clean.
So I’ll also stretch-pu the fix then.


Cheers,
--Aurélien

Bug#858643: desktop-base: File not found in the post-inst script

[Aurélien COUDERC]

control: reassign -1 desktop-base
control: found -1 9.0.3
control: tags -1 - moreinfo

Hi Wolfgang,

Le 01/07/2017 à 15:43, Wolfgang Schweer a écrit :
> Hi,
> 
> On Sat, Jul 01, 2017 at 01:39:07PM +0200, Andreas Beckmann wrote:
>> Followup-For: Bug #858643
>  
>> I could also reproduce this with piuparts in a stable -> testing ->
>> unstable upgrade test.
>  
> IMO it's a desktop-base bug; see 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858643#63
> for a proposed patch.
> 
> @ Aurélien
> 
> Any progress fixing it? See your mail: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858643#29

I had missed it was for post stretch upgrade last time I looked into
this, so I hadn’t come to any conclusion.

I initially thought we could "just" patch debian-edu-artwork to ship an
SVG versions of the edu-spacefun wallpaper, but there’s no such thing in
the source repository even going back in time to squeeze. There are SVGs
for edu-spacefun but they look like imports from bitmap with vain
attempts to make them vector…
By itself it’s a problem since it means these wallpapers are essentially
sourceless and we cannot easily adapt them should the need arise (higher
resolution, etc).

Anyway we should never break on upgrade for even if the active theme
pack is incomplete, I’m thus reassigning the bug to desktop-base and
will conditionally create the alternatives for the active theme only if
the target exists in that theme.

Also I can see the rationale of theme packs providing a bitmap
background instead of SVG, if it’s based on a photo for instance.
Currently desktop-base doesn’t provide an easy way to support that.

What I can think of is for each theme pack to provide a
"default-wallpaper" symlink to their wallpaper file of choice and the
desktop-background alternative will target link for the active theme, so
it works whatever wallpaper/resolution/format the theme wants as default.
For buster I’ll create the links for the themes included in desktop-base
and the *all* debian-edu-artwork-* themes should do the same.
That would be for example with softwaves:
  softwaves-theme/wallpaper/contents/images$ ls -l
  1920x1080.svg
  default-wallpaper -> 1920x1080.svg
  …
and second example with debian-edu-spacefun:
  debian-edu-spacefun-theme/wallpaper/contents/images$ ls -l
  1920x1080.png
  default-wallpaper -> 1920x1080.png
  …

Would that be OK with you ?


On a side note I don’t like very much the concept of a single wallpaper
image that the "desktop-background" alternative provides. It cannot
support various screen sizes and ratios correctly.
Gnome or KDE Plasma get it right by selecting one among n possible
resolutions to match the screen size at runtime, but getting this done
for all Desktop Environments seems far-fetched.
If anyone from other DEs is listening and want to use either
/usr/share/gnome-background-properties/*.xml or KDE Plasma’s
/usr/share/wallpaper structure, don’t refrain. :)


Cheers,
--Aurélien

Bug#852014: desktop-base: Boot hangs if plymouth is not installed

[Aurélien COUDERC]

Package: gdm

Hi Marko,


Le 21 janvier 2017 16:54:35 GMT+01:00, "Marko Mäkelä"  a 
écrit :
>Hi Aurélien,
>
>Thank you for your response, and I am sorry for filing the bug against 
>the wrong package. I hope that the log output in this message will help
>
>to narrow down the problem. But I fear that it may remain a mystery,
>and 
>I accept that Debian unstable can sometimes be true to its name. :)
>
>TL;DR version: I would suggest that the systemd-based bootup should
>give 
>up after 3 failed attempts of starting up gdm, like I believe it used
>to 
>be in the past. Now it seems to be doing it forever.


With this additional info I'll reaffect the bug to GDM for now.
Gnome maintainers, feel free to further qualify this bug if it should be 
against yet another package…

>>I'm not sure it's raised against the correct package tough, or I will 
>>need more information to analyze this problem.
>
>Unfortunately, I cannot reproduce the problem any more (even after 
>removing plymouth and downgrading all systemd-related packages to
>232-11 
>or 232-9). But see the /var/log/apt/history.log excerpt near the end of
>this message.

…or maybe close it if it's not reproducible or due to a known/transient error 
in sid fixed in between.


>>>After some analysis (booting into rescue mode and entering the root
>>>password, and following the instructions to view the systemd log),
>>>I figured out that the fatal error was that
>>>exec /bin/plymouth failed, because the program was not installed.
>>
>>Could you share more complete logs about that ?
>
>It seems that journalctl only keeps the systemd log since the system 
>startup. I did not attempt to record any logs when the system did not 
>boot beyond the single-user mode. I do have some kernel and user-space 
>messages in /var/log/messages from the failed startup attempts. Maybe 
>the real error was this one:
>
>Jan 20 14:39:17 hp org.gnome.Shell.desktop[1071]: /usr/bin/gnome-shell:
>
>error while loading shared libraries: libmutter-cogl.so: cannot open 
>shared object file: No such file or directory
>Jan 20 14:39:17 hp gnome-session[1063]: gnome-session-binary[1063]: 
>WARNING: App 'org.gnome.Shell.desktop' exited with code 127
>Jan 20 14:39:17 hp gdm3: GdmDisplay: display lasted 0,106016 seconds
>Jan 20 14:39:17 hp gdm3: Child process -1059 was already dead.
>Jan 20 14:39:17 hp gdm3: Child process 1043 was already dead.
>Jan 20 14:39:17 hp gdm3: Unable to kill session worker process
>Jan 20 14:39:17 hp /usr/lib/gdm3/gdm-x-session[1090]: Unable to run X 
>server
>…
>Jan 20 14:39:57 hp gdm3: GdmDisplay: display lasted 0,083347 seconds
>Jan 20 14:39:57 hp gdm3: Child process -13450 was already dead.
>Jan 20 14:39:57 hp gdm3: Child process 13437 was already dead.
>Jan 20 14:39:57 hp gdm3: Unable to kill session worker process
>Jan 20 14:39:57 hp /usr/lib/gdm3/gdm-x-session[13480]: Unable to run X 
>server
>Jan 20 14:39:57 hp gdm3: Child process -13480 was already dead.
>Jan 20 14:39:57 hp gdm3: Child process 13465 was already dead.
>Jan 20 14:39:57 hp gdm3: Unable to kill session worker process
>Jan 20 14:39:57 hp org.gnome.Shell.desktop[13510]:
>/usr/bin/gnome-shell: 
>error while loading shared libraries: libmutter-cogl.so: cannot open 
>shared object file: No such file or directory
>Jan 20 14:39:57 hp gnome-session[13502]: gnome-session-binary[13502]: 
>WARNING: App 'org.gnome.Shell.desktop' exited with code 127
>Jan 20 14:39:57 hp gdm3: GdmDisplay: display lasted 0,079726 seconds
>Jan 20 14:39:57 hp gdm3: Could not start command 
>'/usr/lib/gdm3/gdm-session-worker': Liian monta avointa tiedostoa
>Jan 20 14:39:57 hp gdm3: Child process -13498 was already dead.
>Jan 20 14:39:57 hp gdm3: Child process 13486 was already dead.
>Jan 20 14:39:57 hp gdm3: Unable to kill session worker process
>
>Back in the days before systemd, a failure to start up gdm3 or xdm or 
>whatever would result in a text dialog after 3 or so failed attempts, 
>and there would be getty listening to some virtual consoles at
>/dev/tty1 
>to /dev/tty6. But, when the above happened, the system was seemingly 
>dead. It seems to me that it went into an infinite loop and eventually 
>run out of file descriptors (or maybe I had pressed ctrl-alt-del which 
>was obeyed after 1 or 2 seconds). "Liian monta avointa tiedostoa" is
>the 
>Finnish translation of "Too many open files".
>
>On some occasion, I left the system there for 5 or 10 minutes, but
>there 
>was no progress. (And on this laptop, the status LED for mass storage 
>activity is pretty well hidden, so I did not even notice that there was
>
>constant SSD activity going on.)
>
>In /var/log/syslog there is a bit more detail of the above 
>startup/shutdown loops of the gdm service:
>
>Jan 20 14:39:16 hp systemd[1]: Started Session c4 of user Debian-gdm.
>Jan 20 14:39:16 hp kernel: [   35.891506] iwlwifi :02:00.0: L1 
>Enabled - LTR Enabled
>Jan 20 14:39:16 hp kernel: [   35.891772] iwlwifi :02:00.0: L1 
>Enabled - LTR Enabled
>Jan 

Bug#851893: The availability of update-grub does not imply that GRUB is used

[Aurélien COUDERC]

Severity: important

Hi Alexander,

Le 20 janvier 2017 20:39:04 GMT+01:00, Alexander Kurtz <alexan...@kurtz.be> a 
écrit :
>Hi!
>
>On Thu, 2017-01-19 at 22:05 +0100, Aurélien COUDERC wrote:
>> Thank you for your detailed bug report and analysis.
>> This looks a lot like #843727 [0] to me, although not for the same
>use case.
>> 
>> Would you care to test 9.0.1, already in sid that should fix this
>problem ?
>> The following change was done :
>> 208:    update-grub || echo "Updating grub failed, report success
>anyway!"
>
>I am sorry, I had not noticed bug #843727.

No problem. :-)


> However, I believe this
>change is not a correct solution, because:
>
> a) "On Error Resume Next" is (in general) not a good idea.

Yes, this was discussed on the team's list and deemed sufficient for now though 
not a very likable solution.
I quickly checked the released versions of desktop-base and it has been doing 
this at least since Squeeze… (Not that it makes it any better of an idea.)

> b) It is still a GRUB-specific solution. People use a whole bunch
>of different bootloaders to start Debian, GRUB is just one of them.

Understood. And is not using grub and still having grub tools installed such a 
common case ?

> c) It will cause really subtle bugs under some circumstances.
>
>Let me explain c): Assume that a user has the grub-pc package installed
>and GRUB is installed to /boot normally. At one point, the user decides
>to remove the grub-pc package (and only that) and use a different
>bootloader. Everything works, but the files under /boot/grub are of
>course still there. Now your package comes along and runs update-grub
>which happily modifies /boot/grub even though the user explicitly
>removed the GRUB automation package.

OK that's a case. :-)

I'm not really getting the problem here as I don't understand which other 
components would break with update-grub updating a grub folder… Not being a 
specialist I can imagine such cases could exist, though.
And anyway I agree with the whole idea that we shouldn't be update-grubing when 
we don't need to.


>> I'll merge the 2 bugs after confirmation that it works for you.
>
>I agree that your changes fixes the immediate problem. But I really
>think there are two fundamental issues with desktop-base calling the
>update script of one specific bootloader:
>
>(1) It's surprising to the user (and the maintainers of other packages)
>(2) It will only work with GRUB

Right, that said it's currently targeted specifically at grub to setup its 
wallpaper so I can sleep with that.
Patches are of course welcome if other bootloaders support similar 
functionality.


>> If you know of a better and robust way to detect if grub is being
>> used, advice is welcome.
>
>There is a better way, dpkg triggers [0-3]. There's even a
>corresponding bug in GRUB about it [4]. However, nobody really seems to
>care, so not much progress has been made.
>
>Maybe you could talk to the GRUB maintainers and convince them to add a
>"interest update-grub" trigger in the grub-pc and grub-efi packages.

You mean "activate update-grub" in grub packages ? (Or even "activate-noawait 
update-grub" would be preferred if I read the doc correctly.)


>Then GRUB's postinst would run the update-grub script, and all your
postinst would do is issue a "dpkg-trigger update-grub" call. Of
>course, it would be even better to find a generic solution for all
>bootloaders (e.g. a generic "update-bootloader" trigger), but I believe
>that it's too late in the release cycle for this.

I didn't have dpkg triggers in mind, but it sounds like a nice solution to this 
problem.
I'm unsure we can manage even the "simple" update-grub trigger done for Stretch 
though.
The current behaviour (that I had broken in 9.0.0, and reverted in 9.0.1) has 
been around for such I long time that I'd personally prefer postponing this 
change to early in the Buster cycle.

If you still feel like preparing the patches for both grub* and desktop-base 
and coordinating with the grub maintainers, I'll happily accept the change for 
desktop-base where I have commit rights.


Cheers,
--Aurélien

Bug#852014: desktop-base: Boot hangs if plymouth is not installed

[Aurélien COUDERC]

Tags: moreinfo unreproducible

Hi Marko.

Thank you for your bug report.
I'm not sure it's raised against the correct package tough, or I will need more 
information to analyze this problem.


Le 20 janvier 2017 19:00:37 GMT+01:00, "Marko Mäkelä"  a 
écrit :
>Package: desktop-base
>Version: 9.0.1
>Severity: critical
>Justification: breaks the whole system
>
>Dear Maintainer,
>
>I run Debian unstable on my desktop. Today, after "apt update&
>upgrade"
>the system failed to boot.
>
>After some analysis (booting into rescue mode and entering the root
>password, and following the instructions to view the systemd log),
>I figured out that the fatal error was that
>exec /bin/plymouth failed, because the program was not installed.

Could you share more complete logs about that ?


>Finally, I figured out how to manually bring up the Ethernet interface
>and how to install plymouth. The next reboot worked.
>
>The command
>grep -lr plymouth /etc
>suggests that the existence of files in /usr/share/plymouth/themes
>led to the assumption that plymouth is available. I am filing this
>bug against desktop-base because dpkg -S suggests that the directory
>is associated with desktop-base.

This is really unrelated to desktop-base as far as I can tell.
The path you mention is used in a "case" branch specific to *buntu and Tanglu 
derivatives, and not for Debian. Please have a look at the contents of 
05_debian_theme.

>Possibly this bug should be filed against grub-common instead, because
>grub-common owns the file /etc/grub.d/05_debian_theme which references
>the directory /usr/share/plymouth/themes.

Yes, I'd agree with that but I'm still unsure this is the real cause of your 
problem.


>Here are some versions of packages:
>
>desktop-base: 9.0.1
>grub-common: 2.02~beta3-3
>systemd: 232-12
>plymouth: 0.9.2-4
>
>I got the hang with systemd 232-9 and 232-11 before installing
>plymouth.

I have a VM with up to date stretch and installed desktop-base 9.0.1 from sid, 
then uninstalled plymouth* and I could not reproduce the issue.

Additional information would be welcome !


Cheers,
--Aurélien

Bug#851893: The availability of update-grub does not imply that GRUB is used

[Aurélien COUDERC]

Hi Alexander.

Le 19 janvier 2017 17:47:18 GMT+01:00, Alexander Kurtz  a 
écrit :

>Hi!
>
>People who want to have the GRUB binaries installed (for example to
>create VM images with GRUB), but don't want to use GRUB as their
>bootloader will (in the case of classic PCs) have the grub-pc-bin [0]
>and grub2-common [1] packages installed, but not the grub-pc [2]
>package as this contains the scripts for the automatic installation.

[buggy script code…]

>Since update-grub is shipped by the grub2-common package (see [3]),
>this test is wrong. The fact that update-grub is available does not
>imply that the system uses GRUB to boot. Since update-grub will
>obviously fail to run if GRUB is not installed to /boot, this bug
>causes desktop-base's postinst to fail, making the package
>uninstallable on such systems.

Thank you for your detailed bug report and analysis.
This looks a lot like #843727 [0] to me, although not for the same use case.

Would you care to test 9.0.1, already in sid that should fix this problem ?
The following change was done :
208:update-grub || echo "Updating grub failed, report success anyway!"

I'll merge the 2 bugs after confirmation that it works for you.

If you know of a better and robust way to detect if grub is being used, advice 
is welcome.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843727

Cheers,
--Aurélien

Bug#843727: fix inside

[Aurélien COUDERC]

control: tags -1 pending

Le mercredi 9 novembre 2016, 22:45:32 CET Eric Valette a écrit :
> the wrong code is calling "which update-initramfs" outside of if
> because then the set -e catch an error and there is no way the
> test on $? can work
> 
> correct code is:
> 
>  if which update-initramfs > /dev/null; then
>  update-initramfs -u
>  fi

Yes, was preparing that already after reading your last mail. :-)

It’s now committed to SVN and will be in the next upload.


Cheers,
--Aurélien

Bug#772417: Re: Bug#772417: Re: Bug#772417: desktop-base: debian/copyright file needs to be updated

[Aurélien COUDERC]

Le 08/12/2014 11:38, Francesco Poli a écrit :
 The following part looks problematic:

 | The Lines KSplash theme is © 2013 Martin Klapetek, © 2014 Aurélien Couderc
 | under the GPLv2 with artwork from Juliette Taka Belin, Nuno Pinheiro under 
 the
 | GPLv2 license.

 First of all, the artwork by Juliette is not under the GPL v2 or any
 later version, not under the GPL v2 (only).
 But the question is: are the other artwork also under the GPL v2 or any
 later version? It's not too clear from the description, but, *in case*
 the Lines KSplash theme is derived from the artwork by Juliette which
 is based on the Debian “Open Use” Logo (with the “Debian” label), we
 could again face the issue due to LGPLv3 / GPLv2 incompatibility...
 Please check with the relevant copyright holders and update the
 debian/copyright file accordingly.
After checking :
- we’re talking about the script that is © 2013 Martin Klapetek, © 2014
Aurélien Couderc under the GPLv2+ (not just v2)
- the artwork is a from Juliette Taka Belin (GPLv2+) and the Oxygen Icon
Theme contributors (LGPLv3+)
   
http://metadata.ftp-master.debian.org/changelogs//main/o/oxygen-icons/oxygen-icons_4.14.0-1_copyright

I propose the following :
| The Lines KSplash script is © 2013 Martin Klapetek, © 2014 Aurélien
Couderc
| under the GPLv2 or any later version.
|
| The artwork for the Lines KSplash theme is © 2014 Juliette Taka Belin
under
| the GPLv2 or any later version and © 2007-2014 from the Oxygen Icon Theme
| contributors under the LGPLv3 or any later version.


And we were missing the 2012 copyright for Eshat Cakar for login box of
the Lines KDM themes :
https://wiki.debian.org/DebianArt/Themes/Roj
that is not Adrien’s work as I thought but Eshat’s (fortunately under
GPLv2+).


 There may be issues with the following parts, as well:

 | The Joy GDM is © 2012 Paul Tagliamonte GPLv2, with work
 | from all the previous authors of that file, and artwork from Adrien Aubourg 
 under
 | the GPLv3 license.
 | 
 | The Joy KDM theme is © 2012 Eshat Cakar and © 2010 Roman Shtylman GPLv2
 | with artwork from Adrien Aubourg under the GPLv3 license.
 | 
 | The Joy KSplash theme is © 2012 Eshat Cakar, Nuno Pinheiro, Riccardo 
 Iaconelli GPLv2
 | with artwork from Adrien Aubourg under the GPLv3 license.
 | 
 | The Joy grub theme is © 2012 Paul Tagliamonte GPLv2, using artwork from 
 Adrien
 | Aubourg licensed under GPLv3 license.

 Any of these four themes may be troublesome, if is a work derived from
 GPLv3 artwork and from GPLv2 parts is created.
 Since the Joy artwork by Adrien Aubourg was previously licensed under
 the GPLv2 and has subsequently been re-licensed under the GPLv3
 (without modifying the artwork itself, if I understand correctly:
 please confirm!), then we may solve the issues with these four themes
 by stating that: The Joy theme is © 2012 Adrien Aubourg and released
 under the GPL license, version 2 or 3.
Adrien nicely accepted to relicense the Joy theme under the GPLv2+ so it
solves the incompatibilities. I’ll update the copyrights.
https://wiki.debian.org/DebianArt/Themes/Joy
As Adrien mentioned, it would be good to impose GPLv2+ for future theme
contributions to avoid headaches for too many people.

Then I propose dropping :

| The Joy grub theme is © 2012 Paul Tagliamonte GPLv2, using artwork from Adrien
| Aubourg licensed under GPLv3 license.

That « theme » is the grub background and like the Joy wallpaper is
strictly based on Adrien’s work + debian open logo without debian, so
it’s already covered by the global copyright statement about the Joy theme.
I see the statement as more noise than information.

I also removed mentions of the « splashy » spacefun theme as splashy is
not used anymore on recent desktops.
 
 Another issue could be:

 | Spacefun plymouth theme is © 2010 Aurelien Couderc and released under the 
 GPLv3
 | license, using artwork from Valessio S. Brito.

 I am not sure: is the part of the Spacefun plymouth theme that's
 copyrighted by you a script that loads Valessio's artwork? Or is
 something that combines with Valessio's artwork, thus creating a whole
 work derived from both parts?
 In the former case I can see no problems; in the latter case, there's
 again an incompatibility issue (GPLv2 vs. GPLv3).
Hard to say really. The copyright is for the script, the script uses
artwork elements to build what’s displayed, where do we stand ?…
Anyway I hereby relicense the script under the GPLv2+, and will update
the script and copyright file accordingly.


All that is committed to the repository, would you mind reviewing again
the latest version ?
(Revision 342).


Thanks,
--Aurélien




signature.asc
Description: OpenPGP digital signature