IRC channel logs


back to list of logs

<OriansJ>j3kyl_: Yep, plus it makes it trivial to enforce coding styles in projects. (One could even make it a make target if they so desired)
<lukas__>Hi. am I allowed to post question regarding building custom kernel with nonfree blobs?
<lukas__>I almost finished my config.scm but just want to know if I'm on right track...
<lukas__>if anyone's interested my wip config.scm is here :
<snape>lukas__: hint: you can ask about building custom kernels (or custom packages) :) It's more generic, and it will probably meet your needs
<lukas__>@snape I see. My script right now is failing with error message invalid field specifier and I was just scratching my head
<snape>lukas__: I don't know. Maybe you could try to remove stuff until it works, and add little by little then. And find inspiration from Guix git repository. Now I *really* must go to sleep... good luck!
<lukas__>After trimming some functions to more elegant forms now the kernel is building :)
<lukas__>classic scheme experience
<Copenhagen_Bram>How do you learn to write in scheme?
<lukas__>Hi. I just installed guix with FDE but my laptop fails to boot while trying to mount root partition. I think it is duplicate of the bug reported here :
<lukas__>I am reading generating initial ram disk section of guix manual but I do not see any intrinsics that might help be sort the order of the kernel modules. Can somebody help me?
<kimin>I am confused with GuixSD as to where I define the system configuration and where I define specific user configurations. When I run guix system reconfigure, is that setting the system configuration?
<kimin>Then how would I set specific user configurations*
<sturm>kimin: Yes, that's the system configuration with `system reconfigure`, which will (probably) include things like Gnome and a basic set of programs to use on the system.
<sturm>You can install programs for a specific user with `guix package --install [package] ...`
<sturm>I prefer to do `guix package --manifest=somefile.scm`, where somefile.scm contains a list of all the programs I want as a user
<kimin>what would the syntax be for that file?
<kimin>Thank you
<sturm>sorry, Riot messed that paste up
<sturm>pretty handy to be able to commit that file with version control
<kimin>Yeah, that was something I was unsure about. But on a machine with a single user, I assume just using the system config is ideal
<sturm>I guess they're tools you can use however you prefer, but I've settled into having a mostly stable system config that upgrades reasonably reliably and quickly for security, and the bulk of my day-to-day tools in my user config, which doesn't always upgrade reliably if some package no longer builds.
<civodul>Hello Guix!
<ngz>Hello civodul
<civodul>heya ngz
<felicien>Hello Guix :)
<reepca>out of curiosity, anyone know why openssh clients can't seem to access lsh servers? They complain about failing to find matching ciphers, but ssh -Q cipher shows that there *are* ones that match... does openssh not try all the ciphers it has available? How do you know/control which ones it does try?
<g_bor[m]>Hello guix!
<janneke>hey g_bor!
<g_bor[m]>I've just sent a patch for java-jarjar. This is one of the last patches making it possible to switch to java8. It works, but might have some style problems :)
<g_bor[m]>janneke: Hi! Excellent work on mes, thank you for that.
<g_bor[m]>It seems, that when package inheritance is involved I tend to make mistakes. It would be nice, if I could rebuild all inherited stuff. Any way that can be done?
<g_bor[m]>(Except manually, one by one)
<g_bor[m]>Also, it would be nice if we could add a git reference to operating system and manifest files, to tie the configuration to a given guix version. WDYT?
<g_bor[m]>Is there any way to that now?
***jonsger1 is now known as jonsger
<janneke>g_bor[m]: i do not know how to do that, currently
<janneke>and thanks, g_bor[m]!
<reepca>On a more on-topic note, what have we got in the way of remote desktop services?
<snape>g_bor[m]: I don't understand, if you don't 'guix pull', you stay at the same Guix version don't you?
<janneke>i tried the jump to gcc-4.7.4 but haven't managed yet and opted for a (temporary?) half-way step to gcc-4.1.0
<g_bor[m]>snape: Actually, yes. But it would simplify provisioning new machines, furthermore would allow to use guix pull with much less breakage. Using such config files would bring the possibility to get to a completely defined state one more step closer :)
<snape>g_bor[m]: then guix pull --commit...
<g_bor[m]>snape: A logical next step would be to extend the mainfest format to include user configuration.
<snape>My understanding is that 'guix pull --commit' does what you want. I don't know why you want the commit to be embedded in the configuration file. It would be annoying to upgrade
<roptat>maybe that's for a separate command though
<roptat>like guix home, where each user can manage their own services/packages/configurations
<snape>g_bor[m]: what do you mena by "user configuration"?
<snape>oh user services and such I guess ok
<g_bor[m]>snape: Actually, yes, I know that. It is nice that we have this. My point is that guix pull --commit and a manifest, or an operating system file separates configuration to two places... I would not want this as a required filed.
<g_bor[m]>roptat: Yes, that would be fine by me.
<g_bor[m]>snape: Yes, user services an dotfiles.
<snape>g_bor[m]: fixing the Guix commit in the configuration involes not receiving security updates anymore
<roptat>I don't think we have a way to find packages that inherit another one
<g_bor[m]>snape: Also, by using a git reference, it could also name a branch, or a tag, so you could say for example use the stable branch.
<snape>oh like with Google's repo
<snape>g_bor[m]: Yes I see your point
<ngz>Oh Python 3.7.0 is out.
<snape>g_bor[m]: so imagine manifest1 is attached to <sha1>, and manifest2 is attached to <sha2>. Does that mean that each 'guix package -m' command would imply a Guix pull to update Guix?
<snape>or there would be one Guix per manifest?
<g_bor[m]>snape: I guess the one guix per mainfest approach would be ok, with deduplication.
<g_bor[m]>Most probably it is already present, if gc was not run...
<jlicht>hey guix
<civodul>g_bor[m], snape: the idea i had was to have a "meta-manifest" for guix pull
<civodul>so you'd say 'guix pull -m manifest' and it's instantiate the thing, which could contain not just Guix but also external "channels"
<snape>interesting. It's a long time I haven't heard of channels by the way. Is there any progress?
<civodul>the new 'guix pull' is channel-ready™
<g_bor[m]>civodul: That would be really useful:)
<civodul>that is, a channel will be an entry in the profile that 'guix pull' create
<civodul>then it's just a matter of writing 'guix channel add' and all that
<g_bor[m]>civodul: It would also be nice, if we could create links between manifests, or embed them into one another, or to have a format to bundle them together. WDYT? This is just an idea for now, I don't have any particular thing aside from deployment in mind...
<civodul>i agree it would be nice, yes
<civodul>at first sight they seem to work at two different levels though
<civodul>so for instance 'guix package -m' alone cannot do anything with the commit info
<civodul>that's why i'm suggesting to have two manifests
<g_bor[m]>civodul: I'm fine with that. Two manifests are no problem, but it would be nice to be able to mark them 'compatible'. So that for example we don't try to reconfigure to a system with a config incompatible with the guix version. For example see the changes around file system config.
<g_bor[m]>civodul: I have a workflow in my mind, which goes something like this: Install guixsd from this installer image (determined by guix manifest, and an os description) to nodeid. Log in the node, guix pull to this manifest. guix system reconfigure to this os description. Add these manifest to these profiles. Maybe add profiles to users... Configure users like this (guix home, for example as roptat mentioned, with a home
<g_bor[m]>description). Reboot if needed. WDYT?
<roptat>g_bor[m]: so you could embed the guix pull manifest in the installation image, right?
<g_bor[m]>roptat: That would be nice.
<civodul>yes, that would be nice
<civodul>hopefully we'll work on this for good after 0.15 :-)
<civodul>speaking of which, i am/was hoping to fix one of the guile multithreaded crashes before the Guix release
<civodul>because 'guix pull' is just too crashy currently
<jlicht>g_bor[m]: How would you 'know' if something is compatible with a guix version?
<g_bor[m]>roptat: Currently most of the time provisioning either goes trough an api, so you know already what you need for an installation image, or when provisioning unknown devices, most probably bare-metal, you netboot it using a discovery kernel, an enc classifies the node, and reboots, so that it can provide the image that fits the node. I hope to shortcut this, by guix system reconfiguring the discovery image. I'm actually trying
<g_bor[m]>to design out other configuration management tools from the setup.
<g_bor[m]>jlicht: Oh, that is so nice question. Actually what I know, is that it is compatible with the very version it was used an succeeded :)
<g_bor[m]>For my usecase it is enough.
<jlicht>g_bor[m]: fair enough :-)
<roptat>ah somehow I made a translation mistake in guix graph --help :/
<roptat>there are two -t arguments
<roptat>one of which should be -b
<roptat>g_bor[m]: are you sure java-asm builds after your patch?
<roptat>I haven't tried, but it looks like there's a loop
<roptat>java-asm-bootstrap inherits from java-asm in such a way that it preserves the inputs from java-asm, which contains java-asm-bootstrap
<roptat>or am I missing something?
<g_bor[m]>roptat: will have a look.
<roptat>also the phases from java-asm-bootstrap will have 'do-not-use-bundled-asm, which references java-asm-bootstrap
<roptat>hey, I'm looking at java-asm, not java-jarjar, nevermind
<roptat>actually it should be fine
<g_bor[m]>roptat: Yesterday I've broke this booststrap, so I will check it, but I guess it's fine. Will report back with the results.
<roptat>there's a very long line in your patch, I think you can break it :)
<roptat>otherwise, if java-asm builds fine, I think you can push it
<roptat>oh and yesterday, I tried to use my current gradle package, but it seems that scala is unavoidable as a dependency :/
<g_bor[m]>roptat: ok, thanks for the review. I will break that line.
<roptat>also updated it to 4.8.1
<g_bor[m]>roptat: Actually it would be nice to have scala :)
<g_bor[m]>I like it :)
<roptat>yes, but iirc it was impossible to bootstrap properly
<roptat>this work on java-related packages is exhausting too
<ngz>roptat: oh, you're packaging gradel?
<ngz>err gradle
<g_bor[m]>roptat: What is missing for scala?
<jlicht>what happened to 'never use regex for xml' ;-)?
<roptat>g_bor[m]: scala
<roptat>ngz: I'm trying to :)
<roptat>ngz: see
<ngz>Nice work
<g_bor[m]>roptat: woops:) this is similar to ghc boostrap problem....
<roptat>it's not complete: I bundled generated text files in the recipe for gradle-docs, I have doubts about my gradle-maven package, I somehow had to add java-commons-logging-minimal even though it's not in the upstream binary distribution and gradle-ide eventually requires scala
<roptat>well, it's the same problem with ocaml and rust
<roptat>and we didn't do anything to address those
<roptat>so maybe it's fine to package a binary version for scala?
<g_bor[m]>roptat: I guess it is still good to have a todo item, but it would not make much sense to stop using these. In the last Reproducible Build Summit we mapped this problem space, a graph should be lingering somewhere about that. Rust seemed to be the most problematic, depending on everything including itself.
<g_bor[m]>roptat: I guess we could do that, until we can find out something better, but it would be nice to wait for some other opinions. I guess writing a message to guix-devel, with a shot summary of this conversation would be nice. WDYT?
<g_bor[m]>roptat: java-asm builds fine :)
<ngz>Is there a way, or better, an example, for packaging something that requires "npm install ..." in its README file?
<ngz>(if that's possible at all)
<ngz>I'm pretty lost when it comes to npm ecosystem.
<g_bor[m]>ngz: It seems that the java-ecosystem is a bit crazy... Once there was an npm exporter, but it very quickly blew up to hundreds of dependent packages... I think it is not maintained any more. The main problem is that versions are locked, and this causes version bloat. The correct way is to have a look at the package.json file. There will be the dependencies listed. Package those first.
<g_bor[m]>ngz: have a look at this
<roelj>Does anyone know when the last build for mysql was succesful?
<ng0>prior to the merge of core-update
<efraim>I build my kodi with mariadb instead of mysql, don't change the flags
<ng0>mariadb works, if you need a drop-in replacement
<ng0>ah, yes
<efraim>No idea if changing the flags from mysql to mariadb would make a difference
<roelj>Well, I need to build python2-mysqlclient
<ngz>g_bor[m]: Thank you. Not good then.
<g_bor[m]>roptat: It seems that scala can be bootstrapped, version 2.0.0 seems to build from ant, I will have a look at this later.
<roptat>g_bor[m]: ok, but the build system is not my biggest worry
***jonsger1 is now known as jonsger
<roptat>what I'm worried about is that the scala compiler is written in scala, so you need a scala compiler to compile it :/
<civodul>yogurt software again
<civodul>most of the compilers we package fall into this category, i'm afraid :-/
<civodul>so far the (informal) policy has been to accept such packages and "raise awareness", invite people to discuss the issue with upstream, etc.
<civodul>discussions aren't necessarily fruitful though...
<roptat>civodul: if we're lucky, there may be old versions of scala that don't require scala
<roptat>and they may be enough to build newer versions
<civodul>yes, maybe, but that approach (building a chain of historical versions) is often brittle
<civodul>rekado knows that all too well ;-)
<civodul>it'd be nice if Bootstrappable would become a funded and communication-heavy project like Reproducible Builds
<civodul>it's the logical next step
<roptat>what would be the best way then? have an alternative implementation?
<civodul>or have bootstrapping in mind right from the start of the compiler development
<roptat>ok, reading the ticket that was linked in the old thread, it's not as easy as building older versions of scala
<jonsger>Sleep_Walker: I packaged guile-sqlite3 and guile-ssh which are dependencies of guix 0.15 in my home project. Just that we don't do duplicate work :)
<roptat>maybe another way is to convert scala code to java code, and then build that with our ant-build-system
<roptat>it still sounds hard to do though
<atw>that reminds me, I need to try bootstrapping leiningen again
<civodul>jonsger: do you have guile-git already?
<civodul>atw: oh, right
<atw>the tricky thing is that leiningen is self hosting. Even its oldest tag is self-hosting:
<kimin>I cannot use guix system commands in GuixSD, it says guix: system: command not found. Why is this? How can I fix it?
<atw> is the initial commit of the project, which contains a build.clj (later this became project.clj). This is equivalent to the very first version of Maven containing a pom.xml. However, that build.clj does have Maven coordinates for dependencies. Maybe we could use those to write Ant XML or a pom.xml?
<civodul>atw: you mean have a project.clj -> pom.xml converter of sorts?
<atw>civodul: I propose manually writing the translation of the linked build.clj to a pom.xml once, in order to write a leiningen-bootstrap package definition, then using leiningen-bootstrap to build a modern leiningen
<roptat>kimin: I think you should try running guix pull once more
<kimin>roptat: I did, same problem after it finished
<kimin>I can run it as root but not as a user
<roptat>guix pull works in a per-user basis
<roptat>maybe you updated only for root?
<reepca>kimin: does your PATH include ~/.config/guix/current?
<kimin>reepca: yes
<reepca>(err, with the /bin part that I forgot)
<kimin>reepca: I ran guix pull as my user
<mbakke>This tool looks useful to automate (aspects of) patch review:
<Sleep_Walker>jonsger: great! thanks
<civodul>mbakke: looks interesting
***Gamayun_ is now known as Gamayun
<jonsger>civodul: yes, we have guile-git for quite some time. guile-sqlite3 is new and guile-ssh isnt mandatory
<civodul>jonsger: i'm asking because guile-git has never had a formal release
<jonsger>civodul: I know. thats not a direct problem for opensuse, but packaging a release is a little easier... :)
<jonsger>Sleep_Walker: could we remove upstart support from the guix package or is there a reason it's still there?
<Sleep_Walker>jonsger: only if anyone would like to use same source package for his distribution
<Sleep_Walker>jonsger: feel free to drop it
<jonsger>oke. then I'll drop it. Non systemd distros are too old for guix 0.15
<tibbe>Hey, since a few days any attempt to execute guix pull fails for me. I am quite new to guix. Is it "normal" that the guix master branch points to non buildable commits or is it a problem with my setup?
<mbakke>tibbe: What error are you getting?
<tibbe>compilation works fine but after calculating the derivation it the process crashes with stacktrace and an error message (-> invalid build result (#<derivation /gnu/store/0dqqhqq9fmwjadhrj9wa0kpdp3q74c56-compute-guix-derivation.drv => /gnu/store/r2cvdmf3bbdqz07lw14zvp3j7hgz7w9q-compute-guix-derivation 2b4e280> "") )
<mbakke>tibbe: Is this on a foreign distro or GuixSD?
<tibbe>mbakke: I am running debian right now and can reproduce the problem on another machine running debian
<mbakke>tibbe: What is your `guix --version`?
<tibbe>mbakke: guix (GNU Guix) 0.14.0-12.77a1aac
<mbakke>tibbe: I have to go now, will be back in a few hours.
<mbakke>In the mean time, make sure `~/.config/guix/current/bin` is first in PATH.
<mbakke>Also try updating the root guix and restart the daemon, if possible.
<tibbe>mbakke: bye then I will try my best
<brendyn>tibbe: do you have guix in your profile?
<pomyslek>I've got a little trouble setting up new guixsd installation
<pomyslek>everything works fine until the point og guix system init
<pomyslek>looks like setup puts all the downloaded files in /
<pomyslek>instead of /mnt or anything else
<pomyslek>result is that there is not more free space for the program to store its temporary files
<pomyslek>is there any way to work around this problem?
<samplet>pomyslek: Did you run ‘herd start cow-store /mnt’?
<pomyslek>this one I forgot, thank you!
<samplet>You’re welcome!
<lfam>libreoffice now crashes on foreign distros when trying to open a file :(
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, civodul says: is now up-to-date
<lfam>Of course it works when XDG_DATA_DIRS is not set
<Copenhagen_Bram>So... I think I can't run executables other than in a Guix profile. when I try, it says "No such file or directory", as if it doesn't exist.
<eric23>what's your $PATH
<nckx>Copenhagen_Bram: And what does ‘command -v [command]’ say? That error message can be misleading (i.e. when the executable actually ran but the dynamic linker couldn't find a library).
<nckx>One of the more obscure sed flags.
<ng0>seems like for the nodejs free experience (from source) someone has to write a frontend without nodejs for pleroma. Or my quick reading of the code for the frontends was wrong. Too bad.
<ng0>backend, all good. frontends however have all npm in their instructions
<ng0>can't remember how I got everything.. seems like Mix hides some of that.. more likely that I need to read more
<Copenhagen_Bram>nckx: it outputs the path of the executable
<nckx>Copenhagen_Bram: ^ just too late.
<Copenhagen_Bram>> not a dynamic executable
<nckx>Hum. What *is* it?
<Copenhagen_Bram>nckx: it's actually an executable i scp'd from a hacker wargame
<Copenhagen_Bram>but i've had the same issue with a downloaded copy of qtads
<nckx>Copenhagen_Bram: Aaaah.
<nckx>That's a known limitation of Guix (and Nix) when running unmodified ‘foreign’ binaries. IIRC, they point to something like /lib/ as the linker loader which doesn't exist on those systems.
<nckx>You'll have to use patchelf to, well, patch them. Let me see...
<ng0>it's not nice, but you can elfpatch if it's for private use
<ng0>that is.. if this is Guix-on-GuixSD. Otherwise you could simply write a thinwrapper to re-set the path
<nckx>Ugh. It's been years since I've patchelf'd something.
<nckx>How would you even go about protecting such a thing against GC? Any best practices for the worst practice?
<ng0>I would share the code, but I can't because I use it for the obvious cases where you can't get the source of an application. I have a package definition, and as I had to replace the install phase, it was trial and error. the basic recipe is that this has to occur:
<ng0>something along those lines, I mean.. (for-each (lambda (file) (system* "patchelf" "--set-rpath" rpath file)) (cons* bin bin-as bin-as2 (find-files out "\\\\.so$"))) followed by (for-each (lambda (file) (system* "patchelf" "--set-interpreter" ld-so file)) (list bin bin-as bin-as2)))… you get the general idea. there's no one formular that matches all cases though. Our rust package has an example.
<ng0>if you wanted to, you could try and formalize it into a build system for yourself, but so far the 1 application I have did not justify half-automation
<nckx>Copenhagen_Bram: What ng0 wrote is correct. A less elegant but faster way if you just want to play around in the meantime: a manual ‘cp $(patchelf --print-interpreter $(which ls)) /home/bram/...’ and ‘patchelf --set-interpreter /home/bram/.../ $your_binary’ should at least get ‘ldd $your_binary’ to work so you can list the required libraries.
<nckx>The reason for making your own copy is that the original ld-linux*.so.2 in /gnu/store will get GC'd eventually.
<nckx>If this all sounds very complicated and ugly that's because it is, unfortunately, quite.
<nckx>I just realized I have (service special-files-service-type ("/lib/" ,(file-append (canonical-package glibc) "/lib/")))) in my system configuration and absolutely no memory why or when I wrote that.
<nckx>So that's a third disgusting option.
<Copenhagen_Bram>nckx: wow, it's like the only way to install something in Guix is to write a package for it
<Rukako>g_bor: sorry for not replying to your mail before, I just noticed it
<ng0>I think you could still install to a path in your home directory, or in the root, etc.. options exist, but if you want to maintain control a package is nicer
<ng0>it's what I do for my scripts collection for example
<ng0>tbh, I would really pay more money for renoise if they would do a source release. but that's their business model. a .deb is better than nothing.
<ng0>ah, I forgot: you also need to disable runpath verification for some software.
<nckx>Copenhagen_Bram: Keep in mind that ‘installing’ here is short for ‘installing binaries compiled someone else’. I agree it's (probably unnecessarily) painful, but it's not really what Guix stands for.
<nckx>So yes, creating packages is encouraged through harsh application of nudge theory.
<Copenhagen_Bram>Hmm. Well I'd be writing a packaged for qtads if I knew what lamda meant
<ng0>we have some of these "problems" right now because we are to some extent like NixOS diverging from the currently agreed-upon Unix system.
<Copenhagen_Bram>right now? is there plans to fix these problems?
<nckx>Around the time I left Nix for guixer pastures there was a ‘FHS environment’ being worked on. Not for the entire system, but for packages that needed it.
<Copenhagen_Bram>what's FHS?
<nckx>FHS = ‘the currently agreed-upon Unix system’ [file system layout]. /usr, /bin, etc.
<nckx>(File system Hierarchy Standard, I believe.)
<Copenhagen_Bram>hmm... It might be even better to improve the ease of writing guix packages?
<fzer0>Hi guys, newbie here. How do you guys handle package managers? I have seen a lot of youtube videos about this distro and the speakers talk about it, but I am still confused. Do you use package managers, or do you declaratively add the package to the config?
<ng0>I'Ve been think about package manager namespace for things I'm working on.. provide with lots of hacking for portage, etc
<nckx>Copenhagen_Bram: Not that I know of. Guix is very source-focused (understatement of the week) so this is not considered much of a problem AFAICT. I certainly don't think it merits the effort or possible overhead.
<ng0>which might or might not involve some tinkering with chroot-like FHS spaces.. or something. nothing I prioritize, just a curiosity.
<Copenhagen_Bram>fzer0: guix is a package manager, and you don't add every package you install to the config, just the ones you want installed system-wide. You can install guix packages by typing `guix package -i icecat`, and they get installed just for your user. And you could install a different version of icecat for a different user.
<ng0>Copenhagen_Bram: eventually we should have converters. Where you write a limited set of a package definition and it transforms to a guix readable package, but you have to do some manual work, like dealing with gexps which we might or might not get later on in package objects.
<nckx>Copenhagen_Bram: Making packaging easier is always good.
<fzer0>Copenhagen_Bram: Sorry, I am mostly referring to GUIXSD and want to know best practices. For instance, if you use python do you use pip for scikit-learn, or are you creating a guix package?
<ng0>so a friend and myself have been discussing ideas about what essentially is a lexer+parser, taking a range of languages and try not to output to much garbage for something based on guix or guix. I didn't think about packages, but rather about system definitions though
<ng0>pip works.. though I noticed for python development to really work, I need to enter a guix environment, where I then can activate a venv or whatever
<nckx>ng0: I think that's the way to go! Not making packaging ‘easier’ by dumbing down the DSL, but making sure that people have to write as little as possible of it whenever possible.
<Copenhagen_Bram>fzer0: hmm i have a bad feeling pip might not work
<nckx>This would help experienced users as much as new ones.
<fzer0>ngo: but wouldn't that be introducing state and the problems that Guix is trying to prevent?
<nckx>fzer0: Basically, yes.
<ng0>my idea is not about "dumbing down" the DSL.
<nckx>More manually-managed state, at least.
<nckx>ng0: That was my point.
<Copenhagen_Bram>ACTION installs pip
<ng0>it's about providing tools to interact with it
<ng0>read the sentence again :D
<fzer0>nckx: how hard is it to package something like a python library, ELM, Elixer, etc?
<ng0>when it comes from pypi, we have importers
<nckx>ng0: It's just often suggested or (usually) implied as the way to ‘make packaging easier’, often by people outside of Guix. I agree that it's not a good one.
<fzer0>ng0: thats cool, i will look into that more
<nckx>We've tried packaging-by-YAML. It fails.
<ng0>so, guix import pypi toasted-bread gives you a basic package object you could pipe into a file, or without the pipe just look at it and improve
<ng0>guix import --help lists all of the importers
<ng0>and info guix import should show some info :)
<fzer0>How would you install a package like dwm, st, or another package by the suckless organization...with pathes? How would you define that in the config?
<mbakke>tibbe: Did you have any luck?
<ng0>nckx: I just spend enough time thinking how to bridge some communities
<ng0>where communities literally just means groups of people with different goals and knowledge/expertise
<nckx>fzer0: ng0 has answered in the mean time, but (IMHO) not hard at all for the average case.
<ng0>it's a long time to get there, and what I have as part of a templating system can hopefully be added back with only minor adjustments to guix
<ng0>fzer0: I have my own forks and patches for suckless-like software
<fzer0>Ng0: thanks for the response!
<ng0>and besides patches or own remotes we can have 'substitute' phases which is a - to some degree - intelligent search and replace patch
<nckx>ng0: I'm looking forward to it. The Guix community needs to grow & not just in numbers.
<mbakke>fzer0: I've used this to have a local git checkout of `st` in my system configuration:
<ng0>I wished university wouldn't cost so much time, I'm really looking forward to the day to break even, rebase and have a shared workload on my side..
<mbakke>It's not perfect, since it will rebuild st every reconfigure, but luckily it's a pretty quick build.
<ng0>I'm really amazed by how far I could go before I had to realize that certain parts in guix can not be adjusted the way I wanted it, but the design has grown over the years.
<fzer0>mbakke: so you pointed the package manager to your own patched version, correct?
<ng0>I hope I can write about this soon, it's like what Ludovic wrote in the thesis which introduced Guix: " make future operating system building easier"
<mbakke>fzer0: It doesn't show up in `guix package --search` etc, but it will be part of the system configuration.
<nckx>(source "/home/marius/repos/st")... wait, you can do that? Without a hash? I... huh.
<nckx>I'll just file that under ‘never to old to learn’ & move on.
<fzer0>I want to use it on my laptop, but I found out it has a proprietary wlan connector so I can't use Atheros card (Carbon X1 gen 1). Does anyone run a non-free version (kernal)?
<ng0>I used to inherit from st and apply patches on top of it
<nckx>fzer0: No one who can admit to on this channel.
<fzer0>nckx: sorry. I really want to try it on bare metal and i already have enough laptops and libre boot won't work on any of them.
<nckx>(Not me either, to be clear.)
<fzer0>ng0: is it possible to look at your config file? I want to see how it is done.
<ng0>for what?
<pkill9>fzer0: this is how i add patches to st
<ng0>I mean I have coinfig files online, but they are rather unique due to what I do with guix
<ng0>or st?
<fzer0>ngo: oh sorry, i thought your "yeah" was in response to my question about non-free kernel conifg
<nckx>ACTION gives st a try since all the cool kids seem to.
<bavier>ACTION realizes they must be a cool kid
<Copenhagen_Bram>so i tried to run pip, but i'm pretty sure pip is broken on guix
<ng0>sharing configs is not forbidden though. in my case, idk. it would be on the same git host as the almost-instrucitons but: you just will not be able to use it, since what I do in there and reference in there is currently not in a state that is online. so it mentions a different kernel because I have more kernels, but that's it.
<ng0>Copenhagen_Bram: remember when I said enter a guix environment with python + the required modules?
<ng0>that's how pip works for me
<ng0>in a Guix-on-GuixSD setting
<ng0>fzer0: what is done in terms of using other kernels and firmware is to use the module where the kernel is and maybe its firmware, and use the firmware in the firmware-related part of the system config and the kernel like (kernel name-you-used)
<rekado>roptat, g_bor I looked into Scala a while ago and it cannot be bootstrapped sanely.
<rekado>The earliest Scala versions (from before the history was cut) depend on Pizza, which (of course) has a bootstrap problem of its own.
<rekado>everything from 2.0.0 onward depends on a working version of scalalib, which is written in Scala.
<roptat>rekado: ok, thanks for the info
<roptat>actually I thought I could try to "transpile" the scala code into java to build it a first time
<roptat>then we would get a scala compiler built with javac
<mbakke>fzer0: You can find an example configuration with a custom kernel and firmware here: (warning: may contain nuts)
<roptat>I don't know if that's enough and reading a comment in a random file, it looks difficult (scala annotations seem incompatible with java ones, but I don't know if we need any annotation)
<fzer0>mbakke: thank you!
<mbakke>rekado: Can you remember how to run the "reduced" test suites of scipy and friends? I'm trying to update them, but iteration cycles are sloooooow....
<fzer0>mbakke: I actually ran across this config about a week ago. I like I3 as well, so I just keep those sections as well correct? Why the suplementary groups?
<mbakke>fzer0: That config is years old, though I do like to have access to various device nodes without being root, which is why I am member of all the things.
<fzer0>mbakke: interesting; I have a lot to learn.
<ng0>hm. I think I can link to my config without problems here, I made a split by hosts recently and there's no indication on the one hosts what the other host is, at least not in the old_systems.git repo
<ng0>it's not that up to date online.
<ng0>there's lots of testing and old testing experiments in that file.
<mbakke>Bah, scipy:doc is failing hard and inexplicably. Syntax errors from matplotlib, and "sphinx-build: error: option -b not recognized".
<rekado>mbakke: the Python science packages have very strict version requirements on one another. Make sure that this particular version of matplotlib will work with this particular version of scipy.
<rekado>I once had to revert an upgrade (and the attempts to fix breakage) because it couldn’t be made to work.
<mbakke>rekado: From their CI configuration and docs, it does not look like they depend on an unreleased matplotlib (we have the latest version already, and 1.0.1 works fine with it).
<mbakke>I suspect rather that Sphinx@1.6 is broken. Or that it actually requires 1.7.
<mbakke>Woah, my tmux server crashed. Disconcerting.
<lukas__>Hi. I just installed guix and wanted to reconfigure system (to enable sshd service). I changed /etc/config.scm but guix is not reconfiguring system with error message: guix: system: command not found
<lukas__>This is very strange as both manual page and guix -help both list system as subcommand. Any ideas of what is happening?
<pkill9>lukas__: a lot of people have mentioned that issue lately, can't remember the fix though
<lukas__>pkill9 : google search is not revealing any useful insights and I do not know where guix developers keep their issues. Should I look at the devel mailing list?
<pkill9>someone here will probably be able to tell you when they see your message :)
<pkill9>also check guix-bugs
<rekado>lukas__: you need to run “guix pull”
<rekado>then “sudo -E guix system …”
<lukas__>rekado: are you telling me to guix pull as root and execute guix system with sudo? or should I guix pull for every user on the system?
<rekado>lukas__: “guix pull” operates only for the current user.
<rekado>lukas__: you can run “guix pull” as your regular user and then use “sudo -E” to use that version of Guix to reconfigure.
<rekado>if you don’t install or upgrade packages for the root user you don’t need to run “guix pull” as root.
<rekado>(in that regard, root is not special)
<lukas__>rekado: I'm confident I guix pull-ed as root (to upgrade neovim) but system command is still failing. I will try again as regular user (after pulling that is)
<lukas__>rekado: nope. Still the same message after guix pull on my account.
<lukas__>This is beyond strange. mb I should try different version of installation image...
<rekado>installation image?
<rekado>have you installed Guix already? Are you using GuixSD?
<lukas__>I used latest one (0.14.0)
<rekado>then you have no use for an installation image at this point.
<rekado>after “guix pull”, did you add ~/.config/guix/current/bin to PATH?
<lukas__>No I'm saying mb I should clean reinstall with different one
<lukas__>hmm let me check $PATH again
<rekado>I don’t understand how a reinstallation would help.
<lukas__>Well I thought it was a guile bug but it was actually my sloppiness. After updating the $PATH the command is running again
<lukas__>Would definately appreciate if manual was bit more elaborate about reconfigure command tho...
<rekado>in what way?
<rekado>the behaviour about “guix system” failing is a bug that was introduced and fixed recently.
<rekado>small bugs like this are generally not mentioned in the manual.
<rekado>the problem is said to disappear after a second “guix pull”
<rekado>(the reason here is that “guix pull” did not ensure that guile-sqlite3 was available; this has been fixed in later versions)
<lukas__> interesting.