Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard

[Timo Aaltonen]

Sven Joachim kirjoitti 13.3.2024 klo 19.41:

Control: forwarded -1 https://gitlab.freedesktop.org/mesa/mesa/-/issues/10613

On 2024-02-17 18:53 +0100, Sven Joachim wrote:


Control: severity -1 grave

On 2024-02-17 13:35 +0100, Lorenzo Beretta wrote:


Package: libgl1-mesa-dri
Version: 24.0.1-1
Severity: important

Dear Maintainer,

after the latest upgrade it's impossible for me to run a display manager
or startx any window manager; after at most a few seconds / keypresses /
mouse movements the screen freezes, completely unresponsive to anything
other than the power button; the log below suggests a null pointer.

Running "sleep 30; killall -u lorenzo" as root before startx returns me
to a tty.

Reverting to the previous version everything works.

I'm running this on a debian derivative, devuan; afaik it shouldn't make
a difference, as the package is unmodified from debian - I don't know
how to verify that other than by installing debian in some partition,
can one start some window manager from a debian chroot/whatever?

If it's ok in debian or you need any more info please do let me know.


I can reproduce that on my laptop which runs pure Debian, and at least
one other user seems to have the same problem.


VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc.
[AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520
OEM] [1002:6611]


I have the following graphics hardware:

,
| 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices,
| Inc. [AMD/ATI] Mullins [Radeon R3 Graphics] [1002:985\ 0] (rev 40)
`

This is also using the radeonsi driver, and the symptoms and the
backtrace are the same as yours.

Bumping severity to keep this mesa version out of testing, but I will
not be able to investigate the problem because I need the machine and
have already downgraded all packages from src:mesa.  There does not seem
to be an upstream report yet.


Looks like there is one now and it even has a patch which seems to have
been applied in Archlinux and Ubuntu, but not committed upstream. :-(


Sorry, I noticed this bug right after uploading 24.0.2-1, which is why 
Ubuntu got the patch.. I'll include it in 24.0.3-1.



--
t

Bug#1063370: closing 1063370

[Timo Aaltonen]

close 1063370 1.3.275.0+dfsg1-1
thanks

Didn't realize there was a bug filed for the FTBFS.

Bug#1064294: [Pkg-freeipa-devel] Bug#1064294: bind-dyndb-ldap: FTBFS: error: Install BIND9 development files

[Timo Aaltonen]

Aurelien Jarno kirjoitti 19.2.2024 klo 21.37:

Source: bind-dyndb-ldap
Version: 11.10-6
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

bind-dyndb-ldap fails to build from source, from my build log on amd64:

| checking for -fvisibility=hidden compiler flag... yes
| checking for -fno-delete-null-pointer-checks compiler flag... yes
| checking for -std=gnu11 compiler flag... yes
| checking for isc-config.sh... no
| checking for working isc-config... no
| configure: WARNING:
|   Could not detect script isc-config.sh. Compilation may fail.
|   Defining variable BIND9_CFLAGS will fix this problem.
|   
| checking for isc_dir_open in -lisc... yes
| checking for dns_name_init in -ldns... no
| configure: error: Install BIND9 development files
|   cd build && tail -v -n \+0 config.log

A full build log is also available on riscv64:
https://buildd.debian.org/status/fetch.php?pkg=bind-dyndb-ldap=riscv64=11.10-6%2Bb2=1703783350=0

The issue is also visible on the reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/bind-dyndb-ldap_11.10-6.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/unstable/arm64/bind-dyndb-ldap_11.10-6.rbuild.log.gz

Regards
Aurelien


This issue could be fixed by changing d/patches/hardcode-version.diff, 
but the real issue is that it won't build against 9.19 at all. Upstream 
has known for a year and hasn't fixed it yet. 9.19 should become stable 
9.20 next month, when I'd assume upstream to fix the build.



--
t

Bug#1063434: [Pkg-freeipa-devel] Bug#1063434: src:389-ds-base: fails to migrate to testing for too long: FTBFS on 32 bits

[Timo Aaltonen]

Paul Gevers kirjoitti 8.2.2024 klo 9.38:

Source: 389-ds-base
Version: 2.3.4+dfsg1-1.1
Severity: serious
Control: close -1 2.4.4+dfsg1-1
Tags: sid trixie ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 30 days as having a Release Critical bug in 
testing [1]. Your package src:389-ds-base has been trying to migrate for 
31 days [2]. Hence, I am filing this bug. The version in unstable failed 
to build on armel, armhf and i386 (our 32 bit architectures).


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and trixie, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html
[2] https://qa.debian.org/excuses.php?package=389-ds-base


___
Pkg-freeipa-devel mailing list
pkg-freeipa-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-freeipa-devel


Probably time to finally drop 32bit builds since upstream dropped 
support for them years ago..



--
t

Bug#1042862: Xspice crashes on start

[Timo Aaltonen]

Frank Heckenbach kirjoitti 2.8.2023 klo 0.44:

Package: xserver-xspice
Version: 0.1.6-1
Severity: grave
Justification: renders package unusable

See #1038648.

As I wrote there, 0.1.6-1 doesn't fix the problem, but this was
ignored, so I'm sending a new bug report.

The buggy patch is now upstream, but that doesn't make it correct.
I've already explained how to fix it correctly.



send your explanation upstream, thanks

--
t

Bug#1039922: mesa breaks gtk4 autopkgtest: panel surface gone

[Timo Aaltonen]

Paul Gevers kirjoitti 29.6.2023 klo 17.21:

Source: mesa, gtk4
Control: found -1 mesa/23.1.2-1
Control: found -1 gtk4/4.8.3+ds-2
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of mesa the autopkgtest of gtk4 fails in testing 
when that autopkgtest is run with the binary packages of mesa from 
unstable. It passes when run with only packages from testing. In tabular 
form:


    pass    fail
mesa   from testing    23.1.2-1
gtk4   from testing    4.8.3+ds-2
all others from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of mesa to testing 
[1]. Due to the nature of this issue, I filed this bug report against 
both packages. Can you please investigate the situation and reassign the 
bug to the right package?


More information about this bug and the reason for filing it can be 
found on

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul


Yes, I filed this upstream a while ago and bisected the regressing 
commit now:


https://gitlab.freedesktop.org/mesa/mesa/-/issues/9199

but it's not possible to revert just that, would need to revert 17 
commits in total.


--
t

Bug#1037345: [Pkg-freeipa-devel] Bug#1037345: 389-ds-base: ftbfs with rust-base64 0.21

[Timo Aaltonen]

plugwash kirjoitti 11.6.2023 klo 22.29:

Package: 389-ds-base
Version: 2.3.1+dfsg1-1
Tags: trixie, sid, ftbfs

389-ds-base FTBFS with the new version of rust-base64.

I attach a patch which makes the package build, and also fixes some 
packaging annoyances. I have not tested it beyond that. I may or may not 
NMU this later.


merged thanks, but not uploaded as there seem to be other issues now 
with the dependencies being unable to install at least on my sbuilder




--
t

Bug#1035474: Don't include in Bookworm?

[Timo Aaltonen]

Moritz Muehlenhoff kirjoitti 3.5.2023 klo 20.44:

Source: libdmx
Version: 1:1.1.4-2
Severity: serious

The Xorg folks mentioned at 
https://www.openwall.com/lists/oss-security/2023/05/02/3:

| We have also announced that we plan to retire the following packages soon
| and while their gitlab repos are not yet archived, we expect they will be
| archived in the future, and encourage distros that still ship them to
| consider retiring them on your side as well:
|
| lib/libdmx:
|  The Xdmx server was removed from the xorg-server sources in
|  xorg-server 21 (released Oct. 2021), so this is only useful
|  for communicating with Xdmx from the 1.20 and older releases.

Given that Bookworm has xorg-server 21 and there are no rdeps in the archive,
let's exclude it from bookworm (and remove entirely eventually)?


sounds good

--
t

Bug#1034824: tomcat9 should not be released with Bookworm

[Timo Aaltonen]

Paul Gevers kirjoitti 26.5.2023 klo 22.14:

Hi,

On 26-05-2023 10:58, Moritz Muehlenhoff wrote:

Can't we just do the pragmatic fix of updating src:tomcat9 to only ship
libtomcat9-java and libtomcat9-embed-java? The maintenance burden for
security updates lies within the server stack, the percentage of issues
affecting the libtomcat9-java binary packages as used by rdeps will be 
small

to none?


I have just added removal hints for tomcatjss and dogtag-pki. As 
mentioned in my previous message, I want the changes in logback 
reverted. You can do the reduced upload of tomcat9.


Huh, that was a surprising outcome of the discussion..

--
t

Bug#1034824: tomcat9 should not be released with Bookworm

[Timo Aaltonen]

Timo Aaltonen kirjoitti 16.5.2023 klo 10.12:

Markus Koschany kirjoitti 13.5.2023 klo 23.38:

Hi Salvatore,

adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC

Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso:

Hi Markus,

On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote:

I have just pushed the necessary changes to our Git repository.

https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993


Do we need to have done more here? When Paul asked on #debian-release
I noted that pki-server depends on tomcat9-user, so reducing
libtomcat9-java only would now cause a broken dpeends for pki-server:

$ dak rm --suite=bookworm -n -R -b tomcat9-user
Will remove the following packages from bookworm:

tomcat9-user |   9.0.70-1 | all


We could simply replace tomcat9-user with tomcat10-user because it 
only ships a

script to create a standalone tomcat instance. We have to do
s/tomcat9/tomcat10/ in some debian service files as well.

The question is: If we ship libtomcat9-java in Bookworm and change the
dependency from tomcat9-user to tomcat10-user, will a web application 
like
dogtag-pki, which is designed for Tomcat 9, continue to work with 
Tomcat 10? I

don't know yet and maybe Timo can chime in here.


I don't know, dogtag uses the skel files from tomcat9-user, but I diffed 
them between tomcat9 and 10 and couldn't see why it would regress.


Had a closer look at dogtag, and it's launching the tomcat instance from 
CATALINA_HOME, so it's a one-way ticket to migrate an installed instance 
to use tomcat10 in the configuration, so I don't think moving to 
tomcat10-user would fly..



--
t

Bug#1034824: tomcat9 should not be released with Bookworm

[Timo Aaltonen]

Markus Koschany kirjoitti 13.5.2023 klo 23.38:

Hi Salvatore,

adding Timo Aaltonen, maintainer of dogtag-pki and tomcatjss, to CC

Am Samstag, dem 13.05.2023 um 20:50 +0200 schrieb Salvatore Bonaccorso:

Hi Markus,

On Sat, May 13, 2023 at 06:27:49PM +0200, Markus Koschany wrote:

I have just pushed the necessary changes to our Git repository.

https://salsa.debian.org/java-team/tomcat9/-/commit/adbd0b0711de66b67278b10e258c47c805e9b993


Do we need to have done more here? When Paul asked on #debian-release
I noted that pki-server depends on tomcat9-user, so reducing
libtomcat9-java only would now cause a broken dpeends for pki-server:

$ dak rm --suite=bookworm -n -R -b tomcat9-user
Will remove the following packages from bookworm:

tomcat9-user |   9.0.70-1 | all


We could simply replace tomcat9-user with tomcat10-user because it only ships a
script to create a standalone tomcat instance. We have to do
s/tomcat9/tomcat10/ in some debian service files as well.

The question is: If we ship libtomcat9-java in Bookworm and change the
dependency from tomcat9-user to tomcat10-user, will a web application like
dogtag-pki, which is designed for Tomcat 9, continue to work with Tomcat 10? I
don't know yet and maybe Timo can chime in here.


I don't know, dogtag uses the skel files from tomcat9-user, but I diffed 
them between tomcat9 and 10 and couldn't see why it would regress.


--
t

Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10

[Timo Aaltonen]

Markus Koschany kirjoitti 24.3.2023 klo 15.35:

Am Freitag, dem 24.03.2023 um 09:21 +0200 schrieb Timo Aaltonen:

Markus Koschany kirjoitti 23.3.2023 klo 19.00:

Control: severity -1 serious

On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen 
wrote:
   

Upstream doesn't support tomcat10 yet, and tomcatjss fails to build with
it.


Unfortunately we can only support one Tomcat version per release. We should
either migrate to tomcat10 or maybe it is possible to embed some of the
required tomcat9 classes in your source package as a workaround provided
the
changes are rather small and the security impact is negligible.


Right, but that's for bookworm+1? By that time I'm sure
jss/tomcatjss/dogtag have gained upstream support for tomcat10.


We are targeting Bookworm. We had Tomcat 8 in Stretch and Tomcat 9 in Buster
and Bullseye already. Tomcat 10 also targets Java 11 and later while Tomcat 9
was intended for Java 8 and later. We ship OpenJDK 17 in Bookworm. resteasy3.0
and tomcatjss are the only packages apart from i2p that still depend on
libtomcat9-java.


Nice, so you expect them to migrate after bookworm is already frozen?

--
t

Bug#1031816: [Pkg-freeipa-devel] Bug#1031816: Bug#1031816: tomcatjss: Migrate to Tomcat 10

[Timo Aaltonen]

Markus Koschany kirjoitti 23.3.2023 klo 19.00:

Control: severity -1 serious

On Fri, 24 Feb 2023 11:48:36 +0200 Timo Aaltonen  wrote:
  

Upstream doesn't support tomcat10 yet, and tomcatjss fails to build with it.


Unfortunately we can only support one Tomcat version per release. We should
either migrate to tomcat10 or maybe it is possible to embed some of the
required tomcat9 classes in your source package as a workaround provided the
changes are rather small and the security impact is negligible.


Right, but that's for bookworm+1? By that time I'm sure 
jss/tomcatjss/dogtag have gained upstream support for tomcat10.



--
t

Bug#1013935: [Pkg-freeipa-devel] Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x

[Timo Aaltonen]

Adrian Bunk kirjoitti 3.2.2023 klo 12.01:

On Thu, Feb 02, 2023 at 10:07:24PM +0100, Paul Gevers wrote:

Hi Adrian,

On 02-02-2023 21:32, Adrian Bunk wrote:

On Mon, Jun 27, 2022 at 08:31:53PM +0200, Paul Gevers wrote:

I looked at the results of the autopkgtest of you package because it was
showing up on our "slow" page [1]. I noticed that there were several runs
that took 2:47 (our timeout time), while successful runs more in the order
of minutes.
...


Lookking at debci results with recent versions, this problem seems to be
fixed now?


It was a mistake that the block was lifted, but indeed, you might be right.


There only seems to be an unrelated(?) error
Installation failed: Server did not start after 60s
on !amd64 that results in fast failures.


But that is an RC issue on it's own, because dogtag-pki used to pass on all
architectures and autopkgtest regression is listed on
https://release.debian.org/testing/rc_policy.txt


But that's a different issue, and one that could be workarounded with
   Architecture: amd64
for the autopkgtest.


That wouldn't be an unreasonable workaround, as upstream mostly (/only?) 
cares about amd64. I'll add that.



--
t

Bug#1013935: [Pkg-freeipa-devel] Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x

[Timo Aaltonen]

Timo Aaltonen kirjoitti 12.1.2023 klo 20.57:

Paul Gevers kirjoitti 27.6.2022 klo 21.31:

Source: dogtag-pki
Version: 11.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it 
was showing up on our "slow" page [1]. I noticed that there were 
several runs that took 2:47 (our timeout time), while successful runs 
more in the order of minutes.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put dogtag-pki on our reject_list for amd64, 
armhf, and s390x.


Don't hesitate to reach out if you need help and some more information
from our infrastructure. E.g. I note that the runs on amd64 that I 
happen to check are run on ci-worker13 that, together with our armhf 
worker is running on a host with lots of CPUs (64 and 160) and RAM 
(256GB and 511GB) and also our s390x has 10 CPUs and 32 GB.


Paul

[1] https://ci.debian.net/status/slow/


Hi,

I've finally updated dogtag-pki to fix some grave bugs, but this still 
remains. I don't know if the update fixes these racy tests (which they 
are, something goes wrong and it gets stuck), but is there a way for me 
to manually trigger them on ci.debian.net? They do pass on salsa-ci, but 
it's not the same thing..


Looks like the tests are still being run, which at least shows that they 
seem to be just as racy still :/ I need to reproduce the failure 
locally, which has been impossible so far.


--
t

Bug#1013935: [Pkg-freeipa-devel] Bug#1013935: dogtag-pki: flaky autopkgtest: regularly times out on amd64, armhf and s390x

[Timo Aaltonen]

Paul Gevers kirjoitti 27.6.2022 klo 21.31:

Source: dogtag-pki
Version: 11.0.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainer(s),

I looked at the results of the autopkgtest of you package because it was 
showing up on our "slow" page [1]. I noticed that there were several 
runs that took 2:47 (our timeout time), while successful runs more in 
the order of minutes.


Because the unstable-to-testing migration software now blocks on
regressions in testing, flaky tests, i.e. tests that flip between
passing and failing without changes to the list of installed packages,
are causing people unrelated to your package to spend time on these
tests.

On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put dogtag-pki on our reject_list for amd64, armhf, 
and s390x.


Don't hesitate to reach out if you need help and some more information
from our infrastructure. E.g. I note that the runs on amd64 that I 
happen to check are run on ci-worker13 that, together with our armhf 
worker is running on a host with lots of CPUs (64 and 160) and RAM 
(256GB and 511GB) and also our s390x has 10 CPUs and 32 GB.


Paul

[1] https://ci.debian.net/status/slow/


Hi,

I've finally updated dogtag-pki to fix some grave bugs, but this still 
remains. I don't know if the update fixes these racy tests (which they 
are, something goes wrong and it gets stuck), but is there a way for me 
to manually trigger them on ci.debian.net? They do pass on salsa-ci, but 
it's not the same thing..



--
t

Bug#1026809: Xlib: sequence lost (0x10000 > 0x...) in reply type 0x... when running emacs

[Timo Aaltonen]

Vincent Lefevre kirjoitti 21.12.2022 klo 15.01:

Package: libx11-6
Version: 2:1.8.3-2
Severity: grave
Justification: renders package unusable

or possible data loss?

After the upgrade to libx11-6 2:1.8.3-2, I get the following errors
when running emacs:

e.g.

Xlib: sequence lost (0x1 > 0x473) in reply type 0x21!
Xlib: sequence lost (0x1 > 0x58e) in reply type 0xf!
Xlib: sequence lost (0x1 > 0x9bb) in reply type 0xf!
Xlib: sequence lost (0x1 > 0xfb4) in reply type 0xc!
Xlib: sequence lost (0x1 > 0xfbe) in reply type 0xf!

or

Xlib: sequence lost (0x1 > 0x450) in reply type 0x1c!
Xlib: sequence lost (0x1 > 0x45b) in reply type 0x13!
Xlib: sequence lost (0x1 > 0x473) in reply type 0x21!
Xlib: sequence lost (0x1 > 0x567) in reply type 0xf!
Xlib: sequence lost (0x1 > 0xa0d) in reply type 0xf!
Xlib: sequence lost (0x1 > 0xfb7) in reply type 0xc!
Xlib: sequence lost (0x1 > 0xfc1) in reply type 0xf!

etc.

This changes each time.

Not sure about the bug severity, but if such errors are output,
this means that they are really serious. Otherwise, the end user
shouldn't be bothered. In any case, this must be fixed before
the next Debian release.



meh, well the offending commit is found so I'll revert that as well 
unless a fix is made upstream soon, and that's unlikely due to holidays



--
t

Bug#1026071: xorg-server: CVE-2022-4283 CVE-2022-46340 CVE-2022-46341 CVE-2022-46342 CVE-2022-46343 CVE-2022-46344

[Timo Aaltonen]

Salvatore Bonaccorso kirjoitti 14.12.2022 klo 11.42:


btw, there's a typo in one of the CVE's, it's -46283 not -4283:

https://lists.x.org/archives/xorg-announce/2022-December/003302.html

the typo is also on the git commit but I fixed it on d/changelog


Should already be correct in above listing and security-tracker. But
right the final advisory upstream still has the typo.


Hmm so the announce mail was wrong and it's actually -4283?? These 
aren't public so I wasn't able to check, my bad..


--
t

Bug#1026071: xorg-server: CVE-2022-4283 CVE-2022-46340 CVE-2022-46341 CVE-2022-46342 CVE-2022-46343 CVE-2022-46344

[Timo Aaltonen]

Salvatore Bonaccorso kirjoitti 14.12.2022 klo 11.19:

Source: xorg-server
Version: 2:21.1.4-3
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for xorg-server.

CVE-2022-4283[0]:
| xkb: reset the radio_groups pointer to NULL after freeing it

CVE-2022-46340[1]:
| Xtest: disallow GenericEvents in XTestSwapFakeInput

CVE-2022-46341[2]:
| Xi: disallow passive grabs with a detail > 255

CVE-2022-46342[3]:
| Xext: free the XvRTVideoNotify when turning off from the same client

CVE-2022-46343[4]:
| Xext: free the screen saver resource when replacing it

CVE-2022-46344[5]:
| Xi: avoid integer truncation in length check of ProcXIChangeProperty

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4283
 https://www.cve.org/CVERecord?id=CVE-2022-4283
[1] https://security-tracker.debian.org/tracker/CVE-2022-46340
 https://www.cve.org/CVERecord?id=CVE-2022-46340
[2] https://security-tracker.debian.org/tracker/CVE-2022-46341
 https://www.cve.org/CVERecord?id=CVE-2022-46341
[3] https://security-tracker.debian.org/tracker/CVE-2022-46342
 https://www.cve.org/CVERecord?id=CVE-2022-46342
[4] https://security-tracker.debian.org/tracker/CVE-2022-46343
 https://www.cve.org/CVERecord?id=CVE-2022-46343
[5] https://security-tracker.debian.org/tracker/CVE-2022-46344
 https://www.cve.org/CVERecord?id=CVE-2022-46344
[6] https://lists.x.org/archives/xorg-announce/2022-December/003302.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



I've uploaded 21.1.5-1 ~20min ago :) All of these were referenced in the 
changelog.


btw, there's a typo in one of the CVE's, it's -46283 not -4283:

https://lists.x.org/archives/xorg-announce/2022-December/003302.html

the typo is also on the git commit but I fixed it on d/changelog


--
t

Bug#1023204: closing 1023204

[Timo Aaltonen]

close 1023204 
thanks

alright, good to know

Bug#1012067: closing 1012067

[Timo Aaltonen]

close 1012067 5.2.0-1
thanks

forgot to close this via the changelog

Bug#1022577: llvm-toolchain-15 fails with LLVM ERROR when using mesa

[Timo Aaltonen]

Adrian Bunk kirjoitti 24.10.2022 klo 12.45:

Source: llvm-toolchain-15
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian X Strike Force 
Control: affects -1 src:mesa src:lomiri-settings-components src:clutter-1.0 
src:mutter src:gtk4 src:mrpt src:sphinx
Control: block 1022576 by -1

https://buildd.debian.org/status/fetch.php?pkg=mutter=armhf=43.0-3=1666029584=0

...
# Start of pipeline tests
LLVM ERROR: Cannot select: 0x1300f80: v4i32 = ARMISD::VCMPZ 0x1301c70, 
Constant:i32<2>
   0x1301c70: v4i32,ch = ARMISD::VLD1DUP<(load (s32) from %ir.212)> 0xdf9afc, 
0x131c538:1, Constant:i32<4>
 0x131c538: i32,i32,ch = load<(load (s32) from %ir.209, align 8), > 
0xdf9afc, 0x12fb7e0, Constant:i32<64>
   0x12fb7e0: i32,ch = CopyFromReg 0xdf9afc, Register:i32 %23
 0x12e99c0: i32 = Register %23
   0x131a9a8: i32 = Constant<64>
 0x1319fd0: i32 = Constant<4>
   0x131a2e8: i32 = Constant<2>
In function: fs_variant_partial
...


Some discussion is in
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-15/+bug/1993800



This needs 
https://github.com/llvm/llvm-project/commit/f970b007e55d6dab6d84d98a39658a58019eb06e


please include in the llvm package for now


--
t

Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO

[Timo Aaltonen]

Leandro Cunha kirjoitti 20.8.2022 klo 22.15:

Hi.

Had the same problem with me and I don't see a good idea to send
release candidate versions to sid/testing but to experimental. There
are a lot of people who use sid/testing on a daily basis.
With the graphics card NVidia GT310 using the Nouveau.
But it was good to catch the problem before launch.



Upload to sid was a mistake.

File this bug upstream, don't assume newer rc's will fix it.


--
t

Bug#998534: closing 998534

[Timo Aaltonen]

close 998534 1.26+git20220524-1
thanks

Bug#1012502: [Pkg-sssd-devel] Bug#1012502: Bug#1012502: Bug#1012502: sssd: authentication fails with latest sssd

[Timo Aaltonen]

Timo Aaltonen kirjoitti 9.6.2022 klo 9.51:

Michael Stone kirjoitti 8.6.2022 klo 18.52:

On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote:

Did you have 2.7.0 at some point?


2.7.0-1 was installed 2022-05-27
2.7.0-1+b1 was installed 2022-05-29

no issues with either of those; I reverted to 2.6.3 just because it 
was easier to grab from the mirrors.


I guess it should be filed upstream then, if it's a regression in 2.7.1 
which was supposed to be a bugfix release.




actually, this should fix it:

https://github.com/SSSD/sssd/pull/6204



--
t

Bug#1012502: [Pkg-sssd-devel] Bug#1012502: Bug#1012502: sssd: authentication fails with latest sssd

[Timo Aaltonen]

Michael Stone kirjoitti 8.6.2022 klo 18.52:

On Wed, Jun 08, 2022 at 05:41:00PM +0300, Timo Aaltonen wrote:

Did you have 2.7.0 at some point?


2.7.0-1 was installed 2022-05-27
2.7.0-1+b1 was installed 2022-05-29

no issues with either of those; I reverted to 2.6.3 just because it was 
easier to grab from the mirrors.


I guess it should be filed upstream then, if it's a regression in 2.7.1 
which was supposed to be a bugfix release.


https://github.com/SSSD/sssd/issues


--
t

Bug#1012502: [Pkg-sssd-devel] Bug#1012502: sssd: authentication fails with latest sssd

[Timo Aaltonen]

Michael Stone kirjoitti 8.6.2022 klo 15.44:

Package: sssd
Version: 2.7.1-1
Severity: critical
Justification: breaks the whole system

Installing sssd 2.7.1-1 causes IPA/krb5 authentication to fail with messages
such as the following in /var/log/sssd/sssd_DOMAIN.log

(2022-06-07 18:31:36): [be[DOMAIN]] [krb5_auth_done] (0x3f7c0): [RID#10] The 
krb5_child process returned an error. Please inspect the krb5_child.log file or 
the journal for more information
(2022-06-07 18:32:59): [be[DOMAIN]] [krb5_auth_send] (0x0020): [RID#14] Illegal 
empty authtok for user [USER@DOMAIN]
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
[...]
*  (2022-06-07 18:32:59): [be[DOMAIN]] [krb5_auth_queue_send] (0x1000): 
[RID#14] Wait queue of user [USER@DOMAIN] is empty, running request 
[0x560b4c6ac820] immediately.
*  (2022-06-07 18:32:59): [be[DOMAIN]] [krb5_auth_send] (0x0020): [RID#14] 
Illegal empty authtok for user [USER@DOMAIN]
** BACKTRACE DUMP ENDS HERE 
*


while in /var/log/sssd/krb5_child.log:

(2022-06-07 18:31:36): [krb5_child[2481391]] [sss_extract_pac] (0x0040): 
[RID#10] No PAC authdata available.
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
[...]
*  (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x2000): 
[RID#10] Found keytab entry with the realm of the credential.
*  (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x0400): 
[RID#10] TGT verified using key for [PRINCIPAL@DOMAIN].
*  (2022-06-07 18:31:36): [krb5_child[2481391]] [sss_extract_pac] (0x0040): 
[RID#10] No PAC authdata available.
** BACKTRACE DUMP ENDS HERE 
*

(2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x0020): [RID#10] 
PAC check failed for principal [USER@DOMAIN].
(2022-06-07 18:31:36): [krb5_child[2481391]] [get_and_save_tgt] (0x0020): 
[RID#10] 2045: [1432158308][Unknown code UUz 100]
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
*  (2022-06-07 18:31:36): [krb5_child[2481391]] [validate_tgt] (0x0020): 
[RID#10] PAC check failed for principal [USER@DOMAIN].
*  (2022-06-07 18:31:36): [krb5_child[2481391]] [get_and_save_tgt] 
(0x0020): [RID#10] 2045: [1432158308][Unknown code UUz 100]
** BACKTRACE DUMP ENDS HERE 
*

(2022-06-07 18:31:36): [krb5_child[2481391]] [map_krb5_error] (0x0020): 
[RID#10] [1432158308][PAC check failed].
(2022-06-08  8:06:08): [krb5_child[2498572]] [sss_extract_pac] (0x0040): 
[RID#93] No PAC authdata available.
** PREVIOUS MESSAGE WAS TRIGGERED BY THE FOLLOWING 
BACKTRACE:
[...]


Reverting to sssd 2.6.3-3 immediately reestablishes authentication.


Did you have 2.7.0 at some point?


--
t

Bug#1001801: [Pkg-freeipa-devel] Bug#1001801: closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#1001801: fixed in dogtag-pki 11.0.3-1)

[Timo Aaltonen]

Paul Gevers kirjoitti 15.3.2022 klo 21.58:

Control: reopen -1

Hi

On 15-03-2022 13:09, Debian Bug Tracking System wrote:

#1001801: dogtag-pki: hits autopkgtest timeout on powerful workers

It has been closed by Debian FTP Masters 
 (reply to Timo Aaltonen 
).


Sorry to say, but this seems to not have solved the issue:

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dogtag-pki/20012305/log.gz 


yeah, I'll ask upstream why starting webapps have no default timeout.. 
trying to force it didn't work here.




--
t

Bug#1006014: [Pkg-freeipa-devel] Bug#1006014: FTBFS: void value not ignored as it ought to be

[Timo Aaltonen]

Ryan Tandy kirjoitti 19.2.2022 klo 0.46:

Source: bind-dyndb-ldap
Version: 11.9-4
Severity: serious
Tags: ftbfs

Dear Maintainer,

bind-dyndb-ldap fails to build from source on amd64:

/bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../src -I..   
-Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -std=gnu99 -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-uninitialized -fvisibility=hidden 
-fno-delete-null-pointer-checks -c -o ldap_la-acl.lo `test -f 'acl.c' || echo 
'../../src/'`acl.c
In file included from ../../src/fwd_register.h:11,
  from ../../src/ldap_entry.h:11,
  from ../../src/acl.h:10,
  from ../../src/acl.c:32:
../../src/acl.c: In function ‘acl_configure_zone_ssutable’:
../../src/util.h:29:24: error: void value not ignored as it ought to be
29 | result = (op);  \
   |^
../../src/acl.c:286:9: note: in expansion of macro ‘CHECK’
   286 | CHECK(dns_ssutable_create(mctx, ));
   | ^
../../src/acl.c:328:24: error: void value not ignored as it ought to be
   328 | result = dns_ssutable_addrule(table, grant,
   |^
make[3]: *** [Makefile:542: ldap_la-acl.lo] Error 1

This looks like it could be caused by a recent change in bind9:

https://gitlab.isc.org/isc-projects/bind9/-/commit/8fb4c5bb7a703e7c174ccd13b2ede618696af69c

The complete build log is attached.

Thank you,
Ryan


Yes, known upstream and not fixed yet:

https://pagure.io/bind-dyndb-ldap/pull-request/212



--
t

Bug#1004729: bind9-dyndb-ldap: fails to load dyndb-ldap backend

[Timo Aaltonen]

l3mm.0x kirjoitti 1.2.2022 klo 12.35:
> Package: bind9-dyndb-ldap
> Version: 11.6-3
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> after an upgrade from buster to bullseye my previously working 
> bind9-dyndb-ldap
> installation dosn't work anymore.
> 
> It seems that there is something wrong with the dependencies to the package
> bind9-libs.
> 
> named log:
> ...
> Feb 01 07:53:19 testing named[4485]: loading DynDB instance 'ldap-db' driver
> '/usr/lib/bind/ldap.so'
> Feb 01 07:53:19 testing named[4485]: failed to dynamically load instance 
> 'ldap-
> db' driver '/usr/lib/bind/ldap.so': libdns-9.16.15-Debian.so: cannot open
> shared object file: No such file or directory (failure)
> Feb 01 07:53:19 testing named[4485]: dynamic database 'ldap-db' configuration
> failed: failure
> Feb 01 07:53:19 testing named[4485]: loading configuration: failure
> Feb 01 07:53:19 testing named[4485]: exiting (due to fatal error)
> 
> 
> The package bind9-libs lists a newer version about the shared object file.
> 
> /usr/lib/x86_64-linux-gnu
> /usr/lib/x86_64-linux-gnu/libbind9-9.16.22-Debian.so
> /usr/lib/x86_64-linux-gnu/libdns-9.16.22-Debian.so
> /usr/lib/x86_64-linux-gnu/libirs-9.16.22-Debian.so
> /usr/lib/x86_64-linux-gnu/libisc-9.16.22-Debian.so
> /usr/lib/x86_64-linux-gnu/libisccc-9.16.22-Debian.so
> /usr/lib/x86_64-linux-gnu/libisccfg-9.16.22-Debian.so
> /usr/lib/x86_64-linux-gnu/libns-9.16.22-Debian.so

Oh nice, a rather big version bump disguised as a CVE update.. You'd
need the version from unstable to have some hope of it working with
bind9 9.16.17+.

Bug#1001311: [Pkg-freeipa-devel] Bug#1001311: certmonger: FTBFS with openssl 3

[Timo Aaltonen]

On 8.12.2021 9.09, Steve Langasek wrote:

Source: certmonger
Version: 0.79.14+git20211010-2
Severity: serious
Tags: experimental
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu jammy

Hi Timo,

certmonger FTBFS against openssl 3 with an undefined symbol error:

[...]
gcc   -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -isystem 
/usr/include/mit-krb5   -I/usr/include/uuid -g -O2 
-ffile-prefix-map=/<>/certmonger-0.79.14+git20211010=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra  
-I/usr/include/libxml2 -I/usr/include/nss -I/usr/include/nspr -I/usr/include/x86_64-linux-gnu -g -O2 
-ffile-prefix-map=/<>/certmonger-0.79.14+git20211010=. -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wextra -fPIC  -fPIC 
-pie -Wl,-z,relro,-z,now -o scep-submit scep_submit-scep.o scep_submit-submit-h.o scep_submit-util-m.o 
scep_submit-util-o.o scep_submit-submit-u.o scep_submit-util.o scep_submit-log.o scep_submit-pkcs7.o 
scep_submit-store-gen.o scep_submit-tm.o scep_submit-prefs.o scep_submit-prefs-o.o scep_submit-scep-o.o 
scep_submit-env-system.o -lcurl -lxml2 -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 
-lcrypto -ltalloc  -luuid  -lpopt
../../src/submit-h.c: In function ‘cm_submit_h_run’:
../../src/submit-h.c:257:17: warning: call to 
‘_curl_easy_setopt_err_write_callback’ declared with attribute warning: 
curl_easy_setopt expects a curl_write_callback argument for this option 
[-Wattribute-warning]
   257 | curl_easy_setopt(ctx->curl, CURLOPT_WRITEFUNCTION,
   | ^
/usr/bin/ld: /tmp/ccPXkLF2.ltrans0.ltrans.o: in function `main':
./build/src/../../src/util-o.c:54: undefined reference to `OPENSSL_init_ssl'
collect2: error: ld returned 1 exit status
[...]

   
(https://launchpad.net/ubuntu/+source/certmonger/0.79.14+git20211010-2/+build/22293176)

openssl 3 is currently in experimental, and is expected to ship with the
next version of Debian.  It is also the version of openssl to be used for
the upcoming Ubuntu 22.04 LTS release.


Hi,

Yeah looks like upstream was lazy and never pushed a bunch of fixes from 
the Fedora package to upstream git, but I've poked them about this and 
should get a new release soon.



--
t

Bug#1000576: closing 1000576

[Timo Aaltonen]

On 25.11.2021 17.38, Salvo Tomaselli wrote:

What about the evdev one?


What about it? -libinput replaced it and has more features.


--
t

Bug#1000576: closing 1000576

[Timo Aaltonen]

close 1000576 
thanks

Not going to happen, synaptics is unmaintained and dropped for a reason. You 
can still
have both installed and configure X to use synaptics instead after installing 
it.

Bug#998575: [Pkg-freeipa-devel] Bug#998575: Bug#998575: Bug#998575: bind-dyndb-ldap: FTBFS: build-dependency not installable: bind9-libs (= 1:9.16.21-1)

[Timo Aaltonen]

On 12.11.2021 15.14, Timo Aaltonen wrote:
Thanks for adding the -dev, but it's missing the .so's? bind-dyndb-ldap 
fails to pass configure with the current version.


Looks like dns/version.h is gone as well, and there are several checks 
for the version in the code.


I see that lib/bind/api was removed in 9.17.10, bind-dyndb-ldap has not 
even looked at 9.17 yet..



--
t

Bug#998575: [Pkg-freeipa-devel] Bug#998575: Bug#998575: bind-dyndb-ldap: FTBFS: build-dependency not installable: bind9-libs (= 1:9.16.21-1)

[Timo Aaltonen]

On 9.11.2021 10.53, Ondřej Surý wrote:

Hi Timo,


On 5. 11. 2021, at 8:09, Timo Aaltonen  wrote:

On 5.11.2021 1.37, peter green wrote:

  bind9-dev : Depends: bind9-libs (= 1:9.16.21-1) but it is not going to be 
installed

It looks like bind8 no longer builds the bind9-dev package. It's still present 
in
unstable as a cruft package but is uninstallable due to version constraints, 
it's
completely gone from testing.


I don't know what's going on here, but at least the current bind9 packaging is 
not available on salsa, debian/main is on 9.16.22-1 and according to 
d/changelog it was uploaded to unstable on the same day as 9.17.19-1... (which 
has now migrated to testing already)


The 9.17 packaging is available from the isc/9.17 branch which should be up to 
date.


The new bind9 doesn't mention dropping bind9-dev on d/changelog. Ondrej, why 
was it dropped?


We need to figure out what to do with bind-dyndb-ldap in the future.  The BIND 
9 libraries are not
meant for public consumption since 9.14.0. The upstream (which is incidentally 
also me) has declare the libraries
private and the symbols could change even between patch releases. There’s 
absolutely no guarantee
about symbol stability even on stable branch.

Unfortunately, bind-dyndb-ldap is licensed under GPL-2.0 which makes it 
impossible to include
it directly in the src:bind9 package.

I see no easy way from this. I will reintroduce the bind9-dev package, but this 
will make
the bind-dyndb-ldap package to regularly FTBFS anyway and it needs to be fixed 
before
the next stable release.


Thanks for adding the -dev, but it's missing the .so's? bind-dyndb-ldap 
fails to pass configure with the current version.


Looks like dns/version.h is gone as well, and there are several checks 
for the version in the code.



--
t

Bug#998575: [Pkg-freeipa-devel] Bug#998575: Bug#998575: bind-dyndb-ldap: FTBFS: build-dependency not installable: bind9-libs (= 1:9.16.21-1)

[Timo Aaltonen]

On 9.11.2021 10.53, Ondřej Surý wrote:

Hi Timo,


On 5. 11. 2021, at 8:09, Timo Aaltonen  wrote:

On 5.11.2021 1.37, peter green wrote:

  bind9-dev : Depends: bind9-libs (= 1:9.16.21-1) but it is not going to be 
installed

It looks like bind8 no longer builds the bind9-dev package. It's still present 
in
unstable as a cruft package but is uninstallable due to version constraints, 
it's
completely gone from testing.


I don't know what's going on here, but at least the current bind9 packaging is 
not available on salsa, debian/main is on 9.16.22-1 and according to 
d/changelog it was uploaded to unstable on the same day as 9.17.19-1... (which 
has now migrated to testing already)


The 9.17 packaging is available from the isc/9.17 branch which should be up to 
date.


The new bind9 doesn't mention dropping bind9-dev on d/changelog. Ondrej, why 
was it dropped?


We need to figure out what to do with bind-dyndb-ldap in the future.  The BIND 
9 libraries are not
meant for public consumption since 9.14.0. The upstream (which is incidentally 
also me) has declare the libraries
private and the symbols could change even between patch releases. There’s 
absolutely no guarantee
about symbol stability even on stable branch.

Unfortunately, bind-dyndb-ldap is licensed under GPL-2.0 which makes it 
impossible to include
it directly in the src:bind9 package.

I see no easy way from this. I will reintroduce the bind9-dev package, but this 
will make
the bind-dyndb-ldap package to regularly FTBFS anyway and it needs to be fixed 
before
the next stable release.


Ok thanks. I asked about plans to upstream the ldap plugin, but 
apparently "upstream was not interested in it". Would it be possible to 
get merged now? :) (if the license is changed, of course)




--
t

Bug#998575: [Pkg-freeipa-devel] Bug#998575: bind-dyndb-ldap: FTBFS: build-dependency not installable: bind9-libs (= 1:9.16.21-1)

[Timo Aaltonen]

On 5.11.2021 9.09, Timo Aaltonen wrote:

On 5.11.2021 1.37, peter green wrote:
 >  bind9-dev : Depends: bind9-libs (= 1:9.16.21-1) but it is not 
going to be installed


It looks like bind8 no longer builds the bind9-dev package. It's still 
present in
unstable as a cruft package but is uninstallable due to version 
constraints, it's

completely gone from testing.


I don't know what's going on here, but at least the current bind9 
packaging is not available on salsa, debian/main is on 9.16.22-1 and 
according to d/changelog it was uploaded to unstable on the same day as 
9.17.19-1... (which has now migrated to testing already)


The new bind9 doesn't mention dropping bind9-dev on d/changelog. Ondrej, 
why was it dropped?


Looks like the the commit that added bind9-dev back in 1:9.16.2-2 is 
missing from 9.17, and the common base for the branches is 1:9.16.1-1 so 
there might be other changes missing, not to mention the changelog 
history from 1:9.16.1-2..1:9.16.21-1 is lost from the new version..


I'd have assumed that reverse build-depends are checked before migration 
to testing?


--
t

Bug#998575: [Pkg-freeipa-devel] Bug#998575: bind-dyndb-ldap: FTBFS: build-dependency not installable: bind9-libs (= 1:9.16.21-1)

[Timo Aaltonen]

On 5.11.2021 1.37, peter green wrote:
 >  bind9-dev : Depends: bind9-libs (= 1:9.16.21-1) but it is not going 
to be installed


It looks like bind8 no longer builds the bind9-dev package. It's still 
present in
unstable as a cruft package but is uninstallable due to version 
constraints, it's

completely gone from testing.


I don't know what's going on here, but at least the current bind9 
packaging is not available on salsa, debian/main is on 9.16.22-1 and 
according to d/changelog it was uploaded to unstable on the same day as 
9.17.19-1... (which has now migrated to testing already)


The new bind9 doesn't mention dropping bind9-dev on d/changelog. Ondrej, 
why was it dropped?


--
t

Bug#996946: freeipa-server: Server setup can fail due to some race in configuring pki-tomcatd

[Timo Aaltonen]

Package: freeipa-server
Version: 4.9.7-1
Severity: serious
Justification: RT

This is a placeholder bug preventing migration to testing, until the root cause 
of server
setup failing randomly is found. Seems to be related to slapd and pki-tomcatd; 
in some
cases it doesn't trust it's own certificate or something.


-- System Information:
Debian Release: 11.0
  APT prefers impish-updates
  APT policy: (500, 'impish-updates'), (500, 'impish-security'), (500, 'impish')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.13.0-19-generic (SMP w/8 CPU threads)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=fi:en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#970880: closing 970880

[Timo Aaltonen]

close 970880 0.79.14+git20211010-1
thanks

So, as it turns out this bug was caused by certmonger still being
built against libcurl4-nss-dev, while the rest of the stack had moved to
openssl.. Many thanks to Spencer Olson for figuring it out!

The current stack on unstable seems to be able to pass ipaserver-install,
at least without bind9 and dnssec, but I'm sure there are some kinks left to
fix. Anyway, I wouldn't consider all of this backportable until it passes the
full test suite on Azure, and that's still WIP.

timo

Bug#996408: libepoxy: autopkgtest failure: No such build data file as "'/tmp/autopkgtest-lxc.08f3y1bd/downtmp/build.XWR/src/meson-private/build.dat'".

[Timo Aaltonen]

On 13.10.2021 22.09, Paul Gevers wrote:

Source: libepoxy
Version: 1.5.9-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: fails-always

Dear maintainer(s),

You recently added an autopkgtest to your package libepoxy, great.
However, it fails. Currently this failure is blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

I copied some of the output at the bottom of this report.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libepoxy

https://ci.debian.net/data/autopkgtest/testing/amd64/libe/libepoxy/15268087/log.gz


autopkgtest [18:51:12]: test upstream-tests: [---

ERROR: No such build data file as
"'/tmp/autopkgtest-lxc.08f3y1bd/downtmp/build.XWR/src/meson-private/build.dat'".
autopkgtest [18:51:13]: test upstream-tests: ---]



That was a lousy attempt at trying to run the build-time tests, 
uncommitted files were left on the repo and got included. I'll drop them.




--
t

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 12.10.2021 23.53, Spencer Olson wrote:

On Tue, Oct 12, 2021 at 2:17 PM Timo Aaltonen  wrote:


On 12.10.2021 20.48, Spencer Olson wrote:

On Tue, Oct 12, 2021 at 9:53 AM Spencer Olson  wrote:


On Sun, Oct 10, 2021 at 12:58 PM Timo Aaltonen  wrote:





Maybe the CI will finish before I can get back to my testing.


And it did, this error is fixed now :)

But it fails later on, so there's some work still to catch up with the
current distro, but at least this particular annoyance is resolved, so
many thanks for figuring it out! I was sure the reason was something
silly and related to the SSL stack (or maybe ciphers) but was blind to
see it.


I borrowed the .deb packages from the build artifacts and tested more.
You probably already have this fixed but,
* /var/lib/gssproxy directory has to be created so that gssproxy can
be started.


gssproxy 0.8.2-2 or newer has it.


I have tried to keep my Debian Sid instance updated.  It has gssproxy
0.8.4-1 installed.  Installing gssproxy 0.8.4-1 did not result in
/var/lib/gssproxy being created.  Just for kicks, I tried removing
then reinstalling to see if anything different would happen--it didn't
and the directory still does not exist simply due to installation.


Huh, you're right, 0.8.4-1 cleans the dirs after dh_auto_install.. -2 
fixes that.




Well, at this point my focus is on getting a working baseline on Debian sid.


Unless you request any specific help, I will keep testing as you
submit changes or new CI tests.


Cool, so since this bug is essentially fixed, further hacking on the 
packaging would probably best be handled via irc or 
pkg-freeipa-de...@alioth-lists.debian.net. The latter will also get all 
bug/salsa spam.



--
t

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 12.10.2021 20.48, Spencer Olson wrote:

On Tue, Oct 12, 2021 at 9:53 AM Spencer Olson  wrote:


On Sun, Oct 10, 2021 at 12:58 PM Timo Aaltonen  wrote:





Maybe the CI will finish before I can get back to my testing.


And it did, this error is fixed now :)

But it fails later on, so there's some work still to catch up with the
current distro, but at least this particular annoyance is resolved, so
many thanks for figuring it out! I was sure the reason was something
silly and related to the SSL stack (or maybe ciphers) but was blind to
see it.


I borrowed the .deb packages from the build artifacts and tested more.
You probably already have this fixed but,
   * /var/lib/gssproxy directory has to be created so that gssproxy can
be started.


gssproxy 0.8.2-2 or newer has it.


I manually created the path and ran the script again.  It passes the
gssproxy error that the CI got stuck on, but it failed at creating the
client with this error:

DEBUG The ipa-client-install command failed, exception: KerberosError:
No valid Negotiate header in server response
2021-10-11T09:32:49Z ERROR No valid Negotiate header in server response

I've found a few posts online with errors similar to this in 2019 (one
"solution" supposedly posted on RedHat's site that I don't have access
to).  But, I haven't figured this one out yet.  Perhaps you already
know how to fix this one.


So, I am now wondering if the latest issue I am seeing (where iti
complains about the Negotiate problem) might be due to the bind9
configuration/installation not being quite correct.

I have two VMs, one for CentOS Stream.
For the CentOS stream VM:
  - just uses a DHCP address because I was lazy in the setup and didn't
take the time to change this
  - ipa-server-install finished successfully
  - there is a named-pkcs11 program installed and corresponding
processing running
  - the named-pkcs11 program is certainly linked to a few libraries
that the normal named program is not linked to
  - the nameserver resolves things as expected:  the host of the server
("sid" in my test case) and certainly also ipa-ca.domain resolve just
fine
  - bind9-dyndb-ldap *is* installed
  - doing "fuser /usr/lib64/bind/ldap.so" does show the process ID of
named-pkcs11

For the Debian sid install:
  - Uses netplan to specify a static IP.  This is the same VM i've been
using for all my tests, though I have been using and unwinding
snapshots a lot from test to test.
  - ipa-server-install fails at the point that the ipa-client-install runs
  - named-pkcs11 does *not* exist as an installed program
  - `named` process is running and does respond to queries, but it does
not resolve anything useful
  - browsing through the LDAP entries for DNS, I can see entries for
the ipa server, but named does not resolve these
  - bind9-dyndb-ldap *is* installed.
  - doing "fuser /usr/lib64/bind/ldap.so" does show the process ID of
named-pkcs11

So, clearly, there is a difference between the install on CentOS and
Debian Sid with the latest updates.  I might add that my working old
ubuntu machine does indeed have the named-pkcs11 process.  I am
wondering if this is a problem that was never resolved since the
updates to the new bind9 that plagued getting freeipa to work for
debian originally.  Perhaps this was never fully finished because we
never had freeipa to actually test the changes in the bind9 package.


Well, at this point my focus is on getting a working baseline on Debian sid.

named-pkcs11 isn't used anymore with the current versions.


--
t

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 10.10.2021 20.04, Spencer Olson wrote:



On Sun, Oct 10, 2021, 10:38 Timo Aaltonen <mailto:tjaal...@debian.org>> wrote:


On 10.10.2021 18.41, Spencer Olson wrote:
 > Did some more investigation.  I downloaded the packages that are
being
 > used on centos stream 8.  First I tried my test code with their
version
 > of libssl3.so preloaded:  it failed in the same way as all the
others
 > failed--not surprisingly since its version is much later than the
3.39
 > version where this changed.
 >
 > Then, I downloaded and took a look at "dogtag-submit" from the
CentOS
 > Stream 8 (RedHat) certmonger package.  As far as I can tell, their
 > version of "dogtag-submit" is *not* linked against libcurl-nss.so
at all
 > like the version on debian sid.  Instead, all their certmonger
helper
 > programs are linked against the OpenSSL version (libcurl.so.4).
 >
 > So, I think that we should just link these against the openssl
version,
 > as the RedHat packages do and get things to work again.

Hmm, thanks.. indeed certmonger is still built against
libcurl4-nss-dev,
I've changed it to openssl now and see how it goes against gitlab CI..


Maybe the CI will finish before I can get back to my testing.


And it did, this error is fixed now :)

But it fails later on, so there's some work still to catch up with the 
current distro, but at least this particular annoyance is resolved, so 
many thanks for figuring it out! I was sure the reason was something 
silly and related to the SSL stack (or maybe ciphers) but was blind to 
see it.



--
t

Bug#970880: [Pkg-freeipa-devel] Bug#970880: Bug#970880: Bug#970880: freeipa-server: FreeIPA server installation fails with Certificate issuance failed (CA_REJECTED)

[Timo Aaltonen]

On 10.10.2021 18.41, Spencer Olson wrote:
Did some more investigation.  I downloaded the packages that are being 
used on centos stream 8.  First I tried my test code with their version 
of libssl3.so preloaded:  it failed in the same way as all the others 
failed--not surprisingly since its version is much later than the 3.39 
version where this changed.


Then, I downloaded and took a look at "dogtag-submit" from the CentOS 
Stream 8 (RedHat) certmonger package.  As far as I can tell, their 
version of "dogtag-submit" is *not* linked against libcurl-nss.so at all 
like the version on debian sid.  Instead, all their certmonger helper 
programs are linked against the OpenSSL version (libcurl.so.4).


So, I think that we should just link these against the openssl version, 
as the RedHat packages do and get things to work again.


Hmm, thanks.. indeed certmonger is still built against libcurl4-nss-dev, 
I've changed it to openssl now and see how it goes against gitlab CI..



This raises two other issues:
- is there truly a bug in the ssl portion of the nss library?  If so, 
this should probably be brought to the attention.
- perhaps the libcurl package ought to be reconfigured such that one can 
install the dev packages simultaneously.  Right now, libcurl-nss also 
makes a symlink "libcurl.so" that makes it conflict with the 
libcurl-openssl package to which the "libcurl.so.x.x" lib belongs to.  I 
think that the libcurl-gnutls package might do the same thing.


My next step will be do rebuild freeipa and certmonger with the 
libcurl-openssl-dev package in place instead of the libcurl-nss-dev and 
then try reinstalling.


No need to rebuild freeipa.


--
t

Bug#992908: awesome: autopkgtest regression between 20 and 23 August 2021: Could not resolve keysym

[Timo Aaltonen]

On 25.8.2021 10.28, Reiner Herrmann wrote:

Hi,

I can reproduce the autopkgtest failure on my system after only
upgrading xkb-data from 2.29-2 to 2.33-1.

I noticed that the xkb-data build has been changed to meson [1], and
it is no longer instructed to install xfree86 symlinks.
And also according to a debdiff, xfree86-related symlinks are now
dropped:


Files in first .deb but not in second
-
lrwxrwxrwx  root/root   /usr/share/X11/xkb/rules/xfree86 -> base
lrwxrwxrwx  root/root   /usr/share/X11/xkb/rules/xfree86.lst -> base.lst
lrwxrwxrwx  root/root   /usr/share/X11/xkb/rules/xfree86.xml -> base.xml


But even with manually restoring the symlinks, the errors still appear
("Could not resolve keysym XF86RightUp" etc).

@Timo, do you have an idea why XF86* keysyms are no longer available
with the new xkb-data?
The actual output on stderr seems to come from xkbcomp.

Kind regards,
   Reiner

[1] 
https://salsa.debian.org/xorg-team/data/xkeyboard-config/-/commit/89b2833a2271d5cac9ede6dfe506ae811db299fe



Hi, could you test after rebuilding current libx11 against the new 
x11-proto-dev in sid? That's supposed to help I'm told.



--
t

Bug#992696: [Pkg-freeipa-devel] Bug#992696: 389-ds: 389-DS no longer starts since bullseye due to libjemalloc.so.2 not found

[Timo Aaltonen]

On 22.8.2021 15.15, Adam Reece wrote:


Aug 22 14:13:38 amun ns-slapd[14030]: [22/Aug/2021:14:13:38.279004946 +0200] - ERR - 
dse_read_one_file - The entry cn=schema in file 
/etc/dirsrv/slapd-amun.service/schema/60samba3.ldif (lineno: 1) is invalid, error code 20 
(Type or value exists) - object class sambaConfig: The name does not match the OID 
"1.3.6.1.4.1.7165.1.2.2.10". Another object class is already using the name or 
OID.
Aug 22 14:13:38 amun ns-slapd[14030]: [22/Aug/2021:14:13:38.280495362 +0200] - 
ERR - setup_internal_backends - Please edit the file to correct the reported 
problems and then restart the server.

That's your error.

The 389 packages didn't change since -2 and things work just fine on 
ci.debian.net and salsa (meaning the daemon starts), so I don't know how 
389 could be to blame here.


the libjemalloc thing is just noise, it's not a hard requirement AIUI.


--
t

Bug#992385: x11-common: use of deprecated tempfile breaks login

[Timo Aaltonen]

On 18.8.2021 7.34, Marc Dequènes (duck) wrote:

Package: x11-common
Version: 1:7.7+22
Severity: grave


Quack,

Since debianutils has dropped the deprecated `tempfile` in 5.0-1 
/etc/X11/Xsession fails around the WRITE_TEST and this breaks graphical 
login completely. Commenting this section allowed me to log in. There is 
another call line 85 that needs to be changed too.


Regards.
\_o<



What if you just do s/tempfile/mktemp?

--
t

Bug#990320: [Pkg-sssd-devel] Bug#990320: sssd - Fails after upgrade from Buster

[Timo Aaltonen]

severity: normal
thanks

On 25.6.2021 19.07, Bastian Blank wrote:

Package: sssd
Version: 2.4.1-2
Severity: serious

After upgrade from Buster, several components of sssd simply fail:

| ● sssd-nss.socket  loaded failed failed
SSSD NSS Service responder socket
|   sssd-pac.socket  loaded active listening 
SSSD PAC Service responder socket
| ● sssd-pam-priv.socket loaded failed failed
SSSD PAM Service responder private socket
| ● sssd-ssh.socket  loaded failed failed
SSSD SSH Service responder socket
| ● sssd-sudo.socket loaded failed failed
SSSD Sudo Service responder socket

So all the sockets are broken and the system is in degraded mode due to
failed units.

Bastian


Check the logs for why that happens.. the above says nothing.


--
t

Bug#986080: [Pkg-freeipa-devel] Bug#986080: pki-base-java: arch-specific link target in arch:all package

[Timo Aaltonen]

On 29.3.2021 14.19, Andreas Beckmann wrote:

Package: pki-base-java
Version: 10.10.2-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

 From the attached log (scroll to the bottom...):

0m57.0s ERROR: FAIL: Broken symlinks:
   /usr/share/pki/lib/p11-kit-trust.so -> 
../../../lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so (pki-base-java)

That link target is part of p11-kit-modules, but even adding a
Depends/Recommends/Suggests would only work on amd64.


Right, needs to move to pki-tools.


--
t

Bug#980369: glslang: autopkgtest regression: undefined reference to `ShConstructUniformMap'

[Timo Aaltonen]

On 18.1.2021 12.44, Simon McVittie wrote:

Source: glslang
Version: 11.1.0-1
Severity: serious
Justification: release team policy
X-Debbugs-Cc: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression
Tags: patch

Thanks for adding an autopkgtest (#940488) and pkg-config metadata
(#940487). However, since version 11.1.0-1, glslang fails the autopkgtest,
for example in
https://ci.debian.net/data/autopkgtest/testing/amd64/g/glslang/9766376/log.gz:

autopkgtest [13:18:41]: test glslang-dev: [---
+ mktemp -d
+ tempdir=/tmp/tmp.UEoTRS3LSr
+ cd /tmp/tmp.UEoTRS3LSr
+ cat
+ c++ -std=c++11 -o trivial trivial.cpp -lglslang -lHLSL -lOGLCompiler 
-lOSDependent -lSPIRV -lpthread
/usr/bin/ld: /tmp/ccZLSVyX.o: in function `main':
trivial.cpp:(.text+0x9): undefined reference to `ShConstructUniformMap'
/usr/bin/ld: trivial.cpp:(.text+0x19): undefined reference to `ShDestruct'
collect2: error: ld returned 1 exit status
autopkgtest [13:18:42]: test glslang-dev: ---]

This indicates that the compile-time interface has changed: it is now
necessary for client code to link to -lMachineIndependent and
-lGenericCodeGen in addition to the libraries that were previously
required. This will presumably mean that some packages dependent on
glslang will now FTBFS.

Linking with the new glslang.pc seems to have the same bug: glslang.pc
needs updating for the new compile-time interface.

I attach an attempt to fix this, together with improvements to the
autopkgtest.

(I should warn you that I don't really know how this library works,
so I'm guessing at what the intended compile-time interface is; please
review accordingly.)

 smcv



Thanks, they look fine to me and will be in -2 which will be uploaded soon.


--
t

Bug#976624: python3-xcbgen: not compatible with python 3.9

[Timo Aaltonen]

On 6.12.2020 3.49, Samuel Henrique wrote:

Package: xcb-proto
Severity: serious
Tags: patch upstream

Hello Maintainer,

Python 3.9 deprecated fractions.gcd in favor of math.gcd, this causes a 
FTBFS in polybar #975795[0]. I believe this issue can cause FTBFS in 
other packages and thus I picked the serious severity (same one applied 
to the polybar bug report caused by this).


I have tried to find the correct place to send patches upstream and gave 
up along the way when I couldn't find the project on freedesktop's 
gitlab instance[1] and the homepage pointed to an empty bugzilla (which 
I assume is not used anymore).


I proposed a solution on salsa[2], which I'm also attaching to this email.

I'm also willing to NMU the fix in case the maintainers don't have 
available time.


Thanks,

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


[1] https://gitlab.freedesktop.org 
[2] 
https://salsa.debian.org/xorg-team/proto/xcb-proto/-/merge_requests/2 



--
Samuel Henrique 


Hi, upstream is at https://gitlab.freedesktop.org/xorg/proto/xcbproto

and this issue is fixed in the latest release, so I'll just release that.


--
t

Bug#971178: closing 971178

[Timo Aaltonen]

close 971178 
thanks

Bug#974702: closing 974702

[Timo Aaltonen]

close 974702 
thanks

fixed by 20.44.18297-1

Bug#974702: intel-opencl-icd causes all OpenCL programs to abort

[Timo Aaltonen]

On Sat, 14 Nov 2020 01:05:56 +0100 Giuseppe Bilotta 
 wrote:

Package: intel-opencl-icd
Version: 20.37.17906-1
Severity: critical

When this package is installed, any OpenCL program will abort with the
message


Hi, please try with the current version, I think this was due to the old 
driver being built with llvm10. 20.44 was uploaded yesterday.



And 972620 should be fixed as well.


--
t

Bug#968076: closing 968076

[Timo Aaltonen]

close 968076 11.4-1
thanks

Bug#963049: [Pkg-freeipa-devel] Bug#963049: pki-base: syntax error in /usr/share/pki/scripts/config

[Timo Aaltonen]

severity normal
thanks

On 18.6.2020 13.31, Laurent Bonnaud wrote:
> 
> Package: pki-base
> Version: 10.9.0~a2-2
> Severity: serious
> 
> 
> Dear Maintainer,
> 
> here is the problem:
> 
> # source /usr/share/pki/scripts/config
> -bash: break: only meaningful in a `for', `while', or `until' loop

This isn't a fatal error. This is caused by forcing the scripts to use
bash, and without that pki-tomcatd wouldn't even start. You may check
where the actual bashism is and fix that, then we'd be able to drop
forcing bash.

-- 
t

Bug#954311: Not just rendering issues...

[Timo Aaltonen]

On 8.4.2020 17.15, Pascal Giard wrote:
> On Mon, Apr 6, 2020 at 12:05 PM Timo Aaltonen  <mailto:tjaal...@debian.org>> wrote:
> 
> On 6.4.2020 1.55, Pascal Giard wrote:
> > Thanks A LOT for the /etc/drirc trick, it fixed the problem
> > detailed below for me.
> > Took me over an hour to figure out what was wrong and to end up on
> this
> > bug report.
> >
> > I have a Thinkpad T480 (Intel UHD 620).
> >
> > The new iris driver causes all my video players to crash (e.g., VLC or
> > mpv) and prevents Zoom from converting my recorded sessions.
> Do you use xserver-xorg-video-intel? If yes, get rid of it.
> 
> 
> I do use it, yes. Which driver am I suppose to use instead?

The default, which is modesetting_drv.so from the xserver.


-- 
t

Bug#954311: Not just rendering issues...

[Timo Aaltonen]

On 6.4.2020 1.55, Pascal Giard wrote:
> Thanks A LOT for the /etc/drirc trick, it fixed the problem
> detailed below for me.
> Took me over an hour to figure out what was wrong and to end up on this
> bug report.
> 
> I have a Thinkpad T480 (Intel UHD 620).
> 
> The new iris driver causes all my video players to crash (e.g., VLC or
> mpv) and prevents Zoom from converting my recorded sessions.
Do you use xserver-xorg-video-intel? If yes, get rid of it.


-- 
t

Bug#954729: src:mesa: X won't start after upgrading mesa

[Timo Aaltonen]

On 23.3.2020 18.25, Chow Loong Jin wrote:
> On Mon, Mar 23, 2020 at 01:21:23PM +0200, Timo Aaltonen wrote:
>> On 22.3.2020 20.02, Timo Aaltonen wrote:
>>> On 22.3.2020 17.38, Chow Loong Jin wrote:
>>>> Package: src:mesa
>>>> Version: 20.0.2-1
>>>> Severity: critical
>>>> Justification: breaks the whole system
>>>>
>>>> Dear Maintainer,
>>>>
>>>>> * What led up to the situation?
>>>>
>>>> Upgraded mesa packages from 19.3.3-1 to 20.0.2-1.
>>>>
>>>>> * What exactly did you do (or not do) that was effective (or
>>>>>   ineffective)?
>>>>
>>>> Tried to boot
>>>>
>>>>> * What was the outcome of this action?
>>>>
>>>> X wouldn't start (log attached)
>>>>
>>>>> * What outcome did you expect instead?
>>>>
>>>> X starts.
>>>>
>>>
>>> Your kernel (4.9) is probably too old for the new iris dri driver.
>>
>> Requires at least 4.16 (while sid has 5.4):
> 
> Thanks. We tried upgrading the kernel to 5.4.0-4, but X didn't start,
> and before we could log into a TTY, it spat a bunch of nouveau-related
> kernel messages and started shutting down on its own.
> 
> Attached is a kern.log that includes a 5.4.0-4-amd64 boot and a
> subsequent successful 4.9.0-7-amd64 boot.
> 

I guess you need to blacklist nouveau for now. File a separate bug on
the kernel for that.


-- 
t



signature.asc
Description: OpenPGP digital signature

Bug#954729: src:mesa: X won't start after upgrading mesa

[Timo Aaltonen]

On 22.3.2020 20.02, Timo Aaltonen wrote:
> On 22.3.2020 17.38, Chow Loong Jin wrote:
>> Package: src:mesa
>> Version: 20.0.2-1
>> Severity: critical
>> Justification: breaks the whole system
>>
>> Dear Maintainer,
>>
>>> * What led up to the situation?
>>
>> Upgraded mesa packages from 19.3.3-1 to 20.0.2-1.
>>
>>> * What exactly did you do (or not do) that was effective (or
>>>   ineffective)?
>>
>> Tried to boot
>>
>>> * What was the outcome of this action?
>>
>> X wouldn't start (log attached)
>>
>>> * What outcome did you expect instead?
>>
>> X starts.
>>
> 
> Your kernel (4.9) is probably too old for the new iris dri driver.

Requires at least 4.16 (while sid has 5.4):

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/283

so you should either upgrade the kernel or force i915 in drirc.



-- 
t

Bug#954729: src:mesa: X won't start after upgrading mesa

[Timo Aaltonen]

On 22.3.2020 17.38, Chow Loong Jin wrote:
> Package: src:mesa
> Version: 20.0.2-1
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
>> * What led up to the situation?
> 
> Upgraded mesa packages from 19.3.3-1 to 20.0.2-1.
> 
>> * What exactly did you do (or not do) that was effective (or
>>   ineffective)?
> 
> Tried to boot
> 
>> * What was the outcome of this action?
> 
> X wouldn't start (log attached)
> 
>> * What outcome did you expect instead?
> 
> X starts.
> 

Your kernel (4.9) is probably too old for the new iris dri driver.

-- 
t

Bug#954311: libgl1-mesa-dri: Makes KDE konsole unusable

[Timo Aaltonen]

On 20.3.2020 10.18, Stefan Fritsch wrote:
> Package: libgl1-mesa-dri
> Version: 20.0.2-1
> Followup-For: Bug #954311
> 
> 
> With this mesa version, there are severe drawing artifacts with the kde
> konsole terminal emulator that makes it unusable. I also see problems
> when marking text in thunderbird.
> 
> Downgrading the following packages to 19.3.3-1 fixes the problem:
> 
>  libegl-mesa0
>  libglapi-mesa
>  libgbm1
>  libgl1-mesa-dri
>  libosmesa6
>  libgbm-dev
>  libglx-mesa0
> 
> Cheers,
> Stefan

Please file it upstream, this is caused by the new 'iris' driver. In the
meantime, you can force the previous driver with this in a ~/.drirc:


  

  



Or run the app with the driver to verify it actually helps:

dri_driver=i965 ./app




-- 
t

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Timo Aaltonen]

On 28.2.2020 18.50, Domenico Cufalo wrote:
> This is my output:
> 
> $ gsettings get org.gnome.desktop.input-sources sources
> [('xkb', 'it'), ('xkb', 'gr'), ('xkb', 'de')]
> 
> Obviously the command "setxkbmap it" solves the problem, at least for
> the current session.
> 
> In Italian keyboard, for example, round brackets are above the numbers 8
> and 9, instead of 9 and 0.
> 
> The issue arose after updating the following packages:
> 
> Start-Date: 2020-02-28  00:30:26
> Commandline: apt upgrade
> Requested-By: domenico (1000)
> Upgrade: libqt5test5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> qt5-gtk-platformtheme:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5dbus5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5sql5-sqlite:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5widgets5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), xkb-data:amd64
> (2.26-2, 2.29-1), libqt5xml5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5printsupport5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9),
> libqt5concurrent5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5gui5:amd64
> (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5core5a:amd64 (5.12.5+dfsg-8,
> 5.12.5+dfsg-9), libxml2:amd64 (2.9.10+dfsg-3, 2.9.10+dfsg-4),
> libqt5network5:amd64 (5.12.5+dfsg-8, 5.12.5+dfsg-9), libqt5sql5:amd64
> (5.12.5+dfsg-8, 5.12.5+dfsg-9)
> End-Date: 2020-02-28  00:30:33
> 
> In the meantime, I think I will downgrade the package...
> 
> Regards,
> Domenico
> 

I'm pretty sure the reason for the failure is that our xkbcomp is too
old, the newer versions ignore errors caused by having keycodes above
255.. and launching Xwayland in weston clearly shows a bunch of errors
from xkbcomp. Our version (1.4.0) is almost 2y old and this was fixed
upstream in 1.4.1 in June 2018.

So I'll update x11-xkb-utils, thanks for the patience..


-- 
t

Bug#952731: xkb-data: Italian keyboard layout not working in some apps

[Timo Aaltonen]

On 28.2.2020 10.35, Domenico Cufalo wrote:
> Package: xkb-data
> Version: 2.29-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Latest version of xkb-data (2.29.1) renders Italian keyboard unusable in some
> apps.
> 
> In short, in applications like Firefox or Chrome, even if I use an Italian
> keyboard, the English layout is activated.
> 
> In gedit, gnome-terminal, Libreoffice, reportbug itself and maybe other apps,
> Italian keyboard works fine.
> 
> Thank you very much in advance,
> Domenico

Sorry to hear that, but I wonder if this is actually triggered by
something else.. at least I'm not able to reproduce it with .fi layout
on ubuntu focal..



-- 
t

Bug#952589: libx11-dev: trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also in package x11proto-dev 2018.4-4

[Timo Aaltonen]

On 26.2.2020 19.57, Daniel Serpell wrote:
> Hi!
> 
> On Wed, Feb 26, 2020 at 1:27 PM Simon McVittie  wrote:
>>
>> On Wed, 26 Feb 2020 at 17:47:07 +0200, Timo Aaltonen wrote:
> 
>>> bah, I'll release a new xorgproto asap
>>
>> You'll probably need to give x11proto-dev a versioned Breaks on the older
>> libx11-dev versions that expected x11proto-dev to provide that header.
>>
> 
> Also, the headers moved from x11proto to other library packages, see
> https://gitlab.freedesktop.org/xorg/lib/libxvmc/-/commit/0fab90b409a3e4848603bdb6b438523038239f23
> for the corresponding move of vldXvMC.h to libxvmc-dev.

yes, libxvmc 1.0.12-1 fixed that


-- 
t

Bug#952589: libx11-dev: trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also in package x11proto-dev 2018.4-4

[Timo Aaltonen]

On 26.2.2020 16.17, Dmitry Shachnev wrote:
> Package: libx11-dev
> Version: 2:1.6.9-1
> Severity: serious
> Justification: fails to install
> 
> Dear Maintainer,
> 
> When trying to install the latest version of libx11-dev, I get the following
> error:
> 
>   Unpacking libx11-dev:amd64 (2:1.6.9-1) ...
>   dpkg: error processing archive .../097-libx11-dev_2%3a1.6.9-1_amd64.deb 
> (--unpack):
>trying to overwrite '/usr/include/X11/extensions/XKBgeom.h', which is also 
> in package x11proto-dev 2018.4-4
> 
> --
> Dmitry Shachnev
> 

bah, I'll release a new xorgproto asap

-- 
t

Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup

[Timo Aaltonen]

On 23.1.2020 23.08, Paul Gevers wrote:
> Hi Timo,
> 
> On 23-01-2020 22:01, Timo Aaltonen wrote:
>> Look at the error above, the file shipped by qtbase5-dev requires
>> libEGL.so which the libegl-dev dependency provides. It used to be in
>> libglvnd-dev but moved to a new package when the EGL headers were added
>> upstream.
> 
> So, libglvnd-dev should add a versioned breaks on the old qtbase5-dev,
> right?

Uh no...

The old qtbase5-dev (5.12.5+dfsg-2, in testing) depends on
libgl1-mesa-dev. libgl1-mesa-dev (in testing) used to pull in
libglvnd-dev which had libEGL.so. New libgl1-mesa-dev depends only on
libgl-dev, so you don't get the libEGL.so symlink anymore. I guess
libgl1-mesa-dev should depend on libegl-dev too, for now.

Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup

[Timo Aaltonen]

On 23.1.2020 22.07, Paul Gevers wrote:
> Hi Timo,
> 
> On 23-01-2020 19:32, Timo Aaltonen wrote:
>> The relevant part of the build log was:
>>
>> CMake Error at
>> /usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:27 (message):
>>   The imported target "Qt5::Gui" references the file
>>
>>  "/usr/lib/x86_64-linux-gnu/libEGL.so"
>>
>>   but this file does not exist.
>>
>>
>> So you need at least qtbase5-dev version 5.12.5+dfsg-3 which added
>> libegl-dev to it's Depends.
> 
> Which package (source or binary) do you refer here with "you"? As I
> noted before, the interesting thing is that the autopkgtest passes both
> in a pure testing environment and a pure unstable environment, but not
> in testing with the following packages from unstable:
> unstable/main amd64 libglvnd0 amd64 1.3.0-7 [51.5 kB]
> unstable/main amd64 libglapi-mesa amd64 19.3.2-1 [69.9 kB]
> unstable/main amd64 libgl1-mesa-dri amd64 19.3.2-1 [9,187 kB]
> unstable/main amd64 libglx-mesa0 amd64 19.3.2-1 [182 kB]
> unstable/main amd64 libglx0 amd64 1.3.0-7 [34.6 kB]
> unstable/main amd64 libgl1 amd64 1.3.0-7 [88.8 kB]
> unstable/main amd64 libglx-dev amd64 1.3.0-7 [16.2 kB]
> unstable/main amd64 libgl-dev amd64 1.3.0-7 [100 kB]
> unstable/main amd64 libgl1-mesa-dev amd64 19.3.2-1 [49.1 kB]
> unstable/main amd64 libgbm1 amd64 19.3.2-1 [70.5 kB]
> unstable/main amd64 libegl-mesa0 amd64 19.3.2-1 [139 kB]
> unstable/main amd64 libegl1 amd64 1.3.0-7 [34.1 kB]
> 
> A successful run in testing doesn't pull in libegl-dev either, so it
> seems that the file is not a hard requirement.

Look at the error above, the file shipped by qtbase5-dev requires
libEGL.so which the libegl-dev dependency provides. It used to be in
libglvnd-dev but moved to a new package when the EGL headers were added
upstream.


-- 
t

Bug#949677: mesa breaks build of kcrash, konsole and libkscreen as tested in autopkgtest migration setup

[Timo Aaltonen]

On 23.1.2020 17.01, Paul Gevers wrote:
> Source: mesa, kcrash, konsole, libkscreen
> Control: found -1 mesa/19.3.2-1
> Control: found -1 kcrash/5.62.0-1
> Control: found -1 konsole/4:19.08.1-2
> Control: found -1 libkscreen/4:5.14.5-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainers,
> 
> With a recent upload of mesa the autopkgtest of kcrash, konsole and
> libkscreen fails in testing during building of the source package when
> that autopkgtest is run with the binary packages of mesa from unstable.
> It passes when run with only packages from testing. In tabular form (for
> kcrash):
>passfail
> mesa   from testing19.3.2-1
> kcrash from testing5.62.0-1
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing

The relevant part of the build log was:

CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/Qt5Gui/Qt5GuiConfig.cmake:27 (message):
  The imported target "Qt5::Gui" references the file

 "/usr/lib/x86_64-linux-gnu/libEGL.so"

  but this file does not exist.


So you need at least qtbase5-dev version 5.12.5+dfsg-3 which added
libegl-dev to it's Depends.




-- 
t

Bug#941750: [Pkg-sssd-devel] Bug#941750: sssd: ftbfs with libldb2 (fails during configure)

[Timo Aaltonen]

On 4.10.2019 21.32, Paul Gevers wrote:

Source: sssd
Version: 2.2.2-1
Severity: serious
Tags: ftbfs
Justification: ftbfs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear maintainers,

Your package is part of the ldb transition which is currently ongoing. However,
your package fails to build from source on all architectures.

Paul

Tail of log for sssd on amd64:

#define HAVE_SYSTEMD_LOGIN 1
#define HAVE_SYSTEMD_DAEMON 1
#define HAVE_PAC_RESPONDER 1
#define HAVE_CIFS_IDMAP_PLUGIN 1
#define HAVE_SIGPROCMASK 1
#define HAVE_SIGBLOCK 1
#define HAVE_SIGACTION 1
#define HAVE_GETPGRP 1
#define HAVE_PRCTL 1

configure: exit 1
dh_auto_configure: cd build && ../configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --enable-krb5-locator-plugin 
--datadir=/usr/share/ --with-environment-file=/etc/default/sssd 
--with-ldb-lib-dir=/usr/lib/x86_64-linux-gnu/ldb/modules/ldb 
--with-krb5-plugin-path=/usr/lib/x86_64-linux-gnu/krb5/plugins/libkrb5 
--enable-nsslibdir=/lib/x86_64-linux-gnu 
--enable-pammoddir=/lib/x86_64-linux-gnu/security --enable-systemtap --disable-static 
--disable-rpath --with-autofs --with-ssh --with-initscript=systemd 
--with-systemdunitdir=/lib/systemd/system --disable-files-domain 
--with-smb-idmap-interface-version=6 --without-python2-bindings --with-sudo returned 
exit code 1
make[1]: *** [debian/rules:26: override_dh_auto_configure] Error 255
make[1]: Leaving directory '/<>'
make: *** [debian/rules:3: build-arch] Error 2


ldb2 is not the reason why it fails, but samba-dev has changed somehow:

configure:18175: checking for NDR_NBT
configure:18183: $PKG_CONFIG --exists --print-errors "ndr_nbt"
Package samba-util was not found in the pkg-config search path.
Perhaps you should add the directory containing `samba-util.pc'
to the PKG_CONFIG_PATH environment variable
Package 'samba-util', required by 'ndr', not found
configure:18186: $? = 1
configure:18201: $PKG_CONFIG --exists --print-errors "ndr_nbt"
Package samba-util was not found in the pkg-config search path.
Perhaps you should add the directory containing `samba-util.pc'
to the PKG_CONFIG_PATH environment variable
Package 'samba-util', required by 'ndr', not found
configure:18204: $? = 1
Package 'samba-util', required by 'ndr', not found
configure:18232: result: no
configure:18234: error: Please install Samba 4 NDR NBT development 
libraries.

Samba 4 libraries are necessary for building ad and ipa provider.
If you do not want to build these providers it is possible to build SSSD
without them. In this case, you will need to execute configure script
with argument --without-samba



--
t

Bug#940560: libvulkan1: depends (ambiguously) on non-free package

[Timo Aaltonen]

On 17.9.2019 14.56, Timo Aaltonen wrote:
>> libvulkan1 recommends (directly, i.e. not as fallback alternative)
>> virtual package vulkan-icd, provided by several non-free packages.
>>
>> This is covered by Debian Policy §2.2.1:
>>
>>> "[a] package [in main] must not declare a [...] "Recommends" [...]
>>> relationship on a non-main package unless that package is only listed
>>> as a non-default alternative for a package in main.
>>
>> Related is also §7.5:
>>
>>> To specify which of a set of real packages should be the default to
>>> satisfy a particular dependency on a virtual package, list the real
>>> package as an alternative before the virtual one.
>>
>>
>> Please either declare a package in main as primary alternative, or lower
>> to only suggest vulkan-icd.
>>
>>  - Jonas
> 
> Hmm, right.. maybe I'll add mesa-vulkan-drivers to recommends and lower
> vulkan-icd to suggests, that should cover all use-cases?

Oh, actually I'll make it 'Recommends: mesa-vulkan-drivers | vulkan-icd'...


-- 
t

Bug#940560: libvulkan1: depends (ambiguously) on non-free package

[Timo Aaltonen]

> libvulkan1 recommends (directly, i.e. not as fallback alternative)
> virtual package vulkan-icd, provided by several non-free packages.
> 
> This is covered by Debian Policy §2.2.1:
> 
>> "[a] package [in main] must not declare a [...] "Recommends" [...]
>> relationship on a non-main package unless that package is only listed
>> as a non-default alternative for a package in main.
> 
> Related is also §7.5:
> 
>> To specify which of a set of real packages should be the default to
>> satisfy a particular dependency on a virtual package, list the real
>> package as an alternative before the virtual one.
> 
> 
> Please either declare a package in main as primary alternative, or lower
> to only suggest vulkan-icd.
> 
>  - Jonas

Hmm, right.. maybe I'll add mesa-vulkan-drivers to recommends and lower
vulkan-icd to suggests, that should cover all use-cases?


-- 
t

Bug#921926: pki-base: Does not work with Java 11

[Timo Aaltonen]

Package: pki-base
Severity: grave
Tags: upstream
Justification: renders package unusable

Upstream needs to port Dogtag to TLS1.3 & Java11 before pkispawn is able to 
configure the instance. Upstream ticket at:

https://pagure.io/dogtagpki/issue/3088

It's unlikely that this will be fixed before Fedora has switched to Java11, 
which might happen in Fedora 31 but not before.

Bug#920725: [Pkg-freeipa-devel] Bug#920725: pki-base-java: Depends on openjdk-8-jre-headless which will not be in buster

[Timo Aaltonen]

On 28.1.2019 17.19, Andreas Beckmann wrote:
> Package: pki-base-java
> Version: 10.6.8-2
> Severity: serious
> Control: block 920037 with -1
> 
> Hi,
> 
> buster will ship with openjdk-11 only.

This was already changed in git, but turns out it doesn't actually work
with java11 so best to leave dogtag-pki out of buster then.


-- 
t

Bug#870032: [Pkg-fedora-ds-maintainers] Bug#870032: closed by Timo Aaltonen (Bug#870032: fixed in 389-admin 1.1.46-1)

[Timo Aaltonen]

On 17.3.2018 19.47, Adrian Bunk wrote:
> On Wed, Oct 04, 2017 at 06:21:05PM +, Debian Bug Tracking System wrote:
>> ...
>>  389-admin (1.1.46-1) unstable; urgency=medium
>> ...
>>* rules, postinst: Don't fail the install when the unconfigured
>>  service doesn't start. (Closes: 870032) (LP: #1652476)
>> ...
> 
> Thanks a lot for fixing this bug for unstable.
> 
> It is still present in stretch, could you also fix it there?
> Alternatively, I can fix it for stretch if you don't object.
> 
> It might also be a good idea to include:
> 
>>* Fix systemd service to stop properly.
>> ...

Hi, it's been a while, but I have this prepared now. Are you part of the
stable team or should I ask for the ack elsewhere?


-- 
t



signature.asc
Description: OpenPGP digital signature

Bug#916115: [Pkg-freeipa-devel] Bug#916115: 389-ds-base: Please use pkg-config to detect icu

[Timo Aaltonen]

On 30.12.2018 10.23, Hugh McMaster wrote:
> Control: severity -1 serious
> Control: tags -1 + upstream
> 
> Dear maintainer,
> 
> As the removal of icu-config from Debian is imminent, I have prepared a 
> patch that allows389-ds-base to detect icu by using pkg-config.
> 
> I have sent the patch upstream, but they have not yet responded.
> 
> https://pagure.io/fork/hmc/389-ds-base/c/2c7eccb57b889294f5ff402a5dcc6333ac3379cc.patch

Hi, could you send a merge request on salsa?


-- 
t

Bug#879469: Should not enter testing

[Timo Aaltonen]

On 22.10.2017 1.13, Timo Aaltonen wrote:
> Package: resteasy3.0
> Severity: serious
> 
> Resteasy 3.0 was reintroduced to sid in order to allow porting new
> versions of Dogtag and Freeipa. It should not enter testing though.
> Hopefully upstream will finish porting Dogtag to 3.1 or newer before too
> long.

Upstream/Redhat has no immediate plans to move to a newer branch of
Resteasy (they still have 3.0.19), so I think the best plan for buster
is to ship with src:resteasy3.0 and instead keep src:resteasy out of the
release. Nothing depends on it anyway.

FTR, Dogtag does build with Resteasy 3.6.2, but there probably would be
runtime issues, also adding Jackson2 provider (which Dogtag 10.6.8
needs) would require packaging a bunch of new packages.

-- 
t

Bug#912395: Bug #912395 in resteasy marked as pending

[Timo Aaltonen]

Control: tag -1 pending

Hello,

Bug #912395 in resteasy 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/java-team/resteasy/commit/7b849ed7f12a63a3e77dcbb4a735505fc069c4cd


control, jaxb-api-compatibility.diff: Fix build, add libjaxb-api-java to 
build-depends. (Closes: #912395)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/912395

Bug#891450: custodia FTBFS: TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

[Timo Aaltonen]

On 21.4.2018 23.27, Ben Finney wrote:
> On 25-Feb-2018, Adrian Bunk wrote:
>> Source: custodia
> 
> I Think this is the correct assignment for this bug report.
> 
> See the command-line used to invoke the coverage module:
> 
>> ERROR: InvocationError: '/build/1st/custodia-0.5.0/.tox/py36/bin/python -m 
>> coverage run --parallel -m pytest --capture=no --strict --skip-servertests'
> 
> Note that the command line calls ‘[…]python -m coverage run’ but
> specifies no tests to run. That's why the ‘coverage’ module eventually
> complains that the path that was specified is None.
> 
> Somehow, the ‘custodia’ test suite is invoking ‘coverage’ in such a
> way that no path is specified.

Well, it seems to build fine on my sbuild these days, so whatever caused
the error doesn't seem to be true anymore.


-- 
t



signature.asc
Description: OpenPGP digital signature

Bug#914167: fatal error: KHR/khrplatform.h: No such file or directory

[Timo Aaltonen]

On 20.11.2018 9.04, Mathieu Malaterre wrote:
> Package: mesa-common-dev
> Version: 18.2.5-1
> Severity: serious
> Tags: ftbfs
> 
> OpenVDB fails to build from source because of:
> 
> In file included from /usr/include/GL/gl.h:2055,
>  from viewer/Font.h:40,
>  from viewer/Font.cc:31:
> /usr/include/GL/glext.h:467:10: fatal error: KHR/khrplatform.h: No
> such file or directory
>  #include 
>   ^~~
> compilation terminated.
> 
> ref:
> https://buildd.debian.org/status/fetch.php?pkg=openvdb=amd64=5.2.0-5=154226=0
> 
> It would be nice to fix this, upstream seems to have provided a patch:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=107511

That commit is in 18.2.5:

commit 2645ea5817f4fd05905b8deda96c268cd69fa48c
Author: Eric Engestrom 
Date:   Tue Aug 7 12:56:25 2018 +0100

configure: install KHR/khrplatform.h when needed

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107511
Fixes: f7d42ee7d319256608ad "include: update GL & GLES headers (v2)"
Signed-off-by: Eric Engestrom 
Tested-by: Brad King 
Reviewed-by: Emil Velikov 
(cherry picked from commit 87c156183cd668f1341326cc7c88ab6686f27d8f)

so something else is wrong.


-- 
t

Bug#913820: [Pkg-freeipa-devel] Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin

[Timo Aaltonen]

On 15.11.2018 18.22, Jan Luca Naumann wrote:
> Package: cockpit-389-ds
> Version: 1.4.0.18-1
> Severity: grave
> Justification: renders package unusable
> 
> At the momenent the package cockpit-389-ds applies a patch to use the Debian
> packaged JS libraries. In contrast to the vendored libraries the Debian 
> versions
> do not work with the current version of the cockpit-389-plugin, c.f. the
> backtrace attached. Removing the Debian-specific patch and installing the
> vendored JS libs resolves the issue.

yeah, and all the minified stuff is already in debian/missing-sources,
so it should be fine to just drop the patch.. Thanks for the bug!


-- 
t

Bug#910698: dogtag-pki needs jdk8

[Timo Aaltonen]

On 17.10.2018 09:52, Emmanuel Bourg wrote:
> Le 17/10/2018 à 07:11, Timo Aaltonen a écrit :
> 
>> ldapjdk is built against jdk8 because jss/dogtag-pki still need it that
>> way or things will break. Though now I realized maybe it might still
>> work with -Dant.build.javac.target=1.8 (or whatever jdk8 uses).
> 
> What errors do you get if you use the Java 11 compiled ldapjdk with
> jss/dogtag-pki?

I can't remember offhand, some compatibility errors with versions.


-- 
t

Bug#910698: dogtag-pki needs jdk8

[Timo Aaltonen]

(the bug didn't get to pkg-freeipa-devel..)

Hi

ldapjdk is built against jdk8 because jss/dogtag-pki still need it that
way or things will break. Though now I realized maybe it might still
work with -Dant.build.javac.target=1.8 (or whatever jdk8 uses).

-- 
t

Bug#905184: [Pkg-freeipa-devel] Bug#905184: Bug#905184: Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc

[Timo Aaltonen]

On 09.10.2018 21:03, Timo Aaltonen wrote:
> On 03.09.2018 11:16, Jan Kowalsky wrote:
>>
>> solves the issue:
>>
>> --- updates.orig/60upgradeconfigfiles.pl 2018-09-03 09:58:45.911804203 
>> +0200
>> +++ updates/60upgradeconfigfiles.pl  2018-09-03 09:59:36.420699451 +0200
>> @@ -31,7 +31,7 @@
>>  next if (! -f $oldname); # does not exist - skip - already
>> (re)moved
>>  my $newname = "$bakdir/$file";
>>  $! = 0; # clear
>> -rename $oldname, $newname;
>> +move $oldname, $newname;
>>  if ($!) {
>>  push @errs, ["error_renaming_config", $oldname, $newname, $!];
>>  }
>> @@ -57,7 +57,7 @@
>>  next if (! -f $oldname); # does not exist - not backed up
>>  my $newname = $inf->{slapd}->{config_dir} . "/" . $file;
>>  next if (-f $newname); # not removed
>> -rename $oldname, $newname;
>> +move $oldname, $newname;
>>  }
>>  return @errs;
>>  }
> 
> Unfortunately the upgrade only works once with this.. try running
> 'setup-ds -u -s General.UpdateMode=offline' after shutting down the
> daemon, every second attempt works and the other fails.
> 
> so I'm forced to revert the change unless it can be fixed to work each
> time..

nevermind, using 'copy' instead works fine..


-- 
t

Bug#905184: [Pkg-freeipa-devel] Bug#905184: Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc

[Timo Aaltonen]

On 03.09.2018 11:16, Jan Kowalsky wrote:
> 
> solves the issue:
> 
> --- updates.orig/60upgradeconfigfiles.pl  2018-09-03 09:58:45.911804203 
> +0200
> +++ updates/60upgradeconfigfiles.pl   2018-09-03 09:59:36.420699451 +0200
> @@ -31,7 +31,7 @@
>  next if (! -f $oldname); # does not exist - skip - already
> (re)moved
>  my $newname = "$bakdir/$file";
>  $! = 0; # clear
> -rename $oldname, $newname;
> +move $oldname, $newname;
>  if ($!) {
>  push @errs, ["error_renaming_config", $oldname, $newname, $!];
>  }
> @@ -57,7 +57,7 @@
>  next if (! -f $oldname); # does not exist - not backed up
>  my $newname = $inf->{slapd}->{config_dir} . "/" . $file;
>  next if (-f $newname); # not removed
> -rename $oldname, $newname;
> +move $oldname, $newname;
>  }
>  return @errs;
>  }

Unfortunately the upgrade only works once with this.. try running
'setup-ds -u -s General.UpdateMode=offline' after shutting down the
daemon, every second attempt works and the other fails.

so I'm forced to revert the change unless it can be fixed to work each
time..

-- 
t

Bug#895643: [Pkg-freeipa-devel] Bug#895643: Patch for building using default-jdk (openjdk10)

[Timo Aaltonen]

On 12.09.2018 11:56, Hilko Bengen wrote:
> * Timo Aaltonen:
> 
>>> Unfortunately, I do not know how to test whether the resulting package
>>> still works.
>>
>> This is not for jss though?
> 
> Argh, yes, sorry, here's the right patch.
> 
> Cheers,
> -Hilko
> 

I don't think it's enough to actually make it work. Upstream has been
working on it:

https://pagure.io/jss/issue/15

besides, I think it would break dogtag which expects to see a compatible
version of jss, and dogtag would need to be fixed as well and upstream
is slow.


-- 
t

Bug#895643: [Pkg-freeipa-devel] Bug#895643: Patch for building using default-jdk (openjdk10)

[Timo Aaltonen]

On 12.09.2018 00:27, Hilko Bengen wrote:
> control: tag -1 patch
> 
> Dear maintainer(s),
> 
> here's a patch that fixes the FTBFS issues with openjdk-10 and removes
> the openjdk-8 dependency.
> 
> Unfortunately, I do not know how to test whether the resulting package
> still works.

This is not for jss though?


-- 
t

Bug#905184: [Pkg-freeipa-devel] Bug#905184: upgrade of 389-ds-base fails if /var/lib/dirsrv is on different partition as /etc

[Timo Aaltonen]

On 01.08.2018 13:30, Jan Kowalsky wrote:
> Package: 389-ds-base
> Version: 1.3.5.17-2
> Severity: serious
> 
> Upgrade to newer version of 389-ds-base fails with dpkg configuration
> error on postinstall script /var/lib/dpkg/info/389-ds-base.postinst
> 
> After getting full log of postinstall I saw:
> 
> [18/08/01:10:33:37] - [Setup] Info Could not rename config file
> '/etc/dirsrv/slapd-INSTANCE/slapd-collations.conf' to
> '/var/lib/dirsrv/slapd-INSTANCE/bak.bak/slapd-collations.conf'.  Error:
> Invalid cross-device link
> 
> This is caused by line 24:
> 
> setup-ds -l $OUT -u -s General.UpdateMode=offline > $OUT 2>&1
> 
> calling this directly we got the same failure.
> 
> The reason is that the script tries to make a backup of configuration
> files in /var/lib/dirsrv/INSTANCE/bak.bak:
> 
> 
> # these files are obsolete, or we want to replace
> # them with newer versions
> my @toremove = qw(slapd-collations.conf);
> 
> # make a backup directory to store the deleted config file, then
> # don't really delete it, just move it to that directory
> my $mode = (stat($inf->{slapd}->{config_dir}))[2];
> my $bakdir = $inf->{slapd}->{bak_dir} . ".bak";
> if (! -d $bakdir) {
> $! = 0; # clear
> mkdir $bakdir, $mode;
> if ($!) {
> return ('error_creating_directory', $bakdir, $!);
> }
> }
> 
> my @errs;
> for my $file (@toremove) {
> my $oldname = $inf->{slapd}->{config_dir} . "/" . $file;
> next if (! -f $oldname); # does not exist - skip - already (re)moved
> my $newname = "$bakdir/$file";
> $! = 0; # clear
> rename $oldname, $newname;
> if ($!) {
> push @errs, ["error_renaming_config", $oldname, $newname, $!];
> }
> }
> 
> 
> According to
> https://www.unix.com/shell-programming-and-scripting/27747-perl-rename-failed.html
> the perl rename call can cause this error.
> 
> My workaround was to create the directories in /etc and make symlinks in
> /var/lib/dirsrv/...
> 
>   mkdir /etc/dirsrv/slapd-INSTANCE/bak
>   ln -s /etc/dirsrv/slapd-INSTANCE/bak /var/lib/dirsrv/slapd-INSTANCE/bak
>   mkdir /etc/dirsrv/slapd-INSTANCE/bak.bak
>   ln -s /etc/dirsrv/slapd-INSTANCE/bak.bak
> /var/lib/dirsrv/slapd-INSTANCE/bak.bak
> 
> 
> Upgrade succeeded now.
> 
> I originally encountered this problem while upgrading 389-ds-base on
> jessie from 1.3.3.5-4 to 1.3.3.5-4+deb8u1. Since upgrade scripts didn't
> change this should be still valid for the actual version.

What if you change 'rename' with 'move' in /usr/share/dirsrv/updates/*.pl?



-- 
t

Bug#905220: [Pkg-sssd-devel] Bug#905220: Bug#905220: sssd-tools: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

[Timo Aaltonen]

On 22.08.2018 11:51, Timo Aaltonen wrote:
> On 01.08.2018 18:02, Andreas Beckmann wrote:
>> Package: sssd-tools
>> Version: 1.16.2-1
>> Severity: serious
>>
>> # sss_obfuscate
>> Traceback (most recent call last):
>>   File "/usr/sbin/sss_obfuscate", line 8, in 
>> import pysss
>> ImportError: No module named pysss
> 
> sssd-tools depends on python-sss, so you should have pysss installed..

ha, it does depend on it, in git..


-- 
t

Bug#905220: [Pkg-sssd-devel] Bug#905220: sssd-tools: /usr/sbin/sss_obfuscate fails to run: ImportError: No module named pysss

[Timo Aaltonen]

On 01.08.2018 18:02, Andreas Beckmann wrote:
> Package: sssd-tools
> Version: 1.16.2-1
> Severity: serious
> 
> # sss_obfuscate
> Traceback (most recent call last):
>   File "/usr/sbin/sss_obfuscate", line 8, in 
> import pysss
> ImportError: No module named pysss

sssd-tools depends on python-sss, so you should have pysss installed..


-- 
t

Bug#900879: [Pkg-freeipa-devel] Bug#900879: bind9-dyndb-ldap: does not work with current bind9 anymore

[Timo Aaltonen]

On 06.06.2018 13:13, Dominik George wrote:
> On Wed, Jun 06, 2018 at 11:54:04AM +0200, Dominik George wrote:
>> This plugin only works with the old dyndb patch for BIND, but not with
>> the DynDB interface in the version now included in BIND upstream.
> 
> Seems that is not the case, but the plugin needs to be rebuilt against BIND
> 9.11.3, which seems not to work right now: 
> https://pagure.io/bind-dyndb-ldap/issue/176

If you had a look at the changelog, it would show that there was an
upload to fix the build against 9.11.3.. so it's pretty clear that the
plugin was built against it.

What's your issue? The upstream link says nothing.

-- 
t

Bug#877091: [Pkg-sssd-devel] Bug#877091: getent crashes while trying to display a group provided by sssd

[Timo Aaltonen]

severity: normal
thanks

On 28.09.2017 18:11, Petr Zaytsev wrote:
> Package: sssd
> Version: 1.15.3-1
> Severity: serious

1.16.1-1 has been available for a while, how's it working?

-- 
t

Bug#892956: libinput-dev: Requires.private without package dependencies breaks pkg-config users

[Timo Aaltonen]

On 14.03.2018 22:25, Adrian Bunk wrote:
> Package: libinput-dev
> Version: 1.10.3-1
> Severity: grave
> Control: affects -1 src:efl src:gnome-twitch src:muffin src:mutter 
> src:gnome-shell
> 
> https://buildd.debian.org/status/package.php?p=efl=sid
> 
> ...
> configure: error: pkg-config missing libinput >= 0.6.0 xkbcommon >= 0.3.0 
> libudev
> 
> 
> Root cause are the new dependencies in Requires.private
> without package dependencies:
> 
> $ pkg-config --cflags  libinput
> Package libwacom was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libwacom.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libwacom', required by 'libinput', not found

1.10.2-1 didn't have them, and nothing changed in 1.10.3 that would
result in this, so the culprit is elsewhere. Where did that
"Requires.private" come from?


-- 
t

Bug#891450: [Pkg-freeipa-devel] Bug#891450: custodia FTBFS: TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

[Timo Aaltonen]

reassign 891450 python-coverage
thanks

On 25.02.2018 19:17, Adrian Bunk wrote:
> Source: custodia
> Version: 0.5.0-3
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/custodia.html
> 
> ...
>  67 passed, 43 skipped in 14.94 seconds 
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/coverage/cmdline.py", line 624, in 
> do_run
> self.run_python_module(args[0], args)
>   File "/usr/lib/python3/dist-packages/coverage/execfile.py", line 114, in 
> run_python_module
> run_python_file(pathname, args, package=packagename, 
> modulename=modulename, path0="")
>   File "/usr/lib/python3/dist-packages/coverage/execfile.py", line 184, in 
> run_python_file
> exec(code, main_mod.__dict__)
>   File "/usr/lib/python3/dist-packages/pytest.py", line 73, in 
> raise SystemExit(pytest.main())
> SystemExit: 0
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/runpy.py", line 193, in _run_module_as_main
> "__main__", mod_spec)
>   File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
> exec(code, run_globals)
>   File "/usr/lib/python3/dist-packages/coverage/__main__.py", line 8, in 
> 
> sys.exit(main())
>   File "/usr/lib/python3/dist-packages/coverage/cmdline.py", line 753, in main
> status = CoverageScript().command_line(argv)
>   File "/usr/lib/python3/dist-packages/coverage/cmdline.py", line 488, in 
> command_line
> return self.do_run(options, args)
>   File "/usr/lib/python3/dist-packages/coverage/cmdline.py", line 638, in 
> do_run
> self.coverage.save()
>   File "/usr/lib/python3/dist-packages/coverage/control.py", line 783, in save
> self.get_data()
>   File "/usr/lib/python3/dist-packages/coverage/control.py", line 836, in 
> get_data
> self._post_save_work()
>   File "/usr/lib/python3/dist-packages/coverage/control.py", line 851, in 
> _post_save_work
> self._warn_about_unmeasured_code(pkg)
>   File "/usr/lib/python3/dist-packages/coverage/control.py", line 884, in 
> _warn_about_unmeasured_code
> has_file = hasattr(mod, '__file__') and os.path.exists(mod.__file__)
>   File "/build/1st/custodia-0.5.0/.tox/py36/lib/python3.6/genericpath.py", 
> line 19, in exists
> os.stat(path)
> TypeError: stat: path should be string, bytes, os.PathLike or integer, not 
> NoneType
> ERROR: InvocationError: '/build/1st/custodia-0.5.0/.tox/py36/bin/python -m 
> coverage run --parallel -m pytest --capture=no --strict --skip-servertests'
> ___ summary 
> 
> ERROR:   py36: commands failed
> make[1]: *** [debian/rules:22: override_dh_auto_test] Error 1
> 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890844#45
>   The fix is for third party packages to use `getattr(module, ‘__file__’, 
> None)` instead of `hasattr(module, ‘__file__’)`.


The bug is in coverage though.


-- 
t

Bug#891582: Dependency missing in vulkan-utils

[Timo Aaltonen]

severity 891582 normal
thanks

On 26.02.2018 22:09, Brett Johnson wrote:
> Package: vulkan
> Version: 1.0.65.2+dfsg1-1
> Severity: serious
> Justification: 1
> 
> 
> The utility "vulkan-smoketest" in the vulkan-utils package depends on
> layers in the libvulkan-dev package, but there is no dependency.  This
> can be easily verified by running it with the "--validate" option:
> 
> $ vulkan-smoketest --validate
> terminate called after throwing an instance of 'std::runtime_error'
>   what():  instance layer VK_LAYER_LUNARG_standard_validation is missing
> Aborted
> 
> 
> The easiest way to fix this is simply add a dependency, but it raises
> the question of why the vulkan-utils package exists.  Both vulkaninfo
> and smoketest could reasonably just be part of libvulkan-dev, as both
> are really vulkan developer utilities, rather than general purpose
> utilities.
But vulkan-smoketest runs fine without the dev package. Smoketest and
vulkaninfo are useful as a quick way to test the driver and/or the system.


-- 
t

Bug#890467: [Pkg-sssd-devel] Bug#890467: Bug#890467: sssd: upgrade from 1.16.0-3 to 1.16.0-5 causes total failure of sssd to work, can not log into machine

[Timo Aaltonen]

On 15.02.2018 16:46, Daniel Lakeland wrote:
> On 02/15/2018 04:55 AM, Timo Aaltonen wrote:
>> On 15.02.2018 14:50, Daniel Lakeland wrote:
>>>
>>> What exactly needs changing? Where is the documentation on this?
>> I don't know what you did to get -3 working in sid, but undo that. -5 is
>> not any different from -1 other than enabling a default config.
>>
>>
>>
> 
> For reference, it seems that what I did was remove the line "services
> nss,pam" and putting that line back makes it work with -5 apparently...
> in limited testing ;-)

Right, that line would break sssd if socket activation is used IIRC..
which was why it got dropped (again) :)


-- 
t

Bug#890067: libgl1-mesa-dri: breaks kde experimental (sddm or sddm-greeter crash, ksplashscreen crash)

[Timo Aaltonen]

On 10.02.2018 20:57, Eric Valette wrote:
> Package: libgl1-mesa-dri
> Version: 18.0.0~rc2-1
> Severity: critical
> Justification: breaks unrelated software
> 
> After sucesfully upgrading this machine with experimental kde; libc6, mesa, I 
> went down and upgraded htpc and kids pc that are
> 
> AMD A4-5000
> AMD E2-1800
> AMD E1
> 
> respectively and all did break preventing to log in any way in kde session.
> Becasue one of the crash in one machine reported once  a bug in r600_dri.so
> ksplashqml[1148]: segfault at 7ffcac73c000 ip 7f9bf07d5be5 sp 
> 7ffcac739bf8 error 6 in r600_dri.so[7f9bf0394000+a86000]

18.0.0-rc4 is now pushed to experimental, please try with it once it's
built but if the driver still crashes, file a bug upstream.



-- 
t

Bug#889698: nss 3.35 now defaults to SQL database, broke certmonger/mod_nss/dogtag/freeipa

[Timo Aaltonen]

On 06.02.2018 10:33, Mike Hommey wrote:
> On Tue, Feb 06, 2018 at 09:16:05AM +0200, Timo Aaltonen wrote:
>> Package: nss
>> Severity: grave
>>
>> Hi, please revert this commit which switched the default certificate 
>> database format to SQL:
>>
>> https://github.com/nss-dev/nss/commit/33b114e38278c4ffbb6b244a0ebc9910e5245cd3
>>
>> Several packages are not ready for it yet, including but likely not limited 
>> to:
>>
>> certmonger
>> libapache2-mod-nss
>> dogtag-pki
>> freeipa
>>
>> respective upstreams are working on it but getting everything merged will 
>> take a month or two.
> 
> Can you be more specific in how this affects those packages? Because
> AFAIR, this is supposed to kind of be transparent.

For example it changes how certutil is run, which would now need a
'dbm:'(?) prefix when accessing an old DB like when setting up Freeipa
as shown here:

https://bugs.launchpad.net/bugs/1746947

and it also breaks an installed Dogtag instance though I don't know how
exactly:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889526

these all use an internal cert DB.

-- 
t

Bug#889698: nss 3.35 now defaults to SQL database, broke certmonger/mod_nss/dogtag/freeipa

[Timo Aaltonen]

Package: nss
Severity: grave

Hi, please revert this commit which switched the default certificate database 
format to SQL:

https://github.com/nss-dev/nss/commit/33b114e38278c4ffbb6b244a0ebc9910e5245cd3

Several packages are not ready for it yet, including but likely not limited to:

certmonger
libapache2-mod-nss
dogtag-pki
freeipa

respective upstreams are working on it but getting everything merged will take 
a month or two.


-- 
t