IRC channel logs


back to list of logs

<bandali>fyi: Savannah DDoS Attack
<lfam>I'm getting some compiler errors in the daemon code
<lfam>Hm, may have been some strange files in my repo
<PotentialUser-21>Hi, how usable is Guix on ARM based system?
<lfam>PotentialUser-21: What kind of ARM system?
<PotentialUser-21>specifically Rockchip
<nckx>rekado: Are you still working on the git mirror?
<PotentialUser-21>I haven't tried anything yet, I'm still learning Guix hosted on my main OS
<PotentialUser-21>on ubuntu
<nckx>PotentialUser-21: We run some aarch64 build machines on Guix System, and they work fine. They are headless servers, though.
<PotentialUser-21>Ok, so I wouldn't be able to use a desktop environment
<nckx>Not saying that, just that I haven't ever personally tried it.
<PotentialUser-21>what advice would you give me, I will try to do this
<PotentialUser-21>thanks for the help everyone
<civodul>bandali: bah :-/
<civodul>from a Guix perspective we should have mirrors
<civodul>and for that we need proper checkout authentication
<bandali>yeah clement asked about a mirror in the debbugs issue
<bandali>would one of y'all like to reply to him?
<snape>clement is snape
<civodul>hey you! :-)
<nckx>bandali: Ricardo has.
<bandali>oh! lol
*bandali waves at snape
<bandali>nice nick :p
<snape>it's because hackers are wizards
*bandali approves
<nckx>Spooky wizards no less.
<bandali>nckx, coolio
*civodul -> zZz
<snape>bandali, I already got two replies
<snape>one from rekado and one from nckx
<civodul>tomorrow: reproducible build summit \o/
<bandali>snape, awesome :)
<snape>indeed ;)
<nckx>I wanted to start a simple git fetch loop to keep it updated during the night, but that might fuck up rekado's plans… :-/
<bandali>oh, and thanks for your kind words in your reply, snape :)
<snape>nckx: I wan't sure whether you were talking about the same repo as rekado, now I know you weren't ;)
<nckx>I am?
<snape>or I just didn't understand a thing
<snape>it's too late
<nckx>snape: It's currently just a snapshot of what savannah served whenever rekado ran ‘git clone --bare’ manually.
<snape>bandali: you're welcome!
<snape>nckx: wait, what is "Coming soon ;-)" exactly?
<nckx>Well, I was gonna ask rekado about his plans & take over for the night but I guess I missed their bed time.
<nckx>I didn't realise it was this late.
<snape>indeed it's late.
*snape is going to bed too
<nckx>Yeah :-/
<nckx>snape: Good night.
<snape>you too
<vertigo_38>Hi Guix! Does anyone know, how I can switch between java versions? I have openjdk12 systemwide through config.scm and just did 'guix install openjdk@11.28' to get the 11 version. Things looked good during installation, but how do I 'activate' it?
<atw>vertigo_38: what does java -version say now that you've done guix install openjdk@11.28 ?
<vertigo_38>atw: still #12, but I think I just found it out, let me check
<vertigo_38>atw: yess. I didn't get at first, that my 'unprivileged user's' packages are accessible through ~.guix-profile/bin/XYZ'. Awesome!
<vertigo_38>atw: funny though, that if I install a through emacs-guix, I get the hint regarding my GUIX_PROFILE, and if I run 'guix install XYZ' straight on bash, I not necessarily do...
<ScaredySquirrel>once you have a fully working services section and a fully working packages section in your operating-system under config.scm how do you modify it to work?
<ScaredySquirrel>under uhh a guix package -m setup for your normal user "user01" in your home directory /home/user01?
<ScaredySquirrel>I want all those services and packages under my /home
***Server sets mode: +cnt
<str1ngs>ScaredySquirrel: manifest does not handle services. actually guix package won't do anything with service. only guix system does
<ScaredySquirrel>ok well I removed the services section then I ran guix package -m on the new packages config file for my user and it said um
<montokapro>How does one override arguments in build-systems like `default-ruby` in `ruby-build-system`? I'm having trouble doing so without mutating the guix repository itself, since `default-ruby` inspects the gnu module instead of my personal module.
***ScaredySquirrel is now known as ScaredyFerret
<montokapro>Also - for those are interested in a newb's perspective on guix, I am compiling my experiences at
<xelxebar>So, I am futzing around with gnu/system/mapped-devices.scm to try and implement support for detached LUKS headers.
<xelxebar>However, I'm still just beginning to grok all the pieces involved and just want to bounce my ideas off you guys to check my understanding.
<xelxebar>At the moment, I am just running guix on a foreign distribution. Implementing detached luks headers is so I can do a full native install
<xelxebar>So, on this foreign distro, I have a copy of the guix git repo and am editing gnu/system/mapped-devices.scm
<xelxebar>To test out my hacks, do I just need to do a build and then ./pre-inst-env guix system disk-image ... to get an image reflecting my changes?
<xelxebar>At least, that seems like the dumbest thing to do: hack, build guix, build disk image, test on other machine...
<xelxebar>However, I am sure there's a better way. Ideally, I'd like to rapidly prototype ideas in gnu/system/mapped-devices.scm and locally test against some dummy operating-system declaration.
<xelxebar>Any pointers?
<xelxebar>Am I just hopelessly confused?
<bdju>I'm here but unable to help you. Not sure if hearing this will make you feel better or worse.
<lfam>sneek: later tell montokapro: I think you can set #:ruby to a package variable name in your package's arguments field. Similar to how #:python can be set, and of which there are lots of examples
<sneek>Will do.
<pat_h>Hi all, does anyone know where I can find documentation for the 'search-patches' function for package definitions? I can't seem to find any.
<pat_h>Actually in lieu of that, is it possible to provide a path to a local patch file to the 'patches' field for the package source?
<xelxebar>bdju: Hehe, thanks.
***_xvilka_ is now known as xvilka
<Blackbeard[m]>Hi :D
<zig>hello #guix
<PurpleSym>Has the npm importer ever made it into master? I’m trying to package jupyterlab, which depends on node to build its assets.
<leoprikler>PurpleSym: Not yet AFAIK, but give it some time.
<nixo_>Hello guix! What's happening? Does "under attack" really means they are running a DoS on us?
<pkill9>PurpleSym: there is not an npm importer in guix, where is the one you are using?
<pkill9>who is running a DoS on the savannah servers?
<zig>me :o)
***kensington_ is now known as kensington
<PurpleSym>leoprikler: Ah, ok. Last mail on the mailinglist I found was from end of 2018. Is it possible to add NPM packages manually right now? Does node-build-system work?
<PurpleSym>pkill9: There’s an experimental importer and a couple of patches on the mailinglist. But I have not tried it yet.
***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | ⚠️ Savannah (guix pull) servers under attack: try and try again… | 1.0.1 is out! get it at | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel is logged: http://logs.guix.gnu.or'
***nckx changes topic to 'GNU Guix | ⚠️ Savannah (guix pull) servers under attack: try and try again… | 1.0.1 is out! get it at | videos: | bugs & patches: | paste: | Guix in high-performance computing: | This channel's logged:'
***ChanServ sets mode: -o nckx
***inoaffep is now known as pinoaffe
<pkill9>has anyone configured guix so that it doesn't require the $HOME/.guix-profile symlink? I assume the thing required to do this is to change /etc/profile to use /var/guix/profile/per-user/... instead of $HOME/.guix-profile
<pkill9>hmm actually all references to the guix profile in packages seem to use ~/.guix-profile
<leoprikler>pkill9: where would you like to move ~/.guix-profile?
<pkill9>leoprikler: i want to remove it altogether, it's just a symlink to /var/guix/profiles/per-user/$USER/guix-profile
<dutchie> seems to be having trouble, is it related to the dos attack?
<pkill9>I'm gonna make a GUI for managing Guix
<nixo_>Since I've been using guix for a year now, I probably should already know, but where should guix be installed for user accounts? under $HOME/.guix-profile or $HOME/.config/guix/current/ ? I can't find a way to have user-installed emacs packages in the profile
<nixo_>pkill9: are you going to rewrite emacs? :P No seriously, gtk/qt/web?
<leoprikler>nixo_: the guix command is under $HOME/.config/guix/current, packages are in $HOME/.guix-profile
<leoprikler>I personally would welcome a GTK interface.
<nixo_>leoprikler: thanks :) (also, I was missing emacs in the user profile, now everything is fine)
***Noctambulist is now known as Sleep_Walker
<pkill9>nixo_: i am thinking either GTK or QT
<zig>pkill9: what programming language will you use?
<pkill9>ideally guile
<zig>there is several work on-going to make gtk available in guile, there is a guile-gnome project already.
<zig>the two new work-in-progress project aim to make gnome-introspection available in guile
<leoprikler>actually, there are three
<leoprikler>guile-gnome, guile-gi and g-golf
<leoprikler>not sure whether g-golf has GTK already, but GTK via GI should be possible
<zig>that is to say, it will be a lot of work to make a gtk frontend :)
<zig>nothing you did not know already, i guess.
<leoprikler>Tbh. regardless of toolkit, things will be complicated.
<leoprikler>You need some kind of mapping between Guix records and toolkit widgets, and we already know from Emacs that those aren't necessarily all that intuitive.
<str1ngs>leoprikler because g-golf is a language binding to gobject introspection. it inherently supports anything that has gobject bindings like GTK
<leoprikler>as is guile-gi
*kmicu (╯°□°)╯︵ ┻━┻ once again no mention of Guix
<leoprikler>Both should support GTK, but tbh. I'm not really up-to-date on how mature g-golf is yet.
<str1ngs>guile-gi is more mature at this point. g-golf is still WIP
<leoprikler>Also I can't get off the feeling that g-golf relies heavily on whatever magic they put in their hl-api modules.
<str1ngs>I also wrote some limited GI bindings to QT. so you can in theory write use QT from guile. here is an example using g-golf
<leoprikler>Whereas guile-gi maps between GObject and GOOPS objects.
<str1ngs>leoprikler there is no real magic. basically use does the same thing
<zig>my pain point about those is that they rely on OOP.
<zig>(I do not know GOOPS)
<str1ngs>in this case OOP translates well to graphical toolkits. I'm not a fan of OOP either. but for toolkits it makes sense
<str1ngs>GOOPS is not so bad once you dive in
<leoprikler>well that's a given if you're using an OOP library
<str1ngs>zig: generic methods are kinda nice too
<leoprikler>that said you likely won't find a widget toolkit that isn't OO in some way
<leoprikler>(and if you were to make your own, you'd get OO but different)
<nckx>kmicu: Heh. I get & often share your frustration, but it's easy to forget that people outside of our bubble will have never heard of Guix and it's kind of our responsibility to change that. A friedly e-mail and/or comments can do wonders, unless you've already tried (‘once again’). I wish I had time to draft a blurb but I don't.
<nckx>…and posting comments requires reading ToS :-/
<dongcarl>Is there prior art on intermediate hashes between stages?
<dongcarl>Mostly thinking of: I build something that's hard to build... and it also has extensive tests, which I Ctrl-C'd, I want the next build to just be the 'test stage
<leoprikler>dongcarl: not afaik
<leoprikler>you might be able to do stuff locally if you pass -K
<dongcarl>Huh... Maybe I should contribute that... But it does seem like quite an extensive change
<nckx>dongcarl: This has been discussed (I mean, in general) but it was noted that many (most?) test suites require the intermediate build environment to still exist, and can't easily be run after installation without rebuilding anyway.
<dongcarl>nckx: not sure what you mean by "can't easily be run after installation without rebuilding"
<leoprikler>nckx: I think the idea was to keep the unfinished build and then retry building later from the dirty directory at a given stage
<leoprikler>e.g. performing all steps until and including build, then aborting, then doing stuff later
<nckx>dongcarl: I mean that the check target often rebuilds the actual software, and you can't easily say ‘oh we've already built it but it's in /gnu/store, use that’ for various reasons.
<leoprikler>I'm not sure if this scheme would be reproducible even without all the management steps involved
<nckx>It sounds extremely dirty.
<leoprikler>that it does
<nckx>Since dongcarl mentioned ‘intermediate hashes’ I was imagining something much more structured, probably involving the store.
<dongcarl>Okay, so why can't /9
<nckx>utraz: And change your password afterwards.
<nckx>Damn, too late.
<leoprikler>Well, you could put the stopped build into the store under some hash and probably retrieve it later.
<nckx>Something like that.
***ng0_ is now known as ng0
<leoprikler>But that's still very dirty
<nckx>Slightly less dirty, more inefficient.
<dongcarl>leoprikler: Why is that dirty?
<dongcarl>genuinely curious
<leoprikler>(perhaps it would be less dirty if we made a snapshot after each phase?)
<dongcarl>yes that's what I'm talking about
<dongcarl>only place in store after each stage
<dongcarl>not _at_ stop
<leoprikler>perhaps it would make sense to add this as an alternative flag to -K
*nckx back to work, but my answer to your unfinished ‘why can't’ would probably be ‘maybe we can, but need a more concrete proposal, including *how* this would work’.
<nckx>Nobody's saying can't yet, I think.
<nckx>Just wrinkling noses but that's a reflex more than anything 🙂
<dongcarl>nckx: Oh yeah for sure, I'm just thinking about what's the cleanest way to do this, so lmk if you think of any ideas!
<nomr>why is my guix building cmake 3.15.5 when there is a substitute available? The leading hash of the output is different from the available substitute ... Is this an error?
<leoprikler>nomr: different inputs?
<nomr>would that mean I have different versions of packages that cmake depends on than the substitute has?
*nomr looks into it =)
<leoprikler>well, that or some extra input or some of the inputs has a different input (and then recurse)
<nomr>thanks leoprikler
<nomr>I just noticed the guix pull attack issue ... I'm able to pull ok now, but if it helps anyone sometimes earlier used the crude git http protocol to get through: wget'ing the objects/info/packs file and then objects/packs/*.pack file in it. since wget can keep retrying ... thought it was my isp...
<zimoun>kmicu: thank you for the SIAM link.
<zimoun>kmicu: but it is ads! And IMHO the quality is heterogeneous... Do not feel frustrated because AFAIK Guix is probably one of the most advanced tools for reproducibility in the field of Applied Maths -- and I am in. :-)
<jonsger>hm seems to have issues
<zimoun>jonsger: yes, since a couple of hours. Yesterday too.
<kmicu>zimoun: nckx it was a friendly table flip cuz I’m a regular SIAM/Guix reader/user. No frustration here only fun ;) It’s nice to flip the table from time to time for a comical effect 😹
<kmicu>(Iiuc rekado_ represents bio/physics area of HPC and we still need to find some math folks.)
<kmicu>(BTW I only load mathjax on SIAM pages (and generally surf w/ javascript turned off by default) so I wasn’t even aware that they have some ads clutter. Sad to here that.)
<zimoun>kmicu: I have both hats. Previous life working on PDE and Krylov solvers. Now more about "bioinformatics" and workflow pipeline analysis. (With biologists, everything is bio-something: biochemistry, bioinformatics, biophysics, etc. Whatever.)
<zimoun>no, the news is just ads for projects (mainly US ones)
<PotentialUser-87>What's the equivalent of mkinitcpio's FILES option in config.scm?
<nckx>PotentialUser-87: What does mkinitcpio's FILES option do?
<nckx>You can pass whatever you want to Guix as (initrd …). I don't know if there's a ready-made facility for including custom files though.
<PotentialUser-87>include a file (such as a luks keyfile) in the initrd.
<nckx>Then you're already writing a custom initrd that reads and uses a keyfile anyway.
<nckx>Guix doesn't do that.
<nckx>PotentialUser-87: Have you read (guix)Initial RAM Disk?
*nckx away.
<PotentialUser-87>Yes. So what should I do to avoid entering my password twice on my librebooted computer with full disk encryption.
<kmicu>Hi PotentialUser-87 iirc we enter password twice for now and the issue is not solved yet. Please idle here for an answer from other Libreboot users.
<kmicu>(You’re not the first one mentioning the issue. I saw others on the guix-help mailing list too. Maybe the answer is there 🤷)
*nckx back
<nckx>This isn't related to Libreboot, it happens to everyone using LUKS like me.
<kmicu>Where ‘using LUKS’ means using it for protecting boot partition?
<kmicu>(Iirc libreboot has some support for full disk encryption and that’s why Libreboot users often go that path and raise the issue here.)
<nckx>Right. FDE, I guess it's called.
<nckx>kmicu: What kind of ‘support’? Doesn't seem like it offers an any more streamlined experience than other firmware.
<kmicu>Dunno, some libreboot user claimed something like that here in the past. I don’t own any hardware supported by Libreboot so didn’t pay attention. 😺
<kmicu>(I assume it’s possible that control over BIOS gives some cool powers to Libreboot folks.)
<PotentialUser-87>libreboot uses grub as its payload so because grub is already on the bios chip you don't need an unencrypted /boot partition.
<kmicu>^^ something like that
<nckx>PotentialUser-87: Thanks.
<Blackbeard[m]>Hi :D
<nixo_>PotentialUser-87: Hi, I'm on libreboot+FDE too, and too I'm inserting the passphrase twice :(
<nckx>Guix: twice as secure!
<jackhill>dongcarl: I'm interested in something like that too! My desire is for hacking on software where `guix environment package` isn't enough because the build system needs to be fixed up.
<jackhill>I was immagining some interface that allowed me to step through the guix build process interactively.
<nckx>Or --on-error=shell…
<nckx>(Where ^D continues the build magic.)
<nckx>I really thought we had --on-error=repl, but that was apparently but a vivid fever dream :-I
<alextee[m]>what's the right place to put the packages i want installed for my user in the system config?
<alextee[m]>i currently have them under (packages (append (map specification->package (... but i think that's bad because they get installed for root or something
<lfam>alextee[m]: The system config installs packages for all users on the system. Per-user packages aren't currently handled there (unless it changed recently!)
<alextee[m]>oh so it's correct to install them there
<alextee[m]>anyone know a package that makes it easy to create bootable usbs?
<alextee[m]>something like bootiso or etcher
<alextee[m]>just give it an iso and a drive and let it automagically(tm) create the bootable usb
<nckx>alextee[m]: What's the use case?
<alextee[m]>nckx: trying to make a bootable usb for a freebsd distro to check something
<alextee[m]>i used to use this script
<alextee[m]>but im having problems getting it working on guix
<alextee[m]>trying with sudo dd now but i'm a n00b
<nckx>alextee[m]: That's the normal way.
<nckx>Apart from dd, I only know of Unetbootin, if you want graphical complexity making things more complex 😉
<alextee[m]>ill try it out, thanks
<nckx>I'm 100% certain that FreeBSD just supports regular dd'ing though, if you download the memstick image.
<alextee[m]>if that fails i'll do it the hard (normal) way
<nckx>Downloading the ISO and using some tool to transform it into a bootable USB… eh.
<nckx>Not very BSD-y.
<nckx>alextee[m]: Good luck!
<lfam>You just have to make sure that the data is really completely written to the USB drive before you pull it out. By default dd doesn't take care of that
<alextee[m]>i see, thanks :D
<lfam>I think you can pass conv=fsync to dd
<nckx>Right. I always use oflag=fsync.
<lfam>"physically write output file data before finishing" and the same for metadata
<lfam>I don't even know the difference between conv and oflag here
<nckx>There's also conv=fdatasync, because nothing may be simple and inpire user trust, ever.
<lfam>Right, fsync is fdatasync plus for metadata
*nckx hopes this doesn't mean you're leaving us for the Open Source ☹
<alextee[m]>sudo umount sdb1
<alextee[m]>umount: sdb1: no mount point specified.
<alextee[m]>eh, this is hard
<stikonas>Unetbooting GUI runs as root, doesn't it? That's not very good. has a daemon that basically dd's image but GUI runs as regular user...
<nckx>alextee[m]: 1) is sdb1 mounted? dd doesn't mount things 2) if it is, umount /dev/sdb1
<nckx>2 won't hurt in any case, assuming you're sure that sdb is the right drive.
<alextee[m]>oh /dev/ thanks
<nckx>stikonas: No experience with it. That's a strange design decision. So is a daemon(??).
<nckx>gksu the-final-dd-step
<alextee[m]>dd is doing something, but it's very slow (92 kB/s) wow
<lfam>Try increasing the block size
<alextee[m]>so the general procedure is umount, mkfs.vfat, dd
<nckx>alextee[m]: dd if=the.iso of=/dev/sdx bs=4M is what I use.
<nckx>alextee[m]: Nope, just dd.
<nckx>dd is now blasting away the vfat you just made.
<nckx>But umount is important (this is why some people don't like ‘desktops’ that auto-mount things, amongst other reasons).
<nckx>alextee[m]: You want to add the sync option discussed above, though.
<alextee[m]>oh thanks, i am doing this now and it's super fast (5MB/s)
<alextee[m]>sudo dd if=/home/alex/Downloads/DesktopBSD-1.7-amd64.iso of=sdb status=progress oflag=sync bs=32768
<alextee[m]>i forgot the /dev again
<nckx>alextee[m]: Using sync dd without bs= is basically asking any modern drive to write the same thing many times over, which is slow & wears down your flash *much* quicker.
<nckx>rm sdb 😛
<nckx>I'd use an even bigger block size like ‘1M’ with sync, never know what strange erase block/bad firmware cheap USB drives have.
<nckx>And they're all cheap.
<nckx>But don't interrupt it now.
<alextee[m]>i see
<alextee[m]>yay i think it worked
<alextee[m]>i don't think it's recognized as a bootable usb though, doesn't show in the boot menu
<alextee[m]>but i can see the data when i mount it
<alextee[m]>may be missing a flag to make it bootable or something
*alextee[m] tries on another pc
<sebboh1>Hi all.
<sebboh1>Sorry, I haven't been using my guix vm much lately. I should know this already.. but, how do shell script shebangs work on guix? Am I supposed to have a /bin/bash available? Am I in the wrong profile or something?
<sebboh1>I phrased that poorly, I should have just said: I wrote a little shell script and I got this error, please help! -bash: ./ /bin/bash: bad interpreter: No such file or directory
<jackhill>sebboh1: if it's just for you, I suppose you could use /run/current-system/profile/bin/bash
<sebboh1>It's not just for me, actually.
<jackhill>also note tahat /usr/bin/env is now available by default, and that should be available on other systems.
<sebboh1>I'm submitting some solutions to this year's Advent of Code. :)
<jackhill>ah, sounds like fun!
<jackhill>I might try `#!/usr/bin/env bash`
<jackhill>but I'm not sure if that's the best recommended solution
<sebboh1>that's sensible.. Looks weird though. :)
<jackhill>yeah … just pretend it's a weird way to spell python or something
<jackhill>anyways, as I understand the /usr/bin/env discussion it was sort of for this use case: "there is all this software out there that expects to use it, and we don't want to break it even if it is technically unpure"
<alextee[m]>oh gnome has right click -> open with disk image writer, gonna try that
<sebboh1>I imagine that if I download some project that contains a shell script with #!/bin/bash, it won't work. But there are thousands such projects, surely we don't intend to edit every one... but. Now that I think about it. One of the top priority features of guix is the ability to install multiple versions of things side-by-side--even bash! So, a system-wide /bin/bash is not the solution. I think.
<sebboh1>I'm going to finish the project on a different machine that is not from the future. Let me know how this /bin/bash topic turns out. Seems like one of those problems that sounds simple at first but is actually quite hard.
<nckx>alextee[m]: Writing the image to the drive also overwrites the partition table, so there's no place for a flag to hide. Good to learn about the built-in Gnome thing, let us know if it worked.
<alextee[m]>nckx: the gnome thing worked similarly to manually doind dd, was even faster (7MB/s), but i still have trouble getting it to show on the boot menu
<nckx>sebboh1: Using #!/usr/bin/env bash in scripts has been considered ‘best practice’ for decades now, and those scripts will just work by default on Guix System. Assuming that /bin/bash exists has always been at the author's peril.
<nckx>alextee[m]: Interesting. I wonder what we missed while dd'ing.
<alextee[m]>maybe the freebsd iso file is bad, i will try trident OS don't know if it's free or not but i only need it to test something
<jackhill>sebboh1: I suppose you could make /bin/bash exist if you really wanted to by defining a special-files serive
<nckx>jackhill: Yes, it's trivial.
<nckx>It's how /bin/sh and /usr/bin/env are already provided.
<jackhill>er, service
<sebboh1>I see now that env bash is the right way to do it. Thank you.
<sebboh1>special-files service?
<nckx>(service special-files-service-type ("/bin/bash" ,(file-append (canonical-package bash) "/bin/sh")) …
<nckx>If you use %base-services I think you have to use extra-special-file-service.
<nckx>It's extra special.
<sebboh1>extra special. hehe :)
<nckx>Pasto. My ‘sh’ should be a ‘bash’ too, although it might not matter in practice.
<nckx>alextee[m]: So it was faster but the result is the same?
<alextee[m]>nckx: yeah, looks like it. it was simpler too, just right click, select disk, accept overwrite and it also showed me time remaining
<alextee[m]>perfect for n00bs like me :D
<nckx>alextee[m]: You used the memstick.img, right? And, just to make sure: you decompressed it if it was compressed before writing?
<nckx>alextee[m]: Simple's different things to different folks, I guess.
<alextee[m]>nckx: i can't find where i downloaded this from, but it's an iso named "DesktopBSD-1.7-amd64.iso" and iirc it was labelled as a desktop distribution of freebsd
<alextee[m]>maybe it was something else and not meant to be a bootable thing
<nckx>Pretty sure the FreeBSD ISO is for optical drives only.
<nckx>Eh, sorry, didn't even see the Desktop thing.
<alextee[m]>well the project trident thing clearly says "DVD/USB Install image" so maybe i'll have more luck
<nckx>But assume they have the same rules.
<nckx>alextee[m]: You're very welcome to post further questions here (I assuming you're trying to do this with Guix), but don't forget there are more BSD-specific Freenode channels too. They'll know more details about image variants &c.
<alextee[m]>thanks! will ask there next
*jackhill wonders what a recursive importer for Go packages would look like
<ScaredySquirrel>hey um I have a problem with some headers
***ScaredySquirrel is now known as insertsquirrel
<reepca>anyone else getting segfaults when trying to run murmurd?
*reepca just realized should probably reconfigure before asking
<reepca>well, reconfigured and the issue still happens... Dec 3 16:36:41 localhost vmunix: [1389245.712196] traps: murmurd[15529] general protection fault ip:7fdca77672f1 sp:7ffcb2d88670 error:0 in[7fdca76a6000+ca000]
<nckx>roptat: Your reply to Leo's IPv4 OpenSSH mail seems… off.
<nckx>(If you've sent a correction it hasn't arrived ye.)
<dutchie>if i have a patch that fixes a bug, i don't need to send it to guix-patches as well as the bug, right?
<dutchie>(also bump #36675)
<leoprikler>dutchie: No, just send it as reply to the bug