IRC channel logs
2026-09-05.log
back to list of logs
<damo22>GNU_Hurd_Rocks: it seems odd you fixed it but he wants you to store the error message so you dont have to repeat it. I recommend just omitting the errno check and printing the same literal message in both cases <damo22>because storing the error message just to print it twice defeats the purpose of not needing to know the length of the string <GNU_Hurd_Rocks>damo22: the if is to check if errno actually has a value, else it prints the other format instead <GNU_Hurd_Rocks>unless strerror(0) is fine to do in which case yes I will revert <GNU_Hurd_Rocks>oh, missed this, "The value of errnum is neither a valid error number nor zero" <damo22>the check is actually (!paper) so that is probably enough <damo22>there seems to be no need to distinguish which error it was <damo22>or you could set errno = EINVAL and use the strerror format <GNU_Hurd_Rocks>damo22: originally it was this if (errno) perror(errmsg);else fputs(errmsg, stderr); <damo22>you could do if(!ierrno) errno = EINVAL ; printf <damo22>i would point you to my code for java but i cant right now, my server is dead <GNU_Hurd_Rocks>damo22: or could consider this instead, "fprintf(stderr, "%s: cannot get system paper size: %s", progname, strerror(errno));" <damo22>if(!errno) errno = EINVAL ; fprintf(stderr...) <damo22>then you only have the literal message written once <damo22>it satisfies the author and removes the MAXPATHLEN macro <damo22>GNU_Hurd_Rocks: almost, you left the MAXPATHLEN string in there <damo22>also, i think you need to include <errno.h> not errno-base.h <GNU_Hurd_Rocks>oh whoops, I'm not paying attention, and that would clangd getting in the way <GNU_Hurd_Rocks>looks like errno was already there, no idea why clangd tried including the other thing <damo22>do you know how to amend/squash commits? <damo22>it would be best if you squashed this down to one single commit that adds the correct fix <damo22>git rebase -i origin/master (then you get an editor where you can change "pick" to "fixup" commits that will squash the fixup commit into the one above) <damo22>yes, if you rebase locally, you can force push to the branch <damo22>then the pull request gets rewritten to be the single commit <damo22>i recommend to add this to ~/.gitconfig, then you can run "git lol" to view the commit tree in graph form so you can see what youre doing <damo22> lol = log --graph --decorate --pretty=oneline --abbrev-commit --all <damo22>you can rename a branch of yours <damo22>but origin/master is the upstream branch and master is local <damo22>if you lost the origin/master pointer, you can just refer to the hash of the commit you want to rebase on <GNU_Hurd_Rocks>what I mean is that the tag had nothing extra between what I wanted to add <damo22>you can fix it and then git commit -a --amend <damo22>that will add the change into the existing commit <damo22>the current code assumes zero is a valid value for errno as it checks for that <damo22>but strerror(errno) wont work if it is zero <GNU_Hurd_Rocks>[EINVAL] The value of errnum is neither a valid error number nor zero. <damo22>but you dont want the error message printing to fail <GNU_Hurd_Rocks>I think it means the value must either be a valid number or 0, if that wording makes sense <damo22>in this code path, the program exits, so i think it doesnt really matter <damo22>the program cannot continue if paper == 0 so we are just dumping an error and quitting <GNU_Hurd_Rocks>making some more progress to build openjdk now, hopefully all of the dependencies build without errors <jab>GNU_Hurd_Rocks that's fairly awesome! best of luck! <GNU_Hurd_Rocks>media-libs/alsa-lib failed, it could not find the header <sys/endian.h> <jab>the hurd doesn't have any sound support at the moment... <jab>or rather we have some very limited sound support. <GNU_Hurd_Rocks>did some greping, found this, configure.ac:350:AC_CHECK_HEADERS([endian.h sys/endian.h sys/shm.h malloc.h]) <jab>You are already beyond what I can comment on. I'm really not a Hurd developer. :( <GNU_Hurd_Rocks>jab: I've only very recently got interested into Hurd thanks to the Gentoo announcement back in April of this year <jab>yeah the gentoo Hurd distro is pretty cool! We had an alpine Hurd at some point... <damo22>GNU_Hurd_Rocks: you can remove USE=alsa from openjdk and just dont build it with sound support <Gooberpatrol66>also ensure you're not using a desktop profile, eselect profile set 1 <GNU_Hurd_Rocks>looks like openjdk is ignoring "-alsa" and still includes it as a dependency <GNU_Hurd_Rocks>I guess RDEPEND means runtime dependency, and DEPEND means needed for build <GNU_Hurd_Rocks>I haven't looked at ebuild documentation so I am guessing on this <damo22>you will have to hack the source code of openjdk to unset REQUIRED_ALSA_VERSION <damo22>unless it has a configure arg now <GNU_Hurd_Rocks>Gooberpatrol66: if I'm understanding this right, say app-misc/foo requires media-libs/mesa for runtime and build, it would list that dependency under both RDEPEND and DEPEND? <GNU_Hurd_Rocks>unfortunately looks like it is required, ALSA, Advanced Linux Sound Architecture is required on Linux. At least version 0.9.1 of ALSA is required. <damo22>yes, but the makefile has a way to ignore alsa <damo22>its just not configurable by --enable-blah <damo22>in openjdk7 there is REQUIRED_ALSA_VERSION macro, if unset, it will ignore code that depends on alsa <damo22>but it is selected by default on linux platform <damo22>so you can just hack the makefile <damo22>there is no manual for this, i discovered it by reading the source <GNU_Hurd_Rocks>although will have to come up with some sort of patch that works <damo22>i wish my server was back up, i could show you all the changes i made <damo22>it will take a week or so, i am waiting for new PSU <GNU_Hurd_Rocks>damo22: I will be fine with that to then not do something that was already done