bug#58813: can't substitute etc/teams.scm command as doc suggests
Hi Simon, Simon Tournier writes: > Hi, > > On Mon, 09 Jan 2023 at 15:52, Maxim Cournoyer > wrote: > >> It wouldn't change; patman would be hinted at briefly with a reference >> to its documentation (info '(u-boot) Patman patch manager' from the >> u-boot-documentation package) as a nice way to stay organize with >> submissions and automate a few things on top of git send-email. > > Is it possible to read online patman documentation? I am not able to > find one. It's developed as part of U-Boot and available at https://u-boot.readthedocs.io/en/latest/develop/patman.html. It's generated from the same sources as the info manual from u-boot-documentation referenced above. > Moreover, it could ease the adoption if a minimal sample of > such configuration is provided. A minimal out of the box configuration > as starter. No configuration is required other than the .patman file already checked in Guix. > On my side, if I have to do more than just click to read documentation, > then I give up. And then, if I have to parse lengthy documentation, > then it depends on my motivation but it is also possible that I give > up–the well-known RTFM trap. In other words, I am lazy. :-) The 'Patman patch manager' section is relatively compact; I read it from the comfort of Emacs ;-). There's also some alternative short text available as 'patman -H' if you are in a hurry. -- Thanks, Maxim
bug#58309: [DONE]
We've got all the reasonable good from this. Now it is just noise. Let's close it. Regards, Frank Pursel
bug#60725: guix lint thinks 2019111-0.7e76d75 is older than 20191111
Hi, Jelle Licht writes: > Maxim Cournoyer writes: > >> retitle 60725 support the special '~' character in our version parser >> thanks >> >> Jelle Licht writes: [...] >> That's not currently the case with Guix. Guix package version strings >> are documented has having the requirement to be 'monotonically >> increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than >> '43', the final release. > > I agree with your assesment, but note that my example (again) had one > "1" less, in which case Guix does the right thing :-). Ah! I failed to correctly read that version number again, eh! -- Thanks, Maxim
bug#60733: python build systems does not support cross-compilation
Hello, Here's an example: --8<---cut here---start->8--- $ guix build --target=aarch64-linux-gnu python-coverage guix build: error: gnu/packages/check.scm:1997:2: python-coverage@5.2.1: build system `python' does not support cross builds --8<---cut here---end--->8--- Python byte compiled files are not architecture dependents, so nothing is needed for them. In some cases where C extensions are used, setuptools or PEP 517 python build systems handle this transparently. So it seems like we should be able to support cross-compiling Python packages easily, which can be useful when building images containing Python packages for embedded systems via cross-compilation. Thoughts? -- Thanks, Maxim
bug#58813: can't substitute etc/teams.scm command as doc suggests
Hi, On Mon, 09 Jan 2023 at 15:52, Maxim Cournoyer wrote: > It wouldn't change; patman would be hinted at briefly with a reference > to its documentation (info '(u-boot) Patman patch manager' from the > u-boot-documentation package) as a nice way to stay organize with > submissions and automate a few things on top of git send-email. Is it possible to read online patman documentation? I am not able to find one. Moreover, it could ease the adoption if a minimal sample of such configuration is provided. A minimal out of the box configuration as starter. On my side, if I have to do more than just click to read documentation, then I give up. And then, if I have to parse lengthy documentation, then it depends on my motivation but it is also possible that I give up–the well-known RTFM trap. In other words, I am lazy. :-) Cheers, simon
bug#60725: guix lint thinks 2019111-0.7e76d75 is older than 20191111
Maxim Cournoyer writes: > retitle 60725 support the special '~' character in our version parser > thanks > > Jelle Licht writes: > >> Maxim Cournoyer writes: >> >>> Hi Guix, >>> >>> If you run 'guix lint emacs-enh-ruby-mode', it'll print this: >>> >>> --8<---cut here---start->8--- >>> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 2019 >>> --8<---cut here---end--->8--- >> In this particular case, 2019111 seems to have been a typo in the first >> place. (It misses out on a '1' in our package record). > > Thanks! With this typo fixed, 'guix lint' doesn't suggest a downgrade > anymore. > >> AFAIK, any sane versioning scheme would assert that 2019 > >> 2019111-anything. > > That's not currently the case with Guix. Guix package version strings > are documented has having the requirement to be 'monotonically > increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than > '43', the final release. I agree with your assesment, but note that my example (again) had one "1" less, in which case Guix does the right thing :-). > > I'll keep this bug open (and retitle it), because implementing ~ would > be useful (GNOME makes use of that scheme, and it's understood by rpm, > dpkg, pkg-config, etc.). Fixing our versioning code so "123" > "123-alpha2" will also bring us (more) in line with Semantic Versioning. - Jelle
bug#60725: guix lint thinks 2019111-0.7e76d75 is older than 20191111
retitle 60725 support the special '~' character in our version parser thanks Jelle Licht writes: > Maxim Cournoyer writes: > >> Hi Guix, >> >> If you run 'guix lint emacs-enh-ruby-mode', it'll print this: >> >> --8<---cut here---start->8--- >> emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 2019 >> --8<---cut here---end--->8--- > In this particular case, 2019111 seems to have been a typo in the first > place. (It misses out on a '1' in our package record). Thanks! With this typo fixed, 'guix lint' doesn't suggest a downgrade anymore. > AFAIK, any sane versioning scheme would assert that 2019 > > 2019111-anything. That's not currently the case with Guix. Guix package version strings are documented has having the requirement to be 'monotonically increasing', so '43.rc3' as used by GNOME is seen by Guix as newer than '43', the final release. I'll keep this bug open (and retitle it), because implementing ~ would be useful (GNOME makes use of that scheme, and it's understood by rpm, dpkg, pkg-config, etc.). -- Thanks, Maxim
bug#60725: guix lint thinks 2019111-0.7e76d75 is older than 20191111
Maxim Cournoyer writes: > Hi Guix, > > If you run 'guix lint emacs-enh-ruby-mode', it'll print this: > > --8<---cut here---start->8--- > emacs-enh-ruby-mode@2019111-0.7e76d75: can be upgraded to 2019 > --8<---cut here---end--->8--- In this particular case, 2019111 seems to have been a typo in the first place. (It misses out on a '1' in our package record). AFAIK, any sane versioning scheme would assert that 2019 > 2019111-anything.
