Re: 04/08: gnu: QEMU: Unbundle iPXE.

[Marius Bakke]

Mathieu Othacehe  skriver:

> Hello Marius,
>
>> glib
>> gtk+
>> +   ipxe-qemu
>> libaio
>> libcacard;smartcard support
>> attr libcap-ng   ;VirtFS support
>
> I just noticed that:
>
> --8<---cut here---start->8---
> ./pre-inst-env guix build --system=aarch64-linux grub
> /home/mathieu/guix/gnu/packages/bootloaders.scm:101:2: warning: package 
> grub@2.06 does not support aarch64-linux
> --8<---cut here---end--->8---
>
> it seems to be because of the following dependency path:
>
> --8<---cut here---start->8---
> grub <- qemu-minimal <- ipxe-qemu <- ipxe <- syslinux
> --8<---cut here---end--->8---
>
> with syslinux that only supports x86_64-linux and i686-linux.
>
> I'm not sure how to break that path. It looks like qemu-minimal is
> required by grub for test purposes. Maybe we could restrict that
> dependency and the tests to x86_64-linux and i686-linux?

I don't know what iPXE uses syslinux for (CC Vincent); it appears to
build fine without it.  I made the dependency conditional on
architecture in d15972194aaef17fd1f7fd713d235c70794c9d4f, that way QEMU
should still work on aarch64.

(speaking of aarch64, Cuirass is slowly catching up now:
).

Thanks for the heads-up,
Marius


signature.asc
Description: PGP signature

Re: 06/06: gnu: samba/fixed: Update to 4.15.13.

[Marius Bakke]

Hi Liliana,

guix-comm...@gnu.org skriver:

> lilyp pushed a commit to branch master
> in repository guix.
>
> commit c39db91e51e55e46f177378c7b5a797441dc7d1b
> Author: Liliana Marie Prikler 
> AuthorDate: Sun Dec 18 08:29:07 2022 +0100
>
> gnu: samba/fixed: Update to 4.15.13.
> 
> * gnu/packages/samba.scm (samba/fixed-patched): New variable.
> (samba/fixed): Add replacement for samba/fixed-patched.

[...]

>  (define-public samba/fixed
>;; Version that rarely changes, depended on by libsoup.
>(hidden-package
> -   (package/inherit samba
> +   (package
> + (inherit samba)
> + (replacement samba/fixed-patched)
>   (version "4.15.3")

[...]

> +(define-public samba/fixed-patched
> +  (package
> +(inherit samba/fixed)
> +(version "4.15.13")

This is dangerous: grafts must have exactly the same store name length
since it patches binary files in-place.

I'm surprised the grafting machinery does not bail out when they differ.

I'm assuming this had security impliciations despite not being mentioned
in the commit message or comment and fixed it with
fb5514d3db19b5b405ea75cbe8fbf72d79baea1d instead of reverting.


signature.asc
Description: PGP signature

Re: 01/03: gnu: lld-as-ld-wrapper: Add version 15.

[Marius Bakke]

Christopher Baines  skriver:

> guix-comm...@gnu.org writes:
>
>> mbakke pushed a commit to branch master
>> in repository guix.
>>
>> commit 65976a8382678cd983ceddde040b777cba1f1be9
>> Author: Marius Bakke 
>> AuthorDate: Thu Nov 17 07:22:41 2022 +0100
>>
>> gnu: lld-as-ld-wrapper: Add version 15.
>>
>> * gnu/packages/llvm.scm (lld-as-ld-wrapper-15): New variable.
>> ---
>>  gnu/packages/llvm.scm | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
>> index de19b40343..2b50b127c2 100644
>> --- a/gnu/packages/llvm.scm
>> +++ b/gnu/packages/llvm.scm
>> @@ -1625,6 +1625,9 @@ misuse of libraries outside of the store.")
>>(make-lld-wrapper lld))
>>
>>  ;;; A LLD wrapper that can be used as a (near) drop-in replacement to GNU 
>> ld.
>> +(define-public lld-as-ld-wrapper-15
>> +  (make-lld-wrapper lld-15 #:lld-as-ld? #t))
>> +
>>  (define-public lld-as-ld-wrapper
>>(make-lld-wrapper lld #:lld-as-ld? #t))
>
> I spotted this change when looking at [1] as the Guix Data Service is
> failing at extracting a consistent derivation for lld-as-ld-wrapper@0.
>
> 1: https://qa.guix.gnu.org/issue/59367
>
> Maybe that could be viewed as a bug in the Guix Data Service, as it
> assumes/wants packages to be unique by name and version (at least the
> public/visible packages).
>
> But this is something raised by the linter also:
>
>   → ./pre-inst-env guix lint lld-as-ld-wrapper
>   guix lint: warning: ambiguous package specification `lld-as-ld-wrapper'
>   guix lint: warning: choosing lld-as-ld-wrapper@0 from 
> gnu/packages/llvm.scm:1594:2
>
> Is there something that can be done about this, perhaps by using the lld
> package version in the name or version for this package, or by hiding
> this package?

I think using the LLD version is sensible.  I made this change in
cd9161372aa3ec9b8902385d5937d04e1868495c and also inherited the
home-page and license fields.

Maxim: please let me know if you this this was misguided!


signature.asc
Description: PGP signature

Re: Packages depending on (guix build syscalls)

[Marius Bakke]

Ludovic Courtès  skriver:

> Hi!
>
> Marius Bakke  skribis:
>
>> Ludovic Courtès  skriver:
>>
>>> Ludovic Courtès  skribis:
>>>
>>>> Quite a few packages depend on (guix build syscalls), starting from
>>>> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
>>>> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
>>>> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).
>>
>> It seems the usage of (guix build syscalls) in java.scm and
>> ant-build-system is solely for 'mkdtemp!'.  Guile 3.0.6 gained
>> 'mkdtemp', so I suppose we can switch to that?
>
> I think so.

Pushed in fa9ad4b4822d..e6f5b9f7321925.

However it is only a temporary measure because on the 'core-updates'
branch, (guix build syscalls) is used by polkit (for
SET-CHILD-SUBREAPER!) and thus get nearly 3k dependents.


signature.asc
Description: PGP signature

Re: Packages depending on (guix build syscalls)

[Marius Bakke]

Ludovic Courtès  skriver:

> Ludovic Courtès  skribis:
>
>> Quite a few packages depend on (guix build syscalls), starting from
>> ‘ant-bootstrap’ (since commit cded3a759356ff66b7df668bcdbdfa0daf96f4c5
>> in 2018) up to GNOME-related packages such as ‘mutter’ (commit
>> d1c2fe248a7a326189fb7dcae64a59ece96251ba a few months ago).

It seems the usage of (guix build syscalls) in java.scm and
ant-build-system is solely for 'mkdtemp!'.  Guile 3.0.6 gained
'mkdtemp', so I suppose we can switch to that?

If there are backwards-compatibility concerns it seems possible to
modify these procedures to not need to 'mkdtemp' at all.

I can prepare a patch along these lines, but not sure if we need to
maintain backward compatibility in (gnu packages).

> An issue is that GNOME now depends on Java:

[...]

> There’s probably not much we can do, unless the python-afdko -> icedtea
> dependency is optional.

This relationship was added in b0ddbb05729e86ce4efb7eac8909317e16d7bed7
and is possible to trade at a purity cost.


signature.asc
Description: PGP signature

State of the 'core-updates' branch

[Marius Bakke]

Hello Guix,

There has been a lot of activity on 'core-updates' recently.

Some highlights from this branch:

* The Full-Source Bootstrap
* GCC 11
* glibc 2.35
* Python 3.10.7
* OpenSSL 3.0
* Meson 0.63.2
* CMake 3.24.2
* Pytest 7.1.3
* bash-completion 2.11

As well as updates to the usual low-level libraries: GNU tools, Wayland,
ICU, Boost, the font stack, Mesa, Ghostscript, etc.

As of commit 28918b4ff8d2c297d1f1fb84eebdca9fc2dc9303, these work:

* GNOME
* IceCat
* Xfce
* Sway
* 'guix system vm'
* cross-compiling to various targets

These "almost" work:

* 'guix' needs this patch, and an update of the guix package:
  .  Can be worked around with this
  horrifying patch to the 'guix' package definition:

(add-after 'unpack 'adjust-for-glibc-2.34
  (lambda _
(substitute* "guix/build/syscalls.scm"
  (("#:library \"libutil\"")
   ""

* Linux-Libre fails due to a regression in gawk, easy to work around by
  providing an older version; will be fixed with gawk 5.2.1.
* ungoogled-chromium needs a few tweaks
* libreoffice likewise
* diffoscope has one failing dependency
* there are segfaults from 'libgc' via Shepherd in a 'guix system vm'
  ... it still boots, but you probably should not reconfigure just yet!

These are currently failing:

* GCC 5
* glibc 2.33 (for old locales)

All in all, the branch is in great shape, and all my manifests are
building apart from the mentioned problems.

If there are any outstanding patches on the tracker, let's get them in.

I expect many Python packages need to be updated for 3.10.  To ease this
process it would be great to get the revamped build system from
'wip-python-pep517' merged.  I plan to look at it "soon", but volunteers
welcome.  :-)

Should we aim to "freeze" this branch by early/mid October or so?

-- 
Marius


signature.asc
Description: PGP signature

'staging' freeze

[Marius Bakke]

Hi Guix,

The 'staging' branch is in a pretty good shape, let's get it merged!

Highlights from this branch:

* Rust 1.60
* Gstreamer 1.20.3
* Sphinx 5.1.1
* ruby-nokogiri and its dependencies is no longer in the bootstrap path
  of TeX Live, so they can be more freely updated on 'master'

I'm fairly rusty when it comes to Cuirass, and don't see a button to
start the jobset here even when authenticated:

  https://ci.guix.gnu.org/jobset/staging

Can someone remind me how to enable a disable jobset?  :-)

Full shortlog below:

Marius Bakke (100):
  [a49c829a05] gnu: libva: Update to 2.14.0.
  [87793b349f] gnu: libva: Use G-expressions.
  [a5436115a0] gnu: python-babel: Update to 2.10.3.
  [e850e361b6] gnu: python-sphinx: Update to 5.0.2.
  [9acd1a150f] gnu: python-certifi: Update to 2022.6.15.
  [647ec2ae78] gnu: python-requests: Update to 2.28.0.
  [a4283bf55f] gnu: python-urllib3: Update to 1.26.9.
  [3787f0d215] gnu: python-charset-normalizer: Update to 2.1.0.
  [32c676bbcd] gnu: libepoxy: Update to 1.5.10.
  [2692624ecf] gnu: libepoxy: Use new style.
  [c209146212] gnu: libwebp: Update to 1.2.2.
  [1535d8c5d8] gnu: libwebp: Simplify inputs.
  [7f209d8425] gnu: bluez: Update to 5.64.
  [6cb7e67dc5] gnu: bluez: Simplify inputs.
  [60f17c197d] gnu: bluez: Use new style.
  [a6bc7baa54] gnu: freeglut: Update to 3.2.2.
  [ddc538ac32] gnu: libical: Update to 3.0.14.
  [b40151ff4f] gnu: glu: Update to 9.0.2.
  [421a3c8172] gnu: libinput: Update to 1.19.4.
  [fce910af55] gnu: Remove postgresql@13 replacement.
  [6c7fcc71d1] gnu: qtbase: Build with PostgreSQL@14.
  [66e3adcad8] gnu: Remove unused patch.
  [de9d389c54] gnu: nspr: Update to 4.34.
  [fd004ddafa] gnu: nss, nss-certs: Update to 3.80.
  [b316d8b751] gnu: nspr: Use G-expressions.
  [01d1b285b8] gnu: nss: Use G-expressions.
  [dce7ed146d] gnu: libunwind: Enable tests.
  [d33f051740] gnu: libmng: Remove input labels.
  [5b48591176] gnu: python-pillow: Update to 9.2.0.
  [32b7e12e77] gnu: python-cffi: Update to 1.15.1.
  [97e2983310] gnu: python-cffi: Remove input labels.
  [f49eef43fd] gnu: iso-codes: Remove input labels.
  [03a4908ea5] gnu: mozjs: Build with the default LLVM.
  [13040cd309] gnu: mozjs: Remove obsolete workaround.
  [1f22184b22] gnu: python-attrs: Disable test deadline on all 
architectures.
  [572ed223ab] gnu: python-requests: Update to 2.28.1.
  [8d241c685a] gnu: python-chardet: Update to 5.0.0.
  [3b20467807] gnu: libva: Update to 2.15.0.
  [c0c6944f1a] gnu: perl-pod-parser: Update to 1.65.
  [9b4b5e33c4] gnu: perl-file-basedir: Update to 0.09.
  [c3da692293] gnu: perl-file-mimeinfo: Update to 0.33.
  [4625519f2c] gnu: libmbim: Update to 1.26.4.
  [718f75a55a] gnu: libqmi: Update to 1.30.8.
  [40992a1e02] gnu: modem-manager: Remove input labels.
  [9ee4069eb0] gnu: modem-manager: Use G-expression.
  [fdd40f391c] gnu: modem-manager: Remove obsolete input.
  [68aab436af] gnu: modem-manager: Update to 1.18.10.
  [f098d93352] gnu: nss, nss-certs: Update to 3.81.
  [f3673447cc] gnu: rust-smallvec: Update to 1.9.0.
  [ca5f1dd01e] gnu: rust-target-lexicon: Update to 0.12.4.
  [7b38d7731a] gnu: rust-cfg-expr: Add 0.10.3.
  [8d05800f67] gnu: rust-system-deps: Add 6.0.2.
  [e31cc7f0c9] gnu: rust-glib-sys: Add 0.15.
  [21e5e408bf] gnu: rust-cairo-sys: Add 0.15.1.
  [633c4ca407] gnu: rust-gobject-sys: Add 0.15.10.
  [ac393134e5] gnu: rust-glib-macros: Add 0.15.
  [bc9ea4f6e8] gnu: rust-glib: Add 0.15.12.
  [01c410a440] gnu: rust-cairo-rs: Add 0.15.12.
  [def0acd5e5] gnu: rust-pango-sys: Add 0.15.
  [713b289ff0] gnu: rust-pango: Add 0.15.10.
  [c5d4f2e8f0] gnu: rust-pangocairo-sys: Add 0.15.
  [2f9aa892c6] gnu: rust-pangocairo: Add 0.15.1.
  [b4678e4488] gnu: rust-gio-sys: Add 0.15.10.
  [bdd55817ed] gnu: rust-gdk-pixbuf-sys: Add 0.15.
  [79ee7d783a] gnu: rust-gio: Add 0.15.12.
  [c7bbf937ff] gnu: rust-gdk-pixbuf: Add 0.15.11.
  [de212cb74e] gnu: rust-itertools@0.10: Update to 0.10.3.
  [26afc27f29] gnu: rust-tinyvec@1: Update to 1.2.0.
  [e62dd8e762] gnu: rust-crc32fast: Update to 1.3.2.
  [822edbf08b] gnu: rust-gzip-header: Add 1.0.0.
  [fe76e27789] gnu: rust-mint: Update to 0.5.9.
  [1160932ea0] gnu: rust-deflate: Add 1.0.0.
  [4059158e6a] gnu: rust-png: Add 0.17.
  [1338e25610] gnu: rust-yeslogic-fontconfig-sys: Add 2.11.2.
  [0b770c2da4] gnu: librsvg: Update to 2.54.4.
  [7b69cd0740] Revert "gnu: librsvg: Update to 2.54.4."
  [b9a3083db3] gnu: qtscxml: Fix build failure.
  [f561830a5b] gnu: python-pympler: Update to 1.0.1.
  [431df1214e] gnu: python-dateutil: Adjust tests for Pytest 7.
  [30ac875bd8] gnu: python-sphinx: Update to 5.1.1.
  [a20a934081] gnu: python-freezegun: Update to 1.2.2.
  [c5860b97e9] g

Re: Who owns guix-mirror?

[Marius Bakke]

Tobias Geerinckx-Rice  skriver:

> Hi Philip,
>
> Philip Beadling 写道：
>> I was wondering who owns the mirror as there is no public 
>> ownership declared on github.com?
>>
>> Is it owned by Guix or is it run by a trusted third party,  etc? 
>
> It's Marius Bakke (mbakke) and me (nckx).  It probably wouldn't 
> hurt to make that list public.  Marius, what say you?

Agreed, I've just stepped out of the darkness by navigating to this
page (took me a while to find it):

  https://github.com/orgs/guix-mirror/people

Awesome logo, by the way!


signature.asc
Description: PGP signature

Re: branch master updated: gnu: python-lxml: Update to 4.6.5.

[Marius Bakke]

Danny Milosavljevic  skriver:

> Hi Mathieu,
>
> On Mon, 15 Aug 2022 16:24:03 +0200
> Mathieu Othacehe  wrote:
>
>> > * gnu/packages/xml.scm (python-lxml): Update to 4.6.5.  
>> 
>> I had to revert it as it caused >15k rebuilds. I also cancelled all the
>> triggered builds in the CI.
>
> Thanks for doing it!
>
> But guix refresh -l python-lxml reported one package O_o
>
> Now I see that python-lxml-4.7 shadows it.
>
> Note: This would have fixed two CVEs, CVE-2021-43818 and CVE-2021-43818.

Can you add a "graft" for this version instead of updating in-place?



signature.asc
Description: PGP signature

100k commits!

[Marius Bakke]

Guix,

We just passed 100 000 commits!

The lucky winner is ...

  commit 9fe9856ebef515927900e56686a1071936bdafcc
  Author: Ricardo Wurmus 
  Date:   Wed Aug 10 12:19:55 2022 +0200

  gnu: r-fontawesome: Update to 0.3.0.

  * gnu/packages/cran.scm (r-fontawesome): Update to 0.3.0.

An appropriate package name for such a big milestone.  :-)

Congratulations for making it this far, and a big thank you to the 700+
contributors who made this possible.  You are truly awesome.

Happy hacking!


signature.asc
Description: PGP signature

Re: Dealing with non-ASCII file names in BOOTSTRAP-ORIGIN

[Marius Bakke]

Greg Hogan  skriver:

> On the off chance that the following is helpful, in order to switch
> the build to GCC 11 or 12 I had to apply the patch (with the missing
> endif) from
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017#c12
>
> You may have avoided or worked around this issue, but even though a
> different fix from the ticket was patched into our GCC 11.3 and 12.1,
> these would not bootstrap for me without that patch.

Neat.  Do you have a patch submitted to the tracker already?  Did you
also find a solution to the file name problem?

I took a slightly different route to work around the libstdc++ bootstrap
issue (see bottom hunk):

--8<---cut here---start->8---
   (add-after 'unpack 'apply-patches-and-snippet
 (lambda* (#:key inputs #:allow-other-keys)
   (let ((patch1 (assoc-ref inputs "patch1"))
 (patch2 (assoc-ref inputs "patch2"))
 (libstdc++ (assoc-ref inputs "libstdc++")))

 ;; Apply the patch inputs added below.
 (for-each (lambda (patch)
 (invoke "patch" "-p1" "--input" patch
 "--no-backup-if-mismatch"))
   (list patch1 patch2))

 ;; Apply the gcc-canadian-cross-objdump snippet.
 (substitute* "libcc1/configure"
   (("\\$gcc_cv_objdump -T")
"$OBJDUMP_FOR_TARGET -T"))

 ;; Fix a regression in GCC 11 where the libstc++ input
 ;; shadows glibc headers when building libstdc++.  An
 ;; upstream fix was added in GCC 11.3.0, but it only
 ;; hides system include directories, not those on
 ;; CPLUS_INCLUDE_PATH.  See discussion at
 ;; .
 (substitute* "libstdc++-v3/src/c++17/Makefile.in"
   (("^AM_CXXFLAGS = ")
(string-append "CPLUS_INCLUDE_PATH = "
   (string-join
(remove (cut string-prefix? libstdc++ 
<>)
(string-split
 (getenv "CPLUS_INCLUDE_PATH")
 #\:))
":")
   "\nAM_CXXFLAGS = "
--8<---cut here---end--->8---

It's not pretty, but does the job!  I won't push it right away though,
waiting for feedback and checking that things generally work first.

-- 
Thanks,
Marius


signature.asc
Description: PGP signature

Dealing with non-ASCII file names in BOOTSTRAP-ORIGIN

[Marius Bakke]

Hi Guix,

I tried switching to GCC 11 on the core-updates branch, but it fails
early when attempting to repack the GCC source code for GCC-BOOT0,
because some files in its test suite contains non-ASCII characters:

--8<---cut here---start->8---
[... unpacking ...]
patching file gcc/builtins.c
Hunk #1 succeeded at 4623 with fuzz 1 (offset 1341 lines).
Hunk #2 succeeded at 6097 with fuzz 2 (offset 2206 lines).
patching file gcc/gimple-fold.c
Hunk #1 succeeded at 665 (offset 9 lines).
Hunk #2 succeeded at 766 with fuzz 2 (offset 16 lines).
patching file libvtv/Makefile.in
Hunk #1 succeeded at 14 with fuzz 1 (offset -1 lines).
source is at 'gcc-11.3.0'
applying 
'/gnu/store/g0ba4l825z9i4l1jd5cqvl6m09xicdwa-gcc-9-strmov-store-file-names.patch'...
applying 
'/gnu/store/5705r4ajxl8lav1hz9xm19w75zdcz1n2-gcc-5.0-libvtv-runpath.patch'...
find-files: 
gcc-11.3.0/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go: No such 
file or directory
Backtrace:
In srfi/srfi-1.scm:
 465: 19 [fold # ...]
In ice-9/ftw.scm:
 452: 18 [# 
# #]
 450: 17 [loop "gcc" "gcc-11.3.0" ...]
In srfi/srfi-1.scm:
 465: 16 [fold # ...]
In ice-9/ftw.scm:
 452: 15 [# 
# #]
 450: 14 [loop "testsuite" "gcc-11.3.0/gcc" ...]
In srfi/srfi-1.scm:
 465: 13 [fold # ...]
In ice-9/ftw.scm:
 452: 12 [# # 
#]
 450: 11 [loop "go.test" "gcc-11.3.0/gcc/testsuite" ...]
In srfi/srfi-1.scm:
 465: 10 [fold # ...]
In ice-9/ftw.scm:
 452: 9 [# # 
#]
 450: 8 [loop "test" "gcc-11.3.0/gcc/testsuite/go.test" ...]
In srfi/srfi-1.scm:
 465: 7 [fold # ...]
In ice-9/ftw.scm:
 452: 6 [# # 
#]
 450: 5 [loop "fixedbugs" "gcc-11.3.0/gcc/testsuite/go.test/test" ...]
In srfi/srfi-1.scm:
 465: 4 [fold # ...]
In ice-9/ftw.scm:
 452: 3 [# # 
#]
 474: 2 [loop "issue27836.dir" ...]
In guix/build/utils.scm:
 540: 1 [# 
"gcc-11.3.0/gcc/testsuite/go.test/test/fixedbugs/issue27836.dir/Äfoo.go" ...]
In unknown file:
   ?: 0 [scm-error misc-error #f "~A" ("find-files failed") #f]

ERROR: In procedure scm-error:
ERROR: find-files failed
--8<---cut here---end--->8---

Deleting these files also don't work for the same reason, even when
using the hex representation, i.e. (delete-file "\u00c4foo.go"), or with
DELETE-FILE-RECURSIVELY.

One workaround is to avoid the use of BOOTSTRAP-ORIGIN by applying the
patches and snippet in phases, but that's suboptimal because it has to
be done for all of GCC-BOOT0, LIBSTDC++, and GCC-FINAL.

I'll try this workaround to get things going, but hoping for better
suggestions!

Re: Non-free data in Poppler test suite

[Marius Bakke]

Mark H Weaver  skriver:

> Therefore, I think that in order to comply with the FSDG, we should use
> a snippet to remove any files covered by the CC BY-NC-ND license.

The test suite is shipped separately from the Poppler source code, and
contains many seemingly unauditable PDF files.  I don't think removing
all PDFs without a clear license and adjusting the test suite
accordingly is tenable, so I went ahead and removed the whole origin:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=72cb5a3a648a3853a772b8b1a2cd26206627fb0d

I also raised a ticket with licensing@fsf with ID [gnu.org #1851409].

Thanks for the feedback, everyone.

-- 
Marius


signature.asc
Description: PGP signature

Non-free data in Poppler test suite

[Marius Bakke]

Hello Guix,

I discovered a potential freedom issue with the Poppler test suite.
Specifically it includes a file with the CC BY-NC-ND (non-commercial)
license:

  
https://gitlab.freedesktop.org/poppler/test/-/commit/920c89f8f43bdfe8966c8e397e7f67f5302e9435

It turns out the repository is filled with PDFs of unknown origins, that
are impossible to audit.

(this issue only exists on the "core-updates" branch)

Normally we'd remove such files with a 'snippet', but these files are
not actually shipped with Poppler itself: they are downloaded separately
and only used for running tests during the build process:

  
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/pdf.scm?h=core-updates=8c3e9da13a3c92a7db308db8c0d81cb474ad7799#n226

As such, these files are not accessible to end users of Guix short of
disabling substitutes and grepping the store.

So the million dollar question ... are these files okay to use for Guix?

In my (non-lawyer) opinion, I have faith that Poppler developers would
not distribute files that are not freely redistributable, and that this
counts as "non-functional data" per FSDG guidelines:

  https://www.gnu.org/distros/free-system-distribution-guidelines.html

However, we failed to reach a consensus on #guix[0].  What do others
around here think?  Should we play it safe and disable Poppler tests?
Raise the issue with FSF?  Something else?

[0]: https://logs.guix.gnu.org/guix/2022-06-28.log#195123

-- 
Thanks,
Marius
(And sorry for being gone for so long!  I'm back now, promise.)


signature.asc
Description: PGP signature

Re: License of your contributions to the blog at guix.gnu.org

[Marius Bakke]

Ludovic Courtès  skriver:

> Hello,
>
> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> .
>
> With a few exceptions, these articles do not have a clear license, which
> we would like to fix.  We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
>
> Do you agree with the proposed licensing terms for your contributions to
> the blog?

I agree.


signature.asc
Description: PGP signature

Re: Expat 2.3.0 has been released

[Marius Bakke]

Sebastian Pipping  skriver:

> Hello everyone,
>
>
> just a quick heads up that there will be a new release of libexpat with
> security fix in a few weeks.  Unless I looked in the wrong place, I
> noticed that your distro has not updated to libexpat 2.3.0 as of today.
>  If you ran into any issues with packaging 2.3.0, please let me know now
> so that I can fix things upstream for you and everyone while there is
> still a window before next releases to do so.  Thank you!

Hi Sebastian,

I have updated expat on our "core-updates" branch, since it entails a
full rebuild:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates=831c6d84e1bcff4b68dfd0f6e299f2c0bb60d0b8

I notice 2.3.0 does not have any ABI changes from 2.2.9.  In that case
the security fix/version can be "grafted" in place without rebuilding
the world.  So count us ready, we'll test 2.3.0 meanwhile.  :-)

Thanks for the heads-up,
Marius


signature.asc
Description: PGP signature

Re: A "cosmetic changes" commit that removes security fixes

[Marius Bakke]

Léo,

We maintainers have been disappointed by Marks harsh tone which do not
meet the project's communication standards, but also by your apparent
lack of will to reply constructively to legitimate criticism.

This is the next in a series of incidents.  The incidents are okay--we
we all make mistakes and that's how we learn--but we interpreted your
responses all too often as dismissive and defensive, rather than
understanding and forward-looking.  This has been causing unnecessary
friction and stress, and is not how we envision peaceful collaboration.

I'm sorry to say your commit privileges have been temporarily
suspended.  After one month, you are invited to get in touch with the
maintainers collective and discuss next steps.

You have done terrific work in Guix in the short time you've been
around: from the POWER9 port, to the many security fixes,
to tracking and reporting issues, and suggesting improvements to the
tools.  I hope you'll eventually rejoin to collaborate in the peaceful
and empathetic fashion that this project encourages.

-- 
Marius (on behalf of the maintainers collective)


signature.asc
Description: PGP signature

Re: [ungrafting] cURL is missing the 'curl-use-ssl-cert-env' patch

[Marius Bakke]

Marius Bakke  skriver:

> Now the question is: should we restore this patch, and in practice
> restart the branch almost from scratch?  Or drop it, considering
> upstream has rejected it[0]?

Following a discussion on IRC, we decided to reinstate the patch and get
rid of the newly added graft at the same time.

Apologies to those who already started building it!


signature.asc
Description: PGP signature

Polkit now depends on Rust

[Marius Bakke]

Hello,

Newer versions of 'polkit' depend on mozjs 78, which unsurprisingly
depends on Rust.

As Rust currently only builds on x86_64, that means an important piece
of desktop systems will no longer work on other architectures.

How should we deal with this?  I see a couple of options:

1. Stick with Polkit 0.116 indefinitely, backporting security fixes as
   they are discovered.
2. Use the newer version of Polkit on x86_64 only, leaving other
   architectures to "fend for themselves" so to speak.
3. Make Polkit work with mozjs 60.
4. Fix Rust on other architectures.

Obviously 4 is the better option, but I suppose it can take a while.  I
don't think anyone is actively working on it.  Volunteers wanted!

Thoughts?


signature.asc
Description: PGP signature

[ungrafting] cURL is missing the 'curl-use-ssl-cert-env' patch

[Marius Bakke]

Hello,

As you may have noticed, there is a new "ungrafting" branch that intends
to remove most of the "grafts" people have to deal with on a regular
basis.

The CI (and undersigned) have gotten pretty far on building this branch,
but there is a problem: cURL lost its "curl-use-ssl-cert-env" patch in
commit cb8569e10c766f180c48c7cf74b74f7b4cb74541.

This patch adds support for the SSL_CERT_DIR and SSL_CERT_FILE variables
for any application using libcurl.

I only noticed this because I merged a new graft for cURL (1adeb74456,
a7737f0ead).

Now the question is: should we restore this patch, and in practice
restart the branch almost from scratch?  Or drop it, considering
upstream has rejected it[0]?

[0] https://github.com/curl/curl/pull/4809

As a middle ground, we can add it to the recent graft added in
1adeb74456, which won't require rebuilds.

Thoughts?


signature.asc
Description: PGP signature

Re: Poetry upgrade and related packages

[Marius Bakke]

Tanguy LE CARROUR  skriver:

> Hi Marius,
>
>
> Excerpts from Marius Bakke's message of December 7, 2020 11:59 pm:
>> Tanguy LE CARROUR  skriver:
>>> Excerpts from Ludovic Courtès's message of December 5, 2020 4:44 pm:
 Tanguy LE CARROUR  skribis:
 
> It's not yet clear to me how to handle (python) package updates:
> - when to update;
> - when not to update;
> - when to introduce "versionned" (`-x.y` suffix) package definitions;
> - when to introduce "next" (`/next` suffix) package definitions;
> - when to remove the two above suffixes;
> - …
>
> So I'm looking forward to reading the answers to this thread! :-)
 
 When a change introduces too many rebuilds, the convention is to make
 that change on a branch that will be merged “later” rather than on
 ‘master’; this is bullet 8 here:
 
   https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html
>>>
>>> Thanks for pointing at, but this "just" tells me on which branch to put
>>> the changeset, not which of the above options should be used when a
>>> package needs to be updated.
>> 
>> There is no "one size fits all" rule.  With rare exceptions, Guix
>> "wants" to have only have a single version of each package (mainly to
>> ease maintenance).  As you found, that's not always feasible.
>> 
>> If a package depends on a newer version of something "deep in the graph"
>> such as Pytest, it's always OK to add a "/next" or "-x.y" variant
>> (though a convention about which to use would probably be a good idea).
>>
>> If something depends on a *specific* (older) version of Pytest, it's
>> better to try and make it work with the newer version; but failing that,
>> adding a "-x.y" is fine too.
>
> `-x.y` packages are here to stay.
> `/next` are temporary packages.

In most cases, yes.  :-)

> Is it safe to remove all `-x.y` packages that are not used as inputs?
> Is there a (programmatic) way to find those packages?

Good questions.  It should be safe to remove unused and versioned "leaf"
packages.  I don't have good answers on how to discover them though.

> When `/next` become "current|default|latest", who is in charge of patching
> all the package definitions that were using it?!

Typically those occur in the same or (closely related) commits.  But it
happens that a "/latest" has been removed on 'core-updates', yet keeps
gaining uses on 'master'.  In those cases deprecating (instead of
removing) the variable on the 'core-updates' branch is the best option,
so that merging master->core-updates won't break the branch.

There is no one "in charge" though, just "someone" has to do it.  :-)

 Yet, sometimes we want to introduce new versions that people can get in
 their profile, even if the “default” one remains the older version to
 avoid world rebuilds.
>>>
>>> That's exactly my point! If the default one lags behind, then after some
>>> time, nobody will use it any more and we will have introduced one or more
>>> `-x.y` package definitions!
>>> I would consider it to be a "saner" approach to have the default always
>>> "point" to the latest version, but then we would have to "fix" package
>>> depending on older versions by introducing `-x.y` package definitions
>>> for them.
>>>
>>> Or am I missing something?!
>> 
>> You got it right.  It might be saner to make the unversioned variable
>> refer to the newest version, but it would often require "pinning"
>> hundreds of packages to the old version to avoid rebuilds.  Thus, it's
>> typically more practical to use the "/next" variant until the next
>> rebuild cycle.
>
> Then, during the rebuild cycle those hundreds of packages get rebuilt
> and… some of them fail because they depend on the older version, right?!
> But I'm pretty sure it's a problem all distributions have to face.

Yes, often you'll get an "upgrading cascade", which may bring new
problems such as circular dependencies, etc (looking at you, Python
ecosystem).

The only remedy I know for that is copious amounts of coffee.

> Wasn't it discussed somewhere else that one should get notified (by email)
> when their favourite packages were broken?

I think cbaines is working on something along those lines.

>> Again there is no hard rule here, I did such a change for 'libcap' in
>> 9e1f5a263e4f6df4d075901c9b58a56f80c8b452 because only two packages
>> needed to pin the old version.
>
>> Hope this clears things up a little more.  :-)
>
> Yes, thanks! But I guess I need to go through more of those situations
> to make sure I understand everything.

For some practical experience, you can try updating to Python 3.9.1 and
the latest Pytest (+ dependencies).  This needs to be done soon for the
'core-updates' branch anyway.  ;-)


signature.asc
Description: PGP signature

Re: updating Jami to "Together", Qt update?

[Marius Bakke]

Jan Wielkiewicz  skriver:

> Hello everyone,
>
> I managed to compile the latest release of Jami and I'll be sending
> patches soon.
> Is anyone planning to update Qt to 5.15.1? It would be nice if Jami
> used this version to stay close to upstream.
> I can update it if no one plans that.

I have an update for Qt 5.15.2 lined up for the 'staging' branch that
will get pushed approximately tomorrow.  :-)


signature.asc
Description: PGP signature

Re: Poetry upgrade and related packages

[Marius Bakke]

Tanguy LE CARROUR  skriver:

> Hi,
>
>
> Excerpts from Ludovic Courtès's message of December 5, 2020 4:44 pm:
>> Tanguy LE CARROUR  skribis:
>> 
>>> It's not yet clear to me how to handle (python) package updates:
>>> - when to update;
>>> - when not to update;
>>> - when to introduce "versionned" (`-x.y` suffix) package definitions;
>>> - when to introduce "next" (`/next` suffix) package definitions;
>>> - when to remove the two above suffixes;
>>> - …
>>>
>>> So I'm looking forward to reading the answers to this thread! :-)
>> 
>> When a change introduces too many rebuilds, the convention is to make
>> that change on a branch that will be merged “later” rather than on
>> ‘master’; this is bullet 8 here:
>> 
>>   https://guix.gnu.org/manual/devel/en/html_node/Submitting-Patches.html
>
> Thanks for pointing at, but this "just" tells me on which branch to put
> the changeset, not which of the above options should be used when a
> package needs to be updated.

There is no "one size fits all" rule.  With rare exceptions, Guix
"wants" to have only have a single version of each package (mainly to
ease maintenance).  As you found, that's not always feasible.

If a package depends on a newer version of something "deep in the graph"
such as Pytest, it's always OK to add a "/next" or "-x.y" variant
(though a convention about which to use would probably be a good idea).

If something depends on a *specific* (older) version of Pytest, it's
better to try and make it work with the newer version; but failing that,
adding a "-x.y" is fine too.

Then there are ecosystems such as Go and Rust that have fairly strict
semver rules, and require carrying many different versions of the same
package.

>> Yet, sometimes we want to introduce new versions that people can get in
>> their profile, even if the “default” one remains the older version to
>> avoid world rebuilds.
>
> That's exactly my point! If the default one lags behind, then after some
> time, nobody will use it any more and we will have introduced one or more
> `-x.y` package definitions!
> I would consider it to be a "saner" approach to have the default always
> "point" to the latest version, but then we would have to "fix" package
> depending on older versions by introducing `-x.y` package definitions
> for them.
>
> Or am I missing something?!

You got it right.  It might be saner to make the unversioned variable
refer to the newest version, but it would often require "pinning"
hundreds of packages to the old version to avoid rebuilds.  Thus, it's
typically more practical to use the "/next" variant until the next
rebuild cycle.

Again there is no hard rule here, I did such a change for 'libcap' in
9e1f5a263e4f6df4d075901c9b58a56f80c8b452 because only two packages
needed to pin the old version.

>> One example is GDB: gdb@8 has 1,671 dependents, but we added gdb@10 on
>> the side such that “guix install gdb” gives you version 10.
>
> The difference here is that it's a package added to a profile, not a
> dependency, so `gdb` means the latest available version of GDB, right?
>
> As you can see, everything is not yet clear to me! Sorry! ^_^'

Hope this clears things up a little more.  :-)


signature.asc
Description: PGP signature

Re: 01/07: gnu: python-packaging: Update to 20.4.

[Marius Bakke]

Hello,

guix-comm...@gnu.org skriver:

> ngz pushed a commit to branch master
> in repository guix.
>
> commit 71b15b4874b7f9ec7001d2916a8ab27dcce6cdc0
> Author: Tanguy Le Carrour 
> AuthorDate: Mon Nov 30 10:48:57 2020 +0100
>
> gnu: python-packaging: Update to 20.4.
> 
> * gnu/packages/python-xyz.scm (python-packaging): Update to 20.4.
> [source]: Remove patch that has been merged upstream.
> * gnu/packages/patches/python-packaging-test-arch.patch: Remove file.
> * gnu/local.mk (dist_patch_DATA): Apply removal.
> 
> Signed-off-by: Nicolas Goaziou 

I have just reverted this patch on 'master' because it caused 6328
rebuilds.  It's not obvious, because they come via the 'bootstrap'
variant defined below the main package:

  $ guix refresh -l -e '(@ (gnu packages python-xyz) 
python-packaging-bootstrap)'
  Building the following 2399 packages would ensure 6328 dependent
  packages are rebuilt: [...]

Not sure how we can improve on this.  Thoughts?

@Tanguy: do you know if Poetry will still work with the old version?


signature.asc
Description: PGP signature

Re: GNU Guix 1.2.0rc1 available for testing!

[Marius Bakke]

"pelzflorian (Florian Pelz)"  writes:

> On Fri, Nov 13, 2020 at 06:07:32PM +0100, Ludovic Courtès wrote:
>>   system installation:
>> […]
>> 
>> https://alpha.gnu.org/gnu/guix/guix-system-install-1.2.0rc1.x86_64-linux.iso.xz
>
> Sorry for testing so late.  For me the graphical installer crashes
> when doing a Manual Partitioning with an encrypted partition.
> I attach the last-installer-error after Manual Partitioning.
>
> Can others successfully use encryption with the installer?

I have just installed a system using manual partitioning through the
installer, with encryption.  Everything worked like a charm.

Can you provide more details about the steps you did to arrive at the
error?  And information about the (new and old) partition layout?


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Pierre Neidhardt  writes:

>> I had not realized sbcl-static-dispatch failed to build even on 'master'
>> initially, did you commit it by mistake?  If I'd known I would not have
>> let it hold up the merge.
>
> Weird, it works for me on be0ebf33aa19dcfd36c7a8d22a53344dc3b4a533

It did not work for me until 9f78a37f52a12474d1eb61f789b159c4ea3134b7.


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> Speaking of the Common Lisp build system on 'staging', the newly-added
>> 'sbcl-static-dispatch' fails to build when merged or cherry-picked.
>>
>> Can you look into it?
>
> I haven't tested but this could be fixed by the commit I've just pushed
> for cl-environments:
>
> 9f78a37f52a12474d1eb61f789b159c4ea3134b7
>
> I'll look into static-dispatch more closely later.

I can confirm the above commit works.

I had not realized sbcl-static-dispatch failed to build even on 'master'
initially, did you commit it by mistake?  If I'd known I would not have
let it hold up the merge.


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Marius Bakke  writes:

> Pierre Neidhardt  writes:
>
>> Can't wait for staging to merge, the Common Lisp build-system is vastly
>> improved!
>
> I've just fixed a 'totem' test failure.  Unless other regressions show
> up it should be ready for merge within a few days.  Testers wanted!

Speaking of the Common Lisp build system on 'staging', the newly-added
'sbcl-static-dispatch' fails to build when merged or cherry-picked.

Can you look into it?


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Pierre Neidhardt  writes:

> I've just pushed a fix in 98a15c796afcc91894b7400b1d548cd50604db0c, so
> Nyxt should be back to its pristine defintion.

Oh my, thanks for catching that.

I did have the lparallel removal in my notes and distinctly remember
adjusting for it, but obviously messed up at some point.  At least I got
the additions right...

I'm not usually this sloppy with merges, promise!  :-)

> Can't wait for staging to merge, the Common Lisp build-system is vastly
> improved!

I've just fixed a 'totem' test failure.  Unless other regressions show
up it should be ready for merge within a few days.  Testers wanted!


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Pierre Neidhardt  writes:

> Hi Marius!
>
> Sorry about this! :(
>
>> If you happen to be around right now, can you confirm that there were no
>> changes to nyxt inputs in 573489fbcd68e3a89cc5c9c66693d3689b1b88bf?
>
> I don't have a Guix checkout at hand now so I can only tell you tomorrow.
> Did you manage to fix the merge conflict?

The merge was resolved in 32787d652460871a79f99b63230f92759e2e0de2.

> Otherwise go ahead and I'll fix the Nyxt recipe when you are done.

Great.  I verified that Nyxt builds on 'staging', but have not tried
running it.

> Out of curiosity: how do commit messages help you here?

It can be difficult to tell from the diff alone which inputs are native,
regular, or propagated.

Often when merging, I need to look at the conflicting commits multiple
times.  Having to deduce the changes every time carries a mental
overhead that is eliminated when I can compare the diff against the
commit message.

In this particular case I ended up writing down the changes for each
conflicting Nyxt commit (21e792, c5d9cd, 573489).  The latter was
especially tricky because it changed the indentation, but ultimately I
found that it had no input changes (by comparing line-for-line).

> Is there an automated way to report the inputs changes from the
> comment message?

I'm not sure what you mean, can you elaborate?

> Sorry for the troubles!

No worries.  :-)


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Marius Bakke  writes:

> This is a friendly reminder to please list all changes to inputs,
> arguments etc in the commit message.  It makes resolving merge conflicts
> *much* easier.
>
> Due to SBCL changes on the 'staging' branch, there have been a few
> changes to the 'nyxt' inputs; and because the changes from 'master' are
> not mentioned in the commit messages, I need to manually look at each
> commit and note what has changed in order to resolve the conflict.
>
> (feel free to try merging c2396ceb onto 052939c2 to get an idea of what
> I'm talking about :-)

If you happen to be around right now, can you confirm that there were no
changes to nyxt inputs in 573489fbcd68e3a89cc5c9c66693d3689b1b88bf?


signature.asc
Description: PGP signature

Re: branch master updated: gnu: nyxt: Update to 2-pre-release-3.

[Marius Bakke]

Hello Pierre,

guix-comm...@gnu.org writes:

> commit 21e79225352a5e78aa329b6cd213eb553862c363
> Author: Pierre Neidhardt 
> AuthorDate: Tue Oct 20 15:06:59 2020 +0200
>
> gnu: nyxt: Update to 2-pre-release-3.
> 
> * gnu/packages/web-browsers.scm (nyxt): Update to 2-pre-release-3.
> ---
>  gnu/packages/web-browsers.scm | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)

[...]

> @@ -482,7 +482,8 @@ driven and does not detract you from your daily work.")
> #:strip-binaries? #f ; Stripping breaks SBCL binaries.
> #:phases
> (modify-phases %standard-phases
> - (add-after 'unpack 'patch-version ; Version is guessed from .git 
> which Guix does not have.
> + ;; Version is guessed from .git which Guix does not have.
> + (add-after 'unpack 'patch-version
> (lambda* (#:key inputs #:allow-other-keys)
>   (let ((version (format #f "~a" ,version))
> (file "source/global.lisp"))
> @@ -515,7 +516,8 @@ driven and does not detract you from your daily work.")
> ":"))
>  (gi-path (string-join
>(map (lambda (lib)
> - (string-append (assoc-ref inputs lib) 
> "/lib/girepository-1.0"))
> + (string-append (assoc-ref inputs lib)
> +"/lib/girepository-1.0"))
> libs)
>":"))
>  (xdg-path (string-join
> @@ -540,6 +542,7 @@ driven and does not detract you from your daily work.")
>   ;; See https://github.com/atlas-engineer/nyxt/issues/680.
>   `(("alexandria" ,cl-alexandria)
> ("bordeaux-threads" ,cl-bordeaux-threads)
> +   ("cl-chanl" ,cl-chanl)
> ("cl-containers" ,cl-containers)
> ("cl-css" ,cl-css)
> ("cl-json" ,cl-json)
> @@ -555,7 +558,6 @@ driven and does not detract you from your daily work.")
> ("iolib" ,cl-iolib)
> ("local-time" ,cl-local-time)
> ("log4cl" ,cl-log4cl)
> -   ("lparallel" ,cl-lparallel)
> ("mk-string-metrics" ,cl-mk-string-metrics)
> ("moptilities" ,cl-moptilities)
> ("osicat" ,sbcl-osicat) ; SBCL version needed for 
> libosicat.so.
> @@ -571,6 +573,7 @@ driven and does not detract you from your daily work.")
> ("trivial-package-local-nicknames" 
> ,cl-trivial-package-local-nicknames)
> ("trivial-types" ,cl-trivial-types)
> ("unix-opts" ,cl-unix-opts)
> +   ("usocket" ,cl-usocket)
> ;; WebKitGTK deps
> ("cl-cffi-gtk" ,cl-cffi-gtk)
> ("cl-webkit" ,cl-webkit)

This is a friendly reminder to please list all changes to inputs,
arguments etc in the commit message.  It makes resolving merge conflicts
*much* easier.

Due to SBCL changes on the 'staging' branch, there have been a few
changes to the 'nyxt' inputs; and because the changes from 'master' are
not mentioned in the commit messages, I need to manually look at each
commit and note what has changed in order to resolve the conflict.

(feel free to try merging c2396ceb onto 052939c2 to get an idea of what
I'm talking about :-)


signature.asc
Description: PGP signature

Re: Update on the timeline for the release v1.2.

[Marius Bakke]

Julien Lepiller  writes:

> Le 21 octobre 2020 11:57:48 GMT-04:00, "Ludovic Courtès"  a 
> écrit :
>>zimoun  skribis:
>>
 > The proposed coming timeline is:
 >
 >  - freeze starting the Oct. 26th
 >  - last round for testing all over the week
 >  - unfreeze the Oct. 29th and then create the branch
 >  - minor bug fixes and all the papeword around (NEWS, blog, etc.)
 >  - release Nov. 6th.

 Overall LGTM, but could you clarify what you mean by “freeze” on
 Oct. 26–29?  No “important” changes to ‘master’, including to the
 manual, is that correct?
>>>
>>> Yes, no "important" changes to 'master' which means:
>>>  - no package or service updates
>>
>>I would phrase it as no _important_ package or service updates.
>>Updating non-critical leaf packages or services is probably fine.

Agree.  Re: staging, I don't think there is anything release-critical in
it (and it may even introduce bugs, hard to tell because #44121).

>>>  - no manual entry
>>>  - only serious fixes under guix/ or installer(s)
>>>
>>> From my point of view, it is easier to freeze 'master' since
>>everybody
>>> can "guix pull" and check that everything is fine.
>>> Otherwise, instead of the freeze, let create the branch and so "guix
>>> pull --branch=version-1.2.0".  It is up to you.
>>
>>Yeah we could also branch on the 26th and cherry-pick harmless changes
>>from ‘master’, so people can still have fun on ‘master’.

Sounds good to me.

> Wouldn't that mess up with guix's authentication mechanism? If we branch v1.2 
> early, our release will have no forward path to master, so all our users will 
> get an error when running guix pull.

I think the authentication mechanism starts at a fixed point for new
users/installs (i.e. no previous 'guix pull').


signature.asc
Description: PGP signature

Re: Did nmap just become non-free?

[Marius Bakke]

Brett Gilio  writes:

> Marius Bakke  writes:
>>
>> ...I'm fairly certain this is not an acceptable license for Guix, or
>> free software distributions in general.
>>
>
> This is definitely not a consistent license for us.

Having re-read the original text (without the annotations), the thing
that stands out is:

  Proprietary software companies wishing to use or incorporate Covered
  Software within their programs must contact Licensor to purchase a
  separate license. Open source developers who wish to incorporate parts
  of Covered Software into free software with conflicting licenses may
  write Licensor to request a waiver of terms.

From <https://svn.nmap.org/nmap/LICENSE>.

So a "proprietary software company" cannot use or incorporate nmap
within a program, even if that program is free (as in software)?

>> So I think we should revert the license change, as well as the update
>> to 7.90 which introduced the new license.
>>
>> Now to read the previous license text, perhaps that will help me sleep..
>>
>
>
> As to how to fix it, I think we will need to revert the change, and also
> make note of the FINAL version of nmap that was still compliant with FSDG.

I'll see what licens...@fsf.org has to say first.

PS: Licenses make terrible bed-side reading!


signature.asc
Description: PGP signature

Did nmap just become non-free?

[Marius Bakke]

Hello,

I updated the nmap license in 2323a7120a0f3ed96fedfff42e86c0aee97995c0.
Admittedly I had only skimmed through the text, which is "based on GPL2"
and "believed to be compliant with the 'Open Source Definition'", but
after a closer read of the annotated version:

  https://nmap.org/npsl/npsl-annotated.html

...which states:

  Proprietary vendors: This license does not allow you to redistribute
  Nmap source code or the executable for use with your software (stand
  alone or on an appliance).

...I'm fairly certain this is not an acceptable license for Guix, or
free software distributions in general.

So I think we should revert the license change, as well as the update
to 7.90 which introduced the new license.

Now to read the previous license text, perhaps that will help me sleep..


signature.asc
Description: PGP signature

Re: staging freeze

[Marius Bakke]

Julien Lepiller  writes:

> Le 13 octobre 2020 17:54:16 GMT-04:00, Marius Bakke  a écrit :
>>Hello Guix,
>>
>>I've pushed a set of updates to the long-overdue "staging" branch.
>>
>>Let's get it merged once Cuirass is done building for the various
>>architectures.  Not sure how long that takes now that we no longer use
>>transparent QEMU emulation for AArch64 and armhf.
>
> I have my groovy update ready to push to staging. Can I push it, or should I 
> wait for next time staging is open?

Sure, go ahead!  I suppose we can give people a day or two to brush up
any almost-ready patches.


signature.asc
Description: PGP signature

staging freeze

[Marius Bakke]

Hello Guix,

I've pushed a set of updates to the long-overdue "staging" branch.

Let's get it merged once Cuirass is done building for the various
architectures.  Not sure how long that takes now that we no longer use
transparent QEMU emulation for AArch64 and armhf.


signature.asc
Description: PGP signature

Re: etc/news copyright (was Re: Translating the web site)

[Marius Bakke]

Julien Lepiller  writes:

> OK for me too!

Ditto for me (I think I mainly copy-pasted another news item anyway).


signature.asc
Description: PGP signature

Running service migrations during upgrades

[Marius Bakke]

Hello Guix,

Some services require administrator interaction when they are updated.
The most prominent examples here are MySQL/MariaDB and PostgresQL.

For the former, running 'mysql_upgrade' in-place is generally sufficient
and fairly safe.

For the latter, the procedure is more involved, and requires making a
full backup, as well as access to the old _and_ new PostgreSQL
packages.

There is a patch to update MariaDB here:

  https://issues.guix.gnu.org/43355

Users of mysql-service-type will need to run 'mysql_upgrade' afterwards.

I have been considering adding an AUTO-UPGRADE? parameter of
mysql-service-type that runs 'mysql_upgrade' as part of the activation
script.

Another approach is adding a 'herd upgrade' Shepherd action along with a
news entry describing what to do.  Of course it is possible to do both,
having 'auto-upgrade?' _and_ a Shepherd action for manual upgrades.

Thoughts?

While that works for MariaDB, I'm not sure what to do about Postgres.
For those unfamiliar, the procedure for upgrading from PostgreSQL 10
(current default) to 11 (available in Guix) is roughly:

  sudo cp -a /var/lib/postgresql/data /var/lib/postgresql/data10
  sudo -u postgres $(guix build postgresql)/bin/pg_upgrade \
--old-bindir=$(guix build postgresql@10)/bin \
--new-bindir=$(guix build postgresql)/bin \
--old-datadir=/var/lib/postgresql/data10 \
--new-datadir=/var/lib/postgresql/data

In order to automate it, we need to somehow preserve the "previous"
version of PostgreSQL so that we can reach it when the major version
changes.  Or add an 'upgrade-from' parameter to
postgresql-service-type.

How do other distros deal with this?

On a related note, a 'herd backup' action might be a prerequisite for
doing such potentially dangerous operations...

I will try to add a 'mysql_upgrade' pass to 'mysql-service-type' in time
for the MariaDB upgrade, but tips regarding backups, potential pitfalls,
and especially Postgres welcome.

PS: I'm mostly busy for some time still, but can be reached on #guix or
by private email if you want my feedback on something.  :-)


signature.asc
Description: PGP signature

Re: [PATCH 0/X] gnu: poetry: Fix broken dependency after dependency's version update.

[Marius Bakke]

Tanguy Le Carrour  writes:

> Hi Guix!
>
> Few days ago, I submitted a patch to update `python-tomlkit`. It was pushed
> to master and, after I upgraded my packages today, I realised that `poetry`
> (and possibly other python packages) was broken!
>
> The "problem" is that Poetry depends on `tomlkit = "^0.5.11"`. This
> translates to `>=0.5.11,<0.6.0`. And I updated `python-tomlkit` to… 0.6.0!
>
> In SemVer [1], minor releases are supposed to "add functionality
> in a backwards compatible manner", so this "<0.6.0" seems, IMHO, wrong.
> But that's not the point…
>
> [1]: https://semver.org/
>
> Now, I have to fix Poetry and I have 2 options:
> - modify poetry `setup.py` and substitute `>=0.5.11,<0.7.0` to 
> `>=0.5.11,<0.6.0`;
> - add a new `python-tomlkit-0.5` and use it in the propagated inputs.
>
> Any suggestion on the one I should implement?

I haven't looked into it, but if the tomlkit API really is compatible,
the first suggestion sounds good to me.  It would be good to notify
upstream about the unreasonable "pinning" in that case.

Otherwise the second suggestion sounds good too.  There is plenty of
precedence for both solutions in Guix and is really something that needs
to be decided on a case-by-case basis.

Thanks for finding and following up on the issue!  :-)


signature.asc
Description: PGP signature

Re: guile-readline bug -- readline module not available

[Marius Bakke]

Josh Marshall  writes:

> Hello all,
>
> I ran into an issue where the readline module isn't available for the
> guile repl after installing `guile-readline`.  It can be replicated
> via:
>
> `echo "(use-modules (ice-9 readline))" | guix environment --pure guile
> guile-readline -- guile`
>
> So with that, I'm pretty sure it isn't just me.

This is on a foreign distribution, right?

The '.guile' on Guix System has a trick that automatically loads
readline when available:

--8<---cut here---start->8---
$ cat ~/.guile
(cond ((false-if-exception (resolve-interface '(ice-9 readline)))
   =>
   (lambda (module)
 ;; Enable completion and input history at the REPL.
 ((module-ref module 'activate-readline
  (else
   (display "Consider installing the 'guile-readline' package for
convenient interactive line editing and input history.\n\n")))
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

Re: [Guix Website] A Search Page for Packages

[Marius Bakke]

Ludovic Courtès  writes:

> On berlin we’ll have to keep using nginx I guess (there’s too much
> config in there), but perhaps Varnish is an option for the Data Service.

To be clear, Varnish is not a replacement for nginx (it does not even
speak HTTPS), the typical deployment is nginx -> Varnish -> backend.  It
introduces another "hop" though.

I'm not sure if it's worth the added complexity here, just thought I'd
mention it.  It's a programming language for caching/proxying logic.


signature.asc
Description: PGP signature

Re: [Guix Website] A Search Page for Packages

[Marius Bakke]

Christopher Baines  writes:

> Ludovic Courtès  writes:
>
>> Heya Danjela,
>>
>> Daniela Lura  skribis:
>>
>>> Taking into consideration the suggestion made in this thread:
>>> https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00096.html, my
>>> mentor, Christopher Baines suggested me to write a script that serves a
>>> search page for packages using the search functionality within the Guix
>>> Data Service,
>>> https://data.guix.gnu.org/repository/1/branch/master/latest-processed-revision/packages?search_query=git=version=synopsis_name=_results=100
>>> .
>>>
>>> The prototype page can be accessed through a test version of the Guix
>>> website that Chris deployed:
>>> http://guix-website-test.cbaines.net/packages/search
>>
>> Cool!  To be clear, guix-website-test actually makes a search query on a
>> Data Service instance, right?  I guess that explains part of the
>> slowness, but maybe we could tweak nginx to keep search results in cache
>> for a few hours.
>>
>> Florian raised an important issue regarding the possibility of denial of
>> service.  Ideas on how to mitigate that, either in the Data Service, or
>> nginx at guix.gnu.org?
>
> On this point specifically, I've used the rate limiting functionality in
> NGinx before, and that's probably a low cost approach to guarding
> against this. It's not going to stop a DDOS, but might help avoid lots
> of requests from one IP address causing load issues.

We also have Varnish, a web caching proxy that excels at tasks like
this, and is used by some CDNs such as Fastly.  I'm happy to help write
a configuration if that is desired.


signature.asc
Description: PGP signature

Re: How to package inputrc

[Marius Bakke]

Efraim Flashner  writes:

> On Mon, Jul 13, 2020 at 09:30:31PM +0300, Efraim Flashner wrote:
>> On Mon, Jul 13, 2020 at 11:26:59AM -0600, Jesse Gibbons wrote:
>> > > In order to achieve this more elegant I could write a simple service to
>> > > copy the file to /etc. Another option would be a small package.
>> > 
>> > I like the service idea a lot better. It appears to me that Guix is 
>> > designed for services to deal with the more customizable parts of the 
>> > installation, whereas packages are standard. /etc/inputrc is one of those 
>> > things each system admin would want to customize, just like most of the 
>> > things in /etc.
>> 
>> I'll go ahead and link to my os-release service here. It's a small
>> service that creates an /etc/os-release file. The service in action¹ and
>> the actual service itself. It would also be possible to create an even
>> simpler file than the one I made here², with something like this:
>> 
>> (define %inputrc
>>   (plain-file "inputrc"
>>   "set show-mode-in-prompt on\n"
>>   "set enable-bracketed-paste on\n"
>>   "set editing-mode vi\n"
>>   "Control-l: clear-screen\n"
>>   "set bell-style visible\n"))
>
> The above wouldn't actually work. It needs a string-append or to not be
> multiple strings.

Or use 'mixed-text-file' instead of 'plain-file'.  Though 'string-join'
might be clearer in this case.  :-)


signature.asc
Description: PGP signature

Re: Pushed a fix (?) for ACL key location

[Marius Bakke]

Jonathan Brielmaier  writes:

> On 12.07.20 03:44, Christopher Lemmer Webber wrote:
>> Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
>> of Guix, and it looks like it wasn't possible to build new systems from
>> that because the filename for the "Berlin ACL key" changed.  (Or at
>> least, I couldn't run "guix system vm".)
>>
>> I pushed out a "fix" for this.  I hope it's ok.
>
> Thanks for the fix.
>
> As I ran into all those little errors with `guix pull` this week-end, I
> wonder if we can do better.

This particular change broke 'guix system', not 'guix pull'.  Which is
equally bad of course, but a different kind of beast entirely.

Are you referring to something else?

> So maybe some pre-checkin CI which tests that a commit/commit series
> doesn't break `guix pull`. What do you think? Is this doable?

> I find those little errors pretty annoying as they seem to be avoidable
> through technical counter measures...

One possible solution that has been discussed before is to have the CI
continously merge master to a 'stable' branch when lights are green.
There are quite a few challenges to solve with that approach though.

We could make the pre-push hook run 'guix pull' and 'guix system build'
but it will quickly get annoying.  A server-side hook for the same would
be less annoying, but would have a hard time if someone accidentally
pushes a full rebuild.

In practice there will always be problems that cannot be caught in an
automated way.  I hope such breakages are rare, but from your message it
sounds like there were many problems just this week-end?


signature.asc
Description: PGP signature

Re: Pushed a fix (?) for ACL key location

[Marius Bakke]

Christopher Lemmer Webber  writes:

> Commit 6680880f9b8dceb4f2f3f91bd2b13c659b53835e pushed out a new version
> of Guix, and it looks like it wasn't possible to build new systems from
> that because the filename for the "Berlin ACL key" changed.  (Or at
> least, I couldn't run "guix system vm".)
>
> I pushed out a "fix" for this.  I hope it's ok.

Whoops, thanks for correcting my mistake, again.  :-)

> I'm presuming this was expected to change given
> ec4c404c0575b340a04b3922fb828ac5417832dd appearing to try to compensate
> in the other direction *before* the new "guix" package version was
> pushed.

Indeed, there was even a TODO comment about it just above the changed
line, now removed.


signature.asc
Description: PGP signature

Re: hint: Run `guix search ... | less' to view all the results

[Marius Bakke]

Robin Templeton  writes:

> Seconded! The current behavior seems exactly backwards compared to most
> *nix tools; if I wanted *less* information from "guix search" I'd
> manually pipe the output into head or recsel. Perhaps Git-style
> auto-pagination (i.e. page the results when outputting to a terminal)
> would be a good compromise as a default.

I think this is exactly what 'guix search' does as of a few weeks ago?


signature.asc
Description: PGP signature

Re: Reducing Mesa closure size

[Marius Bakke]

Pierre Neidhardt  writes:

> So what the following strategy:
>
> - Extract the various mesa drivers to separate package,
>   e.g. mesa-radeon, mesa-radeonsi, mesa-nouveau, etc.

I think outputs are better suited for this.

> - Modify xorg-wrapper to accept an extra `drivers'
>   parameter.
>
> - Extend xorg-configuration to accept a list of mesa drivers.

How will this work with Wayland?

On a related note, some distributions have migrated to "libglvnd", the
"vendor neutral OpenGL dispatch library".  AIUI it installs a shim
libE?GL.so that automatically loads the appropriate driver.  Perhaps it
can be useful to achieve this goal, and it might also make hardware
acceleration work on foreign graphics drivers, which would be awesome.


signature.asc
Description: PGP signature

Re: Downloader for "wrapped" tarbar?

[Marius Bakke]

Hartmut Goebel  writes:

> Hi,
>
> was just written in another mail, I'm currently working on a
> erlang/rebar build system. This includes an importer from hex.pm, a
> package repository for elixir and erlang packages. (Since this is build
> into rebar3 I assume it what PyPI is for Python and CPAN for Perl.)
>
> At hex.pm, packages are provided in a tarfile [1] wrapping the source
> tar-file:
>
> -rw-r--r-- 0/0   1 2017-06-14 21:57 VERSION
> -rw-r--r-- 0/0  64 2017-06-14 21:57 CHECKSUM
> -rw-r--r-- 0/0 532 2017-06-14 21:57 metadata.config
> -rw-r--r-- 0/0    4744 2017-06-14 21:57 contents.tar.gz
>
> IMHO it does not make sense to keep this wrapping tar-file in the store.
>
> So my idea is to create a "hexpm-fetch" method, which downloads the
> tar-file and only stores the "content.tar.gz" in the store (using a
> proper name, of course).
>
> How can this be done?

Tarballs from rubygems.org has the same problem and works around it by
special support in ruby-build-system.

It would be ideal to have an origin method that could extract the
"inner" tarball, i.e. contents.tar.gz for hex.pm and data.tar.gz in the
case of RubyGems.  As zimoun mentioned, a good place to start is look at
how other origin methods are implemented such as url-fetch/tarbomb, etc.


signature.asc
Description: PGP signature

Re: branch staging updated: gnu: ghc-7: Clean up package definition.

[Marius Bakke]

guix-comm...@gnu.org writes:

> This is an automated email from the git hooks/post-receive script.
>
> niedzejkob pushed a commit to branch staging
> in repository guix.
>
> The following commit(s) were added to refs/heads/staging by this push:
>  new f20d1cf  gnu: ghc-7: Clean up package definition.
> f20d1cf is described below
>
> commit f20d1cfb51ed14f325da000406807076323f70bc
> Author: Jakub Kądziołka 
> AuthorDate: Wed Apr 8 12:21:42 2020 +0200
>
> gnu: ghc-7: Clean up package definition.
> 
> * gnu/packages/haskell.scm (ghc-7)[modules, imported-modules]: Remove
>   the unused rpath module.
>   [phases]: Use invoke instead of system*.

Thanks!  Unfortunately the staging branch was recently 'frozen':

  https://lists.gnu.org/archive/html/guix-devel/2020-05/msg00373.html

I was about to revert the commit, but as GHC currently only builds on
i686 and x86_64 and the CI is "half way there" already, perhaps we can
let it slide:

  https://ci.guix.gnu.org/eval/13961?status=failed

We should have a better way to poll branch status other than "read all
messages on guix-devel" or "ask Marius on IRC".


signature.asc
Description: PGP signature

Re: Git repos with large submodules

[Marius Bakke]

raingloom  writes:

> Hey all!
>
> So, I recently gave a go to packaging EDK2 on my channel, and found out
> that it requires several submodules, including OpenSSL, which take up
> quite a bit of space and take way longer to download than necessary.
>
> Since I couldn't find a way to shallow-init the submodules, I added
> them as separate origins and copied / symlinked them after the unpack
> phase.

That sounds like a decent workaround.  Even better to symlink
(package-source openssl) to use the OpenSSL sources from Guix.

The ideal solution would of course be to provide OpenSSL as a regular
input and make the build system use it, but that's not always feasible.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add font-sarasa-gothic

[Marius Bakke]

Zhu Zihao  writes:

> You miss the right angle bracket in the copyright line
>
> It should be
>
> ;;; Copyright © 2020 Zhu Zihao 

Good catch, fixed in a8c7d4b0c326905b71680783ced6b68d25fb3bfd, thanks!


signature.asc
Description: PGP signature

Re: [PATCH] gnu: Add font-sarasa-gothic

[Marius Bakke]

Zhu Zihao  writes:

> This patch adds Sarasa Gothic. Sarasa Gothic is based on Iosevka and Source 
> Han
> Sans, intends to make a really monospaced(inclduing CJK characters) 
> programming
> fonts. In Sarasa Gothic, a normal CJK character is same height and double 
> width
> as an ASCII character.

Thanks!  Applied with the following changes, hope the copyright line was
okay:

diff --git a/gnu/packages/fonts.scm b/gnu/packages/fonts.scm
index 3c7361f162..f60d4f80fb 100644
--- a/gnu/packages/fonts.scm
+++ b/gnu/packages/fonts.scm
@@ -34,6 +34,7 @@
 ;;; Copyright © 2020 John Soo 
 ;;; Copyright © 2020 Raghav Gururajan 
 ;;; Copyright © 2020 Julien Lepiller 
+;;; Copyright © 2020 Zhu Zihao https://github.com/be5invis/Sarasa-Gothic;)
 (license license:silofl1.1)
 (synopsis "Sarasa Gothic / 更纱黑体 / 更紗黑體 / 更紗ゴシック / 사라사 고딕")


signature.asc
Description: PGP signature

Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Ludovic Courtès  writes:

> Hi!
>
> Marius Bakke  skribis:
>
>> I have good news and bad news.  The good news is that the new commit
>> verification infrastructure works great.  'make authenticate' will
>> verify that all commits were signed by a key that was authorized by
>> .guix-authorizations at that point in time.
>>
>> The bad news is that we need to ensure .guix-authorizations has been
>> updated on any branches that new committers/keys will be pushing to.
>> Currently the 'staging' branch has one commit
>> (8229ce3116c1f522c7157ab2dcd50dc2d765686a) signed by a
>> not-yet-authorized key (it had been authorized on 'master' by
>> d074f73aacc5a39aed0202d6e45721f53f34a8c0, but that was not yet merged to
>> 'staging' at the time).
>>
>> To fix it properly without leaving a gap where 'make authenticate' will
>> fail, we actually need to rewrite the history.  Luckily git supports
>> rebasing merges(!), and the merge we need was the next commit on that
>> branch.
>
> To be clear, it wouldn’t just “leave a gap”: all future commits would
> also be rejected.  The authentication code ensures that each commit is
> signed by one of the keys authorized in its parent commit(s).  (See the
> latest discussions at <https://issues.guix.gnu.org/22883>.)

Indeed, sorry for being unclear.  The gap I was referring to was based
on a hypothetical situation where we worked around this issue in
git-authenticate.scm, similar to %commits-with-known-bad-signature.

> This is a good opportunity to remind all fellow committers of the latest
> changes in that area, which are summarized here:
>
>   https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html
>
> Please take a look.
>
> SCARY WARNING:
>
>   When ‘guix pull’ runs that authentication code, which I hope will be
>   the case in a few weeks, any such mistakes means that users will not
>   be able to pull at all, so we all have to be very cautious.  If we do
>   make a mistake, we’ll have to reset the branch to a known-good state,
>   like you did.

I am really looking forward to strong authentication in 'guix pull'.
Sounds like a good excuse to make a new release!  :-)

> That said… thanks *a lot* for carrying out this rebase, Marius!  I’ve
> never done a rebase including merge commits before (sounds scary!), and
> I learned that ‘git rerere’ is not a typo.  Thumbs up!

Rebasing merges was a first for me too, and hopefully a last!  I only
learned about (and enabled) 'git rerere' recently and it has saved me a
lot of time already, mainly when a merge had to be aborted and redone.

But it's a double edged sword, no wonder it's not enabled by default.


signature.asc
Description: PGP signature

Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Marius Bakke  writes:

> Marius Bakke  writes:
>
>> I have pushed a 'staging2' branch where I did the following:
>>
>>  1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~
>>
>>  2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after
>> f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes
>> .guix-authorizations) -- it was "one step down" in Magits interactive
>> rebase menu.
>>
>>  3) "solved" three merge conflicts (actually git rerere remembered the
>> resolutions, and I could have used git rebase --rerere-autoupdate to
>> make the process entirely automatic).
>>
>> I intend to move the current 'staging' branch to 'staging-old', and
>> rename 'staging2' to 'staging' once I'm fully confident in the result
>> and resolution.
>
> Of course I sent this before actually testing the branch!  'git rerere'
> had forgotten a very important merge resolution from
> 354880e7209a2aec0360dfe5b08b1873c084e2dd: the "tzdata-for-tests" package
> needs to be kept on version 2019c during that merge to prevent a
> full rebuild via "python".
>
> I will do a new rebase tomorrow and make sure each of the merges are
> correct.

So the three merges that needed rebasing were:

  f00270d35a6ca814903a9392caedc29d44959088
  1ffd7a7e514072039a1bc92eb1a09b8119b06c91
  34d8640b1a85198fa060a6ddbdbf10ad6e2415ea

During the first, apart from the _actual_ (git style) conflict,
tzdata-for-tests needed manual merging as mentioned earlier.

I solved it by "git checkout f00270d35 -- gnu/packages/base.scm" during
the merge.

For 1ffd7a7e there was another "hidden" (not detected by git) conflict
in gnu/packages/cups.scm, though not as grave (only a leftover
variable).  Solved by "git checkout 1ffd7a7e --
gnu/packages/cups.scm".

34d8640b1 did not have any surprise conflicts.

The new rebased merges are:

  9edb3f66fd807b096b48283debdcddccfea34bad
  aa13c5657d4f8b5dd52beda88a9a8ccc59ebca86
  8a7a5dc7805f4628e60f90af6b2416f951d0c034

They should be identical to the previous merges, with one difference:
the first merge no longer has a conflict in linux.scm because it was
moved to the rebased ddcfc467968d8367e62cb24cbc9e89bb5af0fe6d.

The new 'staging' branch have these rebased merges and is identical to
the previous 'staging' (excluding .git).  The previous branch is
available as 'staging-old' for the time being in case anyone wants to
verify.

In the future I'll be annotating such "hidden" merge conflicts in the
commit message somehow (perhaps using the regular ChangeLog style).  I
hope we don't need to perform branch surgery again, but there are
legitimate cases for making similar merges to different branches.

Another key takeaway is that 'git rerere' does not remember any
"manual" merge resolutions: it only saves resolutions for things that
would introduce the regular git conflict markers.

If you read this far, I'm sorry!  Happy to say the situation is under
control and the staging branch will continue its normal operation
shortly.  :-)


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> You can run it directly from a shell, and/or attach a debugger.
>
> Thanks for the tip.
>
> Any idea how to attach Geiser to it?

The daemon is a C++ program, so I'm not sure that would work ...

If you are trying to increase the trace width within a build expression,
you probably just need to (setenv "COLUMNS" "200") in the builder.


signature.asc
Description: PGP signature

Re: Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Marius Bakke  writes:

> I have pushed a 'staging2' branch where I did the following:
>
>  1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~
>
>  2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after
> f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes
> .guix-authorizations) -- it was "one step down" in Magits interactive
> rebase menu.
>
>  3) "solved" three merge conflicts (actually git rerere remembered the
> resolutions, and I could have used git rebase --rerere-autoupdate to
> make the process entirely automatic).
>
> I intend to move the current 'staging' branch to 'staging-old', and
> rename 'staging2' to 'staging' once I'm fully confident in the result
> and resolution.

Of course I sent this before actually testing the branch!  'git rerere'
had forgotten a very important merge resolution from
354880e7209a2aec0360dfe5b08b1873c084e2dd: the "tzdata-for-tests" package
needs to be kept on version 2019c during that merge to prevent a
full rebuild via "python".

I will do a new rebase tomorrow and make sure each of the merges are
correct.

Meanwhile, do not pull 'staging2' unless you are freezing and the 
computer is your main heat source.


signature.asc
Description: PGP signature

Heads-up: hard reset of the 'staging' branch

[Marius Bakke]

Guix,

I have good news and bad news.  The good news is that the new commit
verification infrastructure works great.  'make authenticate' will
verify that all commits were signed by a key that was authorized by
.guix-authorizations at that point in time.

The bad news is that we need to ensure .guix-authorizations has been
updated on any branches that new committers/keys will be pushing to.
Currently the 'staging' branch has one commit
(8229ce3116c1f522c7157ab2dcd50dc2d765686a) signed by a
not-yet-authorized key (it had been authorized on 'master' by
d074f73aacc5a39aed0202d6e45721f53f34a8c0, but that was not yet merged to
'staging' at the time).

To fix it properly without leaving a gap where 'make authenticate' will
fail, we actually need to rewrite the history.  Luckily git supports
rebasing merges(!), and the merge we need was the next commit on that
branch.

I have pushed a 'staging2' branch where I did the following:

 1) git rebase -i --rebase-merges 8229ce3116c1f522c7157ab2dcd50dc2d765686a~

 2) Moved 8229ce3116c1f522c7157ab2dcd50dc2d765686a after
f00270d35a6ca814903a9392caedc29d44959088 (the first merge that includes
.guix-authorizations) -- it was "one step down" in Magits interactive
rebase menu.

 3) "solved" three merge conflicts (actually git rerere remembered the
resolutions, and I could have used git rebase --rerere-autoupdate to
make the process entirely automatic).

I intend to move the current 'staging' branch to 'staging-old', and
rename 'staging2' to 'staging' once I'm fully confident in the result
and resolution.

In the mean time, comments or replications of the experiment welcome.

In other good news, the new pre-push hook proposed by Ludovic in

will eliminate this issue as long as people remember to activate it.
For total confidence we should perform it on the server side though.

Sorry for the inconvenience!


signature.asc
Description: PGP signature

Re: Can we increase the print width/column in daemon backtraces

[Marius Bakke]

Pierre Neidhardt  writes:

> Ludovic Courtès  writes:
>
>> Users are not supposed to see backtraces coming from the daemon or its
>> helpers (‘guix substitute’, ‘guix offload’, etc.).
>
> How are we supposed to debug Guix daemon errors?

You can run it directly from a shell, and/or attach a debugger.

I agree that if a failure happens on the daemon level, Guix should print
an actionable error message instead of a confusing back trace.


signature.asc
Description: PGP signature

Staging freeze!

[Marius Bakke]

Guix,

The 'staging' branch has seen plenty of changes recently and is now
"frozen".

Changes in the current iteration include Mesa 20.0.7, Rust 1.39 as the
default Rust compiler, Qt 5.14.2, KDE Frameworks 5.70, updates and
overhaul of all Vulkan packages, and lots of other minor changes.

Testers wanted!


signature.asc
Description: PGP signature

Release Guix 1.1.1?

[Marius Bakke]

Hello Guix,

The installer has seen a few bugfixes since the 1.1.0 release, and
guix-install.sh has also had a face lift.  Not to mention the big
"core-updates" merge that broke everyones fonts, but also brought
goodies such as GNOME 3.34.

What do y'all think about targeting a 1.1.1 release a few weeks from
now?

Any milestones we should try to complete before an eventual release?


signature.asc
Description: PGP signature

Re: [PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of gs-fonts.

[Marius Bakke]

Leo Famulari  writes:

> On Sun, May 17, 2020 at 04:50:12PM +0200, Marius Bakke wrote:
>> This is a hack to make (some) fonts working when users don't have fonts
>> specified in their system configuration, and (crucially) places where
>> the fontconfig cache may be unavailable such as 'guix pack's.
>> 
>> I'm not sure whether font-dejavu is a good replacement here.  Another
>> approach could be to convert gs-fonts to TrueType or OpenType format.
>> 
>> Thoughts?  I don't know much about fonts and would appreciate feedback.
>
> I think you should push right away, assuming that it helps and doesn't
> rebuild the world.

I pushed the patch as ab9de8cfb0525ef43668712ac898707f97f9a620.

I verified that it fixes the immediate problem with fonts in the Guix
manual (#41282) as well as 'guix pack' (#41344).  It should also provide
a decent fallback for cases where the user did not explicitly install
any fonts such as in #41241.

Hoping for angry reports now about why such a poor replacement font was
chosen.  ;-)


signature.asc
Description: PGP signature

Re: [PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of gs-fonts.

[Marius Bakke]

zimoun  writes:

> On Wed, 20 May 2020 at 15:55, Marius Bakke  wrote:
>> zimoun  writes:
>
>> > Apparently, there is different fonts on master and core-updates, if yes 
>> > why?
>>
>> The only known difference since the core-updates merge is that
>> applications using Pango (e.g. GTK+) no longer recognizes bitmap fonts.
>>
>>   https://gitlab.gnome.org/GNOME/pango/issues/386
>
> Thank you for the pointer but I think it is another issue.
>
>
>> > I mean, on my machine -- Guix on the top of Debian with font-dejavu
>> > installed -- why does commit 4bdf4182fe (core-update merge) not
>> > display correctly and the parent commit c81457a588 too but the other
>> > parent commit 23a59b180b displays nicely?
>>
>> Leo reported problems with fonts on Debian in
>> <https://issues.guix.gnu.org/issue/41132>, but said that fonts installed
>> with Guix still worked.  I don't know what could cause it to fail on
>> your system.
>
> Thank for the pointer, it seems the same issue.  But I am not sure
> because I am using the font from Guix.
>
> Well, I have font-dejavu-2.37 and fontconfig-2.13.1 installed in
> ~/.guix-profile from Guix e98689f.
>
>
> When I run
>
> guix pull --commit=4bdf4182fe -p /tmp/bad
>
> then
>
>display  /tmp/bad/share/info/images/bootstrap-graph.png
>
> there is an issue.  Note that 'imagemagick' is installed in
> ~/.guix-profile using the same commit above.
>
>
> The commit 4bdf4182fe is the commit of merge.  If I pull from the
> (left) parent commit, i.e., the commit c81457a588,
>
>   guix pull --commit=c81457a588 -p /tmp/left
>
> then
>
>   display  /tmp/right/share/info/images/bootstrap-graph.png
>
> displays nicely and the font is correct.  However, if I pull form the
> (right) parent commit, i.e., the commit 23a59b180b,
>
>   guix pull --commit=23a59b180b -p /tmp/right
>
> then
>
>   display  /tmp/right/share/info/images/bootstrap-graph.png
>
> displays wrongly.  Well, I have changed nothing, considering the
> fonts.  And the only difference is commit from "master" vs from
> "core-updates".  And as I explained [1], it always happens when
> core-updates is merged.

Missing fonts in the manual is another known issue and was not clear
from your initial message: <https://issues.guix.gnu.org/issue/41418>.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of gs-fonts.

[Marius Bakke]

zimoun  writes:

> Apparently, there is different fonts on master and core-updates, if yes why?

The only known difference since the core-updates merge is that
applications using Pango (e.g. GTK+) no longer recognizes bitmap fonts.

  https://gitlab.gnome.org/GNOME/pango/issues/386

> I mean, on my machine -- Guix on the top of Debian with font-dejavu
> installed -- why does commit 4bdf4182fe (core-update merge) not
> display correctly and the parent commit c81457a588 too but the other
> parent commit 23a59b180b displays nicely?

Leo reported problems with fonts on Debian in
, but said that fonts installed
with Guix still worked.  I don't know what could cause it to fail on
your system.


signature.asc
Description: PGP signature

Re: [PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of gs-fonts.

[Marius Bakke]

Leo Famulari  writes:

> On Sun, May 17, 2020 at 04:50:12PM +0200, Marius Bakke wrote:
>> This is a hack to make (some) fonts working when users don't have fonts
>> specified in their system configuration, and (crucially) places where
>> the fontconfig cache may be unavailable such as 'guix pack's.
>> 
>> I'm not sure whether font-dejavu is a good replacement here.  Another
>> approach could be to convert gs-fonts to TrueType or OpenType format.
>> 
>> Thoughts?  I don't know much about fonts and would appreciate feedback.
>
> I think you should push right away, assuming that it helps and doesn't
> rebuild the world.

Someone on #guix wanted to test it, so I've attached the patch here
again to this message.

Will push later today unless anyone objects.  Though I'm still not
convinced 'font-dejavu' is a good replacement for 'gs-fonts'.

> The gs-fonts are important for printing so we might need a real fix
> later but for now a quick fix is the right thing.

The print infrastructure (CUPS, ghostscript) does not use Pango, so I
think gs-fonts still work there.

Might be difficult to work with when the end user applications don't
recognize them though.

What do you expect from a "real fix"?

From ba3a99430ce1c0f6f27973e1d82539a67c769b89 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 17 May 2020 16:23:29 +0200
Subject: [PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of
 gs-fonts.

This fixes <https://bugs.gnu.org/41282>, <https://bugs.gnu.org/41241>, and <https://bugs.gnu.org/41344>.
Reported by Pierre Neidhardt, W Knight, Alexandros Theodotou, and others.

* gnu/packages/fontutils.scm (fontconfig)[replacement]: New field.
(fontconfig/font-dejavu): New variable.
---
 gnu/packages/fontutils.scm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gnu/packages/fontutils.scm b/gnu/packages/fontutils.scm
index e552ece50b..27c84d5814 100644
--- a/gnu/packages/fontutils.scm
+++ b/gnu/packages/fontutils.scm
@@ -37,6 +37,7 @@
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages autotools)
+  #:use-module (gnu packages fonts)
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages python)
   #:use-module (gnu packages python-xyz)
@@ -292,6 +293,12 @@ fonts to/from the WOFF2 format.")
 (define-public fontconfig
   (package
(name "fontconfig")
+
+   ;; This replacement is not security-related, but works around the fact
+   ;; that gs-fonts are not recognized by Pango, causing many applications
+   ;; to fail to find fonts otherwise.
+   (replacement fontconfig/font-dejavu)
+
(version "2.13.1")
(source (origin
 (method url-fetch)
@@ -348,6 +355,13 @@ high quality, anti-aliased and subpixel rendered text on a display.")
"See COPYING in the distribution."))
(home-page "https://www.freedesktop.org/wiki/Software/fontconfig;)))
 
+(define fontconfig/font-dejavu
+  (package
+(inherit fontconfig)
+(inputs
+ ;; XXX: Reuse the name to avoid having to override the configure flags.
+ `(("gs-fonts" ,font-dejavu)
+
 (define-public t1lib
   (package
(name "t1lib")
-- 
2.26.2



signature.asc
Description: PGP signature

Re: [bug#41382] [PATCH 0/6] Allow for a cryptographic hash function migration

[Marius Bakke]

Ludovic,

(+ guix-devel)

Ludovic Courtès  writes:

> Hello,
>
> Ludovic Courtès  skribis:
>
>> Another option would be to create a  data type that specifies
>> its algorithm and its value.  We’d replace the ‘sha256’ field with
>> a ‘hash’ field of that type (in a backward-compatible way).  Thinking
>> about it, this is perhaps the better option.
>
> Here’s a v2 that does that: instead of adding a ‘sha512’ field to
> , it replaces the ‘sha256’ field with ‘hash’ and introduces a
>  data type (similar to the  data type we have).
>
> One can now write things like:
>
>   (origin
> ;; …
> (hash (content-hash (base64 "…") sha512)))
>
> Since it’s a bit verbose, one can also pass a literal string directly,
> in which case it’s base32-decoded:
>
>   (origin
> ;; …
> (hash (content-hash "…")))
>
> ‘content-hash’ uses macrology to validate as much as possible at
> macro-expansion time.
>
> There’s a compatibility ‘origin’ macro intended to allow people to keep
> writing:
>
>   (origin
> (url …)
> (method …)
> (sha256 …))
>
> and to automatically “convert” the ‘sha256’ field specification to a
> ‘content-hash’.  Due to the way identifiers are matched, there are cases
> where we can’t preserve the illusion of compatibility, as can be seen
> with the patch below.  Perhaps that’s acceptable, though.
>
> Thoughts?

This is a great initiative, and the patches LGTM.

I think that if we are to move away from SHA256, we should go with
something that is immune to length extension attacks[0] such as BLAKE2/3
or SHA-3 (Keccak).

Although I don't know any Guile implementations of those as of yet.

SHA512 does not improve much security-wise IMO, but maybe it's
worthwhile as s stop-gap.

0: https://en.wikipedia.org/wiki/Length_extension_attack


signature.asc
Description: PGP signature

[PATCH] gnu: fontconfig: Add replacement with font-dejavu instead of gs-fonts.

[Marius Bakke]

This fixes  and .
Reported by Pierre Neidhardt, W Knight, and others.

* gnu/packages/fontutils.scm (fontconfig)[replacement]: New field.
(fontconfig/font-dejavu): New variable.
---
Guix,

This is a hack to make (some) fonts working when users don't have fonts
specified in their system configuration, and (crucially) places where
the fontconfig cache may be unavailable such as 'guix pack's.

I'm not sure whether font-dejavu is a good replacement here.  Another
approach could be to convert gs-fonts to TrueType or OpenType format.

Thoughts?  I don't know much about fonts and would appreciate feedback.

---
 gnu/packages/fontutils.scm | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/gnu/packages/fontutils.scm b/gnu/packages/fontutils.scm
index e552ece50b..27c84d5814 100644
--- a/gnu/packages/fontutils.scm
+++ b/gnu/packages/fontutils.scm
@@ -37,6 +37,7 @@
   #:use-module (gnu packages perl)
   #:use-module (gnu packages pkg-config)
   #:use-module (gnu packages autotools)
+  #:use-module (gnu packages fonts)
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages python)
   #:use-module (gnu packages python-xyz)
@@ -292,6 +293,12 @@ fonts to/from the WOFF2 format.")
 (define-public fontconfig
   (package
(name "fontconfig")
+
+   ;; This replacement is not security-related, but works around the fact
+   ;; that gs-fonts are not recognized by Pango, causing many applications
+   ;; to fail to find fonts otherwise.
+   (replacement fontconfig/font-dejavu)
+
(version "2.13.1")
(source (origin
 (method url-fetch)
@@ -348,6 +355,13 @@ high quality, anti-aliased and subpixel rendered text on a 
display.")
"See COPYING in the distribution."))
(home-page "https://www.freedesktop.org/wiki/Software/fontconfig;)))
 
+(define fontconfig/font-dejavu
+  (package
+(inherit fontconfig)
+(inputs
+ ;; XXX: Reuse the name to avoid having to override the configure flags.
+ `(("gs-fonts" ,font-dejavu)
+
 (define-public t1lib
   (package
(name "t1lib")
-- 
2.26.2

Re: Out-of-date Mesa

[Marius Bakke]

Pierre Neidhardt  writes:

> Hi!
>
> I see that our Mesa 19.3.4 is out-of-date.  20.0.0 was released last February 
> and
> 20.0.7 was released on May 14th:
>
> https://mesa3d.org/

The 'staging' branch has Mesa 20.0.7.

> I'm wondering why a recent Mesa wasn't including in the last core-update
> merge.  Any specific reason?

Because 'core-updates' has has been "frozen" for a long time, and
concerns itself with more low-level packages.

Mesa typically gets updated on 'staging' despite the massive rebuild
count.  But no one has made the effort to update Mesa until recently.

The Vulkan packages are probably out of date too, as Rutger appears to
have moved on.  Help wanted!


signature.asc
Description: PGP signature

Re: core-updates all over again :)

[Marius Bakke]

Christopher Baines  writes:

> Hey,
>
> So, given that core-updates was recently merged, I guess it's time to
> start the branch again?
>
> I've got two patches in mind, [1] for parallel xz compression during the
> unpack phase if the build is happening in parallel, and [2] to enable
> p11-kit in gnutls.
>
> 1: https://issues.guix.info/issue/33643
> 2: https://issues.guix.info/issue/40654

For [2], you could define a 'gnutls+p11-kit' and use that in libcacard
for now, instead of having to wait N months for the branch to start
rolling (during which time things may change in libcacard or GnuTLS).

> There's also updating Ruby to 2.7 which can at least be considered for
> core-updates, I've seen some 2.7 incompatibilities in various Ruby
> libraries, but it's worth looking at.

Maybe we should have a 'package-with-ruby27' procedure, similar to
'package-with-python2'?  Then we don't need to wait for core-updates to
try this either.  :-)

> The above patches could do with a bit more review, but is there any
> formalities in terms of getting core-updates going again?

The job specification needs to be re-added on Cuirass, but other than
that it should be "safe to push".


signature.asc
Description: PGP signature

Re: Some packages failing to build

[Marius Bakke]

Guillaume Le Vaillant  writes:

> Guillaume Le Vaillant  skribis:
>
>> Hi,
>>
>> After pulling guix with the merged core updates (guix at commit
>> 95ffdfe86cb1b8a8e4fff1386a147718400b76e0), I found a few packages
>> failing to build:
>>
>>  - fbreader
>>  - gnubg
>>  - gnubik
>>  - postgis
>>  - python-cheetah
>>  - python-trezor
>>
>> I have not yet had the time to try and fix them, so I just list them
>> here in case someone wants to take a look at them.
>
> Update: postgis and python-cheetah fixed.

fbreader, gnubg and gnubik fixed.

Thanks!


signature.asc
Description: PGP signature

core-updates merged!

[Marius Bakke]

Guix,

The mythical 'core-updates' branch was just merged to 'master'!

You will notice newer versions of many "core" packages such as glibc,
findutils, make, etc; see 'guix pull --news' for the scoop.  The mailing
list has a (non-exhaustive) overview of the big changes this round:

  https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00412.html

Please report any problems you find to bug-g...@gnu.org.

Enjoy!


signature.asc
Description: PGP signature

Re: branch master updated: gnu: gnome-todo: Fix build.

[Marius Bakke]

Hi Danny,

guix-comm...@gnu.org writes:

> commit b17b29454d5edd61eecb4536461789b7a3865a9a
> Author: Danny Milosavljevic 
> AuthorDate: Wed May 6 17:36:03 2020 +0200
>
> gnu: gnome-todo: Fix build.
> 
> * gnu/packages/patches/gnome-todo-delete-esource-duplicate.patch: New 
> file.
> * gnu/packages/gnome.scm (gnome-todo)[source]: Add it.
> * gnu/local.mk (dist_patch_DATA): Add it.

Thanks for fixing GNOME Todo!

[...]

> diff --git a/gnu/packages/patches/gnome-todo-delete-esource-duplicate.patch 
> b/gnu/packages/patches/gnome-todo-delete-esource-duplicate.patch
> new file mode 100644
> index 000..9e9c2e2
> --- /dev/null
> +++ b/gnu/packages/patches/gnome-todo-delete-esource-duplicate.patch
> @@ -0,0 +1,7 @@
> +--- gnome-todo-3.28.1/plugins/eds/gtd-eds-autoptr.h.orig 2020-05-06 
> 14:20:49.589902539 +0200
>  gnome-todo-3.28.1/plugins/eds/gtd-eds-autoptr.h  2020-05-06 
> 14:20:54.593919721 +0200
> +@@ -25,4 +25,3 @@
> + G_DEFINE_AUTOPTR_CLEANUP_FUNC (ECalComponent, g_object_unref);
> + G_DEFINE_AUTOPTR_CLEANUP_FUNC (ECalComponentId, e_cal_component_free_id);
> + G_DEFINE_AUTOPTR_CLEANUP_FUNC (ECalClient, g_object_unref);
> +-G_DEFINE_AUTOPTR_CLEANUP_FUNC (ESource, g_object_unref);

Can you add a short comment at the top of the patch file explaining what
this does, along with links to relevant upstream commits/issues (if
applicable)?

That way future packagers don't have to reverse-engineer your patch to
figure out what it does / whether it is still needed.

TIA!  :-)


signature.asc
Description: PGP signature

Re: branch master updated: gnu: Add warsow-qfusion.

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>> On a related note, the 'ccl' package has a similar issue, and actually
>> produces an invalid derivation on aarch64 and armhf.  It can be seen by
>> running e.g. 'guix weather -s armhf-linux'.  I've been meaning to file a
>> bug about it forever, but typically just comment the package and forget
>> about it.  :-/
>
> I don't understand why the `ccl' package would have an invalid
> derivation on armhf-linux: All `match' seem to be correct, but I can't
> test at the moment.  Are you sure this is a similar issue?

Admittedly it's only tangentially related.  It is really easy to test by
running 'guix build -s armhf-linux --no-grafts -d ccl'.


signature.asc
Description: PGP signature

Re: branch master updated: gnu: Add warsow-qfusion.

[Marius Bakke]

Pierre Neidhardt  writes:

> Marius Bakke  writes:
>
>>>> +  (let ((commit "c4de15df559410aff0ca6643724e24cddb0ecbbd")
>>>> +(arch (match (or (%current-target-system)
>>>> + (%current-system))
>>>> +("x86_64-linux" "x86_64")
>>>> +("i686-linux" "i386")
>>>> +(_ ""
>>>> Don't do this if you just need to determine architecture at build time.
>>>
>>> Just to be sure, you suggest moving this inside the 'really-install
>>> phase, right?
>>
>> Yes.  Otherwise it gets needlessly evaluated by the Guix "front-end"
>> every time one uses 'guix search' etc -- even on unsupported
>> architectures.  It's better to do it at build time, especially when it
>> is only used within a single phase.
>
> I don't understand the difference.
>
> (match (or (%current-target-system)
>(%current-system))
>("x86_64-linux" "x86_64")
>("i686-linux" "i386"))
>
> must be unquoted inside the phase, so it's evaluated when the package
> is and not at build time, isn't it?
>
> Else how do you match against the build architecture at build time?

You can use (lambda* (#:key target system #:allow-other-keys)) to access
those variables at build time.


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Christopher Baines  writes:

> Marius Bakke  writes:
>
>> Please try upgrading your profiles and systems and file bugs for
>> anything that does not work for you.  GNOME users in particular are
>> encouraged to try the new GNOME 3.34 and report any regressions.
>
> I did some testing today, I managed to upgrade my profile after I
> excluded flightgear, hplip and unknown-horizons (this fails to build on
> master as well).

FlightGear is fairly outdated, I suspect that there are patches upstream
to allow building with the latest Boost.

> I've got a patch to fix python-s3transfer [1].
>
> 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41027

Oh, great that you brought it upstream.  The change LGTM.

> As for reconfiguring my system, I use hplip with the CUPS service, so
> that doesn't work. I did have a look at hplip but I got lost in the
> configure script. I did find something related to Fedora [2].
>
> 2: https://bugzilla.redhat.com/show_bug.cgi?id=1706233
> 3: 
> https://src.fedoraproject.org/rpms/hplip/c/2268f0b1bdc4abce391458a5c90500d37ed438b6?branch=master

I fixed hplip in commit 68c7f577d8cbb1a11a812e36c7ae1e34ccc57e62.  I did
not look at these reports, so let me know if you think something else
should be done.

> The other issue I ran in to when trying to build my system was the
> channel/inferior I use for Linux didn't work. I've raised [4] regarding
> this.
>
> 4: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41028

I haven't looked into this, but is the inferior from before
commit 05e783871c2c69b402e088863d46f5be7915ac74?

Not sure how we can provide backwards-compatibility in this case.


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Timothy Sample  writes:

> Hi Marius,
>
> Marius Bakke  writes:
>
>> The "core-updates" branch is ready for testing!  [...]
>>
>> Please try upgrading your profiles and systems and file bugs for
>> anything that does not work for you.  GNOME users in particular are
>> encouraged to try the new GNOME 3.34 and report any regressions.
>
> Just so you know, GNOME 3.34 is working swimmingly for me.  So far I am
> a very happy core-updates user.  Thank you very much for all your hard
> work!

Great to know, thanks!  Credits to Kei for the GNOME 3.34 upgrade.  :-)

I think the only remaining blocker is fixing the WebKitGTK+ sandbox
issue in Epiphany: <https://issues.guix.gnu.org/issue/40837>.

Chris also reported an issue with FlighGear.  Presumably updating to the
latest version would make it work with the newer Boost.  Any takers?

@everyone, please speak up if you find any of your packages failing on
the core-updates branch!  The substitute coverage is currently ~90%,
which is better than on 'master'.


signature.asc
Description: PGP signature

Re: branch master updated: gnu: Add warsow-qfusion.

[Marius Bakke]

Pierre Neidhardt  writes:

> Hi Marius,
>
> Sorry, I rebased and edited a few things, some changes slipped through
> and resulted in this terrible commit :(
>
>> +  (let ((commit "c4de15df559410aff0ca6643724e24cddb0ecbbd")
>> +(arch (match (or (%current-target-system)
>> + (%current-system))
>> +("x86_64-linux" "x86_64")
>> +("i686-linux" "i386")
>> +(_ ""
>> Don't do this if you just need to determine architecture at build time.
>
> Just to be sure, you suggest moving this inside the 'really-install
> phase, right?

Yes.  Otherwise it gets needlessly evaluated by the Guix "front-end"
every time one uses 'guix search' etc -- even on unsupported
architectures.  It's better to do it at build time, especially when it
is only used within a single phase.

On a related note, the 'ccl' package has a similar issue, and actually
produces an invalid derivation on aarch64 and armhf.  It can be seen by
running e.g. 'guix weather -s armhf-linux'.  I've been meaning to file a
bug about it forever, but typically just comment the package and forget
about it.  :-/


signature.asc
Description: PGP signature

Re: branch master updated: gnu: Add warsow-qfusion.

[Marius Bakke]

Hi Pierre,

guix-comm...@gnu.org writes:

> commit 39f1806ca1d04b9aee70e897e06466aadbbee152
> Author: Pierre Neidhardt 
> AuthorDate: Thu Apr 9 15:56:42 2020 +0200
>
> gnu: Add warsow-qfusion.
> 
> * gnu/local.mk (warsow-qfusion): New variable.

This commit message is weird.

> ---
>  gnu/local.mk  |  1 +
>  gnu/packages/game-development.scm | 78 
> +++
>  2 files changed, 79 insertions(+)

warsow-qfusion-fix-bool-return-type.patch is missing, breaking the
build of both Guix and this package.

> +(define-public warsow-qfusion
> +  ;; As of 2020-04-09, the latest stable version 2.1.0 is deprecated.
> +  ;; The 2.5 beta as published on the homepage is commit
> +  ;; c4de15df559410aff0ca6643724e24cddb0ecbbd
> +  (let ((commit "c4de15df559410aff0ca6643724e24cddb0ecbbd")
> +(arch (match (or (%current-target-system)
> + (%current-system))
> +("x86_64-linux" "x86_64")
> +("i686-linux" "i386")
> +(_ ""

Don't do this if you just need to determine architecture at build time.

> +   (add-after 'install 'really-install
> + (lambda* (#:key outputs #:allow-other-keys)
> +   (let ((out (assoc-ref outputs "out")))
> + (install-file (string-append 
> "../source/build/basewsw/libgame_"
> +  ,arch ".so")
> +   (string-append out "/lib/"))
> + (install-file (string-append "../source/build/libui_" ,arch 
> ".so")
> +   (string-append out "/lib/"))

Add it here instead.  There is also no need for the fallback value
as the package apparently only supports i686 and x86_64 according to
supported-systems.

> +  (synopsis "Warsow's fork of qfusion, the id Tech 2 derived game 
> engine")
> +  (supported-systems '("i686-linux" "x86_64-linux"))
> +  (description
> +   "This package contains Warsow's fork of qfusion, the id Tech 2 derived
> +game engine.  id Tech 2 is the engine originally behind Quake 2.")
> +  (license license:gpl2+

Nit-pick: could you put description immediately after synopsis?  Also,
please avoid restating the synopsis in the description, but try to
expand on it.  I.e. what is Warsow?  I thought it was a city!

Meanwhile I've reverted the commit so that 'make' works again.

Thanks!


signature.asc
Description: PGP signature

Re: [PATCH] website: Update sjd.se servers.

[Marius Bakke]

Simon Josefsson  writes:

> * website/apps/base/templates/donate.scm (donate-t):

I've pushed this patch now:

  https://guix.gnu.org/donate/

Thank you!


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Ricardo Wurmus  writes:

> Leo Famulari  writes:
>
>> I'm doing `guix pull --branch=core-updates`, with a `guix describe` of
>> commit a533c5a183 (core-updates from 2 weeks ago), on Debian, in tmux,
>> and I see this weird thing:
>>
>> --
>> substitute: updating substitutes from 'https://private.mirror'... 100.0%
>> @ substituter-started 
>> /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 substitute
>> /@ download-started 
>> /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 
>> https://private.mirror/nar/lzip/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2
>>  4856299
>> \@ download-progress 
>> /gnu/store/zfskbazynmdgmrbhnkbvar8qn5rpqgh2-git-minimal-2.26.2 
>> https://private.mirror/nar
>
> These tags are status information that Guix should hide and use to build
> progress bars and the like.  They have been around for quite some time,
> but they should not ever be visible.

Could it be because locales are not yet available for the new Guix?


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Leo Famulari  writes:

> On Tue, Apr 28, 2020 at 03:17:06PM +0200, Marius Bakke wrote:
>> Leo Famulari  writes:
>> 
>> > I reconfigured my Guix System based on core-updates, and afterwards I
>> > was unable to login, either remotely over SSH, or on the Linux console.
>> 
>> Do you still have the logs from this attempt?  Curious what caused login
>> to fail.
>
> Yes, they are excerpted below. First you'll see the remote login
> attempts, and then the attempts at the Linux console:

Thanks!

> Apr 25 13:57:16 localhost sshd[2731]: Accepted publickey for leo from 
> 192.168.1.101 port 55512 ssh2: ED25519 SHA256:my-key
> Apr 25 13:57:16 localhost sshd[2731]: error: PAM: pam_open_session(): Module 
> is unknown

strace on the ssh server process after reconfiguring on core-updates
shows:

966   sendto(8, "<83>Apr 29 14:38:19 sshd[966]: PAM unable to 
dlopen(/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so):
 /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib/libc.so.6: version 
`GLIBC_2.30' not found (required by 
/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so)",
 340, MSG_NOSIGNAL, NULL, 0) = 340
966   getpid()  = 966
966   sendto(8, "<83>Apr 29 14:38:19 sshd[966]: PAM adding faulty module: 
/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so",
 142, MSG_NOSIGNAL, NULL, 0) = 142

Restarting 'ssh-daemon' allows login to succeed.

[...]

> Apr 25 13:58:17 localhost shepherd[1]: Respawning term-tty1.
> Apr 25 13:58:17 localhost shepherd[1]: Service host-name has been started.   
> Apr 25 13:58:17 localhost shepherd[1]: Service term-tty1 has been started.
> Apr 25 13:58:20 localhost vmunix: [433720.062263] login[2745]: segfault at 0 
> ip 7f8fc66d0934 sp 7fffcf163610 error 4 in 
> libpthread-2.31.so[7f8fc66d+f000]
> Apr 25 13:58:20 localhost vmunix: [433720.062271] Code: 82 e8 02 00 00 e0 ff 
> ff ff be 18 00 00 00 b8 11 01 00 00 48 89 ba d8 02 00 00 48 89 ba e0 02 00 00 
> 0f 05 48 8b 05 84 56 01 00 <48> 8b 00 64 48 89 04 25 98 06 00 00 48 8d 05 09 
> 9a 01 00 48 8d 8a

I see a similar failure when tracing the associated mingetty process:

1003  sendto(4, "<83>Apr 29 14:49:20 login[1003]: PAM unable to 
dlopen(/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so):
 /gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy
4pj-glibc-2.29/lib/libc.so.6: version `GLIBC_2.30' not found (required by 
/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so)",
 342, MSG_NOSIGNAL, NULL, 0) = 342
1003  getpid()  = 1003
1003  sendto(4, "<83>Apr 29 14:49:20 login[1003]: PAM adding faulty module: 
/gnu/store/44il8dnl5qc6ryb3v0lp5374hg3h7vx5-elogind-243.4/lib/security/pam_elogind.so",
 144, MSG_NOSIGNAL, NULL, 0) = 144

Again running 'herd restart term-tty1' lets me log in successfully.

I'm not sure what to do about this.  Can we get the Shepherd to
automatically restart select services on reconfigure?

For the term-tty services that are started on demand, one fix would be
to have Shepherd start the new service without the explicit 'herd
restart term-tty1' call.

Thoughts?


signature.asc
Description: PGP signature

Re: When installing pycurl through pip, linux/limits.h is missing from glibc

[Marius Bakke]

Josh Marshall  writes:

> `python3 -m pip install pycurl` fails due to glibc not being able to find
> the header "linux/limits.h".  I am aware that there is a "python-pycurl"
> package in guix, but the above should still work.  I think glibc is missing
> a dependency on linux headers, but I'm not sure that all this is
> actionable.  Should I be opening up a bug report for this?

Does it work if you run it in a 'guix environment --ad-hoc
gcc-toolchain'?  That would set up CPATH and related variables and
should allow the build system to locate the Linux headers.


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Leo Famulari  writes:

> I reconfigured my Guix System based on core-updates, and afterwards I
> was unable to login, either remotely over SSH, or on the Linux console.

Do you still have the logs from this attempt?  Curious what caused login
to fail.


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

Efraim Flashner  writes:

> I have a package which currently depends on gfortran-5, although
> gfortran-5 doesn't build on core-updates.
>
> efraimf@penguin2:~/workspace/guix-core-updates$ ./pre-inst-env guix build 
> --no-grafts -e '(@@ (gnu packages gcc) gfortran-5)'
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> The following derivation will be built:
>/gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv
> building /gnu/store/frqb5p2vdk8qcjwbny1s6mlak344a0gx-gfortran-5.5.0.drv...
> Backtrace:
> In ice-9/eval.scm:
>217:50 19 (lp (# ?))
>217:50 18 (lp (# ?))
>217:50 17 (lp (# ?))
>217:50 16 (lp (# ?))
>217:50 15 (lp (# ?))
>217:50 14 (lp (# ?))
>217:50 13 (lp (# ?))
>217:50 12 (lp (# ?))
>217:50 11 (lp (# ?))
>217:50 10 (lp (# ?))
>217:50  9 (lp (# ?))
>217:50  8 (lp (# ?))
>217:50  7 (lp (# ?))
>217:50  6 (lp (# ?))
>217:33  5 (lp (# ?))
>196:43  4 (_ #f)
>196:35  3 (_ #f)
>202:27  2 (_ #f)
>223:20  1 (proc #)
>In unknown file:
>0 (%resolve-variable (7 . cut) #)
>
> ERROR: In procedure %resolve-variable:
> Unbound variable: cut

Fixed in 587398d2a82e0b5966a6827d36a1f1d115181b11, thanks!


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

sirgazil  writes:

> This time, one of my packages in a custom channel failed with "no code for 
> (term ansi-color)" (the package definition: 
> https://gitlab.com/sirgazil/guix-channel-x/-/blob/master/sirgazil-x/packages/guile.scm#L13).
>  This is not a new package in my profile, I've been using it for a long time. 
> Since both error seemed to be related to Guile, I removed all Guile-related 
> packages from my profile and tried upgrading again. This time, the upgrade 
> succeeded.

The reason your custom package failed is because it is using guile-2.2,
but the dependencies are built with Guile 3.0.

Changing the native-input to 'guile-3.0' should do the trick.  Otherwise
you can change the dependencies to 'guile2.2-json' and similar.

Thanks for testing!


signature.asc
Description: PGP signature

Re: core-updates call for testing

[Marius Bakke]

sirgazil  writes:

>   On Fri, 24 Apr 2020 03:20:41 + sirgazil  wrote 
> 
>  >   On Thu, 23 Apr 2020 23:24:23 + Marius Bakke 
>  wrote 
>  >  > Hello Guix!
>  >  > 
>  >  > The "core-updates" branch is ready for testing!  According to 'guix
>  >  > weather', the substitute coverage is slightly better than on "master"
>  >  > for x86_64.  You can get it by running:
>  >  > 
>  >  >   guix pull --branch=core-updates
>  >  > 
>  >  > Please try upgrading your profiles and systems and file bugs for
>  >  > anything that does not work for you.  GNOME users in particular are
>  >  > encouraged to try the new GNOME 3.34 and report any regressions.
>  > 
>  > I pulled from core-updates without problems, but "guix upgrade" failed.
>  > 
>  > First, when running "guix upgrade", I got the following message, which I 
> think is confusing because I use GNU, not Guix on a foreign distro:
>  > 
>  > $ guix upgrade
>  > guile: warning: failed to install locale
>  > hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' 
> package and defining `GUIX_LOCPATH', along these lines:
>  > 
>  >  guix package -i glibc-utf8-locales
>  >  export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
>  > 
>  > See the "Application Setup" section in the manual, for more info.
>  > 
>  > Then, everything was going alright, until building emacs-guix derivation 
> failed:
>  > 
>  > building 
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv...
>  > \ 'configure' phasebuilder for 
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed 
> with exit code 1
>  > build of 
> /gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv failed
>  > View build log at 
> '/var/log/guix/drvs/6k/dl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv.bz2'.
>  > guix upgrade: error: build of 
> `/gnu/store/6kdl0pyv7i571d6b4vcxskr75ffqw1mk-emacs-guix-0.5.2.drv' failed
>  > 
>  > 
>  > The build log said:
>  > 
>  > starting phase `configure'
>  > source directory: 
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2" (relative from 
> build: ".")
>  > build directory: 
> "/tmp/guix-build-emacs-guix-0.5.2.drv-0/emacs-guix-0.5.2"
>  > configure flags: 
> ("CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu")
>  > configure: WARNING: unrecognized options: --enable-fast-install
>  > checking for a BSD-compatible install... 
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/install -c
>  > checking whether build environment is sane... yes
>  > checking for a thread-safe mkdir -p... 
> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32/bin/mkdir -p
>  > checking for gawk... gawk
>  > checking whether make sets $(MAKE)... no
>  > checking whether make supports nested variables... yes
>  > checking whether make supports nested variables... (cached) yes
>  > checking for pkg-config... 
> /gnu/store/krpyb0zi700dcrg9cc8932w4v0qivdg9-pkg-config-0.29.2/bin/pkg-config
>  > checking pkg-config is at least version 0.9.0... yes
>  > configure: checking for guile 2.2
>  > configure: checking for guile 2.0
>  > configure: error: 
>  > No Guile development packages were found.
>  > 
>  > Please verify that you have Guile installed.  If you installed Guile
>  > from a binary distribution, please verify that you have also installed
>  > the development packages.  If you installed it yourself, you might need
>  > to adjust your PKG_CONFIG_PATH; see the pkg-config man page for more.
>  > 
>  > command 
> "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" 
> "./configure" 
> "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  
> "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash"
>  "--prefix=/gnu/store/bqplgazij77awh62579p56wbnxdb1c2l-emacs-guix-0.5.2" 
> "--enable-fast-install" "--build=x86_64-unk

core-updates call for testing

[Marius Bakke]

Hello Guix!

The "core-updates" branch is ready for testing!  According to 'guix
weather', the substitute coverage is slightly better than on "master"
for x86_64.  You can get it by running:

  guix pull --branch=core-updates

Please try upgrading your profiles and systems and file bugs for
anything that does not work for you.  GNOME users in particular are
encouraged to try the new GNOME 3.34 and report any regressions.

If you don't feel like jumping into the deep end, you can pull it to a
temporary location instead of the default ~/.config/guix/current:

  guix pull -p /tmp/core-updates --branch=core-updates
  /tmp/core-updates/bin/guix package -u

That way you don't have to 'guix pull --roll-back' to get at your
previous Guix (from the "master" branch).

Enjoy!


signature.asc
Description: PGP signature

Re: GNU Guix 1.1.0 released

[Marius Bakke]

Vincent Legoll  writes:

>> Another question, why is the VM image partitionned
>> like that (root first, then EFI) ? It makes root
>> partition resizing more painful than needed.
>
> This one's still bugging me though

Not really an answer to your question, but you can safely delete the EFI
partition unless you are using QEMU with a UEFI firmware (default is
BIOS emulation).


signature.asc
Description: PGP signature

Re: Jami: Bug source investigation

[Marius Bakke]

Jan  writes:

> Hello,
>
> so I tested Jami on core-updates and it didn't fix the bug
> (https://git.jami.net/savoirfairelinux/jami-packaging/issues/63)
>
> Here's my work up to now, it is on wip-jami branch:
> https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix/-/tree/wip-jami
> https://gitlab.com/kromka_chleba/jami-package-and-other-things-for-guix.git
>
> What happens is when making an audio call and then pressing the red
> "disconnect" button, Jami daemon (dring) stops with the following
> message:
>
> dring: ../src/pjsip-ua/sip_inv.c:246: pjsip_inv_dec_ref: Assertion `inv
> && inv->ref_cnt' failed.

It looks like this problem was fixed a while back:

https://trac.pjsip.org/repos/ticket/2240
https://github.com/pjsip/pjproject/commit/d5a9caf6aac077c157fa6b20c770385c2355973d

Have you tried updating pjproject to 2.10?


signature.asc
Description: PGP signature

Re: branch wip-gnome3.34 created (now 1538791)

[Marius Bakke]

Hi Kei,

guix-comm...@gnu.org writes:

> kkebreau pushed a change to branch wip-gnome3.34
> in repository guix.
>
>   at 1538791  gnu: libical: Enable introspection and Vala bindings.
>
> This branch includes the following new commits:
>
>  new e8cccae  gnu: adwaita-icon-theme: Update to 3.34.3.
>  new b76506e  gnu: baobab: Update to 3.34.0.
>  new a720afb  gnu: dconf: Update to 3.34.0.
>  new 929ad4f  gnu: dconf-editor: Update to 3.34.2.
>  new 904227e  gnu: eog: Update to 3.34.1.
>  new 8ff022a  gnu: gnome-desktop: Update to 3.34.2.
>  new 8730829  gnu: gnome-backgrounds: Update to 3.34.0.
>  new fdfaefa  gnu: gsettings-desktop-schemas: Update to 3.34.0.
>  new 781da7d  gnu: libdazzle: Update to 3.34.1.
>  new 7c44117  gnu: epiphany: Update to 3.34.2.
>  new 49c537d  gnu: gedit: Update to 3.34.1.
>  new 48d8c3b  gnu: glib-networking: Update to 2.62.2.
>  new 9d875e7  gnu: gnome-bluetooth: Update to 3.34.0.
>  new fea74bf  gnu: libgweather: Update to 3.34.0.
>  new 3febbdc  gnu: evolution-data-server: Update to 3.34.2.
>  new 46d713c  gnu: gnome-autoar: Update to 0.2.4.
>  new aace96f  gnu: evolution: Update to 3.34.2.
>  new cff7f2f  gnu: dbus-glib: Update to 0.110.
>  new e4e7160  gnu: folks: Update to 0.13.1.
>  new c8be939  gnu: gnome-contacts: Update to 3.34.
>  new 12a8807  gnu: gnome-session: Update to 3.34.2.
>  new 048875f  gnu: gnome-settings-daemon: Update to 3.34.1.
>  new 093ab99  gnu: gnome-control-center: Update to 3.34.2.
>  new 586eb32  gnu: gnome-disk-utility: Update to 3.34.0.
>  new 44f210a  gnu: gnome-keyring: Update to 3.34.0.
>  new e822ab3  gnu: gnome-screenshot: Update to 3.34.0.
>  new c09d945  gnu: gnome-terminal: Update to 3.34.2.
>  new ba1d88e  gnu: nautilus: Update to 3.34.2.
>  new 513a19c  gnu: totem: Update to 3.34.1.
>  new b9686ae  gnu: mutter: Update to 3.34.2.
>  new b989db7  gnu: gdm: Update to 3.34.1.
>  new 9049e4d  gnu: telepathy-glib: Disable failing tests.
>  new be62a1b  gnu: gjs: Update to 1.58.3.
>  new 4ac325a  gnu: gnome-shell: Update to 3.34.2.
>  new df3e812  gnu: seahorse: Update to 3.34.
>  new 92a7370  gnu: gnome-mines: Update to 3.34.0.
>  new d82cdcd  gnu: gnome-sudoku: Update to 3.34.1.
>  new df8dfba  gnu: devhelp: Update to 3.34.0.
>  new d2fce9c  gnu: gnome-klotski: Update to 3.34.0.
>  new 0293a06  gnu: gnome-clocks: Update to 3.34.0.
>  new 2f7f0be  gnu: gnome-calendar: Update to 3.34.2.
>  new 097da4b  gnu: gnome-tweaks: Update to 3.34.0.
>  new c7587d3  gnu: gnome-shell-extensions: Update to 3.34.2.
>  new f6342be  gnu: orca: Update to 3.34.1.
>  new e96f871  gnu: cheese: Update to 3.34.0.
>  new 08c5ffd  gnu: gnome-maps: Update to 3.34.2.
>  new 1538791  gnu: libical: Enable introspection and Vala bindings.

Thank you very much for maintaining this branch.  I think we are ready
to merge it to core-updates proper and start asking people to test it on
their systems.  WDYT?

Please cherry-pick these commits to core-updates if you agree!  :-)


signature.asc
Description: PGP signature

Reproducibility of Qt packages

[Marius Bakke]

Hi Maxim,

I noticed this nice commit:

guix-comm...@gnu.org writes:

> commit a4f1a7e2db22cd028fb514846c2791928b8734d3
> Author: Maxim Cournoyer 
> AuthorDate: Wed Apr 15 02:03:26 2020 -0400
>
> gnu: linphoneqt: Fix reproducibility issue and improve description.
> 
> * gnu/packages/linphone.scm (linphoneqt)[phases]: Rename the 'patch phase 
> to
> 'set-version-string, and use the version variable of the package in the
> replacement.
> {set-qt-rcc-source-date-override, fix-cmake-error}: Add phases.
> [synopsis]: Explicit what the package is.
> [description]: Mention more useful keywords and features.

[...]

> + (add-after 'set-paths 'set-qt-rcc-source-date-override
> +   (lambda _
> + ;; This fixes a reproducibility problem where the Qt Resource
> + ;; Compiler (RCC) includes timestamp of the its source files
> + ;; (see: https://reproducible-builds.org/docs/
> + ;;   deterministic-build-systems/#cmake-notes)
> + (setenv "QT_RCC_SOURCE_DATE_OVERRIDE" "1")
> + #t))

Would it make sense to add this variable directly in qt-build-system (or
maybe even patch Qt to make it the default)?


signature.asc
Description: PGP signature

Re: Packaging Jami "progress"

[Marius Bakke]

Jan  writes:

> I get several merge conflicts when merging wip-jami into core updates.
> The wip-jami is based on the current master, rebased a minute ago.
> Is there a way to avoid this without pain?

A git merge will merge all the commits, some of which are bound to cause
conflicts.  I will try to resolve those tomorrow.

In the mean time, you should be able to "cherry-pick" your patches
instead.  Something along the lines of:

$ git checkout core-updates
$ git cherry-pick master..wip-jami

Does that work?


signature.asc
Description: PGP signature

Re: Packaging Jami "progress"

[Marius Bakke]

Jan  writes:

> Hello everybody,
>
> I recently tested Jami using the latest pjproject version - 2.10 which
> was supposed to fix some strange bugs that are present only on Guix,
> but it didn't.
> https://git.jami.net/savoirfairelinux/jami-packaging/issues/63
> Jami developer - Sébastien Blin told me: "Imho the probable issue
> is related to our codebase... and this would need some bisect to
> understand what's wrong... This can be long and painful" and I'm
> currently out of ideas what could cause this bug.

Do you have a patch we can use to reproduce this issue on Guix?

> My last chance is waiting for core-updates to be merged into master and
> maybe something will fix the problem magically. When is
> the 1.1.0 release planned?

You can easily test the patch on core-updates by simply checking out the
branch and apply your patches.  Or 'guix pull --branch=core-updates' if
you are testing via a channel.

1.1.0 will be released before the core-updates merge.


signature.asc
Description: PGP signature

Re: native or not

[Marius Bakke]

Vincent Legoll  writes:

>> Making ‘groff’ native was the right thing to do (and please, keep
>> fixing bugs like this! :-) but it has nothing to do with making
>> packages smaller.
>
> Never will ?
>
> I'm not expecting package size to shrink, but package closure
> (is that the right word) size to sometimes shrink.

Unless you are cross-compiling (i.e. guix build --target=foo),
native-inputs and inputs behave exactly the same; they are simply
concatenated.


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Marius Bakke]

Jan Nieuwenhuizen  writes:

>> For those unaware, this means that the set of trusted binaries at the
>> root of the package graph from which everything else derives is only 60
>> MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
>> glibc!
>
>> For more information, see jannekes blog post:
>>
>> https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html
>
> For the record...it's even better: The GCC, binutils and glibc
> removal mentioned above is already in master; so our next release will
> bootstrap from ~135MB like blog post mentions!
>
> The Core-updates bootstrap (code named "Scheme-only bootstrap") removes
>
>   Awk, Bash, the GNU Core Utilities, Grep, Gzip, Sed, and Tar.
>
> and replaces them with Gash and Gash-Utils!

Oh my, that's just incredible, I did not think we were there already!

Thanks for the update.  :-)


signature.asc
Description: PGP signature

Re: Cannot build guix from git due to .po file errors

[Marius Bakke]

Marius Bakke  writes:

> Ludovic Courtès  writes:
>
>> Hi Vagrant,
>>
>> Vagrant Cascadian  skribis:
>>
>>> e...@boldquot.po:4591: format specifications in 'msgstr[0]' are not a
>>> subset of those in 'msgid_plural'
>>> /gnu/store/p50cw1g05g566bkbr6ylcibqffhha8w4-profile/bin/msgfmt: found 1
>>> fatal error
>>
>> What’s the message on that line?
>
> The message is:
>
> msgstr[0] "The following ~*machine will be deployed:~%"
>
> ...from (guix scripts deploy).

So this is the same issue as <https://issues.guix.gnu.org/issue/37505>.

I went ahead and applied the same workaround in
388b432cea4ae2bb9bf4b044026b7764ab002e1e.


signature.asc
Description: PGP signature

Re: Cannot build guix from git due to .po file errors

[Marius Bakke]

Ludovic Courtès  writes:

> Hi Vagrant,
>
> Vagrant Cascadian  skribis:
>
>> e...@boldquot.po:4591: format specifications in 'msgstr[0]' are not a
>> subset of those in 'msgid_plural'
>> /gnu/store/p50cw1g05g566bkbr6ylcibqffhha8w4-profile/bin/msgfmt: found 1
>> fatal error
>
> What’s the message on that line?

The message is:

msgstr[0] "The following ~*machine will be deployed:~%"

...from (guix scripts deploy).


signature.asc
Description: PGP signature

Re: core-updates frozen!

[Marius Bakke]

Jan Nieuwenhuizen  writes:

> Marius Bakke writes:
>
>> The branch currently represents 676 commits by 26 people.  Some
>> highlights from this round:
>>
>> * Guix runs natively on GNU/Hurd.
>> * Guix System can be cross-compiled for foreign architectures.
>> * The distribution is built with Guile 3.0.
>> * GNOME 3.34 (on a separate branch, will get merged shortly).
>
> These are exciting changes!  Let's also not forget:
>
>  * for x86 and x86_64: another reduction of the bootstrap binary seed by
> roughly %0%, to ~60MB!

I knew I was forgetting something important!  Thanks for the reminder.

For those unaware, this means that the set of trusted binaries at the
root of the package graph from which everything else derives is only 60
MiB (on i686 and x86_64).  The set no longer includes GCC, binutils, or
glibc!

For more information, see jannekes blog post:

https://www.joyofsource.com/guix-reduces-bootstrap-seed-by-50.html


signature.asc
Description: PGP signature

core-updates frozen!

[Marius Bakke]

Hello Guix!

The 'core-updates' branch is now in a "feature freeze" after a long ...
thawing period.  That means that there will be no more world rebuilding
changes apart from bug fixes[*].

It is expected to start the full rebuild in a few days once the
bootstrap is complete on AArch64 and ARMv7, which are unfortunately
lacking in compute power at the moment (side note: if you have hardware
to spare, consider donating!).

The branch currently represents 676 commits by 26 people.  Some
highlights from this round:

* Guix runs natively on GNU/Hurd.
* Guix System can be cross-compiled for foreign architectures.
* The distribution is built with Guile 3.0.
* GNOME 3.34 (on a separate branch, will get merged shortly).

Significant package updates:

* glibc 2.31
* Python 3.8.2
* Ruby 2.6.5
* TeX Live 2019

Other changes that may require adjusting third-party channels:

* "libjpeg" has been deprecated in favor of "libjpeg-turbo".
* "util-linux" gained a "lib" output for significant size savings.
* Build systems now set C_INCLUDE_PATH and CPLUS_INCLUDE_PATH instead of
  CPATH.
* Any package that uses libcurl now respects SSL_CERT_DIR and
  SSL_CERT_FILE.

Thanks to everyone who contributed to this branch.  Let the rebuilds
begin!

[*] There are problems with OpenSSL 1.1.1e and we might take on 1.1.1f
if it is released before the full rebuild starts:
https://mta.openssl.org/pipermail/openssl-project/2020-March/001919.html



signature.asc
Description: PGP signature

Re: automake-1.16.2

[Marius Bakke]

Vincent Legoll  writes:

>> We’d probably have to decide on a case by case basis which additional
>> dependencies we’d like to add, given that Automake has a lot of
>> dependents.
>
> For the tests they will be native-inputs, so only increase dependencies
> for building, is that a problem ? I would have thought that test coverage
> is more important (especially on such important packages), I'm probably
> missing something...

For such heavy-impact packages, an important consideration is that any
dependency we add gets the same impact.

Hypothetically, let's say Automake has an optional dependency on
'git' for some tests.  Providing git as a native-input means that we can
no longer update git outside of the "core-updates" cycle, because that
would cause too many rebuilds.

Of course there are ways to work around such cycles, but it complicates
the dependency graphs.


signature.asc
Description: PGP signature