bug#51559: Webkit fails to build

[Liliana Marie Prikler]

Hi,

Am Donnerstag, den 04.11.2021, 17:58 -0400 schrieb Mark H Weaver:
> However, I ran into the same problem where programs linked to
> webkitgtk failed.
> 
> My knowledge of C++ is weak (I avoid it like the plague) but I guess
> this might be because GCC 10 and GCC 7 use different versions of the
> standard C++ library, which are not ABI compatible with each other.
Yes, you will have to add GCC 10 to the packages that fail to link. 
Maxim pointed out, that it already woks on core-updates-frozen-batched-
changes, what we need to check is which packages will require GCC 10 on
master.

Cheers

bug#47422: tar is vulnerable to CVE-2021-20193

[phodina via Bug reports for GNU Guix]

Hi,

here's patch for the master branch as I'm not sure what is the roadmap for 
merging core-updates into master.

The obvious downside is that the update triggers large rebuild of core packages 
:-/

---8<-cut here--start>8

[PATCH] gnu: tar: Update to 1.34.

* gnu/package/base.scm (tar): Update to 1.34.

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index ea2e102c15..6ebe30464e 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -179,14 +179,14 @@ (define-public sed
(define-public tar
   (package
    (name "tar")
-   (version "1.32")
+   (version "1.34")
    (source (origin
 (method url-fetch)
 (uri (string-append "mirror://gnu/tar/tar-"
 version ".tar.xz"))
 (sha256
  (base32
-  "1n7xy657ii0sa42zx6944v2m4v9qrh6sqgmw17l3nch3y43sxlyh"))
+  "0a0x87anh9chbi2cgcyy7pmnm5hzk4yd1w2j8gm1wplwhwkbvgk3"))
 (patches (search-patches "tar-skip-unreliable-tests.patch"
  "tar-remove-wholesparse-check.patch"
    (build-system gnu-build-system)
--
2.33.1

bug#51506: Add --quiet option to guix-install.sh

[Maxim Cournoyer]

Hello,

Jacob Hrbek  writes:

> Yes, that seems to work, thanks

Great, thanks for the reply, and thanks for Simon for the solution!

Closing.

Maxim

bug#47089: error: make-session: unbound variable

[Maxim Cournoyer]

Hi,

Mark H Weaver  writes:

> Hi Jean,
>
> Jean Louis  writes:
>
>> Running guix package manager on Hyperbola GNU/Linux-libre:
>>
>> [root@protected ~]# guix pull --no-substitutes -K
>> accepted connection from pid 876, user root
>> Updating channel 'guix' from Git repository at 
>> 'https://git.savannah.gnu.org/git/guix.git'...
>> Building from this channel:
>>   guix  https://git.savannah.gnu.org/git/guix.git   5a06b83
>> building /gnu/store/0l5krmnzmkyawbh7y7xa808sq7sp30vv-config.scm.drv...
>> building /gnu/store/klcxrfvivkjri4whdpyhsnjywr9ki8br-git.scm.drv...
>> building /gnu/store/6kfhwxxjkrknf9wgv2mawyrrzlbbzli2-hash.scm.drv...
>> building /gnu/store/1imdq47vyanhn2mw4814xz10d4ahyd25-module-import.drv...
>> building 
>> /gnu/store/2zb0ys1iiz7djfgyj234ykzfqcjg27lf-module-import-compiled.drv...
>> building 
>> /gnu/store/dmr42vhl0wsjm413i79dxx5nv6wqvcb8-compute-guix-derivation.drv...
>> Computing Guix derivation for 'x86_64-linux'... |@ build-started
>> /gnu/store/51h0bidlh2w1qhkmy1mc3jdg31jla4b1-module-import-compiled.drv
>> - x86_64-linux
>> /var/log/guix/drvs/51//h0bidlh2w1qhkmy1mc3jdg31jla4b1-module-import-compiled.drv.bz2
>> 2051
>> -@ build-succeeded 
>> /gnu/store/51h0bidlh2w1qhkmy1mc3jdg31jla4b1-module-import-compiled.drv -
>> @ build-started 
>> /gnu/store/rx4xa4pzl258yg3hgxrv8xaasrcc6fkg-Python-3.8.2.tar.xz.drv - 
>> x86_64-linux 
>> /var/log/guix/drvs/rx//4xa4pzl258yg3hgxrv8xaasrcc6fkg-Python-3.8.2.tar.xz.drv.bz2
>>  2083
>> |@ build-log 2083 22
>>
>> Starting download of @ build-log 2083 132
>> /gnu/store/pkzdxf9fhdfx473lphqgydd4q3nk4rql-Python-3.8.2.tar.xz
>> From https://www.python.org/ftp/python/3.8.2/Python-3.8.2.tar.xz...
>> /@ build-log 2083 51
>> error: make-session: unbound variable
>
> 'make-session' should be provided by the Guile-bindings included in
> GnuTLS.  It might be that the GnuTLS provided by Hyperbola wasn't
> compiled with Guile support, or provides Guile support but for a
> different version of Guile than the one you're using to run Guix.
>
> What method did you use to install Guix?
>
> It looks like you compiled Guix from source using Hyperbola's native
> toolchain, libraries, and Guile.  If so, you might have better results
> using Guix's binary installer method, which installs a Guix binary that
> avoids using components from your native OS, in favor of components that
> were built by Guix and are known to work correctly with it.

Thanks for your answer, Mark.

I believe it addresses the question, as there haven't been a new reply
in the last 6 months.

Thanks for the report!

Closing.

Maxim

bug#51559: Webkit fails to build

[Maxim Cournoyer]

Hi Mark,

Mark H Weaver  writes:

> Hi,
>
> Liliana Marie Prikler  writes:
>
>> Am Donnerstag, den 04.11.2021, 14:23 -0400 schrieb Maxim Cournoyer:
>>> Note that on the core-updates-frozen-batched-changes branch webkitgtk
>>> (with libsoup2 or 3) could still be built with GCC (version 10).
>> Should we try building webkitgtk and its dependants with GCC 10 on
>> master
>
> I've already verified that webkitgtk-2.34.1 can be successfully built
> with GCC 10, because I tried it on my private branch (simply because I
> already have a built GCC 10 on my system, and I don't use substitutes).
> However, I ran into the same problem where programs linked to webkitgtk
> failed.
>
> My knowledge of C++ is weak (I avoid it like the plague) but I guess
> this might be because GCC 10 and GCC 7 use different versions of the
> standard C++ library, which are not ABI compatible with each other.
>
> Since GCC 10 is the default compiler on 'core-updates-frozen', I think
> it's quite likely that webkitgtk-2.34.1 and its programs can be built
> successfully on 'core-updates-frozen' with its default compiler.  That
> would need to be verified, of course.

It's already been verified on the core-updates-frozen-batched-changes
branch (which had webkitgtk-2.34.1 before master).

Thanks,

Maxim

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

[Maxim Cournoyer]

Hello,

Mark H Weaver  writes:

> Earlier, I wrote:
>> libwebkit2gtk-4.0.so fails to link on i686-linux, due to an undefined
>> reference to '__mulodi4'.
>
> Here are some relevant links:
>
>   https://bugs.webkit.org/show_bug.cgi?id=190208
>   https://trac.webkit.org/changeset/272140/webkit
>   https://github.com/android/ndk/issues/506
>
>>   https://ci.guix.gnu.org/build/1428233/details
> [...]
>> [100%] Linking CXX shared library ../../lib/libwebkit2gtk-4.0.so
>> cd /tmp/guix-build-webkitgtk-2.34.1.drv-0/build/Source/WebKit && 
>> /gnu/store/4mlbaklbibcdgprxg7vp42vkafs69v9i-cmake-minimal-3.16.5/bin/cmake 
>> -E cmake_link_script CMakeFiles/WebKit.dir/link.txt --verbose=1
>> /gnu/store/dbcwl680w24rf2dn2pk3gx9nmvz7rl9c-clang-11.0.0/bin/clang++ -fPIC 
>> -Wextra -Wall -mfpmath=sse -msse2 [...]
>
> Also, I just noticed that "-mfpmath=sse -msse2" is being passed on the
> compile command line.  Historically, we've chosen not to assume the
> availability of SSE or SSE2 on i686-linux, so it would be good to
> inhibit those flags.
>
>Mark

FWIW, webkitgtk-with-libsoup2 on the core-updates-frozen-batched-changes
has built fine with GCC 10 on x86_64; I can't test currently there on
i686 due to another issue lower in the chain, but perhaps it'd work fine
too.

HTH!

Maxim

bug#51498: onionshare build is broken

[raid5atemyhomework via Bug reports for GNU Guix]

> > Can you test it again? I was able to build it just now with commit
> > c0c974ad96767a1e207fe2823cd5479605485415. I was also able to build it
> > with your provided commit above.
>
> Having diverging results suggests a nondeterministic build, which is bad, 
> right? I'm running on a Guix System machine running directly on the metal.

On a Guix on top of a foreign distro, I got:

* good: `guix time-machine --commit=ebc274063716a3a9471f51abb526d693c06b9f63 -- 
build onionshare`
  * result: `/gnu/store/ynkjlqh9sjr72blfvvxrj86cgjpa270l-onionshare-2.3.2`

Looks like nondeterminism?

On the machine where the build is failing, this is the stanza where the tests 
start going wrong:

```
tests/test_gui_share.py::TestShare::test_401_public_skips_ratelimit PASSED [  
5%]
tests/test_gui_share.py::TestShare::test_401_triggers_ratelimit PASSED   [ 10%]
tests/test_gui_share.py::TestShare::test_405_page_returned_for_invalid_methods 
PASSED [ 15%]
tests/test_gui_share.py::TestShare::test_autostart_and_autostop_timer_mismatch 
SKIPPED [ 21%]
tests/test_gui_share.py::TestShare::test_autostart_timer SKIPPED [ 26%]
tests/test_gui_share.py::TestShare::test_autostart_timer_cancel PASSED   [ 31%]
tests/test_gui_share.py::TestShare::test_autostart_timer_too_short SKIPPED [ 
36%]
tests/test_gui_share.py::TestShare::test_autostop_timer SKIPPED  [ 42%]
tests/test_gui_share.py::TestShare::test_autostop_timer_too_short SKIPPED [ 47%]
tests/test_gui_share.py::TestShare::test_clear_all_history_button PASSED [ 52%]
tests/test_gui_share.py::TestShare::test_download PASSED [ 57%]
tests/test_gui_share.py::TestShare::test_individual_files PASSED [ 63%]
tests/test_gui_share.py::TestShare::test_individual_files_without_autostop_sharing
 PASSED [ 68%]
tests/test_gui_share.py::TestShare::test_large_download FAILED   [ 73%]
tests/test_gui_share.py::TestShare::test_persistent_password FAILED  [ 78%]
tests/test_gui_share.py::TestShare::test_public_mode FAILED  [ 84%]
tests/test_gui_share.py::TestShare::test_remove_all_file_selection_button 
FAILED [ 89%]
tests/test_gui_share.py::TestShare::test_unreadable_file FAILED  [ 94%]
tests/test_gui_share.py::TestShare::test_without_autostop_sharing FAILED [100%]
```

Build log github gist: 
https://gist.github.com/raid5atemyhomework/113e4860b359ab70637eedc032648d3b


Thanks
raid5atemyhomework

bug#51498: onionshare build is broken

[raid5atemyhomework via Bug reports for GNU Guix]

>
> Can you test it again? I was able to build it just now with commit
> c0c974ad96767a1e207fe2823cd5479605485415. I was also able to build it
> with your provided commit above.

Having diverging results suggests a nondeterministic build, which is bad, 
right?  I'm running on a Guix System machine running directly on the metal.

* bad: `guix time-machine --commit=ebc274063716a3a9471f51abb526d693c06b9f63 -- 
build onionshare`


```
"""
>   tab = self.new_share_tab()

tests/test_gui_share.py:435:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tests/gui_base_test.py:88: in new_share_tab
self.verify_new_tab(tab)
tests/gui_base_test.py:80: in verify_new_tab
self.assertTrue(tab.new_tab.isVisible())
E   AssertionError: False is not true
--- Captured stdout teardown ---
[Nov 05 2021 01:00:36 AM] MainWindow.closeEvent
[Nov 05 2021 01:00:36 AM] MainWindow.closeEvent, opening warning dialog
[Nov 05 2021 01:00:37 AM] MainWindow.cleanup
[Nov 05 2021 01:00:37 AM] TabWidget.cleanup
[Nov 05 2021 01:00:37 AM] Tab.cleanup: tab_id=8
[Nov 05 2021 01:00:37 AM] Web.stop: stopping server
[Nov 05 2021 01:00:37 AM] Web.cleanup
[Nov 05 2021 01:00:37 AM] Alert.__init__
[Nov 05 2021 01:00:37 AM] OnionCleanupThread.__init__
[Nov 05 2021 01:00:37 AM] OnionCleanupThread.run
[Nov 05 2021 01:00:37 AM] Onion.cleanup
--- Captured stderr teardown ---
This plugin does not support propagateSizeHints()
This plugin does not support propagateSizeHints()
 Captured log teardown -
INFO werkzeug:_internal.py:113 127.0.0.1 - - [05/Nov/2021 01:00:37] "GET 
/hpzwg6jwsaxb4bde4qmlh5emeu/shutdown HTTP/1.1" 200 -
== 6 failed, 8 passed, 5 skipped in 83.87s (0:01:23) ===
QThread: Destroyed while thread is still running
Fatal Python error: Aborted

Thread 0x7fffd77fe700 (most recent call first):
  File 
"/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/lib/python3.8/zipfile.py",
 line 1139 in write
  File 
"/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/lib/python3.8/shutil.py",
 line 205 in copyfileobj
  File 
"/gnu/store/9w9jvy3bgjg4qaqmrij01nbppiccqr7c-python-3.8.2/lib/python3.8/zipfile.py",
 line 1776 in write
  File 
"/gnu/store/qycixjbyhvh2mchlrsbadvrh0p81lgpz-onionshare-cli-2.3.2/lib/python3.8/site-packages/onionshare_cli/web/share_mode.py",
 line 565 in add_file
  File 
"/gnu/store/qycixjbyhvh2mchlrsbadvrh0p81lgpz-onionshare-cli-2.3.2/lib/python3.8/site-packages/onionshare_cli/web/share_mode.py",
 line 511 in build_zipfile_list
  File 
"/gnu/store/qycixjbyhvh2mchlrsbadvrh0p81lgpz-onionshare-cli-2.3.2/lib/python3.8/site-packages/onionshare_cli/web/share_mode.py",
 line 418 in set_file_info_custom
  File 
"/gnu/store/qycixjbyhvh2mchlrsbadvrh0p81lgpz-onionshare-cli-2.3.2/lib/python3.8/site-packages/onionshare_cli/web/send_base_mode.py",
 line 130 in set_file_info
  File 
"/gnu/store/vz73w4kdk44swsws46kvzvypk2dg6nv3-onionshare-2.3.2/lib/python3.8/site-packages/onionshare/tab/mode/share_mode/threads.py",
 line 46 in run

Current thread 0x7785c300 (most recent call first):

./tests/run.sh: line 6:76 Aborted pytest -v 
tests/test_gui_share.py
command "./tests/run.sh" failed with status 134
builder for `/gnu/store/nwm0wl6ilxgaqwl331fmp3ggxgh706a5-onionshare-2.3.2.drv' 
failed with exit code 1
build of /gnu/store/nwm0wl6ilxgaqwl331fmp3ggxgh706a5-onionshare-2.3.2.drv failed
View build log at 
'/var/log/guix/drvs/nw/m0wl6ilxgaqwl331fmp3ggxgh706a5-onionshare-2.3.2.drv.bz2'.
guix build: error: build of 
`/gnu/store/nwm0wl6ilxgaqwl331fmp3ggxgh706a5-onionshare-2.3.2.drv' failed
```

* bad: `guix time-machine --commit=c0c974ad96767a1e207fe2823cd5479605485415 -- 
build onionshare`


```
"""
>   tab = self.new_share_tab()

tests/test_gui_share.py:435:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tests/gui_base_test.py:88: in new_share_tab
self.verify_new_tab(tab)
tests/gui_base_test.py:80: in verify_new_tab
self.assertTrue(tab.new_tab.isVisible())
E   AssertionError: False is not true
--- Captured stdout teardown ---
[Nov 05 2021 01:08:53 AM] MainWindow.closeEvent
[Nov 05 2021 01:08:53 AM] MainWindow.closeEvent, opening warning dialog
[Nov 05 2021 01:08:53 AM] MainWindow.cleanup
[Nov 05 2021 01:08:53 AM] TabWidget.cleanup
[Nov 05 2021 01:08:53 AM] Tab.cleanup: tab_id=8
[Nov 05 2021 01:08:53 AM] Web.stop: stopping server
[Nov 05 2021 01:08:54 AM] Web.cleanup
[Nov 05 2021 01:08:54 AM] Alert.__init__
[Nov 05 2021 01:08:54 AM] OnionCleanupThread.__init__
[Nov 05 2021 01:08:54 AM] OnionCleanupThread.run
[Nov 05 2021 01:08:54 AM] Onion.cleanup
--- Captured stderr teardown ---
This plugin does not support propagateSizeHints()
This plugin does not 

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

[Mark H Weaver]

Liliana Marie Prikler  writes:

> Am Mittwoch, den 03.11.2021, 17:04 -0400 schrieb Mark H Weaver:
>> Earlier, I wrote:
>> > libwebkit2gtk-4.0.so fails to link on i686-linux, due to an
>> > undefined reference to '__mulodi4'.
>> 
>> Here are some relevant links:
>> 
>>   https://bugs.webkit.org/show_bug.cgi?id=190208
>>   https://trac.webkit.org/changeset/272140/webkit
>>   https://github.com/android/ndk/issues/506
> This error does not occur when compiling with GCC [1].

Right.  As mentioned in the first link above:

  "This is because clang generates code using the __mulodi4 symbol for
   __builtin_mul_overflow.  But this symbol is available only in
   compiler-rt, and not in the libgcc runtime used by most Linux
   distributions of clang."

So, one possible solution might be to link with compiler-rt, which is
the 'clang-runtime-11' package in Guix.  However, it's possible that
this might cause other complications.

A more conservative approach would be to apply a patch to
trunk/Source/WTF/wtf/CheckedArithmetic.h analogous to the one in the
second link I cited above, namely this one:

  https://trac.webkit.org/changeset/272140/webkit

However, it would need to be changed slightly.  The patch above arranges
to avoid using __builtin_mul_overflow on 32-bit ARM systems.  We would
need to do the same for 32-bit x86 as well.  So, where the patch above
has this:

--8<---cut here---start->8---
/* On Linux with clang, libgcc is usually used instead of compiler-rt, and it 
does
 * not provide the __mulodi4 symbol used by clang for __builtin_mul_overflow
 */
#if COMPILER(GCC) || (COMPILER(CLANG) && !(CPU(ARM) && OS(LINUX)))
#define USE_MUL_OVERFLOW 1
#endif
--8<---cut here---end--->8---

We would need to change "CPU(ARM)" to "(CPU(ARM) || CPU(XXX))", where
XXX is the appropriate symbol for 32-bit x86.  Or maybe there's another
solution.

I won't be able to look at this in the next couple of days, so hopefully
someone else can pick this up.

> However, now dependant packages fail to link Webkit [2].  We might have
> to add GCC 11 to all of them -- or at least to a fair number.  I've
> verified that gnome-online-accounts builds with GCC 11 added, we might
> want to make sure we check the rest of the gnome package as well.

I'm not sure about this approach.  Maybe it's feasible, but there might
be problems if *any* C++ library built using GCC 7 is linked together
with WebKitGTK.

> On that note, which GCC will be the standard once core-updates-frozen
> is merged?  If it's not GCC 11 – say GCC 10 – we might want to try to
> get Webkit building with that instead, so that at least after the merge
> we're clean on that front.

The standard compiler on 'core-updates-frozen' is GCC 10.  As I wrote
elsewhere, I think it's quite likely that these workarounds will not be
needed on 'core-updates-frozen'.

>> Also, I just noticed that "-mfpmath=sse -msse2" is being passed on
>> the compile command line.  Historically, we've chosen not to assume
>> the availability of SSE or SSE2 on i686-linux, so it would be good to
>> inhibit those flags.
> This is still true for the GCC build.  Could you add the necessary
> flags to disable them?

I don't know when I'll be able to look into it.  It's a busy time for me.

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#51555: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:

> On Thu, Nov 04, 2021 at 08:57:18AM -0400, Mark H Weaver wrote:
>> Although the WebKitGTK package itself built successfully using GCC 11,
>> the switch to GCC 11 caused many failures in programs that use
>> WebKitGTK.  For example:
>
> Should we just revert the WebKitGTK upgrade for now?

I'm reluctant to do that, because it would mean reintroducing
CVE-2021-30846, CVE-2021-30851 and CVE-2021-42762.  According to
, two of those
CVEs could allow an attacker to execute arbitrary code via maliciously
crafted web content.

For now, I've reverted back to using clang-11 to compile WebKitGTK,
which works correctly on x86_64-linux, but another fix will be needed to
i686-linux users.  I have some ideas on how to fix it.  I'll write about
that soon at 51...@debbugs.gnu.org.

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#51559: Webkit fails to build

[Mark H Weaver]

Hi,

Liliana Marie Prikler  writes:

> Am Donnerstag, den 04.11.2021, 14:23 -0400 schrieb Maxim Cournoyer:
>> Note that on the core-updates-frozen-batched-changes branch webkitgtk
>> (with libsoup2 or 3) could still be built with GCC (version 10).
> Should we try building webkitgtk and its dependants with GCC 10 on
> master

I've already verified that webkitgtk-2.34.1 can be successfully built
with GCC 10, because I tried it on my private branch (simply because I
already have a built GCC 10 on my system, and I don't use substitutes).
However, I ran into the same problem where programs linked to webkitgtk
failed.

My knowledge of C++ is weak (I avoid it like the plague) but I guess
this might be because GCC 10 and GCC 7 use different versions of the
standard C++ library, which are not ABI compatible with each other.

Since GCC 10 is the default compiler on 'core-updates-frozen', I think
it's quite likely that webkitgtk-2.34.1 and its programs can be built
successfully on 'core-updates-frozen' with its default compiler.  That
would need to be verified, of course.

 Regards,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

bug#47473: font-{canad1500,cns11643}: hash mismatch

[phodina via Bug reports for GNU Guix]

Hi,

seems that font-cns11643 was updated in 377fad00979 by Brendan Tildesley and 
font-canad1500 in dcd4d697686 by Ludovic Courtès.

Petr

bug#37047: git needs sed either as propagated input or as input (with some substitute*-work)

[phodina via Bug reports for GNU Guix]

Hi,

I'm attempting to replicate the described issue, but when I run the commands I 
get certificate error.

$ guix environment --container -N --ad-hoc go coreutils binutils less  emacs 
grep findutils git nss-certs
[env]$ go get github.com/fatih/structs
go get: module github.com/fatih/structs: Get 
"https://proxy.golang.org/github.com/fatih/structs/@v/list": x509: certificate 
signed by unknown authority

Petr

bug#47474: fossil: hash mismatch

[phodina via Bug reports for GNU Guix]

Hi,

the checksum was corrected by Tobias Geerinckx-Rice in commit 
20771f4043990632b73187b10d1851a1244df4e6 as well as the pkg was updated from 
2.10 -> 2.11.

Petr

bug#47480: logo gprolog: hash mismatch

[phodina via Bug reports for GNU Guix]

Hi,

I've looked at the package gprolog and it was updated by Efraim Flashner in 
commit
1914d24b452ca6dad30fad6f1faa5f611fa740b0 to version 1.5.0.

There's a note saying "Recent versions are not hosted on the GNU mirrors".

Petr

bug#51559: Webkit fails to build

[Liliana Marie Prikler]

Hi,

Am Donnerstag, den 04.11.2021, 14:23 -0400 schrieb Maxim Cournoyer:
> Note that on the core-updates-frozen-batched-changes branch webkitgtk
> (with libsoup2 or 3) could still be built with GCC (version 10).
Should we try building webkitgtk and its dependants with GCC 10 on
master or should we rather wait for the core-updates-frozen merge?  Do
we have an ETA?

CC'd lfam due to security relevance

Cheers

bug#51559: Webkit fails to build

[Maxim Cournoyer]

Hello,

Mark H Weaver  writes:

> reopen 51559
> thanks
>
> Hi Maxim,
>
> Maxim Cournoyer  writes:
>> That's fixed on core-updates-frozen-batched-changes, having upgraded
>> webkitgtk to 2.34.4 and libsoup to 3.0.1.
>>
>> Closing.
>
> Unless I'm mistaken, there still remains the problem that 'webkitgtk'
> and all of its dependents are currently broken on 'master', so I'm
> reopening the bug.

Thanks Mark (also for the fix) -- I had mistakenly thought the issue was
about core-updates-frozen.

Note that on the core-updates-frozen-batched-changes branch webkitgtk
(with libsoup2 or 3) could still be built with GCC (version 10).

Thanks,

Maxim

bug#51559: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

[Liliana Marie Prikler]

Am Donnerstag, den 04.11.2021, 11:47 -0400 schrieb Leo Famulari:
> On Thu, Nov 04, 2021 at 08:57:18AM -0400, Mark H Weaver wrote:
> > Although the WebKitGTK package itself built successfully using GCC
> > 11,
> > the switch to GCC 11 caused many failures in programs that use
> > WebKitGTK.  For example:
> 
> Should we just revert the WebKitGTK upgrade for now?
SGTM.  Can someone check whether it builds fine with GCC 10 on c-u-
frozen?

bug#51559: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

[Leo Famulari]

On Thu, Nov 04, 2021 at 08:57:18AM -0400, Mark H Weaver wrote:
> Although the WebKitGTK package itself built successfully using GCC 11,
> the switch to GCC 11 caused many failures in programs that use
> WebKitGTK.  For example:

Should we just revert the WebKitGTK upgrade for now?

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

[Liliana Marie Prikler]

Hi,

Am Mittwoch, den 03.11.2021, 17:04 -0400 schrieb Mark H Weaver:
> Earlier, I wrote:
> > libwebkit2gtk-4.0.so fails to link on i686-linux, due to an
> > undefined reference to '__mulodi4'.
> 
> Here are some relevant links:
> 
>   https://bugs.webkit.org/show_bug.cgi?id=190208
>   https://trac.webkit.org/changeset/272140/webkit
>   https://github.com/android/ndk/issues/506
This error does not occur when compiling with GCC [1].

However, now dependant packages fail to link Webkit [2].  We might have
to add GCC 11 to all of them -- or at least to a fair number.  I've
verified that gnome-online-accounts builds with GCC 11 added, we might
want to make sure we check the rest of the gnome package as well.

On that note, which GCC will be the standard once core-updates-frozen
is merged?  If it's not GCC 11 – say GCC 10 – we might want to try to
get Webkit building with that instead, so that at least after the merge
we're clean on that front.

> >   https://ci.guix.gnu.org/build/1428233/details
> [...]
> > [100%] Linking CXX shared library ../../lib/libwebkit2gtk-4.0.so
> > cd /tmp/guix-build-webkitgtk-2.34.1.drv-0/build/Source/WebKit &&
> > /gnu/store/4mlbaklbibcdgprxg7vp42vkafs69v9i-cmake-minimal-
> > 3.16.5/bin/cmake -E cmake_link_script
> > CMakeFiles/WebKit.dir/link.txt --verbose=1
> > /gnu/store/dbcwl680w24rf2dn2pk3gx9nmvz7rl9c-clang-
> > 11.0.0/bin/clang++ -fPIC -Wextra -Wall -mfpmath=sse -msse2 [...]
> 
> Also, I just noticed that "-mfpmath=sse -msse2" is being passed on
> the compile command line.  Historically, we've chosen not to assume
> the availability of SSE or SSE2 on i686-linux, so it would be good to
> inhibit those flags.
This is still true for the GCC build.  Could you add the necessary
flags to disable them?

Cheers,
Liliana

[1] http://ci.guix.gnu.org/build/1530117/log/raw
[2] http://ci.guix.gnu.org/build/1530484/log/raw

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

[Mark H Weaver]

reopen 51591
thanks

Hi Liliana,

Mark H Weaver  writes:

> Liliana Marie Prikler  writes:
>
>> Am Mittwoch, den 03.11.2021, 14:09 -0400 schrieb Mark H Weaver:
>>> [...]
>>> 
>>> Note that I tried clang-11 first, because upstream WebKit surely uses
>>> clang for compilation, and it works for building IceCat on Guix, so I
>>> had it hunch that it was a good bet.  However, it would be good to
>>> now try compiling webkitgtk-2.34.1 with a newer version of GCC.  It's
>>> possible that might fix the build on i686-linux.
>> I'm currently building webkitgtk on x86_64 locally with GCC 11.  If
>> that succeeds, I'll push to master and have CI take it from there.
>
> For the record, it's commit 63f78f6a6ea0d33f3b1fa68c7285cfb865677211 on
> the 'master' branch, and it did indeed fix the build on i686-linux.

I spoke too soon.

Although the WebKitGTK package itself built successfully using GCC 11,
the switch to GCC 11 caused many failures in programs that use
WebKitGTK.  For example:

  https://ci.guix.gnu.org/build/1530462/details (epiphany)
  https://ci.guix.gnu.org/build/1530484/details (gnome-online-accounts)
  https://ci.guix.gnu.org/build/1530479/details (yelp)
  https://ci.guix.gnu.org/build/1530407/details (surf)
  https://ci.guix.gnu.org/build/1530465/details (zenity)

See below for an illustrative excerpt from the failed epiphany log.

I've pushed commit 1007eb4874b7d3d2e0ecda07157f5794a0591ea2 to 'master',
which reverts commit 63f78f6a6e.

I've also reopened , to track progress on
fixing the webkitgtk build on i686 using clang-11.  I have a couple of
ideas of how to fix it.  To be continued...

   Mark

--8<---cut here---start->8---
[274/292] Linking target src/epiphany.
FAILED: src/epiphany 
gcc  -o src/epiphany 
'src/25a6634@@epiphany@exe/meson-generated_.._epiphany-resources.c.o' 
'src/25a6634@@epiphany@exe/meson-generated_.._ephy-type-builtins.c.o' 
'src/25a6634@@epiphany@exe/meson-generated_.._.._embed_ephy-embed-type-builtins.c.o'
 
'src/25a6634@@epiphany@exe/meson-generated_.._.._lib_ephy-lib-type-builtins.c.o'
 
'src/25a6634@@epiphany@exe/meson-generated_.._.._lib_widgets_ephy-widgets-type-builtins.c.o'
 'src/25a6634@@epiphany@exe/ephy-main.c.o' -Wl,--as-needed -Wl,--no-undefined 
-Wl,-rpath=/gnu/store/qaia05dz19yc8p1lmf6jnrlmlwzw45iv-epiphany-3.34.4/lib/epiphany
 -Wl,--start-group src/libephymain.so embed/libephyembed.a lib/libephymisc.so 
subprojects/libhandy/src/libhandy-0.0.a lib/sync/libephysync.so 
lib/widgets/libephywidgets.a 
/gnu/store/arza64g68736x20dmh786d3vrlnp5zq2-libdazzle-3.37.1/lib/libdazzle-1.0.so
 /gnu/store/rcjh2gisni3jzkld0d7883kzsmmj0kwg-gtk+-3.24.24/lib/libgtk-3.so 
/gnu/store/rcjh2gisni3jzkld0d7883kzsmmj0kwg-gtk+-3.24.24/lib/libgdk-3.so 
/gnu/store/66crnfykciiip52fjlawxd4aa62yx7kc-pango-1.44.7/lib/libpangocairo-1.0.so
 /gnu/store/66crnfykciiip52fjlawxd4aa62yx7kc-pango-1.44.7/lib/libpango-1.0.so 
/gnu/store/7n014z63svmbih0wbq15hanilmjnzl41-harfbuzz-2.6.4/lib/libharfbuzz.so 
/gnu/store/hd946pyi5lwqa980fzglqb8299k9518w-atk-2.34.1/lib/libatk-1.0.so 
/gnu/store/kakspf0hkf7pnyq581bh0pq3r3bjfrvx-cairo-1.16.0/lib/libcairo-gobject.so
 /gnu/store/kakspf0hkf7pnyq581bh0pq3r3bjfrvx-cairo-1.16.0/lib/libcairo.so 
/gnu/store/gj6q6rs9aprwkk4x67y8nv45hai5fq2v-gdk-pixbuf+svg-2.40.0/lib/libgdk_pixbuf-2.0.so
 /gnu/store/qzj0j8lv58fyr7dbsjj4fzjcqvgmkwzb-glib-2.62.6/lib/libgio-2.0.so 
/gnu/store/qzj0j8lv58fyr7dbsjj4fzjcqvgmkwzb-glib-2.62.6/lib/libgobject-2.0.so 
/gnu/store/qzj0j8lv58fyr7dbsjj4fzjcqvgmkwzb-glib-2.62.6/lib/libglib-2.0.so 
/gnu/store/3jqq5m8j8vbawm8bgirhwrsywpdmgmnv-json-glib-1.4.4/lib/libjson-glib-1.0.so
 
/gnu/store/338yvdb6jr0nnscbb30zfa6xm1sdf0mr-libsecret-0.20.4/lib/libsecret-1.so 
/gnu/store/b5lfjmd8wgdvc9050870xianfz7isvna-libsoup-2.72.0/lib/libsoup-2.4.so 
/gnu/store/c8w9z48vvx2a3q3k44ch9yn00wk1qwhb-libxml2-2.9.10/lib/libxml2.so -lm 
/gnu/store/807c6g9xqrxdjyhm8wm1r6jjjmc8q4vs-sqlite-3.31.1/lib/libsqlite3.so 
/gnu/store/4436r43crxcdmz011r7i2c1niz4jvi6g-webkitgtk-2.34.1/lib/libwebkit2gtk-4.0.so
 
/gnu/store/4436r43crxcdmz011r7i2c1niz4jvi6g-webkitgtk-2.34.1/lib/libjavascriptcoregtk-4.0.so
 -Wl,--export-dynamic 
/gnu/store/qzj0j8lv58fyr7dbsjj4fzjcqvgmkwzb-glib-2.62.6/lib/libgmodule-2.0.so 
-pthread -lrt -lgmp 
/gnu/store/mz5fvdfks10rmwxf29n95bp9bim6wq7g-nettle-3.5.1/lib/libhogweed.so 
/gnu/store/mz5fvdfks10rmwxf29n95bp9bim6wq7g-nettle-3.5.1/lib/libnettle.so 
/gnu/store/j0d13s4j72nvmzdg7v0k529qyas7x2wk-gcr-3.34.0/lib/libgcr-ui-3.so 
/gnu/store/j0d13s4j72nvmzdg7v0k529qyas7x2wk-gcr-3.34.0/lib/libgcr-base-3.so 
/gnu/store/j0d13s4j72nvmzdg7v0k529qyas7x2wk-gcr-3.34.0/lib/libgck-1.so 
/gnu/store/p0p3p28cc5n220cikqvq1r6xgf7qx066-p11-kit-0.23.22/lib/libp11-kit.so 
/gnu/store/li61ai11bbayiqsz0ab4wawxifdd5wza-libnotify-0.7.9/lib/libnotify.so 
-Wl,--end-group 
'-Wl,-rpath,$ORIGIN/:$ORIGIN/../embed:$ORIGIN/../lib:$ORIGIN/../subprojects/libhandy/src:$ORIGIN/../lib/sync:$ORIGIN/../lib/widgets'
 

bug#51435: Fix it (unison does not build on core-updates-frozen)

[Vivien Kraus via Bug reports for GNU Guix]

Rekado on #guix told me that I had to create a simple texlive package
for the missing package, that’s what I did. Since I’m not familiar with
the texlive way of doing things, I’m not sure the homepage is that of
l3backend (and thus, I’m not sure of the license if it’s not), and I
need someone to review the description for the package too.

Vivien

>From 093b913147b8f7e9aab66887ed1484e6aaeeb102 Mon Sep 17 00:00:00 2001
From: Vivien Kraus 
Date: Thu, 4 Nov 2021 10:59:18 +0100
Subject: [PATCH 1/2] gnu: Add texlive-dvips-l3backend.

* gnu/packages/tex.scm (texlive-dvips-l3backend): New variable.
---
 gnu/packages/tex.scm | 17 +
 1 file changed, 17 insertions(+)

diff --git a/gnu/packages/tex.scm b/gnu/packages/tex.scm
index bf427f1594..888ded3fce 100644
--- a/gnu/packages/tex.scm
+++ b/gnu/packages/tex.scm
@@ -3513,6 +3513,23 @@ (define-public texlive-latex-l3packages
 @end enumerate\n")
 (license license:lppl1.3c+)))
 
+(define-public texlive-dvips-l3backend
+  (package
+(inherit (simple-texlive-package
+  "texlive-dvips-l3backend"
+  (list
+   "/dvips/l3backend/")
+  (base32
+   "1hvj153h1pn93h6n76dv3mg9ai0mcz9q9mysfiqjfpqzijz9ikky")
+  #:trivial? #t))
+(home-page "https://www.ctan.org/pkg/l3backend;)
+(synopsis "LaTeX3 backend drivers for dvips")
+(description
+ "This package forms parts of expl3, and contains the code used to
+interface with backends (drivers) across the expl3 codebase.  The functions
+here are defined for the dvips engine only.")
+(license license:lppl1.3c+)))
+
 (define-public texlive-fontspec
   (let ((template (simple-texlive-package
"texlive-fontspec"
-- 
2.33.1

>From a7568441319c4e42ec2e51dfddf62eacb0a054e2 Mon Sep 17 00:00:00 2001
From: Vivien Kraus 
Date: Thu, 4 Nov 2021 01:02:39 +0100
Subject: [PATCH 2/2] gnu: unison: Fix building the manual.

* gnu/packages/ocaml.scm (unison)[native-inputs]: Add the missing texlive inputs.
---
 gnu/packages/ocaml.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/ocaml.scm b/gnu/packages/ocaml.scm
index 7b1363a5c3..5b190e7e8d 100644
--- a/gnu/packages/ocaml.scm
+++ b/gnu/packages/ocaml.scm
@@ -1205,7 +1205,8 @@ (define-public unison
  `(("ocaml" ,ocaml-4.09)
;; For documentation
("ghostscript" ,ghostscript)
-   ("texlive" ,texlive-tiny)
+   ("texlive" ,(texlive-updmap.cfg
+(list texlive-fonts-ec texlive-dvips-l3backend)))
("hevea" ,hevea)
("lynx" ,lynx)
("which" ,which)))
-- 
2.33.1

bug#51559: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

[Mark H Weaver]

Hi Liliana,

Liliana Marie Prikler  writes:

> Am Mittwoch, den 03.11.2021, 14:09 -0400 schrieb Mark H Weaver:
>> [...]
>> 
>> Note that I tried clang-11 first, because upstream WebKit surely uses
>> clang for compilation, and it works for building IceCat on Guix, so I
>> had it hunch that it was a good bet.  However, it would be good to
>> now try compiling webkitgtk-2.34.1 with a newer version of GCC.  It's
>> possible that might fix the build on i686-linux.
> I'm currently building webkitgtk on x86_64 locally with GCC 11.  If
> that succeeds, I'll push to master and have CI take it from there.

For the record, it's commit 63f78f6a6ea0d33f3b1fa68c7285cfb865677211 on
the 'master' branch, and it did indeed fix the build on i686-linux.

Thanks again,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .