<leoprikler>why ship separate tarballs if you need a monorepo build anyway <jlicht>gotta keep those distro packagers on their toes ;) <wirez>does guix have complete support for suspend/resume? <jackhill>wirez: and what do you mean by complete? Both more or less work for me :) <nckx>Aurora_v_kosmose: I mean, perhaps, but I wouldn't recommend it. <Aurora_v_kosmose>nckx: Hardware suspending has been broken on basically every laptop I've owned. That has worked. <nckx>wirez: Never heard of acpiconf, but assuming that's S3, yes that's supported. Doesn't really require any distro support to begin with. <nckx>Suspend to disc works, but isn't supported in all edge cases. It's strictly for people who know what it is and how it works ATM. <nckx>Which isn't a high bar, I just mean ‘how hibernation works’. <wirez>does it seem weird to anyone that 2021 suspend to disk/ram aren't rock solid? not trying to be prick <Aurora_v_kosmose>I experienced some weird crashes over the years when using that software hibernate, back on Debian when I commuted a lot. Such that I still closed most programs I cared about anyway. <nckx>People explicitly don't care. Linus explicitly doesn't care. Hibernation's heyday was 10+ years ago. <Aurora_v_kosmose>Hibernation is kind of pointless with faster disks. And that's really its only actual benefit. <wirez>why don't ppl care? it's great to shutdown and preserve run state <jackhill>I still care, but 10 years ago probably best describes me :) <wirez>not all program state is persistent tho <jackhill>Aurora_v_kosmose: what about state of my desktop session <nckx><Hibernation is kind of pointless with faster disks> How is that reasoning even supposed to work. <wirez>i dont think a system should expect it <Aurora_v_kosmose>nckx: You load the image directly into ram, without processing the usual boot sequence. <wirez>im not writing the code so im not making demands just seems like a big hole in guix <wirez>or linux in general or FOSS or whatever it is <nckx>Aurora_v_kosmose: That's hibernation. <jackhill>Aurora_v_kosmose: that would be cool. Allthough I do somethine get into the state (heh) with my browsers that I like to keep the restore the last session, but not now, so I switch to a different browser… <Aurora_v_kosmose>jackhill: Firefox does keep most/all of the state I care about in a session. <Aurora_v_kosmose>Which is also how I tend to keep hundreds of tabs around over multiple sessions but yeah. <jackhill>or, just use your workstation as a dumb terminal and keep all state on a remote server :) <jackhill>Aurora_v_kosmose: exactly, sometime, I don't want all my tabs back right now :) <nckx>Faster drives makes hibernation more relevant, but the hibernation code in Linux is deliberately neglected. That's just the way things are. <Aurora_v_kosmose>jackhill: Ah, in that case you'd require the session extensions. I used one a while ago before XUL was deprecated and didn't bother finding another one after. <jackhill>wirez: I think it mostly works, so doesn't seem like that big a hole (compared to other parts of our boot, it's a smaller hole). I just posted a patch fixing one of them. I think for hibernation we just need to think through more of the corner cases, and add logic to bail out if it would be unsafe. <Aurora_v_kosmose>nckx: It's one continuous read most of the time, which is why it's faster than going through the normal boot that does some seeking. <nckx>That's why I don't understand why you called it pointless. <Aurora_v_kosmose>I'm saying that SSDs have constant-time reading/seeking which makes it mostly not matter for boot-time <Aurora_v_kosmose>The main problem is seeking on very slow drives. Such as the cheapest laptop ones. <Aurora_v_kosmose>But those are basically being phased out if not already no longer sold with new laptops. <nckx>I still don't see the connection. If you have to clean boot, you have to clean boot. If you don't want to lose state, you still have to hibernate, what does it matter that your machine boots fast. <nckx>They are completely unrelated. <Aurora_v_kosmose>In my case, booting took significantly more time than reopening Emacs. So skipping only the conventional boot made a huge difference <nckx>(I'm sure there's some embedded manufacturer abusing a 10-year old ToI keep-image patch to ‘boot fast’, but let's ignore that person as they deserve.) <Aurora_v_kosmose>And if I wasn't working something important, I could also just leave Emacs opened when I suspended. Skipping the seek-heavy loading for both. <Aurora_v_kosmose>But on an SSD, seeking isn't really a thing as far as human perceptible timescales go. <nckx>Why would you close emacs before suspending? <Aurora_v_kosmose>nckx: I suspect that either the memory or disk of that laptop was unreliable, or I was running into an edge-case, but I noticed that after a few suspend/reload cycles, it got a lot more likely to crash for no perceptible reason <podiki[m]>is python-pyyaml failing to build for anyone on core-updates? <podiki[m]>(I don't care about pyyaml directly, but it is a dependency for something) <podiki[m]>maybe due to recent commit adjusting python sanity tests? <jackhill>nckx: re: my patch, I agree that caution and taking time to consider it properly is in order <jackhill>I'm fairly confident it's correct for my (weird?) setup, but am less confident about other device arrangements <raghavgururajan>Damn! I spent whole day trying to start X display server without a display-manager. I couldn't make it work. <jackhill>(I used a dedicated VM for testing, so wasn't too worried about my data ☺) <raghavgururajan>nckx: [unrelated]: Do you have your dotfiles and system-configuration published some where? <jackhill>raghavgururajan: uhg, I think i've done stuff like that before. (unfortunately), I had the wayland cool-aid. I'll probably try to get gnome-on-wayland working again after the upgrade. <jackhill>raghavgururajan: I haven't forgot about wanting to test xmpp-calling with you. Life is just … busy <raghavgururajan>jackhill: I see. I'll be getting to the gdm part during my gnome work. May be would work together on that part? <jackhill>raghavgururajan: sure, feel free to ping me. I'll try to do some prep work and get a testing setup with the branch. Last time I looked at it, I got as far as it's starting but then crashing for some reason a falling back to X, and since there was an update in progress, I figured that it didn't make sense to try to debug it too much. <jackhill>is wip-gnome based on core-updates? I know that has a wayland update in it. <jackhill>raghavgururajan: I was just using master! <jackhill>I thought it was a case of just not having been enabled yet, and thought I could get an easy win :) <raghavgururajan>wip-gnome is based on master, but has commits from core-updates as well. <daviid>raghavgururajan: did you try/use xvfb? <raghavgururajan>sneek, later tell iyzsong: Before you moved to wayland, do you still have the configuration files for starting X display server with startx/xinit and your xorg-server-service-type? I am desparately want to set that up. :) <raghavgururajan>sneek, later tell efraim: [1] Could you reshare your snippet for auto-starting shepherd-user-services? [2] For shepherd-user-services, what is the difference between using make-forkexec-constructor/make-kill-destructor and using make-system-constructor/make-system-destructor? [3] Thanks! <raghavgururajan>sneek, later tell efraim: [1] Could you reshare your snippet for auto-starting shepherd-user-services? [2] For shepherd-user-services, what is the difference between using make-forkexec-constructor/make-kill-destructor and using make-system-constructor/make-system-destructor? [3] Thanks! <raghavgururajan>sneek, later tell efraim: Could you reshare your snippet for auto-starting shepherd-user-services? ; For shepherd-user-services, what is the difference between using make-forkexec-constructor/make-kill-destructor and using make-system-constructor/make-system-destructor? <sneek>raghavgururajan, you have 1 message! <sneek>raghavgururajan, raghavgururajan says: test test <raghavgururajan>sneek, later tell efraim: Could you reshare your snippet for auto-starting shepherd-user-services? <raghavgururajan>sneek, later tell efraim: Regarding shepherd-user-services, what is the difference between using make-forkexec-constructor/make-kill-destructor and using make-system-constructor/make-system-destructor? <daviid>raghavgururajan: no, i thought you were tryingto'fake' an Xserver <raghavgururajan>daviid: Nah , I wanted to use display server without display manager <daviid>and manually run startx doesn't work? <sneek>efraim, you have 2 messages! <sneek>efraim, raghavgururajan says: test <sneek>efraim, raghavgururajan says: Could you reshare your snippet for auto-starting shepherd-user-services? <efraim>interesting sneek got distracted by the semi-colon <efraim>I actually regularly refer to the shepherd manual to make sure I use the one I want <raghavgururajan>efraim: Does `export GPG_TTY=$(tty)` in bash_profile work for you? When I do env, I see GPG_TTY=not a tty <raghavgururajan>Also, do you have your ~/.config/sheperd files published somewhere? I'd be interested to learn something from yout setup. <MysteriousSilver>raghavgururajan: what's the difference between bash_profile and profile? <leoprikler>MysteriousSilver: one is specific to bash, the other more generic but rarely sourced shells in practice. <efraim>raghavgururajan: GPG_TTY works for me on other machines were I log in only through ssh. I haven't published my ~/.config/shepherd yet but I should <civodul>is that because upon failure substitutes aren't retrieved on berlin? <civodul>looking at maintenance.git commit ea4b2fb90633372e6989f23b18af4fa3e991e323, we must have two OverDrives idle somewhere <mothacehe>it means that its dependencies are not registered as Cuirass jobs <civodul>oh and thus they're not retrieved, right? <civodul>all the dependencies come from commencement.scm, yes <civodul>so they're expensive to build but have no corresponding Cuirass job <mothacehe>they are rebuilt for each %core-packages from (gnu ci) and not fetched on failure I guess <mothacehe>only a succeeded package is fetched back using ensure-path RPC <mothacehe>I wonder if we could create jobs for the packages in commencement.scm <mothacehe>regarding the idle overdrives, nckx has a hard drive issue with one of them iirc <mothacehe>dover has also been unreachable for weeks but you have already noticed andreas <darosior>to send a bug report to bug-guix@gnu.org. Any way i can check i'm not going to create a duplicate before doing so? Thanks! <civodul>hmm somehow ERC seems to no longer be notifying me <civodul>mothacehe: perhaps it would be good to have jobs ("hidden" jobs?) so we can get substitutes for them <civodul>otherwise it's really hard to debug things on core-updates <mothacehe>do you think a naive approach adding jobs for each package in the commencement.scm file could work? I can give it a try if so <mothacehe>they won't be hidden because it doesn't exist in Cuirass though but it can come later on <civodul>we should not make the variables in commencement.scm public though <mothacehe>hehe, yeah i'm trying to find a way to collect them anyway *civodul had forgotten to hit "push" yesterday for patches applied to 'master', oops! <vivien>Dear Guix, my nginx service logs a lot of things indefinitely in /var/log/nginx/access.log and /var/log/nginx/error.log. I’d like to manage these with rottlog, but it seems that the rottlog service does not accept more log-rotation definitions, only the service extension. How should I proceed? <vivien>I mean, with all search engines and other bots, this log is the largest on my system. <vivien>I’ll see tomorrow if it works :) <zamfofex>Hello, everyone! I don’t think anyone would remember me back from Freenode. But I wanted to mention that I recently published some experimental packages for Guix on my GitHub. (This includes the IRC client I’m using right now!) <zamfofex>For now, the only packages are (i) glirc, (ii) Liquid War 5, and (iii) KDE 1 (from the restoration project from around 2016) <zamfofex>There is also byacc, but it’s only really there for KDE 1. <zamfofex>I hope someone might find it interesting in some way or another! <zamfofex>tschilptschilp23: move the “guix licenses” import above the “gnu packages compression” import, see if it works better. <tschilptschilp23><zamfofex "tschilptschilp23: move the “guix"> Thank you, that was it :) I will have to add a little input still, but the license-error is gone! <tissevert>wait what ? order of #use-module «imports» matters in package descriptions ? <zamfofex>It does because zlib is exported by both modules. <zamfofex>tschilptschilp23: I’m glad I was able to help! <zamfofex>tissevert: It is both the name of a package and a license. <tissevert>ahhh a special case, ok that's a relief ^^' thanks ! <roptat>usually it's avoided by adding a prefix <zamfofex>There is probably some better way to disambiguate it, but I don’t know! As you might have realized by my wording “imports”, I’m quite a newbie at scheme. <roptat>you can do (use-modules ((guix licenses) #:prefix license:)) <roptat>and then, to refer to the zlib license, you'd do license:zlib <zamfofex>Oh. Does that require you to use the prefix, or does it simply allow it? Because if it’s the former, that might be annoying. <tissevert>zamfofex: no, I hadn't realized because I'm a newbie too : ) <roptat>I don't consider myself a complete noob now, but I still don't know which verb is appropriate for "use-module" <ytc>hello. is there any way for me to start X server without a display manager like gdm? <tricon>ytc: Yes. Are you wanting to use xinit to start X? <tricon>I use xinit to start X myself, with dwm. <ytc>tricon: thank you very much. <tricon>ytc: Sure thing. LMK if you need help with anything. <roptat>so, I still get "In procedure load-thunk-from-memory: incompatible bytecode version" when running guix from my checkout... <roptat>it's failing to load the .go file from the repository that I built minutes ago ***lukedashjr is now known as luke-jr
<apteryx>roptat: did you try 'rm guile' at the root of your tree? <jlicht>roptat: `make clean-go' might be the sledge-hammer approach <roptat>didn't know there was a guile at the root of the tree <roptat>another question, I have a package whose tests require pdflatex. I could use "texlive" as an input, but I believe we avoid using it as a package input, right? <apteryx>roptat: I think you can use 'import' <apteryx>that's what the Guile REPL uses at least; ,import <apteryx>importing a module; ,import (guix build utils) <apteryx>equivalent to (use-modules (guix build utils)) <podiki[m]>hi irfus, have you checked in on the discussion on the mesa patch? <dongcarl>Hi all, looks like a texlive derivation is broken: /gnu/store/20g6mvz00kw749y27kyjnw2y22gl6wgh-texlive-bin-pdftex-poppler0.76.patch.drv <roptat>dongcarl, do you know where the patch is now? <dongcarl>Likely any other git.archlinux.org links also need to be changed <roptat>great! can you send a bug report for that? I can't fix it right now <roptat>I see only two places where we use that, in tex.scm and engineering.scm <roptat>the other references are comments <dongcarl>Okay yeah, I think in general Guix should not depend on other web servers for pinned patches... Makes builds fail in a way that's hard to mitigate... <roptat>does anyone know which package provides plain.bst (the plain bibliographic style for bibtex)? <roptat>dongcarl, I built it recently without issue, probably because I got a substitute for the patch? <roptat>(you'd get a substitute even if you don't allow any substitute server key, since it's a fixed-output derivation, as long as you specify a substitute server) ***crazazy` is now known as crazazy
<civodul>dongcarl: is it a cgit-generated patch (or similar)? <dongcarl>civodul: It's actually a patch that's inside the repo rather than a diff of two git refs <civodul>dongcarl: but there's a commit ID in the URL, so you would expect it to be stable, no? <civodul>ah well, maybe we just need to update the URL? <dongcarl>civodul: Yes, I think archlinux changed their git.archlinux cgit to a GitLab? <dongcarl>civodul: Also, I think it'd be better to just put it in gnu/packages/patches, so archlinux/github servers don't cause us trouble in the future <sneek>soheilkhanalipur, you have 3 messages! <sneek>soheilkhanalipur, nckx says: OK, so the phodav failure seems related to my libgudev update. I'll investigate and push a fix after I wake up! <sneek>soheilkhanalipur, nckx says: Ignore that ☝message: I decided to fix it in my sleep instead. <sneek>soheilkhanalipur, nckx says: The gudev update actually ‘fixed’ the installation of the udev rules, but phodav tried to install them to udev's /lib directory, failing. If you ‘guix pull’ it will install to its own directory instead, working. <dongcarl>Hmmm, any reason something like this would happen? `/root/.config/guix/current: symbolic link to /var/guix/profiles/per-user/darosior/current-guix` <zacchae[m]>is that an error? I believe profiles are usually symlinks <dongcarl>Right, but the root one should link to per-user/root <bricewge>jlicht: Thank you for the snippet :) Were you a member of input or video group when you used this? <raghavgururajan>> efraim: raghavgururajan: GPG_TTY works for me on other machines were I log in only through ssh. I haven't published my ~/.config/shepherd yet but I should <raghavgururajan>I see. Cool! Please let me know when you do. Will be a great resource. :) <bricewge>sneek, later tell viven: You can use simple-service to avoid the boiler plate when you are extending a single service <raghavgururajan>> MysteriousSilver: which one should i use for, say start shepherd <dstolfa>civodul: i've been hacking a bit on `guix bisect`, which would act a lot like `git bisect` and you could do stuff like `guix bisect --good=... --bad=... -- environment --ad-hoc ...` (so a lot like time-machine). however, i'm hitting an issue in computing the halfway point between good and bad. libgit2 doesn't have a way of doing this, it just has a revwalk API. now, i could reimplement bisect with that, <dstolfa>though my concern is that if `git bisect` semantics change at some point, we would have to chase them in guix. would it make sense to do the dirty thing of invoking `git rev-list bad..good --bisect`? <lfam>Linux 5.13 has a new configuration option MODPROBE_PATH, where you tell it where to find modprobe <lfam>I guess we should use '/run/current-system/profile/bin/modprobe'? <lfam>It has to be set while building the kernel and then continue to work after the kernel is built. <raghavgururajan>That way, the kernel always uses modprobe form its own build. No mismatch across versions can occur. <raghavgururajan>Does it uses modprobe while building or just needs the path-value to be set? <roptat>modprobe is part of the kernel package? <raghavgururajan>Let me rephrase that. While building, does it uses the modprobe program set in MODPROBE_PATH or does it just expects the value of MODPROBE_PATH not to be empty. <lfam>It just needs the value to be set <lfam>If the value is empty, module loading is disabled <lfam>I mean, the value also needs to be set correctly <lfam>I'm not sure what it was doing before 5.13 <lfam>The one we offer on our website, brettgilio? <brettgilio>mutable isnt the right word, persistent is probably better <brettgilio>pardon my ignorance, but does it have a set storage size, or can that be changed too? <roptat>I think the manual has some commands to resize it? <lfam>The size is set, but it can be enarlged <lfam>You can resize the qcow2 container, and you can also resize the filesystems and partitions from within <lfam>Check commit 4b236c88eaa690a045bc57b9c4d2acf44ae91f17 which included instructions for that. Those instructions have since been removed <roptat>ha, that's why I can't find them anymore. why were they removed? <lfam>I think the use case of this template changed <lfam>I added it so it could be used with VPS services that accept qcow2 uploads. Over time I stopped needing that, so other people took over the tempalte <bricewge>lfam: It should probably be /run/current-system/profile/bin/modprobe <bricewge>IIUC we could get rid of setting /proc/sys/kernel/modprobe after that <lfam>It's tough to get rid of it because the older kernel versions don't have this option <jlicht>bricewge: I was in the video group back then <lfam>It's at least 5 years until we will drop those old versions. And maybe never if we decide to include the CIP super-long-term-support kernels <lfam>"Never" is not realistic, I suppose <lfam>But it could be 10 years <lfam>Of course we could discuss support of these older kernels and decide to remove them sooner <lfam>Oh, I was wondering about that <lfam>It would be nice to understand how it works before 5.13 <lfam>There's no binding between linux-libre and modprobe/kmod, at the package level. Neither of them depend on each other IIUC <lfam>So I wonder if the distinction between booted and current matters or not. I don't know anything about how this stuff works, really <raghavgururajan>Oh so modprobe is part of the package module-init-tools. We can add that to inputs and do `(string-append "MODPROBE_PATH=" (assoc-ref %build-inputs "module-init-tools") "/bin/modprobe")`. <lfam>I think it's okay to use a dynamic binding here. Unless there have been problems with it in the past? <lfam>If I understand correctly, it's been dynamic since the beginning <raghavgururajan>IIUC: When you boot the system, the system-generation for current-system and boot-system will be same. When you do system-reconfigure, the system-generation of current-system move forward by one, while the system-generation of booted-system stays the same until reboot. <podiki[m]>I asked in here earlier (though an odd hour), but anyone having difficulty building python packages on core-updates? <podiki[m]>python-pyyaml fails for me on sanity-check (recent commits I believe) <raghavgururajan>lfam: I think using non-dynamic will be good for run-time reproducability. <lfam>But I'm saying, have their been reproducibility problems so far? <lfam>podiki[m]: If it's not working for you, it's probably not working for anybody <podiki[m]>lfam: yeah, I submitted a bug report, but thought I'd check in here <lfam>Core-updates is where we put changes that have a big impact, so we can work on them without disrupting Guix users. But it's not a branch that is expected to work, in case you were hoping to use it for something <podiki[m]>i keep making local changes and jumping around, just wanted to make sure it wasn't me (even though I tried on a clean checkout) <raghavgururajan>Not sure about that. I am thinking of easy debugging. If two systems are using exact same build of kernel, but one has issues with loading modules, then we can eliminate modprobe if both kenel builds used same build of modprobe. <podiki[m]>lfam: gotcha, just been working on patches that would go in core-updates, so been working from that branch directly. though I guess not necessary maybe <lfam>It's tricky to find the right workflow for that :) <lfam>I'm not sure of the current status of core-updates... been out to lunch for a while <lfam>What I do in that situation is apply my patch to master, test it there, and then submit it for inclusion in core-updates <lfam>It may be that the tests are invalidated by the change of branch, but that's just how things go on core-updates <lfam>It's always a somewhat herculean effort to whip core-updates into shape <lfam>We had some trouble with the build farm, plus the pandemic, and the current core-updates cycle has stretched on for way longer than usual <lfam>The build farm is working well now <roptat>did ci start evaluating core-updates? <sneek>Welcome back maximed, you have 1 message! <sneek>maximed, civodul says: this new lint warning for #:tests? is awesome :-) <lfam>Not sure but, from a glance at the web site, it looks like it's only doing the "core subset" of packages <lfam>I think it is always doing the core subset, which is quite minimal <lfam>It belies the true meaning of 'core' in terms of Guix, which has perhaps been lost over time <lfam>As the number of packages increased, the old guidelines have become somewhat less coherent <lfam>Like, it's a bit silly that python-pytest-5 qualifies for core-updates now <lfam>We can probably rethink the branching workflow <lfam>Especially as the aarch64 build capability increases <lfam>It's kind of a drag doing the kernel configs, but also pretty interesting. You learn a lot about the development of the kernel <lfam>I wouldn't be surprised if the Microsoft Surface devices had some of the most complete and sophisticated Linux support of any laptop <lfam>It's quite a bit beyond "does the trackpad work" <roptat>ah, the sanity-check phase is new in core-update's python-build-system? <roptat>ok, so the issue with pyyaml is also present on master, but it's "hidden" because there's no sanity-check on master <roptat>pyyaml can load the "yaml" module, but fails to load the "_yaml" module <lfam>An issue that I noticed as a result of grafting is that there are 4 different webkitgtk derivations in my profile. I wonder if this can be improved... <lfam>I didn't dig in to it yet <podiki[m]>roptat: right, just made the tests work on core-updates <roptat>podiki[m], oh great! what did you do? <lfam>It definitely compiles with less than 64 GB RAM :) <lfam>The only replacement for webkitgtk is chromium or firefox <lfam>It's simply not something that's easy to replace <podiki[m]>lfam: thanks, that is helpful to hear. Some patches I had there had been revised in core-updates, so I figured I'd work there directly. but perhaps has been more annoying that way (and probably more rebuilding) <lfam>Yes, a lot of rebuilding <roptat>I was trying to find a way to make the _yaml module work, and it seems it needs to build the native extension instead of the python one, but can't figure out how to do tat properly <podiki[m]>roptat: I just meant the commits made the sanity-check do something, which is why they fail <maximed>There is an independent browser that doesn't use webkitgtk but I forgot its name <lfam>There are a lot of little micro browsers, but they aren't really a "replacement" for most people <maximed>(a graphical browser I mean. If text+image only is sufficient, see eww-mode) <podiki[m]>roptat: and pyyaml only does the python build I think the log said? <maximed>I found it again. 'dillo' is its name <roptat>yes, it's failing to build yaml/_yaml.c <roptat>and indeed, no C file in the sources... <lfam>It's not like webkitgtk / chromium / firefox are big just because they like being big. It's a really challenging thing to do well <podiki[m]>there is something soothing about watching compile logs fly by, but when I see it will rebuild every version of ghc, texlive, llvm....ugh <lfam>I would say that one avoids the "big browsers" at their own peril <lispmacs[work]>well, really the problem is HTML/CSS/etc has become a horrible monstrosity <lfam>It's not just that. The security issues and the features that people expect are simply gigantic <maximed>Technically, there are plenty of well-working and relatively small graphical web browsers (see ‘gemini’). That doesn't help if you need to access HTTP(S) sites though <podiki[m]>browsers are computers now, and computers are browsers (and computers = lots of devices) <lfam>If security doesn't matter (and it might not), then those little browsers are totally fine <dstolfa>i use small browsers for anything work-related, but i can't do any media without ungoogled-chromium or icecat <leoprikler>tbf I too expect security issues from every web page I browse <lfam>Well, I wasn't calling out webkitgtk for its compilation cost. The grafting derivations only use I/O and space. It's annoying to have to graft it 4 times. I don't even understand where these different derivations are coming from. Are there some webkitgtk variants in the package graph somewherE? <leoprikler>IIRC you can end up grafting some things twice or more. <leoprikler>Meaning an already grafted webkit would be grafted again. <leoprikler>I don't quite understand it either, but it depends on your output package. <drakonis>basically, i've grafted the ol' nasty into mesa and it turns out it's too fiddly, so i tried to create another generation without the grafted bits and now gdm refuses to run <lfam>GDM has a lot of state that can break <lfam>Try the solutions that Ricardo suggests there <drakonis>also we need more build systems a la carte in guix <lfam>leoprikler: Maybe my understanding of grafting is wrong. I thought that a package's grafts were known after building the package, because it's references are known then. I don't see how it could change <lfam>Like, we know what packages webkitgtk depends on at run-time, and we know which of those packages must be replaced. It's a one-shot process IIUC <podiki[m]>drakonis: if you are fiddling with mesa and co, feel free to try out the mesa 21.1.4 patch :-P i've compiled mesa so many times now, luckily it isn't too bad (~5 minutes?) <leoprikler>My understand is basically nonexistent, but I know that glib is already in a situation where it gets different grafts from the same base for no apparent reason. <leoprikler>So while I agree with you in principle, that grafting should be a one-time thing, we'd have to look under the hood to find out whether that's actually the case everywhere. <lfam>leoprikler: Yeah, I noticed a few others besides webkitgtk. That one stood out for the large number of derivations. We should make a bug report <podiki[m]>note that it is written on top of core-updates, so if using master you'd want the mesa package def from core-updates first (and libdrm, but that should be it I think) <lfam>leoprikler: I can report it now <leoprikler>go for it, your phrasing will probably be better than mine <jackhill>I don't understand grafts either (and this may not be related to the webkit thing), but "Redundant library grafts lead to breakage" https://issues.guix.gnu.org/47115 seems like a subtle problem in the grafting logic <lfam>jackhill: Hm, I'm not sure it's related <lfam>Starting there is the good part, I think <darth-cheney>hey all, quick and potentially dumb question about guile and guix <darth-cheney>if I want to just explore in the repl, should I be able to use guix modules in guile interactively? <maximed>darth-cheny: in "guix repl", yes, using (use-modules (...)) <darth-cheney>At the moment this is not working for me, ie I cannot (use-modules (guix)) or something and inspect it <maximed>in the REPL started with "guile", no, unless you're in an approprate "./pre-inst-env" I suppose <lispmacs[work]>darth-cheney: use command "guix repl" to enter repl with paths setup <darth-cheney>thanks. I'm just trying to debug a package and its, you know, tough <darth-cheney>I do not have any cmake experience and this particular thing is built with cmake so it might be a lost cause <tricon>But I thought cmake was supposed to make building easier!? <tricon>I had a monolithic project years ago with hundreds of standard Makefiles that I was responsible for cleaning up and converging. I rather enjoyed that project as I find Make to be rather easy to work with and predictable. <tricon>I admit at the time that I had proposed CMake as an alternative, but my wise CTO said, "No. No additonal deps." <lispmacs[work]>the main problem I run into with makefile only source packages is they usually assume alot about where stuff is located <roptat>podiki[m], I don't understand how one is supposed to build the C extension of pyyaml... <Reinhilde>drakonis: no. I strictly speaking cannot, because I use ZFS <leoprikler>lispmacs[work]: paradoxically, unless you're using autotools your makefile abstraction layer is actually worse at assuming than handwritten Makefiles <leoprikler>case in point, LLVM's broken CMake configuration <leoprikler>This is the compiler, that big companies bet on, folks. <Reinhilde>does guix need a special kernel, or will a debian kernel do? I only have space for a debian kernel next to my FreeBSD kernel in my ESP (necessary as I don't use a bootloader) <podiki[m]>roptat: sorry hadn't looked. I guess that is supposed to be the faster way to do yaml rather than just pure python? <lfam>Reinhilde: You can use whichever kernel you prefer <drakonis>you can install just the package manager on any linux distro <leoprikler>Reinhilde: guix uses linux-libre (or hurd if that's your thing) <lfam>However, it's easiest if it's built by Guix <lfam>You might have to do some munging of GRUB stuff <drakonis>as well as feed it whatever kernel config you need <maximed>but unprivileged containers are required for some things <roptat>podiki[m], that would be needed to load "_yaml", so the sanity check passes <roptat>_yaml is actually installed, but it has some logic to check if the extension was built or not, and if not, it raises "ModuleNotFound" :/ <lfam>I think you can use the --no-bootloader option of `guix system` <maximed>Reinhilde: I think it was just a matter of writing something to /sys/SOMEWHERE <maximed>Something about ‘unprivileged namespaces’ <podiki[m]>roptat: ah. but it doesn't need that to be functioning? or was it broken in someway before but the sanity-check wasn't working to pick that up? <maximed>Debian (used to?) disable those by default, but you can overwrite the setting easily if you have root access <maximed>And maybe Debian now enables it by defaults nowadays? (I dunno) <roptat>podiki[m], the sanity check was added in core-updates, on master, _yaml doesn't load either <podiki[m]>roptat: oh, then maybe needs a patch to find where Guix has it? <maximed>Reinhilde: If it's enabled, then I wouldn't expect trouble <lfam>Debian patched their kernel to add a sysctl flag to control it, maximed. This flag never existed outside of Debian <lfam>Maybe it ended up in Ubuntu and other downstream distros, not sure <Reinhilde>Does Guix speak French? I don't, but i've a tradition of using BSDs in Canadian English and GNU/Linux in Canadian French. <maximed>Reinhilde: Guix is partially translated in French <maximed>(the manual and CLI commands at least) <Reinhilde>so, same situation as Debian (many system management outputs are still in English)? <maximed>Reinhilde: it depends on the particular package, but yes, most tools are in English only <drakonis>linux on debian sid is entirely unpatched now <dstolfa>doesn't that kind of depend on the tool itself, rather than guix? obviously it's desirable to support as many languages as possible for guix itself, but i can't see how that could be done for a random package that guix packages <Reinhilde>That's fine. It just has to be enough to remind me that this isn't BSD <dstolfa>Reinhilde: just hit ctrl-t and you'll quickly remember! *dstolfa hits ctrl-t all the time by mistake <drakonis>but the tools don't actually implement it <dstolfa>a tool doesn't have to implement siginfo to get the most basic output though <drakonis>maybe implement siginfo on gash coreutils? <Reinhilde>don't utils written for linux usually sub SIGUSR1 for SIGINFO? <dstolfa>also... i don't think linux supports siginfo, it's instead sigusr1/2 <dstolfa>and tools can implement "progress status" using those, or at least have traditionally done so if they choose to do it <dstolfa>it's just not nearly as common as i'd like it to be :( <Reinhilde>but yeah, using language translations on a local machine (since.. they do not work on freebsd) are the way I remember which command syntaxes to use <Reinhilde>i have a machine rented i run illumos on in new jersey <drakonis>* Signal 29 is SIGINFO/SIGPWR (synonyms for the same value) on Alpha but SIGLOST on SPARC <Reinhilde>.. is there a more on-topic channel for this banter? <lfam>It's okay to go off-topic for this kind of stuff sometimes <lfam>Guix is a new type of system, so talking about other unusual systems is maybe on-topic <drakonis>well, do we spin up a new channel for this? <drakonis>we dont have a channel for offtopic things but i've been squatting on chat and offtopic <Reinhilde>on section 3.6 of the manual. having been a BSDer for years, i'm not familiar with gnu/linux but i should be easy to get up to speed <drakonis>guix is quite the deviation from the usual linux experience <lfam>Does Guix support the substitution of grafted derivations now? <drakonis>am i allowed to register channels under the guix umbrella? <lfam>No, grafting always took place locally in the past <lfam>But I just did a big `guix package -u .` and it didn't graft anything <lfam>Oh, it did graft one thing. But that's abnormally low <dstolfa>i asked earlier, but it might be too far back in the log -- i'm implementing `guix bisect --good=... --bad=... -- run-stuff` and i was wondering what the preferred implementation for bisecting would be. libgit2 doesn't have a notion of a "bisect" but it has revision walking implemented, so i could implement our own bisect, or i could spawn invoke `git rev-list bad..good --bisect` to give us a hash. which is <lfam>It's not a chroot but `guix system` includes a lot of tools for running Guix in a VM (QEMU) or in a container <podiki[m]>just needed to add cython to inputs? or modify package to use it? <podiki[m]>roptat: nice investigation and easy fix (or upgrade really, if it didn't use it before), the best kind <podiki[m]>we were discussing earlier about branches and working on patches, does anyone here run mainly from core-updates? or only use that to test/patch certain things <lfam>No, it's not usable (until the final stage of the cycle) <lfam>Like, low-level packages may simply not build at all, breaking the entire distro <maximed>podiki: core-updates is for updating & fixing things that would lead to lots of rebuilds <podiki[m]>so rely on Cuirass for seeing what builds and not, although it is only building core right now? <podiki[m]>so only have real world usage/testing when freezing before final merge really? <lfam>Once we decide to "finish it", we'll have Cuirass try building every package based on it. Then, we'll fix things until it's usable, then people will update their systems based on it to test things <lfam>Finally, it will get merged into the master branch, deploying it <lfam>Hopefully not :) That's the point of the "people will update their systems based on it" <lfam>It's supposed to happen before the merge <podiki[m]>wasn't sure if if it was like distros that have a "testing" or "unstable" branch that is generally usable <lfam>No, we don't have that podiki[m] <drakonis>Reinhilde: guix can run on foreign systems <lfam>It's not that easy to motivate enough people with diverse use cases to catch all the issues, though <Reinhilde>I want to install the whole distribution though <podiki[m]>thanks for the info. just been in the weeds because the patches I've been working on are for mesa, haskell-build-system, and they would go to core-update first, so been working in that branch (still on foreign distro, just doing lots of compiling) <drakonis>hmm, well, you can chuck the distribution into a whole container <Reinhilde>(I actually came here off some xmpp drama. Now i'm installing a second Linux distrib?) <podiki[m]>Reinhilde: you can easily build a bootable USB for instance, and play with that on hardware directly too <maximed>or install guix on an external hard drive (should work but I've never tried) <raghavgururajan>Folks, if I use (dns "dnsmasq") in network-manager-configuration of network-manager-service-type, do you also I also need dnsmasq-service-type? <dstolfa>raghavgururajan: looking at the code, i think so, but maybe... it shouldn't be necessary? <dstolfa>ideally it would be figured out by the shepherd service i reckon? <dstolfa>seems fairly straightforward to implement <drakonis>i wonder how nixos even deals with this aspect of gdm <drakonis>its good to know this isnt a grafting issue, that its just gdm being terrible lol <drakonis>should gdm still be the default desktop manager in %desktop-services? <drakonis>gnome and xfce4 are recommended but yet gdm is a default that has to be removed from the list <drakonis>latest would save you time upgrading your system afaik <drakonis>stable is based on 1.3.0, which is from may <drakonis>latest should get you as close to the freshest release as possible <jackhill>drakonis: as far as I know, gnome depends on gdm for some features like the lock screen, so if you ever want gnome, you need to use gdm <drakonis>well, gnome isn't a default either, you need to explicitly declare its service <dstolfa>jackhill: i don't think that's correct, i use sddm with gnome and AFAIK i can lock screen on my systems just fine <dstolfa>though maybe i misunderstood what you meant <jackhill>dstolfa: oh? cool, not I suspect I might be mistaken. Or maybe just picked on the wrong feature. I'll have to look again. <drakonis>there is a specific thing that gdm provides for gnome <jackhill>also, I guess it provides all the gnome/gtk accessibility goodness to the login screen <drakonis>doesnt look like you still require gdm for gnome now <drakonis>but in the past it was explicitly necessary to run <bricewge>raghavgururajan: No, using (dns "dnsmasq") in network-manager-configuration will handle its own dnsmasq instance, with its specific configuration (see manual) <bricewge>Actually I have issue using this with libvirt-service-type since it produce 2 dnsmasq processes <drakonis>apparently nixos had explicit issues with not using gdm alongside gnome ***LispyLights is now known as Aurora_v_kosmose
***lukedashjr is now known as luke-jr
<raghavgururajan>bricewge: Ah I see. So if want to use dnsmasq I just need to add dnsmasq-service-type? Will networkmanager/applications use it? <drakonis>weekend project: figure out how to parallelize shepherd <civodul>so, i've been building gcc & co. for aarch64 emulated on x86_64 <civodul>and guess what: it's been running for ~12h and hasn't completed yet