Re: GNOME 49’s dependencies on systemd

Rutherther writes: > Hi Noé, > > Noé Lopez writes: > >> >> Hi again, >> >> As I have it working now, there is no dependency on guix-home. Simply, >> on session start an shepherd instance is started for GNOME. Completely >> independently from yo

Re: GNOME 49’s dependencies on systemd

Hi Noé, Noé Lopez writes: > > Hi again, > > As I have it working now, there is no dependency on guix-home. Simply, > on session start an shepherd instance is started for GNOME. Completely > independently from your home shepherd if you have one. Thanks for the info. I have

Re: GNOME 49’s dependencies on systemd

Hi, Noé Lopez writes: [...] > As I have it working now, there is no dependency on guix-home. Simply, > on session start an shepherd instance is started for GNOME. Completely > independently from your home shepherd if you have one. Sounds good, thanks for having worked on it! -

Re: GNOME 49’s dependencies on systemd

Noé Lopez writes: > Rutherther writes: > >> Hi Noé, >> >> Noé Lopez via "Development of GNU Guix and the GNU System distribution." >> writes: >> >>> Secondly, gnome-session (responsible for starting user services) is >>> go

Re: System without GDM [was: GNOME 49’s dependencies on systemd]

(program (file-append (specification->package "swaylock") "/bin/swaylock")) (using-pam? #t) (using-setuid? #f))) It works fine without any GNOME things--and like it is configured above it eve

Re: GNOME 49’s dependencies on systemd

Rutherther writes: > Hi Noé, > > Noé Lopez via "Development of GNU Guix and the GNU System distribution." > writes: > >> Secondly, gnome-session (responsible for starting user services) is >> going to use systemd too. So we need to replace it with a Shep

Re: GNOME 49’s dependencies on systemd

Hi Noé, Noé Lopez via "Development of GNU Guix and the GNU System distribution." writes: > Secondly, gnome-session (responsible for starting user services) is > going to use systemd too. So we need to replace it with a Shepherd > implementation. I am just wondering... ho

Re: GNOME 49’s dependencies on systemd

Hello, Noé Lopez via "Development of GNU Guix and the GNU System distribution." writes: > I started a thread on GNOME discourse[1], to create direct discussion with > the developers on their side. > > The author of the blog post responded, it seems they are willing to >

Re: GNOME 49’s dependencies on systemd

Noé Lopez writes: > Hi GNOME team, > > In [1], GNOME recently announced some new dependencies on systemd for > release 49. > > Firstly, GDM now depends on userdb to dynamically allocate user accounts > for showing multiple GDM at once. However, there is an alternate code &g

Re: GNOME 49’s dependencies on systemd

Hello, Liliana Marie Prikler writes: > Seeing how we're currently stalled on 48 already (mostly due to GTK > failing, but there are some more issues closer to core packages), I > think we should take our time and directly go towards a working userdb > replacement. Either we can strip out userdb

Re: System without GDM [was: GNOME 49’s dependencies on systemd]

Hi, Andreas Enge writes: > a somewhat tangential question, since in any case Gnome is an important > part of our system: Can we make it easier for a user to get rid of > everything Gnome? > > Personally I chose the XFCE desktop (but might also be happy with > others, such as K

Re: System without GDM [was: GNOME 49’s dependencies on systemd]

Hi Andreas, Andreas Enge writes: Hello, a somewhat tangential question, since in any case Gnome is an important part of our system: Can we make it easier for a user to get rid of everything Gnome? Are you thinking this would be an option in the installer? Or an easier way to remove

Re: System without GDM [was: GNOME 49’s dependencies on systemd]

Am Samstag, dem 14.06.2025 um 15:37 +0200 schrieb Andreas Enge: > Hello, > > a somewhat tangential question, since in any case Gnome is an > important part of our system: Can we make it easier for a user to get > rid of everything Gnome? > > Personally I chose the XFCE deskt

System without GDM [was: GNOME 49’s dependencies on systemd]

Hello, a somewhat tangential question, since in any case Gnome is an important part of our system: Can we make it easier for a user to get rid of everything Gnome? Personally I chose the XFCE desktop (but might also be happy with others, such as KDE or LXQT), but I think GDM is still required as

Re: GNOME 49’s dependencies on systemd

Am Samstag, dem 14.06.2025 um 12:10 +0200 schrieb Noé Lopez: > Hi GNOME team, > > In [1], GNOME recently announced some new dependencies on systemd for > release 49. > > Firstly, GDM now depends on userdb to dynamically allocate user > accounts for showing multiple GDM at on

GNOME 49’s dependencies on systemd

Hi GNOME team, In [1], GNOME recently announced some new dependencies on systemd for release 49. Firstly, GDM now depends on userdb to dynamically allocate user accounts for showing multiple GDM at once. However, there is an alternate code path for elogind that means we can preallocate gdm

[rust-team] gnome-authenticator

Hi Guix, I am probably becoming rust-team's worst nightmare after this but I just sent ~100 new Rust packages required to build gnome-authenticator . I divided them somewhat arbitrarily in these 4 issues with ~30 new patches each: 1. https://issues.guix.gnu.org/73956 2.

The state of gnome-team

Hi Guix, after CI hasn't been building gnome-team for a while (more than two weeks IIRC), I've force-pushed an update that removes what I believe to be the culprit – GLib 2.80. We still need GLib 2.80 or newer for gnome-shell, so I will try again to push an update. Then there'

Re: Emacs and Gnome branches are merged now

Hello, Liliana Marie Prikler skribis: > I've now pushed the merge commits for both emacs-team and gnome-team. > If you have a weak machine, PLEASE DO NOT PULL IMMEDIATELY AND WAIT FOR > CI TO CATCH UP! Despite efforts to prebuild things on the respective > branches, the mer

Re: Emacs and Gnome branches are merged now

just a heads' up: after pulling the gnome changes i was unable to log in (empty screen with frozen pointer after the password). `herd restart elogind` can be used to get back to the login screen. i could fix it using the following steps: 1. move away my ~/.local/share/gnome-shell/exten

Re: Emacs and Gnome branches are merged now

Am Samstag, dem 30.03.2024 um 14:20 + schrieb Christopher Baines: > I think the last merge of master in to gnome-team was pushed on the > 20th of March, with the merge of gnome-team in to master being pushed > today on the 30th. Good catch, I should have merged to gnome-team first

Re: Emacs and Gnome branches are merged now

Liliana Marie Prikler writes: > I've now pushed the merge commits for both emacs-team and gnome-team. Thank you to everyone involved in getting these changes through :D > If you have a weak machine, PLEASE DO NOT PULL IMMEDIATELY AND WAIT FOR > CI TO CATCH UP! Despite effor

Emacs and Gnome branches are merged now

Hey Guix, I've now pushed the merge commits for both emacs-team and gnome-team. If you have a weak machine, PLEASE DO NOT PULL IMMEDIATELY AND WAIT FOR CI TO CATCH UP! Despite efforts to prebuild things on the respective branches, the merge commit carries with it a rebuild of the most

Eudev in gnome-team [Was: Core-updates coordination and plans]

Hi Vivien, > The eudev package has been touched on gnome-team I reviewed the patches but do not believe they solve Bug#63508 or Bug#63787. That issue, stated succinctly, arises because configure.ac sets the Makefile variable $(udevrulesdir) to the store output [1] while custom rules like m

Re: gnome-doc-utils?

Hi, Christopher Am Mittwoch, dem 16.08.2023 um 10:48 -0800 schrieb Christopher Howard: > Hi, I was trying to build some software that requires "gnome-doc- > utils", and can't find it. Is that part of another Guix gnome > package, or something that still needs to be pac

gnome-doc-utils?

Hi, I was trying to build some software that requires "gnome-doc-utils", and can't find it. Is that part of another Guix gnome package, or something that still needs to be packaged? I've tried some packages out with guix shell but haven't figured it out yet. -- 📛 Chr

Re: [gnome-team] gtk+ on core-updates

Hello! Am Tue, Apr 11, 2023 at 02:36:13PM -0400 schrieb Maxim Cournoyer: > > I am also still questioning whether we should include gnome-boxes into the > > gnome meta package; it is a bit surprising to have a desktop environment > > depend on qemu. > GNOME Boxes is reall

Re: [gnome-team] gtk+ on core-updates

gt; good! > > Good idea, it is also what I tend to try out first... > > Repercussions trickle towards the leaves now. Maybe the Gnome team could > follow suit and fix the build errors for "guix build gnome"? I encountered a problem building qemu-minimal (I had erroneously d

Re: [gnome-team] gtk+ on core-updates

e >> good! > > Good idea, it is also what I tend to try out first... > > Repercussions trickle towards the leaves now. Maybe the Gnome team could > follow suit and fix the build errors for "guix build gnome"? > > Currently I see this in python-scipy (!): >

Re: [gnome-team] gtk+ on core-updates

first... Repercussions trickle towards the leaves now. Maybe the Gnome team could follow suit and fix the build errors for "guix build gnome"? Currently I see this in python-scipy (!): + meson setup --prefix=/gnu/store/i0d555a5fd7isi606aqqmbp5zgy9jh6p-python-3.10.7 /tmp/guix-build-py

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Am Sun, Apr 09, 2023 at 12:57:34PM -0400 schrieb Maxim Cournoyer: >> OK, that's been fixed in meson-build-system; I've taken that opportunity >> to update our meson package to its latest 1.0.1 release too. > > Great, thanks a lot

Re: [gnome-team] gtk+ on core-updates

Am Sun, Apr 09, 2023 at 12:57:34PM -0400 schrieb Maxim Cournoyer: > OK, that's been fixed in meson-build-system; I've taken that opportunity > to update our meson package to its latest 1.0.1 release too. Great, thanks a lot! The KDE package and the Gnome package I have in my p

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Hello Maxim, > > your gtk+ update on core-updates broke gnome packages since it somehow > moved the bin/ subdirectory from the bin to the out output, so that > gtk-update-icon-cache is not found any more by packages using gtk+:bin > as inp

Re: [gnome-team] gtk+ on core-updates

Hi Andreas, Andreas Enge writes: > Hello Maxim, > > your gtk+ update on core-updates broke gnome packages since it somehow > moved the bin/ subdirectory from the bin to the out output, so that > gtk-update-icon-cache is not found any more by packages using gtk+:bin > as inp

[gnome-team] gtk+ on core-updates

Hello Maxim, your gtk+ update on core-updates broke gnome packages since it somehow moved the bin/ subdirectory from the bin to the out output, so that gtk-update-icon-cache is not found any more by packages using gtk+:bin as input. Should the split not happen automagically? Maybe this is a

Re: Gnome dans core-updates

Update on gnome in core-updates: We have it! (At least we had it yesterday, the latest commits will lead to a few rebuilds that are not yet done.) Congratulations to all who made it work! Andreas

Re: Gnome dans core-updates

Am Thu, Mar 30, 2023 at 11:08:50AM +0200 schrieb Andreas Enge: > There is still libcacard with its runpath verification failure. Fixed by Efraim, thanks a lot! Andreas

Re: Gnome dans core-updates

Hello Josselin, Am Mon, Mar 20, 2023 at 08:18:41PM +0100 schrieb Josselin Poiret: > I ended up > fixing a couple of things locally for qemu-minimal to build (since I was > working on the Hurd and disk images). I also fixed u-boot-tools not > building on Python 3.10 (even though it's a swig bug th

Re: bug#62244: [PATCH] etc: Add gnome team.

Hello, Liliana Marie Prikler writes: > * etc/teams.scm.in (gnome): New team. > ("Liliana Marie Prikler"): Add to gnome. > --- > Hi folks, > > to get effort for GNOME 44 rolling while also recognizing the burden this > puts on folks, I've decided to add a

Re: Gnome dans core-updates

Hi Andreas, Andreas Enge writes: > Ah, it makes me super nervous. I now did for the first time ever... > There were a few problems with openjdk, where the automatic merge took > the wrong things from core-updates, instead of from master; hopefully > I worked it out correctly. At worst, we can al

Re: Gnome dans core-updates

Am Mon, Mar 20, 2023 at 07:17:41PM +0200 schrieb Efraim Flashner: > > Time to merge master into core-updates, I would say. > Often a good idea :) Ah, it makes me super nervous. I now did for the first time ever... There were a few problems with openjdk, where the automatic merge took the wrong thi

Re: Gnome dans core-updates

On Mon, Mar 20, 2023 at 06:11:56PM +0100, Andreas Enge wrote: > Am Mon, Mar 20, 2023 at 06:00:37PM +0100 schrieb Andreas Enge: > > If it is indeed a solution... Here is how far I got, patch attached. > > Actually it was updated by Efraim in master on March 9. Indeed, it was needed for qemu-minima

Re: Gnome dans core-updates

Am Mon, Mar 20, 2023 at 06:00:37PM +0100 schrieb Andreas Enge: > If it is indeed a solution... Here is how far I got, patch attached. Actually it was updated by Efraim in master on March 9. Time to merge master into core-updates, I would say. Andreas

Re: Gnome dans core-updates

Am Sun, Mar 19, 2023 at 03:14:59PM +0100 schrieb Josselin Poiret: > I agree with you, but given that upstream has already closed a > discussion on this topic with a clear stance, I don't really want to > re-open anything. We could go with that solution for now? If it is indeed a solution... Here

Re: Gnome dans core-updates

Hi Andreas, Andreas Enge writes: > Am Sun, Mar 19, 2023 at 10:20:27AM +0100 schrieb Josselin Poiret: >> The project does seem functional, they just seem to not care about >> making new releases, since they direct users to official builds of HEAD >> [1]. Maybe we could just point there as well?

Re: [bug#62244] [PATCH] etc: Add gnome team.

Liliana, Count me in. :-) Regards, RG. On 17/03/23 13:37, Liliana Marie Prikler wrote: * etc/teams.scm.in (gnome): New team. ("Liliana Marie Prikler"): Add to gnome. --- Hi folks, to get effort for GNOME 44 rolling while also recognizing the burden this puts on folks, I've d

Re: Gnome dans core-updates

Am Sun, Mar 19, 2023 at 10:20:27AM +0100 schrieb Josselin Poiret: > The project does seem functional, they just seem to not care about > making new releases, since they direct users to official builds of HEAD > [1]. Maybe we could just point there as well? > [1] https://github.com/ipxe/ipxe/discus

Re: Gnome dans core-updates

ease in December 2020, with more > than 400 commits since then. Difficult to assert that the release is > actually functional! Does it have to be a transitive input of gnome? > And a help-guix question: How do I retrace the part of the dependency > graph that links ipxe-qemu to gnome? The p

Re: Gnome dans core-updates

Am Sat, Mar 18, 2023 at 12:15:34PM +0100 schrieb Liliana Marie Prikler: > Feel free to promote it into a snippet. I didn't, because it only > affects the build files rather than the package being built. Okay, I did and pushed, many thanks again! Andreas

Re: Gnome dans core-updates

Am Samstag, dem 18.03.2023 um 11:36 +0100 schrieb Andreas Enge: > Am Sat, Mar 18, 2023 at 12:00:49AM +0100 schrieb Liliana Marie > Prikler: > > This error is caused by trying to install > > '/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion- > > 2.11/share/bash-completion/completions/pkco

Re: Gnome dans core-updates

Am Sat, Mar 18, 2023 at 12:00:49AM +0100 schrieb Liliana Marie Prikler: > This error is caused by trying to install > '/gnu/store/mxp199mvjb6dhyyg0pi4hn6c7m0xibvp-bash-completion- > 2.11/share/bash-completion/completions/pkcon'. Meson appears to have a > feature where it tries to use pkexec to gai

Re: Gnome dans core-updates

Am Sat, Mar 18, 2023 at 11:07:08AM +0100 schrieb Andreas Enge: > And a help-guix question: How do I retrace the part of the dependency > graph that links ipxe-qemu to gnome? I am still interested in the answer to this question, but here the line is short: ipxe-qemu -> qemu-minimal ->

Re: Gnome dans core-updates

e than 400 commits since then. Difficult to assert that the release is actually functional! Does it have to be a transitive input of gnome? And a help-guix question: How do I retrace the part of the dependency graph that links ipxe-qemu to gnome? Andreas

Re: Gnome dans core-updates

Am Fri, Mar 17, 2023 at 09:46:27PM +0100 schrieb Liliana Marie Prikler: > On a rather unrelated note, the uri > https://gitlab.freedesktop.org/spice/libcacard/uploads/13b249e695a0d9aa7cb501b1a85ebab1/libcacard-2.8.1.tar.xz > looks rather sus. Should we perhaps replace that with a git-reference? T

Re: Gnome dans core-updates

Am Freitag, dem 17.03.2023 um 20:40 +0100 schrieb Andreas Enge: > packagekit fails its installation phase (!) like so: > /gnu/store/xrn2zn2ky4jkigg2cal0g8sacpkfai9m-meson-0.63.2/bin/meson > install --no-rebuild > ninja: build stopped: subcommand failed. > error: in phase 'install': uncaught excepti

Re: Gnome dans core-updates

Am Freitag, dem 17.03.2023 um 21:46 +0100 schrieb Liliana Marie Prikler: > Also, the package definitions appear the same on master, so > there is possibly something else going on (but what?) Now that's quite embarrassing, but git worktree put my core-updates to master...

Re: Gnome dans core-updates

Am Freitag, dem 17.03.2023 um 20:40 +0100 schrieb Andreas Enge: > libcacard fails validate-runpath: > starting phase `validate-runpath' > validating RUNPATH of 1 binaries in > "/gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacard-2.8.1/lib"... > /gnu/store/29kdbd1q8lkyyr7apzczx53683mr0yhz-libcacar

Re: Gnome dans core-updates

Am Fri, Mar 17, 2023 at 08:40:00PM +0100 schrieb Andreas Enge: > libcacard fails validate-runpath: > It looks like we need some of nss (the "normal" output, not "bin") as a This did not help, nss appears in no runpath; this is what is printed: starting phase `shrink-runpath' /gnu/store/clqhrdvg1jp

Gnome dans core-updates

Hello, today I have compiled a maximum of inputs for gnome on berlin. Here is what is missing: The following derivations would be built: /gnu/store/1f71al4jx8pn7qnpp94642pvf6m4la5m-gnome-42.4.drv /gnu/store/4yvabkw23pwmxcanvl1qn8ch9jak7py4-packagekit-1.2.5.drv /gnu/store

[PATCH] etc: Add gnome team.

* etc/teams.scm.in (gnome): New team. ("Liliana Marie Prikler"): Add to gnome. --- Hi folks, to get effort for GNOME 44 rolling while also recognizing the burden this puts on folks, I've decided to add a gnome team to our teams.scm. To those in Debbugs CC – you know who you

Re: monero-gui-wallet does not show up in GNOME

> Done in commit ef0613a81dca73602e702cb5f5444ee94566f983. Awesome, thanks for doing that! all best, jgart

Re: monero-gui-wallet does not show up in GNOME

Guillaume Le Vaillant skribis: > "jgart" skribis: > >> Hi, >> >> Even after logging out and in I still can't see `monero-wallet-gui` >> executable show up when I press the "windows" key in the GNOME desktop. >> >> See thi

Re: monero-gui-wallet does not show up in GNOME

"jgart" skribis: > Hi, > > Even after logging out and in I still can't see `monero-wallet-gui` > executable show up when I press the "windows" key in the GNOME desktop. > > See this screenshot: > > https://up.nixnet.services/vyv1z6ia.pn

monero-gui-wallet does not show up in GNOME

Hi, Even after logging out and in I still can't see `monero-wallet-gui` executable show up when I press the "windows" key in the GNOME desktop. See this screenshot: https://up.nixnet.services/vyv1z6ia.png I installed monero-gui like this: https://git.sr.ht/~whereiseveryon

GNOME 43

Hi, Is anyone working on upgrading to GNOME 43?

Re: bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

Am Mittwoch, dem 23.03.2022 um 12:28 +0100 schrieb zimoun: > Hi, > > This old bug [1] is there since a long time.  What is the status? > > 1: > > [...] > > Is it still an issue? If I recall correctly, the offending caches have not been updated since, so

Re: bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

> > it > > would because both GDM and GNOME Shell appear to be leaving some > > binary > > files behind that cause different versions to crash > > unceremoneously. > > > > What can we do to make GDM and GNOME Shell more reliable? > > Is it still

Re: bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

Hi, This old bug [1] is there since a long time. What is the status? 1: <http://issues.guix.gnu.org/issue/36924> On Sun, 04 Aug 2019 at 23:00, Ricardo Wurmus wrote: > Today I again couldn’t log into my workstation after upgrading the > system. I’m using GDM + GNOME Shell. >

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi Florian, On Wed, 24 Nov 2021 at 15:40, "pelzflorian (Florian Pelz)" wrote: >>> I don't know if that convinces maintainers to change decisions. >> >> This decision is consistent with the analysis [1] done by Software >> Conservancy Freedom, at least. > > I did not speak about one decision. A

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Mon, Nov 22, 2021 at 07:10:48PM +0100, pelzflorian (Florian Pelz) wrote: > Maybe there is consensus that adding ZFS is a legal risk. I assume we are talking about the risk of litigation from Oracle (ZFS owner), right? Canonical decided in 2016 that the risk was low enough to take a chance and

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, Nov 24, 2021 at 01:32:56PM +0100, pelzflorian (Florian Pelz) wrote: > Sorry I misunderstood. I think your claim is that the ZFS decisions > listed by Ludo i.e. to disallow binary substitutes but to allow > patches for a ZFS file-system object (once reviewed) are inconsistent. > Right? > >

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, 24 Nov 2021 13:03:18 +0100 "pelzflorian (Florian Pelz)" wrote: > On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli > wrote: > > If that's the case then it would also be legal to redistribute > > binaries too as long as they are dynamically linked as the linking > > happens

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi Florian, On Wed, 24 Nov 2021 at 13:32, "pelzflorian (Florian Pelz)" wrote: > I don't know if that convinces maintainers to change decisions. This decision is consistent with the analysis [1] done by Software Conservancy Freedom, at least. I have not read a clear position by the FSF. They

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, Nov 24, 2021 at 01:03:29PM +0100, pelzflorian (Florian Pelz) wrote: > On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli wrote: > > If that's the case then it would also be legal to redistribute binaries > > too as long as they are dynamically linked as the linking happens at

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, Nov 24, 2021 at 01:45:19AM +0100, Denis 'GNUtoo' Carikli wrote: > If that's the case then it would also be legal to redistribute binaries > too as long as they are dynamically linked as the linking happens at > runtime. The FSF is unable to have such a position. It seems unrelated to the

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi Denis, On Wed, 24 Nov 2021 at 00:51, Denis 'GNUtoo' Carikli wrote: > If I understood correctly Florian, the argument here is that it is safe > to redistribute source code under a GPL incompatible license that links > to GPL code because it's in source form? Maybe you could be interested by t

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Wed, 24 Nov 2021 00:50:04 +0100 Denis 'GNUtoo' Carikli wrote: > Hi, > > On Tue, 23 Nov 2021 18:29:22 +0100 > Ludovic Courtès wrote: > > > When consensus cannot be met, maintainers have the last say. > > > > But again, my understanding is that there’s no new decision to be > > made here. >

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hi, On Tue, 23 Nov 2021 18:29:22 +0100 Ludovic Courtès wrote: > When consensus cannot be met, maintainers have the last say. > > But again, my understanding is that there’s no new decision to be made > here. If I understood correctly Florian, the argument here is that it is safe to redistribute

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

ision on ZFS and their patches is bad. Maybe their patches >> would be for the RFC model to decide? The decision to include zfs-on-linux, but not provide substitutes, was made long ago. Then there was a discussion in this very thread where I think (but I don’t remember precisely) there was

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Mon, 22 Nov 2021 19:10:48 +0100 "pelzflorian (Florian Pelz)" wrote: > I don’t actually care about ZFS myself, but there should be a decision > because I think current badly supported ZFS makes people here unhappy. For people that really want the ZFS kernel module, would using an extra channel f

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Sun, Nov 21, 2021 at 11:54:15AM +0100, pelzflorian (Florian Pelz) wrote: > raid5atemyhomework wrote patches to add ZFS to Guix > . I put them in CC. That there is > no decision on ZFS and their patches is bad. Maybe their patches > would be for the RFC model

Re: ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

On Sun, 21 Nov 2021 11:54:15 +0100 "pelzflorian (Florian Pelz)" wrote: > Hello Denis. Thank you for your write-up. Hi, > raid5atemyhomework wrote patches to add ZFS to Guix > . I put them in CC. That there is > no decision on ZFS and their patches is bad. M

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Denis, On Sun, 21 Nov 2021 at 02:33, Denis 'GNUtoo' Carikli wrote: >> That's not the general consensus at all > On what part precisely is there no consensus? Consensus about distributing ZFS as source code but not as binary. As the comment says, IIUC: --8<---cut here--

ZFS part of Guix? RFC? (Re: Effectively force all GNOME users to locally compile ZFS?)

Hello Denis. Thank you for your write-up. raid5atemyhomework wrote patches to add ZFS to Guix . I put them in CC. That there is no decision on ZFS and their patches is bad. Maybe their patches would be for the RFC model to decide? As for Denis’ arguments

Re: Effectively force all GNOME users to locally compile ZFS?

On Sat, 20 Nov 2021 03:34:26 +0100 Tobias Geerinckx-Rice wrote: > Hi Denis, Hi, > but did you mean to include a reference to someone who disagrees? I forgot to look for references on that. > Denis 'GNUtoo' Carikli [wrote]: > > Even in source code form[1]. > That's not the general consensus at

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Denis, Denis 'GNUtoo' Carikli 写道： Even in source code form[1]. That's not the general consensus at all, but did you mean to include a reference to someone who disagrees? Kind regards, T G-R signature.asc Description: PGP signature

Re: Effectively force all GNOME users to locally compile ZFS?

hat work. Even in source code form[1]. The same applies to the ZFS kernel module source code and binaries. And so because of that images with gnome can't be redistributed without violating the GPL. And the corresponding source of the ZFS package is also violating the GPL. So the question is

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Tobias, Tobias Geerinckx-Rice writes: > Something about this virt-manager reasoning strikes me as bogus, According to , "a module covered by the GPL and a module covered by the CDDL cannot legally be linked together." Regards,

Re: Effectively force all GNOME users to locally compile ZFS?

Mark H Weaver 写道： Maxime Devos 写道： Perhaps the "zfs" package can be split in an userspace package (containing userspace binaries and libraries) and a kernelspace component (containing the kernel module)? And let the kernelspace component be unsubstitutable and the userspace component substitu

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Mark, Something about this virt-manager reasoning strikes me as bogus, but it's complicated by how Guix works in practice… I think any perceived (pseudo-)(cosplay-)(that includes me)‘legal’ issues are a distraction. Mark H Weaver 写道： For now, I think that commit 61ccd756e5ff73b2f8dc3449

Re: Effectively force all GNOME users to locally compile ZFS?

FS by default, but we could have “libvirt-with-zfs” etc. Who knows, but I'd rather just revert the commit and be done with it. ‘Nothing depend on ZFS by default’ is clear and unambiguous. Thanks! I agree that GNOME Boxes and libvirt should not depend on ZFS by default because (1) ZFS is a

Re: Effectively force all GNOME users to locally compile ZFS?

including CDDL-licensed ZFS code on the userspace side. 'virt-manager' is distributed under GPLv2+ and links with 'libvirt'. > Meanwhile, what do you think about a temporary revert of commit > 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 to avoid causing GNOME users > ZFS c

Re: Effectively force all GNOME users to locally compile ZFS?

Hi Ludovic, Ludovic Courtès writes: > I would rather have nothing depend on ZFS by default, but we could have > “libvirt-with-zfs” etc. > > I agree that GNOME Boxes and libvirt should not depend on ZFS by default > because (1) ZFS is an optional feature and probably not widely

Re: Effectively force all GNOME users to locally compile ZFS?

el modules binaries (re)distribution, (obviously) not for the userspace binaries, so AFAIU this would be a fine solution. Meanwhile, what do you think about a temporary revert of commit 61ccd756e5ff73b2f8dc3449df537f1c5adb5872 to avoid causing GNOME users ZFS compilation upon update (if I c

Re: Effectively force all GNOME users to locally compile ZFS?

Hi, Tobias Geerinckx-Rice skribis: > Mark H Weaver 写道： >> The reason is that our 'gnome' package depends >> on 'gnome-boxes' > > To me (a non-GNOME user), this is the problem. GNOME Boxes is a > wonderful front-end for creating and running v

Re: Effectively force all GNOME users to locally compile ZFS?

Tobias Geerinckx-Rice writes: > Maxime Devos 写道： >> Perhaps the "zfs" package can be split in an userspace package >> (containing userspace binaries and libraries) and a kernelspace >> component (containing the kernel module)? And let the kernelspace >> component be unsubstitutable and the usersp

Re: Effectively force all GNOME users to locally compile ZFS?

Hi: On Sat, Jul 03, 2021 at 10:16:54PM +0200, Tobias Geerinckx-Rice wrote: > Maxime, > > Maxime Devos 写道： > > > > That's a very good idea if possible. Why can substitutes not be offered for ZFS as a standalone module? I'm not a lawyer nor do I understand much lawyerese, but AIUI, the problem s

Re: Effectively force all GNOME users to locally compile ZFS?

Tobias Geerinckx-Rice 写道： My understanding was (and still is) that this is specific to CDDL+GPL only, not CDDL+LGPL, so distributing a dynamically linked libvirt with ZFS support is allowed. Do note that I did not consult my lawyer on this matter, partly because the man's an idiot. Kind re

Re: Effectively force all GNOME users to locally compile ZFS?

Domagoj Stolfa 写道： Why can substitutes not be offered for ZFS as a standalone module? I'm not a lawyer nor do I understand much lawyerese, but AIUI, the problem stems from the FSF lawyers thinking it wouldn't stand up in court to distribute CDDL software linked against GPL'd software as one big

Re: Effectively force all GNOME users to locally compile ZFS?

Maxime, Maxime Devos 写道： Perhaps the "zfs" package can be split in an userspace package (containing userspace binaries and libraries) and a kernelspace component (containing the kernel module)? And let the kernelspace component be unsubstitutable and the userspace component substitutable? T

  1   2   3   4   5   6   7   8   >