<nckx>xavierm02: Those are 2 source derivations, by the way. Can't say what they are since the way we build kernels was recently changed (we perform the deblobbing ourselves now). What you see is probably related.
<xavierm02>You mean it's not really linux-libre anymore, it's linux minus stuff guix removes?
<lukas4456>luckily i live at a place where i get help with my depression
<nckx>I mean, honestly, the fact that I *don't* own a phone is an luxury I can afford because I'm *not* poor. I have the luxury to tell anyone (boss, government agency, …) demanding I be ‘reachable’ to go fuck themselves and have. Poor people have no such power.
<lfam>Remember to not let this turn into a flame war
<nckx>[rg]: No, not when building software with Guix. Integrating it would be complicated & error-prone, and ccache is great software but never 100% reliable (I say this from experience). It's unlikely to ever be supported.
<Guest65>Hello, I am planning on building a pc soon. I was researching which OS to run on my new pc when I found out about Guix system.
<apteryx>Guest65: it seems your search was fruitful ;-)
<Guest65>I would like to install Guix system but I am worried about hardware compatibility. I found that Guix system ships with the linux libre kernel, and my google searches have yielded curious results.
<apteryx>Guest65: it is, although you'll have to find support for this outside of the official Guix channels, as Guix is strictly about free software.
<nckx>Guest65: Guix doesn't restrict your freedom to run non-free software (although I honestly don't know of a preexisting linux-nonfree package or how much work it would be to configure), but we can't provide support for it through official Guix channels.
<apteryx>weird. Maybe it's time for me to pull and retry.
<Guest65>thank you for the responses. i would like to use free software as much as possible, but i was not able to determine with certainty whether the hardware i will be purchasing relies on proprietary software.
<apteryx>Guest65: if you *will* be purchasing hardware, now is a good time to research it so that it runs free software :-)
<davexunit>it's easy to mess up. I've done that more than once.
<Guest65>the guix manual indicated that wireless network cards are troublesome. but some other sources made me think that there could be many other conflicts besides networking cards.
<nckx>davexunit: Buying hardware or setting timezones?
<apteryx>laptops usual problem is the wifi chipset, which more often than not relies on a binary blob to work.
<davexunit>read a ton about free drivers on new AMD GPUs, bought one, and then discovered that yes, the drivers are free, but they require the kernel to load a firmware blob before the drivers can work.
<apteryx>nckx: yes, I've bought a R9 285, after buying into the "free software drivers", only to find out it wouldn't work *at all* without a binary blob... No thank you, AMD. A 125 kloc driver which does nothing without a blob? Hard to believe.
<davexunit>for some reason none of the docs I read prior to purchase mentioned that.
<nckx>Guest65: Nope, it's a pretty aggressive propaganda campaign though so I can't blame you. The drivers are ‘free’ they also hard-depend on binary blobs to do anything.
<vagrantc>just being four timezones further east, i see so much more activity in #guix
<Guest65>a lot of the information out there about hardware compatibility seems to be at least a little dated. so there isn't an easy list for me to check off. especially when all the hardware i expect to buy is pretty new.
<Guest65>but based on your answers i feel the graphics card and the wifi card would be most likely to cause issues.
<vagrantc>hardware options are definitely limited a bit
<OriansJ>The limitation is to the hardware that have Libre drivers
<Guest65>OriansJ what do you mean? do you mean that hardware with Libre drivers are less effective?
<OriansJ>Guest65: as in The Linux kernel that guix uses does not have any binary blobs and thus the hardware it supports is a subset of all hardware supported by Linux
<OriansJ>Now the hardware that it does support has world class drivers but that was an explicit decision made to ensure no blobs
<Guest65>do you have any hardware recommendations OriansJ
<OriansJ>Guest65: depends entirely on what your goals are; some people prefer RYF cerfitied hardware and other people prefer having a newer machine with better performance
<Guest65>i looked at the list of RYF certified hardware and it seemed to be very limited and didn't even include all the necessary components to build a pc.
<Guest65>i would like to have hardware with modern performance
<OriansJ>Guest65: well, that is more of a problem of manufactors choosing not to pursue the certification. and as you are more concerned about modern performance purism or system76 systems would probably be a better match for you
<OriansJ>remember for some people, it is a better match to install ARCH/debian/Centos on their system and then install guix as a supplimentary package manager to deal with their day to day application needs
<Guest65>i am set on using guix system! in the worst case, i would prefer to just install the proprietary drivers. is that a terribly difficult thing to do?
<OriansJ>Guest65: assuming you can follow directions and take responsibility for auditing the imported package definition; then it is relatively simple
<Guest65>glad to hear that. thank you for the information.
<bavier`>has anyone had trouble with our ungoogled-chromium not allowing microphone permissions for websites?
<Gamayun>Lukas4452: Yeah, I think that would be sensible too - at least to introduce it to people upfront. You could always switch to another virtual console to correct the config, though I don't know where the installer might write. Although if you've already run 'guix system init' I guess it'll be put in /etc/config.scm.
<roptat>criticalcat, you probably have a message that gives you a log file name (it should be in red iirc)
<roptat>yeah, the actual issue is probably just a few lines above that
<roptat>indeed, it's notclear what happened from the log
<runejuhl>I'm trying to update an old guix system, and it consistently fails on compiling curl 7.65.0, but where it fails changes from run to run; so far it's failed at curl unit tests 1551, 2051 and 2052. Has anyone seen that behavior before?
*davexunit may have found a bug in cross-compilation logic related to propagated inputs
<runejuhl>These are the versions: failed to compute the derivation for Guix (version: "e7dfbae8a99995abc9f088452ca35371d38eb343"; system: "x86_64-linux"; host version: "71b4974a40347bdc651c3a1f923780733d96ded7"; pull-version: 1).
<davexunit>I have a package that propagates a dependency. that dependency varies its inputs based on the target system triplet. however, when transforming a package to a derivation, the transitive-inputs procedure calls package-propagated-inputs without first setting %current-target-system appropriately.
<davexunit>and thus my build fails because it tries to build something that is incompatible with the target system.
<davexunit>I believe this is a bug, but honestly I'm surprised it went under the radar this long so maybe it is expected behavior? if so it's *very* confusing behavior.
<rekado_>davexunit: cross-compilation isn’t done much. Not on the build farm, and many build systems don’t have cross-build support, so it’s not that surprising that it might be buggy.
<davexunit>it seems to be *only* propagated inputs that have this issue
<davexunit>I've put in a lot of debugging print calls to trace what is going on
<efraim>Jan got lilypond to cross compile to mingw but I feel it's mostly been used for bootstrapping
<davexunit>in order to reveal the bug, you need to build a package that depends on a package with propagated inputs that vary depending on the target system. I imagine few packages do this. :)
<davexunit>however, sdl-mixer does, for example. it depends on sdl, which propagates libx11, libcap, and mesa.
<davexunit>when building for mingw, those dependencies must be removed.
<criticalcat>Should I be doing "sudo guix..."? I think that's maybe a habit from yum/apt tools.
<roptat>criticalcat, that shouldn't change anything
<mbakke>rekado_: how is the wip-texlive branch doing? can it be merged?
<jfred>Hey - so it looks like running "guix system init" doesn't populate /etc/passwd and /etc/shadow in the generated FS tree, at least for the root user. Maybe that happens on first boot? If so, is there an easy way to trigger that prior to the first boot? I haven't been able to track down where that logic is in the guix source yet
<Marlin1113>do i just write the name? or something like (package "packagename")?
<roptat>alternatively, if you defined the file as a guile module, put it in a directory that reflects the module name (my module my-package) must be in my/module/my-package.scm and use -L <directory where "my" is in>
<roptat>just the name, since it's a variable bound to the package definition
<xavierm02>What do search-path and native-search-paths do exactly?
<xavierm02>"A list of search-path-specification objects describing search-path environment variables honored by the package. "
<roptat>xavierm02, the idea is that if you have that package in a profile, and other packages (or itself) that contain the specified path, then etc/profile will define the variable
<nckx>xavierm02: Search paths are environment variables like TERMINFO_DIRS, XCURSOR_PATH, TUXPAINT_STAMPS_PATH.
<roptat>like, the guile package defines the GUILE_LOAD_PATH variable to be lib/guile something, so if you install guile and any package that contain this path, GUILE_LOAD_PATH will be defined in that profile
<xavierm02>Ok. My exact question is: Why does qt have search-paths and qtsvg does not?
<xavierm02>Ok so. If qt has a search path QT_PLUGIN_PATH defined to lib/qt5/plugins, and qtsvg writes stuff in lib/qt5/plugins, and LyX works if you wrap to set QT_PLUGIN_PATH to be the /lib/qt5/plugins/ of qtsvg, LyX should also work not wrapped, no?
<nckx>(‘But $prefix/var basically never makes sense in Guix's case’ — absolutely, but that's the convention.)
<roptat>rekado_, so, in (guix profiles), in package->manifest-entry, instead of using package-transitive-native-search-paths, use something that does the same, but with any input, and not just propagated ones. Would that work?
<xavierm02>nckx: I did read it. I was just saying that the shell commands you provided showed that the same history file was used inside and outside guix env. I already knew how to share history between all terminals but it'd break the "Up arrow + enter" workflow.
<xavierm02>I would've liked history to only be shared inside the terminal. I guess it'd be posisble by naming the history file in a way that depends on the terminal instance but that'd require some tinkering
<weedloser>>my computer is making random noises > ican't turn it off
<nckx>Also, why does disabling audio make your computer make more noise.
<nckx>Lukas4453: Absolutely nothing special or unusual.
<nckx>Guix just uses ALSA + PulseAudio like ‘everyone’ else these days.
<nckx>xavierm02: So what you want is <type foo> <run guix env> <tybe bar> <exit env> <UP> <see bar appear>, right?
<nckx>One way I could see that work is making guix a shell function that calls ‘command guix "$@"’, then does the ‘history -a/-r’ dance.
<nckx>That will allow you to keep one history file, but I'm sure there will always be ways to accidentally ‘cross-contaminate’ sessions if you're mixing different guix environment calls in different terminals.
<Lukas4453>I tried to reconfigure for fun, now I can't build hash-system.drv
<nckx>Could you paste as much output as possible to paste.debian.net?
<raingloom>is something wrong with git-minimal? i'm getting a checksum error....
<rekado_>raingloom: “hash mismatch for store item '/gnu/store/pn8l10w9hjmglag2z72bawfj8m6ccwrq-git-checkout” is not a message about git.
<rekado_>it’s a message about something that was fetched with git.
<raingloom>rekado_, the previous message was about it downloading "git-minimal", hence my confusion
<raingloom>rekado_, not sure what's mismatching then, but i'll do a triple check
<nckx>raingloom: Could it be just your custom idris package?
<raingloom>nckx, no, that installed fine, but it might be the Idris2 package
<nckx>I can't get Guix to report any mismatches when building upstream idris.
<nckx>Maybe I'm substituting something but I don't think so.
<rekado_>raingloom: that’s why we use (file-name (git-file-name name version)) when using git-fetch.
<raingloom>nckx, yeah, Idris 1.3.1 is fine, I patched it 1.3.2 (for which I'll send a patch... soon? tonight?) and that installed fine on both machines, and now I'm trying to use Idris 1 to build Idris 2, which is a different thing
<rekado_>if it isn’t used “git-checkout” will be the source name.
*nckx AFK, I wish everyone well with their outstanding problems, but I don't actually have time to IRC and it really shows.
<raingloom>rekado_, where would that be used? in the package description? I just used the usual origin template from the tutorial