<Kolev>I do `guix home reconfigure` and it's building Icedove from source. This is awful. <singpolyma>Kolev: does your guix home settings specify icedove somehow? <Kolev>singpolyma: Yes. I do use/need Icedove, but I'm shocked there's no substitute and that it's building the giant piece of software. <singpolyma>Maybe it updated recently. I expect there's a substitute for the previous version if so <singpolyma>I do wish guix defaulted to erroring when no substitutes instead of trying to build stuff locally <tho1efx[m]>I'm not sure that my terminal history is long enough to send everything that happened after `guix pull` ***alMalsam1 is now known as alMalsamo
<apteryx>you use the -K flag, then switch to the directory under /tmp/guix-build-*, source environment-variables, then try stuff <apteryx>if you need the data that would have been installed to the store, you could try setting a different --prefix as a configure flag <Ribby>I talked about firmware, but I'll just contact the company for driver and firmware support. <mrwater>Concerning the bootloader line in config.scm: It uses /dev/sdX. Could I use a uuid instead? ***A_Dragon is now known as [
***[ is now known as A_Dragon
***Noisytoot is now known as [
***badcodec is now known as EndOfAnEra
***Rue is now known as Carp
***Carp is now known as hlz
***califax- is now known as califax
<apteryx>lilyp: by the way, your patch at #53559 LGTM. <mroh>Is it only me or does `make check TESTS=tests/graph.scm` currently fail? (in "node-transitive-edges + node-back-edges") <apteryx>mrwater: it tehcnically could (GRUB supports it) but Guix can't generate such config yet <apteryx>it'd be a nice addition (an top of labelS) <Guest6>how is it that I can boot the installer just fine, but no installs even gets to grub? I've tried bios and uefi, manual and guided, with and without a "guix pull". Always I cannot get to the grub screen of my install. <gnoo>Guest6: when that happened to me, it was that the bios was going the bois route and i had configured to use efi <gnoo>does the install error out at any point? <Guest6>gnoo: I got some errors with the guided installation. Manual seemed to work. I can get to a one-time boot screen and boot in bios or uefi, but it never even gets to grub. says something like "failed to boot" <gnoo>if you only have one hdd(or sdd) in there that would mean grub failed to install properly. manually reinstalling grub is a pain on guix (very different than other distros) <jackhill>Quick way to find the list of available system (e.g. to pass to the --system= option of guix-pack)? <vivien>My v5 patch series is out! I bet not many of you have made so many mistakes in a single patch series as to require 5 revisions. <Guest6>gnoo: strangely, this guided install seems to be working. <Guest6>In general, is it a good idea to guix pull in the installer, or is that bad for some reason? <gnoo>it's not bad but rather useless, i think <gnoo>it'll git clone guix in live system which will be wiped <Guest6>I know that much. Just thinking there could be a bug that gets patched. Seems like a good last resort when things aren't working <jackhill>vivien: oh, what are you packaging? Sometimes the software and computers just don't want to coöperate. At least we got the issue worked out in review <mrwater>How can I tell why I can't close my encrypted volume without lsof? <mrwater>Because lsof isn't on the guix live image <mrwater>Now the fuser list is empty and it still says the device is in use <bavier[m]>anyone know if a minetest update to 5.5.0 is underway already? <mrwater>Can I force a luksClose? How do I get out of this? I understand that it's unsafe to not properly close an encrypted filesystem right? <dcunit3d>i'm not sure. can you read the data off the partitions that you need? <dcunit3d>what are you using fuser for? what's the typical usecase for fuser <mrwater>Yeah, I can read it, I just can't close it because it's "in use" <mrwater>fuser is like lsof. It says if there's processes related to a mount point working <mrwater>It looks like I have to deactivate a logical volume situation, and none of the commands I can find on the internet to do that are available in the guix livecd <sughosha>Hi guys and gals, could someone help me how to change GDM to SDDM in `config.scm`? By default it is loading GDM. <mrwater>Okay, so pvcreate and lvcreate apparently used to be in the guix live image, and now they're not? How do I manipulate logical volumes? <dcunit3d>i'm not sure how to help. the easiest way to deal would be to unmount any disks you want to save within the mapped luks device, then back them up & recreate. create a new USB image to boot from if necessary. <dcunit3d>if you have to continue from within your current live image, then it's going to be much tougher, especially if you've started the cow store or are working off an existing system that's partially attached. <mrwater>I can't mess with this device, it's an encrypted ssd :/ <mrwater>I just figured out that the guix package manager might work, so I can maybe install the lvm stuff <dcunit3d>if it's a device image you can't risk losing, you always need to work from a copy of an image <dcunit3d>they should already be on the live image afaik. it would be tough to install if they weren't <dcunit3d>it is possible to install the LVM packages, but i'm not sure what state your system is in <dcunit3d>did you boot from USB? is the encrypted disk a guix system? <dcunit3d>and i'm hesitant to help you out here bc you may lose data if I'm wrong ... <mrwater>I booted from usb. The encrypted device is a nothing system. I'm trying to make it a guix system. <dcunit3d>ok, have you read the Guix/Libreboot guide? <dcunit3d>it does reference lvcreate/pvcreate though <dcunit3d>it mentions something that should fix your situation, this is needed very early on to have LVM tools `guix pull --branch=master && guix install lvm2` <mrwater>That is what I'm looking at atm. It wasn't there the last time I tried to install guix, and I wasn't expecting it to be there <lilyp>apteryx: thanks, I also reported it upstream as asked, I'll just rewrite it slightly to add that comment and push it today in the evening or so <mrwater>Also incidentally, the pull keeps screwing up because I keep losing connection because the ethernet network device isn't available and I can't figure out how to make it available <dcunit3d>yeh, i had problems with that as well. you really want to use DHCP if you can. <dcunit3d>yeh. otherwise you have to really dig to find the tools you need to get the network up. i can't remember exactly. i didn't use DHCP. <mrwater>Eveny time I have used dhclient in the past, I have had problems <dcunit3d>you may have to use net-tool or ifconfig or another networking tool. <dcunit3d>if you build another USB image, it will be easier <dcunit3d>i can't remember the exact details, sorry <char[m]>What do I do if my patch is ignored? <ryanprior[m]>char: at some point (week? month? your judgment call) you send another email to bump it, maybe tag people here and beg for reviews. Or if it's not that serious you move on, I guess. <ryanprior[m]>I have a bunch of old ignored patches that I don't know when/if I'll ever get around to doing the work to get them noticed & merged. <mrwater>Ok, how do you install a package as a binary <mrwater>I failed to compute the derivation. I don't need the source anyway <char[m]>ryanprior: If i just bump the created thread will anyone get updated? <ryanprior[m]>char: well, people will get another email in their inbox at least. <ryanprior[m]>mrwater: if you run `guix weather PACKAGE` (substituting the package you want) then it'll tell you whether binaries are available or not <ryanprior[m]>If you enable substitutes and `guix install PACKAGE` then it'll download the binary <char[m]>I'm being told "glibc: unbound variable", but I have (gnu packages base) already <mrwater>It looks like the logical volume thing is a dead end. There's no logical volumes. I just didn't know how that worked. <mrwater>How. Do I close. This luks partition <ryanprior[m]>char: you typically don't need to refer to glibc directly, what are you trying to do? <char[m]>I'm trying to make dlopen available for cffi <ryanprior[m]>Referring to glibc should work in general, I just verified it's defined as (define-public glibc (package ...)) <ryanprior[m]>Are you maybe doing this as part of a deferred build step where you need to import the module again? <char[m]>ryanprior: removing base module seems to please but now it has the same complaint about libffi. unknown symbol even though it is imported <dcunit3d>what is the best way to set up LaTeX with Guix? i'm trying to integrate emacs with Anki, but soon I'm going to want LaTeX <dcunit3d>there are quite a few packages, but i've just been using the minimal LaTeX in emacs/org so far <char[m]>actually, my bad. it still complains about glibc without base, I had it commented out <char[m]>that is most strange, putting the list of packages directly in inputs instead of in a let made it happy. <mrwater>dcunit3d: I have a hate/hate relationship with R and think that R markdown was the biggest mistake mankind ever made and that Yihui Xie should be burned at the stake for his crimes, but he *did* make a cool thing called TinyTeX, which is a minimal TeX package that can auto-pull packages as-needed using R. <mrwater>It makes things a lot more manageable. I always use it even though it feels like I'm installing a tumor every time I do. <dcunit3d>mrwater: lol with guix manifests, you can pluck that tumor out whenever you want. <dcunit3d>it looks like guix has the r-tinytex package. i've just installed techlive-bin for now, but thanks for the heads up. <mrwater>dcunit3d: about the manifests, yeah, a lot of what I'm doing here has to do with not being able to tell whether I hate anaconda or R more. <mrwater>What happens if you don't run luksclose and you just reboot? <AwesomeAdam54321>mrwater: The worst case scenario is that the data on the encrypted partition is unreadable <mrwater>Well if it's readable now and unmounted then it's fine? <mrwater>Mounting problems in linux are the only ones that I can't break through on after 12 years of this shit <roptat>looks like I managed to update coq after all, easier than I expected <mrwater>device-mapping-guix-root requires udev which is not provided by any service <mrwater>while running the big install command guix system init /mnt/etc/config.scm /mnt <mrwater>according to herd status, udev is started <civodul>mrwater: hi! it's a diagnosis about your config file, not about the running system <civodul>that would suggest udev is missing from the 'services' field <civodul>although it's part of %base-services <mrwater>civodul: I have (services (append (list (service dhcp...) %base-services)...) <mrwater>Ok nvm I had the parentheses wrong. Yay <mrwater>And now it's failing for a different reason! <mrwater>Okay, this seems drastic. It outputs a backtrace to ice-9/boot-9.scm in procedure raise-exception wrong type argument in position 1 <roptat>if you go back a little in the backtrace, you should see where that comes from <mrwater>that's as far back as it goes... it looks like it's complaining about the services line <mrwater>(services (append (list (service dhcp-client-service-type) %base-services))) <mrwater>civodul: Can I? What's an easy terminal pastebin for guix? <mrwater>Or not, because I keep losing connection every 3 seconds <civodul>mrwater: here it's doing (append (list x %base-services)) instead of (append (list x) %base-services) <civodul>i guess that's why you get that ugly type error <civodul>probably one way to help would be through automatic code formatting; that would make the error more visible <mrwater>civodul: Extremely agreed. Unfortunately the guix livecd seems to only have vi and zile and I'm learning that I dislike both of them. <roptat>you can use "guix install" from the live cd <roptat>like "guix install nano" if that's what you prefer :) <mrwater>Yeah, hadn't occurred to me, I've kinda been at this for hours. Thanks for the reminder <mrwater>Unfortunately I can't guix install dhcpcd. I'm getting sick of losing connection <zimoun>apteryx, civodul: well, I think it is time to have a “stable” branch; because I have hard time each time I run “guix pull”. Classical sysadmin do not upgrade because they fear to break without the possibility to rollback. I fear to “guix pull” because I do not know what to expect then. :-) <zimoun>yesterday, I had a similar case with a Python package of my own. Now it fails to build. <civodul>zimoun: i take it that you're offering to maintain a stable branch? :-) <civodul>how did you stumble upon the autogen failure? <cbaines>I'm guessing that the core-updates merge introduced the autogen failure, it's hard to tell though as data.guix.gnu.org is missing a load of revisions <cbaines>given there's lots of room for improvement in general Quality Assurance processes, I think that's the first thing to try, rather than a stable branch <zimoun>civodul: trying to package gcc-rust <abrenon>aren't those breaking cases actually good scenarios for end-to-end tests ? <civodul>zimoun: ah ok; they must be among the few users of autogen <abrenon>maybe we should have a process running a VM with Debian, installing guix on it and checking that a given package builds on it <zimoun>civodul, I also used it for a package of my own (bioinfo tool) <civodul>cbaines: yes, i think so, though we should identify concrete and reachable milestones i guess <abrenon>another one performing various installs from the liveCD in another VM ? <cbaines>civodul, I think comparing branches using the Guix Data Service in preparation and prior to merging would be a big help <cbaines>I think we're nearly there with that <civodul>abrenon: it'd be nice to have automated installation tests on foreign distros <civodul>zimoun: are you looking at the autogen failure? otherwise i can give it a spin <abrenon>this was not a proposal to develop and maintain such tests : ) <zimoun>civodul, no I am not looking at the failure. <civodul>cbaines: that would be a nice improvement, yes <civodul>we need to check with maintainers how to deal with compute resources <civodul>but clearly, making this service "official" would be a great step forward <civodul>then we can arrange so that issues.guix links to it, too <cbaines>the machines already behind bordeaux.guix.gnu.org should be able to make a good attempt at building branches as well <cbaines>I feel like I'm maybe sending too many emails at the moment, but I'll try and send out an email about some QA stuff later today <civodul>i'm chronically lagging behind email :-) <civodul>my preference goes short and to-the-point messages ;-) <cbaines>I've actually been slowly catching up recently, hence why I've been replying to messages from months ago <civodul>hmm i see lots of Ruby things being built <pingpongball>*The Nix Packages collection (Nixpkgs) is a set of over 60 000 packages for the Nix package manager.* <cbaines>those sound like questions better asked to people involved in Nix and Debian respectively ***blacked is now known as pingpongball
<gfleury>How can i import (ice-9 popen) in #:modules when using gexp <cbaines>gfleury, I think #:modules in a gexp is for copying modules from the host environment <cbaines>given (ice-9 popen) is part of Guile, I think you should (use-modules (ice-9 popen)) inside the gexp <zimoun>rekado: I get « File `scalefnt.sty' not found.» and I have texlive-base. How I find what is missing? <rekado>zimoun: according to tlpdb you need the “carlisle” package. <zimoun>rekado, I get «Math formula deleted: Insufficient extension fonts.». And I do not understand what is the issue. <guest432145315>hi, does someone know how I can guix pull --commit=blabla, with the commit referring to a channel (other than "guix") <zimoun>rekado: it appears when the docmentclass is beamer. <zimoun>guest432145315, using the option --channels. <zimoun>guest432145315: you need to create a file, say named channels.scm, for instance “guix describe -f channels > channels.scm”, then edit this file to set the commit your want for the extra channel. Last “guix pull -C channels.scm”. Does it make sense? <guest432145315>it doesn't belong to the configuration file because it changes every time I run "guix pull" <zimoun>guest432145315: what would you suggest as CLI? <leinad>guest432145315: wouldn't then setting up a branch and specifying that branch in the channels file work for you? <rekado>zimoun: there’s a bug report about this very issue, but I closed it as it could no longer be reproduced <zimoun>rekado: maybe I am doing wrongly. <guest432145315>zimoun: guix pull --commit=bla --channel=extra-channel --commit=blabla <rekado>zimoun: no, it’s more likely to be a bug <zimoun>guest432145315: how do you identify that bla is from extra-channel and blabla from Guix ? <guest432145315>leinad: it's a channel I don't have write access to, I can't setup branches. My use case is the following: I don't want to build the world every time I guix pull so I find a commit for which I'm sure to find my packages built by the CI <zimoun>rekado: Ok, I am going to find this bug report and reopen thus. <guest432145315>the search for that commit is done once and only, right before running 'guix pull' <rekado>zimoun: can you reproduce this in “guix shell -C”? <rekado>(just to be sure that state in $HOME doesn’t affect this) <leinad>guest432145315: I see... hmm... it's a bit complicated but you could of course create a temporary channels.scm file with the commit right before `guix pull' <leinad>but I think you CLI proposal isn't too bad... maybe just the other way around: `guix pull --channel=extra --commit=xxxx' <zimoun>rekado, yes. I am running “guix shell -C -m manifest -- pdflatex foo.tex” <zimoun>it works for article documentclass but not beamer. <guest432145315>your proposal is the same as mine, the first --commit was referring to the implicit "guix" channel <rekado>zimoun: interesting! Please reopen with a reproducer. I’ll try to figure out what’s wrong. <zimoun>guest432145315: “guix pull” update a local Git repo by doing under the hood “git pull”, then it checkout the mentionned commit. I miss how your proposal would work for several channels. AFAIK, extra channels are specified via a file. <rekado>I guess the two could be merged now that they have converged on the same error. <guest432145315>zimoun: each channel is another git repo, so nothing prevents guix for checking out that git repo on another commit I believe <MysteriousSilve4>Hello! Where would I learn about the commit message format followed in guix.git? <rekado>MysteriousSilve4: the commit message format is derived from the GNU Standards; 6.8.2 Style of Change Logs <rekado>MysteriousSilve4: you can also use the yasnippet to generate the message for additions or changes <rekado>there’s also etc/committer.scm, which will create the commits on your behalf <rekado>it’s a little stupid, but it works well enough for changes to existing packages. <zimoun>guest432145315: 1/ it is not possible to specify the extra-channel at the CLI level and 2/ assuming it would be possible, “guix pull --commit=C1 --url=path/to/foo --commit=C2 --url=path/to/bar” so how do you know that C1 is related to foo and not related to bar? <guest432145315>guix pull --channel=guix --commit=foo --channel=bar --commit=bar <guest432145315>I know foo is related to guix because it's after --channel=guix and before another --channel <zimoun>guest432145315: it is not how many of the CLI parsers work. For instance, grep, -e is waiting a PATTERNS, but not -E. So ’grep -E -e 1’ is equivalent to ’grep -e 1 -E’. In the case of “guix pull”, I fail to see how it would work without rewrite this CLI parser. <zimoun>guest432145315: Somehow, this example is doing what you are requesting for the Guix channel. <zimoun>guest432145315: My point is, instead of complex CLI, I would investigate in Scheme API for filtering. :-) <unmatched-paren>what does 'guix build: error: expected regular file' mean when i do 'guix build -f manifest.scm' to build my project from local sources? <civodul>unmatched-paren: you're passing 'local-file' a directory <civodul>but you did not specify #:recursive? #t <unmatched-paren>i thought that configured whether to fetch git submodules in the local directory :) <civodul>i discover lots of funny issues while upgrading guile-3.0-latest to 3.0.8 ***blacked is now known as pingpongball
<mroh>I'm trying to write a system test/marionette "test-lvm-root-os" (to fix 44877 and boot from lvm) , but can't get past `make check(-local)` (tests/graph and tests/pypi fails). Is it my version, am I doing it wrong or is this known? <civodul>mroh: hi! i noticed that tests/graph.scm failure and wasn't sure if it was due to my changes or not <civodul>but i guess you can ignore it while working on your system test <mroh>Thank you! I would love to skip it, because it takes so much time anyway. But how so? <civodul>you want to run "make check-system TESTS=your-test" <mroh>Hmm, then, something is wrong on my checkout/config/whatever, because here they are not unrelated: make check-system TESTS="my-test" includes/executes make check-local. <civodul>for me "make check-system TESTS=basic" builds the system test called "basic", but that's it <mroh>"make check-system TESTS="lvm-separate-home-os" calls "make check-TESTS check-local" for me. <civodul>mroh: i'm confused; in Makefile.am, i have: check-system: $(GOBJECTS) <civodul>meaning that "check-system" depends on nothing but .go files <civodul>how can it end up building "check-local"? <mroh>Im confused too, I also tried only executing the target there "TESTS="lvm..." ./pre-inst-env guix build -m $(top_srcdir)/etc/system-tests.scm -K" but stil it calls check-local. So I think, it's somewhere else. <civodul>maybe you're seeing check-local in a package build, no? <civodul>comrades, Guile 3.0.8's in the house! <civodul>twas fun because texlive things implicitly depended on the (%guile-for-build) value <civodul>and so changing guile-3.0-latest would lead "make as-derivation" to rebuild all the texlive things <rekado>zimoun: could the texlive problem be due to the use of tabular? <rekado>but … is this really related to beamer at all? <rekado>or can you reproduce this also with the article class? <zimoun>rekado: commenting ’frame’ and using ’article’, it works using guix shell -C -m manifest.scm; for both, tabular or equation. <tanner40>I'm using Guix System and booted the 4th of 4 system generations. I rolled back to 3, and then reconfigured at which point I could no longer find the original 4th system generation, either in the grub menu or in `guix system list-generations`. Did it get overwritten? <gnoo>probably. according to the manual, it'll get overwritten <gnoo>info "(guix) Invoking guix system" <gnoo>how do i use dnsmasq such that /etc/resolv.conf always has 'nameserver 127.0.0.1' in it. <ardon>Hi, I'm dealing with this issue "ld: cannot find crti.o: No such file or directory" when running `ocamlopt`. My web searches yielded me needing to install gcc-multilib, libc-dev, and other packages which have no equivalent on guix. Any hints? <vivien>ardon, maybe install gcc-toolchain <ardon>vivien: Thanks, but I do have it installed already. I think it has to do with the fact that the OCaml compiler can target various architectures, but I'm unsure of what file would solve that issue. <jpoiret>sneek, later tell civodul: So i've got a wip that builds now using #:autoload instead of #:use-module, but I don't know how I could test it, since a) with `make as-derivation`, you don't have (current-channels) b) the the source i'm currently using isn't git-checkoutable since it's a local checkout <jpoiret>the woes of testing the guix bootstrap :( <rekado>ardon: do you have the “gcc” package installed? If so remove it. <jgart>Hi Guixers, How can I compile a static binary with Guix? (not using guix pack) <rekado>ardon: otherwise this may be a bug and we would appreciate if you could send an email with a reproducer to bug-guix@gnu.org <rekado>jgart: see static-bash in (gnu packages bash) for an example <jgart>Is there a way to compile a static binary for armv7 by passing a CLI flag to guix build? <ardon>rekado: I have `gcc-toolchain` installed. If I remove it `ocamlopt` complains about `gcc` being missing. <jgart>ah, ok. Is that a feature that would be welcome? <rekado>ardon: sounds like a bug then. Perhaps ocamlopt ignores your GCC. <rekado>you can cross-build a package with --target, but building something statically requires a few more changes <rekado>using static-package may get you there <jgart>not sure how that would work <jgart>I'll have to do some more research first <rekado>if you want to build a binary for a foreign architecture you need to cross-build it <rekado>that’s what --target does, but it is generally difficult to make it work <jgart>I know that guix build can currently do that but I don't know how that ties in to producing a static binary output <rekado>building a static package is a separate issue <jgart>I'd like to learn more about that issue <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, jpoiret says: So i've got a wip that builds now using #:autoload instead of #:use-module, but I don't know how I could test it, since a) with `make as-derivation`, you don't have (current-channels) b) the the source i'm currently using isn't git-checkoutable since it's a local checkout <civodul>jpoiret: as part of "make release", we'd have to make it use $PWD as the source repo <civodul>i'm confident but i think we should have more than one person vet for such changes <rekado>sneek later tell zimoun The first hint for 40558 is that stmaryrd doesn’t contain any font files… <rekado>this is again a consequence of simple-texlive-package doing nothing useful when overriding its build phases <rekado>we’re fetching them all and then forget to install them <gordon1>does current authentication scheme allow if i for example i have a fork of guix with minor patches, to pull changes from the upstream? <dcunit3d>from within the guix emacs package, is there a way to load a package on top of the existing GUIX_EXTRA_PROFILES loaded within the environment that emacs launches with? <gordon1>i'm kinda stuck with that one, from my limited understanding if i have my own introduction in my guix fork i have to sign all new commits after this introduction (because .guix-authhorizations will be changed) <gordon1>is that correct? if so that will hinder a bit convenience of forking guix even for personal use, since you have to revert to --disable-authentication <dcunit3d>i see that I can "set the emacs environment" with (guix-set-emacs-environment &opt PROFILE) <dcunit3d>gordon1 i don't know the answer, other than, at a minimum you should be able to stash your changes then pull and reapply the stash <dcunit3d>i'm not sure whether you would then have to do a `guix pull` afterwards, but i think so <gordon1>i bet i will try to authenticate changes and fail, though i didn't try it <dcunit3d>but with guix, you can have multiple installed Guix's active (the system guix is maintained separately from the user's guix) <gordon1>yeah, well, the issue exactly with fact that i don't want to have multiple version of guix installed, at least i don't want to have original guix installed <dcunit3d>if you hook into that functionality, where the user's system has system, user and "custom" guix's that's probably the best way to maintain a Guix with a few patches applied (on a single system at least). <dcunit3d>and like i said, i don't know, but i'll stay posted bc i'd like the answer <gordon1>because it pulls pile of software i will never ever use and it will just sit in my /gnu/store as a dead weight <gordon1>(though the task of cleaning it up looks more and more daunting with every day i spent on it) <civodul>so, evaluation fails because of: (system-error "canonicalize-path" "~A: ~S" ("Dosiero aŭ dosierujo ne ekzistas" "aux-files/chromium/master-preferences.json") (2)) <rekado>pretty much every texlive-* package using simple-texlive-package without #:trivial? #t and a chdir phase is broken <rekado>simple-texlive-package has a copy-files phase, which copies from the current directory <rekado>all those packages that chdir away from the initial directory are thus incomplete <rekado>I already fixed three core packages <rekado>but none of them affected #40558 <ngz>rekado: I don't think so <sneek>Welcome back ngz, you have 1 message! <sneek>ngz, rekado_ says: That’s great news about the modular LaTeX. If you have recommendations about documentation (since the experience is still fresh in you mind), I’m all ears! <ngz>rekado: oh wait. I misread your sentence. <ngz>Yes, a chdir phase is mandatory if #:trivial? is not true. <rekado>yes, but a) that’s silly and b) it breaks the copy-files phase <ngz>A false #:trivial? often implies a new copy-file phase <rekado>when the build system is given a #:tex-directory it should go there and build stuff <rekado>or work on the #:build-targets directly, I don’t care. <ngz>I don't know what #:tex-directory is supposed to mean. <rekado>the build system is also silly in that it creates a “build” directory wherever it is right now <rekado>so the copy-files phase usually just copies it along with all the other files <rekado>and that’s wrong because that puts a “build” directry in the output <rekado>I don’t remember the details but the way we process #:build-targets is also wrong <rekado>some .ins files are pretty clever and they specify what files to generate where <rekado>it forces all files to the “build” directory <rekado>this destroys directory structures set up by the .ins file <ngz>I see that in texlive-build-system.scm, with "-output-directory=build" <rekado>this leads to awkward workarounds like the one in texlive-fontinst (although that one is innocent; we’re not using texlive-build-system there) <ngz>Well, this build system is not too bad for 70 locs :) <rekado>I’m sure we could create as many bugs in even fewer lines ;) <rekado>so … another round of wip-texlive hacking, I guess <ngz>I didn't heard about any freeze period. <rekado>I stopped hacking on wip-texlive because there wasn’t enough time to finish it before 1.4.0 <ngz>Speaking of hacking core-updates, I have a questions about worktrees. I created one for core-updates branch, but if I modify a package, and try ./pre-inst-env guix build this-package, this just tries to build the package from master instead. Am I missing something? <ngz>./pre-inst-env is called from the directory associated to the core-updates worktree. <rekado>argh! “This file was generated from version 1.2beta of amstex.dtx and then underwent additional hand-editing.” <rekado>well, this explains why the file doesn’t exist in our package… <rekado>ngz: did you ./bootstrap in the worktree? <ngz>Yes, to generate the ./pre-inst-env script <rekado>does the script refer to the correct abs_top_srcdir? <mbakke>civodul: any idea what's up with that ungoogled-chromium aux-files shenanigan? <mbakke>ngz: does the worktree have the intended branch checked out..? <ngz>it is on core-updates <podiki[m]>guix days video, is CC BY-NC-SA a suitable license? <civodul>mbakke: yes, i'll push a fix soonish <podiki[m]>or does it need to have commercial usage allowed? <rekado>podiki[m]: NC makes it a non free license <cwebber>I'm not running guix days but I suspect that's the preference :) <podiki[m]>probably spent at least as much time playing with OBS as I did actually recording the talk :) <rekado>I’m about to add texlive-stmaryrd/fixed, texlive-psnfss/fixed, texlive-babel/fixed, and texlive-amsmath (could be texlive-latex-amsmath/fixed, but it also needed a new name anyway) <civodul>rekado: a95924c9ac3f238cde243c96d552ff59ad77ca16 and defa85b26537a3cc20624fb9dbcae906226361d5 broke a test in tests/graph.scm, which does not expect the mesboot0 packages to be exposed <rekado>what are your thoughts on using grafts to replace the original packages? <civodul>(no rush, just mentioning it because i was looking into it) <rekado>fine to change the test to accept it? <rekado>or should I try to hide the mesboot0 packages again? <civodul>the other day we discussed moving glibc-2.2.5 and gcc-2.95 elsewhere, would that be an option? <mbakke>oh, I suppose ungoogled-chromium should use 'search-auxiliary-file' <mbakke>errh, already done by civodul :) <podiki[m]>cwebber: yes, obs is great, tried out transitions for the first time, just to go between full screen slides or with webcam view; easy! <rekado>civodul: glibc is already in base; the reason why three of the mesboot packages are exposed now is because that glibc and the gcc wrapper have them as inputs <rekado>because that would add packages to commencement (not good) <rekado>“would not help” is not true — but it would lead to another unwanted outcome <civodul>these intermediate packages should really not be used <civodul>i mean, outside commencement.scm :-) <rekado>we could try to build them backwards <rekado>i.e. use GCC 5 to build GCC 4, then GCC 4 to build GCC 3, then build 2.95 with GCC 3 <civodul>maybe defining them in base.scm or something, independently of what's in commencement.scm?