<vagrantc>the username and hostname are normalized in the guix build environment? <pkill9>tfw you need a newer version of a package and it's already been added and just need to guix pull <rndd>i've installed ntfs-3g and fuse, but cannot mount ntfs partition in read write mode? <roptat>just did some work on scala/sbt this weekend. haven't bootstrapped them, but I managed to update them in my package repo <roptat>I bootstrapped sbt-launcher from scala, which is good, but it's just a wrapper whose purpose is to download the full sbt and run it ^^' <roptat>it's also what you get when you download sbt from their website, so not so bad <roptat>there were some crazy stuff I had to do, like converting some scala code to guile for generating some files, because the scala code depends on sbt, which I don't have yet... <roptat>the other crazy stuff was the sbt-launch package, I had to bundle and shadow its dependencies... <roptat>but in the end, it's usable, I managed to build a package with it (outside of guix), and it failed with another package exactly in the same way the official sbt did <roptat>sorry to bother you, I had to talk about it somewhere :) <rndd>nckx: well, when i try do something in mounted dir, it shows that filesystem is read-only <nckx>rndd: What does ‘mount’ say about it? <nckx>Ideas, since you asked: you're not actually using ntfs-3g but the suckful in-kernel driver; the file system needs checking (which can't be fixed with Free software) or is hibernated (same). <rndd>nckx: so, i cannot use ntfs with guix (if use only libre software?) <nckx>It's not a good or well-supported file system, the drivers are buggy and reverse-engineered. <nckx>But I didn't say that, I just asked about ‘mount’ :) <nckx>rndd: s/Guix/Linux/, Guix isn't relevant here. <dstolfa>nckx: btw, do you have a persistent hurd VM working on guix? i can only get the volatile VM working through the service <nckx>Had one once 's all I can say. <rndd>nckx: i need to use it because of work <dstolfa>fair enough, guess some playing around is in order then <rndd>trying to use guix as daily driver <nckx>Well, Linux support for NTFS is what it is (poor). But I can't help you if you don't share more info. <pkill9>anyone know what this error means when running a java build? Cannot invoke "javax.tools.JavaCompiler.getStandardFileManager(javax.tools.DiagnosticListener, java.util.Locale, java.nio.charset.Charset)" because "this.delegate" is null <pkill9>as in, building a software written in java, not building java itself <char>is wip-gnome branch working on gnome 40? <rndd>nckx: i installed fuse, ntfs-3g and "mount -t ntfs /dev/sdb1 /directory <rndd>and inside this directory i cannot create files <nckx>So you're not using ntfs-3g. <nckx>Your using ntfs, the Linux driver. <nckx>Mount it with ntfs-3g instead. <nckx>The Linux ntfs driver has experimental write support but it's a very bad idea to enable it, so we don't, so file systems mounted with ‘mount -t ntfs’ will never support writing. <rndd>unknown filesystem ntfs-3g <nckx>No, mount it using ntfs-3g. <nckx>I don't know if you need root, but probably, so sudo ntfs-3g. <nckx>ntfs-3g is known to be slow but it shouldn't be any slower on Guix than on Ubuntu. It's the same software. <nckx>To further confuse^Wexcite you: a new in-kernel NTFS driver has been submitted to Linux, completely unrelated to the old one, that should be of much better quality than the crap read-only one you accidentally used. But it hasn't been accepted yet. <rndd>but as i know, there is no way <rndd>except diggin in source code <dragestil>I see, my root partition does not have a lot of space left <rndd>and mentioned it in /etc/fstab <dragestil>right. would it work the same if I hook a usb drive? my only concern with that is for times when the usb is temporarily unmounted things may break <rndd>dragestil: this is bad idea <rndd>usb sticks have little amount <dragestil>or are you talking about the durability of a usb stick <dragestil>atm I'm just trying out / experimenting with guix so that's not a concern for me <rndd>well, try to mention it in fstab <dragestil>does the guix daemon leave the store alone when I don't issue any guix command? <ecbrown>hi all, is there a `guix ...' way of building a pacakge with core-updates compiler versions? (i need gfortran-10) <dragestil>pkill9: cool. i saw it in a reddit submission and the top comments were like "what's the point of 100% reproducible" <ecbrown>apparently they never set seeds for their monte carlo simulations <nckx>pkill9: That is cool but we must point out it's ‘only’ the installer ISO, so a small selection of packages + system services. <nckx>That said, AFAIK Guix still has the… unfortunate situation that one of the irreproducible packages is… Guile. So we can't boast reproducible systems at all, only packages. <nckx>Maybe (probably) more packages but eh. *ecbrown thinks this can be done with inferiors <nckx>Before the above gets quoted out of context: Guix systems are *functionally* reproducible, of course, but the Guile bytecode in .go sections/files can shuffle about mildly, so they're not *bit*-reproducible. <rndd>is there any way to move emacs to guile or guix to elisp <ecbrown>of course the answer is yes to both questions <rndd>they are both lisps, but having one for both would be great <ecbrown>there was effort on the former by bipt a few years ago <ecbrown>it is an infatuation of mine: guile-emacs <ecbrown>on the second, of course it's theoretically possible to port to an inferior lisp <ecbrown>i mean how can one wax on about the benefits of functional and not have infinite recursion? it's embarrasing <ixmpp>If you want an emacs-like environment not using emacs-lisp, look at nyxt maybe <itismyfirstday>there have been efforts to rewrite emacs in guile I think (not sure how far they've gotten) <ecbrown>rndd: if you can slum it with common lisp there is an environment that has an emacs-alike and pjb on #emacs might be able to hook you up <ecbrown>the current build of emacs-guile in guix hangs. i have never had time to debug it <dragestil>I copied /gnu/store to a usb drive, but when I tried to rm -rf /gnu I got "read-only file system" error <drakonis>rnytom: there is but it is a very difficult thing to achieve without breaking the decades of code written with elisp in mind <dragestil>another weird thing is /gnu occupies 1.2G, but when copied over to the usb drive the new folder is > 3G <dragestil>I guess I'll uninstall guix and re-install after mounting the usb drive <ecbrown>dragestil: i think theres some de-dupe and some filesystem differences perhaps <drakonis>fat32 doesnt do symlinks, so the storage balloons <ixmpp>Its the hard links, not symlinks <dragestil>drakonis: huh? both the usb drive and the root are ext4 <ixmpp>The hard links wont be preserved <dragestil>hard links from guix store to the base foreign system? <ecbrown>dragestil: why you messing with /gnu? <nckx>dragestil: Hard links. You can preserve them with rsync. <ecbrown>have you already whacked your store? first `guix gc' and 'guix gc --delete-generations' <ixmpp>dragestil: hard links from /gnu/store/.links to /gnu/store/**/* <ixmpp>They will *all* have been reified <dragestil>ecbrown: not sure if i've whacked the store yet <drakonis>the hard links are maybe the thing that takes up the most space <ecbrown>dragestil: i'd like to see if you can recover, if maybe you just want some disk space back <ecbrown>(try those commands as root and as user) <dragestil>if none of the things got deleted in sudo rm -rf /gnu then the store is intact <nckx>By the way, hard links are just an inherently weird unixthing to handle, so rsync will stare at your file system for a very long time going ‘hm’ before it does anything. <ecbrown>dragestil: yeah, i have reformatted a number of systems because i didn <ecbrown>t understand how to trim down the store <ecbrown>all those reconfigures went somewhere ;-) <ixmpp>(a way of avoiding this entire mess is to just use btrfs, so you can copy at filesystem level instead of at userspace level, which will be orders of magnitude faster and perfectly accurate) <dragestil>looks like there's no instructions for uninstall in the manual <ecbrown>dragestil: yes there is some higgery jiggery going on with /gnu, i don't know what the specifics are. it also makes it a drag to post-hoc put /gnu in its own zfs pool <ecbrown>so i just converted to btrfs and have to learn the syntax to btrfs send over ssh <ixmpp>As a btrfs user, it was instinct to put /nix on it's own subvolume. I just carried over that habit to /gnu <ecbrown>ixmpp: i'm sure it is, but it's another bullet point on a long list <ixmpp>Make a readonly snapshot of the subvolume, then its just `btrfs send /path/to/sub` and pipe that into `btrfs recieve /path/to/newsub` somewhere <ixmpp>/ is a subvolume too, presumably <ecbrown>that's what i haven't figured out, like do i need /subvolume etc etc <dragestil>still can't fix the read only file system error when trying to delete /gnu though <ecbrown>like, i want to put /.subvolume on the / that i want to.... <ixmpp>ecbrown: Did you make subvolumes when you created the btrfs, cause if not you have messed up a bit <ecbrown>ixmpp: i just followed the guix installer <ixmpp>/ should not be the toplevel of btrfs <ixmpp>Do you have a "subvol=??" Arg to your root mount? <nckx>/ is just a subvolume (5) on btrfs. I don't know why it ‘should not be the top level’ though. That sounds like dogma. <ixmpp>nckx: If its the toplevel, you cant make any subvolumes that arent sub-subvolumes of / <ixmpp>It's clipping your own wings <ixmpp>E.g. ecbrown can now not make readonly snapshots of / <ixmpp>So as i said, messed up a bit. <ecbrown>ixmpp: this is why i couldn't just "waltz in and start doing btrfs" <ixmpp>I reccomend you boot into live media, make a subvolume, and `mv` all your root stuff into it <nckx>So, dogma if you want to do a specific thing. Fine to warn against in context, but not wrong. <ecbrown>i had actually thought of that ixmpp, but laziness.... <nckx>Not everyone wants to snapshot /… <nckx>and deal with the drawbacks needed to allow that. <ecbrown>thanks this does sound like what i need to do, or logical partitions of various subdirectories of interest <ixmpp>nckx: in the sense that having a monitor is dogma for computing. Youre defeating the point of btrfs if you dont take advantage of this behaviour, which is why its the default for *every* distribution ive encountered except seemingly guix?? <ixmpp>And believe me ive been on a lot of distros. <nckx>Nonsense, but not worth debating. <ecbrown>it's not nonsense, i'm in this situation right now <nckx>We've all seen a lot of distroes :) <ecbrown>ixmpp just walked me through it like a jedi master <ecbrown>sorry for the outpouring, i made a big gamble to switch a lot of computers from zfs to btrfs and i was totally stuck <nckx>On the bright side, I suddenly intuitively understand why some people don't like systemd. <nckx>Same ‘you don't want to do that, it's not correct, do only this’ mindset. <nckx>For a personal preference. <nckx>…eurgh, I can't go to bed yet, you're stuck with me for MULTIPLE LONG MINUTES more. *nckx twiddles thumbs and watches the ASCII spin. <drakonis>ecbrown: if you have to use btrfs, you also have to use a newer kernel <ecbrown>drakonis: thanks for confirming this. i am currently on latest and greatest and had waffled about going to lts kernel <nckx>CompanionCube: Sweet, we team-battled some poor sod in #idlerpg and won. <drakonis>its a matter of being much safer to do that <ecbrown>drakonis: i'm always reading about improvements to btrfs in the new kernel -- it's encouraging <nckx>drakonis: What's still wonky? <nckx>Well, yeah, early adopter here, but… that was literal ages ago, it's hardly heartening to hear it in 2021. <nckx>Btrfs should be boring now! <drakonis>well i dont know if it is stable enough to run on lts <nckx>Hah, neat, thanks drakonis. <drakonis>the features you dont have arent critical changes <nckx>That is one handy table I will reference in future. <drakonis>zoned storage hardware seems to be the new thing now <nckx>Whatever happened to *whispers* raid5/6? <drakonis>"The parity RAID code has a specific issue with regard to data integrity: see "write hole", below. It should not be used for metadata. For data, it should be safe as long as a scrub is run immediately after any unclean shutdown." <drakonis>looks generally safe to use now, which is very good imo <drakonis>huh, zoned storage looks like an amazing thing to have <dragestil>does anyone know how to delete /gnu/store? It looks like a combination of sticky bit and 444 permission flag prevent me from chmod / chown / rm with root <nckx>drakonis: You sure it's not just bind-mounted still? <drakonis>hmm there shouldnt be any issues with nuking it <ixmpp>It probably still bindmounted /gnu/store ro <nckx>dragestil: Try to unmount it, see what happens. <ixmpp>Or whatever's mounted in that tree <nckx>As ixmpp says: it's a trick. <nckx>To make it super-read-only. <drakonis>so you cannot deliberately delete the directories sitting there *nckx remounts /gnu/store rw more often than anyone here need know. <ixmpp>(i get around it by mounting the store subvol at /run/btrfs so i can fiddle derivations in naughty ways) <nckx>ixmpp: Of course you use a btrfs subvolume for that, of course 😃 <drakonis>a btrfs question, how do i deal with having a ssd and a hdd? <nckx>dragestil: Wasn't that fun? I hope we all had fun. <ixmpp>drakonis: I'd keep them separate <ixmpp>The difference in speeds will get weird <drakonis>i'm not sure if i'm ready to reformat my home yet <ecbrown>that sounds like a fusion drive. an abomination <drakonis>going to go all out with btrfs after my upgrade *ecbrown split fusion drive and now runs guix system on imac's ssd <nckx>drakonis: I'd use bcache{,fs} but btrfs+bcache sounds like one of those things that just totally hoses btrfs. Which is… most things. *nckx knocks on laptop ‘Yep.’ <ixmpp>I attempted to use it while on nixos and lost all my data :D <nckx>There is a native one now it's just el crappo. <nckx>ixmpp: Fuuuun! We're all having fun I'm so hap. <drakonis>this one's a kernel driver written by paragon software <drakonis>the existing one is read only and it sucks <nckx>ntfs3, the old one is ntfs (CONFIG_NTFS) with optional write support. <ixmpp>Bcachefs sounds now like btrfs was when i started using it, basically "use this at your own risk", but at least ive never really properly been burnt by btrfs whereas bcachefs hates me already <nckx>Nah, you can set CONFIG_NTFS_RW if you hate having data. <nckx>I do hope CONFIG_NTFS is removed and -t ntfs is reused. Having to type -t ntfs3 is stupid. <nckx>I use the Paragon driver & patch my kernel to remove the 3 but then I'm also stupid. <nckx>ixmpp: Exact opposite here. Years of using btrfs as a starry-eyed youth, kept getting abused, kept coming back for more like a victim. Conversely, I've created exactly 1 bcachefs, two years ago. I think I'm learning to love again. <ixmpp>Now i want to try it again, but i have no need for new partitions <dragestil>still can't install guix on a usb drive, because I mount the usb drive on /gnu, which the install script thinks is a sign of a previous installation and refuses to continue <nckx>That's not to say file systems don't die on the bcachefs issue tracker. But, well, that's my story, and there's this vague trust-in-upstream thing that's hard to quantify. <nckx>dragestil: You can patch the install script, but nobody here will guarantee that such a system's sure to work. <dragestil>not sure if i can comment out the lines in the install script, because I don't remember the permission flags of /gnu and can't replicate it <nckx>There might be *waves spookily both hands* assumptions. <drakonis>dragestil: are you running nixos right now? <ixmpp>dragestil: 777 and hope for the best <nckx>Wait why isn't your install script not in ~/Downloads or something. <nckx>dragestil: drwxr-xr-x 3 root root 0 Sep 27 2020 /gnu/ <nckx>dragestil: Right, I meant something like that. I must have misread you thinking you meant the script was read-only or such nonsense. Never mind. <nckx>No problem. I have many more. <dragestil>mv: inter-device move failed: '/tmp/guix.ETm/gnu' to '/gnu'; unable to remove target: Device or resource busy <dragestil>looks like it's a simple one though, let me patch the script <nckx>I'm not saying this is bound to work, but *if* I were to try this, I'd mount the medium at /gnu/store, not /gnu. <nckx>There's nothing under /gnu but store/ anyway. No need to sever at that point. <dragestil>i suspect `mv "${tmp_path}/gnu" /` will fail for the same reason if mounting on /gnu/store <dragestil>i changed it to mv "${tmp_path}/gnu/*" /gnu/ <nckx>It bears pointing out that Guix maintains a /var/guix that is assumed to be ‘in sync’ with /gnu (should it not be moved to /gnu? is a very fair question to which the answer is probably yes, but let's not go there now). If it desyncs severely and Guix doesn't notice, bad things might happen. I don't think it's likely, but you should be aware. <nckx>Just don't accidentally plug in a year-old back-up /gnu and start running ‘guix gc’ or so. <nckx>Now I will finally fulfill my promise to you all <ixmpp>> It bears pointing out that Guix maintains a /var/guix that is assumed to be ‘in sync’ with /gnu (should it not be moved to /gnu? is a very fair question to which the answer is probably yes, but let's not go there now). If it desyncs severely and Guix doesn't notice, bad things might happen. I don't think it's likely, but you should be aware. <ixmpp>nckx: It irritates me that it isnt there already! It is in nix, and definitely should be. Thats why i moved it in nixos-guix, and why i symlink it in my system. Bizarre state of affairs <dragestil>just reinstalled guix onto the root partition, and rsynced /gnu to the usb drive. still not clear how /gnu/store is mounted, as `sudo findmnt | grep gnu` returns nothing <dragestil>ok, the bind mount did not happen immediately after installation, weird <ixmpp>Guix-daemon will be the thing that does the mount <arthur0>Hi there .. I recently tried installing GUIX 1.2.0 systems on Oracle VM VirtualBox. It seems to be installing fine until the rebooting process.. Instead of booting the system, it enters the same installation process again. Has anyone encountered the same problem before ? or may I seek advices on this ? <ecbrown>arthur0: sounds like you need to eject the iso <ecbrown>or, change the boot order to go to hard drive first <ecbrown>arthur0: also, while you are at it, may i recommend getting the latest iso ***lukedashjr is now known as luke-jr
***ggoes_ is now known as ggoes
***ashkitte1 is now known as ashkitten-irc
<dragestil>my test result has 18 fails, 2 xfails and 27 skips out of 1904 total <dragestil>I examined test-suite.log, but don't quite understand the failures :p <dragestil>maybe 18 is a small enough number to proceed ***platinum.libera.chat sets mode: +o ChanServ
<dragestil>ugh, but then `make authenticate` complains about not finding guix <vagrantc>"guix environment guix --ad-hoc guix" can help with that <vagrantc>dragestil: the test suite itself is a list of possible cases of failures ... and having read it more than a few times, the test-suite.log is a bit hard to read <bdju>did anyone ever figure out why qutebrowser has no audio? <vagrantc>teh xfails are things expected to fail, so those are arguably ignorable <dragestil>vagrantc: do you mean the test-suite code is more readable than the log? <vagrantc>dragestil: there is no list other than the test-suite itself, or the logs it producses <vagrantc>dragestil: skipped tests are typically because you don't have some optional thing installed in order to run that test, or some feature is otherwise unavailable to run the test ... <vagrantc>dragestil: the 18 failures ... shouldn't happen :/ <vagrantc>dragestil: which is not to say they don't happen often ... but they're things that should get checked and fixed <vagrantc>dragestil: i tended to do something like... grep -E '^result:|^test' test-suite.log | grep -B 1 'result: FAIL' to at least get the names of the failed tests <vagrantc>dragestil: although i'm not sure on the ^test part ... but there's a line that lists the test itself <vagrantc>i also often build with the output going to a log file, and then can at least: grep ^FAIL <dragestil>right, thanks. The first failure is in test-name: inferior-packages <dragestil>I'll just need to get used to read test results in lisp <vagrantc>i think the test suites assume a UTF-8 locale <dragestil>could be. and most of the remaining failures are about broken pipes ***niko is now known as o
<bdju>could someone update the bemenu package? it's pretty out-of-date now. <ngz>bdju: It doesn't look so hard. Would you like to give it a try? <ngz>bdju: Great. Let me know if you need help. BTW, I don't think the new name of the tarball version has any impact on the package definition since we're getting code from the repository directly. <bdju>ah, good point. I wasn't thinking about it that much <ngz>So, IMO, we just need to bump version and hash. <bdju>I'm not yet familiar with the standard process. I actually run a newer version of bemenu on my machine installed with the --with-commit= thing, but I'm not sure how one would typically modify an existing package and then test it, or how to submit it <bdju>yeah that sounds probably true <ngz>There's at least a crude way and a more elegant way. <bdju>is the crude way something like copying some lines to a new file to install from? <ngz>Exactly. I still have GUIX_PACKAGE_PATH pointing to some incubator.scm file, where I just copy the definition I want to hack on (e.g., update it). <ngz>What is better, however is to use ./pre-inst-env script, as explained in (info "(guix) Running Guix Before It Is Installed") <vagrantc>the better part being that it will then be more easy to actually merge it later <ngz>For the record, I have this silly script <https://paste.debian.net/1201872/> named "guixdev", so I modify Guix source tree, then call, e.g., "guixdev build bemenu" and see what happens. <vagrantc>in some cases i've even been using: guix time-machine --url=/my/repo --commit=... -- build <ngz>vagrantc: what were those cases? <vagrantc>cases where my local git with ./pre-inst-env was out of date enough that it was faster to start fresh ... maybe combined with occasional bugs in the ./bootstrap && ./configure ... && make .... process <vagrantc>but somehow guix pull worked fine, but i didn't want to "pollute" my actual guix pull generations with stuff that might not land <vagrantc>i've also experimented with guix pull --profile=path/to/guix-pull && ./path/to/guix-pull/bin/guix ... <vagrantc>many ways to get sort of the same thing :) <ngz>True. It may be worth to have some entries about it in the cookbook. <vagrantc>it also may be worth getting some sleep. :) <ngz>bdju: There is some interesting information at (info "(guix-cookbook) Direct checkout hacking") <bdju>I'm not quite sure what to do with your info suggestions. like how to format it to actually open <bdju>the parens make me think emacs maybe. I tried variations of what you said with the info command in a shell and can't figure it out <gnoo>if you paste that on scratch buffer, go to end ')' and type C-x C-e, it should bring you the manual <ngz>Yes, I paste an Emacs command. In a shell, it would be info "(guix-cookbook) Direct checkout hacking" <ngz>There are online versions, too. <ngz>I just assume everyone uses Emacs ;) <bdju>yeah I usually read the manual in a browser. I do have emacs installed but I only use it to manage a few files and I get picky about the buffer order and such. also never gotten comfortable with info in general <ngz>Ah. I find browsing info documentation from Emacs much more pleasant (and faster) than using a web browser on the HTML counterpart. It's a matter of taste. <bdju>I'm not the biggest fan of web browsers, it's probably just a difference in experience. I still reach for (neo)vim for most of my editing. Largely because emacs buffers don't keep their order based on how you set them / when they're opened, but based on last-visited, which makes the prev/next buffer functions a lot less useful to me if I don't visit everything in a careful order. I wish it was more like an IRC <gnoo>there's probably an easy way to convert info files into markdown. <gnoo>you can try that instead of a browser <ngz>In my experience, order of buffers is irrelevant in Emacs. And so are prev/next buffer functions. I just open the buffer list, type some characters, and let completion (not the default one, mind you) mechanism do its stuff to open the appropriate buffer. <bdju>part of the problem is that my ivy buffer switcher is extremely laggy (several full seconds of hanging when I use it, possibly related to some TRAMP stuff), but also even in irssi when I jump to a specific channel, going backwards takes into account the channel # rather than where I last was. I just really think that's the best way to organize things. then nothing is moving around unexpectedly <bdju>so after a new emacs start I split my windows, start my tramp connection(s) and then proceed to slowly visit like 6 or 7 of my common files in a specific order, then I try to just prev/next between them because it doesn't lag <bdju>I had a better experience using spacemacs a couple years ago, but I wanted my own config so I could use emacs packages from guix instead of elpa/melpa or whatever. <ngz>So, prev/next is more like a workaround for you lag in buffer switching? <ngz>I don't use Ivy; I haven't experienced lag with TRAMP buffers either. This may not be related, of course. <bdju>in part, yes, but even without that lag, the order is not one I'm a fan of at all. if I know two buffers I wanna switch between are next to each other, I should be able to mix in the prev/next to save keystrokes, but it becomes useless if I've been jumping around via the list <bdju>from testing I recall it being specifically the displaying of the tramp buffers in the buffer list. if I have enough things open and have visited enough non-TRAMP buffers to bump the TRAMP buffers out of the initial view, I think it works at a more normal speed <bdju>and I've ran the profiler and detected high CPU usage with it before, but wasn't sure what to do with the info <bdju>I think I'll read up on the guix stuff later, if anyone else wants to update bemenu, go ahead. Otherwise maybe I'll get to it another time. <dragestil>nckx: nice. a bit weird that the mount only happens for systemd and not other init systems <nckx>dragestil: Guix works (and for a long time on systemd systems: worked) fine without it. I added that .mount unit only to bring a modicum of protection on par with Guix Systems. <nckx>WDYM by missing Shepherd? <dragestil>it is a switch case on init, and shepherd is the guix init system (that's the only fact I know about shepherd btw) but is not a case there <nckx>dragestil: If you mean there's no case statement, well, who else uses Shepherd? <nckx>I'm not ever sure what a non-Guix Shepherd configuration would look like. <nckx>dragestil: You're welcome to add cases for other init systems than systemd, it's just work 😉 <nckx>Which init system do you use, dragestil? <dragestil>will learn more about init system from (G)LFS <nckx>Did the script not install the mount unit, or did you not use the script after all, or did something else mishap? *nckx will read replies later, AFK o/ <dragestil>I don't know what happened, it just didn't get mounted, which saved me one step in installing the whole thing on a usb drive <dragestil>maybe I should've kept a log of the stdout / stderr <dragestil>but reading the code it seems to me the install script only enabled the mounting service, rather than starting it ***Exagone313 is now known as Exa
<tissevert>I plan to package a processing line for work, but I need it quick'n'dirty rather than very clean, since I'm in a hurry and it's going to be hard to publish (closed-source stuff) <tissevert>I don't really know how to declare an origin outside from a package definition, is that even possible ? (I'd still like guix to be able to cache all I can for when I get to write a proper package, even if it doesn't get published) <roptat>you can even use an origin as an input (that's how the source is used btw) <roptat>you can see how bbb-render is defined as an origin, and later used in a gexp <efraim>i'm getting glib-networking test failure on core-updates <TheAsdfMan>Hello, I just found out about xorg-server-service-type and I don't think it's documented in the manual <TheAsdfMan>I think it would help people trying to not use a display manager <tissevert>roptat: thank you so much !! I thought I had seen that somewhere ^^ that was there <tissevert>ahhh, so one must use `define` and not `let`… <tissevert>this looks exactly like what I needed to read <tissevert>hmmm I'm at the «root» of my .scm file, maybe that's why it didn't work ? <tissevert>or maybe I need a body on which to «apply» the let ? <roptat>depends how you use that file, you can't define anything inside the let, so the only reason to use a let at the top level is that you use it with guix build -f, at the let is the last instruction <tissevert>well I don't know why it failed ^^ I'm just clumsy <roptat>the let will return a value, and that's only useful if you use guix build -f <roptat>I mean you might be able to define something in the let, but it won't be visible outside of it, so unless you make it return something, it's useless <roptat>anyway, defines at the top level will work too :) <tissevert>I can't just define a source and have guix store that ? <roptat>if you use the file with guix build -f, you can return any file-like object, be it a package, and origin or a computed-file <roptat>you can define the source, but if you don't instruct guix to build it, or one of its dependents, it won't be put in the store <roptat>you can't build anything other than a package if you use guix build/guix install (except with -f), because the UI is looking for a package specifically <tissevert>and, once again, I failed at predicting the hash : ( <roptat>when you give a name like "guix build foo", guix is looking for a package object whose name field is "foo" <roptat>with "guix build -f foo.scm", it will build whatever is the return value of the file <roptat>yeah, it's not easy, I always define a dummy hash, let guix fail and copy the one it reports ^^' <tissevert>I know I should do that, but each time I try <tissevert>it's because it's a git clone and there's .git and there's a special option to tell guix hash to ignore it that Ludovic told me last time I wailed it was failing <roptat>that's --recursive and --exclude-vcs <tissevert>it works, I got the source code in /gnu/store, neato <tissevert>now to see whether I manage to get an environment with what I need ***jackhill_ is now known as jackhill
<ytc>did i do something wrong? <apapsch>ytc: there should be no need for sudo <ytc>i haven't used sudo at the first time but it gave me permission error. <ytc>because of that i scared. <dstolfa>sneek: later tell nckx: is there anything else i can do to get the strongswan service pushed? i'd like to start getting swanctl working, but want to make sure i'm not working off a baseline that needs changing for whatever reason <apapsch>ytc: :-) what was the message exactly? <ytc>Warning: Permission denied <ytc>Error: Permission denied <ytc>error: Failed to install org.freedesktop.Platform: Permission denied <apapsch>that sounds bad indeed. maybe a dbus error. is it running in your desktop session? <ytc>is it possible for me to roll-back? <apapsch>ytc: yes, guix always lets you roll back regardless of the application (however, the state the application left is another story) <ytc>it created a /var/lib/flatpak directory. <ytc>how can i know that if there are other files? <apapsch>state is unmanaged afaik. unless you are running a special service that monitors the files you can't know <ytc>i know fixing everything with unix way. so guix is a very exotic operating system for me. i am worried about breaking some things because of the lack of guix knowledge. <roptat>ytc, as long as you don't touch /gnu/store or /var/guix, you should be fine <ytc>some programs may want to create /etc files. is it ok? <roptat>if you run them as root, that might happen, and it can be a bit concerning. Services are passed configuration files directly from the store <roptat>compared to other systems, /etc is almost empty <roptat>the main issue with programs creating files in /etc, /var, etc, is that the files are not managed by guix, so you can get stalled states in them <roptat>however, I don't think it's a problem to remove them: if they were managed by guix, a reboot will recreate them, otherwise, they'll get recreated fresh by the program <ytc>i understand. where can i learn the structure of the guix system? the manual explains how-tos but not the details. <roptat>that should give you an idea of how the system is structured <roptat>I have to admit that a lot of what I know comes from reading the source code <roptat>but the manual is still useful most of the time :) <apapsch>it has still got room to grow as the scroll bar does not appear to be stuck like with guile manual ;-) <jackhill>What does this error mean? "guix build: error: renaming ‘/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16’ to ‘/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16-check’: No such file or directory" <sneek>Welcome back jackhill, you have 2 messages! <sneek>jackhill, maximed says: It targets core-updates (so G-exps can be used everywhere and the patch doesn't have to deal with 'canonicalize-reference') though <jackhill>I got it after running `guix build --rounds=4 -K --no-substitutes fldigi` <jackhill>sneek: later tell maximed re: meson cross-compilation: thanks for the pointer <cdegroot>Is it me or is lttng-ust broken? I thought it strange that it was building locally instead of downloading a substitute, but the build ended in ```configure: error: Cannot find liburcu-bp lib. Use LDFLAGS=-Ldir to specify its location. <cdegroot>command "/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" "./configure" "CONFIG_SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" "SHELL=/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash" "--prefix=/gnu/store/9skd3cws0n6z9699qz5c8my3af6ixxdf-lttng-ust-2.11.0" "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" failed with status 1 <roptat>I tried building locally, the previous line says "checking for synchronize_rcu_bp in -lurcu-bp... no" <roptat>configure does find liburcu, so its hint is useless <roptat>it's possible there is a version mismatch though <cdegroot>liburcu did get an upgrade recently-ish. I was just wondering whether it was just me before filing a bug report. <roptat>guix build lttng-uts --with-latest=lttng-uts seems to work (it passes the configure phase at least) <roptat>so it's just a matter of updating it <roptat>it builds the package using the latest source available upstream, instead of whatever guix defines <roptat>in that case, guix knows only of 2.11.0, but --with-latest is able to build version 2.12.2 (with the same recipe) <cdegroot>Well, at least it's just not me (shouldn't happen but never hurts to check). I'll try to throw together a patch when I have some time later today if nobody else beats me to it. Now, it's time to head to the office and do some work ;-) <dstolfa>i can't get them to pass locally on two of my machines <dstolfa>neither make check nor make check-system <dstolfa>make check-system breaks on docker, make check breaks on cpan/ctan/etc <tissevert>do phases depend upon a particular build system ? <tissevert>could trying to set a #:phases in a copy-build-system yield a warning «invalid field specifier» ? <civodul>tissevert: phases are build-system-dependent <civodul>for copy-build-system, it looks like you can pass #:phases <civodul>"invalid field specifier" probably means there's an incorrect field name in your (package ...) form <civodul>(say, "iNPuTS" instead of "inputs" :-)) <tissevert>what's the easiest way to troubleshoot such situations ? <tissevert>is there a «catch-all» value that can be plugged anywhere, like `undefined` in haskell, that allows to check everything outside a given construct ? <tissevert>(i.e., magically filling-in as long as it doesn't need to be evaluated, and then failing cleanly showing it got to that point when evaluation is eventually attempted on it) <apapsch>dstolfa: cpan test passes on a machine of mine <tissevert>ok, well I was lucky this time it was outside the #:phases keyword <dstolfa>alright thanks, i guess it's some user error on my end. <jackhill>What should I do about "path `/gnu/store/jlk67v3nddhv0z963wfvahk8fc8gqcz8-gnutls-3.6.16' disappeared, but it still has valid referrers!" reported from `guix gc --verify`? <rekado>jackhill: perhaps you can do “guix build /gnu/store/zkhymfsbrv0s4y7l778g78k6y65nidxd-gnutls-3.6.16.drv” <ixmpp>tissevert: aiui there arent many scheme nerds in here. Try #guile <bavier[m]>hrm, another qt application whose icons aren't visible for me: kiwix-desktop <tissevert>ixmpp: really ? I'm a total noob, you know, people around here sound very skilled to me, I doubt my (un)understanding of guile is enough that I can ask any question that people here can't answer (but thanks for the tip ! I'll keep it in mind for when I understand guile enough to have a «real question» ^^) <ixmpp>Just going by my experience. Every scheme-y question ive asked is met with blank faces :p <ixmpp>apparently theres more scheme nerds on the mailing list, but snail email isnt my thing <roptat>it depends the type of question you have <dstolfa>tissevert: missed your question... you can use #f <roptat>if it's very precise about guile, then #guile is probably a better place, but if it's about guix or general questions, here is fine <tissevert>it's about realizing I can't even copy-paste properly what I read in the guix manual and then trying to cope with strategies like «ok, please guile assume this part magically works and tell me if the rest makes at least any sense» ^^ <tissevert>dstolfa: #f can do that ? that's wonderful ! thank you !! <roptat>#f or "" can be a placeholder for most required fields <tissevert>(also, this is my trying to pretend every language I don't know must be just like haskell ^^*) <ixmpp>it actually is reasonably similar, being a lisp <ixmpp>just, there's so much stuff bizarrely missing or not catered for <ixmpp>but everything is just as possible <ixmpp>except maybe type inference :p <roptat>it's not telling guile "there will be something later", it's just filling it with some dummy value that might have some effect on how the package is handled, so be careful <ixmpp>parametric polymorphism in a lisp would be amusing <dstolfa>it's not that bizarre when you consider that guile was meant to be an extension language <dstolfa>tissevert: there are nice things and bad things about types. right tool for the job and all that <ixmpp>i mean yeah i've made my peace with it. it's still an order of magnitude step up from nix-lang <tissevert>roptat: yeah I was going for «syntaxically valid and will cause the interpreter to wail when it starts evaluating» <ixmpp>maybe (eval "!") or something <ixmpp>that's a syntax error packed in a thunk :p <tissevert>every time I try and write something on nix it's a nightmare and the documentation makes it impossible to find the answer to the slightest question one may have with a basic understanding of declarative languages, yeah I know about fixed-point, thank you I just wanna know what you call your assocs <ixmpp>what is the policy on emacs packages? <ixmpp>i may resort to nix for emacs for now <roptat>there's the importer that makes it easier <ixmpp>that's true, but good god, have you seen my emacs config? i think at last count i was using 149 packages <ixmpp>if even half of those aren't present, i'm not about to import them all <dstolfa>an emacs user that doesn't have a self-bootstrapping emacs config? <ixmpp>dstolfa; i was one of the only 3 or so people with my emacs config fully integrated into nix <ixmpp>and it helped with the nature of "have everything config'd in one place" <ixmpp>but to be fair, emacs lisp can be embedded directly in scheme <ixmpp>so that's less of an issue here <ixmpp>i just ...need to migrate ALL of that, AND add missing packages <dstolfa>my emacs config basically just installs and updates packages if needed every time it's run and always runs as a daemon, and i only pull from elpa <dstolfa>so it's a non-issue with melpa things missing <dstolfa>it's just an org file with my own config <jackhill>/gnu and /var/guix are on the same btrfs filesystem, and btrfs scrub didn't find any problems <lispmacs[work]>hi, I want guix-daemon to be started with the --gc-keep-outputs=yes option. Can somebody tell me how to add that to my system configuration, or tell me what section of the manual covers it? <jackhill>raghavgururajan: Your latest changes look good to me. Thanks for the reminder, I'll add a comment in the ticket. <jackhill>raghavgururajan: I'm excited to see the crystal work! <ixmpp>anyone got an emacs config as complicated as mine set up through guix that i could leaf through? <dongcarl>Hey is there a site where I can search through all Guix mailing lists? <ecbrown`>ixmpp: my init.el is becoming *less* complicated with guix. no use-package etc. <ecbrown`>its currently a disaster though and full of secrets or i would share <ixmpp>see, i still used use-package <ixmpp>cause it was nice having the load hooks <ixmpp>but yeah i'm interested to see what a guix config might look like at the extreme <ixmpp>what i desperately want to avoid is having packages in multiple places <ixmpp>either all in guix, or all in nix, or all managed by emacs <apteryx>ixmpp: I did that experiment a couple years back (adding all Emacs packages I needed to Guix). Been happy ever since. I highly recommend it; and your efforts will make the next person migration easier. <ixmpp>apteryx; there's no automation, though, right? <ixmpp>so each package has to be updated individually, manually <ixmpp>no of course, but there's no automated repo of emacs packages imported from melpa regularly, is what i mean <ixmpp>oh good god that's excellent <apteryx>guix refresh -u to directly manipulate the package definitions in your source tree <apteryx>(i.e. update their hash and version string when an update was found) ***betelgeuse7 is now known as betelgeuse
<sneek>Welcome back nckx, you have 1 message! <sneek>nckx, dstolfa says: is there anything else i can do to get the strongswan service pushed? i'd like to start getting swanctl working, but want to make sure i'm not working off a baseline that needs changing for whatever reason <nckx>dstolfa: I was hoping someone else would chime in. They didn't. I'll queue it. <sneek>I think I remember dannym in #guix 3 months ago, saying: pjotrp[m]1: Hmm... are you still using the non-root guix? I tried proot right now and I get a cryptic error message. <nckx>If anyone runs into non-deterministic Dovecot test failures let me know. <ixmpp>apteryx; ecbrown`; alright had a go, 81 missing out of 189 <ixmpp>but they are almost all the less important ones <ixmpp>the only one that shocked me was emacs-weechat <ixmpp>oh and i guess some don't build... i forgot that was a possibility too <pogchamp>Howdy fellow guixers. I'm trying to make a docker container. I'm running `guix system docker-image my-simple-config.scm' but this outputs nothing. Am I running the command wrong? <ixmpp>curiously, having installed all of those has actually made it such that i can run my old init.el now, because it is *slightly* self-bootstrapping <roptat>pogchamp, it seems to be the correct command <roptat>pogchamp, is it doing nothing, and is it terminating fast and giving no result? <roptat>or is it blocked without outputing anything? <pogchamp>Is there a way I can see the return code? I don't know if it's succeeding or not <roptat>although it's gonna be hard to know why if it doesn't say anything ^^' <ixmpp>so native comp in emacs is a bit of a mess <ixmpp>even with flat's repo, it's not working right for me <ixmpp>but native comp has been merged <ixmpp>so emacs-next should soon contain it <ixmpp>but i can't find any patches regarding that, does nobody use nativecomp here? <pogchamp>roptat: All good. I later realized it was not what I needed, but I'll try it on another machine and see if the problem is from the vm or guix <dstolfa>no, but looking forward to it when it gets into mainline <dstolfa>not no as in nobody does, i'm sure some do :) <ixmpp>guess i'll go pilfer the emacs package... <pogchamp>Weird question: Is Guix only supported on GNU/Linux or does it also support Linux like Alpine? <dstolfa>i'd imagine that as long as you have guile, autoconf, etc you'd probably be able to get it working <nckx>But if glibc runs fine on the Alpine Linux kernel, it should work. <nckx>dstolfa: That I do not know. <nckx>You can configure Linux in ways that break Guix and it's probably more likely you'll do so if you don't care about GNU, but in practice most distros don't. <roptat>pogchamp, it will work on any Linux, but you might have to do a bit of work so the glibc can work (setting a few files in /etc should be all you need). I managed to run guix on android ;) <roptat>dstolfa, the libc of the system doesn't matter, guix is entirely independent from it, what matters is the kernel <dstolfa>rekado: i'm getting conflicting information here... which one is it :D <nckx>I don't see the conflict. <roptat>I mean, if you use the binary install, guix comes with its libc, so the system's libc doesn't matter <nckx>If the kernel supports glibc, it supports Guix. <dstolfa>that makes more sense, i'd assumed it just linked against the system's libc <dstolfa>(which admittedly is a poor assumption in retrospect) <roptat>that wouldn't fit the model very well :) <dstolfa>i'll just blame the non-existent side effects of my vaccination dose today for my silliness <nckx>Admittedly, using the kernel breaks the model in a similar way but is rather hard to avoid 😛 <dstolfa>nckx: there's still time to have some side effects, but so far so good! :D <nckx>I've had both the illness itself and the vaccine side-effects. You definitely want the side-effects. <jackhill>Welcome to jackhill's ghost ranch. Tours: 5¢ <jackhill>It's a good deal, but you might end up bringing some home with you. They're very clingly :) <ixmpp>is it cause all the packages i've installed are being built with 27.2 <nckx>jackhill: Have you tried with --no-substitutes, or does that just explode harder? <ixmpp>that might be the root of all my suffering <jackhill>nckx: yes, I've also tried --substitute-urls=http://ci.guix.gnu.org so it wouldn't have to do TLS to substitute. Appears to work but the directory is still absent from /gnu/store *nckx .oO Hm Guix really wants a cwd and crashes without one. <nckx>I figured as much jackhill but it was worth a shot. <nckx>The only time my store & DB got out of sync the system ended up eating itself completely & I had to reinstall. No bright ideas from me… <jackhill>at least Guix makes that somewhat easier <jackhill>I'm currently trying to resist the urge to make it worse by mucking about in the database. I should go take a walk or something and wait for some better advice <nckx>bdju: ‘too large for paste site, ~3.9MB’ <nckx>…the list limit is 4000KiB 😛 <nckx>It's a soft limit, though, so I've let it through, but next time please compress huge text logs if you don't want to risk trimming important information. They compress very well. <nckx>Don't use paste sites in e-mails at all. <jackhill>ok, so I did do some poking around in the database (only selects!) so maybe it's a file system problem? <jackhill>er, when I was poking around, I couldn't find mention of that path, but maybe I missed something, because gc definitely thinks it needs to find it <jackhill>What makes me most suspect the firesystem is that guix doesn't re-create the path <ixmpp>how do i deep replace inputs to a package <civodul>ixmpp: you can use --with-input at the command line <ixmpp>civodul; isn't package-input-rewriting going to replace it using grafts though? not at build time <ixmpp>i could use package-mapping, if so <dstolfa>i can't believe it took me this long to realize what your name meant civodul... <dstolfa>not once did it occur to me to read it backwards <ixmpp>TIL (begin) and (let ()) are actually different <civodul>ixmpp: package-input-rewriting is similar to --with-input; package-mapping is lower-level, and probably not what you want <ixmpp>am i right in thinking package-input-rewriting results in grafts after-the-fact? <ixmpp>if not, yeah you're probably right <civodul>no no, package-input-rewriting doesn't rely on grafts <ixmpp>Boy, yeah guess package-mapping was a poor plan, it's melting my pc <sss1>it seems pybitmessage finally resumed development and switched to python3, i would like to have this package on guix again <asdf-uiop>How can I mount partitions in a way that my user can write to them? I assume this must be somewhere in the documentation, but I was not able to find it. <dstolfa>ixmpp: laptop or pc? pc isn't too bad, but having a laptop boil you alive is not fun :D <ixmpp>i'm at a loss, tbh, everything i try for this isn't working well, but i can't believe i'm the only person with this issue <ixmpp>but i guess everyone else just doesn't use guix to package emacs modules