IRC channel logs


back to list of logs

<NieDzejkob>what error?
<NieDzejkob>you need a pam-service, and yubico-pam seems to only be a package?
<NieDzejkob>rekado: you packaged yubico-pam, right? ^^^
<ng0>jonsger: i mean, it's nice to know and being able to patch in time, but the next default version bump for pkgsrc will be to 2.2 as far as I can remember. parallel version installs remain, and most packages (which aren't many) are 2.2 by now.
<ng0>or something like that, email thread was too long ago
<jonsger>ng0: I wont toggle 3.0 as default when it's released. But I already try to make the packages 3.0-ready :) The first batch I'll migrate when Guix is ready for 3.0
<nckx>‘Avoid @@, which doesn't work on Guile 3.’ 😮
<nckx>Guile 3 why u steal my hammer.
<lispmacs[work]>NieDzejkob: rekado: okay, let me know what service is needed.
<lispmacs[work]>I got it working in the past in Debian following instructions, but am trying to figure it out for Guix
<lispmacs[work]>NieDzejkob: rekado: wait, I found my original debian instructions. In debian you just install libpam-u2f
<nckx>lispmacs[work]: Have you looked at -pam-service examples in gnu/system/pam.scm to see whether writing one's within your skillz?
<lispmacs[work]>nckx: no, I was really hoping that was already available
<lispmacs[work]>since a search for yubi brought up like 8 packages in guix repo
<nckx>Understandable, but I think you'll still need a service to tie the u2f ‘.so’ module into PAM.
<lispmacs[work]>nckx: erm, but surely whoever added all the plam-u2f and *yubi* packages must have thought of that
<lispmacs[work]>unless he/she added them all and didn't use them
<nckx>lispmacs[work]: I didn't know about pam-u2f in Guix.
<nckx>Can't disagree with your reasoning.
<lispmacs[work]>nckx: hmm, not making any progress grepping the guix source code. if a service needs to be coded it doesn't seem to have been
<raghav-gururajan>Hello Guix!
*raghav-gururajan just got back from tiring shift.
<lispmacs[work]>nckx: well, I guess I could try to figure out how to create a PAM service, but I'm really curious how they tested that pam-u2f works when they added it
<lispmacs[work]>any really similar services out there I could edit?
<str1ngs>is there syntax sugar to add to RUNPATH? or do I just need to modify LDFLAGS?
<brettgilio>I just made a V2 patch for SMLnj if anybody wants to look at it please do :)
<bandali>brettgilio, feel free to cc me :)
<leoprikler>so wait, these things can not be packaged individually?
<leoprikler>git submodule in 1969 it seems
<drakonis>NieDzejkob: is this you?
<Gooberpatrol66>where are .patch files stored for patching packages?
<nckx>Gooberpatrol66: gnu/packages/patches and ‘registered’ in gnu/
<Gooberpatrol66>i don't have those directories on my pc
<Gooberpatrol66>is that for user patches or ones that are performed by the package definitions
<nckx>Gooberpatrol66: That's relative to the Guix source tree.
<Gooberpatrol66>so it's included with the guix program?
<nckx>It contains all ‘official’ patches that are applied to Guix packages.
<Gooberpatrol66>how would a channel add a patch
<leoprikler>you put it in the root of the channel
<leoprikler>how do I know? been there, done that
<Gooberpatrol66>ok thanks
<roptat>hey guix!
<nckx>Gooberpatrol66: ☝ and just use search-patches as usual. If you put them elsewhere you're on your own. (Been there, don that.)
<roptat>today I've been trying to learn how to use Z3, and found that they had a s-expression syntax. So I did that:
<roptat>using z3 in guile now :)
<roptat>formal method people might be interested
<nckx>A first news post for is born.
<nckx>Heh 🙂
<leoprikler>Doesn't every major SMT solver use smtlib in some form or another though?
<leoprikler>Or are you talking about internal syntax?
*nckx → bed, space-station-ping IRC UX ≠ fun. G'night.
<roptat>leoprikler, I suppose, but I never used an SMT solver before
<roptat>smtlib is indeed supposed to be generic, so...
<roptat>nckx, good night :)
<leoprikler>okay, I goofed myself
<roptat>I have to admit: I take your s-expression, transform it into a string, pass it to z3, get a string and parse it as an s-expression back :p
<leoprikler>You could make an FFI out of that.
<leoprikler>Somewhere out there, some JS developer uses exactly that (well, not "exactly", the z3 part is replaced by whatever) as an FFI, I guarantee it.
<roptat>what do you mean?
<roptat>I use an FFI already
<leoprikler>Oh, sure, that's not my point.
<roptat>z3-eval-smtlib2-string is the foreing function Z3_eval_smtlib2_string
<roptat>ok, I don't understand
<leoprikler>My point is, that in certain cases, you can make an FFI based on (de)serialisation of objects.
<leoprikler>Basically, the JS pattern of writing your objects as JSON and then serializing them back into data.
<leoprikler>+ eval
<leoprikler>Could you use this with ports?
<roptat>I don't think z3 can read on its standard input
<roptat>I think I'll need a concrete example, I still don't understand what you mean
<leoprikler>Let's say, you want to use Javascript to compute 2+2. So you start a repl via fork/exec, as you do, write "2+2", read the output and parse it back.
<roptat>ah I see
<roptat>I don't think z3 has a repl though
<roptat>but I guess I could make a repl for z3 in guile :)
<leoprikler>It would be nice, if z3 could read and eval from arbitrary streams, not just files or strings.
<leoprikler>that way, you could keep feeding it chunks of data while keeping the context
<leoprikler>but I guess either way you're reading/writing sexps as strings 😐️
<leoprikler>Well, either way, time for me to go to bed. Good night, everyone!
<roptat>see you!
<plasma41>From the README in the Guix source:
<plasma41>See the manual for the installation instructions[...] by running
<plasma41> info -f doc/ "Installation"
<plasma41>The file does not exit within the doc directory. guix.texi (which I assume is the source) can be found in that directory though.
<str1ngs>plasma41: did you use a source traball? or pull with git?
<plasma41>str1ngs: git. Is the tarball different?
<str1ngs>yes, when generating the dist taball the manual is created.
<str1ngs>you could use ./configure --localstatedir=/var then make info
<str1ngs>but that will probably fail because you need all of guix depends. best to use the info from the tarball.
<plasma41>How is the tarball created from a git commit? I had (falsely, apparently) assumed that simply checking out the correct tag would give me an exact copy of the contents of the tarball.
<roptat>plasma41, once you have all the dependencies, it's created with make dist
<smithras>hi guix! Today during a system reconfigure, I got a message saying 'error: executing SQLite query: database disk image is malformed' and now any guix command that modifies the store is raising the same error
<smithras>Is there any way to recover from this?
<apteryx>smithras: ouch. I don't know. Is your disk healthy? I've never experienced such failure.
<smithras>apteryx: It's only a year old, but I'll check the disk stats :(
<drakonis>guix system init maybe?
<drakonis>if it can recreate the sqlite db
<smithras>drakonis: can that be run on the same system? Or would I have to flash a live guix usb and use that to rebuild the store?
<drakonis>same system
<drakonis>i dont know if it can actually recreate the sqlite db
<drakonis>i have not tried
<drakonis>its not going to eat your files though
<smithras>ok thanks, I'll give it a try
<apteryx>the thing is after the db is lost, the files under /gnu/store becomes useless -- they won't get reused (IIRC).
<apteryx>but it's an otherwise good idea to try
<smithras>ok, I didn't get the same error and now it's downloading the linux kernel, so hopefully once everything is built it'll work again
<smithras>thank you!
<smithras>I spoke too soon, the same db error came back :(
<smithras>I'll try again later from a live usb I guess
<NieDzejkob>sneek: later tell drakonis: yes, this is me (re: cursedfs)
<sneek>Got it.
***modula is now known as defaultxr
<peanutbutterandc>Hello there
<peanutbutterandc>Since guile3 will be out tomorrow, I was wondering if guix will start using guile3 from the bottom up really soon... We'll probably have guile3 as guile instad of guile-next in a few days, won't we? And from what I've understood, `guix pull` and friends will work noticably faster (?)
<str1ngs>peanutbutterandc: this tuxguitar build is not an easy fix. as far as I can see to build the tuxguitar-alsa-jni it needs to use maven .
<str1ngs>peanutbutterandc: though I have fixed up the build somewhat at least.
<str1ngs>peanutbutterandc: if you do a guix pull mercurial show be fixed now
<peanutbutterandc>str1ngs, Wow. That is good news. Did you fix mercurial?
<peanutbutterandc>Also, regarding guile3 release tomorrow, what can us guix users expect?
<str1ngs>peanutbutterandc: between nckx and myself we figured out it was just taking a real long time to build.
<str1ngs>err run tests I mean
<str1ngs>I'm not sure about moving to guile 3 yet. I suspect that's not something to be rushed.
<peanutbutterandc>so... you skipped the tests?
<str1ngs>peanutbutterandc: not tests are enabled, but we have the tests run verbosely so they don't time out on the build farm.
<str1ngs>so though the tests are long most people will now just get substitutes
<efraim>a guile-3 update would be a world rebuild, so core-updates
<peanutbutterandc>str1ngs, I see. I'm glad it is fixed now. I'm running guix pull currently.
<str1ngs>peanutbutterandc: you can test with. guix pull && guix weather mercurial
<efraim>IIRC it's built already on berlin
<efraim>or at least on bayfront
<peanutbutterandc>Oh I see... in this talk Mr. Wingo says that guile3 is essentially source compatible with guile2. Hence my question.
<peanutbutterandc>str1ngs, I see. It says 100% substitutes available. However, It isn't giving me back the terminal prompt. Is that to be expected?
<peanutbutterandc>with guix weather, I mean
<str1ngs>peanutbutterandc: that's expected. guix build mercurial should download the substitute
<peanutbutterandc>str1ngs, So.. the only to get out of `guix weather` is to Ctrl-C?
<peanutbutterandc>I see. Perhaps it should be redone to quit after it shows the information?
<str1ngs>well well what do we have here.....
<str1ngs>peanutbutterandc: -> /gnu/store/jyzy8gldr2p4qddi8qy59d391smb2r5n-tuxguitar-1.5.3/lib/
<peanutbutterandc>str1ngs, Umm... sorry, how do I get that, please? I tried `guix build --dry-run tuxguitar` but couldn't see it. Also it's not in my /gnu/store. Also, I see that you are working on tuxguitar 1.5.3. Truely a man of culture. :)
<str1ngs>peanutbutterandc: oh this is my local build
<str1ngs>peanutbutterandc: once I get it working I need to mail a patch
<str1ngs>this build was messy it was doing chdir etc. I at least wrapped it in a guard.
<peanutbutterandc>Oh... I see. So you meant to say that you've got the library working. Sorry I don't yet speak the langauge of the wizards.
<str1ngs>peanutbutterandc: its WIP
<str1ngs>peanutbutterandc: does the fret board make sound when you click on it?
<peanutbutterandc>str1ngs, I see. No, sir. It does not.
<str1ngs>lol I'm trying to click out a G chord.. and I actually have to think about it
<nckx>Mornin' Guix.
<peanutbutterandc>str1ngs, I usually do ukulele tabs. So I just thought of a D-shape. lol.
<str1ngs>peanutbutterandc: do you have alsa utils installed?
<peanutbutterandc>nckx, Good morning!
<str1ngs>good moring nckx
<civodul>Hello Guix!
<nckx>NieDzejkob: ‘I could answer: sure, see bcache migrate or btrfs convert. Or I could reimplement the world's most disturbing fs combo.’ I like your style.
<str1ngs>peanutbutterandc: alsa-utils I mean
<peanutbutterandc>str1ngs, No, sir. Should I install it?
<peanutbutterandc>Strange... guix upgrade seems to be upgrading basically everything. Wonder if it is the mercurial thing
<peanutbutterandc>gimp, emacs, gnucash... everything
<peanutbutterandc>"1057.8MB will be downloaded"
<str1ngs>peanutbutterandc: is this the first time you did guix pull?
<peanutbutterandc>str1ngs, No, sir. First time in a few days, rather
<peanutbutterandc>It seems 30 packages are being upgraded
<nckx>smithras: You could try using the sqlite command-line tool to repair or dump the database, but it has a low chance of success (and will you ever trust the result?). Just go straight to ‘guix system init’ from the installer (it won't touch anything but /gnu and /var/guix). Happened to me too ☹ This fragility is unfortunate.
<str1ngs>peanutbutterandc: so good news I have sound but need to use timidity
<nckx>peanutbutterandc: If I'm not mistaken the mercurial update would not cause this because sources are fixed-output: the only hash inputs are the source files themselves, not the tools used to fetch them.
<str1ngs>it would only happen to build were the source changed correct?
<str1ngs>or I guess you can test with guix build -S ?
<peanutbutterandc>str1ngs, I see. Perhaps timidity can be made an input?
<nckx>str1ngs: Correct. You'd have to download the new mercurial. But it wouldn't cause gimp &c. to be rebuilt even if GIMP used hg-fetch.
<peanutbutterandc>nckx, Perhaps this is normal. I might have `guix pull`-ed a lot but might have forgotten to `guix upgrade`. Either ways, as long as it is not stuck, I'm happy. :)
<str1ngs>nope, and now that there is a substitute mercurial should not be factor.
<str1ngs>I think the biggest issue really with mecurial was the build farm timing out
<nckx>Oh, it passed? I haven't checked yet. Yay then.
<str1ngs>yes, weather seems to be good for mercurial.. pun intended
<nckx>Apart from the -v thing I also raised the ‘internal’ time-out. It was quite low and the test suite would kill its own children. That's Guix's job!
<str1ngs>peanutbutterandc: timidity is the output tuxguitar is the synthesizer input
<str1ngs>peanutbutterandc: so definitely need this alsa plugin minimum.
<str1ngs>peanutbutterandc: but should probably add jack too
<str1ngs>peanutbutterandc: I don't know about the keyboard issue yet. I need to clean this build up more
<peanutbutterandc>str1ngs, I still need to read that book on linux sound/audio. I don't precisely understand how jack and alsa and pulseaudio work, yet. Perhaps it is one of the plug-ins of TuxGuitar? Also, it seems the XDG thing needs to be fixed for tuxguitar. I only see flatpak-installed tuxguitar on my machine
<str1ngs>peanutbutterandc: probably needs a desktop file
<str1ngs>peanutbutterandc: can you describe how the keyboard should work so I can test this?
<peanutbutterandc>str1ngs, I just type a key (number) and the number shows up in the tab (and plays a sound). If I want to change strings, I can use the up/down arrow keys to change them. right-left to navigate between notes on the same string
<str1ngs>peanutbutterandc: any number or number pad?
<str1ngs>I don't have number pad haha
<str1ngs>peanutbutterandc: hmmm arrows keys don't even work. do you need to be in an edit mode?
<peanutbutterandc>str1ngs, Perhaps you might be interested in seeing the flatpak? I don't need to be in edit mode... It just works.. but I might have to check again. Number keys. Sorry.
<peanutbutterandc>It doesn't help that I have supertuxkart installed via guix. Which ships the very excellent 1.0. One of these days, I am going to learn blender just to create custom supertuxkart tracks.
<peanutbutterandc>str1ngs, Edit > Selection Mode seems to be the one checked in flatpak. Not edit mode...
<str1ngs>peanutbutterandc: on my nano jetson which uses ubuntu the keys work by defaul
<str1ngs>peanutbutterandc: what version is the flatpack?
<str1ngs>I don't use flatpak myself
<peanutbutterandc>str1ngs, Flatpak 1.2.5, as supplied by the debian maintainers on debian 10
<str1ngs>sorry I meant tuxguitar in flatpak
<peanutbutterandc>Flatpak is pretty popular "universal package manager"
<peanutbutterandc>But guix is better. :)
<str1ngs>right but lets pretend I don't use flatpak an only guix. what version is tuxguitar in flatpak?
<str1ngs>okay thank you
<peanutbutterandc>I was checking. Sorry
<peanutbutterandc>I feel like the only thing that makes flatpak more appealing than guix is that it works well out-of-the-box. Which is what I hope to do with guix with the patch for install script. (Which does need to be updated, but still)
<peanutbutterandc>The first time I installed guix, I couldn't figure out why I couldn't run the programs that I just installed. Turns out, I did not have PATH set up correctly. Neither did the programs show up on the menus. That did turn me away from guix for quite some time until I finally read the reference manual
<str1ngs>unfortunately foreign distro does not get as much love at times.
<str1ngs>need more foreign users I think.
<str1ngs>err foreign distro users
<peanutbutterandc>str1ngs, I understand. I am one. And I plan to remain a foreign distro user (foreigner?) for some while. :)
<str1ngs>it's the best way to try and use guix I think.
<peanutbutterandc>The great thing is: I get to teach my friends/sibilings how to install programs via terminal without the 'sudo' part. And they understand it. It's so much fun to see them loving it. Guix is just great. It has put fun back in computing for me. :)
<peanutbutterandc>str1ngs, I have one question, however. I hypothesize that even if there were a malicious package definiton somewhere that ran `rm -rvf /*`, and a normal user of a system ran it, it wouldn't do much harm as all the builds happen inside of a chroot
<str1ngs>peanutbutterandc: correct
<peanutbutterandc>...and that if a user installs a package that does nothing but `rm -rvf /*`, it damage would only be local to their own home... ?
<peanutbutterandc>I have wanted to actually do that but haven't gotten around to it, yet.
<nckx>peanutbutterandc: You can't compare Guix to Flatpack. Flatpack is just ‘guix pack -RR’ which also generates binary blobs that also run out of the box and also don't require $PATH. You had to set PATH because you wanted a real package manager, not just a blobware downloader 😉
<str1ngs>peanutbutterandc: I've actually even got the guix daemon to run inside a rootless cgroup. so you don't need root ever
<nckx>Flatpak probably does do sandboxing, so they have that over us.
<nckx>For now.
<peanutbutterandc>nckx, "For now". :) I love it! You know what I am most excited about? In the reference manual it says that the end goal is to have peer-to-peer substitutes (using something like gnu net perhaps). That is the thing.
<peanutbutterandc>I understand that guix is, indeed the best "universal package manager" out there.
<nckx>It is absolutely the thing.
<peanutbutterandc>Yes, sir!
<lxsameer>hey folks, i'm trying to build guix from source. the `configure` complains about missing guile 2.2, but i installed guile and guile-json using guix and it's available via my PATH
<nckx>Guix is the shit but P2P substitutes are the thing.
<peanutbutterandc>nckx, hahaha :D
<str1ngs>peanutbutterandc: gnu net is feasible but I think it would take much work then say using IPFS
<str1ngs>peanutbutterandc: I literally wrote a package manager that uses IPFS
<nckx>lxsameer: Does your distribution have a separate ‘development’ package for either?
<peanutbutterandc>Also, here is my first (scared) attempts at running guix:
<lxsameer>nckx: nope, apparently i messed up my source tree some how
<str1ngs>lxsameer: are you using git?
<peanutbutterandc>str1ngs, Whoa. Interplanetery File System.
<lxsameer>nckx: i installed bunch of packages using guix but now they do not exist in my profile
<lxsameer>str1ngs: yes
<lxsameer>i'm guissing that something is wrong with my guix installation
<str1ngs>what errors are you getting?
<lxsameer>str1ngs: missing dependencies, and I'm installing them one by one but I installed them once before.
*nckx → afk
<lxsameer>str1ngs: they are missing from my profile
<lxsameer>also as a suggestion
<lxsameer>it might be good to have a script to install all the dependencies for building guix from source using guix itself
<str1ngs>ummm is using dynamic-wind to change build directory context over kill? I can avoid changing directories
<nckx>lxsameer: If you already have Guix installed we recommend building guix inside ‘guix environment guix’, which is exactly that (but for everything!).
<lxsameer>nckx: o cool, do i have to use the same environment when ever i want to use the ./pre-inst-... script ?
<nckx>lxsameer: I say no, others say yes, you do you. 😛
<leoprikler>I personally have come to prefer guix environment --pure guix --make and using ./pre-inst-env outside of it.
<nckx>str1ngs: Eh. Wow. It's certainly… something. I'm sure you know about with-directory-excursion so what the hell are you building?
<leoprikler>s/--make/-- make/
<nckx>leoprikler, lxsameer: Exactly.
<lxsameer>nckx: leoprikler thanks folks I'll try it
<str1ngs>nckx: I'm fixing tuxguitar. it need to as a hack around using (@@ (guix build ant-build-system) default-build.xml)
<str1ngs>maybe that can be fixed but I don't want to change the build to much if it works.
<str1ngs>the current build literally uses chdir and chdir .. etc
<g_bor[m]>hello guix!
<nckx>Ah. Well, it's overkill but it's not wrong. Once you fix the build you can make it pretty.
<g_bor[m]>I noticed that the installer does a readline in the function run-shell-command.
<str1ngs>nckx: thanks I'll use with-directory-excursion which is just sugar for my dynamic-wind hack
<nckx>g_bor[m]: o/
<nckx>str1ngs: Sounds good.
<g_bor[m]>that makes it not feasible to use in an automatic installation context.
<g_bor[m]>I have two ways around that, one is to add a parameter to run-shell if the pause is requested, but then I would also have to add it to all calling functions, or maybe I could add a parameter instead.
<g_bor[m]>I believe a parameter would make more sense. Wdyt?
<str1ngs>g_bor[m] is it yes/no prompt?
<g_bor[m]>no, it just waits.
<g_bor[m]>there is no need to provide input at all.
<str1ngs>hmm would it not just hang then?
<nckx>g_bor[m]: I guess. Hard to say since I don't actually like this design to pause by default now that I see it.
<g_bor[m]>nckx: do you think it would be better to rewrite using a do not pause default?
<civodul>so, i think today we'll rename "guile-next" to "guile", and probably we'll rename the "guile3.0-" and "guile-" packages later
<nckx>And if the intent is to show important output to the user it should be captured and displayed in a scrollable window, not just rely on the terminal's limited scrollback(?).
<str1ngs>g_bor[m]: normally I get around this with yes " " | command
<str1ngs>but that's kinda hackish
<g_bor[m]>civodul: looks good to me
<nckx>str1ngs: No, it's the Scheme wrapper that hangs, it's not a subcommand waiting for stdin.
<str1ngs>readline implies stdin
<nckx>str1ngs: Look at the code.
<nckx>g_bor[m]: I think I'd have written run-shell in a way that captures and returns the output for the caller to display or ignore as needed. With a run-and-display variant for use throughout the interactive installer.
<leoprikler>civodul: won't that cause a lot of rebuilds?
<nckx>Less than you'd hope for GNU's official extension language.
<g_bor[m]>nckx: I don't think that I will do this now, I just wanted to raise the awareness. I believe that the main problem is that this mixes ui stuff into the lower level of the api.
<nckx>g_bor[m]: Absolutely.
<lxsameer>hey folks when i run this command `./pre-inst-env guix build -f gnu/packages/guile.scm` with any package, guix just freezes and does nothing until I close the process using C-c
*nckx needs to review more patches because this wouldn't have passed by them 😛
<g_bor[m]>I think that if this is really desired the ui behaviour should be injected from the frontend. Does that make sense?
<civodul>leoprikler: no, debug the "default" Guile will remain 2.2.6
<str1ngs>lxsameer: that is not how you want to use pre-insta-env. use ./pre-inst-env guix build <package-name> no need for -f
<civodul>Freudian slip?
<str1ngs>lxsameer: also have you done configure and make?
<lxsameer>str1ngs: yes
<leoprikler>so `guix install guile` will install 3.0, because it is the highest, but builds will still refer to guile-2.2 until guix is fully ported?
<str1ngs>lxsameer: if -f is if you have a single file package outside of the guix tree
<nckx>g_bor[m]: I don't know exactly what you mean but I think we agree on the matter 🙂
<lxsameer>str1ngs: but it shouldn't matter as long as i provide a file to -f right ?
<nckx>lxsameer: The -f file needs to evaluate to a single package which gnu/package/*scm files don't do.
<str1ngs>lxsameer: -f takes a file and evaluates the last expression in the file. usually a package binding. which the files in guix.git won't have.
<nckx>That said I don't know why it hangs and doesn't error out.
<nckx>(Assuming you're sure it hangs.)
<lxsameer>i see
<str1ngs>lxsameer: try with ./pre-inst-env guix build <package>
<lxsameer>str1ngs: ok
<civodul>leoprikler: exactly
<str1ngs>using -f in this will will probably trow an unspecified error
<str1ngs>this way*
<civodul>leoprikler: but as a consequence, if you run "guix install guile guile-json" (say), you'll actually install Guile 3 alongside guile-json for Guile 2.2
<civodul>instead one will have to use "guile3.0-json", until it's renamed to "guile-json"
<civodul>i'd say it's ok
<leoprikler>Makes some sense, but figuring out which package supports guile 3.0 and which does not might cause some pain.
*nckx wonders if their preference for package specs in system.scms will now asplode in their face.
<leoprikler>(for the uninitiated users just typing stuff into their shell)
<wingo>"just typing stuff into their shell" describes my professional skill set :)
<nckx>also does the initiation hurt
<leoprikler>For me personally not, I got plenty of time, but I fear others might have less.
***emyles` is now known as emyles
<civodul>leoprikler: yeah
<civodul>the other option would be to do the renaming at the same time
<civodul>but that's quite some work
<leoprikler>I agree. Whichever way you go, it's going to be a pain for someone.
<civodul>heh, that's one way to look at it :-)
<leoprikler>just to be sure: one /can/ install both guile@3.0 and guile@2.2 at the same time, can one not?
<leoprikler>well, stuff like bin/guile would be a pain…
<jonsger>leoprikler: you can
<potential-alex>Good morning! I have a channel / GUIX_PACKAGE_PATH for some experimental packages. I need to apply patches to one of the packages during the build process. I know I can use the package field in <origin> — but it can't seem to find patches in my channel. How do I specify the path to the patch?
<leoprikler>if the patch lives in the root of your channel things should be a-ok
<leoprikler>if it lives elsewhere you'll have to write your own procedure to find it
<lxsameer>str1ngs: it worked
<lxsameer>but when i build a package guix start downloading some packages including openldap, gcc, git and several others but i didn't define any dependencies in my package definition. is that normal ?
<potential-alex>leoprikler: OK, testing now. Thanks for that!
<str1ngs>lxsameer: yes, certain build systems assume certain packages are available
<lxsameer>str1ngs: cool
<str1ngs>lxsameer: also you might see something like when installing something to your profile the first time. say you install bash it will download packages needed to setup a profile
<str1ngs>like that*
<lxsameer>str1ngs: cool
<str1ngs>lxsameer: -f is mostly useful when you have one custom package outside of guix.git. with ./pre-inst-env you can use guix as you normally would. but it's using packages etc from guix.git tree
<lxsameer>str1ngs: cool, thanks. Now I have another problem to fix. thanks mate
<str1ngs>no problem lxsameer
<efraim>i can never remember for symlink if the source or the destination goes first
<str1ngs>src -> dst
<efraim>so just like 'ln -s' afterall
<str1ngs>oh is this a system call in scheme?
<str1ngs>it's the same with 'symlink
<nckx>I have the same with ‘mount’.
<nckx>Never right on the first try.
<str1ngs>efraim: its the same in C
<efraim>i guess that's why it's like that in scheme then
<efraim>near the top of 'git grep \(symlink' '#~(symlink (string-append #$bash "/bin/bash")' makes it hard to get confused for the future
<str1ngs>rsync can be a pain if you try ./foo/ it will re base all the directories vs ./foo
<str1ngs>err entries rather
<brettgilio>leoprikler: did you make a comment on my WIP SMLnj package yesterday?
<numerobis>Hi #guix! Is anyone using Jupyter on guix system? I get an error - The 'ipykernel' distribution was not found - when I try to run 'jupyter-notebook', although python-ipyernel is installed.
<numerobis>ah wait, it seems to work now. Thanks!
<kmicu>numerobis: your are welcome ;P
<leoprikler>brettgilio: I don't think so, but I might misremember
<leoprikler>ah, I remember again
<leoprikler>I asked whether you could package its components individually instead of putting them together in this manner
<brettgilio>leoprikler: I could. But it would seem very superfluous and odd imo as the components by themselves do not work stand-alone. It's a subversion repository with several directory checkouts.
<brettgilio>Idk it's kind of an odd repo
<brettgilio>So idk how to handle it "correctly"
<leoprikler>I thought so, hence my "git submodule in 1969" comment.
<brettgilio>leoprikler: yep, you are spot on.
<brettgilio>It's really a mess to try and package.
<roptat> :/
<brettgilio>roptat: people are so harsh lol
<roptat>Yeah but it's bad if our video tutorial doesn't work
<brettgilio>Instead of filing a bug report. Just blast us on mastodon, cus that is how things get fixed right?
<roptat>Precisely, because we have eyes everywhere :)
<brettgilio>Guix tech support for Google plus? I nominate nckx :)
<wingo>lol :)
<jonsger>I could watch diaspora, if my server would still be alive :P
<brettgilio>Gtg for now. Back later
<civodul>leoprikler: "guix install guile@2 guile@3" will error out, unless you pass --allow-collisions
<civodul>comrades, the future starts today!
*kmicu checkes whether Typed Guile is a thing in 3.0 xD
<civodul>that's for Guile 4 :-)
<bzp>hi all
<kmicu>Better perf for free. That’s what we get for using eDSL.
<bzp>Hello everyone, I am trying to install manually, can you tell me what I am failing with my "config.scm" configuration file, please.
<bzp>guix system: error: invalid field specifier
<civodul>bzp: there's an extra paren right before %base-file-systems
<civodul>that triggers this misleading message
<civodul>well there's another paren issue just above
<civodul>i'm surprised we don't get source location info in the message, though
<bzp>Is my partition configuration well declared? I could not label the partitions
<holyKau>If anyone's running wayland with sway, can you please share you config.scm?
<sneek>Welcome back holyKau, you have 1 message.
<bzp>This is my way of formatting the 4 partitions (/ boot, /, swap, / home). I do it this way:
<bzp>mkfs.ext4 / dev / sda1
<bzp>mkfs.ext4 / dev / sda2
<bzp>mkfs.ext4 / dev / sda4
<valignatev>Hey Guix! I know it's kinda wrong channel, but I still want to give my congratz to all involved in Guile 3.0 release! Yay! <3
<bzp>mkswap / dev / sda3
<bzp>swapon / dev / sda3
<bzp>mkdir / mnt / boot
<bzp>mkdir / mnt / home
<bzp>mount / dev / sda2 / mnt
<bzp>mount / dev / sda1 / mnt / boot
<bzp>mount / dev / sda4 / mnt / home
<jonsger>bzp: please use a paste service
<bzp>jonsger: how do I do that?
<jonsger>bzp: copy your stuff e.g. here and give us the link
<bandali>hiya and congrats y’all
<lxsameer>how can i get the address of the downloaded package direcotory?
<holyKau>anyone running wayland?
<bandali>lxsameer, hi, doesn’t ‘guix download’ print that?
<lxsameer>bandali: i mean in guile
<lxsameer>is it like (assoc-ref %input "source") ???
<bandali>ah, i’m not sure. i’d look around in existing package definitions i guess?
*civodul builds guile@3
<lxsameer>bandali: already did that but it made me more confused
<bandali>i don’t i can help personally, but for the sake of others, i’d also describe what you’re trying to achieve and what you need that address for
<bandali>i don’t *think i …
<lxsameer>So i need to get the address of the cloned source for my package to copy its files using `copy-recursively` to the output directory
<bandali>lxsameer, see the (gnu packages gnuzilla) module, in particular, look for “gnuzilla-source”
<lxsameer>bandali: that's not what i'm looking for
<lxsameer>i'm using a trivial-build-system
<bandali>what difference does it make?
<lxsameer>i already created the `source` field
<lxsameer>now i want to copy from source directory to out in #:builder section of trivial-build-system
<bandali>the important part is you ‘let’-bind the ‘source’ field, and refer to it further down
<bandali>i think the icecat-source package is an example of that, which you just dismissed
<bandali>if i’m wrong, hopefully others can help
<lxsameer>bandali: yeah i know about lisp. i'm looking for a function to give me the source path
<lxsameer>bandali: for example i know that (assoc-ref %output "out") returns the out directory path
<bandali>lxsameer, so the examples of ‘copy-recursively’ in (gnu packages gnuzilla) aren’t similar to what you’re trying to do?
<lxsameer>bandali: that's what i'm using but for example i need to know how to get that "local-dir" ( i mean the function the gives me the path to my source directory )
<gnutec>GNU Guile 3.0.0 is here.
<bandali>lxsameer, can you not directly pass the ‘source’ record to ‘copy-recursively’? that seems to be what gnuzilla-source is, in the icecat-source definition
<joshuaBPMan>does anyone have a channel with unrar in it?
<gnutec>joshuaBPMan: I can't extract a rar file. And I hope everyone change to LZIP, that is much better. The guile 3.0.0 compare.
<bandali>i think bsdtar and unar (unarchiver) are free alternatives to unrar, but i think both are absent from guix
<efraim>is bsdtar also named libarchive?
<bandali>oh, so it seems
<bandali>or rather, bsdtar seems to be a part of libarchive
<joshuaBPMan>bandali: can you send me a link of where I can download / install unar or bsdtar?
<bandali>joshuaBPMan, if you’re on Guix System, try installing libarchiver, it may contain bsdtar
<bandali>if you’re on another distro, it may already have bsdtar, unar, and/or unarchiver packages
<roptat>Don't we have a package for unar now?
<bandali>apparently not ?
<joshuaBPMan>bandali: I'll give that a try.
<bandali>though i haven’t guix pulled in a few days so…
<roptat>Oh no we don't
<roptat>I thought we already had that conversation here
<roptat>And I remember someone came up with a package definition… maybe it's still waiting for a review? I'll check
<roptat>I can only find 28972
<roptat>Removal of unrar
<jonsger>building guix with guile 3.0 feels at least faster
<roptat>Exciting :)
***ng0_ is now known as ng0
<bdju>Got a build failure for neomutt. Just booted up my Guix System machine for the first time since 2019 sometime and I started running updates.
<nckx>bdju: Had literally just started a build of neomutt to see what's up. (I'm updating lmdb & neomutt is a dependent.)
<nckx>Oh. I'm betting the tests can't cope with the year change.
<nckx>mutt_date_localtime.c:61: Check tm.tm_yday >= 119... failed
<nckx>Whatever that means.
<nckx>bdju: Update pushed.
<bdju>Nice! I'll try again in a sec. I'm in the middle of an update skipping neomutt.
<lxsameer>hey folks, how can i extract a tarball in guile ?
<nckx>brettgilio: The actual fuck my friend? Why do you hate me? ;_; (Also Wiki-p says this Plus business shut down last year, do you mean LinkedIn.)
<brettgilio>nckx: hahaha :).
<nckx>lxsameer: I strongly recommend just calling ‘tar’, using SYSTEM or (in Guix) INVOKE. Something like (invoke "tar" "xvf" (assoc-ref %build-inputs "source") or (invoke (string-append (assoc-ref inputs "tar") "/bin/tar"). Those are just two random examples from gnu/packages.
<gnutec>guix is using LZIP. This mean something.
<lxsameer>nckx: ok thanks
<zimoun>brettgilio, roptat: I am looking at ocaml.scm for examples about package-with-explicit-<lang> and I see the variant ocaml-4.01; symbol in default-ocaml4.01 if I understand well. But I do not find ocaml-4.01 in (gnu packages ocaml). Is it expected? Does this code about variant still work?
<roptat>Ah no it doesn't work
<roptat>4.01 was removed last year, we probably forgot about that bit
<bdju>Looks like openjdk has a build failure also. I'll start updates again now since neomutt should be fixed at least.
<zimoun>so today, it is only possible to build ocaml package with the default ocaml, currently ocaml-4.07. Right?
<zimoun>ok, but should this piece of code still make sense to keep 4.07 and 4.09.
<roptat>zimoun: not the 4.01 part, but anything left, let me see
<roptat>I guess if we have an ocaml 4.09, we can s/4.01/4.07/g in that file (if we make 4.09) the default
<zimoun>roptat: yes, replace default-ocaml4.01-findlib and default-ocaml4.01 by the correct new ones.
<roptat>Any reference to 4.01 is safe to remove
<zimoun>ok, let the code for now and see if 4.09 happens soon, then s/4.01/4.07/g :-)
<roptat>The real difficulty is that we'll have some duplicate packages that don't fit well with package-with-explicit-ocaml
<roptat>None of the janestreet packages support both versions in any version, and there dependency graph was rewritten between 0.11 and 0.13
<roptat>But I might be able to come up with something. It means lots of duplicates and new packages, but we can do it
<roptat>I mean, bap is not compatible with 4.09 and requires the janestreet packages, which is why we would need both variants for them
<zimoun>I see. My point of view is: the default is supported which mean Guix ensures it works. Other can be tried by the user without any guarantee. Or the user can build its own packages with the other version than the default one if they knows it will works; otherwise it is painful, even when the user knows their packages compile with several versions
<zimoun>I understand.
***MinceR_ is now known as MinceR
<roptat>I can push an ocaml-4.09 without making it the default tonight, and we can see what to do from there. How does that sound?
<zimoun>Sounds good! :-)
<roptat>I would like to have an upgrade plan that doesn'tbreak anything at intermediate comnits, but it looks difficult
<roptat>Not sure if it's possible at all…
<zimoun>Larger picture: I would like to be able to compile my OCaml packages with all the OCaml compilers we have. Easily :-)
<zimoun>Not know neither
<roptat>That's clearly beyond the goal of what I'm trying to do :p
<roptat>I'd like to have the latest ocaml, but keep packages that haven't migrated yet
<roptat>We don't generally keep multiple versions of packaqes, so I'm not sure this is a goal of guix either
<roptat>We could build our own channel to maitain multiple versions of the ocaml compiler and software though
<roptat>Like I do with the coq channel
<zimoun>Yes for sure. Pragmatical is always better. But I feel a piece is lacking kind in the build systems. I mean, OCaml has code for variant, which looks very similar to Python one. Now I am looking at supporting 2 versions of R. We can think to build with GCC 7 or 8 or 9. From my point of view, it should be easy to tweak the compiler behing the build system; at the end-user level (CLI or package definition level, e.g., properties).
<zimoun>I am not sure neither multiple versions should exist, but I find useful to have an interface to easily change the compiler of any build systems.
<NieDzejkob>nckx: Well, in response to a cursed idea, one does not simply answer "yeah, this is running in production"
<zimoun>For example, the package Gmsh which is C++ but does not depend explicitely on GCC, so it is not easy to compile it using GCC 7 or 8 or 9. And I would like to do that, for example to compare performances or see if one bug is present using this compiler or not in this other one.
<drakonis>NieDzejkob: that's very metal.
<sneek>drakonis, you have 1 message.
<drakonis>actually how do i get those messages?
<zimoun>For sure, it is combinatorial and Guix cannot support. Guix ensures that the default works. But when doing research, I need to be able to compare different versions; tweaking implicit inputs.
<drakonis>sneek: message
<drakonis>i dont get it.
<bandali>it used to automatically play them back when you spoke
<roptat>drakonis: sneek should give it to you immediately
<bandali>sneek, botsmack
<roptat>sneek: botsnack
<drakonis>damn it sneek
<roptat>zimoun: I can probably come up with some generic package-with-explicit thing
<roptat>If that's what you're asking for
<drakonis>i suppose the next guix release will be the one where guile 3.0 is the default guile for guix?
<bandali>drakonis, okay, here’s what sneek was supposed to tell you:
<bandali> <NieDzejkob> sneek: later tell drakonis: yes, this is me (re: cursedfs)
<bandali>that’s from my logs
<drakonis>i actually read the logs
<drakonis>guix is publicly logged, but yes.
<bandali>ah yeah, forgot the channel is publicly logged
<efraim>what's the guix hpc website?
<refpga>Hello, I'm using Simple Login manager (Slim) and it runs in -nodaemon mode with CPU usage 100% (one complete core). It's configured as shown here: Has anybody encountered this before? I suspect because of this my cpu temperature reaches 100°C quickly.
<efraim>did we drop the guix.d subdirectory for emacs packages?
<efraim>bandali: thanks
<bandali>efraim, cheers
<drakonis>for a moment i thought i saw hyperbola
<apteryx_>efraim: yes
***apteryx_ is now known as apteryx
<apteryx>(we did drop the emacs.d subdir for emacs packages)
<apteryx>err, guix.d
<efraim>apteryx: I thought so, but there are still some with it
<apteryx>OK :-(. They need to be adapted.
<zig>Oh! I just found out about
<zig>I will make more useful feedback when I watch them, but in the mean time I want to say I love the font in the presentation :)
<NieDzejkob>re: sneek eating messages, maybe it's a rate limit of freenode?
<NieDzejkob>hmm, my immediately-sent x got received just fine
<zimoun>roptat: I am asking for to see build-systems as a function where the compiler is an argument :-). Then I do not know what is the correct level to modify and provide such argument. And I am not convinced that package-with-ocaml4.01 package-with-ocaml4.07 package-with-ocaml4.09 etc. is the right abstraction. Something like (package-with-<build-name> <version>) seems more appropriate, or using the properties of the package.
<NieDzejkob>refpga: slim is running with -nodeamon, but (at least when logged in) the CPU usage is 0
*apteryx is fixing inkscape on core-updates
*NieDzejkob is getting excited after discovering that a 7-way filesystem polyglot is plausible
<finfin>has anyone got the Nim compiler working on Guix? I got a really bizarre error i can't seem to diagnose (
<NieDzejkob>finfin: try running it under strace, paste the log
<bavier>nckx: thanks for the handbrake update
<nckx>bavier: Fellow handbrake user, does the ‘Close’ button in the Help → About dialogue work for you? Here it doesn't. I'm not going to debug this but it's odd.
<bavier>nckx: yup, not working here either. now that you mention it, I vaguely recall the same in version 1.3.0
<Gooberpatrol66>a recursive importer for gentoo ebuilds would be awesome. has anyone tried writing one?
<nckx>bavier: Thanks! That's possible, I never checked it before the update.
<nckx>Gooberpatrol66: Someone mentioned it last year and we had a very brief discussion about ebuild parsing, but I don't remember who or where. I doubt anything came from it.
<Gooberpatrol66>ah ok
<Gooberpatrol66>i probably know enough about ebuilds to do it, but i barely know anything about lisp or how the other importers work
<zig>read the manual Gooberpatrol66, there is a tutorail about guile scheme (the lisp used in guix)
<NieDzejkob>finfin: I reproduced the problem, I'll send a patch that fixes this to the ML in a moment
<jonsger>it's nice how few processes run on a basic Guix system :)
<moesasji>Hi all; is there any logic why I see multiple occurrences of gtk+-3.24.12 as to be downloaded when running "guix install emacs-next --dry-run"? The weird bit is that 2 out of the 3 even have the same hash.
<str1ngs>moesasji: and if you do guix build emacs-next? does it download only one?
<moesasji>Just tried. It only downloads one; the links that end with -bin in the dry-run are missing when omitting the --dry-run.
<finfin>NieDzejkob, hi, sorry for not reporting earlier, have you managed to find a workaround around this issue?
<pkill9>moesasji: the -bin means it's the 'bin' output of the package, you can see with 'guix show gtk+'
<sameerynho>hey folks, i'm trying to pull from savannah: "fatal: unable to access '': server certificate verification failed. CAfile: none CRLfile: none"
<pkill9>i assume that it's going to use that to build something from source
<moesasji>pkill9: the question is why it features twice in the list when using --dry-run with the same hash.
<pkill9>can you post the output in a pastebin moesasji ?
<pkill9>sameerynho: you may need nss-certs (i think that's the name of the package) in your system packages
<moesasji>here it is pkill9:
<sameerynho>pkill9: still the same
<sameerynho>pkill9: installed nss-certs using guix
<pkill9>moesasji: maybe best to send a bug report
<pkill9>sameerynho: did you logout then in?
<pkill9>i think it may set some environment variables
<sameerynho>pkill9: ok let me try
<roptat>zimoun: I might have thought of a plan
<roptat>And remembered there was a wip-ocaml branch or something, I need to check it
<roptat>also we had a talk on the legion programming language, which might be of interest to HPC people :)
<roptat>so the plan: add ocaml-4.09 and findlib, add package-with-ocaml4.09, then update any package not from janestreet to a version that can compile with both compilers, then switch with a renaming of janestreet packages and use of #:ocaml and #:findlib arguments in those and dependents, finaly reimport janestreet packages in their latest version for ocaml 4.09 and switch any dependent that supports 4.09
<roptat>and legion is this: