disable substitutes for grub config and bootloader installation script
rolling back the system shows it's trying to get substitutes for grub.cfg.drv and install-bootloader.scm.drv: ``` itsme@antelope ~> sudo guix system roll-back Password: substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0% substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% The following derivation will be built: /gnu/store/b90j6p6qpzvs5x884hhy9dc3zvv6jhcs-grub.cfg.drv building /gnu/store/b90j6p6qpzvs5x884hhy9dc3zvv6jhcs-grub.cfg.drv... substitute: updating substitutes from 'https://berlin.guixsd.org'... 100.0% substitute: updating substitutes from 'https://mirror.hydra.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% building /gnu/store/m7lcl11s38ks2hapm1j7s2z9szig3zhs-install-bootloader.scm.drv... switched from generation 46 to 45 ``` This is not needed, unless I am missing something?
Re: How can I set architecture/system-specific origin sources?
On Tue, Dec 31, 2019 at 03:00:50PM +0100, Pierre Neidhardt wrote: > Hi Mathieu! > > Thanks for the details, this makes much more sense now! :) > So how can I thunk the source field then? > There's computed-origin-method that's floating around a couple of package modules or you can look at something like ghc which has a different blessed binary per-architecture. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
Re: Packaging Jami progress
On Sat, 28 Dec 2019 10:40:09 +0100
Pierre Neidhardt wrote:
> P.S.: Have you managed to set up a public Git clone of Guix to share
> you patches?
>
Okay, good news: I finally have a public repo at
https://notabug.org/kromka_chleba/guix-jami/src/jami-wip
My changes are on the jami-wip branch. Would be nice if someone checked
the ffmpeg-jami package - I have there some conditionals adding
configure flags depending on the architecture and system, and don't know
if what I did is fine.
Something like this:
(if (string-contains (%current-system) "linux")
'("--enable-pic"
...
Bad news:
I still haven't got any response that would solve the bug present only
in our package:
https://git.jami.net/savoirfairelinux/ring-client-gnome/issues/1123
I have not much experience with debugging and reading backtraces, but
could it be there's something wrong with our glibc package?
Jan Wielkiewicz
Allow system configuration without a bootloader
Hello. I am very happy with manually setting up my boot programs. On UEFI systems I don’t use a standalone bootloader at all, because I think it is so unnecessary, and rely on Linux ‘EFI stub’ functionality. I don’t ever want any automatic scripts to intervene. For a couple of years I have used this: (bootloader (grub-configuration (target "/dev/null"))) It works, but produces an ugly error during configuration. I believe the field should actually be made optional.
Re: qtwenengine anybody?
Pierre Neidhardt writes: > I tested again on an Intel HD Graphics 620. > Everything works for me so far (navigating, smooth scrolling, rendering). > > I tested the following: > > - https://gnu.org > - https://ambrevar.xyz (has some CSS that may required hardware acceleration) > - https://github.com > - https://youtube.com: playing videos works flawlessly. > - https://get.webgl.org/: the webgl cube is spinning properly :) Thanks for testing this. one site that suffers with webkit I noticed is reddit I would add that to your test sites. I think I found the issues nouaveau in that the those drivers currently do not support multi threaded OpenGL which qtwebengine uses. Oddly though I do not need to set QT_XCB_FORCE_SOFTWARE_OPENGL in my monolithic QT package with qtwebengine. But that package is using the latest QT 5.14.0 and it's possible it's doing some auto detection and switching software acceleration on nouveau anyways. I'll have to investigate this further down the road. Mike
drop net-tools from %base-packages?
Hello!
While preparing a new release of GNU Inetutils, I read the following
comment in ./gnu/system.scm
net-tools; XXX: remove when Inetutils suffices
and looked into what possible tools Guix would want from inetutils that
aren't available already.
I'm not sure how to best find out what tools are actually used by Guix,
but on my system the following tools appear to be installed:
root@hamster ~# ls -la /run/current-system/profile/*bin/|grep net-tool|awk '{
print $9 }'
netstat
route
arp
ipmaddr
iptunnel
mii-tool
nameif
plipconfig
rarp
slattach
root@hamster ~#
Is anything else from net-tools used?
Most of the tools are esoteric. I suspect the more well-known tools are
'route', 'netstat', 'arp' and 'rarp'.
My Debian buster laptop has none of the tools above installed. In fact,
the net-tools package is not even installed by default. It seems all
uses have transitioned over to the modern 'iproute' suite.
Thus, I suggest Guix drop net-tools from its required tools. People who
are nostalgic about the tools can install them separately, just like on
Debian.
I wouldn't know how to comprehensible test the patch below, but I'm sure
people will notice if there are problems if it is applied. :-)
/Simon
From 3ac6e4c9853a0cbc6fb42a2d263bb03bb9583c34 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Wed, 1 Jan 2020 18:05:47 +0100
Subject: [PATCH] system: Drop net-tools from %BASE-PACKAGES (replaced by
iproute2).
* gnu/system.scm (%base-packages): Remove net-tools.
---
gnu/system.scm | 1 -
1 file changed, 1 deletion(-)
diff --git a/gnu/system.scm b/gnu/system.scm
index abdbb081e6..fbc72ada3d 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -574,7 +574,6 @@ of PROVENANCE-SERVICE-TYPE to its services."
iw wireless-tools
iproute
- net-tools; XXX: remove when Inetutils suffices
man-db
info-reader ;the standalone Info reader (no Perl)
--
2.20.1
signature.asc
Description: PGP signature
Re: qtwenengine anybody?
Pierre Neidhardt writes: > Mike, have you tried building the package against ungoogled-chromium? > > Either way, I vote for including this package into Guix, it seems mature > enough. > We can open an issue to replace the bundled chromium with > ungoogled-chromium if need be. Sorry for the long delay on responding to this topic. I've been pretty busy. I have done a cursory look at upstreamn ungoogled-chrome and then started to reason what might need to be done to integrate this into qtwebengine. My conclusion is this is going to be way more work then the benefits. And once this was achieved it still needs to be maintained. Keep in mind QT already has a patch re base process with changes that might conflict with ungoogled-chrome. I think the better approach is to try and fix the in tree dependencies upstream. and let it trick down to the guix declaration. In a more ideal world I think QT and the ungogogled project should be working together since there goals are much on par. Though maybe given enough time and resources I could find an more ideal way to solve this. Right now though I don't think I have the time or resources. Mike
Re: Allow system configuration without a bootloader
Le 1 janvier 2020 10:31:08 GMT-05:00, kanic...@yandex.ru a écrit : >Hello. > >I am very happy with manually setting up my boot programs. On UEFI >systems I don’t use a standalone bootloader at all, because I think it >is so unnecessary, and rely on Linux ‘EFI stub’ functionality. I don’t >ever want any automatic scripts to intervene. > >For a couple of years I have used this: >(bootloader (grub-configuration (target "/dev/null"))) >It works, but produces an ugly error during configuration. > >I believe the field should actually be made optional. Have tried to use --no-bootloader when reconfiguring?
Re: Allow system configuration without a bootloader
Yes, AFAIR it only works with ‘init’ and has no effect at all with ‘reconfigure’. 02.01.2020, 00:12, "Julien Lepiller" : > Le 1 janvier 2020 10:31:08 GMT-05:00, kanic...@yandex.ru a écrit : >> Hello. >> >> I am very happy with manually setting up my boot programs. On UEFI >> systems I don’t use a standalone bootloader at all, because I think it >> is so unnecessary, and rely on Linux ‘EFI stub’ functionality. I don’t >> ever want any automatic scripts to intervene. >> >> For a couple of years I have used this: >> (bootloader (grub-configuration (target "/dev/null"))) >> It works, but produces an ugly error during configuration. >> >> I believe the field should actually be made optional. > > Have tried to use --no-bootloader when reconfiguring?
Re: qtwenengine anybody?
Pierre Neidhardt writes: > Let me know if there are more changes you'd like to include to your > patch. > If no one objects, I'll merge it within a week. > > Cheers! I think the package is looking pretty good now. I sent some changes requested by Hartmut today so we might need to wait on any more changes he might have. Moving forward I'll start a discussion upstream about how to go about improving the in tree dependency issue. I'm going to take a further look at the nouveau issue both on guix system and I'd like to do more testing of foreign distro. Mike
Re: qtwenengine anybody?
Pierre Neidhardt writes: > mike.ros...@gmail.com writes: > >> My conclusion is this is going to be way more work then the >> benefits. And once this was achieved it still needs to be >> maintained. Keep in mind QT already has a patch re base process with >> changes that might conflict with ungoogled-chrome. I think the better >> approach is to try and fix the in tree dependencies upstream. and let it >> trick down to the guix declaration. >> >> In a more ideal world I think QT and the ungogogled project should be >> working together since there goals are much on par. > > Totally, I think you are making a lot of sense here. > Since you are the most knowledgeable on the topic, would you mind > reporting this to upstream and include the links in your patch? Thanks! > > Let me know if there are more changes you'd like to include to your > patch. > If no one objects, I'll merge it within a week. I’m sorry for making this harder, but I would very much like to first see evidence that the problematic features of Chromium have in fact been addressed by QT upstream. Does the code include DRM support, for example? Does it phone home? Can we see the patches that upstream applied to the Chromium sources? -- Ricardo
