bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi Ludovic, Ludovic Courtès writes: > Mark H Weaver skribis: > >>> I have added a very similar set of two patches to wip-cu-binaries, >>> branched @ ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f. >>> >>> They give the same md5sum for me as the wip-binaries branch that >>> branched off of master; so mine are at >>> http://lilypond.org/janneke/guix/20190722/ >> >> I built these, and here are the results: >> >> mhw@jojen /gnu/store/hd3lk0f08a0sq40qqa6yv1q9gbk7gxww-bootstrap-tarballs-0$ >> sha256sum * >> b5915c71ff5ea722864e1097ce1e7ed50fd68ad7544521f2dd6969173c260276 >> guile-static-stripped-2.2.4-i686-linux.tar.xz >> 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a >> linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz >> 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 >> mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz >> fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 >> mes-minimal-stripped-0.19-i686-linux.tar.xz >> 9ee954dc19db5c8d4113c73a702fd8f79f26c51024220f2617d0572c0a85e69c >> static-binaries-0-i686-linux.tar.xz >> >> Do these match what you built? > > We verified things back then: > > https://lists.gnu.org/archive/html/guix-devel/2018-12/msg00046.html > > This was on commit 4ae7dc7b9af64794081b1913740b97acd89c91bc, which is > earlier than the one you’re looking at (commit > ef809e3ac036eccc5f9c9edd8fb661d14ae15f2f, right?) Yes. However, I just noticed a more serious problem. The "independent verification" that you and I performed at commit 4ae7dc7b9af64794081b1913740b97acd89c91bc was bogus, because at that commit, %bootstrap-inputs had already been changed to use an earlier draft of the reduced binary seed, based on unverified bootstrap tarballs downloaded from lilypond.org. In order to perform a truly independent verification, we need to build the new bootstrap binaries without using the new bootstrap binaries. Otherwise our verification is circular. It seems to me that the best way to accomplish this is to backport the new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch. What do you think? Thanks, Mark
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Mark H Weaver writes: > It seems to me that the best way to accomplish this is to backport the > new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch. I called that `wip-binaries', @master from three weeks ago. -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#36977: Add OpenSubdiv library, and add as Blender dependency
On Sun, Aug 11 2019, Carlo Zancanaro wrote:
... adding it to the Blender inputs didn't cause the subdivision
modifier to work. ...
Well, it turns out I just had to add the -DWITH_OPENSUBDIV=ON
configure flag. Here's a new patch to do that!
>From 231763df5b336118dae973da9dbde362dd1c1465 Mon Sep 17 00:00:00 2001
From: Carlo Zancanaro
Date: Mon, 12 Aug 2019 20:15:11 +1000
Subject: [PATCH] gnu: blender: Add opensubdiv as an input
* gnu/packages/graphics.scm (blender)[inputs]: Add opensubdiv.
[arguments]: Add "-DWITH_OPENSUBDIV=ON" to #:configure-flags.
---
gnu/packages/graphics.scm | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gnu/packages/graphics.scm b/gnu/packages/graphics.scm
index 11ea550039..b9207f284d 100644
--- a/gnu/packages/graphics.scm
+++ b/gnu/packages/graphics.scm
@@ -147,6 +147,7 @@ architectures.")
"-DWITH_INSTALL_PORTABLE=OFF"
"-DWITH_JACK=ON"
"-DWITH_MOD_OCEANSIM=ON"
+ "-DWITH_OPENSUBDIV=ON"
"-DWITH_PYTHON_INSTALL=OFF"
(string-append "-DPYTHON_LIBRARY=python" ,python-version "m")
(string-append "-DPYTHON_LIBPATH=" (assoc-ref %build-inputs "python")
@@ -182,6 +183,7 @@ architectures.")
("libx11" ,libx11)
("openimageio" ,openimageio)
("openexr" ,openexr)
+ ("opensubdiv" ,opensubdiv)
("ilmbase" ,ilmbase)
("openjpeg" ,openjpeg)
("libjpeg" ,libjpeg)
--
2.22.0
bug#36961: Can't use microphone in ungoogled-chromium
Brian Leung writes: > When a microphone is plugged in, ungoogled-chromium fails to detect it. I have the same issue here. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
bug#37013: LyX can not find refstyle.sty
I couldn't find a way to make LyX find refstyle.
How to reproduce:
1 - Install the texlive and lyx packages
2 - Load the bug.lyx file (or any other file that makes it add
\usepackage{refstyle} to the generated TeX file).
3 - Press Ctrl+R to compile the file.
4 - You will get an error saying that refstyle.sty could not be found.
You can however use LyX to produce a .tex file, and the run pdflatex from the
terminal and it will work.
Since it loaded inputenc, the package just before refstyle, from
/gnu/store/wy5865kh09qak63rpq3v47wnxv2gj1y0-texlive-union-49435/share/texmf-dist/tex/latex/base/inputenc.sty,
and /gnu/store/wy5865kh09qak63rpq3v47wnxv2gj1y0-texlive-union-49435/ does not
contain refstyle, I think that the problem is that LyX uses the pdflatex from
this textlive-union instead of the one from the full texlive.
LyX has a reconfigure option (Tools -> Reconfigure) but it does not seem to
help.
bug.lyx
Description: application/lyx
bug#37013: LyX can not find refstyle.sty
Hi Xavier, thanks for the report! > Since it loaded inputenc, the package just before refstyle, from > /gnu/store/wy5865kh09qak63rpq3v47wnxv2gj1y0-texlive-union-49435/share/texmf-dist/tex/latex/base/inputenc.sty, > and /gnu/store/wy5865kh09qak63rpq3v47wnxv2gj1y0-texlive-union-49435/ does not > contain refstyle, I > think that the problem is that LyX uses the pdflatex from this > textlive-union instead of the one from the full texlive. The problem is that Lyx is configured to use the texlive-union that was provided during the build. It should prefer an optional TeX Live installation that the user provides. Perhaps we can make it (optionally?) look up the TeX Live tools on PATH before falling back to its texlive-union. > LyX has a reconfigure option (Tools -> Reconfigure) but it does not > seem to help. Investigating this might be a good starting point. -- Ricardo
bug#37014: Gajim blows me with Pop-Up Errors
Hello Guix! Everytime I open Gajim, I get the same follwing error in multiple pop- up windows. ***START*** ## Versions - OS: Linux - GTK+ Version: 3.24.9 - PyGObject Version: 3.28.3 - python-nbxmpp Version: 0.6.10 - Gajim Version: 1.1.3 ## Traceback ``` Traceback (most recent call last): File "/gnu/store/rpci88n5cl5bzslcv3zp6b7jag1in8xa-python-nbxmpp- 0.6.10/lib/python3.7/site-packages/nbxmpp/dispatcher_nb.py", line 502, in dispatch handler['func'](session, stanza) File "/gnu/store/ic0dxmxfj3b68q07v2nmjycirl9byizh-gajim- 1.1.3/lib/python3.7/site-packages/gajim/common/modules/mam.py", line 212, in _mam_message_received self._decryption_finished(event) File "/gnu/store/ic0dxmxfj3b68q07v2nmjycirl9byizh-gajim- 1.1.3/lib/python3.7/site-packages/gajim/common/modules/mam.py", line 290, in _decryption_finished stanza_id=stanza_id) File "/gnu/store/ic0dxmxfj3b68q07v2nmjycirl9byizh-gajim- 1.1.3/lib/python3.7/site-packages/gajim/common/logger.py", line 1370, in insert_into_logs sql, (account_id, jid_id, time_, kind) + tuple(kwargs.values())).lastrowid sqlite3.IntegrityError: UNIQUE constraint failed: logs.log_line_id ``` ## Steps to reproduce the problem ... ***END*** The multiple pop-ups can be seen at: https://share.riseup.net/#2QkqGAhP W7zvZRVbwUgPnA Thank you! Regards, RG. signature.asc Description: This is a digitally signed message part
bug#36747: Official MesCC bootstrap binaries differ from my locally built ones
Hi Janneke, Jan Nieuwenhuizen writes: > Mark H Weaver writes: > >> It seems to me that the best way to accomplish this is to backport the >> new '%bootstrap-tarballs' from 'wip-cu-binaries' to the 'master' branch. > > I called that `wip-binaries', @master from three weeks ago. Thank you, that was a good start. I found that some additional patches were needed to match the bootstrap binaries that 'core-updates' is currently based on. I ended up deleting and repushing a revised 'wip-binaries' to Savannah. It includes slightly modified versions of the two commits you had included, as well as some additional cherry-picked commits of yours to update mescc-tools and add linux-libre-headers-bootstrap-tarball, and a few of my own. I built the new bootstrap tarballs at the new 'wip-binaries', commit c67becb31c30a5cd7685f166970ac4793e3a34a9, and here's what I got: --8<---cut here---start->8--- mhw@jojen ~/guix-wip-binaries$ git describe v1.0.1-2404-gc67becb31c mhw@jojen ~/guix-wip-binaries$ ./pre-inst-env guix build --system=i686-linux bootstrap-tarballs /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0 mhw@jojen ~/guix-wip-binaries$ cd /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0 mhw@jojen /gnu/store/bg086i2qw1fn2jgbd15d9v91hyjrjsb2-bootstrap-tarballs-0$ sha256sum * 3e50c070a100b6bcf84c4bf5c868f9cd0a9fd1570f5d82fbfb78f8411959091b guile-static-stripped-2.2.4-i686-linux.tar.xz 1acd8f83e27d2fac311a5ca78e9bf11a9a1638b82469870d5c854c4e7afaa26a linux-libre-headers-stripped-4.14.67-i686-linux.tar.xz 021543d9bb6af55f39e68d69692e3cb74646ced2cad0bb9ac0047ef81e9d7330 mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz fb32090071b39fc804fb9a7fba96f0bc5eb844a0efd268fb24c42e6bfa959de0 mes-minimal-stripped-0.19-i686-linux.tar.xz c80cdd17b0a24eebdd75570ff72c4ec06e129bd702ac008186b57f6301c448e7 static-binaries-0-i686-linux.tar.xz --8<---cut here---end--->8--- All of these match what you posted here earlier except for guile-static-stripped-2.2.4. In my final commit to 'wip-binaries' I disabled the parallel build in guile-static, which I hope might make that build deterministic. Can you try "guix build --system=i686-linux bootstrap-tarballs" at the new 'wip-binaries' branch and see if you get the same results? Also, I have a question: One of the changes I made to 'wip-binaries' was to update mescc-tools to 0.5.2-0.bb062b0, to match the %bootstrap-mescc-tools that's currently being used in 'core-updates'. However, I noticed that you have also apparently built the official release of mescc-tools-0.5.2, which is on your site: http://lilypond.org/janneke/guix/20190722/mescc-tools-static-stripped-0.5.2-i686-linux.tar.xz and that this tarball is identical to the build output of the later git commit: mescc-tools-static-stripped-0.5.2-0.bb062b0-i686-linux.tar.xz. With this in mind, could we just use 0.5.2? What changed between 0.5.2 and 0.5.2-0.bb062b0, and what was the rationale for updating to bb062b0? Here's the relevant commit: commit 7cbf6f1ca268a7a179d715aaba2a451a8886ab44 Author: Jan Nieuwenhuizen Date: Fri Oct 12 08:19:53 2018 +0200 gnu: mescc-tools: Update to 0.5.2-0.bb062b0d. * gnu/packages/mes.scm (mescc-tools): Update to 0.5.2-0.bb062b0d. mescc * gnu/packages/commencement.scm (mescc-tools-boot): Stay at 0.5.2 Anyway, thanks for all of your work on this. Best, Mark
