[core-updates-frozen] Haskell for i686-linux: report

[zimoun]

Hi,

All related Haskell packages for both x86_64 and i686 in
core-updates-frozen are not blockers for the merge. \o/


After some Cuirass monitoring and restarted some unexpected failures,
the situation for ghc-* on i686-linux is the same as the one from
current master.

Two packages are broken in core-updates-frozen and not in master:

 1. ghc-ncurses
https://ci.guix.gnu.org/build/1858160/details

 2. ghc-lukko
https://ci.guix.gnu.org/build/1858215/details

Therefore, ’scroll’ (because #1) and ’ganeti’ (because #2) are also
broken.


These test suite failures require some investigations.  Many other ghc-*
packages too:

 - ghc-sha
 - ghc-validty
 - ghc-bloomfilter
 - ghc-tar
 - ghc-llvm-hs
 - ghc-lucid

https://ci.guix.gnu.org/search?query=spec%3Acore-updates-frozen+system%3Ai686-linux+status%3Afailed+ghc


Last, note that for x86_64 in core-updates-frozen, ghc-ncurses is also
broken:

https://ci.guix.gnu.org/build/1779259/details


Let merge core-updates-frozen!


Cheers,
simon

Reverse the naming of store items?

[Jacob Hrbek]

Currently we use 
/gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv for 
store items which are painful to navigate from CLI using bash's auto-completion 
as the first letter doesn't correspond to the package name which usually 
requires doing `ls /gnu/store | grep emacs` and then copy pasting the path to 
work with the store items.

Would it break anything if we changed the metadata order like: 
/gnu/store/emacs-ert-runner-0.8.0-zzz16sfz4jxsdvf8j29rkd46psrc6dpj.drv ?

-- Jacob "Kreyren" Hrbek

Sent with ProtonMail Secure Email.

publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: Reverse the naming of store items?

[Kaelyn]

On Saturday, December 4th, 2021 at 7:04 AM, Jacob Hrbek 
 wrote:

> Currently we use 
> /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv for 
> store items which are painful to navigate from CLI using bash's 
> auto-completion as the first letter doesn't correspond to the package name 
> which usually requires doing `ls /gnu/store | grep emacs` and then copy 
> pasting the path to work with the store items.
>
While I agree the store paths are a pain to work with from the CLI and could 
make CLI interactions a bit easier, I don't think reversing the name of the 
store items willresolve the issue of knowing the correct package path. 
Specifically, as package dependencies and derivations change over time, the 
hash changes without the package name or version changing. For example, on a 
computer I switched to GuixSD 3 or 4 months ago currently has 25 different 
hashes for mesa 20.2.4 (as seen from "ls -d /gnu/store/*mesa-20.2.4") and three 
more for mesa 21.2.5 from switching to core-updates-frozen. So using the latter 
as example, "ls -d /gnu/store/*mesa-21.2.5" currently yields:

/gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/
/gnu/store/ibcvamhixj4gnxbimgzgb7hga01wa7fw-mesa-21.2.5/
/gnu/store/yai19kghj02lkp8g5rjh28qwyp3i7ik4-mesa-21.2.5/

Reversing the names won't solve the issue of which is the correct/current 
version. Following the same example, "guix build -n mesa" prints out the path 
corresponding to the current generation of "guix pull":

25.2 MB would be downloaded:
   /gnu/store/irq1fkfd4cg78qscycjzxy1nzf0n8j9m-mesa-21.2.5-bin
   /gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5

(The message about the downloads is because the "*-bin" output isn't currently 
in my /gnu/store.)

In the simplest cases picking any one of the three could work, though even then 
there could be library version conflicts if the picked version uses 
older/different libs than what your environment has (for mesa, that could be 
VDPAU_DRIVER_PATH pointing to a directory with incompatible modules; for 
python, that could be PYTHONPATH referring to the wrong python site directory 
such as "~/.guix-profile/lib/python3.8/site-packages"). In this case, because I 
also have wine installed, one of the three mesa-21.2.5 directories is not even 
the same architecture as the others:

$ file /gnu/store/*mesa-21.2.5/lib/libGL.so.1.2.0
/gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not 
stripped
/gnu/store/ibcvamhixj4gnxbimgzgb7hga01wa7fw-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, 
not stripped
/gnu/store/yai19kghj02lkp8g5rjh28qwyp3i7ik4-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not 
stripped

That isn't to say I disagree with reversing the naming or other improvements to 
the CLI experience, because I do agree it could use some QoL polish. I only 
wanted to chime in about the complexities of providing better integrations.

Cheers,
Kaelyn

> Would it break anything if we changed the metadata order like: 
> /gnu/store/emacs-ert-runner-0.8.0-zzz16sfz4jxsdvf8j29rkd46psrc6dpj.drv ?
>
> -- Jacob "Kreyren" Hrbek
>
> Sent with ProtonMail Secure Email.

Re: Reverse the naming of store items?

[Vagrant Cascadian]

On 2021-12-04, Jacob Hrbek wrote:
> Currently we use
> /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv
> for store items which are painful to navigate from CLI using bash's
> auto-completion as the first letter doesn't correspond to the package
> name which usually requires doing `ls /gnu/store | grep emacs` and
> then copy pasting the path to work with the store items.

I would welcome changes like this, although the last time I brought it
up, it was mentioned that there was some sort of optimization done that
took advantage of the first N characters being a fixed length...

Some workarounds:

* make a symlink farm somewhere else that pointed to all the store items

* write a fuse filesystem that reorders the paths

* write an emacs mode that allows you to browse the tree with a
  different view of the paths


> Would it break anything if we changed the metadata order like:
> /gnu/store/emacs-ert-runner-0.8.0-zzz16sfz4jxsdvf8j29rkd46psrc6dpj.drv
> ?

It would trigger a world-rebuild event, as everything references paths
by the existing names...


While we're on the topic of such massive changes, I'm also partial to
splitting into subdirs, for the cost of one extra character, you could
have:

  /gnu/store/z/zz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv
instead of:
  /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv

This might provide improved performance on some filesystems (e.g. ext4
fsck uses huge amounts of memory with very large numbers of files in a
single directory), and would potentially allow to split the store across
multiple filesystems... although maybe that would be difficult to
actually do.


Though... my guess is such core changes just will not happen unless
there is a strongly compelling reason to do so as it would be a very
expensive transition.


live well,
  vagrant


signature.asc
Description: PGP signature

bug#52284: Partially unifying packages and inferior packages

[Maxime Devos]

X-Debbugs-CC: guix-devel@gnu.org

Hi guix,

There have been some bug reports with as root cause that inferior packages 
aren't
packages. I think that root cause is a bug. To resolve this, there was some 
talk on
using GOOP classes, or define-gexp-compiler-style polymorphism for 
package-native-inputs
etc., but these come with a complexity and time cost.

At the end of this e-mail, there is some untested code for turning an inferior
package into an equivalent package. If it's properly integrated into (guix 
inferior),
we could mostly do away with the inferior-package?/package? distinction,
by letting lookup-inferior-package and the like return ‘proper’ packages, albeit
with a weird build system and ignoring inheritance.

To be clear, I won't be working on this, but the idea seemed to nice to not 
send it.

Greetings,
Maxime

(define inferior-package-build-system
  (build-system
(name 'inferior)
(description "Build things via an inferior")
(lower lower)))

(define* (lower name #:key inferior-package system target #:allow-other-keys)
  (bag ;; TODO(?): package transformations using bags won't work!
(name name) ; ignored
(system system) ; ignored
(target target) ; ignored
(arguments '()) ; ignored
(build (lambda _
 (inferior-package->derivation inferior-package system #:target 
target)

(define (inferior-inputs->inputs inferior-inputs)
  (map (match-lamda
 ((label inf . rest)
  `(,label ,(inferior-package->package inf) ,@rest)))
   inferior-inputs))

(define (inferior-package->package inf)
  ;; TODO: somehow make sure no inheritance happens on this package
  (package
(name (inferior-package-name inf))
(version (inferior-package-version inf))
(replacement (and=> (inferior-package-replacement inf) 
inferior-package->package))
(source #f) ; TODO
(build-system inferior-package-build-system)
(arguments `(#:inferior-package ,inf))
(synopsis (inferior-package-synopsis inf))
    (description (inferior-package-description inf))
(home-page (inferior-package-home-page inf))
(location (inferior-package-location inf))
(inputs (map inferior-inputs->inputs (inferior-package-inputs inf)))
(native-inputs (map inferior-inputs->inputs (inferior-package-native-inputs 
inf)))
(propagated-inputs (map inferior-inputs->inputs 
(inferior-package-propagated-inputs inf)))
(transitive-propagated-inputs (map inferior-inputs->inputs 
(inferior-package-transitive-propagated-inputs inf)))
(native-search-paths (propagated-package-native-search-paths inf))
(search-paths (propagated-package-search-paths inf))
(license #f)) ; TODO

Re: Reverse the naming of store items?

[Mark H Weaver]

Hi Jacob,

Jacob Hrbek  writes:

> Currently we use
> /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv
> for store items which are painful to navigate from CLI using bash's
> auto-completion as the first letter doesn't correspond to the package
> name which usually requires doing `ls /gnu/store | grep emacs` and
> then copy pasting the path to work with the store items.

As Kaelyn pointed out, there will usually be more than one store item
for the same package, so you'll need to know at least the first few
characters of the hash.  Once you have that, then you will also have the
entire store item name on your screen, at which point you can copy+paste
it into your shell session.

Suppose you don't want to copy+paste it.  If you know the first few hash
characters, then you can simply type "/gnu/store/"
and that will usually be sufficient.  For example, suppose I wish to
navigate to the store item of the emacs that I'm currently using to type
this message, which is:

  /gnu/store/9a31k78k56ky1da7n7knq3ys9hriw5sj-emacs-next-pgtk-28.0.50-1.ae18c8e

On my current system, it suffices to type:

  /gnu/store/9a31 .

If your proposal were adopted, then I would instead need to type:

  /gnu/store/emacs-ne  9 

That's 6 more keypresses than is required under the current approach.

  Regards,
Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: Software Heritage fifth anniversary event

[Maxim Cournoyer]

Hi!

Ludovic Courtès  writes:

> Hey!
>
> Maxim Cournoyer  skribis:
>
>> Thank you for sharing the slides, they were interesting/entertaining.  I
>> note that they were written prior to 'guix shell' :-).
>
> I thought I’d rather leave ‘guix environment’ in there as someone
> downloading 1.3.0 won’t have ‘guix shell’.
>
> Likewise, I recently gave a packaging tutorial and I was extremely
> frustrated that I had to teach things `(("like" ,this)).  :-)

Eh :-).  We can all forget about that syntax soon...

Thanks!

Maxim