Re: Zig on core-updates
They just added a tag for the next release. We can wait. On Mon, Apr 10, 2023 at 05:56:52PM +0200, Andreas Enge wrote: > Am Fri, Mar 17, 2023 at 09:33:31AM + schrieb pukkamustard: > > A hunch: This might have something to do with Zig not properly > > supporting glibc 2.35: https://github.com/ziglang/zig/issues/12808 > > Thanks, this looks like a good explanation of the problem, but I do not > quite see what could be a solution... I see a string of issues of the form > "add support for targeting glibc ..." >https://github.com/ziglang/zig/issues/12808 >https://github.com/ziglang/zig/issues/12809 >https://github.com/ziglang/zig/issues/14798 > but all of them are open. > > We may have to do without zig in the foreseeable future... > > Andreas > >
Re: [gnome-team] gtk+ on core-updates
Hi Andreas,
Andreas Enge writes:
> Am Sun, Apr 09, 2023 at 12:57:34PM -0400 schrieb Maxim Cournoyer:
>> OK, that's been fixed in meson-build-system; I've taken that opportunity
>> to update our meson package to its latest 1.0.1 release too.
>
> Great, thanks a lot! The KDE package and the Gnome package I have in my
> profile now build, and I hope the best for all of Gnome (which is not yet
> available on the build farm).
>
> However, there is a problem with meson-python, which for some reason is
> needed for my system profile:
>
> tests/test_wheel.py::test_configure_data FAILED [
> 94%]
> === FAILURES
> ===
> _ test_configure_data
> __
>
> wheel_configure_data =
> PosixPath('/tmp/guix-build-meson-python-0.8.1.drv-0/pytest-of-nixbld/pytest-0/test0/mesonpy-test-5dncnze6/configure_data-1.0.0-py3-none-any.whl')
>
> def test_configure_data(wheel_configure_data):
> artifact = wheel.wheelfile.WheelFile(wheel_configure_data)
>
>> assert wheel_contents(artifact) == {
> 'configure_data-1.0.0.data/platlib/configure_data.py',
> 'configure_data-1.0.0.dist-info/METADATA',
> 'configure_data-1.0.0.dist-info/RECORD',
> 'configure_data-1.0.0.dist-info/WHEEL',
> }
> E AssertionError: assert {'configure_data-1.0.0.dist-info/METADATA',\n
> 'configure_data-1.0.0.dist-info/RECORD',\n
> 'configure_data-1.0.0.dist-info/WHEEL',\n 'configure_data.py'} ==
> {'configure_data-1.0.0.data/platlib/configure_data.py',\n
> 'configure_data-1.0.0.dist-info/METADATA',\n
> 'configure_data-1.0.0.dist-info/RECORD',\n
> 'configure_data-1.0.0.dist-info/WHEEL'}
> E Extra items in the left set:
> E 'configure_data.py'
> E Extra items in the right set:
> E 'configure_data-1.0.0.data/platlib/configure_data.py'
> E Full diff:
> E {
> E - 'configure_data-1.0.0.data/platlib/configure_data.py',
> E'configure_data-1.0.0.dist-info/METADATA',
> E'configure_data-1.0.0.dist-info/RECORD',
> E'configure_data-1.0.0.dist-info/WHEEL',
> E + 'configure_data.py',
> E }
>
> tests/test_wheel.py:103: AssertionError
> Captured stdout setup
> -
>
> Not very telling for someone who does not know meson!
I don't know meson that much either, but I've updated the package to its
latest 0.12.1 version, and it passes it's test suite, so we should be
good!
--
Thanks,
Maxim
[bug#62760] [PATCH 0/3] Two serious vulnerabilities in Heimdal Kerberos
Hi, This patch series addresses two serious vulnerabilities in Heimdal, which is an implementation of the Kerberos protocol and therefore a security-relevant package. First, the version being shipped currently in Guix suffers from "a severe vulnerability, possibly a 10.0 on the Common Vulnerability Scoring System (CVSS) v3." The upstream developers "believe it should be possible to get an RCE [remote code execution] on a KDC, which means that credentials can be compromised that can be used to impersonate anyone in a realm or forest of realms." "While no zero-day exploit is known, such an exploit will likely be available soon after public disclosure." [1] Second, all recent upstream releases (but not the development branch) suffer from a serious backporting error that NIST scored at a "7.5 HIGH". That issue is being patched here. [2] Finally, we enabled OpenLDAP support for the principals database (which is different from using LDAP for user authorization) and modified the inputs to be more in line with Debian packaging. The packaging presented here passed some cursory testing for basic client and server functionality locally, but that version did not include the patch for CVE-2022-45142 because I did not know how to add it to my custom channel. Kind regards Felix Lechner [1] https://github.com/heimdal/heimdal/releases/tag/heimdal-7.8.0 [2] https://www.openwall.com/lists/oss-security/2023/02/08/1 * * * Felix Lechner (3): gnu: heimdal: Update to 7.8.0. gnu: heimdal: Patch for CVE-2022-45142. gnu: heimdal: Enable OpenLDAP support; converge inputs toward Debian packaging. gnu/packages/kerberos.scm | 25 +++--- .../patches/heimdal-CVE-2022-45142.patch | 49 +++ 2 files changed, 68 insertions(+), 6 deletions(-) create mode 100644 gnu/packages/patches/heimdal-CVE-2022-45142.patch base-commit: b08cdfc6d363e9ca63118303b4628542c54a612d -- 2.39.2
Re: Fix for librsvg 2.40 on core-updates
Hi Kaelyn, On Mon, Apr 10, 2023 at 12:00 PM Kaelyn wrote: > > I also forgot to set the subject prefix to "PATCH core-updates" I took the liberty to retitle the bug for you. [1] (The exclamation error, in turn, was an error on my part.) You can do it too, via the Debbugs control server. [2] Kind regards Felix Lechner [1] https://debbugs.gnu.org/cgi/bugreport.cgi?msg=10;bug=62758 [2] https://debbugs.gnu.org/server-control.html
Re: Fix for librsvg 2.40 on core-updates
--- Original Message --- On Saturday, April 8th, 2023 at 3:55 PM, Kaelyn wrote: > > --- Original Message --- > On Saturday, April 8th, 2023 at 9:52 AM, Andreas Enge andr...@enge.fr wrote: > > > > > Hello, > > > > Am Fri, Apr 07, 2023 at 04:53:15PM + schrieb Kaelyn: > > > > > On core-updates, librsvg-2.40 fails to compile due to a single failing > > > test (I've confirmed the failure on x86_64 and i686, though the package > > > is only used/needed on non-x86_64 systems for gtk+ and others; it also > > > affects wine and wine-staging on x86_64 as they are 32-bit packages). I > > > was able to track down the test failure to a text rendering difference > > > between Pango 1.48 and 1.50, which led to the text being one pixel line > > > higher between the reference and output images. On Monday I submitted > > > https://issues.guix.gnu.org/62646 which adds a phase to librsvg-2.40 to > > > adjust the output Y coordinate of the SVG transformation matrix by one > > > for the failing test so that it passes with Pango 1.50. > > > > thanks a lot, I added a copyright line for you and pushed. > > > Thank you! (I often forget the copyright line, so thanks for that as well.) > > > Wine still fails to build due to autogen not building on i686: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts > > -DPKGDATADIR=\"/gnu/store/6i60j0fxdsg4qwymas4ymfqlv1azidnc-autogen-5.18.16/share/autogen\" > > -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror > > -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow > > -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra > > -Wno-cast-qual -g -O2 -Wno-format-contains-nul -fno-strict-aliasing -c > > libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o > > In file included from libopts.c:48: > > usage.c: In function ‘prt_extd_usage.isra’: > > usage.c:736:38: error: ‘s ’ directive output may be truncated writing 2 > > bytes into a region of size between 0 and 9 [-Werror=format-truncation=] > > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > > | ^~~ > > usage.c:736:9: note: ‘snprintf’ output between 9 and 18 bytes into a > > destination of size 12 > > 736 | snprintf(vfmt, sizeof(vfmt), vfmtfmt, (unsigned int)nmlen + 4); > > | ^~ > > > > Just in case you wish to continue investigating :) > > > I probably will. :) My goal has been to build my home and system profiles > from core-updates, including wine64-staging. I just mailed https://issues.guix.gnu.org/62758 to add a snippet to fix the build error. I used a similar approach as the existing snippet for fixing a format overflow error. (I also forgot to set the subject prefix to "PATCH core-updates" on the git send-mail command line.). Cheers, Kaelyn
Re: GOOPS-less Shepherd
jbra...@dismail.de writes: > April 8, 2023 8:54 PM, "Ivan Sokolov" wrote: > >> Bodertz writes: >> >>> I don't have strong feelings either way, and the change won't really >>> affect me too much, but what benefit is there in breaking things? From >>> what I understand from your message, users' configs will stop working in >>> a few months when 1.0.x releases (or with the macro would "kinda work"), >>> which is at least a short-term con, so what's the long-term benefit of >>> this change? Is GOOPS so bad a thing to require? >> >> If I understand correctly, that will allow Shepherd to run on GNU Mes, >> a Scheme interpreter written for Guix bootstraping. > > So by removing the Shepherd's dependency on GNU Mes, the Guix project > benefits by simplying its bootstrapping process? Where did this come from? No, Mes is not a Shepherd's dependency, please read the quotes again.
Re: Zig on core-updates
Am Fri, Mar 17, 2023 at 09:33:31AM + schrieb pukkamustard: > A hunch: This might have something to do with Zig not properly > supporting glibc 2.35: https://github.com/ziglang/zig/issues/12808 Thanks, this looks like a good explanation of the problem, but I do not quite see what could be a solution... I see a string of issues of the form "add support for targeting glibc ..." https://github.com/ziglang/zig/issues/12808 https://github.com/ziglang/zig/issues/12809 https://github.com/ziglang/zig/issues/14798 but all of them are open. We may have to do without zig in the foreseeable future... Andreas
Re: core-updates sprint (was: Building more of ‘core-updates’ on ci.guix)
Am Sat, Apr 08, 2023 at 12:28:07PM +0200 schrieb Josselin Poiret: > Should we organize a code sprint soon to bring the community together > and try and get this finally merged? I can take care of sending a mail > to guix-devel, as long as we have enough helping hands for the fateful > day(s). > If so, would next week-end (15-16 april) work? Excellent idea! I will be available one of the days (tentatively Sunday, but it will depend on the weather as I would like to go to a gardening faire ;-)) I suppose we would then coordinate on the #guix channel on IRC? The powerpc bug has apparently been fixed by one of the latest commits, so it makes sense to advance. aarch64 is in very bad shape (maybe due to a lack of build power), and i686 could also do better. But I think we have a basis for substantial progress. Andreas
Re: [gnome-team] gtk+ on core-updates
Am Sun, Apr 09, 2023 at 12:57:34PM -0400 schrieb Maxim Cournoyer:
> OK, that's been fixed in meson-build-system; I've taken that opportunity
> to update our meson package to its latest 1.0.1 release too.
Great, thanks a lot! The KDE package and the Gnome package I have in my
profile now build, and I hope the best for all of Gnome (which is not yet
available on the build farm).
However, there is a problem with meson-python, which for some reason is
needed for my system profile:
tests/test_wheel.py::test_configure_data FAILED [ 94%]
=== FAILURES ===
_ test_configure_data __
wheel_configure_data =
PosixPath('/tmp/guix-build-meson-python-0.8.1.drv-0/pytest-of-nixbld/pytest-0/test0/mesonpy-test-5dncnze6/configure_data-1.0.0-py3-none-any.whl')
def test_configure_data(wheel_configure_data):
artifact = wheel.wheelfile.WheelFile(wheel_configure_data)
> assert wheel_contents(artifact) == {
'configure_data-1.0.0.data/platlib/configure_data.py',
'configure_data-1.0.0.dist-info/METADATA',
'configure_data-1.0.0.dist-info/RECORD',
'configure_data-1.0.0.dist-info/WHEEL',
}
E AssertionError: assert {'configure_data-1.0.0.dist-info/METADATA',\n
'configure_data-1.0.0.dist-info/RECORD',\n
'configure_data-1.0.0.dist-info/WHEEL',\n 'configure_data.py'} ==
{'configure_data-1.0.0.data/platlib/configure_data.py',\n
'configure_data-1.0.0.dist-info/METADATA',\n
'configure_data-1.0.0.dist-info/RECORD',\n
'configure_data-1.0.0.dist-info/WHEEL'}
E Extra items in the left set:
E 'configure_data.py'
E Extra items in the right set:
E 'configure_data-1.0.0.data/platlib/configure_data.py'
E Full diff:
E {
E - 'configure_data-1.0.0.data/platlib/configure_data.py',
E'configure_data-1.0.0.dist-info/METADATA',
E'configure_data-1.0.0.dist-info/RECORD',
E'configure_data-1.0.0.dist-info/WHEEL',
E + 'configure_data.py',
E }
tests/test_wheel.py:103: AssertionError
Captured stdout setup -
Not very telling for someone who does not know meson!
Andreas
Re: [core-updates] qtbase 6 ssl tests fail.
Hi again Ricardo, I just saw that you disabled these tests with 03580b5f1d997df066a5119cf0a242f827354ba8, by saying that not all key types are supported by our build of OpenSSL. Wouldn't this be an issue on our part, especially if Qt expects these to be available? Best, -- Josselin Poiret signature.asc Description: PGP signature
Re: [core-updates] qtbase 6 ssl tests fail.
Hi Ricardo, Ricardo Wurmus writes: > Hi Guix, > > on core-updates qtbase 6.3 fails its test suite. > > The tst_QSslKey group of tests has 122 failures that all look like > this: > > FAIL! : tst_QSslKey::passphraseChecks(DES) '!key.isNull()' returned FALSE. () >Loc: > [/tmp/guix-build-qtbase-6.3.2.drv-0/qtbase-everywhere-src-6.3.2/tests/auto/network/ssl/qsslkey/tst_qsslkey.cpp(626)] > > The tst_QSslKey failures are the only tests that fail. > > I’m currently working on upgrading linphone-desktop (I’ve upgraded all > its dependencies already, but haven’t pushed them yet) and the current > version needs Qt 6. > > Is anyone of you working on Qt 6 on core-updates? I also got bitten by this when building my own package manifest (for qpwgraph). The fact that it needs quite a lot of time was quite discouraging so I just abandoned the idea of doing it myself. I might revisit it by just building in a `guix shell -C` instead. Best, -- Josselin Poiret signature.asc Description: PGP signature
