<nckx>Self-correction: I think adding them at 1% is fine, just not implying anywhere we have a translated manual until it's very close to complete.
<nckx>I don't know if info does that? I don't use translations myself.
<nckx>Meh, it's not really that important I guess.
<nij>nckx, xkcn - thanks for helping out! and sorry for the delay of my response.
<roptat>nckx, well, we advertise them in the manual/cookbook directly, and on the website by listing available languages
<roptat>it would be available as "info guix.ko" for the Korean manual for instance
<nij>The current issue I'm having is mainly "Settings schema 'org.freedesktop.IBus.Chewing' is not installed". I am at the test phase, passing 40%. The log file (the last 168 lines) is here: https://bpa.st/AOQA
<nij>I figure this won't be the last issue I can't get pass though.. so I'm questioning perhaps I need to get more general knowledge by reading more for example.
<nij>I also wonder if I should start packaging softwares with toolchains I'm more familiar with (elisp, common-lisp for example), instead of c, gnu which I have never had experience with.
<roptat>nckx, alright, I'll add them all, but we're not advertising them until they reach a good percentage, sounds good
<nckx>roptat: If we can omit languages from those lists but still ship them, that has my vote. But no idea if it's possible. You're the locale master.
<nckx>nij: Did you try setting #:tests? #f at all, if you saw my PM? It's not acceptable for the final patch, of course, but it can help if you're stuck. For morale, but also to see whether running the result (a) works - great, almost done (b) gives a more informative/different error.
<nij>Uh, I didn't see you're PM. Lemme see if I can see that in my local backups.
<nckx>nij: I don't think any of those are needed, and Guix should set the ones that are by default anyway.
<nckx>I don't know if the 2 binaries in libexec are safe to wrap (=replace with a wrapper shell script that sets certain variables and might fix the glib error), or whether ibus expects them to be ELF.
<Noclip>Mhh, actually 3.1.6 (currently in guix) is marked as the latest release on the glances github page. But 18.104.22.168 and 22.214.171.124 got released shortly after, they are however not marked as latest release.
<Noclip>But every time I close glances it complains about not being the latest version ...
<brendyyn>Noclip: sounds like a bug. packages shouldn't be checking if they are the latest version
<sneek>Welcome back brendyyn, you have 2 messages!
<sneek>brendyyn, leoprikler says: the hard limit seems to be (expt 2 (expt 2 28)) and likely has to do with the amount of continuous memory you'd need to allocate for that
<sneek>brendyyn, rekado_ says: For CRAN / Bioconductor packages what you describe is already reality. I can’t remember the last time I wrote an R package definition by hand.
<Noclip>brendyyn: glances always does that, no matter how it was installed. And it always tells you to update with pip even if it isn't installed with pip.
<brendyyn>Noclip: we should ideally patch that out
<raghavgururajan>sneek, later tell nij: I think you implemented it wrong. You just have to add #:use-module (guix build glib-or-gtk-build-system) at the top. For reference, you can look at telegram-desktop package. :)
<smoothdev>the symptom is the machine only shows black screen with white underscore cursor at the top left, and accepts no input
<smoothdev>I'll give a shot at qemu and exporting the vm image, as I gather vmware host is probably not the best approach
<nij>Hello! I'm unsure about the following. Could someone help out? I'm define-public a package, and I have (source (origin .. (uri (git-reference (comment XYZ))))). I notice that altering XYZ from commit to another different commit DOES NOT alter the hash of the whole package -- so when I build with the second commit, it does not rebuild! That contradicts to my understanding that if the commit (the source) is different, then the package
<nij>must be rebuilt. Could someone clarify what's going on? Thanks a lot!
<mdevos>Question: wrap-script is used for wrapping scripts. By default (which "guile") as interpreter. But that's incorrect when cross-compiling. I'd prefer for wrap-script to automatically do the right thing, which is using a guile of the target. Problem is, wrap-script has no way of guessing where the target guile is located. Proposal: introduce a PATH_FOR_TARGET environment variable, which is like PATH, but contains binaries for the
<leoprikler>mdevos: I think the proper solution would be to evaluate the search path in target without binding it to a variable
<mdevos>leoprikler: sorry, I didn't understand any of that
<leoprikler>I recently encountered a similar problem as a developer writing a guix.scm for my own package, and I think as a solution to this and problems like it I'd prefer a cleaner separation between inputs and native-inputs.
<jgart[m]>cbaines: sorry I didn't understand the last sentence after the second comma. It looks like it got munged
<leoprikler>mdevos: inside guix, you have a search-path specification for stuff like PATH
<morgansmith>I noticed an odd thing. We have the package "tidy" which is just our "tidy-html" package except the version is from 2009. It seems there are like 267 packages that depend on tidy but only 10 depend on tidy-html. Is this intention or are people just accidentally using the wrong tidy?
<mdevos>number of uses of wrap-script on core-updates: "git grep -F wrap-script gnu guix | wc -l"
<vincele>mothacehe: I've setup a local cuirass, which is working, and now I'm on to add remote-worker nodes, but reading the doc (or your blog), I'm not sure how to do that declaratively (f.e. as a service in `operating-system`), any hint ?
<apteryx>civodul: OK! In this case I'll add the doc-po-update target as a dependency of release
<raghavgururajan>the error happens during tests and and during run-time. The above explanation is for run-time.
<apteryx>and also ignore the *.pot files in .gitignore
<raghavgururajan>During tests, the test binaries looked for schemas, which were not compiled until 'glib-or-gtk-compile-schemas phase. So I moved the 'check phase to the end and modified env-var XDG_DATA_DIRS to include files in /share of output.
<cyberTeX>I just installed GNU GUIX on my Toshiba Tecra A8. The initial part of the boot process proceeds successfully, but it encounters errors regarding GDM. Whether I login or not, the system reports "Cannot make/remove an entry for the specified session", and an ambiguous message about "no return value" from a daemon.
<nij>make: Entering directory '/home/nij/guix/po/packages'. File vi.po does not exist. If you are a translator, you can create it through 'msginit'. make: *** [Makefile:476: vi.po-create] Error 1
<roptat>or just share your experience, sometimes it's hard to see obvious blockers when you're experienced, so it's always a good thing to hear what works and what doesn't from newcomers
<cyberTeX>apteryx: I'm willing to try newer images, especially if they might address something that was untested in previous i686 images. Regarding architecture, this machine has an Intel Core 2 Duo T5500; I just looked up the product specification on Intel's website, which states that the processor does support the 64-bit instruction set. Should I instead u
<derivates>yeah, right now i want to get rid of GDM and just boot to a TTY, and use ~/.xinitrc with startx command
<cyberTeX>apteryx: This machine only has 2GB of RAM, which is why I chose the 32-bit image. I always get confused when needing to choose installation images for systems that have <4GB RAM and aren't Intel Core "i[[:digit:]]".
<apteryx>cyberTeX: no the i686 image, just a recent one. Let me find a link.
<apteryx>ah, we do not generate it it seems for the latest images
<apteryx>I can ping you after I've managed to generate the first RC for what will become 1.3.0.
<cyberTeX>rotpat: I read that you have high priveleges in the GNU GUIX infrastructure. While it's something that most GUIX can eek out, it's easy to forget when a system actually requires a non-x86_64 image. Could "3.3 USB Stick and DVD Installation" of _System Installation_ be modified to include a reminder that the architecture images are specific to the _
<cyberTeX>processor architecture_ and do not regard the amount of installed memory in the system.
<cyberTeX>roptat: I misspelled your nickname. See my message above, please. :)
<cyberTeX>apteryx: Okay, I can try that. Are we sure I _should_ be using the i686 image? It boots and runs, but given the processor (Intel Core 2 Duo) is a 64-bit processor I should probably be using the x86_64 installation image, right?
<apteryx>it'd probably give you better performance yes, at the price of a bit more RAM
<roptat>cyberTeX, depends if we plan to take at least one more week to finish the release
<roptat>we're in string freeze, which means it's too late for the next release, but we can update the text on master
<cyberTeX>roptat: I've only used `patch` or `diff` a couple times, and I struggled with that. I've also never made an account on Savannah or the GNU infrastructure sites. I can iterate over a reminder text, though; I've got a little bit of technical writing education, so it's mostly determining how to remind the audience, who generally understand this concep
<cyberTeX>t, of something that can be easily forgotten because of disuse. :)
<apteryx>if you want, I can push what I've got here, and after you reproduce what I see, we can try finding the solution
<roptat>cyberTeX, basically, clone the repo, change doc/guix.texi (or doc/contributing.texi) as you wish, "git add doc/guix.texi; git commit", write your commit message, save, then "git format-patch -1" and attach the file it created to a message you send to email@example.com
<cyberTeX>take a look at the packaging guidelines, but seeing that KDE is not an available desktop environment on GNU GUIX, does that forebode that Qt 5 is unavailable as well, or merely the KDE framework? This software is built with cmake and qmake, and requires Qt 5.9.5 or later for compilation and runtimes. I'd be happy to package it for GUIX and submit i
<cyberTeX>t to the project. It's GPLv3 licensed, so there is no conflict of licensing. :)
<apteryx>OK, we want to stick to the versions that were already checked in master? I can remove the updates.
<roptat>similarly 6997f145585c72a25d473f424d2f566fb8852fae "nls: Update translation files with doc-po-update." must have updated the po files against the pot from master, which is not the same as the string freeze
<roptat>I can take care of that, and fix remaining issues... mh maybe I can kinda force the changes directly without commiting on weblate (I don't want my name in the files for languages I don't speak)
<apteryx>roptat: wondering if new packages should be treated as breaking the 'string freeze'; we don't care right?
<nckx>...and it's reset my layout to us-stupid, great.
<nij>nckx: Oh you mean to use a paste bin? I will do that next time.
<nckx>Aurora_v_kosmose: Correct, and Guix builds are pure anyway.
<cyberTeX>I'm trying again, but `guix pull` failed: `error: Git error: error inflating zlib stream`. This is a bit confusing for me, guix seems to be using git, but git is not installed (I tried just `git`).
<nckx>No prob nij. We recommend the one in the topic but any non-JS, non-Tor-blocking, non-horrible one is fine.
<cyberTeX>civodul: From the i686 system install image.
<cyberTeX>There were graphical "Oh no!"s at first, but I managed to change to a different virtual terminal and now I have a working system, at least without X it seems. I think the problem may be with gdm or a driver, but I'm unsure right now.
<civodul>cyberTeX: so you installed Guix System 1.2.0, right?
<apteryx>roptat: the version-1.3.0 was recreated now, the 'make dist' works, so I supposed 'make release' will proceed further. Will try do to so a bit later.
<mdevos>I'm preparing a patch that fixes a cross-compilation issue in 'wrap-program'. It add an 'inputs' argument for where to search for "bash". It is the same argument as in (lambda* (#:key inputs #:allow-other-keys) ...). Is it a problem that the patch needs to adjusts the 200 (or so) callers?
<mdevos>Aside from the tediousness of writing it in the first place of course ;-)
<nij>raghavgururajan: should i push your definition to guix channel anyway? Maybe it will work after it becomes official..
<mdevos>I need to go now, send responses to sneek!
<raghavgururajan>nij: Once you send the patch, folks will review and send feed-backs by replying in that thread. You can use those feed-backs to edit the patch and resend it. Once, the patch is satisfactory, a committer (folks who have commit access) will push your patch to guix channel.