<sameerynho>daamn, getting segmentation fault when i build guix from source ***akko is now known as stallman
<str1ngs>hello, is there a build argument to specify the build directory? or do I just need to add a phase before 'build that changes the build directory context? <leoprikler>str1ngs: If it's something simple, do a pre-build chdir. <leoprikler>If it's a little more complicated, use directory excursions, as in my newly updated renpy build đď¸ <str1ngs>leoprikler: I'm pretty sure in this case its set once and that's it. <jonsger>uff guixs php is to new for nextcloud. It only runs with 7.3 and we only have 7.4 <plasma41>So the page at https://guix.gnu.org/manual/en/ indicates that the version of the manual there is 1.0.1. While that is true for the "HTML, with one page per node" version, the "HTML, entirely on one page" version and the PDF version are newer than 1.0.1 (master branch?). <str1ngs>leoprikler: I would use with-directory-excursion but then I need modify 'build I guess. unless there is another way <str1ngs>leoprikler: I guess I'm just looking for syntax sugar if it's available. <plasma41>I'm specifically looking at section 14.1 in the manual. <leoprikler>Not AFAIK. Guix makes the assumption that most source tarballs are reasonable in the sense that they put build information in the top directory. <plasma41>The relevant source file for that section of the manual is the file doc/contributing.texi in the guix git repo. <str1ngs>leoprikler: make sense, but there is always that one upstream guy! lol . there worst are the ones that do not have leaf directory. and put everything in the root tarball. <leoprikler>well, for a small enough project that works fine <leoprikler>it's worse, if you have something like a full maven-style build tree at level 2. <sneek>sameerynho, you have 1 message. <leoprikler>sameerynho: is this unmodified guix or modified guix? <nojr>Hi, how do I install node packages with NPM? <leoprikler>You don't, you package them via guix and node-build-system đď¸ <nojr>I'm trying to install ember with npm i ember -g but I get the following error (first line, the stack trace is longer): npm WARN checkPermissions Missing write access to /gnu/store/4lv33i2jqpirirvyrgw4nb3ghn89rfw6-node-10.16.0/lib/node_modules <nckx>sneek: do you still crave the botsnack. <sneek>From what I understand, love is baby don't hurt me, don't hurt me, no more. <nojr>@leoprikler I'm new to guix and I've never packaged a library <nojr>so when I guix package -A node I get: <nckx>sameerynho: Is your guix-daemon running? Can you restart it? <nojr>sameerynho: the locale warning ? <leoprikler>there should be some people using node on the webz, lemme check <nckx>nojr: No, âwriting to file: Broken pipeâ. <nckx>The locale warning is as harmless as it is annoying. <nojr>nckx: there's a way to fix that actually, I asked a while back <nojr>nckx: yeah someone here helped me a while back <nojr>so just to confirm, if I want to install npm package I have to packaged them and upload them to guix? <nojr>the locale issue can be fixed with <nojr>in /etc/systemd/system/guix-daemon.service, there should be a line that starts with Envionment=..., this should read Envionment[filtered]=... <nckx>nojr: Yes, and packaging npm is usually horrible due to the insane number of dependencies. There's currently no painless combination of npm + Guix of which I'm aware. <leoprikler>not necessarily upload them to guix, because that involves waiting time on reviews until you can use your package <nckx>sameerynho: I guess so, how exactly that's done depends on your distribution. systemctl restart guix-daemon, or something? <leoprikler>there are a number of ways, in which you can use a package, that has not yet made it to guix itself. Package files, package paths, channels⌠<leoprikler>so the real hurdle will just be writing an insane amount of package definitions <nojr>leoprikler: yeah I'm aware, I actually been trying to learn how to package but I run into issues when going through the tutorials <sameerynho>nckx: restarted the daemon and the pull is all ok now, i'm trying to rebuild guix from source <nckx>nojr: What kind of issues? <nojr>nckx: the first part in the tutorial says to use guix environment --pure guix --ad-hoc coreutils findutils which, then in the second part it uses the guix import command and right afterwards it creates a new branch in the guix repo, but previously it was not installed in the pure environment? ***stallman is now known as akko
<nojr>so, it was a bit confusing, should the command read `guix environment --pure guix --ad-hoc coreutils findutils which git'? <nojr>also the video uses the guix command without ./pre-inst-env and then goes back to use ./pre-inst-env in the end of the tutorial <nckx>jonsger: So this /usr/lib64 is coming (ominous voice)⌠from inside the --pure environment? <nojr>but I can recall when I tried to follow the tutorial I could not use `guix' like it does in the second part. Therefore, I was very confused <nckx>nojr: s/it/git/ in your message @me? <nckx>nojr: What's âthe tutorialâ? <leoprikler>nojr: you can use multiple shells at the same time <nojr>nckx: "Packaging, Part One and Packaging, Part Two" if you scroll to the bottom <leoprikler>best praxis is to not contaminate your build environment (i.e. `guix environment --pure guix`) with other packages <nojr>leoprikler: so should I `guix environment --pure guix --ad-hoc coreutils findutils which git' <leoprikler>if you don't have multiple shells available in a simple manner, you can also do stuff like `guix environment --pure guix -- make` <nojr>and use the ./pre-inst-env command? <leoprikler>no, I'd rather advocate against coreutils as well <leoprikler>btw. pre-inst-env does not care about whether or not you're inside a guix environment <nojr>ok. I'll try to read over the manual, I think there is more info in the cookbook pdf <nojr>btw I did a guix package -A node and I don't see any node packages yet? only several that have to do with emacs. I'm guessing if there were they'd be name something like "node-emberjs" for example <nckx>nojr: Problem is I don't have sound and can only read the text, but it's not how I tend to do things (assuming all these commands take place in the same session). I only enter the environment when bootstrapping, configuring, or making guix. I do everything else (including ./pre-inst-env guix build my-package) outside of it. <nckx>nojr: AFAIK the only node package we have is node. <nojr>nckx: I think that's why the tutorial was a bit confusing because it does not explain the commands <nckx>Without the sound, I tend to agree. <nojr>nckx: so why does the tutorial use guix environment --pure then? <nckx>nojr: I don't actually use âguix environment --pure guixâ to enter an environment, I run something like âguix environment --pure guix ⌠-- sh -c "./bootstrap && ./configure && make"â. That's an incomplete example but the point is when it finishes, you're not âinâ any kind of environment, and can use emacs & git & ./pre-inst-env guix as always. <nckx>nojr: You want to use --pure while building; you just don't want to hang around in that human-hostile pure environment after the build (make) is complete. <nojr>nckx: the last step in Part One of the tutorial is `make' <nojr>how do I then leave the environment? afterwards <nckx>nojr: âexitâ or C-d. As I noted above, I'd've added that as the extra last line of that video. <nojr>leoprikler: I think thats what I did last time... <nojr>Ok, thanks. So, I tried this almost 3 months ago. I'll give it another try again this weekend. I think I understand a bit better how it all works together. ***jonsger1 is now known as jonsger
***dftxbs3e_ is now known as dftxbs3e
***jonsger1 is now known as jonsger
<apteryx>is it possible to import module symbols in the bulid system using a prefix? <apteryx>but you can use #:imported-modules and then refer to the symbol using the (@ (module name) symbol) hack. <roptat>zimoun, I pushed ocaml-4.09 to master. I haven't changed the default ocaml, so we should be fine <roptat>mh... I think I modified the ocaml-4.07 package though, so there's going to be a rebuild of the whole ocaml packages... 166 of them, that's fine I guess <roptat>anyway, part 1 of the plan is completed :D <drakonis>sneek: later tell NieDzejkob: can cursedfs be used to create a guix install image and have usb storage visible to windows? <refpga>NieDzejkob: About Slim running in nodaemon, are you using Slim version 1.3.6? <refpga>NieDzejkob: Can you share your Slim service configuration? <efraim>bayfront is almost out of space, I'm going to slowly try to free some up ***Noctambulist is now known as Sleep_Walker
<kmicu>Iâm surprised Guix users donât run out of inodes on ext4. (That was a common issue on Nix) (Or maybe we are all on btrfs 𤡠đş) <sneek>Welcome back civodul!, you have 1 message! <sneek>civodul, dsmith says: Topic needs updating! <nckx>kmicu: Was it? I don't remember that. I'm on ext4 with only 16% of inodes used. 89% of those are used by my 197G store, though. My drive is 94% full. <kmicu>nckx: yep, many many times. âHelp I cannot update my system but I still have a disk space! â youâve run out of đ inodes đ (on ext4)â. What a classic. <civodul>i'm a bit concerned about the Rust situation <civodul>now we have lots of packages but we haven't sorted out the "inputs" story *kmicu just checked nix logs. running out of inodes (on ext4) is still a thing. <kmicu>âBtw, any ideas why the manual installation instructions still recommend ext4? I read that with all the small files in the store there's the danger of running out of inodes.â I miss inodes meme. <kmicu>A genuine issue reported by users many times on Nix. ***w2gz is now known as w1gz
<kmicu>(only on ext4, not others like btrfs, btrfs allocates upto 2^64 inodes as needed) <kmicu>If you read its manual then btrfs is solid and has all those nice features. No issues since almost a decade here. No issues on Nix, no issues on Guix for me. <kmicu>(my SSD is also happy even after almost a decade of Nix/Guix fun) <kmicu>(personal usage with casual kernel/emacs compilation, no CI) <kmicu>â<betaboon> gchristensen: removing those logs resulted in freeing enough inodes to run `nix-collect-garbage -d`â guix needs inode memes pls *kmicu shuts up cuz Rust situation in Guix needs attention *civodul walks through the remaining Guix test failures on Guile 3 <efraim>I'd rather not overload {propagated-,native-,}inputs and say any rust-foo inputs are automatically source. IMO it would be better to add a source-input field and have the build system decide what to do with it, if anything <efraim>It would also limit our (package-source foo) inputs somewhat <efraim>We could add/override 'guix refresh -l foo' to really be 'guix refresh -l -e (package-source foo)' <abralek>Hi all does anybody working on openjfx packaging? or maybe has some ideas? I need to package it properly to provide GUI features for davmail. Davmail uses jfxpanel and friends in case of oauth2. <abralek>I am going step by step and managed to compile half of the libraries. But not sure if it is worth it or not. Can we just run gradlew and move files wherever we want? <leoprikler>What does gradlew do? Magically download all dependencies and build everything like e.g. npm? <abralek>Well yes. It also uses precompiled bundle gradle-wrapper.jar <abralek>In my case It didn't download anything <abralek>I used an existing java-openjfx-build source <zimoun>roptat: sorry, I was logged but sleeping. ;-) <zimoun>roptat: the plan sounds good! Cool! And thank you for the Legion pointer. <Parra>hey Guixers I want to mix two build systems and in addition, one of them must run in a different folder, how can I do that? do you have any example? should I run a cd command before first step? <Parra>one of them is node-build-system <Parra>another thing is that I have to copy some generated files from one package to another, as input packages but in a specific folder too <civodul>Parra: the 'build-system' field is only one build system <civodul>however, there are cases where we use phases of another build system in addition to those of the chosen build system <Parra>I've seen that in some emacs modules like howm <Parra>and I have no idea how to set the base path neither <Parra>because those pashes must run in another folder <bricewge>How do you test if you are on a Guix system? <bricewge>I want to patch some scripts but we don't have /etc/os-release (#34154) here. So how do you do this? <str1ngs>[[ -s /run/current-system/profile ]] && echo "Guix" || echo "Not Guix" <str1ngs>that's still brittle but there is no lsb_release as far as I know for guix <civodul>bricewge: you could test for /gnu/store and /run/current-system but... i think testing for OS identity is brittle :-) <str1ngs>bricewge that only works for guix system won't work for foreign distros. I'm assuming that is what you checking for? <Parra>is there any doc about changing a folder and mixing build systems? <civodul>Parra: to change directories you can call 'chdir', as in: (chdir "foo/bar") <bricewge>str1ngs: Yes I want to identify Guix OS. <bricewge>What you answered will do and won't mistake NixOS from Guix. Thanks (: <civodul>there's no doc about mixing build systems tho <Parra>@civodul: but I can put that line arbitrarily? <str1ngs>bricewge: I would test for /gnu/store as well as and added measure ad civodul suggested. <civodul>Parra: there are quite a few packages that add a phase that calls chdir <Parra>I think doc is very necessary, for new users like me that don't know guile either <Parra>the docs I've found are for basic usage only, and I need to do more complex things <civodul>it goes into more details on packaging <Parra>civodul: I do, I know lisp too but guile has its own framework and function definitions, which I don't know, like chdir for example <Parra>I will re-read it in more detail thought, thanks for the link <bricewge>str1ngs: Will do. For sure such testing is fragile but it's only for some personal scripts. <Parra>code-staging has what I was asking for <str1ngs>bricewge: you can also have config.scm create a unique file in /etc/ it could even contain meta data. <str1ngs>bricewge: the only draw back is it would not work on systems not already configured. <civodul>is news.gmane.org (NNTP) down for everyone? <civodul>looks like it's been down for a couple of days already <bricewge>str1ngs: I need to work on a fresh installed system otherwise I would have applied #34154 or as you suggested a file in /etc with s-expressions. <Moondhum>what is the difference between gnu packages and gnu system? <str1ngs>Moondhum gnu packages has package definitions. gnu system is used to create guix system and vm's etc <bricewge>Moondhum: Guix System is the OS, it use the guix package manager to install guix packages. And it happen to be that you can use guix the package manager on other OSes. <civodul>zimoun: oh, thanks for the link, definitely related! <zimoun>you are welcome. :-) Is the sync done? <lxsameer>hey folks, is there any way to force a rebuild for a package ? <str1ngs>lxsameer: guix build --no-substitutes --no-grafts --check <package> <lxsameer>str1ngs: thanks, and when i use (system "tar ...") it complains about a missing tar command, should i add tar as an input ? <str1ngs>lxsameer: though if your package should rebuild if you change it. are you using git for source? <str1ngs>lxsameer: sorry what I meant was. if you change the package it should rebuild no need to force a rebuild. <lxsameer>str1ngs: and what is the convention for tools that are necessary only for building other tools ? should i define them publicly or private to my namespace ? <str1ngs>lxsameer: guix gnu packages are exported as modules bindings. for your own personal packages you can use your own convention <lxsameer>str1ngs: even if I want to contribute it to the official repo? <str1ngs>if you plan to contribute to the official repo. the convention is each package binding is export at the module level. <str1ngs>so in order to use bash you need to use (gnu package bash) since bash is in the bash module. <str1ngs>lxsameer: you can test this in a guile repl. ,m (gnu packages bash) then ,b to see all the bindings <str1ngs>lxsameer: if you use define-public to define your package that should be enough. <kmicu>Whoa, the recent blog post is as good as itâs long. *kmicu genuinely thought that âReaching closureâ header was an epilog xD <Moondhum>(use-modules (gnu packages wayland)) Is this correct? <civodul>kmicu: it's a bit long but i find it pleasant to read <kmicu>Yeah, itâs. Itâs really good and final words âcongratulations for having survived to the end of this long journey! May all your computations be reproducible, with Guix.â are so sweet Ęăâ˘á´Ľâ˘Ęă ︾ âĽâ¤âŁđďťż <str1ngs>Moondhum should be (use-modules (gnu package freedesktop) <kmicu>(and that thing with Python and Perl in pure C will hunt me in my nightmares ;) <str1ngs>Moondhum use guix show wayland to see what module it is in. eg. location: gnu/packages/freedesktop.scm:556:2 <str1ngs>Moondhum should be (use-modules (gnu packages freedesktop)) <str1ngs>I had a typo and missing parentheses <str1ngs>sneek later tell peanutbutterandc. you will still need to use timidity to produce sound. <jonsger>guix environment: error: cannot create container: user namespaces unavailable <jonsger>guix environment: error: is your kernel version < 3.10? <jonsger>But the example program from `man user_namespaces` works. needs some further investigation from my side... <roelj>If I add a patch file in the âoriginâ of a package, how do I see whether the patch was applied before building? <lxsameer>is there any specific reason why there is no openjdk8 on the repo ? <nckx>lxsameer: Because it was added at version 9, and Guix doesn't collect old versions of things unless there's a good reason. <lxsameer>nckx: i see, but i guess for java including jdk8 make sense. Since it's widely in use in production these days <nckx>lxsameer: Wouldn't icedtea@3.7 fill that hole? I read that it matches JDK8 but I'm not a Java person. <lxsameer>nckx: never used, i have no idea about it <nckx>My layman's interpretation is that icedtea used to be required to package OpenJDK in an acceptable (libre?) way, so it's the only way you'll find older versions of Java packaged. Then $something changed for the better in OpenJDK and we can now package it as-is. Or something. So try icedtea@3, it might just work. <nckx>(People who actually know this stuff: correct me.) <mjw>yes, IcedTea basically is OpenJDK so it is easier to package *mjw happens to run icedtea.classpath.org but hasn't contributed to the project for a very long time. <nckx>Thanks! Why they didn't just match version numbers is beyond me, but probably had their reasons. <mjw>And yes, IcedTea started as OpenJDK plus GNU Classpath bits and pieces to provide a fully free JDK. It took a couple of years, but over time Sun, then Oracle released more and more sources. <nckx>âEarly pre-releases of OpenJDK7 also used a major version number of 1â ohoh. <lxsameer>mjw: what's the deal with classpath licensing ? I mean i always thought classpath is just a concept, but apparently it's something else as well <mjw>lxsameer, the name came from GNU Classpath, it was the license (GPL + exception) used that OpenJDK adopted. <refpga>Hello, I'm trying to add a theme for sddm and even though I can browse the file system and see the theme files in the specified directory, somehow I get the error "No such file or directory". This happened with one executable file too (even after setting permissions etc.). <mjw>boo, all those links don't work anymore. But that explains where the license came from. As you can expect we were so happy with that. It was amazing. <mwette>I've been away from doing sysadmin for a long time. Does anyone know how I can have guix-daemon start at boot-time on Fedora? Is this a systemd config? <mwette>In the old days, it was via rc.local. <mjw>mwette, yes, through a systemd service, but I have only done it on centos through the install script (which just plops it into the right place) <nckx>mwette: Guix provides a guix-daemon.service file for systemd. <mwette>nckx: thanks -- I will take a look. <nckx>âInstallingâ it is step 5 in (guix)Binary Installation. <nckx>But the install script that mjw mentions is apparently the recommended way to install Guix now and will do that for you. <mjw>mwette, yes, I highly recommend it, it "just works". <civodul>roelj: you can take a look at "guix build -S PKG --log-file" to see if the patch was applied <mwette>did the systemd thing; "guix install hello" fails with "guix install: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused" <nckx>mwette: That means the daemon isn't running. Is the service actually started? <zimoun>civodul: I have tried "wget `guix build -S gmsh --log-file`" and then tar tell me "File format not recognized" and I have xz installed. Hum? What am I doing wrong? <mwette>nckx: status is "Loaded: loaded; Active: failed" so need to chase that down, I guess; FYI I recenlty did "dnf upgrade to fedora 30" <civodul>zimoun: you're not running tar here, right? what does the "guix build ..." command return? <mwette>journalctl _SYSTEMD_UNIT=guix-daemon.service indicates I never got this running; maybe a do-over is in order; thanks for the help *civodul fi^H^H worked around the last test failure on Guile 3 \o/ ***ng0_ is now known as ng0
<zimoun>civodul: then xz: (stdin): File format not recognized <roelj>civodul: What should I see when the patch has been applied? I'd expect a "Applying patch ..." message? <nckx>zimoun: That URL is a gzipped text file log, not a xzipped tar file. <nckx>It's the build log *for* gmsh-2.16.0.tar.xz. <zimoun>nckx: tar -xzvf returns tar: This does not look like a tar archive <nckx>Don't rely on file names, use file đ <nckx> /dev/stdin: gzip compressed data, max compression, from Unix <nckx>zimoun: zless, gunzip < FILE | less, or (my choice) curl -L FILE | gunzip | less. <nckx>Mainly because it didn't occur to me to type zless. <zimoun>nckx: Crap! I thought my less was configured to call zless intead when gzipped. Sorry for the noise. <zimoun>nckx: I was just confused by the name .tar.xz :-) <civodul>roelj: yes, the "Applying patch" message, and perhaps additional output from 'patch' <roelj>civodul: Alright, thanks! :) <roelj>civodul: Is there any message that indicates failure? Like "Cannot find patch ..."? <roelj>civodul: Ideally, the build should fail. <civodul>roelj: yes, it fails it the patch cannot be found (before even starting to build) <nckx>zimoun: Guix ships a very basic lesspipe script: exporting LESSOPEN="|lesspipe %s" will decompress gzipped files (only gzip) no matter what the extension. It doesn't work on stdin though. <nckx>zimoun: Hah, disregard that, it's something I installed locally (ââ˘á´â˘â) <nckx>I should submit it upstream. <zimoun>nckx: thank you for the tip. I thought I have some similar... Probably get it out during my Xmas cleaning. :-) <mwette>so I re-installed guix-1.0.1 on my Fedora 30 system; the daemon is still not starting; note: I have /gnu on a separate file system (from /); error message: systemd[20269]: guix-daemon.service: Failed at step EXEC spawning /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon: Permission denied <nckx>mwette: I associate âFedoraâ with âSELinuxâ. Assuming the file above exists, could that be it? <roptat>Is that a selinux related issue? <nckx>mwette: I don't know anything about SELinux but the manual does. It has an âSELinux supportâ section. <mwette>[root@localhost guix]# getenforce <nckx>Don't you feel all warm & fuzzy & NSA-secured now. <mwette>the SElinux instrructions are not super-clear; I found a guix-daemon.cil file in the store but it looks like scheme code; to me, does not make sense to feed this to semodule <roptat>Actually cil is a s-expression format for selinux <refpga>Hello, does anybody use a custom theme for sddm here? <lxsameer>hey folks, is it ok to download binaries to build a package from source ? or should i build those binaries from source as well ? <bandali>i think the latter is strongly preferred <mwette>roptat: thanks; "semodule -i guix-daemon.cil" done; "restorecon -R /gnu/store" ? -- /gnu is a separate file system from / <roptat>mwette: I'm sorry I don't know much about selinux. <mwette>roptat: hey, thanks anyhow; I thought I would try this at least <mwette>restorecon failed: "Could not set context for ..." (lots of shared objects; hope this is not a barbed rabbit hole <mwette>The above includes "Permission denied" and seems to apply to everything <KE0VVT>Did I hear that Guix has Plasma now? <jonsger>KE0VVT: not yet. But there was some activity on the KDE front recently <KE0VVT>I don't use any KDE apps, but Plasma gives me modern features without making my computer feel like it's lagging. <jonsger>if you are interested in joining the effort, you could maybe reach out on the guix-devel mailing list. Maybe Hartmut has some more details... <KE0VVT>abralek: I've only used it for cosmetic stuff. <abralek>I see. I run it with guix within a gnome session <abralek>Is there any strategy to compile packages that use Gradle? <janneke>abralek: in short: it's a web of cyclic dependencies that has not been broken yet <roptat>Not so cyclic I chink, at least when I looked a a version 4 or 5 <roptat>But clearly difficult to bootstrap because of kotlin <janneke>roptat: hmm, /me just quotes the blog <roptat>I wasn't there, but really if yoi take che same approach as the ant-build-system takes with maven projects (don't use the build system they provide), the cycles almost go away <roptat>The only cycle left is kotlin depending on kotlin <roptat>And potentially scala too, but I'm not sure it's needed anymore, for newer versions of gradle <roptat>Btw thc reason why ant-build-system iqnore maven projects is because maven and all its dependencies are maven projects: it's the same kind of cycle, and we managed to have maven <abralek>I see. I am trying to build openjfx. I am literally using invoke javac or java to generate headers and friends. ***ng0_ is now known as ng0
<roptat>abralek: I understand, but we don't really have a better solution :/ <roptat>I guess after all this time and effort it's time to admit defeat and package a non bootstrappedqversion of kotlin⌠<euandreh>hello:) running make is broken for me in Guix repo master branch. Is it broken for anyone else or did I do something wrong?? <str1ngs>euandreh are you in a guix environment. there are edge cases where that might be required <euandreh>I used a pure guix environment: guix environment --pure guix --ad-hoc help2man git strace -- sh -c "./bootstrap && ./configure --localstatedir=/var && make" <euandreh>str1ngs: fairly recent, a few hours earlier today <euandreh>I'm on commit a3143063aeeecb5c02f75a6e1ddc0cc295e0e4f8 now <str1ngs>euandreh I think some work is currently being done for guile 3. so maybe you hit a non build state. check git logs <ngz>euandreh: try make clean-go and start over <str1ngs>what ngz is a good idea. or git clean -xfd if you don't have files that need staging <euandreh>I already had a clean repo (git clean -fdx) <bzp>I am new to this world of guix, as the .xinitrc file is started, I have some script that I need to start <nckx>bzp: Try .xsession instead. <nckx>.xinitrc requires xinint which requires startx which Guix System doesn't support (well), IIRC. <nckx>.xsession is selected by the âCustom sessionâ of your login manager & must exec your WM at the end. <bzp>nckx: How do I do what you tell me? <nckx>bzp: How you select a session type depends on your login manager. My .xsession starts i3 so it ends with the line âexec dbus-launch --exit-with-session ssh-agent i3â. Before that there are lines to set the background image, exec shepherd &, xmodmap, ⌠That's where you'd put your script. <bzp_>I already have the .xsession file, but when I start my session my section is restarted <ngz>nckg: Ah. Good catch <ngz>Do you want to fix it, or shall I? <nckx>It's trivial for me to do if you want. Up to you. <ngz>Don't worry, I'll do that in a sec. <nckx>Thanks! (as well as for the package.) <ngz>Done. Thank you for the heads up. ***jonsger1 is now known as jonsger
<nckx>A freemium engine for yo' freemium game. <ngz>There is no more Chipmunk Pro. Both have been merged into the same free project. <nckx>ngz: That this graph on the front page makes them look bad IMO (there's a difference between âpay us for feature Xâ and the implied âpay us for better-written codeâ), but if what you say is true it's outdated & moot anyway. <ngz>The merge is recent. It started in release 7 (current is 7.0.3). <ngz>(the info is at the very top of the front page) ***jonsger1 is now known as jonsger
<ngz>Not even in the first slide of their banner? <nckx>There's a sidebar item on the right still recommending Pro. <nckx>ngz: Now I get ya. Yes, it's there, but it scrolled away by the time the page actually loaded. <nckx>I obviously need to buy IceCat Pro. <ngz>Wait for Guix Pro, it will include IceCat Pro <ngz>I heard that Guix Pro will include a modular Texlive ;) <nckx>You're thinking of Guix Forever. <ngz>Who needs forever when you have time-machine? *nckx now wondering if that ref is Too Old & feeling Too Old. <bandali>nckx, thanks again for applying that patch, btw :-) <nckx>bandali: No prob. Considerate of you to not want to burden the patch tracker, but don't ever worry about that. Integers are cheap. ***jonsger1 is now known as jonsger
<civodul>but a "guile3.0-guix" package is going to land very soon :-) <civodul>hmm, i wonder how Debian's doing with Guile 3.0... la la la <sameerynho>my guile fails with seg fault on compiling guile from source, so i was like should i try it with guile 3 ? <vagrantc>civodul: i do believe i wondered that on the list, no? :) <vagrantc>civodul: are you waiting to get guile 3.x sorted out before releasing the next version? *vagrantc was really hoping the next version could at least be attempted to upload to Debian <sameerynho>another seg fault when I'm pulling from official repo "builder for `/gnu/store/25xl94ww9d3sjbsnlmribq988rh8aqql-guix-system.drv' failed due to signal 11 (Segmentation fault)" <drakonis>if guix updates, which version will it be? 1.1.0? <drakonis>the version in which guix gets a lot faster <NieDzejkob>sameerynho: anything in dmesg about the segfaults? <sneek>Welcome back NieDzejkob!, you have 1 message! <sneek>NieDzejkob, drakonis says: can cursedfs be used to create a guix install image and have usb storage visible to windows? <civodul>vagrantc: oh yes, i saw your message on the list! <civodul>regarding the new release, i would have liked to get better testing of the installer <civodul>there's also a couple of embarassing bugs, like md-raid installations not working <civodul>or at least the test's not working :-) <vagrantc>not that it shouldn't be possible ... but do people really use that for rootfs? *civodul is a complete RAID noob, guidance welcome :-) <vagrantc>raid0 is for performance, but at risk of data; if any device fails you likely loose data *vagrantc would suggest testing raid1 as a more "normal" raid level to actually use <vagrantc>which might ... obviate the importance of the bug? <jonsger>civodul: is there anywhere a current installation image. so from master? <drakonis>ah guile 3 guix is available, how do i install that one now? <sameerynho>when i look at the installed packages i see this record for guile "guile: warning: failed to install locale" <vagrantc>but if people actually have typical use-cases for raid0 ... maybe that should be tested too <NieDzejkob>drakonis: as is, not really, because the ext part is limited to 32M, but I'm working on removing this limitation <nckx>drakonis: What purpose would you have in mind for that? The âhybridâ installer's file system is already an unholy stack o' hacks. <drakonis>boot into a guix install image i suppose <nckx>Which confuses some tools and mainly buggy firmwarez. <drakonis>it doesnt seem to work with syslinux it seems <drakonis>the unholy purpose i have in mind is install it on my laptop and still carry other useful data <NieDzejkob>uhh, you do realize that partitions are a thing? <drakonis>i have tried flashing the iso and it didnt work as it should? <vagrantc>huh. is "./pre-inst-env guix ..." expected to work on a foreign distro? <drakonis>i'll try something real quick to see if it works <vagrantc>i seem to need to run it with "guix environment --pure guix -- ./pre-inst-env guix ..." <sameerynho>hey folks, how can i fix this "guile: warning: failed to install locale" <drakonis>or is it guix system but you didn't create a fresh home directory? <drakonis>as it turns out, it is all fine when i copy the contents of skel to my home profile <NieDzejkob>vagrantc: that's odd, it usually links to the dependency <vagrantc>NieDzejkob: i seem to recall that too, but not recently <str1ngs>NieDzejkob and this will probably only work on guix system not foreign distros. <NieDzejkob>str1ngs: on a foreign distro I wouldn't need a workaround in the first place ;) <drakonis>i cant help with this problem, so i'll step aside and stop being unhelpful <oriansj>now the guix manual says guile 2.2.x and so that can't be it <sameerynho>drakonis: well i install everything using guix itself <mroh>sameerynho: this warning "failed to install locale" seems a foreign distro thing, i also have it on a gentoo foreign. but it has nothing to do with a segfault <moesasji>not followed the complete discussion; but the only time I see segfaults with guix is when I run out of space on root <sameerynho>moesasji: i have more than 900G space and 12G memory <drakonis>that one's usually fixed on guix by copying guix's skel to home <oriansj>sameerynho: free space or just space? <sameerynho>oriansj: it seems like a segfault on guile though <moesasji>My recollection for Debian is that it splits into partitions by default, so really 900G including root? <oriansj>sameerynho: ok and are you bootstrapping guix from guile or using the guix binary to do something with guile on your distro? <oriansj>moesasji: default in debian is single partition (less confusing for new people) <sameerynho>oriansj: so my situation is i have netinstalled debian, a bare bone system with guix installed <oriansj>moesasji: possibly was thinking of Redhat (which does that to comply with STIG) <moesasji>as a sideline: guix builds fine for me on a foreign distro 