IRC channel logs
2023-12-09.log
back to list of logs
<ieure>Hmm. My work gave me an AWS Workspaces setup which runs Ubuntu. I installed the guix package Ubuntu ships, but `guix pull` fails with: "guix pull: error: while creating directory `/var/guix/profiles/per-user/ian.eure@aws.mycompany.com: Permission denied" <ieure>And indeed, my system username is some kind of fake email address. <ieure>Okay, this is just a completely wack-ass distro, this is almost definitely not a Guix bug. <ieure>`whoami` reports "ian.eure", but all the environment variables are "ian.eure@aws.mycompany.com" <ieure>Resetting the environment variables fixed it. <ieure>What a ludicrous Linux setup. <ieure>But it's this or macOS, soooo.... <ieure>I want to make a guix home service which launches a program when I log into a graphical session. Is that a reasonable thing to do, or... not <ieure>Mmm, I think this redshift service more or less does the same thing as I want, that's probably what I should be looking at. <civodul>nckx: hi! could you add a note in infra.org about the rsync thing? <ieure>Kolev, Too hard to tell from a diff, can you paste the raw file? <civodul>nckx: so thanks for restarting it, as always! <ieure>Kolev, Also whatever error you're getting trying to reconfigure. <Kolev>ieure: the unbalanced file? Ok <civodul>ieure: i think the part of the API there is deprecated but still valid as of 0.10, no? <ieure>civodul, Well, it complains that <service> isn't available and tells me to use the (shepherd services) module, which I'm already using. <civodul>ieure: weird, that part definitely hasn’t changed <ieure>Kolev, for services, You're calling (append (list ... %desktop-services)) instead of (append (list ...) %desktop-services) <ieure>The error you got has nothing to do with unbalanced parens. They are balanced, but the arguments are in the wrong place. <ieure>Feels nice to know enough to lend a hand now and then. <Kolev>I always get confused by misplaced (()). <nckx>civodul: The issue was on gnu.org's end, not ours. <nckx>The command is in root's history on berlin but contains a password. <ieure>ci.guix.gnu.org seems to be horked again, 504 gateway timeouts on all my requests. <oceane>hi, i can't seem to build a local bibliography with biblatex? <oceane>moreover, xelatex isn't found if i don't install the full texlive binary <oceane>so i was thinking about maybe installing just the packages i needed to see if it solved the issue? <oceane>but unfortunately, xetex complains about the lack of a xelatex.fmt file <oceane>i've tried every solution i've found for the last 20 minutes <oceane>hmm, or rather, for the last hour <oceane>hmm so to describe my problem with xelatex, it basically gives me entries as (oceane_comment_2023) instead of (Océane, 2023) <oceane>i.e., entries are printed “as is” in the pdf document <oceane>oh and i've installed the texlive-collection-{latex,xetex} packages <apteryx>oceane: I've used xelatex in at least one package definition to build the doc <apteryx>ah, it's called python-ipython-documentation <apteryx>it includes texlive-latexmk, texlive-polyglossia, texlive-xetex and texlive-xindy <PotentialUser-97>Hello. I just tried to resubmit a patch series that apparently failed to submit a couple days ago and it failed again. Can someone please help me understand what I am doing incorrectly? Here is a paste of the response email I receive https://paste.debian.net/plainh/bc4929de <PotentialUser-97>series so I'm wondering if I missed something. I know there have been some issues recently with the issue tracker, but it looks like it's working again. <apteryx>PotentialUser-97: the URL is @gnu.org, not @debbugs.gnu.org <PotentialUser-97>The docs say git send-email outgoing/0000-cover-letter.patch -a --to=guix-patches@debbugs.gnu.org $(etc/teams.scm cc-members ...) <apteryx>after the issue has been submitted, you'll get back an email for the issue, which *is* suffixed with @debbugs.gnu.org <apteryx>but the original submission goes to guix-patches@gnu.org <PotentialUser-97>Right, so then when I submit the actual patches I'm sending them to @debbugs.gnu.org using the issue number right? <apteryx>ACTION needs to find a new email provider... gmail takes ages to fetch 100 KiB of mail <apteryx>PotentialUser-97: if you use a cover letter + series yes! <apteryx>you could also try 'mumi send' that automates the process <apteryx>but it's still beta (beware of bugs) I'd say <PotentialUser-97>Thank you for your help, it looks like the mail was sent properly that time (at least I didn't get an immediate failure email) <PotentialUser-97>I just got confirmation that my patch series was correctly submitted. I'm glad to know about that devel version of the docs. <apteryx>it's the same as 'info guix' locally <villageidiot>Hey there, I'm wondering if anyone knows why the "zerotier" package is no longer in the guix repo. I was using it for work before but now it appears to be gone. <villageidiot>Also the StumpWM entry in the Guix Cookbook appears out of date. Reconfiguration will complain about `sbcl-ttf-fonts` being unbound. I guess it should be replaced by `sbcl-stumpwm-ttf-fonts`, but then I get a different error: "In procedure append: Wrong type argument in position 3 (expecting empty list): #<package <villageidiot>sbcl-stumpwm-ttf-fonts@0.0.1-5.4613a95 gnu/packages/wm.scm:2342 7f7bdc3719a0>" <xelxebar>I packaged it up and have been using it for a while as my hosts-file. <nckx>xelxebar: Well I didn't yet :) <nckx>Do you sexpify it first? <xelxebar>nckx: Not yet. Just plainly using the built etc/hosts and feeding that to the operating-system hosts-file. <xelxebar>Not sure about the best way to sexpy it up. Parsing the file downstream would work, but I think doing something upstream could be nicer. <nckx>I'm not saying you should. It's the kind of thing I'd do only to moan ‘whyyy, which idiot made this stupid decision’ half an hour in. <nckx>Then again, if you had, I'd wanna see. <attila_lendvai>ACTION hopes civodul will say something about the guile 2 vs 3 requirement for shepherd <bongo>anybody familiar with nixOS and can compare it with guix? idk what its like but i use nix <tex_milan>Hello folks! How can I add my entry to /etc/pam.d? I tried to use simple-service ("pam.d/xxx" ,xxx) but that failed on some symlink error. Any idea? <lilyp>There are multiple pam- services defined <dariqq>hi how can i close an issue (that i created) that is no longer relevant? I tried sending a control message 2h ago but I think this did not work as i did not receive a reply and the status was not updated. Or is it just that debbugs may take some time? <lilyp>I'd say may take some time, but to be on the safe side, you did check that the recipient address is correct, right? :) <dariqq>I sent to control@debbugs.gnu.org , is that correct? <nckx>If you sent mail to that (correct) address, debbugs will reply regardless, even if it failed to parse your mail. <tex_milan>@lilyp thanks, found it and learning from them <dariqq>nckx: hmm i did not receive a reply from debbugs <nckx>I'd wait a bit longer. Your mail might be stuck on the receiving server for a few hours, or debbugs might have a tummy ache and is taking a nap. <oceane>ok it seems totally related to xelatex, i'm going to dig in this direction <oceane>ok, found the problem, i have no author-year citation style on my machine <oceane>so i've installed oxref and everything works now through the oxyear citation style <attila_lendvai>lilyp, master. i pulled it recently. it has either built now, or the substitute became available, because the system reconfigure has finished. <nckx>Substitute aside, I can't reproduce a test failure. <attila_lendvai>services: activate-users+groups in activation.scm is run without considering service requirements. my service specifies a user with a home dir that only becomes available after file-systems is started. what am i to do? <civodul>attila_lendvai: just replies re Guile 2.2 in the Shepherd :-) <attila_lendvai>i just got distracted by the annoying cutoff in the guile backtraces... and the lack of readline support in the guile that runs shepherd (and lands in the debugger for me when i try to boot a server of mine) <civodul>efraim: did you eventually get glibc-locales to build for powerpc-linux? <nckx>civodul: Is this truncation not seen as a problem by the Guile project? <civodul>“the Guile project” is a strong word :-) <nckx>I've considered sending a patch that disables it in Guix but that would look antagonistic. <attila_lendvai>civodul, how come (ice-9 readline) is not available for the guile that runs shepherd? where is that decided? is it because it's not included in the initrd? <nckx>Well, ‘on the Guile side’, of the divide you straggle :) <civodul>it’s complicated because you wouldn’t want to dump entire bytevectors either <civodul>so perhaps the better option would be to check (isatty? (current-error-port)) <civodul>and if #f, set COLUMNS to a large value <nckx>Or bytevector? thing, but that would get more complicated faster. <civodul>there’d still be truncation but it’d be more reasonable than 80 chars <civodul>bytevectors are the typical example but the same goes for any data structure <attila_lendvai>a print-length of 10+ would be so much more useful, and still bearable with a reasonable print-depth. CL has this thought out more or less... <nckx>ACTION not familiar with CL or any other Lisp, so not familiar with the state of the art in backtrace printing. <attila_lendvai>nckx, then let me tell you that a Slime+SBCL experience is uncomparable to what we have with geiser and guile <nckx>Why does that always mean ‘incomparably better’… <attila_lendvai>i even looked briefly into writing a guile backend for slime. even a partial backend would result in a much better experience. <nckx>I was looking at terminal-width itself. <nckx>I know, more ‘controversial’, but why not? <civodul>problem is ‘terminal-width’ is initialized too early <nckx>(I'm not familiar with the Guile codebase at all.) <civodul>or we could parameterize it in ‘display-backtrace’ maybe but uh <attila_lendvai>nckx, to me guile feels like a lisp written by primarily C hackers. while slime and sbcl are both written by primarily lispers. guile is shaped by a specific use-case, it's not really a general lisp impl. <civodul>Guile hackers will appreciate that comment :-) <nckx>I think my brain has been permawarped by Guile being my first—*remotely*—ever ‘Lisp’ :( <attila_lendvai>civodul, that looks reasonable. but what if the terminal is narrow? even then i'd prefer some wrapping to eager cutoffs making backtraces useless <civodul>so maybe there could be a minimal width? <attila_lendvai>civodul, honestly, i much more prefer ugly wrapped backtraces to ones that miss important info. <civodul>it all sounds pretty arbitrary i admit, but there has to be some cutoff somewhere <attila_lendvai>in lisp most of the bugs can be fixed by a glimpse at the backtrace that reminds you of a situation you didn't consider <nckx>civodul: I'm going to defer to you on the subtleties of how globally to apply this (I've never heard complaints about anything but backtraces, maybe that's enough), but I was intuitively going to set a default of 1024 or so. Maybe we could compromise on ~500? 250 isn't even a full screen width in many places. <civodul>and if a single frame spills over many lines, the backtrace is arguably unreadable <attila_lendvai>civodul, in most situation i can still copy-paste that frame into an emacs buffer and see it properly formatted <nckx>I'm happily looking forward to the first bug report of a crucial keyword being pushed out of view by a 487-byte URL string or whatever. <civodul>if Guile 3.0.10 cannot be released soon, we can apply the patch in Guix <nckx>attila_lendvai: I want to ask but am not sure if I should. <attila_lendvai>nckx, the nicely fine-tuned linux OOM killer keeps killing my gnome session... <nckx>rm -rf ~/guile, I barely knew thee. <dariqq>nckx: it seems like you were right earlier today about my issue with the debbugs control messgae. it just now replied (6.5 h later) <nckx>I'm not going to bother them to ask, but it could have been related to other debbugs/gnu.org services dying yesterday. <nckx>issues.guix was out of sync for several hours. <civodul>attila_lendvai: i’d rather avoid it :-) (are there tabs in the code?) <civodul>ACTION tries “guix build hello --target=aarch64-linux-gnu -d --no-grafts” on ‘core-updates’ <civodul>now that we have substitutes for most of the basic things <efraim>civodul: I've been pre-seeding some of the builds on berlin <efraim>I figured it would be helpful and the x86_64 machines were idle at the time <civodul>news from glibc-cross-aarch64-linux-gnu-2.38: objcopy: Unable to recognise the format of the input file `/tmp/guix-build-glibc-cross-aarch64-linux-gnu-2.38.drv-0/build/libc_pic.os' 😟 <civodul>so the objcopy/objdump patches may need to be updated after all <pastor>Is it posible to use `--emulate-fhs` for a package definition? <pastor>It was make an easy wraper for tor-browser bundle until we have it packaged but I see it needs write access on the folder where it is located so never mind <nckx>You could make a wrapper package that writes a script that invokes a guix shell with the original package… maybe. <nckx>But facilitating the packaging of binary blobs (the main use case for --emulate-fhs, really) as packages themselves isn't a priority. <kotet>Hi, I have installed Boost through Guix. How can I link to the library? Do I have to use the path of Boost in the current profile? <kotet>(I'm not building with Guix but using a makefile) <attila_lendvai>civodul, there are quite some tabs, and a little trailing spaces, and missing EOL at the end, but nothing dramatic. i'll clean it up wherever i touch a file, but i will not do a general cleanup then. <nckx>kotet: Simply -lboost should suffice. Guix sets environment variables referring to boost if there's a C(++) toolchain in the same profile. <nckx>should contain a directory with boost/. <kotet>nckx: that's what I thought, but for some reason ld can't find boost. I have checked and the directory for boost is in CPLUS_INCLUDE_PATH <kotet>I'm using guix-home and have boost installed in the home profile, for if it changes anything <nckx>I'm not a boost expert, but I see there's no lib/libboost.so*, so indeed -lboost won't work, but -lboost_atomic etc. should. <nckx>kotet: But unless you're writing this Makefile as we speak based on my ramblings here (which I don't recommend), it should already use the correct library names. <kotet>Yeah, I'm writing the makefile now, I'm learning C++ and I don't have previous experience with boost, so my error may be not related to Guix at all <kotet>And you're right, I had to link against -lboost_program_options in this case, not -lboost. So it wasn't related to Guix. Thank you! <nckx>😃 OK, I wasn't expecting that. Happy I could nonetheless help! <PotentialUser-18>Can anyone help me respond to an issue conversation? I sent an email to the issue number @debbugs.gnu.org but I'm getting a "Relay access denied" error. <PotentialUser-18>I can send messages to other email addresses so I don't think it's an issue with my own authentication <apteryx>gmail is giving me a new itch to scratch: hosting my own email service. it's been intolerably slow in the last days <nckx>PotentialUser-18: Do you get anything more than that? And which software exactly is saying it? <PotentialUser-18>This is the only additional information I get "Failed to transport message. Server error: 4.7.1" <nckx>Thanks. That message isn't from KMail then. <evilsetg>I get an 'error: while setting up the build environment: cannot pivot old root directory onto '/gnu/store/<longhash>.drv.chroot/real-root' whenever trying to build something (on a strange installation setup that is). Does anyone know which procedure that might be? I tried grepping for the error and by bet is on the `pivot-root` call in `mount-file-systems` in `(gnu build linux-container)` but the error does not quite match. <nckx>PotentialUser-18: See PM. <nckx>Apparently 4.7.1 is also used by providers to signal you've exceeded your quota of outgoing messages (so not related to the recipient at all). Maybe your provider limits mails sent to the same recipient domain, so others still work? <PotentialUser-18>I saw that explanation as well, but I would be shocked if that is the case. I've only sent a couple of messages to the issue tracker over the past week. <nckx>Who hosts your mail server? (I'm not getting big business vibes, so at first I thought it was you :) <nckx>OK, since you were unable to send a message to my personal address, I'm afraid that I don't think there's much we can help you with. I'll check my server logs just in case but it's unlikely your server ever connected. <PotentialUser-18>Ok, I just sent another test message through the web interface to see if that goes through. <PotentialUser-18>Just trying to debug is this a KMail configuration error or something else <nckx>Nothing yet, nor any connection attempts in my logs (either successful or unsuccessful). <nckx>I think you're right that SquirrelMail is simply swallowing the errors or is not correctly configured to receive them in the first place from the local MTA. <PotentialUser-18>It's very odd, because I've been able to send multiple messages to guix-patches using that email through git send-email. <PotentialUser-18>Ok, so I've done something wrong when setting up KMail with this address. <nckx>I know nothing about your mail host, but some throttle ‘high volumes’ on ‘personal’ accounts. <nckx>Yeah, I guess that's possible. <nckx>I only ever got your Web interface test. <PotentialUser-18>I don't know why else it would fail in KMail and then work in the web interface a couple minutes later <civodul>ACTION tries ‘git merge master’ in ‘core-updates’ <nckx>PotentialUser-18: It is strange. I don't have any good ideas… <PotentialUser-18>nckx I think I got it resolved. I was able to send to my personal gmail and just sent you one final test message to verify I can reach other providers <PotentialUser-18>What it was is that KMail for some reason did not save my password for sending emails, only for receiving <nckx>Phew. Not the best error UX, but I don't know who was to blame. <PotentialUser-18>Final question: Is there any way I could get someone to manually remove the email I sent through my web client that got sent with the wrong address? I'd like to resend with the correct address just so the conversation logs are consistent on the issue tracker. <nckx>E-mail should still be relatively unshittified. I've heard stories about the tech giants not accepting mail from smol (smoller than yours, as in, personal) servers but I've yet to run into that myself. <nckx>We can't. We have to ask the GNU folks and last time I did they were extremely hesitant. I think they refused to do so ‘merely’ because someone used the wrong address. <nckx>If it's not a privacy issue, I'd rather not bother if that's OK. <PotentialUser-18>Yeah that's fine, no worries. SquirrelMail was just more barebones than I initially realized. It requires you to manually configure all of the headers for sending address, name, etc. so I ended up accidentally sending with just username@mywebsite.com. The username is almost the same as the intended sending address anyway so it's not the end of the <nckx>You can disable this feature by launching the daemon with ‘--disable-chroot’. <nckx>I've had to do so on ‘strange’ systems before. <nckx>I'm obligated to point out that you should fix the (ch)root issue if at all possible, because your build environment will be less pure without this, but it's better than not building at all. <nckx>And it shouldn't™ cause real problems. <evilsetg>I'll look into it. Right now I am just happy to be able to build at all. It's on a rootfs after kexec. I think I talked with you about this a week ago or so as well. I imagine that's why the pivot does not work like that. <nckx>And yes, one of my ‘use cases’ for --disable-chroot is in initrds. <nckx>I didn't actually bother to learn why since it's a reasonable trade-off in a rescue context. <nckx>Happy to hear it. I'd at least make sure you're using an unprivileged --build-users-group to limit what the builders can do outside of /tmp/guix-build-*. <nckx>They should be available even there. <oceane>so i've had a problem yesterday. (1) i needed to install texlive-biber (which wasn't a biblatex dependency), <oceane>(2) ox-latex seems to delete .bcf files before biber can use them <oceane>i'm sorry but i don't know if i should report it on irc or in a mailing list? <nckx>I don't get #1. If it's not a dependency, why did you need to install it? <nckx>#2 seems like a straightforward bug. Reporting bug reports on IRC isn't very productive or reliable, we have a bug tracker at <bug-guix at gnu dot org>. Just send a mail to that address and it will be assigned a bug number and show up at issues.guix.gnu.org. <nckx>You can then reply to [replies to] your bug number as <the number>@debbugs.gnu.org.