Re: default tar format for "make dist" and patch file length

[Vagrant Cascadian]

On 2021-11-17, Vagrant Cascadian wrote:
> On 2021-11-17, Ludovic Courtès wrote:
>> Vagrant Cascadian  skribis:
>>
>>> Ideally, "guix lint" would be run and issues fixed before applying
>>> patches ... !
...
>>> Is it worth adding an inexpensive check to etc/git/pre-push that also
>>> checks for file-length and fails to push due to this issue potentially
>>> breaking "make dist"?
...
> This basically mimics the check that guix-lint does:
>
> for p in $(find gnu/packages/patches -type f ) ; do
>   if [ "$(echo guix-2.0.0rc3-1-1234567890/${p} | wc -c)" -ge "99" ]
>   then
> echo $p
> exit 1
>   fi
> done
>
> Would something like that be cheap enough to consider adding to
> etc/git/pre-push? Are "find" and "wc" reasonable dependencies to assume
> they are available?
>
> Obviously, have to wait until they are all fixed, some of which probably
> require going through core-updates... or start with a more conservative
> but still useful length-check.

Another strategy would be to reduce the overly cautious lint check:

diff --git a/guix/lint.scm b/guix/lint.scm
index ac2e7b3841..e795c466b1 100644
--- a/guix/lint.scm
+++ b/guix/lint.scm
@@ -957,7 +957,7 @@ (define (starts-with-package-name? file-name)

  ;; Check whether we're reaching tar's maximum file name length.
  (let ((prefix (string-length (%distro-directory)))
-   (margin (string-length "guix-2.0.0rc3-1-1234567890/"))
+   (margin (string-length "guix-2.0.0rc3-1-12345678/"))
(max99))
(filter-map (match-lambda
  ((? string? patch)


That leaves only two packages on master in violation of the lint check,
and those are both updatable directly on master, and "make dist" still
works with those two packages as they are, in my experience.

I think that's fairly safe to do, actually, as "make dist" on
core-updates-frozen currently produces a tarball prefixed with:

  guix-1.3.0.10380-fe257/

If guix keeps bumping it's version into the double-digits, an
rc-version, and it surpasses 9 commits, and an extra character for
the git commit hash, this still leaves considerable wiggle-room:

  guix-10.0.0rc0-123456-abcde0/
vs.
  guix-2.0.0rc3-1-12345678/

So, I guess I'm leaning towards making the guix lint check a little more
lenient.

Thoughts?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: default tar format for "make dist" and patch file length

[Vagrant Cascadian]

On 2021-11-17, Ludovic Courtès wrote:
> Vagrant Cascadian  skribis:
>
>> Ideally, "guix lint" would be run and issues fixed before applying
>> patches ... !
>
> On the bright side, that there’s just a dozen of issues on 20K packages
> suggests it’s usually run.  :-)
>
> I think we’re used to running it for new packages but not when modifying
> an existing package, which is probably when issues like that are
> introduced.

Sounds plausible.

My guess is this is triggered from folks using "git format-patch" and
dumping the files into gnu/packages/patches, which probably has a
default length that is a little too long in this case.

Another option that would help a little would be to drop the .patch
suffix, it's kind of redundant to have gnu/packages/patches/*.patch

>> Is it worth adding an inexpensive check to etc/git/pre-push that also
>> checks for file-length and fails to push due to this issue potentially
>> breaking "make dist"?
>
> Could be.

This basically mimics the check that guix-lint does:

for p in $(find gnu/packages/patches -type f ) ; do
  if [ "$(echo guix-2.0.0rc3-1-1234567890/${p} | wc -c)" -ge "99" ]
  then
echo $p
exit 1
  fi
done

Would something like that be cheap enough to consider adding to
etc/git/pre-push? Are "find" and "wc" reasonable dependencies to assume
they are available?

Obviously, have to wait until they are all fixed, some of which probably
require going through core-updates... or start with a more conservative
but still useful length-check.


>> A different angle might be to actually use a different tar format:
>>
>>   https://www.gnu.org/software/tar/manual/html_section/Formats.html
>>
>> I would guess "make dist" is using the tar "v7" format, based on the 99
>> character length limit for files. Most of the other formats have no file
>> length limit or a longer limit.
>
> Yes, we could also do that.

Struggling to figure out how to do that; seems automake is very inclined
to use the old format... anyone with sufficient auto* skills to try and
upgrade the "make dist" to pass one of the newer --format= arguments to
tar?


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Thursday 18th: ‘core-updates-frozen’ sprint!

[Ricardo Wurmus]

Ludovic Courtès  writes:

I hereby declare tomorrow, Thursday Nov. 18th, day of the 
on-line

‘core-updates-frozen’ sprint!

The idea is that you join #guix on IRC, you try to build your 
system or
profile from ‘core-updates-frozen’, and you report (and fix!) 
any issues
you may have, in the warmth of a collective of friendly human 
beings all

sharing the same goal and helping each other.


I’ll be there!

To give everyone a head start: we have some annoying errors:

1) 
/gnu/store/aw65rwl2c50ckwghafv0p98hpg4wqvxm-vigra-1.11.1-0.9b514fa.drv 
has a bunch of test failures; this blocks libreoffice.  Looks like 
this and was caused by the most recent boost upgrade:


--8<---cut here---start->8---
Boost.Python.ArgumentError: Python argument types in
   vigra.vigranumpycore.constructArrayFromAxistags(type, tuple, 
   numpy.dtype[float32], AxisTags, bool)

did not match C++ signature:
   constructArrayFromAxistags(boost::python::api::object, 
   vigra::ArrayVector >, NPY_TYPES, 
   vigra::AxisTags, bool)

--8<---cut here---end--->8---


2) python-notebook has failing tests.  Same for a more recent 
version (6.4.3).  The failing tests *all* relate to deleting files 
with send2trash.  Upgrading send2trash does not help.  These tests 
also fail outside the build container environment.  The errors 
look like this:


--8<---cut here---start->8---
notebook-6.4.3/notebook/services/contents/manager.py:279: in 
delete

   self.delete_file(path)
notebook-6.4.3/notebook/services/contents/filemanager.py:533: in 
delete_file

   send2trash(os_path)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

path = 
'/tmp/guix-build-python-notebook-6.4.3.drv-0/tmpkwgdpuk_/Untitled.ipynb'


   def send2trash(path):
   try:
   f = Gio.File.new_for_path(path)
   f.trash(cancellable=None)
   except GObject.GError as e:
   if e.code == Gio.IOErrorEnum.NOT_SUPPORTED:
   # We get here if we can't create a trash directory 
   on the same
   # device. I don't know if other errors can result 
   in NOT_SUPPORTED.

   raise TrashPermissionError('')

  raise OSError(e.message)
E   OSError: Error trashing file 
/tmp/guix-build-python-notebook-6.4.3.drv-0/tmpkwgdpuk_/Untitled.ipynb: 
No such file or directory

--8<---cut here---end--->8---


3) Building Gnome systems fails because of a package conflict. 
Commit 781f475bbac4e73848f68cb9f420a7283ec17c16 is the direct 
cause; different variants of at-spi2-atk end up in the same 
profile.



Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great 
to have

that branch finally merged in ‘master’ by then?


Yes!

--
Ricardo

Thursday 18th: ‘core-updates-frozen’ sprint!

[Ludovic Courtès]

Hello Guix!

I hereby declare tomorrow, Thursday Nov. 18th, day of the on-line
‘core-updates-frozen’ sprint!

The idea is that you join #guix on IRC, you try to build your system or
profile from ‘core-updates-frozen’, and you report (and fix!) any issues
you may have, in the warmth of a collective of friendly human beings all
sharing the same goal and helping each other.

Nov. 23th will mark Guix’s 9th birthday.  Wouldn’t it be great to have
that branch finally merged in ‘master’ by then?

See you on Thursday!  :-)

Ludo’.

Re: Recommend order for package fields?

[zimoun]

Hi,

On Wed, 17 Nov 2021 at 12:18, Ludovic Courtès  wrote:

> I don’t think so; examples in the manual, ‘guix import’, etc. are
> already mostly consistent.

>From my point of view, an explicit recommendation is always better
than an implicit one.  If it is already consistent and defacto
ordering, it costs nothing to write down such as a recommendation and
it helps, IMHO.

(On a side note, IMHO, similar issues with packages sorted or not
depending on the phase of the Moon, mostly, or with inputs sorted or
not depending on the phase of the Moon, mostly. ;-))


> > Especially when there is probably some issues with the semantic, for
> > instance, compare [1] corner cases:
>
> It’s not a corner case, it’s lexical scoping.  :-)

Thanks for explaining. :-)  Let rephrase: compare different behaviours
[1] depending on lexical scope which is odd in the framework of
"declarative".  Anyway, your point is: it is a feature, not an issue,
IIUC.


> > If yes, why not add a checker for “guix lint” for warning that?  And
> > obviously, it could be nice to have an automatic tool for formatting;
> > something similar as etc/indent-code.el for ordering packages. ;-)
>
> I think ‘guix style’ should eventually be improved to replace
> etc/indent-code.el.  We could augment it with specific stylers, such as
> alphabetically sorting inputs.

Ah yes I have forgotten about "guix style".  :-)


Cheers,
simon

Re: Guix services, logging, and log rotation

[Ludovic Courtès]

Hi,

Katherine Cox-Buday  skribis:

> In the manual, SS10.8.3, it says:
>
>> (usually, services that produce log files already take care of that)
>
> I found an excellent example in =hpcguix-web-service-type=. It looks like you 
> can achieve this by extending the =rottlog-service-type=?

Yes (info "(guix) Log Rotation").

> However, I noticed not all services allow users to specify where log files 
> go, or setup log rotation. E.g.:
>
> #+BEGIN_SRC scheme
> (define syncthing-service-type
>   (service-type (name 'syncthing)
> (extensions (list (service-extension 
> shepherd-root-service-type
>  
> syncthing-shepherd-service)))
> (description
>  "Run @uref{https://github.com/syncthing/syncthing, Syncthing}
> decentralized continuous file system synchronization.")))
> #+END_SRC
>
> Are these bugs?
>
> Why don't all services allow you to specify where logs go?

I think these are omissions rather than bugs.  But really, each daemon
has its own way of dealing with logging: some write to syslog (in which
case we don’t need to add a new log rotation rule), some just write to
stderr (like hpcguix-web, and in this case you need to pass #:log-file
to ‘make-forkexec-constructor’), some write to custom log files that may
or may not be configurable.

I think it’s nice in general for services to provide log rotation
entries, especially when they’re likely to produce verbose logs.

HTH,
Ludo’.

Re: default tar format for "make dist" and patch file length

[Ludovic Courtès]

Vagrant Cascadian  skribis:

> Ideally, "guix lint" would be run and issues fixed before applying
> patches ... !

On the bright side, that there’s just a dozen of issues on 20K packages
suggests it’s usually run.  :-)

I think we’re used to running it for new packages but not when modifying
an existing package, which is probably when issues like that are
introduced.

> Is it worth adding an inexpensive check to etc/git/pre-push that also
> checks for file-length and fails to push due to this issue potentially
> breaking "make dist"?

Could be.

> A different angle might be to actually use a different tar format:
>
>   https://www.gnu.org/software/tar/manual/html_section/Formats.html
>
> I would guess "make dist" is using the tar "v7" format, based on the 99
> character length limit for files. Most of the other formats have no file
> length limit or a longer limit.

Yes, we could also do that.

Thanks,
Ludo’.

Re: Recommend order for package fields?

[Ludovic Courtès]

Hi,

zimoun  skribis:

> On Sun, 07 Nov 2021 at 13:40, Tobias Geerinckx-Rice via Guix-patches via 
>  wrote:
>
>> So the de-facto ordering of common fields is something like:
>>
>> name
>> version
>> source
>> build-system
>> outputs ; a bit inconsistent, yes, and sometimes put after *inputs
>> arguments ; to the build-system
>> native-inputs, inputs, propagated-inputs
>> metadata: synopsis, description, home-page, properties, license…
>>
>> There's some minor variation in where to put inputs, but 
>> (build-system trivial-build-system) definitely belongs here, above 
>> arguments, no matter what.
>
> Does it make sense to add this ordering advice in the manual?  Somewhere
> under section “Contributing”.

I don’t think so; examples in the manual, ‘guix import’, etc. are
already mostly consistent.

> Especially when there is probably some issues with the semantic, for
> instance, compare [1] corner cases:

It’s not a corner case, it’s lexical scoping.  :-)

> If yes, why not add a checker for “guix lint” for warning that?  And
> obviously, it could be nice to have an automatic tool for formatting;
> something similar as etc/indent-code.el for ordering packages. ;-)

I think ‘guix style’ should eventually be improved to replace
etc/indent-code.el.  We could augment it with specific stylers, such as
alphabetically sorting inputs.

Thanks,
Ludo’.

Re: Recommend order for package fields?

[Ludovic Courtès]

Hi,

Katherine Cox-Buday  skribis:

> zimoun  writes:
>
>> And obviously, it could be nice to have an automatic tool for formatting; > 
>> something similar as etc/indent-code.el for ordering packages. ;-)
>
> And cleaning up unused imports too! Does such a thing exist for Guile in 
> general?

Unfortunately no.

Ludo’.

Re: broken "make dist" on core-updates-frozen

[Ludovic Courtès]

Hi!

Vagrant Cascadian  skribis:

> I've now pushed to core-updates-frozen:
>
>   
> https://git.savannah.gnu.org/cgit/guix.git/commit/?h=core-updates-frozen=6cdf4e5bf230fdbe17e592c2ec74fb34dba70eb5

Thanks!

>> I'll also make a plea to create a "make dist" job on ci.guix.gnu.org
>> soon, to catch these things earlier, as issues like this could block
>> making a release!
>
> Still think this would be a great idea! :)

Yes.  Note also that ‘guix lint -c patch-file-names’ also reports these:

--8<---cut here---start->8---
$ LANGUAGE= guix lint -c patch-file-names |grep "too long"
gnu/packages/admin.scm:2672:2: debops@1.1.0: 
debops-constants-for-external-program-names.patch: file name is too long
gnu/packages/astronomy.scm:768:2: xplanet@1.3.1: 
xplanet-1.3.1-libdisplay_DisplayOutput.cpp.patch: file name is too long
gnu/packages/astronomy.scm:768:2: xplanet@1.3.1: 
xplanet-1.3.1-xpUtil-Add2017LeapSecond.cpp.patch: file name is too long
gnu/packages/geo.scm:311:2: libgeotiff@1.5.1: 
libgeotiff-adapt-test-script-for-proj-6.2.patch: file name is too long
gnu/packages/glib.scm:478:2: gobject-introspection@1.62.0: 
gobject-introspection-absolute-shlib-path.patch: file name is too long
checking go-github-com-google-gmail-oauth2-tools-go-sendgmail@0.0.0-0.e322915 
[patch-file-names]..gnu/packages/java.scm:13120:2: java-apache-ivy@2.4.0: 
java-apache-ivy-port-to-latest-bouncycastle.patch: file name is too long
gnu/packages/java.scm:8926:2: 
java-tunnelvisionlabs-antlr4-runtime-annotations@4.7.4: 
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is too long
gnu/packages/java.scm:9040:2: java-tunnelvisionlabs-antlr4@4.7.4: 
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is too long
gnu/packages/java.scm:9032:2: java-tunnelvisionlabs-antlr4-runtime@4.7.4: 
java-tunnelvisionlabs-antlr-code-too-large.patch: file name is too long
gnu/packages/kde-frameworks.scm:3419:2: plasma-framework@5.70.1: 
plasma-framework-fix-KF5PlasmaMacros.cmake.patch: file name is too long
gnu/packages/llvm.scm:98:2: clang-runtime@3.9.1: 
clang-runtime-3.9-libsanitizer-mode-field.patch: file name is too long
gnu/packages/llvm.scm:98:2: clang-runtime@3.7.1: 
clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too long
gnu/packages/llvm.scm:98:2: clang-runtime@3.8.1: 
clang-runtime-3.8-libsanitizer-mode-field.patch: file name is too long
gnu/packages/llvm.scm:851:4: clang-runtime@3.5.2: 
clang-runtime-3.5-libsanitizer-mode-field.patch: file name is too long
$ guix describe
Generacio 194   Nov 07 2021 23:40:30(nuna)
  guix bd41e59
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: bd41e590dd24e54797fb8b6854c244efd4d12df5
--8<---cut here---end--->8---

It’s conservative so maybe not all these are problematic for “make
dist” (yet), but they’re worth fixing.

Ludo’.

Re: Replacing polkit by polkit-duktape on core-updates-frozen ?

[Ludovic Courtès]

Hi,

Thiago Jung Bauermann  skribis:

> Em quinta-feira, 11 de novembro de 2021, às 15:23:37 -03, Maxim Cournoyer 
> escreveu:
>> Hello Guix!
>> 
>> I've finally merged the core-updates-frozen-batched-changes to
>> core-updates-frozen. 
>
> Hooray!
>
>> One thing we could do in the meantime is to replace our polkit package
>> with polkit-duktape, which uses an (unmerged) patch to build polkit
>> against duktape rather than mozjs [1].  The patch seems to have garnered
>> some attention recently.  This would enable to build GTK and parts of
>> GNOME without rust, I believe.
>
> I’d suggest replacing polkit with polkit-duktape only for non-x86_64 
> architectures. What do you think?¨

Yes, that seems like the most reasonable option.

Thanks, Maxim!

Ludo’.

Re: Unable to define shebang for guix shell file

[Ludovic Courtès]

Hi,

Jacob Hrbek  skribis:

> Doesn't seem to work on `busybox sh` for me (I am not aware of better way to 
> replicate POSIX environment on GNU Guix):

Note that you’re running /usr/bin/env, which has nothing to do with
Busybox.

> kreyren@leonid ~$ guix shell busybox -- busybox sh
> ...
> ~ $ cat test.sh 
>
> #!/usr/bin/env -S guix shell --
> (use-modules
>   (guix channels))
>
> (list (channel
> (name 'guix)
> (url "https://git.savannah.gnu.org/git/guix.git;)
> (commit
>   "f1bfd9f1948a5ff336d737c0614b9a30c2bb3097")
> (introduction
>   (make-channel-introduction
> "9edb3f66fd807b096b48283debdcddccfea34bad"
> (openpgp-fingerprint
>   "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA")
>
> (specifications->manifest
>   (list "emacs@27.2"
>   "emacs-treemacs"
>   "emacs-evil"))
> ~ $ ./test.sh 
>
> guix shell: warning: no packages specified; creating an empty environment
> guix shell: warning: no packages specified; creating an empty environment

It’s working as expected: ‘guix shell’ has zero arguments so it creates
an empty environment.  Additionally, the shebang does not specify an
interpreter.

The example I gave at  goes like
this:

--8<---cut here---start->8---
$ cat t.sh
#!/usr/bin/env -S guix shell hello bash -- sh
type -P hello
hello
--8<---cut here---end--->8---

HTH!

Ludo’.

Re: [VULN 0/4] Hurd vulnerability details

[Ludovic Courtès]

Hi Samuel, Sergey, & all,

Samuel Thibault  skribis:

> Ludovic Courtès, le mar. 09 nov. 2021 18:19:03 +0100, a ecrit:
>> Am I right that the fixes have not been applied yet in the upstream
>> repository?
>
> That's right. That's still waiting for the copyright assignment.

How about making it the first contribution without FSF copyright
assignment?

The delay we observe here might be an outlier in FSF assignment
processing times, but regardless, it’s a good illustration of what a
project can lose by waiting for this long.

Thanks,
Ludo’.