<jonsger>do others get substitutes for the current HEAD on master? I don't get any substitutes or at least it seems so <nckx>joshuaBPMan: How would you describe the style of The Little Schemer? I read it and enjoyed it, but it's... odd. <nckx>There are also two sequels to it which I haven't read yet. <bluekeys>Hmm.. There was an error on the screen, but now the installer is giving me congratulations. Is there a way I can make a note of the error before I reboot? <bluekeys>Something about rmdir -A i think and directory isn't empty? <bluekeys>I couldn't see because the error message flashed before the congratulations screen. I've hit reboot now. Let's see what happens. <nckx>-A isn't an rmdir command flag, and the installer is written in Scheme and wouldn't shell out for that, so I wonder what it was. Oh well. <nckx>It's possible that it happened during the shutdown sequence in which case it's likely harmless. <nckx>Maayybe hit C-s quickly but that's not really an answer. Probably not. *nckx has never used the installer, this probably bears repeating. <bluekeys>Does that suspend, kinda like how pause works in the bios. nckx are you not using guixos? How did you install it without the installer? <nckx>bluekeys: Yes, exactly (Scroll Lock does the same). C-q resumes flow. <bluekeys>Ahh, that happens in terminals sometimes too <nckx>bluekeys: I use Guix System on all my machines đ (we never used the name GuixOS; we used GuixSD haven't for 1-2 years) <nckx>bluekeys: I used the command line and âguix system initâ. <nckx>This was years before the TUI installer. <bluekeys>Oh, is there a reason no-one uses guixos? Wait a minute, is it because the OS is GNU? <nckx>Yeah, Guix is a distribution of the GNU operating system. <nckx>If you log into a getty you'll see âThis is the GNU system. Welcome.â for that reason. <bluekeys>Thats a very reassuring welcome message. <nckx>Naming is always a touchy subject, and this is GNU, so there was a lot of discussion before the original name (Guix System Distribution) was chosen. Later shortened to âGuix Systemâ, but not for any political reason or because anyone asked us to. <bluekeys>Ha. brave login: People, I think I may have a running GNU system (correct me if I'm using the wrong words). First time I haven't been running "Linux", if you know what I mean :) <bluekeys>Right, now how do I get the Hurd installed! <nckx>bluekeys: Your words are fine đ All Guix Systems are GNU systems, not all GNU systems are Guix Systems. And you were already running Linux before, I'm sure. *nckx needs to work a bit o/ <nckx>It's a different workspace on my laptop but thanks! Be back in a few hours, let me know how it goes (and don't hesitate to file bugs -- Guix isn't done). <mroh>hendursaga: you are right, gnunet-gtk seems to be broken currently, needs some work. I'll take a look. <bdju>which package gives the gsettings command? <OriansJ`>I know I am a broken record at this point but guix pull is broken on debian if one does not enable substitutes; which really presents an issue in regards to binary trust. <mroh>hendursaga: weird, looks like gnunet-gtk needs --libexec to gnunet... ***catonano_ is now known as catonano
<OriansJ`>NieDzejkob: not that I know of but if you look at the IRC log on Aug 7; you'll see the previous report and details of how to replicate; down to the last possible step. lfam said they would look into it but there appears nothing further on the subject. <nckx>OriansJ`: Is vagrantc aware of this? <apteryx>is it possible to remap 2 different mouse buttons to the same action using xmodmap or others? One of my mouse has a broken button 2 <apteryx>I'd like button 2 to continue sending button 2, but also button 8 to act as button 2. <apteryx>seems not. I'll have to use some glue scripting to conditionally apply the config when the broken mouse is detected. <apteryx>The autossh service should require networking, me think <nckx>raghavgururajan: rust@1.24.1 <nckx>apteryx: It should if openssh does. <nckx>raghavgururajan: Why did the rust chain change so deeply? <apteryx>nckx: I could with a Match directive. More precisely, Match originalhost myhostname ***lukedashjr is now known as luke-jr
<apteryx>you can put this inside a Host block, and it'll enable the directives below it (if it matches) until the next Host block (or next Match directive). <apteryx>Allowed me to make my .ssh/config portable across systems. <nckx>I'm aware of Host and Match blocks, but confused as to how they answer my question... <nckx>Oh, I didn't even ask one. <nckx>(I kind of assume openssh require's networking, so I didn't ask.) <nckx>What were your Host/Match blocks about? <nckx>(They are very handy but addictive; I have 5 of them now...) <apteryx>I thought I asked a question about the possibility to use conditionals in a .ssh/config file earlier. <apteryx>and I thought you were answering back to that question ;-) <nckx>Oh, sorry, I must've missed that. You found the right answer though. <apteryx>the openssh service doesn't require the network <nckx>âHost behindlan | ProxyJump langatewayâ is a very cool feature. <apteryx>At least based on the output of 'herd status ssh' <apteryx>well not true, it requires the loopback <nckx>You're right. OpenSSH doesn't but LSH and Dropbear do :-/ i.e. it's totally arbitrary and in need of refactoring. <nckx>apteryx: Personally, I prefer minimal dependencies ('loopback is probably required to even start the service while 'networking isn't) but I'd rather see uniform bloat than this mess đ <nckx>So feel free to whatever, if you want, I mean, you know. <nckx>raghavgururajan: rust@1.25.0. <apteryx>someone reported that if they messed with avahi-daemon it resolved teh issue for them, which suggests something racy <apteryx>nckx: ah, reading the comments, this bug is no more. It remained open for some bogus reason, after being closed by civodul. <raghavgururajan>sneek, later tell nckx: Thanks! Could you gc-root those substitute on bayfront? I cannot do sudo guix archive. But you can and undo it quickly. Also, the rust changed because I made some changes to build systems. ***rEnr3n2 is now known as rEnr3n
<bdju>a lot of wayland stuff is broken after updating, I'm not actually sure what to blame yet <bdju>screenshots with slurp+grim don't get the right geometry or orientation from one of my monitors (mismatches the box I drew and is an entirely different spot, often upside down) <bdju>but also my keybinds to focus windows aren't working I think <bdju>update: some of them are working. maybe alacritty is busted. I can still focus mpv <bdju>okay changed my focus stuff to use titles instead of classes for alacritty and now that's fixed <bdju>how do I check which version of a program I have on guix? or all the versions or the latest versions... whichever is the most correct/easy. seems grim is lacking a --version argument <bdju>grim looks to be up to date and it changed something with rotation. sway made a similar change in the latest version. so only having one up to date is probably why my screenshots are being rotated! <bdju>no, sorry, I'm yet to get comfortable with that sort of th ing <bdju>oh, that would be great. :) *raghavgururajan has update wayland on wip-desktop. Soon will be available on master. <KimaprOnPhone>Is guix.gnu.org up? I cant ping it and guix system installation image cant download substitutes <brendyyn>guix time-machine wont fallback to building packages, even with --fallback and --no-substitutes so its just failing to download substitutes <KimaprOnPhone>Are there any other known substitute servers/mirrors of ci.guix.gnu.org? <brendyyn>i thought ci... was behind a caching CDN so it should have some amount of rendundency as a part of it. may be wrong though. <KimaprOnPhone>I also found mirror.hydra.gnu.org, dunno if it serves substitutes though, but it is pingable <brendyyn>looks like sway requires a meson update too @_@ <KimaprOnPhone>Okay so now my screen is officially full of "updating substitutes" messages <brendyyn>Is there a routine for how meson gets updated since it affects many other things ***iyzsong-- is now known as iyzsong-w
<xd1le>ah yeah down for me as well :/ <xelxebar>Will definitely be interested to hear about what brought it down and the remediation efforts. <mbakke>brendyyn: you can add a 'meson/latest' variable with the new version, and then in sway arguments pass '#:meson ,meson/latest'. <brendyyn>Europe is probably still getting out of bed. <rekado_>Iâm sick in bed, but I asked Madalin to look into it. *mbakke is slowly emerging from a somewhat spontaneous vacation <efraim>ed-1.14.1 tarball disappeaed upstream :/ <mbakke>efraim: weird, maybe message the maintainer? <efraim>I grabbed it from bayfront in the meantime <alextee[m]>Speaking of meson can someone bump the version in core updates plz? <alextee[m]>Fails at some patch in meson build system or something <mbakke>ah yes, the meson rpath patch should no longer be necessary <rekado_>ci.guix.gnu.org is back; looks like we ran out of space on the root file system <mbakke>alextee: it's better to add the new version on 'master' first for testing, I think brendyyn is on it :-) <rekado_>meanwhile /store (which contains kernels and initrds) is 6G <brendyyn>its my first time working in this stuff haha <brendyyn>i had to remake the rpath patch because the code had changed at that place <mbakke>rekado_: do you think we can get more storage on Berlin? <mbakke>brendyyn: I think the patch can be removed actually <brendyyn>oh really? i never understood what it did anyway i just monkey see monkey do <rekado_>I think at some point we should actually clean out some logs <rekado_>weâre barely even using the root file system <rekado_>the /gnu directory itself is on attached storage <rekado_>so do you mean a bigger root disk or bigger /gnu? <rekado_>I applied for extending /gnu a few months ago but I donât know the current status. <brendyyn>I tried to use time-machine today and it wouldnt work due to no substitutes being availble for the version a few weeks ago. i tried with `guix time-machine --commit=1a2902735664c6696f331b079f5e221ea4244fb9 -- build piper --fallback' but it didnt seem to recognise the --fallback and continued trying to pull substitutes while the server was down <mbakke>rekado_: bigger /gnu mainly, to avoid running GC so often; for the rootfs I suppose some rottlog rules should suffice for now. <efraim>brendyyn: what if you try 'guix time-machine --fallback --commit=...` <efraim>it's not possible to inherit a package that's defined but not exported when you're not in the same module, right? <brendyyn>guile 2 used to have @@ that you could do that with but it was deprecated i think <brendyyn>looks like there is still plenty of use of it in the codebase <alextee[m]>brendyyn: ping me when meson is ready plz, i have a few patches that depend on >= 0.55 <brendyyn>I don't have any access to the git repo so i can't push it to core-updates though so youll have to add it locally yourself <brendyyn>Then as mbakke explained, import the (gnu packages build-tools) module and set #:meson ,meson/latest in the packages you need to use it with. <alextee[m]>Ah ok, i kinda want it in git to submit some packages. Dont need it locally <brendyyn>alextee[m]: well just submit that patch with it together. <brendyyn>i can email it to guix-patches if you like but this saves you waiting <brendyyn>im also still testing to see if it works ***rEnr3n3 is now known as rEnr3n
<KimaprOnGuixInst>and looks like ci.guix.gnu.org is up again, though i still can't ping it <efraim>does anyone remember the magic commit between 0.13 and 0.14 to pull to when upgrading? <efraim>on the other hand the daemon was from 0.12, maybe if I run the 0.13 daemon it'll work <efraim>does anyone know if the cran importer works with older version? <efraim>rekado_: thanks. I'm trying to build some of the packages with r-2.15.3, wasn't sure if some of the dependencies changed over time <rekado_>all the other archives (git, hg, bioconductor) work by downloading the tarball and looking at the DESCRIPTION inside <rekado_>that could also be done for old CRAN releases <efraim>that sounds like a pain. I'll have to think about it vs doing it manually :/ <efraim>adding a phase while testing (invoke "cat" "DESCRIPTION") and touching up manually isn't too bad when it's guess and check anyway while building and guessing supported R versions <rekado_>I donât see why that would be painful <rekado_>(or did you mean âlike a planâ?) <brendyyn>what is the <filesystem> header provided by? <brendyyn>just weird that when i update waybar to 0.9.3 i get error: filesystem: No such file or directory <brendyyn>apparently it finds experimental/filesystem, but not filesystem <leoprikler>well, that would work, but you need to patch src/modules/temperature.cpp to respect it <brendyyn>could the fact that there isa #:configure-flags being used overwrite something? <alextee[m]>cd /tmp/guix-build-surge-synth-1.7.1.drv-0/source && python /tmp/guix-build-surge-synth-1.7.1.drv-0/source/scripts/linux/emit-vector-piggy.py /tmp/guix-build-surge-synth-1.7.1.drv-0/source /tmp/guix-build-surge-synth-1.7.1.drv-0/build/lintemp <alextee[m]>/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/sh: python: command not found <alextee[m]>hmm, is there a way to make `python` available to a package? <leoprikler>the thing is temperature.cpp tries to include <filesystem>, when it should check for <experimental/filesystem> <leoprikler>the offending commit is 2f975f870a715f6691ebd2fc12d6ad75dc752316 <brendyyn>how do you know it should be experimental, rather than us providing the filesystem dependency somehow <raghavgururajan>leoprikler, I have a question for you. What would be the difference between adding dbus-root-service and dbus-service to the config.scm? <raghavgururajan>Will adding either dbus-root-service-type or dbus-service gives same result? That is to run system-wide dbus service? <leoprikler>brendyyn: experimental/filesystem will become filesystem at some point, but not yet with the stdlib you're using <leoprikler>they have a define to account for that, but it's not being used in this specific source file <leoprikler><[experimental/]filesystem> is part of the C++ standard, so you have one of them through gcc-toolchain <brendyyn>so filesystem doesnt exist yet in guix's standard lib <leoprikler>raghavgururajan: dbus-root-service-type is a service type, whereas dbus-service is a procedure to instantiate a service of said type <leoprikler>some ancient services are duplicated as procedures before record constructors became the big thing <leoprikler>In new code you should almost always use (service service-type config) <raghavgururajan>> âleopriklerâ: In new code you should almost always use (service service-type config) <leoprikler>for adding to config.scm or for adding them to %desktop-services etc. <leoprikler>you don't otherwise instantiate services in guix <brendyyn>derp. looks like someone already updated waybar 7 days ago and fixed this <alextee[m]>this directory: /tmp/guix-build-surge-synth-1.7.1.drv-20/build <alextee[m]>this package doesnt install anything so i need to copy-recursively from there <alextee[m]>oh nvm you're already inside that dir when you do `replace 'install` <abralek>I posted dovecot updates one more time, but now with the documentation <raghavgururajan>I have this expression, (define %foo-list (append (list (foo-item) (bar-item)) %bar-list)) <raghavgururajan>Like (define %foo-list (append (list (foo-item)) (delete bar-item %bar-list))) <rekado_>is it â(bar-item)â or âbar-itemâ? <raghavgururajan>(define %foo-list (append (list (foo-item)) (delete (bar-item) %bar-list))) <apteryx>(bar-item) being a procedure returning the bar item to remove? <rekado_>âdeleteâ will work on the identity of an item <rekado_>if itâs a procedure application you will not be able to use âdeleteâ here <raghavgururajan>For example, to delete (service rottlog-service-type) from %base-services, inside %desktop-services. *raghavgururajan should have used the example in the first place <rekado_> (eq? (service-kind service) avahi-service-type)) <rekado_>thatâs the example from the manual <rekado_>I remember I had a patch to simplify this <rekado_>using (modify-services %desktop-services (delete avahi-service-type)) <raghavgururajan>I am temporarily doing (define-public service to indent the service definitions. <sneek>Welcome back nckx, you have 1 message! <sneek>nckx, raghavgururajan says: Thanks! Could you gc-root those substitute on bayfront? I cannot do sudo guix archive. But you can and undo it quickly. Also, the rust changed because I made some changes to build systems. <nckx>I'll copy Rust to bayfront. I'm still building 1.31.1 though. This will take a while đ <apteryx>nckx: do you know why the CI is so slow at building it? Is ungoogled-chromium still unavailable too? <nckx>I don't know, you know my 'tude towards the chrome. I noticed y'day that âsomeoneâ was building it on bayfront. Was berlin having trouble? <nckx>(Tip to that someone: feel free to use much more than the default -c6 when the system is otherwise idle. It has 32 cores.) <alextee[m]>is there a way to copy a dir recursively but without including the dir (only contents)? <nckx>apteryx: As to why Rust is so slow: it needs to build 28 rustcs (guix graph --path rust mrustc | nl), that by definition can be done in parallel, and the build itself does a lot of one-process stuff too. And a long test suite. <nckx>I wonder if there are any arguments about disabling the intermediate test suites during bootstrapping. Surely if the final rustc passes its suit, it's fine... <nckx>s/about/against/, not that kind of argument. <nckx>s/can be done in parallel/*can't* be done in parallel/ of course. Christ. <apteryx>nckx: copying from where to bayfront? <apteryx>Hmm, I'm not sure we should disable the tests unless those bootstrapping rust packages are for internal use only (hidden or otherwise private). <apteryx>OK, so that's where I get curious: your machine managed to build it faster than the ci/bayfront ? <nckx>These store items are specific to raghav's WIP branches; they won't be included in repro stats &c. <nckx>apteryx: I don't know. It's about halfway through the bootstrap, bayfront isnt't building rusts at all. <apteryx>haha, bayfront has some character (rust? no way -- takes the day off). <rekado_>sometimes builds on ci.guix.gnu.org fail because there are too many available cores <nckx>I certainly don't have 32 cores on a single machine, but considering how badly it parallelises (from random samplings looking at top đ), perhaps my cores are just a tiny bit faster. <rekado_>some packages then require unusual amounts of memory as they allocate a fixed amount per core <apteryx>ah, running out of memory due to using too many build processes <nckx>rekado_: As in, --cores is set too high on berlin, or the packages blindly look at nproc instead of -j? <nckx>If they still respect -j, that's... silly. If they don't, a bug. <Formbi>on mrustc's github it's written that it can compile Rust 1.29 <nckx>Considering the insane amount of RAM berlin has (not sure about the other nodes), that's nuts. <nckx>Formbi: WDYM? That's what Guix does. <nckx>guix graph --path rust mrustc. <Formbi>it starts with 1.19 after mrustc <NieDzejkob>there's a WIP patch somewhere on the mailinglist <nckx>I thought Danny had fixed that. <nckx>IIRC they mentioned .29 in February in Brussels already. *nckx ssh's into a Guix machine. <nckx>Formbi: Eh, you're right. :-/ <nckx>Formbi: Did you say you volunteered to âcheck that in Guixâ? đ *puppy eyes* <Formbi>after trying to package Firefox, I don't wanna touch the things related to Rust xD <nckx>Pity. Not that I blame you. <nckx>...Rust's test suite just threw a poop emoji at me. It knows. <nckx>..thread '<unnamed>' panicked at 'index 5 and/or 8 in `"aĂŠ đŠ"` do not lie on character boundary' <raghavgururajan>That changes other definitions. Review burden and also, I am too lazy to mentioned in the commit message as to why there were changes to other defs. <nckx>It's still tedious. raghavgururajan: Did that patch work? Then I'll commit it. <raghavgururajan>> ânckxâ: I'll copy Rust to bayfront. I'm still building 1.31.1 though. This will take a while <nckx>raghavgururajan: I'm copying rusts 1.19 â 1.30.1 (wow, that's a lot of Rust) now. <nckx>If âguix importâ succeeds. Its currently using 30 GiB of RAM... <nckx>Bah, guix import demanded more than 50 gigs o' RAM & died. *raghavgururajan 's head spins <nckx>This is to import a 4.7G archive. That's big (and maybe outside of the intended use) but not that big. <nckx>I could post that on a DVD. <apteryx>nckx: eh, 'interesting' :-). You should log an issue about it! <nckx>I'll keep the offending archive and try to remember. <raghavgururajan>nckx: Could it be because I was running `./pre-inst-env guix build rust@1.23 --cores=32`? <nckx>Ah, I saw all CPUs light up and wondered what that was. *raghavgururajan got greedy when nckx mentioned that bayfront has 32 cores <nckx>If you hadn't done that it might have been killed a few seconds later. <raghavgururajan>nckx: Is there a way to see running `guix build` processes? Yesterday, I `bg` ang `disown -ar` after running `./pre-inst-env guix build rust`. Not sure, if it is still running. <raghavgururajan>nckx: If you see any gnome-related build processes, please kill them all without mercy. <nckx>Yeah, that's next on the list. I'm currently trying per-rust-version guix archive --imports, which (cross wood) seems to work. <nckx>It's just... sigh... that both archive & copy fail so badly the first time I have a non-toy use case for them. <raghavgururajan>nckx: Btw, you can use bootstrapped guix at /home/raghavgururajan/guix/wip-desktop <nckx>Thanks, but I have my own bootstrapped copy. I'd rather not step in each other's stuff like that. On a more technical note, it could hide bugs/wrong assumptions. <nckx>OK. Of course the daemon is running with -no-substitutes. I want --yes-substitutes. What's the option for that? <pkill9>it should probably be renaned --disable-substitutes and --enable-substitutes <nckx>I mean, I know that one can override this at the RPC level, so it's not a security feature, but it doesn't seem to be exposed in the CLI. <nckx>--{no-,}foo is more conventional (and hence less surprising and hence good) but I don't really care. Since we already support --no I don't see much reason to switch though. <nckx>Oh praise the jeez, fifth time's the charm! To think it was as simple as starting a second Guix daemon listening on a different GUIX_DAEMON_SOCKET, and using that to download substitutes đ *raghavgururajan gave some internsive work for nckx <raghavgururajan>nckx: May be, [1] Create config-copy.scm, with enabled substitutes in guix-service. [2] `guix system reconfigure config.scm` [3] Restart guix daemon [4] get substitutes and gcroot stuff [5] guix system roll-back [6] remove config-copy.scm <nckx>raghavgururajan: I don't follow. I'm done. Rust has been downloaded from g.t.gr and is currently being grafted on bayfront. <nckx>I can't reconfigure the system or kill the running guix-daemon since that would kill others' running builds (including someone's ungoogled-chromium, they'd be rightly miffed if I killed that for no reason). Instead, I started a second daemon at a different address (socket file name), and used âGUIX_DAEMON_SOCKET=/tmp/ffs guix build ...â to talk to my daemon instead of the system one. <nckx>I mean, no, it's horrible and shouldn't be needed and doesn't make âsenseâ, but it works đ <nckx>raghavgururajan: Anyway, Rust up to 1.30 is ready and I'll âcopyâ later versions as they are completed here. <apteryx>raghavgururajan: what branch are you trying to build? <apteryx>I thought it was a dependency for another leaf package <nckx>It's the full bootstrap chain :-/ <apteryx>what branch is wip-desktop based oN? <nckx>05f3d34094b23dc9612ff6641a0257bc4f7dcd12 from master. <apteryx>if I can build guix itself: error: gnu/services/desktop.scm:1301:4: no value specified for service of type 'accountsservice' <apteryx>on the wip-desktop branch as it exists on savannah <alextee[m]>umm, how do you get the source dir in the (replace 'install) lambda? <alextee[m]>i need to install some files from the source dir directly <apteryx>raghavgururajan: is this branch up to date? I get the same error even after a make distclean <nckx>apteryx: I'm building from 7060754ffd88275693801954b9dcd00559f32f72, try that I guess. <nckx>Reset hard, bootstrap hard, build hard. ***terpri__ is now known as terpri
<apteryx>weird, I get the same error from the commit nckx mentioned <apteryx>I was just trying to build guix on that wip-desktop branch, 'make' <nckx>raghavgururajan: What was the highest version of rust you needed? <nckx>.30 is ready, off to bayfront it goes. <nckx>alextee[m]: (assoc-ref inputs "source") is the package source, but it can be in any format, tarball, git checkout, ⌠<alextee[m]>nckx: thanks! let me try that. it's a git checkout <raghavgururajan>apteryx: May be use 4ea5be9471b413393b3f1d299753f5d995611b93 . The last two commits has changes to desktop.scm <nckx>alextee[m]: Build systems are free to build things in subdirectories, I believe that Meson & CMake do so. I think both use ../source (but am not positive). Otherwise, the source is simply in the current working directory. <alextee[m]>always wondered what this does: (#:key inputs outputs #:allow-other-keys) <raghavgururajan>Looks like I need to use procedure instead of type, for accountsservice. <nckx>Phase lambdas are called with various keyword arguments (-> should be documented in Guile manual) such as inputs, outputs, make-flags, and more, but you can only access them inside the Îť if you explicitly request (bind) them like that. <nckx>raghavgururajan: Yes I did. <alextee[m]>it's weird that when you change the replace install phase only it still goes over the rest of the phases <raghavgururajan>nckx: On bayfront, `./pre-inst-env guix build rust@1.31` shows build-lock. <nckx>It would add significant overhead (time but mostly space, saving the entire source tree for each phase, and space is already our weaker point) but could be done! <nckx>raghavgururajan: Probably mine. <nckx>raghavgururajan: No, I'm substituting it since nothing else works. <nckx>So âguix buildâ so takes locks, but not for long. <NieDzejkob>wait, does this mean that bayfront has authorized g.t.gr? <raghavgururajan>After seeing that picture, I was like fuck other desktops, Hail GNUStep! <nckx>NieDzejkob: You will get no substitutes on bayfront unless you use my sekrit socket. Please don't. <nckx>raghavgururajan: Is Guix's gnustep package at all usable/up to date? Never used it, but tried to package it once as a dependency and it was not trivial. <NieDzejkob>ah, that's not what I'm getting at. I once needed something on bayfront that I already built on my computer and I was wondering if there was a way of copying that without bayfront having to trust me <nckx>raghavgururajan: It looks very very much like what I remember GNOME2 looked like. Is that the default look? <nckx>NieDzejkob: You should be able to use âguix archive --import --authorizeâ which as I understand it does not add your key permanently to /etc/guix/acl. <nckx>That's what I actually want to do, but it gobbled up 40-50 GiB of RAM and died. <raghavgururajan>Never mind! I misread the description on GNUStep website. It is not a desktop ennvironment. It provides tools to build one. <nckx>raghavgururajan: Yeah, it's basically a broad toolkit, is my understanding. <terpri>\'etoile is an example of a gnustep-based DE, dunno how it's progressed <terpri>...last post in 2014, so probably not much since then <nckx>The only reason I know of GNUstep at all is because it was a dependency of The Unarchiver, which I once wanted to package for Nix, ages ago. But then I found another tool, no clue what it was, with less dependency. <raghavgururajan>GNUstep is an object-oriented tool development kit, a graphical development kit and a cross platform development environment. GNUStep is not a desktop, not an operating system clone and not a window manager. <nckx>So I see it as something like Qt. <terpri>of course, you can run gnustep apps under windowmaker and get a NeXTish experience (or appearance, anyway) <terpri>one problem with gnustep: gcc hasn't kept up with clang's objective-c(++) extensions so gnustep now effectively requires clang iirc <nckx>Wow, I remember that sidebar/dock/whatever. <nckx>I definitely tried this when I was a wee lad. <nckx>How nice that it still lives. <terpri>yes, it seemed dormant for a while but started getting updates again in the last few years <raghavgururajan>nckx: Wowza! The latest release of windowmaker was on 04.04.2020. The project is so active <nckx>nckx's late 90s Slackware box. <raghavgururajan>nckx: Looks like GNUStep/NeXTSTEP were already following Human Interface Guidelines (HIG). Things look so simple and easy to access. *raghavgururajan is *definitely* going to *try* to develop guix package-management GUI front-end with GNUStep <nckx>alextee[m]: Congrats! Looks nice. Sounds good? *raghavgururajan joins #GNUStep and #WindowMaker *nckx killed a pointless bayfrontial Rust build, whoever's it was. <apteryx>fun fact: you can run guix environment without any argument <apteryx>raghavgururajan: the commit you gave me seem sto build <raghavgururajan>nckx: That was mine. Accidentally started it. Thanks for killing it. <apteryx>I'm squashing all the rusts ...1.29 into 1.29 <apteryx>Formbi said that mrustc could build 1.29 directly, so that'd means we do not need the older rusts anymore <apteryx>we can start the bootstrap chain from mrustc -> rust 1.29 -> ... <nckx>I didn't get the version number part, but maybe you made the same typo I made earlier (1.19)? <nckx>apteryx: Did you see my link to the relevant issue #? *raghavgururajan 's birthday today and receives rust toolchain compilation as a gift from nckx <apteryx>nckx: ah, so it's already done, just waiting review and an non-deterministic issue at building texinfo <nckx>Oh, happy birthday Raghav. <nckx>apteryx: Well, it's not clear to me how serious the âjustâ non-determinism is. Just didn't want you to waste time. <apteryx>nckx: thanks, i was indeed going to waste a lot of time ;-) <nckx>berlin nodes aren't exactly low-core so I wonder what's up there. <nckx>apteryx: Trying out Danny's patch (does it still apply? does it build on your machine?) would be valuable though, and serve as a high-quality ping đ <nckx>Sorry, didn't mean to sound like I was delegating, but you seemed invested in Rust and wanting to show off how fast your machine was so... <apteryx>eh, I'm an Icecat user, I guess that makes me at least somewhat invested in Rust. <raghavgururajan>Why does accountsservice-service-type asking for a value? Look like I have to use accountsservice-service procedure after all. <nckx>raghavgururajan: The totally undocumented accountsservice-service-type is missing a default-value field, so Guix doesn't know what to use. <apteryx>nckx: the patch doesn't apply on current cu <raghavgururajan>error: Server does not allow request for unadvertised object 2d431ac35c4943a3655c07ba91870d2323321b43 <nckx>I'm not familiar with this service or the underlying software (I read the docstring, that's it). I wonder why it doesn't declare a -configuration record as is standard. <raghavgururajan>Shoot! Didn't mean to post that error here. Middle-click paste happend on Gajim. <nckx>raghavgururajan: You will have to use a branch or tag (so-called ârefsâ). <nckx>Well, you got an answer anyway because this is #guix and we are helpful screw you. <butterypancake>nckx: You're still planning on looking at my openrc patch right? I'm not trying to nag, it's just I've never had to wait more than like half a week for a review before (You guys do spoil me). Does this patch have to go through extra scrutiny because it's touching more stuff? <nckx>butterypancake: No such lofty reasons. It was not on my to-do list and now it is. <nckx>butterypancake: Your patch is important to us and will be dealt with presently. <nckx>butterypancake: Thanks for the compliment but patch review speed (and general not-forgetting-them-for-a-year) is really our weak spot. You got lucky. <raghavgururajan>Can it be used to manage services on foriegn distros? In know it cannot be done on Guix System (Hail Shepherd!). <nckx>raghavgururajan: Oh no no, it's just an extra clause in guix-install.sh that adds a guix-daemon service for OpenRC. Like we already have for sysvinit and systemd. <nckx>It's not guix/shepherd<->openrc integration. <nckx>But still very welcome since a first impression that won't run isn't a very good first impression. <raghavgururajan>This is really good. Guix can now be run on OpenRC (non-SystemD) distros. <butterypancake>nckx: I'd like to start triaging a few of the older open issues but I feel like it would be a little pretentious since I'm still not that great at Guix (yet). I'd also then need to somehow grab the attention of someone with commit access to look over my prognoses, and I'm not sure the best way of doing that. I don't want to just CC my favorite person everytime because that'd be unfair <butterypancake>raghavgururajan: you give me too much credit. Others made guix work with other init systems and I just rode on the shoulders of those giants to add one extra init system <raghavgururajan>butterypancakeâ, You did something that needed to be done. It's good. <nckx>butterypancake: I understand. What some have done in the past is ping issues that end with a question from âourâ side, but never received a reply. Just sending a âHi! Have you had time to {reproduce,investigate,...} this yet?â. <nckx>Or for old bugs about old versions of software, âHi, is this still a problem?â. <nckx>And mention a deadline or something for closing forgotten issues. <nckx>Often the reply will be âI no longer use Guix lolâ and that's not fun, but oh well. <butterypancake>well a good number of issues are like 30924 where the submitter never resent in the patch with a few trivial changes. I could easily make those changes. <nckx>butterypancake: Totally arbitrary example from the front page: https://issues.guix.gnu.org/27372 - doesn't matter that it's Ludo', go ahead and ask whether and why this âhigh-priorityâ bug from 2017 is still an issue. đ <nckx>It would be nice if the Issues UI differentiated between âdoneâ (âfixedâ) and âclosedâ (âsubmitter never repliedâ or myriad other reasons). I don't know if debbugs itself does. <butterypancake>everything in debbugs seems to be different colors but I'm not sure why :P <nckx>âWe hope you like blue.â <nckx>issues.guix (âMumiâ) is a Guix-specific front-end to that. <butterypancake>oh shoot, totally forgot the backend is called debbugs and we should probably be saying different words for our front end interface :P I'm using the debbugs emacs package <nckx>butterypancake: Using C-u C-x = to look up the face names (a hack, I know): yellow is stale, red is new, green is âhandledâ. <butterypancake>so if I reply to an issue, it won't be stale anymore, but it'll still be at the bottom of the list so I still doubt anyone would see my reply :P I'd rather not just spam the IRC with 'plz look at what I did' but currently it sounds like that's what triaging will be like <apteryx>butterypancake: you have to hit S W to send a large reply to the issue and everyone involved in the thread. <butterypancake>this is pretty cool. Just gotta add or find the evil bindings, and this'll be pretty damn ideal <apteryx>that's one problem I have with Mumi right now, is that it doesn't send wide replies, which means the mail won't reach my mailbox and I'm likely to not notice about it. <nckx>âDoubt anyone would seeâ: remember it's just e-mail. You CC the interested parties (and the bug address). They need never know what a debbugs is (many don't). <nckx>I never use emacs-debbugs, just mu4e, and get everything in my mailbox. <butterypancake>ya, I can contact the person who submitted the bug easily, but once I come to a resolution, I need to notify a comitter. Notifying a commiter is the step I'm not sure how to do <nckx>Hm, right. The committer will still have to review the patch (no slight on you) & sign off on the patch, which is totally Work, or I'd just say ping me đ But I don't want to be a bottleneck. <nckx>Replying to a bug will send a new message to everyone subscribed to the bug list. I can't imagine many committers who aren't. Maybe that's enough. *vagrantc isn't subscribed fwiw <vagrantc>not that i tend to review patches much... <nckx>'s What I was going to say đ¤ *NieDzejkob prefers to peek into the archives every once in a while :P <butterypancake>well debbugs has states right? Can't we have a state that's "awaiting review" <nckx>I was going to suggest that but someone told me you can't use arbitrary tags in Debbugs, only a short hard-coded list. <nckx>Maybe they were full of 'it. *nckx looks for a random bug to tag <NieDzejkob>Rust's bug/patch tracker has many nice tags and they're a godsend. S-waiting-on-review, S-waiting-on-author. A-tags mark code areas <nckx>raghavgururajan: Could you test this trivial patch? https://paste.debian.net/plain/1160413 I know it builds, but you're likely more familiar with what the service actually does (and how to notice when it's broken). <NieDzejkob>if debbugs doesn't support custom tags, we can maintain this state on top of debbugs in issues.guix.gnu.org <nckx>We could overload e.g. âpendingâ (no idea what that's âsupposedâ to mean) or âconfirmedâ to mean âcommitter wantedâ. <nckx>We don't actually use them for their intended purpose in practice. <apteryx>debbugs supports user tags, I just tried <nckx>apteryx: Can you elaborate? The docs [I have] don't mention user tags or usertags or user in general. <apteryx>docs may not be complete (they don't mention anything about colors, for example). In M-x debbugs, you press C on a bug, select usertag, leave 'guix' as package name, then proceed to put whatever tag you want. *nckx reinstalls emacs-debbugs, sigh. <nckx>I was looking at the Web docs. <nckx>Installing a client to look up server docs is weird to me but OK. <butterypancake>why is emacs-debbugs needed? Is that the package the debbugs info pages are bundled with? They're normal info pages <nckx>butterypancake: âinfo debbugsâ is provided by âemacs-debbugsâ. Not sure bundled is the right word. <nckx>What else would provide them? <butterypancake>idk how this stuff works. The texi files are in the emacs-debbugs repo so I see why they're distributed with emacs-debbugs. Still feels like they could be useful on their own though <nckx>Documentation for Web services should be on the Web... no? âguix install wordpress-manualâ? Surely not. <nckx>(Not talking about people who run their own Wordpress there, *obviously*.) <butterypancake>I have terrible internet so plz have offline documentation at least avaliable <nckx>We seem to be talking past each other. <nckx>You can't install GNU's debbugs server on your machine. So the documentation should not be provided in a random emacs interface to that server. <butterypancake>oh I see. Ya I misunderstood. I agree a debbugs-manual would be a good package. It might be messy to detangle from the emacs-debbugs repo though <leoprikler>shouldn't the debbugs server manual be bundled with the debbugs server tho? <leoprikler>(not specifically the GNU one, but the software to spawn your own= <butterypancake>the emacs-debbugs repo has both the debbugs manual and the debbugs-ug (userguide) manual <leoprikler>and which of those describes the emacs bindings? <nckx>butterypancake: The problem is that âinfo debbugsâ isn't a manual for debbugs, it's a manual for *emacs-debbugs*. Read it: âInstalling debbugsâ doesn't tell you how to install debbugs, it tells you to visit ELPA 𤌠<nckx>That's like calling a client emacs-mastodon, then hijacking âinfo mastodonâ and âHow to install Mastodonâ to describe your obscure little client. <butterypancake>oh ya. I was confused because most of it is describing programming interface and stuff. It's quite unlike most emacs manuals. There's no fluff. Is it really and emacs manual without fluff? <nckx>Ah, it's at least explicit: âdebbugs', described in this document, is the Emacs library that exposes to developers the available functions provided by the Debbugs server.â <nckx>Still needlessly confusing. <nckx>that's what I meant by âthe docsâ above. <nckx>AFAIK these are the canonical docs for the canonical (=server-side) software actually called Debbugs <nckx>So now I guess the question is: is this âuser tagsâ business just an emacs-debbugs specific thing? Does it even propagate to the server? <nckx>The âuserâ part doesn't fill me with confidence. <butterypancake>well I would just clone the debbugs software and read the readme but I keep getting timeouts :/ <butterypancake>I am cloning from debain.org though, is there a gnu one on savannah? <nckx>Is that the one you're cloning? <butterypancake>yep. but it might be my internet that's stopping me. The third try is showing a little more spunk than the first two <nckx>It's cloning at ~80k/s here. *nckx stops cloning. Maybe I'm stealing half of their 160k/s total bandwidth from you! <butterypancake>nah, I finished. but grep -ir "user tags" didn't yeld anything... <nckx>Try without the space if âsourcecodeâ is any indication, but I'm not hopeful. <apteryx>nckx: yeah I haven't seen the test tag appear yet either... I wonder if it'll work. <apteryx>load average is currently 70 on my build machine <butterypancake>what command did you send? The docs say it should have been something like either `usertag 23423 epictag' or `tags 23424 + epictag' <nckx>butterypancake: The former is what I sent a few minutes ago. *nckx refreshes hopefully. <apteryx>nckx, butterypancake: Should have checked by inbox, I recieved errors from my Debbugs command <apteryx>the command that failed was: 'user guix', which appears to be necessary before issuing 'usertag 40134 test-tag' <butterypancake>So the tags are hardcoded in a config file that I assume you can change if you really want to <apteryx>the error is: Selected user id (guix) invalid, sorry <nckx>Shit, removed all mail addresses but my own 𤌠<nckx>I don't know. I don't know where to look. I'm currently waiting for the Web interfaces to sync. <nckx>Maybe only me@saibot.rg can now send a mail to ask what me@saibot.rg's flags are. Which would be pretty useless. <apteryx>yeah, I don't understand what usertags are supposed to be, put perhaps it was a mean to sync *local* (private) tags to the server <butterypancake>in the emacs-debbugs the example users it gave where "emacs" and stuff like that <nckx>I don't want you to be right, but that's also what I think. <butterypancake>We can add more real tags by modifiying the config file on the server that's hosting debbugs. The default config file location is /etc/debbugs/config (maybe) and in there, there is a line like Tags = ('patch', etc etc... ***apteryx_ is now known as apteryx
<nckx>butterypancake: That would be a GNU-wide change. Not impossible, not ideal. <butterypancake>why are we sharing a server? We have to maintain CI servers anyways, so why don't we maintain our own debbugs instance? Seems like a single point of failure to me (maybe they have good backup machines and I'm wrong) <vagrantc>does the version of debbugs on gnu.org support usertags? because then you can implement arbitrary tags without changing configuration <apteryx>nckx: apparently there's M-x debbugs-gnu-usertags <nckx>vagrantc: Did you follow the discussion so far? Because the consensus is that nobody has a clue what user tags are đ <apteryx>I could see my last successfull attempt <apteryx>seems I was right about it's a per-user thing <nckx>OK, yes: me@saibot.rg darntootin â RET â 42816 <apteryx>we could share the same user, but it's a kludge <apteryx>the doc says a package name should be accepted, but 'guix' didn't work <butterypancake>is there a global config for users and GNU doesn't care about us enough to put us in? <apteryx>That's how emacs seems to make use of it: user emacs (example from the doc) <apteryx>butterypancake: no no, we are in there. The person managing the Debbugs instance of GNU is very nice and manages both creation of the trackers and taking care of the hard coded lists in emacs-debbugs. <apteryx>see the debbugs-gnu-default-packages defcustom variable in debbugs-gnu.el. <apteryx>I recently had 'anubis' added (GNU Anubis), a mail daemon scriptable with Guile. <butterypancake>well that's one hard coded list. Maybe they missed us in a different list? Or maybe users need authentication to post a usertag as someone else? <vagrantc>nckx: i've only dropped in here and there <apteryx>butterypancake: we'd have to study debbugs-get-usertag <butterypancake> User tags, applied by the Emacs maintainers, are shown by M-x debbugs-gnu-usertags <vagrantc>nckx: there's a difference between tags, which are configured in debbugs itself, and usertags, which allow people to send control messages to debbugs that include arbitrary namespaced tags <butterypancake>I really think there is some maintainer list that people need to be on to set usertags <vagrantc>nckx: no idea how they're implemented under the hood <nckx>vagrantc: But how can we create, say, a âguixâ user that everyone can use? <nckx>butterypancake: If you have to be a maintainer to set user tags there's little point in using them as âcommiter-wantedâ flags, which is what started all this. <vagrantc>nckx: you can use whatever values for user and usertag you want <vagrantc>nckx: but i don't know if it's a core feature of debbugs or some add-on that debian's infrastructure implements <nckx>User tags are definitely supported, not sure about the header interface. <butterypancake>when you send control messages to debbugs, do you send to bug email or the global email? <vagrantc>the "Control:" meta-header was established in debian's infrastructure to be able to just include it in the relevent bug email address <vagrantc>nckx: before "Control:" was added, you'd have to cc or bcc control@bugs to mark tags <apteryx>the debbugs-get-usertag docstring says users can be package like "emacs", "coreutils", "gnus" or "tramp" (examples). Only (debbugs-get-usertag :user "emacs") returns entries. <nckx>This is all extremely complicated. <butterypancake>You just gotta set the user to guix@debbugs.gnu.org instead of guix <nckx>s/complicated/ridiculous/ <nckx>butterypancake: How do you query it? <butterypancake>your usertag worked too. When doing C-u debbugs-gnu-usertag and putting in me@saibot.rg I see your user tag <apteryx>butterypancake: user can be *anything* <nckx>butterypancake: Honestly not a bad tag name for committer-requested. <apteryx>as long as it's a mail address, apparently <apteryx>I wonder how emacs gets the special treatment of supporting putting the package name directly, e.g. 'emacs'. <butterypancake>It's probably some alias that's hard coded. I do think we're not in a hardcoded list that we really should be in <butterypancake>the error I get when trying to do user guix stuff is 'Selected user id (guix) invalid, sorry' which doesn't sound like an authentication problem to me <butterypancake>has anyone managed to actually find an issue from looking at a usertag? I can view usertags, but not what bugs they're attached too <nckx>Evil rebinds RET? That is evil. <butterypancake>being a vim guy in emacs I really feel like a second class citizen <butterypancake>it only rebinds it in normal mode. So I can get around it by going into insert mode before hitting enter :P <apteryx>I asked the question to help-debbugs@gnu.org about whether it should be supported to use 'guix' as a package when creating usertags. <butterypancake>nice! but did we ever actually figure out where the documentation is? <nckx>I think we learnt that the real documentation is the friends we made along the way. <apteryx>butterypancake: for the Emacs interface to Debbugs, the source code is most helpful to get the juicy details. <apteryx>C-h f debbugs-get-usertag for example <apteryx>then there are the info manuals that comes with it <apteryx>for the server itself... I don't know. <butterypancake>ok, but no one told me how to send emails to control@debbugs.gnu.org. I honestly just kinda guessed. Where is that documentation? <butterypancake>ok, but actually that documentation says nothing about usertags so I think it's outdated. good <apteryx>the point of the Debbugs interface is that you don't need to know these implementation details ;-) <apteryx>the documentation of Debbugs itself (if it exists) should cover this <butterypancake>debbugs the back end or debbugs the emacs front end? I'm confused <apteryx>by Debbugs itself, I meant the backend (server) <butterypancake>So how does not telling me what the interface is help me not know the implementation details? <butterypancake>oh wait, I misread your one sentence. my bad. The documentation should cover this but doesn't. so I'm upset <butterypancake>that page says the user has to be an email. So I'm pretty sure emacs is just an email alias in their system <butterypancake>and people wonder why everyone flocks to githubs forge. It's so much easier to work with. Although now that I think of it, you probably could completely recreate the github forge using debbugs as your backend and then people would have an option to use either the forge or email.... that'd be really cool actually. Not sure how you'd set up authentication for the web interface though... <apteryx>butterypancake: that's exactly what MUMI is trying to do, I believe <butterypancake>oh ok, I get it. It's the forge environment you run on the server <apteryx>well, it combines both the bug-guix and guix-patches trackers, IIRC. <pkill9>butterypancake: there is gitea for self-hosted github clone <pkill9>and there is sr.ht that lets you interact via web interface or email 
