# IRC channel logs

## 2020-04-10.log

back to list of logs

<madage>'without pulling' would be more accurate, and I do it because sometimes the pull takes a long time to build and I just want to upgrade one package..
<efraim>civodul: hurd-vm build is finally going
<madage>in this case, nano, whose definition was added just after my last pull... but I couldn't even upgrade the remaining packages whose dependencies or definitions changed after pulling
<dattashantih8>when using clang-toolchain, should I have to be setting the rpath?
<NieDzejkob>ideally it would've been handled by ld-wrapper
<NieDzejkob>but I think clang uses it's own linker, LLD
<efraim>/etc/sudoers is 0440, should the file /run/current-system/etc/sudoers links to in the store be 0444 ?
<dattashantih8>NieDzejkob: hmm, ok. I was trying to use clang instead of gcc from guix, but am having trouble with it finding shared libraries.
<mbakke>madage: how does Guix find the packages you've added on /etc/gnu ? I recommend migrating to a channel instead.
<mbakke>dattashantih8: what are you trying to run, and how does it fail?
<dattashantih8>mbakke: I'm just trying to use clang with a cmake project, but the executables that it generates cannot find their shared libraries.
<mbakke>dattashantih8: so the executables compile and link fine, but fails when you run them?
<dattashantih8>mbakke: Yes, it works if I add -Wl,-rpath=/profile/lib
***ssouth is now known as simonsouth
<civodul>efraim: so "guix build" remained seemingly idle for a while?
<efraim>i killed it twice after 17 minutes, while it was about 65% done building the wip-hurd-vm branch
<civodul>so it was actually building stuff?
<madage>mbakke: hmm.. not sure if you are asking me for the relevant code section, but I believe GUIX_PACKAGE_PATH overrides the search path and package definitions on the directory are prefered to those of custom guix
<mbakke>dattashantih8: that flag should get added by the ld wrapper if /profile/lib is on $LIBRARY_PATH, so perhaps clang finds the wrong linker <madage>and I'll read on guix channels again, I use the variable because it was easier the first time around and never gave me issues, so I kept procrastinating on learning how to use channels <madage>but anyways, I guess I'll try rebooting my modem, clear all local mods and if the issue persists I'll forward to debbugs <efraim>sneek: later tell civodul it wasn't downloading sources or building anything, it was more like it was deciding what to do. Now it is building glibc-cross-i586-pc-gnu-2.31 <sneek>Will do. <efraim>sneek: botsnack <sneek>:) <mbakke>madage: channels are better at error handling, and it will also be much faster :) <madage>maybe I should just go back to the previous working generation and pull/reconfigure again <dattashantih8>mbakke: Yeah, it is probably as NieDzejkob was saying and clang uses LLVM lld by default. <madage>mbakke: noted :) <mbakke>dattashantih8: CMake has a habit of overriding RUNPATHs, cmake-build-system sets "-DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE" <dattashantih8>mbakke: Yeah, I reproduced this with a simple source file that just calls zlib_version and compile with clang++ from guix. <mbakke>right <mbakke>there is at least one package in Guix that compiles with clang and the ld wrapper, though possibly in separate steps <mbakke>dattashantih8: can you poke at the process to see which ld it executes (if any)? <dattashantih8>mbakke: it looks like it is using ld from my guix profile <mbakke>dattashantih8: is that a shell (actually Guile) script? <dattashantih8>mbakke: it is a guile script installed from clang-toolchain <mbakke>dattashantih8: try exporting "GUIX_LD_WRAPPER_DEBUG=oui" and see if you can spot any differences between the clang and GCC invocations <dattashantih8>mbakke: It looks like the gcc invocation adds -rpath /my-profile/lib and the clang invocation does not <dattashantih8>mbakke: even though it lists /my-profile/lib in the library search path list before invocation <mbakke>dattashantih8: can you file a bug with the details? <simonsouth>In trying to build a disk image for my ARM SBC guix has been "stuck" for three hours (!) at <simonsouth>building /gnu/store/cdsbk8sxgpy6yvqpjxxkrdww5ippzn9l-disk-image.drv... <simonsouth>A qemu-system-aarch64 process has been running the entire time with one CPU core pegged at 100%. <simonsouth>The ASCII spinner is still moving slowly, and this is not a particularly powerful board, but... three hours. <simonsouth>Does this sound normal? <simonsouth>Or is it possible something has quietly failed? <simonsouth>I can't tell whether it's making progress or not. What I assume is the relevant log file in /var/log/guix/drvs/cd is empty. <mbakke>simonsouth: if you're willing to sacrifice potentially another 3+ hours you can safely cancel it, I think the log file is only written when it stops <simonsouth>mbakke: Alright. But I'm happy to leave it running so long as it's likely to complete. <simonsouth>I assume it's running a VM to populate a virtual hard drive as part of creating the disk image, or something along those lines---if it's normal for this to take so long (on low-power hardware) I'll just leave it be. <mbakke>simonsouth: is it running on an SSD? <simonsouth>mbakke: An eMMC module. So, quick but not that fast. <simonsouth>Oh, it just finished. Ha. <mbakke>yay :-) <simonsouth>So, "yes" is the answer: This final step can take three hours on a low-power SBC. <mbakke>simonsouth: are you using Guix System? <mbakke>or what I'm really interested in, are the guix build users member of the 'kvm' group? :) <simonsouth>mbakke: Let me see---this is guix installed via the installer script on Armbian... <simonsouth>mbakke: Doesn't look like it, no. So I suppose qemu wasn't using hardware virtualization. <simonsouth>That would explain why it was so slow. <mbakke>simonsouth: sounds plausible <simonsouth>Not sure this CPU supports hardware virtualization even. I think it does, but then Armbian may not have support built into the kernel, etc. <dattashantih8>mbakke: It looks like the issue is on my end. cmake was adding libraries using their full path without -l which causes the ld wrapper to not realize it needs to add to the rpath. It worked for gcc, since gcc was adding other libraries from my profile. <simonsouth>mbakke: Anyway, thanks. <mbakke>simonsouth: so did you just build a Guix disk image for your board? :-) <simonsouth>mbakke: I believe so, assuming everything worked. An installer image, that is. <simonsouth>mbakke: Time to write it to an SD card and find out... <mbakke>dattashantih8: oh, great that you found out! <mbakke>dattashantih8: what flags did cmake pass if not -l ? <mbakke>simonsouth: awesome, good luck! <simonsouth>mbakke: Thanks! <dattashantih8>mbakke: clang++ -o executable source.cc /profile/lib/libz.so <dattashantih8>mbakke: If shared libraries are included like this the ld wrapper doesn't realize you are linking them <dattashantih8>mbakke: thanks for the help! <mbakke>dattashantih8: right, I see. Seems like the ld wrapper could be taught to catch those cases, not sure how efficient it would be though. Maybe toggled by some environment variable? Thanks for investigating. :-) *bavier a little sad I haven't been able to polish up one of my commits in time for 1.1.0 <mbakke>bavier: what did you want to include? <bavier>mbakke: my fix to 'guix pack -R' wrapping <mbakke>bavier: if you have it in decent shape, perhaps there is still time :) <bavier>the tests are holding me up; not quite what I'd like; and I'm nervous at the thought of breaking tests somewhere <bavier>but yeah, if I can find some time to get it fixed up I'll ask if I can push it to the release branch <mbakke>:) ***cantstanya is now known as Oxford ***Oxford is now known as frank ***frank is now known as cartwright ***cartwright is now known as cantstanya <Blackbeard>hello <Blackbeard>anyone here? <xelxebar>Blackbeard: This time of day it seems to be quieter in here, but people are about <Blackbeard>xelxebar: yes, I am working on packaging some emacs mode <Blackbeard>but I had doubts about git <xelxebar>If you have any questions, go ahead and ask. People will certainly see it and someone might pick it up <Blackbeard>When I compile my package I get a few files that can be added to git, are those created automatically or something? <Blackbeard>I have stuff like t-home-6243/ and I don't know if I should add them or skip them <xelxebar>So those files are text file outputs of the build process? <Blackbeard>xelxebar: seems like so. I just ignored them for now. <bavier>Blackbeard: generally best to only add files to git if you know what they are :) <Blackbeard>bavier: yes, seems like i will do that hhaha <Blackbeard>right now I am looking for how to do guix download with git and a specific commit <Blackbeard>ohh seems like it is guix hash <Blackbeard>I am getting "error: emacs-dash: unbound variable" <Blackbeard> (propagated-inputs <Blackbeard> (("emacs-dash" ,emacs-dash) *vagrantc_ wonders why 1.1.0rc1 is based on such an old commit <vagrantc_>the tarball also seems to be missing gnu/services/linux.scm ***vagrantc_ is now known as vagrantc <str1ngs>Blackbeard: if you do guix show emacs-dash . if you look at the location field. it will tell you it's in the (gnu packages emacs-xyz) in which case you'll need to add to your use modules (use-modules (gnu package emacs-xyz)) <Blackbeard>str1ngs: ahh!! Hahaha <Blackbeard>str1ngs: as I copied the modules from it, I did not think of adding it haha so dumb of me <Blackbeard>str1ngs: thanks!! <str1ngs>it happens, no worries <Blackbeard>str1ngs: I am 90% certain by build will fail. Can you help me with it ? <Blackbeard>There are a couple things I don't understand <str1ngs>it's best to ask any questions in channel someone is bound to help <Blackbeard>Ok. <vagrantc>it looks like the tarball does not contain the commits that it claims to <vagrantc>bah. <ex101>just installing icecat via guix takes an eternity. is this normal? <Blackbeard>It seem like there a few emacn packages that do not use propagated-inputs and instead do this <str1ngs>ex101: do you have substitutes enables? <str1ngs>enabled* <ex101>I believe so, yes. <str1ngs>did you just recently pull? <ex101>Yes I did <str1ngs>ex101: does guix weather --substitute-urls='https://ci.guix.gnu.org' icecat show 100%? <ex101>Let me paste the output from that <ex101>computing 1 package derivations for i686-linux...looking for 1 store items on https://ci.guix.gnu.org...updating substitutes from 'https://ci.guix.gnu.org'... 100.0%https://ci.guix.gnu.org .0% substitutes available (0 out of 1) unknown substitute sizes 0.0 MiB on disk (uncompressed) 0.663 seconds per request (0.7 seconds in total) 1.5 requests <ex101>per second 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out") <str1ngs>ex101: ahh you are using 32bit guix? <ex101>I am, which would explain some of the slowness of things. <str1ngs>ex101: I'm assuming it's trying to build icecat? <Blackbeard>and I do not know when to modify-phases <ex101>Yes, at this point it's building. <buenouanq>rust won't build on 32 bit preventing icecat from building <buenouanq>or so has been my experience <buenouanq>if this is figured out I would love to know the solution <str1ngs>Blackbeard are you trying to package counsel-dash? <str1ngs>ex101: is your cpu 64bit or 32bit? <ex101>32, it's a Thinkpad T60, I forget which model the CPU is. It needs an upgrade. <str1ngs>ahh icecat seems blocked on 32bit maybe <Blackbeard>str1ngs: no, that was an example I found but I don't know how to know when to do that <str1ngs>Blackbeard: after unpack is fine. <ex101>Build failed on rust, surprise surprise <str1ngs>I don't see a way around that. you might have to use another browser <ex101>Interesting, okay. <str1ngs>I use nomad! no rush just scheme and a little C :P <str1ngs>I'm biased though haha <str1ngs>err rust even <Blackbeard>ohh my package works now :) <Blackbeard>but I think there are a few things I still need to package <str1ngs>nice <brendyyn>Was this debt ever repaid? <str1ngs>umm git grep | Stallman :( <str1ngs>git log* <Blackbeard>str1ngs: it works :) thanks!!! <str1ngs>Blackbeard: no problem <Blackbeard>i packaged org-roam <str1ngs>nice <Blackbeard>now I will package uml-mode <Blackbeard>seems quite easy <vagrantc>ok, pushed a fix for missing gnu/services/linux.scm in tarball... <bdju>does anyone know what to look out for when buying a large networking switch and wanting to keep freedom in mind? not sure if it's enough to go for unmanaged rather than managed, like I don't know how much software they run <bdju>I've put openwrt on routers but I don't know as much about switches <bdju>planning to run ethernet to many rooms of a new house soon and I figure I'll need more than just the ports on the router for it all to come back to <damo22>bdju: does it need to be gigabit <damo22>if not, 100M switches are pretty cheap, i dont think you need to put software on them <damo22>actually gigabit unmanaged are pretty cheap too ***gal is now known as galex-713 ***galex-713 is now known as gal ***gal is now known as galex-713 <chipb>depends on your definition of freedom, of course. heh. <chipb>aren't FSF a-ok with embedded blobs if they're not field-updatable? <chipb>I'm fuzzy on detail, so don't take my word for it. <chipb>it's an interesting question where the openness can stop and still be considered "free". <chipb>do you require the RTL description of the ICs that implement the switch? what about the silicon masks? <damo22>chipb: well you dont want a switch that dials home base and relays copies of packets over the internet <damo22>hopefully none do that <chipb>indeed, but you can certainly hide a lot in a die and still make it look like a dumb switch. <damo22>i would go with a brand that fsf has previously approved for other devices <damo22>if they exist *chipb shrugs. <chipb>have they torn it apart and decapped the chips inside? how about your particular revision or specific unit? *damo22 hands chipb a tinfoil hat <chipb>you're the one asking for a switch that won't dial home base... <damo22>lol <chipb>freedom certification and that are orthogonal things. <damo22>are they? <damo22>im pretty sure fsf would not certify as RYF a device that dials home base with your data <chipb>if you get the FSF to endorse a particular switch as not dialing home base, I will eat my hat. <damo22>are you saying that RYF only ensures that there is potential for freedom on the device? not that its default behaviour is to do so <damo22>i think thats incorrect <damo22>because for example, x200 laptop has potential to be fully free, but shipped from the factory it doesnt only from companies that refurbish them and load libreboot on them <damo22>so RYF applies only to the devices sold by those companies <damo22>not the original boxed device <chipb>no. I'm saying it doesn't even preclude embedded, but not field updatable software. <chipb>"However, there is one exception for secondary embedded processors." <damo22>but the exception only applies to a processor that is not the primary processor of the system <damo22>eg, the BIOS of a x86 is not excluded because it runs on the primary processor <damo22>i dont think a network switch is a general purpose pc <chipb>understood, but the exception applies to the secondary processor with uninspected, non-free code that has direct access to the gates that forward packets. <chipb>it's not a general purpose pc, but it doesn't mean it doesn't execute software. <chipb>fortunately, a [unmanaged] gigabit switch is *just* simple enough it's probably a basic state machine for e.g. autonegotiation support. there's probably not a full-on processor. <damo22>right, its a bit of a grey area <chipb>don't get me wrong. given the tangle of complex layers of modern hardware, I think the FSF draws a pretty reasonable line. <damo22>because it could easily have a secondary processor attached that interferes with packets <damo22>another example is the management engine in intel chips <chipb>I wonder if one could also argue that the Intel ME is also a secondary processor...if only its software were burned to a mask permanently. ;-P <damo22>err no thanks <chipb>agreed. <damo22>i like the fact i can wipe 95% <damo22>of its unauditable software <chipb>unauditable [to you] software. <chipb>big enough checkbook (or rubber hose), I'm sure they'd arrange something. <damo22>yes, who else would matter for a device i paid for <damo22>given its a consumer device <damo22>i dont really want to read all the source anyway, i wouldnt be able to share what i found <chipb>I dunno, I'd be reasonably happy if, say, google project zero was able to get access for audit. <damo22>ok <chipb>better than nothing, not that it'd be sufficient for everyone. <damo22>sure <chipb>I'd certainly prefer open. <damo22>if they indeed implemented RSA correctly, there would be no way to run a libre fw anyway unless they signed it <chipb>going full circle back to "depends on your definition of freedom, of course." <chipb>it all depends on where your line is. <damo22>unless you have access to a 2048 qubit quantum computer that is <chipb>right. I should probably head to bed. <chipb>good luck on the switch purchase. TLS/wireguard all the things. ;-P <damo22>goodnight chipb, go find chipa <damo22>:P <reepca>anyone else get a big white rectangle instead of the playback bar when trying to watch youtube videos on icecat? Strangely enough it only started a bit ago... I didn't even restart icecat or anything, just opened another youtube tab and now they all have a white bar covering the bottom half whenever the playback bar is visible ¯\_(ツ)_/¯ <Blackbeard>reepca: did you upgrade icecat? <Blackbeard>reepca: I had some trouble with extensions recently. I deleted my profile and created a new one <reepca>Blackbeard: I upgraded icecat relatively recently, but have been able to use it fine for viewing youtube for quite some time since then. I take it you don't experience the issue currently? <civodul>Hello Guix! <sneek>civodul, you have 1 message! <sneek>civodul, efraim says: it wasn't downloading sources or building anything, it was more like it was deciding what to do. Now it is building glibc-cross-i586-pc-gnu-2.31 <civodul>weird <Blackbeard>reepca: I use mpv to watch youtube <Blackbeard>civodul: hi ! <Blackbeard>Is there an automated way to know when a package has a new release? <civodul>"guix refresh", for most packages but not all <Blackbeard>Like if there is a github package <Blackbeard>A good <Blackbeard>I was building some Emacs packages and I was thinking about that <Blackbeard>I have two packages to send <nly>good day all <Blackbeard>nly: hi :D <nly>how generous do you feel today? <nly>could someone please take a look at this patch? https://lists.gnu.org/archive/html/guix-patches/2020-04/msg00258.html <nly>hello Blackbeard :) <nly>hope everyone's fine and all <Blackbeard>The more I use Guix <Blackbeard>The more I feel like I was wasting my time not using it as my main distribution <Blackbeard>The problem is my God damn printer >_< <reepca>hmmm, I'm not too familiar with web rendering, but I suspect a pure white gradient causes pure white output. So I'd imagine it's a problem on youtube's end... <Blackbeard>reepca: can I suggest you to try a different website see if it works? <Blackbeard>reepca: https://invidio.us/ it is a front end for youtube <Blackbeard>reepca: here is the AGPLv3 code https://github.com/omarroth/invidious <reepca>Blackbeard: invidious works <Blackbeard>reepca: I know is not a real solution. But I am glad. <reepca>Blackbeard: better than waiting for youtube-dl to finish to start watching, though. As far as I can tell the issue is that a pure white, non-transparent gradient is being used for some reason. And for some unknown reason it doesn't happen on the other two systems I just tested on (which use firefox and chrome). And it doesn't happen in ungoogled-chromium either. Weird. ***pie_[bnc] is now known as pie_ ***pie_ is now known as pie__ ***pie__ is now known as pi^e ***pi^e is now known as pi^e_ ***pi^e_ is now known as pie_[bnc] <Blackbeard>reepca: yes, weird :/ <efraim>civodul: the commit for /gnu/store/qv1ajfwsmj1pyb5r2qqsk4hmr3cpk7z7-guix-1.0.1-hurd-16.9ae76b7-checkout.drv doesn't seem to exist :/ <janneke>efraim: that's me! are you looking at wip-hurd-vm? <efraim>janneke: I see your new commits, I'm trying to build it again now <efraim>yeah <janneke>yeah i failed to refresh the guix hash <janneke>after the rebase <civodul>ah yes, you have to run "make update-guix-package" from a public commit <sarg>I've sent my first package to guix-patches. How do I push it forward? In debbugs there are >200 bugs with patch available, some of them dated 2017. Is there an established process for reviewing patches? <civodul>but we can update it later <civodul>hi sarg <civodul>sarg: volunteers pick it up <civodul>often it's quick, sometimes it falls into the cracks <civodul>you can wait for a couple of days and then send a ping <civodul>also patches that are simple, that pass "guix lint", etc. pass review much more quickly :-) <sarg>Here is the package https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40479 <sarg>Should I replace this call to adb with one provided by guix? https://github.com/mvdan/fdroidcl/blob/bda18064d61e91e82c7c645e52964e588f8527cc/adb/device.go#L29 <sarg>Currently it uses$PATH
<xelxebar>Trying to switch to list profiles and switch to an older on, what subcommand am I looking for?
<xelxebar>Just not seeing anything obvious in guix help
<brendyyn>xelxebar: subcommands have help pages too. guix package --help
<xelxebar>Yeah, or guix help <subcommand>.
<xelxebar>I've haphazzardly read through several of them, but for the life of me cannot find what I'm looking for.
<sarg>guix package -l and -S
<xelxebar>Oh, the term I was looking for is "generations"
<xelxebar>Thakns, sarg
<sarg>xelxebar: --help is often not enough. I recommend you to read manual - it's well written and I've learned a lot from it.
<xelxebar>Yeah, I sort of binged the manual yesterday, so the outline of concepts is mostly in my head. Apparently several of the details didn't stick though.
<xelxebar>Surprised at how many of the services are documented
<xelxebar>nly: Did you try spinning up the vm image? :)
<xelxebar>nly: Also, did you see the follow up? https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-hurd/
<nly>not yet, but yes
<nly>i just found out about it
<rekado_>on wip-hurd-vm I get this error: make[2]: *** No rule to make target 'gnu/packages/patches/gnutls-cross.patch.patch', needed by 'all-am'. Stop.
<efraim>rekado_: I just pushed a fix for that
<xelxebar>Loving the fact that the hurd is getting so much tlc lately
<nly>what's tlc?
<efraim>tender love & care
<nly>nice, and thank you guys :)
<nly>s/guys/folks/
<guix-vits>Hi Guix.
<nly>good day guix-vits
<xelxebar>The output of guix lint -c cve is a bit humbling...
<civodul>perhaps we should change it to just display: DON'T PANIC!
<efraim>you can mostly ignore the older glibc versions, but yeah, it does look bad
<efraim>I haven't run it recently but it's about 200 packages
<efraim>some are more concerning than others once you start looking at them
<efraim>If you do want to tackle some of them I found debian's security tracker to be a good source of patches: https://security-tracker.debian.org/tracker/CVE-2019-16275
<efraim>just replace the CVE string with the CVE in question
<efraim>and it's a good chance to learn about using grafts!
<guix-vits>nly: i'd updated my box yesterday (again used guix pull instead git pull). A bit confused by tor-service-type: it's shown as stopped, while it's works.
<xelxebar>efraim: Looks like 188 packages right now. mysql@5.7.27 boasts the longest list by far.
<nly>guix-vits: i'm updating today :), i have the same experience with tor-service-type, i just disabled it
<nly>prolly, i didn't add it properly
<nly>reepca: i see the same white bar, on old icecat (60 days old)
<nly>it's fixed in fullscreen mode tho
<guix-vits>nly: strangest thing that it's working; probaly it's need to be in "one-shot" category?
<civodul>nckx: the ISO compression trick looks nice!
<civodul>should we ship it?
<cbaines>the compression is exciting, as that should help with the Guix .go files
<nly>guix-vits: i dunno
*guix-vits "neither i'm"
<xelxebar>make authenticate is erroring out for me
<xelxebar>automake-1.16: error: cannot open < ./doc/guix-cookbook.de.texi: No such file or directory
<civodul>xelxebar: did you run ./bootstrap?
<xelxebar>That's it. Should be run from the build environment, correct?
<civodul>yes
<xelxebar>Thanks
<Blackbeard>guix-vits: I am better, thanks for asking. I was packaging stuff for Emacs
<Blackbeard>guix-vits: I had been learning to document everything with org-mode so I easily remember everything
<Blackbeard>I used org-mode but I am not really used to take notes. Just to write homework
<Blackbeard>So I packaged org-roam
<guix-vits>Blackbeard: i hope it's more intuitive than M-x org-mode (i'm going to read a manual somewhere)
<Blackbeard>guix-vits: I had been reading more about how to take good notes than the actual workflow. But org-roam has a nice workflow. I also tried org-brain
<Blackbeard>I also packaged emacs-uml-mode
<Blackbeard>Have a more visual representation of the modules and their relationships
<Blackbeard>To have*
<Blackbeard>I think it will help me
<Blackbeard>Oh that reminds me, when I build a package with guix in my branch some files are created, is that normal?
<Blackbeard>like i have a directory t-home-6243/
<guix-vits>Blackbeard: i've those too, but idk if that is good.
<guix-vits>tmp-profile, tmp-home (if t stands for temporary)
<Blackbeard>guix-vits: I see
<Blackbeard>They gave me a bit of conflict with git pull
<Blackbeard>But I played with magit so that was fun
<str1ngs>that sounds new to me
<str1ngs>also those should not give you a conflict on git pull. did you stage or some commit something that you did'nt want to?
<Blackbeard>But everything is solved now
<str1ngs>one thing I would do, when creating packages is commit them your own branch. and only git pull on master. this way you can rebase your branch onto master. you should have less merge conflicts this way.
<str1ngs>also I suggest a get fetch , diff then merge workflow.
<Blackbeard>That's what I did. I had some git am session.
<str1ngs>if you have in tree changes you can stash them first. that's more advanced approach though
<Blackbeard>It was weird because I have only done minor changes in my branch
<Blackbeard>And I pulled to master
<str1ngs>hard to say what the conflict was. but I would not use git pull IMHO. it's not a good workflow
<Blackbeard>But I was able to solve so it is good.
<Blackbeard>str1ngs: ohh so git fetch instead?
<Blackbeard>I didn't know thtat
<str1ngs>I find git fetch, then diff and merge when you have a good grasp whats going to occur
<str1ngs>though guix has many commits so it's better to pull on master and rebase your branches onto master.
<str1ngs>this way you are only dealing with conflicts that you have context with.
<Blackbeard>str1ngs: ok. I will do that.
<efraim>seems there's no guix-daemon running in the hurd vm
<str1ngs>efraim: it probably needs to be ported
<str1ngs>to hurd that is
<str1ngs>Blackbeard: also stash is nice if you want to save commit you don't want to commit quite yet.
<nckx>Good morning, Guix.
<sneek>nckx, you have 1 message!
<sneek>nckx, raghavgururajan says: The groups suggestion worked. Thank you! But I still get segmentation fault though. At least now with no other errors.
<guix-vits>Hi nckx.
<nckx>civodul: Yes! I'd like to see it in the next tag so it can get some testing, but this should be a safe change. Doesn't touch any of the grub-mkrescue magic that keeps us booting everywhere.
<nckx>civodul: Is upstream/version-1.1.0 open for cherry-picking?
<rndd>hi everyone! do anybody use guile-curl package? i have problem with it.
<janneke>it looks like core-updates has broken package-transitive-supported-systems since "last week" (1808e64de0)
<janneke>well, after running make update-guix-package
<janneke>any ideas?
***reepca is now known as reepca
<mekeor>do i understand correctly that with guix system docker-image, it's possible to make a docker-image out of a guix-system-declaration; and with (gnu services docker), it's possible to add a docker-image as a service to a guix-system-declaration?
*janneke sends bug report
<efraim>python-prometheus-client is in both (gnu packages monitoring) and (gnu packages python-xyz)
<civodul>mekeor: yup!
<civodul>see https://guix.gnu.org/manual/devel/en/html_node/Invoking-guix-system.html for 'guix system docker-image'
<civodul>janneke: right, mbakke reported a bug
<civodul>i haven't looked at it yet
<civodul>looks like the pressure is growing
<civodul>nckx: not really :-) it's on a case by case basis
<civodul>i'm testing your ISO compression patch on master now
<janneke>ah, crap then i possibly reported a dupe
<civodul>if it goes well, we can take it
<civodul>sorry that this is becoming much of a problem :-/
<janneke>ah, nice bug report; i'll just close mine
<mbakke>janneke: I just merged them, so closing will close both!
<janneke>sorry for not checking well -- i was too frustrated to check well enough
<janneke>mbakke: thanks!
<mekeor>civodul: that's so cool! i'm now seriously considering to use guix-system on my server. i was always thinking "when there is no guix-service-declaration for the service i want, i'll have to write my own" and that felt quiet uncomfortable. i don't know why i didn't think of it earlier but just today, i realized i could just quickly use docker-containers running on guix-system (until i write a guix-service-declaration) for that
<mekeor>services :D
<mbakke>janneke: no worries, it's perfectly reasonable to assume that the tests pass at any given time :-)
<janneke>mbakke: 5h ago i had guix build --source hello' working and realised i had reverted the guix update on wip-hurd-vm
<janneke>because i wanted that to succeed as well
<mbakke>janneke: oof... at least now you know what the problem is :-/
<janneke>hehe, i learned a lot -- but i went is a sort of "stress mode" -- real work as well, try a rebuild in the background, retry, retry...wtf :-)
<janneke>"this should only take 5m, at most" -- not a helpful belief to hold
<janneke>does this sound familiar: ;;; no code for module (charting)
<civodul>janneke: this warning is fine: it's because guile-charting is a soft optional dependency of "guix size"
<civodul>see the neat "map" at https://guix.gnu.org/manual/en/html_node/Invoking-guix-size.html :-)
<janneke>civodul: ah, it was just before: error: failed to load 'gnu/system/install.scm': No such file or directory
<janneke>so i blamed the error on the warning
<janneke>cool charts!
<bricewge>Where can I get this background? https://guix.gnu.org/screenshots/slim/
<raghav-gururajan>Hello Guix!
<bricewge>BTW it's not a screenshot of SLIM but GDM.
<bricewge>I have looked in guix-artwork and it ain't there
<bricewge>Hey raghav-gururajan, how are you doing?
<raghav-gururajan>bricewge o/ I am doing good. How about you?
<bricewge>Fine
<apteryx>raghav-gururajan: o/
<sneek>Welcome back apteryx, you have 1 message!
<sneek>apteryx, raghavgururajan says: I have sent a patch to #40264, to add mirror and fix some formatting, in linphone.scm.
***ChanServ sets mode: +o apteryx
***apteryx sets mode: -b guix-ci!*@*
<bricewge>rekado_: Hum, it looks like it's missing the Guix logo but the pattern is the same
***apteryx sets mode: -b guix-ci!~guix-ci__@141.80.181.40
***ChanServ sets mode: -o apteryx
<apteryx>raghav-gururajan: I'll look into it tonight :-)
<nckx>apteryx: Thanks for taking care o' that by the way.
<apteryx>nckx: np :-). I've learned a thing or two in the process.
<civodul>nckx: i've run the "gui-installed-os" test off the compressed ISO, and it passes!
<civodul>i'll checrry-pick it to version-1.1.0
<civodul>very cool!
<civodul>did you check the size of the ISO with and without compression?
<nckx>civodul: Passed here too but happy to hear it's deterministic 😉 What do you mean by the last line?
<nckx>IIRC I compared the two in my cover letter.
<nckx>That was master, though,
<nckx>I don't see that changing much if at all.
<cbaines>Has anyone got a working virt-manager at the moment?
<cbaines>(where working means you can start it successfully)
<sirgazil>bricewge: If I recall correctly GDM uses separate components for the theming of the login screen (background and logo are separate).
<sirgazil>bricewge: Where would you like to use the background? I think I can help you.
<civodul>nckx: those tests were not using ISO9660 though, so i changed that
<civodul>i missed your cover letter i guess, apologies!
<sirgazil>bricewge: Or see if you like any of these backgrounds I sent for review recently: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39760
<sirgazil> https://issues.guix.gnu.org/ is not displaying some reports and http://logs.guix.gnu.org/guix is showing logs only to 2013.
<civodul>sirgazil: http://logs.guix.gnu.org/guix starts with logs from today
<raghav-gururajan>apteryx o/
<raghav-gururajan>apteryx Thank you!
<civodul>as for issue., it's not picking up changes since yesterday i think
<alextee[m]>how can i get the new iso for testing?
<alextee[m]>oh nvm i didn't see "iso.xz" there. thanks ctrl+f
<nckx>civodul: No worries. The Gnome thing was a joke (I was, before things turned to shit, going to post an silly ‘Add Gnome 3 to the installer which reduces the size by a few megs compared to our bloated TUI’ patch on 1 April), but actually… running the ‘GUI’ installer in a terminal window and slowly porting the UI to Zenity or so would be cool… One could watch Guix tutorials or cat videos while installing.
<nckx>Or Guix tutorials with cats.
<civodul>definitely
<civodul>Guix tutorials with cats would make the installation process much nicer
<civodul>like, even if it fails eventually, you're not disappointed
<nckx>guix instdieoreoaredoarer ceoahur5({+ gnome.
<nckx>This is Fuzzy, our fuzz tester.
<bricewge>sirgazil: It's for the new lightdm login manager https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35305
<gr8>Hi, I'm interested in Guix from a security perspective. Since Guix is declarative and deterministic, what options are there for verifying the integrity of the system installed on disk (like an intrusion detection) and for verifying the integrity of the system at boot time in order to boostrap trust?
<raghav-gururajan>Folks! Why some packages are patched with "/share/foo/bar" path?
<sirgazil>Ah, logs are in a different order :)
<bricewge>sirgazil: guix-checkered-16-9.svg is nice but it'll probably end up under the user selection popup
<raghav-gururajan>For example, gajim is patched with "/share/gajim/plugins". But gajim plugins are managed by gajim under "~/.config/gajim/plugins" for each user?
<sirgazil>bricewge: Give me a few minutes to do what you need.
<emys>hi I get errors like the following: /gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
<emys>environment variable is set: GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <raghav-gururajan>cbaines Was it an error regarding 'libvirt'? I reported it upstream long ago and still not fixed it seems. <emys>package glibc-locales is installed <emys>any ideas? <raghav-gururajan>emys Is it on foriegn distro? I think you have to meddle something distro's service manager. nckx could explain it better. :-) <emys>its on debian <cbaines>raghav-gururajan, no, the error is "TypeError: Item 10: Must be gobject.GType, not GObjectMeta" <nckx>raghav-gururajan: nckx, the person who (rounded down) uses 0 Guixes on foreign distros? Not sure I'll be of much help 😛 <mbakke>emys: guix-daemon might be referring to the wrong locales, try upgrading the root users guix profile and restart 'guix-daemon.service'. <nckx>Nah, I do manage one Guix/Ubuntu system, I just don't put much effort into it. emys: Try setting GUIX_LOCPATH in your systemd service, like so <https://paste.debian.net/plain/1139549>. Note that my profiles might not be the same as yours; I think the installer uses root's profile by default. <nckx>gr8: ‘guix gc --verify=contents,repair’ can be used as a rudimentary IDS. It scans your entire /gnu/store and compares each file to its original checksum in /var/guix/db. It's meant to weed out corruption, not malice (an attacker could modify the db), and if an attacker has managed to modify the read-only mounted store you've already lost. <nckx>We don't do any boot-time security theatre yet. <emys>nckx, mbakke I think I just installed the locales stuff on my normal user not with the root user, will try that <nckx>emys: That's why I changed my .service to start ‘my’ Guix, by the way. Only one thing to keep up-to-date & no constant confusion. But that's orthogonal to your problem. <bricewge>sirgazil: Thank you, that's exactly what I was looking for :D <sirgazil>No problem. <nckx>raghav-gururajan: But we don't want gajim storing random copies of plugins in ~, we want them to be managed by Guix, so we tell Gajim to look in the user's profile using native-search-paths. <nckx>It is the Guix way. <raghav-gururajan>cbaines I see. <bricewge>This is the way <raghav-gururajan>nckx LoL. You were telling me something about changing a value in systemd service, so that guix stops throwing locale related error on foriegn distros. <nckx>I just don't remember exactly what it was 😛 <raghav-gururajan>nckx Ah. Would it be better to leave app's components to be managed by app itself? Like guix manages applications, applications manages it's own plugins. <raghav-gururajan>That's okay. <nckx>raghav-gururajan: Won't that break roll-backs, inferiors, & the like? <raghav-gururajan>nckx Anyway, even after installing gajim-omemo, the omemo plugin does not appear as 'installed' in gajim. User still need to manually 'install' omemo to make it work. <nckx>Interesting. That should definitely be fixed, but I don't use Gajim. <raghav-gururajan>nckx I dont think so. Files that are stored under "/.foo" are not reproducible or tranactionable anyway. For example, account information, bookmarks etc are still goint to me maintained after guix ttransactions. <raghav-gururajan>nckx I consider plug-ins are like bookmarks. That are user-specific data. <raghav-gururajan>I think managing plugins by guix is not feasible in long-run. Imagine if we start making guix to handle Icecat plugins/addons. There are lot and keeps growing. I can't comprehend that user has to install each add-on as package. <nckx>I don't, and I think you'll have a tough time convincing others that plug-ins are somehow exceptions to all other software. Bookmarks are mutable databases, so are preferences, plug-ins are code. <nckx>One of these things is not like the others ♪ <nckx>They are versioned (like all software) but not particularly mutable. <raghav-gururajan>Ah I see. I get what you are saying. Yeah, plugins are code. <nckx>I agree that the logistics are problematic. <nckx>raghav-gururajan: How is the user expected to obtain these plug-ins? <nckx>Is there a built-in shoppe? <nckx>I think this is manageable. <raghav-gururajan>Hmm. I we are doing this, then I think we have to find a way to disable the ability to manage plugins by the application. Because, guix gonna handle the plugin in a transparent way (verifiable source, secure build, hashes etc.). But application gonna just download a pre-built binary, which can be malicious or non-free. <nckx>I keep getting disconnected and can't install Gajim, so I'm going to punt on this discussion for now. I'll read the logs though. <nckx>raghav-gururajan: Absolutely. <raghav-gururajan>nckx In gajim? The gajim has a starter plugin called 'plugin installer'l, which installed by default with gajim source. The gajim installer downloads and installs plugins. <nckx>That's a real problem in general. Trust aside, every application-specific ‘plug-in store’ that pops up is now something we have to audit for freedom (or disable, see the Retroarch mess). When we compare the workload of ‘packaging every plug-in zomg’ we have to compare it to the workload of auditing the upstream shoppe anyway, *not* to ‘letting upstream handle it’. That wouldn't be a fair comparison. <raghav-gururajan>The thing is, a user could just ignore gajim-omemo package and install omemo plugin using plugin-installer. *nckx really signing off now, hop that last hurried salvo was readable 🙂 o/ <raghav-gururajan>nckx Later o/ <raghav-gururajan>leoprikler Just in pinging you to see if you have clue about why installing gajim-omemo plugin doesn't activate that plugin in gajim. This is regarding above ^ discussion. :-) <sirgazil>raghav-gururajan: In some workplaces people use application plugins in the business workflow. I think letting guix manage those plugins would make it easier to set up the business tools in all computers, instead of manually installing plugins using per app using the application plugin manager. <emys>I wrote a guix.scm inspired by https://github.com/wingo/fibers <emys>I thought i could build now via % guix build -f guix.scm <emys>guix build: error: failed to load 'guix.scm': No such file or directory <emys>guix.scm is definitely there and readable by my user <guix-vits>emys: if ./guix.scm ? <civodul>emys: it may be that "No such file" is about the 'source' field of the package <civodul>(admittedly confusing) ***gal is now known as galex-713 <vagrantc>civodul: any chance of a cleaner rc tarball before the release? <vagrantc>i can build a tarball from a git snapshot, but the process has never been smooth and would love to avoid it if i could :) <civodul>vagrantc: yes, we'll have to do an RC2 i guess <civodul>oh well, Monday is a day off in some parts of the world anyway, so maybe not a good day for a release *civodul tries to see the half-full glass :-) <vagrantc>i think the guix glass has been overflowing with awesome :) <emys>guix-vits, yes, ./guix.scm is the same <emys>civodul, source is provided, same content like in the "fibers" guix.scm <raghav-gururajan>> ‎sirgazil‎: raghav-gururajan: In some workplaces people use application plugins in the business workflow. I think letting guix manage those plugins would make it easier to set up the business tools in all computers, instead of manually installing plugins using per app using the application plugin manager. <raghav-gururajan>That's true. Yeah, I now think this way is better as it provides transparency, reprodicability and authenticity. <rekado_>sirgazil: issues aren’t updated due to an unresolved discussion with the maintainers of debbugs.gnu.org <vagrantc>huh. mhw even updated the linux-libre 5.6 hashes to 5.6.3 ... but no comment on the bug :/ <civodul>vagrantc: i think you'll have to ping them explicitly <civodul>i don't think Mark really reads mailing lists these days <civodul>emys: can you change (dirname (current-filename)) to (pk (dirname (current-filename))) ? <rekado_>raghav-gururajan: plugins should be managed via Guix but this doesn’t mean that the application’s mechanism to install them needs to be disabled. <civodul>emys: then when you run "guix build -f guix.scm", it'll display the directory name it thinks is correct <emys>civodul, will try, so far it seems the guix.scm is loaded and its part of the logic within that file I think <rekado_>raghav-gururajan: the GNOME browser Web, for example, used to offer an “install” button for extensions. <rekado_>they were not installed through the browser but actually handled specially <rekado_>raghav-gururajan: Emacs is another example of an application that has extensions that can be either installed via Guix or via the application itself. <rekado_>so both ways can be enabled — with one of them better than the other. <raghav-gururajan>rekado_ Hmm. Wouldn't that be a security issue? The downloaded code can be anything. <rekado_>your question is specific but in a very vague context, so it cannot be answered. <vagrantc>civodul: i've CCed mhw on the bug report ... maybe they're not getting my mails? <rekado_>gotta go <civodul>vagrantc: i'd say just ping; it's not great, but i think there's nothing personal <raghav-gururajan>rekado_ I meant that when app manages plugin, it gonna probably download binary file, which is not verifiable and also cam be malicious. <civodul>or get someone else's opinion and go ahead, dunno <vagrantc>fair enough <emys>civodul, I believe the problem is due to the git-predicate procedure <civodul>ah, could be <emys>I cannot find documentation for it, don't know from where its pulled <civodul>it comes from (guix git-download) <civodul>you could do "strace guix build -f guix.scm" to see which open(2) returns ENOENT <civodul>well, towards the end of the log <raghav-gururajan>sneek, later tell nckx: If you try the gajim and gajim-omemo, let me know what the issue might be. May be I can work on it, Thanks! <sneek>Will do. ***ssouth is now known as simonsouth <civodul>xorriso is terrrribly slow :-/ <emys>civodul, ok, the problem was I had a script called ./bootstrap and I kind of removed it from the repo because I renamed it to ./autogen.sh for following convnetions. <emys>and that seems to have caused the issue, after committing all these changes, stuff worked. <civodul>ah i see <civodul>yeah probably git-predicate expected that file to be there, because it had been checked in before <emys>what is the typical workflow when working with such a setup, would I write a manifest file for a development environment or are people using the package definition to do development? <civodul>the guix.scm file plays both roles <civodul>it allows you to install/pack/whatever the package <civodul>or you can run "guix environment -l guix.scm" to get a dev env <emys>ah and thanks civodul for the hint for strace, really neat, always heard about that but never used it. <civodul>cool, yw! <mbakke>TZander: do you see any messages in dmesg when you experience lag in the browser? <TZander>wrong nick? <lispmacs[work]>janneke: hi, I reported bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40542 <lispmacs[work]>let me know if I can run commands or test something to be helpful <janneke>lispmacs[work]: thanks! <janneke>i cleaned-up "wip-hurd-vm" and while most code looks pretty OK now, several things have broken since the rebase <mbakke>TZander: lol yes, sorry <mbakke>joshuaBPMan: do you see any messages in dmesg when you experience lag in the Guix browsers? <pkill9>good afternoon guix <sneek>pkill9, you have 1 message! <sneek>pkill9, xelxebar says: Here's the original blog post about Guix on Hurd: https://guix.gnu.org/blog/2020/deprecating-support-for-the-linux-kernel/. It has a link there to a prebuilt image. <pkill9>xelxebar: that isn't actually guix on the hurd, that image is debian on hurd :P <pkill9>xelxebar: the guix command in that image is a script made to look like it's running guix lol <lispmacs[work]>janneke: what commit was the one you used for the blog post <janneke>lispmacs[work]: that was something similar to branch wip-hurd-vm8 @ https://gitlab.com/janneke/guix.git <janneke>however, that branch was reset too, and references a non-public commit <janneke>if you really want, you could try "wip-hurd-vm-old-cu" on my gitlab <mbakke>civodul: WDYT of increasing the priority of the aarch64->arm builders on the CI? i.e. ensure that the aarch64 nodes are prioritized over the QEMU user-mode builders for armhf, as both cmake-build-system and meson-build-system struggle with QEMU <leoprikler>raghav-gururajan: I honestly don't care, as I use Guix even for managing all my emacs stuff sans my own config. <leoprikler>I personally find disabling the plugin manager if its behaviour is confusing to be the better option. <leoprikler>Btw. has something changed for the gnome service? <noobly> what might be the quickest way to get a math typesetting program running? I've been trying to downlaod texlive for days now, it's a big package and my wifi is poor <leoprikler>you could go for a smaller subset of texlive or use some fast cable connection <leoprikler>if you have a laptop and a large desktop with only one cable, consider offloading to the desktop <noobly>leoprikler: unfortunately I'm on satelite internet, so even the cable is slow, but i'll start thinking in that direction, thanks <noobly>im considering texlive-base but i don't know if that'll cause problems due to needing some package like amsmath <leoprikler>doing the thing modular is still a good idea <leoprikler>if texlive-base is lacking something, just get that one or two package extra <leoprikler>unless you guix pull in between, you won't have to download texlive twice <noobly>leoprikler: that's going considerably faster, thanks for the idea <Blackbeard>Hi :D <guix-vits>Hi Blackbeard. <Blackbeard>٩(◕‿◕｡)۶ <jonsger> https://ci.guix.gnu.org/log/zn36dd3kgw4hfsbxz0kadldqsxcwdh21-opencv-3.4.3 is this a build host failure or an abortion? <civodul>mbakke: i agree about prioritizing actual hardware, i thought that was the case <civodul>when you say "struggle", you mean "fail"? <civodul>if so, we should "do something 'bout it" <civodul>mbakke: in other news, i looked at the package-transitive-supported-systems issue <civodul>i have a lead, which is that ld-wrapper-boot0 memoizes the bash it first sees <civodul>either the gash graph, or the other one <civodul>if you see what i mean <civodul>to be continued... *civodul -> dinner <ATuin>hello <mbakke>civodul: sounds plausible, thanks for investigating. Enjoy your dinner! :-) <ATuin>which version of sbcl is used to build asdf packages, i have alexandria complaining that can not be loaded because it was compiled with version 2.0.1 <ATuin>when i run "guix package -u" it's not updated, so i guess its inputs did not change <bandali>fishyfriend, hey, were you able to put together and send a patch for adjusting the bit about git-authenticate in the guix manual? <mbakke>civodul: I'll adjust machines-for-berlin with the priority change. <jonsger>does the CI actually building the master branch? <lfam>It looks like it hasn't succeeded since sometime yesterday jonsger <lfam>The first failing commit was 960abd5, the libssh update <lfam>Not sure what's up with that... I did test building Guix <jonsger>lfam: what is the difference between guix-master and guix-modular-master? <lfam>jonsger: guix-master builds Guix packages, guix-modular-master builds Guix <jonsger>lfam: and if guix-modular-master doesnt succeed guix-master has nothing to do or? <lfam>I'm not sure how it works <lfam>I see that libssh 0.9.4 failed to build on armhf: https://ci.guix.gnu.org/build/2560982/details <cbaines>If you click through to libssh 0.9.4, it failed to build on ci.guix.gnu.org for the armhf-linux system <lfam>Yup <lfam>Those glorious sloooooooooooooooow computers <cbaines>This is apparently the Cuirass build https://ci.guix.gnu.org/build/2560982/details <lfam>mbakke: Are you around? What do you think of the libssh-0.9.4 build failure on armhf? <lfam>The CMake configure phase fails immediately <TZander>yeah! My first package got merged :) I'm happy. <lfam>CMake Error at /gnu/store/lxj8wisj7ylwc67x1rshiw24fb5digx5-cmake-minimal-3.15.1/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message): Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") <jonsger>TZander: congrats <lfam>Congrats TZander <TZander>tnx guys <mbakke>lfam: right, CMake frequently fails on QEMU-emulated armhf builds <mbakke>lfam: the real issue can be found further up in the log, with compiler_id_detection failing <jonsger>TZander: you are involved in KDE? <TZander>jonsger: long time ago. <mbakke>lfam: I restarted the derivation, and have also decreased the priority of the QEMU armhf builders to make it more likely to build on AArch64 (which works fine) <cbaines>I didn't realise there were build machines using QEMU behind ci.guix.gnu.org. I guess maybe they could do MIPS as well, although I haven't been able to even build hello on mips using QEMU. <noobly>does anyone here use emacs to export latex to pdf? I read an old mailing list thread saying this is unsupported <alextee[m]>so with hurd, all packages will work as long as they are the same architecture? <alextee[m]>or does changing the kernel means you need to re-compile things separately? <alextee[m]>mean* <noobly>hi, guix is stilling me to set environment vars by running "$GUIX_PROFILE=/home/me/.giux-profile" \ . "$GUIX_PROFILE/etc/profile" but this command fails, what does it want me to do/. <noobly>*? <TZander>While configuring someting in a guix package definition. What would be a good way to create a small file with the content like: #define GIT_COMMIT_ID \"$GIT_COMMIT\""
<TZander>calling 'echo' in a lambda?
<noobly>to any guix latex users, i ran fmtutil-sys --all, and was returned this: http://dpaste.com/28VG857, is this a problem?
<noobly>im trying to uninstall a package i jsut installed, but guix is saying it's not found in profile.. why might this be?
<NieDzejkob>TZander: grep for with-output-to-file for examples
<Blackbeard>noobly: can you do $which package <noobly>hmm, which texlive-base is saying there is no texlive-base in "/run/setuid-programs:/home/daws/.config/guix/current/bin:/home/daws/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin" <TZander>cool, thanks NieDzejkob <noobly>Blackbeard: ^ <Blackbeard>noobly: wait, let's go by parts. Are you using Guix as a package manager on your distribution ? <noobly>Blackbeard: yes, and that distribution is guix <Blackbeard>noobly: can you do$ which pdflatex
<TZander>does anyone know how to find the path to the build dir while configuring a package? A variable that leads me to something like /tmp/guix-build-myPackage/build/
<noobly>Blackbeard: /home/daws/.guix-profile/bin/pdflatex
<Blackbeard>noobly: what about $which latex <noobly>Blackbear: /home/daws/.guix-profile/bin/latex <Blackbeard>noobly: seems like texlive is installed <Blackbeard>noobly:$ guix package --list-installed | grep texlive
<noobly>Blackbeard: I did that earlier too: texlive-base, texlive-latex-preview, texlive-amsfonts, texlive-pstools, texlive-latex-base, texlive-latexconfig
<noobly>ultimately I'd just like to get latex working and producing pdfs, i wsa going to try uninstall + reinstall as a desperate last minute attempt
<noobly>really appreciate the help
<TZander>grmbl; enough for now... scheme for packaging is really not fun. Simple things like echoing a double quote to a file, and even finding a file, and all that is just sooo hard. This is utterly frustating to package.
<Blackbeard>noobly: ok, so what's the issue ? You can compile a .tex file to pdf with pdflatex
<Blackbeard>noobly: what is exactly the problem you are trying to solve?
<Blackbeard>TZander: what's the issue?
<noobly>no, that doesn't work for me. output is here: http://dpaste.com/2HZYFV9
<Blackbeard>TZander: what are you trying to package? Can you share in debian pastebin?
<noobly>hold on, that output was weird
<Blackbeard>noobly: what packages are you using on your file?
<TZander>Blackbeard: the issue is that a bash script is normally executed. It created a header file that gcc includes. The generated header file has a single define, and the git commit in it. Ignoring that this script doesn't work in git I just want to echo the version number to a header file.
<TZander>The equivalent of '#define GIT_COMMIT_ID "0.1"
<bendersteed>hi all! was really happy to see gnuradio and gqrx hit the repos today
<bendersteed>i was thinking maybe it would useful to have rtl-sdr udev rules as a package
<Blackbeard>TZander: so you want to modify a file before compiling ??
<TZander>Blackbeard: basically, yes. Or overwrite. https://paste.debian.net/1139613/
<bendersteed>like android-udev-rules, shall i work on it?
<noobly>Blackbeard: I'm just using a testfile, trying to convert '2+2' into a valid latex file. I was using org export, which usually takes care of all that. i set up a template file amsmath, graphicx, hyperref and latin1{inputenc}, but the output of pdflatex is the same.
<TZander>Blackbeard: I get an error that the file doesn't exist there (should be build/include/build.h). And I can't get actual double quotes to show up in the output file
<Blackbeard>noobly: can you compile a simple fire without any extra package ?
<Blackbeard>File*
<Blackbeard>TZander: so does it works except for the double quotes?
<noobly>Blackbear: im a little rusty on latex, but in my file now all i have is \documentClass[12pt]{article} 2+2 \end{document}, i get the same pdflatex output once again
<noobly>*Blackbeard^
<TZander>Blackbeard: the variable 'version' is also just plain text instead of the actual version.
<TZander>Blackbeard: and the 'add-after' doens't seem to actually make my lambda run after the configure step but before it.
<TZander>specifically, when I do an 'with-output-to-file' then it looks like that output file should exist at start of script, not at the moment the script is executed.
<Blackbeard>noobly: texconfig rehash
<TZander>well, the dirs should exist. THe file it can create. That looks like a bug to me IMOHO
<noobly>Blackbeard: tried that earlier as well. tried it again, but running pdflatex still produces the same output.
<Blackbeard>TZander: ok, please give me a few minutes to try to help from my PC. I am at the phone right now
<Blackbeard>noobly: have you tried rebooting ? Hahah
<TZander>np, thanks for helping!
<noobly>Blackbeard: lol, no... I'll try right now
<noobly>Blackbeard: reboot has gotten me much closer! still havng issues though but these seem to indicate that pdflatex is at least doing it's job. here is the most recent paste: http://dpaste.com/22CVJDC
<noobly>oh wait, that output looks super simple now lol
<noobly>it didn't say that before, welp
<noobly>one sec i think i'll get it
<noobly>oh my gosh i think it worked, gotta downlaod a pdf prgoram no
<noobly>*now
<Blackbeard>noobly: good!
<noobly>Blackbeard: I can't believe it was as simple as rebooting, lol... I'll remember to try that sooner next time!
<TZander>Blackbeard: I think I have a working version
<Blackbeard>TZander: oh good! I am still eating. But I am hurrying
<TZander>don't hurry on my account :)
<TZander>Its near midnight here, I won't be much longer
<noobly>how do i permanently disable network manager?
<rekado_>noobly: you can reconfigure your system after removing the network manager service from the list of services.
<noobly>nvm found it, phew. it's sudo herd stop networking. rekado: thanks, I'll try that in a bit. I had a problem with multiple dhclients and killing network manager helped, but upon reboot all these have resurfaced
<civodul>"rsync-boot0" o_O
<Blackbeard>civodul: what is that?
<civodul>mbakke: ↑ what happened with the linux folks? :-)
<civodul>Blackbeard: i just noticed that we now need rsync just to install the Linux-libre headers
<civodul>kinda unexpected
<Blackbeard>Ahh
<mbakke>civodul: I think they just got lazy, IIRC it was to work around some corner case in their build system, it took me by surprise too
<civodul>mbakke: not sure if it really matters, but would it work if we provided an rsync that's basically cp?
<mbakke>civodul: I'm sure we could at least patch the build system to undo the change: https://github.com/torvalds/linux/commit/59b2bd05f5f4dc62979c2e82ddd384f07e8f10bc
<civodul>it's terrible
<civodul>well dunno, rsync does have a few dependencies so we're adding stuff just for that one command
<mbakke>I suppose we could use 'find' & 'install' if we wanted to
<civodul>yes