Re: Status of Gnome upgrade?
Hi, Yay! We already have Gnome 3.32 on master! Unfortunately, I've found one regression on XFCE/LXDE, as libwnck-2 does not build anymore. I've open a bug report[1] with the proposed patch, sorry I didn't noticed it sooner, but I haven't run a full reconfiguration on my old machine with the branch integrated until it has been in master. Best regards, Miguel [1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=38547
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: > 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
Granularity of grub-install (was Re: Reproducibility of grub-install)
Hi,
First of all, thank you for your comments. My answers are inline,
although the bad subject was a main issue of misunderstanding. I
changed it, as I think it reflects better my current idea. I'm sorry
for the confusion it certainly caused.
Wed, 23 Oct 2019 11:09:07 +0200
Daniel Kiper wrote:
> On Mon, Oct 21, 2019 at 04:30:21PM +0200, Miguel Arruga Vivas wrote:
> > Hi, everybody!
> >
> > After taking a deeper look into our (guix's) grub installation
> > procedure, I have the thought that it could be a neat idea to make
> > the boot directory an actual derivation instead something of the
> > global status.
>
> I do not understand what you mean by "make the boot directory an
> actual derivation instead something of the global status". Could you
> elaborate more about that?
Currently, the /boot directory is partially a system-wide directory,
even though most of its contents are direct copies of the ones from
grub's installation prefix: /usr/... in most distributions including
BSD world, /{nix,gnu}/store/-grub-2.04 in Nix/Guix. Most of its
contents don't depend at all on the actual machine and that can be
shared between machine-dependent boot-sector/efi-variables
"activations". These contents include all grub modules and message
object files. On the other hand, the task of the platform-specific
installation cannot be "shared", as it must be performed directly "on
the metal". And there is a third task between these two: the generation
of the raw image, that depends on the hardware configuration through
the provided configuration file *and* the binary installation.
> (...)
> I am not sure why grub.cfg have to be reproducible. OK, to some extent
> it has but...
Guix doesn't generate grub.cfg through grub-mkconfig, as each kernel is
also associated with the configuration for the init system too--GNU
Shepherd in Guix--, and one kernel may boot up different systems, so it
is generated with Guile scripts. My understanding is that grub-mkconfig
is a portable tool, not only intended for this case, whose output is
system dependant. I mixed up concepts here, sorry.
> >
> > - /boot/grub/grubenv: IIUC, this file must be writable by grub.
> > This should not be on the store, and not sharing the path may be the
> > main problem right now to implement this.
>
> I do not understand this.
>
> > AFAIK, the grubenv problem requires a modification of the grub code
> > if we try to use a different path for this kind-of-modifiable file,
> > so this would require modify grub to being able to lookup for that
> > file somewhere else. This way the global state can be made
> > explicit.
>
> What do you mean by "This way the global state can be made explicit."?
Sorry again. We do not use load_env nor save_env in our
configuration. I misunderstood the creation in grub-install.c as a
hidden requirement for it, but I'd just had to read the manual. That
global state already is explicit enough. I think now that its creation
should be optional, even though it's created by default as
grub-mkconfig makes use of it. Should I send a patch for it?
> > The image installation into the device is a separate issue from the
> > binaries installation, that could be separated into two separate
> > binaries, or two steps/flags for grub-install, one for binaries
> > installation into ${boot-directory}/grub and the other one for
> > load.cfg generation and core/boot.img installation.
>
> Why do you need to separate this thing into two steps?
I'd like being able to have different grub /boot-like folders, maybe
through unions in the file system (as hard links) of the shared
contents and the physical system dependencies, and activate them
selectively without writing into them any more. This is intended for
Guix's store[1], but other use cases are possible, in order to roll-back
to a previous generation of the system by only writing
core.img/grub.efi/etc. into platform-dependant locations.
As I said before, I see them now as three steps. The middle one is
already there with grub-mkimage. The bios-like installation can be
performed with grub-setup, but EFI systems need grub-install to copy
the image and activate it, the reason behind grub-setup deprecation if I
understand the code correctly. And the copy of the correct files to
the boot-directory needs no modification at all of grub-install.
> > To grub-devel: I'd be able to send patches for the latter if you
> > think
>
> Patches are always welcome...
I'll send just to grub-devel following this mail a patch for a minor
problem I've found reading the code.
The code for an --only-platform-installation flag (the name I'm using
right now) needs more work but I'll send it as soon as I have
something I've tested on x86 BIOS and x86_64 EFI. From my
current understanding it would replace completely grub-setup, wouldn't
it?
Happy hacking!
Miguel
[1] https://guix.gnu.org/manual/en/html_node/Features.html
Reproducible grub-install
Hi, everybody!
After taking a deeper look into our (guix's) grub installation
procedure, I have the thought that it could be a neat idea to make the
boot directory an actual derivation instead something of the global
status.
From what I currently understand:
- boot.img/core.img and load.cfg: The written images must be replaced
on each installation. This is one task performed by grub-install.
- /boot/grub/*: The contents of these folders should be reproducible,
such as the modules or the localization binaries, as currently
grub.cfg is. This is the other task performed by grub-install.
- /boot/grub/grubenv: IIUC, this file must be writable by grub. This
should not be on the store, and not sharing the path may be the
main problem right now to implement this.
AFAIK, the grubenv problem requires a modification of the grub code if
we try to use a different path for this kind-of-modifiable file, so this
would require modify grub to being able to lookup for that file
somewhere else. This way the global state can be made explicit.
The image installation into the device is a separate issue from the
binaries installation, that could be separated into two separate
binaries, or two steps/flags for grub-install, one for binaries
installation into ${boot-directory}/grub and the other one for load.cfg
generation and core/boot.img installation.
To everyone: Are you aware of any other way to achieve this? What do
you think?
To grub-devel: I'd be able to send patches for the latter if you think
it is a good idea without help, but I guess that the first kind of
modification would need some and deeper study of grub code.
To guix-devel: Even though the procedure I have in mind needs
changes in grub, there are alternative ways to achieve this with the
current tools, as copying the files and using the installation as an
"implicit" guix-challenge, but they are not as neat an clean as the
split between reproducible binaries installation and global state,
which includes the disk preparation for the load of the bootloader.
Happy hacking to all!
Miguel
Re: [bug#35394] [PATCH 0/3] Bootloader localization
Hi Ludo’, El Mon, 29 Apr 2019 09:56:25 +0200 Ludovic Courtès escribió: > Hi Miguel, > > Thanks a lot for this work. I've been quite silent about this because I wanted to solve the issue with .mo files in a better way, but my current understanding is that the best way to go with that is to make grub installation (store-)reproducible and removing /boot altogether, so I'll open a different thread on the mailing list about that. For the moment, the patches following this mail rely on the installation of /boot/grub/locale, usually generated by grub-install. The generated grub.cfg scriptlet enables the use case for /boot in a different partition found in many other distributions (which breaks the boot when /gnu/store is encrypted in a different partition, I'm going to fill a bug for that too). I've tested them on the following machine configurations, on top of commit 5f760515c8: - grub-efi on x86_64-gnu-linux: * Encrypted partition for the whole disk. * Separate "/boot" (ext4) and "/" (ext4 and btrfs) partitions. - grub-pc on x86_64-gnu-linux: * Same as grub-efi, plus * Encrypted and different "/boot" and "/" partitions, typing manually in the console "cryptomount (hdX,msdosX)" with the "/" partition to allow grub loading the kernel image. > FWIW, I’m holding off review and integration after 1.0, but I’m happy > if someone else reviews :-), I'm CCing the list to bring some attention onto it, I think it's on-topic enough to worth a try. The hardest part for review is the new test case, because I wanted to be 100% sure I didn't break anything. As you can see, the tested code didn't need almost any change, although I've made some changes on the test case from the last set of patches. > and I’ll be really happy to see it in master once 1.0 is out. I wish we'll see it in master soon. Best regards, Miguel
