<NieDzejkob>you need a pam-service, and yubico-pam seems to only be a package? <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]>I got it working in the past in Debian following yubico.com 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? <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 <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 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 <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 :) <leoprikler>so wait, these things can not be packaged individually? <nckx>Gooberpatrol66: gnu/packages/patches and ‘registered’ in gnu/local.mk. <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. <nckx>It contains all ‘official’ patches that are applied to Guix packages. <nckx>Gooberpatrol66: ☝ and just use search-patches as usual. If you put them elsewhere you're on your own. (Been there, don that.) <roptat>formal method people might be interested <nckx>A first news post for formal.guix.gnu.org is born. <leoprikler>Doesn't every major SMT solver use smtlib in some form or another though? *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>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>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>z3-eval-smtlib2-string is the foreing function Z3_eval_smtlib2_string <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. <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>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! <plasma41>See the manual for the installation instructions[...] by running <plasma41>The file guix.info 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? <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 <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 :( <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>i dont know if it can actually recreate the sqlite db <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>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) ***modula is now known as defaultxr
<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 <str1ngs>peanutbutterandc: between nckx and myself we figured out it was just taking a real long time to build. <str1ngs>I'm not sure about moving to guile 3 yet. I suspect that's not something to be rushed. <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 <peanutbutterandc>str1ngs, I see. It says 100% substitutes available. However, It isn't giving me back the terminal prompt. Is that to be expected? <str1ngs>peanutbutterandc: that's expected. guix build mercurial should download the substitute <peanutbutterandc>I see. Perhaps it should be redone to quit after it shows the information? <str1ngs>peanutbutterandc: -> /gnu/store/jyzy8gldr2p4qddi8qy59d391smb2r5n-tuxguitar-1.5.3/lib/libtuxguitar-alsa-jni.so <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: does the fret board make sound when you click on it? <str1ngs>lol I'm trying to click out a G chord.. and I actually have to think about it <peanutbutterandc>str1ngs, I usually do ukulele tabs. So I just thought of a D-shape. lol. <str1ngs>peanutbutterandc: do you have alsa utils installed? <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. <peanutbutterandc>Strange... guix upgrade seems to be upgrading basically everything. Wonder if it is the mercurial thing <str1ngs>peanutbutterandc: is this the first time you did guix pull? <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 ? <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>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? <peanutbutterandc>str1ngs, Flatpak 1.2.5, as supplied by the debian maintainers on debian 10 <str1ngs>right but lets pretend I don't use flatpak an only guix. what version is tuxguitar in flatpak? <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. <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 <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... ? <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. <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. <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. <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? <lxsameer>nckx: nope, apparently i messed up my source tree some how <lxsameer>nckx: i installed bunch of packages using guix but now they do not exist in my profile <lxsameer>i'm guissing that something is wrong with my guix installation <lxsameer>str1ngs: missing dependencies, and I'm installing them one by one but I installed them once before. <lxsameer>str1ngs: they are missing from my profile <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? <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 <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 <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? <g_bor[m]>there is no need to provide input at all. <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 <nckx>str1ngs: No, it's the Scheme wrapper that hangs, it's not a subcommand waiting for 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. <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. <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 <str1ngs>lxsameer: also have you done configure and make? <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.) <str1ngs>lxsameer: try with ./pre-inst-env guix build <package> <str1ngs>using -f in this will will probably trow an unspecified error <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" <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>the other option would be to do the renaming at the same time <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? <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>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 ? <str1ngs>lxsameer: yes, certain build systems assume certain packages are available <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>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 <efraim>i can never remember for symlink if the source or the destination goes first <nckx>I have the same with ‘mount’. <nckx>Never right on the first try. <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 <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. <kmicu>numerobis: your are welcome ;P <leoprikler>brettgilio: I don't think so, but I might misremember <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. <leoprikler>I thought so, hence my "git submodule in 1969" comment. <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 :) <jonsger>I could watch diaspora, if my server would still be alive :P <civodul>leoprikler: "guix install guile@2 guile@3" will error out, unless you pass --allow-collisions *kmicu checkes whether Typed Guile is a thing in 3.0 xD <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>mount / dev / sda2 / mnt <bzp>mount / dev / sda1 / mnt / boot <bzp>mount / dev / sda4 / mnt / home <bzp>jonsger: how do I do that? <lxsameer>how can i get the address of the downloaded package direcotory? <bandali>lxsameer, hi, doesn’t ‘guix download’ print that? <lxsameer>is it like (assoc-ref %input "source") ??? <bandali>ah, i’m not sure. i’d look around in existing package definitions i guess? <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 <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>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 ) <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 <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>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>though i haven’t guix pulled in a few days so… <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 <jonsger>building guix with guile 3.0 feels at least faster ***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 <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.) <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. <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>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 ***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? <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 :-) <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 <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. <sneek>drakonis, you have 1 message. <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. <bandali>it used to automatically play them back when you spoke <roptat>drakonis: sneek should give it to you immediately <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>ah yeah, forgot the channel is publicly logged <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: http://ix.io/27zh. 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? ***apteryx_ is now known as apteryx
<apteryx>(we did drop the emacs.d subdir for emacs packages) <efraim>apteryx: I thought so, but there are still some with it <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 <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>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+' <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 <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 <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