Re: 'core-updates' Q4 2019
Hello again Miguel, I apologize for the delay. My semester at university is becoming busier as final exams get closer! On Fri, 2019-11-08 at 01:58 +0100, Miguel Arruga Vivas wrote: > Hi Kei, ... > > > - The patch for gedit contains a reference to libgd, wouldn't it > > > be > > >clearer for the reader/updater to have it defined in a let > > > over > > > the package definition and use the name in native-inputs? > > > > > > > I'm not sure. I don't know if there is an explicit convention for > > packaging software that is distributed like this, and the examples > > of > > this in the code base (that I've seen, at least) define the > > third-party library the way I've done it here. I'm open to change > > on > > this point though. > > This actually should have been an open question, as I have a patch on > libosinfo, related with gnome-boxes (patches coming soon) and it > doesn't feel right for me having usb.ids and pci.ids hidden there, so > I've put another origin needed (osinfo-db) out there. > After some thought, I believe it is clearer to someone reading the package to see the origin object defined in the "native-inputs" field rather than a let over the whole package. The extra "let" adds a layer of indirection in reading the code that I'm not sure pays off. Also, such a bound variable could be accessed both directly and through the "native-inputs" field, so that could be confusing as well. > > > - Is there any reason to not patch-out the gtk-icon-update-cache > > >invocations? If I understand it correctly, this is performed > > > at > > >profile level, so makes no sense creating a cache at package > > > level, isn't it? The patches for quadrapassel, gnome-klotski, > > > ghex, > > >gnome-sudoku, gnome-mines, five-or-more and gedit contain > > > references to it. Maybe creating a package like > > > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to > > > "true" from coreutils would help in the long term. > > > > > > > I don't think such a reason exists. I could add changes that > > substitute calls to "gtk-icon-update-cache" with "true" for these > > packages, but I agree that a better solution may be possible. > > Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache' > > phase in the relevant build systems? > > Some of these packages already have phases for it on master. I > rebased > your branch onto it (1a9df94cec..fb936351d3), I had to solve two > merge > conflicts: devhelp and totem. > > devhelp's patch has only a trivial conflict, as there was no > arguments > parameter before. OTOH, I did not check as much as I should totem's > last day, as now I have one question here: Who kills the Xvfb server > on display :1 after the tests? I see it's a common idiom, but I > don't > get why shouldn't the daemon treat it like from any other process and > wait for it to reach completion (other than technical means, I mean). > This could be a great place for a #:xorg-for-tests?, should I try? > I really like the idea of an #:xorg-for-tests? flag! If you can attempt a patch, I'll do my best to help. > > > As a final comment, the gnome release cycle and the amount of > > > packages involved is quite big, so again, thank you. > > > > > > Happy hacking! > > > Miguel > > > > Thanks Miguel! This comment and review means a lot! > > Kei > > Thank you too > > Best regards, > Miguel
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > Miguel Arruga Vivas writes: > Boot and login worked properly for me after I cleared the contents of > my /var/lib/gdm directory (if it's unclear why that directory > matters, see > https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html > for a quick overview). Great pointer, thank you, and good that it's solved. > > - The patch for gedit contains a reference to libgd, wouldn't it be > >clearer for the reader/updater to have it defined in a let over > > the package definition and use the name in native-inputs? > > > > I'm not sure. I don't know if there is an explicit convention for > packaging software that is distributed like this, and the examples of > this in the code base (that I've seen, at least) define the > third-party library the way I've done it here. I'm open to change on > this point though. This actually should have been an open question, as I have a patch on libosinfo, related with gnome-boxes (patches coming soon) and it doesn't feel right for me having usb.ids and pci.ids hidden there, so I've put another origin needed (osinfo-db) out there. > > - Is there any reason to not patch-out the gtk-icon-update-cache > >invocations? If I understand it correctly, this is performed at > >profile level, so makes no sense creating a cache at package > > level, isn't it? The patches for quadrapassel, gnome-klotski, ghex, > >gnome-sudoku, gnome-mines, five-or-more and gedit contain > > references to it. Maybe creating a package like > > xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to > > "true" from coreutils would help in the long term. > > > > I don't think such a reason exists. I could add changes that > substitute calls to "gtk-icon-update-cache" with "true" for these > packages, but I agree that a better solution may be possible. > Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache' > phase in the relevant build systems? Some of these packages already have phases for it on master. I rebased your branch onto it (1a9df94cec..fb936351d3), I had to solve two merge conflicts: devhelp and totem. devhelp's patch has only a trivial conflict, as there was no arguments parameter before. OTOH, I did not check as much as I should totem's last day, as now I have one question here: Who kills the Xvfb server on display :1 after the tests? I see it's a common idiom, but I don't get why shouldn't the daemon treat it like from any other process and wait for it to reach completion (other than technical means, I mean). This could be a great place for a #:xorg-for-tests?, should I try? > > As a final comment, the gnome release cycle and the amount of > > packages involved is quite big, so again, thank you. > > > > Happy hacking! > > Miguel > > Thanks Miguel! This comment and review means a lot! > Kei Thank you too Best regards, Miguel
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > `git push --force-with-lease` doesn't seem to work on the WIP branch. > This is a good thing in general, but how do I rewrite history? Do I > just delete the remote WIP branch and recreate a new one with the > appropriate changes? Yup! This is what I do for “wip-haskell-updates” and what I’ve seen others do before. -- Tim
Re: 'core-updates' Q4 2019
On Wed, 2019-11-06 at 12:46 -0500, Leo Famulari wrote: > On Tue, Nov 05, 2019 at 06:38:05PM -0500, Kei Kebreau wrote: > > > - The patch for libdazzle only changes the xorg-server, as it > > > already > > >is at version 3.33.90 in master. It still makes sense as a > > > patch, > > >but the title indicates a version downgrade. > > > > > > > Good catch! I'd correct this commit message, but I don't know what > > the > > rules are for rewriting commit history on Guix WIP branches. For > > now > > I'll note your comment and leave the message alone. > > You can feel free to rewrite history completely on the WIP branches, > including commit messages. `git push --force-with-lease` doesn't seem to work on the WIP branch. This is a good thing in general, but how do I rewrite history? Do I just delete the remote WIP branch and recreate a new one with the appropriate changes?
Re: 'core-updates' Q4 2019
On Tue, Nov 05, 2019 at 06:38:05PM -0500, Kei Kebreau wrote: > > - The patch for libdazzle only changes the xorg-server, as it already > >is at version 3.33.90 in master. It still makes sense as a patch, > >but the title indicates a version downgrade. > > > > Good catch! I'd correct this commit message, but I don't know what the > rules are for rewriting commit history on Guix WIP branches. For now > I'll note your comment and leave the message alone. You can feel free to rewrite history completely on the WIP branches, including commit messages.
Re: 'core-updates' Q4 2019
Miguel Arruga Vivas writes: > Hi Kei, > > Kei Kebreau writes: >> Update: Please check out the new wip-gnome-updates branch of the Guix >> git repository for continued updates. The contents of the notabug.org >> link given above will be changed to a notice that says to do this. > > Thank you very much for this huge effort. I've been playing with the > branch and I have a working system, both X11 with GDM and Wayland with > SDDM (I haven't tried hard enough to set up gdm with wayland as only a > change to gdm-configuration doesn't seem to have any effect) and your > branch works great on my machine, do you still have the issue during > boot? I haven't found any (new) problem on the applications I've > tested (x86_64, normal use with almost all of the gnome applications, > not the games though.) > Boot and login worked properly for me after I cleared the contents of my /var/lib/gdm directory (if it's unclear why that directory matters, see https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00421.html for a quick overview). > Nevertheless, I've been reading the patches and I have a couple of > comments about them: > > - The patch for libdazzle only changes the xorg-server, as it already >is at version 3.33.90 in master. It still makes sense as a patch, >but the title indicates a version downgrade. > Good catch! I'd correct this commit message, but I don't know what the rules are for rewriting commit history on Guix WIP branches. For now I'll note your comment and leave the message alone. > - The patch for gedit contains a reference to libgd, wouldn't it be >clearer for the reader/updater to have it defined in a let over the >package definition and use the name in native-inputs? > I'm not sure. I don't know if there is an explicit convention for packaging software that is distributed like this, and the examples of this in the code base (that I've seen, at least) define the third-party library the way I've done it here. I'm open to change on this point though. > - Is there any reason to not patch-out the gtk-icon-update-cache >invocations? If I understand it correctly, this is performed at >profile level, so makes no sense creating a cache at package level, >isn't it? The patches for quadrapassel, gnome-klotski, ghex, >gnome-sudoku, gnome-mines, five-or-more and gedit contain references >to it. Maybe creating a package like xorg-server-for-tests >(perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would >help in the long term. > I don't think such a reason exists. I could add changes that substitute calls to "gtk-icon-update-cache" with "true" for these packages, but I agree that a better solution may be possible. Perhaps not a package; maybe a new 'patch-gtk-icon-update-cache' phase in the relevant build systems? > As a final comment, the gnome release cycle and the amount of packages > involved is quite big, so again, thank you. > > Happy hacking! > Miguel Thanks Miguel! This comment and review means a lot! Kei
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > Update: Please check out the new wip-gnome-updates branch of the Guix > git repository for continued updates. The contents of the notabug.org > link given above will be changed to a notice that says to do this. Thank you very much for this huge effort. I've been playing with the branch and I have a working system, both X11 with GDM and Wayland with SDDM (I haven't tried hard enough to set up gdm with wayland as only a change to gdm-configuration doesn't seem to have any effect) and your branch works great on my machine, do you still have the issue during boot? I haven't found any (new) problem on the applications I've tested (x86_64, normal use with almost all of the gnome applications, not the games though.) Nevertheless, I've been reading the patches and I have a couple of comments about them: - The patch for libdazzle only changes the xorg-server, as it already is at version 3.33.90 in master. It still makes sense as a patch, but the title indicates a version downgrade. - The patch for gedit contains a reference to libgd, wouldn't it be clearer for the reader/updater to have it defined in a let over the package definition and use the name in native-inputs? - Is there any reason to not patch-out the gtk-icon-update-cache invocations? If I understand it correctly, this is performed at profile level, so makes no sense creating a cache at package level, isn't it? The patches for quadrapassel, gnome-klotski, ghex, gnome-sudoku, gnome-mines, five-or-more and gedit contain references to it. Maybe creating a package like xorg-server-for-tests (perhaps 'gtk-bin-for-build'?) linked to "true" from coreutils would help in the long term. As a final comment, the gnome release cycle and the amount of packages involved is quite big, so again, thank you. Happy hacking! Miguel
Re: 'core-updates' Q4 2019
Kei Kebreau writes: > Timothy Sample writes: > >> Hi Kei, >> >> Kei Kebreau writes: >> >>> Anyone want to see the 54 patches and possibly help me root around for >>> the issue? >> >> I would love to take a look at it! I’ve been a little tied up, but I >> should have some time tomorrow or the next day. I think it would be >> easiest to push it to some world-readable Git repository rather than >> post all 54 patches here, but I can work with whatever suits you. >> >> >> -- Tim > > I've pushed my changes to the following repository for anyone who wants > to take a look: > > https://notabug.org/kei/guix-gnome-updates Update: Please check out the new wip-gnome-updates branch of the Guix git repository for continued updates. The contents of the notabug.org link given above will be changed to a notice that says to do this. Thanks, Kei signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Hi Marius, Marius Bakke writes: > LGTM. It needs a corresponding entry in doc/guix.texi though. Pushed with an update to the docs. Thanks for the suggestion and review! -- Tim
Re: 'core-updates' Q4 2019
"pelzflorian (Florian Pelz)" writes: > On Tue, Oct 22, 2019 at 11:07:06PM -0400, Timothy Sample wrote: >> There’s a “glib-or-gtk?” flag for the Meson build system. Setting it to >> “#t” in the “mutter” package makes GDM and GNOME work in a VM. > > Thank you for investigating, I suppose this fixes your issue. > webkitgtk failed again for me the same way, so I will not test and > just wait for substitutes. I am not interested in investigating my > error. > > Regards, > Florian With some of the changes mentioned in this email thread, I'm able to build and log in to GNOME desktop! I've force pushed (sorry!) the changes to my NotABug git repository today.
Re: 'core-updates' Q4 2019
Timothy Sample writes: > Hi Marius, > > Marius Bakke writes: > >> Timothy Sample writes: >> >>> [1] It’s not obvious, but if you edit the GDM configuration file >>> generation code in “gnu/services/xorg.scm”, you can enable debug output >>> for GDM. The debug output is usually extremely helpful! >> >> Could that be exposed as a toggle in the service configuration? > > Indeed! It’s been on my list for ages. Thanks for the nudge. ;) Cool! Glad to be of service. :-) > How about the attached patch? I can confirm that it works, but would > like a second opinion on the name, since it is annoying to change later. LGTM. It needs a corresponding entry in doc/guix.texi though. Thank you! signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Hi Marius, Marius Bakke writes: > Timothy Sample writes: > >> [1] It’s not obvious, but if you edit the GDM configuration file >> generation code in “gnu/services/xorg.scm”, you can enable debug output >> for GDM. The debug output is usually extremely helpful! > > Could that be exposed as a toggle in the service configuration? Indeed! It’s been on my list for ages. Thanks for the nudge. ;) How about the attached patch? I can confirm that it works, but would like a second opinion on the name, since it is annoying to change later. >From b3e577799c2dfabb2bed00b9f3715144155c2c43 Mon Sep 17 00:00:00 2001 From: Timothy Sample Date: Wed, 23 Oct 2019 21:57:52 -0400 Subject: [PATCH] services: gdm: Add 'debug?' configuration field. * gnu/services/xorg.scm ()[debug?]: New field. (gdm-configuration-file): Use it. --- gnu/services/xorg.scm | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm index 1d55e388a1..9c84f7413f 100644 --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -835,6 +835,7 @@ the GNOME desktop environment.") (allow-empty-passwords? gdm-configuration-allow-empty-passwords? (default #t)) (auto-login? gdm-configuration-auto-login? (default #f)) (dbus-daemon gdm-configuration-dbus-daemon (default dbus-daemon-wrapper)) + (debug? gdm-configuration-debug? (default #f)) (default-user gdm-configuration-default-user (default #f)) (gnome-shell-assets gdm-configuration-gnome-shell-assets (default (list adwaita-icon-theme font-cantarell))) @@ -866,7 +867,9 @@ the GNOME desktop environment.") "WaylandEnable=false\n" "\n" "[debug]\n" - "#Enable=true\n" + "Enable=" (if (gdm-configuration-debug? config) + "true" + "false") "\n" "\n" "[security]\n" "#DisallowTCP=true\n" -- 2.23.0 Thanks! -- Tim
Re: 'core-updates' Q4 2019
Timothy Sample writes: > [1] It’s not obvious, but if you edit the GDM configuration file > generation code in “gnu/services/xorg.scm”, you can enable debug output > for GDM. The debug output is usually extremely helpful! Could that be exposed as a toggle in the service configuration? signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
On Tue, Oct 22, 2019 at 11:07:06PM -0400, Timothy Sample wrote: > There’s a “glib-or-gtk?” flag for the Meson build system. Setting it to > “#t” in the “mutter” package makes GDM and GNOME work in a VM. Thank you for investigating, I suppose this fixes your issue. webkitgtk failed again for me the same way, so I will not test and just wait for substitutes. I am not interested in investigating my error. Regards, Florian
Re: 'core-updates' Q4 2019
Hi again, Timothy Sample writes: > I’ll report back if I have good luck with fsck and am able to do more > testing. :) I was able to build everything and start testing. To use “guix system vm” I had to disable tests in QEMU due to a failure. I did not investigate it. This turned up in the logs [1]: (.gnome-shell-real:317): GLib-GIO-ERROR **: 03:50:44.482: Settings schema 'org.gnome.mutter' is not installed. It was followed by a warning that “org.gnome.Shell.desktop” was killed. This is the same message mentioned in the comment explaining disabled tests in the “mutter” package. There’s a “glib-or-gtk?” flag for the Meson build system. Setting it to “#t” in the “mutter” package makes GDM and GNOME work in a VM. It compiles the schemas and wraps Mutter so that it knows where they are. It does nothing for the tests, though. However, from the log of an older Mutter build [2], it looks like the tests were not being run correctly under Autotools anyway (it looks like not a single test is actually run). Hope that helps! -- Tim [1] It’s not obvious, but if you edit the GDM configuration file generation code in “gnu/services/xorg.scm”, you can enable debug output for GDM. The debug output is usually extremely helpful! [2] https://ci.guix.gnu.org/log/q0gkbynj35qp522bi8sf98kzwrsyy037-mutter-3.30.2
Re: 'core-updates' Q4 2019
Hi Kei and Florian, "pelzflorian (Florian Pelz)" writes: > On Sat, Oct 19, 2019 at 11:29:33PM -0400, Kei Kebreau wrote: >> I've pushed my changes to the following repository for anyone who wants >> to take a look: >> >> https://notabug.org/kei/guix-gnome-updates > > I tried reproducing your failure but webkitgtk failed to build. > > [...] > > I will try again later hoping it is non-deterministic. I was able to to build WebKitGTK, but ran into trouble later. The trouble seems to be file system corruption on my system, so I will fix that tonight, but I may not get a chance to test this promptly. I’ll report back if I have good luck with fsck and am able to do more testing. :) -- Tim
Re: 'core-updates' Q4 2019
On Sat, Oct 19, 2019 at 11:29:33PM -0400, Kei Kebreau wrote: > I've pushed my changes to the following repository for anyone who wants > to take a look: > > https://notabug.org/kei/guix-gnome-updates I tried reproducing your failure but webkitgtk failed to build. make[2]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build' [ 98%] Built target gtkdoc make -f Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/build.make Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/depend make[2]: Entering directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build' cd /tmp/guix-build-webkitgtk-2.26.1.drv-0/build && /gnu/store/iz9500ssxcqlyr74hg1jq10ycrh42yq1-cmake-minimal-3.15.1/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/guix-build-webkitgtk-2.26.1.drv-0/webkitgtk-2.26.1 /tmp/guix-build-webkitgtk-2.26.1.drv-0/webkitgtk-2.26.1/Source/WebKit /tmp/guix-build-webkitgtk-2.26.1.drv-0/build /tmp/guix-build-webkitgtk-2.26.1.drv-0/build/Source/WebKit /tmp/guix-build-webkitgtk-2.26.1.drv-0/build/Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/DependInfo.cmake --color= Scanning dependencies of target WebKit2WebExtension-4-gir make[2]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build' make -f Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/build.make Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/build make[2]: Entering directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build' make[2]: *** No rule to make target 'JavaScriptCore-4.0.gir', needed by 'WebKit2-4.0.gir'. Stop. make[2]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build' make[1]: *** [CMakeFiles/Makefile2:1403: Source/WebKit/CMakeFiles/WebKit2WebExtension-4-gir.dir/all] Error 2 make[1]: Leaving directory '/tmp/guix-build-webkitgtk-2.26.1.drv-0/build' make: *** [Makefile:155: all] Error 2 command "make" "-j" "1" failed with status 2 I will try again later hoping it is non-deterministic. Regards, Florian
Re: 'core-updates' Q4 2019
Timothy Sample writes: > Hi Kei, > > Kei Kebreau writes: > >> Anyone want to see the 54 patches and possibly help me root around for >> the issue? > > I would love to take a look at it! I’ve been a little tied up, but I > should have some time tomorrow or the next day. I think it would be > easiest to push it to some world-readable Git repository rather than > post all 54 patches here, but I can work with whatever suits you. > > > -- Tim I've pushed my changes to the following repository for anyone who wants to take a look: https://notabug.org/kei/guix-gnome-updates signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Hi Kei, Kei Kebreau writes: > Anyone want to see the 54 patches and possibly help me root around for > the issue? I would love to take a look at it! I’ve been a little tied up, but I should have some time tomorrow or the next day. I think it would be easiest to push it to some world-readable Git repository rather than post all 54 patches here, but I can work with whatever suits you. -- Tim
Re: 'core-updates' Q4 2019
Kei Kebreau writes: > Ricardo Wurmus writes: > >> Kei Kebreau writes: >> >>> I have news! The good part is that I got 54 packages to build on top of >>> master. The bad part is that when I try to use the resulting packages as >>> my system configuration, my computer gets stuck in tty1, and attempting >>> to switch to Xorg on tty7 leaves my screen frozen though the system is >>> still responsive. >> >> Have you tried removing /var/lib/gdm and the contents of your user >> account’s .local/share/gnome* directories? > > I just did, and now tty7 simply shows a copy of tty1 rather than > irreversibly freezing my screen. What files are in /var/lib/gdm and > $HOME/.local/share/gnome that would have such an effect? ~/.local/share/gnome-shell/application_state is a common problem. It contains some state that different versions of GNOME seem to be choking on. There are some other files like ~/.cache/gnome* that might affect GNOME and prevent starting after upgrades. It’s frustrating. /var/lib/gdm is the home directory of the gdm account, and it too can accumulate state. In my opinion /var/lib/gdm should always be recreated on every boot. -- Ricardo
Re: 'core-updates' Q4 2019
Ricardo Wurmus writes: > Kei Kebreau writes: > >> I have news! The good part is that I got 54 packages to build on top of >> master. The bad part is that when I try to use the resulting packages as >> my system configuration, my computer gets stuck in tty1, and attempting >> to switch to Xorg on tty7 leaves my screen frozen though the system is >> still responsive. > > Have you tried removing /var/lib/gdm and the contents of your user > account’s .local/share/gnome* directories? I just did, and now tty7 simply shows a copy of tty1 rather than irreversibly freezing my screen. What files are in /var/lib/gdm and $HOME/.local/share/gnome that would have such an effect? signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Kei Kebreau writes: > I have news! The good part is that I got 54 packages to build on top of > master. The bad part is that when I try to use the resulting packages as > my system configuration, my computer gets stuck in tty1, and attempting > to switch to Xorg on tty7 leaves my screen frozen though the system is > still responsive. Have you tried removing /var/lib/gdm and the contents of your user account’s .local/share/gnome* directories? -- Ricardo
Re: 'core-updates' Q4 2019
Marius Bakke writes: > Kei Kebreau writes: > >> Ludovic Courtès writes: >> >>> Hello Kei, >>> >>> Kei Kebreau skribis: >>> I have the GNOME 3.32 branch! I'm building it on top of the new core-updates as you read this message. If everything still builds, I'll immediately send my changes to the guix-patches mailing list for review and testing. >>> >>> Shouldn’t you instead base it on ‘master’ or ‘staging’? >>> >>> That may allow us to merge it more quickly, especially if these are only >>> GNOME-related changes. >>> >>> Thanks for working on it! >>> >>> Ludo’. >> >> Hi Ludovic, >> >> Taken individually, most changes on the GNOME 3.32 branch could be >> pushed to master without too much trouble. The only issues are big >> changes like >> upgrading Vala. The following changes would cause a large number of >> rebuilds: >> >> At least 300 rebuilds: python-pygobject, gtk+ >> >> At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized, >> python-check-manifest, python-anytree >> >> I'll minimize the changes, isolate what I can, and submit the results >> for review as time allows! > > Thanks! Sounds like something we can handle in a 'staging' cycle. > > By the way, GNOME 3.34 is out, and 3.36 is slated for March. So I think > we will finally be able to catch up with GNOME again soon... > > (let's focus on 3.32 first though ;-)) I have news! The good part is that I got 54 packages to build on top of master. The bad part is that when I try to use the resulting packages as my system configuration, my computer gets stuck in tty1, and attempting to switch to Xorg on tty7 leaves my screen frozen though the system is still responsive. Anyone want to see the 54 patches and possibly help me root around for the issue? signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Kei Kebreau writes: > Ludovic Courtès writes: > >> Hello Kei, >> >> Kei Kebreau skribis: >> >>> I have the GNOME 3.32 branch! I'm building it on top of the new >>> core-updates as you read this message. If everything still builds, I'll >>> immediately send my changes to the guix-patches mailing list for review >>> and testing. >> >> Shouldn’t you instead base it on ‘master’ or ‘staging’? >> >> That may allow us to merge it more quickly, especially if these are only >> GNOME-related changes. >> >> Thanks for working on it! >> >> Ludo’. > > Hi Ludovic, > > Taken individually, most changes on the GNOME 3.32 branch could be > pushed to master without too much trouble. The only issues are big changes > like > upgrading Vala. The following changes would cause a large number of > rebuilds: > > At least 300 rebuilds: python-pygobject, gtk+ > > At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized, > python-check-manifest, python-anytree > > I'll minimize the changes, isolate what I can, and submit the results > for review as time allows! Thanks! Sounds like something we can handle in a 'staging' cycle. By the way, GNOME 3.34 is out, and 3.36 is slated for March. So I think we will finally be able to catch up with GNOME again soon... (let's focus on 3.32 first though ;-)) signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Ludovic Courtès writes: > Hello Kei, > > Kei Kebreau skribis: > >> I have the GNOME 3.32 branch! I'm building it on top of the new >> core-updates as you read this message. If everything still builds, I'll >> immediately send my changes to the guix-patches mailing list for review >> and testing. > > Shouldn’t you instead base it on ‘master’ or ‘staging’? > > That may allow us to merge it more quickly, especially if these are only > GNOME-related changes. > > Thanks for working on it! > > Ludo’. Hi Ludovic, Taken individually, most changes on the GNOME 3.32 branch could be pushed to master without too much trouble. The only issues are big changes like upgrading Vala. The following changes would cause a large number of rebuilds: At least 300 rebuilds: python-pygobject, gtk+ At least 1200 rebuilds: gtk-doc, vala, yelp-tools, python-parameterized, python-check-manifest, python-anytree I'll minimize the changes, isolate what I can, and submit the results for review as time allows! Thanks, Kei signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Hello Kei, Kei Kebreau skribis: > I have the GNOME 3.32 branch! I'm building it on top of the new > core-updates as you read this message. If everything still builds, I'll > immediately send my changes to the guix-patches mailing list for review > and testing. Shouldn’t you instead base it on ‘master’ or ‘staging’? That may allow us to merge it more quickly, especially if these are only GNOME-related changes. Thanks for working on it! Ludo’.
Re: 'core-updates' Q4 2019
Marius Bakke writes: > Guix, > > As you know, the "quarterly" core-updates rebuild took almost a full > year this previous cycle. There are already 35 commits on the > 'core-updates-next' branch, and I've heard rumors of a GNOME 3.32 branch > lurking somewhere. > > To prevent this work from rotting away, I propose that we start the > branch as early as next month. With luck, users will be able to > cross-compile Guix System for arbitrary toys come December ;-) > > Thoughts? Hi Marius, I have the GNOME 3.32 branch! I'm building it on top of the new core-updates as you read this message. If everything still builds, I'll immediately send my changes to the guix-patches mailing list for review and testing. Thanks, Kei signature.asc Description: PGP signature
Re: 'core-updates' Q4 2019
Hi, Svante Signell skribis: > On Thu, 2019-10-10 at 16:32 +0200, Ludovic Courtès wrote: >> Hi! >> >> Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to >> ‘core-updates’ if nobody’s done it yet. >> >> Let’s get the ball rolling! > > What's the status of the GNU/Hurd port with this core-updates release, > better or worse? It’s most likely unchanged. Thanks, Ludo’.
Re: 'core-updates' Q4 2019
On Thu, 2019-10-10 at 16:32 +0200, Ludovic Courtès wrote: > Hi! > > Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to > ‘core-updates’ if nobody’s done it yet. > > Let’s get the ball rolling! What's the status of the GNU/Hurd port with this core-updates release, better or worse?
Re: 'core-updates' Q4 2019
Hey Ludo, > Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to > ‘core-updates’ if nobody’s done it yet. Done! We have a new core-updates branch open. Mathieu
Re: 'core-updates' Q4 2019
Hi! Mathieu Othacehe skribis: >> To prevent this work from rotting away, I propose that we start the >> branch as early as next month. With luck, users will be able to >> cross-compile Guix System for arbitrary toys come December ;-) >> >> Thoughts? Let’s do that! > Seems like a good plan :) Mathieu, I guess you can go ahead and rename ‘core-updates-next’ to ‘core-updates’ if nobody’s done it yet. Let’s get the ball rolling! Ludo’.
Re: 'core-updates' Q4 2019
Hey Marius, > To prevent this work from rotting away, I propose that we start the > branch as early as next month. With luck, users will be able to > cross-compile Guix System for arbitrary toys come December ;-) > > Thoughts? Seems like a good plan :) Mathieu
