<Kabouik>(emacs-which-key will help me tremendously with learning emacs. Glad I found about it.) <podiki[m]>I think use-package will become part of emacs at some point, so I heard <dgcampea>when should I use mixed-text-file over text-file* ? <jab>dgcampea: I believe mixed-text-file lets you use strings and gexps. <jab>but text-file* is only for text... <Kabouik>I see that System Crafters do use use-packages to download and install some emacs packages, even on Guix (like command-log-mode) <Kabouik>But other that may be to make the emacs config self-sufficient and to make the video less Guix-oriented to better reflect the audience, instead of depending on Guix packages <podiki[m]>not all emacs packages are in guix, though I think there is a channel out there that automates every melpa package definition? <atka>hey guix, which package contains chattr? <apteryx>Kabouik: it's very easy to add Emacs packages to Guix, so if you have something missing, I'd recommend trying to package it! It'll be worth it down the line. <jab>apteryx: weirdly enough, I think emacs XMPP package (jabber.el) is gaining some bitrot. <jab>last time I tried to use it, I had some weird errors. <Kabouik>I'm not there yet apteryx, so far I found all those I wanted to try (except command-log, but really it's mostly useful to a streamer, I just wanted to try it but don't really need it). <Kabouik>But I surely will if I definitely settle with emacs and find something useful that wouldn't be packaged! <apteryx>rekado: oh, I see; sources filled with third party .jars; neat <apteryx>uh, apparently "source jar"s are a thing <apteryx>rekado: uh: Build successful! Binary is here: /tmp/guix-build-bazel-5.3.1.drv-6/source/output/bazel ***Server sets mode: +Ccntz
***pkal_ is now known as pkal
***jetomit_ is now known as jetomit
<sneek>Welcome back civodul, you have 2 messages! <sneek>civodul, nckhexen says: Is lookup-qemu-platforms silently ignoring unknown platforms a design decision? <sneek>civodul, PurpleSym says: Wrt release: Can I still push a few world-rebuilding changes to haskell-build-system to core-updates or is it too late for that? They’re currently sitting in wip-haskell, but I never got around to get the indended Haskell ecosystem done. <rekado>sneek: later tell apteryx oh wow. I don’t know if it existed back then. Last I remember is that it was merely a copy of a binary bazel distribution with a bunch of third-party jars that was only good for downloading a new bazel. <rekado>sneek: later tell apteryx if you actually have a working bazel build that would be wonderful! Building a newer version of tensorflow would still be very challenging (because bazel needs to be convinced not to download *everything* from the internet), but it would at least be possible. <f3n1x>Good morning guixers ! I must be missing some basics here... I've just '$ sudo guix install ripgrep' and when i try to invoke the command i'm getting 'command not found' error message instead of. What am i missing ? (see the full log here https://pad.elbinario.net/p/ripgrep-guix ) <unmatched-paren>so when you run ``sudo guix install'' you're installing packages for root and *only* root <f3n1x>ah! ... nice to know unmatched-paren. Thanks, thanks, thanks *f3n1x guess is that helps on the 'reproducible' spirit <unmatched-paren>the only commands that should require root are the ones that start with ``guix system'' <unmatched-paren>not really, just that the stuff that helps with reproducibility also make it easy to implement per-user package management. <f3n1x>crystal clear .That makes sense... now that i know. *f3n1x loves GNU Guix philosophy <kitty1>Hows everyone going? Anything new recently? Haven't been here a while. <mbakke>PurpleSym: core-updates is still open, but haskell-build-system can go to 'staging' ... although it might be better as a focused "topic branch" that gets merged separately :) <mbakke>PurpleSym: in other news I've started to look at wip-python-pep517, I'm going to try and add it on 'master' as a separate build system <PurpleSym>mbakke: A topic branch for an entire Haskell upgrade was my plan, but as of now it’s just two patches, so I’d rather have these in the next release than waiting for an upgrade to happen. <PurpleSym>mbakke: Nice. So, slow transition for Python? <mbakke>PurpleSym: it probably won't make it to the release, but you can push them to 'staging' <mbakke>PurpleSym: I'm thinking to add it on master now and merge it piecewise to python-build-system, we'll see how it pans out <PurpleSym>Thanks, mbakke! I wish I had the time to do it myself, but great that you’ve picked it up. <PurpleSym>If you have any questions about that new build system, please ask. <nckhexen>Morning everyone who said morning. And everyone else, too. <mbakke>not sure what to name the new python build system though ... any bikeshedders around? <mbakke>pep517-build-system, python-build-system-next, or something else entirely? <mroh>There are only two hard things in Computer Science: cache invalidation, naming things, and off by one errors. <mroh>perhaps python-pep517-build-system. <PurpleSym>mbakke: Maybe pyproject-build-system after the name of the config file controlling everything? <PurpleSym>(Even though it technically still works with setup.py) <cbaines>has anyone built rust@1.54 or greater post staging merge? <mbakke>cbaines: I can't reach that derivation, I have /gnu/store/mxag14jgfjmxx0gx004f7mp5jxnsamwg-rust-1.54.0.drv <reyman>Hum, there is actually a problem with : `/gnu/store/sb9737fc6wpskkw8z7r8lzz4gfkwq0c9-emacs-native-comp-28.1.91-checkout.drv' failed with exit code 1 ? <cbaines>mbakke, ah, I forgot to mention that I was looking at aarch64-linux ***wielaard is now known as mjw
<cbaines>I guess it's maybe useful to compare the log against the successful x86_64-linux build though, this line stands out as different: <cbaines>:0: BUG:src/mir/from_hir.cpp:524: TODO: visit - asm! const <mbakke>efraim: thoughts? should we do a rust rebuild before the release? <mbakke>there were so many missing substitutes for aarch64 that I missed rust <cbaines>I thought it was really good recently? <cbaines>I spotted over 90% for aarch64-linux <horizoninnovatio>Greetings, how far along is kde-plasma to being a usable desktop? I was thinking more along the lines of LXQt + kwin + latte-dock. Would that combo work? Thank you. <mbakke>cbaines: I rechecked now and got 39.1% on ci.guix for commit 3a84b4ec4 (just before staging merge) ... however I had not noticed that bordeaux was at 84.7%! <unmatched-paren>horizoninnovatio: Maybe you could apply and test that patch yourself, and report back to the issue thread. <unmatched-paren>By the way, you can reconfigure from the guix checkout with ``sudo guix shell -D guix -- ./pre-inst-env guix system reconfigure ...''. <unmatched-paren>They do add a plasma-desktop-service-type, so try adding that to your system and reconfiguring with that command. <pkill9>i've been so unnecessarily afraid of reconfiguring my system on the assumption it does a bunch of magic that takes ages <pkill9>but it only took a minute to add the earlyoom service <unmatched-paren>it often seems to take ages because you don't reconfigure often, which means there'll be a lot of updates etc to download <pkill9>unmatched-paren: it shouldn't though if you don't update your guix <pkill9>but in the past it has downloaded random stuff, even though I didn't update guix before reconfiguring <pkill9>i think earloom service should be in %default-desktop-services <pkill9>i should send a message to the mailing list <horizoninnovatio><unmatched-paren> "By the way, you can reconfigure..." <- Thanks, I'll have a look and see what I can do. <cyberkefir>expected one is 1mx2b7ljwvmfl5d0w9m7i1i900198lsdx1cpi8n7wq58h5df88p9 <cyberkefir>actual is 030837yak24ymjawsfr1hgyfdjy3k30ld1ca0cgnrxhgxc7p8hwv <cyberkefir>my master guix commit is 6fad3d5985f46ce19672c902fc93e0f91c3fb8f2 <cyberkefir>can I ask you to show your guix descrbe - guix master commit ? <unmatched-paren>maybe you could gc the source output? ``guix gc $(guix build --source emacs-eglot)' <cyberkefir>nah, it still wants 030837yak24ymjawsfr1hgyfdjy3k30ld1ca0cgnrxhgxc7p8hwv <cyberkefir>eglot was the propagated input of one of my packages <unmatched-paren>But it didn't have a hash mismatch, instead there was a profile collision. <mroh>any emacs-guix users around? Is there a way to disable (emacs-guix)pcompletion for shell mode? (setq dont-touch-my-shell-mode t) <PotentialUser-26>Hi. The building guix package cache now takes forever and uses a lot of RAM. Was there a change lately causing this behaviour? <cyberkefir>PotentialUser-26: what kind of hardware you are using? <cyberkefir>nah i guess guix is not the best thing you can use there <cyberkefir>of course you can try to define your own base packages and services <PotentialUser-26>The problem is in the last stage. Everything works until phase building package cache <PotentialUser-26>cpu is not that active on the last phase. RAM starts swapping (4G on board) 2 GB swap now. Storage is 10 GB free <mbakke>the update in guix was done october 10th, the day before the current 1.9 tag <mbakke>cyberkefir: sorry I already fixed it: b13362107dbb7e351e0d227b903a8ebba9cd494f :P <cyberkefir>PotentialUser-26: can you use time-machine or switch generation to check it? <cyberkefir>i think it would be better to boot in another generation and repeat update <mbakke>PotentialUser-26: can you file a bug? there was a merge done yesterday, perhaps there are "loops" or something on aarch64 *mbakke should buy an aarch64 machine <mbakke>if they can run Guix System that would be awesome :-) <cyberkefir>btw, anyone tried to boot guix on new arm based thinkpad? <cyberkefir>mbakke: actually i want to find energy efficient mini pc which will work with guix <mbakke>cyberkefir: if you can do without wifi, most hardware will work with -libre <unmatched-paren>and if you can't, it should be pretty easy to buy a wifi card that does work <Lumine>I bought a Lenovo Ideacentre 5i Mini last winter, with no plans for a system, but turned out Guix was borderline perfect <PotentialUser-26>mbakke: I did a guix time-machine --commit=hash from 4 days ago. Does this switch to an older guix binary? Do I have to restart the daemon <unmatched-paren>PotentialUser-26: Doesn't ``guix time-machine'' only allow you to "execute COMMAND ARGS ... in an older version of Guix", not downgrade it? <unmatched-paren>Pretty sure you have to do ``guix pull --allow-downgrades'' for that. <mbakke>PotentialUser-26: you can try 'guix pull --commit=3a84b4ec4c' to confirm whether it is related to the merge <mbakke>that is the last commit preceding the merge <mbakke>if that succeeds, we have some bisecting to do <PotentialUser-26>I have to read the topics in the docs. Never used time-machine before. Sounds like a chance to learn something <PotentialUser-26>nashdidan[m]: if it has 4 GB RAM and is 64bit it should be fine. But for now you better have an underlying OS running on the PI and just use guix as package manager. <PotentialUser-26>I could boot GUIX directly on my PI400 but it was barely usable due to missing drivers. Textmode was working <PotentialUser-26>nashdidan[m] And depending on the packages you need, it takes sometimes overnight to build something like sbcl or emacs-next <linj>cyberkefir: that mirror of sjtu is under maintenance, should be online near the end of this month <PotentialUser-26>nashdidan[m] The Pinebook Pro experience is much nicer, but not even compares to x86 <nashdidan[m]>I see... not something I'd like to spend time doing... but I'm using it as a <nashdidan[m]>"headless" home server, practically, so it only needs to be able to see the usb <PotentialUser-26>I just play around on PI because its in the living room, fanless and always on. For exploring guix home and other functionality its fine, though. <PotentialUser-26>I wonder if I can cross compile from x86 to aarch64 and publish it somehow to a self hosted substitute server. Compiling on aarch itself is not fun. <antipode>PotentialUser-26: You can do so with 'cuirass'. <antipode>ci.guix.gnu.org already does some cross-compilation. <antipode>Alternatively, it might be possible to do more cross-compilation on ci.guix.gnu.org. <antipode>(I don't know how to ask Cuirass for cross-compilation, but it's done somehow in gnu/ci.scm) <cbaines>if you want substitutes for aarch64, do make sure you're using bordeaux.guix.gnu.org, as that has more natively compiled and cross compiled things than ci.guix.gnu.org <PotentialUser-26>antipode: That would be a nice topic for a cookbook entry. In the company I work for at least one colleague also sees the benefits of guix and we have some arm machines, but it would be nice to have more control about the packages we need to build <PotentialUser-26>mbakke: The commit you gave me worked with guix pull --allow-downgrades. Building package cache is fast again <mbakke>PotentialUser-26: can you file a bug report? <PotentialUser-26>mbakke: When I run guix pull again, it should try to update to the latest version of guix again, right? If it fails again I will file a bug report. I even might try to bisect, but it will take time, because this machine is very slow and it takes upto 30 min for one run <civodul>mbakke: congrats on the 'staging' merge! :-) <mbakke>civodul: thanks! I messed up aarch64 though :-) <civodul>mbakke: oh! i haven't fully caught up <PurpleSym>Do we have an example on how to use gexp’s in service configurations? I’m trying to write a service file for acpid, which expect config files with event/command info. This is what I have so far: https://paste.debian.net/1257374/ <cbaines>PurpleSym, I think all the services in Guix use gexps in one way or another. Do you have a specific thing you're trying to do? <antipode>PurpleSym: in 'acpid-files', you are appending a string to a G-exp: <mbakke>civodul: cbaines reported that rust fails on aarch64, and PotentialUser-26 reports that package cache generation fails <mbakke>might need an emergency staging round :-) <antipode>(format #f "..." ... #~(identity #$(file-append ...))) <antipode>I think you need 'mixed-test-file' instead <PurpleSym>cbaines: I want to give it rules as tuples of (event command), where command could be a gexp. And then I have to write that to a file and get the union of all files. <antipode>Also, why are you wrapping (file-append ...) in a #~(identity #$...)? <mbakke>efraim: did you work on Rust for aarch64? <antipode>IIUC, you coudld just do (list ... (file-append ...)) <PurpleSym>antipode: Because I have no idea what I’m doing 😆 <PurpleSym>Ah yes, mixed-text-file does the trick. Thank you very much! <PotentialUser-26>mbakke: Thats strange. sudo -i guix pull worked, but as normal user it stalls <civodul>mbakke: i don't think Rust worked on aarch64 pre-merge, did it? <PotentialUser-26>civodul: Did not work for a long time. Sad, because ripgrep and fd-find are not available then, too. <cbaines>civodul, I think the previous staging merge got it working <apteryx>how can I test bash completions in 'guix shell'? <sneek>apteryx, you have 2 messages! <sneek>apteryx, rekado says: oh wow. I don’t know if it existed back then. Last I remember is that it was merely a copy of a binary bazel distribution with a bunch of third-party jars that was only good for downloading a new bazel. <sneek>apteryx, rekado says: if you actually have a working bazel build that would be wonderful! Building a newer version of tensorflow would still be very challenging (because bazel needs to be convinced not to download *everything* from the internet), but it would at least be possible. <antipode>apteryx: Maybe you could do ". location-of-bash-completions" to load them? <civodul>cbaines: this patch of yours talks about the status before yesterday's merge, right? <cbaines>it looks like there has been some work upstream to fix the aarch64 issues in mrustc <cbaines>so maybe there's a path to make the same bootstrap as x86 uses work <cbaines>otherwise, maybe we could go back to how it was previously <apteryx>OK! I always forget how the magic works <civodul>yeah, i have no idea what changed actually <PotentialUser-26>mbakke: I might have found the problem with the package cache build. It was probably related to my channels.scm file. I have to examine this a little more, but without channels file it works as normal user too <GNUtoo>unmatched-paren: thanks a lot, I'll try <GNUtoo>09:01 < unmatched-paren> GNUtoo: why not do something like (append (if foo? (list (service ...)) '()) (list ...))? <GNUtoo>It was for my issue of not finding a clean way to do (if foo? (<service 1 definition>) (<nothing>)) <GNUtoo>btw, what is the best build-system for shipping a script that has no build system like autotools ? <GNUtoo>is the copy-build-system the way to go? <GNUtoo>(the files are not executable by default, and I need the file to be executable) <GNUtoo>btw, for some reasons #58484 is still open <apteryx>rekado: re bazel, this runs and passes a hello world self test: https://paste.debian.net/1257384/. There's one TODO left, if you'd like to help (review the sources), and probably it needs to be wrapped with a few core tools <unmatched-paren>Well, if it has a makefile but no autotools, you can still use gnu-build-system, you just need to delete the 'configure phase. <unmatched-paren>Is it just a bunch of scripts or whatever that only need to be installed? <GNUtoo>no Makefile, it's just a script that I wrote and that I want to package to use it, I'll try to publish it to the mailing list once I get my mail setup back <GNUtoo>And I've more scripts like that that I use (that are not necessary useful for the mailing list though) <unmatched-paren>If it's a shell script, you'll want to patch it to refer to the programs it calls directly. <apteryx>rekado: err, I spoke too soon, the self test doesn't pass yet, in the build container <GNUtoo>I did that for #!/bin/sh but it's more for shipping it, if I use #:install-plan and copy-build-system for installing it I get a file that is not executable <GNUtoo>maybe I need to chmod it, but I'm not sure what the best way to handle cases like that is <GNUtoo>(I looked for examples in the guix source code but I didn't found any, and looking with grep by hand is tedious) <unmatched-paren>GNUtoo: use (chmod (string-append #$output "/bin/foo") #o777), I think... <GNUtoo>ah #$output, that was probably the thing I was missing <GNUtoo>I had a version with gnu-build system, delete build, configure and replace install where I was struggling with refering to outputs, so I'll try that there <GNUtoo>I used substitute* for the #!/bin/sh, chmod on the file, and install-file where I install the file to the output <unmatched-paren>which is the function used by gnu-build-system's patch-shebangs phase <unmatched-paren>GNUtoo: you'll also want to replace, e.g. ``ls'' with ``(search-input-file inputs "bin/ls")'' <GNUtoo>Well here there are only 2 commands, one is 'cd' and the other is guix shell [...] <GNUtoo>Without patch-shebang it works fine (I use gnu-build-system) thanks a lot <civodul>janneke: congrats on the Mes release! :-) <unmatched-paren>Hmm, so, home-mako-service-type nearly works, but it's failing to connect to the Wayland display. <unmatched-paren>So that they aren't exposed to environment variables (e.g. WAYLAND_DISPLAY)? <unmatched-paren>If so, is there some way I can expose external env vars to services? <GNUtoo>I don't know how services run, but the only way I found to set global variable was to modify the variables service inside guix source code <GNUtoo>More precisely the service that generates /etc/environment <GNUtoo>So I would guess that they are isolated somehow <unmatched-paren>Since it's set when Sway launches to the name of the Wayland socket file. <GNUtoo>Maybe making a service that output the content of 'env' in a file could tell <GNUtoo>I was thinking of system services <GNUtoo>for home services it would make sense to be able to use some of the environment, for dbus for instance <GNUtoo>redshift also need some way to talk to wayland <GNUtoo>synopsis: Adjust the color temperature of your screen (with Wayland support) <gnucode>hey guix! I am trying to set up some simple tests for my opensmtpd service records. Currently whenever I run "make" on guix source, my newly written tests are being run directly. I'm not sure how to NOT do that. And it would be nice to get make check-system TESTS="mail" to work. <unmatched-paren>GNUtoo: problem here is you can't just start a Wayland server on boot <GNUtoo>The manual has more infos on that, but basically home services don't start magically <GNUtoo>I think they start once you start a shell <unmatched-paren>So I think this means that any service that runs on Wayland can't possibly work with guix services <GNUtoo>They can, but the question is if it can work out of the box or not <GNUtoo>With wayland too you can make sure that the desktop environment source things <GNUtoo>"Guix Home will always create ~/.profile, which contains the following lines: " <GNUtoo>so what I said is valid only for shell services <GNUtoo>else it can use sheepherd apparently <GNUtoo>"A home service is not necessarily something that has a daemon and is managed by Shepherd (see Jump Start in The GNU Shepherd Manual), in most cases it doesn’t" in the next section <GNUtoo>But the best way would just be to test it <GNUtoo>like make a service that spawn env and that writes to a file <GNUtoo>And depending on the home service type that could lead to different results <unmatched-paren>The problem, I think, is that home services inherit all the variables that user shepherd does, but WAYLAND_DISPLAY is not inherited by user shepherd. <GNUtoo>ok, can that be gathered somehow? <GNUtoo>I get wayland-1 and wayland-1.lock <GNUtoo>Though I'm not sure what's the best way to get it <unmatched-paren>There's no way to know what WAYLAND_DISPLAY is set to without examining WAYLAND_DISPLAY <GNUtoo>like if it looks that it works, I'm not sure if it's actually supported to do that, if it is, it should be fine <unmatched-paren>You can't scan that $XDG_RUNTIME_DIR, since you don't know which files are Wayland sockets. <GNUtoo>The issue is also how to support corner cases transparently, like multi-seat or multiple sway sessions for the same user <unmatched-paren>I suppose I'll just do this as a configuration file service, without actually running the daemon. <GNUtoo>did you try getting WAYLAND_DISPLAY within a home-shepherd-service-type? <GNUtoo>(define (redshift-shepherd-service config) <GNUtoo> ;; FIXME: This fails to start if Home is first activated from a <GNUtoo>So it seems that there is no support for wayland somehow <unmatched-paren>GNUtoo: Yes, and it's even worse with Wayland, since there's no way to start a headless "Wayland server" as root. *GNUtoo needs to remember how he enabled guix by default on Parabola in graphical applications <GNUtoo>Maybe I modified /etc/environment or something like that that can't be modified like that in guix <GNUtoo>maybe /etc/profile.d was sourced there I'm not sure <GNUtoo>Somehow with Xorg /etc/profile.d/* was sourced <GNUtoo>Maybe it was done by the display manager like gdm / lightdm, etc <GNUtoo>I'm not sure how it works in Guix, but maybe there is a way through that <GNUtoo>So basically it relies on systemd <GNUtoo>There are also gdm specific things that don't rely on systemd but I guess that other dm don't use that as well <GNUtoo>For redshift At boot it's not started but if I do 'guix home reconfigure home-configuration.scm' it's started <GNUtoo>A quick fix could be to somehow modify the service that generates /etc/environment to be able to source some other files and ship files there with services <GNUtoo>Or somehow use that to make things work <GNUtoo>PULSE_CONFIG=/etc/pulse/daemon.conf <GNUtoo>PULSE_CLIENTCONFIG=/etc/pulse/client.conf <GNUtoo>There there are things related to pulseaudio anyway ^^^ <GNUtoo>hmmm, bad idea, there would be security issues, we'd need something like that for users in general <GNUtoo>Basically like what systemd does <GNUtoo>(the issue is that we have several daemons (at least 2) for that like elogind and seatd) <GNUtoo>unmatched-paren: Something is strange because I if look at shepherd running at user through grep -a --color WAYLAND /proc/7771/environ it already has WAYLAND_DISPLAY=wayland-1 now <GNUtoo>So maybe it acquired it later on when I ran guix home reconfigure <GNUtoo>I'll do more tests after rebooting (way later) <GNUtoo>Personally I'm interested in getting redshift run automatically so I do need that somehow <GNUtoo>I also need to set some variables to make some software work <GNUtoo>(And it'd be great if I don't need to use a shell to launch software that need variables exporting) <nckhexen>unmatched-paren: I didn't explicitly say it, so: thanks! Soon, all the old familiar bugs will be gone, and we'll have to come up with new ones. <sneek>Welcome back nckhexen, you have 1 message! <nckhexen>Okido. I thought you might object to ~% for some (translation?) reason, but it's common in Guix already. <unmatched-paren>Nope, I just didn't realise you could use format specifiers with report-error et al. ***Dynom_ is now known as Guest9276
<GNUtoo>unmatched-paren: after a reboot, the user sheepherd isn't launched automatically, so that may explain the issue <GNUtoo>So the question now is where and how to launch it <GNUtoo>And if done correctly, it'll inherit WAYLAND_DISPLAY and it'll be able to launch redshift and so on <rekado>the haskell compiler in GHC 4 still segfaults and I don’t know why. <rekado>tried to build it with -g to keep debug symbols, but gdb doesn’t see any symbols <rekado>I wonder if that’s due to a format mismatch (we’re using GCC 2.95 after all) ***mark_ is now known as mjw
<apteryx>I thought jquery was one of the 'foundational' js packages, hence I hoped they'd had been immune of the zillion dependencies syndrome <apteryx>also, I see some packages pulling jquery or flavor of it as input. not sure why that's OK. <podiki[m]>and sizzle is also just one file meant as standalone I think....but I know nothing <lilyp>apteryx: there's no "why", if you're the first one to notice that then please tell others :) <podiki[m]>oh, jquery.js is the compiled file? (but is also source; i have no idea how the js ecosystem workds) <podiki[m]>what does that mean exactly, if the "compiled" library is still a readable source file, what counts as building from source then? if it is generated code but still just code....? <apteryx>js is source (until there was wasm), but it is typically "built" into a minified version (still js, but unreadable) <dthompson>it's still a compilation artifact. to qualify as source it would have to be the preferred form for editing the software, which a concatenated js file, minified or not, isn't. <apteryx>lilyp: one example is r-leaflet, which lits a bunch of js inputs, including js-query <dthompson>at least it's a nonminified version. we could live with that. <podiki[m]>dthompson: thanks, that is a good working definition that maybe avoids some "philosophical" considerations :-P <mroh>we even have a plugin for jquery: js-datatables ;) <podiki[m]>should we allow non-minified js more generally? or single file js? <dthompson>podiki[m]: np. once I was told that definition it's been pretty easy to answer the "source or not?" question. with that baseline, it's easier to talk about any potential compromises. <podiki[m]>(I don't that we have a strict definition now, beyond the guiding principles of free and from source) <lilyp>no, since they are by definition not source <podiki[m]>dthompson: I like it; i'm sure there are still nuances, but I think that makes a good starting point <podiki[m]>lilyp: what is? single file non-minified js? <podiki[m]>why exactly? you can't just write js in a file and work with it like that? (I don't use js at all) <podiki[m]>(actually did use parenscript once for a very little bit) <PotentialUser-36>Hi, I just successfully installed Guix using systemcrafter's image (with nonguix kernel), and it loaded successfully to gdm. After installation, I was experiencing some delays when I was typing characters in a terminal in i3. Also in Gnome, window movement where so slow. I tried adding Xorg driver configuration based on this link <PotentialUser-36>Authentication is needed to run `/gnu/store/wxlj28cqypx6ws8swq6612xky8271ilj-xf86-video-intel-2.99.917-18.31486f4/libexec/xf86-video-intel-backlight-helper' as the super user <dthompson>when it comes to javascript we should probably be a little more relaxed about it since the situation is *so* bad overall. <PotentialUser-36>where of course it is not reacting to anything I type. I can switch to other tty and reconfigure the system. Wanted to know if anyone experienced this error before? <rekado>I added a couple of non-minified JS things (mostly for R packages), as long as they are mere concatenations of source code. <rekado>they may not be the preferred form for editing, but they are a very usable form nonetheless. <rekado>bah, I’ve built GHC 4 countless times and I still can’t get past the segfault <rekado>all I know is that it segfaults in putMVarzh_fast <rekado>the definition is probably the one in ghc-4.08.2/ghc/rts/PrimOps.hc *rekado builds the damn thing again with -optc-g added to the RTS compile flags *jonsger admires rekado 's persistence :) <dave>i installed guix with qemu. Then i do: <dave> - sudo cp /mypathtoconfig /etc/config.scm <dave> - sudo guix reconfigure /etc/config.scm <dave> - Bad magic number in super-block while trying to open /dev/vda1 <dave>Anybody any idea what i did wrong? I just want to do my first config. <apteryx>how does java finds other libraries in Guix? <apteryx>seems it's generated by the java build systems <apteryx>(setenv "CLASSPATH" (generate-classpath inputs)) in configure phase of ant-build-system for example <itd_>rekado: Out of curiosity: would it make sense to git-bisect the segfault? (Assuming git, a known good version, and probably more.) <apteryx>not sure how it survives passed it; it's probably baked in the built artifacts, but unzip -p $(guix build java-picocli)^Chare/java/picocli.jar | strings | grep CLASSPATH turns nothing <civodul>apteryx: ISTR there's a "manifest-inf" file or something in jars, and that contains metadata including possibly a search path <apteryx>is the daemon able to scan references properly for that? <apteryx>picocli may be a bad example; no CLASSPATH, no manifest-inf <civodul>not sure what the exact file name is <apteryx>java-common pool has: /tmp/common-pool/META-INF/MANIFEST.MF <apteryx>and that's another bad example, since it has no dependency :-) <civodul>i had to do a bit of Java at school but that was *ahem* some time ago <apteryx>ah, /tmp/common-pool/META-INF/INDEX.LIST has /gnu/store/n80rlj3bd3767qp3ql3pf0vpc5nhzvy4-java-commons-pool-2.6.2/share/java/common-pool.jar <apteryx>but I don't find a ref to java-cglib from java-commons-pool <apteryx>another example: java-commons-dbcp has 3 java inputs, but 'guix size java-commons-dbcp' only lists itself *apteryx checks our known java bugs <apteryx>so grafts wouldn't currently work at all for java libraries, right? <efraim>I'm about to give up for the night on building gcc-2.95 for arm. the differences between armv4t and armv7 seem pretty big <apteryx>I don't even see how java libraries can work currently (where they depend on other java libraries) *civodul looks for members of the Java team, finds roptat <dave>It is just the standard config of the image for qemu, i just wanted to start by copying the config and then restarting in my new config without changing anything. <dave>tricon The only thing i really changed from the standard config is changing my keyboard layout to dvorak. <rekado>itd_: must be a CVS / darcs to git conversion <rekado>itd_: it’s interesting but I don’t think bisect is going to be as useful here as it would be in a modern repo. We’re constrained by ancient versions of the toolchain and libraries. <rekado>civodul, apteryx: generate-jar-indices explicitly mentions grafts <apteryx>hm, so it doesn't seem to work in the eaxmple I used in #58591 <apteryx>the INDEX.LIST only refers to itself <rekado>axoloti-patcher’s Axoloti.jar refers to java-simple-xml and nothing beyond that <rekado>I don’t think this is working as advertised