IRC channel logs

2018-01-23.log

back to list of logs

<brendyn>mount -t ecryptfs ... refers to /bin/mount
<buenouanq>thomassgn: neat, thanks
<lfam>brendyn: Can you send a bug report or a patch?
<lfam>It could even be a single sentence, just so we don't forget
<brendyn>lfam: sure thing
<Guest73083>I sent a patch to guix-patches for retux/python-uniseg a couple of days ago that doesn't seem to have shown up in the archives. Could it be one of those "subscribed under a different address" issues? I didn't get the typical mailman "held for moderation" message though. Any ideas?
<castilma>someone awake?
<Apteryx>yep
<buenouanq>awake, but still as useless as ever~
<Apteryx>buenouanq: eh, don't say that :)
<castilma>i want to compile on x86_64 with -m32 and see this: gnu/stubs-32.h: File not found
<castilma>it is referenced directly by /gnu/store/...-profile/include/gnu/stubs.h:7:11
<castilma>seems to me like the installed libc was cleaned of every i386 specific stuff.
<castilma>how do i install glibc with the missing headers? (and where does gcc look for headers in guix?)
<castilma>witch --target?
<castilma>(gcc -print-search-dirs)
<Apteryx>castilma: I'm not sure! The manual covers touches it briefly in "2.6.6 The GCC toolchain", wher installing the 'gcc-toolchain' package is supposed to install gcc, the glibc with headers and binaries, and debug symbols if you also install the 'debug' output.
<atw>the packages gcc and gcc-toolchain don't provide cc. Is there a package I can add that would provide that, or should I just add CC = gcc to the Makefile I'm using?
<sneek>atw, you have 1 message.
<sneek>atw, Apteryx says: right, the local-file and other file-like objects need to be "lowered" into actual things by a gexp compiler, so to try them out at the REPL you'd need to use the correct gexp facility (I'm not sure myself which one :).
<atw>I'm oft running afoul of lowering :)
<CharlieBrown>Has anybody tried turning a site's JS into a WebExtension and then packaging it for Guix?
<CharlieBrown>This way, you can install a verified version of a site's JavaScript, instead of automatically running random code.
<buenouanq>at first that sounded like a neat idea,
<buenouanq>then it hit me how horrible that would make everything
<buenouanq>no more web browsers, everything just has it"s own APP
<buenouanq>there is no good fix for the modern wobsite problem, we'll have to step back and start over
<catonano>good morning guuixers. berlin.guixsd.org increased the coverage by a percentage point, up to 68%
<catonano>since yesterday
<CharlieBrown>buenouanq: I'm not so pessimistic: "Take in all the garbage! Cake it on! Make the monkey dance!"
<CharlieBrown>buenouanq: The reality is that every website is a program, and so we shall treat them.
<buenouanq>I miss web 1.0 ;~;
<catonano>buenouanq: I do too
<civodul>Hello Guix!
<CharlieBrown>Where will WebExtension package recipes be stored?
<efraim>tbb has built before for aarch64
<efraim>oh, i'll be waiting a while, test phase failed after ~40 minutes
<buenouanq> https://rectilinear.xyz/p/c70bc394f9+ posting my guix aliases again in hopes that someone maybe has a better way to find package/service modules (gpM)
<buenouanq>thomassgn: have recently reinstalled and upgraded everything (guixsd) on my macbook and have not had the weird trackpad thing for the last 4 or so reboots
<buenouanq>but now that I've said this I'm sure it'll start happening again (;-___-)
<rekado_>Hi Guix!
<rekado_>The Librem 13 that I ordered as a work laptop has arrived… at the customs :-/
<rekado_>looks like it’s going to be difficult to get it through customs here. They didn’t include a German manual nor a declaration of conformity.
<rekado_>confirmation of payment took a very long time, so I’ve been waiting for this laptop since November last year.
<rekado_>very frustrating.
<civodul>bah :/
<civodul>probably you were unlucky that the customs looked at it this closely, no?
<rekado_>that’s possible.
<rekado_>but really, purism should ship their laptops such that the minimal requirements for EU import are met.
<rekado_>if I can’t get it sorted out within the next 10 days the laptop will be sent back or be destroyed.
<rekado_>at least the declaration of conformity is a requirement throughout the EU.
<civodul>yeah they should have paid attention to this, if they were to make customers happy...
<civodul>heya mbakke!
<civodul>mbakke: do you have ideas regarding the ICU-related build failures on core-updates? :-)
<wigust>Hello
<thomassgn>buenouanq: Nice.
<efraim>sunxi-tools FTBFS on armhf because armhf fails to build the armhf->armhf cross chain
<mbakke>civodul: haven't been paying attention, sorry. Maybe build them against an older variant?
<mbakke>I'll be "back" tonight or tomorrow and can have a look.
<buenouanq>thomassgn: sort of - I'd rather understand \\emph{why} it happens than just having it magically go away ( ._.)
<thomassgn>hehe, yes - true. I guess currently I have a bit much of non-computer-life happening, so I'm just happy when it works enough that I don't need to fix anything :)
<buenouanq>so it doesn't look like we have jitsi or ekiga
<buenouanq>what sort of internet telephone things do we have right now?
<buenouanq>what are all the cool kids today using?
<rekado_>buenouanq: I heard that cool kids use ring.
<buenouanq>not seeing it, what's the package name?
<snape>Is there a reason why Zathura is not propagated from its plugins?
<rekado_>we don’t usually propagate main applications from plugins.
<rekado_>same goes for all R packages; they don’t propagate r-minimal.
<snape>then what's the point of adding as an input, if it's not even usable without installing it manually?
<snape>of adding *it
<rekado_>it may be required to build the plugin.
<rekado_>for R packages R itself is required to build the packages, but no reference to R is retained.
<snape>Yeah it makes sense. But I don't understand why we don't propagate main applications from plugins
<rekado_>in general we avoid propagation.
<snape>But when it makes sense?..
<snape>The plugin (a .so file) is obviously unusable without the propagation, so to me it makes sense to propagate.
<mbakke>snape: maybe the user wants to use another version of Zathura.
<snape>mbakke: then they would package the other version of Zathura. But if they are able to package it, they would be able to inherit from the plugin too, so as to change its propagated input.
<snape>And anyway zathura is an input of its plugin, so if the user wants to use another version of Zathura, they have to build the plugin too with that new version.
<mbakke>snape: but they would not be able to use plugins from Guix with their custom Zathura. Unless they override all plugins as well.
<t0167641>hi, i need help for script running, due to not welll define env
<snape>mbakke: yes, but they can't do that anyway since Zathura is an input of its plugins.
<mbakke>I don't think it matters which zathura the plugins are built with.
<snape>it will matter if Zathura API changes
<t0167641>i have a python script name "lapin", and when i run it over a guix container the bang cannot be resolve because /bin/env, /bin/python is false etc...
<snape>it *may matter, I don't think it's a good idea to assume it won't.
<t0167641>my command : guix environment --pure --container bash python@2 -- ./lapin
<mbakke>snape: sure, but my custom zathura can still have the same API. Propagating would prevent using any custom zathura at all.
<t0167641>how can i set to guix env to link profile/bin to /bin/ in the profile like pack option
<mbakke>I often hack on some stuff in a package and reuse the Guix package definition. Propagation would prevent me from using the custom package with existing stuff.
<snape>mbakke: But if you have a custom Zathura, it makes sense to have a custom plugin too. And your case is an edge case, whereas my issue happens to everyone who just wants zathura-mupdf and won't understand why they have to install zathura too.
<t0167641>sorry re
<snape>I really think that using a plugin with another Zathura that's the one being its input is not a very good practice.
<snape>*with a Zathura that isn't the one...
<mbakke>t0167641: I don't think `guix environment` can set up FHS-style paths. Either strip the /bin paths and rely on $PATH or create a package definition for the script and patch it to use absolute references.
<Apteryx>has the ui changes making most command silent been merged?
<t0167641>then i was oblige to use a scheme scritp to set the environment ?
<snape>t0167641: you can use --expose to expose your /bin to your environment
<rekado_>Apteryx: which change would that be?
<civodul>mbakke, t0167641: one could use "guix environment -C ..." and then "ln -s $GUIX_ENVIRONMENT /usr"
<Apteryx>rekado_: when I run 'guix environment ...', it takes a long time to print anything.
<snape>t0167641: and special-files-service-type to create /bin/env on your host (see https://www.gnu.org/software/guix/manual/html_node/Base-Services.html)
<t0167641>thanx snape
<t0167641>this solution look good, we are agree this solution can only be use by scheme definition ?
<t0167641>and not with the bash command line
<t0167641>?
<snape>t0167641: 'guix environment' is a command. If your goal is to create a package for 'lapin', then there is 'patch-shebang' (which build systems use) that will patch the shebang and make it work.
<t0167641>i want to use guix to control my script dépendance, for that i use the guix environment with --ad-hoc option, and i don't find any option to use bang without link myself or write scheme code
<t0167641>i just ask, because this option exit in guix pack and not in enviroment
<t0167641>and i doesn't want to do a package with 'lapin', just use guix as a project tool dépance
<snape>t0167641: why don't you make a private package of 'lapin'? Then the dependencies would be properly handled.
<snape>mbakke: rekado_: if the 'zathura' input is just a build dependency, then it should be a native-input I guess.
<mbakke>snape: you can check if it's referenced with `guix gc --references`.
<snape>mbakke: that will show everything that is in 'inputs', which I can see by reading the code, so I don't see how it helps.
<snape>oh sorry
<snape>you're right
<mbakke>snape: it will catch everything that's referenced at runtime and does not know anything about build inputs.
<PotentialUser-39>Hello All, I need to discuss a specific use case and would like to know how i can use Guix for it.
<snape>yeah
<PotentialUser-39>am I in the right channel for this?
<snape>PotentialUser-39: yes :-)
<PotentialUser-39>thanks
<PotentialUser-39>So I would like to explain then :)
<PotentialUser-39>I am developing a specific software which I need to roll out remotely to some IOT devices periodically.
<PotentialUser-39>We have our propritory download and installation app which installs the full distro on the devices.
<PotentialUser-39>But, in future we would like to go for partial and incremental updates for the applications running in our system and thus need a package manager for this.
<PotentialUser-39>We would still like to distribute the updates via our own download application, but want to use install using a package manager
<PotentialUser-39>any opinions on how can I use Guix for this? is Guix the right package manager for such scenarios?
<mbakke>PotentialUser-39: I think GuixSD will work fine. You can push pre-built system profiles to the clients.
<wigust>PotentialUser-39: You cannot use any part of Guix without liberating of proprietary stuff to build a system from it, because everything in Guix is GPL3+ (including package definitions). I can be wrong still.
<PotentialUser-39>@wigust: so do you mean, that I cannot use the package management functionality without building my complete system for GuixSD?
<PotentialUser-39>I would like to just use Guix as a package creator and installer - no more!
<snape>PotentialUser-39: I see no reason why you couln't.
<snape>couldn't*
<snape>wigust: Debian, Arch include proprietary stuff
<wigust>PotentialUser-39: Ah, I thought you were talking about building a proprietary system on top of GuixSD. Still for usage as a package manager in proprietary system is not possible, I believe.
<wigust>PotentialUser-39: GuixSD is an operating system and Guix is a package manager.
<PotentialUser-39>No, we have a specific linux distribution and donot want to move to GuixSD
<PotentialUser-39>wigust: yes, this is what i understood from the documentation and therefore, just want to use Guix as a utility for creating and installing packages
<wigust>snape: Debian and Arch are different. They don't care basically, if you look on Debian non-free repository for example.
<wigust>Also Arch has a liberated Parabola fork.
<PotentialUser-39>snape: I suppose for Guix, it does not matter which flavour it is installed on
<mbakke>I'd consult an attorney before distributing Guix packages on a proprietary distribution to end users. The source code of Guix and package definitions must be available to the end users due to GPL, not sure about the rest.
<PotentialUser-39>mbakke: understood
<PotentialUser-39>mbakke: thats already abig question mark, if Guix makes sense for us or not.
<mbakke>Guix excels as a general-purpose package manager, so it will probably be a good fit technically.
<PotentialUser-39>mbakke: Since I am in evaluation phase, what makes Guix as the best choice for this use case? any opinions?
<PotentialUser-39>I have already done some research on OPKG for our case, but still trying to find out if Guix is any better.
<PotentialUser-39>The only point which I found in the documentation is the "operation rollback" feature.
<mbakke>PotentialUser-39: I'm biased ;) but easy package definitions and atomic upgrades and roll-backs are big selling points. For the embedded case yum might work just as well.
<PotentialUser-39>mbakke: do you have more information on tomic upgrades and roll-backs i.e. how it works?
<mbakke>Guix is somewhat "heavy" and you might not want clients to fall back to building from source. AFAIK that's not possible to prevent right now (but should be fairly easy to implement).
<mbakke>PotentialUser-39: Guix builds (realizes) an entire profile with all the defined packages and swaps a symlink, for every operation.
<mbakke>I'd recommend installing it on your distro of choice and play around with it a bit.
<PotentialUser-39>mbakke: ok
<PotentialUser-39>mbakke: any hello-world examples?
<mbakke>For package definitions?
<PotentialUser-39>for creating a package and installing it
<davexunit>PotentialUser-39: the manual has an example package for gnu hello
<PotentialUser-39>mbakke: is entire profile per user? or per operation?
<mbakke> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/base.scm#n62 :)
<PotentialUser-39>because we only have just one user on the devices i.e. root
<PotentialUser-39>these are small devices, with no user management on them
<mbakke>PotentialUser-39: users can add as many profiles as they please. By default it's per-user, but many create profile manifests and realize those.
<mbakke>So either use the root profile or a custom profile directory.
<PotentialUser-39>mbakke
<PotentialUser-39>mbakke
<PotentialUser-39>mbakke: so that means I would be able to replace old profile with the new one (after installation) for the same "root" user
<mbakke>You can use manifests (or not) in any case.
<mbakke>Yes. And roll back to the previous profile any time.
<mbakke>Note that you'll need to clean old profiles and run garbage collection to reclaim disk space.
<davexunit>PotentialUser-39: I wrote a blog post back in 2013 after I wrote my very first package and it has a simple package reicpe in it that may be of some use to you getting started: https://dthompson.us/my-first-gnu-guix-patch.html
<PotentialUser-39>davexunit: yes, thats something what I am looking for, will have a look at the blog. Many thanks!
<PotentialUser-39>mbakke: thanks this helps
<PotentialUser-39>mbakke: coming back to your earlier comment "Guix is somewhat "heavy" and you might not want clients to fall back to building from source. AFAIK that's not possible to prevent right now (but should be fairly easy to implement). "
<PotentialUser-39>mbakke: I could not understand what you meant. Can you explain a little bit?
<mbakke>PotentialUser-39: Guix will build any package from source if no binary substitute is available.
<quiliro>hello Guix!
<quiliro>Saluton!
<quiliro>Bonan matenon.
<civodul>bon dia!
<quiliro>It is weird. I did guix gc and lost WiCD
<mbakke>The heavy part comes from the immutable store, but if you only distribute binaries it should not end up too big.
<quiliro>civodul: bon dia a voce!
<PotentialUser-39>mbakke: in our case, we build thge packages in house and distribute them to the required clients.
<PotentialUser-39>mbakke: yes, we plan to distribute only binaries
<quiliro>should the system install wicd or it is a user program?
<civodul>quiliro: there's a service, see https://www.gnu.org/software/guix/manual/html_node/Networking-Services.html
<civodul>nowadays GuixSD defaults to NetworkManager though
<PotentialUser-39>no its mainly a user program with specific configurations
<mbakke>PotentialUser-39: But again, make sure to read GPL3 carefully, in particular section 6.
<PotentialUser-39>mbakke: yes, i got your point. I will confirm this before going any forward.
<quiliro>is network manager included with (desktop-services) _
<quiliro>?
<quiliro>i mean %desktop-services
<quiliro>as it says in the manual
<quiliro>will this config.scm for reconfigure be the problem? https://pastebin.com/qpWmY5zn
<quiliro>i did not realize %desktop-services changed to networkmanger, but wouldn-t %desktop-services deal with that?
<quiliro>what i mean is that i did not realize %desktop-services changed from wicd to nm....but i ran reconfigure with %desktop-services....so i should have nm in my oser...or not?
<quiliro>s/oser/user/
<quiliro>will guix gc remove that program?
<quiliro>why would 'guix package -u' then 'guix gc' and then 'guix package -u' not report packages are up to date, but download and install a bunch of programs
<quiliro>and now i do not know how to connect to wireless networks i have not coonneted to before
<quiliro>please give me tip
<quiliro>s/coonnected/connected/
<civodul>quiliro: if you reconfigured you have the NetworkManager daemon running, and you have commands like 'nmtui' in the profile
<civodul>in the system profile, i.e., /run/current-system/profile
<wigust>quiliro: this 'nmtui' will help you out with wireless
<wigust>quiliro: Also you could look what profile the package belongs to with 'which nmtui'.
<quiliro>civodul, wigust: nmtui complains about permissions when run with nonroot proviliges (without sudo)...it is understandable if it is a root profile, but user should be able to use wireless communications without root priviledges
<quiliro>wdyt?
<quiliro>it will complain about changing wireless passwords
<quiliro>cannot add, erase or modify wireless connections in nmtui as user without
<wigust>quiliro: I think you should look onto policykit
<quiliro>perhaps i can just connect and it will ask for password
<quiliro>but i cannot test that now
<quiliro>i will report as soon as i can test
<quiliro>thank you civodul and wigust for your help
<quiliro>my problem is temporarily solved!
<quiliro>but i have another problem....as i told you before
<quiliro>why would 'guix package -u' then 'guix gc' and then 'guix package
<wigust>quiliro: Seems like a bug for me, dunno. Maybe related to https://debbugs.gnu.org/cgi/bugreport.cgi?bug=28743
<wigust>quiliro: It should not 'install' for sure, only upgrade.
<wigust>quiliro: Maybe because of grafts?
<wigust>quiliro: What does 'guix package --no-grafts -u . && guix gc && guix package --no-grafts -u .' do?
<quiliro>it will take a day or so to upgrade
<quiliro>because it is a cor2duo
<quiliro>core2duo
<quiliro>please do not ask me to do that
<wigust>quiliro: You don't need to do this on your user profile with a big package list. Could play with a different one with 'guix package -p /tmp/play-guix …'.
<wigust>quiliro: As you wish. :-)
<quiliro>wigust: oh!
<quiliro>but i do not need a new user, right? what has to be in /tmp/play-guix....the list of packages?
<quiliro>the marvel or running guix package -u a few days after guix pull!
<quiliro>it took minutes to upgrade!
<wigust>quiliro: It's not a new user. It's a profile which user could have in any amount. It will be removed after reboot and garbage collected after 'guix gc'.
<quiliro>what does the file contain? is it in the manual?
<wigust>quiliro: sure it is there :-)
<quiliro>wigust: i could only find:
<quiliro>‘--profile=PROFILE’
<quiliro>‘-p PROFILE’
<quiliro> Use PROFILE instead of the user’s default profile.
<quiliro>in guix package
<quiliro>how can i search for that?
<quiliro>that which you are mentioning (contents of PROFILE)
<wigust>quiliro: Same as your user's profile. I don't remember contents description in the manual. It's just manifest file and a bunch of directory similar to FHS.
<quiliro>oh! a manifest file.....what is FHS?
<quiliro>wigust: ^
<wigust>quiliro: /bin /etc /share /bla-bla-bla
<quiliro>File Hyerchy
<quiliro>System?
<quiliro>ok...thanks
<quiliro>wigust: what is FHS for in this manifest file?
<quiliro>i suppose it is mentioned in the manual in the part of how to make a manifest file
<quiliro>ok....i think now i understand how to learn guix....start learning guix package in the first place
<quiliro>then i can understand better whatever else i need to learn
<quiliro>wdyt?
<quiliro>really understanding package management
<quiliro>gc, pull, package...to start with
<quiliro>not in that order!
<wigust>quiliro: Just use it for some time, it will become clear, I think
<wigust>quiliro: It's really robust to play with because you could always rollback by reboot or with 'guix package'.
<quiliro>i have had a lot of problems with reconfigure
<quiliro>and now with wicd....this one is trivial
<quiliro>the boot problems were show stoppers
<quiliro>but i am not going to reconfigure any more than once a year now
<quiliro>unless i have a permanent connectin for 1 week and have nothing else to do
<quiliro>wicd problem was raised with reconfigure also
<wigust>quiliro: So you could just reboot to the previous generation, couldn't you?
<quiliro>so i think guix package -u long upgrades can be solved by running it a week or two after guix pull
<quiliro>wigust: yes but sometimes older generatiosn would not work either...perhaps i did not know what i know now
<quiliro>it sometimes took 2 weeks to recover boot
<quiliro>also, one time the disk needed fsck wich could not be repaired by booting with the installed system...had to reboot with usb...but 0.14 would not boot with my machine
<quiliro>s/wich/which/
<quiliro>so it is preferable not to reconfigure that often
<quiliro>unless someone could help at the time in order to solve in less than a few hours
<quiliro>is it possible to pull to an earlier version?
<quiliro>so the available packages have substitutes available
<quiliro>maybe in the way you can switch generations!
<quiliro>but before installing
<quiliro>this could be useful in 'sudo guix pull' and in 'guix pull' also
<quiliro>someting like :
<quiliro>guix pull --switch-generation=-1
<quiliro>sudo guix pull --roll-back
<quiliro>guix pull --switch-generation=10days
<quiliro>i guess it is not desireable
<quiliro>for most users
<quiliro>or devs
<quiliro>rather
<quiliro>it would be great for low end machines
<quiliro>and for people with short connection times
<quiliro>what is the current option? building a substitute server? but how can i predict what i will want to install between connections
<quiliro>what about offloading? is that using another machine for building packages? will downloading sources and building them be quicker than downloading the substitutes?
<quiliro>is anyone reading...am i disconnected?
<mbakke>quiliro: offloading sends all build inputs to a remote server which performs the build and send the result back.
<quiliro>mbakke: that would be great!
<mbakke>You'll want a decent connection to the build machine since you send the entire dependency closure for every build.
<quiliro>is it possible to install guix in parabola via pacman -S guix ?
<bavier`>there's no such package on parabola afaik
<quiliro>2MB/s is enough
<quiliro>bavier`: there is! guix 0.11
<quiliro>bavier`: i am wrong according to https://www.parabola.nu/packages/?q=guix
<quiliro>it is version 0.14.0-1
<quiliro>updatde yesterday
<bavier`>oh, nice
<quiliro> https://wiki.parabola.nu/Using_GNU_Guix_on_Parabola
<quiliro>are those instructions still good?
<quiliro>they were updated 2016
<CharlieBrown>Why does there need to be Parabola-specific instructions? Just use the Guix manual.
<adfeno>CharlieBrown: I also wonder the same.
<CharlieBrown>I'm glad there's a Guix package.
<CharlieBrown>That said, I forgot all the workarounds I did to get Guix to work on Trisquel. But I guess I just have to search "adfeno" on Trisquel forum and see all the answers. :D
<adfeno>Hahaha
<adfeno>That XDG_DATA_DIRS wizardry....
<CharlieBrown>I'm heavily considering writing an auto-install script that turns Parabola into a very conventional GNOME desktop. Unlike preconfigured distros, the setup will be completely documented, and easy to hack.
<adfeno>Too bad I'm currently unable to both use and work on packaging GNU Ring for Guix :S
<CharlieBrown>(I like Parabola because it's easier to hack.)
<CharlieBrown>adfeno: Ring isn't working for you, or you just don't have time?
<adfeno>I love every free/libre distro because they are free/libre ;)
<adfeno>CharlieBrown: No time
<CharlieBrown>adfeno: Do you like BLAG and PureOS?
<quiliro>did not workguix with pacman
<quiliro>i will try the guix docs
<CharlieBrown>Does Flatpak work on GuixSD?
<CharlieBrown>I'd like to start telling people to package apps with Flatpak and everything else with Guix.,
<quiliro>pacman -R guix
<CharlieBrown>I failed at making a script to automate the tips in the Guix docs. I hear Uruk made such a script, but IDK where it is.
<adfeno>CharlieBrown: BLAG: Sure, as long as it's free/libre ;)
<adfeno>PureOS: Yes, as long as it's free/libre (and they maange to keep it alive since they now decided to start their own fork of Debian, instead of contributing to gNewSense)
<CharlieBrown>I hate your-freedom. It blocks free software in untrusted external repos.
<CharlieBrown>And people are too lazy to add the free software back.
<adfeno>I recall there is some backstory between GNewSense and PureOS
<CharlieBrown>If I could add the free software back, like make my own pacman repo full of Kodi/R/Python/RetroArch extensions, that'd be great.
<mbakke>ケーラブ: why not package them with Guix instead ;)
<CharlieBrown>Because the whole RetroArch repo was removed without any replacement, even though Debian DOES replace the untrusted upstream repo.
<CharlieBrown>with a free one
<CharlieBrown>I understand that they have to flat-out remove an entire repo becasue they don't have time to separate out the free software, but it makes my system hard to use.
<quiliro> https://www.gnu.org/software/guix/manual/guix.html#Binary-Installation has step 2 wrong
<quiliro>mv guix-binary-0.14.0.x86_64-linux.tar.xz /tmp
<quiliro>is needed before
<quiliro>cd /+tmp
<quiliro>s/+//
***Jorge is now known as Guest77594
<quiliro>after:
<quiliro># guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub
<quiliro>I get:
<quiliro>guile: warning: failed to install locale
<quiliro>warning: failed to install locale: Invalid argument
<quiliro>$ guix package -i glibc-locales
<quiliro>guile: warning: failed to install locale
<quiliro>warning: failed to install locale: Invalid argument
<quiliro>guix package: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory
<quiliro>sorry for the flood
<Jorge>Hi. I have authorized substitutes but they are ignored. I have issued ~sudo guix archive --authorize < /gnu/store/pii5cimi72lj5l7793h54g5sg0sr2apl-guix-0.14.0/share/guix/berlin.guixsd.org.pub~
***Jorge is now known as Guest70939
<Guest70939>I also issued ~sudo guix archive --authorize < /gnu/store/pii5cimi72lj5l7793h54g5sg0sr2apl-guix-0.14.0/share/guix/hydra.gnu.org.pub~
<Guest70939>But guix wants to compile everything
<Guest70939>For example, ~sudo guix build emacs --dry-run~ would not download a single substitute, instead it would build dozens of derivations.
<mbakke>Are you sure it's "everything"? Sometimes binary substitutes are not available and Guix resorts to building locally.
<mbakke>For emacs it would also have to download substitutes for every runtime dependency.
<Guest70939>For emacs, it wants to build 446 derivations.
<Guest70939>And does not download a single substitute
<Guest70939>For Bash, it would build six derivations, download zero substitutes.
<Guest70939>For GCC, it would build 18 derivations, download zero substitutes
<Guest70939>And everything I actually try to do results in a big number of builds, and I never see it downloading substitutes.
<Guest70939>I still have not finished ~guix pull~ because it tries to build many derivations and some download fails with some hash mismatch. This happened two or three times already.
<mbakke>Guest70939: that's terrible.
<mbakke>Can you check that the hydra key is indeed in /etc/guix/acl?
<Guest70939>I am under a corporate proxy, meditated by ntlmaps. In override.conf I have configured http_proxy=http://localhost:5865 https_proxy=https://localhost:5865 ftp_proxy=ftp://localhost:5865 all_proxy=localhost:5865
<Guest70939>Most source tarball downloads succeed, which indicates the proxy configuration is working
<mbakke>And please report those hash mismatches.
<Guest70939>OK, I will check
<Guest70939>mbakke: three copies of hydra's public key seem to be present in /etc/guix/acl
<mbakke>Msybe `guix substitute` ignores http_proxy or something. Can you file a bug report?
<mbakke>Also try `guix weather`, does it show whether substitutes are available?
<apteryx_>Hi! I'm attempting to clone a personal git repo over ssh, and I get: git-upload-pack: command not found
<Guest70939>guix weather fails. Let me try it in order to see the error message
<apteryx_>shouldn't this be already in my PATH?
<Guest70939>guix weather: error: perl-text-markdown-discount-unbundle.patch: patch not found
<Guest70939>mbakke: and this time guix pull failed on the first download: sha256 hash mismatch for output path `/gnu/store/zdahqsfvra1r2ic61x1blh3i3p7xsax6-libpng-1.6.29.tar.xz'
<mbakke>Guest70939: That at least seems to hint that it's trying a substitute. Could it be that the proxy adds some kind of compression or similar?
<quiliro>/home/ernesto/.guix-profile/etc/profileGUIX_PROFILE=/root/.guix-profile does not exist
<Guest70939>I do not know
<mbakke>Apteryx: if the remote uses a recently-installed GuixSD then PATH should be correctly set up when using SSH.
<mbakke>Otherwise grab a fresh .bashrc from /etc/skel.
<apteryx_>mbakke: the remote is using a freshly updated GuixSD, yes.
<apteryx_>the problem happens when doing 'git clone myhost:some/path/torepo.git'
<mbakke>apteryx_: check that the SSH_CLIENT line in .bashrc matches that of /etc/skel/.bashrc. This was fixed somewhat recently.
<Guest70939>It is configured to use ntlmaps. I could try configuring it to use the proxy server directly, but then it would need to know my corporate login and password in order to authenticate itself to the proxy server. How do I provide the password?
<mbakke>Guest70939: I don't know :) could you try to download the substitute manually and inspect it with `file`?
<mbakke>Hmm or I guess most HTTP clients would decompress automatically, if the proxy was adding gzip compression.
<Guest70939>I tried browsing to http://downloads.sourceforge.net/project/libpng/libpng16/1.6.29/libpng-1.6.29.tar.xz in my web browser; it redirects me to a download page which only offers version 1.6.32
<Guest70939>So I cannot compare
<Guest70939>Meanwhile, should I fix /etc/guix/acl, which appears to show three copies of the same public key? How do I do that quickly and reliably? Can I delete the whole file and then authorize the two servers again?
<mbakke>Guest70939: the tarball you tried to download earlier was a substitute for the "lib" output of libpng. So it does try to fetch substitutes, but fails for some reason.
<apteryx_>mbakke: oh, it doesn't! Do I have to do 'cp /etc/skel/.bashrc ~/.bashrc' on my GuixSD system?
<mbakke>Can you file a bug report? Even if it turns out to be a misconfigured proxy, maybe we could try to detect double compression and strip it.
<mbakke>apteryx_: or manually merge the lines.
<apteryx_>mbakke: I've never touched this file myself, so I'll go with the full replacement :)
<apteryx_>mbakke: it works! thank you :)
<mbakke>apteryx_: yay! The system test for SSH servers now also verifies that this works forever :)
<apteryx_>mbakke: super!
<wigust>Guest70939: What about ftp://ftp.simplesystems.org/pub/libpng/png/src/history/libpng16/libpng-1.6.29.tar.xz
<mbakke>wigust: I'm not in front of a (proper) computer, but we're looking for /gnu/store/zdahqsfvra1r2ic61x1blh3i3p7xsax6-libpng-1.6.29.tar.xz. Can you try to construct the Hydra URL?
<mbakke>Oh wait, that's not the lib output.
<mbakke>Stupid tiny screens with confusing line breaks.
<mbakke>Anyway it should also be on Hydras content-adressed mirror.
<efraim>i have a copy on my aarch64 substitute server if that helps
<efraim>if you try with --fallback it should try again with another substitute server or the content addressed mirror if you get the wrong hash
<mbakke>Guest70939: ^
<Guest70939>OK, I will try that as soon as the current guix pull finisnes (probably it will fail again).
***Guest70939 is now known as JorgeMorais
<wigust>mbakke: Is https://berlin.guixsd.org/nar/zdahqsfvra1r2ic61x1blh3i3p7xsax6-libpng-1.6.29.tar.xz
<JorgeMorais>I have just issued ~guix pull --url=/home/jorge/repos/guix --fallback~.
<JorgeMorais>The --url option is because otherwise git fails. To make it work, I have added ~--chroot-directory=/home/jorge/repos/guix~ to the daemon command line.
<JorgeMorais>Hi. I have tried to configure the proxy environment variables in /etc/systemd/system/guix-daemon.service.d/override.conf to connect directly to my corporate proxy, not mediated by ntlmaps.
<JorgeMorais>I specified username and password in the proxy environment variables.
<JorgeMorais>However, guix pull fails with:
<JorgeMorais>Starting download of /gnu/store/zdahqsfvra1r2ic61x1blh3i3p7xsax6-libpng-1.6.29.tar.xz From http://mirror.hydra.gnu.org/file/libpng-1.6.29.tar.xz/sha256/0fgjqp7x6jynacmqh6dj72cn6nnf6yxjfqqqfsxrx0pyx22bcia2... ERROR: In procedure struct_vtable: Wrong type argument in position 1 (expecting struct): #f
<civodul>JorgeMorais: does the same happen if you 'guix download' that URL, again with the proxy env vars?
<JorgeMorais>I'll test that, but please wait a little. Problems here.
<trivialfis>How to have bash completion for guix on foreign distro?
<pkill9>trivialfis: `guix package -s bash-completion`
<civodul>sneek: later tell trivialfis the 'guix' package provides Bash completion under $prefix/etc
<sneek>Got it.
<bavier`>what's a good way to complain about a software failing when installed to a read-only prefix?
<bavier`>while anticipating suggestions like "why not make it writable?"
<civodul>bavier`: to complain to upstream devs you mean?
<bavier`>civodul: right
<civodul>well, "it is a universally admitted convention that everything but $localstatedir is read-only, kthx"
<bavier`>nice and concise :)
<civodul>:-)
<civodul>there's no real argument, other than it's a widespread convention, i guess
<bavier`>civodul: this is "spack" btw
<civodul>you can tell them that everything on their GNU/Linux or Unix system works this way
<civodul>bavier`: oh, wat?
<civodul>well, well!
<bavier`>it tries to write to $prefix/share, $prefix/opt, $prefix/var
<civodul>but wait, there's no notion of "prefix" for Spack itself, is there?
<civodul>i thought one was supposed to run ./spack straight from the checkout, no?
<bavier`>well, "root of the Spack install tree"
<bavier`>civodul: right, but they kinda sorta support "system" installations
<bavier`>and with some configuration variable tweaking I thought I could get things to work as a guix package
<civodul>hmm, ok
<civodul>perhaps you'll have to modify it a bit to match these expectations
<civodul>ACTION does "extreme" programming on Cuirass in the truest sense of the word
<bavier`>yeah, it'll be fun; have to dust off my python muscles
<civodul>heh