Re: Conflict resolution (gtk, wayland)
For the record, I've added 'wayland' to the '--with-platforms' flag again. A lot of things get broken on Wayland otherwise. It looks like we'll have to wait for Mesa to remove it themselves. On Tue, 22 May 2018 17:55:49 +0200 Marius Bakke wrote: > Rutger Helling writes: > > > I've created a patch to update Mesa on staging, along with removing > > wayland-egl from it. I can confirm I can still start GNOME on > > Wayland manually after rebuilding with this patch. > > Excellent, thanks! > > > Should I apply this to staging now? It's been two weeks since the > > last commit to staging, and a merge doesn't seem to be happening > > anytime soon. > > Hydra is currently busy with 'core-updates'. In the mean time, please > queue up patches on 'staging' so we can start it as soon as > core-updates is merged. The patch LGTM! > > > On an unpleasant side-note, certain things are completely broken on > > GNOME on Wayland with staging. Menus and buttons don't work > > anymore. I suspect this is because our mutter and gnome-shell > > packages are too old (3.24.x instead of 3.28.x). > > Does GNOME on Wayland work on current 'master'? The only real > difference on staging (apart from this patch) is GTK+ 3.22.30, which > is fairly uneventful: > > https://ftp.acc.umu.se/pub/gnome/sources/gtk+/3.22/gtk+-3.22.30.news > > But perhaps they removed some other interfaces when adding xdg-shell > support? pgprc2DyxU1yT.pgp Description: OpenPGP digital signature
Re: Conflict resolution (gtk, wayland)
I've just applied the patch to staging, thanks! Regarding the Wayland issue, it seems to have something to do with the Mesa update to the 18.x series. I've tried building master with a cherry-picked Mesa update and had the same problem. Maybe the newer wayland-egl is the problem. The problem's also still there after applying this new staging patch. That's why I speculate it has something to do with the mutter and gnome-shell components being too old (not 100% sure). On Tue, 22 May 2018 17:55:49 +0200 Marius Bakke wrote: > Rutger Helling writes: > > > I've created a patch to update Mesa on staging, along with removing > > wayland-egl from it. I can confirm I can still start GNOME on > > Wayland manually after rebuilding with this patch. > > Excellent, thanks! > > > Should I apply this to staging now? It's been two weeks since the > > last commit to staging, and a merge doesn't seem to be happening > > anytime soon. > > Hydra is currently busy with 'core-updates'. In the mean time, please > queue up patches on 'staging' so we can start it as soon as > core-updates is merged. The patch LGTM! > > > On an unpleasant side-note, certain things are completely broken on > > GNOME on Wayland with staging. Menus and buttons don't work > > anymore. I suspect this is because our mutter and gnome-shell > > packages are too old (3.24.x instead of 3.28.x). > > Does GNOME on Wayland work on current 'master'? The only real > difference on staging (apart from this patch) is GTK+ 3.22.30, which > is fairly uneventful: > > https://ftp.acc.umu.se/pub/gnome/sources/gtk+/3.22/gtk+-3.22.30.news > > But perhaps they removed some other interfaces when adding xdg-shell > support? pgp5dLJyN3KNi.pgp Description: OpenPGP digital signature
Re: Conflict resolution (gtk, wayland)
I've created a patch to update Mesa on staging, along with removing
wayland-egl from it. I can confirm I can still start GNOME on Wayland
manually after rebuilding with this patch.
Should I apply this to staging now? It's been two weeks since the last
commit to staging, and a merge doesn't seem to be happening anytime
soon.
On an unpleasant side-note, certain things are completely broken on
GNOME on Wayland with staging. Menus and buttons don't work anymore. I
suspect this is because our mutter and gnome-shell packages are too old
(3.24.x instead of 3.28.x).
On Thu, 17 May 2018 16:13:28 +0200
l...@gnu.org (Ludovic Courtès) wrote:
> Hi,
>
> Rutger Helling skribis:
>
> > It's because Wayland recently absorbed libwayland-egl. See:
> > https://lists.freedesktop.org/archives/wayland-devel/2018-April/037767.html
> >
> > Specifically:
> > "libwayland-egl is now part of libwayland, and will presumably be
> > removed from mesa in the not too distant future."
>
> Thanks for the info.
>
> On our next MESA update, we should probably explicitly remove
> libwayland-egl from MESA if upstream hasn’t done it yet.
>
> Ludo’.
From b786aaa2f8353d6bf9fbcf3b8ce77af765392ed5 Mon Sep 17 00:00:00 2001
From: Rutger Helling
Date: Tue, 22 May 2018 02:22:30 +0200
Subject: [PATCH] gnu: mesa: Update to 18.0.4.
* gnu/packages/gl.scm (mesa): Update to 18.0.4.
[source]: Remove mesa-wayland-egl-symbols-check-mips.patch.
[arguments]: Remove wayland from --with-platforms configure flag.
* gnu/local.mk: Remove mesa-wayland-egl-symbols-check-mips.patch.
* gnu/packages/patches/mesa-wayland-egl-symbols-check-mips.patch: Remove file.
---
gnu/local.mk | 1 -
gnu/packages/gl.scm | 9 -
.../mesa-wayland-egl-symbols-check-mips.patch | 15 ---
3 files changed, 4 insertions(+), 21 deletions(-)
delete mode 100644 gnu/packages/patches/mesa-wayland-egl-symbols-check-mips.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index 7b8ddad83..7b0de9e10 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -917,7 +917,6 @@ dist_patch_DATA = \
%D%/packages/patches/mcrypt-CVE-2012-4426.patch \
%D%/packages/patches/mcrypt-CVE-2012-4527.patch \
%D%/packages/patches/mesa-skip-disk-cache-test.patch \
- %D%/packages/patches/mesa-wayland-egl-symbols-check-mips.patch \
%D%/packages/patches/meson-for-build-rpath.patch \
%D%/packages/patches/metabat-fix-compilation.patch \
%D%/packages/patches/mhash-keygen-test-segfault.patch \
diff --git a/gnu/packages/gl.scm b/gnu/packages/gl.scm
index 441d4646e..dcd647202 100644
--- a/gnu/packages/gl.scm
+++ b/gnu/packages/gl.scm
@@ -224,7 +224,7 @@ also known as DXTn or DXTC) for Mesa.")
(define-public mesa
(package
(name "mesa")
-(version "18.0.2")
+(version "18.0.4")
(source
(origin
(method url-fetch)
@@ -236,10 +236,9 @@ also known as DXTn or DXTC) for Mesa.")
version "/mesa-" version ".tar.xz")))
(sha256
(base32
- "1cz7p4b4yy201djzv3s28zx27f5cqwv0zgzqp5lcaba8d2bibylq"))
+ "03wjlb5qy1mn8d6zm0q1pq35x60agrfxyh9bmq6w59ghrvkwyfqz"))
(patches
- (search-patches "mesa-wayland-egl-symbols-check-mips.patch"
- "mesa-skip-disk-cache-test.patch"
+ (search-patches "mesa-skip-disk-cache-test.patch"
(build-system gnu-build-system)
(propagated-inputs
`(;; The following are in the Requires.private field of gl.pc.
@@ -284,7 +283,7 @@ also known as DXTn or DXTC) for Mesa.")
'("--with-gallium-drivers=i915,nouveau,r300,r600,radeonsi,svga,swrast,virgl")))
;; Enable various optional features. TODO: opencl requires libclc,
;; omx requires libomxil-bellagio
- "--with-platforms=x11,drm,wayland,surfaceless"
+ "--with-platforms=x11,drm,surfaceless"
"--enable-glx-tls";Thread Local Storage, improves performance
;; "--enable-opencl"
;; "--enable-omx"
diff --git a/gnu/packages/patches/mesa-wayland-egl-symbols-check-mips.patch b/gnu/packages/patches/mesa-wayland-egl-symbols-check-mips.patch
deleted file mode 100644
index aa2278697..0
--- a/gnu/packages/patches/mesa-wayland-egl-symbols-check-mips.patch
+++ /dev/null
@@ -1,15 +0,0 @@
-Fix 'wayland-egl-symbols-check' on mips64el-linux, where an additional symbol
-(_ftext) is present in libwayland-egl.so.
-
-Patch by Mark H Weaver
-
mesa-12.0.1/src/egl/wayland/wayland-egl/wayland-egl-symbols-check.orig 2016-01-18 02:39:25.0 -0500
-+++ mesa-12.0.1/src/egl/wayland/wayland-egl/wayland-egl-symbols-check 2016-10-24 16:25:07.110721426 -0400
-@@ -7,6 +7,7 @@
- wl_egl_window_destroy
- wl_egl_window_get_attached_size
- _fini
-+_ftext
- _init
- EOF
- done)
--
2.17.0
pgpIdMjB462YE.pgp
Description: OpenPGP digital signature
Re: Conflict resolution (gtk, wayland)
It's because Wayland recently absorbed libwayland-egl. See: https://lists.freedesktop.org/archives/wayland-devel/2018-April/037767.html Specifically: "libwayland-egl is now part of libwayland, and will presumably be removed from mesa in the not too distant future." On Mon, 14 May 2018 11:23:41 +0200 l...@gnu.org (Ludovic Courtès) wrote: > Hello, > > Pierre Neidhardt skribis: > > > Sometimes when updating or install packages, guix encounters > > conflicts. It's usually smart enough to fix it by itself. > > > > That said, conflicts seems to be a telltale sign of bad packaging > > (e.g. duplicate files in a package and its inputs). > > > > Presently guix reports 3 conflicts on my install: > > > > warning: collision encountered: > > > > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/pkgconfig/wayland-egl.pc > > > > /gnu/store/2w8lhl8hyvciy3hb0h2r0mbhx7pmniy1-wayland-1.15.0/lib/pkgconfig/wayland-egl.pc > > warning: > > choosing > > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/pkgconfig/wayland-egl.pc > > > > warning: collision encountered: > > > > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/libwayland-egl.la > > > > /gnu/store/2w8lhl8hyvciy3hb0h2r0mbhx7pmniy1-wayland-1.15.0/lib/libwayland-egl.la > > warning: > > choosing > > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/libwayland-egl.la > > > > warning: collision encountered: > > > > /gnu/store/nf6py3ddvk8nsqxg7jlg0kmiqjigiqgw-gtk-icon-themes/share/icons/hicolor/icon-theme.cache > > > > /gnu/store/mg1ilfq7ajcsk12kanzsbb8jhgv7g5vm-gtk+-3.22.29/share/icons/hicolor/icon-theme.cache > > warning: > > choosing > > /gnu/store/nf6py3ddvk8nsqxg7jlg0kmiqjigiqgw-gtk-icon-themes/share/icons/hicolor/icon-theme.cache > > > > [...] > > > So if I get it right, gtk-icon-themes is an automatically generated > > store items for each profile and it duplicates a file found in > > gtk+-3.22.29. > > Is this a packaging mistake? > > No, “icon-theme.cache” collisions can be ignored. In fact, I think we > should not warn about them in the first place. > > > Now to wayland: > > > >> guix gc -R /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8 > >> | grep wayland > > /gnu/store/2w8lhl8hyvciy3hb0h2r0mbhx7pmniy1-wayland-1.15.0 > > > >> guix gc > >> --referrers /gnu/store/2w8lhl8hyvciy3hb0h2r0mbhx7pmniy1-wayland-1.15.0 > >> | grep mesa > > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8 > > > > So mesa depends on wayland and wayland is properly referred to by > > mesa. So far so good. Same question: is this a packaging mistake? > > It could be. > > Actually, the .so files are identical, but the .la files differ > trivially: > > --8<---cut here---start->8--- > $ cmp $(guix build mesa)/lib/libwayland-egl.so $(guix build > wayland)/lib/libwayland-egl.so $ diff -u $(guix build > mesa)/lib/libwayland-egl.la $(guix build > wayland)/lib/libwayland-egl.la > --- > /gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib/libwayland-egl.la > 1970-01-01 01:00:01.0 +0100 > +++ > /gnu/store/2w8lhl8hyvciy3hb0h2r0mbhx7pmniy1-wayland-1.15.0/lib/libwayland-egl.la > 1970-01-01 01:00:01.0 +0100 @@ -1,5 +1,5 @@ # > libwayland-egl.la - a libtool library file -# Generated by libtool > (GNU libtool) 2.4.6 Debian-2.4.6-2 +# Generated by libtool (GNU > libtool) 2.4.6 # # Please DO NOT delete this file! # It is necessary > for linking the library. @@ -38,4 +38,4 @@ > dlpreopen='' > > # Directory that this library needs to be installed in: > -libdir='/gnu/store/9hddxnv7q3q819axyw0yngzppmrgmjfi-mesa-17.3.8/lib' > +libdir='/gnu/store/2w8lhl8hyvciy3hb0h2r0mbhx7pmniy1-wayland-1.15.0/lib' > --8<---cut here---end--->8--- > > I’m not familiar enough with these packages, and I’m not sure why they > both provide this library. > > Ideas? Rutger maybe? > > Thanks, > Ludo’. pgpGfRX2xlIsu.pgp Description: OpenPGP digital signature
Re: Don't auto-start a service in Shepherd
Thanks for the replies. My use case is that I don't want to auto-start SDDM, since I usually start GNOME (Wayland) from the TTY. However there are certain cases where I want to start GNOME on X11, for which I do need SDDM. On systemd you can do "systemctl disable service", so I was wondering if there was an equivelant command in Shepherd. Removing the service entirely and reconfiguring every time I want to start SDDM isn't really what I'm looking for. I'll have a look at `auto-start?`. I think it would be nice if all services exposed this option. On Sun, 25 Feb 2018 09:27:49 +1100 Carlo Zancanaro wrote: > On Fri, Feb 23 2018, Rutger Helling wrote: > > Is there a way to prevent auto-starting a service in Shepherd? I > > find that if I use "herd disable service" it still automatically > > starts the service on a reboot/reconfigure. > > I've just had a look at gnu/services/shepherd.scm, and it looks > like system services can set `auto-start?` to #f when creating > their shepherd-service, but not many expose this. I think openssh > is the only service to expose it to the system configuration. You > could try patching the service you want to use to expose the > option to not automatically start it. Which service are you trying > to disable? > > There's a discussion to be had about whether shepherd should > remember disabled services across a reboot/reconfigure. I don't > think it should, because the running services should be considered > a part of the system specification. > > Carlo pgpcM7GYKADb5.pgp Description: OpenPGP digital signature
Don't auto-start a service in Shepherd
Hello Guix, Is there a way to prevent auto-starting a service in Shepherd? I find that if I use "herd disable service" it still automatically starts the service on a reboot/reconfigure. pgpvxUx8AYJd9.pgp Description: OpenPGP digital signature
Re: Moving packages over to new module
Alright, I've done so. The migration should now be complete. Thanks for the help! On Thu, 22 Feb 2018 12:51:43 +0100 Andreas Enge wrote: > On Thu, Feb 22, 2018 at 12:33:22PM +0100, Rutger Helling wrote: > > I ended up using git log --grep= and have moved the packages. > > Using 'git blame' I found that a few copyright lines can be removed > > from games.scm now. If a person has only imported a module ((gnu > > packages base) for example), should I keep the copyright notice or > > lose it? > > That is always a good question. I think importing a module is not > copy- rightable, so I would drop the line. > > Personally I also do not add my copyright when simply updating a > package (new version and hash), unless more complex changes are > required. > > Andreas > pgp9IHNKpIJ6F.pgp Description: OpenPGP digital signature
Re: Moving packages over to new module
I ended up using git log --grep= and have moved the packages. Using 'git blame' I found that a few copyright lines can be removed from games.scm now. If a person has only imported a module ((gnu packages base) for example), should I keep the copyright notice or lose it? On Thu, 22 Feb 2018 11:43:51 +0100 Andreas Enge wrote: > On Thu, Feb 22, 2018 at 10:57:06AM +0100, Ricardo Wurmus wrote: > > We need to move the copyright notices as well. For that I usually > > look at the git log for the packages that should be moved. Since > > we’re using predictable commit messages this can easily be grep’ed > > from the git log. > > This would require to also look at all the other packages in the > module, to decide whether the copyright notice should be moved or > copied. Maybe "git blame MODULE.scm" could also be helpful in that > respect: If used after the packages have been moved, it shows who has > contributed to the remaining packages. > > Andreas > pgpuWuekJTJkB.pgp Description: OpenPGP digital signature
Moving packages over to new module
Hello, I've added a new (gnu packages emulators) module. As a result a few existing packages from (gnu packages games) should be moved over. At first glance, this includes: desmume dosbox emulation-station higan mgba mupen64plus* nestopia-ue retroarch I'm a little unsure about how to handle the existing copyright notices however. What's the usual procedure for moving packages over? pgpSS5SBIgxsd.pgp Description: OpenPGP digital signature
Re: Building with multiple architectures
I've already solved this via a different way, but it's still an interesting question I guess. I think the only way to do it is via specifying #:system in arguments for an input to force it to build for a certain architecture? On Sat, 30 Dec 2017 17:15:53 +0100 Rutger Helling wrote: > Hey Guix, > > is it possible to specify a specific architecture for an input? I'm > trying to build Wine with WOW64 (meaning both 32-bit and 64-bit > support at once), however this requires that I need access to both > 32-bit and 64-bit (i686/x86_64) inputs. pgpIsffCj6i0p.pgp Description: OpenPGP digital signature
Repeating phases during build process
Hey Guix, is there a way to tell Guix to repeat an earlier phase when building? pgp7Bjq6aeVTQ.pgp Description: OpenPGP digital signature
Building with multiple architectures
Hey Guix, is it possible to specify a specific architecture for an input? I'm trying to build Wine with WOW64 (meaning both 32-bit and 64-bit support at once), however this requires that I need access to both 32-bit and 64-bit (i686/x86_64) inputs. pgptDZB_Z65WH.pgp Description: OpenPGP digital signature
