*tschilptschilp23 finally managed to migrate to libera <Kabouik>phodina[m] I am sorry, I submitted a patch to add rot8 and only later found out that you submitted an earlier version somewhere last year (it was probably forgotten as I think it was ready for inclusion) <Kabouik>Hopefully with the new patch submission, one of them gets merged. <Kabouik>I see that you have worked towards updating i3status-rust in the past. I am trying to update it to 0.22.0 because the version we have is more than a year old and lacks important new features (distinguishing left and right click for instance). It requires updates for rust-inotify (0.10) and rust-maildir (0.6), and I got those working, but I'm still failing to update i3status-rust itself. It now needs neli-wifi which is not packaged at all as of now. <Kabouik>I will probably just give up for now. I'm not sending the patches for updating rust-inotify and rust-maildir because I am not sure of the added value of those except from building i3status-rust. But if by any chance you want to give i3status-rust a try and need those updates, I'm happy to send them. Just ping me. <Kabouik>Re: jpoiret: so just use the usual login shell files > I still haven't figured out which files I could use to set env variables when I start Swaywm from GDM. Did you have any file in mind? ***maximed is now known as antipode
<oriansj>Kabouik: well just a thought but ${HOME}/.config/sway/env <pkill9>does anyone know how to pass a package manifest to the guile code for the `guix environment` command? <pkill9>I want to make a script that takes the packages and wraps them and goes into a guix environment with them <Kabouik>I tried profile but that didn't work oriansj. I'.. try ~/.config/sway/env. Is that a file, or a dir? `export VAR=blahblah` would be the correct syntax? <Kabouik>And I'm sorry for the many typos. I'm swinging from a full-size keyboard to a 8" device (the actual Guix UMPC, starting to be a pretty neat machine now that my system is better configured), my muscle memory is not at its best. <oriansj>Kabouik: it would be a file that you source in which you export variables <Kabouik>If I source it manually, GUI apps like Icecat won't inherit env variables in it, will they? <oriansj>Kabouik: not unless you do it sideways. in a termal start the gui application or your app launcher <Kabouik>Yeah, that's is what I currently do but it is not elegant. I am looking for a way to have some variables exported for my whole session whenever I start Sway. This was straightforward in Xorg or in non-guix Systems, but the combination of Guix and Wayland somehow makes it not trivial. <Kabouik>Typically I need to use MOZ_USE_XINPUT2=1 to enable touch-scrolling in Icecat. I could of course edit the .desktop file but that's not very Guixy, and there are a couple other variables I would need that would be useful outside of the shell. <oriansj>I take it you use a login manager like gdm3 <Kabouik>I will try that oriansj, thank you. I was hoping there would be a "standard" way of doing that without altering desktop files since this is not very reproducible, but doing that on Sway's desktop file is a much better idea than altering other GUI apps I need the variables to be visible to, thanks for the suggestion <Kabouik>(If I can find Sway's desktop file). <oriansj>find / -iname '*.desktop' -print 2> /dev/null <Kabouik>Oh, it's in /gnu/store/blarb-sway/share only apparently, I was expecting it in ~/.guix-profile/share/applications. But I guess it makes sense that a WM is not in a user profile ***taiju is now known as Guest1700
***taiju` is now known as taiju
<Kabouik>Then again I face the same issue I faced a few days ago: everything is readonly in /gnu/store, and in ~/.guix-profile/share/applications where I wanted to put the altered copy of sway.desktop. <oriansj>Kabouik: if you do ls -hal / do you notice a /usr? <Kabouik>Yes, but I thought it was either (1) useless to Guix or (2) just clutter from some C programs I have make install-ed earlier. Do you recommend to put the altered sway.desktop in good old /usr/share/applications/? <oriansj>Kabouik: guix does many great things but changing out hard-coded logic is rarely one of them. <oriansj>what is the worst that can happen if it doesn't work? <Kabouik>Heh nothing really, I was just seeking advice on what would be the best way to do it in Guix. If that's the answer, I'm happy with it! I'll give it a go tomorrow oriansj, thank you very much. <the_tubular>I think podman is bugged since 38086675738c93ba1ad9fd81d3257a9cf74f0597 ***taiju_ is now known as taiju
***taiju` is now known as taiju
<ulfvonbelow>alright, so apparently what I was seeing with ungoogled-chromium before was --thinlto-cache-policy=cache_size=10%:cache_size_bytes=40g:cache_size_files=100000 <ulfvonbelow>so it's actually just saying to use up to 40GB of disk space for the link-time-optimization cache, which apparently is used for speeding up incremental rebuilds. Which, of course, are never used in guix, since it gets rebuild from scratch each time. <ulfvonbelow>I wonder how it would work to split ungoogled-chromium into two packages, one that just generates tarball containing /tmp/guix-build-ungoogled-chromium.drv-0 in a post-build but immediately pre-install state, and another that takes that, applies any changes to ungoogled-chromium that have occurred between then and the latest packaged version, and tries an incremental rebuild, then installs that. <zamfofex>Then you’d have to keep definitions for previous versions around, though, no? <apteryx>phew, libsoup2 -> libsoup3 in GNOME reminds me of of the great python2 to python3 migration <ulfvonbelow>nah, the idea is that the second-phase package just modifies the files in the saved build directory that actually got changed, then lets the build system rebuild only those. Newer versions just do the same on top of the same saved build directory, but with newer source to update to. Eventually enough of the source would have changed that it'd be worth it to just bump the phase-1 build source. You'd keep the definition for the phase-1 <ulfvonbelow>package and a single later version, occasionally bumping up the phase-1 package to the later version. <ulfvonbelow>welp, after 16 or so hours the ungoogled-chromium build failed due to running out of memory. I guess 8GB RAM and 10GB swap wasn't enough. Gonna have to make the swapfile bigger... <sneek>civodul, you have 2 messages! <sneek>civodul, rekado says: woo, a new shepherd release! <civodul>/me is running Emacs with native compilation *civodul is running Emacs with native compilation <kitty4>Is there any quick and dirty way to attempt to just install/upgrade a package from a newer version than what is on the repository or would you have to just deal with copying the whole package and manually changing it to a newer version? <ulfvonbelow>guix build --with-source=somepackage=<url of newer version's source> <ulfvonbelow>I don't think there's a --with-version, as other package fields are often computed from the version <jpoiret>Kabouik: depends on your login shell <jpoiret>.bash_profile or .zprofile are good guesses <Kabouik> Hi jpoiret. Is GDM considered a login shell? So far I have tried ~/.profile, ~/.bashrc, and tewaking sway.desktop and putting it in /usr/share/applications, but no dice. I was about to just prepend the variable to my application launcher (sway-launcher-desktop) command, but I'm not too satisfied with the fact that it'd be tied to that launcher only <jpoiret>i'd say you need to try .bash_profile and .zprofile, depending on your login shell (bash and zsh respectively) <jpoiret>i wrote the code that leads to wayland launchers being launched through a login shell, exactly for this reason (this was why wayland GDM was unsupported on Guix until last year) <Kabouik>If there is a better solution that using GDM, I'm happy to try too. I have no particular preference for it, it's just what was there by default and someone shared theyr config file to show me how to enable Wayland in it. I like the option to start other WMs from there without knowing the command lines though, that can be useful for debugging sometimes. <jpoiret>you should look into greetd, that's what I'm currently switching to <Kabouik>I see that unmatched-paren submitted a patch for greetd-wlgreet too, but I don't know yet what are the implications in the config.scm for the change, I'll look for examples later <Kabouik>I must say tuigreet looks appealing to me. ***taiju_ is now known as taiju
<kitzman>Is anyone getting complete system freezes with particular qt apps on wayland? <efraim>kitzman: It happens to me sometimes, but I'm pretty sure it's enlightenment that's crashing on me. <kitzman>I would have hoped for a sway crash, at least. Ill try rebuilding the thing with an older or a newer version, ill see <Kabouik>unmatched-paren: about Iosevka font, I recommend using the Iosevka Term variant; I realized today that the regular Iosevka has some characters wider than the others (like ellipsis). This is intended, but Term fixes that. <Luk6655>let's say I would like to update the Linux kernel version on guix os, in my /etc/config.scm I don't define a specific kernel. Will my kernel version be updated if I just do guix pull, guix system reconfigure? (assuming there is a newer kernel in the guix repo) <tschilptschilp23>Luk6655: I pulled and reconfigured yesterday as you describe and it brought me kernel 5.19.8, which is pretty new. You will need 'sudo' for the system reconfiguration. I typically do a reboot afterwards to have the kernel picked up, but there might be smarter ways to do so... <jpoiret>tschilptschilp23: apart from kexec (warranty's off), you'll need to reboot yes <rekado_>Kabouik: make sure to delete old generations too, or else gc cannot collect much garbage. <rekado_>(I haven’t run “guix gc” in months.) <civodul>overdrive1.guix has become extremely slow, even when idle <Kabouik>That would be `guix pull -d` rekado_? <rekado_>civodul: I can relate. Maybe it’s just tired :-/ ***taiju is now known as Guest3359
***taiju` is now known as taiju
<examors>tschilptschilp23: you can add `modprobe.blacklist=modulename` to the `kernel-arguments` field <jpoiret>tschilptschilp23: you should pass kernel arguments to do so <antipode>Has someone been looking into updating our gnunet to 0.17? If not, I'd like to give it a try. <podiki[m]>woop looks like the matrix bridge is operational (or at least seeing libera messages coming through today) ***rgherdt_ is now known as rgherdt
<apteryx>hmm, I have a package with "#:disallowed-references `(,libsoup)", yet it retains a reference to /gnu/store/jxk2b6hlahc2s3bwanmw1zn9dji3bga0-libsoup-3.1.4. What am I doing wrong? <tschilptschilp23>Somehow it keeps bothering me, that kernel 5.19.8 brought in some changes, that seem to make battery-readings dysfunctional on my Fujitsu A357 laptop (/sys/class/power_supply/BAT1/status states 'not charging' constantly and /sys/class/power_supply/ACAD/online keeps 0 or 1, depending on whether the power supply was plugged in on boot or not). I know that I can pin the exact kernel version by using inferiors. But if I don't confuse <tschilptschilp23>things, 5.15.x and 5.10.x stayed available for quite a while over the various guix versions. How would I tell my system to stay with, say the '5.15.x'-kernel-series? <antipode>tschilptschilp23: Do you know if this has been reported to the linux people? <antipode>Linux has a strong focus on backwards-compatibility, (sometimes even when a bug is in the dependent, in userspace) <antipode>tschilptschilp23: Set the 'kernel' field of operating-system <antipode>If you do "guix edit linux-lobre", you'll see that a bunch of variants are defined <tschilptschilp23>antipode: mhm, I've seen some reports by arch and fedora users running into this as well (partly with way newer hardware than mine). I cannot tell if it's been reported towards linux, they seem to switch to the 'lts'-kernel version to solve the problem. <antipode>tschilptschilp23: Have these arch and fedora users reported it to their distro? <apteryx>would '#:disallowed-references' guard against the reference appearing in 'guix gc -R' ? <apteryx>tschilptschilp23: agreed that finding a report or making one would be in your best long term interest :-) <antipode>I mean, eventually the 5.15 series and -lts will become unsupported, short-term it's ok but the linux people really need to know about it, the earlier the better <apteryx>but otherwise there seems to be a linux-libre-5.15 variable. not sure how long it'll stick around. <antipode>More precisely, it should make the build fail if a reference appears <apteryx>antipode: it doesn't for some reason... I must be doing something wrong. <antipode>Which package is this, what branch, which --system/--target, with/without --no-grafts? <antipode>There are a number of package variants of libsoup, so I'm wondering if you have a variant of it in inputs/native-inputs/propagated-inputs and another version in #:disallowed-references <apteryx>antipode: can't easily share a reproducer, as the branch I'm working on has accumulated a lot of GNOME changes <apteryx>but it's gnome-maps, which knows libsoup@3.1.4 through folks -> evolution-data-server -> libsoup <apteryx>(guix graph) shows that. and grepping the 'guix gc -R' build output shows references to libsoup 3 <antipode>apteryx: I think that #:disallowed-references is only about the references of the package that is built, without regard to the references of its inputs (i.e., no transitivity) (unverified) <zamfofex>Try verifying whether the ‘libsoup’ variable refers to the same ‘libsoup-3.1.4’ that is being referenced. <apteryx>yes it does, there's only one libsoup at 3.1.4 on my branch <antipode>Also, at least on master, "gnome-maps" has libsoup-minimal in inputs, but you are adding libsoup to #:disallowed-references <apteryx>yep, even at 42.3 gnome-maps wants libsoup 2 things <apteryx>mixing libsoup 3 in causes a run time error, so I want to avoid that <tschilptschilp23>It's all guessing from my side, as people are using very different hardware from mine (mainly sounds much newer) -- and possibly my battery sensor really burned yesterday evening for some reason. <tschilptschilp23>I'd be happy if I'd use an asus laptop, then I could blacklist the module ;) <Kabouik>tschilptschilp23, out of curiosity, have you tried with `upower` installed? I have been having issues with my battery monitoring before I installed it: the value was only getting refreshed at reboots (plugging/unplugging was properly reported dynamically, though). <Kabouik>Since I installed upower, monitoring of battery level just works. <tschilptschilp23>Kabouik: did you put it into config.scm? I just installed it using 'guix install upower' to get somewhat more information, but this didn't have any effect.. <antipode>tschilptschilp23: Possibly Fujitsu and ASUS have the same battery thing, or the ASUS driver accidentally tries to act for a Fujitsu battery or such. <antipode>(I mean, an amendment to my previous reply, not a response to Kabouik) <tschilptschilp23>although upower queries does at least report charging cycles, which correspond, what my BIOS tells me! <ulfvonbelow>does running the "configure" phase of build systems usually make it so that the "build" phase, when next run, will build from scratch (disabling an incremental rebuild)? <ulfvonbelow>(not really a guix-specific question, just wondering about build systems in general) <antipode>Are you referring to the 'configure' and 'build' phase? <tschilptschilp23>yes, with my previous generation (kernel 5.18.16) all is fine, immediate response to plugging in/out, battery percentage as expected. <antipode>If so, note that (usually?) there is only ever a single 'build' phase per package. *tschilptschilp23 is very fond of guix' roll-back feature <antipode>It's less 'building from scratch again, disabling incremental rebuild' and more 'looks like it isn't build yet, let's do it'. <antipode>Also, if you don't want things to be built again, why did you run ./configure again? <ulfvonbelow>the use case I have in mind is saving a built work tree for a massive package as a tarball, then having another package use it as an input, effectively "edit" its source using rsync, then do an incremental build. But the output directory, working directory, etc for the later package would of course be different than the one it was configured for. <ulfvonbelow>the hope is that hopefully it would be possible to do a configure that only changes the install prefix, basically, and most things wouldn't need to be rebuilt from that <apteryx>make install PREFIX= should be a thing with autotools, I think. <tschilptschilp23>on the newer kernel also closing my laptop's lid does not shut down the built-in monitor as now (what I actually want, as most of the time it's closed). <tschilptschilp23>(I had to set gnome's display settings to mirror mode, what I don't really like) <antipode>ulfvonbelow: I've heard that 'ccache' can avoid lots of recompilation, to me it seems like this is a similar situation <antipode>(this is assuming the massive package consists mostly of C or C++) <zamfofex>civodul: Thank you for taking a look at my issue regarding the missing ‘inherit’. Also, thank you for founding work on Guix, by the way! Sorry if I come across as annoying or otherwise too demanding, by the way. I just want to help and create something people can appreciate in some way or another. <Luk6655>I'm writing a package build stage and I'm getting a generic excecption about "unbound variable" in that phase. Is there some way I can narrow down where (which line etc) this exception is thrown? <Luk6655>the exact error is "Unbound variable: ungexp" and the backtrace is not much help either <jpoiret>did you remember to use-module (guix gexp)? <jpoiret>also, don't locally bind anything to gexp <Luk6655>no I haven't used module guix gexp, perhaps that's it <Luk6655>In general sense is there something one can do to try locate such errors in the source (other than randomly plugging (display "no error yet") statements? ***wielaard is now known as mjw
<Luk6655>that's not it, I have few other things to try. <Luk6655>I think guile needs an ability to be able to exactly tell where an exception occurs in the source. It is one of most basic troubleshooting features... unless I'm missing something? <antipode>At least, in compiled mode, not interpreted mode. <KarlJoad>Quick double-check, is the Guix daemon implemented in C++ (inherited from Nix), or is it re-written in Guile? <Luk6655>antipode: It needs it in interpreted mode too <antipode>Luks6655: it is indeed needed in interpreted mode. <antipode>a I wrote previously: ‘At least, in compiled mode, not interpreted mode’ <antipode>in compiled mode, it is not already the case. <Luk6655>ok, well, hopefully it get's added at some point(in interpreted mode) <Luk6655>can you use compiled mode for guix build? <Luk6655>specifically guix build my_package_name ? ***Dynom_ is now known as Guest8581
<antipode>Sure, this is already the case to some degree. <antipode>Line information is already available for guix/build/*.scm <zamfofex>KarlJoad: It is still implemented in C++. <antipode>However, line information is _not_ available for phases! <antipode>That's more a Guix problem than a Guile problem, though. *antipode searches log for old discussion <Luk6655>it makes writing those phases an exercise in frustration... unfortunately, it is only a detail, but it would be massively helpful <antipode>Short explanation of the problem: if we just passed the line information to the build process (to produce a nice backtrace when required), then we would often rebuild the world way too often <antipode>It is, in theory, sort-of solvable to a degree (see: the old discussion on logs.guix.gnu.org), but complicated and unimplemented <antipode>Luk6655: Do you have an example backtrace + package definition (paste.debian.net) <antipode>I wonder if 'something' could be done to improve things but doesn't require line information <ulfvonbelow>so I ran a 'guix build ...' with --quiet because I didn't want it flooding my emacs shell buffer, and now it's telling me that the derivation that failed to build has no log file. Does --quiet keep it from producing a log file? <Luk6655>antipode: I need to figure this one myself\ <KarlJoad>zamfofex: Do you know if that is for performance reasons, or compatibility, or what? <zamfofex>KarlJoad: I think it’s just that no‐one took upon converting it to Guile yet. <Luk6655>regarding the line number problem, how about only enabling them for unhandled exceptions? <Luk6655>or, if some switch is used during the run <antipode>There is no such thing as 'unhandled exceptions'. <antipode>To elaborate, the build process somewhere catches the exception, then walks the stack for stack frames and prints the backtrace <antipode>A --with-line-information switch should be feasible, though (see: that discussion I couldn't find again) <Luk6655>hopefully it happens at some point to improve how new user friendly the system is <antipode>(saving the line number information would grow the .go a bit, but there were some ideas on how to mitigate that a little) <antipode>Luks6655: With ‘Do you have an example backtrace + package definition (paste.debian.net)’, the idea wasn't that I would investigate the issue for you, but rather to have a look at how ‘useless backtraces’ look like in practice <antipode>Then, if, for example, it turned out that the problem was that was hard to determine in which phase things happened, <antipode>a potential solution would be to adjust the modify-phases macro to give the lambda's a name based on the phase name <Luk6655>the error happens between (display "test1") and test2 <Luk6655>I suspect I can;t do this: " (add-after 'install 'install-copy <Luk6655> (lambda* (#:key inputs native-inputs outputs #:allow-other-keys)" in gnu-build-system <Luk6655>I've lifted that bit from a copy-build-system <antipode>The issue here, is the use of quasiquote. <antipode>In short-term, do (arguments (list #:phases #~(modify-phases %standard-phases ...) #:implicit-inputs? #f #:substitutable? #f)). <antipode>Basically, #$ (ungexp) can only be uses inside a #~(gexp) <antipode>Long-term, this is something "guix style" could be taught to do. <antipode>(I recommend doing (list #:phases #~...) instead of `(#:phases ...) for new packages, as it avoids this problem) <Luk6655>I've changed line 71 during testing, previously It had no assoc-ref at all, to be fair I had no idea how it could've worked at all, as the function definition specifies a keyword argument called outputs, and in this let* block we use output, which seems to be undefined <Luk6655>ok, so that's where ungexp came from <antipode>Luk6655: #$output is documented in the manual, close to 'gexp' IIRC <antipode>Not really easy to search for though in my experience. <Luk6655>just so I understand this fully, so by using quasiquote, we can create a list (list of pahses) that we can choose to interpret elements of if we put a comma (,) in front of the item <Luk6655>but in this bit of code we don't do that (no comma in front of any item as far as I can tell) <Luk6655>so this should be equivalent to the (list a b c), right? <antipode>You can indeed use 'quasiquote' to make lists: `(a b c). <antipode>However, no interpretation happens, this isn't eval. <antipode>You can, however, do `(,a ,b ,c), which is equivalent to (list a b c). <antipode>But this is not interpretation, but rather the 'quasiquote' macro expanding the syntax #'`(,a ,b ,c) to the syntax #'(list a b c). <antipode>What I mean is that the Guile's interpreter is not involved in this, this is just the macro-expander and the macros at work. <antipode>Luks6655: Replace the chmod with (chmod (pk source) #o755) <antipode>If it outputs /gnu/store/whatever, that means you're trying to modify a store file. <antipode>But the store is immutable (except for #$output, #$output:whatever), so you can't do that. <Luk6655>ok, I'll do that, but it didn't complain about that <Luk6655>it makes the file executable and indeed it executes fine <antipode>I haven't seen the backtrace yet, so I don't know what it is complaining about. <antipode>I've seen the 'ungexp' backtrace, but that's unrelated to the chmod problem. <Luk6655>chmod is not relevant, the problem started when I added the install-copy phase <Luk6655>antipode: indeed, I will do that, I'm just trying to understand the why's etc <antipode>unmatched-paren: I could be mistaken, please check. <Luk6655>Is the fact all the other phases are added like this: (replace 'install <Luk6655> (lambda* (#:key outputs #:allow-other-keys), while the problemating phase is added like this: (add-after 'install 'install-copy <Luk6655> (lambda* (#:key inputs native-inputs outputs #:allow-other-keys) relevant? <Luk6655>I mean in other phases we have a name of the phase followed by lambda, while here we have two names <apteryx>mbakke: I've managed to get latest GNOME anything in (gnu packages gnome) and some on master <antipode>If you replace a phase by another phase, there is already a name, the old name of the phase. <apteryx>I've cherry picked some of your commits from cu <antipode>But if you add a phase, Guix doesn't know what to name it, so you have to tell Guix what it's name is. <Luk6655>I see regarding the names now, what is it in that install-copy phase that triggers the exception? <antipode>#$ = ungexp, as documented in the manual <Luk6655>and we can't use it, because of the quasiqote, ok, I get it now <Luk6655>interesting, I didn't realise this '(1 2 <Luk6655>,(+ 1 2) 4) is any different than (list 1 2 (+ 1 2) 4) <Luk6655>I have to do something else now, but I'll try it later. Thanks for help (again) <antipode>You used 'quote' ('), but probably meant 'quasiquote' (`) <Luk6655>with quasiquote `(1 2 ,(+ 1 2) 4) returns (1 2 3 4) same as (list 1 2 (+ 1 2) 4), but I guess the macro expander is smart enough to deal with numbers etc, but is not quite the same as eval, right? <antipode>quasiquote / unquote and the macro expander don't care about numbers. <antipode>Keep in mind that `(1 2 ,(+ 1 2) 4) expands to (list 1 2 (+ 1 2) 4), and not (1 2 3 4). <imtheonewhodudes>has anyone played around with a Pinephone and guix? how did people figure out the precise image layout required to boot for example the Pinebook? <Luk6655>yes, only once it is eval'ed it turns into (1 2 3 4) <antipode>It is not eval'ed -- 'eval' is not used (unless you more generally meant ‘evaluation’). <Luk6655>yes, I meant generic evaluation rather than eval <antipode>(To be 100% precise, Guile's compiler will optimize the (list 1 2 (+ 1 2) 4) into (list 1 2 3 4), no addition happens at runtime) <antipode>Luks6655: I don't know if you know of thse already, but you can use ',expand EXPRESSION' and ',optimize EXPRESSION' to experiment with macro-expansion and to see how Guile optimises things. ***mark__ is now known as mjw
<apteryx>sneek later tell mothacehe would you know how to make the action of registering store items in the system images used by the system tests conditional to whether a guix-daemon is configured for that system (the way we do it for docker images) <sneek>civodul, you have 1 message! <mbakke>civodul: it's served from the store, no? nginx uses the mtime <civodul>mbakke: yes, but i'm not sure nginx sends Last-Modified if you don't ask it to? <mbakke>civodul: apparently it can be disabled by 'add_header Last-Modified "";' <mbakke>in other news, I have a fixes for OpenJDK on core-updates and consider the branch almost ready for merge <civodul>mbakke: BTW, congrats on the glibc+GCC upgrade! <civodul>i haven't been able to follow closely, but that's exciting <mbakke>civodul: thanks! I also have Python 3.10 + OpenSSL 3.0 patches in the pipeline, but most of the fixes are already merged so I'll probably just push them when all my manifests are passing :-) <mbakke>yay, OpenJDK 11 built without patches <zamfofex>Was there any reason for not updating glibc to the latest release from last month? I was going to send another patch, but then it got merged before I had a chance to investigate it. <mbakke>zamfofex: I tried it, it works without any changes, but some of the GNU libs needs bootstrapping with a newer gnulib (or ad-hoc patching ) ... I think we should pull it, but I want to have the branch in good shape first <mbakke>hopefully some of the offending packages get new releases in the mean time :P <civodul>i was thinking we could have Guile 3.0.9 (bug fixes) before core-updates is frozen... <mbakke>I also tried the latest binutils, but it now needs bison, causing a bootstrapping headache <mbakke>huh, OpenJDK 12 needs the same fix as all prior versions, I wonder how OpenJDK 11 avoided it! <mbakke>openjdk 11 comes from a different source; the other versions are snapshots from hg.openjdk.java.net; whereas OpenJDK 11 comes from openjdk-sources.osci.io ! <apteryx>civodul: any clue why PID 1 on berlin uses close to 10 GiB? <mbakke>and apparently OpenJDK 11 bundles a newer hotspot that DTRT wrt the problem in question <mbakke>ima borrow the OpenJDK 11 hotspot fix which is better than mine :P <mbakke>I wonder what's up with the different snapshot though <mbakke>so commit 3c60336bf2c8ea1e4b406343cda0dd11897c2f13 changed the source of OpenJDK 11 to an official release tarball instead of just a source code snapshot <mbakke>I wonder if we should find release tarballs for the other versions? rekado, roptat: thoughts? <mbakke>then we don't have to manually patch the apparently ancient hotspot that's present in the source repository, but updated in releases <civodul>apteryx: but (maybe not related) it's been respawning anonip-* every second for several weeks <civodul>i haven't had the time to fix it, though i made the first step by allowing nginx to depend on other Shepherd services <mbakke>I think we can shorten the OpenJDK bootstrap chain a bit <rekado_>bah, I’m sorry that this anonip stuff turned out to be so troublesome <rekado_>I’ve been having difficulties making time for bug fixing :-/ <mbakke>the hotspot stack size fix in OpenJDK 11 malloc's memory without freeing it. It's just a test executable, but still feels wrong :P though I'm fairly used to ignoring my feelings at this point. <civodul>apteryx: re berlin, i'm not sure what's happening, but it's a time bomb; my advice would be: (1) update berlin.scm to have nginx depend on the anonip-* services, (2) reconfigure with this change + shepherd 0.9.2, and (3) reboot <civodul>i probably won't be able to help this week unfortunately <civodul>or maybe on Wed. i can help with (1) <mbakke>that seems like a great solution, will test 
