Trailing whitespace in /etc/guix/acl
I've noticed there is some trailing whitespace in /etc/guix/acl ... some of it comes from the keys in etc/substitutes/ci.guix.gnu.org.pub ... but some of it comes from whatever code assembles /etc/guix/acl (or rather, whatever the symlink points to in /gnu/store). I noticed this by trying to add the bordeaux substitute server for the Debian package, and swear in the past I was able to do it bit-for-bit-identical... but now with the inconsistent whitespace differences, while they do not make it impossible, make it needlessly more difficult than it needs to be, having to match the extraneous whitespace exactly... I have not figured out where in the code to look for all this stray whitespace... maybe someone could take a peek? Maybe the lazy approach might be to strip all trailing whitespace from the file after generating it? Thanks! live well, vagrant signature.asc Description: PGP signature
Re: python-ledgerblue as input for electrum? (was: Core-updates, the last metres)
Hi, On Sun, Apr 23, 2023 at 04:32 PM, Vagrant Cascadian wrote: > On 2023-04-23, Guillaume Le Vaillant wrote: >> Here are a few leaf packages that don't build because of some >> failing dependencies: >> - blender is blocked by opencolorio >> - electrum is blocked by python-ledgerblue > > Hrm this is kind of an aisde, but python-ledgerblue is a plugin for > electrum to support specific hardware, which makes me wonder why it is > in one of the inputs for electrum at all... > > There is at least one other, python-btchip-python; electron-cash has > similar inputs, python-keepkey and python-trezor. > > My understanding is optional plugins in general should not be in inputs > for packages; people should add the plugins to their profile or > manifest, etc. for the hardware they plan to use... > Right, that's a good point. I had no idea about these packages before trying to fix this one, but what you point out suggests a refactoring/restructuring needed. Alas, python-ecdsa (needed for electrum) is a transient failure I think, as it built locally. John
python-ledgerblue as input for electrum? (was: Core-updates, the last metres)
On 2023-04-23, Guillaume Le Vaillant wrote: > Here are a few leaf packages that don't build because of some > failing dependencies: > - blender is blocked by opencolorio > - electrum is blocked by python-ledgerblue Hrm this is kind of an aisde, but python-ledgerblue is a plugin for electrum to support specific hardware, which makes me wonder why it is in one of the inputs for electrum at all... There is at least one other, python-btchip-python; electron-cash has similar inputs, python-keepkey and python-trezor. My understanding is optional plugins in general should not be in inputs for packages; people should add the plugins to their profile or manifest, etc. for the hardware they plan to use... live well, vagrant signature.asc Description: PGP signature
Re: Core-updates, the last metres
Hi Guillaume, On Sun, Apr 23, 2023 at 08:00 PM, Guillaume Le Vaillant wrote: > John Kehayias skribis: > >> If things continue looking good, are we planning to see the merge in >> the next few days? Any other more leaf packages anyone has noticed >> needs a fix someone should look at? > > Hi, > > Here are a few leaf packages that don't build because of some > failing dependencies: > - blender is blocked by opencolorio Not sure what is wrong here (error for a null pointer...) and it is quite out of date. Looks like it'll need more than a quick fix to update it, though admittedly I didn't try. > - electrum is blocked by python-ledgerblue python-ledgerblue doesn't have tests. Looking at an old build log it would run tests, but there was nothing. Something has changed so this errors now. Anyway, disabled, it built, as did electrum locally. Pushed as bacee2da69dc3fdc20c384bed479d7596d9234a9. > - freecad is blocked by python-pyside-2 > Didn't look much here yet, looks like part of the Python QT bindings ecosystem. Maybe someone familiar with this can see a quick fix. > I'm not sure if I'll be able to look at them before the merge, so if > someone has the time to try and fix them, please go for it. > I picked off the easy one, thanks in advance to whoever gets the tougher ones done!
Re: Core-updates, the last metres
John Kehayias skribis: > If things continue looking good, are we planning to see the merge in > the next few days? Any other more leaf packages anyone has noticed > needs a fix someone should look at? Hi, Here are a few leaf packages that don't build because of some failing dependencies: - blender is blocked by opencolorio - electrum is blocked by python-ledgerblue - freecad is blocked by python-pyside-2 I'm not sure if I'll be able to look at them before the merge, so if someone has the time to try and fix them, please go for it. signature.asc Description: PGP signature
Re: Core-updates, the last metres
Hello John, thanks for your report, and the patch work! Am Sun, Apr 23, 2023 at 06:51:27PM + schrieb John Kehayias: > If things continue looking good, are we planning to see the merge in > the next few days? Yes, the plan is to merge on Tuesday. Andreas
Re: Core-updates, the last metres
Dear Andreas and Guix,
On Sun, Apr 23, 2023 at 09:30 AM, Andreas Enge wrote:
> Hello,
>
> yesterday I updated my system to core-updates. Since I am writing this
> message now, you can deduce that it succeeded. Well, there is no reason
> you should care, but it could encourage you to do the same. :)
>
As did I! (I'm on x86_64.) And boldly late at night and everything
went smoothly (caveat/tip below). I did build all my profiles and
system beforehand so my reconfigure was just some new minor builds and
activating.
Big thanks again to you (Andreas) for really pushing this all through.
I hope our move to more feature branches will make such a job less
onerous or maybe even extinct in the near future.
> I used commands like "./pre-inst-env guix package/system ...", but this
> resulted in strange behaviour; I suppose I may have ended up with a
> mixture between old and new guix.
> I think the safest approach is to use "guix pull --commit=..." with
> a commit from core-updates, or probably just
>guix pull --commit=core-updates
> Then I would start by updating the system, followed by the user profiles.
>
I agree here; I reconfigured my system (I switched my channels.scm
over to core-updates or similar for all my channels) but forgot to
update all my user profiles. I think this is what lead to not dropping
back to lightdm after I exited my WM, though the system booted fine. I
updated my profiles and rebooted (had to use some magic keys or I was
too impatient again) and all was good.
So, I also suggest updating everything all together before doing a
restart. I think last time I had some weird stuff as well, likely
because of the deep changes from moving to core-updates.
One noticeable difference was some fonts, perhaps a different
rendering or substitutes for some graphical programs? My terminal
emulator, kitty, also decided to pick some different default font, but
looked fine when I manually specified a font. Perhaps a difference in
some default font picking somewhere in an update? I also did a manual
fc-cache -fv for good measure.
> Please tell us if there is a show-stopper for the merge!
>
None I'm aware of, other than a few others with the same weirdness
when partially upgrading it seems.
> We already received a first report:
> python-yubikey-manager does not build. It should be repaired very shortly
> after the merge (the fix is there, but would cause too many rebuilds now);
> so if you rely on it, maybe delay updating your system, or hold this one
> package back in your profile ("guix package --do-not-upgrade ... -u").
>
I have a patch set almost ready for this. I need to do some minor
polishing and try to get some ordering here. It is one of those cases
where an update needed by one package causes others to need updates
and so on. It isn't too bad, about 20 mostly trivial patches. A few
need 10s to 100s of rebuilds, and at least one (python-filelock) will
need 3000 packages rebuilt. This will get us some overdue updates for
the affected packages.
(If you use a yubikey as a gpg smartcard everything should be fine, as
that's what I'm doing. I only use python-yubikey-manager for one time
codes or card setup. Just be aware before you update, or use another
computer/device for codes if need be.)
Likely we'll want to tack on any other core python packages in need of
updates, so please feel free to let me know of those or send patches.
I'll send a bug number here once I submit the series and we can make a
quick feature branch just after the core-updates merge. We do want to
keep this quick and not let it become another huge endevor, but I'm
happy to incorporate what we can.
> As for the architectures, x86_64 looks good; i686 and powerpc64le look
> okay (or at least not much worse than on master; R does not work on
> powerpc64le, and should also be fixed shortly after the merge).
> For aarch64 it is difficult to say, since the build farm has trouble
> keeping up. We brought back a few machines, but they are churning through
> the backlog.
>
> Andreas
If things continue looking good, are we planning to see the merge in
the next few days? Any other more leaf packages anyone has noticed
needs a fix someone should look at?
Thanks everyone for your great work here!
John
WDYT of guix remove flag that is like sed -i?
hi, WDYT of a `guix remove` flag that is like sed -i that removes the package from the module it is in? It is like `sed -i` but works on guix packages/sexps themselves. For example, I as the user would be able to do the following `guix remove -i chezmoi` and it would remove the chezmoi package cleanly from gnu/packages/configuration-management.scm:31:2 If I also pass in the -r flag then it will also remove all the direct dependencies of chezmoi. Might be cool and powerful to be able to have a flag to remove dependents as well. I realize that this better serves the particular use cases of a channel like Guix 'R Us that is constantly needing to remove packages that it has upstreamed in an efficient manner. Still, this would be cool functionality to have.
Re: [PATCH 0/2] Update gfeeds to 2.2.0.
Am Sonntag, dem 23.04.2023 um 09:07 +0200 schrieb Andreas Enge:
> Hello Liliana,
>
> Am Sun, Apr 23, 2023 at 01:45:19AM +0200 schrieb Liliana Marie
> Prikler:
> > as with the recent update to Evolution, this is an update to get a
> > package into a working state again.
>
> gfeeds has python-magic as input, which fails on the soon to be
> merged core-updates. It would be interesting if you could have a look
> at this package. Thanks!
Patch is attached.
Cheers
From 7c2b2abd1b6168941a102ac30581bb607c841bd8 Mon Sep 17 00:00:00 2001
From: Liliana Marie Prikler
Date: Sun, 23 Apr 2023 15:07:39 +0200
Subject: [PATCH core-updates] gnu: python-magic: Update to 0.4.27.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* gnu/packages/patches/python-magic-python-bytecode.patch: Remove file.
* gnu/local.mk (dist_patch_DATA): Unregister it.
* gnu/packages/python-xyz.scm (python-magic): Update to 0.4.27.
[source]: Remove field.
[#:phases]: Do not invoke ‘tests.py’.
---
gnu/local.mk | 1 -
.../python-magic-python-bytecode.patch| 19 ---
gnu/packages/python-xyz.scm | 6 ++
3 files changed, 2 insertions(+), 24 deletions(-)
delete mode 100644 gnu/packages/patches/python-magic-python-bytecode.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index a2b7defe30..fcb3acd212 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1774,7 +1774,6 @@ dist_patch_DATA = \
%D%/packages/patches/python-pyflakes-test-location.patch \
%D%/packages/patches/python-flint-includes.patch \
%D%/packages/patches/python-libxml2-utf8.patch \
- %D%/packages/patches/python-magic-python-bytecode.patch \
%D%/packages/patches/python-memcached-syntax-warnings.patch \
%D%/packages/patches/python-mox3-python3.6-compat.patch \
%D%/packages/patches/python-parso-unit-tests-in-3.10.patch\
diff --git a/gnu/packages/patches/python-magic-python-bytecode.patch b/gnu/packages/patches/python-magic-python-bytecode.patch
deleted file mode 100644
index 997fb4ee5a..00
--- a/gnu/packages/patches/python-magic-python-bytecode.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-File 5.41 changed the MIME type of Python bytecode; adjust accordingly.
-
-Taken from upstream:
-
- https://github.com/ahupp/python-magic/commit/0ae7e7ceac0e80e03adc75c858bb378c0427331a
-
-diff --git a/test/test.py b/test/test.py
-index 0c4621c..e443b84 100755
a/test/test.py
-+++ b/test/test.py
-@@ -90,7 +90,7 @@ def test_mime_types(self):
- try:
- m = magic.Magic(mime=True)
- self.assert_values(m, {
--'magic._pyc_': ('application/octet-stream', 'text/x-bytecode.python'),
-+'magic._pyc_': ('application/octet-stream', 'text/x-bytecode.python', 'application/x-bytecode.python'),
- 'test.pdf': 'application/pdf',
- 'test.gz': ('application/gzip', 'application/x-gzip'),
- 'test.snappy.parquet': 'application/octet-stream',
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index c623ce3135..685e1df38f 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -16863,17 +16863,16 @@ (define-public python-textual
(define-public python-magic
(package
(name "python-magic")
-(version "0.4.24")
+(version "0.4.27")
(home-page "https://github.com/ahupp/python-magic";)
(source
(origin
(method git-fetch)
(uri (git-reference (url home-page) (commit version)))
(file-name (git-file-name name version))
- (patches (search-patches "python-magic-python-bytecode.patch"))
(sha256
(base32
- "17jalhjbfd600lzfz296m0nvgp6c7vx1mgz82jbzn8hgdzknf4w0"
+ "1x11kfn4g244fia9a7y4ly8dqv5zsxfg3l5azc54dl6gkp2bk7vx"
(build-system python-build-system)
(arguments
'(#:phases (modify-phases %standard-phases
@@ -16895,7 +16894,6 @@ (define-public python-magic
(setenv "LC_ALL" "en_US.UTF-8")
(if tests?
(with-directory-excursion "test"
-(invoke "python" "./test.py")
(invoke "python" "./libmagic_test.py"))
(format #t "test suite not run~%")))
(native-inputs
--
2.39.2
Core-updates, the last metres
Hello,
yesterday I updated my system to core-updates. Since I am writing this
message now, you can deduce that it succeeded. Well, there is no reason
you should care, but it could encourage you to do the same. :)
I used commands like "./pre-inst-env guix package/system ...", but this
resulted in strange behaviour; I suppose I may have ended up with a
mixture between old and new guix.
I think the safest approach is to use "guix pull --commit=..." with
a commit from core-updates, or probably just
guix pull --commit=core-updates
Then I would start by updating the system, followed by the user profiles.
Please tell us if there is a show-stopper for the merge!
We already received a first report:
python-yubikey-manager does not build. It should be repaired very shortly
after the merge (the fix is there, but would cause too many rebuilds now);
so if you rely on it, maybe delay updating your system, or hold this one
package back in your profile ("guix package --do-not-upgrade ... -u").
As for the architectures, x86_64 looks good; i686 and powerpc64le look
okay (or at least not much worse than on master; R does not work on
powerpc64le, and should also be fixed shortly after the merge).
For aarch64 it is difficult to say, since the build farm has trouble
keeping up. We brought back a few machines, but they are churning through
the backlog.
Andreas
Re: Latest news on core-updates
Am Fri, Apr 21, 2023 at 07:04:19PM +0200 schrieb reza.housse...@gmail.com: > Consider my praise added as well! Was there already a discussion about adding > liberapay, to at least have some monetary compensation for the hard and > necessary work done by all these volunteers? Thanks for the thanks! Well, the volunteers are volunteers; if you want to donate to Guix (so far, mainly for covering infrastructure costs and Outreachy internships), you can do so at Guix Europe or the FSF. Andreas
Re: [PATCH 0/2] Update gfeeds to 2.2.0.
Hello Liliana, Am Sun, Apr 23, 2023 at 01:45:19AM +0200 schrieb Liliana Marie Prikler: > as with the recent update to Evolution, this is an update to get a > package into a working state again. gfeeds has python-magic as input, which fails on the soon to be merged core-updates. It would be interesting if you could have a look at this package. Thanks! Andreas
