ripit/perl: use perl_cddb_get package?
Hey, so I wanted to use ripit to make backups of my audio cds, but when trying to use it at first, it said: Perl module CDDB_get not found. Needed for checking the CD-ID and retrieving the CDDB entry from freeDB.org! Please install CDDB_get from your closest CPAN mirror before trying again. Install by hand or e.g. type as root: perl -MCPAN -e 'install CDDB_get' So I obviously installed perl-cddb-get with guix, but the error message persisted, and I think installing it the way ripit asks is not the "guix-way". As I never hacked with perl and am pretty new to guix, I am unsure if I did something wrong. Is there anyone who got ripit to work or has pointers? Thanks Sam
Re: ripit/perl: use perl_cddb_get package?
Hey marc, thanks for answering. perl -E 'map say, grep -d, @INC' should provide a direcory that contains CDDB_get.pm This seems to be the problem, it returned: $ perl -E 'map say, grep -d, @INC' /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/site_perl/5.30.0/x86_64-linux-thread-multi /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/site_perl/5.30.0 /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/5.30.0/x86_64-linux-thread-multi /gnu/store/ziinjmbnq004866mwjrczsk12wf35qb8-perl-5.30.0/lib/perl5/5.30.0 But $ find /gnu/store/*perl* -iname "CDDB_get.pm" /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/CDDB_get.pm /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/CDDB_get.pm I then copied the perl script and manually pointed to the dir (use lib '/gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/';) and the error got replaced by a different one, but with the same cause (this time it was about "LWP::Simple", I tried the same trick, but apparently this module is not part of perl-http-daemon). So it seems like the problem is that this perl script package can't see the installed perl modules? I am unsure if this is a bug, thinking about opening an issue because at least without cddb_get, the package won't work. Any input is appreciated. Thanks, Sam
Re: ripit/perl: use perl_cddb_get package?
Thank you for your time, but I am afraid I have wasted it. The perl module dirs are set in a env variable in bash's files, and for that reason my fish couldn't find them. (Also the syntax isn't compatible so I you to copy them out, which is quite annoying). So in a way it's fixed now ^^" Thanks anyway! Am 9. November 2019 12:24:58 MEZ schrieb Marc Chantreux : >> This seems to be the problem, it returned: >> $ perl -E 'map say, grep -d, @INC' >> $ find /gnu/store/*perl* -iname "CDDB_get.pm" >> /gnu/store/7n8rdqbx25801ypj38bywacbicmsc2ns-perl-cddb-get-2.28/lib/perl5/site_perl/5.28.0/CDDB_get.pm >> /gnu/store/mg8qgzi0v2his2xld1zkb8x7p5lf3v6m-perl-cddb-get-2.28/lib/perl5/site_perl/5.30.0/CDDB_get.pm > >> So it seems like the problem is that this perl script package can't see the >> installed perl modules? > >yes: every module have its own store so perl don't see them >ok. i don't know enough of guix to help on it but from the perl >perspective, a module is available is in @INC which contains: > >* a built-in list of standard directories >* the list of directories provided by the $PERL5LIB env variable > (the awesome local::lib module is very helpful to manage $PERL* > variables: don't miss it) >* the list of directories hardcoded in the script using `use lib` > instruction > >if guix wants to compete with (or encapsulate) cpan tooling, it needs to >have a way to embrace the 2 most common strategies to install the >things > >* installing everything in a directory dedicated for the software > (this clear separation with the base system and other programs > makes it easy to install, remove, maintain without breaking anything > on the host... like containers does) > >* installing as much as possible in the standard directories using > system packages. > >it would be very good to reach the point when the combo >perlbrew+cpanm+local::lib (or carton) could be replaced by a guix >counterpart. this is probably the momentum i'm waiting for to replace >my perl toolchain with guix. > >for the projects providing cpanfiles, a strategy could be to provide >both a perl version and the installed modules from the perl cpanm >commands in the same store? > >also: having a plan9 experience, i would like to arg that the better way >to do that is having a single dir to bind everything we need in it. >that's basically what docker does poorly but i have no experience in >handmade linux namespaces > >> Any input is appreciated. > >i can help as "someone who knows the perl ecosystem practices" but >i don't know enough about guix. > >regards >marc > >
Boost with C++14
Hi all, When compiling my own code with gcc 8.2.0 I get "undefined reference to `boost::system::detail::generic_category_instance'" unless I use -std=c++11. Word on the net is that I need to use boost libraries compiled for C++14. 'guix edit boost' shows boost and boost-cxx14 packages. I see that other packages use the latter with (inputs `((boost ,boost-cxx14))). How do I link the C++14 variant with my code? Thanks.
Segmentation fault when running rust-cargo
I am trying to run `cargo update` (version 1.59.0) on a rust project but am encountering a segmentation fault. =2D-8<---cut here---start->8--- (gdb) run update Starting program: /gnu/store/3p1vy8lqx0fazck9gnmk0dlp6hni3zqs-profile/bin/cargo update [Thread debugging using libthread_db enabled] Using host libthread_db library "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libthread_db.so.1". Updating crates.io index Program received signal SIGSEGV, Segmentation fault. 0x77f48128 in ?? () from /gnu/store/kqcv7w297aihagjdj3pqkxd4ssdxnx4f-libgit2-1.5.1/lib/libgit2.so.1.5 (gdb) bt #0 0x77f48128 in ?? () from /gnu/store/kqcv7w297aihagjdj3pqkxd4ssdxnx4f-libgit2-1.5.1/lib/libgit2.so.1.5 #1 0x77f49db5 in git_remote_fetch () from /gnu/store/kqcv7w297aihagjdj3pqkxd4ssdxnx4f-libgit2-1.5.1/lib/libgit2.so.1.5 #2 0x559d76cc in ?? () #3 0x55726bd0 in ?? () #4 0x55724755 in ?? () #5 0x55700f04 in ?? () #6 0x55a02bd8 in ?? () #7 0x55725d15 in ?? () #8 0x559fa029 in ?? () #9 0x55961160 in ?? () #10 0x55ac74c9 in ?? () #11 0x55ac96b7 in ?? () #12 0x55955843 in ?? () #13 0x55accfb9 in ?? () #14 0x55ade54c in ?? () #15 0x55a5c3e0 in ?? () #16 0x5576fa1a in ?? () #17 0x559581e7 in ?? () #18 0x55adab1d in ?? () #19 0x55ad7bd5 in ?? () #20 0x55ad357f in ?? () #21 0x55a32573 in ?? () #22 0x55aeee56 in ?? () #23 0x55aef785 in ?? () #24 0x55681f58 in ?? () #25 0x556896bb in ?? () #26 0x5568663d in ?? () #27 0x5565b005 in ?? () #28 0x556985c3 in ?? () #29 0x556b4d79 in ?? () #30 0x55cdd5f1 in ?? () #31 0x5565fa82 in ?? () #32 0x775501f7 in __libc_start_call_main () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6 #33 0x775502ac in __libc_start_main_impl () from /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6 #34 0x5564b011 in ?? () =2D-8<---cut here---end--->8--- It seems to be caused by libgit2.so. Running with the '--offline' option will not result in a segfault (because it presumably doesn't reach out to git). =2D-8<---cut here---start->8--- linux-vdso.so.1 (0x7ffd0839) libgit2.so.1.5 => /gnu/store/kqcv7w297aihagjdj3pqkxd4ssdxnx4f-libgit2-1.5.1/lib/libgit2.so.1.5 (0x7efc84ce6000) libssh2.so.1 => /gnu/store/mnip2lqdzgdnm3asg9yf7g27bvk5kray-libssh2-1.10.0/lib/libssh2.so.1 (0x7efc8593d000) libz.so.1 => /gnu/store/slzq3zqwj75lbrg4ly51hfhbv2vhryv5-zlib-1.2.13/lib/libz.so.1 (0x7efc8591f000) libcurl.so.4 => /gnu/store/b727ryyfiz1cfdywjp8s1wmxd6lzsz8p-curl-7.85.0/lib/libcurl.so.4 (0x7efc84c53000) libssl.so.3 => /gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/lib/libssl.so.3 (0x7efc84ba7000) libcrypto.so.3 => /gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/lib/libcrypto.so.3 (0x7efc8460) libgcc_s.so.1 => /gnu/store/930nwsiysdvy2x5zv1sf6v7ym75z8ayk-gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so.1 (0x7efc85903000) libm.so.6 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so.6 (0x7efc84aca000) libc.so.6 => /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so.6 (0x7efc84404000) /gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/ld-linux-x86-64.so.2 (0x7efc85974000) libhttp_parser.so.2.9 => /gnu/store/0s8cmg8vlwr8hakdkz5zaicm5rrm3zjw-http-parser-2.9.4-1.ec8b5ee/lib/libhttp_parser.so.2.9 (0x7efc858f5000) libpcre2-8.so.0 => /gnu/store/i7f40vxcp8gi05pzcf75s3hvv8m2gv0i-pcre2-10.40/lib/libpcre2-8.so.0 (0x7efc84367000) libgcrypt.so.20 => /gnu/store/8y0pwifz8a3d7zbdfzsawa1amf4afx1s-libgcrypt-1.10.1/lib/libgcrypt.so.20 (0x7efc84224000) libnghttp2.so.14 => /gnu/store/n0xrvryfjg2yciifxb2c0ac5rx9wy0xi-nghttp2-1.49.0-lib/lib/libnghttp2.so.14 (0x7efc858c3000) libidn2.so.0 => /gnu/store/1r1azdi4hvfypnx14d01n60p4aa7g2im-libidn2-2.3.4/lib/libidn2.so.0 (0x7efc84a78000) libnettle.so.8 => /gnu/store/c2fx42ial6lr60s96xcbml5hd8vwaxq3-nettle-3.8.1/lib/libnettle.so.8 (0x7efc841d6000) libgnutls.so.30 => /gnu/store/yr4lbvdyc4dgs76yij1dw2w2z8s84af8-gnutls-3.7.7/lib/libgnutls.so.30 (0x7efc83e0) libgssapi_krb5.so.2 => /gnu/store/1i0iz5rgixyva0zy4bmaasjil2683xrn-mit-krb5-1.20/lib/libgssapi_krb5.so.2 (0x7efc84184000) libgpg-error.so.0 => /gnu/store/m9wi9hcrf7f9dm4ri32vw1jrbh1csywi-libgpg-error-1.45/lib/libgpg-error.so.0 (0x7efc85899000) libunistring.so.2 => /gnu/store/0jk7sl5xqwwdkzjpp9sxgz9z0d48a3vy-libunistring-1.0/lib/libunistring.so.2 (0x7efc83c53000) libp11-kit.so.0 => /gnu/store/vq7dxp5la2lnhsvniwv38j0ggvsmzim7-p11-kit-0.24.1/lib/libp11-kit.so.0 (0x7efc8405) libffi.so.8 => /gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-
some questions about GUIX
Dear GUIX-SD, I am interested in this initiative because it is the GNU distribution and also because there is the possibility to address some major technical problems I have with current GNU / Linux distributions. I have several questions, and I would appreciate it if you could attempt to answer some of them. * Integration with existing software distribution managers Modern languages (I use this term loosely) have developed their own cross-platform distribution mechanisms. It feels like a terrible waste of effort for GNU / Linux distributions to repackage such artefacts instead of relying on the well maintained industry standards. For example, on the JVM, Maven Central is the central point for hosting source code, binaries and documentations for individual libraries, with GPG signatures, checksums and license information. Most commercial organisations host their on mirror of Maven Central, giving them full control over which artefacts are approved for use internally. Developers of Java / Scala / etc use tools (maven, ivy, etc) to manage downloading local filesystem caches of the exact artefacts that they need (and their transitive dependencies). However, distributions such as Debian and Redhat repackage all files and make a complete mess of it. It would be far superior if the OS package manager simply had a Maven backend that populated a system-wide local filesystem maven repository. Then Java applications supported by guix could follow a basic "java application" template, and there would be no need for the OS package manager to track each individual transitive dependency. Installation of Java applications would then be trivial. I don't want to single out Java, because this is true of a large variety of other languages: Haskell (cabal), Go (built-in), Python, Perl, etc. One could even argue that Emacs ELPA falls into this category also, and that a locally hosted MELPA would make sense for locked-down machines. The result is that I tend to ignore any java, scala, haskell or go application or library from apt, and use the preferred language-specific package manager to install and manage that application. It would be really nice if this was all integrated into guix such that I had one package management interface for system wide installations. How are you planning on handling these more modern languages that manage their own dependencies? * Docker image Most GNU / Linux distributions have uploaded a base image of their OS to hub.docker.com will you be creating and uploading a similar image? I'd love to try one out. I use docker to maintain a consistent build environment (across many heterogenous devices) for many of my free software projects and it is incredibly well suited to this task. I strongly recommend docker as a way to build artefacts. With the immergence of lightweight CI build tools such as http://github.com/drone/drone/ it would be an incredible way to boost your build farm! Indeed, you wouldn't need to ask for hardware donations and could instead ask for docker worker donations (users open up an SSL connection to their hardware and you use it from an orchestrated drone). It also makes it a lot easier for users to test their packaging scripts before submitting their changes to your central repository. * Issue tracker / comm channels I see that you are using debbugs, savannah and email mailing lists as the main communication channels. This is a very traditional approach to managing a free software community. Along with a large number of other people, I have found that a single, integrated, web based approach is far easier to engage with as a user, for example github (free as in beer) or gitlab (free as in freedom, but less complete). The "pull request" concept makes it exceptionally easy to make contributions, and easy for admins to review and accept those proposed changes. Will you be continuing to use debbugs, savannah and mailing lists going forward or would you consider moving to a modern community management system like gitlab? * Custom / full install images Debian and co use an antiquated concept of CD/DVD isos for installations. The vast majority of modern users want to put either a full or a custom (where they have selected all the packages) installation image onto a USB. It is not always possible to use network installation from a minimal image due to firewall rules or connectivity issues. Something I've wanted for a long time would be the ability to create an installation image on a USB, and fill the remainder of the USB with a VFAT partition. This is remarkably hard to achieve with gparted and a fixed size installation image. -- Best regards, Sam signature.asc Description: PGP signature
Re: some questions about GUIX
Thanks Ludovic, Ludovic Courtès writes: >> * Integration with existing software distribution managers >> >> How are you planning on handling these more modern languages that >> manage their own dependencies? > > Currently, we import those languages’ dependency trees into the Guix > dependency tree, and so some additional QA (make sure tests pass, > provide adequate licensing info, descriptions and synopses, etc.) OK, I'm not entirely sure what that means for JVM / Maven Central applications but it sounds like you're doing something sane. The important thing for JVM applications is that each jar doesn't end up getting tracked as a separate entity, because that just makes it infeasible and painful to package anything through the official channels. The main problem I want to avoid is the situation where it can take longer to package a small application than it does to write it. >> * Docker image > > I don’t think there’ll be an “official” presence there, but everyone is > welcome to do it. OK, I'll watch out for one appearing. > Guix’s build daemon uses containers to perform isolated builds: > > http://www.gnu.org/software/guix/manual/html_node/Features.html Interesting. I wonder if you wouldn't benefit from a docker / drone network, just as a distribution mechanism for your own build farm. It would be a shame to expend effort on that since it is somewhat something of a solved problem (and purely a DevOps matter, not a user concern). >> * Issue tracker / comm channels >> >> Will you be continuing to use debbugs, savannah and mailing lists going >> forward or would you consider moving to a modern community management >> system like gitlab? > > I hear the appeal of GitLab and the like. However, as was recently > discussed on guix-devel, while I think we must find ways to improve our > workflows (for instance, tracking patches is becoming tricky), I don’t > see us moving to one of those web-based approaches for several reasons: > > https://lists.gnu.org/archive/html/guix-devel/2015-12/msg00429.html I've never used GitLab, but I understand that it is free software. The thread above seems to suggest that it is proprietary. Perhaps a challenge as large as GUIX itself, but I'd love to see something from GNU to genuinely compete with GitHub on a technical level and gitlab seems like the closest thing available in the free software world. -- Best regards, Sam signature.asc Description: PGP signature
Re: some questions about GUIX
Thanks Ricardo, Ricardo Wurmus writes: > I’m not sure I understand what you mean here. I have been packaging a > couple of Java things and the reliance on prebuilt jars and Maven > causes quite a few problems. This is the single most important reason > why there isn’t much of Java to be found in Guix yet. If the GUIX-SD goal is to build every package from source, then I can see why you're doing it this way. It is possible to achieve this noble goal, but you are embarking on an absolutely *gigantic* mission. > Building a full non-trivial Java application from source without > resorting to some black box jars along the way is very difficult. I’m > still working on slowly packaging the dependencies of log4j, one jar > at a time, ... and I even forgot why I’m working on log4j because the > dependency graph for an arbitrary Java package is overwhelmingly > large. I'm not sure I would refer to Maven Central binaries as "black box". The jars on Maven Central are digitally signed by the distributors and the source jars are available beside them, with meta data such as license and homepages available in the pom file. It should not be difficult to set up Maven and Ivy to only use a GUIX-hosted repository (many organisations do this), or a local repository, but it will involve an incredible amount of effort to actually *rebuild* everything, as you are discovering. What practical benefit does rebuilding on the GUIX farm actually bring? Is there a claim that the binary build can be traced directly to a "trusted" machine and source code? In the Scala community, there is an attempt to rebuild a range of free software projects as part of the continuous integration of the scala compiler itself: https://github.com/scala/community-builds It may be worthwhile collaborating with the authors in order to avoid duplicating efforts. > We are building library for library as individual packages in Guix. We > certainly won’t bundle prebuilt jars from Maven if it can be avoided > at all. As a Java / Scala developer, I consider the maven / ivy dependency tracking to be the environment where I define the exact and definitive versions of dependencies that I require and I would not be happy depending on the GUIX-SD jars. Although, I would not object to using GUIX-SD jars as a user, if the installation was easier than self-managed and I did not experience and bugs as a result of the re-packaging. I would be very interested if you had a way of integrating with Maven Central artefacts in order to install applications, as it would make it significantly easier for me, as a developer, to produce packages for GUIX-SD. -- Best regards, Sam signature.asc Description: PGP signature
Re: some questions about GUIX
Hi Ricardo, I have a few more questions about your proposed jar packaging. Ricardo Wurmus writes: > We are building library for library as individual packages in Guix. We > certainly won’t bundle prebuilt jars from Maven if it can be avoided > at all. Does this mean that you have a GUIX package for every jar? If so, can you have multiple versions of the same jar installed at the same time? Support for multiple versions of a library will be necessary as it is not always a simple case of bumping the version to use a library: many libraries introduce breaking changes at both source and binary level. Will you be using the same version names as the official upstream binaries? I strongly recommend against doing this. The convention in corporate environments is that rebuilds of jars incur a postfix to their version. E.g. a rebuild of guava 18.0 (even with no changes to the sources) would be 18.0-guix1. Of course, there is no way for you to know that jars are not being loaded by name at runtime through the classloader, so you introduce further opportunity for bugs here. -- Best regards, Sam signature.asc Description: PGP signature
Re: some questions about GUIX
Leo Famulari writes: > Our goal is to build everything from source. OK, that helps me to understand why you are doing things the way you are doing it. Indeed, this means that your efforts are incompatible with my original hope: that guix would make packaging of Java applications significantly easier. As a Java / Scala developer, I avoid all repackaged jars unless they contain a bug or security fix. I don't see why I should trust a package manager (and their machines), who are self-confessed non-experts, more than the original author of that library, who has GPG signed their artefacts and made their source code available. > I'm not a Java programmer so I can't get very deep into the specifics. I > have tried to package some Java software, though. In that case, I strongly encourage you and other GUIX contributors to halt all Java packaging efforts immediately. Please dedicate time to scope out what you're planning to do: have discussions with experienced Java developers. Find a common ground so that the jar artefact packaging is compatible with developer needs. It is most important that this is done properly from the beginning, because the longer you go down this route, the more time you will have ultimately wasted, and the harder it will be to dig yourself out of it. From what I've seen, you're solving a problem at the expense of excluding everybody who would use it. One thing I can see that would be compatible would be if you rebuilt everything as Maven artefacts, using a postfix to the versions such as -guix, and when packages are installed they get placed into exactly the location one would expect a maven artefact to go. This would allow the "GUIX build" world to co-exist with the developer's "Maven Central" world. Build tool plugins may then arise that would transparently swap between the two at the developer's request, thereby greatly simplifying your repackaging effort. > Postfixing the binary name sounds like a last-ditch attempt to keep > track of binary artifacts that have no clear provenance It would be GUIX demonstrating that the artefacts are not the same artefacts that Java developers expect to receive from Maven Central, (GPG signed by the author). It doesn't hurt you to do it this way, but it will be appreciated by all Java developers. > Several of us read this blog post [2] on the state of Java packaging > recently. It echoed my experiences trying to package Java software and > it clearly explains the potential negative consequences of the current > methods, and it says it all better than I can. > > [2] > http://www.vitavonni.de/blog/201504/2015042601-big-data-toolchains-are-a-security-risk.html I agree that Maven Central needs a distributed verification mechanism. It was designed for an era where trusting the developer's artefacts (through GPG) was enough. (The article appears to be confused on this matter, and fails to recognise that Maven Central artefacts are, in fact, GPG signed, checksummed and transmitted securely over HTTPS) I am unsubscribing from this mailing list now as I only came on to ask these questions, and I feel I have received an answer already, thank you all for answering! I will leave by encouraging GUIX to move towards a more user-focused infrastructure than mailing lists, as it is extremely difficult for people like myself who want to dip in and out to get involved. Therefore, I do not feel it is the right time for me to move to GUIX just yet. A clone of github, meeting all the FSF's ethical hosting guidelines, is absolutely essential, and I hope it is a strategic goal of GNU. If GUIX are planning to dedicate a significant amount of effort to rebuilding the entire Java universe from scratch, I would prefer that you not support Java at all (except by providing OpenJDK builds). Instead, put that effort into building a github-like community portal. Once GUIX proves the viability of reproducible builds, Java will catch up. -- Best regards, Sam signature.asc Description: PGP signature
