<KE0VVT>zamfofex: Ah. I wasn't aware I did that. Strange.
<zamfofex>I knew I wasn’t going crazy. 🙂 There might be other lines like that too.
<KE0VVT>zamfofex: Hm. How do I make Emacs see the whitespace?
<KE0VVT>zamfofex: Were you able to reproduce the error?
<zamfofex>I just was a few seconds ago. (Sorry it took a while, I didn’t have most of those packages, so they began substituting. I stopped the build to remove all of them, and the error is indeed there.)
<efraim>there's a flag to disable them. I'm not sure how necessary they are, but I think we could disable them at least for non-x86 builds. I'm sending that patch and one to fix building on powerpc-linux to the mailing list
<xelxebar>Hrm. I have a package that's looking for gnu/stubs-32.h, but glibc only provides gnu/stubs-64.h for the target system.
<efraim>I think that normally means you're building with a 64-bit toolchain and should be using a 32-bit toolchain
<efraim>does anyone remember what gets to use the daemon from inside a container? I want to see if I can get it working with guix home
<futurile>santiagopim: OK, in that case your email worked. What's happening with the patches email list is that it's manually administered: I *think* it's a one time thing (not sure), so you have to wait for someone to let the email through to the mailing list.
<futurile>mrh57: it's variable. Did you look up whether there is a team responsible for the area? If so you should CC them onto the email so they know about it. You could probably politely give a nudge after a few days.
<futurile>Kabouik: remember you can built the package locally; and help out by then confirming to QA that you both built AND used it successfully
<futurile>Kabouik: ofc, that requires some work heh heh
<Kabouik>Could you please remind me what would be the most parcimonious way to build a package from an unofficial patch? Writing the .scm file, adding the name of the package at the end, and guix build -L /path/to/file? I'm sorry, I'm rusted.
<mrh57>futurile: good to know. doesn't look like there's a team for wayland compositors / window managers in general, although good to see there are teams for lisp, go, and emacs as I have some packages for those
<mrh57>futurile: when you say "nudge", do you mean sending another email to the issue thread (i.e. to [bug-number]@debbugs.gnu.org)?
<Kabouik>I remember now that the main problem I'm having when trying to build locally a patch I found in the issue tracker, is finding which modules the package would require, since this is usually not in the patch given that the main .scm file has all modules already.
<gabber`>Kabouik: in regard to *patches* it might be easiest to host your own git clone of the repository and *apply* the patch to it -- you can then build with $(./pre-inst-env guix build foo)
<futurile>mrh57: I would check if the QA system build packages from your patch - if it's all good it's a lot easier. Yes, send an email to the bug@debbugs etc as that will cause it to go back up in the patch email list. If there's no 'team' then I think it's just to do with someoen seeing it at the right time. There's a general thing that there aren't enough people available to review/commit patches.
<gabber`>mrh57: everyone is cordially invited to do reviews, general outline of patches, formats and other caveats with respect to that is written down in the reference manual (:
<Kabouik>Thanks gabber, that seems to be a better workflow indeed. The build failed on my end but at least it started, so I guess it might be an issue with the patch (I'm unable to understand the ice-9/boot-9.scm exception I got to be honest, will have to check that later since I'm at work).
<Kabouik>I assume I should just guix pull and guix package -u beforehand.
<Kabouik>Unfortunately guix package -u freezes my computer and I have no choice but hard rebooting. The last message before the freeze is "Building profile with xxx packages..." What are my options? Can I build only a fraction of the packages to update my system little by little if it can't take that much load?
<gabber`>Kabouik: that sounds bad (and kinda weird)
<gabber`>when working with your own guix checkout you don't need neither $(guix pull) nor $(guix package -u). come to think of it you should never need that to $(guix build) something
<gabber`>the ./pre-inst-env ensures you use the adequate versions of guix and the package's dependencies
<gabber`>also: if you provide the logs and/or the patches we could glance over and maybe provide you with more specific help
<Kabouik>Re: pre-inst-env: got it, thanks. A guix pull && guix package -u is long overdue though, it was not a bad thing to make me run it. Not sure though why it crashes. I'll try with cpulimit and see if throttle/overheat that was the culprit.
<Kabouik>If not, I'll post more details yes, but can't delve too much time on it myself today anyway. Thanks again.
<gabber`>jpoiret: that didn't work (it hung but i could C-c it again) and also C-c in the parent process didn't terminate it (i suspect an interestingly broken OS definition since it also doesn't work as expected in the VM)
<nutcase_>Hi Guix, is there anyone here happily doing Java development on a Guix System?
<lilyp>"happily doing Java" is already a contradiction, and I recently packaged some java RDF stuff, so I guess I qualify for whatever question you have following up
<Kabouik>Any idea about this? This follows my update. /home/mat/.guix-profile/bin/chromium: error while loading shared libraries: /gnu/store/ljik32x4kdplpbpyyp79wbd6m2vz6yhz-xvid-1.3.7/lib/libxvidcore.so.4: file too short
<gabber`>that is an interesting error (i think i have never seen before)
<lilyp>Does your update by any chance include a gratuitous power outage?
<Kabouik>My update did include two hard reboots due to freezes lilyp
<lilyp>congratulations, you can garbage collect and try again :)
<gabber`>that only sets you up to make things worse
<gabber`>IIUC all the old generations are still *there*
<gabber`>what happens after boot? no password means it just boots? grub rescue? what do you see?
<Kabouik>Except I guix gc'ed before guix gc -d 677. But I didn't delete-generations before so hopefully that didn't touch the previous generations.
<Kabouik>I just get the manufacturer logo, no grub. But I'll let it col down too, this symptoms occurred too before when it was overheating during the stalled updates that forced me to hard reboot. Could be the BIOS being blocked when temps are higher than some threshold.
<Kabouik>I could select an old configuration but got the same issue at the logon script: typing my passwords sends me back to twthe log on screen. I'll try an even older configuration (that's what it's called in grub, not generation) and if it fails, try from tty a rollbac.
<Kabouik>I guess configurations in Grub are just system reconfigures, not package generations?
<Kabouik>No I'm not, I'd be happy to delete them but I guess I misunderstood the delete-generations patterns. I always use `guix package --delete-generations=2m` before my gc.
<gabber`>are $(guix system vm) and --system=some-foreign-system mutually exclusive?
<gabber`>according to the --help option of $(guix gc) the part after the = sign in --delete-generations= is a pattern matching string.
<gabber`>i think the 2m is a useful option for --collect-garbage (where it denotes a minimum of garbage to collect) or maybe (but that doesn't seem to make much sense) the --free-space option
<Kabouik>I thought =2m would keep me only two-month worth of generations. See the manual: "When pattern specifies a duration, generations older than the specified duration match. For instance, --delete-generations=1m deletes generations that are more than one month old."
<Kabouik>But somehow I still have 677 generations so there is something wrong with my workflow.
<nutcase_>lilyp: ok, I should've said "as happily as possible with Java". I have several issues, some of them could be solved by guix shell --containers. But still there are issues and I consider of having a fundamental error in my setup. So one example is, that I need to use OpenJDK 17 and maven and maven 3.8.6 (which is the version in guix) does not work with simple `guix shell [--container --network coreutils] maven email@example.com:jdk`
<lilyp>nutcase_: to be completely honest, I have no idea how maven is supposed to work and what's required to make it do so
<lilyp>in my personal experience, brute-forcing builds via ant-build-system is more likely to be fruitful (sad but true)
<gabber`>Kabouik: it'd be great if you filed a bug-report (if there isn't anything that resembles your issues of today)
<nutcase_>lilyp: in my case it's not about building a binary from source, but in performing different tasks with maven during the development process
<nutcase_>lilyp: So, I just want to run some `mvn clean package`. Furthermore, a lot of Java programs won't run, if I'm not using --container --emulate-fhs. Maybe just some env variable is missing to avoid that?
<lilyp>if it's guix-packaged once, they ought to have a wrapper setting the java classpath
<Kabouik>Sure gabber. I'll do it after I fix my update and after work.
<nutcase_>lilyp: what do you by "it" in "if it's guix-packaged once"?
<lilyp>if you have a java program packaged in guix, there should be a wrapper :)
<nutcase_>lilyp: I need a development environment (not for building guix packages), not a runtime environment (to run a software that is mature enough to run).
<futurile>nutcase_: hi - when you said 'maven' doesn't work when you start it with a shell, what happens? I just did `guix shell --container --nesting --network maven` and it's told me it's going to download 1G of packages - so might be a while heh
<nutcase_>futurile: What java version is mvn using? (java -version)
<nutcase_>and even with this, I am running in a problem with a software that additionally uses npm. So my initial questions were into the direction: Where did I go wrong? Is there a good source of information about guix shells for java development?
<futurile>nutcase_: I don't think you're going wrong anywhere really - you either have to use what's in the archive (and sounds like that's not going to work for you - or you can use ``shell --fhs`` and treat it that guix is giving you a 'chroot'
<nutcase_>with `shell --fhs` you mean a `guix shell --container --emulate-fhs`?
<futurile>nutcase_: yup - which basically makes the environment look like a 'normal' Linux environment. Essentially, it creates symlinks so that the 'normal' /lib is there.
<futurile>nutcase_: then things that have been compiled to work in that kind of environment should work - so for example, it's how I run Chrome
<nutcase_>futurile: I didn't figure out, how to add something manually to $PATH inside a guix shell --container
<futurile>nutcase_: so say you have something in ~/bin, you could do it two different ways - either use the `--preserve=^PATH$` to keep your existing path; or (b) create a script like the one shown in the blog post and manipulate PATH there
<Guest36>Hello, is the build server down? I get this error message:
<podiki>the idea would be yes, adding gcc-toolchain should be the correct thing to do I would say, and it is a bug that it is n ot
<nutcase_>podiki: while my software seems to build now with your fix, your explanation builds me up a bit :-)
<podiki>it was a change in how gcc was exposed as a package, you used to be able to specify gcc:lib as a package to guix shell
<podiki>seems the conversation in that bug report stalled out so I should probably propose a new patch there
<nutcase_>podiki: why is the (list ...) expression not evaluated in my `guix repl`?
<Kabouik>Updating my machine is a rocky road today. My guix system reconfigure keep failing in the middle of the building step (here it stalled after linux-6.5.10.drv check phase) and makes my whole system read-only until I reboot: https://0x0.st/HtI0.jpg
<podiki>what do you mean? (list ...) evaluates to the gcc:lib package output for me
<podiki>Kabouik: are you sure some filesystem isn't mounted read-only as it says?
<nutcase_>sorry. It also works in my guix repl, I just forgot the final paranthesis
<nutcase_>podiki: / futurile: thanks to the both of you, I am now able to run a maven buildof a software in question. However, it still requires me to manually add something to $PATH. What would you to suggest, how I could do that elegantly in that shell: http://paste.debian.net/1297677 ?
<podiki>did you try to preserve PATH? I think that works, just note that with a container you'll need to also share the directories of things from path you want to execute (and whatever they depend on)
<nutcase_>futurile: sorry, you suggested that before and I didn't test and assumed that this won't work. Thank you
<futurile>nutcase_: no worries - it sounds like you're making progress
<podiki>as reported earlier seems some parts of ci.guix.gnu.org are down (web page) but responds to ping and weather requests
<nutcase_>futurile: yes, I do, but slowly. Unfortunately, this isn't something contributing to guix.
<nutcase_>I wish I'd be able to commit a patch that updates the maven version in guix
<Kabouik>podiki: it's not, you can see for instance in the picture I've taken that the guix system reconfigure command did do something the first time (top half of the screen), then after it stalled, the same command does not work anymore and complains about the system being read-only. It kinda crashes half through.
<nutcase_>but in particular the maven package doesn't look trivial to me
<podiki>Kabouik: but after do you see things mounted read only? just curious if that is really the case then.
<Kabouik>And when it crashes like that, I cannot even use wl-copy or scrot to make a screenshot of the error (hence why I took a photo).
<Kabouik>Oh, I haven't checked that. But I can relaunch the reconfigure and see if it happens again.
<podiki>and all the other parts were downloads but this was the first thing being built locally? maybe something with /tmp?
<Kabouik>Would it throw this error if I run out of disk space?
<Kabouik>I'm asking about disk space because I'm in btrfs and knowing exactly how much free space I have is far from being trivial, but I know it's on the low size (i3-statusbar-rust says 18GB, that's not comfy I'll give you that).
<podiki>i don't really have any ideas what is happening, sorry
<Kabouik>My suspect is disk space, with a shady error message
<Kabouik>I actually have a SSD twice bigger that I need to install in my computer. That would be a perfect way to solve the issue without using my brain. But I need to make a 1:1 copy of everything onto it first, knowing that my current SSD is encrypted, so I doubt I could just use dd if=xxx of=xx, could i?
<ieure>Kabouik, What do you see if you run `df -i`? You can have space available on the disk, but run out of inodes in the filesystem to reference it.
<podiki>shouldn't be a problem with btrfs as I understand it
<futurile>nutcase_: well I personally would be interested if you manage to get a good working 'development environment for Java' - so if you do and you blog about it that would be brill - lots of people are asking about that sort of thing in the channels / email lists etc
<podiki>I would think dd works (just copies the raw data) and still would need to be decrypted at mount? but don't quote me on that
<Kabouik>I could try anyway. But given that my disk UUID is in my config.scm, I suspect I'd have to decrypt it externally first, chroot into it, edit the UUID and then system reconfigure?
<podiki>probably? i might check some general information about moving/changing encrypted disks, obviously the process will be a bit different with guix, but that might be helpful before you spend the time
<podiki>or maybe someone here has done it on a guix system
<nckx>sneek: later tell adanska Here's an untested attempt at exFAT support (*of course* it wasn't as easy as I promised, where would be the fun otherwise?) <https://tobias.gr/temp/exFAT.patch>. If you could test it with wild exFATs (created by SD vendors and/or Windows) I'd be grateful. I don't have either.
<podiki>long build and test process needing lots of ram, so a bit hard to test
<roptat>trying to reduce the closure size of josm, I made javacc reference the jre instead of the jdk, reducing its closure by 350MB (\o/), but I also removed the reference from josm to javacc (which is only needed at build time). Still, java-swt has a refreence to a library in icedtea:jdk, but making it an input instead of a propagated-input (it's an optional dependency, but anything depending on it will have to explicitly add it) makes it no
<roptat>longer a dependency of josm, and reduced its closure size by 1GB :)
<podiki>found another issue, qtbase did not like libxkbcommon 1.6 (some removed keysyms)
<podiki>the only breaking change in libxkbcommon but what do you know
<podiki>why skia fail I don't know, it just fails some tests it seems
<podiki>(so did mbedtls-apache, but a version bump fixed that; should have just been because of libx11 ungraft causing rebuild of python, yet tests broke for mbedtls-apache)
<podiki>ACTION shrugs, lets qtbase build locally, and literally runs away
<futurile>Q: how so I tell the QA system to build my patches against a particular branch? (in this case rust-team)
<nutcase_>futurile: I don't blog (usually), but of course I will share my findings and thoughts on how to setup java environments in Guix
<futurile>(twice today I've tested my patches against rust-team, but the QA system is building against master - probably because the base commit I'm using is in both??
<nutcase_>I'm thinking about the format (probably some literate org file) in a git repo, what would you suggest?
<futurile>nutcase_: that would be great - and usable by lots of people in this community!
<nate1>Can someone help me figure out why my variant of httpd stopped building? This used to work and build me a version of httpd with some additional modules enabled, but now even though libxml2 and zlib are inputs, the path that gets passed to the configure phase for those inputs doesn't exist
<nate1>I think there's a great chance I'm doing this wrong so please correct me if I am
<nate1>If I manually build libxml2 and zlib so that the store items are there, it seems to work fine
<gabber>nate1: i'm no expert and you seem to have crafted some advanced magic here, but i think this can be written more easily?
<gabber>i think your ,@(lowered-gexp-sexp could be inlined with some gexp ungexp?
<gabber>is there some error message or other indication as to *what* does not work (anymore)?
<nate1>It won't even build because when it goes searching for libxml2 at the store path that mess of a line generates, it doesn't exist. I would expect it to have built all of the inputs before it got to the configure phase
<nate1>Do you have an example of what I would do instead of that mess? It definitely felt when I was writing it that there had to be a better way that I didn't understand
<nate1>So to be more specific about the error, configure is ran with the argument --with-libxml2=/gnu/store/81l6jbs7rxxsx1ld0vmn43gwnnysa0gf-libxml2-2.9.14, but that store path doesn't exist, so I get this error
<nate1>checking for libxml2... checking for libxml2... no
<nate1>checking whether to enable mod_xml2enc... configure: error: mod_xml2enc has been requested but can not be built due to prerequisite failuresy
<gabber>ok first i think your input modification can be simplified to something like: (cons* libxml2 zlib (package-inputs httpd))
<gabber>and i think your (lowered-gexp-sexp (with-store store)) shabang can be simplified with some #$(this-package-input "input-name")
<nate1>gabber: Doesn't package-inputs return an association list so cons* wouldn't work? I thought that was the whole point of modify-inputs. But I changed the arguments stuff to this https://paste.debian.net/1297713, and everything seems to work now
<nate1>I'm still confused why the inputs weren't built first, but those arguments feel far more correct, so thanks for that
<gabber>first of all: yee (and i can't stress this enough) haw!
<gabber>you may be right about the association list - at least that's the way inputs used to look for all packages. but since a couple of years(?) now this has changed and if you look at the package definition of httpd the (inputs) field is a simple list of packages (while (native-inputs) is still in the old form)
<Kolev>roptat, Haunt generates URLs starting with /.
<roptat>Kolev, for #2 there's #:make-slug in your site generation you could use
<podiki>apteryx: I had to change an input for qtbase for it to build on mesa-updates; should I see about doing a minor version bump or is that likely to cause a lot more work for possible breakage/qt updates?
<apteryx>podiki: is the minor version bump tracking an LTS release?
<apteryx>I think it may be a good idea to stay on an LTS for now, as even Jami struggles to keep up to date
<podiki>I'd have to check, i'm not familiar with qt versioning
<podiki>qt5 is only the last number changes, and qt5 is LTS by default? or not?
<efraim>5.15 is the last of the 5 series, so bumping to a later 5.15.x wouldn't be a bad idea
<podiki>grafts question: grafts are done after building, right? so having tests fail after ungrafting could happen? (in other words, now the package is actually built/tested with the updated input that was before just grafted after, exposing potential changes?)
<podiki>efraim: thanks. I'll take a look then, since qtbase is being built anyway (libxkbcommon update on mesa-updates)
<podiki>lots of little things failing (in tests mostly) that I didn't expect on mesa-updates
<Guest25>is it possible to install java on guix . if so, which is the right package ?