bug#53857: telegram-desktop: fails to build

Am Mittwoch, dem 09.02.2022 um 11:18 -0900 schrieb Christopher Howard: > Hi, when I try to build with `guix build -M 1 -c 1 telegram-desktop` > I seem to be getting the same error. I can believe what you say about > the ram, as I've run into that problem before with other packages, > though it

bug#53873: False flag

Am Dienstag, dem 08.02.2022 um 11:48 +0100 schrieb Rovanion Luckey: > Never mind, it was a networking error and `guix pull` worked fine on > a rerun. Flagging it done then ️

bug#53857: telegram-desktop: fails to build

Hi Christopher, Am Montag, dem 07.02.2022 um 09:32 -0900 schrieb Christopher Howard: > {standard input}:1918775: Warning: end of file not at end of a line; > newline inserted > {standard input}: Error: open CFI at the end of file; missing > .cfi_endproc directive > c++: fatal error: Killed signal

bug#53752: guix home symlink permissions

Am Montag, dem 07.02.2022 um 22:02 +0100 schrieb Maxime Devos: > Zacchaeus Scheffer schreef op ma 07-02-2022 om 14:47 [-0500]: > > I was able create the desired effect with the following service > > definition: > > (simple-service > >  'my-activation-service > >  home-activation-service-type > >  

bug#53840: The current bitlbee-discord@0.4.3 does not work with glib@2.70.2

Hi, Am Montag, dem 07.02.2022 um 09:44 +0100 schrieb Adam Maleszka: > I'm trying to configure bitlbee-discord in order to write on Discord > using ERC in Emacs. Unfortunately, every time I open connection to > Discord, this error is thrown: > > [...] > I see three solutions. > * The third

bug#53790: Audacity has extraneous binary at directory root

Hi, Am Samstag, dem 05.02.2022 um 13:52 -0500 schrieb Leo Famulari: > On Sat, Feb 05, 2022 at 08:22:32AM +0100, Liliana Marie Prikler > wrote: > > Looking at the size of this thing compared to our audacity, I > > thought to myself "hmm, that's a shell script"

bug#53790: Audacity has extraneous binary at directory root

Hi Leo, Am Freitag, dem 04.02.2022 um 17:03 -0500 schrieb Leo Famulari: > Our Audacity package creates an extraneous "audacity" binary in the > root of the store item: > > -- > $ git describe   > v1.3.0-15695-gba60aede97 > $ ls -la $(./pre-inst-env guix

bug#53752: guix home symlink permissions

Am Donnerstag, dem 03.02.2022 um 13:08 -0500 schrieb Zacchaeus Scheffer: > I finally migrated my home configuration to guix home.  However, it > seems guix home creates all symlinks with 777 permissions.  This causes > problems with openssh as it will not recognize my > ~/.ssh/authorized_keys.  It

bug#53696: Integer overflow on Guix GC size calculation

Hi, Am Dienstag, dem 01.02.2022 um 21:54 + schrieb Ekaitz Zarraga: > > Hi, > > ‐‐‐ Original Message ‐‐‐ > > On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler > wrote: > > > > I find it somewhat concerning that you've accumulated mo

bug#53696: Integer overflow on Guix GC size calculation

Hi, Am Mittwoch, dem 02.02.2022 um 19:51 + schrieb Ekaitz Zarraga: > I mean something like: > > 0 > 1 > 2 > 4 > 8 > 10 > 12 > HUGE_NUMBER > HUGE_NUMBER > ... > HUGE_NUMBER > 15 > 20 > ... > > It's like it corrected itself. It happened in "low numbers" (less > than a > hundred). > > I just

bug#53696: Integer overflow on Guix GC size calculation

Am Dienstag, dem 01.02.2022 um 14:06 + schrieb Ekaitz Zarraga: > Hi, > > I noticed there's some kind of a wierd integer overflow on the size > calculation on `guix gc`: > > [17592186042896 MiB] deleting > '/gnu/store/j2s6kva8l20m6rjj10bnknq99jc9rg6w-ghc-random-1.2.0- > builder' >

bug#53591: [PATCH] gnu: audacity: Add fallback to locate ffmpeg via pkg-config.

Am Samstag, dem 29.01.2022 um 14:53 -0500 schrieb Leo Famulari: > On Sat, Jan 29, 2022 at 06:54:54PM +0100, Liliana Marie Prikler > wrote: > > * gnu/packages/patches/audacity-ffmpeg-fallback.patch: New file. > > * gnu/local.mk (dist_patch_DATA): Add it here. > > * gnu/pack

bug#53591: [PATCH] gnu: audacity: Add fallback to locate ffmpeg via pkg-config.

-0,0 +1,61 @@ +From 3c20057d0cbbbed453a692d4dd4589d865808024 Mon Sep 17 00:00:00 2001 +From: Liliana Marie Prikler +Date: Sat, 29 Jan 2022 10:44:44 +0100 +Subject: [PATCH] Add pkg-config fallback for locating ffmpeg. + +--- + libraries/lib-ffmpeg-support/CMakeLists.txt | 8 + libraries/lib-ffmpeg-support/FFmp

bug#53559: [PATCH] gnu: mutter: Disable timeline tests.

* gnu/packages/gnome.scm (mutter)[disable-problematic-tests]: Also disable timeline tests. --- gnu/packages/gnome.scm | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm index e3fac534c4..b341fb4c97 100644 ---

bug#53559: Mutter test-suite is flaky

Hi Guix, ever since the merge of core-updates-frozen, I've been unable to build mutter locally, while fetching it from CI is usually fine. Attached is a build log -- note, that the traceback is generated by me killing the process with a SIGSEGV, it would otherwise go on for several days. Cheers

bug#53514: Guix should not set global variables that may affect host

Hi, Am Montag, dem 24.01.2022 um 17:24 -0500 schrieb Maxim Cournoyer: > Hello! > > There are multiple reports about the negative effects of Guix setting > variables such as XDG_DATA_DIRS on foreign distributions, that may > cause problems a severe as locking users out of their graphical >

bug#53407: libfuse 3 can't find fusermount

Hi Leo, Am Freitag, dem 21.01.2022 um 02:41 -0500 schrieb Leo Famulari: > While testing a Borg update (patch attached), I noticed that the > FUSERMOUNT_DIR hack in Fuse 3 doesn't seem to work like it does with > Fuse 2. > > The 1.2.0b3 beta of the upcoming Borg release can use either Fuse 2 >

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

Am Donnerstag, dem 20.01.2022 um 09:29 -0300 schrieb Jorge P.de Morais Neto: > I have defined TZDIR on ~/.profile and so far it's working.  Let's > see if it continues to work well. > > And how will other users know how to fix the problem?  Will Guix's > manual be updated?  There could also be a

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

Am Donnerstag, dem 20.01.2022 um 08:27 -0300 schrieb Jorge P.de Morais Neto: > Hello.  So the solution to the bug is for the user to manually write > the file ~/.config/systemd/user/gnome-shell- > x11.service.d/override.conf ? > > I would like to know a little more about that.  What is the

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

Am Donnerstag, dem 20.01.2022 um 09:03 + schrieb John Hamelink: > Hi Liliana, > > Liliana Marie Prikler writes: > > > It turns out this issue is actually related to another issue of > > Guix' Emacs on foreign distros, which is it not finding timezones.  > >

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

Hi Am Donnerstag, dem 20.01.2022 um 00:03 + schrieb John Hamelink: > Hi there, > > I'm experiencing an issue with the emacs-next package on my Guix > foreign setup where the cursor (*not* Emacs point) is very dark. It's > perfectly legible against the default Emacs theme, but nonetheless it

bug#53197: [PATCH 0/3] Update WPEWebkit to 2.34.3

Hi, Am Sonntag, dem 16.01.2022 um 13:30 -0500 schrieb Leo Famulari: > I noticed that GTK 4 depends on wpebackend-fdo. For now, we can > change GTK 4 on the master branch, but eventually wpebackend-fdo will > be a package that requires grafting to keep up to date. I'm fine with turning the

bug#53197: [PATCH 3/3] gnu: wpewebkit: Update to 2.34.3.

* gnu/packages/webkit.scm (wpewebkit): Update to 2.34.3. [#:phases]: Add ‘patch-cmake’ phase to fix an error in the install directories of the documentation. [inputs]: Add lcms. --- gnu/packages/webkit.scm | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git

bug#53197: [PATCH 2/3] gnu: wpebackend-fdo: Update to 1.12.0.

* gnu/packages/webkit.scm (wpebackend-fdo): Update to 1.12.0. [build-system]: Use meson-build-system. [inputs]: Add libepoxy. --- gnu/packages/webkit.scm | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gnu/packages/webkit.scm b/gnu/packages/webkit.scm index

bug#53197: [PATCH 1/3] gnu: libwpe: Update to 1.12.0.

* gnu/packages/webkit.scm (libwpe): Update to 1.12.0. [build-system]: Use meson-build-system. --- gnu/packages/webkit.scm | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/gnu/packages/webkit.scm b/gnu/packages/webkit.scm index 8e9aa2b1b5..582adaddda 100644 ---

bug#53197: [PATCH 0/3] Update WPEWebkit to 2.34.3

. Cheers Liliana Marie Prikler (3): gnu: libwpe: Update to 1.12.0. gnu: wpebackend-fdo: Update to 1.12.0. gnu: wpewebkit: Update to 2.34.3. gnu/packages/webkit.scm | 29 - 1 file changed, 20 insertions(+), 9 deletions(-) -- 2.34.0

bug#53197: wpewebkit: Fails to build (a required package was not found)

Am Donnerstag, dem 13.01.2022 um 08:45 +0100 schrieb Liliana Marie Prikler: > some hitherto unpackaged... package[1] > [1] https://github.com/Igalia/WPEBackend-fdo It turns out we actually do have wpebackend-fdo and are even using it in our webkitgtk build. I'll try updating the wp

bug#53245: broken package: python2-future

Am Freitag, dem 14.01.2022 um 00:17 -0500 schrieb Faerryn: > It looks like module tkinter doesn't load for some reason.  Here is > the tail of the build log: Note that a patch to exclude tkinter and winreg from the sanity check is already in the mailing list [1], but hasn't been applied yet.

bug#53197: wpewebkit: Fails to build (a required package was not found)

Am Mittwoch, dem 12.01.2022 um 13:28 -0500 schrieb Leo Famulari: > On Wed, Jan 12, 2022 at 08:28:13AM +0100, Liliana Marie Prikler wrote: > > wpewebkit seems to have been ignored in the core-updates merge.  It > > still uses old-style inputs and (more importantly) libsoup now refers

bug#53197: wpewebkit: Fails to build (a required package was not found)

Am Dienstag, dem 11.01.2022 um 22:49 +0100 schrieb kias...@tutanota.com: > ``` > -- Found ICU: /gnu/store/7sik9fp2ffvnr7l01s423x4r5pn75rf9-icu4c- > 69.1/include (found suitable version "69.1", minimum required is > "60.2") > -- Found JPEG: /gnu/store/vhxayydx3y9n2gi2sc0dam26p7k1aaj8-libjpeg- >

bug#53180: libportal missing GTK3 backend

Hi Guix, this bug also affects Epiphany (build log attached). The issue appears to be that it tries to build without the GTK3 backend, we should probably enable that. Cheers dac0xa4q6lxcp63jz3fm7phnxsn5hv-epiphany-40.3.drv.bz2 Description: application/bzip

bug#53127: [PATCH RFC] Turning Rust/Cargo inputs into “regular” inputs?

Am Montag, dem 10.01.2022 um 09:58 +0100 schrieb Ludovic Courtès: > Hi! > > Liliana Marie Prikler skribis: > > > I suppose adding (package-source rust-cargo) to inputs to preserve > > the > > old meaning would not make much sense? > > No because you need tra

bug#53127: [PATCH RFC] Turning Rust/Cargo inputs into “regular” inputs?

Am Samstag, dem 08.01.2022 um 18:57 +0100 schrieb Ludovic Courtès: > Hello! > > I’m opening this issue to discuss the possibility of changing > #:cargo-inputs and #:cargo-development-inputs to regular inputs, as a > followup to: > >   https://issues.guix.gnu.org/51845#10 > > I have a

bug#53064: Already fixed

Am Donnerstag, dem 06.01.2022 um 21:01 -0500 schrieb Stephen Paul Weber: > A push to master right after I filed this has fixed it already. Debbugs allows you to mark your own bugs as done, you don't need to wait for a committer or someone to acknowledge that. Simply add "- done" to the bug

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

Hi, Am Freitag, dem 07.01.2022 um 03:56 + schrieb raid5atemyhomework: > Hello Liliana, > > [...] > > > It may be a *related* bug, but this may also be unique to how Guix > packages both programs. So I want to know if other users on Guix are > seeing the same thing as well. We don't do

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

Hi, Am Donnerstag, dem 06.01.2022 um 04:35 + schrieb raid5atemyhomework: > I recently upgraded, and on reboot found that the Gnome Shell extension > Dash to Dock was no longer working properly. > > Instead of displaying my favorite applications on the bottom dock, it > only displays the

bug#53002: guix can't find gfortran-toolchain or gdc-toolchain

Hi Jesse Am Dienstag, dem 04.01.2022 um 00:47 -0700 schrieb Jesse Gibbons: > Strange bug, guix can't find gfortran-toolchain even though it is a > package defined publicly in one of the files it presumably searches. > > `which guix` outputs the expected > "$HOME/.config/guix/current/bin/guix",

bug#52044: Various Program Settings not Saving and Icons not Recognized

Am Montag, dem 03.01.2022 um 22:05 + schrieb Jaft: > Hey, Josselin. > > Thanks so much for all the info. and walking through how things work; > it was really helpful. > > In the end, I think I just missed restarting my computer; after doing > so, the change that was made regarding gdk-pixbuf

bug#53000: How to reclaim space when no space is available?

Am Montag, dem 03.01.2022 um 23:12 -0500 schrieb Jeffrey Walton: > Hi Everyone, > > I've run out of disk space. I'm trying to run 'guix gc' but it seems > to need disk space to perform the garbage collection. > > $ sudo guix gc I don't think the manuals specify using `sudo guix gc'. Last time I

bug#52949: Traceback when reloading services

Hi Guix, today I got the attached traceback while trying to reconfigure Guix. It turns out that 145:12 tries to check which services are currently running and ignores that (eval exp) might return #f. I'm not sure which point would be the correct one to guard against this case, but a naïve

bug#52913: 0ad only builds fine with a specific version of mozjs

Am Samstag, dem 01.01.2022 um 12:14 -0700 schrieb Jesse Gibbons: >  > What would be the best way to fix this? >  >  - keep a mozjs-78.6 package around just for 0ad >  >  - patch 0ad to fix the compatibility issues with mozjs 78.15 >  >  - use the mozjs version bundled in the 0ad sources >  > >  >

bug#52073: remove Google support from GVFS?

Hi, Given that we have GNOME 40/41 on master right now with GVFS supporting Google as it did before, is this still relevant? Cheers

bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

Am Donnerstag, dem 23.12.2021 um 08:31 +0100 schrieb Denis 'GNUtoo' Carikli: > On Wed, 22 Dec 2021 11:29:29 +0100 > Maxime Devos wrote: > > > Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]: > > > For the record, guile has been a part of the system p

bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

Am Mittwoch, dem 22.12.2021 um 11:32 +0100 schrieb Maxime Devos: > Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]: > > No.  The Guix command as built by `guix pull' sets its own load path, > > but respects system paths too.  You can check by

bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

Hi Denis, Am Mittwoch, dem 22.12.2021 um 01:16 +0100 schrieb Denis 'GNUtoo' Carikli: > [A]s user GUILE_LOAD_COMPILED_PATH is somehow exported to system > paths: > > [gnutoo@primary_laptop ~]$ echo $GUILE_LOAD_COMPILED_PATH > > /run/current-system/profile/lib/guile/3.0/site-ccache:/run/current- >

bug#52665: buku build failure

I've pushed a patch to master, which fixes the build, but note that buku remains broken according to the sanity-check phase, meaning that at least some of its features will be missing. You're of course always welcome to add missing packages etc. Cheers

bug#52663: taisei build failure

Am Sonntag, dem 19.12.2021 um 14:01 -0600 schrieb bdju: > guix system > guix (GNU Guix) b3a0db7a0e5fa7186c090647cfd5666e2b9287ff > build log here: http://ix.io/3IRZ Hi, I just pushed a patch, that builds cglm with meson, as taisei appears to be the only package relying on it (according to `guix

bug#52573: gdk-pixbuf+svg

Hi Florian, Am Freitag, dem 17.12.2021 um 13:27 +0100 schrieb Florian Hoertlehner: > I believe something has changed in guix that breaks my package > definition of vscodium. > > I had this package running for 6 months, and now it no longer works: >

bug#52539: Fwd: Comments in /etc/passwd don't get updated

Hi, Am Donnerstag, dem 16.12.2021 um 07:00 + schrieb Jacob First: > In my Guix system's /etc/passwd file, my user named "abc" has a > comment attached to it. The relevant line is: > >     abc:x:1000:998:Old > Comment:/home/jkf:/gnu/store/71yp1p06jy2j96bfdz43f4p6ncdym5a1-zsh- > 5.8/bin/zsh >

bug#52347: Shell: error when -m manifest is removed

Am Dienstag, den 07.12.2021, 15:27 +0100 schrieb zimoun: > Hi, > > On Tue, 7 Dec 2021 at 14:48, Liliana Marie Prikler > wrote: > > > I am pretty sure all files are owned by the same user in my > > case. Can > > stat:uid really return 0 then? > > Maybe I

bug#52347: Shell: error when -m manifest is removed

Am Dienstag, den 07.12.2021, 14:41 +0100 schrieb zimoun: > On Tue, 7 Dec 2021 at 14:33, Liliana Marie Prikler > wrote: > > > I am experiencing a similar situation without the container. At > > work, > > I need some special Emacs packages, that I don't need/want in my

bug#52347: Shell: error when -m manifest is removed

Hi, I am experiencing a similar situation without the container. At work, I need some special Emacs packages, that I don't need/want in my normal setup, so I do `guix shell -m manifest.scm -- emacs'. Even with the directory added to the good noodles list, `guix shell -- emacs' fails, probably

bug#52236: PRIVACY: Integrate arkenfox for icecat configuration

Am Samstag, den 04.12.2021, 00:31 + schrieb Jacob Hrbek: > arkenfox is a **TEMPLATE** we can't just paste it in userland and > expect peak security instead we should process the template and > integrate the configuration in parametrisation with cherrypicked > defaults to **generate** the

bug#48331: Emacs' describe-package doesn't work for packages managed by guix

At long last, I'm pushing the patch to keep -pkg.el files as well as to load them from guix-emacs during package-initialize. I'll hereby be closing this bug. Andrew, if you wish to write a phase that adds such a file for the packages currently lacking them, I'm pretty sure we can do with a new

bug#52044: Various Program Settings not Saving and Icons not Recognized

Am Donnerstag, den 02.12.2021, 20:16 + schrieb Jaft: > > Am Donnerstag, den 02.12.2021, 02:10 + schrieb Jaft: > > > I had noticed that the core-updates-frozen branch had been merged > > > so > > > I upgraded but found things pretty much the same as before. > > Please come back, you're

bug#52044: Various Program Settings not Saving and Icons not Recognized

Hi, Am Donnerstag, den 02.12.2021, 02:10 + schrieb Jaft: > I had noticed that the core-updates-frozen branch had been merged so > I upgraded but found things pretty much the same as before. Please come back, you're within the wrong timeline. > I saw an old patch ( >

bug#52044: Various Program Settings not Saving and Icons not Recognized

Hi, Am Montag, den 29.11.2021, 04:01 + schrieb Jaft: > The issue seems to be that icons such as Papirus and Delft aren't > using their own folders; instead, they seem to be using Adwaita's > (maybe via the gnome-icon-theme package?). I think the images I'd > attached better demonstrate the

bug#52044: Various Program Settings not Saving and Icons not Recognized

Hi, Am Sonntag, den 28.11.2021, 12:52 + schrieb Jaft: > [...] > > (If I understood correctly,) you were saying that a similar setup to > the Gnome example you gave could work with XFCE but running the full, > plain XFCE (assuming I did that right) still resulted in this weird > thing with

bug#52044: Various Program Settings not Saving and Icons not Recognized

Hi Jaft, > I'm not sure if it's stemming from a bug or I've just missed a package > or service I should've included but I find there're several programs I > have installed which aren't saving their settings. > Catfish and thunar are two easy examples while gnome-calendar, arandr, > and viewnior

bug#52073: remove Google support from GVFS?

Am Mittwoch, den 24.11.2021, 12:33 -0500 schrieb Leo Famulari: > On Wed, Nov 24, 2021 at 06:00:15AM +0100, raingloom wrote: > > I'd love to say it's because I want the package to be more in line > > with libre software guidelines, but honestly I just don't want > > WebKitGTK as a transitive input.

bug#52011: pkexec: PATH environment variable

Hi, Am Sonntag, den 21.11.2021, 11:33 +0330 schrieb Hamzeh Nasajpour: > The `PATH` environment variable is hard-code here: > > https://github.com/freedesktop/polkit/blob/master/src/programs/pkexec.c#L882-L886 > > We don't have any executable in these paths in guix: > ``` >

bug#51869: [PATCH] Add emacs-vala-mode

Hi, Am Dienstag, den 16.11.2021, 19:48 + schrieb Vivien Kraus: > > > + (emacs-substitute-sexps "vala-mode.el" > > > + (";; Support multiline strings" 'disabled.) > > > + ("(defcustom vala-multiline-strings nil" > > > + "This

bug#51869: [PATCH] Add emacs-vala-mode

Hi, Am Dienstag, den 16.11.2021, 18:12 + schrieb Vivien Kraus: > + (home-page "https://github.com/rrthomas/vala-mode;) > + (source > + (origin > + (method git-fetch) > + (uri (git-reference > + (url home-page) > + (commit commit)))

bug#51869: [PATCH] Add emacs-vala-mode

Hi, Am Montag, den 15.11.2021, 20:48 + schrieb Vivien Kraus: > Liliana Marie Prikler writes: > > > Since I don’t have a solution to fix this issue, I went away and > > > reverted the multiline support. It builds and is useful enough > > > for LSP to k

bug#51869: [PATCH] Add emacs-vala-mode

Hi Vivien, Am Montag, den 15.11.2021, 14:05 + schrieb Vivien Kraus: > Dear guix, > > There’s a vala mode for emacs. It is not very useful I'd beg to differ. Not opening Vala files in fundamental-mode is very useful. > The project is not very well maintained I've experienced the same. I

bug#48713: [PATCH] gnu: emacs-all-the-icons: Install all the fonts.

* gnu/packages/emacs-xyz.scm (emacs-all-the-icons)[#:include]: Drop fonts. [#:phases]: Install them directly to ‘/share’. [propagated-inputs]: Add font-awesome. --- gnu/packages/emacs-xyz.scm | 19 +-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git

bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen

Hi, Am Mittwoch, den 10.11.2021, 20:20 + schrieb Vivien Kraus: > Apparently, we shouldn’t apply guix style yet, we will apply it for > all packages at once some day. I don't think it's a rule that you can't at all; rather that you shouldn't when you're not already touching that package. Then

bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen

Hi, Am Dienstag, den 09.11.2021, 23:10 + schrieb Vivien Kraus: > I fixed a couple of linter errors, and applied guix style to > it. However, now the linter complains that we have the "bin" output > of glib in something that would be called "glib" and not "glib:bin"… > Should we still keep the

bug#51559: [PATCH v2] gnu: webkit: Disable SSE2 when not on x86_64.

Hi, Am Samstag, den 06.11.2021, 04:55 -0400 schrieb Mark H Weaver: > Hi Liliana, > > I have one more comment: > > Liliana Marie Prikler writes: > > @@ -241,7 +241,7 @@ (define-public webkitgtk > > (build-system cmake-build-system) > > (outputs '(

bug#51559: [PATCH v2] gnu: webkit: Disable SSE2 when not on x86_64.

* gnu/packages/webkit.scm (webkitgtk)[#:phases]: Add ‘disable-sse2’ if the current (target) system is not an x86_64 one. --- Hi Maxime, I tried conditionally disabling SSE2 on the host side, but for some reason this patch would cause a rebuild for me. Did I do something wrong?

bug#51559: [PATCH] gnu: webkitgtk: Disable SSE2 when not on x86_64.

Hi, Am Freitag, den 05.11.2021, 20:15 + schrieb Maxime Devos: > Liliana Marie Prikler schreef op vr 05-11-2021 om 21:06 [+0100]: > > * gnu/packages/webkit.scm (webkitgtk)[#:phases]: Add ‘disable- > > sse2’. > > --- > > gnu/packages/webkit.scm | 5 + > &

bug#51559: [PATCH] gnu: webkitgtk: Disable SSE2 when not on x86_64.

* gnu/packages/webkit.scm (webkitgtk)[#:phases]: Add ‘disable-sse2’. --- gnu/packages/webkit.scm | 5 + 1 file changed, 5 insertions(+) diff --git a/gnu/packages/webkit.scm b/gnu/packages/webkit.scm index e54b680855..45150e185f 100644 --- a/gnu/packages/webkit.scm +++

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

Hi, Am Donnerstag, den 04.11.2021, 19:15 -0400 schrieb Mark H Weaver: > 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

bug#51559: Webkit fails to build

Hi, Am Donnerstag, den 04.11.2021, 17:58 -0400 schrieb Mark H Weaver: > However, I ran into the same problem where programs linked to > webkitgtk failed. > > My knowledge of C++ is weak (I avoid it like the plague) but I guess > this might be because GCC 10 and GCC 7 use different versions of

bug#51559: Webkit fails to build

Hi, 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 dependants with GCC 10 on master or should we

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

Am Donnerstag, den 04.11.2021, 11:47 -0400 schrieb Leo Famulari: > 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

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

Hi, 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 relevant links: > > https://bugs.webkit.org/show_bug.cgi?id=190208 >

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

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 > had it hunch that it was a good bet. However, it would be good to > now try

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

Am Mittwoch, den 03.11.2021, 03:16 -0400 schrieb Mark H Weaver: > In the case, upstream's upstream (WebKit) is Apple, which I guess > uses some version of clang for compilation. I'm currently trying to > build WebKitGTK with clang-11, and so far it looks hopeful. It has > gotten beyond the point

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

Am Dienstag, den 02.11.2021, 13:31 -0400 schrieb Mark H Weaver: > 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

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

Am Dienstag, den 02.11.2021, 12:08 -0400 schrieb Mark H Weaver: > "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.

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

See , , and . * gnu/packages/webkit.scm (webkitgtk)[#:configure-flags]: Enable USE_SOUP2. [inputs]: Add lcms. --- Currently building this thing, but my machine is rather slow. Someone with a faster one might want

bug#51559: Webkit fails to build

Copypasta of the relevant log (/var/log/guix/drvs/pr/nl8g1ky1z3l3dfp4llh50w5qzd2qz4-webkitgtk- 2.34.1.drv.bz2): -- Checking for module 'egl' -- Found egl, version 20.2.4 -- Found EGL: /gnu/store/jf269s6clr6r57p8v5c3c1qkyra6apq2-mesa- 20.2.4/include -- Checking for module 'gl' -- Found gl,

bug#51366: Pure storage overflow warning in *GNU Emacs* buffer when emacs@27.2 is invoked

Small followup: Am Samstag, den 23.10.2021, 20:31 -0700 schrieb Calvin Heim: > > Warning Warning!!! Pure space overflow!!!Warning Warning > > (See the node Pure Storage in the Lisp manual for details.) Said node says > If Emacs will be dumped using the ‘pdump’ method (*note Building >

bug#51366: Pure storage overflow warning in *GNU Emacs* buffer when emacs@27.2 is invoked

Hi, Am Samstag, den 23.10.2021, 20:31 -0700 schrieb Calvin Heim: > In emacs@27.2, a warning appears about pure storage overflow in the > *GNU Emacs* > buffer that displays at startup. My main concern is that I'm not sure > if Emacs's garbage collection is working or not, so I have been > hesitant

bug#51258: [PATCH v3] gnu: emacs: Handle pdump filenames that contain a fingerprint

Hi, Am Samstag, den 23.10.2021, 21:00 -0400 schrieb morgan.j.sm...@outlook.com: > From: Morgan Smith > > * gnu/packages/emacs.scm (emacs) [restore-emacs-pdmp]: Change regex > to handle > filenames that have a fingerprint in them. Remove #t at the end of > the > phase. Don't bother deleting the

bug#51352: Matterbridge contained a lot of vendored code

Hi, Am Samstag, den 23.10.2021, 16:57 +0200 schrieb Denis 'GNUtoo' Carikli: > Hi, > > When I sent the patch adding matterbridge to Guix, I only notified > that I didn't know if it contained vendored code or not at the last > moment (after the patch was sent, during the discussion about it, and >

bug#48462: Corrupt, un-repairable store after power cut during upgrade

Hi Guix, Am Sonntag, den 16.05.2021, 17:59 +0900 schrieb elaexuo...@wilsonb.com: > Hey Guix, > > Recently, during in the middle of a `guix package -m > .guix/manifest.scm`, my > machine had power failure. After rebotting, I simply reran the above > and it completed without error. > > However,

bug#51258: [PATCH v2] gnu: emacs: Handle pdump filenames that contain a fingerprint

Am Dienstag, den 19.10.2021, 15:10 -0400 schrieb morgan.j.sm...@outlook.com: > From: Morgan Smith > > * gnu/packages/emacs.scm (emacs) [restore-emacs-pdmp]: Change regex > to handle filenames that have a fingerprint in them. Also remove #t > at the end of the phase. > --- > > I'm a fan of your

bug#51258: [PATCH] gnu: emacs: Handle pdump filenames that contain a fingerprint

Hi, Am Montag, den 18.10.2021, 19:50 -0400 schrieb morgan.j.sm...@outlook.com: > From: Morgan Smith > > * gnu/packages/emacs.scm (emacs) [restore-emacs-pdmp]: Add regex to > handle > filenames that have a fingerprint in them > --- > > Fixed your problem. Well it was also my problem. The

bug#51202: peek broken on foreign distro

Hi simon, Am Donnerstag, den 14.10.2021, 11:55 +0200 schrieb zimoun: > In this case, adding the package ’ffmpeg’ makes it work. Any reason > to not propagate ’ffmpeg’ here? Maybe ’gnome-shell’ could be > propagated instead but the sizes are really different: 797.2MiB vs > 2120.1MiB. The correct

bug#51183: lagrange: fribidi and harfbuzz dependencies?

Hi, Am Mittwoch, den 13.10.2021, 15:40 -0800 schrieb Christopher Howard: > Hello, the following did NOT work: > > ``` > (use-modules (guix packages)) > (use-modules (gnu packages web-browsers)) > (use-modules (gnu packages gtk)) > (use-modules (gnu packages fribidi)) > > (packages->manifest >

bug#51183: lagrange: fribidi and harfbuzz dependencies?

Hi, Am Mittwoch, den 13.10.2021, 07:22 -0800 schrieb Christopher Howard: > [...] > > According to the Lagrange github README, Lagrange should be able to > utilize the fribidi and harfbuzz software to properly display these > sorts of scripts, but it does not seem to be doing this in Guix, even >

bug#47672: [PATCH] gnu: owncloud-client: Update to 2.9.0.5150.

Am Montag, den 11.10.2021, 14:24 +0200 schrieb Daniel Meißner: > > Thanks for checking. Your workaround LGTM aside from indentation > > which I can fix. If the updater is still patched away as intended, > > I could apply it on top of this one. Did you check that as well? > > Cool, thanks, that

bug#51114: Owncloud client error message

Hi, Am Sonntag, den 10.10.2021, 10:43 +0200 schrieb Cayetano Santos: > Context: > > Using guix as a package manager under a foreign, up to date > archlinux distribution. > > Problem: > > When I install owncloud-client, and provide the log in > credentials, I get a message > > "could not

bug#50789: syncthing-gtk creates autostart file with wrong bin

Hi, Am Donnerstag, den 30.09.2021, 20:13 + schrieb John Kehayias: > ‐‐‐ Original Message ‐‐‐ > > On Thursday, September 30th, 2021 at 4:00 PM, Liliana Marie Prikler > wrote: > > > As I stated initially you could hardcode the store path to > > syncthin

bug#50789: syncthing-gtk creates autostart file with wrong bin

Hi, Am Donnerstag, den 30.09.2021, 19:29 + schrieb John Kehayias: > Hello, > > ‐‐‐ Original Message ‐‐‐ > > On Monday, September 27th, 2021 at 5:23 PM, Liliana Marie Prikler > wrote: > > > Hi, > > > > Am Montag, den 27.09.

bug#50918: "server is somewhat slow" error is more annoying than helpful

Hi, Am Donnerstag, den 30.09.2021, 15:17 + schrieb raid5atemyhomework: > So for the past several months I have been getting errors like these: > > ``` > guix substitute: warning: while fetching > https://ci.guix.gnu.org/nar/lzip/k9wmrk5m91599lk8gd4rc7h4df642qw0-curl-7.74.0 > : server is

bug#50789: syncthing-gtk creates autostart file with wrong bin

Hi, Am Montag, den 27.09.2021, 19:04 + schrieb John Kehayias: > [...] > > But back to the matter at hand. Medium to long-term I support better > Guix services for autostart, but that doesn't address the problem of > having packages run as intended by upstream, at least with reasonable >

bug#50789: syncthing-gtk creates autostart file with wrong bin

Hi John, Am Samstag, den 25.09.2021, 00:45 + schrieb John Kehayias: > [...] > > 3. Remove the ability for these types of files to be created, as > Liliana suggested. I think this is drastic though, changing the > expected behavior in programs and difficult to enforce evenly. The > point

<    1   2   3   4   5   >