<phireh>Hi there, I have some questions about libraries on the Guix System (just installed it on my laptop) <nckx>phireh: Welcome! And shoot. You might get an answer here. Otherwise, help-guix at gnu.org is a good place to mail. <phireh>I'm trying to get a hobby project I'm doing to compile (it needs libX11). No problem installing it, but since <phireh>Guix does not put it in /usr/include/ or any other well-known place, I can't compile it <phireh>Is there a way to get library files for developers (I'm thinking sdl2, libFLAC, etc) in a place where the compiler can find it? <roptat>phireh, I think you need to set $LIBRARY_PATH, but guix should do it for you if you have glibc in the same profile ***nckx is now known as jorts
<roptat>you mean guix didn't set it, or your project explicitely unsets it? <phireh>It didn't set it. Glibc is not installed in this profile either <roptat>phireh, so after you install glibc, guix should set it, but I think you'll need to reload the environment (open another terminal our source <the profile>/etc/profile) <lle-bout`>raghavgururajan: it's my laptop it's normal but you can disable this by now, the offload server you've got will give you substitutes from me as well already ***lle-bout` is now known as lle-bout
<lle-bout>raghavgururajan: I'm in some kind of chill party with WiFi at the other side of the building now so, it's normal it's slow <phireh>roptat: It worked, thank you very much =)! <link2xt>is there any way to run services on foreign distro? <link2xt>I compiled jami on debian via guix for whatever reason, it says that "dring" is not running <pkill9>link2xt: maybe you could run a system in a container <link2xt>but I have systemctl here, not shepherd <pkill9>the dring issue is, i think, because it's not in the $PATH, and it's in libexec <link2xt>I don't see it at all in my .guix-profile <link2xt>only .guix-profile/share/man/man1/dring.1.gz and .guix-profile/include/dring <lle-bout>raghavgururajan: basically I set up local substitution from the physical host within the VM <lle-bout>and my offload server is the physical host <lle-bout>So if I build anything, it gets on the physical host's store, and you get it too <link2xt>pkill9: running it manually solved the issue <link2xt>so a workaround is probably to write a systemd unit :/ <link2xt>but in general shepherd services are not supported on foreign distros, right? <pkill9>i think guix system does the same thing of not finding dring <pkill9>yea they are, it's just that guix services rely on building a guix system <pkill9>you have guix services (i.e. what you put in your config.scm) and shepherd services, which are usually generated by guix services <pkill9>but you can run shepherd like any other program <pkill9>by default it runs services written in ~/.config/shepherd/init.scm <pkill9>you can run shepherd as pid1, also as a user <lfam>vagrantc: There should be a substitute available for that grub-efi derivation now <sneek>lfam, vagrantc says: well, this time grub-efi (and presumably qemu-minimal) successfully built for me on aarch64 <lfam>'/gnu/store/na3311bmikbqdhch5p3z8a3pz2l3m9di-grub-efi-2.04.drv' <mekeor[m]>would it be possible to change guix in such a way that it installs packages as images instead of archives, just like the distri package manager? <lfam>mekeor[m]: From my point of view, Guix installs packages as files, which are then symlinked into place <lfam>There is an archive format used to deliver the files over the network <vagrantc>so, i'm on the verge of trying guix system on this machine, then ... <lfam>mekeor[m]: But I think I misunderstand your goals, which are surely interesting :) <mekeor[m]>lfam: thats right. package installation would be much faster if we'd download packages as images and mount those images <vagrantc>is it plausible to install guix system rootfs on lvm? <lfam>What about it would be faster, mekeor[m]? <lfam>vagrantc: Guix System can mount LVM things now, but I don't think they can be created declaratively yet <mekeor[m]>lfam: one heavy reason for package installation to take so long is that extracting archives takes so long because creating files in a file system takes so long, compared to mounting an image <lfam>This was added since Guix 1.2.0, vagrantc <jorts>mekeor[m]: Wouldn't that be slower? You'd have to mount easily hundreds of images at every boot. <lfam>You profiled it mekeor[m]? <jorts>mekeor[m]: Do you have numbers for that? <jorts>mekeor[m]: Do you have a specific file system in mind (for the images, I mean)? <lfam>Anyways, it's a really interesting idea! <vagrantc>lfam: ... oh ... but does that mean i can't use them for rootfs? <lfam>This is probably not the best time of day (or day of the week) to present it, though. I think many of the people that are familiar with this level of Guix aren't around <lfam>vagrantc: I think that you can. What I mean is that you have to create the logical volumes, the volume groups, register the physical volumes, etc, on your own. Imperatively. But then you can use them in config.scm <jorts>mekeor[m]: I don't doubt that, but video is too inefficient to consider. <lfam>You can't create new logical volumes or configure LVM from config.scm yet. *If I understand correctly* <mekeor[m]>the other link is a quick intro into distri which beats apt and similar package managers by an order of magnitude in package installation time <lfam>mekeor[m]: One of the main Guix developers watched that talk and has been landing some improvements based on it, actually <lfam>There is still room for improvment, obviously. Guix is probably the slowest package manager <mekeor[m]>yes i stumbled upon the talk because its linked in the guix blog <lfam>Something I'd really like is to speed up or somehow memoize the compute-guix-derivation step of `guix pull` <lfam>mekeor[m]: Ah, great :) That person is called 'civodul' here, btw. In case you didn't know <lfam>Okay :) Sorry to act like you don't know anything... <mekeor[m]>but yeah i wonder why the packages-as-images idea wouldnt be implementable for guix as well <lfam>I used to be able to keep track of pretty much everybody, but now Guix is too big :) <lfam>I think it's probably a case of "Wow, big change!". But Guix is no stranger to that kind of thing <lfam>Plus, big changes help us argue against the "It's just a fork of Nix" criticism, which is always nice <mekeor[m]>imagine guix to be one of the fastest package manager uuuuhhhh <jorts>I think it would be a *relatively* easy transition for Guix compared to almost any other PM. <mekeor[m]><jorts "I think it would be a *relativel"> exactly <jorts>I'm just not as optimistic about unpacking being a significant bottleneck. Which is why numbers would be vital. <jorts>None of the painfully slow parts of Guix are addressed by mounting packages: compiling Guile modules on Guix pull, rebuilding the manual database, … <jorts>We'd be replacing one of the cheapest operations (throwing some bits at the disc) with one with different trade-offs (do more work at [every!] boot & during run time). <mekeor[m]>i do think that throwing bits at the disc is generally quite a bottleneck but i guess guix has multiple of those :D <jorts>Actually, I take even that back. <jorts>‘This means that even for large dependency trees, setting up a build environment happens in a fraction of a second!’ -- I want this! <mekeor[m]>jorts: what is being postponed? the mounting of the image? <mekeor[m]>maybe we should file a ticket for this idea, huh? <jorts>That, and decompression, and the fact that unpacking is extremely fast if you don't do anything interesting like deduplication. <jorts>mekeor[m]: There isn't one yet? I'm surprised. <mekeor[m]>what is oldish? distri? the packages-as-images idea? <mekeor[m]>if you know of a ticket, let me know. i might be just failing at querying the right keywords <mekeor[m]>jorts: i don't know the implementation details. but i'd rather guess that distri does decompress during installation <jorts>I meant the idea of mounting packages as virtual file systems. I think it's as old as Nix :) <jorts>mekeor[m]: The whole point of distri is that it doesn't decompress during installation, that's why it's ‘fast’. <vagrantc>oh, this could have been my chance to try btrfs <mekeor[m]>jorts: where does nix mount packages as VFSs? <mekeor[m]>jorts: ah right. – but maybe the speed advantage would remain if you'd only have one file to decompress – namely the image – and not dozens of files (which you'd have to create each on the file system) <jorts>mekeor[m]: Guix deduplicates identical files. It saves quite a bit of space, but is also slow (it's most of the ‘unpacking time’, I'm sure). You can disable it to use significantly more space to save some time installing packages. <mekeor[m]>jorts: okay, i didn't know about the idea before i saw it implemented in distri <jorts>But you only create them once, vs. decompressing them every time... who knows? I don't. The only answer is in hard data ☺ <jorts>Feel free to start an issue thread, and hopefully find fellow volunteers to implement a PoC to demonstrate clear wins. <jorts>I don't find any issues about it either. I'm a bit surprised. <jorts>Maybe guix-devel@, which might be better for discussion anyway. ***jorts is now known as nckx
<phireh>Hi back, is there a way to edit files in /etc/bluetooth? It points to a static filesystem <nckx>mekeor[m]: I can't find any results either. <lle-bout>nckx: hello! do you happen to be able to run 'make check-system' on your GNU Guix git clone? <nckx>I'll check, but then I really need to zzz. <nckx>While I try: what fails? <nefix>Contributing to Guix is kinda complicated :S <nefix>I'd love to have a place to "drop" my derivations and share them with everyone <nckx>nefix: What could improve nefix? <raingloom><grumble>goddammit i'm trying to package rust-parinfer and the specific bindgen version it indirectly depends on isn't one of the ~10 packaged ones so i tried patching the dependency to use a packaged one and now it won't accept it, even though the version string matches. cargo-build-system feels like a sick joke.</grumble> <nckx>nefix: What would such a place look like? <vagrantc>well, no huge surprise, Guix System installation ... gets stuck at a guile prompt in the initramfs <vagrantc>probably missing some modules or something *vagrantc tries linux-libre-arm64-generic <lle-bout>thank you for fixing that last privilege escalation flaw! <pkill9>vagrantc: that is my fear in guix <nckx>lle-bout: Er, it certainly didn't fail that quickly here O_O I'm going to let it run overnight. <nckx>If I don't run out of storage space. It's downloading (a lot) of substitutes. <lle-bout>nckx: do not worry then.. cancel it I think.. <nckx>I need to sleep now or I'll start aimlessly meandering at you like I did at mekeor[m]. Good night Guix. <raingloom>pkill9, vagrantc: that REPL really needs to be improved. very difficult to use without readline and autocomplete. sexps are also not nice to edit without dedicated editor features. <raingloom>i was dropped into it a **lot** while working on f2fs and i have pretty much never got it working in a useful way. <pkill9>idk how i would use it to fix a problem <pkill9>better option is to keep a guix instlal laying on a usb drive <raingloom>> usb drive: or just boot an earlier config, but ye <pkill9>i think that may be what I was thinking of <vagrantc>gah. forgot to set up a serial console ... <phireh>I managed to get the bluetooth working on Guix but it's only working on mono (A2DP sink is unavailable). The solutions posted online involve editing /etc/bluetooth... but it's a read-only filesystem in Guix x.x, has anyone had this problem before? <pkill9>typically you want to run the bluetooth daemon and ppoint to a editable config, and once you got it working add that config to the service <pkill9>as in, run it as a user while getting it working <pkill9>not sure if the bluetooth service lets you give it a raw config <pkill9>maybe it already has configuration ooptions for it <pkill9>in which case often you got to translate web solutions to guix config <phireh>The bluetooth-service does not expose any config that I could find <lle-bout>I use A2DP sink on GNU Guix and it's been working OK out of the box with blueman <lle-bout>What do the solutions suggest? Where is the problem located? <lle-bout>Are you sure it's not because some package in GNU Guix may be outdated and not support some speakers for example? <phireh>Nay, it's just that the pair of speakers I got default to the mono profile. Happens on other distros/Windows too <lle-bout>phireh: I see, do you use Blueman? It's got quite a lot of customization options there maybe you can make it switch away from mono with it. <phireh>They suggest disabling the Headset profile in /etc/bluetooth/main.conf <lle-bout>phireh: can't blueman achieve what you want without modifying bluetooth service config? <phireh>Does not seem like it, "failed to change profile to a2pd_sink" <lle-bout>phireh: one would need to add an extra-config field to the bluetooth service <phireh>I think I might have an idea. Is there a way to kill / delete an input audio device with paudio? <phireh>Oh, bluetooth-configuration-file looks promising <phireh>But can I use it? Or is it something internal? <lle-bout>phireh: not entirely sure but you can redefine the service within your own system configuration and include anything you like there <lle-bout>just copy the definitions to your system config and edit it there <lle-bout>phireh: all the stuff until the colord dbus block thing <vagrantc>ok, booted guix system on an apm mustang :) <vagrantc>been a while since i've started a new system from scratch <lle-bout>phireh: let me know if it works out for you <phireh>lle-bout: Guix system does not seem to like it <phireh>"source expression failed to match any pattern" <lle-bout>phireh: Just FYI, this way of doing works, it's just a matter of finding right syntax, you can always move and redefine GNU Guix bits inside your config to override them and customize. <phireh>Sounds cool, I like hackable things. I'm just very lost 'cause it's literally my first day x3 <phireh>I just did a big fat copypaste of the bluetooth section <lle-bout>phireh: can you also paste the full error message on reconfigure? <phireh>guix system: error: bluetooth-configuration: source expression failed to match any pattern <lle-bout>phireh: probably there you could be missing some use-modules, try to take inspiration from the use-modules at the top of the desktop.scm file and copy some over, there I am thinking you'll need at least (gnu services) and (guix gexp) <pkill9>does anyone use apparmor with guix system? <phireh>lle-bout: I added some of the use-modules that you and guix system suggested and now I have this error <lle-bout>phireh: I need to go AFK now, I believe you'll be able to sort this out, looks like for your first day you already are at ease with using GNU Guix. <phireh>lle-bout: Thanks! And actually, it worked. At least I was able to input a comment so I can start hacking :3 <phireh>lle-bout: Adding MultiProfile=multiple to the [General] option fixed my problem. Maybe it could get added as an option to the bluetooth service? Anyhow thanks again <wdkrnls>Is there a package that gives me libguile.h? <wdkrnls>guile.cpp:4:10: fatal error: libguile.h: No such file or directory <wdkrnls>I've got pkg-config, autoconf, and automake already in there. <apteryx>wdkrnls: according to my store entries that's from guile itself: /gnu/store/0w76khfspfy8qmcpjya41chj3bgfcy0k-guile-3.0.4/include/guile/3.0/libguile.h <apteryx>but yeah libguile is not directly under include so you probably want to get the help of pkg-config to set the include paths correctly <wdkrnls>apteryx: Yeah, that seems to be true. Sadly, I have no idea how to use any of that `pkg-config` magic. <wdkrnls>I saw that in the guile manual for linking with C code. <wdkrnls>So, it looks like I would have to fork the original program (an R package) I was looking to package and modify it to have a decent configuration script for linking it. <wdkrnls>Hehe, I was hoping to use use Guile from R so I could continue being blissfully ignorant of the massive learning curve involved in C++ projects. <apteryx>wdkrnls: guile ships a guile.m4 set of macros that you can include in the project (if it uses autoconf) and use; these macros use pkg-config. <apteryx>Usage: GUILE_PKG([VERSIONS]); then it sets variables such as GUILE_FLAGS, than should include the correct -I directives <wdkrnls>That sounds promising. The project is unfortunately not that sophisticated. It literally hard coded PKG_CXXFLAGS and PKG_LIBS to values which apparently work on Debian. <wdkrnls>PKG_CXXFLAGS = -I"/usr/include/guile/3.0" <wdkrnls>That's the extent of the configuration in the project. <wdkrnls>So, I don't think this is really a Guix problem. <wdkrnls>I was hoping to this package might help me integrate Guix more closely with R, but that is the extent of the relationship. <marusich>Or morning, or afternoon, or night, wherever you are. <wdkrnls>I am do well. It's getting a bit late here (00:47 AM), but so far I am not too sleepy. And you? <iyzsong>hello from afternoon here, should go for food soon :) <marusich>Trying to build some things on POWER9, and noting what fails. I think the next goal for that port on master should be to get guix-build-coordinator working, so we can more easily gauge the health of the port. <marusich>But I have no experience with using guix-build-coordinator, so it's an adventure. <brendyyn>(EE) Cannot open log file "/var/lib/gdm/.local/share/xorg/Xorg.pid-704.log" <brendyyn>how do we do socket activation for things like pulseaudio, like what systemd does? ***jx97 is now known as jx96
<brendyyn>i notice pulseaudio runs as the gdm user <brendyyn>im wondering how that is launched like that <leoprikler>IIUC it is GNOME that launches pulseaudio through some mechanisms <leoprikler>you'll have to look in the relevant GNOME code for that <brendyyn>hmm ok im trying to make pipewire run instead of pulseaudio <PotentialUser-28>when I `guix pull` getting this errror. Maybe my /gnu/store got corrupted or smth. Any way to fix? <PotentialUser-28>guix pull: error: opening file `/gnu/store/2vzv3p0a5nbn8gg259csrja8pnyignry-module-import-compiled.drv': No such file or directory <pkill9>I want to use apparmor (which isn't packaged, but apparently is easier to use) or selinux to sandbox applications <pkill9>I use firejail currently but the problem is you can't call applications from other applications <pkill9>and have those other applications run with their own data <pkill9>I think apparmor or selinux would allow you to do this, but i'm not sure <rekado>pkill9: if you want to use selinux you will need to design a system-wide policy first. <pkill9>being able to have all applications sandboxed by default at the package level would be cool, although maybe a bit draconian, so opt-in <pkill9>i mean hypothetically if guix were to be set up so it sandboxes all programs by default <pkill9>it would probably break a bunch of stuff <pkill9>but it would be cool if programs are all sandboxed by default, yet still work with eachother without further setup <rekado>“sandboxing” isn’t quite what you get with selinux. <rekado>you label files and executables, and define domains and domain transitions. <rekado>executables start out in a certain domain, and that restricts what labels they can access <rekado>domain transitions are used to plot a path from one domain to another, so that other labeled files can be accessed when the process transitions <rekado>yeah, that’s a common feeling with selinux :) <rekado>take a look at etc/guix-daemon.cil.in for a start <pkill9>the problem with apparmor is according to the repository, it requires patches to the kernel :/ <pkill9>they say they upstreamed most of it, but that some patches are required <rekado>that file is the policy for a guix-daemon process on Fedora <rekado>it makes a bunch of assumptions about existing types that are not declared on Guix System. <rekado>there’s one block called “guix_daemon” <rekado>the first thing is to declare types that this policy depends on <rekado>things like init_t (for processes started by the init system, for example) <rekado>these exist on Fedora, but they are not declared on a Guix System. <rekado>the next section shows how to declare types. <rekado>next we declare type transitions, to say that processes in domain init_t (processes started by the init system) may transition to guix_daemon_exec_t, so that the rules we specify for that type apply to that process. <rekado>and then we declare what permissions come with all these types. <rekado>at the very end we declare what files should get what label. <rekado>all of the rules for files and processes are defined in terms of labels on files <rekado>that’s pretty much all there is to it. <rekado>the hard part is designing the policy; implementing it is pretty straight-forward. <rekado>once the base policy is in place (defining common types) you can define per-application policies. <rekado>the filecon directive uses regular expressions to label files, and since the application directories all have unique prefixes in Guix, it would make sense to generate the policy in a separate service (using G-expressions to get the absolute directory names). <rekado>without fixed FHS file names we can’t generate static application policies. <pkill9>I'm thinking I can use a daemon to do wha tI want <pkill9>downside with firejail is it uses SUID <pkill9>i'll make firejail solution first, then look into selinux/apparmor <rekado>I think for Guix System services SELinux policies would work fine. But I don’t see how that would work for arbitrary applications. <pkill9>I was thinking a daemon that updates selinux policies when you install new aplications to a given profile you wan them sandboxed, could be ~/.guix-profile <nckx>PotentialUser-28: Good morning. You could try ‘guix gc --verify=contents,repair’ first. *mekeor[m] hopes that the devel-mailinglist received his mail <nckx>Impatient mailman sent me a reminder 1 minute after you sent it. <pkill9>I htought of a filesystem idea that is interesting: files that are computed on the fly when accessed <meo>that is what /proc, /dev and /sys do <pkill9>is there a userspace option for that? <pkill9>e.g. you could have a file that generates a list of files from another directory, and whenever that directory is updated, the file just lists more <pkill9>instead of having to rewrite the file *pkill9 is slowly coming up with a sandboxing solution <pkill9>someday you'll be able to generate a profile of sandboxed applications that can call other sandboxed applications safely <rekahsoft>What is the best way to install a manifest, ensuring that only the manifest packages are installed? <rekahsoft>My understanding is that if I do something like `guix package -i some-package` and then install a manifest with `guix package -m some-manifest.scm`, 'some-package' will still be installed. <roptat>pkill9, I think the hurd has something like that with translators. I remember an example where they generate /etc/issue for instance, to provide a dynamic banner when you connect <roptat>rekahsoft, "guix package -m" creates a new generation that contains only packages from the manifest (unless something changed recently?) <balance>Hello! Can anyone help with issue with command "./gradlew build" a error occurs "Execution failed for task ':assets:compileJava'. Cannot find System Java Compiler. Ensure that you have installed a JDK (not just JRE) and configured your JAVA_HOME system variable to point to the according directory"? Have installed openjdk. Have exported JAVA_HOME=/home/user/.guix-profile/bin/ <rekahsoft>roptat: Well, just tested again and you are definitely right. Thank you for clearing up my confusion :) <leoprikler>balance: openjdk has a jdk output for the jdk :P <balance>leoprikler: ok, thank you for answer, and what it means? <roptat>balance, you need to install openjdk:jdk insteadd of openjdk <roptat>(confusingly openjdk provides "java" to run java programs, while openjdk:jdk provides the jdk, to build java software) <balance>roptat: thanks for help, will try :) <raghavgururajan>HELP! Ruby dependencies of ruby-asciidoctor are failing in core-updates. Could anyone help us by fixing them? <g_bor[m]>raghavgururajan: Hello, do you know why they fail? <raghavgururajan>g_bor[m]: Not sure, bunch of ruby stuff fails. I am unable to look into it more, as I am working on fixing other stuff. :) <raghavgururajan>Btw, `./pre-inst-env guix build ruby-asciidoctor --dry-run` should give all its ruby dependencies that are not building. <balance>roptat: your advice helped, but another issue occurs. Trying to build bisq on guix. "Failure: Build failed with an exception. * What went wrong: Execution failed for task ':proto:generateProto'. > java.io.IOException: Cannot run program "/home/user/.gradle/caches/modules-2/files-2.1/com.google.protobuf/protoc/3.10.0/e7ba2967f692c3bd2bd417f6a305bcb6a8c6a357/protoc-3.10.0-linux-x86_64.exe" : error=2, No such file or directory <apteryx>Hello Guix! I'm trying to 'guix deploy' a machine, and it failes because of a channel downgrade error; are channels used when guix deploying? Is there a workaround? <roptat>balance, yeah, kinda expected: gradle downloads arbitrary binaries that expect to be run on a system that has all its dependencies, but they can't find them on Guix System <roptat>I don't really have a good solution, probably you can fix this by running in an FHS container (a guix container where you mount at least /lib to contain the libraries, so these binaries can run) <roptat>the "no such file or directory" is confusing: I'm sure the file exists, but it wants to be run by /lib/ld-linux.so or similar, that doesn't exist on Guix System <balance>roptat: yes file exists, but even when i try to start it manually console shows "no such file or directory" <apteryx>ah, the machine-ssh-configure has this: machine-ssh-configuration-allow-downgrades? <leoprikler>balance: "file does not exist" can also mean, that it links against some library, that it can't find <roptat>(you'll have to adapt parts of that because gradle and your project don't have the same dependencies as android studio) <roptat>in general running another package manager is not very well supported on Guix System :/ <balance>roptat: ok, thanks, will read about that <Noisytoot>leoprikler, How was gradle initially bootstrapped? <roptat>but just like Maven, you don't really need gradle to build gradle, it's just very time consuming and error prone because you have to figure out what commands to run manually <roptat>and when you package dependencies, you very quickly hit scala and kotlin which are more difficult to bootstrap <efraim>I believe gradle is like basel and ghc, they descended from the heavens fully compiled <roptat>I'm working on scala today, and I think I have a working lexer and ~half the rules for the parser... this is going to be very long ^^' <roptat>but at least now I have a plan for the parser that might work <leoprikler>I found a commit, that one could theoretically bootstrap with ant+ivy <leoprikler>thing is, that ivy version and everything else is super ancient <leoprikler>in case anyone is interested in it, git stash says it's 68ed305dc9ea1efedf6e5774451dbd7a0725494e <roptat>I had recipes for a big chunk of gradle in 2017 <roptat>but it stalled because of scala and kotlin <nefix>Good afternoon! I've almost finished packaging `libvirt@7.2`! There's only a missing piece: there are 3 build options that are `sysconfigdir`, `localstatedir` and `runstatedir`, which are mappped to `/etc` `/var` and `/run` by default. The thing is that they make the install phase (using `meson-build-system`) fail since they try to write to those directories during install. `libvirt@5.8` solves this <nefix>by sending flags to the `make install` but now `libvirt@7.2` uses`meson` & `ninja`. Can I pass flags to the `ninja install` command? I've tried replacing the `'install` phase, but it doesn't seem to pick up the `-D` flag prefix. Any ideas? Thanks! :D <roptat>leoprikler, well, if you use the ant-build-system, it generates an ant.xml file <roptat>that's how we build maven and its dependencies too <roptat>although now I would rather use invoke and manually run javac instead of using the ant-build-system <leoprikler>ah, so instead of using the build xmls that ship with the package, you generate your own? <roptat>the ant-build-system uses the build.xml that ship with the package when they exist, otherwise it generates its own build.xml <roptat>in retrospect, that was probably a mistake, we should probably have created a separate build system to make things clearer <leoprikler>maybe toggle it with a flag? #:override-build.xml? <roptat>yeah, whenever #:jar-name is set, it replaces or creates the build.xml <Vongazi>Hey is /etc/config.scm supposed to be non writable by anyone? <lfam>There are different reasons for that file to exist. So, it depends <lfam>Did you create that file? Or was it created for you? Did you look to see if it's a regular file, or a symlink to something else? <Vongazi>i installed guix manually as described in the info page, So i copied this file from /etc/configurations/lightweight-desktop.scm in the live cd to /mnt/etc/config.scm and edited it, And no it is not a symlink <lfam>So, why can't you edit it? <lfam>I think the installer put it there <lfam>If you want to edit it, and it's a regular file, then it should be fine <lfam>I have to go, good luck! <Vongazi>i can edit it if change the permissions, I'm asking because some programs do this intentionally like sudo, /etc/sudoers is not writable by any user and if you want to edit it, the proper way is to run visudo, i thought maybe config.scm is doing something like this. <apteryx>would someone know if h.264 hardware acceleration is possible with the Intel 4500MHD GPU that the X200 boasts? <cbaines>Vongazi, I don't believe /etc/config.scm has any special significance, so I'd just change the permissions to suit you <roptat>speaking of acceleration, I sometimes have weird lines on top of canvas, sometimes it also appears when sharing my webcam or screen in icecat :/ <roptat>and sound in some videos is terrible when played from icecat, not sure how to debug that <roptat>the pitch is very low and clicks suggest that maybe there's an issue with sampling <apteryx>roptat: I think this issues of sound pitch problem has been reported before <roptat>yeah, I'd like to fix it once and for all <roptat>maybe it's related to the type of content returned by the server? From two sources I have the low pitch issue and they both send video/mp2t <jackhill>apteryx: I don't have a x200, but vainfo fails in the same way for me. Still with Intel, my CPU is Intel(R) Core(TM) i7 CPU L 640 @ 2.13GHz <ss2>I've had this happening too. The streams would pitch up and become unhearable. <apteryx>jackhill: the store reference it points to doesn't even exist <apteryx>/gnu/store/14qgm67plbh8d3m6lc87b9j6s9296vwn-mesa-20.2.4/lib/dri/iHD_drv_video.so <apteryx>jackhill: from the libva NEWS file: * drm: Add iHD to driver_name_map; this was in release 2.6.0 - 15.Dec.2019 of libva <apteryx>perhaps it's leading our mesa package <apteryx>but there seems to be some challenges with backporting new things to this old unmaintained branch, and have it work reliably with the latest linux-libre kernels *raghavgururajan hugs nckx for updating flite <jackhill>apteryx: thanks for the pointers/investigation. I've noted them as I have other distractions that prevent me from thinking to much about Guix things right now. <raghavgururajan>sneek, later tell lle-bout: Phew! All gst stuff builds successfully now, with --without-tests={shepherd,nss,libsoup,python-pygobject}. Could you review and merge please? <vagrantc>so, i've gotten the apm mustang booting guix with linux-libre-arm64-generic ... <vagrantc>now, trying to get "linux-libre" working involves tweaking the initrd-modules .... boot 7 and i still haven't gotten it to boot <vagrantc>that's why i like linux-libre-arm64-generic <vagrantc>but, finally figured it out ... now let's see if i can trim that module list down... <raingloom>might take a few days before i submit a proper patch, given my track record with focusing my attention. <raingloom>if you don't like emacs but wanna edit scheme, this might be for you :D <raingloom>i can't believe that kakrc entry worked on first try. <ryanprior>I did `make clean`, `configure`, `make` to no improvement <ryanprior>When I add or upgrade a package definition and then run pre-inst-env guix build <package> it ignores the new definition <ryanprior>If I `pre-inst-env which guix` it looks like the right one, pointing to scripts/guix <ryanprior>If I modify the package file to evaluate to the package such that I can pre-inst-env guix build -f <the-file> then it works, it builds fine, so the definition is not broken. <ryanprior>But the repo is screwed, I can't use "pre-inst-env guix" normally, it's got some kind of screw loose and I can't figure out what that might be <Frosku>I want to bump the version of clojure <raingloom>for a proper fix that you can send as a patch to the mailing list, you'll have to create a local clone of guix and upgrade clojure there. <Frosku>raingloom: Thanks, how would I get my guix to use the local clone instead of the remote? <raingloom>Frosku: you probably shouldn't. just use ./pre-inst-env to install the fixed package. <raingloom>Frosku: see the Contributing page, that explains it better than i can in a few lines of IRC. <raingloom>no prob UwU. `info Guix` is where you should look for that btw. Or on the website, but browsing the local copy is faster. <raingloom>Noisytoot: that's a can of worms i'm not opening right now :D <raingloom>let's just say i tried to love Emacs but it didn't love me back. Kakoune is my new sweetheart for now. <Noisytoot>raingloom, You can use evil-mode if you prefer vi keybindings <raingloom>of course Kakoune also sucks in its own ways, but they are much more manageable ways, at least for me personally. <Frosku>Sorry, last question. The contributing guideline says that it needs to be 'in the guix source tree' before running ./pre-inst-env -- do I just run the command in the same dir as the file or does it need to be somewhere special? <raingloom>Frosku: you should cd to the guix repo that you pulled. <raingloom>technically you can use an absolute path to pre-inst-env. for example, for me it would be $HOME/Projects/Guix/guix-source/pre-inst-env guix build whatever. <raingloom>but it's easier to just stay in the guix repo. <sneek>lle-bout, you have 1 message! <sneek>lle-bout, raghavgururajan says: Phew! All gst stuff builds successfully now, with --without-tests={shepherd,nss,libsoup,python-pygobject}. Could you review and merge please? <lle-bout>raghavgururajan: heyy!! nice!! Testing now! <raingloom>Noisytoot: that's ./configure --sysconfdir=/etc/ --localstatedir=/var <raingloom>not an issue for packages, but if you guix system reconfigure from a local checkout, you will have a bad time. <lle-bout>raghavgururajan: what changed basically? <raingloom>Noisytoot: in that case it probably doesn't matter if you use sysconfdir, but it's better to know about the option. <leoprikler>Btw. how are profile hooks recorded in the manifest? <bdju>My guix shirt says `guix build world` on it, but it seems this isn't a real command! Maybe it could be added. ;) <Noisytoot>bdju, It's real if there's a package called "world" <pkill9>make it a meta-package containing all the packages in guix <leoprikler>or write your file system in a way, that "world" always refers to the manifest of all public (and non-public) packages <Frosku>raingloom: Sorry, I'm feeling a bit dense. I've pulled `guix` from savannah, I can't find pre-inst-env.sh. <raingloom>it's a bit intimidating when you first do it, but don't worry. <Frosku>Yeah I'm sure I'll pick it up fast enough <raingloom>the manual should cover it, but just in case: <raingloom>./bootstrap && ./configure --sysconfdir=/etc/ --localstatedir=/var && make -j 2 <raingloom>replace the 2 in "-j 2" with the number of CPU cores you have / want make to use <raingloom>yeh, stikonas 's version is probably the ideal. although more cores also means more memory use. if that becomes an issue, just use a smaller number. <Frosku>Sorry, what are the deps to install to build? It's telling me I don't have autoreconf (I assumed that was in the autoconf package but apparently not) <raingloom>Frosku: ah, forgot to mention, you need to be in `guix environment guix` <raingloom>which will pull in all the dependencies to the local environment without installing anything globally <stikonas>autoreconf should be in autoconf package <stikonas>unless distro splits autoconf package into two... *lle-bout loves the new guix download progress bar UI <stikonas>raingloom: well, guix environment guix only works if you already have guix... <raingloom>stikonas: yes but if they already have guix installed there is no need to use anything other than `guix environment` <Frosku>Just very new to the build process <lle-bout>marusich: heyy!! about the article, how do you feel about it? <lle-bout>marusich: I'm going to write/review a little now <raingloom>Frosku: anyways, that build will take a while and even though the Revision stream is very cool, i'm going to have to go to sleep. :C