bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

Hi Calvin, Calvin Heim writes: > On Thu, 2019-08-15 at 15:15 -0400, Mark H Weaver wrote: >> I did some looking around for any recently updated tutorials on how to >> install GNU/Linux on a MacBook 1,1, and the only recent success story I >> found involved installing the rE

bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

Mark H Weaver writes: > Hi Calvin, > > Calvin Heim writes: > >> On Thu, 2019-08-15 at 15:15 -0400, Mark H Weaver wrote: >>> I did some looking around for any recently updated tutorials on how to >>> install GNU/Linux on a MacBook 1,1, and the only recen

bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

Calvin Heim writes: >> Ubuntu 16.04 uses linux-4.4.  We have linux-libre-4.4 (LTS) in Guix, but >> our 1.0.1 installer images are based on linux-libre-5.1. >> >> It might be worth using another machine to build a Guix installer image >> that uses linux-libre-4.4, and trying that.   > Is it impor

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Marius, Earlier I wrote: > Marius Bakke writes: >> I can look into adjusting the bash fix for 5.0, and updating the >> bootstrap binary URLs and hashes. > > I've attached preliminary untested patches for these. I'm testing them > now. I pushed those two commits to 'core-updates-next', and a

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Marius Bakke skribis: > >> Mark H Weaver writes: > > [...] > >>> I think what needs to be done is the following: >>> >>> (1) commit 78ced7975b0665e810834391d826c9f0ef7277e1 on 'wip-binaries' &

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Earlier, I wrote: > I pushed those two commits to 'core-updates-next', and am currently > building out that branch on my X200. So far I've successfully built the > core packages and 'hello', and am now continuing on to build the rest of > my Guix system. FYI, on 'core-updates-next', I've built t

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès wrote: > It’s currently being evaluated: > > https://ci.guix.gnu.org/jobset/core-updates-next Thanks, although I guess all of the builds will fail, unless someone manually added the new bootstrap tarballs to Berlin's store, or uploaded them to one of the URLs in %bo

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès wrote: >>> It’s currently being evaluated: >>> >>> https://ci.guix.gnu.org/jobset/core-updates-next >> >> Thanks, although I guess all of the builds

bug#37123: gnome-shell: LD_LIBRARY_PATH setting propagates to entire session

Since commit 2b0c755d195c79bfc95cdbe802e1e2dea1adb7a2 in August 2018, our 'gnome-shell' executable has been wrapped by a script that sets LD_LIBRARY_PATH. One consequence of this, which I just noticed, is that if 'gnome-shell' is based on 'core-updates' (or in my case, 'core-updates-next'), many p

bug#37135: GNOME+Wayland: mouse pointer disappears over gnome-shell elements

For the last few months, I've run into a new problem in gnome-shell that only happens when running under Wayland: the mouse pointer disappears sporadically, but only when the pointer is hovered over GUI elements owned by gnome-shell. In particular, it happens when the pointer is over the gnome-she

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

FYI, I've fully switched my entire GNOME-based Guix system to 'core-updates-next' now. Of the packages that I use, only three failed to build: diffoscope, openimageio (needed by blender), and simple-scan. Mark

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> You can reproduce them with the following command from a git checkout at >> commit 9e6256ba0f32ab12d61c914a3fed879dac881762, which is the tip of the >> 'wip-binaries' branch, based on recent &#x

bug#36708: Serving an up-to-date https://guix.gnu.org/packages

Ludovic Courtès writes: > Ludovic Courtès skribis: > >>The package list at is made from the >>current ‘guix’ package, not from the latest ‘master’. We should >>work to build it dynamically with something like hpcguix-web, or to >>generate it from

bug#37021: GuixSD 1.01-i686 install DVD boot failure on Macbook1, 1: failed to resolve partition

Hi Danny, Danny Milosavljevic writes: > On Thu, 22 Aug 2019 16:31:19 +0200 > Danny Milosavljevic wrote: > >> could you try booting >> https://drive.google.com/open?id=15YTPS2jt1l3VMyE4LTbMCoy7DnEu7etv from DVD >> and later from USB Flash drive? > > Sorry, I didn't mean that one. Wrong archit

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

rap-mes): Update the download URL and hash. commit 82eaac49ac983f28768d6623d802f41cbd7f779b Author: Mark H Weaver Date: Thu Aug 15 16:44:36 2019 -0400 gnu: bash: Unconditionally configure PGRP_PIPE for *-linux systems. * gnu/packages/patches/bash-linux-pgrp-pipe.patch: New file. * gnu/local.mk (dist_p

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès wrote: >>> I don’t think we explicitly discussed it, but my assumption is that >>> we’re delaying merging of ‘core-updates’ into ‘master’ until >>> ‘core-updates-next’ be

bug#36855: guix system switch-generation doesn't

Hi, Ludovic Courtès writes: > Jakob, now that we generate scripts for the effectful bits of system > reconfiguration (one of these bits being service upgrades), couldn’t we > take it one step further and store those scripts in the “system” > derivation so we can run them eventually, notably upon

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Ludovic Courtès wrote: >>> Also, what’s the next step for ‘wip-binaries’? >> >> Good question! First, I think we should tag it with a name that >> indicates that it was used t

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès wrote: > Mark H Weaver skribis: > >> Hmm, good point. Perhaps we should postpone the Bash fix until the next >> core-updates cycle. [...] > > Your call: if you think this Bash fix can be delayed without causing > problems, then please r

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Ludovic Courtès writes: > Mark H Weaver skribis: > >> I could simply push the revised commits to 'core-updates' directly. > > That sounds good me, please do! Done. I'm closing this bug now, but feel free to reopen if there are remaining issues that I've overlooked. Thanks! Mark

bug#36855: guix system switch-generation doesn't

Hello again, Mark H Weaver writes: > Ludovic Courtès writes: > >> Jakob, now that we generate scripts for the effectful bits of system >> reconfiguration (one of these bits being service upgrades), couldn’t we >> take it one step further and store those scripts in the “

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, I pushed the revised commits to 'core-updates', but something seems to have gone wrong with the new evaluation on Berlin: https://ci.guix.gnu.org/jobset/core-updates-core-updates https://ci.guix.gnu.org/eval/7008 The first URL above shows a big "X" in the "Success" column for eva

bug#36855: guix system switch-generation doesn't

Hi Jakob, zerodaysford...@sdf.lonestar.org (Jakob L. Kreuze) writes: > Thanks for the input; I wasn't aware that the activation process was > taking so long for some people. One of Ludovic's suggestions was to > create a single derivation, rather than three, to speed up system > activation. I'll

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic and Ricardo, Ludovic Courtès writes: > Mark H Weaver skribis: > >> I pushed the revised commits to 'core-updates', but something seems to >> have gone wrong with the new evaluation on Berlin: >> >> https://ci.guix.gnu.org/job

bug#36747: Official MesCC bootstrap binaries differ from my locally built ones

Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >> Thanks. The next evaluation got further, but eventually failed. Again, >> there seems no way to get any details on what went wrong from the web >> interface: >> >> https://ci.guix.gnu.

bug#37246: Cuirass builds spuriously fail with truncated build logs

Cuirass builds sometimes spuriously fail with truncated build logs. Recent examples: https://ci.guix.gnu.org/build/1643344/details https://ci.guix.gnu.org/build/1632149/details Previously, we've noticed that this problem happens quite frequently with armhf builds offloaded to hydra-slave{1,2,

bug#37290: Guix System: Hibernation

work, I recommend that the first time you test this, be prepared for the possibility that resume will fail. So far I've only tested it with simple partitions, without encryption or RAID. It may be that we should add a dedicated 'resume-device' field to the 'operating-system'.

bug#32835: Icecat is missing fonts (on foreign distro)

Here's a very hacky workaround that worked for me, while testing a preliminary IceCat 68.2 build on a Debian system: make ~/.config/fontconfig be a symlink to /etc/fonts. Mark

bug#37940: endless "try upgrading both" cycles

Hi Arne, Arne Babenhauserheide writes: > When installing a package while some packages are not up to date, guix > can require adding more and more packages to guix install: [...] > guix install: error: profile contains conflicting entries for util-linux > guix install: error: first entry: util-

bug#37996: guile-ssh non-deterministic test failure

FYI, guile-ssh-0.11.3 failed one of its tests the first time I tried to build it today on my X200. The second attempt succeeded. Mark --8<---cut here---start->8--- Guile-SSH 0.11.3: tests/test-suite.log ==

bug#38045: Video Rendering Issues on IceCat

Hi, Raghav Gururajan wrote: > It was just weird that this is issue started after the upgrade. > Before that, all was fine. I have a hypothesis of what might have happened here. Since the upgrade to version 68, the IceCat package in GNU Guix is no longer using our system ffmpeg. Although ffmpeg

bug#38045: Video Rendering Issues on IceCat

Earlier, I wrote: > I have a hypothesis of what might have happened here. > > Since the upgrade to version 68, the IceCat package in GNU Guix is no > longer using our system ffmpeg. Sorry, I forgot to mention why I think this might be relevant. The reason is because upstream Firefox adopts the a

bug#38087: IceCat: HTTPS Every-where becomes HTTPS No-where :-P

Hi Raghav, > P.S. Mark, please don't feel pressured. I am just sumbmitting the issue > for awareness and tracking. :-) I appreciate these reports, thank you! > I was using 'HTTPS Everywhere' add-on, with enabled https-only rule. > > After v68 upgrade, the icon disappears from the tool bar and h

bug#38087: IceCat: HTTPS Every-where becomes HTTPS No-where :-P

Hi Raghav, Raghav Gururajan wrote: > Would it be better to reverse the version just before 68? > > I remember you mentioned something about security fix in the 68 > release; may be for now, it would be better to use the older version > with only the security patch from v68? It's not feasible for

bug#38190: Icecat 68.2.0-guix0-preview3 does not play H264/MP4

close 38190 retitle 38045 IceCat-68.x lacks support for some codecs including H264/MP4 thanks Hi Jelle, Jelle Licht writes: > On latest master, with the following icecat package: > icecat 68.2.0-guix0-preview3 out > /gnu/store/zqzhirykpqhay8n768aqqg4xplrmpfwz-icecat-68.2.0-guix0-p

bug#38203: "make as-derivation" no longer uses the checked-out branch

First, some relevant background: I use 'guix' in an unusual way. I *never* run "guix pull". My ~/.config/guix directories are empty for all accounts. I always run 'guix' using './pre-inst-env' from a git checkout of my private branch. I build everything locally, and never use substitutes. My /

bug#38422: .png files in /gnu/store with executable permissions (555)

Hi Bengt, Bengt Richter wrote: > I was wanting to check on some executable files in the store, > and happened to see some executable .png files ;-/ > > I suspect they came in when I was playing with icecat > and let it load a "theme", but I am not sure some didn't > also happen trying to get fi

bug#38422: .png files in /gnu/store with executable permissions (555)

Hi Bengt, Bengt Richter writes: > On +2019-11-29 07:20:41 -0500, Mark H Weaver wrote: >> The proper solution is to send bug reports to the upstream developers of >> docbook-xsl, faba-icon-theme, and moka-icon-theme, asking them to fix >> the permissions of the *.png

bug#38360: Retroarch does violate FSDG

Hi Arne, Arne Babenhauserheide writes: > Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: > >> Guix, >> >> This is not about Schrödinger's proprietary-until-proven-innocent >> binary. The Updater includes at least two cores explicitly marked as >> non-free in Debian: >> >> libretro-

bug#55089: [IceCat and IceDove]: Doesn't use system's locale/timezone.

Hi Raghav and bdju, "bdju" via Bug reports for GNU Guix writes: > On Sun Apr 24, 2022 at 1:06 AM CDT, Raghav Gururajan via Bug reports for GNU > Guix wrote: >> Hello Guix, >> >> It appears that the applications IceCat and IceDove doesn't follow >> system's locale/timezone. By default, it uses

bug#58147: FAAC considered nonfree by Debian and Parabola

Liliana Marie Prikler writes: > Am Mittwoch, dem 28.09.2022 um 19:12 +0200 schrieb Denis 'GNUtoo' > Carikli: >> The path chosen by Parabola (and probably most other FSDG compliant >> or 100% free distributions) was to make the packages not depend on >> faac. > Assuming one can clearly point out

bug#37244: Icecat Audio Issues

One of the differences between Firefox and IceCat is the default value of the "privacy.resistFingerprinting" setting in . The default in Firefox is "false", and the default in IceCat is "true". I've found that some audio/video players that misbehave in IceCat will start working correctly if you s

bug#30265: Fish embeds store file names in UCS-4/UTF-32 literal strings

John Soo writes: > I looked into it and I think a patch to fish might be required but I > got buried in other work. Note that commit 1bab9b9f17256a9e4f45f5b0cceb8b52e0a1b1ed (April 2021) added support in our grafting code to find and rewrite UTF-16 and UTF-32 store references. That might have mi

bug#58591: Java packages do not appear to keep a reference to their inputs

Julien Lepiller writes: > You're right, java package don't retain references to there input, > that's why we propagate required dependencies (mh… sometimes). I don't > know how they could reference dependencies directly. A better workaround would be to add a phase that installs file(s) in the ou

bug#32026: [PATCH 10/10] gnu: icecat: Use the locale of the system.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/patches/icecat-makeicecat.patch: Set the intl.locale.requested > option to the empty string. Let's fix this in upstream IceCat. I see that you've already posted a proposed patch to bug-gnuzilla. I'll followup there. Thanks! Mark

bug#32026: [PATCH 05/10] gnu: icecat: Add a patch that makes building language packs reproducible.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/patches/icecat-reproducible-langpacks.patch: New file. > * gnu/local.mk (dist_patch_DATA): Register. it. > * gnu/packages/gnuzilla.scm (icecat-source): Apply it. Let's make this change in upstream IceCat instead of in Guix. What do you think?

bug#32026: [PATCH 05/10] gnu: icecat: Add a patch that makes building language packs reproducible.

Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver writes: > >> Maxim Cournoyer writes: >> >>> * gnu/packages/patches/icecat-reproducible-langpacks.patch: New file. >>> * gnu/local.mk (dist_patch_DATA): Register. it. >>> * gnu/packages/gnuzilla.sc

bug#32026: [PATCH 04/10] gnu: icecat: Update the "ach" locale.

Hi Maxim, Maxim Cournoyer writes: > The currently captured changeset didn't match what the manifest in the source > specifies. This was discovered by running 'update-mozilla-locales'. > > * gnu/packages/gnuzilla.scm (all-mozilla-locales) [ach]: Update revision and > hash. I took the liberty of

bug#32026: [PATCH 01/10] gnu: Add a 'update-mozilla-locales' helper for maintenance.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (update-mozilla-locales): New procedure. > (all-mozilla-locales): Comment how to proceed to update it. [...] > +(define (update-mozilla-locales changesets.json) > + "Output a new list of Mozilla locales, to update the ALL-MOZILLA

bug#32026: [PATCH 10/10] gnu: icecat: Unbundle nss and nspr.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (icecat-minimal) [inputs]: Add nspr-next and > nss-next. > [configure-flags]: Re-instate the "--with-system-nspr" and "--with-system-nss" > configure flags. > [phases] {remove-bundled-libraries}: Update comment. This is really grea

bug#32026: [PATCH 03/10] gnu: Define UPSTREAM-FIREFOX-SOURCE at the top level.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (%icecat-base-version): New variable. > (%upstream-firefox-version): Likewise. > (%icecat-version): Define in terms of %icecat-base-version. > (upstream-firefox-source): New variable. > (icecat-source): Adjust to use the above newly

bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (%icecat-locales, %icedove-locales): New variable. > (make-l10n-package): New procedure. > (icecat-l10n, icedove-l10n): New variables. Thanks very much for this important work. Our lack of support for language packs has been sore s

bug#32026: [PATCH 09/10] gnu: icecat: Remove gtk+-2 input.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (icecat-minimal) [inputs]: Remove gtk+-2. Looks good to me, except that the commit log should say 'icecat' instead of 'icecat-minimal' if it's pushed now. Thanks, Mark

bug#32026: [PATCH v3 10/11] gnu: nss-next: Update to 3.88.1 [fixes CVE-2023-0767].

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/nss.scm (nss-next): Update to 3.88.1 This commit should be pushed immediately as an important security update. Thanks, Mark

bug#32026: [PATCH 10/10] gnu: icecat: Unbundle nss and nspr.

Hi Maxim, Maxim Cournoyer writes: > I've updated nss-next to 3.88.1 on master, which is supposed to fix this > CVE, [...] Great, thanks! Could you please make sure that 'nspr-next' is up-to-date as well? It would be good to avoid inadvertently downgrading the NSPR used by IceCat. I don't know

bug#32026: [PATCH 05/10] gnu: Add icecat-l10n and icedove-l10n.

Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver writes: [...] >> (1) Instead of generating the locales in separate "*-locales" packages >> and then merging them with the main package (which must then be >> renamed to "*-minimal"), ho

bug#32026: [PATCH 03/10] gnu: Define UPSTREAM-FIREFOX-SOURCE at the top level.

Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver writes: > >> Maxim Cournoyer writes: >> >>> * gnu/packages/gnuzilla.scm (%icecat-base-version): New variable. >>> (%upstream-firefox-version): Likewise. >>> (%icecat-version): Define in terms o

bug#32026: [PATCH v3 04/11] gnu: icecat: Make language packs reproducible.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/patches/icecat-reproducible-langpacks.patch: New file. > * gnu/local.mk (dist_patch_DATA): Register. it. > * gnu/packages/gnuzilla.scm (icecat-source): Apply it. Instead of adding this patch in Guix, let's make the change in upstream IceCat. Am

bug#32026: [PATCH v4 3/9] gnu: Define %icecat-base-version at the top level.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (%icecat-base-version): New variable. > (%icecat-version): Define in terms of %icecat-base-version. > (icecat-source): Adjust to use the above newly introduced variables. What's the rationale for this? I couldn't find any uses of '

bug#32026: [PATCH v4 1/9] gnu: Add a 'update-mozilla-locales' helper for maintenance.

Hi Maxim, Maxim Cournoyer writes: > * gnu/packages/gnuzilla.scm (update-mozilla-locales): New procedure. > (all-mozilla-locales): Comment how to proceed to update it. The second line above should be removed to reflect the updated patch. > +(define (update-mozilla-locales changesets.json) > + "

bug#61722: [PATCH] cpio: Properly handle Unicode characters in file names.

Hi Maxim, Maxim Cournoyer writes: > Fixes . > > * guix/cpio.scm (file->cpio-header): Compute the file name length in bytes > rather than in > characters. > (file->cpio-header*, special-file->cpio-header*): Likewise. > (write-cpio-archive): Likewise, and write

bug#43166: The issues.guix.gnu.org is hard to read in emacs-w3m.

Hi Maxim, Maxim Cournoyer writes: > Mark H Weaver writes: > >> Earlier, I wrote: >>> However, I've noticed that in Dillo with CSS disabled, generating a >>> 'pre' for each line makes the line spacing larger than would be ideal. >>> It

bug#48602: Grafted python2 packages gets erroneous package names

Hi Marius, Marius Bakke writes: > 'guix build python2-urllib3' currently gives: > > /gnu/store/cx22ny550g97klf499yqgzx9mpvvkx1f-python2-python2-urllib3-1.26.4 > > Adding '--no-grafts' gives the expected file name. > > Note that up until commit 2f97a666a564fea0fdcff00a0513aa8b4c2d60fe, the > st

bug#48604: Linux-libre 5.12.5 freezes

Hi, Yusuf Talha via Bug reports for GNU Guix writes: > hello.  i am using a librebooted thinkpad x200 laptop with gnu guix.  > if i use the latest kernel on my system, my computer suddenly freezes > without a reason after a while of usage.  it is probably a kernel > panic.  older kernels don't ha

bug#48213: offlineimap build fails

Hi Simon, zimoun writes: > The package offlineimap will go sooner or later since Python 2 is EOL. > The migration from Py2 to Py3 is not clear [1] and the README [2] says: > > > As one of the maintainer of OfflineIMAP, I'd like to put my efforts into > > [imapfw](http://github.com/OfflineIMAP

bug#48273: Icedove 78.10.0 build stuck at 'unpack' phase

Hi Jonathan, I wrote: > Unfortunately, not all of our package definitions respect the --cores > option. Our 'icecat' package does, but I can see now that our > 'icedove' package does _not_ respect it. It would be good to fix that. Jonathan Brielmaier replied: > @Mark: Yes, it would by nice to

bug#48796: Guix on Debian 11 - Cant run or find applications from Guix

Hi, bo0od writes: > I have installed Guix package manager over debian bullseye 11 then i > installed a package using guix (after running guix pull) with two ways: > (x package i tried is icecat) > > guix install x > > sudo -i guix install x > > both of the commands worked but the x package has

bug#48959: icecat imcomplete LD_LIBRARY_PATH affecting Kerberos authentication

re It Is Installed) of our manual for details of how to do this. If you encounter difficulties or have additional questions, please do not hesitate to ask. Regards, Mark >From 857f829906e0f8d9583a32ad47c91149c7714171 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 13

bug#48959: icecat imcomplete LD_LIBRARY_PATH affecting Kerberos authentication

Hello again, Earlier, I wrote: > Are you able to test this patch? One way to do so is to clone the > master branch of our git repository, apply this patch to the Guix git > checkout and build it, and then run that modified copy of Guix (without > installing it) to build icecat. On second thought

bug#48959: icecat imcomplete LD_LIBRARY_PATH affecting Kerberos authentication

Hi Ignacio, Ignacio Coterillo writes: > First, I confirm that Kerberos authentication works when running > icecat as: > > LD_LIBRARY_PATH=$(guix build mit-krb5)/lib icecat Thanks. I just pushed my proposed patch to the master branch, commit 61b904b744c1f16084c79e526837cc7fe73f9b92. I'm al

bug#49121: ./guix-daemon is broken

Hi Tobias, Tobias Geerinckx-Rice via Bug reports for GNU Guix writes: > There's a new(?) warning in towne: > > --8<---cut here---start->8--- > $ guix environment guix -- make V=1 > […] > LANGUAGE= ./pre-inst-env /run/current-system/profile/bin/sh > /home/nckx

bug#49276: evolution-data-server: test-failure

Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Thu, 24 Sep 2020 16:53:21 -0400 Subject: [PATCH] LOCAL: gnu: evolution-data-server: Disable tests. --- gnu/packages/gnome.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index dfcf5dcd0c..9

bug#50212: Several tests fail, Bash fails often. Was: Tests fail while building Guix

Hi, Maxime Devos writes: > * What's the hash of gnu/packages/bootstrap/i686-linux/bash? > > (Run guix hash gnu/packages/bootstrap/i686-linux/bash) > > I have 1ig8a4bhc7fpw8zrnw4l568wmmcb29rlwg4jbih3imb4x6d9l1gd. > If you see something different, your copy is probably corrupt. Also check th

bug#33463: guix publish error on Hydra: fport_close: Bad file descriptor

Hi Simon, zimoun writes: > This old bug [1] is about Hydra which is down now, IIRC. > > Does it make sense to keep it open? I think it's okay to close it. I'm doing so now. Thanks! Mark -- Disinformation flourishes because many people care deeply about injustice but very few chec

bug#34135: IceCat lacks WebGL support

Hi Sarah, Thanks for looking into this, and more generally for all the work you've been putting into Guix lately. Sarah Morgensen writes: > While it looks like preliminary precise whitelisting was done for > ffmpeg, it seems that this approach may require excessive effort for > WebGL. Perhaps,

bug#51021: detect loops in module/package graph

Hi, raingloom writes: > I'll be short and blunt, currently it sucks big time whenever you have > a loop in your packages. Agreed. I've been concerned about this problem since the early days of Guix. See . Back in August 2014, there was a strongly connected componen

bug#51021: detect loops in module/package graph

Earlier, I wrote > I've attached a script that I hacked up in 2014 to analyze the Guix > package module dependency graph. Here's the script: ;;; cycle-viewer.scm: a Guix package module dependency graph analyzer ;;; Copyright (C) 2014 Mark H Weaver ;;; ;;; This program is free s

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

Roel Janssen writes: > On Fri, 2021-03-19 at 19:13 -0400, Mark H Weaver wrote: >> Ludovic Courtès writes: >> >> > Maxim Cournoyer skribis: >> > >> > > We should patch GnuTLS so that it also honors the SSL_* >> > > environment >&g

bug#44953: lsof: LTlock test consistently fails (possibly due to btrfs)

I don't know whether it will apply cleanly. >From 1a658341538b8ea1470ef1bd02dfb3922011df79 Mon Sep 17 00:00:00 2001 From: Mark H Weaver Date: Sun, 29 Nov 2020 16:03:57 -0500 Subject: [PATCH] Revert "gnu: lsof: Make test failures fatal." This reverts commit 2bf502

bug#47092: Icecat sandbox causes issues with fonts in --pure env

Hi, Martin via Bug reports for GNU Guix writes: > Problem fixed with the newest IceCat v91.2.0-guix0-preview1 in the >  guix c1ca853 >     repository URL: https://git.savannah.gnu.org/git/guix.git >     branch: master >     commit: c1ca85323d5246fc805a31e03b4164b8da08e930 Thanks for letting

bug#51478: icecat 91 can't display chinese font in many web page

Z572 via Bug reports for GNU Guix writes: > after update to 91, icecat can't display chinese font for many web page: Thanks for the report. As a temporary workaround, it might help to visit and change the setting for "security.sandbox.content.read_path_whitelist" to contain simply "/gnu/store/"

bug#51559: Webkit fails to build

reopen 51559 thanks Hi Maxim, Maxim Cournoyer writes: > That's fixed on core-updates-frozen-batched-changes, having upgraded > webkitgtk to 2.34.4 and libsoup to 3.0.1. > > Closing. Unless I'm mistaken, there still remains the problem that 'webkitgtk' and all of its dependents are currently bro

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

Hi Liliana, Liliana Marie Prikler writes: > See , , and > . > > * gnu/packages/webkit.scm (webkitgtk)[#:configure-flags]: Enable USE_SOUP2. > [inputs]: Add lcms. > --- > Currently building this thing, but my mach

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

"Leo Famulari" writes: > Thanks, please push! How about testing it first, for a change? An essentially equivalent[*] patch didn't work for me, although admittedly my private branch has diverged quite a bit from master. Based on the error message, I guess we might need to use a newer C++ compile

bug#51478: icecat 91 can't display chinese font in many web page

Hi, Z572 <873216...@qq.com> writes: > I add "/run/current-system/profile/share/fonts/" to > "security.sandbox.content.read_path_whitelist" fixed it for me. Thanks! One very important note: you should "reset" this customization after updating to IceCat 91.3.0, or else IceCat will stop working cor

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

Hi Liliana, Liliana Marie Prikler writes: > I'm now trying 2.34.4 (same version and hash as c-u-f), which at least > appears to build further than the bug we both encounter. As far as I can tell, WebKitGTK 2.34.4 doesn't yet exist. The newest version available at

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

Hi Liliana, Liliana Marie Prikler writes: > Am Dienstag, den 02.11.2021, 13:31 -0400 schrieb Mark H Weaver: [...] >> or (2) try using a newer C++ compiler. > Is this really an issue with g++? Not necessarily. It could be that the code relies on compiler behavior beyond what is req

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

FYI, I pushed commit 9d3a5ddc2700aa099bb1bf9c5e8b3062445b907a to 'master', which fixes the webkitgtk-2.34.1 build on x86_64-linux. In addition to the fixes already shown in Liliana's proposed patch, 9d3a5ddc27 also arranges to use clang-11 for compilation. Unfortunately, the build fails on i686-l

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

libwebkit2gtk-4.0.so fails to link on i686-linux, due to an undefined reference to '__mulodi4'. https://ci.guix.gnu.org/build/1428233/details See below for the tail of the build log. It might be an issue with clang, or with our clang packaging. Thanks, Mark --8<---cu

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

Earlier, I wrote: > libwebkit2gtk-4.0.so fails to link on i686-linux, due to an undefined > reference to '__mulodi4'. Here are some relevant links: https://bugs.webkit.org/show_bug.cgi?id=190208 https://trac.webkit.org/changeset/272140/webkit https://github.com/android/ndk/issues/506 > h

bug#51555: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

Liliana Marie Prikler writes: > Am Mittwoch, den 03.11.2021, 14:09 -0400 schrieb Mark H Weaver: >> [...] >> >> Note that I tried clang-11 first, because upstream WebKit surely uses >> clang for compilation, and it works for building IceCat on Guix, so I >> ha

bug#51559: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

Hi Liliana, Liliana Marie Prikler writes: > Am Mittwoch, den 03.11.2021, 14:09 -0400 schrieb Mark H Weaver: >> [...] >> >> Note that I tried clang-11 first, because upstream WebKit surely uses >> clang for compilation, and it works for building IceCat on Guix, so I

bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

reopen 51591 thanks Hi Liliana, Mark H Weaver writes: > Liliana Marie Prikler writes: > >> Am Mittwoch, den 03.11.2021, 14:09 -0400 schrieb Mark H Weaver: >>> [...] >>> >>> Note that I tried clang-11 first, because upstream WebKit surely uses >

bug#51559: Webkit fails to build

Hi, Liliana Marie Prikler writes: > Am Donnerstag, den 04.11.2021, 14:23 -0400 schrieb Maxim Cournoyer: >> Note that on the core-updates-frozen-batched-changes branch webkitgtk >> (with libsoup2 or 3) could still be built with GCC (version 10). > Should we try building webkitgtk and its dependan

bug#51555: bug#51564: [PATCH] gnu: webkitgtk: Fix configure failures.

Hi Leo, Leo Famulari writes: > On Thu, Nov 04, 2021 at 08:57:18AM -0400, Mark H Weaver wrote: >> Although the WebKitGTK package itself built successfully using GCC 11, >> the switch to GCC 11 caused many failures in programs that use >> WebKitGTK. For example: > >

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

Liliana Marie Prikler writes: > Am Mittwoch, den 03.11.2021, 17:04 -0400 schrieb Mark H Weaver: >> Earlier, I wrote: >> > libwebkit2gtk-4.0.so fails to link on i686-linux, due to an >> > undefined reference to '__mulodi4'. >> >> Here are some

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

Leo Famulari writes: > On Fri, Nov 05, 2021 at 09:08:05AM +0100, Liliana Marie Prikler wrote: >> I did some static code analysis and it seems we could comment out the >> line >> CHECK_FOR_SSE2() >> in Source/cmake/DetectSSE2.cmake. In my personal opinion, we should >> probably do so on all pla

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

Hi Liliana, Liliana Marie Prikler writes: > Am Donnerstag, den 04.11.2021, 19:15 -0400 schrieb Mark H Weaver: [...] >> A more conservative approach would be to apply a patch to >> trunk/Source/WTF/wtf/CheckedArithmetic.h analogous to the one in the >> second link I cited a

bug#47422: tar is vulnerable to CVE-2021-20193

Hi Maxime, Maxime Devos writes: > Leo Famulari schreef op vr 05-11-2021 om 12:23 [-0400]: >> For use of tar by Guix users, we could add a new package 'tar-1.34' >> and arrange so that `guix install tar` selects it instead of >> tar@1.32, and so that whatever tar is provided by default on Guix >>

bug#51591: webkitgtk fails to build on i686-linux; possibly a clang issue

Hi Maxime, Maxime Devos writes: > Mark H Weaver schreef op vr 05-11-2021 om 15:42 [-0400]: >> +     ;; XXX Until we switch back to using GCC, >> + ;; work around <https://bugs.gnu.org/51591>. >> + ,@(if (string=? &q

<    5   6   7   8   9   10   11   >