Bug#1065688: [Pkg-freeipa-devel] Bug#1065688: python-jwcrypto: CVE-2024-28102

[Timo Aaltonen]

Steve McIntyre kirjoitti 30.4.2024 klo 19.19:

Hi!

On Fri, Mar 08, 2024 at 10:42:40PM +0100, Salvatore Bonaccorso wrote:

Source: python-jwcrypto
Version: 1.5.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-jwcrypto.

CVE-2024-28102[0]:
| JWCrypto implements JWK, JWS, and JWE specifications using python-
| cryptography. Prior to version 1.5.6, an attacker can cause a denial
| of service attack by passing in a malicious JWE Token with a high
| compression ratio. When the server processes this token, it will
| consume a lot of memory and processing time. Version 1.5.6 fixes
| this vulnerability by limiting the maximum token length.


We wanted this fixed in Pexip, so I've taken a look at this bug.

The upstream bugfix just needs a small rework so it applies cleanly to
the version in bookworm. Here's a debdiff for that that in case it's
useful.


I've pushed 1.5.6 to sid now, feel free to upload the proposed version 
for bookworm, thanks.


--
t

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#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#1063725: xkb-data: keymap alias 'dvorak' no longer available

[Timo Aaltonen]

Michael Gold kirjoitti 11.2.2024 klo 21.31:

Package: xkb-data
Version: 2.41-1

Dear Maintainer,

I noticed a "setxkbmap dvorak" command, run by my X session scripts,
starting giving an error with the latest xkb-data:
Error loading new keyboard description

It started after upgrading the following 4 packages together:
console-setup:amd64 (1.223, 1.226)
console-setup-linux:amd64 (1.223, 1.226)
xkb-data:amd64 (2.38-2, 2.41-1),
keyboard-configuration:amd64 (1.223, 1.226)
(The xkb-data changes look the most substantial, which is why I've filed
against that package.)

My keyboard layout was still as expected, but downgrading those packages
to the versions from 'testing' eliminated the error.

Here's the output of "setxkbmap -verbose 10 -print dvorak" with 2.38-2:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)"   };
xkb_types { include "complete"};
xkb_compat{ include "complete"};
xkb_symbols   { include 
"pc+us(dvorak)+inet(evdev)+ctrl(swapcaps)+compose(menu)"  };
xkb_geometry  { include "pc(pc105)"   };
};

And with 2.41-1:
Setting verbose level to 10
locale is C
Warning! Multiple definitions of keyboard layout
 Using command line, ignoring X server
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:  evdev
model:  pc105
layout: dvorak
options:ctrl:swapcaps,compose:menu
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:  complete
compat: complete
symbols:pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)
geometry:   pc(pc105)
xkb_keymap {
xkb_keycodes  { include "evdev+aliases(qwerty)"   };
xkb_types { include "complete"};
xkb_compat{ include "complete"};
xkb_symbols   { include 
"pc+dvorak+inet(evdev)+ctrl(swapcaps)+compose(menu)"  };
xkb_geometry  { include "pc(pc105)"   };
};

The contents of /etc/default/keyboard:
# KEYBOARD CONFIGURATION FILE

# Consult the keyboard(5) manual page.

XKBMODEL="pc105"
XKBLAYOUT="us"
XKBVARIANT="dvorak"
XKBOPTIONS="ctrl:swapcaps"

BACKSPACE="guess"

My X session was configured to run this command at startup:
setxkbmap -option 'ctrl:swapcaps' -option 'compose:menu' dvorak

After looking at the above output, I changed "dvorak" to "us(dvorak)" in
the command, and it worked without error.

It's not clear whether support for just "dvorak" was dropped on purpose,
but I don't recall seeing any deprecation warnings about it, and don't
see any relevant Debian changelog or "NEWS" entry.

- Michael


Hi,

This was likely due to

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/470ad2cd8fea84d7210377161d86b31999bb5ea6

I'll add a NEWS entry for this too.


--
Timo Aaltonen
Kernel Enablement
Canonical Ltd.

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#1061213: [Pkg-opencl-devel] Bug#1061213: Bug#1061213: Please upgrade to llvm-toolchain-17

[Timo Aaltonen]

Timo Aaltonen kirjoitti 25.1.2024 klo 9.52:

Sylvestre Ledru kirjoitti 20.1.2024 klo 23.03:

Source: intel-graphics-compiler
Severity: important

Dear Maintainer,

As part of the effort to limit the number of llvm packages in the
archive, it would be great if you could upgrade to -17.

This package depends on 14.

Thanks,
Sylvestre


according to upstream, 14 is the current one they support

https://github.com/intel/intel-graphics-compiler/projects/5


and the latest version doesn't even build with llvm 16, let alone 17.


according to

https://github.com/intel/intel-graphics-compiler/issues/289

they are planning to support llvm 15 later this year. IGC does build 
against it already, but it's not considered production quality.



--
t

Bug#1061213: [Pkg-opencl-devel] Bug#1061213: Please upgrade to llvm-toolchain-17

[Timo Aaltonen]

Sylvestre Ledru kirjoitti 20.1.2024 klo 23.03:

Source: intel-graphics-compiler
Severity: important

Dear Maintainer,

As part of the effort to limit the number of llvm packages in the
archive, it would be great if you could upgrade to -17.

This package depends on 14.

Thanks,
Sylvestre


according to upstream, 14 is the current one they support

https://github.com/intel/intel-graphics-compiler/projects/5


and the latest version doesn't even build with llvm 16, let alone 17.


--
t

Bug#1060415: [Pkg-freeipa-devel] Bug#1060415: freeipa: CVE-2023-5455

[Timo Aaltonen]

Salvatore Bonaccorso kirjoitti 10.1.2024 klo 23.14:

Source: freeipa
Version: 4.10.2-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.9.11-1

Hi,

The following vulnerability was published for freeipa.

CVE-2023-5455[0]:
| A Cross-site request forgery vulnerability exists in
| ipa/session/login_password in all supported versions of IPA. This
| flaw allows an attacker to trick the user into submitting a request
| that could perform actions as the user, resulting in a loss of
| confidentiality and system integrity. During community penetration
| testing it was found that for certain HTTP end-points FreeIPA does
| not ensure CSRF protection. Due to implementation details one cannot
| use this flaw for reflection of a cookie representing already
| logged-in user. An attacker would always have to go through a new
| authentication attempt.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-5455
 https://www.cve.org/CVERecord?id=CVE-2023-5455
[1] https://www.freeipa.org/release-notes/4-10-3.html#highlights-in-4-10-3
 https://pagure.io/freeipa/c/363fd5de98e883800ac08b2760e8c3150783e7e2
[2] https://www.freeipa.org/release-notes/4-9-14.html#highlights-in-4-9-14
 https://pagure.io/freeipa/c/9b1a65fe3936c4d3fe237775e54f0249b740f23e

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


Hi,

This affects the server only, which we only have in experimental every 
now and then.



--
t

Bug#1059971: libgl1-mesa-dri: X doesn't start after mesa upgrade from 23.2.1-1 to 23.3.2-1

[Timo Aaltonen]

Pierre Erraud kirjoitti 4.1.2024 klo 11.20:

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

After doing my usual `apt-get dist-upgrade` this morning & reboot, I could not 
get into gdm anymore. Downgrading to 23.2.1-1 all the mesa packages makes it work 
again. I have seen similar bugs, but they are old, I don't know if they are related 
or not.

Happy new year!

Pierre
[ 9.518] (EE) AIGLX error: dlopen of 
/usr/lib/x86_64-linux-gnu/dri/i965_dri.so failed 
(/usr/lib/x86_64-linux-gnu/dri/i965_dri.so: cannot open shared object file: No 
such file or directory)
[ 9.518] (EE) AIGLX error: unable to load driver i965


That driver is not from mesa, but mesa-amber, which isn't even in Debian 
(yet).



--
t

Bug#1056215: vulkan-tools: vulkaninfo tool can't be installed

[Timo Aaltonen]

Steven Friedrich kirjoitti 19.11.2023 klo 8.27:

Package: vulkan-tools
Severity: important

Dear Maintainer,

Vulcan Info Center missing vulkaninfo, apt can't find package.



But you managed to file a bug against vulkan-tools, which includes 
/usr/bin/vulkaninfo? So what's the problem?



--
t

Bug#1055277: ITP: vulkan-utility-libraries -- Libraries useful for other Vulkan projects

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: vulkan-utility-libraries
  Version : 1.3.268.0
  Upstream Contact: https://github.com/KhronosGroup/Vulkan-Utility-Libraries
* URL : https://github.com/KhronosGroup/Vulkan-Utility-Libraries
* License : Apache-2.0
  Programming Lang: C++
  Description : Libraries useful for other Vulkan projects

Bug#1052681: no uploader

[Timo Aaltonen]

Ben Tris kirjoitti 26.9.2023 klo 8.50:

Source: xinit
X-Debbugs-Cc: benatt...@gezapig.nl
Severity: important

Dear Maintainer,

There is no uploader at this moment, it is required in this case I
think.

Debian Policy Manual, Release 4.6.2.0
3.3 The maintainer of a package

If the maintainer of the package is a team of people with a shared
email
address, the Uploaders control field must be
present and must contain at least one human with their personal email
address.



Stop already, these bugreports are of no use.

--
t

Bug#1050071: llvm-defaults: move to 16

[Timo Aaltonen]

Simon McVittie kirjoitti 11.9.2023 klo 12.36:

On Sat, 19 Aug 2023 at 10:39:44 +0200, Sylvestre Ledru wrote:

llvm-defaults has been pointing to 16 in experimental for quite sometime.
Opening this transition to make sure it is on your radar! :)

I opened bug #1050070 & #1050069 for future removals.


Mesa is a significant user of LLVM, and hard-codes its own non-default
version of LLVM which often runs ahead of the default (currently 15).
It seems to be relatively common for a LLVM version upgrade to cause
regressions or uninstallability on at least one architecture, and also
relatively common for a LLVM version upgrade to be necessary to unblock
features or bug fixes in Mesa, which I assume is why the Mesa maintainers
have felt the need to control this themselves.

Should Mesa try moving to -16 *before* the default changes? It would
seem unhelpful to move the rest of the distribution to a version that
Mesa can't use for whatever reason.

I've opened a Mesa bug at wishlist severity suggesting a move to version
16, and set it to block the bug for llvm-toolchain-15 removal (#1050070).

 smcv



Hi,

The remaining blocker for this is that using llvm-16 requires a newer 
bindgen, and the latest upstream version split the cli separate, so that 
needs to be packaged (has been done AIUI) and processed through NEW 
first, see:


https://salsa.debian.org/rust-team/debcargo-conf/-/issues/50


--
t

Bug#1042827: [Pkg-sssd-devel] priv-wrapper?

[Timo Aaltonen]

Simon Josefsson kirjoitti 3.8.2023 klo 22.55:

Timo Aaltonen  writes:

I had a brief look at priv-wrapper packaging, and noticed it only
keeps the debian/ dir in git? The sssd-team packages have the full
upstream git as the base, with packaging added to the packaging
branch. I prefer those will remain like that :)


I usually also do the full git repo with upstream branch for most of the
packages I maintain, but for this new package I wanted to see if keeping
only debian/ in git worked, as I've had success with that in another
package.  What is really the upside of having upstream code in Debian's
git?  One downside is that it wastes space, although I don't think that
matters a lot these days.  Another downside is that it confuses what is
really the "upstream" in case the Debian git-repo's view of what
"upstream" is differs from the real upstream.


How do you pull a new upstream release, download the tarball? I don't 
like working with upstream tarballs as the source of a new release, git 
is much nicer. And it allows using snapshots when needed etc.



Just to clarify, did you mean that you would want priv-wrapper to use
the same style as the other packages, or merely that I shouldn't change
the other sssd-packages to use this debian/-only approach?  I wouldn't
do the latter.  Generally if you feel there is any subjective style
matter you don't agree with, I'm happy to follow what you prefer.  I
prefer to keep priv-wrapper as debian/-only if you think that is okay,
unless I learn some disadvantage with it that I am not aware of yet.


It's fine to have priv-wrapper as-is, no objections there.


/Simon

PS. Changing to your ubuntu.com email address since sending to your
debian.org address results in bounces when debian.org forwards it to
ubuntu.com because debian.org is not authorized to send emails on behalf
of si...@josefsson.org due to (probably) my SPF 'mx -all' preference.  I
think it is a problem with the debian.org forwarder..


Yeah email sucks. I can't send to gmail addresses (with @debian.org) 
because of my smtp provider which has no DKIM..



--
t

Bug#1042961: mesa-utils: glxdemo dumps core when called with an empty environment

[Timo Aaltonen]

Francesco Potortì kirjoitti 3.8.2023 klo 13.57:

Package: mesa-utils
Version: 8.5.0-1
Severity: normal
X-Debbugs-Cc: none, Francesco Potortì 

$ env - glxdemo
Segmentation fault (core dumped)



Probably because it can't open the display, although it could be more 
graceful like glxinfo.


That said, if you like to see it fixed at some point, file this 
upstream: https://gitlab.freedesktop.org/mesa/demos/-/issues


--
t

Bug#1042827: [Pkg-sssd-devel] priv-wrapper?

[Timo Aaltonen]

Simon Josefsson kirjoitti 1.8.2023 klo 18.46:

Hi

I have finished packaging cwrap's priv-wrapper:

https://salsa.debian.org/jas/priv-wrapper/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042827

Would you be interested in co-maintaining priv-wrapper in the SSSD
group?  I noticed that SSSD maintains some of the other cwrap projects:

https://tracker.debian.org/pkg/nss-wrapper
https://tracker.debian.org/pkg/pam-wrapper
https://tracker.debian.org/pkg/uid-wrapper

I'm happy to maintain priv-wrapper in the sssd-group, and help improve
packaging of other SSSD packages (e.g, upload new releases), if you
grant me access to the Salsa gitlab group.

/Simon


Hi,

That sounds fine. I had a brief look at priv-wrapper packaging, and 
noticed it only keeps the debian/ dir in git? The sssd-team packages 
have the full upstream git as the base, with packaging added to the 
packaging branch. I prefer those will remain like that :)



--
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#1036176: mesa: please consider upgrading to 3.0 source format

[Timo Aaltonen]

On 16.5.2023 21.08, Bastian Germann wrote:

Source: mesa
Version: 22.3.6-1+deb12u1
Severity: wishlist

Please switch xss-lock to the 3.0 (quilt) source format.



Why? And was this part of some mass bug filing, as you have xss-lock in 
there.


--
t

Bug#1041243: mesa: please remove control file, as control.in is present

[Timo Aaltonen]

On 16.7.2023 15.30, Fabio Pedretti wrote:

Source: mesa
Version: 22.3.6-1+deb12u1
Severity: normal
X-Debbugs-Cc: pedretti.fa...@gmail.com

Please remove control file in git, since there is already control.in, and
control is automatically generated during build.


regeneration doesn't work when d/control is removed


--
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#1036993: [Pkg-sssd-devel] Bug#1036993: /lib/x86_64-linux-gnu/security/pam_sss.so: pam_sss passes KRB5CCNAME with sudo -i (see redhat bug/fix 1324486)

[Timo Aaltonen]

J. Pfennig kirjoitti 31.5.2023 klo 21.34:

Package: libpam-sss
Version: 2.8.2-4
Severity: normal
File: /lib/x86_64-linux-gnu/security/pam_sss.so

Dear Maintainer,

* What led up to the situation?

 using kerberos, AD/DC, sssd and its pam module

* What exactly did you do (or not do) that was effective (or
  ineffective)?

 kinit ...   # to get a kerberos ticket
 echo $KRB5CCNAME# path to creditial cache

 sudo -i user2
 echo $KRB5CCNAME# ORIGINAL path to creditial cache

* What was the outcome of this action?

 kinit, klist et al fail, wrong credential cache
 echo $KRB5CCNAME# path from original user

* What outcome did you expect instead?

 KRB5CCNAME must not be passed

 the case is described better than I can do at:

 https://bugzilla.redhat.com/show_bug.cgi?id=1324486

 Bug fixed there in 2017. Could Debian fix it too?



The default value for pam_response_filter should already be
'ENV:KRB5CCNAME:sudo, ENV:KRB5CCNAME:sudo-i', so this issue should not 
happen since 2.5.1.



--
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#1035895: Please add ast_dri.so

[Timo Aaltonen]

Al Ma kirjoitti 10.5.2023 klo 23.11:

Package: libgl1-mesa-dri

Version: 20.3.5-1



My journal log shows, among other weird stuff, the following error message:

Mai 10 21:01:20 AnonymizedComputerName gnome-shell[1026]: Running GNOME 
Shell (using mutter 42.3) as a Wayland display server


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Device 
'/dev/dri/card0' prefers shadow buffer


Mai 10 21:01:21 AnonymizedComputerName goa-daemon[1048]: goa-daemon 
version 3.38.0 starting


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Added device 
'/dev/dri/card0' (ast) using atomic mode setting.


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Activating service name='org.gnome.Identity' requested 
by ':1.15' (uid=119 pid=1048 comm="/usr/libexec/goa-daemon ")


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Device 
'/dev/dri/card1' prefers shadow buffer


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 'org.gnome.OnlineAccounts'


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 'org.gnome.Identity'


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 
'org.gtk.vfs.GoaVolumeMonitor'


Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Virtual 
filesystem service - GNOME Online Accounts monitor.


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Activating via systemd: service 
name='org.gtk.vfs.GPhoto2VolumeMonitor' 
unit='gvfs-gphoto2-volume-monitor.service' requested by ':1.3' (uid=119 
pid=955 comm="/usr/libexec/tracker-miner-fs ")


Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Starting Virtual 
filesystem service - digital camera monitor...


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[962]: [session 
uid=119 pid=962] Successfully activated service 
'org.gtk.vfs.GPhoto2VolumeMonitor'


Mai 10 21:01:21 AnonymizedComputerName systemd[920]: Started Virtual 
filesystem service - digital camera monitor.


Mai 10 21:01:21 AnonymizedComputerName dbus-daemon[778]: [system] 
Activating via systemd: service name='org.freedesktop.UPower' 
unit='upower.service' requested by ':1.37' (uid=119 pid=955 
comm="/usr/libexec/tracker-miner-fs ")


Mai 10 21:01:21 AnonymizedComputerName systemd[1]: Starting Daemon for 
power management...


Mai 10 21:01:21 AnonymizedComputerName systemd[1]: Started Console Mouse 
manager.


Mai 10 21:01:21 AnonymizedComputerName gnome-shell[1026]: Added device 
'/dev/dri/card1' (nouveau) using non-atomic mode setting.


Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
pci id for fd 9: 1a03:2000, driver (null)


Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
MESA-LOADER: failed to open ast: /usr/lib/dri/ast_dri.so: Kann die 
Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden 
(search paths /usr/lib/x86_64-linux-gnu/dri:\$${ORIGIN}/dri:/usr/lib/dri)


Mai 10 21:01:21 AnonymizedComputerName org.gnome.Shell.desktop[1026]: 
failed to load driver: ast




So MESA-LOADER complains that /usr/lib/dri/ast_dri.so is not found.  
This is correct because on my machine, /usr/lib/dri doesn't exist and 
ast_dri.so doesn't exist elsewhere. Does my Aspeed chip have no driver?  
Should I ever need it a VGA output, don't I get it?  My request is to 
deal with this error message, ideally, by introducing ast_dri.so into to 
Debian (or making MESA-LOADER work without it).


There is no such driver.

--
t

Bug#1035014: installation-reports: Graphical installer has Xorg "no screens found" error

[Timo Aaltonen]

Cyril Brulebois kirjoitti 1.5.2023 klo 18.50:

Control: reassign -1 xserver-xorg-core-udeb 2:21.1.1-1
Control: affects -1 debian-installer

Hello debian-x,

Cyril Brulebois  (2023-04-27):

Tracked down to 9c81b8f5b5 upstream:
   https://cgit.freedesktop.org/xorg/xserver/commit/?id=9c81b8f5b5

Flipping the switch and wrapping it up in a netboot mini.iso
debian-installer build led to a successful test (with amd64) by Keith.
We'll try and confirm the same happens with arm64.

If you're happy with that approach, feel free to reassign to the udeb,
and check the udeb-modesetting branch in xorg-server:
   
https://salsa.debian.org/xorg-team/xserver/xorg-server/-/commits/udeb-modesetting


Any objections to my merging/uploading this?


Hi, fine by me!

--
t

Bug#1034899: unblock: sssd/2.8.2-4

[Timo Aaltonen]

Package: release.debian.org
Control: affects -1 + src:sssd
X-Debbugs-Cc: s...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package sssd.

[ Reason ]
This drops a change that added a line for subid to /etc/nsswitch.conf, 
but subuid only supports a single database, so this addition needs to be 
dropped so that /etc/sub[ug]id still works.


[ Impact ]
Prevents sssd from getting dropped from bookworm.

[ Risks ]
Minimal, subuid support was a fairly recent addition, so people 
upgrading from earlier Debian don't see sssd changing behaviour (due to 
this).


[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing

unblock sssd/2.8.2-4

--
tdiff -Nru sssd-2.8.2/debian/changelog sssd-2.8.2/debian/changelog
--- sssd-2.8.2/debian/changelog 2023-02-26 16:35:48.0 +0200
+++ sssd-2.8.2/debian/changelog 2023-04-11 15:19:36.0 +0300
@@ -1,3 +1,10 @@
+sssd (2.8.2-4) unstable; urgency=medium
+
+  [ Sam Morris ]
+  * Don't add subid to /etc/nsswitch.conf (Closes: #1032990)
+
+ -- Timo Aaltonen   Tue, 11 Apr 2023 15:19:36 +0300
+
 sssd (2.8.2-3) unstable; urgency=medium
 
   [ Gioele Barabucci ]
diff -Nru sssd-2.8.2/debian/sssd-common.nss sssd-2.8.2/debian/sssd-common.nss
--- sssd-2.8.2/debian/sssd-common.nss   2023-02-26 16:33:13.0 +0200
+++ sssd-2.8.2/debian/sssd-common.nss   1970-01-01 02:00:00.0 +0200
@@ -1,5 +0,0 @@
-# The 'subid' database supports only a sigle data source:
-# <https://github.com/shadow-maint/shadow/issues/351>
-subid  database-add
-
-subid  lastsss
diff -Nru sssd-2.8.2/debian/sssd-common.preinst 
sssd-2.8.2/debian/sssd-common.preinst
--- sssd-2.8.2/debian/sssd-common.preinst   2023-01-10 16:39:57.0 
+0200
+++ sssd-2.8.2/debian/sssd-common.preinst   2023-04-11 15:14:22.0 
+0300
@@ -17,6 +17,14 @@
 # Force the AppArmor profile to complain mode on install
 inst_complain_profile
 ;;
+upgrade)
+if dpkg --compare-versions "$2" le 2.8.2-3; then
+   # 2.8.2-2 added a line for subid which was premature given that
+   # libsubid supports only a single database. Let's remove it to avoid
+   # breaking systems where the user expects /etc/sub[ug]id to continue to
+   # work.
+   sed -E -i "${DPKG_ROOT}/etc/nsswitch.conf" -e '/^subid:\s*sss\s*$/d'
+fi
 esac
 
 #DEBHELPER#

Bug#1034659: [Pkg-freeipa-devel] Bug#1034659: Bug#1034659: freeipa-client: IPA client Kerberos configuration incompatible with java

[Timo Aaltonen]

Mathieu Baudier kirjoitti 21.4.2023 klo 10.45:

Okay, so it got added to sssd due to

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

so I wonder if ipa should stop doing the same, and remove the line
from
krb5.conf on upgrade.


Seems this is filed upstream already at

https://pagure.io/freeipa/issue/9267

but no fix available yet, so it needs to be fixed downstream first.


Ok, I had missed that it was already filed upstream.
Actually, the issue also occurs on RHEL 9.

I am well set up to test a patched Debian package if it can be helpful.

As I described in the original bug report above, the workaround is
either to delete /etc/krb5.conf.d/enable_sssd_conf_dir or to comment
the includedir line out.

It could be more robust to patch it at this level since
/etc/krb5.conf.d/enable_sssd_conf_dir is a static file, while
/etc/krb5.conf is modified by ipa-client-install. But on the long run,
the upstream fix will probably be at IPA level as you suggested, so
maybe it is safer to keep a patch there, and not to impact sssd.


Yes, the change should be in freeipa, sssd needs that for other use 
cases where ipa is not involved.


--
t

Bug#1034659: [Pkg-freeipa-devel] Bug#1034659: Bug#1034659: freeipa-client: IPA client Kerberos configuration incompatible with java

[Timo Aaltonen]

Timo Aaltonen kirjoitti 21.4.2023 klo 9.59:

Mathieu Baudier kirjoitti 21.4.2023 klo 7.19:

Package: freeipa-client
Version: 4.9.11-1
Severity: normal

Dear Maintainer,


on a host enrolled as an IPA client, Kerberos is not usable in Java.

The error message is:
   KrbException: krb5.conf loading failed

(please find simple steps to reproduce below)

After debugging step by step, I found out that this is due to the fact
that the following Kerberos configuration directory
/var/lib/sss/pubconf/krb5.include.d/
ends up being included twice and that Java rejects multiple includes 
of the same directory.


This directory is included:

- in the configuration file /etc/krb5.conf.d/enable_sssd_conf_dir
which is deployed by the installation of the *package* freeipa-client
(probably indirectly by one of the sssd packages?)

- in the configuration file /etc/krb5.conf
which is generated by the ipa-client-install procedure

As a workaround, commenting out the includedir line in
/etc/krb5.conf.d/enable_sssd_conf_dir
(or completely removing this file, since it contains only this line)
solves the problem.

Please note that:
- the issue occurs with Java 17, 11 and 21 (and most likely other 
available Java versions)

- the issue does NOT occur on bullseye with freeipa-client from backports
(which we have been using in production for a while)

In order to reproduce (on a host enrolled as an IPA client), using the 
standard Java JAAS Kerberos example:

https://docs.oracle.com/en/java/javase/17/security/jaas-authentication.html
(just copy JaasAcn.java and jaas.conf in the same directory; no need 
to compile)


$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Djava.security.auth.login.config=jaas.conf JaasAcn.java

Kerberos username [mbaudier]:
Authentication failed:
   KrbException: krb5.conf loading failed

And the workaround:

$ sudo mv /etc/krb5.conf.d/enable_sssd_conf_dir /tmp

$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Djava.security.auth.login.config=jaas.conf JaasAcn.java

Kerberos username [mbaudier]:
Kerberos password for mbaudier:
Authentication succeeded!


Hi,

Okay, so it got added to sssd due to

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

so I wonder if ipa should stop doing the same, and remove the line from 
krb5.conf on upgrade.


Seems this is filed upstream already at

https://pagure.io/freeipa/issue/9267

but no fix available yet, so it needs to be fixed downstream first.

--
t

Bug#1034659: [Pkg-freeipa-devel] Bug#1034659: freeipa-client: IPA client Kerberos configuration incompatible with java

[Timo Aaltonen]

Mathieu Baudier kirjoitti 21.4.2023 klo 7.19:

Package: freeipa-client
Version: 4.9.11-1
Severity: normal

Dear Maintainer,


on a host enrolled as an IPA client, Kerberos is not usable in Java.

The error message is:
   KrbException: krb5.conf loading failed

(please find simple steps to reproduce below)

After debugging step by step, I found out that this is due to the fact
that the following Kerberos configuration directory
/var/lib/sss/pubconf/krb5.include.d/
ends up being included twice and that Java rejects multiple includes of the 
same directory.

This directory is included:

- in the configuration file /etc/krb5.conf.d/enable_sssd_conf_dir
which is deployed by the installation of the *package* freeipa-client
(probably indirectly by one of the sssd packages?)

- in the configuration file /etc/krb5.conf
which is generated by the ipa-client-install procedure

As a workaround, commenting out the includedir line in
/etc/krb5.conf.d/enable_sssd_conf_dir
(or completely removing this file, since it contains only this line)
solves the problem.

Please note that:
- the issue occurs with Java 17, 11 and 21 (and most likely other available 
Java versions)
- the issue does NOT occur on bullseye with freeipa-client from backports
(which we have been using in production for a while)

In order to reproduce (on a host enrolled as an IPA client), using the standard 
Java JAAS Kerberos example:
https://docs.oracle.com/en/java/javase/17/security/jaas-authentication.html
(just copy JaasAcn.java and jaas.conf in the same directory; no need to compile)

$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Djava.security.auth.login.config=jaas.conf JaasAcn.java
Kerberos username [mbaudier]:
Authentication failed:
   KrbException: krb5.conf loading failed

And the workaround:

$ sudo mv /etc/krb5.conf.d/enable_sssd_conf_dir /tmp

$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java 
-Djava.security.auth.login.config=jaas.conf JaasAcn.java
Kerberos username [mbaudier]:
Kerberos password for mbaudier:
Authentication succeeded!


Hi,

Okay, so it got added to sssd due to

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

so I wonder if ipa should stop doing the same, and remove the line from 
krb5.conf on upgrade.



--
t

Bug#1005359: xserver-xorg-core: Intel HD Graphics 610: blank screen

[Timo Aaltonen]

Alban Browaeys kirjoitti 4.4.2023 klo 23.04:

You also have:
[70.087] (EE) Failed to load module "fbdev" (module does not exist, 0)
and
[70.087] (EE) Failed to load module "vesa" (module does not exist, 0)

you could try installing:
xserver-xorg-video-vesa
and
xserver-xorg-video-fbdev

please no



--
t

Bug#1033968: unblock: certmonger/0.79.17-2

[Timo Aaltonen]

Package: release.debian.org
Control: affects -1 + src:certmonger
X-Debbugs-Cc: certmon...@packages.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Please unblock package certmonger.

[ Reason ]
This reverts a change in -1 that was done in order to work around the 
fact that Debian doesn't use a shared /etc/pki/nssdb, and that turned 
out to be unnecessary after upstream fixed the original issue and 
doesn't need an nssdb anymore.


The other changes are minor, fixes a crossbuild issue and disables 
support for insecure DSA keys.


There is one undocumented change which was due to a MR from salsa:
https://salsa.debian.org/freeipa-team/certmonger/-/merge_requests/3

but it just bumps a build-dep. Running 'gbp dch' was easy to miss, as I 
usually include the dch entry in my commits.


[ Impact ]
Allows (free)ipa-server-install to succeed without racing to a failure, 
this can be seen in the CI results using the package from experimental 
(testing/unstable only has the client):


https://ci.debian.net/packages/f/freeipa/unstable/amd64/

Having a fixed package in bookworm would allow backporting 
freeipa-server if need be.


[ Risks ]
Minimal, certmonger itself doesn't need the nssdb that was created in -1 
so reverting it here shouldn't break any systems that have -1.


[ Checklist ]
[ ] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing

unblock certmonger/0.79.17-2diff -Nru certmonger-0.79.17/debian/certmonger.install certmonger-0.79.17/debian/certmonger.install
--- certmonger-0.79.17/debian/certmonger.install	2023-02-25 12:18:09.0 +0200
+++ certmonger-0.79.17/debian/certmonger.install	2023-03-18 10:37:33.0 +0200
@@ -1,5 +1,4 @@
 etc/certmonger/certmonger.conf
-etc/certmonger/nssdb
 etc/dbus-1/system.d/*
 lib/systemd/system/
 usr/bin/*
diff -Nru certmonger-0.79.17/debian/certmonger.maintscript certmonger-0.79.17/debian/certmonger.maintscript
--- certmonger-0.79.17/debian/certmonger.maintscript	1970-01-01 02:00:00.0 +0200
+++ certmonger-0.79.17/debian/certmonger.maintscript	2023-03-18 14:26:01.0 +0200
@@ -0,0 +1,5 @@
+rm_conffile /etc/certmonger/nssdb/cert9.db 0.79.17-2~
+rm_conffile /etc/certmonger/nssdb/key4.db 0.79.17-2~
+rm_conffile /etc/certmonger/nssdb/pkcs11.txt 0.79.17-2~
+rm_conffile /etc/certmonger/nssdb/ 0.79.17-2~
+
diff -Nru certmonger-0.79.17/debian/certmonger.postrm certmonger-0.79.17/debian/certmonger.postrm
--- certmonger-0.79.17/debian/certmonger.postrm	2023-02-25 12:18:09.0 +0200
+++ certmonger-0.79.17/debian/certmonger.postrm	2023-03-18 10:45:39.0 +0200
@@ -7,7 +7,6 @@
 rm -f /var/lib/certmonger/local/*
 rm -f /var/lib/certmonger/lock
 rm -f /var/lib/certmonger/requests/*
-rm -rf /etc/certmonger/nssdb
 ;;
 esac
 
diff -Nru certmonger-0.79.17/debian/changelog certmonger-0.79.17/debian/changelog
--- certmonger-0.79.17/debian/changelog	2023-02-25 12:25:47.0 +0200
+++ certmonger-0.79.17/debian/changelog	2023-03-18 14:33:47.0 +0200
@@ -1,3 +1,12 @@
+certmonger (0.79.17-2) unstable; urgency=medium
+
+  * control: Respect nocheck, thanks Chris Lamb! (Closes: #1032058)
+  * rules: Disable DSA.
+  * Revert adding an internal nssdb, instead add an upstream patch
+that drops the requirement for one.
+
+ -- Timo Aaltonen   Sat, 18 Mar 2023 14:33:47 +0200
+
 certmonger (0.79.17-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru certmonger-0.79.17/debian/control certmonger-0.79.17/debian/control
--- certmonger-0.79.17/debian/control	2023-02-25 12:18:09.0 +0200
+++ certmonger-0.79.17/debian/control	2023-03-07 10:17:19.0 +0200
@@ -16,7 +16,7 @@
  libldap2-dev,
  libnspr4-dev,
  libnss3-tools,
- libnss3-dev,
+ libnss3-dev (>= 2:3.69),
  libpopt-dev,
  libssl-dev,
  systemd [linux-any],
diff -Nru certmonger-0.79.17/debian/patches/dont-require-an-nss-database.diff certmonger-0.79.17/debian/patches/dont-require-an-nss-database.diff
--- certmonger-0.79.17/debian/patches/dont-require-an-nss-database.diff	1970-01-01 02:00:00.0 +0200
+++ certmonger-0.79.17/debian/patches/dont-require-an-nss-database.diff	2023-03-18 10:46:18.0 +0200
@@ -0,0 +1,147 @@
+From 83cd2e9d63e4851b3ada42aba868ecbb58365831 Mon Sep 17 00:00:00 2001
+From: Rob Crittenden 
+Date: Mar 17 2023 17:39:41 +
+Subject: Don't require an NSS database in cm_certread_n_parse
+
+
+If CM_DEFAULT_CERT_STORAGE_LOCATION points to a non-existant
+NSS database then parsing certificates will fail. This is
+noticable during IPA install when the CA certificates
+are tracked and the database doesn't exist.
+
+If the NSS Init fails then certmonger thinks there is no
+cert at all and tries to obtain a new one, only to fail again
+and again because of the failed parsing.
+
+This function only loads the certificate to parse out
+attributes from the certific

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#1032999: unblock: mesa/22.3.6-1

[Timo Aaltonen]

Paul Gevers kirjoitti 15.3.2023 klo 21.46:

Hi Timo,

On 15-03-2023 19:15, Timo Aaltonen wrote:
There's actually 22.3.7 out, which I was thinking of uploading to sid, 


Is that following the freeze policy [1]? I.e. targeted fixes? (It might 
be, I don't know the release policy of mesa).


Mesa does quarterly feature releases, and then bugfix releases on top of 
those. 22.3 was the feature release, 22.3.x are for bugfixes only. So 
yes, it does follow the policy. 23.0 is the latest release and will stay 
in experimental until bookworm is out.


since it's the last release of the 22.3.x series. Maybe that should be 
requested to be unblocked instead once it's available?


Well, it's blocked by something else, having *this* version tested in 
unstable is worth quite a bit for us. So, please only upload that 
version if it meets the freeze policy.


Paul


I think it makes sense to let 22.3.6 migrate first, and not risk that by 
another upload at this time. Once it has migrated, I'll see if 22.3.7-1 
could make it to the release or not.



--
t

Bug#1032999: unblock: mesa/22.3.6-1

[Timo Aaltonen]

Simon McVittie kirjoitti 15.3.2023 klo 16.40:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: m...@packages.debian.org
Control: affects -1 + src:mesa
Control: block -1 by 1032887

Please consider unblocking package mesa.

[ Reason ]
New upstream bugfix release, fixing #1029731 (RC) and many more.

[ Impact ]
If not accepted, bookworm will ship with various avoidable crashes and
hangs in the graphics driver stack.

[ Tests ]
Has been in unstable for 17 days, currently no RC bugs.

[ Risks ]
I'll leave this for the Mesa maintainers to answer...

[ Checklist ]
   [x] all changes are documented in the d/changelog
   [ ] I reviewed all changes and I approve them
   [x] attach debdiff against the package in testing

[ Other info ]
I am not a maintainer of this package, just an interested user.

This can't migrate until llvm-toolchain-15 does (see #1032887, which I
believe is only waiting for a maintainer re-upload with build artifacts
excluded).

unblock mesa/22.3.6-1



Hi,

There's actually 22.3.7 out, which I was thinking of uploading to sid, 
since it's the last release of the 22.3.x series. Maybe that should be 
requested to be unblocked instead once it's available?


--
t

Bug#1032984: libx11-6 version 2:1.8.4-2 regression

[Timo Aaltonen]

Stefan Schippers kirjoitti 15.3.2023 klo 10.23:

Package: libx11-6
Version: 2:1.8.4-2

I have frequent fvwm window manager crashes due to an assertion in 
libX11 that causes

a SIGABRT and window manager crash.
This bug is related to #1032379, if you go down to the thread it is 
triggered by the

same assertion.
I do not use a desktop environment, I just start X by using startx and 
use the fvwm2

window manager. The message printed from fvwm is:

fvwm: ../../src/xcb_io.c:626: _XAllocID: Assertion `ret != inval_id' 
failed.


I can reliably crash the window manager by doing some mouse actions in 
the root window

(minimize, maximize windows, resize windows).

I have reverted the following packages to 2:1.8.3-3 and no failures 
happen any more,

even after intensive stress tests:

libx11-6
libx11-data
libx11-dev
libx11-xcb-dev
libx11-xcb1

Backtrace of failed fvwm process follows.
Thank you.

Stefan

This is the backtrace of the failed fvwm process:

(gdb) run
Starting program: /usr/bin/fvwm
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 4851]
[Detaching after vfork from child process 4864]
Warning: Arg --fvwm-icons is obsolete and ignored
Python module python-xdg not found.fvwm: ../../src/xcb_io.c:626: 
_XAllocID: Assertion `ret != inval_id' failed.


Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44

44  ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x76ca9d2f in __pthread_kill_internal (signo=6, 
threadid=) at ./nptl/pthread_kill.c:78
#2  0x76c5aef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26

#3  0x76c45472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x76c45395 in __assert_fail_base
     (fmt=0x76db9a70 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
assertion=assertion@entry=0x77b75b2a "ret != inval_id", 
file=file@entry=0x77b75a9b "../../src/xcb_io.c", 
line=line@entry=626, function=function@entry=0x77b75ef0 "_XAllocID") 
at ./assert/assert.c:92
#5  0x76c53df2 in __GI___assert_fail (assertion=0x77b75b2a 
"ret != inval_id", file=0x77b75a9b "../../src/xcb_io.c", line=626, 
function=0x77b75ef0 "_XAllocID") at ./assert/assert.c:101

#6  0x77b02443 in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x77e56558 in XRenderCreatePicture () at 
/usr/lib/x86_64-linux-gnu/libXrender.so.1

#8  0x77f9e5b6 in  () at /usr/lib/x86_64-linux-gnu/libXft.so.2
#9  0x77f9ec95 in XftDrawGlyphs () at 
/usr/lib/x86_64-linux-gnu/libXft.so.2
#10 0x77f9f2ad in XftDrawStringUtf8 () at 
/usr/lib/x86_64-linux-gnu/libXft.so.2

#11 0x555ff843 in  ()
#12 0x555e6dfb in  ()
#13 0x555a5fff in  ()
#14 0x555a7ba4 in  ()
#15 0x55588dba in  ()
#16 0x5558c4eb in  ()
#17 0x5558c66c in  ()
#18 0x55600189 in  ()
#19 0x5560020f in  ()
#20 0x77add9da in XCheckIfEvent () at 
/usr/lib/x86_64-linux-gnu/libX11.so.6

#21 0x55600b62 in  ()
#22 0x55600cb7 in  ()
#23 0x5558d58a in  ()
#24 0x555bfb2f in  ()
#25 0x555a92ca in  ()
#26 0x555a9bf4 in  ()
#27 0x555c7f29 in  ()
#28 0x55589d43 in  ()
#29 0x5558c4eb in  ()
#30 0x5558c5e4 in  ()
#31 0x555674f7 in  ()
#32 0x76c4618a in __libc_start_call_main 
(main=main@entry=0x55565a90, argc=argc@entry=1, 
argv=argv@entry=0x7fffe4d8) at 
../sysdeps/nptl/libc_start_call_main.h:58
#33 0x76c46245 in __libc_start_main_impl (main=0x55565a90, 
argc=1, argv=0x7fffe4d8, init=, fini=, 
rtld_fini=, stack_end=0x7fffe4c8) at 
../csu/libc-start.c:381

#34 0x55568631 in  ()
(gdb)



Well, it still needs someone to file a bug upstream.


--
t

Bug#1032851: mesa: FTBFS in dirty env if clang-14 is installed

[Timo Aaltonen]

Oneric kirjoitti 12.3.2023 klo 22.11:

Source: mesa
Version: 23.0.0-1
Severity: normal

Hi,

when clang-14 but not clang-15 is installed while building mesa 23.0.0
on Sid (debuild -us -uc -i -b), the build fails about 60% in related to
bindgen and rusticl. (See further down for logged errors.)
If clang-15 is installed, the build succeeds regardless of clang-14 being
present or not. If no clang is installed at all, the build succeeds too.
In Sid clang-14 is currently the default for "clang", in experimental
it is already clang-15.

Given it also works with no clang (like when building the official
package) adding a dependency on clang-15 is probably not desirable
and I’m not sure what to do about it.
If nothing else, I hope this report can at least help
others figure out why they can't backport mesa.

Cheers
Oneric


Mesa already build-depends on several packages from llvm-15, so adding 
one more shouldn't matter much.



--
t

Bug#1005359: xserver-xorg-core: Intel HD Graphics 620: blank screen

[Timo Aaltonen]

Stefan Monnier kirjoitti 9.3.2023 klo 0.18:

Control: found -1 2:21.1.7-1

I still see this problem with the latest version on `testing`.


I'm sure the problem is in the kernel driver (i915) and not xserver.


--
t

Bug#1032379: bug#746: Killed when starting modale dialog like pinentry

[Timo Aaltonen]

Mark Hindley kirjoitti 8.3.2023 klo 12.33:

On Wed, Mar 08, 2023 at 11:26:37AM +0100, Klaus Ethgen wrote:

Maybe you can add this information to #1032379 and reassign?


I can prove it. If I revert the last update of libx11-6, libx11-data and
libx11-xcb1, everything works correct again.


Good work! Thanks.

Mark



please file this upstream and mention that it's a regression in 1.8.4

https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues

--
t

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

[Timo Aaltonen]

On 23.2.2023 13.29, Emmanuel Bourg wrote:

Source: tomcatjss
Version: 8.3.0-1
Severity: important

libtomcatjss-java uses libtomcat9-java but this package is about to be removed.
libtomcat10-java should be used instead.


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


--
t

Bug#1031815: [Pkg-freeipa-devel] Bug#1031815: pki-server: Migrate to Tomcat 10

[Timo Aaltonen]

On 23.2.2023 13.24, Emmanuel Bourg wrote:

Package: pki-server
Version: 11.2.1-2
Severity: important

pki-server uses tomcat9-user but this package is about to be removed.
tomcat10-user should be used instead.


Hi, surely not for bookworm though?


--
t

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Timo Aaltonen]

Timo Aaltonen kirjoitti 23.9.2022 klo 11.21:

Paul Gevers kirjoitti 22.9.2022 klo 22.26:

Hi,

On 22-09-2022 20:38, Salvatore Bonaccorso wrote:

I honestly don't know because I don't use this package, but I think
it might prevent the users using the bind-dyndb-ldap users from
upgrading the bind9 package.



Why is this binNMU actually needed? bind9-dyndb-ldap has the
following:

Depends: bind9-libs (>= 1:9.16.15), libc6 (>= 2.14), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.4-2 (>= 2.4.7), libuuid1 (>= 2.16), bind9 (>= 
9.11)


which is satisifed as well after the bind9 update via
bullseye-security, and updates are possible. Do your request imply
that the relationship would be too lax?


I think there was a change after the bullseye release. The package in 
unstable has a strict relation instead of a larger-or-equal relation:


Depends: bind9-libs (= 1:9.18.6-2), libc6 (>= 2.34), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.5-0 (>= 2.5.4), libuuid1 (>= 2.16), bind9 (>= 
9.11)


bind-dyndb-ldap (11.9-5) unstable; urgency=medium

   * support-9.18.diff: Fix build with bind9 9.18. (Closes: #1006014)
 - drop patches that aren't needed anymore with this
   * control, rules: Use a strict dependency on bind9-libs that the
 package was built against, in order to avoid bind9 updates breaking
 the package. (Closes: #1004729)

  -- Timo Aaltonen   Wed, 23 Feb 2022 13:17:07 +0200

So, Timo, is the package in bullseye broken with the security update 
and does it need a fix, or is it fine?


It needs a rebuild, because the bind9 library sonames get bumped every 
time the upstream version changes. That's why the silly strict 
dependencies were introduced in sid.


Ondrej, let's talk about merging bind-dyndb-ldap to src:bind9 for 
bookworm, I'm all for it ;)


I'm sure you've seen my MR #21 to add it there, but it got zero 
comments. I noticed afterwards that you had some concerns about shipping 
the GPL2 plugin alongside withe the MPL2 bind9, but is it really a problem?




--
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#1010636: [Pkg-freeipa-devel] Bug#1010636: dogtag-pki: please reduce unused Build-Depends

[Timo Aaltonen]

Helmut Grohne kirjoitti 5.5.2022 klo 22.40:

Source: dogtag-pki
Version: 11.0.3-4
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

dogtag-pki cannot be cross built from source, because its Build-Depends
are not satisfiable. The problems are numerous, so instead of looking
into them in detail, I looked for low hanging fruit: unused
Build-Depends. Since dogtag-pki is mostly reproducible (except for the
build path), there is a relatively easy technique for identifying unused
Build-Depends:
  * Build dogtag-pki
  * Build dogtag-pki with as many Build-Depends moved to Build-Conflicts
as possible while also passing DEB_BUILD_OPTIONS=nocheck. Use the
same build path.
  * Verify that both builds produce bit-identical results.

So that's what I did and the following dependencies could be moved to
Build-Conflicts:
  * libjaxp1.3-java
  * libxalan2-java
  * policycoreutils
  * python3-dev
  * python3-nss

Of course, Build-Conflicts is not the aim, but it ensures that the
packages are really gone and not pulled by some other dependency for the
purpose of testing. Then, disabling tests via DEB_BUILD_OPTIONS=nocheck
of course may have found test dependencies. And finally, packages may
contain pre-build artifacts that are only rebuilt when the relevant
build tools are available, so we cannot just delete these packages from
Build-Depends. Some will have to stay. Some may be annotated 
and some can be dropped.

Can I ask you to review each of the mentioned 5 dependencies? I'd hope
that all of them can be annotated  or dropped entirely.

Thanks in advance

Helmut


Hi, the others have been dropped from the version being prepared, but 
python3-dev is needed for dh_auto_test:


dh_auto_test: warning: warning: pybuild does not support building out of 
source tree. In source building enforced.
E: Please add appropriate interpreter package to Build-Depends, see 
pybuild(1) for details.this: $VAR1 = bless( {

 'py3def' => '3.11',
 'pyvers' => '',
 'pydef' => '',
 'builddir' => undef,
 'py3vers' => '3.10 3.11',
 'sourcedir' => '.',
 'cwd' => '/<>',
 'parallel' => '32'
   }, 'Debian::Debhelper::Buildsystem::pybuild' );
deps: $VAR1 = [
  'python3-cryptography',
  'python3-distutils',
  'python3-ldap',
  'python3-requests',
  'python3-setuptools',
  'python3-sphinx',
  'python3-urllib3'
];
make: *** [debian/rules:47: build] Error 25


--
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#1026768: vulkan-loader: please consider packaging version 1.3.238

[Timo Aaltonen]

Dylan Aïssi kirjoitti 9.1.2023 klo 10.48:

Hi,

On Tue, 3 Jan 2023 14:55:47 +0200 Timo Aaltonen  wrote:

Andrea Pappacoda kirjoitti 20.12.2022 klo 22.01:

By looking at <https://github.com/KhronosGroup/Vulkan-Loader/tags> it seems
that version 1.3.238 has been tagged with a "v" prefix, and not with an "sdk-"
one; this means that this version is still in development, right?


Correct, only sdk-releases have consistent tags across the stack
(including glslang, spirv-tools etc).


In the meantime, can we have the sdk-1.3.236.0 tag packaged? I would
need it to update gfxreconstruct to 0.9.16.1 in order to fix its FTBFS
issue. I can help if needed.


okay, pushed the branches, but build fails because it can't find the 
headers anymore, so if you have ideas how to fix that then that'd be 
great :)


--
t

Bug#1026768: vulkan-loader: please consider packaging version 1.3.238

[Timo Aaltonen]

Andrea Pappacoda kirjoitti 20.12.2022 klo 22.01:

Source: vulkan-loader
Version: 1.3.231.1-1
Severity: wishlist

Hi, could you please consider upgrading to version 1.3.238 when it is fully
released? It is currently needed by the latest release of yuzu[1], a package
I'm maintaining.

By looking at  it seems
that version 1.3.238 has been tagged with a "v" prefix, and not with an "sdk-"
one; this means that this version is still in development, right?


Correct, only sdk-releases have consistent tags across the stack 
(including glslang, spirv-tools etc).



--
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#1025760: ITP: level-zero -- oneAPI Level Zero

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: level-zero
  Version : 1.8.8
  Upstream Author : Intel
* URL : https://github.com/oneapi-src/level-zero
* License : MIT
  Programming Lang: C++
  Description : oneAPI Level Zero

 The oneAPI Level Zero (Level Zero) provides low-level direct-to-metal 
 interfaces that are tailored to the devices in a oneAPI platform. 
 Level Zero supports broader language features such as function pointers, 
 virtual functions, unified memory, and I/O capabilities while also 
 providing fine-grain explicit controls needed by higher-level runtime APIs.

Bug#948510: xserver-xorg-core: leaking open /dev/dri/card0 fds on vt switch, leading to lockup

[Timo Aaltonen]

Spiky Caterpillar kirjoitti 16.11.2022 klo 15.08:

Package: xserver-xorg-core
Version: 2:1.20.11-1+deb11u3
Followup-For: Bug #948510
X-Debbugs-Cc: spikycaterpillar_debian...@deekoo.net

The FD leak when switching VTs still occurs on the current stable version of
xserver-xorg-core.

To verify:
Start X, start an xterm
lsof -n|grep -c /dev/dri/card0
control-alt-functionkey to another terminal, then return to X
lsof -n|grep -c /dev/dri/card0


lspci shows the video card as
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Caicos XT [Radeon HD 7470/8470 / R5 235/310 OEM] (prog-if 00 [VGA controller])
 Subsystem: PC Partner Limited / Sapphire Technology Radeon R5 235 OEM
 Flags: bus master, fast devsel, latency 0, IRQ 46, IOMMU group 0
 Memory at c000 (64-bit, prefetchable) [size=256M]
 Memory at fea2 (64-bit, non-prefetchable) [size=128K]
 I/O ports at e000 [size=256]
 Expansion ROM at 000c [disabled] [size=128K]
 Capabilities: [50] Power Management version 3
 Capabilities: [58] Express Legacy Endpoint, MSI 00
 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
 Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 

 Capabilities: [150] Advanced Error Reporting
 Kernel driver in use: radeon
 Kernel modules: radeon


As before, patching it out seems to fix the problem.
diff --git a/hw/xfree86/os-support/linux/systemd-logind.c 
b/hw/xfree86/os-support/linux/systemd-logind.c
index 13784d1..9f196ef 100644
--- a/hw/xfree86/os-support/linux/systemd-logind.c
+++ b/hw/xfree86/os-support/linux/systemd-logind.c
@@ -417,9 +417,10 @@ message_filter(DBusConnection * connection, DBusMessage * 
message, void *data)
  /* info->vt_active gets set by systemd_logind_vtenter() */
  info->active = TRUE;
  
-if (pdev)

+if (pdev) {
+close(fd);
  pdev->flags &= ~XF86_PDEV_PAUSED;
-else
+} else
  systemd_logind_set_input_fd_for_all_devs(major, minor, fd,
   info->vt_active);




Hi, the only way to fix it for good is to send a MR upstream for review:

https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests



--
t

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#1022058: spirv-headers: Please upgrade to spirv-headers >=1.3.224

[Timo Aaltonen]

Timo Aaltonen kirjoitti 19.10.2022 klo 20.34:

Christopher Obbard kirjoitti 19.10.2022 klo 18.20:

Package: spirv-headers
Version: 1.6.1+1.3.216.0-1
Severity: normal

Dear Maintainer,

mesa 22.3 in debian-experimental FTBFS with the following tests
failing:

 Failed Tests (4):
 LLVM_SPIRV :: transcoding/AtomicFMaxEXT.ll
 LLVM_SPIRV :: transcoding/AtomicFMaxEXTForOCL.ll
 LLVM_SPIRV :: transcoding/AtomicFMinEXT.ll
 LLVM_SPIRV :: transcoding/AtomicFMinEXTForOCL.ll

Turns out we need to bump spirv-headers to >= 1.3.224 and make
sure llvm-spirv-translator gets built against that.



The tag for 1.3.224 is the same as .216, but there's .231 now.


I was wrong, it is branched but not tagged yet.


--
t

Bug#1022058: spirv-headers: Please upgrade to spirv-headers >=1.3.224

[Timo Aaltonen]

Christopher Obbard kirjoitti 19.10.2022 klo 18.20:

Package: spirv-headers
Version: 1.6.1+1.3.216.0-1
Severity: normal

Dear Maintainer,

mesa 22.3 in debian-experimental FTBFS with the following tests
failing:

 Failed Tests (4):
 LLVM_SPIRV :: transcoding/AtomicFMaxEXT.ll
 LLVM_SPIRV :: transcoding/AtomicFMaxEXTForOCL.ll
 LLVM_SPIRV :: transcoding/AtomicFMinEXT.ll
 LLVM_SPIRV :: transcoding/AtomicFMinEXTForOCL.ll

Turns out we need to bump spirv-headers to >= 1.3.224 and make
sure llvm-spirv-translator gets built against that.



The tag for 1.3.224 is the same as .216, but there's .231 now.


--
t

Bug#1021201: vulkan-loader: new upstream stable point release 1.3.224.1

[Timo Aaltonen]

Simon McVittie kirjoitti 3.10.2022 klo 18.43:

Source: vulkan-loader
Version: 1.3.224.0-1
Severity: wishlist

vulkan-loader is currently at upstream version 1.3.224.0, but upstream's
sdk-1.3.224 stable branch now has a 1.3.224.1 point release with these
release notes:


Enable layer interception of unknown functions

Re-add previously reverted behavior that allows layers to setup
dispatch chains for unknown physical device and device functions during
vkCreateInstance. Previously, functions not known to the loader could
not be queried by a layer during vkCreateInstance (when dispatch tables
should be setup). The change adds support for unknown functions in the
trampolines of vkGetInstanceProcAddr and vkGetPhysicalDeviceProcAddr.


If I'm reading correctly, this is a backport of part of
https://github.com/KhronosGroup/Vulkan-Loader/pull/999,
which seems to be a fix for bugs seen with the RenderDoc and
GFXReconstruct development tools.

 smcv



Only vulkan-validationlayers had actual changes in .1, -loader is 
unchanged. Is this what you're after?


git log1 sdk-1.3.224.0..sdk-1.3.224.1
2995230d4eb3aff (tag: sdk-1.3.224.1) tests: Add tests for VK_REMAINING_*
e78782f28adde30 layers: Fix VK_REMAINING_* on Z-Cull tracking
05199e2928e7c4b tests: Add test in OneTimeSubmit
4a8a6a14be9971c layers: Fix one-time-submit


--
t

Bug#1021199: ITP: rust-lru -- A LRU cache implementation

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rust-lru
  Version : 0.7.8
  Upstream Author : Jerome Froelich
* URL : https://github.com/jeromefroe/lru-rs.git
* License : MIT
  Programming Lang: Rust
  Description : A LRU cache implementation


Required by rust-concread.

Bug#1021195: ITP: rust-concread -- Concurrently readable datastructures for Rust

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rust-concread
  Version : 0.3.7
  Upstream Author : William Brown 
* URL : https://github.com/kanidm/concread/
* License : MPL-2.0
  Programming Lang: Rust
  Description : Concurrently readable datastructures for Rust


Required by new 389-ds-base.

Bug#1021191: ITP: rust-fernet -- An implementation of fernet in Rust

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: rust-fernet
  Version : 0.1.4
  Upstream Author : Alex Gaynor , Ben Bangert 

* URL : https://github.com/mozilla-services/fernet-rs/
* License : MPL-2.0
  Programming Lang: Rust
  Description : An implementation of fernet in Rust


Required by new 389-ds-base.

Bug#1020421: /usr/libexec/at-spi-bus-launcher: If I start some programs (i.e. gimp), system gets me out of the session and show me login again

[Timo Aaltonen]

Roberto kirjoitti 23.9.2022 klo 15.45:
Il giovedì 22 settembre 2022 15:00:02 CEST, Timo Aaltonen 
 ha scritto:



Samuel Thibault kirjoitti 22.9.2022 klo 15.38:
 > Control: reassign -1 mesa
 > Control: retitle -1 If I start some programs (i.e. gimp), system gets 
me out of the session and show me login again

 >
 > Roberto, le jeu. 22 sept. 2022 12:33:13 +, a ecrit:
 >> In the .old file I found:
 >> --
 >> [  1450.752] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not 
supported.

 >> Supported versions are: 1.10, 1.20, and 1.00 ES
 >> --
 >>
 >> I think this is the problem...
 >
 > That's a sign indeed. Thus reassigning to mesa for now.
 >
 > Samuel
 >

either use a wayland session, or install libgl1-amber-dri which has the
old i965 dri driver



--
t


Thank you Timo,

I use Mate and it doesn't support wayland

I'm trying to installlibgl1-amber-dri but I can't find it in debian repo 
and the only package I found is
libgl1-amber-dri_21.3.7-0ubuntu1_arm64.deb but it doesn't work with dpkg 
on debian

(it gives me " unknown compression for member 'control.tar.zst', giving up")

how can I install libgl1-amber-dri ?

Thanks in advance


sorry, my bad.. the upload to sid got rejected by the ftpadmin and needs 
to be fixed.


you can use the intel X driver in the meantime, that should be another 
workaround for this bug


--
t

Bug#1020413: nmu: bind-dyndb-ldap_11.6-3

[Timo Aaltonen]

Paul Gevers kirjoitti 22.9.2022 klo 22.26:

Hi,

On 22-09-2022 20:38, Salvatore Bonaccorso wrote:

I honestly don't know because I don't use this package, but I think
it might prevent the users using the bind-dyndb-ldap users from
upgrading the bind9 package.



Why is this binNMU actually needed? bind9-dyndb-ldap has the
following:

Depends: bind9-libs (>= 1:9.16.15), libc6 (>= 2.14), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.4-2 (>= 2.4.7), libuuid1 (>= 2.16), bind9 (>= 
9.11)


which is satisifed as well after the bind9 update via
bullseye-security, and updates are possible. Do your request imply
that the relationship would be too lax?


I think there was a change after the bullseye release. The package in 
unstable has a strict relation instead of a larger-or-equal relation:


Depends: bind9-libs (= 1:9.18.6-2), libc6 (>= 2.34), libkrb5-3 (>= 
1.6.dfsg.2), libldap-2.5-0 (>= 2.5.4), libuuid1 (>= 2.16), bind9 (>= 9.11)


bind-dyndb-ldap (11.9-5) unstable; urgency=medium

   * support-9.18.diff: Fix build with bind9 9.18. (Closes: #1006014)
     - drop patches that aren't needed anymore with this
   * control, rules: Use a strict dependency on bind9-libs that the
     package was built against, in order to avoid bind9 updates breaking
     the package. (Closes: #1004729)

  -- Timo Aaltonen   Wed, 23 Feb 2022 13:17:07 +0200

So, Timo, is the package in bullseye broken with the security update and 
does it need a fix, or is it fine?


It needs a rebuild, because the bind9 library sonames get bumped every 
time the upstream version changes. That's why the silly strict 
dependencies were introduced in sid.


Ondrej, let's talk about merging bind-dyndb-ldap to src:bind9 for 
bookworm, I'm all for it ;)



--
t

Bug#1020421: /usr/libexec/at-spi-bus-launcher: If I start some programs (i.e. gimp), system gets me out of the session and show me login again

[Timo Aaltonen]

Samuel Thibault kirjoitti 22.9.2022 klo 15.38:

Control: reassign -1 mesa
Control: retitle -1 If I start some programs (i.e. gimp), system gets me out of 
the session and show me login again

Roberto, le jeu. 22 sept. 2022 12:33:13 +, a ecrit:

In the .old file I found:
--
[  1450.752] Failed to compile FS: 0:1(10): error: GLSL 1.30 is not supported.
Supported versions are: 1.10, 1.20, and 1.00 ES
--

I think this is the problem...


That's a sign indeed. Thus reassigning to mesa for now.

Samuel



either use a wayland session, or install libgl1-amber-dri which has the 
old i965 dri driver



--
t

Bug#1020386: mesa: FTBFS on x32

[Timo Aaltonen]

Laurent Bigonville kirjoitti 20.9.2022 klo 23.13:

Source: mesa
Version: 21.0.0-1
Severity: important
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hello,

mesa currently FTBFS on x32, with the following errors:

dh_install -a
dh_install: warning: Cannot find (any matches for) 
"usr/share/drirc.d/00-radv-defaults.conf" (tried in ., debian/tmp)

dh_install: warning: mesa-vulkan-drivers missing files: 
usr/share/drirc.d/00-radv-defaults.conf
dh_install: error: missing files, aborting
make[1]: *** [debian/rules:228: override_dh_install] Error 25

That's probably happening because the amd vulkan driver is not built


..because there's no llvm for x32.

--
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#1016687: Clarification Needed

[Timo Aaltonen]

Dan Letzeisen kirjoitti 15.8.2022 klo 0.10:
I realize this is a tricky situation with dfsg, but is there any intent 
to fix this bug at Debian distro level or should we look at building our 
own mesa?


Also, the bug should be retitled. It doesn't just affect VA-API 
encoding. It affects VA-API/VDPAU/Vulkan decoding and encoding of the 
codecs in question.


Thank you



I don't think this can be enabled, since Debian does not allow 
distributing software encumbered by patents:


https://www.debian.org/legal/patent



--
t

Bug#1012067: [Pkg-freeipa-devel] Bug#1012067: Bug#1012067: Bug#1012067: jss: FTBFS with OpenJDK 17: no such provider SunJSSE

[Timo Aaltonen]

Timo Aaltonen kirjoitti 28.7.2022 klo 14.14:

Emmanuel Bourg kirjoitti 28.7.2022 klo 13.36:

Le 2022-07-28 09:49, Timo Aaltonen a écrit :


Rebuilding jss with openjdk 11 fails just the same way, so the failure
is not caused by jdk 17 but something else..


It seems to build fine with OpenJDK 11 on the reproducible build 
workers though:


https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jss.html 



ok, fails to build on my chroot


jss 5.2.0 would build with openjdk-17. I can build it with current 
kinetic, but not when kinetic-proposed is enabled. I believe this is 
caused by the new libnss3 3.81-1.





--
t

Bug#1012067: [Pkg-freeipa-devel] Bug#1012067: Bug#1012067: jss: FTBFS with OpenJDK 17: no such provider SunJSSE

[Timo Aaltonen]

Emmanuel Bourg kirjoitti 28.7.2022 klo 13.36:

Le 2022-07-28 09:49, Timo Aaltonen a écrit :


Rebuilding jss with openjdk 11 fails just the same way, so the failure
is not caused by jdk 17 but something else..


It seems to build fine with OpenJDK 11 on the reproducible build workers 
though:


https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/jss.html


ok, fails to build on my chroot


--
t

Bug#1012067: [Pkg-freeipa-devel] Bug#1012067: jss: FTBFS with OpenJDK 17: no such provider SunJSSE

[Timo Aaltonen]

Emmanuel Bourg kirjoitti 29.5.2022 klo 19.46:

Source: jss
Version: 5.1.0-1
Severity: important
Tags: ftbfs sid bookworm
User: debian-j...@lists.debian.org
Usertags: default-java17


jss fails to build with OpenJDK 17, there is an error during the tests
(because libfakeroot-sysv.so can't be loaded?)

   
   cd build && ctest --output-on-failure

   Test project /<>/build
 Start  1: Clean_Data_Dir
1/75 Test  #1: Clean_Data_Dir    Passed 
   0.01 sec
 Start  2: Create_Data_Dir
2/75 Test  #2: Create_Data_Dir ...   Passed 
   0.01 sec
 Start  3: Clean_Setup_DBs
3/75 Test  #3: Clean_Setup_DBs ...   Passed 
   0.01 sec
 Start  4: Create_Setup_DBs
4/75 Test  #4: Create_Setup_DBs ..   Passed 
   0.01 sec
 Start  5: Setup_DBs
5/75 Test  #5: Setup_DBs .   Passed 
   0.18 sec
 Start  6: Clean_FIPS_Setup_DBs
6/75 Test  #6: Clean_FIPS_Setup_DBs ..   Passed 
   0.01 sec
 Start  7: Create_FIPS_Setup_DBs
7/75 Test  #7: Create_FIPS_Setup_DBs .   Passed 
   0.01 sec
 Start  8: Setup_FIPS_DBs
8/75 Test  #8: Setup_FIPS_DBs    Passed 
   0.14 sec
 Start  9: TestBufferPRFD
9/75 Test  #9: TestBufferPRFD    Passed 
   0.00 sec
 Start 10: Test_UTF-8_Converter
   10/75 Test #10: Test_UTF-8_Converter ..   Passed 
   0.04 sec
 Start 11: Test_Base64_Parsing
   11/75 Test #11: Test_Base64_Parsing ...   Passed 
   0.03 sec
 Start 12: JSS_DER_Encoding_of_Enumeration_regression_test
   12/75 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...   Passed 
   1.68 sec
 Start 13: JSS_Test_DER_Encoding_Functionality
   13/75 Test #13: JSS_Test_DER_Encoding_Functionality ...   Passed 
   0.07 sec
 Start 14: JSS_Test_Empty_DER_Value
   14/75 Test #14: JSS_Test_Empty_DER_Value ..   Passed 
   0.03 sec
 Start 15: BigObjectIdentifier
   15/75 Test #15: BigObjectIdentifier ...   Passed 
   0.05 sec
 Start 16: JSS_Test_PR_FileDesc
   16/75 Test #16: JSS_Test_PR_FileDesc ..   Passed 
   0.06 sec
 Start 17: JSS_Test_Raw_SSL
   17/75 Test #17: JSS_Test_Raw_SSL ..   Passed 
   0.08 sec
 Start 18: JSS_Test_Buffer
   18/75 Test #18: JSS_Test_Buffer ...   Passed 
   0.06 sec
 Start 19: JSS_Test_GlobalRefProxy
   19/75 Test #19: JSS_Test_GlobalRefProxy ...   Passed 
   5.07 sec
 Start 20: JUnit_BMPStringTest
   20/75 Test #20: JUnit_BMPStringTest ...   Passed 
   0.26 sec
 Start 21: JUnit_IA5StringTest
   21/75 Test #21: JUnit_IA5StringTest ...   Passed 
   0.21 sec
 Start 22: JUnit_PrintableStringTest
   22/75 Test #22: JUnit_PrintableStringTest .   Passed 
   0.26 sec
 Start 23: JUnit_TeletexStringTest
   23/75 Test #23: JUnit_TeletexStringTest ...   Passed 
   0.18 sec
 Start 24: JUnit_UniversalStringTest
   24/75 Test #24: JUnit_UniversalStringTest .   Passed 
   0.29 sec
 Start 25: JUnit_UTF8StringTest
   25/75 Test #25: JUnit_UTF8StringTest ..   Passed 
   0.27 sec
 Start 26: buffer_size_1
   26/75 Test #26: buffer_size_1 .   Passed 
   0.00 sec
 Start 27: buffer_size_4
   27/75 Test #27: buffer_size_4 .   Passed 
   0.00 sec
 Start 28: JUnit_CertificateChainTest
   28/75 Test #28: JUnit_CertificateChainTest    Passed 
   0.25 sec
 Start 29: JUnit_ChainSortingTest
   29/75 Test #29: JUnit_ChainSortingTest    Passed 
   0.24 sec
 Start 30: Generate_known_RSA_cert_pair
   30/75 Test #30: Generate_known_RSA_cert_pair ..   Passed 
   3.87 sec
 Start 31: Generate_known_ECDSA_cert_pair
   31/75 Test #31: Generate_known_ECDSA_cert_pair    Passed 
   0.48 sec
 Start 32: Create_PKCS11_cert_to_PKCS12_rsa.pfx
   32/75 Test #32: Create_PKCS11_cert_to_PKCS12_rsa.pfx ..   Passed 
   1.80 sec
 Start 33: Create_PKCS11_cert_to_PKCS12_ecdsa.pfx
   33/75 Test #33: Create_PKCS11_cert_to_PKCS12_ecdsa.pfx    Passed 
   1.51 sec
 Start 34: List_CA_certs
   34/75 Test #34: List_CA_certs .   Passed 
   0.15 sec
 Start 35: SSLClientAuth
   35/75 Test #35: 

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#1011952: mesa: FTBFS on kfreebsd

[Timo Aaltonen]

Laurent Bigonville kirjoitti 27.5.2022 klo 18.43:

Source: mesa
Version: 22.1.0~rc5-1
Severity: important
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
Forwarded: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4081

Hello,

mesa currently FTBFS on kfreebsd

The attached patch seems to fix this

The patch has been propsed upstream

Could you please apply that patch?



Is disabling gallium-extra-hud a part of the fix?


--
t

Bug#980542: [Pkg-freeipa-devel] Bug#980542: cockpit : 389ds tab is empty and does not appear in installed applications

[Timo Aaltonen]

Andreas Bock kirjoitti 20.5.2022 klo 16.06:
I can confirm this bug for Ubuntu Jammy and kinetic. All files are 
missing in '/usr/share/cockpit/389-console'.


Already posted this in Ubuntu Launchpad as 
https://bugs.launchpad.net/ubuntu/+source/389-ds-base/+bug/1974329:


What happend:
After installing the server and afterwards the '389-ds' package 
including all dependencies, Cockpit lacks the plugins entry "389 
Directory Server" in the Web-GUI.


How to reproduce:
I installed Ubuntu server 22.04 multiple times from scratch. Either as 
minimal but althought as default installation does not help. After lots 
of testing and reinstalling the server I found that all files from 
'/usr/share/cockpit/389-console' are missing for the jammy and kinetic 
package 'cockpit-389-ds'. If one compares the package content to focal 
one will see the difference.


What I have done to resolve the issue:
$ wget 
https://github.com/389ds/389-ds-base/archive/389-ds-base-2.0.15.tar.gz

$ tar xzf 389-ds-base-2.0.15.tar.gz
$ cd ~/389-ds-base-2.0.15/src/cockpit/389-console
$ sh ./buildAndRun.sh # Stop the script after downloading and compling 
with ^C
$ sudo cp ~/389-ds-base-2.0.15/src/cockpit/389-console/dist/* 
/usr/share/cockpit/389-console




If you have any further questions feel free to contact me.

Regards, Andreas


Thanks for the hint, the tarballs stopped having prebuilt files for 
cockpit when 389 migrated to github. This is now being tracked at:


https://github.com/389ds/389-ds-base/issues/5302



--
t

Bug#1010337: move /usr/bin/luit to its own package

[Timo Aaltonen]

Harald Dunkel kirjoitti 29.4.2022 klo 10.30:

Package: x11-utils
Version: 7.7+5

Hi folks,

If I set

 XTerm*locale: true

then xterm requires /usr/bin/luit, which can be found in x11-utils.
x11-utils puts appr 150 MByte additional files and directories into
/, even if Install-Recommends is set to false.

Would it be possible to move luit to its own package, reducing the
footprint of xterm for strict UTF-8 support? Actually luit is not
even an XWindow program:

 % ldd /usr/bin/luit
     linux-vdso.so.1 (0x7fff0cda2000)
     libfontenc.so.1 => /usr/lib/x86_64-linux-gnu/libfontenc.so.1 
(0x7f62f4d03000)

     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f62f4b3e000)
     libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f62f4b21000)
     /lib64/ld-linux-x86-64.so.2 (0x7f62f4d3d000)



Regards

Harri



almost done, see 1006193


--
t

Bug#1008668: bug #1008668: tomcat9: logrotated is not able to truncate catalina.out

[Timo Aaltonen]

Evren Yurtesen kirjoitti 29.4.2022 klo 8.42:

One solution would be undoing 
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/388608 at Ubuntu. But I 
do not know how to reach to correct people at Ubuntu side. I also do not think 
I could convince them that this is creating problems.


try ubuntu-ser...@lists.ubuntu.com, or -devel-discuss


--
t

Bug#1009995: x11-xkb-utils: xkbcomp gives a warning for keysym XF86EmojiPicker from symbols/inet

[Timo Aaltonen]

Vincent Lefevre kirjoitti 22.4.2022 klo 5.00:

Package: x11-xkb-utils
Version: 7.7+6
Severity: normal

Consider

zira:~> cat .xkb/keymap/test
xkb_keymap {
 xkb_keycodes  { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete"  };
 xkb_compat{ include "complete"  };
 xkb_symbols   { include "pc+gb+inet(evdev)" };
 xkb_geometry  { include "pc(pc105)" };
};

(the "+inet(evdev)" is important).

I get the following warning:

zira:~> xkbcomp -w 0 -I$HOME/.xkb -R$HOME/.xkb keymap/test xkb.dump
Warning:  Could not resolve keysym XF86EmojiPicker

The issue probably comes from

zira:~> grep -r XF86EmojiPicker /usr/share/X11/xkb
/usr/share/X11/xkb/symbols/inet:   key{   [ XF86EmojiPicker   
 ]  }; // KEY_EMOJI_PICKER

This file is provided by xkb-data (current version 2.35.1-1).
So there's something wrong between x11-xkb-utils and xkb-data
(similar to bug 953032 / 994036).

Note: about the fact that I get this warning with "-w 0" is
the following bug, which I've just reported:
   https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/20
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1009994

Once this bug is fixed, this could be tested without the "-w 0".

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

Kernel: Linux 5.17.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages x11-xkb-utils depends on:
ii  libc62.33-7
ii  libx11-6 2:1.7.5-1
ii  libxaw7  2:1.0.14-1
ii  libxkbfile1  1:1.1.0-1
ii  libxrandr2   2:1.5.2-1
ii  libxt6   1:1.2.1-1

x11-xkb-utils recommends no packages.

x11-xkb-utils suggests no packages.

-- no debconf information



Before 7.7+6 you'd get an error instead of a warning, and the warning 
isn't going away until x11proto is updated and libx11 built against it. 
But these warnings happen when stuff gets updated independently, so I 
don't consider it a bug.



--
t

Bug#1009223: [Pkg-sssd-devel] Bug#1009223: Bug#1009223: sssd fails on startup: Module [memberof] not found - do you need to set LDB_MODULES_PATH

[Timo Aaltonen]

Timo Aaltonen kirjoitti 9.4.2022 klo 16.01:

Troy Telford kirjoitti 9.4.2022 klo 10.13:

Package: sssd
Version: 2.6.3-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


After upgrading, sssd wouldn't run - running in interactive/debug mode 
was somewhat helpful: 'sssd -i -d1' would give the message:
(2022-04-09  0:45:09): [sssd] [ldb] (0x0010): WARNING: Module 
[memberof] not found - do you need to set LDB_MODULES_PATH?


This eventually lead to a search for memberof.so, which is in 
/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so


As hinted at, setting 
LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before 
running 'sssd -i -d1' allowed sssd to run.


I was able to apply a workaround by simply modifying the various 
systemd unit files (sssd-autofs.service sssd-nss.service 
sssd-pam.service sssd-ssh.service sssd-ifp.service sssd-pac.service 
sssd.service sssd-sudo.service in my case) to add:

Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"

Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am 
back up and running. I'm pretty sure there's a better way to inform 
the binaries where the LDB_MODULES_PATH is than having to update the 
environment modules at runtime -- I've definitely forgotten it, 
though. I also wouldn't be surprised if I may need to do something 
similar for the socket unit files for systemd -- but it's late & I'm 
tired...


The reason if fails is probably that libldb got a new version and sssd 
needs a rebuild. Could you try building the current package against 
current samba?


oh well, it actually fails to build now, so I need to fix that anyway


--
t

Bug#1009223: [Pkg-sssd-devel] Bug#1009223: sssd fails on startup: Module [memberof] not found - do you need to set LDB_MODULES_PATH

[Timo Aaltonen]

Troy Telford kirjoitti 9.4.2022 klo 10.13:

Package: sssd
Version: 2.6.3-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

After upgrading, sssd wouldn't run - running in interactive/debug mode was 
somewhat helpful: 'sssd -i -d1' would give the message:
(2022-04-09  0:45:09): [sssd] [ldb] (0x0010): WARNING: Module [memberof] not 
found - do you need to set LDB_MODULES_PATH?

This eventually lead to a search for memberof.so, which is in 
/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/memberof.so

As hinted at, setting 
LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb" before running 
'sssd -i -d1' allowed sssd to run.

I was able to apply a workaround by simply modifying the various systemd unit 
files (sssd-autofs.service sssd-nss.service sssd-pam.service sssd-ssh.service 
sssd-ifp.service sssd-pac.service sssd.service sssd-sudo.service in my case) to 
add:
Environment=LDB_MODULES_PATH="/usr/lib/x86_64-linux-gnu/ldb/modules/ldb/"

Then I ran 'systemctl daemon-reload; systemctl start sssd' and I am back up and 
running. I'm pretty sure there's a better way to inform the binaries where the 
LDB_MODULES_PATH is than having to update the environment modules at runtime -- 
I've definitely forgotten it, though. I also wouldn't be surprised if I may need to 
do something similar for the socket unit files for systemd -- but it's late & 
I'm tired...


The reason if fails is probably that libldb got a new version and sssd 
needs a rebuild. Could you try building the current package against 
current samba?



--
t

Bug#1009027: mesa: Please enable these new drivers and features available since mesa 22

[Timo Aaltonen]

Emma Anholt kirjoitti 7.4.2022 klo 22.41:

VULKAN_DRIVERS
- panfrost (there is already a gallium driver for this)


ok


panvk is very much not ready for use and shouldn't be packaged.


thanks, won't add it then


--
t

Bug#1009027: mesa: Please enable these new drivers and features available since mesa 22

[Timo Aaltonen]

Fabio Pedretti kirjoitti 6.4.2022 klo 11.34:

Source: mesa
Version: 22.0.1-2
Severity: wishlist
X-Debbugs-Cc: pedretti.fa...@gmail.com

Dear Maintainer,

please consider enablig the following new drivers and features available
since mesa 22:

GALLIUM_DRIVERS
- asahi (driver for Apple M1)


I'm assuming this is for arm64?


- i915 (new i915 gallium driver, replaces old i915 classic driver)


If both i915g and i915 classic (from mesa-amber) are installed, which 
one is used?



VULKAN_DRIVERS
- panfrost (there is already a gallium driver for this)


ok


confflags_VULKAN
- intel-nullhw (this layer disables all rendering & compute commands in the
command parsing HW. It can be useful to identify CPU bottlenecks.)


ok


--
t

Bug#1008583: [Pkg-sssd-devel] Bug#1008583: python3-sss dependencies cannot be satisfied

[Timo Aaltonen]

pe...@chubb.wattle.id.au kirjoitti 29.3.2022 klo 7.50:


Package: python3-sss
Version: 2.4.1-2


When I try to install sssd, I see:

   Some packages could not be installed. This may mean that you have
   requested an impossible situation or if you are using the unstable
   distribution that some required packages have not yet been created
   or been moved out of Incoming.
   The following information may help to resolve the situation:

   The following packages have unmet dependencies:
 python3-ldb : Depends: python3 (< 3.10) but 3.10.4-1 is to be installed
 python3-sss : Depends: python3 (< 3.10) but 3.10.4-1 is to be installed


python3-sss in sid or bookworm depends on a python version that is no
longer available for bookwork or sid.


so python-defaults was changed, but ldb was never built against it, so 
sssd can't build either (python3-ldb has the same dep issue)



--
t

Bug#1008195: [Pkg-freeipa-devel] Bug#1008195: marked as done (Joining a domain fails on chrony.service in all scenarios)

[Timo Aaltonen]

Hi, and thanks for tracking it down :)

I guess freeipa upstream should support systemd-timesyncd, if it's "good 
enough". Or freeipa-client package should add a Conflicts for it, for 
now. I'll think about it.



--
t

Bug#834233: [Pkg-freeipa-devel] Bug#834233: Bug#915510: Removed package(s) from unstable

[Timo Aaltonen]

Petter Reinholdtsen kirjoitti 17.3.2022 klo 12.30:

Control: forward -1 https://github.com/389ds/389-ds-base/issues/1912

The old fedorahosted ticked now point to
https://github.com/389ds/389-ds-base/issues/1912 > as the new
upstream issue, and this issue is marked as closed.  No idea which
version closes the issue.



It was closed as "wontfix".


--
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#1006202: ITP: mesa-amber -- Legacy DRI modules and vendor libraries

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: mesa-amber
  Version : 21.3.6
  Upstream Author : various
* URL : https://mesa3d.org/
* License : MIT
  Programming Lang: C
  Description : Legacy DRI modules and vendor libraries


Mesa 22.0 drops non-gallium DRI modules, so 21.3-branch will be made a LTS 
branch for
legacy hardware.

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#909436: libdrm: FTBFS on hurd-i386 (#909436, updated and new patches)

[Timo Aaltonen]

Svante Signell kirjoitti 11.2.2022 klo 23.22:

On Tue, 2022-01-18 at 17:46 +0100, Svante Signell wrote:

Hello again,

libdrm still FTBFS on GNU/Hurd, now at 2.4.109-2. Attached are two
updated patches, hurd-port.diff and path_max.diff and two new ones.
hurd_port.diff, path_max.diff, tests_amdgpu_ras_tests.c.diff and
tests_amdgpu_amdgpu_test.c.diff.

The above patches will be submitted to upstream in due time.  For
completeness they are attached here, and as they were not included in
the email announcing them, dated 06 Dec 2021.


The patches are now submitted to
https://gitlab.freedesktop.org/mesa/drm/-/issues/24

Would this be enough to make upstream aware, or is something else
needed, like a merge request?

Thanks!



A merge request would be better, it allows code review etc.

--
t

Bug#1005347: ITP: onevpl-intel-gpu -- Intel oneVPL GPU Runtime

[Timo Aaltonen]

Package: wnpp
Severity: wishlist
Owner: Timo Aaltonen 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: onevpl-intel-gpu
  Version : 22.2.0
  Upstream Author : Intel
* URL : https://github.com/oneapi-src/oneVPL-intel-gpu
* License : MIT
  Programming Lang: C, C++
  Description : Intel oneVPL GPU Runtime

 Intel oneVPL GPU Runtime is a Runtime implementation of oneVPL
 API for Intel Gen GPUs. Runtime provides access to hardware-accelerated
 video decode, encode and filtering.

 Supported video encoders: HEVC, AVC, MPEG-2, JPEG, VP9  
 Supported video decoders: HEVC, AVC, VP8, VP9, MPEG-2, VC1, JPEG, AV1  
 Supported video pre-processing filters: Color Conversion, Deinterlace, Denoise,
 Resize, Rotate, Composition  

Bug#1005170: xserver-xorg-video-nouveau: corrupted display on GT218 [GeForce 210] since Firefox 91 ESR

[Timo Aaltonen]

Martin-Éric Racine kirjoitti 8.2.2022 klo 18.59:

On Tue, Feb 8, 2022 at 4:02 PM Martin-Éric Racine
 wrote:


On Tue, Feb 8, 2022 at 3:54 PM Timo Aaltonen  wrote:


Martin-Éric Racine kirjoitti 8.2.2022 klo 14.09:
  > Package: xserver-xorg-video-nouveau
  > Version: 1:1.0.17-1
  > Severity: important
  >

Since ESR 91 replaced ESR 78 in Stable, Firefox randomly triggers nasty bugs in 
nouveau. The content in Firefox gets randomly garbled for several minutes then 
suddenly gets cleaned up. This is highly problematic, since I use the browser 
to access government sites and having to close Firefox and logon again seldom 
is an option.

dmesg shows the following:

[133514.948849] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1510 data 
[133613.222007] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133624.336810] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133635.477428] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133700.776172] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133716.072659] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133716.355210] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355219] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12e4 data 
[133716.355232] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355236] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1360 data 
[133716.355247] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355250] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 19c4 data 
[133716.355264] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355267] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1a00 data 
[133716.355279] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355283] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12e8 data 
[133716.355296] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355299] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12cc data 
[133716.355312] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355315] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 19bc data 
[133716.355328] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355332] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1380 data 
[133716.355360] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355363] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1594 data 
[133716.355380] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355384] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12ec data 
[133716.355400] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355403] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12d4 data 1d01
[133716.355419] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355422] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1688 data 
[133716.355438] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355442] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1534 data 
[133716.355458] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355461] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 13b0 data 
[133716.355477] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355481] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1570 data 
[133716.355498] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355502] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 166c data 
[133716.355518] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355521] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1518 data 
[133716.355537] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355540] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1520 data 
[133716.37] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355560] nouveau :01:00.0: 

Bug#1005170: xserver-xorg-video-nouveau: corrupted display on GT218 [GeForce 210] since Firefox 91 ESR

[Timo Aaltonen]

Martin-Éric Racine kirjoitti 8.2.2022 klo 14.09:
> Package: xserver-xorg-video-nouveau
> Version: 1:1.0.17-1
> Severity: important
>

Since ESR 91 replaced ESR 78 in Stable, Firefox randomly triggers nasty bugs in 
nouveau. The content in Firefox gets randomly garbled for several minutes then 
suddenly gets cleaned up. This is highly problematic, since I use the browser 
to access government sites and having to close Firefox and logon again seldom 
is an option.

dmesg shows the following:

[133514.948849] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1510 data 
[133613.222007] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133624.336810] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133635.477428] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133700.776172] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133716.072659] nouveau :01:00.0: Xorg[1785]: nv50cal_space: -16
[133716.355210] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355219] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12e4 data 
[133716.355232] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355236] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1360 data 
[133716.355247] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355250] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 19c4 data 
[133716.355264] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355267] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1a00 data 
[133716.355279] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355283] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12e8 data 
[133716.355296] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355299] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12cc data 
[133716.355312] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355315] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 19bc data 
[133716.355328] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355332] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1380 data 
[133716.355360] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355363] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1594 data 
[133716.355380] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355384] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12ec data 
[133716.355400] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355403] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 12d4 data 1d01
[133716.355419] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355422] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1688 data 
[133716.355438] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355442] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1534 data 
[133716.355458] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355461] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 13b0 data 
[133716.355477] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355481] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1570 data 
[133716.355498] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355502] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 166c data 
[133716.355518] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355521] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1518 data 
[133716.355537] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355540] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1520 data 
[133716.37] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355560] nouveau :01:00.0: gr: 0010 [] ch 3 [003fa24000 
Xorg[1785]] subc 3 class 8597 mthd 1658 data 
[133716.355576] nouveau :01:00.0: gr: DATA_ERROR 000d [BEGIN_END_ACTIVE]
[133716.355580] 

Bug#1005068: transition (unplanned?): libwacom9

[Timo Aaltonen]

Sebastian Ramacher kirjoitti 7.2.2022 klo 11.38:

On 2022-02-07 10:48:01, Timo Aaltonen wrote:

Simon McVittie kirjoitti 7.2.2022 klo 3.17:

On Mon, 07 Feb 2022 at 00:51:08 +, Marius Gripsgard wrote:

The ABI/API breakage is not *too* bad, see [0]. just hope none use those
deprecated APIs

[0] 
https://github.com/linuxwacom/libwacom/commit/b4f3c3f855a68e35b5ebfc305bc67c565f9146c7


Thanks. Looks like nobody should have been using those symbols anyway
(the commit message says they were private and not mentioned in any public
header files), and codesearch.debian.net does not find any references
outside src:libwacom, so it should be safe to binNMU dependent packages.

  smcv



Right, should've asked for a transition.

Filed nmu's for wacomtablet and cinnamon-settings-daemon, libinput rebuild
upload I did myself.


If there's a transition bug, there is no need to file individual
requests for nmus.

Cheers


Oh, sorry about those then. I thought there was something I had to do to 
fix this mess..


I'll upload a source-only libwacom later, thanks.


--
t

Bug#1005100: nmu: muffin_5.2.0-2

[Timo Aaltonen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu


New libwacom bumped the SONAME, but simple rebuilds should be enough for the 
transition,
because most of the API was not really public anyway.

nmu muffin_5.2.0-2 . ANY . unstable . -m "Rebuild against libwacom9."

Bug#1005098: nmu: gnome-control-center_1:41.2-2

[Timo Aaltonen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu


New libwacom bumped the SONAME, but simple rebuilds should be enough for the 
transition,
because most of the API was not really public anyway.

nmu gnome-control-center_1:41.2-2 . ANY . unstable . -m "Rebuild against 
libwacom9."

Bug#1005097: nmu: ukwm_1.2.0-1

[Timo Aaltonen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu


New libwacom bumped the SONAME, but simple rebuilds should be enough for the 
transition,
because most of the API was not really public anyway.

nmu ukwm_1.2.0-1 . ANY . unstable . -m "Rebuild against libwacom9."

Bug#1005096: nmu: cinnamon-control-center_5.2.1-1

[Timo Aaltonen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu


New libwacom bumped the SONAME, but simple rebuilds should be enough for the 
transition,
because most of the API was not really public anyway.

nmu cinnamon-control-center_5.2.1-1 . ANY . unstable . -m "Rebuild against 
libwacom9."

Bug#1005095: nmu: gnome-settings-daemon_41.0-4

[Timo Aaltonen]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu


New libwacom bumped the SONAME, but simple rebuilds should be enough for the 
transition,
because most of the API was not really public anyway.

nmu gnome-settings-daemon_41.0-4 . ANY . unstable . -m "Rebuild against 
libwacom9."