bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

2022-10-15 Thread phodina via Bug reports for GNU Guix
Hi,

unfortunately incorrect hash was pushed in the last patchset.

The patch is already part of the next patch series [1].

Also it's tracked here [2].

1 
https://github.com/phodina/guix/commit/4636279dfb3b96eb5836baad0d8ea36e58ff79ee
2 https://issues.guix.gnu.org/57608#8


Petr




Sent with Proton Mail secure email.

--- Original Message ---
On Sunday, October 16th, 2022 at 6:33 AM, 'Brendan Tildesley 
 wrote:


> From: Brendan Tildesley m...@brendan.scot
> 
> 
> * gnu/packages/kde.scm (akregator)[phases]: Fix finding
> QtWebEngineProcess path.
> ---
> gnu/packages/kde.scm | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
> index 37125b1d0b..d0ffb28505 100644
> --- a/gnu/packages/kde.scm
> +++ b/gnu/packages/kde.scm
> @@ -167,9 +167,8 @@ (define-public akregator
> (lambda* (#:key inputs outputs #:allow-other-keys)
> (let* ((out (assoc-ref outputs "out"))
> (bin (string-append out "/bin/akregator"))
> - (qt-process-path (string-append
> - (assoc-ref inputs "qtwebengine-5")
> - "/lib/qt5/libexec/QtWebEngineProcess")))
> + (qt-process-path (search-input-file
> + inputs "/lib/qt5/libexec/QtWebEngineProcess")))
> (wrap-program bin
> `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)
> (native-inputs
> --
> 2.37.2





bug#58561: [PATCH 2/2] gnu: akregator: Fix build.

2022-10-15 Thread 'Brendan Tildesley
From: Brendan Tildesley 

* gnu/packages/kde.scm (akregator)[phases]: Fix finding
QtWebEngineProcess path.
---
 gnu/packages/kde.scm | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 37125b1d0b..d0ffb28505 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -167,9 +167,8 @@ (define-public akregator
(lambda* (#:key inputs outputs #:allow-other-keys)
  (let* ((out (assoc-ref outputs "out"))
 (bin (string-append out "/bin/akregator"))
-(qt-process-path (string-append
-   (assoc-ref inputs "qtwebengine-5")
-   "/lib/qt5/libexec/QtWebEngineProcess")))
+(qt-process-path (search-input-file
+  inputs 
"/lib/qt5/libexec/QtWebEngineProcess")))
(wrap-program bin
  `("QTWEBENGINEPROCESS_PATH" = (,qt-process-path)
 (native-inputs
-- 
2.37.2






bug#58561: [PATCH 1/2] gnu: akregator: Correct source hash.

2022-10-15 Thread 'Brendan Tildesley
From: Brendan Tildesley 

* gnu/packages/kde.scm (akregator): Use correct hash.
---
 gnu/packages/kde.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 1d4321237a..37125b1d0b 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -158,7 +158,7 @@ (define-public akregator
(uri (string-append "mirror://kde/stable/release-service/" version
"/src/akregator-" version ".tar.xz"))
(sha256
-(base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"
+(base32 "08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g"
 (build-system qt-build-system)
 (arguments
  `(#:phases
-- 
2.37.2






bug#58561: Source hash mismatch with aggregator + possible guix bug with hashes.

2022-10-15 Thread Brendan Tildesley

I'm getting this after the recent updates:

sha256 hash mismatch for 
/gnu/store/iv6ixlrvh0swq22fjal0cbfbr9ayaq7m-akregator-22.04.3.tar.xz:

  expected hash: 1yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8
  actual hash: 08n713271i7ifnbrgwrqmxvcpvj45wfqjiidw8zf9rpwxg2m2m9g


However what concerned me more is that when I look in the source code it 
looks like this:


(sha256
    (base32 "9yy5c29zxpli4cddknmdvjkgii3j7pvw6lhwqfrqjc8jh83gm8f8"))


Notice how at the start its a '9', not a '1'?

I've tried with both guix pull local repo and building from source.


Is there a bug with how guix is reading/writing sha256 hashes?






bug#58560: Inconsistent test failure in mutter

2022-10-15 Thread Brendan Tildesley

It didn't fail the second time though:




94/107 mutter:core+mutter/stacking / set-parent RUNNING
>>> G_TEST_BUILDDIR=/tmp/guix-build-mutter-42.4.drv-0/build 
MUTTER_TEST_PLUGIN_PATH=/tmp/guix-build-mutter-42.4.drv-0/build/src/compositor/plugins/libdefault.so 
MALLOC_PERTURB_=247 
G_TEST_SRCDIR=/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src 
/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src/tests/meta-dbus-runner.py 
/tmp/guix-build-mutter-42.4.drv-0/build/src/tests/mutter-test-runner 
/tmp/guix-build-mutter-42.4.drv-0/build/../mutter-42.4/src/tests/stacking/set-parent.metatest
― ✀ 
―

Starting D-Bus daemons (session & system)...
Starting mocked services...
Running test case...
# random seed: R02S542f1e4fb657b24556bc18339672aff5
# libmutter-MESSAGE: Running Mutter Test (using mutter 42.4) as a 
Wayland display server
libmutter-Message: 01:38:04.142: Running Mutter Test (using mutter 42.4) 
as a Wayland display server
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
memory (GMemorySettingsBackend) for ‘gsettings-backend’

Failed to create //.cache for shader cache (Permission denied)---disabling.
# libmutter-MESSAGE: Created surfaceless renderer without GPU
libmutter-Message: 01:38:04.273: Created surfaceless renderer without GPU
# GLib-GIO-DEBUG: _g_io_module_get_default: Found default implementation 
local (GLocalVfs) for ‘gio-vfs’
# libmutter-MESSAGE: Disabling DMA buffer screen sharing (not hardware 
accelerated)
libmutter-Message: 01:38:04.330: Disabling DMA buffer screen sharing 
(not hardware accelerated)
# libmutter-MESSAGE: Disabling DMA buffer screen sharing (implicit 
modifiers not supported)
libmutter-Message: 01:38:04.331: Disabling DMA buffer screen sharing 
(implicit modifiers not supported)
# libmutter-DEBUG: WL: loaded 
/gnu/store/rdlkxcp52i1sz3qhajdxjc7a7gkgdq0v-egl-wayland-1.1.11/lib/libnvidia-egl-wayland.so.1:wl_eglstream_controller.
# libmutter-MESSAGE: Using public X11 display :512, (using :513 for 
managed services)
libmutter-Message: 01:38:04.332: Using public X11 display :512, (using 
:513 for managed services)

# libmutter-MESSAGE: Using Wayland display name 'mutter-test-display'
libmutter-Message: 01:38:04.333: Using Wayland display name 
'mutter-test-display'
Window manager warning: Failed to set environment variable 
GNOME_SETUP_DISPLAY for gnome-session: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
"org.gnome.SessionManager" does not exist
Window manager warning: Failed to set environment variable DISPLAY for 
gnome-session: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: 
Name "org.gnome.SessionManager" does not exist
Window manager warning: Failed to set environment variable XAUTHORITY 
for gnome-session: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
"org.gnome.SessionManager" does not exist
Window manager warning: Failed to set environment variable 
WAYLAND_DISPLAY for gnome-session: 
GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name 
"org.gnome.SessionManager" does not exist

1..1
# libmutter-MESSAGE: Added virtual monitor Meta-0
libmutter-Message: 01:38:04.397: Added virtual monitor Meta-0
# libmutter-INFO: Acquired name org.gnome.Mutter.ScreenCast
# libmutter-INFO: Acquired name org.gnome.Mutter.RemoteDesktop
# libmutter-MESSAGE: Removed virtual monitor Meta-0
libmutter-Message: 01:38:04.779: Removed virtual monitor Meta-0
ok 1 stacking/set-parent.metatest
Traceback (most recent call last):
  File 
"/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src/tests/meta-dbus-runner.py", 
line 184, in 

    test_case.wrap_call(rest[1:])
  File 
"/tmp/guix-build-mutter-42.4.drv-0/mutter-42.4/src/tests/meta-dbus-runner.py", 
line 171, in wrap_call

    self.assertEqual(p.wait(), 0)
  File 
"/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9/lib/python3.9/unittest/case.py", 
line 837, in assertEqual

    assertion_func(first, second, msg=msg)
  File 
"/gnu/store/65i3nhcwmz0p8rqbg48gaavyky4g4hwk-python-3.9.9/lib/python3.9/unittest/case.py", 
line 830, in _baseAssertEqual

    raise self.failureException(msg)
AssertionError: -11 != 0
――
 94/107 mutter:core+mutter/stacking / set-parent FAIL    
1.67s   exit status 1







bug#58559: Rust 1.58.1 fails to build

2022-10-15 Thread Brendan Tildesley

   Compiling toml v0.5.7

error: use of deprecated associated function `std::array::IntoIter::N>::new`: use `IntoIterator::into_iter` instead

    --> src/bootstrap/lib.rs:1046:31
 |
1046 | std::array::IntoIter::new(options).flatten()
 |   ^^^
 |
 = note: `-D deprecated` implied by `-D warnings`

error: could not compile `bootstrap` due to previous error
failed to run: 
/gnu/store/njjhb4ql1bpb1qj5ksmjgnhaxmy093nz-rust-1.60.0-cargo/bin/cargo 
build --manifest-path 
/tmp/guix-build-rust-1.58.1.drv-0/rustc-1.58.1-src/src/bootstrap/Cargo.toml 
--frozen

Build completed unsuccessfully in 0:00:12
error: in phase 'build': uncaught exception:
%exception #< program: "./x.py" arguments: ("-j16" "build" 
"library/std" "src/tools/cargo" "src/tools/rustfmt") exit-status: 1 
term-signal: #f stop-signal: #f>

phase `build' failed after 12.3 seconds
command "./x.py" "-j16" "build" "library/std" "src/tools/cargo" 
"src/tools/rustfmt" failed with status 1







bug#58551: kgraphviewer is broken

2022-10-15 Thread Csepp
message in GUI is "could not find the KGraphViewer part", on console it's:
kf5.kxmlgui: cannot find .rc file "kgraphviewerui.rc" for component 
"kgraphviewer"

Ran with guix shell --no-grafts because there is some gosh darn bug with
grafts again and even though both this and Krita report as OK on the CI
dashboard, users have to build dozens (no an exaggeration) of packages
on their own machines.





bug#57878: Minimal reproducible setup

2022-10-15 Thread Liliana Marie Prikler
Am Samstag, dem 15.10.2022 um 17:40 +0200 schrieb zimoun:
> Just to be sure, do you mean an emacs-next version which includes the
> upstream Lars’s patches?  The ones that Eli and Andrea are calling to
> be reverted?
> 
> --8<---cut here---start->8---
> Sorry as changeset I meant 5fec9182db + f97993ee66.  I'm not against
> e245c4f226.
> 
> [...]
> 
> Again 5fec9182db + f97993ee66 are IMO not useful / wrong, they were
> not discussed and are just a step backward.  The best change I can
> suggest is to revert them now.
> --8<---cut here---end--->8---
> 
> from 
Ehm, yes... best to keep this open until I can bump to a version that's
approved and solves the problem.





bug#57878: Minimal reproducible setup

2022-10-15 Thread zimoun
Hi Liliana,

On Sat, 15 Oct 2022 at 16:40, Liliana Marie Prikler  
wrote:

> Done.  Since I just copypasta'd the wording, I made you the author.

Oh, thanks.  (It was the news’ wording. :-))


> As for this bug: I've bumped emacs-next to a version that can inhibit
> almost all native-compilation (trampolines are still compiled, but not
> written to the cache), fixed the linker issue, and disabled native
> compilation for emacs-ido-completing-read+.  Any remaining native-comp
> issues or can this be closed?

Closing is fine with me; well I do not have a opinion on that. :-)

Just to be sure, do you mean an emacs-next version which includes the
upstream Lars’s patches?  The ones that Eli and Andrea are calling to be
reverted?

--8<---cut here---start->8---
Sorry as changeset I meant 5fec9182db + f97993ee66.  I'm not against
e245c4f226.

[...]

Again 5fec9182db + f97993ee66 are IMO not useful / wrong, they were not
discussed and are just a step backward.  The best change I can suggest
is to revert them now.
--8<---cut here---end--->8---

from 


Cheers,
simon





bug#57878: Minimal reproducible setup

2022-10-15 Thread Liliana Marie Prikler
Am Samstag, dem 15.10.2022 um 12:11 +0200 schrieb zimoun:
> Hi Liliana,
> 
> On Fri, 14 Oct 2022 at 20:22, Liliana Marie Prikler
>  wrote:
> 
> > > Maybe it could be worth to have that in the manual too, no?  For
> > > example, under ’Application setup, Emacs packages’ [1].
> > > 
> > Would you prefer a paragraph, a note, or a footnote?
> 
> As you would prefer.  Maybe a note with,
> 
>     Emacs can now compile packages natively.  Under the default
>     configuration, this means that Emacs packages will now be
>     just-in-time (JIT) compiled as you use them, and the results
>     stored in a subdirectory of your @code{user-emacs-directory}.
> 
>     Furthermore, the build system for Emacs packages
> transparently
>     supports native compilation, but note, that
>     @code{emacs-minimal}---the default Emacs for building
>     packages---has been configured without native compilation. 
> To
>     natively compile your emacs packages ahead of time, use a
>     transformation like @option{--with-input=emacs-
> minimal=emacs}.
> 
> BTW, thanks for your efforts to explain upstream the situation. :-)
Done.  Since I just copypasta'd the wording, I made you the author.

As for this bug: I've bumped emacs-next to a version that can inhibit
almost all native-compilation (trampolines are still compiled, but not
written to the cache), fixed the linker issue, and disabled native
compilation for emacs-ido-completing-read+.  Any remaining native-comp
issues or can this be closed?

Cheers





bug#58526: bug report upgrading Guix from 1.0.1 to 1.3

2022-10-15 Thread zimoun
Hi,

On Fri, 14 Oct 2022 at 20:08, Timothée Flutre  wrote:

> I have a computer with Ubuntu 22.04.1 LTS". Some time ago, I installed Guix
> to try it out, which I finally did not for various reasons. But hearing the
> talk of K. Hinsen last month convinced me of giving it another try.

Cool!


> I hence started by upgrading Guix, like this:
> sudo -i guix pull >& output_guix_pull.txt

Well, the guix-daemon is probably too old.  Maybe you need something
like [1]:

   sudo -i guix package --bootstrap -r guix -i \
 /gnu/store/n8vdar2f60mvq62g7mngpqwykbm9rw1q-guix-1.2.0rc2-1.0d4b1af

1: 


> The whole report is attached in the file "output_guix_pull.txt".

Missing attachment.


Cheers,
simon





bug#57878: Minimal reproducible setup

2022-10-15 Thread zimoun
Hi Liliana,

On Fri, 14 Oct 2022 at 20:22, Liliana Marie Prikler  
wrote:

>> Maybe it could be worth to have that in the manual too, no?  For
>> example, under ’Application setup, Emacs packages’ [1].
>>
> Would you prefer a paragraph, a note, or a footnote?

As you would prefer.  Maybe a note with,

Emacs can now compile packages natively.  Under the default
configuration, this means that Emacs packages will now be
just-in-time (JIT) compiled as you use them, and the results
stored in a subdirectory of your @code{user-emacs-directory}.

Furthermore, the build system for Emacs packages transparently
supports native compilation, but note, that
@code{emacs-minimal}---the default Emacs for building
packages---has been configured without native compilation.  To
natively compile your emacs packages ahead of time, use a
transformation like @option{--with-input=emacs-minimal=emacs}.

BTW, thanks for your efforts to explain upstream the situation. :-)


Cheers,
simon