<apteryx>bricewge1: yep the first part of the fix resolves the issue here <apteryx>bricewge1: there's another error though: guix deploy: error: failed to deploy raisin: ~A: ~S <apteryx>interestingly the message is not properly shown <gnutec`>ryanprior: I had a problems with gdm after upgrade to kernel 5.4.12. I talk to the e-mail of Ludovic (ludo@gnu.org). But the problem was solve with new updates. Just wait! If what you did is good, they will add. Or you can share your scheme definition by your self. <apteryx>I think I know that one, it happens when trying to restart the nfs-server or something related <ryanprior>Of course, if I start packaging software built with v, then those will only be available in my repo as well, there would be no point submitting them upstream if the compiler isn't available XD <timothy_>Numbers are not rendered in IceCat for me. This even happens in the address bar. If I visit 'covid19.com', I see 'covid .com'. I am using i3 so maybe its an i3 configuration error? <NieDzejkob>timothy_: you're missing some fonts. Install font-liberation and/or font-dejavu and run fc-cache -fv <gnutec`>ryanprior: Is vlang 100% free as in freedom? <apteryx>bricewge1: I feel we shouldn't be seeing those ~A and ~S in the first place <apteryx>jonsger: no, that's a desktop I use at work *mbakke is currently provisioning a Debian VM using Ganeti with the debootstrap OS plugin <mbakke>why does 'chroot /debian-fs passwd -d root' fail, but 'chroot /debian-fs /bin/passwd -d root' works? <mbakke>export PATH="$PATH:/bin" works and explains it :P <mbakke>for once, I get to add a hard /bin/foo reference in a package definition.. <jonsger>mbakke: whats your motiviation ofr that debian vm? <mbakke>jonsger: I'm packaging the Ganeti virtualization system, so I can provision Debian and Guix VMs at will, and balance them across a cluster, all automatic :-) <mbakke>I occasionally need Debian for work, it's neat to be able to provision a debian/ubuntu VM from scratch and spin up a VM whenever I want <mbakke>I've used Ganeti for eons and have missed it in Guix, but did not dare trying to package it until now.. it's a complicated beast consisting of many different daemons, and written in a mixture of Python and Haskell. <mbakke>it's kind of like VMware, except more reliable (especially in a cluster setting), and without a pretty GUI ***catonano_ is now known as catonano
<raghavgururajan>While building, I get "ccache: error: Failed to create directory /homeless-shelter/.ccache/tmp: Permission denied". <vidak`>got my GuixSD install working on my big AMD Ryzen terminal a couple days ago :3 <vidak`>i read online that some people with an AMD RX580 graphics adaptor had no issues getting all their hardware working, but i found it necessary to, sadly, install some non-free firmware in order to get my RX550 adaptor working <vidak`>but all seems nice and functional now! <apteryx>bricewge1: try (uuid=? #f #f). It hangs. <apteryx>I just recurses switching parameters ***cjpb0 is now known as cjpbirkbeck
***terpri__ is now known as terpri
<gnutec``>Leaving but happy with my Guix System. o/ <ijimiji>Hi, everyone! Does xdg-mime db rebuilding still take eternity to finish? <ijimiji>I used Guix in time. And it used to be a problem. <xelxebar>Apparently responding also takes too much time for ijimiji :/ <xelxebar>But, yeah, what *is* up with the mime database regeneration. Might be fun to look into that. <bricewge1>sneek later tell apteryx: I see it now, the parameters 'a b' switches to 'b a'. Thank for the fixes! <nckx>raghavgururajan: ‘ccache: error’: It makes no sense to compile Guix packages with ccache. Which package is this? <nckx>vidak`: Happy to hear most of that! <leoprikler>bonz060: what do you mean by "generating a manifest file"? <leoprikler>you can certainly write one by hand, but I doubt that's useful <nckx>leoprikler: guix package --list-installed > manifest.nope <nckx>That's what that linked script does. <bonz060>leoprikler: like if there's a guix profile that's looks like `guix archive --manifests` and then later ingest it vis-a-vis: `guix package -m manifest.scm`. Does guix provide an inbuilt CLI flag to output a manifests.scm file instead of writing a script that does that? That's what I mean. <leoprikler>So you basically want that script baked into Guix? But why? You already have that script? <bonz060>leoprikler: I'm thinking it's a convenient that alot of people would want. At some point when moving machines, you'd research how to reproduce your system right? At that point, it would convenient to have an inbuilt tool that generates the manifests file for you <leoprikler>Perhaps, but the manual already points you to manifests for the reproducibility aspect. <leoprikler>You may also consider partial manifests, if e.g. you really need your Emacs configuration, but none of the other packages shared between your personal and business setup. <nckx>bonz060: It would be misleading to call a list of packages (as produced by ‘guix package -I’ or your script) a ‘manifest’. <nckx>If you want to reproduce your system based on a list of package names, you can already do that: bonz@old ~$ guix package -I | cut -f1 > fake-manifest; bonz@new ~$ guix install $(<fake-manifest) <nckx>All your script does is add quotes and some Schemey-looking boilerplate to make ‘guix package -m’ accept it, but it's not a manifest in any meaningful sense. It's a name list. <nckx>(That's good enough for boats, not for Guix.) <Bryophyllum>Hello Guix o/ May someone do a favour for me? I need the output of `tree` run in the /boot directory on a UEFI system (CSM disabled). <oliverp>hm feels very much like Hurd's design makes so much sense in 2020 <oliverp>kind of unfortunate that Hurd have made more progress <Bryophyllum>NieDzejkob: Thanks. To clarify, do you mean that your /boot directory is separate from /? <NieDzejkob>Bryophyllum: Yes, I mount the ESP partition at /boot/efi <Bryophyllum>NieDzejkob: Oh. /boot/efi, not /boot. Gotcha. Speaking of which, isn't an ESP partition at /boot/efi a requirement? Like, I know the /boot itself can be a fat32 partition, and this fact alone makes a separate mountpoint for the ESP partition redundant, but I personally think that /boot whether on an external partition or not, should be on more corruption resilient FS, such as ext4, on UEFI systems <guix-vits>oliverp: I'd read someone told on StackOverflow that "microkernel is not for faint hearths" or so. Though me too want it. <nckx>That's meaningless without context. Hacking on a monolithic kernel like Linux is hardly for the faint-hearted either, and potentially more dangerous. <guix-vits>Bryophyllum: maybe support for FAT is easier to maintain for UEFI firmware? <oliverp>guix-vits: well I would not put to much trust in something someone wrote at StackOverflow in subject <nckx>Hurd is absolutely not plug-&-play, certainly on hardware, that's certainly true. But we can guess at what they actually meant all day. <nckx>Or we can work on improving it like janneke et al are doing, which seems to be a better route. <nckx>My BIOS still refuses to do the VM good, I'm chomping at the bit to try it out… <oliverp>nckx I would not state it so much of what it is today but rather what Hurd's potential is given its design <apteryx>mbakke: provisioning other OS VMs can also be useful to test Guix on foreign distributions! I don't have non-Guix machines around anymore. <sneek>apteryx, you have 1 message! <sneek>apteryx, bricewge1 says: I see it now, the parameters 'a b' switches to 'b a'. Thank for the fixes! <oliverp>Also having in mind that its 2020 now hehe <apteryx>mbakke: we also seem to be lacking vagrant and packer, other tools for VM provisionning. <janneke>nckx: thanks; i think oliverp that if we want to make hurd grow into something nice, there's some very hard work to do, and a great lot of pretty mundane work too <janneke>discussions amongst the non-involved...i dunno; can be entertaining i guess <janneke>i for one was amazed how well it works, a year or so ago <janneke>i'm a big fan for working towards the changes you'd like to see happen <oliverp>janneke: yeah its super that someone doing is efforts with regards to try provide Guix Hurd-wm image <oliverp>janneke: +1 well I'm writing on something, that might could help at least a little bit <oliverp>janneke: and while its not ready for publishing yet it could in a week or so maybe <oliverp>jannkeke, maybe I could connect back then for some kind of feedback <janneke>that's great; being involved does not necessarily mean to write code <janneke>oliverp: sure, please do -- have you seen #hurd? <nckx>raghavgururajan: Not on wip-desktop? Could you paste the package? ccache is meant to speed up incremental compilation (and it does so wonderfully) but makes no sense in a chroot that's thrown away after each build. If by default wpewebkit won't build without ccache I'm sure it can be disabled. <oliverp>janneke: thanks. well yeah while I have a cretin understanding of C, writing code is what I consider my strongest skill <nckx>janneke: Is there a GuixHurd for noobs guide newer than the 4 April blog post? <janneke>nckx: no, and that's terribly outdated too; even if you meant to type April 8 *janneke remembers those dates and that week well <Bryophyllum>guix-vits: It is. What I meant is that mounting the ESP partition at /boot/efi is compliant with the spec, and should be preferred over a FAT-formatted, separate /boot partition, as it usually holds kernel and initramfs images that I wouldn't trust FAT with <Bryophyllum>Though, Guix seems to not store those on /boot, so it doesn't matter <xelxebar>Aaaargh. Updating the commit on this package is sooo annoying. It takes forever to clone, but then to get the hash, I have to let the build error out. <xelxebar>Then the build *clones the repo all over again* :( <xelxebar>Is there a better way to get the sha of a repo? <guix-vits>xelxebar: Do You mean "other than `guix hash -rx .`? <xelxebar>That's arguably cleaner, but it still requires checking out a repo twice. <xelxebar>It's annoying that updating the hash completely changes the store output for the checkout. <jlicht>civodul: I really enjoyed your reproducible journey in reproducing research results! <Bryophyllum>NieDzejkob: Excuse me for interrupting you again, but shouldn't the i386-pc directory be only present on BIOS installations? <xelxebar>jlicht: That sounds awesome. Mind sharing a link? <bonz060>janneke: when working on hurd, do you run it on a VM? How'd a noOb(I primarily have a tonne of wed-dev experience) start out? That's something I'd like to start exploring but I don't have an idea of how to start :( <civodul>with an excursion in GNU and Guile history <janneke>bonz060: using the guix system with current guix master, that has become very easy to do <bonz060>Are there beginner-friendly resources that discuss about getting into hurd dev work? <janneke>bonz060: i maintained a readme-like file for that, for a while <oliverp>very general about hurd contributions.. <janneke>is possibly the easiest resource to get going...feel free to ask specific questions, here or in #hurd <bonz060>Yeah thanks man. It's really encouraging that the hurd effort is being driven by guix afaiu \m/\m/. <nckx>Bryophyllum: If it's left over from a previous/other OS it's harmless, but grub-efi should use x86_64-efi/, yes. <jlicht>general question on G-expressions, but how would one make packages with native-search-paths 'usable' in the context of the g-exp? I think this is nicely solved for guile modules and closures, but is there some way to generalize this to e.g. EMACSLOADPATH? <civodul>jlicht: what you can do is add your packages to a profile; the from the gexp, call 'profile-search-paths' and 'set-search-paths' <jlicht>civodul: can I actually create profiles programmatically? That would solve this quite niceley <civodul>jlicht: yes, there's a new 'profile' record constructor <civodul>(profile (content (packages->manifest (list python python-numpy)))) <civodul>and then you can #$ that in your gexp <jlicht>wow, that is cool. Thanks a bunch! <jlicht>wow, that is cool. Thanks a bunch! <pkill9>does there exist a simple daemon manager for user daemons? shepherd is a bit much <pkill9>something where you run it and it gives an ncurses list of running processes it owns, and you view their output inside it <pkill9>a step above executing the daemon in .profile <civodul>shepherd does little more than that :-) <civodul>it actually does less: no ncurses interface <civodul>there are probably other options, though <pkill9>I don't want to have to create the services first though <pkill9>I just want to run the executable with the daemon manager <pkill9>yea it probably exists somewhere <xelxebar>pkill9: something like runit and svlogd, perhaps? <pkill9>probably owuldn't be too difficult to make either <pkill9>i think I could easily make a bash script that runs them in tmux <pkill9>hmm maybe it wouldn't capture the programs though <xelxebar>pkill9: Looks like s6 is already packaged. <jlicht>civodul: it worked! Although I had to do some data-massaging, as profile-search-paths already called evaluate-search-paths, as does set-search-paths <civodul>jlicht: ah good, i wasn't entirely sure of the combination <pkill9>why is syncthing so damn annoying to configure without a GUI? <jlicht>pkill9: people who have a need for a configuration file and think "I know! I'll use xml, that'll make life easy!" have plenty of things wrong with them ;-) \s <leoprikler>"Hmm, I need a configuration file... better write my own language while I'm at it." <pkill9>they have a browser-based configuration, except it doesn't render with a CLI browser. they have a REST API, which is annoying enough but you also need to create an API key. There is an 'stcli' program but not only did it not accept the syntax (if i even was using it correctly), but apparently it's deprecated <pkill9>and yea, on top of that the config file uses XML <clemens3>jlicht: well, exactly 20 years ago I belonged to that group.. but yeah, pain makes you wiser <cbaines>Does anyone know how to work out with Guile/Guix what the current system (x86_64-linux, ...) is? <pkill9>cbaines: %current-system might be what you wnat <cbaines>pkill9, ah, I wasn't expecting that to have a default value <cbaines>but I've just noticed (guix config) has %system, so I might just use that <nckx>o_o Welp, there's a first time for everything. <nckx>raghavgururajan: We're going to get rid of it, but ccache would be a perfect example of an input that should be native, since the ccache binary runs at build time. <nckx>leoprikler: Ikr. Is that an ‘embedded’ thing? <nckx>‘They do things differently there.’ <nckx>raghavgururajan: Well, we really want to get rid of it, so it doesn't matter much, but OK. *nckx building without ccache, waiting for fail. <leoprikler>In my own experience, it's not embedded unless you're testing with GDB on at all times. <nckx>raghavgururajan: Oh, I get a gstreamer (possibly too old) error instead. <nckx>Atop which branch are you building this? <raghavgururajan>nckx: Wait, it started to build? I got error at configure phase for missing ccache. <nckx>This is during the configure phase. <nckx>My guess is you have a newer gstreamer on your end? <raghavgururajan>OK. You will have to use gstreamer and gst-plugins-base patches from the archive file I sent yesterday. <leoprikler>nckx can do -DUSE_GSTREAMER_GL=OFF or something like that? <nckx>raghavgururajan: Thanks, but I still have the exact checkout we built openjdk/icedtea from y'day. <nckx>raghavgururajan: Did that substitute by the way? <nckx>raghavgururajan: # Enable ccache by default, if installed. To disable it you can: # if using script build-webkit: pass --no-use-ccache # if using cmake: set environment variable WK_USE_CCACHE=NO <nckx>From Source/cmake/WebKitCCache.cmake. <nckx>raghavgururajan: To answer your earlier question: ccache is a compiler (‘cc’) cache. It replaces gcc (the normal way to use it is to create a /usr/local/bin/gcc → /usr/bin/ccache symlink, which precedes the ‘real’ GCC in $PATH). When you call it the first time, it will simply call the real GCC, producing the exact same output. But it will also save the output so the next time you call it with the exact same arguments, pwd, etc. it can si <nckx>mply (and immediately) return the exact same output without compiling everything again. <nckx>It works remarkably well. <nckx>Just not in Guix, since package builds can't save sneaky state. <leoprikler>well, in guix we have substitutes, which work like ccache on drugs ;) <raghavgururajan>nckx: Woah! That sounds handy. No way to implement similar technique in guix? <leoprikler>for packages? substitute. In general? Have a look at GWL. <raghavgururajan>For example, if a build fails at, say, 67%. When you rebuild, it starts again at 0%. <leoprikler>the thing is, you don't get the same package in a build, that doesn't fail at 67% deterministically <leoprikler>so even if we had a build cache, it would probably not do what you'd expect it to <nckx>raghavgururajan: Yes, that's exactly the problem that ccache solved for me on Exherbo. Even a minor version update would share 99% of the previous source files so most package upgrades went a lot faster with a full cache. ***jonsger1 is now known as jonsger
<nckx>However. There are edge cases (I had to rm -rf my ccache once in a while to get rid of ‘weird’ errors) and there are some serious trade-offs that I don't think belong in Guix. <raghavgururajan>leoprikler, Ah, gotcha! If say, foo.o and bar.o was compiled at 3% and over-al build fails at 10%. If those *.o files not gonna be changed in rebuild, we can reuse those cached files right? <nckx>Guix gives me peace of mind: almost every time I think Guix screwed up/got confused, I look again, and it turns out it was right and I was confused 🙂 That's extremely valuable. You'd lose that peace of mind and the nagging state gremlin (whispering ‘maybe you should just reinstall…’) on my shoulder will return. <leoprikler>but how can you be sure, that those *.o fails would not be changed? <leoprikler>If you rebuild, then very likely you changed the package description between the two invocations. ***apteryx_ is now known as apteryx
<leoprikler>how do you ensure, that everything leading up to the 3% build is the same between those two builds? <raghavgururajan>leoprikler, nckx: For example, a while ago, I was building a package. It failed at 95% due to missing glu.h. All I had to do is rebuild with glu as input. Here, all the files that were compiled before 94%, didn't depend on glu.h. So those 94% of compiled files could have been reused right? <leoprikler>no, because your build system could have done something weird if it detected glu, adding additional sources to the files that are compiled <leoprikler>adding -DHAVE_GLU so that the files that you do compile compile differently <leoprikler>I'm currently trying to package ppsspp, and they recently introduced an issue that requires to build with ffmpeg <raghavgururajan>leoprikler, Ah, good point. I wish there was a way to detect that. Like hashes or something? <leoprikler>(I already wanted to package it with ffmpeg support anyway, but you get the point) <leoprikler>what could help was if you used GWL as build system and we had (guix build-system gwl), which specifically shares the GWL cache with the build <nckx>raghavgururajan: It does use hashes. It also looks at command line flags and variables like CFLAGS and working directories and …. leoprikler's scenario is probably too trivial to confuse ccache, but any cache makes tradeoffs, and Guix doesn't, so the two aren't compatible. GWL is a much better (and ‘native’) approach that a magical ‘cc’ binary. <raghavgururajan>leoprikler, Hmm, but build-system could not have done something to files that were compiled before 94%, because their respective .c files did not have #include glu.h <leoprikler>It could very well be, that they have that in an #ifdef HAVE_GLU <raghavgururajan>leoprikler, I scanned the source with the string and only one .c file had the line glu.h *guix-vits "<3 #include /thread" <nckx>leoprikler: Is that a real-world example of ccache breaking? It sounds like something ccache wouldn't have trouble with unless there's something much more subtle going on. <leoprikler>tbh. I'm not sure how ccache would react, but it is something we shouldn't cache from a Guix POV <nckx>#ifdefs are removed by the preprocessor so it sounds bogus. <nckx>You're misunderestimating a properly configured (and it's sane out of the box IIRC) ccache but I certainly agree it's not a good fit here. <leoprikler>yeah, but who manually invokes the preprocessor? <raghavgururajan>Is there a reason why hpc and workflow are at guix.info, instead of, guix.gnu.org? <nckx>One of the reasons that a first ccached compilation is slower. It's really quite careful. <nckx>raghavgururajan: There is but I forgot what it was 😛 <nckx>raghavgururajan: Whatever it was it's not a ‘hard’ reason though, if we'd let the guix.info domain expire there's no reason not to move them over. <raghavgururajan>I think it is better to move hpc.guix.info and workflow.guix.info to hpc.guix.gnu.org and workflow.guix.gnu.org, respectively. This makes things less fragmented. <leoprikler>Or to be contrarian, we could also move guix.gnu.org to guix.info ;) <nckx>I honestly can't remember the past arguments about this. <nckx>Am I just old that .info still sounds a bit… no? I mean, let's go full guix.biz. *nckx old man yells at ‘new’ TLDs that seem downright quaint next to actually new TLDs… <nckx>I kept an eye on guix.org this year but it was renewed a day before expiry. Oh well. *raghavgururajan prefers gnu project's sites to be on sub-domains of gnu.org. Looks logical. <nckx>One day their script will fall asleep. <nckx>raghavgururajan: I agree, I like .gnu.org despite the mouthful. *raghavgururajan orders lunch on seeing wpewebkit at 59%. <leoprikler>I think we should lobby .still-compiling to be a TLD specifically for Gentoo folks *nckx .oO first stone and all that. <leoprikler>Not to fault them, it's rather an homage at their trademark ;) <nckx>PotentialUser-36: Assuming you accept ~60 MiB of binaries to get started (like every distro has — and the have *a lot* more): yes. <nckx>PotentialUser-36: Simply don't authorise any substitute servers (or remove the default one if you use Guix System) and your CPU will get nice and warm. *guix-vits "the Fairies wear boots, and You got to believe me... I tell You no lie.." <nckx>guix-vits: I'm not sure I understand the question. HOME is set (and I believe exported) to "/homeless-shelter" in the build environment. Shells use the value of $HOME to expand ~ (~/foo is just syntactic sugar for $HOME/foo). <nckx>So if you change $HOME it will change ‘echo ~’ as well. <nckx>Does that… answer it at all? <guix-vits>nckx: but Raghav uses setenv in that package? Why HOME isn't set there? <raghavgururajan>nckx: With the same environment as yesterday, could you build ffmpeg please? <nckx>guix-vits: It is set, to /homeless-shelter. setenv changes what it's set to. <nckx>raghavgururajan: Anything else? I'm about to get on a bus. <mwelt>Hello everyone. I am trying to install guix onto an usb stick, and fail remarkably on installing grub. <mwelt>It complains about not getting canonical path of /boot/efi. <nckx>guix-vits: The argument for not setting HOME=/tmp by default is that it's nice to know (and document for posterity it in code) when packages use it because it can be a sign of weirdness. <nckx>mwelt: Is your EFI System partition formatted as FAT32 and mounted at /boot/efi? <nckx>The only time I've got that message was when it wasn't. <nckx>guix-vits: Yes, to catch builds silently writing to $HOME. <mwelt>nckx: All done and dusted by the guix gfx installer, didn't change something by myself. <nckx>Well, sure, and / is ro so it won't be created, but that's the point. <nckx>It's just a silly way to say /bogus-value. <guix-vits>a breaking news. But at least i feel less confused now. <raghavgururajan>nckx: Pardon me! Just came across new needed things. fluidsynth lash zbar qtx11extras chromaprint ffmpeg sdl2 fcitx enchant spandsp sox ao ccextractor opencv pangox-compat vtk <raghavgururajan>gtkglext libopenmpt vulkan-loader directfb wpebackend-fdo transcode libde265 <mwelt>nckx: maye I have to go back to pre-shool and look up the way efi works anyways. Is efi partition something bios related or is it actually related to the physical disk (i.e. usb stick). <nckx>mwelt: Wow, I don't have time to answer that can o' worms I'm afraid 😉 <nckx>raghavgururajan: OK, that might take a while. See y'all in a few hours. <mwelt>leoprikler: ah i c. This is actually not what I want. I want to be able to boot this usb stick from another hardware setup...just like the install iso of guix works. So am I able somehow to install grub just on the mbr of the usb stick? <leoprikler>you could try grub without efi, that tends to work out (at least for me) <leoprikler>(bootloader-configuration (bootloader grub-bootloader) (target "/dev/sda")) <mwelt>leoprikler: so i figure i have to change (bootloader-configuration (bootloader grub-efi-bootloader) (target "/boot/efi") ...) in some way? <nckx>raghavgururajan: guix build: error: transcode-ffmpeg.patch: patch not found… <mwelt>raghavgururajan: If this efi thing is something bios related, I do not actually want that. I want something like the guix installer USB, which can boot from every system. <nckx>raghavgururajan: I don't have time to fix that now, I'll see what builds. Maybe nothing. <mwelt>leoprikler: ah thx a lot! I'll try. <guix-vits>leoprikler: Gentoo wiki features some "hybrid" partitioning: BIOS-boot, EFI, the rest. Can be of use for mwelt? <raghavgururajan>mwelt: In that case, you use grub-bootloader instead of grub-efi-bootloader. Make sure that usb stick is MBR partitioned, so that grub is installed on MBR Gap. <mwelt>raghavgururajan: MBR partitioned / gap means partition starts at 2048? <raghavgururajan>mwelt: As leoprikler mentioned, (bootloader-configuration (bootloader grub-bootloader) (target "/dev/sdX")). <mwelt>raghavgururajan: I am in the middle of trying this, but I have to figure out nano first ^^ would rather use vi :) <raghavgururajan>mwelt: Not sure, but it doesn't matter. As long as the usb stick is mbr partitioned, grub should get installed correctly. <leoprikler>mwelt you can guix install vi after mounting cow-store IIRC <raghavgururajan>mwelt: Beware that, whenever you do `guix system reconfigure`, you have to double-check sdX and change "target" accordingly. <mwelt>raghavgururajan: maybe I should use disk uuid as target, if this is possible as leoprikler mentioned. <raghavgururajan>But isn't UUID points to filesystem (sdXY), instead of device (sdX)? <mwelt>raghavgururajan: actually I am not 100% sure about that, but you might be right, that this is only a partition thing. But there must be some way to uniquely identify the hardware component itself <mwelt>leoprikler: not for installing grub in mbr, do I? <raghavgururajan>mwelt: May be, you can use GPT. In this case, you will create two partitions sdX1 and sdX2. sdx1 can be BIOS Boot Partition. Also, here target can be a partition sdXY. <raghavgururajan>Only for MBR, the target should be device itself (sdX) and not a partition (sdXY). <leoprikler>Inspect guix-daemon.service. If it mentions gnu-store.mount, then the package itself is broken. <lfam>Hm, I updated my Guix installation on Debian and now my urxvt font is messed up <lfam>Something changed in the last couple weeks <lfam>And I don't it's related to the gs-fonts / pango issue. I use font-anonymous-pro in the terminal <lfam>Indeed, I straced and it's trying to open the wrong font <lfam>For some reason it's using '/gnu/store/...-font-dejavu-2.37/share/fonts/truetype/DejaVuSans.ttf' instead of '/home/lfam/.guix-profile/share/fonts/truetype/Anonymous Pro.ttf' ***jfred[m] is now known as jfred[m]1
<apteryx>lfam: I haven't had time to investigate, but japanese fonts stopped working on one of my machines, possibly related <lfam>I feel bad filing another mysterious bug report about fonts <lfam>I don't really know how to debug it ***hitchcock.freenode.net sets mode: +o ChanServ
<mbakke>lfam: font cache issue perhaps? font-dejavu is the grafted fallback in fontconfig when no other fonts were found <lfam>mbakke: I deleted '~/.cache/fontconfig' and '/var/cache/fontconfig', ran `fc-cache -rfv /usr/share/fonts ~/.guix-profile/share/fonts`, but it still doesn't work <lfam>I also tried updating with --no-grafts which should avoid the fontconfig change, right? <mbakke>lfam: yes, --no-grafts should make it fallback to the broken gs-fonts <tmck>I've just installed guix system alongside debian (and windows), and after manually copying the GRUB menu entry into my existing grub, I am able to begin guix boot -- but it keeps freezing during "early boot guile"(?), the last message is usually `parport_pc parport_pc.632: Unable to set coherent dma mask: disabling DMA` -- any suggestions on how to ***mekeor- is now known as mekeor
<tmck>i removed the "quiet" argument from the guix grub entry -- with more verbose output i can see the boot reliably fails at `switching to amdgpudrmfb from EFI VGA`, looks like i am missing some firmware <NieDzejkob>tmck: BTW, Guix's update mechanisms rely on being able to modify the grub config, I'd recommend letting guix manage the bootloader and setting it up to include entries for other OSes <tmck>Bryophyllum the display was plugged into an RX 580, I am trying to see if I have any luck running it off my Ryzen 5/Vega now <tmck>NieDzejkob noted, thanks! i will try that out <nckx>tmck: Or you can add a ‘Guix’ menu entry to your existing grub.cfg that loads Guix's grub.cfg with ‘configfile’. Guix wants to manage (a) grub.cfg but it doesn't have to be your only boot loader. <nckx>raghavgururajan: Things are building at full capacity now, I don't know how much work was done while I was travelling. <nckx>I'm currently building 2 ffmpegs (4.2.2 and 3.i.forget). <vagrantc>lfam: still building rust-1.20 ... will see about the rest <vagrantc>i didn't actively ask for rust ... but something in my system and user profiles apparently depend on it ***drakonis1 is now known as drakonis
<lfam>vagrantc: Do you use ffmpeg? <lfam>It recently gained a dependency on a rust library <nckx>To make matters worse 2 aarch64 build nodes are still down for the week-end. Reconfigured & rebooted them & neither respond over SSH. <hendursaga>Hello all! I've decided to take the plunge and try out GuixSD, on a VM. I'm excited by the possibilities, especially the container technology. I guess I'll be learning another Lisp soon :) <nckx>hendursaga: Welcome. Guix is filled with possibility 🙂 <hendursaga>Thankfully I've decided to switch to Emacs a few months ago, so I suspect Lisp development would be a lot easier. <nckx>gnutec: Are you asking which to prefer…? TL;DR: it doesn't matter. xz is much more common. <gnutec>some times ago, Guix dev told that will use lzip. I see when I install a package something like "lzip/...". But I still don't understand how it's work. rsrsrsrsrs <civodul>lzip is a tool with a good compression ratio/compression speed <gnutec>nckx: some times ago, Guix dev told that will use lzip. I see when I install a package something like "lzip/...". But I still don't understand how it's work. rsrsrsrsrs <NieDzejkob>ci.guix.gnu.org responds with 504, is there some monitoring for this? <nckx>gnutec: Yes, lzip replaced gzip as the default compression algorithm for ‘guix publish’. I think this was done because it's a GNU(ish?) project and there were bindings available (again: ?). lzip has… opinionated marketers^Wmaintainers. I don't like them. Both xz and lzip compress equally well (with xz performing ever so slightly better in my tests). <nckx>As a user, you wouldn't notice a difference between xz or lzip in practice. <civodul>nckx: lzip is much less memory-intensive than xz IME *vagrantc wonders what will need to be removed from vagrantc's profile/system config <NieDzejkob>vagrantc: I've located the culprit and git blame says it's been that way for at least a year <nckx>civodul: Funny. Last time I tried lzip 'tutes there was an obvious memory leak (which you couldn't reproduce) using gigs of mem 😛 <vagrantc>NieDzejkob: well, this system hasn't changed much ... so it must be some new dependency somewhere :/ <apteryx>xz has (had?) bootstrappability problems IIRC. <nckx>That's a good argument since memory is a pretty hard limit. Especially since the compressor chooses how much RAM the decompressor will need. <nckx>apteryx: True, that's why sed switching to .tar.xz-only releases was a problem. Is lzip better in this regard? *vagrantc systematically builds all the packages in the profile to see which pulls in rust <nckx>I forgot /gnu/store/7qnj3ipciagrgyynsrfa4zpf8gw3ggz8-ffmpeg-3.4.7. *NieDzejkob is about to test building rust for i686 on bayfront <apteryx>eh, I get out of memory failures during the tests when building a slightly modified Guile 3.0. <pkill9>ok it wasn't too difficult to configure syncthing, i just needed to do an ssh port forward, then i could change the settings in my laptop's web browser, still sucks they make it way too difficult to configure via commandline <mbakke>vagrantc: we should probably remove the rust dependency from ffmpeg on non-x86_64 <mbakke>or better yet, complete the aarch64 rust port <vagrantc>mbakke: ah yes ... apparently sway -> wlroots -> ffmpeg -> rust ... <mbakke>funny that wlroots depend on ffmpeg <civodul>janneke: damn it, i broke your time-machine workflow again! <janneke>civodul: weird, no? we reverted all to 5e9cf93364d87c70f8bfad915417cd75d21c0fed, so we're "fine", as in: no hurry :-) <janneke>civodul: i'm not sure why i didn't catch this -- that's why i gave it a test ride... <civodul>you can use --disable-authentication too <civodul>still, are the two commits actually unrelated? <janneke>ah, --disable-authentication should also work :-) <NieDzejkob>does anybody have an idle arm server lying around? I think building rust in QEMU will take a good while... <ngz>I'm trying to update our xmoto package. The new version builds fine, but I get texture rendering errors at run time (error message displayed when trying a game). I would appreciate if someone else could build it too and report if they encounter the same problem. The package updated package definition is at: https://paste.debian.net/1152957/ <civodul>janneke: i think that "staging" branch that "bad" is on was forked before 36640207c9543e48cd6daa92930f023f80065a5d <civodul>what good tools do we have for that? <civodul>all the UIs try to be smart so it's hard for me to understand what i'm looking at <janneke>right, silly me just did git log --pretty=oneline | grep ==> ah, linear history <civodul>i think the problem is: commit 36640207c9543e48cd6daa92930f023f80065a5d was made on master (May 29) after commit 9edb3f66fd807b096b48283debdcddccfea34bad (May 26) <vagrantc>mbakke: there's no mention of ffmpeg in wlroots sources ... <janneke>oh...so the problem is actually bigger/not solved yet <janneke>because of non-linear history/merges <mbakke>vagrantc: the wlroots package definition is weird, why does it have libpng and libcap as native-inputs? *vagrantc is building now with --with-inputs=ffmpeg=hello :) <ngz>mbakke: I see you have an advanced ufoai package lying around. OOC, do you have any plan to submit it for inclusion? Did you encounter any issue with it? <vagrantc>mbakke: it looks like it does depend on libav* ... which comes from ffmpeg? <mbakke>ngz: it works great, but it's 1) based on the git source, and 2) will rebuild the maps every so often, and the map generation is not great, so it might create "bad" maps (there are tests to catch this). <mbakke>the official ufoai releases come with pre-generated "vetted" maps <mbakke>vagrantc: probably we should exclude the ffmpeg rust dependency on non-x86_64 until NieDzejkob has finished the porting work :P <mbakke>Bryophyllum: thanks for the information, we should not need to add "dependencies of dependencies" to packages in guix, so it would be good to remove those <mbakke>or fix the missing propagation if any <mbakke>NieDzejkob: are you working on rust 1.19, or updating the bootstrap chain in the same go? <ngz>mbakke: Thanks. Do you think it is possible (and worth the trouble) to switch it to official release, and therefore benefit from the "vetted" maps? I assume downgrading to 2.5.0 will require additional patching. <mbakke>ngz: yes, 2.5.0 requires a lot of patches, and according to #ufoai 2.6 was "mostly complete", so I just went for it :P <mbakke>ngz: I suppose we could add it with a warning that it is a pre-release <ngz>mbakke: It would make sense, IMO. <vagrantc>mbakke: my ffmpeg->hello hack seems to have built ... haven't tested yet, but ... <mbakke>ngz: OK, I'll add it to my patch queue :-) any review comments while you are at it? <ngz>mbakke: Thanks! I assume the hard-coded "CC=gcc" will be frowned up… <Bryophyllum>Excuse me for interuppting, but is there a particular reason as to why the graphical installer doesn't support XFS? <apteryx>reproducible FAIL: test-out-of-memory when building guile 3.0.2 :-/ <mbakke>ngz: hah :-) I would not dare trying to cross-compile it, but will adjust, thanks! <ngz>mbakke: Also, AFAICT, the license field could be (list license:gpl2+ license:public-domain license:cc-by-sa3.0). <nckx>Bryophyllum: Because Guix System itself doesn't support it. Support needs to be added to gnu/system/{uuid,linux-initrd}.scm to be able to boot, then you can add it to the installer. <nckx>You don't have to apologise for ‘interrupting’ lines on IRC 🙂 <mbakke>ngz: ah right, I suppose the assets are not covered by the copyleft nature of GPL2+. Good catch! :-) <ngz>mbakke: I'm surprised you don't have to mess with CPATH and sdl-union. <NieDzejkob>mbakke: I'm working on 1.19, so far it looks like it might be doable without rebuilds on x64 <Bryophyllum>nckx: Ahahah. If only I knew about that yesterday. I spent an entire day doing research on benefits of XFS'es asynchronous discard on SSD that only support blocking TRIM. <NieDzejkob>in other news, building rust@1.19 just doesn't work in QEMU <NieDzejkob>(ci has logs of rust@1.20 failing on armhf and I didn't touch 1.19, so it must be a QEMU problem) <terpri_>Bryophyllum, it's not too complicated to add new FSes. i livepatched btrfs support during installation some years before it was officially supported <terpri_>Bryophyllum, if you don't want to hack it in personally, you could file a bug and it would probably get added in the near future <nckx>Bryophyllum: It's not much work if you feel like giving it a try. Not that much code either. Just looking up the location of superblock/label/UUID in docs/C code and translating that to Guile. <nckx>I might add XFS if I get stuck on a bus again. <NieDzejkob>Is there a chance we could add an ARM machine for offloading on bayfront? <nckx>Oh, so spake terpri_ already 🙂 <nckx>raghavgururajan: OK, building. <terpri_>speaking of arm machines, the mnt reform laptop project looks really cool, and potentially an RYF-compliant modern laptop <nckx>raghavgururajan: OOM (out-of-memory) killings are always logged in dmesg. <mbakke>NieDzejkob: bayfront used to have an ARM machine actually, hosted by Andreas. If you email guix-sysadmin@, perhaps he can add it back or give you a shell. <Bryophyllum>terpri_ & nckx: Thanks for your suggestions, though, I'm afraid that programming low-level system components is out of my league. Having used Linux for a while, I grew used to compromising and giving up on things that would require a lot of work <pkill9>mnt reform does look cool, too costly tho :( <terpri_>yeah, i couldn't afford it during the crowdfunding period. maybe it'll get cheaper if they start mass producing them <terpri_>also no setup to help distro porters yet, i asked the organizer <jackhill>terpri_: I beleive that dustyweb is interested in Reform as well, and I'm getting one, so they'll be at least a few Guix folk. <hendursaga>Anyone use Guix to setup any OpenStreetMap servers/services before?