IRC channel logs


back to list of logs

<lfam>over7head: It's not exactly authoritative but Debian distributes the RTL8188EE firmware as 'nonfree'. If so, it won't work with Guix's linux-libre kernel
<pkill9>over7head: you can test it by running the distro from a USB drive (like if you were going to install it) and running the network commands from the installation guide:
<over7head>can linux-firmware be installed on guix?
<over7head>maybe i can build my vanilla kernel there but i still need firmware for wifi
<rvgn>@over7head Just in case if your wifi did not work, you can by this:
<ngz>Ah well. It took me hours to discover recursive? parameter for git-fetch...
***catonano_ is now known as catonano
***atw` is now known as atw
***rvgn is now known as Guest54261
***rvgn2 is now known as rvgn
<rvgn>Hi Guix!
<rvgn>What is the syntax of the command to make certain directories available in the search path set by the XDG_DATA_DIRS environment variable??
<rvgn>What is the syntax of the command to make certain directories available in the search path set by the XDG_DATA_DIRS environment variable??
<roptat>hi guix!
<shift->hi roptat!
<allana>Hi guix. Python developers: when managing local development environments for Python 2 and Python 3, do you prefer using guix profiles or environments? something else?
<ngz>Hello. I have a package, retrieved with git-fetch, with a directory that is a submodule, needed at build time. I thought recursive? parameter from git-fetch would also get the subdirectory, but this isn't the case, AFAICT. What can I do? Package the subdir in another variable, add it as a native input to the main package, and copy recursively the contents of the input at the correct location in a new phase?
<ng0>is there a way to trigger user-creation? all that's missing is $HOME of the user because /home gets mounted late (this is an xfs disk, have my own mount service)
<ng0>otherwise I know I have to copy in all the skeleton
<notnotdan[m]>Hm, I am trying to write a package description. If I do `guix build <pkgname>` then it downloads some pre-built inputs and starts building the package. But if I run `guix environment <pkgname>` guix starts building the inputs from source.
<notnotdan[m]>What could be the reason for this behavior?
<notnotdan[m]>Or maybe `guix environment` is not something I should be using for developing a package?
<roptat>guix environment gives you an environment with the inputs of the package, not the package itself, maybe you wanted to run "guix environment --ad-hoc <pkgname>"?
<rekado>“guix environment foo” builds the environment for “foo”. The things it needs to build in that case shouldn’t differ much from what is built with “guix build foo”.
<roptat>also, maybe some inputs are actually required for an environment but are not inputs for the package, if there is some hook that needs to be built for instance
<rekado>notnotdan[m]: can you be more specific about the actual derivations that are built in one case but not the other?
<roptat>and maybe it's grafting stuff?
<roptat>but in that case it would tell you grafting... instead of building...
<ngz>It seems that "recursive?" argument used in conjunction with git-fetch doesn't do what I think it would do, i.e., also populate subdirs from submodules.
<notnotdan[m]>rekado: sorry i am just not very familiar with the whole process. for example, in case of `guix build` it downloads the gtk+ package, whereas if i do `guix environment` it tries to build gtk+ from source
<notnotdan[m]>this is for the coq package btw
<notnotdan[m]>just seemed a bit weird to me
<hulten>Could someone remind me what to do to clean up unused packages from the Store?
<Sleep_Walker>`guix gc` - garbage collect
<hulten>Yes, thanks Sleep_Walker!
<ng0>is there a resource size when building guile slows down because the server became a bottleneck?
<ng0>like right now it's running for a long time already with 96 cores
<ng0>ram usage 8.86gb and growing
***Piece_Maker is now known as Acou_Bass
***nalkri` is now known as nalkri
<rekado>notnotdan[m]: yeah, this doesn’t seem right. Could you show us the full output please? Guix usually says what derivations it will build.
<g_bor>hello guix!
<g_bor>I've updated libedit, but I want to build the dependents before pushing.
<pkill9>hey g_bor
<g_bor>This is now in progress, looks good so far.
<jackhill>Hi, I'm trying to package a Guile script I wrote <> in a Guix channel for local use <>.
<g_bor>hey pkill9
<jackhill>For better or worse, it is using autotools currently, but the autotool stuff needs to be generated before it is bootstrapped. I tried to add a phase before bootstrap in my package definition (see endpoint-management.scm), but that fails with a permissions error: "In procedure mkdir: Permission denied
<jackhill>Pointers would be appreciated. I'm not tied to using autotools if there is a better way, but I would like to understand what I've done wrong reguardless :)
<rekado>jackhill: you need to make the source directory writeable.
<rekado>jackhill: that’s a side-effect of using git-fetch.
<rekado>you can use (for-each make-file-writable (find-files ".")) or similar.
<jackhill>rekado: thanks!
<rekado>(BTW: there’s an extra “is” on line 48)
<jackhill>good catch ☺
<rekado>is this going to be a tool for cluster admins to keep an overview on what users have installed?
<ngz>It seems that "recursive?" argument used in conjunction with git-fetch doesn't do what I think it would do, i.e., also populate subdirs from submodules. Am I using it wrong or misunderstanding it?
<jackhill>rekado: sort of. This is for reporting the the security office thread that I started on the mailing list a number of weeks ago.
<_tibbe>Hi! I have a problem with patching something: I defined a function in (guix build utils) and it uses mkdtemp! (guix build syscalls). But I cannot use it in a phase of a package definition because it cannot resolve mkdtemp!. Does anyone have a clue what the problem is?
<bavier>hello guix
<pkill9>hi bavier
<roptat>_tibbe, it's because of code staging: inside the builder the required module is not loaded
<roptat>so you have to (use-modules (guix build utils)) inside the builder
<roptat>but that won't work because the module is not available (imported) so there's something else you need to import the module, but I need to read the manual to tell you what :p
<roptat>I can't find it, I think it's an argument, like #:imported-modules or something
<roptat>ah yes, see the definition for sonata (guix edit sonata)
<roptat>_tibbe, ^
<rekado>I’m trying to use a bluetooth audio dongle on a headless system. I can’t connect to the remote bluetooth device via bluetoothctl, so I tried starting pulseaudio first.
<rekado>pulseaudio doesn’t want to start because it fails to launch a “dbus-daemon without a $DISPLAY for X11”.
<rekado>is there a way to use it without a graphical session?
<apteryx>rekado: the bluetooth pairing went OK?
<apteryx>this might be useful:
<rekado>yes, pairing is fine.
<rekado>it works all fine on my laptop where I do use a graphical user interface.
<apteryx>seems it'd deserve a bug ticket upstream
<apteryx>a sound server shouldn't require a full X session to start
<g_bor>hello guix!
<g_bor>I've had the luck to update a package with a few dependents, and I am right now watching the berlin web interface to see what is happening.
<g_bor>I've seen that a hpcguix-web test fails, with an error in the log like connect: no such file or directory.
<g_bor>Is this a normal thing? It seems to fail consistenty.
<g_bor>hi vagrantc!
<vagrantc>g_bor: hi!
<g_bor>ledger seem to fail in an iteresting way on armhf-linux...
<g_bor>It gets a c++ compiler internal error. Do we know anything about that?
<efraim>Error 9 or something else
<efraim>could the ledger failure be related to libedit?
<g_bor>Hello efraim!
<efraim>hello g_bor!
<g_bor>I don't know. That's one thing I am trying to find out.
<g_bor>Do we know and evaluation number where ledger was built?
<g_bor>Currently the berlin we interface is not very friendly in this regard...
<efraim>looks like beignet is x86+ only
<efraim>c++: internal compiler error: Killed (program cc1plus)
<efraim>not error 9, but I'm still guessing OOM
<g_bor>The beignet log clearly points to a dependency like failure, that's why I did not raise it. But the ledger one is suspicious...
<g_bor>Yes, that is the row that caught my attention...
<efraim>I'm at 52% locally building armhf on aarch64
<efraim>i'll let it keep on building but i'm not expecting any problems
<g_bor>efraim: can I help somehow? Do I have anything to do regarding that? (Besides improving the web interface...)
<wednesday>Hey, so when I boot up the guixsd iso on a usb stick I end up getting a lot of "waiting for partition 31393730-3031-3031-3139-313631383738 to appear" until it gives up saying failed to resolve. The only disk in the machine should be a blank btrfs. When it fails to resolve I get slapped into a guile repl with no working keyboard, so I don't know wha
<wednesday>t to do next.
<wednesday>I see stuff like "device not accepting address 9, error -32" and "unable to enumerate USB device" which seem like they probably relate to the keyboard issue
<quiliro>hello pals
<quiliro>thank you for working for freedom
<quiliro>i am using gnome now
<quiliro>when showing the image of the current keyboard distribution, I get an error failed execution of gkbd-keyboard-display. command not found
<quiliro>what package am i supposed to install for this to work?
<wednesday>OK so, the reason for my keyboard not working and the partition error was the iso on the usb for some reason not liking my usb2 ports, and only letting my usb3 ports work. Is this a known thing with the ISO and will that carry over when I install(not having usb2 support)?
<apteryx>wednesday: maybe check the kernel messages under /var/log/messages for hints
<apteryx>the kernel of the liveUSB is the same as for a normal Guix system (linux-libre), so yes, it's likely you'd run into the same problem after installin.g
<apteryx>s/liveUSB/iso image/
<wednesday>apteryx: well I see these 2 messages "usb 4-2: new full-speed USB device number 9 using ohci-pci" then "usb 4-2: device not accepting address 9, error -32", other than that it seems to be fine
<wednesday>I think I remember before on an old install of another OS I was using I think I might have had to use ehci or maybe xhci for usb 2, would you be able to do that in guixsd without having to do my own kernel?
<apteryx>wednesday: OK! Are these extra kernel modules to load (ehci/xhci)? If so, yes, I believe you should be able to do that in the operating system definition.
<wednesday>well xhci is the kernel subsystem for handling usb 3, and I believe can also deal with 2>, and ehci if another kernel subsystem for usb 2> and so is ohci, which is the one that's not working for me
<wednesday>at least that's my understanding of the whole mess of usb support
<wednesday>and also now I can see that my internet wont work, it's wired but ifconfig says something about a firmware patch being deblobbed, I swear I used a deblobbed kernel on gentoo ages ago but that might have been on another motherboard
<quiliro>what fonts are necessary to install to see all web page characters correctly on epiphany?
<wednesday>so I do have internet, but I'm still going to have to figure out that usb 2 issue, I may have to end up making a custom kernel for that unfortunately
<rekado>wednesday: why a custom kernel for this? Can this not be achieved with blacklisting of the unwanted module?
<wednesday>rekado: No idea, thats w
<wednesday>that's why I'm here heh, I don't know what I should do, I can get you my /var/log/messages so you can try see whats going on with the usb 2 if you want
<rekado>I probably won’t be of much help. I’m just thinking that building a custom kernel is only necessary if you’re missing modules or features are missing from the kernel configuration.
<wednesday>well my assumption is that they haven't built the other usb systems as modules, since xhci and ohci should be good for most people, but I don't know heh
<ngz>When I clone a repository and use git submodule update --init --recursive, git pulls data from the submodule. If I define a package with git-fetch and recursive? #t, it doesn't. I don't understand why.
<apteryx>ngz: according to the info manual, it should fetch the submodules, so maybe it is a bug.
<dongcarl>Any updates on getting guix into official repos for debian?
<rekado>ngz: does git clone --recursive work for this repository?
<ngz>rekado: Let me check
<wednesday>rekado, apteryx: here is my /var/log/messages if you want to see at the bottom I replug my keyboard into a usb 2 slot so you can see what errors it gives.
<vagrantc>dongcarl: i haven't put any time into it recently
<rekado>ngz: (guix build git) defines git-fetch, and it does handle submodules.
<ngz>rekado: the command seems to resolve submodules, too.
<vagrantc>dongcarl: going to have to be after the debian freeze is over, most likely
<rekado>ngz: are you prehaps testing this with an existing hash for a different checkout?
<vagrantc>dongcarl: my current plan is to first implement an installer that just downloads the guix binaries, so it wouldn't go into contrib
<ngz>rekado: It should. But it doesn't in my case... Could it be related to some data lingering around in the store
<vagrantc>dongcarl: er, would have to go into contrib
<vagrantc>dongcarl: actually, downloader-installers can go in main, i forgot
<ngz>rekado: How can I ignore any previous cloning from the repository?
<vagrantc>dongcarl: it's on my back burner, but keeps getting pushed back further
<apteryx>wednesday: you could verify your assumption by inspecting the .config file at the root of the Guix linux-libre package.
<rekado>ngz: you don’t. You just shouldn’t use the hash of that previously cloned repository.
<apteryx>to see what is the currently used configuration for the kernel
<dongcarl>vagrantc: Huh... I feel like as a stop-gap, a guix PPA would work fine (and would convince a lot of my colleagues to try guix out at least)
<ngz>Ok, so I invent a wrong hash and let the build process yell at me.
<apteryx>dongcarl: teh install script is handy too
<wednesday>apteryx: do you happen to know where that would be?
<vagrantc>dongcarl: there are some build-dependencies missing from debian, which is why i'd suggest first implementing something that downloads, installs, and configures the guix binary distribution
<apteryx>on a guix system, you'd do `guix build linux-libre`, and it would print the path from the store
<dongcarl>vagrantc: Ah that makes sense. Perhaps I'll just point them to the install script that apteryx mentioned
<wednesday>apteryx: thanks, from what I see it's got all 3 usb systems built straight in, not as modules, and I think I need to get rid of ohci so that ehci can take over for my usb 2
<dongcarl>Somehow people are more comfortable with PPAs than `curl | sh`, dispite them not being too dissimilar
<apteryx>wednesday: or, guix gc -R /var/guix/profiles/system | grep linux-libre
<dongcarl>vagrantc: Perhaps I'm misunderstanding, but can't debian packages specify build dependencies?
<dongcarl>vagrantc: I guess I'm asking why an installer is needed instead of an actual installation
<ngz>rekado: OK. That seems to be it. It didn't bother cloning again the repository because my hash was already matching an old clone.
<vagrantc>dongcarl: you can specify build dependencies, of course. but you have to get those packaged in debian as their own project first
<vagrantc>one of the things i *love* about working with guix
<wednesday>apteryx: well that command give me an error on the usb, was that meant to do the same as the first command?
<vagrantc>you can just start packaging your dependency chain all locally and then submit a patch series
<dongcarl>vagrantc: which ones aren't packaged in debian yet?
*dongcarl is a curious person
<vagrantc>dongcarl: mentioned in some guile ones, if i recall
<vagrantc>dongcarl: i think maybe one more has been added since... looks like guile-git and guile-ssh
<apteryx>wednesday: yes, I read your reply a bit late :-) it's just a 2nd way to get the Guix store location of your linux-libre kernel.
<dongcarl>vagrantc: Ah... I see what you mean...
<vagrantc>dongcarl: fwiw, nix has been uploaded, which has an ... interesting solution to the FHS issue. hasn't yet been accepted into debian though
<wednesday>i wonder what I can do to fix this problem
<wednesday>from what I can see it's not even pushing power through the usb 2 ports ha
<dongcarl>vagrantc: uploaded to where?
<vagrantc>dongcarl: uploaded to debian, but stuck in new for review:
<apteryx>wednesday: it seems you could live test disabling the ehci_hcd module as suggested here:
<dongcarl>vagrantc: FHS = file hierarchy structure?
<jackhill>Is the best option for wrapping guile programs (so that they can find their modules) "manually" like in the haunt package?
<vagrantc>dongcarl: filesystem hierarchy standard ... e.g. directories in the top-level ... e.g. /nix or /gnu
<jackhill>I guess we don't have too many guile executables yet
<harding>vagrantc: it looks like it just uses /nix, as expected. The pacakage description links to a discussion on the debian-devel mailing list where there's general consensus for them having an exception.
<vagrantc>harding: but it creates the directories with a systemd tempfiles mechanism
<harding>vagrantc: oh, indeed. That is weird. The install script should be about to mkdir -p the required directories.
<vagrantc>harding: like i said, a curious workaround to remain FHS compliant
<wednesday>apteryx: I just gave that a go for both ohci, and ehci dirs, but either way it seems usb 2 devices dont want to work
<wednesday>I got no idea what to look at next
<wednesday> I'll try what this guy says but doubt that will do anything in my case
<apteryx>wednesday: oh, so maybe just too high of a current draw
<apteryx>that'd be an easy fix ;-)
<wednesday>well i left the pc off while i made coffee, turned it back on, plugged in my phone, and get the same errors instead of it just charging, so the ports still wont do nothing
<wednesday>and i know they worked earlier today, ha
<wednesday>100% they still work, because i had the issue a few days ago when I booted the usb, but it was fine on the os I had
<wednesday>so now i'm more stuck
<wednesday>I havent been on linux in about a year, been on the bsds, but I doubt during my year hiatus they somehow broke support for my usb ports ha
<wednesday>maybe what this guy is saying applys to me but I don't think I could apply that to the liveusb
<wednesday>well I found another thing that tells me to enable IOMMU in the bios, but that causes the usb not to boot with the same "waiting for partition to appear" error I get when I plug the liveusb in a usb 2 port, even thuogh it's in a usb3 one
<wednesday>OK another revelation, enabling IOMMU in the bios switches things about, the usb 2 ports all now work fine, but the usb 3 ports are not working, things are getting weird apteryx
<ngz>While trying to update a package, I got a strange translation error ( I am puzzled. I'd appreciate some guidance.
<g_bor>ngz: istm it fails on a permission error. I guess you can simply make-file-writeable the file in a phase, unless it is generated.
<g_bor>if it is a directory, then you can chmod it...
<ngz>What file would it be?
<wednesday>I guess might be my final solution, but I'll have to finish up the install and find out
<ngz>generic/po/generic.pot is a relative file name
<ngz>Hmmm. I found one "generic.pot". It is read-only, as every .po file.